[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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.

> The
> problem with setting individual CPUID bits is very fragile. That's
> mostly what we naively started to do in qemu driver and we're fighting
> with it since then. It's way too easy to create a virtual CPU which a
> guest OS will crash on.

Well, IMHO if you modify things like CPUID you should really know what
you are doing...

-- 
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?

Attachment: signature.asc
Description: PGP signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]