Re: [libvirt] [PATCH 2/3] libxl: add support for CPUID features policy

On 06/29/2017 09:39 AM, Marek Marczykowski-Górecki wrote: > On Thu, Jun 29, 2017 at 10:04:42AM +0200, Jiri Denemark wrote: >> On Thu, Jun 29, 2017 at 03:11:42 +0200, Marek Marczykowski-Górecki wrote: >>> Set CPU features in appropriate libxl structure. >>> Use old "xend" syntax, because it allow control over any bit and libvirt >>> already have API for translating features to appropriate cpuid bits. And >>> also features naming in libxl do not match the one of libvirt in >>> multiple cases. >> >> How does the new syntax look like? > > "host,tm=0,sse3=0" > >> And would it be actually better? > > Maybe? But the new syntax use different names for many features (like > pni vs sse3, or sep vs sysenter), so it would require some ugly > translation table... > What I would really like here, is to get list of bits specified with > <feature ...>, _without_ those defined by <model>. And maybe even > without requiring <model> to be set at all. > Another misleading thing about interpreting <model> here is, it doesn't > mask out features not really present in that CPU. So, you get a CPU > based on <model> but with many additional features. > Two suggestions (the first one to hopefully complement current discussion): 1) Maybe there could be a driver config item to allow the Xend syntax (since it's a rather fragile facility that allows all bits controlled)? Or else prefer first libxl format through the translation table of features and use xend format for this driver config such that non-supported features in libxl format fallback to xend format instead? Probably this allows for best of both worlds (better safety with libxl-format) yet higher flexibility/controllability with xend format. Also I am not sure we should support models either - since our CPUID view is restricted to host-{passthrough,model} only.

2) perhaps part of the code in this patch could be better placed at xenconfig/xen_{xl,xm}.c since it's really two different formats of config? This would also allow supporting Xen <-> Xml config file conversions.