[Qemu-devel] Access to the host filesystem

[Qemu-devel] Access to the host filesystem

[Fabrice Bellard]

Hi,

I wonder what would be the best way to access to the host filesystem, 
especially with the Linux, MSDOS/FreeDos and Windows guest OSes.

Here are my thoughts:

1) Do nothing and just use the network with NFS or Samba host servers. 
It is the easiest solution but it requires a complicated host and guest 
configuration.

2) Add a hardware device in QEMU giving access to the host filesystem 
with specific commands such as "open", "read" and "close" working by 
using DMA in physical guest memory. Then by reusing the user mode Linux 
"hostfs" filesystem, it would be easy to add access to the host 
filesystem. By reusing the dosemu "MFS" driver, it would also be 
possible to do the same as dosemu to access to an host DOS tree.

3) Add a tiny NFS server in QEMU so that no host configuration is 
needed. Then only NFS drivers are needed in the guest OS.

Any comments ?

Fabrice.

[Qemu-devel] Re: Access to the host filesystem

[Matt Howard]

Fabrice Bellard wrote:

> Hi,
> 
> I wonder what would be the best way to access to the host filesystem,
> especially with the Linux, MSDOS/FreeDos and Windows guest OSes.
> 
> Here are my thoughts:
> 
> 1) Do nothing and just use the network with NFS or Samba host servers.
> It is the easiest solution but it requires a complicated host and guest
> configuration.
> 
> 2) Add a hardware device in QEMU giving access to the host filesystem
> with specific commands such as "open", "read" and "close" working by
> using DMA in physical guest memory. Then by reusing the user mode Linux
> "hostfs" filesystem, it would be easy to add access to the host
> filesystem. By reusing the dosemu "MFS" driver, it would also be
> possible to do the same as dosemu to access to an host DOS tree.
> 
> 3) Add a tiny NFS server in QEMU so that no host configuration is
> needed. Then only NFS drivers are needed in the guest OS.
> 
> Any comments ?
> 
> Fabrice.

I'd stick with Option 1.  2 and 3 are most heinously hackish, and won't
provide the user/operator with as many options.  2 only covers Linux and
DOS out of the box, and we all know how easy it is to get OSS developers to
work on windows drivers. ;)  3 sounds workable, except that the MS OSes
only support NFS through add-ons.  95% of qemu users will want network
connections to the guest anyway, so I'd say it's safe to assume that
they'll have it set up.  Maybe someone could write up a document for
post-networking setup that describes how to set up NFS/Samba in a
locked-down, local-only configuration.  This way, the job for you is
basically done. :)

-- 
Matt Howard <mhoward@sigins.com>
Superior Insurance - Technical Services

Re: [Qemu-devel] Access to the host filesystem

[Martin Garton]

On Fri, 20 Feb 2004, Fabrice Bellard wrote:

> 1) Do nothing and just use the network with NFS or Samba host servers. 
> It is the easiest solution but it requires a complicated host and guest 
> configuration.

This is my preferred optino. It's not really that complicated to set up.  
eg, for a windows host on a linux guest for a typical distro its a few
lines in smb.conf (or possibly even a few clicks on some config front end
these days)

Even if it was slightly more complicated you could always have a separate
config tool to help with the setup (like vmware does for its networking
setup I believe)

Regards,
Martin.

[Qemu-devel] Fabrice, could you look at this

[Daniel J. Guinan]

These are logs from a run of QEMU on OS X, using the linux kernel found 
on your website (the 2.4x kernel).   The code in question is an edited 
version of what is currently in CVS and it does NOT use the new 
bootloader code that you checked in (because that requires a 
cross-compiler, which I haven't yet built).

I am new to QEMU and am slowly training myself up on what is going on 
while fixing bugs.  But I could really use your expert eyes for a 
moment.  Could you scan this output log and give me your opinion on 
whether things appear to be doing the right thing and what might be 
wrong?

Thank you so much.

-Daniel Guinan

[Qemu-devel] Re: Access to the host filesystem

[John Davidorff Pell]

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

I vote for option 3, as it is the simplest and would work almost 
universally. the M$ OSes would need the add-on, but that's the price 
you pay for running windoze. Option 1 will only work if networking is 
running properly in the guest *and* in the host, so it is concievable 
that it won't work at all at times, and option 3 also has some 
guest-networking-related issues. option 2 requires guest os drivers, 
which might be hard to get.

Perhaps a combination of option 2 and 3. A special custom network card 
that does only NFS (i'm thinking not even TCP/IP, but that might be 
more work than its worth, and require drivers again...). Maybe just an 
extra IDE controler (no extra drivers) and the host drives (or 
host-based "shares") show up as drives/partitions?

JP

Fabrice Wrote:
> Hi,
>
> I wonder what would be the best way to access to the host filesystem,
> especially with the Linux, MSDOS/FreeDos and Windows guest OSes.
>
> Here are my thoughts:
>
> 1) Do nothing and just use the network with NFS or Samba host servers.
> It is the easiest solution but it requires a complicated host and guest
> configuration.
>
> 2) Add a hardware device in QEMU giving access to the host filesystem
> with specific commands such as "open", "read" and "close" working by
> using DMA in physical guest memory. Then by reusing the user mode Linux
> "hostfs" filesystem, it would be easy to add access to the host
> filesystem. By reusing the dosemu "MFS" driver, it would also be
> possible to do the same as dosemu to access to an host DOS tree.
>
> 3) Add a tiny NFS server in QEMU so that no host configuration is
> needed. Then only NFS drivers are needed in the guest OS.
>
> Any comments ?
>
> Fabrice.

--
if (message.signature==FUNNY) steal(message.signature); else 
message=message->next;

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2426 bytes --]

Re: [Qemu-devel] Re: Access to the host filesystem

[Grzegorz Kulewski]

I vote for option 1.

Why:
- configuration of Samba or NFS or CIFS is not so complicated, I think
- Windows guests will not need any configuration probably
- You cannot implement all protocols
- implementing that will be time consuming and will not allow developers 
focus on more important things
- this is code duplication with kernel/samba/NFS
- security problems and need for updates and maintaining the code

I know that in VMWare there is such utility and is not working for me 
correctly (it hangs/hangs the windows/stops responding/etc.). So I have 
bad experiencess...

I you configure the host in standard way, you can fully customize your 
settings and achieve stability, reliability and security of the newest 
versions of the original implementations.

That is what I think...


Grzegorz Kulewski


On Fri, 20 Feb 2004, John Davidorff Pell wrote:

> I vote for option 3, as it is the simplest and would work almost 
> universally. the M$ OSes would need the add-on, but that's the price 
> you pay for running windoze. Option 1 will only work if networking is 
> running properly in the guest *and* in the host, so it is concievable 
> that it won't work at all at times, and option 3 also has some 
> guest-networking-related issues. option 2 requires guest os drivers, 
> which might be hard to get.
> 
> Perhaps a combination of option 2 and 3. A special custom network card 
> that does only NFS (i'm thinking not even TCP/IP, but that might be 
> more work than its worth, and require drivers again...). Maybe just an 
> extra IDE controler (no extra drivers) and the host drives (or 
> host-based "shares") show up as drives/partitions?
> 
> JP
> 
> Fabrice Wrote:
> > Hi,
> >
> > I wonder what would be the best way to access to the host filesystem,
> > especially with the Linux, MSDOS/FreeDos and Windows guest OSes.
> >
> > Here are my thoughts:
> >
> > 1) Do nothing and just use the network with NFS or Samba host servers.
> > It is the easiest solution but it requires a complicated host and guest
> > configuration.
> >
> > 2) Add a hardware device in QEMU giving access to the host filesystem
> > with specific commands such as "open", "read" and "close" working by
> > using DMA in physical guest memory. Then by reusing the user mode Linux
> > "hostfs" filesystem, it would be easy to add access to the host
> > filesystem. By reusing the dosemu "MFS" driver, it would also be
> > possible to do the same as dosemu to access to an host DOS tree.
> >
> > 3) Add a tiny NFS server in QEMU so that no host configuration is
> > needed. Then only NFS drivers are needed in the guest OS.
> >
> > Any comments ?
> >
> > Fabrice.
> 
> --
> if (message.signature==FUNNY) steal(message.signature); else 
> message=message->next;

Re: [Qemu-devel] Fabrice, could you look at this

[Daniel J. Guinan]

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

OS X port
--------------

 From translate.c (line 3163) :
     /* TO BE FIXED: T0 hasn't got a proper value, which makes 
tb_add_jump
      *              do bad business and then qemu crashes !
      */

We are indeed crashing in tb_add_jump due to a value of 'n' (drawn from 
T0) that is too high...

Fabrice?  Do you remember what the reason for the TO BE FIXED was?

-Daniel

P.S. Yes, the logs did not make it through yet (80k attachement)


On Feb 20, 2004, at 1:17 PM, Pierre d'Herbemont wrote:

>
> On 20 févr. 04, at 21:54, Daniel J. Guinan wrote:
>
>> These are logs from a run of QEMU on OS X, using the linux kernel 
>> found on your website (the 2.4x kernel).   The code in question is an 
>> edited version of what is currently in CVS and it does NOT use the 
>> new bootloader code that you checked in (because that requires a 
>> cross-compiler, which I haven't yet built).
>>
>
> I think you did forgot to attach them ;)
>
> Pierre
>

[-- Attachment #2: Type: text/enriched, Size: 1083 bytes --]

OS X port

--------------


From translate.c (line 3163) :

<fixed>    <color><param>2323,6E6E,2525</param>/* TO BE FIXED: T0
hasn't got a proper value, which makes tb_add_jump

     *              do bad business and then qemu crashes !

     */</color>

</fixed>

We are indeed crashing in tb_add_jump due to a value of 'n' (drawn
from T0) that is too high...  


Fabrice?  Do you remember what the reason for the TO BE FIXED was?


-Daniel


P.S. Yes, the logs did not make it through yet (80k attachement)



On Feb 20, 2004, at 1:17 PM, Pierre d'Herbemont wrote:


<excerpt>

On 20 févr. 04, at 21:54, Daniel J. Guinan wrote:


<excerpt>These are logs from a run of QEMU on OS X, using the linux
kernel found on your website (the 2.4x kernel).   The code in question
is an edited version of what is currently in CVS and it does NOT use
the new bootloader code that you checked in (because that requires a
cross-compiler, which I haven't yet built).


</excerpt>

I think you did forgot to attach them ;)


Pierre


</excerpt>

[Qemu-devel] ADMINISTRIVIA: List limit now 100k

[Rusty Russell]

In message <0359D4AA-63E7-11D8-8E20-000A95A0844E@yahoo.com> you write:
> These are logs from a run of QEMU on OS X, using the linux kernel found 
> on your website (the 2.4x kernel). 

The followup to this post exceeded 40k, so had to wait for admin
(ie. my) approval.

I've upped the limit to 100k for future.  Let's hope that's enough...

Thanks,
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: [Qemu-devel] Fabrice, could you look at this

[J. Mayer]

On Sat, 2004-02-21 at 01:34, Daniel J. Guinan wrote:
> OS X port
> --------------
> 
> From translate.c (line 3163) :
>     /* TO BE FIXED: T0hasn't got a proper value, which makes
> tb_add_jump
>      *              do bad business and then qemu crashes !
>      */
> 
> We are indeed crashing in tb_add_jump due to a value of 'n' (drawnfrom
> T0) that is too high...  
>
> Fabrice?  Do you remember what the reason for the TO BE FIXED was?

I do know: this is only for PPC target.
We never use tb_add_jump for PPC target.
This gives poor performances and needs to be fixed. But it makes things
simpler to debug.
It's not a major issue for now, as it only affects performances, and it
only concerns PPC target, remember....

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

[Qemu-devel] Newb/OS X/Darwin: Help debugging please...

[dguinan]

I am finding debugging quite an interesting experience.  I am trying to 
track down the problems with the OS X (darwin) port and I have isolated 
the problem to a translation that I could use some log interpretation 
on.  It would be very useful for anyone with some experience to give me 
some pointers on what code I should be isolating during debug sessions 
and a general "debug recipe"..  At any rate, here are the blocks:

FIRST:  On x86 TARGET x86
----------------------------------------
IN:
0x000f090e:  movw   0x6(bp),%bx
0x000f0911:  incw   %bx
0x000f0912:  movw   %bx,0x6(bp)
0x000f0915:  pushw  0x6(bp)
0x000f0918:  movw   $0xf000,%ax
0x000f091b:  pushw  %ax
0x000f091c:  call   0xf059a

--- and a ways down ---

Trace 0x086c4150 [0x000f090e]
EAX=0000f000 EBX=0000da9c ECX=00000000 EDX=00000600
ESI=00000000 EDI=00000500 EBP=0000fff0 ESP=0000ffd8
EIP=0000059a EFL=00000086 [--S--P-]    CPL=0 II=0
ES =0000 00000000 0000ffff 00000000
CS =f000 000f0000 0000ffff 00000000
SS =0000 00000000 0000ffff 00000000
DS =0000 00000000 0000ffff 00000000
FS =0000 00000000 0000ffff 00000000
GS =0000 00000000 0000ffff 00000000
LDT=0000 00000000 0000ffff 00008000
TR =0000 00000000 0000ffff 00008000
GDT=     00000000 0000ffff
IDT=     00000000 0000ffff
CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
CCS=00000000 CCD=0000da9c CCO=INCW
Trace 0x086c3af0 [0x000f059a]
EAX=0000f073 EBX=0000da9c ECX=00000000 EDX=00000600
ESI=00000000 EDI=00000500 EBP=0000fff0 ESP=0000ffda
EIP=0000091f EFL=00000086 [--S--P-]    CPL=0 II=0
ES =0000 00000000 0000ffff 00000000
CS =f000 000f0000 0000ffff 00000000
SS =0000 00000000 0000ffff 00000000
DS =0000 00000000 0000ffff 00000000
FS =0000 00000000 0000ffff 00000000
GS =0000 00000000 0000ffff 00000000
LDT=0000 00000000 0000ffff 00008000
TR =0000 00000000 0000ffff 00008000
GDT=     00000000 0000ffff
IDT=     00000000 0000ffff
CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
CCS=00000000 CCD=0000da9c CCO=INCW
Trace 0x086c3ee0 [0x000f091f]
EAX=0000f073 EBX=0000da9c ECX=00000000 EDX=00000600
ESI=00000000 EDI=00000500 EBP=0000fff0 ESP=0000ffde
EIP=000007af EFL=00000016 [----AP-]    CPL=0 II=0
ES =0000 00000000 0000ffff 00000000
CS =f000 000f0000 0000ffff 00000000
SS =0000 00000000 0000ffff 00000000
DS =0000 00000000 0000ffff 00000000
FS =0000 00000000 0000ffff 00000000
GS =0000 00000000 0000ffff 00000000
LDT=0000 00000000 0000ffff 00008000
TR =0000 00000000 0000ffff 00008000
GDT=     00000000 0000ffff
IDT=     00000000 0000ffff
CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
CCS=00000025 CCD=0000f04e CCO=SUBB
----------------
IN:
0x000f07af:  movw   0xfffffffc(bp),%ax
0x000f07b2:  testw  %ax,%ax
0x000f07b4:  je     0x8ff


And the same on PPC (OS X) Target x86
-------------------------------------------------------

IN:
0x000f090e:  movw   0x6(bp),%bx
0x000f0911:  incw   %bx
0x000f0912:  movw   %bx,0x6(bp)
0x000f0915:  pushw  0x6(bp)
0x000f0918:  movw   $0xf000,%ax
0x000f091b:  pushw  %ax
0x000f091c:  call   0xf059a

--- and a ways down... ---

Trace 0x0020acc0 [0x000f090e]
EAX=0000f000 EBX=0000da9c ECX=00000000 EDX=00000600
ESI=00000000 EDI=00000500 EBP=0000fff0 ESP=0000ffd8
EIP=0000059a EFL=00000086 [--S--P-]    CPL=0 II=0
ES =0000 00000000 0000ffff 00000000
CS =f000 000f0000 0000ffff 00000000
SS =0000 00000000 0000ffff 00000000
DS =0000 00000000 0000ffff 00000000
FS =0000 00000000 0000ffff 00000000
GS =0000 00000000 0000ffff 00000000
LDT=0000 00000000 0000ffff 00008000
TR =0000 00000000 0000ffff 00008000
GDT=     00000000 0000ffff
IDT=     00000000 0000ffff
CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
CCS=00000084 CCD=0000da9c CCO=EFLAGS
Trace 0x0020a3e0 [0x000f059a]
EAX=00000000 EBX=0000da9c ECX=00000000 EDX=00000600
ESI=00000000 EDI=00000500 EBP=0000fff0 ESP=0000ffda
EIP=0000091f EFL=00000086 [--S--P-]    CPL=0 II=0
ES =0000 00000000 0000ffff 00000000
CS =f000 000f0000 0000ffff 00000000
SS =0000 00000000 00000000 00000000
DS =0000 00000000 0000ffff 00000000
FS =0000 00000000 0000ffff 00000000
GS =0000 00000000 0000ffff 00000000
LDT=0000 00000000 0000ffff 00008000
TR =0000 00000000 0000ffff 00008000
GDT=     00000000 0000ffff
IDT=     00000000 0000ffff
CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
CCS=00000084 CCD=0000da9c CCO=EFLAGS
Trace 0x0020a980 [0x000f091f]
EAX=00000000 EBX=0000da9c ECX=00000000 EDX=00000600
ESI=00000000 EDI=00000500 EBP=0000fff0 ESP=0000ffe0
EIP=000000c4 EFL=00000002 [-------]    CPL=0 II=0
ES =0000 00000000 0000ffff 00000000
CS =f000 000f0000 0000ffff 00000000
SS =0000 00000000 00000000 00000000
DS =0000 00000000 0000ffff 00000000
FS =0000 00000000 0000ffff 00000000
GS =0000 00000000 0000ffff 00000000
LDT=0000 00000000 0000ffff 00008000
TR =0000 00000000 0000ffff 00008000
GDT=     00000000 0000ffff
IDT=     00000000 0000ffff
CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
CCS=00000084 CCD=00000000 CCO=[196]
-------------------------------
IN:
The assembly to be translated.
0x000f00c4:  adcb   %ah,0xffffff85(bp)
0x000f00c7:  rolb   $0x89,%bl
0x000f00ca:  stc
0x000f00cb:  jcxz   0xf00e6


--- As you can see, the code does something different under identical 
starting conditions for OS X/ppc  vs Linux/x86 hosts.   Where should I 
be looking for the apparent problems with the values in the registers 
and the choice in branches?  My guess here is that the OS X translation 
is making a mistake, resulting in the execution of code that it 
shouldn't be trying to execute (the 00c4 entry in EIP at the end of the 
call vs the x86 host's 07af).  But there are other discrepencies.

Anyone want to give me debugging tips?