Am 29.04.25 um 16:09 schrieb Matthew Rosato:
On 4/29/25 3:45 AM, Christian Borntraeger wrote:
Am 29.04.25 um 09:37 schrieb David Hildenbrand:
[...]
The only problem I see is with vfio devices is the new "memory pinned" mode. [1]
There, we'd have to check if any such d
Am 29.04.25 um 09:37 schrieb David Hildenbrand:
[...]
The only problem I see is with vfio devices is the new "memory pinned" mode. [1]
There, we'd have to check if any such device is around (discarding of ram is
disabled?), and fallback to actual zeroing of memory.
CC Matt to double check.
###
KVM Forum 2025
September 4-5, 2025
Milan, Italy
###
On behalf of the program committee for the KVM Forum, I am pleased to announce
KVM Forum 2025, September 4-5 2025 in Milan Italy.
The call for papers will follow, but we want to give you the opportunity
to pre
iewed, but
Acked-by: Christian Borntraeger
for the series.
version 2.8. (This also helps to get rid of the problem that has been
described in: https://gitlab.com/qemu-project/qemu/-/issues/2213 )
Thomas Huth (10):
hw/s390x/s390-virtio-ccw: Remove the deprecated 2.4 and 2.5 machine
types
Am 19.12.24 um 12:18 schrieb David Hildenbrand:
The following on top seems to make everything happy. I wish the
CONFIG_S390_CCW_VIRTIO stuff would't have to be so complicated, just to
handle odd configs that don't really make sense.
WOuld it be possible to rid of this config?
Am 16.12.24 um 22:18 schrieb David Hildenbrand:
Thanks, queued to
https://github.com/davidhildenbrand/qemu.git mem-next
On 13.12.24 15:26, David Hildenbrand wrote:
On 13.12.24 13:35, Thomas Huth wrote:
On 12/12/2024 22.52, David Hildenbrand wrote:
On 13.11.24 15:46, David Hildenbrand wrote:
Am 18.11.24 um 16:53 schrieb Jared Rossi:
Loadparm set with boot index works properly and I confirmed the getter/setter
are working as well.
So this is a Tested-by: then?
On 11/18/24 10:29 AM, Jared Rossi wrote:
Looks OK to me.
Reviewed-by Jared Rossi
On 11/15/24 9:12 AM, Thomas Huth wro
Am 12.11.24 um 16:54 schrieb Hendrik Brueckner:
MSA10 introduces new AES XTS subfunctions.
Signed-off-by: Hendrik Brueckner
Reviewed-by: Christian Borntraeger
---
target/s390x/cpu_features.c | 2 ++
target/s390x/cpu_features_def.h.inc | 6 ++
target/s390x/cpu_models.c
Am 12.11.24 um 16:54 schrieb Hendrik Brueckner:
MSA12 changes the KIMD/KLMD instruction format for SHA3/SHAKE.
Signed-off-by: Hendrik Brueckner
Reviewed-by: Christian Borntraeger
---
target/s390x/cpu_features_def.h.inc | 1 +
target/s390x/gen-features.c | 8
2 files
Am 12.11.24 um 16:54 schrieb Hendrik Brueckner:
MSA11 introduces new HMAC subfunctions.
Signed-off-by: Hendrik Brueckner
Reviewed-by: Christian Borntraeger
---
target/s390x/cpu_features.c | 2 ++
target/s390x/cpu_features_def.h.inc | 10 ++
target/s390x/cpu_models.c
Am 01.10.24 um 15:31 schrieb Halil Pasic:
On Tue, 1 Oct 2024 11:15:02 +0200
Christian Borntraeger wrote:
[..]
So 500+4 should probably not cause any harm apart from branch prediction
going wrong the first 2 or 3 notifies.
502 will make kvm_s390_handle_diag larger.
What do you mean by
Am 30.09.24 um 14:57 schrieb Halil Pasic:
On Mon, 30 Sep 2024 13:11:31 +0200
Christian Borntraeger wrote:
We do have kvm_stat counters for 500, not sure if people debugging virtio
will care.
Could end up being confusing, as currently we can assume each and every
DIAG 500 is a virtio
Am 24.09.24 um 22:17 schrieb David Hildenbrand:
On 24.09.24 18:22, Nina Schoetterl-Glausch wrote:
On Tue, 2024-09-10 at 19:58 +0200, David Hildenbrand wrote:
We actually want to check the available RAM, not the maximum RAM size.
Signed-off-by: David Hildenbrand
Reviewed-by: Nina Schoetterl-
Am 27.09.24 um 20:05 schrieb Halil Pasic:
On Thu, 12 Sep 2024 10:19:00 +0200
Thomas Huth wrote:
diff --git a/hw/s390x/s390-hypercall.h b/hw/s390x/s390-hypercall.h
index b7ac29f444..f0ca62bcbb 100644
--- a/hw/s390x/s390-hypercall.h
+++ b/hw/s390x/s390-hypercall.h
@@ -18,6 +18,7 @@
#define DI
Am 13.08.24 um 18:52 schrieb Peter Maydell:
The main aim of this patchseries is to remove the two remaining uses
of device_class_set_parent_reset() in the tree, which are virtio-ccw
and the s390 CPU class. Doing that lets us do some followup cleanup.
(The diffstat looks alarming but is almost all
[...]
docs/system/s390x/bootdevices.rst | 20 +++
pc-bios/s390-ccw/netboot.mak | 62 -
hw/s390x/ipl.h| 12 ++--
pc-bios/s390-ccw/cio.h| 2 +
pc-bios/s390-ccw/iplb.h | 4 +-
pc-bios/s390-ccw/libc.h | 89
Am 05.06.24 um 15:37 schrieb Thomas Huth:
On 29/05/2024 17.43, jro...@linux.ibm.com wrote:
From: Jared Rossi
On a panic during IPL (i.e. a device failed to boot) check for another device
to boot from, as indicated by the presence of an unused IPLB.
If an IPLB is successfully loaded, then j
Am 14.06.24 um 09:15 schrieb Thomas Huth:
On 14/06/2024 08.07, Christian Borntraeger wrote:
Am 13.06.24 um 19:07 schrieb Thomas Huth:
Old CPU models are not officially supported anymore by IBM, and for
downstream builds of QEMU, we would like to be able to disable these
CPUs in the build
Am 13.06.24 um 19:07 schrieb Thomas Huth:
Old CPU models are not officially supported anymore by IBM, and for
downstream builds of QEMU, we would like to be able to disable these
CPUs in the build. Thus add a CONFIG switch that can be used to
disable these CPUs (and old machine types that use
ror message is helpful.
Acked-by: Christian Borntraeger
---
target/s390x/cpu_models.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
index 1a1c096122..0d6d8fc727 100644
--- a/target/s390x/cpu_models.c
+
Am 06.02.24 um 22:24 schrieb Peter Maydell:
[..]
Christian: this is on the s390x machine we have. Does the
VM setup for that share IO or CPU with other VMs somehow?
Yes it does, this is a shared system. I will talk to the team if there is
anything that we can do about this.
Am 11.01.24 um 10:43 schrieb Cédric Le Goater:
[...]
On a side note, I am also seeing :
Michael?
[ 73.989688] [ cut here ]
[ 73.989696] unexpected non zero alert.mask 0x20
[ 73.989748] WARNING: CPU: 9 PID: 4503 at arch/s390/kvm/interrupt.c:3214
kvm_s390_gi
Am 12.12.23 um 16:28 schrieb Eric Farman:
So why do you think exec-all.h is unused?
I think because that got moved out of exec-all.h a few months ago, via
commit 3549118b498873c84b442bc280a5edafbb61e0a4
Author: Philippe Mathieu-Daudé
Date: Thu Sep 14 20:57:08 2023 +0200
exec: Move c
Am 12.12.23 um 12:36 schrieb Philippe Mathieu-Daudé:
Signed-off-by: Philippe Mathieu-Daudé
---
hw/s390x/ipl.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/hw/s390x/ipl.c b/hw/s390x/ipl.c
index 515dcf51b5..62182d81a0 100644
--- a/hw/s390x/ipl.c
+++ b/hw/s390x/ipl.c
@@ -35,7 +35,6 @@
Am 20.10.23 um 11:07 schrieb Juan Quintela:
Just with make check I can see that we can have more than one of this
devices, so use ANY.
ok 5 /s390x/device/introspect/abstract-interfaces
...
Broken pipe
../../../../../mnt/code/qemu/full/tests/qtest/libqtest.c:195: kill_qemu() tried
to terminate Q
Am 09.10.23 um 19:07 schrieb Thomas Huth:
[...]
@@ -483,20 +482,14 @@ int kvm_arch_put_registers(CPUState *cs, int level)
cs->kvm_run->psw_addr = env->psw.addr;
cs->kvm_run->psw_mask = env->psw.mask;
-if (can_sync_regs(cs, KVM_SYNC_GPRS)) {
-for (i = 0; i < 16; i++
Am 10.10.23 um 13:12 schrieb Thomas Huth:
On 10/10/2023 13.02, Christian Borntraeger wrote:
Am 09.10.23 um 19:07 schrieb Thomas Huth:
Since we already require at least kernel 3.15 in the s390x KVM code,
we can assume that the KVM_CAP_SYNC_REGS capability is always there.
Thus turn this
error_report("KVM is missing capability KVM_CAP_S390_COW - "
"unsupported environment");
return -1;
}
Not sure if we also want to move KVM_CAP_S390_COW somehow. The message would be
different.
Aparch from that:
Reviewed-by: Christi
do a full device_reset() afterwards which will
reset some devices twice. That's ok since we can't move the
device_reset() before the unprotect as it includes a CPU clear reset
which the Ultravisor does not expect at that point in time.
Signed-off-by: Janosch Frank
Makes sense.
Am 25.07.23 um 18:45 schrieb Peter Maydell:
There seems to be an intermittent failure on the s390 host in
the qemu:block / io-qcow2-copy-before-write test:
https://gitlab.com/qemu-project/qemu/-/jobs/4737819873
The log says the test was expecting to do some reading
and writing but got an unex
Am 28.06.23 um 10:32 schrieb Thomas Huth:
On 27/06/2023 14.19, Christian Borntraeger wrote:
Am 27.06.23 um 13:41 schrieb Thomas Huth:
Using types starting with double underscores should be avoided since these
names are marked as reserved by the C standard. The corresponding Linux
In
Am 27.06.23 um 13:41 schrieb Thomas Huth:
Using types starting with double underscores should be avoided since these
names are marked as reserved by the C standard. The corresponding Linux
In general I think this change is fine, but this is kind of interesting, as
/usr/include/linux/types.h
:
.quad 0x00018000
+
+.bss
+
+.align 16
+.lcomm stack,STACK_SIZE
IIRC, the ELF ABI defines the stack to be 8 byte aligned, but 16 certainly does
not hurt.
Acked-by: Christian Borntraeger
stack */
Reviewed-by: Christian Borntraeger
pie -nostdlib -z noexecstack
build-all: s390-ccw.img s390-netboot.img
In the end this should not matter as the resulting binary is not loaded by an
elf loader so this should be fine
Acked-by: Christian Borntraeger
Am 06.04.23 um 14:39 schrieb Peter Maydell:
On Thu, 6 Apr 2023 at 13:30, Thomas Huth wrote:
The thing is: it shouldn't take that long to build QEMU and run the tests
here, theoretically. Some days ago, the job was finishing in 39 minutes:
https://gitlab.com/qemu-project/qemu/-/jobs/39734
Am 06.04.23 um 14:39 schrieb Peter Maydell:
On Thu, 6 Apr 2023 at 13:30, Thomas Huth wrote:
The thing is: it shouldn't take that long to build QEMU and run the tests
here, theoretically. Some days ago, the job was finishing in 39 minutes:
https://gitlab.com/qemu-project/qemu/-/jobs/39734
Am 06.04.23 um 14:30 schrieb Thomas Huth:
On 06/04/2023 14.13, Christian Borntraeger wrote:
Am 06.04.23 um 14:05 schrieb Peter Maydell:
On Thu, 6 Apr 2023 at 12:17, Christian Borntraeger
wrote:
Am 06.04.23 um 12:44 schrieb Peter Maydell:
On Thu, 6 Apr 2023 at 11:40, Christian
Am 06.04.23 um 14:05 schrieb Peter Maydell:
On Thu, 6 Apr 2023 at 12:17, Christian Borntraeger
wrote:
Am 06.04.23 um 12:44 schrieb Peter Maydell:
On Thu, 6 Apr 2023 at 11:40, Christian Borntraeger
wrote:
Am 06.04.23 um 11:21 schrieb Peter Maydell:
Christian, does our S390X machine get
Am 06.04.23 um 12:44 schrieb Peter Maydell:
On Thu, 6 Apr 2023 at 11:40, Christian Borntraeger
wrote:
Am 06.04.23 um 11:21 schrieb Peter Maydell:
Christian, does our S390X machine get a guaranteed amount of CPU,
or does it depend on what else is running on the hardware?
I think its a shared
Am 06.04.23 um 11:21 schrieb Peter Maydell:
On Thu, 6 Apr 2023 at 07:57, Thomas Huth wrote:
On 05/04/2023 17.15, Peter Maydell wrote:
The s390 private runner CI job ubuntu-20.04-s390x-all seems to have
started timing out a lot recently. Here's an example where it passed,
but with only 53 s
Am 13.03.23 um 22:16 schrieb Ilya Leoshkevich:
TCG emulates ckc, cputm, last_break and prefix, and it's quite useful
to have them during debugging.
KVM provides those as well so I dont get what you are trying to do here. (I
would understand moving out the pfault things into a KVM section)
Am 10.01.23 um 16:13 schrieb Peter Maydell:
Meson supports an "uninstall", so we can easily allow it to work by
not suppressing the forwarding of it from Make to meson.
We originally suppressed this because Meson's 'uninstall' has a hole
in it: it will remove everything that is installed by a me
Am 13.12.22 um 14:50 schrieb Christian Borntraeger:
Am 12.12.22 um 11:01 schrieb Pierre Morel:
On 12/9/22 15:45, Cédric Le Goater wrote:
On 12/8/22 10:44, Pierre Morel wrote:
Hi,
Implementation discussions
==
CPU models
--
Since the
Am 13.12.22 um 14:57 schrieb Janis Schoetterl-Glausch:
On Tue, 2022-12-13 at 14:41 +0100, Christian Borntraeger wrote:
Am 12.12.22 um 11:17 schrieb Thomas Huth:
On 12/12/2022 11.10, Pierre Morel wrote:
On 12/12/22 10:07, Thomas Huth wrote:
On 12/12/2022 09.51, Pierre Morel wrote:
On
Am 12.12.22 um 11:01 schrieb Pierre Morel:
On 12/9/22 15:45, Cédric Le Goater wrote:
On 12/8/22 10:44, Pierre Morel wrote:
Hi,
Implementation discussions
==
CPU models
--
Since the S390_FEAT_CONFIGURATION_TOPOLOGY is already in the CPU model
for old QEMU
Am 12.12.22 um 11:17 schrieb Thomas Huth:
On 12/12/2022 11.10, Pierre Morel wrote:
On 12/12/22 10:07, Thomas Huth wrote:
On 12/12/2022 09.51, Pierre Morel wrote:
On 12/9/22 14:32, Thomas Huth wrote:
On 08/12/2022 10.44, Pierre Morel wrote:
Hi,
Implementation discussions
=
Am 08.12.22 um 10:44 schrieb Pierre Morel:
The migration can only take place if both source and destination
of the migration both use or both do not use the CPU topology
facility.
We indicate a change in topology during migration postload for the
case the topology changed between source and dest
Am 07.12.22 um 14:14 schrieb Christian Borntraeger:
Without a kernel or boot disk a QEMU on s390 will exit (usually with a
disabled wait state). This breaks the stream-under-throttle test case.
Do not exit qemu if on s390.
Signed-off-by: Christian Borntraeger
---
tests/qemu-iotests/tests
Am 07.12.22 um 21:40 schrieb Ilya Leoshkevich:
On Wed, 2022-12-07 at 08:55 -0600, Richard Henderson wrote:
On 12/7/22 01:45, Thomas Huth wrote:
On 06/12/2022 23.22, Richard Henderson wrote:
On 12/6/22 13:29, Ilya Leoshkevich wrote:
This change doesn't seem to affect that, but what is the
m
Am 07.12.22 um 14:23 schrieb Thomas Huth:
On 07/12/2022 14.14, Christian Borntraeger wrote:
Without a kernel or boot disk a QEMU on s390 will exit (usually with a
disabled wait state). This breaks the stream-under-throttle test case.
Do not exit qemu if on s390.
Signed-off-by: Christian
Without a kernel or boot disk a QEMU on s390 will exit (usually with a
disabled wait state). This breaks the stream-under-throttle test case.
Do not exit qemu if on s390.
Signed-off-by: Christian Borntraeger
---
tests/qemu-iotests/tests/stream-under-throttle | 2 ++
1 file changed, 2 insertions
Am 07.12.22 um 13:56 schrieb Christian Borntraeger:
Am 07.12.22 um 11:31 schrieb Christian Borntraeger:
Am 14.11.22 um 10:52 schrieb Hanna Reitz:
Test streaming a base image into the top image underneath two throttle
nodes. This was reported to make qemu 7.1 hang
(https://gitlab.com/qemu
Am 07.12.22 um 11:31 schrieb Christian Borntraeger:
Am 14.11.22 um 10:52 schrieb Hanna Reitz:
Test streaming a base image into the top image underneath two throttle
nodes. This was reported to make qemu 7.1 hang
(https://gitlab.com/qemu-project/qemu/-/issues/1215), so this serves as
a
Am 14.11.22 um 10:52 schrieb Hanna Reitz:
Test streaming a base image into the top image underneath two throttle
nodes. This was reported to make qemu 7.1 hang
(https://gitlab.com/qemu-project/qemu/-/issues/1215), so this serves as
a regression test.
Signed-off-by: Hanna Reitz
---
Based-on: <2
Am 27.10.22 um 07:54 schrieb Christian Borntraeger:
[...]
diff --git a/tests/qemu-iotests/common.qemu b/tests/qemu-iotests/common.qemu
index 0f1fecc68e..01bdb05575 100644
--- a/tests/qemu-iotests/common.qemu
+++ b/tests/qemu-iotests/common.qemu
@@ -388,7 +388,7 @@ _cleanup_qemu
Am 29.11.22 um 10:42 schrieb Dr. David Alan Gilbert:
* Marc Hartmayer (mhart...@linux.ibm.com) wrote:
"Dr. David Alan Gilbert" writes:
* Marc Hartmayer (mhart...@linux.ibm.com) wrote:
The virtiofsd currently crashes on s390x. This is because of a
`sigreturn` system call. See audit log bel
Am 29.11.22 um 10:52 schrieb Christian Borntraeger:
Am 29.11.22 um 10:42 schrieb Dr. David Alan Gilbert:
* Marc Hartmayer (mhart...@linux.ibm.com) wrote:
"Dr. David Alan Gilbert" writes:
* Marc Hartmayer (mhart...@linux.ibm.com) wrote:
The virtiofsd currently crashes on s390
Am 25.11.22 um 17:32 schrieb German Maglione:
On Fri, Nov 25, 2022 at 3:40 PM Marc Hartmayer wrote:
The virtiofsd currently crashes on s390x. This is because of a
`sigreturn` system call. See audit log below:
type=SECCOMP msg=audit(1669382477.611:459): auid=4294967295 uid=0 gid=0 ses=429496
Am 21.11.22 um 23:37 schrieb Michael S. Tsirkin:
[...]
qemu-system-x86_64: ../hw/virtio/vhost-vsock-common.c:203:
vhost_vsock_common_pre_save: Assertion `!vhost_dev_is_started(&vvc->vhost_dev)'
failed.
2022-11-15 16:38:46.096+: shutting down, reason=crashed
Alex were you able to replicate
Am 02.09.22 um 09:55 schrieb Pierre Morel:
Hi,
The implementation of the CPU Topology in QEMU has been drastically
modified since the last patch series and the number of LOCs has been
greatly reduced.
Unnecessary objects have been removed, only a single S390Topology object
is created to support
Am 15.11.22 um 17:40 schrieb Christian Borntraeger:
Am 15.11.22 um 17:05 schrieb Alex Bennée:
Christian Borntraeger writes:
Am 15.11.22 um 15:31 schrieb Alex Bennée:
"Michael S. Tsirkin" writes:
On Mon, Nov 14, 2022 at 06:15:30PM +0100, Christian Borntraeger wrote:
A
Am 15.11.22 um 17:05 schrieb Alex Bennée:
Christian Borntraeger writes:
Am 15.11.22 um 15:31 schrieb Alex Bennée:
"Michael S. Tsirkin" writes:
On Mon, Nov 14, 2022 at 06:15:30PM +0100, Christian Borntraeger wrote:
Am 14.11.22 um 18:10 schrieb Michael S. Tsirkin:
On M
Am 15.11.22 um 15:31 schrieb Alex Bennée:
"Michael S. Tsirkin" writes:
On Mon, Nov 14, 2022 at 06:15:30PM +0100, Christian Borntraeger wrote:
Am 14.11.22 um 18:10 schrieb Michael S. Tsirkin:
On Mon, Nov 14, 2022 at 05:55:09PM +0100, Christian Borntraeger wrote:
Am 14.11.2
Am 15.11.22 um 12:25 schrieb Michael S. Tsirkin:
On Tue, Nov 15, 2022 at 09:18:27AM +0100, Christian Borntraeger wrote:
Am 14.11.22 um 18:20 schrieb Michael S. Tsirkin:
On Mon, Nov 14, 2022 at 06:15:30PM +0100, Christian Borntraeger wrote:
Am 14.11.22 um 18:10 schrieb Michael S. Tsirkin
Am 14.11.22 um 18:20 schrieb Michael S. Tsirkin:
On Mon, Nov 14, 2022 at 06:15:30PM +0100, Christian Borntraeger wrote:
Am 14.11.22 um 18:10 schrieb Michael S. Tsirkin:
On Mon, Nov 14, 2022 at 05:55:09PM +0100, Christian Borntraeger wrote:
Am 14.11.22 um 17:37 schrieb Michael S. Tsirkin
Am 14.11.22 um 18:20 schrieb Michael S. Tsirkin:
[...]
This does not seem to fix the regression that I have reported.
This was applied on top of 9f6bcfd99f which IIUC does, right?
Just dobble checked,
9f6bcfd99f was the patch that created the original problem, no?
Am 14.11.22 um 18:10 schrieb Michael S. Tsirkin:
On Mon, Nov 14, 2022 at 05:55:09PM +0100, Christian Borntraeger wrote:
Am 14.11.22 um 17:37 schrieb Michael S. Tsirkin:
On Mon, Nov 14, 2022 at 05:18:53PM +0100, Christian Borntraeger wrote:
Am 08.11.22 um 10:23 schrieb Alex Bennée:
The
Am 14.11.22 um 17:37 schrieb Michael S. Tsirkin:
On Mon, Nov 14, 2022 at 05:18:53PM +0100, Christian Borntraeger wrote:
Am 08.11.22 um 10:23 schrieb Alex Bennée:
The previous fix to virtio_device_started revealed a problem in its
use by both the core and the device code. The core code
Am 08.11.22 um 10:23 schrieb Alex Bennée:
The previous fix to virtio_device_started revealed a problem in its
use by both the core and the device code. The core code should be able
to handle the device "starting" while the VM isn't running to handle
the restoration of migration state. To solve th
Am 04.11.22 um 17:51 schrieb Christian Borntraeger:
Am 04.11.22 um 17:14 schrieb Michael S. Tsirkin:
On Fri, Nov 04, 2022 at 04:59:35PM +0100, Christian Borntraeger wrote:
Am 04.11.22 um 16:56 schrieb Michael S. Tsirkin:
On Fri, Oct 14, 2022 at 02:21:08PM +0100, Alex Bennée wrote:
During
Am 04.11.22 um 17:14 schrieb Michael S. Tsirkin:
On Fri, Nov 04, 2022 at 04:59:35PM +0100, Christian Borntraeger wrote:
Am 04.11.22 um 16:56 schrieb Michael S. Tsirkin:
On Fri, Oct 14, 2022 at 02:21:08PM +0100, Alex Bennée wrote:
During migration the virtio device state can be restored
.
This returns the order introduced in:
9f6bcfd99f (hw/virtio: move vm_running check to virtio_device_started)
to what virtio-sock was doing longhand.
Signed-off-by: Alex Bennée
Cc: Christian Borntraeger
What happens now:
with this applied I get:
https://gitlab.com/mitsirkin/qemu
Am 12.10.22 um 07:18 schrieb Ilya Leoshkevich:
Add ability to dump /tmp/perf-.map and jit-.dump.
The first one allows the perf tool to map samples to each individual
translation block. The second one adds the ability to resolve symbol
names, line numbers and inspect JITed code.
Example of use:
Am 31.03.22 um 10:25 schrieb Christian Borntraeger:
Am 31.03.22 um 09:44 schrieb Christian Borntraeger:
Am 21.02.22 um 11:27 schrieb Christian Borntraeger:
Am 10.02.22 um 18:44 schrieb Vladimir Sementsov-Ogievskiy:
10.02.2022 20:13, Thomas Huth wrote:
On 10/02/2022 15.51, Christian
Ilya has volunteered to review TCG patches for s390x.
Signed-off-by: Christian Borntraeger
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e3d5b7e09c46..ae5e8c8ecbb6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -305,6 +305,7 @@ F: target/rx
vm_running check to virtio_device_started)
to what virtio-sock was doing longhand.
Signed-off-by: Alex Bennée
Cc: Christian Borntraeger
Tested-by: Christian Borntraeger
---
include/hw/virtio/virtio.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/hw
Am 14.10.22 um 13:07 schrieb Alex Bennée:
Christian Borntraeger writes:
Am 14.10.22 um 09:30 schrieb Christian Borntraeger:
Am 10.10.22 um 19:29 schrieb Michael S. Tsirkin:
From: Alex Bennée
All the boilerplate virtio code does the same thing (or should at
least) of checking to see if
Am 14.10.22 um 10:37 schrieb Alex Bennée:
Christian Borntraeger writes:
Am 10.10.22 um 19:29 schrieb Michael S. Tsirkin:
From: Alex Bennée
All the boilerplate virtio code does the same thing (or should at
least) of checking to see if the VM is running before attempting to
start VirtIO
Am 14.10.22 um 09:30 schrieb Christian Borntraeger:
Am 10.10.22 um 19:29 schrieb Michael S. Tsirkin:
From: Alex Bennée
All the boilerplate virtio code does the same thing (or should at
least) of checking to see if the VM is running before attempting to
start VirtIO. Push the logic up to the
Am 10.10.22 um 19:29 schrieb Michael S. Tsirkin:
From: Alex Bennée
All the boilerplate virtio code does the same thing (or should at
least) of checking to see if the VM is running before attempting to
start VirtIO. Push the logic up to the common function to avoid
getting a copy and paste wrong
Fix the opcode for Load and Zero Rightmost Byte (32).
Cc: qemu-sta...@nongnu.org
Reported-by: Nathan Chancellor
Tested-by: Nathan Chancellor
Signed-off-by: Christian Borntraeger
---
target/s390x/tcg/insn-data.def | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/s390x
Am 11.08.22 um 14:27 schrieb Daniel P. Berrangé:
[...]
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -4743,6 +4743,23 @@ HXCOMM Internal use
DEF("qtest", HAS_ARG, QEMU_OPTION_qtest, "", QEMU_ARCH_ALL)
DEF("qtest-log", HAS_ARG, QEMU_OPTION_qtest_log, "", QEMU_ARCH_ALL)
+#ifdef __linux__
Am 04.08.22 um 08:51 schrieb Harald Freudenberger:
On 2022-08-03 14:14, Jason A. Donenfeld wrote:
Hi David,
On Wed, Aug 03, 2022 at 01:55:21PM +0200, David Hildenbrand wrote:
On 02.08.22 21:00, Jason A. Donenfeld wrote:
> In order to fully support MSA_EXT_5, we have to also support the SHA-
Am 02.08.22 um 16:53 schrieb David Hildenbrand:
On 02.08.22 16:01, Christian Borntraeger wrote:
Am 02.08.22 um 15:54 schrieb David Hildenbrand:
On 02.08.22 15:26, Christian Borntraeger wrote:
Am 20.07.22 um 14:08 schrieb Jason A. Donenfeld:
In order for hosts running inside of TCG to
Am 02.08.22 um 15:54 schrieb David Hildenbrand:
On 02.08.22 15:26, Christian Borntraeger wrote:
Am 20.07.22 um 14:08 schrieb Jason A. Donenfeld:
In order for hosts running inside of TCG to initialize the kernel's
random number generator, we should support the PRNO_TRNG instruction,
b
Am 20.07.22 um 14:08 schrieb Jason A. Donenfeld:
In order for hosts running inside of TCG to initialize the kernel's
random number generator, we should support the PRNO_TRNG instruction,
backed in the usual way with the qemu_guest_getrandom helper. This is
confirmed working on Linux 5.19-rc6.
Add stfle 197 (processor-activity-instrumentation extension 1) to the
gen16 default model and fence it off for 7.1 and older.
Signed-off-by: Christian Borntraeger
Reviewed-by: David Hildenbrand
---
v1->v2:
- this is on top of "hw: Add compat machines for 7.2" from Cornelia Huck
Am 26.07.22 um 22:00 schrieb David Hildenbrand:
On 26.07.22 21:48, Christian Borntraeger wrote:
Add stfle 197 (processor-activity-instrumentation extension 1) to the
gen16 default model and fence it off for 7.0 and older.
QEMU is already in soft-freeze. I assume you want to get this still
Add stfle 197 (processor-activity-instrumentation extension 1) to the
gen16 default model and fence it off for 7.0 and older.
Signed-off-by: Christian Borntraeger
---
hw/s390x/s390-virtio-ccw.c | 1 +
target/s390x/cpu_features_def.h.inc | 1 +
target/s390x/gen-features.c | 2
Am 05.07.22 um 18:16 schrieb Dr. David Alan Gilbert:
* Peter Maydell (peter.mayd...@linaro.org) wrote:
On Mon, 4 Jul 2022 at 17:43, Ilya Leoshkevich wrote:
zlib_send_prepare() compresses pages of a running VM. zlib does not
make any thread-safety guarantees with respect to changing deflate()
Am 24.06.22 um 10:50 schrieb Thomas Huth:
The s390-ccw bios fails to boot if the boot disk is a virtio-blk
disk with a sector size of 4096. For example:
dasdfmt -b 4096 -d cdl -y -p -M quick /dev/dasdX
fdasd -a /dev/dasdX
install a guest onto /dev/dasdX1 using virtio-blk
qemu-system-s
pped these steps so far and seems
like QEMU never cared. Anyway, it's better to follow the spec, so
let's set these bits now in the right spots, too.
I have not tested that but I agree with this
Acked-by: Christian Borntraeger
Signed-off-by: Thomas Huth
---
pc-bios/s3
Am 24.05.22 um 12:43 schrieb Thomas Huth:
On 19/05/2022 15.53, Janis Schoetterl-Glausch wrote:
On 5/19/22 12:05, Thomas Huth wrote:
On 06/05/2022 17.39, Janis Schoetterl-Glausch wrote:
Storage key controlled protection is currently not honored when
emulating instructions.
If available, enab
Am 23.03.22 um 14:57 schrieb David Miller:
Implement Vector-Enhancements Facility 2 for s390x
resolves: https://gitlab.com/qemu-project/qemu/-/issues/738
implements:
VECTOR LOAD ELEMENTS REVERSED (VLER)
VECTOR LOAD BYTE REVERSED ELEMENTS (VLBR)
VECTOR LOAD
Am 01.04.22 um 17:02 schrieb David Miller:
vrr is almost a perfect match (it is for this, larger than imm4 would
need to be split).
.long : this would be uglier.
use enough to be filled with nops after ?
or use a 32b and 16b instead if it's in .text it should make no difference.
I will let Ric
Am 01.04.22 um 04:15 schrieb David Miller:
Hi,
There is some issue with instruction sub/alt encodings not matching,
but I worked around it easily.
I'm dropping the updated patch for the tests in here.
I know I should resend the entire patch series as a higher version
really, and will do so.
Am 31.03.22 um 09:44 schrieb Christian Borntraeger:
Am 21.02.22 um 11:27 schrieb Christian Borntraeger:
Am 10.02.22 um 18:44 schrieb Vladimir Sementsov-Ogievskiy:
10.02.2022 20:13, Thomas Huth wrote:
On 10/02/2022 15.51, Christian Borntraeger wrote:
Am 10.02.22 um 15:47 schrieb
Am 21.02.22 um 11:27 schrieb Christian Borntraeger:
Am 10.02.22 um 18:44 schrieb Vladimir Sementsov-Ogievskiy:
10.02.2022 20:13, Thomas Huth wrote:
On 10/02/2022 15.51, Christian Borntraeger wrote:
Am 10.02.22 um 15:47 schrieb Vladimir Sementsov-Ogievskiy:
10.02.2022 10:57, Christian
Peter, Alex this is the fallout of Ilyas analysis of the s390x migration issue
that triggered the DFLTCC workaround.
Am 29.03.22 um 17:21 schrieb Ilya Leoshkevich:
zlib_send_prepare() compresses pages of a running VM. zlib does not
make any thread-safety guarantees with respect to changing defl
1 - 100 of 1242 matches
Mail list logo
