On 04/27/12 17:12, Jordan Justen wrote:
On Fri, Apr 27, 2012 at 07:31, Laszlo Ersek lersek@redhat.com wrote:
edk2's "OvmfPkg/AcpiTables/Platform.h" specifies GPE0_BLK at 0x40C, while qemu's "hw/acpi_piix4.c" expects the guest to access it at 0xAFE0. Which macro should be modified to get them in sync?
Do they need to be in sync?
It appears to me so:
https://bugzilla.redhat.com/show_bug.cgi?id=653382#c22
We set PBMA to 0x400 in OvmfPkg/Library/AcpiTimerLib/AcpiTimerLib.c, so isn't 0x40c correct?
Considering OVMF in isolation, I presume it's self-consistent.
However, is it necessary (a) to group these ACPI registers closely together, (b) to base the "group" at 0x400?
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).
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())
But I'm likely missing something ^W everything...
Thanks! Laszlo
On Fri, Apr 27, 2012 at 07:24:48PM +0200, Laszlo Ersek wrote:
On 04/27/12 17:12, Jordan Justen wrote:
On Fri, Apr 27, 2012 at 07:31, Laszlo Ersek lersek@redhat.com wrote:
edk2's "OvmfPkg/AcpiTables/Platform.h" specifies GPE0_BLK at 0x40C, while qemu's "hw/acpi_piix4.c" expects the guest to access it at 0xAFE0. Which macro should be modified to get them in sync?
Do they need to be in sync?
It appears to me so:
https://bugzilla.redhat.com/show_bug.cgi?id=653382#c22
We set PBMA to 0x400 in OvmfPkg/Library/AcpiTimerLib/AcpiTimerLib.c, so isn't 0x40c correct?
Considering OVMF in isolation, I presume it's self-consistent.
However, is it necessary (a) to group these ACPI registers closely together, (b) to base the "group" at 0x400?
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.
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.
But I'm likely missing something ^W everything...
Thanks! Laszlo
-- Gleb.
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".
Anyway, back to my original question: currently OVMF and qemu disagree wrt. GPE0. Which one should I try to modify so that they agree?
Thanks, Laszlo
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.
On Fri, Apr 27, 2012 at 11:47, Laszlo Ersek lersek@redhat.com 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.
Regarding a solution, such as communicating the address in fw_cfg, that could work. OVMF has plans to add fw_cfg support.
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?
-Jordan
-
Gleb Natapov -
Jordan Justen -
Laszlo Ersek