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

[Borislav Petkov <bp@xxxxxxxxx>]

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.

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