_t
to raw_spinlock_t
Cc: sta...@vger.kernel.org
Fixes: 25da4618af24 ("xen/events: don't unmask an event channel
when an eoi is pending")
Signed-off-by: Luca Fancellu
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
t data and
call the handler only if this flag isn't set.
Cc: sta...@vger.kernel.org
Reported-by: Julien Grall
Signed-off-by: Juergen Gross
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
"normal" masking/unmasking from eoi related
masking/unmasking and temporary masking. The event channel should only
be able to generate an interrupt if all flags are cleared.
Cc: sta...@vger.kernel.org
Fixes: 54c9de89895e0a36047 ("xen/events: add a new late EOI evtchn framework")
Repor
t data and
call the handler only if this flag isn't set.
Reported-by: Julien Grall
Signed-off-by: Juergen Gross
---
V2:
- new patch
---
drivers/xen/events/events_base.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/xen/events/events_base.
zeroed out).
Cc: sta...@vger.kernel.org
Reported-by: Julien Grall
Signed-off-by: Juergen Gross
Reviewed-by: Julien Grall
Cheers,
---
V2:
- reset affinity when tearing down the event (Julien Grall)
---
drivers/xen/events/events_2l.c | 15 +++
drivers/xen/events
From: Julien Grall
After Commit 3499ba8198cad ("xen: Fix event channel callback via
INTX/GSI"), xenbus_probe() will be called too early on Arm. This will
recent to a guest hang during boot.
If there hang wasn't there, we would have ended up to call
xenbus_probe() twice (the se
On 08/02/2021 14:20, Julien Grall wrote:
I believe this will be the case before our "lateeoi" handling is
becoming active (more precise: when our IRQ handler is returning to
handle_fasteoi_irq()), resulting in the possibility of the same race we
are experiencing now.
I am a bi
Hi Juergen,
On 08/02/2021 13:58, Jürgen Groß wrote:
On 08.02.21 14:09, Julien Grall wrote:
Hi Juergen,
On 08/02/2021 12:31, Jürgen Groß wrote:
On 08.02.21 13:16, Julien Grall wrote:
On 08/02/2021 12:14, Jürgen Groß wrote:
On 08.02.21 11:40, Julien Grall wrote:
Hi Juergen,
On 08/02/2021
Hi Juergen,
On 08/02/2021 12:31, Jürgen Groß wrote:
On 08.02.21 13:16, Julien Grall wrote:
On 08/02/2021 12:14, Jürgen Groß wrote:
On 08.02.21 11:40, Julien Grall wrote:
Hi Juergen,
On 08/02/2021 10:22, Jürgen Groß wrote:
On 08.02.21 10:54, Julien Grall wrote:
... I don't really se
On 08/02/2021 12:14, Jürgen Groß wrote:
On 08.02.21 11:40, Julien Grall wrote:
Hi Juergen,
On 08/02/2021 10:22, Jürgen Groß wrote:
On 08.02.21 10:54, Julien Grall wrote:
... I don't really see how the difference matter here. The idea is
to re-use what's already existing rather t
Hi Juergen,
On 08/02/2021 11:48, Jürgen Groß wrote:
On 08.02.21 12:40, Julien Grall wrote:
On 06/02/2021 10:49, Juergen Gross wrote:
In evtchn_read() use READ_ONCE() for reading the producer index in
order to avoid the compiler generating multiple accesses.
Signed-off-by: Juergen Gross
or properly
aligned machine-sized stores, WRITE_ONCE() will prevent store tearing."
Cheers,
[1] https://lwn.net/Articles/793253/#Load%20Tearing
Juergen
--
Julien Grall
ons;
- p = u->ring_prod;
+ p = READ_ONCE(u->ring_prod);
For consistency, don't you also need the write side in
evtchn_interrupt() to use WRITE_ONCE()?
if (c != p)
break;
--
Julien Grall
Hi Juergen,
On 08/02/2021 10:22, Jürgen Groß wrote:
On 08.02.21 10:54, Julien Grall wrote:
... I don't really see how the difference matter here. The idea is to
re-use what's already existing rather than trying to re-invent the
wheel with an extra lock (or whatever we can come
On 08/02/2021 09:41, Jürgen Groß wrote:
On 08.02.21 10:11, Julien Grall wrote:
Hi Juergen,
On 07/02/2021 12:58, Jürgen Groß wrote:
On 06.02.21 19:46, Julien Grall wrote:
Hi Juergen,
On 06/02/2021 10:49, Juergen Gross wrote:
The first three patches are fixes for XSA-332. The avoid WARN
Hi Juergen,
On 07/02/2021 12:58, Jürgen Groß wrote:
On 06.02.21 19:46, Julien Grall wrote:
Hi Juergen,
On 06/02/2021 10:49, Juergen Gross wrote:
The first three patches are fixes for XSA-332. The avoid WARN splats
and a performance issue with interdomain events.
Thanks for helping to
we may want to consider to hold evtchn_rwlock with the write
permission. Although, I am not 100% sure this is going to prevent
everything.
Does my write-up make sense to you?
Cheers,
--
Julien Grall
On 06/02/2021 12:09, Jürgen Groß wrote:
On 06.02.21 12:20, Julien Grall wrote:
Hi Juergen,
On 06/02/2021 10:49, Juergen Gross wrote:
When creating a new event channel with 2-level events the affinity
needs to be reset initially in order to avoid using an old affinity
from earlier usage of
(cpu_evtchn_mask, cpu)));
The bit corresponding to the event channel can only be set on a single
CPU. Could we avoid the loop and instead clear the bit while closing the
port?
Cheers,
--
Julien Grall
Hi Juergen,
On 15/12/2020 10:20, Jürgen Groß wrote:
On 15.12.20 08:27, Jürgen Groß wrote:
On 14.12.20 22:25, Julien Grall wrote:
Hi Juergen,
When testing Linux 5.10 dom0, I could reliably hit the following
warning with using event 2L ABI:
[ 589.591737] Interrupt for port 34, but
Hi Juergen,
On 15/12/2020 10:20, Jürgen Groß wrote:
On 15.12.20 08:27, Jürgen Groß wrote:
On 14.12.20 22:25, Julien Grall wrote:
Hi Juergen,
When testing Linux 5.10 dom0, I could reliably hit the following
warning with using event 2L ABI:
[ 589.591737] Interrupt for port 34, but
enough because I haven't found anything
yet preventing a race between evtchn_2l_handle_events9) and
evtchn_2l_bind_vcpu().
So maybe we want to introduce a refcounting (if there is nothing
provided by the IRQ framework) and only unmask when the counter drop to 0.
Any opinions?
Cheers,
define gfn_to_virt(m)(__va(gfn_to_pfn(m) << XEN_PAGE_SHIFT))
+#define percpu_to_gfn(v) \
+ (pfn_to_gfn(per_cpu_ptr_to_phys(v) >> XEN_PAGE_SHIFT))
+
/* Only used in PV code. But ARM guests are always HVM. */
static inline xmaddr_t arbitrary_virt_to_machine(void *vaddr)
{
Cheers,
--
Julien Grall
Hi Roger,
On 28/07/2020 17:59, Roger Pau Monné wrote:
On Tue, Jul 28, 2020 at 05:48:23PM +0100, Julien Grall wrote:
Hi,
On 27/07/2020 10:13, Roger Pau Monne wrote:
To be used in order to create foreign mappings. This is based on the
ZONE_DEVICE facility which is used by persistent memory
se of hotplug in the
balloon code conditional (maybe using CONFIG_ARM64 and CONFIG_ARM)?
Cheers,
--
Julien Grall
);
bool xen_is_xen_suspend(void);
+void xen_setup_syscore_ops(void);
The function is only implemented and used by x86. So shouldn't this be
declared in an x86 header?
Cheers,
--
Julien Grall
Hi,
On 22/05/2020 04:55, Stefano Stabellini wrote:
On Thu, 21 May 2020, Julien Grall wrote:
Hi,
On 21/05/2020 00:45, Stefano Stabellini wrote:
From: Stefano Stabellini
It is not strictly needed. Call virt_to_phys on xen_io_tlb_start
instead. It will be useful not to have a start_dma_addr
Hi Stefano,
On 22/05/2020 04:54, Stefano Stabellini wrote:
On Thu, 21 May 2020, Julien Grall wrote:
Hi,
On 21/05/2020 00:45, Stefano Stabellini wrote:
From: Boris Ostrovsky
Don't just assume that virt_to_page works on all virtual addresses.
Instead add a is_vmalloc_addr check an
On Thu, 21 May 2020 at 21:08, Stefano Stabellini wrote:
>
> On Thu, 21 May 2020, Julien Grall wrote:
> > > @@ -97,8 +98,7 @@ bool xen_arch_need_swiotlb(struct device *dev,
> > >phys_addr_t phys,
> > >dma_addr_t dev_a
dma_cache_maint(dev, handle, size, GNTTAB_CACHE_INVAL);
else
- dma_cache_maint(handle, size, GNTTAB_CACHE_CLEAN);
+ dma_cache_maint(dev, handle, size, GNTTAB_CACHE_CLEAN);
}
bool xen_arch_need_swiotlb(struct device *dev,
Cheers,
--
Julien Grall
!dev_is_dma_coherent(dev));
}
Cheers,
--
Julien Grall
,
xen_virt_to_bus() is implemented as xen_phys_to_bus(virt_to_phys()). Can
you explain how the two are equivalent?
Cheers,
--
Julien Grall
ages(hwdev, size, vaddr, (dma_addr_t)phys, attrs);
Cheers,
--
Julien Grall
)
xen_destroy_contiguous_region(phys, order);
- xen_free_coherent_pages(hwdev, size, vaddr, (dma_addr_t)phys, attrs);
+ xen_free_coherent_pages(hwdev, size, vaddr, phys_to_dma(hwdev, phys),
+ attrs);
}
/*
Cheers,
--
Julien Grall
.
Therefore, we only need to hidden them from the userspace.
Signed-off-by: Julien Grall
Fixes: 06a916feca2b ('arm64: Expose SVE2 features for userspace')
---
arch/arm64/kernel/cpufeature.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/ar
order as they are defined in header. I.e.,
HWCAP first by ascending value, and then HWCAP2 in the similar fashion.
Signed-off-by: Julien Grall
---
Documentation/arm64/elf_hwcaps.rst | 64 +++---
1 file changed, 32 insertions(+), 32 deletions(-)
diff --git a
be zeroed and therefore the
userspace will not be able to see the HWCAP even if the hardware
supports the feature.
This can be fixed by describing the field in ftr_id_aa64isar1.
Fixes: ca9503fc9e98 ("arm64: Expose FRINT capabilities to userspace")
Signed-off-by: Julien Grall
C
A couple of fields visible to userspace are not described in the
documentation. So update it.
Signed-off-by: Julien Grall
---
Documentation/arm64/cpu-feature-registers.rst | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/arm64/cpu-feature-registers.rst
b/Documentation
On 01/10/2019 15:33, Mark Rutland wrote:
Hi Julien,
Hi Mark,
On Sat, Sep 07, 2019 at 11:05:45AM +0100, Julien Grall wrote:
On 9/6/19 6:20 PM, Andrew Cooper wrote:
On 06/09/2019 17:00, Arnd Bergmann wrote:
On Fri, Sep 6, 2019 at 5:55 PM Andrew Cooper wrote:
On 06/09/2019 16:39, Arnd
4760364. So it should be fine to backport for all the Linux tree contain
this commit.
Signed-off-by: Masayoshi Mizuma
Reported-by: Hidetoshi Seto
Suggested-by: Dave Martin
I have tested the patch and can confirm that double-free disappeared after the
patch is applied:
Tested-by: Julien G
gt;
> Since SVE only exists from v4.15, it may be helpful to specify that,
> i.e., replace that Cc line with:
>
> Cc: # 4.15.x-
>
>
> Otherwise, I'm happy to see this applied, but I'd like somebody to
> confirm that this change definitely fixes the bug.
I am working on a reproducer for this. So I should be able to test it.
Cheers,
--
Julien Grall
dst->thread.fork_in_progress = 1;
return 0;
}
@@ -365,6 +366,7 @@ int copy_thread(unsigned long clone_flags, unsigned long
stack_start,
* and disable discard SVE state for p:
*/
clear_tsk_thread_flag(p, TIF_SVE);
+ p->thread.fork_in_progress = 0;
p->thread.sve_state = NULL;
/*
Cheers,
--
Julien Grall
DMA
will not be coherent for the grant-table. Oleksandr, do you know why
they can't be coherent?
Cheers,
--
Julien Grall
limited. Rather than trying to
accomodate RT-system by switching to a raw_spin_lock(), the lock is now
completely dropped.
Reported-by: Andre Przywara
Signed-off-by: Julien Grall
---
lib/ubsan.c | 64 ++---
1 file changed, 23 insertions(+), 41 de
hence why I think this was unnoticed.
I will see if I can reproduce it and send a patch.
Cheers,
--
Julien Grall
The following commit has been merged into the timers/core branch of tip:
Commit-ID: 68b2c8c1e421096f4b46ac2ac502d25ca067a2a6
Gitweb:
https://git.kernel.org/tip/68b2c8c1e421096f4b46ac2ac502d25ca067a2a6
Author:Julien Grall
AuthorDate:Wed, 21 Aug 2019 10:24:09 +01:00
The following commit has been merged into the timers/core branch of tip:
Commit-ID: dd2261ed45aaeddeb77768f291d604179bcab096
Gitweb:
https://git.kernel.org/tip/dd2261ed45aaeddeb77768f291d604179bcab096
Author:Julien Grall
AuthorDate:Wed, 21 Aug 2019 10:24:07 +01:00
Hi Thomas,
Thank you for the review.
On 21/08/2019 15:02, Thomas Gleixner wrote:
On Wed, 21 Aug 2019, Julien Grall wrote:
migration_base is used as a placeholder when an hrtimer is switching
between base (see switch_hrtimer_timer_base). It is possible
theoritically possible to have timer
ancel+0x1c/0x38
[ 157.449780] 000: kvm_timer_vcpu_load+0x78/0x3e0
An hrtimer is always either running in softirq or not. This cannot be
changed after it is instantiated. So we can rely on timer->is_soft
for checking whether the lock can be grabbed.
Signed-off-by: Julien Grall
---
kernel/tim
t is safe
to remove the NULL checks here.
Signed-off-by: Julien Grall
---
I don't have a reproducer so far, but I can't see why it would not be
possible to happen.
---
kernel/time/hrtimer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/time/hrtimer.c b
e
check and the access is performed on the same base.
Other access of timer->base are either done with a lock or protected
with READ_ONCE(). So use READ_ONCE() in hrtimer_grab_expirty_lock().
Signed-off-by: Julien Grall
---
This is rather theoritical so far as I don't have a reproduce
Hi all,
This small series contains a few fixes for the hrtimer code in RT linux
(v5.2.9-rt3-rebase).
The patch #2 contains a error I managed to reproduce. The other two are
were found while looking at the code.
Cheers,
Julien Grall (3):
hrtimer: Use READ_ONCE to access timer->base
The ptrace trace SVE flags are prefixed with SVE_PT_*. Update the
comment accordingly.
Signed-off-by: Julien Grall
---
arch/arm64/kernel/ptrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 17525da8d5c8
Hi,
On 21/06/2019 10:39, guo...@kernel.org wrote:
Signed-off-by: Guo Ren
Cc: Arnd Bergmann
Cc: Julien Grall
---
arch/arm64/lib/asid.c| 9 ++-
This change should be in a separate e-mail with the Arm64 maintainers in CC.
But you seem to have a copy of the allocator in csky now
valid.
Signed-off-by: Julien Grall
---
This code will be used in the virt code for allocating VMID. I am not
entirely sure where to place it. Lib could potentially be a good place but I
am not entirely convinced the algo as it is could be used by other
architecture.
Looking at x86, it seems that it
is is not present in all relevant stable branches.
We currently have no Qualcomm hardware in the Xen Project test lab so
we do not need this enabled.
CC: Julien Grall
CC: linux-arm-...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
CC: Stephen Boyd
CC: Andy Gross
CC: Bjorn Andersson
CC: Ava
Hi Will,
On 5/30/19 1:01 PM, Will Deacon wrote:
On Thu, May 30, 2019 at 12:30:58PM +0100, Julien Grall wrote:
cpu_enable_ssbs() is called via stop_machine() as part of the cpu_enable
callback. A spin lock is used to ensure the hook is registered before
the rest of the callback is executed.
On
raw_spin_lock() is required here.
Given this is already done under stop_machine() and the work done under
the lock is quite small, the latency should not increase too much.
Signed-off-by: Julien Grall
---
It was noticed when looking at the current use of spin_lock in
arch/arm64. I don't h
Linux, at least.
If we decide to disable the driver, then we would need to add in our .config,
then we would need to disable completely the support for Qualcomm (i.e
CONFIG_ARCH_QCOM=n) on Arm32.
This should not be an issue in osstest as we don't test any qualcomm board so
far.
Cheers,
--
Julien Grall
ARM_PSCI_FW is not selected? Is it possible to
have a .config for RCAR without ARM_PSCI_FW?
Cheers,
--
Julien Grall
, it means Xen would not be able to
use the timer until Dom0 has booted. But, shouldn't newer U-boot do it
for you?
Cheers,
--
Julien Grall
Hi Dave,
On 4/26/19 4:31 PM, Dave Martin wrote:
On Fri, Apr 26, 2019 at 04:06:02PM +0100, Julien Grall wrote:
Hi,
On 26/04/2019 15:52, Dave Martin wrote:
On Fri, Apr 26, 2019 at 03:37:40PM +0100, Julien Grall wrote:
When the kernel is compiled with CONFIG_KERNEL_MODE_NEON, some part of
the
Hi Marc,
On 23/04/2019 11:54, Marc Zyngier wrote:
On 18/04/2019 18:26, Julien Grall wrote:
On RT, the function iommu_dma_map_msi_msg may be called from
non-preemptible context. This will lead to a splat with
CONFIG_DEBUG_ATOMIC_SLEEP as the function is using spin_lock
(they can sleep on RT
Hi,
On 26/04/2019 15:52, Dave Martin wrote:
On Fri, Apr 26, 2019 at 03:37:40PM +0100, Julien Grall wrote:
When the kernel is compiled with CONFIG_KERNEL_MODE_NEON, some part of
the kernel may be able to use FPSIMD/SVE. This is for instance the case
for crypto code.
Any use of FPSIMD/SVE in
-off-by: Julien Grall
Reviewed-by: Dave Martin
---
kernel_neon_begin() does not use fpsimd_save_and_flush_cpu_state()
because the next patch will modify the function to also grab the
FPSIMD/SVE context.
Changes in v4:
- Remove newline before the new prototype
- Add
an be
manipulate freely.
The change has been benchmarked on Linux 5.1-rc4 with defconfig.
On Juno2:
* hackbench 100 process 1000 (10 times)
* .7% quicker
On ThunderX 2:
* hackbench 1000 process 1000 (20 times)
* 3.4% quicker
Signed-off-by: Julien Grall
---
Changes
The function sve_flush_cpu_state() has been removed in commit 21cdd7fd76e3
("KVM: arm64: Remove eager host SVE state saving").
So remove the associated prototype in asm/fpsimd.h.
Signed-off-by: Julien Grall
Reviewed-by: Dave Martin
---
Changes in v3:
- Add Dave
:
* hackbench 1000 process 1000 (20 times)
* 3.4% quicker
Note that while the benchmark has been done on 5.1-rc4, the patch series is
based on kvm-arm/next as it has few conflicts with the SVE KVM series.
Cheers,
Julien Grall (3):
arm64/fpsimd: Remove the prototype for sve_flush_cpu_state
Hi Dave,
On 25/04/2019 17:39, Dave Martin wrote:
On Thu, Apr 25, 2019 at 04:57:26PM +0100, Julien Grall wrote:
Hi Dave,
On 24/04/2019 14:17, Dave Martin wrote:
On Tue, Apr 23, 2019 at 02:57:19PM +0100, Julien Grall wrote:
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
Hi Dave,
On 24/04/2019 14:17, Dave Martin wrote:
On Tue, Apr 23, 2019 at 02:57:19PM +0100, Julien Grall wrote:
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 5313aa257be6..6168d06bbd20 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -92,7
Hi Dave,
On 24/04/2019 14:17, Dave Martin wrote:
On Tue, Apr 23, 2019 at 02:57:18PM +0100, Julien Grall wrote:
tent-Length: 4295
Lines: 128
The only external user of fpsimd_save() and fpsimd_flush_cpu_state() is
the KVM FPSIMD code.
A following patch will introduce a mechanism to acquire
The function sve_flush_cpu_state() has been removed in commit 21cdd7fd76e3
("KVM: arm64: Remove eager host SVE state saving").
So remove the associated prototype in asm/fpsimd.h.
Signed-off-by: Julien Grall
Reviewed-by: Dave Martin
---
Changes in v3:
- Add Dave
-off-by: Julien Grall
---
kernel_neon_begin() does not use fpsimd_save_and_flush_cpu_state()
because the next patch will modify the function to also grab the
FPSIMD/SVE context.
Changes in v3:
- Rework the commit message
- Move the prototype of
:
* hackbench 1000 process 1000 (20 times)
* 3.4% quicker
Note that while the benchmark has been done on 5.1-rc4, the patch series is
based on kvm-arm/next as it has few conflicts with the
SVE KVM series.
Cheers,
Julien Grall (3):
arm64/fpsimd: Remove the prototype for sve_flush_cpu_state
e has been benchmarked on Linux 5.1-rc4 with defconfig.
On Juno2:
* hackbench 100 process 1000 (10 times)
* .7% quicker
On ThunderX 2:
* hackbench 1000 process 1000 (20 times)
* 3.4% quicker
Signed-off-by: Julien Grall
---
Changes in v3:
- Fix typoes in the commit me
Hi Dave,
On 4/17/19 3:01 PM, Dave Martin wrote:
On Wed, Apr 17, 2019 at 12:37:57PM +0100, Julien Grall wrote:
Hi Dave,
On 16/04/2019 13:30, Dave Martin wrote:
On Fri, Apr 12, 2019 at 06:14:20PM +0100, Julien Grall wrote:
[...]
+
+/*
+ * Obtain the CPU FPSIMD context for use by the
other does
not have any requirement.
This patch reworks the GICv3 ITS driver to avoid executing preemptible
code in non-preemptible context by preparing the MSI mapping when
allocating the MSI interrupt.
Signed-off-by: Julien Grall
---
drivers/irqchip/irq-gic-v3-its.c | 5 -
1 file changed, 4
The word 'entirely' has been misspelt in a comment in its_msi_prepare().
Signed-off-by: Julien Grall
---
drivers/irqchip/irq-gic-v3-its.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 75
The word 'number' has been misspelt in the comment on top of
_irq_domain_alloc_irqs().
Signed-off-by: Julien Grall
---
kernel/irq/irqdomain.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 9ed29e4a7dbf..a4
Hi Dave,
On 16/04/2019 13:30, Dave Martin wrote:
On Fri, Apr 12, 2019 at 06:14:20PM +0100, Julien Grall wrote:
When the kernel is compiled with CONFIG_KERNEL_MODE_NEON, some part of
the kernel may be able to use FPSIMD/SVE. This is for instance the case
for crypto code.
Any use of FPSIMD/SVE
Hi Dave,
On 4/16/19 12:53 PM, Dave Martin wrote:
On Fri, Apr 12, 2019 at 06:14:19PM +0100, Julien Grall wrote:
The only external user of fpsimd_save() and fpsimd_flush_cpu_state() is
the KVM FPSIMD code.
A follow-up patch will mandate hold of the FPSIMD context while
This is a bit hard to
fpsimd_save() and fpsimd_flush_cpu_state().
This has also the advantage to remove any external call of fpsimd_save()
and fpsimd_flush_cpu_state(), so they can be turned static.
Lastly, the new function can also be used in the PM notifier.
Signed-off-by: Julien Grall
---
Changes in v2
has been benchmarked on Linux 5.1-rc4 with defconfig.
On Juno2:
* hackbench 100 process 1000 (10 times)
* .7% quicker
On ThunderX 2:
* hackbench 1000 process 1000 (20 times)
* 3.4% quicker
Signed-off-by: Julien Grall
---
Changes in v2:
- Remove spurious call to
The function sve_flush_cpu_state() has been removed in commit
21cdd7fd76e3 "KVM: arm64: Remove eager host SVE state saving".
So remove the associated prototype in asm/fpsimd.h.
Signed-off-by: Julien Grall
---
Changes in v2:
- Patch added
---
arch/arm64/include/asm/fp
:
* hackbench 1000 process 1000 (20 times)
* 3.4% quicker
Note that while the benchmark has been done on 5.1-rc4, the patch series is
based on kvm-arm/next as it has few conflicts with the SVE KVM series.
Cheers,
Julien Grall (3):
arm64/fpsimd: Remove the prototype for sve_flush_cpu_state()
arch
Hi Dave,
On 4/11/19 5:34 PM, Dave Martin wrote:
On Thu, Apr 11, 2019 at 04:58:41PM +0100, Julien Grall wrote:
Hi Dave,
On 4/5/19 4:07 PM, Dave Martin wrote:
On Fri, Apr 05, 2019 at 10:02:45AM +0100, Julien Grall wrote:
+#ifdef CONFIG_KERNEL_MODE_NEON
+
/*
* may_use_simd - whether it is
Hi Dave,
On 4/5/19 4:07 PM, Dave Martin wrote:
On Fri, Apr 05, 2019 at 10:02:45AM +0100, Julien Grall wrote:
+#ifdef CONFIG_KERNEL_MODE_NEON
+
/*
* may_use_simd - whether it is allowable at this time to issue SIMD
*instructions or access the SIMD register file
diff
Hi Sebastian,
On 4/5/19 4:42 PM, Sebastian Andrzej Siewior wrote:
On 2019-04-05 16:17:50 [+0100], Julien Grall wrote:
Hi,
Hi,
A per-CPU lock? It has to be a raw_spinlock_t because a normal
spin_lock() / local_lock() would allow scheduling and might be taken as
part of the context switch or
Hi Dave,
On 4/4/19 11:52 AM, Dave Martin wrote:
On Fri, Feb 08, 2019 at 04:55:13PM +, Julien Grall wrote:
I'm not sure how this patch will affect context switch overhead, so it
would be good to see hackbench numbers (or similar).
I finally have some numbers for this patch. The benc
Hi,
On 05/04/2019 15:39, Sebastian Andrzej Siewior wrote:
On 2019-04-05 10:02:45 [+0100], Julien Grall wrote:
RT folks already saw this corruption because local_bh_disable() does not
preempt on RT. They are carrying a patch (see "arm64: fpsimd: use
preemp_disable in additi
Hi Dave,
Thank you for the review.
On 4/4/19 11:52 AM, Dave Martin wrote:
On Fri, Feb 08, 2019 at 04:55:13PM +, Julien Grall wrote:
For RT-linux, it might be possible to use migrate_{enable, disable}. I
am quite new with RT and have some trouble to understand the semantics
of migrate_
Hi John,
On 3/25/19 10:34 AM, John Ogness wrote:
On 2019-03-25, Julien Grall wrote:
[...]
[1.169151] 002: Serial: AMBA PL011 UART driver
[1.254891] 002: 7ff8.uart: ttyAMA0 at MMIO 0x7ff8 (irq = 32,
base_baud = 0) is a PL011 rev3
[1.255007] 002: printk: console [ttyAMA0
Hi John,
Thank you for your answer.
On 3/25/19 8:13 AM, John Ogness wrote:
> On 2019-03-22, Julien Grall wrote:
>> Apologies for a possible stupid question.
>
> It's an important question because the behavior of console printing has
> changed. (Or, rather, is in the p
So I am wondering
whether this issue is related to it? Is there any advice to prevent the mangling?
Cheers,
--
Julien Grall
On 15/03/2019 10:06, Dave Martin wrote:
On Thu, Mar 14, 2019 at 06:07:19PM +, Julien Grall wrote:
Hi Sebastian,
On 3/4/19 5:25 PM, Sebastian Andrzej Siewior wrote:
[...]
It would increase the softirq latency but the question is how bad would
it be. It would continue once the SIMD
Hi Sebastian,
On 3/4/19 5:25 PM, Sebastian Andrzej Siewior wrote:
On 2019-02-18 15:07:51 [+], Julien Grall wrote:
Hi,
Hi,
Wouldn't this arbitrarily increase softirq latency? Unconditionally
forbidding SIMD in softirq might make more sense. It depends on how
important the use case
ll block on the lock
until the request is done. This is okay because the user asked for a
backtrace of all active CPUs and under "normal circumstances in
production" this path should not be triggered.
Signed-off-by: Julien Grall
[bige...@linuxtronix.de: commit description]
Signed-off-by:
Hi David,
On 3/12/19 5:18 PM, David Hildenbrand wrote:
On 12.03.19 18:14, Matthew Wilcox wrote:
On Tue, Mar 12, 2019 at 05:05:39PM +, Julien Grall wrote:
On 3/12/19 3:59 PM, Julien Grall wrote:
It looks like all the arm test for linus [1] and next [2] tree
are now failing. x86 seems to
Hi Christoph,
On 08/03/2019 15:23, Christoph Hellwig wrote:
On Tue, Mar 05, 2019 at 09:41:46AM +, Julien Grall wrote:
On Xen, dma_addr_t will always be 64-bit while the phys_addr_t will depend
on the MMU type. So we may have phys_addr_t smaller than dma_addr_t from
the kernel point of view
Hi Sebastian,
On 07/03/2019 12:38, Sebastian Andrzej Siewior wrote:
On 2019-03-04 17:20:53 [+], Julien Grall wrote:
At the moment show_lock is implemented using spin_lock_t and called from
an interrupt context on Arm64. The following backtrace was triggered by:
42sh# echo l > /proc/sy
1 - 100 of 727 matches
Mail list logo
