[Qemu-devel] SMB for DOS ?

[Qemu-devel] SMB for DOS ?

[Fabrice Bellard]

Hi,

In order to have similar features to dosemu in QEMU, implementing MFS 
support in QEMU would be useful, but it would require a lot of work.

I just look at this page: 
http://freebooks.by.ru/view/SambaIn24h/ch15.htm . It seems that there is 
a free M$ SMB client for MSDOS. Did someone try it ? If it works with 
the integrated QEMU SMB facility, it can be very interesting...

Fabrice.

Re: [Qemu-devel] SMB for DOS ?

[Adrian Smarzewski]

Fabrice Bellard wrote:
> In order to have similar features to dosemu in QEMU, implementing MFS 
> support in QEMU would be useful, but it would require a lot of work.
I think QEMU should rather focus on x86-x86 speed now (to be full 
replacement of VMWare) and use as much external code for features as 
possible instead of implementing it.
QEMU is usable now. There are two disadvantages: speed of emulation 
compared to virtualisation (maybe some switch to enable virtualisation 
mode instead of emulation? ;)) and lack of USB support for example.
But I would vote for optimizations!

Re: [Qemu-devel] SMB for DOS ?

[Ryan Underwood]

On Thu, Dec 16, 2004 at 11:38:34PM +0100, Fabrice Bellard wrote:
> Hi,
> 
> In order to have similar features to dosemu in QEMU, implementing MFS 
> support in QEMU would be useful, but it would require a lot of work.
> 
> I just look at this page: 
> http://freebooks.by.ru/view/SambaIn24h/ch15.htm . It seems that there is 
> a free M$ SMB client for MSDOS. Did someone try it ? If it works with 
> the integrated QEMU SMB facility, it can be very interesting...

I've used this under "real" DOS.  It mostly works with a Samba server.
Large transfers seem to time out.  Also, Netbios name resolution via DNS
doesn't work.

There is a server package "MS-DOS Workgroup Server" that was sold
separately from the free client, that let your DOS machine become a
server.  That also mostly worked with some quirks.  The biggest thing is
that newer versions of the Samba client can't connect to it, so I had to
compile a Samba 1.x client specifically for this purpose.

-- 
Ryan Underwood, <nemesis@icequake.net>

Re: [Qemu-devel] SMB for DOS ?

[Fabrice Bellard]

Adrian Smarzewski wrote:
> Fabrice Bellard wrote:
> 
>> In order to have similar features to dosemu in QEMU, implementing MFS 
>> support in QEMU would be useful, but it would require a lot of work.
> 
> I think QEMU should rather focus on x86-x86 speed now (to be full 
> replacement of VMWare) and use as much external code for features as 
> possible instead of implementing it.
> QEMU is usable now. There are two disadvantages: speed of emulation 
> compared to virtualisation (maybe some switch to enable virtualisation 
> mode instead of emulation? ;)) and lack of USB support for example.
> But I would vote for optimizations!

It was just a suggestion for DOS users :-)

x86 on x86 optimization is now the top item on my TODO list...

Fabrice.

Re: [Qemu-devel] SMB for DOS ?

[Adrian Smarzewski]

Fabrice Bellard wrote:
> x86 on x86 optimization is now the top item on my TODO list...
Great. Win2k guest on Athlon XP 1800+ and I can see it drawing icons ;)
But is's usable and I stopped thinking about VMWare license.

Re: [Qemu-devel] SMB for DOS ?

[Johannes Schindelin]

Hi,

On Fri, 17 Dec 2004, Fabrice Bellard wrote:

> Adrian Smarzewski wrote:
> > But I would vote for optimizations!
>
> It was just a suggestion for DOS users :-)
>
> x86 on x86 optimization is now the top item on my TODO list...

That's great!

As for SMB: I had this cute idea of implementing a block driver which
simulates a FAT system, but really uses a local directory as backend. If a
block is accessed, the driver transparently maps it to the block of the
file it belongs to, or returns a read/write error if the block is not
associated with a file. This sounds crazy enough that I might try it
soon...

Ciao,
Dscho
-------
Why does a dog lick its balls?
Because it can.

Re: [Qemu-devel] SMB for DOS ?

[Fabrice Bellard]

Johannes Schindelin wrote:
> Hi,
> 
> On Fri, 17 Dec 2004, Fabrice Bellard wrote:
> 
> 
>>Adrian Smarzewski wrote:
>>
>>>But I would vote for optimizations!
>>
>>It was just a suggestion for DOS users :-)
>>
>>x86 on x86 optimization is now the top item on my TODO list...
> 
> 
> That's great!
> 
> As for SMB: I had this cute idea of implementing a block driver which
> simulates a FAT system, but really uses a local directory as backend. If a
> block is accessed, the driver transparently maps it to the block of the
> file it belongs to, or returns a read/write error if the block is not
> associated with a file. This sounds crazy enough that I might try it
> soon...

I had also the same idea... and it is already implemented in dosemu (it 
is only used in the MFS boot process). Implementing it in qemu would be 
very useful too (and easy given the block devices you already wrote). As 
in dosemu, it is very important that it can be made bootable (a boot 
sector must be read from a file or built dynamically).

Fabrice.

Re: [Qemu-devel] SMB for DOS ?

[Laurent Amon]

On 17 déc. 04, at 00:10, Fabrice Bellard wrote:

> Adrian Smarzewski wrote:
>> I think QEMU should rather focus on x86-x86 speed now (to be full 
>> replacement of VMWare) and use as much external code for features as 
>> possible instead of implementing it.
> x86 on x86 optimization is now the top item on my TODO list...
>
I hope you will not forget us poor mac users. Optimizing x86 on ppc 
performance would make a number of people very happy, I'd say.

Pretty please?

Lga.

optimizations, was Re: [Qemu-devel] SMB for DOS ?

[Johannes Schindelin]

Hi,

On Fri, 17 Dec 2004, Laurent Amon wrote:

>
> On 17 déc. 04, at 00:10, Fabrice Bellard wrote:
>
> > x86 on x86 optimization is now the top item on my TODO list...
> >
> I hope you will not forget us poor mac users. Optimizing x86 on ppc
> performance would make a number of people very happy, I'd say.
>
> Pretty please?

If I understand all of those ideas correctly, then it's very likely that
ppc gets a lot of those optimizations, too. The only (obvious) thing which
doesn't make ppc host faster is code copy.

Ciao,
Dscho

RE: [Qemu-devel] SMB for DOS ?

[Andreas Bollhalder]

Hello Fabrice

> In order to have similar features to dosemu in QEMU, implementing
MFS 
> support in QEMU would be useful, but it would require a lot of work.

I use QEmu mainly for running GEOS under FreeDOS on my WinXP system.
There are different drivers for DOS network file access (M$, Novell,
Pathfinder and a lot more). MFS is the definition used under DOS.
Unfortunatly, the Microsoft Client for DOS (SMB access) eats away the
most of directly acessible RAM, so that a lot of apps won't run. The
Novell client (NetWare access) doesn't work for the lack of IPX
support.

It would be very nice to have a direct interface for host file access
trough the emulation of a device. I know, it requires a driver on the
guest side. For DOS, it means a driver which provides the MFS
interface to the OS. The DOS apps which are able to access network
files should have no problems.

A direct interface would allow a faster access to the host files.
Small OS's, like for example Topsy, could faster integrate a driver
for QEmu then a complete network stack and SMB.

Maybe somone would write an RFC for host <-> guest exchange...
Accessing the files, grafic, sound, network and other hardware. Every
OS could then implement default drivers for running inside an
emulation... And in every CPU design, there should be a reserved bit
for defining it to a virtual one... Sorry, I'm dreaming.

I use GEOS since 1991 and have tons of documents I still use. The
emulation in QEmu works very good. Only the sound could be a little
bit better. The main advantage is that the network is running very
fast compared to Bochs. I use the Novell drivers for DOS and GEOS sets
up the TCP/IP stack on it.

Andreas

RE: [Qemu-devel] SMB for DOS ?

[malc]

On Fri, 17 Dec 2004, Andreas Bollhalder wrote:

> Hello Fabrice
>
>> In order to have similar features to dosemu in QEMU, implementing
> MFS
>> support in QEMU would be useful, but it would require a lot of work.
>
> I use QEmu mainly for running GEOS under FreeDOS on my WinXP system.
> There are different drivers for DOS network file access (M$, Novell,
> Pathfinder and a lot more). MFS is the definition used under DOS.
> Unfortunatly, the Microsoft Client for DOS (SMB access) eats away the
> most of directly acessible RAM, so that a lot of apps won't run. The
> Novell client (NetWare access) doesn't work for the lack of IPX
> support.
>
<snip>
>
> I use GEOS since 1991 and have tons of documents I still use. The
> emulation in QEmu works very good. Only the sound could be a little
> bit better. The main advantage is that the network is running very
> fast compared to Bochs. I use the Novell drivers for DOS and GEOS sets
> up the TCP/IP stack on it.

If your host system is indeed WinXP i suggest rebuilding QEMU with FMOD
audio output driver, it should be much better than default SDL audio.

-- 
mailto:malc@pulsesoft.com

Re: [Qemu-devel] SMB for DOS ?

[Herbert Poetzl]

On Fri, Dec 17, 2004 at 12:10:18AM +0100, Fabrice Bellard wrote:
> Adrian Smarzewski wrote:
> >Fabrice Bellard wrote:
> >
> >>In order to have similar features to dosemu in QEMU, implementing MFS 
> >>support in QEMU would be useful, but it would require a lot of work.
> >
> >I think QEMU should rather focus on x86-x86 speed now (to be full 
> >replacement of VMWare) and use as much external code for features as 
> >possible instead of implementing it.
> >QEMU is usable now. There are two disadvantages: speed of emulation 
> >compared to virtualisation (maybe some switch to enable virtualisation 
> >mode instead of emulation? ;)) and lack of USB support for example.
> >But I would vote for optimizations!
> 
> It was just a suggestion for DOS users :-)
> 
> x86 on x86 optimization is now the top item on my TODO list...

good to hear .. maybe I dig out the changes I did
to get a 2-4 times performance improvement for
x86 (qemu-fast) with qemu 0.5.5 ...

mainly improvements in the way the mainloop is
handled (worked fine for userspace, had some
issues with kernels) ...

Fabrice, you are doing a great job!

thanks,
Herbert

> Fabrice.
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] SMB for DOS ?

[Herbert Poetzl]

On Fri, Dec 17, 2004 at 12:41:31AM +0100, Laurent Amon wrote:
> 
> On 17 déc. 04, at 00:10, Fabrice Bellard wrote:
> 
> >Adrian Smarzewski wrote:
> >>I think QEMU should rather focus on x86-x86 speed now (to be full 
> >>replacement of VMWare) and use as much external code for features as 
> >>possible instead of implementing it.
> >x86 on x86 optimization is now the top item on my TODO list...
> >
> I hope you will not forget us poor mac users. Optimizing x86 on ppc 
> performance would make a number of people very happy, I'd say.

performance on ppc can become very good because
there are much more registers available for emulating
the x86 stuff ...

best,
Herbert

> Pretty please?
> 
> Lga.
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] SMB for DOS ?

[Paul Brook]

> > I hope you will not forget us poor mac users. Optimizing x86 on ppc
> > performance would make a number of people very happy, I'd say.
>
> performance on ppc can become very good because
> there are much more registers available for emulating
> the x86 stuff ...

The really slow bit tends to be MMU emulation, and more host registers doesn't 
help here. Mapping all guest registers directly onto host registers probably 
doesn't make all that much difference as the values will tend to be in L1 
cache anyway.

Paul

Re: [Qemu-devel] SMB for DOS ?

[John R. Hogerhuis]

On Sat, 2004-12-18 at 10:32, Paul Brook wrote:
> > > I hope you will not forget us poor mac users. Optimizing x86 on ppc
> > > performance would make a number of people very happy, I'd say.
> >
> > performance on ppc can become very good because
> > there are much more registers available for emulating
> > the x86 stuff ...
> 
> The really slow bit tends to be MMU emulation, and more host registers doesn't 
> help here. Mapping all guest registers directly onto host registers probably 
> doesn't make all that much difference as the values will tend to be in L1 
> cache anyway.
> 
> Paul
> 

This raises an interesting question in my mind, given the existence of
"reconfigurable computing" where you have a PCI card containing an FPGA
loaded onto your machine (such things do exist, and I expect in the
future to start seeing these things standard on motherboards). Certainly
an MMU can be created in FPGA code. There is an interesting article on
reconfigurable computing in this month's Linux Journal, btw.

What kinds of generic hardware based support would really speed up
emulation of other CPUs? Of course, one could also ask the question of
what would be an ideal CPU instruction set for emulating other CPUs. But
if one narrowed the focus to things that could be accomplished by an
FPGA hooked to the bus, it could actually be implemented by anyone with
the interest to do it, whereas making a new CPU is an expensive
undertaking.

Might be an interesting project for a graduate student.

-- John.

Re: [Qemu-devel] SMB for DOS ?

[André Braga]

On Sat, 18 Dec 2004 12:48:16 -0800, John R. Hogerhuis <jhoger@pobox.com> wrote:
> This raises an interesting question in my mind, given the existence of
> "reconfigurable computing" where you have a PCI card containing an FPGA
> loaded onto your machine (such things do exist, and I expect in the
> future to start seeing these things standard on motherboards). Certainly
> an MMU can be created in FPGA code. There is an interesting article on
> reconfigurable computing in this month's Linux Journal, btw.

The PCI bus is still too slow to handle such tasks efficiently. Maybe
if the FPGA could be tied to the north bridge it would be actually
useful, or maybe the PCI Express bus is up to the task; anyway, the
current implementations wouldn't be that helpful at all.

The FPGA accelerators use to have many small "computing elements" and
some decent amount of local RAM. Going back and forth in the PCI bus
would kill most performance gains one would expect.


--
"The user-friendly computer is a red herring. The user-friendliness of
a book just makes it easier to turn pages. There's nothing
user-friendly about learning to read."
-- Alan Kay

Re: [Qemu-devel] SMB for DOS ?

[Herbert Poetzl]

On Sat, Dec 18, 2004 at 06:32:24PM +0000, Paul Brook wrote:
> > > I hope you will not forget us poor mac users. Optimizing x86 on ppc
> > > performance would make a number of people very happy, I'd say.
> >
> > performance on ppc can become very good because
> > there are much more registers available for emulating
> > the x86 stuff ...
> 
> The really slow bit tends to be MMU emulation, and more 
> host registers doesn't help here. Mapping all guest registers 
> directly onto host registers probably doesn't make all that 
> much difference as the values will tend to be in L1 
> cache anyway.

well, thought I do some benchmarks with bintrans[1] vs
qemu (i386 userspace on PPC) to see what should be possible ...

the test cadidates[2] are cli only and do cpu-bound stuff
(fibonacci numbers, the game go, and the magic square) 


            version           [A]         [B]         [C]
---------------------------------------------------------------
qemu        0.5.5           33.20      583.30     1237.48
qemu        0.6.1           18.33      476.78      872.69
bintrans    0.1             10.33      176.71      348.64
---------------------------------------------------------------
speedup                     77.4%      169.8%      150.3%


[A] i386-root/bin/fib
    time i386-user/qemu-i386 i386-root/bin/fib
    time bintrans-0.1/bintrans i386-root/bin/fib

    39088169
    Command exited with non-zero status 9

[B] i386-root/bin/go
    time i386-user/qemu-i386 i386-root/bin/go 50 21 5stone21.in
    time bintrans-0.1/bintrans i386-root/bin/go 50 21 5stone21.in

    ...
    370 W pass
    371 B pass
    Game over
    exit (0)

[C] i386-root/bin/imc
    time i386-user/qemu-i386 i386-root/bin/imc 10000 >/dev/null
    time bintrans-0.1/bintrans i386-root/bin/imc 10000 >/dev/null
    

best,
Herbert

[1] http://www.complang.tuwien.ac.at/schani/bintrans/
[2] http://www.complang.tuwien.ac.at/schani/bintrans/i386-root.tar.gz


> Paul