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