Re: [Qemu-devel] (Before) RFC for new features

Re: [Qemu-devel] (Before) RFC for new features

[Natalia Portillo]

* 1 Chipset (Intel Natoma)

We should have more?
If anyone can put more, great!

> -----Mensaje original-----
> De: qemu-devel-bounces+iosglpgc=teleline.es@nongnu.org 
> [mailto:qemu-devel-bounces+iosglpgc=teleline.es@nongnu.org] 
> En nombre de Hetz Ben Hamo
> Enviado el: viernes, 09 de julio de 2004 22:51
> Para: qemu-devel@nongnu.org
> Asunto: [Qemu-devel] (Before) RFC for new features
> 
> Fabrice Bellard wrote:
> > Hi,
> > 
> > As porting the SDL version to other OSes than Linux seems 
> to become an 
> > important issue, I plan to add the following features in 
> the next days:
> 
> I would like to raise an issue which I'm not sure if it was 
> looked closely..
> 
> Lets see what do we have today:
> 
> * 3 Busses (ISA, ISA PnP, PCI)
> * 4 Processors (Pentium Pro, Arm, PPC, Sparc)
> * 4 Network cards (NE2000 ISA, AMD PCNet, NE2000 PCI, 3COM PnP ISA)
> * 2 Graphics cards (VESA, Cirrus Logic)
> * 2 Bioses (PPC BIOS, Generic Bochs/QEMU BIOS)
> * 2 hard drive formats (RAW, COW)
> 
> And I'm sure I have forgotten few things, not mentioning QEMU 
> is not that publicallyy published (wait for Slashdot effect)..
> 
> I think that something needed here: A plugin mechanism.
> 
> What I was thinking that QEMU missing is a way that upon 
> running QEMU (either first time or doing a first scan), it 
> should "scan" for new hardware and register them as plugins 
> (with depenedencies, so you cannot use PPC BIOS with Pentium 
> Pro processor ;) ). That way a new plugin (either open or 
> closed source) can register itself and a user can simply use 
> it without having to configure everything..
> 
> The method I was thinking was something like Xine player uses 
> when initializing the player..
> 
> Fabrice, others, what do you think about it?
> 
> Thanks,
> Hetz
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] (Before) RFC for new features

[Hetz Ben Hamo]

Natalia Portillo wrote:
> * 1 Chipset (Intel Natoma)
> 
> We should have more?
> If anyone can put more, great!

How many chipset do you know that support Intel's Pentium Pro? Another 
chipset might require MMX/SSE support, not mentioning the BIOS support 
which is needed...

Thanks,
Hetz

RE: [Qemu-devel] (Before) RFC for new features

[Natalia Portillo]

I remember there was a non Intel chipset that supports Pentium Pro.
Also, if I dont remember bad (I saw this a long time ago), there are three
Intel chipsets designed for Ppro: 430FX (Is in the Providence motherboard,
single or dual), 440FX (I think also support Pentium II) and 430GX (is in
the big brother of Providence, and supports QUAD cpu) 

> -----Mensaje original-----
> De: qemu-devel-bounces+iosglpgc=teleline.es@nongnu.org 
> [mailto:qemu-devel-bounces+iosglpgc=teleline.es@nongnu.org] 
> En nombre de Hetz Ben Hamo
> Enviado el: sábado, 10 de julio de 2004 16:37
> Para: qemu-devel@nongnu.org
> Asunto: Re: [Qemu-devel] (Before) RFC for new features
> 
> Natalia Portillo wrote:
> > * 1 Chipset (Intel Natoma)
> > 
> > We should have more?
> > If anyone can put more, great!
> 
> How many chipset do you know that support Intel's Pentium 
> Pro? Another chipset might require MMX/SSE support, not 
> mentioning the BIOS support which is needed...
> 
> Thanks,
> Hetz
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] (Before) RFC for new features

[Antony T Curtis]

On Sat, 2004-07-10 at 16:37, Hetz Ben Hamo wrote:
> Natalia Portillo wrote:
> > * 1 Chipset (Intel Natoma)
> > 
> > We should have more?
> > If anyone can put more, great!
> 
> How many chipset do you know that support Intel's Pentium Pro? Another 
> chipset might require MMX/SSE support, not mentioning the BIOS support 
> which is needed...

I don't think that the chipset particularly cares what extended
instructions the CPU can execute... However, BIOS support we are
definitely lacking. IIRC, the BIOS we are using doesn't do any PCI setup
- so we rely on some code in pc.c and pci.c to make the chipset look
configured and to set up the BARs.

-- 
Antony T Curtis <antony.t.curtis@ntlworld.com>

RE: [Qemu-devel] (Before) RFC for new features

[Natalia Portillo]

About the BIOS question we should have a modular BIOS.

Like AWARD, AMI, Phoenix, etc, BIOS, that have support for a great variety
of chipsets and CPUs, and are compiled with required modules for each
motherboard. 

> -----Mensaje original-----
> De: qemu-devel-bounces+iosglpgc=teleline.es@nongnu.org 
> [mailto:qemu-devel-bounces+iosglpgc=teleline.es@nongnu.org] 
> En nombre de Antony T Curtis
> Enviado el: viernes, 09 de julio de 2004 18:33
> Para: qemu-devel@nongnu.org
> Asunto: Re: [Qemu-devel] (Before) RFC for new features
> 
> On Sat, 2004-07-10 at 16:37, Hetz Ben Hamo wrote:
> > Natalia Portillo wrote:
> > > * 1 Chipset (Intel Natoma)
> > > 
> > > We should have more?
> > > If anyone can put more, great!
> > 
> > How many chipset do you know that support Intel's Pentium 
> Pro? Another 
> > chipset might require MMX/SSE support, not mentioning the 
> BIOS support 
> > which is needed...
> 
> I don't think that the chipset particularly cares what 
> extended instructions the CPU can execute... However, BIOS 
> support we are definitely lacking. IIRC, the BIOS we are 
> using doesn't do any PCI setup
> - so we rely on some code in pc.c and pci.c to make the 
> chipset look configured and to set up the BARs.
> 
> --
> Antony T Curtis <antony.t.curtis@ntlworld.com>
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] (Before) RFC for new features

[Jim C. Brown]

On Fri, Jul 09, 2004 at 06:57:21PM +0100, Natalia Portillo wrote:
> About the BIOS question we should have a modular BIOS.
> 
> Like AWARD, AMI, Phoenix, etc, BIOS, that have support for a great variety
> of chipsets and CPUs, and are compiled with required modules for each
> motherboard. 
> 

A modular BIOS designed for qemu is ok (e.g. VGABios vs Bochs BIOS vs
some other hand-written BIOS) but supporting a commercial BIOS written
for actual hardware is another matter. This is very difficult as such a BIOS
will expect different hardware in different places. Not to mention adding support
for different types of motherboards/ROM chips. Its easier to just fix the
current qemu BIOS.

P.S.

Someone is working on that iirc.... posted to the list a while back. They
loaded qemu directly from a bootloader (so there was no host OS, only a guest
OS) and did some hacking so qemu could access the host BIOS directly. So it
is possible, just very hard.

> > I don't think that the chipset particularly cares what 
> > extended instructions the CPU can execute... However, BIOS 
> > support we are definitely lacking. IIRC, the BIOS we are 
> > using doesn't do any PCI setup
> > - so we rely on some code in pc.c and pci.c to make the 
> > chipset look configured and to set up the BARs.
> > 
> > --
> > Antony T Curtis <antony.t.curtis@ntlworld.com>

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

RE: [Qemu-devel] (Before) RFC for new features

[Natalia Portillo]

Well I didn't say about using a real commercial modular BIOS, but making the
QEMU BIOS modular as the commercial ones are.

Making the first, will be a HARD task, and, Award/AMI/Phoenix/MrBIOS won't
let us to do that.
Both VMWare and VirtualPC pays for using a commercial BIOS in their
products. 

> -----Mensaje original-----
> De: qemu-devel-bounces+iosglpgc=teleline.es@nongnu.org 
> [mailto:qemu-devel-bounces+iosglpgc=teleline.es@nongnu.org] 
> En nombre de Jim C. Brown
> Enviado el: viernes, 09 de julio de 2004 21:43
> Para: qemu-devel@nongnu.org
> Asunto: Re: [Qemu-devel] (Before) RFC for new features
> 
> On Fri, Jul 09, 2004 at 06:57:21PM +0100, Natalia Portillo wrote:
> > About the BIOS question we should have a modular BIOS.
> > 
> > Like AWARD, AMI, Phoenix, etc, BIOS, that have support for a great 
> > variety of chipsets and CPUs, and are compiled with 
> required modules 
> > for each motherboard.
> > 
> 
> A modular BIOS designed for qemu is ok (e.g. VGABios vs Bochs 
> BIOS vs some other hand-written BIOS) but supporting a 
> commercial BIOS written for actual hardware is another 
> matter. This is very difficult as such a BIOS will expect 
> different hardware in different places. Not to mention adding 
> support for different types of motherboards/ROM chips. Its 
> easier to just fix the current qemu BIOS.
> 
> P.S.
> 
> Someone is working on that iirc.... posted to the list a 
> while back. They loaded qemu directly from a bootloader (so 
> there was no host OS, only a guest
> OS) and did some hacking so qemu could access the host BIOS 
> directly. So it is possible, just very hard.
> 
> > > I don't think that the chipset particularly cares what extended 
> > > instructions the CPU can execute... However, BIOS support we are 
> > > definitely lacking. IIRC, the BIOS we are using doesn't 
> do any PCI 
> > > setup
> > > - so we rely on some code in pc.c and pci.c to make the 
> chipset look 
> > > configured and to set up the BARs.
> > > 
> > > --
> > > Antony T Curtis <antony.t.curtis@ntlworld.com>
> 
> --
> Infinite complexity begets infinite beauty.
> Infinite precision begets infinite perfection.
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] (Before) RFC for new features

[Fabrice Bellard]

Natalia Portillo wrote:
> Well I didn't say about using a real commercial modular BIOS, but making the
> QEMU BIOS modular as the commercial ones are.
> 
> Making the first, will be a HARD task, and, Award/AMI/Phoenix/MrBIOS won't
> let us to do that.
> Both VMWare and VirtualPC pays for using a commercial BIOS in their
> products. 

I don't care about the BIOS as long as it works with the hardware that 
QEMU emulates. I am very satisfied with the current Bochs BIOS. The only 
missing stuff is PCI init (it is currently done in QEMU), but it is very 
easy to add.

Of course if other people want to try other BIOSes, they are free to do 
it :-)

Fabrice.

Re: [Qemu-devel] RFC for new features

[Fabrice Bellard]

About the new features: none of them will be for the upcoming 0.6.0 
release. Maybe for 0.6.1.

Some comments:

- The old console will still be available with a command line option.

- The disk images will support both free sector compression (as cow 
images) and "read-only" zlib based block compression, so that the 
FreeOSZoo disk images do not need to be decompressed. QEMU itself will 
never store compressed blocks as it is more complicated and less useful.

- The disk images will support AES based encryption.

- There will be no plugin system in the near future. Such systems are 
mainly useful for closed source project, which QEMU is not. Moreover, as 
in ffmpeg, I don't want to bother about binary compatibility and API 
stability at this stage of the project.

- The first version of config file will just contain the same as the 
command line options. Then someday there will be more options to add new 
hardware dynamically and to change some of its properties... but it will 
never use XML !

Fabrice.

Re: [Qemu-devel] RFC for new features

[Antony T Curtis]

On Sat, 2004-07-10 at 15:03, Fabrice Bellard wrote:
> About the new features: none of them will be for the upcoming 0.6.0 
> release. Maybe for 0.6.1.
> 
> Some comments:
> 
> - The old console will still be available with a command line option.

Cool,

> - The disk images will support both free sector compression (as cow 
> images) and "read-only" zlib based block compression, so that the 
> FreeOSZoo disk images do not need to be decompressed. QEMU itself will 
> never store compressed blocks as it is more complicated and less useful.

How about lzo compression? It is vary fast for compression and
decompression and doesn't require much memory to operate.

<snip>
-- 
Antony T Curtis <antony.t.curtis@ntlworld.com>

Re: [Qemu-devel] RFC for new features

[Fabrice Bellard]

Antony T Curtis wrote:
> On Sat, 2004-07-10 at 15:03, Fabrice Bellard wrote:
> 
>>About the new features: none of them will be for the upcoming 0.6.0 
>>release. Maybe for 0.6.1.
>>
>>Some comments:
>>
>>- The old console will still be available with a command line option.
> 
> 
> Cool,
> 
> 
>>- The disk images will support both free sector compression (as cow 
>>images) and "read-only" zlib based block compression, so that the 
>>FreeOSZoo disk images do not need to be decompressed. QEMU itself will 
>>never store compressed blocks as it is more complicated and less useful.
> 
> 
> How about lzo compression? It is vary fast for compression and
> decompression and doesn't require much memory to operate.

I just want that downloaded images can be easily used. Compression for 
writing is less useful because hard disks are big enough, so it won't be 
available in the first implementation. I agree that LZO would be a good 
choice for a read/write compression system.

Fabrice.

Re: [Qemu-devel] (Before) RFC for new features

[Hetz Ben Hamo]

> P.S.
>
> Someone is working on that iirc.... posted to the list a while back. They
> loaded qemu directly from a bootloader (so there was no host OS, only a
> guest OS) and did some hacking so qemu could access the host BIOS directly.
> So it is possible, just very hard.

URL?

Thanks,
Hetz

[Qemu-devel] RFC for new features

[Fabrice Bellard]

Hi,

As porting the SDL version to other OSes than Linux seems to become an 
important issue, I plan to add the following features in the next days:

- Virtual console handled by SDL (Ctrl-Shift-F1 to get the guest screen, 
Ctrl-Shift-F2 to get the monitor shell, and maybe Ctrl-Shift-F3 for 
various logs).

- Support for more compressed and cow disk images formats so that 
filesystems without hole support can use cow disk images too.

- New tool to create disk images, to compress them and to convert 
between any disk image formats.

- Config file support (syntax: qemu mypc.qmu)

Comments ?

Fabrice.

[Qemu-devel] (Before) RFC for new features

[Hetz Ben Hamo]

Fabrice Bellard wrote:
> Hi,
> 
> As porting the SDL version to other OSes than Linux seems to become an 
> important issue, I plan to add the following features in the next days:

I would like to raise an issue which I'm not sure if it was looked closely..

Lets see what do we have today:

* 3 Busses (ISA, ISA PnP, PCI)
* 4 Processors (Pentium Pro, Arm, PPC, Sparc)
* 4 Network cards (NE2000 ISA, AMD PCNet, NE2000 PCI, 3COM PnP ISA)
* 2 Graphics cards (VESA, Cirrus Logic)
* 2 Bioses (PPC BIOS, Generic Bochs/QEMU BIOS)
* 2 hard drive formats (RAW, COW)

And I'm sure I have forgotten few things, not mentioning QEMU is not 
that publicallyy published (wait for Slashdot effect)..

I think that something needed here: A plugin mechanism.

What I was thinking that QEMU missing is a way that upon running QEMU 
(either first time or doing a first scan), it should "scan" for new 
hardware and register them as plugins (with depenedencies, so you cannot 
use PPC BIOS with Pentium Pro processor ;) ). That way a new plugin 
(either open or closed source) can register itself and a user can simply 
use it without having to configure everything..

The method I was thinking was something like Xine player uses when 
initializing the player..

Fabrice, others, what do you think about it?

Thanks,
Hetz

Re: [Qemu-devel] (Before) RFC for new features

[Johannes Schindelin]

Hi,

On Sat, 10 Jul 2004, Hetz Ben Hamo wrote:
> What I was thinking that QEMU missing is a way that upon running QEMU
> (either first time or doing a first scan), it should "scan" for new
> hardware and register them as plugins (with depenedencies, so you cannot
> use PPC BIOS with Pentium Pro processor ;) ). That way a new plugin
> (either open or closed source) can register itself and a user can simply
> use it without having to configure everything..

There is already a plugin system. It requires you to recompile everytime
you add a new piece of hardware, though. I don't think this is a problem
as most likely you will have to recompile anyway to make sure the plugin
uses the same header files as qemu's core.

Ciao,
Dscho