Re: Plugin virtual-to-physical translation incorrect for some IO accesses

[Aaron Lindsay]

On Jul 06 23:10, Philippe Mathieu-Daudé wrote:
> +Peter/Paolo
> 
> On 7/6/21 10:47 PM, Aaron Lindsay wrote:
> > Hello,
> > 
> > I previously supplied a patch which modified the plugin interface such
> > that it will return physical addresses for IO regions [0]. However, I
> > have now found a case where the interface does not appear to correctly
> > return the full physical addresses.
> > 
> > In particular, when in qemu_plugin_hwaddr_phys_addr() for a particular
> > store to IO memory (haddr->is_io==true), I find that haddr->v.io.offset
> > is 0x0 and mrs->mr->addr is 0x3000, meaning 0x3000 is the returned
> > "physical address". However, I also find that
> > mrs->offset_within_address_space is 0x8000007000 (and also that
> > 0x8000007000 matches up with what an actual translation would be from
> > inspecting the page tables).
> > 
> > Would it be 'safe' to *always* begin using
> > mrs->offset_within_address_space as the returned physical address here
> > instead of `haddr->v.io.offset + mrs->mr->addr`, or is there a reason we
> > should not do that?

I realized this was perhaps not clear, so for clarification, I am
imagining the formula for calculating the address would be:
`mrs->offset_within_address_space + mrs->mr->addr`. Perhaps this was a
confusing example since the offset into the region is 0x0...

> 'safety' is not my area, but using mrs->offset_within_address_space
> sounds correct to me.

I'm not sure I was as clear as I could be here, either. My primary
concern was/is correctness of the address calculation, so perhaps 'safe'
was not the right way to put this.

-Aaron