On Sat, Aug 25, 2012 at 11:56:13AM +0100, Peter Maydell wrote:
> On 24 August 2012 04:14, 陳韋任 (Wei-Ren Chen) <che...@iis.sinica.edu.tw> wrote:
> > I would like to know if there is a function in QEMU which converts
> > a guest physical address into corresponding host virtual address.
>
> So the question is, what do you want to do with the host virtual
> address when you've got it? cpu_physical_memory_map() is really intended
> (as Blue says) for the case where you have a bit of host code that wants
> to write a chunk of data and doesn't want to do a sequence of
> cpu_physical_memory_read()/_write() calls. Instead you _map() the memory,
> write to it and then _unmap() it.
We want to let host MMU hardware to do what softmmu does. As a prototype
(x86 guest on x86_64 host), we want to do the following:
1. Get guest page table entries (GVA -> GPA).
2. Get corresponding HVA.
3. Then we use /dev/mem (with host cr3) to find out HPA.
4. We insert GVA -> HPA mapping into host page table through /dev/mem,
we already move QEMU above 4G to make way for the guest.
So we don't write data into the host virtual addr.
> Note that not all guest physical addresses have a meaningful host
> virtual address -- in particular memory mapped devices won't.
I guess in our case, we don't touch MMIO?
> > 1. I am running x86 guest on a x86_64 host and using the cod below
> > to get the host virtual address, I am not sure what value of len
> > should be.
>
> The length should be the length of the area of memory you want to
> either read or write from.
Actually I want to know where guest page are mapped to host virtual
address. The GPA we get from step 1 points to guest page table, and
we want to know its corresponding HVA.
> > static inline void *gpa2hva(target_phys_addr_t addr)
> > {
> > target_phys_addr_t len = 4;
> > return cpu_physical_memory_map(addr, &len, 0);
> > }
>
> If you try this on a memory mapped device address then the first
> time round it will give you back the address of a "bounce buffer",
> ie a bit of temporary RAM you can read/write and which unmap will
> then actually feed to the device's read/write functions. Since you
> never call unmap, this means that anybody else who tries to use
> cpu_physical_memory_map() on a device from now on will get back
> NULL (meaning resource exhaustion, because the bouncebuffer is in
> use).
You mean if I call cpu_physical_memory_map with a guest MMIO (physcial)
address, the first time it'll return the address of a buffer that I can write
data into. The second time it'll return NULL since I don't call
cpu_physical_memory_umap to flush the buffer. Do I understand you correctly?
Hmm, I think we don't not have such issue in our use case... What do you
think?
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
