On 01/25/2018 05:17 PM, Cornelia Huck wrote:
> On Thu, 25 Jan 2018 17:12:59 +0100
> Christian Borntraeger <borntraeger@xxxxxxxxxx> wrote:
>
>> On 01/25/2018 04:47 PM, Cornelia Huck wrote:
>>> On Thu, 25 Jan 2018 16:43:27 +0100
>>> Christian Borntraeger <borntraeger@xxxxxxxxxx> 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?
