From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Subject: Re: [PATCH] x86/hvm: Provide list of emulated features in HVM CPUID leaf Date: Wed, 3 Feb 2016 16:05:47 +0100 Message-ID: <56B2174B.809@citrix.com> References: <1454455041-4647-1-git-send-email-boris.ostrovsky@oracle.com> <56B13A2F.3070209@citrix.com> <56B13C0E.5070905@oracle.com> <56B14733.4010905@citrix.com> <56B1BD9F.7050302@citrix.com> <56B20F02.7050702@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <56B20F02.7050702@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 , Andrew Cooper , jbeulich@suse.com, keir@xen.org Cc: david.vrabel@citrix.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org El 3/2/16 a les 15:30, Boris Ostrovsky ha escrit: > On 02/03/2016 03:43 AM, Roger Pau Monn=E9 wrote: >> El 3/2/16 a les 1:17, Andrew Cooper ha escrit: >>> On 02/02/2016 23:30, Boris Ostrovsky wrote: >>> >>>> 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 have to do the same for FreeBSD, I have to manually switch the APIC >> cpuid bit, > = > How? In config file's 'cpuid' option? Ah, no, I fix it inside FreeBSD. The FreeBSD kernel stores the result in a local variable, which i fixup when booting under HVMlite: cpu_feature |=3D CPUID_APIC; > = >> or else FreeBSD refuses to do SMP initialization. IMHO, what >> we currently do (no APIC cpuid bit) is correct, and when a local APIC is >> available the bit will indeed be enabled. >> >>> 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. >> This is what I aim to do long term, that is provide an emulated local >> APIC. The plan was to then also provide ACPI tables in order to notify >> the presence of the local and IO APICs (we are going to need both if we >> plan to do pci-passthrough of devices with PCI interrupts). Of course >> the APIC cpuid bit will also be enabled in this case. > = > One might say that in Linux we have APIC even for PV guests --- we > provide PV APIC ops. That's what I am using as justification for stating > that the HVMlite guest has APIC to force-set X86_FEATURE_APIC bit. So > this is somewhat similar to what Andrew is proposing in his option#2 > (quoted below for convenience): > = > 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. IMHO the APIC feature bit has a clear meaning: indicate the presence of a local APIC. A Xen PV APIC, or however we want to call it it's not a local APIC. I think OSes should fixup the CPUID feature bit if that's needed for them to work properly, but fixing it in Xen it's an error. Roger.