External/cloud-hypervisor
1
0
Fork 0
mirror of https://github.com/cloud-hypervisor/cloud-hypervisor.git synced 2024-07-02 16:02:37 +00:00
Code Issues Packages Projects Releases Wiki Activity
b969d92fe3
cloud-hypervisor/Cargo.lock

1646 lines
38 KiB
Plaintext
Raw Normal View History

build: Switch over to using rust-vmm linux-loader crate With everything now merged upstream we no longer need to rely on Cathy's fork. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-06-13 10:07:32 +00:00
# This file is automatically @generated by Cargo.
# It is not intended for manual editing.
acpi_tables: Add initial ACPI tables support Add a revision 2 RSDP table only supporting an XSDT along with support for creating generic SDT based tables. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-08-07 16:53:37 +00:00
[[package]]
name = "acpi_tables"
version = "0.1.0"
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"vm-memory",
acpi_tables: Add initial ACPI tables support Add a revision 2 RSDP table only supporting an XSDT along with support for creating generic SDT based tables. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-08-07 16:53:37 +00:00
]
build(deps): bump backtrace from 0.3.46 to 0.3.47 Bumps [backtrace](https://github.com/rust-lang/backtrace-rs) from 0.3.46 to 0.3.47. - [Release notes](https://github.com/rust-lang/backtrace-rs/releases) - [Commits](https://github.com/rust-lang/backtrace-rs/compare/0.3.46...0.3.47) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-12 17:51:11 +00:00
[[package]]
name = "addr2line"
build(deps): bump addr2line from 0.12.1 to 0.12.2 Bumps [addr2line](https://github.com/gimli-rs/addr2line) from 0.12.1 to 0.12.2. - [Release notes](https://github.com/gimli-rs/addr2line/releases) - [Changelog](https://github.com/gimli-rs/addr2line/blob/master/CHANGELOG.md) - [Commits](https://github.com/gimli-rs/addr2line/compare/0.12.1...0.12.2) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-21 03:45:23 +00:00
version = "0.12.2"
build(deps): bump backtrace from 0.3.46 to 0.3.47 Bumps [backtrace](https://github.com/rust-lang/backtrace-rs) from 0.3.46 to 0.3.47. - [Release notes](https://github.com/rust-lang/backtrace-rs/releases) - [Commits](https://github.com/rust-lang/backtrace-rs/compare/0.3.46...0.3.47) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-12 17:51:11 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump addr2line from 0.12.1 to 0.12.2 Bumps [addr2line](https://github.com/gimli-rs/addr2line) from 0.12.1 to 0.12.2. - [Release notes](https://github.com/gimli-rs/addr2line/releases) - [Changelog](https://github.com/gimli-rs/addr2line/blob/master/CHANGELOG.md) - [Commits](https://github.com/gimli-rs/addr2line/compare/0.12.1...0.12.2) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-21 03:45:23 +00:00
checksum = "602d785912f476e480434627e8732e6766b760c045bbf897d9dfaa9f4fbd399c"
build(deps): bump backtrace from 0.3.46 to 0.3.47 Bumps [backtrace](https://github.com/rust-lang/backtrace-rs) from 0.3.46 to 0.3.47. - [Release notes](https://github.com/rust-lang/backtrace-rs/releases) - [Commits](https://github.com/rust-lang/backtrace-rs/compare/0.3.46...0.3.47) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-12 17:51:11 +00:00
dependencies = [
"gimli",
]
build(deps): bump backtrace from 0.3.48 to 0.3.49 Bumps [backtrace](https://github.com/rust-lang/backtrace-rs) from 0.3.48 to 0.3.49. - [Release notes](https://github.com/rust-lang/backtrace-rs/releases) - [Commits](https://github.com/rust-lang/backtrace-rs/compare/0.3.48...0.3.49) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-15 14:15:23 +00:00
[[package]]
name = "adler32"
build(deps): bump adler32 from 1.0.4 to 1.1.0 Bumps [adler32](https://github.com/remram44/adler32-rs) from 1.0.4 to 1.1.0. - [Release notes](https://github.com/remram44/adler32-rs/releases) - [Commits](https://github.com/remram44/adler32-rs/compare/1.0.4...1.1.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-16 06:13:29 +00:00
version = "1.1.0"
build(deps): bump backtrace from 0.3.48 to 0.3.49 Bumps [backtrace](https://github.com/rust-lang/backtrace-rs) from 0.3.48 to 0.3.49. - [Release notes](https://github.com/rust-lang/backtrace-rs/releases) - [Commits](https://github.com/rust-lang/backtrace-rs/compare/0.3.48...0.3.49) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-15 14:15:23 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump adler32 from 1.0.4 to 1.1.0 Bumps [adler32](https://github.com/remram44/adler32-rs) from 1.0.4 to 1.1.0. - [Release notes](https://github.com/remram44/adler32-rs/releases) - [Commits](https://github.com/remram44/adler32-rs/compare/1.0.4...1.1.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-16 06:13:29 +00:00
checksum = "567b077b825e468cc974f0020d4082ee6e03132512f207ef1a02fd5d00d1f32d"
build(deps): bump backtrace from 0.3.48 to 0.3.49 Bumps [backtrace](https://github.com/rust-lang/backtrace-rs) from 0.3.48 to 0.3.49. - [Release notes](https://github.com/rust-lang/backtrace-rs/releases) - [Commits](https://github.com/rust-lang/backtrace-rs/compare/0.3.48...0.3.49) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-15 14:15:23 +00:00
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
[[package]]
name = "aho-corasick"
build(deps): bump pnet_macros from 0.25.0 to 0.26.0 Bumps [pnet_macros](https://github.com/libpnet/libpnet) from 0.25.0 to 0.26.0. - [Release notes](https://github.com/libpnet/libpnet/releases) - [Commits](https://github.com/libpnet/libpnet/compare/v0.25.0...v0.26.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-01 18:34:05 +00:00
version = "0.7.10"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump pnet_macros from 0.25.0 to 0.26.0 Bumps [pnet_macros](https://github.com/libpnet/libpnet) from 0.25.0 to 0.26.0. - [Release notes](https://github.com/libpnet/libpnet/releases) - [Commits](https://github.com/libpnet/libpnet/compare/v0.25.0...v0.26.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-01 18:34:05 +00:00
checksum = "8716408b8bc624ed7f65d223ddb9ac2d044c0547b6fa4b0d554f3a9540496ada"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"memchr",
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
]
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
[[package]]
name = "ansi_term"
build(deps): bump clap from 2.27.1 to 2.33.0 Bumps [clap](https://github.com/clap-rs/clap) from 2.27.1 to 2.33.0. - [Release notes](https://github.com/clap-rs/clap/releases) - [Changelog](https://github.com/clap-rs/clap/blob/master/CHANGELOG.md) - [Commits](https://github.com/clap-rs/clap/commits) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-02 08:22:53 +00:00
version = "0.11.0"
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "ee49baf6cb617b853aa8d93bf420db2383fab46d314482ca2803b40d5fde979b"
build(deps): bump clap from 2.27.1 to 2.33.0 Bumps [clap](https://github.com/clap-rs/clap) from 2.27.1 to 2.33.0. - [Release notes](https://github.com/clap-rs/clap/releases) - [Changelog](https://github.com/clap-rs/clap/blob/master/CHANGELOG.md) - [Commits](https://github.com/clap-rs/clap/commits) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-02 08:22:53 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"winapi 0.3.8",
build(deps): bump clap from 2.27.1 to 2.33.0 Bumps [clap](https://github.com/clap-rs/clap) from 2.27.1 to 2.33.0. - [Release notes](https://github.com/clap-rs/clap/releases) - [Changelog](https://github.com/clap-rs/clap/blob/master/CHANGELOG.md) - [Commits](https://github.com/clap-rs/clap/commits) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-02 08:22:53 +00:00
]
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
vm-device: Initial Migratable trait The Migratable trait groups all expected capabilities of devices and components that can be migrated. For a component to be migrated, it must be able to pause and resume. Once paused, it should be able to provide a snapshot of itself. It should also be able to restore itself from a snaphot. As a consequence, the Migratable trait will be split between the Pausable and the Snapshotable traits. This commit only adds the Pausable one. All migratable devices will be tracked from the DeviceManager. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-11-18 14:30:54 +00:00
[[package]]
name = "anyhow"
build(deps): bump anyhow from 1.0.30 to 1.0.31 Bumps [anyhow](https://github.com/dtolnay/anyhow) from 1.0.30 to 1.0.31. - [Release notes](https://github.com/dtolnay/anyhow/releases) - [Commits](https://github.com/dtolnay/anyhow/compare/1.0.30...1.0.31) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-15 05:17:39 +00:00
version = "1.0.31"
vm-device: Initial Migratable trait The Migratable trait groups all expected capabilities of devices and components that can be migrated. For a component to be migrated, it must be able to pause and resume. Once paused, it should be able to provide a snapshot of itself. It should also be able to restore itself from a snaphot. As a consequence, the Migratable trait will be split between the Pausable and the Snapshotable traits. This commit only adds the Pausable one. All migratable devices will be tracked from the DeviceManager. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-11-18 14:30:54 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump anyhow from 1.0.30 to 1.0.31 Bumps [anyhow](https://github.com/dtolnay/anyhow) from 1.0.30 to 1.0.31. - [Release notes](https://github.com/dtolnay/anyhow/releases) - [Commits](https://github.com/dtolnay/anyhow/compare/1.0.30...1.0.31) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-15 05:17:39 +00:00
checksum = "85bb70cc08ec97ca5450e6eba421deeea5f172c0fc61f78b5357b2a8e8be195f"
vm-device: Initial Migratable trait The Migratable trait groups all expected capabilities of devices and components that can be migrated. For a component to be migrated, it must be able to pause and resume. Once paused, it should be able to provide a snapshot of itself. It should also be able to restore itself from a snaphot. As a consequence, the Migratable trait will be split between the Pausable and the Snapshotable traits. This commit only adds the Pausable one. All migratable devices will be tracked from the DeviceManager. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-11-18 14:30:54 +00:00
vm-virtio: Implement console size config feature One of the features of the virtio console device is its size can be configured and updated. Our first iteration of the console device implementation is lack of this feature. As a result, it had a default fixed size which could not be changed. This commit implements the console config feature and lets us change the console size from the vmm side. During the activation of the device, vmm reads the current terminal size, sets the console configuration accordinly, and lets the driver know about this configuration by sending an interrupt. Later, if someone changes the terminal size, the vmm detects the corresponding event, updates the configuration, and sends interrupt as before. As a result, the console device driver, in the guest, updates the console size. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-23 19:18:20 +00:00
[[package]]
name = "arc-swap"
build(deps): bump arc-swap from 0.4.6 to 0.4.7 Bumps [arc-swap](https://github.com/vorner/arc-swap) from 0.4.6 to 0.4.7. - [Release notes](https://github.com/vorner/arc-swap/releases) - [Changelog](https://github.com/vorner/arc-swap/blob/master/CHANGELOG.md) - [Commits](https://github.com/vorner/arc-swap/compare/v0.4.6...v0.4.7) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-06 09:13:25 +00:00
version = "0.4.7"
vm-virtio: Implement console size config feature One of the features of the virtio console device is its size can be configured and updated. Our first iteration of the console device implementation is lack of this feature. As a result, it had a default fixed size which could not be changed. This commit implements the console config feature and lets us change the console size from the vmm side. During the activation of the device, vmm reads the current terminal size, sets the console configuration accordinly, and lets the driver know about this configuration by sending an interrupt. Later, if someone changes the terminal size, the vmm detects the corresponding event, updates the configuration, and sends interrupt as before. As a result, the console device driver, in the guest, updates the console size. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-23 19:18:20 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump arc-swap from 0.4.6 to 0.4.7 Bumps [arc-swap](https://github.com/vorner/arc-swap) from 0.4.6 to 0.4.7. - [Release notes](https://github.com/vorner/arc-swap/releases) - [Changelog](https://github.com/vorner/arc-swap/blob/master/CHANGELOG.md) - [Commits](https://github.com/vorner/arc-swap/compare/v0.4.6...v0.4.7) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-06 09:13:25 +00:00
checksum = "4d25d88fd6b8041580a654f9d0c581a047baee2b3efee13275f2fc392fc75034"
vm-virtio: Implement console size config feature One of the features of the virtio console device is its size can be configured and updated. Our first iteration of the console device implementation is lack of this feature. As a result, it had a default fixed size which could not be changed. This commit implements the console config feature and lets us change the console size from the vmm side. During the activation of the device, vmm reads the current terminal size, sets the console configuration accordinly, and lets the driver know about this configuration by sending an interrupt. Later, if someone changes the terminal size, the vmm detects the corresponding event, updates the configuration, and sends interrupt as before. As a result, the console device driver, in the guest, updates the console size. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-23 19:18:20 +00:00
cloud-hypervisor: Initial kernel booting implementation Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-28 13:16:58 +00:00
[[package]]
name = "arch"
version = "0.1.0"
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"acpi_tables",
"arch_gen",
"byteorder",
"kvm-bindings",
"kvm-ioctls",
"libc",
"linux-loader",
"rand 0.7.3",
"vm-memory",
cloud-hypervisor: Initial kernel booting implementation Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-28 13:16:58 +00:00
]
[[package]]
name = "arch_gen"
version = "0.1.0"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
[[package]]
build(deps): bump redox_users from 0.3.0 to 0.3.1 Bumps redox_users from 0.3.0 to 0.3.1. Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-08 06:53:19 +00:00
name = "arrayref"
build(deps): bump arrayref from 0.3.5 to 0.3.6 Bumps [arrayref](https://github.com/droundy/arrayref) from 0.3.5 to 0.3.6. - [Release notes](https://github.com/droundy/arrayref/releases) - [Commits](https://github.com/droundy/arrayref/commits) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-27 08:10:36 +00:00
version = "0.3.6"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "a4c527152e37cf757a3f78aae5a06fbeefdb07ccc535c980a3208ee3060dd544"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
[[package]]
name = "arrayvec"
build(deps): bump blake2b_simd from 0.5.8 to 0.5.9 Bumps [blake2b_simd](https://github.com/oconnor663/blake2_simd) from 0.5.8 to 0.5.9. - [Release notes](https://github.com/oconnor663/blake2_simd/releases) - [Commits](https://github.com/oconnor663/blake2_simd/compare/0.5.8...0.5.9) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-11-07 00:07:00 +00:00
version = "0.5.1"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "cff77d8686867eceff3105329d4698d96c2391c176d5d03adc90c7389162b5b8"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
[[package]]
name = "atty"
build(deps): bump atty from 0.2.13 to 0.2.14 Bumps [atty](https://github.com/softprops/atty) from 0.2.13 to 0.2.14. - [Release notes](https://github.com/softprops/atty/releases) - [Changelog](https://github.com/softprops/atty/blob/master/CHANGELOG.md) - [Commits](https://github.com/softprops/atty/compare/0.2.13...0.2.14) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-05 22:32:54 +00:00
version = "0.2.14"
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "d9b39be18770d11421cdb1b9947a45dd3f37e93092cbf377614828a319d5fee8"
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"hermit-abi",
"libc",
"winapi 0.3.8",
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
]
build(deps): bump openssl-sys from 0.9.53 to 0.9.54 Bumps [openssl-sys](https://github.com/sfackler/rust-openssl) from 0.9.53 to 0.9.54. - [Release notes](https://github.com/sfackler/rust-openssl/releases) - [Commits](https://github.com/sfackler/rust-openssl/compare/openssl-sys-v0.9.53...openssl-sys-v0.9.54) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-30 07:46:26 +00:00
[[package]]
name = "autocfg"
version = "1.0.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "f8aac770f1885fd7e387acedd76065302551364496e46b3dd00860b2f8359b9d"
build(deps): bump openssl-sys from 0.9.53 to 0.9.54 Bumps [openssl-sys](https://github.com/sfackler/rust-openssl) from 0.9.53 to 0.9.54. - [Release notes](https://github.com/sfackler/rust-openssl/releases) - [Commits](https://github.com/sfackler/rust-openssl/compare/openssl-sys-v0.9.53...openssl-sys-v0.9.54) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-30 07:46:26 +00:00
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
[[package]]
name = "backtrace"
build(deps): bump backtrace from 0.3.48 to 0.3.49 Bumps [backtrace](https://github.com/rust-lang/backtrace-rs) from 0.3.48 to 0.3.49. - [Release notes](https://github.com/rust-lang/backtrace-rs/releases) - [Commits](https://github.com/rust-lang/backtrace-rs/compare/0.3.48...0.3.49) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-15 14:15:23 +00:00
version = "0.3.49"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump backtrace from 0.3.48 to 0.3.49 Bumps [backtrace](https://github.com/rust-lang/backtrace-rs) from 0.3.48 to 0.3.49. - [Release notes](https://github.com/rust-lang/backtrace-rs/releases) - [Commits](https://github.com/rust-lang/backtrace-rs/compare/0.3.48...0.3.49) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-15 14:15:23 +00:00
checksum = "05100821de9e028f12ae3d189176b41ee198341eb8f369956407fea2f5cc666c"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
dependencies = [
build(deps): bump backtrace from 0.3.46 to 0.3.47 Bumps [backtrace](https://github.com/rust-lang/backtrace-rs) from 0.3.46 to 0.3.47. - [Release notes](https://github.com/rust-lang/backtrace-rs/releases) - [Commits](https://github.com/rust-lang/backtrace-rs/compare/0.3.46...0.3.47) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-12 17:51:11 +00:00
"addr2line",
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"cfg-if",
"libc",
build(deps): bump backtrace from 0.3.48 to 0.3.49 Bumps [backtrace](https://github.com/rust-lang/backtrace-rs) from 0.3.48 to 0.3.49. - [Release notes](https://github.com/rust-lang/backtrace-rs/releases) - [Commits](https://github.com/rust-lang/backtrace-rs/compare/0.3.48...0.3.49) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-15 14:15:23 +00:00
"miniz_oxide",
build(deps): bump backtrace from 0.3.46 to 0.3.47 Bumps [backtrace](https://github.com/rust-lang/backtrace-rs) from 0.3.46 to 0.3.47. - [Release notes](https://github.com/rust-lang/backtrace-rs/releases) - [Commits](https://github.com/rust-lang/backtrace-rs/compare/0.3.46...0.3.47) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-12 17:51:11 +00:00
"object",
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"rustc-demangle",
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
]
build(deps): bump redox_users from 0.3.0 to 0.3.1 Bumps redox_users from 0.3.0 to 0.3.1. Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-08 06:53:19 +00:00
[[package]]
name = "base64"
build(deps): bump redox_users from 0.3.1 to 0.3.3 Bumps redox_users from 0.3.1 to 0.3.3. Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-20 17:55:49 +00:00
version = "0.11.0"
build(deps): bump redox_users from 0.3.0 to 0.3.1 Bumps redox_users from 0.3.0 to 0.3.1. Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-08 06:53:19 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "b41b7ea54a0c9d92199de89e20e58d49f02f8e699814ef3fdf266f6f748d15c7"
build(deps): bump redox_users from 0.3.0 to 0.3.1 Bumps redox_users from 0.3.0 to 0.3.1. Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-08 06:53:19 +00:00
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
[[package]]
name = "bitflags"
version = "0.5.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "4f67931368edf3a9a51d29886d245f1c3db2f1ef0dcc9e35ff70341b78c10d23"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
cloud-hypervisor: Add devices crate Based on the Firecracker devices crate from commit 9cdb5b2. It is a trimmed down version compared to the Firecracker one, to remove a bunch of pulled dependencies (logger, metrics, rate limiter, etc...). Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-03-07 13:56:43 +00:00
[[package]]
name = "bitflags"
build(deps): bump ssh2 from 0.5.0 to 0.6.0 Bumps [ssh2](https://github.com/alexcrichton/ssh2-rs) from 0.5.0 to 0.6.0. - [Release notes](https://github.com/alexcrichton/ssh2-rs/releases) - [Commits](https://github.com/alexcrichton/ssh2-rs/compare/0.5.0...0.6.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-12-08 18:43:54 +00:00
version = "1.2.1"
cloud-hypervisor: Add devices crate Based on the Firecracker devices crate from commit 9cdb5b2. It is a trimmed down version compared to the Firecracker one, to remove a bunch of pulled dependencies (logger, metrics, rate limiter, etc...). Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-03-07 13:56:43 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "cf1de2fe8c75bc145a2f577add951f8134889b4795d47466a54a5c846d691693"
cloud-hypervisor: Add devices crate Based on the Firecracker devices crate from commit 9cdb5b2. It is a trimmed down version compared to the Firecracker one, to remove a bunch of pulled dependencies (logger, metrics, rate limiter, etc...). Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-03-07 13:56:43 +00:00
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
[[package]]
build(deps): bump redox_users from 0.3.0 to 0.3.1 Bumps redox_users from 0.3.0 to 0.3.1. Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-08 06:53:19 +00:00
name = "blake2b_simd"
build(deps): bump blake2b_simd from 0.5.9 to 0.5.10 Bumps [blake2b_simd](https://github.com/oconnor663/blake2_simd) from 0.5.9 to 0.5.10. - [Release notes](https://github.com/oconnor663/blake2_simd/releases) - [Commits](https://github.com/oconnor663/blake2_simd/compare/0.5.9...0.5.10) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-05 06:10:13 +00:00
version = "0.5.10"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "d8fb2d74254a3a0b5cac33ac9f8ed0e44aa50378d9dbb2e5d83bd21ed1dc2c8a"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"arrayref",
"arrayvec",
"constant_time_eq",
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
]
cloud-hypervisor: Initial kernel booting implementation Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-28 13:16:58 +00:00
[[package]]
name = "byteorder"
build(deps): bump byteorder from 1.3.2 to 1.3.4 Bumps [byteorder](https://github.com/BurntSushi/byteorder) from 1.3.2 to 1.3.4. - [Release notes](https://github.com/BurntSushi/byteorder/releases) - [Changelog](https://github.com/BurntSushi/byteorder/blob/master/CHANGELOG.md) - [Commits](https://github.com/BurntSushi/byteorder/compare/1.3.2...1.3.4) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-02-07 13:44:37 +00:00
version = "1.3.4"
cloud-hypervisor: Initial kernel booting implementation Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-28 13:16:58 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "08c48aae112d48ed9f069b33538ea9e3e90aa263cfa3d1c24309612b1f7472de"
cloud-hypervisor: Initial kernel booting implementation Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-28 13:16:58 +00:00
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
[[package]]
name = "cc"
build(deps): bump cc from 1.0.53 to 1.0.54 Bumps [cc](https://github.com/alexcrichton/cc-rs) from 1.0.53 to 1.0.54. - [Release notes](https://github.com/alexcrichton/cc-rs/releases) - [Commits](https://github.com/alexcrichton/cc-rs/compare/1.0.53...1.0.54) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-19 22:16:53 +00:00
version = "1.0.54"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump cc from 1.0.53 to 1.0.54 Bumps [cc](https://github.com/alexcrichton/cc-rs) from 1.0.53 to 1.0.54. - [Release notes](https://github.com/alexcrichton/cc-rs/releases) - [Commits](https://github.com/alexcrichton/cc-rs/compare/1.0.53...1.0.54) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-19 22:16:53 +00:00
checksum = "7bbb73db36c1246e9034e307d0fba23f9a2e251faa47ade70c1bd252220c8311"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
vmm: Add PCI root Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-04-18 10:26:09 +00:00
[[package]]
name = "cfg-if"
build(deps): bump cfg-if from 0.1.9 to 0.1.10 Bumps [cfg-if](https://github.com/alexcrichton/cfg-if) from 0.1.9 to 0.1.10. - [Release notes](https://github.com/alexcrichton/cfg-if/releases) - [Commits](https://github.com/alexcrichton/cfg-if/compare/0.1.9...0.1.10) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-09-24 19:45:47 +00:00
version = "0.1.10"
vmm: Add PCI root Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-04-18 10:26:09 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "4785bdd1c96b2a846b2bd7cc02e86b6b3dbf14e7e53446c4f54c92a361040822"
vmm: Add PCI root Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-04-18 10:26:09 +00:00
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
[[package]]
name = "clap"
build(deps): bump clap from 2.33.0 to 2.33.1 Bumps [clap](https://github.com/clap-rs/clap) from 2.33.0 to 2.33.1. - [Release notes](https://github.com/clap-rs/clap/releases) - [Changelog](https://github.com/clap-rs/clap/blob/v2.33.1/CHANGELOG.md) - [Commits](https://github.com/clap-rs/clap/compare/v2.33.0...v2.33.1) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-11 17:49:21 +00:00
version = "2.33.1"
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump clap from 2.33.0 to 2.33.1 Bumps [clap](https://github.com/clap-rs/clap) from 2.33.0 to 2.33.1. - [Release notes](https://github.com/clap-rs/clap/releases) - [Changelog](https://github.com/clap-rs/clap/blob/v2.33.1/CHANGELOG.md) - [Commits](https://github.com/clap-rs/clap/compare/v2.33.0...v2.33.1) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-11 17:49:21 +00:00
checksum = "bdfa80d47f954d53a35a64987ca1422f495b8d6483c0fe9f7117b36c2a792129"
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"ansi_term",
"atty",
"bitflags 1.2.1",
"strsim",
"term_size",
"textwrap",
"unicode-width",
"vec_map",
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
]
cloud-hypervisor: Initial commit Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:04:44 +00:00
[[package]]
name = "cloud-hypervisor"
build, release-notes: Document 0.8.0 release Update the build version and the release notes for the 0.8.0 release. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2020-06-11 13:57:47 +00:00
version = "0.8.0"
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"arc-swap",
"clap",
"credibility",
"dirs",
"epoll",
"futures",
"lazy_static",
"libc",
"log 0.4.8",
tests: Add tests checking for host MAC address setting Extend the set of tests we have for virtio-net and vhost-user-net to check for host MAC address setting. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2020-05-15 09:19:51 +00:00
"net_util",
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"seccomp",
"serde_json",
"ssh2",
"tempdir",
"tempfile",
"vhost",
"vhost_user_backend",
"vhost_user_block",
"vhost_user_fs",
"vhost_user_net",
build: Use same virtio-bindings version Consistently use the crates.io 0.1.0 version based on Linux 5.0.0 Fixes: #1192 Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2020-05-20 10:13:06 +00:00
"virtio-bindings",
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"vm-device",
"vm-memory",
"vm-virtio",
"vmm",
"vmm-sys-util",
cloud-hypervisor: Call into the test_vm() routine test_vm is a dummy VM workload, we use it to test our initial VMM settings. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-22 16:05:02 +00:00
]
build(deps): bump ssh2 from 0.6.0 to 0.7.1 Bumps [ssh2](https://github.com/alexcrichton/ssh2-rs) from 0.6.0 to 0.7.1. - [Release notes](https://github.com/alexcrichton/ssh2-rs/releases) - [Commits](https://github.com/alexcrichton/ssh2-rs/compare/0.6.0...0.7.1) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-25 22:43:45 +00:00
[[package]]
name = "cloudabi"
version = "0.0.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "ddfc5b9aa5d4507acaf872de71051dfd0e309860e88966e1051e462a077aac4f"
build(deps): bump ssh2 from 0.6.0 to 0.7.1 Bumps [ssh2](https://github.com/alexcrichton/ssh2-rs) from 0.6.0 to 0.7.1. - [Release notes](https://github.com/alexcrichton/ssh2-rs/releases) - [Commits](https://github.com/alexcrichton/ssh2-rs/compare/0.6.0...0.7.1) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-25 22:43:45 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"bitflags 1.2.1",
build(deps): bump ssh2 from 0.6.0 to 0.7.1 Bumps [ssh2](https://github.com/alexcrichton/ssh2-rs) from 0.6.0 to 0.7.1. - [Release notes](https://github.com/alexcrichton/ssh2-rs/releases) - [Commits](https://github.com/alexcrichton/ssh2-rs/compare/0.6.0...0.7.1) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-25 22:43:45 +00:00
]
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
[[package]]
name = "constant_time_eq"
build(deps): bump constant_time_eq from 0.1.4 to 0.1.5 Bumps [constant_time_eq](https://github.com/cesarb/constant_time_eq) from 0.1.4 to 0.1.5. - [Release notes](https://github.com/cesarb/constant_time_eq/releases) - [Commits](https://github.com/cesarb/constant_time_eq/compare/0.1.4...0.1.5) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-11 22:05:14 +00:00
version = "0.1.5"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "245097e9a4535ee1e3e3931fcfcd55a796a44c643e8596ff6566d68f09b87bbc"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
tests: Switch to launching by command Launch the test binary by command rather than using using the vmm layer. This makes it easier to manage the running VM as you can explicitly kill it. Also switch to using credibility for the tests which catches assertions and continues with subsequent commands and reports the issues at the end. This means it is possible to cleanup even on failed test runs. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-06-04 15:24:39 +00:00
[[package]]
name = "credibility"
version = "0.1.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "fae7a162fd5b462bc49704873a89950a655d44161add4be07e00e64c4c83a5bf"
tests: Switch to launching by command Launch the test binary by command rather than using using the vmm layer. This makes it easier to manage the running VM as you can explicitly kill it. Also switch to using credibility for the tests which catches assertions and continues with subsequent commands and reports the issues at the end. This means it is possible to cleanup even on failed test runs. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-06-04 15:24:39 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"failure",
"failure_derive",
tests: Switch to launching by command Launch the test binary by command rather than using using the vmm layer. This makes it easier to manage the running VM as you can explicitly kill it. Also switch to using credibility for the tests which catches assertions and continues with subsequent commands and reports the issues at the end. This means it is possible to cleanup even on failed test runs. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-06-04 15:24:39 +00:00
]
build(deps): bump redox_users from 0.3.0 to 0.3.1 Bumps redox_users from 0.3.0 to 0.3.1. Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-08 06:53:19 +00:00
[[package]]
name = "crossbeam-utils"
build(deps): bump crossbeam-utils from 0.7.0 to 0.7.2 Bumps [crossbeam-utils](https://github.com/crossbeam-rs/crossbeam) from 0.7.0 to 0.7.2. - [Release notes](https://github.com/crossbeam-rs/crossbeam/releases) - [Changelog](https://github.com/crossbeam-rs/crossbeam/blob/master/CHANGELOG.md) - [Commits](https://github.com/crossbeam-rs/crossbeam/compare/crossbeam-utils-0.7.0...crossbeam-0.7.2) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-02-22 15:14:42 +00:00
version = "0.7.2"
build(deps): bump redox_users from 0.3.0 to 0.3.1 Bumps redox_users from 0.3.0 to 0.3.1. Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-08 06:53:19 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "c3c7c73a2d1e9fc0886a08b93e98eb643461230d5f1925e4036204d5f2e261a8"
build(deps): bump redox_users from 0.3.0 to 0.3.1 Bumps redox_users from 0.3.0 to 0.3.1. Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-08 06:53:19 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"autocfg",
"cfg-if",
"lazy_static",
build(deps): bump redox_users from 0.3.0 to 0.3.1 Bumps redox_users from 0.3.0 to 0.3.1. Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-08 06:53:19 +00:00
]
cloud-hypervisor: Add devices crate Based on the Firecracker devices crate from commit 9cdb5b2. It is a trimmed down version compared to the Firecracker one, to remove a bunch of pulled dependencies (logger, metrics, rate limiter, etc...). Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-03-07 13:56:43 +00:00
[[package]]
name = "devices"
version = "0.1.0"
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"acpi_tables",
devices: ioapic: Implement the Snapshottable trait Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-12-12 01:36:13 +00:00
"anyhow",
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"bitflags 1.2.1",
"byteorder",
"epoll",
"libc",
"log 0.4.8",
devices: ioapic: Implement the Snapshottable trait Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-12-12 01:36:13 +00:00
"serde",
"serde_derive",
"serde_json",
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"tempfile",
"vm-device",
"vm-memory",
devices: ioapic: Implement the Snapshottable trait Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-12-12 01:36:13 +00:00
"vm-migration",
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"vmm-sys-util",
cloud-hypervisor: Add devices crate Based on the Firecracker devices crate from commit 9cdb5b2. It is a trimmed down version compared to the Firecracker one, to remove a bunch of pulled dependencies (logger, metrics, rate limiter, etc...). Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-03-07 13:56:43 +00:00
]
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
[[package]]
name = "dirs"
build(deps): bump dirs from 2.0.1 to 2.0.2 Bumps [dirs](https://github.com/soc/dirs-rs) from 2.0.1 to 2.0.2. - [Release notes](https://github.com/soc/dirs-rs/releases) - [Commits](https://github.com/soc/dirs-rs/commits) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-02 07:51:51 +00:00
version = "2.0.2"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "13aea89a5c93364a98e9b37b2fa237effbb694d5cfe01c5b70941f7eb087d5e3"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"cfg-if",
"dirs-sys",
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
]
[[package]]
name = "dirs-sys"
build(deps): bump dirs-sys from 0.3.4 to 0.3.5 Bumps [dirs-sys](https://github.com/dirs-dev/dirs-sys-rs) from 0.3.4 to 0.3.5. - [Release notes](https://github.com/dirs-dev/dirs-sys-rs/releases) - [Commits](https://github.com/dirs-dev/dirs-sys-rs/commits) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-05 17:15:11 +00:00
version = "0.3.5"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump dirs-sys from 0.3.4 to 0.3.5 Bumps [dirs-sys](https://github.com/dirs-dev/dirs-sys-rs) from 0.3.4 to 0.3.5. - [Release notes](https://github.com/dirs-dev/dirs-sys-rs/releases) - [Commits](https://github.com/dirs-dev/dirs-sys-rs/commits) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-05 17:15:11 +00:00
checksum = "8e93d7f5705de3e49895a2b5e0b8855a1c27f080192ae9c32a6432d50741a57a"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"libc",
"redox_users",
"winapi 0.3.8",
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
]
cloud-hypervisor: Add devices crate Based on the Firecracker devices crate from commit 9cdb5b2. It is a trimmed down version compared to the Firecracker one, to remove a bunch of pulled dependencies (logger, metrics, rate limiter, etc...). Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-03-07 13:56:43 +00:00
[[package]]
name = "epoll"
build(deps): bump epoll from 4.1.0 to 4.2.0 Bumps [epoll](https://github.com/nathansizemore/epoll) from 4.1.0 to 4.2.0. - [Release notes](https://github.com/nathansizemore/epoll/releases) - [Commits](https://github.com/nathansizemore/epoll/commits) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-19 02:07:06 +00:00
version = "4.2.0"
cloud-hypervisor: Add devices crate Based on the Firecracker devices crate from commit 9cdb5b2. It is a trimmed down version compared to the Firecracker one, to remove a bunch of pulled dependencies (logger, metrics, rate limiter, etc...). Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-03-07 13:56:43 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump epoll from 4.1.0 to 4.2.0 Bumps [epoll](https://github.com/nathansizemore/epoll) from 4.1.0 to 4.2.0. - [Release notes](https://github.com/nathansizemore/epoll/releases) - [Commits](https://github.com/nathansizemore/epoll/commits) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-19 02:07:06 +00:00
checksum = "7e5b0ba026ff8d9b1e5d58acc8d6a9a7bbd0185020bbad25cfa835d173ac0860"
cloud-hypervisor: Add devices crate Based on the Firecracker devices crate from commit 9cdb5b2. It is a trimmed down version compared to the Firecracker one, to remove a bunch of pulled dependencies (logger, metrics, rate limiter, etc...). Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-03-07 13:56:43 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"bitflags 1.2.1",
"libc",
cloud-hypervisor: Add devices crate Based on the Firecracker devices crate from commit 9cdb5b2. It is a trimmed down version compared to the Firecracker one, to remove a bunch of pulled dependencies (logger, metrics, rate limiter, etc...). Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-03-07 13:56:43 +00:00
]
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
[[package]]
name = "failure"
build(deps): bump failure from 0.1.7 to 0.1.8 Bumps [failure](https://github.com/rust-lang-nursery/failure) from 0.1.7 to 0.1.8. - [Release notes](https://github.com/rust-lang-nursery/failure/releases) - [Changelog](https://github.com/rust-lang-nursery/failure/blob/master/RELEASES.md) - [Commits](https://github.com/rust-lang-nursery/failure/commits) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-04 07:02:38 +00:00
version = "0.1.8"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump failure from 0.1.7 to 0.1.8 Bumps [failure](https://github.com/rust-lang-nursery/failure) from 0.1.7 to 0.1.8. - [Release notes](https://github.com/rust-lang-nursery/failure/releases) - [Changelog](https://github.com/rust-lang-nursery/failure/blob/master/RELEASES.md) - [Commits](https://github.com/rust-lang-nursery/failure/commits) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-04 07:02:38 +00:00
checksum = "d32e9bd16cc02eae7db7ef620b392808b89f6a5e16bb3497d159c6b92a0f4f86"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"backtrace",
"failure_derive",
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
]
[[package]]
name = "failure_derive"
build(deps): bump failure_derive from 0.1.7 to 0.1.8 Bumps [failure_derive](https://github.com/rust-lang-nursery/failure) from 0.1.7 to 0.1.8. - [Release notes](https://github.com/rust-lang-nursery/failure/releases) - [Changelog](https://github.com/rust-lang-nursery/failure/blob/master/RELEASES.md) - [Commits](https://github.com/rust-lang-nursery/failure/commits) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-02 18:24:57 +00:00
version = "0.1.8"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump failure_derive from 0.1.7 to 0.1.8 Bumps [failure_derive](https://github.com/rust-lang-nursery/failure) from 0.1.7 to 0.1.8. - [Release notes](https://github.com/rust-lang-nursery/failure/releases) - [Changelog](https://github.com/rust-lang-nursery/failure/blob/master/RELEASES.md) - [Commits](https://github.com/rust-lang-nursery/failure/commits) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-02 18:24:57 +00:00
checksum = "aa4da3c766cd7a0db8242e326e9e4e081edd567072893ed320008189715366a4"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"proc-macro2",
"quote",
"syn",
"synstructure",
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
]
vmm: Use virtio-blk to support booting from disk image After the virtio-blk device support has been introduced in the previous commit, the vmm need to rely on this new device to boot from disk images instead of initrd built into the kernel. In order to achieve the proper support of virtio-blk, this commit had to handle a few things: - Register an ioevent fd for each virtqueue. This important to be notified from the virtio driver that something has been written on the queue. - Fix the retrieval of 64bits BAR address. This is needed to provide the right address which need to be registered as the notification address from the virtio driver. - Fix the write_bar and read_bar functions. They were both assuming to be provided with an address, from which they were trying to find the associated offset. But the reality is that the offset is directly provided by the Bus layer. - Register a new virtio-blk device as a virtio-pci device from the vm.rs code. When the VM is started, it expects a block device to be created, using this block device as the VM rootfs. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-05-06 17:27:40 +00:00
[[package]]
name = "fuchsia-cprng"
version = "0.1.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "a06f77d526c1a601b7c4cdd98f54b5eaabffc14d5f2f0296febdc7f357c6d3ba"
vmm: Use virtio-blk to support booting from disk image After the virtio-blk device support has been introduced in the previous commit, the vmm need to rely on this new device to boot from disk images instead of initrd built into the kernel. In order to achieve the proper support of virtio-blk, this commit had to handle a few things: - Register an ioevent fd for each virtqueue. This important to be notified from the virtio driver that something has been written on the queue. - Fix the retrieval of 64bits BAR address. This is needed to provide the right address which need to be registered as the notification address from the virtio driver. - Fix the write_bar and read_bar functions. They were both assuming to be provided with an address, from which they were trying to find the associated offset. But the reality is that the offset is directly provided by the Bus layer. - Register a new virtio-blk device as a virtio-pci device from the vm.rs code. When the VM is started, it expects a block device to be created, using this block device as the VM rootfs. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-05-06 17:27:40 +00:00
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
[[package]]
name = "futures"
build(deps): bump futures from 0.3.4 to 0.3.5 Bumps [futures](https://github.com/rust-lang/futures-rs) from 0.3.4 to 0.3.5. - [Release notes](https://github.com/rust-lang/futures-rs/releases) - [Changelog](https://github.com/rust-lang/futures-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/futures-rs/compare/0.3.4...0.3.5) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-08 23:34:07 +00:00
version = "0.3.5"
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump futures from 0.3.4 to 0.3.5 Bumps [futures](https://github.com/rust-lang/futures-rs) from 0.3.4 to 0.3.5. - [Release notes](https://github.com/rust-lang/futures-rs/releases) - [Changelog](https://github.com/rust-lang/futures-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/futures-rs/compare/0.3.4...0.3.5) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-08 23:34:07 +00:00
checksum = "1e05b85ec287aac0dc34db7d4a569323df697f9c55b99b15d6b4ef8cde49f613"
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"futures-channel",
"futures-core",
"futures-executor",
"futures-io",
"futures-sink",
"futures-task",
"futures-util",
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
]
[[package]]
name = "futures-channel"
build(deps): bump futures from 0.3.4 to 0.3.5 Bumps [futures](https://github.com/rust-lang/futures-rs) from 0.3.4 to 0.3.5. - [Release notes](https://github.com/rust-lang/futures-rs/releases) - [Changelog](https://github.com/rust-lang/futures-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/futures-rs/compare/0.3.4...0.3.5) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-08 23:34:07 +00:00
version = "0.3.5"
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump futures from 0.3.4 to 0.3.5 Bumps [futures](https://github.com/rust-lang/futures-rs) from 0.3.4 to 0.3.5. - [Release notes](https://github.com/rust-lang/futures-rs/releases) - [Changelog](https://github.com/rust-lang/futures-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/futures-rs/compare/0.3.4...0.3.5) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-08 23:34:07 +00:00
checksum = "f366ad74c28cca6ba456d95e6422883cfb4b252a83bed929c83abfdbbf2967d5"
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"futures-core",
"futures-sink",
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
]
[[package]]
name = "futures-core"
build(deps): bump futures from 0.3.4 to 0.3.5 Bumps [futures](https://github.com/rust-lang/futures-rs) from 0.3.4 to 0.3.5. - [Release notes](https://github.com/rust-lang/futures-rs/releases) - [Changelog](https://github.com/rust-lang/futures-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/futures-rs/compare/0.3.4...0.3.5) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-08 23:34:07 +00:00
version = "0.3.5"
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump futures from 0.3.4 to 0.3.5 Bumps [futures](https://github.com/rust-lang/futures-rs) from 0.3.4 to 0.3.5. - [Release notes](https://github.com/rust-lang/futures-rs/releases) - [Changelog](https://github.com/rust-lang/futures-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/futures-rs/compare/0.3.4...0.3.5) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-08 23:34:07 +00:00
checksum = "59f5fff90fd5d971f936ad674802482ba441b6f09ba5e15fd8b39145582ca399"
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
[[package]]
name = "futures-executor"
build(deps): bump futures from 0.3.4 to 0.3.5 Bumps [futures](https://github.com/rust-lang/futures-rs) from 0.3.4 to 0.3.5. - [Release notes](https://github.com/rust-lang/futures-rs/releases) - [Changelog](https://github.com/rust-lang/futures-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/futures-rs/compare/0.3.4...0.3.5) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-08 23:34:07 +00:00
version = "0.3.5"
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump futures from 0.3.4 to 0.3.5 Bumps [futures](https://github.com/rust-lang/futures-rs) from 0.3.4 to 0.3.5. - [Release notes](https://github.com/rust-lang/futures-rs/releases) - [Changelog](https://github.com/rust-lang/futures-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/futures-rs/compare/0.3.4...0.3.5) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-08 23:34:07 +00:00
checksum = "10d6bb888be1153d3abeb9006b11b02cf5e9b209fda28693c31ae1e4e012e314"
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"futures-core",
"futures-task",
"futures-util",
"num_cpus",
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
]
[[package]]
name = "futures-io"
build(deps): bump futures from 0.3.4 to 0.3.5 Bumps [futures](https://github.com/rust-lang/futures-rs) from 0.3.4 to 0.3.5. - [Release notes](https://github.com/rust-lang/futures-rs/releases) - [Changelog](https://github.com/rust-lang/futures-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/futures-rs/compare/0.3.4...0.3.5) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-08 23:34:07 +00:00
version = "0.3.5"
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump futures from 0.3.4 to 0.3.5 Bumps [futures](https://github.com/rust-lang/futures-rs) from 0.3.4 to 0.3.5. - [Release notes](https://github.com/rust-lang/futures-rs/releases) - [Changelog](https://github.com/rust-lang/futures-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/futures-rs/compare/0.3.4...0.3.5) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-08 23:34:07 +00:00
checksum = "de27142b013a8e869c14957e6d2edeef89e97c289e69d042ee3a49acd8b51789"
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
[[package]]
name = "futures-macro"
build(deps): bump futures from 0.3.4 to 0.3.5 Bumps [futures](https://github.com/rust-lang/futures-rs) from 0.3.4 to 0.3.5. - [Release notes](https://github.com/rust-lang/futures-rs/releases) - [Changelog](https://github.com/rust-lang/futures-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/futures-rs/compare/0.3.4...0.3.5) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-08 23:34:07 +00:00
version = "0.3.5"
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump futures from 0.3.4 to 0.3.5 Bumps [futures](https://github.com/rust-lang/futures-rs) from 0.3.4 to 0.3.5. - [Release notes](https://github.com/rust-lang/futures-rs/releases) - [Changelog](https://github.com/rust-lang/futures-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/futures-rs/compare/0.3.4...0.3.5) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-08 23:34:07 +00:00
checksum = "d0b5a30a4328ab5473878237c447333c093297bded83a4983d10f4deea240d39"
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"proc-macro-hack",
"proc-macro2",
"quote",
"syn",
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
]
[[package]]
name = "futures-sink"
build(deps): bump futures from 0.3.4 to 0.3.5 Bumps [futures](https://github.com/rust-lang/futures-rs) from 0.3.4 to 0.3.5. - [Release notes](https://github.com/rust-lang/futures-rs/releases) - [Changelog](https://github.com/rust-lang/futures-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/futures-rs/compare/0.3.4...0.3.5) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-08 23:34:07 +00:00
version = "0.3.5"
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump futures from 0.3.4 to 0.3.5 Bumps [futures](https://github.com/rust-lang/futures-rs) from 0.3.4 to 0.3.5. - [Release notes](https://github.com/rust-lang/futures-rs/releases) - [Changelog](https://github.com/rust-lang/futures-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/futures-rs/compare/0.3.4...0.3.5) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-08 23:34:07 +00:00
checksum = "3f2032893cb734c7a05d85ce0cc8b8c4075278e93b24b66f9de99d6eb0fa8acc"
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
[[package]]
name = "futures-task"
build(deps): bump futures from 0.3.4 to 0.3.5 Bumps [futures](https://github.com/rust-lang/futures-rs) from 0.3.4 to 0.3.5. - [Release notes](https://github.com/rust-lang/futures-rs/releases) - [Changelog](https://github.com/rust-lang/futures-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/futures-rs/compare/0.3.4...0.3.5) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-08 23:34:07 +00:00
version = "0.3.5"
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump futures from 0.3.4 to 0.3.5 Bumps [futures](https://github.com/rust-lang/futures-rs) from 0.3.4 to 0.3.5. - [Release notes](https://github.com/rust-lang/futures-rs/releases) - [Changelog](https://github.com/rust-lang/futures-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/futures-rs/compare/0.3.4...0.3.5) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-08 23:34:07 +00:00
checksum = "bdb66b5f09e22019b1ab0830f7785bcea8e7a42148683f99214f73f8ec21a626"
dependencies = [
"once_cell",
]
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
[[package]]
name = "futures-util"
build(deps): bump futures from 0.3.4 to 0.3.5 Bumps [futures](https://github.com/rust-lang/futures-rs) from 0.3.4 to 0.3.5. - [Release notes](https://github.com/rust-lang/futures-rs/releases) - [Changelog](https://github.com/rust-lang/futures-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/futures-rs/compare/0.3.4...0.3.5) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-08 23:34:07 +00:00
version = "0.3.5"
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump futures from 0.3.4 to 0.3.5 Bumps [futures](https://github.com/rust-lang/futures-rs) from 0.3.4 to 0.3.5. - [Release notes](https://github.com/rust-lang/futures-rs/releases) - [Changelog](https://github.com/rust-lang/futures-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/futures-rs/compare/0.3.4...0.3.5) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-08 23:34:07 +00:00
checksum = "8764574ff08b701a084482c3c7031349104b07ac897393010494beaa18ce32c6"
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"futures-channel",
"futures-core",
"futures-io",
"futures-macro",
"futures-sink",
"futures-task",
"memchr",
build(deps): bump futures from 0.3.4 to 0.3.5 Bumps [futures](https://github.com/rust-lang/futures-rs) from 0.3.4 to 0.3.5. - [Release notes](https://github.com/rust-lang/futures-rs/releases) - [Changelog](https://github.com/rust-lang/futures-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/futures-rs/compare/0.3.4...0.3.5) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-08 23:34:07 +00:00
"pin-project",
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"pin-utils",
"proc-macro-hack",
"proc-macro-nested",
"slab",
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
]
vm-virtio: Add virtio console device for single port operation The virtio console device is a console for the communication between the host and guest userspace. It has two parts: the device and the driver. The console device is implemented here as a virtio-pci device to the guest. On the other side, the guest OS expected to have a character device driver which provides an interface to the userspace applications. The console device can have multiple ports where each port has one transmit queue and one receive queue. The current implementation only supports one port. For data IO communication, one or more empty buffers are placed in the receive queue for incoming data, and outgoing characters are placed in the transmit queue. Details spec can be found from the following link. https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.pdf#e7 Apart from the console, for the communication between guest and host, the Cloud Hypervisor has a legacy serial device implemented. However, the implementation of a console device lets us be independent of legacy pin-based interrupts without losing the logs and access to the VM. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-22 18:50:56 +00:00
[[package]]
name = "getrandom"
build(deps): bump getrandom from 0.1.13 to 0.1.14 Bumps [getrandom](https://github.com/rust-random/getrandom) from 0.1.13 to 0.1.14. - [Release notes](https://github.com/rust-random/getrandom/releases) - [Changelog](https://github.com/rust-random/getrandom/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-random/getrandom/compare/v0.1.13...v0.1.14) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-07 12:14:20 +00:00
version = "0.1.14"
vm-virtio: Add virtio console device for single port operation The virtio console device is a console for the communication between the host and guest userspace. It has two parts: the device and the driver. The console device is implemented here as a virtio-pci device to the guest. On the other side, the guest OS expected to have a character device driver which provides an interface to the userspace applications. The console device can have multiple ports where each port has one transmit queue and one receive queue. The current implementation only supports one port. For data IO communication, one or more empty buffers are placed in the receive queue for incoming data, and outgoing characters are placed in the transmit queue. Details spec can be found from the following link. https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.pdf#e7 Apart from the console, for the communication between guest and host, the Cloud Hypervisor has a legacy serial device implemented. However, the implementation of a console device lets us be independent of legacy pin-based interrupts without losing the logs and access to the VM. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-22 18:50:56 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "7abc8dd8451921606d809ba32e95b6111925cd2906060d2dcc29c070220503eb"
vm-virtio: Add virtio console device for single port operation The virtio console device is a console for the communication between the host and guest userspace. It has two parts: the device and the driver. The console device is implemented here as a virtio-pci device to the guest. On the other side, the guest OS expected to have a character device driver which provides an interface to the userspace applications. The console device can have multiple ports where each port has one transmit queue and one receive queue. The current implementation only supports one port. For data IO communication, one or more empty buffers are placed in the receive queue for incoming data, and outgoing characters are placed in the transmit queue. Details spec can be found from the following link. https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.pdf#e7 Apart from the console, for the communication between guest and host, the Cloud Hypervisor has a legacy serial device implemented. However, the implementation of a console device lets us be independent of legacy pin-based interrupts without losing the logs and access to the VM. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-22 18:50:56 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"cfg-if",
"libc",
"wasi",
vm-virtio: Add virtio console device for single port operation The virtio console device is a console for the communication between the host and guest userspace. It has two parts: the device and the driver. The console device is implemented here as a virtio-pci device to the guest. On the other side, the guest OS expected to have a character device driver which provides an interface to the userspace applications. The console device can have multiple ports where each port has one transmit queue and one receive queue. The current implementation only supports one port. For data IO communication, one or more empty buffers are placed in the receive queue for incoming data, and outgoing characters are placed in the transmit queue. Details spec can be found from the following link. https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.pdf#e7 Apart from the console, for the communication between guest and host, the Cloud Hypervisor has a legacy serial device implemented. However, the implementation of a console device lets us be independent of legacy pin-based interrupts without losing the logs and access to the VM. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-22 18:50:56 +00:00
]
build(deps): bump backtrace from 0.3.46 to 0.3.47 Bumps [backtrace](https://github.com/rust-lang/backtrace-rs) from 0.3.46 to 0.3.47. - [Release notes](https://github.com/rust-lang/backtrace-rs/releases) - [Commits](https://github.com/rust-lang/backtrace-rs/compare/0.3.46...0.3.47) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-12 17:51:11 +00:00
[[package]]
name = "gimli"
version = "0.21.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "bcc8e0c9bce37868955864dbecd2b1ab2bdf967e6f28066d65aaac620444b65c"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
[[package]]
name = "glob"
version = "0.2.11"
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "8be18de09a56b60ed0edf84bc9df007e30040691af7acd1c41874faac5895bfb"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
build(deps): bump atty from 0.2.13 to 0.2.14 Bumps [atty](https://github.com/softprops/atty) from 0.2.13 to 0.2.14. - [Release notes](https://github.com/softprops/atty/releases) - [Changelog](https://github.com/softprops/atty/blob/master/CHANGELOG.md) - [Commits](https://github.com/softprops/atty/compare/0.2.13...0.2.14) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-05 22:32:54 +00:00
[[package]]
name = "hermit-abi"
build(deps): bump hermit-abi from 0.1.13 to 0.1.14 Bumps [hermit-abi](https://github.com/hermitcore/libhermit-rs) from 0.1.13 to 0.1.14. - [Release notes](https://github.com/hermitcore/libhermit-rs/releases) - [Commits](https://github.com/hermitcore/libhermit-rs/commits) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-13 21:03:09 +00:00
version = "0.1.14"
build(deps): bump atty from 0.2.13 to 0.2.14 Bumps [atty](https://github.com/softprops/atty) from 0.2.13 to 0.2.14. - [Release notes](https://github.com/softprops/atty/releases) - [Changelog](https://github.com/softprops/atty/blob/master/CHANGELOG.md) - [Commits](https://github.com/softprops/atty/compare/0.2.13...0.2.14) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-05 22:32:54 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump hermit-abi from 0.1.13 to 0.1.14 Bumps [hermit-abi](https://github.com/hermitcore/libhermit-rs) from 0.1.13 to 0.1.14. - [Release notes](https://github.com/hermitcore/libhermit-rs/releases) - [Commits](https://github.com/hermitcore/libhermit-rs/commits) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-13 21:03:09 +00:00
checksum = "b9586eedd4ce6b3c498bc3b4dd92fc9f11166aa908a914071953768066c67909"
build(deps): bump atty from 0.2.13 to 0.2.14 Bumps [atty](https://github.com/softprops/atty) from 0.2.13 to 0.2.14. - [Release notes](https://github.com/softprops/atty/releases) - [Changelog](https://github.com/softprops/atty/blob/master/CHANGELOG.md) - [Commits](https://github.com/softprops/atty/compare/0.2.13...0.2.14) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-05 22:32:54 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"libc",
build(deps): bump atty from 0.2.13 to 0.2.14 Bumps [atty](https://github.com/softprops/atty) from 0.2.13 to 0.2.14. - [Release notes](https://github.com/softprops/atty/releases) - [Changelog](https://github.com/softprops/atty/blob/master/CHANGELOG.md) - [Commits](https://github.com/softprops/atty/compare/0.2.13...0.2.14) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-05 22:32:54 +00:00
]
vmm: memory_manager: Implement the Transportable trait This implements the send() function of the Transportable trait, so that the guest memory regions can be saved into one file per region. This will need to be extended for live migration, as it will require other transport methods and the recv() function will need to be implemented too. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2020-02-25 01:38:08 +00:00
[[package]]
name = "idna"
version = "0.2.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "02e2673c30ee86b5b96a9cb52ad15718aa1f966f5ab9ad54a8b95d5ca33120a9"
dependencies = [
"matches",
"unicode-bidi",
"unicode-normalization",
]
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
[[package]]
name = "ipnetwork"
build(deps): bump pnet from 0.25.0 to 0.26.0 Bumps [pnet](https://github.com/libpnet/libpnet) from 0.25.0 to 0.26.0. - [Release notes](https://github.com/libpnet/libpnet/releases) - [Commits](https://github.com/libpnet/libpnet/compare/v0.25.0...v0.26.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-04 07:04:05 +00:00
version = "0.16.0"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump pnet from 0.25.0 to 0.26.0 Bumps [pnet](https://github.com/libpnet/libpnet) from 0.25.0 to 0.26.0. - [Release notes](https://github.com/libpnet/libpnet/releases) - [Commits](https://github.com/libpnet/libpnet/compare/v0.25.0...v0.26.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-04 07:04:05 +00:00
checksum = "b8eca9f51da27bc908ef3dd85c21e1bbba794edaf94d7841e37356275b82d31e"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"serde",
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
]
[[package]]
name = "itoa"
build(deps): bump itoa from 0.4.5 to 0.4.6 Bumps [itoa](https://github.com/dtolnay/itoa) from 0.4.5 to 0.4.6. - [Release notes](https://github.com/dtolnay/itoa/releases) - [Commits](https://github.com/dtolnay/itoa/compare/0.4.5...0.4.6) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-16 18:40:11 +00:00
version = "0.4.6"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump itoa from 0.4.5 to 0.4.6 Bumps [itoa](https://github.com/dtolnay/itoa) from 0.4.5 to 0.4.6. - [Release notes](https://github.com/dtolnay/itoa/releases) - [Commits](https://github.com/dtolnay/itoa/compare/0.4.5...0.4.6) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-16 18:40:11 +00:00
checksum = "dc6f3ad7b9d11a0c00842ff8de1b60ee58661048eb8049ed33c73594f359d7e6"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
[[package]]
name = "kernel32-sys"
version = "0.2.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "7507624b29483431c0ba2d82aece8ca6cdba9382bff4ddd0f7490560c056098d"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"winapi 0.2.8",
"winapi-build",
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
]
cloud-hypervisor: Call into the test_vm() routine test_vm is a dummy VM workload, we use it to test our initial VMM settings. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-22 16:05:02 +00:00
[[package]]
name = "kvm-bindings"
cargo: Bump the kvm and vmm-sys-util crates Since the kvm crates now depend on vmm-sys-util, the bump must be atomic. The kvm-bindings and ioctls 0.2.0 and 0.4.0 crates come with a few API changes, one of them being the use of a kvm_ioctls specific error type. Porting our code to that type makes for a fairly large diff stat. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-11-29 15:36:33 +00:00
version = "0.2.0"
Cargo: Update dependencies for the KVM serialization work We need the project to rely on kvm-bindings and kvm-ioctls branches which include the serde derive to be able to serialize and deserialize some KVM structures. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2020-02-17 14:28:24 +00:00
source = "git+https://github.com/cloud-hypervisor/kvm-bindings?branch=ch#3a6780089e0e2d69aaf77666524e81801c814bdd"
cargo: Bump the kvm and vmm-sys-util crates Since the kvm crates now depend on vmm-sys-util, the bump must be atomic. The kvm-bindings and ioctls 0.2.0 and 0.4.0 crates come with a few API changes, one of them being the use of a kvm_ioctls specific error type. Porting our code to that type makes for a fairly large diff stat. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-11-29 15:36:33 +00:00
dependencies = [
vmm: cpu: Get and set KVM vCPU state These two new helpers will be useful to capture a vCPU state and being able to restore it at a later time. Signed-off-by: Cathy Zhang <cathy.zhang@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2020-02-16 20:42:42 +00:00
"serde",
"serde_derive",
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"vmm-sys-util",
cargo: Bump the kvm and vmm-sys-util crates Since the kvm crates now depend on vmm-sys-util, the bump must be atomic. The kvm-bindings and ioctls 0.2.0 and 0.4.0 crates come with a few API changes, one of them being the use of a kvm_ioctls specific error type. Porting our code to that type makes for a fairly large diff stat. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-11-29 15:36:33 +00:00
]
cloud-hypervisor: Call into the test_vm() routine test_vm is a dummy VM workload, we use it to test our initial VMM settings. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-22 16:05:02 +00:00
[[package]]
name = "kvm-ioctls"
build(deps): bump kvm-ioctls from 0.4.0 to 0.5.0 Bumps [kvm-ioctls](https://github.com/rust-vmm/kvm-ioctls) from 0.4.0 to 0.5.0. - [Release notes](https://github.com/rust-vmm/kvm-ioctls/releases) - [Changelog](https://github.com/rust-vmm/kvm-ioctls/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-vmm/kvm-ioctls/compare/v0.4.0...v0.5.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-29 09:53:56 +00:00
version = "0.5.0"
build, vmm: Update to latest kvm-ioctls The ch branch has been rebased to incorporate the latest upstream code requiring a small change to the unit tests. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2020-05-13 11:03:55 +00:00
source = "git+https://github.com/cloud-hypervisor/kvm-ioctls?branch=ch#5b7f1cc5de6d9664ee30e7d6a2f183499de0f685"
cloud-hypervisor: Call into the test_vm() routine test_vm is a dummy VM workload, we use it to test our initial VMM settings. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-22 16:05:02 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"kvm-bindings",
"libc",
"vmm-sys-util",
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
]
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
[[package]]
name = "lazy_static"
build(deps): bump lazy_static from 1.3.0 to 1.4.0 Bumps [lazy_static](https://github.com/rust-lang-nursery/lazy-static.rs) from 1.3.0 to 1.4.0. - [Release notes](https://github.com/rust-lang-nursery/lazy-static.rs/releases) - [Commits](https://github.com/rust-lang-nursery/lazy-static.rs/compare/1.3.0...1.4.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-26 01:05:43 +00:00
version = "1.4.0"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "e2abad23fbc42b3700f2f279844dc832adb2b2eb069b2df918f455c4e18cc646"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
[[package]]
name = "libc"
build(deps): bump libc from 0.2.70 to 0.2.71 Bumps [libc](https://github.com/rust-lang/libc) from 0.2.70 to 0.2.71. - [Release notes](https://github.com/rust-lang/libc/releases) - [Commits](https://github.com/rust-lang/libc/compare/0.2.70...0.2.71) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-26 15:44:29 +00:00
version = "0.2.71"
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump libc from 0.2.70 to 0.2.71 Bumps [libc](https://github.com/rust-lang/libc) from 0.2.70 to 0.2.71. - [Release notes](https://github.com/rust-lang/libc/releases) - [Commits](https://github.com/rust-lang/libc/compare/0.2.70...0.2.71) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-26 15:44:29 +00:00
checksum = "9457b06509d27052635f90d6466700c65095fdf75409b3fbdd903e988b886f49"
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
[[package]]
name = "libssh2-sys"
build(deps): bump libssh2-sys from 0.2.16 to 0.2.17 Bumps [libssh2-sys](https://github.com/alexcrichton/ssh2-rs) from 0.2.16 to 0.2.17. - [Release notes](https://github.com/alexcrichton/ssh2-rs/releases) - [Commits](https://github.com/alexcrichton/ssh2-rs/compare/libssh2-sys-0.2.16...libssh2-sys-0.2.17) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-04-26 15:15:57 +00:00
version = "0.2.17"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump libssh2-sys from 0.2.16 to 0.2.17 Bumps [libssh2-sys](https://github.com/alexcrichton/ssh2-rs) from 0.2.16 to 0.2.17. - [Release notes](https://github.com/alexcrichton/ssh2-rs/releases) - [Commits](https://github.com/alexcrichton/ssh2-rs/compare/libssh2-sys-0.2.16...libssh2-sys-0.2.17) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-04-26 15:15:57 +00:00
checksum = "d45f516b9b19ea6c940b9f36d36734062a153a2b4cc9ef31d82c54bb9780f525"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"cc",
"libc",
"libz-sys",
"openssl-sys",
"pkg-config",
"vcpkg",
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
]
[[package]]
name = "libz-sys"
version = "1.0.25"
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "2eb5e43362e38e2bca2fd5f5134c4d4564a23a5c28e9b95411652021a8675ebe"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"cc",
"libc",
"pkg-config",
"vcpkg",
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
]
cloud-hypervisor: Initial kernel booting implementation Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-28 13:16:58 +00:00
[[package]]
name = "linux-loader"
version = "0.1.0"
build(deps): bump linux-loader from `f7f2e89` to `2a62f21` Bumps [linux-loader](https://github.com/rust-vmm/linux-loader) from `f7f2e89` to `2a62f21`. - [Release notes](https://github.com/rust-vmm/linux-loader/releases) - [Commits](https://github.com/rust-vmm/linux-loader/compare/f7f2e890f7c30b15797e2848298291e433825d27...2a62f21b441716332df048762c3b15700f72563f) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-17 06:20:47 +00:00
source = "git+https://github.com/rust-vmm/linux-loader#2a62f21b441716332df048762c3b15700f72563f"
vendor: Add vendored dependencies We use cargo vendor to generate a .cargo/config file and the vendor directory. Vendoring allows us to lock our dependencies and to modify them easily from the top level Cargo.toml. We vendor all dependencies, including the crates.io ones, which allows for network isolated builds. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-06-03 14:40:09 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"vm-memory",
vendor: Add vendored dependencies We use cargo vendor to generate a .cargo/config file and the vendor directory. Vendoring allows us to lock our dependencies and to modify them easily from the top level Cargo.toml. We vendor all dependencies, including the crates.io ones, which allows for network isolated builds. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-06-03 14:40:09 +00:00
]
build(deps): bump ssh2 from 0.6.0 to 0.7.1 Bumps [ssh2](https://github.com/alexcrichton/ssh2-rs) from 0.6.0 to 0.7.1. - [Release notes](https://github.com/alexcrichton/ssh2-rs/releases) - [Commits](https://github.com/alexcrichton/ssh2-rs/compare/0.6.0...0.7.1) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-25 22:43:45 +00:00
[[package]]
name = "lock_api"
build(deps): bump lock_api from 0.3.3 to 0.3.4 Bumps [lock_api](https://github.com/Amanieu/parking_lot) from 0.3.3 to 0.3.4. - [Release notes](https://github.com/Amanieu/parking_lot/releases) - [Changelog](https://github.com/Amanieu/parking_lot/blob/master/CHANGELOG.md) - [Commits](https://github.com/Amanieu/parking_lot/compare/lock_api-0.3.3...lock_api-0.3.4) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-04-10 16:25:49 +00:00
version = "0.3.4"
build(deps): bump ssh2 from 0.6.0 to 0.7.1 Bumps [ssh2](https://github.com/alexcrichton/ssh2-rs) from 0.6.0 to 0.7.1. - [Release notes](https://github.com/alexcrichton/ssh2-rs/releases) - [Commits](https://github.com/alexcrichton/ssh2-rs/compare/0.6.0...0.7.1) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-25 22:43:45 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump lock_api from 0.3.3 to 0.3.4 Bumps [lock_api](https://github.com/Amanieu/parking_lot) from 0.3.3 to 0.3.4. - [Release notes](https://github.com/Amanieu/parking_lot/releases) - [Changelog](https://github.com/Amanieu/parking_lot/blob/master/CHANGELOG.md) - [Commits](https://github.com/Amanieu/parking_lot/compare/lock_api-0.3.3...lock_api-0.3.4) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-04-10 16:25:49 +00:00
checksum = "c4da24a77a3d8a6d4862d95f72e6fdb9c09a643ecdb402d754004a557f2bec75"
build(deps): bump ssh2 from 0.6.0 to 0.7.1 Bumps [ssh2](https://github.com/alexcrichton/ssh2-rs) from 0.6.0 to 0.7.1. - [Release notes](https://github.com/alexcrichton/ssh2-rs/releases) - [Commits](https://github.com/alexcrichton/ssh2-rs/compare/0.6.0...0.7.1) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-25 22:43:45 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"scopeguard",
build(deps): bump ssh2 from 0.6.0 to 0.7.1 Bumps [ssh2](https://github.com/alexcrichton/ssh2-rs) from 0.6.0 to 0.7.1. - [Release notes](https://github.com/alexcrichton/ssh2-rs/releases) - [Commits](https://github.com/alexcrichton/ssh2-rs/compare/0.6.0...0.7.1) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-25 22:43:45 +00:00
]
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
[[package]]
name = "log"
version = "0.3.9"
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "e19e8d5c34a3e0e2223db8e060f9e8264aeeb5c5fc64a4ee9965c062211c024b"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"log 0.4.8",
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
]
vmm: Add PCI root Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-04-18 10:26:09 +00:00
[[package]]
name = "log"
build: Fix log dependency @dependabot bumped the dependency to 0.4.10 but this is no longer a valid version so downgrade appropriately. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2020-03-13 15:01:27 +00:00
version = "0.4.8"
vmm: Add PCI root Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-04-18 10:26:09 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "14b6052be84e6b71ab17edffc2eeabf5c2c3ae1fdb464aae35ac50c67a44e1f7"
vmm: Add PCI root Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-04-18 10:26:09 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"cfg-if",
vmm: Add PCI root Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-04-18 10:26:09 +00:00
]
vmm: memory_manager: Implement the Transportable trait This implements the send() function of the Transportable trait, so that the guest memory regions can be saved into one file per region. This will need to be extended for live migration, as it will require other transport methods and the recv() function will need to be implemented too. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2020-02-25 01:38:08 +00:00
[[package]]
name = "matches"
version = "0.1.8"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "7ffc5c5338469d4d3ea17d269fa8ea3512ad247247c30bd2df69e68309ed0a08"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
[[package]]
name = "memchr"
build(deps): bump memchr from 2.3.2 to 2.3.3 Bumps [memchr](https://github.com/BurntSushi/rust-memchr) from 2.3.2 to 2.3.3. - [Release notes](https://github.com/BurntSushi/rust-memchr/releases) - [Commits](https://github.com/BurntSushi/rust-memchr/compare/2.3.2...2.3.3) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-02-21 20:02:17 +00:00
version = "2.3.3"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "3728d817d99e5ac407411fa471ff9800a778d88a24685968b36824eaf4bee400"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
vmm: api: Add HTTP server The Cloud Hyper HTTP server runs a synchronous, multi-threaded loop that receives HTTP requests and tries to call the corresponding endpoint handlers for the requests URIs. An endpoint handler will parse the HTTP request and potentially translate it into and IPC request. The handler holds an notifier and an mspc Sender for respectively notifying and sending the IPC payload to the VMM API server. The handler then waits for an API server response and translate it back into an HTTP response. The HTTP server is responsible for sending the reponse back to the caller. The HTTP server uses a static routes hash table that maps URIs to endpoint handlers. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-09-18 09:14:49 +00:00
[[package]]
name = "micro_http"
version = "0.1.0"
build(deps): bump micro_http from `0d87a94` to `c9ffb90` Bumps [micro_http](https://github.com/firecracker-microvm/micro-http) from `0d87a94` to `c9ffb90`. - [Release notes](https://github.com/firecracker-microvm/micro-http/releases) - [Commits](https://github.com/firecracker-microvm/micro-http/compare/0d87a94c8e5a76499fbd1e4acb20a5f4406e6ad1...c9ffb90aebdc77a8fade2e4196f311f9bbfcce82) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-04-28 06:18:15 +00:00
source = "git+https://github.com/firecracker-microvm/micro-http#c9ffb90aebdc77a8fade2e4196f311f9bbfcce82"
cargo: Update micro_http Update micro_http create to allow set content type. Suggested-by: Samuel Ortiz <sameo@linux.intel.com> Tested-by: Jose Carlos Venegas Munoz <jose.carlos.venegas.munoz@intel.com> Signed-off-by: Jose Carlos Venegas Munoz <jose.carlos.venegas.munoz@intel.com>
2019-11-08 17:49:51 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"epoll",
cargo: Update micro_http Update micro_http create to allow set content type. Suggested-by: Samuel Ortiz <sameo@linux.intel.com> Tested-by: Jose Carlos Venegas Munoz <jose.carlos.venegas.munoz@intel.com> Signed-off-by: Jose Carlos Venegas Munoz <jose.carlos.venegas.munoz@intel.com>
2019-11-08 17:49:51 +00:00
]
vmm: api: Add HTTP server The Cloud Hyper HTTP server runs a synchronous, multi-threaded loop that receives HTTP requests and tries to call the corresponding endpoint handlers for the requests URIs. An endpoint handler will parse the HTTP request and potentially translate it into and IPC request. The handler holds an notifier and an mspc Sender for respectively notifying and sending the IPC payload to the VMM API server. The handler then waits for an API server response and translate it back into an HTTP response. The HTTP server is responsible for sending the reponse back to the caller. The HTTP server uses a static routes hash table that maps URIs to endpoint handlers. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-09-18 09:14:49 +00:00
build(deps): bump backtrace from 0.3.48 to 0.3.49 Bumps [backtrace](https://github.com/rust-lang/backtrace-rs) from 0.3.48 to 0.3.49. - [Release notes](https://github.com/rust-lang/backtrace-rs/releases) - [Commits](https://github.com/rust-lang/backtrace-rs/compare/0.3.48...0.3.49) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-15 14:15:23 +00:00
[[package]]
name = "miniz_oxide"
version = "0.3.7"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "791daaae1ed6889560f8c4359194f56648355540573244a5448a83ba1ecc7435"
dependencies = [
"adler32",
]
network: Add virtio-net dependencies The newly added virtio-net implementation needs to interact with TAP interfaces and MAC addresses, which is the reason why it is easier to rely on existing packages net_util and net_gen. One more thing, both net_util and net_gen could be trimmed down, based on using only the things we need from cloud-hypervisor. Both net_util, net_gen and sys_util are based on Firecracker commit d4a89cdc0bd2867f821e3678328dabad6dd8b767. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-05-08 05:28:02 +00:00
[[package]]
name = "net_gen"
version = "0.1.0"
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"vmm-sys-util",
network: Add virtio-net dependencies The newly added virtio-net implementation needs to interact with TAP interfaces and MAC addresses, which is the reason why it is easier to rely on existing packages net_util and net_gen. One more thing, both net_util and net_gen could be trimmed down, based on using only the things we need from cloud-hypervisor. Both net_util, net_gen and sys_util are based on Firecracker commit d4a89cdc0bd2867f821e3678328dabad6dd8b767. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-05-08 05:28:02 +00:00
]
[[package]]
name = "net_util"
version = "0.1.0"
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"lazy_static",
"libc",
"net_gen",
"pnet",
"rand 0.7.3",
"serde",
"serde_json",
"vmm-sys-util",
network: Add virtio-net dependencies The newly added virtio-net implementation needs to interact with TAP interfaces and MAC addresses, which is the reason why it is easier to rely on existing packages net_util and net_gen. One more thing, both net_util and net_gen could be trimmed down, based on using only the things we need from cloud-hypervisor. Both net_util, net_gen and sys_util are based on Firecracker commit d4a89cdc0bd2867f821e3678328dabad6dd8b767. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-05-08 05:28:02 +00:00
]
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
[[package]]
name = "num_cpus"
build(deps): bump num_cpus from 1.12.0 to 1.13.0 Bumps [num_cpus](https://github.com/seanmonstar/num_cpus) from 1.12.0 to 1.13.0. - [Release notes](https://github.com/seanmonstar/num_cpus/releases) - [Changelog](https://github.com/seanmonstar/num_cpus/blob/master/CHANGELOG.md) - [Commits](https://github.com/seanmonstar/num_cpus/compare/v1.12.0...v1.13.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-04-15 16:24:34 +00:00
version = "1.13.0"
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump num_cpus from 1.12.0 to 1.13.0 Bumps [num_cpus](https://github.com/seanmonstar/num_cpus) from 1.12.0 to 1.13.0. - [Release notes](https://github.com/seanmonstar/num_cpus/releases) - [Changelog](https://github.com/seanmonstar/num_cpus/blob/master/CHANGELOG.md) - [Commits](https://github.com/seanmonstar/num_cpus/compare/v1.12.0...v1.13.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-04-15 16:24:34 +00:00
checksum = "05499f3756671c15885fee9034446956fff3f243d6077b91e5767df161f766b3"
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"hermit-abi",
"libc",
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
]
build(deps): bump backtrace from 0.3.46 to 0.3.47 Bumps [backtrace](https://github.com/rust-lang/backtrace-rs) from 0.3.46 to 0.3.47. - [Release notes](https://github.com/rust-lang/backtrace-rs/releases) - [Commits](https://github.com/rust-lang/backtrace-rs/compare/0.3.46...0.3.47) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-12 17:51:11 +00:00
[[package]]
name = "object"
build(deps): bump backtrace from 0.3.48 to 0.3.49 Bumps [backtrace](https://github.com/rust-lang/backtrace-rs) from 0.3.48 to 0.3.49. - [Release notes](https://github.com/rust-lang/backtrace-rs/releases) - [Commits](https://github.com/rust-lang/backtrace-rs/compare/0.3.48...0.3.49) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-15 14:15:23 +00:00
version = "0.20.0"
build(deps): bump backtrace from 0.3.46 to 0.3.47 Bumps [backtrace](https://github.com/rust-lang/backtrace-rs) from 0.3.46 to 0.3.47. - [Release notes](https://github.com/rust-lang/backtrace-rs/releases) - [Commits](https://github.com/rust-lang/backtrace-rs/compare/0.3.46...0.3.47) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-12 17:51:11 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump backtrace from 0.3.48 to 0.3.49 Bumps [backtrace](https://github.com/rust-lang/backtrace-rs) from 0.3.48 to 0.3.49. - [Release notes](https://github.com/rust-lang/backtrace-rs/releases) - [Commits](https://github.com/rust-lang/backtrace-rs/compare/0.3.48...0.3.49) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-15 14:15:23 +00:00
checksum = "1ab52be62400ca80aa00285d25253d7f7c437b7375c4de678f5405d3afe82ca5"
build(deps): bump backtrace from 0.3.46 to 0.3.47 Bumps [backtrace](https://github.com/rust-lang/backtrace-rs) from 0.3.46 to 0.3.47. - [Release notes](https://github.com/rust-lang/backtrace-rs/releases) - [Commits](https://github.com/rust-lang/backtrace-rs/compare/0.3.46...0.3.47) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-12 17:51:11 +00:00
build(deps): bump futures from 0.3.4 to 0.3.5 Bumps [futures](https://github.com/rust-lang/futures-rs) from 0.3.4 to 0.3.5. - [Release notes](https://github.com/rust-lang/futures-rs/releases) - [Changelog](https://github.com/rust-lang/futures-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/futures-rs/compare/0.3.4...0.3.5) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-08 23:34:07 +00:00
[[package]]
name = "once_cell"
build(deps): bump once_cell from 1.3.1 to 1.4.0 Bumps [once_cell](https://github.com/matklad/once_cell) from 1.3.1 to 1.4.0. - [Release notes](https://github.com/matklad/once_cell/releases) - [Changelog](https://github.com/matklad/once_cell/blob/master/CHANGELOG.md) - [Commits](https://github.com/matklad/once_cell/compare/v1.3.1...v1.4.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-13 23:54:11 +00:00
version = "1.4.0"
build(deps): bump futures from 0.3.4 to 0.3.5 Bumps [futures](https://github.com/rust-lang/futures-rs) from 0.3.4 to 0.3.5. - [Release notes](https://github.com/rust-lang/futures-rs/releases) - [Changelog](https://github.com/rust-lang/futures-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/futures-rs/compare/0.3.4...0.3.5) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-08 23:34:07 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump once_cell from 1.3.1 to 1.4.0 Bumps [once_cell](https://github.com/matklad/once_cell) from 1.3.1 to 1.4.0. - [Release notes](https://github.com/matklad/once_cell/releases) - [Changelog](https://github.com/matklad/once_cell/blob/master/CHANGELOG.md) - [Commits](https://github.com/matklad/once_cell/compare/v1.3.1...v1.4.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-13 23:54:11 +00:00
checksum = "0b631f7e854af39a1739f401cf34a8a013dfe09eac4fa4dba91e9768bd28168d"
build(deps): bump futures from 0.3.4 to 0.3.5 Bumps [futures](https://github.com/rust-lang/futures-rs) from 0.3.4 to 0.3.5. - [Release notes](https://github.com/rust-lang/futures-rs/releases) - [Changelog](https://github.com/rust-lang/futures-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/futures-rs/compare/0.3.4...0.3.5) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-08 23:34:07 +00:00
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
[[package]]
name = "openssl-sys"
build(deps): bump openssl-sys from 0.9.57 to 0.9.58 Bumps [openssl-sys](https://github.com/sfackler/rust-openssl) from 0.9.57 to 0.9.58. - [Release notes](https://github.com/sfackler/rust-openssl/releases) - [Commits](https://github.com/sfackler/rust-openssl/compare/openssl-sys-v0.9.57...openssl-sys-v0.9.58) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-05 22:35:33 +00:00
version = "0.9.58"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump openssl-sys from 0.9.57 to 0.9.58 Bumps [openssl-sys](https://github.com/sfackler/rust-openssl) from 0.9.57 to 0.9.58. - [Release notes](https://github.com/sfackler/rust-openssl/releases) - [Commits](https://github.com/sfackler/rust-openssl/compare/openssl-sys-v0.9.57...openssl-sys-v0.9.58) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-05 22:35:33 +00:00
checksum = "a842db4709b604f0fe5d1170ae3565899be2ad3d9cbc72dedc789ac0511f78de"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"autocfg",
"cc",
"libc",
"pkg-config",
"vcpkg",
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
]
build(deps): bump ssh2 from 0.6.0 to 0.7.1 Bumps [ssh2](https://github.com/alexcrichton/ssh2-rs) from 0.6.0 to 0.7.1. - [Release notes](https://github.com/alexcrichton/ssh2-rs/releases) - [Commits](https://github.com/alexcrichton/ssh2-rs/compare/0.6.0...0.7.1) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-25 22:43:45 +00:00
[[package]]
name = "parking_lot"
build(deps): bump parking_lot from 0.10.0 to 0.10.2 Bumps [parking_lot](https://github.com/Amanieu/parking_lot) from 0.10.0 to 0.10.2. - [Release notes](https://github.com/Amanieu/parking_lot/releases) - [Changelog](https://github.com/Amanieu/parking_lot/blob/master/CHANGELOG.md) - [Commits](https://github.com/Amanieu/parking_lot/compare/0.10.0...0.10.2) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-04-10 22:14:51 +00:00
version = "0.10.2"
build(deps): bump ssh2 from 0.6.0 to 0.7.1 Bumps [ssh2](https://github.com/alexcrichton/ssh2-rs) from 0.6.0 to 0.7.1. - [Release notes](https://github.com/alexcrichton/ssh2-rs/releases) - [Commits](https://github.com/alexcrichton/ssh2-rs/compare/0.6.0...0.7.1) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-25 22:43:45 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump parking_lot from 0.10.0 to 0.10.2 Bumps [parking_lot](https://github.com/Amanieu/parking_lot) from 0.10.0 to 0.10.2. - [Release notes](https://github.com/Amanieu/parking_lot/releases) - [Changelog](https://github.com/Amanieu/parking_lot/blob/master/CHANGELOG.md) - [Commits](https://github.com/Amanieu/parking_lot/compare/0.10.0...0.10.2) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-04-10 22:14:51 +00:00
checksum = "d3a704eb390aafdc107b0e392f56a82b668e3a71366993b5340f5833fd62505e"
build(deps): bump ssh2 from 0.6.0 to 0.7.1 Bumps [ssh2](https://github.com/alexcrichton/ssh2-rs) from 0.6.0 to 0.7.1. - [Release notes](https://github.com/alexcrichton/ssh2-rs/releases) - [Commits](https://github.com/alexcrichton/ssh2-rs/compare/0.6.0...0.7.1) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-25 22:43:45 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"lock_api",
"parking_lot_core",
build(deps): bump ssh2 from 0.6.0 to 0.7.1 Bumps [ssh2](https://github.com/alexcrichton/ssh2-rs) from 0.6.0 to 0.7.1. - [Release notes](https://github.com/alexcrichton/ssh2-rs/releases) - [Commits](https://github.com/alexcrichton/ssh2-rs/compare/0.6.0...0.7.1) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-25 22:43:45 +00:00
]
[[package]]
name = "parking_lot_core"
build(deps): bump parking_lot_core from 0.7.1 to 0.7.2 Bumps [parking_lot_core](https://github.com/Amanieu/parking_lot) from 0.7.1 to 0.7.2. - [Release notes](https://github.com/Amanieu/parking_lot/releases) - [Changelog](https://github.com/Amanieu/parking_lot/blob/master/CHANGELOG.md) - [Commits](https://github.com/Amanieu/parking_lot/compare/0.7.1...core-0.7.2) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-04-21 22:15:56 +00:00
version = "0.7.2"
build(deps): bump ssh2 from 0.6.0 to 0.7.1 Bumps [ssh2](https://github.com/alexcrichton/ssh2-rs) from 0.6.0 to 0.7.1. - [Release notes](https://github.com/alexcrichton/ssh2-rs/releases) - [Commits](https://github.com/alexcrichton/ssh2-rs/compare/0.6.0...0.7.1) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-25 22:43:45 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump parking_lot_core from 0.7.1 to 0.7.2 Bumps [parking_lot_core](https://github.com/Amanieu/parking_lot) from 0.7.1 to 0.7.2. - [Release notes](https://github.com/Amanieu/parking_lot/releases) - [Changelog](https://github.com/Amanieu/parking_lot/blob/master/CHANGELOG.md) - [Commits](https://github.com/Amanieu/parking_lot/compare/0.7.1...core-0.7.2) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-04-21 22:15:56 +00:00
checksum = "d58c7c768d4ba344e3e8d72518ac13e259d7c7ade24167003b8488e10b6740a3"
build(deps): bump ssh2 from 0.6.0 to 0.7.1 Bumps [ssh2](https://github.com/alexcrichton/ssh2-rs) from 0.6.0 to 0.7.1. - [Release notes](https://github.com/alexcrichton/ssh2-rs/releases) - [Commits](https://github.com/alexcrichton/ssh2-rs/compare/0.6.0...0.7.1) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-25 22:43:45 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"cfg-if",
"cloudabi",
"libc",
"redox_syscall",
"smallvec",
"winapi 0.3.8",
build(deps): bump ssh2 from 0.6.0 to 0.7.1 Bumps [ssh2](https://github.com/alexcrichton/ssh2-rs) from 0.6.0 to 0.7.1. - [Release notes](https://github.com/alexcrichton/ssh2-rs/releases) - [Commits](https://github.com/alexcrichton/ssh2-rs/compare/0.6.0...0.7.1) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-25 22:43:45 +00:00
]
vmm: Add PCI root Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-04-18 10:26:09 +00:00
[[package]]
name = "pci"
version = "0.1.0"
dependencies = [
pci: Implement Snapshottable trait for MsixConfig In order to restore devices relying on MSI-X, the MsixConfig structure must be restored with the correct values. Additionally, the KVM routes must be restored so that interrupts can be delivered through KVM the way they were configured before the snapshot was taken. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2020-05-06 15:50:56 +00:00
"anyhow",
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"byteorder",
"devices",
vfio: Move the PCI implementation to the PCI crate There is a much stronger PCI dependency from vfio_pci.rs than a VFIO one from pci/src/vfio.rs. It seems more natural to have the PCI specific VFIO implementation in the PCI crate rather than the other way around. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-11-08 14:50:39 +00:00
"kvm-bindings",
"kvm-ioctls",
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"libc",
"log 0.4.8",
pci: Implement Snapshottable trait for MsixConfig In order to restore devices relying on MSI-X, the MsixConfig structure must be restored with the correct values. Additionally, the KVM routes must be restored so that interrupts can be delivered through KVM the way they were configured before the snapshot was taken. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2020-05-06 15:50:56 +00:00
"serde",
"serde_derive",
"serde_json",
vfio: Switch to the vfio-ioctls crate ch branch Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-11-12 14:36:07 +00:00
"vfio-bindings 0.2.0 (git+https://github.com/rust-vmm/vfio-bindings)",
vfio: Rename to vfio-ioctls Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-11-08 15:27:05 +00:00
"vfio-ioctls",
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"vm-allocator",
"vm-device",
"vm-memory",
pci: Implement Snapshottable trait for MsixConfig In order to restore devices relying on MSI-X, the MsixConfig structure must be restored with the correct values. Additionally, the KVM routes must be restored so that interrupts can be delivered through KVM the way they were configured before the snapshot was taken. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2020-05-06 15:50:56 +00:00
"vm-migration",
vfio: Move the PCI implementation to the PCI crate There is a much stronger PCI dependency from vfio_pci.rs than a VFIO one from pci/src/vfio.rs. It seems more natural to have the PCI specific VFIO implementation in the PCI crate rather than the other way around. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-11-08 14:50:39 +00:00
"vmm-sys-util",
vmm: Add PCI root Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-04-18 10:26:09 +00:00
]
vmm: memory_manager: Implement the Transportable trait This implements the send() function of the Transportable trait, so that the guest memory regions can be saved into one file per region. This will need to be extended for live migration, as it will require other transport methods and the recv() function will need to be implemented too. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2020-02-25 01:38:08 +00:00
[[package]]
name = "percent-encoding"
version = "2.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "d4fd5641d01c8f18a23da7b6fe29298ff4b55afcccdf78973b24cf3175fee32e"
build(deps): bump futures from 0.3.4 to 0.3.5 Bumps [futures](https://github.com/rust-lang/futures-rs) from 0.3.4 to 0.3.5. - [Release notes](https://github.com/rust-lang/futures-rs/releases) - [Changelog](https://github.com/rust-lang/futures-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/futures-rs/compare/0.3.4...0.3.5) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-08 23:34:07 +00:00
[[package]]
name = "pin-project"
build(deps): bump pin-project from 0.4.20 to 0.4.22 Bumps [pin-project](https://github.com/taiki-e/pin-project) from 0.4.20 to 0.4.22. - [Release notes](https://github.com/taiki-e/pin-project/releases) - [Changelog](https://github.com/taiki-e/pin-project/blob/master/CHANGELOG.md) - [Commits](https://github.com/taiki-e/pin-project/compare/v0.4.20...v0.4.22) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-14 03:08:05 +00:00
version = "0.4.22"
build(deps): bump futures from 0.3.4 to 0.3.5 Bumps [futures](https://github.com/rust-lang/futures-rs) from 0.3.4 to 0.3.5. - [Release notes](https://github.com/rust-lang/futures-rs/releases) - [Changelog](https://github.com/rust-lang/futures-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/futures-rs/compare/0.3.4...0.3.5) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-08 23:34:07 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump pin-project from 0.4.20 to 0.4.22 Bumps [pin-project](https://github.com/taiki-e/pin-project) from 0.4.20 to 0.4.22. - [Release notes](https://github.com/taiki-e/pin-project/releases) - [Changelog](https://github.com/taiki-e/pin-project/blob/master/CHANGELOG.md) - [Commits](https://github.com/taiki-e/pin-project/compare/v0.4.20...v0.4.22) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-14 03:08:05 +00:00
checksum = "12e3a6cdbfe94a5e4572812a0201f8c0ed98c1c452c7b8563ce2276988ef9c17"
build(deps): bump futures from 0.3.4 to 0.3.5 Bumps [futures](https://github.com/rust-lang/futures-rs) from 0.3.4 to 0.3.5. - [Release notes](https://github.com/rust-lang/futures-rs/releases) - [Changelog](https://github.com/rust-lang/futures-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/futures-rs/compare/0.3.4...0.3.5) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-08 23:34:07 +00:00
dependencies = [
"pin-project-internal",
]
[[package]]
name = "pin-project-internal"
build(deps): bump pin-project from 0.4.20 to 0.4.22 Bumps [pin-project](https://github.com/taiki-e/pin-project) from 0.4.20 to 0.4.22. - [Release notes](https://github.com/taiki-e/pin-project/releases) - [Changelog](https://github.com/taiki-e/pin-project/blob/master/CHANGELOG.md) - [Commits](https://github.com/taiki-e/pin-project/compare/v0.4.20...v0.4.22) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-14 03:08:05 +00:00
version = "0.4.22"
build(deps): bump futures from 0.3.4 to 0.3.5 Bumps [futures](https://github.com/rust-lang/futures-rs) from 0.3.4 to 0.3.5. - [Release notes](https://github.com/rust-lang/futures-rs/releases) - [Changelog](https://github.com/rust-lang/futures-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/futures-rs/compare/0.3.4...0.3.5) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-08 23:34:07 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump pin-project from 0.4.20 to 0.4.22 Bumps [pin-project](https://github.com/taiki-e/pin-project) from 0.4.20 to 0.4.22. - [Release notes](https://github.com/taiki-e/pin-project/releases) - [Changelog](https://github.com/taiki-e/pin-project/blob/master/CHANGELOG.md) - [Commits](https://github.com/taiki-e/pin-project/compare/v0.4.20...v0.4.22) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-14 03:08:05 +00:00
checksum = "6a0ffd45cf79d88737d7cc85bfd5d2894bee1139b356e616fe85dc389c61aaf7"
build(deps): bump futures from 0.3.4 to 0.3.5 Bumps [futures](https://github.com/rust-lang/futures-rs) from 0.3.4 to 0.3.5. - [Release notes](https://github.com/rust-lang/futures-rs/releases) - [Changelog](https://github.com/rust-lang/futures-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/futures-rs/compare/0.3.4...0.3.5) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-08 23:34:07 +00:00
dependencies = [
"proc-macro2",
"quote",
"syn",
]
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
[[package]]
name = "pin-utils"
build(deps): bump pin-utils from 0.1.0-alpha.4 to 0.1.0 Bumps [pin-utils](https://github.com/rust-lang-nursery/pin-utils) from 0.1.0-alpha.4 to 0.1.0. - [Release notes](https://github.com/rust-lang-nursery/pin-utils/releases) - [Commits](https://github.com/rust-lang-nursery/pin-utils/compare/0.1.0-alpha.4...0.1.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-04-22 16:25:21 +00:00
version = "0.1.0"
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump pin-utils from 0.1.0-alpha.4 to 0.1.0 Bumps [pin-utils](https://github.com/rust-lang-nursery/pin-utils) from 0.1.0-alpha.4 to 0.1.0. - [Release notes](https://github.com/rust-lang-nursery/pin-utils/releases) - [Commits](https://github.com/rust-lang-nursery/pin-utils/compare/0.1.0-alpha.4...0.1.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-04-22 16:25:21 +00:00
checksum = "8b870d8c151b6f2fb93e84a13146138f05d02ed11c7e7c54f8826aaaf7c9f184"
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
[[package]]
name = "pkg-config"
build(deps): bump pkg-config from 0.3.16 to 0.3.17 Bumps [pkg-config](https://github.com/rust-lang/pkg-config-rs) from 0.3.16 to 0.3.17. - [Release notes](https://github.com/rust-lang/pkg-config-rs/releases) - [Changelog](https://github.com/rust-lang/pkg-config-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/pkg-config-rs/compare/0.3.16...0.3.17) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-11-02 09:47:40 +00:00
version = "0.3.17"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "05da548ad6865900e60eaba7f589cc0783590a92e940c26953ff81ddbab2d677"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
[[package]]
name = "pnet"
build(deps): bump pnet from 0.25.0 to 0.26.0 Bumps [pnet](https://github.com/libpnet/libpnet) from 0.25.0 to 0.26.0. - [Release notes](https://github.com/libpnet/libpnet/releases) - [Commits](https://github.com/libpnet/libpnet/compare/v0.25.0...v0.26.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-04 07:04:05 +00:00
version = "0.26.0"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump pnet from 0.25.0 to 0.26.0 Bumps [pnet](https://github.com/libpnet/libpnet) from 0.25.0 to 0.26.0. - [Release notes](https://github.com/libpnet/libpnet/releases) - [Commits](https://github.com/libpnet/libpnet/compare/v0.25.0...v0.26.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-04 07:04:05 +00:00
checksum = "c62df42dcd72f6f2a658bcf38509f1027df1440ac85f1af4badbe034418302dc"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"ipnetwork",
"pnet_base",
"pnet_datalink",
"pnet_packet",
"pnet_sys",
"pnet_transport",
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
]
[[package]]
name = "pnet_base"
build(deps): bump pnet from 0.25.0 to 0.26.0 Bumps [pnet](https://github.com/libpnet/libpnet) from 0.25.0 to 0.26.0. - [Release notes](https://github.com/libpnet/libpnet/releases) - [Commits](https://github.com/libpnet/libpnet/compare/v0.25.0...v0.26.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-04 07:04:05 +00:00
version = "0.26.0"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump pnet from 0.25.0 to 0.26.0 Bumps [pnet](https://github.com/libpnet/libpnet) from 0.25.0 to 0.26.0. - [Release notes](https://github.com/libpnet/libpnet/releases) - [Commits](https://github.com/libpnet/libpnet/compare/v0.25.0...v0.26.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-04 07:04:05 +00:00
checksum = "b7cd5f7e15220afa66b0a9a62841ea10089f39dcaa1c29752c0b22dfc03111b5"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
[[package]]
name = "pnet_datalink"
build(deps): bump pnet from 0.25.0 to 0.26.0 Bumps [pnet](https://github.com/libpnet/libpnet) from 0.25.0 to 0.26.0. - [Release notes](https://github.com/libpnet/libpnet/releases) - [Commits](https://github.com/libpnet/libpnet/compare/v0.25.0...v0.26.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-04 07:04:05 +00:00
version = "0.26.0"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump pnet from 0.25.0 to 0.26.0 Bumps [pnet](https://github.com/libpnet/libpnet) from 0.25.0 to 0.26.0. - [Release notes](https://github.com/libpnet/libpnet/releases) - [Commits](https://github.com/libpnet/libpnet/compare/v0.25.0...v0.26.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-04 07:04:05 +00:00
checksum = "7318ae1d6e0b7fa1e49933233c9473f2b72d3d18b97e70e2716c6415dde5f915"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"ipnetwork",
"libc",
"pnet_base",
"pnet_sys",
"winapi 0.2.8",
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
]
[[package]]
name = "pnet_macros"
build(deps): bump pnet_macros from 0.25.0 to 0.26.0 Bumps [pnet_macros](https://github.com/libpnet/libpnet) from 0.25.0 to 0.26.0. - [Release notes](https://github.com/libpnet/libpnet/releases) - [Commits](https://github.com/libpnet/libpnet/compare/v0.25.0...v0.26.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-01 18:34:05 +00:00
version = "0.26.0"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump pnet_macros from 0.25.0 to 0.26.0 Bumps [pnet_macros](https://github.com/libpnet/libpnet) from 0.25.0 to 0.26.0. - [Release notes](https://github.com/libpnet/libpnet/releases) - [Commits](https://github.com/libpnet/libpnet/compare/v0.25.0...v0.26.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-01 18:34:05 +00:00
checksum = "bbbd5c52c6e04aa720400f9c71cd0e8bcb38cd13421d5caabd9035e9efa47de9"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"regex",
"syntex",
"syntex_syntax",
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
]
[[package]]
name = "pnet_macros_support"
build(deps): bump pnet from 0.25.0 to 0.26.0 Bumps [pnet](https://github.com/libpnet/libpnet) from 0.25.0 to 0.26.0. - [Release notes](https://github.com/libpnet/libpnet/releases) - [Commits](https://github.com/libpnet/libpnet/compare/v0.25.0...v0.26.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-04 07:04:05 +00:00
version = "0.26.0"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump pnet from 0.25.0 to 0.26.0 Bumps [pnet](https://github.com/libpnet/libpnet) from 0.25.0 to 0.26.0. - [Release notes](https://github.com/libpnet/libpnet/releases) - [Commits](https://github.com/libpnet/libpnet/compare/v0.25.0...v0.26.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-04 07:04:05 +00:00
checksum = "daf9c5c0c36766d0a4da9ab268c0700771b8ec367b9463fd678109fa28463c5b"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"pnet_base",
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
]
[[package]]
name = "pnet_packet"
build(deps): bump pnet from 0.25.0 to 0.26.0 Bumps [pnet](https://github.com/libpnet/libpnet) from 0.25.0 to 0.26.0. - [Release notes](https://github.com/libpnet/libpnet/releases) - [Commits](https://github.com/libpnet/libpnet/compare/v0.25.0...v0.26.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-04 07:04:05 +00:00
version = "0.26.0"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump pnet from 0.25.0 to 0.26.0 Bumps [pnet](https://github.com/libpnet/libpnet) from 0.25.0 to 0.26.0. - [Release notes](https://github.com/libpnet/libpnet/releases) - [Commits](https://github.com/libpnet/libpnet/compare/v0.25.0...v0.26.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-04 07:04:05 +00:00
checksum = "89e26a864d71d0ac51a549cf40283c44ed1b8f98168545638a4730ef9f560283"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"glob",
"pnet_base",
"pnet_macros",
"pnet_macros_support",
"syntex",
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
]
[[package]]
name = "pnet_sys"
build(deps): bump pnet from 0.25.0 to 0.26.0 Bumps [pnet](https://github.com/libpnet/libpnet) from 0.25.0 to 0.26.0. - [Release notes](https://github.com/libpnet/libpnet/releases) - [Commits](https://github.com/libpnet/libpnet/compare/v0.25.0...v0.26.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-04 07:04:05 +00:00
version = "0.26.0"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump pnet from 0.25.0 to 0.26.0 Bumps [pnet](https://github.com/libpnet/libpnet) from 0.25.0 to 0.26.0. - [Release notes](https://github.com/libpnet/libpnet/releases) - [Commits](https://github.com/libpnet/libpnet/compare/v0.25.0...v0.26.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-04 07:04:05 +00:00
checksum = "73f0de0c52609f157b25d79ce24d9016ab1bbf10cde761397200d634a833872c"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"libc",
"winapi 0.2.8",
"ws2_32-sys",
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
]
[[package]]
name = "pnet_transport"
build(deps): bump pnet from 0.25.0 to 0.26.0 Bumps [pnet](https://github.com/libpnet/libpnet) from 0.25.0 to 0.26.0. - [Release notes](https://github.com/libpnet/libpnet/releases) - [Commits](https://github.com/libpnet/libpnet/compare/v0.25.0...v0.26.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-04 07:04:05 +00:00
version = "0.26.0"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump pnet from 0.25.0 to 0.26.0 Bumps [pnet](https://github.com/libpnet/libpnet) from 0.25.0 to 0.26.0. - [Release notes](https://github.com/libpnet/libpnet/releases) - [Commits](https://github.com/libpnet/libpnet/compare/v0.25.0...v0.26.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-04 07:04:05 +00:00
checksum = "6712ab76534340494d849e3c51c64a6261e4b451337b7c05bd3681e384c48b10"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"libc",
"pnet_base",
"pnet_packet",
"pnet_sys",
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
]
vm-virtio: Add virtio console device for single port operation The virtio console device is a console for the communication between the host and guest userspace. It has two parts: the device and the driver. The console device is implemented here as a virtio-pci device to the guest. On the other side, the guest OS expected to have a character device driver which provides an interface to the userspace applications. The console device can have multiple ports where each port has one transmit queue and one receive queue. The current implementation only supports one port. For data IO communication, one or more empty buffers are placed in the receive queue for incoming data, and outgoing characters are placed in the transmit queue. Details spec can be found from the following link. https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.pdf#e7 Apart from the console, for the communication between guest and host, the Cloud Hypervisor has a legacy serial device implemented. However, the implementation of a console device lets us be independent of legacy pin-based interrupts without losing the logs and access to the VM. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-22 18:50:56 +00:00
[[package]]
name = "ppv-lite86"
build(deps): bump ppv-lite86 from 0.2.6 to 0.2.8 Bumps [ppv-lite86](https://github.com/cryptocorrosion/cryptocorrosion) from 0.2.6 to 0.2.8. - [Release notes](https://github.com/cryptocorrosion/cryptocorrosion/releases) - [Commits](https://github.com/cryptocorrosion/cryptocorrosion/compare/ppv-lite86-0.2.6...ppv-lite86-0.2.8) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-16 22:35:04 +00:00
version = "0.2.8"
vm-virtio: Add virtio console device for single port operation The virtio console device is a console for the communication between the host and guest userspace. It has two parts: the device and the driver. The console device is implemented here as a virtio-pci device to the guest. On the other side, the guest OS expected to have a character device driver which provides an interface to the userspace applications. The console device can have multiple ports where each port has one transmit queue and one receive queue. The current implementation only supports one port. For data IO communication, one or more empty buffers are placed in the receive queue for incoming data, and outgoing characters are placed in the transmit queue. Details spec can be found from the following link. https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.pdf#e7 Apart from the console, for the communication between guest and host, the Cloud Hypervisor has a legacy serial device implemented. However, the implementation of a console device lets us be independent of legacy pin-based interrupts without losing the logs and access to the VM. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-22 18:50:56 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump ppv-lite86 from 0.2.6 to 0.2.8 Bumps [ppv-lite86](https://github.com/cryptocorrosion/cryptocorrosion) from 0.2.6 to 0.2.8. - [Release notes](https://github.com/cryptocorrosion/cryptocorrosion/releases) - [Commits](https://github.com/cryptocorrosion/cryptocorrosion/compare/ppv-lite86-0.2.6...ppv-lite86-0.2.8) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-16 22:35:04 +00:00
checksum = "237a5ed80e274dbc66f86bd59c1e25edc039660be53194b5fe0a482e0f2612ea"
vm-virtio: Add virtio console device for single port operation The virtio console device is a console for the communication between the host and guest userspace. It has two parts: the device and the driver. The console device is implemented here as a virtio-pci device to the guest. On the other side, the guest OS expected to have a character device driver which provides an interface to the userspace applications. The console device can have multiple ports where each port has one transmit queue and one receive queue. The current implementation only supports one port. For data IO communication, one or more empty buffers are placed in the receive queue for incoming data, and outgoing characters are placed in the transmit queue. Details spec can be found from the following link. https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.pdf#e7 Apart from the console, for the communication between guest and host, the Cloud Hypervisor has a legacy serial device implemented. However, the implementation of a console device lets us be independent of legacy pin-based interrupts without losing the logs and access to the VM. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-22 18:50:56 +00:00
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
[[package]]
name = "proc-macro-hack"
build(deps): bump proc-macro-hack from 0.5.15 to 0.5.16 Bumps [proc-macro-hack](https://github.com/dtolnay/proc-macro-hack) from 0.5.15 to 0.5.16. - [Release notes](https://github.com/dtolnay/proc-macro-hack/releases) - [Commits](https://github.com/dtolnay/proc-macro-hack/compare/0.5.15...0.5.16) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-24 22:54:18 +00:00
version = "0.5.16"
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump proc-macro-hack from 0.5.15 to 0.5.16 Bumps [proc-macro-hack](https://github.com/dtolnay/proc-macro-hack) from 0.5.15 to 0.5.16. - [Release notes](https://github.com/dtolnay/proc-macro-hack/releases) - [Commits](https://github.com/dtolnay/proc-macro-hack/compare/0.5.15...0.5.16) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-24 22:54:18 +00:00
checksum = "7e0456befd48169b9f13ef0f0ad46d492cf9d2dbb918bcf38e01eed4ce3ec5e4"
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
[[package]]
name = "proc-macro-nested"
build(deps): bump proc-macro-nested from 0.1.5 to 0.1.6 Bumps [proc-macro-nested](https://github.com/dtolnay/proc-macro-hack) from 0.1.5 to 0.1.6. - [Release notes](https://github.com/dtolnay/proc-macro-hack/releases) - [Commits](https://github.com/dtolnay/proc-macro-hack/commits) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-14 01:35:13 +00:00
version = "0.1.6"
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump proc-macro-nested from 0.1.5 to 0.1.6 Bumps [proc-macro-nested](https://github.com/dtolnay/proc-macro-hack) from 0.1.5 to 0.1.6. - [Release notes](https://github.com/dtolnay/proc-macro-hack/releases) - [Commits](https://github.com/dtolnay/proc-macro-hack/commits) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-14 01:35:13 +00:00
checksum = "eba180dafb9038b050a4c280019bbedf9f2467b61e5d892dcad585bb57aadc5a"
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
build(deps): bump remain from 0.1.3 to 0.1.4 Bumps [remain](https://github.com/dtolnay/remain) from 0.1.3 to 0.1.4. - [Release notes](https://github.com/dtolnay/remain/releases) - [Commits](https://github.com/dtolnay/remain/compare/0.1.3...0.1.4) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-19 09:50:43 +00:00
[[package]]
name = "proc-macro2"
build(deps): bump proc-macro2 from 1.0.17 to 1.0.18 Bumps [proc-macro2](https://github.com/alexcrichton/proc-macro2) from 1.0.17 to 1.0.18. - [Release notes](https://github.com/alexcrichton/proc-macro2/releases) - [Commits](https://github.com/alexcrichton/proc-macro2/compare/1.0.17...1.0.18) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-31 17:26:09 +00:00
version = "1.0.18"
build(deps): bump remain from 0.1.3 to 0.1.4 Bumps [remain](https://github.com/dtolnay/remain) from 0.1.3 to 0.1.4. - [Release notes](https://github.com/dtolnay/remain/releases) - [Commits](https://github.com/dtolnay/remain/compare/0.1.3...0.1.4) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-19 09:50:43 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump proc-macro2 from 1.0.17 to 1.0.18 Bumps [proc-macro2](https://github.com/alexcrichton/proc-macro2) from 1.0.17 to 1.0.18. - [Release notes](https://github.com/alexcrichton/proc-macro2/releases) - [Commits](https://github.com/alexcrichton/proc-macro2/compare/1.0.17...1.0.18) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-31 17:26:09 +00:00
checksum = "beae6331a816b1f65d04c45b078fd8e6c93e8071771f41b8163255bbd8d7c8fa"
build(deps): bump remain from 0.1.3 to 0.1.4 Bumps [remain](https://github.com/dtolnay/remain) from 0.1.3 to 0.1.4. - [Release notes](https://github.com/dtolnay/remain/releases) - [Commits](https://github.com/dtolnay/remain/compare/0.1.3...0.1.4) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-19 09:50:43 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"unicode-xid 0.2.0",
build(deps): bump remain from 0.1.3 to 0.1.4 Bumps [remain](https://github.com/dtolnay/remain) from 0.1.3 to 0.1.4. - [Release notes](https://github.com/dtolnay/remain/releases) - [Commits](https://github.com/dtolnay/remain/compare/0.1.3...0.1.4) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-19 09:50:43 +00:00
]
qcow: Add qcow support Extracted from crosvm (commit:f82d632), with clippy fixes. Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
2019-04-29 19:32:56 +00:00
[[package]]
name = "qcow"
version = "0.1.0"
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"byteorder",
"libc",
"log 0.4.8",
"remain",
"tempfile",
"vm-virtio",
"vmm-sys-util",
qcow: Add qcow support Extracted from crosvm (commit:f82d632), with clippy fixes. Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
2019-04-29 19:32:56 +00:00
]
build(deps): bump remain from 0.1.3 to 0.1.4 Bumps [remain](https://github.com/dtolnay/remain) from 0.1.3 to 0.1.4. - [Release notes](https://github.com/dtolnay/remain/releases) - [Commits](https://github.com/dtolnay/remain/compare/0.1.3...0.1.4) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-19 09:50:43 +00:00
[[package]]
name = "quote"
build(deps): bump quote from 1.0.6 to 1.0.7 Bumps [quote](https://github.com/dtolnay/quote) from 1.0.6 to 1.0.7. - [Release notes](https://github.com/dtolnay/quote/releases) - [Commits](https://github.com/dtolnay/quote/compare/1.0.6...1.0.7) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-07 18:15:30 +00:00
version = "1.0.7"
build(deps): bump remain from 0.1.3 to 0.1.4 Bumps [remain](https://github.com/dtolnay/remain) from 0.1.3 to 0.1.4. - [Release notes](https://github.com/dtolnay/remain/releases) - [Commits](https://github.com/dtolnay/remain/compare/0.1.3...0.1.4) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-19 09:50:43 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump quote from 1.0.6 to 1.0.7 Bumps [quote](https://github.com/dtolnay/quote) from 1.0.6 to 1.0.7. - [Release notes](https://github.com/dtolnay/quote/releases) - [Commits](https://github.com/dtolnay/quote/compare/1.0.6...1.0.7) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-07 18:15:30 +00:00
checksum = "aa563d17ecb180e500da1cfd2b028310ac758de548efdd203e18f283af693f37"
build(deps): bump remain from 0.1.3 to 0.1.4 Bumps [remain](https://github.com/dtolnay/remain) from 0.1.3 to 0.1.4. - [Release notes](https://github.com/dtolnay/remain/releases) - [Commits](https://github.com/dtolnay/remain/compare/0.1.3...0.1.4) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-19 09:50:43 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"proc-macro2",
build(deps): bump remain from 0.1.3 to 0.1.4 Bumps [remain](https://github.com/dtolnay/remain) from 0.1.3 to 0.1.4. - [Release notes](https://github.com/dtolnay/remain/releases) - [Commits](https://github.com/dtolnay/remain/compare/0.1.3...0.1.4) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-19 09:50:43 +00:00
]
tests: Use a temporary directory for the temporary test files Use the tempdir crate to create a temporary directory that is deleted when the structure goes out of scope. Use this temporary directory for all temporary test files created by the tests. The cloud init file is still in /tmp as that is created by the test wrapper code. This is the first stage towards being able to run the integration tests in parallel. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-18 07:57:01 +00:00
[[package]]
name = "rand"
version = "0.4.6"
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "552840b97013b1a26992c11eac34bdd778e464601a4c2054b5f0bff7c6761293"
tests: Use a temporary directory for the temporary test files Use the tempdir crate to create a temporary directory that is deleted when the structure goes out of scope. Use this temporary directory for all temporary test files created by the tests. The cloud init file is still in /tmp as that is created by the test wrapper code. This is the first stage towards being able to run the integration tests in parallel. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-18 07:57:01 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"fuchsia-cprng",
"libc",
"rand_core 0.3.1",
"rdrand",
"winapi 0.3.8",
tests: Use a temporary directory for the temporary test files Use the tempdir crate to create a temporary directory that is deleted when the structure goes out of scope. Use this temporary directory for all temporary test files created by the tests. The cloud init file is still in /tmp as that is created by the test wrapper code. This is the first stage towards being able to run the integration tests in parallel. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-18 07:57:01 +00:00
]
vm-virtio: Add virtio console device for single port operation The virtio console device is a console for the communication between the host and guest userspace. It has two parts: the device and the driver. The console device is implemented here as a virtio-pci device to the guest. On the other side, the guest OS expected to have a character device driver which provides an interface to the userspace applications. The console device can have multiple ports where each port has one transmit queue and one receive queue. The current implementation only supports one port. For data IO communication, one or more empty buffers are placed in the receive queue for incoming data, and outgoing characters are placed in the transmit queue. Details spec can be found from the following link. https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.pdf#e7 Apart from the console, for the communication between guest and host, the Cloud Hypervisor has a legacy serial device implemented. However, the implementation of a console device lets us be independent of legacy pin-based interrupts without losing the logs and access to the VM. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-22 18:50:56 +00:00
[[package]]
name = "rand"
build(deps): bump rand from 0.7.2 to 0.7.3 Bumps [rand](https://github.com/rust-random/rand) from 0.7.2 to 0.7.3. - [Release notes](https://github.com/rust-random/rand/releases) - [Changelog](https://github.com/rust-random/rand/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-random/rand/commits) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-10 21:54:38 +00:00
version = "0.7.3"
vm-virtio: Add virtio console device for single port operation The virtio console device is a console for the communication between the host and guest userspace. It has two parts: the device and the driver. The console device is implemented here as a virtio-pci device to the guest. On the other side, the guest OS expected to have a character device driver which provides an interface to the userspace applications. The console device can have multiple ports where each port has one transmit queue and one receive queue. The current implementation only supports one port. For data IO communication, one or more empty buffers are placed in the receive queue for incoming data, and outgoing characters are placed in the transmit queue. Details spec can be found from the following link. https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.pdf#e7 Apart from the console, for the communication between guest and host, the Cloud Hypervisor has a legacy serial device implemented. However, the implementation of a console device lets us be independent of legacy pin-based interrupts without losing the logs and access to the VM. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-22 18:50:56 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "6a6b1679d49b24bbfe0c803429aa1874472f50d9b363131f0e89fc356b544d03"
vm-virtio: Add virtio console device for single port operation The virtio console device is a console for the communication between the host and guest userspace. It has two parts: the device and the driver. The console device is implemented here as a virtio-pci device to the guest. On the other side, the guest OS expected to have a character device driver which provides an interface to the userspace applications. The console device can have multiple ports where each port has one transmit queue and one receive queue. The current implementation only supports one port. For data IO communication, one or more empty buffers are placed in the receive queue for incoming data, and outgoing characters are placed in the transmit queue. Details spec can be found from the following link. https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.pdf#e7 Apart from the console, for the communication between guest and host, the Cloud Hypervisor has a legacy serial device implemented. However, the implementation of a console device lets us be independent of legacy pin-based interrupts without losing the logs and access to the VM. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-22 18:50:56 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"getrandom",
"libc",
"rand_chacha",
"rand_core 0.5.1",
"rand_hc",
vm-virtio: Add virtio console device for single port operation The virtio console device is a console for the communication between the host and guest userspace. It has two parts: the device and the driver. The console device is implemented here as a virtio-pci device to the guest. On the other side, the guest OS expected to have a character device driver which provides an interface to the userspace applications. The console device can have multiple ports where each port has one transmit queue and one receive queue. The current implementation only supports one port. For data IO communication, one or more empty buffers are placed in the receive queue for incoming data, and outgoing characters are placed in the transmit queue. Details spec can be found from the following link. https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.pdf#e7 Apart from the console, for the communication between guest and host, the Cloud Hypervisor has a legacy serial device implemented. However, the implementation of a console device lets us be independent of legacy pin-based interrupts without losing the logs and access to the VM. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-22 18:50:56 +00:00
]
[[package]]
name = "rand_chacha"
build(deps): bump rand_chacha from 0.2.1 to 0.2.2 Bumps [rand_chacha](https://github.com/rust-random/rand) from 0.2.1 to 0.2.2. - [Release notes](https://github.com/rust-random/rand/releases) - [Changelog](https://github.com/rust-random/rand/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-random/rand/compare/rand_chacha-0.2.1...rand_chacha-0.2.2) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-03-10 10:54:26 +00:00
version = "0.2.2"
vm-virtio: Add virtio console device for single port operation The virtio console device is a console for the communication between the host and guest userspace. It has two parts: the device and the driver. The console device is implemented here as a virtio-pci device to the guest. On the other side, the guest OS expected to have a character device driver which provides an interface to the userspace applications. The console device can have multiple ports where each port has one transmit queue and one receive queue. The current implementation only supports one port. For data IO communication, one or more empty buffers are placed in the receive queue for incoming data, and outgoing characters are placed in the transmit queue. Details spec can be found from the following link. https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.pdf#e7 Apart from the console, for the communication between guest and host, the Cloud Hypervisor has a legacy serial device implemented. However, the implementation of a console device lets us be independent of legacy pin-based interrupts without losing the logs and access to the VM. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-22 18:50:56 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "f4c8ed856279c9737206bf725bf36935d8666ead7aa69b52be55af369d193402"
vm-virtio: Add virtio console device for single port operation The virtio console device is a console for the communication between the host and guest userspace. It has two parts: the device and the driver. The console device is implemented here as a virtio-pci device to the guest. On the other side, the guest OS expected to have a character device driver which provides an interface to the userspace applications. The console device can have multiple ports where each port has one transmit queue and one receive queue. The current implementation only supports one port. For data IO communication, one or more empty buffers are placed in the receive queue for incoming data, and outgoing characters are placed in the transmit queue. Details spec can be found from the following link. https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.pdf#e7 Apart from the console, for the communication between guest and host, the Cloud Hypervisor has a legacy serial device implemented. However, the implementation of a console device lets us be independent of legacy pin-based interrupts without losing the logs and access to the VM. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-22 18:50:56 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"ppv-lite86",
"rand_core 0.5.1",
vm-virtio: Add virtio console device for single port operation The virtio console device is a console for the communication between the host and guest userspace. It has two parts: the device and the driver. The console device is implemented here as a virtio-pci device to the guest. On the other side, the guest OS expected to have a character device driver which provides an interface to the userspace applications. The console device can have multiple ports where each port has one transmit queue and one receive queue. The current implementation only supports one port. For data IO communication, one or more empty buffers are placed in the receive queue for incoming data, and outgoing characters are placed in the transmit queue. Details spec can be found from the following link. https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.pdf#e7 Apart from the console, for the communication between guest and host, the Cloud Hypervisor has a legacy serial device implemented. However, the implementation of a console device lets us be independent of legacy pin-based interrupts without losing the logs and access to the VM. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-22 18:50:56 +00:00
]
vmm: Use virtio-blk to support booting from disk image After the virtio-blk device support has been introduced in the previous commit, the vmm need to rely on this new device to boot from disk images instead of initrd built into the kernel. In order to achieve the proper support of virtio-blk, this commit had to handle a few things: - Register an ioevent fd for each virtqueue. This important to be notified from the virtio driver that something has been written on the queue. - Fix the retrieval of 64bits BAR address. This is needed to provide the right address which need to be registered as the notification address from the virtio driver. - Fix the write_bar and read_bar functions. They were both assuming to be provided with an address, from which they were trying to find the associated offset. But the reality is that the offset is directly provided by the Bus layer. - Register a new virtio-blk device as a virtio-pci device from the vm.rs code. When the VM is started, it expects a block device to be created, using this block device as the VM rootfs. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-05-06 17:27:40 +00:00
[[package]]
name = "rand_core"
version = "0.3.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "7a6fdeb83b075e8266dcc8762c22776f6877a63111121f5f8c7411e5be7eed4b"
vmm: Use virtio-blk to support booting from disk image After the virtio-blk device support has been introduced in the previous commit, the vmm need to rely on this new device to boot from disk images instead of initrd built into the kernel. In order to achieve the proper support of virtio-blk, this commit had to handle a few things: - Register an ioevent fd for each virtqueue. This important to be notified from the virtio driver that something has been written on the queue. - Fix the retrieval of 64bits BAR address. This is needed to provide the right address which need to be registered as the notification address from the virtio driver. - Fix the write_bar and read_bar functions. They were both assuming to be provided with an address, from which they were trying to find the associated offset. But the reality is that the offset is directly provided by the Bus layer. - Register a new virtio-blk device as a virtio-pci device from the vm.rs code. When the VM is started, it expects a block device to be created, using this block device as the VM rootfs. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-05-06 17:27:40 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"rand_core 0.4.2",
vmm: Use virtio-blk to support booting from disk image After the virtio-blk device support has been introduced in the previous commit, the vmm need to rely on this new device to boot from disk images instead of initrd built into the kernel. In order to achieve the proper support of virtio-blk, this commit had to handle a few things: - Register an ioevent fd for each virtqueue. This important to be notified from the virtio driver that something has been written on the queue. - Fix the retrieval of 64bits BAR address. This is needed to provide the right address which need to be registered as the notification address from the virtio driver. - Fix the write_bar and read_bar functions. They were both assuming to be provided with an address, from which they were trying to find the associated offset. But the reality is that the offset is directly provided by the Bus layer. - Register a new virtio-blk device as a virtio-pci device from the vm.rs code. When the VM is started, it expects a block device to be created, using this block device as the VM rootfs. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-05-06 17:27:40 +00:00
]
[[package]]
name = "rand_core"
vm-virtio: Implement console size config feature One of the features of the virtio console device is its size can be configured and updated. Our first iteration of the console device implementation is lack of this feature. As a result, it had a default fixed size which could not be changed. This commit implements the console config feature and lets us change the console size from the vmm side. During the activation of the device, vmm reads the current terminal size, sets the console configuration accordinly, and lets the driver know about this configuration by sending an interrupt. Later, if someone changes the terminal size, the vmm detects the corresponding event, updates the configuration, and sends interrupt as before. As a result, the console device driver, in the guest, updates the console size. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-23 19:18:20 +00:00
version = "0.4.2"
vmm: Use virtio-blk to support booting from disk image After the virtio-blk device support has been introduced in the previous commit, the vmm need to rely on this new device to boot from disk images instead of initrd built into the kernel. In order to achieve the proper support of virtio-blk, this commit had to handle a few things: - Register an ioevent fd for each virtqueue. This important to be notified from the virtio driver that something has been written on the queue. - Fix the retrieval of 64bits BAR address. This is needed to provide the right address which need to be registered as the notification address from the virtio driver. - Fix the write_bar and read_bar functions. They were both assuming to be provided with an address, from which they were trying to find the associated offset. But the reality is that the offset is directly provided by the Bus layer. - Register a new virtio-blk device as a virtio-pci device from the vm.rs code. When the VM is started, it expects a block device to be created, using this block device as the VM rootfs. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-05-06 17:27:40 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "9c33a3c44ca05fa6f1807d8e6743f3824e8509beca625669633be0acbdf509dc"
vmm: Use virtio-blk to support booting from disk image After the virtio-blk device support has been introduced in the previous commit, the vmm need to rely on this new device to boot from disk images instead of initrd built into the kernel. In order to achieve the proper support of virtio-blk, this commit had to handle a few things: - Register an ioevent fd for each virtqueue. This important to be notified from the virtio driver that something has been written on the queue. - Fix the retrieval of 64bits BAR address. This is needed to provide the right address which need to be registered as the notification address from the virtio driver. - Fix the write_bar and read_bar functions. They were both assuming to be provided with an address, from which they were trying to find the associated offset. But the reality is that the offset is directly provided by the Bus layer. - Register a new virtio-blk device as a virtio-pci device from the vm.rs code. When the VM is started, it expects a block device to be created, using this block device as the VM rootfs. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-05-06 17:27:40 +00:00
vm-virtio: Add virtio console device for single port operation The virtio console device is a console for the communication between the host and guest userspace. It has two parts: the device and the driver. The console device is implemented here as a virtio-pci device to the guest. On the other side, the guest OS expected to have a character device driver which provides an interface to the userspace applications. The console device can have multiple ports where each port has one transmit queue and one receive queue. The current implementation only supports one port. For data IO communication, one or more empty buffers are placed in the receive queue for incoming data, and outgoing characters are placed in the transmit queue. Details spec can be found from the following link. https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.pdf#e7 Apart from the console, for the communication between guest and host, the Cloud Hypervisor has a legacy serial device implemented. However, the implementation of a console device lets us be independent of legacy pin-based interrupts without losing the logs and access to the VM. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-22 18:50:56 +00:00
[[package]]
name = "rand_core"
build(deps): bump rand from 0.7.0 to 0.7.2 Bumps [rand](https://github.com/rust-random/rand) from 0.7.0 to 0.7.2. - [Release notes](https://github.com/rust-random/rand/releases) - [Changelog](https://github.com/rust-random/rand/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-random/rand/compare/0.7.0...0.7.2) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-06 07:55:25 +00:00
version = "0.5.1"
vm-virtio: Add virtio console device for single port operation The virtio console device is a console for the communication between the host and guest userspace. It has two parts: the device and the driver. The console device is implemented here as a virtio-pci device to the guest. On the other side, the guest OS expected to have a character device driver which provides an interface to the userspace applications. The console device can have multiple ports where each port has one transmit queue and one receive queue. The current implementation only supports one port. For data IO communication, one or more empty buffers are placed in the receive queue for incoming data, and outgoing characters are placed in the transmit queue. Details spec can be found from the following link. https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.pdf#e7 Apart from the console, for the communication between guest and host, the Cloud Hypervisor has a legacy serial device implemented. However, the implementation of a console device lets us be independent of legacy pin-based interrupts without losing the logs and access to the VM. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-22 18:50:56 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "90bde5296fc891b0cef12a6d03ddccc162ce7b2aff54160af9338f8d40df6d19"
vm-virtio: Add virtio console device for single port operation The virtio console device is a console for the communication between the host and guest userspace. It has two parts: the device and the driver. The console device is implemented here as a virtio-pci device to the guest. On the other side, the guest OS expected to have a character device driver which provides an interface to the userspace applications. The console device can have multiple ports where each port has one transmit queue and one receive queue. The current implementation only supports one port. For data IO communication, one or more empty buffers are placed in the receive queue for incoming data, and outgoing characters are placed in the transmit queue. Details spec can be found from the following link. https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.pdf#e7 Apart from the console, for the communication between guest and host, the Cloud Hypervisor has a legacy serial device implemented. However, the implementation of a console device lets us be independent of legacy pin-based interrupts without losing the logs and access to the VM. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-22 18:50:56 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"getrandom",
vm-virtio: Add virtio console device for single port operation The virtio console device is a console for the communication between the host and guest userspace. It has two parts: the device and the driver. The console device is implemented here as a virtio-pci device to the guest. On the other side, the guest OS expected to have a character device driver which provides an interface to the userspace applications. The console device can have multiple ports where each port has one transmit queue and one receive queue. The current implementation only supports one port. For data IO communication, one or more empty buffers are placed in the receive queue for incoming data, and outgoing characters are placed in the transmit queue. Details spec can be found from the following link. https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.pdf#e7 Apart from the console, for the communication between guest and host, the Cloud Hypervisor has a legacy serial device implemented. However, the implementation of a console device lets us be independent of legacy pin-based interrupts without losing the logs and access to the VM. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-22 18:50:56 +00:00
]
[[package]]
name = "rand_hc"
version = "0.2.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "ca3129af7b92a17112d59ad498c6f81eaf463253766b90396d39ea7a39d6613c"
vm-virtio: Add virtio console device for single port operation The virtio console device is a console for the communication between the host and guest userspace. It has two parts: the device and the driver. The console device is implemented here as a virtio-pci device to the guest. On the other side, the guest OS expected to have a character device driver which provides an interface to the userspace applications. The console device can have multiple ports where each port has one transmit queue and one receive queue. The current implementation only supports one port. For data IO communication, one or more empty buffers are placed in the receive queue for incoming data, and outgoing characters are placed in the transmit queue. Details spec can be found from the following link. https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.pdf#e7 Apart from the console, for the communication between guest and host, the Cloud Hypervisor has a legacy serial device implemented. However, the implementation of a console device lets us be independent of legacy pin-based interrupts without losing the logs and access to the VM. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-22 18:50:56 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"rand_core 0.5.1",
vm-virtio: Add virtio console device for single port operation The virtio console device is a console for the communication between the host and guest userspace. It has two parts: the device and the driver. The console device is implemented here as a virtio-pci device to the guest. On the other side, the guest OS expected to have a character device driver which provides an interface to the userspace applications. The console device can have multiple ports where each port has one transmit queue and one receive queue. The current implementation only supports one port. For data IO communication, one or more empty buffers are placed in the receive queue for incoming data, and outgoing characters are placed in the transmit queue. Details spec can be found from the following link. https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.pdf#e7 Apart from the console, for the communication between guest and host, the Cloud Hypervisor has a legacy serial device implemented. However, the implementation of a console device lets us be independent of legacy pin-based interrupts without losing the logs and access to the VM. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-22 18:50:56 +00:00
]
vmm: Use virtio-blk to support booting from disk image After the virtio-blk device support has been introduced in the previous commit, the vmm need to rely on this new device to boot from disk images instead of initrd built into the kernel. In order to achieve the proper support of virtio-blk, this commit had to handle a few things: - Register an ioevent fd for each virtqueue. This important to be notified from the virtio driver that something has been written on the queue. - Fix the retrieval of 64bits BAR address. This is needed to provide the right address which need to be registered as the notification address from the virtio driver. - Fix the write_bar and read_bar functions. They were both assuming to be provided with an address, from which they were trying to find the associated offset. But the reality is that the offset is directly provided by the Bus layer. - Register a new virtio-blk device as a virtio-pci device from the vm.rs code. When the VM is started, it expects a block device to be created, using this block device as the VM rootfs. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-05-06 17:27:40 +00:00
[[package]]
name = "rdrand"
version = "0.4.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "678054eb77286b51581ba43620cc911abf02758c91f93f479767aed0f90458b2"
vmm: Use virtio-blk to support booting from disk image After the virtio-blk device support has been introduced in the previous commit, the vmm need to rely on this new device to boot from disk images instead of initrd built into the kernel. In order to achieve the proper support of virtio-blk, this commit had to handle a few things: - Register an ioevent fd for each virtqueue. This important to be notified from the virtio driver that something has been written on the queue. - Fix the retrieval of 64bits BAR address. This is needed to provide the right address which need to be registered as the notification address from the virtio driver. - Fix the write_bar and read_bar functions. They were both assuming to be provided with an address, from which they were trying to find the associated offset. But the reality is that the offset is directly provided by the Bus layer. - Register a new virtio-blk device as a virtio-pci device from the vm.rs code. When the VM is started, it expects a block device to be created, using this block device as the VM rootfs. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-05-06 17:27:40 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"rand_core 0.3.1",
vmm: Use virtio-blk to support booting from disk image After the virtio-blk device support has been introduced in the previous commit, the vmm need to rely on this new device to boot from disk images instead of initrd built into the kernel. In order to achieve the proper support of virtio-blk, this commit had to handle a few things: - Register an ioevent fd for each virtqueue. This important to be notified from the virtio driver that something has been written on the queue. - Fix the retrieval of 64bits BAR address. This is needed to provide the right address which need to be registered as the notification address from the virtio driver. - Fix the write_bar and read_bar functions. They were both assuming to be provided with an address, from which they were trying to find the associated offset. But the reality is that the offset is directly provided by the Bus layer. - Register a new virtio-blk device as a virtio-pci device from the vm.rs code. When the VM is started, it expects a block device to be created, using this block device as the VM rootfs. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-05-06 17:27:40 +00:00
]
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
[[package]]
name = "redox_syscall"
vm-virtio: Add virtio console device for single port operation The virtio console device is a console for the communication between the host and guest userspace. It has two parts: the device and the driver. The console device is implemented here as a virtio-pci device to the guest. On the other side, the guest OS expected to have a character device driver which provides an interface to the userspace applications. The console device can have multiple ports where each port has one transmit queue and one receive queue. The current implementation only supports one port. For data IO communication, one or more empty buffers are placed in the receive queue for incoming data, and outgoing characters are placed in the transmit queue. Details spec can be found from the following link. https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.pdf#e7 Apart from the console, for the communication between guest and host, the Cloud Hypervisor has a legacy serial device implemented. However, the implementation of a console device lets us be independent of legacy pin-based interrupts without losing the logs and access to the VM. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-22 18:50:56 +00:00
version = "0.1.56"
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "2439c63f3f6139d1b57529d16bc3b8bb855230c8efcc5d3a896c8bea7c3b1e84"
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
[[package]]
name = "redox_users"
build(deps): bump redox_users from 0.3.3 to 0.3.4 Bumps redox_users from 0.3.3 to 0.3.4. Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-22 00:35:06 +00:00
version = "0.3.4"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "09b23093265f8d200fa7b4c2c76297f47e681c655f6f1285a8780d6a022f7431"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"getrandom",
"redox_syscall",
"rust-argon2",
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
]
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
[[package]]
name = "regex"
build(deps): bump regex from 1.3.8 to 1.3.9 Bumps [regex](https://github.com/rust-lang/regex) from 1.3.8 to 1.3.9. - [Release notes](https://github.com/rust-lang/regex/releases) - [Changelog](https://github.com/rust-lang/regex/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/regex/compare/1.3.8...1.3.9) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-29 00:25:01 +00:00
version = "1.3.9"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump regex from 1.3.8 to 1.3.9 Bumps [regex](https://github.com/rust-lang/regex) from 1.3.8 to 1.3.9. - [Release notes](https://github.com/rust-lang/regex/releases) - [Changelog](https://github.com/rust-lang/regex/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/regex/compare/1.3.8...1.3.9) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-29 00:25:01 +00:00
checksum = "9c3780fcf44b193bc4d09f36d2a3c87b251da4a046c87795a0d35f4f927ad8e6"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"aho-corasick",
"memchr",
"regex-syntax",
"thread_local",
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
]
[[package]]
name = "regex-syntax"
build(deps): bump regex from 1.3.7 to 1.3.8 Bumps [regex](https://github.com/rust-lang/regex) from 1.3.7 to 1.3.8. - [Release notes](https://github.com/rust-lang/regex/releases) - [Changelog](https://github.com/rust-lang/regex/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/regex/compare/regex-1.3.7...1.3.8) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-28 15:35:21 +00:00
version = "0.6.18"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump regex from 1.3.7 to 1.3.8 Bumps [regex](https://github.com/rust-lang/regex) from 1.3.7 to 1.3.8. - [Release notes](https://github.com/rust-lang/regex/releases) - [Changelog](https://github.com/rust-lang/regex/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/regex/compare/regex-1.3.7...1.3.8) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-28 15:35:21 +00:00
checksum = "26412eb97c6b088a6997e05f69403a802a92d520de2f8e63c2b65f9e0f47c4e8"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
qcow: Add qcow support Extracted from crosvm (commit:f82d632), with clippy fixes. Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
2019-04-29 19:32:56 +00:00
[[package]]
name = "remain"
build(deps): bump remain from 0.2.1 to 0.2.2 Bumps [remain](https://github.com/dtolnay/remain) from 0.2.1 to 0.2.2. - [Release notes](https://github.com/dtolnay/remain/releases) - [Commits](https://github.com/dtolnay/remain/compare/0.2.1...0.2.2) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-16 18:45:06 +00:00
version = "0.2.2"
qcow: Add qcow support Extracted from crosvm (commit:f82d632), with clippy fixes. Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
2019-04-29 19:32:56 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump remain from 0.2.1 to 0.2.2 Bumps [remain](https://github.com/dtolnay/remain) from 0.2.1 to 0.2.2. - [Release notes](https://github.com/dtolnay/remain/releases) - [Commits](https://github.com/dtolnay/remain/compare/0.2.1...0.2.2) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-16 18:45:06 +00:00
checksum = "70ba1e78fa68412cb93ef642fd4d20b9a941be49ee9333875ebaf13112673ea7"
qcow: Add qcow support Extracted from crosvm (commit:f82d632), with clippy fixes. Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
2019-04-29 19:32:56 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"proc-macro2",
"quote",
"syn",
qcow: Add qcow support Extracted from crosvm (commit:f82d632), with clippy fixes. Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
2019-04-29 19:32:56 +00:00
]
vmm: Use virtio-blk to support booting from disk image After the virtio-blk device support has been introduced in the previous commit, the vmm need to rely on this new device to boot from disk images instead of initrd built into the kernel. In order to achieve the proper support of virtio-blk, this commit had to handle a few things: - Register an ioevent fd for each virtqueue. This important to be notified from the virtio driver that something has been written on the queue. - Fix the retrieval of 64bits BAR address. This is needed to provide the right address which need to be registered as the notification address from the virtio driver. - Fix the write_bar and read_bar functions. They were both assuming to be provided with an address, from which they were trying to find the associated offset. But the reality is that the offset is directly provided by the Bus layer. - Register a new virtio-blk device as a virtio-pci device from the vm.rs code. When the VM is started, it expects a block device to be created, using this block device as the VM rootfs. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-05-06 17:27:40 +00:00
[[package]]
name = "remove_dir_all"
build(deps): bump remove_dir_all from 0.5.2 to 0.5.3 Bumps [remove_dir_all](https://github.com/XAMPPRocky/remove_dir_all) from 0.5.2 to 0.5.3. - [Release notes](https://github.com/XAMPPRocky/remove_dir_all/releases) - [Changelog](https://github.com/XAMPPRocky/remove_dir_all/blob/master/CHANGELOG.md) - [Commits](https://github.com/XAMPPRocky/remove_dir_all/compare/v0.5.2...remove_dir_all@0.5.3) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-12 16:34:25 +00:00
version = "0.5.3"
vmm: Use virtio-blk to support booting from disk image After the virtio-blk device support has been introduced in the previous commit, the vmm need to rely on this new device to boot from disk images instead of initrd built into the kernel. In order to achieve the proper support of virtio-blk, this commit had to handle a few things: - Register an ioevent fd for each virtqueue. This important to be notified from the virtio driver that something has been written on the queue. - Fix the retrieval of 64bits BAR address. This is needed to provide the right address which need to be registered as the notification address from the virtio driver. - Fix the write_bar and read_bar functions. They were both assuming to be provided with an address, from which they were trying to find the associated offset. But the reality is that the offset is directly provided by the Bus layer. - Register a new virtio-blk device as a virtio-pci device from the vm.rs code. When the VM is started, it expects a block device to be created, using this block device as the VM rootfs. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-05-06 17:27:40 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump remove_dir_all from 0.5.2 to 0.5.3 Bumps [remove_dir_all](https://github.com/XAMPPRocky/remove_dir_all) from 0.5.2 to 0.5.3. - [Release notes](https://github.com/XAMPPRocky/remove_dir_all/releases) - [Changelog](https://github.com/XAMPPRocky/remove_dir_all/blob/master/CHANGELOG.md) - [Commits](https://github.com/XAMPPRocky/remove_dir_all/compare/v0.5.2...remove_dir_all@0.5.3) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-12 16:34:25 +00:00
checksum = "3acd125665422973a33ac9d3dd2df85edad0f4ae9b00dafb1a05e43a9f5ef8e7"
vmm: Use virtio-blk to support booting from disk image After the virtio-blk device support has been introduced in the previous commit, the vmm need to rely on this new device to boot from disk images instead of initrd built into the kernel. In order to achieve the proper support of virtio-blk, this commit had to handle a few things: - Register an ioevent fd for each virtqueue. This important to be notified from the virtio driver that something has been written on the queue. - Fix the retrieval of 64bits BAR address. This is needed to provide the right address which need to be registered as the notification address from the virtio driver. - Fix the write_bar and read_bar functions. They were both assuming to be provided with an address, from which they were trying to find the associated offset. But the reality is that the offset is directly provided by the Bus layer. - Register a new virtio-blk device as a virtio-pci device from the vm.rs code. When the VM is started, it expects a block device to be created, using this block device as the VM rootfs. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-05-06 17:27:40 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"winapi 0.3.8",
vmm: Use virtio-blk to support booting from disk image After the virtio-blk device support has been introduced in the previous commit, the vmm need to rely on this new device to boot from disk images instead of initrd built into the kernel. In order to achieve the proper support of virtio-blk, this commit had to handle a few things: - Register an ioevent fd for each virtqueue. This important to be notified from the virtio driver that something has been written on the queue. - Fix the retrieval of 64bits BAR address. This is needed to provide the right address which need to be registered as the notification address from the virtio driver. - Fix the write_bar and read_bar functions. They were both assuming to be provided with an address, from which they were trying to find the associated offset. But the reality is that the offset is directly provided by the Bus layer. - Register a new virtio-blk device as a virtio-pci device from the vm.rs code. When the VM is started, it expects a block device to be created, using this block device as the VM rootfs. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-05-06 17:27:40 +00:00
]
build(deps): bump redox_users from 0.3.0 to 0.3.1 Bumps redox_users from 0.3.0 to 0.3.1. Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-08 06:53:19 +00:00
[[package]]
name = "rust-argon2"
build(deps): bump redox_users from 0.3.3 to 0.3.4 Bumps redox_users from 0.3.3 to 0.3.4. Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-22 00:35:06 +00:00
version = "0.7.0"
build(deps): bump redox_users from 0.3.0 to 0.3.1 Bumps redox_users from 0.3.0 to 0.3.1. Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-08 06:53:19 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "2bc8af4bda8e1ff4932523b94d3dd20ee30a87232323eda55903ffd71d2fb017"
build(deps): bump redox_users from 0.3.0 to 0.3.1 Bumps redox_users from 0.3.0 to 0.3.1. Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-08 06:53:19 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"base64",
"blake2b_simd",
"constant_time_eq",
"crossbeam-utils",
build(deps): bump redox_users from 0.3.0 to 0.3.1 Bumps redox_users from 0.3.0 to 0.3.1. Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-08 06:53:19 +00:00
]
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
[[package]]
name = "rustc-demangle"
build(deps): bump rustc-demangle from 0.1.15 to 0.1.16 Bumps [rustc-demangle](https://github.com/alexcrichton/rustc-demangle) from 0.1.15 to 0.1.16. - [Release notes](https://github.com/alexcrichton/rustc-demangle/releases) - [Commits](https://github.com/alexcrichton/rustc-demangle/compare/0.1.15...0.1.16) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-14 07:18:12 +00:00
version = "0.1.16"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "4c691c0e608126e00913e33f0ccf3727d5fc84573623b8d65b2df340b5201783"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
[[package]]
name = "rustc-serialize"
version = "0.3.24"
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "dcf128d1287d2ea9d80910b5f1120d0b8eede3fbf1abe91c40d39ea7d51e6fda"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
[[package]]
name = "ryu"
build(deps): bump ryu from 1.0.4 to 1.0.5 Bumps [ryu](https://github.com/dtolnay/ryu) from 1.0.4 to 1.0.5. - [Release notes](https://github.com/dtolnay/ryu/releases) - [Commits](https://github.com/dtolnay/ryu/compare/1.0.4...1.0.5) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-31 17:07:04 +00:00
version = "1.0.5"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump ryu from 1.0.4 to 1.0.5 Bumps [ryu](https://github.com/dtolnay/ryu) from 1.0.4 to 1.0.5. - [Release notes](https://github.com/dtolnay/ryu/releases) - [Commits](https://github.com/dtolnay/ryu/compare/1.0.4...1.0.5) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-31 17:07:04 +00:00
checksum = "71d301d4193d031abdd79ff7e3dd721168a9572ef3fe51a1517aba235bd8f86e"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
build(deps): bump ssh2 from 0.6.0 to 0.7.1 Bumps [ssh2](https://github.com/alexcrichton/ssh2-rs) from 0.6.0 to 0.7.1. - [Release notes](https://github.com/alexcrichton/ssh2-rs/releases) - [Commits](https://github.com/alexcrichton/ssh2-rs/compare/0.6.0...0.7.1) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-25 22:43:45 +00:00
[[package]]
name = "scopeguard"
build(deps): bump scopeguard from 1.0.0 to 1.1.0 Bumps [scopeguard](https://github.com/bluss/scopeguard) from 1.0.0 to 1.1.0. - [Release notes](https://github.com/bluss/scopeguard/releases) - [Commits](https://github.com/bluss/scopeguard/compare/1.0.0...v1.1.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-02-16 23:05:44 +00:00
version = "1.1.0"
build(deps): bump ssh2 from 0.6.0 to 0.7.1 Bumps [ssh2](https://github.com/alexcrichton/ssh2-rs) from 0.6.0 to 0.7.1. - [Release notes](https://github.com/alexcrichton/ssh2-rs/releases) - [Commits](https://github.com/alexcrichton/ssh2-rs/compare/0.6.0...0.7.1) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-25 22:43:45 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "d29ab0c6d3fc0ee92fe66e2d99f700eab17a8d57d1c1d3b748380fb20baa78cd"
build(deps): bump ssh2 from 0.6.0 to 0.7.1 Bumps [ssh2](https://github.com/alexcrichton/ssh2-rs) from 0.6.0 to 0.7.1. - [Release notes](https://github.com/alexcrichton/ssh2-rs/releases) - [Commits](https://github.com/alexcrichton/ssh2-rs/compare/0.6.0...0.7.1) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-25 22:43:45 +00:00
vmm: Pull seccomp crate from Firecracker The seccomp crate from Firecracker is nicely implemented, documented and tested, which is a good reason for relying on it to create and apply seccomp filters. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2020-03-19 10:49:13 +00:00
[[package]]
name = "seccomp"
version = "0.1.0"
source = "git+https://github.com/firecracker-microvm/firecracker?tag=v0.21.1#047a379eb041f9ceae35df5fa072d88cac55340e"
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"libc",
vmm: Pull seccomp crate from Firecracker The seccomp crate from Firecracker is nicely implemented, documented and tested, which is a good reason for relying on it to create and apply seccomp filters. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2020-03-19 10:49:13 +00:00
]
network: Add virtio-net dependencies The newly added virtio-net implementation needs to interact with TAP interfaces and MAC addresses, which is the reason why it is easier to rely on existing packages net_util and net_gen. One more thing, both net_util and net_gen could be trimmed down, based on using only the things we need from cloud-hypervisor. Both net_util, net_gen and sys_util are based on Firecracker commit d4a89cdc0bd2867f821e3678328dabad6dd8b767. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-05-08 05:28:02 +00:00
[[package]]
name = "serde"
build(deps): bump serde from 1.0.113 to 1.0.114 Bumps [serde](https://github.com/serde-rs/serde) from 1.0.113 to 1.0.114. - [Release notes](https://github.com/serde-rs/serde/releases) - [Commits](https://github.com/serde-rs/serde/compare/v1.0.113...v1.0.114) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-22 05:20:34 +00:00
version = "1.0.114"
network: Add virtio-net dependencies The newly added virtio-net implementation needs to interact with TAP interfaces and MAC addresses, which is the reason why it is easier to rely on existing packages net_util and net_gen. One more thing, both net_util and net_gen could be trimmed down, based on using only the things we need from cloud-hypervisor. Both net_util, net_gen and sys_util are based on Firecracker commit d4a89cdc0bd2867f821e3678328dabad6dd8b767. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-05-08 05:28:02 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump serde from 1.0.113 to 1.0.114 Bumps [serde](https://github.com/serde-rs/serde) from 1.0.113 to 1.0.114. - [Release notes](https://github.com/serde-rs/serde/releases) - [Commits](https://github.com/serde-rs/serde/compare/v1.0.113...v1.0.114) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-22 05:20:34 +00:00
checksum = "5317f7588f0a5078ee60ef675ef96735a1442132dc645eb1d12c018620ed8cd3"
network: Add virtio-net dependencies The newly added virtio-net implementation needs to interact with TAP interfaces and MAC addresses, which is the reason why it is easier to rely on existing packages net_util and net_gen. One more thing, both net_util and net_gen could be trimmed down, based on using only the things we need from cloud-hypervisor. Both net_util, net_gen and sys_util are based on Firecracker commit d4a89cdc0bd2867f821e3678328dabad6dd8b767. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-05-08 05:28:02 +00:00
vmm: {De}serialize VmConfig We use the serde crate to serialize and deserialize the VmVConfig structure. This structure will be passed from the HTTP API caller as a JSON payload and we need to deserialize it into a VmConfig. For a convenient use of the HTTP API, we also provide Default traits implementations for some of the VmConfig fields (vCPUs, memory, etc...). Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-09-27 09:40:50 +00:00
[[package]]
name = "serde_derive"
build(deps): bump serde_derive from 1.0.113 to 1.0.114 Bumps [serde_derive](https://github.com/serde-rs/serde) from 1.0.113 to 1.0.114. - [Release notes](https://github.com/serde-rs/serde/releases) - [Commits](https://github.com/serde-rs/serde/compare/v1.0.113...v1.0.114) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-22 00:44:01 +00:00
version = "1.0.114"
vmm: {De}serialize VmConfig We use the serde crate to serialize and deserialize the VmVConfig structure. This structure will be passed from the HTTP API caller as a JSON payload and we need to deserialize it into a VmConfig. For a convenient use of the HTTP API, we also provide Default traits implementations for some of the VmConfig fields (vCPUs, memory, etc...). Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-09-27 09:40:50 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump serde_derive from 1.0.113 to 1.0.114 Bumps [serde_derive](https://github.com/serde-rs/serde) from 1.0.113 to 1.0.114. - [Release notes](https://github.com/serde-rs/serde/releases) - [Commits](https://github.com/serde-rs/serde/compare/v1.0.113...v1.0.114) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-22 00:44:01 +00:00
checksum = "2a0be94b04690fbaed37cddffc5c134bf537c8e3329d53e982fe04c374978f8e"
vmm: {De}serialize VmConfig We use the serde crate to serialize and deserialize the VmVConfig structure. This structure will be passed from the HTTP API caller as a JSON payload and we need to deserialize it into a VmConfig. For a convenient use of the HTTP API, we also provide Default traits implementations for some of the VmConfig fields (vCPUs, memory, etc...). Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-09-27 09:40:50 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"proc-macro2",
"quote",
"syn",
vmm: {De}serialize VmConfig We use the serde crate to serialize and deserialize the VmVConfig structure. This structure will be passed from the HTTP API caller as a JSON payload and we need to deserialize it into a VmConfig. For a convenient use of the HTTP API, we also provide Default traits implementations for some of the VmConfig fields (vCPUs, memory, etc...). Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-09-27 09:40:50 +00:00
]
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
[[package]]
name = "serde_json"
build(deps): bump serde_json from 1.0.54 to 1.0.55 Bumps [serde_json](https://github.com/serde-rs/json) from 1.0.54 to 1.0.55. - [Release notes](https://github.com/serde-rs/json/releases) - [Commits](https://github.com/serde-rs/json/compare/v1.0.54...v1.0.55) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-10 09:29:45 +00:00
version = "1.0.55"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump serde_json from 1.0.54 to 1.0.55 Bumps [serde_json](https://github.com/serde-rs/json) from 1.0.54 to 1.0.55. - [Release notes](https://github.com/serde-rs/json/releases) - [Commits](https://github.com/serde-rs/json/compare/v1.0.54...v1.0.55) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-10 09:29:45 +00:00
checksum = "ec2c5d7e739bc07a3e73381a39d61fdb5f671c60c1df26a130690665803d8226"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"itoa",
"ryu",
"serde",
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
]
vm-virtio: Implement console size config feature One of the features of the virtio console device is its size can be configured and updated. Our first iteration of the console device implementation is lack of this feature. As a result, it had a default fixed size which could not be changed. This commit implements the console config feature and lets us change the console size from the vmm side. During the activation of the device, vmm reads the current terminal size, sets the console configuration accordinly, and lets the driver know about this configuration by sending an interrupt. Later, if someone changes the terminal size, the vmm detects the corresponding event, updates the configuration, and sends interrupt as before. As a result, the console device driver, in the guest, updates the console size. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-23 19:18:20 +00:00
[[package]]
name = "signal-hook"
build(deps): bump signal-hook from 0.1.14 to 0.1.15 Bumps [signal-hook](https://github.com/vorner/signal-hook) from 0.1.14 to 0.1.15. - [Release notes](https://github.com/vorner/signal-hook/releases) - [Changelog](https://github.com/vorner/signal-hook/blob/master/CHANGELOG.md) - [Commits](https://github.com/vorner/signal-hook/compare/v0.1.14...v0.1.15) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-11 17:49:36 +00:00
version = "0.1.15"
vm-virtio: Implement console size config feature One of the features of the virtio console device is its size can be configured and updated. Our first iteration of the console device implementation is lack of this feature. As a result, it had a default fixed size which could not be changed. This commit implements the console config feature and lets us change the console size from the vmm side. During the activation of the device, vmm reads the current terminal size, sets the console configuration accordinly, and lets the driver know about this configuration by sending an interrupt. Later, if someone changes the terminal size, the vmm detects the corresponding event, updates the configuration, and sends interrupt as before. As a result, the console device driver, in the guest, updates the console size. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-23 19:18:20 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump signal-hook from 0.1.14 to 0.1.15 Bumps [signal-hook](https://github.com/vorner/signal-hook) from 0.1.14 to 0.1.15. - [Release notes](https://github.com/vorner/signal-hook/releases) - [Changelog](https://github.com/vorner/signal-hook/blob/master/CHANGELOG.md) - [Commits](https://github.com/vorner/signal-hook/compare/v0.1.14...v0.1.15) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-11 17:49:36 +00:00
checksum = "8ff2db2112d6c761e12522c65f7768548bd6e8cd23d2a9dae162520626629bd6"
vm-virtio: Implement console size config feature One of the features of the virtio console device is its size can be configured and updated. Our first iteration of the console device implementation is lack of this feature. As a result, it had a default fixed size which could not be changed. This commit implements the console config feature and lets us change the console size from the vmm side. During the activation of the device, vmm reads the current terminal size, sets the console configuration accordinly, and lets the driver know about this configuration by sending an interrupt. Later, if someone changes the terminal size, the vmm detects the corresponding event, updates the configuration, and sends interrupt as before. As a result, the console device driver, in the guest, updates the console size. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-23 19:18:20 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"libc",
"signal-hook-registry",
vm-virtio: Implement console size config feature One of the features of the virtio console device is its size can be configured and updated. Our first iteration of the console device implementation is lack of this feature. As a result, it had a default fixed size which could not be changed. This commit implements the console config feature and lets us change the console size from the vmm side. During the activation of the device, vmm reads the current terminal size, sets the console configuration accordinly, and lets the driver know about this configuration by sending an interrupt. Later, if someone changes the terminal size, the vmm detects the corresponding event, updates the configuration, and sends interrupt as before. As a result, the console device driver, in the guest, updates the console size. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-23 19:18:20 +00:00
]
[[package]]
name = "signal-hook-registry"
build(deps): bump signal-hook-registry from 1.1.1 to 1.2.0 Bumps [signal-hook-registry](https://github.com/vorner/signal-hook) from 1.1.1 to 1.2.0. - [Release notes](https://github.com/vorner/signal-hook/releases) - [Changelog](https://github.com/vorner/signal-hook/blob/master/CHANGELOG.md) - [Commits](https://github.com/vorner/signal-hook/compare/registry-v1.1.1...registry-v1.2.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-11-25 16:36:38 +00:00
version = "1.2.0"
vm-virtio: Implement console size config feature One of the features of the virtio console device is its size can be configured and updated. Our first iteration of the console device implementation is lack of this feature. As a result, it had a default fixed size which could not be changed. This commit implements the console config feature and lets us change the console size from the vmm side. During the activation of the device, vmm reads the current terminal size, sets the console configuration accordinly, and lets the driver know about this configuration by sending an interrupt. Later, if someone changes the terminal size, the vmm detects the corresponding event, updates the configuration, and sends interrupt as before. As a result, the console device driver, in the guest, updates the console size. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-23 19:18:20 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "94f478ede9f64724c5d173d7bb56099ec3e2d9fc2774aac65d34b8b890405f41"
vm-virtio: Implement console size config feature One of the features of the virtio console device is its size can be configured and updated. Our first iteration of the console device implementation is lack of this feature. As a result, it had a default fixed size which could not be changed. This commit implements the console config feature and lets us change the console size from the vmm side. During the activation of the device, vmm reads the current terminal size, sets the console configuration accordinly, and lets the driver know about this configuration by sending an interrupt. Later, if someone changes the terminal size, the vmm detects the corresponding event, updates the configuration, and sends interrupt as before. As a result, the console device driver, in the guest, updates the console size. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-23 19:18:20 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"arc-swap",
"libc",
vm-virtio: Implement console size config feature One of the features of the virtio console device is its size can be configured and updated. Our first iteration of the console device implementation is lack of this feature. As a result, it had a default fixed size which could not be changed. This commit implements the console config feature and lets us change the console size from the vmm side. During the activation of the device, vmm reads the current terminal size, sets the console configuration accordinly, and lets the driver know about this configuration by sending an interrupt. Later, if someone changes the terminal size, the vmm detects the corresponding event, updates the configuration, and sends interrupt as before. As a result, the console device driver, in the guest, updates the console size. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-23 19:18:20 +00:00
]
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
[[package]]
name = "slab"
version = "0.4.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "c111b5bd5695e56cffe5129854aa230b39c93a305372fdbb2668ca2394eea9f8"
vhost_user_fs: Process requests in parallel with a thread pool This change enables vhost_user_fs to process multiple requests in parallel by scheduling them into a ThreadPool (from the Futures crate). Parallelism on a single file is limited by the nature of the operation executed on it. A recent commit replaced the Mutex that protects the File within HandleData with a RwLock, to allow some operations (at this moment, only "read" and "write") to proceed in parallel by acquiring a read lock. A more complex approach was also implemented [1], involving instrumentation through vhost_user_backend to be able to serialize completions, reducing the pressure on the vring RwLock. This strategy improved the performance on some corner cases, while making it worse on other, more common ones. This fact, in addition to it requiring wider changes through the source code, prompted me to drop it in favor of this one. [1] https://github.com/slp/cloud-hypervisor/tree/vuf_async Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-03-12 13:31:11 +00:00
build(deps): bump ssh2 from 0.6.0 to 0.7.1 Bumps [ssh2](https://github.com/alexcrichton/ssh2-rs) from 0.6.0 to 0.7.1. - [Release notes](https://github.com/alexcrichton/ssh2-rs/releases) - [Commits](https://github.com/alexcrichton/ssh2-rs/compare/0.6.0...0.7.1) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-25 22:43:45 +00:00
[[package]]
name = "smallvec"
build(deps): bump smallvec from 1.3.0 to 1.4.0 Bumps [smallvec](https://github.com/servo/rust-smallvec) from 1.3.0 to 1.4.0. - [Release notes](https://github.com/servo/rust-smallvec/releases) - [Commits](https://github.com/servo/rust-smallvec/compare/v1.3.0...v1.4.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-04-23 12:13:46 +00:00
version = "1.4.0"
build(deps): bump ssh2 from 0.6.0 to 0.7.1 Bumps [ssh2](https://github.com/alexcrichton/ssh2-rs) from 0.6.0 to 0.7.1. - [Release notes](https://github.com/alexcrichton/ssh2-rs/releases) - [Commits](https://github.com/alexcrichton/ssh2-rs/compare/0.6.0...0.7.1) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-25 22:43:45 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump smallvec from 1.3.0 to 1.4.0 Bumps [smallvec](https://github.com/servo/rust-smallvec) from 1.3.0 to 1.4.0. - [Release notes](https://github.com/servo/rust-smallvec/releases) - [Commits](https://github.com/servo/rust-smallvec/compare/v1.3.0...v1.4.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-04-23 12:13:46 +00:00
checksum = "c7cb5678e1615754284ec264d9bb5b4c27d2018577fd90ac0ceb578591ed5ee4"
build(deps): bump ssh2 from 0.6.0 to 0.7.1 Bumps [ssh2](https://github.com/alexcrichton/ssh2-rs) from 0.6.0 to 0.7.1. - [Release notes](https://github.com/alexcrichton/ssh2-rs/releases) - [Commits](https://github.com/alexcrichton/ssh2-rs/compare/0.6.0...0.7.1) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-25 22:43:45 +00:00
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
[[package]]
name = "ssh2"
build(deps): bump ssh2 from 0.8.0 to 0.8.1 Bumps [ssh2](https://github.com/alexcrichton/ssh2-rs) from 0.8.0 to 0.8.1. - [Release notes](https://github.com/alexcrichton/ssh2-rs/releases) - [Commits](https://github.com/alexcrichton/ssh2-rs/compare/0.8.0...0.8.1) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-04 07:28:39 +00:00
version = "0.8.1"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump ssh2 from 0.8.0 to 0.8.1 Bumps [ssh2](https://github.com/alexcrichton/ssh2-rs) from 0.8.0 to 0.8.1. - [Release notes](https://github.com/alexcrichton/ssh2-rs/releases) - [Commits](https://github.com/alexcrichton/ssh2-rs/compare/0.8.0...0.8.1) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-04 07:28:39 +00:00
checksum = "dd3183fb5dfacfd604fd33be6f581eb060a54d5fdc828d49b41de3c9309459a9"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"bitflags 1.2.1",
"libc",
"libssh2-sys",
"parking_lot",
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
]
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
[[package]]
name = "strsim"
build(deps): bump clap from 2.27.1 to 2.33.0 Bumps [clap](https://github.com/clap-rs/clap) from 2.27.1 to 2.33.0. - [Release notes](https://github.com/clap-rs/clap/releases) - [Changelog](https://github.com/clap-rs/clap/blob/master/CHANGELOG.md) - [Commits](https://github.com/clap-rs/clap/commits) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-02 08:22:53 +00:00
version = "0.8.0"
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "8ea5119cdb4c55b55d432abb513a0429384878c15dde60cc77b1c99de1a95a6a"
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
build(deps): bump remain from 0.1.3 to 0.1.4 Bumps [remain](https://github.com/dtolnay/remain) from 0.1.3 to 0.1.4. - [Release notes](https://github.com/dtolnay/remain/releases) - [Commits](https://github.com/dtolnay/remain/compare/0.1.3...0.1.4) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-19 09:50:43 +00:00
[[package]]
name = "syn"
build(deps): bump syn from 1.0.32 to 1.0.33 Bumps [syn](https://github.com/dtolnay/syn) from 1.0.32 to 1.0.33. - [Release notes](https://github.com/dtolnay/syn/releases) - [Commits](https://github.com/dtolnay/syn/compare/1.0.32...1.0.33) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-22 00:35:28 +00:00
version = "1.0.33"
build(deps): bump remain from 0.1.3 to 0.1.4 Bumps [remain](https://github.com/dtolnay/remain) from 0.1.3 to 0.1.4. - [Release notes](https://github.com/dtolnay/remain/releases) - [Commits](https://github.com/dtolnay/remain/compare/0.1.3...0.1.4) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-19 09:50:43 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump syn from 1.0.32 to 1.0.33 Bumps [syn](https://github.com/dtolnay/syn) from 1.0.32 to 1.0.33. - [Release notes](https://github.com/dtolnay/syn/releases) - [Commits](https://github.com/dtolnay/syn/compare/1.0.32...1.0.33) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-22 00:35:28 +00:00
checksum = "e8d5d96e8cbb005d6959f119f773bfaebb5684296108fb32600c00cde305b2cd"
build(deps): bump remain from 0.1.3 to 0.1.4 Bumps [remain](https://github.com/dtolnay/remain) from 0.1.3 to 0.1.4. - [Release notes](https://github.com/dtolnay/remain/releases) - [Commits](https://github.com/dtolnay/remain/compare/0.1.3...0.1.4) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-19 09:50:43 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"proc-macro2",
"quote",
"unicode-xid 0.2.0",
build(deps): bump remain from 0.1.3 to 0.1.4 Bumps [remain](https://github.com/dtolnay/remain) from 0.1.3 to 0.1.4. - [Release notes](https://github.com/dtolnay/remain/releases) - [Commits](https://github.com/dtolnay/remain/compare/0.1.3...0.1.4) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-19 09:50:43 +00:00
]
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
[[package]]
name = "synstructure"
build(deps): bump synstructure from 0.12.3 to 0.12.4 Bumps [synstructure](https://github.com/mystor/synstructure) from 0.12.3 to 0.12.4. - [Release notes](https://github.com/mystor/synstructure/releases) - [Commits](https://github.com/mystor/synstructure/commits) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-08 17:52:08 +00:00
version = "0.12.4"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump synstructure from 0.12.3 to 0.12.4 Bumps [synstructure](https://github.com/mystor/synstructure) from 0.12.3 to 0.12.4. - [Release notes](https://github.com/mystor/synstructure/releases) - [Commits](https://github.com/mystor/synstructure/commits) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-08 17:52:08 +00:00
checksum = "b834f2d66f734cb897113e34aaff2f1ab4719ca946f9a7358dba8f8064148701"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"proc-macro2",
"quote",
"syn",
"unicode-xid 0.2.0",
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
]
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
[[package]]
name = "syntex"
version = "0.42.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "0a30b08a6b383a22e5f6edc127d169670d48f905bb00ca79a00ea3e442ebe317"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"syntex_errors",
"syntex_syntax",
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
]
[[package]]
name = "syntex_errors"
version = "0.42.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "04c48f32867b6114449155b2a82114b86d4b09e1bddb21c47ff104ab9172b646"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"libc",
"log 0.3.9",
"rustc-serialize",
"syntex_pos",
"term",
"unicode-xid 0.0.3",
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
]
[[package]]
name = "syntex_pos"
version = "0.42.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "3fd49988e52451813c61fecbe9abb5cfd4e1b7bb6cdbb980a6fbcbab859171a6"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"rustc-serialize",
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
]
[[package]]
name = "syntex_syntax"
version = "0.42.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "7628a0506e8f9666fdabb5f265d0059b059edac9a3f810bda077abb5d826bd8d"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"bitflags 0.5.0",
"libc",
"log 0.3.9",
"rustc-serialize",
"syntex_errors",
"syntex_pos",
"term",
"unicode-xid 0.0.3",
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
]
tests: Use a temporary directory for the temporary test files Use the tempdir crate to create a temporary directory that is deleted when the structure goes out of scope. Use this temporary directory for all temporary test files created by the tests. The cloud init file is still in /tmp as that is created by the test wrapper code. This is the first stage towards being able to run the integration tests in parallel. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-18 07:57:01 +00:00
[[package]]
name = "tempdir"
version = "0.3.7"
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "15f2b5fb00ccdf689e0149d1b1b3c03fead81c2b37735d812fa8bddbbf41b6d8"
tests: Use a temporary directory for the temporary test files Use the tempdir crate to create a temporary directory that is deleted when the structure goes out of scope. Use this temporary directory for all temporary test files created by the tests. The cloud init file is still in /tmp as that is created by the test wrapper code. This is the first stage towards being able to run the integration tests in parallel. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-18 07:57:01 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"rand 0.4.6",
"remove_dir_all",
tests: Use a temporary directory for the temporary test files Use the tempdir crate to create a temporary directory that is deleted when the structure goes out of scope. Use this temporary directory for all temporary test files created by the tests. The cloud init file is still in /tmp as that is created by the test wrapper code. This is the first stage towards being able to run the integration tests in parallel. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-18 07:57:01 +00:00
]
vmm: Use virtio-blk to support booting from disk image After the virtio-blk device support has been introduced in the previous commit, the vmm need to rely on this new device to boot from disk images instead of initrd built into the kernel. In order to achieve the proper support of virtio-blk, this commit had to handle a few things: - Register an ioevent fd for each virtqueue. This important to be notified from the virtio driver that something has been written on the queue. - Fix the retrieval of 64bits BAR address. This is needed to provide the right address which need to be registered as the notification address from the virtio driver. - Fix the write_bar and read_bar functions. They were both assuming to be provided with an address, from which they were trying to find the associated offset. But the reality is that the offset is directly provided by the Bus layer. - Register a new virtio-blk device as a virtio-pci device from the vm.rs code. When the VM is started, it expects a block device to be created, using this block device as the VM rootfs. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-05-06 17:27:40 +00:00
[[package]]
name = "tempfile"
vm-virtio: Add virtio console device for single port operation The virtio console device is a console for the communication between the host and guest userspace. It has two parts: the device and the driver. The console device is implemented here as a virtio-pci device to the guest. On the other side, the guest OS expected to have a character device driver which provides an interface to the userspace applications. The console device can have multiple ports where each port has one transmit queue and one receive queue. The current implementation only supports one port. For data IO communication, one or more empty buffers are placed in the receive queue for incoming data, and outgoing characters are placed in the transmit queue. Details spec can be found from the following link. https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.pdf#e7 Apart from the console, for the communication between guest and host, the Cloud Hypervisor has a legacy serial device implemented. However, the implementation of a console device lets us be independent of legacy pin-based interrupts without losing the logs and access to the VM. Signed-off-by: A K M Fazla Mehrab <fazla.mehrab.akm@intel.com>
2019-07-22 18:50:56 +00:00
version = "3.1.0"
vmm: Use virtio-blk to support booting from disk image After the virtio-blk device support has been introduced in the previous commit, the vmm need to rely on this new device to boot from disk images instead of initrd built into the kernel. In order to achieve the proper support of virtio-blk, this commit had to handle a few things: - Register an ioevent fd for each virtqueue. This important to be notified from the virtio driver that something has been written on the queue. - Fix the retrieval of 64bits BAR address. This is needed to provide the right address which need to be registered as the notification address from the virtio driver. - Fix the write_bar and read_bar functions. They were both assuming to be provided with an address, from which they were trying to find the associated offset. But the reality is that the offset is directly provided by the Bus layer. - Register a new virtio-blk device as a virtio-pci device from the vm.rs code. When the VM is started, it expects a block device to be created, using this block device as the VM rootfs. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-05-06 17:27:40 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "7a6e24d9338a0a5be79593e2fa15a648add6138caa803e2d5bc782c371732ca9"
vmm: Use virtio-blk to support booting from disk image After the virtio-blk device support has been introduced in the previous commit, the vmm need to rely on this new device to boot from disk images instead of initrd built into the kernel. In order to achieve the proper support of virtio-blk, this commit had to handle a few things: - Register an ioevent fd for each virtqueue. This important to be notified from the virtio driver that something has been written on the queue. - Fix the retrieval of 64bits BAR address. This is needed to provide the right address which need to be registered as the notification address from the virtio driver. - Fix the write_bar and read_bar functions. They were both assuming to be provided with an address, from which they were trying to find the associated offset. But the reality is that the offset is directly provided by the Bus layer. - Register a new virtio-blk device as a virtio-pci device from the vm.rs code. When the VM is started, it expects a block device to be created, using this block device as the VM rootfs. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-05-06 17:27:40 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"cfg-if",
"libc",
"rand 0.7.3",
"redox_syscall",
"remove_dir_all",
"winapi 0.3.8",
vmm: Use virtio-blk to support booting from disk image After the virtio-blk device support has been introduced in the previous commit, the vmm need to rely on this new device to boot from disk images instead of initrd built into the kernel. In order to achieve the proper support of virtio-blk, this commit had to handle a few things: - Register an ioevent fd for each virtqueue. This important to be notified from the virtio driver that something has been written on the queue. - Fix the retrieval of 64bits BAR address. This is needed to provide the right address which need to be registered as the notification address from the virtio driver. - Fix the write_bar and read_bar functions. They were both assuming to be provided with an address, from which they were trying to find the associated offset. But the reality is that the offset is directly provided by the Bus layer. - Register a new virtio-blk device as a virtio-pci device from the vm.rs code. When the VM is started, it expects a block device to be created, using this block device as the VM rootfs. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-05-06 17:27:40 +00:00
]
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
[[package]]
name = "term"
version = "0.4.6"
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "fa63644f74ce96fbeb9b794f66aff2a52d601cbd5e80f4b97123e3899f4570f1"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"kernel32-sys",
"winapi 0.2.8",
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
]
build: Use "wrap_help" feature for clap This prevents the output being wrapped at 120 characters and giving strange results. Fixes: #899 Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2020-03-12 16:00:40 +00:00
[[package]]
name = "term_size"
build(deps): bump term_size from 0.3.1 to 0.3.2 Bumps [term_size](https://github.com/kbknapp/term_size-rs) from 0.3.1 to 0.3.2. - [Release notes](https://github.com/kbknapp/term_size-rs/releases) - [Changelog](https://github.com/clap-rs/term_size-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/kbknapp/term_size-rs/commits) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-02 02:44:41 +00:00
version = "0.3.2"
build: Use "wrap_help" feature for clap This prevents the output being wrapped at 120 characters and giving strange results. Fixes: #899 Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2020-03-12 16:00:40 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump term_size from 0.3.1 to 0.3.2 Bumps [term_size](https://github.com/kbknapp/term_size-rs) from 0.3.1 to 0.3.2. - [Release notes](https://github.com/kbknapp/term_size-rs/releases) - [Changelog](https://github.com/clap-rs/term_size-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/kbknapp/term_size-rs/commits) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-02 02:44:41 +00:00
checksum = "1e4129646ca0ed8f45d09b929036bafad5377103edd06e50bf574b353d2b08d9"
build: Use "wrap_help" feature for clap This prevents the output being wrapped at 120 characters and giving strange results. Fixes: #899 Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2020-03-12 16:00:40 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"libc",
build(deps): bump term_size from 0.3.1 to 0.3.2 Bumps [term_size](https://github.com/kbknapp/term_size-rs) from 0.3.1 to 0.3.2. - [Release notes](https://github.com/kbknapp/term_size-rs/releases) - [Changelog](https://github.com/clap-rs/term_size-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/kbknapp/term_size-rs/commits) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-02 02:44:41 +00:00
"winapi 0.3.8",
build: Use "wrap_help" feature for clap This prevents the output being wrapped at 120 characters and giving strange results. Fixes: #899 Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2020-03-12 16:00:40 +00:00
]
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
[[package]]
name = "textwrap"
build(deps): bump clap from 2.27.1 to 2.33.0 Bumps [clap](https://github.com/clap-rs/clap) from 2.27.1 to 2.33.0. - [Release notes](https://github.com/clap-rs/clap/releases) - [Changelog](https://github.com/clap-rs/clap/blob/master/CHANGELOG.md) - [Commits](https://github.com/clap-rs/clap/commits) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-02 08:22:53 +00:00
version = "0.11.0"
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "d326610f408c7a4eb6f51c37c330e496b08506c9457c9d34287ecc38809fb060"
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"term_size",
"unicode-width",
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
]
vm-device: Initial Migratable trait The Migratable trait groups all expected capabilities of devices and components that can be migrated. For a component to be migrated, it must be able to pause and resume. Once paused, it should be able to provide a snapshot of itself. It should also be able to restore itself from a snaphot. As a consequence, the Migratable trait will be split between the Pausable and the Snapshotable traits. This commit only adds the Pausable one. All migratable devices will be tracked from the DeviceManager. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-11-18 14:30:54 +00:00
[[package]]
name = "thiserror"
build(deps): bump thiserror from 1.0.19 to 1.0.20 Bumps [thiserror](https://github.com/dtolnay/thiserror) from 1.0.19 to 1.0.20. - [Release notes](https://github.com/dtolnay/thiserror/releases) - [Commits](https://github.com/dtolnay/thiserror/compare/1.0.19...1.0.20) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-15 23:35:03 +00:00
version = "1.0.20"
vm-device: Initial Migratable trait The Migratable trait groups all expected capabilities of devices and components that can be migrated. For a component to be migrated, it must be able to pause and resume. Once paused, it should be able to provide a snapshot of itself. It should also be able to restore itself from a snaphot. As a consequence, the Migratable trait will be split between the Pausable and the Snapshotable traits. This commit only adds the Pausable one. All migratable devices will be tracked from the DeviceManager. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-11-18 14:30:54 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump thiserror from 1.0.19 to 1.0.20 Bumps [thiserror](https://github.com/dtolnay/thiserror) from 1.0.19 to 1.0.20. - [Release notes](https://github.com/dtolnay/thiserror/releases) - [Commits](https://github.com/dtolnay/thiserror/compare/1.0.19...1.0.20) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-15 23:35:03 +00:00
checksum = "7dfdd070ccd8ccb78f4ad66bf1982dc37f620ef696c6b5028fe2ed83dd3d0d08"
vm-device: Initial Migratable trait The Migratable trait groups all expected capabilities of devices and components that can be migrated. For a component to be migrated, it must be able to pause and resume. Once paused, it should be able to provide a snapshot of itself. It should also be able to restore itself from a snaphot. As a consequence, the Migratable trait will be split between the Pausable and the Snapshotable traits. This commit only adds the Pausable one. All migratable devices will be tracked from the DeviceManager. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-11-18 14:30:54 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"thiserror-impl",
vm-device: Initial Migratable trait The Migratable trait groups all expected capabilities of devices and components that can be migrated. For a component to be migrated, it must be able to pause and resume. Once paused, it should be able to provide a snapshot of itself. It should also be able to restore itself from a snaphot. As a consequence, the Migratable trait will be split between the Pausable and the Snapshotable traits. This commit only adds the Pausable one. All migratable devices will be tracked from the DeviceManager. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-11-18 14:30:54 +00:00
]
[[package]]
name = "thiserror-impl"
build(deps): bump thiserror from 1.0.19 to 1.0.20 Bumps [thiserror](https://github.com/dtolnay/thiserror) from 1.0.19 to 1.0.20. - [Release notes](https://github.com/dtolnay/thiserror/releases) - [Commits](https://github.com/dtolnay/thiserror/compare/1.0.19...1.0.20) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-15 23:35:03 +00:00
version = "1.0.20"
vm-device: Initial Migratable trait The Migratable trait groups all expected capabilities of devices and components that can be migrated. For a component to be migrated, it must be able to pause and resume. Once paused, it should be able to provide a snapshot of itself. It should also be able to restore itself from a snaphot. As a consequence, the Migratable trait will be split between the Pausable and the Snapshotable traits. This commit only adds the Pausable one. All migratable devices will be tracked from the DeviceManager. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-11-18 14:30:54 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump thiserror from 1.0.19 to 1.0.20 Bumps [thiserror](https://github.com/dtolnay/thiserror) from 1.0.19 to 1.0.20. - [Release notes](https://github.com/dtolnay/thiserror/releases) - [Commits](https://github.com/dtolnay/thiserror/compare/1.0.19...1.0.20) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-15 23:35:03 +00:00
checksum = "bd80fc12f73063ac132ac92aceea36734f04a1d93c1240c6944e23a3b8841793"
vm-device: Initial Migratable trait The Migratable trait groups all expected capabilities of devices and components that can be migrated. For a component to be migrated, it must be able to pause and resume. Once paused, it should be able to provide a snapshot of itself. It should also be able to restore itself from a snaphot. As a consequence, the Migratable trait will be split between the Pausable and the Snapshotable traits. This commit only adds the Pausable one. All migratable devices will be tracked from the DeviceManager. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-11-18 14:30:54 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"proc-macro2",
"quote",
"syn",
vm-device: Initial Migratable trait The Migratable trait groups all expected capabilities of devices and components that can be migrated. For a component to be migrated, it must be able to pause and resume. Once paused, it should be able to provide a snapshot of itself. It should also be able to restore itself from a snaphot. As a consequence, the Migratable trait will be split between the Pausable and the Snapshotable traits. This commit only adds the Pausable one. All migratable devices will be tracked from the DeviceManager. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-11-18 14:30:54 +00:00
]
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
[[package]]
name = "thread_local"
build(deps): bump pnet_macros from 0.25.0 to 0.26.0 Bumps [pnet_macros](https://github.com/libpnet/libpnet) from 0.25.0 to 0.26.0. - [Release notes](https://github.com/libpnet/libpnet/releases) - [Commits](https://github.com/libpnet/libpnet/compare/v0.25.0...v0.26.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-01 18:34:05 +00:00
version = "1.0.1"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump pnet_macros from 0.25.0 to 0.26.0 Bumps [pnet_macros](https://github.com/libpnet/libpnet) from 0.25.0 to 0.26.0. - [Release notes](https://github.com/libpnet/libpnet/releases) - [Commits](https://github.com/libpnet/libpnet/compare/v0.25.0...v0.26.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-01 18:34:05 +00:00
checksum = "d40c6d1b69745a6ec6fb1ca717914848da4b44ae29d9b3080cbee91d72a69b14"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"lazy_static",
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
]
build(deps): bump unicode-normalization from 0.1.12 to 0.1.13 Bumps [unicode-normalization](https://github.com/unicode-rs/unicode-normalization) from 0.1.12 to 0.1.13. - [Release notes](https://github.com/unicode-rs/unicode-normalization/releases) - [Commits](https://github.com/unicode-rs/unicode-normalization/compare/v0.1.12...v0.1.13) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-16 19:40:46 +00:00
[[package]]
name = "tinyvec"
version = "0.3.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "53953d2d3a5ad81d9f844a32f14ebb121f50b650cd59d0ee2a07cf13c617efed"
vmm: memory_manager: Implement the Transportable trait This implements the send() function of the Transportable trait, so that the guest memory regions can be saved into one file per region. This will need to be extended for live migration, as it will require other transport methods and the recv() function will need to be implemented too. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2020-02-25 01:38:08 +00:00
[[package]]
name = "unicode-bidi"
version = "0.3.4"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "49f2bd0c6468a8230e1db229cff8029217cf623c767ea5d60bfbd42729ea54d5"
dependencies = [
"matches",
]
[[package]]
name = "unicode-normalization"
build(deps): bump unicode-normalization from 0.1.12 to 0.1.13 Bumps [unicode-normalization](https://github.com/unicode-rs/unicode-normalization) from 0.1.12 to 0.1.13. - [Release notes](https://github.com/unicode-rs/unicode-normalization/releases) - [Commits](https://github.com/unicode-rs/unicode-normalization/compare/v0.1.12...v0.1.13) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-16 19:40:46 +00:00
version = "0.1.13"
vmm: memory_manager: Implement the Transportable trait This implements the send() function of the Transportable trait, so that the guest memory regions can be saved into one file per region. This will need to be extended for live migration, as it will require other transport methods and the recv() function will need to be implemented too. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2020-02-25 01:38:08 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump unicode-normalization from 0.1.12 to 0.1.13 Bumps [unicode-normalization](https://github.com/unicode-rs/unicode-normalization) from 0.1.12 to 0.1.13. - [Release notes](https://github.com/unicode-rs/unicode-normalization/releases) - [Commits](https://github.com/unicode-rs/unicode-normalization/compare/v0.1.12...v0.1.13) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-16 19:40:46 +00:00
checksum = "6fb19cf769fa8c6a80a162df694621ebeb4dafb606470b2b2fce0be40a98a977"
vmm: memory_manager: Implement the Transportable trait This implements the send() function of the Transportable trait, so that the guest memory regions can be saved into one file per region. This will need to be extended for live migration, as it will require other transport methods and the recv() function will need to be implemented too. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2020-02-25 01:38:08 +00:00
dependencies = [
build(deps): bump unicode-normalization from 0.1.12 to 0.1.13 Bumps [unicode-normalization](https://github.com/unicode-rs/unicode-normalization) from 0.1.12 to 0.1.13. - [Release notes](https://github.com/unicode-rs/unicode-normalization/releases) - [Commits](https://github.com/unicode-rs/unicode-normalization/compare/v0.1.12...v0.1.13) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-16 19:40:46 +00:00
"tinyvec",
vmm: memory_manager: Implement the Transportable trait This implements the send() function of the Transportable trait, so that the guest memory regions can be saved into one file per region. This will need to be extended for live migration, as it will require other transport methods and the recv() function will need to be implemented too. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2020-02-25 01:38:08 +00:00
]
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
[[package]]
name = "unicode-width"
build(deps): bump unicode-width from 0.1.6 to 0.1.7 Bumps [unicode-width](https://github.com/unicode-rs/unicode-width) from 0.1.6 to 0.1.7. - [Release notes](https://github.com/unicode-rs/unicode-width/releases) - [Commits](https://github.com/unicode-rs/unicode-width/commits) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-12-05 18:24:09 +00:00
version = "0.1.7"
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "caaa9d531767d1ff2150b9332433f32a24622147e5ebb1f26409d5da67afd479"
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
[[package]]
name = "unicode-xid"
version = "0.0.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "36dff09cafb4ec7c8cf0023eb0b686cb6ce65499116a12201c9e11840ca01beb"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
build(deps): bump remain from 0.1.3 to 0.1.4 Bumps [remain](https://github.com/dtolnay/remain) from 0.1.3 to 0.1.4. - [Release notes](https://github.com/dtolnay/remain/releases) - [Commits](https://github.com/dtolnay/remain/compare/0.1.3...0.1.4) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-19 09:50:43 +00:00
[[package]]
name = "unicode-xid"
version = "0.2.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "826e7639553986605ec5979c7dd957c7895e93eabed50ab2ffa7f6128a75097c"
build(deps): bump remain from 0.1.3 to 0.1.4 Bumps [remain](https://github.com/dtolnay/remain) from 0.1.3 to 0.1.4. - [Release notes](https://github.com/dtolnay/remain/releases) - [Commits](https://github.com/dtolnay/remain/compare/0.1.3...0.1.4) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-19 09:50:43 +00:00
vmm: memory_manager: Implement the Transportable trait This implements the send() function of the Transportable trait, so that the guest memory regions can be saved into one file per region. This will need to be extended for live migration, as it will require other transport methods and the recv() function will need to be implemented too. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2020-02-25 01:38:08 +00:00
[[package]]
name = "url"
version = "2.1.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "829d4a8476c35c9bf0bbce5a3b23f4106f79728039b726d292bb93bc106787cb"
dependencies = [
"idna",
"matches",
"percent-encoding",
]
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
[[package]]
name = "vcpkg"
build(deps): bump vcpkg from 0.2.9 to 0.2.10 Bumps [vcpkg](https://github.com/mcgoo/vcpkg-rs) from 0.2.9 to 0.2.10. - [Release notes](https://github.com/mcgoo/vcpkg-rs/releases) - [Changelog](https://github.com/mcgoo/vcpkg-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/mcgoo/vcpkg-rs/compare/vcpkg-rs-0.2.9...vcpkg-rs-0.2.10) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-10 06:20:03 +00:00
version = "0.2.10"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump vcpkg from 0.2.9 to 0.2.10 Bumps [vcpkg](https://github.com/mcgoo/vcpkg-rs) from 0.2.9 to 0.2.10. - [Release notes](https://github.com/mcgoo/vcpkg-rs/releases) - [Changelog](https://github.com/mcgoo/vcpkg-rs/blob/master/CHANGELOG.md) - [Commits](https://github.com/mcgoo/vcpkg-rs/compare/vcpkg-rs-0.2.9...vcpkg-rs-0.2.10) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-10 06:20:03 +00:00
checksum = "6454029bf181f092ad1b853286f23e2c507d8e8194d01d92da4a55c274a5508c"
tests: Add basic integration testing Add basic integration testing of the hypervisor using a cloud-init to configure the VM at boot and SSH to control it at runtime. Initial test just boots the VM up checks some basic resources and reboots. With a second test that calls into the first to check that subsequent tests work correctly. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-05-23 15:45:13 +00:00
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
[[package]]
name = "vec_map"
build(deps): bump vec_map from 0.8.1 to 0.8.2 Bumps [vec_map](https://github.com/contain-rs/vec-map) from 0.8.1 to 0.8.2. - [Release notes](https://github.com/contain-rs/vec-map/releases) - [Commits](https://github.com/contain-rs/vec-map/commits) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-06 13:42:39 +00:00
version = "0.8.2"
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump vec_map from 0.8.1 to 0.8.2 Bumps [vec_map](https://github.com/contain-rs/vec-map) from 0.8.1 to 0.8.2. - [Release notes](https://github.com/contain-rs/vec-map/releases) - [Commits](https://github.com/contain-rs/vec-map/commits) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-06 13:42:39 +00:00
checksum = "f1bddf1187be692e79c5ffeab891132dfb0f236ed36a43c7ed39f1165ee20191"
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
vmm: Support direct device assignment With the VFIO crate, we can now support directly assigned PCI devices into cloud-hypervisor guests. We support assigning multiple host devices, through the --device command line parameter. This parameter takes the host device sysfs path. Fixes: #60 Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-07-15 09:42:40 +00:00
[[package]]
vfio: Rename to vfio-ioctls Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-11-08 15:27:05 +00:00
name = "vfio-bindings"
version = "0.2.0"
source = "git+https://github.com/rust-vmm/vfio-bindings#f08cbcbf4041c981441d9c036c49ebad5098ed1c"
dependencies = [
"vmm-sys-util",
]
vfio: Switch to the vfio-ioctls crate ch branch Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-11-12 14:36:07 +00:00
[[package]]
name = "vfio-bindings"
version = "0.2.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "4a21f546f2bda37f5a8cfb138c87f95b8e34d2d78d6a7a92ba3785f4e08604a7"
vfio: Rename to vfio-ioctls Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-11-08 15:27:05 +00:00
[[package]]
name = "vfio-ioctls"
vfio: Switch to the vfio-ioctls crate ch branch Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-11-12 14:36:07 +00:00
version = "0.1.0"
source = "git+https://github.com/cloud-hypervisor/vfio-ioctls?branch=ch#f6f81ee865cb60a24ad5d4ba8200940ed1d5d1f4"
vmm: Support direct device assignment With the VFIO crate, we can now support directly assigned PCI devices into cloud-hypervisor guests. We support assigning multiple host devices, through the --device command line parameter. This parameter takes the host device sysfs path. Fixes: #60 Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-07-15 09:42:40 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"byteorder",
"kvm-bindings",
"kvm-ioctls",
"log 0.4.8",
vfio: Switch to the vfio-ioctls crate ch branch Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-11-12 14:36:07 +00:00
"vfio-bindings 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"vm-memory",
"vmm-sys-util",
vmm: Support direct device assignment With the VFIO crate, we can now support directly assigned PCI devices into cloud-hypervisor guests. We support assigning multiple host devices, through the --device command line parameter. This parameter takes the host device sysfs path. Fixes: #60 Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-07-15 09:42:40 +00:00
]
vm-virtio: Add vhost-user-fs support The vhost-user-fs or virtio-fs device allows files and directories to be shared between host and guest. This patch adds the implementation of this device to the cloud-hypervisor device model. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-05-21 18:54:53 +00:00
[[package]]
Cargo: switch vhost_rs to external crate As cloud-hypervisor/vhost crate (dragonball branch) is ready to be used, switch vhost_rs from internal crate to the external one. Signed-off-by: Eryu Guan <eguan@linux.alibaba.com>
2020-02-25 03:26:35 +00:00
name = "vhost"
vm-virtio: Add vhost-user-fs support The vhost-user-fs or virtio-fs device allows files and directories to be shared between host and guest. This patch adds the implementation of this device to the cloud-hypervisor device model. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-05-21 18:54:53 +00:00
version = "0.1.0"
vhost_user_*: Create a vhost::Listener in advance Changes is vhost crate require VhostUserDaemon users to create and provide a vhost::Listener in advance. This allows us to adopt sandboxing strategies in the future, by being able to create the UNIX socket before switching to a restricted namespace. Update also the reference to vhost crate in Cargo.lock to point to the latest commit from the dragonball branch. Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-04-24 11:33:00 +00:00
source = "git+https://github.com/cloud-hypervisor/vhost?branch=dragonball#3e80cf531d278aeb7f947335a4eeca655e0f2c54"
vm-virtio: Add vhost-user-fs support The vhost-user-fs or virtio-fs device allows files and directories to be shared between host and guest. This patch adds the implementation of this device to the cloud-hypervisor device model. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-05-21 18:54:53 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"bitflags 1.2.1",
"libc",
"vmm-sys-util",
vm-virtio: Add vhost-user-fs support The vhost-user-fs or virtio-fs device allows files and directories to be shared between host and guest. This patch adds the implementation of this device to the cloud-hypervisor device model. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-05-21 18:54:53 +00:00
]
src: Add vhost-user-net backend Create vhost-user-net backend with Tap interface, to offload network transaction from cloud-hypervisor. The goal is to provide flexibility about the backend being in use, but also more security as it will allow users to isolate the backend with different security profiles since it will run as a dedicated process on the host. Signed-off-by: Cathy Zhang <cathy.zhang@intel.com> Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-09-20 18:21:54 +00:00
[[package]]
name = "vhost_user_backend"
version = "0.1.0"
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"epoll",
"libc",
"log 0.4.8",
"vhost",
build: Use same virtio-bindings version Consistently use the crates.io 0.1.0 version based on Linux 5.0.0 Fixes: #1192 Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2020-05-20 10:13:06 +00:00
"virtio-bindings",
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"vm-memory",
"vm-virtio",
"vmm-sys-util",
src: Add vhost-user-net backend Create vhost-user-net backend with Tap interface, to offload network transaction from cloud-hypervisor. The goal is to provide flexibility about the backend being in use, but also more security as it will allow users to isolate the backend with different security profiles since it will run as a dedicated process on the host. Signed-off-by: Cathy Zhang <cathy.zhang@intel.com> Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-09-20 18:21:54 +00:00
]
vhost_user_fs: Add new crate This new crate will be dedicated to vhost_user_fs specific code that can be used as a library from the vhost-user-fs daemon. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-10-31 17:16:28 +00:00
[[package]]
vhost_user_block: Refactor vhost_user_block backend code into a new crate Extract the majority of the code that provides the vhost-user-block backend into its own crate and port the binary to use it. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2020-01-20 16:10:21 +00:00
name = "vhost_user_block"
version = "0.1.0"
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"bitflags 1.2.1",
"epoll",
"libc",
"log 0.4.8",
"qcow",
"vhost",
"vhost_user_backend",
build: Use same virtio-bindings version Consistently use the crates.io 0.1.0 version based on Linux 5.0.0 Fixes: #1192 Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2020-05-20 10:13:06 +00:00
"virtio-bindings",
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"vm-memory",
"vm-virtio",
vhost_user_block: Use config::OptionParser to simplify block backend parsing Switch to using the recently added OptionParser in the code that parses the block backend. Fixes: #1092 Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2020-05-08 15:43:56 +00:00
"vmm",
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"vmm-sys-util",
vhost_user_block: Refactor vhost_user_block backend code into a new crate Extract the majority of the code that provides the vhost-user-block backend into its own crate and port the binary to use it. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2020-01-20 16:10:21 +00:00
]
[[package]]
vhost_user_fs: Add new crate This new crate will be dedicated to vhost_user_fs specific code that can be used as a library from the vhost-user-fs daemon. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-10-31 17:16:28 +00:00
name = "vhost_user_fs"
version = "0.1.0"
vhost_user_fs: Add FUSE definitions To be able to deal with FUSE requests, this commit introduces FUSE definitions, copied over from the crosvm commit 961461350c0b6824e5f20655031bf6c6bf6b7c30. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-10-31 17:26:24 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"bitflags 1.2.1",
"libc",
"log 0.4.8",
vhost_user_fs: Add seccomp Implement seccomp; we use one filter for all threads. The syscall list comes from the C daemon with syscalls added as I hit them. The default behaviour is to kill the process, this normally gets audit logged. --seccomp none disables seccomp log Just logs violations but doesn't stop it trap causes a signal to be be sent that can be trapped. If you suspect you're hitting a seccomp action then you can check the audit log; you could also switch to running with 'log' to collect a bunch of calls to report. To see where the syscalls are coming from use 'trap' with a debugger or coredump to backtrace it. This can be improved for some syscalls to restrict the parameters to some syscalls to make them more restrictive. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-05-01 16:26:07 +00:00
"seccomp",
vhost_user_fs: Implement support for optional sandboxing Implement support for setting up a sandbox for running the service. The technique for this has been borrowed from virtiofsd, and consists on switching to new PID, mount and network namespaces, and then switching root to the directory to be shared. Future patches will implement additional hardening features like dropping capabilities and seccomp filters. Signed-off-by: Sergio Lopez <slp@redhat.com>
2020-04-24 11:43:36 +00:00
"tempdir",
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"vhost",
"vm-memory",
"vm-virtio",
vhost_user_fs: Add FUSE definitions To be able to deal with FUSE requests, this commit introduces FUSE definitions, copied over from the crosvm commit 961461350c0b6824e5f20655031bf6c6bf6b7c30. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-10-31 17:26:24 +00:00
]
vhost_user_fs: Add new crate This new crate will be dedicated to vhost_user_fs specific code that can be used as a library from the vhost-user-fs daemon. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-10-31 17:16:28 +00:00
vhost_user_net: Refactor vhost_user_net backend code into a new crate Extract the majority of the code that provides the vhost-user-net backend into its own crate and port the binary to use it. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2020-01-20 16:10:21 +00:00
[[package]]
name = "vhost_user_net"
version = "0.1.0"
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"bitflags 1.2.1",
"epoll",
"libc",
"log 0.4.8",
"net_util",
"vhost",
"vhost_user_backend",
build: Use same virtio-bindings version Consistently use the crates.io 0.1.0 version based on Linux 5.0.0 Fixes: #1192 Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2020-05-20 10:13:06 +00:00
"virtio-bindings",
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"vm-memory",
"vm-virtio",
vhost_user_net: Use config::OptionParser to simplify net backend parsing Switch to using the recently added OptionParser in the code that parses the network backend. Whilst doing this also update the net-backend syntax to use "sock" rather than socket. Fixes: #1092 Partially fixes: #1091 Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2020-05-08 15:43:56 +00:00
"vmm",
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"vmm-sys-util",
vhost_user_net: Refactor vhost_user_net backend code into a new crate Extract the majority of the code that provides the vhost-user-net backend into its own crate and port the binary to use it. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2020-01-20 16:10:21 +00:00
]
Cargo: Move virtio-bindings to crates.io v0.1.0 was just published. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-10-10 07:38:42 +00:00
[[package]]
name = "virtio-bindings"
version = "0.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "3ff512178285488516ed85f15b5d0113a7cdb89e9e8a760b269ae4f02b84bd6b"
Cargo: Move virtio-bindings to crates.io v0.1.0 was just published. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-10-10 07:38:42 +00:00
vmm: Add PCI root Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-04-18 10:26:09 +00:00
[[package]]
name = "vm-allocator"
version = "0.1.0"
dependencies = [
build: Update Cargo.lock An update to the Cargo.lock file was missing from a previous commit. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2020-06-11 14:08:34 +00:00
"arch",
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"libc",
"vm-memory",
vmm: Add PCI root Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-04-18 10:26:09 +00:00
]
vm-device: Add new crate for virtio and VFIO agnostic traits The new crate vm-device is created here to host the definitions of traits not meant to be tied to virtio of VFIO specifically. We need to add a new trait to update external DMA mappings for devices, which is why the vm-device crate is the right fit for this. We can expect this crate to be extended later once the design gets approved from a rust-vmm perspective. In this specific use case, we can have some devices like VFIO or vhost-user ones requiring to be notified about mapping updates. This new trait ExternalDmaMapping will allow such devices to implement their own way to handle such event. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-10-07 16:57:19 +00:00
[[package]]
name = "vm-device"
version = "0.1.0"
vm-device: Initial Migratable trait The Migratable trait groups all expected capabilities of devices and components that can be migrated. For a component to be migrated, it must be able to pause and resume. Once paused, it should be able to provide a snapshot of itself. It should also be able to restore itself from a snaphot. As a consequence, the Migratable trait will be split between the Pausable and the Snapshotable traits. This commit only adds the Pausable one. All migratable devices will be tracked from the DeviceManager. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-11-18 14:30:54 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"anyhow",
"serde",
"serde_derive",
"serde_json",
"thiserror",
"vm-memory",
"vmm-sys-util",
vm-device: Initial Migratable trait The Migratable trait groups all expected capabilities of devices and components that can be migrated. For a component to be migrated, it must be able to pause and resume. Once paused, it should be able to provide a snapshot of itself. It should also be able to restore itself from a snaphot. As a consequence, the Migratable trait will be split between the Pausable and the Snapshotable traits. This commit only adds the Pausable one. All migratable devices will be tracked from the DeviceManager. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-11-18 14:30:54 +00:00
]
vm-device: Add new crate for virtio and VFIO agnostic traits The new crate vm-device is created here to host the definitions of traits not meant to be tied to virtio of VFIO specifically. We need to add a new trait to update external DMA mappings for devices, which is why the vm-device crate is the right fit for this. We can expect this crate to be extended later once the design gets approved from a rust-vmm perspective. In this specific use case, we can have some devices like VFIO or vhost-user ones requiring to be notified about mapping updates. This new trait ExternalDmaMapping will allow such devices to implement their own way to handle such event. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-10-07 16:57:19 +00:00
cloud-hypervisor: Call into the test_vm() routine test_vm is a dummy VM workload, we use it to test our initial VMM settings. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-22 16:05:02 +00:00
[[package]]
name = "vm-memory"
build(deps): bump vm-memory from 0.2.0 to 0.2.1 Bumps [vm-memory](https://github.com/rust-vmm/vm-memory) from 0.2.0 to 0.2.1. - [Release notes](https://github.com/rust-vmm/vm-memory/releases) - [Changelog](https://github.com/rust-vmm/vm-memory/blob/v0.2.1/CHANGELOG.md) - [Commits](https://github.com/rust-vmm/vm-memory/compare/v0.2.0...v0.2.1) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-05-28 15:06:54 +00:00
version = "0.2.1"
build: Use fork of vm-memory with less performance impact Currently released vm-memory uses aligned and volatile copying for all data. The version in the fork only uses the assured (and slower) path for data upto the natural data width. Fixes: #1258 Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2020-06-09 13:35:41 +00:00
source = "git+https://github.com/cloud-hypervisor/vm-memory?branch=ch#708e9aa5d4317f7044d9835fe5080287e9c76f21"
cloud-hypervisor: Call into the test_vm() routine test_vm is a dummy VM workload, we use it to test our initial VMM settings. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-22 16:05:02 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"arc-swap",
"libc",
"winapi 0.3.8",
]
[[package]]
name = "vm-migration"
version = "0.1.0"
dependencies = [
"anyhow",
"serde",
"serde_derive",
"serde_json",
"thiserror",
cloud-hypervisor: Call into the test_vm() routine test_vm is a dummy VM workload, we use it to test our initial VMM settings. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-22 16:05:02 +00:00
]
vmm: Use virtio-blk to support booting from disk image After the virtio-blk device support has been introduced in the previous commit, the vmm need to rely on this new device to boot from disk images instead of initrd built into the kernel. In order to achieve the proper support of virtio-blk, this commit had to handle a few things: - Register an ioevent fd for each virtqueue. This important to be notified from the virtio driver that something has been written on the queue. - Fix the retrieval of 64bits BAR address. This is needed to provide the right address which need to be registered as the notification address from the virtio driver. - Fix the write_bar and read_bar functions. They were both assuming to be provided with an address, from which they were trying to find the associated offset. But the reality is that the offset is directly provided by the Bus layer. - Register a new virtio-blk device as a virtio-pci device from the vm.rs code. When the VM is started, it expects a block device to be created, using this block device as the VM rootfs. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-05-06 17:27:40 +00:00
[[package]]
name = "vm-virtio"
version = "0.1.0"
dependencies = [
vm-virtio: Add the ability to serialize a Queue This commit relies on serde to serialize and deserialize the content of a Queue structure. This will be useful information to store when implementing snapshot/restore feature for virtio devices. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2020-04-08 01:53:12 +00:00
"anyhow",
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"arc-swap",
"byteorder",
"devices",
"epoll",
"libc",
"log 0.4.8",
"net_gen",
"net_util",
"pci",
vm-virtio: Add the ability to serialize a Queue This commit relies on serde to serialize and deserialize the content of a Queue structure. This will be useful information to store when implementing snapshot/restore feature for virtio devices. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2020-04-08 01:53:12 +00:00
"serde",
"serde_derive",
"serde_json",
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"tempfile",
vfio: Switch to the vfio-ioctls crate ch branch Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-11-12 14:36:07 +00:00
"vfio-ioctls",
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"vhost",
build: Use same virtio-bindings version Consistently use the crates.io 0.1.0 version based on Linux 5.0.0 Fixes: #1192 Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2020-05-20 10:13:06 +00:00
"virtio-bindings",
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"vm-allocator",
"vm-device",
"vm-memory",
"vm-migration",
"vmm-sys-util",
vmm: Use virtio-blk to support booting from disk image After the virtio-blk device support has been introduced in the previous commit, the vmm need to rely on this new device to boot from disk images instead of initrd built into the kernel. In order to achieve the proper support of virtio-blk, this commit had to handle a few things: - Register an ioevent fd for each virtqueue. This important to be notified from the virtio driver that something has been written on the queue. - Fix the retrieval of 64bits BAR address. This is needed to provide the right address which need to be registered as the notification address from the virtio driver. - Fix the write_bar and read_bar functions. They were both assuming to be provided with an address, from which they were trying to find the associated offset. But the reality is that the offset is directly provided by the Bus layer. - Register a new virtio-blk device as a virtio-pci device from the vm.rs code. When the VM is started, it expects a block device to be created, using this block device as the VM rootfs. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2019-05-06 17:27:40 +00:00
]
cloud-hypervisor: Call into the test_vm() routine test_vm is a dummy VM workload, we use it to test our initial VMM settings. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-22 16:05:02 +00:00
[[package]]
name = "vmm"
version = "0.1.0"
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"acpi_tables",
"anyhow",
"arc-swap",
"arch",
"clap",
vmm: Add unit tests for DeviceTree Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2020-05-05 12:09:35 +00:00
"credibility",
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"devices",
"epoll",
"kvm-bindings",
"kvm-ioctls",
"lazy_static",
"libc",
"linux-loader",
"log 0.4.8",
"micro_http",
"net_util",
"pci",
"qcow",
"seccomp",
"serde",
"serde_derive",
"serde_json",
"signal-hook",
"tempfile",
vmm: memory_manager: Implement the Transportable trait This implements the send() function of the Transportable trait, so that the guest memory regions can be saved into one file per region. This will need to be extended for live migration, as it will require other transport methods and the recv() function will need to be implemented too. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2020-02-25 01:38:08 +00:00
"url",
vfio: Rename to vfio-ioctls Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-11-08 15:27:05 +00:00
"vfio-ioctls",
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"vm-allocator",
"vm-device",
"vm-memory",
"vm-migration",
"vm-virtio",
"vmm-sys-util",
vmm: Basic Vcpu implementation Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-28 14:26:30 +00:00
]
Bump vmm-sys-utils to 0.2.0 Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-10-23 07:44:42 +00:00
[[package]]
name = "vmm-sys-util"
build(deps): bump vmm-sys-util from 0.6.0 to 0.6.1 Bumps [vmm-sys-util](https://github.com/rust-vmm/vmm-sys-util) from 0.6.0 to 0.6.1. - [Release notes](https://github.com/rust-vmm/vmm-sys-util/releases) - [Changelog](https://github.com/rust-vmm/vmm-sys-util/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-vmm/vmm-sys-util/compare/v0.6.0...v0.6.1) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-10 09:43:20 +00:00
version = "0.6.1"
Bump vmm-sys-utils to 0.2.0 Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-10-23 07:44:42 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
build(deps): bump vmm-sys-util from 0.6.0 to 0.6.1 Bumps [vmm-sys-util](https://github.com/rust-vmm/vmm-sys-util) from 0.6.0 to 0.6.1. - [Release notes](https://github.com/rust-vmm/vmm-sys-util/releases) - [Changelog](https://github.com/rust-vmm/vmm-sys-util/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-vmm/vmm-sys-util/compare/v0.6.0...v0.6.1) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-10 09:43:20 +00:00
checksum = "183d25b56a61a6f518ef464ac578e790f04added34dfaab59a453d8a03cb7bd0"
Bump vmm-sys-utils to 0.2.0 Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-10-23 07:44:42 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"bitflags 1.2.1",
"libc",
Cargo: Update dependencies for the KVM serialization work We need the project to rely on kvm-bindings and kvm-ioctls branches which include the serde derive to be able to serialize and deserialize some KVM structures. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2020-02-17 14:28:24 +00:00
"serde",
"serde_derive",
Bump vmm-sys-utils to 0.2.0 Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-10-23 07:44:42 +00:00
]
build(deps): bump getrandom from 0.1.8 to 0.1.9 Bumps [getrandom](https://github.com/rust-random/getrandom) from 0.1.8 to 0.1.9. - [Release notes](https://github.com/rust-random/getrandom/releases) - [Changelog](https://github.com/rust-random/getrandom/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-random/getrandom/compare/v0.1.8...v0.1.9) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-14 16:19:06 +00:00
[[package]]
name = "wasi"
build(deps): bump getrandom from 0.1.13 to 0.1.14 Bumps [getrandom](https://github.com/rust-random/getrandom) from 0.1.13 to 0.1.14. - [Release notes](https://github.com/rust-random/getrandom/releases) - [Changelog](https://github.com/rust-random/getrandom/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-random/getrandom/compare/v0.1.13...v0.1.14) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-07 12:14:20 +00:00
version = "0.9.0+wasi-snapshot-preview1"
build(deps): bump getrandom from 0.1.8 to 0.1.9 Bumps [getrandom](https://github.com/rust-random/getrandom) from 0.1.8 to 0.1.9. - [Release notes](https://github.com/rust-random/getrandom/releases) - [Changelog](https://github.com/rust-random/getrandom/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-random/getrandom/compare/v0.1.8...v0.1.9) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-14 16:19:06 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "cccddf32554fecc6acb585f82a32a72e28b48f8c4c1883ddfeeeaa96f7d8e519"
build(deps): bump getrandom from 0.1.8 to 0.1.9 Bumps [getrandom](https://github.com/rust-random/getrandom) from 0.1.8 to 0.1.9. - [Release notes](https://github.com/rust-random/getrandom/releases) - [Changelog](https://github.com/rust-random/getrandom/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-random/getrandom/compare/v0.1.8...v0.1.9) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-08-14 16:19:06 +00:00
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
[[package]]
name = "winapi"
version = "0.2.8"
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "167dc9d6949a9b857f3451275e911c3f44255842c1f7a76f33c55103a909087a"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
[[package]]
name = "winapi"
build: Bump linux-loader and vm-memory dependencies linux-loader now uses the released vm-memory so we must move to that version at the same time. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2020-03-05 09:15:06 +00:00
version = "0.3.8"
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "8093091eeb260906a183e6ae1abdba2ef5ef2257a21801128899c3fc699229c6"
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"winapi-i686-pc-windows-gnu",
"winapi-x86_64-pc-windows-gnu",
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
]
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
[[package]]
name = "winapi-build"
version = "0.1.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "2d315eee3b34aca4797b2da6b13ed88266e6d612562a0c46390af8299fc699bc"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
[[package]]
name = "winapi-i686-pc-windows-gnu"
version = "0.4.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "ac3b87c63620426dd9b991e5ce0329eff545bccbbb34f3be09ff6fb6ab51b7b6"
cloud-hypervisor: Application handling We will only support a --kernel option for now. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:39:34 +00:00
[[package]]
name = "winapi-x86_64-pc-windows-gnu"
version = "0.4.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "712e227841d057c1ee1cd2fb22fa7e5a5461ae8e48fa2ca79ec42cfc1931183f"
cloud-hypervisor: Initial commit Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2019-02-21 16:04:44 +00:00
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
[[package]]
name = "ws2_32-sys"
version = "0.2.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
checksum = "d59cefebd0c892fa2dd6de581e937301d8552cb44489cdff035c6187cb63fa5e"
build: Run unit tests on the Jenkins server The addition of [workspace] to the top level Cargo.toml is necessary to have the binaries colocated together. The Cargo.lock files have also been refreshed by the change to the Cargo.toml. Signed-off-by: Rob Bradford <robert.bradford@intel.com>
2019-07-16 09:54:33 +00:00
dependencies = [
vm-migration: Define the Snapshottable and Transportable traits A Snapshottable component can snapshot itself and provide a MigrationSnapshot payload as a result. A MigrationSnapshot payload is a map of component IDs to a list of migration sections (MigrationSection). As component can be made of several Migratable sub-components (e.g. the DeviceManager and its device objects), a migration snapshot can be made of multiple snapshot itself. A snapshot is a list of migration sections, each section being a component state snapshot. Having multiple sections allows for easier and backward compatible migration payload extensions. Once created, a migratable component snapshot may be transported and this is what the Transportable trait defines, through 2 methods: send and recv. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
2019-05-01 16:59:51 +00:00
"winapi 0.2.8",
"winapi-build",
]
Reference in New Issue Copy Permalink