[PATCH] xen: fix multicall debug data referencing

The recent adding of multicall debug mixed up the referencing of the debug data. A __percpu tagged pointer can't be initialized with a plain pointer, so use another percpu variable for the pointer and set it on each new cpu via a function. Fixes: 942d917cb92a ("xen: make multicall debug boot time

[ovmf test] 186848: all pass - PUSHED

flight 186848 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/186848/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 62bf2aefc7d58288bb9e32c0c7fe2052c33101e9 baseline version: ovmf cee9d1b16bdcd7fe8bad6

[xen-unstable test] 186844: tolerable FAIL

flight 186844 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/186844/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail in 186830 pass in 186844 test-armhf-ar

[xen-4.16-testing test] 186838: regressions - FAIL

flight 186838 xen-4.16-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/186838/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-prev 6 xen-buildfail REGR. vs. 185867 build-i386-pre

Re: [XEN PATCH v4 8/9] x86/mm: add defensive return

On Mon, 15 Jul 2024, Federico Serafini wrote: > 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

[ovmf test] 186847: all pass - PUSHED

flight 186847 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/186847/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf cee9d1b16bdcd7fe8bad6b39fe18af0a15941ca4 baseline version: ovmf 0adc868b362873eb7c749

Re: [RFC PATCH 17/17] CODING_STYLE: Add a section on header guards naming conventions

On Wed, 17 Jul 2024, Jan Beulich wrote: > On 17.07.2024 02:20, Stefano Stabellini wrote: > > On Tue, 16 Jul 2024, Jan Beulich wrote: > >> On 16.07.2024 02:43, Stefano Stabellini wrote: > >>> On Mon, 15 Jul 2024, Jan Beulich wrote: > On 13.07.2024 00:38, Stefano Stabellini wrote: > > On Wed

[ovmf test] 186846: all pass - PUSHED

flight 186846 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/186846/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 0adc868b362873eb7c749f3ac6c38f9e293af10d baseline version: ovmf 11c50d6ca10a1410c2db1

[ovmf test] 186845: all pass - PUSHED

flight 186845 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/186845/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 11c50d6ca10a1410c2db187078fa7139e29e3042 baseline version: ovmf 23d3fc056d37039ffe1bd

[libvirt test] 186833: tolerable all pass - PUSHED

flight 186833 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/186833/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186814 test-amd64-amd64-libvirt-xsm 15 migrate-s

[ovmf test] 186843: all pass - PUSHED

flight 186843 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/186843/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 23d3fc056d37039ffe1bd4461492a1e226c779e5 baseline version: ovmf dd58d1227c102ad4a7990

[xen-unstable test] 186830: tolerable FAIL - PUSHED

flight 186830 xen-unstable real [real] flight 186842 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/186830/ http://logs.test-lab.xenproject.org/osstest/logs/186842/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd6

[PATCH for-4.20 0/3] XSA-402 followup

The start of the XSA-402 followup. Better late than never. Andrew Cooper (3): x86/mm: Drop duplicate l1_disallow_mask() calls x86/mm: Move base_disallow_mask into __ro_after_init x86/mm: Simplify/correct l1_disallow_mask() xen/arch/x86/mm.c | 36 +--- 1 fil

[PATCH 2/3] x86/mm: Move base_disallow_mask into __ro_after_init

base_disallow_mask is calculated once in arch_init_memory() and never changes thereafter. Write-protect it at runtime. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné --- xen/arch/x86/mm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/

[PATCH RFC 3/3] x86/mm: Simplify/correct l1_disallow_mask()

l1_disallow_mask() yields L1_DISALLOW_MASK with PAGE_CACHE_ATTRS conditionally permitted. First, rewrite it as a plain function. Next, correct some dubious behaviours. The use of is_pv_domain() is tautological; l1_disallow_mask() is only used in the PV pagetable code, and it return true for syst

[PATCH 1/3] x86/mm: Drop duplicate l1_disallow_mask() calls

Even in release builds, gdprintk() evalues its parameters for side effects, and l1_disallow_mask() is full of them. Calculate the disallow mask once and reuse the variable. This improves code generation in release builds: add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-207 (-207) Function

Re: Pre-register now for the Xen Project Winter Meetup 2024!

Hi Olivier, Le mer. 17 juil. 2024 à 16:33, Olivier Lambert a écrit : > > Hello everyone, > > As discussed during our previous Xen Summit in the first design session, "The > Future of Xen Events," we aim to create an event that is: > > Financially neutral for the Xen Project (0 cost, entirely sup

[PATCH for-4.19?] x86/IOMMU: Move allocation in iommu_identity_mapping

If for some reason, xmalloc fails after having mapped the reserved regions, a error is reported, but the regions are actually mapped in p2m. Move the allocation before trying to map the regions, in case the allocation fails, no mapping is actually done which could allows this operation to be retri

Pre-register now for the Xen Project Winter Meetup 2024!

Hello everyone, As discussed during our previous Xen Summit in the first design session, "The Future of Xen Events," we aim to create an event that is: * Financially neutral for the Xen Project (0 cost, entirely supported by Vates and sponsors) * 100% branded as a Xen Event, similar to a regu

[ovmf test] 186841: all pass - PUSHED

flight 186841 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/186841/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf dd58d1227c102ad4a799002f16b3a8c796d7d7cc baseline version: ovmf e32d24ef8c8211e76c020

[linux-linus test] 186827: tolerable FAIL - PUSHED

flight 186827 linux-linus real [real] flight 186840 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/186827/ http://logs.test-lab.xenproject.org/osstest/logs/186840/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-

Re: [PATCH v1] automation: adjust paths to docker files in documentation

On Wed, 17 Jul 2024, Olaf Hering wrote: > Use new location of dockerfiles. > > Signed-off-by: Olaf Hering Reviewed-by: Stefano Stabellini > --- > automation/build/README.md | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/automation/build/README.md b/automation/b

Re: [PATCH] x86: drop REX64_PREFIX

On 17.07.2024 15:05, Andrew Cooper wrote: > On 17/07/2024 1:40 pm, Jan Beulich wrote: >> While we didn't copy the full Linux commentary, Linux commit >> 7180d4fb8308 ("x86_64: Fix 64bit FXSAVE encoding") is quite explicit >> about gas 2.16 supporting FXSAVEQ / FXRSTORQ. As that's presently our >> m

Re: [PATCH] x86: drop REX64_PREFIX

On 17/07/2024 1:40 pm, Jan Beulich wrote: > While we didn't copy the full Linux commentary, Linux commit > 7180d4fb8308 ("x86_64: Fix 64bit FXSAVE encoding") is quite explicit > about gas 2.16 supporting FXSAVEQ / FXRSTORQ. As that's presently our > minimal required version, we can drop the workaro

Re: [PATCH V3 (resend) 04/19] x86: Lift mapcache variable to the arch level

On Tue Jul 16, 2024 at 6:06 PM BST, Alejandro Vallejo wrote: > On Mon May 13, 2024 at 2:40 PM BST, Elias El Yandouzi wrote: > > 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

[PATCH] x86: drop REX64_PREFIX

While we didn't copy the full Linux commentary, Linux commit 7180d4fb8308 ("x86_64: Fix 64bit FXSAVE encoding") is quite explicit about gas 2.16 supporting FXSAVEQ / FXRSTORQ. As that's presently our minimal required version, we can drop the workaround that was needed for yet for older gas. Signed

Re: [PATCH for-4.20] hvmloader: Rework hypercall infrastructure

On 17.07.2024 13:12, Andrew Cooper wrote: > Right now, the hypercall page is at a hardcoded physical address, and making > hypercalls involves indirect calls to compile-time constant addresses. > e.g. HYPERCALL_memory_op is: > > mov$0x80180,%eax > call *%eax > > Instead, import the hype

Re: [PATCH for-4.20] hvmloader: Use fastcall everywhere

On 17.07.2024 13:18, Andrew Cooper wrote: > HVMLoader is a single freestanding 32bit program with no external > dependencies. Use the fastcall calling convetion (up to 3 parameters in > registers rather than on the stack) globally, which is more efficient because > of reducing the number of stack

[ovmf test] 186839: all pass - PUSHED

flight 186839 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/186839/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf e32d24ef8c8211e76c020fa7a395328cd176190c baseline version: ovmf b3441e01003ab91df8162

[PATCH for-4.20] hvmloader: Use fastcall everywhere

HVMLoader is a single freestanding 32bit program with no external dependencies. Use the fastcall calling convetion (up to 3 parameters in registers rather than on the stack) globally, which is more efficient because of reducing the number of stack operations. Some bloat-o-meter highligs are: a

[PATCH for-4.20] hvmloader: Rework hypercall infrastructure

Right now, the hypercall page is at a hardcoded physical address, and making hypercalls involves indirect calls to compile-time constant addresses. e.g. HYPERCALL_memory_op is: mov$0x80180,%eax call *%eax Instead, import the hypercall infrastructure from XTF to have hypercall_page[] ful

Re: [PATCH V3 (resend) 03/19] x86/pv: Rewrite how building PV dom0 handles domheap mappings

On 16.07.2024 18:12, Elias El Yandouzi wrote: > Hi Jan, > > On 14/05/2024 16:03, Jan Beulich wrote: >> On 13.05.2024 15:40, Elias El Yandouzi wrote: >>> --- a/xen/arch/x86/pv/dom0_build.c >>> +++ b/xen/arch/x86/pv/dom0_build.c >>> @@ -382,6 +382,10 @@ int __init dom0_construct_pv(struct domain *d,

Re: [RFC PATCH 17/17] CODING_STYLE: Add a section on header guards naming conventions

On 17.07.2024 02:20, Stefano Stabellini wrote: > On Tue, 16 Jul 2024, Jan Beulich wrote: >> On 16.07.2024 02:43, Stefano Stabellini wrote: >>> On Mon, 15 Jul 2024, Jan Beulich wrote: On 13.07.2024 00:38, Stefano Stabellini wrote: > On Wed, 3 Jul 2024, Jan Beulich wrote: >> I further ha

[PATCH v1] automation: adjust paths to docker files in documentation

Use new location of dockerfiles. Signed-off-by: Olaf Hering --- automation/build/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/automation/build/README.md b/automation/build/README.md index 12a2b4af18..bd0c0e0418 100644 --- a/automation/build/README.md +++ b/au

[xen-4.18-testing test] 186820: tolerable FAIL - PUSHED

flight 186820 xen-4.18-testing real [real] flight 186834 xen-4.18-testing real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/186820/ http://logs.test-lab.xenproject.org/osstest/logs/186834/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): t

[ovmf test] 186836: all pass - PUSHED

flight 186836 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/186836/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf b3441e01003ab91df816263df98f9675b2cd2aa1 baseline version: ovmf 43b7a856fad2e25b1b5bd

[xen-4.17-testing test] 186819: tolerable FAIL - PUSHED

flight 186819 xen-4.17-testing real [real] flight 186837 xen-4.17-testing real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/186819/ http://logs.test-lab.xenproject.org/osstest/logs/186837/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): t