[Qemu-devel] Performance issues with -usb
G'day all, Just a diary note or similar. I've been playing with skype under win2k under qemu with -kernel-kqemu and the alsa audio driver. 1st. The user-net driver appears to be a problem for skype but the tap driver works nicely. 2nd. I was having awful problems with the audio. The app was reporting failures of either the dac or adc apparently randomly and when it did work it was rather intermittent. I noticed that with -usb -usbdevice tablet that qemu sits at about 20% cpu usage (on this machine which is a Pentium-M 1.2G which idles at 600Mhz) whereas without -usb qemu idles completely. In addition to this, without -usb.. skype works almost perfectly. There is the occasional audio glitch (as you would expect) but it does everything it is supposed to do quite nicely. I'm using all the latest gear. A 2.6.18-rc2 host kernel, Latest Qemu CVS and the -pre9 kernel accelerator. Win2k SP4 as a guest with either 256 or 384M of ram depending on my mood :) I'm going to have a dig around in the USB stuff when I get the chance, but it's more of a fyi and for google that I post it here. 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] Performance issues with -usb
On Mon, 2006-07-24 at 13:06 +0400, Brad Campbell wrote: > G'day all, > > Just a diary note or similar. > > I've been playing with skype under win2k under qemu with -kernel-kqemu and > the alsa audio driver. > > 1st. The user-net driver appears to be a problem for skype but the tap driver > works nicely. > > 2nd. I was having awful problems with the audio. The app was reporting > failures of either the dac or > adc apparently randomly and when it did work it was rather intermittent. > > I noticed that with -usb -usbdevice tablet that qemu sits at about 20% cpu > usage (on this machine > which is a Pentium-M 1.2G which idles at 600Mhz) whereas without -usb qemu > idles completely. > > In addition to this, without -usb.. skype works almost perfectly. There is > the occasional audio > glitch (as you would expect) but it does everything it is supposed to do > quite nicely. > > I'm using all the latest gear. A 2.6.18-rc2 host kernel, Latest Qemu CVS and > the -pre9 kernel > accelerator. Win2k SP4 as a guest with either 256 or 384M of ram depending on > my mood :) > > I'm going to have a dig around in the USB stuff when I get the chance, but > it's more of a fyi and > for google that I post it here. Perhaps tweaking the value of ep_bInterval for the tablet's status change endpoint would help? The endpoint descriptor for the tablet currently has this at 3 milliseconds. The hid mouse reports a 10 millisecond polling interval. excerpt from qemu_tablet_config_descriptor in hw/usb-hid.c: /* one endpoint (status change endpoint) */ 0x07, /* u8 ep_bLength; */ 0x05, /* u8 ep_bDescriptorType; Endpoint */ 0x81, /* u8 ep_bEndpointAddress; IN Endpoint 1 */ 0x03, /* u8 ep_bmAttributes; Interrupt */ 0x08, 0x00, /* u16 ep_wMaxPacketSize; */ 0x03, /* u8 ep_bInterval; (255ms -- usb 2.0 spec) */ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] hw/pflash_cfi02.c: duplicate line
Hi, The following trivial patch removes a duplicated line in pflash_cfi02.c - please apply. Index: hw/pflash_cfi02.c === RCS file: /sources/qemu/qemu/hw/pflash_cfi02.c,v retrieving revision 1.2 diff -u -r1.2 pflash_cfi02.c --- hw/pflash_cfi02.c 4 Jul 2006 09:46:31 - 1.2 +++ hw/pflash_cfi02.c 24 Jul 2006 09:09:42 - @@ -135,7 +135,6 @@ #else ret = p[offset]; ret |= p[offset + 1] << 8; -ret |= p[offset + 1] << 8; ret |= p[offset + 2] << 16; ret |= p[offset + 3] << 24; #endif -- Bye, Peter Korsgaard ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Performance issues with -usb
Lonnie Mendez wrote: Perhaps tweaking the value of ep_bInterval for the tablet's status change endpoint would help? The endpoint descriptor for the tablet currently has this at 3 milliseconds. The hid mouse reports a 10 millisecond polling interval. Indeed. I'm not quite sure how or why I did that in the 1st place as the tablet started life as a copy of the mouse in any case. I've had good drag through the specs and all the data sheets for mouse chips I could find out there and most of them seem to recommend a value no faster than 8ms. This drops the cpu utilisation of a Windows guest while idle about 75% when using -usbdevice tablet I've not noticed any change in usability or mouse responsiveness. (I played with values up to 0xFF but after about 0x20 there seemed to be immeasurable/no difference) Index: hw/usb-hid.c === RCS file: /cvsroot/qemu/qemu/hw/usb-hid.c,v retrieving revision 1.5 diff -u -r1.5 usb-hid.c --- hw/usb-hid.c19 Jul 2006 18:06:15 - 1.5 +++ hw/usb-hid.c24 Jul 2006 09:55:22 - @@ -169,7 +169,7 @@ 0x81, /* u8 ep_bEndpointAddress; IN Endpoint 1 */ 0x03, /* u8 ep_bmAttributes; Interrupt */ 0x08, 0x00, /* u16 ep_wMaxPacketSize; */ - 0x03, /* u8 ep_bInterval; (255ms -- usb 2.0 spec) */ + 0x20, /* u8 ep_bInterval; (255ms -- usb 2.0 spec) */ 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] Re: QEMU GUI-Frontend based on Libvert API
On Sun, Jul 23, 2006 at 11:24:22AM -0400, Evan Paul wrote: > Daniel P. Berrange wrote: > >I'd actually go so far as to say - if you added support for QEMU in libvirt > >the 'virt-manager' GUI would 'just work' without need for any further > >coding. > >This is one of the major points of libvirt - you can have multiple backends > >for different virtualization technologies, but your end user applications > >never have to really care (much) about the differences since they are > >presented a consistent API. The only real differences will be in the range > >of virtual hardware devices exposed by each backend & what config options > >they allow. > > Dan, I have this question regarding virt-manager: Does it currently > support actually creating VM. I see features where it provides the > ability to configure stuff but saw nothing about creating VM. That is the main capability under development at this time. I expect it to be in the next release in 3-4 weeks time. > Also, does virt-manager have support to actually install/update a > particular VMM like XEN or QEMU (when support is avaialble) from the GUI > interface itself. If not, that would be a good feature where users can > download a given file within the GUI and some script would auto install > and set it up. Installation of the VMM itself is not a job that is applicable to this application. There are already perfectly good applications for installing software on Linux - RPM, Debian PKG, etc. By virtue of having the virt-manager application installed, packaging dependancies will already have pulled in Xen / QEMU. Windows of course is a completely different scenario, but I know there are plenty of packaging tools for dealing with this on Windows, although I've not used them myself. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Qemu 0.8.2
Hello All, I see that the new version of Qemu is out 0.8.2. Where is the Windows version?? _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Qemu 0.8.2
On Mon, 2006-07-24 at 06:38 -0500, wayne tempel wrote: > Hello All, >I see that the new version of Qemu is out 0.8.2. Where is the > Windows version?? afaik these builds have so far been user contributed. If you do not want to build it yourself you can find a build for qemu 0.8.2 from cvs here: http://www.crazefiles.com/download.php?file=0151e68e I'm sure there will be an updated build at the qemu for windows site in due time: http://www.h7.dion.ne.jp/~qemu-win/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Compile errors on Solaris for qemu 0.8.2
At airport so can't paste. cpu_get_real_ticks doesn't resolve in vl.o. Using blastwave gcc 3.4.6. What am I missing? -- -- Jonathan Kalbfeld +1 323 620 6682 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Compile errors on Solaris for qemu 0.8.2
I ran into this myself yesterday. I couldn't figure out a definitive
answer, because I am no expert on the SPARC architecture, but it appears
that at least on an UltraSparc IIi machine from a few years ago, the
"sparc V9" instructions are supported. However, the gcc by default
doesn't define __sparc_v9__ on that architecture. There are some -m
flags that can be passed to gcc (like multisparc, etc.), but I'm not
sure for what host machines they are appropriate exactly. Perhaps the
SPARC experts on the list can comment more, but in the meantime, the
following simple (but likely incorrect) patch worked fine for me:
Index: cpu-all.h
===
RCS file: /cvsroot/qemu/qemu/cpu-all.h,v
retrieving revision 1.57
diff -a -u -r1.57 cpu-all.h
--- cpu-all.h 18 Jul 2006 21:23:34 - 1.57
+++ cpu-all.h 24 Jul 2006 13:35:47 -
@@ -971,7 +971,7 @@
return val;
}
-#elif defined(__sparc_v9__)
+#elif defined(__sparc__)
static inline int64_t cpu_get_real_ticks (void)
{
Regards,
Leo Reiter
Jonathan Kalbfeld wrote:
> At airport so can't paste. cpu_get_real_ticks doesn't resolve in
> vl.o. Using blastwave gcc 3.4.6. What am I missing?
--
Leonardo E. Reiter
Vice President of Product Development, CTO
Win4Lin, Inc.
Virtual Computing that means Business
Main: +1 512 339 7979
Fax: +1 512 532 6501
http://www.win4lin.com
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Compile errors on Solaris for qemu 0.8.2
Ok will try when back from DC. Thx
On 7/24/06, Leonardo E. Reiter <[EMAIL PROTECTED]> wrote:
I ran into this myself yesterday. I couldn't figure out a definitive
answer, because I am no expert on the SPARC architecture, but it appears
that at least on an UltraSparc IIi machine from a few years ago, the
"sparc V9" instructions are supported. However, the gcc by default
doesn't define __sparc_v9__ on that architecture. There are some -m
flags that can be passed to gcc (like multisparc, etc.), but I'm not
sure for what host machines they are appropriate exactly. Perhaps the
SPARC experts on the list can comment more, but in the meantime, the
following simple (but likely incorrect) patch worked fine for me:
Index: cpu-all.h
===
RCS file: /cvsroot/qemu/qemu/cpu-all.h,v
retrieving revision 1.57
diff -a -u -r1.57 cpu-all.h
--- cpu-all.h 18 Jul 2006 21:23:34 - 1.57
+++ cpu-all.h 24 Jul 2006 13:35:47 -
@@ -971,7 +971,7 @@
return val;
}
-#elif defined(__sparc_v9__)
+#elif defined(__sparc__)
static inline int64_t cpu_get_real_ticks (void)
{
Regards,
Leo Reiter
Jonathan Kalbfeld wrote:
> At airport so can't paste. cpu_get_real_ticks doesn't resolve in
> vl.o. Using blastwave gcc 3.4.6. What am I missing?
--
Leonardo E. Reiter
Vice President of Product Development, CTO
Win4Lin, Inc.
Virtual Computing that means Business
Main: +1 512 339 7979
Fax: +1 512 532 6501
http://www.win4lin.com
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
--
--
Jonathan Kalbfeld
+1 323 620 6682
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Compile errors on Solaris for qemu 0.8.2
I ran into this myself yesterday. I couldn't figure out a definitive
answer, because I am no expert on the SPARC architecture, but it appears
that at least on an UltraSparc IIi machine from a few years ago, the
"sparc V9" instructions are supported. However, the gcc by default
doesn't define __sparc_v9__ on that architecture. There are some -m
flags that can be passed to gcc (like multisparc, etc.), but I'm not
sure for what host machines they are appropriate exactly. Perhaps the
SPARC experts on the list can comment more, but in the meantime, the
following simple (but likely incorrect) patch worked fine for me:
Well, at least my gcc defines __sparc_v9__ if cpu is either v9, ultrasparc
or ultrasparc3:
%{mcpu=v9:-D__sparc_v9__} %{mcpu=ultrasparc:-D__sparc_v9__}
%{mcpu=ultrasparc3:-D__sparc_v9__}
This is from /usr/lib/gcc-lib/sparc-linux/3.3.5/specs. What does your
compiler define, as you still can compile the RDTICK instruction in the
#ifdef section? RDTICK is not available on V8 (Sparc32) architecture, only
on V9.
_
FREE pop-up blocking with the new MSN Toolbar - get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: Re: QEMU GUI-Frontend based on Libvert API
Hello everyone, I've actually tried to do some of these things myself a few months back. I thought I'd have a daemon or "control" program that would manage the QEMU instances. A new instance would be launched by a controller app with a few of additional parameters. One is a custom window title (I added -t parameter support, which sets the title of the window). So if you had two QEMU instances open, the title of one would be "ABC" and the other would be "XYZ", or whatever you named that virtual computer in the control app. I found that while I was testing, having more than one QEMU window with the exact same title is less cumbersome. Also passed at startup was a unqiue ID string generated by the control app. It is used to identify that instance. Lastly, the control app passes it's own process ID. The the QEMU instance contacts the control app with it's unqiue ID, and then control app knows the process ID of the instance. From this point on the two processes can communicate with each other, since they know each other's process ID and can send messages. I then tried to modify the SDL sources and QEMU sources to support receiving messages sent to the window, similar to how (at least Windows) operating systems work. You can send an app's window a "minimize", "maximize", etc., messages and the app will respond to them. So I investigated and found that there is a range of commands set aside specifically for applications to use (they won't collide with system messages). So I figured I'd enumerate various QEMU commands into that region, such as savevm, etc. I then added code to the SDL/QEMU event loop to process those custom commands and translate them into the traditional commands and then let the event loop process the command as normal. It all worked, but my C/C++ is amateur enough that despite everything I tried my string parameters came through corrupt a good chunk of the time. And I've tried allocating my own memory, making copies of the parameter asap before it was deallocated by the OS, etc., but I never did get it stabilized before I ran out of time to work on it. The string is necessary for some commands, such as the loadvm/savevm to specify the path/filename of the image. With this support in QEMU, then any controlling application can easily manage QEMU transparently. Of course, it doesn't address wrapping controls around the QEMU window like VMWare does, but a controlling app would only need to implement a VNC client and map it to a window region or something to that effect, I suppose. I don't know much about the innerworkings of VNC but it seems plausible. -- James Funny quotes: "There are 10 types of people in the world. Those who understand binary, and those who don't." -- Unknown "A computer once beat me at chess, but it was no match for me at kick boxing." -- Emo Philips ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re[2]: [Qemu-devel] Qemu 0.8.2
Hello Lonnie, LM> On Mon, 2006-07-24 at 06:38 -0500, wayne tempel wrote: >> Hello All, >>I see that the new version of Qemu is out 0.8.2. Where is the >> Windows version?? LM>afaik these builds have so far been user contributed. If you do not LM> want to build it yourself you can find a build for qemu 0.8.2 from cvs LM> here: LM> http://www.crazefiles.com/download.php?file=0151e68e I've set up mingw and all the funky stuff (it was not fun to set up). The only problem I haven't been able to figure out is how to compile the executable so it doesn't pop up a DOS console window. Someone built a binary that used message boxes and didn't require a console window to hang around while QEMU is running (in other words, each instance of QEMU had two windows, one console window, and one main application window). The binary this other chap compiled was slick, it only used one window per instance. I haven't been able to figure out what compilation options were needed to make that happen. I saw some patches (back in the 0.7.x-0.8.1 days) that I applied, but it only seemed to change the diagnostic message output from console to message boxes. Anyhow, just my $.02. Wayne, if you wait for a bit I'm sure someone will post the Windows binary of 0.8.2 soon. -- James Funny quotes: "There are 10 types of people in the world. Those who understand binary, and those who don't." -- Unknown "A computer once beat me at chess, but it was no match for me at kick boxing." -- Emo Philips ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: Re[2]: [Qemu-devel] Qemu 0.8.2
On 7/24/06, James Olsen <[EMAIL PROTECTED]> wrote: I've set up mingw and all the funky stuff (it was not fun to set up). The only problem I haven't been able to figure out is how to compile the executable so it doesn't pop up a DOS console window. http://www.mingw.org/mingwfaq.shtml#faq-ridconsole Never seen a version with message boxes, though. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: Re[2]: [Qemu-devel] Qemu 0.8.2
http://www.h7.dion.ne.jp/~qemu-win/ now has 0.8.2 qemu bins. These are the builds that have the messageboxes, last I checked. WD On 7/24/06, André Braga <[EMAIL PROTECTED]> wrote: On 7/24/06, James Olsen <[EMAIL PROTECTED]> wrote: > I've set up mingw and all the funky stuff (it was not fun to set up). > The only problem I haven't been able to figure out is how to compile > the executable so it doesn't pop up a DOS console window. http://www.mingw.org/mingwfaq.shtml#faq-ridconsole Never seen a version with message boxes, though. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- < undrdawg> it was buggy and hung a lot ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: high CPU load / async IO?
On Mon, 24 Jul 2006 00:47:21 +0200, Sven Köhler wrote: > 3) async block I/O (not merged yet) > It's not in HEAD yet, isn't it? The pthread-based async patch is a band-aid. No doubt it helps your particular case, but it's not the right approach long term. IDE only supports one outstanding request, so having a thread that runs the synchronous block routines appears reasonable. However, SATA and SCSI both support multiple outstanding requests. The extension to the existing patch would be simple--increase the number of threads. A number of Xen hackers (primarily Andy Warfield and Dan Smith) have been doing a lot of work analyzing userspace block device performance. As QEMU's CPU virtualization gets faster (ala kqemu or VT/SVM), it will start facing the same bottlenecks that we do today in Xen. To achieve near-native performance, you basically have to be able to saturate the host's IO scheduler queue. Using O_DIRECT, you can do zero-copy meaning that your ability to queue requests is the only limiting factor. What's been discovered is that a thread based approach requires a ton of threads to achieve saturation. Just imagine the contention of having a very large number of threads trying to get at a single BDRVState. The real solution is to modify the block API to be asynchronous and then provide support for interacting with the host IO scheduler queue via something like linux-aio (or the win32 equiv). 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. Regards, Anthony Liguori > Why i'm curious? Well, i'm curious about the improvement it causes. You > people once told me, that the boost will not be that significant. On the > other hand, i see my host CPU usage going towards 100% just because the > guest is doing some IO or ... or is it because of somethine else > perhaps? > > To be concrete: have you guys ever run windows-update inside qemu? Well, > my win2k guest consumes all CPU on the host for some reason. What might > be the reason? > (qemu is started with -kernel-kqemu -m 256 -soundhw es1370) > > Also windows-update's green "progress bar" inside the guest is stopping > for let's say 3 or 5 seconds and not moving continuous. > > Is anybody experiencing the same or knows the reason? > > > Thanks, > Sven > ___ 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
[Qemu-devel] Re: high CPU load / async IO?
>> 3) async block I/O (not merged yet) >> It's not in HEAD yet, isn't it? > > The pthread-based async patch is a band-aid. No doubt it helps your > particular case, but it's not the right approach long term. > > IDE only supports one outstanding request, so having a thread that runs > the synchronous block routines appears reasonable. However, SATA and SCSI > both support multiple outstanding requests. The extension to the existing > patch would be simple--increase the number of threads. ??? Wasn't there another variant using the async-I/O support of the Host OS and thereby supporting a larger number of outstanding requests? > A number of Xen hackers (primarily Andy Warfield and Dan Smith) have been > doing a lot of work analyzing userspace block device performance. As > QEMU's CPU virtualization gets faster (ala kqemu or VT/SVM), it will start > facing the same bottlenecks that we do today in Xen. > > To achieve near-native performance, you basically have to be able to > saturate the host's IO scheduler queue. Using O_DIRECT, you can do > zero-copy meaning that your ability to queue requests is the only limiting > factor. > > What's been discovered is that a thread based approach requires a ton of > threads to achieve saturation. Just imagine the contention of having a > very large number of threads trying to get at a single BDRVState. > > The real solution is to modify the block API to be asynchronous and then > provide support for interacting with the host IO scheduler queue via > something like linux-aio (or the win32 equiv). The approch that i mentioned above (using the host's async I/O) is what you mean with using linux-aio, right? > 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. signature.asc Description: OpenPGP digital signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re QuickStartGuide on QEMU Wiki
Here is a super short addition you might want to add to the
QuickStartGuide page, stolen from someone's posting in the Forums. Feel
free to edit as I am a newbie here myself. Sorry I couldn't properly
respond to the original post in this thread but I've just joined the
list.
== Linux Guest on Linux Host ==
Create an empty 3 GB image file. You will be installing into this:
{{{
qemu-img create mylinux.raw 3G
}}}
Install from a downloaded iso file:
{{{
qemu -hda mylinux.raw -cdrom /dev/cdrom -boot d -net user -m 256
}}}
Run the installation:
{{{
qemu -hda mylinux.raw -cdrom /dev/cdrom -boot c -net user -m 256
}}}
---
Andrew Malcolmson
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re QuickStartGuide on QEMU Wiki
> qemu -hda mylinux.raw -cdrom /dev/cdrom -boot d -net user -m 256 This is wrong. "-net user" by itself won't give you a working network. You need to specify "-net nic -net user" (this is the default if no -net options are given). Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] sparc-softmmu
Hi, After openbios-sparc32 is introduced for sparc-softmmu, I can see a Linux penguin but can't see booting texts. When it is used with -nographic, I can see prompt. It seems that texts are not shown. It is both on Linux and Windows hosts. Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
