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: Fri, 27 Apr 2012 21:53:02 +0300

On Fri, Apr 27, 2012 at 08:47:00PM +0200, Laszlo Ersek wrote:
> On 04/27/12 20:09, Gleb Natapov wrote:
> > On Fri, Apr 27, 2012 at 07:24:48PM +0200, Laszlo Ersek wrote:
> 
> >> >From "5.2.9 Fixed ACPI Description Table (FADT)" in the ACPI spec (v5.0)
> >> it would appear OVMF can freely choose where to put GPE0_BLK, in both
> >> senses (ie. port address considered alone, and also in relation to the
> >> other ACPI registers).
> >>
> > OVMF can't freely choose where to put GPE0_BLK. It should describe to
> > OSPM where GPE0_BLK is in HW. If it provides incorrect value this is
> > OVMF bug.
> 
> By "freely" I didn't mean freedom from correctly setting up the FADT. I
> meant OVMF coders can reasonably freely choose what port to use --
> because the ACPI spec, or their own codebase, or the other registers
> don't restrict them -- and then they have to describe the chosen port in
> FADT.
> 
> As a special case, they even have the freedom to choose GPE0_BLK so that
> it matches the hardware (qemu) and things start working; there's no
> external obstacle in their way. My only point was "you're free to set up
> GPE0_BLK correctly, nothing ties your hands".
> 
> 
> >> Considering SeaBIOS again (build_fadt()):
> >> - PORT_ACPI_PM_BASE is 0xb000,
> >> - PM1a_EVT_BLK, PM1a_CNT_BLK and PM_TMR_BLK are located consecutively
> >> from this base,
> >> - but GPE0_BLK is placed at 0xafe0 (build_fadt() -->
> >> pci_init_device(fadt_init_tbl) --> piix4_fadt_init())
> >>
> > That is because those are two totally different things. One is PM1
> > register another is GPE0 register. The very obvious hint that they are
> > unrelated is that they described by two different fields in FADT.
> 
> Of course. That was my exact point. They are independent, so OVMF isn't
> forced either to squeeze them in the same port range from 0x400. OVMF is
> free to locate GPE0 so that it matches qemu, independently from other
> ACPI registers.
> 
> 
> 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.
> 
> To quote a mutual friend, "we're in violent agreement".
> 
Oh yes, we are :)

> Anyway, back to my original question: currently OVMF and qemu disagree
> wrt. GPE0. Which one should I try to modify so that they agree?
> 
OVMF of course if you ask me. We are not going to recall millions of
QEMU evaluations boards!

--
                        Gleb.



reply via email to

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