flight 187652 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187652/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9a4088777fbe7941664ad9bb2bd78446d223cbf9
baseline version:
ovmf 1328938560be440f25c12
different physical
address")
I have used the xen-tip tree from next-20240910 for today.
--
Cheers,
Stephen Rothwell
pgp4l69opUXsN.pgp
Description: OpenPGP digital signature
On 9/10/24 04:09, Jason Andryuk wrote:
From: Jason Andryuk
Probing xen-fbfront faults in video_is_primary_device(). The passed-in
struct device is NULL since xen-fbfront doesn't assign it and the
memory is kzalloc()-ed. Assign fb_info->device to avoid this.
This was exposed by the conversion
On Tue, 10 Sep 2024, Alessandro Zucchelli wrote:
> Add deviation 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").
>
> This deviation suppresses the violation arising from autogen
flight 187644 linux-linus real [real]
flight 187651 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187644/
http://logs.test-lab.xenproject.org/osstest/logs/187651/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
On Tue, 10 Sep 2024, Jan Beulich wrote:
> On 10.09.2024 10:18, Nicola Vetrini wrote:
> > On 2024-09-10 08:26, Jan Beulich wrote:
> >> On 10.09.2024 06:46, Stefano Stabellini wrote:
> >>> On Mon, 9 Sep 2024, Jan Beulich wrote:
> On 07.09.2024 15:03, Nicola Vetrini wrote:
> > + * - R18.2
>
On Tue, 10 Sep 2024, Julien Grall wrote:
> Hi,
>
> On 10/09/2024 15:34, Andrei Cherechesu (OSS) wrote:
> > From: Andrei Cherechesu
> >
> > Added support for NXP S32CC platforms (S32G2, S32G3, S32R45),
> > which need SCMI over SMC calls forwarded to the firmware
> > running at EL3 (TF-A). Linux r
flight 187650 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187650/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1328938560be440f25c122bcf6635af210291a4e
baseline version:
ovmf b1ce2e1b67ff3b2478739
flight 187641 xen-unstable real [real]
flight 187647 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187641/
http://logs.test-lab.xenproject.org/osstest/logs/187647/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
Hi,
On 10/09/2024 15:34, Andrei Cherechesu (OSS) wrote:
From: Andrei Cherechesu
Enabled the support for debug through early printk on S32CC
NIT: We tend to avoid using past tense when describing the change. So
s/Enabled/Enable/. However...
platforms via the NXP LINFlexD UART driver.
Sig
Hi,
On 10/09/2024 15:34, Andrei Cherechesu (OSS) wrote:
From: Andrei Cherechesu
Added support for NXP S32CC platforms (S32G2, S32G3, S32R45),
which need SCMI over SMC calls forwarded to the firmware
running at EL3 (TF-A). Linux relies on the SCMI Platform
for system services such as clocking,
Hi,
On 10/09/2024 15:34, Andrei Cherechesu (OSS) wrote:
From: Andrei Cherechesu
This adds support for early printk debug via the NXP LINFlexD
UART controller.
Signed-off-by: Andrei Cherechesu
Signed-off-by: Peter van der Perk
---
xen/arch/arm/Kconfig.debug | 14 +++
xen/arc
Hi,
On 10/09/2024 15:34, Andrei Cherechesu (OSS) wrote:
From: Andrei Cherechesu
The LINFlexD UART is an UART controller available on NXP S32
processors family targeting automotive (for example: S32G2, S32G3,
S32R).
S32G3 Reference Manual:
https://www.nxp.com/webapp/Download?colCode=RMS32G3.
Hi Ayan,
On 10/09/2024 14:42, Ayan Kumar Halder wrote:
On 09/09/2024 15:45, Julien Grall wrote:
Hi Ayan,
Hi Julien,
On 09/09/2024 11:29, Ayan Kumar Halder wrote:
On 08/09/2024 22:13, Julien Grall wrote:
Hi,
Hi Julien,
On 02/09/2024 15:48, Ayan Kumar Halder wrote:
I will rephrase th
flight 187629 qemu-mainline real [real]
flight 187645 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187629/
http://logs.test-lab.xenproject.org/osstest/logs/187645/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
Refactor the code to improve readability and address violations of
MISRA C:2012 Rule 13.6 ("The operand of the `sizeof' operator shall
not contain any expression which has potential side effect").
No functional change.
Suggested-by: Andrew Cooper
Signed-off-by: Federico Serafini
---
xen/common
Address remaining violations of Rule 13.6 and tag it as clean.
Federico Serafini (3):
EFI: address violations of MISRA C Rule 13.6
xen/gnttab: address violations of MISRA C Rule 13.6
automation/eclair: tag Rule 13.6 as clean
automation/eclair_analysis/ECLAIR/tagging.ecl | 1 +
xen/common/
Refactor the code to improve readability and address violations of
MISRA C:2012 Rule 13.6 ("The operand of the `sizeof' operator shall
not contain any expression which has potential side effect").
No functional change.
Suggested-by: Andrew Cooper
Signed-off-by: Federico Serafini
---
xen/common
Update ECLAIR configuration to consider Rule 13.6 as clean:
introducing violations of this rule will cause a failure of the CI pipeline.
Signed-off-by: Federico Serafini
---
automation/eclair_analysis/ECLAIR/tagging.ecl | 1 +
1 file changed, 1 insertion(+)
diff --git a/automation/eclair_analys
On 10/09/2024 3:41 pm, Jan Beulich wrote:
> No uses are left, hence its setup, teardown, and the field itself can
> also go away. stdvga_deinit() is then empty and can be dropped as well.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper , although I think
there's more to do.
> ---
> I h
On 10/09/2024 3:41 pm, Jan Beulich wrote:
> No consumers are left, hence the producer and the fields themselves can
> also go away. stdvga_outb() is then useless, rendering stdvga_out()
> useless as well. Hence the entire I/O port intercept can go away.
>
> Signed-off-by: Jan Beulich
Reviewed-by:
On 10/09/2024 3:41 pm, Jan Beulich wrote:
> No consumers are left, hence the producer and the array itself can also
> go away. The static sr_mask[] is then orphaned and hence needs dropping,
> too.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
On 10/09/2024 3:40 pm, Jan Beulich wrote:
> No consumers are left, hence the producer and the array itself can also
> go away. The static gr_mask[] is then orphaned and hence needs dropping,
> too.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
On 10/09/2024 3:40 pm, Jan Beulich wrote:
> All read accesses are rejected by the ->accept handler, while writes
> bypass the bulk of the function body. Drop the dead code, leaving an
> assertion in the read handler.
>
> A number of other static items (and a macro) are then unreferenced and
> hence
On 10/09/24 16:55, Jan Beulich wrote:
On 10.09.2024 12:08, Federico Serafini wrote:
Address violations of MISRA C:2012 Rule 16.3:
"An unconditional `break' statement shall terminate every
switch-clause".
No functional change.
Signed-off-by: Federico Serafini
---
xen/arch/x86/mm/guest_walk.c
On 10/09/2024 3:40 pm, Jan Beulich wrote:
> Two of its consumers are dead (in compile-time constant conditionals)
> and the only remaining ones are merely controlling (debugging) log
> messages.
Minor, but I'd phrase this as "merely controlling debug logging."
> Hence the field is now pointless
On 10/09/24 19:41, Federico Serafini wrote:
On 10/09/24 16:59, Jan Beulich wrote:
On 10.09.2024 16:57, Jan Beulich wrote:
On 10.09.2024 12:09, Federico Serafini wrote:
Address violations of MISRA C:2012 Rule 16.3:
"An unconditional `break' statement shall terminate every
switch-clause".
Sinc
On 10/09/24 16:59, Jan Beulich wrote:
On 10.09.2024 16:57, Jan Beulich wrote:
On 10.09.2024 12:09, Federico Serafini wrote:
Address violations of MISRA C:2012 Rule 16.3:
"An unconditional `break' statement shall terminate every
switch-clause".
Since in our interpretation "return" is okay too,
On Tue, Sep 10, 2024 at 6:09 AM Federico Serafini
wrote:
>
> Address a violation of MISRA C:2012 Rule 16.3:
> "An unconditional `break' statement shall terminate every
> switch-clause".
>
> No functional change.
>
> Signed-off-by: Federico Serafini
Acked-by: Tamas K Lengyel
On Tue, Sep 10, 2024 at 6:09 AM Federico Serafini
wrote:
>
> Address a violation of MISRA C:2012 Rule 16.3:
> "An unconditional `break' statement shall terminate every
> switch-clause".
>
> No functional change.
>
> Signed-off-by: Federico Serafini
Acked-by: Tamas K Lengyel
On 10/09/2024 3:38 pm, Jan Beulich wrote:
> It's been unused for nearly 9 years. By the end of the series stdvga.c's
> sole purpose will be to make sure VRAM writes use the bufio ioreq path.
>
> 1: drop stdvga's "cache" struct member
> 2: drop stdvga's "stdvga" struct member
> 3: remove unused MMIO
On 10/09/2024 3:39 pm, Jan Beulich wrote:
> As of 68e1183411be ("libxc: introduce a xc_dom_arch for hvm-3.0-x86_32
> guests") caching mode is disabled for HVM domains from start-of-day, due
> the disabling being unconditional in hvm/save.c:arch_hvm_load(). With
> that the field is useless, and can
On Tue, Sep 10, 2024 at 04:29:43PM +0200, Jan Beulich wrote:
> On 10.09.2024 16:24, Roger Pau Monné wrote:
> > On Tue, Sep 10, 2024 at 03:49:52PM +0200, Jan Beulich wrote:
> >> On 10.09.2024 15:10, Roger Pau Monné wrote:
> >>> Would you be fine with
> >>> adding the following in init_xen_time():
>
The 2 code paths were sharing quite some common code, reuse it instead
of having duplications.
Use %ebp register to store boot type before running common code.
Signed-off-by: Frediano Ziglio
---
xen/arch/x86/boot/head.S | 113 +++
1 file changed, 44 insertions
This series came from part of the work of removing duplications
between boot code and rewriting part of code from assembly to C.
First 2 patches rework BIOS/PVH paths to reuse some code.
Third patch rewrites EFI code in pure C.
Frediano Ziglio (3):
x86/boot: Initialise BSS as soon as possible
No need to have it coded in assembly.
Signed-off-by: Frediano Ziglio
---
xen/arch/x86/boot/head.S | 131 ++
xen/arch/x86/efi/Makefile | 1 +
xen/arch/x86/efi/parse-mbi2.c | 54 ++
xen/arch/x86/efi/stub.c | 3 +-
4 files changed, 80
Allows to call C code earlier.
Signed-off-by: Frediano Ziglio
---
xen/arch/x86/boot/head.S | 86
1 file changed, 44 insertions(+), 42 deletions(-)
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 12bbb97f33..de118d72f2 100644
--- a/
On 10.09.2024 17:55, oleksii.kuroc...@gmail.com wrote:
> On Tue, 2024-09-10 at 12:01 +0200, Jan Beulich wrote:
>> On 02.09.2024 19:01, Oleksii Kurochko wrote:
>>> Set up fixmap mappings and the L0 page table for fixmap support.
>>>
>>> Modify the Page Table Entries (PTEs) directly in arch_pmap_map(
On 10.09.2024 17:28, oleksii.kuroc...@gmail.com wrote:
> On Tue, 2024-09-10 at 11:53 +0200, Jan Beulich wrote:
>> On 02.09.2024 19:01, Oleksii Kurochko wrote:
>>> --- a/xen/arch/riscv/include/asm/atomic.h
>>> +++ b/xen/arch/riscv/include/asm/atomic.h
>>> @@ -54,16 +54,16 @@ static always_inline voi
On Tue, 2024-09-10 at 12:01 +0200, Jan Beulich wrote:
> On 02.09.2024 19:01, Oleksii Kurochko wrote:
> > Set up fixmap mappings and the L0 page table for fixmap support.
> >
> > Modify the Page Table Entries (PTEs) directly in arch_pmap_map()
> > instead of using set_fixmap() ( which relies on map
On Tue, 2024-09-10 at 11:53 +0200, Jan Beulich wrote:
> On 02.09.2024 19:01, Oleksii Kurochko wrote:
> > --- a/xen/arch/riscv/include/asm/atomic.h
> > +++ b/xen/arch/riscv/include/asm/atomic.h
> > @@ -54,16 +54,16 @@ static always_inline void
> > read_atomic_size(const volatile void *p,
> > })
> >
On 10.09.2024 16:57, Jan Beulich wrote:
> On 10.09.2024 12:09, Federico Serafini wrote:
>> Address violations of MISRA C:2012 Rule 16.3:
>> "An unconditional `break' statement shall terminate every
>> switch-clause".
>
> Since in our interpretation "return" is okay too, why is not sufficient to
>
On 10.09.2024 12:09, Federico Serafini wrote:
> Address violations of MISRA C:2012 Rule 16.3:
> "An unconditional `break' statement shall terminate every
> switch-clause".
Since in our interpretation "return" is okay too, why is not sufficient to
simply ...
> --- a/xen/drivers/passthrough/pci.c
>
On 10.09.2024 12:08, Federico Serafini wrote:
> Address a violation of MISRA C:2012 Rule 16.3:
> "An unconditional `break' statement shall terminate every
> switch-clause".
>
> No functional change.
>
> Signed-off-by: Federico Serafini
Acked-by: Jan Beulich
On 10.09.2024 12:08, Federico Serafini wrote:
> Address violations of MISRA C:2012 Rule 16.3:
> "An unconditional `break' statement shall terminate every
> switch-clause".
>
> No functional change.
>
> Signed-off-by: Federico Serafini
> ---
> xen/arch/x86/mm/guest_walk.c | 1 +
> xen/arch/x
On 10.09.2024 12:08, Federico Serafini wrote:
> Address violations of MISRA C:2012 Rule 16.3:
> "An unconditional `break' statement shall terminate every
> switch-clause".
>
> No functional change.
>
> Signed-off-by: Federico Serafini
Acked-by: Jan Beulich
On 10.09.2024 12:09, Federico Serafini wrote:
> --- a/xen/drivers/vpci/msix.c
> +++ b/xen/drivers/vpci/msix.c
> @@ -364,6 +364,8 @@ static int adjacent_read(const struct domain *d, const
> struct vpci_msix *msix,
>
> default:
> ASSERT_UNREACHABLE();
> +spin_unlock(&vpci->lo
No consumers are left, hence the producer and the fields themselves can
also go away. stdvga_outb() is then useless, rendering stdvga_out()
useless as well. Hence the entire I/O port intercept can go away.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/stdvga.c
+++ b/xen/arch/x86/hvm/stdvga.c
No uses are left, hence its setup, teardown, and the field itself can
also go away. stdvga_deinit() is then empty and can be dropped as well.
Signed-off-by: Jan Beulich
---
I have no idea whether in the tool stack some memory calculations would
want adjusting, to account for the 256k less that a
On 10.09.2024 12:08, Federico Serafini wrote:
> Address violations of MISRA C:2012 Rule 16.3:
> "An unconditional `break' statement shall terminate every
> switch-clause".
>
> No functional change.
>
> Signed-off-by: Federico Serafini
Acked-by: Jan Beulich
On 10.09.2024 12:08, Federico Serafini wrote:
> Address a violation of MISRA C:2012 Rule 16.3:
> "An unconditional `break' statement shall terminate every
> switch-clause".
>
> No functional change.
>
> Signed-off-by: Federico Serafini
Acked-by: Jan Beulich
Two of its consumers are dead (in compile-time constant conditionals)
and the only remaining ones are merely controlling (debugging) log
messages. Hence the field is now pointless to set, which in particular
allows to get rid of the questionable conditional from which the field's
value was establis
No consumers are left, hence the producer and the array itself can also
go away. The static sr_mask[] is then orphaned and hence needs dropping,
too.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/stdvga.c
+++ b/xen/arch/x86/hvm/stdvga.c
@@ -37,18 +37,6 @@
#define VGA_MEM_BASE 0xa
#defi
All read accesses are rejected by the ->accept handler, while writes
bypass the bulk of the function body. Drop the dead code, leaving an
assertion in the read handler.
A number of other static items (and a macro) are then unreferenced and
hence also need (want) dropping. The same applies to the "
No consumers are left, hence the producer and the array itself can also
go away. The static gr_mask[] is then orphaned and hence needs dropping,
too.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/stdvga.c
+++ b/xen/arch/x86/hvm/stdvga.c
@@ -49,18 +49,6 @@ static const uint8_t sr_mask[8] = {
As of 68e1183411be ("libxc: introduce a xc_dom_arch for hvm-3.0-x86_32
guests") caching mode is disabled for HVM domains from start-of-day, due
the disabling being unconditional in hvm/save.c:arch_hvm_load(). With
that the field is useless, and can be dropped. Drop the helper functions
manipulating
It's been unused for nearly 9 years. By the end of the series stdvga.c's
sole purpose will be to make sure VRAM writes use the bufio ioreq path.
1: drop stdvga's "cache" struct member
2: drop stdvga's "stdvga" struct member
3: remove unused MMIO handling code
4: drop stdvga's "gr[]" struct member
From: Andrei Cherechesu
Added support for NXP S32CC platforms (S32G2, S32G3, S32R45),
which need SCMI over SMC calls forwarded to the firmware
running at EL3 (TF-A). Linux relies on the SCMI Platform
for system services such as clocking, reset, etc.
S32CC platforms use the NXP LINFlexD UART driv
From: Andrei Cherechesu
The LINFlexD UART is an UART controller available on NXP S32
processors family targeting automotive (for example: S32G2, S32G3,
S32R).
S32G3 Reference Manual:
https://www.nxp.com/webapp/Download?colCode=RMS32G3.
Signed-off-by: Andrei Cherechesu
Signed-off-by: Peter van
From: Andrei Cherechesu
This adds support for early printk debug via the NXP LINFlexD
UART controller.
Signed-off-by: Andrei Cherechesu
Signed-off-by: Peter van der Perk
---
xen/arch/arm/Kconfig.debug | 14 +++
xen/arch/arm/arm64/debug-linflex.inc | 58 ++
From: Andrei Cherechesu
This patch series adds support for NXP Automotive S32CC platform
family, which includes S32G [0] and S32R [1].
First patch adds the driver for the NXP LINFlexD UART, available
on S32V, S32G and S32R automotive processors. The compatibles in
the driver match the ones in up
From: Andrei Cherechesu
All versions of Cortex-A53 cores are affected by the speculative
AT instruction erratum, as mentioned in the Cortex-A53 Revision r0
SDEN v21 documentation.
Enabled ARM64_WORKAROUND_AT_SPECULATE for all versions of Cortex-A53
cores, to avoid corrupting the TLB if performin
From: Andrei Cherechesu
Enabled the support for debug through early printk on S32CC
platforms via the NXP LINFlexD UART driver.
Signed-off-by: Andrei Cherechesu
---
xen/arch/arm/Kconfig.debug | 4
1 file changed, 4 insertions(+)
diff --git a/xen/arch/arm/Kconfig.debug b/xen/arch/arm/Kcon
On 10.09.2024 16:24, Roger Pau Monné wrote:
> On Tue, Sep 10, 2024 at 03:49:52PM +0200, Jan Beulich wrote:
>> On 10.09.2024 15:10, Roger Pau Monné wrote:
>>> Would you be fine with
>>> adding the following in init_xen_time():
>>>
>>> /*
>>> * EFI run time services can be disabled form the
On Tue, Sep 10, 2024 at 03:49:52PM +0200, Jan Beulich wrote:
> On 10.09.2024 15:10, Roger Pau Monné wrote:
> > On Tue, Sep 10, 2024 at 11:32:05AM +0200, Jan Beulich wrote:
> >> On 09.09.2024 16:54, Roger Pau Monne wrote:
> >>> --- a/xen/arch/x86/time.c
> >>> +++ b/xen/arch/x86/time.c
> >>> @@ -1550
Add deviation 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").
This deviation suppresses the violation arising from autogenerated file
xen/include/generated/autoconf.h
No functional
On 10.09.24 15:59, Roger Pau Monné wrote:
On Tue, Sep 10, 2024 at 03:46:00PM +0200, Jürgen Groß wrote:
On 10.09.24 13:46, Roger Pau Monne wrote:
Current blkif implementations (both backends and frontends) have all slight
differences about how they handle the 'sector-size' xenstore node, and how
On Tue, Sep 10, 2024 at 03:46:00PM +0200, Jürgen Groß wrote:
> On 10.09.24 13:46, Roger Pau Monne wrote:
> > Current blkif implementations (both backends and frontends) have all slight
> > differences about how they handle the 'sector-size' xenstore node, and how
> > other fields are derived from t
On Tue, 2024-09-10 at 11:42 +0200, Jan Beulich wrote:
> On 02.09.2024 19:01, Oleksii Kurochko wrote:
> > Implement machine_restart() using printk() to prevent recursion
> > that
> > occurs when ASSERT(), BUG*(), or panic() are invoked.
> > All these macros (except panic() which could be called dire
On 10.09.2024 15:10, Roger Pau Monné wrote:
> On Tue, Sep 10, 2024 at 11:32:05AM +0200, Jan Beulich wrote:
>> On 09.09.2024 16:54, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/time.c
>>> +++ b/xen/arch/x86/time.c
>>> @@ -1550,6 +1550,36 @@ static const char *__init
>>> wallclock_type_to_string(vo
On 29.08.24 10:47, Shen Lichuan wrote:
Use ERR_CAST() as it is designed for casting an error pointer to
another type.
This macro utilizes the __force and __must_check modifiers, which instruct
the compiler to verify for errors at the locations where it is employed.
Signed-off-by: Shen Lichuan
On 10.09.24 13:46, Roger Pau Monne wrote:
Current blkif implementations (both backends and frontends) have all slight
differences about how they handle the 'sector-size' xenstore node, and how
other fields are derived from this value or hardcoded to be expressed in units
of 512 bytes.
To give so
flight 187623 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187623/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 187595
test-amd64-amd64-xl-qemut-win7-amd64
On 09/09/2024 15:45, Julien Grall wrote:
Hi Ayan,
Hi Julien,
On 09/09/2024 11:29, Ayan Kumar Halder wrote:
On 08/09/2024 22:13, Julien Grall wrote:
Hi,
Hi Julien,
On 02/09/2024 15:48, Ayan Kumar Halder wrote:
I will rephrase this as ...
"Used to set customized address at which whic
Ping?
I think this is a useful change, could we please have a new version
with the proposed adjustments?
Thanks, Roger.
On Wed, Apr 24, 2024 at 03:18:26PM -0400, Daniel P. Smith wrote:
> From: Stefano Stabellini
>
> Xen always generates as XSDT table even if the firmware provided an RSDT
> ta
On Tue, Sep 10, 2024 at 11:32:05AM +0200, Jan Beulich wrote:
> On 09.09.2024 16:54, Roger Pau Monne wrote:
> > Allow setting the used wallclock from the command line. When the option is
> > set
> > to a value different than `auto` the probing is bypassed and the selected
> > implementation is use
On 10.09.24 14:34, Jan Beulich wrote:
On 10.09.2024 12:39, Juergen Gross wrote:
When running as a Xen PV dom0 the system needs to map ACPI data of the
host using host physical addresses, while those addresses can conflict
with the guest physical addresses of the loaded linux kernel. The same
pro
On 10.09.24 14:26, Jan Beulich wrote:
On 10.09.2024 12:39, Juergen Gross wrote:
When running as a Xen PV dom0 it can happen that the kernel is being
loaded to a guest physical address conflicting with the host memory
map.
In order to be able to resolve this conflict, add the capability to
remap
MISRA Rule 20.7 states:
"Expressions resulting from the expansion of macro parameters
shall be enclosed in parentheses".
The files imported from the gnu-efi package are already deviated, yet
the macro NextMemoryDescriptor is used in non-excluded code, so a further
deviation is needed to exclude al
On 10/09/2024 14:16, Ayan Kumar Halder wrote:
> Hi Julien,
>
> On 09/09/2024 21:59, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 09/09/2024 20:53, Stefano Stabellini wrote:
>>> On Mon, 9 Sep 2024, Julien Grall wrote:
On 09/09/2024 10:50, Ayan Kumar Halder wrote:
> On 09/09/2024 10:11, J
On 10.09.2024 12:39, Juergen Gross wrote:
> In order to minimize required special handling for running as Xen PV
> dom0, the memory layout is modified to match that of the host. This
> requires to have only RAM at the locations where Xen allocated memory
> is living. Unfortunately there seem to be
On 10.09.2024 12:39, Juergen Gross wrote:
> When running as a Xen PV dom0 the system needs to map ACPI data of the
> host using host physical addresses, while those addresses can conflict
> with the guest physical addresses of the loaded linux kernel. The same
> problem might apply in case a PV gue
On 10.09.2024 12:39, Juergen Gross wrote:
> When running as a Xen PV dom0 it can happen that the kernel is being
> loaded to a guest physical address conflicting with the host memory
> map.
>
> In order to be able to resolve this conflict, add the capability to
> remap non-RAM areas to different g
On Tue, Sep 10, 2024 at 02:18:35PM +0200, Arthur Borsboom wrote:
> On Tue, 10 Sept 2024 at 10:33, Greg KH wrote:
> >
> > On Tue, Sep 10, 2024 at 10:13:01AM +0200, Roger Pau Monné wrote:
> > > On Tue, Sep 10, 2024 at 09:29:30AM +0200, Thomas Zimmermann wrote:
> > > > Hi
> > > >
> > > > Am 10.09.24
On Tue, 10 Sept 2024 at 10:33, Greg KH wrote:
>
> On Tue, Sep 10, 2024 at 10:13:01AM +0200, Roger Pau Monné wrote:
> > On Tue, Sep 10, 2024 at 09:29:30AM +0200, Thomas Zimmermann wrote:
> > > Hi
> > >
> > > Am 10.09.24 um 09:22 schrieb Roger Pau Monné:
> > > > On Mon, Sep 09, 2024 at 10:09:16PM -0
On 02.09.2024 19:01, Oleksii Kurochko wrote:
> Implement map_pages_to_xen() which requires several
> functions to manage page tables and entries:
> - pt_update()
> - pt_mapping_level()
> - pt_update_entry()
> - pt_next_level()
> - pt_check_entry()
>
> To support these operations, add functions for
Hi Julien,
On 09/09/2024 21:59, Julien Grall wrote:
Hi Stefano,
On 09/09/2024 20:53, Stefano Stabellini wrote:
On Mon, 9 Sep 2024, Julien Grall wrote:
On 09/09/2024 10:50, Ayan Kumar Halder wrote:
On 09/09/2024 10:11, Julien Grall wrote:
On 09/09/2024 09:56, Michal Orzel wrote:
Hi Julien
Current blkif implementations (both backends and frontends) have all slight
differences about how they handle the 'sector-size' xenstore node, and how
other fields are derived from this value or hardcoded to be expressed in units
of 512 bytes.
To give some context, this is an excerpt of how differ
On 02.09.2024 19:01, Oleksii Kurochko wrote:
> Introduce functions to work with the SBI RFENCE extension for issuing
> various fence operations to remote CPUs.
>
> Add the sbi_init() function along with auxiliary functions and macro
> definitions for proper initialization and checking the availabi
Since recently in the commit e469e2045f1b ("ALSA: memalloc: Let IOMMU
handle S/G primarily"), the SG buffer allocation code was modified to
use the standard DMA code primarily and the fallback is applied only
limitedly. This made the Xen PV specific workarounds we took in the
commit 53466ebdec61 (
On Mon, 09 Sep 2024 22:02:08 +0200,
Elliott Mitchell wrote:
>
> On Sat, Sep 07, 2024 at 11:38:50AM +0100, Andrew Cooper wrote:
> > On 07/09/2024 8:46 am, Takashi Iwai wrote:
> > > On Fri, 06 Sep 2024 20:42:09 +0200,
> > > Ariadne Conill wrote:
> > >> This patch attempted to work around a DMA issue
On 10/09/2024 10:12 am, Jan Beulich wrote:
> On 10.09.2024 10:48, Nicola Vetrini wrote:
>> Rule 7.3 states:
>> "The lowercase character l shall not be used in a literal suffix",
>> but the INTEL_MSR_RANGE macro uses the "ull" suffix.
>> The "u" is transformed in uppercase for consistency.
>>
>> No
flight 187638 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187638/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b1ce2e1b67ff3b2478739976e952ac719010f019
baseline version:
ovmf 61f9695f20a575085d057
MISRA C:2012 Rule 20.7 states that "Expressions resulting from the
expansion of macro parameters shall be enclosed in parentheses".
The rational of the rule is that if a macro argument expands to an
expression, there may be problems related to operator precedence, e.g.,
define M(A, B) A * B
M(1+1
Update ECLAIR configuration to deviate some safe violations of Rule 20.7.
Remove redundant comment-based deviations.
Federico Serafini (2):
automation/eclair: update configuration of Rule 20.7
xen/bitmap: remove redundant deviations
automation/eclair_analysis/ECLAIR/deviations.ecl | 4
Remove comment-based deviations since a project wide deviation that
cover such cases is present.
Signed-off-by: Federico Serafini
---
Changes from v1:
- split modifications in two patches.
---
xen/include/xen/bitmap.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/xen/include/xen/bitmap.h
When running as a Xen PV dom0 the system needs to map ACPI data of the
host using host physical addresses, while those addresses can conflict
with the guest physical addresses of the loaded linux kernel. The same
problem might apply in case a PV guest is configured to use the host
memory map.
This
flight 187614 xen-unstable real [real]
flight 187639 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187614/
http://logs.test-lab.xenproject.org/osstest/logs/187639/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armh
Instead of having max_pfn as a local variable of xen_memory_setup(),
make it a static variable in setup.c instead. This avoids having to
pass it to subfunctions, which will be needed in more cases in future.
Rename it to ini_nr_pages, as the value denotes the currently usable
number of memory page
When running as a Xen PV dom0 the kernel is loaded by the hypervisor
using a different memory map than that of the host. In order to
minimize the required changes in the kernel, the kernel adapts its
memory map to that of the host. In order to do that it is checking
for conflicts of its load addres
1 - 100 of 154 matches
Mail list logo
