On Tue, Jul 15, 2025 at 09:16:24AM -0700, Andrea Bolognani wrote: > On Tue, Jul 15, 2025 at 05:02:54PM +0100, Daniel P. Berrangé wrote: > > On Tue, Jul 15, 2025 at 05:44:25PM +0200, Cornelia Huck wrote: > > > Hmm. So > > > - request a new PCI id (probably in the PCI_DEVICE_ID_REDHAT_* space) > > > - restructure to have two devices base off the same core functionality > > > - teach guest operating systems about the new device > > > - teach management software like libvirt about the new device > > > > > > Not sure how fast we can get an ID (or even how to go about it.) The > > > second step should be reasonably easy. The third step is the most > > > complex one, but at least teaching Linux should hopefully be easy > > > enough, and existing guest operating systems could continue to use the > > > existing device. The last step is probably not that bad. > > > > > > I can start down that path, if we have some consensus that this is the > > > right way to handle this. > > > > > > I'd still argue that patch 1 should be applied regardless :) > > > > This sounds like a hell of alot of busy work to fix a problem that, IIUC, > > does not actually exist from a functional POV - it is merely a perception > > issue that people might be put off by the "Intel 6300ESB" names. > > > > IMHO a better use of time is to expand documentation to clarify this is > > just fine for all PCI architectures, and change nothing in either QEMU > > or guest kernels. > > Agreed that it's not the most high-reward endeavor, but IIRC users > were getting genuinely confused and annoyed by the string "Intel" > showing up in their aarch64 guests.
So be it, that's far from the only wierd thing in virt. > You can point them to documentation over and over again, or you can > work to prevent the confusion/annoyance from showing up in the first > place. Which of the two approaches is a better use of anyone's time > is up for debate. > > I for one am grateful that someone put the time in all those years > ago and, as a result, PCI and USB controllers don't suffer from the > problem today. Ultimately it's up to Connie though. The PCI/USB controller situation is not the same tradeoff though. Those guest kernel drivers will identify and attach to these two controllers regardless of their PCI vendor/product, via the PCI class property. In that case changing the PCI ID and other device metadata in QEMU is cheap as it has no negative impact on guest OS driver compibility. In the case of 6300ESB though the guest driver is tied directly to the currently used PCI device product/vendor ID. If we change this then we have actually created new functional problems with guest/QEMU compatibility, in order to placate a non-functional problem. That is not a good thing. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
