kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] KVM: s390: Add new reset vcpu API
@ 2019-11-29 14:21 Janosch Frank
  2019-11-29 14:31 ` David Hildenbrand
  0 siblings, 1 reply; 9+ messages in thread
From: Janosch Frank @ 2019-11-29 14:21 UTC (permalink / raw)
  To: kvm; +Cc: thuth, david, borntraeger, mihajlov, cohuck, linux-s390

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.

Now that we have a new interface, let's properly clear out local IRQs
and let this commit be a reminder.

Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
---
 arch/s390/kvm/kvm-s390.c | 25 ++++++++++++++++++++++++-
 include/uapi/linux/kvm.h |  7 +++++++
 2 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index d9e6bf3d54f0..2f74ff46b176 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -529,6 +529,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
 	case KVM_CAP_S390_CMMA_MIGRATION:
 	case KVM_CAP_S390_AIS:
 	case KVM_CAP_S390_AIS_MIGRATION:
+	case KVM_CAP_S390_VCPU_RESETS:
 		r = 1;
 		break;
 	case KVM_CAP_S390_HPAGE_1M:
@@ -3293,6 +3294,25 @@ static int kvm_arch_vcpu_ioctl_initial_reset(struct kvm_vcpu *vcpu)
 	return 0;
 }
 
+static int kvm_arch_vcpu_ioctl_reset(struct kvm_vcpu *vcpu, unsigned long type)
+{
+	int rc = -EINVAL;
+
+	switch (type) {
+	case KVM_S390_VCPU_RESET_NORMAL:
+		rc = 0;
+		kvm_clear_async_pf_completion_queue(vcpu);
+		kvm_s390_clear_local_irqs(vcpu);
+		break;
+	case KVM_S390_VCPU_RESET_INITIAL:
+		/* fallthrough */
+	case KVM_S390_VCPU_RESET_CLEAR:
+		rc = kvm_arch_vcpu_ioctl_initial_reset(vcpu);
+		break;
+	}
+	return rc;
+}
+
 int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
 {
 	vcpu_load(vcpu);
@@ -4364,7 +4384,10 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
 		break;
 	}
 	case KVM_S390_INITIAL_RESET:
-		r = kvm_arch_vcpu_ioctl_initial_reset(vcpu);
+		arg = KVM_S390_VCPU_RESET_INITIAL;
+		/* fallthrough */
+	case KVM_S390_VCPU_RESET:
+		r = kvm_arch_vcpu_ioctl_reset(vcpu, arg);
 		break;
 	case KVM_SET_ONE_REG:
 	case KVM_GET_ONE_REG: {
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 52641d8ca9e8..6da16b1f2c86 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1000,6 +1000,7 @@ struct kvm_ppc_resize_hpt {
 #define KVM_CAP_PMU_EVENT_FILTER 173
 #define KVM_CAP_ARM_IRQ_LINE_LAYOUT_2 174
 #define KVM_CAP_HYPERV_DIRECT_TLBFLUSH 175
+#define KVM_CAP_S390_VCPU_RESETS 180
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
@@ -1461,6 +1462,12 @@ struct kvm_enc_region {
 /* Available with KVM_CAP_ARM_SVE */
 #define KVM_ARM_VCPU_FINALIZE	  _IOW(KVMIO,  0xc2, int)
 
+#define KVM_S390_VCPU_RESET_NORMAL	0
+#define KVM_S390_VCPU_RESET_INITIAL	1
+#define KVM_S390_VCPU_RESET_CLEAR	2
+
+#define KVM_S390_VCPU_RESET    _IO(KVMIO,   0xc3)
+
 /* Secure Encrypted Virtualization command */
 enum sev_cmd_id {
 	/* Guest initialization commands */
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH] KVM: s390: Add new reset vcpu API
  2019-11-29 14:21 [PATCH] KVM: s390: Add new reset vcpu API Janosch Frank
@ 2019-11-29 14:31 ` David Hildenbrand
  2019-11-29 14:33   ` Janosch Frank
  0 siblings, 1 reply; 9+ messages in thread
From: David Hildenbrand @ 2019-11-29 14:31 UTC (permalink / raw)
  To: Janosch Frank, kvm; +Cc: thuth, borntraeger, mihajlov, cohuck, linux-s390

On 29.11.19 15:21, Janosch Frank 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.
> 
> Now that we have a new interface, let's properly clear out local IRQs
> and let this commit be a reminder.
> 
> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
> ---
>  arch/s390/kvm/kvm-s390.c | 25 ++++++++++++++++++++++++-
>  include/uapi/linux/kvm.h |  7 +++++++
>  2 files changed, 31 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index d9e6bf3d54f0..2f74ff46b176 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -529,6 +529,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>  	case KVM_CAP_S390_CMMA_MIGRATION:
>  	case KVM_CAP_S390_AIS:
>  	case KVM_CAP_S390_AIS_MIGRATION:
> +	case KVM_CAP_S390_VCPU_RESETS:
>  		r = 1;
>  		break;
>  	case KVM_CAP_S390_HPAGE_1M:
> @@ -3293,6 +3294,25 @@ static int kvm_arch_vcpu_ioctl_initial_reset(struct kvm_vcpu *vcpu)
>  	return 0;
>  }
>  
> +static int kvm_arch_vcpu_ioctl_reset(struct kvm_vcpu *vcpu, unsigned long type)
> +{
> +	int rc = -EINVAL;
> +
> +	switch (type) {
> +	case KVM_S390_VCPU_RESET_NORMAL:
> +		rc = 0;
> +		kvm_clear_async_pf_completion_queue(vcpu);
> +		kvm_s390_clear_local_irqs(vcpu);
> +		break;
> +	case KVM_S390_VCPU_RESET_INITIAL:
> +		/* fallthrough */
> +	case KVM_S390_VCPU_RESET_CLEAR:
> +		rc = kvm_arch_vcpu_ioctl_initial_reset(vcpu);

As we now have two interfaces to achieve the same thing (initial reset),
I do wonder if we should simply introduce

KVM_S390_NORMAL_RESET
KVM_S390_CLEAR_RESET

instead ...

Then you can do KVM_S390_NORMAL_RESET for the bugfix and
KVM_S390_CLEAR_RESET later for PV.

Does anything speak against that?

-- 
Thanks,

David / dhildenb


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] KVM: s390: Add new reset vcpu API
  2019-11-29 14:31 ` David Hildenbrand
@ 2019-11-29 14:33   ` Janosch Frank
  2019-11-29 14:33     ` David Hildenbrand
  0 siblings, 1 reply; 9+ messages in thread
From: Janosch Frank @ 2019-11-29 14:33 UTC (permalink / raw)
  To: David Hildenbrand, kvm; +Cc: thuth, borntraeger, mihajlov, cohuck, linux-s390


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

On 11/29/19 3:31 PM, David Hildenbrand wrote:
> On 29.11.19 15:21, Janosch Frank 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.
>>
>> Now that we have a new interface, let's properly clear out local IRQs
>> and let this commit be a reminder.
>>
>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
>> ---
>>  arch/s390/kvm/kvm-s390.c | 25 ++++++++++++++++++++++++-
>>  include/uapi/linux/kvm.h |  7 +++++++
>>  2 files changed, 31 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
>> index d9e6bf3d54f0..2f74ff46b176 100644
>> --- a/arch/s390/kvm/kvm-s390.c
>> +++ b/arch/s390/kvm/kvm-s390.c
>> @@ -529,6 +529,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>>  	case KVM_CAP_S390_CMMA_MIGRATION:
>>  	case KVM_CAP_S390_AIS:
>>  	case KVM_CAP_S390_AIS_MIGRATION:
>> +	case KVM_CAP_S390_VCPU_RESETS:
>>  		r = 1;
>>  		break;
>>  	case KVM_CAP_S390_HPAGE_1M:
>> @@ -3293,6 +3294,25 @@ static int kvm_arch_vcpu_ioctl_initial_reset(struct kvm_vcpu *vcpu)
>>  	return 0;
>>  }
>>  
>> +static int kvm_arch_vcpu_ioctl_reset(struct kvm_vcpu *vcpu, unsigned long type)
>> +{
>> +	int rc = -EINVAL;
>> +
>> +	switch (type) {
>> +	case KVM_S390_VCPU_RESET_NORMAL:
>> +		rc = 0;
>> +		kvm_clear_async_pf_completion_queue(vcpu);
>> +		kvm_s390_clear_local_irqs(vcpu);
>> +		break;
>> +	case KVM_S390_VCPU_RESET_INITIAL:
>> +		/* fallthrough */
>> +	case KVM_S390_VCPU_RESET_CLEAR:
>> +		rc = kvm_arch_vcpu_ioctl_initial_reset(vcpu);
> 
> As we now have two interfaces to achieve the same thing (initial reset),
> I do wonder if we should simply introduce
> 
> KVM_S390_NORMAL_RESET
> KVM_S390_CLEAR_RESET
> 
> instead ...
> 
> Then you can do KVM_S390_NORMAL_RESET for the bugfix and
> KVM_S390_CLEAR_RESET later for PV.
> 
> Does anything speak against that?

Apart from loosing one more ioctl number probably not



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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] KVM: s390: Add new reset vcpu API
  2019-11-29 14:33   ` Janosch Frank
@ 2019-11-29 14:33     ` David Hildenbrand
  2019-11-29 14:38       ` Janosch Frank
  0 siblings, 1 reply; 9+ messages in thread
From: David Hildenbrand @ 2019-11-29 14:33 UTC (permalink / raw)
  To: Janosch Frank, kvm; +Cc: thuth, borntraeger, mihajlov, cohuck, linux-s390

On 29.11.19 15:33, Janosch Frank wrote:
> On 11/29/19 3:31 PM, David Hildenbrand wrote:
>> On 29.11.19 15:21, Janosch Frank 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.
>>>
>>> Now that we have a new interface, let's properly clear out local IRQs
>>> and let this commit be a reminder.
>>>
>>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
>>> ---
>>>  arch/s390/kvm/kvm-s390.c | 25 ++++++++++++++++++++++++-
>>>  include/uapi/linux/kvm.h |  7 +++++++
>>>  2 files changed, 31 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
>>> index d9e6bf3d54f0..2f74ff46b176 100644
>>> --- a/arch/s390/kvm/kvm-s390.c
>>> +++ b/arch/s390/kvm/kvm-s390.c
>>> @@ -529,6 +529,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>>>  	case KVM_CAP_S390_CMMA_MIGRATION:
>>>  	case KVM_CAP_S390_AIS:
>>>  	case KVM_CAP_S390_AIS_MIGRATION:
>>> +	case KVM_CAP_S390_VCPU_RESETS:
>>>  		r = 1;
>>>  		break;
>>>  	case KVM_CAP_S390_HPAGE_1M:
>>> @@ -3293,6 +3294,25 @@ static int kvm_arch_vcpu_ioctl_initial_reset(struct kvm_vcpu *vcpu)
>>>  	return 0;
>>>  }
>>>  
>>> +static int kvm_arch_vcpu_ioctl_reset(struct kvm_vcpu *vcpu, unsigned long type)
>>> +{
>>> +	int rc = -EINVAL;
>>> +
>>> +	switch (type) {
>>> +	case KVM_S390_VCPU_RESET_NORMAL:
>>> +		rc = 0;
>>> +		kvm_clear_async_pf_completion_queue(vcpu);
>>> +		kvm_s390_clear_local_irqs(vcpu);
>>> +		break;
>>> +	case KVM_S390_VCPU_RESET_INITIAL:
>>> +		/* fallthrough */
>>> +	case KVM_S390_VCPU_RESET_CLEAR:
>>> +		rc = kvm_arch_vcpu_ioctl_initial_reset(vcpu);
>>
>> As we now have two interfaces to achieve the same thing (initial reset),
>> I do wonder if we should simply introduce
>>
>> KVM_S390_NORMAL_RESET
>> KVM_S390_CLEAR_RESET
>>
>> instead ...
>>
>> Then you can do KVM_S390_NORMAL_RESET for the bugfix and
>> KVM_S390_CLEAR_RESET later for PV.
>>
>> Does anything speak against that?
> 
> Apart from loosing one more ioctl number probably not

Do we care? (I think not, but maybe I am missing something :) )

-- 
Thanks,

David / dhildenb


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] KVM: s390: Add new reset vcpu API
  2019-11-29 14:33     ` David Hildenbrand
@ 2019-11-29 14:38       ` Janosch Frank
  2019-11-29 14:39         ` Christian Borntraeger
  0 siblings, 1 reply; 9+ messages in thread
From: Janosch Frank @ 2019-11-29 14:38 UTC (permalink / raw)
  To: David Hildenbrand, kvm; +Cc: thuth, borntraeger, mihajlov, cohuck, linux-s390


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

On 11/29/19 3:33 PM, David Hildenbrand wrote:
> On 29.11.19 15:33, Janosch Frank wrote:
>> On 11/29/19 3:31 PM, David Hildenbrand wrote:
>>> On 29.11.19 15:21, Janosch Frank 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.
>>>>
>>>> Now that we have a new interface, let's properly clear out local IRQs
>>>> and let this commit be a reminder.
>>>>
>>>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
>>>> ---
>>>>  arch/s390/kvm/kvm-s390.c | 25 ++++++++++++++++++++++++-
>>>>  include/uapi/linux/kvm.h |  7 +++++++
>>>>  2 files changed, 31 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
>>>> index d9e6bf3d54f0..2f74ff46b176 100644
>>>> --- a/arch/s390/kvm/kvm-s390.c
>>>> +++ b/arch/s390/kvm/kvm-s390.c
>>>> @@ -529,6 +529,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>>>>  	case KVM_CAP_S390_CMMA_MIGRATION:
>>>>  	case KVM_CAP_S390_AIS:
>>>>  	case KVM_CAP_S390_AIS_MIGRATION:
>>>> +	case KVM_CAP_S390_VCPU_RESETS:
>>>>  		r = 1;
>>>>  		break;
>>>>  	case KVM_CAP_S390_HPAGE_1M:
>>>> @@ -3293,6 +3294,25 @@ static int kvm_arch_vcpu_ioctl_initial_reset(struct kvm_vcpu *vcpu)
>>>>  	return 0;
>>>>  }
>>>>  
>>>> +static int kvm_arch_vcpu_ioctl_reset(struct kvm_vcpu *vcpu, unsigned long type)
>>>> +{
>>>> +	int rc = -EINVAL;
>>>> +
>>>> +	switch (type) {
>>>> +	case KVM_S390_VCPU_RESET_NORMAL:
>>>> +		rc = 0;
>>>> +		kvm_clear_async_pf_completion_queue(vcpu);
>>>> +		kvm_s390_clear_local_irqs(vcpu);
>>>> +		break;
>>>> +	case KVM_S390_VCPU_RESET_INITIAL:
>>>> +		/* fallthrough */
>>>> +	case KVM_S390_VCPU_RESET_CLEAR:
>>>> +		rc = kvm_arch_vcpu_ioctl_initial_reset(vcpu);
>>>
>>> As we now have two interfaces to achieve the same thing (initial reset),
>>> I do wonder if we should simply introduce
>>>
>>> KVM_S390_NORMAL_RESET
>>> KVM_S390_CLEAR_RESET
>>>
>>> instead ...
>>>
>>> Then you can do KVM_S390_NORMAL_RESET for the bugfix and
>>> KVM_S390_CLEAR_RESET later for PV.
>>>
>>> Does anything speak against that?
>>
>> Apart from loosing one more ioctl number probably not
> 
> Do we care? (I think not, but maybe I am missing something :) )
> 

I don't, maybe somebody else does
Btw. I'm struggling to find a good name for the capability:
KVM_CAP_S390_VCPU_ADDITIONAL_RESETS ?


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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] KVM: s390: Add new reset vcpu API
  2019-11-29 14:38       ` Janosch Frank
@ 2019-11-29 14:39         ` Christian Borntraeger
  2019-11-29 14:48           ` David Hildenbrand
  0 siblings, 1 reply; 9+ messages in thread
From: Christian Borntraeger @ 2019-11-29 14:39 UTC (permalink / raw)
  To: Janosch Frank, David Hildenbrand, kvm; +Cc: thuth, mihajlov, cohuck, linux-s390



On 29.11.19 15:38, Janosch Frank wrote:
[...]
>>>> As we now have two interfaces to achieve the same thing (initial reset),
>>>> I do wonder if we should simply introduce
>>>>
>>>> KVM_S390_NORMAL_RESET
>>>> KVM_S390_CLEAR_RESET
>>>>
>>>> instead ...
>>>>
>>>> Then you can do KVM_S390_NORMAL_RESET for the bugfix and
>>>> KVM_S390_CLEAR_RESET later for PV.
>>>>
>>>> Does anything speak against that?
>>>
>>> Apart from loosing one more ioctl number probably not
>>
>> Do we care? (I think not, but maybe I am missing something :) )
>>
> 
> I don't, maybe somebody else does
> Btw. I'm struggling to find a good name for the capability:
> KVM_CAP_S390_VCPU_ADDITIONAL_RESETS ?

KVM_CAP_S390_VCPU_RESETS ?



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] KVM: s390: Add new reset vcpu API
  2019-11-29 14:39         ` Christian Borntraeger
@ 2019-11-29 14:48           ` David Hildenbrand
  2019-11-29 14:57             ` Janosch Frank
  0 siblings, 1 reply; 9+ messages in thread
From: David Hildenbrand @ 2019-11-29 14:48 UTC (permalink / raw)
  To: Christian Borntraeger, Janosch Frank, kvm
  Cc: thuth, mihajlov, cohuck, linux-s390

On 29.11.19 15:39, Christian Borntraeger wrote:
> 
> 
> On 29.11.19 15:38, Janosch Frank wrote:
> [...]
>>>>> As we now have two interfaces to achieve the same thing (initial reset),
>>>>> I do wonder if we should simply introduce
>>>>>
>>>>> KVM_S390_NORMAL_RESET
>>>>> KVM_S390_CLEAR_RESET
>>>>>
>>>>> instead ...
>>>>>
>>>>> Then you can do KVM_S390_NORMAL_RESET for the bugfix and
>>>>> KVM_S390_CLEAR_RESET later for PV.
>>>>>
>>>>> Does anything speak against that?
>>>>
>>>> Apart from loosing one more ioctl number probably not
>>>
>>> Do we care? (I think not, but maybe I am missing something :) )
>>>
>>
>> I don't, maybe somebody else does
>> Btw. I'm struggling to find a good name for the capability:
>> KVM_CAP_S390_VCPU_ADDITIONAL_RESETS ?
> 
> KVM_CAP_S390_VCPU_RESETS ?

Either that or two separate ones if you're not going to introduce them
at the same time ...

-- 
Thanks,

David / dhildenb


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] KVM: s390: Add new reset vcpu API
  2019-11-29 14:48           ` David Hildenbrand
@ 2019-11-29 14:57             ` Janosch Frank
  2019-12-02  8:54               ` Cornelia Huck
  0 siblings, 1 reply; 9+ messages in thread
From: Janosch Frank @ 2019-11-29 14:57 UTC (permalink / raw)
  To: David Hildenbrand, Christian Borntraeger, kvm
  Cc: thuth, mihajlov, cohuck, linux-s390


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

On 11/29/19 3:48 PM, David Hildenbrand wrote:
> On 29.11.19 15:39, Christian Borntraeger wrote:
>>
>>
>> On 29.11.19 15:38, Janosch Frank wrote:
>> [...]
>>>>>> As we now have two interfaces to achieve the same thing (initial reset),
>>>>>> I do wonder if we should simply introduce
>>>>>>
>>>>>> KVM_S390_NORMAL_RESET
>>>>>> KVM_S390_CLEAR_RESET
>>>>>>
>>>>>> instead ...
>>>>>>
>>>>>> Then you can do KVM_S390_NORMAL_RESET for the bugfix and
>>>>>> KVM_S390_CLEAR_RESET later for PV.
>>>>>>
>>>>>> Does anything speak against that?
>>>>>
>>>>> Apart from loosing one more ioctl number probably not
>>>>
>>>> Do we care? (I think not, but maybe I am missing something :) )
>>>>
>>>
>>> I don't, maybe somebody else does
>>> Btw. I'm struggling to find a good name for the capability:
>>> KVM_CAP_S390_VCPU_ADDITIONAL_RESETS ?
>>
>> KVM_CAP_S390_VCPU_RESETS ?
> 
> Either that or two separate ones if you're not going to introduce them
> at the same time ...
> 

This is starting to get messy...


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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] KVM: s390: Add new reset vcpu API
  2019-11-29 14:57             ` Janosch Frank
@ 2019-12-02  8:54               ` Cornelia Huck
  0 siblings, 0 replies; 9+ messages in thread
From: Cornelia Huck @ 2019-12-02  8:54 UTC (permalink / raw)
  To: Janosch Frank
  Cc: David Hildenbrand, Christian Borntraeger, kvm, thuth, mihajlov,
	linux-s390

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

On Fri, 29 Nov 2019 15:57:25 +0100
Janosch Frank <frankja@linux.ibm.com> wrote:

> On 11/29/19 3:48 PM, David Hildenbrand wrote:
> > On 29.11.19 15:39, Christian Borntraeger wrote:  
> >>
> >>
> >> On 29.11.19 15:38, Janosch Frank wrote:
> >> [...]  
> >>>>>> As we now have two interfaces to achieve the same thing (initial reset),
> >>>>>> I do wonder if we should simply introduce
> >>>>>>
> >>>>>> KVM_S390_NORMAL_RESET
> >>>>>> KVM_S390_CLEAR_RESET
> >>>>>>
> >>>>>> instead ...
> >>>>>>
> >>>>>> Then you can do KVM_S390_NORMAL_RESET for the bugfix and
> >>>>>> KVM_S390_CLEAR_RESET later for PV.
> >>>>>>
> >>>>>> Does anything speak against that?  
> >>>>>
> >>>>> Apart from loosing one more ioctl number probably not  
> >>>>
> >>>> Do we care? (I think not, but maybe I am missing something :) )
> >>>>  
> >>>
> >>> I don't, maybe somebody else does
> >>> Btw. I'm struggling to find a good name for the capability:
> >>> KVM_CAP_S390_VCPU_ADDITIONAL_RESETS ?  
> >>
> >> KVM_CAP_S390_VCPU_RESETS ?  
> > 
> > Either that or two separate ones if you're not going to introduce them
> > at the same time ...
> >   
> 
> This is starting to get messy...

In order to reduce the mess, simply introduce them at the same time? I
might be missing something, but is there anything speaking against it,
as you can simply invoke the initial reset handler for clear reset for
now?

Also:
KVM_CAP_S390_ENHANCED_VCPU_RESETS, maybe?

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2019-12-02  8:54 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-29 14:21 [PATCH] KVM: s390: Add new reset vcpu API Janosch Frank
2019-11-29 14:31 ` David Hildenbrand
2019-11-29 14:33   ` Janosch Frank
2019-11-29 14:33     ` David Hildenbrand
2019-11-29 14:38       ` Janosch Frank
2019-11-29 14:39         ` Christian Borntraeger
2019-11-29 14:48           ` David Hildenbrand
2019-11-29 14:57             ` Janosch Frank
2019-12-02  8:54               ` Cornelia Huck

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).