Re: [SeaBIOS] [Qemu-devel] KVM call agenda for 2013-05-28

[Gerd Hoffmann]

On 06/01/13 01:01, Jordan Justen wrote:
> 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?

I still think it's better to simply have qemu generate the acpi tables,
but if that isn't going to be accepted we should seriously consider &
evaluate switching to coreboot.

>>> 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.

Yep.  Some OVMF bits would be needed though (virtio drivers, qemu boot
priority support, ...).

cheers,
  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

[Patrick Georgi]

Am 31.05.2013 14:09, schrieb David Woodhouse:
> On Thu, 2013-05-30 at 09:20 -0700, Jordan Justen wrote:
>> On Thu, May 30, 2013 at 5:19 AM, David Woodhouse 
>> wrote:
>>> https://github.com/pgeorgi/edk2/tree/coreboot-pkg
>> Is the license on this actually BSD as the License.txt indicates?
Yes. All code is either Stefan's or my own work or taken from Tiano and
adapted. We will probably import some libpayload code, but that is
BSD-l, too.
>> Is this planned to be upstreamed?
Yes, once it's ready.
>> Does this support UEFI variables?
Not yet, planned.
>> Does this support UEFI IA32 / X64?
Both, no mixed mode.
> Those are questions for Patrick. 
HTH,
Patrick

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

[David Woodhouse]

On Thu, 2013-05-30 at 09:20 -0700, Jordan Justen wrote:
> 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?

Those are questions for Patrick.

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

[Laszlo Ersek]

On 05/31/13 10:13, Peter Stuge wrote:

> ACPI bytes are obviously a function of QEMU configuration.

Precisely!

When we evaluate that (mathematical-sense) function in boot firmware, we
need to retrieve the function's arguments. Those arguments are bits of
QEMU configuration, as you say, and fw_cfg is extremely inconvenient for
fetching them. Whenever the domain or arity of said "mathematical"
function changes (we need more arguments, or different kinds of
arguments), we have to extend fw_cfg with yet another ad-hoc key or file
entry.

The set of arguments going into ACPI tables *is* ad-hoc and arbitrary,
there's nothing to do about it. But at least we shouldn't impede the
retrieval of said arguments with artificial obstacles, such as
half-assedly serializing them over fw_cfg (and not documenting them,
naturally). In qemu the entire pool of arguments, current and future,
would be at just an arm's length, in immediately consumable form.

I've said the same about the acpi_build_madt() prototype that was
proposed for qemu:
.

Thanks,
Laszlo

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

Re: [SeaBIOS] [Qemu-devel] KVM call agenda for 2013-05-28

[Peter Stuge]

Gerd Hoffmann wrote:
> > 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.

Only a minor correction - cbfs is the flash image, which so far
doesn't really change at runtime. Stuff added at runtime goes into
"coreboot tables" which is a coreboot-specified data structure which
SeaBIOS finds and uses to know things like the memory map.

When using coreboot+SeaBIOS on real hardware, ACPI tables are built
and put in place by coreboot, and never modified by SeaBIOS AFAIK.


//Peter

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

Re: [SeaBIOS] [Qemu-devel] KVM call agenda for 2013-05-28

[Gerd Hoffmann]

  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.

> load the boot firmware (SeaBIOS or OVMF or
> something else -- not sure how to configure that),

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

[Michael S. Tsirkin]

On Thu, May 30, 2013 at 09:57:10AM -0700, Jordan Justen wrote:
> 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

Want to review/ack the patches I sent? That's exactly what they do.

-- 
MST

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

Re: [SeaBIOS] [Qemu-devel] KVM call agenda for 2013-05-28

[Michael S. Tsirkin]

On Thu, May 30, 2013 at 09:20:42AM -0700, Jordan Justen wrote:
> 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.

Of course ACPI tables are firmware.
Please note that what my patches do is simply supply
templates for ACPI tables on a ROM device separate
from where bios code resides.
bios still tweaks them in minor ways.
I am guessing this is what happens on real hardware too:
most tables pre-generated in ROM, firmware shadows
them and tweaks them in minor ways.

> 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

[Laszlo Ersek]

On 05/30/13 18:57, Jordan Justen wrote:
> 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.

I think Xen uses a separate utility called "hvmloader" that runs in the
domU.

- http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/5453/focus=5668
- http://xenbits.xen.org/gitweb/?p=xen.git;a=tree;f=tools/firmware/hvmloader
- http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/6255/focus=110562

Laszlo

___
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

[Laszlo Ersek]

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.

Laszlo


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

[David Woodhouse]

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

> > 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.
> 
> 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.

The extra package in the distro really isn't painful to handle, and I
suspect it would end up *reducing* the amount of work that we have to do
to update. You update *just* Coreboot, not *both* of SeaBIOS and OVMF.

> If you implement a private UEFI FAT driver from scratch, or port a free
> software FAT implementation (eg. the r/o one in grub or the r/w one in
> mtools), you could still run into legal problems, I've been told.

That has been said, and it's been said for the FAT implementation in the
kernel too. If a distribution is happy to ship the kernel without
ripping out its FAT support, then I see no reason why that distribution
wouldn't also be happy to ship a version of OVMF with a clean
implementation of FAT support. It doesn't make sense to be happy with
one but not the other.

> We need at least one out-of-tree edk2 patch for now (from you) but
> apparently that's no problem.

That'll get merged soon. We are working on the corresponding spec
update...

> As far as I understand:
> - Jordan is nearing completion of flash support on KVM,
> - he also has WIP NvVar storage on top of qemu flash.
> 
> http://thread.gmane.org/gmane.comp.emulators.qemu/213690
> http://thread.gmane.org/gmane.comp.bios.tianocore.devel/2781/focus=2798
> 
> ("Please coordinate" I guess :))

Ooh, shiny. Yeah, when I get back to actually working on it rather than
just heckling, I'll make sure I do :)

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

[Laszlo Ersek]

On 05/30/13 14:19, David Woodhouse wrote:

> 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.
> 
> The extra package in the distro really isn't painful to handle, and I
> suspect it would end up *reducing* the amount of work that we have to do
> to update. You update *just* Coreboot, not *both* of SeaBIOS and OVMF.

I can't deny there's logic in that, but it still feels like tying
ourselves up in some intricate bondage choreography. "We'd like to move
ACPI tables out of firmware, but we can't move them to qemu due to
project direction disagreement, so let's adopt a middleman." (I'm not
trying to denigrate coreboot -- I don't know it at all --, but
introducing it in a (granted, distro-specific) stack just for this
purpose seems quite arbitrary.)

>> If you implement a private UEFI FAT driver from scratch, or port a free
>> software FAT implementation (eg. the r/o one in grub or the r/w one in
>> mtools), you could still run into legal problems, I've been told.
> 
> That has been said, and it's been said for the FAT implementation in the
> kernel too. If a distribution is happy to ship the kernel without
> ripping out its FAT support, then I see no reason why that distribution
> wouldn't also be happy to ship a version of OVMF with a clean
> implementation of FAT support. It doesn't make sense to be happy with
> one but not the other.

Under my *personal* impression, logic and Common Law don't really mix,
especially not in the US. Still under my *personal* impression, someone
might not feel convenient suing you for redistributing code that already
exists in the upstream Linux kernel, but might happily drag you to court
for an original clean implementation, and then you can explain it's
illogical for them to do so.

The best I can do with your suggestion is to take it to our legal dept.
I would be happy to work on a new FAT driver. (I used to feel
differently earlier but I've changed my mind.)


>> We need at least one out-of-tree edk2 patch for now (from you) but
>> apparently that's no problem.
> 
> That'll get merged soon. We are working on the corresponding spec
> update...

Great news!

Thanks,
Laszlo

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

Re: [SeaBIOS] [Qemu-devel] KVM call agenda for 2013-05-28

[Michael S. Tsirkin]

On Thu, May 30, 2013 at 01:19:18PM +0100, David Woodhouse wrote:
> 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,

Hopefully this is not yet set in stone.

> 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.

We have all kind of logic in qemu. Some of it can thinkably
be moved to a separate VM - it doesn't even need to
run in the same VM as the guest - we could do it e.g. like
kvm unit-test does, with less pain than running it in firmware.
Not clear why would generating ACPI tables - which merely
fills up an array of bytes from internal QEMU
datastructures - should be the part where we start
this modularization.

-- 
MST

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

Re: [SeaBIOS] [Qemu-devel] KVM call agenda for 2013-05-28

[Laszlo Ersek]

On 05/30/13 11:23, David Woodhouse wrote:
> On Wed, 2013-05-29 at 11:18 -0500, Anthony Liguori wrote:
>>
>>> Certainly an option, but that is a long-term project.
>>
>> Out of curiousity, are there other benefits to using coreboot as a core
>> firmware in QEMU?
>>
>> Is there a payload we would ever plausibly use besides OVMF and SeaBIOS?
> 
> I like the idea of using Coreboot on the UEFI side — if the most
> actively used TianoCore platform is CorebootPkg instead of OvmfPkg, that
> makes it a lot easier for people using *real* hardware with Coreboot to
> use TianoCore.

Where is CorebootPkg available from?

> 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.

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:
.)

> 
>> Is there a payload we would ever plausibly use besides OVMF and
>> SeaBIOS?
> 
> For my part I want to get to the point where the default firmware
> shipped with qemu can be OVMF.

For some distributions this is a licensing question as well. See
"FatBinPkg/License.txt". (The same applies if you rebuild it from source
(FatPkgDev), based on "FatBinPkg/ReadMe.txt".)  For example Fedora can't
ship OVMF because of it.

If you implement a UEFI FAT driver based on Microsoft's official
specification, you're bound by the same restrictions on use and
redistribution.

If you implement a private UEFI FAT driver from scratch, or port a free
software FAT implementation (eg. the r/o one in grub or the r/w one in
mtools), you could still run into legal problems, I've been told.

If you rip out the FAT driver, then OVMF won't be UEFI compliant and no
installer media will boot on it.

Interestingly, Ubuntu has OVMF in "Universe"
. I think they missed the
FatBinPkg license (I would have missed it too, after all you have to
track down the licenses of every module included in the FDF file -- it
was Paolo who told me about it) and I believe they should actually ship
OVMF in Multiverse or Restricted
.

> We have SeaBIOS-as-CSM working, which was
> one of the biggest barriers.

Agreed, and I could have never done that. Thanks for implementing it
with Kevin.

We need at least one out-of-tree edk2 patch for now (from you) but
apparently that's no problem.

> There are a few more things (like NV
> variable storage, in particular) that I need to fix before I can
> actually make that suggestion with a straight face though...

As far as I understand:
- Jordan is nearing completion of flash support on KVM,
- he also has WIP NvVar storage on top of qemu flash.

http://thread.gmane.org/gmane.comp.emulators.qemu/213690
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/2781/focus=2798

("Please coordinate" I guess :))

Laszlo

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

Re: [SeaBIOS] [Qemu-devel] KVM call agenda for 2013-05-28

[Gerd Hoffmann]

  Hi,

> Why should this be true?  Shouldn't we be allowed to increase the amount
> of memory the guest has across reboots?  That's equivalent to adding
> another DIMM after power off.

poweroff is equivalent to exiting qemu, not to guest reset.

> Not generating tables on reset does limit what we can do in a pretty
> fundamental way.  Even if you can argue it in the short term, I don't
> think it's viable in the long term.

I don't think so.  The procedure for adding/removing non-hotpluggable
hardware is:  poweroff, plugin/-out hardware (change config in qemu),
boot.  Hotpluggable hardware doesn't need acpi table updates.

cheers,
  Gerd


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