[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3] x86/altp2m: Added xc_altp2m_set_mem_access_multi()



On 10/06/2017 06:34 PM, Jan Beulich wrote:
>>>> On 05.10.17 at 17:42, <ppircalabu@xxxxxxxxxxxxxxx> wrote:
>> @@ -4451,6 +4453,7 @@ static int do_altp2m_op(
>>      case HVMOP_altp2m_destroy_p2m:
>>      case HVMOP_altp2m_switch_p2m:
>>      case HVMOP_altp2m_set_mem_access:
>> +    case HVMOP_altp2m_set_mem_access_multi:
> 
> Was it agreed that this, just like others (many wrongly, I think) is
> supposed to be invokable by the affected domain itself? Its non-
> altp2m counterpart is a DM_PRIV operation. If the one here is
> meant to be different, I think the commit message should say why.

In the absence of an answer from the designers of altp2m, we've chosen
to remain consistent with HVMOP_altp2m_set_mem_access - since that is
allowed to be invoked by the domain itself, this operation is also
allowed to do that.

Back in March, I've sent a DOMCTL version:

https://patchwork.kernel.org/patch/9633615/

and a HVMOP version (minus the compat part):

https://patchwork.kernel.org/patch/9612799/

It has been discussed, and an authoritative answer on the design of this
was sought out, but despite several kind reminders during this time, it
never came. At this point, the least modification to the initial design
appears to be to keep the new operation as a HVMOP. This is an important
optimization, and the waiting period for objections has surely been
reasonable.


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.