Re: [RFC PATCH V2 00/11] hw/block/nvme: support multi-path for ctrl/ns
On 21-01-19 07:04:04, Klaus Jensen wrote: > On Jan 19 12:21, Minwoo Im wrote: > > On 21-01-18 22:14:45, Klaus Jensen wrote: > > > On Jan 17 23:53, Minwoo Im wrote: > > > > Hello, > > > > > > > > This patch series introduces NVMe subsystem device to support multi-path > > > > I/O in NVMe device model. Two use-cases are supported along with this > > > > patch: Multi-controller, Namespace Sharing. > > > > > > > > V1 RFC has been discussed with Klaus and Keith, I really appreciate them > > > > for this patch series to have proper direction [1]. > > > > > > > > This patch series contains few start-up refactoring pathces from the > > > > first to fifth patches to make nvme-ns device not to rely on the nvme > > > > controller always. Because nvme-ns shall be able to be mapped to the > > > > subsystem level, not a single controller level so that it should provide > > > > generic initialization code: nvme_ns_setup() with NvmeCtrl. To do that, > > > > the first five patches are to remove the NvmeCtrl * instance argument > > > > from the nvme_ns_setup(). I'd be happy if they are picked! > > > > > > > > For controller and namespace devices, 'subsys' property has been > > > > introduced to map them to a subsystem. If multi-controller needed, we > > > > can specify 'subsys' to controllers the same. > > > > > > > > For namespace deivice, if 'subsys' is not given just like it was, it > > > > will have to be provided with 'bus' parameter to specify a nvme > > > > controller device to attach, it means, they are mutual-exlusive. To > > > > share a namespace between or among controllers, then nvme-ns should have > > > > 'subsys' property to a single nvme subsystem instance. To make a > > > > namespace private one, then we need to specify 'bus' property rather > > > > than the 'subsys'. > > > > > > > > Of course, this series does not require any updates for the run command > > > > for the previos users. > > > > > > > > Plase refer the following example with nvme-cli output: > > > > > > > > QEMU Run: > > > > -device nvme-subsys,id=subsys0 \ > > > > -device nvme,serial=foo,id=nvme0,subsys=subsys0 \ > > > > -device nvme,serial=bar,id=nvme1,subsys=subsys0 \ > > > > -device nvme,serial=baz,id=nvme2,subsys=subsys0 \ > > > > -device nvme-ns,id=ns1,drive=drv10,nsid=1,subsys=subsys0 \ > > > > -device nvme-ns,id=ns2,drive=drv11,nsid=2,bus=nvme2 \ > > > > \ > > > > -device nvme,serial=qux,id=nvme3 \ > > > > -device nvme-ns,id=ns3,drive=drv12,nsid=3,bus=nvme3 > > > > > > > > nvme-cli: > > > > root@vm:~/work# nvme list -v > > > > NVM Express Subsystems > > > > > > > > SubsystemSubsystem-NQN > > > > Controllers > > > > > > > > > > > > > > > > nvme-subsys1 nqn.2019-08.org.qemu:subsys0 > > > > nvme0, nvme1, nvme2 > > > > nvme-subsys3 nqn.2019-08.org.qemu:qux > > > > nvme3 > > > > > > > > NVM Express Controllers > > > > > > > > Device SN MN > > > > FR TxPort AddressSubsystemNamespaces > > > > > > > > -- -- > > > > > > > > nvme0foo QEMU NVMe Ctrl > > > > 1.0 pcie :00:06.0 nvme-subsys1 nvme1n1 > > > > nvme1bar QEMU NVMe Ctrl > > > > 1.0 pcie :00:07.0 nvme-subsys1 nvme1n1 > > > > nvme2baz QEMU NVMe Ctrl > > > > 1.0 pcie :00:08.0 nvme-subsys1 nvme1n1, nvme1n2 > > > > nvme3qux QEMU NVMe Ctrl > > > > 1.0 pcie :00:09.0 nvme-subsys3 > > > > > > > > NVM Express Namespaces > > > > > > > > Device NSID Usage Format > > > > Controllers > > > > -- > > > > > > > > nvme1n1 1134.22 MB / 134.22 MB512 B + 0 B > > > > nvme0, nvme1, nvme2 > > > > nvme1n2 2268.44 MB / 268.44 MB512 B + 0 B > > > > nvme2 > > > > nvme3n1 3268.44 MB / 268.44 MB512 B + 0 B > > > > nvme3 > > > > > > > > Summary: > > > > - Refactored nvme-ns device not to rely on controller during the > > > > setup. [1/11 - 5/11] > > > > - Introduced a nvme-subsys device model. [6/11] > > > > - Create subsystem NQN based on subsystem. [7/11] > > > > - Introduced multi-controller model. [8/11 - 9/11] > > > > - Up
Re: [RFC PATCH V2 02/11] hw/block/nvme: open code for volatile write cache
On Jan 17 23:53, Minwoo Im wrote:
> Volatile Write Cache(VWC) feature is set in nvme_ns_setup() in the
> initial time. This feature is related to block device backed, but this
> feature is controlled in controller level via Set/Get Features command.
>
> This patch removed dependency between nvme and nvme-ns to manage the VWC
> flag value. Also, it open coded the Get Features for VWC to check all
> namespaces attached to the controller, and if false detected, return
> directly false.
>
> Signed-off-by: Minwoo Im
> ---
> hw/block/nvme-ns.c | 4
> hw/block/nvme.c| 15 ---
> hw/block/nvme.h| 1 -
> 3 files changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/hw/block/nvme-ns.c b/hw/block/nvme-ns.c
> index 32662230130b..c403cd36b6bd 100644
> --- a/hw/block/nvme-ns.c
> +++ b/hw/block/nvme-ns.c
> @@ -89,10 +89,6 @@ static int nvme_ns_init_blk(NvmeCtrl *n, NvmeNamespace
> *ns, Error **errp)
> return -1;
> }
>
> -if (blk_enable_write_cache(ns->blkconf.blk)) {
> -n->features.vwc = 0x1;
> -}
> -
> return 0;
> }
>
> diff --git a/hw/block/nvme.c b/hw/block/nvme.c
> index cf0fe28fe6eb..b2a9c48a9d81 100644
> --- a/hw/block/nvme.c
> +++ b/hw/block/nvme.c
> @@ -3033,6 +3033,7 @@ static uint16_t nvme_get_feature(NvmeCtrl *n,
> NvmeRequest *req)
> NvmeGetFeatureSelect sel = NVME_GETFEAT_SELECT(dw10);
> uint16_t iv;
> NvmeNamespace *ns;
> +int i;
>
> static const uint32_t nvme_feature_default[NVME_FID_MAX] = {
> [NVME_ARBITRATION] = NVME_ARB_AB_NOLIMIT,
> @@ -3108,7 +3109,17 @@ static uint16_t nvme_get_feature(NvmeCtrl *n,
> NvmeRequest *req)
> result = ns->features.err_rec;
> goto out;
> case NVME_VOLATILE_WRITE_CACHE:
> -result = n->features.vwc;
> +for (i = 1; i <= n->num_namespaces; i++) {
> +ns = nvme_ns(n, i);
> +if (!ns) {
> +continue;
> +}
> +
> +result = blk_enable_write_cache(ns->blkconf.blk);
> +if (!result) {
> +break;
> +}
> +}
I did a small tweak here and changed `if (!result)` to `if (result)`. We
want to report that a volatile write cache is present if ANY of the
namespace backing devices have a write cache.
signature.asc
Description: PGP signature
Re: [PATCH] tests/acceptance: Test PMON with Loongson-3A1000 CPU
On 1/19/21 7:59 AM, Jiaxun Yang wrote: > On Tue, Jan 19, 2021, at 1:57 PM, Philippe Mathieu-Daudé wrote: >> On 1/18/21 5:54 PM, Alex Bennée wrote: >>> Philippe Mathieu-Daudé writes: On 1/12/21 3:07 AM, Jiaxun Yang wrote: > Test booting of PMON bootloader on loongson3-virt platform. > > $ (venv) AVOCADO_ALLOW_UNTRUSTED_CODE=1 \ > avocado --show=app,console \ > run -t machine:loongson3-virt tests/acceptance > Fetching asset from > tests/acceptance/machine_mips_loongson3v.py:MipsLoongson3v.test_pmon_serial_console > JOB ID : 8e202b3727847c9104d0d3d6546ed225d35f6706 > JOB LOG: > /home/flygoat/avocado/job-results/job-2021-01-12T10.02-8e202b3/job.log ... > console: This software may be redistributed under the BSD copyright. > console: Copyright 2000-2002, Opsycon AB, Sweden. > console: Copyright 2005, ICT CAS. > console: CPU GODSON3 BogoMIPS: 1327 > PASS (3.89 s) > RESULTS: PASS 1 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 | > CANCEL 0 > JOB TIME : 4.38 s > > Signed-off-by: Jiaxun Yang > --- > MAINTAINERS | 1 + > tests/acceptance/machine_mips_loongson3v.py | 39 + > 2 files changed, 40 insertions(+) > create mode 100644 tests/acceptance/machine_mips_loongson3v.py > > diff --git a/MAINTAINERS b/MAINTAINERS > index 4be087b88e..f38882f997 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1164,6 +1164,7 @@ F: hw/intc/loongson_liointc.c > F: hw/mips/loongson3_bootp.c > F: hw/mips/loongson3_bootp.h > F: hw/mips/loongson3_virt.c > +F: tests/acceptance/machine_mips_loongson3v.py > > Boston > M: Paul Burton > diff --git a/tests/acceptance/machine_mips_loongson3v.py > b/tests/acceptance/machine_mips_loongson3v.py > new file mode 100644 > index 00..17a85de69f > --- /dev/null > +++ b/tests/acceptance/machine_mips_loongson3v.py > @@ -0,0 +1,39 @@ > +# Functional tests for the Generic Loongson-3 Platform. > +# > +# Copyright (c) 2020 Philippe Mathieu-Daudé 2021 Jiaxun Yang ? :D >> >> Jiaxun, if you agree I can update that line and queue your patch. > > Please do. Thanks! So: Tested-by: Philippe Mathieu-Daudé Reviewed-by: Philippe Mathieu-Daudé and applied (not removing AVOCADO_ALLOW_UNTRUSTED_CODE, fixing copyright line) to mips-next. Thanks, Phil.
Re: [RFC Qemu PATCH v2 1/2] spapr: drc: Add support for async hcalls at the drc level
Thanks for the comments! On 12/28/20 2:08 PM, David Gibson wrote: On Mon, Dec 21, 2020 at 01:08:53PM +0100, Greg Kurz wrote: ... The overall idea looks good but I think you should consider using a thread pool to implement it. See below. I am not convinced, however. Specifically, attaching this to the DRC doesn't make sense to me. We're adding exactly one DRC related async hcall, and I can't really see much call for another one. We could have other async hcalls - indeed we already have one for HPT resizing - but attaching this to DRCs doesn't help for those. The semantics of the hcall made me think, if this is going to be re-usable for future if implemented at DRC level. Other option is to move the async-hcall-state/list into the NVDIMMState structure in include/hw/mem/nvdimm.h and handle it with machine->nvdimms_state at a global level. Hope you are okay with using the pool based approach that Greg suggested. Please let me know. Thanks, Shivaprasad
[Bug 1811711] Re: qemu-img can not convert virtualbox virtual disk formats qcow
The QEMU project is currently considering to move 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 older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. 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/1811711 Title: qemu-img can not convert virtualbox virtual disk formats qcow Status in QEMU: Incomplete Bug description: Hello, I'm working with QEMU on macOS, and am experiencing issues working with the `qemu-img` command. Info $ sw_vers ProductName:Mac OS X ProductVersion: 10.13.6 BuildVersion: 17G4015 VirtualBox -- $ VBoxManage --version 6.0.0r127566 $ qemu-system-x86_64 --version QEMU emulator version 3.1.50 (v3.1.0-rc2-745-g147923b1a9-dirty) Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers $ qemu-img --version qemu-img version 3.1.50 (v3.1.0-rc2-745-g147923b1a9-dirty) Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers Steps to reproduce -- > Prereq VirtualBox needs to be installed to run the `VBoxManage` command $ VBoxManage createmedium disk --filename vbox-vdisk-exp.qcow --format qcow --size 5 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% Medium created. UUID: e2b36955-3791-4c0e-93d4-913669b1d9fb $ file vbox-vdisk-exp.qcow vbox-vdisk-exp.qcow: QEMU QCOW Image (v1), 5242880 bytes $ qemu-img info vbox-vdisk-exp.qcow image: vbox-vdisk-exp.qcow file format: qcow virtual size: 5.0M (5242880 bytes) disk size: 8.0K cluster_size: 4096 # Convert vbox virtualdisk to qcow2 format using `qemu-img` $ qemu-img convert -f qcow vbox-vdisk-exp.qcow -O qcow2 vbox-vdisk-exp-convert.qcow2 $ file vbox-vdisk-exp-convert.qcow2 vbox-vdisk-exp-convert.qcow2: QEMU QCOW Image (v3), 5242880 bytes # Print info about qemu-img converted image from vbox created qcow image $ qemu-img info vbox-vdisk-exp-convert.qcow2 mutts-6 | 0 < 10:53:00 image: vbox-vdisk-exp-convert.qcow2 file format: qcow2 virtual size: 5.0M (5242880 bytes) disk size: 196K cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false # Print info about vbox created qcow image qemu-img info vbox-vdisk-exp.qcow mutts-6 | 0 < 10:53:19 image: vbox-vdisk-exp.qcow file format: qcow virtual size: 5.0M (5242880 bytes) disk size: 8.0K cluster_size: 4096 I've attached a zip file containing the vbox created qcow image along with the image that `qemu-img` converted. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1811711/+subscriptions
[Bug 1811653] Re: usbredir slow when multi bulk packet per second
The QEMU project is currently considering to move 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 older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. 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/1811653 Title: usbredir slow when multi bulk packet per second Status in QEMU: Incomplete Bug description: QEMU Ver: all version Client: virt-viewer with spice Guest VM: win7 Bug description: Use Qemu 2.1 or later with usbredir, When I redirect a bulk usb-device from virt-viewer client,the bulk-usb-device driver or app in GuestVM will send 50 bulk-urb per times. In VM, using the usblyzer to monitor the usb packet, it show these 50 bulk-urb packet (24576 bytes per urb) send in 1ms, But in the QEMU VM log, It shows as below = 2019-01-14T08:27:26.096809Z qemu-kvm: usb-redir: bulk-out ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 2019-01-14T08:27:26.105680Z qemu-kvm: usb-redir: bulk-in status 0 ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 2019-01-14T08:27:26.108219Z qemu-kvm: usb-redir: bulk-out ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 2019-01-14T08:27:26.116742Z qemu-kvm: usb-redir: bulk-in status 0 ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 2019-01-14T08:27:26.119242Z qemu-kvm: usb-redir: bulk-out ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 2019-01-14T08:27:26.129851Z qemu-kvm: usb-redir: bulk-in status 0 ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 2019-01-14T08:27:26.132349Z qemu-kvm: usb-redir: bulk-out ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 2019-01-14T08:27:26.141248Z qemu-kvm: usb-redir: bulk-in status 0 ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 2019-01-14T08:27:26.144932Z qemu-kvm: usb-redir: bulk-out ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 2019-01-14T08:27:26.154035Z qemu-kvm: usb-redir: bulk-in status 0 ep 86 stream 0 len 49152 id 2114122112 0x7f0ffa300b40 = It shows that the bulk packet is single thread send and recv, per bulk packet will use 10-20ms, all 50 bulk-packets will use 500~1000ms, so the in the VM, bulk-urb will timeout always! How to send the bulk packet by multithread to speedup the bulk-urb send and recv, for example: bulk-out ep 86 stream 0 len 49152 id 1 bulk-out ep 86 stream 0 len 49152 id 2 bulk-out ep 86 stream 0 len 49152 id 3 bulk-out ep 86 stream 0 len 49152 id 4 bulk-out ... bulk-out ep 86 stream 0 len 49152 id 50 ... bulk-in status 0 ep 86 stream 0 len 49152 id 1 bulk-in status 0 ep 86 stream 0 len 49152 id 2 bulk-in status 0 ep 86 stream 0 len 49152 id 3 bulk-in status 0 ep 86 stream 0 len 49152 id 4 bulk-in ... bulk-in status 0 ep 86 stream 0 len 49152 id 50 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1811653/+subscriptions
[Bug 1811862] Re: microcode version stays 0x1 even if -cpu host is used
The QEMU project is currently considering to move 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 older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. 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/1811862 Title: microcode version stays 0x1 even if -cpu host is used Status in QEMU: Incomplete Bug description: The microcode version of my host cpu has the following version: grep microcode /proc/cpuinfo | head -1 microcode : 0x3d while trying to run ESXi in an nested VM, the boot bailed out with error message that at least microcode version 0x19 is needed. It seems they have introduced such a check on certain CPU types. The VM in question is using the "host-passthrough" option in libvirt and the qemu command line reads as this: 21172 ?Sl 0:09 /usr/libexec/qemu-kvm -name guest=hpe-env- client1,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-33 -hpe-env-client1/master-key.aes -machine pc-i440fx- rhel7.6.0,accel=kvm,usb=off,dump-guest-core=off -cpu host Running a regular Linux VM with `host-passthrough` shows that the microcode version is still reported as 0x1. Within the VM: [root@hpe-env-client1 ~]# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 63 model name : Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz stepping: 2 microcode : 0x1 cpu MHz : 2397.222 My impression is qemu should copy the hosts microcode version in this case? Running Qemu von RHEl8 beta here. [root@3parserver ~]# /usr/libexec/qemu-kvm --version QEMU emulator version 2.12.0 (qemu-kvm-2.12.0-41.el8+2104+3e32e6f8) To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1811862/+subscriptions
[Bug 1811916] Re: SDL2 interface didn't follow the current X11 keyboard layout for hotkeys
The QEMU project is currently considering to move 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 older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. 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/1811916 Title: SDL2 interface didn't follow the current X11 keyboard layout for hotkeys Status in QEMU: Incomplete Bug description: My X11 was configured to use Dvorak keyboard layout, with setxkbmap(1). Despite the window title said 'Press Ctrl-Alt-G to exit grab' after it grabbed the mouse, pressing this hotkey don't have any effects, and I has to switch to a virtual terminal to kill(1) that qemu process. By debugging the program I found it is using the raw key code to handle the key events, so I must use CTRL-ALT-I to exit the grab, in my keyboard. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1811916/+subscriptions
Re: [PATCH] tests/acceptance: Test PMON with Loongson-3A1000 CPU
On Tue, Jan 19, 2021, at 1:57 PM, Philippe Mathieu-Daudé wrote:
> On 1/18/21 5:54 PM, Alex Bennée wrote:
> > Philippe Mathieu-Daudé writes:
> >> On 1/12/21 3:07 AM, Jiaxun Yang wrote:
> >>> Test booting of PMON bootloader on loongson3-virt platform.
> >>>
> >>> $ (venv) AVOCADO_ALLOW_UNTRUSTED_CODE=1 \
> >>> avocado --show=app,console \
> >>> run -t machine:loongson3-virt tests/acceptance
> >>> Fetching asset from
> >>> tests/acceptance/machine_mips_loongson3v.py:MipsLoongson3v.test_pmon_serial_console
> >>> JOB ID : 8e202b3727847c9104d0d3d6546ed225d35f6706
> >>> JOB LOG:
> >>> /home/flygoat/avocado/job-results/job-2021-01-12T10.02-8e202b3/job.log
> >> ...
> >>> console: This software may be redistributed under the BSD copyright.
> >>> console: Copyright 2000-2002, Opsycon AB, Sweden.
> >>> console: Copyright 2005, ICT CAS.
> >>> console: CPU GODSON3 BogoMIPS: 1327
> >>> PASS (3.89 s)
> >>> RESULTS: PASS 1 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 |
> >>> CANCEL 0
> >>> JOB TIME : 4.38 s
> >>>
> >>> Signed-off-by: Jiaxun Yang
> >>> ---
> >>> MAINTAINERS | 1 +
> >>> tests/acceptance/machine_mips_loongson3v.py | 39 +
> >>> 2 files changed, 40 insertions(+)
> >>> create mode 100644 tests/acceptance/machine_mips_loongson3v.py
> >>>
> >>> diff --git a/MAINTAINERS b/MAINTAINERS
> >>> index 4be087b88e..f38882f997 100644
> >>> --- a/MAINTAINERS
> >>> +++ b/MAINTAINERS
> >>> @@ -1164,6 +1164,7 @@ F: hw/intc/loongson_liointc.c
> >>> F: hw/mips/loongson3_bootp.c
> >>> F: hw/mips/loongson3_bootp.h
> >>> F: hw/mips/loongson3_virt.c
> >>> +F: tests/acceptance/machine_mips_loongson3v.py
> >>>
> >>> Boston
> >>> M: Paul Burton
> >>> diff --git a/tests/acceptance/machine_mips_loongson3v.py
> >>> b/tests/acceptance/machine_mips_loongson3v.py
> >>> new file mode 100644
> >>> index 00..17a85de69f
> >>> --- /dev/null
> >>> +++ b/tests/acceptance/machine_mips_loongson3v.py
> >>> @@ -0,0 +1,39 @@
> >>> +# Functional tests for the Generic Loongson-3 Platform.
> >>> +#
> >>> +# Copyright (c) 2020 Philippe Mathieu-Daudé
> >>
> >> 2021 Jiaxun Yang ? :D
>
> Jiaxun, if you agree I can update that line and queue your patch.
Please do. Thanks!
- Jiaxun
>
> >>
> >>> +#
> >>> +# This work is licensed under the terms of the GNU GPL, version 2 or
> >>> later.
> >>> +# See the COPYING file in the top-level directory.
> >>> +#
> >>> +# SPDX-License-Identifier: GPL-2.0-or-later
> >>> +
> >>> +import os
> >>> +import time
> >>> +
> >>> +from avocado import skipUnless
> >>> +from avocado_qemu import Test
> >>> +from avocado_qemu import wait_for_console_pattern
> >>> +
> >>> +class MipsLoongson3v(Test):
> >>> +@skipUnless(os.getenv('AVOCADO_ALLOW_UNTRUSTED_CODE'), 'untrusted
> >>> code')
> >>
> >> The source code is published [1], you provided reproducible
> >> workflow [2] and a tag [3] with a public build artifacts [4],
> >> so my understanding is this is "trustable" binary.
> >>
> >> Alex, would it be OK to add this test without the UNTRUSTED tag
> >> (amending the links in the commit description)?
> >
> > It's a subjective call. Having open source code is a minimum step to
> > being "trusted" but really the trust is in the community that hosts the
> > code. The upstream distros (e.g. Debian/Fedora) are trusted because
> > people install their software on their desktops and basically give the
> > software publisher root on their machines. There has to be a level of
> > trust that the distros won't abuse that to steal information from their
> > users.
> >
> > I personally have no idea about the loongson community because it's not
> > one I interact with so I have no idea what sort of place it is. Is it a
> > code dump for semi-proprietary non-upstreamed kernels or is it a place
> > that has a good development culture with a sane security process that is
> > responsive to problems and moderately conservative with what they merge?
> >
> > If you would trust your keys to a machine running this communities
> > software then by all means treated it as a trusted source.
>
> Subjective call understood :)
>
> Thanks for your clear explanation,
>
> Phil.
>
>
--
- Jiaxun
[PATCH] target/arm/m_helper: Silence GCC 10 maybe-uninitialized error
When building with GCC 10.2 configured with --extra-cflags=-Os, we get:
target/arm/m_helper.c: In function ‘arm_v7m_cpu_do_interrupt’:
target/arm/m_helper.c:1811:16: error: ‘restore_s16_s31’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
1811 | if (restore_s16_s31) {
|^
target/arm/m_helper.c:1350:10: note: ‘restore_s16_s31’ was declared here
1350 | bool restore_s16_s31;
| ^~~
cc1: all warnings being treated as errors
Initialize the 'restore_s16_s31' variable to silence the warning.
Signed-off-by: Philippe Mathieu-Daudé
---
target/arm/m_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/arm/m_helper.c b/target/arm/m_helper.c
index 61760030292..731c435c00b 100644
--- a/target/arm/m_helper.c
+++ b/target/arm/m_helper.c
@@ -1347,7 +1347,7 @@ static void do_v7m_exception_exit(ARMCPU *cpu)
bool exc_secure = false;
bool return_to_secure;
bool ftype;
-bool restore_s16_s31;
+bool restore_s16_s31 = false;
/*
* If we're not in Handler mode then jumps to magic exception-exit
--
2.26.2
[Bug 1269628] Re: Feature Request: Please add TCG OPAL 2 emulation support to the virtio disk emulation
** Changed in: qemu Status: Expired => New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1269628 Title: Feature Request: Please add TCG OPAL 2 emulation support to the virtio disk emulation Status in QEMU: New Bug description: In order to allow windows guests (and soon, linux guests) which are TCG OPAL 2 aware to perform disk encryption in a native fashion with hardware acceleration, please add TCG OPAL 2 emulation to the VIRTIO driver. Encryption should occur at the host level using any cryptographic facilities available to the host, for example AES-NI, Cryptography Hardware, underlying block device cryptography support where available or any other cryptography facility that may be developed and implemented in the future. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1269628/+subscriptions
[Bug 1605123] Re: PEXT returns wrong values, seemingly switches arguments
Fix has been committed: https://git.qemu.org/?p=qemu.git;a=commitdiff;h=75b208c28316095c4685 ** Changed in: qemu Status: New => Fix Committed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1605123 Title: PEXT returns wrong values, seemingly switches arguments Status in QEMU: Fix Committed Bug description: Hi, I fiddled with BMI2 instructions and discovered that pext instructions emulated with "qemu-x86_64 -cpu Haswell" return the wrong value. It seemingly switches up its arguments. I suspect that the error is around the gen_helper_pext(...) call in target-i386/translate.c. I checked helper_pext in target-i386/int_helper.c and it works fine. I ran my program on a CPU with BMI2 instruction set too, and it indeed returns different values. I didn't check pdep, it could have the same problem. $ qemu-x86_64 --version qemu-x86_64 version 2.6.50 (v2.6.0-2095-ge66b05e-dirty), Copyright (c) 2003-2008 Fabrice Bellard $ uname -a Linux lenard-hp 4.3.0-1-amd64 #1 SMP Debian 4.3.5-1 (2016-02-06) x86_64 GNU/Linux I compiled the attached file with the command line "gcc -o main -g -mbmi2 main.c". $ gcc --version gcc (Debian 5.4.0-6) 5.4.0 20160609 Best regards, Lénárd Szolnoki To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1605123/+subscriptions
[PULL 13/13] spapr_cpu_core.c: use g_auto* in spapr_create_vcpu()
From: Daniel Henrique Barboza
Use g_autoptr() with Object and g_autofree with the string to
avoid the need of a cleanup path.
Signed-off-by: Daniel Henrique Barboza
Message-Id: <20210114180628.1675603-6-danielhb...@gmail.com>
Signed-off-by: David Gibson
---
hw/ppc/spapr_cpu_core.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c
index 2f7dc3c23d..4f316a6f9d 100644
--- a/hw/ppc/spapr_cpu_core.c
+++ b/hw/ppc/spapr_cpu_core.c
@@ -277,8 +277,8 @@ static PowerPCCPU *spapr_create_vcpu(SpaprCpuCore *sc, int
i, Error **errp)
{
SpaprCpuCoreClass *scc = SPAPR_CPU_CORE_GET_CLASS(sc);
CPUCore *cc = CPU_CORE(sc);
-Object *obj;
-char *id;
+g_autoptr(Object) obj = NULL;
+g_autofree char *id = NULL;
CPUState *cs;
PowerPCCPU *cpu;
@@ -293,23 +293,17 @@ static PowerPCCPU *spapr_create_vcpu(SpaprCpuCore *sc,
int i, Error **errp)
cs->start_powered_off = true;
cs->cpu_index = cc->core_id + i;
if (!spapr_set_vcpu_id(cpu, cs->cpu_index, errp)) {
-goto err;
+return NULL;
}
cpu->node_id = sc->node_id;
id = g_strdup_printf("thread[%d]", i);
object_property_add_child(OBJECT(sc), id, obj);
-g_free(id);
cpu->machine_data = g_new0(SpaprCpuState, 1);
-object_unref(obj);
return cpu;
-
-err:
-object_unref(obj);
-return NULL;
}
static void spapr_cpu_core_realize(DeviceState *dev, Error **errp)
--
2.29.2
[PULL 11/13] spapr_hcall.c: make do_client_architecture_support static
From: Daniel Henrique Barboza The function is called only inside spapr_hcall.c. Signed-off-by: Daniel Henrique Barboza Message-Id: <20210114180628.1675603-3-danielhb...@gmail.com> Signed-off-by: David Gibson --- hw/ppc/spapr_hcall.c | 1 + include/hw/ppc/spapr.h | 5 - 2 files changed, 1 insertion(+), 5 deletions(-) diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c index e5dfc1ba7a..7b5cd3553c 100644 --- a/hw/ppc/spapr_hcall.c +++ b/hw/ppc/spapr_hcall.c @@ -1632,6 +1632,7 @@ static uint32_t cas_check_pvr(PowerPCCPU *cpu, uint32_t max_compat, return best_compat; } +static target_ulong do_client_architecture_support(PowerPCCPU *cpu, SpaprMachineState *spapr, target_ulong vec, diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h index 7f785409e4..c27c7ce515 100644 --- a/include/hw/ppc/spapr.h +++ b/include/hw/ppc/spapr.h @@ -582,11 +582,6 @@ void spapr_register_hypercall(target_ulong opcode, spapr_hcall_fn fn); target_ulong spapr_hypercall(PowerPCCPU *cpu, target_ulong opcode, target_ulong *args); -target_ulong do_client_architecture_support(PowerPCCPU *cpu, -SpaprMachineState *spapr, -target_ulong addr, -target_ulong fdt_bufsize); - /* Virtual Processor Area structure constants */ #define VPA_MIN_SIZE 640 #define VPA_SIZE_OFFSET0x4 -- 2.29.2
[PULL 10/13] spapr.h: fix trailing whitespace in phb_placement
From: Daniel Henrique Barboza
This whitespace was messing with lots of diffs if you happen
to use an editor that eliminates trailing whitespaces on file
save.
Signed-off-by: Daniel Henrique Barboza
Message-Id: <20210114180628.1675603-2-danielhb...@gmail.com>
Signed-off-by: David Gibson
---
include/hw/ppc/spapr.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
index 3ad2ff7132..7f785409e4 100644
--- a/include/hw/ppc/spapr.h
+++ b/include/hw/ppc/spapr.h
@@ -144,7 +144,7 @@ struct SpaprMachineClass {
bool pre_5_2_numa_associativity;
bool (*phb_placement)(SpaprMachineState *spapr, uint32_t index,
- uint64_t *buid, hwaddr *pio,
+ uint64_t *buid, hwaddr *pio,
hwaddr *mmio32, hwaddr *mmio64,
unsigned n_dma, uint32_t *liobns, hwaddr *nv2gpa,
hwaddr *nv2atsd, Error **errp);
--
2.29.2
[PULL 07/13] Revert "ppc4xx: Move common dependency on serial to common option"
From: BALATON Zoltan This reverts commit e6d5106786 which was added mistakenly. While this change works it was suggested during review that keeping dependencies explicit for each board may be better than listing them in a common option so keep the previous version and revert this change. Signed-off-by: BALATON Zoltan Message-Id: <8c65807fc7dc1c4c4f6320f2fd6409a3091c88ff.1610143658.git.bala...@eik.bme.hu> Reviewed-by: Peter Maydell Signed-off-by: David Gibson --- hw/ppc/Kconfig | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/hw/ppc/Kconfig b/hw/ppc/Kconfig index d2329edbab..d11dc30509 100644 --- a/hw/ppc/Kconfig +++ b/hw/ppc/Kconfig @@ -36,6 +36,7 @@ config PPC405 select M48T59 select PFLASH_CFI02 select PPC4XX +select SERIAL config PPC440 bool @@ -44,6 +45,7 @@ config PPC440 imply E1000_PCI select PCI_EXPRESS select PPC4XX +select SERIAL select FDT_PPC config PPC4XX @@ -51,7 +53,6 @@ config PPC4XX select BITBANG_I2C select PCI select PPC_UIC -select SERIAL config SAM460EX bool @@ -60,6 +61,7 @@ config SAM460EX select IDE_SII3112 select M41T80 select PPC440 +select SERIAL select SM501 select SMBUS_EEPROM select USB_EHCI_SYSBUS @@ -121,6 +123,7 @@ config VIRTEX bool select PPC4XX select PFLASH_CFI01 +select SERIAL select XILINX select XILINX_ETHLITE select FDT_PPC -- 2.29.2
[PULL 08/13] sam460ex: Use type cast macro instead of simple cast
From: BALATON Zoltan
Use the PCI_BUS type cast macro to convert result of qdev_get_child_bus().
Also remove the check for NULL afterwards which should not be needed
because sysbus_create_simple() uses error_abort and we create the PCI
host object here that's expected to have a PCI bus so this shouldn't
fail. Even if it would fail that would be due to a programmer error so
an error message is not necessary.
Signed-off-by: BALATON Zoltan
Message-Id:
Reviewed-by: Peter Maydell
Signed-off-by: David Gibson
---
hw/ppc/sam460ex.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/hw/ppc/sam460ex.c b/hw/ppc/sam460ex.c
index 45721ad6c7..e459b43065 100644
--- a/hw/ppc/sam460ex.c
+++ b/hw/ppc/sam460ex.c
@@ -419,11 +419,8 @@ static void sam460ex_init(MachineState *machine)
/* All PCI irqs are connected to the same UIC pin (cf. UBoot source) */
dev = sysbus_create_simple("ppc440-pcix-host", 0xc0ec0,
qdev_get_gpio_in(uic[1], 0));
-pci_bus = (PCIBus *)qdev_get_child_bus(dev, "pci.0");
-if (!pci_bus) {
-error_report("couldn't create PCI controller!");
-exit(1);
-}
+pci_bus = PCI_BUS(qdev_get_child_bus(dev, "pci.0"));
+
memory_region_init_alias(isa, NULL, "isa_mmio", get_system_io(),
0, 0x1);
memory_region_add_subregion(get_system_memory(), 0xc0800, isa);
--
2.29.2
[PULL 05/13] hw/ppc: Remove unused ppcuic_init()
From: Peter Maydell
Now we've converted all the callsites to directly create the QOM UIC
device themselves, the ppcuic_init() function is unused and can be
removed. The enum defining PPCUIC symbolic constants can be moved
to the ppc-uic.h header where it more naturally belongs.
Signed-off-by: Peter Maydell
Reviewed-by: Edgar E. Iglesias
Tested-by: Edgar E. Iglesias
Message-Id: <20210108171212.16500-5-peter.mayd...@linaro.org>
Signed-off-by: David Gibson
---
hw/ppc/ppc4xx_devs.c | 38 --
include/hw/intc/ppc-uic.h | 7 +++
include/hw/ppc/ppc4xx.h | 9 -
3 files changed, 7 insertions(+), 47 deletions(-)
diff --git a/hw/ppc/ppc4xx_devs.c b/hw/ppc/ppc4xx_devs.c
index ffe4cf43e8..fe9d4f7155 100644
--- a/hw/ppc/ppc4xx_devs.c
+++ b/hw/ppc/ppc4xx_devs.c
@@ -77,44 +77,6 @@ PowerPCCPU *ppc4xx_init(const char *cpu_type,
return cpu;
}
-/*/
-/* "Universal" Interrupt controller */
-
-qemu_irq *ppcuic_init (CPUPPCState *env, qemu_irq *irqs,
- uint32_t dcr_base, int has_ssr, int has_vr)
-{
-DeviceState *uicdev = qdev_new(TYPE_PPC_UIC);
-SysBusDevice *uicsbd = SYS_BUS_DEVICE(uicdev);
-qemu_irq *uic_irqs;
-int i;
-
-qdev_prop_set_uint32(uicdev, "dcr-base", dcr_base);
-qdev_prop_set_bit(uicdev, "use-vectors", has_vr);
-object_property_set_link(OBJECT(uicdev), "cpu", OBJECT(env_cpu(env)),
- &error_fatal);
-sysbus_realize_and_unref(uicsbd, &error_fatal);
-
-sysbus_connect_irq(uicsbd, PPCUIC_OUTPUT_INT, irqs[PPCUIC_OUTPUT_INT]);
-sysbus_connect_irq(uicsbd, PPCUIC_OUTPUT_CINT, irqs[PPCUIC_OUTPUT_CINT]);
-
-/*
- * Return an allocated array of the UIC's input IRQ lines.
- * This is an ugly temporary API to retain compatibility with
- * the ppcuic_init() interface from the pre-QOM-conversion UIC.
- * None of the callers free this array, so it is leaked -- but
- * so was the array allocated by qemu_allocate_irqs() in the
- * old code.
- *
- * The callers should just instantiate the UIC and wire it up
- * themselves rather than passing qemu_irq* in and out of this function.
- */
-uic_irqs = g_new0(qemu_irq, UIC_MAX_IRQ);
-for (i = 0; i < UIC_MAX_IRQ; i++) {
-uic_irqs[i] = qdev_get_gpio_in(uicdev, i);
-}
-return uic_irqs;
-}
-
/*/
/* SDRAM controller */
typedef struct ppc4xx_sdram_t ppc4xx_sdram_t;
diff --git a/include/hw/intc/ppc-uic.h b/include/hw/intc/ppc-uic.h
index e614e2ffd8..22dd5e5ac2 100644
--- a/include/hw/intc/ppc-uic.h
+++ b/include/hw/intc/ppc-uic.h
@@ -47,6 +47,13 @@ OBJECT_DECLARE_SIMPLE_TYPE(PPCUIC, PPC_UIC)
#define UIC_MAX_IRQ 32
+/* Symbolic constants for the sysbus IRQ outputs */
+enum {
+PPCUIC_OUTPUT_INT = 0,
+PPCUIC_OUTPUT_CINT = 1,
+PPCUIC_OUTPUT_NB,
+};
+
struct PPCUIC {
/*< private >*/
SysBusDevice parent_obj;
diff --git a/include/hw/ppc/ppc4xx.h b/include/hw/ppc/ppc4xx.h
index cc19c8da5b..980f964b5a 100644
--- a/include/hw/ppc/ppc4xx.h
+++ b/include/hw/ppc/ppc4xx.h
@@ -33,15 +33,6 @@ PowerPCCPU *ppc4xx_init(const char *cpu_model,
clk_setup_t *cpu_clk, clk_setup_t *tb_clk,
uint32_t sysclk);
-/* PowerPC 4xx universal interrupt controller */
-enum {
-PPCUIC_OUTPUT_INT = 0,
-PPCUIC_OUTPUT_CINT = 1,
-PPCUIC_OUTPUT_NB,
-};
-qemu_irq *ppcuic_init (CPUPPCState *env, qemu_irq *irqs,
- uint32_t dcr_base, int has_ssr, int has_vr);
-
void ppc4xx_sdram_banks(MemoryRegion *ram, int nr_banks,
MemoryRegion ram_memories[],
hwaddr ram_bases[], hwaddr ram_sizes[],
--
2.29.2
[PULL 09/13] spapr: Improve handling of memory unplug with old guests
From: Greg Kurz
Since commit 1e8b5b1aa16b ("spapr: Allow memory unplug to always succeed")
trying to unplug memory from a guest that doesn't support it (eg. rhel6)
no longer generates an error like it used to. Instead, it leaves the
memory around : only a subsequent reboot or manual use of drmgr within
the guest can complete the hot-unplug sequence. A flag was added to
SpaprMachineClass so that this new behavior only applies to the default
machine type.
We can do better. CAS processes all pending hot-unplug requests. This
means that we don't really care about what the guest supports if
the hot-unplug request happens before CAS.
All guests that we care for, even old ones, set enough bits in OV5
that lead to a non-empty bitmap in spapr->ov5_cas. Use that as a
heuristic to decide if CAS has already occured or not.
Always accept unplug requests that happen before CAS since CAS will
process them. Restore the previous behavior of rejecting them after
CAS when we know that the guest doesn't support memory hot-unplug.
This behavior is suitable for all machine types : this allows to
drop the pre_6_0_memory_unplug flag.
Fixes: 1e8b5b1aa16b ("spapr: Allow memory unplug to always succeed")
Signed-off-by: Greg Kurz
Message-Id: <161012708715.801107.11418801796987916516.st...@bahia.lan>
Reviewed-by: Daniel Henrique Barboza
Signed-off-by: David Gibson
---
hw/ppc/spapr.c | 24 +---
hw/ppc/spapr_events.c | 3 +--
hw/ppc/spapr_ovec.c | 7 +++
include/hw/ppc/spapr.h | 2 +-
include/hw/ppc/spapr_ovec.h | 1 +
5 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 2c403b574e..6c47466fc2 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -4048,6 +4048,18 @@ static void spapr_machine_device_unplug(HotplugHandler
*hotplug_dev,
}
}
+bool spapr_memory_hot_unplug_supported(SpaprMachineState *spapr)
+{
+return spapr_ovec_test(spapr->ov5_cas, OV5_HP_EVT) ||
+/*
+ * CAS will process all pending unplug requests.
+ *
+ * HACK: a guest could theoretically have cleared all bits in OV5,
+ * but none of the guests we care for do.
+ */
+spapr_ovec_empty(spapr->ov5_cas);
+}
+
static void spapr_machine_device_unplug_request(HotplugHandler *hotplug_dev,
DeviceState *dev, Error **errp)
{
@@ -4056,16 +4068,9 @@ static void
spapr_machine_device_unplug_request(HotplugHandler *hotplug_dev,
SpaprMachineClass *smc = SPAPR_MACHINE_CLASS(mc);
if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
-if (!smc->pre_6_0_memory_unplug ||
-spapr_ovec_test(sms->ov5_cas, OV5_HP_EVT)) {
+if (spapr_memory_hot_unplug_supported(sms)) {
spapr_memory_unplug_request(hotplug_dev, dev, errp);
} else {
-/* NOTE: this means there is a window after guest reset, prior to
- * CAS negotiation, where unplug requests will fail due to the
- * capability not being detected yet. This is a bit different than
- * the case with PCI unplug, where the events will be queued and
- * eventually handled by the guest after boot
- */
error_setg(errp, "Memory hot unplug not supported for this guest");
}
} else if (object_dynamic_cast(OBJECT(dev), TYPE_SPAPR_CPU_CORE)) {
@@ -4543,11 +4548,8 @@ DEFINE_SPAPR_MACHINE(6_0, "6.0", true);
*/
static void spapr_machine_5_2_class_options(MachineClass *mc)
{
-SpaprMachineClass *smc = SPAPR_MACHINE_CLASS(mc);
-
spapr_machine_6_0_class_options(mc);
compat_props_add(mc->compat_props, hw_compat_5_2, hw_compat_5_2_len);
-smc->pre_6_0_memory_unplug = true;
}
DEFINE_SPAPR_MACHINE(5_2, "5.2", false);
diff --git a/hw/ppc/spapr_events.c b/hw/ppc/spapr_events.c
index 6aedd988b3..d51daedfa6 100644
--- a/hw/ppc/spapr_events.c
+++ b/hw/ppc/spapr_events.c
@@ -658,8 +658,7 @@ static void spapr_hotplug_req_event(uint8_t hp_id, uint8_t
hp_action,
/* we should not be using count_indexed value unless the guest
* supports dedicated hotplug event source
*/
-g_assert(!SPAPR_MACHINE_GET_CLASS(spapr)->pre_6_0_memory_unplug ||
- spapr_ovec_test(spapr->ov5_cas, OV5_HP_EVT));
+g_assert(spapr_memory_hot_unplug_supported(spapr));
hp->drc_id.count_indexed.count =
cpu_to_be32(drc_id->count_indexed.count);
hp->drc_id.count_indexed.index =
diff --git a/hw/ppc/spapr_ovec.c b/hw/ppc/spapr_ovec.c
index dd003f1763..b2567caa5c 100644
--- a/hw/ppc/spapr_ovec.c
+++ b/hw/ppc/spapr_ovec.c
@@ -125,6 +125,13 @@ bool spapr_ovec_test(SpaprOptionVector *ov, long bitnr)
return test_bit(bitnr, ov->bitmap) ? true : false;
}
+bool spapr_ovec_empty(SpaprOptionVector *ov)
+{
+g_assert(ov);
+
+return bitmap_empty(ov->bitmap, OV_MAXBITS);
+}
+
static void guest_byte_to_bitmap(uint8_t
[PULL 00/13] ppc-for-6.0 queue 20210119
The following changes since commit e43d564fa3a0d1e133935c8180ad4f4ccf699f33: Merge remote-tracking branch 'remotes/vivier2/tags/trivial-branch-for-6.0-pull-request' into staging (2021-01-18 15:19:06 +) are available in the Git repository at: https://gitlab.com/dgibson/qemu.git tags/ppc-for-6.0-20210119 for you to fetch changes up to 2a05350e90ba09b6f42f5cff81f4aa7580a998be: spapr_cpu_core.c: use g_auto* in spapr_create_vcpu() (2021-01-19 10:20:29 +1100) ppc patch queue 2021-01-19 Next pull request for qemu-6.0. Not a huge amount here, but it does have some important fixes from Greg Kurz. Includes: * A number of minor cleanups from Daniel Barboza (preliminaries for some hotplug changes that are still under review) * Improved handling of memory hotplug from Greg Kurz * A number of fixes for sam460ex and other 440 based platforms from Zolan Balaton * Some fixes for the QOMification of the PPC 4xx UIC interrupt controller from Peter Maydell BALATON Zoltan (3): Revert "sam460ex: Remove FDT_PPC dependency from KConfig" Revert "ppc4xx: Move common dependency on serial to common option" sam460ex: Use type cast macro instead of simple cast Daniel Henrique Barboza (4): spapr.h: fix trailing whitespace in phb_placement spapr_hcall.c: make do_client_architecture_support static spapr_rtas.c: fix identation of rtas_ibm_suspend_me() args spapr_cpu_core.c: use g_auto* in spapr_create_vcpu() Greg Kurz (1): spapr: Improve handling of memory unplug with old guests Peter Maydell (5): hw/ppc/sam460ex: Drop use of ppcuic_init() hw/ppc: Delete unused ppc405cr_init() code hw/intc/ppc-uic: Make default dcr-base 0xc0, not 0x30 hw/ppc/ppc405_uc: Drop use of ppcuic_init() hw/ppc: Remove unused ppcuic_init() hw/intc/ppc-uic.c | 2 +- hw/ppc/Kconfig | 6 +- hw/ppc/ppc405.h | 8 +- hw/ppc/ppc405_boards.c | 8 +- hw/ppc/ppc405_uc.c | 415 +--- hw/ppc/ppc4xx_devs.c| 38 hw/ppc/sam460ex.c | 76 +--- hw/ppc/spapr.c | 24 +-- hw/ppc/spapr_cpu_core.c | 12 +- hw/ppc/spapr_events.c | 3 +- hw/ppc/spapr_hcall.c| 1 + hw/ppc/spapr_ovec.c | 7 + hw/ppc/spapr_rtas.c | 6 +- include/hw/intc/ppc-uic.h | 7 + include/hw/ppc/ppc4xx.h | 9 - include/hw/ppc/spapr.h | 9 +- include/hw/ppc/spapr_ovec.h | 1 + 17 files changed, 146 insertions(+), 486 deletions(-)
[PULL 02/13] hw/ppc: Delete unused ppc405cr_init() code
From: Peter Maydell
The function ppc405cr_init() has apparently been unused since it was
added in commit 8ecc7913525ecb in 2007.
Remove this dead code, so we don't have to convert it away from using
ppcuic_init().
Signed-off-by: Peter Maydell
Message-Id: <20210108171212.16500-3-peter.mayd...@linaro.org>
Signed-off-by: David Gibson
---
hw/ppc/ppc405.h| 6 -
hw/ppc/ppc405_uc.c | 345 -
2 files changed, 351 deletions(-)
diff --git a/hw/ppc/ppc405.h b/hw/ppc/ppc405.h
index 7ed25cfa1b..e6c702f7e0 100644
--- a/hw/ppc/ppc405.h
+++ b/hw/ppc/ppc405.h
@@ -62,12 +62,6 @@ ram_addr_t ppc405_set_bootinfo (CPUPPCState *env,
ppc4xx_bd_info_t *bd,
void ppc4xx_plb_init(CPUPPCState *env);
void ppc405_ebc_init(CPUPPCState *env);
-CPUPPCState *ppc405cr_init(MemoryRegion *address_space_mem,
-MemoryRegion ram_memories[4],
-hwaddr ram_bases[4],
-hwaddr ram_sizes[4],
-uint32_t sysclk, qemu_irq **picp,
-int do_init);
CPUPPCState *ppc405ep_init(MemoryRegion *address_space_mem,
MemoryRegion ram_memories[2],
hwaddr ram_bases[2],
diff --git a/hw/ppc/ppc405_uc.c b/hw/ppc/ppc405_uc.c
index 381720aced..3e191ae4af 100644
--- a/hw/ppc/ppc405_uc.c
+++ b/hw/ppc/ppc405_uc.c
@@ -1155,351 +1155,6 @@ static void ppc4xx_gpt_init(hwaddr base, qemu_irq
irqs[5])
qemu_register_reset(ppc4xx_gpt_reset, gpt);
}
-/*/
-/* PowerPC 405CR */
-enum {
-PPC405CR_CPC0_PLLMR = 0x0B0,
-PPC405CR_CPC0_CR0= 0x0B1,
-PPC405CR_CPC0_CR1= 0x0B2,
-PPC405CR_CPC0_PSR= 0x0B4,
-PPC405CR_CPC0_JTAGID = 0x0B5,
-PPC405CR_CPC0_ER = 0x0B9,
-PPC405CR_CPC0_FR = 0x0BA,
-PPC405CR_CPC0_SR = 0x0BB,
-};
-
-enum {
-PPC405CR_CPU_CLK = 0,
-PPC405CR_TMR_CLK = 1,
-PPC405CR_PLB_CLK = 2,
-PPC405CR_SDRAM_CLK = 3,
-PPC405CR_OPB_CLK = 4,
-PPC405CR_EXT_CLK = 5,
-PPC405CR_UART_CLK = 6,
-PPC405CR_CLK_NB= 7,
-};
-
-typedef struct ppc405cr_cpc_t ppc405cr_cpc_t;
-struct ppc405cr_cpc_t {
-clk_setup_t clk_setup[PPC405CR_CLK_NB];
-uint32_t sysclk;
-uint32_t psr;
-uint32_t cr0;
-uint32_t cr1;
-uint32_t jtagid;
-uint32_t pllmr;
-uint32_t er;
-uint32_t fr;
-};
-
-static void ppc405cr_clk_setup (ppc405cr_cpc_t *cpc)
-{
-uint64_t VCO_out, PLL_out;
-uint32_t CPU_clk, TMR_clk, SDRAM_clk, PLB_clk, OPB_clk, EXT_clk, UART_clk;
-int M, D0, D1, D2;
-
-D0 = ((cpc->pllmr >> 26) & 0x3) + 1; /* CBDV */
-if (cpc->pllmr & 0x8000) {
-D1 = (((cpc->pllmr >> 20) - 1) & 0xF) + 1; /* FBDV */
-D2 = 8 - ((cpc->pllmr >> 16) & 0x7); /* FWDVA */
-M = D0 * D1 * D2;
-VCO_out = (uint64_t)cpc->sysclk * M;
-if (VCO_out < 4 || VCO_out > 8) {
-/* PLL cannot lock */
-cpc->pllmr &= ~0x8000;
-goto bypass_pll;
-}
-PLL_out = VCO_out / D2;
-} else {
-/* Bypass PLL */
-bypass_pll:
-M = D0;
-PLL_out = (uint64_t)cpc->sysclk * M;
-}
-CPU_clk = PLL_out;
-if (cpc->cr1 & 0x0080)
-TMR_clk = cpc->sysclk; /* Should have a separate clock */
-else
-TMR_clk = CPU_clk;
-PLB_clk = CPU_clk / D0;
-SDRAM_clk = PLB_clk;
-D0 = ((cpc->pllmr >> 10) & 0x3) + 1;
-OPB_clk = PLB_clk / D0;
-D0 = ((cpc->pllmr >> 24) & 0x3) + 2;
-EXT_clk = PLB_clk / D0;
-D0 = ((cpc->cr0 >> 1) & 0x1F) + 1;
-UART_clk = CPU_clk / D0;
-/* Setup CPU clocks */
-clk_setup(&cpc->clk_setup[PPC405CR_CPU_CLK], CPU_clk);
-/* Setup time-base clock */
-clk_setup(&cpc->clk_setup[PPC405CR_TMR_CLK], TMR_clk);
-/* Setup PLB clock */
-clk_setup(&cpc->clk_setup[PPC405CR_PLB_CLK], PLB_clk);
-/* Setup SDRAM clock */
-clk_setup(&cpc->clk_setup[PPC405CR_SDRAM_CLK], SDRAM_clk);
-/* Setup OPB clock */
-clk_setup(&cpc->clk_setup[PPC405CR_OPB_CLK], OPB_clk);
-/* Setup external clock */
-clk_setup(&cpc->clk_setup[PPC405CR_EXT_CLK], EXT_clk);
-/* Setup UART clock */
-clk_setup(&cpc->clk_setup[PPC405CR_UART_CLK], UART_clk);
-}
-
-static uint32_t dcr_read_crcpc (void *opaque, int dcrn)
-{
-ppc405cr_cpc_t *cpc;
-uint32_t ret;
-
-cpc = opaque;
-switch (dcrn) {
-case PPC405CR_CPC0_PLLMR:
-ret = cpc->pllmr;
-break;
-case PPC405CR_CPC0_CR0:
-ret = cpc->cr0;
-break;
-case PPC405CR_CPC0_CR1:
-ret = cpc->cr1;
-break;
-case PPC405CR_CPC0_PSR:
-ret = cpc->psr;
-break;
-case PPC405CR_CPC0_JTAGID:
-ret = cpc->jtagid;
-break;
-case PPC405CR_CPC0_ER:
-ret = cpc->er;
-break;
-case PPC405CR_CPC0_FR:
-ret = cpc->fr;
-break;
-case PPC405CR_CPC0_SR:
-
[PULL 06/13] Revert "sam460ex: Remove FDT_PPC dependency from KConfig"
From: BALATON Zoltan This reverts commit 038da2adf that was mistakenly added, this dependency is still needed to get libfdt dependencies even if fdt.o is not needed by sam460ex. Signed-off-by: BALATON Zoltan Message-Id: <15a9fa72eed4f02bdbeaef206803d5e22260e2de.1610143658.git.bala...@eik.bme.hu> Reviewed-by: Peter Maydell Signed-off-by: David Gibson --- hw/ppc/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/ppc/Kconfig b/hw/ppc/Kconfig index 7e267d94a1..d2329edbab 100644 --- a/hw/ppc/Kconfig +++ b/hw/ppc/Kconfig @@ -64,6 +64,7 @@ config SAM460EX select SMBUS_EEPROM select USB_EHCI_SYSBUS select USB_OHCI +select FDT_PPC config PREP bool -- 2.29.2
[PULL 12/13] spapr_rtas.c: fix identation of rtas_ibm_suspend_me() args
From: Daniel Henrique Barboza
Signed-off-by: Daniel Henrique Barboza
Message-Id: <20210114180628.1675603-5-danielhb...@gmail.com>
Signed-off-by: David Gibson
---
hw/ppc/spapr_rtas.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c
index 513c7a8435..8a79f9c628 100644
--- a/hw/ppc/spapr_rtas.c
+++ b/hw/ppc/spapr_rtas.c
@@ -219,9 +219,9 @@ static void rtas_stop_self(PowerPCCPU *cpu,
SpaprMachineState *spapr,
}
static void rtas_ibm_suspend_me(PowerPCCPU *cpu, SpaprMachineState *spapr,
- uint32_t token, uint32_t nargs,
- target_ulong args,
- uint32_t nret, target_ulong rets)
+uint32_t token, uint32_t nargs,
+target_ulong args,
+uint32_t nret, target_ulong rets)
{
CPUState *cs;
--
2.29.2
[PULL 03/13] hw/intc/ppc-uic: Make default dcr-base 0xc0, not 0x30
From: Peter Maydell
In commit 34d0831f38fd8 the ppc-uic device was added, with a dcr-base
property. The intention was that the default value of dcr-base should be
the one that most of our boards need, so that in the common case they
don't need to specify a property value.
All QEMU boards with a UIC use a dcr-base of 0xc0, with the exception of
sam460ex which has four UICs and so puts them at 0xc0, 0xd0, 0xe0, 0xf0.
So 0xc0 is the obvious right choice for the default dcr-base.
The board code conversions in commits 0270d74ef88623505 (bamboo) and
c5ac9dc64fa552a6 (virtex_ml507) assumed that default was 0xc0. Unfortunately
the actual default in 34d0831f38fd8 was 0x30, by mistake, so the
bamboo and virtex_ml507 boards were broken as they were converted
away from ppcuic_init() (which always specifies the dcr_base property
value explicitly).
Set the default dcr-base to 0xc0 as was intended, fixing bamboo and
virtex_ml507.
Fixes: 34d0831f38fd8
Reported-by: Nathan Chancellor
Suggested-by: BALATON Zoltan
Signed-off-by: Peter Maydell
Message-Id: <20210111213007.7381-1-peter.mayd...@linaro.org>
Signed-off-by: David Gibson
---
hw/intc/ppc-uic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/intc/ppc-uic.c b/hw/intc/ppc-uic.c
index b21951eea8..7171de7b35 100644
--- a/hw/intc/ppc-uic.c
+++ b/hw/intc/ppc-uic.c
@@ -274,7 +274,7 @@ static void ppc_uic_realize(DeviceState *dev, Error **errp)
static Property ppc_uic_properties[] = {
DEFINE_PROP_LINK("cpu", PPCUIC, cpu, TYPE_CPU, CPUState *),
-DEFINE_PROP_UINT32("dcr-base", PPCUIC, dcr_base, 0x30),
+DEFINE_PROP_UINT32("dcr-base", PPCUIC, dcr_base, 0xc0),
DEFINE_PROP_BOOL("use-vectors", PPCUIC, use_vectors, true),
DEFINE_PROP_END_OF_LIST()
};
--
2.29.2
[PULL 04/13] hw/ppc/ppc405_uc: Drop use of ppcuic_init()
From: Peter Maydell
Switch the ppc405_uc boards to directly creating and configuring the
UIC, rather than doing it via the old ppcuic_init() helper function.
We retain the API feature of ppc405ep_init() where it passes back
something allowing the callers to wire up devices to the UIC if
they need to, even though neither of the callsites currently makes
use of this ability -- instead of passing back the qemu_irq array
we pass back the UIC DeviceState.
This fixes a trivial Coverity-detected memory leak where
we were leaking the array of IRQs returned by ppcuic_init().
Fixes: Coverity CID 1421922
Signed-off-by: Peter Maydell
Message-Id: <20210108171212.16500-4-peter.mayd...@linaro.org>
Signed-off-by: David Gibson
---
hw/ppc/ppc405.h| 2 +-
hw/ppc/ppc405_boards.c | 8 ++---
hw/ppc/ppc405_uc.c | 70 +-
3 files changed, 47 insertions(+), 33 deletions(-)
diff --git a/hw/ppc/ppc405.h b/hw/ppc/ppc405.h
index e6c702f7e0..c58f739886 100644
--- a/hw/ppc/ppc405.h
+++ b/hw/ppc/ppc405.h
@@ -66,7 +66,7 @@ CPUPPCState *ppc405ep_init(MemoryRegion *address_space_mem,
MemoryRegion ram_memories[2],
hwaddr ram_bases[2],
hwaddr ram_sizes[2],
-uint32_t sysclk, qemu_irq **picp,
+uint32_t sysclk, DeviceState **uicdev,
int do_init);
#endif /* PPC405_H */
diff --git a/hw/ppc/ppc405_boards.c b/hw/ppc/ppc405_boards.c
index b7249f21cf..8f77887fb1 100644
--- a/hw/ppc/ppc405_boards.c
+++ b/hw/ppc/ppc405_boards.c
@@ -151,7 +151,6 @@ static void ref405ep_init(MachineState *machine)
CPUPPCState *env;
DeviceState *dev;
SysBusDevice *s;
-qemu_irq *pic;
MemoryRegion *bios;
MemoryRegion *sram = g_new(MemoryRegion, 1);
ram_addr_t bdloc;
@@ -167,6 +166,7 @@ static void ref405ep_init(MachineState *machine)
int len;
DriveInfo *dinfo;
MemoryRegion *sysmem = get_system_memory();
+DeviceState *uicdev;
if (machine->ram_size != mc->default_ram_size) {
char *sz = size_to_str(mc->default_ram_size);
@@ -184,7 +184,7 @@ static void ref405ep_init(MachineState *machine)
ram_bases[1] = 0x;
ram_sizes[1] = 0x;
env = ppc405ep_init(sysmem, ram_memories, ram_bases, ram_sizes,
-, &pic, kernel_filename == NULL ? 0 : 1);
+, &uicdev, kernel_filename == NULL ? 0 : 1);
/* allocate SRAM */
sram_size = 512 * KiB;
memory_region_init_ram(sram, NULL, "ef405ep.sram", sram_size,
@@ -429,7 +429,6 @@ static void taihu_405ep_init(MachineState *machine)
const char *kernel_filename = machine->kernel_filename;
const char *initrd_filename = machine->initrd_filename;
char *filename;
-qemu_irq *pic;
MemoryRegion *sysmem = get_system_memory();
MemoryRegion *bios;
MemoryRegion *ram_memories = g_new(MemoryRegion, 2);
@@ -440,6 +439,7 @@ static void taihu_405ep_init(MachineState *machine)
int linux_boot;
int fl_idx;
DriveInfo *dinfo;
+DeviceState *uicdev;
if (machine->ram_size != mc->default_ram_size) {
char *sz = size_to_str(mc->default_ram_size);
@@ -459,7 +459,7 @@ static void taihu_405ep_init(MachineState *machine)
"taihu_405ep.ram-1", machine->ram, ram_bases[1],
ram_sizes[1]);
ppc405ep_init(sysmem, ram_memories, ram_bases, ram_sizes,
- , &pic, kernel_filename == NULL ? 0 : 1);
+ , &uicdev, kernel_filename == NULL ? 0 : 1);
/* allocate and load BIOS */
fl_idx = 0;
#if defined(USE_FLASH_BIOS)
diff --git a/hw/ppc/ppc405_uc.c b/hw/ppc/ppc405_uc.c
index 3e191ae4af..fe047074a1 100644
--- a/hw/ppc/ppc405_uc.c
+++ b/hw/ppc/ppc405_uc.c
@@ -36,6 +36,9 @@
#include "sysemu/sysemu.h"
#include "qemu/log.h"
#include "exec/address-spaces.h"
+#include "hw/intc/ppc-uic.h"
+#include "hw/qdev-properties.h"
+#include "qapi/error.h"
//#define DEBUG_OPBA
//#define DEBUG_SDRAM
@@ -1446,14 +1449,15 @@ CPUPPCState *ppc405ep_init(MemoryRegion
*address_space_mem,
MemoryRegion ram_memories[2],
hwaddr ram_bases[2],
hwaddr ram_sizes[2],
-uint32_t sysclk, qemu_irq **picp,
+uint32_t sysclk, DeviceState **uicdevp,
int do_init)
{
clk_setup_t clk_setup[PPC405EP_CLK_NB], tlb_clk_setup;
qemu_irq dma_irqs[4], gpt_irqs[5], mal_irqs[4];
PowerPCCPU *cpu;
CPUPPCState *env;
-qemu_irq *pic, *irqs;
+DeviceState *uicdev;
+SysBusDevice *uicsbd;
memset(clk_setup, 0, sizeof(clk_setup));
/* init CPUs */
@@ -1474,59 +1478,69 @@ CPUPPCState *ppc405ep_init(MemoryRegion
*address_space_mem,
/* Initialize timers */
ppc_booke_timers_init(cpu, sysclk, 0);
[PULL 01/13] hw/ppc/sam460ex: Drop use of ppcuic_init()
From: Peter Maydell
Switch the sam460ex board to directly creating and configuring the
UIC, rather than doing it via the old ppcuic_init() helper function.
Signed-off-by: Peter Maydell
Message-Id: <20210108171212.16500-2-peter.mayd...@linaro.org>
Signed-off-by: David Gibson
---
hw/ppc/sam460ex.c | 69 ---
1 file changed, 53 insertions(+), 16 deletions(-)
diff --git a/hw/ppc/sam460ex.c b/hw/ppc/sam460ex.c
index 14e6583eb0..45721ad6c7 100644
--- a/hw/ppc/sam460ex.c
+++ b/hw/ppc/sam460ex.c
@@ -39,6 +39,7 @@
#include "hw/usb/hcd-ehci.h"
#include "hw/ppc/fdt.h"
#include "hw/qdev-properties.h"
+#include "hw/intc/ppc-uic.h"
#include
@@ -281,7 +282,9 @@ static void sam460ex_init(MachineState *machine)
hwaddr ram_bases[SDRAM_NR_BANKS] = {0};
hwaddr ram_sizes[SDRAM_NR_BANKS] = {0};
MemoryRegion *l2cache_ram = g_new(MemoryRegion, 1);
-qemu_irq *irqs, *uic[4];
+DeviceState *uic[4];
+qemu_irq mal_irqs[4];
+int i;
PCIBus *pci_bus;
PowerPCCPU *cpu;
CPUPPCState *env;
@@ -312,13 +315,38 @@ static void sam460ex_init(MachineState *machine)
ppc4xx_plb_init(env);
/* interrupt controllers */
-irqs = g_new0(qemu_irq, PPCUIC_OUTPUT_NB);
-irqs[PPCUIC_OUTPUT_INT] = ((qemu_irq *)env->irq_inputs)[PPC40x_INPUT_INT];
-irqs[PPCUIC_OUTPUT_CINT] = ((qemu_irq
*)env->irq_inputs)[PPC40x_INPUT_CINT];
-uic[0] = ppcuic_init(env, irqs, 0xc0, 0, 1);
-uic[1] = ppcuic_init(env, &uic[0][30], 0xd0, 0, 1);
-uic[2] = ppcuic_init(env, &uic[0][10], 0xe0, 0, 1);
-uic[3] = ppcuic_init(env, &uic[0][16], 0xf0, 0, 1);
+for (i = 0; i < ARRAY_SIZE(uic); i++) {
+SysBusDevice *sbd;
+/*
+ * UICs 1, 2 and 3 are cascaded through UIC 0.
+ * input_ints[n] is the interrupt number on UIC 0 which
+ * the INT output of UIC n is connected to. The CINT output
+ * of UIC n connects to input_ints[n] + 1.
+ * The entry in input_ints[] for UIC 0 is ignored, because UIC 0's
+ * INT and CINT outputs are connected to the CPU.
+ */
+const int input_ints[] = { -1, 30, 10, 16 };
+
+uic[i] = qdev_new(TYPE_PPC_UIC);
+sbd = SYS_BUS_DEVICE(uic[i]);
+
+qdev_prop_set_uint32(uic[i], "dcr-base", 0xc0 + i * 0x10);
+object_property_set_link(OBJECT(uic[i]), "cpu", OBJECT(cpu),
+ &error_fatal);
+sysbus_realize_and_unref(sbd, &error_fatal);
+
+if (i == 0) {
+sysbus_connect_irq(sbd, PPCUIC_OUTPUT_INT,
+ ((qemu_irq
*)env->irq_inputs)[PPC40x_INPUT_INT]);
+sysbus_connect_irq(sbd, PPCUIC_OUTPUT_CINT,
+ ((qemu_irq
*)env->irq_inputs)[PPC40x_INPUT_CINT]);
+} else {
+sysbus_connect_irq(sbd, PPCUIC_OUTPUT_INT,
+ qdev_get_gpio_in(uic[0], input_ints[i]));
+sysbus_connect_irq(sbd, PPCUIC_OUTPUT_CINT,
+ qdev_get_gpio_in(uic[0], input_ints[i] + 1));
+}
+}
/* SDRAM controller */
/* put all RAM on first bank because board has one slot
@@ -331,7 +359,8 @@ static void sam460ex_init(MachineState *machine)
ram_bases, ram_sizes, 1);
/* IIC controllers and devices */
-dev = sysbus_create_simple(TYPE_PPC4xx_I2C, 0x4ef600700, uic[0][2]);
+dev = sysbus_create_simple(TYPE_PPC4xx_I2C, 0x4ef600700,
+ qdev_get_gpio_in(uic[0], 2));
i2c = PPC4xx_I2C(dev)->bus;
/* SPD EEPROM on RAM module */
spd_data = spd_data_generate(ram_sizes[0] < 128 * MiB ? DDR : DDR2,
@@ -341,7 +370,8 @@ static void sam460ex_init(MachineState *machine)
/* RTC */
i2c_slave_create_simple(i2c, "m41t80", 0x68);
-dev = sysbus_create_simple(TYPE_PPC4xx_I2C, 0x4ef600800, uic[0][3]);
+dev = sysbus_create_simple(TYPE_PPC4xx_I2C, 0x4ef600800,
+ qdev_get_gpio_in(uic[0], 3));
/* External bus controller */
ppc405_ebc_init(env);
@@ -356,7 +386,10 @@ static void sam460ex_init(MachineState *machine)
ppc4xx_sdr_init(env);
/* MAL */
-ppc4xx_mal_init(env, 4, 16, &uic[2][3]);
+for (i = 0; i < ARRAY_SIZE(mal_irqs); i++) {
+mal_irqs[0] = qdev_get_gpio_in(uic[2], 3 + i);
+}
+ppc4xx_mal_init(env, 4, 16, mal_irqs);
/* DMA */
ppc4xx_dma_init(env, 0x200);
@@ -369,21 +402,23 @@ static void sam460ex_init(MachineState *machine)
memory_region_add_subregion(address_space_mem, 0x4LL, l2cache_ram);
/* USB */
-sysbus_create_simple(TYPE_PPC4xx_EHCI, 0x4bffd0400, uic[2][29]);
+sysbus_create_simple(TYPE_PPC4xx_EHCI, 0x4bffd0400,
+ qdev_get_gpio_in(uic[2], 29));
dev = qdev_new("sysbus-ohci");
qdev_prop_set_string(dev, "masterbus", "usb-bus.0");
qdev_prop_set_uint32(dev, "num-ports", 6);
sbdev = SYS_BUS_DEVICE(dev);
sysbus_rea
Re: [RFC PATCH V2 00/11] hw/block/nvme: support multi-path for ctrl/ns
On Jan 19 12:21, Minwoo Im wrote: > On 21-01-18 22:14:45, Klaus Jensen wrote: > > On Jan 17 23:53, Minwoo Im wrote: > > > Hello, > > > > > > This patch series introduces NVMe subsystem device to support multi-path > > > I/O in NVMe device model. Two use-cases are supported along with this > > > patch: Multi-controller, Namespace Sharing. > > > > > > V1 RFC has been discussed with Klaus and Keith, I really appreciate them > > > for this patch series to have proper direction [1]. > > > > > > This patch series contains few start-up refactoring pathces from the > > > first to fifth patches to make nvme-ns device not to rely on the nvme > > > controller always. Because nvme-ns shall be able to be mapped to the > > > subsystem level, not a single controller level so that it should provide > > > generic initialization code: nvme_ns_setup() with NvmeCtrl. To do that, > > > the first five patches are to remove the NvmeCtrl * instance argument > > > from the nvme_ns_setup(). I'd be happy if they are picked! > > > > > > For controller and namespace devices, 'subsys' property has been > > > introduced to map them to a subsystem. If multi-controller needed, we > > > can specify 'subsys' to controllers the same. > > > > > > For namespace deivice, if 'subsys' is not given just like it was, it > > > will have to be provided with 'bus' parameter to specify a nvme > > > controller device to attach, it means, they are mutual-exlusive. To > > > share a namespace between or among controllers, then nvme-ns should have > > > 'subsys' property to a single nvme subsystem instance. To make a > > > namespace private one, then we need to specify 'bus' property rather > > > than the 'subsys'. > > > > > > Of course, this series does not require any updates for the run command > > > for the previos users. > > > > > > Plase refer the following example with nvme-cli output: > > > > > > QEMU Run: > > > -device nvme-subsys,id=subsys0 \ > > > -device nvme,serial=foo,id=nvme0,subsys=subsys0 \ > > > -device nvme,serial=bar,id=nvme1,subsys=subsys0 \ > > > -device nvme,serial=baz,id=nvme2,subsys=subsys0 \ > > > -device nvme-ns,id=ns1,drive=drv10,nsid=1,subsys=subsys0 \ > > > -device nvme-ns,id=ns2,drive=drv11,nsid=2,bus=nvme2 \ > > > \ > > > -device nvme,serial=qux,id=nvme3 \ > > > -device nvme-ns,id=ns3,drive=drv12,nsid=3,bus=nvme3 > > > > > > nvme-cli: > > > root@vm:~/work# nvme list -v > > > NVM Express Subsystems > > > > > > SubsystemSubsystem-NQN > > > Controllers > > > > > > > > > > > > nvme-subsys1 nqn.2019-08.org.qemu:subsys0 > > > nvme0, nvme1, nvme2 > > > nvme-subsys3 nqn.2019-08.org.qemu:qux > > > nvme3 > > > > > > NVM Express Controllers > > > > > > Device SN MN > > > FR TxPort AddressSubsystemNamespaces > > > > > > -- -- > > > nvme0foo QEMU NVMe Ctrl > > > 1.0 pcie :00:06.0 nvme-subsys1 nvme1n1 > > > nvme1bar QEMU NVMe Ctrl > > > 1.0 pcie :00:07.0 nvme-subsys1 nvme1n1 > > > nvme2baz QEMU NVMe Ctrl > > > 1.0 pcie :00:08.0 nvme-subsys1 nvme1n1, nvme1n2 > > > nvme3qux QEMU NVMe Ctrl > > > 1.0 pcie :00:09.0 nvme-subsys3 > > > > > > NVM Express Namespaces > > > > > > Device NSID Usage Format > > > Controllers > > > -- > > > > > > nvme1n1 1134.22 MB / 134.22 MB512 B + 0 B > > > nvme0, nvme1, nvme2 > > > nvme1n2 2268.44 MB / 268.44 MB512 B + 0 B nvme2 > > > nvme3n1 3268.44 MB / 268.44 MB512 B + 0 B nvme3 > > > > > > Summary: > > > - Refactored nvme-ns device not to rely on controller during the > > > setup. [1/11 - 5/11] > > > - Introduced a nvme-subsys device model. [6/11] > > > - Create subsystem NQN based on subsystem. [7/11] > > > - Introduced multi-controller model. [8/11 - 9/11] > > > - Updated namespace sharing scheme to be based on nvme-subsys > > > hierarchy. [10/11 - 11/11] > > > > > > Since RFC V1: > > > - Updated namespace sharing scheme to be based on nvme-subsys > > > hierarchy. > > > > > > > Great stuff Minwoo. Thanks! >
Re: [PATCH] tests/acceptance: Test PMON with Loongson-3A1000 CPU
On 1/18/21 5:54 PM, Alex Bennée wrote:
> Philippe Mathieu-Daudé writes:
>> On 1/12/21 3:07 AM, Jiaxun Yang wrote:
>>> Test booting of PMON bootloader on loongson3-virt platform.
>>>
>>> $ (venv) AVOCADO_ALLOW_UNTRUSTED_CODE=1 \
>>> avocado --show=app,console \
>>> run -t machine:loongson3-virt tests/acceptance
>>> Fetching asset from
>>> tests/acceptance/machine_mips_loongson3v.py:MipsLoongson3v.test_pmon_serial_console
>>> JOB ID : 8e202b3727847c9104d0d3d6546ed225d35f6706
>>> JOB LOG:
>>> /home/flygoat/avocado/job-results/job-2021-01-12T10.02-8e202b3/job.log
>> ...
>>> console: This software may be redistributed under the BSD copyright.
>>> console: Copyright 2000-2002, Opsycon AB, Sweden.
>>> console: Copyright 2005, ICT CAS.
>>> console: CPU GODSON3 BogoMIPS: 1327
>>> PASS (3.89 s)
>>> RESULTS: PASS 1 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 |
>>> CANCEL 0
>>> JOB TIME : 4.38 s
>>>
>>> Signed-off-by: Jiaxun Yang
>>> ---
>>> MAINTAINERS | 1 +
>>> tests/acceptance/machine_mips_loongson3v.py | 39 +
>>> 2 files changed, 40 insertions(+)
>>> create mode 100644 tests/acceptance/machine_mips_loongson3v.py
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 4be087b88e..f38882f997 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -1164,6 +1164,7 @@ F: hw/intc/loongson_liointc.c
>>> F: hw/mips/loongson3_bootp.c
>>> F: hw/mips/loongson3_bootp.h
>>> F: hw/mips/loongson3_virt.c
>>> +F: tests/acceptance/machine_mips_loongson3v.py
>>>
>>> Boston
>>> M: Paul Burton
>>> diff --git a/tests/acceptance/machine_mips_loongson3v.py
>>> b/tests/acceptance/machine_mips_loongson3v.py
>>> new file mode 100644
>>> index 00..17a85de69f
>>> --- /dev/null
>>> +++ b/tests/acceptance/machine_mips_loongson3v.py
>>> @@ -0,0 +1,39 @@
>>> +# Functional tests for the Generic Loongson-3 Platform.
>>> +#
>>> +# Copyright (c) 2020 Philippe Mathieu-Daudé
>>
>> 2021 Jiaxun Yang ? :D
Jiaxun, if you agree I can update that line and queue your patch.
>>
>>> +#
>>> +# This work is licensed under the terms of the GNU GPL, version 2 or later.
>>> +# See the COPYING file in the top-level directory.
>>> +#
>>> +# SPDX-License-Identifier: GPL-2.0-or-later
>>> +
>>> +import os
>>> +import time
>>> +
>>> +from avocado import skipUnless
>>> +from avocado_qemu import Test
>>> +from avocado_qemu import wait_for_console_pattern
>>> +
>>> +class MipsLoongson3v(Test):
>>> +@skipUnless(os.getenv('AVOCADO_ALLOW_UNTRUSTED_CODE'), 'untrusted
>>> code')
>>
>> The source code is published [1], you provided reproducible
>> workflow [2] and a tag [3] with a public build artifacts [4],
>> so my understanding is this is "trustable" binary.
>>
>> Alex, would it be OK to add this test without the UNTRUSTED tag
>> (amending the links in the commit description)?
>
> It's a subjective call. Having open source code is a minimum step to
> being "trusted" but really the trust is in the community that hosts the
> code. The upstream distros (e.g. Debian/Fedora) are trusted because
> people install their software on their desktops and basically give the
> software publisher root on their machines. There has to be a level of
> trust that the distros won't abuse that to steal information from their
> users.
>
> I personally have no idea about the loongson community because it's not
> one I interact with so I have no idea what sort of place it is. Is it a
> code dump for semi-proprietary non-upstreamed kernels or is it a place
> that has a good development culture with a sane security process that is
> responsive to problems and moderately conservative with what they merge?
>
> If you would trust your keys to a machine running this communities
> software then by all means treated it as a trusted source.
Subjective call understood :)
Thanks for your clear explanation,
Phil.
[RFC PATCH] tests/docker: Allow passing --network option when building images
When using the Docker engine, build fails because the container is unable to resolve hostnames: $ make docker-image-debian-s390x-cross NETWORK=host ENGINE=docker BUILD debian10 #6 9.679 Err:1 http://deb.debian.org/debian buster InRelease #6 9.679 Temporary failure resolving 'deb.debian.org' #6 16.69 Err:2 http://security.debian.org/debian-security buster/updates InRelease #6 16.69 Temporary failure resolving 'security.debian.org' #6 22.69 Err:3 http://deb.debian.org/debian buster-updates InRelease #6 22.69 Temporary failure resolving 'deb.debian.org' #6 22.74 W: Failed to fetch http://deb.debian.org/debian/dists/buster/InRelease Temporary failure resolving 'deb.debian.org' #6 22.74 W: Failed to fetch http://security.debian.org/debian-security/dists/buster/updates/InRelease Temporary failure resolving 'security.debian.org' #6 22.74 W: Failed to fetch http://deb.debian.org/debian/dists/buster-updates/InRelease Temporary failure resolving 'deb.debian.org' #6 22.74 W: Some index files failed to download. They have been ignored, or old ones used instead. Traceback (most recent call last): File "./tests/docker/docker.py", line 709, in sys.exit(main()) File "./tests/docker/docker.py", line 705, in main return args.cmdobj.run(args, argv) File "./tests/docker/docker.py", line 498, in run dkr.build_image(tag, docker_dir, dockerfile, File "./tests/docker/docker.py", line 353, in build_image self._do_check(build_args, File "./tests/docker/docker.py", line 244, in _do_check return subprocess.check_call(self._command + cmd, **kwargs) File "/usr/lib64/python3.8/subprocess.py", line 364, in check_call raise CalledProcessError(retcode, cmd) make: *** [tests/docker/Makefile.include:61: docker-image-debian10] Error 1 Fix by passing the NETWORK variable with --network= argument. Signed-off-by: Philippe Mathieu-Daudé --- tests/docker/Makefile.include | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include index bdc53ddfcf9..b65fd684011 100644 --- a/tests/docker/Makefile.include +++ b/tests/docker/Makefile.include @@ -63,6 +63,7 @@ docker-image-%: $(DOCKER_FILES_DIR)/%.docker $(if $V,,--quiet) \ $(if $(NOCACHE),--no-cache, \ $(if $(DOCKER_REGISTRY),--registry $(DOCKER_REGISTRY))) \ + $(if $(NETWORK),$(if $(subst $(NETWORK),,1),--network=$(NETWORK))) \ $(if $(NOUSER),,--add-current-user) \ $(if $(EXTRA_FILES),--extra-files $(EXTRA_FILES))\ $(if $(EXECUTABLE),--include-executable=$(EXECUTABLE)),\ -- 2.26.2
[PATCH] tests/docker: Fix typo in help message
To have the variable properly passed, we need to set it, ie. NOUSER=1. Fix the message displayed by 'make docker'. Signed-off-by: Philippe Mathieu-Daudé --- tests/docker/Makefile.include | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include index 0779dab5b96..bdc53ddfcf9 100644 --- a/tests/docker/Makefile.include +++ b/tests/docker/Makefile.include @@ -209,7 +209,7 @@ endif @echo ' before running the command.' @echo 'NETWORK=1Enable virtual network interface with default backend.' @echo 'NETWORK=$$BACKEND Enable virtual network interface with $$BACKEND.' - @echo 'NOUSER Define to disable adding current user to containers passwd.' + @echo 'NOUSER=1 Define to disable adding current user to containers passwd.' @echo 'NOCACHE=1Ignore cache when build images.' @echo 'EXECUTABLE=Include executable in image.' @echo 'EXTRA_FILES=" [... ]"' -- 2.26.2
Re: Re: [PATCH v4 0/3] support NVMe smart critial warning injection
On Jan 19 10:05, zhenwei pi wrote:
> On 1/18/21 5:34 PM, Klaus Jensen wrote:
> > On Jan 15 11:26, zhenwei pi wrote:
> > > v3 -> v4:
> > > - Drop "Fix overwritten bar.cap". (Already fixed)
> > >
> > > - Avoid to enqueue the duplicate event.
> > >
> > > - Several minor changes for coding style & function/variable name.
> > >
> > > v2 -> v3:
> > > - Introduce "Persistent Memory Region has become read-only or
> > >unreliable"
> > >
> > > - Fix overwritten bar.cap
> > >
> > > - Check smart critical warning value from QOM.
> > >
> > > - Trigger asynchronous event during smart warning injection.
> > >
> > > v1 -> v2:
> > > - Suggested by Philippe & Klaus, set/get smart_critical_warning by QMP.
> > >
> > > v1:
> > > - Add smart_critical_warning for nvme device which can be set by QEMU
> > >command line to emulate hardware error.
> > >
> > > Zhenwei Pi (3):
> > >block/nvme: introduce bit 5 for critical warning
> > >hw/block/nvme: add smart_critical_warning property
> > >hw/blocl/nvme: trigger async event during injecting smart warning
> > >
> > > hw/block/nvme.c | 91 +++-
> > > hw/block/nvme.h | 1 +
> > > include/block/nvme.h | 3 ++
> > > 3 files changed, 86 insertions(+), 9 deletions(-)
> > >
> >
> > This looks pretty good to me.
> >
> > I think maybe we want to handle the duplicate event stuff more generally
> > from the AER/AEN code, but this does the job.
> >
> > Tested-by: Klaus Jensen
> > Reviewed-by: Klaus Jensen
> >
>
> What's the next step I should take? Should I push a new version to implement
> this purpose? From my understanding, before inserting a new event to
> aer_queue, I can parse all the pending aer to find the same event.
>
> nvme_enqueue_event()
> {
> ...
>
> QTAILQ_FOREACH_SAFE(event, &n->aer_queue, entry, next) {
> if ((event->result.event_type == event_type)
> && (event->result.event_info == event_info)
> && (event->result.log_page == log_page))
> return;
> }
>
> QTAILQ_INSERT_TAIL(&n->aer_queue, event, entry);
>
>
>
> n->aer_queued++;
> ...
> }
>
No, I'll pick up your series as is, I'll pick it up for nvme-next later
today if noone complains! :)
signature.asc
Description: PGP signature
[PATCH] tests/docker: Fix _get_so_libs() for docker-binfmt-image
Fix a variable rename mistake from commit 5e33f7fead5:
Traceback (most recent call last):
File "./tests/docker/docker.py", line 710, in
sys.exit(main())
File "./tests/docker/docker.py", line 706, in main
return args.cmdobj.run(args, argv)
File "./tests/docker/docker.py", line 489, in run
_copy_binary_with_libs(args.include_executable,
File "./tests/docker/docker.py", line 149, in _copy_binary_with_libs
libs = _get_so_libs(src)
File "./tests/docker/docker.py", line 123, in _get_so_libs
libs.append(s.group(1))
NameError: name 's' is not defined
Fixes: 5e33f7fead5 ("tests/docker: better handle symlinked libs")
Signed-off-by: Philippe Mathieu-Daudé
---
"Tested-by" but apparently not enough... Well actually it was on
Debian, now using Fedora.
---
tests/docker/docker.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/docker/docker.py b/tests/docker/docker.py
index 884dfeb29c4..0b4f6167b3d 100755
--- a/tests/docker/docker.py
+++ b/tests/docker/docker.py
@@ -120,7 +120,7 @@ def _get_so_libs(executable):
search = ldd_re.search(line)
if search:
try:
-libs.append(s.group(1))
+libs.append(search.group(1))
except IndexError:
pass
except subprocess.CalledProcessError:
--
2.26.2
Re: [RFC PATCH v0 1/1] target/ppc: Support for H_RPT_INVALIDATE hcall
On Fri, Jan 15, 2021 at 06:30:05PM +0100, Greg Kurz wrote:
> On Fri, 15 Jan 2021 14:01:28 +0530
> Bharata B Rao wrote:
>
> > On Wed, Jan 13, 2021 at 05:22:56PM +0100, Greg Kurz wrote:
> > > Hi Bharata,
> > >
> > > On Wed, 6 Jan 2021 14:29:10 +0530
> > > Bharata B Rao wrote:
> > >
> > > > If KVM_CAP_RPT_INVALIDATE KVM capability is enabled, then
> > > >
> > > > - indicate the availability of H_RPT_INVALIDATE hcall to the guest via
> > > > ibm,hypertas-functions property.
> > > > - Enable the hcall
> > > >
> > > > Both the above are done only if the new sPAPR machine capability
> > > > cap-rpt-invalidate is set.
> > > >
> > > > Note: The KVM implementation of the hcall has been posted for upstream
> > > > review here:
> > > > https://lore.kernel.org/linuxppc-dev/20210105090557.2150104-1-bhar...@linux.ibm.com/T/#t
> > > >
> > > > Update to linux-headers/linux/kvm.h here is temporary, will be
> > > > done via header updates once the kernel change is accepted upstream.
> > > >
> > > > Signed-off-by: Bharata B Rao
> > > > ---
> > >
> > > Patch looks mostly fine. A few remarks below.
> > >
> > > > hw/ppc/spapr.c| 7 ++
> > > > hw/ppc/spapr_caps.c | 49 +++
> > > > include/hw/ppc/spapr.h| 8 +--
> > > > linux-headers/linux/kvm.h | 1 +
> > > > target/ppc/kvm.c | 12 ++
> > > > target/ppc/kvm_ppc.h | 11 +
> > > > 6 files changed, 86 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > > > index 489cefcb81..0228083800 100644
> > > > --- a/hw/ppc/spapr.c
> > > > +++ b/hw/ppc/spapr.c
> > > > @@ -890,6 +890,11 @@ static void spapr_dt_rtas(SpaprMachineState
> > > > *spapr, void *fdt)
> > > > add_str(hypertas, "hcall-copy");
> > > > add_str(hypertas, "hcall-debug");
> > > > add_str(hypertas, "hcall-vphn");
> > > > +if (kvm_enabled() &&
> > >
> > > You shouldn't check KVM here. The capability is enough to decide if we
> > > should expose "hcall-rpt-invalidate" or not. FWIW we won't even reach
> > > this code when running with anything but KVM.
> >
> > Correct, the capability itself can be only for KVM case.
> >
> > >
> > > > +(spapr_get_cap(spapr, SPAPR_CAP_RPT_INVALIDATE) ==
> > > > SPAPR_CAP_ON)) {
> > > > +add_str(hypertas, "hcall-rpt-invalidate");
> > > > +}
> > > > +
> > > > add_str(qemu_hypertas, "hcall-memop1");
> > > >
> > > > if (!kvm_enabled() || kvmppc_spapr_use_multitce()) {
> > > > @@ -2021,6 +2026,7 @@ static const VMStateDescription vmstate_spapr = {
> > > > &vmstate_spapr_cap_ccf_assist,
> > > > &vmstate_spapr_cap_fwnmi,
> > > > &vmstate_spapr_fwnmi,
> > > > +&vmstate_spapr_cap_rpt_invalidate,
> > > > NULL
> > > > }
> > > > };
> > > > @@ -4478,6 +4484,7 @@ static void spapr_machine_class_init(ObjectClass
> > > > *oc, void *data)
> > > > smc->default_caps.caps[SPAPR_CAP_LARGE_DECREMENTER] = SPAPR_CAP_ON;
> > > > smc->default_caps.caps[SPAPR_CAP_CCF_ASSIST] = SPAPR_CAP_ON;
> > > > smc->default_caps.caps[SPAPR_CAP_FWNMI] = SPAPR_CAP_ON;
> > > > +smc->default_caps.caps[SPAPR_CAP_RPT_INVALIDATE] = SPAPR_CAP_OFF;
> > >
> > > Any reason for not enabling this for the default machine type and
> > > disabling it for existing machine types only ?
> >
> > If this capability is enabled, then
> >
> > 1. First level guest (L1) can off-load the TLB invalidations to the
> > new hcall if the platform has disabled LPCR[GTSE].
> >
> > 2. Nested guest (L2) will switch to this new hcall rather than using
> > the old H_TLB_INVALIDATE hcall.
> >
> > Case 2 is optional and case 1 makes sense only if LPCR[GTSE]=off.
>
> I don't think this is relevant, as the importance of each case can change,
> e.g. nested is gaining momentum.
>
> > Hence I thought keeping it off by default and expecting the
> > user to turn it on only if required would be correct.
> >
>
> If the feature is an improvement, even for what is considered a corner
> case now, and it doesn't do harm to setups that won't use it, then it
> should be enabled IMHO.
>
> > Please note that turning this capability ON will result in the
> > new hcall being exposed to the guest. I hope this is the right
> > usage of spapr-caps?
> >
>
> That's perfectly fine and this is why we should set it to ON
> for the default machine type only.
The property can be turned ON only when the hypervisor supports
the hcall. So if it set to ON for default machine type, then
it may fail if the host doesn't have this hcall. Hence I thought
it should be OFF by default and turning ON should be left to the
user.
Regards,
Bharata.
[Bug 393569] Re: qemu cannot load multiple initramfs archives
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/393569 Title: qemu cannot load multiple initramfs archives Status in QEMU: Expired Bug description: According to Documentation/early-userspace/buffer-format.txt, an initramfs can be populated from multiple cpio archives, which seems like it could be a really useful feature when using QEMU to boot Linux kernels directly, without installing them on the disk image. Unfortunately, QEMU does not support actually loading multiple files into the initrd space (which is also where initramfs archives go). It would be really nice if it did. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/393569/+subscriptions
[Bug 1518969] Re: Instance of QEMU doesn't unplug virtio scsi disk after device_del and drive_del commands
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1518969 Title: Instance of QEMU doesn't unplug virtio scsi disk after device_del and drive_del commands Status in QEMU: Expired Bug description: device_del and drive_del commands don't cause virtio disk detaching Steps to reproduce: 1. Run instance 2. Attach virtio scsi disk 3. Reboot instance 4. Immediately after reboot detach disk with QEMU commands: device_del drive_del Expected result: Disk should be detached anyway Actual: Domain info contains attached disk even after waiting long period of time(5 min in my case). Additional info: QEMU process: root 29010 42.6 1.9 562036 61272 ?Rl 03:42 0:01 /usr/bin/qemu-system-x86_64 -name instance-0069 -S -machine pc-i440fx-trusty,accel=tcg,usb=off -m 64 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid d2418536-2547-4740-96b5-0d4f1d74b9f3 -smbios type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=13.0.0,serial=1fd8f69a-909b-4ed1-aae9-4fc9318fc622,uuid=d2418536-2547-4740-96b5-0d4f1d74b9f3,family=Virtual Machine -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-0069.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -kernel /opt/stack/data/nova/instances/d2418536-2547-4740-96b5-0d4f1d74b9f3/kernel -initrd /opt/stack/data/nova/instances/d2418536-2547-4740-96b5-0d4f1d74b9f3/ramdisk -append root=/dev/vda console=tty0 console=ttyS0 no_timer_check -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/opt/stack/data/nova/instances/d2418536-2547-4740-96b5-0d4f1d74b9f3/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/opt/stack/data/nova/instances/d2418536-2547-4740-96b5-0d4f1d74b9f3/disk.config,if=none,id=drive-ide0-1-1,readonly=on,format=raw,cache=none -device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1 -netdev tap,fd=18,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:1a:10:3d,bus=pci.0,addr=0x3 -chardev file,id=charserial0,path=/opt/stack/data/nova/instances/d2418536-2547-4740-96b5-0d4f1d74b9f3/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -vnc 127.0.0.1:1 -k en-us -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 QEMU version: qemu-system-x86_64 --version QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.19), Copyright (c) 2003-2008 Fabrice Bellard To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1518969/+subscriptions
[Bug 1377163] Re: Does not add usb-host devices as they are hotplugged
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1377163 Title: Does not add usb-host devices as they are hotplugged Status in QEMU: Expired Bug description: A commandline such as qemu-kvm -device usb-ehci,id=USBCtrl -device host- usb,bus=USBCtrl.0,hostbus=3 should automatically add all devices on the given bus (here: 3) not only initially, but also when new devices appear on that bus while Qemu runs. Currently, all devices on the bus are added initially, but new devices which are added to the (host) usb while Qemu runs have to be added manually. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1377163/+subscriptions
[Bug 1531352] Re: QEMU_LD_PREFIX not load correct library order in the PATH
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1531352 Title: QEMU_LD_PREFIX not load correct library order in the PATH Status in QEMU: Expired Bug description: run qemu with QEMU_LD_PREFIX argument will not load correct library order in the PATH. How to reproduce this bug: These command will download the library of other architectures wget https://raw.githubusercontent.com/BinaryAnalysisPlatform/qira/master/fetchlibs.sh bash fetchlibs.sh This is 32bit binary file, wget http://train.cs.nctu.edu.tw/files/magic chmod +x ./magic qemu-i386 -L /home/apple/libs/i386 /home/apple/magic This is work fine. But after you install gcc-multilib, it failed. sudo apt-get install gcc-multilib qemu-i386 -L /home/apple/libs/i386 /home/apple/magic The following is the error message /home/apple/magic: 0���: ̀Í�: D$(�$: Error 18446744073549536926 Because the order of dynamic linker search the shared library is wrong. When your system has /lib32 directory, its priority is higher than the QEMU_LD_PREFIX. If the system not loaded correspond with the dynamic linker, it will crash. Code flow: linux-user/main.c: call loader_exec linuxload.c: call load_elf_binary elfload.c: in load_elf_binary function dynamic loader will be elf_interpreter I think the problem should be here. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1531352/+subscriptions
[Bug 1381846] Re: Data sent to parallel port in guest is lost if host buffer fills up
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1381846 Title: Data sent to parallel port in guest is lost if host buffer fills up Status in QEMU: Expired Bug description: It appears that qemu will blindly write characters out to the chardev and drop them on the floor if a write fails with EAGAIN, without initiating flow control (via BUSY and ACK) back to the guest. If the host buffer is too small, or is talking to a hardware device that is too slow, data will be lost. I notice this problem when I run a DOS program with this on the qemu command line: -parallel /dev/usb/lp0 I can work around this problem by buffering via a pipe, but this looks like a general problem. Is there a way to wire up the readiness of the output chardev to the parallel port ACK and BUSY lines, and signal an ISA interrupt? I don't know the code well enough to tell. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1381846/+subscriptions
[Bug 1391942] Re: Unnecessary events option of the trace argument with UST backend
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1391942 Title: Unnecessary events option of the trace argument with UST backend Status in QEMU: Expired Bug description: When running configure with the --enable-trace-backends=ust option and compiling. The user should not have to specify a the "events" and "file" options because they are not used with that tracing framework. Right now, in order the use this option the need to specify a dummy events file. This fails: $> qemu-system-x86_64 -hda debian_wheezy_amd64_standard.qcow2 -trace -m 512 qemu-system-x86_64: -trace -m: Invalid parameter '-m' This works: $> qemu-system-x86_64 -hda debian_wheezy_amd64_standard.qcow2 -trace events=dummy-events.txt -m 512 VNC server running on `127.0.0.1:5900' I am using version: $> qemu-system-x86_64 --version QEMU emulator version 2.1.90, Copyright (c) 2003-2008 Fabrice Bellard To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1391942/+subscriptions
[Bug 1554451] Re: unable to create preallocated image with gluster network protocol
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1554451 Title: unable to create preallocated image with gluster network protocol Status in QEMU: Expired Bug description: Unable to create preallocated image with gluster protocol Version: qemu-img-0.12.1.2-2.479.el6.x86_64 Platform: RHEL 6 I have tried creating preallocated image as follows : qemu-img create -f qcow2 -o preallocation=full gluster://localhost/vol1/vm1.img 10G I see error a follows : [root@ ]# qemu-img create -f qcow2 -o preallocation=full gluster://localhost/rep3vol/vm1.img 5G Formatting 'gluster://dhcp37-61.lab.eng.blr.redhat.com/rep3vol/newvm3.img', fmt=qcow2 size=3221225472 encryption=off cluster_size=65536 preallocation='full' Unknown option 'preallocation' I could inspect the image using qemu-img info, but still its not preallocated, [root@ ]# qemu-img info newvm3.img image: newvm3.img file format: qcow2 virtual size: 3.0G (3221225472 bytes) disk size: 588K cluster_size: 65536 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1554451/+subscriptions
[Bug 1530278] Re: vhost-user: can not detach chardev which is used by vhost-user backend
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1530278 Title: vhost-user: can not detach chardev which is used by vhost-user backend Status in QEMU: Expired Bug description: I launch a VM which use vhost-user netdevice as follows.When detach the netdevice in qemu monitor, the chardevice which used by the netdevice also should be deatched.The netdevice can be detached sucessfully.But the chardevice failed when it was being detaching. Full command line : qemu-system-x86_64 \ -cpu host -boot c -hda /home/lining/ubuntu_12_04.img -snapshot -m 2048 -smp 2 \ --enable-kvm -name "client1" -vnc :1 \ -object memory-backend-file,id=mem,size=2048M,mem-path=/dev/hugepages,share=on -numa node,memdev=mem \ -chardev socket,id=chr1,path=/opt/network/ovdk/bin/vhost-user \ -netdev vhost-user,id=net12,chardev=chr1,ifname=port80, vhostforce \ -device virtio-net-pci,netdev=net12,mac=00:00:00:00:00:01,\ csum=off,gso=off,guest_tso4=off,guest_tso6=off,guest_ecn=off,guest_ufo=off,any_layout=off To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1530278/+subscriptions
[Bug 1296882] Re: add next free device option to qemu-img
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1296882 Title: add next free device option to qemu-img Status in QEMU: Expired Bug description: I'd like to propose an option to be added to qemu-img which returns the next free NBD (the device file) very similar to losetup -f. It would make life a lot easier. Followers of this enhancement request might be interested in the following workaround: http://stackoverflow.com/questions/22535222 /next-free-device-option-for-qemu-nbd/ To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1296882/+subscriptions
[Bug 1529764] Re: No video output with the official Windows XP VMWare VGA driver
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1529764 Title: No video output with the official Windows XP VMWare VGA driver Status in QEMU: Expired Bug description: Steps to reproduce: 1) Set -vga to vmware 2) Install Windows XP SP3 3) Install VGA drivers from http://packages.vmware.com/tools/releases/latest/windows/x86/VMware-tools-windows-10.0.5-3227872.iso Result: completely black screen (even after F8 -> use VGA mode). To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1529764/+subscriptions
[Bug 1269628] Re: Feature Request: Please add TCG OPAL 2 emulation support to the virtio disk emulation
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1269628 Title: Feature Request: Please add TCG OPAL 2 emulation support to the virtio disk emulation Status in QEMU: Expired Bug description: In order to allow windows guests (and soon, linux guests) which are TCG OPAL 2 aware to perform disk encryption in a native fashion with hardware acceleration, please add TCG OPAL 2 emulation to the VIRTIO driver. Encryption should occur at the host level using any cryptographic facilities available to the host, for example AES-NI, Cryptography Hardware, underlying block device cryptography support where available or any other cryptography facility that may be developed and implemented in the future. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1269628/+subscriptions
[Bug 1534683] Re: no mouse cursor / qxl / windows seven guest
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1534683 Title: no mouse cursor / qxl / windows seven guest Status in QEMU: Expired Bug description: Hello, When i'm using qxl graphic card with qemu 2.4.1 , and sdl2 client ( display ) , in a windows seven guest vm , there's no mouse cursor. I'm using last qxl driver. With windows8.1 , there is no problem, mouse cursor is present. I need this to use two monitor with a windows guest, any suggestions are welcome, Regards, To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1534683/+subscriptions
[Bug 1563152] Re: general protection fault running VirtualBox in KVM guest
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1563152 Title: general protection fault running VirtualBox in KVM guest Status in QEMU: Expired Status in qemu package in Ubuntu: Expired Bug description: I'm trying to run nested VMs using qemu-kvm on the physical host and VirtualBox on the guest host: * physical host: Ubuntu 14.04 running Linux 4.2.0, qemu-kvm 2.0.0 * guest host: Ubuntu 16.04 beta 2 running Linux 4.4.0, VirtualBox 5.0.16 When I try to start up a VirtualBox VM in the guest host, I get a general protection fault (see below for dmesg output). According to https://www.virtualbox.org/ticket/14965 this is caused by a bug in QEMU/KVM: The problem in more detail: As written above, VirtualBox tries to read the MSR 0x9B (IA32_SMM_MONITOR_CTL). This is an architectural MSR which is present if CPUID.01 / ECX bit 5 or bit 6 are set (VMX or SMX). As KVM has nested virtualization enabled and therefore pretends to support VT-x, this MSR must be accessible and reading from this MSR must not raise a #GP. KVM/QEmu does not behave like real hardware in this case. dmesg output: SUPR0GipMap: fGetGipCpu=0x3 general protection fault: [#1] SMP Modules linked in: pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack xt_tcpudp bridge stp llc iptable_filter ip_tables x_tables ppdev kvm_intel kvm irqbypass snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer i2c_piix4 snd input_leds soundcore joydev 8250_fintek mac_hid serio_raw pvpanic parport_pc parport ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear crct10dif_pclmul crc32_pclmul qxl ttm drm_kms_helper syscopyarea sysfillrect aesni_intel sysimgblt fb_sys_fops aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd psmouse floppy drm pata_acpi CPU: 0 PID: 31507 Comm: EMT Tainted: G OE 4.4.0-15-generic #31-Ubuntu Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 task: 880034c0a580 ti: 880002e0 task.ti: 880002e0 RIP: 0010:[] [] 0xc067e506 RSP: 0018:880002e03d70 EFLAGS: 00010206 RAX: 06f0 RBX: ffdb RCX: 009b RDX: RSI: 880002e03d00 RDI: 880002e03cc8 RBP: 880002e03d90 R08: 0004 R09: 06f0 R10: 49656e69 R11: 0f8bfbff R12: 0020 R13: R14: c957407c R15: c0645260 FS: 7f89b8f6b700() GS:88007fc0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f89b8d1 CR3: 35ae1000 CR4: 06f0 Stack: 880002e03db0 c0693e93 c9574010 880035aae550 880002e03e30 c060a3e7 880002e03e10 0282 Call Trace: [] ? supdrvIOCtl+0x2de7/0x3250 [vboxdrv] [] ? VBoxDrvLinuxIOCtl_5_0_16+0x150/0x250 [vboxdrv] [] ? do_vfs_ioctl+0x29f/0x490 [] ? __do_page_fault+0x1b4/0x400 [] ? SyS_ioctl+0x79/0x90 [] ? entry_SYSCALL_64_fastpath+0x16/0x71 Code: 88 e4 fc ff ff b9 3a 00 00 00 0f 32 48 c1 e2 20 89 c0 48 09 d0 48 89 05 f9 db 0e 00 0f 20 e0 b9 9b 00 00 00 48 89 05 d2 db 0e 00 <0f> 32 48 c1 e2 20 89 c0 b9 80 00 00 c0 48 09 d0 48 89 05 cb db RIP [] 0xc067e506 RSP ---[ end trace b3284b6520f49e0d ]--- To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1563152/+subscriptions
[Bug 1530035] Re: usb-host: ATI Technologies, Inc. TV Wonder acts as a different device if used
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1530035 Title: usb-host: ATI Technologies, Inc. TV Wonder acts as a different device if used Status in QEMU: Expired Bug description: Title says it all. If you try to use the "ATI Technologies, Inc. TV Wonder" USB 1.1 TV Tuner for passthrough under any OS that has drivers for the device, the usb-host driver will confuse itself and give the device a new PID number for Linux. Tested on ReactOS and Windows XP with stable QEMU package from pacman on Arch Linux. Commands used: sudo qemu-system-x86_64 -enable-kvm -hda ~/QEMU/hd/winxp.img -usb -device usb-host,hostbus=2,hostaddr=3 -vga vmware Before starting qemu-kvm, lsusb reports: [ Bus 002 Device 003: ID 0528:7561 ATI Technologies, Inc. TV Wonder ] After starting qemu-kvm, usb-host and lsusb report: [ libusb: error [_get_usbfs_fd] File doesn't exist, wait 10 ms and try again libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/003: No such file or directory The device in Bus 2, Device 3 is gone and it appears as this instead: Bus 002 Device 005: ID 0573:0400 Zoran Co. Personal Media Division (Nogatech) D-Link V100 ] This weird effect only lasts until you unplug the TV Wonder. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1530035/+subscriptions
[Bug 1557057] Re: Windows 10 guest under qemu cannot wake up from S3 using rtc wake with -no_hpet
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1557057 Title: Windows 10 guest under qemu cannot wake up from S3 using rtc wake with -no_hpet Status in QEMU: Expired Bug description: Problem : Windows 10 guest cannot wake up from S3 using rtc wake when hpet is disabled( -no_hpet) Steps to reproduce. 1. Boot Windows 10 Guest VM. 2. Create scheduled task (using Task Scheduler) to +5 minutes time from current time to run notepad and enabling "Wake the computer to run this task" option 3. Click Start->Power ->Sleep 4. Guest VM enters suspend mode( screen is black) 5. Wait 10 minutes - nothing happens 6. Press key in spicy window 7. VM resumes Expected behavior - VM should wake after 5 minutes in step 5. NOTE: problem happens only with -no_hpet option More information: #uname -a Linux vm-host 4.4.3-300.fc23.x86_64 #1 SMP Fri Feb 26 18:45:40 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux # /usr/local/bin/qemu-system-x86_64 --version QEMU emulator version 2.5.50, Copyright (c) 2003-2008 Fabrice Bellard -QEMU guest config- OPTS="$OPTS -enable-kvm " OPTS="$OPTS -name win10_35" #OPTS="$OPTS -bios seabios/out/bios.bin" OPTS="$OPTS -machine pc-q35-2.4,accel=kvm,usb=off,vmport=off" OPTS="$OPTS -cpu Broadwell,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff" OPTS="$OPTS -m 4096" OPTS="$OPTS -realtime mlock=off" OPTS="$OPTS -smp 2,sockets=2,cores=1,threads=1" OPTS="$OPTS -uuid e09cbfe5-9016-40b0-a027-62e0d2ef0ba1" OPTS="$OPTS -no-user-config" OPTS="$OPTS -nodefaults " OPTS="$OPTS -rtc base=localtime,driftfix=slew" OPTS="$OPTS -global kvm-pit.lost_tick_policy=discard" OPTS="$OPTS -no-hpet" OPTS="$OPTS -no-shutdown" OPTS="$OPTS -global ICH9-LPC.disable_s3=0" OPTS="$OPTS -global ICH9-LPC.disable_s4=0" OPTS="$OPTS -boot order=c,menu=on,strict=on" OPTS="$OPTS -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e" OPTS="$OPTS -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x1" OPTS="$OPTS -device ich9-usb-ehci1,id=usb,bus=pci.2,addr=0x3.0x7" OPTS="$OPTS -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.2,multifunction=on,addr=0x3" OPTS="$OPTS -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.2,addr=0x3.0x1" OPTS="$OPTS -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.2,addr=0x3.0x2" OPTS="$OPTS -device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x4" OPTS="$OPTS -drive file=/var/lib/images/win10-run2.qcow2,format=qcow2,if=none,id=drive-sata0-0-0,cache=none" OPTS="$OPTS -device ide-hd,bus=ide.0,drive=drive-sata0-0-0,id=sata0-0-0" OPTS="$OPTS -drive file=/var/lib/images/diskd.vhd,format=vpc,if=none,id=drive-sata0-0-1" OPTS="$OPTS -device ide-hd,bus=ide.1,drive=drive-sata0-0-1,id=sata0-0-1" OPTS="$OPTS -drive file=virtio-win.iso,format=raw,if=none,media=cdrom,id=drive-sata0-0-2,readonly=on" OPTS="$OPTS -device ide-cd,bus=ide.2,drive=drive-sata0-0-2,id=sata0-0-2 " OPTS="$OPTS -chardev pty,id=charserial0" OPTS="$OPTS -device isa-serial,chardev=charserial0,id=serial0" OPTS="$OPTS -chardev spicevmc,id=charchannel0,name=vdagent" OPTS="$OPTS -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0" OPTS="$OPTS -device usb-tablet,id=input0" OPTS="$OPTS -spice port=5901,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on" OPTS="$OPTS -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pcie.0,addr=0x1" OPTS="$OPTS -device intel-hda,id=sound0,bus=pci.2,addr=0x2" OPTS="$OPTS -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0" OPTS="$OPTS -device virtio-balloon-pci,id=balloon0,bus=pci.2,addr=0x5" OPTS="$OPTS -msg timestamp=on" OPTS="$OPTS -monitor stdio" #OPTS="$OPTS -qmp stdio" #OPTS="$OPTS -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios" /usr/local/bin/qemu-system-x86_64 $OPTS To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1557057/+subscriptions
[Bug 1555452] Re: GDB server does not work in Windows
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1555452 Title: GDB server does not work in Windows Status in QEMU: Expired Bug description: I build qemu with msys2, MINGW64. After fix the socket_error() problem, and manually specify to use IPv4, GDB server still does not work. The related qemu command is "-monitor none -nographic -gdb tcp::1234 -S" GDB reports "Timed out" There's a message at https://www.mail-archive.com/qemu-devel@nongnu.org/msg357981.html. I've fixed the socket_error() problem. I see that qio_channel_create_socket_watch is called. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1555452/+subscriptions
[Bug 1563152] Re: general protection fault running VirtualBox in KVM guest
[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] ** Changed in: qemu (Ubuntu) Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1563152 Title: general protection fault running VirtualBox in KVM guest Status in QEMU: Expired Status in qemu package in Ubuntu: Expired Bug description: I'm trying to run nested VMs using qemu-kvm on the physical host and VirtualBox on the guest host: * physical host: Ubuntu 14.04 running Linux 4.2.0, qemu-kvm 2.0.0 * guest host: Ubuntu 16.04 beta 2 running Linux 4.4.0, VirtualBox 5.0.16 When I try to start up a VirtualBox VM in the guest host, I get a general protection fault (see below for dmesg output). According to https://www.virtualbox.org/ticket/14965 this is caused by a bug in QEMU/KVM: The problem in more detail: As written above, VirtualBox tries to read the MSR 0x9B (IA32_SMM_MONITOR_CTL). This is an architectural MSR which is present if CPUID.01 / ECX bit 5 or bit 6 are set (VMX or SMX). As KVM has nested virtualization enabled and therefore pretends to support VT-x, this MSR must be accessible and reading from this MSR must not raise a #GP. KVM/QEmu does not behave like real hardware in this case. dmesg output: SUPR0GipMap: fGetGipCpu=0x3 general protection fault: [#1] SMP Modules linked in: pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack xt_tcpudp bridge stp llc iptable_filter ip_tables x_tables ppdev kvm_intel kvm irqbypass snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer i2c_piix4 snd input_leds soundcore joydev 8250_fintek mac_hid serio_raw pvpanic parport_pc parport ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear crct10dif_pclmul crc32_pclmul qxl ttm drm_kms_helper syscopyarea sysfillrect aesni_intel sysimgblt fb_sys_fops aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd psmouse floppy drm pata_acpi CPU: 0 PID: 31507 Comm: EMT Tainted: G OE 4.4.0-15-generic #31-Ubuntu Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 task: 880034c0a580 ti: 880002e0 task.ti: 880002e0 RIP: 0010:[] [] 0xc067e506 RSP: 0018:880002e03d70 EFLAGS: 00010206 RAX: 06f0 RBX: ffdb RCX: 009b RDX: RSI: 880002e03d00 RDI: 880002e03cc8 RBP: 880002e03d90 R08: 0004 R09: 06f0 R10: 49656e69 R11: 0f8bfbff R12: 0020 R13: R14: c957407c R15: c0645260 FS: 7f89b8f6b700() GS:88007fc0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f89b8d1 CR3: 35ae1000 CR4: 06f0 Stack: 880002e03db0 c0693e93 c9574010 880035aae550 880002e03e30 c060a3e7 880002e03e10 0282 Call Trace: [] ? supdrvIOCtl+0x2de7/0x3250 [vboxdrv] [] ? VBoxDrvLinuxIOCtl_5_0_16+0x150/0x250 [vboxdrv] [] ? do_vfs_ioctl+0x29f/0x490 [] ? __do_page_fault+0x1b4/0x400 [] ? SyS_ioctl+0x79/0x90 [] ? entry_SYSCALL_64_fastpath+0x16/0x71 Code: 88 e4 fc ff ff b9 3a 00 00 00 0f 32 48 c1 e2 20 89 c0 48 09 d0 48 89 05 f9 db 0e 00 0f 20 e0 b9 9b 00 00 00 48 89 05 d2 db 0e 00 <0f> 32 48 c1 e2 20 89 c0 b9 80 00 00 c0 48 09 d0 48 89 05 cb db RIP [] 0xc067e506 RSP ---[ end trace b3284b6520f49e0d ]--- To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1563152/+subscriptions
[Bug 1549298] Re: Add missing MSRs for powertop
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1549298
Title:
Add missing MSRs for powertop
Status in QEMU:
Expired
Bug description:
I reported this same bug on the powertop bugtracker [1] because I
think both projects need to change something here.
When running powertop it crashes and prints:
unknown op '{'
read_msr cpu0 0xe8 : Input/output error
It seems that powertop is trying to access model specific registers and
because qemu doesn't emulate them it crashes.
Clearly powertop shouldn't crash in such case but I think it would also be
better if qemu could add support for these registers.
1: https://app.devzing.com/powertopbugs/bugzilla/show_bug.cgi?id=4
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1549298/+subscriptions
[Bug 1563612] Re: pulseaudio applications crash under linux-user-x86_64
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1563612
Title:
pulseaudio applications crash under linux-user-x86_64
Status in QEMU:
Expired
Bug description:
Running a simple application that uses pulseaudio under qemu-i386 or
qemu-x86_64 makes it crash (tested on Debian 8.0):
# apt-get install build-essential qemu-user libpulse-dev pulseaudio
$ cat > test.c << __EOF
#include
int main(void) {
pa_simple *s;
pa_sample_spec ss;
ss.format = PA_SAMPLE_S16NE;
ss.channels = 2;
ss.rate = 44100;
s = pa_simple_new(NULL, // Use the default server.
"Fooapp", // Our application's name.
PA_STREAM_PLAYBACK,
NULL, // Use the default device.
"Music",// Description of our stream.
&ss,// Our sample format.
NULL, // Use default channel map
NULL, // Use default buffering
// attributes.
NULL// Ignore error code.
);
int16_t buf[2 * 1000];
int i;
memset(buf, 0, sizeof buf);
for (i = 0; i < 44; i++) {
pa_simple_write(s, buf, sizeof buf, NULL);
}
pa_simple_free(s);
return 0;
}
__EOF
$ gcc test.c -o test -lpulse -lpulse-simple
$ ./test
$ qemu-x86_64 ./test
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
$
I think this is related to the futex system call. In an attempt to debug the
problem, I compiled pulseaudio in debug mode and it hit an assertion failure in
pa_mutex_unlock.
Thank you for developing QEMU. :-)
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1563612/+subscriptions
[Bug 1579645] Re: [XEN/KVM] pch audio doesn't work on both Windows and linux guest with soundhw="ac97"
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1579645 Title: [XEN/KVM] pch audio doesn't work on both Windows and linux guest with soundhw="ac97" Status in QEMU: Expired Bug description: Environment: when try to boot a guest by qemu with parameter "-soundhw ac97", it showed like below: "audio: Could no init “oss” audio driver.", then login the guest and try run audio, no sound output. Reproduce: 1. kvm: qemu-system-x86_64 -enable-kvm -m 2048 -smp 4 -net nic,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -soundhw ac97 -hda [target.img] xen: add the audio device in guest configure file by soundhw="ac97", xl create $guest-configure 2. it will show "audio: Could no init “oss” audio driver". 3. login in guest, it can detect audio device, but actually it is not working. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1579645/+subscriptions
[Bug 1576347] Re: Only one NVMe device is usable in Windows (10) guest
[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1576347 Title: Only one NVMe device is usable in Windows (10) guest Status in QEMU: Expired Bug description: Full command: qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m 4G -net bridge -net nic -full-screen -drive file=ovmf_x64.bin,format=raw,if=pflash -drive file=disks/win16_ide.img,format=raw,cache=none,aio=native -drive file=disks/one.img,if=none,format=qcow2,id=one -drive file=disks/two.img,if=none,format=qcow2,id=two -device nvme,drive=one,serial=E86C3CFC43518D6F -device nvme,drive=two,serial=2BDAC262CF831698 QEMU version: 2.5.0 Kernel: 4.5.1 (Arch Linux) When there are two NVMe devices specified, only the second one will be usable in Windows. The following error is shown under "Device status" of the failed NVMe controller in Device Manager: "This device cannot start. (Code 10) The I/O device is configured incorrectly or the configuration parameters to the driver are incorrect." The only thing seems suspicious to me is that the nvme emulation in qemu does not have WWN/EUI-64 set for the devices, though I have no idea at all whether that is mandatory: "C:\Windows\system32>sg_vpd -i PD1 Device Identification VPD page: Addressed logical unit: designator type: SCSI name string, code set: UTF-8 SCSI name string: 8086QEMU NVMe Ctrl 00012BDAC262CF831698 C:\Windows\system32>sg_vpd -p sn PD1 Unit serial number VPD page: Unit serial number: ___." To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1576347/+subscriptions
[Bug 1579306] Re: usb-uas does not work in Windows (10) guest
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1579306
Title:
usb-uas does not work in Windows (10) guest
Status in QEMU:
Expired
Bug description:
When I attach a "-device usb-uas" to a VM with Windows 10 10586, the
device fail to start with the following error in the guest:
"The device cannot start. (Code 10)
{Operation Failed}
The requested operation was unsuccessful"
If the host controller is nec-usb-xhci, there will be two of the
following error on the terminal of the host as well:
"qemu-system-x86_64: usb_uas_handle_control: unhandled control
request"
If it's usb-ehci, ich9-usb-ehci1 or ich9-usb-echi2, this will not show
up on the host side, but the device stil fails with the same error on
the guest side.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1579306/+subscriptions
Re: [PATCH] hw/misc: sifive_u_otp: Use error_report() when block operation fails
On 1/19/21 4:23 AM, Bin Meng wrote: > From: Bin Meng > > At present when blk_pread() / blk_pwrite() fails, a guest error > is logged, but this is not really a guest error. Change to use > error_report() instead. > > Signed-off-by: Bin Meng > --- > > hw/misc/sifive_u_otp.c | 13 + > 1 file changed, 5 insertions(+), 8 deletions(-) Reviewed-by: Philippe Mathieu-Daudé
[PATCH] hw/misc: sifive_u_otp: Use error_report() when block operation fails
From: Bin Meng
At present when blk_pread() / blk_pwrite() fails, a guest error
is logged, but this is not really a guest error. Change to use
error_report() instead.
Signed-off-by: Bin Meng
---
hw/misc/sifive_u_otp.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/hw/misc/sifive_u_otp.c b/hw/misc/sifive_u_otp.c
index f921c67..4d8f793 100644
--- a/hw/misc/sifive_u_otp.c
+++ b/hw/misc/sifive_u_otp.c
@@ -23,6 +23,7 @@
#include "hw/qdev-properties.h"
#include "hw/qdev-properties-system.h"
#include "hw/sysbus.h"
+#include "qemu/error-report.h"
#include "qemu/log.h"
#include "qemu/module.h"
#include "hw/misc/sifive_u_otp.h"
@@ -65,8 +66,7 @@ static uint64_t sifive_u_otp_read(void *opaque, hwaddr addr,
unsigned int size)
if (blk_pread(s->blk, s->pa * SIFIVE_U_OTP_FUSE_WORD, &buf,
SIFIVE_U_OTP_FUSE_WORD) < 0) {
-qemu_log_mask(LOG_GUEST_ERROR,
- "read error index<%d>\n", s->pa);
+error_report("read error index<%d>", s->pa);
return 0xff;
}
@@ -169,8 +169,7 @@ static void sifive_u_otp_write(void *opaque, hwaddr addr,
if (blk_pwrite(s->blk, s->pa * SIFIVE_U_OTP_FUSE_WORD,
&s->fuse[s->pa], SIFIVE_U_OTP_FUSE_WORD,
0) < 0) {
-qemu_log_mask(LOG_GUEST_ERROR,
- "write error index<%d>\n", s->pa);
+error_report("write error index<%d>", s->pa);
}
}
@@ -260,15 +259,13 @@ static void sifive_u_otp_reset(DeviceState *dev)
serial_data = s->serial;
if (blk_pwrite(s->blk, index * SIFIVE_U_OTP_FUSE_WORD,
&serial_data, SIFIVE_U_OTP_FUSE_WORD, 0) < 0) {
-qemu_log_mask(LOG_GUEST_ERROR,
- "write error index<%d>\n", index);
+error_report("write error index<%d>", index);
}
serial_data = ~(s->serial);
if (blk_pwrite(s->blk, (index + 1) * SIFIVE_U_OTP_FUSE_WORD,
&serial_data, SIFIVE_U_OTP_FUSE_WORD, 0) < 0) {
-qemu_log_mask(LOG_GUEST_ERROR,
- "write error index<%d>\n", index + 1);
+error_report("write error index<%d>", index + 1);
}
}
--
2.7.4
Re: [RFC PATCH V2 00/11] hw/block/nvme: support multi-path for ctrl/ns
On 21-01-18 22:14:45, Klaus Jensen wrote: > On Jan 17 23:53, Minwoo Im wrote: > > Hello, > > > > This patch series introduces NVMe subsystem device to support multi-path > > I/O in NVMe device model. Two use-cases are supported along with this > > patch: Multi-controller, Namespace Sharing. > > > > V1 RFC has been discussed with Klaus and Keith, I really appreciate them > > for this patch series to have proper direction [1]. > > > > This patch series contains few start-up refactoring pathces from the > > first to fifth patches to make nvme-ns device not to rely on the nvme > > controller always. Because nvme-ns shall be able to be mapped to the > > subsystem level, not a single controller level so that it should provide > > generic initialization code: nvme_ns_setup() with NvmeCtrl. To do that, > > the first five patches are to remove the NvmeCtrl * instance argument > > from the nvme_ns_setup(). I'd be happy if they are picked! > > > > For controller and namespace devices, 'subsys' property has been > > introduced to map them to a subsystem. If multi-controller needed, we > > can specify 'subsys' to controllers the same. > > > > For namespace deivice, if 'subsys' is not given just like it was, it > > will have to be provided with 'bus' parameter to specify a nvme > > controller device to attach, it means, they are mutual-exlusive. To > > share a namespace between or among controllers, then nvme-ns should have > > 'subsys' property to a single nvme subsystem instance. To make a > > namespace private one, then we need to specify 'bus' property rather > > than the 'subsys'. > > > > Of course, this series does not require any updates for the run command > > for the previos users. > > > > Plase refer the following example with nvme-cli output: > > > > QEMU Run: > > -device nvme-subsys,id=subsys0 \ > > -device nvme,serial=foo,id=nvme0,subsys=subsys0 \ > > -device nvme,serial=bar,id=nvme1,subsys=subsys0 \ > > -device nvme,serial=baz,id=nvme2,subsys=subsys0 \ > > -device nvme-ns,id=ns1,drive=drv10,nsid=1,subsys=subsys0 \ > > -device nvme-ns,id=ns2,drive=drv11,nsid=2,bus=nvme2 \ > > \ > > -device nvme,serial=qux,id=nvme3 \ > > -device nvme-ns,id=ns3,drive=drv12,nsid=3,bus=nvme3 > > > > nvme-cli: > > root@vm:~/work# nvme list -v > > NVM Express Subsystems > > > > SubsystemSubsystem-NQN > > Controllers > > > > > > > > nvme-subsys1 nqn.2019-08.org.qemu:subsys0 > > nvme0, nvme1, nvme2 > > nvme-subsys3 nqn.2019-08.org.qemu:qux > > nvme3 > > > > NVM Express Controllers > > > > Device SN MN FR > > TxPort AddressSubsystemNamespaces > > > > -- -- > > nvme0foo QEMU NVMe Ctrl > > 1.0 pcie :00:06.0 nvme-subsys1 nvme1n1 > > nvme1bar QEMU NVMe Ctrl > > 1.0 pcie :00:07.0 nvme-subsys1 nvme1n1 > > nvme2baz QEMU NVMe Ctrl > > 1.0 pcie :00:08.0 nvme-subsys1 nvme1n1, nvme1n2 > > nvme3qux QEMU NVMe Ctrl > > 1.0 pcie :00:09.0 nvme-subsys3 > > > > NVM Express Namespaces > > > > Device NSID Usage Format > > Controllers > > -- > > > > nvme1n1 1134.22 MB / 134.22 MB512 B + 0 B nvme0, > > nvme1, nvme2 > > nvme1n2 2268.44 MB / 268.44 MB512 B + 0 B nvme2 > > nvme3n1 3268.44 MB / 268.44 MB512 B + 0 B nvme3 > > > > Summary: > > - Refactored nvme-ns device not to rely on controller during the > > setup. [1/11 - 5/11] > > - Introduced a nvme-subsys device model. [6/11] > > - Create subsystem NQN based on subsystem. [7/11] > > - Introduced multi-controller model. [8/11 - 9/11] > > - Updated namespace sharing scheme to be based on nvme-subsys > > hierarchy. [10/11 - 11/11] > > > > Since RFC V1: > > - Updated namespace sharing scheme to be based on nvme-subsys > > hierarchy. > > > > Great stuff Minwoo. Thanks! > > I'll pick up [01-05/11] directly since they are pretty trivial. Thanks! will prepare the next series based on there. > The subsystem model looks pretty much like it should, I don't have a lot > of comments. > > One thing that I cons
Re: [PATCH] target/riscv: Declare csr_ops[] with a known size
On 1/19/21 3:52 AM, Bin Meng wrote: > From: Bin Meng > > csr_ops[] is currently declared with an unknown size in cpu.h. > Since the array size is known, let's do a complete declaration. > > Signed-off-by: Bin Meng > --- > > target/riscv/cpu.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Philippe Mathieu-Daudé
[PATCH] target/riscv: Declare csr_ops[] with a known size
From: Bin Meng
csr_ops[] is currently declared with an unknown size in cpu.h.
Since the array size is known, let's do a complete declaration.
Signed-off-by: Bin Meng
---
target/riscv/cpu.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 02758ae..419a214 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -487,7 +487,7 @@ enum {
};
/* CSR function table */
-extern riscv_csr_operations csr_ops[];
+extern riscv_csr_operations csr_ops[CSR_TABLE_SIZE];
void riscv_get_csr_ops(int csrno, riscv_csr_operations *ops);
void riscv_set_csr_ops(int csrno, riscv_csr_operations *ops);
--
2.7.4
Re: [PATCH 1/4] target/riscv: Make csr_ops[CSR_TABLE_SIZE] external
On Tue, Jan 19, 2021 at 1:55 AM Richard Henderson wrote: > > On 1/11/21 6:52 PM, Bin Meng wrote: > > +extern riscv_csr_operations csr_ops[]; > > You might as well use CSR_TABLE_SIZE here. > OK, I will send a patch for this. Thanks! > Otherwise, > Reviewed-by: Richard Henderson Regards, Bin
Re: [PATCH] npcm7xx_adc-test: Fix memleak in adc_qom_set
On Sun, Jan 17, 2021 at 10:59 PM Gan Qixin wrote: > The adc_qom_set function didn't free "response", which caused an indirect > memory leak. So use qobject_unref() to fix it. > > ASAN shows memory leak stack: > > Indirect leak of 593280 byte(s) in 144 object(s) allocated from: > #0 0x7f9a5e7e8d4e in __interceptor_calloc > (/lib64/libasan.so.5+0x112d4e) > #1 0x7f9a5e607a50 in g_malloc0 (/lib64/libglib-2.0.so.0+0x55a50) > #2 0x55b1bebf636b in qdict_new ../qobject/qdict.c:30 > #3 0x55b1bec09699 in parse_object ../qobject/json-parser.c:318 > #4 0x55b1bec0b2df in parse_value ../qobject/json-parser.c:546 > #5 0x55b1bec0b6a9 in json_parser_parse ../qobject/json-parser.c:580 > #6 0x55b1bec060d1 in json_message_process_token > ../qobject/json-streamer.c:92 > #7 0x55b1bec16a12 in json_lexer_feed_char ../qobject/json-lexer.c:313 > #8 0x55b1bec16fbd in json_lexer_feed ../qobject/json-lexer.c:350 > #9 0x55b1bec06453 in json_message_parser_feed > ../qobject/json-streamer.c:121 > #10 0x55b1bebc2d51 in qmp_fd_receive ../tests/qtest/libqtest.c:614 > #11 0x55b1bebc2f5e in qtest_qmp_receive_dict > ../tests/qtest/libqtest.c:636 > #12 0x55b1bebc2e6c in qtest_qmp_receive ../tests/qtest/libqtest.c:624 > #13 0x55b1bebc3340 in qtest_vqmp ../tests/qtest/libqtest.c:715 > #14 0x55b1bebc3942 in qtest_qmp ../tests/qtest/libqtest.c:756 > #15 0x55b1bebbd64a in adc_qom_set ../tests/qtest/npcm7xx_adc-test.c:127 > #16 0x55b1bebbd793 in adc_write_input > ../tests/qtest/npcm7xx_adc-test.c:140 > #17 0x55b1bebbdf92 in test_convert_external > ../tests/qtest/npcm7xx_adc-test.c:246 > > Reported-by: Euler Robot > Signed-off-by: Gan Qixin > Reviewed-by: Hao Wu Thanks! > --- > Cc: Hao Wu > Cc: Havard Skinnemoen > Cc: Tyrone Ting > Cc: Thomas Huth > Cc: Laurent Vivier > --- > tests/qtest/npcm7xx_adc-test.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/tests/qtest/npcm7xx_adc-test.c > b/tests/qtest/npcm7xx_adc-test.c > index f029706945..5ce8ce13b3 100644 > --- a/tests/qtest/npcm7xx_adc-test.c > +++ b/tests/qtest/npcm7xx_adc-test.c > @@ -129,6 +129,7 @@ static void adc_qom_set(QTestState *qts, const ADC > *adc, > path, name, value); > /* The qom set message returns successfully. */ > g_assert_true(qdict_haskey(response, "return")); > +qobject_unref(response); > } > > static void adc_write_input(QTestState *qts, const ADC *adc, > -- > 2.27.0 > >
Re: [RFC PATCH V2 10/11] hw/block/nvme: add NMIC enum value for Identify Namespace
> Let's keep convention (or should be convention...) of using NvmeIdNs > prefix for identify data structure fields on the enum. Okay!
Re: [PATCH v2 10/12] hw/block/nvme: move cmb logic to v1.4
On 21-01-18 20:23:30, Klaus Jensen wrote:
> On Jan 18 14:22, Klaus Jensen wrote:
> > On Jan 18 22:12, Minwoo Im wrote:
> > > On 21-01-18 14:10:50, Klaus Jensen wrote:
> > > > On Jan 18 22:09, Minwoo Im wrote:
> > > > > > > Yes, CMB in v1.4 is not backward-compatible, but is it okay to
> > > > > > > move onto
> > > > > > > the CMB v1.4 from v1.3 without supporting the v1.3 usage on this
> > > > > > > device
> > > > > > > model?
> > > > > >
> > > > > > Next patch moves to v1.4. I wanted to split it because the "bump"
> > > > > > patch
> > > > > > also adds a couple of other v1.4 requires fields. But I understand
> > > > > > that
> > > > > > this is slightly wrong.
> > > > >
> > > > > Sorry, I meant I'd like to have CMB for v1.3 support along with the
> > > > > v1.4
> > > > > support in this device model separately. Maybe I missed the
> > > > > linux-nvme
> > > > > mailing list for CMB v1.4, but is there no plan to keep supportin CMB
> > > > > v1.3 in NVMe driver?
> > > >
> > > > I posted a patch on linux-nvme for v1.4 support in the kernel. It will
> > > > support both the v1.3 and v1.4 behavior :)
> > >
> > > Then, can we maintain CMB v1.3 also in QEMU also along with v1.4 ? :)
> >
> > My first version of this patch actually included compatibility support
> > for v1.3 ("legacy cmb"), but Keith suggested we just drop that and keep
> > this device compliant.
> >
> > What we could do is allow the spec version to be chosen with a
> > parameter?
>
> Uhm. Maybe not. I gave this some more thought.
>
> Adding a device parameter to choose the specification version requires
> us to maintain QEMU "compat" properties across different QEMU version.
> I'm not sure we want that for something like this.
Agreed. The default should head for latest one.
>
> Maybe the best course of action actually *is* an 'x-legacy-cmb'
> parameter.
This looks fine.
As kernel driver does not remove the v1.3 CMB support, then it would be
great if QEMU suports that also.
Re: [PATCH v2 02/12] hw/block/nvme: fix 64 bit register hi/lo split writes
On 21-01-18 20:53:24, Klaus Jensen wrote: > On Jan 18 21:59, Minwoo Im wrote: > > > The spec requires aligned 32 bit accesses (or the size of the register), > > > so maybe it's about time we actually ignore instead of falling through. > > > > Agreed. > > > > On the other hand. > > The spec just allows undefined behavior if the alignment or size > requirement is violated. So falling through is not wrong. If so, maybe we just can make this MMIO region support under 4bytes access with error messaging. I don't think we should not support them on purpose because spec says it just results in undefined behaviors which is just undefined how to handle them.
Re: Re: [PATCH v4 0/3] support NVMe smart critial warning injection
On 1/18/21 5:34 PM, Klaus Jensen wrote:
On Jan 15 11:26, zhenwei pi wrote:
v3 -> v4:
- Drop "Fix overwritten bar.cap". (Already fixed)
- Avoid to enqueue the duplicate event.
- Several minor changes for coding style & function/variable name.
v2 -> v3:
- Introduce "Persistent Memory Region has become read-only or
unreliable"
- Fix overwritten bar.cap
- Check smart critical warning value from QOM.
- Trigger asynchronous event during smart warning injection.
v1 -> v2:
- Suggested by Philippe & Klaus, set/get smart_critical_warning by QMP.
v1:
- Add smart_critical_warning for nvme device which can be set by QEMU
command line to emulate hardware error.
Zhenwei Pi (3):
block/nvme: introduce bit 5 for critical warning
hw/block/nvme: add smart_critical_warning property
hw/blocl/nvme: trigger async event during injecting smart warning
hw/block/nvme.c | 91 +++-
hw/block/nvme.h | 1 +
include/block/nvme.h | 3 ++
3 files changed, 86 insertions(+), 9 deletions(-)
This looks pretty good to me.
I think maybe we want to handle the duplicate event stuff more generally
from the AER/AEN code, but this does the job.
Tested-by: Klaus Jensen
Reviewed-by: Klaus Jensen
What's the next step I should take? Should I push a new version to
implement this purpose? From my understanding, before inserting a new
event to aer_queue, I can parse all the pending aer to find the same event.
nvme_enqueue_event()
{
...
QTAILQ_FOREACH_SAFE(event, &n->aer_queue, entry, next) {
if ((event->result.event_type == event_type)
&& (event->result.event_info == event_info)
&& (event->result.log_page == log_page))
return;
}
QTAILQ_INSERT_TAIL(&n->aer_queue, event, entry);
n->aer_queued++;
...
}
--
zhenwei pi
[PATCH v4 3/5] tests/acpi: add OEM ID and OEM TABLE ID test
Add support for testing the fields OEM ID and OEM TABLE ID in all ACPI tables for PC,Q35,MICROVM,AARCH64 Full diff of changed files disassembly: Table tests/data/acpi/virt/FACP diff: @@ -3,7 +3,7 @@ * AML/ASL+ Disassembler version 20200326 (64-bit version) * Copyright (c) 2000 - 2020 Intel Corporation * - * Disassembly of tests/data/acpi/virt/FACP, Mon Jan 18 23:55:00 2021 + * Disassembly of /tmp/aml-VQIIX0, Mon Jan 18 23:55:00 2021 * * ACPI Data Table [FACP] * @@ -13,9 +13,9 @@ [000h 4]Signature : "FACP"[Fixed ACPI Description Table (FADT)] [004h 0004 4] Table Length : 010C [008h 0008 1] Revision : 05 -[009h 0009 1] Checksum : BB +[009h 0009 1] Checksum : 55 [00Ah 0010 6] Oem ID : "BOCHS " -[010h 0016 8] Oem Table ID : "BXPCFACP" +[010h 0016 8] Oem Table ID : "BXPC" [018h 0024 4] Oem Revision : 0001 [01Ch 0028 4] Asl Compiler ID : "BXPC" [020h 0032 4]Asl Compiler Revision : 0001 Table tests/data/acpi/virt/APIC diff: @@ -3,7 +3,7 @@ * AML/ASL+ Disassembler version 20200326 (64-bit version) * Copyright (c) 2000 - 2020 Intel Corporation * - * Disassembly of tests/data/acpi/virt/APIC, Mon Jan 18 23:55:00 2021 + * Disassembly of /tmp/aml-BQIIX0, Mon Jan 18 23:55:00 2021 * * ACPI Data Table [APIC] * @@ -13,9 +13,9 @@ [000h 4]Signature : "APIC"[Multiple APIC Description Table (MADT)] [004h 0004 4] Table Length : 00A8 [008h 0008 1] Revision : 03 -[009h 0009 1] Checksum : B3 +[009h 0009 1] Checksum : 50 [00Ah 0010 6] Oem ID : "BOCHS " -[010h 0016 8] Oem Table ID : "BXPCAPIC" +[010h 0016 8] Oem Table ID : "BXPC" [018h 0024 4] Oem Revision : 0001 [01Ch 0028 4] Asl Compiler ID : "BXPC" [020h 0032 4]Asl Compiler Revision : 0001 Table tests/data/acpi/virt/GTDT diff: @@ -3,7 +3,7 @@ * AML/ASL+ Disassembler version 20200326 (64-bit version) * Copyright (c) 2000 - 2020 Intel Corporation * - * Disassembly of tests/data/acpi/virt/GTDT, Mon Jan 18 23:55:00 2021 + * Disassembly of /tmp/aml-QQIIX0, Mon Jan 18 23:55:00 2021 * * ACPI Data Table [GTDT] * @@ -13,9 +13,9 @@ [000h 4]Signature : "GTDT"[Generic Timer Description Table] [004h 0004 4] Table Length : 0060 [008h 0008 1] Revision : 02 -[009h 0009 1] Checksum : D9 +[009h 0009 1] Checksum : 8C [00Ah 0010 6] Oem ID : "BOCHS " -[010h 0016 8] Oem Table ID : "BXPCGTDT" +[010h 0016 8] Oem Table ID : "BXPC" [018h 0024 4] Oem Revision : 0001 [01Ch 0028 4] Asl Compiler ID : "BXPC" [020h 0032 4]Asl Compiler Revision : 0001 Table tests/data/acpi/virt/MCFG diff: @@ -3,7 +3,7 @@ * AML/ASL+ Disassembler version 20200326 (64-bit version) * Copyright (c) 2000 - 2020 Intel Corporation * - * Disassembly of tests/data/acpi/virt/MCFG, Mon Jan 18 23:55:00 2021 + * Disassembly of /tmp/aml-OQIIX0, Mon Jan 18 23:55:00 2021 * * ACPI Data Table [MCFG] * @@ -13,9 +13,9 @@ [000h 4]Signature : "MCFG"[Memory Mapped Configuration table] [004h 0004 4] Table Length : 003C [008h 0008 1] Revision : 01 -[009h 0009 1] Checksum : 4F +[009h 0009 1] Checksum : EC [00Ah 0010 6] Oem ID : "BOCHS " -[010h 0016 8] Oem Table ID : "BXPCMCFG" +[010h 0016 8] Oem Table ID : "BXPC" [018h 0024 4] Oem Revision : 0001 [01Ch 0028 4] Asl Compiler ID : "BXPC" [020h 0032 4]Asl Compiler Revision : 0001 Table tests/data/acpi/virt/SPCR diff: @@ -3,7 +3,7 @@ * AML/ASL+ Disassembler version 20200326 (64-bit version) * Copyright (c) 2000 - 2020 Intel Corporation * - * Disassembly of tests/data/acpi/virt/SPCR, Mon Jan 18 23:55:00 2021 + * Disassembly of /tmp/aml-EMIIX0, Mon Jan 18 23:55:00 2021 * * ACPI Data Table [SPCR] * @@ -13,9 +13,9 @@ [000h 4]Signature : "SPCR"[Serial Port Console Redirection table] [004h 0004 4] Table Length : 0050 [008h 0008 1] Revision : 02 -[009h 0009 1] Checksum : 13 +[009h 0009 1] Checksum : CB [00Ah 0010 6] Oem ID : "BOCHS " -[010h 0016 8] Oem Table ID : "BXPCSPCR" +[010h 0016 8] Oem Table ID : "BXPC" [018h 00
[PATCH v4 5/5] tests/acpi: disallow updates for expected data files
Signed-off-by: Marian Postevca --- tests/qtest/bios-tables-test-allowed-diff.h | 94 - 1 file changed, 94 deletions(-) diff --git a/tests/qtest/bios-tables-test-allowed-diff.h b/tests/qtest/bios-tables-test-allowed-diff.h index b20ae72949..dfb8523c8b 100644 --- a/tests/qtest/bios-tables-test-allowed-diff.h +++ b/tests/qtest/bios-tables-test-allowed-diff.h @@ -1,95 +1 @@ /* List of comma-separated changed AML files to ignore */ -"tests/data/acpi/virt/APIC", -"tests/data/acpi/virt/FACP", -"tests/data/acpi/virt/GTDT", -"tests/data/acpi/virt/MCFG", -"tests/data/acpi/virt/SPCR", -"tests/data/acpi/virt/DSDT", -"tests/data/acpi/virt/APIC.numamem", -"tests/data/acpi/virt/FACP.numamem", -"tests/data/acpi/virt/GTDT.numamem", -"tests/data/acpi/virt/MCFG.numamem", -"tests/data/acpi/virt/SPCR.numamem", -"tests/data/acpi/virt/DSDT.numamem", -"tests/data/acpi/virt/SRAT.numamem", -"tests/data/acpi/virt/DSDT.memhp", -"tests/data/acpi/virt/NFIT.memhp", -"tests/data/acpi/virt/SSDT.memhp", -"tests/data/acpi/virt/SLIT.memhp", -"tests/data/acpi/virt/SRAT.memhp", -"tests/data/acpi/virt/SPCR.memhp", -"tests/data/acpi/virt/MCFG.memhp", -"tests/data/acpi/virt/GTDT.memhp", -"tests/data/acpi/virt/APIC.memhp", -"tests/data/acpi/virt/FACP.memhp", -"tests/data/acpi/virt/DSDT.pxb", - -"tests/data/acpi/pc/SRAT.acpihmat", -"tests/data/acpi/pc/HPET", -"tests/data/acpi/pc/DSDT.hpbrroot", -"tests/data/acpi/pc/SRAT.numamem", -"tests/data/acpi/pc/DSDT.dimmpxm", -"tests/data/acpi/pc/DSDT.acpihmat", -"tests/data/acpi/pc/FACP", -"tests/data/acpi/pc/SRAT.cphp", -"tests/data/acpi/pc/DSDT.numamem", -"tests/data/acpi/pc/DSDT.bridge", -"tests/data/acpi/pc/HMAT.acpihmat", -"tests/data/acpi/pc/DSDT.cphp", -"tests/data/acpi/pc/APIC.dimmpxm", -"tests/data/acpi/pc/SRAT.memhp", -"tests/data/acpi/pc/SLIT.cphp", -"tests/data/acpi/pc/DSDT.hpbridge", -"tests/data/acpi/pc/NFIT.dimmpxm", -"tests/data/acpi/pc/APIC.cphp", -"tests/data/acpi/pc/SSDT.dimmpxm", -"tests/data/acpi/pc/SRAT.dimmpxm", -"tests/data/acpi/pc/APIC.acpihmat", -"tests/data/acpi/pc/DSDT.memhp", -"tests/data/acpi/pc/DSDT.ipmikcs", -"tests/data/acpi/pc/SLIT.memhp", -"tests/data/acpi/pc/WAET", -"tests/data/acpi/pc/DSDT", -"tests/data/acpi/pc/APIC", -"tests/data/acpi/pc/DSDT.roothp", - -"tests/data/acpi/q35/SRAT.acpihmat", -"tests/data/acpi/q35/HPET", -"tests/data/acpi/q35/SRAT.numamem", -"tests/data/acpi/q35/DSDT.dimmpxm", -"tests/data/acpi/q35/DSDT.acpihmat", -"tests/data/acpi/q35/FACP", -"tests/data/acpi/q35/DSDT.mmio64", -"tests/data/acpi/q35/SRAT.cphp", -"tests/data/acpi/q35/DSDT.numamem", -"tests/data/acpi/q35/DSDT.bridge", -"tests/data/acpi/q35/HMAT.acpihmat", -"tests/data/acpi/q35/DSDT.cphp", -"tests/data/acpi/q35/APIC.dimmpxm", -"tests/data/acpi/q35/SRAT.memhp", -"tests/data/acpi/q35/SLIT.cphp", -"tests/data/acpi/q35/NFIT.dimmpxm", -"tests/data/acpi/q35/APIC.cphp", -"tests/data/acpi/q35/SSDT.dimmpxm", -"tests/data/acpi/q35/SRAT.dimmpxm", -"tests/data/acpi/q35/APIC.acpihmat", -"tests/data/acpi/q35/MCFG", -"tests/data/acpi/q35/DSDT.memhp", -"tests/data/acpi/q35/SLIT.memhp", -"tests/data/acpi/q35/WAET", -"tests/data/acpi/q35/DSDT.ipmibt", -"tests/data/acpi/q35/DSDT.tis", -"tests/data/acpi/q35/SRAT.mmio64", -"tests/data/acpi/q35/TPM2.tis", -"tests/data/acpi/q35/DSDT", -"tests/data/acpi/q35/APIC", - -"tests/data/acpi/microvm/APIC.pcie", -"tests/data/acpi/microvm/DSDT.pcie", -"tests/data/acpi/microvm/DSDT.usb", -"tests/data/acpi/microvm/DSDT.rtc", -"tests/data/acpi/microvm/FACP", -"tests/data/acpi/microvm/APIC.ioapic2", -"tests/data/acpi/microvm/DSDT.ioapic2", -"tests/data/acpi/microvm/DSDT", -"tests/data/acpi/microvm/APIC", -- 2.26.2
[PATCH v4 2/5] acpi: Permit OEM ID and OEM table ID fields to be changed
Qemu's ACPI table generation sets the fields OEM ID and OEM table ID
to "BOCHS " and "BXPC" where "" is replaced by the ACPI
table name.
Some games like Red Dead Redemption 2 seem to check the ACPI OEM ID
and OEM table ID for the strings "BOCHS" and "BXPC" and if they are
found, the game crashes(this may be an intentional detection
mechanism to prevent playing the game in a virtualized environment).
This patch allows you to override these default values.
The feature can be used in this manner:
qemu -machine oem-id=ABCDEF,oem-table-id=GHIJKLMN
The oem-id string can be up to 6 bytes in size, and the
oem-table-id string can be up to 8 bytes in size. If the string are
smaller than their respective sizes they will be padded with space.
If either of these parameters is not set, the current default values
will be used for the one missing.
Note that the the OEM Table ID field will not be extended with the
name of the table, but will use either the default name or the user
provided one.
This does not affect the -acpitable option (for user-defined ACPI
tables), which has precedence over -machine option.
Signed-off-by: Marian Postevca
---
hw/acpi/hmat.h | 3 +-
hw/i386/acpi-common.h | 3 +-
include/hw/acpi/acpi-defs.h | 2 +-
include/hw/acpi/aml-build.h | 8 ++--
include/hw/acpi/ghes.h | 3 +-
include/hw/acpi/pci.h | 3 +-
include/hw/acpi/vmgenid.h | 2 +-
include/hw/arm/virt.h | 2 +
include/hw/i386/microvm.h | 4 ++
include/hw/i386/pc.h| 5 ++-
include/hw/mem/nvdimm.h | 3 +-
hw/acpi/aml-build.c | 29 ++---
hw/acpi/ghes.c | 5 ++-
hw/acpi/hmat.c | 5 ++-
hw/acpi/nvdimm.c| 18 +---
hw/acpi/pci.c | 5 ++-
hw/acpi/vmgenid.c | 4 +-
hw/arm/virt-acpi-build.c| 40 +++--
hw/arm/virt.c | 63 +++
hw/i386/acpi-build.c| 86 +
hw/i386/acpi-common.c | 5 ++-
hw/i386/acpi-microvm.c | 13 +++---
hw/i386/microvm.c | 66
hw/i386/pc.c| 64 +++
24 files changed, 349 insertions(+), 92 deletions(-)
diff --git a/hw/acpi/hmat.h b/hw/acpi/hmat.h
index e9031cac01..b57f0e7e80 100644
--- a/hw/acpi/hmat.h
+++ b/hw/acpi/hmat.h
@@ -37,6 +37,7 @@
*/
#define HMAT_PROXIMITY_INITIATOR_VALID 0x1
-void build_hmat(GArray *table_data, BIOSLinker *linker, NumaState *numa_state);
+void build_hmat(GArray *table_data, BIOSLinker *linker, NumaState *numa_state,
+const char *oem_id, const char *oem_table_id);
#endif
diff --git a/hw/i386/acpi-common.h b/hw/i386/acpi-common.h
index c30e461f18..b12cd73ea5 100644
--- a/hw/i386/acpi-common.h
+++ b/hw/i386/acpi-common.h
@@ -9,6 +9,7 @@
#define ACPI_BUILD_IOAPIC_ID 0x0
void acpi_build_madt(GArray *table_data, BIOSLinker *linker,
- X86MachineState *x86ms, AcpiDeviceIf *adev);
+ X86MachineState *x86ms, AcpiDeviceIf *adev,
+ const char *oem_id, const char *oem_table_id);
#endif
diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
index 38a42f409a..cf9f44299c 100644
--- a/include/hw/acpi/acpi-defs.h
+++ b/include/hw/acpi/acpi-defs.h
@@ -41,7 +41,7 @@ enum {
};
typedef struct AcpiRsdpData {
-uint8_t oem_id[6] QEMU_NONSTRING; /* OEM identification */
+char *oem_id; /* OEM identification */
uint8_t revision; /* Must be 0 for 1.0, 2 for 2.0 */
unsigned *rsdt_tbl_offset;
diff --git a/include/hw/acpi/aml-build.h b/include/hw/acpi/aml-build.h
index 54a5aec4d7..380d3e3924 100644
--- a/include/hw/acpi/aml-build.h
+++ b/include/hw/acpi/aml-build.h
@@ -8,7 +8,7 @@
#define ACPI_BUILD_TABLE_MAX_SIZE 0x20
#define ACPI_BUILD_APPNAME6 "BOCHS "
-#define ACPI_BUILD_APPNAME4 "BXPC"
+#define ACPI_BUILD_APPNAME8 "BXPC"
#define ACPI_BUILD_TABLE_FILE "etc/acpi/tables"
#define ACPI_BUILD_RSDP_FILE "etc/acpi/rsdp"
@@ -459,10 +459,12 @@ Aml *build_crs(PCIHostState *host, CrsRangeSet
*range_set, uint32_t io_offset,
void build_srat_memory(AcpiSratMemoryAffinity *numamem, uint64_t base,
uint64_t len, int node, MemoryAffinityFlags flags);
-void build_slit(GArray *table_data, BIOSLinker *linker, MachineState *ms);
+void build_slit(GArray *table_data, BIOSLinker *linker, MachineState *ms,
+const char *oem_id, const char *oem_table_id);
void build_fadt(GArray *tbl, BIOSLinker *linker, const AcpiFadtData *f,
const char *oem_id, const char *oem_table_id);
-void build_tpm2(GArray *table_data, BIOSLinker *linker, GArray *tcpalog);
+void build_tpm2(GArray *table_data, BIOSLinker *linker, GArray *tcpalog,
+const char *oem_id, const char *oem_table_id);
#endif
diff --git a/include/hw/acpi/ghes.h b/include/hw/acpi/ghes.h
index 4ad025e09a.
[PATCH v4 0/5] acpi: Permit OEM ID and OEM table ID fields to be changed
Qemu's ACPI table generation sets the fields OEM ID and OEM table ID to "BOCHS " and "BXPC" where "" is replaced by the ACPI table name. Some games like Red Dead Redemption 2 seem to check the ACPI OEM ID and OEM table ID for the strings "BOCHS" and "BXPC" and if they are found, the game crashes(this may be an intentional detection mechanism to prevent playing the game in a virtualized environment). This patch allows you to override these default values. The feature can be used in this manner: qemu -machine oem-id=ABCDEF,oem-table-id=GHIJKLMN The oem-id string can be up to 6 bytes in size, and the oem-table-id string can be up to 8 bytes in size. If the string are smaller than their respective sizes they will be padded with space. If either of these parameters is not set, the current default values will be used for the one missing. Note that the the OEM Table ID field will not be extended with the name of the table, but will use either the default name or the user provided one. This does not affect the -acpitable option (for user-defined ACPI tables), which has precedence over -machine option. v4: - Added testcases for pc,q35,microvm,aarch64 - Switched to strpadcpy() instead of own function - Don't touch unrelated fields in tables - Instead of VIRT_MACHINE(obj)->bar use Foo *vm = VIRT_MACHINE(obj); vm->bar v3: - Do not append the sig part to OEM table id - build_header() always sets the passed in values for oem_id and oem_table_id - Fixed a call to g_strdup() with a non-terminated string - Use MachineState structures to hold the OEM fields - Proper error handling in object setters - Added description for object setters/getters - Added support for pc,q35,microvm,aarch64 v2: - Use machine properties to set the OEM fields values - Pass the desired values from acpi_build() Marian Postevca (5): tests/acpi: allow updates for expected data files acpi: Permit OEM ID and OEM table ID fields to be changed tests/acpi: add OEM ID and OEM TABLE ID test tests/acpi: update expected data files tests/acpi: disallow updates for expected data files hw/acpi/hmat.h | 3 +- hw/i386/acpi-common.h| 3 +- include/hw/acpi/acpi-defs.h | 2 +- include/hw/acpi/aml-build.h | 8 +- include/hw/acpi/ghes.h | 3 +- include/hw/acpi/pci.h| 3 +- include/hw/acpi/vmgenid.h| 2 +- include/hw/arm/virt.h| 2 + include/hw/i386/microvm.h| 4 + include/hw/i386/pc.h | 5 +- include/hw/mem/nvdimm.h | 3 +- hw/acpi/aml-build.c | 29 ++--- hw/acpi/ghes.c | 5 +- hw/acpi/hmat.c | 5 +- hw/acpi/nvdimm.c | 18 +-- hw/acpi/pci.c| 5 +- hw/acpi/vmgenid.c| 4 +- hw/arm/virt-acpi-build.c | 40 --- hw/arm/virt.c| 63 ++ hw/i386/acpi-build.c | 86 +- hw/i386/acpi-common.c| 5 +- hw/i386/acpi-microvm.c | 13 +- hw/i386/microvm.c| 66 +++ hw/i386/pc.c | 64 ++ tests/qtest/bios-tables-test.c | 170 +++ tests/data/acpi/microvm/APIC | Bin 70 -> 70 bytes tests/data/acpi/microvm/APIC.ioapic2 | Bin 82 -> 82 bytes tests/data/acpi/microvm/APIC.pcie| Bin 110 -> 110 bytes tests/data/acpi/microvm/DSDT | Bin 365 -> 365 bytes tests/data/acpi/microvm/DSDT.ioapic2 | Bin 365 -> 365 bytes tests/data/acpi/microvm/DSDT.pcie| Bin 3031 -> 3031 bytes tests/data/acpi/microvm/DSDT.rtc | Bin 404 -> 404 bytes tests/data/acpi/microvm/DSDT.usb | Bin 414 -> 414 bytes tests/data/acpi/microvm/FACP | Bin 268 -> 268 bytes tests/data/acpi/pc/APIC | Bin 120 -> 120 bytes tests/data/acpi/pc/APIC.acpihmat | Bin 128 -> 128 bytes tests/data/acpi/pc/APIC.cphp | Bin 160 -> 160 bytes tests/data/acpi/pc/APIC.dimmpxm | Bin 144 -> 144 bytes tests/data/acpi/pc/DSDT | Bin 5065 -> 5065 bytes tests/data/acpi/pc/DSDT.acpihmat | Bin 6390 -> 6390 bytes tests/data/acpi/pc/DSDT.bridge | Bin 6924 -> 6924 bytes tests/data/acpi/pc/DSDT.cphp | Bin 5529 -> 5529 bytes tests/data/acpi/pc/DSDT.dimmpxm | Bin 6719 -> 6719 bytes tests/data/acpi/pc/DSDT.hpbridge | Bin 5026 -> 5026 bytes tests/data/acpi/pc/DSDT.hpbrroot | Bin 3084 -> 3084 bytes tests/data/acpi/pc/DSDT.ipmikcs | Bin 5137 -> 5137 bytes tests/data/acpi/pc/DSDT.memhp| Bin 6424 -> 6424 bytes tests/data/acpi/pc/DSDT.numamem | Bin 5071 -> 5071 bytes tests/data/acpi/pc/DSDT.roothp | Bin 5261 -> 5261 bytes tests/data/acpi/pc/FACP | Bin 116 -> 116 bytes tests/data/acpi/pc/HMAT.acpihmat | Bin 280 -> 280 bytes tests/data/acpi/pc/HPET | Bin 56 ->
[PATCH v4 4/5] tests/acpi: update expected data files
Signed-off-by: Marian Postevca --- tests/data/acpi/microvm/APIC | Bin 70 -> 70 bytes tests/data/acpi/microvm/APIC.ioapic2 | Bin 82 -> 82 bytes tests/data/acpi/microvm/APIC.pcie| Bin 110 -> 110 bytes tests/data/acpi/microvm/DSDT | Bin 365 -> 365 bytes tests/data/acpi/microvm/DSDT.ioapic2 | Bin 365 -> 365 bytes tests/data/acpi/microvm/DSDT.pcie| Bin 3031 -> 3031 bytes tests/data/acpi/microvm/DSDT.rtc | Bin 404 -> 404 bytes tests/data/acpi/microvm/DSDT.usb | Bin 414 -> 414 bytes tests/data/acpi/microvm/FACP | Bin 268 -> 268 bytes tests/data/acpi/pc/APIC | Bin 120 -> 120 bytes tests/data/acpi/pc/APIC.acpihmat | Bin 128 -> 128 bytes tests/data/acpi/pc/APIC.cphp | Bin 160 -> 160 bytes tests/data/acpi/pc/APIC.dimmpxm | Bin 144 -> 144 bytes tests/data/acpi/pc/DSDT | Bin 5065 -> 5065 bytes tests/data/acpi/pc/DSDT.acpihmat | Bin 6390 -> 6390 bytes tests/data/acpi/pc/DSDT.bridge | Bin 6924 -> 6924 bytes tests/data/acpi/pc/DSDT.cphp | Bin 5529 -> 5529 bytes tests/data/acpi/pc/DSDT.dimmpxm | Bin 6719 -> 6719 bytes tests/data/acpi/pc/DSDT.hpbridge | Bin 5026 -> 5026 bytes tests/data/acpi/pc/DSDT.hpbrroot | Bin 3084 -> 3084 bytes tests/data/acpi/pc/DSDT.ipmikcs | Bin 5137 -> 5137 bytes tests/data/acpi/pc/DSDT.memhp| Bin 6424 -> 6424 bytes tests/data/acpi/pc/DSDT.numamem | Bin 5071 -> 5071 bytes tests/data/acpi/pc/DSDT.roothp | Bin 5261 -> 5261 bytes tests/data/acpi/pc/FACP | Bin 116 -> 116 bytes tests/data/acpi/pc/HMAT.acpihmat | Bin 280 -> 280 bytes tests/data/acpi/pc/HPET | Bin 56 -> 56 bytes tests/data/acpi/pc/NFIT.dimmpxm | Bin 240 -> 240 bytes tests/data/acpi/pc/SLIT.cphp | Bin 48 -> 48 bytes tests/data/acpi/pc/SLIT.memhp| Bin 48 -> 48 bytes tests/data/acpi/pc/SRAT.acpihmat | Bin 280 -> 280 bytes tests/data/acpi/pc/SRAT.cphp | Bin 304 -> 304 bytes tests/data/acpi/pc/SRAT.dimmpxm | Bin 392 -> 392 bytes tests/data/acpi/pc/SRAT.memhp| Bin 264 -> 264 bytes tests/data/acpi/pc/SRAT.numamem | Bin 224 -> 224 bytes tests/data/acpi/pc/SSDT.dimmpxm | Bin 734 -> 734 bytes tests/data/acpi/pc/WAET | Bin 40 -> 40 bytes tests/data/acpi/q35/APIC | Bin 120 -> 120 bytes tests/data/acpi/q35/APIC.acpihmat| Bin 128 -> 128 bytes tests/data/acpi/q35/APIC.cphp| Bin 160 -> 160 bytes tests/data/acpi/q35/APIC.dimmpxm | Bin 144 -> 144 bytes tests/data/acpi/q35/DSDT | Bin 7801 -> 7801 bytes tests/data/acpi/q35/DSDT.acpihmat| Bin 9126 -> 9126 bytes tests/data/acpi/q35/DSDT.bridge | Bin 7819 -> 7819 bytes tests/data/acpi/q35/DSDT.cphp| Bin 8265 -> 8265 bytes tests/data/acpi/q35/DSDT.dimmpxm | Bin 9455 -> 9455 bytes tests/data/acpi/q35/DSDT.ipmibt | Bin 7876 -> 7876 bytes tests/data/acpi/q35/DSDT.memhp | Bin 9160 -> 9160 bytes tests/data/acpi/q35/DSDT.mmio64 | Bin 8932 -> 8932 bytes tests/data/acpi/q35/DSDT.numamem | Bin 7807 -> 7807 bytes tests/data/acpi/q35/DSDT.tis | Bin 8407 -> 8407 bytes tests/data/acpi/q35/FACP | Bin 244 -> 244 bytes tests/data/acpi/q35/HMAT.acpihmat| Bin 280 -> 280 bytes tests/data/acpi/q35/HPET | Bin 56 -> 56 bytes tests/data/acpi/q35/MCFG | Bin 60 -> 60 bytes tests/data/acpi/q35/NFIT.dimmpxm | Bin 240 -> 240 bytes tests/data/acpi/q35/SLIT.cphp| Bin 48 -> 48 bytes tests/data/acpi/q35/SLIT.memhp | Bin 48 -> 48 bytes tests/data/acpi/q35/SRAT.acpihmat| Bin 280 -> 280 bytes tests/data/acpi/q35/SRAT.cphp| Bin 304 -> 304 bytes tests/data/acpi/q35/SRAT.dimmpxm | Bin 392 -> 392 bytes tests/data/acpi/q35/SRAT.memhp | Bin 264 -> 264 bytes tests/data/acpi/q35/SRAT.mmio64 | Bin 224 -> 224 bytes tests/data/acpi/q35/SRAT.numamem | Bin 224 -> 224 bytes tests/data/acpi/q35/SSDT.dimmpxm | Bin 734 -> 734 bytes tests/data/acpi/q35/TPM2.tis | Bin 76 -> 76 bytes tests/data/acpi/q35/WAET | Bin 40 -> 40 bytes tests/data/acpi/virt/APIC| Bin 168 -> 168 bytes tests/data/acpi/virt/APIC.memhp | Bin 168 -> 168 bytes tests/data/acpi/virt/APIC.numamem| Bin 168 -> 168 bytes tests/data/acpi/virt/DSDT| Bin 5204 -> 5204 bytes tests/data/acpi/virt/DSDT.memhp | Bin 6565 -> 6565 bytes tests/data/acpi/virt/DSDT.numamem| Bin 5204 -> 5204 bytes tests/data/acpi/virt/DSDT.pxb| Bin 7689 -> 7689 bytes tests/data/acpi/virt/FACP| Bin 268 -> 268 bytes tests/data/acpi/virt/FACP.memhp | Bin 268 -> 268 bytes tests/data/acpi/virt/FACP.numamem| Bin 268 -> 268 bytes tests/data/acpi/virt/GTDT| Bin 96 -> 96 bytes tests/data/acpi/virt/GTDT.memhp | Bin 96 -> 96 bytes tests/data/acpi/virt/GTDT.numamem| Bin 96 -> 96 bytes tests/data/acpi/virt/MCFG| Bin 60 -> 60 bytes t
[PATCH v4 1/5] tests/acpi: allow updates for expected data files
Signed-off-by: Marian Postevca --- tests/qtest/bios-tables-test-allowed-diff.h | 94 + 1 file changed, 94 insertions(+) diff --git a/tests/qtest/bios-tables-test-allowed-diff.h b/tests/qtest/bios-tables-test-allowed-diff.h index dfb8523c8b..b20ae72949 100644 --- a/tests/qtest/bios-tables-test-allowed-diff.h +++ b/tests/qtest/bios-tables-test-allowed-diff.h @@ -1 +1,95 @@ /* List of comma-separated changed AML files to ignore */ +"tests/data/acpi/virt/APIC", +"tests/data/acpi/virt/FACP", +"tests/data/acpi/virt/GTDT", +"tests/data/acpi/virt/MCFG", +"tests/data/acpi/virt/SPCR", +"tests/data/acpi/virt/DSDT", +"tests/data/acpi/virt/APIC.numamem", +"tests/data/acpi/virt/FACP.numamem", +"tests/data/acpi/virt/GTDT.numamem", +"tests/data/acpi/virt/MCFG.numamem", +"tests/data/acpi/virt/SPCR.numamem", +"tests/data/acpi/virt/DSDT.numamem", +"tests/data/acpi/virt/SRAT.numamem", +"tests/data/acpi/virt/DSDT.memhp", +"tests/data/acpi/virt/NFIT.memhp", +"tests/data/acpi/virt/SSDT.memhp", +"tests/data/acpi/virt/SLIT.memhp", +"tests/data/acpi/virt/SRAT.memhp", +"tests/data/acpi/virt/SPCR.memhp", +"tests/data/acpi/virt/MCFG.memhp", +"tests/data/acpi/virt/GTDT.memhp", +"tests/data/acpi/virt/APIC.memhp", +"tests/data/acpi/virt/FACP.memhp", +"tests/data/acpi/virt/DSDT.pxb", + +"tests/data/acpi/pc/SRAT.acpihmat", +"tests/data/acpi/pc/HPET", +"tests/data/acpi/pc/DSDT.hpbrroot", +"tests/data/acpi/pc/SRAT.numamem", +"tests/data/acpi/pc/DSDT.dimmpxm", +"tests/data/acpi/pc/DSDT.acpihmat", +"tests/data/acpi/pc/FACP", +"tests/data/acpi/pc/SRAT.cphp", +"tests/data/acpi/pc/DSDT.numamem", +"tests/data/acpi/pc/DSDT.bridge", +"tests/data/acpi/pc/HMAT.acpihmat", +"tests/data/acpi/pc/DSDT.cphp", +"tests/data/acpi/pc/APIC.dimmpxm", +"tests/data/acpi/pc/SRAT.memhp", +"tests/data/acpi/pc/SLIT.cphp", +"tests/data/acpi/pc/DSDT.hpbridge", +"tests/data/acpi/pc/NFIT.dimmpxm", +"tests/data/acpi/pc/APIC.cphp", +"tests/data/acpi/pc/SSDT.dimmpxm", +"tests/data/acpi/pc/SRAT.dimmpxm", +"tests/data/acpi/pc/APIC.acpihmat", +"tests/data/acpi/pc/DSDT.memhp", +"tests/data/acpi/pc/DSDT.ipmikcs", +"tests/data/acpi/pc/SLIT.memhp", +"tests/data/acpi/pc/WAET", +"tests/data/acpi/pc/DSDT", +"tests/data/acpi/pc/APIC", +"tests/data/acpi/pc/DSDT.roothp", + +"tests/data/acpi/q35/SRAT.acpihmat", +"tests/data/acpi/q35/HPET", +"tests/data/acpi/q35/SRAT.numamem", +"tests/data/acpi/q35/DSDT.dimmpxm", +"tests/data/acpi/q35/DSDT.acpihmat", +"tests/data/acpi/q35/FACP", +"tests/data/acpi/q35/DSDT.mmio64", +"tests/data/acpi/q35/SRAT.cphp", +"tests/data/acpi/q35/DSDT.numamem", +"tests/data/acpi/q35/DSDT.bridge", +"tests/data/acpi/q35/HMAT.acpihmat", +"tests/data/acpi/q35/DSDT.cphp", +"tests/data/acpi/q35/APIC.dimmpxm", +"tests/data/acpi/q35/SRAT.memhp", +"tests/data/acpi/q35/SLIT.cphp", +"tests/data/acpi/q35/NFIT.dimmpxm", +"tests/data/acpi/q35/APIC.cphp", +"tests/data/acpi/q35/SSDT.dimmpxm", +"tests/data/acpi/q35/SRAT.dimmpxm", +"tests/data/acpi/q35/APIC.acpihmat", +"tests/data/acpi/q35/MCFG", +"tests/data/acpi/q35/DSDT.memhp", +"tests/data/acpi/q35/SLIT.memhp", +"tests/data/acpi/q35/WAET", +"tests/data/acpi/q35/DSDT.ipmibt", +"tests/data/acpi/q35/DSDT.tis", +"tests/data/acpi/q35/SRAT.mmio64", +"tests/data/acpi/q35/TPM2.tis", +"tests/data/acpi/q35/DSDT", +"tests/data/acpi/q35/APIC", + +"tests/data/acpi/microvm/APIC.pcie", +"tests/data/acpi/microvm/DSDT.pcie", +"tests/data/acpi/microvm/DSDT.usb", +"tests/data/acpi/microvm/DSDT.rtc", +"tests/data/acpi/microvm/FACP", +"tests/data/acpi/microvm/APIC.ioapic2", +"tests/data/acpi/microvm/DSDT.ioapic2", +"tests/data/acpi/microvm/DSDT", +"tests/data/acpi/microvm/APIC", -- 2.26.2
Re: [PATCH v3] hvf: guard xgetbv call.
gentle bump :)
On Tue, Jan 12, 2021 at 10:07 PM Hill Ma wrote:
>
> This prevents illegal instruction on cpus do not support xgetbv.
>
> Buglink: https://bugs.launchpad.net/qemu/+bug/1758819
> Signed-off-by: Hill Ma
> ---
> v3: addressed feedback.
> v2: xgetbv() modified based on feedback.
>
> target/i386/hvf/x86_cpuid.c | 34 ++
> 1 file changed, 22 insertions(+), 12 deletions(-)
>
> diff --git a/target/i386/hvf/x86_cpuid.c b/target/i386/hvf/x86_cpuid.c
> index a6842912f5..32b0d131df 100644
> --- a/target/i386/hvf/x86_cpuid.c
> +++ b/target/i386/hvf/x86_cpuid.c
> @@ -27,15 +27,22 @@
> #include "vmx.h"
> #include "sysemu/hvf.h"
>
> -static uint64_t xgetbv(uint32_t xcr)
> +static bool xgetbv(uint32_t cpuid_ecx, uint32_t idx, uint64_t *xcr)
> {
> -uint32_t eax, edx;
> +uint32_t xcrl, xcrh;
>
> -__asm__ volatile ("xgetbv"
> - : "=a" (eax), "=d" (edx)
> - : "c" (xcr));
> +if (cpuid_ecx & CPUID_EXT_OSXSAVE) {
> +/*
> + * The xgetbv instruction is not available to older versions of
> + * the assembler, so we encode the instruction manually.
> + */
> +asm(".byte 0x0f, 0x01, 0xd0" : "=a" (xcrl), "=d" (xcrh) : "c" (idx));
>
> -return (((uint64_t)edx) << 32) | eax;
> +*xcr = (((uint64_t)xcrh) << 32) | xcrl;
> +return true;
> +}
> +
> +return false;
> }
>
> uint32_t hvf_get_supported_cpuid(uint32_t func, uint32_t idx,
> @@ -100,12 +107,15 @@ uint32_t hvf_get_supported_cpuid(uint32_t func,
> uint32_t idx,
> break;
> case 0xD:
> if (idx == 0) {
> -uint64_t host_xcr0 = xgetbv(0);
> -uint64_t supp_xcr0 = host_xcr0 & (XSTATE_FP_MASK |
> XSTATE_SSE_MASK |
> - XSTATE_YMM_MASK | XSTATE_BNDREGS_MASK |
> - XSTATE_BNDCSR_MASK | XSTATE_OPMASK_MASK |
> - XSTATE_ZMM_Hi256_MASK |
> XSTATE_Hi16_ZMM_MASK);
> -eax &= supp_xcr0;
> +uint64_t host_xcr0;
> +if (xgetbv(ecx, 0, &host_xcr0)) {
> +uint64_t supp_xcr0 = host_xcr0 & (XSTATE_FP_MASK |
> + XSTATE_SSE_MASK | XSTATE_YMM_MASK |
> + XSTATE_BNDREGS_MASK | XSTATE_BNDCSR_MASK |
> + XSTATE_OPMASK_MASK | XSTATE_ZMM_Hi256_MASK
> |
> + XSTATE_Hi16_ZMM_MASK);
> +eax &= supp_xcr0;
> +}
> } else if (idx == 1) {
> hv_vmx_read_capability(HV_VMX_CAP_PROCBASED2, &cap);
> eax &= CPUID_XSAVE_XSAVEOPT | CPUID_XSAVE_XGETBV1;
> --
> 2.20.1 (Apple Git-117)
>
Re: [PATCH 7/7] block/rbd: change request alignment to 1 byte
On Fri, Jan 15, 2021 at 10:39 AM Peter Lieven wrote:
>
> Am 15.01.21 um 16:27 schrieb Jason Dillaman:
> > On Thu, Jan 14, 2021 at 2:59 PM Peter Lieven wrote:
> >> Am 14.01.21 um 20:19 schrieb Jason Dillaman:
> >>> On Sun, Dec 27, 2020 at 11:42 AM Peter Lieven wrote:
> since we implement byte interfaces and librbd supports aio on byte
> granularity we can lift
> the 512 byte alignment.
>
> Signed-off-by: Peter Lieven
> ---
> block/rbd.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/block/rbd.c b/block/rbd.c
> index 27b4404adf..8673e8f553 100644
> --- a/block/rbd.c
> +++ b/block/rbd.c
> @@ -223,8 +223,6 @@ done:
> static void qemu_rbd_refresh_limits(BlockDriverState *bs, Error **errp)
> {
> BDRVRBDState *s = bs->opaque;
> -/* XXX Does RBD support AIO on less than 512-byte alignment? */
> -bs->bl.request_alignment = 512;
> >>> Just a suggestion, but perhaps improve discard alignment, max discard,
> >>> optimal alignment (if that's something QEMU handles internally) if not
> >>> overridden by the user.
> >>
> >> Qemu supports max_discard and discard_alignment. Is there a call to get
> >> these limits
> >>
> >> from librbd?
> >>
> >>
> >> What do you mean by optimal_alignment? The object size?
> > krbd does a good job of initializing defaults [1] where optimal and
> > discard alignment is 64KiB (can actually be 4KiB now), max IO size for
> > writes, discards, and write-zeroes is the object size * the stripe
> > count.
>
>
> Okay, I will have a look at it. If qemu issues a write, discard, write_zero
> greater than
>
> obj_size * stripe count will librbd split it internally or will the request
> fail?
librbd will handle it as needed. My goal is really just to get the
hints down the guest OS.
> Regarding the alignment it seems that rbd_dev->opts->alloc_size is something
> that comes from the device
>
> configuration and not from rbd? I don't have that information inside the Qemu
> RBD driver.
librbd doesn't really have the information either. The 64KiB guess
that krbd uses was a compromise since that was the default OSD
allocation size for HDDs since Luminous. Starting with Pacific that
default is going down to 4KiB.
>
> Peter
>
>
--
Jason
Re: [RFC PATCH V2 00/11] hw/block/nvme: support multi-path for ctrl/ns
On Jan 17 23:53, Minwoo Im wrote: > Hello, > > This patch series introduces NVMe subsystem device to support multi-path > I/O in NVMe device model. Two use-cases are supported along with this > patch: Multi-controller, Namespace Sharing. > > V1 RFC has been discussed with Klaus and Keith, I really appreciate them > for this patch series to have proper direction [1]. > > This patch series contains few start-up refactoring pathces from the > first to fifth patches to make nvme-ns device not to rely on the nvme > controller always. Because nvme-ns shall be able to be mapped to the > subsystem level, not a single controller level so that it should provide > generic initialization code: nvme_ns_setup() with NvmeCtrl. To do that, > the first five patches are to remove the NvmeCtrl * instance argument > from the nvme_ns_setup(). I'd be happy if they are picked! > > For controller and namespace devices, 'subsys' property has been > introduced to map them to a subsystem. If multi-controller needed, we > can specify 'subsys' to controllers the same. > > For namespace deivice, if 'subsys' is not given just like it was, it > will have to be provided with 'bus' parameter to specify a nvme > controller device to attach, it means, they are mutual-exlusive. To > share a namespace between or among controllers, then nvme-ns should have > 'subsys' property to a single nvme subsystem instance. To make a > namespace private one, then we need to specify 'bus' property rather > than the 'subsys'. > > Of course, this series does not require any updates for the run command > for the previos users. > > Plase refer the following example with nvme-cli output: > > QEMU Run: > -device nvme-subsys,id=subsys0 \ > -device nvme,serial=foo,id=nvme0,subsys=subsys0 \ > -device nvme,serial=bar,id=nvme1,subsys=subsys0 \ > -device nvme,serial=baz,id=nvme2,subsys=subsys0 \ > -device nvme-ns,id=ns1,drive=drv10,nsid=1,subsys=subsys0 \ > -device nvme-ns,id=ns2,drive=drv11,nsid=2,bus=nvme2 \ > \ > -device nvme,serial=qux,id=nvme3 \ > -device nvme-ns,id=ns3,drive=drv12,nsid=3,bus=nvme3 > > nvme-cli: > root@vm:~/work# nvme list -v > NVM Express Subsystems > > SubsystemSubsystem-NQN > Controllers > > > > nvme-subsys1 nqn.2019-08.org.qemu:subsys0 > nvme0, nvme1, nvme2 > nvme-subsys3 nqn.2019-08.org.qemu:qux > nvme3 > > NVM Express Controllers > > Device SN MN FR > TxPort AddressSubsystemNamespaces > > -- -- > nvme0foo QEMU NVMe Ctrl 1.0 > pcie :00:06.0 nvme-subsys1 nvme1n1 > nvme1bar QEMU NVMe Ctrl 1.0 > pcie :00:07.0 nvme-subsys1 nvme1n1 > nvme2baz QEMU NVMe Ctrl 1.0 > pcie :00:08.0 nvme-subsys1 nvme1n1, nvme1n2 > nvme3qux QEMU NVMe Ctrl 1.0 > pcie :00:09.0 nvme-subsys3 > > NVM Express Namespaces > > Device NSID Usage Format > Controllers > -- > > nvme1n1 1134.22 MB / 134.22 MB512 B + 0 B nvme0, > nvme1, nvme2 > nvme1n2 2268.44 MB / 268.44 MB512 B + 0 B nvme2 > nvme3n1 3268.44 MB / 268.44 MB512 B + 0 B nvme3 > > Summary: > - Refactored nvme-ns device not to rely on controller during the > setup. [1/11 - 5/11] > - Introduced a nvme-subsys device model. [6/11] > - Create subsystem NQN based on subsystem. [7/11] > - Introduced multi-controller model. [8/11 - 9/11] > - Updated namespace sharing scheme to be based on nvme-subsys > hierarchy. [10/11 - 11/11] > > Since RFC V1: > - Updated namespace sharing scheme to be based on nvme-subsys > hierarchy. > Great stuff Minwoo. Thanks! I'll pick up [01-05/11] directly since they are pretty trivial. The subsystem model looks pretty much like it should, I don't have a lot of comments. One thing that I considered, is if we should reverse the "registration" and think about it as namespace attachment. The spec is about controllers attaching to namespaces, not the other way around. Basically, let the namespaces be configured first and register on the subsystem (accumulating in a "namespaces" array), then have the
Re: [PULL 11/24] tcg/optimize: Use tcg_constant_internal with constant folding
On 1/18/21 10:17 AM, Laurent Vivier wrote:
> This commit breaks the build of my hello world test program with
> mips64el/stretch guest
> (and I guess some others too).
>
> cat > $CHROOT/tmp/hello.c < #include
> int main(void)
> {
> printf("Hello World!\n");
> return 0;
> }
> EOF
>
> unshare --time --ipc --uts --pid --fork --kill-child --mount --mount-proc
> --root \
> $CHROOT gcc /tmp/hello.c -o /tmp/hello
> /tmp/hello.c:1:0: internal compiler error: Segmentation fault
> #include
>
> executable file is not ELF
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See for instructions.
>
> # gcc --version
> gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
> Copyright (C) 2016 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> Any idea?
Working on it:
https://bugs.launchpad.net/bugs/1912065
There's a temp hack in there that may work for you. With no change, you'll see
an assert instead of a segv if you --enable-debug-tcg.
r~
Re: [PULL 11/24] tcg/optimize: Use tcg_constant_internal with constant folding
On 16/01/2021 18:24, Richard Henderson wrote:
> On 1/15/21 1:03 PM, Alistair Francis wrote:
>> I run QEMU with these arguments:
>>
>> ./build/riscv32-softmmu/qemu-system-riscv32 \
>> -machine virt -serial mon:stdio -serial null -nographic \
>> -append "root=/dev/vda rw highres=off console=ttyS0 ip=dhcp
>> earlycon=sbi" \
>> -device virtio-net-device,netdev=net0,mac=52:54:00:12:34:02
>> -netdev user,id=net0 \
>> -object rng-random,filename=/dev/urandom,id=rng0 -device
>> virtio-rng-device,rng=rng0 \
>> -smp 4 -d guest_errors -m 256M \
>> -kernel ./Image \
>> -drive
>> id=disk0,file=./core-image-minimal-qemuriscv32.ext4,if=none,format=raw
>> \
>> -device virtio-blk-device,drive=disk0 \
>> -bios default
>>
>> I am uploading the images to:
>> https://nextcloud.alistair23.me/index.php/s/MQFyGGNLPZjLZPH
>
> I don't replicate the assertion failure, I get to
>
> /sbin/init: error while loading shared libraries: libkmod.so.2: cannot open
> shared object file: Error 74
> [0.819845] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x7f00
> [0.820430] CPU: 1 PID: 1 Comm: init Not tainted 5.11.0-rc3 #1
This commit breaks the build of my hello world test program with
mips64el/stretch guest
(and I guess some others too).
cat > $CHROOT/tmp/hello.c <
int main(void)
{
printf("Hello World!\n");
return 0;
}
EOF
unshare --time --ipc --uts --pid --fork --kill-child --mount --mount-proc
--root \
$CHROOT gcc /tmp/hello.c -o /tmp/hello
/tmp/hello.c:1:0: internal compiler error: Segmentation fault
#include
executable file is not ELF
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
# gcc --version
gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Any idea?
Thanks,
Laurent
Re: [RFC PATCH v2 10/20] hw/usb/hcd-ohci: Mark the device with no migratable fields
* Philippe Mathieu-Daudé (f4...@amsat.org) wrote:
> This device doesn't have fields to migrate. Be explicit
> by using vmstate_qdev_no_state_to_migrate.
>
> Add a more descriptive comment to keep a clear separation
> between static property vs runtime changeable.
>
> Signed-off-by: Philippe Mathieu-Daudé
OK,
Reviewed-by: Dr. David Alan Gilbert
although I think it's quite interesting; I think we have
a base class which has data to migrate which expects any
child classes to migrate it's data; so marking it as
not actually having any state is not quite right.
> ---
> hw/usb/hcd-ohci.h | 2 ++
> hw/usb/hcd-ohci.c | 1 +
> 2 files changed, 3 insertions(+)
>
> diff --git a/hw/usb/hcd-ohci.h b/hw/usb/hcd-ohci.h
> index 11ac57058d1..fd4842a352f 100644
> --- a/hw/usb/hcd-ohci.h
> +++ b/hw/usb/hcd-ohci.h
> @@ -101,6 +101,8 @@ struct OHCISysBusState {
> /*< public >*/
>
> OHCIState ohci;
> +
> +/* Properties */
> char *masterbus;
> uint32_t num_ports;
> uint32_t firstport;
> diff --git a/hw/usb/hcd-ohci.c b/hw/usb/hcd-ohci.c
> index f8c64c8b95b..302aab30992 100644
> --- a/hw/usb/hcd-ohci.c
> +++ b/hw/usb/hcd-ohci.c
> @@ -2007,6 +2007,7 @@ static void ohci_sysbus_class_init(ObjectClass *klass,
> void *data)
> DeviceClass *dc = DEVICE_CLASS(klass);
>
> dc->realize = ohci_realize_pxa;
> +dc->vmsd = vmstate_qdev_no_state_to_migrate;
> set_bit(DEVICE_CATEGORY_USB, dc->categories);
> dc->desc = "OHCI USB Controller";
> device_class_set_props(dc, ohci_sysbus_properties);
> --
> 2.26.2
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [RFC PATCH V2 05/11] hw/block/nvme: remove unused argument in nvme_ns_setup
On Jan 17 23:53, Minwoo Im wrote: > nvme_ns_setup() finally does not have nothing to do with NvmeCtrl > instance. > > Signed-off-by: Minwoo Im I also think this *could* be squashed into [04/11] without too much strain on the eye, but Reviewed-by: Klaus Jensen signature.asc Description: PGP signature
Re: [RFC PATCH V2 10/11] hw/block/nvme: add NMIC enum value for Identify Namespace
On Jan 17 23:53, Minwoo Im wrote:
> Added Namespace Multi-path I/O and Namespace Sharing Capabilities (NMIC)
> field to support shared namespace from controller(s).
>
> This field is in Identify Namespace data structure in [30].
>
> Signed-off-by: Minwoo Im
> ---
> include/block/nvme.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/include/block/nvme.h b/include/block/nvme.h
> index e83ec1e124c6..dd7b5ba9ef4c 100644
> --- a/include/block/nvme.h
> +++ b/include/block/nvme.h
> @@ -1110,6 +1110,10 @@ enum NvmeNsIdentifierType {
> NVME_NIDT_CSI = 0x04,
> };
>
> +enum NvmeNsNmic {
> +NVME_NMIC_NS_SHARED = 1 << 0,
> +};
> +
Let's keep convention (or should be convention...) of using NvmeIdNs
prefix for identify data structure fields on the enum.
signature.asc
Description: PGP signature
Re: [RFC PATCH V2 04/11] hw/block/nvme: split setup and register for namespace
On Jan 17 23:53, Minwoo Im wrote: > In NVMe, namespace is being attached to process I/O. We register NVMe > namespace to a controller via nvme_register_namespace() during > nvme_ns_setup(). This is main reason of receiving NvmeCtrl object > instance to this function to map the namespace to a controller. > > To make namespace instance more independent, it should be split into two > parts: setup and register. This patch split them into two differnt > parts, and finally nvme_ns_setup() does not have nothing to do with > NvmeCtrl instance at all. > > This patch is a former patch to introduce NVMe subsystem scheme to the > existing design especially for multi-path. In that case, it should be > split into two to make namespace independent from a controller. > > Signed-off-by: Minwoo Im Reviewed-by: Klaus Jensen signature.asc Description: PGP signature
Re: [PATCH 1/1] linux-user/syscall: Fix do_ioctl_ifconf() for 64 bit targets.
Hi Laurent!
Thanks for your response.
> Why don't you simply replace STRUCT_sockaddr_ifreq by STRUCT_ifmap_ifreq
> rather than introducing a
> new constant?
Because STRUCT_sockaddr_ifreq is the union part to be filled and is needed as
an argument to thunk_convert() in this loop below:
for (i = 0; i < nb_ifreq ; i++) {
thunk_convert(argptr + i * target_ifreq_size,
host_ifc_buf + i * sizeof(struct ifreq),
ifreq_arg_type, THUNK_TARGET);
}
> In the "if (!is_error(ret))", why don't you use the same size with the part
> that copies back the
> values to the user?
I’m not sure if I understand your question correctly. Well, ioclt(…,
SIOCGIFCONF, …) returns an array of struct ifreq, which contains a union, of
which only struct sockaddr ifr_addr needs to be filled. But that union element
is not the biggest element on 64 bit architectures.
Without the fix the returned data is not an array of struct ifreq but an array
of some artificial struct:
struct sockaddr_ifreq {
char ifr_name[IFNAMSIZ]; /* Interface name */
struct sockaddr ifr_addr;
}
That artificial struct is too short for 64 bit architectures. On real x86_64
systems the size of the array returned by ioclt(…, SIOCGIFCONF, …) is a
multiple of 40 bytes, the sizeof(struct ifreq). And it’s also a multiple of 40
on real aarch64 systems. However, on x86_64 emulating aarch64 with qemu, the
returned array size is only a multiple of 32 bytes, which is wrong. It is
enough to fill only 32 bytes with thunk_convert() and ifreq_arg_type is also
the proper type, but the array element increase has to be 40 bytes.
I hope this clarifies your question.
Bye
Stefan
Re: [RFC PATCH V2 03/11] hw/block/nvme: remove unused argument in nvme_ns_init_blk
On Jan 17 23:53, Minwoo Im wrote: > Removed no longer used aregument NvmeCtrl object in nvme_ns_init_blk(). > > Signed-off-by: Minwoo Im I don't think it's too unwieldy for this to be squashed into [02/11], but Reviewed-by: Klaus Jensen signature.asc Description: PGP signature
Re: [RFC PATCH V2 02/11] hw/block/nvme: open code for volatile write cache
On Jan 17 23:53, Minwoo Im wrote: > Volatile Write Cache(VWC) feature is set in nvme_ns_setup() in the > initial time. This feature is related to block device backed, but this > feature is controlled in controller level via Set/Get Features command. > > This patch removed dependency between nvme and nvme-ns to manage the VWC > flag value. Also, it open coded the Get Features for VWC to check all > namespaces attached to the controller, and if false detected, return > directly false. > > Signed-off-by: Minwoo Im The VWC feature really should be namespace specific. I wonder why they didn't fix that when they added an NSID to the Flush command... Anyway, this is much better. Reviewed-by: Klaus Jensen signature.asc Description: PGP signature
Re: [RFC PATCH V2 01/11] hw/block/nvme: remove unused argument in nvme_ns_init_zoned
On Jan 17 23:53, Minwoo Im wrote: > nvme_ns_init_zoned() has no use for given NvmeCtrl object. > > Signed-off-by: Minwoo Im Reviewed-by: Klaus Jensen signature.asc Description: PGP signature
Re: [PATCH v2 02/12] hw/block/nvme: fix 64 bit register hi/lo split writes
On Jan 18 21:59, Minwoo Im wrote: > > The spec requires aligned 32 bit accesses (or the size of the register), > > so maybe it's about time we actually ignore instead of falling through. > > Agreed. > On the other hand. The spec just allows undefined behavior if the alignment or size requirement is violated. So falling through is not wrong. Keith, any thoughts on this? signature.asc Description: PGP signature
Re: [PATCH v7 07/13] confidential guest support: Introduce cgs "ready" flag
* David Gibson (da...@gibson.dropbear.id.au) wrote:
> The platform specific details of mechanisms for implementing
> confidential guest support may require setup at various points during
> initialization. Thus, it's not really feasible to have a single cgs
> initialization hook, but instead each mechanism needs its own
> initialization calls in arch or machine specific code.
>
> However, to make it harder to have a bug where a mechanism isn't
> properly initialized under some circumstances, we want to have a
> common place, relatively late in boot, where we verify that cgs has
> been initialized if it was requested.
>
> This patch introduces a ready flag to the ConfidentialGuestSupport
> base type to accomplish this, which we verify just before the machine
> specific initialization function.
You may find you need to define 'ready' and the answer might be a bit
variable; for example, on SEV there's a setup bit and then you may end
up doing an attestation and receiving some data before you actaully let
the guest execute code. Is it ready before it's received the
attestation response or only when it can run code?
Is a Power or 390 machine 'ready' before it's executed the magic
instruction to enter the confidential mode?
Dave
> Signed-off-by: David Gibson
> ---
> hw/core/machine.c | 8
> include/exec/confidential-guest-support.h | 2 ++
> target/i386/sev.c | 2 ++
> 3 files changed, 12 insertions(+)
>
> diff --git a/hw/core/machine.c b/hw/core/machine.c
> index 94194ab82d..5a742b 100644
> --- a/hw/core/machine.c
> +++ b/hw/core/machine.c
> @@ -1190,6 +1190,14 @@ void machine_run_board_init(MachineState *machine)
> }
>
> if (machine->cgs) {
> +/*
> + * Where confidential guest support is initialized depends on
> + * the specific mechanism in use. But, we need to make sure
> + * it's ready by now. If it isn't, that's a bug in the
> + * implementation of that cgs mechanism.
> + */
> +assert(machine->cgs->ready);
> +
> /*
> * With confidential guests, the host can't see the real
> * contents of RAM, so there's no point in it trying to merge
> diff --git a/include/exec/confidential-guest-support.h
> b/include/exec/confidential-guest-support.h
> index 5f131023ba..bcaf6c9f49 100644
> --- a/include/exec/confidential-guest-support.h
> +++ b/include/exec/confidential-guest-support.h
> @@ -27,6 +27,8 @@ OBJECT_DECLARE_SIMPLE_TYPE(ConfidentialGuestSupport,
> CONFIDENTIAL_GUEST_SUPPORT)
>
> struct ConfidentialGuestSupport {
> Object parent;
> +
> +bool ready;
> };
>
> typedef struct ConfidentialGuestSupportClass {
> diff --git a/target/i386/sev.c b/target/i386/sev.c
> index e2b41ef342..3d94635397 100644
> --- a/target/i386/sev.c
> +++ b/target/i386/sev.c
> @@ -737,6 +737,8 @@ int sev_kvm_init(ConfidentialGuestSupport *cgs, Error
> **errp)
> qemu_add_machine_init_done_notifier(&sev_machine_done_notify);
> qemu_add_vm_change_state_handler(sev_vm_state_change, sev);
>
> +cgs->ready = true;
> +
> return 0;
> err:
> sev_guest = NULL;
> --
> 2.29.2
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
[PATCH v2 1/1] spapr.c: always pulse guest IRQ in spapr_core_unplug_request()
Commit 47c8c915b162 fixed a problem where multiple spapr_drc_detach()
requests were breaking QEMU. The solution was to just spapr_drc_detach()
once, and use spapr_drc_unplug_requested() to filter whether we
already detached it or not. The commit also tied the hotplug request
to the guest in the same condition.
Turns out that there is a reliable way for a CPU hotunplug to fail. If
a guest with one CPU hotplugs a CPU1, then offline CPU0s via
'echo 0 > /sys/devices/system/cpu/cpu0/online', then attempts to
hotunplug CPU1, the kernel will refuse it because it's the last online
CPU of the system. Given that we're pulsing the IRQ only in the first try,
in a failed attempt, all other CPU1 hotunplug attempts will fail, regardless
of the online state of CPU1 in the kernel, because we're simply not letting
the guest know that we want to hotunplug the device.
Let's move spapr_hotplug_req_remove_by_index() back out of the
"if (!spapr_drc_unplug_requested(drc))" conditional, allowing for multiple
'device_del' requests to the same CPU core to reach the guest, in case
the CPU core didn't fully hotunplugged previously. Granted, this is not
optimal because this can allow for multiple hotplug events queueing in the
guest, like it was already possible before 47c8c915b162.
Other possible alternatives would be:
- check if the given CPU is the last online CPU in the guest before attempting
to hotunplug. This can be done by checking 'cs->halted' and msr states of
the core. Problem is, this approach will fail if the guest offlines/onlines
a CPU while we're in the middle of the unplug request, given that we can't
control whether the CPU core states will change in the kernel. This option
sure makes it harder to allow a hotunplug failure to happen, but will never
be enough to fully avoid it;
- let the user handled it. In this case, we would advise the user to reboot the
guest and the CPU will be removed during machine reset.
None of the alternatives are clear winnners, so this patch goes for the approach
makes the IRQ queue of the guest prone to multiple hotunplug requests for the
same CPU, but at least the user can successfully hotunplug the CPU after a
failed
attempt, without the need of guest reboot.
Reported-by: Xujun Ma
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1911414
Signed-off-by: Daniel Henrique Barboza
---
hw/ppc/spapr.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index e9e3816cd3..e2f12ce413 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -3737,8 +3737,17 @@ void spapr_core_unplug_request(HotplugHandler
*hotplug_dev, DeviceState *dev,
if (!spapr_drc_unplug_requested(drc)) {
spapr_drc_detach(drc);
-spapr_hotplug_req_remove_by_index(drc);
}
+
+/*
+ * spapr_hotplug_req_remove_by_index is left unguarded, out of the
+ * "!spapr_drc_unplug_requested" check, to allow for multiple IRQ
+ * pulses removing the same CPU core. Otherwise, in an failed hotunplug
+ * attempt (e.g. the kernel will refuse to remove the last online CPU
+ * core), we will never attempt it again because unplug_requested will
+ * still be 'true' in that case.
+ */
+spapr_hotplug_req_remove_by_index(drc);
}
int spapr_core_dt_populate(SpaprDrc *drc, SpaprMachineState *spapr,
--
2.26.2
[PATCH v2 0/1] pseries: allow CPU unplug after failed attempt
Hi, This is a different approach to the problem after reviews from David and Greg. See the commit msg for the reasoning behind it. changes from v1: - Patches 1,2,4 and 5: applied to ppc-for-6.0 - Patches 3, 6 and 7: removed - new patch: always pulse guest IRQ in spapr_core_unplug_request() v1 link: https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg03349.html Daniel Henrique Barboza (1): spapr.c: always pulse guest IRQ in spapr_core_unplug_request() hw/ppc/spapr.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) -- 2.26.2
Re: [PATCH v2 10/12] hw/block/nvme: move cmb logic to v1.4
On Jan 18 14:22, Klaus Jensen wrote:
> On Jan 18 22:12, Minwoo Im wrote:
> > On 21-01-18 14:10:50, Klaus Jensen wrote:
> > > On Jan 18 22:09, Minwoo Im wrote:
> > > > > > Yes, CMB in v1.4 is not backward-compatible, but is it okay to move
> > > > > > onto
> > > > > > the CMB v1.4 from v1.3 without supporting the v1.3 usage on this
> > > > > > device
> > > > > > model?
> > > > >
> > > > > Next patch moves to v1.4. I wanted to split it because the "bump"
> > > > > patch
> > > > > also adds a couple of other v1.4 requires fields. But I understand
> > > > > that
> > > > > this is slightly wrong.
> > > >
> > > > Sorry, I meant I'd like to have CMB for v1.3 support along with the v1.4
> > > > support in this device model separately. Maybe I missed the linux-nvme
> > > > mailing list for CMB v1.4, but is there no plan to keep supportin CMB
> > > > v1.3 in NVMe driver?
> > >
> > > I posted a patch on linux-nvme for v1.4 support in the kernel. It will
> > > support both the v1.3 and v1.4 behavior :)
> >
> > Then, can we maintain CMB v1.3 also in QEMU also along with v1.4 ? :)
>
> My first version of this patch actually included compatibility support
> for v1.3 ("legacy cmb"), but Keith suggested we just drop that and keep
> this device compliant.
>
> What we could do is allow the spec version to be chosen with a
> parameter?
Uhm. Maybe not. I gave this some more thought.
Adding a device parameter to choose the specification version requires
us to maintain QEMU "compat" properties across different QEMU version.
I'm not sure we want that for something like this.
Maybe the best course of action actually *is* an 'x-legacy-cmb'
parameter.
signature.asc
Description: PGP signature
Re: [Bug 1912065] Re: Segfaults in tcg/optimize.c:212 after commit 7c79721606be11b5bc556449e5bcbc331ef6867d
On 1/18/21 8:00 AM, no-re...@patchew.org wrote: > Patchew URL: > https://patchew.org/QEMU/161099084144.30067.897245088295398204.mal...@chaenomeles.canonical.com/ Can we get patchew to not respond to launchpad threads? r~
Re: Fwd: VirtioSound device emulation implementation
I will make it an in-QEMU pci device. After it is done and the device is working, I can write a vhost-user daemon and move the device out of QEMU should it be needed. This way I'd already have the virtio-pci device tested out by the time I get to the vhost-user daemon. Also I'll be a lot more familiar to sound and virtio devices by then hopefully. I hope this is fine? As for the implementation plan, I will start out by writing the structure for the device, `VirtIOSnd` or `VirtIOSound`. Since QEMU already has a base `VirtIODevice` with common implementation along with the `VirtQueue`s, this shouldn't be very difficult. Following this I will start implementing the methods mentioned in the `VirtIODeviceClass`. This would include creating a separate `virtio-sound-pci.c` file with the `realize`, `unrealize` and various init functions. After that, I will start writing the `get`, `set` and validate functions mentioned in the `VirtioDeviceClass`. QEMU already has an implementation for `start_ioeventfd` and `stop_ioeventfd`. This should get us done with the configuration plane. I am thinking of writing a few tests at this point. I will have to read about the qtest framework first though. This should take at most around a month. I am hoping to get it done earlier than that time (~3 weeks) if things go well. From this most of the time goes to tests. I am taking a bit of a margin to err on the side of caution. This now brings us to the dataplane and processing of the data. I think once the data plane is successfully implemented, processing shouldn't take a lot of time. Once the control queue, event queue, tx queue and rx queues are implemented, I can start implementing the Jack and PCM control requests. I can write tests after completing each of these phases. As of right now, I am not awake enough to give a clear plan on the data plane implementation. I will clear the plan out tomorrow. The dataplane along with the processing should at most take a little over a month to implement I'd guess. I will make sure I write a follow up mail tomorrow with a clearer and complete plan. Apologies for any statements that weren't very clear or mistakes in the language that I used. - Shreyansh Chouhan
Re: [PATCH v7 02/13] confidential guest support: Introduce new confidential guest support class
* David Gibson (da...@gibson.dropbear.id.au) wrote:
> Several architectures have mechanisms which are designed to protect guest
> memory from interference or eavesdropping by a compromised hypervisor. AMD
> SEV does this with in-chip memory encryption and Intel's MKTME can do
^
(and below) My understanding is that it's Intel TDX that's the VM
equivalent.
Dave
> similar things. POWER's Protected Execution Framework (PEF) accomplishes a
> similar goal using an ultravisor and new memory protection features,
> instead of encryption.
>
> To (partially) unify handling for these, this introduces a new
> ConfidentialGuestSupport QOM base class. "Confidential" is kind of vague,
> but "confidential computing" seems to be the buzzword about these schemes,
> and "secure" or "protected" are often used in connection to unrelated
> things (such as hypervisor-from-guest or guest-from-guest security).
>
> The "support" in the name is significant because in at least some of the
> cases it requires the guest to take specific actions in order to protect
> itself from hypervisor eavesdropping.
>
> Signed-off-by: David Gibson
> ---
> backends/confidential-guest-support.c | 33
> backends/meson.build | 1 +
> include/exec/confidential-guest-support.h | 38 +++
> include/qemu/typedefs.h | 1 +
> target/i386/sev.c | 3 +-
> 5 files changed, 75 insertions(+), 1 deletion(-)
> create mode 100644 backends/confidential-guest-support.c
> create mode 100644 include/exec/confidential-guest-support.h
>
> diff --git a/backends/confidential-guest-support.c
> b/backends/confidential-guest-support.c
> new file mode 100644
> index 00..9b0ded0db4
> --- /dev/null
> +++ b/backends/confidential-guest-support.c
> @@ -0,0 +1,33 @@
> +/*
> + * QEMU Confidential Guest support
> + *
> + * Copyright: David Gibson, Red Hat Inc. 2020
> + *
> + * Authors:
> + * David Gibson
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or
> + * later. See the COPYING file in the top-level directory.
> + *
> + */
> +
> +#include "qemu/osdep.h"
> +
> +#include "exec/confidential-guest-support.h"
> +
> +OBJECT_DEFINE_ABSTRACT_TYPE(ConfidentialGuestSupport,
> +confidential_guest_support,
> +CONFIDENTIAL_GUEST_SUPPORT,
> +OBJECT)
> +
> +static void confidential_guest_support_class_init(ObjectClass *oc, void
> *data)
> +{
> +}
> +
> +static void confidential_guest_support_init(Object *obj)
> +{
> +}
> +
> +static void confidential_guest_support_finalize(Object *obj)
> +{
> +}
> diff --git a/backends/meson.build b/backends/meson.build
> index 484456ece7..d4221831fc 100644
> --- a/backends/meson.build
> +++ b/backends/meson.build
> @@ -6,6 +6,7 @@ softmmu_ss.add([files(
>'rng-builtin.c',
>'rng-egd.c',
>'rng.c',
> + 'confidential-guest-support.c',
> ), numa])
>
> softmmu_ss.add(when: 'CONFIG_POSIX', if_true: files('rng-random.c'))
> diff --git a/include/exec/confidential-guest-support.h
> b/include/exec/confidential-guest-support.h
> new file mode 100644
> index 00..5f131023ba
> --- /dev/null
> +++ b/include/exec/confidential-guest-support.h
> @@ -0,0 +1,38 @@
> +/*
> + * QEMU Confidential Guest support
> + * This interface describes the common pieces between various
> + * schemes for protecting guest memory or other state against a
> + * compromised hypervisor. This includes memory encryption (AMD's
> + * SEV and Intel's MKTME) or special protection modes (PEF on POWER,
> + * or PV on s390x).
> + *
> + * Copyright: David Gibson, Red Hat Inc. 2020
> + *
> + * Authors:
> + * David Gibson
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or
> + * later. See the COPYING file in the top-level directory.
> + *
> + */
> +#ifndef QEMU_CONFIDENTIAL_GUEST_SUPPORT_H
> +#define QEMU_CONFIDENTIAL_GUEST_SUPPORT_H
> +
> +#ifndef CONFIG_USER_ONLY
> +
> +#include "qom/object.h"
> +
> +#define TYPE_CONFIDENTIAL_GUEST_SUPPORT "confidential-guest-support"
> +OBJECT_DECLARE_SIMPLE_TYPE(ConfidentialGuestSupport,
> CONFIDENTIAL_GUEST_SUPPORT)
> +
> +struct ConfidentialGuestSupport {
> +Object parent;
> +};
> +
> +typedef struct ConfidentialGuestSupportClass {
> +ObjectClass parent;
> +} ConfidentialGuestSupportClass;
> +
> +#endif /* !CONFIG_USER_ONLY */
> +
> +#endif /* QEMU_CONFIDENTIAL_GUEST_SUPPORT_H */
> diff --git a/include/qemu/typedefs.h b/include/qemu/typedefs.h
> index 976b529dfb..33685c79ed 100644
> --- a/include/qemu/typedefs.h
> +++ b/include/qemu/typedefs.h
> @@ -36,6 +36,7 @@ typedef struct BusState BusState;
> typedef struct Chardev Chardev;
> typedef struct CompatProperty CompatProperty;
> typedef struct CoMutex CoMutex;
> +typedef struct ConfidentialGuestSupport ConfidentialGuestSupport;
> typedef str
Re: [PULL 05/30] Makefile: wrap ctags in quiet-command calls
Hi Alex,
On Fri, Jan 15, 2021 at 2:08 PM Alex Bennée wrote:
>
> For prettier output.
>
> Signed-off-by: Alex Bennée
> Reviewed-by: Willian Rampazzo
> Reviewed-by: Philippe Mathieu-Daudé
> Message-Id: <20210114165730.31607-6-alex.ben...@linaro.org>
>
> diff --git a/Makefile b/Makefile
> index 0c509a7704..bbab640b31 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -250,8 +250,13 @@ find-src-path = find "$(SRC_PATH)/" -path
> "$(SRC_PATH)/meson" -prune -o \( -name
>
> .PHONY: ctags
> ctags:
> - rm -f "$(SRC_PATH)/"tags
> - $(find-src-path) -exec ctags -f "$(SRC_PATH)/"tags --append {} +
> + $(call quiet-command, \
> + rm -f "$(SRC_PATH)/"tags, \
> + "CTAGS", "Remove old tags")
> + $(call quiet-command, \
> + $(find-src-path) -exec ctags\
> + -f "$(SRC_PATH)/"tags --append {} +,\
> + "CTAGS", "Re-index $(SRC_PATH)")
>
> .PHONY: gtags
> gtags:
> --
> 2.20.1
>
Build now fails if ctags is not installed:
$ if test -n "$MAKE_CHECK_ARGS"; then make -j"$JOBS" $MAKE_CHECK_ARGS ; fi
CTAGS Remove old tags
CTAGS Re-index /builds/philmd/qemu
find: 'ctags': No such file or directory
find: 'ctags': No such file or directory
find: 'ctags': No such file or directory
make: *** [Makefile:254: ctags] Error 1
make: *** Waiting for unfinished jobs
Re: [PATCH v2 06/12] qapi/source: Add builtin null-object sentinel
On Thu, Jan 14, 2021 at 02:39:35PM +0100, Markus Armbruster wrote: > John Snow writes: > > > On 1/13/21 10:39 AM, Markus Armbruster wrote: > >> Spelling nitpick: s/builtin/built-in/ in the title. > >> > > > > Sure. > > > >> John Snow writes: > >> > >>> We use None to represent an object that has no source information > >>> because it's a builtin. This complicates interface typing, since many > >>> interfaces expect that there is an info object available to print errors > >>> with. > >>> > >>> Introduce a special QAPISourceInfo that represents these built-ins so > >>> that if an error should so happen to occur relating to one of these > >>> builtins that we will be able to print its information, and interface > >>> typing becomes simpler: you will always have a source info object. > >>> > >>> This object will evaluate as False, so "if info" remains a valid > >>> idiomatic construct. > >>> > >>> NB: It was intentional to not allow empty constructors or similar to > >>> create "empty" source info objects; callers must explicitly invoke > >>> 'builtin()' to pro-actively opt into using the sentinel. This should > >>> prevent use-by-accident. > >>> > >>> Signed-off-by: John Snow > >> > >> As I pointed out in review of v1, this patch has two aspects mixed up: > >> > >> 1. Represent "no source info" as special QAPISourceInfo instead of > >> None > >> > >> 2. On error with "no source info", don't crash. > >> > >> The first one is what de-complicates interface typing. It's clearly > >> serving this patch series' stated purpose: "static typing conversion". > >> > >> The second one is not. It sidetracks us into a design discussion that > >> isn't related to static typing. Maybe it's something we should discuss. > >> Maybe the discussion will make us conclude we want to do this. But > >> letting the static typing work get delayed by that discussion would be > >> stupid, and I'll do what I can to prevent that. > >> > > > > It's not unrelated. It's about finding the most tactical incision to > > make the types as we actually use them correct from a static analysis > > context. > > > > Maybe there's another tactical incision to make that's "smaller", for > > some perception of "smaller", but it's not unrelated. > > We don't have to debate, let alone agree on relatedness. > > >> The stupidest possible solution that preserves the crash is adding an > >> assertion right where it crashes before this patch: in > >> QAPISourceInfo.__str__(). Yes, crashing in a __str__() method is not > >> nice, but it's no worse than before. Making it better than before is a > >> good idea, and you're quite welcome to try, but please not in this > >> series. Add a TODO comment asking for "make it better", then sit on > >> your hands. > > > > I'm recently back from a fairly long PTO, so forgive me if I am > > forgetting something, but I am not really sure I fundamentally > > understand the nature of this critique. > > > > Making functions not "crash" is a side-effect of making the types > > correct. I don't see it as scope-creep, it's a solution to a problem > > under active consideration. > > I disagree. > > The crash you "fix" is *intentional*. I was too lazy to write something > like > > assert self.info > > and instead relied in self.info.whatever to crash. I don't care how it > crashes, as long as it does crash. > > I *like* qapi-gen to crash on such internal errors. It's easy, and > makes "this is a bug, go report it" perfectly clear. > > I'd also be fine with reporting "internal error, this is a bug, go > report it". Not in this series, unless it's utterly trivial, which I > doubt. > > I'm *not* fine with feeding made-up info objects to the user error > reporting machinery without proof that it'll actually produce a useful > error message. Definitely not trivial, thus not in this series. If you really don't want to change the existing behavior of the code, I believe we have only two options: 1) Annotate self.info as QAPISourceInfo (not Optional), and add a hack to make the expression `self.info` crash if the argument to __init__() was None. 2) Annotate self.info as Optional[QAPISourceInfo], and adding manual asserts everywhere self.info is used. Which of those two options do you find acceptable, Markus? -- Eduardo
[PATCH] docker: Bump Fedora images to release 33
Fedora 33 was released on October 27, 2020. Update all the Fedora 32 images to this new release. Suggested-by: Daniel Berrangé Signed-off-by: Philippe Mathieu-Daudé --- Based-on: <20210118181115.313742-1-phi...@redhat.com> hw/usb/hcd-xhci: Fix extraneous format-truncation error on 32-bit hosts Based-on: <20210118170308.282442-1-phi...@redhat.com> hw/usb/dev-uas: Fix Clang 11 -Wgnu-variable-sized-type-not-at-end error --- tests/docker/dockerfiles/fedora-cris-cross.docker | 2 +- tests/docker/dockerfiles/fedora-i386-cross.docker | 2 +- tests/docker/dockerfiles/fedora-win32-cross.docker | 2 +- tests/docker/dockerfiles/fedora-win64-cross.docker | 2 +- tests/docker/dockerfiles/fedora.docker | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/tests/docker/dockerfiles/fedora-cris-cross.docker b/tests/docker/dockerfiles/fedora-cris-cross.docker index 09e7e449f9b..1dfff6e0b96 100644 --- a/tests/docker/dockerfiles/fedora-cris-cross.docker +++ b/tests/docker/dockerfiles/fedora-cris-cross.docker @@ -2,7 +2,7 @@ # Cross compiler for cris system tests # -FROM fedora:30 +FROM fedora:33 ENV PACKAGES gcc-cris-linux-gnu RUN dnf install -y $PACKAGES RUN rpm -q $PACKAGES | sort > /packages.txt diff --git a/tests/docker/dockerfiles/fedora-i386-cross.docker b/tests/docker/dockerfiles/fedora-i386-cross.docker index a6e411291b9..966072c08e6 100644 --- a/tests/docker/dockerfiles/fedora-i386-cross.docker +++ b/tests/docker/dockerfiles/fedora-i386-cross.docker @@ -1,4 +1,4 @@ -FROM fedora:31 +FROM fedora:33 ENV PACKAGES \ bzip2 \ diffutils \ diff --git a/tests/docker/dockerfiles/fedora-win32-cross.docker b/tests/docker/dockerfiles/fedora-win32-cross.docker index 087df598a09..81b5659e9c5 100644 --- a/tests/docker/dockerfiles/fedora-win32-cross.docker +++ b/tests/docker/dockerfiles/fedora-win32-cross.docker @@ -1,4 +1,4 @@ -FROM fedora:32 +FROM fedora:33 # Please keep this list sorted alphabetically ENV PACKAGES \ diff --git a/tests/docker/dockerfiles/fedora-win64-cross.docker b/tests/docker/dockerfiles/fedora-win64-cross.docker index d5d2f5f00d6..bcb428e7242 100644 --- a/tests/docker/dockerfiles/fedora-win64-cross.docker +++ b/tests/docker/dockerfiles/fedora-win64-cross.docker @@ -1,4 +1,4 @@ -FROM fedora:32 +FROM fedora:33 # Please keep this list sorted alphabetically ENV PACKAGES \ diff --git a/tests/docker/dockerfiles/fedora.docker b/tests/docker/dockerfiles/fedora.docker index 0b5053f2d09..9ba8c147edd 100644 --- a/tests/docker/dockerfiles/fedora.docker +++ b/tests/docker/dockerfiles/fedora.docker @@ -1,4 +1,4 @@ -FROM fedora:32 +FROM fedora:33 # Please keep this list sorted alphabetically ENV PACKAGES \ -- 2.26.2
[PATCH] hw/usb/hcd-xhci: Fix extraneous format-truncation error on 32-bit hosts
For some reason the assert() added in commit ccb799313a5
("hw/usb: avoid format truncation warning when formatting
port name") does not fix when building with GCC 10.
KISS and expand the buffer by 4 bytes to silent the following
error when using GCC 10.2.1 on Fedora 33:
hw/usb/hcd-xhci.c: In function 'usb_xhci_realize':
hw/usb/hcd-xhci.c:3309:54: error: '%d' directive output may be truncated
writing between 1 and 8 bytes into a region of size 5
[-Werror=format-truncation=]
3309 | snprintf(port->name, sizeof(port->name), "usb2 port #%d",
i+1);
| ^~~
hw/usb/hcd-xhci.c:3309:54: note: directive argument in the range [1, 89478486]
In file included from /usr/include/stdio.h:866,
from include/qemu/osdep.h:85,
from hw/usb/hcd-xhci.c:22:
/usr/include/bits/stdio2.h:70:10: note: '__builtin___snprintf_chk' output
between 13 and 20 bytes into a destination of size 16
70 | return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
| ^~~~
71 |__bos (__s), __fmt, __va_arg_pack ());
|~
hw/usb/hcd-xhci.c:3323:54: error: '%d' directive output may be truncated
writing between 1 and 8 bytes into a region of size 5
[-Werror=format-truncation=]
3323 | snprintf(port->name, sizeof(port->name), "usb3 port #%d",
i+1);
| ^~~
hw/usb/hcd-xhci.c:3323:54: note: directive argument in the range [1, 89478486]
In file included from /usr/include/stdio.h:866,
from include/qemu/osdep.h:85,
from hw/usb/hcd-xhci.c:22:
/usr/include/bits/stdio2.h:70:10: note: '__builtin___snprintf_chk' output
between 13 and 20 bytes into a destination of size 16
70 | return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
| ^~~~
71 |__bos (__s), __fmt, __va_arg_pack ());
|~
cc1: all warnings being treated as errors
Signed-off-by: Philippe Mathieu-Daudé
---
hw/usb/hcd-xhci.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/usb/hcd-xhci.h b/hw/usb/hcd-xhci.h
index 02ebd764509..7bba361f3bb 100644
--- a/hw/usb/hcd-xhci.h
+++ b/hw/usb/hcd-xhci.h
@@ -128,7 +128,7 @@ typedef struct XHCIPort {
uint32_t portnr;
USBPort *uport;
uint32_t speedmask;
-char name[16];
+char name[20];
MemoryRegion mem;
} XHCIPort;
--
2.26.2
Re: [PATCH] target/mips: fetch code with translator_ld
On 1/16/21 8:13 AM, Philippe Mathieu-Daudé wrote:
> +++ b/target/mips/tlb_helper.c
> @@ -21,7 +21,7 @@
> #include "cpu.h"
> #include "internal.h"
> #include "exec/exec-all.h"
> -#include "exec/cpu_ldst.h"
> +#include "exec/translator.h"
> #include "exec/log.h"
> #include "hw/mips/cpudevs.h"
>
> @@ -526,9 +526,9 @@ static bool get_pte(CPUMIPSState *env, uint64_t vaddr,
> int entry_size,
> return false;
> }
> if (entry_size == 64) {
> -*pte = cpu_ldq_code(env, vaddr);
> +*pte = translator_ldq(env, vaddr);
> } else {
> -*pte = cpu_ldl_code(env, vaddr);
> +*pte = translator_ldl(env, vaddr);
> }
> return true;
> }
NACK. This is not within the translator.
r~
Re: [Bug 1912065] Re: Segfaults in tcg/optimize.c:212 after commit 7c79721606be11b5bc556449e5bcbc331ef6867d
Patchew URL: https://patchew.org/QEMU/161099084144.30067.897245088295398204.mal...@chaenomeles.canonical.com/ Hi, This series seems to have some coding style problems. See output below for more information: Type: series Message-id: 161099084144.30067.897245088295398204.mal...@chaenomeles.canonical.com Subject: [Bug 1912065] Re: Segfaults in tcg/optimize.c:212 after commit 7c79721606be11b5bc556449e5bcbc331ef6867d === 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/161099084144.30067.897245088295398204.mal...@chaenomeles.canonical.com -> patchew/161099084144.30067.897245088295398204.mal...@chaenomeles.canonical.com - [tag update] patchew/cover.1610638428.git.jag.ra...@oracle.com -> patchew/cover.1610638428.git.jag.ra...@oracle.com Switched to a new branch 'test' 0b7840a Segfaults in tcg/optimize.c:212 after commit 7c79721606be11b5bc556449e5bcbc331ef6867d === OUTPUT BEGIN === ERROR: Missing Signed-off-by: line(s) total: 1 errors, 0 warnings, 16 lines checked Commit 0b7840aec0d8 (Segfaults in tcg/optimize.c:212 after commit 7c79721606be11b5bc556449e5bcbc331ef6867d) 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/161099084144.30067.897245088295398204.mal...@chaenomeles.canonical.com/testing.checkpatch/?type=message. --- Email generated automatically by Patchew [https://patchew.org/]. Please send your feedback to patchew-de...@redhat.com
Re: [PATCH v2 03/36] block: bdrv_append(): don't consume reference
Am 18.01.2021 um 18:21 hat Vladimir Sementsov-Ogievskiy geschrieben: > 18.01.2021 17:18, Kevin Wolf wrote: > > Am 27.11.2020 um 15:44 hat Vladimir Sementsov-Ogievskiy geschrieben: > > > We have too much comments for this feature. It seems better just don't > > > do it. Most of real users (tests don't count) have to create additional > > > reference. > > > > > > Drop also comment in external_snapshot_prepare: > > > - bdrv_append doesn't "remove" old bs in common sense, it sounds > > > strange > > > - the fact that bdrv_append can fail is obvious from the context > > > - the fact that we must rollback all changes in transaction abort is > > > known (it's the direct role of abort) > > > > > > Signed-off-by: Vladimir Sementsov-Ogievskiy > > > diff --git a/blockdev.c b/blockdev.c > > > index b5f11c524b..96c96f8ba6 100644 > > > --- a/blockdev.c > > > +++ b/blockdev.c > > > @@ -1587,10 +1587,6 @@ static void > > > external_snapshot_prepare(BlkActionState *common, > > > goto out; > > > } > > > -/* This removes our old bs and adds the new bs. This is an operation > > > that > > > - * can fail, so we need to do it in .prepare; undoing it for abort is > > > - * always possible. */ > > > > This comment is still relevant, it's unrelated to the bdrv_ref(). > > I described in commit message, why I dislike this comment :) I can > keep it of course, it's not critical Ah, right, I missed this bit in the commit message (or forgot it until I reached this hunk) and thought it was an accidental removal. If it's intentional, no reason to change the patch. Kevin
