Re: [Qemu-devel] Wiki spam

[Brad Hards]

On Mon, 4 Jul 2011 03:15:06 PM Stefan Hajnoczi wrote:
> Thanks.  I have a regular wiki account so I checked the Recent Changes
> page and undid the spam changes that I saw:
> 
> http://wiki.qemu.org/Special:RecentChanges
Is there a way to completely remove it? There is still spam on the wiki 
showing at:
http://wiki.qemu.org/index.php?title=Special:DeadendPages&limit=500&offset=0

I'd prefer not to have it in the history at all if thats possible.

Brad

Re: [Qemu-devel] [PATCH 08/11] usb-ehci: Fix handling of PED and PEDC port status bits

[Brad Hards]

5/11 does this:
-#define PORTSC_RO_MASK   0x007021c5
+#define PORTSC_RO_MASK   0x007021c4

before 8/11 does this:
> -#define PORTSC_RO_MASK   0x007021c4
> +#define PORTSC_RO_MASK   0x007021c0

You could push those together if there was a v2. I don't think its important 
though.

Even nicer would be to build it out of symbolic constants / defines, so its 
obvious what is being masked.

Brad

[Qemu-devel] [PATCH] doc: Minor typo fix.

[Brad Hards]

Thanks to agraf_, stefanha and Snader_LB for their IRC assistance.

Thanks to Markus Armbruster and Alexander Graf (again) for their
assistance with the second version of this patch. No patch is too
simple to test...

Signed-off-by: Brad Hards 
---
 qemu-options.hx |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/qemu-options.hx b/qemu-options.hx
index 82e085a..88e7eaa 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1161,9 +1161,9 @@ Specify the guest-visible address of the host. Default is 
the 2nd IP in the
 guest network, i.e. x.x.x.2.
 
 @item restrict=y|yes|n|no
-If this options is enabled, the guest will be isolated, i.e. it will not be
+If this option is enabled, the guest will be isolated, i.e. it will not be
 able to contact the host and no guest IP packets will be routed over the host
-to the outside. This option does not affect explicitly set forwarding rule.
+to the outside. This option does not affect any explicitly set forwarding 
rules.
 
 @item hostname=@var{name}
 Specifies the client hostname reported by the builtin DHCP server.
-- 
1.7.4.1

[Qemu-devel] [PATCH] doc: Minor typo fix.

[Brad Hards]

Thanks to agraf_, stefanha and Snader_LB for their IRC assistance.

Signed-off-by: Brad Hards 
---
 qemu-options.hx |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/qemu-options.hx b/qemu-options.hx
index 82e085a..005c141 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1161,9 +1161,9 @@ Specify the guest-visible address of the host. Default is 
the 2nd IP in the
 guest network, i.e. x.x.x.2.
 
 @item restrict=y|yes|n|no
-If this options is enabled, the guest will be isolated, i.e. it will not be
+If this optionsis enabled, the guest will be isolated, i.e. it will not be
 able to contact the host and no guest IP packets will be routed over the host
-to the outside. This option does not affect explicitly set forwarding rule.
+to the outside. This option does not affect any explicitly set forwarding 
rules.
 
 @item hostname=@var{name}
 Specifies the client hostname reported by the builtin DHCP server.
-- 
1.7.4.1

Re: [Qemu-devel] [0/7] USB UVC updates

[Brad Hards]

On Mon, 6 Jun 2011 07:32:32 PM Natalia Portillo wrote:
> I see it ok, have you tested nothing broken? (specially with the &s patch)
It doesn't work for me (before or after). The descriptor part (which I've now 
implemented) works OK (i.e. the guest can dump it), cheese runs in the guest 
but doesn't show images. luvcview opens but won't capture data. So I have more 
work to do.

> I should take more care with 's's in typos next time
I don't think this is the biggest problem :-)
 
> > The next change I propose to make is to rework the descriptors
> > and add constants / defines for magic numbers.
> 
> Yeah, there are a couple of magic numbers that can be added.
> Please note that most of the constants used in the descriptors should go
> in usb.h
I was planning to do the ones that are specific to usb-uvc.c in that file, and 
only (potentially) shared things like the interface descriptor stuff in usb.h

> Also take special care with the descriptors, the minimal change can break
> it very easily. The ideal solution would be to make the descriptors be
> dynamic depending on the host webcam capabilities.
I believe that part of the descriptor change may be associated with not 
reading data. I could easily have introduced a problem. I haven't finished 
debugging it, but I never see transactions to EP 2 (the isoc data endpoint).

> Bad thing the USB IF put the resolutions and formats in the descriptor,
> instead of in a query command.
Indeed, but like everything in USB device space, its designed down to minimise 
cost on (real) hardware.

Thanks.

Brad

[Qemu-devel] [Bug 793317] Re: Large amount of write-only variables

[Brad Hards]

I'm still confused.
hw/usb-ehci.c line 526 is just a variable declaration:
uint8_t *pci_conf;

Line 529 looks like an unused assignment, but nothing I see on line 526.

Would it be possible for you to double check the work, and possible
paste the error message instead of summarising them?

Brad

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/793317

Title:
  Large amount of write-only variables

Status in QEMU:
  New

Bug description:
  Whenever I try to compile the source from the git repo, it gets a
  large number of "set but not used" errors, in files such as:

  hw/usb_ochi.c (line 526, 1114, and 1108)
  hw/lsi53c895a.c (line 892)
  kvm.c (line 973)
  target-alpha/translate.c (line 1472, 1470)
  linux-user/syscall.c (line 7062, 3754)
  exec.c (line 1211)
  linux-user/linuxload.c (line 60)

  Really now, why would anyone create so many write-only variables
  knowing that it's compiled with write-only variables causing errors..?

  Host: Fedora 15 i686
  Gcc: 4.6.0
  Guest: None
  I pulled the code from the git repo earlier today, so I'm pretty sure it did 
not get fixed in that short timeframe.

[Qemu-devel] [Bug 793317] Re: Large amount of write-only variables

[Brad Hards]

Ok, looking at the first example (line 526), I see code that looks like:

static inline int ohci_put_iso_td(OHCIState *ohci,
  uint32_t addr, struct ohci_iso_td *td)
{
return (put_dwords(ohci, addr, (uint32_t *)td, 4) &&
put_words(ohci, addr + 16, td->offset, 8));
}

Is that what you see? Because I don't see any variables that are only
set.

Of course you're using a newer compiler, but I'm still not sure I can
see the problem.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/793317

Title:
  Large amount of write-only variables

Status in QEMU:
  New

Bug description:
  Whenever I try to compile the source from the git repo, it gets a
  large number of "set but not used" errors, in files such as:

  hw/usb_ochi.c (line 526, 1114, and 1108)
  hw/lsi53c895a.c (line 892)
  kvm.c (line 973)
  target-alpha/translate.c (line 1472, 1470)
  linux-user/syscall.c (line 7062, 3754)
  exec.c (line 1211)
  linux-user/linuxload.c (line 60)

  Really now, why would anyone create so many write-only variables
  knowing that it's compiled with write-only variables causing errors..?

  Host: Fedora 15 i686
  Gcc: 4.6.0
  Guest: None
  I pulled the code from the git repo earlier today, so I'm pretty sure it did 
not get fixed in that short timeframe.

[Qemu-devel] [Bug 793317] Re: Large amount of write-only variables

[Brad Hards]

I don't have a file called hw/usb_ochi.c. Did you mean hw/usb-ohci.c?

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/793317

Title:
  Large amount of write-only variables

Status in QEMU:
  New

Bug description:
  Whenever I try to compile the source from the git repo, it gets a
  large number of "set but not used" errors, in files such as:

  hw/usb_ochi.c (line 526, 1114, and 1108)
  hw/lsi53c895a.c (line 892)
  kvm.c (line 973)
  target-alpha/translate.c (line 1472, 1470)
  linux-user/syscall.c (line 7062, 3754)
  exec.c (line 1211)
  linux-user/linuxload.c (line 60)

  Really now, why would anyone create so many write-only variables
  knowing that it's compiled with write-only variables causing errors..?

  Host: Fedora 15 i686
  Gcc: 4.6.0
  Guest: None
  I pulled the code from the git repo earlier today, so I'm pretty sure it did 
not get fixed in that short timeframe.

[Qemu-devel] [PATCH 7/7] usb-uvc: Use qemu_malloc()

[Brad Hards]

As requested by Blue Swirl (2010-06-10)

Signed-off-by: Brad Hards 
---
 hw/usb-uvc.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/usb-uvc.c b/hw/usb-uvc.c
index 1e3d339..d1e71f8 100644
--- a/hw/usb-uvc.c
+++ b/hw/usb-uvc.c
@@ -1025,7 +1025,7 @@ static int usb_uvc_initfn(USBDevice *dev)
 DPRINTF("Maximum image size: %d bytes.\n", frame_max_length);
 
 DPRINTF("Allocating memory for frames.\n");
-frame = malloc(frame_max_length);
+frame = qemu_malloc(frame_max_length);
 frame_start = frame;
 
 frame_id = 1;
-- 
1.7.4.1

qemu-devel@nongnu.org

[Brad Hards]

As requested by Blue Swirl (2010-06-10 17:46:16)

Signed-off-by: Brad Hards 
---
 hw/usb-uvc.c |   30 +++---
 1 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/hw/usb-uvc.c b/hw/usb-uvc.c
index 5437a13..661eb1a 100644
--- a/hw/usb-uvc.c
+++ b/hw/usb-uvc.c
@@ -507,7 +507,7 @@ static int usb_uvc_handle_control(USBDevice *dev, USBPacket 
*p, int request,
 if (((index & 0xFF) == 0x01) && (((value & 0xFF00) == 0x0100) ||
 ((value & 0xFF00) == 0x0200))) {
 DPRINTF("USB Request: Get video control minimum setting "
-"attribute for interface %d\n", index&0xFF);
+"attribute for interface %d\n", index & 0xFF);
 
 if (length != 26) {
 DPRINTF("USB Request: Requested %d bytes, expected 26 "
@@ -542,7 +542,8 @@ static int usb_uvc_handle_control(USBDevice *dev, USBPacket 
*p, int request,
 data[24] = 0x00;
 data[25] = 0x00;
 ret = 26;
-} else if ((index&0xFF00) == 0x0400 && (value&0xFF00) == 0x0100) {
+} else if (((index & 0xFF00) == 0x0400) &&
+   ((value & 0xFF00) == 0x0100)) {
 /* Setting input */
 DPRINTF("USB Request: Asking for minimum input\n");
 if (length != 1) {
@@ -553,7 +554,8 @@ static int usb_uvc_handle_control(USBDevice *dev, USBPacket 
*p, int request,
 
 data[0] = 0;
 ret = 1;
-} else if ((index&0xFF00) == 0x0500 && (value&0xFF00) == 0x0200) {
+} else if (((index & 0xFF00) == 0x0500) &&
+   ((value & 0xFF00) == 0x0200)) {
 /* PU_BRIGHTNESS_CONTROL of PROCESSING_UNIT */
 DPRINTF("USB Request: Asking for minimum brightness\n");
 if (length != 2) {
@@ -571,7 +573,7 @@ static int usb_uvc_handle_control(USBDevice *dev, USBPacket 
*p, int request,
 break;
 case UVCGetVideoControl | USB_UVC_GET_MAX:
 if (((index & 0xFF) == 0x01) && (((value & 0xFF00) == 0x0100) ||
-((value & 0xFF00) == 0x0200))) {
+ ((value & 0xFF00) == 0x0200))) {
 DPRINTF("USB Request: Get video control maximum setting "
 "attribute for interface %d\n", index & 0xFF);
 
@@ -620,7 +622,8 @@ static int usb_uvc_handle_control(USBDevice *dev, USBPacket 
*p, int request,
 
 data[0] = 1;
 ret = 1;
-} else if ((index&0xFF00) == 0x0500 && (value&0xFF00) == 0x0200) {
+} else if (((index & 0xFF00) == 0x0500) &&
+   ((value & 0xFF00) == 0x0200)) {
 /* PU_BRIGHTNESS_CONTROL of PROCESSING_UNIT */
 DPRINTF("USB Request: Asking for maximum brightness\n");
 if (length != 2) {
@@ -640,7 +643,7 @@ static int usb_uvc_handle_control(USBDevice *dev, USBPacket 
*p, int request,
 if (((index & 0xFF) == 0x01) &&
 ((value & 0xFF00) == 0x0100 || (value & 0xFF00) == 0x0200)) {
 DPRINTF("USB Request: Get video control default setting "
-"attribute for interface %d\n", index&0xFF);
+"attribute for interface %d\n", index & 0xFF);
 
 if (length != 26) {
 DPRINTF("USB Request: Requested %d bytes, expected 26 "
@@ -675,7 +678,8 @@ static int usb_uvc_handle_control(USBDevice *dev, USBPacket 
*p, int request,
 data[24] = 0x00;
 data[25] = 0x00;
 ret = 26;
-} else if ((index&0xFF00) == 0x0400 && (value&0xFF00) == 0x0100) {
+} else if (((index & 0xFF00) == 0x0400) &&
+   ((value & 0xFF00) == 0x0100)) {
 /* Setting input */
 DPRINTF("USB Request: Asking for default input\n");
 if (length != 1) {
@@ -686,7 +690,8 @@ static int usb_uvc_handle_control(USBDevice *dev, USBPacket 
*p, int request,
 
 data[0] = 0;
 ret = 1;
-} else if ((index&0xFF00) == 0x0500 && (value&0xFF00) == 0x0200) {
+} else if (((index & 0xFF00) == 0x0500) &&
+   ((value & 0xFF00) == 0x0200)) {
 /* PU_BRIGHTNESS_CONTROL of PROCESSING_UNIT */
 DPRINTF("USB Request: Asking for default brightness\n");
 if (length != 2) {
@@ -741,7 +746,8 @@ static int usb_uvc_handle_control(USBDevice *dev, USBPacket 
*p, int request,
 first_bulk_packet = 1;
 
 ret = 26;
-} else if ((index&0xFF00) == 0x0400 && (value&

[Qemu-devel] [PATCH 6/7] usb-uvc: Fix a couple of typos

[Brad Hards]

Signed-off-by: Brad Hards 
---
 hw/usb-uvc.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/usb-uvc.c b/hw/usb-uvc.c
index 661eb1a..1e3d339 100644
--- a/hw/usb-uvc.c
+++ b/hw/usb-uvc.c
@@ -893,7 +893,7 @@ static int usb_uvc_initfn(USBDevice *dev)
 error_report("V4L2 device specification needed.\n");
 return -1;
 } else {
-DPRINTF("Trying to open %s\n.", s->v4l2_device);
+DPRINTF("Trying to open %s.\n", s->v4l2_device);
 }
 
 v4l2_fd = open(s->v4l2_device, O_RDWR);
@@ -1042,7 +1042,7 @@ static USBDevice *usb_uvc_init(const char *filename)
 dev = usb_create(NULL /* FIXME */, "usb-uvc-webcam");
 qdev_init_nofail(&dev->qdev);
 
-DPRINTF("Filename: %s\n.", filename);
+DPRINTF("Filename: %s.\n", filename);
 
 if (!*filename) {
 error_report("character device specification needed");
-- 
1.7.4.1

[Qemu-devel] [PATCH 4/7] usb-uvc: fix some spelling issues.

[Brad Hards]

Signed-off-by: Brad Hards 
---
 hw/usb-uvc.c |   10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/hw/usb-uvc.c b/hw/usb-uvc.c
index 20ac23e..5437a13 100644
--- a/hw/usb-uvc.c
+++ b/hw/usb-uvc.c
@@ -487,7 +487,7 @@ static int usb_uvc_handle_control(USBDevice *dev, USBPacket 
*p, int request,
 } else if (((index & 0xFF00) == 0x0500) &&
 ((value & 0xFF00) == 0x0200)) {
 /* PU_BRIGHTNESS_CONTROL of PROCESSING_UNIT */
-DPRINTF("USB Resquest: Asking for current brightness\n");
+DPRINTF("USB Request: Asking for current brightness\n");
 if (length != 2) {
 DPRINTF("USB Request: Requested %d bytes, expected 2 "
 "bytes\n", length);
@@ -555,7 +555,7 @@ static int usb_uvc_handle_control(USBDevice *dev, USBPacket 
*p, int request,
 ret = 1;
 } else if ((index&0xFF00) == 0x0500 && (value&0xFF00) == 0x0200) {
 /* PU_BRIGHTNESS_CONTROL of PROCESSING_UNIT */
-DPRINTF("USB Resquest: Asking for minimum brightness\n");
+DPRINTF("USB Request: Asking for minimum brightness\n");
 if (length != 2) {
 DPRINTF("USB Request: Requested %d bytes, expected 2 "
 "bytes\n", length);
@@ -622,7 +622,7 @@ static int usb_uvc_handle_control(USBDevice *dev, USBPacket 
*p, int request,
 ret = 1;
 } else if ((index&0xFF00) == 0x0500 && (value&0xFF00) == 0x0200) {
 /* PU_BRIGHTNESS_CONTROL of PROCESSING_UNIT */
-DPRINTF("USB Resquest: Asking for maximum brightness\n");
+DPRINTF("USB Request: Asking for maximum brightness\n");
 if (length != 2) {
 DPRINTF("USB Request: Requested %d bytes, expected 2 "
 "bytes\n", length);
@@ -688,7 +688,7 @@ static int usb_uvc_handle_control(USBDevice *dev, USBPacket 
*p, int request,
 ret = 1;
 } else if ((index&0xFF00) == 0x0500 && (value&0xFF00) == 0x0200) {
 /* PU_BRIGHTNESS_CONTROL of PROCESSING_UNIT */
-DPRINTF("USB Resquest: Asking for default brightness\n");
+DPRINTF("USB Request: Asking for default brightness\n");
 if (length != 2) {
 DPRINTF("USB Request: Requested %d bytes, expected 2 "
 "bytes\n", length);
@@ -770,7 +770,7 @@ static int usb_uvc_handle_control(USBDevice *dev, USBPacket 
*p, int request,
 case UVCGetVideoControl | USB_UVC_GET_RES:
 if ((index&0xFF00) == 0x0500 && (value&0xFF00) == 0x0200) {
 /* PU_BRIGHTNESS_CONTROL of PROCESSING_UNIT */
-DPRINTF("USB Resquest: Asking for brightness resolution\n");
+DPRINTF("USB Request: Asking for brightness resolution\n");
 if (length != 2) {
 DPRINTF("USB Request: Requested %d bytes, "
 "expected 2 bytes\n", length);
-- 
1.7.4.1

[Qemu-devel] [PATCH 1/7] usb: Turn off debug output by default.

[Brad Hards]

Addresses comment by Blue Swirl (2010-06-10 17:46:16)

Signed-off-by: Brad Hards 
---
 hw/usb-uvc.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/usb-uvc.c b/hw/usb-uvc.c
index b711f51..e88ee00 100644
--- a/hw/usb-uvc.c
+++ b/hw/usb-uvc.c
@@ -31,7 +31,7 @@
 #include 
 #include 
 
-#define DEBUG_UVC
+// #define DEBUG_UVC
 
 #ifdef DEBUG_UVC
 #define DPRINTF(fmt, ...) \
-- 
1.7.4.1

[Qemu-devel] [0/7] USB UVC updates

[Brad Hards]

Hi Natalia,

As you suggested, I've stopped my nonsense and worked from your
UVC patches (http://patchwork.ozlabs.org/patch/55001 and
http://patchwork.ozlabs.org/patch/55000). These changes
are relative to your patches (applied on top of trunk).

I've mostly just incorporated some changes requested by Blue
Swirl in his review. Fixing the checkpatch stuff changed a lot
of whitespace (tab -> spaces), so I'd like to make sure this is
OK before making more changes.

The next change I propose to make is to rework the descriptors
and add constants / defines for magic numbers.

[Qemu-devel] [PATCH 2/7] usb-uvc: compile fix

[Brad Hards]

Looks like function signature changed.

Signed-off-by: Brad Hards 
---
 hw/usb-uvc.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/hw/usb-uvc.c b/hw/usb-uvc.c
index e88ee00..c9c8f77 100644
--- a/hw/usb-uvc.c
+++ b/hw/usb-uvc.c
@@ -307,8 +307,9 @@ static void usb_uvc_handle_reset(USBDevice *dev)
DPRINTF("Reset called\n");
 }
 
-static int usb_uvc_handle_control(USBDevice *dev, int request, int value,
- int index, 
int length, uint8_t *data)
+static int usb_uvc_handle_control(USBDevice *dev, USBPacket *p, int request,
+  int value, int index, int length,
+  uint8_t *data)
 {
int ret = 0;
USBUVCState *s = (USBUVCState *)dev;
-- 
1.7.4.1

[Qemu-devel] [PATCH 1/3] usb: Add defines for USB Serial Bus Release Number register

[Brad Hards]

Signed-off-by: Brad Hards 
---
 hw/usb.h |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/hw/usb.h b/hw/usb.h
index 9882400..2c051b3 100644
--- a/hw/usb.h
+++ b/hw/usb.h
@@ -26,6 +26,12 @@
 #include "qdev.h"
 #include "qemu-queue.h"
 
+/* Constants related to the USB / PCI interaction */
+#define USB_SBRN0x60 /* Serial Bus Release Number Register */
+#define USB_RELEASE_1  0x10 /* USB 1.0 */
+#define USB_RELEASE_2  0x20 /* USB 2.0 */
+#define USB_RELEASE_3  0x30 /* USB 3.0 */
+
 #define USB_TOKEN_SETUP 0x2d
 #define USB_TOKEN_IN0x69 /* device -> host */
 #define USB_TOKEN_OUT   0xe1 /* host -> device */
-- 
1.7.4.1

[Qemu-devel] [0/3] usb: use defines instead of magic numbers for USB serial bus release number

[Brad Hards]

There is some commonality between the UHCI and EHCI (and xHCI, future) drivers. 
So
we can make nice defines instead of magic numbers.
 usb-ehci.c |2 +-
 usb-uhci.c |2 +-
 usb.h  |6 ++
 3 files changed, 8 insertions(+), 2 deletions(-)

[Qemu-devel] [PATCH 3/3] usb: Use defines for serial bus release number register for EHCI

[Brad Hards]

Signed-off-by: Brad Hards 
---
 hw/usb-ehci.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/usb-ehci.c b/hw/usb-ehci.c
index f63519e..81b9d0b 100644
--- a/hw/usb-ehci.c
+++ b/hw/usb-ehci.c
@@ -1970,7 +1970,7 @@ static int usb_ehci_initfn(PCIDevice *dev)
 
 // pci_conf[0x50] = 0x01; // power management caps
 
-pci_set_byte(&pci_conf[0x60], 0x20);  // spec release number (2.1.4)
+pci_set_byte(&pci_conf[USB_SBRN], USB_RELEASE_2); // release number (2.1.4)
 pci_set_byte(&pci_conf[0x61], 0x20);  // frame length adjustment (2.1.5)
 pci_set_word(&pci_conf[0x62], 0x00);  // port wake up capability (2.1.6)
 
-- 
1.7.4.1

Re: [Qemu-devel] [PATCH 5/5] QMP: add server mode to QEMUMonitorProtocol

[Brad Hards]

On Thu, 2 Jun 2011 01:54:05 AM Luiz Capitulino wrote:
> QEMU supports socket chardevs that establish connections like a server
> or a client. 
Is this protocol documented anywhere?

Brad

[Qemu-devel] [PATCH 2/3] usb: Use defines for serial bus release number register for UHCI

[Brad Hards]

Signed-off-by: Brad Hards 
---
 hw/usb-uhci.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/usb-uhci.c b/hw/usb-uhci.c
index c0de05b..d9c86ad 100644
--- a/hw/usb-uhci.c
+++ b/hw/usb-uhci.c
@@ -1098,7 +1098,7 @@ static int usb_uhci_common_initfn(UHCIState *s)
 pci_config_set_class(pci_conf, PCI_CLASS_SERIAL_USB);
 /* TODO: reset value should be 0. */
 pci_conf[PCI_INTERRUPT_PIN] = 4; // interrupt pin 3
-pci_conf[0x60] = 0x10; // release number
+pci_conf[USB_SBRN] = USB_RELEASE_1; // release number
 
 usb_bus_new(&s->bus, &s->dev.qdev);
 for(i = 0; i < NB_PORTS; i++) {
-- 
1.7.4.1

Re: [Qemu-devel] Webcams under KVM and Linux

[Brad Hards]

On Tue, 31 May 2011 09:39:02 AM Natalia Portillo wrote:
> > Natalia: if possible, could you provide an overview of your work in this
> > area?
> 
> The best should be for you to check for the patches I sent (june 2010 on
> the ML) and enhance what is left to be done.
Sorry I wasn't clear. I'll try to ask more direct questions:
1. Are you still working in this area?

2. Do you have changes on top of the June 2010 set?

3. Would you like to review incremental patches relative to your changes, or 
should I just work independently? That is, do I send the changes to you or to 
Gerd?

> Reinventing the wheel is non-sense.
Thanks for the support :-(

Brad

Re: [Qemu-devel] Webcams under KVM and Linux

[Brad Hards]

On Mon, 30 May 2011 08:38:35 pm Gerd Hoffmann wrote:
> I think people are also working on camera emulation, i.e. pass any (even
> non-usb) v4l devices as usb webcam to the guest.  No idea what the
> status here is.
I have it in early development. Its far from complete - just enough for the 
software (e.g. cheese or uvcview on the guest) to believe that there really is 
a UVC device there and try to open it.

I wasn't planning on being able to connect any V4L(2) device to the emulation. 
I was thinking more along the lines of a gstreamer output, or a fixed image, or 
a test pattern.

Natalia: if possible, could you provide an overview of your work in this area?

Brad

Re: [Qemu-devel] The process of kernel cross-compiling in arm-test-0.2.tar.gz

[Brad Hards]

On Monday 23 May 2011 19:26:45 daixiaoke wrote:
> 3.Compiled uClinux following steps in the attachment(Chapter 4: Building
> the uClinux image). “STM3210E-EVAL-jffs” was selected for "Porduct" while
> Configure uClinux for STM3210E-EVAL.
So you have built the images to install into a STM3210E board.

> 5.Executed following command on command line:
>   qemu-system-arm -kernel xipImage.bin -initrd rootfs.img.bin -nographic
> -append "console=ttyAMA0" But it didn't work and nothing was shown out on
> the command line.
I think this is the problem: qemu-system-arm isn't emulating an STM3210E 
board. The default machine type with qemu-system-arm is the "integratorcp" 
(ARM Integrator/CP (ARM926EJ-S) board). See qemu-system-arm -M ? for a full 
list of options.

You have to build code that matches the environment you are going to run it 
in. 

Brad

[Qemu-devel] [Bug 618533] Re: OpenSolaris guest fails to see the Solaris partitions of a physical disk in qemu-kvm-9999 (GIT)

[Brad Hards]

Did this change get submitted? Is it still an issue?

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/618533

Title:
  OpenSolaris guest fails to see the Solaris partitions of a physical
  disk in qemu-kvm- (GIT)

Status in QEMU:
  New

Bug description:
  # qemu-kvm --version
  QEMU emulator version 0.13.50 (qemu-kvm-devel), Copyright (c) 2003-2008 
Fabrice Bellard

  The following disk is presented to guest as IDE disk with /dev/sdd as
  path.

  # fdisk -l /dev/sdd

  Disk /dev/sdd: 750.2 GB, 750156374016 bytes
  255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors
  Units = sectors of 1 * 512 = 512 bytes
  Sector size (logical/physical): 512 bytes / 512 bytes
  I/O size (minimum/optimal): 512 bytes / 512 bytes
  Disk identifier: 0x7f3a03aa

 Device Boot  Start End  Blocks   Id  System
  /dev/sdd1  63 7887914 3943926   1b  Hidden W95 FAT32
  /dev/sdd2 7887915   980736119   486424102+  83  Linux
  /dev/sdd3   *   980736120  108315049451207187+  bf  Solaris
  /dev/sdd4  1083150495  1465144064   1909967855  Extended
  /dev/sdd5  1083150558  110774600912297726   83  Linux
  /dev/sdd6  1107746073  1465144064   1786989967  HPFS/NTFS

  The prtvtoc output is attached from both VirtualBox and Qemu-KVM. As
  can be seen in the screenshots, a valid Solaris partition table (which
  is inside the /dev/sdd3, marked 'bf' in Linux fdisk output) is not
  seen in Qemu but seen in Virtualbox.

  This makes the guest unbootable in Qemu because the root FS is not
  found but its bootable in Virtualbox.

Re: [Qemu-devel] mouse doesn't work on guest OS

[Brad Hards]

On Sat, 21 May 2011 09:43:57 pm Amirali Shambayati wrote:
> Hi Brad,
Hi.
Please don't "top post" (google for this if you don't understand it).

> Qemu starts, kernel boots and ubuntu's GUI boots. I use "dmesg" in
> terminal to see printks which I have put in kernel code. 
When I wrote "Does it show up in dmesg or /proc?", I meant "Does the mouse 
connection show up in dmesg output" and "Do you see the mouse in 
/proc/bus/input/devices?"

> My problem is
> that, mouse is hanged in the middle of the screen.
I still don't understand the problem. I'm guessing you see the cursor in the 
guest, but the host mouse isn't having any effect on that guest cursor.

> I need mouse to
> connect to Internet!! if anyway exists to make Internet connection
> using terminal, I won't need mouse anymore!
I don't understand what you are doing with the mouse, but there are various 
command line tools (dhclient, ifconfig, etc) that you may be able to use in the 
client. These are nothing to do with qemu though.

> I'm newbie with kernel debugging and using qemu. Your help will be so
> valuable for me.
A clear, explicit problem description will make this a lot easier. 

You still haven't answered all of my questions, and you still haven't 
described what you've done to try to debug this problem.

 
> On Sat, May 21, 2011 at 5:44 AM, Brad Hards  wrote:
> > On Friday 20 May 2011 23:59:25 Amirali Shambayati wrote:
> >> Mouse doesn't work on guest ubuntu.
> > 
> > You need to debug it, as if it was real hardware.
> > 
> >> But none of them worked for me. any help is appreciated.
> > 
> > This isn't a very in-depth problem description. Remember that we can't
> > see your screen.
> > 
> > Does qemu not start? Does the kernel not boot? Does it show up in dmesg
> > or /proc? Does it work in text mode but not in X (or vice versa)? Does
> > it work if you use the -device (qdev) approach instead? Does it work if
> > you use the monitor console to "hotplug" the mouse after boot instead of
> > on the command line?
> > 
> > Basically, you need to tell us what debugging you've done, and the
> > results of each part of that debugging.
> > 
> > It might also help to know which version of qemu you are using.
> > 
> > Brad

Re: [Qemu-devel] mouse doesn't work on guest OS

[Brad Hards]

On Friday 20 May 2011 23:59:25 Amirali Shambayati wrote:
> Mouse doesn't work on guest ubuntu.
You need to debug it, as if it was real hardware.

> But none of them worked for me. any help is appreciated.
This isn't a very in-depth problem description. Remember that we can't see 
your screen.

Does qemu not start? Does the kernel not boot? Does it show up in dmesg or 
/proc? Does it work in text mode but not in X (or vice versa)? Does it work if 
you use the -device (qdev) approach instead? Does it work if you use the 
monitor console to "hotplug" the mouse after boot instead of on the command 
line?

Basically, you need to tell us what debugging you've done, and the results of 
each part of that debugging.

It might also help to know which version of qemu you are using.

Brad

Re: [Qemu-devel] [PATCH v2] Add an isa device for SGA

[Brad Hards]

On Thu, 12 May 2011 10:55:13 pm Glauber Costa wrote:
> This patch adds a dummy legacy ISA device whose responsibility is to
> deploy sgabios, an option rom for a serial graphics adapter.
> The proposal is that this device is always-on when -nographics,
> but can otherwise be enable in any setup when -device sga is used.
Perhaps could use documentation changes, especially a reference to the 
location for the ROM image (given that came up as a question on the original 
patch series)

Brad

Re: [Qemu-devel] -net interface association behavior change in current -git.

[Brad Hards]

On Fri, 13 May 2011 03:19:42 AM Vincent Palatin wrote:
> > Does the kernel need some sort of vlan support compiled into it for this
> > to work, or can the kernel not care?
> 
> You don't need anything in your kernel, this is for Qemu network layer
> configuration.
Just to explain a bit further: qemu "vlan" is not related to 803.1q vlan 
tagging. vlan is virtual lan in the sense of a virtual machine - something 
we're emulating in qemu.

Brad
 

Re: [Qemu-devel] [PATCH 0/2] usb-linux: physical port handling.

[Brad Hards]

On Tuesday 10 May 2011 12:30:41 Gerd Hoffmann wrote:
>   Hi,
> 
> These patches fix and improve the physical port handling in the usb host
> driver.  Passthrough of devices connected via usb hub should work better
> now.  Also you can specify usb devices for passthrough by physical port
> (on the host) now.
> 
> please review,
>   Gerd
> 
> Gerd Hoffmann (2):
>   usb-linux: fix device path aka physical port handling
>   usb-linux: add hostport property
> 
>  usb-linux.c |   47 +++
>  1 files changed, 27 insertions(+), 20 deletions(-)
Some additional docs (based on 2/2 hints) might be a useful addition.
Possible candidates:
- docs/qdev-device-use.txt
- qemu-doc.texi

Brad

Re: [Qemu-devel] [PATCH 1/2] Add documentation for qemu_progres_print()

[Brad Hards]

On Fri, 6 May 2011 07:39:10 PM jes.soren...@redhat.com wrote:
> +/*
> + * Add delta to current state, and print the output if the current
> + * state has progressed more than min_skip since the last value was
> + * printed. 'max' specifies the relative percentage, ie. a function
> + * can count for 30% of the total work, and still count from 0-100, by
> + * setting max to 30. If max is set to zero, the percent argument
> + * becomes an absolute value for current state.
> + */
>  void qemu_progress_print(float percent, int max)
I hate to critique anyone adding docs, but this makes no sense at all to me 
without reading the code. Is "percent" the amount we are adding (i.e. the 
delta) or the result (i.e. absolute progress)? Or does it vary according to 
the value of max?

Brad

Re: [Qemu-devel] [PATCH] doc: Add explanation that -alt-grab and -ctrl-grab affect special keys

[Brad Hards]

ping?

Re: [Qemu-devel] [PATCH] monitor: avoid moving cursor during "mouse_button" command

[Brad Hards]

On Thursday 28 April 2011 20:46:25 Gerd Hoffmann wrote:
> I think it would be much better to keep track of the mouse position (and
> button state while being at it) in input.c instead of monitor.c.
> 
> Once this is in place it should be easy to add kbd_mouse_* functions
> which update position or buttons only, which the monitor code can use
> then to avoid the unwanted pointer warp.
This turns out to be a bit more difficult than we discussed.

The new functions work well for the monitor code side (not unexpected, since 
its essentially the same as the original code I proposed for monitor-only 
changes).

The problem is that almost all input code (in absolute mode) keeps track of 
the position itself - monitor was the exception.

So a sequence like the following:
1. Move cursor in SDL
2. Use mouse_move in monitor
3. Use mouse_button 2 in monitor
4. Click mouse in SDL
works ok up to step 3, but step 4 causes the pointer to warp back to where it 
was at the end of step 1.

So it looks like we'd have to modify all callers of kbd_mouse_event(), and the 
code paths are already a bit convoluted. As discussed on IRC, I'm a bit 
concerned about testing cocoa and spice.

Thoughts?

Brad

[Qemu-devel] [PATCH] doc: Add explanation that -alt-grab and -ctrl-grab affect special keys

[Brad Hards]

Phillip Merensky reported that the special keys (e.g. Ctrl-Alt-f for full
screen) did not work correctly if -alt-grab is used.

BUG: 696530

Review of ui/sdl.c:sdl_refresh indicates that this is the intended behaviour,
so we should update the documentation to match the actual behaviour, as
suggested by Phillip in the bug report.

Signed-off-by: Brad Hards 
---
 qemu-doc.texi   |6 +-
 qemu-options.hx |6 --
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/qemu-doc.texi b/qemu-doc.texi
index 86e017c..d96a6ab 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -278,7 +278,11 @@ targets do not need a disk image.
 
 @c man begin OPTIONS
 
-During the graphical emulation, you can use the following keys:
+During the graphical emulation, you can use special key combinations to change
+modes. The default key mappings are shown below, but if you use 
@code{-alt-grab}
+then the modifier is Ctrl-Alt-Shift (instead of Ctrl-Alt) and if you use 
+@code{-ctrl-grab} then the modifier is the right Ctrl key (instead of 
Ctrl-Alt):
+
 @table @key
 @item Ctrl-Alt-f
 @kindex Ctrl-Alt-f
diff --git a/qemu-options.hx b/qemu-options.hx
index 489df10..8d83aa1 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -662,7 +662,8 @@ DEF("alt-grab", 0, QEMU_OPTION_alt_grab,
 STEXI
 @item -alt-grab
 @findex -alt-grab
-Use Ctrl-Alt-Shift to grab mouse (instead of Ctrl-Alt).
+Use Ctrl-Alt-Shift to grab mouse (instead of Ctrl-Alt). Note that this also
+affects the special keys (for fullscreen, monitor-mode switching, etc).
 ETEXI
 
 DEF("ctrl-grab", 0, QEMU_OPTION_ctrl_grab,
@@ -671,7 +672,8 @@ DEF("ctrl-grab", 0, QEMU_OPTION_ctrl_grab,
 STEXI
 @item -ctrl-grab
 @findex -ctrl-grab
-Use Right-Ctrl to grab mouse (instead of Ctrl-Alt).
+Use Right-Ctrl to grab mouse (instead of Ctrl-Alt). Note that this also
+affects the special keys (for fullscreen, monitor-mode switching, etc).
 ETEXI
 
 DEF("no-quit", 0, QEMU_OPTION_no_quit,
-- 
1.7.1

[Qemu-devel] [Bug 568614] Re: x86_64 host curses interface: spacing/garbling

[Brad Hards]

Hi Devin,

Can you test if this bug still exists with 0.14 (or better still, a git
build)?

Brad

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/568614

Title:
  x86_64 host curses interface: spacing/garbling

Status in QEMU:
  In Progress

Bug description:
  Environment:
  Arch Linux x86_64, kernel 2.6.33, qemu 0.12.3

  Steps to reproduce:
  1. Have a host system running 64-bit Linux.
  2. Start a qemu VM with the -curses flag.

  Expected results:
  Text displayed looks as it would on a real text-mode display, and VM is 
therefore usable.

  Actual results:
  Text displayed contains an extra space between characters, causing text to 
flow off the right and bottom sides of the screen. This makes the curses 
interface unintelligible.

  The attached patch fixes this problem on 0.12.3 on my installation
  without changing behavior on a 32-bit machine.  I don't know enough of
  the semantics of console_ch_t to know if this is the "correct" fix or
  if there should be, say, an extra cast somewhere instead.

[Qemu-devel] [Bug 705931] Re: make ui sdl error 1 on git devel

[Brad Hards]

Hi,

Thanks for reporting this issue. I'm not able to repeat the problem
(although I have no slackware), and the bug does look strange.

Can you update (git pull) and try again?

Can you confirm that you are using git://git.qemu.org/qemu.git?

If it still fails, can you look at the problem file (ui/sdl.c) and see
if it looks complete? For me, this file has 895 lines (last line is
blank, line 894 has the closing braces).

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/705931

Title:
  make ui sdl error 1 on git devel

Status in QEMU:
  New

Bug description:
  after clone git devel, try compile on slackware 13.1 32 bit machine
  got error:

  ui/sdl.c:809:1: error: expected '=', ',', ';', 'asm' or '__attribute__' 
before '{' token
  ui/sdl.c:815:36: error: expected ')' before '*' token
  /usr/include/X11/Xlib.h:3575:14: error: old-style parameter declarations in 
prototyped function definition
  /usr/include/X11/Xlib.h:3576:5: error: parameter name omitted
  ui/sdl.c:883:1: error: expected '{' at end of input
  ui/sdl.c:883:1: error: control reaches end of non-void function
  make: *** [ui/sdl.o] Error 1

  
  root@darkstar:/usr/src/qemu/qemu# gcc -v
  Reading specs from /usr/lib/gcc/i486-slackware-linux/4.5.1/specs
  COLLECT_GCC=gcc
  COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i486-slackware-linux/4.5.1/lto-wrapper
  Target: i486-slackware-linux
  Configured with: ../gcc-4.5.1/configure --prefix=/usr --libdir=/usr/lib 
--mandir=/usr/man --infodir=/usr/info --enable-shared --enable-bootstrap 
--enable-languages=ada,c,c++,fortran,java,objc,lto --enable-threads=posix 
--enable-checking=release --with-system-zlib 
--with-python-dir=/lib/python2.6/site-packages --disable-libunwind-exceptions 
--enable-__cxa_atexit --enable-libssp --enable-lto --with-gnu-ld --verbose 
--with-arch=i486 --target=i486-slackware-linux --build=i486-slackware-linux 
--host=i486-slackware-linux
  Thread model: posix
  gcc version 4.5.1 (GCC) 

  
  root@darkstar:/usr/src/qemu/qemu# uname -a
  Linux darkstar 2.6.35.7-smp #2 SMP Mon Oct 11 14:52:09 CDT 2010 i686 Intel(R) 
Core(TM)2 Duo CPU T7100  @ 1.80GHz GenuineIntel GNU/Linux
  root@darkstar:/usr/src/qemu/qemu# cat /etc/slackware-version 
  Slackware 13.1.0

  thanks

[Qemu-devel] [Bug 696530] Re: qemu-0.13.0-r2 special keys different when using -alt-grab

[Brad Hards]

Hi,

Thanks for reporting this issue - sorry it takes a while to get these
addressed.

I've looked at the code, and the modifiers are handled specially
depending on the command line option, so I think it is the intended
behaviour. I've update the docs (and submitted a patch) to make it
clearer.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/696530

Title:
  qemu-0.13.0-r2 special keys different when using -alt-grab

Status in QEMU:
  New

Bug description:
  I use -alt-grab with qemu-0.13.0-r2 and special keys like Ctrl-Alt-f
  for full screen did not work for me with a windows guest. They work
  normally when omitting the -alt-grab startup parameter.

  After quite a long time, I found out that I have to add the shift key
  to the keys from the documentation when I use the -alt-grab option.

  Probably -ctrl-grab behaves similarly. It would be really nice to have
  this documented in the default documentation in the man page as has
  not been documented there yet.

Re: [Qemu-devel] [PATCH 4/6] docs/tracing.txt: minor documentation fixes

[Brad Hards]

On Tue, 26 Apr 2011 10:26:01 pm Stefan Hajnoczi wrote:
> -There is a set of static trace events declared in the trace-events source
> +There is a set of static trace events declared in the "trace-events"
> source
Would it read better if it said "There are a set..." (i.e. "are" instead of 
"is")?

Brad

[Qemu-devel] [RFC] Removing old command line options

[Brad Hards]

I've been trying to update the documentation (currently on neworking), and one
of the things that makes it hard is that there are a few old (legacy) command
line options (e.g. --tftp).

Removing them is easy, but not really nice to users who depend on them. So I
was thinking about a migration approach. 

I came up with two alternatives.

Simplest approach is just to add a warning for the next release, and remove
the option in the next+1 release.

diff --git a/vl.c b/vl.c
index 68c3b53..a972712 100644
--- a/vl.c
+++ b/vl.c
@@ -1941,6 +1941,13 @@ static const QEMUOption *lookup_opt(int argc, char 
**argv,
 return popt;
 }  





+static void display_legacy_warning(const char *option_name)


+{  


+fprintf(stderr, "%s is a legacy option, which will be removed in a future 
"   
 
+"version of QEMU. Consult the manual for replacement.\n",  


+option_name);
+}
+
 int main(int argc, char **argv, char **envp)
 {
 const char *gdbstub_dev = NULL;
@@ -2277,12 +2284,15 @@ int main(int argc, char **argv, char **envp)
 break;
 #ifdef CONFIG_SLIRP
 case QEMU_OPTION_tftp:
+display_legacy_warning("--tftp");
 legacy_tftp_prefix = optarg;
 break;
 case QEMU_OPTION_bootp:
+display_legacy_warning("--bootp");
 legacy_bootp_filename = optarg;
 break;
 case QEMU_OPTION_redir:
+display_legacy_warning("--redir");
 if (net_slirp_redir(optarg) < 0)
 exit(1);
 break;


The other alternative is to add an intermediate state, so its a warning
in the next release, and requires an --enable-legacy-options command
line argument to get it back in next+1. Then its gone in next+2.

Thoughts? Comments?

Brad

Re: [Qemu-devel] [PATCH 4/4] usb: use DPRINTF instead of printf for some simple cases

[Brad Hards]

On Thursday 14 April 2011 08:01:43 Brad Hards wrote:
> On Wed, 13 Apr 2011 10:52:37 pm Hans de Goede wrote:
> > > @@ -359,7 +359,7 @@ static int usb_host_claim_interfaces(USBHostDevice
> > > *dev, int configuration)
> > > 
> > >   ret = ioctl(dev->fd, USBDEVFS_CLAIMINTERFACE,&interface);
> > >   if (ret<  0) {
> > >   
> > >   if (errno == EBUSY) {
> > > 
> > > -printf("husb: update iface. device already
> > > grabbed\n"); +DPRINTF("husb: update iface. device
> > > already grabbed\n");
> > > 
> > >   } else {
> > >   
> > >   perror("husb: failed to claim interface");
> > >   
> > >   }
> > 
> > Nack, this is an error condition, so it should not be a DPRINTF.
> 
> Then should it go to stderr instead of stdout?
> 
> (There are other places in this code where we use fprintf(stderr, ...) to
> indicate error conditions.)
ping?

Brad

[Qemu-devel] [PATCH] doc: fix slirp description

[Brad Hards]

net/slirp.c says:
/* default settings according to historic slirp */
struct in_addr net  = { .s_addr = htonl(0x0a000200) }; /* 10.0.2.0 */
struct in_addr mask = { .s_addr = htonl(0xff00) }; /* 255.255.255.0 */
struct in_addr host = { .s_addr = htonl(0x0a000202) }; /* 10.0.2.2 */
struct in_addr dhcp = { .s_addr = htonl(0x0a00020f) }; /* 10.0.2.15 */
struct in_addr dns  = { .s_addr = htonl(0x0a000203) }; /* 10.0.2.3 */

Which I think is not what the documentation says.

Signed-off-by: Brad Hards 
---
 qemu-options.hx |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/qemu-options.hx b/qemu-options.hx
index 677c550..489df10 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1152,7 +1152,7 @@ Assign symbolic name for use in monitor commands.
 @item net=@var{addr}[/@var{mask}]
 Set IP network address the guest will see. Optionally specify the netmask,
 either in the form a.b.c.d or as number of valid top-most bits. Default is
-10.0.2.0/8.
+10.0.2.0/24.
 
 @item host=@var{addr}
 Specify the guest-visible address of the host. Default is the 2nd IP in the
@@ -1168,7 +1168,7 @@ Specifies the client hostname reported by the builtin 
DHCP server.
 
 @item dhcpstart=@var{addr}
 Specify the first of the 16 IPs the built-in DHCP server can assign. Default
-is the 16th to 31st IP in the guest network, i.e. x.x.x.16 to x.x.x.31.
+is the 15th to 31st IP in the guest network, i.e. x.x.x.15 to x.x.x.31.
 
 @item dns=@var{addr}
 Specify the guest-visible address of the virtual nameserver. The address must
-- 
1.7.1

[Qemu-devel] [Bug 662461] Re: -name error message should have trailing newline

[Brad Hards]

It looks like this change (or equivalent) was applied by Aurelien Jarno
in 5697f6ae4183f3b3320a1fe677e3404a05e75783

Thanks for reporting it and providing the fix.

** Changed in: qemu
   Status: New => Fix Committed

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/662461

Title:
  -name error message should have trailing newline

Status in QEMU:
  Fix Committed

Bug description:
  Trivial, but it was triggering the OCD.

  diff --git a/vl.c b/vl.c
  index df414ef..9c76a55 100644
  --- a/vl.c
  +++ b/vl.c
  @@ -2524,7 +2524,7 @@ int main(int argc, char **argv, char **envp)
   if (p != NULL) {
  *p++ = 0;
  if (strncmp(p, "process=", 8)) {
  -   fprintf(stderr, "Unknown subargument %s to 
-name", p
  +   fprintf(stderr, "Unknown subargument %s to 
-name\n",
  exit(1);
  }
  p += 8;

[Qemu-devel] [PATCH] vl: trivial spelling fix

[Brad Hards]

Signed-off-by: Brad Hards 
---
 vl.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/vl.c b/vl.c
index 68c3b53..b46ee66 100644
--- a/vl.c
+++ b/vl.c
@@ -756,7 +756,7 @@ void add_boot_device_path(int32_t bootindex, DeviceState 
*dev,
 
 /*
  * This function returns null terminated string that consist of new line
- * separated device pathes.
+ * separated device paths.
  *
  * memory pointed by "size" is assigned total length of the array in bytes
  *
-- 
1.7.1

Re: [Qemu-devel] [PATCH] target-arm: Minimal implementation of performance counters

[Brad Hards]

On Friday 22 April 2011 19:48:09 Peter Maydell wrote:
> Looking at your .rej file it seems to have lost the hardcoded tab
> characters[*] that are in the patch; I suspect something in your mailer
> is turning them back into spaces. Try downloading the patch from
> patchwork instead.
Yep, that worked. Sorry for the noise.

Brad

Re: [Qemu-devel] [PATCH] target-arm: Minimal implementation of performance counters

[Brad Hards]

On Friday 22 April 2011 02:01:48 Peter Maydell wrote:
> Newer Linux kernels assume the existence of the performance counter
> cp15 registers. Provide a minimal implementation of these registers.
> We support no events. This should be compliant with the ARM ARM,
> except that we don't implement the cycle counter.
I tried to apply this to git master, and got a reject (attached). It looks 
like that area of target-arm/helper.c hasn't been touched in a while. Is it 
possible you have other changes for this? Did I miss a pre-requisite?

Brad



helper.c.rej
Description: application/reject

Re: [Qemu-devel] [OOT] gcc trick to help studying Qemu source

[Brad Hards]

On Tuesday 19 April 2011 19:07:39 Mulyadi Santosa wrote:
> Hopefully it's useful for everybody, especially newbie like me.
I added a note about this to the wiki. Perhaps you may like to expand / 
enhance it:
http://wiki.qemu.org/Documentation/GettingStartedDevelopers#Getting_to_know_the_code

Brad

[Qemu-devel] [PATCH] usb-uhci: Use defines for base address registers, instead of magic numbers

[Brad Hards]

Signed-off-by: Brad Hards 
---
 hw/usb-uhci.c |   58 ++--
 hw/usb.h  |6 +
 2 files changed, 41 insertions(+), 23 deletions(-)

diff --git a/hw/usb-uhci.c b/hw/usb-uhci.c
index 346db3e..210b918 100644
--- a/hw/usb-uhci.c
+++ b/hw/usb-uhci.c
@@ -75,6 +75,18 @@
 
 #define NB_PORTS 2
 
+/* address offsets for PCI config registers - UHCI 1.1d spec Table 2 */
+#define UHCI_REG_USBCMD 0x00
+#define UHCI_REG_USBSTS 0x02
+#define UHCI_REG_USBINTR0x04
+#define UHCI_REG_FRNUM  0x06
+#define UHCI_REG_FLBASEADD  0x08
+#define UHCI_REG_SOF_MOD0x0c
+#define UHCI_REG_PORTSC 0x10
+
+#define UHCI_REG_PORTSC_TOP 0x1F /* last potential Port address */
+#define UHCI_BAR_SIZE   0x20 /* the size of the base address registers */
+
 #ifdef DEBUG
 #define DPRINTF printf
 
@@ -407,7 +419,7 @@ static void uhci_ioport_writeb(void *opaque, uint32_t addr, 
uint32_t val)
 
 addr &= 0x1f;
 switch(addr) {
-case 0x0c:
+case UHCI_REG_SOF_MOD:
 s->sof_timing = val;
 break;
 }
@@ -420,7 +432,7 @@ static uint32_t uhci_ioport_readb(void *opaque, uint32_t 
addr)
 
 addr &= 0x1f;
 switch(addr) {
-case 0x0c:
+case UHCI_REG_SOF_MOD:
 val = s->sof_timing;
 break;
 default:
@@ -438,7 +450,7 @@ static void uhci_ioport_writew(void *opaque, uint32_t addr, 
uint32_t val)
 DPRINTF("uhci: writew port=0x%04x val=0x%04x\n", addr, val);
 
 switch(addr) {
-case 0x00:
+case UHCI_REG_USBCMD:
 if ((val & UHCI_CMD_RS) && !(s->cmd & UHCI_CMD_RS)) {
 /* start frame processing */
 qemu_mod_timer(s->frame_timer, qemu_get_clock_ns(vm_clock));
@@ -468,7 +480,7 @@ static void uhci_ioport_writew(void *opaque, uint32_t addr, 
uint32_t val)
 }
 s->cmd = val;
 break;
-case 0x02:
+case UHCI_REG_USBSTS:
 s->status &= ~val;
 /* XXX: the chip spec is not coherent, so we add a hidden
register to distinguish between IOC and SPD */
@@ -476,15 +488,15 @@ static void uhci_ioport_writew(void *opaque, uint32_t 
addr, uint32_t val)
 s->status2 = 0;
 uhci_update_irq(s);
 break;
-case 0x04:
+case UHCI_REG_USBINTR:
 s->intr = val;
 uhci_update_irq(s);
 break;
-case 0x06:
+case UHCI_REG_FRNUM:
 if (s->status & UHCI_STS_HCHALTED)
 s->frnum = val & 0x7ff;
 break;
-case 0x10 ... 0x1f:
+case UHCI_REG_PORTSC ... UHCI_REG_PORTSC_TOP:
 {
 UHCIPort *port;
 USBDevice *dev;
@@ -518,19 +530,19 @@ static uint32_t uhci_ioport_readw(void *opaque, uint32_t 
addr)
 
 addr &= 0x1f;
 switch(addr) {
-case 0x00:
+case UHCI_REG_USBCMD:
 val = s->cmd;
 break;
-case 0x02:
+case UHCI_REG_USBSTS:
 val = s->status;
 break;
-case 0x04:
+case UHCI_REG_USBINTR:
 val = s->intr;
 break;
-case 0x06:
+case UHCI_REG_FRNUM:
 val = s->frnum;
 break;
-case 0x10 ... 0x1f:
+case UHCI_REG_PORTSC ... UHCI_REG_PORTSC_TOP:
 {
 UHCIPort *port;
 int n;
@@ -560,7 +572,7 @@ static void uhci_ioport_writel(void *opaque, uint32_t addr, 
uint32_t val)
 DPRINTF("uhci: writel port=0x%04x val=0x%08x\n", addr, val);
 
 switch(addr) {
-case 0x08:
+case UHCI_REG_FLBASEADD:
 s->fl_base_addr = val & ~0xfff;
 break;
 }
@@ -573,7 +585,7 @@ static uint32_t uhci_ioport_readl(void *opaque, uint32_t 
addr)
 
 addr &= 0x1f;
 switch(addr) {
-case 0x08:
+case UHCI_REG_FLBASEADD:
 val = s->fl_base_addr;
 break;
 default:
@@ -1101,12 +1113,12 @@ static void uhci_map(PCIDevice *pci_dev, int region_num,
 {
 UHCIState *s = (UHCIState *)pci_dev;
 
-register_ioport_write(addr, 32, 2, uhci_ioport_writew, s);
-register_ioport_read(addr, 32, 2, uhci_ioport_readw, s);
-register_ioport_write(addr, 32, 4, uhci_ioport_writel, s);
-register_ioport_read(addr, 32, 4, uhci_ioport_readl, s);
-register_ioport_write(addr, 32, 1, uhci_ioport_writeb, s);
-register_ioport_read(addr, 32, 1, uhci_ioport_readb, s);
+register_ioport_write(addr, UHCI_BAR_SIZE, 2, uhci_ioport_writew, s);
+register_ioport_read(addr, UHCI_BAR_SIZE, 2, uhci_ioport_readw, s);
+register_ioport_write(addr, UHCI_BAR_SIZE, 4, uhci_ioport_writel, s);
+register_ioport_read(addr, UHCI_BAR_SIZE, 4, uhci_ioport_readl, s);
+register_ioport_write(addr, UHCI_BAR_SIZE, 1, uhci_ioport_writeb, s);
+register_ioport_read(addr, UHCI_BAR_SIZE, 1, uhci_ioport_readb, s);
 }
 
 static USBPortOps uhci_port_ops = {
@@ -1125,7 +1137,7 @@ static int usb_uhci_common_initfn(UHCIState *s)
 pci_config_set_class(pci_conf, PCI_CLASS_SERIAL_USB);
 /* T

Re: [Qemu-devel] Bug #757654: UHCI fails to signal stall response patch

[Brad Hards]

On Sat, 16 Apr 2011 06:57:00 am Jan Vesely wrote:
> +s->status |= UHCI_STS_USBERR;
This is per UHCI 1.1D Section 4.1.5. Looks good.

> +*int_mask |= 0x02;
> +if (td->ctrl & TD_CTRL_IOC)
> +*int_mask |= 0x01;
> +uhci_update_irq(s);
I see "A hardware interrupt is signalled to the system", but can you provide a 
little explanation of why this particular interrupt mask?

> +s->status |= UHCI_STS_USBERR;
This is per UHCI 1.1d Section 4.1.4. Looks good.

> +*int_mask |= 0x02;
> +if (td->ctrl & TD_CTRL_IOC)
> +   *int_mask |= 0x01;
> +uhci_update_irq(s);
I see "A hardware interrupt is signalled to the system", but can you provide a 
little explanation of why this particular interrupt mask?

Re: [Qemu-devel] Para-virtualized ram-based filesystem?

[Brad Hards]

On Saturday 16 April 2011 09:58:32 Ritchie, Stuart wrote:
> How does that sound?
As a general user: Confusing.

Is there a concrete example (specific applications, specific performance 
issues, 
specific requirements) that you can share?

Brad

Re: [Qemu-devel] [PATCH] Clean up after "make pdf"

[Brad Hards]

On Wednesday 13 April 2011 16:42:16 Brad Hards wrote:
> ---
>  .gitignore |3 +++
>  Makefile   |5 -
>  2 files changed, 7 insertions(+), 1 deletions(-)
Signed-off-by: Brad Hards 

Sorry about that.

Brad

Re: [Qemu-devel] [PATCH 4/4] usb: use DPRINTF instead of printf for some simple cases

[Brad Hards]

On Wed, 13 Apr 2011 10:52:37 pm Hans de Goede wrote:
> > @@ -359,7 +359,7 @@ static int usb_host_claim_interfaces(USBHostDevice
> > *dev, int configuration)
> >
> >   ret = ioctl(dev->fd, USBDEVFS_CLAIMINTERFACE,&interface);
> >   if (ret<  0) {
> >   if (errno == EBUSY) {
> >
> > -printf("husb: update iface. device already grabbed\n");
> > +DPRINTF("husb: update iface. device already grabbed\n");
> >
> >   } else {
> >   perror("husb: failed to claim interface");
> >   }
> 
> Nack, this is an error condition, so it should not be a DPRINTF.
Then should it go to stderr instead of stdout?

(There are other places in this code where we use fprintf(stderr, ...) to 
indicate error conditions.)

Brad

[Qemu-devel] [PATCH 4/4] usb: use DPRINTF instead of printf for some simple cases

[Brad Hards]

Signed-off-by: Brad Hards 
---
 usb-linux.c |   16 
 1 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/usb-linux.c b/usb-linux.c
index 1f33c2c..b02a0f9 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -233,8 +233,8 @@ static void async_complete(void *opaque)
 return;
 }
 if (errno == ENODEV && !s->closing) {
-printf("husb: device %d.%d disconnected\n",
-   s->bus_num, s->addr);
+DPRINTF("husb: device %d.%d disconnected\n",
+s->bus_num, s->addr);
 usb_host_close(s);
 usb_host_auto_check(NULL);
 return;
@@ -320,7 +320,7 @@ static int usb_host_claim_interfaces(USBHostDevice *dev, 
int configuration)
 }
 config_descr_len = dev->descr[i];
 
-printf("husb: config #%d need %d\n", dev->descr[i + 5], configuration);
+DPRINTF("husb: config #%d need %d\n", dev->descr[i + 5], 
configuration);
 
 if (configuration < 0 || configuration == dev->descr[i + 5]) {
 configuration = dev->descr[i + 5];
@@ -359,7 +359,7 @@ static int usb_host_claim_interfaces(USBHostDevice *dev, 
int configuration)
 ret = ioctl(dev->fd, USBDEVFS_CLAIMINTERFACE, &interface);
 if (ret < 0) {
 if (errno == EBUSY) {
-printf("husb: update iface. device already grabbed\n");
+DPRINTF("husb: update iface. device already grabbed\n");
 } else {
 perror("husb: failed to claim interface");
 }
@@ -368,8 +368,8 @@ static int usb_host_claim_interfaces(USBHostDevice *dev, 
int configuration)
 }
 }
 
-printf("husb: %d interfaces claimed for configuration %d\n",
-   nb_interfaces, configuration);
+DPRINTF("husb: %d interfaces claimed for configuration %d\n",
+nb_interfaces, configuration);
 
 dev->ninterfaces   = nb_interfaces;
 dev->configuration = configuration;
@@ -929,7 +929,7 @@ static int usb_host_open(USBHostDevice *dev, int bus_num,
 if (dev->fd != -1) {
 goto fail;
 }
-printf("husb: open device %d.%d\n", bus_num, addr);
+DPRINTF("husb: open device %d.%d\n", bus_num, addr);
 
 if (!usb_host_device_path) {
 perror("husb: USB Host Device Path not set");
@@ -984,7 +984,7 @@ static int usb_host_open(USBHostDevice *dev, int bus_num,
 goto fail;
 }
 
-printf("husb: grabbed usb device %d.%d\n", bus_num, addr);
+DPRINTF("husb: grabbed usb device %d.%d\n", bus_num, addr);
 
 ret = usb_linux_update_endp_table(dev);
 if (ret) {
-- 
1.7.1

[Qemu-devel] [PATCH 2/4] usb: initialise data element in Linux USB_DISCONNECT ioctl.

[Brad Hards]

This isn't used, but leaving it empty causes valgrind noise.

Signed-off-by: Brad Hards 
---
 usb-linux.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/usb-linux.c b/usb-linux.c
index 255009f..d958853 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -344,6 +344,7 @@ static int usb_host_claim_interfaces(USBHostDevice *dev, 
int configuration)
 for (interface = 0; interface < nb_interfaces; interface++) {
 ctrl.ioctl_code = USBDEVFS_DISCONNECT;
 ctrl.ifno = interface;
+ctrl.data = 0;
 ret = ioctl(dev->fd, USBDEVFS_IOCTL, &ctrl);
 if (ret < 0 && errno != ENODATA) {
 perror("USBDEVFS_DISCONNECT");
-- 
1.7.1

[Qemu-devel] [PATCH 3/4] usb: fix spelling errors in usb-linux.c

[Brad Hards]

Signed-off-by: Brad Hards 
---
 usb-linux.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/usb-linux.c b/usb-linux.c
index d958853..1f33c2c 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -107,7 +107,7 @@ enum {
 /*
  * Control transfer state.
  * Note that 'buffer' _must_ follow 'req' field because
- * we need contigious buffer when we submit control URB.
+ * we need contiguous buffer when we submit control URB.
  */
 struct ctrl_struct {
 uint16_t len;
@@ -580,7 +580,7 @@ static int usb_host_handle_control(USBHostDevice *s, 
USBPacket *p)
 /*
  * Setup ctrl transfer.
  *
- * s->ctrl is layed out such that data buffer immediately follows
+ * s->ctrl is laid out such that data buffer immediately follows
  * 'req' struct which is exactly what usbdevfs expects.
  */
 urb = &aurb->urb;
-- 
1.7.1

[Qemu-devel] [PATCH 1/4] usb: trivial spelling fixes

[Brad Hards]

Signed-off-by: Brad Hards 
---
 hw/usb-msd.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/usb-msd.c b/hw/usb-msd.c
index 76f5b02..947fd3f 100644
--- a/hw/usb-msd.c
+++ b/hw/usb-msd.c
@@ -33,7 +33,7 @@ do { printf("usb-msd: " fmt , ## __VA_ARGS__); } while (0)
 
 enum USBMSDMode {
 USB_MSDM_CBW, /* Command Block.  */
-USB_MSDM_DATAOUT, /* Tranfer data to device.  */
+USB_MSDM_DATAOUT, /* Transfer data to device.  */
 USB_MSDM_DATAIN, /* Transfer data from device.  */
 USB_MSDM_CSW /* Command Status.  */
 };
@@ -253,7 +253,7 @@ static void usb_msd_command_complete(SCSIBus *bus, int 
reason, uint32_t tag,
 usb_msd_copy_data(s);
 if (s->usb_len == 0) {
 /* Set s->packet to NULL before calling usb_packet_complete
-   because annother request may be issued before
+   because another request may be issued before
usb_packet_complete returns.  */
 DPRINTF("Packet complete %p\n", p);
 s->packet = NULL;
-- 
1.7.1

[Qemu-devel] [PATCH 0/4] Minor USB fixes

[Brad Hards]

1 fixes spellos in the mass-storage driver
2-4 fix issues in Linux usb pass-through code. 

[Qemu-devel] [PATCH] Clean up after "make pdf"

[Brad Hards]

---
 .gitignore |3 +++
 Makefile   |5 -
 2 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/.gitignore b/.gitignore
index 1d79680..08013fc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -44,6 +44,9 @@ QMP/qmp-commands.txt
 *.ky
 *.log
 *.pdf
+*.cps
+*.fns
+*.kys
 *.pg
 *.pyc
 *.toc
diff --git a/Makefile b/Makefile
index fa93be5..dc39efd 100644
--- a/Makefile
+++ b/Makefile
@@ -163,7 +163,10 @@ distclean: clean
rm -f config-host.mak config-host.h* config-host.ld $(DOCS) 
qemu-options.texi qemu-img-cmds.texi qemu-monitor.texi
rm -f config-all-devices.mak
rm -f roms/seabios/config.mak roms/vgabios/config.mak
-   rm -f qemu-doc.info qemu-doc.aux qemu-doc.cp qemu-doc.dvi qemu-doc.fn 
qemu-doc.info qemu-doc.ky qemu-doc.log qemu-doc.pdf qemu-doc.pg qemu-doc.toc 
qemu-doc.tp qemu-doc.vr
+   rm -f qemu-doc.info qemu-doc.aux qemu-doc.cp qemu-doc.cps qemu-doc.dvi
+   rm -f qemu-doc.fn qemu-doc.fns qemu-doc.info qemu-doc.ky qemu-doc.kys
+   rm -f qemu-doc.log qemu-doc.pdf qemu-doc.pg qemu-doc.toc qemu-doc.tp
+   rm -f qemu-doc.vr
rm -f qemu-tech.info qemu-tech.aux qemu-tech.cp qemu-tech.dvi 
qemu-tech.fn qemu-tech.info qemu-tech.ky qemu-tech.log qemu-tech.pdf 
qemu-tech.pg qemu-tech.toc qemu-tech.tp qemu-tech.vr
for d in $(TARGET_DIRS) $(QEMULIBS); do \
rm -rf $$d || exit 1 ; \
-- 
1.7.1

[Qemu-devel] [Bug 757654] Re: UHCI fails to signal stall response

[Brad Hards]

Hi,

Thanks for reporting this issue.

Just so you are aware: the qemu USB maintainer is probably going to be
away for a while longer, so don't be too worried if this patch doesn't
get looked at for 2-4 weeks.

Brad

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/757654

Title:
  UHCI fails to signal stall response

Status in QEMU:
  New

Bug description:
  When TD execution results in STALL error (STALL handshake, no stall as
  a result of err count reaching 0), there is no way to know about it
  except for checking that TD. IMO it is an error condition and it
  should be reflected in the status register (and issue an interrupt if
  enabled).

  Ways to replicate:
  Send a query that is answered by stall (like set_idle request to a mouse)

  Expected behavior:
  UHCI hc sets status bit 1 (usb error interrupt) and issues an interrupt

  current behavior:
  Neither status bit is set nor interrupt triggered

  Version 0.14
  attached patch for current master (quick fix, it might be I got something 
wrong)

Re: [Qemu-devel] [PATCH 4/4] qxl: allow QXL_IO_LOG also in vga

[Brad Hards]

On Sun, 10 Apr 2011 08:26:06 pm Alon Levy wrote:
> -if (d->mode == QXL_MODE_NATIVE || d->mode == QXL_MODE_COMPAT)
> +if (d->mode == QXL_MODE_NATIVE || d->mode == QXL_MODE_COMPAT
> +|| (io_port == QXL_IO_LOG))
I think this might look better with consistent use of brackets.

Low priority, for your consideration.

Brad

[Qemu-devel] qemu_malloc failing

[Brad Hards]

Hi,

I'm trying to investigate a bug (crash) that I see when attaching a USB device
(a UVC webcam) from the host to the guest.

I'm running it as:
sudo gdb --args /opt/bin/qemu -hda ubuntu-test -name kubuntu-qemu -usb -device 
usb-tablet -m 1024 -serial stdio -usbdevice host:0c45:6450

(I've tried running with -m 512 too, not discernibly different).

Host and guest are the same - kubuntu 10.10. The device works fine on the host.

The guest runs for a while, and has no ill-effects (that I've seen) until I try
to use the webcam. If I open the device (using cheese or luvcview), I see some
traffic, then qemu segfaults:


Program received signal SIGSEGV, Segmentation fault.
0x75a4e66c in malloc_consolidate (av=0x75d55e40) at malloc.c:5161
5161malloc.c: No such file or directory.
in malloc.c
(gdb) bt
#0  0x75a4e66c in malloc_consolidate (av=0x75d55e40) at 
malloc.c:5161
#1  0x75a51e82 in _int_malloc (av=0x75d55e40, bytes=2128) at 
malloc.c:4373
#2  0x75a5338e in __libc_malloc (bytes=2128) at malloc.c:3660
#3  0x0042b3d6 in qemu_malloc (size=2128) at qemu-malloc.c:49
#4  0x0056100f in uhci_async_alloc (s=0x15dcc10) at 
/home/bradh/qemu-codingstyle.git/hw/usb-uhci.c:167
#5  0x005620d4 in uhci_handle_td (s=0x15dcc10, addr=684474656, 
td=0x7fffdf80, int_mask=0x7fffdfac) at 
/home/bradh/qemu-codingstyle.git/hw/usb-uhci.c:808
#6  0x00562665 in uhci_process_frame (s=0x15dcc10) at 
/home/bradh/qemu-codingstyle.git/hw/usb-uhci.c:1007
#7  0x005628a8 in uhci_frame_timer (opaque=0x15dcc10) at 
/home/bradh/qemu-codingstyle.git/hw/usb-uhci.c:1092
#8  0x004da94c in qemu_run_timers (clock=0x1171ff0) at qemu-timer.c:505
#9  0x004dac0c in qemu_run_all_timers () at qemu-timer.c:616
#10 0x005484c2 in main_loop_wait (nonblocking=1) at 
/home/bradh/qemu-codingstyle.git/vl.c:1324
#11 0x00548549 in main_loop () at 
/home/bradh/qemu-codingstyle.git/vl.c:1365
#12 0x0054c725 in main (argc=14, argv=0x7fffe648, 
envp=0x7fffe6c0) at /home/bradh/qemu-codingstyle.git/vl.c:3195

Line 167 in hw/usb-uhci.c is in in static UHCIAsync *uhci_async_alloc(UHCIState 
*s)
It looks like:
UHCIAsync *async = qemu_malloc(sizeof(UHCIAsync));

UHCIState is fairly large, so the size looks possible:
typedef struct UHCIState {
PCIDevice dev;
USBBus bus;
uint16_t cmd; /* cmd register */
uint16_t status;
uint16_t intr; /* interrupt enable register */
uint16_t frnum; /* frame number */
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];

/* Interrupts that should be raised at the end of the current frame.  */
uint32_t pending_int_mask;

/* Active packets */
UHCIAsync *async_pending;
UHCIAsync *async_pool;
uint8_t num_ports_vmstate;
} UHCIState;

Line 49 in qemu_malloc.c is in void *qemu_malloc(size_t size).
It looks like.
ptr = qemu_oom_check(malloc(size ? size : 1));

So I guess malloc is failing. However I don't see how / why. The host is a 
laptop
machine with 6G RAM, and it appears to remain quite responsive. 

Any suggestions on how to proceed with debugging this?

Brad

[Qemu-devel] [Bug 721659] Re: qemu-kvm-0.13.0 doesn't pass USB devices to the VM

[Brad Hards]

Hi,

Thanks for reporting this problem.

Can you tell me a bit more about your configuration? For example:
What are the guest and host operating systems?

Is it always "need -1"? Do you ever see "need 1"?

What is the device you're trying to open? Can you show the USB
descriptors (e.g. from lsusb)?

Do you have rights to open the device (e.g. are you running qemu with
elevated privileges)? Does it help / change things if you do or don't?

I'm not sure that the error messages are very accurate in this
particular case. I think the problem with those messages comes from use
of perror() in the QEMU code and that the underlying operations aren't
returning / setting errno in the right way (or perhaps at all). However
the fact that we're even getting to the error path indicates a problem.
If I had to guess, the device is already bound to a driver on the host
and you don't have permissions to unbind it. However I'm pretty fuzzy on
this one, and I'm really hoping the additional information might help
someone else fix it.

Brad

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/721659

Title:
  qemu-kvm-0.13.0 doesn't pass USB devices to the VM

Status in QEMU:
  New

Bug description:
  I have the bug, similar to this one:
  https://bugzilla.redhat.com/show_bug.cgi?id=583108
  but under gentoo

  When I add parameters -usb -usbdevice host:4348:5584, I see the
  following lines in console:

  husb: config #1 need -1
  USBDEVFS_DISCONNECT: No route to host
  husb: open device 2.11
  (...many repetitions of three above lines...)

  All parameters (2.11) are verified with lsusb at host computer -
  parameters are correct

  Error description is very confusing - I don't know what to check, what
  "config #1" mean, which route should be checked and how to check it.

[Qemu-devel] [Bug 663713] Re: Mouse frozen under an emulated ubuntu

[Brad Hards]

0.14 is out, so close bug report.

** Changed in: qemu
   Status: Incomplete => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/663713

Title:
  Mouse frozen under an emulated ubuntu

Status in QEMU:
  Fix Released

Bug description:
  Qemu 0.13.0

  Command line used :

  qemu-system-x86_64 --enable-kvm -localtime -soundhw all -k fr -m 1500
  -net user -net nic,model=rtl8139 -hda disk.img -cdrom ubuntu-10.10
  -desktop-amd64.iso -boot d

  When I try to move mouse cursor in qemu, pointer is frozen. Nothing is
  moving. Was working perfectly with Qemu 0.12.5.

[Qemu-devel] [Bug 663713] Re: Mouse frozen under an emulated ubuntu

[Brad Hards]

I'm not sure I understand you. I'm confused about whether you think qemu
is "dead", or the bug is "dead", and what the relationship with gwibber
is.

Can you state whether, in your opinion / experience, a current version
of qemu still has this bug or not?

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/663713

Title:
  Mouse frozen under an emulated ubuntu

Status in QEMU:
  Incomplete

Bug description:
  Qemu 0.13.0

  Command line used :

  qemu-system-x86_64 --enable-kvm -localtime -soundhw all -k fr -m 1500
  -net user -net nic,model=rtl8139 -hda disk.img -cdrom ubuntu-10.10
  -desktop-amd64.iso -boot d

  When I try to move mouse cursor in qemu, pointer is frozen. Nothing is
  moving. Was working perfectly with Qemu 0.12.5.

[Qemu-devel] [Bug 691424] Re: qemu/kvm SDL over ssh -X broken

[Brad Hards]

Hi,

I tried this with a current (git) build, and I'm not able to reproduce
it.

I do see a problem with a bad initial SDL window size (its much too
small) on a remote machine over a moderate-level network (wireless LAN).
I don't see that when ssh-ing to localhost (even though both hosts are
basically the same).

I do see differences between current (git) qemu and the 0.12.5 version.
Current git boots the ISO, but doesn't appear to get to the login
screen.

I'm not sure what the differences between our configurations are. I have
SDL 1.2.14-6ubuntu3

Still investigation.

Brad

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/691424

Title:
  qemu/kvm SDL over ssh -X broken

Status in QEMU:
  New

Bug description:
  qemu/kvm by default uses SDL to render the output of its emulated VGA 
graphics.
  This is broken over ssh -X since quite a while.
  The only workaround I know, is to use qemu -vnc :0
  and connect using vncviewer

  
  How To Reproduce:
  1. zypper in qemu
  2. ssh -X localhost qemu -cdrom ANYISOFILE

  Actual Results:
  qemu hangs in an endless loop on the BIOS display screen

  Expected Results:
  should boot up the iso as 0.10 versions did

  Reproducible: Always

  
  this is what broke it:
  $ git bisect bad
  c18a2c360e3100bbd71162cf922dcd8c429a8b71 is first bad commit
  commit c18a2c360e3100bbd71162cf922dcd8c429a8b71
  Author: Stefano Stabellini 
  Date:   Wed Jun 24 11:58:25 2009 +0100

  sdl zooming

  Hi all,
  this patch implements zooming capabilities for the sdl interface.
  A new sdl_zoom_blit function is added that is able to scale and blit a
  portion of a surface into another.
  This way we can enable SDL_RESIZABLE and have a real_screen surface with
  a different size than the guest surface and let sdl_zoom_blit take care
  of the problem.

  Signed-off-by: Stefano Stabellini 
  Signed-off-by: Anthony Liguori 

  :100644 100644 a06c9bfc22cc6de1c6e5e9068d6bf59d89613767 
f8dc5065dd27010bfdbb6bcfb0c6e3af25024cdb M  Makefile
  :100644 100644 417217582363a87ee67e746ba798e285a64b6cdc 
35183399f65de6f50f3baa4767ab7d4d11d45bca M  console.h
  :100644 100644 178b5532b8d9dd2194a8662fbfdcd49b4bc04222 
d81399e51276e1c97fa1f7272ef16ea4c312b51b M  sdl.c
  :00 100644  
56d3604fc3d79e4cc4622be8437c78bf70075da3 A  sdl_zoom.c
  :00 100644  
33dc63408b43a37fd6b1acde3fa62b1a51315e75 A  sdl_zoom.h
  :00 100644  
64bbca849bd3af678c2259b4d8cc0e48c6a6b43c A  sdl_zoom_template.h

  
  This problem occurs on both Debian and openSUSE.

[Qemu-devel] [Bug 663713] Re: Mouse frozen under an emulated ubuntu

[Brad Hards]

Fred,

Can you test a current version  and confirm that everything is OK now?

Brad

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/663713

Title:
  Mouse frozen under an emulated ubuntu

Status in QEMU:
  Incomplete

Bug description:
  Qemu 0.13.0

  Command line used :

  qemu-system-x86_64 --enable-kvm -localtime -soundhw all -k fr -m 1500
  -net user -net nic,model=rtl8139 -hda disk.img -cdrom ubuntu-10.10
  -desktop-amd64.iso -boot d

  When I try to move mouse cursor in qemu, pointer is frozen. Nothing is
  moving. Was working perfectly with Qemu 0.12.5.

[Qemu-devel] [PATCH] event: trivial coding style fixes.

[Brad Hards]

Signed-off-by: Brad Hards 
---
 input.c |   14 +++---
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/input.c b/input.c
index ec05548..5664d3a 100644
--- a/input.c
+++ b/input.c
@@ -161,15 +161,15 @@ void kbd_mouse_event(int dx, int dy, int dz, int 
buttons_state)
 
 if (mouse_event) {
 if (graphic_rotate) {
-if (entry->qemu_put_mouse_event_absolute)
+if (entry->qemu_put_mouse_event_absolute) {
 width = 0x7fff;
-else
+} else {
 width = graphic_width - 1;
-mouse_event(mouse_event_opaque,
-width - dy, dx, dz, buttons_state);
-} else
-mouse_event(mouse_event_opaque,
-dx, dy, dz, buttons_state);
+}
+mouse_event(mouse_event_opaque, width - dy, dx, dz, buttons_state);
+} else {
+mouse_event(mouse_event_opaque, dx, dy, dz, buttons_state);
+}
 }
 }
 
-- 
1.7.1

[Qemu-devel] [Bug 754635] Re: -d option outs wrong info about sections

[Brad Hards]

Hi,

Thanks for reporting this issue, and the investigation. I don't really
understand the rationale for the change, so I can't help much.

This change appears to be from 5cd2c5b6ad75c46d40118ac67c0c09d4e7930a65.
I think input from Richard Henderson (the author of the change) would be
very useful.

Brad

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/754635

Title:
  -d option outs wrong info about sections

Status in QEMU:
  New

Bug description:
  For example, after run ./qemu-i386 -d in_asm /bin/ls from 0.14.0 release, I 
received this qemu.log file:
  $ cat /tmp/qemu.log | grep -A7 guest
  Relocating guest address space from 0x08048000 to 0x8048000
  guest_base  0x0
  startend  size prot
  00048000-0005f000 00017000 r-x
  0005f000-00069000 a000 rw-
  0004-00041000 1000 ---
  00041000-00041800 0800 rw-
  00041800-0005d800 0001c000 r-x
  0005d800-0005f800 2000 rw-

  But such command in 0.12.5 release outs this:
  $ cat /tmp/qemu.log | grep -A7 guest
  guest_base  0x0
  startend  size prot
  00f38000-00f39000 1000 ---
  08048000-0805f000 00017000 r-x
  0805f000-08061000 2000 rw-
  4000-4008 0008 rw-
  4008-40081000 1000 ---
  40081000-4009d000 0001c000 r-x

  It looks correct.
  I received such differences and with qemu-microblaze. 

  After comparing 0.12.5 and 0.14.0 releases I found this differences in exec.c:
  in 0.12.5:
  end = (i << (32 - L1_BITS)) | (j << TARGET_PAGE_BITS);

  in 0.14.0:
  int rc = walk_memory_regions_1(&data, (abi_ulong)i << V_L1_SHIFT,

  V_L1_SHIFT in my case is 10, but 32 - L1_BITS is 22

  I make this changes:
  $ diff -up qemu-0.14.0/exec.c exec.c
  --- qemu-0.14.0/exec.c2011-04-08 17:26:00.524464002 +0400
  +++ exec.c2011-04-08 17:26:09.800464003 +0400
  @@ -2340,7 +2340,7 @@ int walk_memory_regions(void *priv, walk
   data.prot = 0;
   
   for (i = 0; i < V_L1_SIZE; i++) {
  -int rc = walk_memory_regions_1(&data, (abi_ulong)i << V_L1_SHIFT,
  +int rc = walk_memory_regions_1(&data, (abi_ulong)i << (V_L1_SHIFT + 
TARGET_PAGE_BITS),
  V_L1_SHIFT / L2_BITS - 1, l1_map + i);
   if (rc != 0) {
   return rc;

  After this outputs looks correct.

  I don't know code base good, and think what may to do more general 
corrections.
  Host system: linux i386

Re: [Qemu-devel] [PATCH] monitor: avoid moving cursor during "mouse_button" command

[Brad Hards]

On Sat, 9 Apr 2011 12:34:21 am Markus Armbruster wrote:
> There's one instance of state: position (if absolute) + buttons for any
> number of mice.  Funny things can happen when you have more than one
> mouse and switch between them.
For the common case (in most OS), each of the mice are mixed together. 
Switching (with the guest powered up) is pretty rare.
 
> Even if there's just one mouse: the state is updated only for monitor
> mouse action.  Funny things can happen when something other than monitor
> commands uses the mouse.
That already happens. If SDL and monitor mouse_move are both used, then "last 
wins".
 
> Shouldn't the state be kept per-mouse?  Monitor could ask for current
> coordinates + button state then.
I thought about keeping the state in input.c code, but that adds more 
complexity and probably won't work properly either (as Anthony pointed out on 
IRC), because the inputs that you've provided to the guest get modified by 
guest code (like mouse acceleration).

> Note buttons are already funny.  The patch just extends the funniness to
> position.  Could be a valid excuse for committing it as is.
Note that the diff doesn't change the behaviour of mouse_move (i.e. position). 
It just "breaks less" for the mouse_button command for the following specific 
situation:
1. You've previously used mouse_move to select the point you want
and
2. You're using an absolute pointing device.

Going back to the original bug report, with current trunk (and the common case 
of an absolute pointing device), mouse_button warps the mouse to the origin if 
you press a button. It seems less surprising to use the last position.

Brad

Re: [Qemu-devel] [PATCH] monitor: avoid moving cursor during "mouse_button" command

[Brad Hards]

On Fri, 8 Apr 2011 05:44:00 pm Brad Hards wrote:
> I've tested this with a kubuntu 10.10 guest and it works fine
> for me with both relative and absolute pointing devices. Note
> that testing with realtive pointing device was relatively
> light.
This fix (in slightly different form) was verified by the original reporter as 
fixing the problem. See https://bugs.launchpad.net/qemu/+bug/752476/comments/3

Brad

[Qemu-devel] [PATCH] monitor: avoid moving cursor during "mouse_button" command

[Brad Hards]

This addresses https://bugs.launchpad.net/qemu/+bug/752476 which
basically points out that using the mouse_button command causes
the mouse cursor to warp to the origin (when using absolute
pointing device).

I've tested this with a kubuntu 10.10 guest and it works fine
for me with both relative and absolute pointing devices. Note
that testing with realtive pointing device was relatively
light.

Signed-off-by: Brad Hards 
---
 monitor.c |   14 +-
 1 files changed, 13 insertions(+), 1 deletions(-)

diff --git a/monitor.c b/monitor.c
index f1a08dc..0ce162b 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1879,6 +1879,9 @@ static void do_sendkey(Monitor *mon, const QDict *qdict)
muldiv64(get_ticks_per_sec(), hold_time, 1000));
 }
 
+static int mouse_x;
+static int mouse_y;
+static int mouse_z;
 static int mouse_button_state;
 
 static void do_mouse_move(Monitor *mon, const QDict *qdict)
@@ -1893,13 +1896,22 @@ static void do_mouse_move(Monitor *mon, const QDict 
*qdict)
 if (dz_str)
 dz = strtol(dz_str, NULL, 0);
 kbd_mouse_event(dx, dy, dz, mouse_button_state);
+if (kbd_mouse_is_absolute()) {
+mouse_x = dx;
+mouse_y = dy;
+mouse_z = dz;
+}
 }
 
 static void do_mouse_button(Monitor *mon, const QDict *qdict)
 {
 int button_state = qdict_get_int(qdict, "button_state");
 mouse_button_state = button_state;
-kbd_mouse_event(0, 0, 0, mouse_button_state);
+if (kbd_mouse_is_absolute()) {
+kbd_mouse_event(mouse_x, mouse_y, mouse_z, mouse_button_state);
+} else {
+kbd_mouse_event(0, 0, 0, mouse_button_state);
+}
 }
 
 static void do_ioport_read(Monitor *mon, const QDict *qdict)
-- 
1.7.1

[Qemu-devel] [Bug 752476] Re: monitor command mouse_button 1 moves mouse

[Brad Hards]

Can you try the attached patch?

** Patch added: 
"0001-monitor-Avoid-moving-the-cursor-when-doing-mouse_but.patch"
   
https://bugs.launchpad.net/qemu/+bug/752476/+attachment/1998150/+files/0001-monitor-Avoid-moving-the-cursor-when-doing-mouse_but.patch

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/752476

Title:
  monitor command mouse_button 1 moves mouse

Status in QEMU:
  New

Bug description:
  via the qemu -monitor interface, it is possible to move and click the mouse 
using
  mouse_move 2 1
  mouse_button 1
  but the mouse_button command always moves the mouse to (0,0) making it rather 
unusable to (auto-)trigger any widgets in the VM from the outside.

  Would be nice to have this available for my qemu/kvm based os-autoinst
  testing framework.

[Qemu-devel] [Bug 753916] Re: performance bug with SeaBios 0.6.x

[Brad Hards]

OK, from your test.swf file, I assume that the way you're testing is the
boot-up of a Linux ISO, and that "100%" is an estimate of boot speed.

I'm really not sure what the problem is. I can only suggest that you try
various SeaBIOS versions and try to isolate which version is the
problem. It also might be worth seeing if the problem affects other
Linux distro boot-up.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/753916

Title:
  performance bug with SeaBios 0.6.x

Status in QEMU:
  New

Bug description:
  in my tests SeaBios 0.5.1 has the best performance (100% faster)
  i run qemu port in windows xp (phenom II x4 945, 4 gigas ram DDR3) and 
windows xp (Pentium 4, 1 giga ram ddr)

[Qemu-devel] [Bug 752476] Re: monitor command mouse_button 1 moves mouse

[Brad Hards]

Hi. Thanks for reporting this issue.

I'm able to (partly) reproduce this, but it might help if I could
understand your configuration a bit more.

Does mouse movement work for you using the normal interface (SDL or
VNC)?

Do you have the pointer device configured in an absolute mode (e.g.
something like a USB tablet device)?

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/752476

Title:
  monitor command mouse_button 1 moves mouse

Status in QEMU:
  New

Bug description:
  via the qemu -monitor interface, it is possible to move and click the mouse 
using
  mouse_move 2 1
  mouse_button 1
  but the mouse_button command always moves the mouse to (0,0) making it rather 
unusable to (auto-)trigger any widgets in the VM from the outside.

  Would be nice to have this available for my qemu/kvm based os-autoinst
  testing framework.

[Qemu-devel] [Bug 753916] Re: performance bug with SeaBios 0.6.x

[Brad Hards]

Hi. Thanks for reporting this issue.

Can you tell us a bit more about the problem?
I'm not sure what the cause could be, but perhaps we can understand it better 
with some of the following information (plus anything else you can think of 
that could be related):
 - What version of QEMU are you running on each machine?
 - Did you build it yourself? If so, can you describe how? If not, can you 
provide a pointer to where you got it?
 - What are you running as the guest environment(s)?
 - I'm assuming that Windows XP is the host environment (two different host 
machines from your description). Which version / service packs do you have 
installed?
 - How did you do the tests? For example, what is the benchmarking tool or load 
that you are using? How are you using those tools / loads? Can you provide the 
numbers for each host?

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/753916

Title:
  performance bug with SeaBios 0.6.x

Status in QEMU:
  New

Bug description:
  in my tests SeaBios 0.5.1 has the best performance (100% faster)
  i run qemu port in windows xp (phenom II x4 945, 4 gigas ram DDR3) and 
windows xp (Pentium 4, 1 giga ram ddr)

Re: [Qemu-devel] [PATCH RFC 0/5] kvm/vhost: enable durty logging during memory registration

[Brad Hards]

On Thu, 7 Apr 2011 06:41:35 am Michael S. Tsirkin wrote:
> As a solution, this adds an explicit flag that
> will enable dirty logging directly when registering
> the ram. kvm then needs a single system call
> to update tables for vga ram, vhost-net can simply ignore it.
I'm not very familiar with QEMU coding style and standards (so this could be 
completely bogus), but I think that the code would be easier if you used a 
integer flag / enum instead of a boolean. That would also give you options for 
additional behaviour changes later too. So instead of passing true/false, pass 
MEM_LOG_DIRTY_PAGES (or whatever you decide to call it).

I can't really comment on the rest of the patch - I'm too clueless. 

> This replaces the RFC patchset 'vga: flag vga ram for notifiers'.
> Warning: compile-tested only.
I compiled and booted my Ubuntu guest (on ubuntu host) which uses Cirrus for 
each step in this patchset. Seems OK to me - I didn't notice appreciable 
speedup, but I wasn't really expecting to.

Brad

Re: [Qemu-devel] [PATCH] hw: improve multiboot module loading

[Brad Hards]

On Thu, 7 Apr 2011 10:19:01 am r...@humppa.name wrote:
> Signed-off-by:
Looks like something may be wrong with your git config

Brad

[Qemu-devel] [Bug 688052] Re: usb does not work 0.13.0

[Brad Hards]

Thanks for the report.

For the second part, you need to clone using the git protocol (git clone 
git://git.qemu.org/qemu.git
as shown in http://wiki.qemu.org/Download#Latest_Source_Code). The http bit 
appears broken for now.

I'm not sure about the first part yet - certainly trying a more recent
release would be useful to know.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/688052

Title:
  usb does not work 0.13.0

Status in QEMU:
  New

Bug description:
  Hi all, I'm using both, debian lenny and debian squeeze.
  I installed qemu-kvm (0.12.5) form debian repository but I got problem trying 
to pass a host usb device to the guest.

  I compiled so the latest stable version (0.13.0) hoping that the problem was 
fixed.
  It didn't help, the error I get is always:

  usb_create: no bus specified, using "usb.0" for "usb-host"

  The command I use is

  qemu-system-x86_64 -hda lenny_amd64_vergine.qcow2 -usbdevice
  host:002.007 -boot order=c

  On internet I found this, it might help:
  http://www.mail-archive.com/qemu-devel@nongnu.org/msg38795.html

  The guest is a simple debian lenny with 2.6.26 kernel.

  
  I tried also to download the qemu development version but the download get 
interruped

  git clone http://git.qemu.org/qemu.git
  Cloning into qemu...
  error: Failed connect to git.qemu.org:80; No such file or directory 
(curl_result = 7, http_code = 0, sha1 = 
62d76a25fe741bdaf1157f0edaf50a7772541db6)
  error: Unable to find 62d76a25fe741bdaf1157f0edaf50a7772541db6 under 
http://git.qemu.org/qemu.git

  I attach more info about the host machine I'm testing on.

[Qemu-devel] [Bug 645524] Re: No picture from USB webcam (kvm 0.13-rc1)

[Brad Hards]

Thanks for the report.

Can you tell me if it works with a Linux guest?

Can you tell me what kind of camera it is (e.g. the descriptors from
lsusb -v for the device)?

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/645524

Title:
  No picture from USB webcam (kvm 0.13-rc1)

Status in QEMU:
  New

Bug description:
  I export my Linux webcam to KVM using the switches "-usb -usbdevice
  host:046d:0929". The XP guest sees the webcam and the drivers install,
  but the camera only shows a black image. When I open the camera in
  Windows Explorer, it says "0 images" and a black image, while on a
  real XP, it says "1 image" and shows the video from the camera. Same
  problem with different webcams. Same cameras work fine on a native XP
  install.

[Qemu-devel] [Bug 521994] Re: Windows 98 doesn't detect mouse on qemu and SeaBIOS.

[Brad Hards]

Looks like this is fixed in qemu.

** Changed in: qemu
   Status: Confirmed => Fix Committed

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/521994

Title:
  Windows 98 doesn't detect mouse on qemu and SeaBIOS.

Status in QEMU:
  Fix Committed
Status in “qemu-kvm” package in Debian:
  Fix Committed

Bug description:
  A windows 98 guest doesn't detect mouse on recent qemu. I bisected and
  the result is

  fd646122418ecefcde228d43821d07da79dd99bb is the first bad commit
  commit fd646122418ecefcde228d43821d07da79dd99bb
  Author: Anthony Liguori 
  Date:   Fri Oct 30 09:06:09 2009 -0500

  Switch pc bios from pc-bios to seabios

  SeaBIOS is a port of pc-bios to GCC.  Besides using a more modern tool 
chain,
  SeaBIOS introduces a number of new features including PMM support, better
  BEV and BCV support, and better PnP support.

  Signed-off-by: Anthony Liguori 

  I got following messages with DEBUG_BIOS

  Start bios (version 0.5.1-20100111_132716-squirrel.codemonkey.ws)
  Ram Size=0x0800 (0x high)
  CPU Mhz=2271
  Found 1 cpu(s) max supported 1 cpu(s)
  PIIX3/PIIX4 init: elcr=00 0c
  PCI: bus=0 devfn=0x00: vendor_id=0x8086 device_id=0x1237
  PCI: bus=0 devfn=0x08: vendor_id=0x8086 device_id=0x7000
  PCI: bus=0 devfn=0x09: vendor_id=0x8086 device_id=0x7010
  region 4: 0xc000
  PCI: bus=0 devfn=0x0b: vendor_id=0x8086 device_id=0x7113
  PCI: bus=0 devfn=0x10: vendor_id=0x1013 device_id=0x00b8
  region 0: 0xe000
  region 1: 0xe200
  region 6: 0xe201
  MP table addr=0x000f89b0 MPC table addr=0x000f89c0 size=224
  SMBIOS ptr=0x000f8990 table=0x07fffef0
  ACPI tables: RSDP=0x000f8960 RSDT=0x07ffde30
  Scan for VGA option rom
  Running option rom at c000:0003
  VGABios $Id$
  Turning on vga console
  Starting SeaBIOS (version 0.5.1-20100111_132716-squirrel.codemonkey.ws)

  Found 0 lpt ports
  Found 0 serial ports
  ATA controller 0 at 1f0/3f4/c000 (irq 14 dev 9)
  ATA controller 1 at 170/374/c008 (irq 15 dev 9)
  ps2 irq but no data.
  ata0-0: PCHS=812/16/63 translation=none LCHS=812/16/63
  ata0-1: PCHS=1152/16/56 translation=none LCHS=1024/16/56
  ps2_recvbyte timeout
  keyboard initialized
  Scan for option roms
  Returned 53248 bytes of ZoneHigh
  e820 map has 6 items:
0:  - 0009f400 = 1
1: 0009f400 - 000a = 2
2: 000f - 0010 = 2
3: 0010 - 07ffd000 = 1
4: 07ffd000 - 0800 = 2
5: fffc - 0001 = 2
  enter handle_19:
NULL
  Booting from Hard Disk...
  Booting from :7c00
  pnp call arg1=5
  pnp call arg1=0
  ps2_recvbyte timeout
  ps2_recvbyte timeout
  ps2_recvbyte timeout
  ps2_recvbyte timeout

Re: [Qemu-devel] KVM call agenda for April 05

[Brad Hards]

On Tue, 5 Apr 2011 06:29:48 pm Alexander Graf wrote:
> > quality and resubmission. It would also help to have some explanatory
> > text for some of the architectural docs that are available (e.g. there
> > is a lot of words on the wiki about QED, and I guess its some kind of
> > storage / disk thing, but I have no idea why its important, or even if I
> > should know about it).
> 
> Take a look at http://wiki.qemu.org/Contribute/StartHere. It links to
> (rudimentary) explanations for QED. We don't have a full-on architectural
> doc though. And I'm not sure we ever will - unless people volunteer to
> write documentation instead of code :).
I take it you meant http://wiki.qemu.org/Features/QED (and the pages that link 
from there). I still don't know what QED does. I'm guessing something related 
to block devices (blocks get mentioned) and it is different to something called 
"raw", but I still don't know what QED does (or does differently / better than 
something else).

There is detail on why things are the way they are, but no context to help 
situate that detail.

The problem isn't with QED in particular. That is just an example of the issue 
- it could be applied equally to sheepdog, or VNC / Splice / SDL display, or 
some of the other things I don't even know that I don't know.

I personally found the qdev presentation style pretty approachable:
 - here is how it used to be...
 - that sucks for all the obvious reasons, and some you didn't think about...
 - here is how we do it now / should do it...
 - that sucks (less) for these reasons...
 - here is what you should do...

That isn't going to replace reading the code and copying examples. There 
should only be enough detail to tell people "you should know X and Y, and look 
here for more".

Brad

Re: [Qemu-devel] KVM call agenda for April 05

[Brad Hards]

On Tue, 5 Apr 2011 08:53:21 pm Stefan Hajnoczi wrote:
> scripts/checkpatch.pl is mentioned in CODING_STYLE.  I have a git-hook
> to automatically run it:
> http://blog.vmsplice.net/2011/03/how-to-automatically-run-checkpatchpl.html
> 
> That hook is just a personal tool I use.  It is not required but we
> could document it more prominently for people getting set up with QEMU
> development.
Thanks. Added to 
http://wiki.qemu.org/Documentation/GettingStartedDevelopers#Code
along with some other notes from this thread.

Brad

Re: [Qemu-devel] KVM call agenda for April 05

[Brad Hards]

On Tue, 5 Apr 2011 06:29:48 pm Alexander Graf wrote:
> What exactly do you mean by better-practice git setups?
Some projects try to use special features in git. For example, KDE makes use 
of insteadOf and pushInsteadOf to allow checking out from anongit, and 
committing to the main server using a pseudo-URL. 

Should I have some magic git hooks enabled? Automatic use of checker scripts 
or sign-off?

Is there some way to maintain those version change logs I need if I have to 
submit my patch v26?

Brad

Re: [Qemu-devel] KVM call agenda for April 05

[Brad Hards]

On Tue, 5 Apr 2011 05:59:27 am Anthony Liguori wrote:
> - Trivial patch monkeys^Wteam -- this is an idea Stefan and I have been
> kicking around to help some of the trivial patches get more attention on
> the mailing list
I saw a wiki page (http://wiki.qemu.org/Contribute/TrivialPatches) that I 
assumed was historical - bad assumption given the page history of course.

As an outsider / new contributor, it isn't easy to see how to get patches 
noticed, and how different things should feed into the tree(s). For instance, 
is my patch being ignored because I forgot the Signed-off-by line, or is the 
maintainer away for a month? Or am I just not "in the club"?

It isn't even easy to figure out what trees there are (apart from the main one) 
and a google search for "qemu git" produces some misleading links to savannah 
and places other than git://git.qemu.org/qemu.git. It would also be useful if 
http://git.qemu.org/git/qemu.git/ and http://git.qemu.org/qemu.git worked 
again. Perhaps a list of main trees on the wiki or in MAINTAINERS might help? 
Even a list of obsolete trees might be useful.

It would probably also help if there was a little more documentation on the 
process bits (e.g. whether I need a public git tree, or mailing patches is 
always preferred, and maybe some links to better-practice git setups to ensure 
patches make it through OK) and about what is expected in terms of code 
quality and resubmission. It would also help to have some explanatory text for 
some of the architectural docs that are available (e.g. there is a lot of 
words on the wiki about QED, and I guess its some kind of storage / disk 
thing, but I have no idea why its important, or even if I should know about 
it).

I've tried to expand 
http://wiki.qemu.org/Documentation/GettingStartedDevelopers to cover my 
personal "a-ha" moments, but if I knew enough to write it all, then I'd 
probably be more interested in getting code written too...

I'm sorry I have more complaints than useful suggestions here. I can only say 
I'll hang around (mail / IRC) as long as I feel somewhat welcome and write up 
any insights you can offer.

Brad

[Qemu-devel] [PATCH] Minor spelling mistakes in hw/usb-ccid.c

[Brad Hards]

Hi,

While looking at David Gibson's build-fix for hw/usb-ccid.c, I noticed a spello
in a comment on the following (unchanged) line.

This patch fixes that, and a couple of other spellos, in that file.

Brad

 - - 

From e24a4cfce56799e091ce75aafa20c697ec5fe685 Mon Sep 17 00:00:00 2001
From: Brad Hards 
Date: Tue, 5 Apr 2011 07:39:10 +1000
Subject: [PATCH] usb-ccid: spelling fixes.

Signed-off-by: Brad Hards 
---
 hw/usb-ccid.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/hw/usb-ccid.c b/hw/usb-ccid.c
index 44156cc..079b4a2 100644
--- a/hw/usb-ccid.c
+++ b/hw/usb-ccid.c
@@ -22,7 +22,7 @@
  *  "Universal Serial Bus, Device Class: Smart Card"
  *  Specification for Integrated Circuit(s) Cards Interface Devices
  *
- * Endianess note: from the spec (1.3)
+ * Endianness note: from the spec (1.3)
  *  "Fields that are larger than a byte are stored in little endian"
  *
  * KNOWN BUGS
@@ -172,7 +172,7 @@ enum {
 CLOCK_STATUS_RUNNING = 0,
 /*
  * 0 - Clock Running, 1 - Clock stopped in State L, 2 - H,
- * 3 - unkonwn state. rest are RFU
+ * 3 - unknown state. rest are RFU
  */
 };
 
@@ -1200,7 +1200,7 @@ void ccid_card_card_error(CCIDCardState *card, uint64_t 
error)
 s->bmCommandStatus = COMMAND_STATUS_FAILED;
 s->last_answer_error = error;
 DPRINTF(s, 1, "VSC_Error: %" PRIX64 "\n", s->last_answer_error);
-/* TODO: these error's should be more verbose and propogated to the 
guest.*/
+/* TODO: these errors should be more verbose and propagated to the guest.*/
 /*
  * We flush all pending answers on CardRemove message in 
ccid-card-passthru,
  * so check that first to not trigger abort
@@ -1319,7 +1319,7 @@ static void ccid_pre_save(void *opaque)
 if (s->dev.attached) {
 /*
  * Migrating an open device, ignore reconnection CHR_EVENT to avoid an
- * erronous detach.
+ * erroneous detach.
  */
 s->migration_state = MIGRATION_MIGRATED;
 }
-- 
1.7.1

Re: [Qemu-devel] A question about qemu 0.9.1

[Brad Hards]

On Mon, 4 Apr 2011 08:10:55 pm y y wrote:
> op_movl_A0_EAX() come from?
I think its a pre-processor generated thing. 

So to find it, I think you need to find the parts (like INDEX_op in one pre-
processor command, and the rest in another place), and how it is pasted 
together.

HTH.

Brad

[Qemu-devel] [PATCH 3/4] usb: remove fallback to bNumInterfaces if no .nif

[Brad Hards]

All callers have been updated.

Signed-off-by: Brad Hards 
---
 hw/usb-desc.c |5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/hw/usb-desc.c b/hw/usb-desc.c
index 62591f2..a784155 100644
--- a/hw/usb-desc.c
+++ b/hw/usb-desc.c
@@ -76,7 +76,7 @@ int usb_desc_config(const USBDescConfig *conf, uint8_t *dest, 
size_t len)
 {
 uint8_t  bLength = 0x09;
 uint16_t wTotalLength = 0;
-int i, rc, count;
+int i, rc;
 
 if (len < bLength) {
 return -1;
@@ -91,8 +91,7 @@ int usb_desc_config(const USBDescConfig *conf, uint8_t *dest, 
size_t len)
 dest[0x08] = conf->bMaxPower;
 wTotalLength += bLength;
 
-count = conf->nif ? conf->nif : conf->bNumInterfaces;
-for (i = 0; i < count; i++) {
+for (i = 0; i < conf->nif; i++) {
 rc = usb_desc_iface(conf->ifs + i, dest + wTotalLength, len - 
wTotalLength);
 if (rc < 0) {
 return rc;
-- 
1.7.1

[Qemu-devel] [PATCH 4/4] usb: add support for "grouped" interfaces and the Interface Association Descriptor

[Brad Hards]

This is used for some devices that have multiple interfaces that form a logic
device. An example is Video Class, which has a Control interface and a
Streaming interface. There can be additional interfaces on the same (physical)
devices (e.g. a microphone), and Interface Association Descriptor handles this
case.

Signed-off-by: Brad Hards 
---
 hw/usb-desc.c |   47 +++
 hw/usb-desc.h |   20 
 hw/usb.h  |1 +
 3 files changed, 68 insertions(+), 0 deletions(-)

diff --git a/hw/usb-desc.c b/hw/usb-desc.c
index a784155..8367c45 100644
--- a/hw/usb-desc.c
+++ b/hw/usb-desc.c
@@ -91,6 +91,18 @@ int usb_desc_config(const USBDescConfig *conf, uint8_t 
*dest, size_t len)
 dest[0x08] = conf->bMaxPower;
 wTotalLength += bLength;
 
+/* handle grouped interfaces if any*/
+for (i = 0; i < conf->nif_groups; i++) {
+rc = usb_desc_iface_group(&(conf->if_groups[i]),
+  dest + wTotalLength,
+  len - wTotalLength);
+if (rc < 0) {
+return rc;
+}
+wTotalLength += rc;
+}
+
+/* handle normal (ungrouped / no IAD) interfaces if any */
 for (i = 0; i < conf->nif; i++) {
 rc = usb_desc_iface(conf->ifs + i, dest + wTotalLength, len - 
wTotalLength);
 if (rc < 0) {
@@ -104,6 +116,41 @@ int usb_desc_config(const USBDescConfig *conf, uint8_t 
*dest, size_t len)
 return wTotalLength;
 }
 
+int usb_desc_iface_group(const USBDescIfaceAssoc *iad, uint8_t *dest,
+ size_t len)
+{
+int pos = 0;
+int i = 0;
+
+/* handle interface association descriptor */
+uint8_t bLength = 0x08;
+
+if (len < bLength) {
+return -1;
+}
+
+dest[0x00] = bLength;
+dest[0x01] = USB_DT_INTERFACE_ASSOC;
+dest[0x02] = iad->bFirstInterface;
+dest[0x03] = iad->bInterfaceCount;
+dest[0x04] = iad->bFunctionClass;
+dest[0x05] = iad->bFunctionSubClass;
+dest[0x06] = iad->bFunctionProtocol;
+dest[0x07] = iad->iFunction;
+pos += bLength;
+
+/* handle associated interfaces in this group */
+for (i = 0; i < iad->nif; i++) {
+int rc = usb_desc_iface(&(iad->ifs[i]), dest + pos, len - pos);
+if (rc < 0) {
+return rc;
+}
+pos += rc;
+}
+
+return pos;
+}
+
 int usb_desc_iface(const USBDescIface *iface, uint8_t *dest, size_t len)
 {
 uint8_t bLength = 0x09;
diff --git a/hw/usb-desc.h b/hw/usb-desc.h
index ac734ab..a612515 100644
--- a/hw/usb-desc.h
+++ b/hw/usb-desc.h
@@ -30,6 +30,24 @@ struct USBDescConfig {
 uint8_t   bmAttributes;
 uint8_t   bMaxPower;
 
+/* grouped interfaces */
+uint8_t   nif_groups;
+const USBDescIfaceAssoc   *if_groups;
+
+/* "normal" interfaces */
+uint8_t   nif;
+const USBDescIface*ifs;
+};
+
+/* conceptually an Interface Association Descriptor, and releated interfaces */
+struct USBDescIfaceAssoc {
+uint8_t   bFirstInterface;
+uint8_t   bInterfaceCount;
+uint8_t   bFunctionClass;
+uint8_t   bFunctionSubClass;
+uint8_t   bFunctionProtocol;
+uint8_t   iFunction;
+
 uint8_t   nif;
 const USBDescIface*ifs;
 };
@@ -75,6 +93,8 @@ int usb_desc_device(const USBDescID *id, const USBDescDevice 
*dev,
 int usb_desc_device_qualifier(const USBDescDevice *dev,
   uint8_t *dest, size_t len);
 int usb_desc_config(const USBDescConfig *conf, uint8_t *dest, size_t len);
+int usb_desc_iface_group(const USBDescIfaceAssoc *iad, uint8_t *dest,
+ size_t len);
 int usb_desc_iface(const USBDescIface *iface, uint8_t *dest, size_t len);
 int usb_desc_endpoint(const USBDescEndpoint *ep, uint8_t *dest, size_t len);
 int usb_desc_other(const USBDescOther *desc, uint8_t *dest, size_t len);
diff --git a/hw/usb.h b/hw/usb.h
index 418853f..bbdb189 100644
--- a/hw/usb.h
+++ b/hw/usb.h
@@ -141,6 +141,7 @@ typedef struct USBDesc USBDesc;
 typedef struct USBDescID USBDescID;
 typedef struct USBDescDevice USBDescDevice;
 typedef struct USBDescConfig USBDescConfig;
+typedef struct USBDescIfaceAssoc USBDescIfaceAssoc;
 typedef struct USBDescIface USBDescIface;
 typedef struct USBDescEndpoint USBDescEndpoint;
 typedef struct USBDescOther USBDescOther;
-- 
1.7.1

[Qemu-devel] [PATCH 2/4] usb: update config descriptors to identify number of interfaces

[Brad Hards]

Previously we relied on the .bNumInterfaces, but that won't always be
accurate after the introduction of grouped interfaces.

Signed-off-by: Brad Hards 
---
 hw/usb-hid.c|3 +++
 hw/usb-hub.c|1 +
 hw/usb-msd.c|2 ++
 hw/usb-serial.c |1 +
 hw/usb-wacom.c  |1 +
 5 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/hw/usb-hid.c b/hw/usb-hid.c
index c25362c..8a5e2ca 100644
--- a/hw/usb-hid.c
+++ b/hw/usb-hid.c
@@ -211,6 +211,7 @@ static const USBDescDevice desc_device_mouse = {
 .iConfiguration= STR_CONFIG_MOUSE,
 .bmAttributes  = 0xa0,
 .bMaxPower = 50,
+.nif = 1,
 .ifs = &desc_iface_mouse,
 },
 },
@@ -227,6 +228,7 @@ static const USBDescDevice desc_device_tablet = {
 .iConfiguration= STR_CONFIG_TABLET,
 .bmAttributes  = 0xa0,
 .bMaxPower = 50,
+.nif = 1,
 .ifs = &desc_iface_tablet,
 },
 },
@@ -243,6 +245,7 @@ static const USBDescDevice desc_device_keyboard = {
 .iConfiguration= STR_CONFIG_KEYBOARD,
 .bmAttributes  = 0xa0,
 .bMaxPower = 50,
+.nif = 1,
 .ifs = &desc_iface_keyboard,
 },
 },
diff --git a/hw/usb-hub.c b/hw/usb-hub.c
index 3dd31ba..4c19c8c 100644
--- a/hw/usb-hub.c
+++ b/hw/usb-hub.c
@@ -119,6 +119,7 @@ static const USBDescDevice desc_device_hub = {
 .bNumInterfaces= 1,
 .bConfigurationValue   = 1,
 .bmAttributes  = 0xe0,
+.nif = 1,
 .ifs = &desc_iface_hub,
 },
 },
diff --git a/hw/usb-msd.c b/hw/usb-msd.c
index 76f5b02..ea466c5 100644
--- a/hw/usb-msd.c
+++ b/hw/usb-msd.c
@@ -119,6 +119,7 @@ static const USBDescDevice desc_device_full = {
 .bConfigurationValue   = 1,
 .iConfiguration= STR_CONFIG_FULL,
 .bmAttributes  = 0xc0,
+.nif = 1,
 .ifs = &desc_iface_full,
 },
 },
@@ -153,6 +154,7 @@ static const USBDescDevice desc_device_high = {
 .bConfigurationValue   = 1,
 .iConfiguration= STR_CONFIG_HIGH,
 .bmAttributes  = 0xc0,
+.nif = 1,
 .ifs = &desc_iface_high,
 },
 },
diff --git a/hw/usb-serial.c b/hw/usb-serial.c
index 6763d52..48ea0d8 100644
--- a/hw/usb-serial.c
+++ b/hw/usb-serial.c
@@ -146,6 +146,7 @@ static const USBDescDevice desc_device = {
 .bConfigurationValue   = 1,
 .bmAttributes  = 0x80,
 .bMaxPower = 50,
+.nif = 1,
 .ifs = &desc_iface0,
 },
 },
diff --git a/hw/usb-wacom.c b/hw/usb-wacom.c
index 16be7a2..57041a1 100644
--- a/hw/usb-wacom.c
+++ b/hw/usb-wacom.c
@@ -108,6 +108,7 @@ static const USBDescDevice desc_device_wacom = {
 .bConfigurationValue   = 1,
 .bmAttributes  = 0x80,
 .bMaxPower = 40,
+.nif = 1,
 .ifs = &desc_iface_wacom,
 },
 },
-- 
1.7.1

[Qemu-devel] [PATCH 1/4] usb: Add Interface Association Descriptor descriptor type

[Brad Hards]

Signed-off-by: Brad Hards 
---
 hw/usb.h |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/usb.h b/hw/usb.h
index d3d755d..418853f 100644
--- a/hw/usb.h
+++ b/hw/usb.h
@@ -124,6 +124,7 @@
 #define USB_DT_ENDPOINT0x05
 #define USB_DT_DEVICE_QUALIFIER 0x06
 #define USB_DT_OTHER_SPEED_CONFIG   0x07
+#define USB_DT_INTERFACE_ASSOC  0x0B
 
 #define USB_ENDPOINT_XFER_CONTROL  0
 #define USB_ENDPOINT_XFER_ISOC 1
-- 
1.7.1

[Qemu-devel] [PATCH v2 0/4]usb: implement Interface Association Descriptor support

[Brad Hards]

These descriptors are covered in Section 9.6.4 of the USB 3.0 spec, 
but there is a better description in the Intel IAD whitepaper 
(www.usb.org/developers/whitepapers/iadclasscode_r10.pdf).

The short version is that IAD is an extra descriptor type that appears before 
a group (two or more) interface descriptors, that explains which interface 
descriptors make up a virtual device.  So it could look like:
Config Desc
IAD#0
Iface#0
Iface#1
Iface#2
IAD#1
Iface#3
Iface#4

[Check the diagram in the Intel IAD whitepaper if that makes no sense]

The implementation basically introduces the concept of a grouped of
interfaces (with an IAD header), and support for sending it to the
device.

The intended use for this is USB Video class devices, which have a
Control interface and Streaming interface that are a single logical
device.

Changes v2 (from v1):
 - Added Signed-off-by, per CODING_STYLE
 - Fixed bug in altsetting handling (.nif needed instead of .bNumInterfaces)
 - Fixed some whitespace and line-length problems indicated by checkstyle.pl

Diffstat:
 usb-desc.c   |   52 +---
 usb-desc.h   |   20 
 usb-hid.c|3 +++
 usb-hub.c|1 +
 usb-msd.c|2 ++
 usb-serial.c |1 +
 usb-wacom.c  |1 +
 usb.h|2 ++
 8 files changed, 79 insertions(+), 3 deletions(-)

[Qemu-devel] [PATCH 0/4] usb: implement Interface Association Descriptor support

[Brad Hards]

This patchset implements Interface Association Descriptor suppoort.

These descriptors are covered in Section 9.6.4 of the USB 3.0 spec, 
but there is a better description in the Intel IAD whitepaper 
(www.usb.org/developers/whitepapers/iadclasscode_r10.pdf).

The short version is that IAD is an extra descriptor type that appears before 
a group (two or more) interface descriptors, that explains which interface 
descriptors make up a virtual device.  So it could look like:
Config Desc
IAD#0
Iface#0
Iface#1
Iface#2
IAD#1
Iface#3
Iface#4

[Check the diagram in the Intel IAD whitepaper if that makes no sense]

The implementation basically introduces the concept of a grouped of
interfaces (with an IAD header), and support for sending it to the
device.

The intended use for this is USB Video class devices, which have a
Control interface and Streaming interface that are a single logical
device.

[Qemu-devel] [PATCH 3/4] usb: remove fallback to bNumInterfaces if no .nif

[Brad Hards]

All callers have been updated.
---
 hw/usb-desc.c |5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/hw/usb-desc.c b/hw/usb-desc.c
index 62591f2..a784155 100644
--- a/hw/usb-desc.c
+++ b/hw/usb-desc.c
@@ -76,7 +76,7 @@ int usb_desc_config(const USBDescConfig *conf, uint8_t *dest, 
size_t len)
 {
 uint8_t  bLength = 0x09;
 uint16_t wTotalLength = 0;
-int i, rc, count;
+int i, rc;
 
 if (len < bLength) {
 return -1;
@@ -91,8 +91,7 @@ int usb_desc_config(const USBDescConfig *conf, uint8_t *dest, 
size_t len)
 dest[0x08] = conf->bMaxPower;
 wTotalLength += bLength;
 
-count = conf->nif ? conf->nif : conf->bNumInterfaces;
-for (i = 0; i < count; i++) {
+for (i = 0; i < conf->nif; i++) {
 rc = usb_desc_iface(conf->ifs + i, dest + wTotalLength, len - 
wTotalLength);
 if (rc < 0) {
 return rc;
-- 
1.7.0.4

[Qemu-devel] [PATCH 4/4] usb: add support for "grouped" interfaces and the Interface Association Descriptor

[Brad Hards]

This is used for some devices that have multiple interfaces that form a logic
device. An example is Video Class, which has a Control interface and a
Streaming interface. There can be additional interfaces on the same (physical)
devices (e.g. a microphone), and Interface Association Descriptor handles this
case.
---
 hw/usb-desc.c |   46 ++
 hw/usb-desc.h |   19 +++
 hw/usb.h  |1 +
 3 files changed, 66 insertions(+), 0 deletions(-)

diff --git a/hw/usb-desc.c b/hw/usb-desc.c
index a784155..21c6feb 100644
--- a/hw/usb-desc.c
+++ b/hw/usb-desc.c
@@ -91,6 +91,18 @@ int usb_desc_config(const USBDescConfig *conf, uint8_t 
*dest, size_t len)
 dest[0x08] = conf->bMaxPower;
 wTotalLength += bLength;
 
+/* handle grouped interfaces if any*/
+for (i = 0; i < conf->nif_groups; i++) {
+rc = usb_desc_iface_group(&(conf->if_groups[i]),
+  dest + wTotalLength,
+  len - wTotalLength);
+if (rc < 0) {
+return rc;
+}
+wTotalLength += rc;
+}
+
+/* handle normal (ungrouped / no IAD) interfaces if any */
 for (i = 0; i < conf->nif; i++) {
 rc = usb_desc_iface(conf->ifs + i, dest + wTotalLength, len - 
wTotalLength);
 if (rc < 0) {
@@ -104,6 +116,40 @@ int usb_desc_config(const USBDescConfig *conf, uint8_t 
*dest, size_t len)
 return wTotalLength;
 }
 
+int usb_desc_iface_group(const USBDescIfaceAssoc *iad, uint8_t *dest, size_t 
len)
+{
+int pos = 0;
+int i = 0;
+
+/* handle interface association descriptor */
+uint8_t bLength = 0x08;
+
+if (len < bLength) {
+return -1;
+}
+
+dest[0x00] = bLength;
+dest[0x01] = USB_DT_INTERFACE_ASSOC;
+dest[0x02] = iad->bFirstInterface;
+dest[0x03] = iad->bInterfaceCount;
+dest[0x04] = iad->bFunctionClass;
+dest[0x05] = iad->bFunctionSubClass;
+dest[0x06] = iad->bFunctionProtocol;
+dest[0x07] = iad->iFunction;
+pos += bLength;
+
+/* handle associated interfaces in this group */
+for (i = 0; i < iad->bInterfaceCount; i++) {
+int rc = usb_desc_iface(&(iad->ifs[i]), dest + pos, len - pos);
+if (rc < 0) {
+return rc;
+}
+pos += rc;
+}
+
+return pos;
+}
+
 int usb_desc_iface(const USBDescIface *iface, uint8_t *dest, size_t len)
 {
 uint8_t bLength = 0x09;
diff --git a/hw/usb-desc.h b/hw/usb-desc.h
index ac734ab..6a0c49a 100644
--- a/hw/usb-desc.h
+++ b/hw/usb-desc.h
@@ -30,6 +30,24 @@ struct USBDescConfig {
 uint8_t   bmAttributes;
 uint8_t   bMaxPower;
 
+/* grouped interfaces */
+uint8_t   nif_groups;
+const USBDescIfaceAssoc   *if_groups;
+
+/* "normal" interfaces */
+uint8_t   nif;
+const USBDescIface*ifs;
+};
+
+/* conceptually an Interface Association Descriptor, and releated interfaces */
+struct USBDescIfaceAssoc {
+uint8_t   bFirstInterface;
+uint8_t   bInterfaceCount;
+uint8_t   bFunctionClass;
+uint8_t   bFunctionSubClass;
+uint8_t   bFunctionProtocol;
+uint8_t   iFunction;
+
 uint8_t   nif;
 const USBDescIface*ifs;
 };
@@ -75,6 +93,7 @@ int usb_desc_device(const USBDescID *id, const USBDescDevice 
*dev,
 int usb_desc_device_qualifier(const USBDescDevice *dev,
   uint8_t *dest, size_t len);
 int usb_desc_config(const USBDescConfig *conf, uint8_t *dest, size_t len);
+int usb_desc_iface_group(const USBDescIfaceAssoc *iad, uint8_t *dest, size_t 
len);
 int usb_desc_iface(const USBDescIface *iface, uint8_t *dest, size_t len);
 int usb_desc_endpoint(const USBDescEndpoint *ep, uint8_t *dest, size_t len);
 int usb_desc_other(const USBDescOther *desc, uint8_t *dest, size_t len);
diff --git a/hw/usb.h b/hw/usb.h
index 418853f..bbdb189 100644
--- a/hw/usb.h
+++ b/hw/usb.h
@@ -141,6 +141,7 @@ typedef struct USBDesc USBDesc;
 typedef struct USBDescID USBDescID;
 typedef struct USBDescDevice USBDescDevice;
 typedef struct USBDescConfig USBDescConfig;
+typedef struct USBDescIfaceAssoc USBDescIfaceAssoc;
 typedef struct USBDescIface USBDescIface;
 typedef struct USBDescEndpoint USBDescEndpoint;
 typedef struct USBDescOther USBDescOther;
-- 
1.7.0.4

[Qemu-devel] [PATCH 2/4] usb: update config descriptors to identify number of interfaces

[Brad Hards]

Previously we relied on the .bNumInterfaces, but that won't always be
accurate after the introduction of grouped interfaces.
---
 hw/usb-hid.c|3 +++
 hw/usb-hub.c|1 +
 hw/usb-msd.c|2 ++
 hw/usb-serial.c |1 +
 hw/usb-wacom.c  |1 +
 5 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/hw/usb-hid.c b/hw/usb-hid.c
index c25362c..8a5e2ca 100644
--- a/hw/usb-hid.c
+++ b/hw/usb-hid.c
@@ -211,6 +211,7 @@ static const USBDescDevice desc_device_mouse = {
 .iConfiguration= STR_CONFIG_MOUSE,
 .bmAttributes  = 0xa0,
 .bMaxPower = 50,
+.nif = 1,
 .ifs = &desc_iface_mouse,
 },
 },
@@ -227,6 +228,7 @@ static const USBDescDevice desc_device_tablet = {
 .iConfiguration= STR_CONFIG_TABLET,
 .bmAttributes  = 0xa0,
 .bMaxPower = 50,
+.nif = 1,
 .ifs = &desc_iface_tablet,
 },
 },
@@ -243,6 +245,7 @@ static const USBDescDevice desc_device_keyboard = {
 .iConfiguration= STR_CONFIG_KEYBOARD,
 .bmAttributes  = 0xa0,
 .bMaxPower = 50,
+.nif = 1,
 .ifs = &desc_iface_keyboard,
 },
 },
diff --git a/hw/usb-hub.c b/hw/usb-hub.c
index 3dd31ba..4c19c8c 100644
--- a/hw/usb-hub.c
+++ b/hw/usb-hub.c
@@ -119,6 +119,7 @@ static const USBDescDevice desc_device_hub = {
 .bNumInterfaces= 1,
 .bConfigurationValue   = 1,
 .bmAttributes  = 0xe0,
+.nif = 1,
 .ifs = &desc_iface_hub,
 },
 },
diff --git a/hw/usb-msd.c b/hw/usb-msd.c
index 76f5b02..ea466c5 100644
--- a/hw/usb-msd.c
+++ b/hw/usb-msd.c
@@ -119,6 +119,7 @@ static const USBDescDevice desc_device_full = {
 .bConfigurationValue   = 1,
 .iConfiguration= STR_CONFIG_FULL,
 .bmAttributes  = 0xc0,
+.nif = 1,
 .ifs = &desc_iface_full,
 },
 },
@@ -153,6 +154,7 @@ static const USBDescDevice desc_device_high = {
 .bConfigurationValue   = 1,
 .iConfiguration= STR_CONFIG_HIGH,
 .bmAttributes  = 0xc0,
+.nif = 1,
 .ifs = &desc_iface_high,
 },
 },
diff --git a/hw/usb-serial.c b/hw/usb-serial.c
index 6763d52..48ea0d8 100644
--- a/hw/usb-serial.c
+++ b/hw/usb-serial.c
@@ -146,6 +146,7 @@ static const USBDescDevice desc_device = {
 .bConfigurationValue   = 1,
 .bmAttributes  = 0x80,
 .bMaxPower = 50,
+.nif = 1,
 .ifs = &desc_iface0,
 },
 },
diff --git a/hw/usb-wacom.c b/hw/usb-wacom.c
index 16be7a2..57041a1 100644
--- a/hw/usb-wacom.c
+++ b/hw/usb-wacom.c
@@ -108,6 +108,7 @@ static const USBDescDevice desc_device_wacom = {
 .bConfigurationValue   = 1,
 .bmAttributes  = 0x80,
 .bMaxPower = 40,
+.nif = 1,
 .ifs = &desc_iface_wacom,
 },
 },
-- 
1.7.0.4

[Qemu-devel] [PATCH 1/4] usb: Add Interface Association Descriptor descriptor type

[Brad Hards]

---
 hw/usb.h |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/usb.h b/hw/usb.h
index d3d755d..418853f 100644
--- a/hw/usb.h
+++ b/hw/usb.h
@@ -124,6 +124,7 @@
 #define USB_DT_ENDPOINT0x05
 #define USB_DT_DEVICE_QUALIFIER 0x06
 #define USB_DT_OTHER_SPEED_CONFIG   0x07
+#define USB_DT_INTERFACE_ASSOC  0x0B
 
 #define USB_ENDPOINT_XFER_CONTROL  0
 #define USB_ENDPOINT_XFER_ISOC 1
-- 
1.7.0.4

[Qemu-devel] Request for suggestions: USB Interface Association Descriptors

[Brad Hards]

Hi,

I've just started the learning process on QEMU, and am trying to create a USB 
webcam virtual device (targetting the Linux UVC driver). So far, I'm able to 
create the device, plug it in (thanks to those involved in qdev), and inspect 
the descriptor.

The problem is building the descriptor, and particularly how to do an 
Interface Association Descriptor. This is covered in Section 9.6.4 of the USB 
3.0 spec, but there is a better description in the Intel IAD whitepaper 
(www.usb.org/developers/whitepapers/iadclasscode_r10.pdf).

The short version is that IAD is an extra descriptor type that appears before 
a group (two or more) interface descriptors, that explains which interface 
descriptors make up a virtual device.  So it could look like:
Config Desc
IAD#0
Iface#0
Iface#1
Iface#2
IAD#1
Iface#3
Iface#4

[Check the diagram in the Intel IAD whitepaper if that makes no sense]

I've managed to make the USB descriptor code produce my descriptor, but the 
change has (at least) two problems I'd appreciate suggestions on how to fix:
1. I can only do the simple case where there is 0 or 1 IADs.
2. The change impacts on every USB configuration descriptor, even though IAD 
isn't very common.

Here is what I'm currently doing in any case (not complete - I haven't 
converted over all the existing device to have the .niad = 0 bit, since I got 
a bad feeling about it.  Not sure what the problem is - it just feels a bit 
wrong).

Suggestions?

Brad

--- a/hw/usb-desc.c
+++ b/hw/usb-desc.c
@@ -91,6 +91,15 @@ int usb_desc_config(const USBDescConfig *conf, uint8_t 
*dest, 
size_t len)
 dest[0x08] = conf->bMaxPower;
 wTotalLength += bLength;
 
+/* handle Interface Association Descriptor, if present */
+if (conf->niad != 0) {
+rc = usb_desc_iad(conf->iad, dest + wTotalLength, len - 
wTotalLength);
+if (rc < 0) {
+return rc;
+}
+wTotalLength += rc;
+}
+
 count = conf->nif ? conf->nif : conf->bNumInterfaces;
 for (i = 0; i < count; i++) {
 rc = usb_desc_iface(conf->ifs + i, dest + wTotalLength, len - 
wTotalLength);
@@ -105,6 +114,26 @@ int usb_desc_config(const USBDescConfig *conf, uint8_t 
*dest, size_t len)
 return wTotalLength;
 }
 
+int usb_desc_iad(const USBDescIfaceAssoc *iad, uint8_t *dest, size_t len)
+{
+uint8_t bLength = 0x08;
+
+if (len < bLength) {
+return -1;
+}
+
+dest[0x00] = bLength;
+dest[0x01] = USB_DT_INTERFACE_ASSOC;
+dest[0x02] = iad->bFirstInterface;
+dest[0x03] = iad->bInterfaceCount;
+dest[0x04] = iad->bFunctionClass;
+dest[0x05] = iad->bFunctionSubClass;
+dest[0x06] = iad->bFunctionProtocol;
+dest[0x07] = iad->iFunction;
+
+return bLength;
+}
+
 int usb_desc_iface(const USBDescIface *iface, uint8_t *dest, size_t len)
 {
 uint8_t bLength = 0x09;
diff --git a/hw/usb-desc.h b/hw/usb-desc.h
index ac734ab..cf5f794 100644
--- a/hw/usb-desc.h
+++ b/hw/usb-desc.h
@@ -30,10 +30,22 @@ struct USBDescConfig {
 uint8_t   bmAttributes;
 uint8_t   bMaxPower;
 
+uint8_t   niad; /* 0 or 1 for now */
+const USBDescIfaceAssoc   *iad;
+
 uint8_t   nif;
 const USBDescIface*ifs;
 };
 
+struct USBDescIfaceAssoc {
+uint8_t   bFirstInterface;
+uint8_t   bInterfaceCount;
+uint8_t   bFunctionClass;
+uint8_t   bFunctionSubClass;
+uint8_t   bFunctionProtocol;
+uint8_t   iFunction;
+};
+
 struct USBDescIface {
 uint8_t   bInterfaceNumber;
 uint8_t   bAlternateSetting;
@@ -75,6 +87,7 @@ int usb_desc_device(const USBDescID *id, const USBDescDevice 
*dev,
 int usb_desc_device_qualifier(const USBDescDevice *dev,
   uint8_t *dest, size_t len);
 int usb_desc_config(const USBDescConfig *conf, uint8_t *dest, size_t len);
+int usb_desc_iad(const USBDescIfaceAssoc *iad, uint8_t *dest, size_t len);
 int usb_desc_iface(const USBDescIface *iface, uint8_t *dest, size_t len);
 int usb_desc_endpoint(const USBDescEndpoint *ep, uint8_t *dest, size_t len);
 int usb_desc_other(const USBDescOther *desc, uint8_t *dest, size_t len);
diff --git a/hw/usb-hid.c b/hw/usb-hid.c
index c25362c..acbcddc 100644
--- a/hw/usb-hid.c
+++ b/hw/usb-hid.c
@@ -211,6 +211,7 @@ static const USBDescDevice desc_device_mouse = {
 .iConfiguration= STR_CONFIG_MOUSE,
 .bmAttributes  = 0xa0,
 .bMaxPower = 50,
+.niad  = 0,
 .ifs = &desc_iface_mouse,
 },
 },
@@ -227,6 +228,7 @@ static const USBDescDevice desc_device_tablet = {
 .iConfiguration= STR_CONFIG_TABLET,
 .bmAttributes  = 0xa0,
 .bMaxPower = 50,
+.niad  = 0,
 .ifs =

Re: [Qemu-devel] [PATCH 0/2] Let boards state maximum RAM limits in QEMUMachine struct

[Brad Hards]

On Tue, 22 Mar 2011 04:47:18 am Peter Maydell wrote:
> This fairly simple patchset adds a new 'max_ram' field to the QEMUMachine
> structure so that a board model can specify the maximum RAM it will accept.
> We can then produce a friendly diagnostic message when the user tries to
> start qemu with a '-m' option asking for more RAM than that. (Currently
> most of the ARM devboard models respond with an obscure guest crash when
> the guest tries to access RAM and finds device registers instead.)
As a user, I've been bitten by this. Without understanding how qemu works, the 
problem is quite surprising: "all I've done is increased the RAM, and now it 
just crashes".

I don't think my review of the code will count for much, and I'd prefer to see 
the code added rather than not, but you could move the cmd.c macros (MEGABYTES  
and TO_MEGABYTES) to some common header and just use those. They are pretty 
ugly though...

Brad