Re: Can't boot as Xen dom0 due to commit fe055896

From: Boris Ostrovsky
Date: Thu Dec 15 2016 - 23:34:54 EST




On 12/15/2016 06:04 PM, Borislav Petkov wrote:
On Thu, Dec 15, 2016 at 05:56:44PM -0500, Boris Ostrovsky wrote:
With CONFIG_PARAVIRT (which I suspect you don't have on) cpuid() is a
call via a pointer, you can see it, for example, if you disassemble
load_ucode_amd_bsp(). And we don't have paging on yet when we call
load_ucode_amd_bsp (at least in 32-bit mode).

That's a good catch, you can send me that one as a proper patch with a
commit message and so on...

OK, I'll send something tomorrow.


Since this happens during AP bringup PV cpuid is available and can be
checked to see whether we are a guest.

What exactly do I need to check there? CPUID(4), leaf which, reg which?
How do I identify a xen hypervisor properly?

You can use xen_cpuid_base(), for example. It will prevent microcode loading for all types of Xen guests (PV, HVM and, in the near future, PVH). Which I think is fine. This will require adding a #define for xen_cpu_base() for !CONFIG_XEN.

Alternatively, if we think that no guest should ever load microcode, we could check for 'x86_hyper != 0'. This will be cleaner but I can't speak for KVM/VMware/Hyper-V.

Neither of these solutions will work for load_ucode_bsp() because xen_cpuid_base() calls cpuid() (and so we are back to the above bug) and x86_hyper is not set yet. This is OK for Xen as PV guests never call load_ucode_bsp and HVM/PVH guests should be able to handle MSR accesses.


But I think it may be worthwhile trying to understand why we are
dying, it hasn't happened until now.

What for? We don't want to run the microcode loader on xen at all.

True. But I don't think it's clear that the problem we are seeing is Xen-specific.

-boris