[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] QEMU commit 04bf2526ce breaks use of xen-mapcache
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] QEMU commit 04bf2526ce breaks use of xen-mapcache |
Date: |
Tue, 25 Jul 2017 15:42:03 -0400 (EDT) |
> > 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.
>