Hi, > > You still can have fixed-bar-<nr>=<addr> properties to override the > > auto-discovered address for some or all pci bars. > > If QEMU is willing to accept both a generic PCI mechanism to specify > this, AND a vfio-pci shortcut, sure, we can create the shortcut.
I think this makes sense, but at the end of the day I'm not the pci maintainer, so this is not my call. > As above though, it's also something the caller can construct > relatively easily (maybe not by hand, but with a trivial script) Then everybody who wants / needs this reinvents such a script. Do we really want that? > > Nevertheless I'd tend to only expose the properties for devices where an > > actual use case exists. Which is obviously vfio-pci(-fixed). Also > > pci-testdev for development / testing / CI. I can't see much beyond > > that though. > > I always imagined the properties would live on the core PCI device and > at best vfio-pci would have a shortcut to prefill those properties > based on physical BAR address. pci-testdev is pretty limited and we > can't fully test arbitrary device functionality with it. We'd also > lose the ability to diverge from the host programming if we need to > debug a layout generated on another system. > > IMO, the artificial restriction isn't worth it, especially in the > proposed environment where we enforce and validate fixed BAR > configurations for an entire PCI sub-tree. I think that already > eliminates the most common usage failures we'd see otherwise. Fair enough. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#122152): https://edk2.groups.io/g/devel/message/122152 Mute This Topic: https://groups.io/mt/120952983/21656 Group Owner: [email protected] Unsubscribe: https://edk2.groups.io/g/devel/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
