From: Cornelia Huck <cohuck@redhat.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: KVM <kvm@vger.kernel.org>,
linux-s390 <linux-s390@vger.kernel.org>,
Janosch Frank <frankja@linux.vnet.ibm.com>,
David Hildenbrand <david@redhat.com>,
Michael Mueller <mimu@linux.vnet.ibm.com>
Subject: Re: [PATCH 06/12] KVM: s390: exploit GISA and AIV for emulated interrupts
Date: Thu, 18 Jan 2018 19:10:16 +0100 [thread overview]
Message-ID: <20180118191016.22947066.cohuck@redhat.com> (raw)
In-Reply-To: <20180116200217.211897-7-borntraeger@de.ibm.com>
On Tue, 16 Jan 2018 21:02:11 +0100
Christian Borntraeger <borntraeger@de.ibm.com> wrote:
> From: Michael Mueller <mimu@linux.vnet.ibm.com>
>
> The adapter interruption virtualization (AIV) facility is an
> optional facility that comes with functionality expected to increase
> the performance of adapter interrupt handling for both emulated and
> passed-through adapter interrupts. With AIV, adapter interrupts can be
> delivered to the guest without exiting SIE.
>
> This patch provides some preparations for using AIV for emulated adapter
> interrupts (inclusive virtio) if it's available. When using AIV, the
> interrupts are delivered at the so called GISA by setting the bit
> corresponding to its Interruption Subclass (ISC) in the Interruption
> Pending Mask (IPM) instead of inserting a node into the floating interrupt
> list.
>
> To keep the change reasonably small, the handling of this new state is
> deferred in get_all_floating_irqs and handle_tpi. This patch concentrates
> on the code handling enqueuement of emulated adapter interrupts, and their
> delivery to the guest.
>
> Note that care is still required for adapter interrupts using AIV,
> because there is no guarantee that AIV is going to deliver the adapter
> interrupts pending at the GISA (consider all vcpus idle). When delivering
> GISA adapter interrupts by the host (usual mechanism) special attention
> is required to honor interrupt priorities.
>
> Empirical results show that the time window between making an interrupt
> pending at the GISA and doing kvm_s390_deliver_pending_interrupts is
> sufficient for a guest with at least moderate cpu activity to get adapter
> interrupts delivered within the SIE, and potentially save some SIE exits
> (if not other deliverable interrupts).
>
> The code will be activated with a follow-up patch.
>
> Signed-off-by: Michael Mueller <mimu@linux.vnet.ibm.com>
> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
> arch/s390/kvm/interrupt.c | 104 +++++++++++++++++++++++++++++++++++++---------
> arch/s390/kvm/kvm-s390.c | 8 ++++
> arch/s390/kvm/kvm-s390.h | 3 ++
> 3 files changed, 96 insertions(+), 19 deletions(-)
>
> @@ -935,23 +960,27 @@ static int __must_check __deliver_io(struct kvm_vcpu *vcpu,
> spin_unlock(&fi->lock);
>
> if (inti) {
> - rc = put_guest_lc(vcpu, inti->io.subchannel_id,
> - (u16 *)__LC_SUBCHANNEL_ID);
> - rc |= put_guest_lc(vcpu, inti->io.subchannel_nr,
> - (u16 *)__LC_SUBCHANNEL_NR);
> - rc |= put_guest_lc(vcpu, inti->io.io_int_parm,
> - (u32 *)__LC_IO_INT_PARM);
> - rc |= put_guest_lc(vcpu, inti->io.io_int_word,
> - (u32 *)__LC_IO_INT_WORD);
> - rc |= write_guest_lc(vcpu, __LC_IO_OLD_PSW,
> - &vcpu->arch.sie_block->gpsw,
> - sizeof(psw_t));
> - rc |= read_guest_lc(vcpu, __LC_IO_NEW_PSW,
> - &vcpu->arch.sie_block->gpsw,
> - sizeof(psw_t));
> + rc = __do_deliver_io(vcpu, &(inti->io));
> kfree(inti);
> + goto out;
> }
>
> + if (vcpu->kvm->arch.gisa) {
> + if (kvm_s390_gisa_tac_ipm_gisc(vcpu->kvm->arch.gisa, isc)) {
I think this could benefit from a comment here or there; e.g. that you
manually deliver interrupts here that have not yet been injected via
gisa. This is complex enough to confuse people having to look at this
some years from now :)
> + VCPU_EVENT(vcpu, 4, "%s isc %u", "deliver: I/O (AI/gisa)", isc);
> + memset(&io, 0, sizeof(io));
> + io.io_int_word = (isc << 27) | 0x80000000;
> + vcpu->stat.deliver_io_int++;
> + trace_kvm_s390_deliver_interrupt(vcpu->vcpu_id,
> + KVM_S390_INT_IO(1, 0, 0, 0),
> + ((__u32)io.subchannel_id << 16) |
> + io.subchannel_nr,
> + ((__u64)io.io_int_parm << 32) |
> + io.io_int_word);
> + rc = __do_deliver_io(vcpu, &io);
> + }
> + }
> +out:
> return rc ? -EFAULT : 0;
> }
>
The general approach seems sane from what I can see (unless I'm already
too tired...)
next prev parent reply other threads:[~2018-01-18 18:10 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-16 20:02 [PATCH 00/12] KVM: s390: exitless interrupt support for KVM Christian Borntraeger
2018-01-16 20:02 ` [PATCH 01/12] KVM: s390: reverse bit ordering of irqs in pending mask Christian Borntraeger
2018-01-16 20:18 ` David Hildenbrand
2018-01-17 10:12 ` Christian Borntraeger
2018-01-18 16:50 ` Cornelia Huck
2018-01-16 20:02 ` [PATCH 02/12] KVM: s390: define GISA format-0 data structure Christian Borntraeger
2018-01-16 20:25 ` David Hildenbrand
2018-01-17 7:57 ` Heiko Carstens
2018-01-18 15:49 ` Michael Mueller
2018-01-18 20:47 ` David Hildenbrand
2018-01-19 10:12 ` Heiko Carstens
2018-01-19 10:17 ` David Hildenbrand
2018-01-19 10:20 ` Heiko Carstens
2018-01-19 10:29 ` Cornelia Huck
2018-01-19 11:28 ` David Hildenbrand
2018-01-16 20:02 ` [PATCH 03/12] s390/bitops: add test_and_clear_bit_inv() Christian Borntraeger
2018-01-16 20:13 ` David Hildenbrand
2018-01-18 16:54 ` Cornelia Huck
2018-01-16 20:02 ` [PATCH 04/12] KVM: s390: implement GISA IPM related primitives Christian Borntraeger
2018-01-17 14:35 ` David Hildenbrand
2018-01-18 14:29 ` Michael Mueller
2018-01-18 14:33 ` David Hildenbrand
2018-01-18 15:58 ` Michael Mueller
2018-01-18 20:45 ` David Hildenbrand
2018-01-19 10:11 ` Heiko Carstens
2018-01-19 10:16 ` David Hildenbrand
2018-01-19 10:17 ` Christian Borntraeger
2018-01-16 20:02 ` [PATCH 05/12] s390/css: expose the AIV facility Christian Borntraeger
2018-01-17 15:19 ` David Hildenbrand
2018-01-18 12:02 ` Michael Mueller
2018-01-18 17:54 ` Cornelia Huck
2018-01-25 11:42 ` Christian Borntraeger
2018-01-25 12:00 ` Cornelia Huck
2018-01-25 12:04 ` Christian Borntraeger
2018-01-25 15:13 ` Heiko Carstens
2018-01-16 20:02 ` [PATCH 06/12] KVM: s390: exploit GISA and AIV for emulated interrupts Christian Borntraeger
2018-01-17 8:14 ` Heiko Carstens
2018-01-18 18:10 ` Cornelia Huck [this message]
2018-01-16 20:02 ` [PATCH 07/12] KVM: s390: abstract adapter interruption word generation from ISC Christian Borntraeger
2018-01-18 18:11 ` Cornelia Huck
2018-01-16 20:02 ` [PATCH 08/12] KVM: s390: add GISA interrupts to FLIC ioctl interface Christian Borntraeger
2018-01-16 20:02 ` [PATCH 09/12] KVM: s390: make kvm_s390_get_io_int() aware of GISA Christian Borntraeger
2018-01-16 20:02 ` [PATCH 10/12] KVM: s390: activate GISA for emulated interrupts Christian Borntraeger
2018-01-16 20:02 ` [PATCH 11/12] s390/sclp: expose the GISA format facility Christian Borntraeger
2018-01-16 20:13 ` David Hildenbrand
2018-01-16 20:02 ` [PATCH 12/12] KVM: s390: introduce the format-1 GISA Christian Borntraeger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180118191016.22947066.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=david@redhat.com \
--cc=frankja@linux.vnet.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mimu@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).