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

Re: [Xen-devel] [PATCH v10] x86/altp2m: support for setting restrictions for an array of pages



On 03/30/2018 01:03 PM, George Dunlap wrote:
> On 03/30/2018 07:34 AM, Razvan Cojocaru wrote:
>> On 03/13/2018 07:44 PM, Wei Liu wrote:
>>> On Wed, Dec 13, 2017 at 04:22:20PM +0200, Petre Pircalabu wrote:
>>> [...]
>>> Tabs here.
>>>
>>> With this fixed, libxc bits:
>>>
>>> Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>
>>
>> We seem to have (again) arrived at an impasse with this patch.
>>
>> To summarize, the original designers of altp2m have not replied anything
>> to repeated requests for comments, we've briefly discussed the issue at
>> the Xen Developer Summit last year, and it was concluded that, since we
>> do have a valid use case, we carry on with whatever design most fit with
>> the single-page setting xc_altp2m_set_mem_access() (which is a HVMOP).
>>
>> Previously, Andrew has argued for the operation to be a HVMOP (in
>> keeping with the original design), while Jan has pointed out that since
>> this is only currently useful as a DOMCTL it would perhaps better be
>> implemented as one (which I personally also prefer, as it gets rid of
>> the very ugly compat code).
>>
>> In the process of negotiating this, concerns have been voiced about the
>> possibility of restricting altp2m operations from either dom0 or the
>> guest. This is addressed, IMHO, by Tamas' patches:
>>
>> https://patchwork.kernel.org/patch/9661873/
>>
>> The situation is now this: Wei's obviously acked it; Jan agrees to let
>> it in, pending acks from Andrew or George.
>>
>> We're happy to address any clear objections. But it would be a shame to
>> lose all this work we've all been doing for the better part of an year,
>> as I'm sure we all agree.
>>
>> Please let us know how to proceed.
> 
> Hey Razvan,
> 
> Not sure if you were on the list for the x86 community call, but this
> probably would have been a good item to put on the agenda to discuss
> last month -- the purpose of the call is to try to work through just
> these sorts of impasse.
> 
> In response to v8, I said:  "FWIW the approach looks good to me here.
> You mainly need an x86 maintainer's ack and a toolstack maintainer's
> ack (of which I am neither)."
> 
> I'm not a maintainer of `xen/arch/x86/hvm/hvm.c` -- that's Andy and Jan.
> 
> OTOH, altp2m is a p2m feature, so arguably it should be primarily my
> responsibility.
> 
> Anyway, I'll take a look at it today; if I can give a Reviewed-by, then
> maybe we can negotiate for it to go in with just that (with my committer
> hat on on), or for Andy to Ack it based mostly on my R-b.

Thank you for your help! And sorry if I've mistakenly named you here,
quite possibly I've misunderstood Jan's earlier reply.

Of course, please let us know if there's anything else we should do.

I wasn't on the list by email address for the last x86 community call,
though I did reply that I'm also partial to GoToMeeting on xen-devel -
the agenda seemed to me to had been already set, and to include larger
items than a single floating patch. With apologies for the off-topic,
we're also very interested in Intel's SPP.


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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