On Fri, 9 Jun 2023 at 15:32, Wu, Fei <fei2...@intel.com> wrote: > > On 6/8/2023 5:23 PM, Peter Maydell wrote: > > On Thu, 8 Jun 2023 at 08:44, Wu, Fei <fei2...@intel.com> wrote: > >> Is there any existing function to convert ram_addr_t to guest pa? > > > > Such a function would not be well-defined, because a block of RAM > > as specified by a ram_addr_t could be present at (aliased to) multiple > > guest physical addresses, or even currently not mapped to any guest > > physical address at all. And it could be present at different physical > > addresses for different vCPUs. > > > Thank you, Peter. What's the scenario of the last different physical > addresses for different vCPUs?
You can have a board with two different CPUs, where one of them has a RAM MemoryRegion that it puts at address A in its address space, and the other puts it at address B. This is most likely with 'heterogenous' configurations where you have an application processor A and a board-support processor B. (I don't know if we actually have any board models like that currently, but it's logically possible.) > For this specific case, I found I don't have to convert ram_addr_t to > gpa, the real requirement is converting ram_addr_t to hva, this one > seems well defined using qemu_map_ram_ptr(0, ram_addr) ? That does work for ram_addr_t to hva, but but note the warning on the comment above that function: you need to be in an RCU critical section to avoid some other thread coming along and de-allocating the RAM under your feet. (Also it's tempting to remove that support for passing in 0 as the RAMBlock, because every other use in the codebase seems to pass in a RAMBlock pointer.) thanks -- PMM