This enables the Windows test module. One basic test is enabled,
while all others are disabled yet for aarch64. Jenkins file is
extended with the corresponding step for aarch64.
installAzureCli() is parametrized.
It seems that transferring a 30GB image would take >= 15 minutes. An
optimization here is having a gzip'ed image to 10GB which would unpack
in 3 minutes. Expect to be quicker than transferring an uncompressed
image while on another network.
Signed-off-by: Anatol Belski <ab@php.net>
This removes the requirement for the tests (dev-dependencies) to build
with all supported toolchains including the MSRV.
See: #4318
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
Adding new I/O ports for both the ACPI shutdown and the ACPI PM timer
devices so they can be triggered from both addresses. The reason for
this change is that TDX expects only certain I/O ports to be enabled
based on what QEMU exposes. We follow this to avoid new ports from being
opened exclusively for Cloud Hypervisor.
We have to keep the former I/O ports available given all firmwares
haven't been updated yet. Once we reach a point where we know both Rust
Hypervisor Firmware, OVMF, TDVF and TDSHIM have been updated with the
new port values, we'll be able to remove the former ports.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
The current fuzzer defines a 'format' for the random input 'bytes' from
libfuzzer, but this 'format' failed to improve the fuzzing
efficiency. Instead, the 'format' parsing process obfuscates the fuzzer and
makes the fuzzing engine much harder to focus on the actual fuzzing
target (e.g. virtio-block queue event handling). It is actually worse than
simply using the random inputs as the virt queue content for fuzzing.
We can later introduce a different 'format' to the input 'bytes' for
better fuzzing, say focusing more on virito-block fuzzing through
ensuring the virt queue content always has a valid 'available'
descriptor chain to process.
Signed-off-by: Bo Chen <chen.bo@intel.com>
This also ensures that the 'queue_evt' is fully processed, as we enforce
the main thread is waiting for the virtio-block thread to process the
'kill_evt' which is after the 'queue_evt' processing.
Signed-off-by: Bo Chen <chen.bo@intel.com>
Currently the main thread returns immediately after sending a 'queue'
event which is rarely received and processed by the virtio-block
thread (unless system is in high workload). In this way, the fuzzer is
mostly doing nothing and is unable to reproduce its behavior
deterministically (from the same inputs). This patch relies on a
'level-triggered' epoll to ensure a 'queue' event is properly processed
before return from the main thread.
Signed-off-by: Bo Chen <chen.bo@intel.com>
The old API remains usable, and will remain usable for two releases but
we should only advertise the new API.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
Introduce a new top level member of VmConfig called PayloadConfig that
(currently) encompasses the kernel, commandline and initramfs for the
guest to use.
In future this can be extended for firmware use. The existing
"--kernel", "--cmdline" and "initramfs" CLI parameters now fill the
PayloadConfig.
Any config supplied which uses the now deprecated config members have
those members mapped to the new version with a warning.
See: #4445
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
Whenever starting a test with the capture_output option, both stdout and
stderr pipes are resized to a greater capacity. But the problem is that
when the system call fcntl() fails, we need to know about the error
returned by the system so that we can apply the necessary changes.
This patch simply enhances the error checking and reporting related to
the invocation of fcntl() when trying to resize a pipe.
Refers to #4475
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
The test test_virtio_block_topology has been recently failing due to an
error happening in losetup while trying to set the block size. Since
there's no option in losetup for retrying, we took the approach of
programming the expected behavior of creating a loop device relying
directly on the system ioctl LOOP_CONFIGURE. We apply a retry loop based
on the result returned by this ioctl, so that we don't fail on the first
try. We also added a sleep before retrying, hoping this would help the
next iteration to succeed.
Fixes#3494
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Remove the use of 'unwrap()' that assumes the guest address for request
status is always valid, which avoid virtio-block thread panic on
malformed descriptors from the guest.
Signed-off-by: Bo Chen <chen.bo@intel.com>
By checking in the validation logic we get checking for both devices
specified in the initial config but also hotplug too.
Fixes: #4453
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
There are PCI extended capabilities that can't be passed through the VM
as they would be unusable from a guest perspective. That's why we
introduce a way to patch what is returned to the guest when the PCI
configuration space is accessed. The list of patches is created from the
parsing of the extended capabilities in that case, and particularly
based on the presence of the SRIOV and Resizable BAR capabilities.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Signed-off-by: Steven Dake <sdake@lambdal.com>
The new option parsing for "[..,]" syntax is much stricter and requires
that everything is balanced in terms of brackets. Change the stripping
of the brackets to only strip the first and last one rather than
multiple:
e.g. "[[a,b], [c,d]]" becomes "[a,b],[c,d]" rather than "a,b], [c"
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
The parsing is now O(1) as we only consider each character in the input
once and further it removes the need for allocating memory for
reassembling the option parameter.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
If the BAR for the VFIO device is marked as prefetchable on the
underlying device ensure that the BAR exposed through PciConfiguration
is also marked as prefetchable.
Fixes problem where NVIDIA devices are not usable with PCI VFIO
passthrough. See related NVIDIA kernel driver bug:
https://github.com/NVIDIA/open-gpu-kernel-modules/issues/344.
Fixes: #4451
Signed-off-by: Steven Dake <sdake@lambdal.com>
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
