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

Re: [Qemu-devel] RFC for new features

[Natalia Portillo]

Support for accessing hardware disks under Win32 (making an ISO of a CD
is difficult).

> -----Mensaje original-----
> De: qemu-devel-bounces+iosglpgc=teleline.es@nongnu.org 
> [mailto:qemu-devel-bounces+iosglpgc=teleline.es@nongnu.org] 
> En nombre de Fabrice Bellard
> Enviado el: jueves, 08 de julio de 2004 19:14
> Para: qemu-devel@nongnu.org
> Asunto: [Qemu-devel] RFC for new features
> 
> 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 mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

RE: [Qemu-devel] RFC for new features

[Natalia Portillo]

I forgot to propose:

Select what CPU we want to emulate.
For example under the x86 emulation, what if I want to run a system that
does not work with the current emulated CPU (Pentium Pro) but does with an
older one (for example a 486DX4).
Also in PowerPC emulation, it should be interesting as the 601 has opcodes
that no other 6xx/7xx PowerPC have (that are from POWER). 

> -----Mensaje original-----
> De: qemu-devel-bounces+iosglpgc=teleline.es@nongnu.org 
> [mailto:qemu-devel-bounces+iosglpgc=teleline.es@nongnu.org] 
> En nombre de Natalia Portillo
> Enviado el: jueves, 08 de julio de 2004 21:50
> Para: qemu-devel@nongnu.org
> Asunto: Re: [Qemu-devel] RFC for new features
> 
> Support for accessing hardware disks under Win32 (making an 
> ISO of a CD is difficult).
> 
> > -----Mensaje original-----
> > De: qemu-devel-bounces+iosglpgc=teleline.es@nongnu.org
> > [mailto:qemu-devel-bounces+iosglpgc=teleline.es@nongnu.org]
> > En nombre de Fabrice Bellard
> > Enviado el: jueves, 08 de julio de 2004 19:14
> > Para: qemu-devel@nongnu.org
> > Asunto: [Qemu-devel] RFC for new features
> > 
> > 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 mailing list
> > Qemu-devel@nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

RE: [Qemu-devel] RFC for new features

[Jocelyn Mayer]

On Fri, 2004-07-09 at 00:48, Natalia Portillo wrote:
> I forgot to propose:
> 
> Select what CPU we want to emulate.
> For example under the x86 emulation, what if I want to run a system that
> does not work with the current emulated CPU (Pentium Pro) but does with an
> older one (for example a 486DX4).
> Also in PowerPC emulation, it should be interesting as the 601 has opcodes
> that no other 6xx/7xx PowerPC have (that are from POWER). 

I agree with this.

I wonder if the best is to choose the CPU (ie 601/603/604/G3/G4 for
PPC...) or to choose a coherent hw entity (PowerMac G3, ...). I think
the first approach is good for ones who want to emulate exotic hardware
configurations but the second is more usable for end-users.

The good approach may be to be able to select all motherboard components
but have some predefined templates that describes well known
motherboards.

-- 
Jocelyn Mayer <l_indien@magic.fr>
Never organized

RE: [Qemu-devel] RFC for new features

[Natalia Portillo]

Hi

> > Select what CPU we want to emulate.
> > For example under the x86 emulation, what if I want to run a system 
> > that does not work with the current emulated CPU (Pentium Pro) but 
> > does with an older one (for example a 486DX4).
> > Also in PowerPC emulation, it should be interesting as the 601 has 
> > opcodes that no other 6xx/7xx PowerPC have (that are from POWER).
> 
> I agree with this.
> 
> I wonder if the best is to choose the CPU (ie 601/603/604/G3/G4 for
> PPC...) or to choose a coherent hw entity (PowerMac G3, ...). 
> I think the first approach is good for ones who want to 
> emulate exotic hardware configurations but the second is more 
> usable for end-users.
What about both?
 
> The good approach may be to be able to select all motherboard 
> components but have some predefined templates that describes 
> well known motherboards.
Yeah.
And think that in PowerMacintosh emulation, there can be almost identically
motherboards, but are a different computer (check Gestalt value, and OF one,
both says the computer model).

Re: [Qemu-devel] RFC for new features

[Thomas Munn]

[-- Attachment #1: Type: text/plain, Size: 410 bytes --]

Things I think would be nice:
 
1.  Definately a DISK manager/compressor ala vmware disk images (so I
don't have to waste 4+gb if I don't have a full fileysystem!)
2.  Command line support for restoring state files (instead of having
to start and then load state in monitor machines) -state filename?
3.  support for -march athlon-xp and -march athlon-xp (and other x-86
processors) for faster binary
 
Thomas

[-- Attachment #2: HTML --]
[-- Type: text/html, Size: 737 bytes --]

Re: [Qemu-devel] RFC for new features

[Johannes Schindelin]

Hi,

On Thu, 8 Jul 2004, Thomas Munn wrote:
> 1.  Definately a DISK manager/compressor ala vmware disk images (so I
> don't have to waste 4+gb if I don't have a full fileysystem!)

Fabrice already mentioned that, right? I would favor using cloop devices,
i.e. using the toolset from cloop to create compressed "devices". Knoppix
uses this system to pack much more than 700MB on a CD.

The advantage of cloop as compared to gzip'ed filesystem: Everytime you
seek in the file, with gzip you have to either have stored a certain zlib
state or decompress the whole file up to that point. With cloop this
problem is solved.

> 2.  Command line support for restoring state files (instead of having
> to start and then load state in monitor machines) -state filename?

This is the "-V" option in the VNC patch. For this to work we also need a
save handler for the keyboard. I will prepare that patch later today.

The config file came up a few times. I don't know. For those who
absolutely have to have it, maybe just a file which has exactly the same
syntax as the command line so you don't have to learn two ways to say the
same thing. For sure not an overkill like XML! The extended markup
language is good to markup complex structures, certainly not something as
trivial as a qemu command line.

The Ctrl-Shift-F2 monitor thing is a cute idea, but I really would like to
at least optionally retain the old style monitor.

Ciao,
Dscho

Re: [Qemu-devel] RFC for new features

[Julian Seward]

On Friday 09 July 2004 11:02, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 8 Jul 2004, Thomas Munn wrote:
> > 1.  Definately a DISK manager/compressor ala vmware disk images (so I
> > don't have to waste 4+gb if I don't have a full fileysystem!)
>
> Fabrice already mentioned that, right? I would favor using cloop devices,
> i.e. using the toolset from cloop to create compressed "devices". Knoppix
> uses this system to pack much more than 700MB on a CD.
>
> The advantage of cloop as compared to gzip'ed filesystem: Everytime you
> seek in the file, with gzip you have to either have stored a certain zlib
> state or decompress the whole file up to that point. With cloop this
> problem is solved.

I don't think it's a good idea to compress the real data in the filesystem
it reduces performance and adds complexity.  All that's needed is
to modify the current cow disk system so that unused sectors don't take
any (much) space in the .cow file _without_ having to rely on filesystems
which support holes in files.

vmware (afaik) doesn't really compress disk images, at least not
compression in the gzip/zlib sense.  What it does is understand the
filesystem in the disk image, so it knows where the unused sectors are,
and arranges for them to take more or less zero space in the .vmdk
file.

> The Ctrl-Shift-F2 monitor thing is a cute idea, but I really would like to
> at least optionally retain the old style monitor.

I agree it is a good idea.  Mostly I just want to run WinXP without
having to have a seperate xterm for the monitor, so I vote in favour
of this one.

J

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

Re: [Qemu-devel] RFC for new features

[Antony T Curtis]

On Thu, 2004-07-08 at 19:14, 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:
> 
> - 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).

sounds nice ... but there are a number of benefits with having the
monitor shell as is...

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

These sounds great

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

It would be a nice feature if the hw devices can be dynamically loaded
and 'installed' as per the config file.

> Comments ?
> 
> Fabrice.
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>  FLAGS (\Seen))
-- 
Antony T Curtis <antony.t.curtis@ntlworld.com>

Re: [Qemu-devel] RFC for new features

[Jim C. Brown]

On Thu, Jul 08, 2004 at 07:54:46PM +0100, Antony T Curtis wrote:
> On Thu, 2004-07-08 at 19:14, 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:
> > 
> > - 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).
> 
> sounds nice ... but there are a number of benefits with having the
> monitor shell as is...

I agree. Perhaps on Linux this could be optional (i.e. with '-console-monitor'
you get the old monitor, but on hosts that dont support those (i.e. Windows)
that option would be ignored).

> > - Config file support (syntax: qemu mypc.qmu)
> 
> It would be a nice feature if the hw devices can be dynamically loaded
> and 'installed' as per the config file.

Yes. I have a script that gives qemu config file support, but all it does is
wrap the command line parameters. (It is still very useful and I'll probably
keep it alive since it has a few things in it that qemu prolly wont, such as
support for using vdeq.)

> 
> > Comments ?
> > 
> > Fabrice.
> > 
> > 
> > 
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/qemu-devel
> >  FLAGS (\Seen))
> -- 
> Antony T Curtis <antony.t.curtis@ntlworld.com>
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

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

Re: [Qemu-devel] RFC for new features

[Jernej Simončič]

On Thursday, July 8, 2004, 21:36:44, Jim C. Brown wrote:

> I agree. Perhaps on Linux this could be optional (i.e. with '-console-monitor'
> you get the old monitor, but on hosts that dont support those (i.e. Windows)
> that option would be ignored).

Windows has console support - and the program doesn't have to be compiled
for console to use it (just look at eg. Gimp - starts with no console, and
if there are problems [or, if you eg. use --verbose switch], a console is
open - but only if you didn't redirect stdout and stderr).

-- 
< Jernej Simoncic ><><><><>< http://deepthought.ena.si/ >

When the going gets tough, everybody leaves.
       -- Lynch's Law

Re: [Qemu-devel] RFC for new features

[Jim C. Brown]

On Thu, Jul 08, 2004 at 10:31:10PM +0200, Jernej Simon?i? wrote:
> On Thursday, July 8, 2004, 21:36:44, Jim C. Brown wrote:
> 
> > I agree. Perhaps on Linux this could be optional (i.e. with '-console-monitor'
> > you get the old monitor, but on hosts that dont support those (i.e. Windows)
> > that option would be ignored).
> 
> Windows has console support - and the program doesn't have to be compiled
> for console to use it (just look at eg. Gimp - starts with no console, and
> if there are problems [or, if you eg. use --verbose switch], a console is
> open - but only if you didn't redirect stdout and stderr).

For 9x this isn't true unless the program uses the console subsystem. So a
regular GUI program has no console.

In any case, this is moving away from my original point: I prefer the old behavior.
The first is that I find it convient to be able to switch between the monitor (in
an xterm) and the SDL window just by clicking. The second is that one can redirect
qemu's input/output (and thus redirect the monitor) which makes hooking into
the monitor (from perhaps a GUI wrapper - I am told that is what qemu workstation
does) trivial.

> 
> -- 
> < Jernej Simoncic ><><><><>< http://deepthought.ena.si/ >
> 
> When the going gets tough, everybody leaves.
>        -- Lynch's Law
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

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

Re: [Qemu-devel] RFC for new features

[Jernej Simončič]

On Thursday, July 8, 2004, 23:04:41, Jim C. Brown wrote:

> For 9x this isn't true unless the program uses the console subsystem. So a
> regular GUI program has no console.

Gimp (or, to be more precise GTK+/GLib) somehow get around this limit - I
installed Windows 98 in qemu just to reconfirm, and when run normally, there
is no console, but if you add the --verbose switch (or, if an error occurs),
a console Window is opened.

-- 
< Jernej Simoncic ><><><><>< http://deepthought.ena.si/ >

Only God can make a random selection.
       -- Levy's Ninth Law of the Disillusionment of the True Liberal

Re: [Qemu-devel] RFC for new features

[Jim C. Brown]

On Fri, Jul 09, 2004 at 12:37:59AM +0200, Jernej Simon?i? wrote:
> On Thursday, July 8, 2004, 23:04:41, Jim C. Brown wrote:
> 
> > For 9x this isn't true unless the program uses the console subsystem. So a
> > regular GUI program has no console.
> 
> Gimp (or, to be more precise GTK+/GLib) somehow get around this limit - I
> installed Windows 98 in qemu just to reconfirm, and when run normally, there
> is no console, but if you add the --verbose switch (or, if an error occurs),
> a console Window is opened.
> 

So we are agreed then: We like the old monitor and we want to keep it.

> -- 
> < Jernej Simoncic ><><><><>< http://deepthought.ena.si/ >
> 
> Only God can make a random selection.
>        -- Levy's Ninth Law of the Disillusionment of the True Liberal
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

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

Re: [Qemu-devel] RFC for new features

[Jocelyn Mayer]

On Thu, 2004-07-08 at 20:54, Antony T Curtis wrote:
> On Thu, 2004-07-08 at 19:14, 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:
> > 
> > - 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).

Great !
I'd also like to have a "device interface" to be able to create and use
a new console, mainly for BIOS output and debug without having to use a
serial port or qemu monitor.

[...]

> > - Config file support (syntax: qemu mypc.qmu)
> 
> It would be a nice feature if the hw devices can be dynamically loaded
> and 'installed' as per the config file.

Sounds great only if the whole configuration can be overriden using the
command line. It's a real pain having to edit config files everytime you
need to change a parameter for testing...
But why mypc ? my_hw is more appropriate :-))

-- 
Jocelyn Mayer <l_indien@magic.fr>
Never organized

Re: [Qemu-devel] RFC for new features

[Karel Gardas]

On Thu, 8 Jul 2004, Fabrice Bellard wrote:

> Comments ?

I would like to see qemu faster in system emulation of x86 on x86 -- if it
is ever possible -- vide my email in archive about speed of compilation on
x86/solaris9 on x86 host.

Thanks,

Karel
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

Re: [Qemu-devel] RFC for new features

[vaise]

On Thursday 08 July 2004 21:00, Karel Gardas wrote:
> I would like to see qemu faster in system emulation of x86 on x86 -- if it
> is ever possible 
This is the most important thing for me too. I know it is not easy. But it 
could be done by Little steps.


On Thursday 08 July 2004 21:05, Julian Seward wrote:
> I agree.  Fabrice, it would be good to do a stable 0.5.6 release
> before moving on to this new stuff.  It's been quite a while
> since 0.5.5 -- almost 2 months -- and I get the impression that quite
> a lot has improved in that time.
I agree too.

Re: [Qemu-devel] RFC for new features

[Jean-Michel POURE]

> Comments ?

Sounds great. These features will probably benefit FreeOSZoo users a lot. 

When testing QEMU under Windows, it seemed like there was no CD-ROM access in  
qemu.exe. Are there plans or existing patches to access CD-ROM in the Windows 
port of QEMU?

Regards, Jean-Michel

Re: [Qemu-devel] RFC for new features

[Brad Watson]

Hi Fabrice,

XML format for the config file ?

Device emulation with code virtualization for x86 on
x86 and ppc on ppc (ala lillyvm, colinux like
techniques, or ??? ) ?

Thanks again to you, and everyone else that has
contributed to this project for all of your excellent
work.

Regards,

Brad Watson
--- Fabrice Bellard <fabrice@bellard.org> 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:
> 
> - 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 mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 



		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 

Re: [Qemu-devel] RFC for new features

[Jan Dittmer]

[-- Attachment #1: Type: text/plain, Size: 330 bytes --]

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:

Booting Windows XP (see my mail from earlier this week on the mailing 
list). I could really need some guidance for troubleshooting...

Thanks,

Jan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [Qemu-devel] RFC for new features

[malc]

On Thu, 8 Jul 2004, 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:
>
> - 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)

If it would have some sort of generic interface for devices.
(Though i must say that prunanciation of `qmu' puzzles me)

-- 
mailto:malc@pulsesoft.com

Re: [Qemu-devel] RFC for new features

[Jim C. Brown]

On Thu, Jul 08, 2004 at 10:24:14PM +0000, malc wrote:
> > - Config file support (syntax: qemu mypc.qmu)
> 
> If it would have some sort of generic interface for devices.
> (Though i must say that prunanciation of `qmu' puzzles me)

What do you mean by 'generic interface' ? The ability to set the IRQ/IOMEM/DMA
of various devices (NE2K, SB16, etc)? That would be very useful.

qmu looks like Q - Mu to me (where Q is the letter Q and Mu is the Greek letter
mu).

> 
> -- 
> mailto:malc@pulsesoft.com
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

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