On 6/9/2023 11:51 PM, Peter Maydell wrote: > 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.) > Got it, thank you very much.
Fei. > thanks > -- PMM
