Re: [Qemu-devel] [PATCH v7 2/2] gdbstub: Fix vCont behaviour

On 06/02/17 11:00, Paolo Bonzini wrote: > > > On 27/01/2017 19:11, Claudio Imbrenda wrote: >> +/* mark valid CPUs with 1 */ >> +CPU_FOREACH(cpu) { >> +newstates[cpu_index(cpu) - 1] = 1; >> +} > > Sorry I didn't notice this before: CPU i

[Qemu-devel] [PATCH v6 1/2] move vm_start to cpus.c

resume_all_vcpus, and add an explicit call to it before each instance of resume_all_vcpus in the code. Signed-off-by: Claudio Imbrenda <imbre...@linux.vnet.ibm.com> --- cpus.c | 42 ++ include/sysemu/sysemu.h | 2 ++

[Qemu-devel] [PATCH v6 2/2] gdbstub: Fix vCont behaviour

is issued, all VCPUs continue to run, although all but VCPU nr 2 are to be stopped. This patch completely rewrites the vCont parsing code. Please note that this improvement only works in system emulation mode, when in userspace emulation mode the old behaviour is preserved. Signed-off-by: Cla

[Qemu-devel] [PATCH v6 0/2] Qemu: gdbstub: fix vCont

.0-rc2, no changes needed v2 -> v3 * removed resume_some_vcpus * cleared up the code and simplified the implementation in light of the clarification in the specification of the vCont packet Claudio Imbrenda (2): move vm_start to cpus.c gdbstub: Fix vCont behaviour cpus.c

Re: [Qemu-devel] [PATCH v2 1/2] move vm_start to cpus.c

On 27/01/17 17:31, Alex Bennée wrote: > > Claudio Imbrenda <imbre...@linux.vnet.ibm.com> writes: > >> This patch: >> >> * moves vm_start to cpus.c . >> * exports qemu_vmstop_requested, since it's needed by vm_start . >> * extracts vm_prepare_s

Re: [Qemu-devel] [PATCH v2 1/2] move vm_start to cpus.c

On 27/01/17 18:05, Alex Bennée wrote: > > Claudio Imbrenda <imbre...@linux.vnet.ibm.com> writes: > >> On 27/01/17 17:31, Alex Bennée wrote: >>> >>> Claudio Imbrenda <imbre...@linux.vnet.ibm.com> writes: >>> >>>>

Re: [Qemu-devel] [PATCH v2 2/2] gdbstub: Fix vCont behaviour

On 27/01/17 18:07, Alex Bennée wrote: > > Claudio Imbrenda <imbre...@linux.vnet.ibm.com> writes: > >> When GDB issues a "vCont", QEMU was not handling it correctly when >> multiple VCPUs are active. >> For vCont, for each thread (VCPU), it can be sp

[Qemu-devel] [PATCH v7 1/2] move vm_start to cpus.c

This patch: * moves vm_start to cpus.c. * exports qemu_vmstop_requested, since it's needed by vm_start. * extracts vm_prepare_start from vm_start; it does what vm_start did, except restarting the cpus. * vm_start now calls vm_prepare_start and then restarts the cpus. Signed-off-by: Claudio

[Qemu-devel] [PATCH v7 2/2] gdbstub: Fix vCont behaviour

is issued, all VCPUs continue to run, although all but VCPU nr 2 are to be stopped. This patch completely rewrites the vCont parsing code. Please note that this improvement only works in system emulation mode, when in userspace emulation mode the old behaviour is preserved. Signed-off-by: Cla

[Qemu-devel] [PATCH v7 0/2] Qemu: gdbstub: fix vCont

enable to gdb_continue_partial v3 -> v4 * rebased on v2.8.0-rc2, no changes needed v2 -> v3 * removed resume_some_vcpus * cleared up the code and simplified the implementation in light of the clarification in the specification of the vCont packet Claudio Imbrenda (2): move vm_start to cpus.c

Re: [Qemu-devel] [PATCH v3 1/2] move vm_start to cpus.c

On 25/01/17 11:21, Paolo Bonzini wrote: > > > On 28/10/2016 19:15, Claudio Imbrenda wrote: >> * moves the call to qemu_clock_enable away from resume_all_vcpus, and >> add an explicit call to it before each instance of resume_all_vcpus >> in the code. > > Thi

Re: [Qemu-devel] [PATCH v3 2/2] gdbstub: Fix vCont behaviour

I applied all your suggestions Claudio

[Qemu-devel] [PATCH v8 1/2] move vm_start to cpus.c

This patch: * moves vm_start to cpus.c. * exports qemu_vmstop_requested, since it's needed by vm_start. * extracts vm_prepare_start from vm_start; it does what vm_start did, except restarting the cpus. * vm_start now calls vm_prepare_start and then restarts the cpus. Signed-off-by: Claudio

Re: [Qemu-devel] [PATCH for-2.8 2/2] vhost-vsock: add virtio sockets device

On 09/09/16 23:07, Michael S. Tsirkin wrote: [...] > Seems to fail build: > > /scm/qemu/hw/s390x/virtio-ccw.c:1664:4: error: ‘VirtioCcwDevice {aka > struct VirtioCcwDevice}’ has no member named ‘bus_id’ > DEFINE_PROP_STRING("devno", VirtioCcwDevice, bus_id), > ^ >

[Qemu-devel] [PATCH v1 0/2] Qemu: gdbstub: fix vCont and single-step

(single-step) commands to behave like c (continue) commands. Claudio Imbrenda (2): gdbstub: Fix single-step gdbstub: Fix vCont behaviour gdbstub.c | 189 +- kvm-all.c | 1 + 2 files changed, 151 insertions(+), 39 deletions(-) -- 1.9.1

[Qemu-devel] [PATCH v1 1/2] gdbstub: Fix single-step

Commit e0eeb4a21a3ca4b296220ce4449d8acef9de9049 introduced a bug that causes single-step in the gdbstub to not work, at least in kvm. CPUs that are supposed to single-step will instead run normally. This small patch fixes the problem. (tested on s390x) Signed-off-by: Claudio Imbrenda <im

[Qemu-devel] [PATCH v1 2/2] gdbstub: Fix vCont behaviour

is issued, all VCPUs continue to run, although all but VCPU nr 2 are to be stopped. This patch: * adds an additional helper function to selectively restart only some CPUs * completely rewrites the vCont parsing code Signed-off-by: Claudio Imbrenda <imbre...@linux.vnet.ibm.co

Re: [Qemu-devel] [PATCH for-2.8 2/2] vhost-vsock: add virtio sockets device

ngelog of the kernel patch) we wanted guest -> host to be also possible? thanks! Claudio Imbrenda On 16/08/16 14:27, Stefan Hajnoczi wrote: Implement the new virtio sockets device for host<->guest communication using the Sockets API. Most of the work is done in a vhost kern

[Qemu-devel] [PATCH v3 1/2] move vm_start to cpus.c

resume_all_vcpus, and add an explicit call to it before each instance of resume_all_vcpus in the code. Signed-off-by: Claudio Imbrenda <imbre...@linux.vnet.ibm.com> --- cpus.c | 44 +++- hw/i386/kvmvapic.c | 2 ++ include/

[Qemu-devel] [PATCH v3 2/2] gdbstub: Fix vCont behaviour

is issued, all VCPUs continue to run, although all but VCPU nr 2 are to be stopped. This patch completely rewrites the vCont parsing code. Please note that this improvement only works in system emulation mode, when in userspace emulation mode the old behaviour is preserved. Signed-off-by: Cla

[Qemu-devel] [PATCH v3 0/2] Qemu: gdbstub: fix vCont

https://sourceware.org/gdb/onlinedocs/gdb/Packets.html v2 -> v3 * removed resume_some_vcpus * cleared up the code and simplified the implementation in light of the clarification in the specification of the vCont packet Claudio Imbrenda (2): move vm_start to cpus.c gdbstub: Fix vCont behavi

[Qemu-devel] [PATCH v2 2/2] gdbstub: Fix vCont behaviour

userspace emulation mode the old behaviour is preserved. Signed-off-by: Claudio Imbrenda <imbre...@linux.vnet.ibm.com> --- gdbstub.c | 226 +- 1 file changed, 179 insertions(+), 47 deletions(-) diff --git a/gdbstub.c b/gdbstu

[Qemu-devel] [PATCH v2 1/2] move vm_start to cpus.c

resume_all_vcpus, and add an explicit call to it before each instance of resume_all_vcpus in the code. * adds resume_some_vcpus, to selectively restart only some CPUs. Signed-off-by: Claudio Imbrenda <imbre...@linux.vnet.ibm.com> --- cpus.c

[Qemu-devel] [PATCH v2 0/2] Qemu: gdbstub: fix vCont

should be restarted except the first, and when a vCont;s:1 is received, the first CPU should be stepped without restarting the others. With this patchset Qemu now behaves as expected. See here for reference material about the packets: https://sourceware.org/gdb/onlinedocs/gdb/Packets.html Claudio

[Qemu-devel] a small issue with VSOCK

the issue here, so that you are now aware of it, and can maybe fix it in the future. best regards, Claudio Imbrenda

Re: [Qemu-devel] [PATCH v2 2/2] gdbstub: Fix vCont behaviour

On 27/10/16 13:40, Pedro Alves wrote: > I'm not a qemu gdbstub expert, but FYI, seeing this reminded me to push > to gdb's master a (getting old) gdb patch that clarifies how vCont actions > should be interpreted: > > https://sourceware.org/ml/gdb-patches/2016-02/msg00493.html > > It's already

Re: [Qemu-devel] [PATCH v2 2/2] gdbstub: Fix vCont behaviour

On 28/10/16 16:01, Pedro Alves wrote: >> From the new specifications I seem to understand that if I specify a >> default as first action, then no further actions will be considered, >> since it matches all threads? > > Right. ok, that's the way I understand the new specs, which is not how I had

Re: [Qemu-devel] [PATCH] kvm-all: don't use stale dbg_data->cpu

Tested-by: Claudio Imbrenda <imbre...@linux.vnet.ibm.com> On 10/10/16 17:46, Alex Bennée wrote: > The changes to run_on_cpu and friends mean that all helpers are passed > the CPUState of vCPU they are running on. The conversion missed the > field in commit e0eeb4a21a3ca4b296220ce44

Re: [Qemu-devel] [PATCH 2/2] char: use a fixed idx for child muxed chr

Hi, I noticed that this patch kills the Qemu monitor for me. If I start a text-mode guest with -nographic, then I can't switch to the monitor any longer with Ctrl+a c . The guest works otherwise, e.g. I can login from the console. Tested on s390, but I think it's a more general issue, since the

Re: [Qemu-devel] [PATCH v1 2/2] gdbstub: Fix vCont behaviour

On 12/10/16 15:15, David Hildenbrand wrote: >>> +for (cx = 0; ccpus && ccpus[cx]; cx++) { >>> +cpu_single_step(cpu, 0); > > This looks suspicious why? we set all cpus to single step, since that is the default, and then we clear the single-step property from all CPUs

Re: [Qemu-devel] [PATCH v3 0/2] Qemu: gdbstub: fix vCont

Hello, just a respectful poke to remind about this patchset :) Claudio

Re: [Qemu-devel] [PATCH v3 0/2] Qemu: gdbstub: fix vCont

in suspense :) thanks! Claudio On 28/10/16 19:15, Claudio Imbrenda wrote: > This small patchset fixes the incorrect behaviour of the vCont command > in the gdb stub. > > The first patch, as suggested be Paolo, refactors some code. The most > visible change is that it moves vm_

Re: [Qemu-devel] [PATCH v1 2/2] gdbstub: don't fail on vCont; C04:0; c packets

On Wed, 31 May 2017 18:33:24 +0200 Greg Kurz <gr...@kaod.org> wrote: > On Wed, 31 May 2017 18:17:37 +0200 > Claudio Imbrenda <imbre...@linux.vnet.ibm.com> wrote: > > > On Wed, 31 May 2017 16:09:33 +0100 > > Alex Bennée <alex.ben...@linaro.org> wrote: > &

Re: [Qemu-devel] [PATCH v2 2/4] gdbstub: rename cpu_index -> cpu_gdb_index

int num_regs, const char *xml, int > g_pos); > > -static inline int cpu_index(CPUState *cpu) > +/* Return the GDB index for a given vCPU state. > + * > + * For user mode this is simply the thread id. In system mode GDB > + * numbers CPUs from 1 as 0 is reserved as an "any cpu" index. > + */ > +static inline int cpu_gdb_index(CPUState *cpu) > { > #if defined(CONFIG_USER_ONLY) > return cpu->host_tid; I like this solution Reviewed-by: Claudio Imbrenda <imbre...@linux.vnet.ibm.com>

Re: [Qemu-devel] [PATCH v2 3/4] qom/cpu: remove host_tid field

to change things twice. No big > deal compared to the benefit of dropping the broken @host_tid :) I agree with this > > Signed-off-by: Alex Bennée <alex.ben...@linaro.org> > > --- > > In any case. > > Reviewed-by: Greg Kurz <gr...@kaod.org> and me too

Re: [Qemu-devel] [PATCH v2 4/4] gdbstub: don't fail on vCont; C04:0; c packets

we can use its index. > - */ > -cpu = find_cpu(idx); > /* invalid CPU/thread specified */ > -if (!idx || !cpu) { > +if (!cpu) { > res = -EINVAL; > goto out; > } > + >

Re: [Qemu-devel] [PATCH v1 2/2] gdbstub: don't fail on vCont; C04:0; c packets

On Wed, 31 May 2017 19:06:29 +0200 Greg Kurz <gr...@kaod.org> wrote: > On Wed, 31 May 2017 18:51:06 +0200 > Claudio Imbrenda <imbre...@linux.vnet.ibm.com> wrote: > [...] > > > > > > > > This is strange. cpu_index() is defined as: > > >

Re: [Qemu-devel] [PATCH v1 2/2] gdbstub: don't fail on vCont; C04:0; c packets

On Wed, 31 May 2017 16:09:33 +0100 Alex Bennée wrote: > The thread-id of 0 means any CPU but we then ignore the fact we find > the first_cpu in this case who can have an index of 0. Instead of > bailing out just test if we have managed to match up thread-id to a > CPU. >

Re: [Qemu-devel] [PATCH] hw/s390x: Mark the "sclpquiesce" device with user_creatable = false

es an additional > device, let's better mark it with user_creatable = false to avoid > unexpected behavior, e.g. because the quiesce notifier gets > registered multiple times. > > Signed-off-by: Thomas Huth <th...@redhat.com> Reviewed-by: Claudio Imbrenda <imbre...@linux.v

Re: [Qemu-devel] [PATCH] hw/s390x/sclp: Mark the sclp device with user_creatable = false

; +/* > + * Reason: Creates TYPE_SCLP_EVENT_FACILITY in sclp_init > + * which is a non-pluggable sysbus device > + */ > +dc->user_creatable = false; > > sc->read_SCP_info = read_SCP_info; > sc->read_storage_element0_info = read_storage_element0_info; makes sense Reviewed-by: Claudio Imbrenda <imbre...@linux.vnet.ibm.com>

Re: [Qemu-devel] [PATCH for-2.11] s390x/s390-stattrib: Mark the storage attribute as not user_creatable

On Thu, 24 Aug 2017 14:00:29 +0200 Thomas Huth <th...@redhat.com> wrote: > The storage attribute devices are only meant to be instantiated one > time, internally. They can not be used by the user, so mark them with > user_creatable = false. > > Suggested-by: Cl

Re: [Qemu-devel] [PATCH for-2.11] hw/s390x/s390-skeys: Mark the storage key devices with user_creatable = false

enabled; > skeyclass->get_skeys = qemu_s390_skeys_get; > skeyclass->set_skeys = qemu_s390_skeys_set; > + > +/* Reason: Internal device (only one skeys device for the whole > memory) */ > +dc->user_creatable = false; > } > > static const TypeInfo qemu_s390_skeys_info = { Reviewed-by: Claudio Imbrenda <imbre...@linux.vnet.ibm.com> we probably need something like this for the storage attributes device too

[Qemu-devel] [PATCH v1 1/1] s390x/storage attributes: fix CMMA_BLOCK_SIZE usage

The macro CMMA_BLOCK_SIZE was defined but not used, and a hardcoded value was instead used in the code. This patch fixes the value of CMMA_BLOCK_SIZE and uses it in the appropriate place in the code. Signed-off-by: Claudio Imbrenda --- hw/s390x/s390-stattrib.c | 5 +++-- 1 file changed, 3

[Qemu-devel] [PATCH v2 1/1] s390x/storage attributes: fix CMMA_BLOCK_SIZE usage

appropriate constant KVM_S390_CMMA_SIZE_MAX. Signed-off-by: Claudio Imbrenda --- hw/s390x/s390-stattrib-kvm.c | 3 ++- hw/s390x/s390-stattrib.c | 5 +++-- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/hw/s390x/s390-stattrib-kvm.c b/hw/s390x/s390-stattrib-kvm.c index 480551c..c7e1f35

[Qemu-devel] [PATCH v1 1/1] s390x: fix storage attributes migration for non-small guests

. Signed-off-by: Claudio Imbrenda <imbre...@linux.vnet.ibm.com> Fixes: 903fd80b03243476 ("s390x/migration: Storage attributes device") --- hw/s390x/s390-stattrib-kvm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/hw/s390x/s390-stattrib-kvm.c b/hw/s390x/s39

Re: [Qemu-devel] [PATCH v1 1/1] s390x: fix storage attributes migration for non-small guests

On Thu, 18 Jan 2018 18:25:47 +0100 Cornelia Huck wrote: ... [snip] > > > > > > diff --git a/hw/s390x/s390-stattrib-kvm.c > > > > > > b/hw/s390x/s390-stattrib-kvm.c index 41770a7..480551c 100644 > > > > > > --- a/hw/s390x/s390-stattrib-kvm.c > > > > > > +++

Re: [Qemu-devel] [PATCH v1 1/1] s390x: fix storage attributes migration for non-small guests

On Thu, 18 Jan 2018 17:20:34 +0100 Cornelia Huck <coh...@redhat.com> wrote: > On Mon, 15 Jan 2018 17:52:02 +0100 > Claudio Imbrenda <imbre...@linux.vnet.ibm.com> wrote: > > > Fix storage attribute migration so that it does not fail for guests > > with more than

Re: [Qemu-devel] [PATCH v1 1/1] s390x: fix storage attributes migration for non-small guests

On Thu, 18 Jan 2018 18:02:40 +0100 Cornelia Huck <coh...@redhat.com> wrote: > On Thu, 18 Jan 2018 17:52:29 +0100 > Claudio Imbrenda <imbre...@linux.vnet.ibm.com> wrote: > > > On Thu, 18 Jan 2018 17:20:34 +0100 > > Cornelia Huck <coh...@redhat.com> wrote: &g

[Qemu-devel] [PATCH v2 1/1] s390x: fix storage attributes migration for non-small guests

then not be migrated completely. This patch fixes the out of bounds access, and thus migration of all storage attributes when the guest have large amounts of memory. Signed-off-by: Claudio Imbrenda <imbre...@linux.vnet.ibm.com> Fixes: 903fd80b03243476 ("s390x/migration: Storage attrib

Re: [Qemu-devel] [PATCH] s390x/sclp: fix event mask handling

On Fri, 2 Feb 2018 09:42:41 + Christian Borntraeger <borntrae...@de.ibm.com> wrote: > commit 67915de9f038 ("s390x/event-facility: variable-length event > masks") switches the sclp receive/send mask. This broke the sclp > lm console. Reviewed-by: Claudio Imbrenda <

Re: [Qemu-devel] [PATCH] s390/stattrib: Make SaveVMHandlers data static

gt; -ops->is_active = cmma_active; > > -register_savevm_live(NULL, TYPE_S390_STATTRIB, 0, 0, ops, sas); > > + > > +register_savevm_live(NULL, TYPE_S390_STATTRIB, 0, 0, > > + _s390_stattrib_handlers, sas); > > > > object_property_add_bool(obj, "migration-enabled", > > s390_stattrib_get_migration_enabled, > > > > Looks sane to me. > > Reviewed-by: David Hildenbrand <da...@redhat.com> Reviewed-by: Claudio Imbrenda <imbre...@linux.vnet.ibm.com>

Re: [Qemu-devel] [PATCH v1 2/3] s390x/sclp: clean up sclp masks

On Wed, 21 Feb 2018 18:30:12 +0100 Cornelia Huck <coh...@redhat.com> wrote: > On Wed, 21 Feb 2018 17:42:57 +0100 > Claudio Imbrenda <imbre...@linux.vnet.ibm.com> wrote: > > > On Wed, 21 Feb 2018 16:20:05 +0100 > > Cornelia Huck <coh...@redhat.com> wrote: &g

Re: [Qemu-devel] [PATCH v1 1/3] s390x/sclp: proper support of larger send and receive masks

On Wed, 21 Feb 2018 18:06:36 +0100 Cornelia Huck <coh...@redhat.com> wrote: > On Wed, 21 Feb 2018 17:28:49 +0100 > Claudio Imbrenda <imbre...@linux.vnet.ibm.com> wrote: > > > On Wed, 21 Feb 2018 16:12:59 +0100 > > Cornelia Huck <coh...@redhat.com> wrote: &g

[Qemu-devel] [PATCH v1 0/3] s390x/sclp: 64 bit event masks

2bit masks and the compliant behaviour. The property is bound to the machine version, so older machines keep the old broken behaviour, allowing for migration, but the default is the compliant implementation. Fixes: 67915de9f0383ccf4a ("s390x/event-facility: variable-length event masks")

[Qemu-devel] [PATCH v1 1/3] s390x/sclp: proper support of larger send and receive masks

ward older versions. Fixes: 67915de9f0383ccf4a ("s390x/event-facility: variable-length event masks") Signed-off-by: Claudio Imbrenda <imbre...@linux.vnet.ibm.com> --- hw/s390x/event-facility.c | 90 +++--- hw/s390x/s390-virtio-ccw.c | 8

[Qemu-devel] [PATCH v1 2/3] s390x/sclp: clean up sclp masks

Clean up SCLP masks: introduce an sccb_mask_t to be used for SCLP event masks instead of just unsigned int or uint32_t. This will allow later to extend the mask with more ease. Signed-off-by: Claudio Imbrenda <imbre...@linux.vnet.ibm.com> --- hw/char/sclpconsole-lm.c | 4 ++-- h

[Qemu-devel] [PATCH v1 3/3] s390x/sclp: extend SCLP event masks to 64 bits

Extend the SCLP event masks to 64 bits. This will make us future proof against future extensions of the architecture. Notice that using any of the new bits results in a state that cannot be migrated to an older version. Signed-off-by: Claudio Imbrenda <imbre...@linux.vnet.ibm.com> --- hw

[Qemu-devel] [PATCH v2 0/3] s390x/sclp: 64 bit event masks

v1 -> v2 * improved comments and patch descriptions to better explain why we need this, including better description of the old broken behaviour * rename SCLPEVMSK to SCLP_EVMASK to improve readability * removed some unneded variable initializations * fixed a pre-existing typo Claudio Imbrenda (3

[Qemu-devel] [PATCH v2 2/3] s390x/sclp: clean up sclp masks

Introduce an sccb_mask_t to be used for SCLP event masks instead of just unsigned int or uint32_t. This will allow later to extend the mask with more ease. Signed-off-by: Claudio Imbrenda <imbre...@linux.vnet.ibm.com> --- hw/char/sclpconsole-lm.c | 4 ++-- hw/char/sclpcon

[Qemu-devel] [PATCH v2 3/3] s390x/sclp: extend SCLP event masks to 64 bits

Extend the SCLP event masks to 64 bits. Notice that using any of the new bits results in a state that cannot be migrated to an older version. Signed-off-by: Claudio Imbrenda <imbre...@linux.vnet.ibm.com> --- hw/s390x/event-facility.c | 43 +-- i

[Qemu-devel] [PATCH v2 1/3] s390x/sclp: proper support of larger send and receive masks

ility: variable-length event masks") Signed-off-by: Claudio Imbrenda <imbre...@linux.vnet.ibm.com> --- hw/s390x/event-facility.c | 91 +++--- hw/s390x/s390-virtio-ccw.c | 8 +++- 2 files changed, 85 insertions(+), 14 deletions(-) diff --git a/h

[Qemu-devel] [PATCH v4 2/3] s390x/sclp: clean up sclp masks

Introduce an sccb_mask_t to be used for SCLP event masks instead of just unsigned int or uint32_t. This will allow later to extend the mask with more ease. Signed-off-by: Claudio Imbrenda <imbre...@linux.vnet.ibm.com> --- hw/char/sclpconsole-lm.c | 4 ++-- hw/char/sclpcon

[Qemu-devel] [PATCH v4 1/3] s390x/sclp: proper support of larger send and receive masks

/event-facility: variable-length event masks") Signed-off-by: Claudio Imbrenda <imbre...@linux.vnet.ibm.com> --- hw/s390x/event-facility.c | 81 ++ hw/s390x/s390-virtio-ccw.c | 8 - 2 files changed, 75 insertions(+), 14 deletions(-) d

[Qemu-devel] [PATCH v4 3/3] s390x/sclp: extend SCLP event masks to 64 bits

Extend the SCLP event masks to 64 bits. Notice that using any of the new bits results in a state that cannot be migrated to an older version. Signed-off-by: Claudio Imbrenda <imbre...@linux.vnet.ibm.com> --- hw/s390x/event-facility.c | 56 ++- i

[Qemu-devel] [PATCH v4 0/3] s390x/sclp: 64 bit event masks

MSK to SCLP_EVMASK to improve readability * removed some unneded variable initializations * fixed a pre-existing typo Claudio Imbrenda (3): s390x/sclp: proper support of larger send and receive masks s390x/sclp: clean up sclp masks s390x/sclp: extend SCLP event masks to 64 bits hw/char/sc

Re: [Qemu-devel] [PATCH v3 1/3] s390x/sclp: proper support of larger send and receive masks

On Fri, 23 Feb 2018 15:27:02 +0100 Christian Borntraeger wrote: [...] > > +/* copy up to dst_len bytes and fill the rest of dst with zeroes > > */ > > you just moved this function but shouldnt it be > > src_len bytes and fill will zeroes until dst_len?

Re: [Qemu-devel] [PATCH v1 3/3] s390x/sclp: extend SCLP event masks to 64 bits

On Wed, 21 Feb 2018 16:34:59 +0100 Cornelia Huck <coh...@redhat.com> wrote: > On Tue, 20 Feb 2018 19:45:02 +0100 > Claudio Imbrenda <imbre...@linux.vnet.ibm.com> wrote: > > > Extend the SCLP event masks to 64 bits. This will make us future > > proof against futu

Re: [Qemu-devel] [PATCH v1 2/3] s390x/sclp: clean up sclp masks

On Wed, 21 Feb 2018 16:20:05 +0100 Cornelia Huck <coh...@redhat.com> wrote: > On Tue, 20 Feb 2018 19:45:01 +0100 > Claudio Imbrenda <imbre...@linux.vnet.ibm.com> wrote: > > > Clean up SCLP masks: introduce an sccb_mask_t to be used for SCLP > > event m

Re: [Qemu-devel] [PATCH v1 1/3] s390x/sclp: proper support of larger send and receive masks

On Wed, 21 Feb 2018 16:12:59 +0100 Cornelia Huck <coh...@redhat.com> wrote: > On Tue, 20 Feb 2018 19:45:00 +0100 > Claudio Imbrenda <imbre...@linux.vnet.ibm.com> wrote: > > > The architecture allows the guests to ask for masks up to 1021 > >

Re: [Qemu-devel] [PULL 09/23] gdbstub: Fix vCont behaviour

On Sat, 17 Feb 2018 10:07:38 +0100 Jan Kiszka wrote: [...] > > Seems like no one is doing guest debugging with kvm on x86 except > > me, and I'm only doing it too infrequently now: This one broke that > > use case for SMP guests long ago. How was it tested? > > > > To

Re: [Qemu-devel] [qemu-s390x] [PATCH v1] numa: s390x has no NUMA

; +exit(1); > +#else > if (!mc->cpu_index_to_instance_props) { > error_report("NUMA is not supported by this machine-type"); > exit(1); > } > +#endif > for (cpus = node->cpus; cpus; cpus = cpus->next) { > CpuInstanceProperties props; > if (cpus->value >= max_cpus) { seems straightforward Reviewed-by: Claudio Imbrenda <imbre...@linux.vnet.ibm.com>

Re: [Qemu-devel] [PATCH v2 1/3] s390x/sclp: proper support of larger send and receive masks

On Fri, 23 Feb 2018 11:31:46 +0100 Cornelia Huck <coh...@redhat.com> wrote: > On Thu, 22 Feb 2018 17:22:57 +0100 > Claudio Imbrenda <imbre...@linux.vnet.ibm.com> wrote: > > > Until 67915de9f0383ccf4a ("s390x/event-facility: variable-length > > event mask

Re: [Qemu-devel] [PATCH v2 0/3] s390x/sclp: 64 bit event masks

On Fri, 23 Feb 2018 11:37:55 +0100 Cornelia Huck <coh...@redhat.com> wrote: > On Thu, 22 Feb 2018 17:22:56 +0100 > Claudio Imbrenda <imbre...@linux.vnet.ibm.com> wrote: > > > Until 67915de9f0383ccf4a ("s390x/event-facility: variable-length > > event mask

[Qemu-devel] [PATCH v3 0/3] s390x/sclp: 64 bit event masks

f the old broken behaviour * rename SCLPEVMSK to SCLP_EVMASK to improve readability * removed some unneded variable initializations * fixed a pre-existing typo Claudio Imbrenda (3): s390x/sclp: proper support of larger send and receive masks s390x/sclp: clean up sclp masks s390x/sclp: extend S

[Qemu-devel] [PATCH v3 1/3] s390x/sclp: proper support of larger send and receive masks

/event-facility: variable-length event masks") Signed-off-by: Claudio Imbrenda <imbre...@linux.vnet.ibm.com> --- hw/s390x/event-facility.c | 91 +++--- hw/s390x/s390-virtio-ccw.c | 8 +++- 2 files changed, 85 insertions(+), 14 deletions(-) d

[Qemu-devel] [PATCH v3 2/3] s390x/sclp: clean up sclp masks

Introduce an sccb_mask_t to be used for SCLP event masks instead of just unsigned int or uint32_t. This will allow later to extend the mask with more ease. Signed-off-by: Claudio Imbrenda <imbre...@linux.vnet.ibm.com> --- hw/char/sclpconsole-lm.c | 4 ++-- hw/char/sclpcon

[Qemu-devel] [PATCH v3 3/3] s390x/sclp: extend SCLP event masks to 64 bits

Extend the SCLP event masks to 64 bits. Notice that using any of the new bits results in a state that cannot be migrated to an older version. Signed-off-by: Claudio Imbrenda <imbre...@linux.vnet.ibm.com> --- hw/s390x/event-facility.c | 50 --- i

[Qemu-devel] [PATCH v3 1/1] s390x/storage attributes: fix CMMA_BLOCK_SIZE usage

appropriate constant KVM_S390_CMMA_SIZE_MAX. Signed-off-by: Claudio Imbrenda --- hw/s390x/s390-stattrib-kvm.c | 3 ++- hw/s390x/s390-stattrib.c | 5 +++-- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/hw/s390x/s390-stattrib-kvm.c b/hw/s390x/s390-stattrib-kvm.c index 480551c..c7e1f35

Re: [Qemu-devel] [PATCH v5 1/1] s390x/sclp: extend SCLP event masks to 64 bits

On Thu, 8 Mar 2018 08:41:47 +0100 Christian Borntraeger <borntrae...@de.ibm.com> wrote: > On 03/07/2018 04:10 PM, Claudio Imbrenda wrote: > > Extend the SCLP event masks to 64 bits. > > > > Notice that using any of the new bits results in a state that > > canno

[Qemu-devel] [PATCH v6 1/1] s390x/sclp: extend SCLP event masks to 64 bits

Extend the SCLP event masks to 64 bits. Notice that using any of the new bits results in a state that cannot be migrated to an older version. Signed-off-by: Claudio Imbrenda <imbre...@linux.vnet.ibm.com> --- hw/s390x/event-facility.c | 50 --- i

Re: [Qemu-devel] [PATCH v5 1/1] s390x/sclp: extend SCLP event masks to 64 bits

On Wed, 7 Mar 2018 16:55:48 +0100 Cornelia Huck <coh...@redhat.com> wrote: > On Wed, 7 Mar 2018 16:10:34 +0100 > Claudio Imbrenda <imbre...@linux.vnet.ibm.com> wrote: > > > Extend the SCLP event masks to 64 bits. > > > > Notice that using any of the new

Re: [Qemu-devel] [qemu-s390x] [PATCH v4 1/3] s390x/sclp: proper support of larger send and receive masks

On Tue, 6 Mar 2018 16:21:18 +0100 Cornelia Huck <coh...@redhat.com> wrote: > On Fri, 2 Mar 2018 10:09:16 +0100 > Christian Borntraeger <borntrae...@de.ibm.com> wrote: > > > On 02/23/2018 06:42 PM, Claudio Imbrenda wrote: > > > Until 67915de9f0383ccf4a (&q

Re: [Qemu-devel] [PATCH v4 3/3] s390x/sclp: extend SCLP event masks to 64 bits

On Mon, 26 Feb 2018 17:57:51 +0100 Cornelia Huck <coh...@redhat.com> wrote: > On Fri, 23 Feb 2018 18:42:58 +0100 > Claudio Imbrenda <imbre...@linux.vnet.ibm.com> wrote: > > > Extend the SCLP event masks to 64 bits. > > > > Notice that using any of the new

[Qemu-devel] [PATCH v5 1/1] s390x/sclp: extend SCLP event masks to 64 bits

Extend the SCLP event masks to 64 bits. Notice that using any of the new bits results in a state that cannot be migrated to an older version. Signed-off-by: Claudio Imbrenda <imbre...@linux.vnet.ibm.com> --- hw/s390x/event-facility.c | 49 --- i

Re: [Qemu-devel] [qemu-s390x] [PATCH v4 3/3] s390x/sclp: extend SCLP event masks to 64 bits

On Mon, 5 Mar 2018 16:27:10 +0100 Cornelia Huck <coh...@redhat.com> wrote: > On Fri, 2 Mar 2018 10:44:46 +0100 > Christian Borntraeger <borntrae...@de.ibm.com> wrote: > > > On 02/23/2018 06:42 PM, Claudio Imbrenda wrote: > > > Extend the SCLP event m

Re: [Qemu-devel] [qemu-s390x] [PATCH v4 3/3] s390x/sclp: extend SCLP event masks to 64 bits

46 +0100 > > > Christian Borntraeger <borntrae...@de.ibm.com> wrote: > > > > > >> On 02/23/2018 06:42 PM, Claudio Imbrenda wrote: > > >>> Extend the SCLP event masks to 64 bits. > > >>> > > >>> Notice that using a

Re: [Qemu-devel] [qemu-s390x] [PATCH v4 3/3] s390x/sclp: extend SCLP event masks to 64 bits

On Tue, 6 Mar 2018 09:23:23 +0100 Christian Borntraeger <borntrae...@de.ibm.com> wrote: > On 03/05/2018 04:27 PM, Cornelia Huck wrote: > > On Fri, 2 Mar 2018 10:44:46 +0100 > > Christian Borntraeger <borntrae...@de.ibm.com> wrote: > > > >> On 0

[PATCH v1 1/2] s390x: Add sclp boundary check and fix error priority

From: Janosch Frank * All sclp codes need to be checked for page boundary violations. * Requests over 4k are not a spec exception. * Invalid command checking has to be done before the boundary check. Signed-off-by: Janosch Frank Reviewed-by: Jason J. Herne --- hw/s390x/event-facility.c | 3

[PATCH v1 0/2] s390x: SCLP error cleanup

SCLP doesn't report a lot of errors like it should do, let's fix that. Janosch Frank (1): s390x: Add sclp boundary check and fix error priority Claudio Imbrenda (1): s390x: Fix SCLP return code when buffer too small hw/s390x/event-facility.c | 3 --- hw/s390x/sclp.c | 35

[PATCH v1 2/2] s390x: Fix SCLP return code when buffer too small

Return the correct error code when the SCCB buffer is too small to contain all of the output, for the Read SCP Information and Read CPU Information commands. Signed-off-by: Claudio Imbrenda Reviewed-by: Jason J. Herne --- hw/s390x/sclp.c | 10 ++ 1 file changed, 10 insertions(+) diff

[PATCH v2 0/4] s390x: SCLP error cleanup

SCLP doesn't report a lot of errors like it should do, let's fix that. Changes v1 to v2: * added a few missing be16_to_cpu * split first patch into three smaller patches Claudio Imbrenda (1): s390x: Fix SCLP return code when buffer too small Janosch Frank (3): s390x: sclp: refactor invalid

[PATCH v2 1/4] s390x: sclp: refactor invalid command check

From: Janosch Frank Invalid command checking has to be done before the boundary check, refactoring it now allows to insert the boundary check at the correct place later. Signed-off-by: Janosch Frank Reviewed-by: Jason J. Herne --- hw/s390x/event-facility.c | 3 --- hw/s390x/sclp.c

[PATCH v2 4/4] s390x: Fix SCLP return code when buffer too small

Return the correct error code when the SCCB buffer is too small to contain all of the output, for the Read SCP Information and Read CPU Information commands. Signed-off-by: Claudio Imbrenda Reviewed-by: Jason J. Herne --- hw/s390x/sclp.c | 12 1 file changed, 12 insertions

[PATCH v2 3/4] s390x: sclp: fix error handling for oversize control blocks

From: Janosch Frank Requests over 4k are not a spec exception. Signed-off-by: Janosch Frank Reviewed-by: Jason J. Herne --- hw/s390x/sclp.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/hw/s390x/sclp.c b/hw/s390x/sclp.c index 73244c9..abb6e50 100644 ---

[PATCH v2 2/4] s390x: sclp: boundary check

From: Janosch Frank All sclp codes need to be checked for page boundary violations. Signed-off-by: Janosch Frank Reviewed-by: Jason J. Herne --- hw/s390x/sclp.c | 5 + 1 file changed, 5 insertions(+) diff --git a/hw/s390x/sclp.c b/hw/s390x/sclp.c index 95ebfe7..73244c9 100644 ---

[PATCH v1 1/1] pc-bios/s390-ccw: fix sclp_get_loadparm_ascii

Info") Signed-off-by: Claudio Imbrenda --- pc-bios/s390-ccw/sclp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pc-bios/s390-ccw/sclp.c b/pc-bios/s390-ccw/sclp.c index c0223fa..7251f9a 100644 --- a/pc-bios/s390-ccw/sclp.c +++ b/pc-bios/s390-ccw/sclp.c @@ -

Re: [PATCH v1 1/1] pc-bios/s390-ccw: fix sclp_get_loadparm_ascii

On Thu, 28 Nov 2019 13:33:57 +0100 Claudio Imbrenda wrote: [...] > Signed-off-by: Claudio Imbrenda I forgot this: Reported-by: Marc Hartmayer [...] please add the reported-by when merging :)

Re: [PATCH v9 02/15] s390x: protvirt: Support unpack facility

VALID 0x0402 > +#define DIAG_308_RC_NO_PV_CONF 0x0902 > > #define DIAG308_RESET_MOD_CLR 0 > #define DIAG308_RESET_LOAD_NORM 1 > @@ -59,10 +61,17 @@ int handle_diag_288(CPUS390XState *env, uint64_t > r1, uint64_t r3) #define DIAG308_LOAD_NORMAL_DUMP4 > #define DIAG308_SET 5 > #define DIAG308_STORE 6 > +#define DIAG308_PV_SET 8 > +#define DIAG308_PV_STORE9 > +#define DIAG308_PV_START10 > > static int diag308_parm_check(CPUS390XState *env, uint64_t r1, > uint64_t addr, uintptr_t ra, bool write) > { > +/* Handled by the Ultravisor */ > +if (s390_is_pv()) { > +return 0; > +} > if ((r1 & 1) || (addr & ~TARGET_PAGE_MASK)) { > s390_program_interrupt(env, PGM_SPECIFICATION, ra); > return -1; > @@ -93,6 +102,11 @@ void handle_diag_308(CPUS390XState *env, uint64_t > r1, uint64_t r3, uintptr_t ra) return; > } > > +if (subcode >= DIAG308_PV_SET && > !s390_has_feat(S390_FEAT_UNPACK)) { > +s390_program_interrupt(env, PGM_SPECIFICATION, ra); > +return; > +} > + > switch (subcode) { > case DIAG308_RESET_MOD_CLR: > s390_ipl_reset_request(cs, S390_RESET_MODIFIED_CLEAR); > @@ -105,6 +119,7 @@ void handle_diag_308(CPUS390XState *env, uint64_t > r1, uint64_t r3, uintptr_t ra) s390_ipl_reset_request(cs, > S390_RESET_REIPL); break; > case DIAG308_SET: > +case DIAG308_PV_SET: > if (diag308_parm_check(env, r1, addr, ra, false)) { > return; > } > @@ -128,10 +143,15 @@ out: > g_free(iplb); > return; > case DIAG308_STORE: > +case DIAG308_PV_STORE: > if (diag308_parm_check(env, r1, addr, ra, true)) { > return; > } > -iplb = s390_ipl_get_iplb(); > +if (subcode == DIAG308_PV_STORE) { > +iplb = s390_ipl_get_iplb_pv(); > +} else { > +iplb = s390_ipl_get_iplb(); > +} > if (iplb) { > cpu_physical_memory_write(addr, iplb, > be32_to_cpu(iplb->len)); env->regs[r1 + 1] = DIAG_308_RC_OK; > @@ -139,6 +159,15 @@ out: > env->regs[r1 + 1] = DIAG_308_RC_NO_CONF; > } > return; > +case DIAG308_PV_START: > +iplb = s390_ipl_get_iplb_pv(); > +if (!iplb) { > +env->regs[r1 + 1] = DIAG_308_RC_NO_PV_CONF; > +return; > +} > + > +s390_ipl_reset_request(cs, S390_RESET_PV); > +break; > default: > s390_program_interrupt(env, PGM_SPECIFICATION, ra); > break; with the two typos fixed and the fixup: Reviewed-by: Claudio Imbrenda

Re: [PATCH v9 10/15] s390x: protvirt: Move diag 308 data over SIDA

if (!iplb) { > env->regs[r1 + 1] = DIAG_308_RC_NO_CONF; > +return; > } > + > +if (!s390_is_pv()) { > +cpu_physical_memory_write(addr, iplb, > be32_to_cpu(iplb->len)); > +} else { > + s390_cpu_pv_mem_write(cpu, 0, iplb, > be32_to_cpu(iplb->len)); > +} > +env->regs[r1 + 1] = DIAG_308_RC_OK; > return; > case DIAG308_PV_START: > iplb = s390_ipl_get_iplb_pv(); Reviewed-by: Claudio Imbrenda

Re: [PATCH v9 14/15] docs: Add protvirt docs

ludes the encrypted > +components (kernel, initrd, cmdline), the stage3a loader and > +metadata. In case this boot method is used, the command line > +options -initrd and -cmdline are ineffective. The preparation of a > PVM +image is done by genprotimg of the s390-tools package. Reviewed-by: Claudio Imbrenda

  1   2   >