On Tue, Jul 15, 2025 at 05:44:25PM +0200, Cornelia Huck wrote: > On Tue, Jul 15 2025, Andrea Bolognani <abolo...@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 <coh...@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é <berra...@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 :|
