On 16.03.24 00:32, Stefano Stabellini wrote:
Hi Dominique,
You posted this configuration:
device_model_args = [ "
"-device","nec-usb-xhci,id=xhci",
"-device","usb-host,bus=xhci.0,hostbus=1,hostport=13",
"-device","usb-host,bus
flight 185053 linux-6.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185053/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 12 debian-install fail REGR. vs. 184922
Tests which did not succeed, b
A very small correction to Marek's summary, only matters if you really
going to look at details:
Marek Marczykowski-Górecki:
[...]
> 2. When toolstack issues "suspend" command (via xenstore
> control/shutdown), Linux uses "freeze" path, that doesn't put devices
> into low power state. Changing tha
Hi,
S0ix came up in a recent discussion, so let me post a small status
update. We have patches that makes Qubes suspend with ~90% S0ix
residency. It's significantly worse than native Linux on the same system
- that gets 99+%, but still a significant progress.
We do have a tricky case though, becau
flight 185051 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185051/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 185036
test-armhf-armhf-libvirt 16 save
On Fri, 15 Mar 2024, Jan Beulich wrote:
> On 14.03.2024 23:59, Stefano Stabellini wrote:
> > On Mon, 11 Mar 2024, Simone Ballarin wrote:
> >> On 11/03/24 14:56, Jan Beulich wrote:
> >>> On 11.03.2024 13:00, Simone Ballarin wrote:
> On 11/03/24 11:08, Jan Beulich wrote:
> > On 11.03.2024 09
On Fri, 15 Mar 2024, Jan Beulich wrote:
> On 14.03.2024 23:55, Stefano Stabellini wrote:
> > On Mon, 11 Mar 2024, Jan Beulich wrote:
> >> On 11.03.2024 09:59, Simone Ballarin wrote:
> >>> Some headers, under specific circumstances (documented in a comment at
> >>> the beginning of the file), explic
On Fri, 15 Mar 2024, Nicola Vetrini wrote:
> Delete unused functions from 'iommu_guest.c'.
>
> No functional change.
>
> Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
> ---
> guest_iommu_add_ptr_log has still one caller, but even that seems
> suspicious. I left it in and unif
On Fri, 15 Mar 2024, Jan Beulich wrote:
> On 15.03.2024 01:35, Stefano Stabellini wrote:
> > --- a/docs/misra/rules.rst
> > +++ b/docs/misra/rules.rst
> > @@ -181,6 +181,21 @@ maintainers if you want to suggest a change.
> > headers (xen/include/public/) are allowed to retain longer
> >
On Fri, 15 Mar 2024, Federico Serafini wrote:
> Update ECLAIR configuration of MISRA C:2012 Rule 8.3 to deviate
> violations involving parameter name "unused" (with an optional
> numeric suffix): it makes explicit the intention of not using such
> parameter within the function.
>
> Signed-off-by:
On Fri, 15 Mar 2024, Jan Beulich wrote:
> On 14.03.2024 23:17, Stefano Stabellini wrote:
> > Xen makes assumptions about the size of integer types on the various
> > architectures. Document these assumptions.
>
> My prior reservation wrt exact vs minimum sizes remains.
We have to specify the exac
On Fri, 15 Mar 2024, George Dunlap wrote:
> On Fri, Mar 15, 2024 at 2:13 PM Jan Beulich wrote:
> >
> > On 15.03.2024 14:55, Julien Grall wrote:
> > > Hi Jan,
> > >
> > > On 15/03/2024 13:24, Jan Beulich wrote:
> > >> On 15.03.2024 13:17, George Dunlap wrote:
> > >>> On Fri, Mar 15, 2024 at 11:57 A
Hi Dominique,
You posted this configuration:
device_model_args = [ "
"-device","nec-usb-xhci,id=xhci",
"-device","usb-host,bus=xhci.0,hostbus=1,hostport=13",
"-device","usb-host,bus=xhci.0,hostbus=1,hostport=10",
flight 185046 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185046/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 185023
test-amd64-amd64-xl-qemut-win7-amd64
Right now, check_nmi_watchdog() has two processing loops over all online CPUs
using prev_nmi_count as storage.
Use a cpumask_t instead (1/32th as much initdata) and have wait_for_nmis()
make the determination of whether it is stuck, rather than having both
functions needing to agree on how many ti
Hi Jan,
On 22/01/2024 13:22, Jan Beulich wrote:
On 15.01.2024 15:36, Jan Beulich wrote:
Use the generic framework in xen/linkage.h. No change in generated code
except for the changed padding value (noticable when config.gz isn't a
multiple of 4 in size). Plus of course the converted symbols cha
This patch doesn't represent a strict lower bound for GCC and
GNU Binutils; rather, these versions are specifically employed by
the Xen RISC-V container and are anticipated to undergo continuous
testing. Older GCC and GNU Binutils would work,
but this is not a guarantee.
While it is feasible to ut
Signed-off-by: Oleksii Kurochko
---
Changes in V6:
- drop __virt_to_maddr() ( transform to macro ) and __maddr_to_virt ( rename
to maddr_to_virt ).
- parenthesize va in definition of vmap_to_mfn().
- Code style fixes.
---
Changes in V5:
- update the comment around "struct domain *domain;" :
Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
---
Changes in V5-6:
- Nothing changed. Only rebase.
---
Changes in V4:
---
- Change message -> subject in "Changes in V3"
- s/BUG/BUG_ON("...")
- Do proper rebase ( pfn_to_paddr() and paddr_to_pfn() aren't removed ).
---
Changes in V3:
-
The cpu_relax() function, introduced in this commit, is anticipated to
support _zihintpause by the CPU.
Signed-off-by: Oleksii Kurochko
---
Changes in V6:
- drop incorrect part in riscv/booting.txt and move the introduction of it to
separate patch.
- compiler check that __riscv_zihintpause e
flight 185050 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185050/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 185005
test-amd64-i386-xl-qemuu-win7-amd64 19 gu
Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
---
Changes in V6:
- update the commit in stubs.c around /* ... common/irq.c ... */
- add Acked-by: Jan Beulich
---
Changes in V5:
- drop unrelated changes
- assert_failed("unimplmented...") change to BUG_ON()
---
Changes in V4:
- added
Signed-off-by: Oleksii Kurochko
Reviewed-by: Jan Beulich
---
Changes in V5-V6:
- Nothing changed. Only rebase.
---
Changes in V4:
- drop stubs for irq_actor_none() and irq_actor_none() as common/irq.c is
compiled now.
- drop defintion of max_page in stubs.c as common/page_alloc.c is compiled
Add minimal requied things to be able to build full Xen.
Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
---
Changes in V5/V6:
- Nothing changed. Only rebase.
---
Changes in V4:
- BUG() was changed to BUG_ON("unimplemented");
- Change "xen/bug.h" to "xen/lib.h" as BUG_ON is defined in x
The header taken form Linux 6.4.0-rc1 and is based on
arch/riscv/include/asm/mmio.h with the following changes:
- drop forcing of endianess for read*(), write*() functions as
no matter what CPU endianness, what endianness a particular device
(and hence its MMIO region(s)) is using is entirely i
Return type was left 'int' because of the following compilation error:
./include/xen/kernel.h:18:21: error: comparison of distinct pointer types lacks
a cast [-Werror]
18 | (void) (&_x == &_y);\
| ^~
common/page_alloc.c:1843:34: note: i
The definition of __read_mostly should be removed in:
https://lore.kernel.org/xen-devel/f25eb5c9-7c14-6e23-8535-2c66772b3...@suse.com/
The patch introduces it in arch-specific header to not
block enabling of full Xen build for RISC-V.
Signed-off-by: Oleksii Kurochko
---
- [PATCH] move __read_mos
Signed-off-by: Oleksii Kurochko
---
Changes in V5-V6:
- Only rebase was done.
---
Changes in V4:
- New patch.
---
xen/arch/riscv/Makefile | 1 +
xen/arch/riscv/vm_event.c | 19 +++
2 files changed, 20 insertions(+)
create mode 100644 xen/arch/riscv/vm_event.c
diff --git a/
This patch disables unnecessary configs for two cases:
1. By utilizing EXTRA_FIXED_RANDCONFIG for randconfig builds (GitLab CI jobs).
2. By using tiny64_defconfig for non-randconfig builds.
Signed-off-by: Oleksii Kurochko
---
Changes in V6:
- Nothing changed. Only rebase.
---
Changes in V5:
- R
Taken from Linux-6.4.0-rc1
Xen's bitops.h consists of several Linux's headers:
* linux/arch/include/asm/bitops.h:
* The following function were removed as they aren't used in Xen:
* test_and_set_bit_lock
* clear_bit_unlock
* __clear_bit_unlock
* The following functions
Currently, RISC-V requires two extensions: _zbb and _zihintpause.
This patch introduces a compiler check to check if these extensions
are supported.
Additionally, it introduces the riscv/booting.txt file, which contains
information about the extensions that should be supported by the platform.
In
Initially the patch was introduced by Bobby, who takes the header from
Linux kernel.
The following changes were done on top of Linux kernel header:
- atomic##prefix##_*xchg_*(atomic##prefix##_t *v, c_t n) were updated
to use__*xchg_generic()
- drop casts in write_atomic() as they are unnece
Signed-off-by: Oleksii Kurochko
---
Changes in V4/V5/V6:
- Nothing changed. Only rebase.
---
Changes in V3:
- new patch.
---
xen/arch/riscv/include/asm/monitor.h | 26 ++
1 file changed, 26 insertions(+)
create mode 100644 xen/arch/riscv/include/asm/monitor.h
diff --gi
The mentioned macros exist only because of Linux compatible purpose.
The patch defines __ffs() in terms of Xen bitops and it is safe
to define in this way ( as __ffs() - 1 ) as considering that __ffs()
was defined as __builtin_ctzl(x), which has undefined behavior when x=0,
so it is assumed that s
The patch introduces the following generic functions:
* test_bit
* generic___test_and_set_bit
* generic___test_and_clear_bit
* generic___test_and_change_bit
Also, the patch introduces the following generics which are
used by the functions mentioned above:
* BITOP_BITS_PER_WORD
* BITOP_MASK
* BITOP
The header was taken from Linux kernl 6.4.0-rc1.
Addionally, were updated:
* add emulation of {cmp}xchg for 1/2 byte types using 32-bit atomic
access.
* replace tabs with spaces
* replace __* variale with *__
* introduce generic version of xchg_* and cmpxchg_*.
* drop {cmp}xchg{release,relaxed,a
This patch series performs all of the additions necessary to drop the
build overrides for RISCV and enable the full Xen build. Except in cases
where compatibile implementations already exist (e.g. atomic.h and
bitops.h), the newly added definitions are simple.
The patch series is based on the foll
This patch introduces the anchor riscv-fixed-randconfig,
which includes all configurations that should be disabled for
randconfig builds.
Suggested-by: Stefano Stabellini
Signed-off-by: Oleksii Kurochko
Reviewed-by: Michal Orzel
Acked-by: Stefano Stabellini
---
Changes in V6:
- new patch for
Last Branch Record and Bus Lock Detect both belong to the same MSR.
The same mechanism that restores LBR also restores BLD.
Therefore, the name of the feature that enables this mechanism should
reflect restoring the MSR, instead of one field.
No functional change.
Signed-off-by: Matthew Barnes
Bus Lock Detect can be used to reduce the effects of DoS in case it
happens.
This patch series enables BLD from MSR_DEBUGCTL if available, and
refines a mechanism to restore MSR_DEBUGCTL upon VMExit to support BLD
as well as LBR.
Said mechanism is also refactored to have a name that reflects gene
Enable Bus Lock Detect if available, and handle #DB traps to reduce
effects of DoS.
The value to restore MSR_DEBUGCTL to after VMExit will now depend on
whether BLD is enabled or not.
Restore MSR_DEBUGCTL after being cleared by storing a copy of the
register value in memory, instead of hard-codin
On 15.03.24 16:48, Anthony PERARD wrote:
linux-4.19 branch in xenbits is outdated, it haven't been updated and
tested since 2020 as it has been disabled in osstest. Also, this 4.19
branch doesn't build on Bookworm.
So we will start to use a newer version of Linux. We switch to 6.1 for
the Arm* t
On 15/03/2024 3:13 pm, Roger Pau Monné wrote:
> On Fri, Mar 15, 2024 at 12:13:22PM +, Andrew Cooper wrote:
>> The use of __clear_bit() forces dmask to be spilled to the stack, and
>> interferes with the compiler heuristcs for some upcoming improvements to the
>> ffs() code generation.
>>
>> Fir
Delete unused functions from 'iommu_guest.c'.
No functional change.
Signed-off-by: Nicola Vetrini
---
guest_iommu_add_ptr_log has still one caller, but even that seems
suspicious. I left it in and uniformed its parameter type at the
moment, so that whether it should be kept can be sorted out lat
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/osstest.git br.linux-6.1-v2
Hi,
A set of patch which lead to using Linux 6.1 instead of 4.19 as a default
kernel on x86.
I've check the list of jobs changes with
OSSTEST_CONFIG=standalone-config-example ni
There is 6 potenteil test of toolstack disk_format combination:
{xl,libvirt}-{raw,vhd,qcow2}. Commit f536e834f673 ("make-flight: Trim
the matrix of disk format flights") introduced a way to avoid testing
on every architecture and actually do only 6 tests accross all
arches, 3 on x86, 3 on armhf (no
Current freebsd as guest tests rely on the variable $qemuu_suffix, but
that one may or may not be set yet, and can't be rely upon. It isn't
set on the first iteration which call test_matrix_do_one(), with
xenarch=amd64 dom0arch=i386, but it is on the second call with
xenarch=amd64 dom0arch=amd64.
linux-4.19 branch in xenbits is outdated, it haven't been updated and
tested since 2020 as it has been disabled in osstest. Also, this 4.19
branch doesn't build on Bookworm.
So we will start to use a newer version of Linux. We switch to 6.1 for
the Arm* tests recently, so will use that same versio
On Fri, Mar 15, 2024 at 12:13:22PM +, Andrew Cooper wrote:
> The use of __clear_bit() forces dmask to be spilled to the stack, and
> interferes with the compiler heuristcs for some upcoming improvements to the
> ffs() code generation.
>
> First, shrink dmask to just the active vectors by makin
flight 185045 xen-unstable real [real]
flight 185048 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185045/
http://logs.test-lab.xenproject.org/osstest/logs/185048/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
On Fri, Mar 15, 2024 at 2:13 PM Jan Beulich wrote:
>
> On 15.03.2024 14:55, Julien Grall wrote:
> > Hi Jan,
> >
> > On 15/03/2024 13:24, Jan Beulich wrote:
> >> On 15.03.2024 13:17, George Dunlap wrote:
> >>> On Fri, Mar 15, 2024 at 11:57 AM Jan Beulich wrote:
> > It sounds like Andy and Stef
flight 185049 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185049/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3840c35e34d1c992268092b6366e26f2acc55a75
baseline version:
ovmf ccbbc2a5c84a0330b28b7
On 15.03.2024 14:48, Andrew Cooper wrote:
> On 14/03/2024 5:14 pm, Andrew Cooper wrote:
>> On 14/03/2024 3:59 pm, Jan Beulich wrote:
>>> On 13.03.2024 18:27, Andrew Cooper wrote:
--- a/xen/arch/x86/include/asm/bitops.h
+++ b/xen/arch/x86/include/asm/bitops.h
@@ -401,18 +401,6 @@ stat
On 15.03.2024 14:55, Julien Grall wrote:
> Hi Jan,
>
> On 15/03/2024 13:24, Jan Beulich wrote:
>> On 15.03.2024 13:17, George Dunlap wrote:
>>> On Fri, Mar 15, 2024 at 11:57 AM Jan Beulich wrote:
> It sounds like Andy and Stefano feel like this is a situation where "a
> fixed width quanti
Hi Jan,
On 15/03/2024 13:24, Jan Beulich wrote:
On 15.03.2024 13:17, George Dunlap wrote:
On Fri, Mar 15, 2024 at 11:57 AM Jan Beulich wrote:
It sounds like Andy and Stefano feel like this is a situation where "a
fixed width quantity is meant"; absent any further guidance from the
CODING_STYL
On 14/03/2024 5:14 pm, Andrew Cooper wrote:
> On 14/03/2024 3:59 pm, Jan Beulich wrote:
>> On 13.03.2024 18:27, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/include/asm/bitops.h
>>> +++ b/xen/arch/x86/include/asm/bitops.h
>>> @@ -401,18 +401,6 @@ static always_inline unsigned int __scanbit(unsigned
On 2024-03-15 14:31, Jan Beulich wrote:
On 15.03.2024 12:16, Nicola Vetrini wrote:
Delete unused functions from 'iommu_guest.c'.
The 'cmd' parameter of amd_iommu_send_guest_cmd is passed
to a function that expects arrays of size 4, therefore
specifying explicitly the size also in amd_iommu_send
On 15.03.2024 12:16, Nicola Vetrini wrote:
> Delete unused functions from 'iommu_guest.c'.
>
> The 'cmd' parameter of amd_iommu_send_guest_cmd is passed
> to a function that expects arrays of size 4, therefore
> specifying explicitly the size also in amd_iommu_send_guest_cmd
> allows not to accide
On 15.03.2024 13:17, George Dunlap wrote:
> On Fri, Mar 15, 2024 at 11:57 AM Jan Beulich wrote:
>>> It sounds like Andy and Stefano feel like this is a situation where "a
>>> fixed width quantity is meant"; absent any further guidance from the
>>> CODING_STYLE about when fixed widths should or sho
flight 185047 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185047/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ccbbc2a5c84a0330b28b726ef0936fc16937005a
baseline version:
ovmf e7486b50646d6a645706b
On Fri, Mar 15, 2024 at 11:57 AM Jan Beulich wrote:
> > It sounds like Andy and Stefano feel like this is a situation where "a
> > fixed width quantity is meant"; absent any further guidance from the
> > CODING_STYLE about when fixed widths should or should not be used, I
> > don't think this chan
The use of __clear_bit() forces dmask to be spilled to the stack, and
interferes with the compiler heuristcs for some upcoming improvements to the
ffs() code generation.
First, shrink dmask to just the active vectors by making out the upper bits.
This replaces the "i < msi->vectors" part of the lo
On 15.03.2024 11:59, George Dunlap wrote:
> On Fri, Mar 15, 2024 at 6:54 AM Jan Beulich wrote:
>> On 15.03.2024 01:21, Stefano Stabellini wrote:
>>> On Mon, 11 Mar 2024, Julien Grall wrote:
On 11/03/2024 11:32, George Dunlap wrote:
> On Sat, Mar 9, 2024 at 1:59 AM Stefano Stabellini
>
EFI_GET_TIME doesn't seem to be very reliable:
[ Xen-4.19-unstable x86_64 debug=y Tainted: C]
CPU:0
RIP:e008:[<62ccfa70>] 62ccfa70
[...]
Xen call trace:
[<62ccfa70>] R 62ccfa70
[<732e9a3f>] S 732e9a3f
[] F arch/x86/t
Hi all,
unfortunately, this patch doesn't apply cleanly to the latest master.
The conflict is very small: just a reordering of two lines in
xen/common/Kconfig. Should I resend the whole series?
Thanks.
On Fri, Mar 15, 2024 at 11:59 AM Carlo Nonato
wrote:
>
> Last Level Cache (LLC) coloring allo
On 2024-03-12 12:01, Roger Pau Monné wrote:
On Wed, Dec 13, 2023 at 05:10:50PM +0100, Simone Ballarin wrote:
From: Maria Celeste Cesario
The xen sources contain violations of MISRA C:2012 Rule 14.4 whose
headline states:
"The controlling expression of an if statement and the controlling
expres
On 15/03/24 12:13, Andrew Cooper wrote:
On 15/03/2024 11:07 am, Federico Serafini wrote:
Hello everyone,
there are violations of Rule 5.5 ("Identifiers shall be distinct
from macro names") in xen/arch/x86/include/asm/bitops.h.
You can see them at [1].
Do you agree to distinguish between functi
On Fri, Mar 15, 2024 at 6:54 AM Jan Beulich wrote:
>
> On 15.03.2024 01:21, Stefano Stabellini wrote:
> > On Mon, 11 Mar 2024, Julien Grall wrote:
> >> On 11/03/2024 11:32, George Dunlap wrote:
> >>> On Sat, Mar 9, 2024 at 1:59 AM Stefano Stabellini
> >>> wrote:
>
> I would like to resu
Delete unused functions from 'iommu_guest.c'.
The 'cmd' parameter of amd_iommu_send_guest_cmd is passed
to a function that expects arrays of size 4, therefore
specifying explicitly the size also in amd_iommu_send_guest_cmd
allows not to accidentally pass a bigger array.
No functional change.
Sig
On 15/03/2024 11:07 am, Federico Serafini wrote:
> Hello everyone,
>
> there are violations of Rule 5.5 ("Identifiers shall be distinct
> from macro names") in xen/arch/x86/include/asm/bitops.h.
> You can see them at [1].
>
> Do you agree to distinguish between function-like macros and
> inline fun
Hello everyone,
there are violations of Rule 5.5 ("Identifiers shall be distinct
from macro names") in xen/arch/x86/include/asm/bitops.h.
You can see them at [1].
Do you agree to distinguish between function-like macros and
inline functions by adding a suffix to the functions?
I thought about "_
From: Luca Miccio
Add a new command line parameter to configure Xen cache colors.
These colors can be dumped with the cache coloring info debug-key.
By default, Xen uses the first color.
Benchmarking the VM interrupt response time provides an estimation of
LLC usage by Xen's most latency-critica
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
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 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
---
v7:
- removed alloc_colors() helper usage from domain_set_llc_colors_from_str()
v6:
- rewrote dom
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().
Signed-off-by: Carlo Nonato
---
v7:
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 alloc
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 mapping
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() a
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 i
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 sof
Add a new PGC_no_buddy_merge flag that prevents the buddy algorithm in
free_heap_pages() from merging pages that have it set. As of now, only
PGC_static has this feature, but future work can extend it easier than
before.
Signed-off-by: Carlo Nonato
---
v7:
- new patch
---
xen/common/page_alloc.c
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
range
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 and put other options under
xen/arch.
LLC colors are a property of the domain, so the domain struct has to be
e
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
---
v7:
- -EOPNOTSUPP re
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 const
On 14/03/2024 14:22, Henry Wang wrote:
Hi Julien,
Hi,
On 3/14/2024 9:27 PM, Julien Grall wrote:
Hi Henry,
On 28/02/2024 01:58, Henry Wang wrote:
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index a84e706d77..d9ebd55d4a 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/
Update ECLAIR configuration of MISRA C:2012 Rule 8.3 to deviate
violations involving parameter name "unused" (with an optional
numeric suffix): it makes explicit the intention of not using such
parameter within the function.
Signed-off-by: Federico Serafini
---
Changes in v2:
- optional numeric s
On 15/03/2024 10:05 am, George Dunlap wrote:
> On Thu, Mar 14, 2024 at 5:39 PM Julien Grall wrote:
>> From: Julien Grall
>>
>> The script docs/support-matrix-generate throw the following error on the
>> latest staging.
> I wonder if it would be worth adding a follow-up patch to run that
> script,
On Thu, Mar 14, 2024 at 5:39 PM Julien Grall wrote:
>
> From: Julien Grall
>
> The script docs/support-matrix-generate throw the following error on the
> latest staging.
I wonder if it would be worth adding a follow-up patch to run that
script, maybe only when debug=y, so it catches errors in de
On 14.03.2024 20:19, Jason Andryuk wrote:
> On 2024-03-14 09:31, Jan Beulich wrote:
>> On 13.03.2024 20:30, Jason Andryuk wrote:
>>> --- a/xen/arch/x86/hvm/dom0_build.c
>>> +++ b/xen/arch/x86/hvm/dom0_build.c
>>> @@ -537,6 +537,108 @@ static paddr_t __init find_memory(
>>> return INVALID_PADD
On 14.03.2024 23:17, Stefano Stabellini wrote:
> Xen makes assumptions about the size of integer types on the various
> architectures. Document these assumptions.
My prior reservation wrt exact vs minimum sizes remains. Additionally,
is it really meaningful to document x86-32 as an architecture, w
On 15.03.2024 01:35, Stefano Stabellini wrote:
> --- a/docs/misra/rules.rst
> +++ b/docs/misra/rules.rst
> @@ -181,6 +181,21 @@ maintainers if you want to suggest a change.
> headers (xen/include/public/) are allowed to retain longer
> identifiers for backward compatibility.
>
> +
On 15/03/24 10:12, Jan Beulich wrote:
On 14.03.2024 17:35, Federico Serafini wrote:
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -157,6 +157,11 @@ Deviations related to MISRA C:2012 Rules:
- xen/common/unxz.c
- xen/common/unzstd.c
+ * - R8.3
+
On 14.03.2024 23:59, Stefano Stabellini wrote:
> On Mon, 11 Mar 2024, Simone Ballarin wrote:
>> On 11/03/24 14:56, Jan Beulich wrote:
>>> On 11.03.2024 13:00, Simone Ballarin wrote:
On 11/03/24 11:08, Jan Beulich wrote:
> On 11.03.2024 09:59, Simone Ballarin wrote:
>> --- a/xen/arch/ar
On 14.03.2024 23:15, Shawn Anastasio wrote:
> Arm's setup.c contains a collection of functions for parsing memory map
> and other boot information from a device tree. Since these routines are
> generally useful on any architecture that supports device tree booting,
> move them into xen/common/devic
On 14.03.2024 17:35, Federico Serafini wrote:
> --- a/docs/misra/deviations.rst
> +++ b/docs/misra/deviations.rst
> @@ -157,6 +157,11 @@ Deviations related to MISRA C:2012 Rules:
> - xen/common/unxz.c
> - xen/common/unzstd.c
>
> + * - R8.3
> + - Parameter name "unused" i
Hi Shawn,
> On 14 Mar 2024, at 22:15, Shawn Anastasio
> wrote:
>
> Add the definitions used by ARM's bootfdt.c, which will be moved into
> xen/common in a later patch, to PPC's setup.h.
>
> Signed-off-by: Shawn Anastasio
> ---
> xen/arch/ppc/include/asm/setup.h | 112
On Thu, Mar 14, 2024 at 12:59:19PM -0400, Jason Andryuk wrote:
> On 2024-03-14 11:30, Jan Beulich wrote:
> > On 14.03.2024 15:33, Roger Pau Monné wrote:
> > > On Thu, Mar 14, 2024 at 09:51:22AM -0400, Jason Andryuk wrote:
> > > > On 2024-03-14 05:48, Roger Pau Monné wrote:
> > > > > On Wed, Mar 13,
flight 185040 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185040/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 185023
test-amd64-amd64-li
1 - 100 of 101 matches
Mail list logo
