On 2021/2/26 3:36 下午, Parav Pandit wrote:
Hi Michael, Jason,
From: Michael S. Tsirkin <mst@xxxxxxxxxx>
Sent: Wednesday, February 24, 2021 12:40 PM
On Wed, Feb 24, 2021 at 08:18:36AM +0200, Parav Pandit wrote:
To honor VIRTIO_F_VERSION_1 feature bit, during endianness detection,
consider the read only supported features bit instead of current
features bit which can be modified by the driver.
This enables vdpa_sim_net driver to invoke cpu_to_vdpasim16() early
enough just after vdpasim device creation in subsequent patch.
Signed-off-by: Parav Pandit <parav@xxxxxxxxxx>
Reviewed-by: Eli Cohen <elic@xxxxxxxxxx>
Well that works for legacy and modern devices but not for transitional ones.
Without transitional device support vendors are reluctant to add modern
features since that will break old guests ... I suspect we need to either add a
new ioctl enabling modern mode, or abuse SET_FEATURES and call it from
qemu on first config space access.
From mgmt tool kernel point of view,
(a) config space decoding depends on current feature version bit
(b) feature get/set and config read are not atomic callbacks
Mgmt. tool kernel code need to read them in single call from the vendor driver.
I need to add mgmt_dev->ops->get_features_config(struct virtio_features_config*) calllback that returns value of both atomically in structure like below.
struct virtio_features_config {
u64 features;
union {
struct virtio_net_config net;
struct virtio_block_config blk;
} u;
}
What do you think?
I'm wait for Michael to clairfy how the dependency will look like. E.g
without multiqueue, should we consider the config as:
struct virtio_net_config {
u8 mac[6];
le16 status;
le16 reserved;
le16 mtu;
};
or
struct virtio_net_config {
u8 mac[6];
le16 status;
le16 mtu;
};
And I wonder whether or not to reuse config is the best choice which
needs to deal with feature.
Thanks
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
