Re: [Qemu-devel] Where is ehci hiding ?
On 12/21/10 08:16, Olivier Galibert wrote: Hi all, Google sees patches to hw/usb-ehci.c from time to time, in http://www.mail-archive.com/qemu-devel@nongnu.org/msg37741.html for instance. Where is that code hiding, since I just can't find it in the git tree? git://git.kiszka.org/qemu.git ehci Not much has been done in the past 4+ months. David Best, OG.
Re: [Qemu-devel] Where is ehci hiding ?
On 12/21/10 11:39, Olivier Galibert wrote: On Tue, Dec 21, 2010 at 09:18:08AM -0700, David S. Ahern wrote: On 12/21/10 08:16, Olivier Galibert wrote: Hi all, Google sees patches to hw/usb-ehci.c from time to time, in http://www.mail-archive.com/qemu-devel@nongnu.org/msg37741.html for instance. Where is that code hiding, since I just can't find it in the git tree? git://git.kiszka.org/qemu.git ehci Not much has been done in the past 4+ months. Thanks. Any idea what's missing to get it into mainline? Reading what little discussions I could find was unenlightening. OG. This is the summary of open items: http://www.mail-archive.com/qemu-devel@nongnu.org/msg46381.html David
Re: [Qemu-devel] State of EHCI emulation for QEMU
On 12/08/10 01:32, Jan Kiszka wrote: Am 08.12.2010 09:26, Gerd Hoffmann wrote: Hi, It appears that the import of the ehci code to spice has completely lost the development history and code contributions - from the original version by Mark Burkley through the work I've done on it. Would you mind pulling in the patch history instead of just the final code? I've first tried to rebase the ehci branch to latest master exactly to keep the history. Was quite messy with lots of conflicts though, so I gave up. For review upstream merge having the whole history isn't that helpful anyway. Where was the messiness given that most of the changes are to a brand new file? The biggest change after that is to usb-linux to handle large requests. David I'm was regularly merging master into ehci, and that worked quite well. For the development phase, it might be nice to keep the history if possible. But I agree that we need a clean series once upstream submission is in sight. Jan
Re: [Qemu-devel] State of EHCI emulation for QEMU
On 12/09/10 06:05, Gerd Hoffmann wrote: Hi, New features developed for the kernel are done in a separate git trees. When a feature is ready for inclusion into the main kernel tree, a pull request is sent. That workflow maintains a complete change history for the feature. Take performance events for example: you can go into Linus' git tree and see the complete history of changes. There's no reason the same methodology cannot be done for qemu. It is done for qemu, pci and block are maintained that way for example. The key difference is that the patches which are accepted into the subsystem branches and then are pulled go through a full review @ qemu-devel before. Yes, I know I've been following qemu and kvm for 3 years now. And there is no reason the same process cannot be done for usb as a subsystem or ehci as a feature branch. Jan already has that started. I realize this is most likely a moot point given that xhci appears better suited for virtualization than ehci, nonetheless it bugs me that you are not wanting to take the time to maintain the code change and sign-off histories. David cheers, Gerd
Re: [Qemu-devel] State of EHCI emulation for QEMU
On 12/04/10 02:05, Jan Kiszka wrote: Am 04.12.2010 01:18, Gerd Hoffmann wrote: Hi, as you may know, there is an experimental git repository at git://git.kiszka.org/qemu.git ehci Looking into this right now as I'm busy with various usb issues anyway. Current state: http://cgit.freedesktop.org/spice/qemu/log/?h=usb.1 It appears that the import of the ehci code to spice has completely lost the development history and code contributions - from the original version by Mark Burkley through the work I've done on it. Would you mind pulling in the patch history instead of just the final code? I'll respond in --verbose mode for the other questions later this weekend when I get more time. David
Re: [Qemu-devel] Log Console Output to File
On 11/11/10 09:57, Mulyadi Santosa wrote: On Thu, Nov 11, 2010 at 12:50, q...@rkmorris.us wrote: Hi, Is there a way to log / copy the console output (like the Linux boot info, if booting QEMU to Linux) to a file? I think you could consider booting Linux in serial console...then start Qemu with -nographic. From there, everything will be spilled right in your standart output. Then you can use your favourite method to save the output...let's say using script command. I use 'screen' and its logging capability (Ctrl-a H). Launch the VM with '-serial stdio -nographic' and have the guest console directed to ttyS0 (console=ttyS0 kernel arg). David
Re: [Qemu-devel] Log Console Output to File
On 11/11/10 13:37, Russell Morris wrote: Hi, Thanks for the pointer! I tried this, but I get an error message, as follows ... *chardev: opening backent stdio failed* *qemu: could not open serial device 'stdio': Inappropriate ioctl for device.* qemu command line? David Thoughts? Thanks again! On Thu, Nov 11, 2010 11:22 AM, David S. Ahern daah...@cisco.com wrote: On 11/11/10 09:57, Mulyadi Santosa wrote: On Thu, Nov 11, 2010 at 12:50, q...@rkmorris.us mailto:q...@rkmorris.us wrote: Hi, Is there a way to log / copy the console output (like the Linux boot info, if booting QEMU to Linux) to a file? I think you could consider booting Linux in serial console...then start Qemu with -nographic. From there, everything will be spilled right in your standart output. Then you can use your favourite method to save the output...let's say using script command. I use 'screen' and its logging capability (Ctrl-a H). Launch the VM with '-serial stdio -nographic' and have the guest console directed to ttyS0 (console=ttyS0 kernel arg). David
Re: [Qemu-devel] Log Console Output to File
On 11/11/10 14:17, Stefan Weil wrote: Am 11.11.2010 21:37, schrieb Russell Morris: Hi, Thanks for the pointer! I tried this, but I get an error message, as follows ... *chardev: opening backent stdio failed* *qemu: could not open serial device 'stdio': Inappropriate ioctl for device.* Thoughts? Hi, I assume that you tried this (as it was suggested by an earlier mail): qemu -serial stdio -nographic ... This results in an error message for me, too: chardev: opening backend stdio failed qemu: could not open serial device 'stdio': No such file or directory Try this variant (which works for me): qemu -nographic ... It will redirect the serial output (first serial port) of your guest os to standard output, so you can write it to a file with the usual methods, for example this one: qemu -nographic ... | tee log.txt Regards Stefan Weil On one host I am using qemu-kvm from qemu-system-x86-0.13.0-1.fc14.x86_64, and on another /usr/local/qemu-kvm.latest/bin/qemu-kvm where latest was qemu-kvm.git on Oct 11. Both work fine. I like this route (using screen and stdio -- no piping) so that I still have a usable console. Maybe it's a difference between qemu and qemu-kvm. David
Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35?
On 08/03/10 12:43, Avi Kivity wrote: libguestfs does not depend on an x86 architectural feature. qemu-system-x86_64 emulates a PC, and PCs don't have -kernel. We should discourage people from depending on this interface for production use. That is a feature of qemu - and an important one to me as well. Why should it be discouraged? You end up at the same place -- a running kernel and in-ram filesystem; why require going through a bootloader just because the hardware case needs it? David
Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35?
On 08/04/10 11:34, Avi Kivity wrote: And it's awesome for fast prototyping. Of course, once that fast becomes dog slow, it's not useful anymore. For the Nth time, it's only slow with 100MB initrds. 100MB is really not that large for an initrd. Consider the deployment of stateless nodes - something that virtualization allows the rapid deployment of. 1 kernel, 1 initrd with the various binaries to be run. Create nodes as needed by launching a shell command - be it for more capacity, isolation, etc. Why require an iso or disk wrapper for a binary blob that is all to be run out of memory? The -append argument allows boot parameters to be specified at launch. That is a very powerful and simple design option. David
[Qemu-devel] Re: [PATCH] Create USB buses and devices based on USB version.
ping. This patch request was first submitted to the list 3 weeks ago. If
there are no objections, please apply.
On 07/26/10 07:50, David Ahern wrote:
Create USB buses and devices based on USB version. This addresses
addresses a number of FIXME's by assigning USB devices to a specific bus.
t is also groundwork for adding ehci.
Signed-off-by: David Ahern daah...@cisco.com
---
hw/usb-bus.c| 70
---
hw/usb-msd.c|2 +-
hw/usb-net.c|2 +-
hw/usb-ohci.c |2 +-
hw/usb-serial.c |4 +-
hw/usb-uhci.c |2 +-
hw/usb.h|7 +++--
usb-bsd.c |2 +-
usb-linux.c |2 +-
9 files changed, 63 insertions(+), 30 deletions(-)
diff --git a/hw/usb-bus.c b/hw/usb-bus.c
index b692503..f4849f8 100644
--- a/hw/usb-bus.c
+++ b/hw/usb-bus.c
@@ -4,6 +4,12 @@
#include sysemu.h
#include monitor.h
+enum {
+USB_VERSION_NONE,
+USB_VERSION_1_1,
+};
+
+
static void usb_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent);
static struct BusInfo usb_bus_info = {
@@ -14,27 +20,46 @@ static struct BusInfo usb_bus_info = {
static int next_usb_bus = 0;
static QTAILQ_HEAD(, USBBus) busses = QTAILQ_HEAD_INITIALIZER(busses);
-void usb_bus_new(USBBus *bus, DeviceState *host)
+static void usb_bus_new(USBBus *bus, int version, DeviceState *host)
{
qbus_create_inplace(bus-qbus, usb_bus_info, host, NULL);
bus-busnr = next_usb_bus++;
bus-qbus.allow_hotplug = 1; /* Yes, we can */
+bus-version = version;
QTAILQ_INIT(bus-free);
QTAILQ_INIT(bus-used);
QTAILQ_INSERT_TAIL(busses, bus, next);
}
-USBBus *usb_bus_find(int busnr)
+void usb_bus_new_v1(USBBus *bus, DeviceState *host)
+{
+usb_bus_new(bus, USB_VERSION_1_1, host);
+}
+
+static USBBus *usb_bus_find(int busnr)
+{
+USBBus *bus;
+
+QTAILQ_FOREACH(bus, busses, next) {
+if (bus-busnr == busnr) {
+break;
+}
+}
+
+return bus;
+}
+
+/* device creation should be using this one */
+USBBus *usb_bus_find_version(int version)
{
USBBus *bus;
-if (-1 == busnr)
-return QTAILQ_FIRST(busses);
QTAILQ_FOREACH(bus, busses, next) {
-if (bus-busnr == busnr)
-return bus;
+if (bus-version == version) {
+break;
+}
}
-return NULL;
+return bus;
}
static int usb_qdev_init(DeviceState *qdev, DeviceInfo *base)
@@ -80,20 +105,15 @@ void usb_qdev_register_many(USBDeviceInfo *info)
}
}
-USBDevice *usb_create(USBBus *bus, const char *name)
+static USBDevice *usb_create(USBBus *bus, const char *name)
{
DeviceState *dev;
-#if 1
-/* temporary stopgap until all usb is properly qdev-ified */
if (!bus) {
-bus = usb_bus_find(-1);
-if (!bus)
-return NULL;
-fprintf(stderr, %s: no bus specified, using \%s\ for \%s\\n,
-__FUNCTION__, bus-qbus.name, name);
+fprintf(stderr, %s: no bus specified for \%s\\n,
+__FUNCTION__, name);
+return NULL;
}
-#endif
dev = qdev_create(bus-qbus, name);
return DO_UPCAST(USBDevice, qdev, dev);
@@ -101,7 +121,13 @@ USBDevice *usb_create(USBBus *bus, const char *name)
USBDevice *usb_create_simple(USBBus *bus, const char *name)
{
-USBDevice *dev = usb_create(bus, name);
+USBDevice *dev;
+
+/* if bus not given default to USB 1.1 */
+if (!bus)
+bus = usb_bus_find_version(USB_VERSION_1_1);
+
+dev = usb_create(bus, name);
if (!dev) {
hw_error(Failed to create USB device '%s'\n, name);
}
@@ -109,6 +135,13 @@ USBDevice *usb_create_simple(USBBus *bus, const char
*name)
return dev;
}
+/* create USB device attached to USB 1.1 controller */
+USBDevice *usb_create_v1(const char *name)
+{
+USBBus *bus = usb_bus_find_version(USB_VERSION_1_1);
+return usb_create(bus, name);
+}
+
void usb_register_port(USBBus *bus, USBPort *port, void *opaque, int index,
usb_attachfn attach)
{
@@ -260,7 +293,6 @@ void usb_info(Monitor *mon)
/* handle legacy -usbdevice cmd line option */
USBDevice *usbdevice_create(const char *cmdline)
{
-USBBus *bus = usb_bus_find(-1 /* any */);
DeviceInfo *info;
USBDeviceInfo *usb;
char driver[32];
@@ -302,7 +334,7 @@ USBDevice *usbdevice_create(const char *cmdline)
error_report(usbdevice %s accepts no params, driver);
return NULL;
}
-return usb_create_simple(bus, usb-qdev.name);
+return usb_create_simple(NULL, usb-qdev.name);
}
return usb-usbdevice_init(params);
}
diff --git a/hw/usb-msd.c b/hw/usb-msd.c
index 65e9624..d8b68f7 100644
--- a/hw/usb-msd.c
+++ b/hw/usb-msd.c
@@ -606,7 +606,7 @@ static USBDevice *usb_msd_init(const char
[Qemu-devel] enabling X86_FEATURE_ARCH_PERFMON in guest
How do I get X86_FEATURE_ARCH_PERFMON enabled for a guest? I've tried -cpu host,+perfmon and -cpu host,+arch_perfmon, but both get rejected with an error: CPU feature perfmon not found Host processor: model name : Intel(R) Xeon(R) CPU E5540 @ 2.53GHz stepping: 5 ... flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm ida tpr_shadow vnmi flexpriority ept vpid Guest side: model name : Intel(R) Xeon(R) CPU E5540 @ 2.53GHz stepping: 5 ... flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx lm constant_tsc pni ssse3 cx16 sse4_1 sse4_2 popcnt lahf_lm David
Re: [Qemu-devel] Re: [PATCH] Disable O_DIRECT for physical CDROM/DVD drives
On 07/20/10 10:02, Jes Sorensen wrote: On 07/20/10 17:40, Anthony Liguori wrote: On 07/20/2010 10:17 AM, jes.soren...@redhat.com wrote: From: Jes Sorensenjes.soren...@redhat.com O_DIRECT (cache=none) requires sector alignment, however the physical sector size of CDROM/DVD drives is 2048, as opposed to most disk devices which use 512. QEMU is hard coding 512 all over the place, so allowing O_DIRECT for CDROM/DVD devices does not work. Signed-off-by: Jes Sorensenjes.soren...@redhat.com Wouldn't a better solution be to have a cdrom_read/cdrom_write hook that did the appropriate bouncing? Silently disabling something a user explicitly asked for is not a good option. In the very least, it should error out entirely. I thought about this, but it would require basically fixing up or copying all of the pread/pwrite code to use the right block size. This is really more of a band-aid but it should be pretty safe. Cheers, Jes What about setting the logical and physical block size properties? Is the intent of these to handle varying sizes amongst block devices? David
Re: [Qemu-devel] [PATCH] Error on O_DIRECT for physical CDROM/DVD drives
On 07/20/10 10:09, jes.soren...@redhat.com wrote:
From: Jes Sorensen jes.soren...@redhat.com
O_DIRECT (cache=none) requires sector alignment, however the physical
sector size of CDROM/DVD drives is 2048, as opposed to most disk
devices which use 512. QEMU is hard coding 512 all over the place, so
allowing O_DIRECT for CDROM/DVD devices does not work. Exit with an
error!
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
---
block/raw-posix.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/block/raw-posix.c b/block/raw-posix.c
index 291699f..1b840c4 100644
--- a/block/raw-posix.c
+++ b/block/raw-posix.c
@@ -1139,6 +1139,11 @@ static int cdrom_open(BlockDriverState *bs, const char
*filename, int flags)
BDRVRawState *s = bs-opaque;
s-type = FTYPE_CD;
+if (flags BDRV_O_NOCACHE) {
+fprintf(stderr, O_DIRECT (cache=none) for CDROM/DVD device (%s)
+is unsupported\n, filename);
+exit(1);
+}
If a cdrom is added via the monitor this would abruptly terminate the VM
- which is not good.
David
/* open will not fail even if no CD is inserted, so add O_NONBLOCK */
return raw_open_common(bs, filename, flags, O_NONBLOCK);
[Qemu-devel] Re: KVM call minutes for July 20
On 07/20/10 08:45, Chris Wright wrote: 0.13 - rc RSN (hopefully this week, top priority for anthony) Can Cam's inter-vm shared memory device get committed for 0.13? It's been stagnant on the list for a while now waiting for inclusion (or NAK comments). David
[Qemu-devel] Re: [PATCH] Create USB buses and devices based on USB version.
On 07/14/10 11:56, David Ahern wrote:
Create USB buses and devices based on USB version.
Signed-off-by: David Ahern daah...@cisco.com
ping.
Relative to current code this addresses a number of FIXME's by assigning
USB devices to a specific bus. It is also groundwork for adding ehci.
David
---
hw/usb-bus.c| 70
---
hw/usb-msd.c|2 +-
hw/usb-net.c|2 +-
hw/usb-ohci.c |2 +-
hw/usb-serial.c |4 +-
hw/usb-uhci.c |2 +-
hw/usb.h|7 +++--
usb-bsd.c |2 +-
usb-linux.c |2 +-
9 files changed, 63 insertions(+), 30 deletions(-)
diff --git a/hw/usb-bus.c b/hw/usb-bus.c
index b692503..f4849f8 100644
--- a/hw/usb-bus.c
+++ b/hw/usb-bus.c
@@ -4,6 +4,12 @@
#include sysemu.h
#include monitor.h
+enum {
+USB_VERSION_NONE,
+USB_VERSION_1_1,
+};
+
+
static void usb_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent);
static struct BusInfo usb_bus_info = {
@@ -14,27 +20,46 @@ static struct BusInfo usb_bus_info = {
static int next_usb_bus = 0;
static QTAILQ_HEAD(, USBBus) busses = QTAILQ_HEAD_INITIALIZER(busses);
-void usb_bus_new(USBBus *bus, DeviceState *host)
+static void usb_bus_new(USBBus *bus, int version, DeviceState *host)
{
qbus_create_inplace(bus-qbus, usb_bus_info, host, NULL);
bus-busnr = next_usb_bus++;
bus-qbus.allow_hotplug = 1; /* Yes, we can */
+bus-version = version;
QTAILQ_INIT(bus-free);
QTAILQ_INIT(bus-used);
QTAILQ_INSERT_TAIL(busses, bus, next);
}
-USBBus *usb_bus_find(int busnr)
+void usb_bus_new_v1(USBBus *bus, DeviceState *host)
+{
+usb_bus_new(bus, USB_VERSION_1_1, host);
+}
+
+static USBBus *usb_bus_find(int busnr)
+{
+USBBus *bus;
+
+QTAILQ_FOREACH(bus, busses, next) {
+if (bus-busnr == busnr) {
+break;
+}
+}
+
+return bus;
+}
+
+/* device creation should be using this one */
+USBBus *usb_bus_find_version(int version)
{
USBBus *bus;
-if (-1 == busnr)
-return QTAILQ_FIRST(busses);
QTAILQ_FOREACH(bus, busses, next) {
-if (bus-busnr == busnr)
-return bus;
+if (bus-version == version) {
+break;
+}
}
-return NULL;
+return bus;
}
static int usb_qdev_init(DeviceState *qdev, DeviceInfo *base)
@@ -80,20 +105,15 @@ void usb_qdev_register_many(USBDeviceInfo *info)
}
}
-USBDevice *usb_create(USBBus *bus, const char *name)
+static USBDevice *usb_create(USBBus *bus, const char *name)
{
DeviceState *dev;
-#if 1
-/* temporary stopgap until all usb is properly qdev-ified */
if (!bus) {
-bus = usb_bus_find(-1);
-if (!bus)
-return NULL;
-fprintf(stderr, %s: no bus specified, using \%s\ for \%s\\n,
-__FUNCTION__, bus-qbus.name, name);
+fprintf(stderr, %s: no bus specified for \%s\\n,
+__FUNCTION__, name);
+return NULL;
}
-#endif
dev = qdev_create(bus-qbus, name);
return DO_UPCAST(USBDevice, qdev, dev);
@@ -101,7 +121,13 @@ USBDevice *usb_create(USBBus *bus, const char *name)
USBDevice *usb_create_simple(USBBus *bus, const char *name)
{
-USBDevice *dev = usb_create(bus, name);
+USBDevice *dev;
+
+/* if bus not given default to USB 1.1 */
+if (!bus)
+bus = usb_bus_find_version(USB_VERSION_1_1);
+
+dev = usb_create(bus, name);
if (!dev) {
hw_error(Failed to create USB device '%s'\n, name);
}
@@ -109,6 +135,13 @@ USBDevice *usb_create_simple(USBBus *bus, const char
*name)
return dev;
}
+/* create USB device attached to USB 1.1 controller */
+USBDevice *usb_create_v1(const char *name)
+{
+USBBus *bus = usb_bus_find_version(USB_VERSION_1_1);
+return usb_create(bus, name);
+}
+
void usb_register_port(USBBus *bus, USBPort *port, void *opaque, int index,
usb_attachfn attach)
{
@@ -260,7 +293,6 @@ void usb_info(Monitor *mon)
/* handle legacy -usbdevice cmd line option */
USBDevice *usbdevice_create(const char *cmdline)
{
-USBBus *bus = usb_bus_find(-1 /* any */);
DeviceInfo *info;
USBDeviceInfo *usb;
char driver[32];
@@ -302,7 +334,7 @@ USBDevice *usbdevice_create(const char *cmdline)
error_report(usbdevice %s accepts no params, driver);
return NULL;
}
-return usb_create_simple(bus, usb-qdev.name);
+return usb_create_simple(NULL, usb-qdev.name);
}
return usb-usbdevice_init(params);
}
diff --git a/hw/usb-msd.c b/hw/usb-msd.c
index 65e9624..d8b68f7 100644
--- a/hw/usb-msd.c
+++ b/hw/usb-msd.c
@@ -606,7 +606,7 @@ static USBDevice *usb_msd_init(const char *filename)
}
/* create guest device */
-dev = usb_create(NULL /* FIXME */,
[Qemu-devel] Re: [PATCH] ehci: check controller state when setting list registers
On 07/10/10 00:02, Jan Kiszka wrote:
They improve disk pass-through for me as well. I'm now also able to boot
from some external USB disk. However, applying more heavy load, the disk
stops working at some point and even disconnects after a while.
I saw that as well. On the TO-DO list.
The changes also modified the errors disk emulation give. I can attach
and write to such images now, but reading back seems to return different
data.
One change msd needs is the ep_wMaxPacketSize. Also I cannot get msd to
work with linux guests with either uhci or ehci. Some debugging is
needed. e.g., impacts of the hack comments usb-msd.c (case insensitive
search)?
diff --git a/hw/usb-msd.c b/hw/usb-msd.c
index 09a6a33..87c306e 100644
--- a/hw/usb-msd.c
+++ b/hw/usb-msd.c
@@ -124,7 +124,7 @@ static const uint8_t qemu_msd_config_descriptor[] = {
0x05, /* u8 ep_bDescriptorType; Endpoint */
0x81, /* u8 ep_bEndpointAddress; IN Endpoint 1 */
0x02, /* u8 ep_bmAttributes; Bulk */
- 0x40, 0x00, /* u16 ep_wMaxPacketSize; */
+ 0x00, 0x02, /* u16 ep_wMaxPacketSize; */
0x00, /* u8 ep_bInterval; */
/* Bulk-Out endpoint */
@@ -132,7 +132,7 @@ static const uint8_t qemu_msd_config_descriptor[] = {
0x05, /* u8 ep_bDescriptorType; Endpoint */
0x02, /* u8 ep_bEndpointAddress; OUT Endpoint 2 */
0x02, /* u8 ep_bmAttributes; Bulk */
- 0x40, 0x00, /* u16 ep_wMaxPacketSize; */
+ 0x00, 0x02, /* u16 ep_wMaxPacketSize; */
0x00/* u8 ep_bInterval; */
};
[Qemu-devel] Re: [PATCH] ehci: uhci-ehci co-existence (handling v1.1 and v2 devices)
On 07/08/10 01:49, Jan Kiszka wrote: David Ahern wrote: Per the EHCI specification a USB 2.0 host controller is comprised of one high-speed controller and 0 to N USB 1.1 companion host controllers (UHCI or OHCI) for low- and full-speed devices. Port routing and control logic determines which HC owns a particular port. See Sections 1.2 and 4.2 of the EHCI specification. http://www.intel.com/technology/usb/download/ehci-r10.pdf In essence a USB 2.0 bus has N ports. Those N ports can be controlled by either the companion controller or the ehci controller. The ports default to the companion controller. At boot if the OS has an EHCI host driver it can take control of the ports by default and when a low/full speed device is connected switch the port to a companion controller. After looking into this for the past 6+ weeks, the port routing and control logic gets rather complex to implement in qemu. To keep the implementation simple I propose keeping the UCHI/OHCI and EHCI buses implemented independently -- using the 0 option for the number of companion host controllers. When USB devices are created they are assigned to a specific bus: .---. | device creation | '---' /\ | UHCI controller || EHCI controller | | | | Low/Full speed dev || High speed devices | qemu's emulated devices already know which USB version they are compatible with, so no need to probe for it. Host based devices can default to ehci (or uhci if preferred) and then use the speed information obtained from the scan to determine if the device should be attached to the uhci bus instead. What about the case the guest does not use EHCI (or later on XHCI)? Can we avoid attaching device of higher speed to those buses then? And migrate them over once the guest disables EHCI (XHCI), e.g. by unloading the related module? Otherwise, those devices will be unusable for the guest IIUC. Jan There really is no way of knowing if the guest loads or unloads the kernel module. For example, recent seabios images configure and enable the ehci controller -- and leave it enabled on the hand off to the guest OS. Also, the guest driver enables and disables the periodic and asynchronous lists as needed. Given that I'm not sure there is a way to know 100% that the guest does not support ehci. Then there is the complexity of moving devices between the USB buses as the driver is loaded and unloaded. As an alternative, what about enhancing the -usb option to note the maximum version to enable: e.g., -usb v2[,v3]? -usb alone defaults to uhci/ohci for compatibility with current design. Then ehci can be enabled by the user. Enabling v2 means v1 is also enabled. Similarly when v3 comes along -usb v3 means uhci/ohci, ehci and xhci are all enabled. David
[Qemu-devel] Re: [PATCH] ehci: uhci-ehci co-existence (handling v1.1 and v2 devices)
On 07/08/10 08:42, Jan Kiszka wrote:
David S. Ahern wrote:
On 07/08/10 01:49, Jan Kiszka wrote:
David Ahern wrote:
Per the EHCI specification a USB 2.0 host controller is comprised of one
high-speed controller and 0 to N USB 1.1 companion host controllers (UHCI
or OHCI) for low- and full-speed devices. Port routing and control logic
determines which HC owns a particular port. See Sections 1.2 and 4.2 of
the EHCI specification.
http://www.intel.com/technology/usb/download/ehci-r10.pdf
In essence a USB 2.0 bus has N ports. Those N ports can be controlled by
either the companion controller or the ehci controller. The ports default
to the companion controller. At boot if the OS has an EHCI host driver it
can take control of the ports by default and when a low/full speed device
is connected switch the port to a companion controller. After looking into
this for the past 6+ weeks, the port routing and control logic gets rather
complex to implement in qemu.
To keep the implementation simple I propose keeping the UCHI/OHCI and EHCI
buses implemented independently -- using the 0 option for the number of
companion host controllers.
When USB devices are created they are assigned to a specific bus:
.---.
| device creation |
'---'
/\
| UHCI controller || EHCI controller |
| |
| Low/Full speed dev || High speed devices |
qemu's emulated devices already know which USB version they are compatible
with, so no need to probe for it. Host based devices can default to ehci
(or uhci if preferred) and then use the speed information obtained from
the scan to determine if the device should be attached to the uhci bus
instead.
What about the case the guest does not use EHCI (or later on XHCI)? Can
we avoid attaching device of higher speed to those buses then? And
migrate them over once the guest disables EHCI (XHCI), e.g. by unloading
the related module? Otherwise, those devices will be unusable for the
guest IIUC.
Jan
There really is no way of knowing if the guest loads or unloads the
kernel module. For example, recent seabios images configure and enable
the ehci controller -- and leave it enabled on the hand off to the guest
OS.
We only need to behave like real HW does. If Seabios leaves the
controllers in an improper state, then it's a Seabios bug that can be
fixed independently.
Also, the guest driver enables and disables the periodic and
asynchronous lists as needed. Given that I'm not sure there is a way to
know 100% that the guest does not support ehci.
According to quick glance at the spec, the logic to route a device to
the companion controller is !EHCI-configured || !port.EHCI-owned. So
detection should be a non-issue...
Per Section 2.2.3 if there are no companion controllers then the port
ownership handoff is not supported. The configured flag you mentioned
(Section 2.3.8) is not applicable if port routing is not supported. Port
routing as defined in the EHCI spec is the complexity part that I think
should be avoided.
Then there is the
complexity of moving devices between the USB buses as the driver is
loaded and unloaded.
...but I guess this is the actual problem. What makes moving devices
between buses so complex in QEMU?
From a terminology perspective my reference to moving devices between
buses is separate from the ehci port routing which is way more complex
(a very subtle point).
In my first cut at this I was using the following to switch buses and it
works fine:
+void usb_device_migrate(USBDevice *dev, USBBus *bus)
+{
+BusState *bus_state = bus-qbus;
+
+/* remove from current */
+usb_device_detach(dev);
+
+dev-qdev.parent_bus = bus_state;
+
+/* add to given one */
+if (bus-nfree == 1) {
+usb_create_simple(bus, usb-hub);
+}
+do_attach(dev);
+return;
+}
As an alternative, what about enhancing the -usb option to note the
maximum version to enable: e.g., -usb v2[,v3]? -usb alone defaults to
uhci/ohci for compatibility with current design. Then ehci can be
enabled by the user. Enabling v2 means v1 is also enabled. Similarly
when v3 comes along -usb v3 means uhci/ohci, ehci and xhci are all enabled.
I think we either go for your current proposal as an intermediate
solution and fix the routing later on, or we find a way to do it
correctly on first run.
Moving devices from ehci to uhci and vice versa can be implemented later
if there is agreement that a simplified ehci model (ie, no companion
controllers) is acceptable.
David
Jan
[Qemu-devel] Re: [PATCH v7 RESEND 4/4] Inter-VM shared memory PCI device
On 07/08/10 15:08, Cam Macdonell wrote:
Resent (again): Some lines were over 80 characters and debugging is now off.
Support an inter-vm shared memory device that maps a shared-memory object as a
PCI device in the guest. This patch also supports interrupts between guest by
communicating over a unix domain socket. This patch applies to the qemu-kvm
repository.
-device ivshmem,size=size in format accepted by -m[,shm=shm name]
Interrupts are supported between multiple VMs by using a shared memory server
by using a chardev socket.
-device ivshmem,size=size in format accepted by -m[,shm=shm name]
[,chardev=id][,msi=on][,irqfd=on][,vectors=n][,role=peer|master]
-chardev socket,path=path,id=id
The shared memory server, sample programs and init scripts are in a git repo
here:
www.gitorious.org/nahanni
This is an oft requested feature that Cam's been working on for a while
now. I've tested the plan host-VM shared memory aspect and it works
quite nicely. Can this get committed soon?
David
Signed-off-by: Cam Macdonell c...@cs.ualberta.ca
---
Makefile.target |3 +
hw/ivshmem.c| 842
+++
qemu-char.c |6 +
qemu-char.h |3 +
qemu-doc.texi | 43 +++
5 files changed, 897 insertions(+), 0 deletions(-)
create mode 100644 hw/ivshmem.c
diff --git a/Makefile.target b/Makefile.target
index a0e9747..1e99ec8 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -203,6 +203,9 @@ obj-$(CONFIG_USB_OHCI) += usb-ohci.o
obj-y += rtl8139.o
obj-y += e1000.o
+# Inter-VM PCI shared memory
+obj-y += ivshmem.o
+
# Hardware support
obj-i386-y += vga.o
obj-i386-y += mc146818rtc.o i8259.o pc.o
diff --git a/hw/ivshmem.c b/hw/ivshmem.c
new file mode 100644
index 000..763b9c2
--- /dev/null
+++ b/hw/ivshmem.c
@@ -0,0 +1,842 @@
+/*
+ * Inter-VM Shared Memory PCI device.
+ *
+ * Author:
+ * Cam Macdonell c...@cs.ualberta.ca
+ *
+ * Based On: cirrus_vga.c
+ * Copyright (c) 2004 Fabrice Bellard
+ * Copyright (c) 2004 Makoto Suzuki (suzu)
+ *
+ * and rtl8139.c
+ * Copyright (c) 2006 Igor Kovalenko
+ *
+ * This code is licensed under the GNU GPL v2.
+ */
+#include hw.h
+#include pc.h
+#include pci.h
+#include msix.h
+#include kvm.h
+
+#include sys/mman.h
+#include sys/types.h
+
+#define IVSHMEM_IRQFD 0
+#define IVSHMEM_MSI 1
+
+#define IVSHMEM_PEER0
+#define IVSHMEM_MASTER 1
+
+#define IVSHMEM_REG_BAR_SIZE 0x100
+
+//#define DEBUG_IVSHMEM
+#ifdef DEBUG_IVSHMEM
+#define IVSHMEM_DPRINTF(fmt, ...)\
+do {printf(IVSHMEM: fmt, ## __VA_ARGS__); } while (0)
+#else
+#define IVSHMEM_DPRINTF(fmt, ...)
+#endif
+
+typedef struct Peer {
+int nb_eventfds;
+int *eventfds;
+} Peer;
+
+typedef struct EventfdEntry {
+PCIDevice *pdev;
+int vector;
+} EventfdEntry;
+
+typedef struct IVShmemState {
+PCIDevice dev;
+uint32_t intrmask;
+uint32_t intrstatus;
+uint32_t doorbell;
+
+CharDriverState **eventfd_chr;
+CharDriverState *server_chr;
+int ivshmem_mmio_io_addr;
+
+pcibus_t mmio_addr;
+pcibus_t shm_pci_addr;
+uint64_t ivshmem_offset;
+uint64_t ivshmem_size; /* size of shared memory region */
+int shm_fd; /* shared memory file descriptor */
+
+Peer *peers;
+int nb_peers; /* how many guests we have space for */
+int max_peer; /* maximum numbered peer */
+
+int vm_id;
+uint32_t vectors;
+uint32_t features;
+EventfdEntry *eventfd_table;
+
+char * shmobj;
+char * sizearg;
+char * role;
+int role_val; /* scalar to avoid multiple string comparisons */
+} IVShmemState;
+
+/* registers for the Inter-VM shared memory device */
+enum ivshmem_registers {
+INTRMASK = 0,
+INTRSTATUS = 4,
+IVPOSITION = 8,
+DOORBELL = 12,
+};
+
+static inline uint32_t ivshmem_has_feature(IVShmemState *ivs,
+unsigned int feature) {
+return (ivs-features (1 feature));
+}
+
+static inline bool is_power_of_two(uint64_t x) {
+return (x (x - 1)) == 0;
+}
+
+static void ivshmem_map(PCIDevice *pci_dev, int region_num,
+pcibus_t addr, pcibus_t size, int type)
+{
+IVShmemState *s = DO_UPCAST(IVShmemState, dev, pci_dev);
+
+s-shm_pci_addr = addr;
+
+if (s-ivshmem_offset 0) {
+cpu_register_physical_memory(s-shm_pci_addr, s-ivshmem_size,
+
s-ivshmem_offset);
+}
+
+IVSHMEM_DPRINTF(guest pci addr = % FMT_PCIBUS , guest h/w addr = %
+PRIu64 , size = % FMT_PCIBUS \n, addr, s-ivshmem_offset, size);
+
+}
+
+/* accessing registers - based on rtl8139 */
+static void ivshmem_update_irq(IVShmemState *s, int val)
+{
+int isr;
+isr = (s-intrstatus
Re: [Qemu-devel] Guest OS hangs on usb_add
On 06/23/10 22:45, TJ wrote:
-- Forwarded message --
From: Timothy Jones one.timothy.jo...@gmail.com
Date: Wed, Jun 23, 2010 at 9:07 PM
Subject: Guest OS hangs on usb_add
To: qemu-devel@nongnu.org
With some digging around I found out that the qemu hangs in
usb_host_claim_interfaces, which is caused by screwed up usb
descriptor. The device reports the following:
(gdb) p dev-descr_len
$21 = 50
(gdb) p /x dev-descr...@50
$23 = {0x18, 0x1, 0x0, 0x1, 0xff, 0xff, 0xff, 0x8, 0x47, 0x46, 0x0,
0x30, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1, 0x9, 0x2, 0x20,
0x0, 0x1, 0x1, 0x0, 0x80, 0x19, 0x9, 0x4, 0x0, 0x0, 0x2, 0xff, 0xff,
0xff, 0x0, 0x7, 0x5, 0x81, 0x2, 0x40, 0x0, 0x0,
0x7, 0x5, 0x3, 0x2, 0x10, 0x0, 0x0}
The first 0x18 (Device Descriptor bLength) is supposed to be decimal
18, not hex! According to USB spec, if the device reports size greater
than expected, the host is supposed ignore the extra bytes. So qemu
behaves correctly here. However, with this length, the following
Configuration Descriptor length falls on a 0x0 and so the qemu spins
in an endless loop. (This is prolly something that should be detected
and reported as error by qemu.)
My question is: This 0x18 -- is this something that comes from the
device itself (ie, firmware bug)? Or does it come from the USB
subsystem?
What kind of device is this?
David
Re: [Qemu-devel] [RFC PATCH 0/2] Add USB Video Class device emulation.
On 06/08/10 09:34, Natalia Portillo wrote: Hi, This currently adds an emulated USB webcam compliant with USB Video Class Specification 1.0a. It only works on Linux guests and feeds the emulated device using a Video4Linux 2 host device, as long as it supports 320x240 MJPEG format. This is a Request for Comments as surely code needs some cleaning or style. You can see it working here: http://www.youtube.com/watch?v=fzGYvjZzx6E with Linux guest http://www.youtube.com/watch?v=_Yo9TWPDXCo with Windows XP Home guest To add the device use -device usb-uvc-webcam,device=path to v4l2 device Regards, Natalia Portillo Attempting to try out your patches, but it's failing with the following: usb-uvc: Init called usb-uvc: Trying to open /dev/video0 .usb-uvc: Device opened correctly. usb-uvc: Querying capabilities. usb-uvc: Device driver: uvcvideo usb-uvc: Device name: Laptop_Integrated_Webcam_0.3M usb-uvc: Device bus: usb-:00:1a.7-6 usb-uvc: Driver version: 0.1.0 usb-uvc: Device capabilities: 0x0401 usb-uvc: Enumerating video inputs. usb-uvc: Setting video input to index 0 usb-uvc: Video input correctly set. usb-uvc: Trying to set 320x240 MJPEG. qemu-system-x86_64: -device usb-uvc-webcam,device=/dev/video0: Invalid format. Using ekiga for example I know that 320x240 is ok. I know very little about the v4l (or video in general). Can you provide some pointers? Also, I tried a PWC camera which is not a V4L2_INPUT_TYPE_CAMERA and noticed that video_input_index is used uninitialized in usb_uvc_initfn David
Re: [Qemu-devel] [RFC PATCH 0/2] Add USB Video Class device emulation.
On 06/10/10 12:26, Natalia Portillo wrote: Hi David, Attempting to try out your patches, but it's failing with the following: usb-uvc: Init called usb-uvc: Trying to open /dev/video0 .usb-uvc: Device opened correctly. usb-uvc: Querying capabilities. usb-uvc: Device driver: uvcvideo usb-uvc: Device name: Laptop_Integrated_Webcam_0.3M usb-uvc: Device bus: usb-:00:1a.7-6 usb-uvc: Driver version: 0.1.0 usb-uvc: Device capabilities: 0x0401 usb-uvc: Enumerating video inputs. usb-uvc: Setting video input to index 0 usb-uvc: Video input correctly set. usb-uvc: Trying to set 320x240 MJPEG. qemu-system-x86_64: -device usb-uvc-webcam,device=/dev/video0: Invalid format. As for now only cameras that allow MJPEG format will work. Check your camera specifications (lsusb -v works if your real camera is UVC, check driver's source otherwise). Cameras with RAW frames (YUYV and NV12 formats) do not work, yet. I'm on it. Trying to guess the relevant descriptors: VideoStreaming Interface Descriptor: bLength50 bDescriptorType36 bDescriptorSubtype 5 (FRAME_UNCOMPRESSED) bFrameIndex 3 bmCapabilities 0x00 Still image unsupported wWidth320 wHeight 240 dwMinBitRate 768000 dwMaxBitRate 4608000 dwMaxVideoFrameBufferSize 153600 dwDefaultFrameInterval 33 bFrameIntervalType 6 dwFrameInterval( 0)33 dwFrameInterval( 1)40 dwFrameInterval( 2)50 dwFrameInterval( 3)66 dwFrameInterval( 4) 100 dwFrameInterval( 5) 200 VideoStreaming Interface Descriptor: bLength 6 bDescriptorType36 bDescriptorSubtype 13 (COLORFORMAT) bColorPrimaries 1 (BT.709,sRGB) bTransferCharacteristics1 (BT.709) bMatrixCoefficients 4 (SMPTE 170M (BT.601)) Also, I tried a PWC camera which is not a V4L2_INPUT_TYPE_CAMERA and noticed that video_input_index is used uninitialized in usb_uvc_initfn It's a webcam? Could you give me more information? Manufacturer, model, linux's module name. usb 7-1: new full speed USB device using uhci_hcd and address 3 usb 7-1: New USB device found, idVendor=046d, idProduct=08b6 usb 7-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 pwc: Logitech/Cisco VT Camera webcam detected. David All webcams SHOULD (and MUST) implement V4L2_INPUT_TYPE_CAMERA. Not the same for video cameras or capture devices (PAL/NTSC, DVB/ATSC). Regards, Natalia Portillo
[Qemu-devel] Re: [RFC] Moving the kvm ioapic, pic, and pit back to userspace
On 06/07/10 09:26, Avi Kivity wrote: The original motivation for moving the PIC and IOAPIC into the kernel was performance, especially for assigned devices. Both devices are high interaction since they deal with interrupts; practically after every interrupt there is either a PIC ioport write, or an APIC bus message, both signalling an EOI operation. Moving the PIT into the kernel allowed us to catch up with missed timer interrupt injections, and speeded up guests which read the PIT counters (e.g. tickless guests). However, modern guests running on modern qemu use MSI extensively; both virtio and assigned devices now have MSI support; and the planned VFIO only supports kernel delivery via MSI anyway; line based interrupts will need to be mediated by userspace. The modern guest comment is a bit concerning. 2.4 kernels (e.g., RHEL3) use the PIT for timekeeping and will still be around for a while. RHEL4 and RHEL5 will be around for a long time to come. Not sure how those fit within the modern label, though I see my RHEL4 guest is using the pit as a timesource. David
[Qemu-devel] Re: [RFC] Moving the kvm ioapic, pic, and pit back to userspace
On 06/07/10 12:46, Avi Kivity wrote: On 06/07/2010 07:31 PM, David S. Ahern wrote: On 06/07/10 09:26, Avi Kivity wrote: The original motivation for moving the PIC and IOAPIC into the kernel was performance, especially for assigned devices. Both devices are high interaction since they deal with interrupts; practically after every interrupt there is either a PIC ioport write, or an APIC bus message, both signalling an EOI operation. Moving the PIT into the kernel allowed us to catch up with missed timer interrupt injections, and speeded up guests which read the PIT counters (e.g. tickless guests). However, modern guests running on modern qemu use MSI extensively; both virtio and assigned devices now have MSI support; and the planned VFIO only supports kernel delivery via MSI anyway; line based interrupts will need to be mediated by userspace. The modern guest comment is a bit concerning. 2.4 kernels (e.g., RHEL3) use the PIT for timekeeping and will still be around for a while. RHEL4 and RHEL5 will be around for a long time to come. Not sure how those fit within the modern label, though I see my RHEL4 guest is using the pit as a timesource. First of all, the existing code will remain for a long while (several years). We still have to support existing userspace. But, that's not a satisfactory answer. I don't want users to choose which device model to use according to their guest. As far as I'm concerned all guests are triple-boot with the guest rebooting to a different OS every half hour. So it's important to know how often your RHEL3/4 guest queries the PIT (not just receives interrupts, actually reads the counter) under a realistic load. If you have such a number (in reads/sec) that would be a good input to this discussion. Aps that invoke gettimeofday a lot. As I recall RHEL3 uses the TSC between timer interrupts, but RHEL4 samples counters on each gettimeofday call: http://www.mail-archive.com/k...@vger.kernel.org/msg07231.html Because of that performance of applications that timestamp log entries (like a certain product I work on) takes a hit on KVM unless the TSC is the clock source. David
Re: [Qemu-devel] [Bug 319014] Re: serial usb-device can't be passed-through to a guest
On 06/03/10 09:41, Nico Prenzel wrote: Hello Anthony, which qemu-kvm version do you expect to work with serial usb devices? After you've changed this ticket status and I've checked it again with qemu-kvm version 0.12.4. The reported error message is gone away and the device is present in the guest. The cdc_acm driver loads too without any visible problems, but the device is still unusable. The device data led flash if it gets un/initialized by minicom. But if I try to make a test dial, nothing happens after I call a phone number. To be more precise: -host dosn't have loaded the cdc_acm driver -guest loads the cdc_acm driver -a dial with minicom to the same phone number works on the host, if I load the cdc_acm within the host I would like to get this fixed, as I really want to use this usb-device as my dusty fax again. One option I resorted to is using Qemu's emulated USB serial device and connecting it to the USB serial device host side. The stack then looks like: .-. | VM | | | |/dev/ttyUSB0 | |-| | Qemu - serial device| '-' | .-. | Host: /dev/ttyUSB0 | '-' | .-. | USB serial port|-- character stream -- '-' A hack, but it works. :-) David
Re: [Qemu-devel] RFC: ehci - uhci handoff suggestions
On 05/26/2010 06:48 AM, Gerd Hoffmann wrote: Hi, USB devices can support both 1.1 and 2.0, right? Who decides which protocol is used then? I think the OS can speak 1.1 to the device even in case a ehci controller is present (but unused by the OS), right? AFAIK the OS must tell the EHCI that it should hand the device off to the UHCI/OHCI companion before it can use it there. Huh? Compatibility-wise it makes sense to do it the other way around (i.e. have it @ UHCI/OHCI by default and move to EHCI on request), so a OS which knows nothing about EHCI can cope. If they should be accessed via the EHCI or a companion controller depends on what the OS requests. And USB 2.0 says that any device that supports High Speed must also support Full Speed and therefore be accessible using the companion (at least that's what I understand). Hmm, ok, so no shortcut even for emulated devices. Not that it would have helped much as we have to cover host devices anyway. Also I think one ehci controller can have multiple uhci companion controllers. At least lspci on my T60 suggests that: 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02) cheers, Gerd Yes, that is the ehci feature to be implemented. My understanding is that the port routing happens internally to the host controller based on device speed - section 4.2 (pag 64) of: http://www.intel.com/technology/usb/download/ehci-r10.pdf ehci does have more overhead from an emulation perspective, so it would be best to keep mice, keyboard, serial ports, etc on the uhci/ohci bus and have storage devices and webcams and such on ehci. And any transition should happen automagically within the device model. David
Re: [Qemu-devel] RFC: ehci - uhci handoff suggestions
On 05/26/2010 07:23 AM, Kevin Wolf wrote: Am 26.05.2010 15:06, schrieb David S. Ahern: On 05/26/2010 06:48 AM, Gerd Hoffmann wrote: Hi, USB devices can support both 1.1 and 2.0, right? Who decides which protocol is used then? I think the OS can speak 1.1 to the device even in case a ehci controller is present (but unused by the OS), right? AFAIK the OS must tell the EHCI that it should hand the device off to the UHCI/OHCI companion before it can use it there. Huh? Compatibility-wise it makes sense to do it the other way around (i.e. have it @ UHCI/OHCI by default and move to EHCI on request), so a OS which knows nothing about EHCI can cope. Ah, the page referenced by David explains this, so what I knew is only half of it. There is a Configured Flag that tells if the EHCI is used - and only when the OS has activated the EHCI this way it needs to explicitly hand off per device. If they should be accessed via the EHCI or a companion controller depends on what the OS requests. And USB 2.0 says that any device that supports High Speed must also support Full Speed and therefore be accessible using the companion (at least that's what I understand). Hmm, ok, so no shortcut even for emulated devices. Not that it would have helped much as we have to cover host devices anyway. Also I think one ehci controller can have multiple uhci companion controllers. At least lspci on my T60 suggests that: Yes, I think any number is allowed, and from a specification point of view it's even okay to have no companion controller at all. You just couldn't use Low/Full Speed devices in the ports of that controller then. 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02) cheers, Gerd Yes, that is the ehci feature to be implemented. My understanding is that the port routing happens internally to the host controller based on device speed - section 4.2 (pag 64) of: http://www.intel.com/technology/usb/download/ehci-r10.pdf The routing may happen internally, but the OHCI/UHCI appears just like a normal controller to the OS. You can't access the devices on a companion with your EHCI driver. ehci does have more overhead from an emulation perspective, so it would be best to keep mice, keyboard, serial ports, etc on the uhci/ohci bus and have storage devices and webcams and such on ehci. And any transition should happen automagically within the device model. I think in reality things like keyboards are Low Speed anyway, so they would need to be handed off to a OHCI/UHCI anyway. Any transition between High Speed (directly handled by EHCI) and Low/Full Speed (OHCI/UHCI companion controller) must not happen automagically, but be requested by the guest OS. And you probably don't want to re-implement UHCI or OHCI inside the EHCI emulation, so you can't keep things inside the EHCI device model. Kevin I'm still confused by the guest OS interaction -- more code/spec reading I guess. Key points are that lspci in the VM shows both buses, and the qemu monitor would still scan both buses and show devices. And definitely no code duplication - some kind of movement to current uhci/ohci ports is what I am after. David
[Qemu-devel] RFC: ehci - uhci handoff suggestions
USB 2.0 leverages companion UHCI or OHCI host controllers for full and low speed devices. I do not see an appropriate means for doing that bus transition and could use some suggestions. I've read through the code for the legacy path in handling USB devices (-usbdevice CLI arg and usb_add monitor command), and I am now working on the new path (now that I know about it). As I understand the code at this point it is a top down setup: device added, bus found, device attached. | Qemu USB admin | - adding/removing devices | interface | - showing device list | | USB controller | | | USB device model | - emulated devices (e.g., hw/usb-serial) |(or driver )| - host devices ie., key point is the expectation that the bus to which the device is assigned is known early in the code path. For USB devices the bus to attach it to should be determined automatically when the device is attached. Something along the lines of: | Qemu USB admin | | interface | | | EHCI controller |---|UHCI / OHCI | | | | USB device model || USB device model | |(or driver )||(or driver )| high speed full / low speed To know which bus to attach it to the device needs to be queried/probed for basic information - something the current architecture does not have. Suggestions? David P.S. I skimmed the USB 3.0 spec and it has the same design: super speed devices are attached to the new 3.0 controller, high speed to ehci and low/full to uhci/ohci.
Re: [Qemu-devel] [PATCH v2] Release usb devices on shutdown and usb_del command
On 05/21/2010 1:33 AM, Markus Armbruster wrote: Note: usbdevice_init() is not for general initialization, just for dealing with the legacy -usbdevice command line. Perhaps the comment before usbdevice_create is misleading or has some conversion not completed? Right now even devices entered through the monitor go through usbdevice_create -- which is the only place the usbdevice_init() hook is invoked. David
Re: [Qemu-devel] Problems changing dvdrom iso during execution
On 05/21/2010 10:10 AM, Adnan Khaleel wrote: So do you have any idea whats causing the problem? Is there any other way I can mount a dvd in Qemu? Adnan have you tried ejecting the cd in the guest before changing the file in the monitor? David
Re: [Qemu-devel] Problems changing dvdrom iso during execution
On 05/20/2010 02:29 PM, Adnan Khaleel wrote: I cannot change DVD roms during execution using the monitor. I can only mount a cdrom/dvdrom if I specify the iso file in the command line x86_64-softmmu/qemu-system-x86_64 -hda ../../OSImages/sles11.qcow2 -cdrom ../../ISOz/mydvd.iso -m 2048 In the guest I can mount the iso image as you could normally expect mount /dev/cdrom /mnt mount: block device /dev/sr0 is write-protected, mounting read-only Info block in the monitor yields (qemu) info block ide0-hd0: type=hd removable=0 file../../OSImages/sles11.qcow2 ro=0 drv=dcow2 encrypted=0 ide1-cd0: type=cdrom removable=1 locked=1 file=../../ISOz/mydvd.iso ro=0 drv=raw encrypted=0 floppy0: type=floppy removable=1 locked=0 [not inserted] sd0: type=floppy removable=1 locked=0 [not inserted] When I try to do a eject ide0-cd0, I get a device busy message so I have to do a eject -f ide0-cd0 After which, an info block yields: (qemu) info block ide0-hd0: type=hd removable=0 file../../OSImages/sles11.qcow2 ro=0 drv=dcow2 encrypted=0 ide1-cd0: type=cdrom removable=1 locked=1 [not inserted] floppy0: type=floppy removable=1 locked=0 [not inserted] sd0: type=floppy removable=1 locked=0 [not inserted] I change the iso image with (or so it seems) (qemu) change ide1-cd0 ../../ISOz/mydvd2_rom.iso (qemu) info block ide0-hd0: type=hd removable=0 file../../OSImages/sles11.qcow2 ro=0 drv=dcow2 encrypted=0 ide1-cd0: type=cdrom removable=1 locked=1 file=../../ISOz/mydvd2.iso ro=0 drv=raw encrypted=0 floppy0: type=floppy removable=1 locked=0 [not inserted] sd0: type=floppy removable=1 locked=0 [not inserted] I go back to the guest and when I try to mount: mount /dev/cdrom /mnt mount: /dev/sr0 unknown device I'm running sles11 as guest and I think it may have something to do with sles11 as it works fine with ubuntu9. Any ideas what might be happening? Does it work if the guest uses ide based CD's: rmmod ide-scsi modprobe ide-cd David Thanks AK
Re: [Qemu-devel] Problems changing dvdrom iso during execution
On 05/20/2010 03:48 PM, Adnan Khaleel wrote: Thanks for your response. Does it work if the guest uses ide based CD's: rmmod ide-scsi modprobe ide-cd There isn't an ide-scsi but there is a scsi_mod and when I try to remove that it gives ERROR: Module scsi_mod is in use by sr_mod,sg,sd_mod,libata modprobe ide-cd seems to work. Ok, I pulled those from a RHEL3 VM. Looks like SLES11 is using a newer 2.6 kernel. The idea I was poking at was to get the CD in the VM to go through the ide-cd layer and not the ata/scsi route. I had to do that for my RHEL3 guest to get some consistency with the DVD -- similar to the problem you are seeing. David However it doesn't fix the problem. Interestingly, before doing modprobe ide-cd, linux lsmod | grep ide ide_pci_generic 46520 ide_core 115068 2 ide_pci_generic, piix After the modprobe ide-cd, I get ide_cd_mod 339840 cdrom 362002 ide_cd_mod, sr_mod ide_pci_generic 46520 ide_core 115068 3 ide_cd_mod, ide_pci_generic, piix
Re: [Qemu-devel] [PATCH v2] Release usb devices on shutdown and usb_del command
On 05/19/2010 12:10 PM, Shahar Havivi wrote:
When closig Vm or removing usb on guest via usb_del monitor command,
qemu does not return the control to the host, the user have to
unplug and plug the device in order to use it on the host.
v2:
added empty methods to usb-bsd and usb-stub.
release usb devices when main is out.
Signed-off-by: Shahar Havivi shah...@redhat.com
---
hw/usb-bus.c |4
hw/usb.h |2 ++
usb-bsd.c| 10 ++
usb-linux.c | 21 +
usb-stub.c | 10 ++
vl.c |1 +
6 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/hw/usb-bus.c b/hw/usb-bus.c
index b692503..75dc819 100644
--- a/hw/usb-bus.c
+++ b/hw/usb-bus.c
@@ -207,6 +207,10 @@ int usb_device_delete_addr(int busnr, int addr)
return -1;
dev = port-dev;
+if (!strcmp(dev-info-usbdevice_name, host)) {
+usb_host_device_release(dev);
+}
+
Shouldn't this be done through a callback -- say usbdevice_release
similar to usbdevice_init -- instead of embedding host specifics here?
You wouldn't need the bsd and stub stubs then.
David
qdev_free(dev-qdev);
return 0;
}
diff --git a/hw/usb.h b/hw/usb.h
index 00d2802..08c48d2 100644
--- a/hw/usb.h
+++ b/hw/usb.h
@@ -258,6 +258,8 @@ void usb_send_msg(USBDevice *dev, int msg);
USBDevice *usb_host_device_open(const char *devname);
int usb_host_device_close(const char *devname);
void usb_host_info(Monitor *mon);
+int usb_host_device_release(USBDevice *dev);
+void usb_cleanup(void);
/* usb-hid.c */
void usb_hid_datain_cb(USBDevice *dev, void *opaque, void (*datain)(void *));
diff --git a/usb-bsd.c b/usb-bsd.c
index 48567a3..fc9ea80 100644
--- a/usb-bsd.c
+++ b/usb-bsd.c
@@ -634,3 +634,13 @@ int usb_host_device_close(const char *devname)
{
return 0;
}
+
+int usb_host_device_release(USBDevice *dev)
+{
+return 0;
+}
+
+void usb_cleanup(void)
+{
+return 0;
+}
diff --git a/usb-linux.c b/usb-linux.c
index 88273ff..cea5b84 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -286,6 +286,27 @@ static void async_cancel(USBPacket *unused, void *opaque)
}
}
+void usb_cleanup(void)
+{
+struct USBHostDevice *s;
+
+QTAILQ_FOREACH(s, hostdevs, next) {
+if (s-fd != -1) {
+usb_host_device_release((USBDevice*)s);
+}
+}
+}
+
+int usb_host_device_release(USBDevice *dev)
+{
+int ret;
+
+USBHostDevice *s = DO_UPCAST(USBHostDevice, dev, dev);
+ret = ioctl(s-fd, USBDEVFS_RESET);
+
+return ret;
+}
+
static int usb_host_claim_interfaces(USBHostDevice *dev, int configuration)
{
int dev_descr_len, config_descr_len;
diff --git a/usb-stub.c b/usb-stub.c
index 9c3fcea..4432c2e 100644
--- a/usb-stub.c
+++ b/usb-stub.c
@@ -50,3 +50,13 @@ int usb_host_device_close(const char *devname)
{
return 0;
}
+
+int usb_host_device_release(USBDevice *dev)
+{
+return 0;
+}
+
+void usb_cleanup(void)
+{
+return 0;
+}
diff --git a/vl.c b/vl.c
index d77b47c..e3f4dc9 100644
--- a/vl.c
+++ b/vl.c
@@ -3914,6 +3914,7 @@ int main(int argc, char **argv, char **envp)
main_loop();
quit_timers();
net_cleanup();
+usb_cleanup();
return 0;
}
[Qemu-devel] Re: ehci fixes
On 05/09/2010 08:32 PM, Vincent Palatin wrote: Dear developers, While using the EHCI patchset, I have found 2 minor issues. So, I send in this email thread 2 fix proposals. Changes look good to me. Are you looking at any particular device or EHCI in general? David Those patches apply on top of the Jan Kiszka's ehci branch. Thanks to Jan and David for gathering and updating this patchset. -- Vincent
[Qemu-devel] [PATCH] ehci: fix infinite loop with usb netdevice
Hi Jan:
The attached addresses the spinning with the usb net device. Now I can
enable the device and ethtool shows a link:
# ifconfig usb0 up
# ethtool usb0
Settings for usb0:
Current message level: 0x0007 (7)
Link detected: yes
Though dhclient still can't get an address. After a bit of
instrumentation it appears that packets are lost in the receive the path
somewhere:
usb0 Link encap:Ethernet HWaddr 42:5F:CA:51:54:77
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:25 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:5513 (5.3 KiB)
I looked at an x3650M2 with an IMM. It has a usb-based ethernet device.
I compared the output of lsusb -v from the IMM with the qemu usb net
device and nothing jumps out -- other than the fact that the IMM's
network device shows up on a uhci bus.
David
diff --git a/hw/usb-ehci.c b/hw/usb-ehci.c
index f806a20..218d590 100644
--- a/hw/usb-ehci.c
+++ b/hw/usb-ehci.c
@@ -981,13 +981,15 @@ err:
qh-token |= QTD_TOKEN_HALT;
break;
case USB_RET_NAK:
+/* 4.10.3 */
reload = get_field(qh-epchar, QH_EPCHAR_RL);
if ((ehci-pid == USB_TOKEN_IN) reload) {
int nakcnt = get_field(qh-altnext_qtd, QH_ALTNEXT_NAKCNT);
nakcnt--;
set_field(qh-altnext_qtd, nakcnt, QH_ALTNEXT_NAKCNT);
+} else if (!reload) {
+return USB_RET_NAK;
}
-return USB_RET_NAK;
break;
case USB_RET_BABBLE:
fprintf(stderr, USB babble TODO\n);
@@ -1040,7 +1042,7 @@ err:
ret += ehci-more;
-if (ret ehci-tbytes) {
+if ((ret ehci-tbytes) (ehci-pid == USB_TOKEN_IN)) {
ret = USB_RET_BABBLE;
goto err;
}
[Qemu-devel] Re: ehci update
On 04/13/2010 05:35 PM, Jan Kiszka wrote: David S. Ahern wrote: After a month of code refactoring and clean ups, etc, I thought I would send along an update. The attached patch is relative to your ehci branch; I also attached the full usb-ehci.c file for easier reading. Thanks for your work! I applied it and once again merged git head at this chance. Just one request for the future: Please keep a queue of incremental changes. This EHCI beast is sufficiently tricky, and at some point someone (you included) may want to go back in history to find out where some change came from, and why it was applied. Agreed. I will submit focused changes from now on. E.g.: We apparently regressed further /wrt my favorite test case (as it's self-contained): -usbdevice net. qemu is now entering an infinite loop when you start dhcpcd in the guest on that interface. I've been focused on a single path -- async, bulk transfers to a USB key. I take a look at the ethernet device as well. I've struggled with the infinite loop part: the async train jumps the track with FC-12 guest rather quickly (ie., the link list is no longer a loop). I put in a loop detector in the advance_state function which helps for storage devices - but clearly something is not right. I've been roaming the ehci_hcd code in the kernel as well looking for clues. A lot of details to gel and the day job keeps getting in the way. :-) At this point I can get a Windows XP guest to format a 4GB key and read from and write to it. I can get an FC-12 guest to format a 4GB key and an 8GB key as well as read from and write to both. Write rates are on the order of 8 MB/sec for dd: # dd if=/dev/zero of=test bs=1M count=100 oflag=dsync 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 12.1205 s, 8.7 MB/s rsync of text files (e.g., /var/log) is on the order of 2MB/sec. 4GB keys are definitely more stable; the 8GB is not recognized by Windows XP. It still needs a lot of love, but definitely an improvement from the last version. The biggest difference for the performance boost and stability is discovering that the usbfs in linux limits transactions to 16k versus the EHCI spec which allows 20k per qTD. I added a hack to submit which detects 20k requests from a guest and breaks it up into 2 requests through the host (a 16k and then a 4k). Did someone already bring this up on LKML or wherever usbfs is discussed? Should be fixable, I naively guess. I submitted the patch to linux-usb and it was nack'ed. The response was that memory is allocated in powers of 2 so trying to up the limit from 16k to 20k means it will actually want to find 32k of contiguous memory. The suggestion was to handle it with multiple requests within qemu. I guess libusb does that. Right now there is a hack in the ehci model to do this, but the usb-linux code would be a better place since it might be specific to linux hosts. David Jan
Re: [Qemu-devel] Re: ehci update
On 04/13/2010 07:20 PM, Alexander Graf wrote: It still needs a lot of love, but definitely an improvement from the last version. The biggest difference for the performance boost and stability is discovering that the usbfs in linux limits transactions to 16k versus the EHCI spec which allows 20k per qTD. I added a hack to submit which detects 20k requests from a guest and breaks it up into 2 requests through the host (a 16k and then a 4k). Did someone already bring this up on LKML or wherever usbfs is discussed? Should be fixable, I naively guess. I submitted the patch to linux-usb and it was nack'ed. The response was that memory is allocated in powers of 2 so trying to up the limit from 16k to 20k means it will actually want to find 32k of contiguous memory. The suggestion was to handle it with multiple requests within qemu. I guess libusb does that. Any reason we're not using libusb? Good question. I was wondering the same. I was going to look at converting usb-linux to use libusb1 when I get some time. David Alex
Re: [Qemu-devel] [PATCH] hw/usb-msd: fix some usb requests
On 03/10/2010 02:45 AM, Arnaud Patard (Rtp) wrote: The usb-msd device emulation needs some small tweaks in the requests emulations. For instance, the reset/maxlun requests are class/interface specific so requests for them with the type class and recipient interface bits sets have to be handled. Signed-off-by: Arnaud Patard arnaud.pat...@rtp-net.org --- I hit this yesterday with msd as well. I suggest moving the ClassInterfaceRequest and ClassInterfaceOutRequest defines from hw/usb-net.c to hw/usb.h and then use those in hw/usb-msd.c for the Class specific requests. David
Re: [Qemu-devel] Re: EHCI support in QEMU
On 03/03/2010 04:47 PM, Jan Kiszka wrote: Thanks for your work, David and Niels! I assume that David based this on Niels' patch, so there is nothing to be merged? David's version built for me, so I pushed git://git.kiszka.org/qemu.git ehci So far it's supposed to be a reference for anyone interested in this topic, willing to test or even to hack on it. I will collect and merge improvements as they are sent to the list. Jan Yes, I took Niels post as a start. Addressed a few white space issues, made some of the initializations parallel the uhci code and removed the mem_base from the read/write functions (causing segfaults due to outbounds referencing -- addr MMIO_SIZE -- and do not appear to be needed). David
Re: [Qemu-devel] [PATCH] Restore terminal attributes for tty based monitor
On 02/27/2010 01:41 AM, Shahar Havivi wrote:
On Fri, Feb 26, 2010 at 03:19:19PM -0700, David S. Ahern wrote:
Date: Fri, 26 Feb 2010 15:19:19 -0700
From: David S. Ahern daah...@cisco.com
To: Shahar Havivi shah...@redhat.com
CC: qemu-devel@nongnu.org, Dor Laor dl...@redhat.com
Subject: Re: [Qemu-devel] [PATCH] Restore terminal attributes for tty based
monitor
On 02/26/2010 01:04 PM, Shahar Havivi wrote:
Fix codding style
---
qemu-char.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index 4169492..4533887 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -1002,6 +1002,7 @@ static void tty_serial_init(int fd, int speed,
speed, parity, data_bits, stop_bits);
#endif
tcgetattr (fd, tty);
+oldtty = tty;
#define check_speed(val) if (speed = val) { spd = B##val; break; }
speed = speed * 10 / 11;
@@ -1173,6 +1174,11 @@ static int tty_serial_ioctl(CharDriverState *chr,
int cmd, void *arg)
return 0;
}
+static void tty_exit(void)
+{
+tcsetattr(0, TCSANOW, oldtty);
+}
+
static void qemu_chr_close_tty(CharDriverState *chr)
{
FDCharDriver *s = chr-opaque;
@@ -1207,6 +1213,9 @@ static CharDriverState *qemu_chr_open_tty(QemuOpts
*opts)
}
chr-chr_ioctl = tty_serial_ioctl;
chr-chr_close = qemu_chr_close_tty;
+if (!term_atexit_done++) {
+atexit(tty_exit);
+}
return chr;
}
#else /* ! __linux__ ! __sun__ */
--
1.6.3.3
If qemu is invoked with both stdio and one or more host tty's only the
last one referenced is reset one exit. Also, shouldn't the attributes be
reset when the device is closed as opposed to exit? ie., a device
connected to a tty chardev is removed via the monitor.
David
stdio have the same handling code:
http://git.savannah.gnu.org/cgit/qemu.git/tree/qemu-char.c#n738
Shahar
Right now stdio is the only user of the oldtty global, so it holds the
atributes for stdio. If you reuse the variable you are setting the tty
(ttyN or ttySN) to the attributes retrieved from stdin - assuming it was
even used.
I think you want to save the attributes for the terminal that is in use
and reset that terminal on close / exit.
David
Re: [Qemu-devel] [PATCH] Restore terminal attributes for tty based monitor
On 02/26/2010 01:04 PM, Shahar Havivi wrote:
Fix codding style
---
qemu-char.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index 4169492..4533887 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -1002,6 +1002,7 @@ static void tty_serial_init(int fd, int speed,
speed, parity, data_bits, stop_bits);
#endif
tcgetattr (fd, tty);
+oldtty = tty;
#define check_speed(val) if (speed = val) { spd = B##val; break; }
speed = speed * 10 / 11;
@@ -1173,6 +1174,11 @@ static int tty_serial_ioctl(CharDriverState *chr, int
cmd, void *arg)
return 0;
}
+static void tty_exit(void)
+{
+tcsetattr(0, TCSANOW, oldtty);
+}
+
static void qemu_chr_close_tty(CharDriverState *chr)
{
FDCharDriver *s = chr-opaque;
@@ -1207,6 +1213,9 @@ static CharDriverState *qemu_chr_open_tty(QemuOpts
*opts)
}
chr-chr_ioctl = tty_serial_ioctl;
chr-chr_close = qemu_chr_close_tty;
+if (!term_atexit_done++) {
+atexit(tty_exit);
+}
return chr;
}
#else /* ! __linux__ ! __sun__ */
--
1.6.3.3
If qemu is invoked with both stdio and one or more host tty's only the
last one referenced is reset one exit. Also, shouldn't the attributes be
reset when the device is closed as opposed to exit? ie., a device
connected to a tty chardev is removed via the monitor.
David
Re: [Qemu-devel] Isochronous devices support in QEMU
David Ahern On 02/22/2010 12:32 AM, Taimoor Mirza wrote: Hi all, I've few questions about QEMU: 1) I read in QEMU's official documentation that in case of using host system devices USB devices requiring real time streaming (i.e. USB Video Cameras) are not supported yet. Also there is no isochronous transfer based virtual USB device in QEMU. I want to know what is current status of Iso. support in QEMU? Can I test my Linux based USB As of commit 8e65b7c04965c8355e4ce43211582b6b83054e3d I have been able to pass audio devices to a VM with good success (though I use qemu-kvm, not just qemu). I just started looking at web cameras and not having much luck yet. David host application for ARM with physical iso devices in host USB port? 2) I found a function ohci_service_iso_td in usb-ohci.c file in QEMU source code. 3) I am developing a Linux based USB device using Gadget API. Does QEMU provide USB function controller emulation in such a way that I can run plug this USB device at run time with host machine and can test it? Regards, Taimoor Hotmail: Trusted email with powerful SPAM protection. Sign up now. https://signup.live.com/signup.aspx?id=60969
Re: [Qemu-devel] [PATCH] terminal attributes is not restored when using /dev/tty monitor
On 02/20/2010 10:03 AM, Anthony Liguori wrote:
On 02/20/2010 09:18 AM, David S. Ahern wrote:
On 02/20/2010 01:30 AM, Shahar Havivi wrote:
when exiting qemu that run with -monitor /dev/tty, the launching
terminal get weird behaviour because no restore terminals action has
taken.
added chr_close and register atexit() code for tty devices (like stdio
does)
Signed-off-by: Shahar Havivishah...@redhat.com
---
qemu-char.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index 75dbf66..de16883 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -1002,6 +1002,7 @@ static void tty_serial_init(int fd, int speed,
speed, parity, data_bits, stop_bits);
#endif
tcgetattr (fd,tty);
+oldtty = tty;
#define check_speed(val) if (speed= val) { spd = B##val; break; }
speed = speed * 10 / 11;
@@ -1173,6 +1174,17 @@ static int tty_serial_ioctl(CharDriverState
*chr, int cmd, void *arg)
return 0;
}
+static void tty_exit(void)
+{
+tcsetattr(0, TCSANOW,oldtty);
+}
+
+static void qemu_chr_close_tty(struct CharDriverState *chr)
+{
+tty_exit();
+fd_chr_close(chr);
+}
The close callback needs to close the fd for the device as well. I have
sent a patch to handle this; waiting for it to be included:
http://permalink.gmane.org/gmane.comp.emulators.qemu/63472
It didn't apply with git-am. I'm not sure why, am investigating now.
Regards,
Anthony Liguori
Are you referring to my patch? I'm still learning the git commands, so
maybe I messed something up. I used git format-patch followed git send-mail.
If I save the email (Thunderbird client, saving the copy I received of
what I sent using git send-mail), strip out the mail headers and use
patch it applies fine - but with the warning (Stripping trailing CRs
from patch.)
David
Re: [Qemu-devel] [PATCH] terminal attributes is not restored when using /dev/tty monitor
On 02/20/2010 12:42 PM, Shahar Havivi wrote:
On Sat, Feb 20, 2010 at 11:03:41AM -0600, Anthony Liguori wrote:
Date: Sat, 20 Feb 2010 11:03:41 -0600
From: Anthony Liguori anth...@codemonkey.ws
To: David S. Ahern daah...@cisco.com
Cc: Dor Laor dl...@redhat.com, Shahar Havivi shah...@redhat.com,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] terminal attributes is not restored when
using /dev/tty monitor
On 02/20/2010 09:18 AM, David S. Ahern wrote:
On 02/20/2010 01:30 AM, Shahar Havivi wrote:
when exiting qemu that run with -monitor /dev/tty, the launching
terminal get weird behaviour because no restore terminals action has
taken.
added chr_close and register atexit() code for tty devices (like stdio
does)
Signed-off-by: Shahar Havivishah...@redhat.com
---
qemu-char.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index 75dbf66..de16883 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -1002,6 +1002,7 @@ static void tty_serial_init(int fd, int speed,
speed, parity, data_bits, stop_bits);
#endif
tcgetattr (fd,tty);
+oldtty = tty;
#define check_speed(val) if (speed= val) { spd = B##val; break; }
speed = speed * 10 / 11;
@@ -1173,6 +1174,17 @@ static int tty_serial_ioctl(CharDriverState *chr,
int cmd, void *arg)
return 0;
}
+static void tty_exit(void)
+{
+tcsetattr(0, TCSANOW,oldtty);
+}
+
+static void qemu_chr_close_tty(struct CharDriverState *chr)
+{
+tty_exit();
+fd_chr_close(chr);
+}
The close callback needs to close the fd for the device as well. I have
sent a patch to handle this; waiting for it to be included:
http://permalink.gmane.org/gmane.comp.emulators.qemu/63472
It didn't apply with git-am. I'm not sure why, am investigating now.
Regards,
Anthony Liguori
Note that the method fd_chr_close() is closing the fd_in, no need to the
close logic again, and when opening a monitor with /dev/tty the
chr-chr_close not called that is why you need to register with
atexit(). (same as stdio monitor does).
Shahar.
I don't see that fd_chr_close() closes the fd; it only unregisters the
handler.
David
Re: [Qemu-devel] [PATCH] terminal attributes is not restored when using /dev/tty monitor
On 02/20/2010 01:30 AM, Shahar Havivi wrote:
when exiting qemu that run with -monitor /dev/tty, the launching
terminal get weird behaviour because no restore terminals action has
taken.
added chr_close and register atexit() code for tty devices (like stdio
does)
Signed-off-by: Shahar Havivi shah...@redhat.com
---
qemu-char.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index 75dbf66..de16883 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -1002,6 +1002,7 @@ static void tty_serial_init(int fd, int speed,
speed, parity, data_bits, stop_bits);
#endif
tcgetattr (fd, tty);
+oldtty = tty;
#define check_speed(val) if (speed = val) { spd = B##val; break; }
speed = speed * 10 / 11;
@@ -1173,6 +1174,17 @@ static int tty_serial_ioctl(CharDriverState *chr, int
cmd, void *arg)
return 0;
}
+static void tty_exit(void)
+{
+tcsetattr(0, TCSANOW, oldtty);
+}
+
+static void qemu_chr_close_tty(struct CharDriverState *chr)
+{
+tty_exit();
+fd_chr_close(chr);
+}
The close callback needs to close the fd for the device as well. I have
sent a patch to handle this; waiting for it to be included:
http://permalink.gmane.org/gmane.comp.emulators.qemu/63472
David
+
static CharDriverState *qemu_chr_open_tty(QemuOpts *opts)
{
const char *filename = qemu_opt_get(opts, path);
@@ -1190,6 +1202,8 @@ static CharDriverState *qemu_chr_open_tty(QemuOpts
*opts)
return NULL;
}
chr-chr_ioctl = tty_serial_ioctl;
+chr-chr_close = qemu_chr_close_tty;
+atexit(tty_exit);
return chr;
}
#else /* ! __linux__ ! __sun__ */
[Qemu-devel] Re: [PATCH] segfault due to buffer overrun in usb-serial
I have not seen response to this. If there are no objections please apply.
Thanks,
David Ahern
On 02/03/2010 09:00 AM, David S. Ahern wrote:
This fixes a segfault due to buffer overrun in the usb-serial device.
The memcpy was incrementing the start location by recv_used yet, the
computation of first_size (how much to write at the end of the buffer
before wrapping to the front) was not accounting for it. This causes the
next element after the receive buffer (recv_ptr) to get overwritten with
random data.
Signed-off-by: David Ahern daah...@cisco.com
diff --git a/hw/usb-serial.c b/hw/usb-serial.c
index 37293ea..c3f3401 100644
--- a/hw/usb-serial.c
+++ b/hw/usb-serial.c
@@ -497,12 +497,28 @@ static int usb_serial_can_read(void *opaque)
static void usb_serial_read(void *opaque, const uint8_t *buf, int size)
{
USBSerialState *s = opaque;
-int first_size = RECV_BUF - s-recv_ptr;
-if (first_size size)
-first_size = size;
-memcpy(s-recv_buf + s-recv_ptr + s-recv_used, buf, first_size);
-if (size first_size)
-memcpy(s-recv_buf, buf + first_size, size - first_size);
+int first_size, start;
+
+/* room in the buffer? */
+if (size (RECV_BUF - s-recv_used))
+size = RECV_BUF - s-recv_used;
+
+start = s-recv_ptr + s-recv_used;
+if (start RECV_BUF) {
+/* copy data to end of buffer */
+first_size = RECV_BUF - start;
+if (first_size size)
+first_size = size;
+
+memcpy(s-recv_buf + start, buf, first_size);
+
+/* wrap around to front if needed */
+if (size first_size)
+memcpy(s-recv_buf, buf + first_size, size - first_size);
+} else {
+start -= RECV_BUF;
+memcpy(s-recv_buf + start, buf, size);
+}
s-recv_used += size;
}
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Qemu-devel] Re: [PATCH] add close callback for tty-based char device
I have not seen response to this. If there are no objections please apply.
Thanks,
David Ahern
On 02/03/2010 09:18 AM, David S. Ahern wrote:
Add a tty close callback. Right now if a guest device that is connected
to a tty-based chardev in the host is removed, the tty is not closed.
With this patch it is closed.
Example use case is connecting an emulated USB serial cable in the guest
to tty0 of the host using the monitor command:
usb_add serial::/dev/tty0
and then removing the device with:
usb_del serial::/dev/tty0
Signed-off-by: David Ahern daah...@cisco.com
diff --git a/qemu-char.c b/qemu-char.c
index 800ee6c..ecd84ec 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -1173,6 +1173,20 @@ static int tty_serial_ioctl(CharDriverState *chr,
int cmd
return 0;
}
+static void qemu_chr_close_tty(CharDriverState *chr)
+{
+FDCharDriver *s = chr-opaque;
+int fd = -1;
+
+if (s)
+fd = s-fd_in;
+
+fd_chr_close(chr);
+
+if (fd = 0)
+close(fd);
+}
+
static CharDriverState *qemu_chr_open_tty(QemuOpts *opts)
{
const char *filename = qemu_opt_get(opts, path);
@@ -1187,6 +1201,7 @@ static CharDriverState *qemu_chr_open_tty(QemuOpts
*opts)
return NULL;
}
chr-chr_ioctl = tty_serial_ioctl;
+chr-chr_close = qemu_chr_close_tty;
return chr;
}
#else /* ! __linux__ ! __sun__ */
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH] audio streaming from usb devices
I have not seen a response to this. If there are no objections please apply. Thanks, David Ahern On 02/03/2010 08:49 AM, David S. Ahern wrote: I have streaming audio devices working within qemu-kvm. This is a port of the changes to qemu. Streaming audio generates a series of isochronous requests that are repetitive and time sensitive. The URBs need to be submitted in consecutive USB frames and responses need to be handled in a timely manner. Summary of the changes for isochronous requests: 1. The initial 'valid' value is increased to 32. It needs to be higher than its current value of 10 since the host adds a 10 frame delay to the scheduling of the first request; if valid is set to 10 the first isochronous request times out and qemu cancels it. 32 was chosen as a nice round number, and it is used in the path where a TD-async pairing already exists. 2. The token field in the TD is *not* unique for isochronous requests, so it is not a good choice for finding a matching async request. The buffer (where to write the guest data) is unique, so use that value instead. 3. TD's for isochronous request need to be completed in the async completion handler so that data is pushed to the guest as soon as it is available. The uhci code currently attempts to process complete isochronous TDs the next time the UHCI frame with the request is processed. The results in lost data since the async requests will have long since timed out based on the valid parameter. Increasing the valid value is not acceptable as it introduces a 1+ second delay in the data getting pushed to the guest. 4. The frame timer needs to be run on 1 msec intervals. Currently, the expire time for the processing the next frame is computed after the processing of each frame. This regularly causes the scheduling of frames to shift in time. When this happens the periodic scheduling of the requests is broken and the subsequent request is seen as a new request by the host resulting in a 10 msec delay (first isochronous request is scheduled for 10 frames from when the URB is submitted). [ For what's worth a small change is needed to the guest driver to have more outstanding URBs (at least 4 URBs with 5 packets per URB).] Signed-off-by: David Ahern daah...@cisco.com
[Qemu-devel] [PATCH] audio streaming from usb devices
I have streaming audio devices working within qemu-kvm. This is a port
of the changes to qemu.
Streaming audio generates a series of isochronous requests that are
repetitive and time sensitive. The URBs need to be submitted in
consecutive USB frames and responses need to be handled in a timely manner.
Summary of the changes for isochronous requests:
1. The initial 'valid' value is increased to 32. It needs to be higher
than its current value of 10 since the host adds a 10 frame delay to the
scheduling of the first request; if valid is set to 10 the first
isochronous request times out and qemu cancels it. 32 was chosen as a
nice round number, and it is used in the path where a TD-async pairing
already exists.
2. The token field in the TD is *not* unique for isochronous requests,
so it is not a good choice for finding a matching async request. The
buffer (where to write the guest data) is unique, so use that value instead.
3. TD's for isochronous request need to be completed in the async
completion handler so that data is pushed to the guest as soon as it is
available. The uhci code currently attempts to process complete
isochronous TDs the next time the UHCI frame with the request is
processed. The results in lost data since the async requests will have
long since timed out based on the valid parameter. Increasing the valid
value is not acceptable as it introduces a 1+ second delay in the data
getting pushed to the guest.
4. The frame timer needs to be run on 1 msec intervals. Currently, the
expire time for the processing the next frame is computed after the
processing of each frame. This regularly causes the scheduling of frames
to shift in time. When this happens the periodic scheduling of the
requests is broken and the subsequent request is seen as a new request
by the host resulting in a 10 msec delay (first isochronous request is
scheduled for 10 frames from when the URB is submitted).
[ For what's worth a small change is needed to the guest driver to have
more outstanding URBs (at least 4 URBs with 5 packets per URB).]
Signed-off-by: David Ahern daah...@cisco.com
diff --git a/hw/usb-uhci.c b/hw/usb-uhci.c
index fdbb4d1..19b4ce6 100644
--- a/hw/usb-uhci.c
+++ b/hw/usb-uhci.c
@@ -112,6 +112,7 @@ typedef struct UHCIAsync {
uint32_t td;
uint32_t token;
int8_tvalid;
+uint8_t isoc;
uint8_t done;
uint8_t buffer[2048];
} UHCIAsync;
@@ -131,6 +132,7 @@ typedef struct UHCIState {
uint32_t fl_base_addr; /* frame list base address */
uint8_t sof_timing;
uint8_t status2; /* bit 0 and 1 are used to generate UHCI_STS_USBINT */
+int64_t expire_time;
QEMUTimer *frame_timer;
UHCIPort ports[NB_PORTS];
@@ -164,6 +166,7 @@ static UHCIAsync *uhci_async_alloc(UHCIState *s)
async-td= 0;
async-token = 0;
async-done = 0;
+async-isoc = 0;
async-next = NULL;
return async;
@@ -762,13 +765,25 @@ static int uhci_handle_td(UHCIState *s, uint32_t addr,
UHCI_TD *td, uint32_t *in
{
UHCIAsync *async;
int len = 0, max_len;
-uint8_t pid;
+uint8_t pid, isoc;
+uint32_t token;
/* Is active ? */
if (!(td-ctrl TD_CTRL_ACTIVE))
return 1;
-async = uhci_async_find_td(s, addr, td-token);
+/* token field is not unique for isochronous requests,
+ * so use the destination buffer
+ */
+if (td-ctrl TD_CTRL_IOS) {
+token = td-buffer;
+isoc = 1;
+} else {
+token = td-token;
+isoc = 0;
+}
+
+async = uhci_async_find_td(s, addr, token);
if (async) {
/* Already submitted */
async-valid = 32;
@@ -785,9 +800,13 @@ static int uhci_handle_td(UHCIState *s, uint32_t addr,
UHCI_TD *td, uint32_t *in
if (!async)
return 1;
-async-valid = 10;
+/* valid needs to be large enough to handle 10 frame delay
+ * for initial isochronous requests
+ */
+async-valid = 32;
async-td= addr;
-async-token = td-token;
+async-token = token;
+async-isoc = isoc;
max_len = ((td-token 21) + 1) 0x7ff;
pid = td-token 0xff;
@@ -841,9 +860,31 @@ static void uhci_async_complete(USBPacket *packet, void
*opaque)
dprintf(uhci: async complete. td 0x%x token 0x%x\n, async-td,
async-token);
-async-done = 1;
+if (async-isoc) {
+UHCI_TD td;
+uint32_t link = async-td;
+uint32_t int_mask = 0, val;
+int len;
+
+cpu_physical_memory_read(link ~0xf, (uint8_t *) td, sizeof(td));
+le32_to_cpus(td.link);
+le32_to_cpus(td.ctrl);
+le32_to_cpus(td.token);
+le32_to_cpus(td.buffer);
+
+uhci_async_unlink(s, async);
+len = uhci_complete_td(s, td, async, int_mask);
+s-pending_int_mask |= int_mask;
-uhci_process_frame(s);
+/* update the status bits of the TD */
+val = cpu_to_le32(td.ctrl);
+cpu_physical_memory_write((link ~0xf) + 4,
+
[Qemu-devel] [PATCH] segfault due to buffer overrun in usb-serial
This fixes a segfault due to buffer overrun in the usb-serial device.
The memcpy was incrementing the start location by recv_used yet, the
computation of first_size (how much to write at the end of the buffer
before wrapping to the front) was not accounting for it. This causes the
next element after the receive buffer (recv_ptr) to get overwritten with
random data.
Signed-off-by: David Ahern daah...@cisco.com
diff --git a/hw/usb-serial.c b/hw/usb-serial.c
index 37293ea..c3f3401 100644
--- a/hw/usb-serial.c
+++ b/hw/usb-serial.c
@@ -497,12 +497,28 @@ static int usb_serial_can_read(void *opaque)
static void usb_serial_read(void *opaque, const uint8_t *buf, int size)
{
USBSerialState *s = opaque;
-int first_size = RECV_BUF - s-recv_ptr;
-if (first_size size)
-first_size = size;
-memcpy(s-recv_buf + s-recv_ptr + s-recv_used, buf, first_size);
-if (size first_size)
-memcpy(s-recv_buf, buf + first_size, size - first_size);
+int first_size, start;
+
+/* room in the buffer? */
+if (size (RECV_BUF - s-recv_used))
+size = RECV_BUF - s-recv_used;
+
+start = s-recv_ptr + s-recv_used;
+if (start RECV_BUF) {
+/* copy data to end of buffer */
+first_size = RECV_BUF - start;
+if (first_size size)
+first_size = size;
+
+memcpy(s-recv_buf + start, buf, first_size);
+
+/* wrap around to front if needed */
+if (size first_size)
+memcpy(s-recv_buf, buf + first_size, size - first_size);
+} else {
+start -= RECV_BUF;
+memcpy(s-recv_buf + start, buf, size);
+}
s-recv_used += size;
}
[Qemu-devel] [PATCH] add close callback for tty-based char device
Add a tty close callback. Right now if a guest device that is connected
to a tty-based chardev in the host is removed, the tty is not closed.
With this patch it is closed.
Example use case is connecting an emulated USB serial cable in the guest
to tty0 of the host using the monitor command:
usb_add serial::/dev/tty0
and then removing the device with:
usb_del serial::/dev/tty0
Signed-off-by: David Ahern daah...@cisco.com
diff --git a/qemu-char.c b/qemu-char.c
index 800ee6c..ecd84ec 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -1173,6 +1173,20 @@ static int tty_serial_ioctl(CharDriverState *chr,
int cmd
return 0;
}
+static void qemu_chr_close_tty(CharDriverState *chr)
+{
+FDCharDriver *s = chr-opaque;
+int fd = -1;
+
+if (s)
+fd = s-fd_in;
+
+fd_chr_close(chr);
+
+if (fd = 0)
+close(fd);
+}
+
static CharDriverState *qemu_chr_open_tty(QemuOpts *opts)
{
const char *filename = qemu_opt_get(opts, path);
@@ -1187,6 +1201,7 @@ static CharDriverState *qemu_chr_open_tty(QemuOpts
*opts)
return NULL;
}
chr-chr_ioctl = tty_serial_ioctl;
+chr-chr_close = qemu_chr_close_tty;
return chr;
}
#else /* ! __linux__ ! __sun__ */
Re: [Qemu-devel] usb-host quirks
On 02/02/2010 06:42 AM, Michael Buesch wrote: Hi, I've got a buggy device that needs a special workaround to be usable under host-usb access. The device really doesn't like being reset via USBDEVFS_RESET. It immediatenly locks up the device firmware or whatever. It won't respond properly anymore. With the following patch it works fine, though. What about the USBDEVFS_RESET in usb_host_open? Does that have an impact? For some USB keys I have had to add an additional reset prior to claiming interfaces: diff --git a/usb-linux.c b/usb-linux.c index 1aaa595..092e75c 100644 --- a/usb-linux.c +++ b/usb-linux.c @@ -906,6 +906,9 @@ static int usb_host_open(USBHostDevice *dev, int bus_num, #endif +/* some keys require a reset before the getconfig */ +ioctl(fd, USBDEVFS_RESET); + /* * Initial configuration is -1 which makes us claim first * available config. We used to start with 1, which does not David Ahern So I was wondering what the accepted way was to get these quirks upstream into the qemu source tree. Is usb-linux.c the correct place, or should we put the quirk into a different place? --- usb-linux.c |4 1 file changed, 4 insertions(+) --- qemu.orig/usb-linux.c +++ qemu/usb-linux.c @@ -389,6 +389,10 @@ static void usb_host_handle_reset(USBDev dprintf(husb: reset device %u.%u\n, s-bus_num, s-addr); +if (((s-descr[8] 8) | s-descr[9]) == 0x2471 +((s-descr[10] 8) | s-descr[11]) == 0x0853) +return; + ioctl(s-fd, USBDEVFS_RESET); usb_host_claim_interfaces(s, s-configuration);
Re: [Qemu-devel] need help getting a USB audio device to work
On 01/03/2010 11:19 AM, David S. Ahern wrote: After weeks of fruitless effort I could use some help getting a USB audio device to work. I have instrumented the hell out of the guest driver and uhci code, qemu's linux and uhci code, and the host side usb code. Near as I can tell data from the device makes its way into qemu (async_complete shows a urb length equal to the data the host OS receives from the device), but the data does not appear to make its way to the guest OS. I have tried a variety of guests -- Fedora 12, RHEL5.3, and RHEL3U8, and none work. How do I determine in fact the data pulled into qemu from ioctl(USBDEVFS_REAPURBNDELAY) is getting pushed to the guest? Thanks, Upon further review the problem appears to be that the TD's are still active when received in the VM. In the bare metal case the usb-uhci code shows (my instrumentation in a RHEL3U8 guest): process_iso @ 36912: urb f74bd03c, mode 0, frame 1191, npkt 5, nerr 0, status 0357 TD @ c8281480, link 8281180, status 20007ff, info c610369: MaxLen=63 DT0 EP=2 Dev=3 PID=( IN ) Len=7ff e0 Link points to TD @ 08281180, Breadth first TD NOT active (20007ff) process_iso: 0 len 0 020007ff status 0 TD @ c82814c0, link 8281200, status 20007ff, info c610369: MaxLen=63 DT0 EP=2 Dev=3 PID=( IN ) Len=7ff e0 Link points to TD @ 08281200, Breadth first TD NOT active (20007ff) process_iso: 1 len 0 020007ff status 0 TD @ c8281500, link 8281180, status 259, info c610369: MaxLen=63 DT0 EP=2 Dev=3 PID=( IN ) Len=59 e0 Link points to TD @ 08281180, Breadth first TD NOT active (259) process_iso: 2 len 90 0259 status 0 TD @ c8281540, link 82811c0, status 257, info c610369: MaxLen=63 DT0 EP=2 Dev=3 PID=( IN ) Len=57 e0 Link points to TD @ 082811c0, Breadth first TD NOT active (257) process_iso: 3 len 88 0257 status 0 TD @ c82815c0, link 8281180, status 357, info c610369: MaxLen=63 DT0 EP=2 Dev=3 PID=( IN ) Len=57 e0 IOC Link points to TD @ 08281180, Breadth first TD NOT active (357) process_iso: 4 len 88 0357 status 0 process_iso: exit 5 (0), transfer length 500 actual len 266 The same case in a VM shows: process_iso: td still active TD @ c1980580, link 1980200, status 380, info c610269: MaxLen=63 DT0 EP=2 Dev=2 PID=( IN ) Len=00 e0 IOC Active Link points to TD @ 01980200, Breadth first process_urb: type 0 process_iso @ 8376: urb dee5c0f0, mode 0, frame 1033, npkt 5, nerr 0, status 030007ff TD @ c19805c0, link 1980180, status 280, info c610269: MaxLen=63 DT0 EP=2 Dev=2 PID=( IN ) Len=00 e0 Active Link points to TD @ 01980180, Breadth first TD still active (200)- grrr. paranoia! Does this ring a bell with anyone? David
[Qemu-devel] need help getting a USB audio device to work
After weeks of fruitless effort I could use some help getting a USB audio device to work. I have instrumented the hell out of the guest driver and uhci code, qemu's linux and uhci code, and the host side usb code. Near as I can tell data from the device makes its way into qemu (async_complete shows a urb length equal to the data the host OS receives from the device), but the data does not appear to make its way to the guest OS. I have tried a variety of guests -- Fedora 12, RHEL5.3, and RHEL3U8, and none work. How do I determine in fact the data pulled into qemu from ioctl(USBDEVFS_REAPURBNDELAY) is getting pushed to the guest? Thanks, -- David Ahern
Re: [Qemu-devel] cpuid problem in upstream qemu with kvm
On 12/21/2009 05:05 AM, Avi Kivity wrote: On 12/21/2009 01:45 PM, Alexander Graf wrote: Well, we have two groups: 1) Casual user w/o management app 2) Enterprise user w/ management app So I clearly belong to the first group. 3) Developer/power user who knows what he's about. You could simply add -cpu qemu64 for those guests that care about it. 4) embedded virtualization where the use of a management app provides little to no added benefit and everything has to be automated (ie., no user). My point is there are other use cases besides data center deployments (aka enterprise) and workstation (casual/power user). There are use cases where virtualization is just yet another tool to achieve a product. David
Re: [Qemu-devel] cpuid problem in upstream qemu with kvm
On 12/21/2009 06:51 AM, Michael S. Tsirkin wrote: On Mon, Dec 21, 2009 at 06:45:22AM -0700, David S. Ahern wrote: On 12/21/2009 05:05 AM, Avi Kivity wrote: On 12/21/2009 01:45 PM, Alexander Graf wrote: Well, we have two groups: 1) Casual user w/o management app 2) Enterprise user w/ management app So I clearly belong to the first group. 3) Developer/power user who knows what he's about. You could simply add -cpu qemu64 for those guests that care about it. 4) embedded virtualization where the use of a management app provides little to no added benefit and everything has to be automated (ie., no user). My point is there are other use cases besides data center deployments (aka enterprise) and workstation (casual/power user). There are use cases where virtualization is just yet another tool to achieve a product. David Yes, but unless someone runs qemu directly, default value for any flag does not matter much. That's what I was getting at - direct invocation of qemu in an automated sense without a libvirt layer. Defaults that do the right thing on the host would be nice, with tweaking from the defaults only if something extra is wanted. David
Re: [Qemu-devel] Qemu terminating with SIGABRT
I'm using a variant of the KVM source from RHEL5 plus a few cherry-picked patches. Host OS is RHEL 5.3. The servers are using E5540 or E5504 processors. The host OS is running from a small USB key, and there is no place to write a core file. Other accommodations have to be made to get it. Hopefully by the end of the week I can get make to reproducing the abort and capturing a core. David Ahern On 12/14/2009 09:04 AM, Luiz Capitulino wrote: On Sat, 12 Dec 2009 11:09:38 -0700 David S. Ahern daah...@cisco.com wrote: Thanks for the responses. I had forgotten that SIGABRT==abort() which means I have to get the core file to get to the root cause. To date the only information I have is a shell exit status of 134 which from the bash man pages means it died due to SIGABRT. Are you using qemu-kvm or upstream qemu? Which version? Don't you have any procedure which would make the bug more likely to happen? Thanks.
Re: [Qemu-devel] Qemu terminating with SIGABRT
Thanks for the responses. I had forgotten that SIGABRT==abort() which means I have to get the core file to get to the root cause. To date the only information I have is a shell exit status of 134 which from the bash man pages means it died due to SIGABRT. David Ahern On 12/12/2009 01:52 AM, Stefan Weil wrote: David S. Ahern schrieb: I realize this is a rather generic question, but what are typical reasons Qemu would be killed by a SIGABRT? I am seeing this on a somewhat regular (though not repeatable on demand) basis. I do not have a core file, though I hope to capture one if I can get it repeat again. Thanks, Look for abort in QEMU's code to see the possible reasons. In many cases, the reason will be printed to stderr before aborting. Did you call QEMU from a console and get some output there? Or maybe the stderr output went into a file? Run ulimit -c unlimited before you run QEMU, then a core file will be written automatically on SIGABRT.
[Qemu-devel] Qemu terminating with SIGABRT
I realize this is a rather generic question, but what are typical reasons Qemu would be killed by a SIGABRT? I am seeing this on a somewhat regular (though not repeatable on demand) basis. I do not have a core file, though I hope to capture one if I can get it repeat again. Thanks, -- David Ahern
