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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2012-01-18 at 19:07 +0000, Daniel De Graaf wrote:
> 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.

The DCO itself isn't terribly specific about what to do with an existing
Signed-off-by if you modify the patch. Common practice appears to be to
include both the original and your own and to note what you have changed
unless you have done a wholesale rewrite in which case it is
"Based-on"/"Originally-by"/etc + your own S-o-b.

Ian.


> 



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