[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 2/2] x86: explicitly disallow guest access to PPIN
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |