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

Re: [Xen-devel] [PATCH v3 4/4] x86/hvm: Indicate avaliability of HW support of APIC virtualization to HVM guests



Boris Ostrovsky wrote on 2014-03-14:
> On 03/13/2014 09:48 PM, Zhang, Yang Z wrote:
>> 
>> 
>> +/*
>> + * Leaf 5 (0x40000004)
>> + * HVM-specific features
>> + */
>> +
>> +/* EAX Features */
>> +#define XEN_HVM_CPUID_APIC_ACCESS_VIRT (1u << 0) /* Virtualized
>> +APIC
>> registers */
>> +#define XEN_HVM_CPUID_X2APIC_VIRT      (1u << 1) /* Virtualized
>> x2APIC accesses */
>> I still wonder why expose the x2APIC? I guess you only want to know
>> whether
> the APICv is used and all platforms that support APICv must also
> support virtualized x2apic. What can guest do if he knows there is
> only virtuazliaed x2apic but no APICv?
> 
> You mean if it has virtualized x2APIC but not virtualized APIC
> registers (i.e. bit 4 in VMCS secondary controls is set but bit 8 is
> not)? I thought that term APICv encompasses both of these features.
> 
> Then it's up to the guest to decide whether to use APIC or pirqs:
> 
> * If the guest is in APIC mode then it probably should stick to pirqs
> since memory-mapped accesses to APIC will cause VMEXIT.
> * If it is in x2APIC mode then it makes sense for it to not use pirqs
> and go with APIC (x2APIC, really) since accesses will be handled 
> transparently.
> 

Does x2apic mode faster than pirq?

> I said in the cover letter I am not particularly happy about having
> two bits for this but I thought it is justified in this case.
> 
> -boris


Best regards,
Yang



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.