On 05/31/13 09:09, Jordan Justen wrote:
Why is updating the ACPI tables in seabios viewed as such a burden? Either qemu does it, or seabios... (And, OVMF too, but I don't think you guys are concerned with that. :)
I am :)
On the flip side, why is moving the ACPI tables to QEMU such an issue? It seems like Xen and virtualbox both already do this. Why is running iasl not an issue for them?
I think something was mentioned about iasl having problems on BE machines? I could be easily wrong but I *guess* qemu's hosts x targets (emulate what on what) set is a proper superset of xen's and virtualbox's. Presumably if you want to run an x86 guest on a MIPS host, and also want to build qemu on the same MIPS (or SPARC) host, you'd have to run iasl there too.
Maybe we are doing lots of things horribly wrong in our OVMF ACPI tables :)
Impossible. :)
In earnest, I think what we have now is (mostly) correct, just not extensive / flexible enough. No support for PCI hotplug or CPU hotplug, none for S3 (although all of these tie into UEFI deeply), no MTRR setup, no MPTABLE; let alone a non-PIIX chipset. (Well maybe I shouldn't lump these under the "ACPI umbrella".)
but I haven't seen it as much of a burden. (Of course, Laszlo has helped out with many of the ACPI changes in OVMF, so his opinion should be taken into consideration too. :)
It hasn't been a "burden" in the sense of me not liking the activity; I actually like fiddling with knobs. It has certainly been extra work to bring OVMF's ACPI tables closer to SeaBIOS's functionality / flexibility (and we still lag behind it quite.).
Due to licensing differences I can't just port code from SeaBIOS to OVMF (and I never have without explicit permission), so it's been a lot of back and forth with acpidump / iasl -d in guests (massage OVMF, boot guest, check guest dmesg / lspci, dump tables, compare, repeat), brain picking colleagues, the ACPI and PIIX specs and so on. I have a page on the RH intranet dedicated to this. When something around these parts is being changed (or looks like it could be changed) in SeaBIOS, or between qemu and SeaBIOS, I always must be alert and consider reimplementing it in, or porting it with permission to, OVMF. (Most recent example: pvpanic device -- currently only in SeaBIOS.)
It worries me that if I slack off, or am busy with something else, or simply don't notice, then the gap will widen again. I appreciate learning a bunch about ACPI, and don't mind the days of work that went into some of my simple-looking ACPI patches for OVMF, but had the tables come from a common (programmatic) source, none of this would have been an issue, and I wouldn't have felt even occasionally that ACPI patches for OVMF were both duplicate work *and* futile (considering how much ahead SeaBIOS was).
I don't mind reimplementing stuff, or porting it with permission, going forward, but the sophisticated parts in SeaBIOS are a hard nut. For example I'll never be able to auto-extract offsets from generated AML and patch the AML using those offsets; the edk2 build tools (a project separate from edk2) don't support this, and it takes several months to get a thing as simple as gcc-47 build flags into edk2-buildtools.
Instead I have to write template ASL, compile it to AML, hexdump the result, verify it against the AML grammar in the ACPI spec (offsets aren't obvious, BytePrefix and friends are a joy), define & initialize a packed struct or array in OVMF, and patch the template AML using fixed field names or array subscripts. Workable, but dog slow. If the ACPI payload came from up above, we might be as well provided with a list of (canonical name, offset, size) triplets, and could perhaps blindly patch the contents. (Not unlike Michael's linker code for connecting tables into a hierarchy.)
AFAIK most recently iasl got built-in support for offset extraction (and in the process the current SeaBIOS build method was broken...), so that part might get easier in the future.
Oh well it's Friday, sorry about this rant! :) I'll happily do what I can in the current status quo, but frequently, it won't amount to much.
Thanks, Laszlo
Laszlo Ersek lersek@redhat.com writes:
On 05/31/13 09:09, Jordan Justen wrote:
Due to licensing differences I can't just port code from SeaBIOS to OVMF
<soapbox>
Fork OVMF, drop the fat module, and just add GPL code. It's an easily solvable problem.
Rewriting BSD implementations of everything is silly. Every other vendor that uses TianoCore has a proprietary fork. Maintaining a GPL fork seems just as reasonable.
</soapbox>
Regards,
Anthony Liguori
(and I never have without explicit permission), so it's been a lot of back and forth with acpidump / iasl -d in guests (massage OVMF, boot guest, check guest dmesg / lspci, dump tables, compare, repeat), brain picking colleagues, the ACPI and PIIX specs and so on. I have a page on the RH intranet dedicated to this. When something around these parts is being changed (or looks like it could be changed) in SeaBIOS, or between qemu and SeaBIOS, I always must be alert and consider reimplementing it in, or porting it with permission to, OVMF. (Most recent example: pvpanic device -- currently only in SeaBIOS.)
It worries me that if I slack off, or am busy with something else, or simply don't notice, then the gap will widen again. I appreciate learning a bunch about ACPI, and don't mind the days of work that went into some of my simple-looking ACPI patches for OVMF, but had the tables come from a common (programmatic) source, none of this would have been an issue, and I wouldn't have felt even occasionally that ACPI patches for OVMF were both duplicate work *and* futile (considering how much ahead SeaBIOS was).
I don't mind reimplementing stuff, or porting it with permission, going forward, but the sophisticated parts in SeaBIOS are a hard nut. For example I'll never be able to auto-extract offsets from generated AML and patch the AML using those offsets; the edk2 build tools (a project separate from edk2) don't support this, and it takes several months to get a thing as simple as gcc-47 build flags into edk2-buildtools.
Instead I have to write template ASL, compile it to AML, hexdump the result, verify it against the AML grammar in the ACPI spec (offsets aren't obvious, BytePrefix and friends are a joy), define & initialize a packed struct or array in OVMF, and patch the template AML using fixed field names or array subscripts. Workable, but dog slow. If the ACPI payload came from up above, we might be as well provided with a list of (canonical name, offset, size) triplets, and could perhaps blindly patch the contents. (Not unlike Michael's linker code for connecting tables into a hierarchy.)
AFAIK most recently iasl got built-in support for offset extraction (and in the process the current SeaBIOS build method was broken...), so that part might get easier in the future.
Oh well it's Friday, sorry about this rant! :) I'll happily do what I can in the current status quo, but frequently, it won't amount to much.
Thanks, Laszlo
On 05/31/13 15:04, Anthony Liguori wrote:
Laszlo Ersek lersek@redhat.com writes:
On 05/31/13 09:09, Jordan Justen wrote:
Due to licensing differences I can't just port code from SeaBIOS to OVMF
<soapbox>
:)
Fork OVMF, drop the fat module, and just add GPL code. It's an easily solvable problem.
It's not optimal for the "upstream first" principle; we'd have to backport upstream edk2 patches forever (there's a whole lot of edk2 modules outside of direct OvmfPkg that get built into OVMF.fd -- OvmfPkg "only" customizes / cherry-picks the full edk2 tree for virtual machines), or to periodically rebase an ever-increasing set of patches.
Independently, we need *some* FAT driver (otherwise you can't even boot most installer media), which is where the already discussed worries lie. Whatever solves this aspect is independent of forking all of edk2.
Rewriting BSD implementations of everything is silly. Every other vendor that uses TianoCore has a proprietary fork.
Correct, but they (presumably) keep rebasing their ever accumulating stuff at least on the periodically refreshed "stable edk2 subset" (UDK2010, which BTW doesn't include OvmfPkg). This must be horrible for them, but in exchange they get to remain proprietary (which may benefit them commercially).
Maintaining a GPL fork seems just as reasonable.
Perhaps; diverging from "upstream first" would hurt for certain.
</soapbox>
Thanks for the suggestion :) Laszlo
Laszlo Ersek lersek@redhat.com writes:
On 05/31/13 15:04, Anthony Liguori wrote:
Laszlo Ersek lersek@redhat.com writes:
On 05/31/13 09:09, Jordan Justen wrote:
Due to licensing differences I can't just port code from SeaBIOS to OVMF
<soapbox>
:)
Fork OVMF, drop the fat module, and just add GPL code. It's an easily solvable problem.
It's not optimal for the "upstream first" principle;
<still on soapbox>
OVMF is not Open Source so "upstream first" doesn't apply. At least, the FAT module is not Open Source.
Bullet 8 from the Open Source Definition[1]
"8. License Must Not Be Specific to a Product
The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution."
License from OVMF FAT module[2]:
"Additional terms: In addition to the forgoing, redistribution and use of the code is conditioned upon the FAT 32 File System Driver and all derivative works thereof being used for and designed only to read and/or write to a file system that is directly managed by: Intel’s Extensible Firmware Initiative (EFI) Specification v. 1.0 and later and/or the Unified Extensible Firmware Interface (UEFI) Forum’s UEFI Specifications v.2.0 and later (together the “UEFI Specifications”); only as necessary to emulate an implementation of the UEFI Specifications; and to create firmware, applications, utilities and/or drivers."
[1] http://opensource.org/osd-annotated [2] http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Edk2-fat-dri...
AFAIK, for the systems that we'd actually want to use OVMF for, a FAT module is a hard requirement.
we'd have to backport upstream edk2 patches forever (there's a whole lot of edk2 modules outside of direct OvmfPkg that get built into OVMF.fd -- OvmfPkg "only" customizes / cherry-picks the full edk2 tree for virtual machines), or to periodically rebase an ever-increasing set of patches.
Independently, we need *some* FAT driver (otherwise you can't even boot most installer media), which is where the already discussed worries lie. Whatever solves this aspect is independent of forking all of edk2.
It's either Open Source or it's not. It's currently not. I have a hard time sympathesizing with trying to work with a proprietary upstream.
Rewriting BSD implementations of everything is silly. Every other vendor that uses TianoCore has a proprietary fork.
Correct, but they (presumably) keep rebasing their ever accumulating stuff at least on the periodically refreshed "stable edk2 subset" (UDK2010, which BTW doesn't include OvmfPkg). This must be horrible for them, but in exchange they get to remain proprietary (which may benefit them commercially).
Maintaining a GPL fork seems just as reasonable.
Perhaps; diverging from "upstream first" would hurt for certain.
Well I'm suggesting creating a real upstream (that is actually Open Source). Then I'm all for upstream first.
In terms of creating a FAT module, the most likely source would seem to be the kernel code and since that's GPL, I don't think it's terribly avoidable to end up with a GPL'd uefi implementation.
If that's inevitable, then we're wasting effort by rewriting stuff under a BSD license.
Regards,
Anthony Liguori
</soapbox>
Thanks for the suggestion :) Laszlo
On 05/31/13 16:38, Anthony Liguori wrote:
It's either Open Source or it's not. It's currently not.
I disagree with this binary representation of Open Source or Not. If it weren't (mostly) Open Source, how could we fork (most of) it as you're suggesting (from the soapbox :))?
I have a hard time sympathesizing with trying to work with a proprietary upstream.
My experience has been positive.
First of all, whether UEFI is a good thing or not is controversial. I won't try to address that.
However UEFI is here to stay, machines are being shipped with it, Linux and other OSen try to support it. Developing (or running) an OS in combination with a specific firmware is sometimes easier / more economic in a virtual environment, hence there should be support for qemu + UEFI. It is this mindset that I operate in. (Oh, I also forgot to mention that this task has been assigned to me by my superiors as well :))
Jordan, the OvmfPkg maintainer is responsive and progressive in the true FLOSS manner (*), which was a nice surprise for a project whose coding standards for example are made 100% after Windows source code, and whose mailing list is mostly subscribed to by proprietary vendors. Really when it comes to OvmfPkg patches the process follows the "normal" FLOSS development model.
(*) Jordan, I hope this will prompt you to merge VirtioNetDxe v4 real soon now :)
I personally think the 2-clause BSDL for 99% of the project was a very sane and practical one from Intel et al.
FatPkg is a sad exception. One might even consider it a bad accident: http://thread.gmane.org/gmane.comp.bios.tianocore.devel/1861/focus=1878
I have no idea how that selection process went down, but I assume if FLOSS people had been screaming very loud at that time and had offered a *simple* (which ext2 is not, I gather), wide-spread and unencumbered filesystem, things would be different today.
In terms of creating a FAT module, the most likely source would seem to be the kernel code and since that's GPL, I don't think it's terribly avoidable to end up with a GPL'd uefi implementation.
If that's inevitable, then we're wasting effort by rewriting stuff under a BSD license.
Please ask your employer if they'd be willing to put their name on an original, clean-room, GPL-licensed implementation of FAT32 for UEFI.
Thus far we've been talking copyright rather than patents, but there's also this:
http://en.wikipedia.org/wiki/FAT_filesystem#Challenge http://en.wikipedia.org/wiki/FAT_filesystem#Patent_infringement_lawsuits
It almost doesn't matter who prevails in such a lawsuit; the *possibility* of such a lawsuit gives people cold feet. Blame the USPTO.
Laszlo
On Fri, May 31, 2013 at 7:38 AM, Anthony Liguori anthony@codemonkey.ws wrote:
In terms of creating a FAT module, the most likely source would seem to be the kernel code and since that's GPL, I don't think it's terribly avoidable to end up with a GPL'd uefi implementation.
Why would OpenBSD not be a potential source?
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/msdosfs/
We have a half-done ext2 fs from GSoC2011 that started with OpenBSD.
https://github.com/the-ridikulus-rat/Tianocore_Ext2Pkg
If that's inevitable, then we're wasting effort by rewriting stuff under a BSD license.
Regards,
Anthony Liguori
On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote:
<soapbox>
Fork OVMF, drop the fat module, and just add GPL code. It's an easily solvable problem.
Heh. Actually it doesn't need to be a fork. It's modular, and the FAT driver is just a single module. Which is actually included in *binary* form in the EDK2 repository, I believe, and its source code is elsewhere.
We could happily make a GPL¹ or LGPL implementation of a FAT module and build our OVMF with that instead, and we wouldn't need to fork OVMF at all.
On 05/31/13 16:08, David Woodhouse wrote:
On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote:
<soapbox>
Fork OVMF, drop the fat module, and just add GPL code. It's an easily solvable problem.
Heh. Actually it doesn't need to be a fork. It's modular, and the FAT driver is just a single module. Which is actually included in *binary* form in the EDK2 repository, I believe, and its source code is elsewhere.
Correct.
We could happily make a GPL¹ or LGPL implementation of a FAT module and build our OVMF with that instead, and we wouldn't need to fork OVMF at all.
Yes, that's one plan, *if* someone can sort out, or is willing to shoulder, the perhaps illogical but still worrisome surroundings of FatPkg / FatBinPkg.
(I don't intend to spread FUD!)
For example, if your employer authorizes you to implement GplFatPkg from scratch, and distribute it as an external module, I -- as someone without any education in law though -- will give you a standing ovation and buy you a case of beer at KVM Forum 2013. Deal? :)
(You proved to have great leverage by getting the efi compat table extended, so... :))
¹ If it's GPL, of course, then we mustn't include any *other* binary blobs in our OVMF build. But the whole point in this conversation is that we don't *want* to do that. So that's fine.
Right. Eg. Shell1 is embedded as a pre-built binary, but that's just "convenience", you can build the in-tree Shell2 from source afresh and embed that instead (and ship its source too).
Laszlo
David Woodhouse dwmw2@infradead.org writes:
On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote:
<soapbox>
Fork OVMF, drop the fat module, and just add GPL code. It's an easily solvable problem.
Heh. Actually it doesn't need to be a fork. It's modular, and the FAT driver is just a single module. Which is actually included in *binary* form in the EDK2 repository, I believe, and its source code is elsewhere.
We could happily make a GPL¹ or LGPL implementation of a FAT module and build our OVMF with that instead, and we wouldn't need to fork OVMF at all.
So can't we have GPL virtio modules too? I don't think there's any problem there except for the FAT module.
I would propose more of a virtual fork. It could consist of a git repo with the GPL modules + a submodule for edk2. Ideally, there would be no need to actually fork edk2.
My assumption is that edk2 won't take GPL code. But does ovmf really need to live in the edk2 tree?
If we're going to get serious about supporting OVMF, it we need something that isn't proprietary.
-- dwmw2
¹ If it's GPL, of course, then we mustn't include any *other* binary blobs in our OVMF build. But the whole point in this conversation is that we don't *want* to do that. So that's fine.
It's even more fundamental. OVMF as a whole (at least in it's usable form) is not Open Source. Without even tackling the issue of GPL code sharing, that is a fundamental problem that needs to be solved if we're going to serious about making changes to QEMU to support it.
I think solving the general problem will also enable GPL code sharing though.
Regards,
Anthony Liguori
On Fri, 2013-05-31 at 10:43 -0500, Anthony Liguori wrote:
It's even more fundamental. OVMF as a whole (at least in it's usable form) is not Open Source.
The FAT module is required to make EDK2 usable, and yes, that's not Open Source. So in a sense you're right.
But we're talking here about *replacing* the FAT module with something that *is* open source. And the FAT module isn't a fundamental part of EDK2; it's just an optional module that happens to be bundled with the repository.
So I think you're massively overstating the issue. OVMF/EDK2 *is* Open Source, and replacing the FAT module really isn't that hard.
We can only bury our heads in the sand and ship qemu with non-EFI-capable firmware for so long...
I *know* there's more work to be done. We have SeaBIOS-as-CSM, Jordan has mostly sorted out the NV variable storage, and now the FAT issue is coming up to the top of the pile. But we aren't far from the point where we can realistically say that we want the Open Source OVMF to be the default firmware shipped with qemu.
On 05/31/13 18:33, David Woodhouse wrote:
On Fri, 2013-05-31 at 10:43 -0500, Anthony Liguori wrote:
It's even more fundamental. OVMF as a whole (at least in it's usable form) is not Open Source.
The FAT module is required to make EDK2 usable, and yes, that's not Open Source. So in a sense you're right.
But we're talking here about *replacing* the FAT module with something that *is* open source. And the FAT module isn't a fundamental part of EDK2; it's just an optional module that happens to be bundled with the repository.
Yes. *Some* FAT module is a hard requirement.
So I think you're massively overstating the issue. OVMF/EDK2 *is* Open Source,
Agreed,
and replacing the FAT module really isn't that hard.
technically it's not hard; for a seasoned file system developer (which I'm not, of course), even possibly missing UEFI bits, it should be children's play actually, considering the high quality of UEFI documentation and the responsiveness of edk2-devel.
Considering US legal climate however, it appears *extremely* hard to replace the FAT module, in my unwashed personal opinion.
Laszlo
David Woodhouse dwmw2@infradead.org writes:
On Fri, 2013-05-31 at 10:43 -0500, Anthony Liguori wrote:
It's even more fundamental. OVMF as a whole (at least in it's usable form) is not Open Source.
The FAT module is required to make EDK2 usable, and yes, that's not Open Source. So in a sense you're right.
But we're talking here about *replacing* the FAT module with something that *is* open source. And the FAT module isn't a fundamental part of EDK2; it's just an optional module that happens to be bundled with the repository.
So *if* we replace the FAT module *and* that replacement was GPL, would there be any objects to having more GPL modules for things like virtio, ACPI, etc?
And would that be doable in the context of OVMF or would another project need to exist for this purpose?
So I think you're massively overstating the issue. OVMF/EDK2 *is* Open Source, and replacing the FAT module really isn't that hard.
We can only bury our heads in the sand and ship qemu with non-EFI-capable firmware for so long...
Which is why I think we need to solve the real problem here.
I *know* there's more work to be done. We have SeaBIOS-as-CSM, Jordan has mostly sorted out the NV variable storage, and now the FAT issue is coming up to the top of the pile. But we aren't far from the point where we can realistically say that we want the Open Source OVMF to be the default firmware shipped with qemu.
Yes, that's why I'm raising this now. We all knew that we'd have to talk about this eventually.
Regards,
Anthony Liguori
-- dwmw2
Il 31/05/2013 19:06, Anthony Liguori ha scritto:
David Woodhouse dwmw2@infradead.org writes:
On Fri, 2013-05-31 at 10:43 -0500, Anthony Liguori wrote:
It's even more fundamental. OVMF as a whole (at least in it's usable form) is not Open Source.
The FAT module is required to make EDK2 usable, and yes, that's not Open Source. So in a sense you're right.
But we're talking here about *replacing* the FAT module with something that *is* open source. And the FAT module isn't a fundamental part of EDK2; it's just an optional module that happens to be bundled with the repository.
So *if* we replace the FAT module *and* that replacement was GPL, would there be any objects to having more GPL modules for things like virtio, ACPI, etc?
And would that be doable in the context of OVMF or would another project need to exist for this purpose?
I don't think it would be doable in TianoCore. I think it would end up either in distros, or in QEMU.
A separate question is whether OVMF makes more sense as part of TianoCore or rather as part of QEMU. With 75% of the free hypervisors now reunited under the same source repository, the balance is tilting...
Paolo
Paolo Bonzini pbonzini@redhat.com writes:
Il 31/05/2013 19:06, Anthony Liguori ha scritto:
David Woodhouse dwmw2@infradead.org writes:
On Fri, 2013-05-31 at 10:43 -0500, Anthony Liguori wrote:
It's even more fundamental. OVMF as a whole (at least in it's usable form) is not Open Source.
The FAT module is required to make EDK2 usable, and yes, that's not Open Source. So in a sense you're right.
But we're talking here about *replacing* the FAT module with something that *is* open source. And the FAT module isn't a fundamental part of EDK2; it's just an optional module that happens to be bundled with the repository.
So *if* we replace the FAT module *and* that replacement was GPL, would there be any objects to having more GPL modules for things like virtio, ACPI, etc?
And would that be doable in the context of OVMF or would another project need to exist for this purpose?
I don't think it would be doable in TianoCore. I think it would end up either in distros, or in QEMU.
As I think more about it, I think forking edk2 is inevitable. We need a clean repo that doesn't include the proprietary binaries. I doubt upstream edk2 is willing to remove the binaries.
But this can be quite simple using a combination of git-svn and a rewriting script. We did exactly this to pull out the VGABios from Bochs and remove the binaries associated with it. It's 100% automated and can be kept in sync via a script on qemu.org.
A separate question is whether OVMF makes more sense as part of TianoCore or rather as part of QEMU.
I'm not sure if qemu.git is the right location, but we can certainly host an ovmf.git on qemu.git that embeds the scrubbed version of edk2.git.
Of course, this would enable us to add GPL code (including a FAT module) to ovmf.git without any impact on upstream edk2.
With 75% of the free hypervisors now reunited under the same source repository, the balance is tilting...
<insert evil laugh> :-)
Regards,
Anthony Liguori
Paolo
On Fri, May 31, 2013 at 11:35 AM, Anthony Liguori anthony@codemonkey.ws wrote:
As I think more about it, I think forking edk2 is inevitable. We need a clean repo that doesn't include the proprietary binaries. I doubt upstream edk2 is willing to remove the binaries.
No, probably not unless a BSD licensed alternative was available. :)
But, in thinking about what might make sense for EDK II with git, one option that should be considered is breaking the top-level 'packages' into separate sub-modules. I had gone so far as to start pushing repos as sub-modules.
But, as the effort to convert EDK II to git has stalled (actually never even thought about leaving the ground), I abandoned that approach and went back to just mirroring one EDK II.
I could fairly easily re-enable mirror the sub-set of packages needed for OVMF. So, in that case, the FatBinPkg sub-module could easily be dropped from a tree.
But this can be quite simple using a combination of git-svn and a rewriting script. We did exactly this to pull out the VGABios from Bochs and remove the binaries associated with it. It's 100% automated and can be kept in sync via a script on qemu.org.
I would love to mirror the BaseTools as a sub-package without all the silly windows binaries... What script did you guys use?
-Jordan
On 05/31/13 17:43, Anthony Liguori wrote:
David Woodhouse dwmw2@infradead.org writes:
On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote:
<soapbox>
Fork OVMF, drop the fat module, and just add GPL code. It's an easily solvable problem.
Heh. Actually it doesn't need to be a fork. It's modular, and the FAT driver is just a single module. Which is actually included in *binary* form in the EDK2 repository, I believe, and its source code is elsewhere.
We could happily make a GPL¹ or LGPL implementation of a FAT module and build our OVMF with that instead, and we wouldn't need to fork OVMF at all.
So can't we have GPL virtio modules too? I don't think there's any problem there except for the FAT module.
I share your assessment.
I would propose more of a virtual fork. It could consist of a git repo with the GPL modules + a submodule for edk2. Ideally, there would be no need to actually fork edk2.
Indeed. edk2 is extremely modular. But in order to get a useful firmware image ultimately, you need a FAT driver.
My assumption is that edk2 won't take GPL code.
Correct, see eg. OvmfPkg/Contributions.txt.
Laszlo
On Fri, May 31, 2013 at 01:45:55PM +0200, Laszlo Ersek wrote:
On 05/31/13 09:09, Jordan Justen wrote:
Why is updating the ACPI tables in seabios viewed as such a burden? Either qemu does it, or seabios... (And, OVMF too, but I don't think you guys are concerned with that. :)
I am :)
On the flip side, why is moving the ACPI tables to QEMU such an issue? It seems like Xen and virtualbox both already do this. Why is running iasl not an issue for them?
I think something was mentioned about iasl having problems on BE machines? I could be easily wrong but I *guess* qemu's hosts x targets (emulate what on what) set is a proper superset of xen's and virtualbox's. Presumably if you want to run an x86 guest on a MIPS host, and also want to build qemu on the same MIPS (or SPARC) host, you'd have to run iasl there too.
You guys should take a look at the patch series I posted.
That's solved there by the means of keeping iasl output in qemu git tree. configure checks for a working iasl and enables/disables using this pre-processed output accordingly. Everyone developing ASL code would still need working iasl but that's already the case today.
tables :)
Impossible. :)
In earnest, I think what we have now is (mostly) correct, just not extensive / flexible enough. No support for PCI hotplug or CPU hotplug, none for S3 (although all of these tie into UEFI deeply), no MTRR setup, no MPTABLE; let alone a non-PIIX chipset. (Well maybe I shouldn't lump these under the "ACPI umbrella".)
but I haven't seen it as much of a burden. (Of course, Laszlo has helped out with many of the ACPI changes in OVMF, so his opinion should be taken into consideration too. :)
It hasn't been a "burden" in the sense of me not liking the activity; I actually like fiddling with knobs. It has certainly been extra work to bring OVMF's ACPI tables closer to SeaBIOS's functionality / flexibility (and we still lag behind it quite.).
Due to licensing differences I can't just port code from SeaBIOS to OVMF (and I never have without explicit permission), so it's been a lot of back and forth with acpidump / iasl -d in guests (massage OVMF, boot guest, check guest dmesg / lspci, dump tables, compare, repeat), brain picking colleagues, the ACPI and PIIX specs and so on. I have a page on the RH intranet dedicated to this. When something around these parts is being changed (or looks like it could be changed) in SeaBIOS, or between qemu and SeaBIOS, I always must be alert and consider reimplementing it in, or porting it with permission to, OVMF. (Most recent example: pvpanic device -- currently only in SeaBIOS.)
It worries me that if I slack off, or am busy with something else, or simply don't notice, then the gap will widen again. I appreciate learning a bunch about ACPI, and don't mind the days of work that went into some of my simple-looking ACPI patches for OVMF, but had the tables come from a common (programmatic) source, none of this would have been an issue, and I wouldn't have felt even occasionally that ACPI patches for OVMF were both duplicate work *and* futile (considering how much ahead SeaBIOS was).
I don't mind reimplementing stuff, or porting it with permission, going forward, but the sophisticated parts in SeaBIOS are a hard nut. For example I'll never be able to auto-extract offsets from generated AML and patch the AML using those offsets; the edk2 build tools (a project separate from edk2) don't support this, and it takes several months to get a thing as simple as gcc-47 build flags into edk2-buildtools.
Instead I have to write template ASL, compile it to AML, hexdump the result, verify it against the AML grammar in the ACPI spec (offsets aren't obvious, BytePrefix and friends are a joy), define & initialize a packed struct or array in OVMF, and patch the template AML using fixed field names or array subscripts. Workable, but dog slow. If the ACPI payload came from up above, we might be as well provided with a list of (canonical name, offset, size) triplets, and could perhaps blindly patch the contents. (Not unlike Michael's linker code for connecting tables into a hierarchy.)
AFAIK most recently iasl got built-in support for offset extraction (and in the process the current SeaBIOS build method was broken...), so that part might get easier in the future.
Oh well it's Friday, sorry about this rant! :) I'll happily do what I can in the current status quo, but frequently, it won't amount to much.
Thanks, Laszlo
On Sun, Jun 2, 2013 at 2:43 AM, Michael S. Tsirkin mst@redhat.com wrote:
On Fri, May 31, 2013 at 01:45:55PM +0200, Laszlo Ersek wrote:
On 05/31/13 09:09, Jordan Justen wrote:
Why is updating the ACPI tables in seabios viewed as such a burden? Either qemu does it, or seabios... (And, OVMF too, but I don't think you guys are concerned with that. :)
I am :)
On the flip side, why is moving the ACPI tables to QEMU such an issue? It seems like Xen and virtualbox both already do this. Why is running iasl not an issue for them?
I think something was mentioned about iasl having problems on BE machines? I could be easily wrong but I *guess* qemu's hosts x targets (emulate what on what) set is a proper superset of xen's and virtualbox's. Presumably if you want to run an x86 guest on a MIPS host, and also want to build qemu on the same MIPS (or SPARC) host, you'd have to run iasl there too.
You guys should take a look at the patch series I posted.
That's solved there by the means of keeping iasl output in qemu git tree. configure checks for a working iasl and enables/disables using this pre-processed output accordingly. Everyone developing ASL code would still need working iasl but that's already the case today.
I'm sorry the I haven't had time to review your series yet. But, from what you saying about it in this thread, it sounds like a good plan.
-Jordan
-
Anthony Liguori -
David Woodhouse -
Jordan Justen -
Laszlo Ersek -
Michael S. Tsirkin -
Paolo Bonzini