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

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

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?


-boris