History log of /cloud-hypervisor/vm-virtio/src/queue.rs (Results 1 – 25 of 45)
Revision Date Author Comments
# 190d9019 10-Jun-2025 Jinank Jain <jinankjain@microsoft.com>

build: Bump vfio and all the dependent crates to latest version

Recently vfio crates have moved to crates.io, thus we should start
consuming the crate from crates.io instead git url.

This results i

build: Bump vfio and all the dependent crates to latest version

Recently vfio crates have moved to crates.io, thus we should start
consuming the crate from crates.io instead git url.

This results in better versioning instead of tracking some git commit
sha.

Signed-off-by: Jinank Jain <jinankjain@microsoft.com>

show more ...


# b41daddc 18-Oct-2024 Ruoqing He <heruoqing@iscas.ac.cn>

misc: Remove manual implementation of is_power_of_two

As clippy of rust-toolchain version 1.83.0-beta.1 suggests, remove
manual implementation of `is_power_of_two` to improve readability.

Signed-of

misc: Remove manual implementation of is_power_of_two

As clippy of rust-toolchain version 1.83.0-beta.1 suggests, remove
manual implementation of `is_power_of_two` to improve readability.

Signed-off-by: Ruoqing He <heruoqing@iscas.ac.cn>

show more ...


# 61e57e1c 29-Sep-2024 Ruoqing He <heruoqing@iscas.ac.cn>

misc: Further improve imports styling

By introducing `imports_granularity="Module"` format strategy,
effectively groups imports from the same module into one line or block,
improving maintainability

misc: Further improve imports styling

By introducing `imports_granularity="Module"` format strategy,
effectively groups imports from the same module into one line or block,
improving maintainability and readability.

Signed-off-by: Ruoqing He <heruoqing@iscas.ac.cn>

show more ...


# 88a9f799 29-Sep-2024 Rob Bradford <rbradford@rivosinc.com>

misc: Adapt consistent import style formatting

Historically the Cloud Hypervisor coding style has been to ensure that
all imports are ordered and placed in a single group. Unfortunately
cargo fmt ha

misc: Adapt consistent import style formatting

Historically the Cloud Hypervisor coding style has been to ensure that
all imports are ordered and placed in a single group. Unfortunately
cargo fmt has no support for ensuring that all imports are in a single
group so if whitespace lines were added as part of the import statements
then they would only be odered correctly in the group.

By adopting "group_imports="StdExternalCrate" we can enforce a style
where imports are placed in at most three groups for std, external
crates and the crate itself. Choosing a style enforceable by the tooling
reduces the reviewer burden.

Signed-off-by: Rob Bradford <rbradford@rivosinc.com>

show more ...


# a423bf13 06-Jul-2022 Sebastien Boeuf <sebastien.boeuf@intel.com>

virtio: Port codebase to the latest virtio-queue version

The new virtio-queue version introduced some breaking changes which need
to be addressed so that Cloud Hypervisor can still work with this
ve

virtio: Port codebase to the latest virtio-queue version

The new virtio-queue version introduced some breaking changes which need
to be addressed so that Cloud Hypervisor can still work with this
version.

The most important change is about removing a handle to the guest memory
from the Queue, meaning the caller has to provide the guest memory
handle for multiple methods from the QueueT trait.

One interesting aspect is that QueueT has been widely extended to
provide every getter and setter we need to access and update the Queue
structure without having direct access to its internal fields.

This patch ports all the virtio and vhost-user devices to this new crate
definition. It also updates both vhost-user-block and vhost-user-net
backends based on the updated vhost-user-backend crate. It also updates
the fuzz directory.

Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>

show more ...


# 0162d73e 21-Dec-2021 Sebastien Boeuf <sebastien.boeuf@intel.com>

virtio-queue: Update crate based on latest rust-vmm/vm-virtio

This crate contains up to date definition of the Queue, AvailIter,
DescriptorChain and Descriptor structures forked from the upstream
cr

virtio-queue: Update crate based on latest rust-vmm/vm-virtio

This crate contains up to date definition of the Queue, AvailIter,
DescriptorChain and Descriptor structures forked from the upstream
crate rust-vmm/vm-virtio 27b18af01ee2d9564626e084a758a2b496d2c618.

The following patches have been applied on top of this base in order to
make it work correctly with Cloud Hypervisor requirements:

- Add MSI vector field to the Queue

In order to help with MSI/MSI-X support, it is convenient to store the
value of the interrupt vector inside the Queue directly.

- Handle address translations

For devices with access to data in memory being translated, we add to
the Queue the ability to translate the address stored in the
descriptor.
It is very helpful as it performs the translation right after the
untranslated address is read from memory, avoiding any errors from
happening from the consumer's crate perspective. It also allows the
consumer to reduce greatly the amount of duplicated code for applying
the translation in many different places.

- Add helpers for Queue structure

They are meant to help crate's consumers getting/setting information
about the Queue.

These patches can be found on the 'ch' branch from the Cloud Hypervisor
fork: https://github.com/cloud-hypervisor/vm-virtio.git

This patch takes care of updating the Cloud Hypervisor code in
virtio-devices and vm-virtio to build correctly with the latest version
of virtio-queue.

Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>

show more ...


# f035cff1 17-Nov-2021 Wei Liu <liuwe@microsoft.com>

vm-virtio: drop VirtqUsedElem from its test module

Use the one defined in virtio_queue instead.

Signed-off-by: Wei Liu <liuwe@microsoft.com>


# 0249e864 21-Oct-2021 Sebastien Boeuf <sebastien.boeuf@intel.com>

Move Cloud Hypervisor to virtio-queue crate

Relying on the vm-virtio/virtio-queue crate from rust-vmm which has been
copied inside the Cloud Hypervisor tree, the entire codebase is moved to
the new

Move Cloud Hypervisor to virtio-queue crate

Relying on the vm-virtio/virtio-queue crate from rust-vmm which has been
copied inside the Cloud Hypervisor tree, the entire codebase is moved to
the new definition of a Queue and other related structures.

The reason for this move is to follow the upstream until we get some
agreement for the patches that we need on top of that to make it
properly work with Cloud Hypervisor.

Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>

show more ...


# 5825ab2d 23-Jun-2021 Bo Chen <chen.bo@intel.com>

clippy: Address the issue 'needless-borrow'

Issue from beta verion of clippy:

Error: --> vm-virtio/src/queue.rs:700:59
|
700 | if let Some(used_event) = self.get_used_event(&mem)

clippy: Address the issue 'needless-borrow'

Issue from beta verion of clippy:

Error: --> vm-virtio/src/queue.rs:700:59
|
700 | if let Some(used_event) = self.get_used_event(&mem) {
| ^^^^ help: change this to: `mem`
|
= note: `-D clippy::needless-borrow` implied by `-D warnings`
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_borrow

Signed-off-by: Bo Chen <chen.bo@intel.com>

show more ...


# b5bcdbaf 02-Jun-2021 Bo Chen <chen.bo@intel.com>

misc: Upgrade to use the vm-memory crate w/ dirty-page-tracking

As the first step to complete live-migration with tracking dirty-pages
written by the VMM, this commit patches the dependent vm-memory

misc: Upgrade to use the vm-memory crate w/ dirty-page-tracking

As the first step to complete live-migration with tracking dirty-pages
written by the VMM, this commit patches the dependent vm-memory crate to
the upstream version with the dirty-page-tracking capability. Most
changes are due to the updated `GuestMemoryMmap`, `GuestRegionMmap`, and
`MmapRegion` structs which are taking an additional generic type
parameter to specify what 'bitmap backend' is used.

The above changes should be transparent to the rest of the code base,
e.g. all unit/integration tests should pass without additional changes.

Signed-off-by: Bo Chen <chen.bo@intel.com>

show more ...


# 57f532a7 01-Jun-2021 Rob Bradford <robert.bradford@intel.com>

virtio-devices, vm-virtio: Refactor queue state saving/restoring

Use a separate QueueState structure which can be versioned.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>


# 8160c288 18-May-2021 Dayu Liu <liu.dayu@zte.com.cn>

docs: Fix some typos in docs and comments

Fix some typos or misspellings without functional change.

Signed-off-by: Dayu Liu <liu.dayu@zte.com.cn>


# 496ceed1 11-May-2021 Rob Bradford <robert.bradford@intel.com>

misc: Remove unnecessary "extern crate"

Now all crates use edition = "2018" then the majority of the "extern
crate" statements can be removed. Only those for importing macros need
to remain.

Signed

misc: Remove unnecessary "extern crate"

Now all crates use edition = "2018" then the majority of the "extern
crate" statements can be removed. Only those for importing macros need
to remain.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>

show more ...


# 1eb4ebe3 29-Mar-2021 Rob Bradford <robert.bradford@intel.com>

vm-virtio: queue: Fix descriptor chain validation

DescriptorChain::is_valid() wrongly used .checked_offset() to attempt to
validate that the descriptor's data is in valid memory. This works in
all c

vm-virtio: queue: Fix descriptor chain validation

DescriptorChain::is_valid() wrongly used .checked_offset() to attempt to
validate that the descriptor's data is in valid memory. This works in
all cases except where the guest has placed the data at the very end of
the guest memory as the offset + offset will be outside the range (as
the combined offset will be the next byte and as such out of the guest
memory). Instead use the function .check_range() takes an offset and a
length to validate

This fixes issues see with error messages featuring the
DescriptorChainTooShort error.

Fixes: #2424

Signed-off-by: Rob Bradford <robert.bradford@intel.com>

show more ...


# 46d08276 24-Mar-2021 Rob Bradford <robert.bradford@intel.com>

vm-virtio: queue: Fix comment for DescriptorChain::has_next()

This returns trues if this descriptor has another descriptor linked to
it. Not whether this descriptor chain has another one following i

vm-virtio: queue: Fix comment for DescriptorChain::has_next()

This returns trues if this descriptor has another descriptor linked to
it. Not whether this descriptor chain has another one following it.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>

show more ...


# f685f0e0 16-Mar-2021 Zide Chen <zide.chen@intel.com>

vm-virtio: initialize MSI-X vectors with VIRTIO_MSI_NO_VECTOR

In case of the virtio frontend driver doesn't need interupts for
certain queue event, it may explicitly write VIRTIO_MSI_NO_VECTOR
to th

vm-virtio: initialize MSI-X vectors with VIRTIO_MSI_NO_VECTOR

In case of the virtio frontend driver doesn't need interupts for
certain queue event, it may explicitly write VIRTIO_MSI_NO_VECTOR
to the virtio common configuration, or it may doesn't configure
the event type vector at all.

This patch initializes both MSI-X configuration vector and queue vector
with VIRTIO_MSI_NO_VECTOR, so that the backend drivers won't trigger
unexpected interrupts to the guest.

Signed-off-by: Zide Chen <zide.chen@intel.com>

show more ...


# 72b73615 19-Jan-2021 Xie Yongji <xieyongji@bytedance.com>

vm-virtio: Fix update_avail_event() memory ordering

We should use full memory barrier to ensure both guest and us
can see the correct avail_idx and avail_event_idx. Something
like this pattern:

VM:

vm-virtio: Fix update_avail_event() memory ordering

We should use full memory barrier to ensure both guest and us
can see the correct avail_idx and avail_event_idx. Something
like this pattern:

VM: CLH:
update vring.avail->idx update avail_event_idx
mb() mb()
read avail_event_idx read vring.avail->idx

Signed-off-by: Xie Yongji <xieyongji@bytedance.com>

show more ...


# 230e8a23 05-Jan-2021 Rob Bradford <robert.bradford@intel.com>

vm-virtio: queue: Reduce logging level of EVENT_IDX logs

This logging is too spammy for info!() level and should be handled as
debug!() level

Signed-off-by: Rob Bradford <robert.bradford@intel.com>


# fabd6307 02-Jan-2021 Rob Bradford <robert.bradford@intel.com>

misc: Remove unnecessary literal casts

Signed-off-by: Rob Bradford <robert.bradford@intel.com>


# 5c3f4dbe 22-Sep-2020 Josh Soref <jsoref@users.noreply.github.com>

ch: Fix various misspelled words

Misspellings were identified by https://github.com/marketplace/actions/check-spelling
* Initial corrections suggested by Google Sheets
* Additional corrections by Go

ch: Fix various misspelled words

Misspellings were identified by https://github.com/marketplace/actions/check-spelling
* Initial corrections suggested by Google Sheets
* Additional corrections by Google Chrome auto-suggest
* Some manual corrections

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

show more ...


# dac60030 02-Sep-2020 Rob Bradford <robert.bradford@intel.com>

vm-virtio: queue: Clear all queue fields on reset

Some of the fields on the queue were not being cleared up on device
reset.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>


# 2a6eb31d 02-Jul-2020 Rob Bradford <robert.bradford@intel.com>

vm-virtio, virtio-devices: Split device implementation from virt queues

Split the generic virtio code (queues and device type) from the
VirtioDevice trait, transport and device implementations.

Thi

vm-virtio, virtio-devices: Split device implementation from virt queues

Split the generic virtio code (queues and device type) from the
VirtioDevice trait, transport and device implementations.

This also simplifies the feature handling in vhost_user_backend as the
vm-virtio crate is no longer has any features.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>

show more ...


# a5596020 02-Jun-2020 Rob Bradford <robert.bradford@intel.com>

vm-virtio: Add some info! level debugging interrupt generation

This was very helpful when debugging interrupt issues and will be useful
for the future.

Signed-off-by: Rob Bradford <robert.bradford@

vm-virtio: Add some info! level debugging interrupt generation

This was very helpful when debugging interrupt issues and will be useful
for the future.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>

show more ...


# a813b57f 20-May-2020 Rob Bradford <robert.bradford@intel.com>

vm-virtio, vhost_user_{fs,block,backend}: Move EVENT_IDX handling

Move the method that is used to decide whether the guest should be
signalled into the Queue implementation from vm-virtio. This remo

vm-virtio, vhost_user_{fs,block,backend}: Move EVENT_IDX handling

Move the method that is used to decide whether the guest should be
signalled into the Queue implementation from vm-virtio. This removes
duplicated code between vhost_user_backend and the vm-virtio block
implementation.

Signed-off-by: Rob Bradford <robert.bradford@intel.com>

show more ...


# 475040b2 07-May-2020 Sebastien Boeuf <sebastien.boeuf@intel.com>

vm-virtio: Correctly reset the virtqueues

Upon a virtio reset, the driver expects that available and used indexes
will be reset to 0. That's why we need to reset these values from the
VMM for any vi

vm-virtio: Correctly reset the virtqueues

Upon a virtio reset, the driver expects that available and used indexes
will be reset to 0. That's why we need to reset these values from the
VMM for any virtio device that might get reset.

This issue was not detected before because the Vec<Queue> maintained
through VirtioPciDevice or MmioDevice was never updated from the virtio
device thread after the device had been actived. For this reason, upon
reset, both available and used indexes were already at the value 0.

The issue arose when trying to reset a device after the VM was restored.
That's because during the restore, each queue is assigned with the right
available and used indexes before it is passed to the device through the
activate function. And that's why upon reset, each queue was still
assigned with these indexes while it should have been reset to 0.

Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>

show more ...


12