[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] x86/msr: Fix handling of MSR_AMD_PATCHLEVEL/MSR_IA32_UCODE_REV



>>> On 01.04.19 at 16:01, <andrew.cooper3@xxxxxxxxxx> wrote:
> There are a number of bugs.  There are no read/write hooks on the HVM side, so
> guest accesses fall into the "read/write-discard" defaults, which bypass the
> correct faulting behaviour and the Intel special case.
> 
> For the PV side, writes are discarded (again, bypassing proper faulting),
> except for a pinned dom0, which is permitted to actually write the values
> other than 0.  This is pointless with read hook implementing the Intel special
> case.
> 
> However, implementing the Intel special case is pointless.  First of all, OS
> software can't guarentee to read back 0 in the first place, because a) this
> behaviour isn't guarenteed in the SDM, and b) there are SMM handlers which use
> the CPUID instruction.

I didn't think there was ever an intention to be able to (reliably)
hand back zero on a subsequent read.

>  Secondly, when a guest executes CPUID, this doesn't
> typically result in Xen executing a CPUID instruction in practice.

Wait - this is true for DomU, but used to be false for (PV) Dom0,
until you've switched over from pv_cpuid() to guest_cpuid(). I
would assume it was an unintended side effect to, this way,
eliminate the actual CPUID access from the special ucode rev
reading sequence Dom0 may perform.

As to DomU, I severely doubt it's a good idea to expose the
ucode revision to a guest, at least as long as the guest can be
migrated. But yes, we can leave avoiding to do so to the guest
itself: We won't mislead it any worse by handing it the real
revision than we would by handing it some synthetized one (e.g.
constant 0).

> With the dom0 special case removed, there are now no writes to this MSR other
> than Xen's microcode loading facilities, which means that the value held in
> the MSR will be properly up-to-date.  Forward it directly, without jumping
> through any hoops.

I agree with this, so
Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> ---
> CC: Jan Beulich <JBeulich@xxxxxxxx>
> CC: Wei Liu <wei.liu2@xxxxxxxxxx>
> CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> CC: David Wang <davidwang@xxxxxxxxxxx>
> 
> This patch texturally (but not functionally) interacts with "xen/sched: Remove
> d->is_pinned" but rebasing either is easy.  It would also be best applied with
> Sergey's "x86/microcode: always collect_cpu_info() during boot".

Well, "best" is probably an understatement, as you'd supply
stale data if we never came through that code. So I'd call it a
strict prereq.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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