On Thu, Jun 29, 2017 at 10:21:11AM +0100, Joao Martins wrote:
> 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.
IIUC setting CPU model is required to get CPUID bits from libvirt cpu
API (cpuEncode function). If there is some other way, that would be
great. But if that would require changing cpu libvirt internal API, I
think just a fallback doesn't worth it.
> 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.
Ok, I'll look into it.
--
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
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
