qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Incorrect memory region address with large 64-bit PCI B


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] Incorrect memory region address with large 64-bit PCI BARs
Date: Mon, 13 Mar 2017 14:02:40 +0200

On Sun, Mar 12, 2017 at 11:16:44AM +0000, Mark Cave-Ayland wrote:
> On 12/03/17 03:56, Michael S. Tsirkin wrote:
> 
> > After looking at it some more, I think the issue is merely with how info
> > mtree presents information, which confuses instead of helping when
> > overlap triggers. Specifically
> >     000001ff00000000-000001ffffffffff (prio 0, i/o): pci-mmio
> >     ...
> >       000001fe04040000-000001fe04043fff (prio 1, i/o): virtio-pci
> > 
> > really means that virtio-pci is not visible at all, this
> > happens because it starts at offset ffffffff04040000 which is
> > outside the parent.
> > 
> > I think that the cleanest fix is probably to show 128 bit addresses,
> > then user will see the real addresses:
> > 
> >     000001ff00000000-000001ffffffffff (prio 0, i/o): pci-mmio
> >     ...
> >       1000001fe04040000-1000001fe04043fff (prio 1, i/o): virtio-pci
> >     
> > and now it's clear what is going on: virtio-pci is outside pci-mmio.
> > 
> > This would have pointed Mark in the right direction earlier.
> > 
> > Thoughts? Patch?
> 
> Presumably if someone tried to do this on real hardware, the BAR address
> would lie outside of the pci-mmio region and effectively isn't mapped?
> 
> If this is the case I'd be happy with a simple qemu_log() showing the
> full 64-bit address and region name explaining that it couldn't be
> mapped underneath its parent because it was outside its parent region,
> and skip the mapping.
> 
> 
> ATB,
> 
> Mark.

I think that's what happens anyway. The bug is merely the desplay in info mtree
which uses 64 bit math.

-- 
MST



reply via email to

[Prev in Thread] Current Thread [Next in Thread]