[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] QEMU commit 04bf2526ce breaks use of xen-mapcache
> > Thanks---however, after re-reading xen-mapcache.c, dma needs to be false > > for unlocked mappings. > > If there is a DMA operation already in progress, it means that we'll > already have a locked mapping for it. Yes, I only wanted to say that qemu_ram_ptr_length should pass dma=false when called by address_space_*_continue (i.e. with locked=false). Paolo > When address_space_write_continue is called, which in turn would call > qemu_map_ram_ptr, or qemu_ram_ptr_length(unlocked), if the start and > size of the requested mapping matches the one of the previously created > locked mapping, then a pointer to the locked mapping will be returned. > > If they don't match, a new unlocked mapping will be created and a > pointer to it will be returned. (Arguably the algorithm could be > improved so that a new mapping is not created if the address and size > are contained within the locked mapping. This is a missing optimization > today.) > > It doesn't matter if a new unlocked mapping is created, or if the locked > mapping is returned, because the pointer returned by > qemu_ram_ptr_length(unlocked) is only used to do the memcpy, and never > again. So I don't think this is a problem. > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |