Discussion of the implementations of VIRTIO specification
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: stratos-dev@op-lists.linaro.org, virtio-dev@lists.oasis-open.org,
	Sumit Semwal <sumit.semwal@linaro.org>,
	John Stultz <john.stultz@linaro.org>,
	Tom Gall <tom.gall@linaro.org>,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	Christopher Clark <christopher.w.clark@gmail.com>,
	Will Deacon <will@kernel.org>,
	Arnd Bergmann <arnd.bergmann@linaro.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Joakim Bech <joakim.bech@linaro.org>,
	Mike Holmes <mike.holmes@linaro.org>,
	Trilok Soni <tsoni@quicinc.com>,
	Srivatsa Vaddagiri <vatsa@codeaurora.org>,
	Anmar Oueja <anmar.oueja@linaro.org>,
	Jan Kiszka <jan.kiszka@siemens.com>
Subject: Re: [virtio-dev] Some thoughts on zero-copy between VM domains for discussion
Date: Fri, 14 Jan 2022 14:28:11 +0000	[thread overview]
Message-ID: <87r19a8jub.fsf@linaro.org> (raw)
In-Reply-To: <YdwBGYBdzfYxOvp4@stefanha-x1.localdomain>


Stefan Hajnoczi <stefanha@redhat.com> writes:

> [[PGP Signed Part:Undecided]]
> On Thu, Jan 06, 2022 at 05:03:38PM +0000, Alex Bennée wrote:
>> 
>> Hi,
>> 
>> To start the new year I thought would dump some of my thoughts on
>> zero-copy between VM domains. For project Stratos we've gamely avoided
>> thinking too hard about this while we've been concentrating on solving
>> more tractable problems. However we can't put it off forever so lets
>> work through the problem.
>> 
>> Memory Sharing
<snip>
>> Buffer Allocation
<snip>
>> Transparent fallback and scaling
<snip>
>> 
>>  - what other constraints we need to take into account?
>>  - can we leverage existing sub-systems to build this support?
>> 
>> I look forward to your thoughts ;-)
>
> (Side note: Shared Virtual Addressing (https://lwn.net/Articles/747230/)
> is an interesting IOMMU feature. It would be neat to have a CPU
> equivalent where loads and stores from/to another address space could be
> done cheaply with CPU support. I don't think this is possible today and
> that's why software IOMMUs are slow for per-transaction page protection.
> In other words, a virtio-net TX VM would set up a page table allowing
> read access only to the TX buffers and vring and the virtual network
> switch VM would have the capability to access the vring and buffers
> through the TX VM's dedicated address space.)

Does binding a device to an address space mean the driver allocations
will be automatically done from the address space or do the drivers need
modifying to take advantage of that? Jean-Phillipe?

> Some storage and networking applications use buffered I/O where the
> guest kernel owns the DMA buffer while others use zero-copy I/O where
> guest userspace pages are pinned for DMA. I think both cases need to be
> considered.
>
> Are guest userspace-visible API changes allowed (e.g. making the
> userspace application aware at buffer allocation time)?

I assume you mean enhanced rather than breaking APIs here? I don't see
why not. Certainly for the vhost-user backends we are writing we aren't
beholden to sticking to an old API.

> Ideally the
> requirement would be that zero-copy must work for unmodified
> applications, but I'm not sure if that's realistic.
>
> By the way, VIRTIO 1.2 introduces Shared Memory Regions. These are
> memory regions (e.g. PCI BAR ranges) that the guest driver can map. If
> the host pages must come from a special pool then Shared Memory Regions
> would be one way to configure the guest to use this special zero-copy
> area for data buffers and even vrings. New VIRTIO feature bits and
> transport-specific information may need to be added to do this.

Are these fixed sizes or could be accommodate a growing/shrinking region?

Thanks for the pointers.

-- 
Alex Bennée

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


  reply	other threads:[~2022-01-14 14:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-06 17:03 [virtio-dev] Some thoughts on zero-copy between VM domains for discussion Alex Bennée
2022-01-10  9:49 ` Stefan Hajnoczi
2022-01-14 14:28   ` Alex Bennée [this message]
2022-01-14 17:16     ` Jean-Philippe Brucker
2022-01-17 10:15     ` Stefan Hajnoczi
2022-01-19 17:10 ` Dr. David Alan Gilbert

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=87r19a8jub.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=anmar.oueja@linaro.org \
    --cc=arnd.bergmann@linaro.org \
    --cc=christopher.w.clark@gmail.com \
    --cc=jan.kiszka@siemens.com \
    --cc=jean-philippe@linaro.org \
    --cc=joakim.bech@linaro.org \
    --cc=john.stultz@linaro.org \
    --cc=mike.holmes@linaro.org \
    --cc=stefanha@redhat.com \
    --cc=stratos-dev@op-lists.linaro.org \
    --cc=sumit.semwal@linaro.org \
    --cc=tom.gall@linaro.org \
    --cc=tsoni@quicinc.com \
    --cc=vatsa@codeaurora.org \
    --cc=vincent.guittot@linaro.org \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=will@kernel.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