date:20180414

[Qemu-devel] [Bug 1402289] Re: netware 5.1 and SCSI (LSI Logic 53c895a) = lsi_scsi: error: readb 0x49

2018-04-14 Thread Launchpad Bug Tracker

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  netware 5.1 and SCSI (LSI Logic 53c895a) = lsi_scsi: error: readb 0x49

Status in QEMU:
  Expired

Bug description:
  Subj.

  This error occurs while loading LSIHINW.HAM driver in the netware5.1
  SP8 installer.

  Affected versions: qemu 2.1.2 and 2.2.50 from git (2014-12-14).
  Linux kernel: 3.17.6 and 3.18.0.

  Debug log for machine in the attachment.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1402289/+subscriptions

[Qemu-devel] [Bug 1376938] Re: detect-zeroes=unmap fails to discard in some cases

2018-04-14 Thread Launchpad Bug Tracker

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  detect-zeroes=unmap fails to discard in some cases

Status in QEMU:
  Expired

Bug description:
  Under certain circumstances, QEMU 2.1.2 fails to discard the
  underlaying block. The command to start QEMU is:

  qemu-system-x86_64 -machine pc,accel=kvm -m 2G -smp 2 -vga std -usb
  -usbdevice tablet -drive if=none,id=ff,aio=native,discard=unmap
  ,detect-zeroes=unmap,file=/tmp/test.qcow2 -device virtio-scsi-pci
  -device scsi-disk,drive=ff -cdrom
  /media/iso/archlinux-2014.06.01-dual.iso -vnc :1

  Steps to reproduce:

   0. qemu-img create -f qcow2 /tmp/test.qcow2 4G
   1. Boot in the guest (Arch Linux x86_64 with Linux 3.14.4)
   2. cat /dev/zero > /dev/sda. Observe a file of 4109M (size measured with `du 
-m`
   3. cat /dev/zero > /dev/sda
   4. blkdiscard /dev/sda
   5. Observe that test.qcow2 grows larger than 1M (13M in my testing).

  The results are more severe when you write other kind of data in step
  2, for instance `base64 /dev/zero > /dev/sda` and then continuing with
  step 3 and 4 will result in a file of 3642M, after blkdiscard.

  It makes not much of a difference if I create an ext4 filesystem on
  top of it and use fstrim (or rm).

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1376938/+subscriptions

[Qemu-devel] [Bug 1405176] Re: ctrl+alt+2 not work on gtk display

2018-04-14 Thread Launchpad Bug Tracker

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  ctrl+alt+2 not work on gtk display

Status in QEMU:
  Expired

Bug description:
  I download 2.2.0 release  on http://wiki.qemu.org/Download
  the monitor console does not appear in gtk display but works for sdl and vnc.
  my gtk is 3.12.2

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1405176/+subscriptions

[Qemu-devel] [Bug 1397157] Re: cpu high with ps2 keyboard on multi-core win7 guest os

2018-04-14 Thread Launchpad Bug Tracker

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  cpu high with ps2 keyboard on multi-core win7 guest os

Status in QEMU:
  Expired

Bug description:
  
  qemu ver: 1.5.3-Latest 

  guest os: window 7 64bit with 2 cpu and ps2 keybord.

  problem: Use virt-viwer as client to connect, When input quickly, the
  guest and host cpu will high and the input-char will display later.
  but when only 1 cpu on the vm, the problem will not display or When
  qemu ver is 0.12.1, the problem will not display.

  qemu cmd:
  /usr/libexec/qemu-kvm -name xx_win7 -machine 
pc-i440fx-rhel7.0.0,accel=kvm,usb=off -cpu 
qemu64,+sse4.2,+sse4.1,+ssse3,-svm,hv_relaxed,hv_vapic,hv_spinlocks=0x1000 -m 
4096 -realtime mlock=off -smp 2,sockets=1,cores=2,threads=1 -uuid 
0860a434-6560-591b-f92f-c13c5caaf52d -rtc base=localtime -no-shutdown -boot 
strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device 
ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 
-device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 
-device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive 
file=/lfs/xx_win7/xx_win7.vda,if=none,id=drive-virtio-disk0,format=qcow2,cache=writeback
 -device 
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2
 -drive if=none,id=drive-ide0-0-0,readonly=on,format=raw -device 
ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -chardev 
spicevmc,id=charchannel0,name=vdagent -device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
 -device usb-tablet,id=input0 -spice 
port=5900,addr=::,disable-ticketing,plaintext-channel=main,plaintext-channel=display,plaintext-channel=inputs,plaintext-channel=cursor,plaintext-channel=playback,plaintext-channel=record,plaintext-channel=usbredir,image-compression=auto_glz,jpeg-wan-compression=auto,zlib-glz-wan-compression=auto,playback-compression=on,disable-copy-paste,seamless-migration=on
 -vga qxl -global qxl-vga.ram_size=268435456 -global qxl-vga.vram_size=67108864 
-device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device 
hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev 
spicevmc,id=charredir0,name=usbredir -device 
usb-redir,chardev=charredir0,id=redir0 -chardev 
spicevmc,id=charredir1,name=usbredir -device 
usb-redir,chardev=charredir1,id=redir1 -chardev 
spicevmc,id=charredir2,name=usbredir -device 
usb-redir,chardev=charredir2,id=redir2 -chardev 
spicevmc,id=charredir3,name=usbredir -device 
usb-redir,chardev=charredir3,id=redir3 -device 
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1397157/+subscriptions

Re: [Qemu-devel] [PATCH v4 1/2] Implement .hex file loader

2018-04-14 Thread Stefan Hajnoczi

On Sat, Apr 14, 2018 at 11:44 PM, Su Hang  wrote:
> Thanks for your detailed reply! I  will carefully treat
> all the content that you mentioned, and apply them in v5.

By the way, if you are wondering why the parser needs to validate
everything, here is an example scenario:

QEMU may be used to host an online micro:bit simulator where the user
can provide a .hex file.  In that case QEMU is running on a server and
the .hex file is provided by an untrusted user.  That user must not be
able to crash QEMU (and exploit security holes).

Stefan

[Qemu-devel] [Bug 1191326] Re: QNX 4 doesn't boot on qemu >= 1.3

2018-04-14 Thread Christian Bohr

Hi,

I had the same problem, and maybe it can help. I wrote my own toy OS
with a PATA / IDE driver back in 2012 using older version of QEMU and
everything worked fine. These days, I tried that on a recent version
(2.5) and it failed with exactly the same behaviour - lots of zeros
being written during a DMA transfer.

After some research, I found that the behaviour that was changed with
1.3 is that the bus master configuration bit (bit 2 of the PCI command
register) is now emulated, and my driver did not set this bit.
Apparently, the BIOS does not set it either, so it was off and the DMA
transfer silently failed and only wrote zeros.

So I added some code to my init routine that sets this bit, and voila -
it worked. I have tried 1.2, 1.3 and 2.5.0 and this works with all of
them.

I do not know the internals of QNX, but I learned that apparently also
Linux did not set this bit in older version, so it might very well be
that QNX does not set it either and this is the 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/1191326

Title:
  QNX 4 doesn't boot on qemu >= 1.3

Status in QEMU:
  Confirmed

Bug description:
  I am using virtual machine with QNX4 operating system installed on it.  I 
updated my qemu from version
  to newer and QNX4 doesn't start any more. All is ok on version 1.2 but when I 
try to use any newer version
  (1.3, 1.4, 1.5)  QNX4 doesn't boot.  I tried on windows and linux ubuntu 
hosts - effects are the same.

  When virtual machine boots qnx bootloader loads and starts operating system. 
In the next step
  qnx starts its ide driver, which detects qemu harddisk and cdrom. Problem 
starts when operating system
  tries mount partition - an error occur and qnx stop booting procedure:

  mount -p "No bios signature in partition sector on /dev/hd0"

  I have tried install qnx from cdrom but it seems that there is the same 
problem. QNX installer boot from
  cdrom, detects hard disk and cdrom, but cdrom can't be mounted in the next 
step of installation procedure.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1191326/+subscriptions

Re: [Qemu-devel] [PATCH v2 15/17] cputlb: remove tb_lock from tlb_flush functions

2018-04-14 Thread Richard Henderson

On 04/05/2018 04:13 PM, Emilio G. Cota wrote:
> The acquisition of tb_lock was added when the async tlb_flush
> was introduced in e3b9ca810 ("cputlb: introduce tlb_flush_* async work.")
> 
> tb_lock was there to allow us to do memset() on the tb_jmp_cache's.
> However, since f3ced3c5928 ("tcg: consistently access cpu->tb_jmp_cache
> atomically") all accesses to tb_jmp_cache are atomic, so tb_lock
> is not needed here. Get rid of it.
> 
> Reviewed-by: Alex Bennée 
> Signed-off-by: Emilio G. Cota 
> ---
>  accel/tcg/cputlb.c | 8 
>  1 file changed, 8 deletions(-)

Reviewed-by: Richard Henderson 


r~

[Qemu-devel] [Bug 1717708] Re: QEMU aarch64 can't run Windows ARM64 iso's

2018-04-14 Thread Giles Gaffney

Has anyone been able to find a workaround to run this with KVM from an
ARM64 host? What exactly is the problem with Qemu/KVM/Aarch64 that stops
KVM from working - and are any efforts being made to get around it?

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

Title:
  QEMU aarch64 can't run Windows ARM64 iso's

Status in QEMU:
  New

Bug description:
  Hi,
  recently Windows ARM64 ISOs have been posted on the internet..
  just checked with latest QEMU 2.10 release from 
  https://qemu.weilnetz.de/w64/qemu-w64-setup-20170830.exe 
  "h:\qemu\qemu-system-aarch64.exe" -boot d -cdrom 
h:\iso\16353.1000.170825-1423.RS_PRERELEASE_CLIENTPRO_OEMRET_ARM64FRE_ES-ES.ISO 
-m 2048 -cpu cortex-a57 -smp 1 -machine virt
  seems no video output..
  checked various machine options for example versatilepb (says guest has not 
initialized the guest)..

  so don't know if it's a QEMU bug or lacking feature but can support
  running Windows ARM64 builds (would be nice if you can add a
  Snapdragon835 machine type which is which first machines will be
  running..)

  
  note running a Windows x64 ISO with similar parameters works (removing -cpu 
and -machine as not needed)

  thanks..

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1717708/+subscriptions

Re: [Qemu-devel] [PATCH v4 1/2] Implement .hex file loader

2018-04-14 Thread Su Hang

Thanks for your detailed reply! I  will carefully treat
all the content that you mentioned, and apply them in v5.


> -Original Messages-
> From: "Stefan Hajnoczi" 
> Sent Time: 2018-04-14 22:08:43 (Saturday)
> To: "Su Hang" 
> Cc: "Jim Mussared" , qemu-devel 
> , "Joel Stanley" 
> Subject: Re: [Qemu-devel] [PATCH v4 1/2] Implement .hex file loader
> 
> On Mon, Apr 9, 2018 at 11:39 AM, Su Hang  wrote:
> > This patch adds Intel Hexadecimal Object File format support to
> > the loader.  The file format specification is available here:
> > http://www.piclist.com/techref/fileext/hex/intel.htm
> >
> > The file format is mainly intended for embedded systems
> > and microcontrollers, such as Arduino, ARM, STM32, etc.
> >
> > Suggested-by: Stefan Hajnoczi 
> > Signed-off-by: Su Hang 
> > ---
> >  hw/arm/boot.c   |   9 +-
> >  hw/core/loader.c| 280 
> > 
> >  include/hw/loader.h |  17 
> >  3 files changed, 305 insertions(+), 1 deletion(-)
> 
> Parsers must be robust against invalid inputs so that a corrupt input
> file cannot crash QEMU.  Please validate all addresses/offsets/lengths
> so that this cannot happen.  For example, the byte_count is currently
> not validated and can overflow HexLine.data[].
> 
> parse_hex_blob() must handle input files that touch large ranges of
> memory.  At the moment it assumes bin_buf will be large enough for the
> memory regions described by the input file.  Since Intel HEX files
> support 32-bit addressing, that means processing a file in this way
> could require 4 GB of RAM!  Three solutions:
> 1. Reject files that have large gaps in their address ranges.
> 2. Return a list of data blobs, each with its own start address.
> 3. Set up the ROM structs directly within parse_hex_blob() instead of
> returning a linear buffer.
> 
> > diff --git a/hw/arm/boot.c b/hw/arm/boot.c
> > index 9319b12fcd2a..07ce54e5936d 100644
> > --- a/hw/arm/boot.c
> > +++ b/hw/arm/boot.c
> > @@ -1060,8 +1060,15 @@ static void arm_load_kernel_notify(Notifier 
> > *notifier, void *data)
> >  kernel_size = load_aarch64_image(info->kernel_filename,
> >   info->loader_start, , as);
> >  is_linux = 1;
> > +} else if (kernel_size < 0 && strstr(info->kernel_filename, ".hex")) {
> 
> Most UNIX-style programs, including QEMU, do not check the file
> extension to determine its format.  Instead they look at the contents
> of the file to see if it can be parsed.
> 
> Please do not check for ".hex".  Try to load it as a hex file and fall
> back to the next file type if parsing fails.
> 
> > +/* 32-bit ARM .hex file */
> > +entry = info->loader_start + KERNEL_LOAD_ADDR;
> > +kernel_size = load_targphys_hex_as(info->kernel_filename, entry,
> > +   info->ram_size - 
> > KERNEL_LOAD_ADDR,
> > +   as);
> > +is_linux = 1;
> 
> Why is this needed?  Linux images are not loaded from hex files and
> the extra information provided by is_linux = 1 won't be used/tested.
> 
> >  } else if (kernel_size < 0) {
> > -/* 32-bit ARM */
> > +/* 32-bit ARM binary file */
> >  entry = info->loader_start + KERNEL_LOAD_ADDR;
> >  kernel_size = load_image_targphys_as(info->kernel_filename, entry,
> >   info->ram_size - 
> > KERNEL_LOAD_ADDR,
> > diff --git a/hw/core/loader.c b/hw/core/loader.c
> > index 06bdbca53709..41d714520be4 100644
> > --- a/hw/core/loader.c
> > +++ b/hw/core/loader.c
> > @@ -1286,3 +1286,283 @@ void hmp_info_roms(Monitor *mon, const QDict *qdict)
> >  }
> >  }
> >  }
> > +
> > +typedef enum HexRecord HexRecord;
> > +enum HexRecord {
> > +DATA_RECORD = 0,
> > +EOF_RECORD,
> > +EXT_SEG_ADDR_RECORD,
> > +START_SEG_ADDR_RECORD,
> > +EXT_LINEAR_ADDR_RECORD,
> > +START_LINEAR_ADDR_RECORD,
> > +};
> > +
> > +typedef union HexLine HexLine;
> > +union HexLine {
> > +uint8_t buf[0x25];
> 
> Why is the length 0x25?  According to the file format specification
> the data[] part can be 255 bytes long.
> 
> > +struct __attribute__((packed)) {
> 
> This use of packed is not portable since the address field is not
> aligned to 16 bits.  Some CPU architectures do not support unaligned
> memory accesses and the program would terminate with an exception.
> 
> Have you considered using fscanf() instead?  It removes the need for
> HexLine, hex_buf, and the character parsing loop:
> 
>   if (fscanf(fp, ":%02hhx%04hx%02hhx", _count, ,
> _type) != 3) {
>   ...
>   goto fail;
>   }
> 
>   our_checksum = byte_count  + ((address >> 8) & 0xff) + (address &
> 0xff) + record_type;
> 
>   for (i = 0; i <

[Qemu-devel] [PATCH trivial for-2.12] Makefile: install gtk message catalogs if CONFIG_GTK=y too, not only =m

2018-04-14 Thread Michael Tokarev

Signed-off-by: Michael Tokarev 
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 727ef118f3..8644c2e918 100644
--- a/Makefile
+++ b/Makefile
@@ -856,7 +856,7 @@ ifneq ($(BLOBS),)
$(INSTALL_DATA) $(SRC_PATH)/pc-bios/$$x 
"$(DESTDIR)$(qemu_datadir)"; \
done
 endif
-ifeq ($(CONFIG_GTK),m)
+ifneq ($(filter $(CONFIG_GTK),y m),)
$(MAKE) -C po $@
 endif
$(INSTALL_DIR) "$(DESTDIR)$(qemu_datadir)/keymaps"
-- 
2.11.0

Re: [Qemu-devel] [PATCH v4 1/2] Implement .hex file loader

2018-04-14 Thread Stefan Hajnoczi

On Mon, Apr 9, 2018 at 11:39 AM, Su Hang  wrote:
> This patch adds Intel Hexadecimal Object File format support to
> the loader.  The file format specification is available here:
> http://www.piclist.com/techref/fileext/hex/intel.htm
>
> The file format is mainly intended for embedded systems
> and microcontrollers, such as Arduino, ARM, STM32, etc.
>
> Suggested-by: Stefan Hajnoczi 
> Signed-off-by: Su Hang 
> ---
>  hw/arm/boot.c   |   9 +-
>  hw/core/loader.c| 280 
> 
>  include/hw/loader.h |  17 
>  3 files changed, 305 insertions(+), 1 deletion(-)

Parsers must be robust against invalid inputs so that a corrupt input
file cannot crash QEMU.  Please validate all addresses/offsets/lengths
so that this cannot happen.  For example, the byte_count is currently
not validated and can overflow HexLine.data[].

parse_hex_blob() must handle input files that touch large ranges of
memory.  At the moment it assumes bin_buf will be large enough for the
memory regions described by the input file.  Since Intel HEX files
support 32-bit addressing, that means processing a file in this way
could require 4 GB of RAM!  Three solutions:
1. Reject files that have large gaps in their address ranges.
2. Return a list of data blobs, each with its own start address.
3. Set up the ROM structs directly within parse_hex_blob() instead of
returning a linear buffer.

> diff --git a/hw/arm/boot.c b/hw/arm/boot.c
> index 9319b12fcd2a..07ce54e5936d 100644
> --- a/hw/arm/boot.c
> +++ b/hw/arm/boot.c
> @@ -1060,8 +1060,15 @@ static void arm_load_kernel_notify(Notifier *notifier, 
> void *data)
>  kernel_size = load_aarch64_image(info->kernel_filename,
>   info->loader_start, , as);
>  is_linux = 1;
> +} else if (kernel_size < 0 && strstr(info->kernel_filename, ".hex")) {

Most UNIX-style programs, including QEMU, do not check the file
extension to determine its format.  Instead they look at the contents
of the file to see if it can be parsed.

Please do not check for ".hex".  Try to load it as a hex file and fall
back to the next file type if parsing fails.

> +/* 32-bit ARM .hex file */
> +entry = info->loader_start + KERNEL_LOAD_ADDR;
> +kernel_size = load_targphys_hex_as(info->kernel_filename, entry,
> +   info->ram_size - KERNEL_LOAD_ADDR,
> +   as);
> +is_linux = 1;

Why is this needed?  Linux images are not loaded from hex files and
the extra information provided by is_linux = 1 won't be used/tested.

>  } else if (kernel_size < 0) {
> -/* 32-bit ARM */
> +/* 32-bit ARM binary file */
>  entry = info->loader_start + KERNEL_LOAD_ADDR;
>  kernel_size = load_image_targphys_as(info->kernel_filename, entry,
>   info->ram_size - 
> KERNEL_LOAD_ADDR,
> diff --git a/hw/core/loader.c b/hw/core/loader.c
> index 06bdbca53709..41d714520be4 100644
> --- a/hw/core/loader.c
> +++ b/hw/core/loader.c
> @@ -1286,3 +1286,283 @@ void hmp_info_roms(Monitor *mon, const QDict *qdict)
>  }
>  }
>  }
> +
> +typedef enum HexRecord HexRecord;
> +enum HexRecord {
> +DATA_RECORD = 0,
> +EOF_RECORD,
> +EXT_SEG_ADDR_RECORD,
> +START_SEG_ADDR_RECORD,
> +EXT_LINEAR_ADDR_RECORD,
> +START_LINEAR_ADDR_RECORD,
> +};
> +
> +typedef union HexLine HexLine;
> +union HexLine {
> +uint8_t buf[0x25];

Why is the length 0x25?  According to the file format specification
the data[] part can be 255 bytes long.

> +struct __attribute__((packed)) {

This use of packed is not portable since the address field is not
aligned to 16 bits.  Some CPU architectures do not support unaligned
memory accesses and the program would terminate with an exception.

Have you considered using fscanf() instead?  It removes the need for
HexLine, hex_buf, and the character parsing loop:

  if (fscanf(fp, ":%02hhx%04hx%02hhx", _count, ,
_type) != 3) {
  ...
  goto fail;
  }

  our_checksum = byte_count  + ((address >> 8) & 0xff) + (address &
0xff) + record_type;

  for (i = 0; i < byte_count; i++) {
  if (fscanf(fp, "%02hhx", [i]) != 1) {
  ...
  goto fail;
  }

  our_checksum += data[i];
  }

  if (fscanf(fp, "%02hhx\n", ) != 1) {
  ...
  goto fail;
  }

  if (our_checksum + checksum != 0) {
  ...
  goto fail;
  }

  ...process record...

> +uint8_t byte_count;
> +uint16_t address;
> +uint8_t record_type;
> +uint8_t data[0x25 - 0x5];
> +uint8_t checksum;
> +};
> +};
> +
> +static uint8_t ctoh(char c)
> +{
> +return (c & 0x10) ? /*0-9*/ c & 0xf : /*A-F, a-f*/ (c & 0xf) + 9;
> +}

Not needed if you switch to fscanf(), but otherwise please use glib's
g_ascii_xdigit_value():

[Qemu-devel] qapi: [PATCH v2] Implement query-usbhost QMP command

2018-04-14 Thread Alexander Kappner

Implement a QMP command similar to the HMP's "info usbhost" command.
This allows a QMP client to query which USB devices may be available
for redirection. Because the availability of the command needs to
depend on the target's (not the build host's) USB configuration,
a stub function in host-stub.c is provided for targets without USB support.

v2 of this patch resolves build failure under some configurations
without libusb.

Signed-off-by: Alexander Kappner 
---
 hw/usb/host-libusb.c | 64 
 hw/usb/host-stub.c   |  9 
 qapi/misc.json   | 62 ++
 3 files changed, 135 insertions(+)

diff --git a/hw/usb/host-libusb.c b/hw/usb/host-libusb.c
index 1b0be07..efdf577 100644
--- a/hw/usb/host-libusb.c
+++ b/hw/usb/host-libusb.c
@@ -40,6 +40,7 @@
 #include 
 
 #include "qapi/error.h"
+#include "qapi/qapi-commands-misc.h"
 #include "qemu-common.h"
 #include "monitor/monitor.h"
 #include "qemu/error-report.h"
@@ -1743,6 +1744,69 @@ bool usb_host_dev_is_scsi_storage(USBDevice *ud)
 return is_scsi_storage;
 }
 
+UsbDeviceInfoList *qmp_query_usbhost(Error **errp)
+{
+UsbDeviceInfoList *usb_list = NULL;
+UsbDeviceInfoList *info;
+libusb_device **devs = NULL;
+struct libusb_device_descriptor ddesc;
+char port[16];
+int i, n;
+
+if (usb_host_init() != 0) {
+return NULL;
+}
+n = libusb_get_device_list(ctx, );
+
+for (i = 0; i < n; i++) {
+if (libusb_get_device_descriptor(devs[i], ) != 0) {
+continue;
+}
+if (ddesc.bDeviceClass == LIBUSB_CLASS_HUB) {
+continue;
+}
+usb_host_get_port(devs[i], port, sizeof(port));
+info = g_new0(UsbDeviceInfoList, 1);
+info->value = g_new0(UsbDeviceInfo, 1);
+info->value->id_vendor = ddesc.idVendor;
+info->value->bus_num = libusb_get_bus_number(devs[i]);
+info->value->dev_addr = libusb_get_device_address(devs[i]);
+info->value->id_product = ddesc.idProduct;
+info->value->b_device_class = ddesc.bDeviceClass;
+info->value->speed = libusb_get_device_speed(devs[i]);
+info->next = usb_list;
+usb_list = info;
+
+if (ddesc.iProduct) {
+libusb_device_handle *handle;
+if (libusb_open(devs[i], ) == 0) {
+unsigned char name[64] = "";
+libusb_get_string_descriptor_ascii(handle,
+   ddesc.iProduct,
+   name, sizeof(name));
+libusb_close(handle);
+info->value->str_product = g_strdup((gchar *)name);
+}
+} else
+info->value->str_product = NULL;
+
+if (ddesc.iManufacturer) {
+libusb_device_handle *handle;
+if (libusb_open(devs[i], ) == 0) {
+unsigned char name[64] = "";
+libusb_get_string_descriptor_ascii(handle,
+   ddesc.iManufacturer,
+   name, sizeof(name));
+libusb_close(handle);
+info->value->str_manufacturer = g_strdup((gchar *)name);
+}
+} else
+info->value->str_manufacturer = NULL;
+}
+libusb_free_device_list(devs, 1);
+return usb_list;
+}
+
 void hmp_info_usbhost(Monitor *mon, const QDict *qdict)
 {
 libusb_device **devs = NULL;
diff --git a/hw/usb/host-stub.c b/hw/usb/host-stub.c
index 41d93ec..fd227c4 100644
--- a/hw/usb/host-stub.c
+++ b/hw/usb/host-stub.c
@@ -35,6 +35,9 @@
 #include "ui/console.h"
 #include "hw/usb.h"
 #include "monitor/monitor.h"
+#include "qapi/error.h"
+#include "qapi/qapi-commands-misc.h"
+#include "qapi/qmp/qerror.h"
 
 void hmp_info_usbhost(Monitor *mon, const QDict *qdict)
 {
@@ -45,3 +48,9 @@ bool usb_host_dev_is_scsi_storage(USBDevice *ud)
 {
 return false;
 }
+
+UsbDeviceInfoList *qmp_query_usbhost(Error **errp)
+{
+error_setg(errp, QERR_FEATURE_DISABLED, "usb");
+return NULL;
+};
diff --git a/qapi/misc.json b/qapi/misc.json
index 5636f4a..19a1453 100644
--- a/qapi/misc.json
+++ b/qapi/misc.json
@@ -270,6 +270,46 @@
 { 'command': 'query-kvm', 'returns': 'KvmInfo' }
 
 ##
+# @query-usbhost:
+#
+# Returns information about USB devices available on the host
+#
+# Returns: a [UsbDeviceInfo]. Returns an error if compiled without
+# CONFIG_USB_LIBUSB
+#
+# Since: TODO (maintainer insert version number if mainlined)
+#
+# Example:
+#
+# -> {"execute": "query-usbhost" }
+# {
+# "return": [
+# {
+# "b_device_class": 239,
+# "id_product": 793,
+# "id_vendor": 3468,
+# "speed": 3,
+# "str_manufacturer": "Schiit Audio",
+# "str_product": "Schiit Modi Uber"
+# "bus_num": 5,
+# "dev_addr": 21
+#

[Qemu-devel] [Bug 1402289] Re: netware 5.1 and SCSI (LSI Logic 53c895a) = lsi_scsi: error: readb 0x49

[Qemu-devel] [Bug 1376938] Re: detect-zeroes=unmap fails to discard in some cases

[Qemu-devel] [Bug 1405176] Re: ctrl+alt+2 not work on gtk display

[Qemu-devel] [Bug 1397157] Re: cpu high with ps2 keyboard on multi-core win7 guest os

Re: [Qemu-devel] [PATCH v4 1/2] Implement .hex file loader

[Qemu-devel] [Bug 1191326] Re: QNX 4 doesn't boot on qemu >= 1.3

Re: [Qemu-devel] [PATCH v2 15/17] cputlb: remove tb_lock from tlb_flush functions

[Qemu-devel] [Bug 1717708] Re: QEMU aarch64 can't run Windows ARM64 iso's

Re: [Qemu-devel] [PATCH v4 1/2] Implement .hex file loader

[Qemu-devel] [PATCH trivial for-2.12] Makefile: install gtk message catalogs if CONFIG_GTK=y too, not only =m

Re: [Qemu-devel] [PATCH v4 1/2] Implement .hex file loader

[Qemu-devel] qapi: [PATCH v2] Implement query-usbhost QMP command

12 matches

Site Navigation

Mail list logo

Footer information