[Qemu-devel] USB Host Asynchronous I/O (Linux)
Hi. The attached patch allows qemu to dispatch usb data packets
asynchronously.
The uhci controller gives poor performance with this patch. It was
said on irc that allowing the uhci controller several pending requests
would improve this. However the ohci controller performs very well
as-is. The tested guests included windows xp and linux 2.6. Both were
noticeably more responsive - cases included transfering files from a
flash drive attached to the host, using an interrupt endpoint based gps
device, and using a usb scanner to scan a few images. There might be a
race condition for scheduling bh's from the signal handler.
--- qemu/usb-linux.c 2006-08-11 20:04:27.0 -0500
+++ qemu/usb-linux.c 2006-11-18 20:40:52.0 -0600
@@ -29,6 +29,8 @@
#include
#include
#include
+#include
+#include
/* We redefine it to avoid version problems */
struct usb_ctrltransfer {
@@ -53,11 +55,225 @@
#define USBDEVFS_PATH "/proc/bus/usb"
#define PRODUCT_NAME_SZ 32
+// endpoint association data
+struct endp_data {
+uint8_t type;
+};
+
typedef struct USBHostDevice {
USBDevice dev;
int fd;
+
+/* for async completion - the
+ * current controller model
+ * issues one packet per
+ * controller.
+ */
+struct usbdevfs_urb urb;
+USBPacket *packet;
+QEMUBH *bh;
+int status;
+
+struct endp_data endp_table[16];
} USBHostDevice;
+// returns 1 on problem encountered or 0 for success
+static int usb_linux_update_endp_table(USBHostDevice *s)
+{
+uint8_t descriptors[1024];
+uint8_t buf[3];
+uint8_t devep, type;
+struct usb_ctrltransfer ct;
+int configuration, interface, alt_interface;
+int length, i, ret;
+
+ct.bRequestType = USB_DIR_IN;
+ct.bRequest = USB_REQ_GET_CONFIGURATION;
+ct.wValue = 0;
+ct.wIndex = 0;
+ct.wLength = 1;
+ct.data = buf;
+ct.timeout = 50;
+
+ret = ioctl(s->fd, USBDEVFS_CONTROL, &ct);
+if (ret < 0) {
+perror("usb_linux_update_endp_table");
+return 1;
+}
+configuration = buf[0];
+
+// in address state
+if (configuration == 0)
+return 1;
+
+/* get the desired configuration, interface, and endpoint
+ * descriptors in one shot - could also re-read all data from
+ * open file descriptor, go through sysfs entries, etc.
+ */
+ct.bRequestType = USB_DIR_IN;
+ct.bRequest = USB_REQ_GET_DESCRIPTOR;
+ct.wValue = (USB_DT_CONFIG << 8) | (configuration - 1);
+ct.wIndex = 0;
+ct.wLength = 1024;
+ct.data = descriptors;
+ct.timeout = 50;
+
+ret = ioctl(s->fd, USBDEVFS_CONTROL, &ct);
+if (ret < 0) {
+perror("usb_linux_update_endp_table");
+return 1;
+}
+
+length = ret;
+i = 0;
+
+if (descriptors[i + 1] != USB_DT_CONFIG ||
+descriptors[i + 5] != configuration) {
+printf("invalid descriptor data - configuration\n");
+return 1;
+}
+i += descriptors[i];
+
+while (i < length) {
+if (descriptors[i + 1] != USB_DT_INTERFACE ||
+(descriptors[i + 1] == USB_DT_INTERFACE &&
+ descriptors[i + 4] == 0)) {
+i += descriptors[i];
+continue;
+}
+
+interface = descriptors[i + 2];
+ct.bRequestType = USB_DIR_IN | USB_RECIP_INTERFACE;
+ct.bRequest = USB_REQ_GET_INTERFACE;
+ct.wValue = 0;
+ct.wIndex = interface;
+ct.wLength = 1;
+ct.data = buf;
+ct.timeout = 50;
+
+ret = ioctl(s->fd, USBDEVFS_CONTROL, &ct);
+if (ret < 0) {
+perror("usb_linux_update_endp_table");
+return 1;
+}
+alt_interface = buf[0];
+
+// the current interface descriptor is the active interface
+// and has endpoints
+if (descriptors[i + 3] != alt_interface)
+continue;
+
+// advance to the endpoints
+while (i < length && descriptors[i +1] != USB_DT_ENDPOINT)
+i += descriptors[i];
+
+if (i >= length)
+break;
+
+while (i < length) {
+if (descriptors[i + 1] != USB_DT_ENDPOINT)
+break;
+
+devep = descriptors[i + 2];
+switch (descriptors[i + 3] & 0x3) {
+case 0x00:
+type = USBDEVFS_URB_TYPE_CONTROL;
+break;
+case 0x01:
+type = USBDEVFS_URB_TYPE_ISO;
+break;
+case 0x02:
+type = USBDEVFS_URB_TYPE_BULK;
+break;
+case 0x03:
+type = USBDEVFS_URB_TYPE_INTERRUPT;
+break;
+default:
+printf("usb_host: malformed endpoint type\n");
+type = USBDEVFS_URB_TYPE_BULK;
+}
+s->endp_table[(devep & 0xf) - 1].type = type;
+
+i += descriptors[i];
+}
+
+i += descriptors[i];
+}
+
+return 0;
+}
+
+static void usb_linux_bh_c
[Qemu-devel] Wake OHCI up on device attach.
This makes linux detect new devices when they're attached with
"usb_add", if anyone cares.
OHCI manual (I checked in PXA27x manual to be exact) says a remote
wake-up should be sent when a device is attached and the host was
suspended. A more general fix (but only UHCI) was posted in
http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00576.html
---
hw/usb-ohci.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/hw/usb-ohci.c b/hw/usb-ohci.c
index de113e9..9e4289a 100644
--- a/hw/usb-ohci.c
+++ b/hw/usb-ohci.c
@@ -295,6 +295,11 @@ static void ohci_attach(USBPort *port1,
else
port->ctrl &= ~OHCI_PORT_LSDA;
port->port.dev = dev;
+
+/* notify of remote-wakeup */
+if ((s->ctl & OHCI_CTL_HCFS) == OHCI_USB_SUSPEND)
+ohci_set_interrupt(s, OHCI_INTR_RD);
+
/* send the attach message */
usb_send_msg(dev, USB_MSG_ATTACH);
dprintf("usb-ohci: Attached port %d\n", port1->index);
--
1.4.3.2
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] FreeBSD compile fix.
I needed the following change to build under FreeBSD 6.0. --- Makefile|8 +--- Makefile.target |3 ++- configure |7 +++ 3 files changed, 10 insertions(+), 8 deletions(-) diff --git a/Makefile b/Makefile index f0a8199..568bd5b 100644 --- a/Makefile +++ b/Makefile @@ -25,13 +25,7 @@ else DOCS= endif -ifndef CONFIG_DARWIN -ifndef CONFIG_WIN32 -ifndef CONFIG_SOLARIS -LIBS+=-lrt -endif -endif -endif +LIBS+=$(AIOLIBS) all: $(TOOLS) $(DOCS) recurse-all diff --git a/Makefile.target b/Makefile.target index 63dba83..9c4272a 100644 --- a/Makefile.target +++ b/Makefile.target @@ -406,6 +406,7 @@ VL_OBJS+=$(addprefix slirp/, $(SLIRP_OBJ endif VL_LDFLAGS= +VL_LIBS=$(AIOLIBS) # specific flags are needed for non soft mmu emulator ifdef CONFIG_STATIC VL_LDFLAGS+=-static @@ -416,7 +417,7 @@ endif ifndef CONFIG_DARWIN ifndef CONFIG_WIN32 ifndef CONFIG_SOLARIS -VL_LIBS=-lutil -lrt +VL_LIBS+=-lutil endif endif endif diff --git a/configure b/configure index 84f8ee0..f0f9fdb 100755 --- a/configure +++ b/configure @@ -150,6 +150,12 @@ if [ "$solaris" = "yes" ] ; then solarisrev=`uname -r | cut -f2 -d.` fi +if [ "$bsd" = "yes" -o "$solaris" = "yes" -o "$mingw32" = "yes" ] ; then +AIOLIBS= +else +AIOLIBS="-lrt" +fi + # find source path source_path=`dirname "$0"` if [ -z "$source_path" ]; then @@ -588,6 +594,7 @@ echo "STRIP=$strip -s -R .comment -R .no echo "CFLAGS=$CFLAGS" >> $config_mak echo "LDFLAGS=$LDFLAGS" >> $config_mak echo "EXESUF=$EXESUF" >> $config_mak +echo "AIOLIBS=$AIOLIBS" >> $config_mak if test "$cpu" = "i386" ; then echo "ARCH=i386" >> $config_mak echo "#define HOST_I386 1" >> $config_h -- 1.4.3.2 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] move date/time initialization into mc146818rtc.c
The patch below moves the initialisation of the RTC date/time, currently
into hw/pc.c into hw/mc146818rtc.c as this part of the initialization
is not guest specific. This avoid duplication of code in (future)
platforms emulation.
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
Index: mc146818rtc.c
===
RCS file: /sources/qemu/qemu/hw/mc146818rtc.c,v
retrieving revision 1.6
diff -u -d -p -r1.6 mc146818rtc.c
--- mc146818rtc.c 3 Jun 2004 12:51:19 - 1.6
+++ mc146818rtc.c 18 Nov 2006 21:26:38 -
@@ -380,6 +380,29 @@ void rtc_set_date(RTCState *s, const str
rtc_copy_date(s);
}
+/* PC cmos mappings */
+#define REG_IBM_CENTURY_BYTE0x32
+#define REG_IBM_PS2_CENTURY_BYTE0x37
+
+void rtc_set_date_from_host(RTCState *s)
+{
+time_t ti;
+struct tm *tm;
+int val;
+
+/* set the CMOS date */
+time(&ti);
+if (rtc_utc)
+tm = gmtime(&ti);
+else
+tm = localtime(&ti);
+rtc_set_date(s, tm);
+
+val = to_bcd(s, (tm->tm_year / 100) + 19);
+rtc_set_memory(s, REG_IBM_CENTURY_BYTE, val);
+rtc_set_memory(s, REG_IBM_PS2_CENTURY_BYTE, val);
+}
+
static void rtc_save(QEMUFile *f, void *opaque)
{
RTCState *s = opaque;
@@ -444,6 +467,8 @@ RTCState *rtc_init(int base, int irq)
s->cmos_data[RTC_REG_C] = 0x00;
s->cmos_data[RTC_REG_D] = 0x80;
+rtc_set_date_from_host(s);
+
s->periodic_timer = qemu_new_timer(vm_clock,
rtc_periodic_timer, s);
s->second_timer = qemu_new_timer(vm_clock,
Index: pc.c
===
RCS file: /sources/qemu/qemu/hw/pc.c,v
retrieving revision 1.62
diff -u -d -p -r1.62 pc.c
--- pc.c24 Sep 2006 18:48:00 - 1.62
+++ pc.c18 Nov 2006 21:26:38 -
@@ -111,14 +111,6 @@ static void pic_irq_request(void *opaque
/* PC cmos mappings */
#define REG_EQUIPMENT_BYTE 0x14
-#define REG_IBM_CENTURY_BYTE0x32
-#define REG_IBM_PS2_CENTURY_BYTE0x37
-
-
-static inline int to_bcd(RTCState *s, int a)
-{
-return ((a / 10) << 4) | (a % 10);
-}
static int cmos_get_fd_drive_type(int fd0)
{
@@ -171,18 +163,6 @@ static void cmos_init(int ram_size, int
struct tm *tm;
int i;
-/* set the CMOS date */
-time(&ti);
-if (rtc_utc)
-tm = gmtime(&ti);
-else
-tm = localtime(&ti);
-rtc_set_date(s, tm);
-
-val = to_bcd(s, (tm->tm_year / 100) + 19);
-rtc_set_memory(s, REG_IBM_CENTURY_BYTE, val);
-rtc_set_memory(s, REG_IBM_PS2_CENTURY_BYTE, val);
-
/* various important CMOS locations needed by PC/Bochs bios */
/* memory size */
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Experimental initial patch providing accelerated OpenGL for Linux i386 (2nd attempt to post)
Even Rouault wrote: Le Jeudi 16 Novembre 2006 23:41, vous avez écrit : My main remark is that the host/guest communication system must be changed and I can help you to implement it. I would prefer to use a PCI device and to avoid any i386 dependent code. For the PCI device, using the Bochs VGA adapter could be a possible idea. All the parameters and data should be transmitted as if the PCI device was doing DMA. A single I/O port could be used to start executing a list of OpenGL commands. Hi, I would indeed appreciate help, or at least some pointers to start in the direction you propose, as I know hardly anything about hardware programming, such as PCI, memory mapped region, DMA, etc... So my questions may sound very naive. As you stated, the current solution is i386 dependent, but this dependancy is very thin, so I imagined that it should possible to find equivalent of the current int 0x99 trap for other architectures. Apart from portability to other architectures, what would be the other advantages of a solution based on a PCI device ? Better security ? Better performance when KQEMU is enabled ? The PCI device is not necessarily an advantage is terms of performance and it will be more complicated to implement on both the host and the guest. But it is better in terms of security and it avoids adding unnecessary hacks in the CPU core (for example, I consider the use of virtual addresses as a hack). I've looked at vga.c and I've the feeling that with cpu_register_io_memory/cpu_register_physical_memory you can install callback functions that will intercept reads/writes to a range of the physical memory of the target machine. Am I right ? Yes. But I don't see how the replacement libGL can read/write physical memory from a userland process. I suppose it needs some special priviledges to use for example a ioctl, or maybe writing a kernel module. So it would become guest OS dependant. Furthermore, doesn't this solution imply more memcpy that may affect performance ? Currently, if a memory range of a guest process (let's say a texture) is by chance mapped contiguously into guest physical memory, we don't need to do any copy before passing it to the host libGL, though I've not benchmarked if it really improves performance. You have no choice but adding a kernel module to handle the transfers to and from the PCI device. Basically you must write a small XFree DRM like kernel driver. Since the PCI device will only handle physical memory, the kernel driver will convert the virtual addresses to physical addresses and ensure that the corresponding pages are not swapped out by the guest OS. The PCI device must handle lists of physical I/O regions so that no memcpy will be needed to do the transfers (scatter/gather DMA). The performance should be the same as your current implementation. Moreover, your protocol could handle queueing of several OpenGL commands in a FIFO because "int 0x99" or the equivalent PCI write command takes some time to execute, especially when using kqemu where an exception is raised. Another point is that I fear that your current use of glX is not portable and can lead to subtle problems. You should rely on SDL/OpenGL on the host side and leave glX on the guest OS. All in all, what I propose gets very close to adding something like a real 3d VGA device in QEMU and a new 3d driver in X11 ! [My intend before your submission was to emulate a recent Intel 3d card because their protocols are mostly documented now (at least in the X11 source !) and because these recent cards support higher level 3d operations such as hardware 3d transformations. My guess is that converting their DMA commands to OpenGL is easy. As writing an Intel 3d emulation would take time and is likely to be very complicated to tune for closed source guest OSes, I think it is safer to begin by improving your proposal.] Regards, Fabrice. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] -snapshot and tmpsfs
On Sat, 18 Nov 2006, Ottavio Caruso wrote: > Are the writes to tmpfs (in a *nix guest OS) recorded to the > snapshotted image? > > Example: /var/run on tmpfs > OS writes to /var/run. Bigger temp file or not? This isn't a guaranteed certain answer, but IIRC tmpfs uses system RAM and swap as its storage. Therefore a guest writing into its tmpfs space would only touch the host filesystem if it were to use the swapfile. As you say you're using the snapshot mode it would, if the swapfile is touched, go into the snapshot temp file, otherwise it wouldn't. -- Michael "Soruk" McConnell Eridani Star System MailStripper - http://www.MailStripper.eu/ - SMTP spam filter Mail Me Anywhere - http://www.MailMeAnywhere.com/ - Mobile email ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] -snapshot and tmpsfs
Are the writes to tmpfs (in a *nix guest OS) recorded to the snapshotted image? Example: /var/run on tmpfs OS writes to /var/run. Bigger temp file or not? Thank you Ottavio Sponsored Link Compare mortgage rates for today. Get up to 5 free quotes. Www2.nextag.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Experimental initial patch providing accelerated OpenGL for Linux i386 (2nd attempt to post)
Le Jeudi 16 Novembre 2006 23:41, vous avez écrit : > My main remark is that the host/guest communication system must be > changed and I can help you to implement it. I would prefer to use a PCI > device and to avoid any i386 dependent code. For the PCI device, using > the Bochs VGA adapter could be a possible idea. All the parameters and > data should be transmitted as if the PCI device was doing DMA. A single > I/O port could be used to start executing a list of OpenGL commands. Hi, I would indeed appreciate help, or at least some pointers to start in the direction you propose, as I know hardly anything about hardware programming, such as PCI, memory mapped region, DMA, etc... So my questions may sound very naive. As you stated, the current solution is i386 dependent, but this dependancy is very thin, so I imagined that it should possible to find equivalent of the current int 0x99 trap for other architectures. Apart from portability to other architectures, what would be the other advantages of a solution based on a PCI device ? Better security ? Better performance when KQEMU is enabled ? I've looked at vga.c and I've the feeling that with cpu_register_io_memory/cpu_register_physical_memory you can install callback functions that will intercept reads/writes to a range of the physical memory of the target machine. Am I right ? But I don't see how the replacement libGL can read/write physical memory from a userland process. I suppose it needs some special priviledges to use for example a ioctl, or maybe writing a kernel module. So it would become guest OS dependant. Furthermore, doesn't this solution imply more memcpy that may affect performance ? Currently, if a memory range of a guest process (let's say a texture) is by chance mapped contiguously into guest physical memory, we don't need to do any copy before passing it to the host libGL, though I've not benchmarked if it really improves performance. Regards, Even ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
