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 --]
next prev parent 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).