On 27/8/25 22:39, Jason Gunthorpe wrote:
On Tue, Aug 26, 2025 at 08:52:58PM -0700, Dan Williams wrote:+static int devsec_pci_probe(struct pci_dev *pdev, + const struct pci_device_id *id) +{ + void __iomem *base; + int rc; + + rc = pcim_enable_device(pdev); + if (rc) + return dev_err_probe(&pdev->dev, rc, "enable failed\n"); + + base = pcim_iomap_region(pdev, 0, KBUILD_MODNAME); + if (IS_ERR(base)) + return dev_err_probe(&pdev->dev, PTR_ERR(base), + "iomap failed\n"); + + rc = device_cc_probe(&pdev->dev); + if (rc) + return rc;I really don't understand what the proposal is here? device_cc_probe() doesn't save anything, doesn't this just get into an endless loop of EPROBE_DEFER? Usually the kernel will retry these things during booting? How does userspace accept through the sysfs retrigger probing? As we discussed in the prior chain we need to have a policy decision before auto-binding drivers at all in a CC environment, I don't see that in the code though the cover letter talked about it?? How does the kernel/userspace tell the difference between drivers that want this early binding and those that don't? Can you write out the whole flow from a userspace perspective in one of the commit messages? This also disables BME, we talked about that a lot, the commit messages didn't seem to describe what solution was settled on here?
My current flow is: - blacklist the driver, - let the userspace "lock", attest, then "accept" via sysfs, - modprove the device driver as usual - at this point DMA is enabled (device::force_encrypted_dma=1) and MMIOs are "validated" (in AMD's SNP words); - the device driver will enable BME, which is allowed to go from 0 to 1 in the RUN state (my test device did not allow it in early days, now fixed); - the device driver will map MMIO as usual and iomap() will do the right thing as it knows by now if the region is encrypted. Thanks,
Jason
-- Alexey
