public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: "Christian Borntraeger" <borntraeger@de.ibm.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>
Cc: KVM <kvm@vger.kernel.org>,
	Cornelia Huck <cornelia.huck@de.ibm.com>,
	linux-s390 <linux-s390@vger.kernel.org>,
	QingFeng Hao <haoqf@linux.vnet.ibm.com>
Subject: Re: [GIT PULL 9/9] KVM: s390: Inject machine check into the nested guest
Date: Wed, 28 Jun 2017 20:06:51 +0200	[thread overview]
Message-ID: <9ec0f700-c686-44ce-c633-01f2b0ec46c0@redhat.com> (raw)
In-Reply-To: <1498671044-81240-10-git-send-email-borntraeger@de.ibm.com>

On 28.06.2017 19:30, Christian Borntraeger wrote:
> From: QingFeng Hao <haoqf@linux.vnet.ibm.com>
> 
> With vsie feature enabled, kvm can support nested guests (guest-3).
> So inject machine check to the guest-2 if it happens when the nested
> guest is running. And guest-2 will detect the machine check belongs
> to guest-3 and reinject it into guest-3.
> The host (guest-1) tries to inject the machine check to the picked
> destination vcpu if it's a floating machine check.

The subject is confusing. We don't inject anything into the nested guest
here. We just catch machine checks during vsie and inject it into the
ordinary kvm guest.

Are there any SIE specific things to consider here, that may have to be
translated?

> 
> Signed-off-by: QingFeng Hao <haoqf@linux.vnet.ibm.com>
> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
>  arch/s390/kvm/vsie.c | 23 +++++++++++++++++++----
>  1 file changed, 19 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/s390/kvm/vsie.c b/arch/s390/kvm/vsie.c
> index e947657..715c19c 100644
> --- a/arch/s390/kvm/vsie.c
> +++ b/arch/s390/kvm/vsie.c
> @@ -26,13 +26,18 @@
>  
>  struct vsie_page {
>  	struct kvm_s390_sie_block scb_s;	/* 0x0000 */
> +	/*
> +	 * the backup info for machine check. ensure it's at
> +	 * the same offset as that in struct sie_page!
> +	 */
> +	struct mcck_volatile_info mcck_info;    /* 0x0200 */
>  	/* the pinned originial scb */
> -	struct kvm_s390_sie_block *scb_o;	/* 0x0200 */
> +	struct kvm_s390_sie_block *scb_o;	/* 0x0218 */
>  	/* the shadow gmap in use by the vsie_page */
> -	struct gmap *gmap;			/* 0x0208 */
> +	struct gmap *gmap;			/* 0x0220 */
>  	/* address of the last reported fault to guest2 */
> -	unsigned long fault_addr;		/* 0x0210 */
> -	__u8 reserved[0x0700 - 0x0218];		/* 0x0218 */
> +	unsigned long fault_addr;		/* 0x0228 */
> +	__u8 reserved[0x0700 - 0x0230];		/* 0x0230 */
>  	struct kvm_s390_crypto_cb crycb;	/* 0x0700 */
>  	__u8 fac[S390_ARCH_FAC_LIST_SIZE_BYTE];	/* 0x0800 */
>  };
> @@ -801,6 +806,8 @@ static int do_vsie_run(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page)
>  {
>  	struct kvm_s390_sie_block *scb_s = &vsie_page->scb_s;
>  	struct kvm_s390_sie_block *scb_o = vsie_page->scb_o;
> +	struct mcck_volatile_info *mcck_info;
> +	struct sie_page *sie_page;
>  	int rc;
>  
>  	handle_last_fault(vcpu, vsie_page);
> @@ -822,6 +829,14 @@ static int do_vsie_run(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page)
>  	local_irq_enable();
>  	vcpu->srcu_idx = srcu_read_lock(&vcpu->kvm->srcu);
>  
> +	if (rc == -EINTR) {
> +		VCPU_EVENT(vcpu, 3, "%s", "machine check");

We directly have a pointer to vsie_page, why do we need to go back from
scb_s?

Am I missing anything important?



> +		sie_page = container_of(scb_s, struct sie_page, sie_block);
> +		mcck_info = &sie_page->mcck_info;
> +		kvm_s390_reinject_machine_check(vcpu, mcck_info);

This could be a simple

kvm_s390_reinject_machine_check(vcpu, &vsie_page->mcck_info);

no?

> +		return 0;
> +	}
> +
>  	if (rc > 0)
>  		rc = 0; /* we could still have an icpt */
>  	else if (rc == -EFAULT)
> 


-- 

Thanks,

David

  reply	other threads:[~2017-06-28 18:06 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-28 17:30 [GIT PULL 0/9] KVM: s390: fixes and features for 4.13 (via kvm/next) Christian Borntraeger
2017-06-28 17:30 ` [GIT PULL 1/9] KVM: s390: CMMA tracking, ESSA emulation, migration mode Christian Borntraeger
2017-06-28 17:30 ` [GIT PULL 2/9] KVM: s390: ioctls to get and set guest storage attributes Christian Borntraeger
2017-06-28 17:30 ` [GIT PULL 3/9] KVM: s390: implement instruction execution protection for emulated ifetch Christian Borntraeger
2017-06-28 17:30 ` [GIT PULL 4/9] KVM: S390: add new group for flic Christian Borntraeger
2017-06-28 17:30 ` [GIT PULL 5/9] KVM: s390: avoid packed attribute Christian Borntraeger
2017-06-28 17:30 ` [GIT PULL 6/9] s390/nmi: s390: New low level handling for machine check happening in guest Christian Borntraeger
2017-06-28 17:30 ` [GIT PULL 7/9] KVM: s390: Backup the guest's machine check info Christian Borntraeger
2017-06-28 18:20   ` David Hildenbrand
2017-06-28 18:37     ` Christian Borntraeger
2017-06-28 18:56       ` David Hildenbrand
2017-06-28 19:14         ` Christian Borntraeger
2017-06-28 19:46           ` David Hildenbrand
2017-06-28 17:30 ` [GIT PULL 8/9] KVM: s390: Inject machine check into the guest Christian Borntraeger
2017-06-28 17:30 ` [GIT PULL 9/9] KVM: s390: Inject machine check into the nested guest Christian Borntraeger
2017-06-28 18:06   ` David Hildenbrand [this message]
2017-06-28 18:59     ` Christian Borntraeger
2017-06-28 19:08       ` David Hildenbrand
2017-06-28 19:16         ` Christian Borntraeger
2017-06-28 19:17           ` David Hildenbrand
2017-06-29 14:57           ` Christian Borntraeger
2017-06-30 16:30             ` David Hildenbrand
2017-06-28 20:39 ` [GIT PULL 0/9] KVM: s390: fixes and features for 4.13 (via kvm/next) Paolo Bonzini

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=9ec0f700-c686-44ce-c633-01f2b0ec46c0@redhat.com \
    --to=david@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=haoqf@linux.vnet.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@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