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

Re: [Xen-devel] [PATCH 1/4] move XENMEM_add_to_physmap handling framework to common code



>>> On 20.12.13 at 09:58, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Fri, 2013-12-20 at 07:48 +0000, Jan Beulich wrote:
>> >>> On 18.12.13 at 18:52, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
>> > On Wed, 2013-12-18 at 14:34 +0000, Jan Beulich wrote:
>> >> There's really nothing really architecture specific here; the
>> >> architecture specific handling is limited to
>> >> xenmem_add_to_physmap_one().
>> >> 
>> >> Note that ARM's restriction of XENMAPSPACE_gmfn_foreign only being
>> >> supported through XENMEM_add_to_physmap_range is being dropped as being
>> >> pointless.
>> > 
>> > It's not pointless, dropping this restriction turns a comprehensible
>> > EINVAL result into an incorrect ESRCH result. Which is incorrect because
>> > no domain was specified so how can it not exist.
>> 
>> How can there have been no domain specified for a
>> XENMAPSPACE_gmfn_foreign?
> 
> The arguments to XENMEM_add_to_physmap have no field which specifies a
> foreign domain. (this is one of the reasons we added the _range version
> with the field in the first place).
> 
> The domid parameter to add_to_physmap one is why hardcoded to
> DOMID_INVALID in all the add_to_physmap (!range) cases.
> 
>>  If the field was left uninitialized,
>> -ESRCH would be as valid as -EINVAL, and I don't think we
>> specify for any hypercall that between multiple applicable
>> error code a specific one would be preferred over others.
> 
> I think given the above -ESRCH is invalid, since there is no field to
> have been left uninitialised.

Oh, I finally understand. The thing that mainly confused me here
is the wording of the original comment: "Foreign mapping is only
supported by add_to_physmap_range". Whereas it should have
said "Foreign mapping is only possible through
add_to_physmap_range". I'll re-add that with the adjusted
comment.

Will that make the patch acceptable to you?

Jan


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


 


Rackspace

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