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

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 03/16/2014 08:40 PM, Zhang, Yang Z wrote:
> 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?
In terms of the number of VMEXITs -- yes, it results in far fewer of 
them. For example, eoi_pirq() may end up in a hypercall, something that 
will be avoided with virtualized x2APIC.

-boris

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