From: Alex Williamson <alex.williamson@redhat.com>
To: Li Qiang <liq3ea@163.com>
Cc: "eric.auger@redhat.com" <eric.auger@redhat.com>,
"liq3ea@gmail.com" <liq3ea@gmail.com>,
Alex Williamson <alex.l.williamson@gmail.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: Questions about the VFIO BAR region
Date: Mon, 4 Nov 2019 11:48:57 -0700 [thread overview]
Message-ID: <20191104114857.74fe9222@x1.home> (raw)
In-Reply-To: <5DC05485.008EAA.00665@m12-12.163.com>
On Tue, 5 Nov 2019 00:40:39 +0800
Li Qiang <liq3ea@163.com> wrote:
> Hello Alex, Auger and all,
>
> I have a question about the VFIO virtual device BAR.
>
> In vfio_region_setup, it initialize a ‘region->mem’ MR and set its ops to ‘vfio_regions_ops’.
> In ‘vfio_region_mmap’, it maps the physical device’s MMIO to QEMU’s virtual address space
> as a raw MR ‘region->mmaps[i].mem’.
> And also it set the latter MR as a subregion of the first one.
>
> So when the guest accesses the BAR, it will direct go to the physical device’s BAR.
> My question is here:
> When the qemu will use the ‘vfio_regions_ops’ to read/write the BAR?
> Also whey in the last of ‘vfio_region_write/read’ we need to call ‘vbasedev->ops->vfio_eoi(vbasedev);’?
We support:
a) sparse mmaps where the entire BAR is not covered by an mmap
b) quirks, which layer on top of the mmaps to provide virtualized
access
c) INTx emulation which disables mmaps MRs in order to detect device
access as a generic mechanism for inferring interrupt
acknowledgment.
The latter being the reason we call vfio_eoi. Thanks,
Alex
next prev parent reply other threads:[~2019-11-04 18:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-04 16:40 Questions about the VFIO BAR region Li Qiang
2019-11-04 18:48 ` Alex Williamson [this message]
2019-11-05 1:16 ` Li Qiang
2019-11-05 13:17 ` Auger Eric
2019-11-05 13:44 ` Li Qiang
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=20191104114857.74fe9222@x1.home \
--to=alex.williamson@redhat.com \
--cc=alex.l.williamson@gmail.com \
--cc=eric.auger@redhat.com \
--cc=liq3ea@163.com \
--cc=liq3ea@gmail.com \
--cc=qemu-devel@nongnu.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;
as well as URLs for NNTP newsgroup(s).