[Qemu-devel] [PATCH 0/4][RFC] Bring ROM source into tree via git submodules

[Qemu-devel] [PATCH 0/4][RFC] Bring ROM source into tree via git submodules

[Anthony Liguori]

This series is still a work in progress but I wanted to get some feedback on
the general idea.

Today we ship ROMs that are required for guests to execute properly.  These ROMs
are target specific and consist of target code that runs in the guest's context.

Because these ROMs require target-specific toolchains, we include binary copies.
In some cases, cross compilers aren't available.

The ROMs we ship are not easily reproducible today.  Some are better documented
than others.  Distributions typically have a hard requirement that they must
build all of their binaries from source.  Since we don't distribute the source
for these projects, this has led to all sorts of packaging related problems.

I would like to make the ROMs we ship buildable via the QEMU make system.  I
still want to include binary ROMs but I want the building of the ROMs we ship to
be a one step process.

This series adds git submodules for the BIOS and VGABIOS we use for QEMU.  I've
setup trees on repo.or.cz that contain the changes we make to each of these
projects.  The trees are derived from scripts originally written by Avi that
among other things, extract out the bios/ directory from the Bochs project.

If you do a normal git clone of the QEMU tree, you don't automatically checkout
the submodules.  To do that, you have to run an explicit git submodule update
command.  This should make the workflow for most people identical to what it
is today.

I'd like to make the Makefile logic smarter such that it always installed roms
that it builds whenever the right tool chain is available.  Distributions would
just make use of --disable-blobs and would not need additional packages for
etherboot, bochs bios, etc.

[Qemu-devel] [PATCH 1/4] Add GPL bios as a submodule

[Anthony Liguori]

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
---
 .gitmodules  |    3 +++
 roms/gplbios |    1 +
 2 files changed, 4 insertions(+), 0 deletions(-)
 create mode 100644 .gitmodules
 create mode 160000 roms/gplbios

diff --git a/.gitmodules b/.gitmodules
new file mode 100644
index 0000000..9bdf196
--- /dev/null
+++ b/.gitmodules
@@ -0,0 +1,3 @@
+[submodule "roms/gplbios"]
+	path = roms/gplbios
+	url = git://repo.or.cz/gplbios/qemu.git
diff --git a/roms/gplbios b/roms/gplbios
new file mode 160000
index 0000000..ff509b4
--- /dev/null
+++ b/roms/gplbios
@@ -0,0 +1 @@
+Subproject commit ff509b44010d161e8202ee4c0b6f3ca463672bca
-- 
1.6.2.5

[Qemu-devel] Re: [PATCH 1/4] Add GPL bios as a submodule

[Avi Kivity]

Anthony Liguori wrote:
> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
> ---
>  .gitmodules  |    3 +++
>  roms/gplbios |    1 +
>  2 files changed, 4 insertions(+), 0 deletions(-)
>  create mode 100644 .gitmodules
>  create mode 160000 roms/gplbios
>
> diff --git a/.gitmodules b/.gitmodules
> new file mode 100644
> index 0000000..9bdf196
> --- /dev/null
> +++ b/.gitmodules
> @@ -0,0 +1,3 @@
> +[submodule "roms/gplbios"]
> +	path = roms/gplbios
> +	url = git://repo.or.cz/gplbios/qemu.git
>   

I really prefer a relative path here, so that people can set up mirrors 
on an internal server.  Also, not everyone can access the git port.  It 
can be worked around, but it's much better to have things working out of 
the proverbial box.

Also, s/roms/firmware/ to be modern.

Having said all that, I'd rather see seabios here.  Sure, it will take 
us time to add missing features, if any, but life will be much more 
pleasant afterwards.  We should reduce our ties to the bochs bios, not 
tighten them.

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

[Qemu-devel] Re: [PATCH 1/4] Add GPL bios as a submodule

[Anthony Liguori]

Avi Kivity wrote:
> Anthony Liguori wrote:
>> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
>> ---
>>  .gitmodules  |    3 +++
>>  roms/gplbios |    1 +
>>  2 files changed, 4 insertions(+), 0 deletions(-)
>>  create mode 100644 .gitmodules
>>  create mode 160000 roms/gplbios
>>
>> diff --git a/.gitmodules b/.gitmodules
>> new file mode 100644
>> index 0000000..9bdf196
>> --- /dev/null
>> +++ b/.gitmodules
>> @@ -0,0 +1,3 @@
>> +[submodule "roms/gplbios"]
>> +    path = roms/gplbios
>> +    url = git://repo.or.cz/gplbios/qemu.git
>>   
>
> I really prefer a relative path here, so that people can set up 
> mirrors on an internal server.  Also, not everyone can access the git 
> port.  It can be worked around, but it's much better to have things 
> working out of the proverbial box.

Do you also include a way to automatically setup the relative path?  
Otherwise, it's a multi-step process for someone to fetch all of the git 
trees for building.

We have a lot of ROMs, so this is potentially very undesirable.  People 
can always make local changes to the .gitmodules file.

> Also, s/roms/firmware/ to be modern.

ROM is a little more specific in my mind.  We had a long debate in IRC 
as to what was appropriate to include in pc-bios.  One key requirement 
is that whatever is there has to be a ROM because of the fact that we 
install it in a read-only location in the file system.

On embedded boards, the entire operating system stack constitutes 
"firmware".

> Having said all that, I'd rather see seabios here.  Sure, it will take 
> us time to add missing features, if any, but life will be much more 
> pleasant afterwards.  We should reduce our ties to the bochs bios, not 
> tighten them.

Actually, I want to include seabios in here too and install it by default.

There's already a -bios option that can be used to change the bios file 
name.  After some basic testing, we can decide whether we should change 
the default bios we use.  With both installed, it's easier to have 
people check for bugs in one verse the other.

-- 
Regards,

Anthony Liguori

[Qemu-devel] Re: [PATCH 1/4] Add GPL bios as a submodule

[Avi Kivity]

Anthony Liguori wrote:
>> I really prefer a relative path here, so that people can set up 
>> mirrors on an internal server.  Also, not everyone can access the git 
>> port.  It can be worked around, but it's much better to have things 
>> working out of the proverbial box.
>
> Do you also include a way to automatically setup the relative path?  
> Otherwise, it's a multi-step process for someone to fetch all of the 
> git trees for building.

I don't understand the question.  The relative path is set up once (in 
.gitmodules), and that's it.

Look at kvm-kmod.git for an example.

>
> We have a lot of ROMs, so this is potentially very undesirable.  
> People can always make local changes to the .gitmodules file.

Not if they're a mirror.

>
>> Also, s/roms/firmware/ to be modern.
>
> ROM is a little more specific in my mind.  We had a long debate in IRC 
> as to what was appropriate to include in pc-bios.  One key requirement 
> is that whatever is there has to be a ROM because of the fact that we 
> install it in a read-only location in the file system.
>
> On embedded boards, the entire operating system stack constitutes 
> "firmware".

I'm not sure I agree, but we have more pressing subjects to bikeshed.

>> Having said all that, I'd rather see seabios here.  Sure, it will 
>> take us time to add missing features, if any, but life will be much 
>> more pleasant afterwards.  We should reduce our ties to the bochs 
>> bios, not tighten them.
>
> Actually, I want to include seabios in here too and install it by 
> default.
>
> There's already a -bios option that can be used to change the bios 
> file name.  After some basic testing, we can decide whether we should 
> change the default bios we use.  With both installed, it's easier to 
> have people check for bugs in one verse the other.

Let's only include seabios then and reject all patches to the bochs 
bios.  If that doesn't motivate people to switch, nothing will.

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

Re: [Qemu-devel] Re: [PATCH 1/4] Add GPL bios as a submodule

[Jamie Lokier]

Avi Kivity wrote:
> Let's only include seabios then and reject all patches to the bochs 
> bios.  If that doesn't motivate people to switch, nothing will.

Is there a technical reason why should people switch, other than you
want them to?  Is Bochs BIOS broken in some difficult to fix way?

-- Jamie

Re: [Qemu-devel] Re: [PATCH 1/4] Add GPL bios as a submodule

[Avi Kivity]

Jamie Lokier wrote:
> Avi Kivity wrote:
>   
>> Let's only include seabios then and reject all patches to the bochs 
>> bios.  If that doesn't motivate people to switch, nothing will.
>>     
>
> Is there a technical reason why should people switch, other than you
> want them to?  Is Bochs BIOS broken in some difficult to fix way?
>   

bochs bios is written in 16-bit assembly and a mix of 16-bit C and 
32-bit gcc.  It requires a special toolchain (bcc/dev86), the code is 
(no disrespect to its authors) quite nasty.

seabios is mostly C (gcc, not dev86) and well written and maintained.  
No doubt you could fix the bochs bios to have these attributes, but then 
I'd ask if there is a technical reason why we should do that rather than 
switch to seabios.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

RE: [Qemu-devel] Re: [PATCH 1/4] Add GPL bios as a submodule

[Stanislav]

And similar question: why don't you think about switching to Coreboot ?
What is the status Coreboot now ? Is it working for legacy OS ?

Stanislav

-----Original Message-----
From: qemu-devel-bounces+stlintel=gmail.com@nongnu.org
[mailto:qemu-devel-bounces+stlintel=gmail.com@nongnu.org] On Behalf Of Jamie
Lokier
Sent: Sunday, May 17, 2009 8:51 PM
To: Avi Kivity
Cc: Glauber Costa; Anthony Liguori; Dustin Kirkland; qemu-devel@nongnu.org;
Alex Graf
Subject: Re: [Qemu-devel] Re: [PATCH 1/4] Add GPL bios as a submodule

Avi Kivity wrote:
> Let's only include seabios then and reject all patches to the bochs 
> bios.  If that doesn't motivate people to switch, nothing will.

Is there a technical reason why should people switch, other than you
want them to?  Is Bochs BIOS broken in some difficult to fix way?

-- Jamie

Re: [Qemu-devel] Re: [PATCH 1/4] Add GPL bios as a submodule

[Avi Kivity]

Stanislav wrote:
> And similar question: why don't you think about switching to Coreboot ?
>   

What does Coreboot give us over seabios?

> What is the status Coreboot now ? Is it working for legacy OS ?
>   

Doesn't Coreboot use seabios for legacy OS?

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

RE: [Qemu-devel] Re: [PATCH 1/4] Add GPL bios as a submodule

[Stanislav]

> What does Coreboot give us over seabios?

You asking :)

- It is much better maintained and sponsored by technology leaders (IBM,
AMD, Intel).
  Also as I understood some of bios stuff is patented, IBM bought these
patents and contributed them to Coreboot project.
- I expect it will do support all recent stuff (new ACPI specs, UEFI and
etc) much faster than seabios.
- It is written for real modern hardware as well so it is validated on real
life as well.

> Doesn't Coreboot use seabios for legacy OS?

No idea ...

Stanislav

-----Original Message-----
From: Avi Kivity [mailto:avi@redhat.com] 
Sent: Sunday, May 17, 2009 9:12 PM
To: Stanislav
Cc: 'Jamie Lokier'; 'Glauber Costa'; 'Anthony Liguori'; 'Dustin Kirkland';
qemu-devel@nongnu.org; 'Alex Graf'
Subject: Re: [Qemu-devel] Re: [PATCH 1/4] Add GPL bios as a submodule

Stanislav wrote:
> And similar question: why don't you think about switching to Coreboot ?
>   

What does Coreboot give us over seabios?

> What is the status Coreboot now ? Is it working for legacy OS ?
>   

Doesn't Coreboot use seabios for legacy OS?

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: [Qemu-devel] Re: [PATCH 1/4] Add GPL bios as a submodule

[Avi Kivity]

Stanislav wrote:
>
>> Doesn't Coreboot use seabios for legacy OS?
>>     
>
> No idea ...
>   

 From the FAQ:

>
>       What is coreboot?
>
> It performs just a little bit of hardware initialization and then 
> executes a so-called payload <http://www.coreboot.org/Payloads>.
>
> Some of the many possible payloads are: a Linux 
> <http://www.coreboot.org/Linux> kernel, FILO 
> <http://www.coreboot.org/FILO> (a GRUB-like bootloader for booting 
> from disk), GRUB2 <http://www.coreboot.org/GRUB2>, Open Firmware 
> <http://www.openbios.org/Open_Firmware>, Etherboot 
> <http://www.coreboot.org/Etherboot>/GPXE 
> <http://www.coreboot.org/GPXE>, SeaBIOS 
> <http://www.coreboot.org/SeaBIOS> (for booting Windows XP, Windows 
> Vista, Windows 7, NetBSD and Linux), and many others 
> <http://www.coreboot.org/Payloads>.
>

So it seems to make little sense to load coreboot just to load seabios.  
Of course I'd like to see coreboot supported, but seabios looks like a 
better primary target.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [Qemu-devel] Re: [PATCH 1/4] Add GPL bios as a submodule

[Carl-Daniel Hailfinger]

On 17.05.2009 21:07, Avi Kivity wrote:
> So it seems to make little sense to load coreboot just to load
> seabios.  Of course I'd like to see coreboot supported, but seabios
> looks like a better primary target.

Coreboot already works with Qemu and also with Qemu+KVM. In case you
want to test something without traditional BIOS services, coreboot is
definitely the way to go.


Regards,
Carl-Daniel

Re: [Qemu-devel] Re: [PATCH 1/4] Add GPL bios as a submodule

[Avi Kivity]

Carl-Daniel Hailfinger wrote:
> On 17.05.2009 21:07, Avi Kivity wrote:
>   
>> So it seems to make little sense to load coreboot just to load
>> seabios.  Of course I'd like to see coreboot supported, but seabios
>> looks like a better primary target.
>>     
>
> Coreboot already works with Qemu and also with Qemu+KVM. In case you
> want to test something without traditional BIOS services, coreboot is
> definitely the way to go.
>   

To be frank, it's not on my top list of priorities.  I want to support 
Windows and Linux running from their traditional installers, as close as 
possible to off-the-shelf hardware.  As far as I can see the best way to 
get there is seabios.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [Qemu-devel] Re: [PATCH 1/4] Add GPL bios as a submodule

[Anthony Liguori]

Stanislav wrote:
>> What does Coreboot give us over seabios?
>>     
>
> You asking :)
>
> - It is much better maintained and sponsored by technology leaders (IBM,
> AMD, Intel).
>   

Take a look at who has been contributing to patches to the Bochs BIOS 
lately via QEMU :-)

>   Also as I understood some of bios stuff is patented, IBM bought these
> patents and contributed them to Coreboot project.
>   

Can you point me to specific information about this?

> - I expect it will do support all recent stuff (new ACPI specs, UEFI and
> etc) much faster than seabios.
>   

I find this very unlikely.  I don't think coreboot bothers with things 
like building ACPI tables.  Why would it have to when it has a full 
Linux environment?

Also, I find it very unlikely that it would bother support uefi 
interfaces.  Maybe provide tiano core as a payload but we could always 
just use tiano core on top of QEMU directly.  The problem with uefi is 
that you still need a CSM to support 99% of guests out there which means 
that you would still need a seabios module for tiano core.

> - It is written for real modern hardware as well so it is validated on real
> life as well.
>   

It's a neat project and I think it's valuable to make it more easily 
used in QEMU, but I don't think it can replace our existing BIOS.  I 
also don't think that that's its general mission statement either.  I 
think its primary purpose is to eliminate all the legacy firmware junk 
and provide the quickest and most featureful environment for large clusters.

>> Doesn't Coreboot use seabios for legacy OS?
>>     
>
> No idea ...
>   

It does.

Regards,

Anthony Liguori

Re: [Qemu-devel] Re: [PATCH 1/4] Add GPL bios as a submodule

[ron minnich]

On Sun, May 17, 2009 at 4:22 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:

> I find this very unlikely.  I don't think coreboot bothers with things like
> building ACPI tables.  Why would it have to when it has a full Linux
> environment?

We did not used to. But it's been a long time since we did just linux
in flash. Now there are lots of other combinations:
coreboot+seabios
coreboot+seabios+gpxe
coreboot+tiano
and on and on ...

Many of these combinations require ACPI and/or SMM. Sad news: vendor
hardware is nowadays *more*, not *less*, dependent on SMM -- very few
modern Intel
chipsets can function without a working SMM layer -- or so the people
with the docs tell me. So SMM and ACPI, both huge security issues in
their
own right, are almost impossible to eliminate nowadays. And, good fun,
some new chips now require that microcode be patched *before* memory
is even turned out. Good fun. No more patching microcode from Linux!

So coreboot supports SMM&ACPI where they are needed. SMM is mostly
restricted to Intel chips for now.

coreboot also supports tiano, But oh, the irony!: Tiano was billed as
a way to an "open source" bios, in competition with coreboot, but you
really can't build a completely open source BIOS with Tiano alone: you
need to have coreboot to turn on the hardware because you need chipset
stuff that only comes from vendors as a binary blob. So, again, AFAIK,
nobody is really bothering to do much with Tiano core. Tiano is at
most half a BIOS or less. The only fully open source BIOS stack you
can get with Tiano is going to be one that includes coreboot.

To pile on the funny bits, vendors, after telling us for 10 years that
linux-in-flash was a stupid idea, are buying into it in a big way. At
the same time coreboot is supporting more traditional models, some
BIOS vendor are jumping on the Linux-in-FLASH bandwagon. Now wait,
whose side are we on anyway?

> It's a neat project and I think it's valuable to make it more easily used in
> QEMU, but I don't think it can replace our existing BIOS.  I also don't
> think that that's its general mission statement either.  I think its primary
> purpose is to eliminate all the legacy firmware junk and provide the
> quickest and most featureful environment for large clusters.

I think it can replace your existing BIOS. I would not have said that
one year ago. Nowadays, coreboot+seabios can even boot/install xp,
vista, and windows 7. I have now got systems that boot anything I've
tried that used to use a traditional BIOS. These guys:
http://xfc.xfce.org/index.html are using coreboot for a build-bot
because the BIOS that came with the board did not even work; coreboot
got them going.

BTW, thanks for qemu. I do most of my initial coreboot testing on
qemu. It's really been a lifesaver. Conversely, qemu (and kvm for that
matter) users who want a fast booting bios that stays out of their way
can do well with coreboot. There are a lot of people besides me using
coreboot+qemu. Qemu is a very fine piece of work!

ron

Re: [Qemu-devel] Re: [PATCH 1/4] Add GPL bios as a submodule

[Kevin O'Connor]

On Sun, May 17, 2009 at 09:37:26PM +0300, Stanislav wrote:
> > What does Coreboot give us over seabios?
> You asking :)

Coreboot and SeaBIOS don't compete - they complement each other.

Modern X86 systems have no memory access when they first power on -
the initial bootstrap code must scan the memory modules via the smbus
and then program the memory controller.  Much of Coreboot is dedicated
to programming ram and other low-level details of the hardware.

SeaBIOS is a port of bochs bios to gcc.  It provides support for
legacy 16bit interfaces, including loading an OS from
floppy/harddrive.  Coreboot uses SeaBIOS to provide support for off
the shelf OSes (eg, Windows).

Much of what coreboot provides is unnecessary for an emulated machine.

> > Doesn't Coreboot use seabios for legacy OS?
> 
> No idea ...

Yes - coreboot itself has no legacy interfaces - SeaBIOS provides that
support.

-Kevin

Re: [Qemu-devel] Re: [PATCH 1/4] Add GPL bios as a submodule

[Anthony Liguori]

Stanislav wrote:
> And similar question: why don't you think about switching to Coreboot ?
> What is the status Coreboot now ? Is it working for legacy OS ?
>   

Coreboot offers no value over seabios because to run any OS, you have to 
run seabios as a payload of coreboot.

Regards,

Anthony Liguori

Re: [Qemu-devel] Re: [PATCH 1/4] Add GPL bios as a submodule

[Jamie Lokier]

Anthony Liguori wrote:
> Stanislav wrote:
> >And similar question: why don't you think about switching to Coreboot ?
> >What is the status Coreboot now ? Is it working for legacy OS ?
> >  
> 
> Coreboot offers no value over seabios because to run any OS, you have to 
> run seabios as a payload of coreboot.

In the list of Coreboot payloads, it has Linux in addition to GRUB,
SeaBIOS etc.  Does that not mean you can run Linux as a payload
_instead_ of SeaBIOS, and therefore boot Linux guests using Coreboot alone?

-- Jamie

Re: [Qemu-devel] Re: [PATCH 1/4] Add GPL bios as a submodule

[Carl-Daniel Hailfinger]

On 18.05.2009 06:22, Jamie Lokier wrote:
> Anthony Liguori wrote:
>   
>> Coreboot offers no value over seabios because to run any OS, you have to 
>> run seabios as a payload of coreboot.
>>     
>
> In the list of Coreboot payloads, it has Linux in addition to GRUB,
> SeaBIOS etc.  Does that not mean you can run Linux as a payload
> _instead_ of SeaBIOS, and therefore boot Linux guests using Coreboot alone?
>   

Sure. It can also boot Plan 9 and others directly as a payload,
eliminating the need for SeaBIOS/GRUB2/FILO.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

Re: [Qemu-devel] Re: [PATCH 1/4] Add GPL bios as a submodule

[Anthony Liguori]

Avi Kivity wrote:
> Anthony Liguori wrote:
>>> I really prefer a relative path here, so that people can set up 
>>> mirrors on an internal server.  Also, not everyone can access the 
>>> git port.  It can be worked around, but it's much better to have 
>>> things working out of the proverbial box.
>>
>> Do you also include a way to automatically setup the relative path?  
>> Otherwise, it's a multi-step process for someone to fetch all of the 
>> git trees for building.
>
> I don't understand the question.  The relative path is set up once (in 
> .gitmodules), and that's it.

To clone kvm-kvm.git, you have to do:

[1] git clone git://git.kernel.org/pub/scm/virt/kvm/kvm-kmod.git
[2] git clone git://git.kernel.org/pub/scm/virt/kvm/kvm.git
[3] cd kvm-kmod.git
[4] git submodule update --init

For qemu.git, we'll have to repeat [2] for every ROM we include which 
will at least be 6 different repositories.  Contrast that to my patchset 
where there's always 3 steps regardless of how many ROMs we include.

>>
>> We have a lot of ROMs, so this is potentially very undesirable.  
>> People can always make local changes to the .gitmodules file.
>
> Not if they're a mirror.

The normal course of usage will not involve doing a git submodule update 
in QEMU.  The only folks who really need to do this are maintainers or 
people doing ROM development/testing.  I don't think I'm that worried 
about mirrors considering the target audience.

This is different than kvm-kmod whereas all users must do git submodule 
updates.

>>> Having said all that, I'd rather see seabios here.  Sure, it will 
>>> take us time to add missing features, if any, but life will be much 
>>> more pleasant afterwards.  We should reduce our ties to the bochs 
>>> bios, not tighten them.
>>
>> Actually, I want to include seabios in here too and install it by 
>> default.
>>
>> There's already a -bios option that can be used to change the bios 
>> file name.  After some basic testing, we can decide whether we should 
>> change the default bios we use.  With both installed, it's easier to 
>> have people check for bugs in one verse the other.
>
> Let's only include seabios then and reject all patches to the bochs 
> bios.  If that doesn't motivate people to switch, nothing will.

I don't think it would be wise to switch the default to seabios until 
after 0.11.  I'm concerned that there hasn't been enough testing on 
non-mainstream guests.  I'd like a full release cycle worth of testing.

The gcc 4.1+ requirement is tough too.  One of the values of switching 
to seabios was moving to a more common toolchain (bcc=>gcc).  Having new 
tool chain restricts seems a little unfortunate.

Regards,

Anthony Liguori

Re: [Qemu-devel] Re: [PATCH 1/4] Add GPL bios as a submodule

[Avi Kivity]

Anthony Liguori wrote:
>>
>> I don't understand the question.  The relative path is set up once 
>> (in .gitmodules), and that's it.
>
> To clone kvm-kvm.git, you have to do:
>
> [1] git clone git://git.kernel.org/pub/scm/virt/kvm/kvm-kmod.git
> [2] git clone git://git.kernel.org/pub/scm/virt/kvm/kvm.git
> [3] cd kvm-kmod.git
> [4] git submodule update --init
>
> For qemu.git, we'll have to repeat [2] for every ROM we include which 
> will at least be 6 different repositories.  Contrast that to my 
> patchset where there's always 3 steps regardless of how many ROMs we 
> include.
>

Step 2 is unneeded.  Step 4 takes care of the cloning.  The relative 
path is relative to the repository you cloned kvm-kmod.git _from_.

So, if you cloned git://git.kernel.org/pub/scm/virt/kvm-kmod.git, git 
will clone git://git.kernel.org/pub/scm/virt/kvm.git.  But if you cloned 
http://git.kernel.org/pub/scm/virt/kvm-kmod.git, git will clone kvm.git 
using the http protocol.

Similarly, if you set up a mirror somewhere, as long as kvm-kmod.git and 
kvm.git are under the same directory, cloning kvm-kmod.git will carry 
kvm.git transparently.

>>>
>>> We have a lot of ROMs, so this is potentially very undesirable.  
>>> People can always make local changes to the .gitmodules file.
>>
>> Not if they're a mirror.
>
> The normal course of usage will not involve doing a git submodule 
> update in QEMU.  The only folks who really need to do this are 
> maintainers or people doing ROM development/testing.  I don't think 
> I'm that worried about mirrors considering the target audience.
>
> This is different than kvm-kmod whereas all users must do git 
> submodule updates.

That's true.  I still dislike hardcoding a URL into the repository.  It 
means that some branches become unclonable if you move the repository, 
at least not without manual intervention.

>>
>> Let's only include seabios then and reject all patches to the bochs 
>> bios.  If that doesn't motivate people to switch, nothing will.
>
> I don't think it would be wise to switch the default to seabios until 
> after 0.11.  I'm concerned that there hasn't been enough testing on 
> non-mainstream guests.  I'd like a full release cycle worth of testing.

Agreed.

>
> The gcc 4.1+ requirement is tough too.  One of the values of switching 
> to seabios was moving to a more common toolchain (bcc=>gcc).  Having 
> new tool chain restricts seems a little unfortunate.

Agreed as well.  I think we can work around this requirement, though.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: [Qemu-devel] Re: [PATCH 1/4] Add GPL bios as a submodule

[Anthony Liguori]

Avi Kivity wrote:
> Anthony Liguori wrote:
>>>
>>> I don't understand the question.  The relative path is set up once 
>>> (in .gitmodules), and that's it.
>>
>> To clone kvm-kvm.git, you have to do:
>>
>> [1] git clone git://git.kernel.org/pub/scm/virt/kvm/kvm-kmod.git
>> [2] git clone git://git.kernel.org/pub/scm/virt/kvm/kvm.git
>> [3] cd kvm-kmod.git
>> [4] git submodule update --init
>>
>> For qemu.git, we'll have to repeat [2] for every ROM we include which 
>> will at least be 6 different repositories.  Contrast that to my 
>> patchset where there's always 3 steps regardless of how many ROMs we 
>> include.
>>
>
> Step 2 is unneeded.  Step 4 takes care of the cloning.  The relative 
> path is relative to the repository you cloned kvm-kmod.git _from_.

Oh, excellent.  Except that's a pain with qemu hosted on Savannah as I 
cannot create additional trees without creating new projects :-(

I can't move qemu's git tree off of Savannah without leaving Savannah 
completely.

>>>
>>> Let's only include seabios then and reject all patches to the bochs 
>>> bios.  If that doesn't motivate people to switch, nothing will.
>>
>> I don't think it would be wise to switch the default to seabios until 
>> after 0.11.  I'm concerned that there hasn't been enough testing on 
>> non-mainstream guests.  I'd like a full release cycle worth of testing.
>
> Agreed.

We can put seabios in the tree now (once we work out the rom building 
stuff).  We can get started with testing now and then for the 0.12 tree, 
we'll switch to seabios by default if things don't look like they're 
going to be too painful.

Regards,

Anthony Liguori

Re: [Qemu-devel] Re: [PATCH 1/4] Add GPL bios as a submodule

[Avi Kivity]

Anthony Liguori wrote:
> Oh, excellent.  Except that's a pain with qemu hosted on Savannah as I 
> cannot create additional trees without creating new projects :-(

Savannah is painful anyway.  I have a hard time pulling from it, though 
may I have a bad route to it.

> I can't move qemu's git tree off of Savannah without leaving Savannah 
> completely.

Maybe we should do that.  Having moved from sourceforge, it's not 
pleasant, but not too bad.

Alternatively, create a new project.  Can you put the new repo under the 
same directory?

> We can put seabios in the tree now (once we work out the rom building 
> stuff).  We can get started with testing now and then for the 0.12 
> tree, we'll switch to seabios by default if things don't look like 
> they're going to be too painful.

Great, thanks.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: [Qemu-devel] Re: [PATCH 1/4] Add GPL bios as a submodule

[Anthony Liguori]

Avi Kivity wrote:
> Anthony Liguori wrote:
>> Oh, excellent.  Except that's a pain with qemu hosted on Savannah as 
>> I cannot create additional trees without creating new projects :-(
>
> Savannah is painful anyway.  I have a hard time pulling from it, 
> though may I have a bad route to it.
>
>> I can't move qemu's git tree off of Savannah without leaving Savannah 
>> completely.
>
> Maybe we should do that.  Having moved from sourceforge, it's not 
> pleasant, but not too bad.

After we have qemu.org setup, we can think about that.  I hope we can 
have qemu.org going sometime in late June/early July.

> Alternatively, create a new project.  Can you put the new repo under 
> the same directory?

With Savannah, you get one git tree in the form of /<projectname>.git.  
I'm sure I could ask about additional tree hosting bug the latency for 
responses from the Savannah admins is pretty high.

Regards,

Anthony Liguori

Re: [Qemu-devel] Re: [PATCH 1/4] Add GPL bios as a submodule

[Avi Kivity]

Anthony Liguori wrote:
> [host a clone of seabios.git]
> After we have qemu.org setup, we can think about that.  I hope we can 
> have qemu.org going sometime in late June/early July.
>
>> Alternatively, create a new project.  Can you put the new repo under 
>> the same directory?
>
> With Savannah, you get one git tree in the form of 
> /<projectname>.git.  I'm sure I could ask about additional tree 
> hosting bug the latency for responses from the Savannah admins is 
> pretty high.

I could have a branch of qemu.git in qemu-kvm.git, with the relative 
submodule url, to experiment with.  Once qemu has finished renovating / 
looking for a new home, we can merge that branch to upstream.  (I'll 
have an additional branch with the qemu-kvm-specific hacks, if any are 
needed).

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

[Qemu-devel] Re: [PATCH 1/4] Add GPL bios as a submodule

[Sebastian Herbszt]

Anthony Liguori wrote:
> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
> ---
> .gitmodules  |    3 +++
> roms/gplbios |    1 +
> 2 files changed, 4 insertions(+), 0 deletions(-)
> create mode 100644 .gitmodules
> create mode 160000 roms/gplbios
> 
> diff --git a/.gitmodules b/.gitmodules
> new file mode 100644
> index 0000000..9bdf196
> --- /dev/null
> +++ b/.gitmodules
> @@ -0,0 +1,3 @@
> +[submodule "roms/gplbios"]
> + path = roms/gplbios
> + url = git://repo.or.cz/gplbios/qemu.git
> diff --git a/roms/gplbios b/roms/gplbios
> new file mode 160000
> index 0000000..ff509b4
> --- /dev/null
> +++ b/roms/gplbios
> @@ -0,0 +1 @@
> +Subproject commit ff509b44010d161e8202ee4c0b6f3ca463672bca
> -- 

FWIW, Bochs BIOS is LGPL.

- Sebastian

[Qemu-devel] [PATCH 2/4] Add submodule for VGABios

[Anthony Liguori]

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
---
 .gitmodules  |    3 +++
 roms/vgabios |    1 +
 2 files changed, 4 insertions(+), 0 deletions(-)
 create mode 160000 roms/vgabios

diff --git a/.gitmodules b/.gitmodules
index 9bdf196..d379a89 100644
--- a/.gitmodules
+++ b/.gitmodules
@@ -1,3 +1,6 @@
 [submodule "roms/gplbios"]
 	path = roms/gplbios
 	url = git://repo.or.cz/gplbios/qemu.git
+[submodule "roms/vgabios"]
+	path = roms/vgabios
+	url = git://repo.or.cz/vgabios/qemu.git
diff --git a/roms/vgabios b/roms/vgabios
new file mode 160000
index 0000000..a40795d
--- /dev/null
+++ b/roms/vgabios
@@ -0,0 +1 @@
+Subproject commit a40795d2bfd93906c9051ebfcc1309d3f9bba142
-- 
1.6.2.5

[Qemu-devel] [PATCH 3/4] Update makefile to build roms

[Anthony Liguori]

We build the roms in a sub directory of the target build directory.  This is
anticipating a single source base (like uboot) that gets built differently for
multiple target architectures (PPC, SH4, etc.).

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
---
 Makefile        |    7 ++++++-
 Makefile.target |   18 ++++++++++++++++++
 configure       |    8 ++++++++
 3 files changed, 32 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index f303aff..8677f38 100644
--- a/Makefile
+++ b/Makefile
@@ -10,7 +10,7 @@ config-host.mak:
 endif
 
 .PHONY: all clean cscope distclean dvi html info install install-doc \
-	recurse-all speed tar tarbin test
+	recurse-all speed tar tarbin test roms
 
 VPATH=$(SRC_PATH):$(SRC_PATH)/hw
 
@@ -231,6 +231,11 @@ qemu-io$(EXESUF):  qemu-io.o qemu-tool.o tool-osdep.o cmd.o $(BLOCK_OBJS)
 
 qemu-img$(EXESUF) qemu-nbd$(EXESUF) qemu-io$(EXESUF): LIBS += -lz
 
+roms:
+	@for d in $(TARGET_DIRS); do \
+	$(MAKE) -C $$d $@ || exit 1 ; \
+        done
+
 clean:
 # avoid old build problems by removing potentially incorrect old files
 	rm -f config.mak config.h op-i386.h opc-i386.h gen-op-i386.h op-arm.h opc-arm.h gen-op-arm.h
diff --git a/Makefile.target b/Makefile.target
index dd1c442..567618b 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -712,6 +712,12 @@ LDFLAGS+=-p
 main.o: CFLAGS+=-p
 endif
 
+#  Per architecture ROMS
+ROMS=
+ifeq ($(TARGET_BASE_ARCH),i386)
+ROMS+=gplbios vgabios
+endif
+
 vl.o: qemu-options.h
 
 $(QEMU_PROG): LIBS += $(SDL_LIBS) $(COCOA_LIBS) $(CURSES_LIBS) $(BRLAPI_LIBS) $(VDE_LIBS)
@@ -731,9 +737,21 @@ endif
 qemu-options.h: $(SRC_PATH)/qemu-options.hx
 	$(call quiet-command,sh $(SRC_PATH)/hxtool -h < $< > $@,"  GEN   $(TARGET_DIR)$@")
 
+.PHONY: roms
+
+roms:
+	@if test "$(ROMS)" ; then \
+	  for subdir in $(ROMS); do \
+	    $(MAKE) -C roms/$${subdir} VPATH=$(SRC_PATH)/roms/$${subdir} ;\
+	  done; \
+	fi
+
 clean:
 	rm -f *.o *.a *~ $(PROGS) nwfpe/*.o fpu/*.o qemu-options.h gdbstub-xml.c
 	rm -f *.d */*.d tcg/*.o
+	for subdir in $(ROMS); do \
+	    $(MAKE) -C $${subdir} clean \
+	done
 
 install: all
 ifneq ($(PROGS),)
diff --git a/configure b/configure
index 4111e7c..29a13ca 100755
--- a/configure
+++ b/configure
@@ -1791,6 +1791,14 @@ if test "$target" = "arm-linux-user" -o "$target" = "armeb-linux-user" -o "$targ
   mkdir -p $target_dir/nwfpe
 fi
 
+if test "$target" = "i386-softmmu" -o "$target" = "x86_64-softmmu" ; then
+    for rom in gplbios vgabios ; do
+	mkdir -p $target_dir/roms/$rom
+	rm -f $target_dir/roms/$rom/Makefile
+	ln -s $source_path/roms/$rom/Makefile $target_dir/roms/$rom/Makefile
+    done
+fi
+
 #
 # don't use ln -sf as not all "ln -sf" over write the file/link
 #
-- 
1.6.2.5

[Qemu-devel] Re: [PATCH 3/4] Update makefile to build roms

[Avi Kivity]

Anthony Liguori wrote:
> We build the roms in a sub directory of the target build directory.  This is
> anticipating a single source base (like uboot) that gets built differently for
> multiple target architectures (PPC, SH4, etc.).
>
>  
> +#  Per architecture ROMS
> +ROMS=
> +ifeq ($(TARGET_BASE_ARCH),i386)
> +ROMS+=gplbios vgabios
> +endif
> +
>   

ROMS-i386 = gplbios vgabios
ROMS = $(ROMS-$(TARGET_BASE_ARCH))

(make is not shell, it tolerates spaces around the equals sign)

Also, I think you'll need to set up the cross-compiler here for 
completeness, not that I think it will ever be used in anger.

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

[Qemu-devel] Re: [PATCH 3/4] Update makefile to build roms

[Avi Kivity]

Avi Kivity wrote:
>
> Also, I think you'll need to set up the cross-compiler here for 
> completeness, not that I think it will ever be used in anger.
>

Err, you did, in 4/4.

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

[Qemu-devel] Re: [PATCH 3/4] Update makefile to build roms

[Anthony Liguori]

Avi Kivity wrote:
> Anthony Liguori wrote:
>> We build the roms in a sub directory of the target build directory.  
>> This is
>> anticipating a single source base (like uboot) that gets built 
>> differently for
>> multiple target architectures (PPC, SH4, etc.).
>>
>>  
>> +#  Per architecture ROMS
>> +ROMS=
>> +ifeq ($(TARGET_BASE_ARCH),i386)
>> +ROMS+=gplbios vgabios
>> +endif
>> +
>>   
>
> ROMS-i386 = gplbios vgabios
> ROMS = $(ROMS-$(TARGET_BASE_ARCH))
>
> (make is not shell, it tolerates spaces around the equals sign)

Yeah, this is still very rough.  The build/install process is different 
for each rom so I'm probably going to need to do something fancier than 
what I have about.  Perhaps something along a subdir-% rule for the sane 
ROMs that can be overridden for weirder ones.

gplbios and vgabios are simple to build so it's where I started.

> Also, I think you'll need to set up the cross-compiler here for 
> completeness, not that I think it will ever be used in anger.

Yeah, also not yet fully bake yet but as you noticed, I've started 
that.  The difficult part is cleaning up the build system of each of the 
ROMs.

gpxe, in particular, looks to be a real pain to get buildable from a 
separate directory :-/

-- 
Regards,

Anthony Liguori

Re: [Qemu-devel] Re: [PATCH 3/4] Update makefile to build roms

[Avi Kivity]

Anthony Liguori wrote:
>
> gpxe, in particular, looks to be a real pain to get buildable from a 
> separate directory :-/
>

I think this should be fixed in the respective upstreams.  Meanwhile a 
hack to get this to work is to cp -rl everything into the object 
directory and build it there.  This is non-intrusive and sufficiently 
performant.

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

Re: [Qemu-devel] Re: [PATCH 3/4] Update makefile to build roms

[Anthony Liguori]

Avi Kivity wrote:
> Anthony Liguori wrote:
>>
>> gpxe, in particular, looks to be a real pain to get buildable from a 
>> separate directory :-/
>>
>
> I think this should be fixed in the respective upstreams.

That's the plan.

>   Meanwhile a hack to get this to work is to cp -rl everything into 
> the object directory and build it there.  This is non-intrusive and 
> sufficiently performant.
>

Regards,

Anthony Liguori

Re: [Qemu-devel] Re: [PATCH 3/4] Update makefile to build roms

[Paul Brook]

> >> We build the roms in a sub directory of the target build directory.
> >> This is
> >> anticipating a single source base (like uboot) that gets built
> >> differently for
> >> multiple target architectures (PPC, SH4, etc.).

I'm pretty sure this is going to be wrong. i386 and x86-64 use the same rom, 
and uboot will most likely need to be built for every *bard*

> >> +#  Per architecture ROMS
> >> +ROMS=
> >> +ifeq ($(TARGET_BASE_ARCH),i386)
> >> +ROMS+=gplbios vgabios
> >> +endif
> >> +
> >
> > ROMS-i386 = gplbios vgabios
> > ROMS = $(ROMS-$(TARGET_BASE_ARCH))
> >
> > (make is not shell, it tolerates spaces around the equals sign)
>
> Yeah, this is still very rough.  The build/install process is different
> for each rom so I'm probably going to need to do something fancier than
> what I have about.  Perhaps something along a subdir-% rule for the sane
> ROMs that can be overridden for weirder ones.
>
> gplbios and vgabios are simple to build so it's where I started.

This worries me. You've probably picked the easiest examples, and already it 
doesn't fit nicely.

Why are you trying so hard to integrate these into qemu? IMHO they really 
don't belong there. AFAICS the roms share no significant code with qemu, and 
require a completely different environment to build. Especially in cross 
environments I'd expect combining the two to cause much more pain than it's 
worth. When developing/building roms a native environment is the exception 
rather than the norm. Even then it's not really a native build, it's more a 
collection of hacks that allow you get away with using a native toolchain.

Paul

Re: [Qemu-devel] Re: [PATCH 3/4] Update makefile to build roms

[Anthony Liguori]

Paul Brook wrote:
>>>> We build the roms in a sub directory of the target build directory.
>>>> This is
>>>> anticipating a single source base (like uboot) that gets built
>>>> differently for
>>>> multiple target architectures (PPC, SH4, etc.).
>>>>         
>
> I'm pretty sure this is going to be wrong. i386 and x86-64 use the same rom, 
> and uboot will most likely need to be built for every *bard*
>   

I guess the alternative is to have top-level rules for building roms and 
then have each target depend on whatever roms it needs.  This may 
include multiple versions of the same rom.

>> gplbios and vgabios are simple to build so it's where I started.
>>     
>
> This worries me. You've probably picked the easiest examples, and already it 
> doesn't fit nicely.
>
> Why are you trying so hard to integrate these into qemu? IMHO they really 
> don't belong there. AFAICS the roms share no significant code with qemu, and 
> require a completely different environment to build. Especially in cross 
> environments I'd expect combining the two to cause much more pain than it's 
> worth. When developing/building roms a native environment is the exception 
> rather than the norm. Even then it's not really a native build, it's more a 
> collection of hacks that allow you get away with using a native toolchain.
>   

For any packager, it's absolutely necessary to build all of the 
distributed binaries from source.

In general, QEMU does not support anything but lock-step versioning with 
it's ROMs.  There is no ABI between QEMU and the BIOS.

Having multiple packages therefore makes little sense because they can 
never be independent of each other.

As long as we include binaries in our source tree, I think we ought to 
also include the source for those binaries.

Regards,

Anthony Liguori

Re: [Qemu-devel] Re: [PATCH 3/4] Update makefile to build roms

[Paul Brook]

> >> gplbios and vgabios are simple to build so it's where I started.
> >
> > This worries me. You've probably picked the easiest examples, and already
> > it doesn't fit nicely.
> >
> > Why are you trying so hard to integrate these into qemu? IMHO they really
> > don't belong there. AFAICS the roms share no significant code with qemu,
> > and require a completely different environment to build. Especially in
> > cross environments I'd expect combining the two to cause much more pain
> > than it's worth. When developing/building roms a native environment is
> > the exception rather than the norm. Even then it's not really a native
> > build, it's more a collection of hacks that allow you get away with using
> > a native toolchain.
>
> For any packager, it's absolutely necessary to build all of the
> distributed binaries from source.

I don't disagree with this.

> In general, QEMU does not support anything but lock-step versioning with
> it's ROMs.  There is no ABI between QEMU and the BIOS.

This is obviously false for things like PXE roms.

> Having multiple packages therefore makes little sense because they can
> never be independent of each other.

Depends how your build system is setup.  IMHO building a ROM and building qemu 
itself are different tasks that effectively need separate packages anyway.

I also think that the Makefile is a bad place to encode knowledge of how to 
build a rom. If roms are hard to build and configure, shouldn't we be fixing 
that uptream? If not, isn't it going to be simpler and more effective to have 
a script that fetches+builds all the roms we ship?

> As long as we include binaries in our source tree, I think we ought to
> also include the source for those binaries.

You aren't importing the source though. You're just add makefile hacks to 
build it after it's been fetched from third party repositories.

Paul

Re: [Qemu-devel] Re: [PATCH 3/4] Update makefile to build roms

[Anthony Liguori]

Paul Brook wrote:
>> As long as we include binaries in our source tree, I think we ought to
>> also include the source for those binaries.
>>     
>
> You aren't importing the source though. You're just add makefile hacks to 
> build it after it's been fetched from third party repositories.
>   

My plan was to include the source in the actual releases though.

I agree that the build integration bits are ugly.  I'll have to think 
about this a little harder.

Regards,

Anthony Liguori

> Paul
>   

Re: [Qemu-devel] Re: [PATCH 3/4] Update makefile to build roms

[Jamie Lokier]

Paul Brook wrote:
> > In general, QEMU does not support anything but lock-step versioning with
> > it's ROMs.  There is no ABI between QEMU and the BIOS.
> 
> This is obviously false for things like PXE roms.
> 
> > Having multiple packages therefore makes little sense because they can
> > never be independent of each other.
> 
> Depends how your build system is setup.  IMHO building a ROM and
> building qemu itself are different tasks that effectively need
> separate packages anyway.

And when built for a distribution, perhaps QEMU, BIOS and PXE should
be separate packages anyway, with QEMU depending on the others (or
perhaps "recommending").

-- Jamie

Re: [Qemu-devel] Re: [PATCH 3/4] Update makefile to build roms

[Riku Voipio]

On Mon, May 18, 2009 at 05:24:45AM +0100, Jamie Lokier wrote:
> Paul Brook wrote:
> > > Having multiple packages therefore makes little sense because they can
> > > never be independent of each other.

> > Depends how your build system is setup.  IMHO building a ROM and
> > building qemu itself are different tasks that effectively need
> > separate packages anyway.

> And when built for a distribution, perhaps QEMU, BIOS and PXE should
> be separate packages anyway, with QEMU depending on the others (or
> perhaps "recommending").

This is indeed how it is done in Debian, roms are built in separate packages.
There is also the complication of building ROMs for non-native archs.
Say building openbios-sparc when building qemu on x86, or vgabios when
building qemu on ppc. Then you need a crosscompiler at hand.

While it is not useful for distributions, making it possible to build roms as
part of qemu build process is still usefull for people hacking on qemu.

Re: [Qemu-devel] Re: [PATCH 3/4] Update makefile to build roms

[Avi Kivity]

Riku Voipio wrote:
> This is indeed how it is done in Debian, roms are built in separate packages.
> There is also the complication of building ROMs for non-native archs.
> Say building openbios-sparc when building qemu on x86, or vgabios when
> building qemu on ppc. Then you need a crosscompiler at hand.
>
> While it is not useful for distributions, making it possible to build roms as
> part of qemu build process is still usefull for people hacking on qemu.
>   

This makes sense, and git submodules support both of these modes of 
operation.  When developing, the submodule links allow the two 
repositories to advance in lockstep, but you can also tag, tarball, and 
build each repository independently.

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

[Qemu-devel] [PATCH 4/4] Allow tool chain to be specified for bios build

[Anthony Liguori]

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
---
 Makefile.target |    8 ++++++--
 configure       |   46 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 52 insertions(+), 2 deletions(-)

diff --git a/Makefile.target b/Makefile.target
index 567618b..7f67734 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -715,8 +715,12 @@ endif
 #  Per architecture ROMS
 ROMS=
 ifeq ($(TARGET_BASE_ARCH),i386)
+ifneq ($(BCC),)
+ifneq ($(GCC_I386),)
 ROMS+=gplbios vgabios
 endif
+endif
+endif
 
 vl.o: qemu-options.h
 
@@ -742,7 +746,7 @@ qemu-options.h: $(SRC_PATH)/qemu-options.hx
 roms:
 	@if test "$(ROMS)" ; then \
 	  for subdir in $(ROMS); do \
-	    $(MAKE) -C roms/$${subdir} VPATH=$(SRC_PATH)/roms/$${subdir} ;\
+	    $(MAKE) -C roms/$${subdir} VPATH=$(SRC_PATH)/roms/$${subdir} "BCC=$(BCC)" "GCC32=$(GCC_I386)";\
 	  done; \
 	fi
 
@@ -750,7 +754,7 @@ clean:
 	rm -f *.o *.a *~ $(PROGS) nwfpe/*.o fpu/*.o qemu-options.h gdbstub-xml.c
 	rm -f *.d */*.d tcg/*.o
 	for subdir in $(ROMS); do \
-	    $(MAKE) -C $${subdir} clean \
+	    $(MAKE) -C roms/$${subdir} clean; \
 	done
 
 install: all
diff --git a/configure b/configure
index 29a13ca..6f9a152 100755
--- a/configure
+++ b/configure
@@ -194,6 +194,10 @@ fdt="yes"
 sdl_x11="no"
 xen="yes"
 pkgversion=""
+have_bcc="yes"
+bcc="bcc"
+have_gcc_i386="yes"
+gcc_i386="gcc -m32 -fno-stack-protector"
 
 # OS specific
 if check_define __linux__ ; then
@@ -1262,6 +1266,40 @@ if test "$rt" = "yes" ; then
   CLOCKLIBS="-lrt"
 fi
 
+# FIXME
+# check for iasl and as86
+
+#########################################
+# Check for BCC
+cat > $TMPC <<EOF
+int main(argc, argv) int argc; char **argv; { return 0; }
+EOF
+
+if test "$have_bcc" = "yes" ; then
+  if $bcc -o $TMPE $TMPC > /dev/null 2> /dev/null ; then
+    :
+  else
+    have_bcc="no"
+  fi
+fi
+
+#########################################
+# Check for GCC on i386
+cat > $TMPC <<EOF
+#ifndef __i386__
+#error Not i386
+#endif
+int main(void) { return 0; }
+EOF
+
+if test "$have_gcc_i386" = "yes" ; then
+  if $gcc_i386 -o $TMPE $TMPC > /dev/null 2> /dev/null ; then
+    :
+  else
+    have_gcc_i386="no"
+  fi
+fi
+
 if test "$mingw32" = "yes" ; then
   if test -z "$prefix" ; then
       prefix="c:\\\\Program Files\\\\Qemu"
@@ -1714,6 +1752,14 @@ else
     exit 1
 fi
 
+if test "$have_bcc" = "yes" ; then
+    echo "BCC=$bcc" >> $config_mak
+fi
+
+if test "$have_gcc_i386" = "yes" ; then
+    echo "GCC_I386=$gcc_i386" >> $config_mak
+fi
+
 tools=
 if test `expr "$target_list" : ".*softmmu.*"` != 0 ; then
   tools="qemu-img\$(EXESUF) $tools"
-- 
1.6.2.5