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