Re: [Qemu-devel] Where is ehci hiding ?

[David S. Ahern]

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] Where is ehci hiding ?

[David S. Ahern]

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] State of EHCI emulation for QEMU

[David S. Ahern]

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

[David S. Ahern]

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

[David S. Ahern]

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

[David S. Ahern]

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] Log Console Output to File

[David S. Ahern]

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"  wrote:
> 
> On 11/11/10 09:57, Mulyadi Santosa wrote:
> > On Thu, Nov 11, 2010 at 12:50,  <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

[David S. Ahern]

On 11/11/10 09:57, Mulyadi Santosa wrote:
> On Thu, Nov 11, 2010 at 12:50,   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] Anyone seeing huge slowdown launching qemu with Linux 2.6.35?

[David S. Ahern]

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

Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35?

[David S. Ahern]

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

[Qemu-devel] Re: [PATCH] Create USB buses and devices based on USB version.

[David S. Ahern]

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 
> ---
>  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);
>  }

[Qemu-devel] enabling X86_FEATURE_ARCH_PERFMON in guest

[David S. Ahern]

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

[Qemu-devel] Re: KVM call minutes for July 20

[David S. Ahern]

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

Re: [Qemu-devel] [PATCH] Error on O_DIRECT for physical CDROM/DVD drives

[David S. Ahern]

On 07/20/10 10:09, jes.soren...@redhat.com wrote:
> From: Jes Sorensen 
> 
> 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 
> ---
>  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);

Re: [Qemu-devel] Re: [PATCH] Disable O_DIRECT for physical CDROM/DVD drives

[David S. Ahern]

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 Sorensen
>>>
>>> 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 Sorensen
>>>
>>
>> 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

[Qemu-devel] Re: [PATCH] Create USB buses and devices based on USB version.

[David S. Ahern]

On 07/14/10 11:56, David Ahern wrote:
> Create USB buses and devices based on USB version.
> 
> Signed-off-by: David Ahern 

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

[Qemu-devel] Re: [PATCH] ehci: check controller state when setting list registers

[David S. Ahern]

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 v7 RESEND 4/4] Inter-VM shared memory PCI device

[David S. Ahern]

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=[,shm=]
> 
> Interrupts are supported between multiple VMs by using a shared memory server
> by using a chardev socket.
> 
> -device ivshmem,size=[,shm=]
>[,chardev=][,msi=on][,irqfd=on][,vectors=n][,role=peer|master]
> -chardev socket,path=,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 
> ---
>  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 
> + *
> + * 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 
> +#include 
> +
> +#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 

[Qemu-devel] Re: [PATCH] ehci: uhci-ehci co-existence (handling v1.1 and v2 devices)

[David S. Ahern]

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->qd

[Qemu-devel] Re: [PATCH] ehci: uhci-ehci co-existence (handling v1.1 and v2 devices)

[David S. Ahern]

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

Re: [Qemu-devel] Guest OS hangs on usb_add

[David S. Ahern]

On 06/23/10 22:45, TJ wrote:
> 
>> -- Forwarded message --
>> From: Timothy Jones 
>> 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.

[David S. Ahern]

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

Re: [Qemu-devel] [RFC PATCH 0/2] Add USB Video Class device emulation.

[David S. Ahern]

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=
> 
> 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

[Qemu-devel] Re: [RFC] Moving the kvm ioapic, pic, and pit back to userspace

[David S. Ahern]

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

[Qemu-devel] Re: [RFC] Moving the kvm ioapic, pic, and pit back to userspace

[David S. Ahern]

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

Re: [Qemu-devel] [Bug 319014] Re: serial usb-device can't be passed-through to a guest

[David S. Ahern]

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

[David S. Ahern]

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

Re: [Qemu-devel] RFC: ehci -> uhci handoff suggestions

[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.
> 
>> 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

[Qemu-devel] RFC: ehci -> uhci handoff suggestions

[David S. Ahern]

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] Problems changing dvdrom iso during execution

[David S. Ahern]

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] [PATCH v2] Release usb devices on shutdown and usb_del command

[David S. Ahern]

> 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

[David S. Ahern]

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] Problems changing dvdrom iso during execution

[David S. Ahern]

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] [PATCH v2] Release usb devices on shutdown and usb_del command

[David S. Ahern]

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 
> ---
>  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

[David S. Ahern]

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

[David S. Ahern]

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;
 }

Re: [Qemu-devel] Re: ehci update

[David S. Ahern]

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
> 

[Qemu-devel] Re: ehci update

[David S. Ahern]

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] [PATCH] hw/usb-msd: fix some usb requests

[David S. Ahern]

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 
> ---

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] [PATCH] EHCI support - device recognized, but no data

[David S. Ahern]

On 03/07/2010 04:32 AM, Jan Kiszka wrote:
> Kevin Wolf wrote:
>> Am Freitag, 5. März 2010 04:17 schrieb David S. Ahern:
>>> Jan:
>>>
>>> I spent some more time on the EHCI support today. With the attached
>>> patch (delta to the patch from yesterday) a USB key is recognized within
>>> the guest (FC-12):
>>
>> Looks very nice. Actually I could access the file system on my USB stick. I 
>> have pushed your patch along with some additional minor changes to 
>> git://repo.or.cz/qemu/kevin.git ehci. Jan, you might want to pull from there.
>>
> 
> Merged, thanks.
> 
> Meanwhile I played with some more devices, and I think I found one
> scenario that should be handy to debug: -usbdevice net. Apparently, it
> does not work yet, my console is just flooded with
> 
>>>>>> ASYNC STATE MACHINE execute
> 000.005 exec: ctr is 1
> 000.004 exec: frindex is 488,3
> 000.004 setting qh.current from 0E0B21E0 to 0x0E0B21E0
> 000.005 Active non-interrupt QH, executing
> 000.003 pid is  1
> 000.0.222 periodic state adv fr=490.  [0E0B37A8] -> 0001
> 000.009 periodic state adv fr=490.  [0E0B37A8] -> 0001
> 000.009
> 
>>>>>> ASYNC STATE MACHINE execute
> 000.006 exec: ctr is 1
> 000.003 exec: frindex is 490,2
> 000.005 setting qh.current from 0E0B21E0 to 0x0E0B21E0
> 000.004 Active non-interrupt QH, executing
> 000.004 pid is  1
> 000.004 calling dev->info->handle_packet
> 000.004 exit loop dev->info->handle_packet
> 000.003 Enter EXECUTING
> 000.004 USBTRAN RSP NAK, returning without clear active
> 000.004 finishing exec
> 000.004 Nak occured and RL != 0, dec NakCnt to -1
> 000.004 write QH to VM memory
> 000.203 periodic state adv fr=490.  [0E0B37A8] -> 0001
> 000.008 periodic state adv fr=490.  [0E0B37A8] -> 0001
> 000.009
> 
> Messages. The guest reports that it received one Ethernet packet, but
> that's all, dhcpcd fails with a timeout. Already "ifconfig ethX up"
> starts this flooding.
> 
> Jan
> 

What guest OS were you successful with for storage devices - windows or
linux, 32-bit or 64? I've been mainly using FC-12, x86_64 as the guest
OS, and an external (ie., physical) key of recent vintage. Qemu's msd
device does not work with FC-12 (and UHCI).

I played around with Qemu's usb-net device a bit, but not sure I am
configuring it correctly (using monitor commands to attach).

David

[Qemu-devel] [PATCH] EHCI support - device recognized, but no data

[David S. Ahern]

Jan:

I spent some more time on the EHCI support today. With the attached
patch (delta to the patch from yesterday) a USB key is recognized within
the guest (FC-12):

scsi 2:0:0:0: Direct-Access Kingston DT HyperXPMAP PQ: 0
ANSI: 0 CCS
sd 2:0:0:0: Attached scsi generic sg1 type 0
sd 2:0:0:0: [sda] 15646720 512-byte logical blocks: (8.01 GB/7.46 GiB)
sd 2:0:0:0: [sda] Write Protect is off
sd 2:0:0:0: [sda] Mode Sense: 23 00 00 00
sd 2:0:0:0: [sda] Assuming drive cache: write through
sd 2:0:0:0: [sda] Assuming drive cache: write through
 sda: sda1 sda2
sd 2:0:0:0: [sda] Assuming drive cache: write through
sd 2:0:0:0: [sda] Attached SCSI removable disk


Unfortunately, fdisk fails to show any data. I'll be out for a few days,
so I won't get back to this until next week.

David
diff --git a/hw/usb-ehci.c b/hw/usb-ehci.c
index aa8ed9e..07eea11 100644
--- a/hw/usb-ehci.c
+++ b/hw/usb-ehci.c
@@ -28,17 +28,16 @@
 #include "usb-ehci.h"
 #include "monitor.h"
 
-#define EHCI_DEBUG 1
-#if EHCI_DEBUG
-//#define DEBUG(x) timed_printf x 
-#define DEBUG(x) printf x
+#define EHCI_DEBUG   1
+#define TDEBUG   0
+#define DEBUG_PACKET 1
+
+#if EHCI_DEBUG || TDEBUG || DEBUG_PACKET
+//#define DPRINTF printf
+#define DPRINTF timed_printf
 #else
-#define DEBUG(x)
+#define DPRINTF(...) 
 #endif
-//static int timed_printf(const char *fmt, ...);
-
-// #define TDEBUG
-// #define DEBUG_PACKET
 
 #define ASSERT(x) { if (!(x)) { printf("Assertion failed in usb-echi.c line 
%d\n", __LINE__); exit(1); } }
 
@@ -135,6 +134,7 @@
 #else
 #define FRAME_TIMER_FREQ 8000
 #endif
+#define FRAME_TIMER_USEC (100 / FRAME_TIMER_FREQ)
 
 #define NB_MAXINTRATE8// Max rate at which controller issues ints
 #define NB_PORTS 4// Number of downstream ports
@@ -376,6 +376,8 @@ typedef struct {
 uint32_t frame_end_usec;
 } EHCIState;
 
+#define SET_LAST_RUN_CLOCK(s)  (s)->last_run_usec = qemu_get_clock(vm_clock) / 
1000;
+
 static inline uint32_t get_field(uint32_t data, uint32_t mask, int shift)
 {
 return((data & mask) >> shift);
@@ -388,23 +390,95 @@ static inline void set_field(uint32_t *data, uint32_t val,
 *data |=(val << shift);
 }
 
+#if EHCI_DEBUG
+static int timed_printf(const char *fmt, ...)
+{
+int msec, usec;
+static int usec_last;
+va_list ap;
+
+usec = qemu_get_clock(vm_clock) / 1000;
+
+msec = usec - usec_last;
+usec_last = usec;
+usec = msec;
+
+msec /= 1000;
+msec %= 1000;
+
+usec %= 1000;
+
+va_start(ap, fmt);
+printf("%03d.%03d ", msec, usec);
+vprintf(fmt, ap);
+va_end(ap);
+
+return 0;
+}
+
+static const char *addr2str(unsigned addr)
+{
+const char *r = "   unknown";
+
+switch(addr) {
+case CAPLENGTH:
+r = " CAPLENGTH";
+break;
+
+case HCIVERSION:
+r = "HCIVERSION";
+break;
+
+case HCSPARAMS:
+r = " HCSPARAMS";
+break;
+
+case HCCPARAMS:
+r = " HCCPARAMS";
+break;
+
+case USBCMD:
+r = "   COMMAND";
+break;
+
+case USBSTS:
+r = "STATUS";
+break;
+
+case USBINTR:
+r = " INTERRUPT";
+break;
+
+case FRINDEX:
+r = " FRAME IDX";
+break;
+}
+
+return r;
+}
+
 static void dump_ptr(const char *s, uint32_t ptr, int has_type)
 {
 int t = NLPTR_TYPE_GET(ptr);
-
-printf("%s%08X", s, NLPTR_GET(ptr));
+DPRINTF("%s%08X", s, NLPTR_GET(ptr));
 
 if (has_type) {
-printf("(PTR type is %s)",
+DPRINTF("(PTR type is %s)",
 t == NLPTR_TYPE_ITD ? "ITD" :
(t == NLPTR_TYPE_QH ? "QH" :
(t == NLPTR_TYPE_STITD ? "STITD" :
(t == NLPTR_TYPE_FSTN ? "FSTN" : "";
 }
 
-printf("%s\n", NLPTR_TBIT(ptr) ? " TBIT set" : "");
+DPRINTF("%s\n", NLPTR_TBIT(ptr) ? " TBIT set" : "");
 }
+#else
+static inline void dump_ptr(const char *s, uint32_t ptr, int has_type)
+{
+}
+#endif
 
+#if EHCI_DEBUG || DEBUG_PACKET
 static void dump_qtd(EHCIqtd *qtd, uint32_t qtdaddr)
 {
 int pid;
@@ -445,7 +519,8 @@ static void dump_qtd(EHCIqtd *qtd, uint32_t qtdaddr)
   qtd->bufptr[0] & BUFPTR_CURROFF_MASK);
 printf("===   \n");
 }
-
+#endif
+#if EHCI_DEBUG
 static void dump_qh(EHCIqh *qh, uint32_t qhaddr)
 {
 int speed =(qh->epchar & QH_EPCHAR_EPS_MASK) >> QH_EPCHAR_EPS_SH;
@@ -496,8 +571,13 @@ static void dump_qh(EHCIqh *qh, uint32_t qhaddr)
  (qh->bufptr[2] & BUFPTR_SBYTES_MASK) >> BUFPTR_SBYTES_SH);
 printf("==    \n");
 }
+#else
+static inline void dump_qh(EHCIqh *qh, uint32_t qhaddr)
+{
+}
+#endif
 
-#ifdef DEBUG_PACKET
+#if DEBUG_PACKET
 
 static void dump_itd(EHCIitd *itd, uint32_t addr)
 {
@@ -554,49 +634,22 @@ static void dump_itd(EHCIitd *itd, uint32_t addr)
 
 #endif
 
-#if 0
-static int timed_printf(const char *fmt, 

Re: [Qemu-devel] Re: EHCI support in QEMU

[David S. Ahern]

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

[David S. Ahern]

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" 
>> To: Shahar Havivi 
>> CC: qemu-devel@nongnu.org, Dor Laor 
>> 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

[David S. Ahern]

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 S. Ahern]

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.
> 

Re: [Qemu-devel] [PATCH] terminal attributes is not restored when using /dev/tty monitor

[David S. Ahern]

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 
>> To: "David S. Ahern" 
>> Cc: Dor Laor , Shahar Havivi ,
>>  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 Havivi
>>>> ---
>>>>  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

[David S. Ahern]

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 Havivi
>>> ---
>>>   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

[David S. Ahern]

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 
> ---
>  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 v2] add close callback for tty-based char device

[David S. Ahern]

I have not seen a follow up. I believe the comments regarding whitespace
and coding style have been addressed.

Thanks,
David Ahern


On 02/10/2010 06:27 PM, David Ahern wrote:
> v1 -> v2  coding style changes
> 
> 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 ttyS0 of the host using the monitor command:
> 
> usb_add serial::/dev/ttyS0
> 
> and then removing the device with:
> 
> usb_del serial::/dev/ttyS0
> 
> Signed-off-by: David Ahern 
> ---
>  qemu-char.c |   17 +
>  1 files changed, 17 insertions(+), 0 deletions(-)
> 
> diff --git a/qemu-char.c b/qemu-char.c
> index 75dbf66..4169492 100644
> --- a/qemu-char.c
> +++ b/qemu-char.c
> @@ -1173,6 +1173,22 @@ static int tty_serial_ioctl(CharDriverState *chr, int 
> cmd, void *arg)
>  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");
> @@ -1190,6 +1206,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] [PATCH] audio streaming from usb devices

[David S. Ahern]

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 
> 
> 

[Qemu-devel] Re: [PATCH] add close callback for tty-based char device

[David S. Ahern]

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 
> 
> 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
> 

[Qemu-devel] Re: [PATCH] segfault due to buffer overrun in usb-serial

[David S. Ahern]

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 
> 
> 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] [PATCH] add close callback for tty-based char device

[David S. Ahern]

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 

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__ */

[Qemu-devel] [PATCH] segfault due to buffer overrun in usb-serial

[David S. Ahern]

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 

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] audio streaming from usb devices

[David S. Ahern]

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 


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 & 

Re: [Qemu-devel] usb-host quirks

[David S. Ahern]

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

[David S. Ahern]

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

[David S. Ahern]

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

[David S. Ahern]

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] cpuid problem in upstream qemu with kvm

[David S. Ahern]

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] Qemu terminating with SIGABRT

[David S. Ahern]

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"  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

[David S. Ahern]

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

[David S. Ahern]

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