Fix last violation of R10.2 by casting the result of toupper to plain
char. Note that we don't want to change toupper itself as it is a legacy
interface and it would cause more issues.
Signed-off-by: Stefano Stabellini
---
I believe this is the last R10.2 violation
diff --git a/xen/lib/strtoul.c
flight 185990 linux-linus real [real]
flight 185991 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185990/
http://logs.test-lab.xenproject.org/osstest/logs/185991/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
On Sat, 11 May 2024, Andrew Cooper wrote:
> Various functions have a parameter or local variable called cpuid, but this
> triggers a MISRA R5.3 violation because we also have a function called cpuid()
> which wraps the real CPUID instruction.
>
> In all these cases, it's a Xen cpu index, which is
On Mon, 13 May 2024, Julien Grall wrote:
> Hi Stefano,
>
> title: Is this the only violation we have in Xen? If so, then please add the
> subsystem in the title.
The only remaining violations are about the use of the "toupper" macro.
Bugseng is recommending to add a cast to fix those or deviate t
Hi Luca,
On 25/04/2024 14:11, Luca Fancellu wrote:
The function dt_unreserved_regions is currently using recursion
to compute the non overlapping ranges of a passed region against
the reserved memory banks, in the spirit of removing the recursion
to improve safety and also improve the scalabilit
Hi Luca,
On 25/04/2024 14:11, Luca Fancellu wrote:
Currently the code is listing device tree reserve map regions
as reserved memory for Xen, but they are not added into
bootinfo.reserved_mem and they are fetched in multiple places
using the same code sequence, causing duplication. Fix this
by ad
Hi Stefano,
title: Is this the only violation we have in Xen? If so, then please add
the subsystem in the title.
On 11/05/2024 00:37, Stefano Stabellini wrote:
Change opt_conswitch to char to fix a violation of Rule 10.2.
Signed-off-by: Stefano Stabellini
diff --git a/xen/drivers/char/cons
On Mon, May 13, 2024 at 10:44:59AM +0200, Roger Pau Monné wrote:
> On Fri, May 10, 2024 at 09:09:54PM -0700, Elliott Mitchell wrote:
> > On Thu, Apr 18, 2024 at 09:33:31PM -0700, Elliott Mitchell wrote:
> > >
> > > I suspect this is a case of there is some step which is missing from
> > > Xen's IO
On 09/05/2024 18:50, Andrew Cooper wrote:
> Now that we're using hypercalls to start APs, we can replace the 'ap_cpuid'
> global with a regular function parameter. This requires telling the compiler
> that we'd like the parameter in a register rather than on the stack.
>
> While adjusting, rename
On Mon, May 13, 2024 at 01:40:30PM +, Elias El Yandouzi wrote:
> From: Hongyan Xia
>
> Building a PV dom0 is allocating from the domheap but uses it like the
> xenheap. Use the pages as they should be.
>
> Signed-off-by: Hongyan Xia
> Signed-off-by: Julien Grall
> Signed-off-by: Elias El Y
On Mon, May 13, 2024 at 01:40:29PM +, Elias El Yandouzi wrote:
> From: Wei Liu
>
> Xen shouldn't use domheap page as if they were xenheap pages. Map and
> unmap pages accordingly.
>
> Signed-off-by: Wei Liu
> Signed-off-by: Wei Wang
> Signed-off-by: Julien Grall
> Signed-off-by: Elias El
On Mon, May 13, 2024 at 11:10:59AM +, Elias El Yandouzi wrote:
> From: Hongyan Xia
>
> Create a per-domain mapping of PV guest_root_pt as direct map is being
> removed.
>
> Note that we do not map and unmap root_pgt for now since it is still a
> xenheap page.
I'm afraid this needs more cont
From: Julien Grall
At the moment, on Arm64, every pCPU is sharing the same page-tables.
In a follow-up patch, we will allow the possibility to remove the
direct map and therefore it will be necessary to have a mapcache.
While we have plenty of spare virtual address space to reserve part
for eac
Until directmap gets completely removed, we'd still need to
keep some calls to mfn_to_virt() for xenheap pages or when the
directmap is enabled.
Rename the macro to mfn_to_directmap_virt() to flag them and
prevent further use of mfn_to_virt().
Signed-off-by: Elias El Yandouzi
diff --git a/xen/a
From: Julien Grall
At the moment, on arm64, map_domain_page() is implemented using
virt_to_mfn(). Therefore it is relying on the directmap.
In a follow-up patch, we will allow the admin to remove the directmap.
Therefore we want to implement a mapcache.
Thanksfully there is already one for arm3
From: Julien Grall
The arm32 version of init_secondary_pagetables() will soon be re-used
for arm64 as well where the root table starts at level 0 rather than level 1.
So rename 'first' to 'root'.
Signed-off-by: Julien Grall
Signed-off-by: Elias El Yandouzi
Changelog in v2:
From: Julien Grall
Implement the same command line option as x86 to enable/disable the
directmap. By default this is kept enabled.
Also modify setup_directmap_mappings() to populate the L0 entries
related to the directmap area.
Signed-off-by: Julien Grall
Signed-off-by: Elias El Yandouzi
---
Until directmap gets completely removed, we'd still need to
keep some calls to mmaddr_to_virt() for xenheap pages or when the
directmap is enabled.
Rename the macro to maddr_to_directmap_virt() to flag them and
prevent further use of maddr_to_virt().
Signed-off-by: Elias El Yandouzi
diff --git
From: Hongyan Xia
Create empty mappings in the second e820 pass. Also, destroy existing
direct map mappings created in the first pass.
To make xenheap pages visible in guests, it is necessary to create empty
L3 tables in the direct map even when directmap=no, since guest cr3s
copy idle domain's
From: Hongyan Xia
When there is not an always-mapped direct map, xenheap allocations need
to be mapped and unmapped on-demand.
Signed-off-by: Hongyan Xia
Signed-off-by: Julien Grall
Signed-off-by: Elias El Yandouzi
I have left the call to map_pages_to_xen() and destroy_xen_mappings
The early fixed addresses must all fit into the static L1 table.
Introduce a build assertion to this end.
Signed-off-by: Elias El Yandouzi
Changes in v2:
* New patch
diff --git a/xen/arch/x86/include/asm/fixmap.h
b/xen/arch/x86/include/asm/fixmap.h
index a7ac365fc6..904bee0
From: Hongyan Xia
When we do not have a direct map, archs_mfn_in_direct_map() will always
return false, thus init_node_heap() will allocate xenheap pages from an
existing node for the metadata of a new node. This means that the
metadata of a new node is in a different node, slowing down heap
allo
From: Hongyan Xia
Create a per-domain mapping of PV guest_root_pt as direct map is being
removed.
Note that we do not map and unmap root_pgt for now since it is still a
xenheap page.
Signed-off-by: Hongyan Xia
Signed-off-by: Julien Grall
Signed-off-by: Elias El Yandouzi
Changes in
From: Hongyan Xia
When we do not have a direct map, memory for metadata of heap nodes in
init_node_heap() is allocated from xenheap, which needs to be mapped and
unmapped on demand. However, we cannot just take memory from the boot
allocator to create the PTEs while we are passing memory to the h
From: Hongyan Xia
Also add a helper function to retrieve it. Change arch_mfns_in_direct_map
to check this option before returning.
This is added as a Kconfig option as well as a boot command line option.
While being generic, the Kconfig option is only usable for x86 at the moment.
Note that the
From: Hongyan Xia
In order to use the mapcache in the idle domain, we also have to
populate its page tables in the PERDOMAIN region, and we need to move
mapcache_domain_init() earlier in arch_domain_create().
Note, commit 'x86: lift mapcache variable to the arch level' has
initialised the mapcac
From: Julien Grall
PMAP will be used in a follow-up patch to bootstrap map domain
page infrastructure -- we need some way to map pages to setup the
mapcache without a direct map.
The functions pmap_{map, unmap} open code {set, clear}_fixmap to break
the loop.
Signed-off-by: Julien Grall
Signed
From: Wei Liu
It is going to be needed by HVM and idle domain as well, because without
the direct map, both need a mapcache to map pages.
This commit lifts the mapcache variable up and initialise it a bit earlier
for PV and HVM domains.
Signed-off-by: Wei Liu
Signed-off-by: Wei Wang
Signed-of
From: Hongyan Xia
When mfn is not in direct map, never use mfn_to_virt for any mappings.
We replace mfn_x(mfn) <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) with
arch_mfns_in_direct_map(mfn, 1) because these two are equivalent. The
extra comparison in arch_mfns_in_direct_map() looks different but b
From: Hongyan Xia
Building a PV dom0 is allocating from the domheap but uses it like the
xenheap. Use the pages as they should be.
Signed-off-by: Hongyan Xia
Signed-off-by: Julien Grall
Signed-off-by: Elias El Yandouzi
Changes in V3:
* Fold following patch 'x86/pv: Map L4 pa
Hi all,
A few years ago, Wei Liu implemented a PoC to remove the directmap
from Xen. The last version was sent by Hongyan Xia [1].
I will start with thanking both Wei and Hongyan for the initial work
to upstream the feature. A lot of patches already went in and this is
the last few patches missin
From: Wei Liu
Xen shouldn't use domheap page as if they were xenheap pages. Map and
unmap pages accordingly.
Signed-off-by: Wei Liu
Signed-off-by: Wei Wang
Signed-off-by: Julien Grall
Signed-off-by: Elias El Yandouzi
Changes in V3:
* Rename commit title
* Rework the
flight 185988 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185988/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 185978
test-amd64-amd64-libvirt-xsm 15 migrate-s
You seem to have forgotten to add the maintainers on Cc for the
patches. Adding them here for reference.
Regards, Roger.
On Mon, May 13, 2024 at 11:10:58AM +, Elias El Yandouzi wrote:
> Hi all,
>
> A few years ago, Wei Liu implemented a PoC to remove the directmap
> from Xen. The last versi
flight 185987 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185987/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 185980
test-amd64-amd64-xl-qemut-win7-amd64
From: Julien Grall
Implement the same command line option as x86 to enable/disable the
directmap. By default this is kept enabled.
Also modify setup_directmap_mappings() to populate the L0 entries
related to the directmap area.
Signed-off-by: Julien Grall
Signed-off-by: Elias El Yandouzi
---
From: Hongyan Xia
When mfn is not in direct map, never use mfn_to_virt for any mappings.
We replace mfn_x(mfn) <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) with
arch_mfns_in_direct_map(mfn, 1) because these two are equivalent. The
extra comparison in arch_mfns_in_direct_map() looks different but b
The early fixed addresses must all fit into the static L1 table.
Introduce a build assertion to this end.
Signed-off-by: Elias El Yandouzi
Changes in v2:
* New patch
diff --git a/xen/arch/x86/include/asm/fixmap.h
b/xen/arch/x86/include/asm/fixmap.h
index a7ac365fc6..904bee0
Until directmap gets completely removed, we'd still need to
keep some calls to mfn_to_virt() for xenheap pages or when the
directmap is enabled.
Rename the macro to mfn_to_directmap_virt() to flag them and
prevent further use of mfn_to_virt().
Signed-off-by: Elias El Yandouzi
diff --git a/xen/a
From: Julien Grall
At the moment, on Arm64, every pCPU is sharing the same page-tables.
In a follow-up patch, we will allow the possibility to remove the
direct map and therefore it will be necessary to have a mapcache.
While we have plenty of spare virtual address space to reserve part
for eac
From: Hongyan Xia
When there is not an always-mapped direct map, xenheap allocations need
to be mapped and unmapped on-demand.
Signed-off-by: Hongyan Xia
Signed-off-by: Julien Grall
Signed-off-by: Elias El Yandouzi
I have left the call to map_pages_to_xen() and destroy_xen_mappings
From: Julien Grall
The arm32 version of init_secondary_pagetables() will soon be re-used
for arm64 as well where the root table starts at level 0 rather than level 1.
So rename 'first' to 'root'.
Signed-off-by: Julien Grall
Signed-off-by: Elias El Yandouzi
Changelog in v2:
From: Hongyan Xia
Create empty mappings in the second e820 pass. Also, destroy existing
direct map mappings created in the first pass.
To make xenheap pages visible in guests, it is necessary to create empty
L3 tables in the direct map even when directmap=no, since guest cr3s
copy idle domain's
From: Julien Grall
At the moment, on arm64, map_domain_page() is implemented using
virt_to_mfn(). Therefore it is relying on the directmap.
In a follow-up patch, we will allow the admin to remove the directmap.
Therefore we want to implement a mapcache.
Thanksfully there is already one for arm3
From: Hongyan Xia
When we do not have a direct map, archs_mfn_in_direct_map() will always
return false, thus init_node_heap() will allocate xenheap pages from an
existing node for the metadata of a new node. This means that the
metadata of a new node is in a different node, slowing down heap
allo
Until directmap gets completely removed, we'd still need to
keep some calls to mmaddr_to_virt() for xenheap pages or when the
directmap is enabled.
Rename the macro to maddr_to_directmap_virt() to flag them and
prevent further use of maddr_to_virt().
Signed-off-by: Elias El Yandouzi
diff --git
From: Hongyan Xia
Building a PV dom0 is allocating from the domheap but uses it like the
xenheap. Use the pages as they should be.
Signed-off-by: Hongyan Xia
Signed-off-by: Julien Grall
Signed-off-by: Elias El Yandouzi
Changes in V3:
* Fold following patch 'x86/pv: Map L4 pa
From: Hongyan Xia
Also add a helper function to retrieve it. Change arch_mfns_in_direct_map
to check this option before returning.
This is added as a Kconfig option as well as a boot command line option.
While being generic, the Kconfig option is only usable for x86 at the moment.
Note that the
From: Hongyan Xia
In order to use the mapcache in the idle domain, we also have to
populate its page tables in the PERDOMAIN region, and we need to move
mapcache_domain_init() earlier in arch_domain_create().
Note, commit 'x86: lift mapcache variable to the arch level' has
initialised the mapcac
From: Hongyan Xia
When we do not have a direct map, memory for metadata of heap nodes in
init_node_heap() is allocated from xenheap, which needs to be mapped and
unmapped on demand. However, we cannot just take memory from the boot
allocator to create the PTEs while we are passing memory to the h
From: Wei Liu
It is going to be needed by HVM and idle domain as well, because without
the direct map, both need a mapcache to map pages.
This commit lifts the mapcache variable up and initialise it a bit earlier
for PV and HVM domains.
Signed-off-by: Wei Liu
Signed-off-by: Wei Wang
Signed-of
From: Wei Liu
Xen shouldn't use domheap page as if they were xenheap pages. Map and
unmap pages accordingly.
Signed-off-by: Wei Liu
Signed-off-by: Wei Wang
Signed-off-by: Julien Grall
Signed-off-by: Elias El Yandouzi
Changes in V3:
* Rename commit title
* Rework the
From: Julien Grall
PMAP will be used in a follow-up patch to bootstrap map domain
page infrastructure -- we need some way to map pages to setup the
mapcache without a direct map.
The functions pmap_{map, unmap} open code {set, clear}_fixmap to break
the loop.
Signed-off-by: Julien Grall
Signed
From: Hongyan Xia
Create a per-domain mapping of PV guest_root_pt as direct map is being
removed.
Note that we do not map and unmap root_pgt for now since it is still a
xenheap page.
Signed-off-by: Hongyan Xia
Signed-off-by: Julien Grall
Signed-off-by: Elias El Yandouzi
Changes in
Hi all,
A few years ago, Wei Liu implemented a PoC to remove the directmap
from Xen. The last version was sent by Hongyan Xia [1].
I will start with thanking both Wei and Hongyan for the initial work
to upstream the feature. A lot of patches already went in and this is
the last few patches missin
On 20/02/2024 11:14, Jan Beulich wrote:
On 16.01.2024 20:25, Elias El Yandouzi wrote:
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -29,6 +29,7 @@ config X86
select HAS_UBSAN
select HAS_VPCI if HVM
select NEEDS_LIBELF
+ select HAS_SECRET_HIDING
Pleas
flight 185986 linux-linus real [real]
flight 185989 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185986/
http://logs.test-lab.xenproject.org/osstest/logs/185989/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-
On 20/02/2024 10:51, Jan Beulich wrote:
On 16.01.2024 20:25, Elias El Yandouzi wrote:
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -750,9 +750,16 @@ int arch_domain_create(struct domain *d,
spin_lock_init(&d->arch.e820_lock);
+if ( (rc = mapcache_domain_init(d))
06.05.24 14:32, Jan Beulich:
On 02.05.2024 11:21, Sergiy Kibrik wrote:
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 ini
There's no point in forcing a system wide update of the MTRRs on all processors
when there are no changes to be propagated. On AP startup it's only the AP
that needs to write the system wide MTRR values in order to match the rest of
the already online CPUs.
We have occasionally seen the watchdog
On Fri, May 10, 2024 at 09:09:54PM -0700, Elliott Mitchell wrote:
> On Thu, Apr 18, 2024 at 09:33:31PM -0700, Elliott Mitchell wrote:
> >
> > I suspect this is a case of there is some step which is missing from
> > Xen's IOMMU handling. Perhaps something which Linux does during an early
> > DMA s
06.05.24 14:18, Jan Beulich:
On 02.05.2024 11:14, Sergiy Kibrik wrote:
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
On Fri, May 10, 2024 at 10:37:53PM +0100, Julien Grall wrote:
> Hi Roger,
>
> On 09/05/2024 13:58, Roger Pau Monné wrote:
> > On Thu, May 09, 2024 at 01:12:00PM +0100, Julien Grall wrote:
> > > Hi,
> > >
> > > On 09/05/2024 12:28, Roger Pau Monné wrote:
> > > > OTOH for 1GB given the code here th
On 13.05.24 09:47, Chen, Jiqian wrote:
Hi,
On 2024/5/10 17:06, Chen, Jiqian wrote:
Hi,
On 2024/5/10 14:46, Jürgen Groß wrote:
On 19.04.24 05:36, Jiqian Chen wrote:
In PVH dom0, it uses the linux local interrupt mechanism,
when it allocs irq for a gsi, it is dynamic, and follow
the principle o
Hi,
On 2024/5/10 17:06, Chen, Jiqian wrote:
> Hi,
>
> On 2024/5/10 14:46, Jürgen Groß wrote:
>> On 19.04.24 05:36, Jiqian Chen wrote:
>>> In PVH dom0, it uses the linux local interrupt mechanism,
>>> when it allocs irq for a gsi, it is dynamic, and follow
>>> the principle of applying first, distr
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 feat
66 matches
Mail list logo
