On Tue, May 06, 2025 at 12:55:02PM -0700, Nicolin Chen wrote:
On Tue, May 06, 2025 at 09:58:47AM -0300, Jason Gunthorpe wrote:
On Mon, May 05, 2025 at 07:53:44PM -0700, Nicolin Chen wrote:
On Mon, May 05, 2025 at 02:08:07PM -0300, Jason Gunthorpe wrote:
On Wed, Apr 30, 2025 at 12:58:47AM -0700, Nicolin Chen wrote: The bus numbers can be reassigned at any time on the fly by the guest by reprogramming the PCI hierarchy.
Yes. If we take some aggressive use case into account, where its BDF number could change multiple times, I think it's natural for VMM to simply destroy the previous vDEVICE and allocate a new one with a new BDF number, right?
We should not destroy the vdevice for something like that. In a CC case that would unplug it from the VM which is not right.
CC needs BDF to allocate a VDEV in the CC world. So, it cannot allocate a VDEV with BDF=0 firstly, which is what Alex reported.
I don't know that should be true. Since the BDF is under guest control it can change at run time, is CC intending to somehow disable that? If not then the BDF is dynamic. You could start with a non-zero bus numebr by default but it isn't fixed.
And even for a normal case that the device is migrating between PCI buses, CC might not be able to update the BDF (which can be a part of CC_VDEV_ALLOC instruction), even if iommufd supports an update ioctl. So, the underlying handler for an update ioctl is still to first destroy the VDEV and re-allocate a new one?
I think CC has to or it somehow has to disable bus number changing in the VM as unsupported.
But I would not do destroy/reallocate of the vPCI device in a CC world, that is completely wrong response for the VM changing a bus number. Either the bus number does not change somehow or there is a modify operation.
Jason