[Qemu-devel] RFC for new features

[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] Re: RFC for new features

[Emmanuel Charpentier]

Dear Fabrice,

First and foremost, thank you for this marvelmous piece of work !

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

I fail to see the point for use in a GUI. Maybe for "autonomous" screens (à 
la Linux virtual consoles) ?

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

Nice idea ! Maybe also support for raw devices (dedicating a full HD to a 
given guest OS might be quite justifiable in some setups...) ?

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

Corrolary of the previous one.

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

This one is *the* most important ! enables easy use and configuration by 
non-technical users (hint : use an easily-parsed format, allowing for GUI 
frontends).

> Comments ?

I have some further ideas, which need to grow up a bit before public 
exposure. Furthermore, I'm still at odds with some difficulties with the 
current version (CVS from end June), that I want to solve before asking for 
more ...

					Emmanuel Charpentier

Re: [Qemu-devel] Re: RFC for new features

[Antony T Curtis]

On Thu, 2004-07-08 at 19:46, Emmanuel Charpentier wrote:

<snip>

> > - Support for more compressed and cow disk images formats so that 
> > filesystems without hole support can use cow disk images too.
> 
> Nice idea ! Maybe also support for raw devices (dedicating a full HD to a 
> given guest OS might be quite justifiable in some setups...) ?

Hmm... I am already able to use raw devices, both CDROM and Hard disks.

One of the fun things I do is to boot FreeBSD Guest off a COW backed
against the same partition that the FreeBSD Host is running.

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

Re: [Qemu-devel] Re: RFC for new features

[Julian Seward]

> Emmanuel Charpentier wrote:
>
> 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).

Good idea.  Yes.

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

Well, maybe, but not critical.

> I'm still at odds with some difficulties with the
> current version (CVS from end June), that I want to solve before asking for
> more ...

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.

J

Re: [Qemu-devel] Re: RFC for new features

[Jim C. Brown]

On Thu, Jul 08, 2004 at 08:46:47PM +0200, Emmanuel Charpentier wrote:
> >- Config file support (syntax: qemu mypc.qmu)
> 
> This one is *the* most important ! enables easy use and configuration by 
> non-technical users (hint : use an easily-parsed format, allowing for GUI 
> frontends).
> 
> 					Emmanuel Charpentier

You can have that now. The shell script called vqemu makes using a configuration
file for qemu easy. It just uses the config file to figure out which command
line parameters to pass to qemu. (I'd expect the .qmu config file to be more
bochs-like myself (the inability to change the default IRQ/IO addrs can be
frustrating when installing a new OS in qemu for the first time).) The caveat
is that the shell script won't work in Windows unless (maybe) you use Cygwin bash.

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

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 (Console under Windows)

[Filip Navara]

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.
>
This isn't problem at all, you can use the AllocConsole or AttachConsole 
API calls, but I think that's not needed. I still have a patch on my HDD 
that makes QEMU a console application and fixes the keyboard input (to 
the monitor) on Windows, but I doubt it would apply cleanly to current CVS.

Regards,
Filip

OT: Re: [Qemu-devel] RFC for new features

[Antony T Curtis]

On Thu, 2004-07-08 at 22:04, Jim C. Brown wrote:
> 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.

Reminds me of my OS/2 days... a PM (GUI) app doesn't have a console....
And a console app cannot open windows. But there is a hack (involves
writing to undocumented data) which allows a console app have windows. I
discovered this by accident and used it for a native OS/2 Xlib
implementation (Xlib->OS/2 GDI, may be googled by keyword "everblue")

> 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
-- 
Antony T Curtis <antony.t.curtis@ntlworld.com>

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.

[Qemu-devel] Re: RFC for new features

[Emmanuel Charpentier]

Fabrice Bellard wrote:

[ that he wants our whishlists before porting the SDL version to other 
platforms. ]

Well, I have some wishes, but I'm not sure they fit well in your current 
worplans. Please feel free to discard them :

1) There are still some CPU emulation issues ; I can't diagnose them but I 
can prove that they exist :
	After Win2k installation (whatever version), I have been unable to install 
Mozilla 1.6. I have been able to install Mozilla 1.7, though. Windows being 
... well, Windows, I've been unable to locate error logs. Go figure ...
	It tool me 4 trials to find a Win2k version that would allow for the 
installation of Office 2000. I tried to install Office 97 twice, with no 
luck. I didn't retry with the "correct" installation of Win2k.
	The SP4 patch doesn't install (error a short while after unpacking)
	The "disk full" issue while installing Win2k still happens every time.

None of this happens using the very same files/disks while installing on 
real hardware.

2) There are device emulation issues :
	The current cirrusvga is a vast improvement over the previous bochs 
device. However, pushing available memory to more than 4 Mb wold allow for 
better resolutions : 1024x768x16 is a bit limiting in some uses.
	There are still serious issues with audio emulation. The current SB16/AXE 
device can do simple things (playing the "opening" .wav file, etc ...), but 
trying to install Dragon voice recognition still fails very early (at the 
first sound that the installer tries to play), and crashes the whole 
emulation (the graphics window diseappear, and you're left with no mouse).

3) I still think that a virtualizer based on QEMU, while quite a bit more 
limited in scope than QEMU itself, would be extremely useful : letting 
user-level code not touching hardware run native and trapping anything 
related to I/O, memory-mapped I/O or changing protection level (allowing to 
run *that* on the emulated CPU) would allow for a nice acceleration. This 
would be a boon for all the people using QEMU to run hardware available for 
their CPU but not their platform (think Windows user running Linux/FreeBSD 
software and vice-versa), which may well be a majority among qemu users.

None of this is absolutely critical, and QEMU is already *extremely* 
useable (and useful ! ) as it is. The most critical are probably the CPU 
emulation issues, the least the virtualizer.

Hope this helps,

					Emmanuel Charpentier

Re: [Qemu-devel] Re: RFC for new features

[Antony T Curtis]

On Fri, 2004-07-09 at 21:27, Emmanuel Charpentier wrote:
> Fabrice Bellard wrote:
> 
> [ that he wants our whishlists before porting the SDL version to other 
> platforms. ]
> 
> Well, I have some wishes, but I'm not sure they fit well in your current 
> worplans. Please feel free to discard them :
> 
> 1) There are still some CPU emulation issues ; I can't diagnose them but I 
> can prove that they exist :
> 	After Win2k installation (whatever version), I have been unable to install 
> Mozilla 1.6. I have been able to install Mozilla 1.7, though. Windows being 
> .. well, Windows, I've been unable to locate error logs. Go figure ...
> 	It tool me 4 trials to find a Win2k version that would allow for the 
> installation of Office 2000. I tried to install Office 97 twice, with no 
> luck. I didn't retry with the "correct" installation of Win2k.
> 	The SP4 patch doesn't install (error a short while after unpacking)
> 	The "disk full" issue while installing Win2k still happens every time.
> 
> None of this happens using the very same files/disks while installing on 
> real hardware.

Yes - I think that there are instances where the simulation is wrong...
OS/2 Warp 3 seems to suffer from GPFs when running applications
consistantly and repeatably.

> 2) There are device emulation issues :
> 	The current cirrusvga is a vast improvement over the previous bochs 
> device. However, pushing available memory to more than 4 Mb wold allow for 
> better resolutions : 1024x768x16 is a bit limiting in some uses.
> 	There are still serious issues with audio emulation. The current SB16/AXE 
> device can do simple things (playing the "opening" .wav file, etc ...), but 
> trying to install Dragon voice recognition still fails very early (at the 
> first sound that the installer tries to play), and crashes the whole 
> emulation (the graphics window diseappear, and you're left with no mouse).

Well - the CL-GD544X chips can only handle 4MB of memory, maximum. For
larger framebuffers, we would have to emulate a different video chip -
If we wish to stick to Cirrus Logic, The Laguna CL-GD546x chips can
address up to 16MB I think.... Of course, there are many other chips - I
think perhaps the Tseng Labs ET6000 may be simple enough to simulate and
would support a larger framebuffer.

> 3) I still think that a virtualizer based on QEMU, while quite a bit more 
> limited in scope than QEMU itself, would be extremely useful : letting 
> user-level code not touching hardware run native and trapping anything 
> related to I/O, memory-mapped I/O or changing protection level (allowing to 
> run *that* on the emulated CPU) would allow for a nice acceleration. This 
> would be a boon for all the people using QEMU to run hardware available for 
> their CPU but not their platform (think Windows user running Linux/FreeBSD 
> software and vice-versa), which may well be a majority among qemu users.

Hmm... If a virtualizer is what is wanted, there are several options
already available... "Xen" is supposedly very good.
I think QEmu's strength is that it is not a virtualizer - it is a system
simulator.

Perhaps work can be done to get better performance when simulating the a
similar system to the host... but perhaps there would be more real
benefit in attemting to make the translator optimise the code it
generates... LUA has already been mentioned as a possible alternative
code generator.

> None of this is absolutely critical, and QEMU is already *extremely* 
> useable (and useful ! ) as it is. The most critical are probably the CPU 
> emulation issues, the least the virtualizer.
> 
> Hope this helps,
> 
> 					Emmanuel Charpentier
> 
> 
> 
> _______________________________________________
> 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] Re: RFC for new features

[Derek Fawcus]

On Fri, Jul 09, 2004 at 11:13:30PM +0100, Antony T Curtis wrote:
> > 2) There are device emulation issues :
> > 	The current cirrusvga is a vast improvement over the previous bochs 
> > device. However, pushing available memory to more than 4 Mb wold allow for 
> > better resolutions : 1024x768x16 is a bit limiting in some uses.

Huh - I don't think there are any specific pitch restrictions on this chipset.

4M should allow 1280x1024@24bpp (or 1152x864@32bpp).  Is that not enougth?

> Well - the CL-GD544X chips can only handle 4MB of memory, maximum. For
> larger framebuffers, we would have to emulate a different video chip -
> If we wish to stick to Cirrus Logic, The Laguna CL-GD546x chips can
> address up to 16MB I think....

Nope.  Only 8M.  The architecture has scope for 2 RAMBUS channels,  but they
only implemented chips with 1 RAMBUS channel.  One of the fields in the
channel control register is 3 bits,  identifying the number of 1M ram banks
available...  (Someone who has spent too long playing with Laguna chips).

Besides,  the Laguna is a more complex beast with a 3 operand BitBLT engine...

DF

[Qemu-devel] 3Dfx... Just guessing

[Natalia Portillo]

Hi.

I'm just thinkig...
Guessing...

Is it possible to emulate a 3Dfx chip?
There are available documents, etc?

The 3Dfx are the most supported 3D cards.
Have drivers for DOS, Windows, MacOS, Linux, BSD, any system where XFree86
works, etc.

But I think that nVidia has "ghosted" all available information, as they did
with the 3Dfx webpage and drivers. :(

Re: [Qemu-devel] 3Dfx... Just guessing

[Fabrice Bellard]

SiS6326 seems a better choice because it is documented and well 
supported. It was my target before I improved the submitted Cirrus patch.

Fabrice.

Natalia Portillo wrote:
> Hi.
> 
> I'm just thinkig...
> Guessing...
> 
> Is it possible to emulate a 3Dfx chip?
> There are available documents, etc?
> 
> The 3Dfx are the most supported 3D cards.
> Have drivers for DOS, Windows, MacOS, Linux, BSD, any system where XFree86
> works, etc.
> 
> But I think that nVidia has "ghosted" all available information, as they did
> with the 3Dfx webpage and drivers. :(
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

RE: [Qemu-devel] 3Dfx... Just guessing

[Natalia Portillo]

Well I wans't proposing 3Dfx for be emulated, but just asking if it is
possible and if there is the documentation. 

> -----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: sábado, 10 de julio de 2004 14:07
> Para: qemu-devel@nongnu.org
> Asunto: Re: [Qemu-devel] 3Dfx... Just guessing
> 
> SiS6326 seems a better choice because it is documented and 
> well supported. It was my target before I improved the 
> submitted Cirrus patch.
> 
> Fabrice.
> 
> Natalia Portillo wrote:
> > Hi.
> > 
> > I'm just thinkig...
> > Guessing...
> > 
> > Is it possible to emulate a 3Dfx chip?
> > There are available documents, etc?
> > 
> > The 3Dfx are the most supported 3D cards.
> > Have drivers for DOS, Windows, MacOS, Linux, BSD, any system where 
> > XFree86 works, etc.
> > 
> > But I think that nVidia has "ghosted" all available information, as 
> > they did with the 3Dfx webpage and drivers. :(
> > 
> > 
> > 
> > _______________________________________________
> > 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] 3Dfx... Just guessing

[Ishwar Rattan]

On Sat, 10 Jul 2004, Natalia Portillo wrote:

> Well I wans't proposing 3Dfx for be emulated, but just asking if it is
> possible and if there is the documentation.
>
Sure, as long as you do the work :-)

-ishwar

RE: [Qemu-devel] 3Dfx... Just guessing

[Natalia Portillo]

> > Well I wans't proposing 3Dfx for be emulated, but just 
> asking if it is 
> > possible and if there is the documentation.
> >
> Sure, as long as you do the work :-)
Tech me how to, and I'll do.

Re: [Qemu-devel] 3Dfx... Just guessing

[Jim C. Brown]

On Sat, Jul 10, 2004 at 03:44:13AM +0100, Natalia Portillo wrote:
> Hi.
> 
> I'm just thinkig...
> Guessing...
> 
> Is it possible to emulate a 3Dfx chip?
> There are available documents, etc?
> 
> The 3Dfx are the most supported 3D cards.
> Have drivers for DOS, Windows, MacOS, Linux, BSD, any system where XFree86
> works, etc.
> 
> But I think that nVidia has "ghosted" all available information, as they did
> with the 3Dfx webpage and drivers. :(
> 
> 

I have a PCI 3Dfx chip, so if we go this route I may be able to help.
 
> _______________________________________________
> 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] 3Dfx... Just guessing

[Gianni Tedesco]

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

On Sat, 2004-07-10 at 21:10 -0400, Jim C. Brown wrote:
> On Sat, Jul 10, 2004 at 03:44:13AM +0100, Natalia Portillo wrote:
> > Hi.
> > 
> > I'm just thinkig...
> > Guessing...
> > 
> > Is it possible to emulate a 3Dfx chip?
> > There are available documents, etc?
> > 
> > The 3Dfx are the most supported 3D cards.
> > Have drivers for DOS, Windows, MacOS, Linux, BSD, any system where XFree86
> > works, etc.
> > 
> > But I think that nVidia has "ghosted" all available information, as they did
> > with the 3Dfx webpage and drivers. :(

I'm uploading the voodoo 3 (avenger) specs to
http://www.scaramanga.co.uk/stuff/voodoo3_spec.pdf (2.9MB) for the
interested.

-- 
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re[2]: [Qemu-devel] Re: RFC for new features

[Igor Shmukler]

> > 3) I still think that a virtualizer based on QEMU, while quite a bit more 
> > limited in scope than QEMU itself, would be extremely useful : letting 
> > user-level code not touching hardware run native and trapping anything 
> > related to I/O, memory-mapped I/O or changing protection level (allowing to 
> > run *that* on the emulated CPU) would allow for a nice acceleration. This 
> > would be a boon for all the people using QEMU to run hardware available for 
> > their CPU but not their platform (think Windows user running Linux/FreeBSD 
> > software and vice-versa), which may well be a majority among qemu users.
> 
> Hmm... If a virtualizer is what is wanted, there are several options
> already available... "Xen" is supposedly very good.
> I think QEmu's strength is that it is not a virtualizer - it is a system
> simulator.

Xen requires modification of guest OS does it not? The problem with that approach (Dynamo) is that one cannot use it to run commercial OSes. 

> Perhaps work can be done to get better performance when simulating the a
> similar system to the host... but perhaps there would be more real
> benefit in attemting to make the translator optimise the code it
> generates... LUA has already been mentioned as a possible alternative
> code generator.

What is LUA? Could you please post a link?

[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

[Qemu-devel] plugins

[Hetz Ben Hamo]

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

Yes, but this plugin method is not very usefull for 3rd party plugins..

Many people don't realize one thing about QEMU which differs it from ANY 
other emulator: For the first time, you can create a "hardware card", 
write drivers for it and test it on guest OS's (Windows, Linux, *BSD, 
etc) and test it on other platforms (PPC, Sparc, ARM, once their core is 
matured).

Think about it: You can create a new PCI card without buying those all 
expensive software to simulate it, write drivers to test it and if it 
works well for your customer(s), you can do the real PCI card! Go try 
that with VMWare (you can't), BOCHS (good luck hacking their code, and 
see the speed difference), and I'm not even mentioning PPC, ARM or Sparc...

With a plugin system (all it takes is 2 files: an text/XML file which 
contains the info on this plugin, and a .so file which is the plugin 
itself) both closed source and open source developers can add lots of 
hardware to QEMU which can be used for driver development on Linux and 
on Windows (as well other guest OS's) without having the real hardware.

Have you ever thought to write driver for Linux for some hardware (which 
someone can writes a plugin) without having it? now you (potentially) can..

Just my thoughts...
Thanks,
Hetz

Re: [Qemu-devel] plugins

[Lionel Ulmer]

> With a plugin system (all it takes is 2 files: an text/XML file which 
> contains the info on this plugin, and a .so file which is the plugin 
> itself) both closed source and open source developers can add lots of 
> hardware to QEMU which can be used for driver development on Linux and 
> on Windows (as well other guest OS's) without having the real hardware.

>From what I know, QEMU is GPL'ed (only libqemu is LGPL'ed). So 'closed
source' developers can use this plug-in mechanism ... only if they do not
release their .so :-)

         Lionel

-- 
		 Lionel Ulmer - http://www.bbrox.org/

Re: [Qemu-devel] plugins

[Hetz Ben Hamo]

>>From what I know, QEMU is GPL'ed (only libqemu is LGPL'ed). So 'closed
> source' developers can use this plug-in mechanism ... only if they do not
> release their .so :-)
> 
>          Lionel

Lionel dear,

I would direct you to a previous project of Fabrice - FFMPEG, which 
Fabrice clearly indicated that he would be delight if closed source 
project would also use the FFMPEG (Macromedia for example already using 
it) and thats why he changed FFMPEG to LGPL license...

So I think that it would be logical from Fabrice to change the hardware 
parts license to LGPL or something like that.

Fabrice, whats your opinion?

Thanks,
Hetz

Re: [Qemu-devel] plugins

[Bartosz Fabianowski]

> With a plugin system (all it takes is 2 files: an text/XML file which 
> contains the info on this plugin, and a .so file which is the plugin

Binary plugins, especially closed source ones, always create the problem 
of binary compatibility. QEMU's 0.5 version number already indicates 
that although it works very well already, it is nowhere near finished. 
Features change very quickly in CVS, just think about how pci was an 
experimental option a short while back and now it's the default. I think 
it would be really hard to come up with an API that would remain stable 
for multiple releases at this point. Also, the need to maintain 
backwards compatibility would hamper QEMU's development. And finally, 
creating and maintaining an API would drain lots of resources from QEMU 
development while benefiting only very few people who want to distribute 
closed source plugins. Maybe at a much later stage, when QEMU is stable 
and mature, binary plugins will make sense. But for now, it seems like 
the source code extensibility QEMU offers is good enough.

- Bartosz

Re: [Qemu-devel] plugins

[Gianni Tedesco]

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

On Fri, 2004-07-09 at 15:35 +0200, Bartosz Fabianowski wrote:
> > With a plugin system (all it takes is 2 files: an text/XML file which 
> > contains the info on this plugin, and a .so file which is the plugin
> 
> Binary plugins, especially closed source ones, always create the problem 
> of binary compatibility. QEMU's 0.5 version number already indicates 
> that although it works very well already, it is nowhere near finished. 
> Features change very quickly in CVS, just think about how pci was an 
> experimental option a short while back and now it's the default.

Adding PCI could easily have been binary backwards compatible. Anyway,
we're not talking about necissarily having a stable or backwards
compatible ABI, just an API which makes developing new code simpler and
makes each module more flexible. It doesn't have to be there to
encourage out-of-tree development at all.

> I think 
> it would be really hard to come up with an API that would remain stable 
> for multiple releases at this point. Also, the need to maintain 
> backwards compatibility would hamper QEMU's development. And finally, 
> creating and maintaining an API would drain lots of resources from QEMU 
> development while benefiting only very few people who want to distribute 
> closed source plugins.

No developing and maintaining a stable or backwards compatible ABI would
do that. An API that doesn't have to be stable or backwards compatible
won't.

> Maybe at a much later stage, when QEMU is stable 
> and mature, binary plugins will make sense. But for now, it seems like 
> the source code extensibility QEMU offers is good enough.

No, I think plugins should be built from the main qemu source and
external developers would ideally release new plugins as source
distributions to compile against your qemu core. Anything else requires
maintaining an ABI.

Another benefit of DSO based plugins is saving memory and virtual
address space, only loading the plugins which are required. It would
also save on disk space as common code can be shared amongst the various
qemu targets.

-- 
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Qemu-devel] plugins

[Gianni Tedesco]

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

On Sat, 2004-07-10 at 14:49 +0300, Hetz Ben Hamo wrote:
> With a plugin system (all it takes is 2 files: an text/XML file which 
> contains the info on this plugin, and a .so file which is the plugin 
> itself) both closed source and open source developers can add lots of 
> hardware to QEMU which can be used for driver development on Linux and 
> on Windows (as well other guest OS's) without having the real hardware.

2 files? whatever goes in the text/xml file can go inside the DSO just
as easily...

> Have you ever thought to write driver for Linux for some hardware (which 
> someone can writes a plugin) without having it? now you (potentially) can..

All I'd like to see changed in the device API is the ability to have a
bit more control over where devices go and make all devices clean to be
used multiple times (ie. like you can have as many NICs as you like).
Then I'd like to see hw/pc.c and hw/ppc.c etc.. go away to be replaced
with 'hardware description files'...

I think that if you wanted to allow the same code to be used by each of
the different CPU emulations, that would be more difficult and could
slow things down at runtime.

-- 
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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] (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