kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: Janosch Frank <frankja@linux.ibm.com>, Cornelia Huck <cohuck@redhat.com>
Cc: 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 08:03:24 +0100	[thread overview]
Message-ID: <f18955c0-4002-c494-b14e-1b9733aad20e@redhat.com> (raw)
In-Reply-To: <f79b523e-f3e8-95b8-c242-1e7ca0083012@linux.ibm.com>


[-- Attachment #1.1: Type: text/plain, Size: 2863 bytes --]

On 09/01/2020 18.51, Janosch Frank wrote:
> On 1/9/20 6:08 PM, Cornelia Huck wrote:
>> On Thu,  9 Jan 2020 10:56:01 -0500
>> Janosch Frank <frankja@linux.ibm.com> wrote:
>>
>>> The architecture states that we need to reset local IRQs for all CPU
>>> resets. Because the old reset interface did not support the normal CPU
>>> reset we never did that on a normal reset.
>>>
>>> Let's implement an interface for the missing normal and clear resets
>>> and reset all local IRQs, registers and control structures as stated
>>> in the architecture.
>>>
>>> Userspace might already reset the registers via the vcpu run struct,
>>> but as we need the interface for the interrupt clearing part anyway,
>>> we implement the resets fully and don't rely on userspace to reset the
>>> rest.
>>>
>>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
>>> ---
>>>
>>> I dropped the reviews, as I changed quite a lot.  
>>>
>>> Keep in mind, that now we'll need a new parameter in normal and
>>> initial reset for protected virtualization to indicate that we need to
>>> do the reset via the UV call. The Ultravisor does only accept the
>>> needed reset, not any subset resets.
>>
>> In the interface, or externally?
> 
> ?
> 
>>
>> [Apologies, but the details of the protected virt stuff are no longer
>> in my cache.
> 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:

static int kvm_arch_vcpu_ioctl_normal_reset(struct kvm_vcpu *vcpu)
{
	...
}

static int kvm_arch_vcpu_ioctl_initial_reset(struct kvm_vcpu *vcpu)
{
	kvm_arch_vcpu_ioctl_normal_reset(vcpu);
	...
}

static int kvm_arch_vcpu_ioctl_clear_reset(struct kvm_vcpu *vcpu)
{
	kvm_arch_vcpu_ioctl_initial_reset(vcpu);
	...
}

...

	case KVM_S390_CLEAR_RESET:
		r = kvm_arch_vcpu_ioctl_clear_reset(vcpu);
		if (!r && protected) {
			r = uv_cmd_nodata(...,
 				UVC_CMD_CPU_RESET_CLEAR, ...);
		}
		break;
 	case KVM_S390_INITIAL_RESET:
 		r = kvm_arch_vcpu_ioctl_initial_reset(vcpu);
		if (!r && protected) {
			r = uv_cmd_nodata(...,
 				UVC_CMD_CPU_RESET_INITIAL, ...);
		}
	case KVM_S390_NORMAL_RESET:
		r = kvm_arch_vcpu_ioctl_normal_reset(vcpu);
		if (!r && protected) {
			r = uv_cmd_nodata(...,
 				UVC_CMD_CPU_RESET, ...);
		}
 		break;

... or does that not work due to some other constraints that I've missed?

 Thomas


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

  reply	other threads:[~2020-01-10  7:03 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 [this message]
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
  -- 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=f18955c0-4002-c494-b14e-1b9733aad20e@redhat.com \
    --to=thuth@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).