[PATCH 0/2] cosmetics for the i6300esb watchdog

[PATCH 0/2] cosmetics for the i6300esb watchdog

[Cornelia Huck]

The i6300esb watchdog device is generic enough to be used on any PCI
platform; however, having an "Intel" device on a non-x86 platform looks
a bit odd. Just call it a "virtual" device instead, and also fix an old
typo for the config option while at it.

Cornelia Huck (2):
  watchdog: CONFIG_WDT_IB6300ESB -> CONFIG_WDT_I6300ESB
  watchdog: generic name for i6300esb

 hw/watchdog/Kconfig        | 2 +-
 hw/watchdog/meson.build    | 2 +-
 hw/watchdog/wdt_i6300esb.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

-- 
2.49.0

[PATCH 1/2] watchdog: CONFIG_WDT_IB6300ESB -> CONFIG_WDT_I6300ESB

[Cornelia Huck]

There's no ib6300esb device; let's correct the typo in the config option.

Signed-off-by: Cornelia Huck <cohuck@redhat.com>
---
 hw/watchdog/Kconfig     | 2 +-
 hw/watchdog/meson.build | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/watchdog/Kconfig b/hw/watchdog/Kconfig
index 861fd003341d..1003939e1f33 100644
--- a/hw/watchdog/Kconfig
+++ b/hw/watchdog/Kconfig
@@ -2,7 +2,7 @@ config CMSDK_APB_WATCHDOG
     bool
     select PTIMER
 
-config WDT_IB6300ESB
+config WDT_I6300ESB
     bool
     default y if PCI_DEVICES
     depends on PCI
diff --git a/hw/watchdog/meson.build b/hw/watchdog/meson.build
index 15370565bd4d..dafb85dfffc3 100644
--- a/hw/watchdog/meson.build
+++ b/hw/watchdog/meson.build
@@ -1,7 +1,7 @@
 system_ss.add(files('watchdog.c'))
 system_ss.add(when: 'CONFIG_ALLWINNER_WDT', if_true: files('allwinner-wdt.c'))
 system_ss.add(when: 'CONFIG_CMSDK_APB_WATCHDOG', if_true: files('cmsdk-apb-watchdog.c'))
-system_ss.add(when: 'CONFIG_WDT_IB6300ESB', if_true: files('wdt_i6300esb.c'))
+system_ss.add(when: 'CONFIG_WDT_I6300ESB', if_true: files('wdt_i6300esb.c'))
 system_ss.add(when: 'CONFIG_WDT_IB700', if_true: files('wdt_ib700.c'))
 system_ss.add(when: 'CONFIG_WDT_DIAG288', if_true: files('wdt_diag288.c'))
 system_ss.add(when: 'CONFIG_ASPEED_SOC', if_true: files('wdt_aspeed.c'))
-- 
2.49.0

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

[Cornelia Huck]

The Intel 6300 Enterprise SouthBridge is a south bridge for a more or
less obscure embedded Intel system; however, the i6300esb watchdog
device we implement in QEMU is a virtual watchdog device that should
work well on any PCI-based machine, is well supported by Linux guests,
and used in many examples on how to set up a virtual watchdog.

Let's use "virtual i6300ESB" in the description to make clear that
this device will work just fine on non-Intel platforms.

Signed-off-by: Cornelia Huck <cohuck@redhat.com>
---
 hw/watchdog/wdt_i6300esb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/watchdog/wdt_i6300esb.c b/hw/watchdog/wdt_i6300esb.c
index bb8a2766b69b..5e5d8c48cfd7 100644
--- a/hw/watchdog/wdt_i6300esb.c
+++ b/hw/watchdog/wdt_i6300esb.c
@@ -472,7 +472,7 @@ static void i6300esb_class_init(ObjectClass *klass, const void *data)
     device_class_set_legacy_reset(dc, i6300esb_reset);
     dc->vmsd = &vmstate_i6300esb;
     set_bit(DEVICE_CATEGORY_WATCHDOG, dc->categories);
-    dc->desc = "Intel 6300ESB";
+    dc->desc = "virtual i6300ESB";
 }
 
 static const TypeInfo i6300esb_info = {
-- 
2.49.0

Re: [PATCH 1/2] watchdog: CONFIG_WDT_IB6300ESB -> CONFIG_WDT_I6300ESB

[Daniel P. Berrangé]

On Tue, Jun 10, 2025 at 04:32:58PM +0200, Cornelia Huck wrote:
> There's no ib6300esb device; let's correct the typo in the config option.
> 
> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
> ---
>  hw/watchdog/Kconfig     | 2 +-
>  hw/watchdog/meson.build | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>


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 :|

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

[Daniel P. Berrangé]

On Tue, Jun 10, 2025 at 04:32:59PM +0200, Cornelia Huck wrote:
> The Intel 6300 Enterprise SouthBridge is a south bridge for a more or
> less obscure embedded Intel system; however, the i6300esb watchdog
> device we implement in QEMU is a virtual watchdog device that should
> work well on any PCI-based machine, is well supported by Linux guests,
> and used in many examples on how to set up a virtual watchdog.
> 
> Let's use "virtual i6300ESB" in the description to make clear that
> this device will work just fine on non-Intel platforms.
> 
> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
> ---
>  hw/watchdog/wdt_i6300esb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

I'm not entirely sold on the idea that this is needed, but at the same
time I won't object so

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>


> 
> diff --git a/hw/watchdog/wdt_i6300esb.c b/hw/watchdog/wdt_i6300esb.c
> index bb8a2766b69b..5e5d8c48cfd7 100644
> --- a/hw/watchdog/wdt_i6300esb.c
> +++ b/hw/watchdog/wdt_i6300esb.c
> @@ -472,7 +472,7 @@ static void i6300esb_class_init(ObjectClass *klass, const void *data)
>      device_class_set_legacy_reset(dc, i6300esb_reset);
>      dc->vmsd = &vmstate_i6300esb;
>      set_bit(DEVICE_CATEGORY_WATCHDOG, dc->categories);
> -    dc->desc = "Intel 6300ESB";
> +    dc->desc = "virtual i6300ESB";
>  }
>  
>  static const TypeInfo i6300esb_info = {
> -- 
> 2.49.0
> 
> 

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 :|

Re: [PATCH 0/2] cosmetics for the i6300esb watchdog

[Cornelia Huck]

On Tue, Jun 10 2025, Cornelia Huck <cohuck@redhat.com> wrote:

> The i6300esb watchdog device is generic enough to be used on any PCI
> platform; however, having an "Intel" device on a non-x86 platform looks
> a bit odd. Just call it a "virtual" device instead, and also fix an old
> typo for the config option while at it.
>
> Cornelia Huck (2):
>   watchdog: CONFIG_WDT_IB6300ESB -> CONFIG_WDT_I6300ESB
>   watchdog: generic name for i6300esb
>
>  hw/watchdog/Kconfig        | 2 +-
>  hw/watchdog/meson.build    | 2 +-
>  hw/watchdog/wdt_i6300esb.c | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)

Friendly ping -- any sentiment regarding those patches?

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

[Andrea Bolognani]

On Tue, Jun 10, 2025 at 06:12:12PM +0100, Daniel P. Berrangé wrote:
> On Tue, Jun 10, 2025 at 04:32:59PM +0200, Cornelia Huck wrote:
> > The Intel 6300 Enterprise SouthBridge is a south bridge for a more or
> > less obscure embedded Intel system; however, the i6300esb watchdog
> > device we implement in QEMU is a virtual watchdog device that should
> > work well on any PCI-based machine, is well supported by Linux guests,
> > and used in many examples on how to set up a virtual watchdog.
> >
> > Let's use "virtual i6300ESB" in the description to make clear that
> > this device will work just fine on non-Intel platforms.
> >
> > Signed-off-by: Cornelia Huck <cohuck@redhat.com>
> > ---
> >  hw/watchdog/wdt_i6300esb.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
>
> I'm not entirely sold on the idea that this is needed, but at the same
> time I won't object so
>
> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>

I would argue that this change is incorrect.

While the QEMU device can be used for non-x86 VMs, it *is* faithfully
modelled after an Intel part, and the guest OS will recognize it as
such:

  # lspci | grep 6300
  07:01.0 System peripheral: Intel Corporation 6300ESB Watchdog Timer

What we actually need to do is create a new QEMU device with distinct
PCI IDs, same as we've done in the past for qemu-xhci, pcie-root-port
and pcie-to-pci-bridge.

That will take a lot longer to integrate throughout the stack and be
supported across the various guest OS, but it's the only approach
that eventually leads to truly Intel-free non-x86 VMs.

-- 
Andrea Bolognani / Red Hat / Virtualization

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

[Cornelia Huck]

On Tue, Jul 15 2025, Andrea Bolognani <abologna@redhat.com> wrote:

> On Tue, Jun 10, 2025 at 06:12:12PM +0100, Daniel P. Berrangé wrote:
>> On Tue, Jun 10, 2025 at 04:32:59PM +0200, Cornelia Huck wrote:
>> > The Intel 6300 Enterprise SouthBridge is a south bridge for a more or
>> > less obscure embedded Intel system; however, the i6300esb watchdog
>> > device we implement in QEMU is a virtual watchdog device that should
>> > work well on any PCI-based machine, is well supported by Linux guests,
>> > and used in many examples on how to set up a virtual watchdog.
>> >
>> > Let's use "virtual i6300ESB" in the description to make clear that
>> > this device will work just fine on non-Intel platforms.
>> >
>> > Signed-off-by: Cornelia Huck <cohuck@redhat.com>
>> > ---
>> >  hw/watchdog/wdt_i6300esb.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> I'm not entirely sold on the idea that this is needed, but at the same
>> time I won't object so
>>
>> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
>
> I would argue that this change is incorrect.
>
> While the QEMU device can be used for non-x86 VMs, it *is* faithfully
> modelled after an Intel part, and the guest OS will recognize it as
> such:
>
>   # lspci | grep 6300
>   07:01.0 System peripheral: Intel Corporation 6300ESB Watchdog Timer
>
> What we actually need to do is create a new QEMU device with distinct
> PCI IDs, same as we've done in the past for qemu-xhci, pcie-root-port
> and pcie-to-pci-bridge.
>
> That will take a lot longer to integrate throughout the stack and be
> supported across the various guest OS, but it's the only approach
> that eventually leads to truly Intel-free non-x86 VMs.

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 :)

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

[Daniel P. Berrangé]

On Tue, Jul 15, 2025 at 05:44:25PM +0200, Cornelia Huck wrote:
> On Tue, Jul 15 2025, Andrea Bolognani <abologna@redhat.com> wrote:
> 
> > On Tue, Jun 10, 2025 at 06:12:12PM +0100, Daniel P. Berrangé wrote:
> >> On Tue, Jun 10, 2025 at 04:32:59PM +0200, Cornelia Huck wrote:
> >> > The Intel 6300 Enterprise SouthBridge is a south bridge for a more or
> >> > less obscure embedded Intel system; however, the i6300esb watchdog
> >> > device we implement in QEMU is a virtual watchdog device that should
> >> > work well on any PCI-based machine, is well supported by Linux guests,
> >> > and used in many examples on how to set up a virtual watchdog.
> >> >
> >> > Let's use "virtual i6300ESB" in the description to make clear that
> >> > this device will work just fine on non-Intel platforms.
> >> >
> >> > Signed-off-by: Cornelia Huck <cohuck@redhat.com>
> >> > ---
> >> >  hw/watchdog/wdt_i6300esb.c | 2 +-
> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> I'm not entirely sold on the idea that this is needed, but at the same
> >> time I won't object so
> >>
> >> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
> >
> > I would argue that this change is incorrect.
> >
> > While the QEMU device can be used for non-x86 VMs, it *is* faithfully
> > modelled after an Intel part, and the guest OS will recognize it as
> > such:
> >
> >   # lspci | grep 6300
> >   07:01.0 System peripheral: Intel Corporation 6300ESB Watchdog Timer
> >
> > What we actually need to do is create a new QEMU device with distinct
> > PCI IDs, same as we've done in the past for qemu-xhci, pcie-root-port
> > and pcie-to-pci-bridge.
> >
> > That will take a lot longer to integrate throughout the stack and be
> > supported across the various guest OS, but it's the only approach
> > that eventually leads to truly Intel-free non-x86 VMs.
> 
> 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.

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 :|

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

[Andrea Bolognani]

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.

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.

-- 
Andrea Bolognani / Red Hat / Virtualization

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

[Daniel P. Berrangé]

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 :|

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

[Cornelia Huck]

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.

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

[Daniel P. Berrangé]

On Thu, Jul 17, 2025 at 05:17:42PM +0200, Cornelia Huck wrote:
> 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.

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 :|

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

[Yan Vugenfirer]

On Thu, Jul 17, 2025 at 9:14 PM Cornelia Huck <cohuck@redhat.com> wrote:
>
> 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?

Eric just asked me about the i6300ESB on ARM and Windows.
Windows has i6300ESB device PNP ID in machine.inf:
%WatchdogTimer_Desc% = NO_DRV, PCI\VEN_8086&DEV_25AB
NO_DRV means that there is no device driver installed for the device,
but the device will have some "Friendly Name" in the device manager
and will be treated as installed device. Users could then install
Intel's driver.

Changing the device ID, will make this device as not-installed from
Windows perspective. If such device will be included by default for
some machine types, those machine types will not be able to pass
Microsoft SVVP certification because the OS will have a device without
a driver. The mitigation is to keep and certify our own dummy INF,
which is a grey zone as Intel should have their own driver certified
with MS.
This is very similar to the discussion we had about AMD IOMMU PCIe
endpoint PNP Id.

Best regards,
Yan.

>
> >
> >> 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.
>
>

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

[Cornelia Huck]

On Thu, Jul 17 2025, Daniel P. Berrangé <berrange@redhat.com> wrote:

> On Thu, Jul 17, 2025 at 05:17:42PM +0200, Cornelia Huck wrote:
>> 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:
>> >> 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.

The fact that the device is something emulated and not the Intel
hardware device is actually visible to the guest:

00:02.0 System peripheral: Intel Corporation 6300ESB Watchdog Timer
	Subsystem: Red Hat, Inc. QEMU Virtual Machine
	Flags: fast devsel
	Memory at 10804000 (32-bit, non-prefetchable) [size=16]
	Kernel driver in use: i6300ESB timer
	Kernel modules: i6300esb

(lspci -v so unfortunately not immediately obvious, but still)

AFAIK the BSDs do not have a driver for this device at the moment -- and
given what turns up when searching for i6300ESB, someone implementing a
driver is far more likely to pick the exising PCI ID.

Windows would also need some dance according to Yan's mail, for unclear
benefits.

On the whole, I think this is not really worth the hassle, we can simply
keep this device as-is.

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

[Daniel P. Berrangé]

On Tue, Jul 29, 2025 at 06:01:25PM +0200, Cornelia Huck wrote:
> On Thu, Jul 17 2025, Daniel P. Berrangé <berrange@redhat.com> wrote:
> 
> > On Thu, Jul 17, 2025 at 05:17:42PM +0200, Cornelia Huck wrote:
> >> 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:
> >> >> 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.
> 
> The fact that the device is something emulated and not the Intel
> hardware device is actually visible to the guest:
> 
> 00:02.0 System peripheral: Intel Corporation 6300ESB Watchdog Timer
> 	Subsystem: Red Hat, Inc. QEMU Virtual Machine
> 	Flags: fast devsel
> 	Memory at 10804000 (32-bit, non-prefetchable) [size=16]
> 	Kernel driver in use: i6300ESB timer
> 	Kernel modules: i6300esb
> 
> (lspci -v so unfortunately not immediately obvious, but still)
> 
> AFAIK the BSDs do not have a driver for this device at the moment -- and
> given what turns up when searching for i6300ESB, someone implementing a
> driver is far more likely to pick the exising PCI ID.

I see vague references (with unfortunately 404 links) to FreeBSD
supporting some ICH watchdogs, which might mean it is compatible
with the q35 built-in watchdog that all x86 q35 machines get by
default. That wouldn't help non-x86 BSD though.

> Windows would also need some dance according to Yan's mail, for unclear
> benefits.

Off-list, Richard Jones pointed to the ACPI Watchdog WADT specification
from Microsoft which appears to the most viable solution for Windows
guests - at least from x86 POV, but hopefully any future Wndows aarch64
too:

  https://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/HardwareWDTSpec.doc

The ACPI watchdog sounds like potentially the best bet for a working
solution across Linux and Windows, on any arch that does ACPI.... if
we can just find someone to write a QEMU driver for it....

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 :|

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

[Cornelia Huck]

On Tue, Jul 29 2025, Daniel P. Berrangé <berrange@redhat.com> wrote:

> On Tue, Jul 29, 2025 at 06:01:25PM +0200, Cornelia Huck wrote:
>> On Thu, Jul 17 2025, Daniel P. Berrangé <berrange@redhat.com> wrote:
>> 
>> > On Thu, Jul 17, 2025 at 05:17:42PM +0200, Cornelia Huck wrote:
>> >> 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:
>> >> >> 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.
>> 
>> The fact that the device is something emulated and not the Intel
>> hardware device is actually visible to the guest:
>> 
>> 00:02.0 System peripheral: Intel Corporation 6300ESB Watchdog Timer
>> 	Subsystem: Red Hat, Inc. QEMU Virtual Machine
>> 	Flags: fast devsel
>> 	Memory at 10804000 (32-bit, non-prefetchable) [size=16]
>> 	Kernel driver in use: i6300ESB timer
>> 	Kernel modules: i6300esb
>> 
>> (lspci -v so unfortunately not immediately obvious, but still)
>> 
>> AFAIK the BSDs do not have a driver for this device at the moment -- and
>> given what turns up when searching for i6300ESB, someone implementing a
>> driver is far more likely to pick the exising PCI ID.
>
> I see vague references (with unfortunately 404 links) to FreeBSD
> supporting some ICH watchdogs, which might mean it is compatible
> with the q35 built-in watchdog that all x86 q35 machines get by
> default. That wouldn't help non-x86 BSD though.

I found https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259673 -- I'm
not sure if anyone has tried to implement something cross-arch.

>
>> Windows would also need some dance according to Yan's mail, for unclear
>> benefits.
>
> Off-list, Richard Jones pointed to the ACPI Watchdog WADT specification
> from Microsoft which appears to the most viable solution for Windows
> guests - at least from x86 POV, but hopefully any future Wndows aarch64
> too:
>
>   https://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/HardwareWDTSpec.doc
>
> The ACPI watchdog sounds like potentially the best bet for a working
> solution across Linux and Windows, on any arch that does ACPI.... if
> we can just find someone to write a QEMU driver for it....

Yes, if someone(tm) wrote a QEMU device for that, we'd have something
that should be quite useful across archs (well, excluding s390, which
has its own watchdog anyway.)

Given all of that, I still think that leaving i6300ESB as-is is the
right thing, with a possible option of implementing the WADT watchdog.