As was basically decided already a while ago, remove - in the simplest
possible way - the archiving of both qemu-s and mini-os from tarball
generation.
With this the subtree-force-update-all prereq isn't needed anymore in
the top level Makefile. That goal the also is unreferenced and hence is
bein
XSM is a generic framework, which in particular is also used by SILO.
With this it can't really be experimental: Arm mandates SILO for having
a security supported configuration.
Signed-off-by: Jan Beulich
---
v3: Add explanations. Another terminology adjustment.
v2: Terminology adjustments. Stron
flight 187237 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187237/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
The cloning from xmalloc.h happened long before Misra work started in
earnest, leading to the missing parameter name having been overlooked
later on.
Fixes: 9102fcd9579f ("mm: introduce xvmalloc() et al and use for grant table
allocations")
Signed-off-by: Jan Beulich
--- a/xen/include/xen/xvmal
flight 187229 xen-4.17-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187229/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 187191
test-amd64-amd64-xl-qemuu-win7-a
These three related patches were previously part of the AMX series.
For AVX10 some of this is going to be needed (or at least wanted) too,
though, hence I'm now refreshing these separately. Neither of the
three is strictly a functional prereq, but two of the three introduce
new functions which then
A maximum extended leaf input value with the high half different from
0x8000 should not be considered valid - all leaves should be cleared in
this case.
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
---
TBD: Andrew suggested to drop this patch, but that sub-thread still has
a loos
Zapping leaf data for out of range leaves is just one half of it: To
avoid guests (bogusly or worse) inferring information from mere leaf
presence, also shrink maximum indicators such that the respective
trailing entry is not all blank (unless of course it's the initial
subleaf of a leaf that's not
This change allows to put the trampoline in a separate, not executable
section. The trampoline contains a mix of code and data (data which
is modified from C code during early start so must be writable).
This is in preparation for W^X patch in order to satisfy UEFI CA
memory mitigation requirements
Instead of relocate the value at that position compute it
entirely and write it.
During EFI boots sym_offs(SYMBOL) are potentially relocated
causing the values to be corrupted.
For PVH and BIOS the change won't be necessary but keep the
code consistent.
Signed-off-by: Frediano Ziglio
---
xen/arc
In case EFI not multiboot rolling back relocation is done in
efi_arch_post_exit_boot, called by efi_start however this is
not done in multiboot code path.
Do it also for this path to make it work correctly.
Signed-off-by: Frediano Ziglio
---
xen/arch/x86/boot/Makefile | 2 +-
xen/arch/
No reason to wait, if Xen image is loaded by EFI (not multiboot
EFI path) these are set in efi_arch_load_addr_check, but
not in the multiboot EFI code path.
This change makes the 2 EFI code paths more similar and allows
the usage of these variables if needed.
Signed-off-by: Frediano Ziglio
---
x
Testing this feature in preparation for UEFI CA memory mitigation
requirements I found some issues causing the loading to fail and
other minor issues.
Details in series commit messages.
This is adding an additional way to boot Xen, using GrUB2+EFI
(xen.efi:__efi64_mb2_start).
Changes since v1:
- C
If code is loaded by EFI the loader will relocate the image
under 4GB. This causes offsets in x86 code generated by
sym_offs(SYMBOL) to be relocated too (basically they won't be
offsets from image base). In order to get wanted address
when using sym_offs an sym_esi compensate the difference
in %esi
Break out this logic from calculate_host_policy() to also use it in the
x86 emulator harness, where subsequently we'll want to avoid open-coding
AMX maximum palette bounding as well as AVX10 sub-feature pruning.
Signed-off-by: Jan Beulich
---
v4: Mark x86_cpu_policy_bound_max_leaves() __init. Add
AVX10.1 is just a re-branding of certain AVX512 (sub)features, i.e.
adds no new instructions. Therefore it's mostly relaxation that needs
doing, plus dealing with the 256-bit-only case that AVX512 itself
does not allow for. Luckily an unnecessary restriction on the mask
register insns was taken out
This requires bumping the number of basic leaves we support. Apart from
this the logic is modeled as closely as possible after that of leaf 7
handling.
Signed-off-by: Jan Beulich
---
The gen-cpuid.py adjustment is merely the minimum needed. It's not
really clear to me whether someone turning off
In preparation of introducing a const struct cpu_policy * local in
x86_emulate(), rename that global variable to something more suitable:
"cp" is our commonly used name for function parameters or local
variables of type struct cpu_policy *, and the present name of the
global could hence have interf
While of little effect right here, future patches (AVX10, AMX,
KeyLocker) will benefit more significantly.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1232,6 +1232,7 @@ x86_emulate(
{
/* Shadow copy of register st
This requires relaxing various pre-existing AVX512* checks, as AVX10.1
covers all AVX512* except PF, ER, 4FMAPS, 4VNNIW (support for all of
which was removed meanwhile anyway), and VP2INTERSECT. Yet potentially
with only less than 512-bit vector width, while otoh guaranteeing more
narrow widths bei
In preparation for having these also cover AVX10, use the helper
functions in preference of open-coded cpu_has_avx512* for those features
that AVX10 includes. Introduce a couple further helper functions where
they weren't previously needed.
Note that this way simd_check_avx512f_sha_vl() gains an A
AVX10.2 (along with APX) assigns new meaning to the bit that previsouly
distinguished EVEX from the Phi co-processor's MVEX. Therefore
evex_encoded() now needs to key off of something else: Use the opcode
mapping field for this, leveraging that map 0 has no assigned opcodes
(and appears unlikely to
Now that we have machinery in testcase.mk to set vector length dependent
flags for AVX512 tests, let's avoid using a pragma to enable AVX512VL
insns for the compiler. This way, correct settings are in place from the
very beginning of compilation.
No change to the generated test blobs, and hence no
AVX512VL not being a standalone feature anyway, but always needing
to be combined with some other AVX512*, replace uses of
cpu_has_avx512vl by just the feature bit check.
Signed-off-by: Jan Beulich
---
v2: Re-base over dropping of Xeon Phi support.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++
Re-use respective AVX512 tests, by suitably adjusting the predicate
functions. This leaves test names ("Testing ... NN-bit code sequence")
somewhat misleading, but I think we can live with that.
Note that the AVX512{BW,DQ} opmask tests cannot be run as-is for the
AVX10/256 case, as they include 51
Hi Amneesh,
On Fri, Aug 02, 2024 at 01:28:25PM +0530, Amneesh Singh wrote:
> diff --git a/tools/helpers/init-dom0less.c b/tools/helpers/init-dom0less.c
> index fee9345..a8cdc6d 100644
> --- a/tools/helpers/init-dom0less.c
> +++ b/tools/helpers/init-dom0less.c
> @@ -300,7 +301,7 @@ int main(int arg
boot_phys_offset stores the physical offset (PA-VA), is calculated in
the startup head.S code and passed to start_xen() as a first argument.
There is no point in using it given that we can ask MMU to translate
a VA for us using e.g. virt_to_{mfn,maddr}. Drop usage of these
variables from the C worl
Given no further use in C world of boot_phys_offset, drop it from the
argument list of start_xen() and do the necessary changes in the startup
code head.S (most notably modifying launch not to expect 2 arguments to
pass to C entry point).
Both on arm64 and arm32, phys offset (stored in x20 or r10
This has been on a TODO list for quite some time now. There is no real need
for these variables since we can ask the MMU to do the virt->maddr translation.
Michal Orzel (2):
xen/arm: Drop {boot_}phys_offset usage
xen/arm: head: Do not pass physical offset to start_xen
xen/arch/arm/arm32/head
On 26.07.2024 17:21, Roger Pau Monne wrote:
> XPTI being a speculation mitigation feels better to be initialized in
> spec_ctrl_init_domain().
>
> No functional change intended, although the call to spec_ctrl_init_domain() in
> arch_domain_create() needs to be moved ahead of pv_domain_initialise()
On 26.07.2024 17:21, Roger Pau Monne wrote:
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -2387,7 +2387,7 @@ By default SSBD will be mitigated at runtime (i.e
> `ssbd=runtime`).
>
> ### spec-ctrl (x86)
> > `= List of [ , xen=, {pv,hvm}=,
> ->
On 26.07.2024 17:21, Roger Pau Monne wrote:
> @@ -1673,13 +1668,14 @@ void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn,
> l4e_from_mfn(sl4mfn, __PAGE_HYPERVISOR_RW);
>
> /* Slot 260: Per-domain mappings. */
> -l4t[l4_table_offset(PERDOMAIN_VIRT_START)] =
> -l4e_from
Hi Jan,
On 14/08/2024 07:37, Jan Beulich wrote:
On 13.08.2024 19:13, Ayan Kumar Halder wrote:
From: Penny Zheng
Introduced CONFIG_VMAP which is selected by the architectures that use
MMU. vm_init() does not do anything if CONFIG_VMAP is not enabled.
VMAP is widely used in ALTERNATIVE feature
On 14.08.2024 12:55, Ayan Kumar Halder wrote:
> Hi Jan,
>
> On 14/08/2024 07:37, Jan Beulich wrote:
>> On 13.08.2024 19:13, Ayan Kumar Halder wrote:
>>> From: Penny Zheng
>>>
>>> Introduced CONFIG_VMAP which is selected by the architectures that use
>>> MMU. vm_init() does not do anything if CONF
On Tue, Aug 13, 2024 at 03:52:32PM -0700, Stefano Stabellini wrote:
> On Tue, 13 Aug 2024, Edgar E. Iglesias wrote:
> > On Mon, Aug 12, 2024 at 06:47:17PM -0700, Stefano Stabellini wrote:
> > > On Mon, 12 Aug 2024, Edgar E. Iglesias wrote:
> > > > From: "Edgar E. Iglesias"
> > > >
> > > > Add SMP
On Mon, Aug 12, 2024 at 06:47:51PM -0700, Stefano Stabellini wrote:
> On Mon, 12 Aug 2024, Edgar E. Iglesias wrote:
> > From: "Edgar E. Iglesias"
> >
> > Break out a common Xen PVH module in preparation for
> > adding a x86 Xen PVH Machine.
> >
> > Signed-off-by: Edgar E. Iglesias
> > ---
> >
Hi Jan,
On 14/08/2024 12:35, Jan Beulich wrote:
On 14.08.2024 12:55, Ayan Kumar Halder wrote:
Hi Jan,
On 14/08/2024 07:37, Jan Beulich wrote:
On 13.08.2024 19:13, Ayan Kumar Halder wrote:
From: Penny Zheng
Introduced CONFIG_VMAP which is selected by the architectures that use
MMU. vm_init(
On 12/08/2024 3:05 pm, Jan Beulich wrote:
> On 12.08.2024 15:04, Andrew Cooper wrote:
>> On 05/08/2024 2:26 pm, Jan Beulich wrote:
>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>>> @@ -839,7 +839,8 @@ protmode_load_seg(
>>> case x86_seg_t
Hi Ayan,
On 13/08/2024 19:13, Ayan Kumar Halder wrote:
> update_boot_mapping() invokes update_identity_mapping() for the MMU specific
> code.
> Later when the MPU code is added, update_boot_mapping() would invoke the
> equivalent.
>
> The common code now invokes update_boot_mapping() instead of
>
Hi Ayan,
On 13/08/2024 19:13, Ayan Kumar Halder wrote:
> Moved init_domheap_mappings(), map_domain_page_global(),
> unmap_domain_page_global(), map_domain_page(), unmap_domain_page(),
> domain_page_map_to_mfn() to MMU specific folder.
Both the commit title and msg seem incorrect (you took them fro
On 14.08.2024 14:33, Ayan Kumar Halder wrote:
> On 14/08/2024 12:35, Jan Beulich wrote:
>> On 14.08.2024 12:55, Ayan Kumar Halder wrote:
>>> On 14/08/2024 07:37, Jan Beulich wrote:
On 13.08.2024 19:13, Ayan Kumar Halder wrote:
> From: Penny Zheng
>
> Introduced CONFIG_VMAP which i
Hi Ayan,
On 13/08/2024 19:13, Ayan Kumar Halder wrote:
> All the EL2 MMU specific registers are enclosed within CONFIG_MMU.
"Also, protect vttbr_el2 field of struct reg_ctxt and accesses to it."
>
> Signed-off-by: Ayan Kumar Halder
Reviewed-by: Michal Orzel
~Michal
On 14.08.2024 14:49, Andrew Cooper wrote:
> On 12/08/2024 3:05 pm, Jan Beulich wrote:
>> On 12.08.2024 15:04, Andrew Cooper wrote:
>>> On 05/08/2024 2:26 pm, Jan Beulich wrote:
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -839,7 +839,8
On 14/08/2024 2:10 pm, Jan Beulich wrote:
> On 14.08.2024 14:49, Andrew Cooper wrote:
>> On 12/08/2024 3:05 pm, Jan Beulich wrote:
>>> On 12.08.2024 15:04, Andrew Cooper wrote:
On 05/08/2024 2:26 pm, Jan Beulich wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86
On 14.08.2024 14:49, Andrew Cooper wrote:
> On 12/08/2024 3:05 pm, Jan Beulich wrote:
>> On 12.08.2024 15:04, Andrew Cooper wrote:
>>> Also, looking at the emulator logic, we're missing the DPL vs
>>> CPL/RPL/Conforming checks.
>> There's surely nothing "conforming" for a nul selector. Hence perhap
flight 187239 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187239/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2024-31145 / XSA-460
version 2
error handling in x86 IOMMU identity mapping
UPDATES IN VERSION 2
Wording updated. Public release.
ISSUE DESCRIP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2024-31146 / XSA-461
version 2
PCI device pass-through with shared resources
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
===
On 14/08/2024 10:06, Jan Beulich wrote:
>
>
> The cloning from xmalloc.h happened long before Misra work started in
> earnest, leading to the missing parameter name having been overlooked
> later on.
>
> Fixes: 9102fcd9579f ("mm: introduce xvmalloc() et al and use for grant table
> allocatio
On 14/08/2024 9:06 am, Jan Beulich wrote:
> The cloning from xmalloc.h happened long before Misra work started in
> earnest, leading to the missing parameter name having been overlooked
> later on.
>
> Fixes: 9102fcd9579f ("mm: introduce xvmalloc() et al and use for grant table
> allocations")
> S
flight 187230 xen-4.18-testing real [real]
flight 187242 xen-4.18-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187230/
http://logs.test-lab.xenproject.org/osstest/logs/187242/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
On Tue, 2024-08-13 at 10:22 +0200, Jan Beulich wrote:
> On 09.08.2024 18:19, Oleksii Kurochko wrote:
> > --- a/xen/arch/riscv/include/asm/config.h
> > +++ b/xen/arch/riscv/include/asm/config.h
> > @@ -74,6 +74,14 @@
> > #error "unsupported RV_STAGE1_MODE"
> > #endif
> >
> > +#define XEN_VIRT_SI
On Tue, 2024-08-13 at 10:54 +0200, Jan Beulich wrote:
> On 09.08.2024 18:19, Oleksii Kurochko wrote:
> > Introduce struct pcpu_info to store pCPU-related information.
> > Initially, it includes only processor_id, but it will be extended
> > to include guest CPU information and temporary variables f
On 14.08.2024 16:21, oleksii.kuroc...@gmail.com wrote:
> On Tue, 2024-08-13 at 10:22 +0200, Jan Beulich wrote:
>> On 09.08.2024 18:19, Oleksii Kurochko wrote:
>>> --- a/xen/arch/riscv/include/asm/page.h
>>> +++ b/xen/arch/riscv/include/asm/page.h
>>> @@ -81,6 +81,12 @@ static inline void flush_page
On 14.08.2024 16:45, oleksii.kuroc...@gmail.com wrote:
> On Tue, 2024-08-13 at 10:54 +0200, Jan Beulich wrote:
>> On 09.08.2024 18:19, Oleksii Kurochko wrote:
>>> --- a/xen/arch/riscv/include/asm/smp.h
>>> +++ b/xen/arch/riscv/include/asm/smp.h
>>> @@ -5,6 +5,8 @@
>>> #include
>>> #include
>>>
On Mon, Aug 12, 2024 at 06:48:37PM -0700, Stefano Stabellini wrote:
> On Mon, 12 Aug 2024, Edgar E. Iglesias wrote:
> > From: "Edgar E. Iglesias"
> >
> > Add support for optionally creating a PCIe/GPEX controller.
> >
> > Signed-off-by: Edgar E. Iglesias
> > ---
> > hw/xen/xen-pvh-common.c
On Tue, 2024-08-13 at 11:34 +0200, Jan Beulich wrote:
> On 09.08.2024 18:19, Oleksii Kurochko wrote:
>
> > --- a/xen/arch/riscv/sbi.c
> > +++ b/xen/arch/riscv/sbi.c
> > @@ -7,11 +7,23 @@
> > * Modified by Bobby Eshleman (bobby.eshle...@gmail.com).
> > *
> > * Copyright (c) 2019 Western Digit
On 14.08.2024 10:54, Jan Beulich wrote:
> AVX10.2 (along with APX) assigns new meaning to the bit that previsouly
> distinguished EVEX from the Phi co-processor's MVEX. Therefore
> evex_encoded() now needs to key off of something else: Use the opcode
> mapping field for this, leveraging that map 0
On Mon, Aug 12, 2024 at 06:48:52PM -0700, Stefano Stabellini wrote:
> On Mon, 12 Aug 2024, Edgar E. Iglesias wrote:
> > From: "Edgar E. Iglesias"
> >
> > This adds a Xen PVH x86 machine based on the PVH Common
> > module used by the ARM PVH machine.
> >
> > Signed-off-by: Edgar E. Iglesias
> >
On 14.08.2024 17:41, oleksii.kuroc...@gmail.com wrote:
> On Tue, 2024-08-13 at 11:34 +0200, Jan Beulich wrote:
>> On 09.08.2024 18:19, Oleksii Kurochko wrote:
>>> +static unsigned long sbi_major_version(void)
>>> +{
>>> + return (sbi_spec_version >> SBI_SPEC_VERSION_MAJOR_SHIFT) &
>>> + S
Upon running `xen-cpuid -d` on a host machine with Sapphire Rapids
within Dom0, there exist unrecognised features.
This patch adds these features as macros to the CPU featureset,
disabled by default.
Signed-off-by: Matthew Barnes
---
xen/include/public/arch-x86/cpufeatureset.h | 12
On 14.08.2024 17:52, Matthew Barnes wrote:
> Upon running `xen-cpuid -d` on a host machine with Sapphire Rapids
> within Dom0, there exist unrecognised features.
Without looking at the particular bits yet, just a question up front:
Why SPR? There's newer hardware available with presumably yet more
flight 187231 xen-4.19-testing real [real]
flight 187245 xen-4.19-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187231/
http://logs.test-lab.xenproject.org/osstest/logs/187245/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
On 14/08/2024 4:58 pm, Jan Beulich wrote:
> On 14.08.2024 17:52, Matthew Barnes wrote:
>> Upon running `xen-cpuid -d` on a host machine with Sapphire Rapids
>> within Dom0, there exist unrecognised features.
> Without looking at the particular bits yet, just a question up front:
> Why SPR?
Because
On Tue, 2024-08-13 at 12:31 +0200, Jan Beulich wrote:
> On 09.08.2024 18:19, Oleksii Kurochko wrote:
> > Implement map_pages_to_xen() which requires several
> > functions to manage page tables and entries:
> > - pt_update()
> > - pt_mapping_level()
> > - pt_update_entry()
> > - pt_next_level()
> >
flight 187243 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187243/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 14/08/2024 4:52 pm, Matthew Barnes wrote:
> Upon running `xen-cpuid -d` on a host machine with Sapphire Rapids
I presume you mean -v ?
> within Dom0, there exist unrecognised features.
>
> This patch adds these features as macros to the CPU featureset,
> disabled by default.
>
> Signed-off-by:
Using the PVH entry point, the uncompressed vmlinux is loaded at
LOAD_PHYSICAL_ADDR, and execution starts in 32bit mode at the
address in XEN_ELFNOTE_PHYS32_ENTRY, pvh_start_xen, with paging
disabled.
Loading at LOAD_PHYSICAL_ADDR has not been a problem in the past as
virtual machines don't have c
The PVH entrypoint is 32bit non-PIC code running the uncompressed
vmlinux at its load address CONFIG_PHYSICAL_START - default 0x100
(16MB). The kernel is loaded at that physical address inside the VM by
the VMM software (Xen/QEMU).
When running a Xen PVH Dom0, the host reserved addresses are
The PVH entry point is 32bit. For a 64bit kernel, the entry point must
switch to 64bit mode, which requires a set of page tables. In the past,
PVH used init_top_pgt.
This works fine when the kernel is loaded at LOAD_PHYSICAL_ADDR, as the
page tables are prebuilt for this address. If the kernel
Sync Xen's elfnote.h header from xen.git to pull in the
XEN_ELFNOTE_PHYS32_RELOC define.
xen commit dfc9fab00378 ("x86/PVH: Support relocatable dom0 kernels")
This is a copy except for the removal of the emacs editor config at the
end of the file.
Signed-off-by: Jason Andryuk
Reviewed-by: Juerg
The PVH entry point will need an additional set of prebuild page tables.
Move the macros and defines to pgtable_64.h, so they can be re-used.
Signed-off-by: Jason Andryuk
---
v2:
Use existing pgtable_64.h
s/-/ - / in pud_index()
Did not add Juergen's R-b in case the header movement matters
---
a
phys_base needs to be set for __pa() to work in xen_pvh_init() when
finding the hypercall page. Set it before calling into
xen_prepare_pvh(), which calls xen_pvh_init(). Clear it afterward to
avoid __startup_64() adding to it and creating an incorrect value.
Signed-off-by: Jason Andryuk
Reviewe
On Wed, Aug 14, 2024 at 08:15:38AM +0200, Jürgen Groß wrote:
> On 14.08.24 00:36, Elliott Mitchell wrote:
> > On Tue, Aug 13, 2024 at 08:55:42PM +0200, Jürgen Groß wrote:
> > > On 13.08.24 19:49, Elliott Mitchell wrote:
> > > >
> > > > There is a possibility spurious interrupts are being turned in
Newer hardware may support FEAT_SME. Xen doesn't have any knowledge but
it will still expose the feature to the VM. If the OS is trying to use
SME, then it will crash.
Solve by hiding FEAT_SME.
Signed-off-by: Julien Grall
---
The current approach used to create the domain cpuinfo is to hide
(i
flight 187235 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187235/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-vhd broken
Tests which are fail
On 14/08/2024 9:34 am, Frediano Ziglio wrote:
> Testing this feature in preparation for UEFI CA memory mitigation
> requirements I found some issues causing the loading to fail and
> other minor issues.
> Details in series commit messages.
> This is adding an additional way to boot Xen, using GrUB2
flight 187238 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187238/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 187221
test-amd64-amd64-libvirt-xsm 15 migrate-s
On Wed, 14 Aug 2024, Edgar E. Iglesias wrote:
> On Mon, Aug 12, 2024 at 06:48:52PM -0700, Stefano Stabellini wrote:
> > On Mon, 12 Aug 2024, Edgar E. Iglesias wrote:
> > > From: "Edgar E. Iglesias"
> > >
> > > This adds a Xen PVH x86 machine based on the PVH Common
> > > module used by the ARM PV
On Wed, 14 Aug 2024, Edgar E. Iglesias wrote:
> On Mon, Aug 12, 2024 at 06:48:37PM -0700, Stefano Stabellini wrote:
> > On Mon, 12 Aug 2024, Edgar E. Iglesias wrote:
> > > From: "Edgar E. Iglesias"
> > >
> > > Add support for optionally creating a PCIe/GPEX controller.
> > >
> > > Signed-off-by:
On Wed, 14 Aug 2024, Edgar E. Iglesias wrote:
> On Tue, Aug 13, 2024 at 03:52:32PM -0700, Stefano Stabellini wrote:
> > On Tue, 13 Aug 2024, Edgar E. Iglesias wrote:
> > > On Mon, Aug 12, 2024 at 06:47:17PM -0700, Stefano Stabellini wrote:
> > > > On Mon, 12 Aug 2024, Edgar E. Iglesias wrote:
> > >
On 8/13/24 10:01, Jan Beulich wrote:
> On 12.08.2024 22:39, Stewart Hildebrand wrote:
>> In commit 4f78438b45e2 ("vpci: use per-domain PCI lock to protect vpci
>> structure") a lock moved from allocate_and_map_msi_pirq() to the caller
>> and changed from pcidevs_lock() to read_lock(&d->pci_lock). H
flight 187240 xen-4.17-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187240/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 187229
test-amd64-amd64-xl-qemuu-win7-a
83 matches
Mail list logo
