All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Janosch Frank <frankja@linux.ibm.com>
Cc: kvm@vger.kernel.org, linux-s390@vger.kernel.org,
	thuth@redhat.com, david@redhat.com, borntraeger@de.ibm.com,
	imbrenda@linux.ibm.com, mihajlov@linux.ibm.com,
	mimu@linux.ibm.com, gor@linux.ibm.com
Subject: Re: [RFC 04/37] KVM: s390: protvirt: Add initial lifecycle handling
Date: Mon, 11 Nov 2019 17:25:58 +0100	[thread overview]
Message-ID: <20191111172558.731a0d8b.cohuck@redhat.com> (raw)
In-Reply-To: <8989f705-ce14-7b85-e5b6-6d87803db491@linux.ibm.com>

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

On Fri, 8 Nov 2019 08:36:35 +0100
Janosch Frank <frankja@linux.ibm.com> wrote:

> On 11/7/19 5:29 PM, Cornelia Huck wrote:
> > On Thu, 24 Oct 2019 07:40:26 -0400
> > Janosch Frank <frankja@linux.ibm.com> wrote:

> >> @@ -2157,6 +2164,96 @@ static int kvm_s390_set_cmma_bits(struct kvm *kvm,
> >>  	return r;
> >>  }
> >>  
> >> +#ifdef CONFIG_KVM_S390_PROTECTED_VIRTUALIZATION_HOST
> >> +static int kvm_s390_handle_pv(struct kvm *kvm, struct kvm_pv_cmd *cmd)
> >> +{
> >> +	int r = 0;
> >> +	void __user *argp = (void __user *)cmd->data;
> >> +
> >> +	switch (cmd->cmd) {
> >> +	case KVM_PV_VM_CREATE: {
> >> +		r = kvm_s390_pv_alloc_vm(kvm);
> >> +		if (r)
> >> +			break;
> >> +
> >> +		mutex_lock(&kvm->lock);
> >> +		kvm_s390_vcpu_block_all(kvm);
> >> +		/* FMT 4 SIE needs esca */
> >> +		r = sca_switch_to_extended(kvm);

Looking at this again: this function calls kvm_s390_vcpu_block_all()
(which probably does not hurt), but then kvm_s390_vcpu_unblock_all()...
don't we want to keep the block across pv_create_vm() as well?

Also, can you maybe skip calling this function if we use the esca
already?

> >> +		if (!r)
> >> +			r = kvm_s390_pv_create_vm(kvm);
> >> +		kvm_s390_vcpu_unblock_all(kvm);
> >> +		mutex_unlock(&kvm->lock);
> >> +		break;
> >> +	}
> >> +	case KVM_PV_VM_DESTROY: {
> >> +		/* All VCPUs have to be destroyed before this call. */
> >> +		mutex_lock(&kvm->lock);
> >> +		kvm_s390_vcpu_block_all(kvm);
> >> +		r = kvm_s390_pv_destroy_vm(kvm);
> >> +		if (!r)
> >> +			kvm_s390_pv_dealloc_vm(kvm);
> >> +		kvm_s390_vcpu_unblock_all(kvm);
> >> +		mutex_unlock(&kvm->lock);
> >> +		break;
> >> +	}  
> > 
> > Would be helpful to have some code that shows when/how these are called
> > - do you have any plans to post something soon?  
> 
> Qemu patches will be in internal review soonish and afterwards I'll post
> them upstream

Great, looking forward to this :)

> 
> > 
> > (...)
> >   
> >> @@ -2529,6 +2642,9 @@ void kvm_arch_vcpu_destroy(struct kvm_vcpu *vcpu)
> >>  
> >>  	if (vcpu->kvm->arch.use_cmma)
> >>  		kvm_s390_vcpu_unsetup_cmma(vcpu);
> >> +	if (IS_ENABLED(CONFIG_KVM_S390_PROTECTED_VIRTUALIZATION_HOST) &&
> >> +	    kvm_s390_pv_handle_cpu(vcpu))  
> > 
> > I was a bit confused by that function name... maybe
> > kvm_s390_pv_cpu_get_handle()?  
> 
> Sure
> 
> > 
> > Also, if this always returns 0 if the config option is off, you
> > probably don't need to check for that option?  
> 
> Hmm, if we decide to remove the config option altogether then it's not
> needed anyway and I think that's what Christian wants.

That would be fine with me as well (I have not yet thought about all
implications there, though.)

> 
> >   
> >> +		kvm_s390_pv_destroy_cpu(vcpu);
> >>  	free_page((unsigned long)(vcpu->arch.sie_block));
> >>  
> >>  	kvm_vcpu_uninit(vcpu);
> >> @@ -2555,8 +2671,13 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
> >>  {
> >>  	kvm_free_vcpus(kvm);
> >>  	sca_dispose(kvm);
> >> -	debug_unregister(kvm->arch.dbf);
> >>  	kvm_s390_gisa_destroy(kvm);
> >> +	if (IS_ENABLED(CONFIG_KVM_S390_PROTECTED_VIRTUALIZATION_HOST) &&
> >> +	    kvm_s390_pv_is_protected(kvm)) {
> >> +		kvm_s390_pv_destroy_vm(kvm);
> >> +		kvm_s390_pv_dealloc_vm(kvm);  
> > 
> > It seems the pv vm can be either destroyed via the ioctl above or in
> > the course of normal vm destruction. When is which way supposed to be
> > used? Also, it seems kvm_s390_pv_destroy_vm() can fail -- can that be a
> > problem in this code path?  
> 
> On a reboot we need to tear down the protected VM and boot from
> unprotected mode again. If the VM shuts down we go through this cleanup
> path. If it fails the kernel will loose the memory that was allocated to
> start the VM.

Shouldn't you at least log a moan in that case? Hopefully, this happens
very rarely, but the dbf will be gone...

> 
> >   
> >> +	}
> >> +	debug_unregister(kvm->arch.dbf);
> >>  	free_page((unsigned long)kvm->arch.sie_page2);
> >>  	if (!kvm_is_ucontrol(kvm))
> >>  		gmap_remove(kvm->arch.gmap);  
> > 
> > (...)
> >   
> >> diff --git a/arch/s390/kvm/kvm-s390.h b/arch/s390/kvm/kvm-s390.h
> >> index 6d9448dbd052..0d61dcc51f0e 100644
> >> --- a/arch/s390/kvm/kvm-s390.h
> >> +++ b/arch/s390/kvm/kvm-s390.h
> >> @@ -196,6 +196,53 @@ static inline int kvm_s390_user_cpu_state_ctrl(struct kvm *kvm)
> >>  	return kvm->arch.user_cpu_state_ctrl != 0;
> >>  }
> >>  
> >> +#ifdef CONFIG_KVM_S390_PROTECTED_VIRTUALIZATION_HOST
> >> +/* implemented in pv.c */
> >> +void kvm_s390_pv_unpin(struct kvm *kvm);
> >> +void kvm_s390_pv_dealloc_vm(struct kvm *kvm);
> >> +int kvm_s390_pv_alloc_vm(struct kvm *kvm);
> >> +int kvm_s390_pv_create_vm(struct kvm *kvm);
> >> +int kvm_s390_pv_create_cpu(struct kvm_vcpu *vcpu);
> >> +int kvm_s390_pv_destroy_vm(struct kvm *kvm);
> >> +int kvm_s390_pv_destroy_cpu(struct kvm_vcpu *vcpu);
> >> +int kvm_s390_pv_set_sec_parms(struct kvm *kvm, void *hdr, u64 length);
> >> +int kvm_s390_pv_unpack(struct kvm *kvm, unsigned long addr, unsigned long size,
> >> +		       unsigned long tweak);
> >> +int kvm_s390_pv_verify(struct kvm *kvm);
> >> +
> >> +static inline bool kvm_s390_pv_is_protected(struct kvm *kvm)
> >> +{
> >> +	return !!kvm->arch.pv.handle;
> >> +}
> >> +
> >> +static inline u64 kvm_s390_pv_handle(struct kvm *kvm)  
> > 
> > This function name is less confusing than the one below, but maybe also
> > rename this to kvm_s390_pv_get_handle() for consistency?  
> 
> kvm_s390_pv_kvm_handle?

kvm_s390_pv_kvm_get_handle() would mirror the cpu function :) </bikeshed>

> 
> >   
> >> +{
> >> +	return kvm->arch.pv.handle;
> >> +}
> >> +
> >> +static inline u64 kvm_s390_pv_handle_cpu(struct kvm_vcpu *vcpu)
> >> +{
> >> +	return vcpu->arch.pv.handle;
> >> +}
> >> +#else
> >> +static inline void kvm_s390_pv_unpin(struct kvm *kvm) {}
> >> +static inline void kvm_s390_pv_dealloc_vm(struct kvm *kvm) {}
> >> +static inline int kvm_s390_pv_alloc_vm(struct kvm *kvm) { return 0; }
> >> +static inline int kvm_s390_pv_create_vm(struct kvm *kvm) { return 0; }
> >> +static inline int kvm_s390_pv_create_cpu(struct kvm_vcpu *vcpu) { return 0; }
> >> +static inline int kvm_s390_pv_destroy_vm(struct kvm *kvm) { return 0; }
> >> +static inline int kvm_s390_pv_destroy_cpu(struct kvm_vcpu *vcpu) { return 0; }
> >> +static inline int kvm_s390_pv_set_sec_parms(struct kvm *kvm,
> >> +					    u64 origin, u64 length) { return 0; }
> >> +static inline int kvm_s390_pv_unpack(struct kvm *kvm, unsigned long addr,
> >> +				     unsigned long size,  unsigned long tweak)
> >> +{ return 0; }
> >> +static inline int kvm_s390_pv_verify(struct kvm *kvm) { return 0; }
> >> +static inline bool kvm_s390_pv_is_protected(struct kvm *kvm) { return 0; }
> >> +static inline u64 kvm_s390_pv_handle(struct kvm *kvm) { return 0; }
> >> +static inline u64 kvm_s390_pv_handle_cpu(struct kvm_vcpu *vcpu) { return 0; }
> >> +#endif
> >> +
> >>  /* implemented in interrupt.c */
> >>  int kvm_s390_handle_wait(struct kvm_vcpu *vcpu);
> >>  void kvm_s390_vcpu_wakeup(struct kvm_vcpu *vcpu);  
> > 
> > (...)
> >   
> >> +int kvm_s390_pv_create_cpu(struct kvm_vcpu *vcpu)
> >> +{
> >> +	int rc;
> >> +	struct uv_cb_csc uvcb = {
> >> +		.header.cmd = UVC_CMD_CREATE_SEC_CPU,
> >> +		.header.len = sizeof(uvcb),
> >> +	};
> >> +
> >> +	/* EEXIST and ENOENT? */  
> > 
> > ?  
> 
> I was asking myself if EEXIST or ENOENT would be better error values
> than EINVAL.

EEXIST might be better, but I don't really like ENOENT.

> 
> >   
> >> +	if (kvm_s390_pv_handle_cpu(vcpu))
> >> +		return -EINVAL;
> >> +
> >> +	vcpu->arch.pv.stor_base = __get_free_pages(GFP_KERNEL,
> >> +						   get_order(uv_info.guest_cpu_stor_len));
> >> +	if (!vcpu->arch.pv.stor_base)
> >> +		return -ENOMEM;
> >> +
> >> +	/* Input */
> >> +	uvcb.guest_handle = kvm_s390_pv_handle(vcpu->kvm);
> >> +	uvcb.num = vcpu->arch.sie_block->icpua;
> >> +	uvcb.state_origin = (u64)vcpu->arch.sie_block;
> >> +	uvcb.stor_origin = (u64)vcpu->arch.pv.stor_base;
> >> +
> >> +	rc = uv_call(0, (u64)&uvcb);
> >> +	VCPU_EVENT(vcpu, 3, "PROTVIRT CREATE VCPU: cpu %d handle %llx rc %x rrc %x",
> >> +		   vcpu->vcpu_id, uvcb.cpu_handle, uvcb.header.rc,
> >> +		   uvcb.header.rrc);
> >> +
> >> +	/* Output */
> >> +	vcpu->arch.pv.handle = uvcb.cpu_handle;
> >> +	vcpu->arch.sie_block->pv_handle_cpu = uvcb.cpu_handle;
> >> +	vcpu->arch.sie_block->pv_handle_config = kvm_s390_pv_handle(vcpu->kvm);
> >> +	vcpu->arch.sie_block->sdf = 2;
> >> +	if (!rc)
> >> +		return 0;
> >> +
> >> +	kvm_s390_pv_destroy_cpu(vcpu);
> >> +	return -EINVAL;
> >> +}  
> > 
> > (...)
> > 
> > Only a quick readthrough, as this patch is longish.
> >   
> 
> 


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

  reply	other threads:[~2019-11-11 16:26 UTC|newest]

Thread overview: 213+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-24 11:40 [RFC 00/37] KVM: s390: Add support for protected VMs Janosch Frank
2019-10-24 11:40 ` [RFC 01/37] DOCUMENTATION: protvirt: Protected virtual machine introduction Janosch Frank
2019-11-01  8:18   ` Christian Borntraeger
2019-11-04 14:18   ` Cornelia Huck
2019-11-12 14:38     ` Janosch Frank
2019-10-24 11:40 ` [RFC 02/37] s390/protvirt: introduce host side setup Janosch Frank
2019-10-24 13:25   ` David Hildenbrand
2019-10-24 13:27     ` David Hildenbrand
2019-10-24 13:40       ` Christian Borntraeger
2019-10-24 15:52         ` David Hildenbrand
2019-10-24 16:30           ` Claudio Imbrenda
2019-10-24 16:54             ` David Hildenbrand
2019-10-28 14:54   ` Cornelia Huck
2019-10-28 20:20     ` Christian Borntraeger
2019-11-01  8:53   ` Christian Borntraeger
2019-11-04 14:26     ` Cornelia Huck
2019-11-12 14:47       ` Janosch Frank
2019-11-04 15:54   ` Cornelia Huck
2019-11-04 17:50     ` Christian Borntraeger
2019-11-05  9:26       ` Cornelia Huck
2019-11-08 12:14         ` Thomas Huth
2019-10-24 11:40 ` [RFC 03/37] s390/protvirt: add ultravisor initialization Janosch Frank
2019-10-25  9:21   ` David Hildenbrand
2019-10-28 15:48     ` Vasily Gorbik
2019-10-28 15:54       ` David Hildenbrand
2019-11-01 10:07   ` Christian Borntraeger
2019-11-07 15:28   ` Cornelia Huck
2019-11-07 15:32     ` Janosch Frank
2019-10-24 11:40 ` [RFC 04/37] KVM: s390: protvirt: Add initial lifecycle handling Janosch Frank
2019-10-25  8:58   ` David Hildenbrand
2019-10-25  9:02     ` David Hildenbrand
2019-11-04  8:18   ` Christian Borntraeger
2019-11-04  8:41     ` Janosch Frank
2019-11-07 16:29   ` Cornelia Huck
2019-11-08  7:36     ` Janosch Frank
2019-11-11 16:25       ` Cornelia Huck [this message]
2019-11-11 16:39         ` Janosch Frank
2019-11-11 16:54           ` Cornelia Huck
2019-11-13 10:05         ` Thomas Huth
2019-11-08 13:44   ` Thomas Huth
2019-11-13 10:28   ` Thomas Huth
2019-11-13 11:34     ` Janosch Frank
2019-11-13 14:03     ` [PATCH] Fix unpack Janosch Frank
2019-11-13 14:19       ` Thomas Huth
2019-11-13 14:36       ` Cornelia Huck
2019-11-13 11:48   ` [RFC 04/37] KVM: s390: protvirt: Add initial lifecycle handling Cornelia Huck
2019-10-24 11:40 ` [RFC 05/37] s390: KVM: Export PV handle to gmap Janosch Frank
2019-10-25  9:04   ` David Hildenbrand
2019-10-24 11:40 ` [RFC 06/37] s390: UV: Add import and export to UV library Janosch Frank
2019-10-25  8:31   ` David Hildenbrand
2019-10-25  8:39     ` Janosch Frank
2019-10-25  8:40       ` David Hildenbrand
2019-10-25  8:42         ` Janosch Frank
2019-11-01 11:26   ` Christian Borntraeger
2019-11-01 12:25     ` Janosch Frank
2019-11-01 12:39       ` Christian Borntraeger
2019-11-01 12:42   ` Christian Borntraeger
2019-11-11 16:40   ` Cornelia Huck
2019-11-11 16:56     ` Janosch Frank
2019-10-24 11:40 ` [RFC 07/37] KVM: s390: protvirt: Secure memory is not mergeable Janosch Frank
2019-10-24 16:07   ` David Hildenbrand
2019-10-24 16:33     ` Claudio Imbrenda
2019-10-24 16:49       ` David Hildenbrand
2019-10-25  7:18     ` Janosch Frank
2019-10-25  8:04       ` David Hildenbrand
2019-10-25  8:20         ` Janosch Frank
2019-10-25  7:46   ` David Hildenbrand
2019-10-25  8:24   ` [RFC v2] " Janosch Frank
2019-11-01 13:02     ` Christian Borntraeger
2019-11-04 14:32     ` David Hildenbrand
2019-11-04 14:36       ` Janosch Frank
2019-11-04 14:38         ` David Hildenbrand
2019-11-13 12:23     ` Thomas Huth
2019-11-13 15:54       ` Janosch Frank
2019-10-24 11:40 ` [RFC 08/37] KVM: s390: add missing include in gmap.h Janosch Frank
2019-10-25  8:24   ` David Hildenbrand
2019-11-13 12:27   ` Thomas Huth
2019-10-24 11:40 ` [RFC 09/37] KVM: s390: protvirt: Implement on-demand pinning Janosch Frank
2019-10-25  8:49   ` David Hildenbrand
2019-10-31 15:41     ` Christian Borntraeger
2019-10-31 17:30       ` David Hildenbrand
2019-10-31 20:57         ` Janosch Frank
2019-11-04 10:19           ` David Hildenbrand
2019-11-04 10:25             ` Janosch Frank
2019-11-04 10:27               ` David Hildenbrand
2019-11-04 13:58             ` Christian Borntraeger
2019-11-04 14:08               ` David Hildenbrand
2019-11-04 14:42                 ` David Hildenbrand
2019-11-04 17:17                   ` Cornelia Huck
2019-11-04 17:44                     ` David Hildenbrand
2019-11-04 18:38                     ` David Hildenbrand
2019-11-05  9:15                       ` Cornelia Huck
2019-11-01  8:50         ` Claudio Imbrenda
2019-11-04 10:22           ` David Hildenbrand
2019-11-02  8:53   ` Christian Borntraeger
2019-11-04 14:17   ` David Hildenbrand
2019-10-24 11:40 ` [RFC 10/37] s390: add (non)secure page access exceptions handlers Janosch Frank
2019-10-24 11:40 ` [RFC 11/37] DOCUMENTATION: protvirt: Interrupt injection Janosch Frank
2019-11-14 13:09   ` Cornelia Huck
2019-11-14 13:25     ` Claudio Imbrenda
2019-11-14 13:47       ` Cornelia Huck
2019-11-14 16:33         ` Janosch Frank
2019-10-24 11:40 ` [RFC 12/37] KVM: s390: protvirt: Handle SE notification interceptions Janosch Frank
2019-10-30 15:50   ` David Hildenbrand
2019-10-30 17:58     ` Janosch Frank
2019-11-05 18:04   ` Cornelia Huck
2019-11-05 18:15     ` Christian Borntraeger
2019-11-05 18:37       ` Cornelia Huck
2019-10-24 11:40 ` [RFC 13/37] KVM: s390: protvirt: Add interruption injection controls Janosch Frank
2019-10-30 15:53   ` David Hildenbrand
2019-10-31  8:48     ` Michael Mueller
2019-10-31  9:15       ` David Hildenbrand
2019-10-31 12:10         ` Michael Mueller
2019-11-05 17:51   ` Cornelia Huck
2019-11-07 12:42     ` Michael Mueller
2019-11-14 11:48   ` Thomas Huth
2019-10-24 11:40 ` [RFC 14/37] KVM: s390: protvirt: Implement interruption injection Janosch Frank
2019-11-04 10:29   ` David Hildenbrand
2019-11-04 14:05     ` Christian Borntraeger
2019-11-04 14:23       ` David Hildenbrand
2019-11-14 12:07   ` Thomas Huth
2019-10-24 11:40 ` [RFC 15/37] KVM: s390: protvirt: Add machine-check interruption injection controls Janosch Frank
2019-11-13 14:49   ` Thomas Huth
2019-11-13 15:57     ` Michael Mueller
2019-10-24 11:40 ` [RFC 16/37] KVM: s390: protvirt: Implement machine-check interruption injection Janosch Frank
2019-11-05 18:11   ` Cornelia Huck
2019-10-24 11:40 ` [RFC 17/37] DOCUMENTATION: protvirt: Instruction emulation Janosch Frank
2019-11-14 15:15   ` Cornelia Huck
2019-11-14 15:20     ` Claudio Imbrenda
2019-11-14 15:41       ` Cornelia Huck
2019-11-14 15:55         ` Janosch Frank
2019-11-14 16:03           ` Cornelia Huck
2019-11-14 16:18             ` Janosch Frank
2019-10-24 11:40 ` [RFC 18/37] KVM: s390: protvirt: Handle spec exception loops Janosch Frank
2019-11-14 14:22   ` Thomas Huth
2019-10-24 11:40 ` [RFC 19/37] KVM: s390: protvirt: Add new gprs location handling Janosch Frank
2019-11-04 11:25   ` David Hildenbrand
2019-11-05 12:01     ` Christian Borntraeger
2019-11-05 12:39       ` Janosch Frank
2019-11-05 13:55         ` David Hildenbrand
2019-11-05 14:11           ` Janosch Frank
2019-11-05 14:18             ` David Hildenbrand
2019-11-14 14:46               ` Thomas Huth
2019-11-14 14:44   ` Thomas Huth
2019-11-14 15:56     ` Janosch Frank
2019-10-24 11:40 ` [RFC 20/37] KVM: S390: protvirt: Introduce instruction data area bounce buffer Janosch Frank
2019-11-14 15:36   ` Thomas Huth
2019-11-14 16:04     ` Janosch Frank
2019-11-14 16:21     ` [PATCH] Fixup sida bouncing Janosch Frank
2019-11-15  8:19       ` Thomas Huth
2019-11-15  8:50         ` Janosch Frank
2019-11-15  9:21           ` Thomas Huth
2019-10-24 11:40 ` [RFC 21/37] KVM: S390: protvirt: Instruction emulation Janosch Frank
2019-11-14 15:38   ` Cornelia Huck
2019-11-14 16:00     ` Janosch Frank
2019-11-14 16:05       ` Cornelia Huck
2019-10-24 11:40 ` [RFC 22/37] KVM: s390: protvirt: Add SCLP handling Janosch Frank
2019-10-24 11:40 ` [RFC 23/37] KVM: s390: protvirt: Make sure prefix is always protected Janosch Frank
2019-11-18 16:39   ` Cornelia Huck
2019-11-19  8:11     ` Janosch Frank
2019-11-19  9:45       ` Cornelia Huck
2019-11-19 10:08         ` Janosch Frank
2019-11-19 10:18   ` David Hildenbrand
2019-11-19 11:36     ` Janosch Frank
2019-10-24 11:40 ` [RFC 24/37] KVM: s390: protvirt: Write sthyi data to instruction data area Janosch Frank
2019-11-15  8:04   ` Thomas Huth
2019-11-15 10:16     ` Janosch Frank
2019-11-15 10:21       ` Thomas Huth
2019-11-15 12:17         ` [PATCH] SIDAD macro fixup Janosch Frank
2019-10-24 11:40 ` [RFC 25/37] KVM: s390: protvirt: STSI handling Janosch Frank
2019-11-15  8:27   ` Thomas Huth
2019-10-24 11:40 ` [RFC 26/37] KVM: s390: protvirt: Only sync fmt4 registers Janosch Frank
2019-11-15  9:02   ` Thomas Huth
2019-11-15 10:01     ` Janosch Frank
2019-10-24 11:40 ` [RFC 27/37] KVM: s390: protvirt: SIGP handling Janosch Frank
2019-10-30 18:29   ` David Hildenbrand
2019-11-15 11:15   ` Thomas Huth
2019-10-24 11:40 ` [RFC 28/37] KVM: s390: protvirt: Add program exception injection Janosch Frank
2019-10-24 11:40 ` [RFC 29/37] KVM: s390: protvirt: Sync pv state Janosch Frank
2019-11-15  9:36   ` Thomas Huth
2019-11-15  9:59     ` Janosch Frank
2019-10-24 11:40 ` [RFC 30/37] DOCUMENTATION: protvirt: Diag 308 IPL Janosch Frank
2019-11-06 16:48   ` Cornelia Huck
2019-11-06 17:05     ` Janosch Frank
2019-11-06 17:37       ` Cornelia Huck
2019-11-06 21:02         ` Janosch Frank
2019-11-07  8:53           ` Cornelia Huck
2019-11-07  8:59             ` Janosch Frank
2019-10-24 11:40 ` [RFC 31/37] KVM: s390: protvirt: Add diag 308 subcode 8 - 10 handling Janosch Frank
2019-11-15 10:04   ` Thomas Huth
2019-11-15 10:20     ` Janosch Frank
2019-11-15 10:27       ` Thomas Huth
2019-11-15 11:29         ` Janosch Frank
2019-10-24 11:40 ` [RFC 32/37] KVM: s390: protvirt: UV calls diag308 0, 1 Janosch Frank
2019-11-15 10:07   ` Thomas Huth
2019-11-15 11:39     ` Janosch Frank
2019-11-15 13:30       ` Thomas Huth
2019-11-15 14:08         ` Janosch Frank
2019-10-24 11:40 ` [RFC 33/37] KVM: s390: Introduce VCPU reset IOCTL Janosch Frank
2019-11-15 10:47   ` Thomas Huth
2019-11-15 13:06     ` Janosch Frank
2019-11-15 13:18       ` Thomas Huth
2019-10-24 11:40 ` [RFC 34/37] KVM: s390: protvirt: Report CPU state to Ultravisor Janosch Frank
2019-10-24 11:40 ` [RFC 35/37] KVM: s390: Fix cpu reset local IRQ clearing Janosch Frank
2019-11-15 11:23   ` Thomas Huth
2019-11-15 11:37     ` Janosch Frank
2019-10-24 11:40 ` [RFC 36/37] KVM: s390: protvirt: Support cmd 5 operation state Janosch Frank
2019-11-15 11:25   ` Thomas Huth
2019-11-18 17:38   ` Cornelia Huck
2019-11-19  8:13     ` Janosch Frank
2019-11-19 10:23       ` Cornelia Huck
2019-11-19 11:40         ` Janosch Frank
2019-10-24 11:40 ` [RFC 37/37] KVM: s390: protvirt: Add UV debug trace Janosch Frank

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=20191111172558.731a0d8b.cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mihajlov@linux.ibm.com \
    --cc=mimu@linux.ibm.com \
    --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.