Re: [PATCH 02/10] KVM: s390: add the GIB and its related life-cyle functions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 05.11.18 16:08, Cornelia Huck wrote:
> On Mon, 5 Nov 2018 13:06:25 +0100
> Michael Mueller <mimu@xxxxxxxxxxxxx> wrote:
> 
>> On 05.11.18 12:28, Pierre Morel wrote:
>>> On 05/11/2018 10:34, Michael Mueller wrote:  
>>>>
>>>>
>>>> On 31.10.18 09:56, Janosch Frank wrote:  
>>>>> On 25.10.18 14:37, Michael Mueller wrote:  
>>>>>> The GIB (Guest Information Block) links the GISA of all guests
>>>>>> that have adapter interrupts pending. These interrupts cannot be
>>>>>> deliverd because no vcpu of these guests is currently running in
>>>>>> SIE context. Instead, a GIB alert is issued on the host to schedule
>>>>>> these guests to run.
>>>>>>
>>>>>> This mechanism allows to process adapter interrupts for currently
>>>>>> not running guests.
>>>>>>
>>>>>> The GIB is created during host initialization and associated with
>>>>>> the Adapter Interruption Facility in case an Adapter Interruption
>>>>>> Virtualization Facility is available.
>>>>>>
>>>>>> Signed-off-by: Michael Mueller<mimu@xxxxxxxxxxxxx>
>>>>>> ---
>>>>>>   /*
>>>>>>    * sie_page2 has to be allocated as DMA because fac_list, crycb and
>>>>>>    * gisa need 31bit addresses in the sie control block.
>>>>>> @@ -829,6 +838,7 @@ struct kvm_arch{
>>>>>>       /* subset of available cpu features enabled by user space */
>>>>>>       DECLARE_BITMAP(cpu_feat, KVM_S390_VM_CPU_FEAT_NR_BITS);
>>>>>>       struct kvm_s390_gisa *gisa;
>>>>>> +    int gib_in_use;
>>>>>>   };  
>>>>> That's a kvm wide value, right? But here we save it per VM.
>>>>> Is that really necessary or am I missing something?  
>>>>
>>>> It is guest related as a guest might decide in future
>>>> to not use a GISA.
>>>>  
>>>>>  
>>>>  
>>>
>>> If it is guest/GISA related, shouldn't the name be more appropriate?
>>> like gisa_in_use instead of gib_in_use?
>>>
>>> Isn't it redundant with kvm->arch.gisa != 0  
>>
>> No, its meaning is *not* (kvm->arch.gisa != 0)
>>
>> It is a combination of both: The guest uses a GISA *and* the host
>> provides a GIB.
>>
>> Pls. compare with the implementation in kvm_s390_gisa_init()
>>
>>
>> Think about it as: "the GIB is in use in view of the guest"
> 
> Ok, now I'm very confused (keep in mind that I do not have access to
> the architecture.)
> 
> The gisa provides exitless interrupts (interrupts can be injected while
> the guest is running). By the patch description, the gib provides a way
> to process alerts for currently not-running guests. So gisa is a
> pre-req for gib, but setting up the gib may fail (for example, if the
> chsc fails for whatever reason).
> 
> But why are you talking about "view of the guest"? Both are a host
> thing and should be invisible to the guest, right?

In that case view of the guest means KVM management data for that guest,
not code running in the guest context.

gib_in_use is "GISA is used for that VM" && "KVM uses GIB", i.e. the
VM's GISA might end up in the GIB list.

gib_in_use = kvm->arch.gisa && gib

For some reason KVM could remove/not allocate a guest's GISA or the GIB
facility is not available/unused, then this is false.


Attachment: signature.asc
Description: OpenPGP digital signature


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Kernel Development]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Info]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Linux Media]     [Device Mapper]

  Powered by Linux