Re: [SeaBIOS] [Qemu-stable] [QEMU PATCH v3] qdev: fix get_fw_dev_path to support to add nothing to fw_dev_path

[Stefan Priebe - Profihost AG]

Am 31.05.2013 00:51, schrieb Amos Kong:
 On Thu, May 30, 2013 at 10:30:21PM +0200, Stefan Priebe wrote:
 Am 30.05.2013 15:13, schrieb Amos Kong:
 On Thu, May 30, 2013 at 02:09:25PM +0200, Stefan Priebe - Profihost AG 
 wrote:
 Am 29.05.2013 09:56, schrieb Amos Kong:
 Recent virtio refactoring in QEMU made virtio-bus become the parent bus
 of scsi-bus, and virtio-bus doesn't have get_fw_dev_path implementation,
 typename will be added to fw_dev_path by default, the new fw_dev_path
 could not be identified by seabios. It causes that bootindex parameter
 of scsi device doesn't work.

 This patch implements get_fw_dev_path() in BusClass, it will be called
 if bus doesn't implement the method, tyename will be added to
 fw_dev_path. If the implemented method returns NULL, nothing will be
 added to fw_dev_path.

 It also implements virtio_bus_get_fw_dev_path() to return NULL. Then
 QEMU will still pass original style of fw_dev_path to seabios.

 Signed-off-by: Amos Kong ak...@redhat.com
 --
 v2: only add nothing to fw_dev_path when get_fw_dev_path() is
 implemented and returns NULL. then it will not effect other devices
 don't have get_fw_dev_path() implementation.
 v3: implement default get_fw_dev_path() in BusClass
 ---
  hw/core/qdev.c | 10 +-
  hw/virtio/virtio-bus.c |  6 ++
  2 files changed, 15 insertions(+), 1 deletion(-)

 diff --git a/hw/core/qdev.c b/hw/core/qdev.c
 index 6985ad8..9190a7e 100644
 --- a/hw/core/qdev.c
 +++ b/hw/core/qdev.c
 @@ -515,7 +515,7 @@ static int qdev_get_fw_dev_path_helper(DeviceState 
 *dev, char *p, int size)
  l += snprintf(p + l, size - l, %s, d);
  g_free(d);
  } else {
 -l += snprintf(p + l, size - l, %s, 
 object_get_typename(OBJECT(dev)));
 +return l;
  }
  }
  l += snprintf(p + l , size - l, /);
 @@ -867,9 +867,17 @@ static void qbus_initfn(Object *obj)
  QTAILQ_INIT(bus-children);
  }

 +static char *default_bus_get_fw_dev_path(DeviceState *dev)
 +{
 +return g_strdup(object_get_typename(OBJECT(dev)));
 +}
 +
  static void bus_class_init(ObjectClass *class, void *data)
  {
 +BusClass *bc = BUS_CLASS(class);
 +
  class-unparent = bus_unparent;
 +bc-get_fw_dev_path = default_bus_get_fw_dev_path;
  }

  static void qbus_finalize(Object *obj)
 diff --git a/hw/virtio/virtio-bus.c b/hw/virtio/virtio-bus.c
 index ea2e11a..6849a01 100644
 --- a/hw/virtio/virtio-bus.c
 +++ b/hw/virtio/virtio-bus.c
 @@ -161,10 +161,16 @@ static char *virtio_bus_get_dev_path(DeviceState 
 *dev)
  return qdev_get_dev_path(proxy);
  }

 +static char *virtio_bus_get_fw_dev_path(DeviceState *dev)
 +{
 +return NULL;
 +}
 +
  static void virtio_bus_class_init(ObjectClass *klass, void *data)
  {
  BusClass *bus_class = BUS_CLASS(klass);
  bus_class-get_dev_path = virtio_bus_get_dev_path;
 +bus_class-get_fw_dev_path = virtio_bus_get_fw_dev_path;
  }

  static const TypeInfo virtio_bus_info = {


 To me booting VMs with more than one SCSI disk does still not work.

 Hi Stefan,

 Can you provide your full command-lines ?

 net: bootindex=100
 scsi0: bootindex=201

 does not work

 this one works fine:
 net: bootindex=200
 scsi0: bootindex=101

 For me, they all work, (1. check the bootindex string, 2. check boot menu 
 by entering F12, 3. check by waiting ).

 
 Thanks for your reply.
 
 Oh it does only NOT work if i have TWO network cards. It never seems
 to try to boot from scsi0. It tries PXE net0 then net1 and then it
 restarts.
  
 Something is wrong here, '-boot menu=on ' - guest could not restart
 if no available boot device, it will also try to boot from other
 unselected devices (DVD, floppy)
 
 '-boot menu=on,strict=on,reboot-timeout=1000' - boot from net0, net1, disk1, 
 then restart ...
 
 It seems the problem of your bios.bin or rbd device.

I've also updated to seabios 1.7.2.2

 I'm using seabios(pc-bios/bios.bin) in qemu repo  latest seabios in 
 seabios.org
 
 Example:
 Command line:
 qemu -chardev
 socket,id=qmp,path=/var/run/qemu-server/155.qmp,server,nowait -mon
 chardev=qmp,mode=control -pidfile /var/run/qemu-server/155.pid
 -daemonize -name TTT -smp sockets=1,cores=4 -nodefaults -boot
 menu=on -vga cirrus -k de -m 4096 -device
 piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2 -device
 usb-tablet,id=tablet,bus=uhci.0,port=1 -device
 virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 -device
 virtio-scsi-pci,id=scsihw0,bus=pci.0,addr=0x5 -drive 
 file=rbd:stor/vmdisk-1:mon_host=10.255.0.100\:6789\;10.255.0.101\:6789\;10.255.0.102\:6789\;:auth_supported=none,if=none,id=drive-scsi0,iops_rd=215,iops_wr=155,bps_rd=136314880,bps_wr=94371840,aio=native,discard=on
 -device 
 scsi-hd,bus=scsihw0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0,id=scsi0,bootindex=200
 -drive if=none,id=drive-ide2,media=cdrom,aio=native -device
 ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2 -netdev 
 type=tap,id=net0,ifname=tap155i0,script=/var/lib/qemu-server/pve-bridge,vhost=on
 

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

[Jordan Justen]

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

[Peter Stuge]

Kevin O'Connor wrote:
 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.

qvmloader sounds a lot like coreboot.


 qvmloader could be committed into the QEMU repo and maintained there.

If QEMU really doesn't want anything besides quacking like a PC with
BIOS or UEFI (such as quacking like a PC *without* a particular
firmware) it makes perfect sense to me to put the complete firmware
code into the QEMU repo and never reuse anything else. After all,
that's how the proprietary firmware products are managed.


Jordan Justen wrote:
 Why is updating the ACPI tables in seabios viewed as such a burden?

I don't know about burden but to me it just doesn't make any sense
to generate ACPI in one component (SeaBIOS) based on configuration
for another component (QEMU).

ACPI bytes are obviously a function of QEMU configuration. QEMU
configuration can be changed through a great many channels, so it
makes sense to me that QEMU itself would take care of generating
correct ACPI, rather than exporting it's own data structures and
pushing the ACPI problem onto the firmware, especially considering
the desire for multiple independent firmware implementations.

There's some code for dynamic ACPI generation in coreboot already,
maybe that can be reused in QEMU to save some effort..


 On the flip side, why is moving the ACPI tables to QEMU such an issue?

Maybe because it is such a steaming pile that even the place where it
belongs doesn't really want it..


 I think overall I prefer the tables being built in the firmware,
 despite the extra thrash.

That doesn't make sense to me. :\

Keep in mind: there is firmware and there is firmware..


 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.

..there is now talk about a first-stage firmware (qvmloader) which
does only hardware init, and then jumps into a second-stage firmware
(SeaBIOS) which starts the operating system.

I don't expect that anyone would argue for the second-stage firmware
to generate ACPI tables if the first-stage firmware would be shared
across different second-stage implementations.

The above is by the way *exactly* the model coreboot uses since 14 years.

Please make an ernest effort to *look into and try to reuse* what *is
already there* ..

The fear of coreboot is truly amazing.


//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] [Qemu-stable] [QEMU PATCH v3] qdev: fix get_fw_dev_path to support to add nothing to fw_dev_path

[Stefan Priebe - Profihost AG]

Am 31.05.2013 13:02, schrieb Amos Kong:

 ...

 thanks for this great explanation. I've done what you sayd but it still
 does not work.

 Here is the output of the seabis debug log where you see the loop:
 http://pastebin.com/raw.php?i=e53rdW2b
 
 | found virtio-scsi at 0:5
 | Searching bootorder for: /pci@i0cf8/*@5/*@0/*@0,0
 | virtio-scsi vendor='QEMU' product='QEMU HARDDISK' rev='1.5.' type=0 
 removable=0
 | virtio-scsi blksize=512 sectors=104857600
 
 It mean the fixed fw_dev_path can be identified.
 
 You problem is a disrelated issue. I didn't see handle_18 before restart, it
 means guest succeses to boot from second nic. How does the resume be
 caused?

No it def. does not succeed. Only the first nic gets a reply from a tftp
server. It shows a menu and then does:
  localboot -1

which causes to go to the next boot device (pxelinux.cfg).

It then tries to boot from the 2nd nic. But there it gets only an IP
through DHCP but no tftp details or even an answer.

PS: this was working fine with Qemu 1.4.2

 Please only aasign two nics for guest, let's see if restart occurs.

With one nic i see correctly - no bootable device restart in 1 sec.
With only two nics the screen just turns black and nothing happens at
all after trying PXE from 2nd nic. But no message and no restart.

 Did you config pxe+tftp service for second nic? did you set some rom
 that just reboot the system?
DHCP yes tftp service no.

Stefan

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

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

[Laszlo Ersek]

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

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

Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one

[Dave Frodin]

- Original Message -
 From: Kevin O'Connor ke...@koconnor.net
 To: Dave Frodin dave.fro...@se-eng.com
 Cc: seabios seabios@seabios.org
 Sent: Thursday, May 30, 2013 7:45:13 PM
 Subject: Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option 
 ROMs to one
 
 On Thu, May 30, 2013 at 07:49:36AM -0500, Dave Frodin wrote:
   From: Kevin O'Connor ke...@koconnor.net
   --- a/src/optionroms.c
   +++ b/src/optionroms.c
   @@ -178,10 +178,19 @@ deploy_romfile(struct romfile_s *file)
static struct rom_header *
lookup_hardcode(struct pci_device *pci)
{
   -char fname[17];
   -snprintf(fname, sizeof(fname), pci%04x,%04x.rom
   +struct romfile_s *file;
   +char fname[19];
   +snprintf(fname, sizeof(fname), alias%04x,%04x.rom
 , pci-vendor, pci-device);
   -struct romfile_s *file = romfile_find(fname);
   +char *alias = romfile_loadfile(fname, NULL);
   +if (alias) {
   +file = romfile_find(alias);
   +free(alias);
   +} else {
   +snprintf(fname, sizeof(fname), pci%04x,%04x.rom
   + , pci-vendor, pci-device);
   +file = romfile_find(fname);
   +}
if (file)
return deploy_romfile(file);
return NULL;
  
  
  In your sample code above, I don't see where any pci ID translation
  (mapping) occurs.
  As an example we could have a family14 mainboard with a coreboot
  .config that generates a vga option rom with the name
  pci1002,9802.rom. The actual mainboard could have a graphics chip
  with the id of 1002,9804 (which is 1 of 8 possible IDs). So there
  needs to be some sort of mapping function (in SeaBIOS) that maps the
  ID of 1002,9804 to 1002,9802.
 
 With the above patch (assuming it works) one should be able to create
 a CBFS file named alias1002,9804.rom that contains the text
 pci1002,9802.rom.
 
 -Kevin

I see now, that's pretty slick. The problem I see with that approach is
that coreboot would need to add all of these files for a family14 mainboard.
alias1002,9803.rom
alias1002,9804.rom
alias1002,9805.rom
alias1002,9806.rom
alias1002,9807.rom
alias1002,9808.rom
alias1002,9809.rom

And all of these files for a family15 mainboard
alias1002,9901.rom
alias1002,9903.rom
alias1002,9904.rom
alias1002,9906.rom
alias1002,9907.rom
alias1002,9908.rom
alias1002,990a.rom
alias1002,9910.rom
alias1002,9913.rom
alias1002,9917.rom
alias1002,9918.rom
alias1002,9919.rom
alias1002,9990.rom
alias1002,9991.rom
alias1002,9992.rom
alias1002,9993.rom
alias1002,9994.rom
alias1002,99a0.rom
alias1002,99a2.rom
alias1002,99a4.rom

Since at build time we only know what cpu family the rom is being
built for and not (necessarily) what the exact graphics ID is.

The method I proposed would have one family specific vendev-map.bin file.

Someone who's building a rom for a mainboard with a single known graphics
ID wouldn't need to add any files with either method.

Thanks, Dave

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

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

[Anthony Liguori]

Kevin O'Connor ke...@koconnor.net writes:

 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.

What about a small change to the SeaBIOS build system to allow ACPI
table generation to be done via a plugin.

This could be as simple as moving acpi.c and *.dsl into the QEMU build
tree and then having a way to point the SeaBIOS makefiles to our copy of
it.

Then the logic is maintained stays in firmware but the churn happens in
the QEMU tree instead of the SeaBIOS tree.

Regards,

Anthony Liguori


 With both the hardware implementation and acpi descriptions for that
 hardware in the same source code repository, it would be possible to
 implement changes to both in a single patch series.  The fwcfg entries
 used to pass data between qemu and qvmloader could also be changed in
 a single patch and thus those fwcfg entries would not need to be
 considered a stable interface.  The qvmloader code also wouldn't need
 the 16bit handlers that seabios requires and thus wouldn't need the
 full complexity of the seabios build.  Finally, it's possible that
 both ovmf and seabios could use a single qvmloader implementation.

 On the down side, reboots can be a bit goofy today in kvm, and that
 would need to be settled before something like qvmloader could be
 implemented.  Also, it may be problematic to support passing of bios
 tables from qvmloader to seabios for guests with only 1 meg of ram.

 Thoughts?
 -Kevin

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

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

[Anthony Liguori]

Laszlo Ersek ler...@redhat.com writes:

 On 05/31/13 15:04, Anthony Liguori wrote:
 Laszlo Ersek ler...@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-driver

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

___
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:
http://thread.gmane.org/gmane.comp.emulators.qemu/207171/focus=208719.

Thanks,
Laszlo

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

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

[Anthony Liguori]

David Woodhouse dw...@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

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

Re: [SeaBIOS] [PATCH v3] config: allow DEBUG_IO for !QEMU

[Laszlo Ersek]

On 05/31/13 03:09, Kevin O'Connor wrote:
 On Thu, May 30, 2013 at 09:30:33AM +0200, Gerd Hoffmann wrote:
 On 05/30/13 03:34, Kevin O'Connor wrote:
 On Wed, May 29, 2013 at 04:25:59PM +0200, Gerd Hoffmann wrote:
 Allow selecting DEBUG_IO for non-qemu configurations,
 which is useful when running coreboot+seabios on qemu.

 Unfortunately, if one does run seabios on real hardware and has
 DEBUG_IO enabled, it will write to IO port 0x402 before confirming
 that it is actually running on QEMU.  This could cause mysterious
 failures on real hardware if something is listening to that port.
 It's why I left the option dependent on QEMU instead of QEMU_HARDWARE.
 Ideally the code would verify it is on QEMU before using the IO port,
 while still providing the very early debugging when it is known to be
 safe.

 The debgconsole port returns 0xe9 on reads, so we could use that for
 probing and do something like the attached patch.  Which doesn't build
 for some reason.  Is the F segment read-only in 16bit mode?  Should I
 use something else instead?  Or #ifdef the SET_GLOBAL for 32bit mode,
 which should work fine given that POST runs in 32bit mode?
 
 Same problem - one can't reliably do an inb(0xe9) on real hardware
 without risking mysterious failures.

This entire problem seems to exist only if someone runs a SeaBIOS binary
on real hardware that was configured like:
- COREBOOT or CSM (ie. not QEMU),
- and QEMU_HARDWARE.

Why would someone set QEMU_HARDWARE (Support hardware found on
emulators) for a binary intended to run on real hardware?

In the rest of src/Kconfig, the following options depend on QEMU_HARDWARE:
- VIRTIO_BLK
- VIRTIO_SCSI
- ESP_SCSI
- LSI_SCSI

The first two clearly don't make sense on bare metal. The last two might
(no idea), but if that's the case, then their dependency on emulated
hardware is wrong.

We need a way to say in Kconfig, this is a CSM build specifically meant
for emulators, and CONFIG_CSM + QEMU_HARDWARE looks like an ideal
candidate. People building for bare metal shouldn't (need to) set
QEMU_HARDWARE.

Alternatively, we need code that can run in 16-bit mode (consequently,
without writing any globals) and that can identify *any* of the
supported hypervisors. PlatformRunningOn is too late. KVM and Xen
could be covered by cpuid() (*), but this approach is a pain because a
single patch would have to add detection for all supported hypervisors
at once.

(*) I checked the SDM and also there's code like this out there, eg.
http://lkml.indiana.edu/hypermail/linux/kernel/0705.0/0019.html.

What if we replace the inb() in the proposed patch with a cpuid call
that detects only KVM, as first step? On KVM it would do the right
thing, on bare metal, ditto. On other hypervisors it would err towards
safety and could be extended later. What do you think?

Thanks,
Laszlo

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

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

[Laszlo Ersek]

On 05/31/13 15:04, Anthony Liguori wrote:
 Laszlo Ersek ler...@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


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

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

[Laszlo Ersek]

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


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

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

[Anthony Liguori]

Laszlo Ersek ler...@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

___
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 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?

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

[David Woodhouse]

On Wed, 2013-05-29 at 21:12 -0400, Kevin O'Connor wrote:
 
 I remain doubtful that QOM has all the info needed to generate the
 BIOS tables.  Does QOM describe how the 5th pci device uses global
 interrupt 11 when using global interrupts, legacy interrupt 5 when not
 using global interrupts, and that the legacy interrupt can be changed
 by writing to the 0x60 address of the 1st pci device's config space?
 Does QOM state that the machine supports S3 sleep mode?  Does QOM
 indicate that an IPMI device supports the 3rd version of the IPMI
 device specification?

Does it indicate whether this particular version of qemu has correctly
implemented the hard reset at 0xcf9? If so, we need to put that in as
the ACPI RESET_REG.

It seems that there's a *lot* which isn't fully described in the QOM
tree. Do we really want to add it all, just so that ACPI tables can be
reliably generated from it? 

As we add new types of hardware and even fix/adjust features like the
examples above, we'll also have to implement the translation from QOM to
ACPI tables. And we'll have to do so in more than one place, in projects
with a completely different release cycle. This would be *so* much
easier if the code which actually generates the ACPI tables was *in* the
qemu tree along with the hardware that those tables describe.

-- 
dwmw2


smime.p7s
Description: S/MIME cryptographic signature
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

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

[Laszlo Ersek]

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

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

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

[Laszlo Ersek]

On 05/31/13 17:43, Anthony Liguori wrote:
 David Woodhouse dw...@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

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

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

[Laszlo Ersek]

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

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

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

[Anthony Liguori]

David Woodhouse dw...@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

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

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

[Paolo Bonzini]

Il 31/05/2013 19:06, Anthony Liguori ha scritto:
 David Woodhouse dw...@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

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

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

[Anthony Liguori]

Paolo Bonzini pbonz...@redhat.com writes:

 Il 31/05/2013 19:06, Anthony Liguori ha scritto:
 David Woodhouse dw...@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

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

Re: [SeaBIOS] [QEMU PATCH v3] qdev: fix get_fw_dev_path to support to add nothing to fw_dev_path

[Anthony Liguori]

Applied.  Thanks.

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

[Jordan Justen]

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

[Anthony Liguori]

Jordan Justen jljus...@gmail.com writes:

 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?

We did this in git pre-history, now git has a fancy git-filter-branch
command that makes it a breeze:

http://git-scm.com/book/ch6-4.html

Regards,

Anthony Liguori


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

[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 dw...@infradead.org
 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] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one

[Kevin O'Connor]

On Fri, May 31, 2013 at 08:32:16AM -0500, Dave Frodin wrote:
 I see now, that's pretty slick. The problem I see with that approach is
 that coreboot would need to add all of these files for a family14 mainboard.
[...]
 And all of these files for a family15 mainboard
[...]
 
 Since at build time we only know what cpu family the rom is being
 built for and not (necessarily) what the exact graphics ID is.
 
 The method I proposed would have one family specific vendev-map.bin file.

Yes, but it would be quite difficult to inspect vendev-map.bin.  I
think an ascii interface is preferable.

One could go a level up and make a symbolic link type in cbfs (this
is effectively what my patch did).  The advantage would be that
cbfstool could display it in a nicer format.

-Kevin

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

Re: [SeaBIOS] [PATCH v3] config: allow DEBUG_IO for !QEMU

[Kevin O'Connor]

On Fri, May 31, 2013 at 03:30:48PM +0200, Laszlo Ersek wrote:
 On 05/31/13 03:09, Kevin O'Connor wrote:
  Same problem - one can't reliably do an inb(0xe9) on real hardware
  without risking mysterious failures.
 
 This entire problem seems to exist only if someone runs a SeaBIOS binary
 on real hardware that was configured like:
 - COREBOOT or CSM (ie. not QEMU),
 - and QEMU_HARDWARE.
 
 Why would someone set QEMU_HARDWARE (Support hardware found on
 emulators) for a binary intended to run on real hardware?

It's common to build seabios with all options enabled and let seabios
auto-detect what it can use.  That's the intent of QEMU_HARDWARE - it
allows one to compile in more drivers and seabios will use them if it
detects the corresponding hardware.  This does not obviate the need
for proper hardware detection though.

If this goes wrong on real hardware, it could require a lengthy
session with a soldering iron to fix it.  People don't like that.

[...]
 What if we replace the inb() in the proposed patch with a cpuid call
 that detects only KVM, as first step? On KVM it would do the right
 thing, on bare metal, ditto. On other hypervisors it would err towards
 safety and could be extended later. What do you think?

The plan was to detect qemu on coreboot via the mainboard vendor/part
info that coreboot generates.  The plan on uefi was to use the smbios
tables to detect qemu.  Once detection is in place, the DEBUG_IO
support could be made dependent on QEMU_HARDWARE and only activated
after detection succeeds.

-Kevin

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

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

[Kevin O'Connor]

On Fri, May 31, 2013 at 10:13:34AM +0200, Peter Stuge wrote:
 Kevin O'Connor wrote:
  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.
 
 qvmloader sounds a lot like coreboot.

Agreed.  I don't much like the qvmloader idea.  I did want to open up
discussion on the possibility, however.  The only advantage it has
over coreboot is that it could reasonably live in the qemu repo, and I
do think that the hardware descriptions should like in the same code
repo as the hardware implementation.

-Kevin

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