On Wed, Apr 10, 2024 at 8:56 PM Peter Xu <pet...@redhat.com> wrote: > > On Wed, Apr 10, 2024 at 06:44:38PM +0200, Edgar E. Iglesias wrote: > > On Tue, Feb 27, 2024 at 11:37 PM Vikram Garhwal <vikram.garh...@amd.com> > > 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> > > > > > > > > > Paolo, Peter, David, Phiippe, do you guys have any concerns with this patch? >
Thanks for your comments Peter, > This introduces a 3rd memory type afaict, neither direct nor !direct. > > What happens if someone does address_space_write() to it? I didn't see it > covered here.. You're right, that won't work, the memory needs to be mapped before it can be used. At minimum there should be some graceful failure, right now this will crash. > > OTOH, the cover letter didn't mention too much either on the big picture: > > https://lore.kernel.org/all/20240227223501.28475-1-vikram.garh...@amd.com/ > > I want to have a quick grasp on whether it's justified worthwhile we should > introduce this complexity to qemu memory core. > > Could I request a better cover letter when repost? It'll be great to > mention things like: I'll do that, but also answer inline in the meantime since we should perhaps change the approach. > > - what is grant mapping, why it needs to be used, when it can be used (is > it only relevant to vIOMMU=on)? Some more information on the high > level design using this type or MR would be great. https://github.com/xen-project/xen/blob/master/docs/misc/grant-tables.txt Xen VM's that use QEMU's VirtIO have a QEMU instance running in a separate VM. There's basically two mechanisms for QEMU's Virtio backends to access the guest's RAM. 1. Foreign mappings. This gives the VM running QEMU access to the entire RAM of the guest VM. 2. Grant mappings. This allows the guest to dynamically grant and remove access to pages as needed. So the VM running QEMU, cannot map guest RAM unless it's been instructed to do so by the guest. #2 is desirable because if QEMU gets compromised it has a smaller attack surface onto the guest. > > - why a 3rd memory type is required? Do we have other alternatives? Yes, there are alternatives. 1. It was suggested by Stefano to try to handle this in existing qemu/hw/xen/*. This would be less intrusive but perhaps also less explicit. Concerns about touching the Memory API have been raised before, so perhaps we should try this. I'm a little unsure how we would deal with unmapping when the guest removes our grants and we're using models that don't map but use address_space_read/write(). 2. Another approach could be to change the Xen grant-iommu in the Linux kernel to work with a grant vIOMMU in QEMU. Linux could explicitly ask QEMU's grant vIOMMU to map/unmap granted regions. This would have the benefit that we wouldn't need to allocate address-bit 63 for grants. A drawback is that it may be slower since we're going to need to bounce between guest/qemu a bit more. > So it's all based on my very limited understanding of reading this: > https://xenbits.xenproject.org/docs/4.3-testing/misc/grant-tables.txt > > If it's about cross-vm sharing memory, does it mean that in reality > there are RAMs allocated, but it's only about permission management? > In that case, is there any option we implement it with direct access > mode (however with some extra dynamic permissions applied on top using > some mechanism)? Yes, I think the grant vIOMMU approach would fall into this category. > > - perhaps sold old links would be great too so people can read about the > context when it's not obvious, without a need to copy-paste. https://wiki.xenproject.org/wiki/Virtio_On_Xen https://lwn.net/Articles/896938/ Cheers, Edgar
