flight 185004 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185004/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184997
test-amd64-amd64-xl-qemut-win7-amd64
flight 185003 xen-4.18-testing real [real]
flight 185013 xen-4.18-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185003/
http://logs.test-lab.xenproject.org/osstest/logs/185013/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On Tue, Mar 12, 2024 at 02:10:02PM +0100, Juergen Gross wrote:
> On 30.11.23 03:34, Marek Marczykowski-Górecki wrote:
> > Hi,
> >
> > While testing 6.7-rc3 on Qubes OS I found several warning like in the
> > subject in dom0 log. I see them when running 6.7-rc1 too. I'm not sure
> > what exactly
flight 185008 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185008/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ddaf39263a1ed84e60238622dfed83ff14ecc50a
baseline version:
ovmf
Signed-off-by: Stefano Stabellini
---
I tested the rendered output and it is correct both on the gitlab UI as
well as with tools like rst2html.
---
docs/misra/rules.rst | 24
1 file changed, 24 insertions(+)
diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
index
flight 185002 xen-4.17-testing real [real]
flight 185011 xen-4.17-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185002/
http://logs.test-lab.xenproject.org/osstest/logs/185011/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Hi Jan,
On 27/07/2023 08:38, Jan Beulich wrote:
... by way of a new arch-selectable Kconfig control.
Note that some smaller pieces of code are left without #ifdef, to keep
things better readable. Hence items like ECS_PIRQ, nr_static_irqs, or
domain_pirq_to_irq() remain uniformly.
As to
Hi Roger,
On 29/02/2024 09:55, Roger Pau Monne wrote:
We no longer have a way to build with the minimum required clang/llvm version
stated in the README on the gitlab CI loop, since we dropped the Debian Jessie
container that had Clang 3.5.0.
Bump the minimum required Clang/LLVM to the one
flight 185005 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185005/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 184988
test-amd64-i386-xl-qemuu-win7-amd64 19
Hi Ayan,
On 07/03/2024 12:39, Ayan Kumar Halder wrote:
When user enables HVC_DCC config option in Linux, it invokes access to debug
transfer register (i.e. DBGDTRTXINT). As this register is not emulated, Xen
injects an undefined exception to the guest and Linux crashes.
To prevent this crash,
Hi Ayan,
On 07/03/2024 12:39, Ayan Kumar Halder wrote:
From: Michal Orzel
Currently, if user enables HVC_DCC config option in Linux, it invokes access
to debug data transfer registers (i.e. DBGDTRTX_EL0 on arm64, DBGDTRTXINT on
arm32). As these registers are not emulated, Xen injects an
Hi,
On 07/03/2024 12:39, Ayan Kumar Halder wrote:
diff --git a/SUPPORT.md b/SUPPORT.md
index 7eb6875cfa..b49da114ab 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -102,6 +102,15 @@ Extension to the GICv3 interrupt controller to support MSI.
Status: Experimental
+### ARM/Partial
On Tue, Mar 12, 2024 at 05:07:12PM -0400, Jason Andryuk wrote:
> On 2024-03-10 10:06, Marek Marczykowski-Górecki wrote:
> > On Fri, Jan 19, 2024 at 02:40:06PM +0100, Marek Marczykowski-Górecki wrote:
> > > On Thu, Jan 18, 2024 at 01:23:56AM -0500, Patrick Plenefisch wrote:
> > > > On Wed, Jan 17,
On 2024-03-10 10:06, Marek Marczykowski-Górecki wrote:
On Fri, Jan 19, 2024 at 02:40:06PM +0100, Marek Marczykowski-Górecki wrote:
On Thu, Jan 18, 2024 at 01:23:56AM -0500, Patrick Plenefisch wrote:
On Wed, Jan 17, 2024 at 3:46 AM Jan Beulich wrote:
On 17.01.2024 07:12, Patrick Plenefisch
flight 185009 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185009/
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
On 12/03/24 15:30, Jan Beulich wrote:
On 12.03.2024 12:48, Federico Serafini wrote:
Place an "#if 0" before grep fodder definitions and remove the
"#undef".
This addresses several violations of MISRA C:2012 Rule 5.5
("Identifiers shall be distinct from macro names").
No functional change.
On Mon, Mar 11, 2024 at 06:27:52PM +0100, Roger Pau Monné wrote:
> On Wed, Mar 06, 2024 at 11:47:41AM +, Anthony PERARD wrote:
> > Gone, but replaced by a new test-amd64-amd64-*:
> > - test-amd64-i386-libvirt-raw
> > - test-amd64-i386-xl-vhd
> >
> > Some test-amd64-amd64-* are also changed:
>
On 8.02.2024 13:37, Jan Beulich wrote:
On 14.11.2023 18:50, Krystian Hebel wrote:
Multiple delays are required when sending IPIs and waiting for
responses. During boot, 4 such IPIs were sent per each AP. With this
change, only one set of broadcast IPIs is sent. This reduces boot time,
On 8.02.2024 13:13, Jan Beulich wrote:
On 14.11.2023 18:50, Krystian Hebel wrote:
This will be used for parallel AP bring-up.
CPU_STATE_INIT changed direction.
Nit: I think you mean "changes" as you describe what the patch does, not
what has happened before. But ...
It was previously set
It will be useful for error reporting in a subsequent patch.
Signed-off-by: Marek Marczykowski-Górecki
---
New in v2
---
xen/drivers/char/xhci-dbc.c | 3 ++-
xen/drivers/passthrough/iommu.c | 5 -
xen/include/xen/iommu.h | 3 ++-
3 files changed, 8 insertions(+), 3 deletions(-)
The IOMMU driver checks if RMRR/IVMD are marked as reserved in memory
map. This should be true for addresses coming from the firmware, but
when extra pages used by Xen itself are included in the mapping, those
are taken from usable RAM used. Mark those pages as reserved too.
Not marking the pages
On 8.02.2024 12:39, Jan Beulich wrote:
On 14.11.2023 18:50, Krystian Hebel wrote:
CPU id is obtained as a side effect of searching for appropriate
stack for AP. It can be used as a parameter to start_secondary().
Coincidentally this also makes further work on making AP bring-up
code parallel
On 8.02.2024 12:30, Jan Beulich wrote:
On 14.11.2023 18:50, Krystian Hebel wrote:
If multiple CPUs called machine_restart() before actual restart took
place, but after boot CPU declared itself not online,
Can you help me please in identifying where this operation is? I can see
two places
On 7.02.2024 18:02, Jan Beulich wrote:
On 14.11.2023 18:50, Krystian Hebel wrote:
It used to be called from smp_callin(), however BUG_ON() was invoked on
multiple occasions before that. It may end up calling machine_restart()
which tries to get APIC ID for CPU running this code. If BSP
On 5.02.2024 09:41, Jan Beulich wrote:
On 02.02.2024 19:24, Julien Grall wrote:
On 14/11/2023 17:50, Krystian Hebel wrote:
This location is easier to access from assembly. Having it close to
other data required during initialization has also positive (although
rather small) impact on
On 11.03.2024 09:59, Simone Ballarin wrote:
> From: Maria Celeste Cesario
>
> Add inclusion guard to address violations of
> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order to
> prevent the contents of a header file being included more than once").
> Mechanical change.
> ---
>
On 11.03.2024 09:59, Simone Ballarin wrote:
> From: Maria Celeste Cesario
>
> Add inclusion guard to address violations of
> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order to
> prevent the contents of a header file being included more than once").
> Mechanical change.
> ---
>
On 11.03.2024 09:59, Simone Ballarin wrote:
> From: Maria Celeste Cesario
>
> Edit inclusion guards to address violations of
> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order to
> prevent the contents of a header file being included more than once").
> Mechanical change.
The
On 12.03.2024 16:29, Krystian Hebel wrote:
> On 7.02.2024 17:41, Jan Beulich wrote:
>> On 02.02.2024 19:11, Julien Grall wrote:
>>> On 14/11/2023 17:50, Krystian Hebel wrote:
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -54,14 +54,13 @@ bool __init
On 12.03.2024 16:18, Krystian Hebel wrote:
> On 7.02.2024 17:28, Jan Beulich wrote:
>> On 14.11.2023 18:49, Krystian Hebel wrote:
>>> --- a/xen/arch/x86/apic.c
>>> +++ b/xen/arch/x86/apic.c
>>> @@ -950,7 +950,7 @@ __next:
>>>*/
>>> if (boot_cpu_physical_apicid == -1U)
>>>
On 12.03.2024 16:11, Krystian Hebel wrote:
> On 7.02.2024 17:11, Jan Beulich wrote:
>> On 14.11.2023 18:49, Krystian Hebel wrote:
>>> --- a/xen/arch/x86/boot/trampoline.S
>>> +++ b/xen/arch/x86/boot/trampoline.S
>>> +/* Not x2APIC, read from MMIO */
>>> +mov 0xfee00020, %esp
>>
On 8.02.2024 08:29, Jan Beulich wrote:
On 14.11.2023 18:50, Krystian Hebel wrote:
Both fields held the same data.
Supposedly the same data only. They come from different origins, and you're
hiding this quite well by leaving all sites in place where the field is
written. Both items are also
Hi,
On 7.02.2024 17:41, Jan Beulich wrote:
On 02.02.2024 19:11, Julien Grall wrote:
Hi,
On 14/11/2023 17:50, Krystian Hebel wrote:
Both fields held the same data.
Signed-off-by: Krystian Hebel
---
xen/arch/x86/boot/x86_64.S | 8 +---
xen/arch/x86/include/asm/asm_defns.h
When not holding the PoD lock across the entire region covering P2M
update and stats update, the entry count - if to be incorrect at all -
should indicate too large a value in preference to a too small one, to
avoid functions bailing early when they find the count is zero. However,
instead of
On 7.02.2024 17:28, Jan Beulich wrote:
On 14.11.2023 18:49, Krystian Hebel wrote:
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -950,7 +950,7 @@ __next:
*/
if (boot_cpu_physical_apicid == -1U)
boot_cpu_physical_apicid = get_apic_id();
-x86_cpu_to_apicid[0] =
On 7.02.2024 17:11, Jan Beulich wrote:
On 14.11.2023 18:49, Krystian Hebel wrote:
--- a/xen/arch/x86/boot/trampoline.S
+++ b/xen/arch/x86/boot/trampoline.S
@@ -72,6 +72,26 @@ trampoline_protmode_entry:
mov $X86_CR4_PAE,%ecx
mov %ecx,%cr4
+/*
+ *
On 12.03.2024 15:49, Marek Marczykowski-Górecki wrote:
> On Tue, Mar 12, 2024 at 03:37:15PM +0100, Jan Beulich wrote:
>> On 12.03.2024 15:24, Marek Marczykowski-Górecki wrote:
>>> On Tue, Mar 12, 2024 at 11:53:46AM +0100, Jan Beulich wrote:
On 12.03.2024 11:24, Roger Pau Monné wrote:
>>
On 11.03.2024 09:59, Simone Ballarin wrote:
> From: Maria Celeste Cesario
>
> Add safe deviation for *.c files, as estabilished in past discussion.
> Add SAF deviation for files that need an #include directive before guard.
While similar topics, the two are technically entirely different, and
On Tue, Mar 12, 2024 at 03:37:15PM +0100, Jan Beulich wrote:
> On 12.03.2024 15:24, Marek Marczykowski-Górecki wrote:
> > On Tue, Mar 12, 2024 at 11:53:46AM +0100, Jan Beulich wrote:
> >> On 12.03.2024 11:24, Roger Pau Monné wrote:
> --- a/xen/arch/x86/setup.c
> +++
On 11.03.2024 09:59, Simone Ballarin wrote:
> --- a/xen/build.mk
> +++ b/xen/build.mk
> @@ -45,6 +45,8 @@ asm-offsets.s: arch/$(SRCARCH)/$(ARCH)/asm-offsets.c
> $(CC) $(call cpp_flags,$(c_flags)) -S -g0 -o $@.new -MQ $@ $<
> $(call move-if-changed,$@.new,$@)
>
> +ARCHDIR = $(shell
On 12.03.2024 15:24, Marek Marczykowski-Górecki wrote:
> On Tue, Mar 12, 2024 at 11:53:46AM +0100, Jan Beulich wrote:
>> On 12.03.2024 11:24, Roger Pau Monné wrote:
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1806,6 +1806,9 @@ void asmlinkage __init noreturn
On 12.03.2024 12:48, Federico Serafini wrote:
> Place an "#if 0" before grep fodder definitions and remove the
> "#undef".
>
> This addresses several violations of MISRA C:2012 Rule 5.5
> ("Identifiers shall be distinct from macro names").
>
> No functional change.
>
> Signed-off-by: Federico
On Tue, Mar 12, 2024 at 11:53:46AM +0100, Jan Beulich wrote:
> On 12.03.2024 11:24, Roger Pau Monné wrote:
> >> --- a/xen/arch/x86/setup.c
> >> +++ b/xen/arch/x86/setup.c
> >> @@ -1806,6 +1806,9 @@ void asmlinkage __init noreturn __start_xen(unsigned
> >> long mbi_p)
> >> mmio_ro_ranges =
Hi,
On 26.01.2024 19:30, Julien Grall wrote:
Hi,
I am not too familiary with the x86 boot code. But I will give a try
to review :).
On 14/11/2023 17:49, Krystian Hebel wrote:
This is made as first step of making parallel AP bring-up possible. It
should be enough for pre-C code.
On 12.03.2024 14:22, Marek Marczykowski-Górecki wrote:
> On Tue, Mar 12, 2024 at 02:09:14PM +0100, Marek Marczykowski-Górecki wrote:
>> On Tue, Mar 12, 2024 at 01:38:53PM +0100, Jan Beulich wrote:
>>> On 12.03.2024 13:02, Marek Marczykowski-Górecki wrote:
BTW should e820_change_range_type()
flight 185000 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185000/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build fail REGR. vs. 184997
Tests which did
On Tue, Mar 12, 2024 at 02:09:14PM +0100, Marek Marczykowski-Górecki wrote:
> On Tue, Mar 12, 2024 at 01:38:53PM +0100, Jan Beulich wrote:
> > On 12.03.2024 13:02, Marek Marczykowski-Górecki wrote:
> > > BTW should e820_change_range_type() return 1 in case of mapping already
> > > having the right
On 11.03.2024 17:04, George Dunlap wrote:
> On Tue, Jan 4, 2022 at 10:58 AM Jan Beulich wrote:
>
>> When not holding the PoD lock across the entire region covering P2M
>> update and stats update, the entry count should indicate too large a
>> value in preference to a too small one, to avoid
On 30.11.23 03:34, Marek Marczykowski-Górecki wrote:
Hi,
While testing 6.7-rc3 on Qubes OS I found several warning like in the
subject in dom0 log. I see them when running 6.7-rc1 too. I'm not sure
what exactly triggers the issue, but my guess would be unbinding an
event channel from userspace
On Tue, Mar 12, 2024 at 01:38:53PM +0100, Jan Beulich wrote:
> On 12.03.2024 13:02, Marek Marczykowski-Górecki wrote:
> > On Tue, Mar 12, 2024 at 11:53:46AM +0100, Jan Beulich wrote:
> >> On 12.03.2024 11:24, Roger Pau Monné wrote:
> --- a/xen/arch/x86/setup.c
> +++
Currently the memory footprint of the static shared memory feature
is impacting all the struct meminfo instances with memory space
that is not going to be used.
To solve this issue, rework the static shared memory extra
information linked to the memory bank to another structure,
struct
From: Penny Zheng
In case there is a /reserved-memory node already present in the host dtb,
current Xen codes would create yet another /reserved-memory node when
the static shared memory feature is enabled and static shared memory
region are present, this would result in an incorrect device tree
This serie is a partial rework of this other serie:
https://patchwork.kernel.org/project/xen-devel/cover/20231206090623.1932275-1-penny.zh...@arm.com/
The original serie is addressing an issue of the static shared memory feature
that impacts the memory footprint of other component when the
From: Penny Zheng
Static shared memory acts as reserved memory in guest, so it shall be
excluded from extended regions.
Extended regions are taken care of under three different scenarios:
normal DomU, direct-map domain with iommu on, and direct-map domain
with iommu off.
For normal DomU, we
The function find_unallocated_memory is using the same code to
loop through 3 structure of the same type, in order to avoid
code duplication, rework the code to have only one loop that
goes through all the structures.
Signed-off-by: Luca Fancellu
---
xen/arch/arm/domain_build.c | 62
From: Penny Zheng
Putting overlap and overflow checking in the loop is causing repetitive
operation, so this commit extracts both checking outside the loop.
Signed-off-by: Penny Zheng
Signed-off-by: Luca Fancellu
---
v1:
- Rework of
The user of shm_mem member of the 'struct kernel_info' is only
the code managing the static shared memory feature, which can be
compiled out using CONFIG_STATIC_SHM, so in case the feature is
not requested, that member won't be used and will waste memory
space.
To address this issue, protect the
The function check_reserved_regions_overlap is calling
'meminfo_overlap_check' on the same type of structure, this code
can be written in a way to avoid code duplication, so rework the
function to do that.
Signed-off-by: Luca Fancellu
---
xen/arch/arm/setup.c | 24 +---
1
Currently Xen is not exporting the static shared memory regions
to the device tree as /memory node, this commit is fixing this
issue.
Signed-off-by: Luca Fancellu
---
xen/arch/arm/dom0less-build.c | 5 +++
xen/arch/arm/domain_build.c | 7 +++-
Introduce a new helper function in the static-memory module
that can be called to manage static memory banks, this is
done to reuse the code when other modules would like to
manage static memory banks that are not part of the
reserved_mem structure.
Signed-off-by: Luca Fancellu
---
Currently the 'stuct meminfo' is defining a static defined array of
'struct membank' of NR_MEM_BANKS elements, some feature like
shared memory don't require such amount of memory allocation but
might want to reuse existing code to manipulate this kind of
structure that is just as 'struct meminfo'
From: Penny Zheng
Function parameters {addr_cells,size_cells} are stale parameters in
assign_shared_memory, so we shall remove them.
Signed-off-by: Penny Zheng
Signed-off-by: Luca Fancellu
Reviewed-by: Michal Orzel
---
v1:
- This is this patch:
... if available only, of course.
Signed-off-by: Jan Beulich
---
I don't really like issuing an IPI (and having another cf_check
function) here, yet then again this is issued only when the debug key
is actually used, and given how simple the handling function is
(including that it doesn't use
On 12.03.2024 13:02, Marek Marczykowski-Górecki wrote:
> On Tue, Mar 12, 2024 at 11:53:46AM +0100, Jan Beulich wrote:
>> On 12.03.2024 11:24, Roger Pau Monné wrote:
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1806,6 +1806,9 @@ void asmlinkage __init noreturn
On Tue, Mar 12, 2024 at 11:53:46AM +0100, Jan Beulich wrote:
> On 12.03.2024 11:24, Roger Pau Monné wrote:
> >> --- a/xen/arch/x86/setup.c
> >> +++ b/xen/arch/x86/setup.c
> >> @@ -1806,6 +1806,9 @@ void asmlinkage __init noreturn __start_xen(unsigned
> >> long mbi_p)
> >> mmio_ro_ranges =
Place an "#if 0" before grep fodder definitions and remove the
"#undef".
This addresses several violations of MISRA C:2012 Rule 5.5
("Identifiers shall be distinct from macro names").
No functional change.
Signed-off-by: Federico Serafini
---
Hello, I would like to know what you think about
On 2024-03-12 12:25, Jan Beulich wrote:
On 12.03.2024 12:13, Nicola Vetrini wrote:
Rule 20.4 states: "A macro shall not be defined with the same name
as a keyword".
Defining this macro with the same name as the inline keyword
allows for additionally checking that out-of-lined static inline
On 12.03.2024 12:13, Nicola Vetrini wrote:
> Rule 20.4 states: "A macro shall not be defined with the same name
> as a keyword".
>
> Defining this macro with the same name as the inline keyword
> allows for additionally checking that out-of-lined static inline
> functions end up in the correct
On 30/01/2024 14.01, Igor Mammedov wrote:
On Mon, 29 Jan 2024 17:44:56 +0100
Philippe Mathieu-Daudé wrote:
Mechanical patch produced running the command documented
in scripts/coccinelle/cpu_env.cocci_template header.
commenting here since, I'm not expert on coccinelle scripts.
On negative
Rule 20.4 states: "A macro shall not be defined with the same name
as a keyword".
Defining this macro with the same name as the inline keyword
allows for additionally checking that out-of-lined static inline
functions end up in the correct section while minimizing churn and
has a positive impact
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
> expression of an iteration-statement
On 3/12/24 11:49, Jan Beulich wrote:
On 12.03.2024 11:00, Vaishali Thakkar wrote:
On 3/12/24 08:54, Jan Beulich wrote:
On 11.03.2024 13:40, Vaishali Thakkar wrote:
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -571,7 +571,7 @@ static int
On 12.03.2024 11:24, Roger Pau Monné wrote:
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -1806,6 +1806,9 @@ void asmlinkage __init noreturn __start_xen(unsigned
>> long mbi_p)
>> mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges",
>>
On 12.03.2024 11:08, Vaishali Thakkar wrote:
> On 3/12/24 08:59, Jan Beulich wrote:
>> On 11.03.2024 13:40, Vaishali Thakkar wrote:
>>> @@ -698,11 +698,11 @@ nsvm_vcpu_vmentry(struct vcpu *v, struct
>>> cpu_user_regs *regs,
>>> /* Convert explicitely to boolean. Deals with l1 guests
>>>
On 12.03.2024 11:00, Vaishali Thakkar wrote:
> On 3/12/24 08:54, Jan Beulich wrote:
>> On 11.03.2024 13:40, Vaishali Thakkar wrote:
>>> --- a/xen/arch/x86/hvm/svm/nestedsvm.c
>>> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c
>>> @@ -571,7 +571,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v,
>>>
On 12.03.2024 11:33, Julien Grall wrote:
> Hi Jan,
>
> On 12/03/2024 10:27, Jan Beulich wrote:
>> There's no use of them anymore except in the definitions of the non-
>> underscore-prefixed aliases.
>>
>> On Arm convert the (renamed) inline function to a macro.
>>
>> On x86 rename the inline
Hi Julien,
On Tue, 2024-03-12 at 10:33 +, Julien Grall wrote:
> Hi Jan,
>
> On 12/03/2024 10:27, Jan Beulich wrote:
> > There's no use of them anymore except in the definitions of the
> > non-
> > underscore-prefixed aliases.
> >
> > On Arm convert the (renamed) inline function to a macro.
Hi Jan,
On 12/03/2024 10:27, Jan Beulich wrote:
There's no use of them anymore except in the definitions of the non-
underscore-prefixed aliases.
On Arm convert the (renamed) inline function to a macro.
On x86 rename the inline functions, adjust the virt_to_maddr() #define,
and purge the
There's no use of them anymore except in the definitions of the non-
underscore-prefixed aliases.
On Arm convert the (renamed) inline function to a macro.
On x86 rename the inline functions, adjust the virt_to_maddr() #define,
and purge the maddr_to_virt() one, thus eliminating a bogus cast
On Mon, Mar 11, 2024 at 09:33:11PM +0100, Marek Marczykowski-Górecki wrote:
> The IOMMU driver checks if RMRR/IVMD are marked as reserved in memory
> map. This should be true for addresses coming from the firmware, but
> when extra pages used by Xen itself are included in the mapping, those
> are
Hi Simone,
On 11/03/2024 08:59, Simone Ballarin wrote:
Amend inclusion guards to address violations of
MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
to prevent the contents of a header file being included more than
once").
Inclusion guards must appear at the beginning of
On 3/12/24 08:59, Jan Beulich wrote:
On 11.03.2024 13:40, Vaishali Thakkar wrote:
@@ -698,11 +698,11 @@ nsvm_vcpu_vmentry(struct vcpu *v, struct cpu_user_regs
*regs,
/* Convert explicitely to boolean. Deals with l1 guests
* that use flush-by-asid w/o checking the cpuid bits */
On 3/12/24 08:54, Jan Beulich wrote:
On 11.03.2024 13:40, Vaishali Thakkar wrote:
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -571,7 +571,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct
cpu_user_regs *regs)
if (
On 11.03.2024 09:59, Simone Ballarin wrote:
> --- a/docs/misra/safe.json
> +++ b/docs/misra/safe.json
> @@ -52,6 +52,14 @@
> },
> {
> "id": "SAF-6-safe",
> +"analyser": {
> +"eclair": "MC3R1.D4.10"
> +},
> +"name":
On 11.03.2024 09:59, Simone Ballarin wrote:
> Amend inclusion guards to address violations of
> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
> to prevent the contents of a header file being included more than
> once").
>
> Inclusion guards must appear at the beginning of the
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-macros.h: $(obj)/asm-macros.i
> $(src)/Makefile
> $(call filechk,asm-macros.h)
>
>
flight 184998 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184998/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build fail REGR. vs. 184996
Tests which are
On 11.03.2024 13:40, Vaishali Thakkar wrote:
> While sev and sev_es bits are not yet enabled in xen,
> including their status in the VMCB dump could be
> informational.Therefore, print it via svmdebug.
Yet there are more bits there. I'm okay with leaving off printing of
them here, but it wants
On 11.03.2024 13:40, Vaishali Thakkar wrote:
> @@ -698,11 +698,11 @@ nsvm_vcpu_vmentry(struct vcpu *v, struct cpu_user_regs
> *regs,
> /* Convert explicitely to boolean. Deals with l1 guests
> * that use flush-by-asid w/o checking the cpuid bits */
> nv->nv_flushp2m =
On 11.03.2024 13:40, Vaishali Thakkar wrote:
> --- a/xen/arch/x86/hvm/svm/nestedsvm.c
> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c
> @@ -571,7 +571,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct
> cpu_user_regs *regs)
> if ( nestedhvm_paging_mode_hap(v) )
> {
> /*
Hi Jan,
On 3/12/2024 3:34 PM, Jan Beulich wrote:
On 12.03.2024 04:44, Henry Wang wrote:
On 3/12/2024 1:07 AM, Jan Beulich wrote:
On 08.03.2024 02:54, Henry Wang wrote:
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -41,6 +41,11 @@
#define XENMEMF_exact_node(n)
On 12.03.2024 04:44, Henry Wang wrote:
> On 3/12/2024 1:07 AM, Jan Beulich wrote:
>> On 08.03.2024 02:54, Henry Wang wrote:
>>> --- a/xen/include/public/memory.h
>>> +++ b/xen/include/public/memory.h
>>> @@ -41,6 +41,11 @@
>>> #define XENMEMF_exact_node(n) (XENMEMF_node(n) |
>>>
flight 184997 linux-linus real [real]
flight 184999 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184997/
http://logs.test-lab.xenproject.org/osstest/logs/184999/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
93 matches
Mail list logo
