[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] x86/hvm: Provide list of emulated features in HVM CPUID leaf



On 02/03/2016 10:05 AM, Roger Pau Monné wrote:
El 3/2/16 a les 15:30, Boris Ostrovsky ha escrit:
On 02/03/2016 03:43 AM, Roger Pau Monné 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 |= 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.

I have a feeling that I confused you (and possibly Andrew) when I said "we provide PV APIC ops". By "we" I meant Linux, not Xen. I.e. arch/x86/xen/apic.c.

I do essentially the same thing in Linux as you do in FreeBSD by setting features bit with setup_force_cpu_cap(X86_FEATURE_APIC). http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg00145.html

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.