From: Marcel Apfelbaum <marcel@redhat.com>
To: Aleksandr Bezzubikov <zuban32s@gmail.com>, seabios@seabios.org
Cc: mst@redhat.com, kevin@koconnor.net, kraxel@redhat.com,
lersek@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v6 0/3] Red Hat PCI bridge resource reserve capability
Date: Wed, 16 Aug 2017 13:36:56 +0300 [thread overview]
Message-ID: <53132fbe-ab14-6708-a682-bb5bf2244db0@redhat.com> (raw)
In-Reply-To: <1502640203-15577-1-git-send-email-zuban32s@gmail.com>
On 13/08/2017 19:03, Aleksandr Bezzubikov wrote:
> Now PCI bridges get a bus range number on a system init,
> basing on currently plugged devices. That's why when one wants to hotplug another bridge,
> it needs his child bus, which the parent is unable to provide (speaking about virtual device).
> The suggested workaround is to have vendor-specific capability in Red Hat PCI bridges
> that contains number of additional bus to reserve (as well as IO/MEM/PREF space limit hints)
> on BIOS PCI init.
> So this capability is intended only for pure QEMU->SeaBIOS usage.
>
> Considering all aforesaid, this series is directly connected with
> QEMU series "Generic PCIE-PCI Bridge".
>
> Although the new PCI capability is supposed to contain various limits along with
> bus number to reserve, now only its full layout is proposed. And
> only bus_reserve field is used in QEMU and BIOS. Limits usage
> is still a subject for implementation as now
> the main goal of this series to provide necessary support from the
> firmware side to PCIE-PCI bridge hotplug.
>
> Changes v5->v6:
> 1. Remove unnecessary indents and line breaks (addresses Marcel's comments)
> 2. Count IO/MEM/PREF region size as a maximum of necessary size and one provide in
> RESOURCE_RESERVE capability (addresses Marcel's comment).
> 3. Make the cap debug message more detailed (addresses Marcel's comment).
> 4. Change pref_32 and pref_64 cap fields comment.
>
> Changes v4->v5:
> 1. Rename capability-related #defines
> 2. Move capability IO/MEM/PREF fields values usage to the regions creation stage (addresses Marcel's comment)
> 3. The capability layout change: separate pref_mem into pref_mem_32 and pref_mem_64 fields (QEMU side has the same changes) (addresses Laszlo's comment)
> 4. Extract the capability lookup and check to the separate function (addresses Marcel's comment)
> - despite of Marcel's comment do not extract field check for -1 since it increases code length
> and doesn't look nice because of different field types
> 5. Fix the capability's comment (addresses Marcel's comment)
> 6. Fix the 3rd patch message
>
> Changes v3->v4:
> 1. Use all QEMU PCI capability fields - addresses Michael's comment
> 2. Changes of the capability layout (QEMU side has the same changes):
> - change reservation fields types: bus_res - uint32_t, others - uint64_t
> - interpret -1 value as 'ignore'
>
> Changes v2->v3:
> 1. Merge commit 2 (Red Hat vendor ID) into commit 4 - addresses Marcel's comment,
> and add Generic PCIE Root Port device ID - addresses Michael's comment.
> 2. Changes of the capability layout (QEMU side has the same changes):
> - add 'type' field to distinguish multiple
> RedHat-specific capabilities - addresses Michael's comment
> - do not mimiс PCI Config space register layout, but use mutually exclusive differently
> sized fields for IO and prefetchable memory limits - addresses Laszlo's comment
> - use defines instead of structure and offsetof - addresses Michael's comment
> 3. Interpret 'bus_reserve' field as a minimum necessary
> range to reserve - addresses Gerd's comment
> 4. pci_find_capability moved to pci.c - addresses Kevin's comment
> 5. Move capability layout header to src/fw/dev-pci.h - addresses Kevin's comment
> 6. Add the capability documentation - addresses Michael's comment
> 7. Add capability length and bus_reserve field sanity checks - addresses Michael's comment
>
> Changes v1->v2:
> 1. New #define for Red Hat vendor added (addresses Konrad's comment).
> 2. Refactored pci_find_capability function (addresses Marcel's comment).
> 3. Capability reworked:
> - data type added;
> - reserve space in a structure for IO, memory and
> prefetchable memory limits.
>
> Aleksandr Bezzubikov (3):
> pci: refactor pci_find_capapibilty to get bdf as the first argument
> instead of the whole pci_device
> pci: add QEMU-specific PCI capability structure
> pci: enable RedHat PCI bridges to reserve additional resource on PCI
> init
>
> src/fw/dev-pci.h | 53 +++++++++++++++++++++++++++
> src/fw/pciinit.c | 101 +++++++++++++++++++++++++++++++++++++++++++++++++---
> src/hw/pci.c | 25 +++++++++++++
> src/hw/pci.h | 1 +
> src/hw/pci_ids.h | 3 ++
> src/hw/pcidevice.c | 24 -------------
> src/hw/pcidevice.h | 1 -
> src/hw/virtio-pci.c | 6 ++--
> 8 files changed, 181 insertions(+), 33 deletions(-)
> create mode 100644 src/fw/dev-pci.h
>
Hi,
Series
Tested-by: Marcel Apfelbaum <marcel@redhat.com>
Tested with Win10 and Fedora guests, verified the bus/io/mem hints
are working correctly.
Thanks,
Marcel
prev parent reply other threads:[~2017-08-16 10:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-13 16:03 [Qemu-devel] [PATCH v6 0/3] Red Hat PCI bridge resource reserve capability Aleksandr Bezzubikov
2017-08-13 16:03 ` [Qemu-devel] [PATCH v6 1/3] pci: refactor pci_find_capapibilty to get bdf as the first argument instead of the whole pci_device Aleksandr Bezzubikov
2017-08-13 16:03 ` [Qemu-devel] [PATCH v6 2/3] pci: add QEMU-specific PCI capability structure Aleksandr Bezzubikov
2017-08-16 9:54 ` Marcel Apfelbaum
2017-08-13 16:03 ` [Qemu-devel] [PATCH v6 3/3] pci: enable RedHat PCI bridges to reserve additional resource on PCI init Aleksandr Bezzubikov
2017-08-16 10:34 ` Marcel Apfelbaum
2017-08-16 10:36 ` Marcel Apfelbaum [this message]
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=53132fbe-ab14-6708-a682-bb5bf2244db0@redhat.com \
--to=marcel@redhat.com \
--cc=kevin@koconnor.net \
--cc=kraxel@redhat.com \
--cc=lersek@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=seabios@seabios.org \
--cc=zuban32s@gmail.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).