Re: [Xen-devel] [PATCH v9 1/3] xen/libxc: Allow changing max number of hypervisor cpuid leaves

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.05.14 at 17:23, <boris.ostrovsky@xxxxxxxxxx> wrote:
> On 04/23/2014 08:36 PM, Zhang, Yang Z wrote:
>> Jan Beulich wrote on 2014-04-23:
>>> I'll definitely want a VMX maintainer's ack (or at least Yang's 
>>> consent) on patch 3 before applying the whole series (the first two 
>>> patches alone don't make that much sense). 
>> I have discussed with Boris before (offlist) and I don't think it is 
> necessary to expose two bits. Per my understanding, only one bit to indicate 
> whether APICv is enabled should be enough. The reason is that all hardwires 
> that support APICv must also support virtualized x2apic(Intel SDM doesn't say 
> it explicitly, but I get confirmed from hardware guys). And in current Xen's 
> implementation, it will enable APICv and virtualize_x2apic unconditionally if 
> hardware support them and not disabled by user. So based on current xen's 
> implementation, APICv is enabled means virtulized x2apic is enabled, vice 
> versa. That's the reason why I think one bit is enough.
>> But if you guys think two bits also is acceptable, I am ok.
> 
> 
> Jan, how do you want to proceed? Although I didn't realize that x2apic 
> virtualization is guaranteed for APICv-enabled silicon I still prefer to 
> keep separate bits for x2apic vs plain APIC for guests that can only use 
> the latter.
> 
> (I know that I need to resend this in any case with stray printk removed)

I already committed the patches a couple of days ago (with that
printk() removed).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel