qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] make vfio and DAX cache work together


From: Alex Williamson
Subject: Re: [PATCH] make vfio and DAX cache work together
Date: Wed, 28 Apr 2021 13:37:40 -0600

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

Alex




reply via email to

[Prev in Thread] Current Thread [Next in Thread]