You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This commit enhances the VirtioDeviceActions Trait to allow
the VMM leverage the VirtIO MMIO implementation for not only
VirtIO devices but also for vhost and vhost-user devices.
Problems:
1) Since the device configuration space can be managed by various
handlers outside of the VMM, such as vhost-user devices when the
VHOST_USER_PROTOCOL_F_CONFIG feature is negotiated between the
backend and the VMM, we need to invoke dedicated logic instead
of performing the MMIO operations through the vm-virtio workspace.
2) When the driver completes the negotiation of the driver features
with the VMM, , selecting page zero within the DriverFeatures MMIO
field, we need to negotiate both the acknowledged features and the
respective protocol features with the vhost/vhost-user backend devices.
Otherwise, the device will not be prepared to support, for example,
multiple queues and configuration space reads and writes.
3) When the backend device sends an interrupt to the frontend driver,
it needs to write the interrupt status so that later the driver
determines the type of notification — whether it is a used
buffer or a configuration change notification.
Since the responsibility for managing the interrupt status lies with the
VMM through a normal MMIO write/read, if the device is not implemented
within the VMM, it cannot manage the interrupt status field.
Solution:
1) Added `read_config` and `write_config` methods to allow the VMM
to instead of executing MMIO writes and reads within the vm-virtio
workspace, using the set_config and get_config methods provided by the
Rust-VMM vhost workspace.
2) Added the `negotiate_driver_features` method to allow the VMM
to exchange the driver and protocol features with the backend
device.
3) Added the `interrupt_status` method to allow the VMM to,
for example, read the configuration space from the backend device
and check for any changes. If the device configuration space has
changed, the VMM may update the interrupt status register by setting
bit 1. Conversely, if no changes are detected, the VMM may set the
bit 0, signaling a used buffer notifcation.
This applies to the backends that do not use the
VHOST_USER_BACKEND_CONFIG_CHANGE_MSG message to notify
about configuration changes (which I think is the case for all
Rust-VMM vhost-user backends).
Otherwise, the VMM can simply handle the message and update the
interrupt status register accordingly.
Signed-off-by: João Peixoto <[email protected]>
0 commit comments