From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] x86/hvm: Provide list of emulated features in HVM CPUID leaf Date: Wed, 3 Feb 2016 00:17:55 +0000 Message-ID: <56B14733.4010905@citrix.com> References: <1454455041-4647-1-git-send-email-boris.ostrovsky@oracle.com> <56B13A2F.3070209@citrix.com> <56B13C0E.5070905@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <56B13C0E.5070905@oracle.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: Boris Ostrovsky , jbeulich@suse.com, keir@xen.org Cc: roger.pau@citrix.com, david.vrabel@citrix.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 02/02/2016 23:30, Boris Ostrovsky wrote: > On 02/02/2016 06:22 PM, Andrew Cooper wrote: >> On 02/02/2016 23:17, Boris Ostrovsky wrote: >>> Hypervisor may choose which features to emulate for HVMlite guests. >>> Guest will query the HVM CPUID leaf to find out what is available. >>> >>> Signed-off-by: Boris Ostrovsky >> Roger also submitted a patch to do this. However, it is not >> appropriate, so was dropped. >> >> An HVMLite domain should assume there are no emulated devices. The very >> old legacy devices will never be implemented, and any others we care >> about possibly implementing in the future have APCI-based ways of >> indicating support. > > OK, so I wasn't the first one to come up with this ;-) > > I think for now I mostly care about APIC and for that I can use HW > CPUID bit (which I believe is cleared for HVMlite guests). The APIC bit in cpuid is magic and specified as a fast forward of the APICBASE_MSR enable bit. Therefore, the correct architectural behaviour is for this bit to be clear if the local APIC is disabled, or indeed not implemented. With my maintainers hat on, I will reject any attempt to introduce non-architectural behaviour; at the moment I am dealing with the stupidity that is the PV XSAVE interface, where broken bugfix piled on top of broken bugfix has resulted in a situation where many Linux PV guests crash if provided with architecturally correct behaviour of the OSXSAVE cpuid bit (yet another magic one). > The trouble is that I need to present Linux as having APIC (boot code > doesn't feel good if !cpu_has_apic) so I'll need to keep no-APIC > emulation private to Xen-related code. Which is doable. I see two choices. 1) Require that Linux DMLite guests require a Local APIC, and we allow that to be a configured option. Exposing APIC definitely makes sense longer term, because APICV hardware acceleration outperforms the hypercall-based method. 2) Find a way of telling the Linux boot path "trust me - here is an APIC driver - dont go looking under the hood". Possibly by registering a cpuid pvop which re-inserts the APIC bit, although this is liable to cause the boot code to then inspect the APICBASE_MSR, which will cause it to blow up slightly later on. ~Andrew