From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>,
"Roger Pau Monné" <roger.pau@citrix.com>,
jbeulich@suse.com, keir@xen.org
Cc: david.vrabel@citrix.com, xen-devel@lists.xen.org
Subject: Re: [PATCH] x86/hvm: Provide list of emulated features in HVM CPUID leaf
Date: Wed, 3 Feb 2016 09:46:30 -0500 [thread overview]
Message-ID: <56B212C6.5070606@oracle.com> (raw)
In-Reply-To: <56B210A6.5030109@citrix.com>
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
next prev parent reply other threads:[~2016-02-03 14:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-02 23:17 [PATCH] x86/hvm: Provide list of emulated features in HVM CPUID leaf Boris Ostrovsky
2016-02-02 23:22 ` Andrew Cooper
2016-02-02 23:30 ` Boris Ostrovsky
2016-02-03 0:17 ` Andrew Cooper
2016-02-03 8:43 ` Roger Pau Monné
2016-02-03 14:30 ` Boris Ostrovsky
2016-02-03 14:37 ` Andrew Cooper
2016-02-03 14:46 ` Boris Ostrovsky [this message]
2016-02-03 15:05 ` Roger Pau Monné
2016-02-03 15:27 ` Boris Ostrovsky
2016-02-03 3:51 ` Tian, Kevin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56B212C6.5070606@oracle.com \
--to=boris.ostrovsky@oracle.com \
--cc=andrew.cooper3@citrix.com \
--cc=david.vrabel@citrix.com \
--cc=jbeulich@suse.com \
--cc=keir@xen.org \
--cc=roger.pau@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.