Re: [PATCH 08/10] KVM: s390: add functions to (un)register GISC with GISA

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

 





On 31.10.18 17:35, Pierre Morel wrote:
On 31/10/2018 15:21, Cornelia Huck wrote:
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.

Sorry, I think I confused ISC and AISM.
So after more thinking I take it back, this is interesting, sorry.

To be generic, we can not know in advance which ISC the guest will use when registering an interrupt, so we need this algorithm somewhere.

Yes, that's the point. And we cannot clear a IAM bit in the restore mask until the last adapter unregisters its ISC.



Do you have an idea about upcoming adapter types (e.g. adding support
for virtio)?

I am not aware of this.


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.

Yes it does.



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?

It is global and do not need differentiation pro adapter.


IIRC, the aiv is a general "adapter interrupt virtualization" facility,
so different adapter types may be present.

Yes, and it is easier if the host use the same host ISC value for all of them.
After all the type of adapter is not important for the GIB



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?







[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