Create Boot-time MPU protection regions (similar to Armv8-R AArch64) for
Armv8-R AArch32.
Also, defined *_PRBAR macros for arm32. The only difference from arm64 is that
XN is 1-bit for arm32.
Define the system registers and macros in mpu/cpregs.h.
Introduce WRITE_SYSREG_ASM() to write to system registers in assembly.
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Tested-by: Luca Fancellu <luca.fancellu@arm.com>
regions.inc is added to hold the common earlyboot MPU regions configurations
between arm64 and arm32.
prepare_xen_region, fail_insufficient_regions() will be used by both arm32 and
arm64. Thus, they have been moved to regions.inc.
*_PRBAR are moved to arm64/sysregs.h.
*_PRLAR are moved to regions.inc as they are common between arm32 and arm64.
Introduce WRITE_SYSREG_ASM to write to the system registers from regions.inc.
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Tested-by: Luca Fancellu <luca.fancellu@arm.com>
The current logic in subpage_mmio_write_emulate() doesn't take into account
the page offset, and always performs the writes at offset 0 (start of the
page).
Fix this by accounting for the offset before performing the write.
Fixes: 8847d6e23f ('x86/mm: add API for marking only part of a MMIO page read only')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
BITS_PER_* values can be defined in a common way using compiler-provided macros.
Thus, these definitions are moved to xen/config.h to reduce duplication across
architectures.
Additionally, *_BYTEORDER macros are removed, as BITS_PER_* values now come
directly from the compiler environment.
The arch_fls() implementation for Arm and PPC is updated to use BITS_PER_INT
instead of a hardcoded value of 32.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>
All the x86 hardware runners are out of date, to varying degrees, in terms of
microcode.
Microcode must be uncompressed and prepended to the initrd in order for Xen to
be able to use it during early boot.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
The argo artefact is now a cpio archive and can be appended to dom?-rootfs
directly, rather than being part of of the overlay. Drop the
copy_dom?_files() functions.
xen-argo.ko has moved into the standard location, so update the insmod path.
No practical change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Use the new test-artifacts which provide rootfs.cpio.gz rather than
initrd.tar.gz. rootfs.cpio.gz also has all the necessary top-level
directories, and includes the rc_verbose setting, so these modifications can
be dropped.
Having that, do not repack the whole initrd, but only pack modified
files and rely on Linux handling of concatenated archives.
This allows packing just test-related files (which includes the whole
toolstack), instead of the whole initrd.
For xilinx-smoke-dom0-x86_64.sh, this involves instructing grub not to unzip
the archive, as doing so corrupts it.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Right now, we have initrd.cpio.gz as domU, and initrd.tar.gz as the base for
dom0.
Rename initrd.cpio.gz to domU-rootfs.cpio.gz, and xen-rootfs.cpio.gz to
dom0-rootfs.cpio.gz to make it clearer which is which. Rename the VM from
test to domU.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
The previous attempt has correct diagnosis, but added -notransfer flag
in a wrong place - it should be used in the first (outer) match out of
two, not the second (inner) one.
Fixes: 1e12cbd6af ("CI: fix waiting for final test message")
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
amd-cppc on active mode bypasses the scaling governor layer, and
provides its own P-state selection algorithms in hardware. Consequently,
when it is used, the driver's -> setpolicy() callback is invoked
to register per-CPU utilization update callbacks, not the ->target()
callback.
So, only when cpufreq_driver.setpolicy is NULL, we need to deliberately
set old gov as NULL to trigger the according gov starting.
Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Currently, the inclusion of libfdt is controlled by the CONFIG_HAS_DEVICE_TREE
kconfig flag. This flag also changes behavior in a few places, such as boot
module processing for XSM. To support the ability to include libfdt without
changing these behaviors, introduce CONFIG_LIBFDT. The inclusion of
libfdt is then moved under CONFIG_LIBFDT.
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Stack protector is meant to be enabled on all architectures, but
currently it is tested (and enabled) only on ARM, so mention it in ARM
section.
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Enable previously added CONFIG_STACK_PROTECTOR feature for ARM
platform. Initialize stack protector magic value very early, at the
very beginning of start_xen() function.
We want to do this early because prior to that
boot_stack_chk_guard_setup() call, default stack protector guard value
is used. While it is fine for general development and testing, it does
not provide highest security level, because potential attacker will
know the default value and can alter a payload, so correct stack
guard value will be placed in the correct position.
Apart from that argument, boot_stack_chk_guard_setup() should be
called prior to enabling secondary CPUs to avoid race with them.
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Both GCC and Clang support -fstack-protector feature, which add stack
canaries to functions where stack corruption is possible. This patch
makes general preparations to enable this feature on different
supported architectures:
- Added CONFIG_HAS_STACK_PROTECTOR option so each architecture
can enable this feature individually
- Added user-selectable CONFIG_STACK_PROTECTOR option
- Implemented code that sets up random stack canary and a basic
handler for stack protector failures
Stack guard value is initialized in two phases:
1. Pre-defined randomly-selected value.
2. Own implementation of linear congruent random number generator. It
relies on get_cycles() being available very early. If get_cycles()
returns zero, it would leave pre-defined value from the previous step.
boot_stack_chk_guard_setup() is declared as always_inline to ensure
that it will not trigger stack protector by itself. And of course,
caller should ensure that stack protection code will not be reached
later. It is possible to call the same function from an ASM code by
introducing simple trampoline in stack-protector.c, but right now
there is no use case for such trampoline.
As __stack_chk_fail() is not called by Xen source code directly, and
only called by compiler-generated code, it does not needed to be
declared separately. So we need separate MISRA deviation for it.
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Some of the uses of dom_cow aren't easily DCE-able (without extra
#ifdef-ary), and hence it being constantly NULL when MEM_SHARING=n
misguides Coverity into thinking that there may be a NULL deref in
if ( p2m_is_shared(t) )
d = dom_cow;
if ( get_page(page, d) )
return page;
(in get_page_from_mfn_and_type()). Help the situation by making
p2m_is_shared() be compile-time false when MEM_SHARING=n, thus also
permitting the compiler to DCE some other code.
Note that p2m_is_sharable() isn't used outside of mem_sharing.c, and
hence P2M_SHARABLE_TYPES can simply be left undefined when
MEM_SHARING=n.
Coverity ID: 1645573
Fixes: 79d91e178a ("dom_cow is needed for mem-sharing only")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tamas K Lengyel <tamas@tklengyel.com>
In GNU ld --disable-reloc-section implies --disable-dynamicbase (and
also --disable-high-entropy-va, just fyi). Therefore to yield
functionally identical binaries independent of whether mkreloc needs to
come into play, add --dynamicbase as well.
GNU ld further defaults to --high-entropy-va (along with --dynamicbase
and --nxcompat) unless "Cygwin-like". This seems wrong to me; that
default should be dependent upon "MinGW-like" instead; for the purpose
of building EFI binaries with a PE32+-capable ELF linker neither
"Cygwin-like" nor "MinGW-like" ought to be true. We certainly don't mean
to have this bit set in the DLL characteristics, so suppress its
setting.
Sadly while --high-entropy-va is supported by GNU ld 2.25,
--disable-high-entropy-va was introduced only in 2.36. Luckily the
defaulting to --high-entropy-va was also only introduced in 2.36. Plus
--disable-reloc-section was introduced precisely there, too. Hence
leverage the probing we do as to base relocation generation, to also
determine whether to pass --disable-high-entropy-va.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Upcoming changes won't unpack original rootfs anymore, so sed on
existing file cannot be used. Override the whole file instead.
No functional change intended.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
It appears as sometimes it takes more time for Xen even start booting,
mostly due to firmware and fetching large boot files by grub. In some
jobs the current timeout is pretty close to the actual time needed, and
sometimes (rarely for now) test fails due to timeout expiring in the
middle of dom0 booting. This will be happening more often if the
initramfs will grow (and with more complex tests).
This has been observed on some dom0pvh-hvm jobs, at least on runners hw3
and hw11.
Switch to using expect (console.exp) for more robust test output
handling. This allows waiting separately for Xen starting to boot and
then for the test to complete. For now, set both of those to 120s, which
pessimistically bumps timeout for the whole test to 240s (from 120s).
Add S3 handling to console.exp via SUSPEND_MSG + WAKEUP_CMD.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Expect normally discards initial part of its buffer after matching the
patter, before looking for the next one. If both PASSED and LOG_MSG
happen to be in the buffer at the same time, depending on their order,
only one will be matched and the waiting for the other will timeout.
Example expect -d output of this happening (parts eclipsed for brevity):
expect: does "\r\r\r\nWelcome to Alpine Linux 3.18\r\r\r\n...\r\r\r\r\n(domU) + echo 'pci test passed'\r\r\r\r\n(domU) pci test passed\r\r\r\r..." (spawn_id exp4) match regular expression "pci test passed"? Gate "pci test passed"? gate=yes re=yes
...
Gate keeper glob pattern for '\nWelcome to Alpine Linux' is '
Welcome to Alpine Linux'. Activating booster.
expect: does "'\r\r\r\r\n(domU) pci test passed\r\r\r\r\n(domU) [ ok ]\r\r\r\r\n(domU) [ ok ]\r\r\r\r\n(domU) \r\r\r\r\r\n(domU) domU Welcome to Alpine Linux 3.18\r\r\r\r\n(domU) \rKernel 6.6.56 on an x86_64 (/dev/hvc0)\r\r\r\r\n(domU) \r\r\r\r\r\n" (spawn_id exp4) match regular expression "\nWelcome to Alpine Linux"? Gate "\nWelcome to Alpine Linux"? gate=no
Fix this by using -notransfer flag to keep matched part in the buffer.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Acked-by: Andrew Cooper <andrew.cooper3@citix.com>
Add additional stage in console output parsing - wait for first message
from Xen. The message is defined via BOOT_MSG variable. This has two
effects:
- distinguishes failing Xen to load at all from later test failures
- resets timeout when Xen starts loading
The latter is especially relevant for hardware tests where firmware +
network boot may take some time before Xen starts booting. The two-stage
timeout is more robust solution than increasing the overall timeout.
The issue has been observed on some dom0pvh-hvm jobs, at least on
runners hw3 and hw11. This patch is a first stage before qubes-x86-64.sh
is switched to use expect in the next stage.
While at it, consistently use 'expect -re' for all matches. This
especially allows matching newlines ("\n"), which will become relevant
in the next patch. And document variables used in console.exp.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Introduce some basic infrastructure for doing rangeset unit tests, and add
a few tests that ensure correctness of rangeset subtraction.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Given the following rangset operation:
{ [0, 1], [4, 5] } - { [3, 4] }
The current rangeset logic will output a rangeset:
{ [0, 2], [5, 5] }
This is incorrect, and also has the undesirable property of being bogus in
a way that the resulting rangeset is expanded.
Fix this by making sure the bounds are correctly checked before modifying
the previous range.
Fixes: 484a058c48 ('Add auto-destructing per-domain rangeset data structure...')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The Eclair runners in GitlabCI have been update. This service is now
included, and redefining results in an error.
No functional change.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
This should have been dropped too, as the authoritative copy lives in another
repo now.
Fixes: babe11b46c ("CI: Drop alpine-3.18-rootfs-export and use test-artefacts")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Linux 6.6.56 was already added to test-artifacts for the argo testing, and
this removes one moving part while cleaning things up.
Drop the associated export job, and dockerfile.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
First, gfn can be set just once, rather than (conditionally) twice.
And then gfn can be used in two function calls, rather than re-
calculating the value there.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
The order of items is stored in .*.chk.cmd, and hence variations between
how items are ordered would result in re-invocation of the checking rule
during "make install-xen" despite that already having successfully run
earlier on. The difference can become noticable when building (as non-
root) and installing (as root) use different GNU make versions: In 3.82
the sorting was deliberately undone, just for it to be restored in 4.3.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Use %pd in all logs issued from arch_domain_create() and reword some of the
messages.
Also, expand error message in arch_domain_create() under !emulation_flags_ok()
case to help debugging.
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
boot_domain stores the domid until it is used to create (and allocate)
struct domain. d->domain_id is not available early enough.
boot_domain domids are initialized to DOMID_INVALID. If not overridden
by device tree, domids of DOMID_INVALID are assigned a valid value. The
domid will be optionally parsed from the device tree configuration.
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
To begin moving toward allowing the hypervisor to construct more than one
domain at boot, a container is needed for a domain's build information.
Introduce a new header, <xen/asm/bootdomain.h>, that contains the initial
struct boot_domain that encapsulate the build information for a domain.
Add a kernel and ramdisk boot module reference along with a struct domain
reference to the new struct boot_domain. This allows a struct boot_domain
reference to be the only parameter necessary to pass down through the domain
construction call chain.
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Signed-off-by: Alejandro Vallejo <agarciav@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Use of Xeon Phi features was dropped earlier on; this one was overlooked.
Fixes: 85191cf321 ("x86: drop Xeon Phi support")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
From their introduction all xc_hypercall_bounce_pre() uses, when they
failed, would properly cause exit from the function including cleanup,
yet without informing the caller of the failure. Purge the unlock_1
label for being both pointless and mis-named.
An earlier attempt to switch to the usual split between return value and
errno wasn't quite complete.
HWP work made the cleanup of the "available governors" array
conditional, neglecting the fact that the condition used may not be the
condition that was used to allocate the buffer (as the structure field
is updated upon getting back EAGAIN). Since cleanup can be done even if
no buffer was allocated, drop the conditional there again.
Fixes: 4513025a87 ("libxc: convert sysctl interfaces over to hypercall buffers")
Amends: 73367cf3b4 ("libxc: Fix xc_pm API calls to return negative error and stash error in errno")
Fixes: 31e264c672 ("pmstat&xenpm: Re-arrage for cpufreq union")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
The current implementation of PVH dom0 relies on vPCI to trap and handle
accesses to the MMCFG area. Previous implementation of PVH dom0 (v1)
didn't have vPCI, and as a classic PV dom0, relied on the MMCFG range being
RO. As such hvm_emulate_one_mmio() had to special case write accesses to
the MMCFG area.
With PVH dom0 using vPCI, and the MMCFG accesses being fully handled there,
hvm_emulate_one_mmio() should never handle accesses to MMCFG, making the
code effectively unreachable.
Remove it and leave an ASSERT to make sure MMCFG accesses never get into
hvm_emulate_one_mmio(). As a result of the removal of one of the users of
mmcfg_intercept_write(), the function can now be moved into the same
translation unit where it's solely used, allowing it to be made static and
effectively built only when PV support is enabled.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Document in the README how to rebuild all containers. This is helpful when
populating a local docker registry for testing purposes.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
AMD have updated the SB-7033 advisory to include Zen5 CPUs. Extend the digest
check to cover Zen5 too.
In practice, cover everything until further notice.
Observant readers may be wondering where the update to the digest list is. At
the time of writing, no Zen5 patches are available via a verifiable channel.
Link: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7033.html
Fixes: 630e8875ab ("x86/ucode: Perform extra SHA2 checks on AMD Fam17h/19h microcode")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
While building xen with GCC 14.2.1 with "-fcondition-coverage" option
or with "-Og", the compiler produces a false positive warning:
arch/x86/irq.c: In function ‘create_irq’:
arch/x86/irq.c:281:11: error: ‘desc’ may be used uninitialized [-Werror=maybe-uninitialized]
281 | ret = init_one_irq_desc(desc);
| ^~~~~~~~~~~~~~~~~~~~~~~
arch/x86/irq.c:269:22: note: ‘desc’ was declared here
269 | struct irq_desc *desc;
| ^~~~
cc1: all warnings being treated as errors
make[2]: *** [Rules.mk:252: arch/x86/irq.o] Error 1
While we have signed/unsigned comparison both in "for" loop and in
"if" statement, this still can't lead to use of uninitialized "desc",
as either loop will be executed at least once, or the function will
return early. So this is a clearly false positive warning due to a
bug [1] in GCC.
Initialize "desc" with NULL to make GCC happy.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119665
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Now that common-macros.h has STR() available, which is even slightly
more flexible, use that and drop the custom macros.
No difference in generated code (except for line numbers, of course,
where embedded in code/data).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
It's not used outside of the CU defining it, and it is clearly of
boolean nature.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Passing the -dumpversion option to gcc may only print the major version
(my system 4.x.y printed major and minor, which in nowaday's scheme is
then indeed just 5 for 5.x, which in turn is what my secondary system
compiler does).
Fixes: 40458f7525 ("Xen: Update compiler baseline checks")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
`QEMU_XEN_PATH` will be configured as `qemu-system-i386` with no clue where, if
`--with-system-qemu` is set without giving a path (as matched in the case `yes`
but not `*`). However, the existence of the executable is checked by `access()`,
that will not look for anywhere in $PATH but the current directory. And since it
is possible for `qemu-system-i386` (or any other configured values) to be
executed from PATH later, we'd better find that in PATH and return the full path
for the caller to check against.
Signed-off-by: Hongbo <hehongbo@mail.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
CPUID leaf 0x2 emits one-byte descriptors in its four output registers
EAX, EBX, ECX, and EDX. For these descriptors to be valid, the most
significant bit (MSB) of each register must be clear.
Leaf 0x2 parsing at intel.c only validated the MSBs of EAX, EBX, and
ECX, but left EDX unchecked.
Validate EDX's most-significant bit as well.
Fixes: 1aa6feb63b ("Port CPU setup code from Linux 2.6")
Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20250304085152.51092-3-darwi@linutronix.de
Use ARRAY_SIZE() though.
Origin: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 1881148215c6
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
A privileged domain can issue XEN_DOMCTL_vm_event_op with
op->domain == DOMID_INVALID. In this case vm_event_domctl()
function will get NULL as the first parameter and this will
cause hypervisor panic, as it tries to derefer this pointer.
Fix the issue by checking if valid domain is passed in.
Fixes: 48b8424945 ("xen/vm-event: Drop unused u_domctl parameter from vm_event_domctl()")
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
In order to close a race window for Xenstore live update when using
the new unique_id of domains, the migration stream needs to contain
this unique_id for each domain known by Xenstore.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
Change how PCI device lookup is done to handle also USB devices, in
which case get the USB controller. Instead of taking basename of the
'device' symlink, resolve the full path (example:
/sys/devices/pci0000:00/0000:00:09.0/usb4/4-7/4-7:1.0) and take the
first part after pci0000:00. Theoretically it could be a bridge, but VM
has flat PCI topology.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Ayan Kumar Halder