Re: [Xen-devel] [PATCH v2 2/3] x86: explicitly disallow guest access to PPIN

[Jan Beulich <jbeulich@xxxxxxxx>]

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

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

Jan

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