qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: David Gibson <david@gibson.dropbear.id.au>
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 15:27:42 +1000	[thread overview]
Message-ID: <53ED9A4E.5000600@ozlabs.ru> (raw)
In-Reply-To: <20140815042052.GN7628@voom.redhat.com>

On 08/15/2014 02:20 PM, David Gibson wrote:
> On Fri, Aug 15, 2014 at 01:09:20PM +1000, Alexey Kardashevskiy wrote:
>> On 08/15/2014 10:04 AM, David Gibson wrote:
>>> 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?
>>
>>
>> No. If we did so, exact numbers would depend on the device order in the
>> QEMU command line - QEMU command line produced by libvirt from handmade XML
>> and QEMU command line produced by libvirt from XML printed by "dumpxml" can
>> have devices in different order, so interrupt numbers, LIOBNs - all of this
>> gets broken.
> 
> Ah, duh.  Clearly I'm still swapping back in my knowledge of qemu
> migration.
> 
> What I was meaning before is that qemu should reconstruct the TCE
> tables / liobns based on the info in the migration stream, which
> remains true, but it can't really be done without more broadly
> addressing the fact that qemu doesn't transmit the hardware
> configuration in the migration stream.
> 
> Ok, so what should probably be done here is to explicitly assign
> fields in the LIOBN to "device type", "device id" (vio reg or PHB
> buid), and per-device instance (DDW number for PCI).
> 

Yes, this is my new queue:

------------------------------ hw/ppc/spapr_pci.c
------------------------------
index 5c46c0d..17eb0d8 100644
@@ -527,11 +527,11 @@ static void spapr_phb_realize(DeviceState *dev, Error
**errp)
                        " be specified for PAPR PHB, not both");
             return;
         }

         sphb->buid = SPAPR_PCI_BASE_BUID + sphb->index;
-        sphb->dma_liobn = SPAPR_PCI_BASE_LIOBN + sphb->index;
+        sphb->dma_liobn = SPAPR_PCI_LIOBN(sphb->index, 0);

         windows_base = SPAPR_PCI_WINDOW_BASE
             + sphb->index * SPAPR_PCI_WINDOW_SPACING;
         sphb->mem_win_addr = windows_base + SPAPR_PCI_MMIO_WIN_OFF;
         sphb->io_win_addr = windows_base + SPAPR_PCI_IO_WIN_OFF;

---------------------------- include/hw/ppc/spapr.h
----------------------------
index c9d6c6c..92c6e2c 100644
@@ -441,11 +441,11 @@ int spapr_rtas_device_tree_setup(void *fdt, hwaddr
rtas_addr,
 #define SPAPR_TCE_PAGE_SHIFT   12
 #define SPAPR_TCE_PAGE_SIZE    (1ULL << SPAPR_TCE_PAGE_SHIFT)
 #define SPAPR_TCE_PAGE_MASK    (SPAPR_TCE_PAGE_SIZE - 1)

 #define SPAPR_VIO_BASE_LIOBN    0x00000000
-#define SPAPR_PCI_BASE_LIOBN    0x80000000
+#define SPAPR_PCI_LIOBN(i, n)   (0x80000000 | ((i) << 8) | (n))

 #define RTAS_ERROR_LOG_MAX      2048




-- 
Alexey

  reply	other threads:[~2014-08-15  5:28 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
2014-08-15  3:09             ` Alexey Kardashevskiy
2014-08-15  4:20               ` David Gibson
2014-08-15  5:27                 ` Alexey Kardashevskiy [this message]
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=53ED9A4E.5000600@ozlabs.ru \
    --to=aik@ozlabs.ru \
    --cc=agraf@suse.de \
    --cc=alex.williamson@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --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).