From: David Gibson <david@gibson.dropbear.id.au>
To: "Hervé Poussineau" <hpoussin@reactos.org>
Cc: qemu-devel@nongnu.org, Alexander Graf <agraf@suse.de>,
qemu-ppc@nongnu.org, Thomas Huth <thuth@redhat.com>,
Giancarlo Teodori <gteodori@gmail.com>
Subject: Re: [Qemu-devel] [PATCH 2/6] vga: increase priority of 0xa0000 memory region
Date: Wed, 4 Jan 2017 11:05:28 +1100 [thread overview]
Message-ID: <20170104000528.GV12761@umbus.fritz.box> (raw)
In-Reply-To: <38325f34-9511-bb4e-2224-097bd9a88d7e@reactos.org>
[-- Attachment #1: Type: text/plain, Size: 4374 bytes --]
On Tue, Jan 03, 2017 at 11:37:20PM +0100, Hervé Poussineau wrote:
> Le 03/01/2017 à 00:02, David Gibson a écrit :
> > On Thu, Dec 29, 2016 at 11:12:12PM +0100, Hervé Poussineau wrote:
> > > VGA device registers vram as BAR 0. If this BAR is activated as a very low address which
> > > crosses 0xa0000-0xbffff, low memory region is not accessible anymore.
> > >
> > > This fixes display on PReP machine if we enable PCI mapping at
> > > address 0.
> >
> > This commit message needs more information. What exactly is the VGA
> > BAR colliding with? Why does the other thing have higher priority?
> > Why is it safe for the VGA BAR to override the other thing? Why is
> > this safe on all platforms?
>
> VGA has (basically) two memory regions:
> - the legacy one, from 0xa0000 to 0xbffff
> - a memory region describing the whole VRAM, configurable with PCI BAR 0.
Yes, that I know. Note that both the fixed 0xa0000 and the BAR value
are offsets with *PCI* memory space, which may not be the same as
addresses in system memory space. PCI memory space is identity mapped
into system address space on x86, IIRC, but it's not on spapr. AFAICT
it's not identity mapped on PReP either (see raven_pcihost_initfn()).
So the VGA legacy window will actually be at 0xc00a0000 and BAR0 at
(0xc0000000 + BAR value) in the _system_ address space if I'm reading
the PReP PCI bridge code correctly.
> In QEMU, mapping PCI at address 0 is not permitted (MachineClass->pci_allow_0_address is false by default),
I believe this is because of the identity map of PCI memory space on
x86 (well, PC, strictly speaking). Because that's not the case on
PReP, it should probably set allow_0_address = true.
> except on arm/virt and ppc/spapr. So, this is usually not a problem as all PCI BARs (including video PCI BAR 0) are not mapped at
> address 0, and so both memory regions can't collide.
>
> When trying Linux on ppc/40p (introduced later in this patchset), I saw that Linux assigns
> PCI BAR addresses in the order of PCI devices detection, and VGA PCI BAR 0 ends up at address 0.
Hmm. You're saying that Linux is assigning BAR 0 so that it collides
with the legacy memory region? That sounds like a Linux bug.
Or.. does Linux always assign BARs on PReP, or only if the firmware
doesn't? Maybe the guest firmware needs to assign the BARs properly
to avoid this collision.
> However, Linux assumes that 0xa0000-0xbffff is still available to drive the VGA card in text mode.
> Without changing the region priority, VGA output is garbled (as writes directly go to VGA memory).
> When increasing the region priority, VGA output is restored (as writes go to legacy address space).
Right. But by increasing the priority, you're effectively making a
hole in BAR0. That sounds like it will cause chaos if after boot you
load a "real" VGA driver which tries to use the full video RAM through
BAR0 instead of via the legacy area.
> arm/virt by default doesn't have a PCI VGA card.
> ppc/spapr may probably have the same problem as ppc/40p. However, as VGA PCI BAR 0 and VGA legacy space
> both have a priority of 1, it may probably have a problem. I only need to convince Linux to use address 0 for VGA PCI BAR.
>
> Hervé
>
> >
> > > Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
> > > ---
> > > hw/display/vga.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/hw/display/vga.c b/hw/display/vga.c
> > > index 2a88b3c..c573f35 100644
> > > --- a/hw/display/vga.c
> > > +++ b/hw/display/vga.c
> > > @@ -2265,7 +2265,7 @@ void vga_init(VGACommonState *s, Object *obj, MemoryRegion *address_space,
> > > memory_region_add_subregion_overlap(address_space,
> > > 0x000a0000,
> > > vga_io_memory,
> > > - 1);
> > > + 2);
> > > memory_region_set_coalescing(vga_io_memory);
> > > if (init_vga_ports) {
> > > portio_list_init(&s->vga_port_list, obj, vga_ports, s, "vga");
> >
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2017-01-04 0:21 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-29 22:12 [Qemu-devel] [PATCH 0/6] ppc: add a IBM 40p machine (RS/6000, PReP) Hervé Poussineau
2016-12-29 22:12 ` [Qemu-devel] [PATCH 1/6] pci: add pci_vga_type(), giving the device name of the chosen VGA device Hervé Poussineau
2017-01-02 23:01 ` David Gibson
2017-01-10 3:14 ` Michael S. Tsirkin
2017-01-10 21:00 ` Hervé Poussineau
2016-12-29 22:12 ` [Qemu-devel] [PATCH 2/6] vga: increase priority of 0xa0000 memory region Hervé Poussineau
2017-01-02 23:02 ` David Gibson
2017-01-03 22:37 ` Hervé Poussineau
2017-01-04 0:05 ` David Gibson [this message]
2016-12-29 22:12 ` [Qemu-devel] [PATCH 3/6] prep: do not use global variable to access nvram Hervé Poussineau
2017-01-03 3:51 ` David Gibson
2016-12-29 22:12 ` [Qemu-devel] [PATCH 4/6] prep: QOM'ify System I/O Hervé Poussineau
2017-01-02 23:03 ` David Gibson
2017-01-03 22:51 ` Hervé Poussineau
2017-01-03 23:39 ` David Gibson
2017-01-03 4:45 ` David Gibson
2017-01-04 21:17 ` Hervé Poussineau
2017-01-05 0:41 ` David Gibson
2017-01-05 20:57 ` Hervé Poussineau
2016-12-29 22:12 ` [Qemu-devel] [PATCH 5/6] prep: add IBM RS/6000 7020 (40p) memory controller Hervé Poussineau
2017-01-03 4:57 ` David Gibson
2017-01-03 22:55 ` Hervé Poussineau
2017-01-03 23:39 ` David Gibson
2016-12-29 22:12 ` [Qemu-devel] [PATCH 6/6] prep: add IBM RS/6000 7020 (40p) machine emulation Hervé Poussineau
2017-01-03 5:02 ` David Gibson
2017-05-08 20:49 ` Eduardo Habkost
2017-05-08 21:32 ` Hervé Poussineau
2017-01-11 16:58 ` [Qemu-devel] [PATCH 0/6] ppc: add a IBM 40p machine (RS/6000, PReP) Artyom Tarasenko
2017-01-11 23:18 ` David Gibson
2017-01-12 12:57 ` Hervé Poussineau
2017-01-12 13:46 ` Artyom Tarasenko
2017-01-13 12:23 ` Mark Cave-Ayland
2017-01-13 13:26 ` Thomas Huth
2017-01-13 13:30 ` Artyom Tarasenko
2017-01-14 13:11 ` Hervé Poussineau
2017-01-15 19:23 ` Artyom Tarasenko
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=20170104000528.GV12761@umbus.fritz.box \
--to=david@gibson.dropbear.id.au \
--cc=agraf@suse.de \
--cc=gteodori@gmail.com \
--cc=hpoussin@reactos.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=thuth@redhat.com \
/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).