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

Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy

On 08/02/16 15:55, Borislav Petkov wrote:
> On Mon, Feb 08, 2016 at 10:39:43AM -0500, Boris Ostrovsky wrote:
>> It does. Very much IIRC, the problem was not caused by an access to MSR but
>> rather some sort of address not being available somewhere.
> See below.
>>> - microcode application on Xen: we've had this before. The hypervisor
>>> should do that (if it doesn't do so already).
>> it does.
> Good.
>>> So yes, that paravirt_enabled() thing should go away. Even more so if we
>>> have CPUID leaf 0x4... reserved for hypervisors.
>> I actually think this was the original proposal until we realized we had
>> paravirt_enabled(). So we can go back to checking CPUID 0x40000000.
>> We might also be able to test for (x86_hyper!=NULL) and have guests that do
>> microcode management prior to init_hypervisor() rely on hypervisors ignoring
>> MSR accesses (as they do today).
> Right, so the early loader can't do that as on 32-bit it runs even
> before paging has been enabled. So I *think* the thing with CPUID would
> be best. What does the xen hypervisor return in regs when I do CPUID(4)?
> I.e., how do I reliably detect it in the guest?
> I can whip up a quick patch and get rid of paravirt_enabled() while at
> it...

For compatibility with other virtualisation specs, Xen's cpuid leaves
shift depending on configuration.

Spec at

Basically, they are either at 0x40000000, or 0x40000100 if viridian or
vmware compatibility has been enabled.


Xen-devel mailing list



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