All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: Alex Williamson <alex.williamson@redhat.com>,
	qemu-ppc@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH qemu 1/5] vfio: Switch from TARGET_PAGE_MASK to qemu_real_host_page_mask
Date: Tue, 14 Jul 2015 13:46:44 +1000	[thread overview]
Message-ID: <20150714034644.GC4121@voom.redhat.com> (raw)
In-Reply-To: <55A367A1.50707@ozlabs.ru>

[-- Attachment #1: Type: text/plain, Size: 3189 bytes --]

On Mon, Jul 13, 2015 at 05:24:17PM +1000, Alexey Kardashevskiy wrote:
> On 07/13/2015 04:15 PM, David Gibson wrote:
> >On Fri, Jul 10, 2015 at 08:43:44PM +1000, Alexey Kardashevskiy wrote:
> >>These started switching from TARGET_PAGE_MASK (hardcoded as 4K) to
> >>a real host page size:
> >>4e51361d7 "cpu-all: complete "real" host page size API" and
> >>f7ceed190 "vfio: cpu: Use "real" page size API"
> >>
> >>This finished the transition by:
> >>- %s/TARGET_PAGE_MASK/qemu_real_host_page_mask/
> >>- %s/TARGET_PAGE_ALIGN/REAL_HOST_PAGE_ALIGN/
> >>- removing bitfield length for offsets in VFIOQuirk::data as
> >>qemu_real_host_page_mask is not a macro
> >
> >This does not make much sense to me.  f7ceed190 moved to
> >REAL_HOST_PAGE_SIZE because it's back end stuff that really depends
> >only on the host page size.
> >
> >Here you're applying a blanket change to vfio code, in particular to
> >the DMA handling code, and for DMA both the host and target page size
> >can be relevant, depending on the details of the IOMMU implementation.
> 
> 
> 5/5 uses this listener for memory preregistration - this totally depends on
> the host page size. It was suggested to make this listener do memory
> preregistration too, not just DMA.
> 
> 
> >>This keeps using TARGET_PAGE_MASK for IOMMU regions though as it is
> >>the minimum page size which IOMMU regions may be using and at the moment
> >>memory regions do not carry the actual page size.
> >
> >And this exception also doesn't make much sense to me.  Partly it's
> >confusing because the listener is doing different things depending on
> >whether we have a guest visible IOMMU or not.
> 
> Yes...
> 
> >In short, there doesn't seem to be a coherent explanation here of
> >where the page size / alignment restriction is coming from, and
> >therefore whether it needs to be a host page alignment, a guest page
> >alignment, or both.
> >
> >>Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> >>---
> >>
> >>In reality DMA windows are always a lot bigger than a single 4K page
> >>and aligned to 32/64MB, may be only use here
> >>qemu_real_host_page_mask?
> >
> >I don't understand this question either.
> 
> The listener is called on RAM regions and DMA windows. If it is a RAM
> region, then host page size applies. If it is a DMA window - then
> 4K.

That might be true in the particular cases you're thinking about, but
you've got to think more generally if you're going to have coherent
semantics in the core code here.

For preregistration, host page size applies.

For auto-mapping of RAM regions (as on x86), host IOMMU page size
applies (which is probably the same as host page size, but it doesn't
theoretically have to be).  Guest page size kind of implicitly
applies, since added RAM regions generally have to be target page
aligned anyway.

For guest controlled mapping, you're contrained by both the host iommu
page size and the guest iommu page size.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2015-07-14  4:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-10 10:43 [Qemu-devel] [PATCH qemu 0/5] vfio: SPAPR IOMMU v2 (memory preregistration support) Alexey Kardashevskiy
2015-07-10 10:43 ` [Qemu-devel] [PATCH qemu 1/5] vfio: Switch from TARGET_PAGE_MASK to qemu_real_host_page_mask Alexey Kardashevskiy
2015-07-13  6:15   ` David Gibson
2015-07-13  7:24     ` Alexey Kardashevskiy
2015-07-14  3:46       ` David Gibson [this message]
2015-07-13 20:32     ` Peter Crosthwaite
2015-07-14  7:08       ` Alexey Kardashevskiy
2015-07-10 10:43 ` [Qemu-devel] [PATCH qemu 2/5] vfio: Skip PCI BARs in memory listener Alexey Kardashevskiy
2015-07-13 17:08   ` Alex Williamson
2015-07-10 10:43 ` [Qemu-devel] [PATCH qemu 3/5] vfio: Store IOMMU type in container Alexey Kardashevskiy
2015-07-10 10:43 ` [Qemu-devel] [PATCH qemu 4/5] vfio: Refactor memory listener to accommodate more IOMMU types Alexey Kardashevskiy
2015-07-10 10:43 ` [Qemu-devel] [PATCH qemu 5/5] vfio: spapr: Add SPAPR IOMMU v2 support (DMA memory preregistering) Alexey Kardashevskiy

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=20150714034644.GC4121@voom.redhat.com \
    --to=david@gibson.dropbear.id.au \
    --cc=aik@ozlabs.ru \
    --cc=alex.williamson@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.