From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH v2 0/4] Expose HW APIC virtualization support to HVM guests Date: Tue, 11 Mar 2014 10:14:07 -0400 Message-ID: <531F1A2F.3070907@oracle.com> References: <1394510043-3159-1-git-send-email-boris.ostrovsky@oracle.com> <531EECE2.2040709@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <531EECE2.2040709@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: David Vrabel Cc: keir@xen.org, jun.nakajima@intel.com, stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com, eddie.dong@intel.com, xen-devel@lists.xen.org, jbeulich@suse.com, ian.campbell@citrix.com List-Id: xen-devel@lists.xenproject.org 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