Re: [PATCH 1/3] xen-pciback: redo VF placement in the virtual topology

[Jan Beulich <jbeulich@xxxxxxxx>]

On 09.04.2021 00:28, Boris Ostrovsky wrote:
> 
> On 4/7/21 10:37 AM, Jan Beulich wrote:
>> The commit referenced below was incomplete: It merely affected what
>> would get written to the vdev-<N> xenstore node. The guest would still
>> find the function at the original function number as long as 
>> __xen_pcibk_get_pci_dev() wouldn't be in sync. The same goes for AER wrt
>> __xen_pcibk_get_pcifront_dev().
>>
>> Undo overriding the function to zero and instead make sure that VFs at
>> function zero remain alone in their slot. This has the added benefit of
>> improving overall capacity, considering that there's only a total of 32
>> slots available right now (PCI segment and bus can both only ever be
>> zero at present).
>>
>> Fixes: 8a5248fe10b1 ("xen PV passthru: assign SR-IOV virtual functions to 
>> separate virtual slots")
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> Cc: stable@xxxxxxxxxxxxxxx
>> ---
>> Like the original change this has the effect of changing where devices
>> would appear in the guest, when there are multiple of them. I don't see
>> an immediate problem with this, but if there is we may need to reduce
>> the effect of the change.
>> Taking into account, besides the described breakage, how xen-pcifront's
>> pcifront_scan_bus() works, I also wonder what problem it was in the
>> first place that needed fixing. It may therefore also be worth to
>> consider simply reverting the original change.
> 
> 
> Perhaps this is no longer a problem, it's been 9 years since that patch. Have 
> you tried reverting to 8a5248fe10b101104d92d01438f918e899414fd1~1 and testing 
> that?

Well, no, for the simple reason that I don't really understand how that
change was meant to make a difference. Hence while simply reverting may
be an option, it's not something I would want to suggest myself (simply
because I couldn't fully justify doing so).

Jan