<div><br><div class="gmail_quote"><div dir="auto">вт, 25 июля 2017 г. в 19:10, Marcel Apfelbaum <<a href="mailto:marcel@redhat.com">marcel@redhat.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 25/07/2017 17:09, Alexander Bezzubikov wrote:<br>
> 2017-07-25 16:53 GMT+03:00 Michael S. Tsirkin <<a href="mailto:mst@redhat.com" target="_blank">mst@redhat.com</a>>:<br>
>> On Tue, Jul 25, 2017 at 04:50:49PM +0300, Alexander Bezzubikov wrote:<br>
>>> 2017-07-25 16:43 GMT+03:00 Michael S. Tsirkin <<a href="mailto:mst@redhat.com" target="_blank">mst@redhat.com</a>>:<br>
>>>> On Sun, Jul 23, 2017 at 05:13:11PM +0300, Marcel Apfelbaum wrote:<br>
>>>>> On 23/07/2017 15:22, Michael S. Tsirkin wrote:<br>
>>>>>> On Sun, Jul 23, 2017 at 01:15:42AM +0300, Aleksandr Bezzubikov wrote:<br>
>>>>>>> To enable hotplugging of a newly created pcie-pci-bridge,<br>
>>>>>>> we need to tell firmware (SeaBIOS in this case)<br>
>>>>>><br>
>>>>><br>
>>>>> Hi Michael,<br>
>>>>><br>
>>>>>> Presumably, EFI would need to support this too?<br>
>>>>>><br>
>>>>><br>
>>>>> Sure, Eduardo added to CC, but he is in PTO now.<br>
>>>>><br>
>>>>>>> to reserve<br>
>>>>>>> additional buses for pcie-root-port, that allows us to<br>
>>>>>>> hotplug pcie-pci-bridge into this root port.<br>
>>>>>>> The number of buses to reserve is provided to the device via a corresponding<br>
>>>>>>> property, and to the firmware via new PCI capability (next patch).<br>
>>>>>>> The property's default value is 1 as we want to hotplug at least 1 bridge.<br>
>>>>>><br>
>>>>>> If so you should just teach firmware to allocate one bus #<br>
>>>>>> unconditionally.<br>
>>>>>><br>
>>>>><br>
>>>>> That would be a problem for the PCIe machines, since each PCIe<br>
>>>>> devices is plugged in a different bus and we are already<br>
>>>>> limited to 256 PCIe devices. Allocating an extra-bus always<br>
>>>>> would really limit the PCIe devices we can use.<br>
>>>><br>
>>>> One of the declared advantages of PCIe is easy support for multiple roots.<br>
>>>> We really should look at that IMHO so we do not need to pile up hacks.<br>
>>>><br>
>>>>>> But why would that be so? What's wrong with a device<br>
>>>>>> directly in the root port?<br>
>>>>>><br>
>>>><br>
>>>> To clarify, my point is we might be wasting bus numbers by reservation<br>
>>>> since someone might just want to put pcie devices there.<br>
>>><br>
>>> I think, changing default value to 0 can help us avoid this,<br>
>>> as no bus reservation by default. If one's surely wants<br>
>>> to hotplug pcie-pci-bridge into this root port in future,<br>
>>> the property gives him such an opportunity.<br>
>>> So, sure need pcie-pci-bridge hotplug -> creating a root port with<br>
>>> bus_reserve > 0. Otherwise (and default) - just as now, no changes<br>
>>> in bus topology.<br>
>><br>
>> I guess 0 should mean "do not reserve any buses".  So I think we also<br>
>> need a flag to just avoid the capability altogether.  Maybe -1?  *That*<br>
>> should be the default.<br>
><br>
> -1 might be useful if any limit value 0 is legal, but is it?<br>
> If not, we can set every field to 0 and<br>
> this is a sign of avoiding capability since none legal<br>
> values are provided.<br>
><br>
<br>
As Gerd suggested, this value is not a "delta" but the number<br>
of buses to be reserved behind the bridge. If I got it right,<br>
0 is not a valid value, since the bridge by definition<br>
has a list one bus behind.</blockquote><div dir="auto"><br></div><div dir="auto">Gerd's suggestion was to set min(cap_value, children_found). >From such point of view 0 can be a valid value.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Michael, would you be OK with that?<br>
<br>
Thanks,<br>
Marcel<br>
<br>
>><br>
>>>><br>
>>>>> First, plugging a legacy PCI device into a PCIe Root Port<br>
>>>>> looks strange at least, and it can;t be done on real HW anyway.<br>
>>>>> (incompatible slots)<br>
>>>>><br>
>>>>> Second (and more important), if we want 2 or more PCI<br>
>>>>> devices we would loose both IO ports space and bus numbers.<br>
>>>>><br>
>>>>>><br>
>>>>>>><br>
>>>>>>> Signed-off-by: Aleksandr Bezzubikov <<a href="mailto:zuban32s@gmail.com" target="_blank">zuban32s@gmail.com</a>><br>
>>>>>>> ---<br>
>>>>>>>    hw/pci-bridge/pcie_root_port.c | 1 +<br>
>>>>>>>    include/hw/pci/pcie_port.h     | 3 +++<br>
>>>>>>>    2 files changed, 4 insertions(+)<br>
>>>>>>><br>
>>>>>>> diff --git a/hw/pci-bridge/pcie_root_port.c b/hw/pci-bridge/pcie_root_port.c<br>
>>>>>>> index 4d588cb..b0e49e1 100644<br>
>>>>>>> --- a/hw/pci-bridge/pcie_root_port.c<br>
>>>>>>> +++ b/hw/pci-bridge/pcie_root_port.c<br>
>>>>>>> @@ -137,6 +137,7 @@ static void rp_exit(PCIDevice *d)<br>
>>>>>>>    static Property rp_props[] = {<br>
>>>>>>>        DEFINE_PROP_BIT(COMPAT_PROP_PCP, PCIDevice, cap_present,<br>
>>>>>>>                        QEMU_PCIE_SLTCAP_PCP_BITNR, true),<br>
>>>>>>> +    DEFINE_PROP_UINT8("bus_reserve", PCIEPort, bus_reserve, 1),<br>
>>>>>>>        DEFINE_PROP_END_OF_LIST()<br>
>>>>>>>    };<br>
>>>>>>> diff --git a/include/hw/pci/pcie_port.h b/include/hw/pci/pcie_port.h<br>
>>>>>>> index 1333266..1b2dd1f 100644<br>
>>>>>>> --- a/include/hw/pci/pcie_port.h<br>
>>>>>>> +++ b/include/hw/pci/pcie_port.h<br>
>>>>>>> @@ -34,6 +34,9 @@ struct PCIEPort {<br>
>>>>>>>        /* pci express switch port */<br>
>>>>>>>        uint8_t     port;<br>
>>>>>>> +<br>
>>>>>>> +    /* additional buses to reserve on firmware init */<br>
>>>>>>> +    uint8_t     bus_reserve;<br>
>>>>>>>    };<br>
>>>>>>>    void pcie_port_init_reg(PCIDevice *d);<br>
>>>>>><br>
>>>>>> So here is a property and it does not do anything.<br>
>>>>>> It makes it easier to work on series maybe, but review<br>
>>>>>> is harder since we do not see what it does at all.<br>
>>>>>> Please do not split up patches like this - you can maintain<br>
>>>>>> it split up in your branch if you like and merge before sending.<br>
>>>>>><br>
>>>>><br>
>>>>> Agreed, Alexandr please merge patches 4-5-6 for your next submission.<br>
>>>>><br>
>>>>> Thanks,<br>
>>>>> Marcel<br>
>>>>><br>
>>>>><br>
>>>>>>> --<br>
>>>>>>> 2.7.4<br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Alexander Bezzubikov<br>
><br>
><br>
><br>
<br>
</blockquote></div></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Alexander Bezzubikov</div></div></div></div>