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

[Boris Ostrovsky]

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