Re: [Qemu-devel] [PATCH rebased for-1.8] i386: pc: align gpa<->hpa on 1GB boundary (v6)

[Laszlo Ersek <lersek@redhat.com>]

On 12/10/13 22:00, Michael S. Tsirkin wrote:
> 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.

I don't mind reformulating (but we've been around this track a couple of
times):

Please let OVMF know about the big MMIO range (the "split" you mention)
- that is going to be advertised via ACPI to the OS,
- in an easy to parse format over fw_cfg.

Gerd's patch that I mentioned above doesn't do this. It restores peace
between the ACPI advertisment produced by qemu and between OVMF's
enumeration by duplicating logic that OVMF does ahead of enumeration. If
you change that qemu code, then OVMF will either have to duplicate the
new qemu code, or it will need to understand the boundaries of the split
from an easy-to-parse fw_cfg file.

Thanks
Laszlo