The following commit has been merged into the irq/irqchip-next branch of
irqchip:
Commit-ID: 91f90daa4fb2b77db7aa25ef2e0206f2e3962665
Gitweb:
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms/91f90daa4fb2b77db7aa25ef2e0206f2e3962665
Author:Marc Zyngier
The following commit has been merged into the irq/irqchip-next branch of
irqchip:
Commit-ID: 3841245e8498a789c65dedd7ffa8fb2fee2c0684
Gitweb:
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms/3841245e8498a789c65dedd7ffa8fb2fee2c0684
Author:Marc Zyngier
The following commit has been merged into the irq/irqchip-next branch of
irqchip:
Commit-ID: 5fe71d271df8c05e1060c0184764eba18b17a96f
Gitweb:
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms/5fe71d271df8c05e1060c0184764eba18b17a96f
Author:Marc Zyngier
The following commit has been merged into the irq/irqchip-next branch of
irqchip:
Commit-ID: 34dd263fce3114147f21698f8e55e05b9e8185bd
Gitweb:
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms/34dd263fce3114147f21698f8e55e05b9e8185bd
Author:Marc Zyngier
Hi Yanan,
On 2020-12-11 08:01, Yanan Wang wrote:
In dirty-logging, or dirty-logging-stopped time, even normal running
time of a guest configed with huge mappings and numbers of vCPUs,
translation faults by different vCPUs on the same GPA could occur
successively almost at the same time. There
Hi Maxime,
On 2020-12-10 13:46, Maxime Ripard wrote:
The BCM2711 uses a number of instances of the bcmstb-l2 controller in
its
display engine. Let's allow the driver to be enabled through KConfig.
Signed-off-by: Maxime Ripard
---
drivers/irqchip/Kconfig | 2 +-
1 file changed, 1
On 2020-12-10 01:39, Joel Fernandes wrote:
[...]
Quentin and I have discussed potential ways of improving guest
scheduling
on terminally broken systems (otherwise known as big-little), in the
form of a capacity request from the guest to the host. I'm not really
keen on the host exposing its
py with this, and as it turns out, the crazy
system that has this SAS thing keeps my backside warm all year long.
As long as this machine keeps ticking, I'm happy to help with this.
So if that helps:
Acked-by: Marc Zyngier
We need to work out the merge strategy for the whole lot though, give
On 2020-12-09 12:44, Catalin Marinas wrote:
On Tue, Dec 08, 2020 at 06:21:12PM +, Marc Zyngier wrote:
On 2020-12-08 17:21, Catalin Marinas wrote:
> On Mon, Dec 07, 2020 at 07:03:13PM +0000, Marc Zyngier wrote:
> > I wonder whether we will have to have something kernel side to
Hi all,
On 2020-12-08 20:02, Joel Fernandes wrote:
On Fri, Sep 11, 2020 at 4:58 AM Sergey Senozhatsky
wrote:
My apologies for the slow reply.
On (20/08/17 13:25), Marc Zyngier wrote:
>
> It really isn't the same thing at all. You are exposing PV spinlocks,
> while Sergey exposes p
On Tue, 08 Dec 2020 19:14:47 +,
David Brazdil wrote:
>
> Hey Marc,
>
> On Thu, Dec 03, 2020 at 07:23:19PM +, Marc Zyngier wrote:
> > On Wed, 2 Dec 2020 18:40:56 +, David Brazdil wrote:
> > > As we progress towards being able to keep guest state private to
On 2020-12-08 17:21, Catalin Marinas wrote:
On Mon, Dec 07, 2020 at 07:03:13PM +, Marc Zyngier wrote:
On Mon, 07 Dec 2020 16:34:05 +,
Catalin Marinas wrote:
> On Mon, Dec 07, 2020 at 04:05:55PM +0000, Marc Zyngier wrote:
> > What I'd really like to see is a description of h
On 2020-12-08 14:24, David Brazdil wrote:
PSCI driver exposes a struct containing the PSCI v0.1 function IDs
configured in the DT. However, the struct does not convey the
information whether these were set from DT or contain the default value
zero. This could be a problem for PSCI proxy in KVM
On 2020-12-08 09:51, Haibo Xu wrote:
On Mon, 7 Dec 2020 at 22:48, Steven Price wrote:
[...]
Sounds like you are making good progress - thanks for the update. Have
you thought about how the PROT_MTE mappings might work if QEMU itself
were to use MTE? My worry is that we end up with MTE in
On 2020-12-08 09:43, Pingfan Liu wrote:
On Tue, Dec 8, 2020 at 5:31 PM Marc Zyngier wrote:
On 2020-12-08 09:21, Pingfan Liu wrote:
> Although there is a runtime WARN_ON() when NR_IPR > max SGI, it had
> better
> do the check during built time, and associate these related cod
per
Cc: Marc Zyngier
Cc: Mark Rutland
To: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
arch/arm64/kernel/smp.c| 2 ++
drivers/irqchip/irq-gic-v3.c | 2 +-
drivers/irqchip/irq-gic.c | 2 +-
include/linux/irqchip/arm-gic-common.h
On Mon, 07 Dec 2020 16:34:05 +,
Catalin Marinas wrote:
>
> On Mon, Dec 07, 2020 at 04:05:55PM +, Marc Zyngier wrote:
> > What I'd really like to see is a description of how shared memory
> > is, in general, supposed to work with MTE. My gut feeling is that
> >
On 2020-12-07 15:45, Steven Price wrote:
On 07/12/2020 15:27, Peter Maydell wrote:
On Mon, 7 Dec 2020 at 14:48, Steven Price
wrote:
Sounds like you are making good progress - thanks for the update.
Have
you thought about how the PROT_MTE mappings might work if QEMU itself
were to use MTE? My
On 2020-12-07 14:48, Steven Price wrote:
On 03/12/2020 17:07, Marc Zyngier wrote:
diff --git a/arch/arm64/include/asm/sysreg.h
b/arch/arm64/include/asm/sysreg.h
index e2ef4c2edf06..b6668ffa04d9 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -569,7
On 2020-12-07 15:08, Johan Hovold wrote:
On Mon, Dec 07, 2020 at 02:41:03PM +, Marc Zyngier wrote:
On 2020-12-07 14:01, Johan Hovold wrote:
> On Fri, Dec 04, 2020 at 04:47:35PM +0000, Marc Zyngier wrote:
>> Having recently tried to use the CBUS GPIOs that come thanks to the
>
On 2020-12-07 14:29, Johan Hovold wrote:
On Fri, Dec 04, 2020 at 04:47:38PM +, Marc Zyngier wrote:
The validity of the ftdi CBUS GPIO is pretty hidden so far,
and finding out *why* some GPIOs don't work is sometimes
hard to identify. So let's help the user by displaying the
map of the CBUS
On 2020-12-07 14:16, Johan Hovold wrote:
On Fri, Dec 04, 2020 at 04:47:36PM +, Marc Zyngier wrote:
When reporting the state of a GPIO to userspace, we never check
for the actual validity of the line, meaning we report invalid
lines as being usable. A subsequent request will fail though
On 2020-12-07 14:01, Johan Hovold wrote:
On Fri, Dec 04, 2020 at 04:47:35PM +, Marc Zyngier wrote:
Having recently tried to use the CBUS GPIOs that come thanks to the
ftdio_sio driver, it occurred to me that the driver has a couple of
usability issues:
- it advertises potential GPIOs
On 2020-12-07 11:58, Quentin Perret wrote:
On Monday 07 Dec 2020 at 11:16:05 (+), Fuad Tabba wrote:
On Fri, Dec 4, 2020 at 6:01 PM Quentin Perret
wrote:
>
> On Thursday 03 Dec 2020 at 12:57:33 (+), Fuad Tabba wrote:
>
> > > +int hyp_create_idmap(void);
> > > +int
On 2020-12-07 09:09, Ard Biesheuvel wrote:
(+ Marc)
On Fri, 4 Dec 2020 at 12:14, Will Deacon wrote:
On Fri, Dec 04, 2020 at 09:44:43AM +0800, Wei Li wrote:
> For the memory hole, sparse memory model that define SPARSEMEM_VMEMMAP
> do not free the reserved memory for the page map, decrease
On 2020-12-06 15:02, Linus Walleij wrote:
On Sat, Dec 5, 2020 at 11:15 PM Serge Semin
wrote:
Hmm, that sounds like a problem, but the explanation is a bit unclear
to me. AFAICS you are saying that the only callbacks which are
called during the IRQ request/release are the irq_enable(), right?
n + 1)."
With that:
Acked-by: Marc Zyngier
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Now that the code code can track the validity of GPIO pins,
there is no need to check whether the line is valid.
Signed-off-by: Marc Zyngier
---
drivers/usb/serial/ftdi_sio.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
: unnamed kernel input active-high [used]
line 3: unnamed unused input active-high
In this example, lines 1 and 2 are invalid, and cannot be used by
userspace.
Signed-off-by: Marc Zyngier
---
drivers/gpio/gpiolib-cdev.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Since it is pretty common for only some of the CBUS lines to be
valid as GPIO lines, let's report such validity to the rest of
the kernel.
Signed-off-by: Marc Zyngier
---
drivers/usb/serial/ftdi_sio.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/usb/serial
appear: https://github.com/richardeoin/ftx-prog
Suggested-by: Linus Walleij
Signed-off-by: Marc Zyngier
---
drivers/usb/serial/ftdi_sio.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 13e575f16bcd..b9d3b33891fc
boot). It is a bit sad that there next to no documentation
on how to use these CBUS pins.
- Drop the error reporting code, which has become useless at this
point.
Tested with a couple of FTDI devices (FT230X and FT231X) and various
CBUS configurations.
Marc Zyngier (4):
gpiolib: cdev: Flag
Hi Stephen,
On 2020-12-04 05:44, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the kvm-arm tree got a conflict in:
arch/arm64/kernel/head.S
between commits:
2ffac9e3fdbd ("arm64: head.S: cleanup SCTLR_ELx initialization")
d87a8e65b510 ("arm64: head.S: always initialize
On Wed, 2 Dec 2020 18:40:56 +, David Brazdil wrote:
> As we progress towards being able to keep guest state private to the
> host running nVHE hypervisor, this series allows the hypervisor to
> install itself on newly booted CPUs before the host is allowed to run
> on them.
>
> All
On Mon, 17 Aug 2020 19:07:26 +0800, Keqian Zhu wrote:
> During picking up pvtime LPT support for arm64, I do some trivial fixes for
> pvtime ST.
>
> change log:
>
> v2:
> - Add Andrew's and Steven's R-b.
> - Correct commit message of the first patch.
> - Drop the second patch.
>
> [...]
diff --git a/arch/arm64/include/asm/sysreg.h
b/arch/arm64/include/asm/sysreg.h
index e2ef4c2edf06..b6668ffa04d9 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -569,7 +569,8 @@
#define SCTLR_ELx_M(BIT(0))
#define SCTLR_ELx_FLAGS(SCTLR_ELx_M
On 2020-08-17 12:07, Keqian Zhu wrote:
Rename PV_FEATURES to PV_TIME_FEATURES.
Signed-off-by: Keqian Zhu
Reviewed-by: Andrew Jones
Reviewed-by: Steven Price
---
Documentation/virt/kvm/arm/pvtime.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
write_sysreg(cval, cntp_cval_el0);
} else {
- cval = evt + arch_counter_get_cntvct();
+ cval = evt + arch_counter_get_cntvct_stable();
write_sysreg(cval, cntv_cval_el0);
}
With that fixed:
Acked-by: Marc Zyngier
This shoul
, then virtual counter trigger an event for
every
two cycles.
Fixes: 037f637767a8 ("drivers: clocksource: add support for
ARM architected timer event stream")
Fixes: tags should on a single line.
Suggested-by: Marc Zyngier
Signed-off-by: Keqian Zhu
---
drivers/c
A couple of cosmetic comments below, none of which require immediate
addressing.
[...]
diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
new file mode 100644
index ..61375d4571c2
--- /dev/null
+++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
@@ -0,0
On 2020-12-02 18:41, David Brazdil wrote:
Add handler of host SMCs in KVM nVHE trap handler. Forward all SMCs to
EL3 and propagate the result back to EL1. This is done in preparation
for validating host SMCs in KVM protected mode.
The implementation assumes that firmware uses SMCCC v1.2 or
On 2020-12-03 11:25, Rongwei Wang wrote:
2020年12月3日 下午4:35，Marc Zyngier 写道：
[...]
But what does it mean to change random system registers while the
kernel
itself is using them in parallel? All you are introducing is a bunch
of
uncontrolled, unexpected, and possibly fatal side effects
On 2020-12-03 05:45, Rongwei Wang wrote:
2020年12月1日 下午11:37，Marc Zyngier 写道：
On 2020-12-01 14:25, wangrongwei wrote:
2020年12月1日 下午4:12，Marc Zyngier 写道：
On 2020-12-01 03:09, wangrongwei wrote:
Hi
We have validate this driver in vm and physical machine, and works
fine.
But what does "
On Wed, 2 Dec 2020 04:10:31 +0800, Yanan Wang wrote:
> When installing a new pte entry or updating an old valid entry in stage 2
> translation, we use get_page()/put_page() to record page_count of the
> page-table
> pages. PATCH 1/3 aims to fix incorrect use of get_page()/put_page() in stage
>
Hi Yanan,
[...]
BTW: there are two more things below that I want to talk about.
1. Recently, I have been focusing on the ARMv8.4-TTRem feature which
is aimed at changing block size in stage 2 mapping.
I have a plan to implement this feature for stage 2 translation when
splitting a block
On 2020-12-01 16:57, Will Deacon wrote:
On Fri, Nov 27, 2020 at 06:16:35PM +, Marc Zyngier wrote:
On 2020-11-27 17:24, Quentin Perret wrote:
> On Friday 27 Nov 2020 at 17:14:11 (+), Marc Zyngier wrote:
[...]
> > Yeah, the sanitized read feels better, if only because that is
On 2020-12-01 14:25, wangrongwei wrote:
2020年12月1日 下午4:12，Marc Zyngier 写道：
On 2020-12-01 03:09, wangrongwei wrote:
Hi
We have validate this driver in vm and physical machine, and works
fine.
But what does "work fine" mean? None of these system registers are
supposed
to be acces
Hi Yanan,
On 2020-12-01 14:11, wangyanan (Y) wrote:
On 2020/12/1 21:46, Will Deacon wrote:
On Tue, Dec 01, 2020 at 10:30:41AM +0800, wangyanan (Y) wrote:
[...]
The point is at b.iii where the TLBI is not enough. There are many
page
mappings that we need to merge into a block mapping.
We
On 2020-12-01 14:23, Will Deacon wrote:
On Tue, Dec 01, 2020 at 02:05:03PM +, Marc Zyngier wrote:
On 2020-12-01 13:46, Will Deacon wrote:
> diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> index 0271b4a3b9fe..12526d8c7ae4 100644
> --- a/arch/arm64/kvm/hyp/
On 2020-12-01 13:46, Will Deacon wrote:
On Tue, Dec 01, 2020 at 10:30:41AM +0800, wangyanan (Y) wrote:
On 2020/12/1 0:01, Will Deacon wrote:
> On Mon, Nov 30, 2020 at 11:24:19PM +0800, wangyanan (Y) wrote:
> > On 2020/11/30 21:34, Will Deacon wrote:
> > > On Mon, Nov 30, 2020 at 08:18:46PM
On 2020-12-01 11:40, Shenming Lu wrote:
On 2020/12/1 18:55, Marc Zyngier wrote:
On 2020-11-30 07:23, Shenming Lu wrote:
Hi Shenming,
We are pondering over this problem these days, but still don't get a
good solution...
Could you give us some advice on this?
Or could we move the restoring
On 2020-12-01 09:38, luojiaxing wrote:
On 2020/11/28 18:18, Marc Zyngier wrote:
On Sat, 28 Nov 2020 07:19:48 +,
luojiaxing wrote:
How can you confirm that the interrupt pending status is the latest?
Is it possible that the interrupt pending status is still cached in
the GICR
On 2020-11-30 07:23, Shenming Lu wrote:
Hi Shenming,
We are pondering over this problem these days, but still don't get a
good solution...
Could you give us some advice on this?
Or could we move the restoring of the pending states (include the sync
from guest RAM and the transfer to HW) to
On 2020-12-01 03:09, wangrongwei wrote:
Hi
We have validate this driver in vm and physical machine, and works
fine.
But what does "work fine" mean? None of these system registers are
supposed
to be accessible from userspace, so please explain *what* you are trying
to
do with this, other
On 2020-11-30 17:48, Rongwei Wang wrote:
The interfaces of this module is same as MSR module in user space, and
to solve
the problem that ARM platform has no similar MSR module. Using this
interface,
we did some pressure tests to test the stability and security of MSR
driver. The
test results
Hi Shameer,
On 2020-11-30 13:55, Shameerali Kolothum Thodi wrote:
Hi Marc,
-Original Message-
From: Marc Zyngier [mailto:m...@kernel.org]
Sent: 30 November 2020 12:28
To: Shameerali Kolothum Thodi
Cc: linux-kernel@vger.kernel.org;
linux-arm-ker...@lists.infradead.org;
eric.au
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 4615fbc3788ddc8e7c6d697714ad35a53729aa2c
Gitweb:
https://git.kernel.org/tip/4615fbc3788ddc8e7c6d697714ad35a53729aa2c
Author:Marc Zyngier
AuthorDate:Sun, 29 Nov 2020 13:55:51
Committer
On 2020-11-30 12:06, Shameerali Kolothum Thodi wrote:
Hi Zenghui,
-Original Message-
From: yuzenghui
Sent: 30 November 2020 11:51
To: Shameerali Kolothum Thodi ;
linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Cc: m...@kernel.org; Linuxarm ;
eric.au...@redhat.com
On 2020-11-30 12:12, Shenming Lu wrote:
On 2020/11/30 19:22, Marc Zyngier wrote:
On 2020-11-28 14:18, Shenming Lu wrote:
In order to further reduce the impact of the wait delay of the
VPT analysis, we can delay the execution of the polling on the
GICR_VPENDBASER.Dirty bit (call it from
Hi Shameer,
On 2020-11-30 10:26, Shameer Kolothum wrote:
At present, the support for GICv2 backward compatibility on GICv3/v4
hardware is determined based on whether DT/ACPI provides a memory
mapped phys base address for GIC virtual CPU interface register(GICV).
This creates a problem that a
On 2020-11-29 13:55, Marc Zyngier wrote:
When an interrupt allocation fails for N interrupts, it is pretty
common for the error handling code to free the same number of
interrupts,
no matter how many interrupts have actually been allocated.
This may result in the domain freeing code
On 2020-11-28 14:18, Shenming Lu wrote:
In order to further reduce the impact of the wait delay of the
VPT analysis, we can delay the execution of the polling on the
GICR_VPENDBASER.Dirty bit (call it from kvm_vgic_flush_hwstate()
corresponding to vPE resident), let the GIC and the CPU work in
The following commit has been merged into the irq/urgent branch of tip:
Commit-ID: 509920aee72ae23235615a009c5148cdb38794c3
Gitweb:
https://git.kernel.org/tip/509920aee72ae23235615a009c5148cdb38794c3
Author:Marc Zyngier
AuthorDate:Sat, 28 Nov 2020 10:37:07
Committer
[- jason]
On 2020-11-30 03:30, Biwen Li wrote:
From: Hou Zhiqiang
Add an new IRQ chip declaration for LS1043A and LS1088A
- compatible "fsl,ls1043a-extirq" for LS1043A, LS1046A.
- compatible "fsl,ls1088a-extirq" for LS1088A, LS208xA, LX216xA
Signed-off-by: Hou Zhiqiang
Signed-off-by: Biwen
no mapping in that domain. Things end pretty
badly.
Instead, add some checks to irq_domain_free_irqs_hierarchy() to make
sure that we don't follow the hierarchy if no mapping exists for
a given interrupt.
Signed-off-by: Marc Zyngier
---
kernel/irq/irqdomain.c | 10 --
1 file changed, 8
Zidenberg
Cc: Antoine Tenart
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-alpine-msi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-alpine-msi.c b/drivers/irqchip/irq-alpine-msi.c
index 23a3b877f7f1..ede02dc2bcd0 100644
--- a/drivers/irqchip/
advertized by the platform-MSI code when allocating an irqdomain
for a device.
Signed-off-by: Marc Zyngier
---
drivers/base/platform-msi.c | 7 +++
include/asm-generic/msi.h | 4
2 files changed, 11 insertions(+)
diff --git a/drivers/base/platform-msi.c b/drivers/base/platform-msi.c
index
The ITS already has some notion of "shared" devices. Let's map the
MSI_ALLOC_FLAGS_PROXY_DEVICE flag onto this internal property.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3-its.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/irqchip/irq-gic-v3-its.c
An aliasing PCI bridge is another case where we should flag the
corresponding allocation as "proxied", as MSIs are coming with
the bridge's RID, and not the originating device's.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3-its-pci-msi.c | 11 ---
1 file
ystem.
Subsequent patches add handling of this new flag in the GICv3 ITS
(though there may be scope for something more generic in the case of
the last patch).
Marc Zyngier (3):
platform-msi: Track shared domain allocation
irqchip/gic-v3-its: Tag ITS device as shared if allocating for a proxy
dev
On 2020-11-27 18:56, Catalin Marinas wrote:
On Fri, Nov 27, 2020 at 06:11:01PM +, Marc Zyngier wrote:
On 2020-11-27 14:15, Hanks Chen wrote:
> Support for interrupt distribution design for SMP system solutions.
As far as I know, we have been supporting interrupt distribution on
ARM
Hesselbarth
Cc: Gregory Clement
Cc: Thomas Gleixner
Cc: Thomas Petazzoni
Signed-off-by: Marc Zyngier
---
CREDITS | 5 +
MAINTAINERS | 4
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/CREDITS b/CREDITS
index 8592e45e3932..cf112d3e9382 100644
--- a/CREDITS
+++ b/CREDITS
On Sat, 28 Nov 2020 07:19:48 +,
luojiaxing wrote:
>
> Hi, shenming
>
>
> I got few questions about this patch.
>
> Although it's a bit late and not very appropriate, I'd like to ask
> before you send next version.
>
> On 2020/11/23 14:54, Shenming Lu wrote:
> > From: Zenghui Yu
> >
> >
Shenming,
Somehow this patch ended up in the wrong folder.
Apologies for the delay reviewing it.
On 2020-09-23 07:35, Shenming Lu wrote:
Right after a vPE is made resident, the code starts polling the
GICR_VPENDBASER.Dirty bit until it becomes 0, where the delay_us
is set to 10. But in our
On 2020-11-27 14:15, Hanks Chen wrote:
Disable irq on cpu shutdown flow to ensure interrupts
did not bother this cpu after status as offline.
To avoid suspicious RCU usage
(0)[0:swapper/0]RCU used illegally from offline CPU! ...
(0)[0:swapper/0]lockdep: [name:lockdep&]cpu_id = 0, cpu_is_offline
On 2020-11-27 17:24, Quentin Perret wrote:
On Friday 27 Nov 2020 at 17:14:11 (+), Marc Zyngier wrote:
[...]
Yeah, the sanitized read feels better, if only because that is
what we are going to read in all the valid cases, unfortunately.
read_sanitised_ftr_reg() is sadly not designed
On 2020-11-27 14:15, Hanks Chen wrote:
Support for interrupt distribution design for SMP system solutions.
As far as I know, we have been supporting interrupt distribution on
ARM SMP systems pretty well for the past... what... 15 years?
I'm sure Russell can dig out an ARM926 SMP system that
On 2020-11-27 11:53, Will Deacon wrote:
On Fri, Nov 27, 2020 at 10:26:47AM +, Marc Zyngier wrote:
On 2020-11-24 15:50, Will Deacon wrote:
> If a vCPU is caught running 32-bit code on a system with mismatched
> support at EL0, then we should kill it.
>
> Acked-by: Marc Zyngier
On 2020-11-27 12:45, John Garry wrote:
On 27/11/2020 09:57, Marc Zyngier wrote:
If I understand the code correctly, MSI_ALLOC_FLAGS_SHARED_DEVICE is
supposed to be set in info->flags in platform_msi_set_desc(), but
this
is called per-msi after its_msi_prepare(), so we don't the flags
On 2020-11-24 15:50, Will Deacon wrote:
If a vCPU is caught running 32-bit code on a system with mismatched
support at EL0, then we should kill it.
Acked-by: Marc Zyngier
Signed-off-by: Will Deacon
---
arch/arm64/kvm/arm.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion
On 2020-11-24 15:50, Will Deacon wrote:
When confronted with a mixture of CPUs, some of which support 32-bit
applications and others which don't, we quite sensibly treat the system
as 64-bit only for userspace and prevent execve() of 32-bit binaries.
Unfortunately, some crazy folks have decided
On 2020-11-26 16:52, John Garry wrote:
Hi Marc,
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=irq/hacks
ok, I'll have a look
I tried that and it doesn't look to work.
I find that for the its_msi_prepare() call, its_dev->shared does not
get set, as
On 2020-11-26 15:57, Matthew Wilcox wrote:
On Thu, Nov 26, 2020 at 03:53:58PM +, David Brazdil wrote:
The hypervisor starts trapping host SMCs and intercepting host's PSCI
CPU_ON/SUSPEND calls. It replaces the host's entry point with its own,
initializes the EL2 state of the new CPU and
Hi John,
On 2020-11-26 10:47, John Garry wrote:
Hi Marc,
Right, I did consider this.
FWIW, I've pushed my hack branch[1]
Did you miss that reference?
I did:
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=irq/hacks
out with a couple of patches
for you
On 2020-11-25 17:20, John Garry wrote:
Add a function to tear down the work which was done in
platform_get_irq()
for when the device driver is done with the irq.
For ACPI companion devices the irq resource is set as disabled, as this
resource is configured from
On 2020-11-24 17:38, John Garry wrote:
Hi Marc,
So initially in the msi_prepare method we setup the its dev - this is
from the mbigen probe. Then when all the irqs are unmapped later for
end device driver removal, we release this its device in
its_irq_domain_free(). But I don't see anything to
On 2020-11-25 16:24, Laurent Vivier wrote:
On 25/11/2020 17:05, Denis Kirjanov wrote:
On 11/25/20, Laurent Vivier wrote:
With virtio multiqueue, normally each queue IRQ is mapped to a CPU.
But since commit 0d9f0a52c8b9f ("virtio_scsi: use virtio IRQ
affinity")
this is broken on pseries.
On 2020-11-25 14:09, Laurent Vivier wrote:
On 25/11/2020 14:20, Thomas Gleixner wrote:
Laurent,
On Wed, Nov 25 2020 at 12:16, Laurent Vivier wrote:
The proper subsystem prefix is: 'genirq/irqdomain:' and the first
letter
after the colon wants to be uppercase.
Ok.
This function adds an
On 2020-11-25 13:26, David Brazdil wrote:
I came up with the following patch on top of this series that seems to
compile without issue.
That seems to have an implicit dependency of sysreg.h on memory.h,
doesn't it?
I had it the other way round initially. I also tried including memory.h
in
On 2020-11-25 10:31, David Brazdil wrote:
On Mon, Nov 23, 2020 at 01:52:54PM +, Marc Zyngier wrote:
On Mon, 16 Nov 2020 20:42:58 +,
David Brazdil wrote:
>
> KVM currently initializes MAIR_EL2 to the value of MAIR_EL1. In
> preparation for initializing MAIR_EL2 before MAIR_
On 2020-11-25 10:39, David Brazdil wrote:
On Mon, Nov 23, 2020 at 02:20:07PM +, Marc Zyngier wrote:
[...]
> +
> + /*
> + * Flush the init params from the data cache because the struct will
> + * be read while the MMU is off.
> + */
> + __flush_dcache_area(para
On 2020-11-24 16:26, Peter Zijlstra wrote:
On Tue, Nov 24, 2020 at 02:14:45PM +, Marc Zyngier wrote:
Some interrupts (such as the rescheduling IPI) rely on not going
through
the irq_enter()/irq_exit() calls. To distinguish such interrupts, add
a new IRQ flag that allows the low-level
On 2020-11-23 15:45, John Garry wrote:
Hi John,
But it looks like there is more to it than that, which I'm worried is
far from non-trivial. For example, just calling irq_dispose_mapping()
for removal and then plaform_get_irq()->acpi_get_irq() second time
fails as it looks like more tidy-up is
this. It will do the wrong
thing on normal interrupts. Note that this is a band-aid until we can
move to some more correct infrastructure (such as kernel/entry/common.c).
Signed-off-by: Marc Zyngier
---
include/linux/irq.h | 2 ++
kernel/irq/Kconfig| 3 +++
kernel/irq/debugfs.c | 1 +
kernel/irq
Some arch-specific flags need to be set/cleared, but not exposed to
random device drivers. Introduce a new helper (__irq_modify_status())
that takes an arbitrary mask, and rewrite irq_modify_status() to use
this new helper.
No functionnal change.
Signed-off-by: Marc Zyngier
---
include/linux
Flag the rescheduling IPI as 'raw', making sure such interrupt
skips both tick management and irqtime accounting.
Signed-off-by: Marc Zyngier
---
arch/arm64/Kconfig | 1 +
arch/arm64/kernel/smp.c | 4
2 files changed, 5 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64
IRQ_HIDDEN was probably the wrong name, so let's rename it to IRQ_IPI,
which more accurately describe an IPI with special arch code handling.
Signed-off-by: Marc Zyngier
---
arch/arm/kernel/smp.c | 2 +-
arch/arm64/kernel/smp.c | 2 +-
include/linux/irq.h | 4 ++--
kernel/irq/debugfs.c
IRQ_HIDDEN is hardly a flag generic code should use, so let's
drop it from IRQF_MODIFY_MASK. In turn, update both arm and arm64
to use __irq_modify_status() when setting this flag.
Signed-off-by: Marc Zyngier
---
arch/arm/kernel/smp.c | 2 +-
arch/arm64/kernel/smp.c | 2 +-
include/linux
Flag the rescheduling IPI as 'raw', making sure such interrupt
skips both tick management and irqtime accounting.
Signed-off-by: Marc Zyngier
---
arch/arm/Kconfig | 1 +
arch/arm/kernel/smp.c | 4
2 files changed, 5 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
to IRQ_IPI
- Applied the same workaround to 32bit ARM for completeness
[1] https://lore.kernel.org/r/20201101131430.257038-1-...@kernel.org/
[2] https://lore.kernel.org/r/87lfewnmdz@nanos.tec.linutronix.de/
Marc Zyngier (6):
genirq: Add __irq_modify_status() helper to clear/set special flag
601 - 700 of 9391 matches
Mail list logo
