qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Cc: qemu-devel <qemu-devel@nongnu.org>, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] Incorrect memory region address with large 64-bit PCI BARs
Date: Sun, 12 Mar 2017 03:46:57 +0200	[thread overview]
Message-ID: <20170312025259-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <90ac2aef-5fff-ada6-d847-cd3ce20b967a@ilande.co.uk>

On Sat, Mar 11, 2017 at 10:37:09AM +0000, Mark Cave-Ayland wrote:
> I've been looking at an issue with virtio BARs being mapped incorrectly
> on qemu-system-sparc64, and as part of this investigation found that
> some 64-bit PCI BAR memory regions don't appear correctly in "info mtree".
> 
> The easiest way to see this is to launch QEMU as below and then check
> the output of "info mtree":
> 
> ./qemu-system-sparc64 -device virtio-net-pci
> 
> The interesting part is this:
> 
> > address-space: memory
> >   0000000000000000-ffffffffffffffff (prio 0, i/o): system
> >     0000000000000000-0000000007ffffff (prio 0, ram): sun4u.ram
> >     000001fe00000000-000001fe0000ffff (prio 0, i/o): apb-config
> >     000001fe01000000-000001fe01ffffff (prio 0, i/o): apb-pci-config
> >     000001fe02000000-000001fe0200ffff (prio 0, i/o): alias apb-pci ioport @io 0000000000000000-000000000000ffff
> >     000001ff00000000-000001ffffffffff (prio 0, i/o): pci-mmio
> >       000001ff00000000-000001ff000fffff (prio 1, i/o): alias pci_bridge_mem @pci_bridge_pci 0000000000000000-00000000000fffff
> >       000001ff00000000-000001ff000fffff (prio 1, i/o): alias pci_bridge_pref_mem @pci_bridge_pci 0000000000000000-00000000000fffff
> >       000001ff00000000-000001ff000fffff (prio 1, i/o): alias pci_bridge_mem @pci_bridge_pci 0000000000000000-00000000000fffff
> >       000001ff00000000-000001ff000fffff (prio 1, i/o): alias pci_bridge_pref_mem @pci_bridge_pci 0000000000000000-00000000000fffff
> >       000001ff000a0000-000001ff000affff (prio 2, i/o): alias vga.chain4 @vga.vram 0000000000000000-000000000000ffff
> >       000001ff000a0000-000001ff000bffff (prio 1, i/o): vga-lowmem
> >       000001ff01000000-000001ff01ffffff (prio 1, ram): vga.vram
> >       000001ff02000000-000001ff02000fff (prio 1, i/o): vga.mmio
> >         000001ff02000400-000001ff0200041f (prio 0, i/o): vga ioports remapped
> >         000001ff02000500-000001ff02000515 (prio 0, i/o): bochs dispi interface
> >         000001ff02000600-000001ff02000607 (prio 0, i/o): qemu extended regs
> >       000001ff02010000-000001ff0201ffff (prio 1, rom): vga.rom
> >       000001ff03000000-000001ff03ffffff (prio 1, i/o): alias bar0 @io 0000000000000000-0000000000ffffff
> >       000001ff04000000-000001ff0403ffff (prio 1, rom): ne2000.rom
> >       000001ff04080000-000001ff040bffff (prio 1, rom): virtio-net-pci.rom
> >       000001fe04040000-000001fe04043fff (prio 1, i/o): virtio-pci
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> Here virtio-pci is mapped to address 0x1fe04040000 even though its
> parent pci-mmio memory region is at 0x1ff00000000.
> 
> >         000001fe04040000-000001fe04040fff (prio 0, i/o): virtio-pci-common
> >         000001fe04041000-000001fe04041fff (prio 0, i/o): virtio-pci-isr
> >         000001fe04042000-000001fe04042fff (prio 0, i/o): virtio-pci-device
> >         000001fe04043000-000001fe04043fff (prio 0, i/o): virtio-pci-notify
> >     000001fff0000000-000001fff03fffff (prio 0, rom): sun4u.prom
> 
> The bug in the current OpenBIOS is that 64-bit BARs are incorrectly
> identified, and so the BAR MSB register is set to 0xffffffff to detect
> the size as per a standard 32-bit BAR. At this point OpenBIOS detects
> something is wrong and aborts, leaving the 64-bit BAR set to 0xffffffff
> 0x04040000.
> 
> This is accurately reflected in the virtio-pci memory region itself, i.e.
> 
> > memory-region: virtio-pci
> >   ffffffff04040000-ffffffff04043fff (prio 1, i/o): virtio-pci
> >     ffffffff04040000-ffffffff04040fff (prio 0, i/o): virtio-pci-common
> >     ffffffff04041000-ffffffff04041fff (prio 0, i/o): virtio-pci-isr
> >     ffffffff04042000-ffffffff04042fff (prio 0, i/o): virtio-pci-device
> >     ffffffff04043000-ffffffff04043fff (prio 0, i/o): virtio-pci-notify
> 
> But as you can see above the overall effect is that the virtio-pci
> device ends up somehow being mapped outside (and indeed, before the
> start of) its parent memory region.

And specifically we have:

000001ff00000000 + ffffffff04040000 = 000001fe04043000

which seems to be where this is coming from.

It does have to indicate some kind of modelling problem:
since it looks like on sparc BAR is an offset within
PCI MMIO region, I would expect an offset value bigger than 
the region size not to be visible.

Specifically documentation states:

- all direct subregions of the root region are matched against the address, in
  descending priority order
  - if the address lies outside the region offset/size, the subregion is
    discarded



> Fixing the bug in OpenBIOS itself is fairly trivial, although it took
> much longer to diagnose due to the misleading output above. It does seem
> that something isn't quite right with the handling of the large 64-bit
> BARs in this case, so Michael suggested I email the list for further
> comment.
> 
> 
> ATB,
> 
> Mark.

  reply	other threads:[~2017-03-12  1:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-11 10:37 [Qemu-devel] Incorrect memory region address with large 64-bit PCI BARs Mark Cave-Ayland
2017-03-12  1:46 ` Michael S. Tsirkin [this message]
2017-03-12  3:56   ` Michael S. Tsirkin
2017-03-12 11:16     ` Mark Cave-Ayland
2017-03-13 12:02       ` Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170312025259-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=mark.cave-ayland@ilande.co.uk \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).