On Mon, 10 Apr 2017, Stefano Stabellini wrote: > On Mon, 10 Apr 2017, hrg wrote: > > On Sun, Apr 9, 2017 at 11:55 PM, hrg <hrgstep...@gmail.com> wrote: > > > On Sun, Apr 9, 2017 at 11:52 PM, hrg <hrgstep...@gmail.com> wrote: > > >> Hi, > > >> > > >> In xen_map_cache_unlocked(), map to guest memory maybe in entry->next > > >> instead of first level entry (if map to rom other than guest memory > > >> comes first), while in xen_invalidate_map_cache(), when VM ballooned > > >> out memory, qemu did not invalidate cache entries in linked > > >> list(entry->next), so when VM balloon back in memory, gfns probably > > >> mapped to different mfns, thus if guest asks device to DMA to these > > >> GPA, qemu may DMA to stale MFNs. > > >> > > >> So I think in xen_invalidate_map_cache() linked lists should also be > > >> checked and invalidated. > > >> > > >> What’s your opinion? Is this a bug? Is my analyze correct? > > Yes, you are right. We need to go through the list for each element of > the array in xen_invalidate_map_cache. Can you come up with a patch?
I spoke too soon. In the regular case there should be no locked mappings when xen_invalidate_map_cache is called (see the DPRINTF warning at the beginning of the functions). Without locked mappings, there should never be more than one element in each list (see xen_map_cache_unlocked: entry->lock == true is a necessary condition to append a new entry to the list, otherwise it is just remapped). Can you confirm that what you are seeing are locked mappings when xen_invalidate_map_cache is called? To find out, enable the DPRINTK by turning it into a printf or by defininig MAPCACHE_DEBUG.