qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Pavel Fedin <p.fedin@samsung.com>,
	QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] vfio: Align iova also to IOMMU page size
Date: Thu, 03 Dec 2015 10:58:56 -0700	[thread overview]
Message-ID: <1449165536.15753.214.camel@redhat.com> (raw)
In-Reply-To: <CAFEAcA-eroPCdXDSwUvzGi4fADN0cPAf7VvK3nJc6R6P52jUBQ@mail.gmail.com>

On Thu, 2015-12-03 at 17:36 +0000, Peter Maydell wrote:
> On 3 December 2015 at 17:19, Alex Williamson <alex.williamson@redhat.com> wrote:
> > On Thu, 2015-12-03 at 16:33 +0000, Peter Maydell wrote:
> >> On 3 December 2015 at 16:26, Alex Williamson <alex.williamson@redhat.com> wrote:
> >> > I feel a lot more comfortable if we limit the scope to MMIO regions of
> >> > PCI devices.  The problems I brought up before about the device not
> >> > being able to DMA to a target aligned RAM address are still a
> >> > possibility that I think we want to catch.  To do that, I think we just
> >> > need:
> >> >
> >> > Object *obj = memory_region_owner(section->mr);
> >> >
> >> > if (object_dynamic_cast(obj, "pci-device")) {
> >> >     /* HOST_PAGE_ALIGN... */
> >> > } else {
> >> >     /* TARGET_PAGE_ALIGN... */
> >> > }
> >>
> >> This looks very odd to me, in two ways: (a) behaving differently
> >> for PCI passthrough vs other kinds of passthrough,
> >
> > It's a matter of risk.  If we align an MMIO range out of existence all
> > we've prevented is peer-to-peer DMA between assigned devices.  Chances
> > of anyone caring about that are slim to none.  If we align RAM out of
> > existence, that's a much, much more significant risk that we've just
> > introduced a data integrity issue for the VM.
> 
> I don't see why this is different for PCI devices versus
> memory-mapped passthrough devices, though. If what you mean
> is "is this MemoryRegion not RAM" maybe you want
> if (!memory_region_is_ram(mr))  ?

We would already skip it entirely if that worked, see
hw/vfio/common.c:vfio_listener_skipped_section().  MemoryRegions backed
by a ram ptr still sneak through that.  We're dealing with sub-host-page
MemoryRegionSections that are backed by an mmap to a vfio region.

> >>  and (b) caring
> >> about TARGET_PAGE_ALIGN at all. TARGET_PAGE_ALIGN really isn't
> >> something vfio should need to care about I think.
> >
> > But I think we do.  If a RAM address is target page aligned, it could be
> > a valid DMA target for the device.
> 
> TARGET_PAGE_ALIGN doesn't tell you whether an address is actually
> page aligned for the guest, though. In fact, you can't tell what
> page size the guest happens to be using (or what the alignment
> restrictions on doing DMA might be, or the page size being used by
> the IOMMU, which isn't necessarily the guest page size either).

TAGET_PAGE_ALIGN tells us that it *could* be a valid DMA target though.
The VM model is capable of using that as a page size, which means we
assume it is and want to generate a fault.

> > If we align it out of existence and
> > the device is programmed to perform a DMA to that address, the IOMMU
> > will block it, the VM will not be informed and will continue executing
> > with invalid data.
> 
> Shouldn't this cause the device to say "hey, my DMA transaction
> failed, I will flag that up as an error" ? (That's not much better
> as a failure situation, of course.)

DMA reads can get a target abort, DMA writes fail silently, other than
the possible IOMMU fault from the IOMMU driver, for which we have
nothing resembling an infrastructure for collecting that and reporting
it out to the user.  Thanks,

Alex

  reply	other threads:[~2015-12-03 17:59 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-17  7:46 [Qemu-devel] [PATCH] vfio: Align iova also to IOMMU page size Pavel Fedin
2015-11-18 22:04 ` Alex Williamson
2015-11-19 10:29   ` Pavel Fedin
2015-11-19 23:33     ` Alex Williamson
2015-11-24 15:24       ` Pavel Fedin
2015-12-02 19:40         ` Alex Williamson
2015-12-03  9:02           ` Pavel Fedin
2015-12-03 16:26             ` Alex Williamson
2015-12-03 16:33               ` Peter Maydell
2015-12-03 17:19                 ` Alex Williamson
2015-12-03 17:36                   ` Peter Maydell
2015-12-03 17:58                     ` Alex Williamson [this message]
2015-12-07 10:53                       ` Pavel Fedin
2015-12-07 11:20                         ` Peter Maydell
2015-12-08 23:42                           ` Alex Williamson
2015-12-09  8:08                             ` Pavel Fedin
2015-12-09 10:09     ` Alex Bennée
2015-11-24 15:34   ` Peter Maydell
2015-11-25  7:00     ` Pavel Fedin
2015-12-02 19:05       ` Alex Williamson

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=1449165536.15753.214.camel@redhat.com \
    --to=alex.williamson@redhat.com \
    --cc=p.fedin@samsung.com \
    --cc=peter.maydell@linaro.org \
    --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).