On Tue, Jul 15 2025, Daniel P. Berrangé <berra...@redhat.com> wrote:
> 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. So I'm wondering what the general sentiment is towards having an "Intel" device show up in your non-Intel guest. This device is generic enough to be included in PCI_DEVICES, and should be usable on any of those platforms. Linux treats this as a generic PCI driver as well. Do we know what Windows on non-x86 expects? The *BSDs? Others? > >> 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. I don't think the suggestion was to disable the existing driver on non-Intel setups, but to add a more generic one. Still, more work to get this actually propagated into guests than doing the change in QEMU. Before I start down that route, I'd like to know whether the issue is actually big enough to make investing time there worth it.
