Hi,

Ok, we want for varios reasons separate the firmware from the main
qemu repo.  Here is my attempt to create such a repo.  For starters
only seabios has been added here.

You can find the repo with currently three patches here:
    https://www.kraxel.org/cgit/qemu-firmware/

This "series" is only patch #2 of the repo.  Havn't found a way to
convince git-format-patch to include the initial commit of a repo.
But patch #1 (the initial commit) only adds the seabios submodule,
patch #3 adds the binary blobs, so patch #2 actually is the most
interesting one.

Comments?

cheers,
  Gerd

Gerd Hoffmann (1):
  add Makefile, add configs for seabios

 Makefile             | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 configs/seabios-128k | 12 ++++++++
 configs/seabios-256k |  3 ++
 configs/vga-cirrus   |  3 ++
 configs/vga-isavga   |  3 ++
 configs/vga-qxl      |  6 ++++
 configs/vga-stdvga   |  3 ++
 configs/vga-virtio   |  6 ++++
 configs/vga-vmware   |  6 ++++
 9 files changed, 122 insertions(+)
 create mode 100644 Makefile
 create mode 100644 configs/seabios-128k
 create mode 100644 configs/seabios-256k
 create mode 100644 configs/vga-cirrus
 create mode 100644 configs/vga-isavga
 create mode 100644 configs/vga-qxl
 create mode 100644 configs/vga-stdvga
 create mode 100644 configs/vga-virtio
 create mode 100644 configs/vga-vmware

-- 
2.9.3

On 26/09/2017 13:17, Gerd Hoffmann wrote:
> 
> Ok, we want for varios reasons separate the firmware from the main
> qemu repo.  Here is my attempt to create such a repo.  For starters
> only seabios has been added here.
> 
> You can find the repo with currently three patches here:
>     https://www.kraxel.org/cgit/qemu-firmware/
> 
> This "series" is only patch #2 of the repo.  Havn't found a way to
> convince git-format-patch to include the initial commit of a repo.
> But patch #1 (the initial commit) only adds the seabios submodule,
> patch #3 adds the binary blobs, so patch #2 actually is the most
> interesting one.

Are you planning to include only submodules, or also "QEMU-native"
firmware such as linuxboot, kvmvapic, s390-ccw, spapr-rtas, etc.?

Thanks,

Paolo

On Wed, 2017-09-27 at 09:19 +0200, Paolo Bonzini wrote:
> On 26/09/2017 13:17, Gerd Hoffmann wrote:
> > 
> > Ok, we want for varios reasons separate the firmware from the main
> > qemu repo.  Here is my attempt to create such a repo.  For starters
> > only seabios has been added here.
> > 
> > You can find the repo with currently three patches here:
> >     https://www.kraxel.org/cgit/qemu-firmware/
> > 
> > This "series" is only patch #2 of the repo.  Havn't found a way to
> > convince git-format-patch to include the initial commit of a repo.
> > But patch #1 (the initial commit) only adds the seabios submodule,
> > patch #3 adds the binary blobs, so patch #2 actually is the most
> > interesting one.
> 
> Are you planning to include only submodules, or also "QEMU-native"
> firmware such as linuxboot, kvmvapic, s390-ccw, spapr-rtas, etc.?

The submodules are my priority.

I think it makes sense for all firmware where we have pre-built
binaries committed to the qemu repo, even if the source is in the qemu
repo too.  But maybe it's easier to keep those in qemu.  They tend to
be small and they are also not problematic license-wise.

cheers,
  Gerd

On Wed, Sep 27, 2017 at 09:19:22AM +0200, Paolo Bonzini wrote:
> On 26/09/2017 13:17, Gerd Hoffmann wrote:
> > 
> > Ok, we want for varios reasons separate the firmware from the main
> > qemu repo.  Here is my attempt to create such a repo.  For starters
> > only seabios has been added here.
> > 
> > You can find the repo with currently three patches here:
> >     https://www.kraxel.org/cgit/qemu-firmware/
> > 
> > This "series" is only patch #2 of the repo.  Havn't found a way to
> > convince git-format-patch to include the initial commit of a repo.
> > But patch #1 (the initial commit) only adds the seabios submodule,
> > patch #3 adds the binary blobs, so patch #2 actually is the most
> > interesting one.
> 
> Are you planning to include only submodules, or also "QEMU-native"
> firmware such as linuxboot, kvmvapic, s390-ccw, spapr-rtas, etc.?

The submodules make sense to split out because distro vendors buld them
independently of QEMU, and would rather not have them in the tarballs,
so they have a clearer path to license compliance and legal export
certification.

The other bits of mention are all built normally as part of QEMU and
not subject to these problems, so I don't see a benefit to splitting
them out of QEMU. In fact putting those bits in the qemu-firmware
repo would re-introduce the problem we're trying to solve because
distros would then need to get linuxboox, kvmvapi etc from a tarball
of qemu-firmware which would once again include all the bits they
don't want to have.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

  Hi,

> The other bits of mention are all built normally as part of QEMU and
> not subject to these problems,

Sure?  As far I know no firmware is build automatically as cross
compilers might be needed to do that for guest arch != host arch.

But yes, we don't have licensing issues (we ship the sources too),
so keeping them in the main repo isn't that a big issue.

cheers,
  Gerd

On 27/09/2017 11:15, Daniel P. Berrange wrote:
> On Wed, Sep 27, 2017 at 09:19:22AM +0200, Paolo Bonzini wrote:
>> Are you planning to include only submodules, or also "QEMU-native"
>> firmware such as linuxboot, kvmvapic, s390-ccw, spapr-rtas, etc.?
> 
> The submodules make sense to split out because distro vendors buld them
> independently of QEMU, and would rather not have them in the tarballs,
> so they have a clearer path to license compliance and legal export
> certification.
> 
> The other bits of mention are all built normally as part of QEMU and
> not subject to these problems, so I don't see a benefit to splitting
> them out of QEMU.

They aren't rebuilt in general.  You end up with x86 builds of
qemu-system-x86 rebuilding linuxboot, ppc builds of qemu-system-ppc
rebuilding spapr-rtas, etc. (search configure for "roms=").  In fact,
QEMU has a special exception in Fedora just because these are too hard
to untangle.

So the advantage would be the ability to introduce better infrastructure
for cross compilation, without complicating further the QEMU build system.

> putting those bits in the qemu-firmware
> repo would re-introduce the problem we're trying to solve because
> distros would then need to get linuxboox, kvmvapi etc from a tarball
> of qemu-firmware which would once again include all the bits they
> don't want to have.

This is true.  We could distribute a qemu-firmware tarball with just the
QEMU-specific bits, and a qemu-firmware-all tarball with also those that
are built separately.

Paolo

On Wed, Sep 27, 2017 at 01:34:12PM +0200, Paolo Bonzini wrote:
> On 27/09/2017 11:15, Daniel P. Berrange wrote:
> > On Wed, Sep 27, 2017 at 09:19:22AM +0200, Paolo Bonzini wrote:
> >> Are you planning to include only submodules, or also "QEMU-native"
> >> firmware such as linuxboot, kvmvapic, s390-ccw, spapr-rtas, etc.?
> > 
> > The submodules make sense to split out because distro vendors buld them
> > independently of QEMU, and would rather not have them in the tarballs,
> > so they have a clearer path to license compliance and legal export
> > certification.
> > 
> > The other bits of mention are all built normally as part of QEMU and
> > not subject to these problems, so I don't see a benefit to splitting
> > them out of QEMU.
> 
> They aren't rebuilt in general.  You end up with x86 builds of
> qemu-system-x86 rebuilding linuxboot, ppc builds of qemu-system-ppc
> rebuilding spapr-rtas, etc. (search configure for "roms=").  In fact,
> QEMU has a special exception in Fedora just because these are too hard
> to untangle.
> 
> So the advantage would be the ability to introduce better infrastructure
> for cross compilation, without complicating further the QEMU build system.

Ah I see.

> 
> > putting those bits in the qemu-firmware
> > repo would re-introduce the problem we're trying to solve because
> > distros would then need to get linuxboox, kvmvapi etc from a tarball
> > of qemu-firmware which would once again include all the bits they
> > don't want to have.
> 
> This is true.  We could distribute a qemu-firmware tarball with just the
> QEMU-specific bits, and a qemu-firmware-all tarball with also those that
> are built separately.

Yep, as long as there's a tarball for the QEMU bits that does not
contain the 3rd party bits, that would work.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|