public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Christian Borntraeger <borntraeger@linux.ibm.com>
To: Claudio Imbrenda <imbrenda@linux.ibm.com>
Cc: KVM <kvm@vger.kernel.org>, Janosch Frank <frankja@linux.ibm.com>,
	David Hildenbrand <david@redhat.com>,
	linux-s390 <linux-s390@vger.kernel.org>,
	Thomas Huth <thuth@redhat.com>,
	Heiko Carstens <hca@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Marc Hartmayer <mhartmay@linux.ibm.com>,
	Sven Schnelle <svens@linux.ibm.com>
Subject: Re: [PATCH 1/1] KVM: s390: fix LPSWEY handling
Date: Thu, 27 Jun 2024 11:40:07 +0200	[thread overview]
Message-ID: <8a894728-aa93-48fe-9556-b1e1013bfd87@linux.ibm.com> (raw)
In-Reply-To: <20240627112359.474cbd95@p-imbrenda.boeblingen.de.ibm.com>



Am 27.06.24 um 11:23 schrieb Claudio Imbrenda:
> On Thu, 27 Jun 2024 11:05:20 +0200
> Christian Borntraeger <borntraeger@linux.ibm.com> wrote:
> 
>> in rare cases, e.g. for injecting a machine check we do intercept all
>> load PSW instructions via ICTL_LPSW. With facility 193 a new variant
>> LPSWEY was added. KVM needs to handle that as well.
>>
>> Fixes: a3efa8429266 ("KVM: s390: gen_facilities: allow facilities 165, 193, 194 and 196")
>> Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com>
>> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
> 
> [...]
> 
>> +static inline u64 kvm_s390_get_base_disp_siy(struct kvm_vcpu *vcpu, u8 *ar)
>> +{
>> +	u32 base1 = vcpu->arch.sie_block->ipb >> 28;
>> +	u32 disp1 = ((vcpu->arch.sie_block->ipb & 0x0fff0000) >> 16) +
>> +			((vcpu->arch.sie_block->ipb & 0xff00) << 4);
>> +
>> +	/* The displacement is a 20bit _SIGNED_ value */
>> +	if (disp1 & 0x80000)
>> +		disp1+=0xfff00000;
>> +
>> +	if (ar)
>> +		*ar = base1;
>> +
>> +	return (base1 ? vcpu->run->s.regs.gprs[base1] : 0) + (long)(int)disp1;
>> +}
>> +
>>   static inline void kvm_s390_get_base_disp_sse(struct kvm_vcpu *vcpu,
>>   					      u64 *address1, u64 *address2,
>>   					      u8 *ar_b1, u8 *ar_b2)
>> diff --git a/arch/s390/kvm/priv.c b/arch/s390/kvm/priv.c
>> index 1be19cc9d73c..1a49b89706f8 100644
>> --- a/arch/s390/kvm/priv.c
>> +++ b/arch/s390/kvm/priv.c
>> @@ -797,6 +797,36 @@ static int handle_lpswe(struct kvm_vcpu *vcpu)
>>   	return 0;
>>   }
>>   
>> +static int handle_lpswey(struct kvm_vcpu *vcpu)
>> +{
>> +	psw_t new_psw;
>> +	u64 addr;
>> +	int rc;
>> +	u8 ar;
>> +
>> +	vcpu->stat.instruction_lpswey++;
>> +
>> +	if (!test_kvm_facility(vcpu->kvm, 193))
>> +		return kvm_s390_inject_program_int(vcpu, PGM_OPERATION);
>> +
>> +	if (vcpu->arch.sie_block->gpsw.mask & PSW_MASK_PSTATE)
>> +		return kvm_s390_inject_program_int(vcpu, PGM_PRIVILEGED_OP);
>> +
>> +	addr = kvm_s390_get_base_disp_siy(vcpu, &ar);
>> +	if (addr & 7)
>> +		return kvm_s390_inject_program_int(vcpu, PGM_SPECIFICATION);
>> +
>> +	rc = read_guest(vcpu, addr, ar, &new_psw, sizeof(new_psw));
>> +	if (rc)
>> +		return kvm_s390_inject_prog_cond(vcpu, rc);
>> +
>> +	vcpu->arch.sie_block->gpsw = new_psw;
>> +	if (!is_valid_psw(&vcpu->arch.sie_block->gpsw))
>> +		return kvm_s390_inject_program_int(vcpu, PGM_SPECIFICATION);
>> +
>> +	return 0;
>> +}
> 
> looks quite straightforward, but you duplicated most of handle_lpswe.
> it would probably be cleaner to abstract the "load psw" logic, and
> convert handle_lpswe{,y} to be wrappers around it, something like
> 
> static int _handle_load_psw(struct kvm_vcpu *vcpu, unsigned long
> pswaddr)
> 
> which can then contain the old code from the "if (addr & 7)" to the end
> of the function.
> 
> 
> 
> I think it would look cleaner, but I don't have a super strong opinion
> about it

As this is a functional fix needed to properly run z16 code I would like to
minimize refactoring. I think we also need a different fix for LPSW(E) (we
should set the BEAR register).  We can do refactoring after we have fixed
everything.

  reply	other threads:[~2024-06-27  9:40 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-27  9:05 [PATCH 1/1] KVM: s390: fix LPSWEY handling Christian Borntraeger
2024-06-27  9:23 ` Claudio Imbrenda
2024-06-27  9:40   ` Christian Borntraeger [this message]
2024-06-27  9:44 ` Thomas Huth
2024-06-27  9:49   ` Christian Borntraeger
2024-06-27  9:57 ` Heiko Carstens
2024-06-28 14:53   ` Christian Borntraeger
2024-06-28 15:02     ` Heiko Carstens
2024-06-28 15:22     ` Claudio Imbrenda
2024-06-28 15:50       ` Christian Borntraeger
2024-06-28 16:55       ` Christian Borntraeger

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=8a894728-aa93-48fe-9556-b1e1013bfd87@linux.ibm.com \
    --to=borntraeger@linux.ibm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mhartmay@linux.ibm.com \
    --cc=svens@linux.ibm.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