Re: [Xen-devel] [PATCH 02/18] PVH xen: add XENMEM_add_to_physmap_range

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 31.05.13 at 11:38, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Fri, 2013-05-31 at 10:28 +0100, Jan Beulich wrote:
>> >>> On 25.05.13 at 03:25, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote:
>> >  static int xenmem_add_to_physmap_once(
>> >      struct domain *d,
>> > -    const struct xen_add_to_physmap *xatp)
>> > +    const struct xen_add_to_physmap *xatp,
>> > +    domid_t foreign_domid)
>> 
>> The patch could be a bit smaller afaict if you used the otherwise
>> unused here domain ID field in xatp for passing the domain ID you
>> care about here (I hinted at that in the last round already, where
>> I also asked Stefano why we have three domains here in the first
>> place).
> 
> This interface is already used on ARM, I don't think we want PVH to use
> a different variation of the same thing so I don't think it is right to
> put this on Mukesh.

I expressed this wrong if you understood it this way: I'm not
asking Mukesh to alter the interface - I had asked Stefano why
it was the way it is, and while I'm not happy with the situation,
I appreciate that changing it again is not a very good idea.

All I'm asking is, instead of introducing a new function parameter
here, to use an otherwise unused field of the xatp input
structure. This is based on the fact that the field is being
evaluated once directly in arch_memory_op(), and then no longer
needed.

That would also allow doing the setting just once before loops get
started, rather than having to pass the same value again on each
loop iteration.

The one caveat is that for the continuation creation of
XENMEM_add_to_physmap the field would need to be prevented
from getting written back to guest memory. But I consider it bad
practice anyway to copy back whole structures when only
selected fields (often just one) need updating, and hence
switching that operation to do a couple of individual field writes
would be nice regardless of that change, even if this adds two or
three lines of code.

Jan


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