Re: [PATCH v8 2/2] s390/kvm: diagnose 0x318 sync and reset

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

 



On Mon, 22 Jun 2020 16:50:41 +0200
Christian Borntraeger <borntraeger@xxxxxxxxxx> wrote:

> On 22.06.20 12:24, Cornelia Huck wrote:
> > On Thu, 18 Jun 2020 18:22:22 -0400
> > Collin Walling <walling@xxxxxxxxxxxxx> wrote:
> >   
> >> DIAGNOSE 0x318 (diag318) sets information regarding the environment
> >> the VM is running in (Linux, z/VM, etc) and is observed via
> >> firmware/service events.
> >>
> >> This is a privileged s390x instruction that must be intercepted by
> >> SIE. Userspace handles the instruction as well as migration. Data
> >> is communicated via VCPU register synchronization.
> >>
> >> The Control Program Name Code (CPNC) is stored in the SIE block. The
> >> CPNC along with the Control Program Version Code (CPVC) are stored
> >> in the kvm_vcpu_arch struct.
> >>
> >> The CPNC is shadowed/unshadowed in VSIE.
> >>
> >> This data is reset on load normal and clear resets.
> >>
> >> Signed-off-by: Collin Walling <walling@xxxxxxxxxxxxx>
> >> ---
> >>  arch/s390/include/asm/kvm_host.h |  4 +++-
> >>  arch/s390/include/uapi/asm/kvm.h |  5 ++++-
> >>  arch/s390/kvm/kvm-s390.c         | 11 ++++++++++-
> >>  arch/s390/kvm/vsie.c             |  3 +++
> >>  include/uapi/linux/kvm.h         |  1 +
> >>  5 files changed, 21 insertions(+), 3 deletions(-)
> >>  
> > 
> > (...)
> >   
> >> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> >> index 4fdf30316582..35cdb4307904 100644
> >> --- a/include/uapi/linux/kvm.h
> >> +++ b/include/uapi/linux/kvm.h
> >> @@ -1031,6 +1031,7 @@ struct kvm_ppc_resize_hpt {
> >>  #define KVM_CAP_PPC_SECURE_GUEST 181
> >>  #define KVM_CAP_HALT_POLL 182
> >>  #define KVM_CAP_ASYNC_PF_INT 183
> >> +#define KVM_CAP_S390_DIAG318 184  
> > 
> > Do we strictly need this new cap, or would checking against the sync
> > regs capabilities be enough?  
> 
> We could check the sync_regs valid field to decide about the sync. We do
> that for ETOKEN as well and QEMU also uses it in handle_diag_318.
> 
> I think what this is used for is actually to tell the QEMU CPU model
> if this is there. And for that the sync_reg validity seems wrong. So better
> keep the CAP?
> 

Ok, makes sense.




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Kernel Development]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Info]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Linux Media]     [Device Mapper]

  Powered by Linux