On Mon, 5 Nov 2018 17:16:18 +0100
Michael Mueller <mimu@xxxxxxxxxxxxx> wrote:
> 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?
> >
> Think of "kvm data structures provided by the host for a specific guest"
> instead of guest in terms
> of a kvm consumer like qemu. On that level it is transparent.
>
> The arch itself allows guests with and without GISAs running in parallel
> on the host either
> with or without a GIB. The combinations provide different capabilities
> to a guest. A guest
> without GISA or GIB e.g. cannot use exitless pass-through interrupts.
>
> When running under vSIE we have no GISA, thus certain code paths like:
>
> static int vcpu_pre_run(struct kvm_vcpu *vcpu)
> {
> ...
>
> atomic_inc(&vcpu->kvm->arch.vcpus_in_sie);
> if (vcpu->kvm->arch.gib_in_use)
> vcpu->kvm->arch.gisa->iam = 0;
>
> ...
> }
>
> need to be case specific.
>
> The value of "kvm->arch.gib_in_use" respresents the value of
> "kvm->arch.gisa != 0 && gib !=0"
>
> "gib_in_use" means. This specific kvm guest is using the GIB and it's
> "mechanics" (firmware code)
>
> I hope this helps to clarify and not to confuse even more... ;)
Thanks, it was helpful :)
Quick question: is there any reasonably expected failure case for the
chsc if aiv is actually provided? I.e., are the failure cases for
setting up the gib (other than 'no aiv') edge cases anyway?
