[virtio-comment] Re: proposal: use admin command (and aq) of the device to query config space

["Zhu, Lingshan" <lingshan.zhu@intel.com>]

On 8/2/2023 4:59 PM, Parav Pandit wrote:
>> From: Zhu, Lingshan <lingshan.zhu@intel.com>
>> Sent: Wednesday, August 2, 2023 2:15 PM
>> Rebasing "transport vq" on admin vq is still in my pipeline, I am currently
>> working on a patch series implementing virtio pci live migration in the
>> spec(carry on Jason and Eugenio's work).
>> I will post it next week and back to transport vq task then.
>>
> Awesome and interesting to us as well.
> I have draft for member device migration admin commands.
> I guess yours will hit the mailing list first, so we can converge on your series.
OK
>
>> For SIOV, I have implemented the interfaces for querying the configurations, for
>> example:
>> 1) Access config space:
>>
>> 247 +\begin{lstlisting}
>> 248 +#define VIRTIO_TRANSPTQ_CTRL_CONFIG    6
>> 249 +  #define VIRTIO_TRANSPTQ_CTRL_CONFIG_GET    0
>> 250 +  #define VIRTIO_TRANSPTQ_CTRL_CONFIG_SET    1
>> 251 +
>> 252 +struct virtio_transportq_ctrl_dev_config_get {
>> 253 +       u32 offset;
>> 254 +       u32 size;
>> 255 +};
>> 256 +
>> 257 +struct virtio_transportq_ctrl_dev_config_set {
>> 258 +       u32 offset;
>> 259 +       u32 size;
>> 260 +       u8  data[];
>> 261 +};
>> 262 +\end{lstlisting}
>>
>> I think we can re-use the GET command for SR-IOV, I am afraid SET would be a
>> side-channel attacking surface for SR-IOV.
>>
> Get and set both should be inband for PF, VF, SIOV.
> I don’t see any need to diverge and create any weird combinations differently for 3 different device types.
I am not sure, when passthrough a device to a guest, the guest driver 
ownes the config space of the device,
if we allow changes against the config space through admin vq from host, 
it looks like a risk.
>
>> 2) a specific config, e.g., features:
>>
>> 142 +The features negotiation of managed devices is done by the
>> 143 +following commands:
>> 144 +
>> 145 +\begin{lstlisting}
>> 146 +#define VIRTIO_TRANSPTQ_CTRL_FEAT   3
>> 147 + #define VIRTIO_TRANSPTQ_CTRL_FEAT_DEVICE_GET        0
>> 148 + #define VIRTIO_TRANSPTQ_CTRL_FEAT_DRIVER_SET        1
>> 149 + #define VIRTIO_TRANSPTQ_CTRL_FEAT_DRIVER_GET        2
>> 150 +
>> 151 +struct virtio_transportq_ctrl_dev_features {
>> 152 +        u32 features_len;
>> 153 +        u32 features[features_len];
>> 154 +};
>> 155 +\end{lstlisting}
>>
>> still can re-use the GET commands.
>>
>> Thanks
>> Zhu Lingshan


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/