From: John Levon <levon@movementarian.org>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Elena <elena.ufimtseva@oracle.com>,
qemu-devel@nongnu.org, kvm@vger.kernel.org, mst@redhat.com,
john.g.johnson@oracle.com, dinechin@redhat.com,
cohuck@redhat.com, jasowang@redhat.com, felipe@nutanix.com,
jag.raman@oracle.com, eafanasova@gmail.com
Subject: Re: MMIO/PIO dispatch file descriptors (ioregionfd) design discussion
Date: Wed, 27 Oct 2021 13:22:28 +0100 [thread overview]
Message-ID: <YXlEhCYAJuhsVwDv@movementarian.org> (raw)
In-Reply-To: <YXkmx3V0VklA6qHl@stefanha-x1.localdomain>
On Wed, Oct 27, 2021 at 11:15:35AM +0100, Stefan Hajnoczi wrote:
> > > I like this approach as well.
> > > As you have mentioned, the device emulation code with first approach
> > > does have to how to handle the region accesses. The second approach will
> > > make things more transparent. Let me see how can I modify what there is
> > > there now and may ask further questions.
> >
> > Sorry I'm a bit late to this discussion, I'm not clear on the above WRT
> > vfio-user. If an ioregionfd has to cover a whole BAR0 (?), how would this
> > interact with partly-mmap()able regions like we do with SPDK/vfio-user/NVMe?
>
> The ioregionfd doesn't need to cover an entire BAR. QEMU's MemoryRegions
> form a hierarchy, so it's possible to sub-divide the BAR into several
> MemoryRegions.
I think you're saying that when vfio-user client in qemu calls
VFIO_USER_DEVICE_GET_REGION_IO_FDS, it would create a sub-MR corresponding to
each one, before asking KVM to configure them?
thanks
john
next prev parent reply other threads:[~2021-10-27 12:22 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-25 20:44 MMIO/PIO dispatch file descriptors (ioregionfd) design discussion Elena Afanasova
2020-12-02 18:06 ` Peter Xu
2020-12-03 11:10 ` Stefan Hajnoczi
2020-12-03 11:34 ` Michael S. Tsirkin
2020-12-04 13:23 ` Stefan Hajnoczi
2020-12-03 14:40 ` Peter Xu
2020-12-07 14:58 ` Stefan Hajnoczi
2021-10-12 5:34 ` elena
2021-10-25 12:42 ` Stefan Hajnoczi
2021-10-25 15:21 ` Elena
2021-10-25 16:56 ` Stefan Hajnoczi
2021-10-26 19:01 ` John Levon
2021-10-27 10:15 ` Stefan Hajnoczi
2021-10-27 12:22 ` John Levon [this message]
2021-10-28 8:14 ` Stefan Hajnoczi
[not found] <CAFO2pHzmVf7g3z0RikQbYnejwcWRtHKV=npALs49eRDJdt4mJQ@mail.gmail.com>
2020-11-26 3:37 ` Jason Wang
2020-11-26 12:36 ` Stefan Hajnoczi
2020-11-27 3:39 ` Jason Wang
2020-11-27 13:44 ` Stefan Hajnoczi
2020-11-30 2:14 ` Jason Wang
2020-11-30 12:47 ` Stefan Hajnoczi
2020-12-01 4:05 ` Jason Wang
2020-12-01 10:35 ` Stefan Hajnoczi
2020-12-02 2:53 ` Jason Wang
2020-12-02 14:17 ` Elena Afanasova
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=YXlEhCYAJuhsVwDv@movementarian.org \
--to=levon@movementarian.org \
--cc=cohuck@redhat.com \
--cc=dinechin@redhat.com \
--cc=eafanasova@gmail.com \
--cc=elena.ufimtseva@oracle.com \
--cc=felipe@nutanix.com \
--cc=jag.raman@oracle.com \
--cc=jasowang@redhat.com \
--cc=john.g.johnson@oracle.com \
--cc=kvm@vger.kernel.org \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.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