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

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

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.

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