Sandbox:dev_watcher is a HashMap from a "device address" to a channel used
to notify get_device_name() that a suitable uevent has been found.
However, "device address" isn't well defined, having somewhat different
meanings for different device/event types. We never actually look up this
HashMap by key, except to remove entries.
Not looking up by key suggests that a map is not the appropriate data
structure here. Furthermore, HashMap imposes limitations on the types
which will prevent some future extensions we want.
So, replace the HashMap with a Vec<Option<>>. We need the Option<> so that
we can remove entries by index (removing them from the Vec completely would
hange the indices of other entries, possibly breaking concurrent work.
This does mean that the vector will keep growing as we watch for different
events during startup. However, we don't expect the number of device
events we watch for during a run to be very large, so that shouldn't be
a problem. We can optimize this later if it becomes a problem.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Currently, when Uevent::handle_block_add_event() receives an event matching
a registered watcher, it reports the /dev node name from the event back
to the watcher.
This changes it to report the entire uevent, not just the /dev node name.
This will allow various future extensions. It also makes the client side
of the uevent watching - get_device_name() - more consistent between its
two paths: finding a past uevent in Sandbox::uevent_map() or waiting for
a new uevent via a watcher.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Sandbox::pci_device_map contains a mapping from sysfs paths to /dev entries
which is used by get_device_name() to look up the right /dev node. But,
the map only supplies the answer if the uevent for the device has already
been received, otherwise get_device_name() has to wait for it.
However the matching for already-received and yet-to-come uevents isn't
quite the same which makes the whole system fragile.
In order to make sure the matching for both cases is identical, we need the
already-received side to store the whole uevent to match against, not just
the sysfs path and device name.
So, rename pci_device_map to uevent_map and store the whole uevent there
verbatim.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
In Kata 1.x, both the sysToDevMap and the deviceWatchers are in the sandbox
structure. For some reason in Kata 2.x, the device watchers have moved to
a separate global variable, GLOBAL_DEVICE_WATCHER.
This is a bad idea: apart from introducing an extra global variable
unnecessarily, it means that Sandbox::pci_device_map and
GLOBAL_DEVICE_WATCHER are protected by separate mutexes. Since the
information in these two structures has to be kept in sync with each other,
it makes much more sense to keep them both under the same single Sandbox
mutex.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
For the case of virtio-blk PCI devices, when matching uevents we create
a pci_p temporary. However, we build it incorrectly: the dev_addr values
we use for PCI devices are a relative sysfs paths from the PCI root to the
device in question *including an initial /*. But when we construct pci_p
we add an extra /, meaning the resulting path will *not* match properly.
AFAICT the only reason we got away with this is because in practice the
virtio-blk devices where discovered by the kernel before we looked for them
meaning the loosed matching in get_device_name() was used, rather than the
pci_p logic in handle_block_add_event().
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The current test_get_device_name(), ported from Kata 1.x doesn't really
reflect how the function is used in practice. The example path appears
to be for a virtio-blk device, but it's an s390 specific variant, not a
PCI device. The s390 form isn't actually supported by any of the existing
users of get_device_name().
Change it to a plausible virtio-blk-pci style path to better test how
get_device_name() will actually be used in practice.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Kata 1.x had a testcase for the equivalent getDeviceName function in Go,
this adapts it to Rust and adds it to Kata 2.x.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Rust 1.51 appears to have added a new warning in anticipation of Rust 2021,
which requires the format string for panic!()s (including via the various
assert!() macros) to be a string literal. This triggers quite a few times
in the agent code. This patch fixes them.
fixes#1626
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
While we introduced IMAGE_REGISTRY, we didn't actually update the
corresponding Dockerfiles to utilize it. Let's add
Fixes: #1622
Signed-off-by: Eric Ernst <eric.g.ernst@gmail.com>
This fixes the QAT driver version and provides a check early in the
building process to make sure the driver exists. It also provides
hints to users on how to fix themselves if the driver changes again.
Fixes: #1618
Signed-off-by: Eric Adams <eric.adams@intel.com>
Following what's been done in the past for 1.x repos, the version should
be 2.1.0-alpha1 (instead of 2.1-alpha1).
Fixes: #1617
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
There are many requests to the agent that happen with relatively
high frequency when a workload is running (checkRequest, as an example).
Let's move from Debug to Trace to avoid bombarding journal.
Signed-off-by: Eric Ernst <eric.g.ernst@gmail.com>
Instead of having different VERSION files spread accross the project,
let's always use the one in the topsrcdir and remove all the others,
keeping only a synlink to the topsrcdir one.
Fixes: #1579
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
This patch extends the current process of generating client code for
cloud-hypervisor API with an additional step, `go-fmt`, which will remove
the generated `client/go.mod` file and format all auto-generated code.
Fixes: #1606
Signed-off-by: Bo Chen <chen.bo@intel.com>
Highlights for cloud-hypervisor version 0.14.0 include: 1) Structured
event monitoring; 2) MSHV improvements; 3) Improved aarch64 platform; 4)
Updated hotplug documentation; 6) PTY control for serial and
virtio-console; 7) Block device rate limiting; 8) Plan to deprecate the
support of "LinuxBoot" protocol and support PVH protocol only.
Highlights for cloud-hypervisor version 0.13.0 include: 1) Wider VFIO
device support; 2) Improve huge page support; 3) MACvTAP support; 4) VHD
disk image support; 5) Improved Virtio device threading; 6) Clean
shutdown support via synthetic power button.
Details can be found:
https://github.com/cloud-hypervisor/cloud-hypervisor/releases
Note: The client code of cloud-hypervisor's OpenAPI is automatically
generated by `openapi-generator` [1-2]. As the API changes do not
impact usages in Kata, no additional changes in kata's runtime are
needed to work with the latest version of cloud-hypervisor.
[1] https://github.com/OpenAPITools/openapi-generator
[2] https://github.com/kata-containers/kata-containers/blob/main/src/runtime/virtcontainers/pkg/cloud-hypervisor/README.mdFixes: #1591
Signed-off-by: Bo Chen <chen.bo@intel.com>
As this repo is specific to the kata-containers 2.x, let's stop
mentioning / referring to the 1.x here, including how to setup and use
the snap package for 1.x.
Fixes: #1601
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
The installation guide points to 1.x packages from OBS. For 2.x we
decided to stop building packages on OBS in favour of advertising
kata-deploy.
Apart from this, Ubuntu itself doesn't provide packages for
kata-containers.
Fixes: #1588
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
This patch upgrades Firecracker version from v0.21.1 to v0.23.1
* Generate swagger models for v0.23.1 (from firecracker.yaml)
* Change uint64 types in TokenBucket object according to rate-limiter
implementation (introduced in commit #cfeb966)
* Update Firecracker Logger/Metrics to support the new API
* Update payload in fc.vmRunning to support the new API
* Add Metrics type to fcConfig
Fixes: #1518
Signed-off-by: Orestis Lagkas Nikolos <olagkasn@nubificus.co.uk>
Update how-to-use-k8s-with-cri-containerd-and-kata.md to fit the latest
Kubernetes way.
And also changed CNI plugin from flannel to bridge, that will be easy to run.
Fixes: #1325
Signed-off-by: bin <bin@hyper.sh>
There are two changes here. There first one being relying on the
`centos-release-advanced-virtualization` package instead providing the
content of the repo ourselves; and the second one being installing
`kata-containers` (2.x) instead of the `kata-runtime` one (1.x).
Fixes: #1583
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
The package to be installed on Fedora is `kata-containers` instead of
`kata-runtime`. The difference being `kata-runtime` is the 1.x package,
while `kata-containers` is the 2.x one.
Fixes: #1582
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
The content of the openSUSE installation guide is related to the 1.x
packages, as openSUSE doesn't provide katacontainers 2.x packages.
Fixes: #1585
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
The content of the SLE installation guide is related to the 1.x
packages, as SUSE doesn't provide katacontainers 2.x packages.
Fixes: #1586
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>