From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Dev Audsin <dev.devaqemu@gmail.com>, qemu-devel@nongnu.org
Subject: Re: [PATCH] make vfio and DAX cache work together
Date: Thu, 29 Apr 2021 09:44:51 +0100 [thread overview]
Message-ID: <YIpyA+ZoOYxX0c06@work-vm> (raw)
In-Reply-To: <20210428133740.6ccbbba6@redhat.com>
* Alex Williamson (alex.williamson@redhat.com) wrote:
> On Wed, 28 Apr 2021 20:17:23 +0100
> "Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:
>
> > * Dev Audsin (dev.devaqemu@gmail.com) wrote:
> > > Thanks Dave for your explanation.
> > > Any suggestions on how to make VFIO not attempt to map into the
> > > unaccessible and unallocated RAM.
> >
> > I'm not sure;:
> >
> > static bool vfio_listener_skipped_section(MemoryRegionSection *section)
> > {
> > return (!memory_region_is_ram(section->mr) &&
> > !memory_region_is_iommu(section->mr)) ||
> > section->offset_within_address_space & (1ULL << 63);
> > }
> >
> > I'm declaring that region with memory_region_init_ram_ptr; should I be?
> > it's not quite like RAM.
> > But then I *do* want a kvm slot for it, and I do want it to be accessed
> > by mapping rather htan calling IO functions; that makes me think mr->ram
> > has to be true.
> > But then do we need to add another flag to memory-regions; if we do,
> > what is it;
> > a) We don't want an 'is_virtio_fs' - it needs to be more generic
> > b) 'no_vfio' also feels wrong
> >
> > Is perhaps 'not_lockable' the right thing to call it?
>
> This reasoning just seems to lead back to "it doesn't work, therefore
> don't do it" rather than identifying the property of the region that
> makes it safe not to map it for device DMA (assuming that's actually
> the case).
Yes, I'm struggling to get to what that generic form of that property
is, possibly because I've not got an example of another case to compare
it with.
> It's clearly "RAM" as far as QEMU is concerned given how
> it's created, but does it actually appear in the VM as generic physical
> RAM that the guest OS could program to the device as a DMA target? If
> not, what property makes that so, create a flag for that. Thanks,
The guest sees it as a PCI-bar; so it knows it's not 'generic physical
RAM' - but can a guest set other BARs (like frame buffers or pmem) as
DMA targets? If so, how do I distinguish our bar?
Dave
> Alex
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2021-04-29 8:47 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-26 20:50 [PATCH] make vfio and DAX cache work together Dev Audsin
2021-04-26 21:22 ` Alex Williamson
2021-04-27 16:29 ` Dev Audsin
2021-04-27 18:18 ` Alex Williamson
2021-04-27 19:00 ` Dr. David Alan Gilbert
2021-04-28 12:04 ` Dev Audsin
2021-04-28 19:17 ` Dr. David Alan Gilbert
2021-04-28 19:37 ` Alex Williamson
2021-04-29 8:44 ` Dr. David Alan Gilbert [this message]
2021-04-29 13:09 ` Alex Williamson
2021-04-29 17:55 ` Dr. David Alan Gilbert
2021-04-30 17:41 ` Dev Audsin
2021-05-04 9:58 ` Dr. David Alan Gilbert
-- strict thread matches above, loose matches on Subject: below --
2021-04-26 9:50 Edge NFV
2021-04-26 12:19 ` Dr. David Alan Gilbert
2021-04-26 14:56 ` Alex Williamson
2021-04-26 5:45 Edge NFV
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=YIpyA+ZoOYxX0c06@work-vm \
--to=dgilbert@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=dev.devaqemu@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 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.