All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: Peter Crosthwaite <peter.crosthwaite@xilinx.com>,
	David Gibson <david@gibson.dropbear.id.au>
Cc: Alex Williamson <alex.williamson@redhat.com>,
	qemu-ppc Mailing List <qemu-ppc@nongnu.org>,
	"qemu-devel@nongnu.org Developers" <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 17:08:51 +1000	[thread overview]
Message-ID: <55A4B583.8000908@ozlabs.ru> (raw)
In-Reply-To: <CAEgOgz5Qq+0p=svqG8dPc74JU0GdoZe0U+KWQkaUqyLXF2cHyA@mail.gmail.com>

On 07/14/2015 06:32 AM, Peter Crosthwaite wrote:
> On Sun, Jul 12, 2015 at 11:15 PM, David Gibson
> <david@gibson.dropbear.id.au> 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.
>>
>
> So the multi-arch work (for which f7ceed190 preps) does have a problem
> that needs something like this. TARGET_PAGE_MASK and TARGET_PAGE_ALIGN
> do need to go away from common code, or this has to be promoted to
> cpu-specific code. Consequently, the page size is fixed to 4K for
> multi-arch and this is not a good long-term limitation. Is the IOMMU
> page size really tied to the CPU implementation? In practice this is
> going to be the case, but IOMMU and CPU should be decoupleable.
>
> If vfio needs to respect a particular (or all?) CPUs/IOMMUs page
> alignment then can we virtualise this as data rather than a macroified
> constant?
>
> uint64_t  page_align = 0;
>
> CPU_FOREACH(cpu, ...) {
>      CPUClass *cc = CPU_GET_CLASS(cpu);
>
>      page_align = MAX(page_align, cc->page_size);
> }
>
> /* This is a little more made up ... */
> IOMMU_FOREACH(iommu, ...) {
>      page_align = MAX(page_align, iommu->page_size);
> }

This assumes that IOMMU has a constant page size, is this always true?
Cannot it be a (contigous?) set of different size chunks, for example, one 
per memory dimm?


-- 
Alexey

  reply	other threads:[~2015-07-14  7:09 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
2015-07-13 20:32     ` Peter Crosthwaite
2015-07-14  7:08       ` Alexey Kardashevskiy [this message]
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=55A4B583.8000908@ozlabs.ru \
    --to=aik@ozlabs.ru \
    --cc=alex.williamson@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=peter.crosthwaite@xilinx.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.