[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH v2 4/6] hw/pci: introduce bridge-only vendor
From: |
Marcel Apfelbaum |
Subject: |
Re: [Qemu-devel] [RFC PATCH v2 4/6] hw/pci: introduce bridge-only vendor-specific capability to provide some hints to firmware |
Date: |
Sun, 23 Jul 2017 19:24:22 +0300 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 |
On 23/07/2017 19:19, Alexander Bezzubikov wrote:
2017-07-23 18:57 GMT+03:00 Marcel Apfelbaum <address@hidden
<mailto:address@hidden>>:
On 23/07/2017 1:15, Aleksandr Bezzubikov wrote:
On PCI init PCI bridges may need some
extra info about bus number to reserve, IO, memory and
prefetchable memory limits. QEMU can provide this
with special vendor-specific PCI capability.
Sizes of limits match ones from
PCI Type 1 Configuration Space Header,
number of buses to reserve occupies only 1 byte
since it is the size of Subordinate Bus Number register.
Hi Alexandr,
Signed-off-by: Aleksandr Bezzubikov <address@hidden
<mailto:address@hidden>>
---
hw/pci/pci_bridge.c | 27 +++++++++++++++++++++++++++
include/hw/pci/pci_bridge.h | 18 ++++++++++++++++++
2 files changed, 45 insertions(+)
diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c
index 720119b..8ec6c2c 100644
--- a/hw/pci/pci_bridge.c
+++ b/hw/pci/pci_bridge.c
@@ -408,6 +408,33 @@ void pci_bridge_map_irq(PCIBridge *br,
const char* bus_name,
br->bus_name = bus_name;
}
+
+int pci_bridge_help_cap_init(PCIDevice *dev, int cap_offset,
Can you please rename to something like
'pci_bridge_qemu_cap_init' to be more specific?
+ uint8_t bus_reserve, uint32_t
io_limit,
+ uint16_t mem_limit, uint64_t
pref_limit,
I am not sure regarding "limit" suffix, this
is a reservation, not a limitation.
I'd like this fields names to match actual registers which
are going to get the values.
For this case I think is better to have io_res..., to describe
the parameter rather than match the registers.
+ Error **errp)
+{
+ size_t cap_len = sizeof(PCIBridgeQemuCap);
+ PCIBridgeQemuCap cap;
+
+ cap.len = cap_len;
+ cap.bus_res = bus_reserve;
+ cap.io_lim = io_limit & 0xFF;
+ cap.io_lim_upper = io_limit >> 8 & 0xFFFF;
+ cap.mem_lim = mem_limit;
+ cap.pref_lim = pref_limit & 0xFFFF;
+ cap.pref_lim_upper = pref_limit >> 16 & 0xFFFFFFFF;
+
+ int offset = pci_add_capability(dev, PCI_CAP_ID_VNDR,
+ cap_offset, cap_len, errp);
+ if (offset < 0) {
+ return offset;
+ }
+
+ memcpy(dev->config + offset + 2, (char *)&cap + 2, cap_len
- 2);
+ return 0;
+}
+
static const TypeInfo pci_bridge_type_info = {
.name = TYPE_PCI_BRIDGE,
.parent = TYPE_PCI_DEVICE,
diff --git a/include/hw/pci/pci_bridge.h
b/include/hw/pci/pci_bridge.h
index ff7cbaa..c9f642c 100644
--- a/include/hw/pci/pci_bridge.h
+++ b/include/hw/pci/pci_bridge.h
@@ -67,4 +67,22 @@ void pci_bridge_map_irq(PCIBridge *br, const
char* bus_name,
#define PCI_BRIDGE_CTL_DISCARD_STATUS 0x400 /*
Discard timer status */
#define PCI_BRIDGE_CTL_DISCARD_SERR 0x800 /* Discard
timer SERR# enable */
+typedef struct PCIBridgeQemuCap {
+ uint8_t id; /* Standard PCI capability header field */
+ uint8_t next; /* Standard PCI capability header field */
+ uint8_t len; /* Standard PCI vendor-specific capability
header field */
+ uint8_t bus_res;
+ uint32_t pref_lim_upper;
+ uint16_t pref_lim;
+ uint16_t mem_lim;
This 32bit IOMEM, right?
+ uint16_t io_lim_upper;
+ uint8_t io_lim;
Why do we need io_lim and io_lim_upper?
The idea was to be able to directly move the capability fields values
to the registers when actually using it (in firmware) code.
Secondly, it saves a little space by avoding usage 32-bit types
when 24-bit ones are desired. And the same thing with prefetchable (48->64).
But if it's more convenient no to split this value, I can do that.
With a clear explanation (Mimic of the <PCI config space field>)
I personally don't mind keeping it like that.
Thanks,
Marcel
Thanks,
Marcel
+ uint8_t padding;
+} PCIBridgeQemuCap;
+
+int pci_bridge_help_cap_init(PCIDevice *dev, int cap_offset,
+ uint8_t bus_reserve, uint32_t
io_limit,
+ uint16_t mem_limit, uint64_t
pref_limit,
+ Error **errp);
+
#endif /* QEMU_PCI_BRIDGE_H */
--
Alexander Bezzubikov
- [Qemu-devel] [RFC PATCH v2 0/6] Generic PCIE-PCI Bridge, Aleksandr Bezzubikov, 2017/07/22
- [Qemu-devel] [RFC PATCH v2 2/6] hw/i386: allow SHPC for Q35 machine, Aleksandr Bezzubikov, 2017/07/22
- [Qemu-devel] [RFC PATCH v2 3/6] hw/pci: enable SHPC for PCIE-PCI bridge, Aleksandr Bezzubikov, 2017/07/22
- [Qemu-devel] [RFC PATCH v2 4/6] hw/pci: introduce bridge-only vendor-specific capability to provide some hints to firmware, Aleksandr Bezzubikov, 2017/07/22
- Re: [Qemu-devel] [RFC PATCH v2 4/6] hw/pci: introduce bridge-only vendor-specific capability to provide some hints to firmware, Michael S. Tsirkin, 2017/07/26
- Re: [Qemu-devel] [RFC PATCH v2 4/6] hw/pci: introduce bridge-only vendor-specific capability to provide some hints to firmware, Alexander Bezzubikov, 2017/07/26
- Re: [Qemu-devel] [SeaBIOS] [RFC PATCH v2 4/6] hw/pci: introduce bridge-only vendor-specific capability to provide some hints to firmware, Laszlo Ersek, 2017/07/26
- Re: [Qemu-devel] [RFC PATCH v2 4/6] hw/pci: introduce bridge-only vendor-specific capability to provide some hints to firmware, Michael S. Tsirkin, 2017/07/26
- Re: [Qemu-devel] [RFC PATCH v2 4/6] hw/pci: introduce bridge-only vendor-specific capability to provide some hints to firmware, Marcel Apfelbaum, 2017/07/27
- Re: [Qemu-devel] [SeaBIOS] [RFC PATCH v2 4/6] hw/pci: introduce bridge-only vendor-specific capability to provide some hints to firmware, Laszlo Ersek, 2017/07/27
- Re: [Qemu-devel] [SeaBIOS] [RFC PATCH v2 4/6] hw/pci: introduce bridge-only vendor-specific capability to provide some hints to firmware, Michael S. Tsirkin, 2017/07/28
- Re: [Qemu-devel] [SeaBIOS] [RFC PATCH v2 4/6] hw/pci: introduce bridge-only vendor-specific capability to provide some hints to firmware, Laszlo Ersek, 2017/07/31
- Re: [Qemu-devel] [SeaBIOS] [RFC PATCH v2 4/6] hw/pci: introduce bridge-only vendor-specific capability to provide some hints to firmware, Michael S. Tsirkin, 2017/07/31
- Re: [Qemu-devel] [SeaBIOS] [RFC PATCH v2 4/6] hw/pci: introduce bridge-only vendor-specific capability to provide some hints to firmware, Laszlo Ersek, 2017/07/31