qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] synching GPE0_BLK between OVMF and qemu


From: Gleb Natapov
Subject: Re: [Qemu-devel] synching GPE0_BLK between OVMF and qemu
Date: Sat, 28 Apr 2012 10:08:13 +0300

On Fri, Apr 27, 2012 at 02:55:48PM -0700, Jordan Justen wrote:
> On Fri, Apr 27, 2012 at 11:47, Laszlo Ersek <address@hidden> wrote:
> > This was how I interpreted our discussion with Jordan:
> >
> > L: Shouldn't qemu & OVMF agree on GPE0?
> > J: Why? Anyway, OVMF should be correct, because all ACPI registers are
> > in one tight bunch, starting from 0x400.
> > L: None of those two characteristics (1: "0x400", 2: "one tight bunch")
> > are required by the spec. For proof, see what SeaBIOS does: 1: it
> > doesn't use 0x400 as base, 2: GPE0 is not even above the base.
> 
> This code was written to the PIIX4 datasheet. According to the
> datasheet, if you change PMBA, it changes the GPE blk too.
> 
> It sounds like QEMU does not emulate this, and hardcodes the GPE blk.
> 
Yes. QEMU does not really implement PIIX4 though. It implements PIIX3 +
PM from PIIX4 (but with a functionality that is not present in original
spec like pci/cpu hotplug) + other differences that firmware had to take
into account. For instance event if QEMU will implement PMBA, OVMF would
not be able to configure it to the value 0x400 since QEMU hardcodes
another PV device there.

> Regarding a solution, such as communicating the address in fw_cfg,
> that could work. OVMF has plans to add fw_cfg support.
> 
Can it check that it runs over QEMU and use QEMU's values? No need for
new fw_cfg.

> > Anyway, back to my original question: currently OVMF and qemu disagree
> > wrt. GPE0. Which one should I try to modify so that they agree?
> 
> It does seem like qemu could be changed, does it? It would require a
> simultaneous fix of qemu & seabios. But, if qemu could be changed,
> could it be made to match the PIIX4 datasheet?
> 
We try not to change QEMU in non backwards compatible way. We can
implement PMBA and start using address there if FW writes into it,
but, as I noted before, OVMF will have to be changed anyways since 0x400
address is already occupied and pci/cpu/memory hotplug/unplug
functionality uses additional IO space not documented by PIIX4 spec.

It would be better for OVMF to treat QEMU like separate platform, that
behave almost, but not exactly like, real HW.

--
                        Gleb.



reply via email to

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