From: Cornelia Huck <cohuck@redhat.com>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: Stefan Hajnoczi <stefanha@redhat.com>,
virtio-dev@lists.oasis-open.org,
Zha Bin <zhabin@linux.alibaba.com>,
Jing Liu <jing2.liu@linux.intel.com>,
Chao Peng <chao.p.peng@linux.intel.com>,
Jan Kiszka <jan.kiszka@siemens.com>
Subject: Re: [virtio-dev] On doorbells (queue notifications)
Date: Wed, 15 Jul 2020 19:09:39 +0200 [thread overview]
Message-ID: <20200715190939.60b562f9.cohuck@redhat.com> (raw)
In-Reply-To: <871rlcybni.fsf@linaro.org>
On Wed, 15 Jul 2020 17:40:33 +0100
Alex Bennée <alex.bennee@linaro.org> wrote:
> I was also wondering about the efficiency of doorbells/notifications the
> other way. AFAIUI for both PCI and MMIO only a single write is required
> to the notify flag which causes a trap to the hypervisor and the rest of
> the processing. The hypervisor doesn't have the cost multiple exits to
> read the guest state although it obviously wants to be as efficient as
> possible passing the data back up to what ever is handling the backend
> of the device so it doesn't need to do multiple context switches.
>
> Has there been any investigation into other mechanisms for notifying the
> hypervisor of an event - for example using a HYP call or similar
> mechanism?
For ccw devices, we do a 'diagnose' call (which is basically a
hypercall). It has some parameters (including the queue the guest is
notifying for), so the host already has that information when the exit
happens.
> My gut tells me this probably doesn't make any difference as a trap to
> the hypervisor is likely to cost the same either way because you still
> need to save the guest context before actioning something but it would
> be interesting to know if anyone has looked at it. Perhaps there is a
> benefit in partitioned systems where core running the guest can return
> straight away after initiating what it needs to internally in the
> hypervisor to pass the notification to something that can deal with it?
I guess that depends mostly upon whether there is further interaction
needed, or if the guest can give the host all needed info in one go.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next prev parent reply other threads:[~2020-07-15 17:09 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-14 21:43 [virtio-dev] On doorbells (queue notifications) Alex Bennée
2020-07-15 11:48 ` Stefan Hajnoczi
2020-07-15 13:29 ` Alex Bennée
2020-07-15 15:47 ` Stefan Hajnoczi
2020-07-15 16:40 ` Alex Bennée
2020-07-15 17:09 ` Cornelia Huck [this message]
2020-07-16 10:00 ` Stefan Hajnoczi
2020-07-16 11:25 ` Christophe de Dinechin
2020-07-16 14:19 ` Stefan Hajnoczi
2020-07-16 14:31 ` Christophe de Dinechin
2020-07-16 14:34 ` Christophe de Dinechin
2020-07-17 8:42 ` Stefan Hajnoczi
2020-07-15 17:01 ` Cornelia Huck
2020-07-15 17:25 ` Alex Bennée
2020-07-15 20:04 ` Halil Pasic
2020-07-16 9:41 ` Cornelia Huck
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=20200715190939.60b562f9.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=chao.p.peng@linux.intel.com \
--cc=jan.kiszka@siemens.com \
--cc=jing2.liu@linux.intel.com \
--cc=stefanha@redhat.com \
--cc=virtio-dev@lists.oasis-open.org \
--cc=zhabin@linux.alibaba.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