On Thu, Jul 17, 2025 at 05:17:42PM +0200, Cornelia Huck wrote: > 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.
That is not all that different from an "Intel" device showing up in my "AMD" guest, or that my "modern" virt guest is exposing an Intel machine board from 2005, or that what we advertize as a "q35" machine is actually a "p35" machine, or many other wierd virt things. > Linux treats this as a generic PCI driver as well. Do we know what > Windows on non-x86 expects? The *BSDs? Others? I'm not sure offhand. > >> 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. If we're a mmgmt app provisioning a guest, we have to choose what watchdog to create - either the old one which works everywhere that currently has a driver, or the new one will will work in far fewer places. We'll have to wire up guest OS info about watchdogs into osinfo, and then wire up all the mgmt apps to query this and take action based off it. All possible, but it still feels like a huge waste of time to me. 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 :|
