lkml.org 
[lkml]   [2016]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy
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.

\
 
 \ /
  Last update: 2016-02-08 17:41    [W:0.096 / U:2.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site