Re: [PATCH v2] content: Reserve ID 52 for QPSFI device

["Michael S. Tsirkin" <mst@redhat.com>]

On Fri, Oct 23, 2026 at 12:39:48AM +0200, Peter Hilber wrote:
> On Thu, Oct 22, 2026 at 12:29:31PM -0400, Michael S. Tsirkin wrote:
> > On Thu, Oct 22, 2026 at 04:20:51PM +0000, Parav Pandit wrote:
> > > 
> > > > From: Michael S. Tsirkin <mst@redhat.com>
> > > > Sent: 22 October 2026 09:32 PM
> > > > 
> > > > On Thu, Oct 22, 2026 at 03:49:51PM +0000, Parav Pandit wrote:
> > > > >
> > > > > > From: Michael S. Tsirkin <mst@redhat.com>
> > > > > > Sent: 22 October 2026 09:12 PM
> > > > > >
> > > > > > On Thu, Oct 22, 2026 at 03:35:51PM +0000, Parav Pandit wrote:
> > > > > > >
> > > > > > > > From: Cornelia Huck <cohuck@redhat.com>
> > > > > > > > Sent: 22 October 2026 08:35 PM
> > > > > > > >
> > > > > > > > On Thu, Oct 22 2026, Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote:
> > > > > > > >
> > > > > > > > > Let's define some standard way for the vendors to declare that this
> > > > > > > > > device is "Qualcomm", "NXP" or "hobbyist which doesn't own PCI or USB id
> > > > > > > > > block".
> > > > > > > >
> > > > > > > > Are we able to use the first <n> bytes of config space for that? I guess
> > > > > > > > that is the only way that can possibly work for any transport.
> > > > > > > >
> > > > > > > > Then, maybe something like one or two bytes for a vendor id (including
> > > > > > > > one for "testing purposes" or so), and the rest to be used in a
> > > > > > > > vendor-specific way.
> > > > > > > >
> > > > > > > device ids are independent of the transport.
> > > > > > >
> > > > > > > but Peter already announced that:
> > > > > > > " Reserve a device ID for QPSFI devices (Qualcomm Platform Subsystem
> > > > > > > Firmware Interface). QPSFI devices expose functionality across SoC
> > > > > > > subsystems through a common Virtio-based protocol. There are no plans to
> > > > > > > standardize the devices."
> > > > > > >
> > > > > > > So, I am unable to understand why should it be part of vendor agnostic virtio spec?
> > > > > > > Why a vendor specific implementation of device and driver is not sufficient?
> > > > > >
> > > > > > I don't really think we should vendors burn up device IDs every
> > > > > > times they want something non standard. Reserving ID 52 as
> > > > > > "vendor specific" so vendors can go wild sounds good,
> > > > > > but a bit more needs to be done than just reserving:
> > > > > > document what is expected, e.g. no auto load based on ID
> > > > > > alone.
> > > > >
> > > > > First, you indicate to open virtio to vendor specific extension. This is huge in itself.
> > > > 
> > > > Not as such.  It's just reserving an id. People always do things like
> > > > implement some crazy spec saying "we will upstream later" and later they
> > > > do not.
> > > > And then the ID conflicts with a standard one. Suboptimal.
> > > > 
> > > > So if we can tell everyone "always use this ID, and use platform
> > > > specific tool dor discovery, until your device is in the spec"
> > > > then that's not too bad.
> > > > 
> > > > 
> > > > 
> > > > > that should be first discussed.
> > > > > If you suggest this, may be every device type should be able to extend, and not just demux at device id level.
> > > > >
> > > > > Second, one reserved id is not enough, because a given system may have multiple such different vendors devices installed.
> > > > 
> > > > I don't think we should care.
> > > > 
> > > than all 0xffff as one experimental id once for all is good enough.
> > > than vendor FOO, BAR, differentiation is not needed.
> > 
> > I don't think we want 0xffff, a lot of systems treat that value as
> > special, pci comes to mind.
> > 
> > > And if it is not for experimental purpose, not sure why would vendor stop at only one device.
> > 
> > They can reuse that id as many times as they want and differentiate
> > with a device specific or out of band methods.
> > First X bytes of config space was mentioned. or whatever.
> > 
> > We can add a recommentation maybe if vendors desire that.
> > 
> 
> Thank you to everybody contributing to the discussion and to the concept
> of a vendor-specific device. Just for clarity, Qualcomm intends to
> upstream Linux kernel drivers for this new device type, so would
> definitely want to use a registered device ID.
>
> In case of an in-band approach, I suppose we would then have an explicit
> vendor list in the spec where vendors have to register?
> 
> Best regards,
> 
> Peter

Just why are you bothering with virtio spec at all then?
Just use your own vendor id for this.

> 
> > > > > So why to bend things so much and re-invent the wheel?
> > > > > Why for say PCI transport's any vendor and device id are not sufficient to indicate a vendor and device?
> > > > >
> > > > > and if so, why to even document it in the virtio spec?
> > > > >
> > > > > I guess, I am missing the basic motivation part.
> > > > 
> > > > For the virtio spec? Above. For Qualcomm since they decided never to
> > > > upstream - donnu. Don't care much, either...
> > > 
> > > ok. so yeah, let vendor's platform device be in the vendor's OSS zone.
> >