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

Re: [Xen-devel] [PATCH 01/18] xen: reinstate previously unused XENMEM_remove_from_physmap hypercall



On 01/18/2012 11:06 AM, Ian Campbell wrote:
> On Wed, 2012-01-18 at 14:56 +0000, Daniel De Graaf wrote:
>> On 01/18/2012 05:36 AM, Ian Campbell wrote:
>>> On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
>>>> From: Alex Zeffertt <alex.zeffertt@xxxxxxxxxxxxx>
>>>>
>>>> This patch reinstates the XENMEM_remove_from_physmap hypercall
>>>> which was removed in 19041:ee62aaafff46 because it was not used.
>>>>
>>>> However, is now needed in order to support xenstored stub domains.
>>>> The xenstored stub domain is not priviliged like dom0 and so cannot
>>>> unilaterally map the xenbus page of other guests into it's address
>>>> space.  Therefore, before creating a domU the domain builder needs to
>>>> seed its grant table with a grant ref allowing the xenstored stub
>>>> domain to access the new domU's xenbus page.
>>>>
>>>> At present domU's do not start with their grant table mapped.
>>>> Instead it gets mapped when the guest requests a grant table from
>>>> the hypervisor.
>>>>
>>>> In order to seed the grant table, the domain builder first needs to
>>>> map it into dom0 address space.  But the hypercall to do this
>>>> requires a gpfn (guest pfn), which is an mfn for PV guest, but a pfn
>>>> for HVM guests.  Therfore, in order to seed the grant table of an
>>>> HVM guest, dom0 needs to *temporarily* map it into the guest's
>>>> "physical" address space.
>>>>
>>>> Hence the need to reinstate the XENMEM_remove_from_physmap hypercall.
>>>>
>>>> Signed-off-by: Alex Zeffertt <alex.zeffertt@xxxxxxxxxxxxx>
>>>> Signed-off-by: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
>>>
>>> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> (modulo Jan's comment
>>> about ordering in xlat.lst)
>>>
>>> BTW, since Alex and Diego have subsequently left Citrix you could take
>>> my Acked-by's in this series as Signed-of-by on behalf of Citrix. I've
>>> no idea if that's necessary though, I expect not.
>>>
>>> Ian.
>>>
>>
>> I'm not an expert in this area,
> 
> Me neither.
> 
>> but this is how I read it: the portion of
>> the path authored by Alex/Diego was already signed-off when they were posted,
>> so since the current patches are derived works from them the sign-off may
>> need to stay in order to allow me to sign off because I cannot claim 
>> copyright
>> on all of the content. Assuming Citrix actually owns the copyright on the
>> patches, your Ack may suffice to replace the sign-off for this purpose.
> 
> I don't think an Ack conveys the same meaning (WRT the DCO) as a
> Signed-off-by.
> 
>> I guess my real question here would be: should the sign-off from Alex and
>> Diego remain on these patches in addition to your Ack?
> 
> I would suggest you keep any signed-off-by they provided and augment it
> with my ack. 
> 
> I think I saw one or two which said "Originally-by" instead of
> "Signed-of-by", I guess those were either missing a Signed-off-by in the
> first place or have been heavily modified?
> 
> Ian.
> 

I originally replaced all the signed-off-by lines with originally-by and
missed one when converting back. When looking at the Linux version of the
DCO, it implies (lower down when talking about subsystem maintainers) that
if I make changes I need to drop the sign-off and claim clause (b) unless
the original author is around to sign-off on the changed patch, or if it is
trivial and I note this above my sign-off (not applicable here). This makes
me lean toward changing back to "Originally-by" or similar tags. I did keep
the From tags for those patches that I did not mostly rewrite, which I assume
will be recognized when importing patches.

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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