Re: [Qemu-devel] 0.8.2 and win64
On 7/26/06, ZIGLIO, Frediano, VF-IT <[EMAIL PROTECTED]> wrote: Hi, as expected 0.8.2 make windows 64 works. There is however a smallproblem with network card. Windows 64 do not support old ne card so Iused rtl8139. It seems that 8139plus card make windows enter in an infinite loop at shutdown. Changing pci id from 0x20 to 0x10 (that isuse old 8139, not plus) make the card work. I'm unable to find windowsdriver for pcnet so I'm unable to try it. Just to make it happy I wrote this patch that add a rtl8139too card. It simply change pci revision idbut use rtl8139 code.Do you have debugging logs available? I'm interested in fixing the C+ mode without adding 8139too option. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] How to Simulate hardware that counts scanlines?
I'm working on some custom emulated hardware to integrate with qemu's full pc emulation ( i guess you could call it a new target, but really just some mods of the x86 ).. I am curious if there's a way I could simulate counting scanlines. Basically a small piece of the chipset I'm implementing has a register that increments on each scanline pass. Since other parts of the chipset setup the timing, it probably uses some kind of formula to determine when to count them, rather than any kind of mechanism that tells it a scanline just completed.. but I've no idea how the thing really works.. The guest os code is polling this register on a very fast interval, and when it detects a certain # of scanlines have been counted, it will swap it's display buffers, ie, it's waiting for the vblank, so it can have nice smooth animations. What's the best way to approximate this using qemu? Currently, I'm guessing at it, and the animations are choppy. FYI - this is not using VGA at all, it's all custom programmed via the chipset and the running code. I'm not all that familiar with vga hardware, so I didn't really see anything like this in there. I'm not sure if it does anything like that or not, but if it does, I guess I didn't see it.. Hope someone has some good suggestions - Thanks! -Steve ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Trouble with GDB & Some 'Can it be done' Debugging questions
Thanks for your help!! That goes for all the people who responded on the thread! :) Turns out, I just didn't understand what the vmlinux part meant. Being totally new to linux, I just thought that was the required syntax for using gdb with qemu. I didn't realize it was supposed to be the name of the file containing the debug symbols. The reason it was also a bit confusing was that in my case I don't have source code or debug symbols for the code I'm trying to trace through qemu, so for me I found out the correct syntax is just to call gdb with no parameters. When I did that, it properly displayed all the correct instructions (in assembly of course) at each memory location I wanted to view. I think the reason the instructions weren't decoding was because I had called GDB with vmlinux, but that of course, didn't exist, and it confused gdb. Thanks again for all your help. -Steve From: Mulyadi Santosa <[EMAIL PROTECTED]>Reply-To: [EMAIL PROTECTED]To: qemu-devel@nongnu.org, "Steve Ellenoff" <[EMAIL PROTECTED]>Subject: Re: [Qemu-devel] Trouble with GDB & Some 'Can it be done' Debugging questionsDate: Thu, 20 Jul 2006 14:11:43 +0700>Hi Steve...>> > Hi -> >> > I'm having a bit of trouble getting gdb to do what I was hoping it> > would with qemu. Following the instructions in the docs:> >> > #1) I launch qemu with -S -s flags ( since I want to trace the> > bootloader code )> > It says: Waiting gdb connection on port 1234 - which is correct, and> > it opens the monitor window.> >> > #2) I open a second terminal window and type gdb vmlinux> >[cut]...> > "i386-redhat-linux-gnu"...vmlinux: No such file or directory.>>This message obviously said: either you don't actually have "vmlinux">file or you don't give correct path to the vmlinux file. Can you>confirm that you had given correct path? Also, it is possible that its>name isn't vmlinux (since one is free to rename it)...>> > #3) Anytime I try to dump the instruction at the current IP such as:> > (gdb) x /10i $eip> >> > I get this - which means it's not actually reading or displaying the> > memory properly, since those look to be what you would see if it was> > all 0 in memory (or maybe it's all 0xff - whichever).l>>are you sure you had executed this command in gdb?:>target remote localhost:1234>>Seems like gdb is dumping a wrong address space...>> > This leads to my next question:> >> > #4) Can you use gdb to debug and set breakpoints on binary code you> > don't have any source code or other file for the binary, except the> > binary file itself? Everything I've read so far on GDB (and> > especially any GDB Gui front end) seems to suggest it's not possible.> > That would really suck.>>Well, you can, but of course you can't set the breakpoint at certain>source code's line, but instead put the breakpoint explicitly as memory>address.>>Anyway, i really suggest to read more about gdb by typing:>info gdb>in your shell prompt. It will display the complete gdb manual.>>Don't be hesitate to ask (we're all still learning after all)...>>regards,>>Mulyadi> ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
RE: [Qemu-devel] qemu-0.8.2 under Solaris compilation?
I failed to compile qemu-0.8.2 under Solaris on SPARC Sun-Blade-100 box. Does this patch help? It looks like Solaris gcc by default compiles in V8plus (or V8plusa?) mode, not V8 or V9 as I assumed. V8 would be wrong. _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ solaris_fix.diff.bz2 Description: Binary data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu-0.8.2 under Solaris compilation?
I failed to compile qemu-0.8.2 under Solaris on SPARC Sun-Blade-100 box. [EMAIL PROTECTED]: qemu-0.8.2 $ uname -a SunOS cps222 5.10 Generic_118833-03 sun4u sparc SUNW,Sun-Blade-100 [EMAIL PROTECTED]: qemu-0.8.2 $ gcc -v Reading specs from /opt/sfw/bin/../lib/gcc/sparc-sun-solaris2.10/3.4.4/specs Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls Thread model: posix gcc version 3.4.4 [EMAIL PROTECTED]: qemu-0.8.2 --- ... .8.2/slirp -c -o vl.o /home/faculty/r/rattan/qemu-0.8.2/vl.c /home/user/r/rattan/qemu-0.8.2/vl.c: In function `cpu_get_ticks': /home/user/r/rattan/qemu-0.8.2/vl.c:589: warning: implicit declaration of function `cpu_get_real_ticks' /home/user/r/rattan/qemu-0.8.2/vl.c: In function `init_timer_alarm': /home/user/r/rattan/qemu-0.8.2/vl.c:1008: warning: label `use_itimer' defined but not used /home/user/r/rattan/qemu-0.8.2/vl.c: In function `net_slirp_smb': /home/user/r/rattan/qemu-0.8.2/vl.c:2931: warning: int format, pid_t arg (arg 4) /home/user/r/rattan/qemu-0.8.2/vl.c: In function `create_pidfile': /home/user/r/rattan/qemu-0.8.2/vl.c:3892: warning: int format, pid_t arg (arg 3) /home/user/r/rattan/qemu-0.8.2/vl.c: At top level: /home/user/r/rattan/qemu-0.8.2/vl.c:922: warning: 'start_rtc_timer' defined but not used /home/user/r/rattan/qemu-0.8.2/vl.c: In function `cpu_get_ticks': /home/user/r/rattan/qemu-0.8.2/vl.c:589: warning: implicit declaration of function `cpu_get_real_ticks' ... lm -lz -lsocket -lnsl -lresolv -L/opt/sfw/lib -R/opt/sfw/lib -lSDL -lpthread -lposix4 Undefined first referenced symbol in file cpu_get_real_ticks vl.o ld: fatal: Symbol referencing errors. No output written to qemu collect2: ld returned 1 exit status gmake[1]: *** [qemu] Error 1 gmake[1]: Leaving directory `/home/user/r/rattan/qemu-0.8.2/i386-softmmu' make: *** [subdir-i386-softmmu] Error 2 Any ideas? -ishwar ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: high CPU load / async IO?
On Wed, Jul 26 2006, Sven Köhler wrote: > > Sounds good, so at least it's on its way :-) > > It's on of those big items left on the TODO, so will be good to see go > > in. Then one should implement an ahci host controller for queued > > command support next... > Or use the scsi emulation :-) > >>> Ah, did not know that queueing was fully implemented there yet! > >> It isn't, but it's nearer than the SATA emulation! > > > > ahci wouldn't be too much work, but definitely more so than finishing > > the scsi bits! > > That sounds great! I feel, like my dreams come true. > > > BTW: Fabrice said, he will use the POSIX AIO (i guess, he means > http://www.bullopensource.org/posix/ in case of Linux, right?) Well I would assume that he just would use the glibc posix aio, which is suboptimal but at least the code can be reused. The bull project looks like it's trying to mimic posix aio on top of linux aio, so (if they got the details right) that should be faster. I didn't check their sources, though. You should be able to use the bull stuff with qemu, it would most likely overloading the glibc function for posix aio. > Which other OS do also support the POSIX AIO API? No idea really, but I would guess any "unixy" OS out there. -- Jens Axboe ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: [PATCH][RFC] configure changes to support cross compiling with mingw32
On Tue, 25 Jul 2006 15:15:49 -0500, Anthony Liguori wrote:
> @@ -448,15 +472,10 @@ sdl_too_old=no
>
> if test -z "$sdl" ; then
>
> -sdl_config="sdl-config"
> +sdl_config="${cross-prefix}sdl-config"
That should obviously be cross_prefix :-) Cross compiling SDL seems to be
pretty darn nasty and the binary they provide assumes i386- After
changing the sdl-config to report the right info, things seem to work for
me though.
Regards,
Anthony Liguori
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: high CPU load / async IO?
> Sounds good, so at least it's on its way :-) > It's on of those big items left on the TODO, so will be good to see go > in. Then one should implement an ahci host controller for queued > command support next... Or use the scsi emulation :-) >>> Ah, did not know that queueing was fully implemented there yet! >> It isn't, but it's nearer than the SATA emulation! > > ahci wouldn't be too much work, but definitely more so than finishing > the scsi bits! That sounds great! I feel, like my dreams come true. BTW: Fabrice said, he will use the POSIX AIO (i guess, he means http://www.bullopensource.org/posix/ in case of Linux, right?) Which other OS do also support the POSIX AIO API? signature.asc Description: OpenPGP digital signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: QEMU GUI-Frontend based on Libvert API
On Fri, Jul 21, 2006 at 02:21:21PM -0500, Anthony Liguori wrote: > As far as I know, the big hurdle for QEMU and libvirt right now is not any > GUI aspects (VNC would work just fine). It's interacting with QEMU. Xen > provides an XML-RPC interface to managing instances whereas QEMU only > really provides the monitor interface. Of course, there's still a bit of > work to do before libvirt uses actually uses that interface (it currently > uses the older S-Expression/HTTP interface). Basically, there's quite a > bit of work to do in libvirt before you could even start writing a GUI for > QEMU. Yep, it's still in my TODO list. Unfortunately I lost track of QEmu devel recently, so I may need to restart from scratch it seems, but I really want to be able to manage QEmu instances from libvirt. What makes me a bit uneasy is that I didn't really got feedback on my previous patch, so I'm left with the feeling that having work I do integrated might be hard. The two things really needed are the possibility to enumerate quickly what qemu instances are running and then be able to connect to them dynamically to extract informations or control them. The first one could be done by a centralized tool (if if you also caught qemu isntances started on from user shell) or for example by a list of socket in a dedicated directory, the second one would preferably an unix socket or an xml-rpc interface but the later means an XML dependancy and is probably a bit heavy for the task. Is it possible to get some sort of agreement that this would be a good idea to add (then technical issues and patches could be discussed with reasonable expectation that it would end up being integrated) ? Daniel -- Daniel Veillard | Red Hat http://redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: high CPU load / async IO?
On Wed, Jul 26 2006, Paul Brook wrote: > On Wednesday 26 July 2006 13:23, Jens Axboe wrote: > > On Wed, Jul 26 2006, Paul Brook wrote: > > > > Sounds good, so at least it's on its way :-) > > > > It's on of those big items left on the TODO, so will be good to see go > > > > in. Then one should implement an ahci host controller for queued > > > > command support next... > > > > > > Or use the scsi emulation :-) > > > > Ah, did not know that queueing was fully implemented there yet! > > It isn't, but it's nearer than the SATA emulation! ahci wouldn't be too much work, but definitely more so than finishing the scsi bits! -- Jens Axboe ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: high CPU load / async IO?
> Sounds good, so at least it's on its way :-) > It's on of those big items left on the TODO, so will be good to see go > in. Then one should implement an ahci host controller for queued command > support next... Or use the scsi emulation :-) Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: high CPU load / async IO?
On Wednesday 26 July 2006 13:23, Jens Axboe wrote: > On Wed, Jul 26 2006, Paul Brook wrote: > > > Sounds good, so at least it's on its way :-) > > > It's on of those big items left on the TODO, so will be good to see go > > > in. Then one should implement an ahci host controller for queued > > > command support next... > > > > Or use the scsi emulation :-) > > Ah, did not know that queueing was fully implemented there yet! It isn't, but it's nearer than the SATA emulation! Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: high CPU load / async IO?
On Wed, Jul 26 2006, Paul Brook wrote: > > Sounds good, so at least it's on its way :-) > > It's on of those big items left on the TODO, so will be good to see go > > in. Then one should implement an ahci host controller for queued command > > support next... > > Or use the scsi emulation :-) Ah, did not know that queueing was fully implemented there yet! -- Jens Axboe ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] AltGr keystrokes
Hello,
I'm using Qemu 0.8.2 on Microsoft Windows XP and the AltGr key doesn't seem
to work at all using windib (using directx support it works but the keyboard
mappig isn't correct, even forcing a keymap via -k option). I tried to press
AltGr+ but no output is produced. This is a real matter because
it's impossible to print out (in a easy way) character as: @,#,[ and ],{ and
} and .
There are workarounds?
Thank you,
--
Gaedevel
_
Personalizza MSN Messenger con sfondi e fotografie!
http://spaces.msn.com/morespaces.aspx
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] 0.8.2 and win64
Hi,
On Wed, 26 Jul 2006, Johannes Schindelin wrote:
> On Wed, 26 Jul 2006, ZIGLIO, Frediano, VF-IT wrote:
>
> > -s = &d->rtl8139;
> > -
> > /* I/O handler for memory-mapped I/O */
> > s->rtl8139_mmio_io_addr =
> > cpu_register_io_memory(0, rtl8139_mmio_read, rtl8139_mmio_write, s);
>
> Are you sure it is the right thing to do? rtl8139_mmio_{read,write} still
> expect &d->rtl8139 as opaque, right?
Ah, never mind. You moved it upwards, to set s->PciRevId.
Sorry for the noise,
Dscho
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] 0.8.2 and win64
Hi,
On Wed, 26 Jul 2006, ZIGLIO, Frediano, VF-IT wrote:
> Just to make it happy I wrote this patch that add a rtl8139too card. It
> simply change pci revision id but use rtl8139 code.
Nice.
> -s = &d->rtl8139;
> -
> /* I/O handler for memory-mapped I/O */
> s->rtl8139_mmio_io_addr =
> cpu_register_io_memory(0, rtl8139_mmio_read, rtl8139_mmio_write, s);
Are you sure it is the right thing to do? rtl8139_mmio_{read,write} still
expect &d->rtl8139 as opaque, right?
Ciao,
Dscho
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] 0.8.2 and win64
Hi, as expected 0.8.2 make windows 64 works. There is however a small problem with network card. Windows 64 do not support old ne card so I used rtl8139. It seems that 8139plus card make windows enter in an infinite loop at shutdown. Changing pci id from 0x20 to 0x10 (that is use old 8139, not plus) make the card work. I'm unable to find windows driver for pcnet so I'm unable to try it. Just to make it happy I wrote this patch that add a rtl8139too card. It simply change pci revision id but use rtl8139 code. Frediano Ziglio 8139too.diff Description: 8139too.diff ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Wipe patch
ZIGLIO, Frediano, VF-IT wrote: I use the patch to reduce image size. I use a RIP (repair is possible) ISO image to boot a small Linux system where I can issue ntfswipe (or any other wipe command). Than I can recompress image with qemu-img. Yes, I do similar at the moment. I just boot the windows guest session and use eraser or winhex to erase free space and then recompress with qemu-img. For ext2/3 I use a kernel and utility initramfs I knocked up and then run zerofree on the partition. That works nicely. I'll investigate ntfswipe as that sounds like it might help me make a fully automated re-compression utility. 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] Wipe patch
> > Avi Kivity wrote: > > >> This _looks_ like it would severely impact cpu load during a write. > >> Have you done any testing to determine if this is likely > to impact a > >> normal usage scenario? > > > > Why would it? In most cases, the zero test would terminate quickly, > > without accessing the entire cluster. > > > > Good point, when I looked at it my brain was in zero wipe > mode.. which would be slow but then a > bucketload faster than writing the actual cluster to disk.. > > Brad I use the patch to reduce image size. I use a RIP (repair is possible) ISO image to boot a small Linux system where I can issue ntfswipe (or any other wipe command). Than I can recompress image with qemu-img. freddy77 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Wipe patch
Avi Kivity wrote: This _looks_ like it would severely impact cpu load during a write. Have you done any testing to determine if this is likely to impact a normal usage scenario? Why would it? In most cases, the zero test would terminate quickly, without accessing the entire cluster. Good point, when I looked at it my brain was in zero wipe mode.. which would be slow but then a bucketload faster than writing the actual cluster to disk.. 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] Wipe patch
Brad Campbell wrote: ZIGLIO, Frediano, VF-IT wrote: Hi, well, this is not a definitive patch but it works. The aim is to be able to wipe the disk without allocating entire space. When you wipe a disk the program fill disk with zero bytes so disk image increase to allocate all space. This just patch detect null byte writes and do not write all zero byte clusters. This _looks_ like it would severely impact cpu load during a write. Have you done any testing to determine if this is likely to impact a normal usage scenario? Why would it? In most cases, the zero test would terminate quickly, without accessing the entire cluster. -- error compiling committee.c: too many arguments to function ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
RE: [Qemu-devel] Wipe patch
> > ZIGLIO, Frediano, VF-IT wrote: > > Hi, > > well, this is not a definitive patch but it works. The > aim is to be > > able to wipe the disk without allocating entire space. When > you wipe a > > disk the program fill disk with zero bytes so disk image increase to > > allocate all space. This just patch detect null byte writes > and do not > > write all zero byte clusters. > > This _looks_ like it would severely impact cpu load during a write. > Have you done any testing to determine if this is likely to > impact a normal usage scenario? > > Brad No... as I said is not a definitive patch. I mainly wanted to see comments on this stuff... I'm using it since some weeks and I didn't note all that difference. Do you know any benchmark I could use? Frediano ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Wipe patch
ZIGLIO, Frediano, VF-IT wrote: Hi, well, this is not a definitive patch but it works. The aim is to be able to wipe the disk without allocating entire space. When you wipe a disk the program fill disk with zero bytes so disk image increase to allocate all space. This just patch detect null byte writes and do not write all zero byte clusters. This _looks_ like it would severely impact cpu load during a write. Have you done any testing to determine if this is likely to impact a normal usage scenario? 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
[Qemu-devel] Wipe patch
Hi, well, this is not a definitive patch but it works. The aim is to be able to wipe the disk without allocating entire space. When you wipe a disk the program fill disk with zero bytes so disk image increase to allocate all space. This just patch detect null byte writes and do not write all zero byte clusters. Frediano Ziglio wipe.diff Description: wipe.diff ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: high CPU load / async IO?
On Tue, Jul 25 2006, Fabrice Bellard wrote: > Jens Axboe wrote: > >On Tue, Jul 25 2006, Sven Köhler wrote: > > > >So the current thread-based async dma patch is really just the > >wrong long term solution. A more long term solution is likely in > >the works. It requires quite a bit of code modification though. > > I see. So in other words: > > don't ask for simple async I/O now. The more complex and flexible > sollution will follow soon. > >>> > >>>Yes, hopefully really soon. > >> > >>So i will wait patiently :-) > > > > > >Is anyone actively working on this, or is it just speculation? I'd > >greatly prefer (and might do, if no one is working on it and Fabrice > >would take it) do a libaio version, since that'll for sure perform > >the best on Linux. But a posixaio version might be saner, as that > >should work on other operating systems as well. > > > >Fabrice, can you let people know what you would prefer? > > I am working on an implementation and the first version will use the > posix aio and possibly the Windows ReadFile/WriteFile overlapped I/Os. > Anthony Liguori got a pre version of the code, but it is not > commitable yet. Sounds good, so at least it's on its way :-) It's on of those big items left on the TODO, so will be good to see go in. Then one should implement an ahci host controller for queued command support next... -- Jens Axboe ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
