qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Dev Audsin <dev.devaqemu@gmail.com>
Cc: qemu-devel@nongnu.org, dgilbert@redhat.com
Subject: Re: [PATCH] make vfio and DAX cache work together
Date: Mon, 26 Apr 2021 15:22:03 -0600	[thread overview]
Message-ID: <20210426152203.379dab00@redhat.com> (raw)
In-Reply-To: <CANsN3OTN5Q1DfhC01UGwh4nBEDXxb6=gLtWozh_oFUcc=Fd8DA@mail.gmail.com>

On Mon, 26 Apr 2021 21:50:38 +0100
Dev Audsin <dev.devaqemu@gmail.com> wrote:

> Hi Alex and David
> 
> @Alex:
> 
> Justification on why this region cannot be a DMA target for the device,
> 
> virtio-fs with DAX is currently not compatible with NIC Pass through.
> When a SR-IOV VF attaches to a qemu process, vfio will try to pin the
> entire DAX Window but it is empty when the guest boots and will fail.
> A method to make VFIO and DAX to work together is to make vfio skip
> DAX cache.
> 
> Currently DAX cache need to be set to 0, for the SR-IOV VF to be
> attached to Kata containers. Enabling both SR-IOV VF and DAX work
> together will potentially improve performance for workloads which are
> I/O and network intensive.

Sorry, there's no actual justification described here.  You're enabling
a VM with both features, virtio-fs DAX and VFIO, but there's no
evidence that they "work together" or that your use case is simply
avoiding a scenario where the device might attempt to DMA into the area
with this designation.  With this change, if the device were to attempt
to DMA into this region, it would be blocked by the IOMMU, which might
result in a data loss within the VM.  Justification of this change
needs to prove that this region can never be a DMA target for the
device, not simply that both features can be enabled and we hope that
they don't interact.  Thanks,

Alex



  reply	other threads:[~2021-04-26 21:23 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 [this message]
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
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=20210426152203.379dab00@redhat.com \
    --to=alex.williamson@redhat.com \
    --cc=dev.devaqemu@gmail.com \
    --cc=dgilbert@redhat.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).