All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Janosch Frank <frankja@linux.ibm.com>
Cc: Thomas Huth <thuth@redhat.com>,
	kvm@vger.kernel.org, borntraeger@de.ibm.com,
	linux-s390@vger.kernel.org, david@redhat.com
Subject: Re: [PATCH v4] KVM: s390: Add new reset vcpu API
Date: Fri, 10 Jan 2020 10:07:22 +0100	[thread overview]
Message-ID: <20200110100722.6aad4fdd.cohuck@redhat.com> (raw)
In-Reply-To: <90f65536-c2bb-9234-aef4-7941d477369e@linux.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 3255 bytes --]

On Fri, 10 Jan 2020 09:43:33 +0100
Janosch Frank <frankja@linux.ibm.com> wrote:

> On 1/10/20 8:14 AM, Janosch Frank wrote:
> > On 1/10/20 8:03 AM, Thomas Huth wrote:  
> >> On 09/01/2020 18.51, Janosch Frank wrote:  

> >>> Reworded explanation:
> >>> I can't use a fallthrough, because the UV will reject the normal reset
> >>> if we do an initial reset (same goes for the clear reset). To address
> >>> this issue, I added a boolean to the normal and initial reset functions
> >>> which tells the function if it was called directly or was called because
> >>> of the fallthrough.
> >>>
> >>> Only if called directly a UV call for the reset is done, that way we can
> >>> keep the fallthrough.  
> >>
> >> Sounds complicated. And do we need the fallthrough stuff here at all?
> >> What about doing something like:  
> > 
> > That would work and I thought about it, it just comes down to taste :-)
> > I don't have any strong feelings for a specific implementation.  

(...)

> +	if (kvm_s390_pv_handle_cpu(vcpu) && !chain) {

I find this 'chain' thingy a bit unwieldy...

> +		rc = uv_cmd_nodata(kvm_s390_pv_handle_cpu(vcpu),
> +				   UVC_CMD_CPU_RESET, &ret);
> +		VCPU_EVENT(vcpu, 3, "PROTVIRT RESET NORMAL VCPU: cpu %d rc %x rrc %x",
> +			   vcpu->vcpu_id, ret >> 16, ret & 0x0000ffff);
> +	}
> +
> +	return rc;
>  }

(...)

> 
>  	case KVM_S390_CLEAR_RESET:
>  		r = kvm_arch_vcpu_ioctl_clear_reset(vcpu);
> +		if (r)
> +			break;
>  		/* fallthrough */
>  	case KVM_S390_INITIAL_RESET:
> -		r = kvm_arch_vcpu_ioctl_initial_reset(vcpu);
> +		r = kvm_arch_vcpu_ioctl_initial_reset(vcpu, ioctl !=
> KVM_S390_INITIAL_RESET);
> +		if (r)
> +			break;
>  		/* fallthrough */
>  	case KVM_S390_NORMAL_RESET:
> -		r = kvm_arch_vcpu_ioctl_normal_reset(vcpu);
> +		r = kvm_arch_vcpu_ioctl_normal_reset(vcpu, ioctl !=
> KVM_S390_NORMAL_RESET);

...especially looking at the invocations.

>  		break;
>  	case KVM_SET_ONE_REG:
>  	case KVM_GET_ONE_REG: {
> 

<bikeshed>
What about the following?

static void _do_normal_reset(struct kvm_vcpu *vcpu)
{
	/* do normal reset */
}

static int kvm_arch_vcpu_ioctl_normal_reset(struct kvm_vcpu *vcpu)
{
	_do_normal_reset(vcpu);
        if (kvm_s390_pv_handle_cpu(vcpu)) {
		/* do protected virt normal reset */
	}
}

static void _do_initial_reset(struct kvm_vcpu *vcpu)
{
	/* do initial reset */
}

static int kvm_arch_vcpu_ioctl_initial_reset(struct kvm_vcpu *vcpu)
{
	_do_initial_reset(vcpu);
	if (kvm_set_pv_handle_cpu(vcpu)) {
		/* do protected virt initial reset */
	}
	_do_normal_reset(vcpu);
}

static void _do_clear_reset(struct kvm_vcpu *vcpu)
{
	/* do clear reset */
}

static int kvm_arch_vcpu_ioctl_clear_reset(struct kvm_vcpu *vcpu)
{
	_do_clear_reset(vcpu);
	if (kvm_set_pv_handle_cpu(vcpu)) {
		/* do protected virt clear reset */
	}
	_do_initial_reset(vcpu);
	_do_normal_reset(vcpu);
}

And call the *_ioctl_* functions directly without fallthrough.

The nice thing about this is that it makes the call chain explicit and
does not require parameters.

The drawback is that we need more functions, and that it looks a bit
overcomplicated before the pv stuff is added.

</bikeshed>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2020-01-10  9:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-09 15:56 [PATCH v4] KVM: s390: Add new reset vcpu API Janosch Frank
2020-01-09 17:08 ` Cornelia Huck
2020-01-09 17:51   ` Janosch Frank
2020-01-10  7:03     ` Thomas Huth
2020-01-10  7:14       ` Janosch Frank
2020-01-10  8:43         ` Janosch Frank
2020-01-10  8:49           ` Thomas Huth
2020-01-10  9:05             ` Christian Borntraeger
2020-01-10  9:07           ` Cornelia Huck [this message]
  -- strict thread matches above, loose matches on Subject: below --
2019-12-05 12:19 [PATCH v3] " Cornelia Huck
2019-12-05 12:28 ` [PATCH v4] " Janosch Frank
2019-12-05 12:35   ` Cornelia Huck
2019-12-05 12:50   ` Thomas Huth

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=20200110100722.6aad4fdd.cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.