qemu-s390x
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2] s390/kvm: fix diag318 propagation and reset functionality


From: Thomas Huth
Subject: Re: [PATCH v2] s390/kvm: fix diag318 propagation and reset functionality
Date: Fri, 13 Nov 2020 09:06:11 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0

On 12/11/2020 22.36, Collin Walling wrote:
> The Control Program Name Code (CPNC) portion of the diag318
> info must be set within the SIE block of each VCPU in the
> configuration. The handler will iterate through each VCPU
> and dirty the diag318_info reg to be synced with KVM on a
> subsequent sync_regs call.
> 
> Additionally, the diag318 info resets must be handled via
> userspace. As such, QEMU will reset this value for each
> VCPU during a modified clear, load normal, and load clear
> reset event.
> 
> Fixes: fabdada9357b ("s390: guest support for diagnose 0x318")
> Signed-off-by: Collin Walling <walling@linux.ibm.com>
> ---
> 
> Changelog:
> 
>         v2:
>         - added Fixes tag
>         - added CPU feat check in do_cpu function

Sorry, but this fails to build on x86 (i.e. without kvm):

../../devel/qemu/target/s390x/cpu.c: In function ‘s390_do_cpu_set_diag318’:
../../devel/qemu/target/s390x/cpu.c:459:20: error: dereferencing pointer to
incomplete type ‘struct kvm_run’
         cs->kvm_run->s.regs.diag318 = diag318_info;
                    ^~
../../devel/qemu/target/s390x/cpu.c:460:40: error: ‘KVM_SYNC_DIAG318’
undeclared (first use in this function)
         cs->kvm_run->kvm_dirty_regs |= KVM_SYNC_DIAG318;
                                        ^~~~~~~~~~~~~~~~
../../devel/qemu/target/s390x/cpu.c:460:40: note: each undeclared identifier
is reported only once for each function it appears in
[878/1030] Compiling C object
libqemu-s390x-softmmu.fa.p/target_s390x_misc_helper.c.o
ninja: build stopped: subcommand failed.

(By the way, is Patchew down or now not compile-testing anymore?)

> ---
>  hw/s390x/s390-virtio-ccw.c |  5 +++++
>  target/s390x/cpu.c         | 13 +++++++++++++
>  target/s390x/cpu.h         |  1 +
>  target/s390x/kvm.c         | 10 +++++-----
>  4 files changed, 24 insertions(+), 5 deletions(-)
> 
> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> index 22222c4fd5..a8cebf9bff 100644
> --- a/hw/s390x/s390-virtio-ccw.c
> +++ b/hw/s390x/s390-virtio-ccw.c
> @@ -427,6 +427,9 @@ static void s390_machine_reset(MachineState *machine)
>          qemu_devices_reset();
>          s390_crypto_reset();
>  
> +        CPU_FOREACH(t) {
> +            run_on_cpu(t, s390_do_cpu_set_diag318, RUN_ON_CPU_HOST_ULONG(0));
> +        }

Just double-checking: Is it really ok to modify all CPUs here, while the
code below only touches the ipl-CPU ?

>          /* configure and start the ipl CPU only */
>          run_on_cpu(cs, s390_do_cpu_ipl, RUN_ON_CPU_NULL);
>          break;
> @@ -440,6 +443,7 @@ static void s390_machine_reset(MachineState *machine)
>          s390_pv_prepare_reset(ms);
>          CPU_FOREACH(t) {
>              run_on_cpu(t, s390_do_cpu_full_reset, RUN_ON_CPU_NULL);
> +            run_on_cpu(t, s390_do_cpu_set_diag318, RUN_ON_CPU_HOST_ULONG(0));
>          }
>          run_on_cpu(cs, s390_do_cpu_load_normal, RUN_ON_CPU_NULL);
>          break;
> @@ -451,6 +455,7 @@ static void s390_machine_reset(MachineState *machine)
>          subsystem_reset();
>          s390_pv_prepare_reset(ms);
>          CPU_FOREACH(t) {
> +            run_on_cpu(t, s390_do_cpu_set_diag318, RUN_ON_CPU_HOST_ULONG(0));
>              if (t == cs) {
>                  continue;
>              }

Would it be really wrong to also clear the field in case of S390_RESET_PV?
S390_RESET_PV is also a reset, so I'd assume we could (or even should) also
clear the field in that case?
If so, the new run_on_cpu() statements could maybe also be merged into a
single one that is done before or after the "switch (reset_type)" statement?

 Thomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]