Re: Are user static builds really dynamically linked ?
On 16/12/2020 11:39, Paolo Bonzini wrote: > On 16/12/20 12:07, Peter Maydell wrote: >> Something has definitely changed here. What you had with 4.2.1 >> is what you should be getting. The obvious suspect is that >> something weird happened in the meson conversion... Ubuntu/Debian maintainer reproduced and confirmed my findings. It's been git-bisect-ed to the addition/use of -static-pie on 'supported' architectures when calling configure with --static at commit 127814629b "configure: Support -static-pie if requested". Using --disable-pie works around it on x86_64 for us. https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1908331 https://salsa.debian.org/qemu-team/qemu/-/merge_requests/16 > Please send the (gzipped) build.ninja file. build.ninja archives with and without --disable-pie can be fetched from: https://iam.tj/projects/qemu/
Are user static builds really dynamically linked ?
user --static builds are apparently resulting in dynamically linked executables (to the glibc library, not other shared objects ) Concise summary: $ file ../qemu-aarch64_v* ../qemu-aarch64_v4.2.1: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=70f5e10ac0eb9b63d7758850e2f18d0a047d4b79, for GNU/Linux 3.2.0, with debug_info, not stripped ../qemu-aarch64_v5.2: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=91fda2fa08f46d1bb6d19b6f72a4819a7c20fd7e, for GNU/Linux 3.2.0, stripped $ ldd ../qemu-aarch64_v* ../qemu-aarch64_v4.2.1: not a dynamic executable ../qemu-aarch64_v5.2: statically linked Between v4.2.1 and HEAD and (trying to) perform git-bisect builds using: $ ../../qemu/configure --disable-system --enable-linux-user --static --target-list=aarch64-linux-user All builds from v5.x onwards report: $ file qemu-aarch64 qemu-aarch64: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=546ba11f0de940f7f3cbfaffae3c2bb54b683386, for GNU/Linux 3.2.0, with debug_info, not stripped Whereas builds of v4.2.1 report: $ file ./aarch64-linux-user/qemu-aarch64 ./aarch64-linux-user/qemu-aarch64: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=70f5e10ac0eb9b63d7758850e2f18d0a047d4b79, for GNU/Linux 3.2.0, with debug_info, not stripped ... the same as the v4.2.0 built by Debian/Ubuntu: $ file /usr/bin/qemu-aarch64-static /usr/bin/qemu-aarch64-static: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=abad039a2cfc5bc87215554230a572b085fbc37a, for GNU/Linux 3.2.0, with debug_info, not stripped This could be a problem because when the executable is dynamically linked to glibc the same glibc version needs to be installed in the chroot and that isn't always possible. I'm unsure whether this is a cosmetic issue of file/ldd reporting or is a regression. Hit this whilst in the process of trying to isolate commits that fixed another issue where using qemu-aarch64 on x86_64 Debian/Ubuntu host with a foreign architecture chroot that results in "handle_cpu_signal received signal outside vCPU context" when doing "chroot debian-buster-aarch64 aptitude full-upgrade".
qemu:handle_cpu_signal received signal outside vCPU context
We're seeing this error on Ubuntu 20.04 amd64 host and aarch64 qemu-aarch64-static chroot when executing 'aptitude': qemu:handle_cpu_signal received signal outside vCPU context qemu:handle_cpu_signal received signal outside vCPU context Research led us to an identical issue report against qemu-m68k [0] where it is reported this issue is resolved in 5.0.0+. Ubuntu 20.04 LTS currently ships v4.2 so I'm trying to identify the commit(s) that resolved this issue so we can test a cherry-pick of the fix. Do you know which commit(s) addressed this? Some suggestions as to the responsible patch have been made but I've not been able to find the patchwork patch [1] content in current upstream which suggests its the wrong patch, it was never merged, or the code has since changed so it is unrecognisable. [0] https://github.com/vivier/qemu-m68k/issues/38 [1] http://patchwork.ozlabs.org/project/qemu-devel/patch/1456850240-21096-1-git-send-email-peter.mayd...@linaro.org/
[Qemu-devel] [Bug 955379] Re: cmake hangs with qemu-arm-static
** Also affects: qemu (Ubuntu) Importance: Undecided Status: New ** Changed in: qemu (Ubuntu) Status: New => Confirmed ** Changed in: qemu (Ubuntu) Milestone: None => ubuntu-16.04.5 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/955379 Title: cmake hangs with qemu-arm-static Status in QEMU: Fix Released Status in Linaro QEMU: Confirmed Status in qemu package in Ubuntu: Confirmed Status in qemu-linaro package in Ubuntu: Confirmed Bug description: I'm using git commit 3e7ecd976b06f... configured with --target-list =arm-linux-user --static in a chroot environment to compile some things. I ran into this problem with both pcl and opencv-2.3.1. cmake consistently freezes at some point during its execution, though in a different spot each time, usually during a step when it's searching for some libraries. For instance, pcl most commonly stops after: [snip] -- Boost version: 1.46.1 -- Found the following Boost libraries: -- system -- filesystem -- thread -- date_time -- checking for module 'eigen3' -- found eigen3, version 3.0.1 which is perplexing because it freezes after finding what it wants, not during the search. When it does get past that point, it does so almost immediately but freezes somewhere else. I'm using 64-bit Ubuntu 11.10 with kernel release 3.0.0-16-generic with an Intel i5. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/955379/+subscriptions
[Qemu-devel] [Bug 998435] Re: qemu-kvm-spice doesn't support spice/qxl installs
This is a show-stopper and regression for many VM scenarios on Precise. A year later we should have a fix for this. ** Changed in: qemu-kvm-spice (Ubuntu) Importance: Undecided = High -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/998435 Title: qemu-kvm-spice doesn't support spice/qxl installs Status in QEMU: Confirmed Status in “qemu-kvm-spice” package in Ubuntu: Confirmed Bug description: Been setup as follows :- boris@boris-P5Q-E:~$ dpkg -l | grep spice ii gir1.2-spice-client-glib-2.0 0.9-0ubuntu1 GObject for communicating with Spice servers (GObject-Introspection) ii gir1.2-spice-client-gtk-2.00.9-0ubuntu1 GTK2 widget for SPICE clients (GObject-Introspection) ii gir1.2-spice-client-gtk-3.00.9-0ubuntu1 GTK3 widget for SPICE clients (GObject-Introspection) ii libspice-client-glib-2.0-1 0.9-0ubuntu1 GObject for communicating with Spice servers (runtime library) ii libspice-client-glib-2.0-dev 0.9-0ubuntu1 GObject for communicating with Spice servers (development files) ii libspice-client-gtk-2.0-1 0.9-0ubuntu1 GTK2 widget for SPICE clients (runtime library) ii libspice-client-gtk-2.0-dev0.9-0ubuntu1 GTK2 widget for SPICE clients (development files) ii libspice-client-gtk-3.0-1 0.9-0ubuntu1 GTK3 widget for SPICE clients (runtime library) ii libspice-client-gtk-3.0-dev0.9-0ubuntu1 GTK3 widget for SPICE clients (development files) ii libspice-protocol-dev 0.10.1-1 SPICE protocol headers ii libspice-server-dev0.10.0-1 Header files and development documentation for spice-server ii libspice-server1 0.10.0-1 Implements the server side of the SPICE protocol ii python-spice-client-gtk0.9-0ubuntu1 GTK2 widget for SPICE clients (Python binding) ii qemu-kvm-spice 1.0.50-2012.03-0ubuntu2 Full virtualization on amd64 hardware Spice/QXL install doesn't work on Ubuntu 12.04 . View also https://bugs.launchpad.net/ubuntu/+source/seabios/+bug/823494 It doesn't look like duplicate of bug mentioned above. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/998435/+subscriptions
[Qemu-devel] Obama, Steve Jobs, the Clintons, Oprah - All the great communicators in one big event!
Hello friend, Great speakers are made not born and the best way to become one is by emulating the masters. EASIER SAID THAN DONE, especially in Malaysia, but not anymore. That's because New York based international presentation, speaking and media coach, TJ Walker is coming to Malaysia. This bestselling author, who has worked with presidents, prime ministers, Nobel laureates, corporate leaders celebrities, will be sharing his speaking strategies, tips tricks with you in Kuala Lumpur, Malaysia, on Wednesday, 7th December, 2011. A prominent feature of TJ Walker's seminars is the use of video clips of great communicators such as Barack Obama, Winston Churchill, the Clintons, Oprah Winfrey and Steve Jobs. TJ dissects each of their performances and identify their strengths. He then shows you how to easily adopt these strengths strategies. TJ Walker's method is so effective that all of his clients have shown tremendous improvement shortly after his session and you are about to join that exclusive club. This is TJ's first visit to Asia and to mark the occasion he has, for the first time in his career, agreed to reduce his fee. Tickets are only priced at RM998 each. There is however a super saver in the form of a Super Early Bird Offer, and your price will be only RM389! These tickets are very limited and it's best to buy yours now. For tickets and further information, head to www.tjwalkerasia.com now! Click here http://www.e-marketinginc.com/iem/link.php?M=330561N=109L=20F=T and Sign up now! Best regards, Maverick Foo TJ Walker Associates P.S.: By the way, many of TJ's clients such as U.S. Army, Bank of America, McGraw-Hill, Ernst and Young, Federal Express and UCLA have engaged him in-house to talk on hot topics such as Crisis Communication, Setting Up A Crisis Management Campaign, small group or one-on-one coaching, and more. If you like to enjoy the same positive results as them by bringing the expert in to engage your people personally, kindly contact Maverick, at m...@plaseed.com, or via his mobile, +60162252500. You can also download a one-pager on the TJ Walker's Strategies to Successful Crisis Communication here http://www.e-marketinginc.com/iem/link.php?M=330561N=109L=24F=T. Click here to Unsubscribe http://www.e-marketinginc.com/iem/unsubscribe.php?M=330561C=e9264b3b7e21991615630b1ad9d6e228L=7N=109, or simply reply to this email and we will remove you from the list, no questions asked. To contact us please email train...@plaseed.com. This email is sent from: TJ Walker Associates (A Plaseed Training Partner) B-5-8, Plaza Mont Kiara,Mont Kiara, 50480 Kuala Lumpur, Malaysia Powered by Interspire
Re: [Qemu-devel] Fwd: [PATCH v2] Guest OS hangs on usb_add
On 11/16/2010 02:55 PM, Anthony Liguori wrote: If you don't like the hack, you can just remove the 3 lines above and use the rest of the patch. I will just have to remember to manually patch mine every time I upgrade. Your thoughts? Yeah, that bit is a bit too gnarly for my tastes, but if you can resend the rest of it with a Signed-off-by, I'd appreciate. Regards, Anthony Liguori -TJ Antonio, Did anything come of this? I resubmitted the patch without the hack, but it don't look like it was committed: http://lists.nongnu.org/archive/html/qemu-devel/2010-11/msg01496.html Ciao, TJ
Re: [Qemu-devel] Fwd: [PATCH v2] Guest OS hangs on usb_add
On 11/16/2010 10:00 AM, Anthony Liguori wrote: On 11/02/2010 09:51 AM, TJ wrote: Doesn't look like this has ever been committed. qemu-kvm-0.13 has just arrived to the portage tree, but I am still having problems with it. I checked the git log and it's not there! Please commit. One off device hacks are concerning because it's basically impossible to review. Why does this work on bare metal? Regards, Anthony Liguori Probably because bare metal USB 2.0 controllers don't give a damn about USB 3 spec. :) My guess is that they ignore the device descriptor length and assume that it's always equal 18. Although the USB 2.0 spec doesn't explicitly say anywhere that it can't be more than 18. IIRC USB 3 even adds some extensions to the device descriptor. And since I wanted my code to be portable and USB 3 ready ;) I rely on the value in dev_descr_len. BTW, this patch is more than just a hack for the device in question. Without this patch qemu simply locks up when I attach the remote and spins in endless loop, because USB parsing is so very primitive. With this patch, USB parsing is done more intelligently and devices with whacky USB descriptors are simply rejected. The hack part is really just 3 lines: +if (dev_descr_len == 0x18 dev-descr[ 8] == 0x47 dev-descr[ 9] == 0x46 + dev-descr[10] == 0x00 dev-descr[11] == 0x30) +dev_descr_len = USB_DT_DEVICE_LEN; /* for buggy MX-950 remote reporting len in hex */ And it is very harmless, as all it does is overwrites the device descriptor length with correct one. If you don't like the hack, you can just remove the 3 lines above and use the rest of the patch. I will just have to remember to manually patch mine every time I upgrade. Your thoughts? -TJ
[Qemu-devel] [PATCH v3] Guest OS hangs on usb_add
This is a small patch to slightly intelligentify usb device and
config descriptor parsing. MX-950 bug work-around is not included.
Signed-off-by: Timothy Jones one.timothy.jo...@gmail.com
---
hw/usb.h|5 +
usb-linux.c | 34 +++---
2 files changed, 24 insertions(+), 15 deletions(-)
diff --git a/hw/usb.h b/hw/usb.h
index 00d2802..5c3528f 100644
--- a/hw/usb.h
+++ b/hw/usb.h
@@ -117,6 +117,11 @@
#define USB_DT_INTERFACE 0x04
#define USB_DT_ENDPOINT0x05
+#define USB_DT_DEVICE_LEN 18
+#define USB_DT_CONFIG_LEN 9
+#define USB_DT_INTERFACE_LEN 9
+#define USB_DT_ENDPOINT_LEN7
+
#define USB_ENDPOINT_XFER_CONTROL 0
#define USB_ENDPOINT_XFER_ISOC 1
#define USB_ENDPOINT_XFER_BULK 2
diff --git a/usb-linux.c b/usb-linux.c
index c3c38ec..cf20399 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -290,7 +290,7 @@ static void async_cancel(USBPacket *unused, void *opaque)
static int usb_host_claim_interfaces(USBHostDevice *dev, int configuration)
{
-int dev_descr_len, config_descr_len;
+int dev_descr_len, config_descr_total_len;
int interface, nb_interfaces;
int ret, i;
@@ -299,32 +299,36 @@ static int usb_host_claim_interfaces(USBHostDevice *dev,
int configuration)
DPRINTF(husb: claiming interfaces. config %d\n, configuration);
-i = 0;
dev_descr_len = dev-descr[0];
-if (dev_descr_len dev-descr_len) {
+
+if (dev_descr_len dev-descr_len || dev_descr_len USB_DT_DEVICE_LEN ||
dev-descr[1] != USB_DT_DEVICE) {
+fprintf(stderr, husb: invalid device descriptor\n);
goto fail;
}
-i += dev_descr_len;
-while (i dev-descr_len) {
+for (i = dev_descr_len; i dev-descr_len; ) {
DPRINTF(husb: i is %d, descr_len is %d, dl %d, dt %d\n,
i, dev-descr_len,
dev-descr[i], dev-descr[i+1]);
-if (dev-descr[i+1] != USB_DT_CONFIG) {
-i += dev-descr[i];
-continue;
+if (dev-descr[i] 2) {
+fprintf(stderr, husb: invalid descriptor\n);
+goto fail;
}
-config_descr_len = dev-descr[i];
+if (dev-descr[i+1] == USB_DT_CONFIG) {
+config_descr_total_len = dev-descr[i+2] + (dev-descr[i+3] 8);
-printf(husb: config #%d need %d\n, dev-descr[i + 5], configuration);
+printf(husb: config #%d need %d\n, dev-descr[i + 5],
configuration);
-if (configuration 0 || configuration == dev-descr[i + 5]) {
-configuration = dev-descr[i + 5];
-break;
-}
+if (configuration 0 || configuration == dev-descr[i + 5]) {
+configuration = dev-descr[i + 5];
+break;
+}
-i += config_descr_len;
+i += config_descr_total_len;
+}
+else
+i += dev-descr[i];
}
if (i = dev-descr_len) {
--
1.7.2.2
[Qemu-devel] Fwd: [PATCH v2] Guest OS hangs on usb_add
Doesn't look like this has ever been committed. qemu-kvm-0.13 has just arrived
to the portage tree, but I am still having problems with it. I checked the git
log and it's not there! Please commit.
-TJ
Original Message
Subject: [PATCH v2] Guest OS hangs on usb_add
Date: Mon, 28 Jun 2010 10:47:03 -0400
From: TJ one.timothy.jo...@gmail.com
To: qemu-devel@nongnu.org qemu-devel@nongnu.org
CC: Gianni Tedesco gianni.tede...@citrix.com
This is a small patch to sligtly intelligentify usb device and
config descriptor parsing and to handle bug with certain usb
device (URC MX-950) reporting device desriptor length as 0x18
instead of 18 with added vendor_id/product_id check
---
hw/usb.h|5 +
usb-linux.c | 37 ++---
2 files changed, 27 insertions(+), 15 deletions(-)
diff --git a/hw/usb.h b/hw/usb.h
index 00d2802..5c3528f 100644
--- a/hw/usb.h
+++ b/hw/usb.h
@@ -117,6 +117,11 @@
#define USB_DT_INTERFACE 0x04
#define USB_DT_ENDPOINT0x05
+#define USB_DT_DEVICE_LEN 18
+#define USB_DT_CONFIG_LEN 9
+#define USB_DT_INTERFACE_LEN 9
+#define USB_DT_ENDPOINT_LEN7
+
#define USB_ENDPOINT_XFER_CONTROL 0
#define USB_ENDPOINT_XFER_ISOC 1
#define USB_ENDPOINT_XFER_BULK 2
diff --git a/usb-linux.c b/usb-linux.c
index 88273ff..2ac6562 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -288,7 +288,7 @@ static void async_cancel(USBPacket *unused, void *opaque)
static int usb_host_claim_interfaces(USBHostDevice *dev, int configuration)
{
-int dev_descr_len, config_descr_len;
+int dev_descr_len, config_descr_total_len;
int interface, nb_interfaces;
int ret, i;
@@ -297,32 +297,39 @@ static int usb_host_claim_interfaces(USBHostDevice *dev,
int configuration)
DPRINTF(husb: claiming interfaces. config %d\n, configuration);
-i = 0;
dev_descr_len = dev-descr[0];
-if (dev_descr_len dev-descr_len) {
+if (dev_descr_len == 0x18 dev-descr[ 8] == 0x47 dev-descr[ 9] ==
0x46
+ dev-descr[10] == 0x00 dev-descr[11] ==
0x30)
+dev_descr_len = USB_DT_DEVICE_LEN; /* for buggy MX-950 remote reporting
len in hex */
+
+if (dev_descr_len dev-descr_len || dev_descr_len USB_DT_DEVICE_LEN ||
dev-descr[1] != USB_DT_DEVICE) {
+fprintf(stderr, husb: invalid device descriptor\n);
goto fail;
}
-i += dev_descr_len;
-while (i dev-descr_len) {
+for (i = dev_descr_len; i dev-descr_len; ) {
DPRINTF(husb: i is %d, descr_len is %d, dl %d, dt %d\n,
i, dev-descr_len,
dev-descr[i], dev-descr[i+1]);
-if (dev-descr[i+1] != USB_DT_CONFIG) {
-i += dev-descr[i];
-continue;
+if (dev-descr[i] 2) {
+fprintf(stderr, husb: invalid descriptor\n);
+goto fail;
}
-config_descr_len = dev-descr[i];
+if (dev-descr[i+1] == USB_DT_CONFIG) {
+config_descr_total_len = dev-descr[i+2] + (dev-descr[i+3] 8);
-printf(husb: config #%d need %d\n, dev-descr[i + 5], configuration);
+printf(husb: config #%d need %d\n, dev-descr[i + 5],
configuration);
-if (configuration 0 || configuration == dev-descr[i + 5]) {
-configuration = dev-descr[i + 5];
-break;
-}
+if (configuration 0 || configuration == dev-descr[i + 5]) {
+configuration = dev-descr[i + 5];
+break;
+}
-i += config_descr_len;
+i += config_descr_total_len;
+}
+else
+i += dev-descr[i];
}
if (i = dev-descr_len) {
Re: [Qemu-devel] Guest OS hangs on usb_add
On 06/28/10 08:32, Gianni Tedesco wrote: FWIW, I am signing off on your approach :) Gianni Tedesco Thank you Gianni :) I am gonna add simple vend/prod id check to my 0x18 hack and resubmit final version. -TJ
[Qemu-devel] [PATCH v2] Guest OS hangs on usb_add
This is a small patch to sligtly intelligentify usb device and
config descriptor parsing and to handle bug with certain usb
device (URC MX-950) reporting device desriptor length as 0x18
instead of 18 with added vendor_id/product_id check
---
hw/usb.h|5 +
usb-linux.c | 37 ++---
2 files changed, 27 insertions(+), 15 deletions(-)
diff --git a/hw/usb.h b/hw/usb.h
index 00d2802..5c3528f 100644
--- a/hw/usb.h
+++ b/hw/usb.h
@@ -117,6 +117,11 @@
#define USB_DT_INTERFACE 0x04
#define USB_DT_ENDPOINT0x05
+#define USB_DT_DEVICE_LEN 18
+#define USB_DT_CONFIG_LEN 9
+#define USB_DT_INTERFACE_LEN 9
+#define USB_DT_ENDPOINT_LEN7
+
#define USB_ENDPOINT_XFER_CONTROL 0
#define USB_ENDPOINT_XFER_ISOC 1
#define USB_ENDPOINT_XFER_BULK 2
diff --git a/usb-linux.c b/usb-linux.c
index 88273ff..2ac6562 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -288,7 +288,7 @@ static void async_cancel(USBPacket *unused, void *opaque)
static int usb_host_claim_interfaces(USBHostDevice *dev, int configuration)
{
-int dev_descr_len, config_descr_len;
+int dev_descr_len, config_descr_total_len;
int interface, nb_interfaces;
int ret, i;
@@ -297,32 +297,39 @@ static int usb_host_claim_interfaces(USBHostDevice *dev,
int configuration)
DPRINTF(husb: claiming interfaces. config %d\n, configuration);
-i = 0;
dev_descr_len = dev-descr[0];
-if (dev_descr_len dev-descr_len) {
+if (dev_descr_len == 0x18 dev-descr[ 8] == 0x47 dev-descr[ 9] ==
0x46
+ dev-descr[10] == 0x00 dev-descr[11] ==
0x30)
+dev_descr_len = USB_DT_DEVICE_LEN; /* for buggy MX-950 remote reporting
len in hex */
+
+if (dev_descr_len dev-descr_len || dev_descr_len USB_DT_DEVICE_LEN ||
dev-descr[1] != USB_DT_DEVICE) {
+fprintf(stderr, husb: invalid device descriptor\n);
goto fail;
}
-i += dev_descr_len;
-while (i dev-descr_len) {
+for (i = dev_descr_len; i dev-descr_len; ) {
DPRINTF(husb: i is %d, descr_len is %d, dl %d, dt %d\n,
i, dev-descr_len,
dev-descr[i], dev-descr[i+1]);
-if (dev-descr[i+1] != USB_DT_CONFIG) {
-i += dev-descr[i];
-continue;
+if (dev-descr[i] 2) {
+fprintf(stderr, husb: invalid descriptor\n);
+goto fail;
}
-config_descr_len = dev-descr[i];
+if (dev-descr[i+1] == USB_DT_CONFIG) {
+config_descr_total_len = dev-descr[i+2] + (dev-descr[i+3] 8);
-printf(husb: config #%d need %d\n, dev-descr[i + 5], configuration);
+printf(husb: config #%d need %d\n, dev-descr[i + 5],
configuration);
-if (configuration 0 || configuration == dev-descr[i + 5]) {
-configuration = dev-descr[i + 5];
-break;
-}
+if (configuration 0 || configuration == dev-descr[i + 5]) {
+configuration = dev-descr[i + 5];
+break;
+}
-i += config_descr_len;
+i += config_descr_total_len;
+}
+else
+i += dev-descr[i];
}
if (i = dev-descr_len) {
Re: [Qemu-devel] Guest OS hangs on usb_add
On 06/25/10 12:32, Gianni Tedesco wrote:
A device MAY provide extended descriptors in 2 ways mentioned in the
spec, but ISTR finding at least one device in the wild with standard
descriptors extended which were not so much used by the host but by
application software. So not sure about your patch, a quirks blacklist
based on idDevice/idProduct might be the better fix here.
Makes sense. I should add vend/prod id check.
However the more serious problem is spinning on zero length descriptor
when truncated descriptors are not valid and zero length (in fact 2)
is totally unacceptable. Following patch checks for truncation.
Gianni, Please check my later patch submitted last night. I basically did the
same thing you did, but with few differences:
- if descriptor size is 2, goto fail
- if the descriptor is USB_DT_CONFIG, we can skip through all the sub
descriptors using wTotalLength field.
- otherwise, simply skip it
One thing to also watch out for is the string descriptors. I might be wrong, but
it appears (from reading the doc) that string descriptors (at least for the
device descriptor) can be interspersed with the config descriptors, in which
case (config_descr_len USB_DT_CONFIG_SIZE) without checking descriptor type
might unwittingly lead to failure.
-TJ
diff --git a/hw/usb.h b/hw/usb.h
index 00d2802..efd4a65 100644
--- a/hw/usb.h
+++ b/hw/usb.h
@@ -117,6 +117,14 @@
#define USB_DT_INTERFACE 0x04
#define USB_DT_ENDPOINT 0x05
+/*
+ * Descriptor sizes per descriptor type
+ */
+#define USB_DT_DEVICE_SIZE 18
+#define USB_DT_CONFIG_SIZE 9
+#define USB_DT_INTERFACE_SIZE9
+#define USB_DT_ENDPOINT_SIZE 7
+
#define USB_ENDPOINT_XFER_CONTROL0
#define USB_ENDPOINT_XFER_ISOC 1
#define USB_ENDPOINT_XFER_BULK 2
diff --git a/usb-linux.c b/usb-linux.c
index 88273ff..d259290 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -299,7 +299,7 @@ static int usb_host_claim_interfaces(USBHostDevice *dev,
int configuration)
i = 0;
dev_descr_len = dev-descr[0];
-if (dev_descr_len dev-descr_len) {
+if ( dev_descr_len USB_DT_DEVICE_SIZE || dev_descr_len
dev-descr_len) {
goto fail;
}
@@ -314,6 +314,8 @@ static int usb_host_claim_interfaces(USBHostDevice *dev,
int configuration)
continue;
}
config_descr_len = dev-descr[i];
+if ( config_descr_len USB_DT_CONFIG_SIZE )
+goto fail;
printf(husb: config #%d need %d\n, dev-descr[i + 5],
configuration);
Re: [Qemu-devel] Guest OS hangs on usb_add
On 06/24/10 13:59, David S. Ahern wrote:
On 06/23/10 22:45, TJ wrote:
-- Forwarded message --
From: Timothy Jones one.timothy.jo...@gmail.com
Date: Wed, Jun 23, 2010 at 9:07 PM
Subject: Guest OS hangs on usb_add
To: qemu-devel@nongnu.org
With some digging around I found out that the qemu hangs in
usb_host_claim_interfaces, which is caused by screwed up usb
descriptor. The device reports the following:
(gdb) p dev-descr_len
$21 = 50
(gdb) p /x dev-descr...@50
$23 = {0x18, 0x1, 0x0, 0x1, 0xff, 0xff, 0xff, 0x8, 0x47, 0x46, 0x0,
0x30, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1, 0x9, 0x2, 0x20,
0x0, 0x1, 0x1, 0x0, 0x80, 0x19, 0x9, 0x4, 0x0, 0x0, 0x2, 0xff, 0xff,
0xff, 0x0, 0x7, 0x5, 0x81, 0x2, 0x40, 0x0, 0x0,
0x7, 0x5, 0x3, 0x2, 0x10, 0x0, 0x0}
The first 0x18 (Device Descriptor bLength) is supposed to be decimal
18, not hex! According to USB spec, if the device reports size greater
than expected, the host is supposed ignore the extra bytes. So qemu
behaves correctly here. However, with this length, the following
Configuration Descriptor length falls on a 0x0 and so the qemu spins
in an endless loop. (This is prolly something that should be detected
and reported as error by qemu.)
My question is: This 0x18 -- is this something that comes from the
device itself (ie, firmware bug)? Or does it come from the USB
subsystem?
What kind of device is this?
David
Universal Remote Control MX-950
http://www.universalremote.com/product_detail.php?model=35
-TJ
[Qemu-devel] Fwd: [PATCH] Guest OS hangs on usb_add
This is a small patch to sligtly intelligentify usb device and
config descriptor parsing and to handle bug with certain usb
device reporting device desriptor length as 0x18 (instead of 18)
---
hw/usb.h|5 +
usb-linux.c | 36 +---
2 files changed, 26 insertions(+), 15 deletions(-)
diff --git a/hw/usb.h b/hw/usb.h
index 00d2802..5c3528f 100644
--- a/hw/usb.h
+++ b/hw/usb.h
@@ -117,6 +117,11 @@
#define USB_DT_INTERFACE 0x04
#define USB_DT_ENDPOINT0x05
+#define USB_DT_DEVICE_LEN 18
+#define USB_DT_CONFIG_LEN 9
+#define USB_DT_INTERFACE_LEN 9
+#define USB_DT_ENDPOINT_LEN7
+
#define USB_ENDPOINT_XFER_CONTROL 0
#define USB_ENDPOINT_XFER_ISOC 1
#define USB_ENDPOINT_XFER_BULK 2
diff --git a/usb-linux.c b/usb-linux.c
index 88273ff..3ff0856 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -288,7 +288,7 @@ static void async_cancel(USBPacket *unused, void *opaque)
static int usb_host_claim_interfaces(USBHostDevice *dev, int configuration)
{
-int dev_descr_len, config_descr_len;
+int dev_descr_len, config_descr_total_len;
int interface, nb_interfaces;
int ret, i;
@@ -297,32 +297,38 @@ static int usb_host_claim_interfaces(USBHostDevice *dev,
int configuration)
DPRINTF(husb: claiming interfaces. config %d\n, configuration);
-i = 0;
dev_descr_len = dev-descr[0];
-if (dev_descr_len dev-descr_len) {
+if (dev_descr_len == 0x18)
+dev_descr_len = USB_DT_DEVICE_LEN; /* for buggy device(s) reporting len
in hex */
+
+if (dev_descr_len dev-descr_len || dev_descr_len USB_DT_DEVICE_LEN ||
dev-descr[1] != USB_DT_DEVICE) {
+fprintf(stderr, husb: invalid device descriptor\n);
goto fail;
}
-i += dev_descr_len;
-while (i dev-descr_len) {
+for (i = dev_descr_len; i dev-descr_len; ) {
DPRINTF(husb: i is %d, descr_len is %d, dl %d, dt %d\n,
i, dev-descr_len,
dev-descr[i], dev-descr[i+1]);
-if (dev-descr[i+1] != USB_DT_CONFIG) {
-i += dev-descr[i];
-continue;
+if (dev-descr[i] 2) {
+fprintf(stderr, husb: invalid descriptor\n);
+goto fail;
}
-config_descr_len = dev-descr[i];
+if (dev-descr[i+1] == USB_DT_CONFIG) {
+config_descr_total_len = dev-descr[i+2] + (dev-descr[i+3] 8);
-printf(husb: config #%d need %d\n, dev-descr[i + 5], configuration);
+printf(husb: config #%d need %d\n, dev-descr[i + 5],
configuration);
-if (configuration 0 || configuration == dev-descr[i + 5]) {
-configuration = dev-descr[i + 5];
-break;
-}
+if (configuration 0 || configuration == dev-descr[i + 5]) {
+configuration = dev-descr[i + 5];
+break;
+}
-i += config_descr_len;
+i += config_descr_total_len;
+}
+else
+i += dev-descr[i];
}
if (i = dev-descr_len) {
Re: [Qemu-devel] Guest OS hangs on usb_add
On 06/24/10 02:42, Markus Armbruster wrote: A botched up patch is often a pretty effective way to get somebody to fix the thing correctly. OK, I gave it a shot and sent it to the list. Shoulda prolly added a disclaimer in case it blows something up ;) -TJ
[Qemu-devel] Guest OS hangs on usb_add
-- Forwarded message --
From: Timothy Jones one.timothy.jo...@gmail.com
Date: Wed, Jun 23, 2010 at 9:07 PM
Subject: Guest OS hangs on usb_add
To: qemu-devel@nongnu.org
With some digging around I found out that the qemu hangs in
usb_host_claim_interfaces, which is caused by screwed up usb
descriptor. The device reports the following:
(gdb) p dev-descr_len
$21 = 50
(gdb) p /x dev-descr...@50
$23 = {0x18, 0x1, 0x0, 0x1, 0xff, 0xff, 0xff, 0x8, 0x47, 0x46, 0x0,
0x30, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1, 0x9, 0x2, 0x20,
0x0, 0x1, 0x1, 0x0, 0x80, 0x19, 0x9, 0x4, 0x0, 0x0, 0x2, 0xff, 0xff,
0xff, 0x0, 0x7, 0x5, 0x81, 0x2, 0x40, 0x0, 0x0,
0x7, 0x5, 0x3, 0x2, 0x10, 0x0, 0x0}
The first 0x18 (Device Descriptor bLength) is supposed to be decimal
18, not hex! According to USB spec, if the device reports size greater
than expected, the host is supposed ignore the extra bytes. So qemu
behaves correctly here. However, with this length, the following
Configuration Descriptor length falls on a 0x0 and so the qemu spins
in an endless loop. (This is prolly something that should be detected
and reported as error by qemu.)
My question is: This 0x18 -- is this something that comes from the
device itself (ie, firmware bug)? Or does it come from the USB
subsystem?
I don't mind writing a small patch to make descriptor parsing a bit
more intelligent, but I am very unfamiliar with the code, so I might
botch things up. Or is the above data sufficient for one of the devs
to take a look at the code and improve it?
Thank you.
-TJ
Here is small patch that fixed my problem.
In looking at the USB spec, it seems pretty clear cut about the whole
device/config/interface/endpoint descriptor hierarchy, so the
usb_host_claim_interfaces can be optimized instead of parsing through each
descriptor to skip through config descriptors using wTotalLength field. And
again, some checks can be done for descriptor types and/or sizes.
Just my 2 cents.
-TJ
--- hw/usb.h.orig 2010-06-23 22:55:27.649182672 -0400
+++ hw/usb.h2010-06-23 22:56:09.937910171 -0400
@@ -117,6 +117,8 @@
#define USB_DT_INTERFACE 0x04
#define USB_DT_ENDPOINT0x05
+#define USB_DT_DEVICE_LEN 18
+
#define USB_ENDPOINT_XFER_CONTROL 0
#define USB_ENDPOINT_XFER_ISOC 1
#define USB_ENDPOINT_XFER_BULK 2
--- usb-linux.c.orig2010-06-23 22:56:23.191339634 -0400
+++ usb-linux.c 2010-06-24 00:08:19.437515669 -0400
@@ -299,6 +299,9 @@
i = 0;
dev_descr_len = dev-descr[0];
+if (dev_descr_len == 0x18)
+dev_descr_len = USB_DT_DEVICE_LEN; /* for buggy device(s) reporting
len in hex */
+
if (dev_descr_len dev-descr_len) {
goto fail;
}
Re: [Qemu-devel] [RFC] linux-user (mostly syscall.c)
I'm glad you posted about your efforts since I've also been working on solving related x86_64 build warnings caused by 32-bit int to 64-bit pointer conversions. warning: cast to pointer from integer of different size There are a lot of these in syscall.c I have in my drafts folder an RFC I was planning to post detailing the issue (1,053 warnings in the x64_64 build) and how to resolve them - some simply require a cast from abi_long/unit32_t to a larger integer storage (same size as host-pointer-size) using the various pre-processor macros and typedefs so the compiler can do implicit conversion from the larger integer type to the pointer. I'll post what I've written so far so it can be considered in conjunction with your work. The title is RFC: x86_64 Best way to fix 'cast to pointer from integer of different size' problems? TJ.
[Qemu-devel] RFC: x86_64 Best way to fix 'cast to pointer from integer of different size' problems?
I'm building on x86_64 GNU/Linux. There are *lots* of (1053) compiler
warnings of the class:
warning: cast to pointer from integer of different size
caused by the various conversions to/from host-to-target pointer and int
types.
On x86 the warnings mostly don't occur. An easy way to get an idea of
the scale of the build problems is to review the Ubuntu build logs for
x86, x86_64, powerpc, and solaris (It's a 0.9.0 build and the solaris
build fails, but the x86_64 build log is clear although the line numbers
don't match CVS).
Fixing it looks to require a variety of fixes, from simple explicit
casts in-line, to some complicated review of multiple levels of macros
to decide where best to apply a fix.
I am aiming to work through all 1053 errors to classify the reasons for
them, and then work up a solution for each class.
If you could review the details here and provide useful feedback and
ides I'd be grateful. I don't want to redo work others are already doing
or go against some implicit techniques hidden in the macro nesting in
particular.
This should be considered alongside Thayne Harbaugh's post [RFC]
linux-user (mostly syscall.c).
Thanks
TJ.
--- specimen details ---
The first warning is also one of the most complex to unravel. It occurs
in linux-user/syscall.c in functions
target_to_host_cmsg()
host_to_target_cmsg()
It is caused by use of the macro TARGET_CMSG_FIRSTHDR (which is a
reworking of the linux macro CMSG_FIRSTHDR defined in
sys/bits/socket.h):
static inline void target_to_host_cmsg(struct msghdr *msgh,
struct target_msghdr *target_msgh)
{
struct target_cmsghdr *target_cmsg = TARGET_CMSG_FIRSTHDR(target_msgh);
The macro is defined thus:
linux-user/syscall_defs.h
#define TARGET_CMSG_FIRSTHDR(mhdr) \
((size_t) tswapl((mhdr)-msg_controllen) = sizeof (struct
target_cmsghdr) \
? (struct target_cmsghdr *) tswapl((mhdr)-msg_control) : (struct
target_cmsghdr *) NULL)
and the pre-processor generates:
struct target_cmsghdr *target_cmsg = ((size_t)
tswap32((target_msgh)-msg_controllen) = sizeof (struct target_cmsghdr) ?
(struct target_cmsghdr *) tswap32((target_msgh)-msg_control) : (struct
target_cmsghdr *) ((void *)0));
The issue is in the 'true' action:
(struct target_cmsghdr *) tswap32((target_msgh)-msg_control)
and the fact that the macro wasn't designed to handle different pointer
sizes. In this case assigning a 32-bit unsigned int to a 64-bit pointer.
The variables are defined as:
linux-user/syscall_defs.h
struct target_msghdr { ...
abi_long msg_control;
linux-user/qemu.h
#ifdef TARGET_ABI32
typedef uint32_t abi_ulong;
typedef int32_t abi_long;
#define TARGET_ABI_BITS 32
and the 'tswap' function as:
cpu-all.h
static inline uint32_t tswap32(uint32_t s)
{
return s;
}
So the compiler assigns the 32-bit value returned by tswap32() to the 64-bit
pointer 'target_cmsg'.
For this case it appears the 'pure' solution would be to use additional
macros along the lines of:
struct target_cmsghdr *target_cmsg = TARGET_TO_HOST_PTR(
TARGET_CMSG_FIRSTHDR(target_msgh));
and define new macros along the lines of
TARGET_TO_HOST_PTR
HOST_TO_TARGET_PTR
The practical solution is to promote the 32-bit unsigned integer to a
64-bit unsigned integer (using a cast) and then let the compiler do
implicit conversion to a 64-bit pointer.
[Qemu-devel] [Patch] Auto-detect USB devfs in Linux
Since Linux kernel 2.6.14 the USB device file-system has moved from
'/proc/bus/usb' to '/dev/bus/usb' but qemu has '/proc/bus/usb'
hard-coded in usb-linux.c
I explored the option of moving USBDEVFS_PATH to config.h but it would
require several additions to the configure script as well as the changes
to usb-linux.c
Therefore I have opted to detect which USB file-system is in use by
extending the error-detection in usb_host_scan() to first try
'/dev/bus/usb' and if that fails, then try the pre-2.6.14
'/proc/bus/usb'.
The new code uses a (new) static char 'usb_devfs_path' set to the path
that works, and it is subsequently used in usb_host_device_open().
TJ.
Index: usb-linux.c
===
RCS file: /sources/qemu/qemu/usb-linux.c,v
retrieving revision 1.15
diff -u -r1.15 usb-linux.c
--- usb-linux.c 31 Oct 2007 00:27:50 - 1.15
+++ usb-linux.c 2 Nov 2007 11:31:57 -
@@ -52,7 +52,17 @@
//#define DEBUG_ISOCH
//#define USE_ASYNCIO
-#define USBDEVFS_PATH /proc/bus/usb
+/*
+ * TJ [EMAIL PROTECTED] 2007-11-02
+ * Now defaults to /dev/bus/usb/devices which was introduced into kernel
version 2.6.14 with
+ * commit fbf82fd2e1f4e679c60516d772d1862c941ca845 on Jul 31st 2005.
+ *
+ * If the 'devices' file doesn't exist, code checks for the older
/proc/bus/usb/devices
+ * before reporting an error.
+*/
+static unsigned char usb_devfs_path[64];
+#define USB_DEVFS_PATH_PRE_2_6_14 /proc/bus/usb
+#define USB_DEVFS_PATH /dev/bus/usb
#define PRODUCT_NAME_SZ 32
#define SIG_ISOCOMPLETE (SIGRTMIN+7)
#define MAX_ENDPOINTS 16
@@ -614,7 +624,7 @@
devname) 0)
return NULL;
-snprintf(buf, sizeof(buf), USBDEVFS_PATH /%03d/%03d,
+snprintf(buf, sizeof(buf), %s/%03d/%03d, usb_devfs_path,
bus_num, addr);
fd = open(buf, O_RDWR | O_NONBLOCK);
if (fd 0) {
@@ -737,11 +747,25 @@
int bus_num, addr, speed, device_count, class_id, product_id, vendor_id;
int ret;
char product_name[512];
-
-f = fopen(USBDEVFS_PATH /devices, r);
+
+/* TJ [EMAIL PROTECTED] 2007-11-02
+ * Auto-detect USB devices file-system location
+ * pre 2.6.14 kernels used /proc/bus/usb
+ * Standard location is now /dev/bus/usb
+ * Retain correct location in static variable for use by
usb_host_device_open()
+ */
+snprintf(usb_devfs_path, sizeof(usb_devfs_path), %s, USB_DEVFS_PATH);
+/* use buf temporarily to build path to devices file */
+snprintf(buf, sizeof(buf), %s/devices, usb_devfs_path);
+f = fopen(buf, r);
if (!f) {
-term_printf(Could not open %s\n, USBDEVFS_PATH /devices);
-return 0;
+snprintf(usb_devfs_path, sizeof(usb_devfs_path), %s,
USB_DEVFS_PATH_PRE_2_6_14);
+snprintf(buf, sizeof(buf), %s/devices, usb_devfs_path);
+f = fopen(buf, r);
+if (!f) {
+term_printf(Could not open USB devices file %s\n, buf);
+return 0;
+}
}
device_count = 0;
bus_num = addr = speed = class_id = product_id = vendor_id = 0;
