qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Auger <eric.auger@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: eric.auger@st.com,
	Pranav Sawargaonkar <pranav.sawargaonkar@gmail.com>,
	Pavel Fedin <p.fedin@samsung.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Alexander Graf <agraf@suse.de>,
	Bharat Bhushan <Bharat.Bhushan@freescale.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	qemu-arm <qemu-arm@nongnu.org>,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Christoffer Dall <christoffer.dall@linaro.org>
Subject: Re: [Qemu-devel] [RFC v2 7/8] hw: arm: virt: register reserved IOVA region
Date: Thu, 18 Feb 2016 19:48:43 +0100	[thread overview]
Message-ID: <56C6120B.3040005@linaro.org> (raw)
In-Reply-To: <CAFEAcA87ZXSHDE4v5udfWGH15xGGAFNQGBCzm2TcnFEP0LLutg@mail.gmail.com>

Hi Peter,
On 02/16/2016 07:21 PM, Peter Maydell wrote:
> On 29 January 2016 at 16:53, Eric Auger <eric.auger@linaro.org> wrote:
>> Registers a 16x64kB reserved iova region. Currently this iova
>> region is used by the host kernel to map host MSI controller frames
>> (GICv2m, GITS_TRANSLATER). The host kernel needs this iova window
>> since it cannot program the PCIe device with MSI frame physical
>> address (as opposed to x86) since the MSI write transactions go
>> through the IOMMU.
>>
>> The reserved region is mapped on the platform bus.
> 
> I guess that keeps it neatly out of the way of everybody else :-)
Yes hopefully. The platform bus has its own MMIO allocation scheme.
> 
>> Signed-off-by: Eric Auger <eric.auger@linaro.org>
>>
>> ---
>>
>> RFC v1 -> RFC v2:
>> - use the platform bus to map the reserved iova region
>> ---
>>  hw/arm/virt.c | 19 ++++++++++++++-----
>>  1 file changed, 14 insertions(+), 5 deletions(-)
>>
>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>> index 3839c68..4b2a891 100644
>> --- a/hw/arm/virt.c
>> +++ b/hw/arm/virt.c
>> @@ -805,7 +805,7 @@ static void create_pcie_irq_map(const VirtBoardInfo *vbi, uint32_t gic_phandle,
>>  }
>>
>>  static void create_pcie(const VirtBoardInfo *vbi, qemu_irq *pic,
>> -                        bool use_highmem)
>> +                        bool use_highmem, MemoryRegion **reserved_reg)
>>  {
>>      hwaddr base_mmio = vbi->memmap[VIRT_PCIE_MMIO].base;
>>      hwaddr size_mmio = vbi->memmap[VIRT_PCIE_MMIO].size;
>> @@ -920,10 +920,16 @@ static void create_pcie(const VirtBoardInfo *vbi, qemu_irq *pic,
>>      qemu_fdt_setprop_cell(vbi->fdt, nodename, "#interrupt-cells", 1);
>>      create_pcie_irq_map(vbi, vbi->gic_phandle, irq, nodename);
>>
>> +    /* initialize the reserved iova region for MSI binding (16 x 64kb) */
>> +    *reserved_reg = g_new0(MemoryRegion, 1);
>> +    memory_region_init_reserved_iova(*reserved_reg, OBJECT(dev),
>> +                                     "reserved-iova",
>> +                                     0x100000, &error_fatal);
> 
> So the only reason this is here is because we need to have a pointer to
> the PCIe controller DeviceState, right?
yes that's correct. currently the PCIe controller is the object that
tracks the reserved region's ref count. I proceeded that way because the
reserved IOVA provision currently is related to PCIe/MSI functionality.

 I think it would be better to
> make create_pcie() return the DeviceState* instead of NULL. Then you
> can either (a) pass the pcie controller pointer into create_platform_bus()
> and have that create and map the reserved iova region, or (b) have a
> separate function to create the reserved iova region. In any case I
> think it fits more naturally with the rest of the platform bus code
> rather than in the PCIe controller creation function.
OK

Another issue is that we currently book an arbitrary 1MB IOVA window
whatever the needs. We are also thinking about extending the VFIO user
API to return the number of reserved iova pages that are requested and
possibly some alignment constraints. Then it becomes more complex since
VFIO devices are instantiated after the machine creation, all the needs
must be collected and consolidated and eventually the reserved iova
region can be created. So I think that code will end up somewhere in a
machine init done notifier ...

Thanks for the review!

Best Regards

Eric
> 
> thanks
> -- PMM
> 

  reply	other threads:[~2016-02-18 18:49 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-29 16:53 [Qemu-devel] [RFC v2 0/8] KVM PCI/MSI passthrough with mach-virt Eric Auger
2016-01-29 16:53 ` [Qemu-devel] [RFC v2 1/8] linux-headers: partial update for VFIO reserved IOVA registration Eric Auger
2016-01-29 16:53 ` [Qemu-devel] [RFC v2 2/8] Add a function to determine interrupt number for INTx routing Eric Auger
2016-01-29 16:53 ` [Qemu-devel] [RFC v2 3/8] Generic PCIe host bridge INTx determination " Eric Auger
2016-02-16 18:14   ` Peter Maydell
2016-02-18 18:15     ` Eric Auger
2016-01-29 16:53 ` [Qemu-devel] [RFC v2 4/8] hw: vfio: common: introduce vfio_register_reserved_iova Eric Auger
2016-01-29 16:53 ` [Qemu-devel] [RFC v2 5/8] memory: add reserved_iova region type Eric Auger
2016-01-29 16:53 ` [Qemu-devel] [RFC v2 6/8] hw: platform-bus: enable to map any memory region onto the platform-bus Eric Auger
2016-02-16 18:16   ` Peter Maydell
2016-01-29 16:53 ` [Qemu-devel] [RFC v2 7/8] hw: arm: virt: register reserved IOVA region Eric Auger
2016-02-16 18:21   ` Peter Maydell
2016-02-18 18:48     ` Eric Auger [this message]
2016-01-29 16:53 ` [Qemu-devel] [RFC v2 8/8] hw: vfio: common: adapt vfio_listeners for reserved_iova region Eric Auger
2016-02-16 18:23 ` [Qemu-devel] [RFC v2 0/8] KVM PCI/MSI passthrough with mach-virt Peter Maydell
2016-05-04 11:18 ` Yehuda Yitschak

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=56C6120B.3040005@linaro.org \
    --to=eric.auger@linaro.org \
    --cc=Bharat.Bhushan@freescale.com \
    --cc=agraf@suse.de \
    --cc=alex.williamson@redhat.com \
    --cc=christoffer.dall@linaro.org \
    --cc=eric.auger@st.com \
    --cc=p.fedin@samsung.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=pranav.sawargaonkar@gmail.com \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=suravee.suthikulpanit@amd.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).