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] [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);
return portnum;
} else {
[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.114tr2=1.115r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/Makefile.target.diff?tr1=1.105tr2=1.106r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/keymaps.c.diff?tr1=1.1tr2=1.2r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/qemu-doc.texi.diff?tr1=1.85tr2=1.86r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.c.diff?tr1=1.176tr2=1.177r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.h.diff?tr1=1.115tr2=1.116r1=textr2=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.20tr2=1.21r1=textr2=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.12tr2=1.13r1=textr2=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.177tr2=1.178r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/slirp/libslirp.h.diff?tr1=1.6tr2=1.7r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/slirp/slirp.c.diff?tr1=1.11tr2=1.12r1=textr2=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.2tr2=1.3r1=textr2=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.179tr2=1.180r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vnc.c.diff?tr1=1.1tr2=1.2r1=textr2=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.179tr2=1.180r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vnc.c.diff?tr1=1.1tr2=1.2r1=textr2=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] [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
[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.98tr2=1.99r1=textr2=text ___ 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_sizesize) 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 mailing list
Qemu-devel@nongnu.org
[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
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
