flight 185902 linux-linus real [real]
flight 185905 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185902/
http://logs.test-lab.xenproject.org/osstest/logs/185905/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
flight 185904 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185904/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 248aa153f65866f46b5370ac2ef7dfaf3af72480
baseline version:
ovmf
flight 185901 linux-6.1 real [real]
flight 185903 linux-6.1 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185901/
http://logs.test-lab.xenproject.org/osstest/logs/185903/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 02/05/2024 2:25 pm, Andrew Cooper wrote:
> On 02/05/2024 2:21 pm, Juergen Gross wrote:
>> Today test-xenstore will write nodes with 3000 bytes node data. This
>> size is exceeding the default quota for the allowed node size. While
>> working in dom0 with C-xenstored, OCAML-xenstored does not
On Thu, 2 May 2024, Edgar E. Iglesias wrote:
> On Thu, May 2, 2024 at 8:53 PM Stefano Stabellini
> wrote:
> >
> > +Xenia
> >
> > On Thu, 2 May 2024, Edgar E. Iglesias wrote:
> > > On Wed, May 1, 2024 at 11:24 PM Stefano Stabellini
> > > wrote:
> > > >
> > > > On Tue, 30 Apr 2024, Edgar E.
On Thu, May 2, 2024 at 9:18 PM Stefano Stabellini
wrote:
>
> On Tue, 30 Apr 2024, Edgar E. Iglesias wrote:
> > From: "Edgar E. Iglesias"
> >
> > Add a second mapcache for grant mappings. The mapcache for
> > grants needs to work with XC_PAGE_SIZE granularity since
> > we can't map larger ranges
On Thu, May 2, 2024 at 8:53 PM Stefano Stabellini
wrote:
>
> +Xenia
>
> On Thu, 2 May 2024, Edgar E. Iglesias wrote:
> > On Wed, May 1, 2024 at 11:24 PM Stefano Stabellini
> > wrote:
> > >
> > > On Tue, 30 Apr 2024, Edgar E. Iglesias wrote:
> > > > From: "Edgar E. Iglesias"
> > > >
> > > > The
On Tue, 30 Apr 2024, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Add a second mapcache for grant mappings. The mapcache for
> grants needs to work with XC_PAGE_SIZE granularity since
> we can't map larger ranges than what has been granted to us.
>
> Like with foreign mappings
+Xenia
On Thu, 2 May 2024, Edgar E. Iglesias wrote:
> On Wed, May 1, 2024 at 11:24 PM Stefano Stabellini
> wrote:
> >
> > On Tue, 30 Apr 2024, Edgar E. Iglesias wrote:
> > > From: "Edgar E. Iglesias"
> > >
> > > The current mapcache assumes that all memory is mapped
> > > in a single RAM MR
On Tue, 30 Apr 2024, Luca Fancellu wrote:
> Commit 2209c1e35b47 ("xen/arm: Introduce a generic way to access memory
> bank structures") introduced a MISRA regression for Rule 1.1 because a
> flexible array member is introduced in the middle of a struct, furthermore
> this is using a GCC extension
On Tue, 30 Apr 2024, Luca Fancellu wrote:
> Import __struct_group from Linux, commit 50d7bd38c3aa
> ("stddef: Introduce struct_group() helper macro"), in order to
> allow the access through the anonymous structure to the members
> without having to write also the name, e.g:
>
> struct foo {
>
On Thu, 2 May 2024, Federico Serafini wrote:
> Update ECLAIR configuration to take into account the deviations
> agreed during MISRA meetings.
>
> Amend an existing entry of Rule 14.4 in deviations-rst:
> it is not a project-wide deviation.
>
> Tag Rule 14.4 as clean for arm.
>
> Signed-off-by:
On Thu, 2 May 2024, Andrew Cooper wrote:
> We deprecated the use of ---help--- a while ago, but a lot of new content
> copy bad examples. Convert the remaining instances, and update
> Kconfig's parser to no longer recongise it.
>
> This now causes builds to fail with:
>
> Kconfig.debug:8:
On Mon, 29 Apr 2024, Julien Grall wrote:
> Hi Juergen,
>
> On 29/04/2024 12:28, Jürgen Groß wrote:
> > On 29.04.24 13:04, Julien Grall wrote:
> > > Hi Juergen,
> > >
> > > Sorry for the late reply.
> > >
> > > On 29/04/2024 11:33, Juergen Gross wrote:
> > > > On 08.04.24 09:10, Jan Beulich
On Fri, 26 Apr 2024, Henry Wang wrote:
> If CONFIG_DEBUG=y, below assertion will be triggered:
> (XEN) Assertion 'rw_is_locked(_host_lock)' failed at
> drivers/passthrough/device_tree.c:146
> (XEN) [ Xen-4.19-unstable arm64 debug=y Not tainted ]
> (XEN) CPU: 0
> (XEN) PC:
We deprecated the use of ---help--- a while ago, but a lot of new content
copy bad examples. Convert the remaining instances, and update
Kconfig's parser to no longer recongise it.
This now causes builds to fail with:
Kconfig.debug:8: syntax error
Kconfig.debug:7: unknown statement
On Fri, 26 Apr 2024, Henry Wang wrote:
> For use cases such as Dom0less PV drivers, a mechanism to communicate
> Dom0less DomU's static data with the runtime control plane (Dom0) is
> needed. Since on Arm HVMOP is already the existing approach to address
> such use cases (for example the
On Tue, 30 Apr 2024, Henry Wang wrote:
> Hi Julien,
>
> On 4/30/2024 1:34 AM, Julien Grall wrote:
> > On 29/04/2024 04:36, Henry Wang wrote:
> > > Hi Jan, Julien, Stefano,
> >
> > Hi Henry,
> >
> > > On 4/24/2024 2:05 PM, Jan Beulich wrote:
> > > > On 24.04.2024 05:34, Henry Wang wrote:
> > > >
From: "Edgar E. Iglesias"
Use the generic xen/linkage.h macros to annotate code symbols
and add missing annotations.
Signed-off-by: Edgar E. Iglesias
---
xen/arch/arm/arm64/debug.S | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/arm64/debug.S
From: "Edgar E. Iglesias"
Use the generic xen/linkage.h macros to annotate code symbols.
Signed-off-by: Edgar E. Iglesias
---
xen/arch/arm/arm64/cache.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/arm64/cache.S b/xen/arch/arm/arm64/cache.S
index
From: "Edgar E. Iglesias"
Use the generic xen/linkage.h macros to annotate code symbols
and add missing annotations.
Signed-off-by: Edgar E. Iglesias
Reviewed-by: Stefano Stabellini
---
xen/arch/arm/arm64/entry.S | 72 +-
1 file changed, 48 insertions(+),
From: "Edgar E. Iglesias"
Use the generic xen/linkage.h macros to annotate code symbols
and add missing annotations.
Signed-off-by: Edgar E. Iglesias
---
xen/arch/arm/arm64/bpi.S | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/xen/arch/arm/arm64/bpi.S
From: "Edgar E. Iglesias"
Use the generic xen/linkage.h macros to annotate code symbols
and add missing annotations.
Signed-off-by: Edgar E. Iglesias
---
xen/arch/arm/arm64/smc.S | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/arm64/smc.S
From: "Edgar E. Iglesias"
Use the generic xen/linkage.h macros to annotate code symbols
and add missing annotations.
Signed-off-by: Edgar E. Iglesias
---
xen/arch/arm/arm64/mmu/head.S | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git
From: "Edgar E. Iglesias"
Use the generic xen/linkage.h macros to annotate code symbols.
Signed-off-by: Edgar E. Iglesias
---
xen/arch/arm/arm64/lib/memchr.S | 4 ++--
xen/arch/arm/arm64/lib/memcmp.S | 4 ++--
xen/arch/arm/arm64/lib/memcpy.S | 4 ++--
xen/arch/arm/arm64/lib/memmove.S | 4
From: "Edgar E. Iglesias"
Use the generic xen/linkage.h macros to annotate code symbols
and add missing annotations.
Signed-off-by: Edgar E. Iglesias
---
xen/arch/arm/arm64/sve-asm.S | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/arm64/sve-asm.S
From: "Edgar E. Iglesias"
Use the generic xen/linkage.h macros to annotate code symbols
and add missing annotations.
Signed-off-by: Edgar E. Iglesias
---
xen/arch/arm/arm64/head.S | 50 ---
1 file changed, 26 insertions(+), 24 deletions(-)
diff --git
From: "Edgar E. Iglesias"
On the way towards Xen safety certification we're evaluating the use
of tools to collect code-coverage/profiling information from execution
traces. Some tools rely on ELF symbols for code being declared with
type FUNC and having a symbol size.
We currently annotate
Add a command line parameter to allow the user to set the coloring
configuration for Dom0.
A common configuration syntax for cache colors is introduced and
documented.
Take the opportunity to also add:
- default configuration notion.
- function to check well-formed configurations.
Direct
Cache colored domains can benefit from having p2m page tables allocated
with the same coloring schema so that isolation can be achieved also for
those kind of memory accesses.
In order to do that, the domain struct is passed to the allocator and the
MEMF_no_owner flag is used.
This will be useful
Add a new "llc_colors" parameter that defines the LLC color assignment for
a domain. The user can specify one or more color ranges using the same
syntax used everywhere else for color config described in the
documentation.
The parameter is defined as a list of strings that represent the color
Add the "llc-colors" Device Tree attribute to express DomUs and Dom0less
color configurations.
Based on original work from: Luca Miccio
Signed-off-by: Carlo Nonato
Signed-off-by: Marco Solieri
---
v8:
- fixed memory leak on error path of domain_set_llc_colors_from_str()
- realloc colors array
Cache coloring must physically relocate Xen in order to color the hypervisor
and consider_modules() is a key function that is needed to find a new
available physical address.
672d67f339c0 ("xen/arm: Split MMU-specific setup_mm() and related code out")
moved consider_modules() under arm32. Move it
Last Level Cache (LLC) coloring allows to partition the cache in smaller
chunks called cache colors.
Since not all architectures can actually implement it, add a HAS_LLC_COLORING
Kconfig option.
MAX_LLC_COLORS_ORDER Kconfig option has a range maximum of 10 (2^10 = 1024)
because that's the number
Shared caches in multi-core CPU architectures represent a problem for
predictability of memory access latency. This jeopardizes applicability
of many Arm platform in real-time critical and mixed-criticality
scenarios. We introduce support for cache partitioning with page
coloring, a transparent
Add a new memory page allocator that implements the cache coloring mechanism.
The allocation algorithm enforces equal frequency distribution of cache
partitions, following the coloring configuration of a domain. This allows
for an even utilization of cache sets for every domain.
Pages are stored
Add the cache coloring support for Xen physical space.
Since Xen must be relocated to a new physical space, some relocation
functionalities must be brought back:
- the virtual address of the new space is taken from 0c18fb76323b
("xen/arm: Remove unused BOOT_RELOC_VIRT_START").
- relocate_xen()
From: Luca Miccio
Add a new command line parameter to configure Xen cache colors.
These colors are dumped together with other coloring info.
Benchmarking the VM interrupt response time provides an estimation of
LLC usage by Xen's most latency-critical runtime task. Results on Arm
Cortex-A53 on
Cache coloring requires Dom0 not to be direct-mapped because of its non
contiguous mapping nature, so allocate_memory() is needed in this case.
8d2c3ab18cc1 ("arm/dom0less: put dom0less feature code in a separate module")
moved allocate_memory() in dom0less_build.c. In order to use it
in Dom0
LLC coloring needs to know the last level cache layout in order to make the
best use of it. This can be probed by inspecting the CLIDR_EL1 register,
so the Last Level is defined as the last level visible by this register.
Note that this excludes system caches in some platforms.
Static memory
PGC_static and PGC_extra needs to be preserved when assigning a page.
Define a new macro that groups those flags and use it instead of or'ing
every time.
To make preserved flags even more meaningful, they are kept also when
switching state in mark_page_free().
Enforce the removal of PGC_extra
Add a new domctl hypercall to allow the user to set LLC coloring
configurations. Colors can be set only once, just after domain creation,
since recoloring isn't supported.
Based on original work from: Luca Miccio
Signed-off-by: Carlo Nonato
Signed-off-by: Marco Solieri
---
v8:
- fixed memory
On Fri, Apr 26, 2024 at 1:14 AM Stefano Stabellini
wrote:
>
> On Tue, 16 Apr 2024, Edgar E. Iglesias wrote:
> > From: "Edgar E. Iglesias"
> >
> > Use the generic xen/linkage.h macros when and add missing
> ^ when what?
>
> > code symbol annotations.
> >
>
flight 185899 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185899/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-examine 8 reboot fail REGR. vs. 185870
Tests which are
Updates so request_irq() can be used with a dynamically assigned SGI irq
as input. This prepares for a later patch where an FF-A schedule
receiver interrupt handler is installed for an SGI generated by the
secure world.
>From the Arm Base System Architecture v1.0C [1]:
"The system shall implement
Replace read_atomic() with ACCESS_ONCE() to match the intended use, that
is, to prevent the compiler from (via optimization) reading shared
memory more than once.
Signed-off-by: Jens Wiklander
Reviewed-by: Bertrand Marquis
---
xen/arch/arm/tee/ffa_shm.c | 15 ---
1 file changed, 8
Hi,
This patch set adds support for FF-A notifications. We only support
global notifications, per vCPU notifications remain unsupported.
The first three patches are further cleanup and can be merged before the
rest if desired.
A physical SGI is used to make Xen aware of pending FF-A
Add support for FF-A notifications, currently limited to an SP (Secure
Partition) sending an asynchronous notification to a guest.
Guests and Xen itself are made aware of pending notifications with an
interrupt. The interrupt handler retrieves the notifications using the
FF-A ABI and deliver them
Simplify ffa_handle_mem_share() by removing the start_page_idx and
last_page_idx parameters from get_shm_pages() and check that the number
of pages matches expectations at the end of get_shm_pages().
Signed-off-by: Jens Wiklander
Reviewed-by: Bertrand Marquis
---
xen/arch/arm/tee/ffa_shm.c |
Refactors the large switch block in ffa_handle_call() to use common code
for the simple case where it's either an error code or success with no
further parameters.
Signed-off-by: Jens Wiklander
Reviewed-by: Bertrand Marquis
---
xen/arch/arm/tee/ffa.c | 30 ++
1 file
flight 185900 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185900/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf fecf55a66a1cf908c2f906bedb79fe2e8362d50f
baseline version:
ovmf
On 02/05/2024 07:57, Jan Beulich wrote:
> On 02.05.2024 08:55, Jan Beulich wrote:
>> On 01.05.2024 18:35, Alejandro Vallejo wrote:
>>> Hi,
>>>
>>> On 26/03/2024 16:41, Jan Beulich wrote:
On 09.01.2024 16:38, Alejandro Vallejo wrote:
> --- a/xen/lib/x86/policy.c
> +++
On Thu, May 02, 2024 at 03:16:54PM +0200, Jan Beulich wrote:
> On 02.05.2024 13:49, Roger Pau Monne wrote:
> > Like it was done recently for libxl, switch to using the auto-generated
> > feature
> > names by the processing of cpufeatureset.h, this allows removing the
> > open-coded
> > feature
On 02.05.2024 15:24, Andrew Cooper wrote:
> On 02/05/2024 1:39 pm, Jan Beulich wrote:
>> On 29.04.2024 20:28, Andrew Cooper wrote:
>>> Make use of the new xstate_uncompressed_size() helper rather than
>>> maintaining
>>> the running calculation while accumulating feature components.
>>
On 02/05/2024 2:04 pm, Jan Beulich wrote:
> On 29.04.2024 20:28, Andrew Cooper wrote:
>> If max leaf is greater than 0xd but xsave not available to the guest, then
>> the
>> current XSAVE size should not be filled in. This is a latent bug for now as
>> the guest max leaf is 0xd, but will become
On 02/05/2024 2:21 pm, Juergen Gross wrote:
> Today test-xenstore will write nodes with 3000 bytes node data. This
> size is exceeding the default quota for the allowed node size. While
> working in dom0 with C-xenstored, OCAML-xenstored does not like that.
>
> Use a size of 2000 instead, which is
On 02/05/2024 1:39 pm, Jan Beulich wrote:
> On 29.04.2024 20:28, Andrew Cooper wrote:
>> Make use of the new xstate_uncompressed_size() helper rather than maintaining
>> the running calculation while accumulating feature components.
> xstate_uncompressed_size() isn't really a new function, but the
Today test-xenstore will write nodes with 3000 bytes node data. This
size is exceeding the default quota for the allowed node size. While
working in dom0 with C-xenstored, OCAML-xenstored does not like that.
Use a size of 2000 instead, which is lower than the allowed default
node size of 2048.
On 02.05.2024 13:49, Roger Pau Monne wrote:
> Like it was done recently for libxl, switch to using the auto-generated
> feature
> names by the processing of cpufeatureset.h, this allows removing the
> open-coded
> feature names, and unifies the feature naming with libxl and the hypervisor.
>
>
On 02/05/2024 1:19 pm, Jan Beulich wrote:
> On 29.04.2024 20:28, Andrew Cooper wrote:
>> @@ -567,16 +567,51 @@ static unsigned int hw_uncompressed_size(uint64_t xcr0)
>> return size;
>> }
>>
>> -/* Fastpath for common xstate size requests, avoiding reloads of xcr0. */
>> -unsigned int
Update ECLAIR configuration to take into account the deviations
agreed during MISRA meetings.
Amend an existing entry of Rule 14.4 in deviations-rst:
it is not a project-wide deviation.
Tag Rule 14.4 as clean for arm.
Signed-off-by: Federico Serafini
---
Changes in v2:
- reordered deviations
On 29.04.2024 20:28, Andrew Cooper wrote:
> If max leaf is greater than 0xd but xsave not available to the guest, then the
> current XSAVE size should not be filled in. This is a latent bug for now as
> the guest max leaf is 0xd, but will become problematic in the future.
Why would this not be
On 29.04.2024 20:28, Andrew Cooper wrote:
> Make use of the new xstate_uncompressed_size() helper rather than maintaining
> the running calculation while accumulating feature components.
xstate_uncompressed_size() isn't really a new function, but the re-work of
an earlier one. That, aiui, could
On 02.05.2024 14:14, Andrew Cooper wrote:
> On 30/04/2024 1:54 pm, Roger Pau Monné wrote:
>> On Tue, Apr 30, 2024 at 02:06:38PM +0200, Jan Beulich wrote:
>>> On 30.04.2024 13:25, Roger Pau Monné wrote:
On Tue, Apr 30, 2024 at 12:37:44PM +0200, Jan Beulich wrote:
> On 30.04.2024 10:29,
On 29.04.2024 20:28, Andrew Cooper wrote:
> @@ -567,16 +567,51 @@ static unsigned int hw_uncompressed_size(uint64_t xcr0)
> return size;
> }
>
> -/* Fastpath for common xstate size requests, avoiding reloads of xcr0. */
> -unsigned int xstate_ctxt_size(u64 xcr0)
> +unsigned int
On 30/04/2024 1:54 pm, Roger Pau Monné wrote:
> On Tue, Apr 30, 2024 at 02:06:38PM +0200, Jan Beulich wrote:
>> On 30.04.2024 13:25, Roger Pau Monné wrote:
>>> On Tue, Apr 30, 2024 at 12:37:44PM +0200, Jan Beulich wrote:
On 30.04.2024 10:29, Roger Pau Monne wrote:
> @@ -301,21 +52,32 @@
On 29.04.2024 20:28, Andrew Cooper wrote:
> HVM_CPU_XSAVE_SIZE() may rewrite %xcr0 twice. Defer the caluclation it until
> after we've decided to write out an XSAVE record.
>
> Note in hvm_load_cpu_xsave_states() that there were versions of Xen which
> wrote out a useless XSAVE record. This
On Thu, May 2, 2024 at 8:36 AM Jan Beulich wrote:
>
> On 30.04.2024 17:40, Petr Beneš wrote:
> > On Tue, Apr 30, 2024 at 4:47 PM Jan Beulich wrote:
> >>
> >> On 28.04.2024 18:52, Petr Beneš wrote:
> >>> From: Petr Beneš
> >>>
> >>> This change anticipates scenarios where `max_altp2m` is set to
Like it was done recently for libxl, switch to using the auto-generated feature
names by the processing of cpufeatureset.h, this allows removing the open-coded
feature names, and unifies the feature naming with libxl and the hypervisor.
Introduce a newly auto-generated array that contains the
flight 185897 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185897/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 185890
> On 2 May 2024, at 11:30, Jan Beulich wrote:
>
> On 02.05.2024 12:12, Luca Fancellu wrote:
In any case it would be used soon also for other architectures using
bootinfo.
>>>
>>> Oh, would it?
>>
>> PPC people have plans on putting that interface in common:
>
> I'm aware, but
On Thu, May 02, 2024 at 10:46:12AM +0200, Oleksii wrote:
> On Tue, 2024-04-30 at 17:34 +0200, Roger Pau Monne wrote:
> > None of the implementations support set_foreign_p2m_entry() yet,
> > neither they
> > have a p2m walk in domain_relinquish_resources() in order to remove
> > the foreign
> >
On 02.05.2024 12:12, Luca Fancellu wrote:
>>> In any case it would be used soon also for other architectures using
>>> bootinfo.
>>
>> Oh, would it?
>
> PPC people have plans on putting that interface in common:
I'm aware, but ...
>
>
>> In any case it would be used soon also for other architectures using
>> bootinfo.
>
> Oh, would it?
PPC people have plans on putting that interface in common:
On Mon, 2024-04-29 at 15:30 +0200, Jan Beulich wrote:
> On 26.04.2024 17:23, Oleksii Kurochko wrote:
> > Now, the check-extension() macro has 1 argument instead of 2.
> > This change helps to reduce redundancy around usage of extensions
> > name (in the case of the zbb extension, the name was used
On 02.05.2024 10:13, Luca Fancellu wrote:
>
>
>> On 2 May 2024, at 07:43, Jan Beulich wrote:
>>
>> On 02.05.2024 08:33, Luca Fancellu wrote:
>>>
>>>
On 2 May 2024, at 07:14, Jan Beulich wrote:
On 01.05.2024 08:57, Luca Fancellu wrote:
> Hi Jan,
>
>> On 30 Apr 2024,
On 02/05/2024 10:22 am, Juergen Gross wrote:
> In case a test is failing in test-xenstore, let the tool exit with an
> exit status other than 0.
>
> Fix a typo in an error message.
>
> Reported-by: Andrew Cooper
> Fixes: 3afc5e4a5b75 ("tools/tests: add xenstore testing framework")
>
In case a test is failing in test-xenstore, let the tool exit with an
exit status other than 0.
Fix a typo in an error message.
Reported-by: Andrew Cooper
Fixes: 3afc5e4a5b75 ("tools/tests: add xenstore testing framework")
Signed-off-by: Juergen Gross
---
tools/tests/xenstore/test-xenstore.c
Separate Intel/AMD-specific MCE code using CONFIG_{INTEL,AMD} config options.
Now we can avoid build of mcheck code if support for specific platform is
intentionally disabled by configuration.
Add default return value to init_nonfatal_mce_checker() routine -- in case
of a build with both AMD and
flight 185896 linux-linus real [real]
flight 185898 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185896/
http://logs.test-lab.xenproject.org/osstest/logs/185898/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
Guard calls to CPU-specific mcheck init routines in common MCE code
using new INTEL/AMD config options.
The purpose is not to build platform-specific mcheck code and calls to it,
if this platform is disabled in config.
Signed-off-by: Sergiy Kibrik
Reviewed-by: Stefano Stabellini
CC: Jan
Add build-time checks for newly introduced INTEL/AMD config options when
calling vmce_{intel/amd}_{rdmsr/wrmsr}() routines.
This way a platform-specific code can be omitted in vmce code, if this
platform is disabled in config.
Signed-off-by: Sergiy Kibrik
Reviewed-by: Stefano Stabellini
CC: Jan
Moving this function out of mce_intel.c would make it possible to disable
build of Intel MCE code later on, because the function gets called from
common x86 code.
Add internal check for CONFIG_INTEL option, as MCG_LMCE_P bit is currently
specific to Intel CPUs only.
Also replace boilerplate code
Build AMD vPMU when CONFIG_AMD is on, and Intel vPMU when CONFIG_INTEL
is on respectively, allowing for a plaftorm-specific build.
No functional change intended.
Signed-off-by: Sergiy Kibrik
Reviewed-by: Stefano Stabellini
CC: Andrew Cooper
CC: Jan Beulich
---
changes in v2:
- drop static
Here's a second attempt to separate support of Intel & AMD CPUs in Xen build.
The code to drive both platforms used to be built unconditionally, until recent
introduction of CONFIG_{AMD,INTEL} Kconfig options.
This series extends coverage of these options on vpmu and mcheck subsystems,
which
29.04.24 18:54, Jan Beulich:
On 27.04.2024 01:16, Stefano Stabellini wrote:
On Tue, 23 Apr 2024, Sergiy Kibrik wrote:
--- a/xen/arch/x86/cpu/mcheck/Makefile
+++ b/xen/arch/x86/cpu/mcheck/Makefile
@@ -1,12 +1,10 @@
-obj-y += amd_nonfatal.o
-obj-y += mce_amd.o
obj-y += mcaction.o
obj-y +=
29.04.24 18:42, Jan Beulich:
On 23.04.2024 10:54, Sergiy Kibrik wrote:
Guard access to Intel-specific lmce_support & cmci_support variables in
common MCE/VMCE code. These are set in Intel-specific parts of mcheck code
and can potentially be skipped if building for non-intel platform by
On Tue, 2024-04-30 at 13:25 +0200, Roger Pau Monné wrote:
> On Tue, Apr 30, 2024 at 12:37:44PM +0200, Jan Beulich wrote:
> > On 30.04.2024 10:29, Roger Pau Monne wrote:
> > > Like it was done recently for libxl, switch to using the auto-
> > > generated feature
> > > names by the processing of
Hi Roger,
On Tue, 2024-04-30 at 18:58 +0200, Roger Pau Monne wrote:
> Hello,
>
> The following series attempts to solve a shortcoming of HVM/PVH
> guests
> with the lack of support for foreign mappings. Such lack of support
> prevents using PVH based guests as stubdomains for example.
>
> Add
On Tue, 2024-04-30 at 17:34 +0200, Roger Pau Monne wrote:
> None of the implementations support set_foreign_p2m_entry() yet,
> neither they
> have a p2m walk in domain_relinquish_resources() in order to remove
> the foreign
> mappings from the p2m and thus drop the extra refcounts.
>
> Adjust the
On Mon, 2024-04-29 at 15:45 +0200, Jan Beulich wrote:
> On 17.04.2024 12:04, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/arch/riscv/include/asm/atomic.h
> > @@ -0,0 +1,281 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +/*
> > + * Taken and modified from Linux.
> > + *
> > + *
> On 2 May 2024, at 07:43, Jan Beulich wrote:
>
> On 02.05.2024 08:33, Luca Fancellu wrote:
>>
>>
>>> On 2 May 2024, at 07:14, Jan Beulich wrote:
>>>
>>> On 01.05.2024 08:57, Luca Fancellu wrote:
Hi Jan,
> On 30 Apr 2024, at 12:37, Jan Beulich wrote:
>
> On
On Thu, May 02, 2024 at 09:23:30AM +0200, Jan Beulich wrote:
> On 30.04.2024 17:34, Roger Pau Monne wrote:
> > None of the implementations support set_foreign_p2m_entry() yet, neither
> > they
> > have a p2m walk in domain_relinquish_resources() in order to remove the
> > foreign
> > mappings
On Tue, Apr 30, 2024 at 6:50 PM Edgar E. Iglesias
wrote:
>
> From: "Edgar E. Iglesias"
>
> When invalidating memory ranges, if we happen to hit the first
> entry in a bucket we were never unmapping it. This was harmless
> for foreign mappings but now that we're looking to reuse the
> mapcache
On Thu, May 2, 2024 at 9:24 AM David Hildenbrand wrote:
>
> On 30.04.24 18:49, Edgar E. Iglesias wrote:
> > From: "Edgar E. Iglesias"
> >
> > Propagate MR and is_write to xen_map_cache().
>
> I'm pretty sure the patch subject is missing a "to" :)
Thanks David! I'll fix it in v5!
Cheers,
Edgar
On 30.04.24 18:49, Edgar E. Iglesias wrote:
From: "Edgar E. Iglesias"
Add xen_mr_is_memory() to abstract away tests for the
xen_memory MR.
Signed-off-by: Edgar E. Iglesias
---
[...]
#endif
diff --git a/system/physmem.c b/system/physmem.c
index ad7a8c7d95..1a5ffcba2a 100644
---
On 30.04.24 18:49, Edgar E. Iglesias wrote:
From: "Edgar E. Iglesias"
Propagate MR and is_write to xen_map_cache().
I'm pretty sure the patch subject is missing a "to" :)
This is in preparation for adding support for grant mappings.
No functional change.
Reviewed-by: David Hildenbrand
On 30.04.2024 17:34, Roger Pau Monne wrote:
> None of the implementations support set_foreign_p2m_entry() yet, neither they
> have a p2m walk in domain_relinquish_resources() in order to remove the
> foreign
> mappings from the p2m and thus drop the extra refcounts.
While I don't mind the cod
On Wed, May 1, 2024 at 11:24 PM Stefano Stabellini
wrote:
>
> On Tue, 30 Apr 2024, Edgar E. Iglesias wrote:
> > From: "Edgar E. Iglesias"
> >
> > The current mapcache assumes that all memory is mapped
> > in a single RAM MR (the first one with offset 0). Remove
> > this assumption and propagate
On 01.05.2024 19:06, Alejandro Vallejo wrote:
> On 26/03/2024 17:02, Jan Beulich wrote:
>> On 09.01.2024 16:38, Alejandro Vallejo wrote:
>>> --- a/tools/include/xenguest.h
>>> +++ b/tools/include/xenguest.h
>>> @@ -843,5 +843,20 @@ enum xc_static_cpu_featuremask {
>>>
1 - 100 of 112 matches
Mail list logo
