From: Cornelia Huck <cornelia.huck@de.ibm.com>
To: Avi Kivity <avi@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
kvm <kvm@vger.kernel.org>,
patches@linaro.org, Marcelo Tosatti <mtosatti@redhat.com>,
qemu-devel@nongnu.org, Alexander Graf <agraf@suse.de>,
Jan Kiszka <jan.kiszka@web.de>
Subject: Re: [Qemu-devel] [PATCH] kvm: Move kvm_allows_irq0_override() to target-i386
Date: Mon, 23 Jul 2012 15:06:00 +0200 [thread overview]
Message-ID: <20120723150600.57f2aab5@BR9GNB5Z> (raw)
In-Reply-To: <500D4129.8030200@redhat.com>
On Mon, 23 Jul 2012 15:18:49 +0300
Avi Kivity <avi@redhat.com> wrote:
> > So, for example, if a specific subchannel (=device) has pending status
> > and an I/O interrupt is to be generated, this interrupt remains pending
> > until an arbitrary cpu is enabled for I/O interrupts. If several cpus
> > are enabled for I/O interrupts, any of them may be interrupted.
>
> This may be costly to emulate. On x86 we do not have access to a
> guest's interrupt status while it is running. Is this not the case for
> s390?
>
> Oh, let me guess. You write some interrupt descriptor in memory
> somewhere, issue one of your famous instructions, and the hardware finds
> a guest vcpu and injects the interrupt.
Basically, we have some flags in our control block we can set so that
the cpu drops out of SIE whenever external/I/O/... interrupts are
enabled and then have the host do the lowcore updates, psw swaps, etc.
>
> x86 has a "least priority" mode which is similar to what you're
> describing, but I don't think we emulate it correctly.
>
> > When an
> > I/O interrupt is delivered on a cpu, the cpu's lowcore contains the
> > interrupt payload which defines the subchannel (=device) the interrupt
> > is for.
> >
> > Any idea on how this architecture can be married with the irqchip
> > concept is welcome. If all else fails, would a special irqfd concept
> > for !irqchip be acceptable?
>
> I don't see an issue. You need an arch-specific irqfd configuration
> ioctl (or your own data field in the existing ioctl) that defines the
> payload. Then the kernel installs a poll function on that eventfd that,
> when called, does the magic sequence needed to get the interrupt there.
If extending the existing ioctl is acceptable, I think we will go that
route.
> While you don't have an irqchip, you do have asynchronous interrupt
> injection, yes? That's what irqchip really is all about.
You mean injection via ioctl() that is asynchronous to vcpu execution?
Yes, although we use a different ioctl than the others.
Cornelia
next prev parent reply other threads:[~2012-07-23 13:06 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-20 19:14 [Qemu-devel] [PATCH] kvm: Move kvm_allows_irq0_override() to target-i386 Peter Maydell
2012-07-21 6:57 ` Jan Kiszka
2012-07-21 8:54 ` Peter Maydell
2012-07-21 9:14 ` Jan Kiszka
2012-07-21 9:30 ` Peter Maydell
2012-07-21 9:44 ` Jan Kiszka
2012-07-21 9:56 ` Peter Maydell
2012-07-21 10:22 ` Jan Kiszka
2012-07-21 10:53 ` Peter Maydell
2012-07-21 11:08 ` Jan Kiszka
2012-07-21 12:17 ` Peter Maydell
2012-07-21 12:35 ` Jan Kiszka
2012-07-21 12:57 ` Peter Maydell
2012-07-21 13:16 ` Jan Kiszka
2012-07-23 12:04 ` Cornelia Huck
2012-07-23 12:18 ` Avi Kivity
2012-07-23 12:25 ` Peter Maydell
2012-07-23 12:31 ` Avi Kivity
2012-07-23 12:34 ` Avi Kivity
2012-07-23 13:06 ` Cornelia Huck [this message]
2012-07-23 13:14 ` Avi Kivity
2012-07-23 13:55 ` Cornelia Huck
2012-07-23 14:27 ` Avi Kivity
2012-07-23 15:01 ` Cornelia Huck
2012-07-23 12:26 ` Avi Kivity
2012-07-23 12:58 ` Peter Maydell
2012-07-23 13:09 ` Avi Kivity
2012-07-23 13:27 ` Peter Maydell
2012-07-23 13:38 ` Avi Kivity
2012-07-23 13:50 ` Peter Maydell
2012-07-23 14:30 ` Avi Kivity
2012-07-23 17:58 ` Peter Maydell
2012-07-24 8:50 ` Avi Kivity
2012-07-24 8:54 ` Peter Maydell
2012-07-24 8:58 ` Jan Kiszka
2012-07-23 15:19 ` Peter Maydell
2012-07-23 16:55 ` Jan Kiszka
2012-07-23 17:41 ` Peter Maydell
2012-07-23 17:51 ` Jan Kiszka
2012-07-24 8:56 ` Avi Kivity
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=20120723150600.57f2aab5@BR9GNB5Z \
--to=cornelia.huck@de.ibm.com \
--cc=agraf@suse.de \
--cc=avi@redhat.com \
--cc=jan.kiszka@web.de \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=patches@linaro.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/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).