[PATCH stable/3.0.x 1/2] x86: cobalt/switchtest: Fix testing issue due to uninitialized FPU
On x86 fp_regs_set() expects that the FPU state was initialized by
calling the fninit instruction. When running in kernel space in task
context there is no guarantee that the FPU was initialized. Under
heavy load / scheduling the test might fail and report a FPU
register corruption.
The new introduced fp_init() takes care of the FPU initialization. We
call it before fp_regs_set() in task context and re-use it for the kernel
context as well.
Signed-off-by: Florian Bezdeka
---
kernel/cobalt/arch/arm/include/asm/xenomai/fptest.h | 4
kernel/cobalt/arch/blackfin/include/asm/xenomai/fptest.h | 4
kernel/cobalt/arch/powerpc/include/asm/xenomai/fptest.h | 4
kernel/cobalt/arch/x86/include/asm/xenomai/fptest.h | 7 ++-
kernel/drivers/testing/switchtest.c | 4 +++-
5 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/kernel/cobalt/arch/arm/include/asm/xenomai/fptest.h
b/kernel/cobalt/arch/arm/include/asm/xenomai/fptest.h
index a76f1e6bb..d100baad4 100644
--- a/kernel/cobalt/arch/arm/include/asm/xenomai/fptest.h
+++ b/kernel/cobalt/arch/arm/include/asm/xenomai/fptest.h
@@ -35,6 +35,10 @@ static inline int fp_kernel_supported(void)
return 1;
}
+static inline void fp_init(void)
+{
+}
+
static inline int fp_linux_begin(void)
{
return -ENOSYS;
diff --git a/kernel/cobalt/arch/blackfin/include/asm/xenomai/fptest.h
b/kernel/cobalt/arch/blackfin/include/asm/xenomai/fptest.h
index 904ce83fb..ffa057a81 100644
--- a/kernel/cobalt/arch/blackfin/include/asm/xenomai/fptest.h
+++ b/kernel/cobalt/arch/blackfin/include/asm/xenomai/fptest.h
@@ -27,6 +27,10 @@ static inline int fp_kernel_supported(void)
return 0;
}
+static inline void fp_init(void)
+{
+}
+
static inline int fp_linux_begin(void)
{
return -ENOSYS;
diff --git a/kernel/cobalt/arch/powerpc/include/asm/xenomai/fptest.h
b/kernel/cobalt/arch/powerpc/include/asm/xenomai/fptest.h
index e09ca2c3b..a9d93fe87 100644
--- a/kernel/cobalt/arch/powerpc/include/asm/xenomai/fptest.h
+++ b/kernel/cobalt/arch/powerpc/include/asm/xenomai/fptest.h
@@ -41,6 +41,10 @@ static inline int fp_kernel_supported(void)
#endif /* !CONFIG_PPC_FPU */
}
+static inline void fp_init(void)
+{
+}
+
static inline int fp_linux_begin(void)
{
return -ENOSYS;
diff --git a/kernel/cobalt/arch/x86/include/asm/xenomai/fptest.h
b/kernel/cobalt/arch/x86/include/asm/xenomai/fptest.h
index f0ecd00e9..ccf7afa11 100644
--- a/kernel/cobalt/arch/x86/include/asm/xenomai/fptest.h
+++ b/kernel/cobalt/arch/x86/include/asm/xenomai/fptest.h
@@ -29,6 +29,11 @@ static inline int fp_kernel_supported(void)
return 1;
}
+static inline void fp_init(void)
+{
+ __asm__ __volatile__("fninit");
+}
+
static inline int fp_linux_begin(void)
{
#if defined(CONFIG_X86_USE_3DNOW) \
@@ -48,7 +53,7 @@ static inline int fp_linux_begin(void)
/* kernel_fpu_begin() does no re-initialize the fpu context, but
fp_regs_set() implicitely expects an initialized fpu context, so
initialize it here. */
- __asm__ __volatile__("fninit");
+ fp_init();
return 0;
}
diff --git a/kernel/drivers/testing/switchtest.c
b/kernel/drivers/testing/switchtest.c
index 08b64820a..84eb586c7 100644
--- a/kernel/drivers/testing/switchtest.c
+++ b/kernel/drivers/testing/switchtest.c
@@ -416,8 +416,10 @@ static void rtswitch_ktask(void *cookie)
rtswitch_pend_rt(ctx, task->base.index);
while (!rtdm_task_should_stop()) {
- if (task->base.flags & RTTST_SWTEST_USE_FPU)
+ if (task->base.flags & RTTST_SWTEST_USE_FPU) {
+ fp_init();
fp_regs_set(fp_features, task->base.index + i * 1000);
+ }
switch(i % 3) {
case 0:
--
2.30.2
[PATCH stable/3.0.x 0/2] Backport FPU testing cleanup to 3.0.x
Hi all, this is the backport of the previously published FPU testing cleanup series to the stable/3.0.x branch. Patch 1 has been updated to match the supported architectures in the 3.0.x stable branch, Patch 2 is unmodified. Best regards, Florian Florian Bezdeka (2): x86: cobalt/switchtest: Fix testing issue due to uninitialized FPU x86: cobalt/switchtest: Enable FPU tests unconditionally .../arch/arm/include/asm/xenomai/fptest.h | 4 .../blackfin/include/asm/xenomai/fptest.h | 4 .../arch/powerpc/include/asm/xenomai/fptest.h | 4 .../arch/x86/include/asm/xenomai/fptest.h | 20 ++- kernel/drivers/testing/switchtest.c | 4 +++- 5 files changed, 21 insertions(+), 15 deletions(-) -- 2.30.2
[PATCH stable/3.1.x 2/2] x86: cobalt/switchtest: Enable FPU tests unconditionally
Parts of the FPU tests were skipped when one of the following config
options was enabled, shadowing a real test issue that was triggered by
high load on the system. The options:
- CONFIG_X86_USE_3DNOW
- CONFIG_MD_RAID456
- CONFIG_MD_RAID456_MODULE
As the FPU initialization is fixed now, we can enable the tests
unconditionally.
Signed-off-by: Florian Bezdeka
---
kernel/cobalt/arch/x86/include/asm/xenomai/fptest.h | 13 -
1 file changed, 13 deletions(-)
diff --git a/kernel/cobalt/arch/x86/include/asm/xenomai/fptest.h
b/kernel/cobalt/arch/x86/include/asm/xenomai/fptest.h
index ccf7afa11..7a2b17d75 100644
--- a/kernel/cobalt/arch/x86/include/asm/xenomai/fptest.h
+++ b/kernel/cobalt/arch/x86/include/asm/xenomai/fptest.h
@@ -36,19 +36,6 @@ static inline void fp_init(void)
static inline int fp_linux_begin(void)
{
-#if defined(CONFIG_X86_USE_3DNOW) \
- || defined(CONFIG_MD_RAID456) || defined(CONFIG_MD_RAID456_MODULE)
- /* Ther kernel uses x86 FPU, we can not also use it in our tests. */
- static int once = 0;
- if (!once) {
- once = 1;
- printk("%s:%d: Warning: Linux is compiled to use FPU in "
- "kernel-space.\nFor this reason, switchtest can not "
- "test using FPU in Linux kernel-space.\n",
- __FILE__, __LINE__);
- }
- return -EBUSY;
-#endif /* 3DNow or RAID 456 */
kernel_fpu_begin();
/* kernel_fpu_begin() does no re-initialize the fpu context, but
fp_regs_set() implicitely expects an initialized fpu context, so
--
2.30.2
[PATCH stable/3.1.x 0/2] Backport FPU testing cleanup to 3.1.x
Hi all, this is the backport of the previously published FPU testing cleanup series to the stable/3.1.x branch. Patch 1 has been updated to match the supported architectures in the 3.1.x stable branch, Patch 2 is unmodified. Best regards, Florian Florian Bezdeka (2): x86: cobalt/switchtest: Fix testing issue due to uninitialized FPU x86: cobalt/switchtest: Enable FPU tests unconditionally .../arch/arm/include/asm/xenomai/fptest.h | 4 .../arch/arm64/include/asm/xenomai/fptest.h | 4 .../arch/powerpc/include/asm/xenomai/fptest.h | 4 .../arch/x86/include/asm/xenomai/fptest.h | 20 ++- kernel/drivers/testing/switchtest.c | 4 +++- 5 files changed, 21 insertions(+), 15 deletions(-) -- 2.30.2
[PATCH stable/3.1.x 1/2] x86: cobalt/switchtest: Fix testing issue due to uninitialized FPU
On x86 fp_regs_set() expects that the FPU state was initialized by
calling the fninit instruction. When running in kernel space in task
context there is no guarantee that the FPU was initialized. Under
heavy load / scheduling the test might fail and report a FPU
register corruption.
The new introduced fp_init() takes care of the FPU initialization. We
call it before fp_regs_set() in task context and re-use it for the kernel
context as well.
Signed-off-by: Florian Bezdeka
---
kernel/cobalt/arch/arm/include/asm/xenomai/fptest.h | 4
kernel/cobalt/arch/arm64/include/asm/xenomai/fptest.h | 4
kernel/cobalt/arch/powerpc/include/asm/xenomai/fptest.h | 4
kernel/cobalt/arch/x86/include/asm/xenomai/fptest.h | 7 ++-
kernel/drivers/testing/switchtest.c | 4 +++-
5 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/kernel/cobalt/arch/arm/include/asm/xenomai/fptest.h
b/kernel/cobalt/arch/arm/include/asm/xenomai/fptest.h
index b8c627bed..d3f335f86 100644
--- a/kernel/cobalt/arch/arm/include/asm/xenomai/fptest.h
+++ b/kernel/cobalt/arch/arm/include/asm/xenomai/fptest.h
@@ -35,6 +35,10 @@ static inline int fp_kernel_supported(void)
return 1;
}
+static inline void fp_init(void)
+{
+}
+
static inline int fp_linux_begin(void)
{
return -ENOSYS;
diff --git a/kernel/cobalt/arch/arm64/include/asm/xenomai/fptest.h
b/kernel/cobalt/arch/arm64/include/asm/xenomai/fptest.h
index 291c9e5f0..39903a047 100644
--- a/kernel/cobalt/arch/arm64/include/asm/xenomai/fptest.h
+++ b/kernel/cobalt/arch/arm64/include/asm/xenomai/fptest.h
@@ -30,6 +30,10 @@ static inline int fp_kernel_supported(void)
return 0;
}
+static inline void fp_init(void)
+{
+}
+
static inline int fp_linux_begin(void)
{
return -ENOSYS;
diff --git a/kernel/cobalt/arch/powerpc/include/asm/xenomai/fptest.h
b/kernel/cobalt/arch/powerpc/include/asm/xenomai/fptest.h
index e09ca2c3b..a9d93fe87 100644
--- a/kernel/cobalt/arch/powerpc/include/asm/xenomai/fptest.h
+++ b/kernel/cobalt/arch/powerpc/include/asm/xenomai/fptest.h
@@ -41,6 +41,10 @@ static inline int fp_kernel_supported(void)
#endif /* !CONFIG_PPC_FPU */
}
+static inline void fp_init(void)
+{
+}
+
static inline int fp_linux_begin(void)
{
return -ENOSYS;
diff --git a/kernel/cobalt/arch/x86/include/asm/xenomai/fptest.h
b/kernel/cobalt/arch/x86/include/asm/xenomai/fptest.h
index f0ecd00e9..ccf7afa11 100644
--- a/kernel/cobalt/arch/x86/include/asm/xenomai/fptest.h
+++ b/kernel/cobalt/arch/x86/include/asm/xenomai/fptest.h
@@ -29,6 +29,11 @@ static inline int fp_kernel_supported(void)
return 1;
}
+static inline void fp_init(void)
+{
+ __asm__ __volatile__("fninit");
+}
+
static inline int fp_linux_begin(void)
{
#if defined(CONFIG_X86_USE_3DNOW) \
@@ -48,7 +53,7 @@ static inline int fp_linux_begin(void)
/* kernel_fpu_begin() does no re-initialize the fpu context, but
fp_regs_set() implicitely expects an initialized fpu context, so
initialize it here. */
- __asm__ __volatile__("fninit");
+ fp_init();
return 0;
}
diff --git a/kernel/drivers/testing/switchtest.c
b/kernel/drivers/testing/switchtest.c
index 6f8a9fcaa..f25745bac 100644
--- a/kernel/drivers/testing/switchtest.c
+++ b/kernel/drivers/testing/switchtest.c
@@ -416,8 +416,10 @@ static void rtswitch_ktask(void *cookie)
rtswitch_pend_rt(ctx, task->base.index);
while (!rtdm_task_should_stop()) {
- if (task->base.flags & RTTST_SWTEST_USE_FPU)
+ if (task->base.flags & RTTST_SWTEST_USE_FPU) {
+ fp_init();
fp_regs_set(fp_features, task->base.index + i * 1000);
+ }
switch(i % 3) {
case 0:
--
2.30.2
Re: SPI
Hi! Many thanks for your response, but unfortunately we're receiving the same error. I was already using the config file as suggested from the resource you provided, but still the compilation does not build the device trees RPi4 needs. So I compiled the official kernel source [1] (I tried with 5.15.45 [1] and .44 [2]) to have the correct overlays. Then, I installed the Xenomai modules and copied the Xenomai kernel. Still, I'm receiving the same error from my previous email and cannot enable the SPI. I noticed the same error after compiling [3], thinking it was the right .44 kernel for RPi4. I don't know if it can be helpful. Davide [1] https://github.com/raspberrypi/linux [2] https://github.com/raspberrypi/linux/tree/ea7fe1b21ea73146b1d49ac5f554fbd0ac5de9de , "Merge remote-tracking branch 'stable/linux-5.15.y' into rpi-5.15.y" [3] https://github.com/raspberrypi/linux/tree/4e67be407725b1d8b829ed2075987037abec98ec , "Linux 5.15.44" Il giorno gio 9 giu 2022 alle ore 13:50 Philippe Gerum ha scritto: > > > Davide Valeri writes: > > > Hi! > > We need your help once more. > > We cannot enable SPI in the built kernel. Neither "sudo raspi-config" > > nor manually editing "config.txt" worked. > > > > Using "raspi-config" results in > > "mount: /config/device-tree: mount point does not exist > > * Failed to mount configfs - 2" > > > > Commit linux-evl: 81e5b7be. > > > > We're using the bcm2711_defconfig provided by [1]. > > We tried the kernel from the repository in [1] and we were able to enable > > SPI. > > > > Do you experience something like this? > > > > Davide Valeri > > > > [1] > > https://github.com/raspberrypi/linux/blob/rpi-5.15.y/arch/arm64/configs/bcm2711_defconfig > > (commit: 9b573727) > > This is not an EVL issue. Google has a match for this it seems: > https://forums.gentoo.org/viewtopic-t-1104786-start-0.html > > -- > Philippe.
[PATCH stable/3.0.x 2/2] x86: cobalt/switchtest: Enable FPU tests unconditionally
Parts of the FPU tests were skipped when one of the following config
options was enabled, shadowing a real test issue that was triggered by
high load on the system. The options:
- CONFIG_X86_USE_3DNOW
- CONFIG_MD_RAID456
- CONFIG_MD_RAID456_MODULE
As the FPU initialization is fixed now, we can enable the tests
unconditionally.
Signed-off-by: Florian Bezdeka
---
kernel/cobalt/arch/x86/include/asm/xenomai/fptest.h | 13 -
1 file changed, 13 deletions(-)
diff --git a/kernel/cobalt/arch/x86/include/asm/xenomai/fptest.h
b/kernel/cobalt/arch/x86/include/asm/xenomai/fptest.h
index ccf7afa11..7a2b17d75 100644
--- a/kernel/cobalt/arch/x86/include/asm/xenomai/fptest.h
+++ b/kernel/cobalt/arch/x86/include/asm/xenomai/fptest.h
@@ -36,19 +36,6 @@ static inline void fp_init(void)
static inline int fp_linux_begin(void)
{
-#if defined(CONFIG_X86_USE_3DNOW) \
- || defined(CONFIG_MD_RAID456) || defined(CONFIG_MD_RAID456_MODULE)
- /* Ther kernel uses x86 FPU, we can not also use it in our tests. */
- static int once = 0;
- if (!once) {
- once = 1;
- printk("%s:%d: Warning: Linux is compiled to use FPU in "
- "kernel-space.\nFor this reason, switchtest can not "
- "test using FPU in Linux kernel-space.\n",
- __FILE__, __LINE__);
- }
- return -EBUSY;
-#endif /* 3DNow or RAID 456 */
kernel_fpu_begin();
/* kernel_fpu_begin() does no re-initialize the fpu context, but
fp_regs_set() implicitely expects an initialized fpu context, so
--
2.30.2
Re: [PATCH] rtdm/drvlib: Prevent pagefaults on arm on io mapping
On 15.06.22 10:30, Philippe Gerum wrote:
>
> Jan Kiszka writes:
>
>> On 15.06.22 09:54, Philippe Gerum wrote:
>>>
>>> Jan Kiszka via Xenomai writes:
>>>
On 23.05.22 16:04, Gunter Grau via Xenomai wrote:
> From: Gunter Grau
>
> When mapping io memory into userspace an extra simulated pagefault for all
> pages is added to prevent later pagefaults because of copy on write
> mechanisms. This happens only on architectures that have defined the
> needed cobalt_machine.prefault function.
>
> Signed-off-by: Gunter Grau
> ---
> kernel/cobalt/rtdm/drvlib.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/cobalt/rtdm/drvlib.c b/kernel/cobalt/rtdm/drvlib.c
> index 4eaf3a57c..db8431ee1 100644
> --- a/kernel/cobalt/rtdm/drvlib.c
> +++ b/kernel/cobalt/rtdm/drvlib.c
> @@ -1761,6 +1761,7 @@ static int mmap_iomem_helper(struct vm_area_struct
> *vma, phys_addr_t pa)
> {
> pgprot_t prot = PAGE_SHARED;
> unsigned long len;
> + int ret;
>
> len = vma->vm_end - vma->vm_start;
> #ifndef CONFIG_MMU
> @@ -1774,8 +1775,15 @@ static int mmap_iomem_helper(struct vm_area_struct
> *vma, phys_addr_t pa)
> #endif
> vma->vm_page_prot = pgprot_noncached(prot);
>
> - return remap_pfn_range(vma, vma->vm_start, pa >> PAGE_SHIFT,
> + ret = remap_pfn_range(vma, vma->vm_start, pa >> PAGE_SHIFT,
> len, vma->vm_page_prot);
> + if (ret)
> + return ret;
> +
> + if (cobalt_machine.prefault)
> + cobalt_machine.prefault(vma);
> +
> + return ret;
> }
>
> static int mmap_buffer_helper(struct rtdm_fd *fd, struct vm_area_struct
> *vma)
Wow, that was likely broken by the refactoring in c8e9e166, long ago.
Applied to next
>>>
>>> The prefault hook has always been specifically about COW-breaking, I/O
>>> memory has no business with this, so there is no point in having the
>>> iomem helper calling the prefaulting hook.
>>>
>>> I suspect that rtdm_mmap_to_user() should be called instead of
>>> rtdm_iomap_to_user() in the case at hand.
>>>
>>
>> If Gunter is mapping IO memory, rtdm_mmap_to_user is surely not the
>> right thing.
>
> The xenomai2 implementation had a single helper dealing with I/O and
> kernel memory mappings (from virtual and linear memory) altogether. So I
> would not find impossible that wrong assumptions could be made from
> this implementation.
>
>>
>> Could it be that the prefault callback also has the side effect of
>> setting all page table entries that would otherwise only be filled lazily?
>
> Yes, this could prevent PTE misses, however I would expect minor faults
> to take place, those should be handled directly from the out-of-band
> stage. Otherwise, this _might_ be an issue with the interrupt pipeline
> used. The prefault for ARM was kind of a hack to work around
> shortcomings from the generic COW-breaking mechanism implemented by the
> I-pipe on ARM (IIRC, this had to do with LPAE support).
>
Gunter, could you take a function-trace of that very first fault without
your patch applied? Then we may see better what actually happens here,
specifically if your patch just happens to paper over a real issue.
BTW, you only tested it with I-pipe kernels so far, or did you also see
the issue with dovetail (5.10+)?
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
[PATCH 3.2.x] cobalt/x86: Account for changes to switch_fpu_finish in 5.4.182
From: Jan Kiszka The signature of switch_fpu_finish changed in stable 5.4. Signed-off-by: Jan Kiszka --- kernel/cobalt/arch/x86/ipipe/thread.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/kernel/cobalt/arch/x86/ipipe/thread.c b/kernel/cobalt/arch/x86/ipipe/thread.c index dd97a5d32c..7e28903a42 100644 --- a/kernel/cobalt/arch/x86/ipipe/thread.c +++ b/kernel/cobalt/arch/x86/ipipe/thread.c @@ -425,7 +425,9 @@ void xnarch_leave_root(struct xnthread *root) #if LINUX_VERSION_CODE >= KERNEL_VERSION(4,14,0) /* restore current's fpregs */ __cpu_invalidate_fpregs_state(); -#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0) +#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,4,182) + switch_fpu_finish(current); +#elif LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0) switch_fpu_finish(>thread.fpu); #else switch_fpu_finish(>thread.fpu, raw_smp_processor_id()); -- 2.35.3
Re: [xenomai-images][PATCH] Update Isar revision
On 15.06.22 18:00, Jan Kiszka via Xenomai wrote:
> From: Jan Kiszka
>
> This brings changes to image types that are easy to account for. Also
> the image file name changed, so adjust readme and start-qemu.sh.
>
> The update fixes logging issues, thus helps a lot with analyzing failing
> builds, specifically in CI.
>
> Signed-off-by: Jan Kiszka
> ---
> README.md | 2 +-
> conf/machine/hikey.conf | 2 +-
> conf/machine/qemu-machine.inc | 2 +-
> conf/machine/x86-64-efi.conf| 2 +-
> kas.yml | 2 +-
> recipes-xenomai/xenomai/xenomai_stable-3.0.x.bb | 2 ++
> start-qemu.sh | 2 +-
> 7 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/README.md b/README.md
> index b38e131..5f6c4c7 100644
> --- a/README.md
> +++ b/README.md
> @@ -41,7 +41,7 @@ armhf(`board-beagle-bone-black.yml`) and
> arm64(`board-hikey.yml`) targets.
> Each physical target will generate ready-to-boot images under
> `build/tmp/deploy/images/`. To flash, e.g., the HiKey image to an SD card,
> run
>
> -dd
> if=build/tmp/deploy/images/hikey/demo-image-hikey-xenomai-demo-hikey.wic.img \
> +dd
> if=build/tmp/deploy/images/hikey/demo-image-hikey-xenomai-demo-hikey.wic \
> of=/dev/ bs=1M status=progress
>
> ## CI Build
> diff --git a/conf/machine/hikey.conf b/conf/machine/hikey.conf
> index 6ad4611..344a3de 100644
> --- a/conf/machine/hikey.conf
> +++ b/conf/machine/hikey.conf
> @@ -11,7 +11,7 @@
>
> DISTRO_ARCH = "arm64"
>
> -IMAGE_FSTYPES ?= "wic-img"
> +IMAGE_FSTYPES ?= "wic"
> IMAGER_INSTALL += "${GRUB_BOOTLOADER_INSTALL}"
>
> IMAGE_PREINSTALL_append = " firmware-ti-connectivity"
> diff --git a/conf/machine/qemu-machine.inc b/conf/machine/qemu-machine.inc
> index 7771a11..d9ee2dd 100644
> --- a/conf/machine/qemu-machine.inc
> +++ b/conf/machine/qemu-machine.inc
> @@ -9,7 +9,7 @@
> # SPDX-License-Identifier: MIT
> #
>
> -IMAGE_FSTYPES = "ext4-img"
> +IMAGE_FSTYPES = "ext4"
>
> IMAGE_INSTALL_remove += "expand-on-first-boot"
> ROOTFS_EXTRA = "1024"
> diff --git a/conf/machine/x86-64-efi.conf b/conf/machine/x86-64-efi.conf
> index cb3ed85..036bdcd 100644
> --- a/conf/machine/x86-64-efi.conf
> +++ b/conf/machine/x86-64-efi.conf
> @@ -11,5 +11,5 @@
>
> DISTRO_ARCH = "amd64"
>
> -IMAGE_FSTYPES ?= "wic-img"
> +IMAGE_FSTYPES ?= "wic"
> IMAGER_INSTALL += "${GRUB_BOOTLOADER_INSTALL}"
> diff --git a/kas.yml b/kas.yml
> index 6b3b32d..7a06aca 100644
> --- a/kas.yml
> +++ b/kas.yml
> @@ -22,7 +22,7 @@ repos:
>
>isar:
> url: https://github.com/ilbers/isar.git
> -refspec: a960a4e52c50ef4a15e3827685fa9cfffead
> +refspec: 660d23fe898297524628a058d6121d9e425694f9
> layers:
>meta:
>
> diff --git a/recipes-xenomai/xenomai/xenomai_stable-3.0.x.bb
> b/recipes-xenomai/xenomai/xenomai_stable-3.0.x.bb
> index 6231e9e..00e4058 100644
> --- a/recipes-xenomai/xenomai/xenomai_stable-3.0.x.bb
> +++ b/recipes-xenomai/xenomai/xenomai_stable-3.0.x.bb
> @@ -20,3 +20,5 @@ SRC_URI = " \
> SRCREV = "${AUTOREV}"
>
> S = "${WORKDIR}/git"
> +
> +SRC_URI += "file://stable.patch"
> diff --git a/start-qemu.sh b/start-qemu.sh
> index 68516cc..33b6e65 100755
> --- a/start-qemu.sh
> +++ b/start-qemu.sh
> @@ -83,7 +83,7 @@ fi
> shift 1
>
> ${QEMU_PATH}${QEMU} \
> - -drive
> file=${IMAGE_PREFIX}.ext4.img,discard=unmap,if=none,id=disk,format=raw \
> + -drive
> file=${IMAGE_PREFIX}.ext4,discard=unmap,if=none,id=disk,format=raw \
> -m 1G -serial mon:stdio -netdev user,id=net \
> -kernel ${IMAGE_PREFIX}-${KERNEL_SUFFIX} -append "${KERNEL_CMDLINE}" \
> -initrd ${IMAGE_PREFIX}-initrd.img ${QEMU_EXTRA_ARGS} "$@"
Strike it. Missed some cases, and it contains a debug line.
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
Re: [PATCH 3.2.x] cobalt/x86: Account for changes to switch_fpu_finish in 5.4.182
On 15.06.22 17:20, Jan Kiszka via Xenomai wrote: > From: Jan Kiszka > > The signature of switch_fpu_finish changed in stable 5.4. > > Signed-off-by: Jan Kiszka > --- > kernel/cobalt/arch/x86/ipipe/thread.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/kernel/cobalt/arch/x86/ipipe/thread.c > b/kernel/cobalt/arch/x86/ipipe/thread.c > index dd97a5d32c..7e28903a42 100644 > --- a/kernel/cobalt/arch/x86/ipipe/thread.c > +++ b/kernel/cobalt/arch/x86/ipipe/thread.c > @@ -425,7 +425,9 @@ void xnarch_leave_root(struct xnthread *root) > #if LINUX_VERSION_CODE >= KERNEL_VERSION(4,14,0) > /* restore current's fpregs */ > __cpu_invalidate_fpregs_state(); > -#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0) > +#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,4,182) > + switch_fpu_finish(current); > +#elif LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0) > switch_fpu_finish(>thread.fpu); > #else > switch_fpu_finish(>thread.fpu, raw_smp_processor_id()); Actually 3.1.x material as well - we already supported 5.4 there. Jan -- Siemens AG, Technology Competence Center Embedded Linux
[xenomai-images][PATCH] Update Isar revision
From: Jan Kiszka
This brings changes to image types that are easy to account for. Also
the image file name changed, so adjust readme and start-qemu.sh.
The update fixes logging issues, thus helps a lot with analyzing failing
builds, specifically in CI.
Signed-off-by: Jan Kiszka
---
README.md | 2 +-
conf/machine/hikey.conf | 2 +-
conf/machine/qemu-machine.inc | 2 +-
conf/machine/x86-64-efi.conf| 2 +-
kas.yml | 2 +-
recipes-xenomai/xenomai/xenomai_stable-3.0.x.bb | 2 ++
start-qemu.sh | 2 +-
7 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/README.md b/README.md
index b38e131..5f6c4c7 100644
--- a/README.md
+++ b/README.md
@@ -41,7 +41,7 @@ armhf(`board-beagle-bone-black.yml`) and
arm64(`board-hikey.yml`) targets.
Each physical target will generate ready-to-boot images under
`build/tmp/deploy/images/`. To flash, e.g., the HiKey image to an SD card, run
-dd
if=build/tmp/deploy/images/hikey/demo-image-hikey-xenomai-demo-hikey.wic.img \
+dd
if=build/tmp/deploy/images/hikey/demo-image-hikey-xenomai-demo-hikey.wic \
of=/dev/ bs=1M status=progress
## CI Build
diff --git a/conf/machine/hikey.conf b/conf/machine/hikey.conf
index 6ad4611..344a3de 100644
--- a/conf/machine/hikey.conf
+++ b/conf/machine/hikey.conf
@@ -11,7 +11,7 @@
DISTRO_ARCH = "arm64"
-IMAGE_FSTYPES ?= "wic-img"
+IMAGE_FSTYPES ?= "wic"
IMAGER_INSTALL += "${GRUB_BOOTLOADER_INSTALL}"
IMAGE_PREINSTALL_append = " firmware-ti-connectivity"
diff --git a/conf/machine/qemu-machine.inc b/conf/machine/qemu-machine.inc
index 7771a11..d9ee2dd 100644
--- a/conf/machine/qemu-machine.inc
+++ b/conf/machine/qemu-machine.inc
@@ -9,7 +9,7 @@
# SPDX-License-Identifier: MIT
#
-IMAGE_FSTYPES = "ext4-img"
+IMAGE_FSTYPES = "ext4"
IMAGE_INSTALL_remove += "expand-on-first-boot"
ROOTFS_EXTRA = "1024"
diff --git a/conf/machine/x86-64-efi.conf b/conf/machine/x86-64-efi.conf
index cb3ed85..036bdcd 100644
--- a/conf/machine/x86-64-efi.conf
+++ b/conf/machine/x86-64-efi.conf
@@ -11,5 +11,5 @@
DISTRO_ARCH = "amd64"
-IMAGE_FSTYPES ?= "wic-img"
+IMAGE_FSTYPES ?= "wic"
IMAGER_INSTALL += "${GRUB_BOOTLOADER_INSTALL}"
diff --git a/kas.yml b/kas.yml
index 6b3b32d..7a06aca 100644
--- a/kas.yml
+++ b/kas.yml
@@ -22,7 +22,7 @@ repos:
isar:
url: https://github.com/ilbers/isar.git
-refspec: a960a4e52c50ef4a15e3827685fa9cfffead
+refspec: 660d23fe898297524628a058d6121d9e425694f9
layers:
meta:
diff --git a/recipes-xenomai/xenomai/xenomai_stable-3.0.x.bb
b/recipes-xenomai/xenomai/xenomai_stable-3.0.x.bb
index 6231e9e..00e4058 100644
--- a/recipes-xenomai/xenomai/xenomai_stable-3.0.x.bb
+++ b/recipes-xenomai/xenomai/xenomai_stable-3.0.x.bb
@@ -20,3 +20,5 @@ SRC_URI = " \
SRCREV = "${AUTOREV}"
S = "${WORKDIR}/git"
+
+SRC_URI += "file://stable.patch"
diff --git a/start-qemu.sh b/start-qemu.sh
index 68516cc..33b6e65 100755
--- a/start-qemu.sh
+++ b/start-qemu.sh
@@ -83,7 +83,7 @@ fi
shift 1
${QEMU_PATH}${QEMU} \
- -drive
file=${IMAGE_PREFIX}.ext4.img,discard=unmap,if=none,id=disk,format=raw \
+ -drive
file=${IMAGE_PREFIX}.ext4,discard=unmap,if=none,id=disk,format=raw \
-m 1G -serial mon:stdio -netdev user,id=net \
-kernel ${IMAGE_PREFIX}-${KERNEL_SUFFIX} -append "${KERNEL_CMDLINE}" \
-initrd ${IMAGE_PREFIX}-initrd.img ${QEMU_EXTRA_ARGS} "$@"
--
2.35.3
[Xenomai 3.1 PATCH v2] process: update clockfreq when receive corresponding event.
1. When there is clockfreq param passed down via command line, we
do not update clockfreq even if we receive event of updating clockfreq.
Or else, we update the clockfreq with notified value.
2. At the same time, we would like to update clockfreq param showing
in sys filesystem after apply updated clockfreq.
Signed-off-by: Hongzhan Chen
---
include/cobalt/kernel/init.h | 2 ++
kernel/cobalt/init.c | 12
kernel/cobalt/posix/process.c | 3 ++-
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/include/cobalt/kernel/init.h b/include/cobalt/kernel/init.h
index 41dd531a8..36d1ea290 100644
--- a/include/cobalt/kernel/init.h
+++ b/include/cobalt/kernel/init.h
@@ -51,4 +51,6 @@ void cobalt_remove_state_chain(struct notifier_block *nb);
void cobalt_call_state_chain(enum cobalt_run_states newstate);
+void cobalt_update_clockfreq(unsigned long freq);
+
#endif /* !_COBALT_KERNEL_INIT_H_ */
diff --git a/kernel/cobalt/init.c b/kernel/cobalt/init.c
index dbe321c3b..558030292 100644
--- a/kernel/cobalt/init.c
+++ b/kernel/cobalt/init.c
@@ -53,6 +53,16 @@ module_param_named(timerfreq, timerfreq_arg, ulong, 0444);
static unsigned long clockfreq_arg;
module_param_named(clockfreq, clockfreq_arg, ulong, 0444);
+static bool passed_clockfreq;
+
+void cobalt_update_clockfreq(unsigned long freq)
+{
+ if (!passed_clockfreq) {
+ xnclock_update_freq(freq);
+ clockfreq_arg = freq;
+ }
+}
+
#ifdef CONFIG_SMP
static unsigned long supported_cpus_arg = -1;
module_param_named(supported_cpus, supported_cpus_arg, ulong, 0444);
@@ -150,6 +160,8 @@ static int __init mach_setup(void)
if (clockfreq_arg == 0)
clockfreq_arg = sysinfo.sys_hrclock_freq;
+ else
+ passed_clockfreq = clockfreq_arg != 0;
if (clockfreq_arg == 0) {
printk(XENO_ERR "null clock frequency? Aborting.\n");
diff --git a/kernel/cobalt/posix/process.c b/kernel/cobalt/posix/process.c
index 6d1c1c427..f762fef2e 100644
--- a/kernel/cobalt/posix/process.c
+++ b/kernel/cobalt/posix/process.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1382,7 +1383,7 @@ static inline int handle_clockfreq_event(unsigned int *p)
{
unsigned int newfreq = *p;
- xnclock_update_freq(newfreq);
+ cobalt_update_clockfreq(newfreq);
return KEVENT_PROPAGATE;
}
--
2.17.1
[I-PIPE PATCH v2] x86/tsc: I-PIPE : notify I-PIPE about updated clockfreq
When there is refined tsc clock, notify Xenomai to apply it. Linux may schedule a delayed work to refine tsc clock and update tsc_khz which happen after Xenomai finsih init but tsc_scale and tsc_shift still keep the value depending on origianl tsc clock which is outdated. The difference between two clocks may cause unexpected timing drift. For example: [ 0.001731] tsc: Detected 2899.886 MHz TSC [ 5.588387] tsc: Refined TSC clocksource calibration: 2903.999 MHz cat /sys/module/xenomai/parameters/clockfreq 2899886000 After patching, we like to use 2903.999 MHz. Signed-off-by: Hongzhan Chen --- arch/x86/kernel/tsc.c | 4 1 file changed, 4 insertions(+) diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c index 835856efd71f..37faaf9a9e6c 100644 --- a/arch/x86/kernel/tsc.c +++ b/arch/x86/kernel/tsc.c @@ -1294,6 +1294,7 @@ static void tsc_refine_calibration_work(struct work_struct *work) u64 tsc_stop, ref_stop, delta; unsigned long freq; int cpu; + unsigned int ipipe_freq; /* Don't bother refining TSC on unstable systems */ if (tsc_unstable) @@ -1345,6 +1346,9 @@ static void tsc_refine_calibration_work(struct work_struct *work) /* Inform the TSC deadline clockevent devices about the recalibration */ lapic_update_tsc_freq(); + ipipe_freq = tsc_khz * 1000; +__ipipe_report_clockfreq_update(ipipe_freq); + /* Update the sched_clock() rate to match the clocksource one */ for_each_possible_cpu(cpu) set_cyc2ns_scale(tsc_khz, cpu, tsc_stop); -- 2.17.1
Re: [PATCH] rtdm/drvlib: Prevent pagefaults on arm on io mapping
Jan Kiszka writes:
> On 15.06.22 09:54, Philippe Gerum wrote:
>>
>> Jan Kiszka via Xenomai writes:
>>
>>> On 23.05.22 16:04, Gunter Grau via Xenomai wrote:
From: Gunter Grau
When mapping io memory into userspace an extra simulated pagefault for all
pages is added to prevent later pagefaults because of copy on write
mechanisms. This happens only on architectures that have defined the
needed cobalt_machine.prefault function.
Signed-off-by: Gunter Grau
---
kernel/cobalt/rtdm/drvlib.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/kernel/cobalt/rtdm/drvlib.c b/kernel/cobalt/rtdm/drvlib.c
index 4eaf3a57c..db8431ee1 100644
--- a/kernel/cobalt/rtdm/drvlib.c
+++ b/kernel/cobalt/rtdm/drvlib.c
@@ -1761,6 +1761,7 @@ static int mmap_iomem_helper(struct vm_area_struct
*vma, phys_addr_t pa)
{
pgprot_t prot = PAGE_SHARED;
unsigned long len;
+ int ret;
len = vma->vm_end - vma->vm_start;
#ifndef CONFIG_MMU
@@ -1774,8 +1775,15 @@ static int mmap_iomem_helper(struct vm_area_struct
*vma, phys_addr_t pa)
#endif
vma->vm_page_prot = pgprot_noncached(prot);
- return remap_pfn_range(vma, vma->vm_start, pa >> PAGE_SHIFT,
+ ret = remap_pfn_range(vma, vma->vm_start, pa >> PAGE_SHIFT,
len, vma->vm_page_prot);
+ if (ret)
+ return ret;
+
+ if (cobalt_machine.prefault)
+ cobalt_machine.prefault(vma);
+
+ return ret;
}
static int mmap_buffer_helper(struct rtdm_fd *fd, struct vm_area_struct
*vma)
>>>
>>> Wow, that was likely broken by the refactoring in c8e9e166, long ago.
>>>
>>> Applied to next
>>>
>>
>> The prefault hook has always been specifically about COW-breaking, I/O
>> memory has no business with this, so there is no point in having the
>> iomem helper calling the prefaulting hook.
>>
>> I suspect that rtdm_mmap_to_user() should be called instead of
>> rtdm_iomap_to_user() in the case at hand.
>>
>
> If Gunter is mapping IO memory, rtdm_mmap_to_user is surely not the
> right thing.
The xenomai2 implementation had a single helper dealing with I/O and
kernel memory mappings (from virtual and linear memory) altogether. So I
would not find impossible that wrong assumptions could be made from
this implementation.
>
> Could it be that the prefault callback also has the side effect of
> setting all page table entries that would otherwise only be filled lazily?
Yes, this could prevent PTE misses, however I would expect minor faults
to take place, those should be handled directly from the out-of-band
stage. Otherwise, this _might_ be an issue with the interrupt pipeline
used. The prefault for ARM was kind of a hack to work around
shortcomings from the generic COW-breaking mechanism implemented by the
I-pipe on ARM (IIRC, this had to do with LPAE support).
--
Philippe.
Re: [PATCH 2/2] x86: ipipe: Enable FPU tests unconditionally
On Tue, 2022-06-14 at 20:11 +0200, Jan Kiszka wrote:
> On 08.06.22 18:59, Bezdeka, Florian (T CED SES-DE) wrote:
> > On Wed, 2022-06-08 at 17:02 +0200, Jan Kiszka wrote:
> > > On 25.05.22 11:56, Florian Bezdeka wrote:
> > > > Parts of the FPU tests were skipped when one of the following config
> > > > options was enabled, shadowing a real test issue that was triggered by
> > > > high load on the system. The options:
> > > > - CONFIG_X86_USE_3DNOW
> > > > - CONFIG_MD_RAID456
> > > > - CONFIG_MD_RAID456_MODULE
> > > >
> > > > As the FPU initialization is fixed now, we can enable the tests
> > > > unconditionally.
> > > >
> > > > Signed-off-by: Florian Bezdeka
> > > > ---
> > > > .../arch/x86/ipipe/include/asm/xenomai/fptest.h | 13 -
> > > > 1 file changed, 13 deletions(-)
> > > >
> > > > diff --git a/kernel/cobalt/arch/x86/ipipe/include/asm/xenomai/fptest.h
> > > > b/kernel/cobalt/arch/x86/ipipe/include/asm/xenomai/fptest.h
> > > > index ccf7afa11..7a2b17d75 100644
> > > > --- a/kernel/cobalt/arch/x86/ipipe/include/asm/xenomai/fptest.h
> > > > +++ b/kernel/cobalt/arch/x86/ipipe/include/asm/xenomai/fptest.h
> > > > @@ -36,19 +36,6 @@ static inline void fp_init(void)
> > > >
> > > > static inline int fp_linux_begin(void)
> > > > {
> > > > -#if defined(CONFIG_X86_USE_3DNOW) \
> > > > - || defined(CONFIG_MD_RAID456) || defined(CONFIG_MD_RAID456_MODULE)
> > > > - /* Ther kernel uses x86 FPU, we can not also use it in our tests. */
> > > > - static int once = 0;
> > > > - if (!once) {
> > > > - once = 1;
> > > > - printk("%s:%d: Warning: Linux is compiled to use FPU in "
> > > > - "kernel-space.\nFor this reason, switchtest can not "
> > > > - "test using FPU in Linux kernel-space.\n",
> > > > - __FILE__, __LINE__);
> > > > - }
> > > > - return -EBUSY;
> > > > -#endif /* 3DNow or RAID 456 */
> > > > kernel_fpu_begin();
> > > > /* kernel_fpu_begin() does no re-initialize the fpu context, but
> > > >fp_regs_set() implicitely expects an initialized fpu context, so
> > >
> > > Hmm, I'm not yet fully convinced from reading both commit logs that the
> > > one fix actually obsoletes this check. Did it really only paper over a
> > > simple bug?
> >
> > I don't have the full history here, but it seems that this was kind of
> > double protection.
> >
> > So far all tests did not bring up any further issues.
> >
> > On systems with RAID (=systems with one of the mentioned options
> > enabled) FPU usage is much more likely and bugs would trigger more
> > likely. I would like to enable the FPU systems especially on such
> > systems.
> >
> > But: In case we have more undiscovered bugs in this area, it might
> > happen that we damage a RAID based file system. It seems Gilles had
> > such a system and tried to prevent FS damage this way.
> >
>
> OK, it's just a test setup in the end - let's dare it.
>
> Applied both to stable/v3.2.
I have prepared backports for stable/v3.1.x and stable/v3.0.x as well.
If there is interest I could easily send them out. I was just waiting
for feedback to avoid reworking them all.
Do we try to keep the stable branches "synchronized" even for testing
issues?
>
> Jan
>
Re: [PATCH 2/2] x86: ipipe: Enable FPU tests unconditionally
On 15.06.22 09:44, Bezdeka, Florian (T CED SES-DE) wrote:
> On Tue, 2022-06-14 at 20:11 +0200, Jan Kiszka wrote:
>> On 08.06.22 18:59, Bezdeka, Florian (T CED SES-DE) wrote:
>>> On Wed, 2022-06-08 at 17:02 +0200, Jan Kiszka wrote:
On 25.05.22 11:56, Florian Bezdeka wrote:
> Parts of the FPU tests were skipped when one of the following config
> options was enabled, shadowing a real test issue that was triggered by
> high load on the system. The options:
> - CONFIG_X86_USE_3DNOW
> - CONFIG_MD_RAID456
> - CONFIG_MD_RAID456_MODULE
>
> As the FPU initialization is fixed now, we can enable the tests
> unconditionally.
>
> Signed-off-by: Florian Bezdeka
> ---
> .../arch/x86/ipipe/include/asm/xenomai/fptest.h | 13 -
> 1 file changed, 13 deletions(-)
>
> diff --git a/kernel/cobalt/arch/x86/ipipe/include/asm/xenomai/fptest.h
> b/kernel/cobalt/arch/x86/ipipe/include/asm/xenomai/fptest.h
> index ccf7afa11..7a2b17d75 100644
> --- a/kernel/cobalt/arch/x86/ipipe/include/asm/xenomai/fptest.h
> +++ b/kernel/cobalt/arch/x86/ipipe/include/asm/xenomai/fptest.h
> @@ -36,19 +36,6 @@ static inline void fp_init(void)
>
> static inline int fp_linux_begin(void)
> {
> -#if defined(CONFIG_X86_USE_3DNOW) \
> - || defined(CONFIG_MD_RAID456) || defined(CONFIG_MD_RAID456_MODULE)
> - /* Ther kernel uses x86 FPU, we can not also use it in our tests. */
> - static int once = 0;
> - if (!once) {
> - once = 1;
> - printk("%s:%d: Warning: Linux is compiled to use FPU in "
> - "kernel-space.\nFor this reason, switchtest can not "
> - "test using FPU in Linux kernel-space.\n",
> - __FILE__, __LINE__);
> - }
> - return -EBUSY;
> -#endif /* 3DNow or RAID 456 */
> kernel_fpu_begin();
> /* kernel_fpu_begin() does no re-initialize the fpu context, but
>fp_regs_set() implicitely expects an initialized fpu context, so
Hmm, I'm not yet fully convinced from reading both commit logs that the
one fix actually obsoletes this check. Did it really only paper over a
simple bug?
>>>
>>> I don't have the full history here, but it seems that this was kind of
>>> double protection.
>>>
>>> So far all tests did not bring up any further issues.
>>>
>>> On systems with RAID (=systems with one of the mentioned options
>>> enabled) FPU usage is much more likely and bugs would trigger more
>>> likely. I would like to enable the FPU systems especially on such
>>> systems.
>>>
>>> But: In case we have more undiscovered bugs in this area, it might
>>> happen that we damage a RAID based file system. It seems Gilles had
>>> such a system and tried to prevent FS damage this way.
>>>
>>
>> OK, it's just a test setup in the end - let's dare it.
>>
>> Applied both to stable/v3.2.
>
> I have prepared backports for stable/v3.1.x and stable/v3.0.x as well.
> If there is interest I could easily send them out. I was just waiting
> for feedback to avoid reworking them all.
Great, please share then.
>
> Do we try to keep the stable branches "synchronized" even for testing
> issues?
More or less. In this case, 3.2 could rush forward first, though, as
there is no testing on next.
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
Re: [PATCH] rtdm/drvlib: Prevent pagefaults on arm on io mapping
Jan Kiszka via Xenomai writes:
> On 23.05.22 16:04, Gunter Grau via Xenomai wrote:
>> From: Gunter Grau
>>
>> When mapping io memory into userspace an extra simulated pagefault for all
>> pages is added to prevent later pagefaults because of copy on write
>> mechanisms. This happens only on architectures that have defined the
>> needed cobalt_machine.prefault function.
>>
>> Signed-off-by: Gunter Grau
>> ---
>> kernel/cobalt/rtdm/drvlib.c | 10 +-
>> 1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/kernel/cobalt/rtdm/drvlib.c b/kernel/cobalt/rtdm/drvlib.c
>> index 4eaf3a57c..db8431ee1 100644
>> --- a/kernel/cobalt/rtdm/drvlib.c
>> +++ b/kernel/cobalt/rtdm/drvlib.c
>> @@ -1761,6 +1761,7 @@ static int mmap_iomem_helper(struct vm_area_struct
>> *vma, phys_addr_t pa)
>> {
>> pgprot_t prot = PAGE_SHARED;
>> unsigned long len;
>> +int ret;
>>
>> len = vma->vm_end - vma->vm_start;
>> #ifndef CONFIG_MMU
>> @@ -1774,8 +1775,15 @@ static int mmap_iomem_helper(struct vm_area_struct
>> *vma, phys_addr_t pa)
>> #endif
>> vma->vm_page_prot = pgprot_noncached(prot);
>>
>> -return remap_pfn_range(vma, vma->vm_start, pa >> PAGE_SHIFT,
>> +ret = remap_pfn_range(vma, vma->vm_start, pa >> PAGE_SHIFT,
>> len, vma->vm_page_prot);
>> +if (ret)
>> +return ret;
>> +
>> +if (cobalt_machine.prefault)
>> +cobalt_machine.prefault(vma);
>> +
>> +return ret;
>> }
>>
>> static int mmap_buffer_helper(struct rtdm_fd *fd, struct vm_area_struct
>> *vma)
>
> Wow, that was likely broken by the refactoring in c8e9e166, long ago.
>
> Applied to next
>
The prefault hook has always been specifically about COW-breaking, I/O
memory has no business with this, so there is no point in having the
iomem helper calling the prefaulting hook.
I suspect that rtdm_mmap_to_user() should be called instead of
rtdm_iomap_to_user() in the case at hand.
--
Philippe.
Re: [PATCH] rtdm/drvlib: Prevent pagefaults on arm on io mapping
On 15.06.22 09:54, Philippe Gerum wrote:
>
> Jan Kiszka via Xenomai writes:
>
>> On 23.05.22 16:04, Gunter Grau via Xenomai wrote:
>>> From: Gunter Grau
>>>
>>> When mapping io memory into userspace an extra simulated pagefault for all
>>> pages is added to prevent later pagefaults because of copy on write
>>> mechanisms. This happens only on architectures that have defined the
>>> needed cobalt_machine.prefault function.
>>>
>>> Signed-off-by: Gunter Grau
>>> ---
>>> kernel/cobalt/rtdm/drvlib.c | 10 +-
>>> 1 file changed, 9 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/kernel/cobalt/rtdm/drvlib.c b/kernel/cobalt/rtdm/drvlib.c
>>> index 4eaf3a57c..db8431ee1 100644
>>> --- a/kernel/cobalt/rtdm/drvlib.c
>>> +++ b/kernel/cobalt/rtdm/drvlib.c
>>> @@ -1761,6 +1761,7 @@ static int mmap_iomem_helper(struct vm_area_struct
>>> *vma, phys_addr_t pa)
>>> {
>>> pgprot_t prot = PAGE_SHARED;
>>> unsigned long len;
>>> + int ret;
>>>
>>> len = vma->vm_end - vma->vm_start;
>>> #ifndef CONFIG_MMU
>>> @@ -1774,8 +1775,15 @@ static int mmap_iomem_helper(struct vm_area_struct
>>> *vma, phys_addr_t pa)
>>> #endif
>>> vma->vm_page_prot = pgprot_noncached(prot);
>>>
>>> - return remap_pfn_range(vma, vma->vm_start, pa >> PAGE_SHIFT,
>>> + ret = remap_pfn_range(vma, vma->vm_start, pa >> PAGE_SHIFT,
>>>len, vma->vm_page_prot);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + if (cobalt_machine.prefault)
>>> + cobalt_machine.prefault(vma);
>>> +
>>> + return ret;
>>> }
>>>
>>> static int mmap_buffer_helper(struct rtdm_fd *fd, struct vm_area_struct
>>> *vma)
>>
>> Wow, that was likely broken by the refactoring in c8e9e166, long ago.
>>
>> Applied to next
>>
>
> The prefault hook has always been specifically about COW-breaking, I/O
> memory has no business with this, so there is no point in having the
> iomem helper calling the prefaulting hook.
>
> I suspect that rtdm_mmap_to_user() should be called instead of
> rtdm_iomap_to_user() in the case at hand.
>
If Gunter is mapping IO memory, rtdm_mmap_to_user is surely not the
right thing.
Could it be that the prefault callback also has the side effect of
setting all page table entries that would otherwise only be filled lazily?
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
RE: [PATCH] rtdm/drvlib: Prevent pagefaults on arm on io mapping
Hi,
Your right, for io memory it does not make sense to do COW.
Nevertheless we see a page fault for each page after mapping on first access.
We also saw this at first when we used Xenomai 2.6 on 32bit arm, where it was
fixed.
It now happened again when porting to Xenomai3. I was hoping the linux kernel
whould now behave in an other way for io memory, but look like it stayed the
same at least for 32Bit arm. So I checked how it was handled in mmap and copied
the solution from there.
Regards,
Gunter
> -Original Message-
> From: Jan Kiszka
> Sent: Mittwoch, 15. Juni 2022 10:12
> To: Philippe Gerum ; Grau, Gunter
>
> Cc: xenomai@xenomai.org
> Subject: Re: [PATCH] rtdm/drvlib: Prevent pagefaults on arm on io mapping
>
> Caution: This e-mail originated from outside of Philips, be careful for
> phishing.
>
>
> On 15.06.22 09:54, Philippe Gerum wrote:
> >
> > Jan Kiszka via Xenomai writes:
> >
> >> On 23.05.22 16:04, Gunter Grau via Xenomai wrote:
> >>> From: Gunter Grau
> >>>
> >>> When mapping io memory into userspace an extra simulated pagefault
> >>> for all pages is added to prevent later pagefaults because of copy
> >>> on write mechanisms. This happens only on architectures that have
> >>> defined the needed cobalt_machine.prefault function.
> >>>
> >>> Signed-off-by: Gunter Grau
> >>> ---
> >>> kernel/cobalt/rtdm/drvlib.c | 10 +-
> >>> 1 file changed, 9 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/kernel/cobalt/rtdm/drvlib.c
> >>> b/kernel/cobalt/rtdm/drvlib.c index 4eaf3a57c..db8431ee1 100644
> >>> --- a/kernel/cobalt/rtdm/drvlib.c
> >>> +++ b/kernel/cobalt/rtdm/drvlib.c
> >>> @@ -1761,6 +1761,7 @@ static int mmap_iomem_helper(struct
> >>> vm_area_struct *vma, phys_addr_t pa) {
> >>> pgprot_t prot = PAGE_SHARED;
> >>> unsigned long len;
> >>> + int ret;
> >>>
> >>> len = vma->vm_end - vma->vm_start; #ifndef CONFIG_MMU @@
> >>> -1774,8 +1775,15 @@ static int mmap_iomem_helper(struct
> >>> vm_area_struct *vma, phys_addr_t pa) #endif
> >>> vma->vm_page_prot = pgprot_noncached(prot);
> >>>
> >>> - return remap_pfn_range(vma, vma->vm_start, pa >> PAGE_SHIFT,
> >>> + ret = remap_pfn_range(vma, vma->vm_start, pa >> PAGE_SHIFT,
> >>>len, vma->vm_page_prot);
> >>> + if (ret)
> >>> + return ret;
> >>> +
> >>> + if (cobalt_machine.prefault)
> >>> + cobalt_machine.prefault(vma);
> >>> +
> >>> + return ret;
> >>> }
> >>>
> >>> static int mmap_buffer_helper(struct rtdm_fd *fd, struct
> >>> vm_area_struct *vma)
> >>
> >> Wow, that was likely broken by the refactoring in c8e9e166, long ago.
> >>
> >> Applied to next
> >>
> >
> > The prefault hook has always been specifically about COW-breaking, I/O
> > memory has no business with this, so there is no point in having the
> > iomem helper calling the prefaulting hook.
> >
> > I suspect that rtdm_mmap_to_user() should be called instead of
> > rtdm_iomap_to_user() in the case at hand.
> >
>
> If Gunter is mapping IO memory, rtdm_mmap_to_user is surely not the right
> thing.
>
> Could it be that the prefault callback also has the side effect of setting all
> page table entries that would otherwise only be filled lazily?
>
> Jan
>
> --
> Siemens AG, Technology
> Competence Center Embedded Linux
The information contained in this message may be confidential and legally
protected under applicable law. The message is intended solely for the
addressee(s). If you are not the intended recipient, you are hereby notified
that any use, forwarding, dissemination, or reproduction of this message is
strictly prohibited and may be unlawful. If you are not the intended recipient,
please contact the sender by return e-mail and destroy all copies of the
original message.
Re: [REMINDER] Mailing list rehosting
On 21.05.22 12:48, Philippe Gerum via Xenomai wrote: > > The Xenomai mailing list server will be migrated to [1] on June 18 > 2022. In the meantime, the current server will be operating as > usual. However, the existing subscriptions to xenomai@xenomai.org will > NOT be automatically transferred to the new server. > > This means that: > > - The Xenomai mailing list service will be inaccessible on June 18 > from 4pm to 6pm CET for maintenance duties. > > - Starting from June 18 at 6pm CET, all posts to xenomai@xenomai.org > will be forwarded to xeno...@lists.linux.dev, the current mailing list > archive will move to [2] afterwards. > > - If you want to keep on receiving e-mails from the Xenomai mailing list > after this date, please subscribe to xeno...@lists.linux.dev by > sending an empty mail to xenomai+subscr...@lists.linux.dev. > > NOTE: xeno...@lists.linux.dev is a public list, you only need to > subscribe for receiving e-mails. > > Thanks, > > [1] https://subspace.kernel.org/lists.linux.dev.html > [2] https://lore.kernel.org/xenomai/ > Reminder @all that this switch is happening this weekend. Make sure you are already subscribed to the new list. Jan -- Siemens AG, Technology Competence Center Embedded Linux
Re: [External] - Re: compile conflict with Boost
Russell Johnson writes:
> [[S/MIME Signed Part:Undecided]]
> Apologies. Here you go.
>
> From 452e8b2ca8ecd53571a6b1f5d8b9ab23cd67f99d Mon Sep 17 00:00:00 2001
> From: Russell Johnson
> Date: Tue, 14 Jun 2022 08:10:14 -0600
> Subject: [PATCH] fixing conflict with C++ [[fallthough]], and maybe at some
> point in the future with the C2X standard
>
> Signed-off-by: Russell Johnson
> ---
> benchmarks/hectic.c| 10 +-
> benchmarks/latmus.c| 4 ++--
> include/evl/compiler.h | 2 +-
> lib/thread.c | 2 +-
> 4 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/benchmarks/hectic.c b/benchmarks/hectic.c
> index 6b6b3b5..886f7d2 100644
> --- a/benchmarks/hectic.c
> +++ b/benchmarks/hectic.c
> @@ -336,7 +336,7 @@ static void *sleeper_switcher(void *cookie)
> break;
> case 1:
> handle_bad_fpreg(param->cpu, ~0, -1);
> - fallthrough;
> + __fallthrough;
> case -1:
> clean_exit(EXIT_FAILURE);
> }
> @@ -469,7 +469,7 @@ static void *rtup(void *cookie)
> break;
> case 1:
> handle_bad_fpreg(param->cpu, ~0, -1);
> - fallthrough;
> + __fallthrough;
> case -1:
> clean_exit(EXIT_FAILURE);
> }
> @@ -549,7 +549,7 @@ static void *rtus(void *cookie)
> break;
> case 1:
> handle_bad_fpreg(param->cpu, ~0, -1);
> - fallthrough;
> + __fallthrough;
> case -1:
> clean_exit(EXIT_FAILURE);
> }
> @@ -646,7 +646,7 @@ static void *rtuo(void *cookie)
> break;
> case 1:
> handle_bad_fpreg(param->cpu, ~0, -1);
> - fallthrough;
> + __fallthrough;
> case -1:
> clean_exit(EXIT_FAILURE);
> }
> @@ -811,7 +811,7 @@ static int task_create(struct cpu_tasks *cpu,
> case RTUS:
> case RTUO:
> param->swt.flags = HECTIC_OOB_WAIT;
> - fallthrough;
> + __fallthrough;
> case SLEEPER:
> case SWITCHER:
> err = ioctl(cpu->fd, EVL_HECIOC_REGISTER_UTASK,
> >swt);
> diff --git a/benchmarks/latmus.c b/benchmarks/latmus.c
> index a507e80..59ed448 100644
> --- a/benchmarks/latmus.c
> +++ b/benchmarks/latmus.c
> @@ -1252,10 +1252,10 @@ int main(int argc, char *const argv[])
> switch (*endptr) {
> case 'd':
> timeout *= 24;
> - fallthrough;
> + __fallthrough;
> case 'h':
> timeout *= 60;
> - fallthrough;
> + __fallthrough;
> case 'm':
> timeout *= 60;
> break;
> diff --git a/include/evl/compiler.h b/include/evl/compiler.h
> index fce2766..8e6ad8c 100644
> --- a/include/evl/compiler.h
> +++ b/include/evl/compiler.h
> @@ -61,7 +61,7 @@
> #endif
>
> #ifndef __fallthrough
> -#define fallthrough__attribute__((__fallthrough__))
> +#define __fallthrough __attribute__((__fallthrough__))
> #endif
>
> #ifndef __alloc_size
> diff --git a/lib/thread.c b/lib/thread.c
> index 4b836cc..dc2ca6c 100644
> --- a/lib/thread.c
> +++ b/lib/thread.c
> @@ -111,7 +111,7 @@ int evl_attach_thread(int flags, const char *fmt, ...)
> break;
> default:
> policy = SCHED_FIFO;
> - fallthrough;
> + __fallthrough;
> case SCHED_FIFO:
> case SCHED_RR:
> priority = param.sched_priority;
Merged, thanks.
--
Philippe.
Re: EVL Heap Clarification
Russell Johnson via Xenomai writes: > Am I correct in assuming that any dynamic allocation in an EVL thread needs > to use the EVL heap in order to avoid in-band context switching? > > > > There are 4 calls in particular that I am using from the EVL heap API: > evl_init_heap (on startup), evl_alloc_block (may be called during realtime > processing to expand a data structure), evl_free_block (on shutdown), > evl_destroy_heap (on shutdown). The question is are all 4 of these calls > expected to only ever be called by an EVL thread? Looking at the source > code, I see that the alloc and free functions lock/unlock an EVL mutex so I > assume those can only be called from an EVL thread? Though the error codes > are not checked on those mutex calls, so if you call alloc or free from a > Linux thread, they do not fail. Can init and destroy be called from a Linux > thread? I was looking at the test code in libevl for heap-torture, and it > appeared that all 4 of these functions were being called from an EVL > attached thread. > Please check this documentation, the 3rd column gives the answer: https://evlproject.org/core/user-api/function_index/#memory-heap-services -- Philippe.
