From: Arnd Bergmann <arnd@kernel.org>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: "Jason Wang" <jasowang@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Cornelia Huck" <cohuck@redhat.com>,
"Linus Walleij" <linus.walleij@linaro.org>,
"Bartosz Golaszewski" <bgolaszewski@baylibre.com>,
"Vincent Guittot" <vincent.guittot@linaro.org>,
"Jean-Philippe Brucker" <jean-philippe@linaro.org>,
"Bill Mills" <bill.mills@linaro.org>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Enrico Weigelt, metux IT consult" <info@metux.net>,
virtio-dev@lists.oasis-open.org,
"Geert Uytterhoeven" <geert@linux-m68k.org>
Subject: Re: [PATCH V5 2/2] virtio-gpio: Add support for interrupts
Date: Mon, 19 Jul 2021 14:00:21 +0200 [thread overview]
Message-ID: <CAK8P3a09QeGsav65dbjK9=4yNCBRHPdxP6h0O1ve3tBYRbAuzQ@mail.gmail.com> (raw)
In-Reply-To: <20210719102411.yykntzjefeamz24t@vireshk-i7>
On Mon, Jul 19, 2021 at 12:24 PM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> On 16-07-21, 13:09, Viresh Kumar wrote:
> > This patch adds support for interrupts to the virtio-gpio specification.
> > This uses the feature bit 0 for the same.
>
> Michael (and other virtio experts),
>
> I have a doubt about interrupt messages initiated by the device. There is
> nothing meaningful I want to return from the driver to the device on an
> interrupt event, but I need to make sure the device doesn't send another
> interrupt for the same GPIO line, before the previous one is serviced. I was
> thinking about sending some sort of response message for it, but am not sure how
> to implement it.
>
> Another way out to implement this, is by adding to the spec that on interrupt
> the device MUST mask the interrupt line on the GPIO before sending the event to
> the driver and this irq can be re-enabled only by the driver sending another
> request over the primary virtqueue (and not interrupt virtqueue).
>
> What do you suggest ?
I would still hope that we can simplify this to the 'Ack' being implied by
requeuing the message from the gpio driver. In case of a level interrupt:
device driver
1. queue message
2. line activates
3. send reply
4. notify guest
5. call handler
6. line may activate
7. goto 1
For edge interrupts, I'm still not sure how it would work. The options
that I see are:
a) fasteoi style controller: when the device sends an event, this
becomes implicitly masked as there is no way to send another
until the message is requeued, but the device latches any further
events, so that queuing the next message after the guest handler
returns immediately results in the event getting delivered.
This would use the minimum number of requests and let the
driver use the exact same code for edge and level mode, but it
does mean the possibility of extra wakeups, and it may require
more work in the host.
b) require the requeue to happen in the guest before calling the
handler to prevent missed events. Not sure if this is possible
without another message, as the guest must be sure that the
host has observed the requeue, but it cannot have returned
any data yet.
c) explicit ack at start of guest: driver starts by sending an
ack to the first virtqueue and waiting for it to be complete,
then calls the handler, and only then requeues the request.
This would presumably add a lot of extra latency.
Arnd
next prev parent reply other threads:[~2021-07-19 12:00 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-16 7:39 [PATCH V5 0/2] virtio: Add specification for virtio-gpio Viresh Kumar
2021-07-16 7:39 ` [PATCH V5 1/2] virtio-gpio: Add the device specification Viresh Kumar
2021-07-16 8:23 ` Arnd Bergmann
2021-07-16 16:26 ` Viresh Kumar
2021-07-16 18:20 ` Arnd Bergmann
2021-07-19 9:29 ` Viresh Kumar
2021-07-19 10:40 ` [virtio-dev] " Arnd Bergmann
2021-07-19 10:50 ` Viresh Kumar
2021-07-19 11:48 ` Geert Uytterhoeven
2021-07-19 7:32 ` Viresh Kumar
2021-07-16 9:13 ` Geert Uytterhoeven
2021-07-16 15:43 ` Viresh Kumar
2021-07-16 15:22 ` Michael S. Tsirkin
2021-07-16 15:41 ` Viresh Kumar
2021-07-16 7:39 ` [virtio-dev] [PATCH V5 2/2] virtio-gpio: Add support for interrupts Viresh Kumar
2021-07-16 9:02 ` Arnd Bergmann
2021-07-16 15:17 ` [virtio-dev] " Viresh Kumar
2021-07-16 16:19 ` Arnd Bergmann
2021-07-16 16:50 ` Viresh Kumar
2021-07-16 18:49 ` Arnd Bergmann
2021-07-20 5:47 ` Viresh Kumar
2021-07-20 7:01 ` Arnd Bergmann
2021-07-20 7:11 ` Viresh Kumar
2021-07-20 7:22 ` Arnd Bergmann
2021-07-19 10:24 ` Viresh Kumar
2021-07-19 12:00 ` Arnd Bergmann [this message]
2021-07-20 6:11 ` Viresh Kumar
2021-07-20 7:17 ` Arnd Bergmann
2021-07-20 7:53 ` Viresh Kumar
2021-07-20 8:10 ` Arnd Bergmann
2021-07-20 8:42 ` Viresh Kumar
2021-07-20 9:50 ` Michael S. Tsirkin
2021-07-19 15:11 ` Michael S. Tsirkin
2021-07-20 4:19 ` Viresh Kumar
2021-07-16 9:57 ` [PATCH V5 0/2] virtio: Add specification for virtio-gpio Arnd Bergmann
2021-07-16 16:57 ` Viresh Kumar
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='CAK8P3a09QeGsav65dbjK9=4yNCBRHPdxP6h0O1ve3tBYRbAuzQ@mail.gmail.com' \
--to=arnd@kernel.org \
--cc=alex.bennee@linaro.org \
--cc=bgolaszewski@baylibre.com \
--cc=bill.mills@linaro.org \
--cc=cohuck@redhat.com \
--cc=geert@linux-m68k.org \
--cc=info@metux.net \
--cc=jasowang@redhat.com \
--cc=jean-philippe@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=mst@redhat.com \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.org \
--cc=virtio-dev@lists.oasis-open.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.