[Qemu-devel] [patch] non-blocking disk IO
Non-blocking disk IO now works for any type of disk image, not just raw format. There is no longer any format-specific code in the patch: http://people.brandeis.edu/~jcoiner/qemu_idedma/qemu_dma_patch.html You might want this patch if: * you run a multitasking guest OS, * you access a disk sometimes, and * you wouldn't mind if QEMU ran a little faster. Why I have not got feedback in droves I do not understand ;) -John ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] tun/tap networking: patch for existing tun
I'd argue that it should be -tap or -tuntap instead of -tun, since using tun would confuse users who knew the distinction between tun devices and tap devices. Ok for -tuntap long option. Can I propose -t for a short option ? I'm not sure if a -vde option is necessary or a good idea, though. We might want to keep a -socket-fd option around for the really technical people who do funny things like that. (imho -tun-fd is badly named since it doesn't require a tun/tap fd, it works with any type of file descriptor.) So -tun-fd will be renamed -socket-fd. The idea of the -vde option is to have in parameter the VDE socket (default to /tmp/vde.ctl) an act like vde_plug so it don't need any other code to work. Just start a vde_switch and as many qemu -vde you wants to create a complete virtual nework (1 switch and n hosts). -tun-fd (or -socket-fd) should probably be kept around for really specialized applications (and the geeks who know how to use them). We should have options that adaquately cover everything in normal use, of course. Yes, this is the good way to make it, I agree. So an open question: is the -tun and -vde options a good idea to cleanup the network interface options ? To be clear, I don't propose to remove option at this point, but just to make qemu more easy to use for simple and most common setup. Actually, they might just add to the clutter. -dummy-net, -user-net, -nics, -macaddr, etc. It would be even worse if not for the fact that Fabrice has refused to incorporate many networking patches (silently, as usual). The fact that we don't know what Fabrice think about this subjet is a problem. Only Fabrice can commit to the qemu CVS as I understand. I hope Fabrice read this list and can provids to us usefull informations on how to make the patch to get it accepted. So while we're at it, we should redesign the interface for qemu. For each nic, we'd have -net type[,macaddr] where type is tap or user or dummy and the macaddr is an (optional) parameter that replaces -macaddr. Number of nics would depend on number of -net options, with none meaning either no nics or one nic defaulting to tap (or user if tap isn't available). For the tap type we could have a 3rd optional parameter for the name, e.g. -net tap,macaddr,name (with name defaulting to tapX if its not specified). This is an other work, but why not ? I think that a syntax like -net type[:macaddr][,arg[,arg[...]]] is more usefull, since the MAC addresse of the TAP devices is not alway specified as it can be set randomly by the Linux kernel (with possible collision see code in include/linux/etherdevice.h). The advantage of your proposition is that it make more easy to add new type of network device like VDE. This enable to possibility to use a socket-fd type to make everyone happy. In case of this new interface, will network script still needed. If yes, how should we handle them in the new option syntax ? -- Jean-Christian de Rivaz ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] tun/tap networking: patch for existing tun
On Mon, Oct 03, 2005 at 11:46:57AM +0200, Jean-Christian de Rivaz wrote: Ok for -tuntap long option. Can I propose -t for a short option ? Makes sense. The idea of the -vde option is to have in parameter the VDE socket (default to /tmp/vde.ctl) an act like vde_plug so it don't need any other code to work. Just start a vde_switch and as many qemu -vde you wants to create a complete virtual nework (1 switch and n hosts). One potential issue is that the vde code is under the GPL, while qemu (at least the part that we're talking about) is under the BSD license. I'm not sure if use of VDE is common enough to justify having special code for it in qemu anyways. This is an other work, but why not ? I think that a syntax like -net type[:macaddr][,arg[,arg[...]]] is more usefull, since the MAC addresse of the TAP devices is not alway specified as it can be set randomly by the Linux kernel (with possible collision see code in include/linux/etherdevice.h). The macaddr sets the mac address of the guest nic that qemu provides. I do not know if it is possible to set a tap device's mac address on creation but if it is possible then I agree that it would be a useful parameter. The advantage of your proposition is that it make more easy to add new type of network device like VDE. This enable to possibility to use a socket-fd type to make everyone happy. In case of this new interface, will network script still needed. If yes, how should we handle them in the new option syntax ? Network scripts will only be needed for tuntap devices that are created by qemu, same as now. The -n script thing (defaulting to /etc/qemu-ifup) should continue to work fine. The parameters that we choose to pass to the script will be a separate issue. My vote is qemu-ifup tapname macaddr (with macaddr being what was specified on the -net command line or the appropriate default). The fact that we don't know what Fabrice think about this subjet is a problem. Only Fabrice can commit to the qemu CVS as I understand. I hope Fabrice read this list and can provids to us usefull informations on how to make the patch to get it accepted. Actually a lot of the issues have been discussed before. The -net syntax was his idea I believe. Once Fabrice makes his opinion known, he generally will keep quiet until code appears. Once the patch is written, then we can start asking Fabrice for changes or improvements needed to make the patch commitable (as then we'll actually have something substantial for him to look at). -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] tun/tap networking: patch for existing tun
On Mon, 3 Oct 2005, Jean-Christian de Rivaz wrote: The idea of the -vde option is to have in parameter the VDE socket (default to /tmp/vde.ctl) an act like vde_plug so it don't need any other code to work. Just start a vde_switch and as many qemu -vde you wants to create a complete virtual nework (1 switch and n hosts). Or in line with the earlier proposal of a -net option: -net vde,socket=/path/to/vde.ctl,group=xxx where socket defaults to /tmp/vde.ctl and group defaults to 0 if not specified. I think that a syntax like -net type[:macaddr][,arg[,arg[...]]] is more usefull, since the MAC addresse of the TAP devices is not alway specified as it can be set randomly by the Linux kernel (with possible collision see code in include/linux/etherdevice.h). The MAC of the TUN/TAP device on the host side is a completely different thing and is the MAC the HOST should use on that virtual ethernet. What the option to QEMU specifies is the MAC QEMU should use. In case of this new interface, will network script still needed. If yes, how should we handle them in the new option syntax ? -net ...,script=/path/to/script Regards Henrik ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] tun/tap networking: patch for existing tun
On Sun, 2 Oct 2005, Jim C. Brown wrote: So while we're at it, we should redesign the interface for qemu. For each nic, we'd have -net type[,macaddr] where type is tap or user or dummy and the macaddr is an (optional) parameter that replaces -macaddr. Number of nics would depend on number of -net options, with none meaning either no nics or one nic defaulting to tap (or user if tap isn't available). The proposal by Fabrice looks better to me -net usernet,macaddr=00:11:a:0:2:19 -net tunfd=10,macaddr=00:11:a:0:1:19 this way the syntax can easily be extended with new options as needed, and the exact order of things is not important (you just specify the net parameters as needed). Only objection is that for the tunfd case I would use -net tap,fd=10,macaddr=... For the tap type we could have a 3rd optional parameter for the name, e.g. -net tap,macaddr,name (with name defaulting to tapX if its not specified). What about this: -net tap,ifname=qemu0,macaddr=... Regards Henrik ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] tun/tap networking: patch for existing tun
Jim C. Brown a écrit :
The idea of the -vde option is to have in parameter the VDE socket
(default to /tmp/vde.ctl) an act like vde_plug so it don't need any
other code to work. Just start a vde_switch and as many qemu -vde
you wants to create a complete virtual nework (1 switch and n hosts).
One potential issue is that the vde code is under the GPL, while qemu (at
least the part that we're talking about) is under the BSD license.
Ok. that a point to look at. The methode used to connect to a VDE is
simple, and it should be relatively a small work to rewrite a new code
that do that under the BSD license.
I'm not sure if use of VDE is common enough to justify having special code for
it in qemu anyways.
It's matter to make the use of VDE easy for the users. I think it will
become more common that some others options for advancer users. Product
like vmware offert a private network setting in standard.
I think that a syntax like -net type[:macaddr][,arg[,arg[...]]] is
more usefull, since the MAC addresse of the TAP devices is not alway
specified as it can be set randomly by the Linux kernel (with possible
collision see code in include/linux/etherdevice.h).
The macaddr sets the mac address of the guest nic that qemu provides. I do
not know if it is possible to set a tap device's mac address on creation
but if it is possible then I agree that it would be a useful parameter.
From Linux drivers/net/tun.c
static int tun_chr_ioctl(struct inode *inode, struct file *file,
unsigned int cmd, unsigned long arg)
{
[...]
case SIOCSIFHWADDR:
/** Set the character device's hardware address. This
is used when
* filtering packets being sent from the network device
to the character
* device. */
memcpy(tun-dev_addr, ifr.ifr_hwaddr.sa_data,
min(sizeof ifr.ifr_hwaddr.sa_data,
sizeof tun-dev_addr));
DBG(KERN_DEBUG %s: set hardware address:
%x:%x:%x:%x:%x:%x\n,
tun-dev-name,
tun-dev_addr[0], tun-dev_addr[1],
tun-dev_addr[2],
tun-dev_addr[3], tun-dev_addr[4],
tun-dev_addr[5]);
return 0;
Giving this code, I think the answare is yes: it's possible to set the
MAC addresse of a TUN/TAP device.
In case of this new interface, will network script still needed. If yes,
how should we handle them in the new option syntax ?
Network scripts will only be needed for tuntap devices that are created by
qemu, same as now. The -n script thing (defaulting to /etc/qemu-ifup) should
continue to work fine.
The parameters that we choose to pass to the script will be a separate issue.
My vote is qemu-ifup tapname macaddr (with macaddr being what was specified
on the -net command line or the appropriate default).
Ok.
The fact that we don't know what Fabrice think about this subjet is a
problem. Only Fabrice can commit to the qemu CVS as I understand. I hope
Fabrice read this list and can provids to us usefull informations on how
to make the patch to get it accepted.
Actually a lot of the issues have been discussed before. The -net syntax was
his idea I believe. Once Fabrice makes his opinion known, he generally will
keep quiet until code appears.
Once the patch is written, then we can start asking Fabrice for changes or
improvements needed to make the patch commitable (as then we'll actually have
something substantial for him to look at).
Ok. I havn't read all the posts into this maling list, but I hope the
indications you provids are the conclusion of what has been discussed
before.
--
Jean-Christian de Rivaz
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] tun/tap networking: patch for existing tun
On Sun, 2 Oct 2005, Jean-Christian de Rivaz wrote: It's already the case with at least my proposed patch. I have't tested the patch written by Henrik Nordstrom or Lars Munch but it's likly that there work the same way since this feature come from the Linux kernel tun code. Indeed. It is impossible to support persistent TUN/TAP devices without not also supporting dynamically created devices. In fact, if qemu supported both these things, then I don't see a reason for -tun-fd at all (except for something like VDE). Agree, and a -vde option will go forward in this direction. vde is not the only userspace switch available. Locking qemu to only vde would be bad. I then much prefer not having the builtin vde option or even the tun/tap open code and only keep -tun-fd. (from -tun-fd all the others can be implemented by a wrapper opening the connections and handing them over to QEMU) So an open question: is the -tun and -vde options a good idea to cleanup the network interface options? No. To be clear, I don't propose to remove option at this point, but just to make qemu more easy to use for simple and most common setup. See the proposal from Fabrice some month ago on what the command line parameters should look like. Very nice imho. And very easy to extend with new modes (VDE, persistent TUN/TAP, whatever) without having to introduce new confusing options. Regards Henrik ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [patch] non-blocking disk IO
Magnus, I don't think the Windows 2000 install hack will ever be obsolete. The installer assumes that a hard disk will take nonzero time to read some data. QEMU always services a read in zero-guest-time. (With the nonblocking IO patch, zero-guest-time reads still occur, when the requested data is in the host's file cache.) I doubt the IDE spec allows Windows to make this assumption... but the assumption is there, and we work around it by adding a delay that's visible to the guest. -- John ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [patch] non-blocking disk IO
I managed to make it work (qemu+non blocking IO on windows host),
with a rough estimation of 10% speed increase at the early stage of
windows setup. I expect more once windows installs itself in true
multitasking mode. :)
What you need to do is:
- download pthreads-w32-2-6-0-release.tar.gz and compile it from scratch
(make clean GC)
- you also need to add the following lines inside block.c (usleep is not
present in win32/mingw32)
#ifdef WIN32
void usleep(unsigned long usec)
{
Sleep(usec/1000);
}
#endif
- you need to update the link to include -lpthreadGC2 -lz, and
keep a copy of the pthreadGC2.dll where qemu.exe will be
(to pu it just in from of -lz is just my personal suggestion)
HIH,
Christian
On 10/3/05, Elefterios Stamatogiannakis [EMAIL PROTECTED] wrote:
With which pthreads library have you compiled it under windows?
I've tried it with the one here:
ftp://sources.redhat.com/pub/pthreads-win32/
but it didn't compile.
teris.
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] tun/tap networking: patch for existing tun
Henrik Nordstrom a écrit : On Mon, 3 Oct 2005, Jean-Christian de Rivaz wrote: The idea of the -vde option is to have in parameter the VDE socket (default to /tmp/vde.ctl) an act like vde_plug so it don't need any other code to work. Just start a vde_switch and as many qemu -vde you wants to create a complete virtual nework (1 switch and n hosts). Or in line with the earlier proposal of a -net option: -net vde,socket=/path/to/vde.ctl,group=xxx where socket defaults to /tmp/vde.ctl and group defaults to 0 if not specified. Nice. I think that a syntax like -net type[:macaddr][,arg[,arg[...]]] is more usefull, since the MAC addresse of the TAP devices is not alway specified as it can be set randomly by the Linux kernel (with possible collision see code in include/linux/etherdevice.h). The MAC of the TUN/TAP device on the host side is a completely different thing and is the MAC the HOST should use on that virtual ethernet. What the option to QEMU specifies is the MAC QEMU should use. Ok. I was wrong sorry. In case of this new interface, will network script still needed. If yes, how should we handle them in the new option syntax ? -net ...,script=/path/to/script Ok, can't be more clean. -- Jean-Christian de Rivaz ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] tun/tap networking: patch for existing tun
Henrik Nordstrom a écrit : On Sun, 2 Oct 2005, Jean-Christian de Rivaz wrote: It's already the case with at least my proposed patch. I have't tested the patch written by Henrik Nordstrom or Lars Munch but it's likly that there work the same way since this feature come from the Linux kernel tun code. Indeed. It is impossible to support persistent TUN/TAP devices without not also supporting dynamically created devices. Agree. My patch don't drop the dynamic way to use TUN/TAP! Or it has a bug in it. vde is not the only userspace switch available. Locking qemu to only vde would be bad. I then much prefer not having the builtin vde option or even the tun/tap open code and only keep -tun-fd. (from -tun-fd all the others can be implemented by a wrapper opening the connections and handing them over to QEMU) I don't want to stop support of others virtual switch or whatever new interfaces! I just tell about VDE because I like it. Now ok, you can arg that you can make everything with a -tun-fd option, but this requier a wrapper for every use and this is I think the best way to confuse users. See the proposal from Fabrice some month ago on what the command line parameters should look like. Very nice imho. And very easy to extend with new modes (VDE, persistent TUN/TAP, whatever) without having to introduce new confusing options. Ok. -- Jean-Christian de Rivaz ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [patch] non-blocking disk IO
On Mon, Oct 03 2005, John Coiner wrote: Non-blocking disk IO now works for any type of disk image, not just raw format. There is no longer any format-specific code in the patch: http://people.brandeis.edu/~jcoiner/qemu_idedma/qemu_dma_patch.html You might want this patch if: * you run a multitasking guest OS, * you access a disk sometimes, and * you wouldn't mind if QEMU ran a little faster. Why I have not got feedback in droves I do not understand ;) Why not use aio for this instead, seems like a better fit than spawning a thread per block device? That would still require a thread for handling completions, but you could easily just use a single completion thread for all devices for this as it would not need to do any real work. -- Jens Axboe ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] tun/tap networking: patch for existing tun
On Mon, Oct 03, 2005 at 03:07:02PM +0200, Henrik Nordstrom wrote: On Sun, 2 Oct 2005, Jim C. Brown wrote: Only objection is that for the tunfd case I would use -net tap,fd=10,macaddr=... Since it doesn't have to be a tap device, how about this? -net socket,fd=10,macaddr=... For the tap type we could have a 3rd optional parameter for the name, e.g. -net tap,macaddr,name (with name defaulting to tapX if its not specified). What about this: -net tap,ifname=qemu0,macaddr=... That looks fine. Regards Henrik -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] tun/tap networking: patch for existing tun
On Mon, Oct 03, 2005 at 03:01:08PM +0200, Henrik Nordstrom wrote: On Sun, 2 Oct 2005, Jean-Christian de Rivaz wrote: In fact, if qemu supported both these things, then I don't see a reason for -tun-fd at all (except for something like VDE). Agree, and a -vde option will go forward in this direction. vde is not the only userspace switch available. Locking qemu to only vde would be bad. I then much prefer not having the builtin vde option or even the tun/tap open code and only keep -tun-fd. (from -tun-fd all the others can be implemented by a wrapper opening the connections and handing them over to QEMU) Agreed. So -net socket,fd=... or at least -socket-fd (I think it should be made clear that qemu won't require tap fds, just datagram sockets.) To be clear, I don't propose to remove option at this point, but just to make qemu more easy to use for simple and most common setup. See the proposal from Fabrice some month ago on what the command line parameters should look like. Very nice imho. And very easy to extend with new modes (VDE, persistent TUN/TAP, whatever) without having to introduce new confusing options. Agreed. Regards Henrik ___ 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. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] tun/tap networking: patch for existing tun
On Mon, Oct 03, 2005 at 02:54:42PM +0200, Henrik Nordstrom wrote: On Sun, 2 Oct 2005, Jim C. Brown wrote: What it really boils down to is cleaning up the command line options for the network interface(s), which up to now have been added in a hackish, piece-wise manner. And persistent TUN TAP devices makes it extremely clean on the host, and as it is not difficult for qemu there is not really any reason why not. One could obviously drop all the TUN/TAP setup code from qemu, requiring the user to wrap qemu in some application passing it already opened sockets using -tun-fd, but this will be a bit cumbersome to users.. but on the other hand not worse than the users using VDE or similar userspace switches/hubs. This is definitely the wrong way to go. A separate program shouldn't be necessary for handling what is probably the most common networking mode for qemu. qemu should support using tap devices (persistent or otherwise) on its own in an easy-to-understand manner. In fact, I like Fabrice's -net syntax. An argument for adding vde support in qemu itself does exist - but VDE provides its own wrapper so thats not really too much hassle for the end user. Also, VDE may not be popular enough to justify adding vde-specific code to qemu. (I haven't taken any polls, so I don't know if it is or not. Personally I would have no objection. BTW, it seems bochs has native support for vde now.) In fact, if qemu supported both these things, then I don't see a reason for -tun-fd at all (except for something like VDE). VDE and a number of other similar applications is a fairly strong reason to support the -tun-fd functionality I would say. I'd argue that -tun-fd is the wrong name. However, there may be less popular switches (maybe someone can make qemu run on uml_switch for example) - so the functionality should stay. Incidently, does the current -tun-fd code work for windows hosts? Regards Henrik ___ 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. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] about DHCP server in qemu
On Mon, 3 Oct 2005, octane indice wrote: And what about a full IP connection beetween hosts? In order to simulate a real network to do nfs/smtp/http/smb and so on? This is done with a TUN/TAP device, or via a VDE switch using TUN/TAP to connect to the host. Regards Henrik ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] tun/tap networking: patch for existing tun
Hi, Sorry for the lack of comment. I mostly use the 'user-net' networking so I never bothered much about TUN/TAP. What I can say is that the '-net xxx' option will be implemented to solve the existing issues. My only concern is about ensuring backward compatibility (if no one needs it then it is much simpler). Another point is that I am very tempted to integrate a feature to connect several qemu without needing an external program such as VDE. I am thinking of it because it would be relatively easy to add to the existing user-net code (user-net already simulates a kind of LAN). Fabrice. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [patch] non-blocking disk IO
Thank you for the patch. I'll look at it ASAP. If there is no regression (in terms of bugs and performance) I will include it soon: I consider that non blocking I/O is now a critical feature in QEMU in order to get better performances. Fabrice. John Coiner wrote: Non-blocking disk IO now works for any type of disk image, not just raw format. There is no longer any format-specific code in the patch: http://people.brandeis.edu/~jcoiner/qemu_idedma/qemu_dma_patch.html You might want this patch if: * you run a multitasking guest OS, * you access a disk sometimes, and * you wouldn't mind if QEMU ran a little faster. Why I have not got feedback in droves I do not understand ;) -John ___ 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
Re: [Qemu-devel] tun/tap networking: patch for existing tun
Christian MICHON a écrit : to do so, does that mean we would need to launch a 1st qemu instance which would contain the dhcp server, and next qemu instances would connect to it ? if so, 'qemu -server' and 'qemu -client -connect_to server' could be useful... As I understand and with what I know, you can do that now using a virtual network (VDE for example). What matter is that fact that two qemu instances are connected on the same network. DHCP protocol (like any others netowrk protocol) is over that network and is not visible to qemu. To do what you wants, you have to use to different operating system image, one that contains a DHCP server, and the second that contain a DHCP client. 1) create a virtual switch: vde_switch -s /tmp/my_switch.ctl 2) start a virtual server: vdeq -s /tmp/my_switch.ctl qemu-softmmu -hda dhcp-server.bin [...] 3) start a virtual client: vdeq -s /tmp/my_switch.ctl qemu-softmmu -hda dhcp-client.bin [...] -- Jean-Christian de Rivaz ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu inside qemu troubles with FreeBSD 6.0beta4 guest
Hi!
What worked with a 4.11 guest I couldnt get to work with a
6.0beta4 guest: running qemu inside qemu. without kqemu loaded in
both the host and the guest qemu doesnt properly start up in the
guest, top in the guest showing the cpu spending most of its time
servicing interrupts (but none which show up in systat -vm), with
kqemu loaded in the guest the host's qemu hangs as soon as i start
qemu in the guest (monitor (on stdio) and guest dont respond anymore),
and when i attach gdb i get this: (which doesnt tell me much tho -
anyone have an idea?)
$ gdb work/qemu-snapshot-2005-09-09_23/i386-softmmu/qemu 31161
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd...
Attaching to program:
/usr/ports/emulators/qemu/work/qemu-snapshot-2005-09-09_23/i386-softmmu/qemu,
process 31161
Reading symbols from /lib/libm.so.3...done.
Loaded symbols for /lib/libm.so.3
Reading symbols from /lib/libz.so.2...done.
Loaded symbols for /lib/libz.so.2
Reading symbols from /usr/local/lib/libSDL-1.1.so.7...done.
Loaded symbols for /usr/local/lib/libSDL-1.1.so.7
Reading symbols from /lib/libutil.so.4...done.
Loaded symbols for /lib/libutil.so.4
Reading symbols from /usr/lib/libpthread.so.1...done.
Loaded symbols for /usr/lib/libpthread.so.1
Reading symbols from /lib/libc.so.5...done.
Loaded symbols for /lib/libc.so.5
Reading symbols from /usr/lib/libvgl.so.3...done.
Loaded symbols for /usr/lib/libvgl.so.3
Reading symbols from /usr/X11R6/lib/libX11.so.6...done.
Loaded symbols for /usr/X11R6/lib/libX11.so.6
Reading symbols from /usr/X11R6/lib/libXext.so.6...done.
Loaded symbols for /usr/X11R6/lib/libXext.so.6
Reading symbols from /usr/local/lib/libvga.so.1...done.
Loaded symbols for /usr/local/lib/libvga.so.1
Reading symbols from /usr/local/lib/libaa.so.1...done.
Loaded symbols for /usr/local/lib/libaa.so.1
Reading symbols from /usr/lib/libusbhid.so.1...done.
Loaded symbols for /usr/lib/libusbhid.so.1
Reading symbols from /lib/libncurses.so.5...done.
Loaded symbols for /lib/libncurses.so.5
Reading symbols from /usr/X11R6/lib/libXcursor.so.1...done.
Loaded symbols for /usr/X11R6/lib/libXcursor.so.1
Reading symbols from /usr/X11R6/lib/libXrender.so.1...done.
Loaded symbols for /usr/X11R6/lib/libXrender.so.1
Reading symbols from /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2...done.
Loaded symbols for /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
[Switching to LWP 100145]
0x281d0f77 in pthread_testcancel () from /usr/lib/libpthread.so.1
(gdb) bt
#0 0x281d0f77 in pthread_testcancel () from /usr/lib/libpthread.so.1
#1 0x281bf8ca in sigprocmask () from /usr/lib/libpthread.so.1
#2 0x28215f96 in setjmp () from /lib/libc.so.5
#3 0x0001 in ?? ()
#4 0x in ?? ()
#5 0x09b97288 in ?? ()
#6 0x09b97000 in ?? ()
#7 0x080965fa in cpu_x86_exec (env1=0x9b97000)
at /usr/ports/emulators/qemu/work/qemu-snapshot-2005-09-09_23/cpu-exec.c:193
#8 0x0804d34c in main_loop ()
at /usr/ports/emulators/qemu/work/qemu-snapshot-2005-09-09_23/vl.c:2879
#9 0x0804e777 in main (argc=0, argv=0xc099d780)
at /usr/ports/emulators/qemu/work/qemu-snapshot-2005-09-09_23/vl.c:3939
(gdb) fr 7
#7 0x080965fa in cpu_x86_exec (env1=0x9b97000)
at /usr/ports/emulators/qemu/work/qemu-snapshot-2005-09-09_23/cpu-exec.c:193
193 if (setjmp(env-jmp_env) == 0) {
(gdb) l
188 #endif
189 env-exception_index = -1;
190
191 /* prepare setjmp context for exception handling */
192 for(;;) {
193 if (setjmp(env-jmp_env) == 0) {
194 env-current_tb = NULL;
195 /* if an exception is pending, we execute it here */
196 if (env-exception_index = 0) {
197 if (env-exception_index = EXCP_INTERRUPT) {
(gdb) p env
$1 = (struct CPUX86State *) 0x9b97000
(gdb) p *env
$2 = {regs = {3230665952, 3231311552, 0, 3231307648, 3521339392, 3521339404,
3246877824, 10}, eip = 3229438863, eflags = 524290, cc_src = 0,
cc_dst = 3230665952, cc_op = 16, df = 1, hflags = 68276, segs = {{
selector = 40, base = 0, limit = 4294967295, flags = 13603584}, {
selector = 32, base = 0, limit = 4294967295, flags = 13605632}, {
selector = 40, base = 0, limit = 4294967295, flags = 13603584}, {
selector = 40, base = 0, limit = 4294967295, flags = 13603584}, {
selector = 8, base = 4290772992, limit = 4294967295,
flags = 4291793856}, {selector = 27, base = 163075072,
limit = 4294967295, flags = 164623288}}, ldt = {selector = 80,
base = 3231313952, limit = 135, flags = 3221283481}, tr = {selector = 72,
Re: [Qemu-devel] tun/tap networking: patch for existing tun
On Mon, Oct 03, 2005 at 08:29:13PM +0200, Fabrice Bellard wrote: Hi, Sorry for the lack of comment. I mostly use the 'user-net' networking so I never bothered much about TUN/TAP. What I can say is that the '-net xxx' option will be implemented to solve the existing issues. My only concern is about ensuring backward compatibility (if no one needs it then it is much simpler). Doubtful. Not many use tundev.c or tapdev.c VDE is more popular but fixing it for a new syntax is a trivial change. (Probably a one liner, even.) AFAIK nothing else will care. Another point is that I am very tempted to integrate a feature to connect several qemu without needing an external program such as VDE. I am thinking of it because it would be relatively easy to add to the existing user-net code (user-net already simulates a kind of LAN). How would the syntax for this work? Fabrice. ___ 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. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] about DHCP server in qemu
On Mon, Oct 03, 2005 at 05:55:58PM +0200, octane indice wrote: And what about a full IP connection beetween hosts? In order to simulate a real network to do nfs/smtp/http/smb and so on? I was thinking of a sort of a net-server which handles the DHCP process, the connection for going outside (masquerade+DNS+SMB) and the connection beetween hosts. huh? hosts? if u really mean guests, then i'd recommend using vde (or wait for Fabrice's new group usernet mode). if u really mean host, i'd recommend using tuntap. -- - Etes vous un consom'Acteur ? Toutes les saveurs ?quitables sont sur http://www.epicerie-equitable.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. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [patch] non-blocking disk IO
Jens Axboe wrote: Why not use aio for this instead, seems like a better fit than spawning a thread per block device? That would still require a thread for handling completions, but you could easily just use a single completion thread for all devices for this as it would not need to do any real work. Pthreads vs. AIO is an open question. The pthreads implementation works with all disk image formats, without modifying any format-specific code. To use AIO, each image format driver would have to be modified. QEMU already uses pthreads, therefore using pthreads does not add a new dependency on the host platform. (Or so I thought. The build on Windows broke anyway. Haha... my bad...) My questions are: * Which QEMU host platforms support Posix AIO? * Which host platform has the slowest pthreads library, and how many cycles will it waste on pthreads overhead? * What is the likely performance benefit of using AIO? When I have time, I'll hack AIO into the raw image driver, and take some benchmarks on a linux host. Thanks. -John ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [patch] non-blocking disk IO
On Mon, Oct 03, 2005 at 08:41:46AM -0400, John Coiner wrote: Magnus, I don't think the Windows 2000 install hack will ever be obsolete. The installer assumes that a hard disk will take nonzero time to read some data. QEMU always services a read in zero-guest-time. (With the nonblocking IO patch, zero-guest-time reads still occur, when the requested data is in the host's file cache.) I doubt the IDE spec allows Windows to make this assumption... but the assumption is there, and we work around it by adding a delay that's visible to the guest. There are other bugs in the IDE emulation.. I need to try this latest patch, but with the previous DMA patch (without non-blocking support) having a disk image on an AFS filesystem just did not work at all. I am also haveing trouble getting a fresh win2k install under qemu to actually be able to run windows update. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [patch] non-blocking disk IO
Troy Benjegerdes wrote: I am also haveing trouble getting a fresh win2k install under qemu to actually be able to run windows update. I had to download and install Win2k SP4, then Win2k SP4 Hotfixes, and also an IE6 upgrade, before windows update ran. -john ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [patch] non-blocking disk IO
On Mon, 3 Oct 2005, Troy Benjegerdes wrote: Why is there a posix async IO 'standard', but a different linux AIO standard? Because the Posix AIO sucks quite badly both to implement and use. But all Linuxes I know of have a Posix AIO library. Some even have a Posix AIO library using Linux AIO. Having something that wraps both Linux-native AIO and posix async I/O might make supporting it a little easier to swallow on cross-platform applications. If you anyway plan on having Posix AIO support then go for the Posix AIO interface. The performance reasons why Linux AIO exists is very unlikely to be an issue to qemu as you need to be quite I/O intensive to see any performance difference. Regards Henrik ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [patch] non-blocking disk IO
Why is there a posix async IO 'standard', but a different linux AIO standard? Linux has a Posix AIO library that sits on top of linux's native AIO: http://www.bullopensource.org/posix/ It's pretty new, version 0.6. We might not want qemu to depend on it, because most distros probably do not bundle it yet, so it would be an extra dependency for all new users to chase down. -john ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] about DHCP server in qemu
En réponse à Jim C. Brown [EMAIL PROTECTED] : On Mon, Oct 03, 2005 at 05:55:58PM +0200, octane indice wrote: And what about a full IP connection beetween hosts? In order to simulate a real network to do nfs/smtp/http/smb and so on? I was thinking of a sort of a net-server which handles the DHCP process, the connection for going outside (masquerade+DNS+SMB) and the connection beetween hosts. huh? hosts? er, no. It shoulded be guests. if u really mean guests, then i'd recommend using vde (or wait for Fabrice's new group usernet mode). Ok, I'm waiting for that. - Etes vous un consom'Acteur ? Toutes les saveurs équitables sont sur http://www.epicerie-equitable.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [patch] non-blocking disk IO
If you anyway plan on having Posix AIO support then go for the Posix AIO interface. The performance reasons why Linux AIO exists is very unlikely to be an issue to qemu as you need to be quite I/O intensive to see any performance difference. Ideally, we should be able to use a Posix AIO support libary that uses native Linux AIO underneath. What we want is to be able to have the guest OS request some DMA I/O operation, and have qemu be able to use AIO so that the actual disk hardware can dump the data directly in the pages the userspace process on the guest OS ends up wanting it in, avoiding several expensive memcopy and context switch operations. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
