On Wed, 11 Oct 2023, Juergen Gross wrote: > On 10.10.23 02:17, Stefano Stabellini wrote: > > On Thu, 5 Oct 2023, Vikram Garhwal wrote: > > > From: Juergen Gross <jgr...@suse.com> > > > > > > In order to support mapping and unmapping guest memory dynamically to > > > and from qemu during address_space_[un]map() operations add the map() > > > and unmap() callbacks to MemoryRegionOps. > > > > > > Those will be used e.g. for Xen grant mappings when performing guest > > > I/Os. > > > > > > Signed-off-by: Juergen Gross <jgr...@suse.com> > > > Signed-off-by: Vikram Garhwal <vikram.garh...@amd.com> > > > > Can't we just use the existing Xen hooks in qemu_ram_ptr_length and > > xen_invalidate_map_cache_entry? Do we really need new ones? > > I tried your idea first and it didn't work out. > > The existing hooks are invoked not only when explicitly [un]mapping memory > regions, but in some other cases, too. Have a look for qemu_ram_ptr_length() > call in flatview_write_continue().
Hi Juergen, thanks for the explanation and sorry for my late reply. I missed your email when it came out. If that is the only problem, it seems to me that it could be solved. The call to qemu_ram_ptr_length() in flatview_write_continue is unlocked. It should be also distinguishable by address (the grants have the top bit set?) So from qemu_ram_ptr_length() we could call xen_map_grant_dyn only when locked. And in xen_map_grant_dyn we could also check that XEN_GRANT_ADDR_OFF is set before continuing. Do you see any other issues with it?
