virtio — archive

[PATCH v5 0/7] Introduce device group and device management

From: Cornelia Huck <[email protected]>
To: [email protected]
Date: Tue, 17 May 2022 10:08:00 -0000

On Mon, May 16 2022, Parav Pandit <[email protected]> wrote: > Hi Michael, > >> From: Michael S. Tsirkin <[email protected]> >> Sent: Sunday, May 15, 2022 11:24 AM > > [..] > >> > +\subsection{VIRTIO ADMIN DEVICE CAPS ACCEPT >> command}\label{sec:Basic >> > +Facilities of a Virtio Device / Admin command set / VIRTIO ADMIN >> > +DEVICE CAPS ACCEPT command} >> > + >> > +The VIRTIO_ADMIN_DEVICE_CAPS_ACCEPT command is used by the >> driver to acknowledge those admin capabilities it understands and wishes to >> use. >> >> >> ok so we have a protocol here, kind of like feature negotiation. Please write >> its description. >> e.g. is it ok to change accepted caps? when? can device change its caps etc >> etc etc. >> >> Avoiding this kind of spec work is exactly why me and jason keep telling you >> to consider just using features instead. Add a 64 bit admin features field to >> the PCI transport and be done with it. CCW and MMIO already have feature >> selector so it's trivial to add feature bits. >> > As we begin to scale with the device, adding more and more registers like this demands more on-device real estate to comply to the PCI standards. > > And therefore, things are queried/accessed rare or occasionally, are better accessed via a queue interface. > > One can argue that admin VQ is proposed only for the mgmt. functions so having this cfg register for PF is enough. > > However, AQ may find some usage in the VF/SF themselves down the road. > Hence, keeping the cap exchange transport this way is more optimal. > > Max has called out this AQ rationale in 4 or 5 points in the cover letter. I'm not against using a queue, but why not use feature bits for capabilities? As Michael said, the infrastructure for that is already in place.