On Mon, Aug 04, 2025 at 11:33:27PM +0100, Suzuki K Poulose wrote: > On 24/07/2025 15:09, Aneesh Kumar K.V wrote: > > Will Deacon <will@xxxxxxxxxx> writes: > > > On Sun, May 25, 2025 at 01:19:15PM +0530, Aneesh Kumar K.V (Arm) wrote: > > > > + dev_num = vdev->dev_hdr.dev_num; > > > > + /* kvmtool only do 0 domain, 0 bus and 0 function devices. */ > > > > + guest_bdf = (0ULL << 32) | (0 << 16) | dev_num << 11 | (0 << 8); > > > > > > I don't understand this. Shouldn't the BDF correspond to the virtual > > > configuration space? That's not allocated until later, but just going > > > with 0 isn't going to work. > > > > > > What am I missing? > > > > > > > As I understand it, kvmtool supports only bus 0 and does not allow > > multifunction devices. Based on that, I derived the guest BDF as follows > > (correcting what was wrong in the original patch): > > > > guest_bdf = (0ULL << 16) | (0 << 8) | dev_num << 3 | (0 << 0); > > > > Are you suggesting that this approach is incorrect, and that we can use > > a bus number other than 0? > > To put this other way, the emulation of the configuration space is based > on the "dev_num". i.e., CFG address is converted to the offset and > mapped to the "dev_num". So I think what we have here is correct. My point is that 'dev_num' isn't allocated until vfio_pci_setup_device(), which is called from __iommufd_configure_device() _after_ we've called iommufd_alloc_s1bypass_hwpt(). So I don't see how this works. You have to allocate the virtual config space before you can allocate the virtual device with iommufd. Will
