On Wed, 04 Sep 2024 17:17:58 +0100,
Will Deacon wrote:
>
> On Wed, Sep 04, 2024 at 01:55:03PM +0100, Joey Gouly wrote:
> > On Wed, Sep 04, 2024 at 12:43:02PM +0100, Will Deacon wrote:
> > > Right, there's quite a lot I need to do:
> > >
> > > - Uncorrupt your patches
> > > - Fix the conflict in
On Fri, 30 Aug 2024 10:05:22 +0100,
Will Deacon wrote:
>
> Hey Marc,
>
> On Fri, Aug 30, 2024 at 09:01:18AM +0100, Marc Zyngier wrote:
> > On Fri, 23 Aug 2024 14:48:11 +0100,
> > Will Deacon wrote:
> > >
> > > On Thu, Aug 22, 2024 at 04:10:51PM +0100
> >
> > Signed-off-by: Joey Gouly
> > Cc: Marc Zyngier
> > Cc: Oliver Upton
> > Cc: Catalin Marinas
> > Cc: Will Deacon
> > Reviewed-by: Marc Zyngier
> > ---
> > arch/arm64/include/asm/kvm_asm.h | 3 ++-
> > arch/arm64/kv
uction.
> >
> > Signed-off-by: Joey Gouly
> > Cc: Marc Zyngier
> > Cc: Oliver Upton
> > Cc: Catalin Marinas
> > Cc: Will Deacon
> > Reviewed-by: Marc Zyngier
> > ---
> > arch/arm64/include/asm/kvm_asm.h | 3 ++-
> > arc
> >
> > Signed-off-by: Joey Gouly
> > Cc: Marc Zyngier
> > Cc: Oliver Upton
> > Cc: Catalin Marinas
> > Cc: Will Deacon
> > Reviewed-by: Marc Zyngier
> > ---
> > arch/arm64/include/asm/kvm_asm.h | 3 ++-
> > arch/arm64/kv
On Fri, 26 Jul 2024 16:51:11 -0700, Sean Christopherson wrote:
> Disallow copying MTE tags to guest memory while KVM is dirty logging, as
> writing guest memory without marking the gfn as dirty in the memslot could
> result in userspace failing to migrate the updated page. Ideally (maybe?),
> KVM
On Fri, 26 Jul 2024 16:51:10 -0700, Sean Christopherson wrote:
> Put the page reference acquired by gfn_to_pfn_prot() if
> kvm_vm_ioctl_mte_copy_tags() runs into ZONE_DEVICE memory. KVM's less-
> than-stellar heuristics for dealing with pfn-mapped memory means that KVM
> can get a page reference t
On Fri, 16 Aug 2024 16:13:01 +0100,
Joey Gouly wrote:
>
> On Fri, Aug 16, 2024 at 03:55:11PM +0100, Marc Zyngier wrote:
> > On Fri, 03 May 2024 14:01:25 +0100,
> > Joey Gouly wrote:
> > >
> > > + if (!kvm_has_feat(kvm, ID_AA64MMFR3_EL1, S1POE, IMP))
> &
On Fri, 03 May 2024 14:01:25 +0100,
Joey Gouly wrote:
>
> Define the new system registers that POE introduces and context switch them.
>
> Signed-off-by: Joey Gouly
> Cc: Marc Zyngier
> Cc: Oliver Upton
> Cc: Catalin Marinas
> Cc: Will Deacon
> ---
> arc
On Tue, 06 Aug 2024 00:26:54 +0100,
Oliver Upton wrote:
>
> On Mon, Aug 05, 2024 at 11:26:03PM +, Oliver Upton wrote:
> > [+cc Fuad]
>
> Take 2!
>
> > Fuad, you mentioned in commit 9c30fc615daa ("KVM: arm64: Move setting
> > the page as dirty out of the critical section") that restructuring
+ Steven Price for this patch (and the following one), as this really
is his turf.
On Sat, 27 Jul 2024 00:51:10 +0100,
Sean Christopherson wrote:
>
> Put the page reference acquired by gfn_to_pfn_prot() if
> kvm_vm_ioctl_mte_copy_tags() runs into ZONE_DEVICE memory. KVM's less-
> than-stellar h
On 2024-07-05 09:05, Christian Zigotzky wrote:
How about the other patch[1], which would be far preferable?
M.
[1] https://lore.kernel.org/all/86ed8ba2sp.wl-...@kernel.org
- - - -
Marc,
We will test the patch as soon as possible.
Christian
- - - -
Our tester has reported, that it doesn
On Thu, 04 Jul 2024 05:10:46 +0100,
Christian Zigotzky wrote:
>
> On 02.07.24 18:54, Marc Zyngier wrote:
> > On Sun, 30 Jun 2024 11:21:55 +0100,
> > Christian Zigotzky wrote:
> >> Hello,
> >>
> >> There is an issue with the identification of ATA
Hi Michael,
On Wed, 03 Jul 2024 12:30:38 +0100,
Michael Ellerman wrote:
>
> Rob Herring writes:
> > On Tue, Jul 2, 2024 at 10:54 AM Marc Zyngier wrote:
> >>
> >> On Sun, 30 Jun 2024 11:21:55 +0100,
> >> Christian Zigotzky wrote:
> >> >
>
On Wed, 03 Jul 2024 11:26:17 +0100,
Christian Zigotzky wrote:
>
> On 3. Jul 2024, at 08:40, Marc Zyngier wrote:
>
> This isn't a DTS. This is a listing of all the nodes, not something I
> can use to feed the kernel. I explained how to generate it.
>
> Download the co
On Wed, 03 Jul 2024 04:27:37 +0100,
Christian Zigotzky wrote:
>
> Hello Marc,
>
> On 02.07.24 18:54, Marc Zyngier wrote:
> > On Sun, 30 Jun 2024 11:21:55 +0100,
> > Christian Zigotzky wrote:
> >> Hello,
> >>
> >> There is an issue with the i
On Wed, 03 Jul 2024 04:11:55 +0100,
Christian Zigotzky wrote:
>
> Hello Marc,
>
> On 02.07.24 21:49, Marc Zyngier wrote:
> > On 2024-07-02 18:55, Christian Zigotzky wrote:
> >> Hello Marc,
> >>
> >> Thank you for your reply.
> >>
&g
On Tue, 02 Jul 2024 21:48:23 +0100,
Rob Herring wrote:
>
> On Tue, Jul 2, 2024 at 10:54 AM Marc Zyngier wrote:
> >
> > On Sun, 30 Jun 2024 11:21:55 +0100,
> > Christian Zigotzky wrote:
> > >
> > > Hello,
> > >
> > > There is an is
On 2024-07-02 18:55, Christian Zigotzky wrote:
Hello Marc,
Thank you for your reply.
On 02.07.24 17:19, Marc Zyngier wrote:
Please provide the device tree for your platform. It isn't possible to
debug this without it, no matter how many pictures you provide. If it
doesn't exist in s
On Sun, 30 Jun 2024 11:21:55 +0100,
Christian Zigotzky wrote:
>
> Hello,
>
> There is an issue with the identification of ATA drives with our
> P.A. Semi Nemo boards [1] after the
> commit "of/irq: Factor out parsing of interrupt-map parent
> phandle+args from of_irq_parse_raw()" [2].
[snip]
M
Christian,
On Sun, 30 Jun 2024 11:21:55 +0100,
Christian Zigotzky wrote:
>
> Hello,
>
> There is an issue with the identification of ATA drives with our
> P.A. Semi Nemo boards [1] after the
> commit "of/irq: Factor out parsing of interrupt-map parent
> phandle+args from of_irq_parse_raw()" [2]
ruction could fail, and not get the IPA.
>
> Switch to using `at s1e1a` so that KVM can get the IPA regardless of S1
> permissions.
>
> Signed-off-by: Joey Gouly
> Cc: Marc Zyngier
> Cc: Oliver Upton
> Cc: Catalin Marinas
> Cc: Will Deacon
> ---
> arch/arm64/kvm/
On Fri, 03 May 2024 14:01:26 +0100,
Joey Gouly wrote:
>
> To allow using newer instructions that current assemblers don't know about,
> replace the `at` instruction with the underlying SYS instruction.
>
> Signed-off-by: Joey Gouly
> Cc: Marc Zyngier
> Cc: Oliver Up
On Fri, 03 May 2024 14:01:25 +0100,
Joey Gouly wrote:
>
> Define the new system registers that POE introduces and context switch them.
>
> Signed-off-by: Joey Gouly
> Cc: Marc Zyngier
> Cc: Oliver Upton
> Cc: Catalin Marinas
> Cc: Will Deacon
> ---
> arc
On Fri, 12 Apr 2024 15:54:22 +0100,
Sean Christopherson wrote:
>
> On Fri, Apr 12, 2024, Marc Zyngier wrote:
> > On Fri, 12 Apr 2024 11:44:09 +0100, Will Deacon wrote:
> > > On Fri, Apr 05, 2024 at 07:58:12AM -0400, Paolo Bonzini wrote:
> > > Also, if you're
On Fri, 12 Apr 2024 11:44:09 +0100,
Will Deacon wrote:
>
> On Fri, Apr 05, 2024 at 07:58:12AM -0400, Paolo Bonzini wrote:
> > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > index dc04bc767865..ff17849be9f4 100644
> > --- a/arch/arm64/kvm/mmu.c
> > +++ b/arch/arm64/kvm/mmu.c
> > @@ -
7 +---
> mm/migrate_device.c | 8 +---
> mm/mmu_notifier.c | 17 -
> virt/kvm/kvm_main.c | 50 +
> 26 files changed, 10 insertions(+), 411 deletions(-)
>
Reviewed-by: Marc Zyngier
M.
--
Without deviation from the norm, progress is not possible.
ail VM creation.
>
> Change to a void return to discourage architectures from making debugfs
> failures fatal for the VM. Seems like everyone already had the right
> idea, as all implementations already return 0 unconditionally.
>
> Signed-off-by: Oliver Upton
Acked-by: Marc
On Fri, 09 Jun 2023 01:59:35 +0100,
Yu Zhao wrote:
>
> TLDR
>
> Apache Spark spent 12% less time sorting four billion random integers twenty
> times (in ~4 hours) after this patchset [1].
Why are the 3 architectures you have considered being evaluated with 3
different benchmarks? I am not
On Thu, 23 Feb 2023 03:58:47 +,
Yu Zhao wrote:
>
> On Fri, Feb 17, 2023 at 2:00 AM Marc Zyngier wrote:
> >
> > On Fri, 17 Feb 2023 04:21:28 +,
> > Yu Zhao wrote:
> > >
> > > On Thu, Feb 16, 2023 at 9:12 PM Yu Zhao wrote:
> > > >
&
| 1 +
> > arch/arm64/kvm/hyp/pgtable.c| 51 ++--
> > arch/arm64/kvm/mmu.c| 77 -
> > 6 files changed, 141 insertions(+), 46 deletions(-)
>
> Adding Marc and Will.
>
> Can you please add other interested
On 2022-12-27 13:02, Paolo Bonzini wrote:
Queued, thanks. I will leave this in kvm/queue after testing
everything
else and moving it to kvm/next; this way, we can wait for test results
on other architectures.
Can you please make this a topic branch, and if possible based
on a released -rc? It
On Tue, 27 Dec 2022 20:36:08 +,
Sasha Levin wrote:
>
> From: Marc Zyngier
>
> [ Upstream commit 4545c6a3d6ba71747eaa984c338ddd745e56e23f ]
>
> Since 2f2940d16823 ("genirq/msi: Remove filter from
> msi_free_descs_free_range()"), the core MSI code relies on th
by: Paolo Bonzini
> Signed-off-by: Sean Christopherson
Acked-by: Marc Zyngier
M.
--
Without deviation from the norm, progress is not possible.
On 2022-06-23 02:49, Chen Zhongjin wrote:
Using unreachable() at default of switch generates an extra branch at
end of the function, and compiler won't generate a ret to close this
branch because it knows it's unreachable.
If there's no instruction in this branch, compiler will generate a NOP,
A
}
> >
> > if ((unsigned)ipinr < NR_IPI)
> > - trace_ipi_exit_rcuidle(ipi_types[ipinr]);
> > + trace_ipi_exit(ipi_types[ipinr]);
> > }
> >
> > static irqreturn_t ipi_handler(int irq, void *data)
Acked-by: Marc Zyngier
M.
--
Without deviation from the norm, progress is not possible.
PUs are (really!) off.
>
> This patch mimics the ipi_cpu_stop() interrupt disable mechanism
> in the crash CPU shutdown path, hence disabling IRQs/FIQs in all
> secondary CPUs in the kexec/panic path as well.
>
> Cc: Marc Zyngier
> Cc: Russell King
> Signed-off-by: Guilh
On Fri, 29 Apr 2022 22:45:14 +0100,
"Russell King (Oracle)" wrote:
>
> On Fri, Apr 29, 2022 at 06:38:19PM -0300, Guilherme G. Piccoli wrote:
> > Thanks Marc and Michael for the review/discussion.
> >
> > On 29/04/2022 15:20, Marc Zyngier wrote:
> > >
On Fri, 04 Mar 2022 13:10:19 +,
Christophe Leroy wrote:
>
>
>
> Le 04/03/2022 à 02:18, cgel@gmail.com a écrit :
> > From: Minghao Chi (CGEL ZTE)
> >
> > Use of_device_get_match_data() to simplify the code.
> >
> > Reported-by: Zeal Robot
> > Signed-off-by: Minghao Chi (CGEL ZTE)
>
On Wed, 17 Nov 2021 17:39:59 +,
David Woodhouse wrote:
>
> From: David Woodhouse
>
> The kvm_dirty_ring_get() function uses kvm_get_running_vcpu() to work out
> which dirty ring to use, but there are some use cases where that doesn't
> work.
>
> There's one in setting the Xen shared info p
m-y := $(KVM)/kvm_main.o $(KVM)/eventfd.o $(KVM)/binary_stats.o
> +kvm-$(CONFIG_KVM_VFIO) += $(KVM)/vfio.o
> +kvm-$(CONFIG_KVM_MMIO) += $(KVM)/coalesced_mmio.o
> +kvm-$(CONFIG_KVM_ASYNC_PF) += $(KVM)/async_pf.o
> +kvm-$(CONFIG_HAVE_KVM_IRQ_ROUTING) += $(KVM)/irqchip.o
> +kvm-$(CONFIG_HAVE_KVM_DIRTY_RING) += $(KVM)/dirty_ring.o
Acked-by: Marc Zyngier
M.
--
Without deviation from the norm, progress is not possible.
m.o mmu.o mmio.o psci.o perf.o hypercalls.o pvtime.o \
>inject_fault.o va_layout.o handle_exit.o \
>guest.o debug.o reset.o sys_regs.o \
>vgic-sys-reg-v3.o fpsimd.o pmu.o \
Acked-by: Marc Zyngier
M.
--
Without deviation from the norm, progress is not possible.
XIVE driver to use a 'tree' domain type instead.
>
> [1] For instance, a linux KVM guest with virtio-rng and virtio-balloon
> devices.
>
> Cc: Marc Zyngier
> Cc: sta...@vger.kernel.org # v5.14+
> Fixes: 4f86a06e2d6e ("irqdomain: Make normal and nomap irqdom
Now that the vcpu array is backed by an xarray, use the optimised
iterator that matches the underlying data structure.
Suggested-by: Sean Christopherson
Signed-off-by: Marc Zyngier
---
include/linux/kvm_host.h | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/include
Everywhere we use kvm_for_each_vpcu(), we use an int as the vcpu
index. Unfortunately, we're about to move rework the iterator,
which requires this to be upgrade to an unsigned long.
Let's bite the bullet and repaint all of it in one go.
Signed-off-by: Marc Zyngier
---
arch
this memory, let's use an xarray instead,
which gives us almost the same flexibility as a normal array, but
with a reduced memory usage with smaller VMs.
Signed-off-by: Marc Zyngier
---
include/linux/kvm_host.h | 5 +++--
virt/kvm/kvm_main.c | 15 +--
2 files change
As we are about to change the way vcpus are allocated, mandate
the use of kvm_get_vcpu() instead of open-coding the access.
Signed-off-by: Marc Zyngier
---
arch/x86/kvm/vmx/posted_intr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/vmx/posted_intr.c b/arch
As we are about to change the way vcpus are allocated, mandate
the use of kvm_get_vcpu() instead of open-coding the access.
Reviewed-by: Claudio Imbrenda
Signed-off-by: Marc Zyngier
---
arch/s390/kvm/kvm-s390.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch
As we are about to change the way vcpus are allocated, mandate
the use of kvm_get_vcpu() instead of open-coding the access.
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Marc Zyngier
---
arch/mips/kvm/loongson_ipi.c | 4 ++--
arch/mips/kvm/mips.c | 2 +-
2 files changed, 3
her changes.
The locking is dropped altogether, as this should only be called
when there is no further references on the kvm structure.
Reviewed-by: Claudio Imbrenda
Signed-off-by: Marc Zyngier
---
arch/arm64/kvm/arm.c | 10 +-
arch/mips/kvm/mips.c |
an xarray,
which results in a net code deletion after a bit of cleanup.
* From v1:
- Rebased on v5.16-rc1
- Dropped the dubious locking on teardown
- Converted kvm_for_each_vcpu() to xa_for_each_range(), together with
an invasive change converting the index to an unsigned long
Marc
On Tue, 16 Nov 2021 15:03:40 +,
Paolo Bonzini wrote:
>
> On 11/5/21 20:20, Marc Zyngier wrote:
> > The kvm structure is pretty large. A large portion of it is the vcpu
> > array, which is 4kB on x86_64 and arm64 as they deal with 512 vcpu
> > VMs. Of course, hardly
On Mon, 15 Nov 2021 19:05:17 +,
Cédric Le Goater wrote:
>
> Hello Mark,
s/k/c/
>
> On 5/20/21 18:37, Marc Zyngier wrote:
> > Direct mappings are completely exclusive of normal mappings, meaning
> > that we can refactor the code slightly so that w
On Fri, 12 Nov 2021 14:15:18 +,
Christian Zigotzky wrote:
>
> On 12 November 2021 at 02:41 pm, Marc Zyngier wrote:
> > On Fri, 12 Nov 2021 09:40:30 +,
> > Christian Zigotzky wrote:
> >> On 11 November 2021 at 06:39 pm, Marc Zyngier wrote:
> >>
On Fri, 12 Nov 2021 09:40:30 +,
Christian Zigotzky wrote:
>
> On 11 November 2021 at 06:39 pm, Marc Zyngier wrote:
> > On Wed, 10 Nov 2021 18:07:24 +,
> > Christian Zigotzky wrote:
> >> On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:
> >>
On Wed, 10 Nov 2021 18:07:24 +,
Christian Zigotzky wrote:
>
> On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:
> > Hello,
> >
> > The Nemo board [1] doesn't recognize any ATA disks with the
> pci-v5.16 updates [2].
> >
> > Error messages:
> >
> > ata4.00: gc timeout cmd 0xec
> > ata
On Thu, 11 Nov 2021 10:44:30 +,
Christian Zigotzky wrote:
>
> On 11 November 2021 at 11:20 am, Marc Zyngier wrote:
> > On Thu, 11 Nov 2021 07:47:08 +,
> > Christian Zigotzky wrote:
> >> On 11 November 2021 at 08:13 am, Marc Zyngier wrote:
> >>
On Thu, 11 Nov 2021 07:47:08 +,
Christian Zigotzky wrote:
>
> On 11 November 2021 at 08:13 am, Marc Zyngier wrote:
> > On Thu, 11 Nov 2021 05:24:52 +,
> > Christian Zigotzky wrote:
> >> Hello Marc,
> >>
> >> Here you are:
> >> ht
On Thu, 11 Nov 2021 05:24:52 +,
Christian Zigotzky wrote:
>
> On 10 November 2021 at 08:09 pm, Marc Zyngier wrote:
> > HI all,
> >
> > On Wed, 10 Nov 2021 18:41:06 +,
> > Bjorn Helgaas wrote:
> >> On Wed, Nov 10, 2021 at 07:07:24PM +0100, Christi
all ATA disks without any problems.
> >
> > I created a patch for an easy reverting the bad commit [1]. With this patch
> > we can do further our kernel tests.
> >
> > Could you please check the first bad commit [2]?
> >
> > Thanks,
> > Christ
On 2021-11-06 11:48, Marc Zyngier wrote:
On Fri, 05 Nov 2021 20:21:36 +,
Sean Christopherson wrote:
On Fri, Nov 05, 2021, Marc Zyngier wrote:
> At least on arm64 and x86, the vcpus array is pretty huge (512 entries),
> and is mostly empty in most cases (running 512 vcpu VMs is no
On Fri, 05 Nov 2021 20:21:36 +,
Sean Christopherson wrote:
>
> On Fri, Nov 05, 2021, Marc Zyngier wrote:
> > At least on arm64 and x86, the vcpus array is pretty huge (512 entries),
> > and is mostly empty in most cases (running 512 vcpu VMs is not that
> > common).
On Fri, 05 Nov 2021 20:12:12 +,
Sean Christopherson wrote:
>
> On Fri, Nov 05, 2021, Marc Zyngier wrote:
> > All architectures have similar loops iterating over the vcpus,
> > freeing one vcpu at a time, and eventually wiping the reference
> > off the vc
se an xarray instead,
which gives us almost the same flexibility as a normal array, but
with a reduced memory usage with smaller VMs.
Signed-off-by: Marc Zyngier
---
include/linux/kvm_host.h | 5 +++--
virt/kvm/kvm_main.c | 15 +--
2 files changed, 12 insertions(+), 8 deletions(-)
her changes.
Signed-off-by: Marc Zyngier
---
arch/arm64/kvm/arm.c | 10 +-
arch/mips/kvm/mips.c | 21 +
arch/powerpc/kvm/powerpc.c | 10 +-
arch/riscv/kvm/vm.c| 10 +-
arch/s390/kvm/kvm-s390.c | 18 +-
arch/x86/kvm/
As we are about to change the way vcpus are allocated, mandate
the use of kvm_get_vcpu() instead of open-coding the access.
Signed-off-by: Marc Zyngier
---
arch/x86/kvm/vmx/posted_intr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/vmx/posted_intr.c b/arch
As we are about to change the way vcpus are allocated, mandate
the use of kvm_get_vcpu() instead of open-coding the access.
Signed-off-by: Marc Zyngier
---
arch/s390/kvm/kvm-s390.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390
into an xarray,
which results in a net code deletion after a bit of cleanup.
This series is on top of the current linux/master as it touches the
RISC-V implementation. Only tested on arm64.
Marc Zyngier (5):
KVM: Move wiping of the kvm->vcpus array to common code
KVM: mips: Use kvm_get_v
As we are about to change the way vcpus are allocated, mandate
the use of kvm_get_vcpu() instead of open-coding the access.
Signed-off-by: Marc Zyngier
---
arch/mips/kvm/loongson_ipi.c | 4 ++--
arch/mips/kvm/mips.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a
On Mon, 04 Oct 2021 21:42:45 +0100,
Linus Walleij wrote:
>
> On Mon, Oct 4, 2021 at 9:52 PM Rob Herring wrote:
>
> > FYI, I pushed patches 1-3 to kernelCI and didn't see any regressions.
> > I am a bit worried about changes to the DT interrupt parsing and
> > ancient platforms (such as PowerMac
Hi Michael,
On Fri, 03 Sep 2021 14:36:57 +0100,
Michael Ellerman wrote:
>
> Hi Linus,
>
> Please pull powerpc updates for 5.15.
>
> A bit of a small batch this time.
>
> There was one conflict against my own fixes branch, and the resolution was a
> little bit
> messy, so I just did a merge of
: Benjamin Herrenschmidt
Cc: Christophe Leroy
Cc: Paul Mackerras
Cc: Jonathan Marek
Cc: Catalin Marinas
Cc: Andrew Morton
Cc: Nicholas Piggin
Cc: Mark Rutland
Cc: Geert Uytterhoeven
Cc: Marc Zyngier
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
--->8
Jona
On Thu, 24 Jun 2021 04:57:47 +0100,
David Stevens wrote:
>
> From: David Stevens
>
> Avoid converting pfns returned by follow_fault_pfn to struct pages to
> transiently take a reference. The reference was originally taken to
> match the reference taken by gup. However, pfns returned by
> follow
On Thu, 24 Jun 2021 09:58:00 +0100,
Nicholas Piggin wrote:
>
> Excerpts from David Stevens's message of June 24, 2021 1:57 pm:
> > From: David Stevens
> > out_unlock:
> > if (is_tdp_mmu_root(vcpu->kvm, vcpu->arch.mmu->root_hpa))
> > read_unlock(&vcpu->kvm->mmu_lock);
> > els
Hi David,
On Thu, 24 Jun 2021 04:57:45 +0100,
David Stevens wrote:
>
> From: David Stevens
>
> Return a struct kvm_pfn_page containing both a pfn and an optional
> struct page from the gfn_to_pfn family of functions. This differentiates
> the gup and follow_fault_pfn cases, which allows caller
On Fri, 14 May 2021 21:51:51 +0100,
Thomas Gleixner wrote:
>
> On Fri, Apr 30 2021 at 10:03, Cédric Le Goater wrote:
>
> CC: +Marc
Thanks Thomas.
>
> > PCI MSI interrupt numbers are now mapped in a PCI-MSI domain but the
> > underlying calls handling the passthrough of the interrupt in the
>
Hi Guenter,
Thanks for the heads up.
On Mon, 26 Apr 2021 23:39:42 +0100,
Guenter Roeck wrote:
>
> On Tue, Apr 06, 2021 at 10:35:50AM +0100, Marc Zyngier wrote:
> > irq_create_strict_mappings() is a poor way to allow the use of
> > a linear IRQ domain as a legacy one. Let&
On Tue, 06 Apr 2021 11:32:13 +0100,
Geert Uytterhoeven wrote:
>
> Hi Marc,
>
> On Tue, Apr 6, 2021 at 11:44 AM Marc Zyngier wrote:
> > Instead of playing games with using irq_create_identity_mapping()
> > and irq_domain_associate(), drop the use of the former and
Christophe,
On Tue, 06 Apr 2021 12:21:33 +0100,
Christophe Leroy wrote:
>
>
>
> Le 06/04/2021 à 11:35, Marc Zyngier a écrit :
> > irq_linear_revmap() is supposed to be a fast path for domain
> > lookups, but it only exposes low-level details of the irqdomain
> >
This helper doesn't have a user anymore, let's remove it.
Signed-off-by: Marc Zyngier
---
Documentation/core-api/irq/irq-domain.rst | 1 -
include/linux/irqdomain.h | 11 ---
2 files changed, 12 deletions(-)
diff --git a/Documentation/core-api/irq/irq-dom
tting NR_IRQS_LEGACY.
The dependency cannot be broken yet as there is a lot of PPC-related
code that depends on it, but that's the first step towards it.
A followup patch will remove irq_domain_add_legacy_isa.
Signed-off-by: Marc Zyngier
---
arch/powerpc/include/asm/irq.h | 4 ++--
ar
No user of these APIs are left, remove them.
Signed-off-by: Marc Zyngier
---
include/linux/irqdomain.h | 9 -
kernel/irq/irqdomain.c| 35 ---
2 files changed, 44 deletions(-)
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index
It was never completely implemented, and was removed a long time
ago. Adjust the documentation to reflect this.
Signed-off-by: Marc Zyngier
---
kernel/irq/irqdomain.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
Use the generic irq_domain_simple_ops structure instead of
a home-grown one.
Signed-off-by: Marc Zyngier
---
arch/mips/netlogic/common/irq.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/mips/netlogic/common/irq.c b/arch/mips/netlogic/common/irq.c
index
Instead of playing games with using irq_create_identity_mapping()
and irq_domain_associate(), drop the use of the former and only
use the latter, together with the allocation of the irq_desc
as needed.
It doesn't make the code less awful, but at least the intent
is clearer.
Signed-off-by:
changes in the way irqdomains work.
M.
Marc Zyngier (9):
irqdomain: Reimplement irq_linear_revmap() with irq_find_mapping()
ARM: PXA: Kill use of irq_create_strict_mappings()
irqchip/jcore-aic: Kill use of irq_create_strict_mappings()
sh: intc: Drop the use of irq_create_i
meaningful difference compared to the cost of taking an
interrupt.
Reimplement irq_linear_revmap() with irq_find_mapping()
in order to preserve source code compatibility, and
rename the internal field for a measure.
Signed-off-by: Marc Zyngier
---
include/linux/irqdomain.h | 22
irq_create_strict_mappings() is a poor way to allow the use of
a linear IRQ domain as a legacy one. Let's be upfront about it.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-jcore-aic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-jcore-
irq_create_strict_mappings() is a poor way to allow the use of
a linear IRQ domain as a legacy one. Let's be upfront about
it and use a legacy domain when appropriate.
Signed-off-by: Marc Zyngier
---
arch/arm/mach-pxa/pxa_cplds_irqs.c | 24 +++-
1 file changed, 11 inser
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.
P
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 af
Hi Alexey,
On 2020-10-27 09:06, Alexey Kardashevskiy wrote:
PCI devices share 4 legacy INTx interrupts from the same PCI host
bridge.
Device drivers map/unmap hardware interrupts via irq_create_mapping()/
irq_dispose_mapping(). The problem with that these interrupts are
shared and when performi
Hi Tianjia,
On 2020-04-27 05:35, Tianjia Zhang wrote:
In the current kvm version, 'kvm_run' has been included in the
'kvm_vcpu'
structure. For historical reasons, many kvm-related function parameters
retain the 'kvm_run' and 'kvm_vcpu' parameters at the same time. This
patch does a unified clea
On 2020-04-16 09:45, Tianjia Zhang wrote:
On 2020/4/16 16:28, Marc Zyngier wrote:
[...]
Overall, there is a large set of cleanups to be done when both the
vcpu and the run
structures are passed as parameters at the same time. Just grepping
the tree for
kvm_run is pretty instructive
On 2020-04-16 08:03, Vitaly Kuznetsov wrote:
Tianjia Zhang writes:
In earlier versions of kvm, 'kvm_run' is an independent structure
and is not included in the vcpu structure. At present, 'kvm_run'
is already included in the vcpu structure, so the parameter
'kvm_run' is redundant.
This patch
> hwtracing/coresight/Kconfig
> Signed-off-by: Mauro Carvalho Chehab
> ---
> Documentation/virt/kvm/arm/pvtime.rst| 2 +-
> virt/kvm/arm/vgic/vgic-mmio-v3.c | 2 +-
> virt/kvm/arm/vgic/vgic.h | 4 ++--
Acked-b
On Sat, 14 Dec 2019 17:54:47 +
Yangtao Li wrote:
> Use devm_platform_ioremap_resource() to simplify code.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/soc/qcom/llcc-qcom.c| 7 +--
> drivers/soc/qcom/qcom-geni-se.c | 4 +---
> drivers/soc/qcom/qcom_aoss.c| 4 +---
> drivers/soc
On 13/06/18 10:20, Thomas Gleixner wrote:
> On Wed, 13 Jun 2018, Julien Thierry wrote:
>> On 13/06/18 09:34, Peter Zijlstra wrote:
>>> On Tue, Jun 12, 2018 at 05:57:23PM -0700, Ricardo Neri wrote:
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 5426627..dbc5e02 10
On Thu, 29 Mar 2018 18:32:47 +0100,
Russell King - ARM Linux wrote:
>
> On Thu, Mar 29, 2018 at 05:53:14PM +0100, Marc Zyngier wrote:
> > On Thu, 29 Mar 2018 16:58:27 +0100,
> > Russell King - ARM Linux wrote:
[...]
> > > I'm not aware of there being an emul
On Thu, 29 Mar 2018 16:58:27 +0100,
Russell King - ARM Linux wrote:
>
> On Thu, Mar 29, 2018 at 05:43:47PM +0200, Geert Uytterhoeven wrote:
> > On Thu, Mar 29, 2018 at 5:27 PM, Russell King - ARM Linux
> > wrote:
> > > On Thu, Mar 29, 2018 at 09:37:52AM +1100, Oliver wrote:
> > >> On Thu, Mar 29,
1 - 100 of 136 matches
Mail list logo