Memory node probing is done as part of early_scan_node() that is called
for each node with depth >= 1 (root node is at depth 0). According to
Devicetree Specification v0.4, chapter 3.4, /memory node can only exists
as a top level node. However, Xen incorrectly considers all the nodes with
unit node
On 26.06.2024 03:11, Stefano Stabellini wrote:
> On Tue, 25 Jun 2024, Jan Beulich wrote:
>> On 25.06.2024 02:54, Stefano Stabellini wrote:
>>> On Mon, 24 Jun 2024, Federico Serafini wrote:
Add break or pseudo keyword fallthrough to address violations of
MISRA C Rule 16.3: "An unconditiona
On 25.06.2024 21:31, Nicola Vetrini wrote:
> On 2024-03-12 09:16, Jan Beulich wrote:
>> On 11.03.2024 09:59, Simone Ballarin wrote:
>>> --- a/xen/arch/x86/Makefile
>>> +++ b/xen/arch/x86/Makefile
>>> @@ -258,18 +258,20 @@ $(obj)/asm-macros.i: CFLAGS-y += -P
>>> $(objtree)/arch/x86/include/asm/asm-
On 25.06.2024 20:09, Oleksii wrote:
> On Tue, 2024-06-25 at 16:45 +0200, Jan Beulich wrote:
>> On 25.06.2024 15:51, Oleksii Kurochko wrote:
>>> The following compilation error occurs:
>>> ./arch/riscv/include/asm/processor.h: Assembler messages:
>>> ./arch/riscv/include/asm/processor.h:70: Erro
On 2024-06-26 10:20, Jan Beulich wrote:
On 25.06.2024 21:31, Nicola Vetrini wrote:
On 2024-03-12 09:16, Jan Beulich wrote:
On 11.03.2024 09:59, Simone Ballarin wrote:
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -258,18 +258,20 @@ $(obj)/asm-macros.i: CFLAGS-y += -P
$(objtree)/a
On 25.06.2024 15:51, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/bitops.h
> @@ -0,0 +1,137 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/* Copyright (C) 2012 Regents of the University of California */
> +
> +#ifndef _ASM_RISCV_BITOPS_H
> +#define _ASM_RISCV_BITOPS_
flight 186507 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186507/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186451
test-amd64-amd64-libvirt 15 migrate-s
On 26/06/24 09:37, Oleksii wrote:
On Tue, 2024-06-25 at 18:59 -0700, Stefano Stabellini wrote:
+-doc_begin="The conversion from a function pointer to unsigned
long or (void *) does not lose any information, provided that the
target type has enough bits to store it."
+-config=MC3R1.R11.1,casts+={
On 26.06.2024 09:43, Ma Ke wrote:
> kasprintf() is used for formatting strings and dynamically allocating
> memory space. If memory allocation fails, kasprintf() will return NULL.
> We should add a check to ensure that failure does not occur.
>
> Fixes: d5de8841355a ("x86: split spinlock implement
On Wed, Jun 26, 2024 at 03:43:39PM +0800, Ma Ke wrote:
> kasprintf() is used for formatting strings and dynamically allocating
> memory space. If memory allocation fails, kasprintf() will return NULL.
> We should add a check to ensure that failure does not occur.
Did you also consider what happens
On 26.06.2024 07:54, Juergen Gross wrote:
> In case cpu_schedule_up() is failing, it needs to undo all externally
> visible changes it has done before.
>
> Reason is that cpu_schedule_callback() won't be called with the
> CPU_UP_CANCELED notifier in case cpu_schedule_up() did fail.
>
> Reported-b
On 25.06.2024 21:31, Nicola Vetrini wrote:
> On 2024-03-12 09:16, Jan Beulich wrote:
>> On 11.03.2024 09:59, Simone Ballarin wrote:
>>> --- a/xen/arch/x86/Makefile
>>> +++ b/xen/arch/x86/Makefile
>>> @@ -258,18 +258,20 @@ $(obj)/asm-macros.i: CFLAGS-y += -P
>>> $(objtree)/arch/x86/include/asm/asm-
flight 186511 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186511/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 78bccfec9ce5082499db035270e7998d5330d75c
baseline version:
ovmf e21bfae345f9eee1c3f58
On 2024-06-26 11:06, Jan Beulich wrote:
On 25.06.2024 21:31, Nicola Vetrini wrote:
On 2024-03-12 09:16, Jan Beulich wrote:
On 11.03.2024 09:59, Simone Ballarin wrote:
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -258,18 +258,20 @@ $(obj)/asm-macros.i: CFLAGS-y += -P
$(objtree)/a
On 25.06.2024 21:07, Andrew Cooper wrote:
> --- a/xen/include/xen/macros.h
> +++ b/xen/include/xen/macros.h
> @@ -59,6 +59,8 @@
> #define BUILD_BUG_ON(cond) ((void)BUILD_BUG_ON_ZERO(cond))
> #endif
>
> +#define BUILD_ERROR(msg) asm ( ".error \"" msg "\"" )
I think this wants a comment, and one
On 26.06.2024 11:20, Nicola Vetrini wrote:
> On 2024-06-26 11:06, Jan Beulich wrote:
>> On 25.06.2024 21:31, Nicola Vetrini wrote:
>>> On 2024-03-12 09:16, Jan Beulich wrote:
On 11.03.2024 09:59, Simone Ballarin wrote:
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @
Escape the final dot of the comment and extend the search of a
fallthrough comment up to 2 lines after the last statement.
Fixes: a128d8da913b ("automation/eclair: add deviations for MISRA C:2012 Rule
16.3")
Reported-by: Jan Beulich
Signed-off-by: Federico Serafini
Acked-by: Stefano Stabellini
Add missing break statements to address violations of MISRA C Rule
16.3: "An unconditional `break' statement shall terminate every
switch-clause".
No functional change.
Signed-off-by: Federico Serafini
---
Changes in v3:
- addressed all violations of R16.3 in vpmu_intel.c
---
xen/arch/x86/cpu/v
Add break or pseudo keyword fallthrough to address violations of
MISRA C Rule 16.3: "An unconditional `break' statement shall terminate
every switch-clause".
No functional change.
Signed-off-by: Federico Serafini
---
Changes in v3:
- use break instead of fallthrough.
---
xen/arch/x86/traps.c |
The current comment making explicit the fallthrough intention does
not follow the agreed syntax: replace it with the pseduo keyword.
No functional change.
Signed-off-by: Federico Serafini
Reviewed-by: Stefano Stabellini
Acked-by: Jan Beulich
---
xen/arch/x86/cpuid.c | 3 +--
1 file changed, 1
Add defensive return statement at the end of an unreachable
default case. Other than improve safety, this meets the requirements
to deviate a violation of MISRA C Rule 16.3: "An unconditional `break'
statement shall terminate every switch-clause".
Signed-off-by: Federico Serafini
---
Changes in v
Add a missing break statement to address a violation of
MISRA C Rule 16.3: "An unconditional `break' statement shall terminate
every switch-clause".
No functional change.
Signed-off-by: Federico Serafini
Reviewed-by: Stefano Stabellini
Acked-by: Jan Beulich
---
xen/arch/x86/mpparse.c | 1 +
1
Add missing break statement to address a violation of MISRA C
Rule 16.3: "An unconditional `break' statement shall terminate every
switch-clause".
No functional change.
Signed-off-by: Federico Serafini
Reviewed-by: Stefano Stabellini
Acked-by: Jan Beulich
---
xen/arch/x86/hvm/vlapic.c | 1 +
This patch series fixes a missing escape in a deviation and addresses some
violations.
Federico Serafini (12):
automation/eclair: fix deviation of MISRA C Rule 16.3
x86/cpuid: use fallthrough pseudo keyword
x86/domctl: address a violation of MISRA C Rule 16.3
x86/vpmu: address violations o
Add missing break statements to address violations of
MISRA C Rule 16.3: "An unconditional `break' statement shall terminate
every switch-clause".
No functional change.
Signed-off-by: Federico Serafini
Reviewed-by: Stefano Stabellini
Acked-by: Jan Beulich
---
xen/arch/x86/cpu/mcheck/mce_amd.c
Add missing break statement to address a violation of
MISRA C Rule 16.3: "An unconditional `break' statement shall terminate
every switch-clause".
No functional change.
Signed-off-by: Federico Serafini
Reviewed-by: Stefano Stabellini
Acked-by: Jan Beulich
---
xen/arch/x86/domctl.c | 1 +
1 fi
Add pseudo keyword fallthrough to meet the requirements to deviate
a violation of MISRA C Rule 16.3 ("An unconditional `break'
statement shall terminate every switch-clause").
No functional change.
Signed-off-by: Federico Serafini
---
Changes in v3:
- better indentation of fallthrough.
---
xen/
Add pseudokeyword fallthrough to meet the requirements to deviate
a violation of MISRA C Rul 16.3: "An unconditional `break' statement
shall terminate every switch-clause".
No functional change.
Signed-off-by: Federico Serafini
Reviewed-by: Stefano Stabellini
Acked-by: Jan Beulich
---
xen/arc
MISRA C Rule 16.3 states that "An unconditional `break' statement shall
terminate every switch-clause".
Add pseudo keyword fallthrough or missing break statement
to address violations of the rule.
As a defensive measure, return -EOPNOTSUPP in case an unreachable
return statement is reached.
Sign
On 25.06.2024 21:07, Andrew Cooper wrote:
> There are two issues. First, pi_test_and_clear_on() pulls the cache-line to
> the CPU and dirties it even if there's nothing outstanding, but the final
> for_each_set_bit() is O(256) when O(8) would do, and would avoid multiple
> atomic updates to the sa
On 26.06.2024 11:27, Federico Serafini wrote:
> This patch series fixes a missing escape in a deviation and addresses some
> violations.
>
> Federico Serafini (12):
> automation/eclair: fix deviation of MISRA C Rule 16.3
> x86/cpuid: use fallthrough pseudo keyword
> x86/domctl: address a vio
On 25.06.2024 21:07, Andrew Cooper wrote:
> The current implementation wants to take an in-memory bitmap. However, all
> ARM callers and all-but-1 x86 callers spill a scalar to the stack in order to
> use the "generic arbitrary bitmap" helpers under the hood.
>
> This functions, but it's far from
On 25.06.2024 21:07, Andrew Cooper wrote:
> The prior version (renamed to bitmap_for_each()) was inefficeint when used
> over a scalar, but this is the more common usage even before accounting for
> the many opencoded forms.
>
> Introduce a new version which operates on scalars only and does so wi
On 25.06.2024 21:07, Andrew Cooper wrote:
> In all 3 examples, we're iterating over a scaler. No caller can pass the
> COMPRESSED flag in, so the upper bound of 63, as opposed to 64, doesn't
> matter.
Not sure, maybe more a language question (for my education): Is "can"
really appropriate here? I
On 2024-06-26 11:26, Jan Beulich wrote:
On 26.06.2024 11:20, Nicola Vetrini wrote:
On 2024-06-26 11:06, Jan Beulich wrote:
On 25.06.2024 21:31, Nicola Vetrini wrote:
On 2024-03-12 09:16, Jan Beulich wrote:
On 11.03.2024 09:59, Simone Ballarin wrote:
--- a/xen/arch/x86/Makefile
+++ b/xen/arch
On 26.06.2024 12:25, Nicola Vetrini wrote:
> On 2024-06-26 11:26, Jan Beulich wrote:
>> On 26.06.2024 11:20, Nicola Vetrini wrote:
>>> On 2024-06-26 11:06, Jan Beulich wrote:
On 25.06.2024 21:31, Nicola Vetrini wrote:
> On 2024-03-12 09:16, Jan Beulich wrote:
>> On 11.03.2024 09:59, Si
On 25.06.2024 18:23, Oleksii wrote:
> On Tue, 2024-06-25 at 16:25 +0200, Jan Beulich wrote:
>> On 25.06.2024 15:51, Oleksii Kurochko wrote:
>>> During Gitlab CI randconfig job for RISC-V failed witn an error:
>>> common/trace.c:57:22: error: expected '=', ',', ';', 'asm' or
>>>
flight 186512 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186512/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf dc002d4f2d76bdd826359a3dd608d9bc621fcb47
baseline version:
ovmf 78bccfec9ce5082499db0
From: Alessandro Zucchelli
This addresses violations of MISRA C:2012 Rule 5.3 which states as
following: An identifier declared in an inner scope shall not hide an
identifier declared in an outer scope.
In this case the gloabl variable being shadowed is the global static struct
mctctl in this fi
On 26.06.24 11:02, Jan Beulich wrote:
On 26.06.2024 07:54, Juergen Gross wrote:
In case cpu_schedule_up() is failing, it needs to undo all externally
visible changes it has done before.
Reason is that cpu_schedule_callback() won't be called with the
CPU_UP_CANCELED notifier in case cpu_schedule
On 25.06.2024 21:07, Andrew Cooper wrote:
> --- a/xen/include/xen/bitops.h
> +++ b/xen/include/xen/bitops.h
> @@ -56,6 +56,16 @@ static always_inline __pure unsigned int ffs64(uint64_t x)
> return !x || (uint32_t)x ? ffs(x) : ffs(x >> 32) + 32;
> }
>
> +/*
> + * A type-generic ffs() whi
On 2024-06-24 3:36 pm, Teddy Astie wrote:
Hello Robin,
Thanks for the thourough review.
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 0af39bbbe3a3..242cefac77c9 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -480,6 +480,15 @@ config VIRTIO_IOMMU
Sa
Hi Tamas,
On 24/06/2024 23:18, Tamas K Lengyel wrote:
On Mon, Jun 24, 2024 at 5:58 PM Julien Grall wrote:
Hi,
On 21/06/2024 20:14, Tamas K Lengyel wrote:
The build integration script for oss-fuzz targets.
Do you have any details how this is meant and/or will be used?
https://google.gith
On 26/06/2024 10:49 am, Jan Beulich wrote:
> On 25.06.2024 21:07, Andrew Cooper wrote:
>> There are two issues. First, pi_test_and_clear_on() pulls the cache-line to
>> the CPU and dirties it even if there's nothing outstanding, but the final
>> for_each_set_bit() is O(256) when O(8) would do, and
On 26/06/2024 1:54 pm, Andrew Cooper wrote:
> On 26/06/2024 10:49 am, Jan Beulich wrote:
>> On 25.06.2024 21:07, Andrew Cooper wrote:
>>> There are two issues. First, pi_test_and_clear_on() pulls the cache-line to
>>> the CPU and dirties it even if there's nothing outstanding, but the final
>>> fo
On 26.06.2024 15:04, Andrew Cooper wrote:
> One final thing.
>
> This logic here depends on interrupts not being enabled between these
> atomic actions, and entering non-root mode.
>
> Specifically, Xen must not service a pending delivery-notification
> vector between this point and the VMEntry m
On Wed, Jun 26, 2024 at 8:41 AM Julien Grall wrote:
>
> Hi Tamas,
>
> On 24/06/2024 23:18, Tamas K Lengyel wrote:
> > On Mon, Jun 24, 2024 at 5:58 PM Julien Grall wrote:
> >>
> >> Hi,
> >>
> >> On 21/06/2024 20:14, Tamas K Lengyel wrote:
> >>> The build integration script for oss-fuzz targets.
>
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses".
The helper macro bitmap_switch has parameters that cannot be parenthesized
in order to comply with the rule, as that would break its functionality.
Moreover, the risk of misus
Remove from the ECLAIR integration scripts an unused option, which
was already ignored, and make the help texts consistent
with the rest of the scripts.
No functional change.
Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
---
automation/eclair_analysis/ECLAIR/analyze.sh | 3 +--
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses".
The local helpers GRP2 and XADD in the x86 emulator use their first
argument as the constant expression for a case label. This pattern
is deviated project-wide, because it is
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter
Hi all,
this series addresses several violations of Rule 20.7, as well as a
small fix to the ECLAIR integration scripts that do not influence
the current behaviour, but were mistakenly part of the upstream
configuration.
Note that by applying this series the rule has a few leftover violations.
Mo
On 2024-06-26 15:28, Nicola Vetrini wrote:
Hi all,
this series addresses several violations of Rule 20.7, as well as a
small fix to the ECLAIR integration scripts that do not influence
the current behaviour, but were mistakenly part of the upstream
configuration.
Note that by applying this seri
On Wed, Jun 26, 2024 at 12:31:42PM +0200, Jan Beulich wrote:
> On 26.06.2024 12:25, Nicola Vetrini wrote:
> > On 2024-06-26 11:26, Jan Beulich wrote:
> >> On 26.06.2024 11:20, Nicola Vetrini wrote:
> >>> On 2024-06-26 11:06, Jan Beulich wrote:
> On 25.06.2024 21:31, Nicola Vetrini wrote:
> >>>
Hi all,
Our next community call is on 4th July 2024. As this is a national holiday
in the US, I propose we move our call to the same time on *11th July 2024*
if there are no objections.
Details and agenda links will be sent that week.
Many thanks,
Kelly Choi
Community Manager
Xen Project
Hello Robin,
Le 26/06/2024 à 14:09, Robin Murphy a écrit :
> On 2024-06-24 3:36 pm, Teddy Astie wrote:
>> Hello Robin,
>> Thanks for the thourough review.
>>
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 0af39bbbe3a3..242cefac77c9 100644
--- a/drivers/iommu/Kconfi
flight 186510 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186510/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186499
test-amd64-amd64-xl-qemut-win7-amd64
I'm late to the party but there's something bothering me a little.
On Tue Jan 16, 2024 at 7:25 PM GMT, Elias El Yandouzi wrote:
> diff --git a/xen/common/vmap.c b/xen/common/vmap.c
> index 171271fae3..966a7e763f 100644
> --- a/xen/common/vmap.c
> +++ b/xen/common/vmap.c
> @@ -245,6 +245,11 @@ void
NOTE: This patch is be partially superseded by Andrew Cooper's "x86:
AMD CPUID handling improvements" series.
Currently, the CPUID leaf for SVM features (extd 0xa.edx) is manually
twiddled:
- hvm_max_policy takes host_policy and clamps it to supported
features (with some features unilaterally
Generally speaking, a VMEXIT/VMENTRY cycle should have at least three
trace records: the VMEXIT trace (which contains the processor-specific
exit code), a more generic Xen-based Xen event (an HVM_HANDLER trace
record), and a VMEXIT trace; and any given VMEXIT exit reason should
only have a single H
On SVM, VMEXIT that occur in when an L1 is in non-root mode ("nested
exits") are tagged with the TRC_HVM_NESTEDFLAG flag. Expand xenalyze
to do basic handling of these records:
- Refactor hvm_process to filter out both TRC_HVM_NESTEDFLAG and
TRC_64_FLAG when deciding how to process
- Create se
Commit 37f074a3383 ("x86/msr: introduce guest_rdmsr()") introduced a
function to combine the MSR_READ handling between PV and HVM.
Unfortunately, by returning directly, it skipped the trace generation,
leading to gaps in the trace record, as well as xenalyze errors like
this:
hvm_generic_postproce
The non-nested HVM code knows how to provide PCID functionality
(non-zero values in the lower 12 bits of CR3 when running in 64-bit
mode), but the nested code doesn't. If the L2 decides to use the PCID
functionality, the L0 will fail the next L1 VMENTRY.
Long term we definitely want to enable thi
hvmemul_read_cr ends up being called fairly freqently during
emulation; these are generally not necessary for understanding a
trace, and make processing more complicated (because they show up as
extra trace records within a vmexit/entry "arc" that must be
classified).
Leave the trace in write_cr,
Note that this trace is SVM-specific. Most HVM handler traces are
shared between VMX and SVM because the underlying instruction set is
largely the equivalent; but in this case, the instructions are
different enough that there's no sensible way to share HVM handler
traces between them.
Keeping the
VMX combines all exceptions into a single VMEXIT exit reason, and so
needs a separate HVM_HANDLER trace record (HVM_TRAP) to say which
exception happened; but for a number of exceptions, no further
information is put into the trace log.
SVM, by contrast, has a separate VMEXIT exit reason for each
Adding an HVM_TRAP trace record is redundant for EXCEPTION_AC: it adds
trace volume without adding any information, and xenalyze already
knows not to expect it. Remove it.
Signed-off-by: George Dunlap
---
xen/arch/x86/hvm/svm/svm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/xen/arch/x86
This is my work-in-progress series for getting nested virt working
again on AMD.
The first patch is an early draft to integrate the SVM bits into the
CPUID framework. It will be partially superseded by a series Andrew
has posted but which has not yet been checked in.
The second patch is a workar
There's a general issue with both PIO and MMIO reads (as detailed in
the comment); do a work-around for now.
Signed-off-by: George Dunlap
---
tools/xentrace/xenalyze.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
in
Basically this means adding VMEXIT strings for XSETBV exit, and adding
the handlers and strings for them.
Signed-off-by: George Dunlap
---
tools/xentrace/xenalyze.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
Signed-off-by: George Dunlap
---
xen/arch/x86/hvm/svm/nestedsvm.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c
index 35a2cbfd7d..dca06f2a6c 100644
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hv
Unfortunately I've forgotten exactly why I made this change. I
suspect that there were other traces (like MMIO traces) which were
being put before the NPF trace; but to understand the trace record
you'd want to have the NPF information first.
Signed-off-by: George Dunlap
---
xen/arch/x86/hvm/sv
There are already "HVM handler" trace records for writing to XCRs in
the context of an HVM guest. This trace is currently taken in
hvmemul_write_xcr.
However, both VMX and SVM vmexits call hvm_handle_xsetbv as a result
of an XSETBV vmexit, and hvm_handle_xsetbv calls x86emul_write_xcr
directly, b
On Wed, Jun 26, 2024 at 2:57 PM George Dunlap wrote:
>
> This is my work-in-progress series for getting nested virt working
> again on AMD.
Forgot to add, this can be found at this branch:
https://gitlab.com/xen-project/people/gdunlap/xen/-/commits/working/amd-nested-virt
-George
On Tue, Jun 25, 2024 at 10:02:42PM +0100, Andrew Cooper wrote:
> On 03/06/2024 3:59 pm, Matthew Barnes wrote:
> > xen-hvmcrash would previously save records, overwrite the instruction
> > pointer with a bogus value, and then restore them to crash a domain
> > just enough to cause the guest OS to me
On 2024-06-26 15:38, Anthony PERARD wrote:
On Wed, Jun 26, 2024 at 12:31:42PM +0200, Jan Beulich wrote:
On 26.06.2024 12:25, Nicola Vetrini wrote:
> On 2024-06-26 11:26, Jan Beulich wrote:
>> On 26.06.2024 11:20, Nicola Vetrini wrote:
>>> On 2024-06-26 11:06, Jan Beulich wrote:
On 25.06.202
flight 186513 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186513/
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
Hi Michal,
> On 26 Jun 2024, at 09:04, Michal Orzel wrote:
>
> Memory node probing is done as part of early_scan_node() that is called
> for each node with depth >= 1 (root node is at depth 0). According to
> Devicetree Specification v0.4, chapter 3.4, /memory node can only exists
> as a top lev
Hi Tamas,
On 26/06/2024 14:20, Tamas K Lengyel wrote:
On Wed, Jun 26, 2024 at 8:41 AM Julien Grall wrote:
Hi Tamas,
On 24/06/2024 23:18, Tamas K Lengyel wrote:
On Mon, Jun 24, 2024 at 5:58 PM Julien Grall wrote:
Hi,
On 21/06/2024 20:14, Tamas K Lengyel wrote:
The build integration scri
From: Teddy Astie
Some operating systems want to use IOMMU to implement various features (e.g
VFIO) or DMA protection.
This patch introduce a proposal for IOMMU paravirtualization for Dom0.
Signed-off-by Teddy Astie
---
docs/designs/pv-iommu.md | 105 +++
1
From: Teddy Astie
Introduce a new pv interface to manage the underlying IOMMU and manage contexts
and devices. This interface allows creation of new contexts from Dom0 and
addition of IOMMU mappings using guest PoV.
This interface doesn't allow creation of mapping to other domains.
Signed-off-b
This work has been presented at Xen Summit 2024 during the
IOMMU paravirtualization and Xen IOMMU subsystem rework
design session.
Operating systems may want to have access to a IOMMU in order to do DMA
protection or implement certain features (e.g VFIO on Linux).
VFIO support is mandatory for
From: Teddy Astie
Current IOMMU subsystem has some limitations that make PV-IOMMU practically
impossible.
One of them is the assumtion that each domain is bound to a single "IOMMU
domain", which
also causes complications with quarantine implementation.
Moreover, current IOMMU subsystem is not
From: Teddy Astie
Port the driver with guidances specified in iommu-contexts.md.
Add a arena-based allocator for allocating a fixed chunk of memory and
split it into 4k pages for use by the IOMMU contexts. This chunk size
is configurable with X86_ARENA_ORDER and dom0-iommu=arena-order=N.
Signed
From: Teddy Astie
Based on docs/designs/iommu-contexts.md, implement the redesigned IOMMU
subsystem.
Signed-off-by Teddy Astie
---
Changed in V2:
* cleanup some unneeded includes
* fix dangling devices in context on detach
---
xen/arch/x86/domain.c| 2 +-
xen/arch/x86/mm/p2m
On 26.06.2024 15:54, Alejandro Vallejo wrote:
> I'm late to the party but there's something bothering me a little.
>
> On Tue Jan 16, 2024 at 7:25 PM GMT, Elias El Yandouzi wrote:
>> diff --git a/xen/common/vmap.c b/xen/common/vmap.c
>> index 171271fae3..966a7e763f 100644
>> --- a/xen/common/vmap.
forgot to add that this patch series is rebased on top of staging
Teddy
Teddy Astie | Vates XCP-ng Intern
XCP-ng & Xen Orchestra - Vates solutions
web: https://vates.tech
Remain a Reviewer on the golang bindings and scheduler for now (using
a xenproject.org alias), since there may be architectural decisions I
can shed light on.
Remove the XENTRACE section entirely, as there's no obvious candidate
to take it over; having the respective parts fall back to the tools
a
flight 186516 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186516/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 89377ece8f1c7243d25fd84488dcd03e37b9e661
baseline version:
ovmf dc002d4f2d76bdd826359
hvmloader's cpuid() implementation deviates from Xen's in that the value passed
on ecx is unspecified. This means that when used on leaves that implement
subleaves it's unspecified which one you get; though it's more than likely an
invalid one.
Import Xen's implementation so there are no surprises
Make it so the APs expose their own APIC IDs in a LUT. We can use that LUT to
populate the MADT, decoupling the algorithm that relates CPU IDs and APIC IDs
from hvmloader.
While at this also remove ap_callin, as writing the APIC ID may serve the same
purpose.
Signed-off-by: Alejandro Vallejo
---
Add a helper to populate topology leaves in the cpu policy from
threads/core and cores/package counts. It's unit-tested in test-cpu-policy.c,
but it's not connected to the rest of the code yet.
Adds the ASSERT() macro to xen/lib/x86/private.h, as it was missing.
Signed-off-by: Alejandro Vallejo
Expose sensible topologies in leaf 0xb. At the moment it synthesises non-HT
systems, in line with the previous code intent.
Leaf 0xb in the host policy is no longer zapped and the guest {max,def} policies
have their topology leaves zapped instead. The intent is for toolstack to
populate them. Ther
This allows the initial x2APIC ID to be sent on the migration stream. This
allows further changes to topology and APIC ID assignment without breaking
existing hosts. Given the vlapic data is zero-extended on restore, fix up
migrations from hosts without the field by setting it to the old convention
This patch is a precondition for a later patch in which toolstack uses HVM
contexts to upload LAPIC data to a newly constructed domain.
If toolstack were to upload LAPIC contexts as part of domain creation as-is it
would encounter a problem were the architectural state does not reflect the APIC
ID
I've added the patches most critical to get into 4.19 at the head. They are
pretty well reviewed already and shouldn't be very contentious anymore.
v3 -> v4:
* Fixed cpuid() bug in hvmloader, causing UB in v3
* Fixed a bogus assert in hvmloader, also causing a crash in v3
* Used HVM contexts
While doing this, factor out checks common to architectural and hidden state.
Signed-off-by: Alejandro Vallejo
Reviewed-by: Roger Pau Monné
---
This puts essential LAPIC information in the stream. It's technically a feature
but it makes 4.19 guests a lot more future-proof. I think this should go
1 - 100 of 152 matches
Mail list logo
