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

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

[Peter Hilber]

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.

The Linux DCP display driver series is planned as the first user of this
device ID:

https://lore.kernel.org/all/20261015-jshekhar-drm-msm-dcp-v1-v1-10-48aad0fe4f72@oss.qualcomm.com/

Device ID 51 is already reserved for the Virtio HAB device:

https://lore.kernel.org/virtio-comment/20260702140939.3535968-1-zeloren@qti.qualcomm.com/

Signed-off-by: Peter Hilber <peter.hilber@oss.qualcomm.com>
---

    v2:
    
    - Rename the device from "Snapdragon device" to "QPSFI device".
    
    - Refer to DCP Linux driver patch as planned first QPSFI user.
    
    v1:
    
    - Was posted as "content: Reserve ID 52 for Snapdragon device":
    
      https://lore.kernel.org/virtio-comment/20260826115504.1955-1-peter.hilber@oss.qualcomm.com/

 content.tex | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/content.tex b/content.tex
index 243ce2dde36b..7416939e67d3 100644
--- a/content.tex
+++ b/content.tex
@@ -805,6 +805,8 @@ \chapter{Device Types}\label{sec:Device Types}
 \hline
 50         &   Video encoder/decoder device \\
 \hline
+52         &   QPSFI device \\
+\hline
 \end{longtable}
 
 Some of the devices above are unspecified by this document,
-- 
2.43.0

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

[Demi Marie Obenour]

[-- Attachment #1.1: Type: text/plain, Size: 1781 bytes --]

On 10/21/26 14:00, Peter Hilber wrote:
> 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.
> 
> The Linux DCP display driver series is planned as the first user of this
> device ID:
> 
> https://lore.kernel.org/all/20261015-jshekhar-drm-msm-dcp-v1-v1-10-48aad0fe4f72@oss.qualcomm.com/
> 
> Device ID 51 is already reserved for the Virtio HAB device:
> 
> https://lore.kernel.org/virtio-comment/20260702140939.3535968-1-zeloren@qti.qualcomm.com/
> 
> Signed-off-by: Peter Hilber <peter.hilber@oss.qualcomm.com>
> ---
> 
>     v2:
>     
>     - Rename the device from "Snapdragon device" to "QPSFI device".
>     
>     - Refer to DCP Linux driver patch as planned first QPSFI user.
>     
>     v1:
>     
>     - Was posted as "content: Reserve ID 52 for Snapdragon device":
>     
>       https://lore.kernel.org/virtio-comment/20260826115504.1955-1-peter.hilber@oss.qualcomm.com/
> 
>  content.tex | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/content.tex b/content.tex
> index 243ce2dde36b..7416939e67d3 100644
> --- a/content.tex
> +++ b/content.tex
> @@ -805,6 +805,8 @@ \chapter{Device Types}\label{sec:Device Types}
>  \hline
>  50         &   Video encoder/decoder device \\
>  \hline
> +52         &   QPSFI device \\
> +\hline
>  \end{longtable}
>  
>  Some of the devices above are unspecified by this document,

I think it would be best to have a single ID for vendor-specific devices.
I believe most of the ID space has already been used, at least for virtio-PCI.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Michael S. Tsirkin]

On Wed, Oct 21, 2026 at 08:00:31PM +0200, Peter Hilber wrote:
> 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.
> 
> The Linux DCP display driver series is planned as the first user of this
> device ID:
> 
> https://lore.kernel.org/all/20261015-jshekhar-drm-msm-dcp-v1-v1-10-48aad0fe4f72@oss.qualcomm.com/
> 
> Device ID 51 is already reserved for the Virtio HAB device:
> 
> https://lore.kernel.org/virtio-comment/20260702140939.3535968-1-zeloren@qti.qualcomm.com/
> 
> Signed-off-by: Peter Hilber <peter.hilber@oss.qualcomm.com>

What about the HAB btw? It was said the spec will be upstreamed
did I miss that?

> ---
> 
>     v2:
>     
>     - Rename the device from "Snapdragon device" to "QPSFI device".
>     
>     - Refer to DCP Linux driver patch as planned first QPSFI user.
>     
>     v1:
>     
>     - Was posted as "content: Reserve ID 52 for Snapdragon device":
>     
>       https://lore.kernel.org/virtio-comment/20260826115504.1955-1-peter.hilber@oss.qualcomm.com/
> 
>  content.tex | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/content.tex b/content.tex
> index 243ce2dde36b..7416939e67d3 100644
> --- a/content.tex
> +++ b/content.tex
> @@ -805,6 +805,8 @@ \chapter{Device Types}\label{sec:Device Types}
>  \hline
>  50         &   Video encoder/decoder device \\
>  \hline
> +52         &   QPSFI device \\
> +\hline
>  \end{longtable}
>  
>  Some of the devices above are unspecified by this document,
> -- 
> 2.43.0

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

[Michael S. Tsirkin]

On Wed, Oct 21, 2026 at 03:25:31PM -0400, Demi Marie Obenour wrote:
> On 10/21/26 14:00, Peter Hilber wrote:
> > 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.
> > 
> > The Linux DCP display driver series is planned as the first user of this
> > device ID:
> > 
> > https://lore.kernel.org/all/20261015-jshekhar-drm-msm-dcp-v1-v1-10-48aad0fe4f72@oss.qualcomm.com/
> > 
> > Device ID 51 is already reserved for the Virtio HAB device:
> > 
> > https://lore.kernel.org/virtio-comment/20260702140939.3535968-1-zeloren@qti.qualcomm.com/
> > 
> > Signed-off-by: Peter Hilber <peter.hilber@oss.qualcomm.com>
> > ---
> > 
> >     v2:
> >     
> >     - Rename the device from "Snapdragon device" to "QPSFI device".
> >     
> >     - Refer to DCP Linux driver patch as planned first QPSFI user.
> >     
> >     v1:
> >     
> >     - Was posted as "content: Reserve ID 52 for Snapdragon device":
> >     
> >       https://lore.kernel.org/virtio-comment/20260826115504.1955-1-peter.hilber@oss.qualcomm.com/
> > 
> >  content.tex | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/content.tex b/content.tex
> > index 243ce2dde36b..7416939e67d3 100644
> > --- a/content.tex
> > +++ b/content.tex
> > @@ -805,6 +805,8 @@ \chapter{Device Types}\label{sec:Device Types}
> >  \hline
> >  50         &   Video encoder/decoder device \\
> >  \hline
> > +52         &   QPSFI device \\
> > +\hline
> >  \end{longtable}
> >  
> >  Some of the devices above are unspecified by this document,
> 
> I think it would be best to have a single ID for vendor-specific devices.
> I believe most of the ID space has already been used, at least for virtio-PCI.
> -- 
> Sincerely,
> Demi Marie Obenour (she/her/hers)

Sounds like a good idea to me. And then qualcomm can do what they
want, like check subsystem id for pci or whatever?
Only issue is there is no way to distinguish for mmio/ccw.
Maybe, add vendor specific id as first e.g. 8 bytes ro in the config space?
Peter?

-- 
MST

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

[Cornelia Huck]

On Wed, Oct 21 2026, "Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Wed, Oct 21, 2026 at 03:25:31PM -0400, Demi Marie Obenour wrote:
>> On 10/21/26 14:00, Peter Hilber wrote:
>> > 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.
>> > 
>> > The Linux DCP display driver series is planned as the first user of this
>> > device ID:
>> > 
>> > https://lore.kernel.org/all/20261015-jshekhar-drm-msm-dcp-v1-v1-10-48aad0fe4f72@oss.qualcomm.com/
>> > 
>> > Device ID 51 is already reserved for the Virtio HAB device:
>> > 
>> > https://lore.kernel.org/virtio-comment/20260702140939.3535968-1-zeloren@qti.qualcomm.com/
>> > 
>> > Signed-off-by: Peter Hilber <peter.hilber@oss.qualcomm.com>
>> > ---
>> > 
>> >     v2:
>> >     
>> >     - Rename the device from "Snapdragon device" to "QPSFI device".
>> >     
>> >     - Refer to DCP Linux driver patch as planned first QPSFI user.
>> >     
>> >     v1:
>> >     
>> >     - Was posted as "content: Reserve ID 52 for Snapdragon device":
>> >     
>> >       https://lore.kernel.org/virtio-comment/20260826115504.1955-1-peter.hilber@oss.qualcomm.com/
>> > 
>> >  content.tex | 2 ++
>> >  1 file changed, 2 insertions(+)
>> > 
>> > diff --git a/content.tex b/content.tex
>> > index 243ce2dde36b..7416939e67d3 100644
>> > --- a/content.tex
>> > +++ b/content.tex
>> > @@ -805,6 +805,8 @@ \chapter{Device Types}\label{sec:Device Types}
>> >  \hline
>> >  50         &   Video encoder/decoder device \\
>> >  \hline
>> > +52         &   QPSFI device \\
>> > +\hline
>> >  \end{longtable}
>> >  
>> >  Some of the devices above are unspecified by this document,
>> 
>> I think it would be best to have a single ID for vendor-specific devices.
>> I believe most of the ID space has already been used, at least for virtio-PCI.
>> -- 
>> Sincerely,
>> Demi Marie Obenour (she/her/hers)
>
> Sounds like a good idea to me. And then qualcomm can do what they
> want, like check subsystem id for pci or whatever?
> Only issue is there is no way to distinguish for mmio/ccw.
> Maybe, add vendor specific id as first e.g. 8 bytes ro in the config space?
> Peter?

Using some information in the config space looks like the most flexible
way to me. Are we still happy with how the device ids are organized in
general (i.e. when do we want a new one, and when do we want to extend
an existing device?)

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

[Demi Marie Obenour]

[-- Attachment #1.1: Type: text/plain, Size: 3078 bytes --]

On 10/22/26 00:35, Cornelia Huck wrote:
> On Wed, Oct 21 2026, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> 
>> On Wed, Oct 21, 2026 at 03:25:31PM -0400, Demi Marie Obenour wrote:
>>> On 10/21/26 14:00, Peter Hilber wrote:
>>>> 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.
>>>>
>>>> The Linux DCP display driver series is planned as the first user of this
>>>> device ID:
>>>>
>>>> https://lore.kernel.org/all/20261015-jshekhar-drm-msm-dcp-v1-v1-10-48aad0fe4f72@oss.qualcomm.com/
>>>>
>>>> Device ID 51 is already reserved for the Virtio HAB device:
>>>>
>>>> https://lore.kernel.org/virtio-comment/20260702140939.3535968-1-zeloren@qti.qualcomm.com/
>>>>
>>>> Signed-off-by: Peter Hilber <peter.hilber@oss.qualcomm.com>
>>>> ---
>>>>
>>>>     v2:
>>>>     
>>>>     - Rename the device from "Snapdragon device" to "QPSFI device".
>>>>     
>>>>     - Refer to DCP Linux driver patch as planned first QPSFI user.
>>>>     
>>>>     v1:
>>>>     
>>>>     - Was posted as "content: Reserve ID 52 for Snapdragon device":
>>>>     
>>>>       https://lore.kernel.org/virtio-comment/20260826115504.1955-1-peter.hilber@oss.qualcomm.com/
>>>>
>>>>  content.tex | 2 ++
>>>>  1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/content.tex b/content.tex
>>>> index 243ce2dde36b..7416939e67d3 100644
>>>> --- a/content.tex
>>>> +++ b/content.tex
>>>> @@ -805,6 +805,8 @@ \chapter{Device Types}\label{sec:Device Types}
>>>>  \hline
>>>>  50         &   Video encoder/decoder device \\
>>>>  \hline
>>>> +52         &   QPSFI device \\
>>>> +\hline
>>>>  \end{longtable}
>>>>  
>>>>  Some of the devices above are unspecified by this document,
>>>
>>> I think it would be best to have a single ID for vendor-specific devices.
>>> I believe most of the ID space has already been used, at least for virtio-PCI.
>>> -- 
>>> Sincerely,
>>> Demi Marie Obenour (she/her/hers)
>>
>> Sounds like a good idea to me. And then qualcomm can do what they
>> want, like check subsystem id for pci or whatever?
>> Only issue is there is no way to distinguish for mmio/ccw.
>> Maybe, add vendor specific id as first e.g. 8 bytes ro in the config space?
>> Peter?
> 
> Using some information in the config space looks like the most flexible
> way to me. Are we still happy with how the device ids are organized in
> general (i.e. when do we want a new one, and when do we want to extend
> an existing device?)

For a platform device like this, I'd prefer to pass the information out
of band.  After all, this device will only ever be found on Qualcomm
SoCs, and presumably the kernel knows exactly which PCI device is
supposed to be the QPSFI device.  This means that the kernel can just
special-case it.

Would it make sense to put this in the ACPI tables or device tree?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Michael S. Tsirkin]

On Thu, Oct 22, 2026 at 03:07:41AM -0400, Demi Marie Obenour wrote:
> On 10/22/26 00:35, Cornelia Huck wrote:
> > On Wed, Oct 21 2026, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > 
> >> On Wed, Oct 21, 2026 at 03:25:31PM -0400, Demi Marie Obenour wrote:
> >>> On 10/21/26 14:00, Peter Hilber wrote:
> >>>> 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.
> >>>>
> >>>> The Linux DCP display driver series is planned as the first user of this
> >>>> device ID:
> >>>>
> >>>> https://lore.kernel.org/all/20261015-jshekhar-drm-msm-dcp-v1-v1-10-48aad0fe4f72@oss.qualcomm.com/
> >>>>
> >>>> Device ID 51 is already reserved for the Virtio HAB device:
> >>>>
> >>>> https://lore.kernel.org/virtio-comment/20260702140939.3535968-1-zeloren@qti.qualcomm.com/
> >>>>
> >>>> Signed-off-by: Peter Hilber <peter.hilber@oss.qualcomm.com>
> >>>> ---
> >>>>
> >>>>     v2:
> >>>>     
> >>>>     - Rename the device from "Snapdragon device" to "QPSFI device".
> >>>>     
> >>>>     - Refer to DCP Linux driver patch as planned first QPSFI user.
> >>>>     
> >>>>     v1:
> >>>>     
> >>>>     - Was posted as "content: Reserve ID 52 for Snapdragon device":
> >>>>     
> >>>>       https://lore.kernel.org/virtio-comment/20260826115504.1955-1-peter.hilber@oss.qualcomm.com/
> >>>>
> >>>>  content.tex | 2 ++
> >>>>  1 file changed, 2 insertions(+)
> >>>>
> >>>> diff --git a/content.tex b/content.tex
> >>>> index 243ce2dde36b..7416939e67d3 100644
> >>>> --- a/content.tex
> >>>> +++ b/content.tex
> >>>> @@ -805,6 +805,8 @@ \chapter{Device Types}\label{sec:Device Types}
> >>>>  \hline
> >>>>  50         &   Video encoder/decoder device \\
> >>>>  \hline
> >>>> +52         &   QPSFI device \\
> >>>> +\hline
> >>>>  \end{longtable}
> >>>>  
> >>>>  Some of the devices above are unspecified by this document,
> >>>
> >>> I think it would be best to have a single ID for vendor-specific devices.
> >>> I believe most of the ID space has already been used, at least for virtio-PCI.
> >>> -- 
> >>> Sincerely,
> >>> Demi Marie Obenour (she/her/hers)
> >>
> >> Sounds like a good idea to me. And then qualcomm can do what they
> >> want, like check subsystem id for pci or whatever?
> >> Only issue is there is no way to distinguish for mmio/ccw.
> >> Maybe, add vendor specific id as first e.g. 8 bytes ro in the config space?
> >> Peter?
> > 
> > Using some information in the config space looks like the most flexible
> > way to me. Are we still happy with how the device ids are organized in
> > general (i.e. when do we want a new one, and when do we want to extend
> > an existing device?)
> 
> For a platform device like this, I'd prefer to pass the information out
> of band.  After all, this device will only ever be found on Qualcomm
> SoCs, and presumably the kernel knows exactly which PCI device is
> supposed to be the QPSFI device.  This means that the kernel can just
> special-case it.

Yes but we are discussing making this id a general "vendor specific
device", as opposed to a "qualcomm device".
Could you share, e.g. if this device has config space, and whether
reading X bytes at offset 0 of this device is harmless, for some value
of X?

> Would it make sense to put this in the ACPI tables or device tree?

As long as it's vendor specific.

> -- 
> Sincerely,
> Demi Marie Obenour (she/her/hers)

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

[Manos Pitsidianakis]

On Thu, Oct 22, 2026 at 10:24 AM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Thu, Oct 22, 2026 at 03:07:41AM -0400, Demi Marie Obenour wrote:
> > On 10/22/26 00:35, Cornelia Huck wrote:
> > > On Wed, Oct 21 2026, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > >
> > >> On Wed, Oct 21, 2026 at 03:25:31PM -0400, Demi Marie Obenour wrote:
> > >>> On 10/21/26 14:00, Peter Hilber wrote:
> > >>>> 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.
> > >>>>
> > >>>> The Linux DCP display driver series is planned as the first user of this
> > >>>> device ID:
> > >>>>
> > >>>> https://lore.kernel.org/all/20261015-jshekhar-drm-msm-dcp-v1-v1-10-48aad0fe4f72@oss.qualcomm.com/
> > >>>>
> > >>>> Device ID 51 is already reserved for the Virtio HAB device:
> > >>>>
> > >>>> https://lore.kernel.org/virtio-comment/20260702140939.3535968-1-zeloren@qti.qualcomm.com/
> > >>>>
> > >>>> Signed-off-by: Peter Hilber <peter.hilber@oss.qualcomm.com>
> > >>>> ---
> > >>>>
> > >>>>     v2:
> > >>>>
> > >>>>     - Rename the device from "Snapdragon device" to "QPSFI device".
> > >>>>
> > >>>>     - Refer to DCP Linux driver patch as planned first QPSFI user.
> > >>>>
> > >>>>     v1:
> > >>>>
> > >>>>     - Was posted as "content: Reserve ID 52 for Snapdragon device":
> > >>>>
> > >>>>       https://lore.kernel.org/virtio-comment/20260826115504.1955-1-peter.hilber@oss.qualcomm.com/
> > >>>>
> > >>>>  content.tex | 2 ++
> > >>>>  1 file changed, 2 insertions(+)
> > >>>>
> > >>>> diff --git a/content.tex b/content.tex
> > >>>> index 243ce2dde36b..7416939e67d3 100644
> > >>>> --- a/content.tex
> > >>>> +++ b/content.tex
> > >>>> @@ -805,6 +805,8 @@ \chapter{Device Types}\label{sec:Device Types}
> > >>>>  \hline
> > >>>>  50         &   Video encoder/decoder device \\
> > >>>>  \hline
> > >>>> +52         &   QPSFI device \\
> > >>>> +\hline
> > >>>>  \end{longtable}
> > >>>>
> > >>>>  Some of the devices above are unspecified by this document,
> > >>>
> > >>> I think it would be best to have a single ID for vendor-specific devices.
> > >>> I believe most of the ID space has already been used, at least for virtio-PCI.
> > >>> --
> > >>> Sincerely,
> > >>> Demi Marie Obenour (she/her/hers)
> > >>
> > >> Sounds like a good idea to me. And then qualcomm can do what they
> > >> want, like check subsystem id for pci or whatever?
> > >> Only issue is there is no way to distinguish for mmio/ccw.
> > >> Maybe, add vendor specific id as first e.g. 8 bytes ro in the config space?
> > >> Peter?
> > >
> > > Using some information in the config space looks like the most flexible
> > > way to me. Are we still happy with how the device ids are organized in
> > > general (i.e. when do we want a new one, and when do we want to extend
> > > an existing device?)
> >
> > For a platform device like this, I'd prefer to pass the information out
> > of band.  After all, this device will only ever be found on Qualcomm
> > SoCs, and presumably the kernel knows exactly which PCI device is
> > supposed to be the QPSFI device.  This means that the kernel can just
> > special-case it.
>
> Yes but we are discussing making this id a general "vendor specific
> device", as opposed to a "qualcomm device".

Is there a reason why a generic VIRTIO_ID_VENDOR wouldn't work?

Instead of adding more and more IDs for different devices that will
never been upstreamed.

Then, a kernel can discover all vendor devices when enumerating the
transport, ignore them unless it knows specifically about them through
ACPI or device tree.

It doesn't make sense to me that HAB/QPSFI need an ID when they are
unusable to anyone except for qualcomm kernel drivers so maybe we
should require that an ID allocation always needs an explicit
justification (i.e. "the spec will be upstreamed", or "we cannot use
VIRTIO_ID_VENDOR because X/Y/Z").



-- 
Manos Pitsidianakis
Emulation and Virtualization Engineer at Linaro Ltd

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

[Michael S. Tsirkin]

On Thu, Oct 22, 2026 at 11:41:17AM +0300, Manos Pitsidianakis wrote:
> On Thu, Oct 22, 2026 at 10:24 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Thu, Oct 22, 2026 at 03:07:41AM -0400, Demi Marie Obenour wrote:
> > > On 10/22/26 00:35, Cornelia Huck wrote:
> > > > On Wed, Oct 21 2026, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > >
> > > >> On Wed, Oct 21, 2026 at 03:25:31PM -0400, Demi Marie Obenour wrote:
> > > >>> On 10/21/26 14:00, Peter Hilber wrote:
> > > >>>> 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.
> > > >>>>
> > > >>>> The Linux DCP display driver series is planned as the first user of this
> > > >>>> device ID:
> > > >>>>
> > > >>>> https://lore.kernel.org/all/20261015-jshekhar-drm-msm-dcp-v1-v1-10-48aad0fe4f72@oss.qualcomm.com/
> > > >>>>
> > > >>>> Device ID 51 is already reserved for the Virtio HAB device:
> > > >>>>
> > > >>>> https://lore.kernel.org/virtio-comment/20260702140939.3535968-1-zeloren@qti.qualcomm.com/
> > > >>>>
> > > >>>> Signed-off-by: Peter Hilber <peter.hilber@oss.qualcomm.com>
> > > >>>> ---
> > > >>>>
> > > >>>>     v2:
> > > >>>>
> > > >>>>     - Rename the device from "Snapdragon device" to "QPSFI device".
> > > >>>>
> > > >>>>     - Refer to DCP Linux driver patch as planned first QPSFI user.
> > > >>>>
> > > >>>>     v1:
> > > >>>>
> > > >>>>     - Was posted as "content: Reserve ID 52 for Snapdragon device":
> > > >>>>
> > > >>>>       https://lore.kernel.org/virtio-comment/20260826115504.1955-1-peter.hilber@oss.qualcomm.com/
> > > >>>>
> > > >>>>  content.tex | 2 ++
> > > >>>>  1 file changed, 2 insertions(+)
> > > >>>>
> > > >>>> diff --git a/content.tex b/content.tex
> > > >>>> index 243ce2dde36b..7416939e67d3 100644
> > > >>>> --- a/content.tex
> > > >>>> +++ b/content.tex
> > > >>>> @@ -805,6 +805,8 @@ \chapter{Device Types}\label{sec:Device Types}
> > > >>>>  \hline
> > > >>>>  50         &   Video encoder/decoder device \\
> > > >>>>  \hline
> > > >>>> +52         &   QPSFI device \\
> > > >>>> +\hline
> > > >>>>  \end{longtable}
> > > >>>>
> > > >>>>  Some of the devices above are unspecified by this document,
> > > >>>
> > > >>> I think it would be best to have a single ID for vendor-specific devices.
> > > >>> I believe most of the ID space has already been used, at least for virtio-PCI.
> > > >>> --
> > > >>> Sincerely,
> > > >>> Demi Marie Obenour (she/her/hers)
> > > >>
> > > >> Sounds like a good idea to me. And then qualcomm can do what they
> > > >> want, like check subsystem id for pci or whatever?
> > > >> Only issue is there is no way to distinguish for mmio/ccw.
> > > >> Maybe, add vendor specific id as first e.g. 8 bytes ro in the config space?
> > > >> Peter?
> > > >
> > > > Using some information in the config space looks like the most flexible
> > > > way to me. Are we still happy with how the device ids are organized in
> > > > general (i.e. when do we want a new one, and when do we want to extend
> > > > an existing device?)
> > >
> > > For a platform device like this, I'd prefer to pass the information out
> > > of band.  After all, this device will only ever be found on Qualcomm
> > > SoCs, and presumably the kernel knows exactly which PCI device is
> > > supposed to be the QPSFI device.  This means that the kernel can just
> > > special-case it.
> >
> > Yes but we are discussing making this id a general "vendor specific
> > device", as opposed to a "qualcomm device".
> 
> Is there a reason why a generic VIRTIO_ID_VENDOR wouldn't work?
> 
> Instead of adding more and more IDs for different devices that will
> never been upstreamed.
> 
> Then, a kernel can discover all vendor devices when enumerating the
> transport, ignore them unless it knows specifically about them through
> ACPI or device tree.
> 
> It doesn't make sense to me that HAB/QPSFI need an ID when they are
> unusable to anyone except for qualcomm kernel drivers so maybe we
> should require that an ID allocation always needs an explicit
> justification (i.e. "the spec will be upstreamed", or "we cannot use
> VIRTIO_ID_VENDOR because X/Y/Z").

Right so let's just reserve ID 52 as VIRTIO_ID_VENDOR for now.
And document precisely what you are saying.

And let's add a chapter for it please:

"A driver is not automatically loaded based on VIRTIO_ID_VENDOR alone,
 instead, the platform probes the device, verifies it is the
 correct vendor specific driver and loads it, all in
 a platform specific way".

and conformance clauses stating the same.

-- 
MST

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

[Dmitry Baryshkov]

On Wed, Oct 21, 2026 at 08:00:31PM +0200, Peter Hilber wrote:
> 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.
> 
> The Linux DCP display driver series is planned as the first user of this
> device ID:

What exactly does this mean? What other users are planned for this
device? How do we plan to differentiate between them on the kernel side?
What exactly is planned for device 52? If the QPSFI device is passed
into the Guest VM, what should that VM do?

> 
> https://lore.kernel.org/all/20261015-jshekhar-drm-msm-dcp-v1-v1-10-48aad0fe4f72@oss.qualcomm.com/
> 
> Device ID 51 is already reserved for the Virtio HAB device:
> 
> https://lore.kernel.org/virtio-comment/20260702140939.3535968-1-zeloren@qti.qualcomm.com/
> 
> Signed-off-by: Peter Hilber <peter.hilber@oss.qualcomm.com>
> ---
> 
>     v2:
>     
>     - Rename the device from "Snapdragon device" to "QPSFI device".
>     
>     - Refer to DCP Linux driver patch as planned first QPSFI user.
>     
>     v1:
>     
>     - Was posted as "content: Reserve ID 52 for Snapdragon device":
>     
>       https://lore.kernel.org/virtio-comment/20260826115504.1955-1-peter.hilber@oss.qualcomm.com/
> 
>  content.tex | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/content.tex b/content.tex
> index 243ce2dde36b..7416939e67d3 100644
> --- a/content.tex
> +++ b/content.tex
> @@ -805,6 +805,8 @@ \chapter{Device Types}\label{sec:Device Types}
>  \hline
>  50         &   Video encoder/decoder device \\
>  \hline
> +52         &   QPSFI device \\
> +\hline
>  \end{longtable}
>  
>  Some of the devices above are unspecified by this document,
> -- 
> 2.43.0
> 

-- 
With best wishes
Dmitry

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

[Dmitry Baryshkov]

On Thu, Oct 22, 2026 at 09:19:16AM -0400, Michael S. Tsirkin wrote:
> On Thu, Oct 22, 2026 at 11:41:17AM +0300, Manos Pitsidianakis wrote:
> > On Thu, Oct 22, 2026 at 10:24 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> > >
> > > On Thu, Oct 22, 2026 at 03:07:41AM -0400, Demi Marie Obenour wrote:
> > > > On 10/22/26 00:35, Cornelia Huck wrote:
> > > > > On Wed, Oct 21 2026, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > > >
> > > > >> On Wed, Oct 21, 2026 at 03:25:31PM -0400, Demi Marie Obenour wrote:
> > > > >>> On 10/21/26 14:00, Peter Hilber wrote:
> > > > >>>> 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.
> > > > >>>>
> > > > >>>> The Linux DCP display driver series is planned as the first user of this
> > > > >>>> device ID:
> > > > >>>>
> > > > >>>> https://lore.kernel.org/all/20261015-jshekhar-drm-msm-dcp-v1-v1-10-48aad0fe4f72@oss.qualcomm.com/
> > > > >>>>
> > > > >>>> Device ID 51 is already reserved for the Virtio HAB device:
> > > > >>>>
> > > > >>>> https://lore.kernel.org/virtio-comment/20260702140939.3535968-1-zeloren@qti.qualcomm.com/
> > > > >>>>
> > > > >>>> Signed-off-by: Peter Hilber <peter.hilber@oss.qualcomm.com>
> > > > >>>> ---
> > > > >>>>
> > > > >>>>     v2:
> > > > >>>>
> > > > >>>>     - Rename the device from "Snapdragon device" to "QPSFI device".
> > > > >>>>
> > > > >>>>     - Refer to DCP Linux driver patch as planned first QPSFI user.
> > > > >>>>
> > > > >>>>     v1:
> > > > >>>>
> > > > >>>>     - Was posted as "content: Reserve ID 52 for Snapdragon device":
> > > > >>>>
> > > > >>>>       https://lore.kernel.org/virtio-comment/20260826115504.1955-1-peter.hilber@oss.qualcomm.com/
> > > > >>>>
> > > > >>>>  content.tex | 2 ++
> > > > >>>>  1 file changed, 2 insertions(+)
> > > > >>>>
> > > > >>>> diff --git a/content.tex b/content.tex
> > > > >>>> index 243ce2dde36b..7416939e67d3 100644
> > > > >>>> --- a/content.tex
> > > > >>>> +++ b/content.tex
> > > > >>>> @@ -805,6 +805,8 @@ \chapter{Device Types}\label{sec:Device Types}
> > > > >>>>  \hline
> > > > >>>>  50         &   Video encoder/decoder device \\
> > > > >>>>  \hline
> > > > >>>> +52         &   QPSFI device \\
> > > > >>>> +\hline
> > > > >>>>  \end{longtable}
> > > > >>>>
> > > > >>>>  Some of the devices above are unspecified by this document,
> > > > >>>
> > > > >>> I think it would be best to have a single ID for vendor-specific devices.
> > > > >>> I believe most of the ID space has already been used, at least for virtio-PCI.
> > > > >>> --
> > > > >>> Sincerely,
> > > > >>> Demi Marie Obenour (she/her/hers)
> > > > >>
> > > > >> Sounds like a good idea to me. And then qualcomm can do what they
> > > > >> want, like check subsystem id for pci or whatever?
> > > > >> Only issue is there is no way to distinguish for mmio/ccw.
> > > > >> Maybe, add vendor specific id as first e.g. 8 bytes ro in the config space?
> > > > >> Peter?
> > > > >
> > > > > Using some information in the config space looks like the most flexible
> > > > > way to me. Are we still happy with how the device ids are organized in
> > > > > general (i.e. when do we want a new one, and when do we want to extend
> > > > > an existing device?)
> > > >
> > > > For a platform device like this, I'd prefer to pass the information out
> > > > of band.  After all, this device will only ever be found on Qualcomm
> > > > SoCs, and presumably the kernel knows exactly which PCI device is
> > > > supposed to be the QPSFI device.  This means that the kernel can just
> > > > special-case it.
> > >
> > > Yes but we are discussing making this id a general "vendor specific
> > > device", as opposed to a "qualcomm device".
> > 
> > Is there a reason why a generic VIRTIO_ID_VENDOR wouldn't work?
> > 
> > Instead of adding more and more IDs for different devices that will
> > never been upstreamed.

The driver for the QPSFI (well, at least for the display controller) has
been posted and it targets being upstreamed.

> > 
> > Then, a kernel can discover all vendor devices when enumerating the
> > transport, ignore them unless it knows specifically about them through
> > ACPI or device tree.

In case of QPSFI the device is visible to the host through the
VirtIO-MMIO on steroids. However, nothing prevents one from passing that
device into the guest VM (e.g. in QEMU) where it then becomes a
VirtIO-PCI device. The same issues would apply to any other vendor
trying to implement the driver for this VirtIO device (and trying to run
the generic enough kernel which supports multiple "vendor" devices).

> > 
> > It doesn't make sense to me that HAB/QPSFI need an ID when they are
> > unusable to anyone except for qualcomm kernel drivers so maybe we
> > should require that an ID allocation always needs an explicit
> > justification (i.e. "the spec will be upstreamed", or "we cannot use
> > VIRTIO_ID_VENDOR because X/Y/Z").
> 
> Right so let's just reserve ID 52 as VIRTIO_ID_VENDOR for now.
> And document precisely what you are saying.
> 
> And let's add a chapter for it please:
> 
> "A driver is not automatically loaded based on VIRTIO_ID_VENDOR alone,
>  instead, the platform probes the device, verifies it is the
>  correct vendor specific driver and loads it, all in
>  a platform specific way".

From my point of view this would be very fragile as different vendors
would implement different mechanisms to identify the device. It would
make it pretty much impossible to support multiple "vendor" devices in
the upstream kernel.

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

> 
> and conformance clauses stating the same.

-- 
With best wishes
Dmitry

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

[Zelong Ren]

Hi Manos, Michael,

> What about the HAB btw? It was said the spec will be upstreamed
> did I miss that?

> It doesn't make sense to me that HAB/QPSFI need an ID when they are
> unusable to anyone except for qualcomm kernel drivers so maybe we
> should require that an ID allocation always needs an explicit
> justification (i.e. "the spec will be upstreamed", or "we cannot use
> VIRTIO_ID_VENDOR because X/Y/Z").

We are already working on virtio-hab specification, linux kernel RFC patch and qemu patch
as the first review package. It is not intended to remain a Qualcomm-only device or driver. 

In fact, even the downstream virtio-hab hab vendor specific implementation, it has already
been used by many external Qualcomm customers as an easy-to-use and reliable generic
inter-VM shared-memory IPC mechanism.

Current work is trimming down the vendor specific implementation and add support
for more common arch(x86, arm), more common vmm(qemu, crosvm) based on kvm(and Xen follows).
We need some time to complete this work but it will be soon.

We will need everybody's support on this.

Just to repeat the functionality of virtio-hab is to provide a generic inter-VM shared-memory IPC
mechanism for user-space applications on multi-VM systems. HAB provides shared-memory support as
the primary data path, including complete shared-memory lifecycle management. HAB also provides
a simple messaging mechanism as the control path for connection management and simple synchronization
between the frontend and backend.

So for virtio-hab, the existing approved device id 51 is more appropriate for everyone. This is very
different than a generic VIRTIO_ID_VENDOR.

Please let us know if you have any more questions.

Best regards,
Zelong

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

[Cornelia Huck]

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.

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

[Parav Pandit]

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

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

[Michael S. Tsirkin]

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.


-- 
MST

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

[Michael S. Tsirkin]

On Thu, Oct 22, 2026 at 05:07:09PM +0300, Dmitry Baryshkov 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".

That is best, yes. Is this acceptable for Qualcomm? You will be
able to make it work with your SOCs?

-- 
MST

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

[Parav Pandit]

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

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.

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

[Michael S. Tsirkin]

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.

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

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

[Parav Pandit]

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

And if it is not for experimental purpose, not sure why would vendor stop at only one device.

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

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

[Michael S. Tsirkin]

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.

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

[Peter Hilber]

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


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

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

[Michael S. Tsirkin]

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

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

[Parav Pandit]

> From: Peter Hilber <peter.hilber@oss.qualcomm.com>
> Sent: 23 October 2026 04:10 AM
> 
> 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?
>
Given this is vendor specific device, I am unable to find the value of virtio-community to maintain the device and it spec.
Motivation is unclear.

virtio spec is something that multi-vendors can implement.

Hence, can you please keep the driver and the spec outside of the virtio spec, and keep that in Qualcomm domain?

 
> Best regards,
> 
> Peter
> 
> 
> > > > > 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.
> >

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

[Manos Pitsidianakis]

On Fri, Oct 23, 2026 at 1:39 AM Peter Hilber
<peter.hilber@oss.qualcomm.com> 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.
> >


Hello Peter,

> Thank you to everybody contributing to the discussion and to the concept
> of a vendor-specific device.

I'd like to echo the sentiment that it unfortunately doesn't seem
necessary to call vendor devices virtio at all.

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

But no upstream specification, correct? There's no point without an
open device specification to being included in a specification. People
can only implement frontend drivers for this vendor device, and only
by reading the upstream code - no spec to follow. Similar to a vendor
SoC in concept.

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

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

[Demi Marie Obenour]

[-- Attachment #1.1: Type: text/plain, Size: 5431 bytes --]

On 10/23/26 01:37, Manos Pitsidianakis wrote:
> On Fri, Oct 23, 2026 at 1:39 AM Peter Hilber
> <peter.hilber@oss.qualcomm.com> 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.
>>>
> 
> 
> Hello Peter,
> 
>> Thank you to everybody contributing to the discussion and to the concept
>> of a vendor-specific device.
> 
> I'd like to echo the sentiment that it unfortunately doesn't seem
> necessary to call vendor devices virtio at all.

It acts like a virtio device, but otherwise I agree.

>  > 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.
> 
> But no upstream specification, correct? There's no point without an
> open device specification to being included in a specification. People
> can only implement frontend drivers for this vendor device, and only
> by reading the upstream code - no spec to follow. Similar to a vendor
> SoC in concept.
> 
>>
>> 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
>>
>>
>>>>>> 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.
>>>
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Peter Hilber]

On Fri, Oct 23, 2026 at 01:40:13AM -0400, Demi Marie Obenour wrote:
> On 10/23/26 01:37, Manos Pitsidianakis wrote:
> > On Fri, Oct 23, 2026 at 1:39 AM Peter Hilber
> > <peter.hilber@oss.qualcomm.com> 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.
> >>>
> > 
> > 
> > Hello Peter,
> > 
> >> Thank you to everybody contributing to the discussion and to the concept
> >> of a vendor-specific device.
> > 
> > I'd like to echo the sentiment that it unfortunately doesn't seem
> > necessary to call vendor devices virtio at all.
> 
> It acts like a virtio device, but otherwise I agree.
> 
> >  > 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.

Qualcomm's intent is to upstream a Linux kernel Virtio driver for a
non-standardized device using a Virtio transport [1]. It should be able
to work in a vanilla Linux kernel. I think this requires a new
"vendor-specific" or similar device. The driver needs to avoid
collisions with other devices and must not take an unassigned ID.

I think "vendor-specific" does not capture all possible use cases for
such a device, though. It could be a "self-assigned" device, e.g. for
prototypes to be standardized later.

In the discussion, it was proposed to distinguish "vendor-specific"
devices through common configuration space fields. I would suggest to
use a UUID at the start of the configuration space of the new device 52
to distinguish "vendor-specific"/"self-assigned" devices. Everybody can
generate a UUID when needed. This would

- allow everybody to create new devices without ID collisions due to
  using unregistered IDs

- allow using UUIDs for prototyping, with a new one available for each
  breaking change

- be a way to resolve the device ID scarcity

- relieve Virtio TC from some device ID registration work.

Best regards,

Peter


[1] https://lore.kernel.org/all/20261015-jshekhar-drm-msm-dcp-v1-v1-10-48aad0fe4f72@oss.qualcomm.com/

> > 
> > But no upstream specification, correct? There's no point without an
> > open device specification to being included in a specification. People
> > can only implement frontend drivers for this vendor device, and only
> > by reading the upstream code - no spec to follow. Similar to a vendor
> > SoC in concept.
> > 
> >>
> >> 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
> >>
> >>
> >>>>>> 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.
> >>>
> -- 
> Sincerely,
> Demi Marie Obenour (she/her/hers)

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

[Michael S. Tsirkin]

On Fri, Oct 23, 2026 at 10:56:24PM +0200, Peter Hilber wrote:
> - relieve Virtio TC from some device ID registration work.

At the cost of easing pressure on vendors to specify their
devices.

-- 
MST

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

[Cornelia Huck]

On Fri, Oct 23 2026, Peter Hilber <peter.hilber@oss.qualcomm.com> wrote:

> Qualcomm's intent is to upstream a Linux kernel Virtio driver for a
> non-standardized device using a Virtio transport [1]. It should be able
> to work in a vanilla Linux kernel. I think this requires a new
> "vendor-specific" or similar device. The driver needs to avoid
> collisions with other devices and must not take an unassigned ID.
>
> I think "vendor-specific" does not capture all possible use cases for
> such a device, though. It could be a "self-assigned" device, e.g. for
> prototypes to be standardized later.
>
> In the discussion, it was proposed to distinguish "vendor-specific"
> devices through common configuration space fields. I would suggest to
> use a UUID at the start of the configuration space of the new device 52
> to distinguish "vendor-specific"/"self-assigned" devices. Everybody can
> generate a UUID when needed. This would
>
> - allow everybody to create new devices without ID collisions due to
>   using unregistered IDs
>
> - allow using UUIDs for prototyping, with a new one available for each
>   breaking change

I would prefer to have a namespace for this kind of experimentation,
i.e. <testing prefix><uuid>, with vendor or purpose-specific devices
using <vendor/purpose prefix><uuid>, so that...

>
> - be a way to resolve the device ID scarcity

...this would still hold (I think the most limiting factor for this is
actually ccw? not sure how much we care about implementing new devices
on ccw, though), and...

>
> - relieve Virtio TC from some device ID registration work.

...this would also still somewhat hold (no need to reserve an ID for
everything, but if you're serious, get a vendor-or-purpose prefix.)
I'd still want to encourage everyone creating a serious device to go and
try to standardize it.

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

[Peter Hilber]

On Mon, Oct 26, 2026 at 03:31:16PM +0100, Cornelia Huck wrote:
> On Fri, Oct 23 2026, Peter Hilber <peter.hilber@oss.qualcomm.com> wrote:
> 
> > Qualcomm's intent is to upstream a Linux kernel Virtio driver for a
> > non-standardized device using a Virtio transport [1]. It should be able
> > to work in a vanilla Linux kernel. I think this requires a new
> > "vendor-specific" or similar device. The driver needs to avoid
> > collisions with other devices and must not take an unassigned ID.
> >
> > I think "vendor-specific" does not capture all possible use cases for
> > such a device, though. It could be a "self-assigned" device, e.g. for
> > prototypes to be standardized later.
> >
> > In the discussion, it was proposed to distinguish "vendor-specific"
> > devices through common configuration space fields. I would suggest to
> > use a UUID at the start of the configuration space of the new device 52
> > to distinguish "vendor-specific"/"self-assigned" devices. Everybody can
> > generate a UUID when needed. This would
> >
> > - allow everybody to create new devices without ID collisions due to
> >   using unregistered IDs
> >
> > - allow using UUIDs for prototyping, with a new one available for each
> >   breaking change
> 
> I would prefer to have a namespace for this kind of experimentation,
> i.e. <testing prefix><uuid>, with vendor or purpose-specific devices
> using <vendor/purpose prefix><uuid>, so that...
> 
> >
> > - be a way to resolve the device ID scarcity
> 
> ...this would still hold (I think the most limiting factor for this is
> actually ccw? not sure how much we care about implementing new devices
> on ccw, though), and...
> 
> >
> > - relieve Virtio TC from some device ID registration work.
> 
> ...this would also still somewhat hold (no need to reserve an ID for
> everything, but if you're serious, get a vendor-or-purpose prefix.)
> I'd still want to encourage everyone creating a serious device to go and
> try to standardize it.
> 

I am wondering how these namespaces would be managed and used. Would
introducing a vendor/purpose prefix require an approval process in the
Virtio TC? Would new standardized devices have a "standard" prefix when
using ID 52?

Could a device UUID transparently transition from testing to
vendor/purpose, so that drivers would only match on the UUID? Could the
namespaces be seen as a quality gate so that testing-prefix devices may
be refused in some circumstances?