[Qemu-devel] [Bug 1378407] [NEW] [feature request] Partition table wrapper for single-filesystem images

[felix]

Public bug reported:

Suppose you have a single filesystem image. It would be nice if QEMU
could generate a virtual partition table for it and make it available to
the guest as a partitioned disk. Otherwise you have to use workarounds
like this:
wiki.archlinux.org/index.php/QEMU#Simulate_virtual_disk_with_MBR_using_linear_RAID

It should be relatively easy to do on top of existing vvfat code.

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  [feature request] Partition table wrapper for single-filesystem images

Status in QEMU:
  New

Bug description:
  Suppose you have a single filesystem image. It would be nice if QEMU
  could generate a virtual partition table for it and make it available
  to the guest as a partitioned disk. Otherwise you have to use
  workarounds like this:
  
wiki.archlinux.org/index.php/QEMU#Simulate_virtual_disk_with_MBR_using_linear_RAID

  It should be relatively easy to do on top of existing vvfat code.

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

[Qemu-devel] [Bug 1180924] Re: fails to handle a usb serial port with a specific vendorid

[felix]

Regressed in commit f29783f72ea77dfbd7ea0c993d62d253d4c4e023.

I've just run into this in a similar circumstance: trying to reverse-
engineer a driver for a phone to which I can only connect via Bluetooth.
No problem, I can just have it pretend to be a USB device. Except that I
can't, because the driver won't recognise 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/1180924

Title:
  fails to handle a usb serial port with a specific vendorid

Status in QEMU:
  New

Bug description:
  If I run qemu-system-i386 with arguments
  -usb -usbdevice serial:vendorid=1221:pty
  (this is what the documentation says about how I shoud add a usb device which 
has a serial port interface and which has a specific vendor id, I used the 
documentation located here:
  http://qemu.weilnetz.de/qemu-doc.html
  ), it says 
  char device redirected to /dev/pts/ (label usbserial0)
  qemu-system-i386: -usbdevice serial:vendorid=1221:pty: Property '.vendorid' 
not found
  Aborted
  and exits. Moreover, if I try to add such a device to a running machine by 
typing usb_add serial:vendorid=1221:pty in the machine's control terminal (to 
reach it, I press ctrl-alt-2), qemu also writes 
  char device redirected to /dev/pts/ (label usbserial0)
  Aborted
  to the terminal where I run it from and exits. To the quest OS this looks 
like a power failure which causes all the programs inside the virtual machine 
to lose their unsaved data.
  I have tested this with qemu-1.5.0-rc2, actually, the issue occured in a 
similar way since 1.0.1, but did not occur in 0.11.1.
  The issue is reproducible always, even if I don't specify any hard disk in 
the command line, i. e.
  $ qemu-system-i386 -usb -usbdevice serial:vendorid=1221:pty
  , so I believe it is guest OS -independent.

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

[Qemu-devel] [Bug 1474263] [NEW] "Image format was not specified" warning should be suppressed for the vvfat (and probably nbd) driver

[felix]

Public bug reported:

Running

qemu -drive file.driver=vvfat,file.dir=.

displays

WARNING: Image format was not specified for 'json:{"dir": ".", "driver": 
"vvfat"}' and probing guessed raw.
 Automatically detecting the format is dangerous for raw images, write 
operations on block 0 will be restricted.
 Specify the 'raw' format explicitly to remove the restrictions.

However, since "images" provided by the vvfat driver are always raw (and
the first sector isn't writeable in any case), this warning is
superfluous and should not be displayed.

A similar warning is displayed for NBD devices; I suspect it should be
also disabled for similar reasons, but I'm not sure if serving non-raw
images is actually a violation of the protocol. qemu-nbd translates them
to raw images, for what it's worth, even if it may be suppressed with -f
raw.

Noticed on 2.3.0; the code that causes this behaviour is still
apparently present in today's git master
(f3a1b5068cea303a55e2a21a97e66d057eaae638). Speaking of versions: you
may want to update the copyright notice that qemu -version displays.

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  "Image format was not specified" warning should be suppressed for the
  vvfat (and probably nbd) driver

Status in QEMU:
  New

Bug description:
  Running

  qemu -drive file.driver=vvfat,file.dir=.

  displays

  WARNING: Image format was not specified for 'json:{"dir": ".", "driver": 
"vvfat"}' and probing guessed raw.
   Automatically detecting the format is dangerous for raw images, 
write operations on block 0 will be restricted.
   Specify the 'raw' format explicitly to remove the restrictions.

  However, since "images" provided by the vvfat driver are always raw
  (and the first sector isn't writeable in any case), this warning is
  superfluous and should not be displayed.

  A similar warning is displayed for NBD devices; I suspect it should be
  also disabled for similar reasons, but I'm not sure if serving non-raw
  images is actually a violation of the protocol. qemu-nbd translates
  them to raw images, for what it's worth, even if it may be suppressed
  with -f raw.

  Noticed on 2.3.0; the code that causes this behaviour is still
  apparently present in today's git master
  (f3a1b5068cea303a55e2a21a97e66d057eaae638). Speaking of versions: you
  may want to update the copyright notice that qemu -version displays.

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

[Qemu-devel] [Bug 1574246] [NEW] Drunken keyboard in go32v2 programs

[felix]

Public bug reported:

QEMU 2.5.0, SeaBIOS 1.9.1; I've been noticing this bug for quite a
while, though.

Steps to reproduce:

# Create a VM image, install DOS in it (doesn't matter which) and launch it.
# Launch a "bare DOS" DPMI host (not an operating system) in it; I tested with 
CWSDPMI and HDPMI32.
# Run a go32v2 program which reads keyboard input (say, the Lua interpreter: 
;
 the Free Pascal IDE will also do; on the other hand, DOS/4GW programs seem 
unaffected).
# Quickly type in something random (e.g. alternate between hitting "p" and 
"q"), then optionally move the cursor left and right.
# Observe how some keystrokes are missed, and some are caught twice.

The issue does NOT arise:
* on bare metal DOS,
* in VirtualBox,
* in Bochs with stock Plex86 BIOS,
* in Bochs with SeaBIOS,
* in DOSEMU,
* in DOSBox,
* in QEMU when the DPMI host is Windows 3.11/9x
so at this point I'm reasonably sure that it's the fault of either QEMU or 
SeaBIOS, and probably the former. The issue arises regardless of whether KVM is 
enabled.

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  Drunken keyboard in go32v2 programs

Status in QEMU:
  New

Bug description:
  QEMU 2.5.0, SeaBIOS 1.9.1; I've been noticing this bug for quite a
  while, though.

  Steps to reproduce:

  # Create a VM image, install DOS in it (doesn't matter which) and launch it.
  # Launch a "bare DOS" DPMI host (not an operating system) in it; I tested 
with CWSDPMI and HDPMI32.
  # Run a go32v2 program which reads keyboard input (say, the Lua interpreter: 
;
 the Free Pascal IDE will also do; on the other hand, DOS/4GW programs seem 
unaffected).
  # Quickly type in something random (e.g. alternate between hitting "p" and 
"q"), then optionally move the cursor left and right.
  # Observe how some keystrokes are missed, and some are caught twice.

  The issue does NOT arise:
  * on bare metal DOS,
  * in VirtualBox,
  * in Bochs with stock Plex86 BIOS,
  * in Bochs with SeaBIOS,
  * in DOSEMU,
  * in DOSBox,
  * in QEMU when the DPMI host is Windows 3.11/9x
  so at this point I'm reasonably sure that it's the fault of either QEMU or 
SeaBIOS, and probably the former. The issue arises regardless of whether KVM is 
enabled.

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

[Qemu-devel] [Bug 1574246] Re: Drunken keyboard in go32v2 programs

[felix]

I compiled the latest git snapshot (tag: v2.6.0-rc4, calling itself
2.5.94; with GTK frontend) and could only half-reproduce the bug; keys
do not longer "jam", but arrow keys are still captured twice. I woudn't
make much of that difference; this bug seems very timing-sensitive. It
could be that the GTK frontend adds sufficient latency to the interface
to avoid triggering it.

I enabled some debugging switches and recompiled both QEMU and the
latest git snapshot of SeaBIOS (1.9.0-127; commit
c8e105a4d5e52e8e7539ab1f2cd07ebe0ae9033a). This is what I got when
running programs affected by this bug:

(key press)
[qemu   ] ps2_queue(0xe0)
[qemu   ] ps2_queue(0x4d)
(IRQ1)
[qemu   ] KBD: kbd: read data=0xe0 ← (***)
[seabios] handle_09
[qemu   ] KBD: kbd: read status=0x1d
[qemu   ] KBD: kbd: read data=0x4d
[seabios] i8042_command cmd=ae
[seabios] i8042_wait_write
[qemu   ] KBD: kbd: read status=0x1c
[qemu   ] KBD: kbd: write cmd=0xae
(IRQ1)
[qemu   ] KBD: kbd: read data=0x4d ← (***)
[seabios] handle_09
[qemu   ] KBD: kbd: read status=0x1c
[qemu   ] KBD: kbd: read data=0x4d
[seabios] i8042_command cmd=ae
[seabios] i8042_wait_write
[qemu   ] KBD: kbd: read status=0x1c
[qemu   ] KBD: kbd: write cmd=0xae

Reads marked (***) do not appear when running unaffected programs. So it
appears something is making reads from the keyboard controller before
SeaBIOS has a chance to put scancodes in the ring buffer. And indeed:
DJGPP libc installs a custom IRQ1 handler which does it to detect
whether it should raise SIGINT in response to Ctrl+C; it can be found in
the file src/libc/go32/exceptn.S in the djcrx package[1]. Free Pascal
incorporates this handler into its RTL with almost no changes; it's
found in rtl/go32v2/exceptn.as[2]. I also noticed I can reproduce this
bug with Borland Pascal 7; lo and behold, the Turbo Vision library does
something similar.

SeaBIOS gets extra confused when I send some mouse events to QEMU (grab
the mouse, move it around, ungrab); it reacts with a "ps2 keyboard irq
but found mouse data?!" message and refuses to put keys in the ring
buffer until the queue of mouse events becomes empty.

That's the culprit, I think. It also explains why the bug doesn't appear
under Windows; because port 0x60 reads from DPMI are simulated, they
don't correspond to actual port 0x60 reads in the guest. I don't know
what the fix ought be; documentation about the i8042 that I found is
unclear about what real hardware does in this case.

If I'm reading the code correctly, DOSEMU[3] (also the DOSEMU2 fork[4]),
DOSBox[5], Bochs[6] and VirtualBox[7] keep one value to be read from
0x60 at until the next interrupt, avoiding the issue.

[1] 
; 
function ___djgpp_kbd_hdlr
[2] 
;
 function ___djgpp_kbd_hdlr
[3] 

[4] 

[5] 

[6] 

[7] 


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

Title:
  Drunken keyboard in go32v2 programs

Status in QEMU:
  New

Bug description:
  QEMU 2.5.0, SeaBIOS 1.9.1; I've been noticing this bug for quite a
  while, though.

  Steps to reproduce:

  # Create a VM image, install DOS in it (doesn't matter which) and launch it.
  # Launch a "bare DOS" DPMI host (not an operating system) in it; I tested 
with CWSDPMI and HDPMI32.
  # Run a go32v2 program which reads keyboard input (say, the Lua interpreter: 
;
 the Free Pascal IDE will also do; on the other hand, DOS/4GW programs seem 
unaffected).
  # Quickly type in something random (e.g. alternate between hitting "p" and 
"q"), then optionally move the cursor left and right.
  # Observe how some keystrokes are missed, and some are caught twice.

  The issue does NOT arise:
  * on bare metal DOS,
  * in VirtualBox,
  * in Bochs with stock Plex86 BIOS,
  * in Bochs with SeaBIOS,
  * in DOSEMU,
  * in DOSBox,
  * in QEMU when the DPMI host is Windows 3.11/9x
  so at this point I'm reasonably sure that it's the fault of either QEMU or 
SeaBIOS, and probably the former. The issue arises regardless of whether KVM is 
enabled.

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

[Qemu-devel] [Bug 1774830] Re: qemu monitor disassembled memory dump produces incorrect output

[felix]

** Patch added: "disas.patch"
   
https://bugs.launchpad.net/qemu/+bug/1774830/+attachment/5261663/+files/disas.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/1774830

Title:
  qemu monitor disassembled memory dump produces incorrect output

Status in QEMU:
  New

Bug description:
  Greetings,

  I've been using qemu-system-aarch64 to do some low-level programming
  targeting the raspberry pi 3. While I was debugging a problem in my
  code I noticed a very confusing inconsistency that I think is very
  likely a bug somewhere in how qemu's monitor produces its disassembled
  output.

  Here's my version output (installed via homebrew on macOS 10.13.4)

  $ qemu-system-aarch64 --version
  QEMU emulator version 2.12.0
  Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

  Some system information (macOS 10.13.4):

  $ uname -a
  Darwin Lillith.local 17.5.0 Darwin Kernel Version 17.5.0: Fri Apr 13 19:32:32 
PDT 2018; root:xnu-4570.51.2~1/RELEASE_X86_64 x86_64

  Here's an example of the problem I am seeing:

  qemu-system-aarch64 -S -M raspi3 -kernel kernel8.img -monitor stdio
  QEMU 2.12.0 monitor - type 'help' for more information
  (qemu) x /32x 0x8
  0008: 0xd53800a1 0x92400421 0xb461 0xd503205f
  00080010: 0x17ff 0x58000161 0x913f 0x58000161
  00080020: 0x18e2 0x3482 0xf800843f 0x51000442
  00080030: 0x35a2 0xd2806763 0x17ff 0x
  00080040: 0x0008 0x 0x00080050 0x
  00080050: 0x 0x 0x 0x
  00080060: 0x 0x 0x 0x
  00080070: 0x 0x 0x 0x
  (qemu) x /32i 0x8
  0x0008:  d53800a1  mrs  x1, mpidr_el1
  0x00080004:  92400421  and  x1, x1, #3
  0x00080008:  b461  cbz  x1, #0x80014
  0x0008000c:  d503205f  wfe
  0x00080010:  17ff  b#0x8000c
  0x00080014:  58000161  ldr  x1, #0x80040
  0x00080018:  913f  mov  sp, x1
  0x0008001c:  58000161  ldr  x1, #0x80048
  0x00080020:  92400421  and  x1, x1, #3
  0x00080024:  b461  cbz  x1, #0x80030
  0x00080028:  d503205f  wfe
  0x0008002c:  17ff  b#0x80028
  0x00080030:  58000161  ldr  x1, #0x8005c
  0x00080034:  913f  mov  sp, x1
  0x00080038:  58000161  ldr  x1, #0x80064
  0x0008003c:  18e2  ldr  w2, #0x80058
  0x00080040:  3482  cbz  w2, #0x80050
  0x00080044:  f800843f  str  xzr, [x1], #8
  0x00080048:  51000442  sub  w2, w2, #1
  0x0008004c:  35a2  cbnz w2, #0x80040
  0x00080050:  d2806763  movz x3, #0x33b
  0x00080054:  17ff  b#0x80050
  0x00080058:    .byte0x00, 0x00, 0x00, 0x00
  0x0008005c:  0008  .byte0x00, 0x00, 0x08, 0x00
  0x00080060:    .byte0x00, 0x00, 0x00, 0x00
  0x00080064:  00080050  .byte0x50, 0x00, 0x08, 0x00
  0x00080068:    .byte0x00, 0x00, 0x00, 0x00
  0x0008006c:    .byte0x00, 0x00, 0x00, 0x00
  0x00080070:    .byte0x00, 0x00, 0x00, 0x00
  0x00080074:    .byte0x00, 0x00, 0x00, 0x00
  0x00080078:    .byte0x00, 0x00, 0x00, 0x00
  0x0008007c:    .byte0x00, 0x00, 0x00, 0x00

  Please notice that between 0x80004 thru 0x8001c is repeated for some
  reason in the /32i formatted output which also causes the addresses
  for the following bytes to also be incorrect.

  Just in order to keep things as clear as possible, I'll also attach
  the binary shown above but disassembled by objdump instead of qemu.

  $ aarch64-elf-objdump -d kernel8.elf

  kernel8.elf: file format elf64-littleaarch64

  Disassembly of section .text:

  0008 <_start>:
     8: d53800a1mrs x1, mpidr_el1
     80004: 92400421and x1, x1, #0x3
     80008: b461cbz x1, 80014 <_start+0x14>
     8000c: d503205fwfe
     80010: 17ffb   8000c <_start+0xc>
     80014: 58000161ldr x1, 80040 <_start+0x40>
     80018: 913fmov sp, x1
     8001c: 58000161ldr x1, 80048 <_start+0x48>
     80020: 18e2ldr w2, 8003c <_start+0x3c>
     80024: 3482cbz w2, 80034 <_start+0x34>
     80028: f800843fstr xzr, [x1], #8
     8002c: 51000442sub w2, w2, #0x1
     80030: 35a2cbnzw2, 80024 <_start+0x24>
     80034: d2806763mov x3, #0x33b  // #827
     80038: 17ffb   80034 <_start+0x34>
     8003c: .word   0x
     80040: 0008.word   0x0008
     80044: .word   0x
     80048: 00080050.word   0x00080050
     8004c: .word   0x

  Hopef

[Qemu-devel] [Bug 1827871] [NEW] Race condition when rebooting with the TCG backend

[felix]

Public bug reported:

Reporting this as present in QEMU 3.1.0, although I don't see any commit
in current git master (a6ae23831b05a11880b40f7d58e332c45a6b04f7) that
would suggest this issue is fixed.

$ uname -a
Linux boole 4.19.0-4-686-pae #1 SMP Debian 4.19.28-2 (2019-03-15) i686 
GNU/Linux
$ qemu -version
QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-7)
Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers

Here's an excerpt from the code which handles reboot requests in SeaBIOS
1.12, located in src/fw/shadow.c:

// Request a QEMU system reset.  Do the reset in this function as
// the BIOS code was overwritten above and not all BIOS
// functionality may be available.

// Attempt PCI style reset
outb(0x02, PORT_PCI_REBOOT);
outb(0x06, PORT_PCI_REBOOT);

// Next try triple faulting the CPU to force a reset
asm volatile("int3");

This compiles to the following:

(qemu) x/10i 0xf1993
0x000f1993:  b0 02movb $2, %al
0x000f1995:  ee   outb %al, %dx
0x000f1996:  b0 06movb $6, %al
0x000f1998:  ee   outb %al, %dx
0x000f1999:  cc   int3 
0x000f199a:  80 3d 0d 53 0f 00 08 cmpb $8, 0xf530d
0x000f19a1:  75 52jne  0xf19f5
0x000f19a3:  a1 10 53 0f 00   movl 0xf5310, %eax
0x000f19a8:  8b 15 14 53 0f 00movl 0xf5314, %edx
0x000f19ae:  89 c3movl %eax, %ebx

Now, with the TCG backend, upon reaching the second outb instruction,
the thread executing JIT-ed opcodes invokes
qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET). This signals
another thread to reset the guest CPU registers to their initial state.
However, the execution thread is *not* stopped, which means it will keep
executing already-translated instructions in the TCG buffer. In
particular, the bootstrap value of the EIP register will be overwritten.
On my machine, this usually results in the guest CPU finding itself in
real mode, CS base 0x, EIP 0x199e, which in real mode
disassembles to this:

(qemu) xp/1i 0xf199e
0x000f199e:  0f 00 08 strw 0(%bx, %si)

This instruction triggers a #UD exception, and given that SeaBIOS
handles #UD by immediately returning, it manifests as the guest locking
up with 100% CPU usage every other reboot.

** Affects: qemu
 Importance: Undecided
 Status: New


** Tags: freeze reboot tcg

** Tags removed: lockup
** Tags added: freeze

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

Title:
  Race condition when rebooting with the TCG backend

Status in QEMU:
  New

Bug description:
  Reporting this as present in QEMU 3.1.0, although I don't see any
  commit in current git master
  (a6ae23831b05a11880b40f7d58e332c45a6b04f7) that would suggest this
  issue is fixed.

  $ uname -a
  Linux boole 4.19.0-4-686-pae #1 SMP Debian 4.19.28-2 (2019-03-15) i686 
GNU/Linux
  $ qemu -version
  QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-7)
  Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers

  Here's an excerpt from the code which handles reboot requests in
  SeaBIOS 1.12, located in src/fw/shadow.c:

  // Request a QEMU system reset.  Do the reset in this function as
  // the BIOS code was overwritten above and not all BIOS
  // functionality may be available.

  // Attempt PCI style reset
  outb(0x02, PORT_PCI_REBOOT);
  outb(0x06, PORT_PCI_REBOOT);

  // Next try triple faulting the CPU to force a reset
  asm volatile("int3");

  This compiles to the following:

  (qemu) x/10i 0xf1993
  0x000f1993:  b0 02movb $2, %al
  0x000f1995:  ee   outb %al, %dx
  0x000f1996:  b0 06movb $6, %al
  0x000f1998:  ee   outb %al, %dx
  0x000f1999:  cc   int3 
  0x000f199a:  80 3d 0d 53 0f 00 08 cmpb $8, 0xf530d
  0x000f19a1:  75 52jne  0xf19f5
  0x000f19a3:  a1 10 53 0f 00   movl 0xf5310, %eax
  0x000f19a8:  8b 15 14 53 0f 00movl 0xf5314, %edx
  0x000f19ae:  89 c3movl %eax, %ebx

  Now, with the TCG backend, upon reaching the second outb instruction,
  the thread executing JIT-ed opcodes invokes
  qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET). This signals
  another thread to reset the guest CPU registers to their initial
  state. However, the execution thread is *not* stopped, which means it
  will keep executing already-translated instructions in the TCG buffer.
  In particular, the bootstrap value of the EIP register will be
  overwritten. On my machine, this usually results 

[Qemu-devel] [Bug 1827871] Re: Race condition when rebooting with the TCG backend

[felix]

Never mind, 0ec7e6779fc830e5b4e6a448d75317fafcf69477 fixed this.

This can be closed.

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

Title:
  Race condition when rebooting with the TCG backend

Status in QEMU:
  New

Bug description:
  Reporting this as present in QEMU 3.1.0, although I don't see any
  commit in current git master
  (a6ae23831b05a11880b40f7d58e332c45a6b04f7) that would suggest this
  issue is fixed.

  $ uname -a
  Linux boole 4.19.0-4-686-pae #1 SMP Debian 4.19.28-2 (2019-03-15) i686 
GNU/Linux
  $ qemu -version
  QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-7)
  Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers

  Here's an excerpt from the code which handles reboot requests in
  SeaBIOS 1.12, located in src/fw/shadow.c:

  // Request a QEMU system reset.  Do the reset in this function as
  // the BIOS code was overwritten above and not all BIOS
  // functionality may be available.

  // Attempt PCI style reset
  outb(0x02, PORT_PCI_REBOOT);
  outb(0x06, PORT_PCI_REBOOT);

  // Next try triple faulting the CPU to force a reset
  asm volatile("int3");

  This compiles to the following:

  (qemu) x/10i 0xf1993
  0x000f1993:  b0 02movb $2, %al
  0x000f1995:  ee   outb %al, %dx
  0x000f1996:  b0 06movb $6, %al
  0x000f1998:  ee   outb %al, %dx
  0x000f1999:  cc   int3 
  0x000f199a:  80 3d 0d 53 0f 00 08 cmpb $8, 0xf530d
  0x000f19a1:  75 52jne  0xf19f5
  0x000f19a3:  a1 10 53 0f 00   movl 0xf5310, %eax
  0x000f19a8:  8b 15 14 53 0f 00movl 0xf5314, %edx
  0x000f19ae:  89 c3movl %eax, %ebx

  Now, with the TCG backend, upon reaching the second outb instruction,
  the thread executing JIT-ed opcodes invokes
  qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET). This signals
  another thread to reset the guest CPU registers to their initial
  state. However, the execution thread is *not* stopped, which means it
  will keep executing already-translated instructions in the TCG buffer.
  In particular, the bootstrap value of the EIP register will be
  overwritten. On my machine, this usually results in the guest CPU
  finding itself in real mode, CS base 0x, EIP 0x199e, which
  in real mode disassembles to this:

  (qemu) xp/1i 0xf199e
  0x000f199e:  0f 00 08 strw 0(%bx, %si)

  This instruction triggers a #UD exception, and given that SeaBIOS
  handles #UD by immediately returning, it manifests as the guest
  locking up with 100% CPU usage every other reboot.

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

[Qemu-devel] [Bug 1599539] Re: 2.6.0: vvfat driver generates bad FAT entries

[felix]

** Patch added: "Patch to fix the qemu-img issue (does NOT resolve the whole 
bug)"
   
https://bugs.launchpad.net/qemu/+bug/1599539/+attachment/4707063/+files/make_vvfat_work_with_qemu-img.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/1599539

Title:
  2.6.0: vvfat driver generates bad FAT entries

Status in QEMU:
  New

Bug description:
  The vvfat driver sometimes generates entries about which file system
  checking utilities generate complaints.

  For example, dosfsck will complain that the volume label entry has
  non-zero size. ScanDisk from Windows 9x complains about invalid dot
  (".") and dot-dot ("..") entries in directories and also about invalid
  long file name entries. MS-DOS ScanDisk also often manages to find
  "lost clusters" on the drive.

  Tangentially: qemu-img convert fat:test test.img doesn't seem to work
  -- it generates an 504MiB of zero bytes and hangs. qemu-img map
  fat:test generates an assertion failure. Having qemu-img working might
  have helped with debugging the above issue.

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

[Qemu-devel] [Bug 1599539] Re: 2.6.0: vvfat driver generates bad FAT entries

[felix]

I noticed another bug in vvfat disk image generation. Applying the patch
I attached earlier made testing easier. I'm less sure what the actual
problem is.

Steps to reproduce (you'll need to have cpio, md5sum and GNU GRUB 2.x 
installed):
0. Apply the patch and build qemu-img.
1. Create a directory, cd into it and unpack the attached cpio file.
2. Run: qemu-img convert fat:. ../xxx.img
3. Run: for fname in $(grub-fstest ../xxx.img ls '(loop0,msdos1)/'); do 
grub-fstest ../xxx.img cat "(loop0,msdos1)/$fname" | md5sum | sed -e 
"s,-,$fname,"; done | md5sum -c
4. Observe how almost all checksum tests fail.

Alternatively, the image can be tested inside a virtual machine. You
probably get the idea.

(File names and data have been changed for the sake of anonymity and
better compressibility)

** Attachment added: "Bug-triggering file structure"
   
https://bugs.launchpad.net/qemu/+bug/1599539/+attachment/4707220/+files/xxx.cpio.xz

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

Title:
  2.6.0: vvfat driver generates bad FAT entries

Status in QEMU:
  New

Bug description:
  The vvfat driver sometimes generates entries about which file system
  checking utilities generate complaints.

  For example, dosfsck will complain that the volume label entry has
  non-zero size. ScanDisk from Windows 9x complains about invalid dot
  (".") and dot-dot ("..") entries in directories and also about invalid
  long file name entries. MS-DOS ScanDisk also often manages to find
  "lost clusters" on the drive.

  Tangentially: qemu-img convert fat:test test.img doesn't seem to work
  -- it generates an 504MiB of zero bytes and hangs. qemu-img map
  fat:test generates an assertion failure. Having qemu-img working might
  have helped with debugging the above issue.

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

[Qemu-devel] [Bug 1599539] [NEW] 2.6.0: vvfat driver generates bad FAT entries

[felix]

Public bug reported:

The vvfat driver sometimes generates entries about which file system
checking utilities generate complaints.

For example, dosfsck will complain that the volume label entry has non-
zero size. ScanDisk from Windows 9x complains about invalid dot (".")
and dot-dot ("..") entries in directories and also about invalid long
file name entries. MS-DOS ScanDisk also often manages to find "lost
clusters" on the drive.

Tangentially: qemu-img convert fat:test test.img doesn't seem to work --
it generates an 504MiB of zero bytes and hangs. qemu-img map fat:test
generates an assertion failure. Having qemu-img working might have
helped with debugging the above issue.

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  2.6.0: vvfat driver generates bad FAT entries

Status in QEMU:
  New

Bug description:
  The vvfat driver sometimes generates entries about which file system
  checking utilities generate complaints.

  For example, dosfsck will complain that the volume label entry has
  non-zero size. ScanDisk from Windows 9x complains about invalid dot
  (".") and dot-dot ("..") entries in directories and also about invalid
  long file name entries. MS-DOS ScanDisk also often manages to find
  "lost clusters" on the drive.

  Tangentially: qemu-img convert fat:test test.img doesn't seem to work
  -- it generates an 504MiB of zero bytes and hangs. qemu-img map
  fat:test generates an assertion failure. Having qemu-img working might
  have helped with debugging the above issue.

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

[Qemu-devel] [Bug 1599539] Re: 2.6.0: vvfat driver generates bad FAT entries

[felix]

The original issue turned out to be trivial. The dot and dot-dot entries
need to be the two very first entries in a non-root directory table;
however, readdir() does not guarantee that "." and ".." will be the
first items returned. When I patched read_directory() to generate "."
and ".." entries first (and also ensured that volume label entry is
generated with zero size), ScanDisk stopped complaining.

The latter issue is also easy. The FAT16 file system cannot hold more
than 512 entries in its root directory table. The vvfat driver does not
recognise this limit and tries to squeeze more entries into the table
than is normally possible. FAT-reading software doesn't seem to
appreciate it. The driver should emit a warning and refuse to generate a
FAT image altogether. (I have actually thought of a way to do it anyway,
but it will not work everywhere.)

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

Title:
  2.6.0: vvfat driver generates bad FAT entries

Status in QEMU:
  New

Bug description:
  The vvfat driver sometimes generates entries about which file system
  checking utilities generate complaints.

  For example, dosfsck will complain that the volume label entry has
  non-zero size. ScanDisk from Windows 9x complains about invalid dot
  (".") and dot-dot ("..") entries in directories and also about invalid
  long file name entries. MS-DOS ScanDisk also often manages to find
  "lost clusters" on the drive.

  Tangentially: qemu-img convert fat:test test.img doesn't seem to work
  -- it generates an 504MiB of zero bytes and hangs. qemu-img map
  fat:test generates an assertion failure. Having qemu-img working might
  have helped with debugging the above issue.

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

[Qemu-devel] [Bug 1599539] Re: 2.6.0: vvfat driver generates bad FAT entries

[felix]

I believe commits f82d92bb028a1d674bab4ccc7e6cde6c04956230 and
6817efea3a0d1bf87be815970cdb014c5a64b628 have fixed this particular bug;
although I've since noticed the vvfat driver remains quite fragile,
especially FAT32 and writing support. I've got some patches for it of my
own, which I might submit someday (they aren't quite ready yet).

Also, after some testing, it turns one can simply grow the fixed-size
root directory table above 512 entries, and it doesn't seem to actually
cause any problems after all; although I haven't tested any extreme
cases or obscure implementations. Shrinking it (entry-wise) should be
fine in any case: 1440 KiB floppy disks typically allow 224 root
directory entries, which is 14 clusters = 14 sectors.

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

Title:
  2.6.0: vvfat driver generates bad FAT entries

Status in QEMU:
  New

Bug description:
  The vvfat driver sometimes generates entries about which file system
  checking utilities generate complaints.

  For example, dosfsck will complain that the volume label entry has
  non-zero size. ScanDisk from Windows 9x complains about invalid dot
  (".") and dot-dot ("..") entries in directories and also about invalid
  long file name entries. MS-DOS ScanDisk also often manages to find
  "lost clusters" on the drive.

  Tangentially: qemu-img convert fat:test test.img doesn't seem to work
  -- it generates an 504MiB of zero bytes and hangs. qemu-img map
  fat:test generates an assertion failure. Having qemu-img working might
  have helped with debugging the above issue.

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

[Qemu-devel] [Bug 1474263] Re: "Image format was not specified" warning should be suppressed for the vvfat (and probably nbd) driver

[felix]

> I could actually see the use of non-raw over NBD.  We support nested
> protocols (where you can use qcow2->qcow2->file), that is, where a file
> contains a qcow2 file whose contents are themselves a qcow2 image.
> (Perhaps useful in nested guests, where the outer qcow2 layer serves a
> disk to an L0 guest, which in turn uses the inner layer to present a
> disk to an L1 guest).  In such a case, opening just one layer of qcow2
> for service over NBD will expose the inner qcow2 image, and connecting
> qemu as an NBD client with format=raw will directly manipulate the qcow2
> data seen by the L0 guest, while connecting as an NBD client with
> format=qcow2 will see the raw data seen by the L1 guest.

Seems like an academic exercise, really. But if this use case is
practical, I believe three levels of wrapping is just as useful, and the
only way to work with that one is to run two or three instances of qemu-
nbd. With more layers, the set-up quickly becomes tangled and
unmanageable.

And I still doubt anyone would actually want to create a set-up like
this. It seems incredibly wasteful (but then, so is virtualisation in
general, so maybe that isn't an issue) and doesn't seem to accomplish
anything that couldn't be done with just one layer of wrapping.

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

Title:
  "Image format was not specified" warning should be suppressed for the
  vvfat (and probably nbd) driver

Status in QEMU:
  New

Bug description:
  Running

  qemu -drive file.driver=vvfat,file.dir=.

  displays

  WARNING: Image format was not specified for 'json:{"dir": ".", "driver": 
"vvfat"}' and probing guessed raw.
   Automatically detecting the format is dangerous for raw images, 
write operations on block 0 will be restricted.
   Specify the 'raw' format explicitly to remove the restrictions.

  However, since "images" provided by the vvfat driver are always raw
  (and the first sector isn't writeable in any case), this warning is
  superfluous and should not be displayed.

  A similar warning is displayed for NBD devices; I suspect it should be
  also disabled for similar reasons, but I'm not sure if serving non-raw
  images is actually a violation of the protocol. qemu-nbd translates
  them to raw images, for what it's worth, even if it may be suppressed
  with -f raw.

  Noticed on 2.3.0; the code that causes this behaviour is still
  apparently present in today's git master
  (f3a1b5068cea303a55e2a21a97e66d057eaae638). Speaking of versions: you
  may want to update the copyright notice that qemu -version displays.

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

[Bug 1860914] [NEW] QEMU prepends pathnames to command lines of Multiboot kernels and modules, contrary to the specification

[felix]

Public bug reported:

When QEMU is launched with the -kernel option to boot a Multiboot image,
the command line passed in the -append option is additionally prefixed
the pathname of the kernel image and a space. Likewise, module command
lines passed in the -initrd option are passed with the module pathname
and a space prepended. At the very least the former is contary to what
is prescribed in the Multiboot specification, version 0.6.96[0], which
says in §3.3:

> General-purpose boot loaders should allow user a complete control on
command line independently of other factors like image name.

With respect to module command lines, the spec is less clear, but GNU
GRUB2 (the de facto reference implementation) does not prepend pathnames
to command lines of either. I haven't tested GRUB legacy, but I assume
it exhibits the same behaviour. It would be strange if passing pathnames
was in fact intended; bootloader pathnames are useless to the loaded
kernel, which may potentially have a completely different view of the
file system from the bootloader.

Also, given that a kernel pathname may contain spaces, skipping it in
the command line cannot be done reliably, while loading a Multiboot
module from a pathname that contains spaces is outright impossible.

Found in 4.2.0, but latest git master apparently behaves the same.

[0]: https://www.gnu.org/software/grub/manual/multiboot/multiboot.html

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  QEMU prepends pathnames to command lines of Multiboot kernels and
  modules, contrary to the specification

Status in QEMU:
  New

Bug description:
  When QEMU is launched with the -kernel option to boot a Multiboot
  image, the command line passed in the -append option is additionally
  prefixed the pathname of the kernel image and a space. Likewise,
  module command lines passed in the -initrd option are passed with the
  module pathname and a space prepended. At the very least the former is
  contary to what is prescribed in the Multiboot specification, version
  0.6.96[0], which says in §3.3:

  > General-purpose boot loaders should allow user a complete control on
  command line independently of other factors like image name.

  With respect to module command lines, the spec is less clear, but GNU
  GRUB2 (the de facto reference implementation) does not prepend
  pathnames to command lines of either. I haven't tested GRUB legacy,
  but I assume it exhibits the same behaviour. It would be strange if
  passing pathnames was in fact intended; bootloader pathnames are
  useless to the loaded kernel, which may potentially have a completely
  different view of the file system from the bootloader.

  Also, given that a kernel pathname may contain spaces, skipping it in
  the command line cannot be done reliably, while loading a Multiboot
  module from a pathname that contains spaces is outright impossible.

  Found in 4.2.0, but latest git master apparently behaves the same.

  [0]: https://www.gnu.org/software/grub/manual/multiboot/multiboot.html

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

[Bug 1878915] [NEW] util/fdmon-io_uring.c:95: get_sqe: Assertion `ret > 1' failed.

[felix]

Public bug reported:

qemu 5.0.0, liburing1 0.6-3, Linux 5.6.0-1-686-pae (Debian)

Stack trace:

Stack trace of thread 31002:
#0  0xb7faf1cd __kernel_vsyscall (linux-gate.so.1 + 
0x11cd)
#1  0xb6c618e2 __libc_signal_restore_set (libc.so.6 + 
0x348e2)
#2  0xb6c4a309 __GI_abort (libc.so.6 + 0x1d309)
#3  0xb6c4a1d1 __assert_fail_base (libc.so.6 + 0x1d1d1)
#4  0xb6c59929 __GI___assert_fail (libc.so.6 + 0x2c929)
#5  0x00ba80be get_sqe (qemu-system-i386 + 0x6d00be)
#6  0x00ba80cb add_poll_add_sqe (qemu-system-i386 + 
0x6d00cb)
#7  0x00ba820c fill_sq_ring (qemu-system-i386 + 
0x6d020c)
#8  0x00ba7145 aio_poll (qemu-system-i386 + 0x6cf145)
#9  0x00aede63 blk_prw (qemu-system-i386 + 0x615e63)
#10 0x00aeef95 blk_pread (qemu-system-i386 + 0x616f95)
#11 0x008abbfa fdctrl_transfer_handler 
(qemu-system-i386 + 0x3d3bfa)
#12 0x00906c3d i8257_channel_run (qemu-system-i386 + 
0x42ec3d)
#13 0x008ac119 fdctrl_start_transfer (qemu-system-i386 
+ 0x3d4119)
#14 0x008ab233 fdctrl_write_data (qemu-system-i386 + 
0x3d3233)
#15 0x00708ae7 memory_region_write_accessor 
(qemu-system-i386 + 0x230ae7)
#16 0x007059e1 access_with_adjusted_size 
(qemu-system-i386 + 0x22d9e1)
#17 0x0070b931 memory_region_dispatch_write 
(qemu-system-i386 + 0x233931)
#18 0x006a87a2 address_space_stb (qemu-system-i386 + 
0x1d07a2)
#19 0x00829216 helper_outb (qemu-system-i386 + 0x351216)
#20 0xb06d9fdc n/a (n/a + 0x0)

Steps:

0. qemu-img create -f raw fda.img 3840K
1. mformat -i fda.img -n 48 -t 80 -h 2
2. qemu-system-i386 -fda fda.img -hda freedos.qcow2
3. Attempt to run 'dosfsck a:' in the guest

According to hw/block/fdc.c, a 3840K image should result in a virtual
floppy with a geometry of 48 sectors/track x 80 tracks x 2 sides.

The assert seems bogus either way.

** Affects: qemu
 Importance: Undecided
 Status: New


** Tags: floppy io-uring

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

Title:
  util/fdmon-io_uring.c:95: get_sqe: Assertion `ret > 1' failed.

Status in QEMU:
  New

Bug description:
  qemu 5.0.0, liburing1 0.6-3, Linux 5.6.0-1-686-pae (Debian)

  Stack trace:

  Stack trace of thread 31002:
  #0  0xb7faf1cd __kernel_vsyscall (linux-gate.so.1 + 
0x11cd)
  #1  0xb6c618e2 __libc_signal_restore_set (libc.so.6 + 
0x348e2)
  #2  0xb6c4a309 __GI_abort (libc.so.6 + 0x1d309)
  #3  0xb6c4a1d1 __assert_fail_base (libc.so.6 + 
0x1d1d1)
  #4  0xb6c59929 __GI___assert_fail (libc.so.6 + 
0x2c929)
  #5  0x00ba80be get_sqe (qemu-system-i386 + 0x6d00be)
  #6  0x00ba80cb add_poll_add_sqe (qemu-system-i386 + 
0x6d00cb)
  #7  0x00ba820c fill_sq_ring (qemu-system-i386 + 
0x6d020c)
  #8  0x00ba7145 aio_poll (qemu-system-i386 + 0x6cf145)
  #9  0x00aede63 blk_prw (qemu-system-i386 + 0x615e63)
  #10 0x00aeef95 blk_pread (qemu-system-i386 + 0x616f95)
  #11 0x008abbfa fdctrl_transfer_handler 
(qemu-system-i386 + 0x3d3bfa)
  #12 0x00906c3d i8257_channel_run (qemu-system-i386 + 
0x42ec3d)
  #13 0x008ac119 fdctrl_start_transfer 
(qemu-system-i386 + 0x3d4119)
  #14 0x008ab233 fdctrl_write_data (qemu-system-i386 + 
0x3d3233)
  #15 0x00708ae7 memory_region_write_accessor 
(qemu-system-i386 + 0x230ae7)
  #16 0x007059e1 access_with_adjusted_size 
(qemu-system-i386 + 0x22d9e1)
  #17 0x0070b931 memory_region_dispatch_write 
(qemu-system-i386 + 0x233931)
  #18 0x006a87a2 address_space_stb (qemu-system-i386 + 
0x1d07a2)
  #19 0x00829216 helper_outb (qemu-system-i386 + 
0x351216)
  #20 0xb06d9fdc n/a (n/a + 0x0)

  Steps:

  0. qemu-img create -f raw fda.img 3840K
  1. mformat -i fda.img -n 48 -t 80 -h 2
  2. qemu-system-i386 -fda fda.img -hda freedos.qcow2
  3. Attempt to run 'dosfsck a:' in the guest

  According to hw/block/fdc.c, a 3840K image should result in a virtual
  floppy with a geometry of 48 sectors/track x 80 tracks x 2 sides.

  The assert seems bogus either way.

To manage notifications about this bug go to:
https://bugs.laun

[Bug 1878915] Re: util/fdmon-io_uring.c:95: get_sqe: Assertion `ret > 1' failed.

[felix]

** Description changed:

  qemu 5.0.0, liburing1 0.6-3, Linux 5.6.0-1-686-pae (Debian)
  
  Stack trace:
  
- Stack trace of thread 31002:
- #0  0xb7faf1cd __kernel_vsyscall (linux-gate.so.1 + 
0x11cd)
- #1  0xb6c618e2 __libc_signal_restore_set (libc.so.6 + 
0x348e2)
- #2  0xb6c4a309 __GI_abort (libc.so.6 + 0x1d309)
- #3  0xb6c4a1d1 __assert_fail_base (libc.so.6 + 
0x1d1d1)
- #4  0xb6c59929 __GI___assert_fail (libc.so.6 + 
0x2c929)
- #5  0x00ba80be get_sqe (qemu-system-i386 + 0x6d00be)
- #6  0x00ba80cb add_poll_add_sqe (qemu-system-i386 + 
0x6d00cb)
- #7  0x00ba820c fill_sq_ring (qemu-system-i386 + 
0x6d020c)
- #8  0x00ba7145 aio_poll (qemu-system-i386 + 0x6cf145)
- #9  0x00aede63 blk_prw (qemu-system-i386 + 0x615e63)
- #10 0x00aeef95 blk_pread (qemu-system-i386 + 0x616f95)
- #11 0x008abbfa fdctrl_transfer_handler 
(qemu-system-i386 + 0x3d3bfa)
- #12 0x00906c3d i8257_channel_run (qemu-system-i386 + 
0x42ec3d)
- #13 0x008ac119 fdctrl_start_transfer 
(qemu-system-i386 + 0x3d4119)
- #14 0x008ab233 fdctrl_write_data (qemu-system-i386 + 
0x3d3233)
- #15 0x00708ae7 memory_region_write_accessor 
(qemu-system-i386 + 0x230ae7)
- #16 0x007059e1 access_with_adjusted_size 
(qemu-system-i386 + 0x22d9e1)
- #17 0x0070b931 memory_region_dispatch_write 
(qemu-system-i386 + 0x233931)
- #18 0x006a87a2 address_space_stb (qemu-system-i386 + 
0x1d07a2)
- #19 0x00829216 helper_outb (qemu-system-i386 + 
0x351216)
- #20 0xb06d9fdc n/a (n/a + 0x0)
+ Stack trace of thread 31002:
+ #0  0xb7faf1cd __kernel_vsyscall (linux-gate.so.1 + 0x11cd)
+ #1  0xb6c618e2 __libc_signal_restore_set (libc.so.6 + 0x348e2)
+ #2  0xb6c4a309 __GI_abort (libc.so.6 + 0x1d309)
+ #3  0xb6c4a1d1 __assert_fail_base (libc.so.6 + 0x1d1d1)
+ #4  0xb6c59929 __GI___assert_fail (libc.so.6 + 0x2c929)
+ #5  0x00ba80be get_sqe (qemu-system-i386 + 0x6d00be)
+ #6  0x00ba80cb add_poll_add_sqe (qemu-system-i386 + 0x6d00cb)
+ #7  0x00ba820c fill_sq_ring (qemu-system-i386 + 0x6d020c)
+ #8  0x00ba7145 aio_poll (qemu-system-i386 + 0x6cf145)
+ #9  0x00aede63 blk_prw (qemu-system-i386 + 0x615e63)
+ #10 0x00aeef95 blk_pread (qemu-system-i386 + 0x616f95)
+ #11 0x008abbfa fdctrl_transfer_handler (qemu-system-i386 + 0x3d3bfa)
+ #12 0x00906c3d i8257_channel_run (qemu-system-i386 + 0x42ec3d)
+ #13 0x008ac119 fdctrl_start_transfer (qemu-system-i386 + 0x3d4119)
+ #14 0x008ab233 fdctrl_write_data (qemu-system-i386 + 0x3d3233)
+ #15 0x00708ae7 memory_region_write_accessor (qemu-system-i386 + 
0x230ae7)
+ #16 0x007059e1 access_with_adjusted_size (qemu-system-i386 + 0x22d9e1)
+ #17 0x0070b931 memory_region_dispatch_write (qemu-system-i386 + 
0x233931)
+ #18 0x006a87a2 address_space_stb (qemu-system-i386 + 0x1d07a2)
+ #19 0x00829216 helper_outb (qemu-system-i386 + 0x351216)
+ #20 0xb06d9fdc n/a (n/a + 0x0)
  
  Steps:
  
  0. qemu-img create -f raw fda.img 3840K
  1. mformat -i fda.img -n 48 -t 80 -h 2
  2. qemu-system-i386 -fda fda.img -hda freedos.qcow2
  3. Attempt to run 'dosfsck a:' in the guest
  
  According to hw/block/fdc.c, a 3840K image should result in a virtual
  floppy with a geometry of 48 sectors/track x 80 tracks x 2 sides.
  
  The assert seems bogus either way.

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

Title:
  util/fdmon-io_uring.c:95: get_sqe: Assertion `ret > 1' failed.

Status in QEMU:
  New

Bug description:
  qemu 5.0.0, liburing1 0.6-3, Linux 5.6.0-1-686-pae (Debian)

  Stack trace:

  Stack trace of thread 31002:
  #0  0xb7faf1cd __kernel_vsyscall (linux-gate.so.1 + 0x11cd)
  #1  0xb6c618e2 __libc_signal_restore_set (libc.so.6 + 0x348e2)
  #2  0xb6c4a309 __GI_abort (libc.so.6 + 0x1d309)
  #3  0xb6c4a1d1 __assert_fail_base (libc.so.6 + 0x1d1d1)
  #4  0xb6c59929 __GI___assert_fail (libc.so.6 + 0x2c929)
  #5  0x00ba80be get_sqe (qemu-system-i386 + 0x6d00be)
  #6  0x00ba80cb add_poll_add_sqe (qemu-system-i386 + 0x6d00cb)
  #7  0x00ba820c fill_sq_ring (qemu-system-i386 + 0x6d020c)
  #8  0x00ba7145 aio_poll (qemu-system-i386 + 0x6cf145)
  #9  0x00aede63 blk_prw (qemu-system-i386 + 0x615e63)
  #10 0x00aeef95 blk_pread (qemu-system-i386 + 0x616f95)
  #11 0x008abbfa fdctrl_transfer_handler (qemu

[Bug 1878915] Re: util/fdmon-io_uring.c:95: get_sqe: Assertion `ret > 1' failed.

[felix]

Confirming that I can no longer reproduce the bug with the latest master
(ae3aa5da96f4ccf0c2a28851449d92db9fcfad71). I have not bisected the bug,
though; at the moment I am not quite able to afford the time.

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

Title:
  util/fdmon-io_uring.c:95: get_sqe: Assertion `ret > 1' failed.

Status in QEMU:
  Fix Committed

Bug description:
  qemu 5.0.0, liburing1 0.6-3, Linux 5.6.0-1-686-pae (Debian)

  Stack trace:

  Stack trace of thread 31002:
  #0  0xb7faf1cd __kernel_vsyscall (linux-gate.so.1 + 0x11cd)
  #1  0xb6c618e2 __libc_signal_restore_set (libc.so.6 + 0x348e2)
  #2  0xb6c4a309 __GI_abort (libc.so.6 + 0x1d309)
  #3  0xb6c4a1d1 __assert_fail_base (libc.so.6 + 0x1d1d1)
  #4  0xb6c59929 __GI___assert_fail (libc.so.6 + 0x2c929)
  #5  0x00ba80be get_sqe (qemu-system-i386 + 0x6d00be)
  #6  0x00ba80cb add_poll_add_sqe (qemu-system-i386 + 0x6d00cb)
  #7  0x00ba820c fill_sq_ring (qemu-system-i386 + 0x6d020c)
  #8  0x00ba7145 aio_poll (qemu-system-i386 + 0x6cf145)
  #9  0x00aede63 blk_prw (qemu-system-i386 + 0x615e63)
  #10 0x00aeef95 blk_pread (qemu-system-i386 + 0x616f95)
  #11 0x008abbfa fdctrl_transfer_handler (qemu-system-i386 + 0x3d3bfa)
  #12 0x00906c3d i8257_channel_run (qemu-system-i386 + 0x42ec3d)
  #13 0x008ac119 fdctrl_start_transfer (qemu-system-i386 + 0x3d4119)
  #14 0x008ab233 fdctrl_write_data (qemu-system-i386 + 0x3d3233)
  #15 0x00708ae7 memory_region_write_accessor (qemu-system-i386 + 
0x230ae7)
  #16 0x007059e1 access_with_adjusted_size (qemu-system-i386 + 0x22d9e1)
  #17 0x0070b931 memory_region_dispatch_write (qemu-system-i386 + 
0x233931)
  #18 0x006a87a2 address_space_stb (qemu-system-i386 + 0x1d07a2)
  #19 0x00829216 helper_outb (qemu-system-i386 + 0x351216)
  #20 0xb06d9fdc n/a (n/a + 0x0)

  Steps:

  0. qemu-img create -f raw fda.img 3840K
  1. mformat -i fda.img -n 48 -t 80 -h 2
  2. qemu-system-i386 -fda fda.img -hda freedos.qcow2
  3. Attempt to run 'dosfsck a:' in the guest

  According to hw/block/fdc.c, a 3840K image should result in a virtual
  floppy with a geometry of 48 sectors/track x 80 tracks x 2 sides.

  The assert seems bogus either way.

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

[Bug 1897568] Re: Strange keyboard behaviour in Vim editor

[felix]

Can someone explain why the patch keeps the incorrect behaviour as the
default? It’s silly.

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

Title:
  Strange keyboard behaviour in Vim editor

Status in QEMU:
  Fix Committed

Bug description:
  
  I'm running MS-DOS 7.10 in a QEMU virtual machine, and there is a problem 
with the keyboard in the Vim editor.  The arrow keys jump over a line, as if 
you had typed the key twice.  PgUp and PgDn are likewise affected.  Other 
applications are not affected, unless you shell out from Vim.

  The QEMU version is 5.0.0, and I'm using the "-k sv" option, but I've
  tried without it and it doesn't make a difference.

  I don't get this keyboard behaviour in the exact same VM under VMware
  Player or Bochs.

  -Albert.

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

[Bug 1860914] Re: QEMU prepends pathnames to command lines of Multiboot kernels and modules, contrary to the specification

[felix]

** Patch added: "cmdline.patch"
   
https://bugs.launchpad.net/qemu/+bug/1860914/+attachment/5383658/+files/cmdline.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/1860914

Title:
  QEMU prepends pathnames to command lines of Multiboot kernels and
  modules, contrary to the specification

Status in QEMU:
  New

Bug description:
  When QEMU is launched with the -kernel option to boot a Multiboot
  image, the command line passed in the -append option is additionally
  prefixed the pathname of the kernel image and a space. Likewise,
  module command lines passed in the -initrd option are passed with the
  module pathname and a space prepended. At the very least the former is
  contary to what is prescribed in the Multiboot specification, version
  0.6.96[0], which says in §3.3:

  > General-purpose boot loaders should allow user a complete control on
  command line independently of other factors like image name.

  With respect to module command lines, the spec is less clear, but GNU
  GRUB2 (the de facto reference implementation) does not prepend
  pathnames to command lines of either. I haven't tested GRUB legacy,
  but I assume it exhibits the same behaviour. It would be strange if
  passing pathnames was in fact intended; bootloader pathnames are
  useless to the loaded kernel, which may potentially have a completely
  different view of the file system from the bootloader.

  Also, given that a kernel pathname may contain spaces, skipping it in
  the command line cannot be done reliably, while loading a Multiboot
  module from a pathname that contains spaces is outright impossible.

  Found in 4.2.0, but latest git master apparently behaves the same.

  [0]: https://www.gnu.org/software/grub/manual/multiboot/multiboot.html

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

[Qemu-devel] qemu-ppc (prep) crashes with NetBSD guest

[Felix Deichmann]

Hi,

I tried to install NetBSD/prep 6.1 in qemu-ppc (-M prep), but qemu
crashes during installation with "floating point exception" in a
reproducible way.

qemu is version 1.5.2-1 from Arch Linux (sorry, didn't have the time
to build a current one) on a x86_64 host. The same happens with Win
qemu 1.5.1 binaries from http://lassauge.free.fr/qemu/.
I boot a custom NetBSD installation image ("sysinst_com0.fs") via the
"-kernel" option, and use a serial console (VGA doesn't work for me).
The custom image contains a kernel which does not use NetBSD's pnpbus
for prep, but hardwired device configuration like ISA IDE
controller's, as qemu seems to miss PnP information found on real PReP
machines completely?

# qemu-system-ppc -nographic -M prep -m 128M -hda hda.qcow2 -cdrom
NetBSD-6.1-prep.iso -serial ... -kernel sysinst_com0.fs

There seems to be a connection between the amount of RAM chosen and
the point where the crash happens. With 128M, qemu will crash when the
installer extracts some of the earlier packages, with 256M the crash
will happen later when extracting. Each one is reproducible at the
exact point of installation. And the amount of bytes extracted could
be the amount of RAM minus some number.
(64M and >256MB won't boot at all, so I could not finish installation...)

The boot image I used can be found at:
http://www.flxd.de/netbsd/qemu-ppc/sysinst_com0.fs

The ISO is the standard one from NetBSD.

Would be great if someone (also with a current qemu) could have a
look, as I did not even manage to get a core file...

Thanks
Felix

Re: [Qemu-devel] [PATCH] ppc: virtex_ml507: QEMU_OPTION_dtb support for this machine.

[Felix Deichmann]

2013/8/14 Alexander Graf :
>> -void *fdt;
>> +void *fdt = 0;
>
> This should be NULL. NULL doesn't have to be 0 according to C IIRC.

The last statement is wrong here, NULL is always the same as 0
language-wise. Although the above code is always correct, some will
consider it better style to use NULL when dealing with pointer
context.
What you probably meant is that the *internal representation* of a
null pointer is not guaranteed to be all-0-bits, in contrast to the
conceptual null pointer constant (== 0) understood and taken care of
by the compiler. But the internal representation is irrelevant here.

http://c-faq.com/null/

Felix

[Qemu-devel] QEMU suitable for mission critical applications?

[Felix Oxley]

Hello,

I have a an (almost) EOL factory planning system running on Solaris
Sparc which I would like to move to intel (and preferably virtualise)
in order to avoid having to maintain the Sun system and backup system.
The text based cobol application runs on this system: SunOS gplan 5.9
Generic_118558-35 sun4u sparc SUNW,Sun-Blade-1500. It is not feasible
to recompile the application to x86.

Therefore I am looking for alternative solutions. I heard of
Transitive QuickTransit, however since being purchased by IBM I do not
believe this is being marketed.

Would QEMU be suitable for this task? Would I be able to get commercial support?

Thanks for your advice.

Re: [Qemu-devel] QEMU suitable for mission critical applications?

[Felix Oxley]

Thank you all for your responses.
It appears that it would be wise to continue to maintain Sun hardware.

On 12 June 2011 22:51, Blue Swirl  wrote:
> On Wed, Jun 8, 2011 at 2:19 PM, Stefan Hajnoczi  wrote:
>> On Wed, Jun 8, 2011 at 11:08 AM, Felix Oxley  wrote:
>>> I have a an (almost) EOL factory planning system running on Solaris
>>> Sparc which I would like to move to intel (and preferably virtualise)
>>> in order to avoid having to maintain the Sun system and backup system.
>>> The text based cobol application runs on this system: SunOS gplan 5.9
>>> Generic_118558-35 sun4u sparc SUNW,Sun-Blade-1500. It is not feasible
>>> to recompile the application to x86.
>>>
>>> Therefore I am looking for alternative solutions. I heard of
>>> Transitive QuickTransit, however since being purchased by IBM I do not
>>> believe this is being marketed.
>>
>> Right.
>>
>>> Would QEMU be suitable for this task? Would I be able to get commercial 
>>> support?
>>
>> I think it will be difficult to get commerical support for QEMU SPARC.
>>  How well QEMU runs sun4u I'm not sure.
>
> Not very well yet. For running a single application, it could be
> possible to develop a Solaris user emulator to run only the
> applications under x86 Solaris.
>
>> Personally, I would leave it running untouched since there isn't a
>> low-risk solution.  Perhaps others on the list have more information
>> but I wanted to reply in case no one else does so you'll at least have
>> something to go by.
>
> Used Sparc hardware is not very expensive either.
>

[Qemu-devel] [PATCH] seccomp: add timerfd_create and timerfd_settime to the whitelist

[Felix Geyer]

libusb calls timerfd_create() and timerfd_settime() when it's built with
timerfd support.

Command to reproduce:

qemu -sandbox on -monitor stdio -device piix3-usb-uhci,id=usb
 -device usb-host,hostbus=1,hostaddr=3,id=hostdev0

Log messages:

audit(1390730418.924:135): auid=4294967295 uid=121 gid=103 ses=4294967295
   pid=5232 comm="qemu-system-x86" sig=31 syscall=283
   compat=0 ip=0x7f2b0f4e96a7 code=0x0
audit(1390733100.580:142): auid=4294967295 uid=121 gid=103 ses=4294967295
   pid=16909 comm="qemu-system-x86" sig=31 syscall=286
   compat=0 ip=0x7f03513a06da code=0x0

Signed-off-by: Felix Geyer 
---
 qemu-seccomp.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/qemu-seccomp.c b/qemu-seccomp.c
index caa926e..2705468 100644
--- a/qemu-seccomp.c
+++ b/qemu-seccomp.c
@@ -225,7 +225,9 @@ static const struct QemuSeccompSyscall seccomp_whitelist[] 
= {
 { SCMP_SYS(fchmod), 240 },
 { SCMP_SYS(shmget), 240 },
 { SCMP_SYS(shmat), 240 },
-{ SCMP_SYS(shmdt), 240 }
+{ SCMP_SYS(shmdt), 240 },
+{ SCMP_SYS(timerfd_create), 240 },
+{ SCMP_SYS(timerfd_settime), 240 }
 };

 int seccomp_start(void)
-- 
1.8.5.3

Re: [Qemu-devel] [PATCH] seccomp: add timerfd_create and timerfd_settime to the whitelist

[Felix Geyer]

On 28.01.2014 14:00, Eduardo Otubo wrote:
> On 01/26/2014 10:21 AM, Felix Geyer wrote:
>> libusb calls timerfd_create() and timerfd_settime() when it's built with
>> timerfd support.
>>
>> Command to reproduce:
>>
>> qemu -sandbox on -monitor stdio -device piix3-usb-uhci,id=usb
>>   -device usb-host,hostbus=1,hostaddr=3,id=hostdev0
>>
>> Log messages:
>>
>> audit(1390730418.924:135): auid=4294967295 uid=121 gid=103 ses=4294967295
>> pid=5232 comm="qemu-system-x86" sig=31 
>> syscall=283
>> compat=0 ip=0x7f2b0f4e96a7 code=0x0
>> audit(1390733100.580:142): auid=4294967295 uid=121 gid=103 ses=4294967295
>> pid=16909 comm="qemu-system-x86" sig=31 
>> syscall=286
>> compat=0 ip=0x7f03513a06da code=0x0
>>
>> Signed-off-by: Felix Geyer 
>> ---
>>   qemu-seccomp.c | 4 +++-
>>   1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/qemu-seccomp.c b/qemu-seccomp.c
>> index caa926e..2705468 100644
>> --- a/qemu-seccomp.c
>> +++ b/qemu-seccomp.c
>> @@ -225,7 +225,9 @@ static const struct QemuSeccompSyscall 
>> seccomp_whitelist[] = {
>>   { SCMP_SYS(fchmod), 240 },
>>   { SCMP_SYS(shmget), 240 },
>>   { SCMP_SYS(shmat), 240 },
>> -{ SCMP_SYS(shmdt), 240 }
>> +{ SCMP_SYS(shmdt), 240 },
>> +{ SCMP_SYS(timerfd_create), 240 },
>> +{ SCMP_SYS(timerfd_settime), 240 }
>
> Did you deliberately set the priority to 240? Or did you run any sort of 
> benchmark (strace) to
> find this value?
>
> Regards,

Not really, sorry.

I've now done a benchmark on x86_64, copying a few hundred MB from a USB drive:

calls  syscall
 - 
   5303600 write
   2240554 read
   2167030 ppoll
   2134828 ioctl
704023 timerfd_settime
689105 poll
 83122 futex
   803 writev
   476 rt_sigprocmask
   287 recvmsg
   178 brk

timerfd_create is basically only called once so it can have the lowest priority.
timerfd_settime should probably have priority around 242.

Regards,
Felix

[Qemu-devel] [PATCH v2] seccomp: add timerfd_create and timerfd_settime to the whitelist

[Felix Geyer]

libusb calls timerfd_create() and timerfd_settime() when it's built with
timerfd support.

Command to reproduce:

   -device usb-host,hostbus=1,hostaddr=3,id=hostdev0

Log messages:

audit(1390730418.924:135): auid=4294967295 uid=121 gid=103 ses=4294967295
   pid=5232 comm="qemu-system-x86" sig=31 syscall=283
   compat=0 ip=0x7f2b0f4e96a7 code=0x0
audit(1390733100.580:142): auid=4294967295 uid=121 gid=103 ses=4294967295
   pid=16909 comm="qemu-system-x86" sig=31 syscall=286
   compat=0 ip=0x7f03513a06da code=0x0

Reading a few hundred MB from a USB drive on x86_64 shows this syscall 
distribution.
Therefore the timerfd_settime priority is set to 242.

calls  syscall
 - 
   5303600 write
   2240554 read
   2167030 ppoll
   2134828 ioctl
704023 timerfd_settime
689105 poll
 83122 futex
   803 writev
   476 rt_sigprocmask
   287 recvmsg
   178 brk

Signed-off-by: Felix Geyer 
---
 qemu-seccomp.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/qemu-seccomp.c b/qemu-seccomp.c
index caa926e..b00922c 100644
--- a/qemu-seccomp.c
+++ b/qemu-seccomp.c
@@ -143,6 +143,7 @@ static const struct QemuSeccompSyscall seccomp_whitelist[] 
= {
 { SCMP_SYS(getsockname), 242 },
 { SCMP_SYS(getpeername), 242 },
 { SCMP_SYS(accept4), 242 },
+{ SCMP_SYS(timerfd_settime), 242 },
 { SCMP_SYS(newfstatat), 241 },
 { SCMP_SYS(shutdown), 241 },
 { SCMP_SYS(getsockopt), 241 },
@@ -225,7 +226,8 @@ static const struct QemuSeccompSyscall seccomp_whitelist[] 
= {
 { SCMP_SYS(fchmod), 240 },
 { SCMP_SYS(shmget), 240 },
 { SCMP_SYS(shmat), 240 },
-{ SCMP_SYS(shmdt), 240 }
+{ SCMP_SYS(shmdt), 240 },
+{ SCMP_SYS(timerfd_create), 240 }
 };

 int seccomp_start(void)
-- 
1.9.rc1

[Qemu-devel] [PATCH] linux-user: translate resource also for prlimit64

[Felix Janda]

The resource argument is translated from host to target for
[gs]etprlimit but not for prlimit64. Fix this.

Signed-off-by: Felix Janda 
---
 linux-user/syscall.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index aaac6a2..5658b66 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -9529,6 +9529,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
 /* args: pid, resource number, ptr to new rlimit, ptr to old rlimit */
 struct target_rlimit64 *target_rnew, *target_rold;
 struct host_rlimit64 rnew, rold, *rnewp = 0;
+int resource = target_to_host_resource(arg2);
 if (arg3) {
 if (!lock_user_struct(VERIFY_READ, target_rnew, arg3, 1)) {
 goto efault;
@@ -9539,7 +9540,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
 rnewp = &rnew;
 }
 
-ret = get_errno(sys_prlimit64(arg1, arg2, rnewp, arg4 ? &rold : 0));
+ret = get_errno(sys_prlimit64(arg1, resource, rnewp, arg4 ? &rold : 
0));
 if (!is_error(ret) && arg4) {
 if (!lock_user_struct(VERIFY_WRITE, target_rold, arg4, 1)) {
 goto efault;
-- 
2.0.4

Re: [Qemu-devel] linux-user: translate resource also for prlimit64

[Felix Janda]

ping (forgot to CC to maintainer before)

http://patchwork.ozlabs.org/patch/417154/

[Qemu-devel] [Bug 1545024] [NEW] compiling on armv7 crashes compile qlx.o

[Klaftenegger Felix]

Public bug reported:

If i try to compile qemu on armv7 cpu i get this error:

  LINK  qemu-nbd
  CCqemu-img.o
  LINK  qemu-img
  LINK  qemu-io
  LINK  qemu-bridge-helper
  CCqmp-marshal.o
  CChw/display/qxl.o
{standard input}: Assembler messages:
{standard input}:1704: Error: bad instruction `lock'
{standard input}:1704: Error: bad instruction `addl $0,0(%rsp)'
{standard input}:1864: Error: bad instruction `lock'
{standard input}:1864: Error: bad instruction `addl $0,0(%rsp)'
{standard input}:5239: Error: bad instruction `lock'
{standard input}:5239: Error: bad instruction `addl $0,0(%rsp)'
{standard input}:5731: Error: bad instruction `lock'
{standard input}:5731: Error: bad instruction `addl $0,0(%rsp)'
{standard input}:11923: Error: bad instruction `lock'
{standard input}:11923: Error: bad instruction `addl $0,0(%rsp)'
{standard input}:13960: Error: bad instruction `lock'
{standard input}:13960: Error: bad instruction `addl $0,0(%rsp)'
{standard input}:14349: Error: bad instruction `lock'
{standard input}:14349: Error: bad instruction `addl $0,0(%rsp)'
/home/fleixi/git/qemu/rules.mak:57: recipe for target 'hw/display/qxl.o' failed
make: *** [hw/display/qxl.o] Error 1

Build options are:

 ./configure --target-list=i386-softmmu
Install prefix/usr/local
BIOS directory/usr/local/share/qemu
binary directory  /usr/local/bin
library directory /usr/local/lib
module directory  /usr/local/lib/qemu
libexec directory /usr/local/libexec
include directory /usr/local/include
config directory  /usr/local/etc
local state directory   /usr/local/var
Manual directory  /usr/local/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path   /home/fleixi/git/qemu
C compilercc
Host C compiler   cc
C++ compiler  c++
Objective-C compiler cc
ARFLAGS   rv
CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread 
-I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabihf/glib-2.0/include  -g 
-mcpu=cortex-a15.cortex-a7 -mfloat-abi=hard -mfpu=neon-vfpv4 -O2 -pipe 
-ffast-math -ftree-vectorize -mvectorize-with-neon-quad -fstack-protector 
--param=ssp-buffer-size=4
QEMU_CFLAGS   -I/usr/include/pixman-1   -Werror  -D_GNU_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes 
-fno-strict-aliasing -fno-common  -Wendif-labels -Wmissing-include-dirs 
-Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self 
-Wignored-qualifiers -Wold-style-declaration -Wold-style-definition 
-Wtype-limits -fstack-protector-strong   -I/usr/include/libpng12  
-I/usr/local/include/spice-server -I/usr/local/include 
-I/usr/local/include/spice-1 -I/usr/include/glib-2.0 
-I/usr/lib/arm-linux-gnueabihf/glib-2.0/include -I/usr/include/pixman-1 
LDFLAGS   -Wl,--warn-common -g 
make  make
install   install
pythonpython -B
smbd  /usr/sbin/smbd
module supportno
host CPU  arm
host big endian   no
target list   i386-softmmu
tcg debug enabled no
gprof enabled no
sparse enabledno
strip binariesyes
profiler  no
static build  no
pixmansystem
SDL support   no
GTK support   yes
GTK GL supportno
GNUTLS supportno
GNUTLS hash   no
libgcrypt no
nettleno
libtasn1  no
VTE support   no
curses supportno
virgl support no
curl support  yes
mingw32 support   no
Audio drivers oss
Block whitelist (rw) 
Block whitelist (ro) 
VirtFS supportno
VNC support   yes
VNC SASL support  yes
VNC JPEG support  yes
VNC PNG support   yes
xen support   no
brlapi supportno
bluez  supportyes
Documentation no
PIE   no
vde support   no
netmap supportno
Linux AIO support no
ATTR/XATTR support yes
Install blobs yes
KVM support   yes
RDMA support  no
TCG interpreter   no
fdt support   no
preadv supportyes
fdatasync yes
madvise   yes
posix_madvise yes
sigev_thread_id   yes
uuid support  no
libcap-ng support no
vhost-net support yes
vhost-scsi support yes
Trace backendslog
spice support yes (0.12.10/0.12.6)
rbd support   no
xfsctl supportno
smartcard support no
libusbno
usb net redir no
OpenGL supportno
libiscsi support  no
libnfs supportno
build guest agent yes
QGA VSS support   no
QGA w32 disk info no
QGA MSI support   no
seccomp support   no
coroutine backend ucontext
coroutine poolyes
GlusterFS support no
Archipelago support no
gcov  gcov
gcov enabled  no
TPM support   yes
libssh2 support   no
TPM passthrough   no
QOM debugging yes
vhdx  no
lzo support   no
snappy supportno
bzip2 support yes
NUMA host support no
tcmalloc support  no
jemalloc support  no

testet with  qemu-git branch stable-2.4 and git master

Shoulded the configure detecting "bigendian" too?

** Affects: qemu
 Importance: Undecided
  

[Qemu-devel] [Bug 1545024] Re: compiling on armv7 crashes compile qlx.o

[Klaftenegger Felix]

i have tried gcc4.9 and gcc4.8. both creating this error

im using debian 8(jessie) and the host is a odroid-xu4
(http://www.hardkernel.com/main/products/prdt_info.php?g_code=G143452239825&tab_idx=2)

spice and spice-platform are build from the last stable the other
dependecies are from the debian repo

bigendian: i have mixed older arm versions in my mind your right

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

Title:
  compiling on armv7 crashes compile qlx.o

Status in QEMU:
  New

Bug description:
  If i try to compile qemu on armv7 cpu i get this error:

LINK  qemu-nbd
CCqemu-img.o
LINK  qemu-img
LINK  qemu-io
LINK  qemu-bridge-helper
CCqmp-marshal.o
CChw/display/qxl.o
  {standard input}: Assembler messages:
  {standard input}:1704: Error: bad instruction `lock'
  {standard input}:1704: Error: bad instruction `addl $0,0(%rsp)'
  {standard input}:1864: Error: bad instruction `lock'
  {standard input}:1864: Error: bad instruction `addl $0,0(%rsp)'
  {standard input}:5239: Error: bad instruction `lock'
  {standard input}:5239: Error: bad instruction `addl $0,0(%rsp)'
  {standard input}:5731: Error: bad instruction `lock'
  {standard input}:5731: Error: bad instruction `addl $0,0(%rsp)'
  {standard input}:11923: Error: bad instruction `lock'
  {standard input}:11923: Error: bad instruction `addl $0,0(%rsp)'
  {standard input}:13960: Error: bad instruction `lock'
  {standard input}:13960: Error: bad instruction `addl $0,0(%rsp)'
  {standard input}:14349: Error: bad instruction `lock'
  {standard input}:14349: Error: bad instruction `addl $0,0(%rsp)'
  /home/fleixi/git/qemu/rules.mak:57: recipe for target 'hw/display/qxl.o' 
failed
  make: *** [hw/display/qxl.o] Error 1

  Build options are:

   ./configure --target-list=i386-softmmu
  Install prefix/usr/local
  BIOS directory/usr/local/share/qemu
  binary directory  /usr/local/bin
  library directory /usr/local/lib
  module directory  /usr/local/lib/qemu
  libexec directory /usr/local/libexec
  include directory /usr/local/include
  config directory  /usr/local/etc
  local state directory   /usr/local/var
  Manual directory  /usr/local/share/man
  ELF interp prefix /usr/gnemul/qemu-%M
  Source path   /home/fleixi/git/qemu
  C compilercc
  Host C compiler   cc
  C++ compiler  c++
  Objective-C compiler cc
  ARFLAGS   rv
  CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread 
-I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabihf/glib-2.0/include  -g 
-mcpu=cortex-a15.cortex-a7 -mfloat-abi=hard -mfpu=neon-vfpv4 -O2 -pipe 
-ffast-math -ftree-vectorize -mvectorize-with-neon-quad -fstack-protector 
--param=ssp-buffer-size=4
  QEMU_CFLAGS   -I/usr/include/pixman-1   -Werror  -D_GNU_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes 
-fno-strict-aliasing -fno-common  -Wendif-labels -Wmissing-include-dirs 
-Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self 
-Wignored-qualifiers -Wold-style-declaration -Wold-style-definition 
-Wtype-limits -fstack-protector-strong   -I/usr/include/libpng12  
-I/usr/local/include/spice-server -I/usr/local/include 
-I/usr/local/include/spice-1 -I/usr/include/glib-2.0 
-I/usr/lib/arm-linux-gnueabihf/glib-2.0/include -I/usr/include/pixman-1 
  LDFLAGS   -Wl,--warn-common -g 
  make  make
  install   install
  pythonpython -B
  smbd  /usr/sbin/smbd
  module supportno
  host CPU  arm
  host big endian   no
  target list   i386-softmmu
  tcg debug enabled no
  gprof enabled no
  sparse enabledno
  strip binariesyes
  profiler  no
  static build  no
  pixmansystem
  SDL support   no
  GTK support   yes
  GTK GL supportno
  GNUTLS supportno
  GNUTLS hash   no
  libgcrypt no
  nettleno
  libtasn1  no
  VTE support   no
  curses supportno
  virgl support no
  curl support  yes
  mingw32 support   no
  Audio drivers oss
  Block whitelist (rw) 
  Block whitelist (ro) 
  VirtFS supportno
  VNC support   yes
  VNC SASL support  yes
  VNC JPEG support  yes
  VNC PNG support   yes
  xen support   no
  brlapi supportno
  bluez  supportyes
  Documentation no
  PIE   no
  vde support   no
  netmap supportno
  Linux AIO support no
  ATTR/XATTR support yes
  Install blobs yes
  KVM support   yes
  RDMA support  no
  TCG interpreter   no
  fdt support   no
  preadv supportyes
  fdatasync yes
  madvise   yes
  posix_madvise yes
  sigev_thread_id   yes
  uuid support  no
  libcap-ng support no
  vhost-net support yes
  vhost-scsi support yes
  Trace backendslog
  spice support yes (0.12.

[Qemu-devel] [Bug 1545024] Re: compiling on armv7 crashes compile qlx.o

[Klaftenegger Felix]

if i try to compile with target-list=i386-linux-user it is working so
the problem must the target i386-softmmu

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

Title:
  compiling on armv7 crashes compile qlx.o

Status in QEMU:
  New

Bug description:
  If i try to compile qemu on armv7 cpu i get this error:

LINK  qemu-nbd
CCqemu-img.o
LINK  qemu-img
LINK  qemu-io
LINK  qemu-bridge-helper
CCqmp-marshal.o
CChw/display/qxl.o
  {standard input}: Assembler messages:
  {standard input}:1704: Error: bad instruction `lock'
  {standard input}:1704: Error: bad instruction `addl $0,0(%rsp)'
  {standard input}:1864: Error: bad instruction `lock'
  {standard input}:1864: Error: bad instruction `addl $0,0(%rsp)'
  {standard input}:5239: Error: bad instruction `lock'
  {standard input}:5239: Error: bad instruction `addl $0,0(%rsp)'
  {standard input}:5731: Error: bad instruction `lock'
  {standard input}:5731: Error: bad instruction `addl $0,0(%rsp)'
  {standard input}:11923: Error: bad instruction `lock'
  {standard input}:11923: Error: bad instruction `addl $0,0(%rsp)'
  {standard input}:13960: Error: bad instruction `lock'
  {standard input}:13960: Error: bad instruction `addl $0,0(%rsp)'
  {standard input}:14349: Error: bad instruction `lock'
  {standard input}:14349: Error: bad instruction `addl $0,0(%rsp)'
  /home/fleixi/git/qemu/rules.mak:57: recipe for target 'hw/display/qxl.o' 
failed
  make: *** [hw/display/qxl.o] Error 1

  Build options are:

   ./configure --target-list=i386-softmmu
  Install prefix/usr/local
  BIOS directory/usr/local/share/qemu
  binary directory  /usr/local/bin
  library directory /usr/local/lib
  module directory  /usr/local/lib/qemu
  libexec directory /usr/local/libexec
  include directory /usr/local/include
  config directory  /usr/local/etc
  local state directory   /usr/local/var
  Manual directory  /usr/local/share/man
  ELF interp prefix /usr/gnemul/qemu-%M
  Source path   /home/fleixi/git/qemu
  C compilercc
  Host C compiler   cc
  C++ compiler  c++
  Objective-C compiler cc
  ARFLAGS   rv
  CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread 
-I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabihf/glib-2.0/include  -g 
-mcpu=cortex-a15.cortex-a7 -mfloat-abi=hard -mfpu=neon-vfpv4 -O2 -pipe 
-ffast-math -ftree-vectorize -mvectorize-with-neon-quad -fstack-protector 
--param=ssp-buffer-size=4
  QEMU_CFLAGS   -I/usr/include/pixman-1   -Werror  -D_GNU_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes 
-fno-strict-aliasing -fno-common  -Wendif-labels -Wmissing-include-dirs 
-Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self 
-Wignored-qualifiers -Wold-style-declaration -Wold-style-definition 
-Wtype-limits -fstack-protector-strong   -I/usr/include/libpng12  
-I/usr/local/include/spice-server -I/usr/local/include 
-I/usr/local/include/spice-1 -I/usr/include/glib-2.0 
-I/usr/lib/arm-linux-gnueabihf/glib-2.0/include -I/usr/include/pixman-1 
  LDFLAGS   -Wl,--warn-common -g 
  make  make
  install   install
  pythonpython -B
  smbd  /usr/sbin/smbd
  module supportno
  host CPU  arm
  host big endian   no
  target list   i386-softmmu
  tcg debug enabled no
  gprof enabled no
  sparse enabledno
  strip binariesyes
  profiler  no
  static build  no
  pixmansystem
  SDL support   no
  GTK support   yes
  GTK GL supportno
  GNUTLS supportno
  GNUTLS hash   no
  libgcrypt no
  nettleno
  libtasn1  no
  VTE support   no
  curses supportno
  virgl support no
  curl support  yes
  mingw32 support   no
  Audio drivers oss
  Block whitelist (rw) 
  Block whitelist (ro) 
  VirtFS supportno
  VNC support   yes
  VNC SASL support  yes
  VNC JPEG support  yes
  VNC PNG support   yes
  xen support   no
  brlapi supportno
  bluez  supportyes
  Documentation no
  PIE   no
  vde support   no
  netmap supportno
  Linux AIO support no
  ATTR/XATTR support yes
  Install blobs yes
  KVM support   yes
  RDMA support  no
  TCG interpreter   no
  fdt support   no
  preadv supportyes
  fdatasync yes
  madvise   yes
  posix_madvise yes
  sigev_thread_id   yes
  uuid support  no
  libcap-ng support no
  vhost-net support yes
  vhost-scsi support yes
  Trace backendslog
  spice support yes (0.12.10/0.12.6)
  rbd support   no
  xfsctl supportno
  smartcard support no
  libusbno
  usb net redir no
  OpenGL supportno
  libiscsi support  no
  libnfs supportno
  build guest agent yes
  QGA VSS support   no
  QGA w32 disk in

[Qemu-devel] [PATCH] Memory Based Block Device

[Evan Felix]

Folks here is a patch i've made for qemu that adds a memory based
block device, it utilizes memory on the Host side to emulate a block
device.

I've tested this on a few boxes to allow a kernel/initramfs system to
boot without needing a specified block device(it automatically creates
a small one) and for installing a usable system on.  One note you can
never shut down the running system, but seems to work fine when only
re-boots are required.  I've installed debian on it a few times.

Some Things I'd like comments on:
- The auto-detection code in the block code causes the code to
allocate the memory used twice, even though it only gets used the
second time.
- using qemu_mallocz seems to pre-allocate all the memory used, which
is fine, but my early code with calloc only allocated what blocks were
actually used. Does this bother people.

Evan Felix


diff -urNp -x '*~' -x '*html' -x '*.mak' -x '*.1'
kvm-28/qemu.orig/block.c kvm-28/qemu/block.c
--- kvm-28/qemu.orig/block.c2007-06-07 08:13:47.0 -0700
+++ kvm-28/qemu/block.c 2007-07-11 13:29:02.0 -0700
@@ -1244,6 +1244,7 @@ static int bdrv_write_em(BlockDriverStat
void bdrv_init(void)
{
bdrv_register(&bdrv_raw);
+bdrv_register(&bdrv_mem);
bdrv_register(&bdrv_host_device);
#ifndef _WIN32
bdrv_register(&bdrv_cow);
diff -urNp -x '*~' -x '*html' -x '*.mak' -x '*.1'
kvm-28/qemu.orig/block-mem.c kvm-28/qemu/block-mem.c
--- kvm-28/qemu.orig/block-mem.c1969-12-31 16:00:00.0 -0800
+++ kvm-28/qemu/block-mem.c 2007-07-09 13:46:39.0 -0700
@@ -0,0 +1,129 @@
+/*
+ *  Block Driver for a Memory disk on the host side.
+ *
+ *  Copyright (c) 2007 Pacific Northwest National Laboratory
+ * and Evan Felix <[EMAIL PROTECTED]>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program (see the file COPYING included with this
+ *  distribution); if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#include "vl.h"
+#include "block_int.h"
+
+//I took this from block-raw.c
+#ifdef __sun__
+#define _POSIX_PTHREAD_SEMANTICS 1
+#include 
+#include 
+#endif
+#ifdef __linux__
+#include 
+#include 
+#include 
+#endif
+#ifdef __FreeBSD__
+#include 
+#endif
+
+#define DEBUG_MEM 0
+
+#ifdef DEBUG_MEM
+#define DEBUG(fmt,a...) printf("D:%s:%d> " fmt "\n",__FILE__,__LINE__,##a)
+#else
+#define DEBUG(fmt,a...)
+#endif
+
+typedef struct BDRVMemState {
+   void *memory;
+   int64_t length;
+} BDRVMemState;
+
+static int mem_open(BlockDriverState *bs, const char *filename, int flags)
+{
+   BDRVMemState *s = bs->opaque;
+   
+   bs->locked = 1;
+   bs->type   = BDRV_TYPE_HD;
+   //Try to parse the filename as a number of bytes.  add recognize M,K,G 
laterz.
+   s->length = strtol(filename+4,NULL,0);
+   DEBUG("mem_open:Raw Image size: %s -> %ld\n",filename,s->length);
+   
+   s->memory=qemu_mallocz(s->length);
+   if (! s->memory)
+   return -ENOMEM;
+   return 0;
+}
+
+static void mem_close(BlockDriverState *bs) {
+   
+   BDRVMemState *s = bs->opaque;
+   DEBUG("mem_close: %lld\n",s->length);
+   qemu_free(s->memory);
+   s->length=0;
+}
+
+static int mem_pread(BlockDriverState *bs, int64_t offset,
+ uint8_t *buf, int count)
+{
+BDRVMemState *s = bs->opaque;
+   
+   if (offset < 0 || (offset + count)>s->length) {
+   return -EINVAL; 
+   }
+   
+memcpy(buf,(s->memory+offset),count);
+   return count;
+}
+
+static int mem_pwrite(BlockDriverState *bs, int64_t offset,
+  const uint8_t *buf, int count)
+{
+   BDRVMemState *s = bs->opaque;
+   
+   if (offset < 0 || (offset + count)>s->length) {
+   return -EINVAL; 
+   }
+   
+   memcpy((s->memory+offset),buf,count);
+   return count;
+}
+
+static void mem_flush(BlockDriverState *bs)
+{
+   //Do Nothing for now
+   DEBUG("mem_flush\n");
+}
+
+static int64_t  mem_getlength(BlockDriverState *bs)
+{
+BDRVMemState *s = bs->opaque;
+
+   return s->length

[Qemu-devel] Re: [kvm-devel] [PATCH] Memory Based Block Device

[Evan Felix]

The Current way to boot a kernel and initrd is to use an option ROM,
bt it still needs a boot sector to hand to the bios so that it knows
where the code got loaded into ram.  This patch makes a fake one just
before its needed.

I never though of the /dev/null trick.  :)

Evan

On 7/25/07, Anthony Liguori <[EMAIL PROTECTED]> wrote:

Evan Felix wrote:
> Folks here is a patch i've made for qemu that adds a memory based
> block device, it utilizes memory on the Host side to emulate a block
> device.
>

I often use -hda /dev/null for -kernel/-append.

If you really want to implement a "proper" solution for -kernel/-append,
I think the right thing to do would be to use an option ROM instead of a
fake boot sector.

Regards,

Anthony Liguori

> I've tested this on a few boxes to allow a kernel/initramfs system to
> boot without needing a specified block device(it automatically creates
> a small one) and for installing a usable system on.  One note you can
> never shut down the running system, but seems to work fine when only
> re-boots are required.  I've installed debian on it a few times.
>
> Some Things I'd like comments on:
> - The auto-detection code in the block code causes the code to
> allocate the memory used twice, even though it only gets used the
> second time.
> - using qemu_mallocz seems to pre-allocate all the memory used, which
> is fine, but my early code with calloc only allocated what blocks were
> actually used. Does this bother people.
>
> Evan Felix
>
>
> diff -urNp -x '*~' -x '*html' -x '*.mak' -x '*.1'
> kvm-28/qemu.orig/block.c kvm-28/qemu/block.c
> --- kvm-28/qemu.orig/block.c  2007-06-07 08:13:47.0 -0700
> +++ kvm-28/qemu/block.c   2007-07-11 13:29:02.0 -0700
> @@ -1244,6 +1244,7 @@ static int bdrv_write_em(BlockDriverStat
>  void bdrv_init(void)
>  {
>  bdrv_register(&bdrv_raw);
> +bdrv_register(&bdrv_mem);
>  bdrv_register(&bdrv_host_device);
>  #ifndef _WIN32
>  bdrv_register(&bdrv_cow);
> diff -urNp -x '*~' -x '*html' -x '*.mak' -x '*.1'
> kvm-28/qemu.orig/block-mem.c kvm-28/qemu/block-mem.c
> --- kvm-28/qemu.orig/block-mem.c  1969-12-31 16:00:00.0 -0800
> +++ kvm-28/qemu/block-mem.c   2007-07-09 13:46:39.0 -0700
> @@ -0,0 +1,129 @@
> +/*
> + *  Block Driver for a Memory disk on the host side.
> + *
> + *  Copyright (c) 2007 Pacific Northwest National Laboratory
> + * and Evan Felix <[EMAIL PROTECTED]>
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License as published by
> + *  the Free Software Foundation; either version 2 of the License, or
> + *  (at your option) any later version.
> + *
> + *  This program is distributed in the hope that it will be useful,
> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *  GNU General Public License for more details.
> + *
> + *  You should have received a copy of the GNU General Public License
> + *  along with this program (see the file COPYING included with this
> + *  distribution); if not, write to the Free Software Foundation, Inc.,
> + *  59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
> + */
> +
> +#include "vl.h"
> +#include "block_int.h"
> +
> +//I took this from block-raw.c
> +#ifdef __sun__
> +#define _POSIX_PTHREAD_SEMANTICS 1
> +#include 
> +#include 
> +#endif
> +#ifdef __linux__
> +#include 
> +#include 
> +#include 
> +#endif
> +#ifdef __FreeBSD__
> +#include 
> +#endif
> +
> +#define DEBUG_MEM 0
> +
> +#ifdef DEBUG_MEM
> +#define DEBUG(fmt,a...) printf("D:%s:%d> " fmt "\n",__FILE__,__LINE__,##a)
> +#else
> +#define DEBUG(fmt,a...)
> +#endif
> +
> +typedef struct BDRVMemState {
> + void *memory;
> + int64_t length;
> +} BDRVMemState;
> +
> +static int mem_open(BlockDriverState *bs, const char *filename, int flags)
> +{
> + BDRVMemState *s = bs->opaque;
> +
> + bs->locked = 1;
> + bs->type   = BDRV_TYPE_HD;
> + //Try to parse the filename as a number of bytes.  add recognize M,K,G 
laterz.
> + s->length = strtol(filename+4,NULL,0);
> + DEBUG("mem_open:Raw Image size: %s -> %ld\n",filename,s->length);
> +
> + s->memory=qemu_mallocz(s->length);
> + if (! s->memory)
> + return -ENOMEM;
> + return 0;
> +}
> +
> +static void mem_close(BlockDriverState *bs) {
&g

Re: Tips for local testing guestfwd

[Felix Wu]

Hi all,

I am continuing debugging the ipv6 guestfwd feature, and I would like to
understand the behavior of slirp better.

Progress I've made:
Let QEMU take parameter like following:
guestfwd=tcp:[fec0::105]:54322-tcp:[::1]:6655
For slirp side, I basically searched for the appearance of gfwd_list and
made all code traverse the fwd list compatible with ipv6.
With these change, now I can see the packets coming out of the guest OS to
the assigned guest server port via tcpdump:
```
00:38:18.831831 IP6 fdb5:481:10ce:0:8c41:aaff:fea9:f674.52190 >
fec0::105.54322: tcp 0
0x:  600a 1f94 0028 0640 fdb5 0481 10ce   `(.@
0x0010:  8c41 aaff fea9 f674 fec0     .A.t
0x0020:     0105 cbde d432 df6d 8332  ...2.m.2
0x0030:    a0*02* fd20 535f  0204 05a0  S_..
0x0040:  0402 080a b87b fd3b   0103 0307  .{.;
```
02 == SYN so it looks good. But both tcpdump and wireshark (looking into
packet dump provided by QEMU invocation) didn't see any response and this
packet never reached the host.
I added multiple prints inside slirp and confirmed the ipv6 version of [1]
was reached.
in tcp_output function [2], I got following print:
qemu-system-aarch64: info: Slirp: AF_INET6 out dst ip =
fdb5:481:10ce:0:8c41:aaff:fea9:f674, port = 52190
qemu-system-aarch64: info: Slirp: AF_INET6 out src ip = fec0::105, port =
54322
It looks like there should be something being sent back to the guest,
unless my understanding of tcp_output is wrong.

To understand the datapath of guestfwd better, I have the following
questions:
1. What's the meaning of tcp_input and tcp_output? My guess is the
following graph, but I would like to confirm.
   tcp_input tcp_output
QEMU > slirp --> host
<   <--
 tcp_output   tcp_input

2. I don't see port 6655 in the above process. How does slirp know 6655 is
the port that needs to be visited on the host side?

Thanks in advance, Felix
[1].
https://gitlab.freedesktop.org/slirp/libslirp/-/blob/master/src/tcp_input.c#L630
[2].
https://gitlab.freedesktop.org/slirp/libslirp/-/blob/master/src/tcp_output.c#L477


On Mon, Jun 26, 2023 at 3:08 AM Samuel Thibault 
wrote:

> Hello,
>
> Felix Wu  wrote:
> > 2. I want to understand what ip I should use. Currently I have following
> > formats for the QEMU invocation in ipv6:
> > ```
> > guestfwd=tcp:[::1]:1234-tcp:[my:host:ip:from:ifconfig]:22
> > ```
> > I know the general form is `guestfwd=tcp:server:port-dev`, where
> > server:port is for guest,
>
> Yes, the address to be used within the guest network. So it needs to be
> within the guest network.
>
> > Is the aforementioned invocation correct?
>
> No, because ::1 isn't in the guest network.
>
> > Or in this case [::1] is the local host address and I should put qemu
> > address for it instead?
>
> You can use whatever IP you want, as long as it's in the guest network.
> e.g. [fec0::1234] if you're with the default fec0::/64 network.
>
> > 3. Is there a default ipv6 address for QEMU instance? I think I need it
> in
> > the invocation.
>
> By default it's address 2 within the prefix, i.e. fec0::2 with the
> default fec0::/64 network.
>
> Samuel
>

Re: udp guestfwd

[Felix Wu]

Hi Louai,

Are you using IPv6 or IPv4? The IPv4 is actually broken (if you want to
send multiple requests to slirp and get them forwarded).
You can check the latest comments in following tickets:
https://gitlab.freedesktop.org/slirp/libslirp/-/issues/67
https://gitlab.com/qemu-project/qemu/-/issues/1835

If you want to use IPv6, let me know and I can create pull requests in
libslirp so you can try it.

Thanks, Felix

On Fri, Dec 8, 2023 at 9:33 AM Patrick Venture  wrote:

>
> On Fri, Oct 27, 2023 at 11:44 PM Louai Al-Khanji 
> wrote:
>
>> Hi,
>>
>> I'm interested in having the guestfwd option work for udp. My
>> understanding is that currently it's restricted to only tcp.
>>
>> I'm not familiar with libslirp internals. What would need to be changed
>> to implement this? I'm potentially interested in doing the work.
>>
>> I did a tiny amount of digging around libslirp and saw this comment in
>> `udp.c':
>>
>> /*
>>  * X Here, check if it's in udpexec_list,
>>  * and if it is, do the fork_exec() etc.
>>  */
>>
>> I wonder whether that is related. In any case any help is much
>> appreciated.
>>
>
> Felix has been working in this space and it may take time to get the CLs
> landed in libslirp and qemu.
>
> Patrick
>
>>
>> Thanks,
>> Louai Al-Khanji
>>
>

Re: [Qemu-devel] [PATCH] gtk: Add show_tabs=on|off command line option.

[Felix Queißner]

Heya!


The patch adds "show_tabs" command line option for GTK ui similar to 
"grab_on_hover". This option allows tabbed view mode to not have to be enabled by hand at 
each start of the VM.


It's been a while now, but i was always missing this feature in QEMU and 
i'd love to see that patch land in QEMU one day.


I discovered that patch by searching for "start qemu with tabs visible" 
and found this link:


https://patchwork.ozlabs.org/project/qemu-devel/patch/56d0203f.5060...@gmail.com/

Regards
- Felix

Re: [Qemu-devel] [PATCH] gtk: Add show_tabs=on|off command line option.

[Felix Queißner]

Not sure why it was never picked up

That patch certainly needs a re-spin since it won't apply as-is anymore. 
Want to have a try?


I guess the semantics of the code stay the same, but the boilerplate 
might change a bit?


If so, i guess i can give it a try tomorrow and see if i can make it work.

- Felix

[PATCH 2/2] include/qom: Rename typename into type_name

[Felix Wu]

From: Roman Kiryanov 

`typename` is a C++ keyword and it prevents from
using the QEMU headers with a C++ compiler.

Google-Bug-Id: 331190993
Change-Id: Iff313ca5ec157a1a3826b4f5665073534d961a26
Signed-off-by: Felix Wu 
Signed-off-by: Roman Kiryanov 
---
 hw/core/bus.c  |   8 +--
 include/hw/qdev-core.h |   4 +-
 include/qom/object.h   |  78 +--
 qom/object.c   | 120 -
 4 files changed, 105 insertions(+), 105 deletions(-)

diff --git a/hw/core/bus.c b/hw/core/bus.c
index b9d89495cd..07c5a83673 100644
--- a/hw/core/bus.c
+++ b/hw/core/bus.c
@@ -152,18 +152,18 @@ static void bus_unparent(Object *obj)
 bus->parent = NULL;
 }
 
-void qbus_init(void *bus, size_t size, const char *typename,
+void qbus_init(void *bus, size_t size, const char *type_name,
DeviceState *parent, const char *name)
 {
-object_initialize(bus, size, typename);
+object_initialize(bus, size, type_name);
 qbus_init_internal(bus, parent, name);
 }
 
-BusState *qbus_new(const char *typename, DeviceState *parent, const char *name)
+BusState *qbus_new(const char *type_name, DeviceState *parent, const char 
*name)
 {
 BusState *bus;
 
-bus = BUS(object_new(typename));
+bus = BUS(object_new(type_name));
 qbus_init_internal(bus, parent, name);
 
 return bus;
diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
index 5336728a23..ede4b74bd8 100644
--- a/include/hw/qdev-core.h
+++ b/include/hw/qdev-core.h
@@ -867,9 +867,9 @@ DeviceState *qdev_find_recursive(BusState *bus, const char 
*id);
 typedef int (qbus_walkerfn)(BusState *bus, void *opaque);
 typedef int (qdev_walkerfn)(DeviceState *dev, void *opaque);
 
-void qbus_init(void *bus, size_t size, const char *typename,
+void qbus_init(void *bus, size_t size, const char *type_name,
DeviceState *parent, const char *name);
-BusState *qbus_new(const char *typename, DeviceState *parent, const char 
*name);
+BusState *qbus_new(const char *type_name, DeviceState *parent, const char 
*name);
 bool qbus_realize(BusState *bus, Error **errp);
 void qbus_unrealize(BusState *bus);
 
diff --git a/include/qom/object.h b/include/qom/object.h
index 7afdb261a8..4e69a3506d 100644
--- a/include/qom/object.h
+++ b/include/qom/object.h
@@ -617,7 +617,7 @@ Object *object_new_with_class(ObjectClass *klass);
 
 /**
  * object_new:
- * @typename: The name of the type of the object to instantiate.
+ * @type_name: The name of the type of the object to instantiate.
  *
  * This function will initialize a new object using heap allocated memory.
  * The returned object has a reference count of 1, and will be freed when
@@ -625,11 +625,11 @@ Object *object_new_with_class(ObjectClass *klass);
  *
  * Returns: The newly allocated and instantiated object.
  */
-Object *object_new(const char *typename);
+Object *object_new(const char *type_name);
 
 /**
  * object_new_with_props:
- * @typename:  The name of the type of the object to instantiate.
+ * @type_name:  The name of the type of the object to instantiate.
  * @parent: the parent object
  * @id: The unique ID of the object
  * @errp: pointer to error object
@@ -673,7 +673,7 @@ Object *object_new(const char *typename);
  *
  * Returns: The newly allocated, instantiated & initialized object.
  */
-Object *object_new_with_props(const char *typename,
+Object *object_new_with_props(const char *type_name,
   Object *parent,
   const char *id,
   Error **errp,
@@ -681,7 +681,7 @@ Object *object_new_with_props(const char *typename,
 
 /**
  * object_new_with_propv:
- * @typename:  The name of the type of the object to instantiate.
+ * @type_name:  The name of the type of the object to instantiate.
  * @parent: the parent object
  * @id: The unique ID of the object
  * @errp: pointer to error object
@@ -689,7 +689,7 @@ Object *object_new_with_props(const char *typename,
  *
  * See object_new_with_props() for documentation.
  */
-Object *object_new_with_propv(const char *typename,
+Object *object_new_with_propv(const char *type_name,
   Object *parent,
   const char *id,
   Error **errp,
@@ -755,13 +755,13 @@ bool object_set_propv(Object *obj, Error **errp, va_list 
vargs);
  * object_initialize:
  * @obj: A pointer to the memory to be used for the object.
  * @size: The maximum size available at @obj for the object.
- * @typename: The name of the type of the object to instantiate.
+ * @type_name: The name of the type of the object to instantiate.
  *
  * This function will initialize an object.  The memory for the object should
  * have already been allocated.  The returned object has a reference count of 
1,
  * and will be finalized when the last reference is dropped.
  */
-void object_initialize(void *obj, size_t size, const char *typename);
+void object_ini

[PATCH 1/2] qom: Rename Object::class into Object::klass

[Felix Wu]

From: Roman Kiryanov 

'class' is a C++ keyword and it prevents from
using the QEMU headers with a C++ compiler.

Google-Bug-Id: 331190993
Change-Id: I9ab7d2d77edef654a9c7b7cb9cd01795a6ed65a2
Signed-off-by: Felix Wu 
Signed-off-by: Roman Kiryanov 
---
 hw/core/qdev-properties-system.c |  2 +-
 include/exec/memory.h|  2 +-
 include/qom/object.h |  2 +-
 qom/object.c | 90 
 4 files changed, 48 insertions(+), 48 deletions(-)

diff --git a/hw/core/qdev-properties-system.c b/hw/core/qdev-properties-system.c
index f13350b4fb..a6781841af 100644
--- a/hw/core/qdev-properties-system.c
+++ b/hw/core/qdev-properties-system.c
@@ -431,7 +431,7 @@ static void set_netdev(Object *obj, Visitor *v, const char 
*name,
 }
 
 if (peers[i]->info->check_peer_type) {
-if (!peers[i]->info->check_peer_type(peers[i], obj->class, errp)) {
+if (!peers[i]->info->check_peer_type(peers[i], obj->klass, errp)) {
 goto out;
 }
 }
diff --git a/include/exec/memory.h b/include/exec/memory.h
index 2d7c278b9f..e5bd75956e 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -1808,7 +1808,7 @@ static inline IOMMUMemoryRegion 
*memory_region_get_iommu(MemoryRegion *mr)
 static inline IOMMUMemoryRegionClass *memory_region_get_iommu_class_nocheck(
 IOMMUMemoryRegion *iommu_mr)
 {
-return (IOMMUMemoryRegionClass *) (((Object *)iommu_mr)->class);
+return (IOMMUMemoryRegionClass *) (((Object *)iommu_mr)->klass);
 }
 
 #define memory_region_is_iommu(mr) (memory_region_get_iommu(mr) != NULL)
diff --git a/include/qom/object.h b/include/qom/object.h
index 13d3a655dd..7afdb261a8 100644
--- a/include/qom/object.h
+++ b/include/qom/object.h
@@ -153,7 +153,7 @@ struct ObjectClass
 struct Object
 {
 /* private: */
-ObjectClass *class;
+ObjectClass *klass;
 ObjectFree *free;
 GHashTable *properties;
 uint32_t ref;
diff --git a/qom/object.c b/qom/object.c
index 157a45c5f8..133cd08763 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -68,7 +68,7 @@ struct TypeImpl
 const char *parent;
 TypeImpl *parent_type;
 
-ObjectClass *class;
+ObjectClass *klass;
 
 int num_interfaces;
 InterfaceImpl interfaces[MAX_INTERFACES];
@@ -304,11 +304,11 @@ static void type_initialize_interface(TypeImpl *ti, 
TypeImpl *interface_type,
 type_initialize(iface_impl);
 g_free((char *)info.name);
 
-new_iface = (InterfaceClass *)iface_impl->class;
-new_iface->concrete_class = ti->class;
+new_iface = (InterfaceClass *)iface_impl->klass;
+new_iface->concrete_class = ti->klass;
 new_iface->interface_type = interface_type;
 
-ti->class->interfaces = g_slist_append(ti->class->interfaces, new_iface);
+ti->klass->interfaces = g_slist_append(ti->klass->interfaces, new_iface);
 }
 
 static void object_property_free(gpointer data)
@@ -329,7 +329,7 @@ static void type_initialize(TypeImpl *ti)
 {
 TypeImpl *parent;
 
-if (ti->class) {
+if (ti->klass) {
 return;
 }
 
@@ -350,7 +350,7 @@ static void type_initialize(TypeImpl *ti)
 assert(!ti->instance_finalize);
 assert(!ti->num_interfaces);
 }
-ti->class = g_malloc0(ti->class_size);
+ti->klass = g_malloc0(ti->class_size);
 
 parent = type_get_parent(ti);
 if (parent) {
@@ -360,10 +360,10 @@ static void type_initialize(TypeImpl *ti)
 
 g_assert(parent->class_size <= ti->class_size);
 g_assert(parent->instance_size <= ti->instance_size);
-memcpy(ti->class, parent->class, parent->class_size);
-ti->class->interfaces = NULL;
+memcpy(ti->klass, parent->klass, parent->class_size);
+ti->klass->interfaces = NULL;
 
-for (e = parent->class->interfaces; e; e = e->next) {
+for (e = parent->klass->interfaces; e; e = e->next) {
 InterfaceClass *iface = e->data;
 ObjectClass *klass = OBJECT_CLASS(iface);
 
@@ -377,7 +377,7 @@ static void type_initialize(TypeImpl *ti)
  ti->interfaces[i].typename, parent->name);
 abort();
 }
-for (e = ti->class->interfaces; e; e = e->next) {
+for (e = ti->klass->interfaces; e; e = e->next) {
 TypeImpl *target_type = OBJECT_CLASS(e->data)->type;
 
 if (type_is_ancestor(target_type, t)) {
@@ -393,20 +393,20 @@ static void type_initialize(TypeImpl *ti)
 }
 }
 
-ti->class->properties = g_hash_table_new_full(g_str_hash, g_str_equal, 
NULL,
+ti->klass->properties = g_hash_table_new_full(g_str_hash, g_str_equal, 
NULL,
   object_property_free);
 

[PATCH 1/1] include/qemu: Provide a C++ compatible version of typeof_strip_qual

[Felix Wu]

From: Roman Kiryanov 

to use the QEMU headers with a C++ compiler.

Signed-off-by: Felix Wu 
Signed-off-by: Roman Kiryanov 
---
 include/qemu/atomic.h   |  8 
 include/qemu/atomic.hpp | 38 ++
 2 files changed, 46 insertions(+)
 create mode 100644 include/qemu/atomic.hpp

diff --git a/include/qemu/atomic.h b/include/qemu/atomic.h
index 99110abefb..aeaecc440a 100644
--- a/include/qemu/atomic.h
+++ b/include/qemu/atomic.h
@@ -20,6 +20,13 @@
 /* Compiler barrier */
 #define barrier()   ({ asm volatile("" ::: "memory"); (void)0; })
 
+#ifdef __cplusplus
+
+#ifndef typeof_strip_qual
+#error Use the typeof_strip_qual(expr) definition from atomic.hpp on C++ 
builds.
+#endif
+
+#else  /* __cpluplus */
 /* The variable that receives the old value of an atomically-accessed
  * variable must be non-qualified, because atomic builtins return values
  * through a pointer-type argument as in __atomic_load(&var, &old, MODEL).
@@ -61,6 +68,7 @@
 __builtin_types_compatible_p(typeof(expr), const volatile unsigned 
short), \
 (unsigned short)1, 
\
   (expr)+0))
+#endif  /* __cpluplus */
 
 #ifndef __ATOMIC_RELAXED
 #error "Expecting C11 atomic ops"
diff --git a/include/qemu/atomic.hpp b/include/qemu/atomic.hpp
new file mode 100644
index 00..5844e3d427
--- /dev/null
+++ b/include/qemu/atomic.hpp
@@ -0,0 +1,38 @@
+/*
+ * The C++ definition for typeof_strip_qual used in atomic.h.
+ *
+ * Copyright (C) 2024 Google, Inc.
+ *
+ * Author: Roman Kiryanov 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ * See docs/devel/atomics.rst for discussion about the guarantees each
+ * atomic primitive is meant to provide.
+ */
+
+#ifndef QEMU_ATOMIC_HPP
+#define QEMU_ATOMIC_HPP
+
+#include 
+
+/* Match the integer promotion behavior of typeof_strip_qual, see atomic.h */
+template  struct typeof_strip_qual_cpp { using result = 
decltype(+T(0)); };
+
+template <> struct typeof_strip_qual_cpp { using result = bool; };
+template <> struct typeof_strip_qual_cpp { using result = signed 
char; };
+template <> struct typeof_strip_qual_cpp { using result = 
unsigned char; };
+template <> struct typeof_strip_qual_cpp { using result = signed 
short; };
+template <> struct typeof_strip_qual_cpp { using result = 
unsigned short; };
+
+#define typeof_strip_qual(expr) \
+typeof_strip_qual_cpp< \
+std::remove_cv< \
+std::remove_reference< \
+decltype(expr) \
+>::type \
+>::type \
+>::result
+
+#endif /* QEMU_ATOMIC_HPP */
-- 
2.45.2.741.gdbec12cfda-goog

Re: [PATCH] gtk: Add show_tabs=on|off command line option.

[Felix Queißner]

Heya!

On 27.06.22 18:44, Felix xq Queißner wrote:

The patch adds "show_tabs" command line option for GTK ui similar to 
"grab_on_hover". This option allows tabbed view mode to not have to be enabled by hand at 
each start of the VM.


On 30.06.22 16:09, Hanna Reitz wrote:
> [snip]

On 30.06.22 16:53, Markus Armbruster wrote:
> [snip]

On 01.07.22 12:00, Gerd Hoffmann wrote:
> [snip]

I have addressed the things mentioned:
- limiting line length to 80 in ui.json, qemu-options.hx
- limiting line length in commit to 72
- improved description of the option as Hanna suggested

On 01.07.22 11:14, Zhang, Chen wrote:
>> Signed-off-by: Felix "xq" Queißner 
>
> Thanks your patch, but please use your real name to sign a patch.

Not sure what to do about this one. Felix Queißer *is* my real name, so 
the only thing i could do is to remove the "xq"?


Should i submit my changes as a response to this or create a new mail 
thread with a new patch?


Regards
- Felix

Re: Tips for local testing guestfwd

[Felix Wu]

Hi Samuel,

Thanks for the clarification! I missed the email so didn't reply in time,
but was able to figure it out.

Hi everyone,
IPv6 guestfwd works in my local test but it has a weird bug: if you send
two requests, the first one gets the correct response, but the second one
gets stuck.
I am using a simple http server for this test, and just noticed this bug
also exists in IPv4 guestfwd. I've documented it in
https://gitlab.com/qemu-project/qemu/-/issues/1835.

Just want to check if anyone has seen the same issue before.

Thanks! Felix

On Thu, Jul 20, 2023 at 7:54 AM Samuel Thibault 
wrote:

> Hello,
>
> Felix Wu, le mar. 18 juil. 2023 18:12:16 -0700, a ecrit:
> > 02 == SYN so it looks good. But both tcpdump and wireshark (looking into
> packet
> > dump provided by QEMU invocation)
>
> Which packet dump?
>
> > I added multiple prints inside slirp and confirmed the ipv6 version of
> [1] was
> > reached.
> > in tcp_output function [2], I got following print:
> > qemu-system-aarch64: info: Slirp: AF_INET6 out dst ip =
> > fdb5:481:10ce:0:8c41:aaff:fea9:f674, port = 52190
> > qemu-system-aarch64: info: Slirp: AF_INET6 out src ip = fec0::105, port
> = 54322
> > It looks like there should be something being sent back to the guest,
>
> That's what it is.
>
> > unless my understanding of tcp_output is wrong.
>
> It looks so.
>
> > To understand the datapath of guestfwd better, I have the following
> questions:
> > 1. What's the meaning of tcp_input and tcp_output? My guess is the
> following
> > graph, but I would like to confirm.
>
> No, tcp_input is for packets that come from the guest, and tcp_output is
> for packets that are send to the guest. So it's like that:
>
> > tcp_inputwrite_cb  host send()
> > QEMU > slirp ---> QEMU > host
> > <<- <-
> >  tcp_output  slirp_socket_recvhost recv()
>
> > 2. I don't see port 6655 in the above process. How does slirp know 6655
> is the
> > port that needs to be visited on the host side?
>
> Slirp itself *doesn't* know that port. The guestfwd piece just calls the
> SlirpWriteCb when it has data coming from the guest. See the
> documentation:
>
> /* Set up port forwarding between a port in the guest network and a
>  * callback that will receive the data coming from the port */
> SLIRP_EXPORT
> int slirp_add_guestfwd(Slirp *slirp, SlirpWriteCb write_cb, void *opaque,
>struct in_addr *guest_addr, int guest_port);
>
> and
>
> /* This is called by the application for a guestfwd, to provide the data
> to be
>  * sent on the forwarded port */
> SLIRP_EXPORT
> void slirp_socket_recv(Slirp *slirp, struct in_addr guest_addr, int
> guest_port,
>const uint8_t *buf, int size);
>
> Samuel
>

Re: Tips for local testing guestfwd

[Felix Wu]

Update on debugging this thing (already updated
https://gitlab.com/qemu-project/qemu/-/issues/1835):
I saw that `tcp_chr_free_connection` was called after the first response
being successfully sent:
```

slirp_guestfwd_write guestfwd_write: size 80tcp_chr_write
tcp_chr_write: s->state:2tcp_chr_write tcp_chr_write:
len:80qemu_chr_write_parameter len: 80 // tracking
qemu_chr_writeqemu_chr_write_res len: 80 // same
thingtcp_chr_free_connection tcp_chr_free_connection: state: 2,
changing it to disconnecttcp_chr_change_state tcp_chr_change_state:
state: 2, next state: 0 // state 2==connected, 0==disconnected.

```
And after that, the state of `SocketChardev` remained disconnected, and
when the 2nd request came in, the `tcp_chr_write` dropped it directly.
Maybe this state machine should be reset after every connection? Not sure.

On Thu, Aug 17, 2023 at 11:58 AM Felix Wu  wrote:

> Hi Samuel,
>
> Thanks for the clarification! I missed the email so didn't reply in time,
> but was able to figure it out.
>
> Hi everyone,
> IPv6 guestfwd works in my local test but it has a weird bug: if you send
> two requests, the first one gets the correct response, but the second one
> gets stuck.
> I am using a simple http server for this test, and just noticed this bug
> also exists in IPv4 guestfwd. I've documented it in
> https://gitlab.com/qemu-project/qemu/-/issues/1835.
>
> Just want to check if anyone has seen the same issue before.
>
> Thanks! Felix
>
> On Thu, Jul 20, 2023 at 7:54 AM Samuel Thibault 
> wrote:
>
>> Hello,
>>
>> Felix Wu, le mar. 18 juil. 2023 18:12:16 -0700, a ecrit:
>> > 02 == SYN so it looks good. But both tcpdump and wireshark (looking
>> into packet
>> > dump provided by QEMU invocation)
>>
>> Which packet dump?
>>
>> > I added multiple prints inside slirp and confirmed the ipv6 version of
>> [1] was
>> > reached.
>> > in tcp_output function [2], I got following print:
>> > qemu-system-aarch64: info: Slirp: AF_INET6 out dst ip =
>> > fdb5:481:10ce:0:8c41:aaff:fea9:f674, port = 52190
>> > qemu-system-aarch64: info: Slirp: AF_INET6 out src ip = fec0::105, port
>> = 54322
>> > It looks like there should be something being sent back to the guest,
>>
>> That's what it is.
>>
>> > unless my understanding of tcp_output is wrong.
>>
>> It looks so.
>>
>> > To understand the datapath of guestfwd better, I have the following
>> questions:
>> > 1. What's the meaning of tcp_input and tcp_output? My guess is the
>> following
>> > graph, but I would like to confirm.
>>
>> No, tcp_input is for packets that come from the guest, and tcp_output is
>> for packets that are send to the guest. So it's like that:
>>
>> > tcp_inputwrite_cb  host send()
>> > QEMU > slirp ---> QEMU > host
>> > <<- <-
>> >  tcp_output  slirp_socket_recvhost recv()
>>
>> > 2. I don't see port 6655 in the above process. How does slirp know 6655
>> is the
>> > port that needs to be visited on the host side?
>>
>> Slirp itself *doesn't* know that port. The guestfwd piece just calls the
>> SlirpWriteCb when it has data coming from the guest. See the
>> documentation:
>>
>> /* Set up port forwarding between a port in the guest network and a
>>  * callback that will receive the data coming from the port */
>> SLIRP_EXPORT
>> int slirp_add_guestfwd(Slirp *slirp, SlirpWriteCb write_cb, void *opaque,
>>struct in_addr *guest_addr, int guest_port);
>>
>> and
>>
>> /* This is called by the application for a guestfwd, to provide the data
>> to be
>>  * sent on the forwarded port */
>> SLIRP_EXPORT
>> void slirp_socket_recv(Slirp *slirp, struct in_addr guest_addr, int
>> guest_port,
>>const uint8_t *buf, int size);
>>
>> Samuel
>>
>

Tips for local testing guestfwd

[Felix Wu]

Hi all,

TL,DR: I am working on QEMU ipv6 guestfwd feature and finished coding, and
would like to learn the best practice to test it.
Context: in slirp side this task is tracking by [1].
Currently, I have done following:
i. made char parse + guestfwd functions happy with ipv6 address.
ii. enabled debug print and made sure the ip and port are inserted into the
forward list in libslirp.
To sufficiently verify it's working, I do have three questions:
1. I want to forward a port in the guest (OS in QEMU) to a port 22 on the
host OS, and ssh from guest back to host,
does this sound reasonable? If this is not a good idea, what method is
recommended?
2. I want to understand what ip I should use. Currently I have following
formats for the QEMU invocation in ipv6:
```
guestfwd=tcp:[::1]:1234-tcp:[my:host:ip:from:ifconfig]:22
```
I know the general form is `guestfwd=tcp:server:port-dev`, where
server:port is for guest, dev is for host.
Adding [] in my implementation will let QEMU know it's ipv6.
Is the aforementioned invocation correct? Or in this case [::1] is the
local host address and I should put qemu address
for it instead?
3. Is there a default ipv6 address for QEMU instance? I think I need it in
the invocation.

Thanks in advance! Felix

[1]. https://gitlab.freedesktop.org/slirp/libslirp/-/issues/67

Re: Tips for local testing guestfwd

[Felix Wu]

Hi,
I noticed why the chardev socket backend disconnects, and I would like to
make this a RFC to see how I should fix it.
Current scenario after boot-up:

   1. tcp_chr_read_poll keeps polling the slirp_socket_can_recv, and
   slirp_socket_can_recv returns 0 since slirp_find_ctl_socket couldn't
   find the guestfwd socket.
   2. The returned 0 in step 1 was assigned to the s->max_size (s is
SocketChardev
   *), and the socket chardev handler won't read since readable size is 0.
   3. When the 1st request is sent, the guestfwd socket is added into the
   slirp's socket list, instead of 0, tcp_chr_read_poll will return the
   result of sopreprbuf > 0.
   4. tcp_chr_read reads the thing.
   5. tcp_chr_read_poll still returns things > 0, which is the output of
   sopreprbuf.
   6. tcp_chr_read reads the thing again, but there's nothing in the
   buffer, so it's unhappy, and closes the connection.
   7. any follow-up requests won't be handled.

These tcp_chr* functions are in fle [1], and slirp_* are in fle [2].

My questions:
1. Since this thing doesn't work on 2nd and later requests, I want to know
how this thing is supposed to work, and to avoid asking people vaguely, I
will provide my though following and please correct me if I am wrong:
a. The state machine in chardev socket should maintain a connected
state (s->state
== TCP_CHARDEV_STATE_CONNECTED), this means no change in [1].
b. slirp_socket_can_recv should return 0 once all data is read instead of
outcome from sopreprbuf. This means I need to remove the socket or change
its state to no file descriptor [3], namely somehow reset it.
c. When a new request comes in, it will need to add the socket back to this
slirp instance's socket list, populate its file descriptor, and establish
the connection.

b and c sounds convoluted so I want to check.

2. What is the outcome of sopreprbuf function [3]?
Since it's returned to the tcp_chr_read_poll function, I thought it's the
readable bytes in the socket, but in my test I noticed following thing:

tcp_chr_read_poll_size : s->max_size: 132480
tcp_chr_read : size: 2076
tcp_chr_read_poll_size : s->max_size: 129600
tcp_chr_read : size: 0

Even there's not remaining things in the buffer (read size 0), it's still
non-zero, and thus the read function keeps reading it until it becomes
unhappy.
Also, 132480-129600 = 2880 vs 2076, the read byte doesn't match.

Either I need to go with the way in question 1, b.c. steps, or I don't need
to delete the socket, but the sopreprbuf wasn't proper to be used there and
I need to correct it.
Also updated https://gitlab.com/qemu-project/qemu/-/issues/1835.

Any feedback will be appreciated, thanks!
Felix

[1].
https://gitlab.com/qemu-project/qemu/-/blob/master/chardev/char-socket.c#L141
[2].
https://gitlab.freedesktop.org/slirp/libslirp/-/blob/master/src/slirp.c#L1582
[3].
https://gitlab.freedesktop.org/slirp/libslirp/-/blob/master/src/socket.h#L221

On Wed, Aug 23, 2023 at 10:27 AM Felix Wu  wrote:

> Update on debugging this thing (already updated
> https://gitlab.com/qemu-project/qemu/-/issues/1835):
> I saw that `tcp_chr_free_connection` was called after the first response
> being successfully sent:
> ```
>
> slirp_guestfwd_write guestfwd_write: size 80tcp_chr_write tcp_chr_write: 
> s->state:2tcp_chr_write tcp_chr_write: len:80qemu_chr_write_parameter len: 80 
> // tracking qemu_chr_writeqemu_chr_write_res len: 80 // same 
> thingtcp_chr_free_connection tcp_chr_free_connection: state: 2, changing it 
> to disconnecttcp_chr_change_state tcp_chr_change_state: state: 2, next state: 
> 0 // state 2==connected, 0==disconnected.
>
> ```
> And after that, the state of `SocketChardev` remained disconnected, and
> when the 2nd request came in, the `tcp_chr_write` dropped it directly.
> Maybe this state machine should be reset after every connection? Not sure.
>
> On Thu, Aug 17, 2023 at 11:58 AM Felix Wu  wrote:
>
>> Hi Samuel,
>>
>> Thanks for the clarification! I missed the email so didn't reply in time,
>> but was able to figure it out.
>>
>> Hi everyone,
>> IPv6 guestfwd works in my local test but it has a weird bug: if you send
>> two requests, the first one gets the correct response, but the second one
>> gets stuck.
>> I am using a simple http server for this test, and just noticed this bug
>> also exists in IPv4 guestfwd. I've documented it in
>> https://gitlab.com/qemu-project/qemu/-/issues/1835.
>>
>> Just want to check if anyone has seen the same issue before.
>>
>> Thanks! Felix
>>
>> On Thu, Jul 20, 2023 at 7:54 AM Samuel Thibault 
>> wrote:
>>
>>> Hello,
>>>
>>> Felix Wu, le mar. 18 juil. 2023 18:12:16 -0700, a ecrit:
>>> > 02 == SYN so it looks good. B

[PATCH 1/1] SMBIOS type 8 should use T8_BASE.

[Felix Wu]

---
 hw/smbios/smbios.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
index 2a90601ac5..7dda84b284 100644
--- a/hw/smbios/smbios.c
+++ b/hw/smbios/smbios.c
@@ -591,6 +591,7 @@ bool smbios_skip_table(uint8_t type, bool required_table)
 #define T2_BASE 0x200
 #define T3_BASE 0x300
 #define T4_BASE 0x400
+#define T8_BASE 0x800
 #define T11_BASE 0xe00
 
 #define T16_BASE 0x1000
@@ -775,7 +776,7 @@ static void smbios_build_type_8_table(void)
 struct type8_instance *t8;
 
 QTAILQ_FOREACH(t8, &type8, next) {
-SMBIOS_BUILD_TABLE_PRE(8, T0_BASE + instance, true);
+SMBIOS_BUILD_TABLE_PRE(8, T8_BASE + instance, true);
 
 SMBIOS_TABLE_SET_STR(8, internal_reference_str, 
t8->internal_reference);
 SMBIOS_TABLE_SET_STR(8, external_reference_str, 
t8->external_reference);
-- 
2.43.0.275.g3460e3d667-goog

[PATCH 0/1] smbios_build_type_8_table should use T8_BASE.

[Felix Wu]

It should use T8_BASE instead of T0_BASE.

Felix Wu (1):
  SMBIOS type 8 should use T8_BASE.

 hw/smbios/smbios.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

-- 
2.43.0.275.g3460e3d667-goog

[Qemu-devel] [PATCH] linux-user: fix mremap for 64bit targets on 32bit hosts

[Felix Janda]

Signed-off-by: Felix Janda 
---
 linux-user/mmap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/linux-user/mmap.c b/linux-user/mmap.c
index c4371d9..4882816 100644
--- a/linux-user/mmap.c
+++ b/linux-user/mmap.c
@@ -682,7 +682,7 @@ abi_long target_mremap(abi_ulong old_addr, abi_ulong 
old_size,
 
 if (flags & MREMAP_FIXED) {
 host_addr = (void *) syscall(__NR_mremap, g2h(old_addr),
- old_size, new_size,
+ (size_t) old_size, (size_t) new_size,
  flags,
  g2h(new_addr));
 
@@ -701,7 +701,7 @@ abi_long target_mremap(abi_ulong old_addr, abi_ulong 
old_size,
 host_addr = MAP_FAILED;
 } else {
 host_addr = (void *) syscall(__NR_mremap, g2h(old_addr),
- old_size, new_size,
+ (size_t) old_size, (size_t) new_size,
  flags | MREMAP_FIXED,
  g2h(mmap_start));
 if (reserved_va) {
-- 
2.7.3

[Qemu-devel] [PATCH] linux-user: use libc wrapper instead of direct mremap syscall

[Felix Janda]

This commit essentially reverts commit
3af72a4d98dca033492102603734cbc63cd2694a, which has replaced
five-argument calls to mremap() by direct mremap syscalls for
compatibility with glibc older than version 2.4.

The direct syscall was buggy for 64bit targets on 32bit hosts
because of the default integer type promotions. Since glibc-2.4
is now a decade old, we can remove this workaround.

Signed-off-by: Felix Janda 
---
 linux-user/mmap.c | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/linux-user/mmap.c b/linux-user/mmap.c
index c4371d9..ffd099d 100644
--- a/linux-user/mmap.c
+++ b/linux-user/mmap.c
@@ -17,8 +17,6 @@
  *  along with this program; if not, see <http://www.gnu.org/licenses/>.
  */
 #include "qemu/osdep.h"
-#include 
-#include 
 
 #include "qemu.h"
 #include "qemu-common.h"
@@ -681,10 +679,8 @@ abi_long target_mremap(abi_ulong old_addr, abi_ulong 
old_size,
 mmap_lock();
 
 if (flags & MREMAP_FIXED) {
-host_addr = (void *) syscall(__NR_mremap, g2h(old_addr),
- old_size, new_size,
- flags,
- g2h(new_addr));
+host_addr = mremap(g2h(old_addr), old_size, new_size,
+   flags, g2h(new_addr));
 
 if (reserved_va && host_addr != MAP_FAILED) {
 /* If new and old addresses overlap then the above mremap will
@@ -700,10 +696,8 @@ abi_long target_mremap(abi_ulong old_addr, abi_ulong 
old_size,
 errno = ENOMEM;
 host_addr = MAP_FAILED;
 } else {
-host_addr = (void *) syscall(__NR_mremap, g2h(old_addr),
- old_size, new_size,
- flags | MREMAP_FIXED,
- g2h(mmap_start));
+host_addr = mremap(g2h(old_addr), old_size, new_size,
+   flags | MREMAP_FIXED, g2h(mmap_start));
 if (reserved_va) {
 mmap_reserve(old_addr, old_size);
 }
-- 
2.7.3

[Qemu-devel] [PATCH] linux-user: include for F_EXLCK and F_SHLCK

[Felix Janda]

The F_EXLCK and F_SHLCK fcntl lock constants are obsolete synonyms for
F_WRLCK and F_RDLCK. Include  to fix compilation with
the musl c library, which does not expose these constants.

Signed-off-by: Felix Janda 
---
 linux-user/syscall.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 0815f30..3d1f694 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -107,6 +107,7 @@ int __clone2(int (*fn)(void *), void *child_stack_base,
 #include 
 #endif
 #include 
+#include 
 #include "linux_loop.h"
 #include "uname.h"
 
-- 
2.7.3

[Qemu-devel] [PATCH RFC] linux-user: peform __SIGRTMIN hack only when __SIGRTMIN is defined

[Felix Janda]

This fixes a compilation error with the musl c library.
---
I don't really understand the purpose of the hack, which was
introduced in

http://git.qemu.org/?p=qemu.git;a=commit;h=624f7979058b84cbf81c76d45f302ce757b213ca

but musl does not have a separate thread library (it is included in
libc.so), so I doubt that the hack is applies to it.
---
 linux-user/signal.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/linux-user/signal.c b/linux-user/signal.c
index c750053..c89f83d 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -73,12 +73,14 @@ static uint8_t host_to_target_signal_table[_NSIG] = {
 [SIGPWR] = TARGET_SIGPWR,
 [SIGSYS] = TARGET_SIGSYS,
 /* next signals stay the same */
+#ifdef __SIGRTMIN
 /* Nasty hack: Reverse SIGRTMIN and SIGRTMAX to avoid overlap with
host libpthread signals.  This assumes no one actually uses SIGRTMAX :-/
To fix this properly we need to do manual signal delivery multiplexed
over a single host signal.  */
 [__SIGRTMIN] = __SIGRTMAX,
 [__SIGRTMAX] = __SIGRTMIN,
+#endif
 };
 static uint8_t target_to_host_signal_table[_NSIG];
 
-- 
2.7.3

[Qemu-devel] [PATCH] linux-user: include instead of

[Felix Janda]

This removes the last usage of  in the code base.

Signed-off-by: Felix Janda 
---
 linux-user/syscall.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 3d1f694..4bfb671 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -42,7 +42,7 @@ int __clone2(int (*fn)(void *), void *child_stack_base,
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
-- 
2.7.3

Re: [Qemu-devel] [PATCH] linux-user: include for F_EXLCK and F_SHLCK

[Felix Janda]

Peter Maydell wrote:
> On 30 September 2016 at 16:39, Felix Janda  wrote:
> > The F_EXLCK and F_SHLCK fcntl lock constants are obsolete synonyms for
> > F_WRLCK and F_RDLCK.
> 
> This seems unlikely, since on for instance Alpha F_EXLCK is
> 16, F_SHLCK is 32, F_RDLCK is 1 and F_WRLCK is 2, so they're
> all distinct:
> http://lxr.free-electrons.com/source/arch/alpha/include/uapi/asm/fcntl.h#L52

Except for headers, the only use of F_EXLCK in the kernel is in
fs/cifs/file.c, where it has the same effect as F_WRLCK (except
for a debug message). Similarly for F_SHLCK and F_RDLCK.

Thanks,
Felix

Re: [Qemu-devel] [PATCH RFC] linux-user: peform __SIGRTMIN hack only when __SIGRTMIN is defined

[Felix Janda]

Peter Maydell wrote:
> On 30 September 2016 at 16:41, Felix Janda  wrote:
> > This fixes a compilation error with the musl c library.
> > ---
> > I don't really understand the purpose of the hack, which was
> > introduced in
> >
> > http://git.qemu.org/?p=qemu.git;a=commit;h=624f7979058b84cbf81c76d45f302ce757b213ca
> >
> > but musl does not have a separate thread library (it is included in
> > libc.so), so I doubt that the hack is applies to it.
> 
> The reason for the hack is that glibc uses SIGRTMAX (ie signal 63)
> for its own internal purposes (it uses it for between-thread
> communication to implement the posix threading APIs). If we
> didn't reverse SIGRTMIN and SIGRTMAX then both the glibc in
> the host process and the glibc in the guest process would try
> to use the same signal and the guest's threading APIs would
> break.

Thanks for explaining this.

> I'm pretty sure musl is going to need to use a signal to
> implement threads too, so I expect this hack will be
> needed there too, not just on glibc.

musl uses signal 34 (internally called SIGSYNCCALL) to implement
threads.

> It would be better to figure out how to identify the
> range of RT signals on musl...

musl has SIGRTMIN and SIGRTMAX, but these resolve to functions
__libc_current_sigrtmin() and __libc_current_sigrtmax(). The first
always returns 35, the second _NSIG-1.

But how do these matter? Isn't it only important that signal 34 gets
remapped?

Felix

Re: [Qemu-devel] [PATCH] linux-user: include for F_EXLCK and F_SHLCK

[Felix Janda]

Peter Maydell wrote:
> On 30 September 2016 at 16:39, Felix Janda  wrote:
> > The F_EXLCK and F_SHLCK fcntl lock constants are obsolete synonyms for
> > F_WRLCK and F_RDLCK.
> 
> This seems unlikely, since on for instance Alpha F_EXLCK is
> 16, F_SHLCK is 32, F_RDLCK is 1 and F_WRLCK is 2, so they're
> all distinct:
> http://lxr.free-electrons.com/source/arch/alpha/include/uapi/asm/fcntl.h#L52

I've now looked at linux-1.0, linux-2.0 and linux-2.4. In all of them,
the constants are used in fs/locks.c. In linux-1.0, F_SHLCK has almost
the same effect as F_RDLCK, except that F_SHLCK accepts also files with
write but without read permission. Similarly for F_EXLCK. In linux-2.0
when F_EXLCK or F_SHLCK are used, the flag F_BROKEN gets set. Finally,
in linux-2.4 they just lead to EINVAL.

So I guess that the commit message should more accurately say that the
constants were used in the past for a broken flock implementation.

With this closer look at the history of these constants, it is also not
clear to me whether qemu should care at all about translating them.

Felix

Re: [Qemu-devel] Fix build break during configuration on musl-libc based system

[Felix Janda]

Defining _GNU_SOURCE causes musl to define everything including
everything protected by _XOPEN_SOURCE. However it does not cause
musl to define _XOPEN_SOURCE.

On the other hand, the ncurses header specifically checks for
_XOPEN_SOURCE or _XOPEN_SOURCE_EXTENDED.

So it is not completely clear where this should be fixed.

-- Felix

Re: [Qemu-devel] [PATCH 1/1] main loop: remove useless code

[felix yao]

Hi Peter Maydell:

Got it, thank you very much!

2017-12-02 19:52 GMT+08:00 Peter Maydell :

> On 2 December 2017 at 07:41, FelixYao  wrote:
> > hi Paolo Bonzini:
> >
> > Those codes seem useless, Could it be removed?
> >
> > Signed-off-by: FelixYao 
> > ---
> >  vl.c | 4 
> >  1 file changed, 4 deletions(-)
> >
> > diff --git a/vl.c b/vl.c
> > index 1ad1c04..5bed4c2 100644
> > --- a/vl.c
> > +++ b/vl.c
> > @@ -2995,10 +2995,6 @@ static void set_memory_options(uint64_t
> *ram_slots, ram_addr_t *maxram_size,
> >
> >  sz = QEMU_ALIGN_UP(sz, 8192);
> >  ram_size = sz;
> > -if (ram_size != sz) {
> > -error_report("ram size too large");
> > -exit(EXIT_FAILURE);
> > -}
>
> ram_size is a ramaddr_t, which may be a 32-bit variable, whereas
> sz is a uint64_t. This check is making sure that the ram size
> specified can actually fit in a ramaddr_t.
>
> thanks
> -- PMM
>

Re: [Qemu-devel] [PATCH 1/1] util/thread-pool: add parameter to limit maximum threads in thread pool

[felix yao]

Hi stefan:
Thank you very much for your reply. Yes, I want to reduce impact of
resources among virtual machines including I/O resources, vCPU and etc. I
can use CPU pin feature to pin vCPU to dedicated host's physical CPU and
use I/O throttling feature to limit IOPS and bandwidth of VM's disks. But,
When using aio=threads, I/O worker threads are too many(if we have 16 VMs
in one host, there are 1024 threads at worst) and  can't pinned to
dedicated CPU(dynamic creating). The I/O worker threads seem out of
control. I/O worker threads of one VM's disk may impact the running of
other VM. I am not sure how much of the impact.
You have mentioned aio=native in the mail. Yes, When Using -drive
aio=native, there is no such problem and performance is better. I am
thinking to use it. But, I found a issue report about using Linux AIO on
QEMU, issue link:
https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/libvirt-aio-mode.html
. http://paste.openstack.org/show/480498/. Do you know about this issue?
Could Linux AIO be safely used in QEMU?
I have  noticed that there is IOthread feature in QEMU(dedicated thread
to handle disk I/O instead of main thread) recently. I can use 'iothreadpin
iothread=xx cpuset=xxx ' in libvirt XML to pin iothreads of one VM to
dedicated host's physical CPU. Worker threads of the VM are also pinned to
that host's physical CPU. This can also solve my problem.




Stefan Hajnoczi  于2018年7月27日周五 下午8:41写道：

> On Fri, Jul 13, 2018 at 03:48:27PM +0800, FelixYao wrote:
> > Hi all:
> >
> > Max threads in thread pool is fixed at 64 before which is not
> > propriate in some situations. For public cloud environment,
> > there are lots of VMs in one host machine. We should limit the worker
> thread
> > numbers for each machine alone based on its ability to prevent impacting
> > each other. Although we can use iotune to limit bandwidth or IOPS of
> block
> > device. That is not enough. Lots of worker threads still impact other
> VMs.
> > I think the ability to limit maximum threads in thread pool is necessary.
> >
> > What's your opinion about this patch? please review it.
>
> I haven't seen any discussion so here are some thoughts:
>
> It sounds like you are trying to control I/O resources so that guests do
> not affect each other.  The threads are an implementation detail and not
> the root of the problem.
>
> For example, if you use -drive aio=native then reads and writes will not
> use the thread pool and you will setting the thread pool size won't
> solve the problem.
>
> Have you tried QEMU's I/O throttling feature?  You can set bandwidth
> (bps) and IOPS limits, including bursts if you wish to allow temporary
> spikes.  The basic parameters are -drive bps=BYTES_PER_SECOND,iops=IOPS.
> See the QEMU or libvirt documentation for details.
>

Re: [Qemu-devel] [PATCH] linux-user: fix mremap for 64bit targets on 32bit hosts

[Felix Janda]

Riku Voipio wrote:
> Hi,
> 
> On Sat, Sep 17, 2016 at 09:20:14PM -0400, Felix Janda wrote:
> > Signed-off-by: Felix Janda 
> 
> Have you run the mremap tests of ltp with this on your host/guest
> combo? 

I have just run the tests. My host is arm and my guest is aarch64.
Without the patch all but mremap02 fail. With the patch all but
mremap04 pass. The mremap04 test indicates that shmat is broken.

> > ---
> >  linux-user/mmap.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/linux-user/mmap.c b/linux-user/mmap.c
> > index c4371d9..4882816 100644
> > --- a/linux-user/mmap.c
> > +++ b/linux-user/mmap.c
> > @@ -682,7 +682,7 @@ abi_long target_mremap(abi_ulong old_addr, abi_ulong 
> > old_size,
> >  
> >  if (flags & MREMAP_FIXED) {
> >  host_addr = (void *) syscall(__NR_mremap, g2h(old_addr),
> > - old_size, new_size,
> > + (size_t) old_size, (size_t) new_size,
> >   flags,
> >   g2h(new_addr));
> >  
> > @@ -701,7 +701,7 @@ abi_long target_mremap(abi_ulong old_addr, abi_ulong 
> > old_size,
> >  host_addr = MAP_FAILED;
> >  } else {
> >  host_addr = (void *) syscall(__NR_mremap, g2h(old_addr),
> > - old_size, new_size,
> > + (size_t) old_size, (size_t) 
> > new_size,
> >   flags | MREMAP_FIXED,
> >   g2h(mmap_start));
> >  if (reserved_va) {
> > -- 
> > 2.7.3
> > 

Re: [Qemu-devel] [PATCH] linux-user: fix mremap for 64bit targets on 32bit hosts

[Felix Janda]

Peter Maydell wrote:
> On 17 September 2016 at 18:20, Felix Janda  wrote:
> > Signed-off-by: Felix Janda 
> > ---
> >  linux-user/mmap.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/linux-user/mmap.c b/linux-user/mmap.c
> > index c4371d9..4882816 100644
> > --- a/linux-user/mmap.c
> > +++ b/linux-user/mmap.c
> > @@ -682,7 +682,7 @@ abi_long target_mremap(abi_ulong old_addr, abi_ulong 
> > old_size,
> >
> >  if (flags & MREMAP_FIXED) {
> >  host_addr = (void *) syscall(__NR_mremap, g2h(old_addr),
> > - old_size, new_size,
> > + (size_t) old_size, (size_t) new_size,
> >   flags,
> >   g2h(new_addr));
> >
> > @@ -701,7 +701,7 @@ abi_long target_mremap(abi_ulong old_addr, abi_ulong 
> > old_size,
> >  host_addr = MAP_FAILED;
> >  } else {
> >  host_addr = (void *) syscall(__NR_mremap, g2h(old_addr),
> > - old_size, new_size,
> > + (size_t) old_size, (size_t) 
> > new_size,
> >   flags | MREMAP_FIXED,
> >   g2h(mmap_start));
> >  if (reserved_va) {
> > --
> > 2.7.3
> 
> Rather than this, I think it would be better to switch to
> using the mremap() library call rather than direct syscall
> here, which then matches the other mremap()s later in the
> function. (That will work right because mremap()'s prototype
> says it takes size_t arguments, whereas syscall() is a
> generic thing which doesn't, and so the C default promotions
> do the wrong thing with the abi_ulongs.)
> 
> The use of syscall(__NR_mremap, ...) originally dates back to 2008:
> https://lists.gnu.org/archive/html/qemu-devel/2008-12/msg01087.html
> https://lists.gnu.org/archive/html/qemu-devel/2008-12/msg00480.html
> 
> and was to permit compilation with glibc 2.4 which didn't
> support the 5-argument mremap() or define MREMAP_FIXED.
> 
> Since glibc 2.4 dates back to a decade ago now, we no longer
> need to carry this ugly (and buggy) workaround for it.

This sounds like a good idea. Thanks also for digging up the history.

I will prepare a new patch.

Thanks,
Felix

[Qemu-devel] [Bug 1347555] [NEW] qemu build failure, hxtool is a bash script, not a /bin/sh script

[Felix von Leitner]

Public bug reported:

hxtool (part of the early build process) is a bash script.  Running it
with /bin/sh yields a syntax error on line 10:

 10 STEXI*|ETEXI*|SQMP*|EQMP*) flag=$(($flag^1))

$(( expr )) is a bash extension, not part of /bin/sh.

Note that replacing the sh in the first line in hxtool with /bin/bash
does not help, because the script is run manually from the Makefile with
sh:

154 $(call quiet-command,sh $(SRC_PATH)/scripts/hxtool -h < $< >
$@,"  GEN   $@")

The fix is to change those lines to

154 $(call quiet-command,bash $(SRC_PATH)/scripts/hxtool -h < $<
> $@,"  GEN   $@")

(there are five or so).

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  qemu build failure, hxtool is a bash script, not a /bin/sh script

Status in QEMU:
  New

Bug description:
  hxtool (part of the early build process) is a bash script.  Running it
  with /bin/sh yields a syntax error on line 10:

   10 STEXI*|ETEXI*|SQMP*|EQMP*) flag=$(($flag^1))

  $(( expr )) is a bash extension, not part of /bin/sh.

  Note that replacing the sh in the first line in hxtool with /bin/bash
  does not help, because the script is run manually from the Makefile
  with sh:

  154 $(call quiet-command,sh $(SRC_PATH)/scripts/hxtool -h < $<
  > $@,"  GEN   $@")

  The fix is to change those lines to

  154 $(call quiet-command,bash $(SRC_PATH)/scripts/hxtool -h <
  $< > $@,"  GEN   $@")

  (there are five or so).

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

[Qemu-devel] [Bug 1347555] Re: qemu build failure, hxtool is a bash script, not a /bin/sh script

[Felix von Leitner]

I actually have bash installed as /bin/sh and /bin/bash.
But I also have heirloom sh installed, which installs itself as /sbin/sh, and 
that happened to be first in my $PATH.

Since the makefiles use "sh script" to run the scripts, that called the
heirloom sh.

http://heirloom.sourceforge.net/sh.html

It is, it turns out, derived from OpenSolaris.  So there you go :-)

When I delete /sbin/sh, qemu builds.

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

Title:
  qemu build failure, hxtool is a bash script, not a /bin/sh script

Status in QEMU:
  New

Bug description:
  hxtool (part of the early build process) is a bash script.  Running it
  with /bin/sh yields a syntax error on line 10:

   10 STEXI*|ETEXI*|SQMP*|EQMP*) flag=$(($flag^1))

  $(( expr )) is a bash extension, not part of /bin/sh.

  Note that replacing the sh in the first line in hxtool with /bin/bash
  does not help, because the script is run manually from the Makefile
  with sh:

  154 $(call quiet-command,sh $(SRC_PATH)/scripts/hxtool -h < $<
  > $@,"  GEN   $@")

  The fix is to change those lines to

  154 $(call quiet-command,bash $(SRC_PATH)/scripts/hxtool -h <
  $< > $@,"  GEN   $@")

  (there are five or so).

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

[Qemu-devel] [Bug 1347555] Re: qemu build failure, hxtool is a bash script, not a /bin/sh script

[Felix von Leitner]

It turns out that expr does not support ^ (at least according to the man
page). :-)

Still, you could do expr -$flag + 1 to do the same thing.

Is the ruckus just about this one place where $(( )) is used or are
there other non-Bourne-shell constructs?

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

Title:
  qemu build failure, hxtool is a bash script, not a /bin/sh script

Status in QEMU:
  New

Bug description:
  hxtool (part of the early build process) is a bash script.  Running it
  with /bin/sh yields a syntax error on line 10:

   10 STEXI*|ETEXI*|SQMP*|EQMP*) flag=$(($flag^1))

  $(( expr )) is a bash extension, not part of /bin/sh.

  Note that replacing the sh in the first line in hxtool with /bin/bash
  does not help, because the script is run manually from the Makefile
  with sh:

  154 $(call quiet-command,sh $(SRC_PATH)/scripts/hxtool -h < $<
  > $@,"  GEN   $@")

  The fix is to change those lines to

  154 $(call quiet-command,bash $(SRC_PATH)/scripts/hxtool -h <
  $< > $@,"  GEN   $@")

  (there are five or so).

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

[PATCH] gtk: Add show_tabs=on|off command line option.

[Felix xq Queißner]

The patch adds "show_tabs" command line option for GTK ui similar to 
"grab_on_hover". This option allows tabbed view mode to not have to be enabled 
by hand at each start of the VM.

Signed-off-by: Felix "xq" Queißner 
---
 qapi/ui.json| 5 -
 qemu-options.hx | 2 +-
 ui/gtk.c| 4 
 3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/qapi/ui.json b/qapi/ui.json
index 413371d5e8..049e7957a9 100644
--- a/qapi/ui.json
+++ b/qapi/ui.json
@@ -1195,12 +1195,15 @@
 #   assuming the guest will resize the display to match
 #   the window size then.  Otherwise it defaults to "off".
 #   Since 3.1
+# @show-tabs:   Displays the tab items by default.
+#   Since 7.1
 #
 # Since: 2.12
 ##
 { 'struct'  : 'DisplayGTK',
   'data': { '*grab-on-hover' : 'bool',
-'*zoom-to-fit'   : 'bool'  } }
+'*zoom-to-fit'   : 'bool',
+'*show-tabs' : 'bool'  } }
 
 ##
 # @DisplayEGLHeadless:
diff --git a/qemu-options.hx b/qemu-options.hx
index 377d22fbd8..2b279afff7 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1937,7 +1937,7 @@ DEF("display", HAS_ARG, QEMU_OPTION_display,
 "[,window-close=on|off]\n"
 #endif
 #if defined(CONFIG_GTK)
-"-display gtk[,full-screen=on|off][,gl=on|off][,grab-on-hover=on|off]\n"
+"-display 
gtk[,full-screen=on|off][,gl=on|off][,grab-on-hover=on|off][,show-tabs=on|off]\n"
 "[,show-cursor=on|off][,window-close=on|off]\n"
 #endif
 #if defined(CONFIG_VNC)
diff --git a/ui/gtk.c b/ui/gtk.c
index 2a791dd2aa..1467b8c7d7 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -2390,6 +2390,10 @@ static void gtk_display_init(DisplayState *ds, 
DisplayOptions *opts)
 opts->u.gtk.grab_on_hover) {
 gtk_menu_item_activate(GTK_MENU_ITEM(s->grab_on_hover_item));
 }
+if (opts->u.gtk.has_show_tabs &&
+opts->u.gtk.show_tabs) {
+gtk_menu_item_activate(GTK_MENU_ITEM(s->show_tabs_item));
+}
 gd_clipboard_init(s);
 }
 
-- 
2.36.1

[PATCH v2] gtk: Add show_tabs=on|off command line option.

[Felix xq Queißner]

The patch adds "show_tabs" command line option for GTK ui similar to
"grab_on_hover". This option allows tabbed view mode to not have to be
enabled by hand at each start of the VM.

Signed-off-by: Felix "xq" Queißner 
---
 qapi/ui.json| 7 ++-
 qemu-options.hx | 6 +-
 ui/gtk.c| 4 
 3 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/qapi/ui.json b/qapi/ui.json
index 413371d5e8..cf58ab4283 100644
--- a/qapi/ui.json
+++ b/qapi/ui.json
@@ -1195,12 +1195,17 @@
 #   assuming the guest will resize the display to match
 #   the window size then.  Otherwise it defaults to "off".
 #   Since 3.1
+# @show-tabs:   Display the tab bar for switching between the various graphical
+#   interfaces (e.g. VGA and virtual console character devices)
+#   by default.
+#   Since 7.1
 #
 # Since: 2.12
 ##
 { 'struct'  : 'DisplayGTK',
   'data': { '*grab-on-hover' : 'bool',
-'*zoom-to-fit'   : 'bool'  } }
+'*zoom-to-fit'   : 'bool',
+'*show-tabs' : 'bool'  } }
 
 ##
 # @DisplayEGLHeadless:
diff --git a/qemu-options.hx b/qemu-options.hx
index 377d22fbd8..79e00916a1 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1938,7 +1938,7 @@ DEF("display", HAS_ARG, QEMU_OPTION_display,
 #endif
 #if defined(CONFIG_GTK)
 "-display gtk[,full-screen=on|off][,gl=on|off][,grab-on-hover=on|off]\n"
-"[,show-cursor=on|off][,window-close=on|off]\n"
+"
[,show-tabs=on|off][,show-cursor=on|off][,window-close=on|off]\n"
 #endif
 #if defined(CONFIG_VNC)
 "-display vnc=[,]\n"
@@ -2023,6 +2023,10 @@ SRST
 
 ``grab-on-hover=on|off`` : Grab keyboard input on mouse hover
 
+``show-tabs=on|off`` : Display the tab bar for switching between the
+   various graphical interfaces (e.g. VGA and
+   virtual console character devices) by default.
+
 ``show-cursor=on|off`` :  Force showing the mouse cursor
 
 ``window-close=on|off`` : Allow to quit qemu with window close button
diff --git a/ui/gtk.c b/ui/gtk.c
index 2a791dd2aa..1467b8c7d7 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -2390,6 +2390,10 @@ static void gtk_display_init(DisplayState *ds, 
DisplayOptions *opts)
 opts->u.gtk.grab_on_hover) {
 gtk_menu_item_activate(GTK_MENU_ITEM(s->grab_on_hover_item));
 }
+if (opts->u.gtk.has_show_tabs &&
+opts->u.gtk.show_tabs) {
+gtk_menu_item_activate(GTK_MENU_ITEM(s->show_tabs_item));
+}
 gd_clipboard_init(s);
 }
 
-- 
2.36.1