On 10/03/17 07:34, Jan Beulich wrote: >>>> On 09.03.17 at 18:29, <ta...@tklengyel.com> wrote: >> On Thu, Mar 9, 2017 at 9:56 AM, Jan Beulich <jbeul...@suse.com> wrote: >>> However - is this interface supposed to be usable by a guest on itself? >>> Arguably the same question would apply to some of the other sub-ops >>> too, but anyway. >> AFAIK the only op the guest would use on itself is >> HVMOP_altp2m_vcpu_enable_notify. > Which then means we should move all of them out of here, into a > suitable domctl. That will in turn reduce the scope of the bogus > interface versioning, which Andrew did point out, quite a bit.
The original usecase for altp2m was for an entirely in-guest agent, which is why they got in as hvmops to start with. I don't think it is wise to break that. I think there needs to be slightly finer grain control, identifying whether a domain may use altp2m, and whether it may configure altp2m permissions itself. The nature of altp2m means that using EPTP switching/etc necessarily can only happen from inside guest context, but whether you trust the domain to make adjustments to the permissions itself depends on your usecase and threat model. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
