From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH] x86/hvm: Provide list of emulated features in HVM CPUID leaf Date: Wed, 3 Feb 2016 09:30:26 -0500 Message-ID: <56B20F02.7050702@oracle.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> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <56B1BD9F.7050302@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: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , 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 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? > 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. -boris