Re: [Qemu-devel] [PATCH] VNC display support for QEMU
Hi, On Sat, 29 Apr 2006, Anthony Liguori wrote: > I would have been more inclined to use LibVNCServer if it wasn't based > on threading. I really wanted an asynchronous implementation of a VNC > server that didn't depend on threads. AFAICT it does not. In vnc_refresh(), there is a call to rfbProcessEvents, which says to select() the socket(s) for 0 microseconds. Same thread. Now, there is a facility in LibVNCServer to take advantage of pthreads, and in some applications it is actually better to run a background thread to handle all the VNC stuff. But it is not used in QEmu. Ciao, Dscho ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu Makefile configure
Attached is a patch to fix 'make install' when the docs are not built (it currently fails). - Leo Reiter Paul Brook wrote: > CVSROOT: /sources/qemu > Module name: qemu > Branch: > Changes by: Paul Brook <[EMAIL PROTECTED]> 06/04/23 17:57:59 > > Modified files: > . : Makefile configure > > Log message: > Autodetect tools neccessary for building documentation. > Make distclean remove generated documentation files. > > CVSWeb URLs: > http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/Makefile.diff?tr1=1.96&tr2=1.97&r1=text&r2=text > http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/configure.diff?tr1=1.93&tr2=1.94&r1=text&r2=text -- 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 Index: Makefile === RCS file: /cvsroot/qemu/qemu/Makefile,v retrieving revision 1.97 diff -a -u -r1.97 Makefile --- Makefile 23 Apr 2006 17:57:59 - 1.97 +++ Makefile 30 Apr 2006 15:03:51 - @@ -55,11 +55,15 @@ video.x proll.elf linux_boot.bin; do \ $(INSTALL) -m 644 $(SRC_PATH)/pc-bios/$$x "$(DESTDIR)$(datadir)"; \ done +ifdef BUILD_DOCS mkdir -p "$(DESTDIR)$(docdir)" $(INSTALL) -m 644 qemu-doc.html qemu-tech.html "$(DESTDIR)$(docdir)" +endif ifndef CONFIG_WIN32 +ifdef BUILD_DOCS mkdir -p "$(DESTDIR)$(mandir)/man1" $(INSTALL) qemu.1 qemu-img.1 "$(DESTDIR)$(mandir)/man1" +endif mkdir -p "$(DESTDIR)$(datadir)/keymaps" for x in $(KEYMAPS); do \ $(INSTALL) -m 644 $(SRC_PATH)/keymaps/$$x "$(DESTDIR)$(datadir)/keymaps"; \ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] VNC display support for QEMU
Johannes Schindelin wrote: Hi, On Sat, 29 Apr 2006, Anthony Liguori wrote: I would have been more inclined to use LibVNCServer if it wasn't based on threading. I really wanted an asynchronous implementation of a VNC server that didn't depend on threads. AFAICT it does not. In vnc_refresh(), there is a call to rfbProcessEvents, which says to select() the socket(s) for 0 microseconds. Same thread. There is a fundamental design in the LibVNCServer code (which I believe was inherited from the various RealVNC derivatives) that all IO is done through some derivation of rfbReadExact. rfbReadExact is semantically synchronous (it uses select to enforce that). You could, perhaps, not begin an iteration of the server message process loop until the socket becomes readable but that only gives you a semi-asynchronous interface. As soon as you get 1 byte of message data, you are now handling things synchronously until that message is complete. Since QEMU is single threaded, this means everything blocks (including progress of the guest). This theoretical problem is why I implemented a true asynchronous VNC implementation. You'll notice that I use a state machine to handle the message dispatch (which is practical for the server side of the VNC protocol at least). My VNC will never (assuming it's working correctly :-)) block guest progress because of outstanding IO. There is a practical problem too with a semi-asynchronous approach. It's entirely possible to get serious congestion in odd places during a message transmission (or even a loss that requires timeout). This means you could end up blocking the guest for a prolonged period of time (and if the guest is doing serious work--like hosting some sort of network service--this is catastrophic). So, in a multithreaded application or a single-threaded application that doesn't have to worry about these things, LibVNCServer is a great solution. I just don't think it's the right solution for QEMU for the reasons outlined above. Regards, Anthony Liguori Now, there is a facility in LibVNCServer to take advantage of pthreads, and in some applications it is actually better to run a background thread to handle all the VNC stuff. But it is not used in QEmu. Ciao, Dscho ___ 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] Large USB patch
Attached is another patch to implement the said resume code. With
this patch, devices attached to windows xp guest are able to resume the
controller when necessary. Before, if a device was attached to the
usbhub and windows had the root hub set for power savings then the bus
would stay suspended.
It implements the function usb_wakeup_controller which can be called
with a USBDevice handle for the device that is causing the event.
--- a/qemu/hw/usb-uhci.c2006-04-30 14:32:43.0 -0500
+++ b/qemu/hw/usb-uhci.c2006-04-30 15:03:46.0 -0500
@@ -102,6 +102,7 @@
} UHCI_QH;
static int uhci_attach (USBDevice *hub, USBDevice *dev, int portnum);
+static void uhci_resume (void *opaque);
static void uhci_update_irq (UHCIState *s)
{
@@ -338,13 +339,6 @@
UHCIPort *port;
int i;
-// wakeup the controller if suspended
-if (s->cmd & UHCI_CMD_EGSM) {
-s->cmd |= UHCI_CMD_FGR;
-s->status |= UHCI_STS_RD;
-uhci_update_irq(s);
-}
-
if (dev) {
if( portnum >= NB_PORTS ) {
#ifdef DEBUG
@@ -385,6 +379,9 @@
port->ctrl |= UHCI_PORT_LSDA;
else
port->ctrl &= ~UHCI_PORT_LSDA;
+
+uhci_resume(s);
+
/* send the attach message */
port->dev= dev;
port->dev->handle_msg (port->dev, USB_MSG_ATTACH);
@@ -401,6 +398,9 @@
port->ctrl &= ~UHCI_PORT_EN;
port->ctrl |= UHCI_PORT_ENC;
}
+
+uhci_resume(s);
+
if (port->dev) {
/* send the detach message */
port->dev->handle_msg(port->dev, USB_MSG_DETACH);
@@ -412,6 +412,21 @@
}
}
+/* signal resume if controller suspended */
+static void uhci_resume (void *opaque)
+{
+UHCIState *s = (UHCIState *)opaque;
+
+if (!s)
+return;
+
+if (s->cmd & UHCI_CMD_EGSM) {
+s->cmd |= UHCI_CMD_FGR;
+s->status |= UHCI_STS_RD;
+uhci_update_irq(s);
+}
+}
+
static int uhci_broadcast_packet(UHCIState *s, uint8_t pid,
uint8_t devaddr, uint8_t devep,
uint8_t *data, int len)
@@ -732,6 +738,7 @@
dev->speed= USB_SPEED_FULL;
dev->state= USB_STATE_ATTACHED;
dev->handle_attach= &uhci_attach;
+dev->handle_resume= &uhci_resume;
for(i = 0; i < NB_PORTS; i++) {
s->ports[i].dev= NULL;
}
--- a/qemu/hw/usb.h 2006-04-30 14:32:43.0 -0500
+++ b/qemu/hw/usb.h 2006-04-30 15:14:23.0 -0500
@@ -187,6 +187,7 @@
int (*handle_data)(USBDevice *dev, int pid, uint8_t devep,
uint8_t *data, int len);
int (*handle_attach) (USBDevice *hub, USBDevice *dev, int
portnum);
+void(*handle_resume) (void *opaque);
};
/* Maximum of simultaneous USB Devices including all USB Controllers */
@@ -212,6 +213,9 @@
USBDevice* usb_find_device (char *path);
char* usb_find_name (USBDevice *device);
+/* resumes a suspended controller that given device is attached to */
+void usb_wakeup_controller(USBDevice *dev);
+
/* function which adds or removes the usb devices according to usb_tree */
int usb_update_devices (PCIBus *pci_bus);
/* functions which show info on the available usb devices - used by monitor.c*/
--- a/qemu/hw/usb.c 2006-04-30 14:32:43.0 -0500
+++ b/qemu/hw/usb.c 2006-04-30 15:14:35.0 -0500
@@ -401,6 +408,27 @@
}
}
+/* communicate resume to host controller */
+void usb_wakeup_controller(USBDevice *dev)
+{
+USBTree *tree = usb_tree;
+USBDevice *controller = NULL;
+char bus_path[5];
+
+if (dev == NULL)
+return;
+
+for (; tree != NULL; tree= tree->next) {
+if (tree->dev == dev) { // have match - next find root controller
+strncpy(bus_path, tree->path, 3);
+controller = usb_find_device(bus_path);
+if (controller && controller->handle_resume) // send resume if
implemented
+controller->handle_resume(controller->opaque);
+break;
+}
+}
+}
+
/* remove a usb device, the following steps are taken:
1. find the device
2. let his father know
@@ -608,6 +636,7 @@
dev->handle_msg=&usb_dummy_handle_msg;
dev->handle_data= &usb_dummy_handle_data;
dev->handle_attach= &usb_dummy_handle_attach;
+dev->handle_resume= NULL;
}
return dev;
}
--- a/qemu/hw/usb-hub.c 2006-04-30 14:33:29.0 -0500
+++ b/qemu/hw/usb-hub.c 2006-04-30 15:13:22.0 -0500
@@ -212,12 +212,20 @@
port->wPortStatus |= PORT_STAT_LOW_SPEED;
else
port->wPortStatus &= ~PORT_STAT_LOW_SPEED;
+
+if (hub->remote_wakeup)
+usb_wakeup_controller(dev);
+
port->dev = dev;
port->dev->handle_msg (port->dev, USB_MSG_ATTACH);
[Qemu-devel] [PATCH] Enhanced Documentation
Here are three patches which enhance and fix the existing QEMU
documentation.
1. Makefile: added rules to build qemu-doc and qemu-tech in info and dvi
format.
I did not add a dependency which calls these rules automatically, so run
make qemu-doc.info qemu-tech.info qemu-doc.dvi qemu-tech.dvi
to build the new targets.
2. qemu-doc.texi, qemu-tech.texi:
* fixed for generation of info files
* fixed long lines for generation of dvi / ps / pdf files
* fixed html title
* added menus for html and info
* added table of contents for html and dvi
* added index (still empty) for html, info and dvi
* fixed minor spelling bug (reasonnable)
All documentation formats should build now without error messages
(my test on Debian Linux passed).
Regards
Stefan Weil
Index: qemu-doc.texi
===
RCS file: /sources/qemu/qemu/qemu-doc.texi,v
retrieving revision 1.85
diff -u -b -B -u -r1.85 qemu-doc.texi
--- qemu-doc.texi 23 Apr 2006 21:57:03 - 1.85
+++ qemu-doc.texi 30 Apr 2006 20:38:33 -
@@ -1,16 +1,46 @@
\input texinfo @c -*- texinfo -*-
[EMAIL PROTECTED] %**start of header
[EMAIL PROTECTED] qemu-doc.info
[EMAIL PROTECTED] QEMU CPU Emulator User Documentation
[EMAIL PROTECTED] 0
[EMAIL PROTECTED] 0
[EMAIL PROTECTED] %**end of header
@iftex
[EMAIL PROTECTED] QEMU CPU Emulator User Documentation
@titlepage
@sp 7
[EMAIL PROTECTED] @titlefont{QEMU CPU Emulator User Documentation}
[EMAIL PROTECTED] @titlefont{QEMU CPU Emulator}
[EMAIL PROTECTED] 1
[EMAIL PROTECTED] @titlefont{User Documentation}
@sp 3
@end titlepage
@end iftex
[EMAIL PROTECTED]
[EMAIL PROTECTED] Top
[EMAIL PROTECTED]
+
[EMAIL PROTECTED]
+* Introduction::
+* Installation::
+* QEMU PC System emulator::
+* QEMU System emulator for non PC targets::
+* QEMU Linux User space emulator::
+* compilation:: Compilation from the sources
+* Index::
[EMAIL PROTECTED] menu
[EMAIL PROTECTED] ifnottex
+
[EMAIL PROTECTED]
+
[EMAIL PROTECTED] Introduction
@chapter Introduction
[EMAIL PROTECTED]
+* intro_features:: Features
[EMAIL PROTECTED] menu
+
[EMAIL PROTECTED] intro_features
@section Features
QEMU is a FAST! processor emulator using dynamic translation to
@@ -52,27 +82,53 @@
For user emulation, x86, PowerPC, ARM, MIPS, and Sparc32/64 CPUs are supported.
[EMAIL PROTECTED] Installation
@chapter Installation
If you want to compile QEMU yourself, see @ref{compilation}.
[EMAIL PROTECTED]
+* install_linux:: Linux
+* install_windows:: Windows
+* install_mac:: Macintosh
[EMAIL PROTECTED] menu
+
[EMAIL PROTECTED] install_linux
@section Linux
If a precompiled package is available for your distribution - you just
have to install it. Otherwise, see @ref{compilation}.
[EMAIL PROTECTED] install_windows
@section Windows
Download the experimental binary installer at
[EMAIL PROTECTED]://www.free.oszoo.org/download.html}.
[EMAIL PROTECTED]://www.free.oszoo.org/@/download.html}.
[EMAIL PROTECTED] install_mac
@section Mac OS X
Download the experimental binary installer at
[EMAIL PROTECTED]://www.free.oszoo.org/download.html}.
[EMAIL PROTECTED]://www.free.oszoo.org/@/download.html}.
[EMAIL PROTECTED] QEMU PC System emulator
@chapter QEMU PC System emulator
[EMAIL PROTECTED]
+* pcsys_introduction:: Introduction
+* pcsys_quickstart:: Quick Start
+* sec_invocation:: Invocation
+* pcsys_keys:: Keys
+* pcsys_monitor:: QEMU Monitor
+* disk_images::Disk Images
+* pcsys_network:: Network emulation
+* direct_linux_boot:: Direct Linux Boot
+* pcsys_usb:: USB emulation
+* gdb_usage:: GDB usage
+* pcsys_os_specific:: Target OS specific information
[EMAIL PROTECTED] menu
+
[EMAIL PROTECTED] pcsys_introduction
@section Introduction
@c man begin DESCRIPTION
@@ -118,6 +174,7 @@
@c man end
[EMAIL PROTECTED] pcsys_quickstart
@section Quick Start
Download and uncompress the linux image (@file{linux.img}) and type:
@@ -147,14 +204,14 @@
@item -fda file
@item -fdb file
-Use @var{file} as floppy disk 0/1 image (@xref{disk_images}). You can
+Use @var{file} as floppy disk 0/1 image (@pxref{disk_images}). You can
use the host floppy by using @file{/dev/fd0} as filename.
@item -hda file
@item -hdb file
@item -hdc file
@item -hdd file
-Use @var{file} as hard disk 0, 1, 2 or 3 image (@xref{disk_images}).
+Use @var{file} as hard disk 0, 1, 2 or 3 image (@pxref{disk_images}).
@item -cdrom file
Use @var{file} as CD-ROM image (you cannot use @option{-hdc} and and
@@ -168,7 +225,7 @@
@item -snapshot
Write to temporary files instead of disk image files. In this case,
the raw disk image you use is not written back. You can however force
-the write back by pressing @key{C-a s} (@xref{disk_images}).
+the write back by pressing @key{C-a s} (@pxref{disk_images}).
@item -m megs
Set virtual RAM size to @var{megs} megabytes. Default is 128 MB.
@@ -297,9 +354,12 @@
Example:
@example
[Qemu-devel] qemu ./Changelog ./Makefile.target ./keymaps.c ...
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 06/04/30 21:28:36 Modified files: . : Changelog Makefile.target keymaps.c qemu-doc.texi vl.c vl.h hw : cirrus_vga.c Added files: . : vnc.c vnc_keysym.h vnchextile.h Log message: VNC server (Anthony Liguori) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/Changelog.diff?tr1=1.114&tr2=1.115&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/Makefile.target.diff?tr1=1.105&tr2=1.106&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/keymaps.c.diff?tr1=1.1&tr2=1.2&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/qemu-doc.texi.diff?tr1=1.85&tr2=1.86&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.c.diff?tr1=1.176&tr2=1.177&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.h.diff?tr1=1.115&tr2=1.116&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vnc.c?rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vnc_keysym.h?rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vnchextile.h?rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/cirrus_vga.c.diff?tr1=1.20&tr2=1.21&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu .cvsignore
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 06/04/30 21:33:34 Modified files: . : .cvsignore Log message: update CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/.cvsignore.diff?tr1=1.12&tr2=1.13&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu ./vl.c slirp/libslirp.h slirp/slirp.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 06/04/30 21:34:15 Modified files: . : vl.c slirp : libslirp.h slirp.c Log message: removed warnings CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.c.diff?tr1=1.177&tr2=1.178&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/slirp/libslirp.h.diff?tr1=1.6&tr2=1.7&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/slirp/slirp.c.diff?tr1=1.11&tr2=1.12&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/hw usb-hub.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 06/04/30 21:53:59 Modified files: hw : usb-hub.c Log message: fixes for more than 8 ports - return NAK if no change - FreeBSD workaround (Lonnie Mendez) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/usb-hub.c.diff?tr1=1.2&tr2=1.3&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu qemu-doc.texi qemu-tech.texi
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 06/04/30 21:58:41 Modified files: . : qemu-doc.texi qemu-tech.texi Log message: Enhanced Documentation (Stefan Weil) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/qemu-doc.texi.diff?tr1=1.86&tr2=1.87&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/qemu-tech.texi.diff?tr1=1.8&tr2=1.9&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] VNC display support for QEMU
just a quick note: your patch breaks the mingw32 build on winXP. Christian for d in i386-softmmu; do \ make -C $d all || exit 1 ; \ done make[1]: Entering directory `/home/root/qemu/i386-softmmu' gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I. -I.. -I/home/root/qemu/target-i386 -I/home/root/qemu -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/home/root/qemu/fpu -DHAS_AUDIO -I/home/root/qemu/slirp -c -o vnc.o /home/root/qemu/vnc.c c:/qemu/mingw/home/root/qemu/vnc.c:3:24: sys/socket.h: No such file or directory c:/qemu/mingw/home/root/qemu/vnc.c:4:24: netinet/in.h: No such file or directory c:/qemu/mingw/home/root/qemu/vnc.c:5:25: netinet/tcp.h: No such file or directory c:/qemu/mingw/home/root/qemu/vnc.c: In function `vnc_client_write': c:/qemu/mingw/home/root/qemu/vnc.c:414: error: `ssize_t' undeclared (first use in this function) c:/qemu/mingw/home/root/qemu/vnc.c:414: error: (Each undeclared identifier is reported only once c:/qemu/mingw/home/root/qemu/vnc.c:414: error: for each function it appears in.) c:/qemu/mingw/home/root/qemu/vnc.c:414: error: syntax error before "ret" c:/qemu/mingw/home/root/qemu/vnc.c:417: error: `ret' undeclared (first use in this function) c:/qemu/mingw/home/root/qemu/vnc.c: In function `vnc_client_read': c:/qemu/mingw/home/root/qemu/vnc.c:439: error: `ssize_t' undeclared (first use in this function) c:/qemu/mingw/home/root/qemu/vnc.c:439: error: syntax error before "ret" c:/qemu/mingw/home/root/qemu/vnc.c:443: error: `ret' undeclared (first use in this function) c:/qemu/mingw/home/root/qemu/vnc.c: In function `vnc_listen_read': c:/qemu/mingw/home/root/qemu/vnc.c:810: error: storage size of `addr' isn't known c:/qemu/mingw/home/root/qemu/vnc.c:811: error: `socklen_t' undeclared (first use in this function) c:/qemu/mingw/home/root/qemu/vnc.c:811: error: syntax error before "addrlen" c:/qemu/mingw/home/root/qemu/vnc.c:813: warning: implicit declaration of function `accept' c:/qemu/mingw/home/root/qemu/vnc.c:813: error: `addrlen' undeclared (first use in this function) c:/qemu/mingw/home/root/qemu/vnc.c:815: warning: implicit declaration of function `fcntl' c:/qemu/mingw/home/root/qemu/vnc.c:815: error: `F_SETFL' undeclared (first use in this function) c:/qemu/mingw/home/root/qemu/vnc.c:815: error: `O_NONBLOCK' undeclared (first use in this function) c:/qemu/mingw/home/root/qemu/vnc.c:810: warning: unused variable `addr' c:/qemu/mingw/home/root/qemu/vnc.c: In function `vnc_display_init': c:/qemu/mingw/home/root/qemu/vnc.c:830: error: storage size of `addr' isn't known c:/qemu/mingw/home/root/qemu/vnc.c:853: warning: implicit declaration of function `socket' c:/qemu/mingw/home/root/qemu/vnc.c:853: error: `PF_INET' undeclared (first use in this function) c:/qemu/mingw/home/root/qemu/vnc.c:853: error: `SOCK_STREAM' undeclared (first use in this function) c:/qemu/mingw/home/root/qemu/vnc.c:859: error: `AF_INET' undeclared (first use in this function) c:/qemu/mingw/home/root/qemu/vnc.c:860: warning: implicit declaration of function `htons' c:/qemu/mingw/home/root/qemu/vnc.c:864: warning: implicit declaration of function `setsockopt' c:/qemu/mingw/home/root/qemu/vnc.c:864: error: `SOL_SOCKET' undeclared (first use in this function) c:/qemu/mingw/home/root/qemu/vnc.c:864: error: `SO_REUSEADDR' undeclared (first use in this function) c:/qemu/mingw/home/root/qemu/vnc.c:871: warning: implicit declaration of function `bind' c:/qemu/mingw/home/root/qemu/vnc.c:876: warning: implicit declaration of function `listen' c:/qemu/mingw/home/root/qemu/vnc.c:830: warning: unused variable `addr' make[1]: *** [vnc.o] Error 1 make[1]: Leaving directory `/home/root/qemu/i386-softmmu' make: *** [all] Error 1 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu vl.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 06/04/30 22:20:58 Modified files: . : vl.c Log message: typo CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.c.diff?tr1=1.178&tr2=1.179&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu Makefile
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 06/04/30 22:51:54 Modified files: . : Makefile Log message: info and dvi doc targets CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/Makefile.diff?tr1=1.97&tr2=1.98&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu vl.c vnc.c qemu_socket.h
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 06/04/30 22:53:25 Modified files: . : vl.c vnc.c Added files: . : qemu_socket.h Log message: win32 socket fixes CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.c.diff?tr1=1.179&tr2=1.180&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vnc.c.diff?tr1=1.1&tr2=1.2&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/qemu_socket.h?rev=1.1 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu vl.c vnc.c qemu_socket.h
ah! now it is working on winXP too. :) (you only forgot ssize_t should be long instead for mingw32) I see the old mouse sync problem is still here too... On 5/1/06, Fabrice Bellard <[EMAIL PROTECTED]> wrote: CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 06/04/30 22:53:25 Modified files: . : vl.c vnc.c Added files: . : qemu_socket.h Log message: win32 socket fixes CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.c.diff?tr1=1.179&tr2=1.180&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vnc.c.diff?tr1=1.1&tr2=1.2&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/qemu_socket.h?rev=1.1 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu vl.c vnc.c qemu_socket.h
Christian MICHON wrote: I see the old mouse sync problem is still here too... Launch with -usbdevice tablet appended. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] VNC display support for QEMU
neat! it is working on windows 3.0 guest (no acceleration) on a winXP host. Fabrice fixed it live while I was trying it (he's fast!). old mouse sync problem is still here, as you mentionned no calibration is done. You mention "absolute mouse". how to do it ? On 5/1/06, Christian MICHON <[EMAIL PROTECTED]> wrote: just a quick note: your patch breaks the mingw32 build on winXP. Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu vl.c vnc.c qemu_socket.h
cool. I see now: it has nothing to do with usb being supported by the guest (it's an old win3.0 in this case). I can manage to calibrate by hand the mouse... On 5/1/06, Lonnie Mendez <[EMAIL PROTECTED]> wrote: Christian MICHON wrote: > I see the old mouse sync problem is still here too... Launch with -usbdevice tablet appended. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu vl.c vnc.c qemu_socket.h
I talk too soon. Once re-enabling mouse acceleration, the sync issue is back. Maybe I need a better/more modern guest like XP ? :) On 5/1/06, Christian MICHON <[EMAIL PROTECTED]> wrote: cool. I see now: it has nothing to do with usb being supported by the guest (it's an old win3.0 in this case). I can manage to calibrate by hand the mouse... On 5/1/06, Lonnie Mendez <[EMAIL PROTECTED]> wrote: > Christian MICHON wrote: > > > I see the old mouse sync problem is still here too... > >Launch with -usbdevice tablet appended. > > > ___ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > -- Christian -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu Makefile
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/04/30 23:54:18 Modified files: . : Makefile Log message: Add install-doc rule. Use it when building docs. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/Makefile.diff?tr1=1.98&tr2=1.99&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: [PATCH] VNC display support for QEMU
On Mon, 01 May 2006 01:11:04 +0200, Christian MICHON wrote: > neat! it is working on windows 3.0 guest (no acceleration) on a winXP > host. Fabrice fixed it live while I was trying it (he's fast!). Yeah, sorry about that. Fortunately, Fabrice rocks :-) > old mouse sync problem is still here, as you mentionned no calibration is > done. You mention "absolute mouse". how to do it ? You would need at least a win98 guest. You then have to add '-usb -usbdevice tablet' to the qemu command line. Regards, Anthony Liguori > On 5/1/06, Christian MICHON <[EMAIL PROTECTED]> wrote: >> just a quick note: your patch breaks the mingw32 build on winXP. >> Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Add copyright to VNC code
Hi, I forgot to put a copyright in the VNC code :-) Please apply the attached patch. Regards, Anthony Liguori # HG changeset patch # User Anthony Liguori <[EMAIL PROTECTED]> # Node ID a9314fc39a5e3d78d80d385f560c922c3ce0e82b # Parent 3d3e1931180246af269c8fc24d321536e3cd3096 Add copyright diff -r 3d3e19311802 -r a9314fc39a5e vnc.c --- a/vnc.c Mon May 01 04:54:18 2006 + +++ b/vnc.c Sun Apr 30 19:04:17 2006 -0500 @@ -1,3 +1,28 @@ +/* + * QEMU VNC display driver + * + * Copyright (C) 2006 Anthony Liguori <[EMAIL PROTECTED]> + * Copyright (C) 2006 Fabrice Bellard + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + #include "vl.h" #include "qemu_socket.h" ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Always use 10.0.2.2 as host addr for -net user (slirp)
A couple of serious problems remain in the slirp redirection code
after the patch Paul applied on 23 April.
* If the IP address returned by gethostbyname(gethostname()) is the
address of one of the host's Ethernet interfaces, bringing down that
interface or changing its IP address disrupts redir connections
between the host and VM.
* If the IP address returned by gethostbyname(gethostname()) is
outside the 10.0.2.0/24 subnet, and the user has not manually added
this address to the routing table within the VM (in addition to the
10.0.2.0/24 route added by DHCP), TCP connections from the host to the
VM are never answered, because the response packets are dropped on the
floor.
The attached patch solves both of these problems simply by always
using 10.0.2.2 as our_addr. There seems to be no value in exposing the
host's "real" address to the VM; thanks to NAT, 10.0.2.2 always works.
--Ed
diff -BurN qemu-snapshot-2006-04-27_23.orig/slirp/misc.c qemu-snapshot-2006-04-27_23/slirp/misc.c
--- qemu-snapshot-2006-04-27_23.orig/slirp/misc.c 2006-04-23 19:41:17.0 +
+++ qemu-snapshot-2006-04-27_23/slirp/misc.c 2006-04-27 22:19:40.0 +
@@ -87,17 +87,7 @@
void
getouraddr()
{
- char buff[256];
- struct hostent *he = NULL;
-
- if (gethostname(buff,256) == 0)
-he = gethostbyname(buff);
-if (he)
-our_addr = *(struct in_addr *)he->h_addr;
-/* If the host doesn't have a useful IP address then use the
- guest side address. */
-if (our_addr.s_addr == 0 || our_addr.s_addr == loopback_addr.s_addr)
-our_addr.s_addr = special_addr.s_addr | htonl(CTL_ALIAS);
+ our_addr.s_addr = special_addr.s_addr | htonl(CTL_ALIAS);
}
#if SIZEOF_CHAR_P == 8
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Fix crash due to faulty realloc logic in slirp/mbuf.c
The attached patch fixes a bug in the slirp memory management code.
m_inc() is called during IP reassembly for IP datagrams greater than 4
KB, as arises with NFS. Currently the code assumes that realloc()
always resizes the buffer without moving it; if the buffer is moved,
the m_data pointer is left pointing to an invalid location. The bug
causes qemu to crash when there is any significant amount of NFS
traffic.
The patch restores some commented-out code that updates m_data correctly.
--Ed
diff -BurN qemu-snapshot-2006-03-27_23.orig/slirp/mbuf.c qemu-snapshot-2006-03-27_23/slirp/mbuf.c
--- qemu-snapshot-2006-03-27_23.orig/slirp/mbuf.c 2004-04-22 00:10:47.0 +
+++ qemu-snapshot-2006-03-27_23/slirp/mbuf.c 2006-04-05 13:03:03.0 +
@@ -146,18 +146,19 @@
struct mbuf *m;
int size;
{
+ int datasize;
+
/* some compiles throw up on gotos. This one we can fake. */
if(m->m_size>size) return;
if (m->m_flags & M_EXT) {
- /* datasize = m->m_data - m->m_ext; */
+ datasize = m->m_data - m->m_ext;
m->m_ext = (char *)realloc(m->m_ext,size);
/* if (m->m_ext == NULL)
* return (struct mbuf *)NULL;
*/
- /* m->m_data = m->m_ext + datasize; */
+ m->m_data = m->m_ext + datasize;
} else {
- int datasize;
char *dat;
datasize = m->m_data - m->m_dat;
dat = (char *)malloc(size);
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Fix crash due to incorrect pointer logic in slirp/ip_input.c
Another memory management bug in the slirp code causes qemu to crash
while attempting to reassemble a fragmented IP packet. While iterating
through a list of buffers, if m_cat() moves the current buffer, the
pointer to the next buffer is read from an invalid location.
The attached patch simply reads the next buffer pointer before calling
m_cat(). Incidentally, this is also the fix adopted in the BSD
networking stack, from which slirp was originally derived.
--Ed
diff -BurN qemu-snapshot-2006-03-27_23.orig/slirp/ip_input.c qemu-snapshot-2006-03-27_23/slirp/ip_input.c
--- qemu-snapshot-2006-03-27_23.orig/slirp/ip_input.c 2004-04-22 00:10:47.0 +
+++ qemu-snapshot-2006-03-27_23/slirp/ip_input.c 2006-04-06 06:02:52.0 +
@@ -344,8 +344,8 @@
while (q != (struct ipasfrag *)fp) {
struct mbuf *t;
t = dtom(q);
- m_cat(m, t);
q = (struct ipasfrag *) q->ipf_next;
+ m_cat(m, t);
}
/*
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Fix scrambling of >32KB packets in slirp
In several places in qemu's slirp code, signed and unsigned ints are
used interchangeably when dealing with IP packet lengths and offsets.
This causes IP packets greater than 32K in length to be scrambled in
various interesting ways that are extremely difficult to troubleshoot.
Although large IP packets are fairly rare in practice, certain
UDP-based protocols like NFS use them extensively.
The attached patch wraps IP packet lengths and offsets in macros that
ensure they are always properly treated as unsigned values.
--Ed
diff -burN qemu-snapshot-2006-03-27_23.orig/slirp/ip.h qemu-snapshot-2006-03-27_23/slirp/ip.h
--- qemu-snapshot-2006-03-27_23.orig/slirp/ip.h 2004-04-21 17:10:47.0 -0700
+++ qemu-snapshot-2006-03-27_23/slirp/ip.h 2006-04-06 00:28:49.0 -0700
@@ -79,6 +79,11 @@
* We declare ip_len and ip_off to be short, rather than u_short
* pragmatically since otherwise unsigned comparisons can result
* against negative integers quite easily, and fail in subtle ways.
+ *
+ * The only problem with the above theory is that these quantities
+ * are in fact unsigned, and sorting fragments by a signed version
+ * of ip_off doesn't work very well, nor does length checks on
+ * ip packets with a signed version of their length!
*/
struct ip {
#ifdef WORDS_BIGENDIAN
@@ -101,6 +106,9 @@
struct in_addr ip_src,ip_dst; /* source and dest address */
};
+#define IP_OFF(ip) (*(u_int16_t *)&((ip)->ip_off))
+#define IP_LEN(ip) (*(u_int16_t *)&((ip)->ip_len))
+
#define IP_MAXPACKET 65535 /* maximum packet size */
/*
diff -burN qemu-snapshot-2006-03-27_23.orig/slirp/ip_input.c qemu-snapshot-2006-03-27_23/slirp/ip_input.c
--- qemu-snapshot-2006-03-27_23.orig/slirp/ip_input.c 2004-04-21 17:10:47.0 -0700
+++ qemu-snapshot-2006-03-27_23/slirp/ip_input.c 2006-04-06 00:32:19.0 -0700
@@ -111,7 +111,7 @@
* Convert fields to host representation.
*/
NTOHS(ip->ip_len);
- if (ip->ip_len < hlen) {
+ if (IP_LEN(ip) < hlen) {
ipstat.ips_badlen++;
goto bad;
}
@@ -124,13 +124,13 @@
* Trim mbufs if longer than we expect.
* Drop packet if shorter than we expect.
*/
- if (m->m_len < ip->ip_len) {
+ if (m->m_len < IP_LEN(ip)) {
ipstat.ips_tooshort++;
goto bad;
}
/* Should drop packet if mbuf too long? hmmm... */
- if (m->m_len > ip->ip_len)
- m_adj(m, ip->ip_len - m->m_len);
+ if (m->m_len > IP_LEN(ip))
+ m_adj(m, IP_LEN(ip) - m->m_len);
/* check ip_ttl for a correct ICMP reply */
if(ip->ip_ttl==0 || ip->ip_ttl==1) {
@@ -191,7 +191,7 @@
* or if this is not the first fragment,
* attempt reassembly; if it succeeds, proceed.
*/
- if (((struct ipasfrag *)ip)->ipf_mff & 1 || ip->ip_off) {
+ if (((struct ipasfrag *)ip)->ipf_mff & 1 || IP_OFF(ip)) {
ipstat.ips_fragments++;
ip = ip_reass((struct ipasfrag *)ip, fp);
if (ip == 0)
@@ -281,7 +281,7 @@
*/
for (q = (struct ipasfrag *)fp->ipq_next; q != (struct ipasfrag *)fp;
q = (struct ipasfrag *)q->ipf_next)
- if (q->ip_off > ip->ip_off)
+ if (IP_OFF(q) > IP_OFF(ip))
break;
/*
@@ -290,10 +290,10 @@
* segment. If it provides all of our data, drop us.
*/
if (q->ipf_prev != (ipasfragp_32)fp) {
- i = ((struct ipasfrag *)(q->ipf_prev))->ip_off +
- ((struct ipasfrag *)(q->ipf_prev))->ip_len - ip->ip_off;
+ i = IP_OFF((struct ipasfrag *)(q->ipf_prev)) +
+ IP_LEN((struct ipasfrag *)(q->ipf_prev)) - IP_OFF(ip);
if (i > 0) {
- if (i >= ip->ip_len)
+ if (i >= IP_LEN(ip))
goto dropfrag;
m_adj(dtom(ip), i);
ip->ip_off += i;
@@ -305,9 +305,9 @@
* While we overlap succeeding segments trim them or,
* if they are completely covered, dequeue them.
*/
- while (q != (struct ipasfrag *)fp && ip->ip_off + ip->ip_len > q->ip_off) {
- i = (ip->ip_off + ip->ip_len) - q->ip_off;
- if (i < q->ip_len) {
+ while (q != (struct ipasfrag *)fp && IP_OFF(ip) + IP_LEN(ip) > IP_OFF(q)) {
+ i = (IP_OFF(ip) + IP_LEN(ip)) - IP_OFF(q);
+ if (i < IP_LEN(q)) {
q->ip_len -= i;
q->ip_off += i;
m_adj(dtom(q), i);
@@ -327,9 +327,9 @@
next = 0;
for (q = (struct ipasfrag *) fp->ipq_next; q != (struct ipasfrag *)fp;
q = (struct ipasfrag *) q->ipf_next) {
- if (q->ip_off != next)
+ if (IP_OFF(q) != next)
return (0);
- next += q->ip_len;
+ next += IP_LEN(q);
}
if (((struct ipasfrag *)(q->ipf_prev))->ipf_mff & 1)
return (0);
diff -burN qemu-snapshot-2006-03-27_23.orig/slirp/udp.c qemu-snapshot-2006-03-27_23/slirp/udp.c
--- qemu-snapshot-2006-03-27_23.orig/slirp/udp.c 2006-04-06 00:24:30.0 -0700
+++ qemu-snapshot-2006-03-27_23/slirp/udp.c 2006-04-06 00:32:55.0 -0700
@@ -111,12 +111,12 @@
*/
len = ntohs((u_int16_t)uh->uh_ulen);
- if (ip->ip_len != len) {
- if (len > ip->ip_len) {
+ if (IP_LEN(ip) != len) {
+ if (len > IP_LEN(ip)) {
udpstat.udps_badlen++;
goto bad;
}
- m_adj(m, len - ip->ip_len);
+ m_adj(m, len - IP_LEN(ip));
ip->ip_len = len;
}
_
[Qemu-devel] [PATCH] Improve -net user (slirp) performance by 4x
Three bugs in the slirp code have an enormous adverse effect on
networking performance.
1. The maximum TCP segment size for data flowing from the VM to the
host is unnecessarily limited to 512 bytes. 1460 bytes is the
appropriate value for Ethernet.
2. TCP acknowledgements are being delayed unnecessarily, in violation
of the TCP Congestion Control RFC (2581). There is no reason to delay
TCP acknowledgements (and certainly no reason to give special
treatment to packets consisting of a single ESC character, as the code
does now!).
3. qemu sleeps soundly while packets back up in slirp's buffers. slirp
socket fds should be added to the main qemu select() loop to avoid
unnecessary delays.
As Ken Duda mentioned in an earlier thread, measurements with a simple
Python script indicate that the attached patch accelerates TCP
throughput from about 2 megabytes/sec to 9 megabytes/sec, in both
directions.
I'm sure many folks would benefit from this improvement; please let me
know if there is anything I can do to help nudge it into CVS.
--Ed
diff -BurN qemu-snapshot-2006-03-27_23.orig/slirp/tcp.h qemu-snapshot-2006-03-27_23/slirp/tcp.h
--- qemu-snapshot-2006-03-27_23.orig/slirp/tcp.h 2004-04-21 17:10:47.0 -0700
+++ qemu-snapshot-2006-03-27_23/slirp/tcp.h 2006-04-11 15:22:05.0 -0700
@@ -100,8 +100,10 @@
* With an IP MSS of 576, this is 536,
* but 512 is probably more convenient.
* This should be defined as MIN(512, IP_MSS - sizeof (struct tcpiphdr)).
+ *
+ * We make this 1460 because we only care about Ethernet in the qemu context.
*/
-#define TCP_MSS 512
+#define TCP_MSS 1460
#define TCP_MAXWIN 65535 /* largest value for (unscaled) window */
diff -BurN qemu-snapshot-2006-03-27_23.orig/slirp/tcp_input.c qemu-snapshot-2006-03-27_23/slirp/tcp_input.c
--- qemu-snapshot-2006-03-27_23.orig/slirp/tcp_input.c 2004-10-07 16:27:35.0 -0700
+++ qemu-snapshot-2006-03-27_23/slirp/tcp_input.c 2006-04-11 15:22:05.0 -0700
@@ -580,28 +580,11 @@
* congestion avoidance sender won't send more until
* he gets an ACK.
*
- * Here are 3 interpretations of what should happen.
- * The best (for me) is to delay-ack everything except
- * if it's a one-byte packet containing an ESC
- * (this means it's an arrow key (or similar) sent using
- * Nagel, hence there will be no echo)
- * The first of these is the original, the second is the
- * middle ground between the other 2
+ * It is better to not delay acks at all to maximize
+ * TCP throughput. See RFC 2581.
*/
-/* if (((unsigned)ti->ti_len < tp->t_maxseg)) {
- */
-/* if (((unsigned)ti->ti_len < tp->t_maxseg &&
- * (so->so_iptos & IPTOS_LOWDELAY) == 0) ||
- * ((so->so_iptos & IPTOS_LOWDELAY) &&
- * ((struct tcpiphdr_2 *)ti)->first_char == (char)27)) {
- */
- if ((unsigned)ti->ti_len == 1 &&
- ((struct tcpiphdr_2 *)ti)->first_char == (char)27) {
-tp->t_flags |= TF_ACKNOW;
-tcp_output(tp);
- } else {
-tp->t_flags |= TF_DELACK;
- }
+ tp->t_flags |= TF_ACKNOW;
+ tcp_output(tp);
return;
}
} /* header prediction */
diff -BurN qemu-snapshot-2006-03-27_23.orig/vl.c qemu-snapshot-2006-03-27_23/vl.c
--- qemu-snapshot-2006-03-27_23.orig/vl.c 2006-04-11 15:21:27.0 -0700
+++ qemu-snapshot-2006-03-27_23/vl.c 2006-04-11 15:22:05.0 -0700
@@ -4026,7 +4026,7 @@
void main_loop_wait(int timeout)
{
IOHandlerRecord *ioh, *ioh_next;
-fd_set rfds, wfds;
+fd_set rfds, wfds, xfds;
int ret, nfds;
struct timeval tv;
@@ -4041,6 +4041,7 @@
nfds = -1;
FD_ZERO(&rfds);
FD_ZERO(&wfds);
+FD_ZERO(&xfds);
for(ioh = first_io_handler; ioh != NULL; ioh = ioh->next) {
if (ioh->fd_read &&
(!ioh->fd_read_poll ||
@@ -4062,7 +4063,12 @@
#else
tv.tv_usec = timeout * 1000;
#endif
-ret = select(nfds + 1, &rfds, &wfds, NULL, &tv);
+#if defined(CONFIG_SLIRP)
+if (slirp_inited) {
+slirp_select_fill(&nfds, &rfds, &wfds, &xfds);
+}
+#endif
+ret = select(nfds + 1, &rfds, &wfds, &xfds, &tv);
if (ret > 0) {
/* XXX: better handling of removal */
for(ioh = first_io_handler; ioh != NULL; ioh = ioh_next) {
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Fix -nographic heap corruption
A bug in console.c causes heap corruption when qemu is started without
a graphical console (-nographic). In this case, the console height and
width are both 0, resulting in allocation of a zero-length cells
array.
Heap corruption is caused by code that assumes the cells array always
has at least one element. The attached patch avoids this problem
simply by making the cells array one byte larger than necessary, i.e.
length 1 in the -nographic case.
--Ed
diff -burN qemu-snapshot-2006-03-27_23.orig/console.c qemu-snapshot-2006-03-27_23/console.c
--- qemu-snapshot-2006-03-27_23.orig/console.c 2006-03-11 07:35:30.0 -0800
+++ qemu-snapshot-2006-03-27_23/console.c 2006-04-06 00:25:41.0 -0700
@@ -407,7 +407,8 @@
if (s->width < w1)
w1 = s->width;
-cells = qemu_malloc(s->width * s->total_height * sizeof(TextCell));
+cells = qemu_malloc((s->width * s->total_height + 1) * sizeof(TextCell));
+/* Add one extra in case s->width is 0, so we can still store one character. */
for(y = 0; y < s->total_height; y++) {
c = &cells[y * s->width];
if (w1 > 0) {
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Allow -kernel without -hda
The qemu -kernel option currently requires specifying a hard disk
image with -hda. Ostensibly at least one hard disk is needed for
qemu's boot loader to populate the partition table in its array of
boot sectors.
Passing -hda /dev/zero tricks qemu into booting, which demonstrates
that the requirement is unnecessary. Booting with no disk image is
needed to support diskless configurations where a remote NFS directory
is used as the root filesystem. In this scenario, the user invokes
qemu with -kernel and -initrd options, with a specially configured
initrd that NFS-mounts a filesystem on / before passing control to the
real init.
The attached patch permits using the -kernel option with no disk
images, and skips copying the partition table in this case.
--Ed
diff -BurN qemu-snapshot-2006-03-27_23.orig/hw/pc.c qemu-snapshot-2006-03-27_23/hw/pc.c
--- qemu-snapshot-2006-03-27_23.orig/hw/pc.c 2006-04-05 13:05:17.0 +
+++ qemu-snapshot-2006-03-27_23/hw/pc.c 2006-04-05 13:12:40.0 +
@@ -707,10 +707,6 @@
uint8_t bootsect[512];
uint8_t old_bootsect[512];
-if (bs_table[0] == NULL) {
-fprintf(stderr, "A disk image must be given for 'hda' when booting a Linux kernel\n");
-exit(1);
-}
snprintf(buf, sizeof(buf), "%s/%s", bios_dir, LINUX_BOOT_FILENAME);
ret = load_image(buf, bootsect);
if (ret != sizeof(bootsect)) {
@@ -719,12 +715,14 @@
exit(1);
}
-if (bdrv_read(bs_table[0], 0, old_bootsect, 1) >= 0) {
-/* copy the MSDOS partition table */
-memcpy(bootsect + 0x1be, old_bootsect + 0x1be, 0x40);
-}
+if (bs_table[0]) {
+if (bdrv_read(bs_table[0], 0, old_bootsect, 1) >= 0) {
+/* copy the MSDOS partition table */
+memcpy(bootsect + 0x1be, old_bootsect + 0x1be, 0x40);
+}
-bdrv_set_boot_sector(bs_table[0], bootsect, sizeof(bootsect));
+bdrv_set_boot_sector(bs_table[0], bootsect, sizeof(bootsect));
+}
/* now we can load the kernel */
ret = load_kernel(kernel_filename,
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Increase maximum kernel size allowed by -kernel and -initrd
qemu fails to boot recent releases of Fedora Core with the -kernel/-initrd options, since the kernel is large enough to overrun the space allocated to it by qemu's built-in bootloader. The attached patch simply moves the base address of the initrd to a higher location, which allows sufficient space for a larger kernel. Ideally qemu would figure out where to load the initrd based on the size of the kernel, but I hope this patch is simple enough to solve the problem for now. --Ed diff -burN qemu-0.7.2.orig/hw/pc.c qemu-0.7.2/hw/pc.c --- qemu-0.7.2.orig/hw/pc.c 2005-09-04 17:11:31.0 + +++ qemu-0.7.2/hw/pc.c 2005-11-22 20:39:29.0 + @@ -32,7 +32,7 @@ #define LINUX_BOOT_FILENAME "linux_boot.bin" #define KERNEL_LOAD_ADDR 0x0010 -#define INITRD_LOAD_ADDR 0x0040 +#define INITRD_LOAD_ADDR 0x0060 #define KERNEL_PARAMS_ADDR 0x0009 #define KERNEL_CMDLINE_ADDR 0x00099000 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Fix qemu hang when i386 Linux host resumes from suspend
qemu hangs when an i386 Linux host resumes from suspend (swsusp2),
because the host's TSC is reset to a value lower than it was before
the suspend.
Although this is a bug in the host OS, the attached patch (originally
from John Coiner) is simple and makes qemu more resilient to weird
host tick counter behavior.
--Ed
diff -BurN qemu-snapshot-2006-03-27_23.orig/vl.c qemu-snapshot-2006-03-27_23/vl.c
--- qemu-snapshot-2006-03-27_23.orig/vl.c 2006-04-01 18:38:27.0 +
+++ qemu-snapshot-2006-03-27_23/vl.c 2006-04-01 18:41:36.0 +
@@ -579,14 +579,21 @@
#error unsupported CPU
#endif
-static int64_t cpu_ticks_offset;
-static int cpu_ticks_enabled;
+static int64_t cpu_ticks_prev;
+static int64_t cpu_ticks_offset;
+static int cpu_ticks_enabled;
static inline int64_t cpu_get_ticks(void)
{
if (!cpu_ticks_enabled) {
return cpu_ticks_offset;
} else {
+int64_t ticks;
+ticks = cpu_get_real_ticks();
+if (cpu_ticks_prev > ticks) {
+cpu_ticks_offset += cpu_ticks_prev - ticks;
+}
+cpu_ticks_prev = ticks;
-return cpu_get_real_ticks() + cpu_ticks_offset;
+return ticks + cpu_ticks_offset;
}
}
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Work around VNC clients that do not transmit shifts for uppercase characters
The spec isn't really clear about what a client should do. This patch
is needed for RealVNC clients (at least).
Regards,
Anthony Liguori
# HG changeset patch
# User Anthony Liguori <[EMAIL PROTECTED]>
# Node ID 8a71740fc36fcaf97e126e581847983cb2a4324d
# Parent a9314fc39a5e3d78d80d385f560c922c3ce0e82b
Fix for VNC clients that do not send Shift's for uppercase characters
diff -r a9314fc39a5e -r 8a71740fc36f vnc.c
--- a/vnc.c Sun Apr 30 19:04:17 2006 -0500
+++ b/vnc.c Sun Apr 30 23:12:48 2006 -0500
@@ -591,11 +591,11 @@ static void pointer_event(VncState *vs,
}
}
-static void key_event(VncState *vs, int down, uint32_t sym)
+static void key_event_post(kbd_layout_t *kbd_layout, int down, uint32_t sym)
{
int keycode;
-keycode = keysym2scancode(vs->kbd_layout, sym & 0x);
+keycode = keysym2scancode(kbd_layout, sym & 0x);
if (keycode & 0x80)
kbd_put_keycode(0xe0);
@@ -603,6 +603,22 @@ static void key_event(VncState *vs, int
kbd_put_keycode(keycode & 0x7f);
else
kbd_put_keycode(keycode | 0x80);
+}
+
+static void key_event(VncState *vs, int down, uint32_t sym)
+{
+
+if (sym >= 'A' && sym <= 'Z') {
+ sym = (sym - 'A') + 'a';
+ if (down) {
+ key_event_post(vs->kbd_layout, 1, 0xffe1);
+ key_event_post(vs->kbd_layout, 1, sym);
+ key_event_post(vs->kbd_layout, 0, 0xffe1);
+ return;
+ }
+}
+
+key_event_post(vs->kbd_layout, down, sym);
}
static void framebuffer_update_request(VncState *vs, int incremental,
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] VNC display support for QEMU
On Sun, Apr 30, 2006 at 03:03:55AM +0200, Johannes Schindelin wrote: > Hi, > > On Sat, 29 Apr 2006, Anthony Liguori wrote: > > > One thing you may notice is that RealVNC has some issues with being > > disconnected. This is because it likes to switch from 8bit to 32bit depths > > automatically at startup. Unfortunately, there is a race condition in the > > VNC > > protocol and since this implementation is asynchronous, we seem to be much > > more prone to exposing this. > > This, along with other problems, has been solved with LibVNCServer. But of > course, you are welcome to solve them again. I have noticed that interactive performance with the current libvncserver based patches is quite bad compared to doing the same thing on SDL. Maybe re-implementing vnc will uncover why it is slow. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] VNC display support for QEMU
> Where 1 is the first display (port 5901). This syntax may change in the > near future to support binding to a particular interface. It's very > useful to use an absolute mouse with VNC as the relative support is > quite poor. It may be useful to adapt the libvncserver patch's > calibration code here but I've not attempted to do that yet. > > This patch is still experimental. I've tested it with RealVNC and > TightVNC under a variety of depths but I won't be suprised if there are > still problems. I only implement Raw, CopyRect, and Hextile encodings > too. Any sort of palette color mode or pixel format that QEMU doesn't > support will not work either. > > One thing you may notice is that RealVNC has some issues with being > disconnected. This is because it likes to switch from 8bit to 32bit > depths automatically at startup. Unfortunately, there is a race > condition in the VNC protocol and since this implementation is > asynchronous, we seem to be much more prone to exposing this. > > A short near-term TODO list is: > > 1) More testing > 2) Support switching between monitor/serial > 3) Support a better encoding (like TightEncoding or ZRLE) > 4) Support a vnc password (and perhaps stuff like TLS) > > Any feedback is greatly appreciated (especially with how it works with > clients I've not tested). realvnc on debian-ppc (xvncviewer-3.3.7) has endian issues (the colors are wrong). However, mouse tracking and dragging windows actually *works*. (This is with the version currently in cvs) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] VNC display support for QEMU
Anthony Liguori wrote: Hi, The attach patch adds VNC display support for QEMU. It does not use libvncserver but was rather written from scratch. libvncserver is a really neat project and I've used it in a number of other projects but I think QEMU really requires a custom implementation. Nice job.. Improves VNC interactivity nicely.. I use xtightvncviewer with the -bgr option to cut down network bandwidth quite a bit. This generates funky colours with the current patch but works with the old implementation. I'll take a look when I get the chance.. Also I can't access the monitor (which I can with the other vnc patch) ... again, when I get a chance. I need to look at the protocol and see if there is a way to instruct the client to change its size on the fly also.. at the moment booting win2k I have three different client sizes and need to close/reopen the client for each change. Nice work. The optimisations to the qemu portion speed up the display refreshes significantly. 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] [PATCH] VNC display support for QEMU
Brad Campbell wrote: Also I can't access the monitor (which I can with the other vnc patch) ... again, when I get a chance. Oh how I wish I'd read the todo carefully.. -- "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
