vgabios and other guest related firmware

vgabios and other guest related firmware

[Carlo Marcelo Arenas Belon]

Avi,

now that vgabios has been merged, would be probably a good idea to remove the
unused vgabios BLOBs in the bios directory which were left from the import of 
the BOCHS bios (I have a patch but felt bad about sending it out with up to
96K) :

  bios/VGABIOS-lgpl-README              |  214
  bios/VGABIOS-lgpl-latest              |  Bin 38400 -> 0 bytes
  bios/VGABIOS-lgpl-latest-cirrus       |  Bin 35328 -> 0 bytes
  bios/VGABIOS-lgpl-latest-cirrus-debug |  Bin 35840 -> 0 bytes
  bios/VGABIOS-lgpl-latest-debug        |  Bin 39936 -> 0 bytes

in preparation for portability work, I suspect though might be a good idea to
create a "firmware" tree were other firmware might be later added to support
the non-PC architectures like ppc, ia64 and others that seem to be imminent.

I'll let the specifics to all the portability interested parties (I mostly use
PC) but would suspect something similar to the work done for the code should
be most likely what is needed :

  firmware -- x86 -- bios
           |      |- vgabios
           |- ia64
           ..

Carlo

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: vgabios and other guest related firmware

[Zhang, Xiantao]

Carlo Marcelo Arenas Belon wrote:
> Avi,
> 
> now that vgabios has been merged, would be probably a good idea to
> remove the unused vgabios BLOBs in the bios directory which were left
> from the import of the BOCHS bios (I have a patch but felt bad about
> sending it out with up to 96K) :
> 
>   bios/VGABIOS-lgpl-README              |  214
>   bios/VGABIOS-lgpl-latest              |  Bin 38400 -> 0 bytes
>   bios/VGABIOS-lgpl-latest-cirrus       |  Bin 35328 -> 0 bytes
>   bios/VGABIOS-lgpl-latest-cirrus-debug |  Bin 35840 -> 0 bytes
>   bios/VGABIOS-lgpl-latest-debug        |  Bin 39936 -> 0 bytes
> 
> in preparation for portability work, I suspect though might be a good
> idea to create a "firmware" tree were other firmware might be later
> added to support the non-PC architectures like ppc, ia64 and others
> that seem to be imminent. 
> 
> I'll let the specifics to all the portability interested parties (I
> mostly use PC) but would suspect something similar to the work done
> for the code should be most likely what is needed :
> 
>   firmware -- x86 -- bios
>            |      |- vgabios
>            |- ia64

Good idea! We also need to upload the ia64 firmware for kvm, and make it
available for users use. At least, we need to provide the binary. 
BTW, current ia64 binary has 2M size, is it OK to upload it to
kvm-source tree ?
Xiantao 

> 
>
------------------------------------------------------------------------
-
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> kvm-devel mailing list
> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: vgabios and other guest related firmware

[Carlo Marcelo Arenas Belon]

On Wed, Jan 02, 2008 at 04:14:53PM +0800, Zhang, Xiantao wrote:
> Carlo Marcelo Arenas Belon wrote:
> > 
> > I'll let the specifics to all the portability interested parties (I
> > mostly use PC) but would suspect something similar to the work done
> > for the code should be most likely what is needed :
> > 
> >   firmware -- x86 -- bios
> >            |      |- vgabios
> >            |- ia64
> 
> Good idea!

this was meant to be for the source files of the firmware that is needed
for each guest architecture, just like is being done now for x86 (both i386
and x86_64) with bios and vgabios.

for ia64 it will most likely include the opensource EFI firmware imported
and plus any needed patches to make it work perfectly with kvm.

> We also need to upload the ia64 firmware for kvm, and make it
> available for users use. At least, we need to provide the binary. 

beware that actually providing the binary without sources might be a problem
for some distributions (like debian and derivatives like ubuntu).

most likely getting the sources and a makefile which could be used to build
the binary and copy it to the qemu/pc-bios/ directory, at release time or when
the sources had been changed and it needs to be rebuilt, and for convenience
so it can be distributed with the release tar.gz will be preferred.

for hints on how to get that look at the Makefiles in the bios or vgabios top
level directories and the top level Makefile

> BTW, current ia64 binary has 2M size, is it OK to upload it to
> kvm-source tree ?

if you are talking about the binary only, EFI BIOS from Intel, then it could
be problematic (because of the free software guidelines of some distributions)
and of course will need to have also some sort of README file clearly
specifying that the license allows for re-distribution and can be used at least
together with kvm (like the ELPIN vga bios was licensed for BOCHS)

IMHO is probably better to use only the GPL version with sources and
distribute that with kvm source packages and let the users or distributions
to manage the distribution/installation of BLOBs otherwise as that keeps the
lawyers from distracting us from the interesting technical issues.

Carlo 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: vgabios and other guest related firmware

[Avi Kivity]

Carlo Marcelo Arenas Belon wrote:
>
>> We also need to upload the ia64 firmware for kvm, and make it
>> available for users use. At least, we need to provide the binary. 
>>     
>
> beware that actually providing the binary without sources might be a problem
> for some distributions (like debian and derivatives like ubuntu).
>
> most likely getting the sources and a makefile which could be used to build
> the binary and copy it to the qemu/pc-bios/ directory, at release time or when
> the sources had been changed and it needs to be rebuilt, and for convenience
> so it can be distributed with the release tar.gz will be preferred.
>
> for hints on how to get that look at the Makefiles in the bios or vgabios top
> level directories and the top level Makefile
>
>   

Note that we ship x86 binaries for two reasons:
- qemu does it that way, and we inherited it, before the need arose to 
make modifications
- obscure tools are needed to build the binaries (iasl and dev86)

Since ia64 doesn't have these issues (is that right?) then we can 
probably do a source-only release.

>> BTW, current ia64 binary has 2M size, is it OK to upload it to
>> kvm-source tree ?
>>     
>
> if you are talking about the binary only, EFI BIOS from Intel, then it could
> be problematic (because of the free software guidelines of some distributions)
> and of course will need to have also some sort of README file clearly
> specifying that the license allows for re-distribution and can be used at least
> together with kvm (like the ELPIN vga bios was licensed for BOCHS)
>
> IMHO is probably better to use only the GPL version with sources and
> distribute that with kvm source packages and let the users or distributions
> to manage the distribution/installation of BLOBs otherwise as that keeps the
> lawyers from distracting us from the interesting technical issues.
>   

I agree, let's avoid binary-only components if possible.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: vgabios and other guest related firmware

[Zhang, Xiantao]

Avi Kivity wrote:
> Carlo Marcelo Arenas Belon wrote:
>> 
>>> We also need to upload the ia64 firmware for kvm, and make it
>>> available for users use. At least, we need to provide the binary.
>>> 
>> 
>> beware that actually providing the binary without sources might be a
>> problem for some distributions (like debian and derivatives like
>> ubuntu). 
>> 
>> most likely getting the sources and a makefile which could be used
>> to build the binary and copy it to the qemu/pc-bios/ directory, at
>> release time or when the sources had been changed and it needs to be
>> rebuilt, and for convenience so it can be distributed with the
>> release tar.gz will be preferred. 
>> 
>> for hints on how to get that look at the Makefiles in the bios or
>> vgabios top level directories and the top level Makefile
>> 
>> 
> 
> Note that we ship x86 binaries for two reasons:
> - qemu does it that way, and we inherited it, before the need arose to
> make modifications
> - obscure tools are needed to build the binaries (iasl and dev86)
> 
> Since ia64 doesn't have these issues (is that right?) then we can
> probably do a source-only release.

Ia64 firmware build need edk tools(very big package), and very hard to
setup the environment correclty.  And it is not friendly to users :(
Maybe binary is also needed. 
Xiantao


>>> BTW, current ia64 binary has 2M size, is it OK to upload it to
>>> kvm-source tree ? 
>>> 
>> 
>> if you are talking about the binary only, EFI BIOS from Intel, then
>> it could be problematic (because of the free software guidelines of
>> some distributions) and of course will need to have also some sort
>> of README file clearly specifying that the license allows for
>> re-distribution and can be used at least together with kvm (like the
>> ELPIN vga bios was licensed for BOCHS) 
>> 
>> IMHO is probably better to use only the GPL version with sources and
>> distribute that with kvm source packages and let the users or
>> distributions 
>> to manage the distribution/installation of BLOBs otherwise as that
>> keeps the lawyers from distracting us from the interesting technical
>> issues. 
>> 
> 
> I agree, let's avoid binary-only components if possible.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: vgabios and other guest related firmware

[Avi Kivity]

Zhang, Xiantao wrote:
>>
>> Note that we ship x86 binaries for two reasons:
>> - qemu does it that way, and we inherited it, before the need arose to
>> make modifications
>> - obscure tools are needed to build the binaries (iasl and dev86)
>>
>> Since ia64 doesn't have these issues (is that right?) then we can
>> probably do a source-only release.
>>     
>
> Ia64 firmware build need edk tools(very big package), and very hard to
> setup the environment correclty.  And it is not friendly to users :(
> Maybe binary is also needed. 
>   

In that case, we can do source+binary distribution like x86.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: vgabios and other guest related firmware

[Zhang, Xiantao]

Avi Kivity wrote:
> Zhang, Xiantao wrote:
>>> 
>>> Note that we ship x86 binaries for two reasons:
>>> - qemu does it that way, and we inherited it, before the need arose
>>> to make modifications 
>>> - obscure tools are needed to build the binaries (iasl and dev86)
>>> 
>>> Since ia64 doesn't have these issues (is that right?) then we can
>>> probably do a source-only release.
>>> 
>> 
>> Ia64 firmware build need edk tools(very big package), and very hard
>> to setup the environment correclty.  And it is not friendly to users
>> :( Maybe binary is also needed. 
>> 
> 
> In that case, we can do source+binary distribution like x86.

OK, maybe we can include basic source in kvm source tree, and let user
download EDK tools from tiano website at build time. It should be more
accepted, since basic souce package is not so big:)
Xiantao

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: vgabios and other guest related firmware

[Carlo Marcelo Arenas Belon]

On Wed, Jan 02, 2008 at 05:46:04PM +0800, Zhang, Xiantao wrote:
> Avi Kivity wrote:
> > Carlo Marcelo Arenas Belon wrote:
> >> 
> >>> We also need to upload the ia64 firmware for kvm, and make it
> >>> available for users use. At least, we need to provide the binary.
> >> 
> >> beware that actually providing the binary without sources might be a
> >> problem for some distributions (like debian and derivatives like
> >> ubuntu). 
> >> 
> >> most likely getting the sources and a makefile which could be used
> >> to build the binary and copy it to the qemu/pc-bios/ directory, at
> >> release time or when the sources had been changed and it needs to be
> >> rebuilt, and for convenience so it can be distributed with the
> >> release tar.gz will be preferred. 
> >> 
> >> for hints on how to get that look at the Makefiles in the bios or
> >> vgabios top level directories and the top level Makefile
> > 
> > Note that we ship x86 binaries for two reasons:
> > - qemu does it that way, and we inherited it, before the need arose to
> > make modifications
> > - obscure tools are needed to build the binaries (iasl and dev86)
> > 
> > Since ia64 doesn't have these issues (is that right?) then we can
> > probably do a source-only release.
> 
> Ia64 firmware build need edk tools(very big package), and very hard to
> setup the environment correclty.  And it is not friendly to users :(

you wouldn't expect users to rebuild the firmware, but distributions or the
providers of the binaries and that have the environment needed, because they
are also the ones working with the sources.

are you referring to this edk? 

  https://edk.tianocore.org/

> Maybe binary is also needed.

Just because the binary is very difficult to make, shouldn't prevent importing
the sources if they are available under a compatible opensource license and
they had been modified to work with KVM.

of course it should preclude the build to try to generate the binary by
default just like it does now for bios and vgabios, so that final users that
don't care can just use the already generated binaries for convenience.

if the binary hasn't been modified and corresponds to some known release which
is publicly available and is licensed for public redistribution in a way
that is compatible with kvm's licenses then it could be imported.

but even in that case would be probably better to let the distributors or
users to handle that for themselves and avoid all the legalese IMHO.

Carlo

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: vgabios and other guest related firmware

[Zhang, Xiantao]

Carlo Marcelo Arenas Belon wrote:
> On Wed, Jan 02, 2008 at 04:14:53PM +0800, Zhang, Xiantao wrote:
>> Carlo Marcelo Arenas Belon wrote:
>>> 
>>> I'll let the specifics to all the portability interested parties (I
>>> mostly use PC) but would suspect something similar to the work done
>>> for the code should be most likely what is needed :
>>> 
>>>   firmware -- x86 -- bios
>>>            |      |- vgabios
>>>            |- ia64
>> 
>> Good idea!
> 
> this was meant to be for the source files of the firmware that is
> needed 
> for each guest architecture, just like is being done now for x86
> (both i386 and x86_64) with bios and vgabios.
> 
> for ia64 it will most likely include the opensource EFI firmware
> imported 
> and plus any needed patches to make it work perfectly with kvm.
> 
>> We also need to upload the ia64 firmware for kvm, and make it
>> available for users use. At least, we need to provide the binary.
> 
> beware that actually providing the binary without sources might be a
> problem for some distributions (like debian and derivatives like
> ubuntu). 
> 
> most likely getting the sources and a makefile which could be used to
> build the binary and copy it to the qemu/pc-bios/ directory, at
> release time or when the sources had been changed and it needs to be
> rebuilt, and for convenience so it can be distributed with the
> release tar.gz will be preferred. 
> 
> for hints on how to get that look at the Makefiles in the bios or
> vgabios top level directories and the top level Makefile
> 
>> BTW, current ia64 binary has 2M size, is it OK to upload it to
>> kvm-source tree ?
> 
> if you are talking about the binary only, EFI BIOS from Intel, then
> it could be problematic (because of the free software guidelines of
> some distributions) and of course will need to have also some sort of
> README file clearly specifying that the license allows for
> re-distribution and can be used at least together with kvm (like the
> ELPIN vga bios was licensed for BOCHS) 

I am talking about the open source guest firmware. Since it is hard to
setup build environment for users, so I want to adds an binary in
kvm-source package(release version) in future.  Of course,  it is great
to include the whole firmware source in the tree, but seems it is big if
we includes EDK tools. 

> IMHO is probably better to use only the GPL version with sources and
> distribute that with kvm source packages and let the users or
> distributions 
> to manage the distribution/installation of BLOBs otherwise as that
> keeps the lawyers from distracting us from the interesting technical
> issues. 
> 
> Carlo


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: vgabios and other guest related firmware

[Avi Kivity]

Carlo Marcelo Arenas Belon wrote:
> Avi,
>
> now that vgabios has been merged, would be probably a good idea to remove the
> unused vgabios BLOBs in the bios directory which were left from the import of 
> the BOCHS bios (I have a patch but felt bad about sending it out with up to
> 96K) :
>
>   bios/VGABIOS-lgpl-README              |  214
>   bios/VGABIOS-lgpl-latest              |  Bin 38400 -> 0 bytes
>   bios/VGABIOS-lgpl-latest-cirrus       |  Bin 35328 -> 0 bytes
>   bios/VGABIOS-lgpl-latest-cirrus-debug |  Bin 35840 -> 0 bytes
>   bios/VGABIOS-lgpl-latest-debug        |  Bin 39936 -> 0 bytes
>
>   

A git patch would have been quite small.  Anyway, I removed the files.

> in preparation for portability work, I suspect though might be a good idea to
> create a "firmware" tree were other firmware might be later added to support
> the non-PC architectures like ppc, ia64 and others that seem to be imminent.
>
> I'll let the specifics to all the portability interested parties (I mostly use
> PC) but would suspect something similar to the work done for the code should
> be most likely what is needed :
>
>   firmware -- x86 -- bios
>            |      |- vgabios
>            |- ia64
>            ..
>   

While this is a good suggestion, the mechanics of the cvs import -> git 
conversion are nasty enough for me not to want to change things.

New firmware can certainly go into the new directory as you suggest.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/