On Wed, 31 Oct 2018 15:05:09 +0100
Pierre Morel <pmorel@xxxxxxxxxxxxx> wrote:
> On 25/10/2018 14:37, Michael Mueller wrote:
> > +int kvm_s390_gisc_register(struct kvm *kvm, u32 gisc)
> > +{
> > + if (!kvm->arch.gib_in_use)
> > + return -ENODEV;
> > + if (gisc > MAX_ISC)
> > + return -EINVAL;
> > +
> > + spin_lock(&kvm->arch.iam_ref_lock);
> > + if (kvm->arch.iam_ref_count[gisc] == 0)
> > + kvm->arch.iam |= 0x80 >> gisc;
> > + kvm->arch.iam_ref_count[gisc]++;
> > + spin_unlock(&kvm->arch.iam_ref_lock);
>
> I am not sure it brings something to handle multiple registrations per VM.
> ISC are defined pro adapter types.
> If we once will multiplex different types pro ISC we would certainly
> handle it through other means.
Do you have an idea about upcoming adapter types (e.g. adding support
for virtio)?
The isc space is very limited and has on top of that priority ordering;
I don't know if the gisa firmware code does have isc-specific semantics
as well.
>
> Not having it will simplify the code.
>
> > +
> > + return gib->nisc;
> > +}
>
> hum.
> Will nisc change ?
> It is hard coded in the call to kvm_s390_gib_init(GAL_ISC)
Should the nisc maybe be explicitly tied to the adapter type? Or is
that a global thing? If yes, does this need any differentiation?
IIRC, the aiv is a general "adapter interrupt virtualization" facility,
so different adapter types may be present.
>
> the NISC is a global value, if the only way to retrieve it is to
> register we need to keep it local in the space of the registering caller.
> I mean, registering to the GIB alert and registering an interruption are
> two different things and can be done in different functions.
>
> Shouldn't we just need the GAL_ISC definition?
