From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cornelia Huck Subject: Re: [PATCH v2 12/12] KVM: s390: introduce the format-1 GISA Date: Thu, 25 Jan 2018 17:53:05 +0100 Message-ID: <20180125175305.6a665e84.cohuck@redhat.com> References: <20180125132848.175942-1-borntraeger@de.ibm.com> <20180125132848.175942-13-borntraeger@de.ibm.com> <20180125164751.3034a45d.cohuck@redhat.com> <20180125171742.484d29d1.cohuck@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: David Hildenbrand , KVM , linux-s390 , Janosch Frank , Martin Schwidefsky , Heiko Carstens , Michael Mueller To: Christian Borntraeger Return-path: Received: from mx1.redhat.com ([209.132.183.28]:50494 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751065AbeAYQxL (ORCPT ); Thu, 25 Jan 2018 11:53:11 -0500 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Thu, 25 Jan 2018 17:51:24 +0100 Christian Borntraeger wrote: > On 01/25/2018 05:17 PM, Cornelia Huck wrote: > > On Thu, 25 Jan 2018 17:12:59 +0100 > > Christian Borntraeger wrote: > > > >> On 01/25/2018 04:47 PM, Cornelia Huck wrote: > >>> On Thu, 25 Jan 2018 16:43:27 +0100 > >>> Christian Borntraeger wrote: > >>> > >>>> On 01/25/2018 04:31 PM, David Hildenbrand wrote: > >>>> [...] > >>>>>> struct kvm_s390_vsie { > >>>>>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c > >>>>>> index 68d7eef..efde264 100644 > >>>>>> --- a/arch/s390/kvm/kvm-s390.c > >>>>>> +++ b/arch/s390/kvm/kvm-s390.c > >>>>>> @@ -2518,6 +2518,8 @@ struct kvm_vcpu *kvm_arch_vcpu_create(struct kvm *kvm, > >>>>>> vcpu->arch.sie_block->icpua = id; > >>>>>> spin_lock_init(&vcpu->arch.local_int.lock); > >>>>>> vcpu->arch.sie_block->gd = (u32)(u64)kvm->arch.gisa; > >>>>>> + if (vcpu->arch.sie_block->gd && sclp.has_gisaf) > >>>>>> + vcpu->arch.sie_block->gd |= GISA_FORMAT1; > >>>>>> seqcount_init(&vcpu->arch.cputm_seqcount); > >>>>>> > >>>>>> rc = kvm_vcpu_init(vcpu, kvm, id); > >>>>>> > >>>>> > >>>>> So, what does this bring us? We don't seem to be using any new GISA-1 > >>>>> features. > >>>> > >>>> Preparation for device pass-through interrupt forwarding. > >>>> > >>> > >>> Should we start out with a dual format-0/format-1 gisa block, then? > >>> IIUC, you'll switch to gisa-1 if the facility is there and gisa-1 can > >>> do anything that gisa-0 can do? > >> > >> There might be systems that only have gisa-0, so I think having both makes > >> sense. > >> > > > > Yes, that's what I meant. Just do it earlier in the series - this patch > > feels like an afterthought with no real user. > > I added > > A format-1 can do everything that format-0 can and we will need it > for real HW passthrough. As there are systems with only format-0 > we keep both variants. > > to the patch description. Maybe its now a bit less odd? Also fine with me. (I'll do a proper review round through the patches later.)