All the usage of the field pfn are done using the same idiom:
pfn_to_page(grant->pfn)
This will return always the same page. Store directly the page in the
grant to clean up the code.
Signed-off-by: Julien Grall
Acked-by: Roger Pau Monné
Reviewed-by: Stefano Stabellini
---
Cc: Kon
On 30/09/15 11:45, Julien Grall wrote:
> Many PV drivers contain the idiom:
>
> pfn = page_to_gfn(...) /* Or similar */
> gnttab_grant_foreign_access_ref
>
> Replace it by a new helper. Note that when Linux is using a different
> page granularity than Xen, the helper onl
The console ring is always based on the page granularity of Xen.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: David Vrabel
Cc: Boris Ostrovsky
Cc: linuxppc-...@lists.ozlabs.org
Changes in v4:
- The ring is always 4K
With 64KB page granularity support, the frame number will be different.
It will be easier to modify the behavior in a single place rather than
in each caller.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Cc: Russell King
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc
64KB page granularity).
Furthermore, in the case of persistent grants we allocate one Linux page
per grant although only the first 4KB of the page will be effectively
in use. This could be improved by sharing the page with multiple grants.
Signed-off-by: Julien Grall
Acked-by: Roger Pau Monné
n the grant table code.
Note that we allocate a Linux page for each rx skb but only the first
4KB is used. We may improve the memory usage by extending the size of
the rx skb.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc
lying on the grant table
code.
Note that the grant table code is allocating a Linux page per grant
which will result to waste 6OKB for every grant when Linux is using 64KB
page granularity. This could be improved by sharing the page between
multiple grants.
Signed-off-by: Julien Grall
Acked-by: &
e are very
minimal because we only need to check the first Xen PFN.
Note that it may be possible to optimize the function
check_page_physically_contiguous to avoid looping over every Xen PFN
for local memory. Although I will let this optimization for a follow-up.
Signed-off-by: Julien Grall
R
the
extent_order field to directly allocate/free chunk of the Linux page
size.
Note that PVMMU is only used for PV guest (which is x86) and the page
granularity is always 4KB. Some BUILD_BUG_ON has been added to ensure
that because the code has not been modified.
Signed-off-by: Julien Grall
page even though only the
first 4KB is used. I don't think this is really important for now as it
helps to have the pointer 4KB aligned (XENMEM_add_to_physmap is taking a
Xen PFN).
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Cc: Russell King
Stefano, I've dr
chunk). That would require more care when we fail to expand the
event channel.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
Reviewed-by: Stefano Stabellini
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Note I haven't updated the suggestion to reduce the memory
ng on the grant table code.
Signed-off-by: Julien Grall
Reviewed-by: Wei Liu
---
Cc: Ian Campbell
Cc: net...@vger.kernel.org
Improvement such as support of 64KB grant is not taken into
consideration in this patch because we have the requirement to run a
Linux using 64KB pages on a non-modifie
multiple
grant. It will require some care with the {Set,Clear}ForeignPage macro.
Note that no changes has been made in the x86 code because both Linux
and Xen will only use 4KB page granularity.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
Reviewed-by: Stefano Stabellini
---
Cc: Stefano
All the ring (xenstore, and PV rings) are always based on the page
granularity of Xen.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
Reviewed-by: Stefano Stabellini
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Changes in v3:
- Fix errors reported by checkpatch.pl
will have
to map multiple Xen PFN in a single Linux page.
Note that this solution works on page granularity which is a multiple of
4KB.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
I kept the hypercall arguments in remap_data to
On 30/09/15 12:32, Mark Rutland wrote:
> On Wed, Sep 30, 2015 at 11:45:15AM +0100, Julien Grall wrote:
>> Hi all,
>
> Hi,
>
>> ARM64 Linux is supporting both 4KB and 64KB page granularity. Although, Xen
>> hypercall interface and PV protocol are always based on 4
hence why I think this was unnoticed.
I will see if I can reproduce it and send a patch.
Cheers,
--
Julien Grall
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
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
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
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
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
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
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
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
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
DMA
will not be coherent for the grant-table. Oleksandr, do you know why
they can't be coherent?
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
.
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
] ---[ end 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,
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,
On
-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, i
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/includ
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/includ
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, i
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
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 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):
n
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(
y attribute you use 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
ine, we need to
@@ -780,7 +780,7 @@ static void vgic_flush_lr_state(struct kvm_vcpu *vcpu)
* the AP list has been sorted already.
*/
if (multi_sgi && irq->priority > prio) {
- spin_unlock(&irq->irq_lock);
+ _raw_spin_unlock(&irq->irq_lock);
break;
}
@@ -791,7 +791,7 @@ static void vgic_flush_lr_state(struct kvm_vcpu *vcpu)
prio = irq->priority;
}
- spin_unlock(&irq->irq_lock);
+ raw_spin_unlock(&irq->irq_lock);
if (count == kvm_vgic_global_state.nr_lr) {
if (!list_is_last(&irq->ap_list,
@@ -921,11 +921,11 @@ int kvm_vgic_vcpu_pending_irq(struct kvm_vcpu *vcpu)
spin_lock_irqsave(&vgic_cpu->ap_list_lock, flags);
list_for_each_entry(irq, &vgic_cpu->ap_list_head, ap_list) {
- spin_lock(&irq->irq_lock);
+ raw_spin_lock(&irq->irq_lock);
pending = irq_is_pending(irq) && irq->enabled &&
!irq->active &&
irq->priority < vmcr.pmr;
- spin_unlock(&irq->irq_lock);
+ raw_spin_unlock(&irq->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->irq_lock, flags);
+ raw_spin_lock_irqsave(&irq->irq_lock, flags);
map_is_active = irq->hw && irq->active;
- spin_unlock_irqrestore(&irq->irq_lock, flags);
+ raw_spin_unlock_irqrestore(&irq->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 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 ba
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
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 additi
, 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
ARM_PSCI_FW is not selected? Is it possible to
have a .config for RCAR without ARM_PSCI_FW?
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 by the
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
-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
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
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
:
* 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
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
-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 in
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
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 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 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
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 of
commit message 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
So I am 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 p
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 using spin
est. So the returned DMA address may
be 64-bit. Hence why we select DMA_ADDR_T_64BIT above.
Cheers,
--
Julien Grall
chine with a larger phys_addr_t
than dma_addr_t but wouldn't need to bother.
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 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:
At
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
0.032591] [] do_one_initcall+0x38/0x130
[0.032783] [] kernel_init_freeable+0xe0/0x248
[0.032995] [] kernel_init+0x10/0x100
[0.033172] [] ret_from_fork+0x10/0x50
Reported-by: Wei Chen
Link: https://lkml.org/lkml/2016/11/28/669
Signed-off-by: Julien Grall
Cc: sta...@vger.kernel.org
---
I have
I don't feel strongly about this either - I think this patch is good
enough. I'll apply to xentip.
I think this patch should be backported to stable trees because the
issue could appear depending on the compiler.
Cheers,
--
Julien Grall
nt32_t" it is a bit weird to use "int" to define xen_vcpu_id
(see patch #3).
Regards,
--
Julien Grall
Hello,
On 25/07/16 14:39, Vitaly Kuznetsov wrote:
Julien Grall writes:
Hi David,
On 25/07/16 13:38, David Vrabel wrote:
On 30/06/16 16:56, Vitaly Kuznetsov wrote:
It may happen that Xen's and Linux's ideas of vCPU id diverge. In
particular, when we crash on a secondary vCPU we m
Hi Juergen,
On 22/06/16 08:03, Juergen Gross wrote:
Add support for the Xen HYPERVISOR_vm_assist hypercall.
Signed-off-by: Juergen Gross
Reviewed-by: Julien Grall
Regards,
---
arch/arm/include/asm/xen/hypercall.h | 1 +
arch/arm/xen/enlighten.c | 1 +
arch/arm/xen
ee(NULL) is benign.
Signed-off-by: Julien Grall
Acked-by: Mark Rutland
---
drivers/perf/arm_pmu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
index 95614d2..1b8304e 100644
--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -104
obody is using dn
between the first and second call to of_node_put.
Signed-off-by: Julien Grall
Acked-by: Mark Rutland
---
drivers/perf/arm_pmu.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
index f2d01d4..6401f0c 100644
Hello all,
This patch series contains a series of small bug fixes for the arm_pmu
drivers.
I think all the patch should be backported to stable but I have not figured
out up to which version.
Julien Grall (3):
drivers/perf: arm_pmu: Fix reference count of a device_node in
of_pmu_irq_cfg
setting of __oprofile_cpu_pmu when the PMU is fully
initialized (i.e when it is no longer possible to fail).
Signed-off-by: Julien Grall
Acked-by: Mark Rutland
---
drivers/perf/arm_pmu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/perf/arm_pmu.c b/drivers/perf
.032229] [] __alloc_percpu+0x18/0x20
[0.032409] [] xen_guest_init+0x174/0x2f4
[0.032591] [] do_one_initcall+0x38/0x130
[0.032783] [] kernel_init_freeable+0xe0/0x248
[0.032995] [] kernel_init+0x10/0x100
[ 0.033172] [] ret_from_fork+0x10/0x50
--
Julien Grall
initialize and zeroed for you the structure at each loop. I.e
for (i = 0; i < count; i++) {
struct xen_add_to_physmap_range xapt = ....
}
Cheers,
--
Julien Grall
On 28/11/16 15:29, t...@kernel.org wrote:
Hello,
Hello,
On Mon, Nov 28, 2016 at 11:59:15AM +, Julien Grall wrote:
commit 3ca45a46f8af8c4a92dd8a08eac57787242d5021
percpu: ensure the requested alignment is power of two
It would have been useful to specify the tree used. In this case
501 - 600 of 727 matches
Mail list logo
