public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Collin Walling <walling@linux.ibm.com>
To: David Hildenbrand <david@redhat.com>,
	kvm@vger.kernel.org, linux-s390@vger.kernel.org
Cc: pbonzini@redhat.com, borntraeger@de.ibm.com,
	frankja@linux.ibm.com, cohuck@redhat.com, imbrenda@linux.ibm.com,
	heiko.carstens@de.ibm.com, gor@linux.ibm.com, thuth@redhat.com
Subject: Re: [PATCH v8 2/2] s390/kvm: diagnose 0x318 sync and reset
Date: Fri, 19 Jun 2020 11:47:46 -0400	[thread overview]
Message-ID: <e080cf6d-c8cb-a363-1fd1-cbbc4cbda7fe@linux.ibm.com> (raw)
In-Reply-To: <eb41cdd1-9bdf-eb0c-1296-254ade66397a@redhat.com>

On 6/19/20 10:52 AM, David Hildenbrand wrote:
> On 19.06.20 00:22, Collin Walling 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.
>>
> 
> [...]
> 
>>  
>>  int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
>> @@ -4194,6 +4198,10 @@ static void sync_regs_fmt2(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
>>  		if (vcpu->arch.pfault_token == KVM_S390_PFAULT_TOKEN_INVALID)
>>  			kvm_clear_async_pf_completion_queue(vcpu);
>>  	}
>> +	if (kvm_run->kvm_dirty_regs & KVM_SYNC_DIAG318) {
>> +		vcpu->arch.diag318_info.val = kvm_run->s.regs.diag318;
>> +		vcpu->arch.sie_block->cpnc = vcpu->arch.diag318_info.cpnc;
>> +	}
>>  	/*
>>  	 * If userspace sets the riccb (e.g. after migration) to a valid state,
>>  	 * we should enable RI here instead of doing the lazy enablement.
>> @@ -4295,6 +4303,7 @@ static void store_regs_fmt2(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
>>  	kvm_run->s.regs.pp = vcpu->arch.sie_block->pp;
>>  	kvm_run->s.regs.gbea = vcpu->arch.sie_block->gbea;
>>  	kvm_run->s.regs.bpbc = (vcpu->arch.sie_block->fpf & FPF_BPBC) == FPF_BPBC;
>> +	kvm_run->s.regs.diag318 = vcpu->arch.diag318_info.val;
>>  	if (MACHINE_HAS_GS) {
>>  		__ctl_set_bit(2, 4);
>>  		if (vcpu->arch.gs_enabled)
>> diff --git a/arch/s390/kvm/vsie.c b/arch/s390/kvm/vsie.c
>> index 9e9056cebfcf..ba83d0568bc7 100644
>> --- a/arch/s390/kvm/vsie.c
>> +++ b/arch/s390/kvm/vsie.c
>> @@ -423,6 +423,8 @@ static void unshadow_scb(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page)
>>  		break;
>>  	}
>>  
>> +	scb_o->cpnc = scb_s->cpnc;
> 
> "This is a privileged s390x instruction that must be intercepted", how
> can the cpnc change, then, while in SIE?
> 
> Apart from that LGTM.
> 

I thought shadow/unshadow was a load/store (respectively) when executing
in SIE for a level 3+ guest (where LPAR is level 1)?

* Shadow SCB (load shadow VSIE page; originally CPNC is 0)

* Execute diag318 (under SIE)

* Unshadow SCB (store in original VSIE page; CPNC is whatever code the
guest decided to set)

Don't we need to preserve the CPNC for the level 3+ guest somehow?

-- 
Regards,
Collin

Stay safe and stay healthy

  reply	other threads:[~2020-06-19 15:47 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-18 22:22 [PATCH v8 0/2] Use DIAG318 to set Control Program Name & Version Codes Collin Walling
2020-06-18 22:22 ` [PATCH v8 1/2] s390/setup: diag 318: refactor struct Collin Walling
2020-06-22 14:56   ` Christian Borntraeger
2020-06-22 15:37     ` Collin Walling
2020-06-18 22:22 ` [PATCH v8 2/2] s390/kvm: diagnose 0x318 sync and reset Collin Walling
2020-06-19 11:02   ` Janosch Frank
2020-06-19 14:45     ` Collin Walling
2020-06-19 14:52   ` David Hildenbrand
2020-06-19 15:47     ` Collin Walling [this message]
2020-06-19 17:17       ` David Hildenbrand
2020-06-19 17:55         ` Collin Walling
2020-06-19 18:13           ` David Hildenbrand
2020-06-19 18:46             ` Collin Walling
2020-06-22 10:24   ` Cornelia Huck
2020-06-22 14:50     ` Christian Borntraeger
2020-06-22 15:03       ` Cornelia Huck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e080cf6d-c8cb-a363-1fd1-cbbc4cbda7fe@linux.ibm.com \
    --to=walling@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox