[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 02/06/2016 05:04 PM, Borislav Petkov wrote:
On Sat, Feb 06, 2016 at 12:05:32PM -0800, Andy Lutomirski wrote:
int __init microcode_init(void)
         if (paravirt_enabled() || dis_ucode_ldr)
                 return -EINVAL;

This is also asking "are we the natively booted kernel?"  This is
plausibly useful for real.  (Borislav, is this actually necessary?)
There was some breakage on 32-bit pvops with that.

Seems to me there should be a function is_native_root_kernel() or
similar.  Obviously it could have false positives and code will have
to deal with that.  (This also could be entirely wrong.  What code is
responsible for CPU microcode updates on Xen?  For all I know, dom0 is
*supposed* to apply microcode updates, in which case that check really
should be deleted.
So there are two aspects:

- the guest loading the microcode driver. Xen should behave like
qemu+kvm does: emulate the MSR accesses the microcode loader does.

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.

- microcode application on Xen: we've had this before. The hypervisor
should do that (if it doesn't do so already).

it does.

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).


Xen-devel mailing list



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