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,
Alexander Graf <agraf@suse.de>
Subject: Re: [Qemu-devel] [RFC PATCH 06/10] spapr_rtas: Add Dynamic DMA windows (DDW) RTAS calls support
Date: Fri, 15 Aug 2014 10:04:07 +1000 [thread overview]
Message-ID: <20140815000407.GK7628@voom.redhat.com> (raw)
In-Reply-To: <53EC737E.4080203@ozlabs.ru>
[-- Attachment #1: Type: text/plain, Size: 4239 bytes --]
On Thu, Aug 14, 2014 at 06:29:50PM +1000, Alexey Kardashevskiy wrote:
> On 08/13/2014 01:27 PM, David Gibson wrote:
> > On Tue, Aug 12, 2014 at 05:25:29PM +1000, Alexey Kardashevskiy wrote:
> >> On 08/12/2014 11:45 AM, David Gibson wrote:
> >>> On Thu, Jul 31, 2014 at 07:34:10PM +1000, Alexey Kardashevskiy
> >> wrote:
> > [snip]
> >>> The function of this is kind of unclear. I'm assuming this is
> >>> filtering the supported page sizes reported by the PHB by the possible
> >>> page sizes based on host page size or other constraints. Is that
> >>> right?
> >>>
> >>> I think you'd be better off folding the whole double loop into the
> >>> fixmask function.
> >>>
> >>>> +
> >>>> + rtas_st(rets, 0, RTAS_OUT_SUCCESS);
> >>>> + rtas_st(rets, 1, windows_available);
> >>>> + /* Return maximum number as all RAM was 4K pages */
> >>>> + rtas_st(rets, 2, ram_size >> SPAPR_TCE_PAGE_SHIFT);
> >>>
> >>> I'm assuming this is the allowed size of the dynamic windows.
> >>> Shouldn't that be reported by a PHB callback, rather than hardcoded
> >>> here?
> >>
> >> Why PHB? This is DMA memory. @ram_size is the upper limit, we can make more
> >> only when we have memory hotplug (which we do not have) and the guest can
> >> create smaller windows if it wants so I do not really follow you here.
> >
> > What I'm not clear on is what this RTAS return actually means. Is it
> > saying the maximum size of the DMA window, or the maximum address
> > which can be mapped by that window? Remember I don't have access to
> > PAPR documentation any more - nor do others reading these patches.
>
>
> It is literally "Largest contiguous block of TCEs allocated specifically
> for (that is, are reserved for) this PE". Which I understand as the maximum
> number of TCEs.
Ok, so essentially it's a property of the IOMMU. Hrm, I guess
ram_size is good enough for now then.
[snip]
> > [snip]
> >>>> +static void rtas_ibm_create_pe_dma_window(PowerPCCPU *cpu,
> >>>> + sPAPREnvironment *spapr,
> >>>> + uint32_t token, uint32_t nargs,
> >>>> + target_ulong args,
> >>>> + uint32_t nret, target_ulong rets)
> >>>> +{
> >>>> + sPAPRPHBState *sphb;
> >>>> + sPAPRPHBClass *spc;
> >>>> + sPAPRTCETable *tcet = NULL;
> >>>> + uint32_t addr, page_shift, window_shift, liobn;
> >>>> + uint64_t buid;
> >>>> + long ret;
> >>>> +
> >>>> + if ((nargs != 5) || (nret != 4)) {
> >>>> + goto param_error_exit;
> >>>> + }
> >>>> +
> >>>> + buid = ((uint64_t)rtas_ld(args, 1) << 32) | rtas_ld(args, 2);
> >>>> + addr = rtas_ld(args, 0);
> >>>> + sphb = spapr_pci_find_phb(spapr, buid);
> >>>> + if (!sphb) {
> >>>> + goto param_error_exit;
> >>>> + }
> >>>> +
> >>>> + spc = SPAPR_PCI_HOST_BRIDGE_GET_CLASS(sphb);
> >>>> + if (!spc->ddw_create) {
> >>>> + goto hw_error_exit;
> >>>> + }
> >>>> +
> >>>> + page_shift = rtas_ld(args, 3);
> >>>> + window_shift = rtas_ld(args, 4);
> >>>> + liobn = sphb->dma_liobn + 0x10000;
> >>>
> >>> Isn't using a fixed LIOBN here assuming you can only have a single DDW
> >>> per PHB? That's true for now, but in theory shouldn't it be reported
> >>> by the PHB code itself?
> >>
> >>
> >> This should be a unique LIOBN so it is not up to PHB to choose. And we
> >> cannot make it completely random for migration purposes. I'll make it
> >> something like
> >>
> >> #define SPAPR_DDW_LIOBN(sphb, windownum) ((sphb)->dma_liobn | windownum)
> >
> > Ok.
> >
> > Really, the assigned liobns should be included in the migration stream
> > if they're not already.
>
> LIOBNs already migrate, liobn itself is an instance id of a TCE table
> object in the migration stream.
Ok, so couldn't we just add an alloc_liobn() function instead of
hardcoding how the liobns are constructed?
--
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 --]
next prev parent reply other threads:[~2014-08-15 0:11 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-31 9:34 [Qemu-devel] [RFC PATCH 00/10] spapr: vfio: Enable Dynamic DMA windows (DDW) Alexey Kardashevskiy
2014-07-31 9:34 ` [Qemu-devel] [RFC PATCH 01/10] qom: Make object_child_foreach safe for objects removal Alexey Kardashevskiy
2014-07-31 9:34 ` [Qemu-devel] [RFC PATCH 02/10] spapr_iommu: Disable in-kernel IOMMU tables for >4GB windows Alexey Kardashevskiy
2014-08-12 1:17 ` David Gibson
2014-08-12 7:32 ` Alexey Kardashevskiy
2014-07-31 9:34 ` [Qemu-devel] [RFC PATCH 03/10] spapr_pci: Make find_phb()/find_dev() public Alexey Kardashevskiy
2014-08-11 11:39 ` Alexander Graf
2014-08-11 14:56 ` Alexey Kardashevskiy
2014-08-11 17:16 ` Alexander Graf
2014-08-12 1:19 ` David Gibson
2014-07-31 9:34 ` [Qemu-devel] [RFC PATCH 04/10] spapr_iommu: Make spapr_tce_find_by_liobn() public Alexey Kardashevskiy
2014-08-12 1:19 ` David Gibson
2014-07-31 9:34 ` [Qemu-devel] [RFC PATCH 05/10] linux headers update for DDW Alexey Kardashevskiy
2014-08-12 1:20 ` David Gibson
2014-08-12 7:16 ` Alexey Kardashevskiy
2014-08-13 3:23 ` David Gibson
2014-07-31 9:34 ` [Qemu-devel] [RFC PATCH 06/10] spapr_rtas: Add Dynamic DMA windows (DDW) RTAS calls support Alexey Kardashevskiy
2014-08-11 11:51 ` Alexander Graf
2014-08-11 15:34 ` Alexey Kardashevskiy
2014-08-12 1:45 ` David Gibson
2014-08-12 7:25 ` Alexey Kardashevskiy
2014-08-13 3:27 ` David Gibson
2014-08-14 8:29 ` Alexey Kardashevskiy
2014-08-15 0:04 ` David Gibson [this message]
2014-08-15 3:09 ` Alexey Kardashevskiy
2014-08-15 4:20 ` David Gibson
2014-08-15 5:27 ` Alexey Kardashevskiy
2014-08-15 5:30 ` David Gibson
2014-07-31 9:34 ` [Qemu-devel] [RFC PATCH 07/10] spapr: Add "ddw" machine option Alexey Kardashevskiy
2014-07-31 9:34 ` [Qemu-devel] [RFC PATCH 08/10] spapr_pci: Enable DDW Alexey Kardashevskiy
2014-08-11 11:59 ` Alexander Graf
2014-08-11 15:26 ` Alexey Kardashevskiy
2014-08-11 17:29 ` Alexander Graf
2014-08-12 0:13 ` Alexey Kardashevskiy
2014-08-12 3:59 ` Alexey Kardashevskiy
2014-08-12 9:36 ` Alexander Graf
2014-08-12 2:10 ` David Gibson
2014-07-31 9:34 ` [Qemu-devel] [RFC PATCH 09/10] spapr_pci_vfio: " Alexey Kardashevskiy
2014-08-11 12:02 ` Alexander Graf
2014-08-11 15:01 ` Alexey Kardashevskiy
2014-08-11 17:30 ` Alexander Graf
2014-08-12 0:03 ` Alexey Kardashevskiy
2014-08-12 9:37 ` Alexander Graf
2014-08-12 15:10 ` Alexey Kardashevskiy
2014-08-12 15:28 ` Alexander Graf
2014-08-13 0:18 ` Alexey Kardashevskiy
2014-08-14 13:38 ` Alexander Graf
2014-08-15 0:09 ` David Gibson
2014-08-15 3:22 ` Alexey Kardashevskiy
2014-08-15 3:16 ` Alexey Kardashevskiy
2014-08-15 7:37 ` Alexander Graf
2014-08-12 2:14 ` David Gibson
2014-07-31 9:34 ` [Qemu-devel] [RFC PATCH 10/10] vfio: Enable DDW ioctls to VFIO IOMMU driver Alexey Kardashevskiy
2014-08-05 1:30 ` [Qemu-devel] [RFC PATCH 00/10] spapr: vfio: Enable Dynamic DMA windows (DDW) Alexey Kardashevskiy
2014-08-10 23:50 ` 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=20140815000407.GK7628@voom.redhat.com \
--to=david@gibson.dropbear.id.au \
--cc=agraf@suse.de \
--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 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).