From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: Laurent Vivier <lvivier@redhat.com>,
David Gibson <david@gibson.dropbear.id.au>
Cc: thuth@redhat.com, gwshan@linux.vnet.ibm.com,
qemu-devel@nongnu.org, alex.williamson@redhat.com,
qemu-ppc@nongnu.org, pbonzini@redhat.com
Subject: Re: [Qemu-devel] [RFC PATCH 07/10] spapr_pci: Allow PCI host bridge DMA window to be configured
Date: Sat, 3 Oct 2015 10:25:13 +1000 [thread overview]
Message-ID: <560F2069.5030902@ozlabs.ru> (raw)
In-Reply-To: <56039F55.6040907@redhat.com>
On 09/24/2015 04:59 PM, Laurent Vivier wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> On 24/09/2015 01:54, David Gibson wrote:
>> On Wed, Sep 23, 2015 at 08:55:01PM +0200, Laurent Vivier wrote:
>>>
>>>
>>> On 17/09/2015 15:09, David Gibson wrote:
>>>> At present the PCI host bridge (PHB) for the pseries machine
>>>> type has a fixed DMA window from 0..1GB (in PCI address space)
>>>> which is mapped to real memory via the PAPR paravirtualized
>>>> IOMMU.
>>>>
>>>> For better support of VFIO devices, we're going to want to
>>>> allow for different configurations of the DMA window.
>>>>
>>>> Eventually we'll want to allow the guest itself to reconfigure
>>>> the window via the PAPR dynamic DMA window interface, but as a
>>>> preliminary this patch allows the user to reconfigure the
>>>> window with new properties on the PHB device.
>>>>
>>>> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> ---
>>>> hw/ppc/spapr_pci.c | 7 +++++--
>>>> include/hw/pci-host/spapr.h | 3 +-- 2 files changed, 6
>>>> insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c index
>>>> b088491..622c4ac 100644 --- a/hw/ppc/spapr_pci.c +++
>>>> b/hw/ppc/spapr_pci.c @@ -1394,7 +1394,7 @@ static void
>>>> spapr_phb_finish_realize(sPAPRPHBState *sphb, Error **errp)
>>>> sPAPRTCETable *tcet; uint32_t nb_table;
>>>>
>>>> - nb_table = SPAPR_PCI_DMA32_SIZE >> SPAPR_TCE_PAGE_SHIFT; +
>>>> nb_table = sphb->dma_win_size >> SPAPR_TCE_PAGE_SHIFT; tcet =
>>>> spapr_tce_new_table(DEVICE(sphb), sphb->dma_liobn, 0,
>>>> SPAPR_TCE_PAGE_SHIFT, nb_table, false); if (!tcet) { @@ -1404,7
>>>> +1404,7 @@ static void spapr_phb_finish_realize(sPAPRPHBState
>>>> *sphb, Error **errp) }
>>>>
>>>> /* Register default 32bit DMA window */ -
>>>> memory_region_add_subregion(&sphb->iommu_root, 0, +
>>>> memory_region_add_subregion(&sphb->iommu_root,
>>>> sphb->dma_win_addr, spapr_tce_get_iommu(tcet)); }
>>>>
>>>> @@ -1437,6 +1437,9 @@ static Property spapr_phb_properties[] =
>>>> { SPAPR_PCI_IO_WIN_SIZE),
>>>> DEFINE_PROP_BOOL("dynamic-reconfiguration", sPAPRPHBState,
>>>> dr_enabled, true), + /* Default DMA window is 0..1GB */ +
>>>> DEFINE_PROP_UINT64("dma_win_addr", sPAPRPHBState, dma_win_addr,
>>>> 0), + DEFINE_PROP_UINT64("dma_win_size", sPAPRPHBState,
>>>> dma_win_size, 0x40000000), DEFINE_PROP_END_OF_LIST(), };
>>>
>>> Add them too to the vmstate_spapr_pci ?
>>
>> No. At least, not just now.
>>
>> This is the sort of configuration information that typically isn't
>> migrated, instead requiring the far end to be set up matching.
>> Which
>
> I think this is the aim of VMSTATE_UINT64_EQUAL() ?
We use it only for things which cannot be set via the command line and
ideally there should be no VMSTATE_*_EQUAL. If something can be set via the
command line, then the management software (read - libvirt) runs QEMU with
explicit parameters to guarantee that these are equal. Checking it in
VMSTATE is too late when migrating with full disk copy - it takes a lot of
time before the destination QEMU discovers that it cannot actually run.
>
>> is a problem, but not one within the scope of this patch series.
>> In any case just transferring the values wouldn't be enough - we'd
>> need post_load handlers to actually rewire the TCE table
>> accordingly.
>>
>> We will need to do this once we add dynamic DMA window support,
>> but again, not in scope just now.
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iEYEARECAAYFAlYDn1UACgkQNKT2yavzbFM20ACfcUVIPLObcYh4y5U8CcoLVGoO
> FR8AoOgigTMFu7FOh7wI8U+fGNtYv6Ji
> =4opa
> -----END PGP SIGNATURE-----
>
--
Alexey
next prev parent reply other threads:[~2015-10-03 0:25 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-17 13:09 [Qemu-devel] [RFC PATCH 00/10] pseries: Allow VFIO devices on spapr-pci-host-bridge David Gibson
2015-09-17 13:09 ` [Qemu-devel] [RFC PATCH 01/10] vfio: Remove unneeded union from VFIOContainer David Gibson
2015-09-18 6:15 ` Alexey Kardashevskiy
2015-09-23 10:31 ` Thomas Huth
2015-09-23 23:14 ` David Gibson
2015-09-23 13:18 ` Laurent Vivier
2015-09-17 13:09 ` [Qemu-devel] [RFC PATCH 02/10] vfio: Generalize vfio_listener_region_add failure path David Gibson
2015-09-23 9:13 ` Thomas Huth
2015-09-23 13:31 ` Laurent Vivier
2015-09-17 13:09 ` [Qemu-devel] [RFC PATCH 03/10] vfio: Check guest IOVA ranges against host IOMMU capabilities David Gibson
2015-09-18 6:38 ` Alexey Kardashevskiy
2015-09-23 10:10 ` Thomas Huth
2015-09-23 11:07 ` David Gibson
2015-09-23 23:43 ` David Gibson
2015-09-23 14:26 ` Laurent Vivier
2015-09-17 13:09 ` [Qemu-devel] [RFC PATCH 04/10] vfio: Record host IOMMU's available IO page sizes David Gibson
2015-09-23 10:29 ` Thomas Huth
2015-09-23 14:30 ` Laurent Vivier
2015-09-17 13:09 ` [Qemu-devel] [RFC PATCH 05/10] memory: Allow replay of IOMMU mapping notifications David Gibson
2015-09-23 10:40 ` Thomas Huth
2015-09-23 16:35 ` Laurent Vivier
2015-09-23 23:47 ` David Gibson
2015-09-23 17:04 ` Laurent Vivier
2015-09-23 23:50 ` David Gibson
2015-09-24 7:09 ` Laurent Vivier
2015-09-17 13:09 ` [Qemu-devel] [RFC PATCH 06/10] vfio: Allow hotplug of containers onto existing guest IOMMU mappings David Gibson
2015-09-17 16:54 ` Alex Williamson
2015-09-17 23:31 ` David Gibson
2015-09-23 11:02 ` Thomas Huth
2015-09-23 23:50 ` David Gibson
2015-09-23 18:44 ` Laurent Vivier
2015-09-17 13:09 ` [Qemu-devel] [RFC PATCH 07/10] spapr_pci: Allow PCI host bridge DMA window to be configured David Gibson
2015-09-23 11:08 ` Thomas Huth
2015-09-23 23:56 ` David Gibson
2015-09-23 18:55 ` Laurent Vivier
2015-09-23 23:54 ` David Gibson
2015-09-24 6:59 ` Laurent Vivier
2015-10-03 0:25 ` Alexey Kardashevskiy [this message]
2015-10-05 14:13 ` Paolo Bonzini
2015-10-06 3:25 ` David Gibson
2015-10-06 4:18 ` David Gibson
2015-09-17 13:09 ` [Qemu-devel] [RFC PATCH 08/10] spapr_iommu: Rename vfio_accel parameter David Gibson
2015-09-17 16:54 ` Alex Williamson
2015-09-17 23:34 ` David Gibson
2015-09-17 13:09 ` [Qemu-devel] [RFC PATCH 09/10] spapr_iommu: Provide a function to switch a TCE table to allowing VFIO David Gibson
2015-09-17 16:54 ` Alex Williamson
2015-09-23 11:24 ` Thomas Huth
2015-09-24 0:35 ` David Gibson
2015-09-17 13:09 ` [Qemu-devel] [RFC PATCH 10/10] spapr_pci: Allow VFIO devices to work on the normal PCI host bridge David Gibson
2015-09-17 16:54 ` [Qemu-devel] [RFC PATCH 00/10] pseries: Allow VFIO devices on spapr-pci-host-bridge Alex Williamson
2015-09-23 11:26 ` Thomas Huth
2015-09-23 16:46 ` Laurent Vivier
2015-09-24 1:02 ` David Gibson
2015-09-24 7:02 ` Laurent Vivier
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=560F2069.5030902@ozlabs.ru \
--to=aik@ozlabs.ru \
--cc=alex.williamson@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=gwshan@linux.vnet.ibm.com \
--cc=lvivier@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=thuth@redhat.com \
/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).