On 30 May 2018 at 01:24, Huaicheng Li <huaicheng@xxxxxxxxxxxxxxx> wrote: > Dear QEMU/KVM developers, > > I was trying to map a buffer in host QEMU process to a guest user space > application. I tried to achieve this > by allocating a buffer in the guest application first, then map this buffer > to QEMU process address space via > GVA -> GPA --> HVA (GPA to HVA is done via cpu_physical_memory_map). Last, > I wrote a host kernel driver to > walk QEMU process's page table and change corresponding page table entries > of HVA to the HPA of the target > buffer. This seems like the wrong way round to try to do this. As a rule of thumb, you'll have an easier life if you have things behave similarly to how they would in real hardware. So it'll be simpler if you start with the buffer in the host QEMU process, map this in to the guest's physical address space at some GPA, tell the guest kernel that that's the GPA to use, and have the guest kernel map that GPA into the guest userspace process's virtual address space. (Think of how you would map a framebuffer, for instance.) Changing the host page table entries for QEMU under its feet seems like it's never going to work reliably. (I think the specific problem you're running into is that guest memory is both mapped into the QEMU host process and also exposed to the guest VM. The former is controlled by the page tables for the QEMU host process, but the latter is a different set of page tables, which QEMU asks the kernel to configure, using KVM_SET_USER_MEMORY_REGION ioctls.) thanks -- PMM
