Re: [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy
From: Borislav Petkov
Date: Mon Feb 08 2016 - 10:55:27 EST
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...
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.