From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH v3 4/4] x86/hvm: Indicate avaliability of HW support of APIC virtualization to HVM guests Date: Mon, 17 Mar 2014 13:18:22 -0400 Message-ID: <53272E5E.4090906@oracle.com> References: <1394734109-3192-1-git-send-email-boris.ostrovsky@oracle.com> <1394734109-3192-5-git-send-email-boris.ostrovsky@oracle.com> <53230A62.3030602@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Zhang, Yang Z" Cc: "keir@xen.org" , "jbeulich@suse.com" , "stefano.stabellini@eu.citrix.com" , "Dong, Eddie" , "ian.jackson@eu.citrix.com" , "xen-devel@lists.xen.org" , "Nakajima, Jun" , "andrew.cooper3@citrix.com" , "ian.campbell@citrix.com" List-Id: xen-devel@lists.xenproject.org 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 > >