Re: [PATCH v14 08/10] Adding info [tb-list|tb] commands to HMP (WIP)

[Wu, Fei]

On 6/9/2023 11:51 PM, Peter Maydell wrote:
> On Fri, 9 Jun 2023 at 15:32, Wu, Fei <fei2.wu@intel.com> wrote:
>>
>> On 6/8/2023 5:23 PM, Peter Maydell wrote:
>>> On Thu, 8 Jun 2023 at 08:44, Wu, Fei <fei2.wu@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