On 16/12/2019 12:37, Jan Beulich wrote: > On 16.12.2019 13:26, Andrew Cooper wrote: >> On 16/12/2019 11:47, Jan Beulich wrote: >>>> What >>>> you've done here is half-virtualise something we have no intention to >>>> ever virtualise for guests. >>>> >>>> Both of these should be blanket #GP faults. AMD should never be in the >>>> position of seeing amd_ppin clear but PPIN_CTL returning LOCKOUT, and >>>> while Intel does have model specific behaviour, whatever else might be >>>> behind that MSR obviously shouldn't be leaking though either. >>> In the interest of getting this ack-ed I might switch to the >>> blanket-#GP as you suggest, but I'm having trouble seeing why >>> giving back sane (and safe) values is wrong. This isn't meant >>> to indicate we might virtualize more of this. But why incur an >>> unnecessary #GP(0) in the guest when we can indicate the same >>> in a more "friendly" manner? >> Why add dead code to Xen? > Well, as you said yourself - at least the Intel part of this > isn't really dead. Of course we _expect_ guest kernels to cope > with #GP here, but there are many expectations of ours which > get violated ... (To give a concrete example in this very area > of code: A customer of ours noticed the x2APIC MSRs having > become inaccessible at some point. Clearly we didn't expect PV > guests to try to access them.)
This is a concrete example proves my point. We would never have been in this mess to begin with if Xen didn't have broken MSR handling. It was an information leak (at best) to offer PV guests even read-only access to the LAPIC. The rest is incorrect pv-ops in Linux, caused by the fact that things which shouldn't leak through, leaked through. This breakage is still present - a PV guest has no business accessing MSR_APIC_BASE, let alone depending on its contents. > >> It is unnecessary complexity in some already-complicated functions which >> are going to become far more complicated by the time we get Xen's MSR >> behaviour into a somewhat-reasonable state. > If this was really about "complexity", I'd fully agree. But > we talk about two instance of almost the same 5-line piece of > code. We are talking about complexity. I said "of the function", not of the individual case blocks. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
