Re: [PATCH v2 06/19] iommufd/viommu: Add IOMMU_VIOMMU_SET/UNSET_VDEV_ID ioctl

[Jason Gunthorpe <jgg@nvidia.com>]

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