hwdev, size, vaddr, (dma_addr_t)phys, attrs);
Cheers,
--
Julien Grall
!dev_is_dma_coherent(dev));
}
Cheers,
--
Julien Grall
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
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
NIT: Shouldn't you use /* ... */ for multi-line comments?
Regardless that:
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
Hi Marc,
On 05/22/2018 04:06 PM, Marc Zyngier wrote:
In a heterogeneous system, we can end up with both affected and
unaffected CPUs. Let's check their status before calling into the
firmware.
Signed-off-by: Marc Zyngier
Reviewed-by: Julien Grall
Cheers,
---
arch/arm64/kernel
30
NIT: Could you indent 30 the same way as the other number?
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
permanently
on or off instead of switching it on exception entry/exit.
In any case, default to the mitigation being enabled.
Signed-off-by: Marc Zyngier
Reviewed-by: Julien Grall
Cheers,
---
Documentation/admin-guide/kernel-parameters.txt | 17
arch/arm64/include/asm/cpufeature.h
Reviewed-by: Julien Grall
Cheers,
---
arch/arm64/include/asm/cpufeature.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/include/asm/cpufeature.h
b/arch/arm64/include/asm/cpufeature.h
index 9bc548e22784..1bacdf57f0af 100644
--- a/arch/arm64/include/asm/cpufeature.h
mitigation.
Think of it as a poor man's static key...
Signed-off-by: Marc Zyngier
Reviewed-by: Julien Grall
Cheers,
---
arch/arm64/kernel/cpu_errata.c | 14 ++
arch/arm64/kernel/entry.S | 3 +++
2 files changed, 17 insertions(+)
diff --git a/arch/arm64/kernel
ine option,
let's enforce it by calling into the firmware again to disable it.
Signed-off-by: Marc Zyngier
Reviewed-by: Julien Grall
Cheers,
---
arch/arm64/include/asm/cpufeature.h | 6 ++
arch/arm64/kernel/cpu_errata.c | 8
arch/arm64/kernel/suspend.c | 8 ++
-implemented to use the new helpers.
Signed-off-by: Julien Grall
---
I have been exploring this solution as an alternative approach to the RT
patch "arm64: fpsimd: use preemp_disable in addition to local_bh_disable()".
So far, the patch has only been lightly tested.
For RT-linux
The bit TIF_USEDFPU is not used in the nds32 code.
Signed-off-by: Julien Grall
Cc: Greentime Hu
Cc: Vincent Chen
---
Untested as I don't have a cross-compiler for it.
---
arch/nds32/include/asm/thread_info.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/nds32/include/asm
Hi all,
This small patch series remove reference of TIF_USEDFPU on nds32, arm and
arm64 as the flag is not inuse.
Cheers,
Cc: Greentime Hu
Cc: Vincent Chen
Cc: Russell King
Cc: Catalin Marinas
Cc: Will Deacon
Cc: linux-arm-ker...@lists.infradead.org
Julien Grall (3):
nds32: Removed
The bit TIF_USEDFPU is not used in the nds32 code.
Signed-off-by: Julien Grall
Cc: Greentime Hu
Cc: Vincent Chen
---
Untested as I don't have a cross-compiler for it.
---
arch/nds32/include/asm/thread_info.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/nds32/include/asm
TIF_USEDFPU is not defined as thread flags for Arm. So drop it from
the documentation.
Signed-off-by: Julien Grall
Cc: Russell King
Cc: linux-arm-ker...@lists.infradead.org
---
arch/arm/include/asm/thread_info.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/include/asm
Hi,
Sorry I made an error in the patches sent. Please ignore this series and look
for the "RESEND" version.
Cheers,
On 08/02/2019 17:03, Julien Grall wrote:
Hi all,
This small patch series remove reference of TIF_USEDFPU on nds32, arm and
arm64 as the flag is not inuse.
C
Hi all,
This small patch series remove reference of TIF_USEDFPU on nds32, arm and
arm64 as the flag is not inuse.
Cheers,
Cc: Greentime Hu
Cc: Vincent Chen
Cc: Russell King
Cc: Catalin Marinas
Cc: Will Deacon
Cc: linux-arm-ker...@lists.infradead.org
Julien Grall (3):
nds32: Removed
TIF_USEDFPU is not defined as thread flags for Arm. So drop it from
the documentation.
Signed-off-by: Julien Grall
Cc: Russell King
Cc: linux-arm-ker...@lists.infradead.org
---
arch/arm/include/asm/thread_info.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/include/asm
-implemented to use the new helpers.
Signed-off-by: Julien Grall
---
I have been exploring this solution as an alternative approach to the RT
patch "arm64: fpsimd: use preemp_disable in addition to local_bh_disable()".
So far, the patch has only been lightly tested.
For RT-linux
TIF_USEDFPU is not defined as thread flags for Arm64. So drop it from
the documentation.
Signed-off-by: Julien Grall
Cc: Catalin Marinas
Cc: Will Deacon
Cc: linux-arm-ker...@lists.infradead.org
---
arch/arm64/include/asm/thread_info.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch
se for memory shared in both the backend and frontend?
Cheers,
Thank you,
Oleksandr
___
Xen-devel mailing list
xen-de...@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
--
Julien Grall
the frontend and backend which may cause screen artifacts.
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Oleksandr Andrushchenko
Suggested-by: Julien Grall
---
drivers/gpu/drm/xen/xen_drm_front_gem.c | 5 ++---
1 file changed, 2 insertions(+), 3
On 24/01/2019 14:34, Oleksandr Andrushchenko wrote:
Hello, Julien!
Hi,
On 1/22/19 1:44 PM, Julien Grall wrote:
On 1/22/19 10:28 AM, Oleksandr Andrushchenko wrote:
Hello, Julien!
Hi,
On 1/21/19 7:09 PM, Julien Grall wrote:
Well, I didn't get the attributes of pages at the backend
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
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
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..a453e229f99c
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 7577755bdcf4
, 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
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
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 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
:
* 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
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'
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 in v4
-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
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
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
il Dom0 has booted. But, shouldn't newer U-boot do it
for you?
Cheers,
--
Julien Grall
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
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 message
-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
:
* 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
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'
n ARM_PSCI_FW is not selected? Is it possible to
have a .config for RCAR without ARM_PSCI_FW?
Cheers,
--
Julien Grall
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 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 cases
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 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,
On 2/26/19 11:02 AM, Roger Pau Monné wrote:
On Tue, Feb 26, 2019 at 10:26:21AM +, Julien Grall wrote:
On 26/02/2019 10:17, Roger Pau Monné wrote:
On Tue, Feb 26, 2019 at 10:03:38AM +, Julien Grall wrote:
Hi Roger,
On 26/02/2019 09:44, Roger Pau Monné wrote:
On Tue, Feb 26, 2019
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 benchmark
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
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 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
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,
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 add
:
* 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
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
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
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
wondering
whether this issue is related to it? Is there any advice to prevent the mangling?
Cheers,
--
Julien Grall
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 proces
On 12/02/2019 17:13, Julia Cartwright wrote:
Hello Julien-
Hello Julien,
On Fri, Feb 08, 2019 at 04:55:13PM +, 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
Hello Sebastian,
On 13/02/2019 14:30, Sebastian Andrzej Siewior wrote:
On 2019-02-08 16:55:13 [+], 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
from cb84d11e1625 "arm64: neon: Remove support for
nested or hardirq kernel-mode NEON", one of the use case for crypto in softirq
is certain mac80211 drivers.
Is there any other use case for use crypto in softirqs?
Cheers,
--
Julien Grall
Hi all,
On 08/02/2019 16:55, Julien Grall wrote:
@@ -1094,9 +1113,7 @@ void kernel_neon_begin(void)
/* Invalidate any task state remaining in the fpsimd regs: */
fpsimd_flush_cpu_state();
- preempt_disable();
-
- local_bh_enable();
+ kernel_neon_enable();
I
trace 1d3fa385877cc18b ]---
Cheers,
--
Julien Grall
Hi Boris,
Thank you for your answer.
On 20/02/2019 00:02, Boris Ostrovsky wrote:
On Tue, Feb 19, 2019 at 05:31:10PM +, Julien Grall wrote:
Hi all,
I have been looking at using Linux RT in Dom0. Once the guest is started,
the console is ending to have a lot of warning (see trace below
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
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: Sebastian Andrz
Hi,
On 20/02/2019 17:07, Boris Ostrovsky wrote:
On 2/20/19 9:15 AM, Julien Grall wrote:
Hi Boris,
Thank you for your answer.
On 20/02/2019 00:02, Boris Ostrovsky wrote:
On Tue, Feb 19, 2019 at 05:31:10PM +, Julien Grall wrote:
Hi all,
I have been looking at using Linux RT in Dom0
(+ Andrew and Jan for feedback on the event channel interrupt)
Hi Boris,
Thank you for the your feedback.
On 2/20/19 8:04 PM, Boris Ostrovsky wrote:
On 2/20/19 1:05 PM, Julien Grall wrote:
Hi,
On 20/02/2019 17:07, Boris Ostrovsky wrote:
On 2/20/19 9:15 AM, Julien Grall wrote:
Hi Boris
Hi Boris,
On 2/20/19 9:46 PM, Boris Ostrovsky wrote:
On 2/20/19 3:46 PM, Julien Grall wrote:
(+ Andrew and Jan for feedback on the event channel interrupt)
Hi Boris,
Thank you for the your feedback.
On 2/20/19 8:04 PM, Boris Ostrovsky wrote:
On 2/20/19 1:05 PM, Julien Grall wrote:
Hi
Hi Roger,
On 21/02/2019 09:14, Roger Pau Monné wrote:
> On Thu, Feb 21, 2019 at 08:38:39AM +0000, Julien Grall wrote:
>> Hi Roger,
>>
>> On Thu, 21 Feb 2019, 08:08 Roger Pau Monné, wrote:
>>
>>> FWIW, you can also mask the interrupt while waiting for the
Hi,
On 22/02/2019 12:38, Oleksandr Andrushchenko wrote:
On 2/20/19 10:46 PM, Julien Grall wrote:
Discussing with my team, a solution that came up would be to introduce one
atomic field per event to record the number of event received. I will explore
that solution tomorrow.
How will this help
668
[ 4432.403607] gic_handle_irq+0x9c/0xa0
[ 4432.403609] el1_irq+0xb4/0x13c
With RT-patches, spin_lock can now sleep and therefore cannot be used from
interrupt context. Use a raw_spin_lock instead to prevent the lock to
sleep.
Signed-off-by: Julien Grall
---
drivers/tty/sysrq.c | 6 +++---
1 f
(CC correctly linux-rt-users)
On 04/03/2019 17:20, 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/sysrq-trigger
[ 4432.073756] sysrq: SysRq : S
Hello Sebastian,
On 04/03/2019 22:01, Sebastian Andrzej Siewior wrote:
> On 2019-03-04 17:21:57 [+], Julien Grall wrote:
>> (CC correctly linux-rt-users)
>>
>> On 04/03/2019 17:20, Julien Grall wrote:
>>> At the moment show_lock is implemented usi
DR_T_64BIT above.
Cheers,
--
Julien Grall
.
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.
Cheers,
--
Julien Grall
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 Steve,
On 04/03/2019 23:15, Steven Rostedt wrote:
On Mon, 4 Mar 2019 22:25:41 +
Julien Grall wrote:
On 04/03/2019 22:01, Sebastian Andrzej Siewior wrote:
On 2019-03-04 17:21:57 [+], Julien Grall wrote:
(CC correctly linux-rt-users)
On 04/03/2019 17:20, Julien Grall wrote
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
Hi Oleksandr,
On 25/02/2019 13:24, Oleksandr Andrushchenko wrote:
On 2/22/19 3:33 PM, Julien Grall wrote:
Hi,
On 22/02/2019 12:38, Oleksandr Andrushchenko wrote:
On 2/20/19 10:46 PM, Julien Grall wrote:
Discussing with my team, a solution that came up would be to introduce one
atomic field
Hi Oleksandr,
On 25/02/2019 14:08, Oleksandr Andrushchenko wrote:
On 2/25/19 3:55 PM, Julien Grall wrote:
Hi Oleksandr,
On 25/02/2019 13:24, Oleksandr Andrushchenko wrote:
On 2/22/19 3:33 PM, Julien Grall wrote:
Hi,
On 22/02/2019 12:38, Oleksandr Andrushchenko wrote:
On 2/20/19 10:46 PM
Hi Roger,
On 26/02/2019 09:44, Roger Pau Monné wrote:
On Tue, Feb 26, 2019 at 09:30:07AM +, Andrew Cooper wrote:
On 26/02/2019 09:14, Roger Pau Monné wrote:
On Mon, Feb 25, 2019 at 01:55:42PM +, Julien Grall wrote:
Hi Oleksandr,
On 25/02/2019 13:24, Oleksandr Andrushchenko wrote
Hi,
On 26/02/2019 10:17, Roger Pau Monné wrote:
On Tue, Feb 26, 2019 at 10:03:38AM +, Julien Grall wrote:
Hi Roger,
On 26/02/2019 09:44, Roger Pau Monné wrote:
On Tue, Feb 26, 2019 at 09:30:07AM +, Andrew Cooper wrote:
On 26/02/2019 09:14, Roger Pau Monné wrote:
On Mon, Feb 25
(!list_is_last(>ap_list,
@@ -921,11 +921,11 @@ int kvm_vgic_vcpu_pending_irq(struct kvm_vcpu *vcpu)
spin_lock_irqsave(_cpu->ap_list_lock, flags);
list_for_each_entry(irq, _cpu->ap_list_head, ap_list) {
- spin_lock(>irq_lock);
+ raw_spin_lock(>irq_lock);
pending = irq_is_pending(irq) && irq->enabled &&
!irq->active &&
irq->priority < vmcr.pmr;
- spin_unlock(>irq_lock);
+ raw_spin_unlock(>irq_lock);
if (pending)
break;
@@ -963,11 +963,10 @@ bool kvm_vgic_map_is_active(struct kvm_vcpu *vcpu,
unsigned int vintid)
return false;
irq = vgic_get_irq(vcpu->kvm, vcpu, vintid);
- spin_lock_irqsave(>irq_lock, flags);
+ raw_spin_lock_irqsave(>irq_lock, flags);
map_is_active = irq->hw && irq->active;
- spin_unlock_irqrestore(>irq_lock, flags);
+ raw_spin_unlock_irqrestore(>irq_lock, flags);
vgic_put_irq(vcpu->kvm, irq);
return map_is_active;
}
-
--
Julien Grall
Hi Julia,
On 01/02/2019 17:36, Julia Cartwright wrote:
On Fri, Feb 01, 2019 at 03:30:58PM +, Julien Grall wrote:
Hi Julien,
On 07/01/2019 15:06, Julien Thierry wrote:
vgic_irq->irq_lock must always be taken with interrupts disabled as
it is used in interrupt context.
I am a
On 1/22/19 10:28 AM, Oleksandr Andrushchenko wrote:
Hello, Julien!
Hi,
On 1/21/19 7:09 PM, Julien Grall wrote:
Well, I didn't get the attributes of pages at the backend side, but IMO
those
do not matter in my use-case (for simplicity I am not using zero-copying at
backend side
Hello,
On 21/01/2019 12:43, Oleksandr Andrushchenko wrote:
On 1/18/19 1:43 PM, Julien Grall wrote:
On 18/01/2019 09:40, Oleksandr Andrushchenko wrote:
On 1/17/19 11:18 AM, Christoph Hellwig wrote:
On Wed, Jan 16, 2019 at 06:43:29AM +, Oleksandr Andrushchenko
wrote:
This whole issue
on non-LPAE kernel and don't see crash anymore:
Tested-by: Julien Grall
Regards,
> Changes in v9:
> - remove BUG_ON from the loop in dma_cache_maint;
> - add static inline for xen_dma_unmap_page, xen_dma_sync_single_for_cpu,
> xen_dma_sync_single_for_device;
> - map_
The Xen ARM API is stable since Xen 4.4 and everything has been
upstreamed in Linux for ARM and ARM64. Therefore we can drop "EXPERIMENTAL"
from the Xen option in the both Kconfig.
Signed-off-by: Julien Grall
Cc: Russell King
Cc: Catalin Marinas
Cc: Will Deacon
Cc: lin
the #ifdef CONFIG_HVC_XEN_FRONTEND earlier to only compile
xen_console_remove, xen_cons_free, xen_cons_disconnect_backend when it's
necessary.
Signed-off-by: Julien Grall
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: David Vrabel
Cc: Paul Gortmaker
Cc: Konrad Rzeszutek Wilk
---
drivers/tty/hvc
+= xen-acpi-pad.o
dom0-$(CONFIG_X86) += pcpu.o
obj-$(CONFIG_XEN_DOM0)+= $(dom0-y)
[..]
AFAIK, There is already a kernel patch exists to fix this issue. I
think Julien or Parth is a right person to ask. Hence I am CCed Julien
Grall too.
The ACPI support for Xen is no
On 22/03/2015 21:49, Rafael J. Wysocki wrote:
On Sunday, March 22, 2015 09:05:21 PM Julien Grall wrote:
Hello,
On 21/03/2015 12:09, Naresh Bhat wrote:
From 268dcdafa34a690e2f99c0784ca33a6d2352ecf5 Mon Sep 17 00:00:00 2001
From: Hanjun Guo mailto:hanjun@linaro.org>>
On 27/07/15 10:30, David Vrabel wrote:
> On 25/07/15 00:21, Julien Grall wrote:
>> On 24/07/2015 12:47, David Vrabel wrote:
>>> @@ -550,6 +551,11 @@ int alloc_xenballooned_pages(int nr_pages, struct
>>> page **pages)
>>> page = balloon_re
or not. It will always return
1 on ARM and keep the same behavior on x86.
This is also allow us to drop the usage of xen_have_vector_callback
entirely in the ARM code.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
Cc: Stefano Stabellini
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Konrad Rzeszutek Wilk
On 27/07/15 13:35, David Vrabel wrote:
> On 27/07/15 12:35, Julien Grall wrote:
>> Currently, the event channel rebind code is gated with the presence of
>> the vector callback.
>>
>> The virtual interrupt controller on ARM has the concept of per-CPU
>> interrup
or not. It will always return
1 on ARM and keep the same behavior on x86.
This is also allow us to drop the usage of xen_have_vector_callback
entirely in the ARM code.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
Cc: Stefano Stabellini
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Konrad Rzeszutek Wilk
701 - 800 of 1315 matches
Mail list logo
