The only functions to modify the list, amd_iommu_detect_one_acpi() and
amd_iommu_init_cleanup(), are already init.
Signed-off-by: Roger Pau Monné
---
xen/drivers/passthrough/amd/iommu_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/drivers/passthrough/amd/iommu_ini
Returning a literal number is a bad idea anyway when all other returns
use IOREQ_STATUS_* values. The function is dead on Arm, and mapping to
X86EMUL_OKAY is surely wrong on x86.
Fixes: f6bf39f84f82 ("x86/hvm: add support for broadcast of buffered ioreqs...")
Signed-off-by: Jan Beulich
---
Should
On 30.09.2024 12:28, Roger Pau Monne wrote:
> The only functions to modify the list, amd_iommu_detect_one_acpi() and
> amd_iommu_init_cleanup(), are already init.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
Surely the same can be said for VT-d's acpi_*_units? And likely other
glob
On 23/09/2024 12:05, Michal Orzel wrote:
Hi Julien,
Hi Michal,
On 20/09/2024 10:29, Julien Grall wrote:
Hi Michal,
On 19/09/2024 12:42, Michal Orzel wrote:
Attempt to attach an overlay (xl dt-overlay attach) to a domain without
first adding this overlay to Xen (xl dt-overlay add) resu
On Mon, Sep 30, 2024 at 9:58 AM Jan Beulich wrote:
>
> On 12.09.2024 03:13, Stefano Stabellini wrote:
> > Hi Jan, we have gone back and forth on this a few times, but neither
> > Alessandro nor I fully understand your perspective. To help streamline
> > the process and save time for everyone, I su
On 12.09.2024 03:13, Stefano Stabellini wrote:
> Hi Jan, we have gone back and forth on this a few times, but neither
> Alessandro nor I fully understand your perspective. To help streamline
> the process and save time for everyone, I suggest you provide an example
> of the rules written in the sty
On 30.09.2024 11:12, Frediano Ziglio wrote:
> On Mon, Sep 30, 2024 at 9:58 AM Jan Beulich wrote:
>>
>> On 12.09.2024 03:13, Stefano Stabellini wrote:
>>> Hi Jan, we have gone back and forth on this a few times, but neither
>>> Alessandro nor I fully understand your perspective. To help streamline
On 30.09.2024 10:14, oleksii.kuroc...@gmail.com wrote:
> On Mon, 2024-09-30 at 09:27 +0200, Jan Beulich wrote:
>> On 27.09.2024 18:33, Oleksii Kurochko wrote:
>>> Current patch series introduces device tree mapping for RISC-V
>>> and necessary things for that such as:
>>> - Fixmap mapping
>>> - pma
On Mon, 2024-09-30 at 10:17 +0200, Jan Beulich wrote:
> On 27.09.2024 18:33, Oleksii Kurochko wrote:
> > Current patch series introduces device tree mapping for RISC-V
> > and necessary things for that such as:
> > - Fixmap mapping
> > - pmap
> > - Xen page table processing
>
> While nothing is be
On 30.09.2024 10:24, oleksii.kuroc...@gmail.com wrote:
> On Mon, 2024-09-30 at 10:17 +0200, Jan Beulich wrote:
>> On 27.09.2024 18:33, Oleksii Kurochko wrote:
>>> Current patch series introduces device tree mapping for RISC-V
>>> and necessary things for that such as:
>>> - Fixmap mapping
>>> - pma
Missed to add revision log:
---
Changes in V8:
- drop PTE_LEAF_MASK.
- update the comment above pte_is_table(): drop table number and use
just "the encoding of the permission bits".
- declare pte_is_table() as static.
- drop const from the argument of pte_is_table
- drop the "const" commen
Add missing revision log:
---
Changes in V6-V8:
- Nothing changed. Only rebase.
---
Changes in V5:
- drop usage of PTE_BLOCK for flag argument of map_pages_to_xen() in
early_fdt_map()
as block mapping is now default behaviour. Also PTE_BLOCK was
dropped in the patch
"xen/riscv: page table
On Mon, 2024-09-30 at 10:32 +0200, Jan Beulich wrote:
> On 30.09.2024 10:24, oleksii.kuroc...@gmail.com wrote:
> > On Mon, 2024-09-30 at 10:17 +0200, Jan Beulich wrote:
> > > On 27.09.2024 18:33, Oleksii Kurochko wrote:
> > > > Current patch series introduces device tree mapping for RISC-V
> > > >
On Mon, 2024-09-30 at 09:27 +0200, Jan Beulich wrote:
> On 27.09.2024 18:33, Oleksii Kurochko wrote:
> > Current patch series introduces device tree mapping for RISC-V
> > and necessary things for that such as:
> > - Fixmap mapping
> > - pmap
> > - Xen page table processing
> >
> > ---
> > Changes
On 27.09.2024 18:33, Oleksii Kurochko wrote:
> Current patch series introduces device tree mapping for RISC-V
> and necessary things for that such as:
> - Fixmap mapping
> - pmap
> - Xen page table processing
While nothing is being said here towards a dependency, ...
> ---
> Changes in v8:
> - T
On Mon, 2024-09-30 at 09:20 +0200, Jan Beulich wrote:
> On 27.09.2024 18:32, Oleksii Kurochko wrote:
> > --- a/xen/arch/x86/xen.lds.S
> > +++ b/xen/arch/x86/xen.lds.S
> > @@ -3,6 +3,10 @@
> >
> > #include
> > #include
> > +
> > +#ifndef EFI
> > +# define DECL_SECTION_WITH_LADDR
> > +#endif
>
From: Ard Biesheuvel
The .head.text section contains code that may execute from a different
address than it was linked at. This is fragile, given that the x86 ABI
can refer to global symbols via absolute or relative references, and the
toolchain assumes that these are interchangeable, which they
From: Ard Biesheuvel
This series was broken out of the series I sent last week [0], after
Jason pointed out that my Xen startup code changes conflict with his
changes to make the PVH startup code position independent.
Jason's work reduces the delta of my changes, and given that my other
series w
On 26.09.2024 14:36, Andrew Cooper wrote:
> On 26/09/2024 10:58 am, Sergiy Kibrik wrote:
>> diff --git a/xen/common/Makefile b/xen/common/Makefile
>> index fc52e0857d..ea0557aee5 100644
>> --- a/xen/common/Makefile
>> +++ b/xen/common/Makefile
>> @@ -64,10 +64,14 @@ obj-bin-$(CONFIG_X86) += $(forea
From: Ard Biesheuvel
The limit field in a GDT descriptor is an inclusive bound, and therefore
one less than the size of the covered range.
Reviewed-by: Jason Andryuk
Tested-by: Jason Andryuk
Signed-off-by: Ard Biesheuvel
---
arch/x86/platform/pvh/head.S | 2 +-
1 file changed, 1 insertion(+)
From: Ard Biesheuvel
Calling C code via a different mapping than it was linked at is
problematic, because the compiler assumes that RIP-relative and absolute
symbol references are interchangeable. GCC in particular may use
RIP-relative per-CPU variable references even when not using -fpic.
So ca
On 30.09.2024 05:42, Jiqian Chen wrote:
> Some domains are not aware of the pIRQ abstraction layer that maps
> interrupt sources into Xen space interrupt numbers. pIRQs values are
> only exposed to domains that have the option to route physical
> interrupts over event channels.
>
> This creates i
On 27.09.2024 18:32, Oleksii Kurochko wrote:
> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -3,6 +3,10 @@
>
> #include
> #include
> +
> +#ifndef EFI
> +# define DECL_SECTION_WITH_LADDR
> +#endif
I think either this wants inserting at the very top or it wants moving down
t
From: Ard Biesheuvel
Xen puts virtual and physical addresses into ELF notes that are treated
by the linker as relocatable by default. Doing so is not only pointless,
given that the ELF notes are only intended for consumption by Xen before
the kernel boots. It is also a KASLR leak, given that the
From: Ard Biesheuvel
Since commit
d9ec1158056b ("x86/boot/64: Use RIP_REL_REF() to assign 'phys_base'")
phys_base is assigned directly rather than added to, so it is no longer
necessary to clear it after use.
Reviewed-by: Jason Andryuk
Tested-by: Jason Andryuk
Signed-off-by: Ard Biesheuvel
On 27.09.2024 18:33, Oleksii Kurochko wrote:
> Introduce struct pcpu_info to store pCPU-related information.
> Initially, it includes only processor_id and hart id, but it
> will be extended to include guest CPU information and
> temporary variables for saving/restoring vCPU registers.
>
> Add set
On 27.09.2024 18:33, Oleksii Kurochko wrote:
> Current patch series introduces device tree mapping for RISC-V
> and necessary things for that such as:
> - Fixmap mapping
> - pmap
> - Xen page table processing
>
> ---
> Changes in v8:
> - The following patch was merged to staging:
> [PATCH v5
On 26.09.2024 12:26, Sergiy Kibrik wrote:
> Xen's implementation of PSR only supports Intel CPUs right now, hence it can
> be
> made dependant on CONFIG_INTEL build option.
> Since platform implementation is not limited to single vendor, intermediate
> option CONFIG_X86_PSR introduced, which selec
On 30.09.24 11:06, Lukas Bulwahn wrote:
From: Lukas Bulwahn
Commit 2fae6bb7be32 ("xen/privcmd: Add new syscall to get gsi from dev")
adds a weak reverse dependency to the config XEN_PRIVCMD definition,
referring to CONFIG_XEN_PCIDEV_BACKEND. In Kconfig files, one refers to
config options withou
On 23/09/2024 11:44, Michal Orzel wrote:
Hi Julien,
On 20/09/2024 10:35, Julien Grall wrote:
Hi Michal,
On 19/09/2024 12:42, Michal Orzel wrote:
The assumption stated in the comment that the code will never get there
is incorrect. It's enough for the target-path to be incorrect (i.e. use
From: Lukas Bulwahn
Commit 2fae6bb7be32 ("xen/privcmd: Add new syscall to get gsi from dev")
adds a weak reverse dependency to the config XEN_PRIVCMD definition,
referring to CONFIG_XEN_PCIDEV_BACKEND. In Kconfig files, one refers to
config options without the CONFIG prefix, though. So in its cur
guest_handle_ok()'s expansion contains a sizeof() involving its
first argument which is guest_handle_cast().
The expansion of the latter, in turn, contains a variable
initialization.
Since MISRA considers the initialization (even of a local variable)
a side effect, the chain of expansions mentione
guest_handle_ok()'s expansion contains a sizeof() involving its
first argument guest_handle_cast().
The expansion of the latter, in turn, contains a variable
initialization.
Since MISRA considers the initialization (even of a local variable)
a side effect, the chain of expansions mentioned above v
On 30.09.2024 14:06, Andrew Cooper wrote:
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -344,6 +344,66 @@ __efi64_mb2_start:
> lea .Lmb2_no_ih(%rip),%r15
> jz x86_32_switch
>
> +push%rax
> +push%rcx
> +push%rd
Update ECLAIR configuration to consider Rule 13.6 as clean:
new 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_analysis/ECLAI
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/
flight 187906 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187906/
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 1
On 26.09.2024 18:54, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/x86/include/asm/percpu.h
> @@ -0,0 +1,14 @@
> +#ifndef __X86_PERCPU_H__
> +#define __X86_PERCPU_H__
> +
> +#define PARK_OFFLINE_CPUS
> +
> +/*
> + * Force uses of per_cpu() with an invalid area to attempt to access the
>
The switch statement in guest_io_okay() is a very expensive way of
pre-initialising x with ~0, and performing a partial read into it.
However, the logic isn't correct either.
In a real TSS, the CPU always reads two bytes (like here), and any TSS limit
violation turns silently into no-access. But
Needs to be used in combination with Jan's "x86/PV: simplify (and thus
correct) guest accessor functions" to provide correct behaviour. See patch 2.
Andrew Cooper (2):
x86/pv: Rework guest_io_okay() to return X86EMUL_*
x86/pv: Handle #PF correctly when reading the IO permission bitmap
xen/a
On 26/09/2024 6:59 pm, Andrew Cooper wrote:
> On 02/09/2024 4:09 pm, Jan Beulich wrote:
>> On 02.09.2024 16:13, Andrew Cooper wrote:
>>> On 02/09/2024 1:28 pm, Jan Beulich wrote:
Taking a fault on a non-byte-granular insn means that the "number of
bytes not handled" return value would nee
flight 187902 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187902/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 187896
test-amd64-amd64-xl-qemuu-win7-amd64
If available, its use is supposed to be cheaper than LFENCE+RDTSC, and
is virtually guaranteed to be cheaper than MFENCE+RDTSC.
Unlike in rdtsc() use 64-bit local variables, eliminating the need for
the compiler to emit a zero-extension insn for %eax (that's a cheap MOV,
yet still pointless to hav
Implement the virt_to_maddr() function to convert virtual addresses
to machine addresses, including checks for address ranges such as
the direct mapping area (DIRECTMAP_VIRT_START) and the Xen virtual
address space. To implement this, the phys_offset variable is made
accessible outside of riscv/mm.
This patch series registers Xen's load address as a boot module and
introduce virt_to_maddr(), and drops LINK_TO_LOAD() to use virt_to_maddr()
instead.
This patch series is based on the patch series: "device tree mapping" [1]
[1]
https://lore.kernel.org/xen-devel/c1426b095aafcb3492edb679195342c4
Avoid using BOOTMOD_XEN region for other purposes or boot modules
which could result in memory corruption or undefined behaviour.
Signed-off-by: Oleksii Kurochko
---
xen/arch/riscv/setup.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/set
Except for switching LINK_TO_LOAD() to virt_to_maddr(),
LINK_TO_LOAD() is dropped, as virt_to_maddr() covers all
the cases where LINK_TO_LOAD() is used.
Signed-off-by: Oleksii Kurochko
---
xen/arch/riscv/mm.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/xen/arch/ris
There's no point using alternative_io() when there are no outputs.
No functional change.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -286,11 +286,10 @@ void cache_flush(const void *addr, unsig
* + prefix than a clflush + nop, and hence the
Parse DTB during startup, allowing memory banks and reserved
memory regions to be set up, along with early device tree node
( chosen, "xen,domain", "reserved-memory", etc ) handling.
Signed-off-by: Oleksii Kurochko
---
xen/arch/riscv/setup.c | 4
1 file changed, 4 insertions(+)
diff --git
Receive Xen's command line passed by DTB using boot_fdt_cmdline()
and passed it to cmdline_parse() for further procesinng and setup
of Xen-specific parameters.
Signed-off-by: Oleksii Kurochko
---
xen/arch/riscv/setup.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/xen/arch/riscv/setup
This patch series initializes bootinfo from dtb and then parse and
handle command line from dtb.
This patch series is based on the patch series:
"Register Xen's load address as a boot module" [1]
[1]
https://lore.kernel.org/xen-devel/cover.1727708665.git.oleksii.kuroc...@gmail.com/T/#t
Oleksi
On 27.09.2024 00:24, Shawn Anastasio wrote:
> In the initial mm-radix implementation, the in-memory partition and
> process tables required to configure the MMU, as well as the page tables
> themselves were all allocated statically since the boot allocator was
> not yet available.
>
> Now that it
On 30/09/2024 4:09 pm, Jan Beulich wrote:
> There's no point using alternative_io() when there are no outputs.
>
> No functional change.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/flushtlb.c
> +++ b/xen/arch/x86/flushtlb.c
> @@ -286,11 +286,10 @@ void cache_flush(const void *addr, unsig
On 27.09.2024 18:33, Oleksii Kurochko wrote:
> +static bool pt_check_entry(pte_t entry, mfn_t mfn, unsigned int flags)
> +{
> +/* Sanity check when modifying an entry. */
> +if ( (flags & PTE_VALID) && mfn_eq(mfn, INVALID_MFN) )
> +{
> +/* We don't allow modifying an invalid ent
On 30/09/2024 4:15 pm, Jan Beulich wrote:
> To fold two 32-bit outputs from the asm()-s into a single 64-bit value
> the compiler needs to emit a zero-extension insn for the low half. Both
> RDMSR and RDTSC clear the upper halves of their output registers anyway,
> though. So despite that zero-exte
On 30.09.2024 17:27, Andrew Cooper wrote:
> On 30/09/2024 4:09 pm, Jan Beulich wrote:
>> There's no point using alternative_io() when there are no outputs.
>>
>> No functional change.
>>
>> Signed-off-by: Jan Beulich
>>
>> --- a/xen/arch/x86/flushtlb.c
>> +++ b/xen/arch/x86/flushtlb.c
>> @@ -286,1
On 30/09/2024 4:39 pm, Jan Beulich wrote:
> On 30.09.2024 17:27, Andrew Cooper wrote:
>> On 30/09/2024 4:09 pm, Jan Beulich wrote:
>>> There's no point using alternative_io() when there are no outputs.
>>>
>>> No functional change.
>>>
>>> Signed-off-by: Jan Beulich
>>>
>>> --- a/xen/arch/x86/flus
On Mon, 2024-09-30 at 15:25 +0200, Jan Beulich wrote:
> On 26.09.2024 18:54, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/arch/x86/include/asm/percpu.h
> > @@ -0,0 +1,14 @@
> > +#ifndef __X86_PERCPU_H__
> > +#define __X86_PERCPU_H__
> > +
> > +#define PARK_OFFLINE_CPUS
> > +
> > +/*
> >
On 26.09.2024 11:21, Frediano Ziglio wrote:
> @@ -243,7 +234,7 @@ __efi64_mb2_start:
> /*
> * Initialize BSS (no nasty surprises!).
> * It must be done earlier than in BIOS case
> - * because efi_multiboot2() touches it.
> + * because efi_multiboot2_prel
On 26.09.2024 11:21, Frediano Ziglio wrote:
> --- a/xen/arch/x86/efi/parse-mbi2.c
> +++ b/xen/arch/x86/efi/parse-mbi2.c
> @@ -13,6 +13,7 @@ efi_multiboot2_prelude(uint32_t magic, const
> multiboot2_fixed_t *mbi)
> EFI_HANDLE ImageHandle = NULL;
> EFI_SYSTEM_TABLE *SystemTable = NULL;
>
On Mon, 2024-09-30 at 17:50 +0200, oleksii.kuroc...@gmail.com wrote:
> On Mon, 2024-09-30 at 15:25 +0200, Jan Beulich wrote:
> > On 26.09.2024 18:54, Oleksii Kurochko wrote:
> > > --- /dev/null
> > > +++ b/xen/arch/x86/include/asm/percpu.h
> > > @@ -0,0 +1,14 @@
> > > +#ifndef __X86_PERCPU_H__
> >
On 30.09.2024 17:56, oleksii.kuroc...@gmail.com wrote:
> On Mon, 2024-09-30 at 17:50 +0200, oleksii.kuroc...@gmail.com wrote:
>> On Mon, 2024-09-30 at 15:25 +0200, Jan Beulich wrote:
>>> On 26.09.2024 18:54, Oleksii Kurochko wrote:
--- /dev/null
+++ b/xen/arch/x86/include/asm/percpu.h
>>>
On 30.09.2024 13:03, Sergiy Kibrik wrote:
> 27.09.24 12:44, Jan Beulich:
> (probably with X86_PMTIMER option depending on PV)
HVM you mean?
>>> I wanted to do it like this:
>>>
>>> --- a/xen/arch/x86/Kconfig
>>> +++ b/xen/arch/x86/Kconfig
>>> @@ -386,7 +386,7 @@ config ALTP2M
>>>
1: x86emul: support LKGS
2: x86emul+VMX: support {RD,WR}MSRLIST
3: x86emul: support USER_MSR instructions
4: x86/cpu-policy: re-arrange no-VMX logic
5: VMX: support USER_MSR
Jan
These are "compound" instructions to issue a series of RDMSR / WRMSR
respectively. In the emulator we can therefore implement them by using
the existing msr_{read,write}() hooks. The memory accesses utilize that
the HVM ->read() / ->write() hooks are already linear-address
(x86_seg_none) aware (by
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
Introduce the SCMI layer to have some basic degree of awareness
about SMC calls that are based on the ARM System Control and
Management Interface (SCMI) specification (DEN0056E).
The SCMI specification includes various protocols for managing
system-level resources, such a
From: Andrei Cherechesu
Add code for NXP S32CC platforms (S32G2, S32G3, S32R45).
S32CC platforms use the NXP LINFlexD UART driver for
console by default, and rely on Dom0 having access to
SCMI services for system-level resources from firmware
at EL3.
Platform-related quirks will be addressed in
In order to fix a bug with guest_io_okay() (subsequent patch), rework
guest_io_okay() to take in an emulation context, and return X86EMUL_* rather
than a boolean.
For the failing case, take the opporunity to inject #GP explicitly, rather
than returning X86EMUL_UNHANDLEABLE. There is a logical dif
Centralize per-cpu area management to reduce code duplication and
enhance maintainability across architectures.
The per-cpu area management code, which is largely common among
architectures, is moved to a shared implementation in
xen/common/percpu.c. This change includes:
* Remove percpu.c from t
On 30/09/2024 4:08 pm, Jan Beulich wrote:
> If available, its use is supposed to be cheaper than LFENCE+RDTSC, and
> is virtually guaranteed to be cheaper than MFENCE+RDTSC.
>
> Unlike in rdtsc() use 64-bit local variables, eliminating the need for
I'd drop this reference to rdtsc() seeing as you
27.09.24 12:44, Jan Beulich:
(probably with X86_PMTIMER option depending on PV)
HVM you mean?
I wanted to do it like this:
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -386,7 +386,7 @@ config ALTP2M
If unsure, stay with defaults.
config X86_PMTIMER
- bool "AC
Hi,
On 25/09/2024 14:22, Ayan Kumar Halder wrote:
On 24/09/2024 18:10, Julien Grall wrote:
On 24/09/2024 12:32, Ayan Kumar Halder wrote:
On 19/09/2024 14:16, Julien Grall wrote:
On 18/09/2024 19:51, Ayan Kumar Halder wrote:
Define enable_boot_cpu_mm() for the AArch64-V8R system.
Like boot
flight 187899 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187899/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-multivcpu 8 xen-boot fail pass in 187892
test-amd64-amd64-xl-qemuu-dmrest
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
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
Acked-by: Julien Grall
---
xen/arch/arm/Kconfig.debug | 12 ++
xen/arch/arm/arm64/debug-linflex.inc | 58 +++
From: Andrei Cherechesu
Add myself as maintainer for NXP S32CC SoCs Family,
and the S32 Linux Team as relevant reviewers list.
Also add the linflex-uart.c driver to the list of other
UART drivers in the ARM section.
Signed-off-by: Andrei Cherechesu
---
MAINTAINERS | 8
1 file changed
From: Andrei Cherechesu
Describe the layer which enables SCMI over SMC calls forwarding
to EL3 FW if issued by Dom0. If the SCMI firmware node is not
found in Dom0's DT during initialization, it fails silently
as it's not mandatory.
The SCMI SMCs trapping at EL2 now lets Dom0 perform SCMI ops fo
From: Andrei Cherechesu
Change the handling of SiP SMC calls to be more generic,
instead of directly relying on the `platform_smc()` callback
implementation.
Try to handle the SiP SMC first through the `platform_smc()`
callback (if implemented). If not handled, check if the
SCMI layer is availab
From: Andrei Cherechesu
Signed-off-by: Andrei Cherechesu
---
CHANGELOG.md | 4
1 file changed, 4 insertions(+)
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 26e7d8dd2a..66ea505843 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -11,6 +11,10 @@ The format is based on [Keep a
Changelog](h
On 30.09.2024 13:47, Andrei Cherechesu (OSS) wrote:
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -11,6 +11,10 @@ The format is based on [Keep a
> Changelog](https://keepachangelog.com/en/1.0.0/)
> - Prefer ACPI reboot over UEFI ResetSystem() run time service call.
>
> ### Added
> + - On
While UWRMSR probably isn't of much use as long as we don't support
UINTR, URDMSR may well be useful to guests even without that (depending
on what OSes are willing to permit access to).
Since the two VEX encodings introduce a lonely opcode point in map 7,
for now don't bother introducing a full 2
Move the PKS check into an "else" for the corresponding "if()", such
that further adjustments (like for USER_MSR) can easily be put there as
well.
Signed-off-by: Jan Beulich
---
v5: Re-base.
v4: New.
--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -744,19 +744,20 @@ static voi
Hook up the new VM exit codes and handle guest accesses, context switch,
and save/restore. At least for now don't allow the guest direct access
to the control MSR; this may need changing if guests were to frequently
access it (e.g. on their own context switch path).
While there also correct a one-
flight 187905 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187905/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a6b472131e6f49ec6ec309a06fed3b70b97a8602
baseline version:
ovmf 21e1fc5400c0d916ef902
On 30/09/2024 12:27 pm, Jan Beulich wrote:
> On 30.09.2024 13:03, Sergiy Kibrik wrote:
>> 27.09.24 12:44, Jan Beulich:
>> (probably with X86_PMTIMER option depending on PV)
> HVM you mean?
>
I wanted to do it like this:
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/K
Provide support for this insn, which is a prereq to FRED. CPUID-wise
introduce both its, FRED's, and the NMI_SRC bit at this occasion, thus
allowing to also express the dependency right away.
While adding a testcase, also add a SWAPGS one. In order to not affect
the behavior of pre-existing tests,
flight 187907 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187907/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 517019a55302b1222c152ee05226d55883050642
baseline version:
ovmf a6b472131e6f49ec6ec30
On 30.09.2024 14:49, Federico Serafini wrote:
> guest_handle_ok()'s expansion contains a sizeof() involving its
> first argument which is guest_handle_cast().
> The expansion of the latter, in turn, contains a variable
> initialization.
>
> Since MISRA considers the initialization (even of a local
On Mon, Sep 30, 2024 at 1:06 PM Andrew Cooper wrote:
>
> When entering via MB2+EFI, the early EFI code hasn't been relocated down to
> it's load address. As a consequence, efi_multboot2() is still expecting to
> run at high address.
>
> To set this up, we need Xen's high mappings, while also reta
On Mon, Sep 30, 2024 at 12:33:56PM +0200, Jan Beulich wrote:
> On 30.09.2024 12:28, Roger Pau Monne wrote:
> > The only functions to modify the list, amd_iommu_detect_one_acpi() and
> > amd_iommu_init_cleanup(), are already init.
> >
> > Signed-off-by: Roger Pau Monné
>
> Acked-by: Jan Beulich
flight 187908 xen-unstable real [real]
flight 187915 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187908/
http://logs.test-lab.xenproject.org/osstest/logs/187915/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm6
On 2024-09-30 15:07, Jan Beulich wrote:
On 30.09.2024 14:49, Federico Serafini wrote:
guest_handle_ok()'s expansion contains a sizeof() involving its
first argument which is guest_handle_cast().
The expansion of the latter, in turn, contains a variable
initialization.
Since MISRA considers the
On Wed, Sep 25, 2024 at 05:01:04PM +0200, Ard Biesheuvel wrote:
> + if (r_type == R_X86_64_GOTPCREL) {
> + Elf_Shdr *s = &secs[sec->shdr.sh_info].shdr;
> + unsigned file_off = offset - s->sh_addr + s->sh_offset;
> +
> + /*
> +
When entering via MB2+EFI, the early EFI code hasn't been relocated down to
it's load address. As a consequence, efi_multboot2() is still expecting to
run at high address.
To set this up, we need Xen's high mappings, while also retaining the EFI
physical-mode mappings in the low half. Introduce
On Mon, 2024-09-30 at 14:53 +0200, Jan Beulich wrote:
> On 30.09.2024 13:47, Andrei Cherechesu (OSS) wrote:
> > --- a/CHANGELOG.md
> > +++ b/CHANGELOG.md
> > @@ -11,6 +11,10 @@ The format is based on [Keep a
> > Changelog](https://keepachangelog.com/en/1.0.0/)
> > - Prefer ACPI reboot over UEFI
Hi Julien,
On 30/09/2024 12:37, Julien Grall wrote:
>
>
> On 23/09/2024 12:05, Michal Orzel wrote:
>> Hi Julien,
>
> Hi Michal,
>
>> On 20/09/2024 10:29, Julien Grall wrote:
>>>
>>>
>>> Hi Michal,
>>>
>>> On 19/09/2024 12:42, Michal Orzel wrote:
Attempt to attach an overlay (xl dt-overlay
To fold two 32-bit outputs from the asm()-s into a single 64-bit value
the compiler needs to emit a zero-extension insn for the low half. Both
RDMSR and RDTSC clear the upper halves of their output registers anyway,
though. So despite that zero-extending insn (a simple MOV) being cheap,
we can do b
flight 187914 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187914/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 4f4673846fc9d6fc1c10a6c025da4739d872a6a0
baseline version:
ovmf c95233b8525ca6828921a
flight 187909 linux-6.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187909/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 187749
test-amd64-amd64-xl-qemuu-win7-amd64 19
1 - 100 of 114 matches
Mail list logo
