qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH rebased for-1.8] i386: pc: align gpa<->hpa on 1G


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH rebased for-1.8] i386: pc: align gpa<->hpa on 1GB boundary (v6)
Date: Tue, 10 Dec 2013 23:00:09 +0200

On Tue, Dec 10, 2013 at 06:46:12PM +0100, Laszlo Ersek wrote:
> On 12/10/13 16:53, Gerd Hoffmann wrote:
> > On Di, 2013-12-10 at 16:47 +0100, Laszlo Ersek wrote:
> >> On 12/10/13 15:53, Gerd Hoffmann wrote:
> >>>   Hi,
> >>>
> >>>> If we could make a small guset visible change, it would be simpler to
> >>>> always make the PCI hole 1GB in size; it is currently 256MB for i440FX
> >>>> and 1.25GB for q35.
> >>>
> >>> Easy for i440fx.
> >>
> >> I think it's going to break OVMF again.
> > 
> > Can't see a reason why it should.
> 
> PCI enumeration in OVMF assigns resources from a window that starts
> exactly above the end of below-4gb-memory. For example, in case of a
> 2.5GB guest, the frame buffer bar of cirrus can be somewhere just above
> 2.5GB.
> 
> If you change the PCI hole in qemu so that it will start at 3GB, always,
> then the ACPI tables exported by qemu will also advertise the big mmio
> range starting at 3GB. OVMF will pass those tables through to the OS.
> Accordingly, the OS will try to access the framebuffer above 3GB, but
> OVMF has configured that bar between 2.5GB and 3GB.
> 
> IOW, I think this proposal would undo your [PATCH v2] piix: fix 32bit
> pci hole.
> 
> I can of course live with whatever PCI hole as long as it is made
> available to OVMF through an easy-to-parse fw_cfg file. Then I can sync
> the OVMF enumeration to qemu's preference.
> 
> The fw_cfg file "etc/pci-info" allowed me to do exactly that. But it has
> been killed. I'd like it to be resurrected, even if SeaBIOS ignores it.
> 
> Thanks,
> Laszlo

There's no PCI hole in QEMU.
All there is, is RAM split in two chunks: below and above 4G.

-- 
MST



reply via email to

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