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
QEMU TCG does not support decimal floating point HW instructions (and there are
no plans to do so).
KVM would work as it supports DFP instructions.
a circumvention would be to compile with -mno-hard-dfp
99.9% of the code will not use decimal floating point so nobody noticed
this before.
--
You
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.
Am 11.04.25 um 14:42 schrieb Heiko Carstens:
On Fri, Apr 11, 2025 at 01:11:55PM +0200, Christian Borntraeger wrote:
Am 10.04.25 um 20:44 schrieb David Hildenbrand:
[...]
---
So, given that
(a) people are actively running into this
(b) we'll have to backport this quite a lot
(c) the
Am 10.04.25 um 20:44 schrieb David Hildenbrand:
[...]
---
So, given that
(a) people are actively running into this
(b) we'll have to backport this quite a lot
(c) the spec issue is not a s390x-only issue
(d) it's still unclear how to best deal with the spec issue
I suggest getting this fix he
xander Gordeev
Cc: Christian Borntraeger
Cc: Sven Schnelle
Cc: "Michael S. Tsirkin"
Cc: Wei Wang
Signed-off-by: David Hildenbrand
Acked-by: Christian Borntraeger
I will apply this to our internal s390 tree and let it sit for a
day to get CI coverage.
Alexander, Vasily, Heiko,
###
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
Am 22.01.25 um 23:07 schrieb Michael S. Tsirkin:
On Wed, Jan 22, 2025 at 06:33:04PM +0100, Christian Borntraeger wrote:
Am 22.01.25 um 15:44 schrieb Boyer, Andrew:
[...]
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -379,14 +379,10 @@ static void virtio_commit_rqs
Am 22.01.25 um 15:44 schrieb Boyer, Andrew:
[...]
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -379,14 +379,10 @@ static void virtio_commit_rqs(struct blk_mq_hw_ctx *hctx)
{
struct virtio_blk *vblk = hctx->queue->queuedata;
struct virtio_blk_vq *vq = &vblk->vqs[hct
Am 07.01.25 um 19:25 schrieb Andrew Boyer:
Commit af8ececda185 ("virtio: add VIRTIO_F_NOTIFICATION_DATA feature
support") added notification data support to the core virtio driver
code. When this feature is enabled, the notification includes the
updated producer index for the queue. Thus it is
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 13.12.24 um 02:22 schrieb Bo YU:
Hi s390 porters,
Now pygalmesh[0] is failed to migrate to testing due to autopkgtest
failed on s390x and upstream has got the same report multiple times,
but they were blocked[1] by lack of access to real s390x machines to
see the bug, so could we offer some h
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
ries as soon as there are ACKs for the third
patch, and from the KVM guys for the whole series.
Christian, Janosch, Claudio?
Acked-by: Christian Borntraeger
for the series.
@Eric Farman,
Was someone from your team planning to look into this (testing, review
whatever)?
Am 15.10.24 um 10:37 schrieb Heiko Carstens:
On Mon, Oct 14, 2024 at 09:16:45PM +0200, David Hildenbrand wrote:
On 14.10.24 20:48, Heiko Carstens wrote:
On Mon, Oct 14, 2024 at 04:46:17PM +0200, David Hildenbrand wrote:
to dump. Based on this, support for dumping virtio-mem memory can be
H
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
Am 23.07.24 um 11:31 schrieb Christoph Schlameuss:
To simplify testing enable UCONTROL KVM by default in debug kernels.
Signed-off-by: Christoph Schlameuss
---
arch/s390/Kconfig.debug | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/s390/Kconfig.debug b/arch/s390/Kconfig.debug
[...]
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 22:32 schrieb Donald Russell:
Is there a RHEL 9 udev rule I can use to trigger an action when a reader
file arrives? I couldn’t find anything. 🙁
Newer vmur drivers support a uevent for unsolicited device end. I think this
happens on new files.
A sample udev rule for running a p
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
: Christian Borntraeger
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
+
the CPU to
use the primary address space normally used anyway. AR[1] is
selected for this test because the host AR[1] is usually non-zero,
and KVM needs to correctly swap those values.
Signed-off-by: Eric Farman
Acked-by: Christian Borntraeger
as it is today. If they don't (the MEM_OP path), the
AR can be read from vcpu->run without stashing the current contents.
Signed-off-by: Eric Farman
Acked-by: Christian Borntraeger
Reviewed-by: Christian Borntraeger
---
arch/s390/include/asm/kvm_host.h | 1 +
arch/s390/kvm/gacces
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 16.11.23 um 11:13 schrieb Ilya Leoshkevich:
It's also possible to get a free s390 machine at [1].
[1] https://linuxone.cloud.marist.edu/oss
I think the URL for registration is this one
https://linuxone.cloud.marist.edu/#/register?flag=VM
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 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.
the kernel and initrd from the guest disk and storing it on the host
to IPL the guest with a direct kernel boot.
-Original Message-
From: Linux on 390 Port On Behalf Of Christian Borntraeger
Sent: Thursday, August 3, 2023 03:08
To: LINUX-390@VM.MARIST.EDU
Subject: [EXTERNAL] - Re: SLE
Am 02.08.23 um 21:11 schrieb Alan Haff:
I have a SLES15 SP4 system running under KVM on a z13s that refuses to IPL after
upgrading from SP3. The failure message is "! Cannot read stage2 boot loader
!". I've IPLed into a rescue shell from the SP4 ISO, set up a chroot environment,
and re-ran gru
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 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)
Thank you Mark for all your work! I think we met first at a zExpo or SHARE
(around 2005?) and you have always been a person that did a lot of work
helping others. Very much appreciated!
All the best for your future life :-)
Christian
Am 15.02.23 um 16:55 schrieb Mark Post:
All,
I'm retiring f
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 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 08.12.22 um 17:44 schrieb Jim Elliott:
I am sure that z/OS must provide a function equivalent to z/VM's Link
Aggregation (where you can share physical OSA ports in a VSwitch), but lots
of Google searches are not helping me. Any suggestions?
Link aggregration is on layer2 (ethernet) and used
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
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
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 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 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 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 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: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 belo
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 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 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 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 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: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: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:
Am 1
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 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
1 - 100 of 3702 matches
Mail list logo
