[Qemu-devel] DMA in Windows 2000/XP/2003

[Qemu-devel] DMA in Windows 2000/XP/2003

[Víctor Córcoles López]

Hello developers. My English is not good.

I see that DMA in Hard Disks in guest OS Windows 2000/XP/2003 is not 
avalaible, it run in PIO mode.

How can activate UDMA mode for hard disk ?

Thanks for developers.

_________________________________________________________________
¿Estás pensando en cambiar de coche? Todas los modelos de serie y extras en 
MSN Motor. http://motor.msn.es/researchcentre/

Re: [Qemu-devel] DMA in Windows 2000/XP/2003

[Kazu]

Hi,

> Tuesday, August 23, 2005 10:28 PM Víctor Córcoles López wrote:
>Subject: [Qemu-devel] DMA in Windows 2000/XP/2003
>
>Hello developers. My English is not good.
>
>I see that DMA in Hard Disks in guest OS Windows 2000/XP/2003 is not
>avalaible, it run in PIO mode.
>
>How can activate UDMA mode for hard disk ?

This patch might help..

http://ebisa.hp.infoseek.co.jp/qemu/arcs/qemu-piix4-udma-20050514.zip

This patch is made by Juergen Lock and Juergen Keil and improved by
lukewarm. Hard disk is DMA mode but CD-ROM is PIO mode. Windows98/2000 and
OS/2 work with this patch. FreeSBIE also works because CD-ROM is PIO mode.

http://lists.gnu.org/archive/html/qemu-devel/2004-11/msg00468.html

Regards,
Kazu

Re: [Qemu-devel] DMA in Windows 2000/XP/2003

[Brad Campbell]

Kazu wrote:
> 
> This patch might help..
> 
> http://ebisa.hp.infoseek.co.jp/qemu/arcs/qemu-piix4-udma-20050514.zip

Interesting.. after applying that patch both my win2k and winxp installs refused to boot.
Winxp gets as far as the safe mode selection screen, select safe mode and it goes straight back to 
the selection screen. Win2k just bluescreens during the boot process mumbling something about being 
unable to access the boot disk.

However, a fresh clean winxp install appears to be working and is reporting DMA enabled.
(Also appears to be a little lighter on the host cpu, but have not really got any way of benchmarking).

Go figure ?!?

I'm wondering if this patch is ever likely to make it into mainline?

Brad
-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams

Re: [Qemu-devel] DMA in Windows 2000/XP/2003

[Christian MICHON]

I think you need to sysprep or you'll get a 7b error.
After all, enabling this dma patch is equivalent to change
your hdd controller, somehow, and it's vital hw to xp/2k.

-- 
Christian


On 8/29/05, Brad Campbell <brad@wasp.net.au> wrote:
> Kazu wrote:
> >
> > This patch might help..
> >
> > http://ebisa.hp.infoseek.co.jp/qemu/arcs/qemu-piix4-udma-20050514.zip
> 
> Interesting.. after applying that patch both my win2k and winxp installs refused to boot.
> Winxp gets as far as the safe mode selection screen, select safe mode and it goes straight back to
> the selection screen. Win2k just bluescreens during the boot process mumbling something about being
> unable to access the boot disk.
> 
> However, a fresh clean winxp install appears to be working and is reporting DMA enabled.
> (Also appears to be a little lighter on the host cpu, but have not really got any way of benchmarking).
> 
> Go figure ?!?
> 
> I'm wondering if this patch is ever likely to make it into mainline?
> 
> Brad
> --
> "Human beings, who are almost unique in having the ability
> to learn from the experience of others, are also remarkable
> for their apparent disinclination to do so." -- Douglas Adams
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>

Re: [Qemu-devel] DMA in Windows 2000/XP/2003

[Jan Marten Simons]

Víctor Córcoles López wrote:

> Hello developers. My English is not good.
>
> I see that DMA in Hard Disks in guest OS Windows 2000/XP/2003 is not 
> avalaible, it run in PIO mode.
>
> How can activate UDMA mode for hard disk ?
>
I don't think you'd get any advantage of activating DMA inside the qemu 
guest-OS, as qemu has to proxy all rw-access into a file anyway, unless 
you pass an actual device/partition to qemu. Besides qemu is emulating 
the complete pci bus, which cannot use features of actual hardware in 
the machine (e.g. your hdd or features your chipset provide). I guess it 
would be possible to emulate uDMA inside the vm, too, but it's likely to 
even slowdown the emulation.

So long,
Jan

Re: [Qemu-devel] DMA in Windows 2000/XP/2003

[André Braga]

Fortunately, it does make a difference.

PIO is polling-base, whereas DMA is, lacking a better term (excuse my
English), transaction-based. Since no CPU arbitration is needed, quite
a few optimizations can be done because of this, like real, large
block transfers. And if you happen to search the list archives, people
have already reported significant gains when using these patches, so
even if I'm talking bullocks empirical results do exist :)


Cheers,
A.


-- 
"I invented the term Object-Oriented, and I can tell you I did not
have C++ in mind"
-Alan Kay


2005/8/24, Jan Marten Simons <marten@xtal.rwth-aachen.de>:
> Víctor Córcoles López wrote:
> 
> > Hello developers. My English is not good.
> >
> > I see that DMA in Hard Disks in guest OS Windows 2000/XP/2003 is not
> > avalaible, it run in PIO mode.
> >
> > How can activate UDMA mode for hard disk ?
> >
> I don't think you'd get any advantage of activating DMA inside the qemu
> guest-OS, as qemu has to proxy all rw-access into a file anyway, unless
> you pass an actual device/partition to qemu. Besides qemu is emulating
> the complete pci bus, which cannot use features of actual hardware in
> the machine (e.g. your hdd or features your chipset provide). I guess it
> would be possible to emulate uDMA inside the vm, too, but it's likely to
> even slowdown the emulation.
> 
> So long,
> Jan

[Qemu-devel] Read/Write to shares on Windows (XP Pro) host from Windows (2000 Adv) guest.

[Francois Rioux]

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

Hi,
 
What I'm trying to achieve is to write a file from a guest OS to a host.  In this case both are Windows OS.
 
I use the user network command line options since I looking for a no install on host, portable solution.
 
I've tried various build in solutions: -tftp (read-only), and -smb (not supported in windows host) do me no good.
 
What I manage to do with a certain success is to map network shares of the host in the guest (net use z: 10.0.2.2\MyShare in the guest).  I can browse and read files from the mapped drive.  However I can't write to it from the guest. I received an Access Denied message instead even if the share is set so Everyone has Full Control.

I don't understand why this doesn't work. Is it Windows preventing the write is the exchange this a limitation in QEMU or in SLiRP?  As I understand it SLiRP translates some tcp headers and acts as a firewall preventing incoming calls but autorizes outgoing calls from the guest out.  That's why web browsing works in user network mode.  Should't file transfer work too?  Is the network file sharing protocol more complex than that for writes? Or is that rather a Windows security issue?
 
Any explanation or workaround would be appreciated.
 
Thanks.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

Re: [Qemu-devel] Read/Write to shares on Windows (XP Pro) host from Windows (2000 Adv) guest.

[Jim C. Brown]

On Wed, Aug 24, 2005 at 07:23:11PM -0700, Francois Rioux wrote:
> Hi,
>  
> What I manage to do with a certain success is to map network shares of the host in the guest (net use z: 10.0.2.2\MyShare in the guest).  I can browse and read files from the mapped drive.  However I can't write to it from the guest. I received an Access Denied message instead even if the share is set so Everyone has Full Control.
> 

Well, you could try mounting the share using the IP on the ethernet card (e.g. the lan IP) of the host.

> I don't understand why this doesn't work. Is it Windows preventing the write is the exchange this a limitation in QEMU or in SLiRP?  As I understand it SLiRP translates some tcp headers and acts as a firewall preventing incoming calls but autorizes outgoing calls from the guest out.  That's why web browsing works in user network mode.  Should't file transfer work too?  Is the network file sharing protocol more complex than that for writes? Or is that rather a Windows security issue?
>  

Not sure. I do know that sometimes using 10.0.2.2 doesn't work but using the lan IP does. This is due to what may be a bug in the slirp code where the localhost ip (127.0.0.1) is not properly rewritten (into 10.0.2.2), but I'm not sure whether or not this is the cause of the issue that you are experiencing.

> Any explanation or workaround would be appreciated.
>  
> Thanks.
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.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] Read/Write to shares on Windows (XP Pro) host from Windows (2000 Adv) guest.

[John R. Hogerhuis]

On Wed, 2005-08-24 at 19:23 -0700, Francois Rioux wrote:

> I don't understand why this doesn't work. Is it Windows preventing the
> write is the exchange this a limitation in QEMU or in SLiRP?  As I
> understand it SLiRP translates some tcp headers and acts as a firewall
> preventing incoming calls but autorizes outgoing calls from the guest
> out.  That's why web browsing works in user network mode.  Should't
> file transfer work too?  Is the network file sharing protocol more
> complex than that for writes? Or is that rather a Windows security
> issue?
>  

Could be an authentication issue. Probably you should be typing in the
fully qualified username and password into the net use command

net use z: \\10.0.2.2\MyShare /USER:domain\username password

or just

ctrl-esc->Run->  \\10.0.2.2\MyShare<ENTER> and type the fully qualified
username and password at the prompt.

After making the share connection, what do you get as output when you
just type

net use<ENTER>

Knowing a bit about the NetBT protocol and the stunning quality of the
Slirp NAT code I'm kind of surprised that it works at all. 

CIFS requires some assistance from an application level gateway (ALG) to
work well across a NAT. In the direction you're going (guest to host)
there are less problems, but I think there are still NAT issues with
browsing and name binding; but then you're using IP addresses rather
than names so it may not matter.

If none of the above works, I'd look at it with a snooper on either side
of the connection (in the guest and on the host), and see what packets
are getting dropped (shows up on one side of snooper but not the other)
or improperly NATed (private IP addresses leak out either in headers or
in packet payload onto the host network).

You might also try port forwarding the NetBT (NetBIOS over TCP/IP, aka
CIFS) TCP and UDP ports. See RFCs 1001, 1002 for port numbers.

-- John.

Re: [Qemu-devel] Read/Write to shares on Windows (XP Pro) host fromWindows (2000 Adv) guest.

[Kazu]

Thursday, August 25, 2005 11:23 AM Francois Rioux wrote:


>What I'm trying to achieve is to write a file from a guest OS to a host.
>In this case both are Windows OS.
>
>I use the user network command line options since I looking for a no
>install on host, portable solution.
>
>I've tried various build in solutions: -tftp (read-only), and -smb (not
>supported in windows host) do me no good.
>
>What I manage to do with a certain success is to map network shares of the
>host in the guest (net use z: >10.0.2.2>\MyShare in the guest).  I can
>browse and read files from the mapped drive.  However I can't write to it
>from the guest. I received an Access Denied message instead even if the
>share is set so Everyone has Full Control.

I think there is a checkbox that "Allow to change files to network user" in
MyShrare folder's property on Windows XP host.
Sorry I don't have English version of Windows, so "explanation" is not
correct. I checked it, then I can write a file from guest to host.

There isn't such checkbox on Windows 2000 host.

Regards,
Kazu

Re: [Qemu-devel] Read/Write to shares on Windows (XP Pro) host fromWindows (2000 Adv) guest.

[Francois Rioux]

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

Thank yoy Kazu,
 
You sent me in the right direction.  It was just a configuration issue : I had given the directory full access to everyone but that wasn't enough.  I needed to give the network SHARE itself the write rights to everyone.  That is through the Permission button on the Sharing tab also.
 
I'm so glad it worked!
 
Thanks the other contributors too.  Your input helped me understand networking a bit more.
 
I didn't think LMHosts configuration could play a role in that. It is just part of the name to ip resolution process.  I might eventually use it as a convenience.
 
NAT and SLIRP seem to be robust enough to handle that.  At least during my preliminary testing.
 
Long life to QEMU!

Kazu <kazoo@r3.dion.ne.jp> wrote:
I think there is a checkbox that "Allow to change files to network user" in
MyShrare folder's property on Windows XP host.
Sorry I don't have English version of Windows, so "explanation" is not
correct. I checked it, then I can write a file from guest to host.

There isn't such checkbox on Windows 2000 host.

Regards,
Kazu



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

Re: [Qemu-devel] Read/Write to shares on Windows (XP Pro) host fromWindows (2000 Adv) guest.

[Francois Rioux]

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

Thank yoy Kazu,
 
You sent me in the right direction.  It was just a configuration issue : I had given the directory full access to everyone but that wasn't enough.  I needed to give the network SHARE itself the write rights to everyone.  That is through the Permission button on the Sharing tab also.
 
I'm so glad it worked!
 
Thanks the other contributors too.  Your input helped me understand networking a bit more.
 
I didn't think LMHosts configuration could play a role in that. It is just part of the name to ip resolution process.  I might eventually use it as a convenience.
 
NAT and SLIRP seem to be robust enough to handle that.  At least during my preliminary testing.
 
Long life to QEMU!

Kazu <kazoo@r3.dion.ne.jp> wrote:
I think there is a checkbox that "Allow to change files to network user" in
MyShrare folder's property on Windows XP host.
Sorry I don't have English version of Windows, so "explanation" is not
correct. I checked it, then I can write a file from guest to host.

There isn't such checkbox on Windows 2000 host.

Regards,
Kazu



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

Re: [Qemu-devel] Read/Write to shares on Windows (XP Pro) host from Windows (2000 Adv) guest.

[Doctor Bill]

On 8/24/05, Francois Rioux <francoisrioux@yahoo.com> wrote:
> What I manage to do with a certain success is to map network shares of the
> host in the guest (net use z: 10.0.2.2\MyShare in the guest).  I can browse
> and read files from the mapped drive.  However I can't write to it from the
> guest. I received an Access Denied message instead even if the share is set
> so Everyone has Full Control.
>  
> I don't understand why this doesn't work. Is it Windows preventing the write
> is the exchange this a limitation in QEMU or in SLiRP?  As I understand it
> SLiRP translates some tcp headers and acts as a firewall preventing incoming
> calls but autorizes outgoing calls from the guest out.  That's why web
> browsing works in user network mode.  Should't file transfer work too?  Is
> the network file sharing protocol more complex than that for writes? Or is
> that rather a Windows security issue? 
>   
> Any explanation or workaround would be appreciated. 

I posted something about this in the forum.  In my case, I was trying
to print to the Windows host.  Unfortunately, it looks like the post
is no longer there.  The solution was simply to add the real IP
address and machine name into the lmhost file.  Once you do that, you
should be able to access samba read-write.  Be aware, Windows has a
lmhost.sam file by defauft, and hides the .sam extension.  Editing
that file will have no effect unless it is renamed to just lmhost with
no extension.

For example, my C:\Windows\lmhost file contains the following:

135.162.253.250 docbill002

When I want to connect via SAMBA I use the hostname not the IP address.

Once you do that, write access is determined completely by Windows security.  

By default, only the "SharedFolders" and shared printers are writable
by guests...

Generally, when I want to add guest write access to a folder, I use a
cygwin command.  For example, I have drive Q: shared as Data.  If I
want guest to have write access, in addition to setting the shared
folder properties I would do:

chmod -R ugo+w /cygdrive/q

I can than modify \\docbill002\Data as guest as much as I want.

Maybe someone on the list can specify the non-cygwin equivalent of this command.


Bill