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-
On 27/01/17 17:31, Alex Bennée wrote:
>
> Claudio Imbrenda writes:
>
>> 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 v
On 27/01/17 18:05, Alex Bennée wrote:
>
> Claudio Imbrenda writes:
>
>> On 27/01/17 17:31, Alex Bennée wrote:
>>>
>>> Claudio Imbrenda writes:
>>>
>>>> This patch:
>>>>
>>>> * moves vm_start to cpus.c .
>>
On 27/01/17 18:07, Alex Bennée wrote:
>
> Claudio Imbrenda 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 specified whether to
>> single step
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-
ble 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
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: Cl
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:
mentation 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 | 42 ++
gdbstub.c | 209 +---
include/sys
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-
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: Cl
e changelog 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
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
I applied all your suggestions
Claudio
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.
>
> Otherwise you get:
>
On Wed, 31 May 2017 18:33:24 +0200
Greg Kurz wrote:
> On Wed, 31 May 2017 18:17:37 +0200
> Claudio Imbrenda wrote:
>
> > 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
&
On Wed, 31 May 2017 19:06:29 +0200
Greg Kurz wrote:
> On Wed, 31 May 2017 18:51:06 +0200
> Claudio Imbrenda wrote:
> [...]
> > > >
> > > > This is strange. cpu_index() is defined as:
> > > >
> > > > static inline int cpu_index(CPUS
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
we probably need something like this for the storage attributes
device too
On Thu, 24 Aug 2017 14:00:29 +0200
Thomas Huth 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: Claudio Imbrenda
> Signed-o
On Fri, 2 Feb 2018 09:42:41 +
Christian Borntraeger 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
> Signed-off-by: Christia
E_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
, 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
Reviewed-by: Claudio Imbrenda
> ---
> hw/s390x/sclpquiesce.c | 7 ++-
> 1 file c
.
Signed-off-by: Claudio Imbrenda
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/s390-stattrib-kvm.c
index 41770a7..4805
On Thu, 18 Jan 2018 17:20:34 +0100
Cornelia Huck wrote:
> On Mon, 15 Jan 2018 17:52:02 +0100
> Claudio Imbrenda wrote:
>
> > Fix storage attribute migration so that it does not fail for guests
> > with more than a few GB of RAM. Migration itself was successful, but
> &
On Thu, 18 Jan 2018 18:02:40 +0100
Cornelia Huck wrote:
> On Thu, 18 Jan 2018 17:52:29 +0100
> Claudio Imbrenda wrote:
>
> > On Thu, 18 Jan 2018 17:20:34 +0100
> > Cornelia Huck wrote:
> >
> > > On Mon, 15 Jan 2018 17:52:02 +0100
> > > Cl
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
> > > > > > +++ b/hw/s390x/s390-stattrib-kvm.c
> > > >
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
Fixes: 903fd80b03243476 ("s390x/migration: Storage attributes device")
---
hw/s390x/s39
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
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
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
Hello,
just a respectful poke to remind about this patchset :)
Claudio
gt; > +
> > +register_savevm_live(NULL, TYPE_S390_STATTRIB, 0, 0,
> > + &savevm_s390_stattrib_handlers, sas);
> >
> > object_property_add_bool(obj, "migration-enabled",
> > s390_stattrib_get_migration_enabled,
> >
>
> Looks sane to me.
>
> Reviewed-by: David Hildenbrand
Reviewed-by: Claudio Imbrenda
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 reproduce the bug: set up
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")
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
---
hw/s390x/event-facility.c | 43
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
---
hw/char/sclpconsole-lm.c | 4 ++--
hw/char/sclpconsole.c
ward older versions.
Fixes: 67915de9f0383ccf4a ("s390x/event-facility: variable-length event masks")
Signed-off-by: Claudio Imbrenda
---
hw/s390x/event-facility.c | 90 +++---
hw/s390x/s390-virtio-ccw.c | 8 -
2 files changed, 84 insertions(+), 1
On Wed, 21 Feb 2018 16:12:59 +0100
Cornelia Huck wrote:
> On Tue, 20 Feb 2018 19:45:00 +0100
> Claudio Imbrenda wrote:
>
> > The architecture allows the guests to ask for masks up to 1021
> > bytes in length. Part was fixed in
> > 67915de9f0383ccf4ab8c42dd02aa18dcd79
On Wed, 21 Feb 2018 16:20:05 +0100
Cornelia Huck wrote:
> On Tue, 20 Feb 2018 19:45:01 +0100
> Claudio Imbrenda wrote:
>
> > 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
> > all
On Wed, 21 Feb 2018 16:34:59 +0100
Cornelia Huck wrote:
> On Tue, 20 Feb 2018 19:45:02 +0100
> Claudio Imbrenda wrote:
>
> > Extend the SCLP event masks to 64 bits. This will make us future
> > proof against future extensions of the architecture.
> >
> > Noti
On Wed, 21 Feb 2018 18:30:12 +0100
Cornelia Huck wrote:
> On Wed, 21 Feb 2018 17:42:57 +0100
> Claudio Imbrenda wrote:
>
> > On Wed, 21 Feb 2018 16:20:05 +0100
> > Cornelia Huck wrote:
> >
> > > On Tue, 20 Feb 2018 19:45:01 +0100
> > > Claud
On Wed, 21 Feb 2018 18:06:36 +0100
Cornelia Huck wrote:
> On Wed, 21 Feb 2018 17:28:49 +0100
> Claudio Imbrenda wrote:
>
> > On Wed, 21 Feb 2018 16:12:59 +0100
> > Cornelia Huck wrote:
> >
> > > On Tue, 20 Feb 2018 19:45:00 +0100
> > > Cl
ility: variable-length event masks")
Signed-off-by: Claudio Imbrenda
---
hw/s390x/event-facility.c | 91 +++---
hw/s390x/s390-virtio-ccw.c | 8 +++-
2 files changed, 85 insertions(+), 14 deletions(-)
diff --git a/hw/s390x/event-facility.c b/hw/s3
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
---
hw/s390x/event-facility.c | 43 +--
include/hw/s390x/event-facility.h
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
---
hw/char/sclpconsole-lm.c | 4 ++--
hw/char/sclpconsole.c | 4 ++--
hw/s390x
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
On Fri, 23 Feb 2018 11:31:46 +0100
Cornelia Huck wrote:
> On Thu, 22 Feb 2018 17:22:57 +0100
> Claudio Imbrenda wrote:
>
> > Until 67915de9f0383ccf4a ("s390x/event-facility: variable-length
> > event masks") we only supported sclp event masks of size exactly 4
On Fri, 23 Feb 2018 11:37:55 +0100
Cornelia Huck wrote:
> On Thu, 22 Feb 2018 17:22:56 +0100
> Claudio Imbrenda wrote:
>
> > Until 67915de9f0383ccf4a ("s390x/event-facility: variable-length
> > event masks") we only supported 32bit sclp event masks, even though
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
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
---
hw/char/sclpconsole-lm.c | 4 ++--
hw/char/sclpconsole.c | 4 ++--
hw/s390x
/event-facility: variable-length event masks")
Signed-off-by: Claudio Imbrenda
---
hw/s390x/event-facility.c | 91 +++---
hw/s390x/s390-virtio-ccw.c | 8 +++-
2 files changed, 85 insertions(+), 14 deletions(-)
diff --git a/hw/s390x/event-facilit
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
---
hw/s390x/event-facility.c | 50 ---
include/hw/s390x/event-facility.h
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?
true, will fix
[...]
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
---
hw/char/sclpconsole-lm.c | 4 ++--
hw/char/sclpconsole.c | 4 ++--
hw/s390x
/event-facility: variable-length event masks")
Signed-off-by: Claudio Imbrenda
---
hw/s390x/event-facility.c | 81 ++
hw/s390x/s390-virtio-ccw.c | 8 -
2 files changed, 75 insertions(+), 14 deletions(-)
diff --git a/hw/s390x/event-facilit
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
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
---
hw/s390x/event-facility.c | 56 ++-
include/hw/s390x/event-facility.h
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
On Mon, 26 Feb 2018 17:57:51 +0100
Cornelia Huck wrote:
> On Fri, 23 Feb 2018 18:42:58 +0100
> 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
On Mon, 5 Mar 2018 16:27:10 +0100
Cornelia Huck wrote:
> On Fri, 2 Mar 2018 10:44:46 +0100
> Christian Borntraeger wrote:
>
> > On 02/23/2018 06:42 PM, Claudio Imbrenda wrote:
> > > Extend the SCLP event masks to 64 bits.
> > >
> > > Notice that us
On Tue, 6 Mar 2018 09:23:23 +0100
Christian Borntraeger wrote:
> On 03/05/2018 04:27 PM, Cornelia Huck wrote:
> > On Fri, 2 Mar 2018 10:44:46 +0100
> > Christian Borntraeger wrote:
> >
> >> On 02/23/2018 06:42 PM, Claudio Imbrenda wrote:
> >>&
t; >
> > >> On 02/23/2018 06:42 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
> > >>> cannot be migrated to
On Tue, 6 Mar 2018 16:21:18 +0100
Cornelia Huck wrote:
> On Fri, 2 Mar 2018 10:09:16 +0100
> Christian Borntraeger wrote:
>
> > On 02/23/2018 06:42 PM, Claudio Imbrenda wrote:
> > > Until 67915de9f0383ccf4a ("s390x/event-facility: variable-length
> > >
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
---
hw/s390x/event-facility.c | 49 ---
include/hw/s390x/event-facility.h
On Wed, 7 Mar 2018 16:55:48 +0100
Cornelia Huck wrote:
> On Wed, 7 Mar 2018 16:10:34 +0100
> Claudio Imbrenda wrote:
>
> > 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
On Thu, 8 Mar 2018 08:41:47 +0100
Christian Borntraeger 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
> > cannot be migrated to an older vers
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
---
hw/s390x/event-facility.c | 50 ---
include/hw/s390x/event-facility.h
_pv());
> +sclp_service_call_protected(env, sccb, code);
> +break;
> +case ICPT_INSTRUCTION:
> + g_assert(!s390_is_pv());
> +r = sclp_service_call(env, sccb, code);
> +if (r < 0) {
> +kvm_s390_program_interrupt(cpu, -r);
> +return;
> +}
> +setcc(cpu, r);
> }
> -setcc(cpu, r);
> }
>
> static int handle_b2(S390CPU *cpu, struct kvm_run *run, uint8_t ipa1)
Reviewed-by: Claudio Imbrenda
ra);
> return -EIO;
> @@ -601,7 +618,7 @@ void ioinst_handle_chsc(S390CPU *cpu, uint32_t
> ipb, uintptr_t ra) {
> ChscReq *req;
> ChscResp *res;
> -uint64_t addr;
> +uint64_t addr = 0;
> int reg;
> uint16_t len;
> uint16_t command;
> @@ -610,7 +627,9 @@ void ioinst_handle_chsc(S390CPU *cpu, uint32_t
> ipb, uintptr_t ra)
> trace_ioinst("chsc");
> reg = (ipb >> 20) & 0x00f;
> -addr = env->regs[reg];
> +if (!s390_is_pv()) {
> +addr = env->regs[reg];
> +}
> /* Page boundary? */
> if (addr & 0xfff) {
> s390_program_interrupt(env, PGM_SPECIFICATION, ra);
Reviewed-by: Claudio Imbrenda
memcpy(sysib.vm[0].uuid, &qemu_uuid, sizeof(sysib.vm[0].uuid));
>
> -s390_cpu_virt_mem_write(cpu, addr, ar, &sysib, sizeof(sysib));
> +if (s390_is_pv()) {
> +s390_cpu_pv_mem_write(cpu, 0, &sysib, sizeof(sysib));
> +} else {
> +s390_cpu_virt_mem_write(cpu, addr, ar, &sysib,
> sizeof(sysib));
> +}
> }
>
> static int handle_stsi(S390CPU *cpu)
Reviewed-by: Claudio Imbrenda
fine DIAG_308_RC_OK 0x0001
> #define DIAG_308_RC_NO_CONF 0x0102
> #define DIAG_308_RC_INVALID 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
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
ncludes 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
ool is_write)
> +{
> + int ret;
> +
> +if (kvm_enabled()) {
> +ret = kvm_s390_mem_op_pv(cpu, offset, hostbuf, len,
> is_write);
> +} else {
> +/* Protected Virtualization is a KVM/Hardware only feature */
> +g_assert_not_reached();
> +}
> +return ret;
> +}
> +
> /**
> * s390_cpu_virt_mem_rw:
> * @laddr: the logical start address
Reviewed-by: Claudio Imbrenda
r,
> bool store_arch) hwaddr len = sizeof(*sa);
> int i;
>
> +/* Storing will occur on next SIE entry for protected VMs */
> +if (s390_is_pv()) {
> + return 0;
> +}
> +
> sa = cpu_physical_memory_map(addr, &len, true);
> if (!sa) {
> return -EFAULT;
Reviewed-by: Claudio Imbrenda
On Wed, 11 Mar 2020 09:21:48 -0400
Janosch Frank wrote:
> For protected guests, we need to put the IO emulation results into the
> SIDA, so SIE will write them into the guest at the next entry.
>
> Signed-off-by: Janosch Frank
> ---
> target/s390x/ioinst.c | 87
> ++
(long)cs->kvm_run->psw_addr);
> switch (icpt_code) {
> case ICPT_INSTRUCTION:
> +case ICPT_PV_INSTR:
> +case ICPT_PV_INSTR_NOTIFICATION:
> r = handle_instruction(cpu, run);
> break;
> case ICPT_PROGRAM:
very straightforward
Reviewed-by: Claudio Imbrenda
On Wed, 11 Mar 2020 09:21:45 -0400
Janosch Frank wrote:
> Handling of CPU reset and setting of the IPL psw from guest storage at
> offset 0 is done by a Ultravisor call. Let's only fetch it if
> necessary.
>
> Signed-off-by: Janosch Frank
> Reviewed-by: Thomas Huth
> Reviewed-by: David Hildenb
error_free_or_abort(&pv_mig_blocker);
> +return rc;
> +}
> +
> /* Create SE VM */
> rc = s390_pv_vm_enable();
> if (rc) {
> + error_report_err(local_err);
> +migrate_del_blocker(pv_mig_blocker);
> +error_free_or_abort(&pv_mig_blocker);
> return rc;
> }
>
looks rather straightforward
Reviewed-by: Claudio Imbrenda
r);
> error_free_or_abort(&pv_mig_blocker);
> return rc;
> @@ -345,6 +349,7 @@ static int
> s390_machine_protect(S390CcwMachineState *ms) /* Create SE VM */
> rc = s390_pv_vm_enable();
> if (rc) {
> +qemu_balloon_inhibit(false);
> error_report_err(local_err);
> migrate_del_blocker(pv_mig_blocker);
> error_free_or_abort(&pv_mig_blocker);
looks straightforward
Reviewed-by: Claudio Imbrenda
x27;t need HW
> support */ set_bit(S390_FEAT_ZPCI, model->features);
> set_bit(S390_FEAT_ADAPTER_EVENT_NOTIFICATION, model->features);
Reviewed-by: Claudio Imbrenda
On Fri, 13 Mar 2020 15:21:07 +0100
Janosch Frank wrote:
> On 3/13/20 1:57 PM, Claudio Imbrenda wrote:
> > On Wed, 11 Mar 2020 09:21:45 -0400
> > Janosch Frank wrote:
> >
> >> Handling of CPU reset and setting of the IPL psw from guest
> >> storage a
On Fri, 13 Mar 2020 15:21:07 +0100
Janosch Frank wrote:
> On 3/13/20 1:57 PM, Claudio Imbrenda wrote:
> > On Wed, 11 Mar 2020 09:21:45 -0400
> > Janosch Frank wrote:
> >
> >> Handling of CPU reset and setting of the IPL psw from guest
> >> storage a
On Fri, 10 Jul 2020 17:12:36 +0200
David Hildenbrand wrote:
> Let's implement diag260 - "Access Certain Virtual Machine
> Information", used under z/VM to expose the storage configuration
> (especially, layout of storage extends and thereby holes). For now,
> the returned information is completel
-strict-aliasing
> -fno-asynchronous-unwind-tables QEMU_CFLAGS += $(call cc-option,
> $(QEMU_CFLAGS), -fno-stack-protector) +QEMU_CFLAGS += -msoft-float
> -march=z900 +QEMU_CFLAGS += -std=gnu99
> LDFLAGS += -Wl,-pie -nostdlib
>
> build-all: s390-ccw.img s390-netboot.img
Reviewed-by: Claudio Imbrenda
t; +}
> +
> +int main(void)
> +{
> +sclp_setup();
> +css_setup();
> +boot_setup();
> +find_boot_device();
> + enable_subchannel(blk_schid);
> +ipl_boot_device();
>
> panic("Failed to load OS from hard disk\n");
> return 0; /* make compiler happy */
Reviewed-by: Claudio Imbrenda
On Tue, 28 Jul 2020 20:37:33 +0200
Thomas Huth wrote:
> If no boot device has been specified (via "bootindex=..."), the
> s390-ccw bios scans through all devices to find a bootable device.
maybe a better title for the patch is "scan through all devices if no
boot device specified" then, since it
On Tue, 28 Jul 2020 20:37:31 +0200
Thomas Huth wrote:
> Move the code to a separate function to be able to re-use it from a
> different spot later.
>
> Signed-off-by: Thomas Huth
> ---
> pc-bios/s390-ccw/main.c | 99
> - 1 file changed, 57
> insertions(+)
On Tue, 4 Aug 2020 15:24:09 +0200
Thomas Huth wrote:
> On 03/08/2020 10.46, Claudio Imbrenda wrote:
> > On Tue, 28 Jul 2020 20:37:31 +0200
> > Thomas Huth wrote:
> >
> >> Move the code to a separate function to be able to re-use it from a
> >> differ
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 -
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
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
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
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
--- a/hw/s3
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
--- a/hw/s390x/sclp
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: refact
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
On Wed, 18 Mar 2020 10:30:32 -0400
Janosch Frank wrote:
> They are part of the IPL process, so let's put them into the ipl
> header.
>
> Signed-off-by: Janosch Frank
Reviewed-by: Claudio Imbrenda
> ---
> hw/s390x/ipl.h | 11 +++
> target/s390x/di
On Tue, 9 Jun 2020 11:41:30 +0200
Halil Pasic wrote:
[...]
> I don't know. Janosch could answer that, but he is on vacation. Adding
> Claudio maybe he can answer. My understanding is, that while it might
> be possible, it is ugly at best. The ability to do a transition is
> indicated by a CPU mo
let's not do anything in case the prefix doesn't change.
also looks like a good idea
Reviewed-by: Claudio Imbrenda
> Cc: Richard Henderson
> Cc: David Hildenbrand
> Cc: Cornelia Huck
> Cc: Thomas Huth
> Cc: Claudio Imbrenda
> Cc: qemu-s3...@nongnu.org
> Signed-
101 - 200 of 203 matches
Mail list logo
