Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest

[Jordan Justen]

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]

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] KVM call agenda for 2013-05-28

[Jordan Justen]

On Sun, Jun 2, 2013 at 2:43 AM, Michael S. Tsirkin  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] KVM call agenda for 2013-05-28

[Jordan Justen]

On Fri, May 31, 2013 at 2:32 AM, Gerd Hoffmann  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] KVM call agenda for 2013-05-28

[Jordan Justen]

On Fri, May 31, 2013 at 11:35 AM, Anthony Liguori  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] KVM call agenda for 2013-05-28

[Jordan Justen]

On Fri, May 31, 2013 at 7:38 AM, Anthony Liguori  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

[Jordan Justen]

On Thu, May 30, 2013 at 7:34 PM, Kevin O'Connor  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] [Qemu-devel] KVM call agenda for 2013-05-28

[Jordan Justen]

On Thu, May 30, 2013 at 9:41 AM, Laszlo Ersek  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] [Qemu-devel] KVM call agenda for 2013-05-28

[Jordan Justen]

On Thu, May 30, 2013 at 5:19 AM, David Woodhouse  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:
>> .)
>
> 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] SeaBIOS as EFI application

[Jordan Justen]

On Sat, Nov 10, 2012 at 1:07 PM, Kevin O'Connor  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  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] SeaBIOS as EFI application

[Jordan Justen]

On Sat, Nov 10, 2012 at 8:25 AM, Thorsten Glaser  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] synching GPE0_BLK between OVMF and qemu

[Jordan Justen]

On Sat, Apr 28, 2012 at 00:08, Gleb Natapov  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

[Jordan Justen]

On Fri, Apr 27, 2012 at 11:47, Laszlo Ersek  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

[Jordan Justen]

On Wed, Mar 9, 2011 at 05:43, Natalia Portillo  wrote:
> This may come late in the discussion, but, has OVMF been tested with Mac OS X?

No.

I don't think Apple considers VMs an acceptable usage environment for
OS X.  Please correct me if I am mistaken.

Thanks,

-Jordan

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [Qemu-devel] OVMF Google Summer of Code ideas

[Jordan Justen]

On Tue, Mar 8, 2011 at 18:23, Kevin O'Connor  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