[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH V3] xen/privcmd: improve performance of mapping of guest memory to dom0
>>> On 22.11.12 at 11:40, Mats Petersson <mats.petersson@xxxxxxxxxx> wrote: > On 22/11/12 08:42, Jan Beulich wrote: >> However, I wonder how a caller of the function would find out >> at which slot the error happened when not passing an error >> indicator array (after all, the function also doesn't undo what >> already succeeded in that case, i.e. the state is completely >> unknown to such a caller). > I agree, which is why the use of err_ptr is the preferred method - I > have talked to Ian Campbell, and he agrees that the "old" interface, > which doesn't use the err_ptr, should be removed eventually. However, we > first have to remove the callers of that method, and since it's a > different interface. > > However, current callers of the "non-errptr" interface already has this > problem regardless of these changes - there is no indication of how far > it got in the existing code either, it just exits with an error code if > one happens. Nothing has changed here except the code to fill in the > err_ptr moved from privcmd.c to mmu.c. If the caller detects a fail, it > will (or should, but I'm not aware of any code that doesn't at present) > call munmap the region, which undoes the entire mapping. > > We can't, at this point undo things, as we can't know how many previous > blocks of mapping has been done to this VMA. The owner of the memory > region may well have mappe several "bunches" of MFN's before the error, > which this function only handles one "bunch" at the time. So it's up to > the caller to deal with the error appropriately. > > In summary, I don't see a reason to change it. And the caller still > needs to call munmap to destroy the memory region it is mapping the MFNs > into, so it wouldn't be much help to "undo" things here. Okay, if things were that way already before, then I agree this is not a topic for this patch. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |