Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
On Mon, Jun 3, 2013 at 4:12 PM, Anthony Liguori wrote: > Jordan Justen writes: >> I mentioned in the other thread that perhaps QEMU could also consider >> making the ACPI code available under some 'appropriate' license, which >> would allow firmware writers to leverage the code directly if desired. >> Perhaps a dual/multi license situation for the relevant files? > > Would the OVMF developers participate in a GPL version of OVMF that live > outside of the EDK2 tree? > > I think the only solution to the licensing problem is a GPL-friendly > UEFI build... Sounds like there is no chance for a multi-license scenario then? My idea here was that QEMU could consider what potential licensing situations alternative firmware writers might desire, and attempt to multi-license the code so it could be used as reference code for those potential consumers. I guess if that is not possible and the fw-cfg method doesn't work out, then we'll probably need to keep doing our best in re-implementing the ASL/ACPI code. OVMF is an important part of the EDK II project, and thus a viable OVMF within the EDK II tree is important. Therefore, we need BSD licensed code for the core pieces of OVMF. (Such as producing ACPI tables.) You mentioned that FatBinPkg in the EDK II tree is a particular issue for some OVMF derivatives. To solve that (as I mentioned in the other thread) I'd be willing to publish a git-submodule version of OVMF. This would also allow OVMF derived projects to include other packages. (Potentially with different source licenses.) Given that there are no FAT driver alternatives, the only purpose I could see for this anytime soon would be something that incorporates the seabios-csm. -Jordan ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
Jordan Justen writes: > On Tue, May 14, 2013 at 6:34 AM, Anthony Liguori > wrote: >> "Michael S. Tsirkin" writes: >> >>> On Mon, May 13, 2013 at 03:38:51PM -0500, Anthony Liguori wrote: I don't think it's a good idea to move BIOS functionality in QEMU. >>> >>> Just to clarify: generating ACPI tables is not BIOS >>> functionality. It ended up in seabios for historical >>> reasons. >>> >>> A normal scenario for ACPI tables is that they are written >>> in ASL and compiled with IASL. >> >> I wouldn't call this the normal scenario. Some tables are static but >> more tables are dynamic than you'd think. If you're a firmware engineer >> and you have to support dozens of platforms, it's much easier to make >> the tables dynamic than attempt to maintain dozens of ASL descriptions. > > Anthony is right. Firmware for "real" systems contains the tables as > binary aml output from the asl compiler, but also goes through > extensive hoops to tweak the ACPI information. > > On the other hand, "real firmware" doesn't have the luxury of being > able to just download the ACPI tables like fw-cfg might be able to > offer. > > I'm a little concerned that firmware might find a desire to still > customize the tables, and thus the fw-cfg solution might be too > restricting. It does seem to work out okay for other VMM projects > though. (It does seem to be working for Xen in OVMF. But, I'm not > certain how well it is working, since I don't have a Xen setup.) > > I mentioned in the other thread that perhaps QEMU could also consider > making the ACPI code available under some 'appropriate' license, which > would allow firmware writers to leverage the code directly if desired. > Perhaps a dual/multi license situation for the relevant files? Would the OVMF developers participate in a GPL version of OVMF that live outside of the EDK2 tree? I think the only solution to the licensing problem is a GPL-friendly UEFI build... Regards, Anthony Liguori > > But, if the fw-cfg route works, then it seems the easiest option for > firmware writers. > > -Jordan ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
On Tue, May 14, 2013 at 6:34 AM, Anthony Liguori wrote: > "Michael S. Tsirkin" writes: > >> On Mon, May 13, 2013 at 03:38:51PM -0500, Anthony Liguori wrote: >>> I don't think it's a good idea to move BIOS functionality in QEMU. >> >> Just to clarify: generating ACPI tables is not BIOS >> functionality. It ended up in seabios for historical >> reasons. >> >> A normal scenario for ACPI tables is that they are written >> in ASL and compiled with IASL. > > I wouldn't call this the normal scenario. Some tables are static but > more tables are dynamic than you'd think. If you're a firmware engineer > and you have to support dozens of platforms, it's much easier to make > the tables dynamic than attempt to maintain dozens of ASL descriptions. Anthony is right. Firmware for "real" systems contains the tables as binary aml output from the asl compiler, but also goes through extensive hoops to tweak the ACPI information. On the other hand, "real firmware" doesn't have the luxury of being able to just download the ACPI tables like fw-cfg might be able to offer. I'm a little concerned that firmware might find a desire to still customize the tables, and thus the fw-cfg solution might be too restricting. It does seem to work out okay for other VMM projects though. (It does seem to be working for Xen in OVMF. But, I'm not certain how well it is working, since I don't have a Xen setup.) I mentioned in the other thread that perhaps QEMU could also consider making the ACPI code available under some 'appropriate' license, which would allow firmware writers to leverage the code directly if desired. Perhaps a dual/multi license situation for the relevant files? But, if the fw-cfg route works, then it seems the easiest option for firmware writers. -Jordan ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
On Tue, 2013-05-14 at 10:38 +0100, Peter Maydell wrote: > > It depends. For ARM we insist that the user provides the > device tree that corresponds to the kernel they're going to > run, and then we just tweak it a bit. Um... device trees describe hardware, and should not be at all kernel-specific. Did you mean to say "the device tree that corresponds to the machine they're going to emulate"? And I suppose you do have a kernel that corresponds to the machine it's going to run on, so what you say isn't *entirely* bogus. But it's just written in a way which makes it scary :) -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
On 14 May 2013 15:29, David Woodhouse wrote: > On Tue, 2013-05-14 at 10:38 +0100, Peter Maydell wrote: >> It depends. For ARM we insist that the user provides the >> device tree that corresponds to the kernel they're going to >> run, and then we just tweak it a bit. > > Um... device trees describe hardware, and should not be at all > kernel-specific. Did you mean to say "the device tree that corresponds > to the machine they're going to emulate"? No, I meant "corresponding to the kernel". (Qualifier to the following rant: I'm talking specifically about ARM; I understand PPC is different.) In my experience if you try to use a device tree blob other than the one which you produce from the dts that is shipped with the exact revision of the kernel that you're booting, then it is likely to result in missing devices at best and quite likely random inexplicable crashes. ARM device trees are simply churning way too much at the moment (the usual failure behaviour is "device which was driven by board data gets a DT binding, so using an old DT means the kernel doesn't think the device exists at all", but I've seen crashes too). Maybe in a decade we'll be able to claim that device trees are a description of the hardware, but right now the fact is that this is a kernel specific data structure and it's not guaranteed to work with anything other than the kernel it goes with. If somebody reports a "this isn't booting" kind of bug, "are you using the right device tree blob for the kernel?" is among the first questions I ask (and I have zero interest in debugging cases where there's a mismatch.) I make a very small exception for mach-virt, because it's entirely device tree driven and there's a very small set of things that appear in it. So we have a reasonable chance of holding kernel peoples' feet to the fire if they try to break existing device trees generated by QEMU or kvmtool. For anything else I am absolutely against having QEMU generate any ARM device tree blobs or do anything beyond the minimal modifications to them we absolutely must. thanks -- PMM ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
Gerd Hoffmann writes: > Hi, > and is also a good reason why exposing this information via a common interface (fw_cfg) would be a good idea. >>> >>> Huh? As far I know we generate device trees in qemu instead of >>> expecting pseries firmware compile them from fw_cfg information. >> >> It depends on what firmware you are using. > > Of course. On archs which don't use device trees in the first place it > doesn't make sense. > >> We don't really generate device trees in general in QEMU. > > pseries does (thats why the hard libfdt dependency if you want pseries > support). arm wants move into that direction too. pseries is a bad example because it's not a real hardware platform. It's emulating what PowerVM does. It's more akin to the xenpv machine than a real piece of hardware. > >> As Peter mentioned, in an ideal world we'd generate them from the QOM >> graph. > > Sure. > >> That should happen in the firmware and it could be enabled by >> adding just a couple fw_cfg commands to navigate the QOM graph (analogs >> to qom-list and qom-get in QMP). > > I don't think Peter intended to imply *that* ... Yes, this has been discussed dozens of times in the past. And as I've said in the past, generating device trees belongs in the firmware. It's a firmware/OS interface. It's not just an academic argument though. We want to expose hardware interfaces that are rich enough for firmware to do whatever it needs to do to initialize the system. There are a lot of things that are normally only visible to firmware that we don't emulate today. In exposing this information, we ought to attempt to do so in an architectural neutral way. ACPI is not architectural neutral. You could argue that that's okay because we only need to support two things: ACPI and device trees. But that's not quite right. Device trees very often have platform specific quirks so a generated device tree in common code is not going to have the right set of quirks for any given system. Having a good interface for firmware to generate ACPI tables and device trees solves this problem in a much nicer way. It enables firmware to display whatever type of tree it wants (ACPI or device tree) and also provides the flexibility to implement the necessary quirks for that platform. Regards, Anthony Liguori > > cheers, > Gerd ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
Hi, >>> and is also a good >>> reason why exposing this information via a common interface (fw_cfg) >>> would be a good idea. >> >> Huh? As far I know we generate device trees in qemu instead of >> expecting pseries firmware compile them from fw_cfg information. > > It depends on what firmware you are using. Of course. On archs which don't use device trees in the first place it doesn't make sense. > We don't really generate device trees in general in QEMU. pseries does (thats why the hard libfdt dependency if you want pseries support). arm wants move into that direction too. > As Peter mentioned, in an ideal world we'd generate them from the QOM > graph. Sure. > That should happen in the firmware and it could be enabled by > adding just a couple fw_cfg commands to navigate the QOM graph (analogs > to qom-list and qom-get in QMP). I don't think Peter intended to imply *that* ... cheers, Gerd ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
Gerd Hoffmann writes: > Hi, > >>> Several future developments that this will enable: >>> - make it easier to use alternative firmware: >>> any firmware can just load the ACPI tables from QEMU. >>> case in point OVMF. >> >> UEFI obviously can create ACPI tables already so I don't think this is a >> valid advantage. > > Yea, but it doesn't do all the patching seabios does, so some features > simply don't work. Generating the tables in qemu instead will zap those > differnces and will make it alot easier to bring all firmware images > (seabios, ovmf, coreboot, ...) to feature parity without duplicating the > code needed for that in all firmwares. The fact that different firmwares duplicate functionality is the based on the fact that the different firmwares inheritently duplication functionality by the virtue of being different projects. >> You could use this argument to say that QEMU should implement int13 or >> int10 too... > > This is comparing apples and oranges. > >> This has strong analogies to generating device trees > > Indeed, both acpi and device trees describe the hardware emulated by > qemu. Comparing acpi + device trees makes alot more sense than > comparing acpi with int10 ... > >> and is also a good >> reason why exposing this information via a common interface (fw_cfg) >> would be a good idea. > > Huh? As far I know we generate device trees in qemu instead of > expecting pseries firmware compile them from fw_cfg information. It depends on what firmware you are using. We don't really generate device trees in general in QEMU. As Peter mentioned, in an ideal world we'd generate them from the QOM graph. That should happen in the firmware and it could be enabled by adding just a couple fw_cfg commands to navigate the QOM graph (analogs to qom-list and qom-get in QMP). Regards, Anthony Liguori > > cheers, > Gerd ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
On 14 May 2013 10:29, Gerd Hoffmann wrote: > Anthony wrote: >> and is also a good >> reason why exposing this information via a common interface (fw_cfg) >> would be a good idea. > > Huh? As far I know we generate device trees in qemu It depends. For ARM we insist that the user provides the device tree that corresponds to the kernel they're going to run, and then we just tweak it a bit. (For the upcoming 'mach-virt' pure-virtual hardware we're going to end up generating a device tree completely from scratch, though.) Not sure fw_cfg is particularly relevant though -- for device tree the obvious "nice" way to do it would be to have the device tree generating/modifying code able to walk the QOM object tree introspecting it to identify hardware presence and properties. That's probably not doable today though. (I need to look more closely at PPC device tree handling, really.) thanks -- PMM ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
Hi, >> Several future developments that this will enable: >> - make it easier to use alternative firmware: >> any firmware can just load the ACPI tables from QEMU. >> case in point OVMF. > > UEFI obviously can create ACPI tables already so I don't think this is a > valid advantage. Yea, but it doesn't do all the patching seabios does, so some features simply don't work. Generating the tables in qemu instead will zap those differnces and will make it alot easier to bring all firmware images (seabios, ovmf, coreboot, ...) to feature parity without duplicating the code needed for that in all firmwares. > You could use this argument to say that QEMU should implement int13 or > int10 too... This is comparing apples and oranges. > This has strong analogies to generating device trees Indeed, both acpi and device trees describe the hardware emulated by qemu. Comparing acpi + device trees makes alot more sense than comparing acpi with int10 ... > and is also a good > reason why exposing this information via a common interface (fw_cfg) > would be a good idea. Huh? As far I know we generate device trees in qemu instead of expecting pseries firmware compile them from fw_cfg information. cheers, Gerd ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
