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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 01.11.2019 19:49, Andrew Cooper wrote:
> On 01/11/2019 14:29, Andrew Cooper wrote:
>> On 01/11/2019 14:00, Eslam Elnikety wrote:
>>> Thanks for this series, Jan.
>>>
>>> On 30.10.19 11:39, Jan Beulich wrote:
>>>> To fulfill the "protected" in its name, don't let the real hardware
>>>> values "shine through". Report a control register value expressing this.
>>>>
>>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>>> ---
>>>> TBD: Do we want to permit Dom0 access?
>>> It would be nice to give an administrator a way to get PPIN outside
>>> the context of an MCE when needed.
>> I suppose this is a reasonable request.  We should expose it to the
>> hardware domain.
> 
> Actually on further thoughts, I'm going to backtrack slightly.
> 
> It is reasonable to give to dom0, but it is not reasonable to provide it
> by emulating the MSR interface.  The problem is that dom0's result is
> sensitive to where it happens to be scheduled.
> 
> The only sane way of letting dom0 have access is via a hypercall which
> returns "no PPIN" or all sockets information in one go, irrespective of
> which socket the current vcpu happens to be executing on.
> 
> This leaves us back in the (substantially easier) position of not having
> to virtualise the MSR interface to begin with.

Right, hence my question whether to make this a new sysctl subop,
or whether to permit reading of this one MSR via XENPF_resource_op
(or yet some other mechanism). Personally I'd go the
XENPF_resource_op route.

Jan

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