All of lore.kernel.org
 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 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.