qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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



  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 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).