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?
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
