Re: [virtio-dev] On doorbells (queue notifications)

[Alex BennÃe <alex.bennee@linaro.org>]

Stefan Hajnoczi <stefanha@redhat.com> writes:

> On Wed, Jul 15, 2020 at 02:29:04PM +0100, Alex BennÃe wrote:
>> Stefan Hajnoczi <stefanha@redhat.com> writes:
>> > On Tue, Jul 14, 2020 at 10:43:36PM +0100, Alex BennÃe wrote:
>> >> Finally I'm curious if this is just a problem avoided by the s390
>> >> channel approach? Does the use of messages over a channel just avoid the
>> >> sort of bouncing back and forth that other hypervisors have to do when
>> >> emulating a device?
>> >
>> > What does "bouncing back and forth" mean exactly?
>> 
>> Context switching between guest and hypervisor.
>
> I have CCed Cornelia Huck, who can explain the lifecycle of an I/O
> request on s390 channel I/O.

Thanks.

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?

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?

-- 
Alex BennÃe