Re: [Xen-devel] [PATCH v2 0/4] Expose HW APIC virtualization support to HVM guests

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 03/11/2014 07:00 AM, David Vrabel wrote:
> On 11/03/14 03:53, Boris Ostrovsky wrote:
> > Version 2:
> > * Added ability to specify hypervisor CPUID leaves in config file (this requires
> >    new sysctl)
> > * Use 2 bits to indicate what is supported --- one for APIC memory access and 
> > the
> >    other for x2APIC. Still not sure whether virtual interrupt delivery should be
> >    exposed as well.
> >
> >
> >
> > HVM guests running on HW that supports HW APIC virtualization features
> > (APIC-register virtualization, virtual interrupt delivery, etc) may
> > want to use APIC instead of hvm_pirqs. Since we are not guaranteed to
> > have these features on VMX (for example, there is a boot option to
> > turn it off) and there is no such support on SVM we need to make the
> > guest aware that its APIC accesses may not be so bad.
> >
> > CPUID seems to be a good way to provide this info to the guest.
> It's seems a bit odd to use a Xen-specific (?) CPUID leaf to report that
> the guest should use a bare-metal feature -- that's the default
> behaviour of a HVM guest.
>
> I think it makes more sense to hint that the guest that a PV alternate
> is available and then omit this hint if using a virtualized APIC
> performs better.
That's what I originally thought too.

However, I don't think we can do this since we don't know guest's 
features. For example, we can have a guest that doesn't have APIC 
support (no CONFIG_X86_LOCAL_APIC). If we don't provide 
XENFEAT_hvm_pirqs (which is essentially what this CPUID bit is trying to 
suggest that the guest doesn't use) then I am not sure how well this 
will work out.
More generally, having one feature doesn't necessarily makes another 
feature disappear (and this is true in this case).
Thanks.
-boris

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