Re: [SeaBIOS] KVM call agenda for 2013-05-28
On Sun, Jun 2, 2013 at 2:43 AM, Michael S. Tsirkin m...@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 ___ 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 anth...@codemonkey.ws wrote: Michael S. Tsirkin m...@redhat.com 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] KVM call agenda for 2013-05-28
On Thu, May 30, 2013 at 7:34 PM, Kevin O'Connor ke...@koconnor.net wrote: On Tue, May 28, 2013 at 07:53:09PM -0400, Kevin O'Connor wrote: There were discussions on potentially introducing a middle component to generate the tables. Coreboot was raised as a possibility, and David thought it would be okay to use coreboot for both OVMF and SeaBIOS. The possibility was also raised of a rom that lives in the qemu repo, is run in the guest, and generates the tables (which is similar to the hvmloader approach that Xen uses). Given the objections to implementing ACPI directly in QEMU, one possible way forward would be to split the current SeaBIOS rom into two roms: qvmloader and seabios. The qvmloader would do the qemu specific platform init (pci init, smm init, mtrr init, bios tables) and then load and run the regular seabios rom. With this split, qvmloader could be committed into the QEMU repo and maintained there. This would be analogous to Xen's hvmloader with the seabios code used as a starting point to implement it. I think hvmloader is more closely tied to Xen, than the Xen firmware. I could be wrong, but thought it could do things like add memory to guest machine. ?? I don't think this model is analogous to Xen's model. I view the hvmloader as just a part of Xen. (Not part of the 'firmware' stack.) In adding this pre-firmware firmware, wouldn't Anthony's concern of iasl still be an issue? 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. :) 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 overall I prefer the tables being built in the firmware, despite the extra thrash. Some things, such as the addresses where devices are configured at are re-programmable in QEMU, so a firmware can decide to use a different address, and thus invalidate the address qvmloader had set in the tables. Maybe we are doing lots of things horribly wrong in our OVMF ACPI tables :), 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. :) -Jordan ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] KVM call agenda for 2013-05-28
On Fri, May 31, 2013 at 7:38 AM, Anthony Liguori anth...@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 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] KVM call agenda for 2013-05-28
On Fri, May 31, 2013 at 11:35 AM, Anthony Liguori anth...@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 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] KVM call agenda for 2013-05-28
On Fri, May 31, 2013 at 2:32 AM, Gerd Hoffmann kra...@redhat.com wrote: Hi, I guess -bios would load coreboot. Coreboot would siphon the data necessary for ACPI table building through the current (same) fw_cfg bottleneck, build the tables, Yes. So, this is really about making coreboot+seabios the default QEMU firmware, and making seabios depend on being a coreboot payload? load the boot firmware (SeaBIOS or OVMF or something else -- not sure how to configure that), It wouldn't be loading OVMF. It would be loading CorebootPkg. OVMF is a better sample platform for EDK II since it shows a more realistic view of what an EDK II based platform looks like on real hardware. Thus, if the ACPI tables are just being added to a new coreboot layer with coreboot becoming the default QEMU firmware, then it doesn't help OVMF (or other non-coreboot payloads). Well, it could if the table code was BSD licensed, but only so we could then merge them into OVMF. Then again, why not just provide a set of suitably licensed ACPI source files within the QEMU tree that firmware projects could use? QEMU doesn't necessarily need to build/link them, or attempt to communicate them at runtime. -Jordan The coreboot rom has named sections (this is called cbfs which stands for coreboot filesystem IIRC): rincewind kraxel ~# cbfstool /usr/share/coreboot.git/bios.bin print bios.bin: 256 kB, bootblocksize 848, romsize 262144, offset 0x0 alignment: 64 bytes Name Offset Type Size cmos_layout.bin0x0cmos_layout 1160 fallback/romstage 0x4c0 stage14419 fallback/coreboot_ram 0x3d80 stage37333 config 0xcfc0 raw 2493 fallback/payload 0xd9c0 payload 56969 vgabios/sgabios0x1b8c0raw 4096 (empty)0x1c900null 144216 where fallback/payload is seabios. and pass down the tables to the firmware (through a now unspecified interface -- perhaps the tables could even be installed at this point). As far I know coreboot can add more stuff such as acpi tables to cbfs at runtime and seabios able to access cbfs too and pull informations from coreboot that way. HTH, Gerd ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] KVM call agenda for 2013-05-28
On Thu, May 30, 2013 at 5:19 AM, David Woodhouse dw...@infradead.org wrote: On Thu, 2013-05-30 at 13:13 +0200, Laszlo Ersek wrote: Where is CorebootPkg available from? https://github.com/pgeorgi/edk2/tree/coreboot-pkg Is the license on this actually BSD as the License.txt indicates? Is this planned to be upstreamed? Does this support UEFI variables? Does this support UEFI IA32 / X64? And it helps to dispel the stupid misconception in some quarters that Coreboot *competes* with UEFI and thus cannot possibly be supported because helping something that competes with UEFI would be bad. Coreboot and EDK II both provide a good infrastructure for initializing hardware. So, they compete on that point. Coreboot then focuses on booting coreboot payloads, while EDK II focuses on UEFI support. On that point they don't compete, but the focus is different. Of course, you can build a layer of EDK II = Coreboot payload support, or Coreboot = EDK II (CorebootPkg, I guess?), but the match will not be perfect. (That is not to say it can't work.) I'm not sure who do you mean by some quarters, but for some distributions Coreboot would be yet another component (package) to support, for no obvious benefit. (Gerd said it better than I possibly could: http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/5685/focus=5705.) Yeah, but if we're shoving a lot of hardware-specific ACPI table generation into the guest's firmware, instead of just doing it on the qemu side where a number of us seem to think it belongs, then there *is* a benefit to using Coreboot. When stuff changes on the qemu side and we have to update the table generation to match, you end up having to update just the Coreboot package, and *not* having to patch both SeaBIOS and OVMF. I think ACPI table generation lives in firmware on real products, because on real products the firmware is the point that best understands the actual hardware layout for the machine. In qemu, I would say that qemu best knows the hardware layout, given that the firmware is generally a slightly separate project from qemu. I don't think adding a coreboot layer into the picture helps, if it brings along the coreboot payload boot interface as a requirement. Then again, I don't really understand how firmware could be swapped out in this case. What would -bios do? How would the coreboot ACPI shim layer be specified to qemu? -Jordan ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] KVM call agenda for 2013-05-28
On Thu, May 30, 2013 at 9:41 AM, Laszlo Ersek ler...@redhat.com wrote: On 05/30/13 18:20, Jordan Justen wrote: I think ACPI table generation lives in firmware on real products, because on real products the firmware is the point that best understands the actual hardware layout for the machine. In qemu, I would say that qemu best knows the hardware layout, given that the firmware is generally a slightly separate project from qemu. I don't think adding a coreboot layer into the picture helps, if it brings along the coreboot payload boot interface as a requirement. Then again, I don't really understand how firmware could be swapped out in this case. What would -bios do? How would the coreboot ACPI shim layer be specified to qemu? I guess -bios would load coreboot. Coreboot would siphon the data necessary for ACPI table building through the current (same) fw_cfg bottleneck, build the tables, load the boot firmware (SeaBIOS or OVMF or something else -- not sure how to configure that), and pass down the tables to the firmware (through a now unspecified interface -- perhaps the tables could even be installed at this point). This could introduce another interface (fw_cfg+something rather than just fw_cfg), but ACPI table preparation would be concentrated in one project. I guess. For reference, I believe that both Xen and virtualbox build ACPI table in the VMM rather than firmware. They both dump the tables into the 0xe000 segment (yuck) where firmware finds and publishes it to the OS. I think fw-cfg would be a reasonable alternative to this for communicating the tables. -Jordan ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] SeaBIOS as EFI application
On Sat, Nov 10, 2012 at 8:25 AM, Thorsten Glaser t...@mirbsd.de wrote: Kevin O'Connor dixit: 1 - Using SeaBIOS as a CSM. The CSM spec is amazingly complex as 2 - Implementing in SeaBIOS a subset of the EFI OS interface so that Both aren’t really what I want. It sounds like you definitely don't want 2, but you do want something similar to 1. In a UEFI+CSM system, the CSM essentially provides the environment that legacy BIOS based software can use. To be clear though, neither of the above paths would enable you to boot something like DOS on an existing UEFI system. It may be Yeah. I was more thinking of having SeaBIOS be an EFI “OS”, just like the MirBSD bootloader is a Multiboot compliant “OS kernel”, and then take over the system and load the real OS, providing BIOS calls to it. How do you generically deal with chipset memory protection in 0xc-0x10? (Ie, shadow ram that Kevin mentioned.) You may find that you need a 'chipset driver' to allow you to write these regions. UEFI has the LegacyRegion protocol for this for CSM systems, for example. But, in a non-CSM UEFI system, there is no need for the LegacyRegion protocol. It could be that in a post-CSM UEFI world that these regions will generally just be set to RAM mode, but I wouldn't bet on it. It certainly seems unlikely that you could rely on this for all UEFI systems. In OVMF we currently leave those regions in ROM mode. -Jordan ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] SeaBIOS as EFI application
On Sat, Nov 10, 2012 at 1:07 PM, Kevin O'Connor ke...@koconnor.net wrote: On Sat, Nov 10, 2012 at 11:30:39AM -0800, Jordan Justen wrote: On Sat, Nov 10, 2012 at 8:25 AM, Thorsten Glaser t...@mirbsd.de wrote: Kevin O'Connor dixit: 1 - Using SeaBIOS as a CSM. The CSM spec is amazingly complex as 2 - Implementing in SeaBIOS a subset of the EFI OS interface so that Both aren’t really what I want. It sounds like you definitely don't want 2, but you do want something similar to 1. In a UEFI+CSM system, the CSM essentially provides the environment that legacy BIOS based software can use. I don't think one can add a CSM to an existing machine though. I think you could load it similarly to an OS, but what you load would probably require some chipset/platform knowledge. So, if you're looking to boot DOS from a machine with an off-the-shelf UEFI implementation without a CSM then I don't think adding a CSM will work. Yes, I think you are correct, due to the chipset/platform legacy pieces that likely aren't provided in a non-CSM UEFI system. -Jordan ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] 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 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] 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 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] OVMF Google Summer of Code ideas
On Tue, Mar 8, 2011 at 18:23, Kevin O'Connor ke...@koconnor.net wrote: On Tue, Mar 08, 2011 at 09:00:05AM -0800, Jordan Justen wrote: Yes, the UEFI system is still in place. The UEFI part still handles the majority of platform init, and calls into the CSM at various points. The CSM returns back to UEFI for all CSM calls, except the legacy boot. Is there a concise list of these various callbacks between UEFI and CSM? If SeaBIOS just needs to be loaded up for legacy boots, that doesn't sound too difficult. However, if SeaBIOS would need to translate various BIOS calls into UEFI calls - that sounds like it could be complex. A CSM does not really know about UEFI for the most part. Rather it carries out some tasks when request by the UEFI environment. The UEFI side still manages the high level boot flow (even for legacy boots). The CSM does not call into UEFI services, but just returns back to whoever invoked the CSM call. The 16-bit CSM component interface is described in this file: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/IntelFrameworkPkg/Include/Protocol/LegacyBios.h The full CSM specification document is available here: http://www.intel.com/technology/framework/spec.htm Thanks, -Jordan ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
