qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Fedin <p.fedin@samsung.com>
To: 'Alex Williamson' <alex.williamson@redhat.com>
Cc: 'Peter Maydell' <peter.maydell@linaro.org>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] vfio: Align iova also to IOMMU page size
Date: Thu, 03 Dec 2015 12:02:57 +0300	[thread overview]
Message-ID: <008a01d12da9$67f816d0$37e84470$@samsung.com> (raw)
In-Reply-To: <1449085233.15753.101.camel@redhat.com>

 Hello!

> >  My device defines this BAR to be of 2M size. In this case qemu splits it up into three
> > regions:
> >  1) Region below the MSI-X table (it's called "mmap", for me it's empty because table offset
> > is 0)
> >  2) MSI-X table itself (20 vectors = 0x00000140 bytes for me).
> >  3) Region above the MSi-X table (it's called "mmap msix-hi"). Size for my case is 2M -
> > REAL_HOST_PAGE_ALIGN(0x140) = 0x1FF000.
> > Regions (1) and (3) are passed through and directly mapped by VFIO, region (2) is emulated.
> >  Now, we have PBA. The device says that PBA is placed in memory specified by the same BAR as
> > table, and its offset is 0x000f0000. PBA is also emulated by qemu, and as a result it overlaps
> > "mmap msix-hi" region, which breaks up into two fragments as a consequence:
> >  3a) offset 0x00000 size 0x0EF000
> >  3b) offset 0xEF008 size 0x10FFF8
> >  PBA sits between these fragments, having only 8 bytes in size.
> >  Attempt to map (3b) causes the problem. vfio_mmap_region() is expected to align this up,
> > and it does, but it does it to a minimum possible granularity for ARM platform, which, as qemu
> > thinks, is always 1K.
> 
> Yep, on x86 we'd have target page size == host page size == minimum
> iommu page size and we'd align that up to something that can be mapped,
> which means we wouldn't have an iommu mapping for peer-to-peer in this
> space, but nobody is likely to notice.

 So, OK, to keep the quoting short... I've also read your previous reply about that "rounding up just works". Let's sum things up.

1. Rounding up "just works" in my case too. So i don't see a direct reason to change it.
2. The only problem is rounding up to 1K, which TARGET_PAGE_ALIGN() does on ARM. What we need is 4K,
   which is appropriate for host too. And, by the way, for modern ARM guests too. So, we can do either of:
   a) Keep my original approach - TARGET_PAGE_ALIGN(), then align to vfio_container_granularity().
   b) Just align to vfio_container_granularity() instead of using TARGET_PAGE_ALIGN().
   c) Use HOST_PAGE_ALIGN() instead of TARGET_PAGE_ALIGN() (what Peter suggested).

   On x86 there would be no difference, because all these alignments are identical. On ARM, actually, all of these approaches would also give correct result, because it's only TARGET_PAGE_ALIGN() wrong in this case. So - what do you think is the most appropriate? Let's make a choice and i'll send a proper patch.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia

  reply	other threads:[~2015-12-03  9:03 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 [this message]
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
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='008a01d12da9$67f816d0$37e84470$@samsung.com' \
    --to=p.fedin@samsung.com \
    --cc=alex.williamson@redhat.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).