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

Marek Marczykowski-Górecki marmarek at invisiblethingslab.com
Thu Jun 29 22:21:27 UTC 2017


On Thu, Jun 29, 2017 at 11:00:35AM +0200, Jiri Denemark wrote:
> On Thu, Jun 29, 2017 at 10:39:26 +0200, 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"
> 
> Is "host" fixed there or are other CPU models supported too? 

Only "host".

> If only
> "host" is allowed, libxl driver should support host-passthrough mode
> only and it would be pretty easy to map it to the libxl's syntax. The
> following CPU XML
> 
>     <cpu mode='host-passthrough'>
>       <feature name='avx' policy='disable'/>
>       <feature name='aes' policy='require'/>
>     </cpu>
> 
> could be directly translated into "host,avx=0,aes=1".

That would make sense, indeed. One practical issue is that I'm doing the
whole thing to disable "smap" bit. And this bit isn't supported in the
new libxl syntax. At least not yet - I've already submitted a patch to
add it :)

> > > 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...
> 
> I don't a translation table would be ugly.

Ok.

> > 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.
> 
> That's what host-passthrough mode is for.

Ok.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170630/0b1f464e/attachment-0001.sig>


More information about the libvir-list mailing list