[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86/altp2m: Add a subop for obtaining the mem access of a page
> On Jul 2, 2018, at 7:34 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote: > >>>> On 29.06.18 at 18:39, <rcojocaru@xxxxxxxxxxxxxxx> wrote: >> On 06/29/2018 06:38 PM, Jan Beulich wrote: >>>>>> On 28.06.18 at 15:00, <apop@xxxxxxxxxxxxxxx> wrote: >>>> @@ -4666,6 +4667,23 @@ static int do_altp2m_op( >>>> } >>>> break; >>>> >>>> + case HVMOP_altp2m_get_mem_access: >>>> + if ( a.u.mem_access.pad ) >>>> + rc = -EINVAL; >>>> + else >>>> + { >>>> + xenmem_access_t access; >>>> + >>>> + rc = p2m_get_mem_access(d, _gfn(a.u.mem_access.gfn), &access, >>>> + a.u.mem_access.view); >>>> + if ( !rc ) >>>> + { >>>> + a.u.mem_access.hvmmem_access = access; >>>> + rc = __copy_to_guest(arg, &a, 1) ? -EFAULT : 0; >>> >>> __copy_field_to_guest()? Or wait, no, the function argument is still a >>> handle of void. >>> >>> And then - here we are again: Is it reasonable to permit a domain inquiring >>> for itself? >> >> A good question. Perhaps the following are decision factors: >> >> 1. It is already possible for a domain to set mem_access restrictions >> (via HVMOP_altp2m_set_mem_access) on itself. > > Which, as before, I consider a flaw. How many times do we have to go over this? Here is my recollection from the last time we had a discussion on this topic: * The original authors of this code probably thought having guests set their own memaccess would be a potential use case * The maintainers and main users of the code (Tamas and Razvan) think it’s a useful use case * The MM maintainer (me) and one of the x86 maintainers (Andy) think it’s a useful use case. (Correct me if I’ve misremembered anywhere.) Do we need to have a formal vote by the committers for you to accept that this should be a supported use case, and stop making objections any time someone wants to improve it? As long as not being able to call altp2m_set_mem_access means not being able to call altp2m_get_mem_access, this should be fine. -George _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |