[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |