On 02/03/2016 09:37 AM, Andrew Cooper wrote:
On 03/02/16 14:30, Boris Ostrovsky wrote:
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.
PV guests currently have Xen's APIC leaked through despite not having
access to an APIC.
What do you mean by "leaked through"?
As with the XSAVE leakage, this has become an
defacto part of the ABI despite being architecturally wrong.
I expect PVOps Linux will blow up when run on older hardware which does
lack a real APIC, or one which is disabled in the BIOS.
I didn't mean to say that we set X86_FEATURE_APIC for PV guests, it's
only done for HVMlite.
I don't think there is hardware with VT/SVM that doesn't have APIC.
Besides, in Linux we have
config XEN_PVHVM
def_bool y
depends on XEN && PCI && X86_LOCAL_APIC
and HVMlite is considered PVHVM.
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
