date:20210510

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/263


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

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #263
   https://gitlab.com/qemu-project/qemu/-/issues/263

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

Title:
  readdir() returns NULL (errno=EOVERFLOW) for 32-bit user-static qemu
  on 64-bit host

Status in QEMU:
  Expired

Bug description:
  This can be simply reproduced by compiling and running the attached C
  code (readdir-bug.c) under 32-bit user-static qemu, such as qemu-arm-
  static:

  # Setup docker for user-static binfmt
  docker run --rm --privileged multiarch/qemu-user-static:register --reset
  # Compile the code and run (readdir for / is fine, so create a new directory 
/test).
  docker run -v /path/to/qemu-arm-static:/usr/bin/qemu-arm-static -v 
/path/to/readdir-bug.c:/tmp/readdir-bug.c -it --rm arm32v7/ubuntu:18.10 bash -c 
'{ apt update && apt install -y gcc; } >&/dev/null && mkdir -p /test && cd 
/test && gcc /tmp/readdir-bug.c && ./a.out'
  dir=0xff5b4150
  readdir(dir)=(nil)
  errno=75: Value too large for defined data type

  Do remember to replace the /path/to/qemu-arm-static and /path/to
  /readdir-bug.c to the actual paths of the files.

  The root cause is in glibc:
  
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/getdents.c;h=6d09a5be7057e2792be9150d3a2c7b293cf6fc34;hb=a5275ba5378c9256d18e582572b4315e8edfcbfb#l87

  By C standard, the return type of readdir() is DIR*, in which the
  inode number and offset are 32-bit integers, therefore, glibc calls
  getdents64() and check if the inode number and offset fits the 32-bit
  range, and reports EOVERFLOW if not.

  The problem here is for 32-bit user-static qemu running on 64-bit
  host, getdents64 simply passing through the inode number and offset
  from underlying getdents64 syscall (from 64-bit kernel), which is very
  likely to not fit into 32-bit range. On real hardware, the 32-bit
  kernel creates 32-bit inode numbers, therefore works properly.

  The glibc code makes sense to do the check to be conformant with C
  standard, therefore ideally it should be a fix on qemu side. I admit
  this is difficult because qemu has to maintain a mapping between
  underlying 64-bit inode numbers and 32-bit inode numbers, which would
  severely hurt the performance. I don't expect this could be fix
  anytime soon (or even there would be a fix), but it would be
  worthwhile to surface this issue.

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

[Bug 1824344] Re: x86: retf or iret pagefault sets wrong error code

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/265


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

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #265
   https://gitlab.com/qemu-project/qemu/-/issues/265

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

Title:
  x86: retf or iret pagefault sets wrong error code

Status in QEMU:
  Expired

Bug description:
  With a x86_64 or i386 guest, non-KVM, when trying to execute a
  "iret/iretq/retf" instruction in userspace with invalid stack pointer
  (under a protected mode OS, like Linux), wrong bits are set in the
  pushed error code; bit 2 is not set, indicating the error comes from
  kernel space.

  If the guest OS is using this flag to decide whether this was a kernel
  or user page fault, it will mistakenly decide a kernel has irrecoverably
  faulted, possibly causing guest OS panic.

  
  How to reproduce the problem a guest (non-KVM) Linux:
  Note, on recent Linux kernel version, this needs a CPU with SMAP support
  (eg. -cpu max)

  $ cat tst.c
  int main()
  {
  __asm__ volatile (
  "mov $0,%esp\n"
  "retf"
  );
  return 0;
  }

  $ gcc tst.c
  $ ./a.out
  Killed

  
  "dmesg" shows the kernel has in fact triggered a "BUG: unable to handle
  kernel NULL pointer dereference...", but it has "recovered" by killing
  the faulting process (see attached screenshot).

  
  Using self-compiled qemu from git:
  commit 532cc6da74ec25b5ba6893b5757c977d54582949 (HEAD -> master, tag: 
v4.0.0-rc3, origin/master, origin/HEAD)
  Author: Peter Maydell 
  Date:   Wed Apr 10 15:38:59 2019 +0100

  Update version for v4.0.0-rc3 release
  
  Signed-off-by: Peter Maydell 

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

[Bug 1843795] Re: 'mtfsf' instruction can clear FI incorrectly

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/266


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

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #266
   https://gitlab.com/qemu-project/qemu/-/issues/266

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

Title:
  'mtfsf' instruction can clear FI incorrectly

Status in QEMU:
  Expired

Bug description:
  Using mtfsf instruction can clear the FPSCR FI bit incorrectly.  This code 
snippet exhibits the issue:
  --
fpscr.ll = 0x1fff;
__builtin_mtfsf (0b, fpscr.d);
fpscr.d = __builtin_mffs ();
  --

  On POWER9 hardware:
  mffs: FPSCR = 0x77ff

  On qemu (git master; "-cpu POWER9"):
  --
  $ ./mtfsf
  mffs: FPSCR = 0x7ffd
  --

  Two differences:
  bit 52: "reserved", so maybe a "don't care" case
  bit 46: "FI"

  $ git log -1 master
  commit 89ea03a7dc83ca36b670ba7f787802791fcb04b1
  Merge: 019217c 2531164
  Author: Peter Maydell 
  Date:   Mon Sep 9 09:48:34 2019 +0100

  I tracked the clear is coming from do_float_check_status, likely the
  one in gen_mtfsf, but then I get lost figuring out what _should_ be
  happening. :-/

  Test attached.

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

[Bug 1883083] Re: QEMU: block/vvfat driver issues

This ticket has been transferred to QEMU's new bug tracker here:
https://gitlab.com/qemu-project/qemu/-/issues/272
... thus closing the issue on Launchpad now.

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #272
   https://gitlab.com/qemu-project/qemu/-/issues/272

** Changed in: qemu
   Status: New => Invalid

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

Title:
  QEMU: block/vvfat driver issues

Status in QEMU:
  Invalid

Bug description:
  Nathan Huckleberry  has reported following issues
  in the block/vvfat driver for the virtual VFAT file system image, used
  to share a host system directory with a guest VM.

  Please note:
-> 
https://www.qemu.org/docs/master/system/images.html#virtual-fat-disk-images

  Virtual VFAT read/write support is available only for (beta) testing
  purposes.

  Following issues are reproducible with:

 host)$ ./bin/qemu-system-x86_64 -nographic -enable-kvm \
-drive file=fat:rw:/tmp/var/run/,index=2  -m 2048 
/var/lib/libvirt/images/f27vm.qcow2

guest)# mount -t vfat /dev/sdb1 /mnt/

  The attached reproducers (run inside a guest) include:

  1. dir.sh: - directory traversal on the host
 - It creates a file under /mnt/
 - Then edits the VFAT directory entry to make it -> /mnt/../y
 - The handle_renames_and_mkdirs() routine does not check this new file name
   and creates a file outside of the shared directory on the host

  2. dos.sh: hits an assertion failure in vvfat driver
 - Creates a deep directory tree like - /mnt/0/1/2/3/4/5/6/../29/30/
 - While updating vvfat commits, driver hits an assertion in
   handle_renames_and_mkdirs
 ...
 } else if (commit->action == ACTION_MKDIR) {
 ...
 assert(j < s->mapping.next);<== it fails

  3. read.sh: reads past vvfat directory entries
 - Creates a file with: echo "x" > /mnt/a
 - Reads past VVFAT directory entry structure with

 # head -c 100 $MNTDEV | xxd | grep x -A 512

 - It may disclose some heap addresses.

  4. write.sh: heap buffer overflow
 - Creates large number of files as /mnt/file[1..35]
 - while syncing directory tree with the host, driver hits an overflow
   while doing memmove(3) in array_roll() routine

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

[Bug 1847467] Re: qemu-x86_64 segment prefixes error

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/267


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

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #267
   https://gitlab.com/qemu-project/qemu/-/issues/267

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

Title:
  qemu-x86_64 segment prefixes error

Status in QEMU:
  Expired

Bug description:
  qemu-x86_64 version 4.1.0 (qemu-x86_64 version 4.0.0 also have the
  issue)

  In 64-bit mode (x86_64) the DS, ES, SS or CS segment prefixes should
  be ignored; qemu-x86_64 does not ignore them.

  example: an x86_64 instructions preceded by FS DS (0x64 0x26) segment
  prefixes have the linear address of its memory reference flat-mapped
  (as if DS was in action) whereas it should be FS-mapped (offset by
  FS_base, because the DS, ES, SS or CS are just ignored).

  
  I attach a small C++ program that shows this discrepancy.

  $ ./sample
  I'm not in QEMU

  $ qemu-x86_64 ./sample
  I'm in QEMU

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

[Bug 1874264] Re: AIX 7.2 TL4 SP1 cannot IPL with QEMU >2.11.2 ppc64-softmmu

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/269


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

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #269
   https://gitlab.com/qemu-project/qemu/-/issues/269

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

Title:
  AIX 7.2 TL4 SP1 cannot IPL with QEMU >2.11.2 ppc64-softmmu

Status in QEMU:
  Expired

Bug description:
  kens@LAPTOP-JN77KAC2$ qemu-system-ppc64 -version
  QEMU emulator version 4.2.93 (v5.0.0-rc3-8-g3119154db0-dirty)
  Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers

  qemu-system-ppc64 \
-name "IBM AIX - IBM POWER9" \
-M pseries \
-cpu POWER9 \
-smp 8 \
-m 8192 \
-nodefaults \
-nographic \
-prom-env input-device=/vdevice/vty@7100 \
-prom-env output-device=/vdevice/vty@7100 \
-serial tcp::9019,server,nowait \
-monitor tcp::9020,server,nowait \
-netdev type=user,id=mynet0,hostfwd=tcp:127.0.0.1:9018-10.0.2.18:22 \
-device virtio-net-pci,netdev=mynet0 \
-drive 
file=images/aix-ppc64.img,format=qcow2,if=none,id=hd,media=disk,cache=unsafe \
-device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd \
-drive file=images/iso/blank-cdrom,format=raw,media=cdrom,cache=unsafe

  
---
  Welcome to AIX.
 boot image timestamp: 14:18:40 03/27/2020
  processor count: 8;  memory size: 8192MB;  kernel size: 45422205
   boot device: /pci@8002000/scsi@1/disk@100
  AIX vm,uuid property contains invalid data
  processing splpar characteristic: MaxEntCap
  processing splpar characteristic: DesMem
  processing splpar characteristic: DesProcs
  processing splpar characteristic: MaxPlatProcs
  processing splpar characteristic: HostThrs

  AKVM: hcall-multi-tce detected but overridden, allow with "multce" boot 
argument
  
---
  Starqemu-system-ppc64: OS terminated: 888 102 700 C20

  
  qemu-system-ppc64 \
-name "IBM AIX - IBM POWER8" \
-M pseries \
-cpu POWER8 \
-smp 8 \
-m 8192 \
-nodefaults \
-nographic \
-prom-env input-device=/vdevice/vty@7100 \
-prom-env output-device=/vdevice/vty@7100 \
-serial tcp::9019,server,nowait \
-monitor tcp::9020,server,nowait \
-netdev type=user,id=mynet0,hostfwd=tcp:127.0.0.1:9018-10.0.2.18:22 \
-device virtio-net-pci,netdev=mynet0 \
-drive 
file=images/aix-ppc64.img,format=qcow2,if=none,id=hd,media=disk,cache=unsafe \
-device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd \
-drive file=images/iso/blank-cdrom,format=raw,media=cdrom,cache=unsafe

  
---
  Welcome to AIX.
 boot image timestamp: 14:18:40 03/27/2020
  processor count: 8;  memory size: 8192MB;  kernel size: 45422205
   boot device: /pci@8002000/scsi@1/disk@100
  AIX vm,uuid property contains invalid data
  processing splpar characteristic: MaxEntCap
  processing splpar characteristic: DesMem
  processing splpar characteristic: DesProcs
  processing splpar characteristic: MaxPlatProcs
  processing splpar characteristic: HostThrs

  AKVM: hcall-multi-tce detected but overridden, allow with "multce" boot 
argument
  
---
  Star**
  ERROR:/home/kens/tmp/qemu/cpus.c:1727:qemu_tcg_cpu_thread_fn: assertion 
failed: (cpu->halted)

  
  kens@LAPTOP-JN77KAC2$ qemu-system-ppc64 -version
  QEMU emulator version 2.11.2
  Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

  qemu-system-ppc64 \
-name "IBM AIX - IBM POWER9" \
-M pseries,cap-htm=off \
-cpu POWER9 \
-smp 8 \
-m 8192 \
-nodefaults \
-nographic \
-prom-env input-device=/vdevice/vty@7100 \
-prom-env output-device=/vdevice/vty@7100 \
-serial tcp::9019,server,nowait \
-monitor tcp::9020,server,nowait \
-netdev type=user,id=mynet0,hostfwd=tcp:127.0.0.1:9018-10.0.2.18:22 \
-device virtio-net-pci,netdev=mynet0 \
-drive 
file=images/aix-ppc64.img,format=qcow2,if=none,id=hd,media=disk,cache=unsafe \
-device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd \
-drive file=images/iso/blank-cdrom,format=raw,media=cdrom,cache=unsafe

  
---
  Welcome to AIX.
 boot image timestamp:

[Bug 1859384] Re: arm gic: gic_acknowledge_irq doesn't clear line level for other cores for 1-n level-sensitive interrupts and gic_clear_pending uses GIC_DIST_TEST_MODEL (even on v2 where it always re

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/268


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

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #268
   https://gitlab.com/qemu-project/qemu/-/issues/268

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

Title:
  arm gic: gic_acknowledge_irq doesn't clear line level for other cores
  for 1-n level-sensitive interrupts and gic_clear_pending uses
  GIC_DIST_TEST_MODEL (even on v2 where it always read 0 - "N-N")

Status in QEMU:
  Expired

Bug description:
  For a 1-N interrupt (any SPI on the GICv2), as mandated by the TRM,
  only one CPU can acknowledge the IRQ until it becomes inactive.

  The TRM also mandates that SGIs and PPIs follow the N-N model and that
  SPIs follow the 1-N model.

  However this is not currently the case with QEMU. I have locally (no
  minimal test case) seen e.g. uart interrupts being acknowledged twice
  before having been deactivated (expected: irqId on one CPU and 1023 on
  the other instead).

  I have narrowed the issue down to the following:

  1) arm_gic_common_reset resets all irq_state[id] fields to 0. This
  means all IRQ will use the N-N model, and if s->revision !=
  REV_11MPCORE, then there's no way to set any interrupt to 1-N.

  If ""fixed"" locally with a hackjob, I still have the following trace:

  pl011_irq_state 534130.800 pid=2424 level=0x1
  gic_set_irq 2.900 pid=2424 irq=0x21 level=0x1 cpumask=0xff target=0xff
  gic_update_set_irq 3.300 pid=2424 cpu=0x0 name=irq level=0x1
  gic_update_set_irq 4.200 pid=2424 cpu=0x1 name=irq level=0x1
  gic_acknowledge_irq 539.400 pid=2424 s=cpu cpu=0x1 irq=0x21
  gic_update_set_irq 269.800 pid=2424 cpu=0x0 name=irq level=0x1
  gic_cpu_read 4.100 pid=2424 s=cpu cpu=0x1 addr=0xc val=0x21
  gic_acknowledge_irq 15.600 pid=2424 s=cpu cpu=0x0 irq=0x21
  gic_cpu_read 265.000 pid=2424 s=cpu cpu=0x0 addr=0xc val=0x21
  pl011_write 1594.700 pid=2424 addr=0x44 value=0x50
  pl011_irq_state 2.000 pid=2424 level=0x0
  gic_set_irq 1.300 pid=2424 irq=0x21 level=0x0 cpumask=0xff target=0xff
  pl011_write 30.700 pid=2424 addr=0x38 value=0x0
  pl011_irq_state 1.200 pid=2424 level=0x0
  gic_cpu_write 110.600 pid=2424 s=cpu cpu=0x0 addr=0x10 val=0x21
  gic_cpu_write 193.400 pid=2424 s=cpu cpu=0x0 addr=0x1000 val=0x21
  pl011_irq_state 1169.500 pid=2424 level=0x0

  This is because:

  2) gic_acknowledge_irq calls gic_clear_pending which uses
  GIC_DIST_CLEAR_PENDING but this usually has no effect on level-
  sensitive interrupts.

  With this often being a no-op (ie. assuming ispendr was not written
  to), any 1-n level-sensitive interrupt is still improperly pending on
  all the other cores.

  (Also, I don't really know how the qemu thread model works, there
  might be race conditions in the acknowledgment logic if
  gic_acknowledge_irq is called by multiple threads, too.)

  Option used:
  -nographic -machine virt,virtualization=on,accel=tcg,gic-version=2 -cpu 
cortex-a57 -smp 4 -m 1024
  -kernel whatever.elf -d unimp,guest_errors -semihosting-config 
enable,target=native
  -chardev stdio,id=uart -serial chardev:uart -monitor none
  -trace gic_update_set_irq -trace gic_acknowledge_irq -trace pl011_irq_state 
-trace pl011_write -trace gic_cpu_read -trace gic_cpu_write
  -trace gic_set_irq

  Commit used: dc65a5bdc9fa543690a775b50d4ffbeb22c56d6d "Merge remote-
  tracking branch 'remotes/dgibson/tags/ppc-for-5.0-20200108' into
  staging"

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

[Bug 1681439] Re: dma_blk_cb leaks memory map handles on misaligned IO

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/259


** Tags added: fuzzer

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

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #259
   https://gitlab.com/qemu-project/qemu/-/issues/259

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

Title:
  dma_blk_cb leaks memory map handles on misaligned IO

Status in QEMU:
  Expired

Bug description:
  Maintainer Edit:

  The functions in dma-helpers mismanage misaligned IO, badly enough to
  cause an infinite loop where no progress can be made. This allows the
  IDE state machine to get wedged such that cancelling DMA can fail;
  because the DMA helpers have bodged the state of the DMA transfer. See
  Comment #15 for the in-depth analysis.

  I've updated the name of this bug to reflect the current status as I
  understand it.

  --js

  
  Original report:

  Since upgrading to QEMU 2.8.0, my Windows 7 64-bit virtual machines
  started crashing due to the assertion quoted in the summary failing.
  The assertion in question was added by commit 9972354856 ("block: add
  BDS field to count in-flight requests").  My tests show that setting
  discard=unmap is needed to reproduce the issue.  Speaking of
  reproduction, it is a bit flaky, because I have been unable to come up
  with specific instructions that would allow the issue to be triggered
  outside of my environment, but I do have a semi-sane way of testing that
  appears to depend on a specific initial state of data on the underlying
  storage volume, actions taken within the VM and waiting for about 20
  minutes.

  Here is the shortest QEMU command line that I managed to reproduce the
  bug with:

  qemu-system-x86_64 \
  -machine pc-i440fx-2.7,accel=kvm \
  -m 3072 \
  -drive file=/dev/lvm/qemu,format=raw,if=ide,discard=unmap \
   -netdev tap,id=hostnet0,ifname=tap0,script=no,downscript=no,vhost=on \
  -device virtio-net-pci,netdev=hostnet0 \
   -vnc :0

  The underlying storage (/dev/lvm/qemu) is a thin LVM snapshot.

  QEMU was compiled using:

  ./configure --python=/usr/bin/python2.7 --target-list=x86_64-softmmu
  make -j3

  My virtualization environment is not really a critical one and
  reproduction is not that much of a hassle, so if you need me to gather
  further diagnostic information or test patches, I will be happy to help.

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

[Bug 1806196] Re: qed leaked clusters

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/264


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

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #264
   https://gitlab.com/qemu-project/qemu/-/issues/264

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

Title:
  qed leaked clusters

Status in QEMU:
  Expired

Bug description:
  There are examples of two QED files which AFAIK does not have any
  errors both. But `qemu-img check` says that one of them has 1 leaked
  cluster.

  I wrote my own tool and it does not find any error. Both files
  attached, as well as debug output from my program.

  Both files are about 4G in size after unpacking. Unpack with `tar -S`
  to handle sparse files.

  And also, I know, that QED is deprecated, but anyway, seems qemu-img
  has bug.

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

[Bug 1699824] Re: qemu-system-sparc64 -M sun4v aborts on tribblix-sparc-0m16.iso

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/260


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

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #260
   https://gitlab.com/qemu-project/qemu/-/issues/260

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

Title:
  qemu-system-sparc64 -M sun4v aborts on tribblix-sparc-0m16.iso

Status in QEMU:
  Expired

Bug description:
  qemu-system-sparc64 qemu-2.9.0-3.10.x86_64 on openSUSE Leap 42.3 using
  'sun4v' machine aborts with tribblix. With 2048 MB of RAM it takes
  considerably more time to abort (but the core is always truncated).

  > qemu-system-sparc64 -m 1024 -cdrom tribblix-sparc-0m16.iso -boot d 
-nographic -M sun4v
  qemu: fatal: Trap 0x0010 while trap level (6) >= MAXTL (6), Error state
  pc: 0200  npc: 0204
  %g0-3:    
  %g4-7:    
  %o0-3:     
  %o4-7:     
  %l0-3: 3ff0 01ff 01fff008  
  %l4-7:     
  %i0-3:     
  %i4-7:     
  %f00:     
  %f08:     
  %f16:     
  %f24:     
  %f32:     
  %f40:     
  %f48:     
  %f56:     
  pstate: 0014 ccr: 44 (icc: -Z-- xcc: -Z--) asi: 00 tl: 6 pil: 0 gl: 8
  tbr:  hpstate: 0004 htba: 
  cansave: 6 canrestore: 0 otherwin: 0 wstate: 0 cleanwin: 6 cwp: 7
  fsr:  y:  fprs: 

  Aborted (core dumped)

  
 PID: 26999 (qemu-system-spa)
 UID: 1000 (newman)
 GID: 100 (users)
  Signal: 6 (ABRT)
   Timestamp: Thu 2017-06-22 16:19:02 CEST (1min 5s ago)
Command Line: qemu-system-sparc64 -m 1024 -cdrom tribblix-sparc-0m16.iso 
-boot d -nographic -M sun4v
  Executable: /usr/bin/qemu-system-sparc64
   Control Group: /
   Slice: -.slice
 Boot ID: aa7431274f854fb7a02a773eefa8a9bb
  Machine ID: 89c660865c00403a9bacef32b6828556
Hostname: assam.suse.cz
Coredump: 
/var/lib/systemd/coredump/core.qemu-system-spa.1000.aa7431274f854fb7a02a773eefa8a9bb.26999.149814114200.xz
 Message: Process 26999 (qemu-system-spa) of user 1000 dumped core.


  (gdb) thread apply all bt full

  Thread 4 (Thread 0x7f3896aca700 (LWP 27001)):
  #0  0x7f38bb983295 in do_futex_wait () at /lib64/libpthread.so.0
  #1  0x7f38bb983349 in __new_sem_wait_slow () at /lib64/libpthread.so.0
  #2  0x7f38bb9833f7 in sem_timedwait () at /lib64/libpthread.so.0
  #3  0x5599ec6a1147 in qemu_sem_timedwait (sem=sem@entry=0x5599ef168628, 
ms=ms@entry=1) at util/qemu-thread-posix.c:255
  rc = 
  ts = {tv_sec = 1498141152, tv_nsec = 280531000}
  __func__ = "qemu_sem_timedwait"
  #4  0x5599ec69c83c in worker_thread (opaque=0x5599ef1685c0) at 
util/thread-pool.c:92
  req = 
  ret = 
  pool = 0x5599ef1685c0
  #5  0x7f38bb97c744 in start_thread () at /lib64/libpthread.so.0
  #6  0x7f38b79bdd3d in clone () at /lib64/libc.so.6

  Thread 3 (Thread 0x7f38bee01c40 (LWP 26999)):
  #0  0x7f38b79b555f in ppoll () at /lib64/libc.so.6
  #1  0x5599ec69d289 in ppoll (__ss=0x0, __timeout=0x7ffd1dcf2a20, 
__nfds=, __fds=) at /usr/include/bits/poll2.h:77
  ts = {tv_sec = 1, tv_nsec = 0}
  Python Exception  That operation is not available on 
integers of more than 8 bytes.: 
  #2  0x5599ec69d289 in qemu_poll_ns (fds=, nfds=, timeout=timeout@entry=10) at util/qemu-timer.c:334
  ts = {tv_sec = 1, tv_nsec = 0}
  Python Exception  That operation is not available on 
integers of more than 8 bytes.: 
  #3  0x5599ec69dff8 in os_host_main_loop_wait (timeout=10) at 
util/main-loop.c:255
  context = 0x5599ef147470
  ret = 
  spin_counter = 0

[Bug 1877015] Re: virtio only support packed ring size power of 2

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/270


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

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #270
   https://gitlab.com/qemu-project/qemu/-/issues/270

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

Title:
  virtio only support packed ring size power of 2

Status in QEMU:
  Expired

Bug description:
  Issue discription：
  When QEMU starts with "-device 
virtio-net-pci,netdev=netdev0,mac=52:54:00:00:00:01,disable-modern=false,mrg_rxbuf=on,rx_queue_size=1025,tx_queue_size=1025,mq=on,vectors=15,packed=on"

  It raises error: Invalid rx_queue_size (= 1025), must be a power of 2
  between 256 and 1024

  Analysis:
  According to virtio1.1 spec, the packed queue size value does not have to be 
a power of 2.

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

[Bug 1882123] Re: ARM cpu emulation regression on QEMU 4.2.0

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/271


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

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #271
   https://gitlab.com/qemu-project/qemu/-/issues/271

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

Title:
  ARM cpu emulation regression on QEMU 4.2.0

Status in QEMU:
  Expired

Bug description:
  [*] Summary

  Latest QEMU has an ARM CPU emulation regression.
  Regression is reproducible by building any C# project with .NET Core SDK 
3.1.300 on Debian 10 armhf guest OS.

  Releases affected: QEMU 4.2.0, 5.0.0
  Releases not affected: QEMU 4.1.0, QEMU 4.1.1

  [*] Detail

  .NET Core SDK 3.1 fails to run on Debian 10 emulated by qemu-system-
  arm.

  I occasionally test my C# projects on the virtual armhf/arm64 system
  emulated by QEMU. MSBuild, a build engine of the .NET Core SDK,
  crashes on QEMU 4.2.0 or later. The crash only happens when MSBuild
  tries to do any JIT compiling (dotnet build / dotnet test).

  I attached the MSBuild crash logs. MSBuild always crashes with
  SEHException, which means it tried to call C binary from .NET binary.

  I think the ARM CPU emulation regression happened between QEMU 4.1.1 ~
  4.2.0. The issue affects QEMU 4.2.0 and 5.0.0. QEMU 4.1.0, 4.1.1, and
  real Raspberry Pi 2 are not affected by this issue, and .NET Core SDK
  works completely fine.

  [*] Environment

  [Host OS]
  Distribution: Linux Mint 19.3 amd64
  CPU: AMD Ryzen 5 3600
  Kernel: Ubuntu 5.3.0-51-generic

  [QEMU Guest OS]
  Distribution: Debian 10 Buster armhf
  Kernel: Debian 4.19.0-9-armmp-lpae
  .NET Core SDK: 3.1.300

  [Raspberry Pi 2]
  Distribution: Raspberry Pi OS Buster armhf
  Kernel: 4.19.118-v7+

  [Tested C# Projects]
  This is a list of C# projects I have tested on QEMU and RPI2.
  - https://github.com/ied206/Joveler.DynLoader
  - https://github.com/ied206/Joveler.Compression
  - https://github.com/ied206/ManagedWimLib

  [QEMU Launch Arguments]
  qemu-system-arm \
  -smp 3 -M virt -m 4096 \
  -kernel vmlinuz-4.19.0-9-armmp-lpae \
  -initrd initrd.img-4.19.0-9-armmp-lpae \
  -append "root=/dev/vda2" \
  -drive if=none,file=debian_arm.qcow2,format=qcow2,id=hd \
  -device virtio-blk-device,drive=hd \
  -netdev user,id=mynet,hostfwd=tcp::-:22 \
  -device virtio-net-device,netdev=mynet \
  -device virtio-rng-device

  [QEMU Configure Arguments]
  ./configure --enable-spice --enable-gtk --enable-vnc-jpeg --enable-vnc-png 
--enable-avx2 --enable-libusb --enable-opengl --enable-virglrenderer 
--enable-kvm --enable-system --enable-modules --audio-drv-list=pa

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

[Bug 1791763] Re: broken signal handling in nios2 user-mode emulation

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/261


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

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #261
   https://gitlab.com/qemu-project/qemu/-/issues/261

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

Title:
  broken signal handling in nios2 user-mode emulation

Status in QEMU:
  Expired

Bug description:
  This bug is against the 3.0 release.

  It appears that the signal handling parts of the nios2 user-mode
  emulation have never really been completed or tested.  Some examples
  of failing tests from the GCC testsuite are gcc.dg/pr78185.c and
  gcc.dg/cleanup-10.c.

  Some problems I've identified and tried to fix with the attached patch
  are:

  - Code copied from the Linux kernel wasn't adjusted to differentiate
  between host and target data types and address spaces.

  - The sigaltstack() system call returns EINVAL because fields are
  listed in the wrong order in struct target_sigaltstack.

  With this patch, the system calls to set up the signal handler are
  returning successfully, but the handler isn't being invoked, so
  something is still wrong.  I think I need another pair of eyes to look
  over this code.

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

[Bug 1883729] Re: xhci_find_stream: Assertion `streamid != 0' failed.

** Tags added: usb

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

Title:
  xhci_find_stream: Assertion `streamid != 0' failed.

Status in QEMU:
  New

Bug description:
  To reproduce run the QEMU with the following command line:
  ```
  qemu-system-x86_64 -cdrom hypertrash_os_bios_crash.iso -nographic -m 100 
-enable-kvm -device virtio-gpu-pci -device nec-usb-xhci -device usb-audio
  ```

  QEMU Version:
  ```
  # qemu-5.0.0
  $ ./configure --target-list=x86_64-softmmu --enable-sanitizers; make
  $ x86_64-softmmu/qemu-system-x86_64 --version
  QEMU emulator version 5.0.0
  Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers
  ```

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

[Bug 1799792] Re: Broken scaling with gtk,gl=on on a hidpi display

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/262


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

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #262
   https://gitlab.com/qemu-project/qemu/-/issues/262

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

Title:
  Broken scaling with gtk,gl=on on a hidpi display

Status in QEMU:
  Expired

Bug description:
  Tested on QEMU 3.0.0 on Arch Linux.

  I'm using a hidpi screen, and therefore use those environment
  variables in order to have GTK+ apps properly scaled:

  GDK_SCALE=2
  GDK_DPI_SCALE=0.5

  However, QEMU, when launched with "-display gtk,gl=on" option, doesn't
  scale the window content properly, as seen on the attached screenshot.

  Switching to "-display gtk,gl=off" and "-display sdl,gl=on" makes it
  work fine.

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

Re: [PATCH] cutils: fix memory leak in get_relocated_path()

2021-05-10 Thread Markus Armbruster

Stefano Garzarella  writes:

> Ping :-)
>
> Should I resend for 6.1?

I'm cc'ing qemu-trivial.

For good measure:
Reviewed-by: Markus Armbruster

[Bug 1883733] Re: FIXME xhci_alloc_device_streams:972 guest streams config not identical for all eps

** Tags added: fuzzer

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

Title:
  FIXME xhci_alloc_device_streams:972 guest streams config not identical
  for all eps

Status in QEMU:
  New

Bug description:
  To reproduce run the QEMU with the following command line:
  ```
  qemu-system-x86_64 -cdrom hypertrash_os_bios_crash.iso -nographic -m 100 
-enable-kvm -device virtio-gpu-pci -device nec-usb-xhci -device usb-audio
  ```

  QEMU Version:
  ```
  # qemu-5.0.0
  $ ./configure --target-list=x86_64-softmmu --enable-sanitizers; make
  $ x86_64-softmmu/qemu-system-x86_64 --version
  QEMU emulator version 5.0.0
  Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers
  ```

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

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

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


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

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

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 1862986] Re: qemu-s390x segfaults

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Tags added: s390x

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

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

Title:
  qemu-s390x segfaults

Status in QEMU:
  Incomplete

Bug description:
  All tested versions (2.11 and 4.2) qemu-s390x crashes with a segfault
  when run on an aarch64 odroid Ubuntu.


  Steps to reproduce:

  root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x 
"/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig"
  Segmentation fault (core dumped)
  root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x --version
  qemu-s390x version 4.2.0
  Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers
  root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-s390x 
"/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig"
  Segmentation fault (core dumped)
  root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-s390x --version
  qemu-s390x version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.22)
  Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

  qemu-arm does work on the same machine:

  root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-arm 
bitcoin-0.19.0.1-armhf/bin/test_bitcoin -t amount_tests
  Running 4 test cases...

  *** No errors detected
  root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-arm 
bitcoin-0.19.0.1-armhf/bin/test_bitcoin -t amount_tests
  Running 4 test cases...

  *** No errors detected


  
  What kind of debug information would be helpful for this issue report?
  GDB for the self-compiled latest release is not particularly helpful:

  (gdb) run
  Starting program: /usr/local/bin/qemu-s390x 
/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
  [New Thread 0x7fb7a2a140 (LWP 28264)]

  Thread 1 "qemu-s390x" received signal SIGSEGV, Segmentation fault.
  0x0096b218 in __bss_start__ ()
  (gdb) bt
  #0  0x0096b218 in __bss_start__ ()
  #1  0x006120a8 in ?? ()
  #2  0x0055579904b0 in ?? ()
  Backtrace stopped: previous frame inner to this frame (corrupt stack?)


  
  A bit more information is available in the version shipped by Ubuntu:

  (gdb) run
  Starting program: /usr/bin/qemu-s390x 
/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
  [New Thread 0x7fb7a01180 (LWP 28271)]

  Thread 1 "qemu-s390x" received signal SIGSEGV, Segmentation fault.
  0x00738f98 in code_gen_buffer ()
  (gdb) bt
  #0  0x00738f98 in code_gen_buffer ()
  #1  0x005e96c8 in cpu_exec ()
  #2  0x005ee430 in cpu_loop ()
  #3  0x005c3328 in main ()

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

[Bug 1869006] Re: PCIe cards passthrough to TCG guest works on 2GB of guest memory but fails on 4GB (vfio_dma_map invalid arg)

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


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

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

Title:
  PCIe cards passthrough to TCG guest works on 2GB of guest memory but
  fails on 4GB (vfio_dma_map invalid arg)

Status in QEMU:
  Incomplete

Bug description:
  During one meeting coworker asked "did someone tried to passthrough
  PCIe card to other arch guest?" and I decided to check it.

  Plugged SATA and USB3 controllers into spare slots on mainboard and
  started playing. On 1GB VM instance it worked (both cold- and hot-
  plugged). On 4GB one it did not:

  Błąd podczas uruchamiania domeny: internal error: process exited while 
connecting to monitor: 2020-03-25T13:43:39.107524Z qemu-system-aarch64: -device 
vfio-pci,host=:29:00.0,id=hostdev0,bus=pci.3,addr=0x0: VFIO_MAP_DMA: -22
  2020-03-25T13:43:39.107560Z qemu-system-aarch64: -device 
vfio-pci,host=:29:00.0,id=hostdev0,bus=pci.3,addr=0x0: vfio :29:00.0: 
failed to setup container for group 28: memory listener initialization failed: 
Region mach-virt.ram: vfio_dma_map(0x563169753c80, 0x4000, 0x1, 
0x7fb2a3e0) = -22 (Invalid argument)

  Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 75, in 
cb_wrapper
  callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 111, in tmpcb
  callback(*args, **kwargs)
File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 
66, in newfn
  ret = fn(self, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/object/domain.py", line 1279, in 
startup
  self._backend.create()
File "/usr/lib64/python3.8/site-packages/libvirt.py", line 1234, in create
  if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
  libvirt.libvirtError: internal error: process exited while connecting to 
monitor: 2020-03-25T13:43:39.107524Z qemu-system-aarch64: -device 
vfio-pci,host=:29:00.0,id=hostdev0,bus=pci.3,addr=0x0: VFIO_MAP_DMA: -22
  2020-03-25T13:43:39.107560Z qemu-system-aarch64: -device 
vfio-pci,host=:29:00.0,id=hostdev0,bus=pci.3,addr=0x0: vfio :29:00.0: 
failed to setup container for group 28: memory listener initialization failed: 
Region mach-virt.ram: vfio_dma_map(0x563169753c80, 0x4000, 0x1, 
0x7fb2a3e0) = -22 (Invalid argument)

  
  I played with memory and 3054 MB is maximum value possible to boot VM with 
coldplugged host PCIe cards.

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

[Bug 1862874] Re: java may stuck for a long time in system mode with "-cpu max"

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


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

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

Title:
  java may stuck for a long time in system mode with "-cpu max"

Status in QEMU:
  Incomplete

Bug description:
  Bug Description:
  Run "java -version" in guest VM, java may stuck for a long time (several 
hours) and then recover.

  Steps to reproduce:
  1. Launch VM by attached simple script: launch.sh
  2. Execute "java -version" and then print "date" in a loop
  while :
  do
/home/bot/jdk/bin/java -version
date
  done
  3. A long time gap will be observed: may > 24 hours.

  Technical details:
  * host: x86_64 Linux 4.15.0-70-generic
  * qemu v4.2.0
  * java: tried two versions: openjdk-11-jre-headless or compiled java-13 
  * command-line: (See details in launch.sh)
  /home/bot/qemu/qemu-build/qemu-4.2.0/binaries/bin/qemu-system-x86_64 \
-drive "file=${img},format=qcow2" \
-drive "file=${user_data},format=raw" \
-cpu max \
-m 24G \
-serial mon:stdio \
-smp 8 \
-nographic \
  ;

  * Observed by java core dump generated by "kill -SIGSEGV" when java stucked:
  Different pthreads are blocked on their own condition variables:

Id   Target Id Frame
1Thread 0x7f48a041a080 (LWP 22470) __GI_raise (sig=sig@entry=6)
  at ../sysdeps/unix/sysv/linux/raise.c:51
2Thread 0x7f487197d700 (LWP 22473) 0x7f489f5c49f3 in 
futex_wait_cancelable (private=, expected=0, 
futex_word=0x7f48980197c0)
  at ../sysdeps/unix/sysv/linux/futex-internal.h:88
3Thread 0x7f4861b89700 (LWP 22483) 0x7f489f5c4ed9 in 
futex_reltimed_wait_cancelable (private=, 
reltime=0x7f4861b88960, expected=0,
  futex_word=0x7f489801b084)
  at ../sysdeps/unix/sysv/linux/futex-internal.h:142
4Thread 0x7f4861e8c700 (LWP 22480) 0x7f489f5c76d6 in 
futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, 
futex_word=0x7f48980107c0)
  at ../sysdeps/unix/sysv/linux/futex-internal.h:205
5Thread 0x7f4861c8a700 (LWP 22482) 0x7f489f5c4ed9 in 
futex_reltimed_wait_cancelable (private=, 
reltime=0x7f4861c89800, expected=0,
  futex_word=0x7f489801ed44)
  at ../sysdeps/unix/sysv/linux/futex-internal.h:142
6Thread 0x7f48a0418700 (LWP 22471) 0x7f4880b13200 in ?? ()
7Thread 0x7f48703ea700 (LWP 22478) 0x7f489f5c49f3 in 
futex_wait_cancelable (private=, expected=0, 
futex_word=0x7f489801dfc0)
  at ../sysdeps/unix/sysv/linux/futex-internal.h:88
8Thread 0x7f48702e9700 (LWP 22479) 0x7f489f5c49f3 in 
futex_wait_cancelable (private=, expected=0, 
futex_word=0x7f489838cd84)
  at ../sysdeps/unix/sysv/linux/futex-internal.h:88
9Thread 0x7f4870f71700 (LWP 22475) 0x7f489f5c49f3 in 
futex_wait_cancelable (private=, expected=0, 
futex_word=0x7f489801a300)
  at ../sysdeps/unix/sysv/linux/futex-internal.h:88
10   Thread 0x7f487187b700 (LWP 22474) 0x7f489f5c76d6 in 
futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, 
futex_word=0x7f48980cf770)
  at ../sysdeps/unix/sysv/linux/futex-internal.h:205
11   Thread 0x7f4871a7f700 (LWP 22472) 0x7f489f5c76d6 in 
futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, 
futex_word=0x7f489809ba30)
  at ../sysdeps/unix/sysv/linux/futex-internal.h:205
12   Thread 0x7f4861d8b700 (LWP 22481) 0x7f489f5c4ed9 in 
futex_reltimed_wait_cancelable (private=, 
reltime=0x7f4861d8a680, expected=0,
  futex_word=0x7f489801ed44)
  at ../sysdeps/unix/sysv/linux/futex-internal.h:142
13   Thread 0x7f48704ec700

[Bug 1873769] Re: SB16 audio playback freezes emulation in Windows 95 guest

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


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

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

Title:
  SB16 audio playback freezes emulation in Windows 95 guest

Status in QEMU:
  Incomplete

Bug description:
  - QEMU 4.2.93 (v5.0.0-rc3) built from latest git master
  20038cd7a8412feeb49c01f6ede89e36c8995472 using MSYS2 on Windows 10 and
  launched on same Windows 10

  - Launched using "qemu-system-i386.exe -drive format=raw,file=hdd-
  2gb.img -soundhw pcspk,sb16 -m 16 -cpu pentium -vga std -cdrom
  Windows_95.iso -boot c"

  - I have attached video screen capture of the issue

  ---

  I decided to make my first ever QEMU build after encountering the
  dsound issues using the latest 4.2.0 binary from
  https://qemu.weilnetz.de/w64/. In my 5.0.0-rc3 build the sound
  playback is working correctly, however the whole Windows 95 UI freezes
  while sound is playing.

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

[Bug 1870331] Re: default nic device created even though supplied by configfile

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


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

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

Title:
  default nic device created even though supplied by configfile

Status in QEMU:
  Incomplete

Bug description:
  QEMU emulator version 4.1.94

  Documentation states that qemu will create a default nic as long as
  not explicitly forbidden (-nic none) or defined ( e.g. -nic
  ).

  Observation:
  Even though qemu-system-ppc is started with "-readconfig" (which defines a 
nic), another nic gets created. When additionally suppling "-nic none", only 
the nic of the config file is created.
  As matter of fact, if all items that are defined in config file are supplied 
as command line arguments, no further nic is created. 

  Expectation:
  When a nic is defined in config file, the default guest-nic should not get 
created.
  That would match behavior when all items, defined in config file are supplied 
as command line arguments.

  
  Attached config file.

  (qemu) info pci
   Bus 0, device 0, function 0:
   Host bridge: PCI device 1057:0002
   PCI subsystem 1af4:1100
   id ""
   Bus 0, device 1, function 0:
   VGA controller: PCI device 1234:
   PCI subsystem 1af4:1100
   BAR0: 32 bit prefetchable memory at 0x8000 [0x80ff].
   BAR2: 32 bit memory at 0x8100 [0x81000fff].
   BAR6: 32 bit memory at 0x [0xfffe].
   id ""
   Bus 0, device 2, function 0:
   Ethernet controller: PCI device 10ec:8029
   PCI subsystem 1af4:1100
   IRQ 23.
   BAR0: I/O at 0x1000 [0x10ff].
   BAR6: 32 bit memory at 0x [0x0007fffe].
   id ""
   Bus 0, device 3, function 0:
   Ethernet controller: PCI device 10ec:8029
   PCI subsystem 1af4:1100
   IRQ 24.
   BAR0: I/O at 0x1100 [0x11ff].
   BAR6: 32 bit memory at 0x [0x0007fffe].
   id ""

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

[Bug 1705118] Re: qemu user mode: rt signals not implemented for sparc guests

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


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

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

Title:
  qemu user mode: rt signals not implemented for sparc guests

Status in QEMU:
  Incomplete

Bug description:
  The documentation
   says that
  qemu in user mode supports POSIX signal handling.

  Catching SIGSEGV according to POSIX, however, does not work on
ppc, ppc64, ppc64le, s390x, sparc64.
  It does work, however, on
aarch64, alpha, arm, hppa, m68k, mips, mips64, sh4.

  How to reproduce:
  The attached program runs fine (exits with code 0) on
- real hardware Linux/PowerPC64 (in 32-bit and 64-bit mode),
- real hardware Linux/PowerPC64LE,
- qemu-system-s390x emulated Linux/s390x,
- real hardware Linux/SPARC64.
  $ gcc -O -Wall testsigsegv.c; ./a.out; echo $?
  0

  For ppc:
  $ powerpc-linux-gnu-gcc-5 -O -Wall -static testsigsegv.c -o testsigsegv-ppc
  $ ~/inst-qemu/2.9.0/bin/qemu-ppc testsigsegv-ppc
  $ echo $?
  3

  For ppc64:
  $ powerpc64-linux-gnu-gcc-5 -O -Wall -static testsigsegv.c -o 
testsigsegv-ppc64
  $ ~/inst-qemu/2.9.0/bin/qemu-ppc64 testsigsegv-ppc64
  $ echo $?
  3

  For ppc64le:
  $ powerpc64le-linux-gnu-gcc-5 -O -Wall -static testsigsegv.c -o 
testsigsegv-ppc64le
  $ ~/inst-qemu/2.9.0/bin/qemu-ppc64le testsigsegv-ppc64le
  $ echo $?
  3

  For s390x:
  $ s390x-linux-gnu-gcc-5 -O -Wall -static testsigsegv.c -o testsigsegv-s390x
  $ ~/inst-qemu/2.9.0/bin/qemu-s390x testsigsegv-s390x
  $ echo $?
  3
  $ s390x-linux-gnu-gcc-5 -O -Wall -static testsigsegv.c 
-DAVOID_LINUX_S390X_COMPAT -o testsigsegv-s390x-a
  $ ~/inst-qemu/2.9.0/bin/qemu-s390x testsigsegv-s390x-a
  $ echo $?
  0
  So, the test fails here because the Linux/s390x kernel omits the least
  significant 12 bits of the fault address in the 'si_addr' field. But
  qemu-s390x is not compatible with the Linux/s390x behaviour: it puts
  the complete fault address in the 'si_addr' field.

  For sparc64:
  $ sparc64-linux-gnu-gcc-5 -O -Wall -static testsigsegv.c -o 
testsigsegv-sparc64
  $ ~/inst-qemu/2.9.0/bin/qemu-sparc64 testsigsegv-sparc64
  Segmentation fault (core dumped)

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

[Bug 1785734] Re: movdqu partial write at page boundary

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


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

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

Title:
  movdqu partial write at page boundary

Status in QEMU:
  Incomplete

Bug description:
  In TCG mode, when a 16-byte write instruction (such as movdqu) is
  executed at a page boundary and causes a page fault, a partial write
  is executed in the first page. See the attached code for an example.

  Tested on the qemu-3.0.0-rc1 release.

  % gcc -m32 qemu-bug2.c && ./a.out && echo && qemu-i386 ./a.out
  [snip]
  page fault: addr=0x70001000 err=0x7
  *(0x7ff8+ 0) = aa
  *(0x7ff8+ 1) = aa
  *(0x7ff8+ 2) = aa
  *(0x7ff8+ 3) = aa
  *(0x7ff8+ 4) = aa
  *(0x7ff8+ 5) = aa
  *(0x7ff8+ 6) = aa
  *(0x7ff8+ 7) = aa
  *(0x7ff8+ 8) = 55
  *(0x7ff8+ 9) = 55
  *(0x7ff8+10) = 55
  *(0x7ff8+11) = 55
  *(0x7ff8+12) = 55
  *(0x7ff8+13) = 55
  *(0x7ff8+14) = 55
  *(0x7ff8+15) = 55

  [snip]
  page fault: addr=0x70001000 err=0x6
  *(0x7ff8+ 0) = 77
  *(0x7ff8+ 1) = 66
  *(0x7ff8+ 2) = 55
  *(0x7ff8+ 3) = 44
  *(0x7ff8+ 4) = 33
  *(0x7ff8+ 5) = 22
  *(0x7ff8+ 6) = 11
  *(0x7ff8+ 7) = 0
  *(0x7ff8+ 8) = 55
  *(0x7ff8+ 9) = 55
  *(0x7ff8+10) = 55
  *(0x7ff8+11) = 55
  *(0x7ff8+12) = 55
  *(0x7ff8+13) = 55
  *(0x7ff8+14) = 55
  *(0x7ff8+15) = 55

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

[Bug 1779955] Re: qemu linux-user requires read permissions on memory passed to syscalls that should only need write access

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


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

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

Title:
  qemu linux-user requires read permissions on memory passed to syscalls
  that should only need write access

Status in QEMU:
  Incomplete

Bug description:
  When read() function takes an mmap'ed address as output buffer, it
  returns EFAULT. The expected behavior is it should just work.

  The following code works for qemu-system-arm, but not for qemu-arm-
  static.

  QEMU version affected: latest release 2.12.0.

  Steps to reproduce (please substitute /path/to/qemu-arm-static with
  the path of the binary, and /tmp/a.cpp with the example source code
  attached):

  # First register binfmt_misc
  [hidden]$ docker run --rm --privileged multiarch/qemu-user-static:register 
--reset

  # Compile the code and run
  [hidden]$ docker run --rm -it -v /tmp/a.cpp:/tmp/a.cpp -v 
/path/to/qemu-arm-static:/usr/bin/qemu-arm-static arm32v7/ubuntu:18.04 bash -c 
'{ apt update -y && apt install -y g++; } >& /dev/null && g++ -std=c++14 
/tmp/a.cpp -o /tmp/a.out && echo hehe > /tmp/haha.txt && /tmp/a.out'
  ofd=3
  ftruncate=0
  mmap=0xff3f5000
  fd=4
  0xff3f5023 -1 14

  The expected result in qemu-system-arm as well as natively on x86_64 host:
  hidden$ ./a.out
  ofd=3
  ftruncate=0
  mmap=0xb6fb7000
  fd=4
  0xb6fb7023 5 0

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

[Bug 1819182] Re: info does not recognize file format of vpc with subformat=fixed

** Changed in: qemu
   Status: Confirmed => In Progress

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

Title:
  info does not recognize file format of vpc with subformat=fixed

Status in QEMU:
  In Progress

Bug description:
  After creating or converting an image to vpc with 'subformat=fixed'
  'qemu-img info' incorrectly identifies the image as 'raw' format.

  $ qemu-img --version
  qemu-img version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.10)
  Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

  $ qemu-img create -f vpc -o subformat=fixed my.vpc 2G
  Formatting 'my.vpc', fmt=vpc size=2147483648 subformat=fixed

  $ qemu-img info my.vpc
  image: my.vpc
  file format: raw
  virtual size: 2.0G (2147992064 bytes)
  disk size: 4.0K

  $ qemu-img info -f vpc my.vpc
  image: my.vpc
  file format: vpc
  virtual size: 2.0G (2147991552 bytes)
  disk size: 4.0K

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

[Bug 1878501] Re: qemu-i386 does not define AT_SYSINFO

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


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

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

Title:
  qemu-i386 does not define AT_SYSINFO

Status in QEMU:
  Incomplete

Bug description:
  qemu-i386 does not define the AT_SYSINFO auxval when running i386
  Linux binaries.

  On most libcs, this is properly handled, but this is mandatory for the
  i686 Bionic (Android) libc or it will segfault.

  This is due to a blind assumption that getauxval(AT_SYSINFO) will
  return a valid function pointer:

  The code varies from version to version, but it looks like this:

  void *__libc_sysinfo;
  // mangled as _Z19__libc_init_sysinfov
  void __libc_init_sysinfo() {
bool dummy;
// __bionic_getauxval = getauxval
__libc_sysinfo = reinterpret_cast(__bionic_getauxval(AT_SYSINFO, 
dummy));
  }

  A simple way to reproduce is to compile a basic C program against the
  NDK:

  int main(void) { return 0; }

  $ i686-linux-android-clang -static empty.c -o empty
  $ qemu-i386 -cpu max ./empty
  qemu: uncaught target signal 11 (Segmentation fault) - core dumped
  Segmentation fault

  The place where it segfaults is misleading: It will, at least on the
  current NDK, crash on __set_thread_area, this is due to it calling a
  function pointer to __libc_sysinfo returned by __kernel_syscall.

  QEMU 4.1.1 (aarch64)
  Pixel 2 XL via Termux

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

[Bug 1886210] Re: [Feature request] Illumnos VM image

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'invalid' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/258


** Changed in: qemu
   Status: New => Invalid

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #258
   https://gitlab.com/qemu-project/qemu/-/issues/258

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

Title:
  [Feature request] Illumnos VM image

Status in QEMU:
  Invalid

Bug description:
  We already have handy VMs to build QEMU within:

  $ git grep -l basevm.BaseVM
  tests/vm/centos
  tests/vm/fedora
  tests/vm/freebsd
  tests/vm/netbsd
  tests/vm/openbsd
  tests/vm/ubuntu.i386

  It would be useful to have a illumos VM to do build testing and avoid
  regressions.

  Suggested by Thomas Huth:
  https://www.mail-archive.com/qemu-devel@nongnu.org/msg719202.html

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

[PATCH v2 5/6] hw/ide/via: Connect IDE function output IRQs to the ISA function input

To avoid abusing isa_get_irq(NULL) using a hidden ISA bridge
under the hood, let the IDE function expose 2 output IRQs,
and connect them to the ISA function inputs when creating
the south bridge chipset model in vt82c686b_southbridge_init.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/ide/via.c| 19 +--
 hw/mips/fuloong2e.c |  9 -
 2 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/hw/ide/via.c b/hw/ide/via.c
index 6c667a92130..7887bf181e6 100644
--- a/hw/ide/via.c
+++ b/hw/ide/via.c
@@ -33,6 +33,17 @@
 #include "hw/ide/pci.h"
 #include "trace.h"
 
+#define TYPE_VIA_IDE "via-ide"
+OBJECT_DECLARE_SIMPLE_TYPE(VIAIDEState, VIA_IDE)
+
+struct VIAIDEState {
+/*  */
+PCIIDEState parent_obj;
+/*  */
+
+qemu_irq irq[2];
+};
+
 static uint64_t bmdma_read(void *opaque, hwaddr addr,
unsigned size)
 {
@@ -105,6 +116,7 @@ static void bmdma_setup_bar(PCIIDEState *d)
 static void via_ide_set_irq(void *opaque, int n, int level)
 {
 PCIDevice *d = PCI_DEVICE(opaque);
+VIAIDEState *s = VIA_IDE(d);
 
 if (level) {
 d->config[0x70 + n * 8] |= 0x80;
@@ -112,7 +124,7 @@ static void via_ide_set_irq(void *opaque, int n, int level)
 d->config[0x70 + n * 8] &= ~0x80;
 }
 
-qemu_set_irq(isa_get_irq(NULL, 14 + n), level);
+qemu_set_irq(s->irq[n], level);
 }
 
 static void via_ide_reset(DeviceState *dev)
@@ -159,6 +171,7 @@ static void via_ide_reset(DeviceState *dev)
 
 static void via_ide_realize(PCIDevice *dev, Error **errp)
 {
+VIAIDEState *s = VIA_IDE(dev);
 PCIIDEState *d = PCI_IDE(dev);
 DeviceState *ds = DEVICE(dev);
 uint8_t *pci_conf = dev->config;
@@ -188,6 +201,7 @@ static void via_ide_realize(PCIDevice *dev, Error **errp)
 bmdma_setup_bar(d);
 pci_register_bar(dev, 4, PCI_BASE_ADDRESS_SPACE_IO, >bmdma_bar);
 
+qdev_init_gpio_out_named(ds, s->irq, "ide-irq", ARRAY_SIZE(s->irq));
 qdev_init_gpio_in(ds, via_ide_set_irq, ARRAY_SIZE(d->bus));
 for (i = 0; i < ARRAY_SIZE(d->bus); i++) {
 ide_bus_new(>bus[i], sizeof(d->bus[i]), ds, i, MAX_IDE_DEVS);
@@ -227,8 +241,9 @@ static void via_ide_class_init(ObjectClass *klass, void 
*data)
 }
 
 static const TypeInfo via_ide_info = {
-.name  = "via-ide",
+.name  = TYPE_VIA_IDE,
 .parent= TYPE_PCI_IDE,
+.instance_size = sizeof(VIAIDEState),
 .class_init= via_ide_class_init,
 };
 
diff --git a/hw/mips/fuloong2e.c b/hw/mips/fuloong2e.c
index 3e7a7e4389d..17b5e41cc7d 100644
--- a/hw/mips/fuloong2e.c
+++ b/hw/mips/fuloong2e.c
@@ -201,12 +201,19 @@ static void vt82c686b_southbridge_init(PCIBus *pci_bus, 
int slot, qemu_irq intc,
I2CBus **i2c_bus)
 {
 PCIDevice *dev;
+DeviceState *isa;
 
 dev = pci_create_simple_multifunction(pci_bus, PCI_DEVFN(slot, 0), true,
   TYPE_VT82C686B_ISA);
-qdev_connect_gpio_out_named(DEVICE(dev), "intr", 0, intc);
+isa = DEVICE(dev);
+qdev_connect_gpio_out_named(isa, "intr", 0, intc);
 
 dev = pci_create_simple(pci_bus, PCI_DEVFN(slot, 1), "via-ide");
+for (unsigned i = 0; i < 2; i++) {
+qdev_connect_gpio_out_named(DEVICE(dev), "ide-irq", i,
+qdev_get_gpio_in_named(isa,
+   "isa-irq", 14 + i));
+}
 pci_ide_create_devs(dev);
 
 pci_create_simple(pci_bus, PCI_DEVFN(slot, 2), "vt82c686b-usb-uhci");
-- 
2.26.3

[PATCH v2 3/6] hw/isa/vt82c686: Let ISA function expose ISA IRQs

The 2 cascaded 8259 PIC are managed by the PCI function #0
(ISA bridge). Expose the 16 IRQs on this function, so other
functions from the same chipset can access them.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/isa/vt82c686.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/hw/isa/vt82c686.c b/hw/isa/vt82c686.c
index 2ce5c6cbb00..388833f4eb1 100644
--- a/hw/isa/vt82c686.c
+++ b/hw/isa/vt82c686.c
@@ -542,6 +542,7 @@ OBJECT_DECLARE_SIMPLE_TYPE(ViaISAState, VIA_ISA)
 struct ViaISAState {
 PCIDevice dev;
 qemu_irq cpu_intr;
+qemu_irq *pic_irq;
 ViaSuperIOState *via_sio;
 };
 
@@ -601,6 +602,13 @@ static void vt82c686b_isa_reset(DeviceState *dev)
 pci_conf[0x77] = 0x10; /* GPIO Control 1/2/3/4 */
 }
 
+static void vt82c686b_isa_irq(void *opaque, int irq, int level)
+{
+ViaISAState *s = opaque;
+
+qemu_set_irq(s->pic_irq[irq], level);
+}
+
 static void vt82c686b_realize(PCIDevice *d, Error **errp)
 {
 ViaISAState *s = VIA_ISA(d);
@@ -611,7 +619,10 @@ static void vt82c686b_realize(PCIDevice *d, Error **errp)
 qdev_init_gpio_out_named(dev, >cpu_intr, "intr", 1);
 isa_bus = isa_bus_new(dev, get_system_memory(), pci_address_space_io(d),
   _fatal);
-isa_bus_irqs(isa_bus, i8259_init(isa_bus, s->cpu_intr));
+s->pic_irq = i8259_init(isa_bus, s->cpu_intr);
+isa_bus_irqs(isa_bus, s->pic_irq);
+qdev_init_gpio_in_named(dev, vt82c686b_isa_irq, "isa-irq", ISA_NUM_IRQS);
+
 i8254_pit_init(isa_bus, 0x40, 0, NULL);
 i8257_dma_init(isa_bus, 0);
 s->via_sio = VIA_SUPERIO(isa_create_simple(isa_bus,
-- 
2.26.3

[PATCH v2 4/6] hw/ide/via: Replace magic 2 value by ARRAY_SIZE / MAX_IDE_DEVS

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/ide/via.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/hw/ide/via.c b/hw/ide/via.c
index be09912b334..6c667a92130 100644
--- a/hw/ide/via.c
+++ b/hw/ide/via.c
@@ -90,7 +90,7 @@ static void bmdma_setup_bar(PCIIDEState *d)
 int i;
 
 memory_region_init(>bmdma_bar, OBJECT(d), "via-bmdma-container", 16);
-for(i = 0;i < 2; i++) {
+for (i = 0; i < ARRAY_SIZE(d->bmdma); i++) {
 BMDMAState *bm = >bmdma[i];
 
 memory_region_init_io(>extra_io, OBJECT(d), _bmdma_ops, bm,
@@ -122,7 +122,7 @@ static void via_ide_reset(DeviceState *dev)
 uint8_t *pci_conf = pd->config;
 int i;
 
-for (i = 0; i < 2; i++) {
+for (i = 0; i < ARRAY_SIZE(d->bus); i++) {
 ide_bus_reset(>bus[i]);
 }
 
@@ -188,9 +188,9 @@ static void via_ide_realize(PCIDevice *dev, Error **errp)
 bmdma_setup_bar(d);
 pci_register_bar(dev, 4, PCI_BASE_ADDRESS_SPACE_IO, >bmdma_bar);
 
-qdev_init_gpio_in(ds, via_ide_set_irq, 2);
-for (i = 0; i < 2; i++) {
-ide_bus_new(>bus[i], sizeof(d->bus[i]), ds, i, 2);
+qdev_init_gpio_in(ds, via_ide_set_irq, ARRAY_SIZE(d->bus));
+for (i = 0; i < ARRAY_SIZE(d->bus); i++) {
+ide_bus_new(>bus[i], sizeof(d->bus[i]), ds, i, MAX_IDE_DEVS);
 ide_init2(>bus[i], qdev_get_gpio_in(ds, i));
 
 bmdma_init(>bus[i], >bmdma[i], d);
@@ -204,7 +204,7 @@ static void via_ide_exitfn(PCIDevice *dev)
 PCIIDEState *d = PCI_IDE(dev);
 unsigned i;
 
-for (i = 0; i < 2; ++i) {
+for (i = 0; i < ARRAY_SIZE(d->bmdma); ++i) {
 memory_region_del_subregion(>bmdma_bar, >bmdma[i].extra_io);
 memory_region_del_subregion(>bmdma_bar, >bmdma[i].addr_ioport);
 }
-- 
2.26.3

[PATCH v2 6/6] hw/southbridge/vt82c686: Introduce VT82C686B_SOUTHBRIDGE

The VT82C686B south bridge is a single chipset. Model
it as a single sysbus device.
Move the vt82c686b_southbridge_init as via_southbridge_realize,
add the QOM state: ViaSouthBridgeState. This device needs 2
properties to be realized: the PCI bus and its slot number.
2 aliases are exposed: the ISA PIC output IRQ and the I2C bus.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/mips/fuloong2e.c|  42 +++
 hw/southbridge/vt82c686.c  | 107 +
 MAINTAINERS|   1 +
 hw/Kconfig |   1 +
 hw/isa/Kconfig |   9 
 hw/meson.build |   1 +
 hw/southbridge/Kconfig |   8 +++
 hw/southbridge/meson.build |   1 +
 8 files changed, 127 insertions(+), 43 deletions(-)
 create mode 100644 hw/southbridge/vt82c686.c
 create mode 100644 hw/southbridge/Kconfig
 create mode 100644 hw/southbridge/meson.build

diff --git a/hw/mips/fuloong2e.c b/hw/mips/fuloong2e.c
index 17b5e41cc7d..00aa085b982 100644
--- a/hw/mips/fuloong2e.c
+++ b/hw/mips/fuloong2e.c
@@ -34,10 +34,8 @@
 #include "hw/mips/cpudevs.h"
 #include "hw/pci/pci.h"
 #include "hw/loader.h"
-#include "hw/ide/pci.h"
 #include "hw/qdev-properties.h"
 #include "elf.h"
-#include "hw/isa/vt82c686.h"
 #include "sysemu/qtest.h"
 #include "sysemu/reset.h"
 #include "sysemu/sysemu.h"
@@ -197,36 +195,6 @@ static void main_cpu_reset(void *opaque)
 }
 }
 
-static void vt82c686b_southbridge_init(PCIBus *pci_bus, int slot, qemu_irq 
intc,
-   I2CBus **i2c_bus)
-{
-PCIDevice *dev;
-DeviceState *isa;
-
-dev = pci_create_simple_multifunction(pci_bus, PCI_DEVFN(slot, 0), true,
-  TYPE_VT82C686B_ISA);
-isa = DEVICE(dev);
-qdev_connect_gpio_out_named(isa, "intr", 0, intc);
-
-dev = pci_create_simple(pci_bus, PCI_DEVFN(slot, 1), "via-ide");
-for (unsigned i = 0; i < 2; i++) {
-qdev_connect_gpio_out_named(DEVICE(dev), "ide-irq", i,
-qdev_get_gpio_in_named(isa,
-   "isa-irq", 14 + i));
-}
-pci_ide_create_devs(dev);
-
-pci_create_simple(pci_bus, PCI_DEVFN(slot, 2), "vt82c686b-usb-uhci");
-pci_create_simple(pci_bus, PCI_DEVFN(slot, 3), "vt82c686b-usb-uhci");
-
-dev = pci_create_simple(pci_bus, PCI_DEVFN(slot, 4), TYPE_VT82C686B_PM);
-*i2c_bus = I2C_BUS(qdev_get_child_bus(DEVICE(dev), "i2c"));
-
-/* Audio support */
-pci_create_simple(pci_bus, PCI_DEVFN(slot, 5), TYPE_VIA_AC97);
-pci_create_simple(pci_bus, PCI_DEVFN(slot, 6), TYPE_VIA_MC97);
-}
-
 /* Network support */
 static void network_init(PCIBus *pci_bus)
 {
@@ -323,8 +291,14 @@ static void mips_fuloong2e_init(MachineState *machine)
 pci_bus = bonito_init((qemu_irq *)&(env->irq[2]));
 
 /* South bridge -> IP5 */
-vt82c686b_southbridge_init(pci_bus, FULOONG2E_VIA_SLOT, env->irq[5],
-   );
+dev = qdev_new("vt82c686b-southbridge");
+object_property_set_uint(OBJECT(dev), "pci-slot",
+ FULOONG2E_VIA_SLOT, _fatal);
+object_property_set_link(OBJECT(dev), "pci-bus",
+ OBJECT(pci_bus), _fatal);
+sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), _fatal);
+qdev_connect_gpio_out_named(dev, "intr", 0, env->irq[5]);
+smbus = I2C_BUS(qdev_get_child_bus(dev, "i2c"));
 
 /* GPU */
 if (vga_interface_type != VGA_NONE) {
diff --git a/hw/southbridge/vt82c686.c b/hw/southbridge/vt82c686.c
new file mode 100644
index 000..61c3e6ae306
--- /dev/null
+++ b/hw/southbridge/vt82c686.c
@@ -0,0 +1,107 @@
+/*
+ * VT82C686B south bridge emulation
+ *
+ * Copyright (c) 2008 yajin (ya...@vm-kernel.org)
+ * Copyright (c) 2009 chenming (chenm...@rdc.faw.com.cn)
+ * Copyright (c) 2010 Huacai Chen (zltjiang...@gmail.com)
+ * Copyright (c) 2021 Philippe Mathieu-Daudé 
+ * This code is licensed under the GNU GPL v2.
+ */
+
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "hw/qdev-properties.h"
+#include "hw/sysbus.h"
+#include "hw/pci/pci.h"
+#include "hw/ide/pci.h"
+#include "hw/isa/vt82c686.h"
+
+#define TYPE_VT82C686B_SOUTHBRIDGE "vt82c686b-southbridge"
+OBJECT_DECLARE_SIMPLE_TYPE(ViaSouthBridgeState, VT82C686B_SOUTHBRIDGE)
+
+struct ViaSouthBridgeState {
+/*  */
+SysBusDevice parent_obj;
+/*  */
+
+uint8_t pci_slot;
+PCIBus *pci_bus;
+PCIDevice *isa;
+PCIDevice *ide;
+PCIDevice *usb[2];
+PCIDevice *apm;
+PCIDevice *audio;
+PCIDevice *modem;
+};
+
+static void via_southbridge_realize(DeviceState *dev, Error **errp)
+{
+ViaSouthBridgeState *s = VT82C686B_SOUTHBRIDGE(dev);
+
+if (!s->pci_bus) {
+error_setg(errp, "SMMU is not attached to any PCI bus!");
+return;
+}
+
+s->isa = pci_create_simple_multifunction(s->pci_bus,
+ PCI_DEVFN(s->pci_slot, 0),
+

[PATCH v2 2/6] hw/isa/vt82c686: Simplify removing unuseful qemu_allocate_irqs() call

Instead of creating an input IRQ with qemu_allocate_irqs()
to pass it as output IRQ of the PIC, with its handler simply
dispatching into the "intr" output IRQ, simplify by directly
connecting the PIC to the "intr" named output.

Fixes: 3dc31cb8490 ("vt82c686: Move creation of ISA devices to the ISA bridge")
Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/isa/vt82c686.c | 14 ++
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/hw/isa/vt82c686.c b/hw/isa/vt82c686.c
index b177016125d..2ce5c6cbb00 100644
--- a/hw/isa/vt82c686.c
+++ b/hw/isa/vt82c686.c
@@ -566,12 +566,6 @@ static const TypeInfo via_isa_info = {
 },
 };
 
-static void via_isa_request_i8259_irq(void *opaque, int irq, int level)
-{
-ViaISAState *s = opaque;
-qemu_set_irq(s->cpu_intr, level);
-}
-
 /* TYPE_VT82C686B_ISA */
 
 static void vt82c686b_write_config(PCIDevice *d, uint32_t addr,
@@ -612,14 +606,12 @@ static void vt82c686b_realize(PCIDevice *d, Error **errp)
 ViaISAState *s = VIA_ISA(d);
 DeviceState *dev = DEVICE(d);
 ISABus *isa_bus;
-qemu_irq *isa_irq;
 int i;
 
 qdev_init_gpio_out_named(dev, >cpu_intr, "intr", 1);
-isa_irq = qemu_allocate_irqs(via_isa_request_i8259_irq, s, 1);
 isa_bus = isa_bus_new(dev, get_system_memory(), pci_address_space_io(d),
   _fatal);
-isa_bus_irqs(isa_bus, i8259_init(isa_bus, *isa_irq));
+isa_bus_irqs(isa_bus, i8259_init(isa_bus, s->cpu_intr));
 i8254_pit_init(isa_bus, 0x40, 0, NULL);
 i8257_dma_init(isa_bus, 0);
 s->via_sio = VIA_SUPERIO(isa_create_simple(isa_bus,
@@ -693,14 +685,12 @@ static void vt8231_realize(PCIDevice *d, Error **errp)
 ViaISAState *s = VIA_ISA(d);
 DeviceState *dev = DEVICE(d);
 ISABus *isa_bus;
-qemu_irq *isa_irq;
 int i;
 
 qdev_init_gpio_out(dev, >cpu_intr, 1);
-isa_irq = qemu_allocate_irqs(via_isa_request_i8259_irq, s, 1);
 isa_bus = isa_bus_new(dev, get_system_memory(), pci_address_space_io(d),
   _fatal);
-isa_bus_irqs(isa_bus, i8259_init(isa_bus, *isa_irq));
+isa_bus_irqs(isa_bus, i8259_init(isa_bus, s->cpu_intr));
 i8254_pit_init(isa_bus, 0x40, 0, NULL);
 i8257_dma_init(isa_bus, 0);
 s->via_sio = VIA_SUPERIO(isa_create_simple(isa_bus, TYPE_VT8231_SUPERIO));
-- 
2.26.3

[PATCH v2 1/6] hw/isa/vt82c686: Name output IRQ as 'intr'

Named IRQs are easier to understand in the monitor.
Name the single output interrupt as 'intr'.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/isa/vt82c686.c   | 2 +-
 hw/mips/fuloong2e.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/isa/vt82c686.c b/hw/isa/vt82c686.c
index f57f3e70679..b177016125d 100644
--- a/hw/isa/vt82c686.c
+++ b/hw/isa/vt82c686.c
@@ -615,7 +615,7 @@ static void vt82c686b_realize(PCIDevice *d, Error **errp)
 qemu_irq *isa_irq;
 int i;
 
-qdev_init_gpio_out(dev, >cpu_intr, 1);
+qdev_init_gpio_out_named(dev, >cpu_intr, "intr", 1);
 isa_irq = qemu_allocate_irqs(via_isa_request_i8259_irq, s, 1);
 isa_bus = isa_bus_new(dev, get_system_memory(), pci_address_space_io(d),
   _fatal);
diff --git a/hw/mips/fuloong2e.c b/hw/mips/fuloong2e.c
index c1b8066a13b..3e7a7e4389d 100644
--- a/hw/mips/fuloong2e.c
+++ b/hw/mips/fuloong2e.c
@@ -204,7 +204,7 @@ static void vt82c686b_southbridge_init(PCIBus *pci_bus, int 
slot, qemu_irq intc,
 
 dev = pci_create_simple_multifunction(pci_bus, PCI_DEVFN(slot, 0), true,
   TYPE_VT82C686B_ISA);
-qdev_connect_gpio_out(DEVICE(dev), 0, intc);
+qdev_connect_gpio_out_named(DEVICE(dev), "intr", 0, intc);
 
 dev = pci_create_simple(pci_bus, PCI_DEVFN(slot, 1), "via-ide");
 pci_ide_create_devs(dev);
-- 
2.26.3

[PATCH v2 0/6] hw/southbridge: QOM'ify vt82c686 as VT82C686B_SOUTHBRIDGE

The motivation behind this series is to remove the
isa_get_irq(NULL) call to simplify the ISA generic model.

Since v1:
- rebased on top of remotes/dg-gitlab/tags/ppc-for-6.1-20210504

Philippe Mathieu-Daudé (6):
  hw/isa/vt82c686: Name output IRQ as 'intr'
  hw/isa/vt82c686: Simplify removing unuseful qemu_allocate_irqs() call
  hw/isa/vt82c686: Let ISA function expose ISA IRQs
  hw/ide/via: Replace magic 2 value by ARRAY_SIZE / MAX_IDE_DEVS
  hw/ide/via: Connect IDE function output IRQs to the ISA function input
  hw/southbridge/vt82c686: Introduce VT82C686B_SOUTHBRIDGE

 hw/ide/via.c   |  31 ---
 hw/isa/vt82c686.c  |  27 +-
 hw/mips/fuloong2e.c|  35 +++-
 hw/southbridge/vt82c686.c  | 107 +
 MAINTAINERS|   1 +
 hw/Kconfig |   1 +
 hw/isa/Kconfig |   9 
 hw/meson.build |   1 +
 hw/southbridge/Kconfig |   8 +++
 hw/southbridge/meson.build |   1 +
 10 files changed, 164 insertions(+), 57 deletions(-)
 create mode 100644 hw/southbridge/vt82c686.c
 create mode 100644 hw/southbridge/Kconfig
 create mode 100644 hw/southbridge/meson.build

-- 
2.26.3

[PATCH v2 3/4] hw/isa/i82378: Rename output IRQ variable

The i82378 has 2 output IRQs: "INT" and "NMI".
We do not model the NMI, so simplify I82378State by
removing the unused IRQ. To avoid keeping an array of
one element, remove the array and rename the variable.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/isa/i82378.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/hw/isa/i82378.c b/hw/isa/i82378.c
index 817eca47053..164d6c65f64 100644
--- a/hw/isa/i82378.c
+++ b/hw/isa/i82378.c
@@ -32,7 +32,7 @@ OBJECT_DECLARE_SIMPLE_TYPE(I82378State, I82378)
 struct I82378State {
 PCIDevice parent_obj;
 
-qemu_irq out[2];
+qemu_irq intr;
 qemu_irq *i8259;
 MemoryRegion io;
 };
@@ -88,7 +88,7 @@ static void i82378_realize(PCIDevice *pci, Error **errp)
  */
 
 /* 2 82C59 (irq) */
-s->i8259 = i8259_init(isabus, s->out[0]);
+s->i8259 = i8259_init(isabus, s->intr);
 isa_bus_irqs(isabus, s->i8259);
 
 /* 1 82C54 (pit) */
@@ -106,7 +106,7 @@ static void i82378_init(Object *obj)
 DeviceState *dev = DEVICE(obj);
 I82378State *s = I82378(obj);
 
-qdev_init_gpio_out_named(dev, s->out, "intr", 1);
+qdev_init_gpio_out_named(dev, >intr, "intr", 1);
 qdev_init_gpio_in(dev, i82378_request_pic_irq, 16);
 }
 
-- 
2.26.3

[PATCH v2 2/4] hw/isa/i82378: Simplify removing unuseful qemu_allocate_irqs() call

When the i82378 model was added in commit a04ff940974 ("prep:
Add i82378 PCI-to-ISA bridge emulation") the i8259 model was
not yet QOM'ified. This happened later in commit 747c70af78f
("i8259: Convert to qdev").

Instead of creating an input IRQ with qemu_allocate_irqs()
to pass it as output IRQ of the PIC, with its handler simply
dispatching into the "intr" output IRQ, we can now simplify
and directly connect the PIC to the "intr" named output.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/isa/i82378.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/hw/isa/i82378.c b/hw/isa/i82378.c
index fd296c8ed7a..817eca47053 100644
--- a/hw/isa/i82378.c
+++ b/hw/isa/i82378.c
@@ -47,12 +47,6 @@ static const VMStateDescription vmstate_i82378 = {
 },
 };
 
-static void i82378_request_out0_irq(void *opaque, int irq, int level)
-{
-I82378State *s = opaque;
-qemu_set_irq(s->out[0], level);
-}
-
 static void i82378_request_pic_irq(void *opaque, int irq, int level)
 {
 DeviceState *dev = opaque;
@@ -94,8 +88,7 @@ static void i82378_realize(PCIDevice *pci, Error **errp)
  */
 
 /* 2 82C59 (irq) */
-s->i8259 = i8259_init(isabus,
-  qemu_allocate_irq(i82378_request_out0_irq, s, 0));
+s->i8259 = i8259_init(isabus, s->out[0]);
 isa_bus_irqs(isabus, s->i8259);
 
 /* 1 82C54 (pit) */
-- 
2.26.3

[PATCH v2 1/4] hw/isa/i82378: Name output IRQ as 'intr'

Named IRQs are easier to understand in the monitor.
Name the single output interrupt as 'intr'.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/isa/i82378.c | 2 +-
 hw/ppc/prep.c   | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/hw/isa/i82378.c b/hw/isa/i82378.c
index 2a2ff05b937..fd296c8ed7a 100644
--- a/hw/isa/i82378.c
+++ b/hw/isa/i82378.c
@@ -113,7 +113,7 @@ static void i82378_init(Object *obj)
 DeviceState *dev = DEVICE(obj);
 I82378State *s = I82378(obj);
 
-qdev_init_gpio_out(dev, s->out, 1);
+qdev_init_gpio_out_named(dev, s->out, "intr", 1);
 qdev_init_gpio_in(dev, i82378_request_pic_irq, 16);
 }
 
diff --git a/hw/ppc/prep.c b/hw/ppc/prep.c
index acfc2a91d8e..f19ec612956 100644
--- a/hw/ppc/prep.c
+++ b/hw/ppc/prep.c
@@ -280,8 +280,8 @@ static void ibm_40p_init(MachineState *machine)
 
 /* PCI -> ISA bridge */
 i82378_dev = DEVICE(pci_create_simple(pci_bus, PCI_DEVFN(11, 0), 
"i82378"));
-qdev_connect_gpio_out(i82378_dev, 0,
-  cpu->env.irq_inputs[PPC6xx_INPUT_INT]);
+qdev_connect_gpio_out_named(i82378_dev, "intr", 0,
+cpu->env.irq_inputs[PPC6xx_INPUT_INT]);
 sysbus_connect_irq(pcihost, 0, qdev_get_gpio_in(i82378_dev, 15));
 isa_bus = ISA_BUS(qdev_get_child_bus(i82378_dev, "isa.0"));
 
-- 
2.26.3

[PATCH v2 4/4] hw/isa/piix4: Fix leak removing unuseful qemu_allocate_irqs() call

We locally create an input IRQ with qemu_allocate_irqs() to
pass it as output IRQ of the PIC, but its handler simply dispatch
into another of our output IRQ ("intr" output).

Simplify by directly connecting the PIC output to our "intr"
output.

This fixes when using QEMU built with --enable-sanitizers:

  ==338425==ERROR: LeakSanitizer: detected memory leaks

  Direct leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x5641b361e1df in malloc (qemu-system-mips+0x1b201df)
#1 0x7f995e683958 in g_malloc (/lib64/libglib-2.0.so.0+0x58958)
#2 0x5641b5558e36 in qemu_allocate_irqs hw/core/irq.c:66:12
#3 0x5641b4161817 in piix4_realize hw/isa/piix4.c:171:21
#4 0x5641b42f077a in pci_qdev_realize hw/pci/pci.c:2114:9
#5 0x5641b554c802 in device_set_realized hw/core/qdev.c:761:13
#6 0x5641b5578458 in property_set_bool qom/object.c:2257:5
#7 0x5641b55709e2 in object_property_set qom/object.c:1402:5
#8 0x5641b55861c9 in object_property_set_qobject qom/qom-qobject.c:28:10
#9 0x5641b5571831 in object_property_set_bool qom/object.c:1472:15
   #10 0x5641b55410fd in qdev_realize hw/core/qdev.c:389:12

Fixes: 078778c5a55 ("piix4: Add an i8259 Interrupt Controller as specified in 
datasheet")
Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/isa/piix4.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/hw/isa/piix4.c b/hw/isa/piix4.c
index 0fe7b69bc4c..a16f7a3ef94 100644
--- a/hw/isa/piix4.c
+++ b/hw/isa/piix4.c
@@ -115,12 +115,6 @@ static const VMStateDescription vmstate_piix4 = {
 }
 };
 
-static void piix4_request_i8259_irq(void *opaque, int irq, int level)
-{
-PIIX4State *s = opaque;
-qemu_set_irq(s->cpu_intr, level);
-}
-
 static void piix4_set_i8259_irq(void *opaque, int irq, int level)
 {
 PIIX4State *s = opaque;
@@ -161,7 +155,6 @@ static void piix4_realize(PCIDevice *dev, Error **errp)
 {
 PIIX4State *s = PIIX4_PCI_DEVICE(dev);
 ISABus *isa_bus;
-qemu_irq *i8259_out_irq;
 
 isa_bus = isa_bus_new(DEVICE(dev), pci_address_space(dev),
   pci_address_space_io(dev), errp);
@@ -180,8 +173,7 @@ static void piix4_realize(PCIDevice *dev, Error **errp)
 PIIX_RCR_IOPORT, >rcr_mem, 1);
 
 /* initialize i8259 pic */
-i8259_out_irq = qemu_allocate_irqs(piix4_request_i8259_irq, s, 1);
-s->isa = i8259_init(isa_bus, *i8259_out_irq);
+s->isa = i8259_init(isa_bus, s->cpu_intr);
 
 /* initialize ISA irqs */
 isa_bus_irqs(isa_bus, s->isa);
-- 
2.26.3

[PATCH v2 0/4] hw/isa: Remove unuseful qemu_allocate_irqs() call

I started to fix the LeakSanitizer error in piix4_realize(),
then looked for similar pattern and found 2 other places.
The older is i82378 (historically the first one) which then
spread.

Since v1:
- rebased
- removed vt82c686 patches

Philippe Mathieu-Daudé (4):
  hw/isa/i82378: Name output IRQ as 'intr'
  hw/isa/i82378: Simplify removing unuseful qemu_allocate_irqs() call
  hw/isa/i82378: Rename output IRQ variable
  hw/isa/piix4: Fix leak removing unuseful qemu_allocate_irqs() call

 hw/isa/i82378.c | 13 +++--
 hw/isa/piix4.c  | 10 +-
 hw/ppc/prep.c   |  4 ++--
 3 files changed, 6 insertions(+), 21 deletions(-)

-- 
2.26.3

Re: [RFC PATCH 1/5] target/riscv: Add Nuclei CSR and Update interrupt handling

2021-05-10 Thread Alistair Francis

On Tue, May 11, 2021 at 2:01 PM Wang Junqiang  wrote:
>
>
>
> On 2021/5/11 上午11:43, Alistair Francis wrote:
> > On Tue, May 11, 2021 at 1:14 PM Wang Junqiang  
> > wrote:
> >>
> >>
> >>
> >> On 2021/5/10 上午10:17, Alistair Francis wrote:
> >>>C isOn Fri, May 7, 2021 at 11:25 PM wangjunqiang
> >>>  wrote:
> 
>  This patch adds Nuclei CSR support for ECLIC and update the
>  related interrupt handling.
> 
>  https://doc.nucleisys.com/nuclei_spec/isa/core_csr.html
> >>>
> >>> Hello,
> >>>
> >>> Thanks for the patches!
> >>>
> >>> This patch is very long and you will need to split it up before it can
> >>> be merged. I understand this is just an RFC, but it's still best to
> >>> start with small patches. Generally each patch should add a feature
> >>> and it seems like you have added lots of features in this patch. This
> >>> patch could probably be broken into at least 4 different patches.
> >>>
> >>> As well as that you will want to ensure that your commit message and
> >>> description explains what you are doing in that patch and in some
> >>> cases justify the change. For example adding a new CPU doesn't need a
> >>> justification (as that's easy for me to understand), but changing some
> >>> existing code might need an explanation of why we need/want that
> >>> change.
> >>>
> >>> This is still a great start though! I look forward to your future patches.
> >>>
> >>> I have left a few comments below as well.
> >>
> >> Thank you for your reply and comments.I will split it into small patches
> >> by feature in next version.And add more detailed description. To make a
> >> brief explanation, add cpu here to simplify the command line when using
> >> -cpu.
> >>
> >>>
>  ---
> target/riscv/cpu.c  |  25 +-
> target/riscv/cpu.h  |  42 ++-
> target/riscv/cpu_bits.h |  37 +++
> target/riscv/cpu_helper.c   |  80 +-
> target/riscv/csr.c  | 347 +++-
> target/riscv/insn_trans/trans_rvi.c.inc |  16 +-
> target/riscv/op_helper.c|  14 +
> 7 files changed, 552 insertions(+), 9 deletions(-)
> 
>  diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
>  index 7d6ed80f6b..b2a96effbc 100644
>  --- a/target/riscv/cpu.c
>  +++ b/target/riscv/cpu.c
>  @@ -173,6 +173,16 @@ static void rv64_sifive_e_cpu_init(Object *obj)
> set_priv_version(env, PRIV_VERSION_1_10_0);
> qdev_prop_set_bit(DEVICE(obj), "mmu", false);
> }
>  +
>  +static void rv64imafdcu_nuclei_cpu_init(Object *obj)
>  +{
>  +CPURISCVState *env = _CPU(obj)->env;
>  +set_misa(env, RV64 | RVI | RVM | RVA | RVF | RVD | RVC | RVU);
>  +set_priv_version(env, PRIV_VERSION_1_10_0);
>  +qdev_prop_set_bit(DEVICE(obj), "mmu", false);
>  +set_resetvec(env, DEFAULT_RSTVEC);
>  +set_feature(env, RISCV_FEATURE_PMP);
>  +}
> #else
> static void rv32_base_cpu_init(Object *obj)
> {
>  @@ -212,6 +222,16 @@ static void rv32_imafcu_nommu_cpu_init(Object *obj)
> set_resetvec(env, DEFAULT_RSTVEC);
> qdev_prop_set_bit(DEVICE(obj), "mmu", false);
> }
>  +
>  +static void rv32imafdcu_nuclei_cpu_init(Object *obj)
>  +{
>  +CPURISCVState *env = _CPU(obj)->env;
>  +set_misa(env, RV32 | RVI | RVM | RVA | RVF | RVD | RVC | RVU);
>  +set_priv_version(env, PRIV_VERSION_1_10_0);
>  +qdev_prop_set_bit(DEVICE(obj), "mmu", false);
>  +set_resetvec(env, DEFAULT_RSTVEC);
>  +set_feature(env, RISCV_FEATURE_PMP);
>  +}
> #endif
> 
> static ObjectClass *riscv_cpu_class_by_name(const char *cpu_model)
>  @@ -331,7 +351,7 @@ static bool riscv_cpu_has_work(CPUState *cs)
>  * Definition of the WFI instruction requires it to ignore the 
>  privilege
>  * mode and delegation registers, but respect individual enables
>  */
>  -return (env->mip & env->mie) != 0;
>  +return ((env->mip & env->mie) != 0  || (env->exccode != -1));
> >>>
> >>> This change for example needs to be explained, I'm not sure what exccode 
> >>> is
> >>>
> #else
> return true;
> #endif
>  @@ -356,6 +376,7 @@ static void riscv_cpu_reset(DeviceState *dev)
> env->mstatus &= ~(MSTATUS_MIE | MSTATUS_MPRV);
> env->mcause = 0;
> env->pc = env->resetvec;
>  +env->exccode = -1;
> env->two_stage_lookup = false;
> #endif
> cs->exception_index = EXCP_NONE;
>  @@ -704,10 +725,12 @@ static const TypeInfo riscv_cpu_type_infos[] = {
> DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_E31,   
>  rv32_sifive_e_cpu_init),
> DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_E34,   
>  rv32_imafcu_nommu_cpu_init),
>

Re: [RFC PATCH 1/5] target/riscv: Add Nuclei CSR and Update interrupt handling

2021-05-10 Thread Wang Junqiang





On 2021/5/11 上午11:43, Alistair Francis wrote:

On Tue, May 11, 2021 at 1:14 PM Wang Junqiang  wrote:




On 2021/5/10 上午10:17, Alistair Francis wrote:

   C isOn Fri, May 7, 2021 at 11:25 PM wangjunqiang
 wrote:


This patch adds Nuclei CSR support for ECLIC and update the
related interrupt handling.

https://doc.nucleisys.com/nuclei_spec/isa/core_csr.html


Hello,

Thanks for the patches!

This patch is very long and you will need to split it up before it can
be merged. I understand this is just an RFC, but it's still best to
start with small patches. Generally each patch should add a feature
and it seems like you have added lots of features in this patch. This
patch could probably be broken into at least 4 different patches.

As well as that you will want to ensure that your commit message and
description explains what you are doing in that patch and in some
cases justify the change. For example adding a new CPU doesn't need a
justification (as that's easy for me to understand), but changing some
existing code might need an explanation of why we need/want that
change.

This is still a great start though! I look forward to your future patches.

I have left a few comments below as well.


Thank you for your reply and comments.I will split it into small patches
by feature in next version.And add more detailed description. To make a
brief explanation, add cpu here to simplify the command line when using
-cpu.




---
   target/riscv/cpu.c  |  25 +-
   target/riscv/cpu.h  |  42 ++-
   target/riscv/cpu_bits.h |  37 +++
   target/riscv/cpu_helper.c   |  80 +-
   target/riscv/csr.c  | 347 +++-
   target/riscv/insn_trans/trans_rvi.c.inc |  16 +-
   target/riscv/op_helper.c|  14 +
   7 files changed, 552 insertions(+), 9 deletions(-)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 7d6ed80f6b..b2a96effbc 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -173,6 +173,16 @@ static void rv64_sifive_e_cpu_init(Object *obj)
   set_priv_version(env, PRIV_VERSION_1_10_0);
   qdev_prop_set_bit(DEVICE(obj), "mmu", false);
   }
+
+static void rv64imafdcu_nuclei_cpu_init(Object *obj)
+{
+CPURISCVState *env = _CPU(obj)->env;
+set_misa(env, RV64 | RVI | RVM | RVA | RVF | RVD | RVC | RVU);
+set_priv_version(env, PRIV_VERSION_1_10_0);
+qdev_prop_set_bit(DEVICE(obj), "mmu", false);
+set_resetvec(env, DEFAULT_RSTVEC);
+set_feature(env, RISCV_FEATURE_PMP);
+}
   #else
   static void rv32_base_cpu_init(Object *obj)
   {
@@ -212,6 +222,16 @@ static void rv32_imafcu_nommu_cpu_init(Object *obj)
   set_resetvec(env, DEFAULT_RSTVEC);
   qdev_prop_set_bit(DEVICE(obj), "mmu", false);
   }
+
+static void rv32imafdcu_nuclei_cpu_init(Object *obj)
+{
+CPURISCVState *env = _CPU(obj)->env;
+set_misa(env, RV32 | RVI | RVM | RVA | RVF | RVD | RVC | RVU);
+set_priv_version(env, PRIV_VERSION_1_10_0);
+qdev_prop_set_bit(DEVICE(obj), "mmu", false);
+set_resetvec(env, DEFAULT_RSTVEC);
+set_feature(env, RISCV_FEATURE_PMP);
+}
   #endif

   static ObjectClass *riscv_cpu_class_by_name(const char *cpu_model)
@@ -331,7 +351,7 @@ static bool riscv_cpu_has_work(CPUState *cs)
* Definition of the WFI instruction requires it to ignore the privilege
* mode and delegation registers, but respect individual enables
*/
-return (env->mip & env->mie) != 0;
+return ((env->mip & env->mie) != 0  || (env->exccode != -1));


This change for example needs to be explained, I'm not sure what exccode is


   #else
   return true;
   #endif
@@ -356,6 +376,7 @@ static void riscv_cpu_reset(DeviceState *dev)
   env->mstatus &= ~(MSTATUS_MIE | MSTATUS_MPRV);
   env->mcause = 0;
   env->pc = env->resetvec;
+env->exccode = -1;
   env->two_stage_lookup = false;
   #endif
   cs->exception_index = EXCP_NONE;
@@ -704,10 +725,12 @@ static const TypeInfo riscv_cpu_type_infos[] = {
   DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_E31,   rv32_sifive_e_cpu_init),
   DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_E34,   rv32_imafcu_nommu_cpu_init),
   DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_U34,   rv32_sifive_u_cpu_init),
+DEFINE_CPU(TYPE_RISCV_CPU_NUCLEI_N307FD,rv32imafdcu_nuclei_cpu_init),
   #elif defined(TARGET_RISCV64)
   DEFINE_CPU(TYPE_RISCV_CPU_BASE64,   rv64_base_cpu_init),
   DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_E51,   rv64_sifive_e_cpu_init),
   DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_U54,   rv64_sifive_u_cpu_init),
+DEFINE_CPU(TYPE_RISCV_CPU_NUCLEI_NX600FD,rv64imafdcu_nuclei_cpu_init),
   #endif
   };

diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 0a33d387ba..1d3a1986a6 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -33,6 +33,7 @@
   #define RISCV_CPU_TYPE_SUFFIX "-" TYPE_RISCV_CPU
   #define RISCV_CPU_TYPE_NAME(name) (name RISCV_CPU_TYPE_SUFFIX)
   #define

Re: [PATCH-for-6.0] hw/mem/meson: Fix linking sparse-mem device with fuzzer

Cc'ing qemu-trivial (patch reviewed).

On 4/12/21 1:07 PM, Philippe Mathieu-Daudé wrote:
> ping?
> 
> On 4/6/21 4:39 PM, Alexander Bulekov wrote:
>> On 210406 1539, Philippe Mathieu-Daudé wrote:
>>> sparse-mem.c is added to the 'mem_ss' source set, which itself
>>> is conditionally added to softmmu_ss if CONFIG_MEM_DEVICE is
>>> selected.
>>> But if CONFIG_MEM_DEVICE isn't selected, we get a link failure
>>> even if CONFIG_FUZZ is selected:
>>>
>>>   /usr/bin/ld: tests_qtest_fuzz_generic_fuzz.c.o: in function 
>>> `generic_pre_fuzz':
>>>   tests/qtest/fuzz/generic_fuzz.c:826: undefined reference to 
>>> `sparse_mem_init'
>>>   clang-10: error: linker command failed with exit code 1 (use -v to see 
>>> invocation)
>>>
>>> Fix by adding sparse-mem.c directly to the softmmu_ss set.
>>>
>>> Fixes: 230376d285b ("memory: add a sparse memory device for fuzzing")
>>> Signed-off-by: Philippe Mathieu-Daudé 
>>
>> Oops..
>> Reviewed-by: Alexander Bulekov 
>>
>>> ---
>>>  hw/mem/meson.build | 3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/hw/mem/meson.build b/hw/mem/meson.build
>>> index ef79e046787..3c8fdef9f9e 100644
>>> --- a/hw/mem/meson.build
>>> +++ b/hw/mem/meson.build
>>> @@ -1,8 +1,9 @@
>>>  mem_ss = ss.source_set()
>>>  mem_ss.add(files('memory-device.c'))
>>> -mem_ss.add(when: 'CONFIG_FUZZ', if_true: files('sparse-mem.c'))
>>>  mem_ss.add(when: 'CONFIG_DIMM', if_true: files('pc-dimm.c'))
>>>  mem_ss.add(when: 'CONFIG_NPCM7XX', if_true: files('npcm7xx_mc.c'))
>>>  mem_ss.add(when: 'CONFIG_NVDIMM', if_true: files('nvdimm.c'))
>>>  
>>>  softmmu_ss.add_all(when: 'CONFIG_MEM_DEVICE', if_true: mem_ss)
>>> +
>>> +softmmu_ss.add(when: 'CONFIG_FUZZ', if_true: files('sparse-mem.c'))
>>> -- 
>>> 2.26.3
>>>
>>>
>>
>

Re: [RFC PATCH 1/5] target/riscv: Add Nuclei CSR and Update interrupt handling

2021-05-10 Thread Alistair Francis

On Tue, May 11, 2021 at 1:14 PM Wang Junqiang  wrote:
>
>
>
> On 2021/5/10 上午10:17, Alistair Francis wrote:
> >   C isOn Fri, May 7, 2021 at 11:25 PM wangjunqiang
> >  wrote:
> >>
> >> This patch adds Nuclei CSR support for ECLIC and update the
> >> related interrupt handling.
> >>
> >> https://doc.nucleisys.com/nuclei_spec/isa/core_csr.html
> >
> > Hello,
> >
> > Thanks for the patches!
> >
> > This patch is very long and you will need to split it up before it can
> > be merged. I understand this is just an RFC, but it's still best to
> > start with small patches. Generally each patch should add a feature
> > and it seems like you have added lots of features in this patch. This
> > patch could probably be broken into at least 4 different patches.
> >
> > As well as that you will want to ensure that your commit message and
> > description explains what you are doing in that patch and in some
> > cases justify the change. For example adding a new CPU doesn't need a
> > justification (as that's easy for me to understand), but changing some
> > existing code might need an explanation of why we need/want that
> > change.
> >
> > This is still a great start though! I look forward to your future patches.
> >
> > I have left a few comments below as well.
>
> Thank you for your reply and comments.I will split it into small patches
> by feature in next version.And add more detailed description. To make a
> brief explanation, add cpu here to simplify the command line when using
> -cpu.
>
> >
> >> ---
> >>   target/riscv/cpu.c  |  25 +-
> >>   target/riscv/cpu.h  |  42 ++-
> >>   target/riscv/cpu_bits.h |  37 +++
> >>   target/riscv/cpu_helper.c   |  80 +-
> >>   target/riscv/csr.c  | 347 +++-
> >>   target/riscv/insn_trans/trans_rvi.c.inc |  16 +-
> >>   target/riscv/op_helper.c|  14 +
> >>   7 files changed, 552 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> >> index 7d6ed80f6b..b2a96effbc 100644
> >> --- a/target/riscv/cpu.c
> >> +++ b/target/riscv/cpu.c
> >> @@ -173,6 +173,16 @@ static void rv64_sifive_e_cpu_init(Object *obj)
> >>   set_priv_version(env, PRIV_VERSION_1_10_0);
> >>   qdev_prop_set_bit(DEVICE(obj), "mmu", false);
> >>   }
> >> +
> >> +static void rv64imafdcu_nuclei_cpu_init(Object *obj)
> >> +{
> >> +CPURISCVState *env = _CPU(obj)->env;
> >> +set_misa(env, RV64 | RVI | RVM | RVA | RVF | RVD | RVC | RVU);
> >> +set_priv_version(env, PRIV_VERSION_1_10_0);
> >> +qdev_prop_set_bit(DEVICE(obj), "mmu", false);
> >> +set_resetvec(env, DEFAULT_RSTVEC);
> >> +set_feature(env, RISCV_FEATURE_PMP);
> >> +}
> >>   #else
> >>   static void rv32_base_cpu_init(Object *obj)
> >>   {
> >> @@ -212,6 +222,16 @@ static void rv32_imafcu_nommu_cpu_init(Object *obj)
> >>   set_resetvec(env, DEFAULT_RSTVEC);
> >>   qdev_prop_set_bit(DEVICE(obj), "mmu", false);
> >>   }
> >> +
> >> +static void rv32imafdcu_nuclei_cpu_init(Object *obj)
> >> +{
> >> +CPURISCVState *env = _CPU(obj)->env;
> >> +set_misa(env, RV32 | RVI | RVM | RVA | RVF | RVD | RVC | RVU);
> >> +set_priv_version(env, PRIV_VERSION_1_10_0);
> >> +qdev_prop_set_bit(DEVICE(obj), "mmu", false);
> >> +set_resetvec(env, DEFAULT_RSTVEC);
> >> +set_feature(env, RISCV_FEATURE_PMP);
> >> +}
> >>   #endif
> >>
> >>   static ObjectClass *riscv_cpu_class_by_name(const char *cpu_model)
> >> @@ -331,7 +351,7 @@ static bool riscv_cpu_has_work(CPUState *cs)
> >>* Definition of the WFI instruction requires it to ignore the 
> >> privilege
> >>* mode and delegation registers, but respect individual enables
> >>*/
> >> -return (env->mip & env->mie) != 0;
> >> +return ((env->mip & env->mie) != 0  || (env->exccode != -1));
> >
> > This change for example needs to be explained, I'm not sure what exccode is
> >
> >>   #else
> >>   return true;
> >>   #endif
> >> @@ -356,6 +376,7 @@ static void riscv_cpu_reset(DeviceState *dev)
> >>   env->mstatus &= ~(MSTATUS_MIE | MSTATUS_MPRV);
> >>   env->mcause = 0;
> >>   env->pc = env->resetvec;
> >> +env->exccode = -1;
> >>   env->two_stage_lookup = false;
> >>   #endif
> >>   cs->exception_index = EXCP_NONE;
> >> @@ -704,10 +725,12 @@ static const TypeInfo riscv_cpu_type_infos[] = {
> >>   DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_E31,   rv32_sifive_e_cpu_init),
> >>   DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_E34,   
> >> rv32_imafcu_nommu_cpu_init),
> >>   DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_U34,   rv32_sifive_u_cpu_init),
> >> +DEFINE_CPU(TYPE_RISCV_CPU_NUCLEI_N307FD,
> >> rv32imafdcu_nuclei_cpu_init),
> >>   #elif defined(TARGET_RISCV64)
> >>   DEFINE_CPU(TYPE_RISCV_CPU_BASE64,   rv64_base_cpu_init),
> >>   DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_E51,   rv64_sifive_e_cpu_init),
> >>

Re: [PATCH] hw/pci-host: Do not build gpex-acpi.c if GPEX is not selected

Cc'ing qemu-trivial (patch reviewed).

On 4/25/21 8:21 PM, Philippe Mathieu-Daudé wrote:
> Since its introduction in commit 5b85eabe68f ("acpi: add
> acpi_dsdt_add_gpex") we build gpex-acpi.c if ACPI is selected,
> even if the GPEX_HOST device isn't build. Add the missing
> Kconfig dependency.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> The gpex*.c files aren't covered by any MAINTAINERS section:
> 
> $ ./scripts/get_maintainer.pl -f hw/pci-host/gpex.c -f hw/pci-host/gpex-acpi.c
> get_maintainer.pl: No maintainers found, printing recent contributors.
> get_maintainer.pl: Do not blindly cc: them on patches!  Use common sense.
> 
> Markus Armbruster  (commit_signer:2/2=100%)
> Paolo Bonzini  (commit_signer:2/2=100%)
> Alistair Francis  (commit_signer:1/2=50%)
> "Philippe Mathieu-Daudé"  (commit_signer:1/2=50%)
> "Michael S. Tsirkin"  (commit_signer:14/8=100%)
> Jiahui Cen  (commit_signer:6/8=75%)
> Igor Mammedov  (commit_signer:4/8=50%)
> Gerd Hoffmann  (commit_signer:2/8=25%)
> Yubo Miao  (commit_signer:2/8=25%)
> qemu-devel@nongnu.org (open list:All patches CC here)
> ---
>  hw/pci-host/meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/pci-host/meson.build b/hw/pci-host/meson.build
> index 87a896973e7..d52dce77cbd 100644
> --- a/hw/pci-host/meson.build
> +++ b/hw/pci-host/meson.build
> @@ -3,7 +3,7 @@
>  pci_ss.add(when: 'CONFIG_PCI_BONITO', if_true: files('bonito.c'))
>  pci_ss.add(when: 'CONFIG_PCI_EXPRESS_DESIGNWARE', if_true: 
> files('designware.c'))
>  pci_ss.add(when: 'CONFIG_PCI_EXPRESS_GENERIC_BRIDGE', if_true: 
> files('gpex.c'))
> -pci_ss.add(when: 'CONFIG_ACPI', if_true: files('gpex-acpi.c'))
> +pci_ss.add(when: ['CONFIG_PCI_EXPRESS_GENERIC_BRIDGE', 'CONFIG_ACPI'], 
> if_true: files('gpex-acpi.c'))
>  pci_ss.add(when: 'CONFIG_PCI_EXPRESS_Q35', if_true: files('q35.c'))
>  pci_ss.add(when: 'CONFIG_PCI_EXPRESS_XILINX', if_true: 
> files('xilinx-pcie.c'))
>  pci_ss.add(when: 'CONFIG_PCI_I440FX', if_true: files('i440fx.c'))
>

Re: [PATCH v2 0/8] hw/block/fdc: Allow Kconfig-selecting ISA bus/SysBus floppy controllers

Hi John,

This series is fully reviewed; can it go via your block tree?

On 4/28/21 2:50 PM, Philippe Mathieu-Daudé wrote:
> Hi,
> 
> The floppy disc controllers pulls in irrelevant devices (sysbus in
> an ISA-only machine, ISA bus + isa devices on a sysbus-only machine).
> 
> This series clean that by extracting each device in its own file,
> adding the corresponding Kconfig symbols: FDC_ISA and FDC_SYSBUS.
> 
> Since v1:
> - added missing "hw/block/block.h" header (jsnow)
> - inlined hardware specific calls (Mark)
> - added R-b/A-b tags

> Philippe Mathieu-Daudé (8):
>   hw/block/fdc: Replace disabled fprintf() by trace event
>   hw/block/fdc: Declare shared prototypes in fdc-internal.h
>   hw/block/fdc: Extract ISA floppy controllers to fdc-isa.c
>   hw/block/fdc: Extract SysBus floppy controllers to fdc-sysbus.c
>   hw/block/fdc: Add sysbus_fdc_init_drives() method
>   hw/sparc/sun4m: Inline sun4m_fdctrl_init()
>   hw/block/fdc-sysbus: Add 'dma-channel' property
>   hw/mips/jazz: Inline fdctrl_init_sysbus()

Re: [PATCH v3 0/2] hw: Convert mc146818rtc & etraxfs_timer to 3-phase reset interface

Hi Laurent,

I addressed your comments from v1, and this series is
now reviewed. Can it get merged via your qemu-trivial tree?

On 5/2/21 6:39 PM, Philippe Mathieu-Daudé wrote:
> Remove qemu_register_reset() when a qdev type has a qbus parent,
> implementing the 3-phase Resettable interface.
> 
> Since v2:
> - Lower IRQ in 'hold' phase, not 'exit' one (Edgar)
> 
> Since v1:
> - Use 3-phase reset interface instead of qdev one (Laurent)
> 
> Supersedes: <20210423233652.3042941-1-f4...@amsat.org>
> 
> Philippe Mathieu-Daudé (2):
>   hw/timer/etraxfs_timer: Convert to 3-phase reset (Resettable
> interface)
>   hw/rtc/mc146818rtc: Convert to 3-phase reset (Resettable interface)
> 
>  hw/rtc/mc146818rtc.c | 42 +---
>  hw/timer/etraxfs_timer.c | 14 +++---
>  2 files changed, 33 insertions(+), 23 deletions(-)
>

Re: [PATCH] hw/arm/raspi: Remove deprecated raspi2/raspi3 aliases

Hi Peter,

Can this patch go via your qemu-arm tree (it is reviewed)?

On 5/3/21 12:57 PM, Philippe Mathieu-Daudé wrote:
> Remove the raspi2/raspi3 machine aliases,
> deprecated since commit 155e1c82ed0.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  docs/system/deprecated.rst   | 7 ---
>  docs/system/removed-features.rst | 7 +++
>  hw/arm/raspi.c   | 2 --
>  3 files changed, 7 insertions(+), 9 deletions(-)
> 
> diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
> index 80cae862528..7895bd4d849 100644
> --- a/docs/system/deprecated.rst
> +++ b/docs/system/deprecated.rst
> @@ -238,13 +238,6 @@ this CPU is also deprecated.
>  System emulator machines
>  
>  
> -Raspberry Pi ``raspi2`` and ``raspi3`` machines (since 5.2)
> -'''
> -
> -The Raspberry Pi machines come in various models (A, A+, B, B+). To be able
> -to distinguish which model QEMU is implementing, the ``raspi2`` and 
> ``raspi3``
> -machines have been renamed ``raspi2b`` and ``raspi3b``.
> -
>  Device options
>  --
>  
> diff --git a/docs/system/removed-features.rst 
> b/docs/system/removed-features.rst
> index 29e90601a51..8a8b8ca627b 100644
> --- a/docs/system/removed-features.rst
> +++ b/docs/system/removed-features.rst
> @@ -312,6 +312,13 @@ This machine has been renamed ``fuloong2e``.
>  These machine types were very old and likely could not be used for live
>  migration from old QEMU versions anymore. Use a newer machine type instead.
>  
> +Raspberry Pi ``raspi2`` and ``raspi3`` machines (removed in 6.1)
> +
> +
> +The Raspberry Pi machines come in various models (A, A+, B, B+). To be able
> +to distinguish which model QEMU is implementing, the ``raspi2`` and 
> ``raspi3``
> +machines have been renamed ``raspi2b`` and ``raspi3b``.
> +
>  
>  linux-user mode CPUs
>  
> diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
> index 990509d3852..20bba0316f1 100644
> --- a/hw/arm/raspi.c
> +++ b/hw/arm/raspi.c
> @@ -342,7 +342,6 @@ static void raspi2b_machine_class_init(ObjectClass *oc, 
> void *data)
>  MachineClass *mc = MACHINE_CLASS(oc);
>  RaspiMachineClass *rmc = RASPI_MACHINE_CLASS(oc);
>  
> -mc->alias = "raspi2";
>  rmc->board_rev = 0xa21041;
>  raspi_machine_class_common_init(mc, rmc->board_rev);
>  };
> @@ -362,7 +361,6 @@ static void raspi3b_machine_class_init(ObjectClass *oc, 
> void *data)
>  MachineClass *mc = MACHINE_CLASS(oc);
>  RaspiMachineClass *rmc = RASPI_MACHINE_CLASS(oc);
>  
> -mc->alias = "raspi3";
>  rmc->board_rev = 0xa02082;
>  raspi_machine_class_common_init(mc, rmc->board_rev);
>  };
>

Re: [PATCH] target/mips: Fix potential integer overflow (CID 1452921)

On 5/5/21 11:51 PM, Philippe Mathieu-Daudé wrote:
> Use the BIT_ULL() macro to ensure we use 64-bit arithmetic.
> This fixes the following Coverity issue (OVERFLOW_BEFORE_WIDEN):
> 
>   CID 1452921:  Integer handling issues:
> 
> Potentially overflowing expression "1 << w" with type "int"
> (32 bits, signed) is evaluated using 32-bit arithmetic, and
> then used in a context that expects an expression of type
> "uint64_t" (64 bits, unsigned).
> 
> Fixes: 074cfcb4dae ("target/mips: Implement hardware page table walker")
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  target/mips/tcg/sysemu/tlb_helper.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Thanks, applied to mips-next.

Re: [RFC PATCH 2/5] hw/intc: Add Nuclei ECLIC device

2021-05-10 Thread Wang Junqiang





On 2021/5/10 下午1:26, Bin Meng wrote:

On Mon, May 10, 2021 at 10:27 AM Bin Meng  wrote:


On Mon, May 10, 2021 at 10:21 AM Alistair Francis  wrote:


On Fri, May 7, 2021 at 11:24 PM wangjunqiang  wrote:


This patch provides an implementation of Nuclei ECLIC Device.
Nuclei processor core have been equipped with an Enhanced Core Local
Interrupt Controller (ECLIC), which is optimized based on the RISC-V
standard CLIC, to manage all interrupt sources.

https://doc.nucleisys.com/nuclei_spec/isa/eclic.html


Hello,

There are patches on the QEMU list adding support for the CLIC. How
different is the ECLIC from the CLIC? Could you use the CLIC as a
starting point instead of implementing a new interrupt controller?



That's my thought too when I saw this patch at first.

A better way is to scandalize the CLIC support in QEMU first, then we


Sorry for the typo. I meant to say: standardize the CLIC support


will see how Nuclei's eCLIC could be built on top of that. Thanks!


Regards,
Bin



I agree with both of you.the CLIC support in QEMU first. I read the 
patch of clic, and there is no problem with compatibility in the 
target/riscv directory.I will split eclic in next version. Thanks


Regards
Wang Junqiang

Re: [RFC PATCH 1/5] target/riscv: Add Nuclei CSR and Update interrupt handling

2021-05-10 Thread Wang Junqiang





On 2021/5/10 上午10:17, Alistair Francis wrote:

  C isOn Fri, May 7, 2021 at 11:25 PM wangjunqiang
 wrote:


This patch adds Nuclei CSR support for ECLIC and update the
related interrupt handling.

https://doc.nucleisys.com/nuclei_spec/isa/core_csr.html


Hello,

Thanks for the patches!

This patch is very long and you will need to split it up before it can
be merged. I understand this is just an RFC, but it's still best to
start with small patches. Generally each patch should add a feature
and it seems like you have added lots of features in this patch. This
patch could probably be broken into at least 4 different patches.

As well as that you will want to ensure that your commit message and
description explains what you are doing in that patch and in some
cases justify the change. For example adding a new CPU doesn't need a
justification (as that's easy for me to understand), but changing some
existing code might need an explanation of why we need/want that
change.

This is still a great start though! I look forward to your future patches.

I have left a few comments below as well.


Thank you for your reply and comments.I will split it into small patches 
by feature in next version.And add more detailed description. To make a 
brief explanation, add cpu here to simplify the command line when using 
-cpu.





---
  target/riscv/cpu.c  |  25 +-
  target/riscv/cpu.h  |  42 ++-
  target/riscv/cpu_bits.h |  37 +++
  target/riscv/cpu_helper.c   |  80 +-
  target/riscv/csr.c  | 347 +++-
  target/riscv/insn_trans/trans_rvi.c.inc |  16 +-
  target/riscv/op_helper.c|  14 +
  7 files changed, 552 insertions(+), 9 deletions(-)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 7d6ed80f6b..b2a96effbc 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -173,6 +173,16 @@ static void rv64_sifive_e_cpu_init(Object *obj)
  set_priv_version(env, PRIV_VERSION_1_10_0);
  qdev_prop_set_bit(DEVICE(obj), "mmu", false);
  }
+
+static void rv64imafdcu_nuclei_cpu_init(Object *obj)
+{
+CPURISCVState *env = _CPU(obj)->env;
+set_misa(env, RV64 | RVI | RVM | RVA | RVF | RVD | RVC | RVU);
+set_priv_version(env, PRIV_VERSION_1_10_0);
+qdev_prop_set_bit(DEVICE(obj), "mmu", false);
+set_resetvec(env, DEFAULT_RSTVEC);
+set_feature(env, RISCV_FEATURE_PMP);
+}
  #else
  static void rv32_base_cpu_init(Object *obj)
  {
@@ -212,6 +222,16 @@ static void rv32_imafcu_nommu_cpu_init(Object *obj)
  set_resetvec(env, DEFAULT_RSTVEC);
  qdev_prop_set_bit(DEVICE(obj), "mmu", false);
  }
+
+static void rv32imafdcu_nuclei_cpu_init(Object *obj)
+{
+CPURISCVState *env = _CPU(obj)->env;
+set_misa(env, RV32 | RVI | RVM | RVA | RVF | RVD | RVC | RVU);
+set_priv_version(env, PRIV_VERSION_1_10_0);
+qdev_prop_set_bit(DEVICE(obj), "mmu", false);
+set_resetvec(env, DEFAULT_RSTVEC);
+set_feature(env, RISCV_FEATURE_PMP);
+}
  #endif

  static ObjectClass *riscv_cpu_class_by_name(const char *cpu_model)
@@ -331,7 +351,7 @@ static bool riscv_cpu_has_work(CPUState *cs)
   * Definition of the WFI instruction requires it to ignore the privilege
   * mode and delegation registers, but respect individual enables
   */
-return (env->mip & env->mie) != 0;
+return ((env->mip & env->mie) != 0  || (env->exccode != -1));


This change for example needs to be explained, I'm not sure what exccode is


  #else
  return true;
  #endif
@@ -356,6 +376,7 @@ static void riscv_cpu_reset(DeviceState *dev)
  env->mstatus &= ~(MSTATUS_MIE | MSTATUS_MPRV);
  env->mcause = 0;
  env->pc = env->resetvec;
+env->exccode = -1;
  env->two_stage_lookup = false;
  #endif
  cs->exception_index = EXCP_NONE;
@@ -704,10 +725,12 @@ static const TypeInfo riscv_cpu_type_infos[] = {
  DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_E31,   rv32_sifive_e_cpu_init),
  DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_E34,   rv32_imafcu_nommu_cpu_init),
  DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_U34,   rv32_sifive_u_cpu_init),
+DEFINE_CPU(TYPE_RISCV_CPU_NUCLEI_N307FD,rv32imafdcu_nuclei_cpu_init),
  #elif defined(TARGET_RISCV64)
  DEFINE_CPU(TYPE_RISCV_CPU_BASE64,   rv64_base_cpu_init),
  DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_E51,   rv64_sifive_e_cpu_init),
  DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_U54,   rv64_sifive_u_cpu_init),
+DEFINE_CPU(TYPE_RISCV_CPU_NUCLEI_NX600FD,rv64imafdcu_nuclei_cpu_init),
  #endif
  };

diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 0a33d387ba..1d3a1986a6 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -33,6 +33,7 @@
  #define RISCV_CPU_TYPE_SUFFIX "-" TYPE_RISCV_CPU
  #define RISCV_CPU_TYPE_NAME(name) (name RISCV_CPU_TYPE_SUFFIX)
  #define CPU_RESOLVING_TYPE TYPE_RISCV_CPU
+#define CPU_INTERRUPT_ECLIC CPU_INTERRUPT_TGT_EXT_0

  #define TYPE_RISCV_CPU_ANY

Re: [PATCH v3 1/2] ui/cocoa: capture all keys and combos when mouse is grabbed

2021-05-10 Thread Akihiko Odaki

On 2021/05/05 8:32, gust...@noronha.eti.br wrote:> @@ -344,6 +361,32 @@ 
- (id)initWithFrame:(NSRect)frameRect

  kbd = qkbd_state_init(dcl.con);
  
  }

+
+CGEventMask mask = CGEventMaskBit(kCGEventKeyDown) | 
CGEventMaskBit(kCGEventKeyUp) | CGEventMaskBit(kCGEventFlagsChanged);
+eventsTap = CGEventTapCreate(kCGHIDEventTap, kCGHeadInsertEventTap, 
kCGEventTapOptionDefault,
+ mask, handleTapEvent, self);
+if (!eventsTap) {
+warn_report("Could not create event tap, system key combos will not be 
captured.\n");
+return self;
+} else {
+COCOA_DEBUG("Global events tap created! Will capture system key 
combos.\n");
+}
+
+CFRunLoopRef runLoop = CFRunLoopGetCurrent();
+if (!runLoop) {
+warn_report("Could not obtain current CF RunLoop, system key combos will 
not be captured.\n");
+return self;
+}
+
+CFRunLoopSourceRef tapEventsSrc = 
CFMachPortCreateRunLoopSource(kCFAllocatorDefault, eventsTap, 0);
+if (!tapEventsSrc ) {
+warn_report("Could not obtain current CF RunLoop, system key combos will 
not be captured.\n");
+return self;
+}
+
+CFRunLoopAddSource(runLoop, tapEventsSrc, kCFRunLoopDefaultMode);
+CFRelease(tapEventsSrc);
+
  return self;
  }
  


These statements should be in "if (self)" block which they follow, or it 
may rely on "self" even if it failed to allocate and initialize "self".


Regards,
Akihiko Odaki

Re: [PATCH 0/7] vhost-user-gpu: fix several security issues

2021-05-10 Thread Li Qiang

Philippe Mathieu-Daudé  于2021年5月11日周二 上午3:25写道：
>
> On 5/5/21 11:35 AM, Marc-André Lureau wrote:
> > Hi
> >
> > On Wed, May 5, 2021 at 1:28 PM Li Qiang  > > wrote:
> >
> > Marc-André Lureau  > > 于2021年5月5日周三 下午5:10写道：
> > >
> > > Hi
> > >
> > > On Wed, May 5, 2021 at 9:21 AM Li Qiang  > > wrote:
> > >>
> > >> These security issue is low severity and is similar with the
> > >> virtio-vga/virtio-gpu device. All of them can be triggered by
> > >> the guest user.
> > >>
> > >> Li Qiang (7):
> > >>   vhost-user-gpu: fix memory disclosure in virgl_cmd_get_capset_info
> > >>   vhost-user-gpu: fix resource leak in 'vg_resource_create_2d'
> > >>   vhost-user-gpu: fix memory leak in vg_resource_attach_backing
> > >>   vhost-user-gpu: fix memory link while calling 'vg_resource_unref'
> > >>   vhost-user-gpu: fix memory leak in 'virgl_cmd_resource_unref'
> > >>   vhost-user-gpu: fix memory leak in 'virgl_resource_attach_backing'
> > >>   vhost-user-gpu: fix OOB write in 'virgl_cmd_get_capset'
> > >>
> > >>  contrib/vhost-user-gpu/vhost-user-gpu.c |  7 +++
> > >>  contrib/vhost-user-gpu/virgl.c  | 17 -
> > >>  2 files changed, 23 insertions(+), 1 deletion(-)
> > >>
> > >> --
> > >
> > >
> > > The whole series looks good to me, and applies fixes that were
> > done earlier in virtio-gpu.
> >
> > Do you mean you have merged this series?
> > Should I tweak something such as "adding the original fix in
> > virtio-gpu"/"better mapping iov cleanup"?
>
> Yes, and please also mention the corresponding CVE (CVE-2021-3544,
> CVE-2021-3545, CVE-2021-3546).
>

OK, I'm still waiting for the some of the patch's response from
Prasad. Kindly ping @Prasad


Thanks,
Li Qiang

> >
> >
> > No I didn't. I was waiting for the answers to Prasad questions, and
> > eventually v2.
> >
> > Then either Gerd or me can queue this imho.
> >
> > --
> > Marc-André Lureau
>

Re: [RFC PATCH v2 0/4] Add migration support for VFIO PCI devices in SMMUv3 nested stage mode

Hi all,

This series has been updated to v3.[1]
Any comments and reviews are welcome.

Thanks,
Kunkun Jiang

[1] [RFC PATCH v3 0/4] Add migration support for VFIO PCI devices in
SMMUv3 nested mode

https://lore.kernel.org/qemu-devel/20210511020816.2905-1-jiangkun...@huawei.com/

On 2021/3/31 18:12, Kunkun Jiang wrote:

Hi all,

Since the SMMUv3's nested translation stages[1] has been introduced by Eric, we
need to pay attention to the migration of VFIO PCI devices in SMMUv3 nested
stage
mode. At present, it is not yet supported in QEMU. There are two problems in the
existing framework.

First, the current way to get dirty pages is not applicable to nested stage
mode.
Because of the "Caching Mode", VTD can map the RAM through the host single stage
(giova->hpa). "vfio_listener_log_sync" gets dirty pages by transferring "giova"
to the kernel for the RAM block section of mapped MMIO region. In nested stage
mode, we setup the stage 2 (gpa->hpa) and the stage 1(giova->gpa) separately. So
it is inapplicable to get dirty pages by the current way in nested stage mode.

Second, it also need to pass stage 1 configurations to the destination host
after
the migration. In Eric's patch, it passes the stage 1 configuration to the host
on
each STE update for the devices set the PASID PciOps. The configuration will be
applied at physical level. But the data of physical level will not be sent to
the
destination host. So we have to pass stage 1 configurations to the destination
host after the migration.

Best Regards,
Kunkun Jiang

[1] [RFC,v8,00/28] vSMMUv3/pSMMUv3 2 stage VFIO integration
http://patchwork.ozlabs.org/project/qemu-devel/cover/20210225105233.650545-1-eric.au...@redhat.com/

This Patch set includes patches as below:
Patch 1-2:
- Refactor the vfio_listener_log_sync and added a new function to get dirty
pages
in nested stage mode.

Patch 3:
- Added global_log_start/stop interface in vfio_memory_prereg_listener

Patch 4:
- Added the post_load function to vmstate_smmuv3 for passing stage 1
configuration
to the destination host after the migration.

History:

v1 -> v2:
- Add global_log_start/stop interface in vfio_memory_prereg_listener
- Add support for repass stage 1 configs with multiple CDs to the host

Kunkun Jiang (4):
vfio: Introduce helpers to mark dirty pages of a RAM section
vfio: Add vfio_prereg_listener_log_sync in nested stage
vfio: Add vfio_prereg_listener_global_log_start/stop in nested stage
hw/arm/smmuv3: Post-load stage 1 configurations to the host

hw/arm/smmuv3.c | 62 +++
hw/arm/trace-events | 1 +
hw/vfio/common.c| 71 -
3 files changed, 126 insertions(+), 8 deletions(-)

[RFC PATCH v3 1/4] vfio: Introduce helpers to mark dirty pages of a RAM section

Extract part of the code from vfio_sync_dirty_bitmap to form a
new helper, which allows to mark dirty pages of a RAM section.
This helper will be called for nested stage.

Signed-off-by: Kunkun Jiang 
---
 hw/vfio/common.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index dc8372c772..9fb8d44a6d 100644
--- a/hw/vfio/common.c
+++ b/hw/vfio/common.c
@@ -1271,6 +1271,19 @@ err_out:
 return ret;
 }
 
+static int vfio_dma_sync_ram_section_dirty_bitmap(VFIOContainer *container,
+  MemoryRegionSection *section)
+{
+ram_addr_t ram_addr;
+
+ram_addr = memory_region_get_ram_addr(section->mr) +
+   section->offset_within_region;
+
+return vfio_get_dirty_bitmap(container,
+REAL_HOST_PAGE_ALIGN(section->offset_within_address_space),
+int128_get64(section->size), ram_addr);
+}
+
 typedef struct {
 IOMMUNotifier n;
 VFIOGuestIOMMU *giommu;
@@ -1312,8 +1325,6 @@ static void vfio_iommu_map_dirty_notify(IOMMUNotifier *n, 
IOMMUTLBEntry *iotlb)
 static int vfio_sync_dirty_bitmap(VFIOContainer *container,
   MemoryRegionSection *section)
 {
-ram_addr_t ram_addr;
-
 if (memory_region_is_iommu(section->mr)) {
 VFIOGuestIOMMU *giommu;
 
@@ -1342,12 +1353,7 @@ static int vfio_sync_dirty_bitmap(VFIOContainer 
*container,
 return 0;
 }
 
-ram_addr = memory_region_get_ram_addr(section->mr) +
-   section->offset_within_region;
-
-return vfio_get_dirty_bitmap(container,
-   REAL_HOST_PAGE_ALIGN(section->offset_within_address_space),
-   int128_get64(section->size), ram_addr);
+return vfio_dma_sync_ram_section_dirty_bitmap(container, section);
 }
 
 static void vfio_listener_log_sync(MemoryListener *listener,
-- 
2.23.0

[RFC PATCH v3 4/4] hw/arm/smmuv3: Post-load stage 1 configurations to the host

In nested mode, we call the set_pasid_table() callback on each
STE update to pass the guest stage 1 configuration to the host
and apply it at physical level.

In the case of live migration, we need to manually call the
set_pasid_table() to load the guest stage 1 configurations to
the host. If this operation fails, the migration fails.

Signed-off-by: Kunkun Jiang 
---
 hw/arm/smmuv3.c | 33 -
 1 file changed, 28 insertions(+), 5 deletions(-)

diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
index ca690513e6..ac1de572f3 100644
--- a/hw/arm/smmuv3.c
+++ b/hw/arm/smmuv3.c
@@ -929,7 +929,7 @@ static void smmuv3_s1_range_inval(SMMUState *s, Cmd *cmd)
 }
 }
 
-static void smmuv3_notify_config_change(SMMUState *bs, uint32_t sid)
+static int smmuv3_notify_config_change(SMMUState *bs, uint32_t sid)
 {
 #ifdef __linux__
 IOMMUMemoryRegion *mr = smmu_iommu_mr(bs, sid);
@@ -938,9 +938,10 @@ static void smmuv3_notify_config_change(SMMUState *bs, 
uint32_t sid)
 IOMMUConfig iommu_config = {};
 SMMUTransCfg *cfg;
 SMMUDevice *sdev;
+int ret;
 
 if (!mr) {
-return;
+return 0;
 }
 
 sdev = container_of(mr, SMMUDevice, iommu);
@@ -949,13 +950,13 @@ static void smmuv3_notify_config_change(SMMUState *bs, 
uint32_t sid)
 smmuv3_flush_config(sdev);
 
 if (!pci_device_is_pasid_ops_set(sdev->bus, sdev->devfn)) {
-return;
+return 0;
 }
 
 cfg = smmuv3_get_config(sdev, );
 
 if (!cfg) {
-return;
+return 0;
 }
 
 iommu_config.pasid_cfg.argsz = sizeof(struct iommu_pasid_table_config);
@@ -977,10 +978,13 @@ static void smmuv3_notify_config_change(SMMUState *bs, 
uint32_t sid)
   iommu_config.pasid_cfg.config,
   iommu_config.pasid_cfg.base_ptr);
 
-if (pci_device_set_pasid_table(sdev->bus, sdev->devfn, _config)) {
+ret = pci_device_set_pasid_table(sdev->bus, sdev->devfn, _config);
+if (ret) {
 error_report("Failed to pass PASID table to host for iommu mr %s (%m)",
  mr->parent_obj.name);
 }
+
+return ret;
 #endif
 }
 
@@ -1545,6 +1549,24 @@ static void smmu_realize(DeviceState *d, Error **errp)
 smmu_init_irq(s, dev);
 }
 
+static int smmuv3_post_load(void *opaque, int version_id)
+{
+SMMUv3State *s3 = opaque;
+SMMUState *s = &(s3->smmu_state);
+SMMUDevice *sdev;
+int ret = 0;
+
+QLIST_FOREACH(sdev, >devices_with_notifiers, next) {
+uint32_t sid = smmu_get_sid(sdev);
+ret = smmuv3_notify_config_change(s, sid);
+if (ret) {
+break;
+}
+}
+
+return ret;
+}
+
 static const VMStateDescription vmstate_smmuv3_queue = {
 .name = "smmuv3_queue",
 .version_id = 1,
@@ -1563,6 +1585,7 @@ static const VMStateDescription vmstate_smmuv3 = {
 .version_id = 1,
 .minimum_version_id = 1,
 .priority = MIG_PRI_IOMMU,
+.post_load = smmuv3_post_load,
 .fields = (VMStateField[]) {
 VMSTATE_UINT32(features, SMMUv3State),
 VMSTATE_UINT8(sid_size, SMMUv3State),
-- 
2.23.0

[RFC PATCH v3 2/4] vfio: Add vfio_prereg_listener_log_sync in nested stage

In nested mode, we set up the stage 2 (gpa->hpa)and stage 1
(giova->gpa) separately by vfio_prereg_listener_region_add()
and vfio_listener_region_add(). So when marking dirty pages
we just need to pay attention to stage 2 mappings.

Legacy vfio_listener_log_sync cannot be used in nested stage.
This patch adds vfio_prereg_listener_log_sync to mark dirty
pages in nested mode.

Signed-off-by: Kunkun Jiang 
---
 hw/vfio/common.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index 9fb8d44a6d..149e535a75 100644
--- a/hw/vfio/common.c
+++ b/hw/vfio/common.c
@@ -1284,6 +1284,22 @@ static int 
vfio_dma_sync_ram_section_dirty_bitmap(VFIOContainer *container,
 int128_get64(section->size), ram_addr);
 }
 
+static void vfio_prereg_listener_log_sync(MemoryListener *listener,
+  MemoryRegionSection *section)
+{
+VFIOContainer *container =
+container_of(listener, VFIOContainer, prereg_listener);
+
+if (!memory_region_is_ram(section->mr) ||
+!container->dirty_pages_supported) {
+return;
+}
+
+if (vfio_devices_all_dirty_tracking(container)) {
+vfio_dma_sync_ram_section_dirty_bitmap(container, section);
+}
+}
+
 typedef struct {
 IOMMUNotifier n;
 VFIOGuestIOMMU *giommu;
@@ -1328,6 +1344,16 @@ static int vfio_sync_dirty_bitmap(VFIOContainer 
*container,
 if (memory_region_is_iommu(section->mr)) {
 VFIOGuestIOMMU *giommu;
 
+/*
+ * In nested mode, stage 2 (gpa->hpa) and stage 1 (giova->gpa) are
+ * set up separately. It is inappropriate to pass 'giova' to kernel
+ * to get dirty pages. We only need to focus on stage 2 mapping when
+ * marking dirty pages.
+ */
+if (container->iommu_type == VFIO_TYPE1_NESTING_IOMMU) {
+return 0;
+}
+
 QLIST_FOREACH(giommu, >giommu_list, giommu_next) {
 if (MEMORY_REGION(giommu->iommu) == section->mr &&
 giommu->n.start == section->offset_within_region) {
@@ -1382,6 +1408,7 @@ static const MemoryListener vfio_memory_listener = {
 static MemoryListener vfio_memory_prereg_listener = {
 .region_add = vfio_prereg_listener_region_add,
 .region_del = vfio_prereg_listener_region_del,
+.log_sync = vfio_prereg_listener_log_sync,
 };
 
 static void vfio_listener_release(VFIOContainer *container)
-- 
2.23.0

[RFC PATCH v3 3/4] vfio: Add vfio_prereg_listener_global_log_start/stop in nested stage

In nested mode, we set up the stage 2 and stage 1 separately. In my
opinion, vfio_memory_prereg_listener is used for stage 2 and
vfio_memory_listener is used for stage 1. So it feels weird to call
the global_log_start/stop interface in vfio_memory_listener to switch
dirty tracking, although this won't cause any errors. Add
global_log_start/stop interface in vfio_memory_prereg_listener
can separate stage 2 from stage 1.

Signed-off-by: Kunkun Jiang 
---
 hw/vfio/common.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index 149e535a75..6e004fc00f 100644
--- a/hw/vfio/common.c
+++ b/hw/vfio/common.c
@@ -1209,6 +1209,17 @@ static void 
vfio_listener_log_global_start(MemoryListener *listener)
 {
 VFIOContainer *container = container_of(listener, VFIOContainer, listener);
 
+/* For nested mode, vfio_prereg_listener is used to start dirty tracking */
+if (container->iommu_type != VFIO_TYPE1_NESTING_IOMMU) {
+vfio_set_dirty_page_tracking(container, true);
+}
+}
+
+static void vfio_prereg_listener_log_global_start(MemoryListener *listener)
+{
+VFIOContainer *container =
+container_of(listener, VFIOContainer, prereg_listener);
+
 vfio_set_dirty_page_tracking(container, true);
 }
 
@@ -1216,6 +1227,17 @@ static void vfio_listener_log_global_stop(MemoryListener 
*listener)
 {
 VFIOContainer *container = container_of(listener, VFIOContainer, listener);
 
+/* For nested mode, vfio_prereg_listener is used to stop dirty tracking */
+if (container->iommu_type != VFIO_TYPE1_NESTING_IOMMU) {
+vfio_set_dirty_page_tracking(container, false);
+}
+}
+
+static void vfio_prereg_listener_log_global_stop(MemoryListener *listener)
+{
+VFIOContainer *container =
+container_of(listener, VFIOContainer, prereg_listener);
+
 vfio_set_dirty_page_tracking(container, false);
 }
 
@@ -1408,6 +1430,8 @@ static const MemoryListener vfio_memory_listener = {
 static MemoryListener vfio_memory_prereg_listener = {
 .region_add = vfio_prereg_listener_region_add,
 .region_del = vfio_prereg_listener_region_del,
+.log_global_start = vfio_prereg_listener_log_global_start,
+.log_global_stop = vfio_prereg_listener_log_global_stop,
 .log_sync = vfio_prereg_listener_log_sync,
 };
 
-- 
2.23.0

[RFC PATCH v3 0/4] Add migration support for VFIO PCI devices in SMMUv3 nested mode

Hi all,

Since the SMMUv3's nested translation stages has been introduced by Eric, we
need to pay attention to the migration of VFIO PCI devices in SMMUv3 nested
stage mode. At present, it is not yet supported in QEMU. There are two problems
in the existing framework.

First, the current way to get dirty pages is not applicable to nested stage
mode. Because of the "Caching Mode", VTD can map the RAM through the host
single stage (giova->hpa). "vfio_listener_log_sync" gets dirty pages by
transferring "giova" to the kernel for the RAM block section of mapped MMIO
region. In nested stage mode, we setup the stage 2 (gpa->hpa) and the stage 1
(giova->gpa) separately. So it is inapplicable to get dirty pages by the
current way in nested stage mode.

Second, it also need to pass stage 1 configurations to the destination host
after the migration. In Eric's patch, it passes the stage 1 configuration to
the host on each STE update for the devices set the PASID PciOps. The
configuration will be applied at physical level. But the data of physical
level will not be sent to the destination host. So we have to pass stage 1
configurations to the destination host after the migration.

This Patch set includes patches as below:
Patch 1-2:
- Refactor the vfio_listener_log_sync and added a new function to get dirty
pages for nested mode

Patch 3:
- Added global_log_start/stop interface in vfio_memory_prereg_listener for
nested mode

Patch 4:
- Added the post_load function to vmstate_smmuv3 for passing stage 1
configuration to the destination host after the migration

Best regards,
Kunkun Jiang

History:

v2 -> v3:
- Rebase to v9 of Eric's series 'vSMMUv3/pSMMUv3 2 stage VFIO integration'[1]
- Delete smmuv3_manual_set_pci_device_pasid_table() and reuse
  smmuv3_notify_config_change() [Eric]

v1 -> v2:
- Add global_log_start/stop interface in vfio_memory_prereg_listener
- Add support for repass stage 1 configs with multiple CDs to the host

[1] [RFC v9 00/29] vSMMUv3/pSMMUv3 2 stage VFIO integration
https://lore.kernel.org/qemu-devel/20210411120912.15770-1-eric.au...@redhat.com/

Kunkun Jiang (4):
  vfio: Introduce helpers to mark dirty pages of a RAM section
  vfio: Add vfio_prereg_listener_log_sync in nested stage
  vfio: Add vfio_prereg_listener_global_log_start/stop in nested stage
  hw/arm/smmuv3: Post-load stage 1 configurations to the host

 hw/arm/smmuv3.c  | 33 ++
 hw/vfio/common.c | 73 ++--
 2 files changed, 93 insertions(+), 13 deletions(-)

-- 
2.23.0

Re: [PATCH] block: Improve backing file validation

2021-05-10 Thread lizhij...@fujitsu.com


On 2021/5/10 16:41, Daniel P. Berrangé wrote:
> On Mon, May 10, 2021 at 12:30:45PM +0800, Li Zhijian wrote:
>> Image below user cases:
>> case 1:
>> ```
>> $ qemu-img create -f raw source.raw 1G
>> $ qemu-img create -f qcow2 -F raw -b source.raw ./source.raw
>> qemu-img info source.raw
>> image: source.raw
>> file format: qcow2
>> virtual size: 193K (197120 bytes)
>> disk size: 196K
>> cluster_size: 65536
>> backing file: source.raw <<
>> backing file format: raw
>> Format specific information:
>>  compat: 1.1
>>  lazy refcounts: false
>>  refcount bits: 16
>>  corrupt: false
>> ```
>>
>> case 2:
>> ```
>> $ qemu-img create -f raw source.raw 1G
>> $ ln -sf source.raw destination.qcow2
>> $ qemu-img create -f qcow2 -F raw -b source.raw ./destination.qcow2
>> qemu-img info source.raw
>> image: source.raw
>> file format: qcow2 <<
>> virtual size: 2.0G (2147483648 bytes)
>> disk size: 196K
>> cluster_size: 65536
>> backing file: source.raw
>> backing file format: raw
>> Format specific information:
>>  compat: 1.1
>>  lazy refcounts: false
>>  refcount bits: 16
>>  corrupt: false
>> ```
>> Generally, we don't expect to corrupte the source.raw anyway, while
>> actually it does.
>>
>> Here we validate the realpath of file instead the input string.
> That still won't handle the case where you use hard links
>
>$ ln source.raw destination.qcow2
>
> To properly validate the scenarios I think it is neccessary
> to ignore the filename sentirely.
>
> Instead attempt to open both files, and if successful, fstat()
> them both, and then compare the st_dev + st_ino  fields.


Sounds great, i will update it.

Thanks

Zhijian

Re: [PATCH v8] introduce vfio-user protocol specification

2021-05-10 Thread John Levon

On Mon, May 10, 2021 at 05:57:37PM +0100, Stefan Hajnoczi wrote:

> On Wed, Apr 14, 2021 at 04:41:22AM -0700, Thanos Makatos wrote:
> 
> Elena A: I CCed you in case you want to review the

Sorry, we should have included Elena already.

> > +VFIO sparse mmap
> > +
> > +
> > ++--+--+
> > +| Name | Value|
> > ++==+==+
> > +| id   | VFIO_REGION_INFO_CAP_SPARSE_MMAP |
> > ++--+--+
> > +| version  | 0x1  |
> > ++--+--+
> > +| next ||
> > ++--+--+
> > +| sparse mmap info | VFIO region info sparse mmap |
> > ++--+--+
> > +
> > +This capability is defined when only a subrange of the region supports
> > +direct access by the client via mmap(). The VFIO sparse mmap area is 
> > defined in
> > + (``struct vfio_region_sparse_mmap_area``).
> 
> It's a little early to reference struct vfio_region_sparse_mmap_area
> here because the parent struct vfio_region_info_cap_sparse_mmap is only
> referenced below. I suggest combining the two:
> 
>   The VFIO sparse mmap area is defined in  (``struct
>   vfio_region_info_cap_sparse_mmap`` and ``struct
>   vfio_region_sparse_mmap_area``).

Good idea.

> > +Region IO FD info format
> > +
> > +
> > ++-++--+
> > +| Name| Offset | Size |
> > ++=++==+
> > +| argsz   | 16 | 4|
> > ++-++--+
> > +| flags   | 20 | 4|
> > ++-++--+
> > +| index   | 24 | 4|
> > ++-++--+
> > +| count   | 28 | 4|
> > ++-++--+
> > +| sub-regions | 32 | ...  |
> > ++-++--+
> > +
> > +* *argsz* is the size of the region IO FD info structure plus the
> > +  total size of the sub-region array. Thus, each array entry "i" is at 
> > offset
> > +  i * ((argsz - 32) / count). Note that currently this is 40 bytes for 
> > both IO
> > +  FD types, but this is not to be relied on.
> > +* *flags* must be zero
> > +* *index* is the index of memory region being queried
> > +* *count* is the number of sub-regions in the array
> > +* *sub-regions* is the array of Sub-Region IO FD info structures
> > +
> > +The client must set ``flags`` to zero and specify the region being queried 
> > in
> > +the ``index``.
> > +
> > +The client sets the ``argsz`` field to indicate the maximum size of the 
> > response
> > +that the server can send, which must be at least the size of the response 
> > header
> > +plus space for the sub-region array. If the full response size exceeds 
> > ``argsz``,
> > +then the server must respond only with the response header and the Region 
> > IO FD
> > +info structure, setting in ``argsz`` the buffer size required to store the 
> > full
> > +response. In this case, no file descriptors are passed back.  The client 
> > then
> > +retries the operation with a larger receive buffer.
> > +
> > +The reply message will additionally include at least one file descriptor 
> > in the
> > +ancillary data. Note that more than one sub-region may share the same file
> > +descriptor.
> 
> How does this interact with the maximum number of file descriptors,
> max_fds? It is possible that there are more sub-regions than max_fds
> allows...

I think this would just be a matter of the client advertising a reasonably large
enough size for max_msg_fds. Do we need to worry about this?

> > +Each sub-region given in the response has one of two possible structures,
> > +depending whether *type* is `VFIO_USER_IO_FD_TYPE_IOEVENTFD` or
> > +`VFIO_USER_IO_FD_TYPE_IOREGIONFD`:
> > +
> > +Sub-Region IO FD info format (ioeventfd)
> > +
> > +
> > ++---++--+
> > +| Name  | Offset | Size |
> > ++===++==+
> > +| offset| 0  | 8|
> > ++---++--+
> > +| size  | 8  | 8|
> > ++---++--+
> > +| fd_index  | 16 | 4|
> > ++---++--+
> > +| type  | 20 | 4|
> > ++---++--+
> > +| flags | 24 | 4|
> > ++---++--+
> > +| padding   | 28 | 4|
> > ++---++--+
> > +| datamatch | 32 | 8|
> > ++---++--+
> > +
> > +* *offset* is the offset of the start of the sub-region within the region
> > +  requested ("physical address offset" for the region)
> > +* *size* is the length of the sub-region. This may be zero if the access 
> > size is
> > +  not relevant, which may allow for optimizations
> > +*

Re: [PATCH 0/3] bsd-user cleanup

2021-05-10 Thread no-reply

Patchew URL: https://patchew.org/QEMU/20210510221511.14205-1-...@bsdimp.com/



Hi,

This series seems to have some coding style problems. See output below for
more information:

Type: series
Message-id: 20210510221511.14205-1-...@bsdimp.com
Subject: [PATCH 0/3] bsd-user cleanup

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag] patchew/20210510221511.14205-1-...@bsdimp.com -> 
patchew/20210510221511.14205-1-...@bsdimp.com
 - [tag update]  patchew/a898b0d5-7086-9699-ae8b-9524ad319...@t-online.de 
-> patchew/a898b0d5-7086-9699-ae8b-9524ad319...@t-online.de
Switched to a new branch 'test'
29436b2 bsd-user: rename linux_binprm to bsd_binprm
6dfc63b bsd-user: Stop building the sparc platforms
7664bfd bsd-user: remove target_signal.h, it's unused

=== OUTPUT BEGIN ===
1/3 Checking commit 7664bfde8daf (bsd-user: remove target_signal.h, it's unused)
Use of uninitialized value $acpi_testexpected in string eq at 
./scripts/checkpatch.pl line 1529.
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#22: 
deleted file mode 100644

total: 0 errors, 1 warnings, 14 lines checked

Patch 1/3 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
2/3 Checking commit 6dfc63b98ef1 (bsd-user: Stop building the sparc platforms)
Use of uninitialized value $acpi_testexpected in string eq at 
./scripts/checkpatch.pl line 1529.
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#21: 
deleted file mode 100644

total: 0 errors, 1 warnings, 0 lines checked

Patch 2/3 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
3/3 Checking commit 29436b2be985 (bsd-user: rename linux_binprm to bsd_binprm)
ERROR: "foo * bar" should be "foo *bar"
#58: FILE: bsd-user/elfload.c:1146:
+int load_elf_binary(struct bsd_binprm * bprm, struct target_pt_regs * regs,

ERROR: "foo * bar" should be "foo *bar"
#80: FILE: bsd-user/qemu.h:134:
+int load_elf_binary(struct bsd_binprm * bprm, struct target_pt_regs * regs,

ERROR: "foo * bar" should be "foo *bar"
#83: FILE: bsd-user/qemu.h:136:
+int load_flt_binary(struct bsd_binprm * bprm, struct target_pt_regs * regs,

total: 3 errors, 0 warnings, 51 lines checked

Patch 3/3 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20210510221511.14205-1-...@bsdimp.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

[PATCH 1/3] bsd-user: remove target_signal.h, it's unused

Remove the target_signal.h file. None of its contents are currently used and the
bsd-user fork doesn't use them (so this reduces the diffs there).

Signed-off-by: Warner Losh 
---
 bsd-user/i386/target_signal.h| 20 
 bsd-user/qemu.h  |  1 -
 bsd-user/signal.c|  1 -
 bsd-user/sparc/target_signal.h   | 27 ---
 bsd-user/sparc64/target_signal.h | 27 ---
 bsd-user/x86_64/target_signal.h  | 19 ---
 6 files changed, 95 deletions(-)
 delete mode 100644 bsd-user/i386/target_signal.h
 delete mode 100644 bsd-user/sparc/target_signal.h
 delete mode 100644 bsd-user/sparc64/target_signal.h
 delete mode 100644 bsd-user/x86_64/target_signal.h

diff --git a/bsd-user/i386/target_signal.h b/bsd-user/i386/target_signal.h
deleted file mode 100644
index 2ef36d1f98..00
--- a/bsd-user/i386/target_signal.h
+++ /dev/null
@@ -1,20 +0,0 @@
-#ifndef TARGET_SIGNAL_H
-#define TARGET_SIGNAL_H
-
-#include "cpu.h"
-
-/* this struct defines a stack used during syscall handling */
-
-typedef struct target_sigaltstack {
-   abi_ulong ss_sp;
-   abi_long ss_flags;
-   abi_ulong ss_size;
-} target_stack_t;
-
-
-static inline abi_ulong get_sp_from_cpustate(CPUX86State *state)
-{
-return state->regs[R_ESP];
-}
-
-#endif /* TARGET_SIGNAL_H */
diff --git a/bsd-user/qemu.h b/bsd-user/qemu.h
index 5a82722281..369c649fe5 100644
--- a/bsd-user/qemu.h
+++ b/bsd-user/qemu.h
@@ -38,7 +38,6 @@ extern enum BSDType bsd_type;
 
 #include "syscall_defs.h"
 #include "target_syscall.h"
-#include "target_signal.h"
 #include "exec/gdbstub.h"
 
 #if defined(CONFIG_USE_NPTL)
diff --git a/bsd-user/signal.c b/bsd-user/signal.c
index f6f7aa2427..ad6d935569 100644
--- a/bsd-user/signal.c
+++ b/bsd-user/signal.c
@@ -19,7 +19,6 @@
 #include "qemu/osdep.h"
 
 #include "qemu.h"
-#include "target_signal.h"
 
 void signal_init(void)
 {
diff --git a/bsd-user/sparc/target_signal.h b/bsd-user/sparc/target_signal.h
deleted file mode 100644
index 5b2abba40f..00
--- a/bsd-user/sparc/target_signal.h
+++ /dev/null
@@ -1,27 +0,0 @@
-#ifndef TARGET_SIGNAL_H
-#define TARGET_SIGNAL_H
-
-#include "cpu.h"
-
-/* this struct defines a stack used during syscall handling */
-
-typedef struct target_sigaltstack {
-   abi_ulong ss_sp;
-   abi_long ss_flags;
-   abi_ulong ss_size;
-} target_stack_t;
-
-
-#ifndef UREG_I6
-#define UREG_I66
-#endif
-#ifndef UREG_FP
-#define UREG_FPUREG_I6
-#endif
-
-static inline abi_ulong get_sp_from_cpustate(CPUSPARCState *state)
-{
-return state->regwptr[UREG_FP];
-}
-
-#endif /* TARGET_SIGNAL_H */
diff --git a/bsd-user/sparc64/target_signal.h b/bsd-user/sparc64/target_signal.h
deleted file mode 100644
index 5b2abba40f..00
--- a/bsd-user/sparc64/target_signal.h
+++ /dev/null
@@ -1,27 +0,0 @@
-#ifndef TARGET_SIGNAL_H
-#define TARGET_SIGNAL_H
-
-#include "cpu.h"
-
-/* this struct defines a stack used during syscall handling */
-
-typedef struct target_sigaltstack {
-   abi_ulong ss_sp;
-   abi_long ss_flags;
-   abi_ulong ss_size;
-} target_stack_t;
-
-
-#ifndef UREG_I6
-#define UREG_I66
-#endif
-#ifndef UREG_FP
-#define UREG_FPUREG_I6
-#endif
-
-static inline abi_ulong get_sp_from_cpustate(CPUSPARCState *state)
-{
-return state->regwptr[UREG_FP];
-}
-
-#endif /* TARGET_SIGNAL_H */
diff --git a/bsd-user/x86_64/target_signal.h b/bsd-user/x86_64/target_signal.h
deleted file mode 100644
index 659cd401b8..00
--- a/bsd-user/x86_64/target_signal.h
+++ /dev/null
@@ -1,19 +0,0 @@
-#ifndef TARGET_SIGNAL_H
-#define TARGET_SIGNAL_H
-
-#include "cpu.h"
-
-/* this struct defines a stack used during syscall handling */
-
-typedef struct target_sigaltstack {
-   abi_ulong ss_sp;
-   abi_long ss_flags;
-   abi_ulong ss_size;
-} target_stack_t;
-
-static inline abi_ulong get_sp_from_cpustate(CPUX86State *state)
-{
-return state->regs[R_ESP];
-}
-
-#endif /* TARGET_SIGNAL_H */
-- 
2.22.1

[PATCH 3/3] bsd-user: rename linux_binprm to bsd_binprm

Rename linux_binprm to bsd_binprm to reflect that we're loading BSD binaries,
not ELF ones.

Signed-off-by: Warner Losh 
---
 bsd-user/bsdload.c | 4 ++--
 bsd-user/elfload.c | 4 ++--
 bsd-user/qemu.h| 6 +++---
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/bsd-user/bsdload.c b/bsd-user/bsdload.c
index e1ed3b7b60..8d83f21eda 100644
--- a/bsd-user/bsdload.c
+++ b/bsd-user/bsdload.c
@@ -32,7 +32,7 @@ static int count(char **vec)
 return i;
 }
 
-static int prepare_binprm(struct linux_binprm *bprm)
+static int prepare_binprm(struct bsd_binprm *bprm)
 {
 struct stat st;
 int mode;
@@ -127,7 +127,7 @@ abi_ulong loader_build_argptr(int envc, int argc, abi_ulong 
sp,
 int loader_exec(const char *filename, char **argv, char **envp,
  struct target_pt_regs *regs, struct image_info *infop)
 {
-struct linux_binprm bprm;
+struct bsd_binprm bprm;
 int retval;
 int i;
 
diff --git a/bsd-user/elfload.c b/bsd-user/elfload.c
index 5f4d824d78..d658d722a5 100644
--- a/bsd-user/elfload.c
+++ b/bsd-user/elfload.c
@@ -662,7 +662,7 @@ static abi_ulong copy_elf_strings(int argc,char ** argv, 
void **page,
 return p;
 }
 
-static abi_ulong setup_arg_pages(abi_ulong p, struct linux_binprm *bprm,
+static abi_ulong setup_arg_pages(abi_ulong p, struct bsd_binprm *bprm,
  struct image_info *info)
 {
 abi_ulong stack_base, size, error;
@@ -1143,7 +1143,7 @@ static void load_symbols(struct elfhdr *hdr, int fd)
 syminfos = s;
 }
 
-int load_elf_binary(struct linux_binprm * bprm, struct target_pt_regs * regs,
+int load_elf_binary(struct bsd_binprm * bprm, struct target_pt_regs * regs,
 struct image_info * info)
 {
 struct elfhdr elf_ex;
diff --git a/bsd-user/qemu.h b/bsd-user/qemu.h
index 369c649fe5..5c33b4279f 100644
--- a/bsd-user/qemu.h
+++ b/bsd-user/qemu.h
@@ -114,7 +114,7 @@ extern unsigned long mmap_min_addr;
  * This structure is used to hold the arguments that are
  * used when loading binaries.
  */
-struct linux_binprm {
+struct bsd_binprm {
 char buf[128];
 void *page[MAX_ARG_PAGES];
 abi_ulong p;
@@ -132,9 +132,9 @@ abi_ulong loader_build_argptr(int envc, int argc, abi_ulong 
sp,
 int loader_exec(const char * filename, char ** argv, char ** envp,
  struct target_pt_regs * regs, struct image_info *infop);
 
-int load_elf_binary(struct linux_binprm * bprm, struct target_pt_regs * regs,
+int load_elf_binary(struct bsd_binprm * bprm, struct target_pt_regs * regs,
 struct image_info * info);
-int load_flt_binary(struct linux_binprm * bprm, struct target_pt_regs * regs,
+int load_flt_binary(struct bsd_binprm * bprm, struct target_pt_regs * regs,
 struct image_info * info);
 
 abi_long memcpy_to_target(abi_ulong dest, const void *src,
-- 
2.22.1

[PATCH 0/3] bsd-user cleanup

Three more bsd-user cleanups.

The general plan after these patches is to get and keep i386 working as I flush
out the loader, the basic system calls, system tracing, etc.  I'll move files
around so they are like the current bsd-user tree.  Once that's all done, I'll
add the different architectures we currently support. Sparc64 was removed from
FreeBSD and never really worked in bsd-user, so would need to be deleted
eventually anyway. If we do it at the start of the series, we'll reduce the
burden on getting the other things in w/o ditching functionality we'll need in
the end.

Short term, this just removes sparc from the build, deletes a file that's
not in the final product and renames a bsd-specific structure to have
a bsd name, not a linux one.

Warner Losh (3):
  bsd-user: remove target_signal.h, it's unused
  bsd-user: Stop building the sparc platforms
  bsd-user: rename linux_binprm to bsd_binprm

 bsd-user/bsdload.c   |  4 +--
 bsd-user/elfload.c   |  4 +--
 bsd-user/i386/target_signal.h| 20 ---
 bsd-user/qemu.h  |  7 +++--
 bsd-user/signal.c|  1 -
 bsd-user/sparc/target_signal.h   | 27 
 bsd-user/sparc64/target_signal.h | 27 
 bsd-user/x86_64/target_signal.h  | 19 --
 default-configs/targets/sparc-bsd-user.mak   |  3 ---
 default-configs/targets/sparc64-bsd-user.mak |  4 ---
 10 files changed, 7 insertions(+), 109 deletions(-)
 delete mode 100644 bsd-user/i386/target_signal.h
 delete mode 100644 bsd-user/sparc/target_signal.h
 delete mode 100644 bsd-user/sparc64/target_signal.h
 delete mode 100644 bsd-user/x86_64/target_signal.h
 delete mode 100644 default-configs/targets/sparc-bsd-user.mak
 delete mode 100644 default-configs/targets/sparc64-bsd-user.mak

-- 
2.22.1

[PATCH 2/3] bsd-user: Stop building the sparc platforms

The forked bsd-user tree doesn't really support these platforms.  They aren't
functional at the moment anyway. Remove them from the build so that the major
reorg patch series can focus on one platform (x86) before adding addition
platforms once things are shuffled. This should make it easier to review
and satisfy that all revisions of a patch series are buildable.

Signed-off-by: Warner Losh 
---
 default-configs/targets/sparc-bsd-user.mak   | 3 ---
 default-configs/targets/sparc64-bsd-user.mak | 4 
 2 files changed, 7 deletions(-)
 delete mode 100644 default-configs/targets/sparc-bsd-user.mak
 delete mode 100644 default-configs/targets/sparc64-bsd-user.mak

diff --git a/default-configs/targets/sparc-bsd-user.mak 
b/default-configs/targets/sparc-bsd-user.mak
deleted file mode 100644
index 9ba3d7b07f..00
--- a/default-configs/targets/sparc-bsd-user.mak
+++ /dev/null
@@ -1,3 +0,0 @@
-TARGET_ARCH=sparc
-TARGET_ALIGNED_ONLY=y
-TARGET_WORDS_BIGENDIAN=y
diff --git a/default-configs/targets/sparc64-bsd-user.mak 
b/default-configs/targets/sparc64-bsd-user.mak
deleted file mode 100644
index 8dd3217800..00
--- a/default-configs/targets/sparc64-bsd-user.mak
+++ /dev/null
@@ -1,4 +0,0 @@
-TARGET_ARCH=sparc64
-TARGET_BASE_ARCH=sparc
-TARGET_ALIGNED_ONLY=y
-TARGET_WORDS_BIGENDIAN=y
-- 
2.22.1

Re: [PATCH v2 00/11] PS/2 controller related fixes

2021-05-10 Thread Volker Rümelin


This patch series fixes two different PS/2 mouse stream corruptions
and adds a feature that allows some old misbehaving DOS programs to
have a working keyboard. With the last few patches, the PS/2 con-
troller behaves more like a real controller.

v2:
Introduce the function kbd_pending() in a preliminary patch to ease
the review of patch "pckbd: correctly disable PS/2 communication",
as Philippe suggested.

Volker Rümelin (11):
  ps2: fix mouse stream corruption
  ps2: don't raise an interrupt if queue is full
  ps2: don't deassert irq twice if queue is empty
  pckbd: split out interrupt line changing code
  pckbd: don't update OBF flags if KBD_STAT_OBF is set
  pckbd: PS/2 keyboard throttle
  pckbd: add state variable for interrupt source
  pckbd: add controller response queue
  pckbd: add function kbd_pending()
  pckbd: correctly disable PS/2 communication
  pckbd: remove duplicated keyboard and mouse defines


I'm sorry, there is a bug somewhere in this series. Seabios sometimes
doesn't detect the PS/2 keyboard. Please ignore this series for now.



This is a Seabios bug. Seabios expects the PS/2 controller doesn't
generate interrupts after it sends the command KBD_CCMD_KBD_DISABLE
to the controller. Even the original author of the pckbd code wrote
in a comment that this is incorrect. I will send a version 3 series
where I don't fix the incorrectness.


With best regards,
Volker



 hw/input/pckbd.c | 293 ++-
 hw/input/ps2.c   |  11 +-
 2 files changed, 223 insertions(+), 81 deletions(-)

[PATCH v3 1/2] bitops.h: Improve find_xxx_bit() documentation

Document the following functions return the bitmap size
if no matching bit is found:

- find_first_bit
- find_next_bit
- find_last_bit
- find_first_zero_bit
- find_next_zero_bit

Reviewed-by: Richard Henderson 
Signed-off-by: Philippe Mathieu-Daudé 
---
 include/qemu/bitops.h | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/include/qemu/bitops.h b/include/qemu/bitops.h
index 3acbf3384c6..a72f69fea85 100644
--- a/include/qemu/bitops.h
+++ b/include/qemu/bitops.h
@@ -140,7 +140,8 @@ static inline int test_bit(long nr, const unsigned long 
*addr)
  * @addr: The address to start the search at
  * @size: The maximum size to search
  *
- * Returns the bit number of the first set bit, or size.
+ * Returns the bit number of the last set bit,
+ * or @size if there is no set bit in the bitmap.
  */
 unsigned long find_last_bit(const unsigned long *addr,
 unsigned long size);
@@ -150,6 +151,9 @@ unsigned long find_last_bit(const unsigned long *addr,
  * @addr: The address to base the search on
  * @offset: The bitnumber to start searching at
  * @size: The bitmap size in bits
+ *
+ * Returns the bit number of the next set bit,
+ * or @size if there are no further set bits in the bitmap.
  */
 unsigned long find_next_bit(const unsigned long *addr,
 unsigned long size,
@@ -160,6 +164,9 @@ unsigned long find_next_bit(const unsigned long *addr,
  * @addr: The address to base the search on
  * @offset: The bitnumber to start searching at
  * @size: The bitmap size in bits
+ *
+ * Returns the bit number of the next cleared bit,
+ * or @size if there are no further clear bits in the bitmap.
  */
 
 unsigned long find_next_zero_bit(const unsigned long *addr,
@@ -171,7 +178,8 @@ unsigned long find_next_zero_bit(const unsigned long *addr,
  * @addr: The address to start the search at
  * @size: The maximum size to search
  *
- * Returns the bit number of the first set bit.
+ * Returns the bit number of the first set bit,
+ * or @size if there is no set bit in the bitmap.
  */
 static inline unsigned long find_first_bit(const unsigned long *addr,
unsigned long size)
@@ -194,7 +202,8 @@ static inline unsigned long find_first_bit(const unsigned 
long *addr,
  * @addr: The address to start the search at
  * @size: The maximum size to search
  *
- * Returns the bit number of the first cleared bit.
+ * Returns the bit number of the first cleared bit,
+ * or @size if there is no clear bit in the bitmap.
  */
 static inline unsigned long find_first_zero_bit(const unsigned long *addr,
 unsigned long size)
-- 
2.26.3

[PATCH v3 2/2] virtio-blk: Convert QEMUBH callback to "bitops.h" API

By directly using find_first_bit() and find_next_bit from the
"bitops.h" API to iterate over the bitmap, we can remove the
bitmap[] variable-length array copy on the stack and the complex
manual bit testing/clearing logic.

Suggested-by: Stefan Hajnoczi 
Suggested-by: Richard Henderson 
Reviewed-by: Richard Henderson 
Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/block/dataplane/virtio-blk.c | 20 +---
 1 file changed, 5 insertions(+), 15 deletions(-)

diff --git a/hw/block/dataplane/virtio-blk.c b/hw/block/dataplane/virtio-blk.c
index e9050c8987e..a31fa94ca33 100644
--- a/hw/block/dataplane/virtio-blk.c
+++ b/hw/block/dataplane/virtio-blk.c
@@ -60,24 +60,14 @@ static void notify_guest_bh(void *opaque)
 {
 VirtIOBlockDataPlane *s = opaque;
 unsigned nvqs = s->conf->num_queues;
-unsigned long bitmap[BITS_TO_LONGS(nvqs)];
-unsigned j;
 
-memcpy(bitmap, s->batch_notify_vqs, sizeof(bitmap));
-memset(s->batch_notify_vqs, 0, sizeof(bitmap));
+for (unsigned long i = find_first_bit(s->batch_notify_vqs, nvqs);
+ i < nvqs; i = find_next_bit(s->batch_notify_vqs, nvqs, i)) {
+VirtQueue *vq = virtio_get_queue(s->vdev, i);
 
-for (j = 0; j < nvqs; j += BITS_PER_LONG) {
-unsigned long bits = bitmap[j / BITS_PER_LONG];
-
-while (bits != 0) {
-unsigned i = j + ctzl(bits);
-VirtQueue *vq = virtio_get_queue(s->vdev, i);
-
-virtio_notify_irqfd(s->vdev, vq);
-
-bits &= bits - 1; /* clear right-most bit */
-}
+virtio_notify_irqfd(s->vdev, vq);
 }
+bitmap_clear(s->batch_notify_vqs, 0, nvqs);
 }
 
 /* Context: QEMU global mutex held */
-- 
2.26.3

[PATCH v3 0/2] virtio-blk: Convert QEMUBH callback to "bitops.h" API

This series follow a suggestion from Stefan to use the bitops
API in virtio-blk:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg805139.html

Since v2:
- clear bitmap to avoid spurious interrupts! (Stefan)
- use 'further' in find_next docstring (Eric)
- added Richard R-b tag

Since v1:
- improved "bitops.h" docstring
- addressed Richard's review comments

Philippe Mathieu-Daudé (2):
  bitops.h: Improve find_xxx_bit() documentation
  virtio-blk: Convert QEMUBH callback to "bitops.h" API

 include/qemu/bitops.h   | 15 ---
 hw/block/dataplane/virtio-blk.c | 20 +---
 2 files changed, 17 insertions(+), 18 deletions(-)

-- 
2.26.3

Re: [PATCH updated v2] spapr: Fix EEH capability issue on KVM guest for PCI passthru

2021-05-10 Thread Daniel Henrique Barboza





On 5/5/21 11:48 AM, Mahesh Salgaonkar wrote:

With upstream kernel, especially after commit 98ba956f6a389
("powerpc/pseries/eeh: Rework device EEH PE determination") we see that KVM
guest isn't able to enable EEH option for PCI pass-through devices anymore.

[root@atest-guest ~]# dmesg | grep EEH
[0.032337] EEH: pSeries platform initialized
[0.298207] EEH: No capable adapters found: recovery disabled.
[root@atest-guest ~]#

So far the linux kernel was assuming pe_config_addr equal to device's
config_addr and using it to enable EEH on the PE through ibm,set-eeh-option
RTAS call. Which wasn't the correct way as per PAPR. The linux kernel
commit 98ba956f6a389 fixed this flow. With that fixed, linux now uses PE
config address returned by ibm,get-config-addr-info2 RTAS call to enable
EEH option per-PE basis instead of per-device basis. However this has
uncovered a bug in qemu where ibm,set-eeh-option is treating PE config
address as per-device config address.

Hence in qemu guest with recent kernel the ibm,set-eeh-option RTAS call
fails with -3 return value indicating that there is no PCI device exist for
the specified PE config address. The rtas_ibm_set_eeh_option call uses
pci_find_device() to get the PC device that matches specific bus and devfn
extracted from PE config address passed as argument. Thus it tries to map
the PE config address to a single specific PCI device 'bus->devices[devfn]'
which always results into checking device on slot 0 'bus->devices[0]'.
This succeeds when there is a pass-through device (vfio-pci) present in
slot 0. But in cases where there is no pass-through device present in slot
0, but present in non-zero slots, ibm,set-eeh-option call fails to enable
the EEH capability.

hw/ppc/spapr_pci_vfio.c: spapr_phb_vfio_eeh_set_option()
case RTAS_EEH_ENABLE: {
 PCIHostState *phb;
 PCIDevice *pdev;

 /*
  * The EEH functionality is enabled on basis of PCI device,
  * instead of PE. We need check the validity of the PCI
  * device address.
  */
 phb = PCI_HOST_BRIDGE(sphb);
 pdev = pci_find_device(phb->bus,
(addr >> 16) & 0xFF, (addr >> 8) & 0xFF);
 if (!pdev || !object_dynamic_cast(OBJECT(pdev), "vfio-pci")) {
 return RTAS_OUT_PARAM_ERROR;
 }

hw/pci/pci.c:pci_find_device()

PCIDevice *pci_find_device(PCIBus *bus, int bus_num, uint8_t devfn)
{
 bus = pci_find_bus_nr(bus, bus_num);

 if (!bus)
 return NULL;

 return bus->devices[devfn];
}

This patch fixes ibm,set-eeh-option to check for presence of any PCI device
(vfio-pci) under specified bus and enable the EEH if found. The current
code already makes sure that all the devices on that bus are from same
iommu group (within same PE) and fail very early if it does not.

After this fix guest is able to find EEH capable devices and enable EEH
recovery on it.

[root@atest-guest ~]# dmesg | grep EEH
[0.048139] EEH: pSeries platform initialized
[0.405115] EEH: Capable adapter found: recovery enabled.
[root@atest-guest ~]#

Signed-off-by: Mahesh Salgaonkar 
---


Reviewed-by: Daniel Henrique Barboza 


Change in v2:
- Fix ibm,set-eeh-option instead of returning per-device PE config address.
- Changed patch subject line.
---
  hw/ppc/spapr_pci_vfio.c |   27 ---
  1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/hw/ppc/spapr_pci_vfio.c b/hw/ppc/spapr_pci_vfio.c
index e0547b1740..b30020da6a 100644
--- a/hw/ppc/spapr_pci_vfio.c
+++ b/hw/ppc/spapr_pci_vfio.c
@@ -47,6 +47,16 @@ void spapr_phb_vfio_reset(DeviceState *qdev)
  spapr_phb_vfio_eeh_reenable(SPAPR_PCI_HOST_BRIDGE(qdev));
  }
  
+static void spapr_eeh_pci_find_device(PCIBus *bus, PCIDevice *pdev,

+  void *opaque)
+{
+bool *found = opaque;
+
+if (object_dynamic_cast(OBJECT(pdev), "vfio-pci")) {
+*found = true;
+}
+}
+
  int spapr_phb_vfio_eeh_set_option(SpaprPhbState *sphb,
unsigned int addr, int option)
  {
@@ -59,17 +69,20 @@ int spapr_phb_vfio_eeh_set_option(SpaprPhbState *sphb,
  break;
  case RTAS_EEH_ENABLE: {
  PCIHostState *phb;
-PCIDevice *pdev;
+bool found = false;
  
  /*

- * The EEH functionality is enabled on basis of PCI device,
- * instead of PE. We need check the validity of the PCI
- * device address.
+ * The EEH functionality is enabled per sphb level instead of
+ * per PCI device. We just need to check the validity of the PCI
+ * pass-through devices (vfio-pci) under this sphb bus.
+ * We have already validated that all the devices under this sphb
+ * are from same iommu group (within same PE) before comming here.
   */
  phb = PCI_HOST_BRIDGE(sphb);
-pdev = pci_find_device(phb->bus,
-   (addr >> 16) & 0xFF, (addr

Re: [PATCH 3/4] gitlab-ci: Run GNU make via the $MAKE variable

On 5/10/21 5:22 PM, Philippe Mathieu-Daudé wrote:
> Add the $MAKE variable to call GNU make, and set it to 'gmake'
> on FreeBSD to avoid:
> 
>   $ make -j"$JOBS"
>   make: Unknown modifier ','
>   make: "/builds/dTyar424/0/qemu/build/Makefile" line 3: Need an operator
>   make: "/builds/dTyar424/0/qemu/build/Makefile" line 4: Missing dependency 
> operator
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  .gitlab-ci.yml | 14 +-
>  1 file changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index aceaac5a398..a33e51bf453 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -19,9 +19,11 @@ include:
>  test $(uname) = "FreeBSD"
>  ;
>then
> +MAKE=gmake
>  JOBS=$(sysctl -n hw.ncpu)
>  ;
>else
> +MAKE=make
>  JOBS=$(expr $(nproc) + 1)
>  ;
>fi
> @@ -44,22 +46,23 @@ include:
>then
>  meson configure . -Dbackend_max_links="$LD_JOBS" ;
>fi || exit 1;
> -- make -j"$JOBS"
> +- $MAKE -j"$JOBS"
>  - if test -n "$MAKE_CHECK_ARGS";
>then
> -make -j"$JOBS" $MAKE_CHECK_ARGS ;
> +$MAKE -j"$JOBS" $MAKE_CHECK_ARGS ;
>fi
>  
>  .native_test_job_template:
>stage: test
>image: $CI_REGISTRY_IMAGE/qemu/$IMAGE:latest
> +  extends: .environment_variables_template
>script:
>  - scripts/git-submodule.sh update
>  $(sed -n '/GIT_SUBMODULES=/ s/.*=// p' build/config-host.mak)
>  - cd build
>  - find . -type f -exec touch {} +
>  # Avoid recompiling by hiding ninja with NINJA=":"
> -- make NINJA=":" $MAKE_CHECK_ARGS
> +- $MAKE NINJA=":" $MAKE_CHECK_ARGS
>  
>  .acceptance_template: _definition
>cache:

I forgot this hunk:

-- >8 --
@@ -70,6 +70,7 @@ include:
 - $MAKE NINJA=":" $MAKE_CHECK_ARGS

 .acceptance_template: _definition
+  extends: .environment_variables_template
   cache:
 key: "${CI_JOB_NAME}-cache"
 paths:
---

> @@ -833,17 +836,18 @@ build-tools-and-docs-debian:
>  pages:
>image: $CI_REGISTRY_IMAGE/qemu/debian-amd64:latest
>stage: test
> +  extends: .environment_variables_template
>needs:
>  - job: build-tools-and-docs-debian
>script:
>  - mkdir -p public
>  # HTML-ised source tree
> -- make gtags
> +- $MAKE gtags
>  - htags -anT --tree-view=filetree -m qemu_init
>  -t "Welcome to the QEMU sourcecode"
>  - mv HTML public/src
>  # Project documentation
> -- make -C build install DESTDIR=$(pwd)/temp-install
> +- $MAKE -C build install DESTDIR=$(pwd)/temp-install
>  - mv temp-install/usr/local/share/doc/qemu/* public/
>artifacts:
>  paths:
>

Re: [PATCH 0/6] hw/arm: Fix modelling of SSE-300 TCMs and SRAM

On 5/10/21 9:22 PM, Peter Maydell wrote:
> On Mon, 10 May 2021 at 20:14, Philippe Mathieu-Daudé  wrote:
>>
>> Hi Peter,
>>
>> On 5/10/21 9:08 PM, Peter Maydell wrote:
>>> This patchset fixes some bugs in how we were modelling the
>>> TCMs and the SRAM in the SSE-300 which were preventing
>>> Arm TF-M from booting on our AN547 model; there are also
>>> some fixes to things I noticed while I was in the code.
>>>
>>> The specific bugs preventing boot were:
>>>  * SRAM_ADDR_WIDTH for the AN547 is 21, not 15, so the SRAM
>>>area was too small
>>>  * we were putting the SRAMs at the wrong address (0x2100_
>>>for SSE-300, not 0x2000_ as for SSE-200)
>>
>> How can we test it?
> 
> I tested using a binary that Devaraj provided me. As usual,
> I don't know if there's anything that would be a sufficiently
> "publicly hosted, with associated source for licensing purposes"
> binary that we could put into tests/acceptance.

OK, thank you.

Phil.

Re: [PATCH 0/7] vhost-user-gpu: fix several security issues

On 5/5/21 11:35 AM, Marc-André Lureau wrote:
> Hi
> 
> On Wed, May 5, 2021 at 1:28 PM Li Qiang  > wrote:
> 
> Marc-André Lureau  > 于2021年5月5日周三 下午5:10写道：
> >
> > Hi
> >
> > On Wed, May 5, 2021 at 9:21 AM Li Qiang  > wrote:
> >>
> >> These security issue is low severity and is similar with the
> >> virtio-vga/virtio-gpu device. All of them can be triggered by
> >> the guest user.
> >>
> >> Li Qiang (7):
> >>   vhost-user-gpu: fix memory disclosure in virgl_cmd_get_capset_info
> >>   vhost-user-gpu: fix resource leak in 'vg_resource_create_2d'
> >>   vhost-user-gpu: fix memory leak in vg_resource_attach_backing
> >>   vhost-user-gpu: fix memory link while calling 'vg_resource_unref'
> >>   vhost-user-gpu: fix memory leak in 'virgl_cmd_resource_unref'
> >>   vhost-user-gpu: fix memory leak in 'virgl_resource_attach_backing'
> >>   vhost-user-gpu: fix OOB write in 'virgl_cmd_get_capset'
> >>
> >>  contrib/vhost-user-gpu/vhost-user-gpu.c |  7 +++
> >>  contrib/vhost-user-gpu/virgl.c          | 17 -
> >>  2 files changed, 23 insertions(+), 1 deletion(-)
> >>
> >> --
> >
> >
> > The whole series looks good to me, and applies fixes that were
> done earlier in virtio-gpu.
> 
> Do you mean you have merged this series?
> Should I tweak something such as "adding the original fix in
> virtio-gpu"/"better mapping iov cleanup"?

Yes, and please also mention the corresponding CVE (CVE-2021-3544,
CVE-2021-3545, CVE-2021-3546).

> 
> 
> No I didn't. I was waiting for the answers to Prasad questions, and
> eventually v2.
> 
> Then either Gerd or me can queue this imho.
>  
> -- 
> Marc-André Lureau

Re: [PATCH 0/6] hw/arm: Fix modelling of SSE-300 TCMs and SRAM

On Mon, 10 May 2021 at 20:14, Philippe Mathieu-Daudé  wrote:
>
> Hi Peter,
>
> On 5/10/21 9:08 PM, Peter Maydell wrote:
> > This patchset fixes some bugs in how we were modelling the
> > TCMs and the SRAM in the SSE-300 which were preventing
> > Arm TF-M from booting on our AN547 model; there are also
> > some fixes to things I noticed while I was in the code.
> >
> > The specific bugs preventing boot were:
> >  * SRAM_ADDR_WIDTH for the AN547 is 21, not 15, so the SRAM
> >area was too small
> >  * we were putting the SRAMs at the wrong address (0x2100_
> >for SSE-300, not 0x2000_ as for SSE-200)
>
> How can we test it?

I tested using a binary that Devaraj provided me. As usual,
I don't know if there's anything that would be a sufficiently
"publicly hosted, with associated source for licensing purposes"
binary that we could put into tests/acceptance.

-- PMM

[Bug 1907210] Re: QEMU gdbstub command "?" issue

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


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

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

Title:
  QEMU gdbstub command "?" issue

Status in QEMU:
  Incomplete

Bug description:
  I am using some third party GDB client, and I have noticed that every time 
"?" command is send from the client, QEMU gdbstub removes all break points. 
This behaviour is not expected since "?" command should only return stop reason.
  Here is documentation from official gdb:
  ‘?’ Indicate the reason the target halted. The reply is the same as for step 
and
  continue. This packet has a special interpretation when the target is in 
non-stop
  mode; see Section E.10 [Remote Non-Stop], page 733.
  Reply: See Section E.3 [Stop Reply Packets], page 693, for the reply 
specifications.

  With some help on the irc, we have been able to pin point the failure 
point(in attachement file gdbstub.c).
  Function that handles "?" command has this comment in it:
  /*
   * Remove all the breakpoints when this query is issued,
   * because gdb is doing an initial connect and the state
   * should be cleaned up.
   */
  From which it is clear that developer that wrote that code assumed, that 
because most popular gdb client only uses "?" command at initial connect, it is 
safe to also remove all BPs.
  In my opinion initial connect should be detected in some other way, and not 
with "?" command.
  Also note that official gdbserver does not remove the BPs when this command 
is send, this issue is present in QEMU and apparently also on kgdb(I was told 
that on irc, have not tested it myself)

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

[Bug 1907061] Re: qemu-system-x86_64 minimizing window causes keyboard input lag globally

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


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

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

Title:
  qemu-system-x86_64 minimizing window causes keyboard input lag
  globally

Status in QEMU:
  Incomplete

Bug description:
  After qemu window is minimized, it causes keyboard lag on the host for all 
applications, pressed keys will be delayed and very laggy, typing to notepad or 
any other text extremely slowly appear on the screen, queue is slowly processed.
  If qemu window is open back to normal size, keyboard is back to normal, 
everything is back to normal and stable, this behavior i have been testing 
since several months of qemu releases, i am reporting a bit late here, not 
breaking but it seems important and everytime i accidently minimize qemu, i 
remember it later and take qemu window to normal size back always, i try never 
minimize it anymore.
  This problem does not occur if using -display none
  Guest OS doesn't matter for this behavior, result is always same
  I am using:
  qemu 5.1.0.0
  qemu-system-x86_64w.exe
  Windows 10 build 2004
  4K screen dpi scaling set to 150%

  If requested, i can record a video to see the problem clearly, but i
  think all information i give already clear now.

  Thanks for making quality software, hope all bugs fixed

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

Re: [for-6.1 v3 2/3] virtiofsd: Track mounts

2021-05-10 Thread Vivek Goyal

On Mon, May 10, 2021 at 05:55:38PM +0200, Greg Kurz wrote:
> The upcoming implementation of ->sync_fs() needs to know about all
> submounts in order to call syncfs() on all of them.
> 
> Track every inode that comes up with a new mount id in a GHashTable.
> If the mount id isn't available, e.g. no statx() on the host, fallback
> on the device id for the key. This is done during lookup because we
> only care for the submounts that the client knows about. The inode
> is removed from the hash table when ultimately unreferenced. This
> can happen on a per-mount basis when the client posts a FUSE_FORGET
> request or for all submounts at once with FUSE_DESTROY.
> 
> Signed-off-by: Greg Kurz 
> ---
>  tools/virtiofsd/passthrough_ll.c | 42 +---
>  1 file changed, 39 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/virtiofsd/passthrough_ll.c 
> b/tools/virtiofsd/passthrough_ll.c
> index 1553d2ef454f..dc940a1d048b 100644
> --- a/tools/virtiofsd/passthrough_ll.c
> +++ b/tools/virtiofsd/passthrough_ll.c
> @@ -117,6 +117,7 @@ struct lo_inode {
>  GHashTable *posix_locks; /* protected by lo_inode->plock_mutex */
>  
>  mode_t filetype;
> +bool is_mnt;
>  };
>  
>  struct lo_cred {
> @@ -163,6 +164,7 @@ struct lo_data {
>  bool use_statx;
>  struct lo_inode root;
>  GHashTable *inodes; /* protected by lo->mutex */
> +GHashTable *mnt_inodes; /* protected by lo->mutex */
>  struct lo_map ino_map; /* protected by lo->mutex */
>  struct lo_map dirp_map; /* protected by lo->mutex */
>  struct lo_map fd_map; /* protected by lo->mutex */
> @@ -968,6 +970,31 @@ static int do_statx(struct lo_data *lo, int dirfd, const 
> char *pathname,
>  return 0;
>  }
>  
> +static uint64_t mnt_inode_key(struct lo_inode *inode)
> +{
> +/* Prefer mnt_id, fallback on dev */
> +return inode->key.mnt_id ? inode->key.mnt_id : inode->key.dev;
> +}
> +
> +static void add_mnt_inode(struct lo_data *lo, struct lo_inode *inode)
> +{
> +uint64_t mnt_key = mnt_inode_key(inode);
> +
> +if (!g_hash_table_contains(lo->mnt_inodes, _key)) {
> +inode->is_mnt = true;
> +g_hash_table_insert(lo->mnt_inodes, _key, inode);
> +}
> +}
> +
> +static void remove_mnt_inode(struct lo_data *lo, struct lo_inode *inode)
> +{
> +uint64_t mnt_key = mnt_inode_key(inode);
> +
> +if (inode->is_mnt) {
> +g_hash_table_remove(lo->mnt_inodes, _key);
> +}

What if same filesystem is mounted at two different mount points. Say at
foo/ and bar/. Now when we lookup foo, we will add that inode to 
hash table. But when we lookup bar, we will not add it. Now say foo
is unmounted, and inode is going away, then we will remove super block
of fs from hash table (while it is still mounted at bar/ ?). Do I
understand it right?

If yes, we probably will need another refcounted object to keep track
of all the instances of the same fs?

Thanks
Vivek


> +}
> +

>  /*
>   * Increments nlookup on the inode on success. unref_inode_lolocked() must be
>   * called eventually to decrement nlookup again. If inodep is non-NULL, the
> @@ -1054,10 +1081,14 @@ static int lo_do_lookup(fuse_req_t req, fuse_ino_t 
> parent, const char *name,
>  pthread_mutex_lock(>mutex);
>  inode->fuse_ino = lo_add_inode_mapping(req, inode);
>  g_hash_table_insert(lo->inodes, >key, inode);
> +add_mnt_inode(lo, inode);
>  pthread_mutex_unlock(>mutex);
>  }
>  e->ino = inode->fuse_ino;
>  
> +fuse_log(FUSE_LOG_DEBUG, "  %lli/%s -> %lli%s\n", (unsigned long 
> long)parent,
> + name, (unsigned long long)e->ino, inode->is_mnt ? " (mount)" : 
> "");
> +
>  /* Transfer ownership of inode pointer to caller or drop it */
>  if (inodep) {
>  *inodep = inode;
> @@ -1067,9 +1098,6 @@ static int lo_do_lookup(fuse_req_t req, fuse_ino_t 
> parent, const char *name,
>  
>  lo_inode_put(lo, );
>  
> -fuse_log(FUSE_LOG_DEBUG, "  %lli/%s -> %lli\n", (unsigned long 
> long)parent,
> - name, (unsigned long long)e->ino);
> -
>  return 0;
>  
>  out_err:
> @@ -1479,6 +1507,7 @@ static void unref_inode(struct lo_data *lo, struct 
> lo_inode *inode, uint64_t n)
>  g_hash_table_destroy(inode->posix_locks);
>  pthread_mutex_destroy(>plock_mutex);
>  }
> +remove_mnt_inode(lo, inode);
>  /* Drop our refcount from lo_do_lookup() */
>  lo_inode_put(lo, );
>  }
> @@ -3129,6 +3158,7 @@ static void lo_destroy(void *userdata)
>  struct lo_data *lo = (struct lo_data *)userdata;
>  
>  pthread_mutex_lock(>mutex);
> +g_hash_table_remove_all(lo->mnt_inodes);
>  while (true) {
>  GHashTableIter iter;
>  gpointer key, value;
> @@ -3659,6 +3689,7 @@ static void setup_root(struct lo_data *lo, struct 
> lo_inode *root)
>  root->posix_locks = g_hash_table_new_full(
>  g_direct_hash, g_direct_equal, NULL, posix_locks_value_destroy);

Re: [for-6.1 v3 3/3] virtiofsd: Add support for FUSE_SYNCFS request

2021-05-10 Thread Vivek Goyal

On Mon, May 10, 2021 at 05:55:39PM +0200, Greg Kurz wrote:
> Honor the expected behavior of syncfs() to synchronously flush all data
> and metadata on linux systems. Simply loop on all known submounts and
> call syncfs() on them.
> 
> Note that syncfs() might suffer from a time penalty if the submounts
> are being hammered by some unrelated workload on the host. The only
> solution to avoid that is to avoid shared submounts.
> 
> Signed-off-by: Greg Kurz 
> ---
>  tools/virtiofsd/fuse_lowlevel.c   | 11 
>  tools/virtiofsd/fuse_lowlevel.h   | 12 +
>  tools/virtiofsd/passthrough_ll.c  | 38 +++
>  tools/virtiofsd/passthrough_seccomp.c |  1 +
>  4 files changed, 62 insertions(+)
> 
> diff --git a/tools/virtiofsd/fuse_lowlevel.c b/tools/virtiofsd/fuse_lowlevel.c
> index 58e32fc96369..3be95ec903c9 100644
> --- a/tools/virtiofsd/fuse_lowlevel.c
> +++ b/tools/virtiofsd/fuse_lowlevel.c
> @@ -1870,6 +1870,16 @@ static void do_lseek(fuse_req_t req, fuse_ino_t nodeid,
>  }
>  }
>  
> +static void do_syncfs(fuse_req_t req, fuse_ino_t nodeid,
> +  struct fuse_mbuf_iter *iter)
> +{
> +if (req->se->op.syncfs) {
> +req->se->op.syncfs(req);
> +} else {
> +fuse_reply_err(req, ENOSYS);
> +}
> +}
> +
>  static void do_init(fuse_req_t req, fuse_ino_t nodeid,
>  struct fuse_mbuf_iter *iter)
>  {
> @@ -2267,6 +2277,7 @@ static struct {
>  [FUSE_RENAME2] = { do_rename2, "RENAME2" },
>  [FUSE_COPY_FILE_RANGE] = { do_copy_file_range, "COPY_FILE_RANGE" },
>  [FUSE_LSEEK] = { do_lseek, "LSEEK" },
> +[FUSE_SYNCFS] = { do_syncfs, "SYNCFS" },
>  };
>  
>  #define FUSE_MAXOP (sizeof(fuse_ll_ops) / sizeof(fuse_ll_ops[0]))
> diff --git a/tools/virtiofsd/fuse_lowlevel.h b/tools/virtiofsd/fuse_lowlevel.h
> index 3bf786b03485..890c520b195a 100644
> --- a/tools/virtiofsd/fuse_lowlevel.h
> +++ b/tools/virtiofsd/fuse_lowlevel.h
> @@ -1225,6 +1225,18 @@ struct fuse_lowlevel_ops {
>   */
>  void (*lseek)(fuse_req_t req, fuse_ino_t ino, off_t off, int whence,
>struct fuse_file_info *fi);
> +
> +/**
> + * Synchronize file system content
> + *
> + * If this request is answered with an error code of ENOSYS,
> + * this is treated as success and future calls to syncfs() will
> + * succeed automatically without being sent to the filesystem
> + * process.
> + *
> + * @param req request handle
> + */
> +void (*syncfs)(fuse_req_t req);
>  };
>  
>  /**
> diff --git a/tools/virtiofsd/passthrough_ll.c 
> b/tools/virtiofsd/passthrough_ll.c
> index dc940a1d048b..289900c6d274 100644
> --- a/tools/virtiofsd/passthrough_ll.c
> +++ b/tools/virtiofsd/passthrough_ll.c
> @@ -3153,6 +3153,43 @@ static void lo_lseek(fuse_req_t req, fuse_ino_t ino, 
> off_t off, int whence,
>  }
>  }
>  
> +static void lo_syncfs(fuse_req_t req)
> +{
> +struct lo_data *lo = lo_data(req);
> +GHashTableIter iter;
> +gpointer key, value;
> +int err = 0;
> +
> +pthread_mutex_lock(>mutex);
> +
> +g_hash_table_iter_init(, lo->mnt_inodes);
> +while (g_hash_table_iter_next(, , )) {
> +struct lo_inode *inode = value;
> +int fd;
> +
> +fuse_log(FUSE_LOG_DEBUG, "lo_syncfs(ino=%" PRIu64 ")\n",
> + inode->fuse_ino);
> +
> +fd = lo_inode_open(lo, inode, O_RDONLY);
> +if (fd < 0) {
> +err = -fd;
> +break;
> +}
> +
> +if (syncfs(fd) < 0) {

I don't have a good feeling about calling syncfs() with lo->mutex held.
This seems to be that global mutex which is held at so many places
and will serialize everything else. I think we agreed that syncfs()
can take 10s of seconds if fs is busy. And that means we will stall
other filesystem operations too.

So will be good if we can call syncfs() outside the lock. May be prepare
a list of inodes which are there, take a reference and drop the lock.
call syncfs and then drop the reference on inode.

Vivek

> +err = errno;
> +close(fd);
> +break;
> +}
> +
> +close(fd);
> +}
> +
> +pthread_mutex_unlock(>mutex);
> +
> +fuse_reply_err(req, err);
> +}
> +
>  static void lo_destroy(void *userdata)
>  {
>  struct lo_data *lo = (struct lo_data *)userdata;
> @@ -3214,6 +3251,7 @@ static struct fuse_lowlevel_ops lo_oper = {
>  .copy_file_range = lo_copy_file_range,
>  #endif
>  .lseek = lo_lseek,
> +.syncfs = lo_syncfs,
>  .destroy = lo_destroy,
>  };
>  
> diff --git a/tools/virtiofsd/passthrough_seccomp.c 
> b/tools/virtiofsd/passthrough_seccomp.c
> index 62441cfcdb95..343188447901 100644
> --- a/tools/virtiofsd/passthrough_seccomp.c
> +++ b/tools/virtiofsd/passthrough_seccomp.c
> @@ -107,6 +107,7 @@ static const int syscall_allowlist[] = {
>  SCMP_SYS(set_robust_list),
>  SCMP_SYS(setxattr),
>  SCMP_SYS(symlinkat),
> +SCMP_SYS(syncfs),
>

[PATCH 6/6] hw/arm: Model TCMs in the SSE-300, not the AN547

The SSE-300 has an ITCM at 0x_ and a DTCM at 0x2000_.
Currently we model these in the AN547 board, but this is conceptually
wrong, because they are a part of the SSE-300 itself. Move the
modelling of the TCMs out of mps2-tz.c into sse300.c.

This has no guest-visible effects.

Signed-off-by: Peter Maydell 
---
 include/hw/arm/armsse.h |  2 ++
 hw/arm/armsse.c | 19 +++
 hw/arm/mps2-tz.c| 12 
 3 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/include/hw/arm/armsse.h b/include/hw/arm/armsse.h
index 36592be62c5..9648e7a4193 100644
--- a/include/hw/arm/armsse.h
+++ b/include/hw/arm/armsse.h
@@ -198,6 +198,8 @@ struct ARMSSE {
 MemoryRegion alias2;
 MemoryRegion alias3[SSE_MAX_CPUS];
 MemoryRegion sram[MAX_SRAM_BANKS];
+MemoryRegion itcm;
+MemoryRegion dtcm;
 
 qemu_irq *exp_irqs[SSE_MAX_CPUS];
 qemu_irq ppc0_irq;
diff --git a/hw/arm/armsse.c b/hw/arm/armsse.c
index be5aa1f113a..a1456cb0f42 100644
--- a/hw/arm/armsse.c
+++ b/hw/arm/armsse.c
@@ -13,6 +13,7 @@
 #include "qemu/log.h"
 #include "qemu/module.h"
 #include "qemu/bitops.h"
+#include "qemu/units.h"
 #include "qapi/error.h"
 #include "trace.h"
 #include "hw/sysbus.h"
@@ -70,6 +71,7 @@ struct ARMSSEInfo {
 bool has_cpuid;
 bool has_cpu_pwrctrl;
 bool has_sse_counter;
+bool has_tcms;
 Property *props;
 const ARMSSEDeviceInfo *devinfo;
 const bool *irq_is_common;
@@ -516,6 +518,7 @@ static const ARMSSEInfo armsse_variants[] = {
 .has_cpuid = false,
 .has_cpu_pwrctrl = false,
 .has_sse_counter = false,
+.has_tcms = false,
 .props = iotkit_properties,
 .devinfo = iotkit_devices,
 .irq_is_common = sse200_irq_is_common,
@@ -536,6 +539,7 @@ static const ARMSSEInfo armsse_variants[] = {
 .has_cpuid = true,
 .has_cpu_pwrctrl = false,
 .has_sse_counter = false,
+.has_tcms = false,
 .props = sse200_properties,
 .devinfo = sse200_devices,
 .irq_is_common = sse200_irq_is_common,
@@ -556,6 +560,7 @@ static const ARMSSEInfo armsse_variants[] = {
 .has_cpuid = true,
 .has_cpu_pwrctrl = true,
 .has_sse_counter = true,
+.has_tcms = true,
 .props = sse300_properties,
 .devinfo = sse300_devices,
 .irq_is_common = sse300_irq_is_common,
@@ -1214,6 +1219,20 @@ static void armsse_realize(DeviceState *dev, Error 
**errp)
 sysbus_mmio_get_region(sbd, 1));
 }
 
+if (info->has_tcms) {
+/* The SSE-300 has an ITCM at 0x_ and a DTCM at 0x2000_ */
+memory_region_init_ram(>itcm, NULL, "sse300-itcm", 512 * KiB, errp);
+if (*errp) {
+return;
+}
+memory_region_init_ram(>dtcm, NULL, "sse300-dtcm", 512 * KiB, errp);
+if (*errp) {
+return;
+}
+memory_region_add_subregion(>container, 0x, >itcm);
+memory_region_add_subregion(>container, 0x2000, >dtcm);
+}
+
 /* Devices behind APB PPC0:
  *   0x4000: timer0
  *   0x40001000: timer1
diff --git a/hw/arm/mps2-tz.c b/hw/arm/mps2-tz.c
index 8d921afec14..e23830f4b7d 100644
--- a/hw/arm/mps2-tz.c
+++ b/hw/arm/mps2-tz.c
@@ -265,23 +265,11 @@ static const RAMInfo an524_raminfo[] = { {
 };
 
 static const RAMInfo an547_raminfo[] = { {
-.name = "itcm",
-.base = 0x,
-.size = 512 * KiB,
-.mpc = -1,
-.mrindex = 0,
-}, {
 .name = "sram",
 .base = 0x0100,
 .size = 2 * MiB,
 .mpc = 0,
 .mrindex = 1,
-}, {
-.name = "dtcm",
-.base = 0x2000,
-.size = 4 * 128 * KiB,
-.mpc = -1,
-.mrindex = 2,
 }, {
 .name = "sram 2",
 .base = 0x2100,
-- 
2.20.1

Re: [PATCH 0/6] hw/arm: Fix modelling of SSE-300 TCMs and SRAM

Hi Peter,

On 5/10/21 9:08 PM, Peter Maydell wrote:
> This patchset fixes some bugs in how we were modelling the
> TCMs and the SRAM in the SSE-300 which were preventing
> Arm TF-M from booting on our AN547 model; there are also
> some fixes to things I noticed while I was in the code.
> 
> The specific bugs preventing boot were:
>  * SRAM_ADDR_WIDTH for the AN547 is 21, not 15, so the SRAM
>area was too small
>  * we were putting the SRAMs at the wrong address (0x2100_
>for SSE-300, not 0x2000_ as for SSE-200)

How can we test it?

> The other stuff I've fixed is:
>  * we were modelling the SRAM in the AN524 both in the SSE
>and in the board model (harmlessly, as the board-model
>memory was just always shadowed in the memory map and
>unreachable)
>  * we were modelling the TCMs in the AN547 board model,
>which is conceptually wrong because in hardware they're
>part of the SSE-300. No guest-visible change, but it will
>avoid problems if/when we add another SSE-300 board model
> 
> thanks
> -- PMM
> 
> Peter Maydell (6):
>   hw/arm/mps2-tz: Don't duplicate modelling of SRAM in AN524
>   hw/arm/mps2-tz: Make SRAM_ADDR_WIDTH board-specific
>   hw/arm/armsse.c: Correct modelling of SSE-300 internal SRAMs
>   hw/arm/armsse: Convert armsse_realize() to use ERRP_GUARD
>   hw/arm/mps2-tz: Allow board to specify a boot RAM size
>   hw/arm: Model TCMs in the SSE-300, not the AN547
> 
>  include/hw/arm/armsse.h |  2 ++
>  hw/arm/armsse.c | 35 +--
>  hw/arm/mps2-tz.c| 39 ---
>  3 files changed, 51 insertions(+), 25 deletions(-)
>

[Bug 1906608] Re: [Feature request]For some ehci controller, qemu should implement using portsc[26-27] to detect the speed of device.

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Tags added: feature-request usb

** Changed in: qemu
   Importance: Undecided => Wishlist

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

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

Title:
   [Feature request]For some ehci controller, qemu should implement
  using portsc[26-27]  to detect the speed of device.

Status in QEMU:
  Incomplete

Bug description:
  for some ehci controller ,for example ehci controller on fsl_imx6,it
  using portsc[26-27] to decide a full speed device or high speed device
  was connected, hub-ehci.c should set the portsc[26-27] to return the
  right speed.

  line:1001 in hub-ehci.c
  if (dev && dev->attached && (dev->speedmask & USB_SPEED_MASK_HIGH)) {
  val |= PORTSC_PED;
  }

  below is the spec for fsl_imx6 USB PART.
  PORTSC:27–26 :PSPD
  Port Speed - Read Only.
  This register field indicates the speed at which the port is operating.
  00 Full Speed
  01 Low Speed
  10 High Speed
  11 Undefined

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

[PATCH 3/6] hw/arm/armsse.c: Correct modelling of SSE-300 internal SRAMs

The SSE-300 was not correctly modelling its internal SRAMs:
 * the SRAM address width default is 18
 * the SRAM is mapped at 0x2100_, not 0x2000_ like
   the SSE-200 and IoTKit

The default address width is no longer guest-visible since
our only SSE-300 board sets it explicitly to a non-default
value, but following the hardware's default will help for
any future boards we need to model.

Reported-by: Devaraj Ranganna 
Signed-off-by: Peter Maydell 
---
 hw/arm/armsse.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/hw/arm/armsse.c b/hw/arm/armsse.c
index 2e5d0679e7b..1729f09c7cb 100644
--- a/hw/arm/armsse.c
+++ b/hw/arm/armsse.c
@@ -59,6 +59,7 @@ struct ARMSSEInfo {
 const char *cpu_type;
 uint32_t sse_version;
 int sram_banks;
+uint32_t sram_bank_base;
 int num_cpus;
 uint32_t sys_version;
 uint32_t iidr;
@@ -102,7 +103,7 @@ static Property sse300_properties[] = {
 DEFINE_PROP_LINK("memory", ARMSSE, board_memory, TYPE_MEMORY_REGION,
  MemoryRegion *),
 DEFINE_PROP_UINT32("EXP_NUMIRQ", ARMSSE, exp_numirq, 64),
-DEFINE_PROP_UINT32("SRAM_ADDR_WIDTH", ARMSSE, sram_addr_width, 15),
+DEFINE_PROP_UINT32("SRAM_ADDR_WIDTH", ARMSSE, sram_addr_width, 18),
 DEFINE_PROP_UINT32("init-svtor", ARMSSE, init_svtor, 0x1000),
 DEFINE_PROP_BOOL("CPU0_FPU", ARMSSE, cpu_fpu[0], true),
 DEFINE_PROP_BOOL("CPU0_DSP", ARMSSE, cpu_dsp[0], true),
@@ -504,6 +505,7 @@ static const ARMSSEInfo armsse_variants[] = {
 .sse_version = ARMSSE_IOTKIT,
 .cpu_type = ARM_CPU_TYPE_NAME("cortex-m33"),
 .sram_banks = 1,
+.sram_bank_base = 0x2000,
 .num_cpus = 1,
 .sys_version = 0x41743,
 .iidr = 0,
@@ -523,6 +525,7 @@ static const ARMSSEInfo armsse_variants[] = {
 .sse_version = ARMSSE_SSE200,
 .cpu_type = ARM_CPU_TYPE_NAME("cortex-m33"),
 .sram_banks = 4,
+.sram_bank_base = 0x2000,
 .num_cpus = 2,
 .sys_version = 0x22041743,
 .iidr = 0,
@@ -542,6 +545,7 @@ static const ARMSSEInfo armsse_variants[] = {
 .sse_version = ARMSSE_SSE300,
 .cpu_type = ARM_CPU_TYPE_NAME("cortex-m55"),
 .sram_banks = 2,
+.sram_bank_base = 0x2100,
 .num_cpus = 1,
 .sys_version = 0x7e00043b,
 .iidr = 0x74a0043b,
@@ -1161,7 +1165,7 @@ static void armsse_realize(DeviceState *dev, Error **errp)
 /* Map the upstream end of the MPC into the right place... */
 sbd_mpc = SYS_BUS_DEVICE(>mpc[i]);
 memory_region_add_subregion(>container,
-0x2000 + i * sram_bank_size,
+info->sram_bank_base + i * sram_bank_size,
 sysbus_mmio_get_region(sbd_mpc, 1));
 /* ...and its register interface */
 memory_region_add_subregion(>container, 0x50083000 + i * 0x1000,
-- 
2.20.1

[PATCH 4/6] hw/arm/armsse: Convert armsse_realize() to use ERRP_GUARD

Convert armsse_realize() to use ERRP_GUARD(), following
the rules in include/qapi/error.h.

Signed-off-by: Peter Maydell 
---
We'll be adding a new error check in the next patch, so
do this first to avoid adding more uses of legacy
error_propagate().
---
 hw/arm/armsse.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/hw/arm/armsse.c b/hw/arm/armsse.c
index 1729f09c7cb..be5aa1f113a 100644
--- a/hw/arm/armsse.c
+++ b/hw/arm/armsse.c
@@ -913,7 +913,6 @@ static void armsse_realize(DeviceState *dev, Error **errp)
 const ARMSSEDeviceInfo *devinfo;
 int i;
 MemoryRegion *mr;
-Error *err = NULL;
 SysBusDevice *sbd_apb_ppc0;
 SysBusDevice *sbd_secctl;
 DeviceState *dev_apb_ppc0;
@@ -922,6 +921,8 @@ static void armsse_realize(DeviceState *dev, Error **errp)
 DeviceState *dev_splitter;
 uint32_t addr_width_max;
 
+ERRP_GUARD();
+
 if (!s->board_memory) {
 error_setg(errp, "memory property was not set");
 return;
@@ -1151,10 +1152,9 @@ static void armsse_realize(DeviceState *dev, Error 
**errp)
 uint32_t sram_bank_size = 1 << s->sram_addr_width;
 
 memory_region_init_ram(>sram[i], NULL, ramname,
-   sram_bank_size, );
+   sram_bank_size, errp);
 g_free(ramname);
-if (err) {
-error_propagate(errp, err);
+if (*errp) {
 return;
 }
 object_property_set_link(OBJECT(>mpc[i]), "downstream",
-- 
2.20.1

[PATCH 1/6] hw/arm/mps2-tz: Don't duplicate modelling of SRAM in AN524

The SRAM at 0x2000_ is part of the SSE-200 itself, and we model
it that way in hw/arm/armsse.c (along with the associated MPCs).  We
incorrectly also added an entry to the RAMInfo array for the AN524 in
hw/arm/mps2-tz.c, which was pointless because the CPU would never see
it.  Delete it.

The bug had no guest-visible effect because devices in the SSE-200
take priority over those in the board model (armsse.c maps
s->board_memory at priority -2).

Signed-off-by: Peter Maydell 
---
 hw/arm/mps2-tz.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/hw/arm/mps2-tz.c b/hw/arm/mps2-tz.c
index 70aa31a7f6c..77ff83acb06 100644
--- a/hw/arm/mps2-tz.c
+++ b/hw/arm/mps2-tz.c
@@ -243,19 +243,13 @@ static const RAMInfo an524_raminfo[] = { {
 .size = 512 * KiB,
 .mpc = 0,
 .mrindex = 0,
-}, {
-.name = "sram",
-.base = 0x2000,
-.size = 32 * 4 * KiB,
-.mpc = -1,
-.mrindex = 1,
 }, {
 /* We don't model QSPI flash yet; for now expose it as simple ROM */
 .name = "QSPI",
 .base = 0x2800,
 .size = 8 * MiB,
 .mpc = 1,
-.mrindex = 2,
+.mrindex = 1,
 .flags = IS_ROM,
 }, {
 .name = "DDR",
-- 
2.20.1

[PATCH 5/6] hw/arm/mps2-tz: Allow board to specify a boot RAM size

Currently we model the ITCM in the AN547's RAMInfo list. This is incorrect
because this RAM is really a part of the SSE-300. We can't just delete
it from the RAMInfo list, though, because this would make boot_ram_size()
assert because it wouldn't be able to find an entry in the list covering
guest address 0.

Allow a board to specify a boot RAM size manually if it doesn't have
any RAM itself at address 0 and is relying on the SSE for that, and
set the correct value for the AN547. The other boards can continue
to use the "look it up from the RAMInfo list" logic.

Signed-off-by: Peter Maydell 
---
 hw/arm/mps2-tz.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/hw/arm/mps2-tz.c b/hw/arm/mps2-tz.c
index f2595b1c7f7..8d921afec14 100644
--- a/hw/arm/mps2-tz.c
+++ b/hw/arm/mps2-tz.c
@@ -126,6 +126,7 @@ struct MPS2TZMachineClass {
 uint32_t sram_addr_width; /* SRAM_ADDR_WIDTH setting for SSE */
 const RAMInfo *raminfo;
 const char *armsse_type;
+uint32_t boot_ram_size; /* size of ram at address 0; 0 == find in raminfo 
*/
 };
 
 struct MPS2TZMachineState {
@@ -761,6 +762,14 @@ static uint32_t boot_ram_size(MPS2TZMachineState *mms)
 const RAMInfo *p;
 MPS2TZMachineClass *mmc = MPS2TZ_MACHINE_GET_CLASS(mms);
 
+/*
+ * Use a per-board specification (for when the boot RAM is in
+ * the SSE and so doesn't have a RAMInfo list entry)
+ */
+if (mmc->boot_ram_size) {
+return mmc->boot_ram_size;
+}
+
 for (p = mmc->raminfo; p->name; p++) {
 if (p->base == boot_mem_base(mms)) {
 return p->size;
@@ -1268,6 +1277,7 @@ static void mps2tz_an505_class_init(ObjectClass *oc, void 
*data)
 mmc->sram_addr_width = 15;
 mmc->raminfo = an505_raminfo;
 mmc->armsse_type = TYPE_IOTKIT;
+mmc->boot_ram_size = 0;
 mps2tz_set_default_ram_info(mmc);
 }
 
@@ -1296,6 +1306,7 @@ static void mps2tz_an521_class_init(ObjectClass *oc, void 
*data)
 mmc->sram_addr_width = 15;
 mmc->raminfo = an505_raminfo; /* AN521 is the same as AN505 here */
 mmc->armsse_type = TYPE_SSE200;
+mmc->boot_ram_size = 0;
 mps2tz_set_default_ram_info(mmc);
 }
 
@@ -1324,6 +1335,7 @@ static void mps3tz_an524_class_init(ObjectClass *oc, void 
*data)
 mmc->sram_addr_width = 15;
 mmc->raminfo = an524_raminfo;
 mmc->armsse_type = TYPE_SSE200;
+mmc->boot_ram_size = 0;
 mps2tz_set_default_ram_info(mmc);
 
 object_class_property_add_str(oc, "remap", mps2_get_remap, mps2_set_remap);
@@ -1357,6 +1369,7 @@ static void mps3tz_an547_class_init(ObjectClass *oc, void 
*data)
 mmc->sram_addr_width = 21;
 mmc->raminfo = an547_raminfo;
 mmc->armsse_type = TYPE_SSE300;
+mmc->boot_ram_size = 512 * KiB;
 mps2tz_set_default_ram_info(mmc);
 }
 
-- 
2.20.1

[Bug 1907042] Re: assert issue locates in hw/usb/core.c:727: usb_ep_get: Assertion `pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT' failed

** Tags added: usb

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

Title:
  assert issue locates in hw/usb/core.c:727: usb_ep_get: Assertion `pid
  == USB_TOKEN_IN || pid == USB_TOKEN_OUT' failed

Status in QEMU:
  New

Bug description:
  Hello,

  An assertion failure was found in hw/usb/core.c:727 in latest version
  5.2.0.

  Reproduced environment is as follows:
  Host: ubuntu 18.04
  Guest: ubuntu 18.04

  QEMU boot command line:
  qemu-system-x86_64 -enable-kvm -boot c -m 4G -drive 
format=qcow2,file=./ubuntu.img -nic user,hostfwd=tcp:0.0.0.0:-:22 -device 
pci-ohci,id=ohci -device usb-tablet,bus=ohci.0,port=1,id=usbdev1 -trace usb\*

  Backtrace is as follows:
  #0  0x7f13fff14438 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
  #1  0x7f13fff1603a in __GI_abort () at abort.c:89
  #2  0x7f13fff0cbe7 in __assert_fail_base (fmt=, 
assertion=assertion@entry=0x55f97745ffe0 "pid == USB_TOKEN_IN || pid == 
USB_TOKEN_OUT", file=file@entry=0x55f97745f6c0 "../hw/usb/core.c", 
line=line@entry=727, function=function@entry=0x55f9774606e0 
<__PRETTY_FUNCTION__.22877> "usb_ep_get") at assert.c:92
  #3  0x7f13fff0cc92 in __GI___assert_fail (assertion=0x55f97745ffe0 "pid 
== USB_TOKEN_IN || pid == USB_TOKEN_OUT", file=0x55f97745f6c0 
"../hw/usb/core.c", line=727, function=0x55f9774606e0 
<__PRETTY_FUNCTION__.22877> "usb_ep_get") at assert.c:101
  #4  0x55f975bfc9b2 in usb_ep_get (dev=0x6230c500, pid=45, ep=1) at 
../hw/usb/core.c:727
  #5  0x55f975f945db in ohci_service_td (ohci=0x627191f0, 
ed=0x7ffcd9308410) at ../hw/usb/hcd-ohci.c:1044
  #6  0x55f975f95d5e in ohci_service_ed_list (ohci=0x627191f0, 
head=857580576, completion=0) at ../hw/usb/hcd-ohci.c:1200
  #7  0x55f975f9656d in ohci_process_lists (ohci=0x627191f0, 
completion=0) at ../hw/usb/hcd-ohci.c:1238
  #8  0x55f975f9725c in ohci_frame_boundary (opaque=0x627191f0) at 
../hw/usb/hcd-ohci.c:1281
  #9  0x55f977212494 in timerlist_run_timers (timer_list=0x60b5b060) at 
../util/qemu-timer.c:574
  #10 0x55f9772126db in qemu_clock_run_timers (type=QEMU_CLOCK_VIRTUAL) at 
../util/qemu-timer.c:588
  #11 0x55f977212fde in qemu_clock_run_all_timers () at 
../util/qemu-timer.c:670
  #12 0x55f9772d5717 in main_loop_wait (nonblocking=0) at 
../util/main-loop.c:531
  #13 0x55f97695100c in qemu_main_loop () at ../softmmu/vl.c:1677
  #14 0x55f9758f7601 in main (argc=16, argv=0x7ffcd930, 
envp=0x7ffcd9308910) at ../softmmu/main.c:50
  #15 0x7f13ffeff840 in __libc_start_main (main=0x55f9758f75b0 , 
argc=16, argv=0x7ffcd930, init=, fini=, 
rtld_fini=, stack_end=0x7ffcd9308878) at ../csu/libc-start.c:291
  #16 0x55f9758f74a9 in _start ()

  
  The poc is attached.

  Thanks.

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

[PATCH 0/6] hw/arm: Fix modelling of SSE-300 TCMs and SRAM

This patchset fixes some bugs in how we were modelling the
TCMs and the SRAM in the SSE-300 which were preventing
Arm TF-M from booting on our AN547 model; there are also
some fixes to things I noticed while I was in the code.

The specific bugs preventing boot were:
 * SRAM_ADDR_WIDTH for the AN547 is 21, not 15, so the SRAM
   area was too small
 * we were putting the SRAMs at the wrong address (0x2100_
   for SSE-300, not 0x2000_ as for SSE-200)

The other stuff I've fixed is:
 * we were modelling the SRAM in the AN524 both in the SSE
   and in the board model (harmlessly, as the board-model
   memory was just always shadowed in the memory map and
   unreachable)
 * we were modelling the TCMs in the AN547 board model,
   which is conceptually wrong because in hardware they're
   part of the SSE-300. No guest-visible change, but it will
   avoid problems if/when we add another SSE-300 board model

thanks
-- PMM

Peter Maydell (6):
  hw/arm/mps2-tz: Don't duplicate modelling of SRAM in AN524
  hw/arm/mps2-tz: Make SRAM_ADDR_WIDTH board-specific
  hw/arm/armsse.c: Correct modelling of SSE-300 internal SRAMs
  hw/arm/armsse: Convert armsse_realize() to use ERRP_GUARD
  hw/arm/mps2-tz: Allow board to specify a boot RAM size
  hw/arm: Model TCMs in the SSE-300, not the AN547

 include/hw/arm/armsse.h |  2 ++
 hw/arm/armsse.c | 35 +--
 hw/arm/mps2-tz.c| 39 ---
 3 files changed, 51 insertions(+), 25 deletions(-)

-- 
2.20.1

[PATCH 2/6] hw/arm/mps2-tz: Make SRAM_ADDR_WIDTH board-specific

The AN547 sets the SRAM_ADDR_WIDTH for the SSE-300 to 21;
since this is not the default value for the SSE-300, model this
in mps2-tz.c as a per-board value.

Reported-by: Devaraj Ranganna 
Signed-off-by: Peter Maydell 
---
 hw/arm/mps2-tz.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/hw/arm/mps2-tz.c b/hw/arm/mps2-tz.c
index 77ff83acb06..f2595b1c7f7 100644
--- a/hw/arm/mps2-tz.c
+++ b/hw/arm/mps2-tz.c
@@ -123,6 +123,7 @@ struct MPS2TZMachineClass {
 int numirq; /* Number of external interrupts */
 int uart_overflow_irq; /* number of the combined UART overflow IRQ */
 uint32_t init_svtor; /* init-svtor setting for SSE */
+uint32_t sram_addr_width; /* SRAM_ADDR_WIDTH setting for SSE */
 const RAMInfo *raminfo;
 const char *armsse_type;
 };
@@ -806,6 +807,7 @@ static void mps2tz_common_init(MachineState *machine)
  OBJECT(system_memory), _abort);
 qdev_prop_set_uint32(iotkitdev, "EXP_NUMIRQ", mmc->numirq);
 qdev_prop_set_uint32(iotkitdev, "init-svtor", mmc->init_svtor);
+qdev_prop_set_uint32(iotkitdev, "SRAM_ADDR_WIDTH", mmc->sram_addr_width);
 qdev_connect_clock_in(iotkitdev, "MAINCLK", mms->sysclk);
 qdev_connect_clock_in(iotkitdev, "S32KCLK", mms->s32kclk);
 sysbus_realize(SYS_BUS_DEVICE(>iotkit), _fatal);
@@ -1263,6 +1265,7 @@ static void mps2tz_an505_class_init(ObjectClass *oc, void 
*data)
 mmc->numirq = 92;
 mmc->uart_overflow_irq = 47;
 mmc->init_svtor = 0x1000;
+mmc->sram_addr_width = 15;
 mmc->raminfo = an505_raminfo;
 mmc->armsse_type = TYPE_IOTKIT;
 mps2tz_set_default_ram_info(mmc);
@@ -1290,6 +1293,7 @@ static void mps2tz_an521_class_init(ObjectClass *oc, void 
*data)
 mmc->numirq = 92;
 mmc->uart_overflow_irq = 47;
 mmc->init_svtor = 0x1000;
+mmc->sram_addr_width = 15;
 mmc->raminfo = an505_raminfo; /* AN521 is the same as AN505 here */
 mmc->armsse_type = TYPE_SSE200;
 mps2tz_set_default_ram_info(mmc);
@@ -1317,6 +1321,7 @@ static void mps3tz_an524_class_init(ObjectClass *oc, void 
*data)
 mmc->numirq = 95;
 mmc->uart_overflow_irq = 47;
 mmc->init_svtor = 0x1000;
+mmc->sram_addr_width = 15;
 mmc->raminfo = an524_raminfo;
 mmc->armsse_type = TYPE_SSE200;
 mps2tz_set_default_ram_info(mmc);
@@ -1349,6 +1354,7 @@ static void mps3tz_an547_class_init(ObjectClass *oc, void 
*data)
 mmc->numirq = 96;
 mmc->uart_overflow_irq = 48;
 mmc->init_svtor = 0x;
+mmc->sram_addr_width = 21;
 mmc->raminfo = an547_raminfo;
 mmc->armsse_type = TYPE_SSE300;
 mps2tz_set_default_ram_info(mmc);
-- 
2.20.1

[Bug 1907427] Re: Build on sparc64 fails with "undefined reference to `fdt_check_full'"

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/255


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

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #255
   https://gitlab.com/qemu-project/qemu/-/issues/255

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

Title:
  Build on sparc64 fails with "undefined reference to `fdt_check_full'"

Status in QEMU:
  Expired

Bug description:
  Trying to build QEMU on sparc64 fails with:

  [4648/8435] c++  -o qemu-system-ppc64 qemu-system-ppc64.p/softmmu_main.c.o 
libcommon.fa.p/ui_vnc-auth-sasl.c.o libcommon.fa.p/migration_colo-failover.c.o 
libcommon.fa.p/hw_input_vhost-user-input.c.o 
libcommon.fa.p/replay_replay-random.c.o libcommon.fa.p/hw_9pfs_codir.c.o 
libcommon.fa.p/hw_display_edid-region.c.o libcommon.fa.p/hw_net_vhost_net.c.o 
libcommon.fa.p/hw_isa_i82378.c.o libcommon.fa.p/backends_rng-egd.c.o 
libcommon.fa.p/hw_usb_core.c.o libcommon.fa.p/hw_pci-bridge_i82801b11.c.o 
libcommon.fa.p/net_tap.c.o libcommon.fa.p/hw_ipack_ipack.c.o 
libcommon.fa.p/hw_scsi_mptconfig.c.o libcommon.fa.p/hw_usb_libhw.c.o 
libcommon.fa.p/hw_display_sm501.c.o 
libcommon.fa.p/hw_net_rocker_rocker_world.c.o 
libcommon.fa.p/fsdev_qemu-fsdev.c.o libcommon.fa.p/backends_tpm_tpm_util.c.o 
libcommon.fa.p/net_tap-linux.c.o libcommon.fa.p/hw_net_rocker_rocker_fp.c.o 
libcommon.fa.p/hw_usb_dev-uas.c.o libcommon.fa.p/hw_net_fsl_etsec_miim.c.o 
libcommon.fa.p/net_queue.c.o libcommon.fa.p/hw_isa_isa-superio.c.o 
libcommon.fa.p/migration_global_state.c.o 
libcommon.fa.p/backends_rng-random.c.o 
libcommon.fa.p/hw_ipmi_ipmi_bmc_extern.c.o 
libcommon.fa.p/migration_postcopy-ram.c.o libcommon.fa.p/hw_scsi_megasas.c.o 
libcommon.fa.p/hw_acpi_acpi-stub.c.o libcommon.fa.p/hw_nvram_mac_nvram.c.o 
libcommon.fa.p/hw_net_pcnet-pci.c.o libcommon.fa.p/cpus-common.c.o 
libcommon.fa.p/hw_core_qdev-properties-system.c.o 
libcommon.fa.p/migration_colo.c.o libcommon.fa.p/ui_spice-module.c.o 
libcommon.fa.p/hw_usb_hcd-ehci-pci.c.o libcommon.fa.p/migration_exec.c.o 
libcommon.fa.p/hw_input_adb-kbd.c.o libcommon.fa.p/hw_timer_xilinx_timer.c.o 
libcommon.fa.p/hw_cpu_core.c.o libcommon.fa.p/chardev_msmouse.c.o 
libcommon.fa.p/migration_socket.c.o libcommon.fa.p/hw_9pfs_9p-synth.c.o 
libcommon.fa.p/backends_dbus-vmstate.c.o libcommon.fa.p/net_colo-compare.c.o 
libcommon.fa.p/hw_misc_macio_cuda.c.o libcommon.fa.p/hw_audio_intel-hda.c.o 
libcommon.fa.p/audio_audio_legacy.c.o
  (...)
  libio.fa libchardev.fa -Wl,--no-whole-archive -Wl,--warn-common -Wl,-z,relro 
-Wl,-z,now -m64 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,--as-needed -fstack-protector-strong 
libmigration.fa -Wl,--start-group libqemuutil.a 
contrib/libvhost-user/libvhost-user.a libqmp.fa libhwcore.fa libblockdev.fa 
libblock.fa libcrypto.fa libauthz.fa libqom.fa libio.fa libchardev.fa 
@block.syms @qemu.syms 
/usr/lib/gcc/sparc64-linux-gnu/10/../../../sparc64-linux-gnu/libfdt.so 
/usr/lib/sparc64-linux-gnu/libcapstone.so -lepoxy -lgbm 
/usr/lib/sparc64-linux-gnu/libpixman-1.so /usr/lib/sparc64-linux-gnu/libz.so 
/usr/lib/sparc64-linux-gnu/libslirp.so 
/usr/lib/sparc64-linux-gnu/libglib-2.0.so -lrdmacm -libverbs -libumad -lgio-2.0 
-lgobject-2.0 -lglib-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 
/usr/lib/gcc/sparc64-linux-gnu/10/../../../sparc64-linux-gnu/libsasl2.so 
@block.syms -lusb-1.0 /lib/sparc64-linux-gnu/libudev.so 
/usr/lib/sparc64-linux-gnu/libpng16.so -lvdeplug 
/usr/lib/sparc64-linux-gnu/libjpeg.so -pthread -luring -lgnutls -lutil 
-lgio-2.0 -lgobject-2.0 -lglib-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lm 
-Wl,--export-dynamic -lgmodule-2.0 -lglib-2.0 -laio -luring -lgnutls -lnettle 
-lstdc++ -Wl,--end-group
  /usr/bin/ld: libqemu-ppc64-softmmu.fa.p/hw_ppc_spapr_hcall.c.o: in function 
`h_update_dt':
  ./b/qemu/../../hw/ppc/spapr_hcall.c:1966: undefined reference to 
`fdt_check_full'
  collect2: error: ld returned 1 exit status

  Full build log available at:
  
https://buildd.debian.org/status/fetch.php?pkg=qemu=sparc64=1%3A5.2%2Bdfsg-1=1607502300=0

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

[Bug 1907776] Re: Mounting VFat drive yields error messages.

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


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

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

Title:
  Mounting VFat drive yields error messages.

Status in QEMU:
  Incomplete

Bug description:
  Mounting a virtual Fat drive results in error messages (see attached
  image).

  * https://www.qemu.org/docs/master/system/images.html#virtual-fat-
  disk-images

  The "drive" is however mounted, and as a test, saving a text file to
  the drive is successfully stored in the directory `/tmp`, which can be
  read after shutdown of Qemu.

  Archlinux 5.9.11-arch2-1 (64-bit)
  qemu-headless 5.1.0-3

  qemu-system-x86_64 -boot order=d -name test \
-enable-kvm -m 2G -cpu host -k sv \
-daemonize \
-drive 
if=pflash,format=raw,readonly,file=/usr/share/edk2-ovmf/x64/OVMF_CODE.fd \
-drive if=pflash,format=raw,file=~/vm/OVMF_VARS.local.fd \
-drive if=ide,format=raw,media=disk,index=1,file=fat:rw:/tmp \
-vnc :1 \
-cdrom /obj/archlinux/release/2020.10.01-x86_64.iso \
-drive format=raw,index=0,media=disk,file=~/vm/qemu.raw

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

[PATCH v2] qemu-iotests: fix pylint 2.8 consider-using-with error

2021-05-10 Thread Emanuele Giuseppe Esposito

pylint 2.8 introduces consider-using-with error, suggesting
to use the 'with' block statement when possible.

Modify all subprocess.Popen call to use the 'with' statement,
except the one in __init__ of QemuIoInteractive class, since
it is assigned to a class field and used in other methods.

Signed-off-by: Emanuele Giuseppe Esposito 
---
v1 -> v2:
* fix indentation [Max]
* explain why we disabled the check in QemuIoInteractive's __init__ [Max]

 tests/qemu-iotests/iotests.py| 65 
 tests/qemu-iotests/testrunner.py | 22 +--
 2 files changed, 44 insertions(+), 43 deletions(-)

diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
index 5af0182895..ec3c69daf1 100644
--- a/tests/qemu-iotests/iotests.py
+++ b/tests/qemu-iotests/iotests.py
@@ -113,15 +113,14 @@ def qemu_tool_pipe_and_status(tool: str, args: 
Sequence[str],
 Run a tool and return both its output and its exit code
 """
 stderr = subprocess.STDOUT if connect_stderr else None
-subp = subprocess.Popen(args,
-stdout=subprocess.PIPE,
-stderr=stderr,
-universal_newlines=True)
-output = subp.communicate()[0]
-if subp.returncode < 0:
-cmd = ' '.join(args)
-sys.stderr.write(f'{tool} received signal {-subp.returncode}: {cmd}\n')
-return (output, subp.returncode)
+with subprocess.Popen(args, stdout=subprocess.PIPE,
+  stderr=stderr, universal_newlines=True) as subp:
+output = subp.communicate()[0]
+if subp.returncode < 0:
+cmd = ' '.join(args)
+sys.stderr.write(f'{tool} received signal \
+   {-subp.returncode}: {cmd}\n')
+return (output, subp.returncode)
 
 def qemu_img_pipe_and_status(*args: str) -> Tuple[str, int]:
 """
@@ -237,6 +236,9 @@ def qemu_io_silent_check(*args):
 class QemuIoInteractive:
 def __init__(self, *args):
 self.args = qemu_io_args_no_fmt + list(args)
+# We need to keep the Popen objext around, and not
+# close it immediately. Therefore, disable the pylint check:
+# pylint: disable=consider-using-with
 self._p = subprocess.Popen(self.args, stdin=subprocess.PIPE,
stdout=subprocess.PIPE,
stderr=subprocess.STDOUT,
@@ -310,22 +312,22 @@ def qemu_nbd_popen(*args):
 cmd.extend(args)
 
 log('Start NBD server')
-p = subprocess.Popen(cmd)
-try:
-while not os.path.exists(pid_file):
-if p.poll() is not None:
-raise RuntimeError(
-"qemu-nbd terminated with exit code {}: {}"
-.format(p.returncode, ' '.join(cmd)))
-
-time.sleep(0.01)
-yield
-finally:
-if os.path.exists(pid_file):
-os.remove(pid_file)
-log('Kill NBD server')
-p.kill()
-p.wait()
+with subprocess.Popen(cmd) as p:
+try:
+while not os.path.exists(pid_file):
+if p.poll() is not None:
+raise RuntimeError(
+"qemu-nbd terminated with exit code {}: {}"
+.format(p.returncode, ' '.join(cmd)))
+
+time.sleep(0.01)
+yield
+finally:
+if os.path.exists(pid_file):
+os.remove(pid_file)
+log('Kill NBD server')
+p.kill()
+p.wait()
 
 def compare_images(img1, img2, fmt1=imgfmt, fmt2=imgfmt):
 '''Return True if two image files are identical'''
@@ -334,13 +336,12 @@ def compare_images(img1, img2, fmt1=imgfmt, fmt2=imgfmt):
 
 def create_image(name, size):
 '''Create a fully-allocated raw image with sector markers'''
-file = open(name, 'wb')
-i = 0
-while i < size:
-sector = struct.pack('>l504xl', i // 512, i // 512)
-file.write(sector)
-i = i + 512
-file.close()
+with open(name, 'wb') as file:
+i = 0
+while i < size:
+sector = struct.pack('>l504xl', i // 512, i // 512)
+file.write(sector)
+i = i + 512
 
 def image_size(img):
 '''Return image's virtual size'''
diff --git a/tests/qemu-iotests/testrunner.py b/tests/qemu-iotests/testrunner.py
index 1fc61fcaa3..eddceeb4ae 100644
--- a/tests/qemu-iotests/testrunner.py
+++ b/tests/qemu-iotests/testrunner.py
@@ -258,17 +258,17 @@ def do_run_test(self, test: str) -> TestResult:
 
 t0 = time.time()
 with f_bad.open('w', encoding="utf-8") as f:
-proc = subprocess.Popen(args, cwd=str(f_test.parent), env=env,
-stdout=f, stderr=subprocess.STDOUT)
-try:
-proc.wait()
-except KeyboardInterrupt:
-proc.terminate()
-proc.wait()
-return

[Bug 1908489] Re: qemu 4.2 bootloops with -cpu host and nested hypervisor

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


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

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

Title:
  qemu 4.2 bootloops with -cpu host and nested hypervisor

Status in QEMU:
  Incomplete
Status in qemu-kvm package in CentOS:
  Unknown

Bug description:
  I've noticed that after upgrading from Ubuntu 18.04 to 20.04 that
  nested virtualization isn't working anymore.

  I have a simple repro where I create a Windows 10 2004 guest and
  enable Hyper-V in it. This worked fine in 18.04 and specifically qemu
  <4.2 (I specifically tested Qemu 2.11-4.1 which work fine).

  The -cpu arg I'm passing is simply:
  -cpu host,l3-cache=on,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time

  Using that Windows won't boot because the nested hypervisor (Hyper-V)
  is unable to be initialize and so it just boot loops. Using the exact
  same qemu command works fine with 4.1 and lower.

  Switching to a named CPU model like Skylake-Client-noTSX-IBRS instead
  of host lets the VM boot but causes some weird behaviour later trying
  to use nested VMs.

  If I had to guess I think it would probably be related to this change
  https://github.com/qemu/qemu/commit/20a78b02d31534ae478779c2f2816c273601e869
  which would line up with 4.2 being the first bad version but unsure.

  For now I just have to keep an older build of QEMU to work around
  this. Let me know if there's anything else needed. I can also try out
  any patches. I already have at least a dozen copies of qemu lying
  around now.

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

[Bug 1908062] Re: qemu-system-i386 virtio-vga: Assertion in address_space_stw_le_cached failed again

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


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

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

Title:
  qemu-system-i386 virtio-vga: Assertion in address_space_stw_le_cached
  failed again

Status in QEMU:
  Incomplete

Bug description:
  When I was fuzzing virtio-vga device of the latest QEMU (1758428, Dec
  12, built with --enable-sanitizers --enable-fuzzing), an assertion
  failed in include/exec/memory_ldst_cached.h.inc.

  --[ Reproducer

  cat << EOF | ./build/i386-softmmu/qemu-system-i386 -machine accel=qtest \
  -machine q35 -display none -nodefaults -device virtio-vga -qtest stdio
  outl 0xcf8 0x881c
  outb 0xcfc 0xc3
  outl 0xcf8 0x8804
  outb 0xcfc 0x06
  write 0xc31024 0x2 0x0040
  write 0xc31028 0x1 0x5a
  write 0xc3101c 0x1 0x01
  writel 0xc3100c 0x2000
  write 0xc31016 0x3 0x80a080
  write 0xc33002 0x1 0x80
  write 0x5c 0x1 0x10
  EOF

  --[ Output

  ==35337==WARNING: ASan doesn't fully support makecontext/swapcontext 
functions and may produce false positives in some cases!
  [I 1607946348.442865] OPENED
  [R +0.059305] outl 0xcf8 0x881c
  OK
  [S +0.059326] OK
  [R +0.059338] outb 0xcfc 0xc3
  OK
  [S +0.059355] OK
  [R +0.059363] outl 0xcf8 0x8804
  OK
  [S +0.059369] OK
  [R +0.059381] outb 0xcfc 0x06
  OK
  [S +0.061094] OK
  [R +0.061107] write 0xc31024 0x2 0x0040
  OK
  [S +0.061120] OK
  [R +0.061127] write 0xc31028 0x1 0x5a
  OK
  [S +0.061135] OK
  [R +0.061142] write 0xc3101c 0x1 0x01
  OK
  [S +0.061158] OK
  [R +0.061167] writel 0xc3100c 0x2000
  OK
  [S +0.061212] OK
  [R +0.061222] write 0xc31016 0x3 0x80a080
  OK
  [S +0.061231] OK
  [R +0.061238] write 0xc33002 0x1 0x80
  OK
  [S +0.061247] OK
  [R +0.061253] write 0x5c 0x1 0x10
  OK
  [S +0.061403] OK
  qemu-system-i386: 
/home/qiuhao/hack/qemu/include/exec/memory_ldst_cached.h.inc:88: void 
address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint32_t, MemTxAttrs, 
MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed.

  --[ Environment

  Ubuntu 20.04.1 5.4.0-58-generic x86_64
  clang: 10.0.0-4ubuntu1
  glibc: 2.31-0ubuntu9.1
  libglib2.0-dev: 2.64.3-1~ubuntu20.04.1

  --[ Note

  Alexander Bulekov found the same assertion failure on 2020-08-04,
  https://bugs.launchpad.net/qemu/+bug/1890333, and it had been fixed in
  commit 2d69eba5fe52045b2c8b0d04fd3806414352afc1.

  Fam Zheng found the same assertion failure on 2018-09-29,
  https://bugs.launchpad.net/qemu/+bug/1795148, and it had been fixed in
  commit db812c4073c77c8a64db8d6663b3416a587c7b4a.

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

[Bug 1907926] Re: Implement TPM2 configuration for emulators that provide TCP interface

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.


** Tags added: feature-request

** Changed in: qemu
   Importance: Undecided => Wishlist

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

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

Title:
  Implement TPM2 configuration for emulators that provide TCP interface

Status in QEMU:
  Incomplete

Bug description:
  swtpm provides several interfaces for its emulated device: unix socket
  (can be used by qemu), chardev. swtpm also provides TCP interface for
  the device which is very convenient for testing as it does not require
  root permissions.

  It would be very useful to have QEMU to work with TPM devices emulated
  via TCP.

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

Re: [PATCH RFC] migrate/ram: remove "ram_bulk_stage" and "fpo_enabled"

2021-05-10 Thread Dr. David Alan Gilbert

* David Hildenbrand (da...@redhat.com) wrote:
> The bulk stage is kind of weird: migration_bitmap_find_dirty() will
> indicate a dirty page, however, ram_save_host_page() will never save it, as
> migration_bitmap_clear_dirty() detects that it is not dirty.
> 
> We already fill the bitmap in ram_list_init_bitmaps() with ones, marking
> everything dirty - it didn't used to be that way, which is why we needed
> an explicit first bulk stage.
> 
> Let's simplify: make the bitmap the single source of thuth. Explicitly
> handle the "xbzrle_enabled after first round" case.

I think you're right here, so (at long last) queued.
I did read the comments on 6eeb63f which added the FPO flag, and I still
think you're right.

> Regarding XBZRLE (implicitly handled via "ram_bulk_stage = false" right
> now), there is now a slight change in behavior:
> - Colo: When starting, it will be disabled (was implicitly enabled)
>   until the first round actually finishes.

Was it or did they see a bulk stage again?
I can imagine that XBZRLE might be useful for COLO if subsequent rounds
of synchornisation finds pages that change but not much.

> - Free page hinting: When starting, XBZRLE will be disabled (was implicitly
>   enabled) until the first round actually finished.

But the XBZRLE cache would be empty anyway on that first round?

> - Snapshots: When starting, XBZRLE will be disabled. We essentially only
>   do a single run, so I guess it will never actually get disabled.
> 
> Postcopy seems to indirectly disable it in ram_save_page(), so there
> shouldn't be really any change.
> 
> Cc: "Michael S. Tsirkin" 
> Cc: Juan Quintela 
> Cc: "Dr. David Alan Gilbert" 
> Cc: Andrey Gruzdev 
> Cc: Peter Xu 
> Signed-off-by: David Hildenbrand 
> ---
> 
> Our dirty bitmap handling is right now a little confusing due to the bulk
> stage. Am i missing something important? Can someone comment on the
> expected XBZRLE handling? It all is a little bit too intertwined for my
> taste.

I think it's mostly due to there being no benefit (and a lot of cost) in
doing xbzrle during the first round.

Dave

> ---
>  hw/virtio/virtio-balloon.c |  4 +-
>  hw/virtio/virtio-mem.c |  3 --
>  include/migration/misc.h   |  1 -
>  migration/ram.c| 78 +-
>  4 files changed, 18 insertions(+), 68 deletions(-)
> 
> diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
> index e770955176..d162b89603 100644
> --- a/hw/virtio/virtio-balloon.c
> +++ b/hw/virtio/virtio-balloon.c
> @@ -659,9 +659,6 @@ virtio_balloon_free_page_hint_notify(NotifierWithReturn 
> *n, void *data)
>  }
>  
>  switch (pnd->reason) {
> -case PRECOPY_NOTIFY_SETUP:
> -precopy_enable_free_page_optimization();
> -break;
>  case PRECOPY_NOTIFY_BEFORE_BITMAP_SYNC:
>  virtio_balloon_free_page_stop(dev);
>  break;
> @@ -681,6 +678,7 @@ virtio_balloon_free_page_hint_notify(NotifierWithReturn 
> *n, void *data)
>   */
>  virtio_balloon_free_page_done(dev);
>  break;
> +case PRECOPY_NOTIFY_SETUP:
>  case PRECOPY_NOTIFY_COMPLETE:
>  break;
>  default:
> diff --git a/hw/virtio/virtio-mem.c b/hw/virtio/virtio-mem.c
> index 99d0712195..c7d261ffe7 100644
> --- a/hw/virtio/virtio-mem.c
> +++ b/hw/virtio/virtio-mem.c
> @@ -1063,9 +1063,6 @@ static int virtio_mem_precopy_notify(NotifierWithReturn 
> *n, void *data)
>  PrecopyNotifyData *pnd = data;
>  
>  switch (pnd->reason) {
> -case PRECOPY_NOTIFY_SETUP:
> -precopy_enable_free_page_optimization();
> -break;
>  case PRECOPY_NOTIFY_AFTER_BITMAP_SYNC:
>  virtio_mem_precopy_exclude_unplugged(vmem);
>  break;
> diff --git a/include/migration/misc.h b/include/migration/misc.h
> index bccc1b6b44..69c7e7e14b 100644
> --- a/include/migration/misc.h
> +++ b/include/migration/misc.h
> @@ -37,7 +37,6 @@ void precopy_infrastructure_init(void);
>  void precopy_add_notifier(NotifierWithReturn *n);
>  void precopy_remove_notifier(NotifierWithReturn *n);
>  int precopy_notify(PrecopyNotifyReason reason, Error **errp);
> -void precopy_enable_free_page_optimization(void);
>  
>  void ram_mig_init(void);
>  void qemu_guest_free_page_hint(void *addr, size_t len);
> diff --git a/migration/ram.c b/migration/ram.c
> index 72143da0ac..7394a9c414 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -313,10 +313,6 @@ struct RAMState {
>  ram_addr_t last_page;
>  /* last ram version we have seen */
>  uint32_t last_version;
> -/* We are in the first round */
> -bool ram_bulk_stage;
> -/* The free page optimization is enabled */
> -bool fpo_enabled;
>  /* How many times we have dirty too many pages */
>  int dirty_rate_high_cnt;
>  /* these variables are used for bitmap sync */
> @@ -332,6 +328,8 @@ struct RAMState {
>  uint64_t xbzrle_pages_prev;
>  /* Amount of xbzrle encoded bytes since the beginning of the period */
>

Re: [PULL v2 00/26] target-arm queue