All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Henderson <rth@twiddle.net>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: qemu-devel@nongnu.org, eduard.munteanu@linux360.ro
Subject: Re: [Qemu-devel] [PATCH 01/14] Generic DMA memory access interface
Date: Thu, 02 Jun 2011 09:43:32 -0700	[thread overview]
Message-ID: <4DE7BDB4.1060601@twiddle.net> (raw)
In-Reply-To: <1307027562-3460-2-git-send-email-david@gibson.dropbear.id.au>

On 06/02/2011 08:12 AM, David Gibson wrote:
> +    err = iommu->translate(dev, addr, &paddr, &plen, is_write);
> +    if (err) {
> +        return NULL;
> +    }
> +
> +    /*
> +     * If this is true, the virtual region is contiguous,
> +     * but the translated physical region isn't. We just
> +     * clamp *len, much like cpu_physical_memory_map() does.
> +     */
> +    if (plen < *len) {
> +        *len = plen;
> +    }
> +
> +    buf = cpu_physical_memory_map(paddr, &plen, is_write);
> +    *len = plen;
> +
> +    /* We treat maps as remote TLBs to cope with stuff like AIO. */

Oh, that reminds me.  There's a bug here in Eduard's original:

PLEN is set to the maximum length of the transfer by the 
translate function.  What we do *not* want is to pass a
very very large region to cpu_physical_memory_map.

The effects of this are hard to see with the AMD IOMMU, since
it is entirely page based and thus PLEN will be increased by
no more than 4k, but Alpha IOMMUs have direct-mapped translation
windows that can be up to 128GB.

I'm unsure whether I prefer to force the translator function
to never increase PLEN (which is what I implemented in my 
own branch) or whether all callers of the translate function
must be aware that the returned PLEN can increase.


r~

  reply	other threads:[~2011-06-02 16:43 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-02 15:12 [Qemu-devel] Yet another take on a generic dma/iommu layer David Gibson
2011-06-02 15:12 ` [Qemu-devel] [PATCH 01/14] Generic DMA memory access interface David Gibson
2011-06-02 16:43   ` Richard Henderson [this message]
2011-06-02 17:35     ` Eduard - Gabriel Munteanu
2011-06-02 19:28       ` Richard Henderson
2011-06-02 19:59         ` Eduard - Gabriel Munteanu
2011-06-02 15:12 ` [Qemu-devel] [PATCH 02/14] pci: add IOMMU support via the generic DMA layer David Gibson
2011-06-02 16:49   ` Richard Henderson
2011-06-02 15:12 ` [Qemu-devel] [PATCH 03/14] AMD IOMMU emulation David Gibson
2011-06-02 15:12 ` [Qemu-devel] [PATCH 04/14] ide: use the DMA memory access interface for PCI IDE controllers David Gibson
2011-06-02 15:12 ` [Qemu-devel] [PATCH 05/14] rtl8139: use the DMA memory access interface David Gibson
2011-06-02 15:12 ` [Qemu-devel] [PATCH 06/14] eepro100: " David Gibson
2011-06-02 15:12 ` [Qemu-devel] [PATCH 07/14] ac97: " David Gibson
2011-06-02 15:12 ` [Qemu-devel] [PATCH 08/14] es1370: " David Gibson
2011-06-02 15:12 ` [Qemu-devel] [PATCH 09/14] e1000: " David Gibson
2011-06-02 15:12 ` [Qemu-devel] [PATCH 10/14] lsi53c895a: " David Gibson
2011-06-02 15:12 ` [Qemu-devel] [PATCH 11/14] pcnet: " David Gibson
2011-06-02 15:12 ` [Qemu-devel] [PATCH 12/14] usb-uhci: " David Gibson
2011-06-02 15:12 ` [Qemu-devel] [PATCH 13/14] usb-ohci: " David Gibson
2011-06-02 15:12 ` [Qemu-devel] [PATCH 14/14] Make spapr tces use generic dma layer David Gibson

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=4DE7BDB4.1060601@twiddle.net \
    --to=rth@twiddle.net \
    --cc=david@gibson.dropbear.id.au \
    --cc=eduard.munteanu@linux360.ro \
    --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 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.