I guess VFIO_ATTACH_IOASID will fail if the underlayer doesn't supportI think it could fail in the IOASID_CREATE_NESTING. If the gpa_ioasid
hardware nesting. Or is there way to detect the capability before?
is not able to support nesting, then should fail it.
I think GET_INFO only works after the ATTACH.yes. After attaching to gpa_ioasid, userspace could GET_INFO on the
gpa_ioasid and check if nesting is supported or not. right?
ENQCMD is not really Intel specific although only Intel supports it today./* Bind guest I/O page table */My understanding is ENQCMD is Intel specific and not a requirement for
bind_data = {
.ioasid = giova_ioasid;
.addr = giova_pgtable;
// and format information
};
ioctl(ioasid_fd, IOASID_BIND_PGTABLE, &bind_data);
/* Invalidate IOTLB when required */
inv_data = {
.ioasid = giova_ioasid;
// granular information
};
ioctl(ioasid_fd, IOASID_INVALIDATE_CACHE, &inv_data);
/* See 5.6 for I/O page fault handling */
5.5. Guest SVA (vSVA)
++++++++++++++++++
After boots the guest further create a GVA address spaces (gpasid1) on
dev1. Dev2 is not affected (still attached to giova_ioasid).
As explained in section 4, user should avoid expose ENQCMD on both
pdev and mdev.
The sequence applies to all device types (being pdev or mdev), except
one additional step to call KVM for ENQCMD-capable mdev:
having vSVA.
The PCIe DMWr capability is the capability for software to enumerate the
ENQCMD support in device side. yes, it is not a requirement for vSVA. They
are orthogonal.