qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RESEND v7 0/3] Red Hat PCI bridge resource reser


From: Marcel Apfelbaum
Subject: Re: [Qemu-devel] [PATCH RESEND v7 0/3] Red Hat PCI bridge resource reserve capability
Date: Sun, 10 Sep 2017 22:40:27 +0300
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1

On 10/09/2017 21:34, Aleksandr Bezzubikov wrote:

пт, 18 авг. 2017 г. в 2:33, Aleksandr Bezzubikov <address@hidden <mailto:address@hidden>>:

    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 v6->v7:
    0. Resend - fix a bug with incorrect subordinate bus default value.
    1. Do not use alignment in case of IO reservation cap usage.
    2. Log additional buses reservation events.

    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 resources on PCI
         init

      src/fw/dev-pci.h    |  53 ++++++++++++++++++++++++++
      src/fw/pciinit.c    | 108
    +++++++++++++++++++++++++++++++++++++++++++++++++---
      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, 188 insertions(+), 33 deletions(-)
      create mode 100644 src/fw/dev-pci.h

    --
    2.7.4


And what about this series? The matching QEMU series has been applied, that's why there should be no problems with picking this series up for SeaBIOS


Hi Aleksandr,

Since SeaBIOS is a different project, we need to monitor the QEMU
patches by ourselves and only then ask the maintainer to merge the
patches if he has no objections, of course. (no automated process)

Can you please verify the series still applies to SeaBIOS AS IS
and run a quick test against today's QEMU master branch?
Can you please give Kevin your OK before he proceeds with the merge?

Thanks,
Marcel


--
Aleksandr Bezzubikov




reply via email to

[Prev in Thread] Current Thread [Next in Thread]