Re: [PATCH 2/2] watchdog: generic name for i6300esb

[Cornelia Huck <cohuck@redhat.com>]

On Tue, Jul 15 2025, Daniel P. Berrangé <berrange@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.