Re: [Qemu-devel] synching GPE0_BLK between OVMF and qemu
On Sat, Apr 28, 2012 at 06:17:24PM -0700, Jordan Justen wrote: On Sat, Apr 28, 2012 at 00:08, Gleb Natapov g...@redhat.com wrote: On Fri, Apr 27, 2012 at 02:55:48PM -0700, Jordan Justen wrote: 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, Actually this is incorrect. QEMU implements PMBA and Seabios sets it to 0xb000. Sorry about the confusion. 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. The pci/cpu/memory hotplug/unplug functionality is also using hard coded addresses in the 0x400 range? No, the hard coded addresses at 0x400 range are used for FW debug. There are four of them 0x400/0x401 used to print panic message on stderr and exit qemu process, now they do nothing but qemu still registers them. 0x402/0x403 print character to stderr if qemu is compiled with DEBUG_BIOS, but ports are registered even if DEBUG_BIOS is not defined. hotplug/unplug uses addresses 0xae00 and above. And, 0xb000 would be the recommended PM base address? Yes. QEMU splits PM and GPE address spaces though. GPE starts at 0xafe0 and is hardcoded. I do not see the way to move it to PMBA + offset and stay backwards compatible (at least not without adding new fw_cfg value, but what would be the advantage). It would be better for OVMF to treat QEMU like separate platform, that behave almost, but not exactly like, real HW. Yes, it does seem like that will be required here. Yes, since we do want to support functionality that does not exist in PIIX4 spec. -- Gleb.
Re: [Qemu-devel] synching GPE0_BLK between OVMF and qemu
On Fri, Apr 27, 2012 at 02:55:48PM -0700, Jordan Justen wrote: On Fri, Apr 27, 2012 at 11:47, Laszlo Ersek ler...@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. 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.
Re: [Qemu-devel] synching GPE0_BLK between OVMF and qemu
On Sat, Apr 28, 2012 at 00:08, Gleb Natapov g...@redhat.com wrote: On Fri, Apr 27, 2012 at 02:55:48PM -0700, Jordan Justen wrote: 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. The pci/cpu/memory hotplug/unplug functionality is also using hard coded addresses in the 0x400 range? And, 0xb000 would be the recommended PM base address? It would be better for OVMF to treat QEMU like separate platform, that behave almost, but not exactly like, real HW. Yes, it does seem like that will be required here. -Jordan
[Qemu-devel] synching GPE0_BLK between OVMF and qemu
Hi, I'm trying to improve understanding between OVMF and qemu-kvm. 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? (SeaBIOS's src/acpi.c #defines PIIX4_GPE0_BLK as 0xafe0 as well.) Or should this setting be communicated via fw_cfg too (not yet in OVMF as far as I know)? Thank you, Laszlo
Re: [Qemu-devel] synching GPE0_BLK between OVMF and qemu
On Fri, Apr 27, 2012 at 07:31, Laszlo Ersek ler...@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? We set PBMA to 0x400 in OvmfPkg/Library/AcpiTimerLib/AcpiTimerLib.c, so isn't 0x40c correct? Thanks, -Jordan
Re: [Qemu-devel] synching GPE0_BLK between OVMF and qemu
On 04/27/12 17:12, Jordan Justen wrote: On Fri, Apr 27, 2012 at 07:31, Laszlo Ersek ler...@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
Re: [Qemu-devel] synching GPE0_BLK between OVMF and qemu
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 ler...@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.
Re: [Qemu-devel] synching GPE0_BLK between OVMF and qemu
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
Re: [Qemu-devel] synching GPE0_BLK between OVMF and qemu
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.
Re: [Qemu-devel] synching GPE0_BLK between OVMF and qemu
On Fri, Apr 27, 2012 at 11:47, Laszlo Ersek ler...@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
