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
Michael
