qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: "Andrea Bolognani" <abologna@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [PATCH 2/2] watchdog: generic name for i6300esb
Date: Tue, 15 Jul 2025 17:44:25 +0200	[thread overview]
Message-ID: <877c09792e.fsf@redhat.com> (raw)
In-Reply-To: <CABJz62O3FKYfUOyCLMotgYgckWV1frSUb=MtTW2J4fDTEg_==g@mail.gmail.com>

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



  reply	other threads:[~2025-07-15 16:29 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-10 14:32 [PATCH 0/2] cosmetics for the i6300esb watchdog Cornelia Huck
2025-06-10 14:32 ` [PATCH 1/2] watchdog: CONFIG_WDT_IB6300ESB -> CONFIG_WDT_I6300ESB Cornelia Huck
2025-06-10 17:11   ` Daniel P. Berrangé
2025-06-10 14:32 ` [PATCH 2/2] watchdog: generic name for i6300esb Cornelia Huck
2025-06-10 17:12   ` Daniel P. Berrangé
2025-07-15 12:17     ` Andrea Bolognani
2025-07-15 15:44       ` Cornelia Huck [this message]
2025-07-15 16:02         ` Daniel P. Berrangé
2025-07-15 16:16           ` Andrea Bolognani
2025-07-15 16:33             ` Daniel P. Berrangé
2025-07-17 15:17               ` Cornelia Huck
2025-07-17 15:49                 ` Daniel P. Berrangé
2025-07-29 16:01                   ` Cornelia Huck
2025-07-29 16:09                     ` Daniel P. Berrangé
2025-07-30  7:53                       ` Cornelia Huck
2025-07-18 14:35                 ` Yan Vugenfirer
2025-06-24 11:46 ` [PATCH 0/2] cosmetics for the i6300esb watchdog Cornelia Huck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877c09792e.fsf@redhat.com \
    --to=cohuck@redhat.com \
    --cc=abologna@redhat.com \
    --cc=berrange@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).