qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Cornelia Huck <cornelia.huck@de.ibm.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 16:14:02 +0300	[thread overview]
Message-ID: <500D4E1A.4010708@redhat.com> (raw)
In-Reply-To: <20120723150600.57f2aab5@BR9GNB5Z>

On 07/23/2012 04:06 PM, Cornelia Huck wrote:
> 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.

Can you write them from a different cpu and expect them to take effect?

How do you emulate an interrupt with a large guest?  You have to update
the flags in the control blocks for all vcpus; then restore them when
the interrupt is delivered?

>> 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.

Sure.

>>  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.

Ok.  The difference between irqfd and the ioctl is that with irqfd
everything (the payload in your case, the interrupt number for others)
is prepared beforehand, while with the ioctl the extra information is
delivered with the ioctl.

-- 
error compiling committee.c: too many arguments to function

  reply	other threads:[~2012-07-23 13:14 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
2012-07-23 13:14                                 ` Avi Kivity [this message]
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=500D4E1A.4010708@redhat.com \
    --to=avi@redhat.com \
    --cc=agraf@suse.de \
    --cc=cornelia.huck@de.ibm.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).