Re: [Qemu-devel] [PATCH v4] cutils: Provide strchrnul
Peter Maydell writes: > On 11 June 2018 at 08:56, Markus Armbruster wrote: >> You're not printing $strchrnul like we print other configuration >> results. Hmm, we're not printing several of them. Question for >> maintainers (MAINTAINERS doesn't have any, so I'm cc'ing the top three >> coughed up by get_maintainer.pl): bug or feature? If feature, how do we >> decide what to print? > > If we printed everything that we tested for then the output would > be unhelpfully enormous. My view is that we should print the > "interesting" things for the user, ie the higher-level things > that the user could potentially turn on by installing more > libraries or has turned off explicitly or whatever. Reporting > whether the host OS has strchrnul or whether we've had to > provide our own implementation is doubly uninteresting: > * there's nothing the user could do to change this > * there is no visible effect (missing features, worse performance) Care to clean out out existing "uninteresting" prints? > There's an argument that we should also log every config check > result somehow (I think autoconf configures do this), but I > don't think that our 'print stuff to stdout' is the right place > for that. Makes sense. Volunteers?
Re: [Qemu-devel] [PATCH v5] cutils: Provide strchrnul
Keno Fischer writes: > strchrnul is a GNU extension and thus unavailable on a number of targets. > In the review for a commit removing strchrnul from 9p, I was asked to > create a qemu_strchrnul helper to factor out this functionality. > Do so, and use it in a number of other places in the code base that inlined > the replacement pattern in a place where strchrnul could be used. > > Signed-off-by: Keno Fischer > Acked-by: Greg Kurz Reviewed-by: Markus Armbruster
Re: [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
On 2018年06月13日 12:24, Samudrala, Sridhar wrote: On 6/12/2018 7:38 PM, Jason Wang wrote: On 2018年06月12日 19:54, Michael S. Tsirkin wrote: On Wed, Jun 06, 2018 at 10:29:03AM +0800, Jason Wang wrote: On 2018年06月05日 20:33, Michael S. Tsirkin wrote: I don't think this is sufficient. If both primary and standby devices are present, a legacy guest without support for the feature might see two devices with same mac and get confused. I think that we should only make primary visible after guest acked the backup feature bit. I think we want exactly the reverse? E.g fail the negotiation when guest does not ack backup feature. Otherwise legacy guest won't even have the chance to see primary device in the guest. That's by design. So management needs to know the capability of guest to set the backup feature. This looks a chicken or egg problem to me. I don't think so. If the tenant requests 'accelerated datapath feature', the management will set 'standby' feature bit on virtio-net interface and if the guest virtio-net driver supports this feature, then the tenant VM will get that capability via a hot-plugged primary device. Ok, I thought exactly the reverse because of the commit title is "enable virtio_net to act as a standby for a passthru device". But re-read the commit log content, I understand the case a little bit. Btw, VF is not necessarily faster than virtio-net, especially consider virtio-net may have a lot of queues. And on reset or when backup is cleared in some other way, unplug the primary. What if guest does not support hotplug? It shouldn't ack the backup feature then and it's a good point. We should both document this and check kernel config has hotplug support. Sridhar could you take a look pls? Something like the below will do the job: Primary device is added with a special "primary-failover" flag. A virtual machine is then initialized with just a standby virtio device. Primary is not yet added. A question is how to do the matching? Qemu knows nothing about e.g mac address of a pass-through device I believe? Supply a flag to the VFIO when it's added, this way QEMU will know. Later QEMU detects that guest driver device set DRIVER_OK. It then exposes the primary device to the guest, and triggers a device addition event (hot-plug event) for it. Do you mean we won't have primary device in the initial qemu cli? No, that's not what I mean. I mean management will supply a flag to VFIO and then - VFIO defers exposing primary to guest until guest acks the feature bit. - When we see guest ack, initiate hotplug. - On reboot, hide it again. - On reset without reboot, request hot-unplug and on eject hide it again. This sounds much like a kind of bonding in qemu. If QEMU detects guest driver removal, it initiates a hot-unplug sequence to remove the primary driver. In particular, if QEMU detects guest re-initialization (e.g. by detecting guest reset) it immediately removes the primary device. I believe guest failover module should handle this gracefully? It can't control enumeration order, if primary is enumerated before standby then guest will load its driver and it's too late when failover driver is loaded. Well, even if we can delay the visibility of primary until DRIVER_OK, there still be a race I think? And it looks to me it's still a bug of guest: E.g primary could be probed before failover_register() in guest. Then we will miss the enslaving of primary forever. That is not an issue. Even if the primary is probed before failover driver, it will enslave the primary via the call to failover_existing_slave_register() as part of failover_register() routine. Aha I get it. So the enumeration order is not an issue. Consider primary may still be seen by guest kernel even if we delay its visibility, I wonder whether we can control the lifecycle of primary through driver but not qemu. This can simplify a lot of things. Thanks Thanks Thanks We can move some of this code to management as well, architecturally it does not make too much sense but it might be easier implementation-wise. HTH On Mon, Jun 04, 2018 at 06:41:48PM -0700, Samudrala, Sridhar wrote: Ping on this patch now that the kernel patches are accepted into davem's net-next tree. https://patchwork.ozlabs.org/cover/920005/ On 5/7/2018 4:09 PM, Sridhar Samudrala wrote: This feature bit can be used by hypervisor to indicate virtio_net device to act as a standby for another device with the same MAC address. I tested this with a small change to the patch to mark the STANDBY feature 'true' by default as i am using libvirt to start the VMs. Is there a way to pass the newly added feature bit 'standby' to qemu via libvirt XML file? Signed-off-by: Sridhar Samudrala --- hw/net/virtio-net.c | 2 ++ include/standard-headers/linux/virtio_net.h | 3 +++ 2 files changed, 5 insertions(+) diff --git a/hw/net/virtio-net.c
[Qemu-devel] [PATCH] trivial: Make bios files and source files non-executable
These files can not be executed on the host, so they should not be marked as executable. Signed-off-by: Thomas Huth --- block/blkreplay.c | 0 pc-bios/hppa-firmware.img | Bin pc-bios/palcode-clipper| Bin pc-bios/u-boot-sam460-20100605.bin | Bin pc-bios/u-boot.e500| Bin replay/replay-char.c | 0 6 files changed, 0 insertions(+), 0 deletions(-) mode change 100755 => 100644 block/blkreplay.c mode change 100755 => 100644 pc-bios/hppa-firmware.img mode change 100755 => 100644 pc-bios/palcode-clipper mode change 100755 => 100644 pc-bios/u-boot-sam460-20100605.bin mode change 100755 => 100644 pc-bios/u-boot.e500 mode change 100755 => 100644 replay/replay-char.c diff --git a/block/blkreplay.c b/block/blkreplay.c old mode 100755 new mode 100644 diff --git a/pc-bios/hppa-firmware.img b/pc-bios/hppa-firmware.img old mode 100755 new mode 100644 diff --git a/pc-bios/palcode-clipper b/pc-bios/palcode-clipper old mode 100755 new mode 100644 diff --git a/pc-bios/u-boot-sam460-20100605.bin b/pc-bios/u-boot-sam460-20100605.bin old mode 100755 new mode 100644 diff --git a/pc-bios/u-boot.e500 b/pc-bios/u-boot.e500 old mode 100755 new mode 100644 diff --git a/replay/replay-char.c b/replay/replay-char.c old mode 100755 new mode 100644 -- 1.8.3.1
[Qemu-devel] [PATCH 3/4] qemu-options: Improve the documentation of '-accel' and '-machine accel=...'
Instead of repeating the same text for both options, let's rather change
the '-machine accel' documentation to point to the preferred '-accel' option
instead.
And in the documenation of the -accel option, make it clear that you can
use colons to specify multiple accelerators.
Signed-off-by: Thomas Huth
---
qemu-options.hx | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index 451f7a6..0ec9cac 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -30,8 +30,7 @@ ETEXI
DEF("machine", HAS_ARG, QEMU_OPTION_machine, \
"-machine [type=]name[,prop[=value][,...]]\n"
"selects emulated machine ('-machine help' for list)\n"
-"property accel=accel1[:accel2[:...]] selects
accelerator\n"
-"supported accelerators are kvm, xen, hax, hvf, whpx or
tcg (default: tcg)\n"
+"property accel=accel1[:accel2[:...]] selects accelerator
(see -accel)\n"
"kernel_irqchip=on|off|split controls accelerated irqchip
support (default=off)\n"
"vmport=on|off|auto controls emulation of vmport (default:
auto)\n"
"kvm_shadow_mem=size of KVM shadow MMU in bytes\n"
@@ -66,10 +65,8 @@ of QEMU will support machine types from many previous
versions.
Supported machine properties are:
@table @option
@item accel=@var{accels1}[:@var{accels2}[:...]]
-This is used to enable an accelerator. Depending on the target architecture,
-kvm, xen, hax, hvf, whpx or tcg can be available. By default, tcg is used. If
there is
-more than one accelerator specified, the next one is used if the previous one
-fails to initialize.
+This can be used to enable an accelerator. See the preferred @code{-accel}
+option for a list of available accelerators.
@item kernel_irqchip=on|off
Controls in-kernel irqchip support for the chosen accelerator when available.
@item gfx_passthru=on|off
@@ -128,16 +125,17 @@ Select CPU model (@code{-cpu help} for list and
additional feature selection)
ETEXI
DEF("accel", HAS_ARG, QEMU_OPTION_accel,
-"-accel [accel=]accelerator[,thread=single|multi]\n"
+"-accel [accel=]accelerator[:accelerator[:...]][,thread=single|multi]\n"
"select accelerator (kvm, xen, hax, hvf, whpx or tcg; use
'help' for a list)\n"
-"thread=single|multi (enable multi-threaded TCG)",
QEMU_ARCH_ALL)
+"thread=single|multi (enable multi-threaded TCG)\n",
QEMU_ARCH_ALL)
STEXI
@item -accel @var{name}[,prop=@var{value}[,...]]
@findex -accel
This is used to enable an accelerator. Depending on the target architecture,
-kvm, xen, hax, hvf, whpx or tcg can be available. By default, tcg is used. If
there is
-more than one accelerator specified, the next one is used if the previous one
-fails to initialize.
+kvm, xen, hax, hvf, whpx or tcg can be available. By default, tcg is used.
+Multiple accelerators can be specified by separating them with a colon. If
+there is more than one accelerator specified, the next one is used if the
+previous one fails to initialize.
@table @option
@item thread=single|multi
Controls number of TCG threads. When the TCG is multi-threaded there will be
one
--
1.8.3.1
[Qemu-devel] [PATCH 2/4] Replace '-enable-kvm' with '-accel kvm' in docs and help texts
The preferred way to select the KVM accelerator is to use "-accel kvm" these days, so let's be consistent in our documentation and help texts. Signed-off-by: Thomas Huth --- docs/COLO-FT.txt | 8 docs/can.txt | 4 ++-- docs/multi-thread-compression.txt | 2 +- docs/multiseat.txt| 2 +- docs/specs/tpm.txt| 8 hw/block/dataplane/virtio-blk.c | 4 ++-- hw/scsi/virtio-scsi-dataplane.c | 4 ++-- 7 files changed, 16 insertions(+), 16 deletions(-) diff --git a/docs/COLO-FT.txt b/docs/COLO-FT.txt index e289be2..d7c7dcd 100644 --- a/docs/COLO-FT.txt +++ b/docs/COLO-FT.txt @@ -113,16 +113,16 @@ by using 'x-colo-lost-heartbeat' command. == Test procedure == 1. Startup qemu Primary: -# qemu-kvm -enable-kvm -m 2048 -smp 2 -qmp stdio -vnc :7 -name primary \ - -device piix3-usb-uhci \ +# qemu-system-x86_64 -accel kvm -m 2048 -smp 2 -qmp stdio -name primary \ + -device piix3-usb-uhci -vnc :7 \ -device usb-tablet -netdev tap,id=hn0,vhost=off \ -device virtio-net-pci,id=net-pci0,netdev=hn0 \ -drive if=virtio,id=primary-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,\ children.0.file.filename=1.raw,\ children.0.driver=raw -S Secondary: -# qemu-kvm -enable-kvm -m 2048 -smp 2 -qmp stdio -vnc :7 -name secondary \ - -device piix3-usb-uhci \ +# qemu-system-x86_64 -accel kvm -m 2048 -smp 2 -qmp stdio -name secondary \ + -device piix3-usb-uhci -vnc :7 \ -device usb-tablet -netdev tap,id=hn0,vhost=off \ -device virtio-net-pci,id=net-pci0,netdev=hn0 \ -drive if=none,id=secondary-disk0,file.filename=1.raw,driver=raw,node-name=node0 \ diff --git a/docs/can.txt b/docs/can.txt index a357105..7ba23b2 100644 --- a/docs/can.txt +++ b/docs/can.txt @@ -52,7 +52,7 @@ The ''kvaser_pci'' board/device model is compatible with and has been tested wit The tested setup was Linux 4.9 kernel on the host and guest side. Example for qemu-system-x86_64: -qemu-system-x86_64 -enable-kvm -kernel /boot/vmlinuz-4.9.0-4-amd64 \ +qemu-system-x86_64 -accel kvm -kernel /boot/vmlinuz-4.9.0-4-amd64 \ -initrd ramdisk.cpio \ -virtfs local,path=shareddir,security_model=none,mount_tag=shareddir \ -object can-bus,id=canbus0 \ @@ -104,4 +104,4 @@ Links to other resources Slides http://rtime.felk.cvut.cz/publications/public/rtlws2015-qemu-can-slides.pdf (5) Linux SocketCAN utilities - https://github.com/linux-can/can-utils/ \ No newline at end of file + https://github.com/linux-can/can-utils/ diff --git a/docs/multi-thread-compression.txt b/docs/multi-thread-compression.txt index d0caaf7..bb88c6b 100644 --- a/docs/multi-thread-compression.txt +++ b/docs/multi-thread-compression.txt @@ -62,7 +62,7 @@ RAM: 128G NIC: Intel I350 (10/100/1000Mbps) Host OS: CentOS 7 64-bit Guest OS: RHEL 6.5 64-bit -Parameter: qemu-system-x86_64 -enable-kvm -smp 4 -m 4096 +Parameter: qemu-system-x86_64 -accel kvm -smp 4 -m 4096 /share/ia32e_rhel6u5.qcow -monitor stdio There is no additional application is running on the guest when doing diff --git a/docs/multiseat.txt b/docs/multiseat.txt index 807518c..dc28cdb 100644 --- a/docs/multiseat.txt +++ b/docs/multiseat.txt @@ -18,7 +18,7 @@ or Next put together the qemu command line (sdk/gtk): -qemu -enable-kvm -usb $memory $disk $whatever \ +qemu -accel kvm -usb $memory $disk $whatever \ -display [ sdl | gtk ] \ -vga std \ -device usb-tablet diff --git a/docs/specs/tpm.txt b/docs/specs/tpm.txt index c230c4c..70ad4a0 100644 --- a/docs/specs/tpm.txt +++ b/docs/specs/tpm.txt @@ -98,7 +98,7 @@ QEMU files related to the TPM passthrough device: Command line to start QEMU with the TPM passthrough device using the host's hardware TPM /dev/tpm0: -qemu-system-x86_64 -display sdl -enable-kvm \ +qemu-system-x86_64 -display sdl -accel kvm \ -m 1024 -boot d -bios bios-256k.bin -boot menu=on \ -tpmdev passthrough,id=tpm0,path=/dev/tpm0 \ -device tpm-tis,tpmdev=tpm0 test.img @@ -164,7 +164,7 @@ swtpm socket --tpmstate dir=/tmp/mytpm1 \ Command line to start QEMU with the TPM emulator device communicating with the swtpm: -qemu-system-x86_64 -display sdl -enable-kvm \ +qemu-system-x86_64 -display sdl -accel kvm \ -m 1024 -boot d -bios bios-256k.bin -boot menu=on \ -chardev socket,id=chrtpm,path=/tmp/mytpm1/swtpm-sock \ -tpmdev emulator,id=tpm0,chardev=chrtpm \ @@ -222,7 +222,7 @@ swtpm socket --tpmstate dir=/tmp/mytpm1 \ In a 2nd terminal start the VM: -qemu-system-x86_64 -display sdl -enable-kvm \ +qemu-system-x86_64 -display sdl -accel kvm \ -m 1024 -boot d -bios bios-256k.bin -boot menu=on \ -chardev socket,id=chrtpm,path=/tmp/mytpm1/swtpm-sock \ -tpmdev emulator,id=tpm0,chardev=chrtpm \ @@ -255,7 +255,7 @@ swtpm socket --tpmstate dir=/tmp/mytpm1 \ In the 2nd terminal restore the state of the VM using the additonal '-incoming' option. -qemu-system-x86_64 -display sdl
[Qemu-devel] [RFC PATCH 4/4] qemu-options: Do not show -enable-kvm and -enable-hax in the docs anymore
We've got three ways of enabling an accelerator: -machine accel=xyz,
-accel xyz and -enable-xyz. For new QEMU users, this must be very
confusing ("Which one do I have to use? Is there a difference between
the options?"). While -enable-kvm was useful in the past, there is no
real good reason for using it anymore today ("-accel kvm" is even less
to type than "-enable-kvm"), so let's decrease the confusing amount of
options in our documenation a little bit by removing the -enable-xyz
here. Note that the option itself is neither removed nor marked as
deprecated - since -enable-kvm is likely used in a lot of scripts and
since its code is easy to maintain, we should keep it around to avoid
to break old setups.
Signed-off-by: Thomas Huth
---
PS: I guess Paolo won't like this patch ... let's try it anyway ;-)
qemu-options.hx | 22 --
1 file changed, 4 insertions(+), 18 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index 0ec9cac..f33a81e 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -3414,25 +3414,11 @@ STEXI
Set the filename for the BIOS.
ETEXI
-DEF("enable-kvm", 0, QEMU_OPTION_enable_kvm, \
-"-enable-kvm enable KVM full virtualization support\n", QEMU_ARCH_ALL)
-STEXI
-@item -enable-kvm
-@findex -enable-kvm
-Enable KVM full virtualization support. This option is only available
-if KVM support is enabled when compiling.
-ETEXI
+HXCOMM -accel kvm should be used instead, thus this is not documented anymore
+DEF("enable-kvm", 0, QEMU_OPTION_enable_kvm, "", QEMU_ARCH_ALL)
-DEF("enable-hax", 0, QEMU_OPTION_enable_hax, \
-"-enable-hax enable HAX virtualization support\n", QEMU_ARCH_I386)
-STEXI
-@item -enable-hax
-@findex -enable-hax
-Enable HAX (Hardware-based Acceleration eXecution) support. This option
-is only available if HAX support is enabled when compiling. HAX is only
-applicable to MAC and Windows platform, and thus does not conflict with
-KVM.
-ETEXI
+HXCOMM -accel hax should be used instead, thus this is not documented anymore
+DEF("enable-hax", 0, QEMU_OPTION_enable_hax, "", QEMU_ARCH_I386)
DEF("xen-domid", HAS_ARG, QEMU_OPTION_xen_domid,
"-xen-domid id specify xen guest domain id\n", QEMU_ARCH_ALL)
--
1.8.3.1
[Qemu-devel] [PATCH 0/4] Clean up accelerator options
The current state of the accelerator options is quite messy: There are three ways of enabling an accelerator (-machine accel=xyz, -accel xyz and -enable-xyz) and this can be very confusing for the users. This patch series now tries to standardize our documentation and examples on the preferred -accel option. Thomas Huth (4): Replace '-machine accel=xyz' with '-accel xyz' Replace '-enable-kvm' with '-accel kvm' in docs and help texts qemu-options: Improve the documentation of '-accel' and '-machine accel=...' qemu-options: Do not show -enable-kvm and -enable-hax in the docs anymore docs/COLO-FT.txt| 8 +++ docs/can.txt| 4 ++-- docs/multi-thread-compression.txt | 2 +- docs/multiseat.txt | 2 +- docs/specs/tpm.txt | 8 +++ hw/block/dataplane/virtio-blk.c | 4 ++-- hw/scsi/virtio-scsi-dataplane.c | 4 ++-- qemu-doc.texi | 3 +-- qemu-options.hx | 44 - scripts/qtest.py| 2 +- tests/bios-tables-test.c| 2 +- tests/boot-serial-test.c| 2 +- tests/libqtest.c| 2 +- tests/migration-test.c | 8 +++ tests/migration/guestperf/engine.py | 2 +- tests/pnv-xscom-test.c | 2 +- tests/prom-env-test.c | 2 +- tests/pxe-test.c| 2 +- tests/qemu-iotests/172 | 2 +- tests/qemu-iotests/check| 2 +- tests/vmgenid-test.c| 2 +- 21 files changed, 46 insertions(+), 63 deletions(-) -- 1.8.3.1
[Qemu-devel] [PATCH 1/4] Replace '-machine accel=xyz' with '-accel xyz'
We've got a separate option to configure the accelerator nowadays.
Use it in the source and examples to demonstrate that this is the
preferred way of setting this option now.
Signed-off-by: Thomas Huth
---
qemu-doc.texi | 3 +--
qemu-options.hx | 2 +-
scripts/qtest.py| 2 +-
tests/bios-tables-test.c| 2 +-
tests/boot-serial-test.c| 2 +-
tests/libqtest.c| 2 +-
tests/migration-test.c | 8
tests/migration/guestperf/engine.py | 2 +-
tests/pnv-xscom-test.c | 2 +-
tests/prom-env-test.c | 2 +-
tests/pxe-test.c| 2 +-
tests/qemu-iotests/172 | 2 +-
tests/qemu-iotests/check| 2 +-
tests/vmgenid-test.c| 2 +-
14 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/qemu-doc.texi b/qemu-doc.texi
index cd05760..1c47e7c 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -2793,8 +2793,7 @@ which is the default.
@subsection -no-kvm (since 1.3.0)
-The ``-no-kvm'' argument is now a synonym for setting
-``-machine accel=tcg''.
+The ``-no-kvm'' argument is now a synonym for setting ``-accel tcg''.
@subsection -vnc tls (since 2.5.0)
diff --git a/qemu-options.hx b/qemu-options.hx
index c0d3951..451f7a6 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -3922,7 +3922,7 @@ STEXI
Enable FIPS 140-2 compliance mode.
ETEXI
-HXCOMM Deprecated by -machine accel=tcg property
+HXCOMM Deprecated by -accel tcg
DEF("no-kvm", 0, QEMU_OPTION_no_kvm, "", QEMU_ARCH_I386)
DEF("msg", HAS_ARG, QEMU_OPTION_msg,
diff --git a/scripts/qtest.py b/scripts/qtest.py
index df0daf2..8c074a6 100644
--- a/scripts/qtest.py
+++ b/scripts/qtest.py
@@ -89,7 +89,7 @@ class QEMUQtestMachine(qemu.QEMUMachine):
def _base_args(self):
args = super(QEMUQtestMachine, self)._base_args()
args.extend(['-qtest', 'unix:path=' + self._qtest_path,
- '-machine', 'accel=qtest'])
+ '-accel', 'qtest'])
return args
def _pre_launch(self):
diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c
index 4e24930..f41ec39 100644
--- a/tests/bios-tables-test.c
+++ b/tests/bios-tables-test.c
@@ -613,7 +613,7 @@ static void test_acpi_one(const char *params, test_data
*data)
char *args;
/* Disable kernel irqchip to be able to override apic irq0. */
-args = g_strdup_printf("-machine %s,accel=%s,kernel-irqchip=off "
+args = g_strdup_printf("-machine %s,kernel-irqchip=off -accel %s "
"-net none -display none %s "
"-drive id=hd0,if=none,file=%s,format=raw "
"-device ide-hd,drive=hd0 ",
diff --git a/tests/boot-serial-test.c b/tests/boot-serial-test.c
index 4d6815c..84a2aa9 100644
--- a/tests/boot-serial-test.c
+++ b/tests/boot-serial-test.c
@@ -175,7 +175,7 @@ static void test_machine(const void *data)
* Make sure that this test uses tcg if available: It is used as a
* fast-enough smoketest for that.
*/
-global_qtest = qtest_startf("%s %s -M %s,accel=tcg:kvm "
+global_qtest = qtest_startf("%s %s -M %s -accel tcg:kvm "
"-chardev file,id=serial0,path=%s "
"-no-shutdown -serial chardev:serial0 %s",
codeparam, code ? codetmp : "",
diff --git a/tests/libqtest.c b/tests/libqtest.c
index 098af6a..51481b0 100644
--- a/tests/libqtest.c
+++ b/tests/libqtest.c
@@ -209,7 +209,7 @@ QTestState *qtest_init_without_qmp_handshake(bool use_oob,
"-qtest-log %s "
"-chardev socket,path=%s,nowait,id=char0 "
"-mon chardev=char0,mode=control%s "
- "-machine accel=qtest "
+ "-accel qtest "
"-display none "
"%s", qemu_binary, socket_path,
getenv("QTEST_LOG") ? "/dev/fd/2" :
"/dev/null",
diff --git a/tests/migration-test.c b/tests/migration-test.c
index 3a85446..2b96ff0 100644
--- a/tests/migration-test.c
+++ b/tests/migration-test.c
@@ -372,12 +372,12 @@ static void test_migrate_start(QTestState **from,
QTestState **to,
if (strcmp(arch, "i386") == 0 || strcmp(arch, "x86_64") == 0) {
init_bootfile_x86(bootpath);
-cmd_src = g_strdup_printf("-machine accel=%s -m 150M"
+cmd_src = g_strdup_printf("-accel %s -m 150M"
" -name source,debug-threads=on"
" -serial file:%s/src_serial"
" -drive file=%s,format=raw",
accel, tmpfs, bootpath);
-cmd_dst = g_strdup_printf("-machine accel=%s -m 150M"
+cmd_dst =
Re: [Qemu-devel] [PATCH 3/4] spapr: introduce a generic IRQ frontend to the machine
On Fri, May 18, 2018 at 06:44:04PM +0200, Cédric Le Goater wrote:
> This proposal moves all the related IRQ routines of the sPAPR machine
> behind a class interface to prepare for future changes in the IRQ
> controller model. First of which is a reorganization of the IRQ number
> space layout and a second, coming later, will be to integrate the
> support for the new POWER9 XIVE IRQ controller.
>
> The new interface defines a set of fixed IRQ number ranges, for each
> IRQ type, in which devices allocate the IRQ numbers they need
> depending on a unique device index. Here is the layout :
>
> SPAPR_IRQ_IPI0x0/* 1 IRQ per CPU */
> SPAPR_IRQ_EPOW 0x1000 /* 1 IRQ per device */
> SPAPR_IRQ_HOTPLUG0x1001 /* 1 IRQ per device */
> SPAPR_IRQ_VIO0x1100 /* 1 IRQ per device */
> SPAPR_IRQ_PCI_LSI0x1200 /* 4 IRQs per device */
> SPAPR_IRQ_PCI_MSI0x1400 /* 1K IRQs per device */
>
> The IPI range is reserved for future use when XIVE support
> comes in.
>
> The routines of this interface encompass the previous needs and the
> new ones and seem complex but the provided IRQ backend should
> implement what we have today without any functional changes.
>
> Each device model is modified to take the new interface into account
> using the IRQ range/type definitions and a device index. A part from
> the VIO devices, lacking an id, the changes are relatively simple.
I find your use of "back end" vs. "front end" in this patch and the
next kind of confusing.
> Signed-off-by: Cédric Le Goater
> ---
> include/hw/ppc/spapr.h | 10 +-
> include/hw/ppc/spapr_irq.h | 46 +
> hw/ppc/spapr.c | 177 +-
> hw/ppc/spapr_events.c | 7 +-
> hw/ppc/spapr_irq.c | 233
> +
> hw/ppc/spapr_pci.c | 21 +++-
> hw/ppc/spapr_vio.c | 5 +-
> hw/ppc/Makefile.objs | 2 +-
> 8 files changed, 308 insertions(+), 193 deletions(-)
> create mode 100644 include/hw/ppc/spapr_irq.h
> create mode 100644 hw/ppc/spapr_irq.c
>
> diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
> index 2cfdfdd67eaf..4eb212b16a51 100644
> --- a/include/hw/ppc/spapr.h
> +++ b/include/hw/ppc/spapr.h
> @@ -3,10 +3,10 @@
>
> #include "sysemu/dma.h"
> #include "hw/boards.h"
> -#include "hw/ppc/xics.h"
> #include "hw/ppc/spapr_drc.h"
> #include "hw/mem/pc-dimm.h"
> #include "hw/ppc/spapr_ovec.h"
> +#include "hw/ppc/spapr_irq.h"
>
> struct VIOsPAPRBus;
> struct sPAPRPHBState;
> @@ -104,6 +104,7 @@ struct sPAPRMachineClass {
>unsigned n_dma, uint32_t *liobns, Error **errp);
> sPAPRResizeHPT resize_hpt_default;
> sPAPRCapabilities default_caps;
> +sPAPRIrq *irq;
> };
>
> /**
> @@ -773,13 +774,6 @@ int spapr_get_vcpu_id(PowerPCCPU *cpu);
> void spapr_set_vcpu_id(PowerPCCPU *cpu, int cpu_index, Error **errp);
> PowerPCCPU *spapr_find_cpu(int vcpu_id);
>
> -int spapr_irq_alloc(sPAPRMachineState *spapr, bool lsi, Error **errp);
> -int spapr_irq_alloc_block(sPAPRMachineState *spapr, int num, bool lsi,
> - bool align, Error **errp);
> -void spapr_irq_free(sPAPRMachineState *spapr, int irq, int num);
> -qemu_irq spapr_qirq(sPAPRMachineState *spapr, int irq);
> -
> -
> int spapr_caps_pre_load(void *opaque);
> int spapr_caps_pre_save(void *opaque);
>
> diff --git a/include/hw/ppc/spapr_irq.h b/include/hw/ppc/spapr_irq.h
> new file mode 100644
> index ..caf4c33d4cec
> --- /dev/null
> +++ b/include/hw/ppc/spapr_irq.h
> @@ -0,0 +1,46 @@
> +/*
> + * QEMU PowerPC sPAPR IRQ backend definitions
> + *
> + * Copyright (c) 2018, IBM Corporation.
> + *
> + * This code is licensed under the GPL version 2 or later. See the
> + * COPYING file in the top-level directory.
> + */
> +#ifndef HW_SPAPR_IRQ_H
> +#define HW_SPAPR_IRQ_H
> +
> +#include "hw/ppc/xics.h"
> +
> +/*
> + * IRQ ranges
> + */
> +#define SPAPR_IRQ_IPI0x0 /* 1 IRQ per CPU */
> +#define SPAPR_IRQ_EPOW 0x1000 /* 1 IRQ per device */
> +#define SPAPR_IRQ_HOTPLUG0x1001 /* 1 IRQ per device */
> +#define SPAPR_IRQ_VIO0x1100 /* 1 IRQ per device */
> +#define SPAPR_IRQ_PCI_LSI0x1200 /* 4 IRQs per device */
> +#define SPAPR_IRQ_PCI_MSI0x1400 /* 1K IRQs per device covered by
> + * a bitmap allocator */
These look like they belong in the next patch with the fixed allocations.
> +typedef struct sPAPRIrq {
Much of this structure doesn't make sense to me. AIUI, the idea is
that this method structure will vary with the xics vs. xive backend,
yes? Comments below are based on that assumption.
> +uint32_tnr_irqs;
> +
> +void (*init)(sPAPRMachineState *spapr, Error **errp);
> +int (*alloc)(sPAPRMachineState *spapr, uint32_t range, uint32_t index,
> + Error **errp);
'range' has no
[Qemu-devel] [Bug 1195012] Re: x86_64 and i386 return 0 when reading MSR_TSC
[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/1195012 Title: x86_64 and i386 return 0 when reading MSR_TSC Status in QEMU: Expired Bug description: Running NetBSD 6.1 (i386 and amd64) under QEMU (from git - 1.5.50 is the version it shows) results in an incorrectly set TSC frequency (set to 0), because NetBSD uses rdmsr(TSC_MSR) for its serializing CPU counter. To reproduce the problem, you can run an install ISO of NetBSD 6.1 (either i386 or amd64, depending on which qemu). Quit out of the installer, and you're left at a root prompt: # sysctl machdep.tsc_freq machdep.tsc_freq = 0 ...on real hardware, it will return the TSC frequency: # sysctl machdep.tsc_freq machdep.tsc_freq = 3292685070 ...this causes problems with a number of applications. The NetBSD code which reads the MSR is here: http://nxr.netbsd.org/xref/src/sys/arch/x86/x86/tsc.c#262 ... the "rdmsr(MSR_TSC)" call in cpu_counter_serializing() always returns 0 when run under QEMU. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1195012/+subscriptions
[Qemu-devel] [Bug 1190525] Re: fdisk still shows the "/dev/sdb" partitions even after the removal of scsi disk
[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/1190525 Title: fdisk still shows the "/dev/sdb" partitions even after the removal of scsi disk Status in QEMU: Expired Bug description: RHEL guest shows the partittions even after the removal of scsi disk: fdisk still shows the "/dev/sdb" partitions even after the removal of scsi disk. Guest details: --- Kernel : 2.6.32-358 Host Details : Upstream Kernel, Qemu, Libvirt and virt-manager - kernel version : 3.9.0+ qemu version : QEMU emulator version 1.5.0 libvirt version : 1.0.5 virt-install : 0.600.3 Steps to reproduce the issue: I. Add the SCSI disk through the virt-manager. 2. Create the partition using fdisk (eg: /dev/sbb) 3. Create a filesystem and format using mkfs.ext3 or mkfs.ext4 4. Remove the scsi disk through the virt-manager. 5. Again run the fdisk /dev/sdb, the guests still shows the partition even after the removal of the disk. This issue is not seen with virt-io disk. This issue is also reproducible without even creating the partitions. Expected Result: The output of fdisk /dev/sd* should not show the enties after the removal of scsi disks To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1190525/+subscriptions
[Qemu-devel] [Bug 1013241] Re: qemu-system-ppc64 hanging occasionally in disk writes
[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/1013241 Title: qemu-system-ppc64 hanging occasionally in disk writes Status in QEMU: Expired Bug description: I found last week that qemu-system-ppc64 (from git) hangs occasionally under load, and I have a reproducer for it now. Unfortunately the reproducer really takes a long time to run -- usually I can get a hang in under 12 hours. Here is the reproducer case: https://lists.fedoraproject.org/pipermail/ppc/2012-June/001698.html Notes: (1) Verified by one other person (other than me). Happens on both ppc64 and x86-64 host. (2) Happens with both Fedora guest kernel 3.3.4-5.fc17.ppc64 and kernel 3.5.0 that I compiled myself. The test case above contains 3.3.4-5. (3) Seems to be a problem in qemu, not the guest. The reason I think this is because I tried to capture a backtrace of the hang using remote gdb, but gdb just hung when trying to connect to qemu (gdb connects fine before the bug happens). (4) Judging by guest messages, appears to be happening when writing to the disk. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1013241/+subscriptions
[Qemu-devel] [Bug 1446726] Re: qemu stable 2.0 crashes during loadvm
[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/1446726 Title: qemu stable 2.0 crashes during loadvm Status in QEMU: Expired Bug description: Qemu output: 2015-03-06 01:06:54.255+: starting up LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-system-x86_64 -name instance-462a -S -machine pc-i440fx-trusty,accel=kvm,usb=off -cpu Westmere,+erms,+smep,+3dnowprefetch,+rdtscp,+rdrand,+tsc-deadline,+movbe,+pdcm,+xtpr,+tm2,+est,+vmx,+ds_cpl,+monitor,+dtes64,+pclmuldq,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -m 4096 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 7c3f225c-df2a-4014-997b-3200fcfff43d -smbios type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=2014.1.2,serial=474aef35-d474-8001-e411-6108001017ac,uuid=7c3f225c-df2a-4014-997b-3200fcfff43d -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-462a.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/nova/instances/7c3f225c-df2a-4014-997b-3200fcfff43d/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none,iops_rd=100,iops_wr=100 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/dev/mapper/258c232d7056e0047,if=none,id=drive-virtio-disk1,format=raw,serial=dedb9d8d-e727-4d09-bf89-52e870125303,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x9,drive=drive-virtio-disk1,id=virtio-disk1 -drive file=/var/lib/nova/instances/7c3f225c-df2a-4014-997b-3200fcfff43d/disk.config,if=none,id=drive-virtio-disk25,format=raw,cache=none,iops_rd=100,iops_wr=100 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk25,id=virtio-disk25 -chardev file,id=charserial0,path=/var/lib/nova/instances/7c3f225c-df2a-4014-997b-3200fcfff43d/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -k ja -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -incoming fd:23 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 char device redirected to /dev/pts/3 (label charserial1) qemu-system-x86_64: /build/buildd/qemu-2.0.0+dfsg/memory.c:1403: memory_region_del_eventfd: Assertion `i != mr->ioeventfd_nb' failed. 2015-03-06 01:09:02.585+: shutting down Libvirt log: 2015-03-05 11:29:48.434+: 8392: error : qemuMonitorIO:656 : internal error: End of file from monitor 2015-03-06 00:13:33.077+: 8397: warning : AppArmorSetFDLabel:919 : could not find path for descriptor /proc/self/fd/26, skipping 2015-03-06 00:13:40.981+: 8397: warning : virFileWrapperFdClose:308 : iohelper reports: 2015-03-06 00:14:27.206+: 8396: warning : qemuDomainObjStart:6073 : Unable to restore from managed state /var/lib/libvirt/qemu/save/instance-462a.save. Maybe the file is corrupted? 2015-03-06 00:14:40.160+: 8392: warning : qemuMonitorJSONHandleDeviceDeleted:931 : missing device in device deleted event 2015-03-06 00:20:45.414+: 8392: error : qemuMonitorIO:656 : internal error: End of file from monitor 2015-03-06 00:26:21.849+: 8396: warning : AppArmorSetFDLabel:919 : could not find path for descriptor /proc/self/fd/25, skipping 2015-03-06 00:26:24.764+: 8396: warning : virFileWrapperFdClose:308 : iohelper reports: 2015-03-06 00:28:09.425+: 8398: warning : qemuDomainObjStart:6073 : Unable to restore from managed state /var/lib/libvirt/qemu/save/instance-462a.save. Maybe the file is corrupted? 2015-03-06 00:29:29.981+: 8392: error : qemuMonitorIO:656 : internal error: End of file from monitor 2015-03-06 00:35:06.485+: 8398: warning : AppArmorSetFDLabel:919 : could not find path for descriptor /proc/self/fd/26, skipping 2015-03-06 00:35:09.645+: 8398: warning : virFileWrapperFdClose:308 : iohelper reports: 2015-03-06 00:37:58.701+: 8397: warning : qemuDomainObjStart:6073 : Unable to restore from managed state /var/lib/libvirt/qemu/save/instance-462a.save. Maybe the file is corrupted? 2015-03-06 00:59:12.925+: 8392: error : qemuMonitorIO:656 : internal error: End of file from monitor 2015-03-06 01:04:57.990+: 8392: warning : qemuMonitorJSONHandleDeviceDeleted:931 : missing device in device deleted event 2015-03-06 01:05:18.031+: 8392: warning : qemuMonitorJSONHandleDeviceDeleted:931 : missing device in device deleted event 2015-03-06 01:05:37.954+: 8392:
Re: [Qemu-devel] [PATCH 2/4] sparp_pci: simplify how the PCI LSIs are allocated
On Tue, Jun 05, 2018 at 08:31:49AM +0200, Cédric Le Goater wrote:
> On 06/05/2018 05:44 AM, David Gibson wrote:
> > On Sat, May 26, 2018 at 11:40:23AM +0200, Greg Kurz wrote:
> >> On Fri, 18 May 2018 18:44:03 +0200
> >> Cédric Le Goater wrote:
> >>
> >>> PCI LSIs are today allocated one by one using the IRQ alloc_block
> >>> routine. Change the code sequence to first allocate a PCI_NUM_PINS
> >>> block. It will help us providing a generic IRQ framework to the
> >>> machine.
> >>>
> >>> Signed-off-by: Cédric Le Goater
> >>> ---
> >>> hw/ppc/spapr_pci.c | 21 ++---
> >>> 1 file changed, 10 insertions(+), 11 deletions(-)
> >>>
> >>> diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
> >>> index 39a14980d397..4fd97ffe4c6e 100644
> >>> --- a/hw/ppc/spapr_pci.c
> >>> +++ b/hw/ppc/spapr_pci.c
> >>> @@ -1546,6 +1546,8 @@ static void spapr_phb_realize(DeviceState *dev,
> >>> Error **errp)
> >>> sPAPRTCETable *tcet;
> >>> const unsigned windows_supported =
> >>> sphb->ddw_enabled ? SPAPR_PCI_DMA_MAX_WINDOWS : 1;
> >>> +uint32_t irq;
> >>> +Error *local_err = NULL;
> >>>
> >>> if (!spapr) {
> >>> error_setg(errp, TYPE_SPAPR_PCI_HOST_BRIDGE " needs a pseries
> >>> machine");
> >>> @@ -1694,18 +1696,15 @@ static void spapr_phb_realize(DeviceState *dev,
> >>> Error **errp)
> >>> QLIST_INSERT_HEAD(>phbs, sphb, list);
> >>>
> >>> /* Initialize the LSI table */
> >>> -for (i = 0; i < PCI_NUM_PINS; i++) {
> >>> -uint32_t irq;
> >>> -Error *local_err = NULL;
> >>> -
> >>> -irq = spapr_irq_alloc_block(spapr, 1, true, false, _err);
> >>> -if (local_err) {
> >>> -error_propagate(errp, local_err);
> >>> -error_prepend(errp, "can't allocate LSIs: ");
> >>> -return;
> >>> -}
> >>> +irq = spapr_irq_alloc_block(spapr, PCI_NUM_PINS, true, false,
> >>> _err);
> >>> +if (local_err) {
> >>> +error_propagate(errp, local_err);
> >>> +error_prepend(errp, "can't allocate LSIs: ");
> >>> +return;
> >>> +}
> >>>
> >>
> >> It isn't strictly equivalent. The current code would be happy with
> >> sparse IRQ numbers, while the proposed one wouldn't... Anyway, this
> >> cannot happen since we don't have PHB hotplug.
> >
> > This makes me pretty nervous, because it's not obvious it will come up
> > with the same numbers in all circumstances, which we have to do for
> > existing machine types.
>
> Given that :
>
> - irq_hint is "unused"
> - all IRQs are allocated sequentially at machine init,
> - spapr_pci is the only model using the block allocation for MSIs,
>potentially fragmenting more the IRQ number space but done at
>guest runtime.
> - the PHB LSI are the allocated at realize time doing the loop above,
> - we don't support PHB hotplug
> - we do support PHB coldplug but then the IRQ allocation is done
>at machine time,
>
> it seems highly improbable that the IRQ number space is fragmented
> to a point which would not allow the loop above to return four
> contiguous IRQ numbers, always.
Well, assuming irq_hint really is unused, that's right. But we can't
assume that - that's the whole point of the deprecation thing.
Given that, AIUI, just one vio device with irq= set to a value that
would be within an LSI block allocated under the old scheme would
result in the new scheme returning a non-contiguous set of LSIs -
i.e. a different result from what we used to have.
> That is why I felt confident changing the loop to a single block
> allocation.
>
> > It's also not obvious to me why it's useful
> > to go via this step before going straight to static allocation of the
> > irq numbers.
>
> It pollutes the new sPAPR IRQ interface API with an extra parameter
> to support both underlying backend and it complexifies the code
> to handle block allocation of a single IRQ (like above) within an
> IRQ range (the PCI LSIs).
>
> So you end up having a family, a device index, a count, an alignment,
> and an index within the range. pffut.
>
> Also, could we kill the alignment ?
Since we sometimes pass 'true', no, we can't, without changing the
existing pattern of allocations, which we can't do.
>
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
Re: [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
On 6/12/2018 7:38 PM, Jason Wang wrote:
On 2018年06月12日 19:54, Michael S. Tsirkin wrote:
On Wed, Jun 06, 2018 at 10:29:03AM +0800, Jason Wang wrote:
On 2018年06月05日 20:33, Michael S. Tsirkin wrote:
I don't think this is sufficient.
If both primary and standby devices are present, a legacy guest
without
support for the feature might see two devices with same mac and get
confused.
I think that we should only make primary visible after guest acked the
backup feature bit.
I think we want exactly the reverse? E.g fail the negotiation when
guest
does not ack backup feature.
Otherwise legacy guest won't even have the chance to see primary
device in
the guest.
That's by design.
So management needs to know the capability of guest to set the backup
feature. This looks a chicken or egg problem to me.
I don't think so. If the tenant requests 'accelerated datapath feature', the
management
will set 'standby' feature bit on virtio-net interface and if the guest
virtio-net driver
supports this feature, then the tenant VM will get that capability via a
hot-plugged
primary device.
And on reset or when backup is cleared in some other way, unplug the
primary.
What if guest does not support hotplug?
It shouldn't ack the backup feature then and it's a good point.
We should both document this and check kernel config has
hotplug support. Sridhar could you take a look pls?
Something like the below will do the job:
Primary device is added with a special "primary-failover" flag.
A virtual machine is then initialized with just a standby virtio
device. Primary is not yet added.
A question is how to do the matching? Qemu knows nothing about e.g mac
address of a pass-through device I believe?
Supply a flag to the VFIO when it's added, this way QEMU will know.
Later QEMU detects that guest driver device set DRIVER_OK.
It then exposes the primary device to the guest, and triggers
a device addition event (hot-plug event) for it.
Do you mean we won't have primary device in the initial qemu cli?
No, that's not what I mean.
I mean management will supply a flag to VFIO and then
- VFIO defers exposing
primary to guest until guest acks the feature bit.
- When we see guest ack, initiate hotplug.
- On reboot, hide it again.
- On reset without reboot, request hot-unplug and on eject hide it
again.
This sounds much like a kind of bonding in qemu.
If QEMU detects guest driver removal, it initiates a hot-unplug
sequence
to remove the primary driver. In particular, if QEMU detects guest
re-initialization (e.g. by detecting guest reset) it immediately
removes
the primary device.
I believe guest failover module should handle this gracefully?
It can't control enumeration order, if primary is enumerated before
standby then guest will load its driver and it's too late
when failover driver is loaded.
Well, even if we can delay the visibility of primary until DRIVER_OK,
there still be a race I think? And it looks to me it's still a bug of
guest:
E.g primary could be probed before failover_register() in guest. Then
we will miss the enslaving of primary forever.
That is not an issue. Even if the primary is probed before failover driver, it
will
enslave the primary via the call to failover_existing_slave_register() as part
of
failover_register() routine.
Thanks
Thanks
We can move some of this code to management as well,
architecturally it
does not make too much sense but it might be easier
implementation-wise.
HTH
On Mon, Jun 04, 2018 at 06:41:48PM -0700, Samudrala, Sridhar wrote:
Ping on this patch now that the kernel patches are accepted into
davem's net-next tree.
https://patchwork.ozlabs.org/cover/920005/
On 5/7/2018 4:09 PM, Sridhar Samudrala wrote:
This feature bit can be used by hypervisor to indicate virtio_net
device to
act as a standby for another device with the same MAC address.
I tested this with a small change to the patch to mark the
STANDBY feature 'true'
by default as i am using libvirt to start the VMs.
Is there a way to pass the newly added feature bit 'standby' to
qemu via libvirt
XML file?
Signed-off-by: Sridhar Samudrala
---
hw/net/virtio-net.c | 2 ++
include/standard-headers/linux/virtio_net.h | 3 +++
2 files changed, 5 insertions(+)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 90502fca7c..38b3140670 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -2198,6 +2198,8 @@ static Property virtio_net_properties[] = {
true),
DEFINE_PROP_INT32("speed", VirtIONet, net_conf.speed,
SPEED_UNKNOWN),
DEFINE_PROP_STRING("duplex", VirtIONet,
net_conf.duplex_str),
+ DEFINE_PROP_BIT64("standby", VirtIONet, host_features,
VIRTIO_NET_F_STANDBY,
+ false),
DEFINE_PROP_END_OF_LIST(),
};
diff --git a/include/standard-headers/linux/virtio_net.h
b/include/standard-headers/linux/virtio_net.h
index e9f255ea3f..01ec09684c 100644
Re: [Qemu-devel] [PATCH 1/4] spapr: remove irq_hint parameter from spapr_irq_alloc()
On Tue, Jun 05, 2018 at 08:41:13AM +0200, Cédric Le Goater wrote:
> On 06/05/2018 05:34 AM, David Gibson wrote:
> > On Mon, May 28, 2018 at 09:06:12AM +0200, Cédric Le Goater wrote:
> >> On 05/28/2018 08:17 AM, Thomas Huth wrote:
> >>> On 25.05.2018 16:02, Greg Kurz wrote:
> On Fri, 18 May 2018 18:44:02 +0200
> Cédric Le Goater wrote:
>
> > This IRQ number hint can possibly be used by the VIO devices if the
> > "irq" property is defined on the command line but it seems it is never
> > the case. It is not used in libvirt for instance. So, let's remove it
> > to simplify future changes.
> >
>
> Setting an irq manually looks a bit anachronistic. I doubt anyone would
> do that nowadays, and the patch does a nice cleanup. So this looks like
> a good idea.
> >>> [...]
> > diff --git a/hw/ppc/spapr_vio.c b/hw/ppc/spapr_vio.c
> > index 472dd6f33a96..cc064f64fccf 100644
> > --- a/hw/ppc/spapr_vio.c
> > +++ b/hw/ppc/spapr_vio.c
> > @@ -455,7 +455,7 @@ static void spapr_vio_busdev_realize(DeviceState
> > *qdev, Error **errp)
> > dev->qdev.id = id;
> > }
> >
> > -dev->irq = spapr_irq_alloc(spapr, dev->irq, false, _err);
> > +dev->irq = spapr_irq_alloc(spapr, false, _err);
>
> Silently breaking "irq" like this looks wrong. I'd rather officially
> remove
> it first (ie, kill spapr_vio_props, -5 lines in spapr_vio.c).
>
> Of course, this raises the question of interface deprecation, and it
> should
> theoretically follow the process described at:
>
> https://wiki.qemu.org/Features/LegacyRemoval#Rules_for_removing_an_interface
>
> Cc'ing Thomas, our Chief Deprecation Officer, for insights :)
> >>>
> >>> The property is a public interface. Just because it's not used by
> >>> libvirt does not mean that nobody is using it. So yes, please follow the
> >>> rules and mark it as deprecated first for two release, before you really
> >>> remove it.
> >>
> >> This "irq" property is a problem to introduce a new static layout of IRQ
> >> numbers. It is in complete opposition.
> >>
> >> Can we keep it as it is for old pseries machine (settable) and ignore it
> >> for newer ? Would that be fine ?
> >
> > So, Thomas is right that we need to keep the interface while we go
> > through the deprecation process, even though it's a bit of a pain
> > (like you, I seriously doubt anyone ever used it).
>
> That's OK. The patch is simple. But it means that we have to keep the
> irq_hint parameter for 2 QEMU versions.
No.. the suggestion below is designed to avoid that..
> > But, I think there's a way to avoid that getting in the way of your
> > cleanups too much.
> >
> > A bunch of the current problems are caused because spapr_irq_alloc()
> > conflates two meanings of "allocate": 1) finding a free irq to use for
> > this device and 2) assigning that irq exclusively to this device.
> >
> > I think the first thing to do is to split those two parts. (1) will
> > never take an irq parameter, (2) will always take an irq parameter.
> > To implement the (to be deprecated) "irq" property on vio devices you
> > should skip (1) and just call (2) with the given irq number.
>
> well, we need to call both because if "irq" is zero then when we
> fallback to "1) finding a free irq to use."
No, basically in the VIO code itself you'd have:
irq = ;
if (!irq)
irq = find_irq()
claim_irq(irq);
find_irq() never takes a hint, claim_irq() always does (except it's
not really a hint).
> But we can move the exclusive IRQ assignment (2) under the VIO model
> which is the only one using it and start deprecating the property.
No.. the exclusive claim would be global - everything would use that.
> > The point of this series is to basically get rid of (1), but this
> > first step means we don't need to worry about the hint parameter as we
> > gradually remove it.
>
> OK. I think I got what you are asking for. (2) means adding an extra
> handler to the sPAPR IRQ interface, which would always fail in the
> new XICS sPAPR IRQ backend using static numbers.
No.. (2), "claim_irq()" as I called it above, would _always_ be used.
find_irq() would only be used to implement the legacy allocation.
In various places we'll have code like this:
if (legacy) {
irq = find_irq();
} else {
irq = ;
}
claim_irq(irq);
Where that fixed value could be something like:
irq = PCI_LSI_BASE + phb->index*4 + pin#;
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
Re: [Qemu-devel] [PATCH v2 5/8] hw/timer: Add basic M41T80 emulation
On Wed, Jun 06, 2018 at 07:35:28PM +0200, BALATON Zoltan wrote:
> On Wed, 6 Jun 2018, Philippe Mathieu-Daudé wrote:
> > On 06/06/2018 10:31 AM, BALATON Zoltan wrote:
> > > Basic emulation of the M41T80 serial (I2C) RTC chip. Only getting time
> > > of day is implemented. Setting time and RTC alarm are not supported.
> [...]
> > > diff --git a/hw/timer/m41t80.c b/hw/timer/m41t80.c
> > > new file mode 100644
> > > index 000..9dbdb1b
> > > --- /dev/null
> > > +++ b/hw/timer/m41t80.c
> > > @@ -0,0 +1,117 @@
> > > +/*
> > > + * M41T80 serial rtc emulation
> > > + *
> > > + * Copyright (c) 2018 BALATON Zoltan
> > > + *
> > > + * This work is licensed under the GNU GPL license version 2 or later.
> > > + *
> > > + */
> > > +
> > > +#include "qemu/osdep.h"
> > > +#include "qemu/log.h"
> > > +#include "qemu/timer.h"
> > > +#include "qemu/bcd.h"
> > > +#include "hw/i2c/i2c.h"
> > > +
> > > +#define TYPE_M41T80 "m41t80"
> > > +#define M41T80(obj) OBJECT_CHECK(M41t80State, (obj), TYPE_M41T80)
> > > +
> > > +typedef struct M41t80State {
> > > +I2CSlave parent_obj;
> > > +int8_t addr;
> > > +} M41t80State;
> > > +
> > > +static void m41t80_realize(DeviceState *dev, Error **errp)
> > > +{
> > > +M41t80State *s = M41T80(dev);
> > > +
> > > +s->addr = -1;
> > > +}
> > > +
> > > +static int m41t80_send(I2CSlave *i2c, uint8_t data)
> > > +{
> > > +M41t80State *s = M41T80(i2c);
> > > +
> > > +if (s->addr < 0) {
> > > +s->addr = data;
> > > +} else {
> > > +s->addr++;
> > > +}
> >
> > What about adding enum i2c_event in M41t80State and use the enum here
> > rather than the addr < 0? Also this wrap at INT8_MAX = 127, is this
> > expected?
>
> Thanks for the review. I guess we could add enum for device bytes and the
> special case -1 meaning no register address selected yet but this is a very
> simple device with only 20 bytes and the datasheet also lists them by number
> without naming them so I think we can also refer to them by number. Since
> the device has only this 20 bytes the case with 127 should also not be a
> problem as that's invalid address anyway. Or did you mean something else?
So, I'm not particularly in favour of adding extra state variables.
But is using addr < 0 safe here? You're assigning the uint8_t data to
addr - could that result in a negative value?
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
Re: [Qemu-devel] Is there a way to package QEMU binaries?
On Tue, Jun 12, 2018 at 09:52:45AM +0100, Peter Maydell wrote: > On 12 June 2018 at 07:24, Peter Xu wrote: > > For example, I wanted to compile QEMU once and install it on multiple > > systems. What would be the suggested way to do so? > > For this, I would recommend using whatever the packaging > format for those systems is. Eg for Debian use the existing > Debian QEMU packages, for Redhat systems use RPMs, etc. > If you want a newer version of QEMU than is in the distro's > packages, you can probably forward port the packaging parts > to a newer QEMU without too much pain. > > Or you can use a distro-agnostic packaging tool of some sort; > there are a few out there but I have no particular recommendations. I'll start my investigation with RPM first. Thanks Peter. -- Peter Xu
Re: [Qemu-devel] [PATCH] tracing.txt: add missing '-' for trace option
On Tue, Jun 12, 2018 at 23:15:49 -0400, Yaowei Bai wrote: > Signed-off-by: Yaowei Bai > --- > docs/devel/tracing.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/docs/devel/tracing.txt b/docs/devel/tracing.txt > index 07abbb3..6ab32cc 100644 > --- a/docs/devel/tracing.txt > +++ b/docs/devel/tracing.txt > @@ -18,7 +18,7 @@ for debugging, profiling, and observing execution. > > 3. Run the virtual machine to produce a trace file: > > -qemu -trace events=/tmp/events ... # your normal QEMU invocation > +qemu --trace events=/tmp/events ... # your normal QEMU invocation The second dash is not missing; both '-args' and '--args' work. '-args' seems to be favoured though; see `qemu -h' or `qemu --h' :-) Emilio
[Qemu-devel] [PATCH v5] cutils: Provide strchrnul
strchrnul is a GNU extension and thus unavailable on a number of targets.
In the review for a commit removing strchrnul from 9p, I was asked to
create a qemu_strchrnul helper to factor out this functionality.
Do so, and use it in a number of other places in the code base that inlined
the replacement pattern in a place where strchrnul could be used.
Signed-off-by: Keno Fischer
Acked-by: Greg Kurz
---
Changes since v4:
- `CONFIG_STRCHRNUL` -> `HAVE_STRCHRNUL` name change
- In the strchrnul configure check
- Return the value of strchrnul to avoid it being optimized away
- Use `` (i.e. the assembly of the generated function as
the haystack) to avoid concerns about constant folding. `main`
seemed like the simplest symbol guaranteed to exist, but with
non-foldable content.
configure | 18 ++
hmp.c | 8
hw/9pfs/9p-local.c| 2 +-
include/qemu/cutils.h | 8
monitor.c | 8 ++--
util/cutils.c | 15 +++
util/qemu-option.c| 6 +-
util/uri.c| 6 ++
8 files changed, 51 insertions(+), 20 deletions(-)
diff --git a/configure b/configure
index 14b1113..8a75745 100755
--- a/configure
+++ b/configure
@@ -4747,6 +4747,21 @@ if compile_prog "" "" ; then
fi
##
+# check if we have strchrnul
+
+strchrnul=no
+cat > $TMPC << EOF
+#include
+int main(void);
+// Use a haystack that the compiler shouldn't be able to constant fold
+char *haystack = (char*)
+int main(void) { return strchrnul(haystack, 'x') != [6]; }
+EOF
+if compile_prog "" "" ; then
+strchrnul=yes
+fi
+
+##
# check if trace backend exists
$python "$source_path/scripts/tracetool.py" "--backends=$trace_backends"
--check-backends > /dev/null 2> /dev/null
@@ -6229,6 +6244,9 @@ fi
if test "$sem_timedwait" = "yes" ; then
echo "CONFIG_SEM_TIMEDWAIT=y" >> $config_host_mak
fi
+if test "$strchrnul" = "yes" ; then
+ echo "HAVE_STRCHRNUL=y" >> $config_host_mak
+fi
if test "$byteswap_h" = "yes" ; then
echo "CONFIG_BYTESWAP_H=y" >> $config_host_mak
fi
diff --git a/hmp.c b/hmp.c
index ef93f48..416d4c9 100644
--- a/hmp.c
+++ b/hmp.c
@@ -2123,12 +2123,12 @@ void hmp_sendkey(Monitor *mon, const QDict *qdict)
int has_hold_time = qdict_haskey(qdict, "hold-time");
int hold_time = qdict_get_try_int(qdict, "hold-time", -1);
Error *err = NULL;
-char *separator;
+const char *separator;
int keyname_len;
while (1) {
-separator = strchr(keys, '-');
-keyname_len = separator ? separator - keys : strlen(keys);
+separator = qemu_strchrnul(keys, '-');
+keyname_len = separator - keys;
/* Be compatible with old interface, convert user inputted "<" */
if (keys[0] == '<' && keyname_len == 1) {
@@ -2165,7 +2165,7 @@ void hmp_sendkey(Monitor *mon, const QDict *qdict)
keylist->value->u.qcode.data = idx;
}
-if (!separator) {
+if (!*separator) {
break;
}
keys = separator + 1;
diff --git a/hw/9pfs/9p-local.c b/hw/9pfs/9p-local.c
index 5721eff..828e8d6 100644
--- a/hw/9pfs/9p-local.c
+++ b/hw/9pfs/9p-local.c
@@ -65,7 +65,7 @@ int local_open_nofollow(FsContext *fs_ctx, const char *path,
int flags,
assert(*path != '/');
head = g_strdup(path);
-c = strchrnul(path, '/');
+c = qemu_strchrnul(path, '/');
if (*c) {
/* Intermediate path element */
head[c - path] = 0;
diff --git a/include/qemu/cutils.h b/include/qemu/cutils.h
index a663340..274d419 100644
--- a/include/qemu/cutils.h
+++ b/include/qemu/cutils.h
@@ -122,6 +122,14 @@ int qemu_strnlen(const char *s, int max_len);
* Returns: the pointer originally in @input.
*/
char *qemu_strsep(char **input, const char *delim);
+#ifdef HAVE_STRCHRNUL
+static inline const char *qemu_strchrnul(const char *s, int c)
+{
+return strchrnul(s, c);
+}
+#else
+const char *qemu_strchrnul(const char *s, int c);
+#endif
time_t mktimegm(struct tm *tm);
int qemu_fdatasync(int fd);
int fcntl_setfl(int fd, int flag);
diff --git a/monitor.c b/monitor.c
index 6d0cec5..4484d74 100644
--- a/monitor.c
+++ b/monitor.c
@@ -797,9 +797,7 @@ static int compare_cmd(const char *name, const char *list)
p = list;
for(;;) {
pstart = p;
-p = strchr(p, '|');
-if (!p)
-p = pstart + strlen(pstart);
+p = qemu_strchrnul(p, '|');
if ((p - pstart) == len && !memcmp(pstart, name, len))
return 1;
if (*p == '\0')
@@ -3400,9 +3398,7 @@ static void cmd_completion(Monitor *mon, const char
*name, const char *list)
p = list;
for(;;) {
pstart = p;
-p = strchr(p, '|');
-if (!p)
-p = pstart + strlen(pstart);
+p = qemu_strchrnul(p, '|');
len = p - pstart;
if (len >
Re: [Qemu-devel] Is there a way to package QEMU binaries?
On Tue, Jun 12, 2018 at 12:53:36AM -0700, Liviu Ionescu wrote: > On 12 June 2018 at 10:44:09, Peter Xu (pet...@redhat.com) wrote: > > > But it'll still be good if we can have a single package to play around > > with. If there is no known way to do, we can try to figure a way out. > > you can take a look at: > > https://github.com/gnu-mcu-eclipse/qemu-build > > the scripts can create the binary distributions for windows, linux and > macos in one run, with all required libraries and everything. > > the result looks like this: > > https://github.com/gnu-mcu-eclipse/qemu/releases This might be a bit heavy weighted to me (I would only use that for debugging purpose basically on single platform, and more frequently), but still good to know such a project and thank you for your reply! -- Peter Xu
Re: [Qemu-devel] Is there a way to package QEMU binaries?
On Tue, Jun 12, 2018 at 01:29:32PM +0200, Laszlo Ersek wrote: > Hi Fam, > > On 06/12/18 08:41, Fam Zheng wrote: > > On Tue, 06/12 14:24, Peter Xu wrote: > >> Hi, > >> > >> For example, I wanted to compile QEMU once and install it on multiple > >> systems. What would be the suggested way to do so? > >> > >> Is there something similar to "make bin-rpmpkg" for Linux? > >> > >> Thanks in advance, > > > > No. The big question is the libraries. Even if you create the rpm, the > > libraries > > that you have linked against are not necessarily available on the systems > > you > > install. This means you either list all possible libraries as required in > > the > > rpm spec, which is a waste, or the list is generated dynamically, which is > > not > > trivial. For example, you can easily build QEMU against a custom glib, but > > it's > > very tricky to generate an rpm from it that works on other systems. > > > > For development, maybe it's easier to combine git and Ansible. > > libvirt supports RPM builds out of the upstream git tree: > > ./autogen.sh ... > make rpm > > However, while QEMU doesn't support that, Peter's idea can be solved > quite simply: > > * run QEMU's configure with "--prefix=...". For example, > --prefix=/opt/qemu-. > > * If you make sure that the prefix configured above is writeable to a > non-root user, then "make install" can be executed without becoming root > first. > > * You can then tar up the installed file tree under prefix, and extract > it on other hosts (at the same absolute prefix). If the installation is > no longer needed, you can simply remove the file tree under the prefix. > > * The above procedure works basically for all open source packages > nowadays; however in order to actually use packages installed like this, > a number of environment variables may have to be extended so they refer > to various subdirectories under "prefix": > > - CPLUS_INCLUDE_PATH > (so g++ can find include files) > - C_INCLUDE_PATH > (so gcc can find include files) > - INFOPATH > (so "info" can find docs) > - LD_LIBRARY_PATH > (so ld.so can load shared objects at executable startup) > - LIBRARY_PATH > (so gcc/g++/ld can resolve "-l" options at link editing time) > - MANPATH > (so "man" can find docs) > - PATH > (so the shell finds the binary) > - PKG_CONFIG_PATH > (modern replacement for CPLUS_INCLUDE_PATH, C_INCLUDE_PATH, > and LIBRARY_PATH) > - PYTHONPATH > (so python can find python modules) > - ... > > On my laptop, I have a bunch of packages installed like this, and I have > a script that traverses /opt and generates another script that assigns > all of the above variables. This latter script is then sourced by my > ~/.bashrc. > > Considering QEMU specifically, only two of the above variables need to > be extended in practice: > > - MANPATH: append /share/man > - PATH: append /bin These steps might be a bit heavy-weighted for debugging purpose of mine, but please take my sincere thanks on all these steps! I believe I could use the idea somewhere, for example, this marco list is really a good thing to know when debugging libraries with old versions. Also, the "tar + pipe" magic you offered in the other thread with Fam is nice and more light-weighted to me. I'm considering maybe I'll read about how to "make binrpm" for QEMU some day in case it'll ease some of us. > > Summary: (1) configure QEMU with option "--prefix", (2) give rwx on > "prefix" to the user that builds and installs QEMU, (3) build and > install QEMU as that user, (3) transfer the tree under prefix to another > host, (4) expand to the same prefix on the target, (5) update MANPATH > and PATH on the target. And... you even provided a summary for all the steps! Thanks again, Laszlo! -- Peter Xu
Re: [Qemu-devel] [PATCH 1/2] cpu-defs.h: Document CPUIOTLBEntry 'addr' field
On Mon, Jun 11, 2018 at 13:56:32 +0100, Peter Maydell wrote:
> typedef struct CPUIOTLBEntry {
> +/*
> + * @addr contains:
> + * - in the lower TARGET_PAGE_BITS, a physical section number
> + * - with the lower TARGET_PAGE_BITS masked off, an offset which
> + *must be added to the virtual address to obtain:
> + * + the ramaddr_t of the target RAM (if the physical section
s/ramaddr_t/ram_addr_t/ ? Also in cputlb.c:
> + * TARGET_PAGE_BITS, and either
> + * + the ramaddr_t of the page base of the target RAM (if NOTDIRTY or
> ROM)
Thanks,
Emilio
[Qemu-devel] [PATCH] tracing.txt: add missing '-' for trace option
Signed-off-by: Yaowei Bai --- docs/devel/tracing.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/devel/tracing.txt b/docs/devel/tracing.txt index 07abbb3..6ab32cc 100644 --- a/docs/devel/tracing.txt +++ b/docs/devel/tracing.txt @@ -18,7 +18,7 @@ for debugging, profiling, and observing execution. 3. Run the virtual machine to produce a trace file: -qemu -trace events=/tmp/events ... # your normal QEMU invocation +qemu --trace events=/tmp/events ... # your normal QEMU invocation 4. Pretty-print the binary trace file: -- 1.8.3.1
Re: [Qemu-devel] [PATCH] exec: Fix MAP_RAM for cached access
On Tue, Jun 12, 2018 at 09:05:25PM +0200, Eric Auger wrote:
> When an IOMMUMemoryRegion is in front of a virtio device,
> address_space_cache_init does not set cache->ptr as the memory
> region is not RAM. However when the device performs an access,
> we end up in glue() which performs the translation and then uses
> MAP_RAM. This latter uses the unset ptr and returns a wrong value
> which leads to a SIGSEV in address_space_lduw_internal_cached_slow,
> for instance. Let's test whether the cache->ptr is set, and in
> the negative use the old macro definition. This fixes the
> use cases featuring vIOMMU (Intel and ARM SMMU) which lead to
> a SIGSEV.
>
> Fixes: 48564041a73a (exec: reintroduce MemoryRegion caching)
> Signed-off-by: Eric Auger
>
> ---
>
> I am not sure whether it doesn't break any targeted optimization
> but at least it removes the SIGSEV.
>
> Signed-off-by: Eric Auger
> ---
> exec.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/exec.c b/exec.c
> index f6645ed..46fbd25 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -3800,7 +3800,9 @@ address_space_write_cached_slow(MemoryRegionCache
> *cache, hwaddr addr,
> #define SUFFIX _cached_slow
> #define TRANSLATE(...) address_space_translate_cached(cache,
> __VA_ARGS__)
> #define IS_DIRECT(mr, is_write) memory_access_is_direct(mr, is_write)
> -#define MAP_RAM(mr, ofs) (cache->ptr + (ofs - cache->xlat))
> +#define MAP_RAM(mr, ofs) (cache->ptr ? \
> + (cache->ptr + (ofs - cache->xlat)) : \
> + qemu_map_ram_ptr((mr)->ram_block, ofs))
A pure question: if the MR is not a RAM (I think the only case for
virtio case should be an IOMMU MR), then why we'll call MAP_RAM()
after all? An glue() example:
void glue(address_space_stb, SUFFIX)(ARG1_DECL,
hwaddr addr, uint32_t val, MemTxAttrs attrs, MemTxResult *result)
{
uint8_t *ptr;
MemoryRegion *mr;
hwaddr l = 1;
hwaddr addr1;
MemTxResult r;
bool release_lock = false;
RCU_READ_LOCK();
mr = TRANSLATE(addr, , , true, attrs);
if (!IS_DIRECT(mr, true)) {<- [1]
release_lock |= prepare_mmio_access(mr);
r = memory_region_dispatch_write(mr, addr1, val, 1, attrs);
} else {
/* RAM case */
ptr = MAP_RAM(mr, addr1);
stb_p(ptr, val);
INVALIDATE(mr, addr1, 1);
r = MEMTX_OK;
}
if (result) {
*result = r;
}
if (release_lock) {
qemu_mutex_unlock_iothread();
}
RCU_READ_UNLOCK();
}
At [1] we should check first against whether it's direct after all.
AFAIU IOMMU MR should not be direct then it'll go the slow path rather
than calling MAP_RAM()?
Since at it, I have another (pure) question about the address space
cache. I don't think it's urgent since I think it's never a problem
for virtio, but I'm still asking anyways...
Still taking the stb example:
static inline void address_space_stb_cached(MemoryRegionCache *cache,
hwaddr addr, uint32_t val, MemTxAttrs attrs, MemTxResult *result)
{
assert(addr < cache->len); <- [2]
if (likely(cache->ptr)) {
stb_p(cache->ptr + addr, val);
} else {
address_space_stb_cached_slow(cache, addr, val, attrs, result);
}
}
Here at [2] what if the region cached is smaller than provided when
doing address_space_cache_init()? AFAIU the "len" provided to
address_space_cache_init() can actually shrink (though for virtio it
should never) when do:
l = len;
...
cache->mrs = *address_space_translate_internal(d, addr, >xlat, ,
true);
...
cache->len = l;
And here not sure whether we should not assert, instead we only run
the fast path if the address falls into the cache region, say:
static inline void address_space_stb_cached(MemoryRegionCache *cache,
hwaddr addr, uint32_t val, MemTxAttrs attrs, MemTxResult *result)
{
if (likely(cache->ptr && addr < cache->len)) {
stb_p(cache->ptr + addr, val);
} else {
address_space_stb_cached_slow(cache, addr, val, attrs, result);
}
}
Or we should add a check in address_space_cache_init() to make sure
the region won't shrink.
Regards,
--
Peter Xu
Re: [Qemu-devel] [PATCH v4b 00/18] target/arm: SVE instructions, part 2
Hi, This series seems to have some coding style problems. See output below for more information: Type: series Message-id: 20180613015641.5667-1-richard.hender...@linaro.org Subject: [Qemu-devel] [PATCH v4b 00/18] target/arm: SVE instructions, part 2 === TEST SCRIPT BEGIN === #!/bin/bash BASE=base n=1 total=$(git log --oneline $BASE.. | wc -l) failed=0 git config --local diff.renamelimit 0 git config --local diff.renames True git config --local diff.algorithm histogram commits="$(git log --format=%H --reverse $BASE..)" for c in $commits; do echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..." if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then failed=1 echo fi n=$((n+1)) done exit $failed === TEST SCRIPT END === Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384 Switched to a new branch 'test' d3104242cb target/arm: Implement SVE Floating Point Arithmetic - Unpredicated Group 0ea2461007 target/arm: Implement SVE Integer Wide Immediate - Unpredicated Group 18a818eb47 target/arm: Implement FDUP/DUP 7f1af2a272 target/arm: Implement SVE Integer Compare - Scalars Group b131f594f6 target/arm: Implement SVE Predicate Count Group 1eaefa4668 target/arm: Implement SVE Partition Break Group c55e12b07b target/arm: Implement SVE Integer Compare - Immediate Group f9f8d5d72f target/arm: Implement SVE Integer Compare - Vectors Group 37d52afaa6 target/arm: Implement SVE Select Vectors Group b799bbce3d target/arm: Implement SVE vector splice (predicated) fafdc0fe92 target/arm: Implement SVE reverse within elements 1145a50559 target/arm: Implement SVE copy to vector (predicated) 394600eb0d target/arm: Implement SVE conditionally broadcast/extract element f97a7773f6 target/arm: Implement SVE compress active elements 31de221ead target/arm: Implement SVE Permute - Interleaving Group 4a8e4e671a target/arm: Implement SVE Permute - Predicates Group d768f8bba5 target/arm: Implement SVE Permute - Unpredicated Group 9950c97fef target/arm: Extend vec_reg_offset to larger sizes === OUTPUT BEGIN === Checking PATCH 1/18: target/arm: Extend vec_reg_offset to larger sizes... Checking PATCH 2/18: target/arm: Implement SVE Permute - Unpredicated Group... ERROR: space prohibited before that close parenthesis ')' #116: FILE: target/arm/sve_helper.c:1575: +DO_INSR(sve_insr_d, uint64_t, ) ERROR: space prohibited before that close parenthesis ')' #190: FILE: target/arm/sve_helper.c:1649: +DO_TBL(sve_tbl_d, uint64_t, ) total: 2 errors, 0 warnings, 330 lines checked Your patch has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in MAINTAINERS. Checking PATCH 3/18: target/arm: Implement SVE Permute - Predicates Group... Checking PATCH 4/18: target/arm: Implement SVE Permute - Interleaving Group... ERROR: space prohibited before that close parenthesis ')' #89: FILE: target/arm/sve_helper.c:1991: +DO_ZIP(sve_zip_d, uint64_t, ) ERROR: space prohibited before that close parenthesis ')' #113: FILE: target/arm/sve_helper.c:2015: +DO_UZP(sve_uzp_d, uint64_t, ) ERROR: space prohibited before that close parenthesis ')' #132: FILE: target/arm/sve_helper.c:2034: +DO_TRN(sve_trn_d, uint64_t, ) total: 3 errors, 0 warnings, 193 lines checked Your patch has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in MAINTAINERS. Checking PATCH 5/18: target/arm: Implement SVE compress active elements... Checking PATCH 6/18: target/arm: Implement SVE conditionally broadcast/extract element... Checking PATCH 7/18: target/arm: Implement SVE copy to vector (predicated)... Checking PATCH 8/18: target/arm: Implement SVE reverse within elements... Checking PATCH 9/18: target/arm: Implement SVE vector splice (predicated)... Checking PATCH 10/18: target/arm: Implement SVE Select Vectors Group... Checking PATCH 11/18: target/arm: Implement SVE Integer Compare - Vectors Group... ERROR: spaces required around that '==' (ctx:WxB) #268: FILE: target/arm/sve_helper.c:2279: +DO_CMP_PPZZ_B(sve_cmpeq_ppzz_b, uint8_t, ==) ^ ERROR: spaces required around that '==' (ctx:WxB) #269: FILE: target/arm/sve_helper.c:2280: +DO_CMP_PPZZ_H(sve_cmpeq_ppzz_h, uint16_t, ==) ^ ERROR: spaces required around that '==' (ctx:WxB) #270: FILE: target/arm/sve_helper.c:2281: +DO_CMP_PPZZ_S(sve_cmpeq_ppzz_s, uint32_t, ==) ^ ERROR: spaces required around that '==' (ctx:WxB) #271: FILE: target/arm/sve_helper.c:2282: +DO_CMP_PPZZ_D(sve_cmpeq_ppzz_d, uint64_t, ==) ^ ERROR: spaces required around that '!=' (ctx:WxB) #273: FILE: target/arm/sve_helper.c:2284: +DO_CMP_PPZZ_B(sve_cmpne_ppzz_b, uint8_t, !=) ^ ERROR: spaces required around that '!=' (ctx:WxB) #274: FILE:
Re: [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
On 2018年06月13日 08:20, Samudrala, Sridhar wrote: On 6/12/2018 4:54 AM, Michael S. Tsirkin wrote: On Wed, Jun 06, 2018 at 10:29:03AM +0800, Jason Wang wrote: On 2018年06月05日 20:33, Michael S. Tsirkin wrote: I don't think this is sufficient. If both primary and standby devices are present, a legacy guest without support for the feature might see two devices with same mac and get confused. I think that we should only make primary visible after guest acked the backup feature bit. I think we want exactly the reverse? E.g fail the negotiation when guest does not ack backup feature. Otherwise legacy guest won't even have the chance to see primary device in the guest. That's by design. And on reset or when backup is cleared in some other way, unplug the primary. What if guest does not support hotplug? It shouldn't ack the backup feature then and it's a good point. We should both document this and check kernel config has hotplug support. Sridhar could you take a look pls? Right now we select NET_FAILOVER when virtio-net is enabled, Should we select PCI_HOTPLUG when NET_FAILOVER is enabled? Maybe I was wrong but it looks to me PCI_HOTPLUG is no sufficient since it depends on other to work e.g HOTPLUG_PCI_ACPI. Thanks
Re: [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
On 2018年06月12日 19:54, Michael S. Tsirkin wrote:
On Wed, Jun 06, 2018 at 10:29:03AM +0800, Jason Wang wrote:
On 2018年06月05日 20:33, Michael S. Tsirkin wrote:
I don't think this is sufficient.
If both primary and standby devices are present, a legacy guest without
support for the feature might see two devices with same mac and get
confused.
I think that we should only make primary visible after guest acked the
backup feature bit.
I think we want exactly the reverse? E.g fail the negotiation when guest
does not ack backup feature.
Otherwise legacy guest won't even have the chance to see primary device in
the guest.
That's by design.
So management needs to know the capability of guest to set the backup
feature. This looks a chicken or egg problem to me.
And on reset or when backup is cleared in some other way, unplug the
primary.
What if guest does not support hotplug?
It shouldn't ack the backup feature then and it's a good point.
We should both document this and check kernel config has
hotplug support. Sridhar could you take a look pls?
Something like the below will do the job:
Primary device is added with a special "primary-failover" flag.
A virtual machine is then initialized with just a standby virtio
device. Primary is not yet added.
A question is how to do the matching? Qemu knows nothing about e.g mac
address of a pass-through device I believe?
Supply a flag to the VFIO when it's added, this way QEMU will know.
Later QEMU detects that guest driver device set DRIVER_OK.
It then exposes the primary device to the guest, and triggers
a device addition event (hot-plug event) for it.
Do you mean we won't have primary device in the initial qemu cli?
No, that's not what I mean.
I mean management will supply a flag to VFIO and then
- VFIO defers exposing
primary to guest until guest acks the feature bit.
- When we see guest ack, initiate hotplug.
- On reboot, hide it again.
- On reset without reboot, request hot-unplug and on eject hide it again.
This sounds much like a kind of bonding in qemu.
If QEMU detects guest driver removal, it initiates a hot-unplug sequence
to remove the primary driver. In particular, if QEMU detects guest
re-initialization (e.g. by detecting guest reset) it immediately removes
the primary device.
I believe guest failover module should handle this gracefully?
It can't control enumeration order, if primary is enumerated before
standby then guest will load its driver and it's too late
when failover driver is loaded.
Well, even if we can delay the visibility of primary until DRIVER_OK,
there still be a race I think? And it looks to me it's still a bug of guest:
E.g primary could be probed before failover_register() in guest. Then we
will miss the enslaving of primary forever.
Thanks
Thanks
We can move some of this code to management as well, architecturally it
does not make too much sense but it might be easier implementation-wise.
HTH
On Mon, Jun 04, 2018 at 06:41:48PM -0700, Samudrala, Sridhar wrote:
Ping on this patch now that the kernel patches are accepted into davem's
net-next tree.
https://patchwork.ozlabs.org/cover/920005/
On 5/7/2018 4:09 PM, Sridhar Samudrala wrote:
This feature bit can be used by hypervisor to indicate virtio_net device to
act as a standby for another device with the same MAC address.
I tested this with a small change to the patch to mark the STANDBY feature
'true'
by default as i am using libvirt to start the VMs.
Is there a way to pass the newly added feature bit 'standby' to qemu via libvirt
XML file?
Signed-off-by: Sridhar Samudrala
---
hw/net/virtio-net.c | 2 ++
include/standard-headers/linux/virtio_net.h | 3 +++
2 files changed, 5 insertions(+)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 90502fca7c..38b3140670 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -2198,6 +2198,8 @@ static Property virtio_net_properties[] = {
true),
DEFINE_PROP_INT32("speed", VirtIONet, net_conf.speed, SPEED_UNKNOWN),
DEFINE_PROP_STRING("duplex", VirtIONet, net_conf.duplex_str),
+DEFINE_PROP_BIT64("standby", VirtIONet, host_features,
VIRTIO_NET_F_STANDBY,
+ false),
DEFINE_PROP_END_OF_LIST(),
};
diff --git a/include/standard-headers/linux/virtio_net.h
b/include/standard-headers/linux/virtio_net.h
index e9f255ea3f..01ec09684c 100644
--- a/include/standard-headers/linux/virtio_net.h
+++ b/include/standard-headers/linux/virtio_net.h
@@ -57,6 +57,9 @@
* Steering */
#define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
+#define VIRTIO_NET_F_STANDBY 62/* Act as standby for another device
+ * with the same MAC.
+ */
#define VIRTIO_NET_F_SPEED_DUPLEX 63/* Device set linkspeed and
duplex */
#ifndef
Re: [Qemu-devel] [PATCH] e1000e: Do not auto-clear ICR bits which aren't set in EIAC
On 2018年06月13日 10:26, Philippe Mathieu-Daudé wrote:
Hi Jason,
On 06/12/2018 11:18 PM, Jason Wang wrote:
On 2018年06月13日 03:00, Philippe Mathieu-Daudé wrote:
Cc'ing Jason who is also listed as co-maintainer:
./scripts/get_maintainer.pl -f hw/net/e1000e_core.c
Dmitry Fleytman (maintainer:e1000e)
Jason Wang (odd fixer:Network devices)
On 06/12/2018 03:43 PM, Jan Kiszka wrote:
On 2018-06-12 20:38, Philippe Mathieu-Daudé wrote:
On 06/12/2018 03:30 PM, Jan Kiszka wrote:
On 2018-06-12 20:11, Philippe Mathieu-Daudé wrote:
Hi Jan,
On 06/12/2018 02:22 PM, Jan Kiszka wrote:
On 2018-05-22 09:00, Jan Kiszka wrote:
On 2018-04-16 17:29, Peter Maydell wrote:
On 16 April 2018 at 16:25, Jan Kiszka
wrote:
On 2018-04-01 23:17, Jan Kiszka wrote:
From: Jan Kiszka
The spec does not justify clearing of any
E1000_ICR_OTHER_CAUSES when
E1000_ICR_OTHER is set in EIAC. In fact, removing this code
fixes the
issue the Linux driver runs into since 4aea7a5c5e94 ("e1000e:
Avoid
receiver overrun interrupt bursts") and was worked around by
745d0bd3af99 ("e1000e: Remove Other from EIAC").
Signed-off-by: Jan Kiszka
---
This resolves the issue I reported on February 18 ("e1000e:
MSI-X
problem with recent Linux drivers").
hw/net/e1000e_core.c | 4
1 file changed, 4 deletions(-)
diff --git a/hw/net/e1000e_core.c b/hw/net/e1000e_core.c
index ecf9b1..d38f025c0f 100644
--- a/hw/net/e1000e_core.c
+++ b/hw/net/e1000e_core.c
@@ -2022,10 +2022,6 @@ e1000e_msix_notify_one(E1000ECore
*core, uint32_t cause, uint32_t int_cfg)
effective_eiac = core->mac[EIAC] & cause;
- if (effective_eiac == E1000_ICR_OTHER) {
- effective_eiac |= E1000_ICR_OTHER_CAUSES;
- }
-
core->mac[ICR] &= ~effective_eiac;
if (!(core->mac[CTRL_EXT] & E1000_CTRL_EXT_IAME)) {
Ping for this - as well as
https://patchwork.ozlabs.org/patch/895476.
Given that q35 uses e1000e by default and many Linux kernel
versions no
longer work, this should likely go into upcoming and stable
versions
I'd rather not put it into 2.12 at this point in the release
cycle unless it's a regression from 2.11, I think.
Second ping - nothing hit the repo so far, nor did I receive
feedback.
And another ping. For both.
These days I had to help someone with a broken QEMU setup that
failed
installing from network. It turned out that "modprobe e1000e
IntMode=0"
was needed to workaround the issues my patches address.
What about the IMS register? It is set just after.
Looking at b38636b8372, can you test this patch?
-- >8 --
diff --git a/hw/net/e1000e_core.c b/hw/net/e1000e_core.c
index c93c4661ed..a484b68a5a 100644
--- a/hw/net/e1000e_core.c
+++ b/hw/net/e1000e_core.c
@@ -2022,13 +2022,13 @@ e1000e_msix_notify_one(E1000ECore *core,
uint32_t cause, uint32_t int_cfg)
effective_eiac = core->mac[EIAC] & cause;
- if (effective_eiac == E1000_ICR_OTHER) {
- effective_eiac |= E1000_ICR_OTHER_CAUSES;
- }
-
core->mac[ICR] &= ~effective_eiac;
if (!(core->mac[CTRL_EXT] & E1000_CTRL_EXT_IAME)) {
+ if (effective_eiac == E1000_ICR_OTHER) {
+ effective_eiac |= E1000_ICR_OTHER_CAUSES;
+ }
+
core->mac[IMS] &= ~effective_eiac;
}
}
Before testing this: What would be the reasoning for this change?
Not breaking the purpose of b38636b8372 :)
I disagree on this expansion of bit 31 ("other causes"). I see no
indication in the spec that setting this bit for autoclear has more
impact than on the very same bit itself. Therefore I'm asking for a
reasoning - based on the spec.
Interrupt Cause Registers
Other bits in this register are the legacy indication of
interrupts as the MDIC complete, management and link status
change. There is a specific Other Cause bit that is set if
one of these bits are set, this bit can be mapped to a
specific MSI-X interrupt message.
I spent half an hour reading the relevant parts of the spec and can't
figure out, so I'll let the authors of b38636b8372 to review your patch.
Regards,
Phil.
Looking at EIAC part of the spec:
Bits 24:20 in this register enables clearing of the corresponding bit in
ICR following
interrupt generation. When a bit is set, the corresponding bit in ICR
and in IMS is
automatically cleared following an interrupt.
Thanks for looking at this.
It looks to me that only the other bit itself need to be cleared.
So no need to set the other_causes bits, thus Jan patch is correct?
Thanks,
Phil.
Yes, I think so. But I think we can wait for few days to see if Dmitry
have come comments.
Thanks
Re: [Qemu-devel] [PATCH] kvm: Delete the slot only when KVM_MEM_READONLY flag is changed
On 2018/6/12 20:17, Paolo Bonzini wrote:
> On 16/05/2018 11:18, Shannon Zhao wrote:
>> According to KVM commit 75d61fbc, it needs to delete the slot before
>> changing the KVM_MEM_READONLY flag. But QEMU commit 235e8982 only check
>> whether KVM_MEM_READONLY flag is set instead of changing. It doesn't
>> need to delete the slot if the KVM_MEM_READONLY flag is not changed.
>>
>> This fixes a issue that migrating a VM at the OVMF startup stage and
>> VM is executing the codes in rom. Between the deleting and adding the
>> slot in kvm_set_user_memory_region, there is a chance that guest access
>> rom and trap to KVM, then KVM can't find the corresponding memslot.
>> While KVM (on ARM) injects an abort to guest due to the broken hva, then
>> guest will get stuck.
>>
>> Signed-off-by: Shannon Zhao
>
> I'm a bit worried about old_flags not being set on all paths to
> kvm_set_user_memory_region. This would lead to extra
> KVM_SET_USER_MEMORY_REGION calls. It should not be a problem but
> it is ugly. Does something like the additional changes below work for you?
>
I test below patch. It works for our testcase.
Do I need to fold them into one and resend?
Thanks,
--
Shannon
> Thanks,
>
> Paolo
>
>
> diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
> index b04f193a76..e318bcfb78 100644
> --- a/accel/kvm/kvm-all.c
> +++ b/accel/kvm/kvm-all.c
> @@ -257,7 +257,7 @@ int kvm_physical_memory_addr_from_host(KVMState *s, void
> *ram,
> return 0;
> }
>
> -static int kvm_set_user_memory_region(KVMMemoryListener *kml, KVMSlot *slot)
> +static int kvm_set_user_memory_region(KVMMemoryListener *kml, KVMSlot *slot,
> bool new)
> {
> KVMState *s = kvm_state;
> struct kvm_userspace_memory_region mem;
> @@ -268,7 +268,7 @@ static int kvm_set_user_memory_region(KVMMemoryListener
> *kml, KVMSlot *slot)
> mem.userspace_addr = (unsigned long)slot->ram;
> mem.flags = slot->flags;
>
> -if (slot->memory_size && (mem.flags ^ slot->old_flags) &
> KVM_MEM_READONLY) {
> +if (slot->memory_size && !new && (mem.flags ^ slot->old_flags) &
> KVM_MEM_READONLY) {
> /* Set the slot size to 0 before setting the slot to the desired
> * value. This is needed based on KVM commit 75d61fbc. */
> mem.memory_size = 0;
> @@ -276,6 +276,7 @@ static int kvm_set_user_memory_region(KVMMemoryListener
> *kml, KVMSlot *slot)
> }
> mem.memory_size = slot->memory_size;
> ret = kvm_vm_ioctl(s, KVM_SET_USER_MEMORY_REGION, );
> +slot->old_flags = mem.flags;
> trace_kvm_set_user_memory(mem.slot, mem.flags, mem.guest_phys_addr,
>mem.memory_size, mem.userspace_addr, ret);
> return ret;
> @@ -394,7 +395,6 @@ static int kvm_slot_update_flags(KVMMemoryListener *kml,
> KVMSlot *mem,
> {
> int old_flags;
>
> -mem->old_flags = mem->flags;
> mem->flags = kvm_mem_flags(mr);
>
> /* If nothing changed effectively, no need to issue ioctl */
> @@ -402,7 +402,7 @@ static int kvm_slot_update_flags(KVMMemoryListener *kml,
> KVMSlot *mem,
> return 0;
> }
>
> -return kvm_set_user_memory_region(kml, mem);
> +return kvm_set_user_memory_region(kml, mem, false);
> }
>
> static int kvm_section_update_flags(KVMMemoryListener *kml,
> @@ -756,7 +756,8 @@ static void kvm_set_phys_mem(KVMMemoryListener *kml,
>
> /* unregister the slot */
> mem->memory_size = 0;
> -err = kvm_set_user_memory_region(kml, mem);
> +mem->flags = 0;
> +err = kvm_set_user_memory_region(kml, mem, false);
> if (err) {
> fprintf(stderr, "%s: error unregistering slot: %s\n",
> __func__, strerror(-err));
> @@ -772,7 +773,7 @@ static void kvm_set_phys_mem(KVMMemoryListener *kml,
> mem->ram = ram;
> mem->flags = kvm_mem_flags(mr);
>
> -err = kvm_set_user_memory_region(kml, mem);
> +err = kvm_set_user_memory_region(kml, mem, true);
> if (err) {
> fprintf(stderr, "%s: error registering slot: %s\n", __func__,
> strerror(-err));
>
> .
>
[Qemu-devel] [PATCH v2 01/10] qcow2/bitmap: remove redundant arguments from bitmap_list_load
We always call it with the same fields of the struct we always pass.
We can split this out later if we really wind up needing to.
Signed-off-by: John Snow
---
block/qcow2-bitmap.c | 23 +--
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/block/qcow2-bitmap.c b/block/qcow2-bitmap.c
index 69485aa1de..0670e5eb41 100644
--- a/block/qcow2-bitmap.c
+++ b/block/qcow2-bitmap.c
@@ -535,8 +535,7 @@ static uint32_t bitmap_list_count(Qcow2BitmapList *bm_list)
* Get bitmap list from qcow2 image. Actually reads bitmap directory,
* checks it and convert to bitmap list.
*/
-static Qcow2BitmapList *bitmap_list_load(BlockDriverState *bs, uint64_t offset,
- uint64_t size, Error **errp)
+static Qcow2BitmapList *bitmap_list_load(BlockDriverState *bs, Error **errp)
{
int ret;
BDRVQcow2State *s = bs->opaque;
@@ -544,6 +543,8 @@ static Qcow2BitmapList *bitmap_list_load(BlockDriverState
*bs, uint64_t offset,
Qcow2BitmapDirEntry *e;
uint32_t nb_dir_entries = 0;
Qcow2BitmapList *bm_list = NULL;
+uint64_t offset = s->bitmap_directory_offset;
+uint64_t size = s->bitmap_directory_size;
if (size == 0) {
error_setg(errp, "Requested bitmap directory size is zero");
@@ -655,8 +656,7 @@ int qcow2_check_bitmaps_refcounts(BlockDriverState *bs,
BdrvCheckResult *res,
return ret;
}
-bm_list = bitmap_list_load(bs, s->bitmap_directory_offset,
- s->bitmap_directory_size, NULL);
+bm_list = bitmap_list_load(bs, NULL);
if (bm_list == NULL) {
res->corruptions++;
return -EINVAL;
@@ -952,8 +952,7 @@ bool qcow2_load_dirty_bitmaps(BlockDriverState *bs, Error
**errp)
return false;
}
-bm_list = bitmap_list_load(bs, s->bitmap_directory_offset,
- s->bitmap_directory_size, errp);
+bm_list = bitmap_list_load(bs, errp);
if (bm_list == NULL) {
return false;
}
@@ -1026,8 +1025,7 @@ int qcow2_reopen_bitmaps_rw_hint(BlockDriverState *bs,
bool *header_updated,
return -EINVAL;
}
-bm_list = bitmap_list_load(bs, s->bitmap_directory_offset,
- s->bitmap_directory_size, errp);
+bm_list = bitmap_list_load(bs, errp);
if (bm_list == NULL) {
return -EINVAL;
}
@@ -1276,8 +1274,7 @@ void
qcow2_remove_persistent_dirty_bitmap(BlockDriverState *bs,
return;
}
-bm_list = bitmap_list_load(bs, s->bitmap_directory_offset,
- s->bitmap_directory_size, errp);
+bm_list = bitmap_list_load(bs, errp);
if (bm_list == NULL) {
return;
}
@@ -1329,8 +1326,7 @@ void
qcow2_store_persistent_dirty_bitmaps(BlockDriverState *bs, Error **errp)
if (s->nb_bitmaps == 0) {
bm_list = bitmap_list_new();
} else {
-bm_list = bitmap_list_load(bs, s->bitmap_directory_offset,
- s->bitmap_directory_size, errp);
+bm_list = bitmap_list_load(bs, errp);
if (bm_list == NULL) {
return;
}
@@ -1494,8 +1490,7 @@ bool qcow2_can_store_new_dirty_bitmap(BlockDriverState
*bs,
goto fail;
}
-bm_list = bitmap_list_load(bs, s->bitmap_directory_offset,
- s->bitmap_directory_size, errp);
+bm_list = bitmap_list_load(bs, errp);
if (bm_list == NULL) {
goto fail;
}
--
2.14.3
Re: [Qemu-devel] [PATCH] e1000e: Do not auto-clear ICR bits which aren't set in EIAC
Hi Jason,
On 06/12/2018 11:18 PM, Jason Wang wrote:
> On 2018年06月13日 03:00, Philippe Mathieu-Daudé wrote:
>> Cc'ing Jason who is also listed as co-maintainer:
>>
>> ./scripts/get_maintainer.pl -f hw/net/e1000e_core.c
>> Dmitry Fleytman (maintainer:e1000e)
>> Jason Wang (odd fixer:Network devices)
>>
>> On 06/12/2018 03:43 PM, Jan Kiszka wrote:
>>> On 2018-06-12 20:38, Philippe Mathieu-Daudé wrote:
On 06/12/2018 03:30 PM, Jan Kiszka wrote:
> On 2018-06-12 20:11, Philippe Mathieu-Daudé wrote:
>> Hi Jan,
>>
>> On 06/12/2018 02:22 PM, Jan Kiszka wrote:
>>> On 2018-05-22 09:00, Jan Kiszka wrote:
On 2018-04-16 17:29, Peter Maydell wrote:
> On 16 April 2018 at 16:25, Jan Kiszka
> wrote:
>> On 2018-04-01 23:17, Jan Kiszka wrote:
>>> From: Jan Kiszka
>>>
>>> The spec does not justify clearing of any
>>> E1000_ICR_OTHER_CAUSES when
>>> E1000_ICR_OTHER is set in EIAC. In fact, removing this code
>>> fixes the
>>> issue the Linux driver runs into since 4aea7a5c5e94 ("e1000e:
>>> Avoid
>>> receiver overrun interrupt bursts") and was worked around by
>>> 745d0bd3af99 ("e1000e: Remove Other from EIAC").
>>>
>>> Signed-off-by: Jan Kiszka
>>> ---
>>>
>>> This resolves the issue I reported on February 18 ("e1000e:
>>> MSI-X
>>> problem with recent Linux drivers").
>>>
>>> hw/net/e1000e_core.c | 4
>>> 1 file changed, 4 deletions(-)
>>>
>>> diff --git a/hw/net/e1000e_core.c b/hw/net/e1000e_core.c
>>> index ecf9b1..d38f025c0f 100644
>>> --- a/hw/net/e1000e_core.c
>>> +++ b/hw/net/e1000e_core.c
>>> @@ -2022,10 +2022,6 @@ e1000e_msix_notify_one(E1000ECore
>>> *core, uint32_t cause, uint32_t int_cfg)
>>>
>>> effective_eiac = core->mac[EIAC] & cause;
>>>
>>> - if (effective_eiac == E1000_ICR_OTHER) {
>>> - effective_eiac |= E1000_ICR_OTHER_CAUSES;
>>> - }
>>> -
>>> core->mac[ICR] &= ~effective_eiac;
>>>
>>> if (!(core->mac[CTRL_EXT] & E1000_CTRL_EXT_IAME)) {
>>>
>> Ping for this - as well as
>> https://patchwork.ozlabs.org/patch/895476.
>>
>> Given that q35 uses e1000e by default and many Linux kernel
>> versions no
>> longer work, this should likely go into upcoming and stable
>> versions
> I'd rather not put it into 2.12 at this point in the release
> cycle unless it's a regression from 2.11, I think.
Second ping - nothing hit the repo so far, nor did I receive
feedback.
>>> And another ping. For both.
>>>
>>> These days I had to help someone with a broken QEMU setup that
>>> failed
>>> installing from network. It turned out that "modprobe e1000e
>>> IntMode=0"
>>> was needed to workaround the issues my patches address.
>> What about the IMS register? It is set just after.
>>
>> Looking at b38636b8372, can you test this patch?
>>
>> -- >8 --
>> diff --git a/hw/net/e1000e_core.c b/hw/net/e1000e_core.c
>> index c93c4661ed..a484b68a5a 100644
>> --- a/hw/net/e1000e_core.c
>> +++ b/hw/net/e1000e_core.c
>> @@ -2022,13 +2022,13 @@ e1000e_msix_notify_one(E1000ECore *core,
>> uint32_t cause, uint32_t int_cfg)
>>
>> effective_eiac = core->mac[EIAC] & cause;
>>
>> - if (effective_eiac == E1000_ICR_OTHER) {
>> - effective_eiac |= E1000_ICR_OTHER_CAUSES;
>> - }
>> -
>> core->mac[ICR] &= ~effective_eiac;
>>
>> if (!(core->mac[CTRL_EXT] & E1000_CTRL_EXT_IAME)) {
>> + if (effective_eiac == E1000_ICR_OTHER) {
>> + effective_eiac |= E1000_ICR_OTHER_CAUSES;
>> + }
>> +
>> core->mac[IMS] &= ~effective_eiac;
>> }
>> }
>>
> Before testing this: What would be the reasoning for this change?
Not breaking the purpose of b38636b8372 :)
>>> I disagree on this expansion of bit 31 ("other causes"). I see no
>>> indication in the spec that setting this bit for autoclear has more
>>> impact than on the very same bit itself. Therefore I'm asking for a
>>> reasoning - based on the spec.
>> Interrupt Cause Registers
>>
>> Other bits in this register are the legacy indication of
>> interrupts as the MDIC complete, management and link status
>> change. There is a specific Other Cause bit that is set if
>> one of these bits are set, this bit can be mapped to a
>> specific MSI-X interrupt message.
>>
>> I spent half an hour reading the relevant parts of the spec and can't
>> figure out, so I'll let the authors of b38636b8372 to review your patch.
>>
>> Regards,
>>
>> Phil.
>
> Looking at EIAC part of the
[Qemu-devel] [PATCH v2 05/10] qcow2/bitmap: reject IN_USE bitmaps on rw reload
Presently, an image with IN_USE bitmaps cannot be loaded as RO.
In preparation for changing that, IN_USE bitmaps ought to create an
error on reload instead of being skipped.
While we're here, update the function to work with two new facts:
- All bm_list entries will have a BdrvDirtyBitmap (because we load and
disable bitmaps when the autoload flag isn't set), and
- The dirty_bitmap will be cached, so we don't have to look it up.
Signed-off-by: John Snow
---
block/qcow2-bitmap.c | 31 +++
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/block/qcow2-bitmap.c b/block/qcow2-bitmap.c
index d94b6bd5cf..859819639b 100644
--- a/block/qcow2-bitmap.c
+++ b/block/qcow2-bitmap.c
@@ -1046,23 +1046,22 @@ int qcow2_reopen_bitmaps_rw_hint(BlockDriverState *bs,
bool *header_updated,
}
QSIMPLEQ_FOREACH(bm, bm_list, entry) {
-if (!(bm->flags & BME_FLAG_IN_USE)) {
-BdrvDirtyBitmap *bitmap = bdrv_find_dirty_bitmap(bs, bm->name);
-if (bitmap == NULL) {
-continue;
-}
-
-if (!bdrv_dirty_bitmap_readonly(bitmap)) {
-error_setg(errp, "Bitmap %s is not readonly but not marked"
- "'IN_USE' in the image. Something went wrong,"
- "all the bitmaps may be corrupted", bm->name);
-ret = -EINVAL;
-goto out;
-}
-
-bm->flags |= BME_FLAG_IN_USE;
-ro_dirty_bitmaps = g_slist_append(ro_dirty_bitmaps, bitmap);
+if (bm->flags & BME_FLAG_IN_USE) {
+error_setg(errp, "Bitmap '%s' is in use; can't reopen RW",
+ bm->name);
+ret = -EINVAL;
+goto out;
+} else if (!bdrv_dirty_bitmap_readonly(bm->dirty_bitmap)) {
+error_setg(errp, "Bitmap %s is neither readonly nor 'IN_USE' in "
+ "the image. Something went wrong, all the bitmaps may "
+ "be corrupted. Please report this to the developers at "
+ " qemu-devel@nongnu.org", bm->name);
+ret = -EINVAL;
+goto out;
}
+
+bm->flags |= BME_FLAG_IN_USE;
+ro_dirty_bitmaps = g_slist_append(ro_dirty_bitmaps, bm->dirty_bitmap);
}
if (ro_dirty_bitmaps != NULL) {
--
2.14.3
[Qemu-devel] [PATCH v2 00/10] qemu-img: add bitmap info output
Allow qemu-img to show information about bitmaps stored in qcow2 images. v2: - Remove bitmap manipulation command in favor of a part 2 series later - Responded to much of Vladimir's feedback (Thank you!); - In particular, make sure IN_USE bitmaps cannot be remounted RW. - Fixed semantics of the extra_data flag John Snow (10): qcow2/bitmap: remove redundant arguments from bitmap_list_load qcow2/bitmap: avoid adjusting bm->flags for RO bitmaps qcow2/bitmap: cache bm_list qcow2/bitmap: cache loaded bitmaps qcow2/bitmap: reject IN_USE bitmaps on rw reload qcow2/bitmap: load IN_USE bitmaps if disk is RO qcow2/bitmap: track bitmap type qcow2/bitmap: track extra_data_size qapi: add bitmap info qcow2/bitmap: add basic bitmaps info block/qcow2-bitmap.c | 276 ++- block/qcow2.c| 9 ++ block/qcow2.h| 3 + qapi/block-core.json | 64 +++- 4 files changed, 260 insertions(+), 92 deletions(-) -- 2.14.3
[Qemu-devel] [PATCH v2 08/10] qcow2/bitmap: track extra_data_size
Similarly to the last patch, track the extra_data_size field that we read.
We do reject anything other than zero, but if this restriction is lifted
in the future, we'll need to update the _info field, so loosen this now.
Signed-off-by: John Snow
---
block/qcow2-bitmap.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/block/qcow2-bitmap.c b/block/qcow2-bitmap.c
index 36573f7b52..3c2e974458 100644
--- a/block/qcow2-bitmap.c
+++ b/block/qcow2-bitmap.c
@@ -86,6 +86,7 @@ typedef struct Qcow2Bitmap {
uint8_t type;
uint8_t granularity_bits;
char *name;
+uint32_t extra_data_size;
BdrvDirtyBitmap *dirty_bitmap;
@@ -609,6 +610,7 @@ static Qcow2BitmapList *bitmap_list_load(BlockDriverState
*bs, Error **errp)
bm->table.size = e->bitmap_table_size;
bm->flags = e->flags;
bm->type = e->type;
+bm->extra_data_size = e->extra_data_size;
bm->granularity_bits = e->granularity_bits;
bm->name = dir_entry_copy_name(e);
QSIMPLEQ_INSERT_TAIL(bm_list, bm, entry);
@@ -782,7 +784,7 @@ static int bitmap_list_store(BlockDriverState *bs,
Qcow2BitmapList *bm_list,
e->type = bm->type;
e->granularity_bits = bm->granularity_bits;
e->name_size = strlen(bm->name);
-e->extra_data_size = 0;
+e->extra_data_size = bm->extra_data_size;
memcpy(e + 1, bm->name, e->name_size);
if (check_dir_entry(bs, e) < 0) {
--
2.14.3
[Qemu-devel] [PATCH v4b 17/18] target/arm: Implement SVE Integer Wide Immediate - Unpredicated Group
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper-sve.h| 25 +++
target/arm/sve_helper.c| 41 +++
target/arm/translate-sve.c | 144 +
target/arm/sve.decode | 26 +++
4 files changed, 236 insertions(+)
diff --git a/target/arm/helper-sve.h b/target/arm/helper-sve.h
index 1863106d0f..97bfe0f47b 100644
--- a/target/arm/helper-sve.h
+++ b/target/arm/helper-sve.h
@@ -680,3 +680,28 @@ DEF_HELPER_FLAGS_4(sve_brkns, TCG_CALL_NO_RWG, i32, ptr,
ptr, ptr, i32)
DEF_HELPER_FLAGS_3(sve_cntp, TCG_CALL_NO_RWG, i64, ptr, ptr, i32)
DEF_HELPER_FLAGS_3(sve_while, TCG_CALL_NO_RWG, i32, ptr, i32, i32)
+
+DEF_HELPER_FLAGS_4(sve_subri_b, TCG_CALL_NO_RWG, void, ptr, ptr, i64, i32)
+DEF_HELPER_FLAGS_4(sve_subri_h, TCG_CALL_NO_RWG, void, ptr, ptr, i64, i32)
+DEF_HELPER_FLAGS_4(sve_subri_s, TCG_CALL_NO_RWG, void, ptr, ptr, i64, i32)
+DEF_HELPER_FLAGS_4(sve_subri_d, TCG_CALL_NO_RWG, void, ptr, ptr, i64, i32)
+
+DEF_HELPER_FLAGS_4(sve_smaxi_b, TCG_CALL_NO_RWG, void, ptr, ptr, i64, i32)
+DEF_HELPER_FLAGS_4(sve_smaxi_h, TCG_CALL_NO_RWG, void, ptr, ptr, i64, i32)
+DEF_HELPER_FLAGS_4(sve_smaxi_s, TCG_CALL_NO_RWG, void, ptr, ptr, i64, i32)
+DEF_HELPER_FLAGS_4(sve_smaxi_d, TCG_CALL_NO_RWG, void, ptr, ptr, i64, i32)
+
+DEF_HELPER_FLAGS_4(sve_smini_b, TCG_CALL_NO_RWG, void, ptr, ptr, i64, i32)
+DEF_HELPER_FLAGS_4(sve_smini_h, TCG_CALL_NO_RWG, void, ptr, ptr, i64, i32)
+DEF_HELPER_FLAGS_4(sve_smini_s, TCG_CALL_NO_RWG, void, ptr, ptr, i64, i32)
+DEF_HELPER_FLAGS_4(sve_smini_d, TCG_CALL_NO_RWG, void, ptr, ptr, i64, i32)
+
+DEF_HELPER_FLAGS_4(sve_umaxi_b, TCG_CALL_NO_RWG, void, ptr, ptr, i64, i32)
+DEF_HELPER_FLAGS_4(sve_umaxi_h, TCG_CALL_NO_RWG, void, ptr, ptr, i64, i32)
+DEF_HELPER_FLAGS_4(sve_umaxi_s, TCG_CALL_NO_RWG, void, ptr, ptr, i64, i32)
+DEF_HELPER_FLAGS_4(sve_umaxi_d, TCG_CALL_NO_RWG, void, ptr, ptr, i64, i32)
+
+DEF_HELPER_FLAGS_4(sve_umini_b, TCG_CALL_NO_RWG, void, ptr, ptr, i64, i32)
+DEF_HELPER_FLAGS_4(sve_umini_h, TCG_CALL_NO_RWG, void, ptr, ptr, i64, i32)
+DEF_HELPER_FLAGS_4(sve_umini_s, TCG_CALL_NO_RWG, void, ptr, ptr, i64, i32)
+DEF_HELPER_FLAGS_4(sve_umini_d, TCG_CALL_NO_RWG, void, ptr, ptr, i64, i32)
diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
index 8539595bd7..128bbf9b04 100644
--- a/target/arm/sve_helper.c
+++ b/target/arm/sve_helper.c
@@ -804,6 +804,46 @@ DO_VPZ_D(sve_uminv_d, uint64_t, uint64_t, -1, DO_MIN)
#undef DO_VPZ
#undef DO_VPZ_D
+/* Two vector operand, one scalar operand, unpredicated. */
+#define DO_ZZI(NAME, TYPE, OP) \
+void HELPER(NAME)(void *vd, void *vn, uint64_t s64, uint32_t desc) \
+{\
+intptr_t i, opr_sz = simd_oprsz(desc) / sizeof(TYPE);\
+TYPE s = s64, *d = vd, *n = vn; \
+for (i = 0; i < opr_sz; ++i) { \
+d[i] = OP(n[i], s); \
+}\
+}
+
+#define DO_SUBR(X, Y) (Y - X)
+
+DO_ZZI(sve_subri_b, uint8_t, DO_SUBR)
+DO_ZZI(sve_subri_h, uint16_t, DO_SUBR)
+DO_ZZI(sve_subri_s, uint32_t, DO_SUBR)
+DO_ZZI(sve_subri_d, uint64_t, DO_SUBR)
+
+DO_ZZI(sve_smaxi_b, int8_t, DO_MAX)
+DO_ZZI(sve_smaxi_h, int16_t, DO_MAX)
+DO_ZZI(sve_smaxi_s, int32_t, DO_MAX)
+DO_ZZI(sve_smaxi_d, int64_t, DO_MAX)
+
+DO_ZZI(sve_smini_b, int8_t, DO_MIN)
+DO_ZZI(sve_smini_h, int16_t, DO_MIN)
+DO_ZZI(sve_smini_s, int32_t, DO_MIN)
+DO_ZZI(sve_smini_d, int64_t, DO_MIN)
+
+DO_ZZI(sve_umaxi_b, uint8_t, DO_MAX)
+DO_ZZI(sve_umaxi_h, uint16_t, DO_MAX)
+DO_ZZI(sve_umaxi_s, uint32_t, DO_MAX)
+DO_ZZI(sve_umaxi_d, uint64_t, DO_MAX)
+
+DO_ZZI(sve_umini_b, uint8_t, DO_MIN)
+DO_ZZI(sve_umini_h, uint16_t, DO_MIN)
+DO_ZZI(sve_umini_s, uint32_t, DO_MIN)
+DO_ZZI(sve_umini_d, uint64_t, DO_MIN)
+
+#undef DO_ZZI
+
#undef DO_AND
#undef DO_ORR
#undef DO_EOR
@@ -818,6 +858,7 @@ DO_VPZ_D(sve_uminv_d, uint64_t, uint64_t, -1, DO_MIN)
#undef DO_ASR
#undef DO_LSR
#undef DO_LSL
+#undef DO_SUBR
/* Similar to the ARM LastActiveElement pseudocode function, except the
result is multiplied by the element size. This includes the not found
diff --git a/target/arm/translate-sve.c b/target/arm/translate-sve.c
index 13d5e1..afd0b1638d 100644
--- a/target/arm/translate-sve.c
+++ b/target/arm/translate-sve.c
@@ -77,6 +77,11 @@ static inline int expand_imm_sh8s(int x)
return (int8_t)x << (x & 0x100 ? 8 : 0);
}
+static inline int expand_imm_sh8u(int x)
+{
+return (uint8_t)x << (x & 0x100 ? 8 : 0);
+}
+
/*
* Include the generated decoder.
*/
@@ -3228,6 +3233,145 @@ static bool trans_DUP_i(DisasContext *s, arg_DUP_i *a,
uint32_t insn)
return true;
}
+static bool trans_ADD_zzi(DisasContext *s, arg_rri_esz *a, uint32_t insn)
+{
+if (a->esz == 0 && extract32(insn, 13, 1)) {
+return false;
+}
[Qemu-devel] [PATCH v4b 18/18] target/arm: Implement SVE Floating Point Arithmetic - Unpredicated Group
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper-sve.h| 14
target/arm/helper.h| 19 +++
target/arm/translate-sve.c | 42 +++
target/arm/vec_helper.c| 69 ++
target/arm/sve.decode | 10 ++
5 files changed, 154 insertions(+)
diff --git a/target/arm/helper-sve.h b/target/arm/helper-sve.h
index 97bfe0f47b..2e76084992 100644
--- a/target/arm/helper-sve.h
+++ b/target/arm/helper-sve.h
@@ -705,3 +705,17 @@ DEF_HELPER_FLAGS_4(sve_umini_b, TCG_CALL_NO_RWG, void,
ptr, ptr, i64, i32)
DEF_HELPER_FLAGS_4(sve_umini_h, TCG_CALL_NO_RWG, void, ptr, ptr, i64, i32)
DEF_HELPER_FLAGS_4(sve_umini_s, TCG_CALL_NO_RWG, void, ptr, ptr, i64, i32)
DEF_HELPER_FLAGS_4(sve_umini_d, TCG_CALL_NO_RWG, void, ptr, ptr, i64, i32)
+
+DEF_HELPER_FLAGS_5(gvec_recps_h, TCG_CALL_NO_RWG,
+ void, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(gvec_recps_s, TCG_CALL_NO_RWG,
+ void, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(gvec_recps_d, TCG_CALL_NO_RWG,
+ void, ptr, ptr, ptr, ptr, i32)
+
+DEF_HELPER_FLAGS_5(gvec_rsqrts_h, TCG_CALL_NO_RWG,
+ void, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(gvec_rsqrts_s, TCG_CALL_NO_RWG,
+ void, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(gvec_rsqrts_d, TCG_CALL_NO_RWG,
+ void, ptr, ptr, ptr, ptr, i32)
diff --git a/target/arm/helper.h b/target/arm/helper.h
index 0c6a144458..879a7229e9 100644
--- a/target/arm/helper.h
+++ b/target/arm/helper.h
@@ -601,6 +601,25 @@ DEF_HELPER_FLAGS_5(gvec_fcmlas_idx, TCG_CALL_NO_RWG,
DEF_HELPER_FLAGS_5(gvec_fcmlad, TCG_CALL_NO_RWG,
void, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(gvec_fadd_h, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(gvec_fadd_s, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(gvec_fadd_d, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr, i32)
+
+DEF_HELPER_FLAGS_5(gvec_fsub_h, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(gvec_fsub_s, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(gvec_fsub_d, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr, i32)
+
+DEF_HELPER_FLAGS_5(gvec_fmul_h, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(gvec_fmul_s, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(gvec_fmul_d, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr, i32)
+
+DEF_HELPER_FLAGS_5(gvec_ftsmul_h, TCG_CALL_NO_RWG,
+ void, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(gvec_ftsmul_s, TCG_CALL_NO_RWG,
+ void, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(gvec_ftsmul_d, TCG_CALL_NO_RWG,
+ void, ptr, ptr, ptr, ptr, i32)
+
#ifdef TARGET_AARCH64
#include "helper-a64.h"
#include "helper-sve.h"
diff --git a/target/arm/translate-sve.c b/target/arm/translate-sve.c
index afd0b1638d..226c97579c 100644
--- a/target/arm/translate-sve.c
+++ b/target/arm/translate-sve.c
@@ -3372,6 +3372,48 @@ DO_ZZI(UMIN, umin)
#undef DO_ZZI
+/*
+ *** SVE Floating Point Arithmetic - Unpredicated Group
+ */
+
+static bool do_zzz_fp(DisasContext *s, arg_rrr_esz *a,
+ gen_helper_gvec_3_ptr *fn)
+{
+if (fn == NULL) {
+return false;
+}
+if (sve_access_check(s)) {
+unsigned vsz = vec_full_reg_size(s);
+TCGv_ptr status = get_fpstatus_ptr(a->esz == MO_16);
+tcg_gen_gvec_3_ptr(vec_full_reg_offset(s, a->rd),
+ vec_full_reg_offset(s, a->rn),
+ vec_full_reg_offset(s, a->rm),
+ status, vsz, vsz, 0, fn);
+tcg_temp_free_ptr(status);
+}
+return true;
+}
+
+
+#define DO_FP3(NAME, name) \
+static bool trans_##NAME(DisasContext *s, arg_rrr_esz *a, uint32_t insn) \
+{ \
+static gen_helper_gvec_3_ptr * const fns[4] = { \
+NULL, gen_helper_gvec_##name##_h, \
+gen_helper_gvec_##name##_s, gen_helper_gvec_##name##_d \
+}; \
+return do_zzz_fp(s, a, fns[a->esz]);\
+}
+
+DO_FP3(FADD_zzz, fadd)
+DO_FP3(FSUB_zzz, fsub)
+DO_FP3(FMUL_zzz, fmul)
+DO_FP3(FTSMUL, ftsmul)
+DO_FP3(FRECPS, recps)
+DO_FP3(FRSQRTS, rsqrts)
+
+#undef DO_FP3
+
/*
*** SVE Memory - 32-bit Gather and Unsized Contiguous Group
*/
diff --git a/target/arm/vec_helper.c b/target/arm/vec_helper.c
index 25e209da31..f504dd53c8 100644
--- a/target/arm/vec_helper.c
+++ b/target/arm/vec_helper.c
@@ -426,3 +426,72 @@ void HELPER(gvec_fcmlad)(void *vd, void *vn, void *vm,
}
clear_tail(d, opr_sz, simd_maxsz(desc));
}
+
+/* Floating-point trigonometric starting value.
+ * See the ARM ARM pseudocode function FPTrigSMul.
+ */
+static float16
[Qemu-devel] [PATCH v2 10/10] qcow2/bitmap: add basic bitmaps info
Add functions for querying the basic information inside of bitmaps.
Restructure the bitmaps flags masks to facilitate providing a list of
flags belonging to the bitmap(s) being queried.
Signed-off-by: John Snow
---
block/qcow2-bitmap.c | 86 ++--
block/qcow2.c| 7 +
block/qcow2.h| 1 +
3 files changed, 92 insertions(+), 2 deletions(-)
diff --git a/block/qcow2-bitmap.c b/block/qcow2-bitmap.c
index 3c2e974458..80bd31bfc1 100644
--- a/block/qcow2-bitmap.c
+++ b/block/qcow2-bitmap.c
@@ -49,8 +49,25 @@
/* Bitmap directory entry flags */
#define BME_RESERVED_FLAGS 0xfffcU
-#define BME_FLAG_IN_USE (1U << 0)
-#define BME_FLAG_AUTO (1U << 1)
+
+enum BME_FLAG_BITS {
+BME_FLAG_BIT__BEGIN = 0,
+BME_FLAG_BIT_IN_USE = BME_FLAG_BIT__BEGIN,
+BME_FLAG_BIT_AUTO = 1,
+BME_FLAG_BIT_EXTRA = 2,
+BME_FLAG_BIT__MAX,
+};
+
+#define BME_FLAG_IN_USE (1U << BME_FLAG_BIT_IN_USE)
+#define BME_FLAG_AUTO (1U << BME_FLAG_BIT_AUTO)
+#define BME_FLAG_EXTRA (1U << BME_FLAG_BIT_EXTRA)
+
+/* Correlate canonical spec values to autogenerated QAPI values */
+int BMEFlagMap[BME_FLAG_BIT__MAX] = {
+[BME_FLAG_BIT_IN_USE] = BITMAP_FLAG_ENUM_IN_USE,
+[BME_FLAG_BIT_AUTO] = BITMAP_FLAG_ENUM_AUTO,
+[BME_FLAG_BIT_EXTRA] = BITMAP_FLAG_ENUM_EXTRA_DATA_COMPATIBLE,
+};
/* bits [1, 8] U [56, 63] are reserved */
#define BME_TABLE_ENTRY_RESERVED_MASK 0xff0001feULL
@@ -668,6 +685,71 @@ static void del_bitmap_list(BlockDriverState *bs)
}
}
+static BitmapFlagEnumList *prepend_bitmap_flag(BitmapFlagEnumList *elist,
+ BitmapFlagEnum value)
+{
+BitmapFlagEnumList *ftmp = g_new0(BitmapFlagEnumList, 1);
+ftmp->value = value;
+ftmp->next = elist;
+return ftmp;
+}
+
+static BitmapFlagEnumList *get_bitmap_flags(uint32_t flags)
+{
+int i;
+BitmapFlagEnumList *flist = NULL;
+
+if (flags & BME_RESERVED_FLAGS) {
+flist = prepend_bitmap_flag(flist, BITMAP_FLAG_ENUM_RESERVED);
+flags &= ~BME_RESERVED_FLAGS;
+}
+
+while (flags) {
+i = ctz32(flags);
+assert(i >= BME_FLAG_BIT__BEGIN && i < BME_FLAG_BIT__MAX);
+flist = prepend_bitmap_flag(flist, BMEFlagMap[i]);
+flags &= ~(1 << i);
+}
+
+return flist;
+}
+
+BitmapInfoList *qcow2_get_bitmap_info(BlockDriverState *bs)
+{
+Qcow2BitmapList *bm_list;
+Qcow2Bitmap *bm;
+BitmapInfoList *info_list = NULL;
+BitmapInfoList *tmp;
+BitmapInfo *bitmap_info;
+
+bm_list = get_bitmap_list(bs, NULL);
+if (!bm_list) {
+return info_list;
+}
+
+QSIMPLEQ_FOREACH(bm, bm_list, entry) {
+bitmap_info = g_new0(BitmapInfo, 1);
+bitmap_info->name = g_strdup(bm->name);
+if (bm->type == BT_DIRTY_TRACKING_BITMAP) {
+bitmap_info->type = BITMAP_TYPE_ENUM_DIRTY_TRACKING;
+} else {
+bitmap_info->type = BITMAP_TYPE_ENUM_UNKNOWN;
+}
+bitmap_info->granularity = 1 << bm->granularity_bits;
+bitmap_info->count = bdrv_get_dirty_count(bm->dirty_bitmap);
+bitmap_info->extra_data = bm->extra_data_size > 0;
+bitmap_info->flags = get_bitmap_flags(bm->flags);
+bitmap_info->has_flags = !!bitmap_info->flags;
+
+tmp = g_new0(BitmapInfoList, 1);
+tmp->value = bitmap_info;
+tmp->next = info_list;
+info_list = tmp;
+}
+
+return info_list;
+}
+
int qcow2_check_bitmaps_refcounts(BlockDriverState *bs, BdrvCheckResult *res,
void **refcount_table,
int64_t *refcount_table_size)
diff --git a/block/qcow2.c b/block/qcow2.c
index dbd334b150..2a52771ac8 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -4133,6 +4133,7 @@ static ImageInfoSpecific
*qcow2_get_specific_info(BlockDriverState *bs)
BDRVQcow2State *s = bs->opaque;
ImageInfoSpecific *spec_info;
QCryptoBlockInfo *encrypt_info = NULL;
+BitmapInfoList *bitmap_list = NULL;
if (s->crypto != NULL) {
encrypt_info = qcrypto_block_get_info(s->crypto, _abort);
@@ -4189,6 +4190,12 @@ static ImageInfoSpecific
*qcow2_get_specific_info(BlockDriverState *bs)
spec_info->u.qcow2.data->encrypt = qencrypt;
}
+bitmap_list = qcow2_get_bitmap_info(bs);
+if (bitmap_list) {
+spec_info->u.qcow2.data->has_bitmaps = true;
+spec_info->u.qcow2.data->bitmaps = bitmap_list;
+}
+
return spec_info;
}
diff --git a/block/qcow2.h b/block/qcow2.h
index 29b637a0ee..d3fe766a1f 100644
--- a/block/qcow2.h
+++ b/block/qcow2.h
@@ -682,5 +682,6 @@ bool qcow2_can_store_new_dirty_bitmap(BlockDriverState *bs,
void qcow2_remove_persistent_dirty_bitmap(BlockDriverState *bs,
const char *name,
Error **errp);
+BitmapInfoList *qcow2_get_bitmap_info(BlockDriverState *bs);
#endif
--
Re: [Qemu-devel] [PATCH] e1000e: Do not auto-clear ICR bits which aren't set in EIAC
On 2018年06月13日 03:00, Philippe Mathieu-Daudé wrote:
Cc'ing Jason who is also listed as co-maintainer:
./scripts/get_maintainer.pl -f hw/net/e1000e_core.c
Dmitry Fleytman (maintainer:e1000e)
Jason Wang (odd fixer:Network devices)
On 06/12/2018 03:43 PM, Jan Kiszka wrote:
On 2018-06-12 20:38, Philippe Mathieu-Daudé wrote:
On 06/12/2018 03:30 PM, Jan Kiszka wrote:
On 2018-06-12 20:11, Philippe Mathieu-Daudé wrote:
Hi Jan,
On 06/12/2018 02:22 PM, Jan Kiszka wrote:
On 2018-05-22 09:00, Jan Kiszka wrote:
On 2018-04-16 17:29, Peter Maydell wrote:
On 16 April 2018 at 16:25, Jan Kiszka wrote:
On 2018-04-01 23:17, Jan Kiszka wrote:
From: Jan Kiszka
The spec does not justify clearing of any E1000_ICR_OTHER_CAUSES when
E1000_ICR_OTHER is set in EIAC. In fact, removing this code fixes the
issue the Linux driver runs into since 4aea7a5c5e94 ("e1000e: Avoid
receiver overrun interrupt bursts") and was worked around by
745d0bd3af99 ("e1000e: Remove Other from EIAC").
Signed-off-by: Jan Kiszka
---
This resolves the issue I reported on February 18 ("e1000e: MSI-X
problem with recent Linux drivers").
hw/net/e1000e_core.c | 4
1 file changed, 4 deletions(-)
diff --git a/hw/net/e1000e_core.c b/hw/net/e1000e_core.c
index ecf9b1..d38f025c0f 100644
--- a/hw/net/e1000e_core.c
+++ b/hw/net/e1000e_core.c
@@ -2022,10 +2022,6 @@ e1000e_msix_notify_one(E1000ECore *core, uint32_t cause,
uint32_t int_cfg)
effective_eiac = core->mac[EIAC] & cause;
-if (effective_eiac == E1000_ICR_OTHER) {
-effective_eiac |= E1000_ICR_OTHER_CAUSES;
-}
-
core->mac[ICR] &= ~effective_eiac;
if (!(core->mac[CTRL_EXT] & E1000_CTRL_EXT_IAME)) {
Ping for this - as well as https://patchwork.ozlabs.org/patch/895476.
Given that q35 uses e1000e by default and many Linux kernel versions no
longer work, this should likely go into upcoming and stable versions
I'd rather not put it into 2.12 at this point in the release
cycle unless it's a regression from 2.11, I think.
Second ping - nothing hit the repo so far, nor did I receive feedback.
And another ping. For both.
These days I had to help someone with a broken QEMU setup that failed
installing from network. It turned out that "modprobe e1000e IntMode=0"
was needed to workaround the issues my patches address.
What about the IMS register? It is set just after.
Looking at b38636b8372, can you test this patch?
-- >8 --
diff --git a/hw/net/e1000e_core.c b/hw/net/e1000e_core.c
index c93c4661ed..a484b68a5a 100644
--- a/hw/net/e1000e_core.c
+++ b/hw/net/e1000e_core.c
@@ -2022,13 +2022,13 @@ e1000e_msix_notify_one(E1000ECore *core,
uint32_t cause, uint32_t int_cfg)
effective_eiac = core->mac[EIAC] & cause;
-if (effective_eiac == E1000_ICR_OTHER) {
-effective_eiac |= E1000_ICR_OTHER_CAUSES;
-}
-
core->mac[ICR] &= ~effective_eiac;
if (!(core->mac[CTRL_EXT] & E1000_CTRL_EXT_IAME)) {
+if (effective_eiac == E1000_ICR_OTHER) {
+effective_eiac |= E1000_ICR_OTHER_CAUSES;
+}
+
core->mac[IMS] &= ~effective_eiac;
}
}
Before testing this: What would be the reasoning for this change?
Not breaking the purpose of b38636b8372 :)
I disagree on this expansion of bit 31 ("other causes"). I see no
indication in the spec that setting this bit for autoclear has more
impact than on the very same bit itself. Therefore I'm asking for a
reasoning - based on the spec.
Interrupt Cause Registers
Other bits in this register are the legacy indication of
interrupts as the MDIC complete, management and link status
change. There is a specific Other Cause bit that is set if
one of these bits are set, this bit can be mapped to a
specific MSI-X interrupt message.
I spent half an hour reading the relevant parts of the spec and can't
figure out, so I'll let the authors of b38636b8372 to review your patch.
Regards,
Phil.
Looking at EIAC part of the spec:
Bits 24:20 in this register enables clearing of the corresponding bit in
ICR following
interrupt generation. When a bit is set, the corresponding bit in ICR
and in IMS is
automatically cleared following an interrupt.
It looks to me that only the other bit itself need to be cleared.
Thanks
[Qemu-devel] [PATCH v4b 15/18] target/arm: Implement SVE Integer Compare - Scalars Group
Signed-off-by: Richard Henderson
---
target/arm/helper-sve.h| 2 +
target/arm/sve_helper.c| 31
target/arm/translate-sve.c | 99 ++
target/arm/sve.decode | 8 +++
4 files changed, 140 insertions(+)
diff --git a/target/arm/helper-sve.h b/target/arm/helper-sve.h
index dd4f8f754d..1863106d0f 100644
--- a/target/arm/helper-sve.h
+++ b/target/arm/helper-sve.h
@@ -678,3 +678,5 @@ DEF_HELPER_FLAGS_4(sve_brkn, TCG_CALL_NO_RWG, void, ptr,
ptr, ptr, i32)
DEF_HELPER_FLAGS_4(sve_brkns, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
DEF_HELPER_FLAGS_3(sve_cntp, TCG_CALL_NO_RWG, i64, ptr, ptr, i32)
+
+DEF_HELPER_FLAGS_3(sve_while, TCG_CALL_NO_RWG, i32, ptr, i32, i32)
diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
index a4ecd653c1..8539595bd7 100644
--- a/target/arm/sve_helper.c
+++ b/target/arm/sve_helper.c
@@ -2738,3 +2738,34 @@ uint64_t HELPER(sve_cntp)(void *vn, void *vg, uint32_t
pred_desc)
}
return sum;
}
+
+uint32_t HELPER(sve_while)(void *vd, uint32_t count, uint32_t pred_desc)
+{
+uintptr_t oprsz = extract32(pred_desc, 0, SIMD_OPRSZ_BITS) + 2;
+intptr_t esz = extract32(pred_desc, SIMD_DATA_SHIFT, 2);
+uint64_t esz_mask = pred_esz_masks[esz];
+ARMPredicateReg *d = vd;
+uint32_t flags;
+intptr_t i;
+
+/* Begin with a zero predicate register. */
+flags = do_zero(d, oprsz);
+if (count == 0) {
+return flags;
+}
+
+/* Scale from predicate element count to bits. */
+count <<= esz;
+/* Bound to the bits in the predicate. */
+count = MIN(count, oprsz * 8);
+
+/* Set all of the requested bits. */
+for (i = 0; i < count / 64; ++i) {
+d->p[i] = esz_mask;
+}
+if (count & 63) {
+d->p[i] = MAKE_64BIT_MASK(0, count & 63) & esz_mask;
+}
+
+return predtest_ones(d, oprsz, esz_mask);
+}
diff --git a/target/arm/translate-sve.c b/target/arm/translate-sve.c
index 6b0b8c55d0..ae6a504f61 100644
--- a/target/arm/translate-sve.c
+++ b/target/arm/translate-sve.c
@@ -3092,6 +3092,105 @@ static bool trans_SINCDECP_z(DisasContext *s,
arg_incdec2_pred *a,
return true;
}
+/*
+ *** SVE Integer Compare Scalars Group
+ */
+
+static bool trans_CTERM(DisasContext *s, arg_CTERM *a, uint32_t insn)
+{
+if (!sve_access_check(s)) {
+return true;
+}
+
+TCGCond cond = (a->ne ? TCG_COND_NE : TCG_COND_EQ);
+TCGv_i64 rn = read_cpu_reg(s, a->rn, a->sf);
+TCGv_i64 rm = read_cpu_reg(s, a->rm, a->sf);
+TCGv_i64 cmp = tcg_temp_new_i64();
+
+tcg_gen_setcond_i64(cond, cmp, rn, rm);
+tcg_gen_extrl_i64_i32(cpu_NF, cmp);
+tcg_temp_free_i64(cmp);
+
+/* VF = !NF & !CF. */
+tcg_gen_xori_i32(cpu_VF, cpu_NF, 1);
+tcg_gen_andc_i32(cpu_VF, cpu_VF, cpu_CF);
+
+/* Both NF and VF actually look at bit 31. */
+tcg_gen_neg_i32(cpu_NF, cpu_NF);
+tcg_gen_neg_i32(cpu_VF, cpu_VF);
+return true;
+}
+
+static bool trans_WHILE(DisasContext *s, arg_WHILE *a, uint32_t insn)
+{
+if (!sve_access_check(s)) {
+return true;
+}
+
+TCGv_i64 op0 = read_cpu_reg(s, a->rn, 1);
+TCGv_i64 op1 = read_cpu_reg(s, a->rm, 1);
+TCGv_i64 t0 = tcg_temp_new_i64();
+TCGv_i64 t1 = tcg_temp_new_i64();
+TCGv_i32 t2, t3;
+TCGv_ptr ptr;
+unsigned desc, vsz = vec_full_reg_size(s);
+TCGCond cond;
+
+if (!a->sf) {
+if (a->u) {
+tcg_gen_ext32u_i64(op0, op0);
+tcg_gen_ext32u_i64(op1, op1);
+} else {
+tcg_gen_ext32s_i64(op0, op0);
+tcg_gen_ext32s_i64(op1, op1);
+}
+}
+
+/* For the helper, compress the different conditions into a computation
+ * of how many iterations for which the condition is true.
+ *
+ * This is slightly complicated by 0 <= UINT64_MAX, which is nominally
+ * 2**64 iterations, overflowing to 0. Of course, predicate registers
+ * aren't that large, so any value >= predicate size is sufficient.
+ */
+tcg_gen_sub_i64(t0, op1, op0);
+
+/* t0 = MIN(op1 - op0, vsz). */
+tcg_gen_movi_i64(t1, vsz);
+tcg_gen_umin_i64(t0, t0, t1);
+if (a->eq) {
+/* Equality means one more iteration. */
+tcg_gen_addi_i64(t0, t0, 1);
+}
+
+/* t0 = (condition true ? t0 : 0). */
+cond = (a->u
+? (a->eq ? TCG_COND_LEU : TCG_COND_LTU)
+: (a->eq ? TCG_COND_LE : TCG_COND_LT));
+tcg_gen_movi_i64(t1, 0);
+tcg_gen_movcond_i64(cond, t0, op0, op1, t0, t1);
+
+t2 = tcg_temp_new_i32();
+tcg_gen_extrl_i64_i32(t2, t0);
+tcg_temp_free_i64(t0);
+tcg_temp_free_i64(t1);
+
+desc = (vsz / 8) - 2;
+desc = deposit32(desc, SIMD_DATA_SHIFT, 2, a->esz);
+t3 = tcg_const_i32(desc);
+
+ptr = tcg_temp_new_ptr();
+tcg_gen_addi_ptr(ptr, cpu_env, pred_full_reg_offset(s, a->rd));
+
+gen_helper_sve_while(t2, ptr, t2, t3);
+do_pred_flags(t2);
+
+tcg_temp_free_ptr(ptr);
+tcg_temp_free_i32(t2);
+
[Qemu-devel] [PATCH v2 04/10] qcow2/bitmap: cache loaded bitmaps
For bitmaps that we succeeded in loading, we can cache a reference
to that object. This will let us iterate over the more convenient
form of in-memory bitmaps for qemu-img bitmap manipulation tools.
Signed-off-by: John Snow
---
block/qcow2-bitmap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/block/qcow2-bitmap.c b/block/qcow2-bitmap.c
index 5ae9b17928..d94b6bd5cf 100644
--- a/block/qcow2-bitmap.c
+++ b/block/qcow2-bitmap.c
@@ -981,6 +981,7 @@ bool qcow2_load_dirty_bitmaps(BlockDriverState *bs, Error
**errp)
if (bitmap == NULL) {
goto fail;
}
+bm->dirty_bitmap = bitmap;
if (!(bm->flags & BME_FLAG_AUTO)) {
bdrv_disable_dirty_bitmap(bitmap);
@@ -1382,6 +1383,7 @@ void
qcow2_store_persistent_dirty_bitmaps(BlockDriverState *bs, Error **errp)
bm->name = g_strdup(name);
QSIMPLEQ_INSERT_TAIL(bm_list, bm, entry);
} else {
+assert(bitmap == bm->dirty_bitmap);
if (!(bm->flags & BME_FLAG_IN_USE)) {
error_setg(errp, "Bitmap '%s' already exists in the image",
name);
--
2.14.3
[Qemu-devel] [PATCH v2 09/10] qapi: add bitmap info
Add some of the necessary scaffolding for reporting bitmap information.
Signed-off-by: John Snow
---
qapi/block-core.json | 64 +++-
1 file changed, 63 insertions(+), 1 deletion(-)
diff --git a/qapi/block-core.json b/qapi/block-core.json
index fff23fc82b..da82a82779 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -34,6 +34,65 @@
'date-sec': 'int', 'date-nsec': 'int',
'vm-clock-sec': 'int', 'vm-clock-nsec': 'int' } }
+##
+# @BitmapTypeEnum:
+#
+# An enumeration of possible serialized bitmap types.
+#
+# @dirty-tracking: This bitmap records information on dirty
+# segments within the file.
+#
+# @unknown: This bitmap is an unknown/reserved type.
+#
+# Since: 3.0
+##
+{ 'enum': 'BitmapTypeEnum', 'data': [ 'dirty-tracking', 'unknown' ] }
+
+##
+# @BitmapFlagEnum:
+#
+# An enumeration of possible flags for serialized bitmaps.
+#
+# @in-use: This bitmap is considered to be in-use, and may now be inconsistent.
+#
+# @auto: This bitmap must reflect any and all changes to the file it describes.
+#
+# @extra-data-compatible: The extra data associated with this bitmap can be
+# safely ignored if it is opaque to the reader. If
+# this flag is absent while extra data is present and
+# opaque to the reader, the bitmap must not be used.
+#
+# @reserved: This bitmap has reserved flags set.
+#
+# Since: 3.0
+##
+{ 'enum': 'BitmapFlagEnum', 'data': [ 'in-use', 'auto',
+ 'extra-data-compatible', 'reserved' ] }
+
+##
+# @BitmapInfo:
+#
+# @name: The name of the bitmap.
+#
+# @type: The type of bitmap.
+#
+# @granularity: Bitmap granularity, in bytes.
+#
+# @count: Overall bitmap dirtiness, in bytes.
+#
+# @extra-data: True if this bitmap has extra data attached.
+#
+# @flags: Bitmap flags, if any.
+#
+# Since: 3.0
+#
+##
+{ 'struct': 'BitmapInfo',
+ 'data': { 'name': 'str', 'type': 'BitmapTypeEnum', 'granularity': 'int',
+'count': 'int', 'extra-data': 'bool', '*flags': ['BitmapFlagEnum']
+ }
+}
+
##
# @ImageInfoSpecificQCow2EncryptionBase:
#
@@ -70,6 +129,8 @@
# @encrypt: details about encryption parameters; only set if image
# is encrypted (since 2.10)
#
+# @bitmaps: list of image bitmaps (since 3.0)
+#
# Since: 1.7
##
{ 'struct': 'ImageInfoSpecificQCow2',
@@ -78,7 +139,8 @@
'*lazy-refcounts': 'bool',
'*corrupt': 'bool',
'refcount-bits': 'int',
- '*encrypt': 'ImageInfoSpecificQCow2Encryption'
+ '*encrypt': 'ImageInfoSpecificQCow2Encryption',
+ '*bitmaps': ['BitmapInfo']
} }
##
--
2.14.3
[Qemu-devel] [PATCH v4b 14/18] target/arm: Implement SVE Predicate Count Group
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper-sve.h| 2 +
target/arm/sve_helper.c| 14
target/arm/translate-sve.c | 133 +
target/arm/sve.decode | 27
4 files changed, 176 insertions(+)
diff --git a/target/arm/helper-sve.h b/target/arm/helper-sve.h
index f0a3ed3414..dd4f8f754d 100644
--- a/target/arm/helper-sve.h
+++ b/target/arm/helper-sve.h
@@ -676,3 +676,5 @@ DEF_HELPER_FLAGS_4(sve_brkbs_m, TCG_CALL_NO_RWG, i32, ptr,
ptr, ptr, i32)
DEF_HELPER_FLAGS_4(sve_brkn, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
DEF_HELPER_FLAGS_4(sve_brkns, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+
+DEF_HELPER_FLAGS_3(sve_cntp, TCG_CALL_NO_RWG, i64, ptr, ptr, i32)
diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
index b27b502d75..a4ecd653c1 100644
--- a/target/arm/sve_helper.c
+++ b/target/arm/sve_helper.c
@@ -2724,3 +2724,17 @@ uint32_t HELPER(sve_brkns)(void *vd, void *vn, void *vg,
uint32_t pred_desc)
return do_zero(vd, oprsz);
}
}
+
+uint64_t HELPER(sve_cntp)(void *vn, void *vg, uint32_t pred_desc)
+{
+intptr_t oprsz = extract32(pred_desc, 0, SIMD_OPRSZ_BITS) + 2;
+intptr_t esz = extract32(pred_desc, SIMD_DATA_SHIFT, 2);
+uint64_t *n = vn, *g = vg, sum = 0, mask = pred_esz_masks[esz];
+intptr_t i;
+
+for (i = 0; i < DIV_ROUND_UP(oprsz, 8); ++i) {
+uint64_t t = n[i] & g[i] & mask;
+sum += ctpop64(t);
+}
+return sum;
+}
diff --git a/target/arm/translate-sve.c b/target/arm/translate-sve.c
index c381240b6f..6b0b8c55d0 100644
--- a/target/arm/translate-sve.c
+++ b/target/arm/translate-sve.c
@@ -34,6 +34,9 @@
#include "translate-a64.h"
+typedef void GVecGen2sFn(unsigned, uint32_t, uint32_t,
+ TCGv_i64, uint32_t, uint32_t);
+
typedef void gen_helper_gvec_flags_3(TCGv_i32, TCGv_ptr, TCGv_ptr,
TCGv_ptr, TCGv_i32);
typedef void gen_helper_gvec_flags_4(TCGv_i32, TCGv_ptr, TCGv_ptr,
@@ -2959,6 +2962,136 @@ static bool trans_BRKN(DisasContext *s, arg_rpr_s *a,
uint32_t insn)
return do_brk2(s, a, gen_helper_sve_brkn, gen_helper_sve_brkns);
}
+/*
+ *** SVE Predicate Count Group
+ */
+
+static void do_cntp(DisasContext *s, TCGv_i64 val, int esz, int pn, int pg)
+{
+unsigned psz = pred_full_reg_size(s);
+
+if (psz <= 8) {
+uint64_t psz_mask;
+
+tcg_gen_ld_i64(val, cpu_env, pred_full_reg_offset(s, pn));
+if (pn != pg) {
+TCGv_i64 g = tcg_temp_new_i64();
+tcg_gen_ld_i64(g, cpu_env, pred_full_reg_offset(s, pg));
+tcg_gen_and_i64(val, val, g);
+tcg_temp_free_i64(g);
+}
+
+/* Reduce the pred_esz_masks value simply to reduce the
+ * size of the code generated here.
+ */
+psz_mask = MAKE_64BIT_MASK(0, psz * 8);
+tcg_gen_andi_i64(val, val, pred_esz_masks[esz] & psz_mask);
+
+tcg_gen_ctpop_i64(val, val);
+} else {
+TCGv_ptr t_pn = tcg_temp_new_ptr();
+TCGv_ptr t_pg = tcg_temp_new_ptr();
+unsigned desc;
+TCGv_i32 t_desc;
+
+desc = psz - 2;
+desc = deposit32(desc, SIMD_DATA_SHIFT, 2, esz);
+
+tcg_gen_addi_ptr(t_pn, cpu_env, pred_full_reg_offset(s, pn));
+tcg_gen_addi_ptr(t_pg, cpu_env, pred_full_reg_offset(s, pg));
+t_desc = tcg_const_i32(desc);
+
+gen_helper_sve_cntp(val, t_pn, t_pg, t_desc);
+tcg_temp_free_ptr(t_pn);
+tcg_temp_free_ptr(t_pg);
+tcg_temp_free_i32(t_desc);
+}
+}
+
+static bool trans_CNTP(DisasContext *s, arg_CNTP *a, uint32_t insn)
+{
+if (sve_access_check(s)) {
+do_cntp(s, cpu_reg(s, a->rd), a->esz, a->rn, a->pg);
+}
+return true;
+}
+
+static bool trans_INCDECP_r(DisasContext *s, arg_incdec_pred *a,
+uint32_t insn)
+{
+if (sve_access_check(s)) {
+TCGv_i64 reg = cpu_reg(s, a->rd);
+TCGv_i64 val = tcg_temp_new_i64();
+
+do_cntp(s, val, a->esz, a->pg, a->pg);
+if (a->d) {
+tcg_gen_sub_i64(reg, reg, val);
+} else {
+tcg_gen_add_i64(reg, reg, val);
+}
+tcg_temp_free_i64(val);
+}
+return true;
+}
+
+static bool trans_INCDECP_z(DisasContext *s, arg_incdec2_pred *a,
+uint32_t insn)
+{
+if (a->esz == 0) {
+return false;
+}
+if (sve_access_check(s)) {
+unsigned vsz = vec_full_reg_size(s);
+TCGv_i64 val = tcg_temp_new_i64();
+GVecGen2sFn *gvec_fn = a->d ? tcg_gen_gvec_subs : tcg_gen_gvec_adds;
+
+do_cntp(s, val, a->esz, a->pg, a->pg);
+gvec_fn(a->esz, vec_full_reg_offset(s, a->rd),
+vec_full_reg_offset(s, a->rn), val, vsz, vsz);
+}
+return true;
+}
+
+static bool trans_SINCDECP_r_32(DisasContext *s, arg_incdec_pred *a,
+uint32_t insn)
+{
+if
[Qemu-devel] [PATCH v2 07/10] qcow2/bitmap: track bitmap type
We only have one type of persistent bitmap right now, but I'd like the
qemu-img tool to be able to give good diagnostic information if it sees
an unknown/unsupported type.
We do enforce it to be the dirty tracking type in check_dir_entry, but
I wanted positive affirmation of the type in the forthcoming info script.
Signed-off-by: John Snow
---
block/qcow2-bitmap.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/block/qcow2-bitmap.c b/block/qcow2-bitmap.c
index 6c4fe9b281..36573f7b52 100644
--- a/block/qcow2-bitmap.c
+++ b/block/qcow2-bitmap.c
@@ -83,6 +83,7 @@ typedef QSIMPLEQ_HEAD(Qcow2BitmapTableList, Qcow2BitmapTable)
typedef struct Qcow2Bitmap {
Qcow2BitmapTable table;
uint32_t flags;
+uint8_t type;
uint8_t granularity_bits;
char *name;
@@ -607,6 +608,7 @@ static Qcow2BitmapList *bitmap_list_load(BlockDriverState
*bs, Error **errp)
bm->table.offset = e->bitmap_table_offset;
bm->table.size = e->bitmap_table_size;
bm->flags = e->flags;
+bm->type = e->type;
bm->granularity_bits = e->granularity_bits;
bm->name = dir_entry_copy_name(e);
QSIMPLEQ_INSERT_TAIL(bm_list, bm, entry);
@@ -777,7 +779,7 @@ static int bitmap_list_store(BlockDriverState *bs,
Qcow2BitmapList *bm_list,
e->bitmap_table_offset = bm->table.offset;
e->bitmap_table_size = bm->table.size;
e->flags = bm->flags;
-e->type = BT_DIRTY_TRACKING_BITMAP;
+e->type = bm->type;
e->granularity_bits = bm->granularity_bits;
e->name_size = strlen(bm->name);
e->extra_data_size = 0;
@@ -1393,6 +1395,7 @@ void
qcow2_store_persistent_dirty_bitmaps(BlockDriverState *bs, Error **errp)
}
bm->flags = bdrv_dirty_bitmap_enabled(bitmap) ? BME_FLAG_AUTO : 0;
bm->granularity_bits = ctz32(bdrv_dirty_bitmap_granularity(bitmap));
+bm->type = BT_DIRTY_TRACKING_BITMAP;
bm->dirty_bitmap = bitmap;
}
--
2.14.3
[Qemu-devel] [PATCH v4b 13/18] target/arm: Implement SVE Partition Break Group
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper-sve.h| 18 +++
target/arm/sve_helper.c| 248 +
target/arm/translate-sve.c | 106
target/arm/sve.decode | 19 +++
4 files changed, 391 insertions(+)
diff --git a/target/arm/helper-sve.h b/target/arm/helper-sve.h
index ae38c0a4be..f0a3ed3414 100644
--- a/target/arm/helper-sve.h
+++ b/target/arm/helper-sve.h
@@ -658,3 +658,21 @@ DEF_HELPER_FLAGS_5(sve_orn_, TCG_CALL_NO_RWG, void,
ptr, ptr, ptr, ptr, i32)
DEF_HELPER_FLAGS_5(sve_nor_, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr,
i32)
DEF_HELPER_FLAGS_5(sve_nand_, TCG_CALL_NO_RWG,
void, ptr, ptr, ptr, ptr, i32)
+
+DEF_HELPER_FLAGS_5(sve_brkpa, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(sve_brkpb, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(sve_brkpas, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(sve_brkpbs, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, ptr, i32)
+
+DEF_HELPER_FLAGS_4(sve_brka_z, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_brkb_z, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_brka_m, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_brkb_m, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+
+DEF_HELPER_FLAGS_4(sve_brkas_z, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_brkbs_z, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_brkas_m, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_brkbs_m, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+
+DEF_HELPER_FLAGS_4(sve_brkn, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_brkns, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
index c1d95edfca..b27b502d75 100644
--- a/target/arm/sve_helper.c
+++ b/target/arm/sve_helper.c
@@ -2476,3 +2476,251 @@ DO_CMP_PPZI_D(sve_cmpls_ppzi_d, uint64_t, <=)
#undef DO_CMP_PPZI_S
#undef DO_CMP_PPZI_D
#undef DO_CMP_PPZI
+
+/* Similar to the ARM LastActive pseudocode function. */
+static bool last_active_pred(void *vd, void *vg, intptr_t oprsz)
+{
+intptr_t i;
+
+for (i = QEMU_ALIGN_UP(oprsz, 8) - 8; i >= 0; i -= 8) {
+uint64_t pg = *(uint64_t *)(vg + i);
+if (pg) {
+return (pow2floor(pg) & *(uint64_t *)(vd + i)) != 0;
+}
+}
+return 0;
+}
+
+/* Compute a mask into RETB that is true for all G, up to and including
+ * (if after) or excluding (if !after) the first G & N.
+ * Return true if BRK found.
+ */
+static bool compute_brk(uint64_t *retb, uint64_t n, uint64_t g,
+bool brk, bool after)
+{
+uint64_t b;
+
+if (brk) {
+b = 0;
+} else if ((g & n) == 0) {
+/* For all G, no N are set; break not found. */
+b = g;
+} else {
+/* Break somewhere in N. Locate it. */
+b = g & n;/* guard true, pred true */
+b = b & -b; /* first such */
+if (after) {
+b = b | (b - 1); /* break after same */
+} else {
+b = b - 1;/* break before same */
+}
+brk = true;
+}
+
+*retb = b;
+return brk;
+}
+
+/* Compute a zeroing BRK. */
+static void compute_brk_z(uint64_t *d, uint64_t *n, uint64_t *g,
+ intptr_t oprsz, bool after)
+{
+bool brk = false;
+intptr_t i;
+
+for (i = 0; i < DIV_ROUND_UP(oprsz, 8); ++i) {
+uint64_t this_b, this_g = g[i];
+
+brk = compute_brk(_b, n[i], this_g, brk, after);
+d[i] = this_b & this_g;
+}
+}
+
+/* Likewise, but also compute flags. */
+static uint32_t compute_brks_z(uint64_t *d, uint64_t *n, uint64_t *g,
+ intptr_t oprsz, bool after)
+{
+uint32_t flags = PREDTEST_INIT;
+bool brk = false;
+intptr_t i;
+
+for (i = 0; i < DIV_ROUND_UP(oprsz, 8); ++i) {
+uint64_t this_b, this_d, this_g = g[i];
+
+brk = compute_brk(_b, n[i], this_g, brk, after);
+d[i] = this_d = this_b & this_g;
+flags = iter_predtest_fwd(this_d, this_g, flags);
+}
+return flags;
+}
+
+/* Compute a merging BRK. */
+static void compute_brk_m(uint64_t *d, uint64_t *n, uint64_t *g,
+ intptr_t oprsz, bool after)
+{
+bool brk = false;
+intptr_t i;
+
+for (i = 0; i < DIV_ROUND_UP(oprsz, 8); ++i) {
+uint64_t this_b, this_g = g[i];
+
+brk = compute_brk(_b, n[i], this_g, brk, after);
+d[i] = (this_b & this_g) | (d[i] & ~this_g);
+}
+}
+
+/* Likewise, but also compute flags. */
+static uint32_t compute_brks_m(uint64_t *d, uint64_t *n, uint64_t *g,
+ intptr_t oprsz, bool after)
+{
+uint32_t flags = PREDTEST_INIT;
+bool brk = false;
+intptr_t i;
+
+for (i = 0; i < oprsz / 8; ++i) {
+uint64_t
[Qemu-devel] [PATCH v2 03/10] qcow2/bitmap: cache bm_list
We don't need to re-read this list every time, exactly. We can keep it cached
and delete our copy when we flush to disk.
Because we don't try to flush bitmaps on close if there's nothing to flush,
add a new conditional to delete the state anyway for a clean exit.
Signed-off-by: John Snow
---
block/qcow2-bitmap.c | 74 ++--
block/qcow2.c| 2 ++
block/qcow2.h| 2 ++
3 files changed, 52 insertions(+), 26 deletions(-)
diff --git a/block/qcow2-bitmap.c b/block/qcow2-bitmap.c
index 85c1b5afe3..5ae9b17928 100644
--- a/block/qcow2-bitmap.c
+++ b/block/qcow2-bitmap.c
@@ -636,6 +636,34 @@ fail:
return NULL;
}
+static Qcow2BitmapList *get_bitmap_list(BlockDriverState *bs, Error **errp)
+{
+BDRVQcow2State *s = bs->opaque;
+Qcow2BitmapList *bm_list;
+
+if (s->bitmap_list) {
+return (Qcow2BitmapList *)s->bitmap_list;
+}
+
+if (s->nb_bitmaps) {
+bm_list = bitmap_list_load(bs, errp);
+} else {
+bm_list = bitmap_list_new();
+}
+s->bitmap_list = bm_list;
+return bm_list;
+}
+
+static void del_bitmap_list(BlockDriverState *bs)
+{
+BDRVQcow2State *s = bs->opaque;
+
+if (s->bitmap_list) {
+bitmap_list_free(s->bitmap_list);
+s->bitmap_list = NULL;
+}
+}
+
int qcow2_check_bitmaps_refcounts(BlockDriverState *bs, BdrvCheckResult *res,
void **refcount_table,
int64_t *refcount_table_size)
@@ -656,7 +684,7 @@ int qcow2_check_bitmaps_refcounts(BlockDriverState *bs,
BdrvCheckResult *res,
return ret;
}
-bm_list = bitmap_list_load(bs, NULL);
+bm_list = get_bitmap_list(bs, NULL);
if (bm_list == NULL) {
res->corruptions++;
return -EINVAL;
@@ -706,8 +734,6 @@ int qcow2_check_bitmaps_refcounts(BlockDriverState *bs,
BdrvCheckResult *res,
}
out:
-bitmap_list_free(bm_list);
-
return ret;
}
@@ -944,7 +970,7 @@ bool qcow2_load_dirty_bitmaps(BlockDriverState *bs, Error
**errp)
return false;
}
-bm_list = bitmap_list_load(bs, errp);
+bm_list = get_bitmap_list(bs, errp);
if (bm_list == NULL) {
return false;
}
@@ -978,8 +1004,6 @@ bool qcow2_load_dirty_bitmaps(BlockDriverState *bs, Error
**errp)
}
}
-bitmap_list_free(bm_list);
-
return needs_update;
fail:
@@ -988,8 +1012,7 @@ fail:
bdrv_release_dirty_bitmap(bs, bm->dirty_bitmap);
}
}
-bitmap_list_free(bm_list);
-
+del_bitmap_list(bs);
return false;
}
@@ -1016,7 +1039,7 @@ int qcow2_reopen_bitmaps_rw_hint(BlockDriverState *bs,
bool *header_updated,
return -EINVAL;
}
-bm_list = bitmap_list_load(bs, errp);
+bm_list = get_bitmap_list(bs, errp);
if (bm_list == NULL) {
return -EINVAL;
}
@@ -1056,7 +1079,6 @@ int qcow2_reopen_bitmaps_rw_hint(BlockDriverState *bs,
bool *header_updated,
out:
g_slist_free(ro_dirty_bitmaps);
-bitmap_list_free(bm_list);
return ret;
}
@@ -1265,7 +1287,7 @@ void
qcow2_remove_persistent_dirty_bitmap(BlockDriverState *bs,
return;
}
-bm_list = bitmap_list_load(bs, errp);
+bm_list = get_bitmap_list(bs, errp);
if (bm_list == NULL) {
return;
}
@@ -1287,7 +1309,11 @@ void
qcow2_remove_persistent_dirty_bitmap(BlockDriverState *bs,
fail:
bitmap_free(bm);
-bitmap_list_free(bm_list);
+}
+
+void qcow2_persistent_dirty_bitmaps_cache_destroy(BlockDriverState *bs)
+{
+del_bitmap_list(bs);
}
void qcow2_store_persistent_dirty_bitmaps(BlockDriverState *bs, Error **errp)
@@ -1304,23 +1330,19 @@ void
qcow2_store_persistent_dirty_bitmaps(BlockDriverState *bs, Error **errp)
if (!bdrv_has_changed_persistent_bitmaps(bs)) {
/* nothing to do */
-return;
+goto out;
}
if (!can_write(bs)) {
error_setg(errp, "No write access");
-return;
+goto out;
}
QSIMPLEQ_INIT(_tables);
-if (s->nb_bitmaps == 0) {
-bm_list = bitmap_list_new();
-} else {
-bm_list = bitmap_list_load(bs, errp);
-if (bm_list == NULL) {
-return;
-}
+bm_list = get_bitmap_list(bs, errp);
+if (bm_list == NULL) {
+goto out;
}
/* check constraints and names */
@@ -1400,8 +1422,7 @@ void
qcow2_store_persistent_dirty_bitmaps(BlockDriverState *bs, Error **errp)
g_free(tb);
}
-bitmap_list_free(bm_list);
-return;
+goto out;
fail:
QSIMPLEQ_FOREACH(bm, bm_list, entry) {
@@ -1416,7 +1437,9 @@ fail:
g_free(tb);
}
-bitmap_list_free(bm_list);
+ out:
+del_bitmap_list(bs);
+return;
}
int qcow2_reopen_bitmaps_ro(BlockDriverState *bs, Error **errp)
@@ -1481,13 +1504,12 @@ bool qcow2_can_store_new_dirty_bitmap(BlockDriverState
*bs,
goto fail;
}
-bm_list = bitmap_list_load(bs,
[Qemu-devel] [PATCH v2 06/10] qcow2/bitmap: load IN_USE bitmaps if disk is RO
For the purposes of qemu-img manipulation and querying of bitmaps, load
bitmaps that are "in use" -- if the image is read only. This will allow
us to diagnose problems with this flag using the qemu-img tool.
Signed-off-by: John Snow
---
block/qcow2-bitmap.c | 32 +++-
1 file changed, 15 insertions(+), 17 deletions(-)
diff --git a/block/qcow2-bitmap.c b/block/qcow2-bitmap.c
index 859819639b..6c4fe9b281 100644
--- a/block/qcow2-bitmap.c
+++ b/block/qcow2-bitmap.c
@@ -345,7 +345,7 @@ static BdrvDirtyBitmap *load_bitmap(BlockDriverState *bs,
uint32_t granularity;
BdrvDirtyBitmap *bitmap = NULL;
-if (bm->flags & BME_FLAG_IN_USE) {
+if (can_write(bs) && (bm->flags & BME_FLAG_IN_USE)) {
error_setg(errp, "Bitmap '%s' is in use", bm->name);
goto fail;
}
@@ -976,23 +976,21 @@ bool qcow2_load_dirty_bitmaps(BlockDriverState *bs, Error
**errp)
}
QSIMPLEQ_FOREACH(bm, bm_list, entry) {
-if (!(bm->flags & BME_FLAG_IN_USE)) {
-BdrvDirtyBitmap *bitmap = load_bitmap(bs, bm, errp);
-if (bitmap == NULL) {
-goto fail;
-}
-bm->dirty_bitmap = bitmap;
+BdrvDirtyBitmap *bitmap = load_bitmap(bs, bm, errp);
+if (bitmap == NULL) {
+goto fail;
+}
+bm->dirty_bitmap = bitmap;
-if (!(bm->flags & BME_FLAG_AUTO)) {
-bdrv_disable_dirty_bitmap(bitmap);
-}
-bdrv_dirty_bitmap_set_persistance(bitmap, true);
-if (can_write(bs)) {
-bm->flags |= BME_FLAG_IN_USE;
-needs_update = true;
-} else {
-bdrv_dirty_bitmap_set_readonly(bitmap, true);
-}
+if (!(bm->flags & BME_FLAG_AUTO)) {
+bdrv_disable_dirty_bitmap(bitmap);
+}
+bdrv_dirty_bitmap_set_persistance(bitmap, true);
+if (can_write(bs)) {
+bm->flags |= BME_FLAG_IN_USE;
+needs_update = true;
+} else {
+bdrv_dirty_bitmap_set_readonly(bitmap, true);
}
}
--
2.14.3
[Qemu-devel] [PATCH v4b 10/18] target/arm: Implement SVE Select Vectors Group
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper-sve.h| 9 +++
target/arm/sve_helper.c| 55 ++
target/arm/translate-sve.c | 2 ++
target/arm/sve.decode | 6 +
4 files changed, 72 insertions(+)
diff --git a/target/arm/helper-sve.h b/target/arm/helper-sve.h
index c3f8a2b502..0f57f64895 100644
--- a/target/arm/helper-sve.h
+++ b/target/arm/helper-sve.h
@@ -195,6 +195,15 @@ DEF_HELPER_FLAGS_5(sve_lsl_zpzz_s, TCG_CALL_NO_RWG,
DEF_HELPER_FLAGS_5(sve_lsl_zpzz_d, TCG_CALL_NO_RWG,
void, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(sve_sel_zpzz_b, TCG_CALL_NO_RWG,
+ void, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(sve_sel_zpzz_h, TCG_CALL_NO_RWG,
+ void, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(sve_sel_zpzz_s, TCG_CALL_NO_RWG,
+ void, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(sve_sel_zpzz_d, TCG_CALL_NO_RWG,
+ void, ptr, ptr, ptr, ptr, i32)
+
DEF_HELPER_FLAGS_5(sve_asr_zpzw_b, TCG_CALL_NO_RWG,
void, ptr, ptr, ptr, ptr, i32)
DEF_HELPER_FLAGS_5(sve_asr_zpzw_h, TCG_CALL_NO_RWG,
diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
index 8da7baad76..f55fdc7dbe 100644
--- a/target/arm/sve_helper.c
+++ b/target/arm/sve_helper.c
@@ -2146,3 +2146,58 @@ void HELPER(sve_splice)(void *vd, void *vn, void *vm,
void *vg, uint32_t desc)
}
swap_memmove(vd + len, vm, opr_sz * 8 - len);
}
+
+void HELPER(sve_sel_zpzz_b)(void *vd, void *vn, void *vm,
+void *vg, uint32_t desc)
+{
+intptr_t i, opr_sz = simd_oprsz(desc) / 8;
+uint64_t *d = vd, *n = vn, *m = vm;
+uint8_t *pg = vg;
+
+for (i = 0; i < opr_sz; i += 1) {
+uint64_t nn = n[i], mm = m[i];
+uint64_t pp = expand_pred_b(pg[H1(i)]);
+d[i] = (nn & pp) | (mm & ~pp);
+}
+}
+
+void HELPER(sve_sel_zpzz_h)(void *vd, void *vn, void *vm,
+void *vg, uint32_t desc)
+{
+intptr_t i, opr_sz = simd_oprsz(desc) / 8;
+uint64_t *d = vd, *n = vn, *m = vm;
+uint8_t *pg = vg;
+
+for (i = 0; i < opr_sz; i += 1) {
+uint64_t nn = n[i], mm = m[i];
+uint64_t pp = expand_pred_h(pg[H1(i)]);
+d[i] = (nn & pp) | (mm & ~pp);
+}
+}
+
+void HELPER(sve_sel_zpzz_s)(void *vd, void *vn, void *vm,
+void *vg, uint32_t desc)
+{
+intptr_t i, opr_sz = simd_oprsz(desc) / 8;
+uint64_t *d = vd, *n = vn, *m = vm;
+uint8_t *pg = vg;
+
+for (i = 0; i < opr_sz; i += 1) {
+uint64_t nn = n[i], mm = m[i];
+uint64_t pp = expand_pred_s(pg[H1(i)]);
+d[i] = (nn & pp) | (mm & ~pp);
+}
+}
+
+void HELPER(sve_sel_zpzz_d)(void *vd, void *vn, void *vm,
+void *vg, uint32_t desc)
+{
+intptr_t i, opr_sz = simd_oprsz(desc) / 8;
+uint64_t *d = vd, *n = vn, *m = vm;
+uint8_t *pg = vg;
+
+for (i = 0; i < opr_sz; i += 1) {
+uint64_t nn = n[i], mm = m[i];
+d[i] = (pg[H1(i)] & 1 ? nn : mm);
+}
+}
diff --git a/target/arm/translate-sve.c b/target/arm/translate-sve.c
index 1517d82468..0de9118fdf 100644
--- a/target/arm/translate-sve.c
+++ b/target/arm/translate-sve.c
@@ -373,6 +373,8 @@ static bool trans_UDIV_zpzz(DisasContext *s, arg_rprr_esz
*a, uint32_t insn)
return do_zpzz_ool(s, a, fns[a->esz]);
}
+DO_ZPZZ(SEL, sel)
+
#undef DO_ZPZZ
/*
diff --git a/target/arm/sve.decode b/target/arm/sve.decode
index a9fa631252..91522d8e13 100644
--- a/target/arm/sve.decode
+++ b/target/arm/sve.decode
@@ -98,6 +98,7 @@
_esz rn=%reg_movprfx
@rdm_pg_rn esz:2 ... ... ... pg:3 rn:5 rd:5 \
_esz rm=%reg_movprfx
+@rd_pg4_rn_rm esz:2 . rm:5 .. pg:4 rn:5 rd:5 _esz
# Three register operand, with governing predicate, vector element size
@rda_pg_rn_rm esz:2 . rm:5 ... pg:3 rn:5 rd:5 \
@@ -466,6 +467,11 @@ RBIT0101 .. 1001 11 100 ... . .
@rd_pg_rn
# SVE vector splice (predicated)
SPLICE 0101 .. 101 100 100 ... . . @rdn_pg_rm
+### SVE Select Vectors Group
+
+# SVE select vector elements (predicated)
+SEL_zpzz0101 .. 1 . 11 . . @rd_pg4_rn_rm
+
### SVE Predicate Logical Operations Group
# SVE predicate logical operations
--
2.17.1
[Qemu-devel] [PATCH v4b 12/18] target/arm: Implement SVE Integer Compare - Immediate Group
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper-sve.h| 44 +++
target/arm/sve_helper.c| 88 ++
target/arm/translate-sve.c | 66
target/arm/sve.decode | 23 ++
4 files changed, 221 insertions(+)
diff --git a/target/arm/helper-sve.h b/target/arm/helper-sve.h
index 6ffd1fbe8e..ae38c0a4be 100644
--- a/target/arm/helper-sve.h
+++ b/target/arm/helper-sve.h
@@ -605,6 +605,50 @@ DEF_HELPER_FLAGS_5(sve_cmplo_ppzw_s, TCG_CALL_NO_RWG,
DEF_HELPER_FLAGS_5(sve_cmpls_ppzw_s, TCG_CALL_NO_RWG,
i32, ptr, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmpeq_ppzi_b, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmpne_ppzi_b, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmpgt_ppzi_b, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmpge_ppzi_b, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmplt_ppzi_b, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmple_ppzi_b, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmphs_ppzi_b, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmphi_ppzi_b, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmplo_ppzi_b, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmpls_ppzi_b, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+
+DEF_HELPER_FLAGS_4(sve_cmpeq_ppzi_h, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmpne_ppzi_h, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmpgt_ppzi_h, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmpge_ppzi_h, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmplt_ppzi_h, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmple_ppzi_h, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmphs_ppzi_h, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmphi_ppzi_h, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmplo_ppzi_h, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmpls_ppzi_h, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+
+DEF_HELPER_FLAGS_4(sve_cmpeq_ppzi_s, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmpne_ppzi_s, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmpgt_ppzi_s, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmpge_ppzi_s, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmplt_ppzi_s, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmple_ppzi_s, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmphs_ppzi_s, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmphi_ppzi_s, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmplo_ppzi_s, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmpls_ppzi_s, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+
+DEF_HELPER_FLAGS_4(sve_cmpeq_ppzi_d, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmpne_ppzi_d, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmpgt_ppzi_d, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmpge_ppzi_d, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmplt_ppzi_d, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmple_ppzi_d, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmphs_ppzi_d, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmphi_ppzi_d, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmplo_ppzi_d, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_cmpls_ppzi_d, TCG_CALL_NO_RWG, i32, ptr, ptr, ptr, i32)
+
DEF_HELPER_FLAGS_5(sve_and_, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr,
i32)
DEF_HELPER_FLAGS_5(sve_bic_, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr,
i32)
DEF_HELPER_FLAGS_5(sve_eor_, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr,
i32)
diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
index d11f591661..c1d95edfca 100644
--- a/target/arm/sve_helper.c
+++ b/target/arm/sve_helper.c
@@ -2388,3 +2388,91 @@ DO_CMP_PPZW_S(sve_cmpls_ppzw_s, uint32_t, uint64_t, <=)
#undef DO_CMP_PPZW_H
#undef DO_CMP_PPZW_S
#undef DO_CMP_PPZW
+
+/* Similar, but the second source is immediate. */
+#define DO_CMP_PPZI(NAME, TYPE, OP, H, MASK) \
+uint32_t HELPER(NAME)(void *vd, void *vn, void *vg, uint32_t desc) \
+{\
+intptr_t opr_sz = simd_oprsz(desc); \
+uint32_t flags = PREDTEST_INIT; \
+TYPE mm = simd_data(desc); \
+intptr_t i = opr_sz; \
+
[Qemu-devel] [PATCH v2 02/10] qcow2/bitmap: avoid adjusting bm->flags for RO bitmaps
Instead of always setting IN_USE, do this conditionally based on
whether or not the bitmap is read-only. Eliminate the two-pass
processing and move the second loop to the failure case.
This will allow us to show the flags exactly as they appear
on-disk for bitmaps in `qemu-img info`.
Signed-off-by: John Snow
---
block/qcow2-bitmap.c | 51 +--
1 file changed, 21 insertions(+), 30 deletions(-)
diff --git a/block/qcow2-bitmap.c b/block/qcow2-bitmap.c
index 0670e5eb41..85c1b5afe3 100644
--- a/block/qcow2-bitmap.c
+++ b/block/qcow2-bitmap.c
@@ -919,13 +919,6 @@ fail:
return ret;
}
-/* for g_slist_foreach for GSList of BdrvDirtyBitmap* elements */
-static void release_dirty_bitmap_helper(gpointer bitmap,
-gpointer bs)
-{
-bdrv_release_dirty_bitmap(bs, bitmap);
-}
-
/* for g_slist_foreach for GSList of BdrvDirtyBitmap* elements */
static void set_readonly_helper(gpointer bitmap, gpointer value)
{
@@ -944,8 +937,7 @@ bool qcow2_load_dirty_bitmaps(BlockDriverState *bs, Error
**errp)
BDRVQcow2State *s = bs->opaque;
Qcow2BitmapList *bm_list;
Qcow2Bitmap *bm;
-GSList *created_dirty_bitmaps = NULL;
-bool header_updated = false;
+bool needs_update = false;
if (s->nb_bitmaps == 0) {
/* No bitmaps - nothing to do */
@@ -968,35 +960,34 @@ bool qcow2_load_dirty_bitmaps(BlockDriverState *bs, Error
**errp)
bdrv_disable_dirty_bitmap(bitmap);
}
bdrv_dirty_bitmap_set_persistance(bitmap, true);
-bm->flags |= BME_FLAG_IN_USE;
-created_dirty_bitmaps =
-g_slist_append(created_dirty_bitmaps, bitmap);
-}
-}
-
-if (created_dirty_bitmaps != NULL) {
-if (can_write(bs)) {
-/* in_use flags must be updated */
-int ret = update_ext_header_and_dir_in_place(bs, bm_list);
-if (ret < 0) {
-error_setg_errno(errp, -ret, "Can't update bitmap directory");
-goto fail;
+if (can_write(bs)) {
+bm->flags |= BME_FLAG_IN_USE;
+needs_update = true;
+} else {
+bdrv_dirty_bitmap_set_readonly(bitmap, true);
}
-header_updated = true;
-} else {
-g_slist_foreach(created_dirty_bitmaps, set_readonly_helper,
-(gpointer)true);
}
}
-g_slist_free(created_dirty_bitmaps);
+/* in_use flags must be updated */
+if (needs_update) {
+int ret = update_ext_header_and_dir_in_place(bs, bm_list);
+if (ret < 0) {
+error_setg_errno(errp, -ret, "Can't update bitmap directory");
+goto fail;
+}
+}
+
bitmap_list_free(bm_list);
-return header_updated;
+return needs_update;
fail:
-g_slist_foreach(created_dirty_bitmaps, release_dirty_bitmap_helper, bs);
-g_slist_free(created_dirty_bitmaps);
+QSIMPLEQ_FOREACH(bm, bm_list, entry) {
+if (bm->dirty_bitmap) {
+bdrv_release_dirty_bitmap(bs, bm->dirty_bitmap);
+}
+}
bitmap_list_free(bm_list);
return false;
--
2.14.3
Re: [Qemu-devel] [PATCH v8 4/6] migration/ram.c: add ram save state notifiers
On Tue, Jun 12, 2018 at 07:12:47PM +0800, Wei Wang wrote: [...] > Hi Peter, > > Thanks for the review. We just got a little accident in the kernel part, > which may cause some modifications to the QEMU side interfaces. So I will > implement a new version and let you review in v9 patches. No problem. Yeah I actually noticed the accident. Please feel free to postpone the QEMU part until the kernel part is fully settled. Regards, -- Peter Xu
[Qemu-devel] [PATCH v4b 08/18] target/arm: Implement SVE reverse within elements
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper-sve.h| 14 +
target/arm/sve_helper.c| 41 +++---
target/arm/translate-sve.c | 38 +++
target/arm/sve.decode | 7 +++
4 files changed, 93 insertions(+), 7 deletions(-)
diff --git a/target/arm/helper-sve.h b/target/arm/helper-sve.h
index a58fb4ba01..3b7c54905d 100644
--- a/target/arm/helper-sve.h
+++ b/target/arm/helper-sve.h
@@ -465,6 +465,20 @@ DEF_HELPER_FLAGS_4(sve_compact_d, TCG_CALL_NO_RWG, void,
ptr, ptr, ptr, i32)
DEF_HELPER_FLAGS_2(sve_last_active_element, TCG_CALL_NO_RWG, s32, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_revb_h, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_revb_s, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_revb_d, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+
+DEF_HELPER_FLAGS_4(sve_revh_s, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_revh_d, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+
+DEF_HELPER_FLAGS_4(sve_revw_d, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+
+DEF_HELPER_FLAGS_4(sve_rbit_b, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_rbit_h, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_rbit_s, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_rbit_d, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+
DEF_HELPER_FLAGS_5(sve_and_, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr,
i32)
DEF_HELPER_FLAGS_5(sve_bic_, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr,
i32)
DEF_HELPER_FLAGS_5(sve_eor_, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr,
i32)
diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
index cb7d101b57..4017b9eed1 100644
--- a/target/arm/sve_helper.c
+++ b/target/arm/sve_helper.c
@@ -238,6 +238,26 @@ static inline uint64_t expand_pred_s(uint8_t byte)
return word[byte & 0x11];
}
+/* Swap 16-bit words within a 32-bit word. */
+static inline uint32_t hswap32(uint32_t h)
+{
+return rol32(h, 16);
+}
+
+/* Swap 16-bit words within a 64-bit word. */
+static inline uint64_t hswap64(uint64_t h)
+{
+uint64_t m = 0xull;
+h = rol64(h, 32);
+return ((h & m) << 16) | ((h >> 16) & m);
+}
+
+/* Swap 32-bit words within a 64-bit word. */
+static inline uint64_t wswap64(uint64_t h)
+{
+return rol64(h, 32);
+}
+
#define LOGICAL_(NAME, FUNC) \
void HELPER(NAME)(void *vd, void *vn, void *vm, void *vg, uint32_t desc) \
{ \
@@ -616,6 +636,20 @@ DO_ZPZ(sve_neg_h, uint16_t, H1_2, DO_NEG)
DO_ZPZ(sve_neg_s, uint32_t, H1_4, DO_NEG)
DO_ZPZ_D(sve_neg_d, uint64_t, DO_NEG)
+DO_ZPZ(sve_revb_h, uint16_t, H1_2, bswap16)
+DO_ZPZ(sve_revb_s, uint32_t, H1_4, bswap32)
+DO_ZPZ_D(sve_revb_d, uint64_t, bswap64)
+
+DO_ZPZ(sve_revh_s, uint32_t, H1_4, hswap32)
+DO_ZPZ_D(sve_revh_d, uint64_t, hswap64)
+
+DO_ZPZ_D(sve_revw_d, uint64_t, wswap64)
+
+DO_ZPZ(sve_rbit_b, uint8_t, H1, revbit8)
+DO_ZPZ(sve_rbit_h, uint16_t, H1_2, revbit16)
+DO_ZPZ(sve_rbit_s, uint32_t, H1_4, revbit32)
+DO_ZPZ_D(sve_rbit_d, uint64_t, revbit64)
+
/* Three-operand expander, unpredicated, in which the third operand is "wide".
*/
#define DO_ZZW(NAME, TYPE, TYPEW, H, OP) \
@@ -1587,13 +1621,6 @@ void HELPER(sve_rev_b)(void *vd, void *vn, uint32_t desc)
}
}
-static inline uint64_t hswap64(uint64_t h)
-{
-uint64_t m = 0xull;
-h = rol64(h, 32);
-return ((h & m) << 16) | ((h >> 16) & m);
-}
-
void HELPER(sve_rev_h)(void *vd, void *vn, uint32_t desc)
{
intptr_t i, j, opr_sz = simd_oprsz(desc);
diff --git a/target/arm/translate-sve.c b/target/arm/translate-sve.c
index eed59524a9..f8d8cf1547 100644
--- a/target/arm/translate-sve.c
+++ b/target/arm/translate-sve.c
@@ -2643,6 +2643,44 @@ static bool trans_CPY_m_v(DisasContext *s, arg_rpr_esz
*a, uint32_t insn)
return true;
}
+static bool trans_REVB(DisasContext *s, arg_rpr_esz *a, uint32_t insn)
+{
+static gen_helper_gvec_3 * const fns[4] = {
+NULL,
+gen_helper_sve_revb_h,
+gen_helper_sve_revb_s,
+gen_helper_sve_revb_d,
+};
+return do_zpz_ool(s, a, fns[a->esz]);
+}
+
+static bool trans_REVH(DisasContext *s, arg_rpr_esz *a, uint32_t insn)
+{
+static gen_helper_gvec_3 * const fns[4] = {
+NULL,
+NULL,
+gen_helper_sve_revh_s,
+gen_helper_sve_revh_d,
+};
+return do_zpz_ool(s, a, fns[a->esz]);
+}
+
+static bool trans_REVW(DisasContext *s, arg_rpr_esz *a, uint32_t insn)
+{
+return do_zpz_ool(s, a, a->esz == 3 ? gen_helper_sve_revw_d : NULL);
+}
+
+static bool trans_RBIT(DisasContext *s, arg_rpr_esz *a, uint32_t insn)
+{
+static gen_helper_gvec_3 * const fns[4] = {
+gen_helper_sve_rbit_b,
+gen_helper_sve_rbit_h,
+gen_helper_sve_rbit_s,
+gen_helper_sve_rbit_d,
+};
+
[Qemu-devel] [PATCH v4b 05/18] target/arm: Implement SVE compress active elements
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper-sve.h| 3 +++
target/arm/sve_helper.c| 34 ++
target/arm/translate-sve.c | 12
target/arm/sve.decode | 6 ++
4 files changed, 55 insertions(+)
diff --git a/target/arm/helper-sve.h b/target/arm/helper-sve.h
index bab20345c6..d977aea00d 100644
--- a/target/arm/helper-sve.h
+++ b/target/arm/helper-sve.h
@@ -460,6 +460,9 @@ DEF_HELPER_FLAGS_4(sve_trn_h, TCG_CALL_NO_RWG, void, ptr,
ptr, ptr, i32)
DEF_HELPER_FLAGS_4(sve_trn_s, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
DEF_HELPER_FLAGS_4(sve_trn_d, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_compact_s, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_compact_d, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+
DEF_HELPER_FLAGS_5(sve_and_, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr,
i32)
DEF_HELPER_FLAGS_5(sve_bic_, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr,
i32)
DEF_HELPER_FLAGS_5(sve_eor_, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr,
i32)
diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
index f114e9ab63..ed3c6d4ca9 100644
--- a/target/arm/sve_helper.c
+++ b/target/arm/sve_helper.c
@@ -2036,3 +2036,37 @@ DO_TRN(sve_trn_d, uint64_t, )
#undef DO_ZIP
#undef DO_UZP
#undef DO_TRN
+
+void HELPER(sve_compact_s)(void *vd, void *vn, void *vg, uint32_t desc)
+{
+intptr_t i, j, opr_sz = simd_oprsz(desc) / 4;
+uint32_t *d = vd, *n = vn;
+uint8_t *pg = vg;
+
+for (i = j = 0; i < opr_sz; i++) {
+if (pg[H1(i / 2)] & (i & 1 ? 0x10 : 0x01)) {
+d[H4(j)] = n[H4(i)];
+j++;
+}
+}
+for (; j < opr_sz; j++) {
+d[H4(j)] = 0;
+}
+}
+
+void HELPER(sve_compact_d)(void *vd, void *vn, void *vg, uint32_t desc)
+{
+intptr_t i, j, opr_sz = simd_oprsz(desc) / 8;
+uint64_t *d = vd, *n = vn;
+uint8_t *pg = vg;
+
+for (i = j = 0; i < opr_sz; i++) {
+if (pg[H1(i)] & 1) {
+d[j] = n[i];
+j++;
+}
+}
+for (; j < opr_sz; j++) {
+d[j] = 0;
+}
+}
diff --git a/target/arm/translate-sve.c b/target/arm/translate-sve.c
index 21319518d7..ed0f48a927 100644
--- a/target/arm/translate-sve.c
+++ b/target/arm/translate-sve.c
@@ -2284,6 +2284,18 @@ static bool trans_TRN2_z(DisasContext *s, arg_rrr_esz
*a, uint32_t insn)
return do_zzz_data_ool(s, a, 1 << a->esz, trn_fns[a->esz]);
}
+/*
+ *** SVE Permute Vector - Predicated Group
+ */
+
+static bool trans_COMPACT(DisasContext *s, arg_rpr_esz *a, uint32_t insn)
+{
+static gen_helper_gvec_3 * const fns[4] = {
+NULL, NULL, gen_helper_sve_compact_s, gen_helper_sve_compact_d
+};
+return do_zpz_ool(s, a, fns[a->esz]);
+}
+
/*
*** SVE Memory - 32-bit Gather and Unsized Contiguous Group
*/
diff --git a/target/arm/sve.decode b/target/arm/sve.decode
index df2b94dc0a..9da6566d32 100644
--- a/target/arm/sve.decode
+++ b/target/arm/sve.decode
@@ -424,6 +424,12 @@ UZP2_z 0101 .. 1 . 011 011 . .
@rd_rn_rm
TRN1_z 0101 .. 1 . 011 100 . . @rd_rn_rm
TRN2_z 0101 .. 1 . 011 101 . . @rd_rn_rm
+### SVE Permute - Predicated Group
+
+# SVE compress active elements
+# Note esz >= 2
+COMPACT 0101 .. 11 100 ... . . @rd_pg_rn
+
### SVE Predicate Logical Operations Group
# SVE predicate logical operations
--
2.17.1
[Qemu-devel] [PATCH v4b 06/18] target/arm: Implement SVE conditionally broadcast/extract element
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper-sve.h| 2 +
target/arm/sve_helper.c| 12 ++
target/arm/translate-sve.c | 328 +
target/arm/sve.decode | 20 +++
4 files changed, 362 insertions(+)
diff --git a/target/arm/helper-sve.h b/target/arm/helper-sve.h
index d977aea00d..a58fb4ba01 100644
--- a/target/arm/helper-sve.h
+++ b/target/arm/helper-sve.h
@@ -463,6 +463,8 @@ DEF_HELPER_FLAGS_4(sve_trn_d, TCG_CALL_NO_RWG, void, ptr,
ptr, ptr, i32)
DEF_HELPER_FLAGS_4(sve_compact_s, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
DEF_HELPER_FLAGS_4(sve_compact_d, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_2(sve_last_active_element, TCG_CALL_NO_RWG, s32, ptr, i32)
+
DEF_HELPER_FLAGS_5(sve_and_, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr,
i32)
DEF_HELPER_FLAGS_5(sve_bic_, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr,
i32)
DEF_HELPER_FLAGS_5(sve_eor_, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr,
i32)
diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
index ed3c6d4ca9..cb7d101b57 100644
--- a/target/arm/sve_helper.c
+++ b/target/arm/sve_helper.c
@@ -2070,3 +2070,15 @@ void HELPER(sve_compact_d)(void *vd, void *vn, void *vg,
uint32_t desc)
d[j] = 0;
}
}
+
+/* Similar to the ARM LastActiveElement pseudocode function, except the
+ * result is multiplied by the element size. This includes the not found
+ * indication; e.g. not found for esz=3 is -8.
+ */
+int32_t HELPER(sve_last_active_element)(void *vg, uint32_t pred_desc)
+{
+intptr_t oprsz = extract32(pred_desc, 0, SIMD_OPRSZ_BITS) + 2;
+intptr_t esz = extract32(pred_desc, SIMD_DATA_SHIFT, 2);
+
+return last_active_element(vg, DIV_ROUND_UP(oprsz, 8), esz);
+}
diff --git a/target/arm/translate-sve.c b/target/arm/translate-sve.c
index ed0f48a927..feb4c09f1b 100644
--- a/target/arm/translate-sve.c
+++ b/target/arm/translate-sve.c
@@ -2296,6 +2296,334 @@ static bool trans_COMPACT(DisasContext *s, arg_rpr_esz
*a, uint32_t insn)
return do_zpz_ool(s, a, fns[a->esz]);
}
+/* Call the helper that computes the ARM LastActiveElement pseudocode
+ * function, scaled by the element size. This includes the not found
+ * indication; e.g. not found for esz=3 is -8.
+ */
+static void find_last_active(DisasContext *s, TCGv_i32 ret, int esz, int pg)
+{
+/* Predicate sizes may be smaller and cannot use simd_desc. We cannot
+ * round up, as we do elsewhere, because we need the exact size.
+ */
+TCGv_ptr t_p = tcg_temp_new_ptr();
+TCGv_i32 t_desc;
+unsigned vsz = pred_full_reg_size(s);
+unsigned desc;
+
+desc = vsz - 2;
+desc = deposit32(desc, SIMD_DATA_SHIFT, 2, esz);
+
+tcg_gen_addi_ptr(t_p, cpu_env, pred_full_reg_offset(s, pg));
+t_desc = tcg_const_i32(desc);
+
+gen_helper_sve_last_active_element(ret, t_p, t_desc);
+
+tcg_temp_free_i32(t_desc);
+tcg_temp_free_ptr(t_p);
+}
+
+/* Increment LAST to the offset of the next element in the vector,
+ * wrapping around to 0.
+ */
+static void incr_last_active(DisasContext *s, TCGv_i32 last, int esz)
+{
+unsigned vsz = vec_full_reg_size(s);
+
+tcg_gen_addi_i32(last, last, 1 << esz);
+if (is_power_of_2(vsz)) {
+tcg_gen_andi_i32(last, last, vsz - 1);
+} else {
+TCGv_i32 max = tcg_const_i32(vsz);
+TCGv_i32 zero = tcg_const_i32(0);
+tcg_gen_movcond_i32(TCG_COND_GEU, last, last, max, zero, last);
+tcg_temp_free_i32(max);
+tcg_temp_free_i32(zero);
+}
+}
+
+/* If LAST < 0, set LAST to the offset of the last element in the vector. */
+static void wrap_last_active(DisasContext *s, TCGv_i32 last, int esz)
+{
+unsigned vsz = vec_full_reg_size(s);
+
+if (is_power_of_2(vsz)) {
+tcg_gen_andi_i32(last, last, vsz - 1);
+} else {
+TCGv_i32 max = tcg_const_i32(vsz - (1 << esz));
+TCGv_i32 zero = tcg_const_i32(0);
+tcg_gen_movcond_i32(TCG_COND_LT, last, last, zero, max, last);
+tcg_temp_free_i32(max);
+tcg_temp_free_i32(zero);
+}
+}
+
+/* Load an unsigned element of ESZ from BASE+OFS. */
+static TCGv_i64 load_esz(TCGv_ptr base, int ofs, int esz)
+{
+TCGv_i64 r = tcg_temp_new_i64();
+
+switch (esz) {
+case 0:
+tcg_gen_ld8u_i64(r, base, ofs);
+break;
+case 1:
+tcg_gen_ld16u_i64(r, base, ofs);
+break;
+case 2:
+tcg_gen_ld32u_i64(r, base, ofs);
+break;
+case 3:
+tcg_gen_ld_i64(r, base, ofs);
+break;
+default:
+g_assert_not_reached();
+}
+return r;
+}
+
+/* Load an unsigned element of ESZ from RM[LAST]. */
+static TCGv_i64 load_last_active(DisasContext *s, TCGv_i32 last,
+ int rm, int esz)
+{
+TCGv_ptr p = tcg_temp_new_ptr();
+TCGv_i64 r;
+
+/* Convert offset into vector into offset into ENV.
+ * The final adjustment for the vector register base
+ * is
[Qemu-devel] Confusion regarding VMEntry events
Hello all, I am working on developing a "modified" record-replay mechanism for recording and replaying disk and network events along with VMEntry events. I have managed to identify the "correct" points where I am going to record the disk and the network events. But I am not quite sure at which point in the source code do I call the "VMEntry record" handler. I am assuming that the VMEntry usually happens just before the ioctl "KVM_RUN" is called. Specifically the below lines of code :- function : kvm_cpu_exec() . . // record(VMENTRY) -- calling VMENTRY record and replay handler run_ret = kvm_vcpu_ioctl(cpu, KVM_RUN, 0); Is this the correct point where a VMEntry command is "logically" executed by the host CPU ? Are there other places in the KVM code where VMEntries can happen as well ? Please help me out regarding these questions. Thank you. Regards, Arnab
[Qemu-devel] [PATCH v4b 16/18] target/arm: Implement FDUP/DUP
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/translate-sve.c | 37 +
target/arm/sve.decode | 8
2 files changed, 45 insertions(+)
diff --git a/target/arm/translate-sve.c b/target/arm/translate-sve.c
index ae6a504f61..13d5e1 100644
--- a/target/arm/translate-sve.c
+++ b/target/arm/translate-sve.c
@@ -3191,6 +3191,43 @@ static bool trans_WHILE(DisasContext *s, arg_WHILE *a,
uint32_t insn)
return true;
}
+/*
+ *** SVE Integer Wide Immediate - Unpredicated Group
+ */
+
+static bool trans_FDUP(DisasContext *s, arg_FDUP *a, uint32_t insn)
+{
+if (a->esz == 0) {
+return false;
+}
+if (sve_access_check(s)) {
+unsigned vsz = vec_full_reg_size(s);
+int dofs = vec_full_reg_offset(s, a->rd);
+uint64_t imm;
+
+/* Decode the VFP immediate. */
+imm = vfp_expand_imm(a->esz, a->imm);
+imm = dup_const(a->esz, imm);
+
+tcg_gen_gvec_dup64i(dofs, vsz, vsz, imm);
+}
+return true;
+}
+
+static bool trans_DUP_i(DisasContext *s, arg_DUP_i *a, uint32_t insn)
+{
+if (a->esz == 0 && extract32(insn, 13, 1)) {
+return false;
+}
+if (sve_access_check(s)) {
+unsigned vsz = vec_full_reg_size(s);
+int dofs = vec_full_reg_offset(s, a->rd);
+
+tcg_gen_gvec_dup64i(dofs, vsz, vsz, dup_const(a->esz, a->imm));
+}
+return true;
+}
+
/*
*** SVE Memory - 32-bit Gather and Unsized Contiguous Group
*/
diff --git a/target/arm/sve.decode b/target/arm/sve.decode
index 4b718060a9..b8bd22aff7 100644
--- a/target/arm/sve.decode
+++ b/target/arm/sve.decode
@@ -614,6 +614,14 @@ CTERM 00100101 1 sf:1 1 rm:5 001000 rn:5 ne:1
# SVE integer compare scalar count and limit
WHILE 00100101 esz:2 1 rm:5 000 sf:1 u:1 1 rn:5 eq:1 rd:4
+### SVE Integer Wide Immediate - Unpredicated Group
+
+# SVE broadcast floating-point immediate (unpredicated)
+FDUP00100101 esz:2 111 00 1110 imm:8 rd:5
+
+# SVE broadcast integer immediate (unpredicated)
+DUP_i 00100101 esz:2 111 00 011 . rd:5 imm=%sh8_i8s
+
### SVE Memory - 32-bit Gather and Unsized Contiguous Group
# SVE load predicate register
--
2.17.1
[Qemu-devel] [PATCH v4b 03/18] target/arm: Implement SVE Permute - Predicates Group
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper-sve.h| 6 +
target/arm/sve_helper.c| 290 +
target/arm/translate-sve.c | 120 +++
target/arm/sve.decode | 18 +++
4 files changed, 434 insertions(+)
diff --git a/target/arm/helper-sve.h b/target/arm/helper-sve.h
index 0c9aad575e..ff958fcebd 100644
--- a/target/arm/helper-sve.h
+++ b/target/arm/helper-sve.h
@@ -439,6 +439,12 @@ DEF_HELPER_FLAGS_3(sve_uunpk_h, TCG_CALL_NO_RWG, void,
ptr, ptr, i32)
DEF_HELPER_FLAGS_3(sve_uunpk_s, TCG_CALL_NO_RWG, void, ptr, ptr, i32)
DEF_HELPER_FLAGS_3(sve_uunpk_d, TCG_CALL_NO_RWG, void, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_zip_p, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_uzp_p, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_trn_p, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_3(sve_rev_p, TCG_CALL_NO_RWG, void, ptr, ptr, i32)
+DEF_HELPER_FLAGS_3(sve_punpk_p, TCG_CALL_NO_RWG, void, ptr, ptr, i32)
+
DEF_HELPER_FLAGS_5(sve_and_, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr,
i32)
DEF_HELPER_FLAGS_5(sve_bic_, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr,
i32)
DEF_HELPER_FLAGS_5(sve_eor_, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr,
i32)
diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
index 58c0fda333..f4d49d4aff 100644
--- a/target/arm/sve_helper.c
+++ b/target/arm/sve_helper.c
@@ -1674,3 +1674,293 @@ DO_UNPK(sve_uunpk_s, uint32_t, uint16_t, H4, H2)
DO_UNPK(sve_uunpk_d, uint64_t, uint32_t, , H4)
#undef DO_UNPK
+
+/* Mask of bits included in the even numbered predicates of width esz.
+ * We also use this for expand_bits/compress_bits, and so extend the
+ * same pattern out to 16-bit units.
+ */
+static const uint64_t even_bit_esz_masks[5] = {
+0xull,
+0xull,
+0x0f0f0f0f0f0f0f0full,
+0x00ff00ff00ff00ffull,
+0xull,
+};
+
+/* Zero-extend units of 2**N bits to units of 2**(N+1) bits.
+ * For N==0, this corresponds to the operation that in qemu/bitops.h
+ * we call half_shuffle64; this algorithm is from Hacker's Delight,
+ * section 7-2 Shuffling Bits.
+ */
+static uint64_t expand_bits(uint64_t x, int n)
+{
+int i;
+
+x &= 0xu;
+for (i = 4; i >= n; i--) {
+int sh = 1 << i;
+x = ((x << sh) | x) & even_bit_esz_masks[i];
+}
+return x;
+}
+
+/* Compress units of 2**(N+1) bits to units of 2**N bits.
+ * For N==0, this corresponds to the operation that in qemu/bitops.h
+ * we call half_unshuffle64; this algorithm is from Hacker's Delight,
+ * section 7-2 Shuffling Bits, where it is called an inverse half shuffle.
+ */
+static uint64_t compress_bits(uint64_t x, int n)
+{
+int i;
+
+for (i = n; i <= 4; i++) {
+int sh = 1 << i;
+x &= even_bit_esz_masks[i];
+x = (x >> sh) | x;
+}
+return x & 0xu;
+}
+
+void HELPER(sve_zip_p)(void *vd, void *vn, void *vm, uint32_t pred_desc)
+{
+intptr_t oprsz = extract32(pred_desc, 0, SIMD_OPRSZ_BITS) + 2;
+int esz = extract32(pred_desc, SIMD_DATA_SHIFT, 2);
+intptr_t high = extract32(pred_desc, SIMD_DATA_SHIFT + 2, 1);
+uint64_t *d = vd;
+intptr_t i;
+
+if (oprsz <= 8) {
+uint64_t nn = *(uint64_t *)vn;
+uint64_t mm = *(uint64_t *)vm;
+int half = 4 * oprsz;
+
+nn = extract64(nn, high * half, half);
+mm = extract64(mm, high * half, half);
+nn = expand_bits(nn, esz);
+mm = expand_bits(mm, esz);
+d[0] = nn + (mm << (1 << esz));
+} else {
+ARMPredicateReg tmp_n, tmp_m;
+
+/* We produce output faster than we consume input.
+ Therefore we must be mindful of possible overlap. */
+if ((vn - vd) < (uintptr_t)oprsz) {
+vn = memcpy(_n, vn, oprsz);
+}
+if ((vm - vd) < (uintptr_t)oprsz) {
+vm = memcpy(_m, vm, oprsz);
+}
+if (high) {
+high = oprsz >> 1;
+}
+
+if ((high & 3) == 0) {
+uint32_t *n = vn, *m = vm;
+high >>= 2;
+
+for (i = 0; i < DIV_ROUND_UP(oprsz, 8); i++) {
+uint64_t nn = n[H4(high + i)];
+uint64_t mm = m[H4(high + i)];
+
+nn = expand_bits(nn, esz);
+mm = expand_bits(mm, esz);
+d[i] = nn + (mm << (1 << esz));
+}
+} else {
+uint8_t *n = vn, *m = vm;
+uint16_t *d16 = vd;
+
+for (i = 0; i < oprsz / 2; i++) {
+uint16_t nn = n[H1(high + i)];
+uint16_t mm = m[H1(high + i)];
+
+nn = expand_bits(nn, esz);
+mm = expand_bits(mm, esz);
+d16[H2(i)] = nn + (mm << (1 << esz));
+}
+}
+}
+}
+
+void HELPER(sve_uzp_p)(void *vd, void *vn, void *vm, uint32_t pred_desc)
+{
+intptr_t oprsz =
[Qemu-devel] [PATCH v4b 11/18] target/arm: Implement SVE Integer Compare - Vectors Group
Reviewed-by: Peter Maydell Signed-off-by: Richard Henderson --- target/arm/helper-sve.h| 115 +++ target/arm/sve_helper.c| 187 + target/arm/translate-sve.c | 91 ++ target/arm/sve.decode | 24 + 4 files changed, 417 insertions(+) diff --git a/target/arm/helper-sve.h b/target/arm/helper-sve.h index 0f57f64895..6ffd1fbe8e 100644 --- a/target/arm/helper-sve.h +++ b/target/arm/helper-sve.h @@ -490,6 +490,121 @@ DEF_HELPER_FLAGS_4(sve_rbit_d, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32) DEF_HELPER_FLAGS_5(sve_splice, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmpeq_ppzz_b, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmpne_ppzz_b, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmpge_ppzz_b, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmpgt_ppzz_b, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmphi_ppzz_b, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmphs_ppzz_b, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) + +DEF_HELPER_FLAGS_5(sve_cmpeq_ppzz_h, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmpne_ppzz_h, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmpge_ppzz_h, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmpgt_ppzz_h, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmphi_ppzz_h, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmphs_ppzz_h, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) + +DEF_HELPER_FLAGS_5(sve_cmpeq_ppzz_s, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmpne_ppzz_s, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmpge_ppzz_s, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmpgt_ppzz_s, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmphi_ppzz_s, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmphs_ppzz_s, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) + +DEF_HELPER_FLAGS_5(sve_cmpeq_ppzz_d, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmpne_ppzz_d, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmpge_ppzz_d, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmpgt_ppzz_d, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmphi_ppzz_d, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmphs_ppzz_d, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) + +DEF_HELPER_FLAGS_5(sve_cmpeq_ppzw_b, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmpne_ppzw_b, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmpge_ppzw_b, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmpgt_ppzw_b, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmphi_ppzw_b, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmphs_ppzw_b, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmple_ppzw_b, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmplt_ppzw_b, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmplo_ppzw_b, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmpls_ppzw_b, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) + +DEF_HELPER_FLAGS_5(sve_cmpeq_ppzw_h, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmpne_ppzw_h, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmpge_ppzw_h, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmpgt_ppzw_h, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmphi_ppzw_h, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmphs_ppzw_h, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32) +DEF_HELPER_FLAGS_5(sve_cmple_ppzw_h, TCG_CALL_NO_RWG, + i32, ptr, ptr, ptr, ptr, i32)
[Qemu-devel] [PATCH v4b 09/18] target/arm: Implement SVE vector splice (predicated)
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper-sve.h| 2 ++
target/arm/sve_helper.c| 37 +
target/arm/translate-sve.c | 13 +
target/arm/sve.decode | 3 +++
4 files changed, 55 insertions(+)
diff --git a/target/arm/helper-sve.h b/target/arm/helper-sve.h
index 3b7c54905d..c3f8a2b502 100644
--- a/target/arm/helper-sve.h
+++ b/target/arm/helper-sve.h
@@ -479,6 +479,8 @@ DEF_HELPER_FLAGS_4(sve_rbit_h, TCG_CALL_NO_RWG, void, ptr,
ptr, ptr, i32)
DEF_HELPER_FLAGS_4(sve_rbit_s, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
DEF_HELPER_FLAGS_4(sve_rbit_d, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_5(sve_splice, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr, i32)
+
DEF_HELPER_FLAGS_5(sve_and_, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr,
i32)
DEF_HELPER_FLAGS_5(sve_bic_, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr,
i32)
DEF_HELPER_FLAGS_5(sve_eor_, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr,
i32)
diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
index 4017b9eed1..8da7baad76 100644
--- a/target/arm/sve_helper.c
+++ b/target/arm/sve_helper.c
@@ -2109,3 +2109,40 @@ int32_t HELPER(sve_last_active_element)(void *vg,
uint32_t pred_desc)
return last_active_element(vg, DIV_ROUND_UP(oprsz, 8), esz);
}
+
+void HELPER(sve_splice)(void *vd, void *vn, void *vm, void *vg, uint32_t desc)
+{
+intptr_t opr_sz = simd_oprsz(desc) / 8;
+int esz = simd_data(desc);
+uint64_t pg, first_g, last_g, len, mask = pred_esz_masks[esz];
+intptr_t i, first_i, last_i;
+ARMVectorReg tmp;
+
+first_i = last_i = 0;
+first_g = last_g = 0;
+
+/* Find the extent of the active elements within VG. */
+for (i = QEMU_ALIGN_UP(opr_sz, 8) - 8; i >= 0; i -= 8) {
+pg = *(uint64_t *)(vg + i) & mask;
+if (pg) {
+if (last_g == 0) {
+last_g = pg;
+last_i = i;
+}
+first_g = pg;
+first_i = i;
+}
+}
+
+len = 0;
+if (first_g != 0) {
+first_i = first_i * 8 + ctz64(first_g);
+last_i = last_i * 8 + 63 - clz64(last_g);
+len = last_i - first_i + (1 << esz);
+if (vd == vm) {
+vm = memcpy(, vm, opr_sz * 8);
+}
+swap_memmove(vd, vn + first_i, len);
+}
+swap_memmove(vd + len, vm, opr_sz * 8 - len);
+}
diff --git a/target/arm/translate-sve.c b/target/arm/translate-sve.c
index f8d8cf1547..1517d82468 100644
--- a/target/arm/translate-sve.c
+++ b/target/arm/translate-sve.c
@@ -2681,6 +2681,19 @@ static bool trans_RBIT(DisasContext *s, arg_rpr_esz *a,
uint32_t insn)
return do_zpz_ool(s, a, fns[a->esz]);
}
+static bool trans_SPLICE(DisasContext *s, arg_rprr_esz *a, uint32_t insn)
+{
+if (sve_access_check(s)) {
+unsigned vsz = vec_full_reg_size(s);
+tcg_gen_gvec_4_ool(vec_full_reg_offset(s, a->rd),
+ vec_full_reg_offset(s, a->rn),
+ vec_full_reg_offset(s, a->rm),
+ pred_full_reg_offset(s, a->pg),
+ vsz, vsz, a->esz, gen_helper_sve_splice);
+}
+return true;
+}
+
/*
*** SVE Memory - 32-bit Gather and Unsized Contiguous Group
*/
diff --git a/target/arm/sve.decode b/target/arm/sve.decode
index 95eb4968a9..a9fa631252 100644
--- a/target/arm/sve.decode
+++ b/target/arm/sve.decode
@@ -463,6 +463,9 @@ REVH0101 .. 1001 01 100 ... . .
@rd_pg_rn
REVW0101 .. 1001 10 100 ... . . @rd_pg_rn
RBIT0101 .. 1001 11 100 ... . . @rd_pg_rn
+# SVE vector splice (predicated)
+SPLICE 0101 .. 101 100 100 ... . . @rdn_pg_rm
+
### SVE Predicate Logical Operations Group
# SVE predicate logical operations
--
2.17.1
[Qemu-devel] [PATCH v4b 04/18] target/arm: Implement SVE Permute - Interleaving Group
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper-sve.h| 15
target/arm/sve_helper.c| 72
target/arm/translate-sve.c | 75 ++
target/arm/sve.decode | 10 +
4 files changed, 172 insertions(+)
diff --git a/target/arm/helper-sve.h b/target/arm/helper-sve.h
index ff958fcebd..bab20345c6 100644
--- a/target/arm/helper-sve.h
+++ b/target/arm/helper-sve.h
@@ -445,6 +445,21 @@ DEF_HELPER_FLAGS_4(sve_trn_p, TCG_CALL_NO_RWG, void, ptr,
ptr, ptr, i32)
DEF_HELPER_FLAGS_3(sve_rev_p, TCG_CALL_NO_RWG, void, ptr, ptr, i32)
DEF_HELPER_FLAGS_3(sve_punpk_p, TCG_CALL_NO_RWG, void, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_zip_b, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_zip_h, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_zip_s, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_zip_d, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+
+DEF_HELPER_FLAGS_4(sve_uzp_b, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_uzp_h, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_uzp_s, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_uzp_d, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+
+DEF_HELPER_FLAGS_4(sve_trn_b, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_trn_h, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_trn_s, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_trn_d, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+
DEF_HELPER_FLAGS_5(sve_and_, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr,
i32)
DEF_HELPER_FLAGS_5(sve_bic_, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr,
i32)
DEF_HELPER_FLAGS_5(sve_eor_, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr,
i32)
diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
index f4d49d4aff..f114e9ab63 100644
--- a/target/arm/sve_helper.c
+++ b/target/arm/sve_helper.c
@@ -1964,3 +1964,75 @@ void HELPER(sve_punpk_p)(void *vd, void *vn, uint32_t
pred_desc)
}
}
}
+
+#define DO_ZIP(NAME, TYPE, H) \
+void HELPER(NAME)(void *vd, void *vn, void *vm, uint32_t desc) \
+{\
+intptr_t oprsz = simd_oprsz(desc); \
+intptr_t i, oprsz_2 = oprsz / 2; \
+ARMVectorReg tmp_n, tmp_m; \
+/* We produce output faster than we consume input. \
+ Therefore we must be mindful of possible overlap. */ \
+if (unlikely((vn - vd) < (uintptr_t)oprsz)) {\
+vn = memcpy(_n, vn, oprsz_2);\
+}\
+if (unlikely((vm - vd) < (uintptr_t)oprsz)) {\
+vm = memcpy(_m, vm, oprsz_2);\
+}\
+for (i = 0; i < oprsz_2; i += sizeof(TYPE)) {\
+*(TYPE *)(vd + H(2 * i + 0)) = *(TYPE *)(vn + H(i)); \
+*(TYPE *)(vd + H(2 * i + sizeof(TYPE))) = *(TYPE *)(vm + H(i)); \
+}\
+}
+
+DO_ZIP(sve_zip_b, uint8_t, H1)
+DO_ZIP(sve_zip_h, uint16_t, H1_2)
+DO_ZIP(sve_zip_s, uint32_t, H1_4)
+DO_ZIP(sve_zip_d, uint64_t, )
+
+#define DO_UZP(NAME, TYPE, H) \
+void HELPER(NAME)(void *vd, void *vn, void *vm, uint32_t desc) \
+{ \
+intptr_t oprsz = simd_oprsz(desc); \
+intptr_t oprsz_2 = oprsz / 2; \
+intptr_t odd_ofs = simd_data(desc);\
+intptr_t i;\
+ARMVectorReg tmp_m;\
+if (unlikely((vm - vd) < (uintptr_t)oprsz)) { \
+vm = memcpy(_m, vm, oprsz);\
+} \
+for (i = 0; i < oprsz_2; i += sizeof(TYPE)) { \
+*(TYPE *)(vd + H(i)) = *(TYPE *)(vn + H(2 * i + odd_ofs)); \
+} \
+for (i = 0; i < oprsz_2; i += sizeof(TYPE)) { \
+*(TYPE *)(vd + H(oprsz_2 + i)) = *(TYPE *)(vm + H(2 * i + odd_ofs)); \
+} \
+}
+
+DO_UZP(sve_uzp_b, uint8_t, H1)
+DO_UZP(sve_uzp_h, uint16_t, H1_2)
+DO_UZP(sve_uzp_s, uint32_t, H1_4)
+DO_UZP(sve_uzp_d, uint64_t, )
+
+#define DO_TRN(NAME, TYPE, H) \
+void HELPER(NAME)(void *vd, void *vn, void *vm, uint32_t desc) \
+{
[Qemu-devel] [PATCH v4b 07/18] target/arm: Implement SVE copy to vector (predicated)
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/translate-sve.c | 19 +++
target/arm/sve.decode | 6 ++
2 files changed, 25 insertions(+)
diff --git a/target/arm/translate-sve.c b/target/arm/translate-sve.c
index feb4c09f1b..eed59524a9 100644
--- a/target/arm/translate-sve.c
+++ b/target/arm/translate-sve.c
@@ -2624,6 +2624,25 @@ static bool trans_LASTB_r(DisasContext *s, arg_rpr_esz
*a, uint32_t insn)
return do_last_general(s, a, true);
}
+static bool trans_CPY_m_r(DisasContext *s, arg_rpr_esz *a, uint32_t insn)
+{
+if (sve_access_check(s)) {
+do_cpy_m(s, a->esz, a->rd, a->rd, a->pg, cpu_reg_sp(s, a->rn));
+}
+return true;
+}
+
+static bool trans_CPY_m_v(DisasContext *s, arg_rpr_esz *a, uint32_t insn)
+{
+if (sve_access_check(s)) {
+int ofs = vec_reg_offset(s, a->rn, 0, a->esz);
+TCGv_i64 t = load_esz(cpu_env, ofs, a->esz);
+do_cpy_m(s, a->esz, a->rd, a->rd, a->pg, t);
+tcg_temp_free_i64(t);
+}
+return true;
+}
+
/*
*** SVE Memory - 32-bit Gather and Unsized Contiguous Group
*/
diff --git a/target/arm/sve.decode b/target/arm/sve.decode
index 1226867f69..519139f684 100644
--- a/target/arm/sve.decode
+++ b/target/arm/sve.decode
@@ -450,6 +450,12 @@ LASTB_v 0101 .. 10001 1 100 ... . .
@rd_pg_rn
LASTA_r 0101 .. 1 0 101 ... . . @rd_pg_rn
LASTB_r 0101 .. 1 1 101 ... . . @rd_pg_rn
+# SVE copy element from SIMD scalar register
+CPY_m_v 0101 .. 10 100 ... . . @rd_pg_rn
+
+# SVE copy element from general register to vector (predicated)
+CPY_m_r 0101 .. 101000 101 ... . . @rd_pg_rn
+
### SVE Predicate Logical Operations Group
# SVE predicate logical operations
--
2.17.1
[Qemu-devel] [PATCH v4b 02/18] target/arm: Implement SVE Permute - Unpredicated Group
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/helper-sve.h| 23 +++
target/arm/sve_helper.c| 114 +++
target/arm/translate-sve.c | 133 +
target/arm/sve.decode | 27
4 files changed, 297 insertions(+)
diff --git a/target/arm/helper-sve.h b/target/arm/helper-sve.h
index 94f4356ce9..0c9aad575e 100644
--- a/target/arm/helper-sve.h
+++ b/target/arm/helper-sve.h
@@ -416,6 +416,29 @@ DEF_HELPER_FLAGS_4(sve_cpy_z_d, TCG_CALL_NO_RWG, void,
ptr, ptr, i64, i32)
DEF_HELPER_FLAGS_4(sve_ext, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_insr_b, TCG_CALL_NO_RWG, void, ptr, ptr, i64, i32)
+DEF_HELPER_FLAGS_4(sve_insr_h, TCG_CALL_NO_RWG, void, ptr, ptr, i64, i32)
+DEF_HELPER_FLAGS_4(sve_insr_s, TCG_CALL_NO_RWG, void, ptr, ptr, i64, i32)
+DEF_HELPER_FLAGS_4(sve_insr_d, TCG_CALL_NO_RWG, void, ptr, ptr, i64, i32)
+
+DEF_HELPER_FLAGS_3(sve_rev_b, TCG_CALL_NO_RWG, void, ptr, ptr, i32)
+DEF_HELPER_FLAGS_3(sve_rev_h, TCG_CALL_NO_RWG, void, ptr, ptr, i32)
+DEF_HELPER_FLAGS_3(sve_rev_s, TCG_CALL_NO_RWG, void, ptr, ptr, i32)
+DEF_HELPER_FLAGS_3(sve_rev_d, TCG_CALL_NO_RWG, void, ptr, ptr, i32)
+
+DEF_HELPER_FLAGS_4(sve_tbl_b, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_tbl_h, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_tbl_s, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+DEF_HELPER_FLAGS_4(sve_tbl_d, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, i32)
+
+DEF_HELPER_FLAGS_3(sve_sunpk_h, TCG_CALL_NO_RWG, void, ptr, ptr, i32)
+DEF_HELPER_FLAGS_3(sve_sunpk_s, TCG_CALL_NO_RWG, void, ptr, ptr, i32)
+DEF_HELPER_FLAGS_3(sve_sunpk_d, TCG_CALL_NO_RWG, void, ptr, ptr, i32)
+
+DEF_HELPER_FLAGS_3(sve_uunpk_h, TCG_CALL_NO_RWG, void, ptr, ptr, i32)
+DEF_HELPER_FLAGS_3(sve_uunpk_s, TCG_CALL_NO_RWG, void, ptr, ptr, i32)
+DEF_HELPER_FLAGS_3(sve_uunpk_d, TCG_CALL_NO_RWG, void, ptr, ptr, i32)
+
DEF_HELPER_FLAGS_5(sve_and_, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr,
i32)
DEF_HELPER_FLAGS_5(sve_bic_, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr,
i32)
DEF_HELPER_FLAGS_5(sve_eor_, TCG_CALL_NO_RWG, void, ptr, ptr, ptr, ptr,
i32)
diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
index b825e44cb5..58c0fda333 100644
--- a/target/arm/sve_helper.c
+++ b/target/arm/sve_helper.c
@@ -1560,3 +1560,117 @@ void HELPER(sve_ext)(void *vd, void *vn, void *vm,
uint32_t desc)
memcpy(vd + n_siz, , n_ofs);
}
}
+
+#define DO_INSR(NAME, TYPE, H) \
+void HELPER(NAME)(void *vd, void *vn, uint64_t val, uint32_t desc) \
+{ \
+intptr_t opr_sz = simd_oprsz(desc);\
+swap_memmove(vd + sizeof(TYPE), vn, opr_sz - sizeof(TYPE));\
+*(TYPE *)(vd + H(0)) = val;\
+}
+
+DO_INSR(sve_insr_b, uint8_t, H1)
+DO_INSR(sve_insr_h, uint16_t, H1_2)
+DO_INSR(sve_insr_s, uint32_t, H1_4)
+DO_INSR(sve_insr_d, uint64_t, )
+
+#undef DO_INSR
+
+void HELPER(sve_rev_b)(void *vd, void *vn, uint32_t desc)
+{
+intptr_t i, j, opr_sz = simd_oprsz(desc);
+for (i = 0, j = opr_sz - 8; i < opr_sz / 2; i += 8, j -= 8) {
+uint64_t f = *(uint64_t *)(vn + i);
+uint64_t b = *(uint64_t *)(vn + j);
+*(uint64_t *)(vd + i) = bswap64(b);
+*(uint64_t *)(vd + j) = bswap64(f);
+}
+}
+
+static inline uint64_t hswap64(uint64_t h)
+{
+uint64_t m = 0xull;
+h = rol64(h, 32);
+return ((h & m) << 16) | ((h >> 16) & m);
+}
+
+void HELPER(sve_rev_h)(void *vd, void *vn, uint32_t desc)
+{
+intptr_t i, j, opr_sz = simd_oprsz(desc);
+for (i = 0, j = opr_sz - 8; i < opr_sz / 2; i += 8, j -= 8) {
+uint64_t f = *(uint64_t *)(vn + i);
+uint64_t b = *(uint64_t *)(vn + j);
+*(uint64_t *)(vd + i) = hswap64(b);
+*(uint64_t *)(vd + j) = hswap64(f);
+}
+}
+
+void HELPER(sve_rev_s)(void *vd, void *vn, uint32_t desc)
+{
+intptr_t i, j, opr_sz = simd_oprsz(desc);
+for (i = 0, j = opr_sz - 8; i < opr_sz / 2; i += 8, j -= 8) {
+uint64_t f = *(uint64_t *)(vn + i);
+uint64_t b = *(uint64_t *)(vn + j);
+*(uint64_t *)(vd + i) = rol64(b, 32);
+*(uint64_t *)(vd + j) = rol64(f, 32);
+}
+}
+
+void HELPER(sve_rev_d)(void *vd, void *vn, uint32_t desc)
+{
+intptr_t i, j, opr_sz = simd_oprsz(desc);
+for (i = 0, j = opr_sz - 8; i < opr_sz / 2; i += 8, j -= 8) {
+uint64_t f = *(uint64_t *)(vn + i);
+uint64_t b = *(uint64_t *)(vn + j);
+*(uint64_t *)(vd + i) = b;
+*(uint64_t *)(vd + j) = f;
+}
+}
+
+#define DO_TBL(NAME, TYPE, H) \
+void HELPER(NAME)(void *vd, void *vn, void *vm, uint32_t desc) \
+{ \
+intptr_t i, opr_sz = simd_oprsz(desc); \
+uintptr_t elem = opr_sz / sizeof(TYPE);\
+TYPE *d =
[Qemu-devel] [PATCH v4b 00/18] target/arm: SVE instructions, part 2
Here's the second installment of SVE instructions. There are about 25 patches waiting for a third installment; this makes a nice break before beginning with the memory ops. Since v3, r-b tags, comment fixes, and other review feedback. r~ Richard Henderson (18): target/arm: Extend vec_reg_offset to larger sizes target/arm: Implement SVE Permute - Unpredicated Group target/arm: Implement SVE Permute - Predicates Group target/arm: Implement SVE Permute - Interleaving Group target/arm: Implement SVE compress active elements target/arm: Implement SVE conditionally broadcast/extract element target/arm: Implement SVE copy to vector (predicated) target/arm: Implement SVE reverse within elements target/arm: Implement SVE vector splice (predicated) target/arm: Implement SVE Select Vectors Group target/arm: Implement SVE Integer Compare - Vectors Group target/arm: Implement SVE Integer Compare - Immediate Group target/arm: Implement SVE Partition Break Group target/arm: Implement SVE Predicate Count Group target/arm: Implement SVE Integer Compare - Scalars Group target/arm: Implement FDUP/DUP target/arm: Implement SVE Integer Wide Immediate - Unpredicated Group target/arm: Implement SVE Floating Point Arithmetic - Unpredicated Group target/arm/helper-sve.h| 294 target/arm/helper.h| 19 + target/arm/translate-a64.h | 26 +- target/arm/sve_helper.c| 1250 +++ target/arm/translate-sve.c | 1458 target/arm/vec_helper.c| 69 ++ target/arm/sve.decode | 248 ++ 7 files changed, 3355 insertions(+), 9 deletions(-) -- 2.17.1
[Qemu-devel] [PATCH v4b 01/18] target/arm: Extend vec_reg_offset to larger sizes
Rearrange the arithmetic so that we are agnostic about the total size
of the vector and the size of the element. This will allow us to index
up to the 32nd byte and with 16-byte elements.
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/translate-a64.h | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/target/arm/translate-a64.h b/target/arm/translate-a64.h
index dd9c09f89b..63d958cf50 100644
--- a/target/arm/translate-a64.h
+++ b/target/arm/translate-a64.h
@@ -67,18 +67,26 @@ static inline void assert_fp_access_checked(DisasContext *s)
static inline int vec_reg_offset(DisasContext *s, int regno,
int element, TCGMemOp size)
{
-int offs = 0;
+int element_size = 1 << size;
+int offs = element * element_size;
#ifdef HOST_WORDS_BIGENDIAN
/* This is complicated slightly because vfp.zregs[n].d[0] is
- * still the low half and vfp.zregs[n].d[1] the high half
- * of the 128 bit vector, even on big endian systems.
- * Calculate the offset assuming a fully bigendian 128 bits,
- * then XOR to account for the order of the two 64 bit halves.
+ * still the lowest and vfp.zregs[n].d[15] the highest of the
+ * 256 byte vector, even on big endian systems.
+ *
+ * Calculate the offset assuming fully little-endian,
+ * then XOR to account for the order of the 8-byte units.
+ *
+ * For 16 byte elements, the two 8 byte halves will not form a
+ * host int128 if the host is bigendian, since they're in the
+ * wrong order. However the only 16 byte operation we have is
+ * a move, so we can ignore this for the moment. More complicated
+ * operations will have to special case loading and storing from
+ * the zregs array.
*/
-offs += (16 - ((element + 1) * (1 << size)));
-offs ^= 8;
-#else
-offs += element * (1 << size);
+if (element_size < 8) {
+offs ^= 8 - element_size;
+}
#endif
offs += offsetof(CPUARMState, vfp.zregs[regno]);
assert_fp_access_checked(s);
--
2.17.1
[Qemu-devel] Test cases for X6-64
Hello Team, I am looking in your repository for any testsuite to test the semantics for x86-64 instruction. But unfortunately did not get any success. Do you guys mind pointing me ot the right place. Regards, Sandeep
Re: [Qemu-devel] [PATCH v3b 15/18] target/arm: Implement SVE Integer Compare - Scalars Group
On 06/05/2018 08:02 AM, Peter Maydell wrote:
>> +if (count & 63) {
>> +d->p[i] = ~(-1ull << (count & 63)) & esz_mask;
>
> Is this d->p[i] = MAKE_64BIT_MASK(0, count & 63) & esz_mask; ?
Fixed.
>> +tcg_gen_setcond_i64(cond, cmp, rn, rm);
>> +tcg_gen_extrl_i64_i32(cpu_NF, cmp);
>> +tcg_temp_free_i64(cmp);
>> +
>> +/* VF = !NF & !CF. */
>> +tcg_gen_xori_i32(cpu_VF, cpu_NF, 1);
>> +tcg_gen_andc_i32(cpu_VF, cpu_VF, cpu_CF);
>> +
>> +/* Both NF and VF actually look at bit 31. */
>> +tcg_gen_neg_i32(cpu_NF, cpu_NF);
>> +tcg_gen_neg_i32(cpu_VF, cpu_VF);
>
> Microoptimization, but I think you can save an instruction here
> using
>/* VF = !NF & !CF == !(NF || CF); we know NF and CF are
> * both 0 or 1, so the result of the logical NOT has
> * VF bit 31 set or clear as required.
> */
>tcg_gen_or_i32(cpu_VF, cpu_NF, cpu_CF);
>tcg_gen_not_i32(cpu_VF, cpu_VF);
No, ~({0,1} | {0,1}) -> {-1,-2}.
>> +/* For the helper, compress the different conditions into a computation
>> + * of how many iterations for which the condition is true.
>> + *
>> + * This is slightly complicated by 0 <= UINT64_MAX, which is nominally
>> + * 2**64 iterations, overflowing to 0. Of course, predicate registers
>> + * aren't that large, so any value >= predicate size is sufficient.
>> + */
>
> The comment says that 0 <= UINT64_MAX is a special case,
> but I don't understand how the code accounts for it ?
>
>> +tcg_gen_sub_i64(t0, op1, op0);
>> +
>> +/* t0 = MIN(op1 - op0, vsz). */
>> +if (a->eq) {
>> +/* Equality means one more iteration. */
>> +tcg_gen_movi_i64(t1, vsz - 1);
>> +tcg_gen_movcond_i64(TCG_COND_LTU, t0, t0, t1, t0, t1);
By bounding the input, here, to the vector size. This reduces the (2**64-1)+1
case, which we can't represent, to a vsz+1 case, which we can. This produces
the same result for this instruction.
This does point out that I should be using the new tcg_gen_umin_i64 helper
instead of open-coding with movcond.
r~
Re: [Qemu-devel] [PATCH v2 3/8] ppc4xx_i2c: Implement directcntl register
On Wed, Jun 06, 2018 at 03:31:48PM +0200, BALATON Zoltan wrote:
> Signed-off-by: BALATON Zoltan
> ---
> default-configs/ppc-softmmu.mak| 1 +
> default-configs/ppcemb-softmmu.mak | 1 +
> hw/i2c/ppc4xx_i2c.c| 14 +-
> 3 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/default-configs/ppc-softmmu.mak b/default-configs/ppc-softmmu.mak
> index 4d7be45..7d0dc2f 100644
> --- a/default-configs/ppc-softmmu.mak
> +++ b/default-configs/ppc-softmmu.mak
> @@ -26,6 +26,7 @@ CONFIG_USB_EHCI_SYSBUS=y
> CONFIG_SM501=y
> CONFIG_IDE_SII3112=y
> CONFIG_I2C=y
> +CONFIG_BITBANG_I2C=y
>
> # For Macs
> CONFIG_MAC=y
> diff --git a/default-configs/ppcemb-softmmu.mak
> b/default-configs/ppcemb-softmmu.mak
> index 67d18b2..37af193 100644
> --- a/default-configs/ppcemb-softmmu.mak
> +++ b/default-configs/ppcemb-softmmu.mak
> @@ -19,3 +19,4 @@ CONFIG_USB_EHCI_SYSBUS=y
> CONFIG_SM501=y
> CONFIG_IDE_SII3112=y
> CONFIG_I2C=y
> +CONFIG_BITBANG_I2C=y
> diff --git a/hw/i2c/ppc4xx_i2c.c b/hw/i2c/ppc4xx_i2c.c
> index a68b5f7..5806209 100644
> --- a/hw/i2c/ppc4xx_i2c.c
> +++ b/hw/i2c/ppc4xx_i2c.c
> @@ -30,6 +30,7 @@
> #include "cpu.h"
> #include "hw/hw.h"
> #include "hw/i2c/ppc4xx_i2c.h"
> +#include "bitbang_i2c.h"
>
> #define PPC4xx_I2C_MEM_SIZE 18
>
> @@ -46,7 +47,13 @@
>
> #define IIC_XTCNTLSS_SRST (1 << 0)
>
> +#define IIC_DIRECTCNTL_SDAC (1 << 3)
> +#define IIC_DIRECTCNTL_SCLC (1 << 2)
> +#define IIC_DIRECTCNTL_MSDA (1 << 1)
> +#define IIC_DIRECTCNTL_MSCL (1 << 0)
> +
> typedef struct {
> +bitbang_i2c_interface *bitbang;
> uint8_t mdata;
> uint8_t lmadr;
> uint8_t hmadr;
> @@ -308,7 +315,11 @@ static void ppc4xx_i2c_writeb(void *opaque, hwaddr addr,
> uint64_t value,
> i2c->xtcntlss = value;
> break;
> case 16:
> -i2c->directcntl = value & 0x7;
> +i2c->directcntl = value & (IIC_DIRECTCNTL_SDAC &
> IIC_DIRECTCNTL_SCLC);
> +i2c->directcntl |= (value & IIC_DIRECTCNTL_SCLC ? 1 : 0);
> +bitbang_i2c_set(i2c->bitbang, BITBANG_I2C_SCL, i2c->directcntl & 1);
Shouldn't that use i2c->directcntl & IIC_DIRECTCNTL_MSCL ?
> +i2c->directcntl |= bitbang_i2c_set(i2c->bitbang, BITBANG_I2C_SDA,
> + (value & IIC_DIRECTCNTL_SDAC) != 0) << 1;
Last expression might be clearer as:
value & IIC_DIRECTCNTL_SDAC ? IIC_DIRECTCNTL_MSDA : 0
> break;
> default:
> if (addr < PPC4xx_I2C_MEM_SIZE) {
> @@ -343,6 +354,7 @@ static void ppc4xx_i2c_init(Object *o)
> sysbus_init_mmio(SYS_BUS_DEVICE(s), >iomem);
> sysbus_init_irq(SYS_BUS_DEVICE(s), >irq);
> s->bus = i2c_init_bus(DEVICE(s), "i2c");
> +r->bitbang = bitbang_i2c_init(s->bus);
> }
>
> static void ppc4xx_i2c_class_init(ObjectClass *klass, void *data)
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
Re: [Qemu-devel] [PATCH v2 2/8] ppc4xx_i2c: Move register state to private struct and remove unimplemented sdata and intr registers
On Fri, Jun 08, 2018 at 11:20:50AM +0200, BALATON Zoltan wrote:
> On Fri, 8 Jun 2018, David Gibson wrote:
> > On Wed, Jun 06, 2018 at 03:31:48PM +0200, BALATON Zoltan wrote:
> > > Signed-off-by: BALATON Zoltan
> >
> > It's not clear to me why this is preferable to having the registers
> > embedded in the state structure. The latter is pretty standard
> > practice for qemu.
>
> Maybe it will be clearer after the next patch in the series. I needed a
> place to store the bitbang_i2c_interface for the directcntl way of accessing
> the i2c bus but I can't include bitbang_i2c.h from the public header because
> it's a local header. So I needed a local extension to the state struct. Once
> I have that then it's a good place to also store private registers which are
> now defined in the same file so I don't have to look up them in a different
> place. This seemed clearer to me and easier to work with. Maybe the spliting
> of the rewrite did not make this clear.
Oh.. right. There's a better way.
You can just forward declare the bitbang_i2c_interface structure like
this in your header:
typdef struct bitbang_i2c_interface bitbang_i2c_interface;
So you're declaring the existence of the structure, but not its
contents - that's sufficient to create a pointer to it. Then you
don't need to creat the substructure and extra level of indirection.
> One thing I'm not sure about though:
>
> > > ---
> > > hw/i2c/ppc4xx_i2c.c | 75
> > > +
> > > include/hw/i2c/ppc4xx_i2c.h | 19 ++--
> > > 2 files changed, 43 insertions(+), 51 deletions(-)
> > >
> > > diff --git a/hw/i2c/ppc4xx_i2c.c b/hw/i2c/ppc4xx_i2c.c
> > > index d1936db..a68b5f7 100644
> > > --- a/hw/i2c/ppc4xx_i2c.c
> > > +++ b/hw/i2c/ppc4xx_i2c.c
> [...]
> > > @@ -330,7 +335,9 @@ static const MemoryRegionOps ppc4xx_i2c_ops = {
> > > static void ppc4xx_i2c_init(Object *o)
> > > {
> > > PPC4xxI2CState *s = PPC4xx_I2C(o);
> > > +PPC4xxI2CRegs *r = g_malloc0(sizeof(PPC4xxI2CRegs));
> > >
> > > +s->regs = r;
> > > memory_region_init_io(>iomem, OBJECT(s), _i2c_ops, s,
> > >TYPE_PPC4xx_I2C, PPC4xx_I2C_MEM_SIZE);
> > > sysbus_init_mmio(SYS_BUS_DEVICE(s), >iomem);
>
> I allocate memory here but I'm not sure if it should be g_free'd somewhere
> and if so where? I was not able to detangle QOM object hierarchies and there
> seems to be no good docs available or I haven't found them. (PCI devices
> seem to have unrealize methods but this did not work for I2C objects.)
Yes, if you're allocating you definitely should be free()ing. It
should go in the corresponding cleanup routine to where it is
allocated. Since the allocation is in instance_init(), the free()
should be in instance_finalize() (which you'd need to add).
Except that the above should let you avoid that.
..and I guess this won't actually ever be finalized in practice.
..and there doesn't seem to be a way to free up a bitbang_interface,
so even if you added the finalize, it still wouldn't really clean up
properly.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
Re: [Qemu-devel] [PATCH v3b 06/18] target/arm: Implement SVE conditionally broadcast/extract element
On 06/04/2018 06:46 AM, Peter Maydell wrote: >> +do_clast_scalar(s, a->esz, a->pg, a->rn, before, cpu_reg(s, a->rd)); > > Why do we use cpu_reg() again here rather than just using 'reg' ? Fixed. r~
Re: [Qemu-devel] [RFC v1 1/1] virtio-crypto: Allow disabling of cipher algorithms for virtio-crypto device
> -Original Message-
> From: Farhan Ali [mailto:al...@linux.ibm.com]
> Sent: Wednesday, June 13, 2018 3:49 AM
> To: qemu-devel@nongnu.org
> Cc: m...@redhat.com; Gonglei (Arei) ; longpeng
> ; pa...@linux.ibm.com; borntrae...@de.ibm.com;
> fran...@linux.ibm.com; al...@linux.ibm.com
> Subject: [RFC v1 1/1] virtio-crypto: Allow disabling of cipher algorithms for
> virtio-crypto device
>
> The virtio-crypto driver currently propagates to the guest
> all the cipher algorithms that the backend cryptodev can
> support. But in certain cases where the guest has more
> performant mechanism to handle some algorithms, it would be
> useful to propagate only a subset of the algorithms.
>
It makes sense to me. E.g. current Intel CPU has the AES-NI instruction for
accelerating
AES algo. We don't need to propagate AES algos.
> This patch adds support for disabling the cipher
> algorithms of the backend cryptodev.
>
> eg:
> -object cryptodev-backend-builtin,id=cryptodev0
> -device virtio-crypto-ccw,id=crypto0,cryptodev=cryptodev0,cipher-aes-cbc=off
>
> Signed-off-by: Farhan Ali
> ---
>
> Please note this patch is not complete, and there are TODOs to handle
> for other types of algorithms such Hash, AEAD and MAC algorithms.
>
> This is mainly intended to get some feedback on the design approach
> from the community.
>
>
> hw/virtio/virtio-crypto.c | 46
> ---
> include/hw/virtio/virtio-crypto.h | 3 +++
> 2 files changed, 46 insertions(+), 3 deletions(-)
>
> diff --git a/hw/virtio/virtio-crypto.c b/hw/virtio/virtio-crypto.c
> index 9a9fa49..4aed9ca 100644
> --- a/hw/virtio/virtio-crypto.c
> +++ b/hw/virtio/virtio-crypto.c
> @@ -754,12 +754,22 @@ static void virtio_crypto_reset(VirtIODevice *vdev)
> static void virtio_crypto_init_config(VirtIODevice *vdev)
> {
> VirtIOCrypto *vcrypto = VIRTIO_CRYPTO(vdev);
> +uint32_t user_crypto_services = (1u <<
> VIRTIO_CRYPTO_SERVICE_CIPHER) |
> +(1u <<
> VIRTIO_CRYPTO_SERVICE_HASH) |
> +(1u <<
> VIRTIO_CRYPTO_SERVICE_AEAD) |
> +(1u <<
> VIRTIO_CRYPTO_SERVICE_MAC);
> +
> +if (vcrypto->user_cipher_algo_l & (1u << VIRTIO_CRYPTO_NO_CIPHER)) {
> +vcrypto->user_cipher_algo_l = 1u << VIRTIO_CRYPTO_NO_CIPHER;
> +vcrypto->user_cipher_algo_h = 0;
> +user_crypto_services &= ~(1u <<
> VIRTIO_CRYPTO_SERVICE_CIPHER);
> +}
>
> -vcrypto->conf.crypto_services =
> +vcrypto->conf.crypto_services = user_crypto_services &
> vcrypto->conf.cryptodev->conf.crypto_services;
> -vcrypto->conf.cipher_algo_l =
> +vcrypto->conf.cipher_algo_l = vcrypto->user_cipher_algo_l &
> vcrypto->conf.cryptodev->conf.cipher_algo_l;
> -vcrypto->conf.cipher_algo_h =
> +vcrypto->conf.cipher_algo_h = vcrypto->user_cipher_algo_h &
> vcrypto->conf.cryptodev->conf.cipher_algo_h;
> vcrypto->conf.hash_algo = vcrypto->conf.cryptodev->conf.hash_algo;
> vcrypto->conf.mac_algo_l = vcrypto->conf.cryptodev->conf.mac_algo_l;
> @@ -853,6 +863,34 @@ static const VMStateDescription
> vmstate_virtio_crypto = {
> static Property virtio_crypto_properties[] = {
> DEFINE_PROP_LINK("cryptodev", VirtIOCrypto, conf.cryptodev,
> TYPE_CRYPTODEV_BACKEND, CryptoDevBackend
> *),
> +DEFINE_PROP_BIT("no-cipher", VirtIOCrypto, user_cipher_algo_l,
> +VIRTIO_CRYPTO_CIPHER_ARC4, false),
s/ VIRTIO_CRYPTO_CIPHER_ARC4/VIRTIO_CRYPTO_NO_CIPHER/
> +DEFINE_PROP_BIT("cipher-arc4", VirtIOCrypto, user_cipher_algo_l,
> +VIRTIO_CRYPTO_CIPHER_ARC4, false),
> +DEFINE_PROP_BIT("cipher-aes-ecb", VirtIOCrypto, user_cipher_algo_l,
> +VIRTIO_CRYPTO_CIPHER_AES_ECB, false),
> +DEFINE_PROP_BIT("cipher-aes-cbc", VirtIOCrypto, user_cipher_algo_l,
> +VIRTIO_CRYPTO_CIPHER_AES_CBC, false),
> +DEFINE_PROP_BIT("cipher-aes-ctr", VirtIOCrypto, user_cipher_algo_l,
> +VIRTIO_CRYPTO_CIPHER_AES_CTR, false),
> +DEFINE_PROP_BIT("cipher-des-ecb", VirtIOCrypto, user_cipher_algo_l,
> +VIRTIO_CRYPTO_CIPHER_DES_ECB, false),
> +DEFINE_PROP_BIT("cipher-3des-ecb", VirtIOCrypto, user_cipher_algo_l,
> +VIRTIO_CRYPTO_CIPHER_3DES_ECB, false),
> +DEFINE_PROP_BIT("cipher-3des-cbc", VirtIOCrypto, user_cipher_algo_l,
> +VIRTIO_CRYPTO_CIPHER_3DES_CBC, false),
> +DEFINE_PROP_BIT("cipher-3des-ctr", VirtIOCrypto, user_cipher_algo_l,
> +VIRTIO_CRYPTO_CIPHER_3DES_CTR, false),
> +DEFINE_PROP_BIT("cipher-kasumi-f8", VirtIOCrypto, user_cipher_algo_l,
> +VIRTIO_CRYPTO_CIPHER_KASUMI_F8, false),
> +DEFINE_PROP_BIT("cipher-snow3g-uea2", VirtIOCrypto,
> user_cipher_algo_l,
> +VIRTIO_CRYPTO_CIPHER_SNOW3G_UEA2, false),
> +
Re: [Qemu-devel] [PATCH 3/3] target/ppc: filter out non-zero PCR values when using TCG
On Tue, Jun 12, 2018 at 07:04:15PM +0200, Greg Kurz wrote:
> Bits set in the PCR disable features of the processor. TCG currently
> doesn't implement that, ie, we always act like if PCR is all zeros.
>
> But it is still possible for the PCR to have a non-null value. This may
> confuse the guest.
>
> There are three distinct cases:
>
> 1) a powernv guest doing mtspr SPR_PCR
>
> 2) reset of a pseries guest if the max-cpu-compat machine property is set
>
> 3) CAS of a pseries guest
>
> This patch adds a ppc_store_pcr() helper that ensures we cannot put
> a non-null value in the PCR when using TCG. This helper also has
> error propagation support, so that each case listed above can be
> handled appropriately:
>
> 1) since the powernv machine is mostly used for OpenPOWER FW devel,
>we just print an error and let QEMU continue execution
>
> 2) an error is printed and QEMU exits, ie, same behaviour as when
>KVM doesn't support the requested compat mode
>
> 3) an error is printed and QEMU reports H_HARDWARE to the guest
>
> Signed-off-by: Greg Kurz
I'm not really convinced this is a good idea. Printing a (non fatal)
error if the guest attempts to write a non-zero value to the PCR
should be ok. However, you're generating a fatal error if the machine
tries to set the PCR in TCG mode. That could easily happen using,
e.g. the cap-htm flag on a TCG guest. That would take TCG from mostly
working, to refusing to run at all.
> ---
> target/ppc/compat.c | 26 --
> target/ppc/cpu.h |3 +++
> target/ppc/misc_helper.c |9 ++---
> 3 files changed, 33 insertions(+), 5 deletions(-)
>
> diff --git a/target/ppc/compat.c b/target/ppc/compat.c
> index 807c906f6848..08aa99e6ad47 100644
> --- a/target/ppc/compat.c
> +++ b/target/ppc/compat.c
> @@ -138,8 +138,8 @@ void ppc_set_compat(PowerPCCPU *cpu, uint32_t compat_pvr,
> Error **errp)
> {
> const CompatInfo *compat = compat_by_pvr(compat_pvr);
> CPUPPCState *env = >env;
> -PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
> uint64_t pcr;
> +Error *local_err = NULL;
>
> if (!compat_pvr) {
> pcr = 0;
> @@ -165,8 +165,30 @@ void ppc_set_compat(PowerPCCPU *cpu, uint32_t
> compat_pvr, Error **errp)
> }
> }
>
> +ppc_store_pcr(env, pcr, _err);
> +if (local_err) {
> +error_propagate(errp, local_err);
> +return;
> +}
> +
> cpu->compat_pvr = compat_pvr;
> -env->spr[SPR_PCR] = pcr & pcc->pcr_mask;
> +}
> +
> +void ppc_store_pcr(CPUPPCState *env, target_ulong value, Error **errp)
> +{
> +PowerPCCPU *cpu = ppc_env_get_cpu(env);
> +PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
> +
> +/* TODO: this check should go away once we actually put the proper PCR
> + * checks in the various bits of TCG that should have them.
> + */
> +if (!kvm_enabled() && value != 0) {
> +error_setg(errp, "TCG doesn't support PCR value 0x"TARGET_FMT_lx,
> + value);
> +return;
> +}
> +
> +env->spr[SPR_PCR] = value & pcc->pcr_mask;
> }
>
> typedef struct {
> diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
> index a91f1a8777eb..fdaae34feffb 100644
> --- a/target/ppc/cpu.h
> +++ b/target/ppc/cpu.h
> @@ -1296,6 +1296,9 @@ int ppc_cpu_handle_mmu_fault(CPUState *cpu, vaddr
> address, int size, int rw,
> #if !defined(CONFIG_USER_ONLY)
> void ppc_store_sdr1 (CPUPPCState *env, target_ulong value);
> void ppc_store_ptcr(CPUPPCState *env, target_ulong value);
> +#if defined(TARGET_PPC64)
> +void ppc_store_pcr(CPUPPCState *env, target_ulong value, Error **errp);
> +#endif
> #endif /* !defined(CONFIG_USER_ONLY) */
> void ppc_store_msr (CPUPPCState *env, target_ulong value);
>
> diff --git a/target/ppc/misc_helper.c b/target/ppc/misc_helper.c
> index b88493009609..7a9b45a01453 100644
> --- a/target/ppc/misc_helper.c
> +++ b/target/ppc/misc_helper.c
> @@ -21,6 +21,7 @@
> #include "exec/exec-all.h"
> #include "exec/helper-proto.h"
> #include "qemu/error-report.h"
> +#include "qapi/error.h"
>
> #include "helper_regs.h"
>
> @@ -102,10 +103,12 @@ void helper_store_ptcr(CPUPPCState *env, target_ulong
> val)
>
> void helper_store_pcr(CPUPPCState *env, target_ulong value)
> {
> -PowerPCCPU *cpu = ppc_env_get_cpu(env);
> -PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
> +Error *local_err = NULL;
>
> -env->spr[SPR_PCR] = value & pcc->pcr_mask;
> +ppc_store_pcr(env, value, _err);
> +if (local_err) {
> +error_report_err(local_err);
> +}
> }
> #endif /* defined(TARGET_PPC64) */
>
>
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
Re: [Qemu-devel] [PATCH v2] pnv: add a physical mapping array describing MMIO ranges in each chip
On Tue, Jun 12, 2018 at 08:13:49AM +0200, Cédric Le Goater wrote: > On 06/12/2018 07:58 AM, David Gibson wrote: > > On Wed, Jun 06, 2018 at 09:04:10AM +0200, Cédric Le Goater wrote: > >> On 06/06/2018 08:39 AM, David Gibson wrote: > >>> On Wed, May 30, 2018 at 12:07:54PM +0200, Cédric Le Goater wrote: > Based on previous work done in skiboot, the physical mapping array > helps in calculating the MMIO ranges of each controller depending on > the chip id and the chip type. This is will be particularly useful for > the P9 models which use less the XSCOM bus and rely more on MMIOs. > > A link on the chip is now necessary to calculate MMIO BARs and > sizes. This is why such a link is introduced in the PSIHB model. > >>> > >>> I think this message needs some work. This says what it's for, but > >>> what actually *is* this array, and how does it work? > >> > >> OK. It is relatively simple: each controller has an entry defining its > >> MMIO range. > >> > >>> The outside-core differences between POWER8 and POWER9 are substantial > >>> enough that I'm wondering if pnvP8 and pnvP9 would be better off as > >>> different machine types (sharing some routines, of course). > >> > >> yes and no. I have survived using a common PnvChip framework but > >> it is true that I had to add P9 classes for each: LPC, PSI, OCC > >> They are very similar but not enough. P9 uses much more MMIOs than > >> P8 which still uses a lot of XSCOM. I haven't looked at PHB4. > > > > Well, it's certainly *possible* to use the same machine type, I'm just > > not convinced it's a good idea. It seems kind of dodgy to me that so > > many peripherals on the system change as a side-effect of setting the > > cpu. Compare to how x86 works where cpu really does change the CPU, > > plugging it into the same virtual "chipset". Different chipsets *are* > > different machine types there (pc vs. q35). > > OK, I agree, and we can use a set of common routines to instantiate the > different chipset models. > > So we would have a common pnv_init() routine to initialize the different > 'powernv8' and 'powernv9' machines and the PnvChip typename would be a > machine class attribute ? Well.. that's one option. Usually for these things, it works out better to instead of parameterizing big high-level routines like pnv_init(), you have separate versions of those calling a combination of case-specific and common routines as necessary. Mostly it just comes down to what is simplest to implement for you, though. > Nevertheless we would still need to introduce "a physical mapping array > describing MMIO ranges" but we can start by differentiating the chipsets > first. Well, maybe. I'm wondering if you can more easily encapsulate the information in that array in a top-level init routine, that calls common helpers with different addresses / device types / whatever. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: [Qemu-devel] [RFC v1 2/2] crypto/virtio-crypto: Register an algo only if it's supported
> -Original Message-
> From: Farhan Ali [mailto:al...@linux.ibm.com]
> Sent: Wednesday, June 13, 2018 1:08 AM
> To: Gonglei (Arei) ; linux-ker...@vger.kernel.org;
> k...@vger.kernel.org
> Cc: m...@redhat.com; qemu-devel@nongnu.org; longpeng
> ; pa...@linux.ibm.com; fran...@linux.ibm.com;
> borntrae...@de.ibm.com
> Subject: Re: [RFC v1 2/2] crypto/virtio-crypto: Register an algo only if it's
> supported
>
>
>
> On 06/11/2018 04:48 AM, Gonglei (Arei) wrote:
> >
> >
> >> -Original Message-
> >> From: Farhan Ali [mailto:al...@linux.ibm.com]
> >> Sent: Saturday, June 09, 2018 3:09 AM
> >> To: linux-ker...@vger.kernel.org; k...@vger.kernel.org
> >> Cc: m...@redhat.com; qemu-devel@nongnu.org; Gonglei (Arei)
> >> ; longpeng ;
> >> pa...@linux.ibm.com; fran...@linux.ibm.com; borntrae...@de.ibm.com;
> >> al...@linux.ibm.com
> >> Subject: [RFC v1 2/2] crypto/virtio-crypto: Register an algo only if it's
> supported
> >>
> >> From: Farhan Ali
> >>
> >> Register a crypto algo with the Linux crypto layer only if
> >> the algorithm is supported by the backend virtio-crypto
> >> device.
> >>
> >> Also route crypto requests to a virtio-crypto
> >> device, only if it can support the requested service and
> >> algorithm.
> >>
> >> Signed-off-by: Farhan Ali
> >> ---
> >> drivers/crypto/virtio/virtio_crypto_algs.c | 110
> >> ++-
> >> drivers/crypto/virtio/virtio_crypto_common.h | 11 ++-
> >> drivers/crypto/virtio/virtio_crypto_mgr.c| 81
> ++--
> >> 3 files changed, 158 insertions(+), 44 deletions(-)
> >>
> >> diff --git a/drivers/crypto/virtio/virtio_crypto_algs.c
> >> b/drivers/crypto/virtio/virtio_crypto_algs.c
> >> index ba190cf..fef112a 100644
> >> --- a/drivers/crypto/virtio/virtio_crypto_algs.c
> >> +++ b/drivers/crypto/virtio/virtio_crypto_algs.c
> >> @@ -49,12 +49,18 @@ struct virtio_crypto_sym_request {
> >>bool encrypt;
> >> };
> >>
> >> +struct virtio_crypto_algo {
> >> + uint32_t algonum;
> >> + uint32_t service;
> >> + unsigned int active_devs;
> >> + struct crypto_alg algo;
> >> +};
> >> +
> >> /*
> >>* The algs_lock protects the below global virtio_crypto_active_devs
> >>* and crypto algorithms registion.
> >>*/
> >> static DEFINE_MUTEX(algs_lock);
> >> -static unsigned int virtio_crypto_active_devs;
> >> static void virtio_crypto_ablkcipher_finalize_req(
> >>struct virtio_crypto_sym_request *vc_sym_req,
> >>struct ablkcipher_request *req,
> >> @@ -312,13 +318,19 @@ static int virtio_crypto_ablkcipher_setkey(struct
> >> crypto_ablkcipher *tfm,
> >> unsigned int keylen)
> >> {
> >>struct virtio_crypto_ablkcipher_ctx *ctx =
> crypto_ablkcipher_ctx(tfm);
> >> + uint32_t alg;
> >>int ret;
> >>
> >> + ret = virtio_crypto_alg_validate_key(keylen, );
> >> + if (ret)
> >> + return ret;
> >> +
> >>if (!ctx->vcrypto) {
> >>/* New key */
> >>int node = virtio_crypto_get_current_node();
> >>struct virtio_crypto *vcrypto =
> >> -virtcrypto_get_dev_node(node);
> >> +virtcrypto_get_dev_node(node,
> >> +VIRTIO_CRYPTO_SERVICE_CIPHER, alg);
> >>if (!vcrypto) {
> >>pr_err("virtio_crypto: Could not find a virtio device
> >> in the
> >> system\n");
> >
> > We'd better change the above error message now. What about:
> > " virtio_crypto: Could not find a virtio device in the system or
> > unsupported
> algo" ?
> >
> > Regards,
> > -Gonglei
>
>
> Sure, I will update the error message. But other than that does the rest
> of the code looks good to you?
>
Yes, good work. You can add my ack in v2:
Acked-by: Gonglei
Regards,
-Gonglei
Re: [Qemu-devel] [RFC v1 1/2] crypto/virtio-crypto: Read crypto services and algorithm masks
> -Original Message-
> From: Farhan Ali [mailto:al...@linux.ibm.com]
> Sent: Wednesday, June 13, 2018 1:07 AM
> To: Gonglei (Arei) ; linux-ker...@vger.kernel.org;
> k...@vger.kernel.org
> Cc: m...@redhat.com; qemu-devel@nongnu.org; longpeng
> ; pa...@linux.ibm.com; fran...@linux.ibm.com;
> borntrae...@de.ibm.com
> Subject: Re: [RFC v1 1/2] crypto/virtio-crypto: Read crypto services and
> algorithm masks
>
> Hi Arei
>
> On 06/11/2018 02:43 AM, Gonglei (Arei) wrote:
> >
> >> -Original Message-
> >> From: Farhan Ali [mailto:al...@linux.ibm.com]
> >> Sent: Saturday, June 09, 2018 3:09 AM
> >> To: linux-ker...@vger.kernel.org; k...@vger.kernel.org
> >> Cc: m...@redhat.com; qemu-devel@nongnu.org; Gonglei (Arei)
> >> ; longpeng ;
> >> pa...@linux.ibm.com; fran...@linux.ibm.com; borntrae...@de.ibm.com;
> >> al...@linux.ibm.com
> >> Subject: [RFC v1 1/2] crypto/virtio-crypto: Read crypto services and
> algorithm
> >> masks
> >>
> >> Read the crypto services and algorithm masks which provides
> >> information about the services and algorithms supported by
> >> virtio-crypto backend.
> >>
> >> Signed-off-by: Farhan Ali
> >> ---
> >> drivers/crypto/virtio/virtio_crypto_common.h | 14 ++
> >> drivers/crypto/virtio/virtio_crypto_core.c | 29
> >>
> >> 2 files changed, 43 insertions(+)
> >>
> >> diff --git a/drivers/crypto/virtio/virtio_crypto_common.h
> >> b/drivers/crypto/virtio/virtio_crypto_common.h
> >> index 66501a5..05eca12e 100644
> >> --- a/drivers/crypto/virtio/virtio_crypto_common.h
> >> +++ b/drivers/crypto/virtio/virtio_crypto_common.h
> >> @@ -55,6 +55,20 @@ struct virtio_crypto {
> >>/* Number of queue currently used by the driver */
> >>u32 curr_queue;
> >>
> >> + /*
> >> + * Specifies the services mask which the device support,
> >> + * see VIRTIO_CRYPTO_SERVICE_* above
> >> + */
> >
> > Pls update the above comments. Except that:
> >
> > Acked-by: Gonglei
> >
>
> Sure will update the comment. How about " Specifies the services mask
> which the device support, * see VIRTIO_CRYPTO_SERVICE_*" ?
>
It makes sense IMHO :)
Regards,
-Gonglei
> or should I specify the file where the VIRTIO_CRYPTO_SERVICE_* are defined?
>
> Thanks
> Farhan
>
> >> + u32 crypto_services;
> >> +
> >> + /* Detailed algorithms mask */
> >> + u32 cipher_algo_l;
> >> + u32 cipher_algo_h;
> >> + u32 hash_algo;
> >> + u32 mac_algo_l;
> >> + u32 mac_algo_h;
> >> + u32 aead_algo;
> >> +
> >>/* Maximum length of cipher key */
> >>u32 max_cipher_key_len;
> >>/* Maximum length of authenticated key */
> >> diff --git a/drivers/crypto/virtio/virtio_crypto_core.c
> >> b/drivers/crypto/virtio/virtio_crypto_core.c
> >> index 8332698..8f745f2 100644
> >> --- a/drivers/crypto/virtio/virtio_crypto_core.c
> >> +++ b/drivers/crypto/virtio/virtio_crypto_core.c
> >> @@ -303,6 +303,13 @@ static int virtcrypto_probe(struct virtio_device
> *vdev)
> >>u32 max_data_queues = 0, max_cipher_key_len = 0;
> >>u32 max_auth_key_len = 0;
> >>u64 max_size = 0;
> >> + u32 cipher_algo_l = 0;
> >> + u32 cipher_algo_h = 0;
> >> + u32 hash_algo = 0;
> >> + u32 mac_algo_l = 0;
> >> + u32 mac_algo_h = 0;
> >> + u32 aead_algo = 0;
> >> + u32 crypto_services = 0;
> >>
> >>if (!virtio_has_feature(vdev, VIRTIO_F_VERSION_1))
> >>return -ENODEV;
> >> @@ -339,6 +346,20 @@ static int virtcrypto_probe(struct virtio_device
> *vdev)
> >>max_auth_key_len, _auth_key_len);
> >>virtio_cread(vdev, struct virtio_crypto_config,
> >>max_size, _size);
> >> + virtio_cread(vdev, struct virtio_crypto_config,
> >> + crypto_services, _services);
> >> + virtio_cread(vdev, struct virtio_crypto_config,
> >> + cipher_algo_l, _algo_l);
> >> + virtio_cread(vdev, struct virtio_crypto_config,
> >> + cipher_algo_h, _algo_h);
> >> + virtio_cread(vdev, struct virtio_crypto_config,
> >> + hash_algo, _algo);
> >> + virtio_cread(vdev, struct virtio_crypto_config,
> >> + mac_algo_l, _algo_l);
> >> + virtio_cread(vdev, struct virtio_crypto_config,
> >> + mac_algo_h, _algo_h);
> >> + virtio_cread(vdev, struct virtio_crypto_config,
> >> + aead_algo, _algo);
> >>
> >>/* Add virtio crypto device to global table */
> >>err = virtcrypto_devmgr_add_dev(vcrypto);
> >> @@ -358,6 +379,14 @@ static int virtcrypto_probe(struct virtio_device
> *vdev)
> >>vcrypto->max_cipher_key_len = max_cipher_key_len;
> >>vcrypto->max_auth_key_len = max_auth_key_len;
> >>vcrypto->max_size = max_size;
> >> + vcrypto->crypto_services = crypto_services;
> >> + vcrypto->cipher_algo_l = cipher_algo_l;
> >> + vcrypto->cipher_algo_h = cipher_algo_h;
> >> + vcrypto->mac_algo_l = mac_algo_l;
> >> + vcrypto->mac_algo_h = mac_algo_h;
> >> + vcrypto->hash_algo = hash_algo;
> >> + vcrypto->aead_algo = aead_algo;
> >> +
> >>
> >>dev_info(>dev,
> >>"max_queues: %u,
Re: [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
On 6/12/2018 4:54 AM, Michael S. Tsirkin wrote:
On Wed, Jun 06, 2018 at 10:29:03AM +0800, Jason Wang wrote:
On 2018年06月05日 20:33, Michael S. Tsirkin wrote:
I don't think this is sufficient.
If both primary and standby devices are present, a legacy guest without
support for the feature might see two devices with same mac and get
confused.
I think that we should only make primary visible after guest acked the
backup feature bit.
I think we want exactly the reverse? E.g fail the negotiation when guest
does not ack backup feature.
Otherwise legacy guest won't even have the chance to see primary device in
the guest.
That's by design.
And on reset or when backup is cleared in some other way, unplug the
primary.
What if guest does not support hotplug?
It shouldn't ack the backup feature then and it's a good point.
We should both document this and check kernel config has
hotplug support. Sridhar could you take a look pls?
Right now we select NET_FAILOVER when virtio-net is enabled, Should we select
PCI_HOTPLUG when NET_FAILOVER is enabled?
Something like the below will do the job:
Primary device is added with a special "primary-failover" flag.
A virtual machine is then initialized with just a standby virtio
device. Primary is not yet added.
A question is how to do the matching? Qemu knows nothing about e.g mac
address of a pass-through device I believe?
Supply a flag to the VFIO when it's added, this way QEMU will know.
Later QEMU detects that guest driver device set DRIVER_OK.
It then exposes the primary device to the guest, and triggers
a device addition event (hot-plug event) for it.
Do you mean we won't have primary device in the initial qemu cli?
No, that's not what I mean.
I mean management will supply a flag to VFIO and then
- VFIO defers exposing
primary to guest until guest acks the feature bit.
- When we see guest ack, initiate hotplug.
- On reboot, hide it again.
- On reset without reboot, request hot-unplug and on eject hide it again.
If QEMU detects guest driver removal, it initiates a hot-unplug sequence
to remove the primary driver. In particular, if QEMU detects guest
re-initialization (e.g. by detecting guest reset) it immediately removes
the primary device.
I believe guest failover module should handle this gracefully?
It can't control enumeration order, if primary is enumerated before
standby then guest will load its driver and it's too late
when failover driver is loaded.
Does it mean that if guest unloads virtio-net driver, Qemu should automatically
unplug the associated primary device?
What about guest unloading/re-loading primary device driver?
Thanks
We can move some of this code to management as well, architecturally it
does not make too much sense but it might be easier implementation-wise.
HTH
On Mon, Jun 04, 2018 at 06:41:48PM -0700, Samudrala, Sridhar wrote:
Ping on this patch now that the kernel patches are accepted into davem's
net-next tree.
https://patchwork.ozlabs.org/cover/920005/
On 5/7/2018 4:09 PM, Sridhar Samudrala wrote:
This feature bit can be used by hypervisor to indicate virtio_net device to
act as a standby for another device with the same MAC address.
I tested this with a small change to the patch to mark the STANDBY feature
'true'
by default as i am using libvirt to start the VMs.
Is there a way to pass the newly added feature bit 'standby' to qemu via libvirt
XML file?
Signed-off-by: Sridhar Samudrala
---
hw/net/virtio-net.c | 2 ++
include/standard-headers/linux/virtio_net.h | 3 +++
2 files changed, 5 insertions(+)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 90502fca7c..38b3140670 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -2198,6 +2198,8 @@ static Property virtio_net_properties[] = {
true),
DEFINE_PROP_INT32("speed", VirtIONet, net_conf.speed, SPEED_UNKNOWN),
DEFINE_PROP_STRING("duplex", VirtIONet, net_conf.duplex_str),
+DEFINE_PROP_BIT64("standby", VirtIONet, host_features,
VIRTIO_NET_F_STANDBY,
+ false),
DEFINE_PROP_END_OF_LIST(),
};
diff --git a/include/standard-headers/linux/virtio_net.h
b/include/standard-headers/linux/virtio_net.h
index e9f255ea3f..01ec09684c 100644
--- a/include/standard-headers/linux/virtio_net.h
+++ b/include/standard-headers/linux/virtio_net.h
@@ -57,6 +57,9 @@
* Steering */
#define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
+#define VIRTIO_NET_F_STANDBY 62/* Act as standby for another device
+ * with the same MAC.
+ */
#define VIRTIO_NET_F_SPEED_DUPLEX 63/* Device set linkspeed and
duplex */
#ifndef VIRTIO_NET_NO_LEGACY
Re: [Qemu-devel] [virtio-dev] Re: [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
On 6/12/2018 4:34 AM, Michael S. Tsirkin wrote:
On Mon, Jun 11, 2018 at 10:02:45PM -0700, Samudrala, Sridhar wrote:
On 6/11/2018 7:17 PM, Michael S. Tsirkin wrote:
On Tue, Jun 12, 2018 at 09:54:44AM +0800, Jason Wang wrote:
On 2018年06月12日 01:26, Michael S. Tsirkin wrote:
On Mon, May 07, 2018 at 04:09:54PM -0700, Sridhar Samudrala wrote:
This feature bit can be used by hypervisor to indicate virtio_net device to
act as a standby for another device with the same MAC address.
I tested this with a small change to the patch to mark the STANDBY feature
'true'
by default as i am using libvirt to start the VMs.
Is there a way to pass the newly added feature bit 'standby' to qemu via libvirt
XML file?
Signed-off-by: Sridhar Samudrala
So I do not think we can commit to this interface: we
really need to control visibility of the primary device.
The problem is legacy guest won't use primary device at all if we do this.
And that's by design - I think it's the only way to ensure the
legacy guest isn't confused.
Yes. I think so. But i am not sure if Qemu is the right place to control the
visibility
of the primary device. The primary device may not be specified as an argument
to Qemu. It
may be plugged in later.
The cloud service provider is providing a feature that enables low latency
datapath and live
migration capability.
A tenant can use this feature only if he is running a VM that has virtio-net
with failover support.
Well live migration is there already. The new feature is low latency
data path.
we get live migration with just virtio. But I meant live migration with VF as
primary device.
And it's the guest that needs failover support not the VM.
Isn't guest and VM synonymous?
I think Qemu should check if guest virtio-net supports this feature and provide
a mechanism for
an upper layer indicating if the STANDBY feature is successfully negotiated or
not.
The upper layer can then decide if it should hot plug a VF with the same MAC
and manage the 2 links.
If VF is successfully hot plugged, virtio-net link should be disabled.
Did you even talk to upper layer management about it?
Just list the steps they need to do and you will see
that's a lot of machinery to manage by the upper layer.
What do we gain in flexibility? As far as I can see the
only gain is some resources saved for legacy VMs.
That's not a lot as tenant of the upper layer probably already has
at least a hunch that it's a new guest otherwise
why bother specifying the feature at all - you
save even more resources without it.
I am not all that familiar with how Qemu manages network devices. If we can do
all the
required management of the primary/standby devices within Qemu, that is
definitely a better
approach without upper layer involvement.
How about control the visibility of standby device?
Thanks
standy the always there to guarantee no downtime.
However just for testing purposes, we could add a non-stable
interface "x-standby" with the understanding that as any
x- prefix it's unstable and will be changed down the road,
likely in the next release.
---
hw/net/virtio-net.c | 2 ++
include/standard-headers/linux/virtio_net.h | 3 +++
2 files changed, 5 insertions(+)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 90502fca7c..38b3140670 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -2198,6 +2198,8 @@ static Property virtio_net_properties[] = {
true),
DEFINE_PROP_INT32("speed", VirtIONet, net_conf.speed, SPEED_UNKNOWN),
DEFINE_PROP_STRING("duplex", VirtIONet, net_conf.duplex_str),
+DEFINE_PROP_BIT64("standby", VirtIONet, host_features,
VIRTIO_NET_F_STANDBY,
+ false),
DEFINE_PROP_END_OF_LIST(),
};
diff --git a/include/standard-headers/linux/virtio_net.h
b/include/standard-headers/linux/virtio_net.h
index e9f255ea3f..01ec09684c 100644
--- a/include/standard-headers/linux/virtio_net.h
+++ b/include/standard-headers/linux/virtio_net.h
@@ -57,6 +57,9 @@
* Steering */
#define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
+#define VIRTIO_NET_F_STANDBY 62/* Act as standby for another device
+ * with the same MAC.
+ */
#define VIRTIO_NET_F_SPEED_DUPLEX 63/* Device set linkspeed and
duplex */
#ifndef VIRTIO_NET_NO_LEGACY
--
2.14.3
-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[Qemu-devel] [PATCH 2/2] xen: add block resize support for xen disks
In the context of a monitor based disk resize, provide notification
of the new size to the front end xen block driver via a xenstore update.
Signed-off-by: Bruce Rogers
---
block/block-backend.c | 7 +++
blockdev.c | 8
hw/block/xen_disk.c| 9 +
include/hw/xen/xen.h | 2 ++
include/sysemu/block-backend.h | 2 ++
stubs/xen-common.c | 4
6 files changed, 32 insertions(+)
diff --git a/block/block-backend.c b/block/block-backend.c
index db39dfe867..e1b0db8363 100644
--- a/block/block-backend.c
+++ b/block/block-backend.c
@@ -2003,6 +2003,13 @@ int blk_truncate(BlockBackend *blk, int64_t offset,
PreallocMode prealloc,
return bdrv_truncate(blk->root, offset, prealloc, errp);
}
+void blk_legacy_resize_cb(BlockBackend *blk)
+{
+if (blk->legacy_dev) {
+xen_blk_resize_cb(blk->dev);
+}
+}
+
static void blk_pdiscard_entry(void *opaque)
{
BlkRwCo *rwco = opaque;
diff --git a/blockdev.c b/blockdev.c
index 4862323012..4dd34ad424 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -3174,6 +3174,7 @@ void qmp_block_resize(bool has_device, const char *device,
{
Error *local_err = NULL;
BlockBackend *blk = NULL;
+BlockBackend *cb_blk = NULL;
BlockDriverState *bs;
AioContext *aio_context;
int ret;
@@ -3186,6 +3187,10 @@ void qmp_block_resize(bool has_device, const char
*device,
return;
}
+if (has_device) {
+cb_blk = blk_by_name(device);
+}
+
aio_context = bdrv_get_aio_context(bs);
aio_context_acquire(aio_context);
@@ -3212,6 +3217,9 @@ void qmp_block_resize(bool has_device, const char *device,
bdrv_drained_begin(bs);
ret = blk_truncate(blk, size, PREALLOC_MODE_OFF, errp);
+if (!ret && cb_blk) {
+blk_legacy_resize_cb(cb_blk);
+}
bdrv_drained_end(bs);
out:
diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index fca0597d36..e69c7f590c 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -1013,6 +1013,15 @@ char *xen_blk_get_attached_dev_id(void *dev)
return g_strdup_printf("xen-qdisk-%i", blkdev->xendev.dev);
}
+void xen_blk_resize_cb(void *dev)
+{
+struct XenBlkDev *blkdev = dev;
+blkdev->file_size = blk_getlength(blkdev->blk);
+xenstore_write_be_int64(>xendev, "sectors",
+blkdev->file_size / blkdev->file_blk);
+xen_be_set_state(>xendev, blkdev->xendev.be_state);
+}
+
struct XenDevOps xen_blkdev_ops = {
.flags = DEVOPS_FLAG_NEED_GNTDEV,
.size = sizeof(struct XenBlkDev),
diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
index a201517675..d923ae53f1 100644
--- a/include/hw/xen/xen.h
+++ b/include/hw/xen/xen.h
@@ -50,4 +50,6 @@ void xen_register_framebuffer(struct MemoryRegion *mr);
char *xen_blk_get_attached_dev_id(void *dev);
+void xen_blk_resize_cb(void *dev);
+
#endif /* QEMU_HW_XEN_H */
diff --git a/include/sysemu/block-backend.h b/include/sysemu/block-backend.h
index 8d03d493c2..0ccaf5b035 100644
--- a/include/sysemu/block-backend.h
+++ b/include/sysemu/block-backend.h
@@ -236,4 +236,6 @@ int coroutine_fn blk_co_copy_range(BlockBackend *blk_in,
int64_t off_in,
BlockBackend *blk_out, int64_t off_out,
int bytes, BdrvRequestFlags flags);
+void blk_legacy_resize_cb(BlockBackend *blk);
+
#endif
diff --git a/stubs/xen-common.c b/stubs/xen-common.c
index aeac0534ac..c2cbf81a87 100644
--- a/stubs/xen-common.c
+++ b/stubs/xen-common.c
@@ -17,3 +17,7 @@ char *xen_blk_get_attached_dev_id(void *dev)
{
return g_strdup("");
}
+
+void xen_blk_resize_cb(void *dev)
+{
+}
--
2.17.1
[Qemu-devel] [PATCH 1/2] xen: add xen disk naming for use in monitor
Provide monitor naming of xen disks, including associating an
attached dev_id for a BlockBackend which has legacy_dev set.
Currently, only xen disks have legacy_dev set to true.
Signed-off-by: Bruce Rogers
---
block/block-backend.c | 5 -
hw/block/xen_disk.c | 15 +++
include/hw/xen/xen.h | 2 ++
stubs/xen-common.c| 5 +
4 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/block/block-backend.c b/block/block-backend.c
index d55c328736..db39dfe867 100644
--- a/block/block-backend.c
+++ b/block/block-backend.c
@@ -23,6 +23,7 @@
#include "qemu/option.h"
#include "trace.h"
#include "migration/misc.h"
+#include "hw/xen/xen.h"
/* Number of coroutines to reserve per attached device model */
#define COROUTINE_POOL_RESERVATION 64
@@ -895,7 +896,9 @@ char *blk_get_attached_dev_id(BlockBackend *blk)
{
DeviceState *dev;
-assert(!blk->legacy_dev);
+if (blk->legacy_dev) {
+return xen_blk_get_attached_dev_id(blk->dev);
+}
dev = blk->dev;
if (!dev) {
diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 9fbc0cdb87..fca0597d36 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -745,6 +745,7 @@ static int blk_connect(struct XenDevice *xendev)
int order, ring_ref;
unsigned int ring_size, max_grants;
unsigned int i;
+Error *errp = NULL;
trace_xen_disk_connect(xendev->name);
@@ -801,6 +802,13 @@ static int blk_connect(struct XenDevice *xendev)
blk_ref(blkdev->blk);
}
blk_attach_dev_legacy(blkdev->blk, blkdev);
+if (!monitor_add_blk(blkdev->blk, g_strdup(blkdev->dev), )) {
+xen_pv_printf(>xendev, 0, "error: %s\n",
+ error_get_pretty(errp));
+error_free(errp);
+return -1;
+}
+
blkdev->file_size = blk_getlength(blkdev->blk);
if (blkdev->file_size < 0) {
BlockDriverState *bs = blk_bs(blkdev->blk);
@@ -951,6 +959,7 @@ static void blk_disconnect(struct XenDevice *xendev)
if (blkdev->blk) {
blk_set_aio_context(blkdev->blk, qemu_get_aio_context());
blk_detach_dev(blkdev->blk, blkdev);
+monitor_remove_blk(blkdev->blk);
blk_unref(blkdev->blk);
blkdev->blk = NULL;
}
@@ -998,6 +1007,12 @@ static void blk_event(struct XenDevice *xendev)
qemu_bh_schedule(blkdev->bh);
}
+char *xen_blk_get_attached_dev_id(void *dev)
+{
+struct XenBlkDev *blkdev = dev;
+return g_strdup_printf("xen-qdisk-%i", blkdev->xendev.dev);
+}
+
struct XenDevOps xen_blkdev_ops = {
.flags = DEVOPS_FLAG_NEED_GNTDEV,
.size = sizeof(struct XenBlkDev),
diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
index 7efcdaa8fe..a201517675 100644
--- a/include/hw/xen/xen.h
+++ b/include/hw/xen/xen.h
@@ -48,4 +48,6 @@ void xen_hvm_modified_memory(ram_addr_t start, ram_addr_t
length);
void xen_register_framebuffer(struct MemoryRegion *mr);
+char *xen_blk_get_attached_dev_id(void *dev);
+
#endif /* QEMU_HW_XEN_H */
diff --git a/stubs/xen-common.c b/stubs/xen-common.c
index 09fce2dd36..aeac0534ac 100644
--- a/stubs/xen-common.c
+++ b/stubs/xen-common.c
@@ -12,3 +12,8 @@
void xenstore_store_pv_console_info(int i, Chardev *chr)
{
}
+
+char *xen_blk_get_attached_dev_id(void *dev)
+{
+return g_strdup("");
+}
--
2.17.1
[Qemu-devel] [PATCH 0/2] xen: add block resize infrastructure
Resizing a disk on the fly is useful, including for Xen guests. Xen has this capability, except in the case of qdisks (Xen QEMU disks). This patch series intends to provide this capability. With these patches, the xl command "qemu-monitor-command" can be used in conjunction with the "info block" and "block_resize" commands to help identify and then resize a Xen qdisk. It is anticipated that Xen's libxl will be extended to handle qdisk resizing without resorting to using the human monitor in this way, with libvirt support eventually building on top of that. Bruce Rogers (2): xen: add xen disk naming for use in monitor xen: add block resize support for xen disks block/block-backend.c | 12 +++- blockdev.c | 8 hw/block/xen_disk.c| 24 include/hw/xen/xen.h | 4 include/sysemu/block-backend.h | 2 ++ stubs/xen-common.c | 9 + 6 files changed, 58 insertions(+), 1 deletion(-) -- 2.17.1
Re: [Qemu-devel] [PATCH v2] xics_kvm: fix a build break
On Tue, Jun 12, 2018 at 12:11:35PM +0200, Cédric Le Goater wrote:
> On CentOS 7.5, gcc-4.8.5-28.el7_5.1.ppc64le fails to build QEMU due to :
>
> hw/intc/xics_kvm.c: In function ‘ics_set_kvm_state’:
> hw/intc/xics_kvm.c:281:13: error: ‘ret’ may be used uninitialized in this
> function [-Werror=maybe-uninitialized]
> return ret;
>
> Fix the breakage and also remove the extra error reporting as
> kvm_device_access() already provides a substantial error message.
>
> Signed-off-by: Cédric Le Goater
Applied to ppc-for-3.0, thanks.
> ---
>
> Greg, can you please test ? RHEL7.5 does not catch the issue with the
> same compiler level :/ I don't understand why.
>
> hw/intc/xics_kvm.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/hw/intc/xics_kvm.c b/hw/intc/xics_kvm.c
> index 8bdf6afe82a0..8dba2f84e71e 100644
> --- a/hw/intc/xics_kvm.c
> +++ b/hw/intc/xics_kvm.c
> @@ -186,8 +186,7 @@ static void ics_get_kvm_state(ICSState *ics)
> kvm_device_access(kernel_xics_fd, KVM_DEV_XICS_GRP_SOURCES,
>i + ics->offset, , false, _err);
> if (local_err) {
> -error_report("Unable to retrieve KVM interrupt controller state"
> -" for IRQ %d: %s", i + ics->offset, strerror(errno));
> +error_report_err(local_err);
> exit(1);
> }
>
> @@ -273,11 +272,10 @@ static int ics_set_kvm_state(ICSState *ics, int
> version_id)
> state |= KVM_XICS_QUEUED;
> }
>
> -kvm_device_access(kernel_xics_fd, KVM_DEV_XICS_GRP_SOURCES,
> - i + ics->offset, , true, _err);
> +ret = kvm_device_access(kernel_xics_fd, KVM_DEV_XICS_GRP_SOURCES,
> +i + ics->offset, , true, _err);
> if (local_err) {
> -error_report("Unable to restore KVM interrupt controller state"
> -" for IRQs %d: %s", i + ics->offset, strerror(errno));
> +error_report_err(local_err);
> return ret;
> }
> }
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
Re: [Qemu-devel] [PATCH 0/7] mac99: add via-pmu support
On Tue, Jun 12, 2018 at 05:43:55PM +0100, Mark Cave-Ayland wrote: > This patchset is based upon Ben H's experimental branch which adds PMU > support to the QEMU mac99 machine. Currently mac99 uses the via-cuda > device which works in a lot of cases, but many OSs such as MacOS 10.5 > only support via-pmu. > > A lot of the work I've been doing on the Mac machines over the past > year or so has been to enable me to remove all the hacks from the PMU > work to enable it to be submitted upstream, and here we are. > > The choice of via is controlled with a new "via" machine option which > has 3 values: > > via=cuda > - Use via-cuda as per the current mac99 machine but largely unsupported > > via=pmu-adb > - Use via-pmu but attach the mouse and keyboard to the PMU ADB bus > rather than USB (useful for esoteric OS X images) > > via=pmu > - Use via-pmu with USB mouse and keyboards, as per a real PowerMac3,1 > machine > > Eventually the aim is to switch the mac99 default option to via=pmu but > there are some minor issues with older OS X related to timer calibration > and USB that means I'm not ready to do that just yet. > > Note that the via-pmu device also requires an updated OpenBIOS containing > a suitable PMU driver which have been posted over to the OpenBIOS mailing > list at https://mail.coreboot.org/pipermail/openbios/2018-June/010384.html. > > Signed-off-by: Mark Cave-Ayland Applied to ppc-for-3.0, thanks. > > > Mark Cave-Ayland (7): > ppc: introduce Core99MachinesState for the mac99 machine > mac_newworld: add via machine option to control mac99 VIA/ADB > configuration > mac_newworld: add gpios to macio devices with PMU enabled > mac_newworld: wire up programmer switch to NMI handler > adb: fix read reg 3 byte ordering > adb: add property to disable direct reg 3 writes > mac_newworld: add PMU device > > default-configs/ppc-softmmu.mak | 2 + > hw/input/adb-kbd.c | 29 +- > hw/input/adb-mouse.c| 41 +- > hw/input/adb.c | 7 + > hw/misc/macio/Makefile.objs | 2 + > hw/misc/macio/gpio.c| 231 +++ > hw/misc/macio/macio.c | 89 +++- > hw/misc/macio/pmu.c | 871 > > hw/misc/macio/trace-events | 28 ++ > hw/ppc/mac.h| 20 + > hw/ppc/mac_newworld.c | 84 +++- > include/hw/input/adb.h | 1 + > include/hw/misc/macio/gpio.h| 47 +++ > include/hw/misc/macio/macio.h | 7 + > include/hw/misc/macio/pmu.h | 237 +++ > include/hw/ppc/ppc.h| 1 + > 16 files changed, 1639 insertions(+), 58 deletions(-) > create mode 100644 hw/misc/macio/gpio.c > create mode 100644 hw/misc/macio/pmu.c > create mode 100644 include/hw/misc/macio/gpio.h > create mode 100644 include/hw/misc/macio/pmu.h > -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: [Qemu-devel] [PULL 00/33] ppc-for-3.0 queue 20180612
On Tue, Jun 12, 2018 at 08:46:03PM +0200, Greg Kurz wrote: > On Tue, 12 Jun 2018 16:55:08 +0100 > Peter Maydell wrote: > > > On 12 June 2018 at 16:52, Greg Kurz wrote: > > > On Tue, 12 Jun 2018 15:34:22 +0100 > > > Peter Maydell wrote: > > > > > >> On 12 June 2018 at 07:44, David Gibson > > >> wrote: > > >> > > > >> > ppc patch queue 2018-06-12 > > >> > > > >> > Here's another batch of ppc patches towards the 3.0 release. There's > > >> > a fair bit here, because I've been working through my mail backlog > > >> > after a holiday. There's not much of a central theme, amongst other > > >> > things we have: > > >> > * ppc440 / sam460ex improvements > > >> > * logging and error cleanups > > >> > * 40p (PReP) bugfixes > > >> > * Macintosh fixes and cleanups > > >> > * Add emulation of the new POWER9 store-forwarding barrier > > >> > instruction variant > > >> > * Hotplug cleanups > > >> > > > >> > > >> Applied, thanks. > > > > > Oh... so we've broken bisect until Cedric's fix is merged. > > > > If you want me not to merge a pullreq you need to follow up to > > the cover letter saying "please don't merge this" or something > > similar. Otherwise I will not notice. > > Yeah I've only answered to the offending patch, sorry... And it was the middle of the night for me. It's only with pretty old gcc, I think we can live with it, I intend to send another pullreq with the fixup as soon as I can. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: [Qemu-devel] [PATCH 1/3] target/ppc: drop empty #if/#endif block
On Tue, Jun 12, 2018 at 06:27:54PM +0200, Greg Kurz wrote: > Commit 9d6f106552fa moved the last line in this block to somewhere else, > but it forgot to remove the now useless #if/#endif. > > Signed-off-by: Greg Kurz Applied to ppc-for-3.0, thanks. > --- > target/ppc/cpu.h |2 -- > 1 file changed, 2 deletions(-) > > diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h > index 0247c1f04c37..a91f1a8777eb 100644 > --- a/target/ppc/cpu.h > +++ b/target/ppc/cpu.h > @@ -1300,8 +1300,6 @@ void ppc_store_ptcr(CPUPPCState *env, target_ulong > value); > void ppc_store_msr (CPUPPCState *env, target_ulong value); > > void ppc_cpu_list (FILE *f, fprintf_function cpu_fprintf); > -#if defined(TARGET_PPC64) > -#endif > > /* Time-base and decrementer management */ > #ifndef NO_CPU_IO_DEFS > -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: [Qemu-devel] [PATCH 2/3] spapr: fix leak in h_client_architecture_support()
On Tue, Jun 12, 2018 at 07:01:26PM +0200, Greg Kurz wrote: > If the negotiated compat mode can't be set, but raw mode is supported, > we decide to ignore the error. An so, we should free it to prevent a > memory leak. > > Signed-off-by: Greg Kurz Applied to ppc-for-3.0, thanks. > --- > hw/ppc/spapr_hcall.c |1 + > 1 file changed, 1 insertion(+) > > diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c > index 022f6d810182..8b9a4b577fbf 100644 > --- a/hw/ppc/spapr_hcall.c > +++ b/hw/ppc/spapr_hcall.c > @@ -1547,6 +1547,7 @@ static target_ulong > h_client_architecture_support(PowerPCCPU *cpu, > error_report_err(local_err); > return H_HARDWARE; > } > +error_free(local_err); > local_err = NULL; > } > } > -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: [Qemu-devel] [Qemu-stable] [PATCH v2] replace functions which are only available in glib-2.24
Quoting Cornelia Huck (2018-05-15 03:09:49)
> On Tue, 15 May 2018 09:18:52 +0200
> Thomas Huth wrote:
>
> > On 15.05.2018 08:31, Olaf Hering wrote:
> > > Currently the minimal supported version of glib is 2.22.
> > > Since testing is done with a glib that claims to be 2.22, but in fact
> > > has APIs from newer version of glib, this bug was not caught during
> > > submit of the patch referenced below.
> > >
> > > Replace g_realloc_n, which is available only since 2.24, with g_renew.
> > >
> > > Fixes commit 418026ca43 ("util: Introduce vfio helpers")
> > >
> > > Signed-off-by: Olaf Hering
> > > ---
> > > This must go into stable-2.12.
> >
> > In that case please CC: qemu-sta...@nongnu.org (done now).
> >
> > Reviewed-by: Thomas Huth
> >
> > > util/vfio-helpers.c | 6 ++
> > > 1 file changed, 2 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/util/vfio-helpers.c b/util/vfio-helpers.c
> > > index 006674c916..1d9272efa4 100644
> > > --- a/util/vfio-helpers.c
> > > +++ b/util/vfio-helpers.c
> > > @@ -522,8 +522,7 @@ static IOVAMapping
> > > *qemu_vfio_add_mapping(QEMUVFIOState *s,
> > >
> > > assert(index >= 0);
> > > s->nr_mappings++;
> > > -s->mappings = g_realloc_n(s->mappings, sizeof(s->mappings[0]),
> > > - s->nr_mappings);
> > > +s->mappings = g_renew(IOVAMapping, s->mappings, s->nr_mappings);
> > > insert = >mappings[index];
> > > shift = s->nr_mappings - index - 1;
> > > if (shift) {
> > > @@ -577,8 +576,7 @@ static void qemu_vfio_undo_mapping(QEMUVFIOState *s,
> > > IOVAMapping *mapping,
> > > memmove(mapping, >mappings[index + 1],
> > > sizeof(s->mappings[0]) * (s->nr_mappings - index - 1));
> > > s->nr_mappings--;
> > > -s->mappings = g_realloc_n(s->mappings, sizeof(s->mappings[0]),
> > > - s->nr_mappings);
> > > +s->mappings = g_renew(IOVAMapping, s->mappings, s->nr_mappings);
> > > }
> > >
> > > /* Check if the mapping list is (ascending) ordered. */
> > >
>
> This looks fine to me, so
>
> Reviewed-by: Cornelia Huck
>
> But this leads to another question: What do we do if we want a fix only
> in stable? Hypothetical scenario: Same parameters as for this patch
> (glib version bump, newer function sneaked in), but the older function
> that could be used in stable is clearly worse (IOW, we don't want it in
> the new version). Do we have a process to get a change only into stable?
>
I've answered in the form of a patch :)
"docs: add details regarding submitting stable-specific patches"
but here's a recent example:
https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg04999.html
[Qemu-devel] [PATCH] docs: add details regarding submitting stable-specific patches
Also add a few more details regarding normal master->stable patch flow. Cc: Cornelia Huck Signed-off-by: Michael Roth --- docs/devel/stable-process.rst | 15 +++ 1 file changed, 15 insertions(+) diff --git a/docs/devel/stable-process.rst b/docs/devel/stable-process.rst index 98736a9ea4..008fb4f9b4 100644 --- a/docs/devel/stable-process.rst +++ b/docs/devel/stable-process.rst @@ -56,6 +56,21 @@ There are various ways to get a patch into stable: appropriate other people (like the patch author or the relevant maintainer) on copy. +Generally patches for a stable release/branch must first be included in the +master QEMU branch, and from there the stable branch's maintainer will +cherry-pick/backport the patch. However, occasionally there is a need to +apply a stable-specific patch, such as a fix from master that isn't easily +cherry-picked and has been reworked/backported specifically for a stable +branch, or a fix that's only necessary in the context of a particular stable +release. In such cases, the patch can be submitted to qemu-devel@nongnu.org +using Cc: qemu-sta...@nongnu.org just like a normal stable patch, but tagged +with a "for-stable" or a "for-" in the subject line to +indicate that's it's specifically for a stable branch and not master. For +instance: + + [PATCH for-2.11.2] spapr: make pseries-2.11 the default machine type + + Stable release process -- -- 2.11.0
Re: [Qemu-devel] [Qemu-block] [PATCH] block/qcow2: fix logic around dirty_bitmaps_loaded
On 06/12/2018 06:11 PM, John Snow wrote:
>
>
> On 06/12/2018 01:26 PM, Vladimir Sementsov-Ogievskiy wrote:
>> First: this variable was introduced to handle reopens. We need it on
>> following qcow2_do_open, to don't try loading bitmaps again. So, we are
>> fixing qcow2_invalidate_cache().
>>
>> However, if we fix only qcow2_invalidate_cache, iotest 169 fails on
>> case test__persistent__not_migbitmap__online_shared, because on first
>> target open, source is not yet closed, and is not yet stored bitmaps,
>> so, we are load nothing. And on second open, dirty_bitmaps_loaded is
>> already true, but we have no bitmaps to reopen with
>> qcow2_reopen_bitmaps_rw_hint(). So, we are fixing qcow2_do_open() too.
>>
>> Signed-off-by: Vladimir Sementsov-Ogievskiy
>> ---
>> block/qcow2.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/block/qcow2.c b/block/qcow2.c
>> index 6fa5e1d71a..b4216a5830 100644
>> --- a/block/qcow2.c
>> +++ b/block/qcow2.c
>> @@ -1499,7 +1499,7 @@ static int coroutine_fn qcow2_do_open(BlockDriverState
>> *bs, QDict *options,
>> {
>> qcow2_reopen_bitmaps_rw_hint(bs, _updated, _err);
>> }
>> -} else {
>> +} else if (s->nb_bitmaps > 0) {
>> header_updated = qcow2_load_dirty_bitmaps(bs, _err);
>> s->dirty_bitmaps_loaded = true;
>> }
>> @@ -2178,6 +2178,7 @@ static void coroutine_fn
>> qcow2_co_invalidate_cache(BlockDriverState *bs,
>> QDict *options;
>> Error *local_err = NULL;
>> int ret;
>> +bool dirty_bitmaps_loaded = s->dirty_bitmaps_loaded;
>>
>> /*
>> * Backing files are read-only which makes all of their metadata
>> immutable,
>> @@ -2190,6 +2191,7 @@ static void coroutine_fn
>> qcow2_co_invalidate_cache(BlockDriverState *bs,
>> qcow2_close(bs);
>>
>> memset(s, 0, sizeof(BDRVQcow2State));
>> +s->dirty_bitmaps_loaded = dirty_bitmaps_loaded;
>> options = qdict_clone_shallow(bs->options);
>>
>> flags &= ~BDRV_O_INACTIVE;
>>
>
> Ah, tch... I didn't realize that invalidate completely wipes the qcow2
> metadata.
>
> I guess the other three fields, nb_bitmaps, bitmap_directory_size and
> bitmap_directory_offset get initialized again on re-open.
>
> (I suppose this means I need to rethink caching bm_list more carefully,
> too...)
>
> I think this looks correct mechanically.
>
Oh, I meant:
Reviewed-by: John Snow
Re: [Qemu-devel] [Qemu-block] [PATCH] block/qcow2: fix logic around dirty_bitmaps_loaded
On 06/12/2018 01:26 PM, Vladimir Sementsov-Ogievskiy wrote:
> First: this variable was introduced to handle reopens. We need it on
> following qcow2_do_open, to don't try loading bitmaps again. So, we are
> fixing qcow2_invalidate_cache().
>
> However, if we fix only qcow2_invalidate_cache, iotest 169 fails on
> case test__persistent__not_migbitmap__online_shared, because on first
> target open, source is not yet closed, and is not yet stored bitmaps,
> so, we are load nothing. And on second open, dirty_bitmaps_loaded is
> already true, but we have no bitmaps to reopen with
> qcow2_reopen_bitmaps_rw_hint(). So, we are fixing qcow2_do_open() too.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> block/qcow2.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/block/qcow2.c b/block/qcow2.c
> index 6fa5e1d71a..b4216a5830 100644
> --- a/block/qcow2.c
> +++ b/block/qcow2.c
> @@ -1499,7 +1499,7 @@ static int coroutine_fn qcow2_do_open(BlockDriverState
> *bs, QDict *options,
> {
> qcow2_reopen_bitmaps_rw_hint(bs, _updated, _err);
> }
> -} else {
> +} else if (s->nb_bitmaps > 0) {
> header_updated = qcow2_load_dirty_bitmaps(bs, _err);
> s->dirty_bitmaps_loaded = true;
> }
> @@ -2178,6 +2178,7 @@ static void coroutine_fn
> qcow2_co_invalidate_cache(BlockDriverState *bs,
> QDict *options;
> Error *local_err = NULL;
> int ret;
> +bool dirty_bitmaps_loaded = s->dirty_bitmaps_loaded;
>
> /*
> * Backing files are read-only which makes all of their metadata
> immutable,
> @@ -2190,6 +2191,7 @@ static void coroutine_fn
> qcow2_co_invalidate_cache(BlockDriverState *bs,
> qcow2_close(bs);
>
> memset(s, 0, sizeof(BDRVQcow2State));
> +s->dirty_bitmaps_loaded = dirty_bitmaps_loaded;
> options = qdict_clone_shallow(bs->options);
>
> flags &= ~BDRV_O_INACTIVE;
>
Ah, tch... I didn't realize that invalidate completely wipes the qcow2
metadata.
I guess the other three fields, nb_bitmaps, bitmap_directory_size and
bitmap_directory_offset get initialized again on re-open.
(I suppose this means I need to rethink caching bm_list more carefully,
too...)
I think this looks correct mechanically.
Re: [Qemu-devel] [PATCH 2/2] cputlb: Pass cpu_transaction_failed() the correct physaddr
On 06/11/2018 02:56 AM, Peter Maydell wrote: > The API for cpu_transaction_failed() says that it takes the physical > address for the failed transaction. However we were actually passing > it the offset within the target MemoryRegion. We don't currently > have any target CPU implementations of this hook that require the > physical address; fix this bug so we don't get confused if we ever > do add one. > > Suggested-by: Paolo Bonzini > Signed-off-by: Peter Maydell > --- > include/exec/exec-all.h | 13 ++-- > accel/tcg/cputlb.c | 44 + > exec.c | 5 +++-- > 3 files changed, 45 insertions(+), 17 deletions(-) Reviewed-by: Richard Henderson r~
Re: [Qemu-devel] [PATCH 1/2] cpu-defs.h: Document CPUIOTLBEntry 'addr' field
On 06/11/2018 02:56 AM, Peter Maydell wrote: > The 'addr' field in the CPUIOTLBEntry struct has a rather non-obvious > use; add a comment documenting it (reverse-engineered from what > the code that sets it is doing). > > Signed-off-by: Peter Maydell > --- > include/exec/cpu-defs.h | 9 + > accel/tcg/cputlb.c | 12 > 2 files changed, 21 insertions(+) Reviewed-by: Richard Henderson r~
[Qemu-devel] [Bug 1776478] Re: Getting qemu: uncaught target signal 6 when running lv2 plugin cross-compilation
my bad, the line should be : source ./common.sh not "source ./common" -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1776478 Title: Getting qemu: uncaught target signal 6 when running lv2 plugin cross- compilation Status in QEMU: New Bug description: Hey, I am part of the Zynthian team and we use qemu-arm-static to cross compile lv2 audio plugins. When running a compilation of DISTRHO-Ports we get: lv2_ttl_generator: pthread_mutex_lock.c:81: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed. qemu: uncaught target signal 6 (Aborted) - core dumped ./scripts/generate-ttl.sh: line 27: 16524 Aborted $GEN ./$FILE Makefile:62: recipe for target 'gen_lv2' failed make[1]: *** [gen_lv2] Error 134 make[1]: Leaving directory '/home/pi/zynthian-sw/plugins/DISTRHO-Ports' Makefile:104: recipe for target 'lv2' failed make: *** [lv2] Error 2 lv2_ttl_generator source is here: https://github.com/DISTRHO/DISTRHO-Ports/tree/master/libs/lv2-ttl-generator The command that is ruining is lv2_ttl_generator ./TAL-Filter-2.so And ./TAL-Filter-2.so source is here: https://github.com/DISTRHO/DISTRHO-Ports/tree/master/ports/tal-filter-2/source Is there a way to debug what is going on? This runs fine on a Raspberrypi which is armv7 A workaround would also help. Bug in Zynthian: https://github.com/zynthian/zynthian-sys/issues/59 Bug in DISTRHO-Ports: https://github.com/DISTRHO/DISTRHO-Ports/issues/29 Using qemu-arm-static version from master from two days ago: qemu-arm version 2.12.50 (v2.12.0-1182-ga7a7309ca5-dirty), commit: a7a7309ca52c327c6603d60db90ae4feeae719f7 Also saw this in qemu-arm version 2.12.0 (Debian 1:2.12+dfsg-3) Thanks, Guy To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1776478/+subscriptions
[Qemu-devel] [Bug 1776478] Re: Getting qemu: uncaught target signal 6 when running lv2 plugin cross-compilation
Hey, Not sure how to boil it down (yet). But this would reproduce it for you: cd /tmp wget https://downloads.raspberrypi.org/raspbian_lite/images/raspbian_lite-2018-04-19/2018-04-18-raspbian-stretch-lite.zip unzip 2018-04-18-raspbian-stretch-lite.zip wget https://raw.githubusercontent.com/guysoft/CustomPiOS/devel/src/common.sh source ./common mkdir ./mount mount_image ./2018-04-18-raspbian-stretch-lite.img 2 ./mount cd mount sudo bash -c "$(declare -f fixLd); fixLd" sudo cp $(which qemu-arm-static) ./usr/bin/ sudo chroot . apt-get update apt-get install -y git premake libfreetype6-dev libgl1-mesa-dev libx11-dev libasound2-dev git clone https://github.com/DISTRHO/DISTRHO-Ports.git --depth=1 cd DISTRHO-Ports/ export RASPPI=true export LINUX_EMBED=true ./scripts/premake-update.sh linux make lv2 -j4 once you have it all running you can just run again ./libs/lv2_ttl_generator ./bin/lv2/TAL-Filter-2.lv2/TAL-Filter-2.so -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1776478 Title: Getting qemu: uncaught target signal 6 when running lv2 plugin cross- compilation Status in QEMU: New Bug description: Hey, I am part of the Zynthian team and we use qemu-arm-static to cross compile lv2 audio plugins. When running a compilation of DISTRHO-Ports we get: lv2_ttl_generator: pthread_mutex_lock.c:81: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed. qemu: uncaught target signal 6 (Aborted) - core dumped ./scripts/generate-ttl.sh: line 27: 16524 Aborted $GEN ./$FILE Makefile:62: recipe for target 'gen_lv2' failed make[1]: *** [gen_lv2] Error 134 make[1]: Leaving directory '/home/pi/zynthian-sw/plugins/DISTRHO-Ports' Makefile:104: recipe for target 'lv2' failed make: *** [lv2] Error 2 lv2_ttl_generator source is here: https://github.com/DISTRHO/DISTRHO-Ports/tree/master/libs/lv2-ttl-generator The command that is ruining is lv2_ttl_generator ./TAL-Filter-2.so And ./TAL-Filter-2.so source is here: https://github.com/DISTRHO/DISTRHO-Ports/tree/master/ports/tal-filter-2/source Is there a way to debug what is going on? This runs fine on a Raspberrypi which is armv7 A workaround would also help. Bug in Zynthian: https://github.com/zynthian/zynthian-sys/issues/59 Bug in DISTRHO-Ports: https://github.com/DISTRHO/DISTRHO-Ports/issues/29 Using qemu-arm-static version from master from two days ago: qemu-arm version 2.12.50 (v2.12.0-1182-ga7a7309ca5-dirty), commit: a7a7309ca52c327c6603d60db90ae4feeae719f7 Also saw this in qemu-arm version 2.12.0 (Debian 1:2.12+dfsg-3) Thanks, Guy To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1776478/+subscriptions
Re: [Qemu-devel] [PATCH v4 11/40] hw/xen: Use the IEC binary prefix definitions
On 06/12/2018 11:04 AM, Eric Blake wrote: > On 06/12/2018 03:51 PM, Richard Henderson wrote: >> On 06/10/2018 03:14 PM, Philippe Mathieu-Daudé wrote: >>> xen_pv_printf(xendev, 1, "type \"%s\", fileproto \"%s\", filename >>> \"%s\"," >>> - " size %" PRId64 " (%" PRId64 " MB)\n", >>> + " size %" PRId64 " (%llu MB)\n", >>> blkdev->type, blkdev->fileproto, blkdev->filename, >>> - blkdev->file_size, blkdev->file_size >> 20); >>> + blkdev->file_size, blkdev->file_size / MiB); >> >> Having to change printf markup is exactly why you shouldn't use ULL in MiB. > > Conversely, M_BYTE was already ULL, so if you don't use it in MiB, you'll have > to change other printf markup where you were changing those uses. > > One benefit of using the widest possible type: we avoid risk of silent > truncation. Potential downsides: wasted processing time (when 32 bits was > sufficient), and compilers might start warning when we narrow a 64-bit value > into a 32-bit variable (but I think we already ignore that). > > One benefit of using the natural type that holds the value: use of 64-bit math > is explicit based on the type of what else is being multiplied by the macro. > Potential downside: 32*32 assigned to a 64-bit result may be botched (but > hopefully Coverity will flag it). > > So there's tradeoffs either way, and you at least need to document in your > commit messages what auditing you have done that any type changes introduced > by > your changes are safe. I'm more concerned about unnecessary or unintended signed vs unsigned changes than I am about width. But if we're going to force a 64-bit type, use (int64_t)1 not 1LL. That way the type will match the existing PRId64 printf markup. r~
Re: [Qemu-devel] [PATCH 1/3] bswap: Add new stn_*_p() and ldn_*_p() memory access functions
On 06/11/2018 07:52 AM, Peter Maydell wrote: > On 11 June 2018 at 18:10, Peter Maydell wrote: >> There's a common pattern in QEMU where a function needs to perform >> a data load or store of an N byte integer in a particular endianness. >> At the moment this is handled by doing a switch() on the size and >> calling the appropriate ld*_p or st*_p function for each size. >> >> Provide a new family of functions ldn_*_p() and stn_*_p() which >> take the size as an argument and do the switch() themselves. >> >> Signed-off-by: Peter Maydell >> --- >> include/exec/cpu-all.h | 4 +++ >> include/qemu/bswap.h| 52 + >> docs/devel/loads-stores.rst | 15 +++ >> 3 files changed, 71 insertions(+) >> >> diff --git a/include/exec/cpu-all.h b/include/exec/cpu-all.h >> index a635f532f97..07ec3808342 100644 >> --- a/include/exec/cpu-all.h >> +++ b/include/exec/cpu-all.h >> @@ -133,6 +133,8 @@ static inline void tswap64s(uint64_t *s) >> #define stq_p(p, v) stq_be_p(p, v) >> #define stfl_p(p, v) stfl_be_p(p, v) >> #define stfq_p(p, v) stfq_be_p(p, v) >> +#define ldn_p(p, sz ldn_be_p(p, sz) > > Silly typo here -- missing ')'. Reviewed-by: Richard Henderson r~
Re: [Qemu-devel] [PATCH v4 11/40] hw/xen: Use the IEC binary prefix definitions
On 06/12/2018 03:51 PM, Richard Henderson wrote: On 06/10/2018 03:14 PM, Philippe Mathieu-Daudé wrote: xen_pv_printf(xendev, 1, "type \"%s\", fileproto \"%s\", filename \"%s\"," - " size %" PRId64 " (%" PRId64 " MB)\n", + " size %" PRId64 " (%llu MB)\n", blkdev->type, blkdev->fileproto, blkdev->filename, - blkdev->file_size, blkdev->file_size >> 20); + blkdev->file_size, blkdev->file_size / MiB); Having to change printf markup is exactly why you shouldn't use ULL in MiB. Conversely, M_BYTE was already ULL, so if you don't use it in MiB, you'll have to change other printf markup where you were changing those uses. One benefit of using the widest possible type: we avoid risk of silent truncation. Potential downsides: wasted processing time (when 32 bits was sufficient), and compilers might start warning when we narrow a 64-bit value into a 32-bit variable (but I think we already ignore that). One benefit of using the natural type that holds the value: use of 64-bit math is explicit based on the type of what else is being multiplied by the macro. Potential downside: 32*32 assigned to a 64-bit result may be botched (but hopefully Coverity will flag it). So there's tradeoffs either way, and you at least need to document in your commit messages what auditing you have done that any type changes introduced by your changes are safe. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Re: [Qemu-devel] [PATCH 3/3] exec.c: Use stn_p() and ldn_p() instead of explicit switches
On 06/11/2018 07:10 AM, Peter Maydell wrote: > Now we have stn_p() and ldn_p() we can use them in various > functions in exec.c that used to have their own switch-on-size code. > > Signed-off-by: Peter Maydell > --- Reviewed-by: Richard Henderson r~
Re: [Qemu-devel] [PATCH 2/3] exec.c: Don't accidentally sign-extend 4-byte loads in subpage_read()
On 06/11/2018 07:10 AM, Peter Maydell wrote: > In subpage_read() we perform a load of the data into a local buffer > which we then access using ldub_p(), lduw_p(), ldl_p() or ldq_p() > depending on its size, storing the result into the uint64_t *data. > Since ldl_p() returns an 'int', this means that for the 4-byte > case we will sign-extend the data, whereas for 1 and 2 byte > reads we zero-extend it. > > This ought not to matter since the caller will likely ignore values in > the high bytes of the data, but add a cast so that we're consistent. > > Signed-off-by: Peter Maydell > --- Reviewed-by: Richard Henderson r~
Re: [Qemu-devel] [PATCH v4 11/40] hw/xen: Use the IEC binary prefix definitions
On 06/10/2018 03:14 PM, Philippe Mathieu-Daudé wrote: > xen_pv_printf(xendev, 1, "type \"%s\", fileproto \"%s\", filename > \"%s\"," > - " size %" PRId64 " (%" PRId64 " MB)\n", > + " size %" PRId64 " (%llu MB)\n", >blkdev->type, blkdev->fileproto, blkdev->filename, > - blkdev->file_size, blkdev->file_size >> 20); > + blkdev->file_size, blkdev->file_size / MiB); Having to change printf markup is exactly why you shouldn't use ULL in MiB. r~
[Qemu-devel] [PATCH] target/arm: Allow ARMv6-M Thumb2 instructions
ARMv6-M supports 6 Thumb2 instructions. This patch checks for these
instructions and allows their execution.
Like Thumb2 cores, ARMv6-M always interprets BL instruction as 32-bit.
This patch is required for future Cortex-M0 support.
Signed-off-by: Julia Suvorova
---
target/arm/translate.c | 35 ++-
1 file changed, 30 insertions(+), 5 deletions(-)
diff --git a/target/arm/translate.c b/target/arm/translate.c
index 0ff5edf2ce..8cae3f5ed0 100644
--- a/target/arm/translate.c
+++ b/target/arm/translate.c
@@ -9965,7 +9965,8 @@ static bool thumb_insn_is_16bit(DisasContext *s, uint32_t
insn)
* end up actually treating this as two 16-bit insns, though,
* if it's half of a bl/blx pair that might span a page boundary.
*/
-if (arm_dc_feature(s, ARM_FEATURE_THUMB2)) {
+if (arm_dc_feature(s, ARM_FEATURE_THUMB2) ||
+arm_dc_feature(s, ARM_FEATURE_M)) {
/* Thumb2 cores (including all M profile ones) always treat
* 32-bit insns as 32-bit.
*/
@@ -10075,6 +10076,11 @@ static void disas_thumb2_insn(DisasContext *s,
uint32_t insn)
{
uint32_t imm, shift, offset;
uint32_t rd, rn, rm, rs;
+uint32_t armv6m_insn[] = {0xf3808000 /* msr */, 0xf3b08040 /* dsb */,
+ 0xf3b08050 /* dmb */, 0xf3b08060 /* isb */,
+ 0xf3e08000 /* mrs */, 0xf000d000 /* bl */};
+uint32_t armv6m_mask[] = {0xffe0d000, 0xfff0d0f0, 0xfff0d0f0,
+ 0xfff0d0f0, 0xffe0d000, 0xf800d000};
TCGv_i32 tmp;
TCGv_i32 tmp2;
TCGv_i32 tmp3;
@@ -10085,10 +10091,25 @@ static void disas_thumb2_insn(DisasContext *s,
uint32_t insn)
int conds;
int logic_cc;
-/* The only 32 bit insn that's allowed for Thumb1 is the combined
- * BL/BLX prefix and suffix.
+/*
+ * ARMv6-M supports a limited subset of Thumb2 instructions.
+ * Other Thumb1 architectures allow only 32-bit
+ * combined BL/BLX prefix and suffix.
*/
-if ((insn & 0xf800e800) != 0xf000e800) {
+if (arm_dc_feature(s, ARM_FEATURE_M) && arm_dc_feature(s, ARM_FEATURE_V6))
{
+int i;
+bool found = false;
+
+for (i = 0; i < ARRAY_SIZE(armv6m_insn); i++) {
+if ((insn & armv6m_mask[i]) == armv6m_insn[i]) {
+found = true;
+break;
+}
+}
+if (!found) {
+goto illegal_op;
+}
+} else if ((insn & 0xf800e800) != 0xf000e800) {
ARCH(6T2);
}
@@ -11009,7 +11030,11 @@ static void disas_thumb2_insn(DisasContext *s,
uint32_t insn)
}
break;
case 3: /* Special control operations. */
-ARCH(7);
+if (!arm_dc_feature(s, ARM_FEATURE_V7) &&
+!(arm_dc_feature(s, ARM_FEATURE_V6) &&
+ arm_dc_feature(s, ARM_FEATURE_M))) {
+goto illegal_op;
+}
op = (insn >> 4) & 0xf;
switch (op) {
case 2: /* clrex */
--
2.17.0
