RE: How to get host virtual address from guest physical address?

[ckim]

Hi Berto,

I used a function written in assembly and I called it in the guest code, not in 
qemu code.
The code was given by arm when we bought a latest processor IP and is marked 
confidential so I can't open it here.
But it uses "dc cvac Xt" command explained in armv8 architecture document. 
(data cache maintenance, cache clean using virtual address to the point of 
coherency).
You pass the virtual address to the instruction and the address(cache-line) is 
flushed(and the address is passed through x0 register of course). 
I don't know if there is any code on the net but found some reference code on 
"bare-metal boot code for armv8-A processors" section 5.3.
Also, if you use system bus supporting cache coherency (like CMN-600) you don't 
need this command to clean(flush to memory) the cache, the hardware will do it 
automatically when needed.
Hope that helps.
Thanks!

Chan Kim

> -----Original Message-----
> From: Berto Furth <bertofurth@sent.com>
> Sent: Monday, June 7, 2021 8:32 AM
> To: ckim <ckim@etri.re.kr>; Peter Maydell <peter.maydell@linaro.org>
> Cc: nerijus--- via <qemu-discuss@nongnu.org>
> Subject: Re: How to get host virtual address from guest physical address?
> 
> Hi Chan,
> 
> Thanks for documenting the information below. I note you mention "you need
> cache flush in the guest for this to work."
> 
> Do you know how to trigger this from the host side? That is, how do you
> make QEMU running on the host force the guest CPU to flush it's cache? Is
> there a QEMU function that can be called to do that?
> 
> Thanks very much Chan!
> 
> Berto.
> 
> On Mon, 31 May 2021, at 16:57, ckim@etri.re.kr wrote:
> > Hello, Peter Maydell,
> >
> > Thanks for the help.
> > I've seen that I can read the guest physical memory using
> > cpu_physical_memory_read function.
> > I followed the function, but couldn't find a nicely cut 'guest
> > physical to host virtual' address conversion function.
> > But I found I can do what I need (passing host virtual address to an
> > .so file) using memory_region_get_ram_ptr function (keeping the return
> > value and adding the offset from the start of known memory region to
> > it).
> >
> > This is for others why might get help from here :
> > I passed the guest physical address to a register write function, and
> > I can use the register value to access the guess memory like below.
> >         uint64_t membuf;
> >         cpu_physical_memory_read(guest_phys_addr, &membuf, 8);   // you
> > need cache flush in the guest for this to work.
> > I've also seen that I can keep the start address (host virtual address
> > seen from qemu) of a guest memory region like below after you do
> > memory_region_init_ram().
> >          ram_ptr = memory_region_get_ram_ptr(my_memory_region);
> >
> > Thank you!
> > Chan Kim
> >
> > > -----Original Message-----
> > > From: Peter Maydell <peter.maydell@linaro.org>
> > > Sent: Friday, May 28, 2021 11:37 PM
> > > To: Chan Kim <ckim@etri.re.kr>
> > > Cc: qemu-discuss <qemu-discuss@nongnu.org>
> > > Subject: Re: How to get host virtual address from guest physical
> address?
> > >
> > > On Fri, 28 May 2021 at 03:50, <ckim@etri.re.kr> wrote:
> > > > In my baremetal test on aarch64, I pass the guest physical address
> > > > of an
> > > array of a structure to the qemu peripheral code using peripherals
> > > register.
> > > >
> > > > I soon realized the adderss is from another world and to access
> > > > this
> > > address in qemu, I need the host virtual address.
> > > >
> > > > I tried reading the document (and will read more) but it shows the
> > > > load
> > > and store APIs, and not the address translation API.
> > > >
> > > > I need that address because I have to pass the “address” to a
> > > > function
> > > in a dynamic library ( a .so file). I don’t myself load or store
> > > using that address.
> > > >
> > > > What is the function for this “guest physical address to host
> > > > virtual
> > > address” translation?
> > >
> > > There is address_space_map(), but watch out for the caveats
> > > documented in its doc comment in memory.h.
> > >
> > > thanks
> > > -- PMM
> >
> >
> >
> >
> >
> >