All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Guo Ren <guoren@kernel.org>
Cc: Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Palmer Dabbelt <palmer@sifive.com>,
	christoffer.dall@arm.com, Atish Patra <Atish.Patra@wdc.com>,
	Julien Grall <julien.grall@arm.com>,
	gary@garyguo.net, linux-riscv@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, Mike Rapoport <rppt@linux.ibm.com>,
	aou@eecs.berkeley.edu, Arnd Bergmann <arnd@arndb.de>,
	suzuki.poulose@arm.com, Marc Zyngier <marc.zyngier@arm.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	linux-arm-kernel@lists.infradead.org,
	Anup Patel <anup.Patel@wdc.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	iommu@lists.linux-foundation.org, james.morse@arm.com
Subject: Re: [PATCH RFC 11/14] arm64: Move the ASID allocator code in a separate file
Date: Thu, 19 Sep 2019 17:18:44 +0200	[thread overview]
Message-ID: <20190919151844.GG1013538@lophozonia> (raw)
In-Reply-To: <CAJF2gTRbyfrUqAULPqJTXdxx8YOscPqAEuMsoJ+dTNobNrUV1g@mail.gmail.com>

On Thu, Sep 19, 2019 at 09:07:15PM +0800, Guo Ren wrote:
> > The solution I had to this problem is pinning the ASID [1] used by the
> > IOMMU, to prevent the CPU from recycling the ASID on rollover. This way
> > the CPU doesn't have to wait for IOMMU invalidations to complete, when
> > scheduling a task that might not even have anything to do with the IOMMU.
> >
> 
> > In the Arm SMMU, ASID and IOASID (PASID) are separate identifiers. IOASID
> > indexes an entry in the context descriptor table, which contains the ASID.
> > So with unpinned shared ASID you don't need to invalidate the ATC on
> > rollover, since the IOASID doesn't change, but you do need to modify the
> > context descriptor and invalidate cached versions of it.
> The terminology confused me a lot. I perfer use PASID for IOMMU and
> ASID is for CPU.
> Arm's entry of the context descriptor table contains a "IOASID"

The terminology I've been using so far is different:
* IOASID is PASID
* The entry in the context descriptor table contains an ASID, which
  is either "shared" with CPUs or "private" to the SMMU (the SMMU spec
  says "shared" or "non-shared").
* So the CPU and SMMU TLBs use ASIDs, and the PCI ATC uses IOASID

> IOASID != ASID for CPU_TLB and IOMMU_TLB.
> 
> When you say "since the IOASID doesn't change",Is it PASID or my IOASID ? -_*!

I was talking about PASID. Maybe we can drop "IOASID" and talk only
about ASID and PASID :)

> PASID in PCI-sig was used to determine transfer address space.
> For intel, the entry which is indexed by PASID also contain S1/S2.PGD
> and DID(VMID).
> For arm, the entry which is indexed by PASID only contain S1.PGD and
> IOASID. Compare to Intel Vt-d Scalable mode, arm's design can't
> support PCI Virtual Function.

The SMMU does support PCI Virtual Function - an hypervisor can assign a
VF to a guest, and let that guest partition the VF into smaller contexts
by using PASID.  What it can't support is assigning partitions of a PCI
function (VF or PF) to multiple Virtual Machines, since there is a
single S2 PGD per function (in the Stream Table Entry), rather than one
S2 PGD per PASID context.

Thanks,
Jean

> > Once you have pinned ASIDs, you could also declare that IOASID = ASID. I
> > don't remember finding an argument to strictly forbid it, even though ASID
> > and IOASID have different sizes on Arm (respectively 8/16 and 20 bits).
> ASID and IOASID are hard to keep the same between CPU system and IOMMU
> system. So I introduce S1/S2.PGD.PPN as a bridge between CPUs and
> IOMMUs.
> See my proposal [1]
> 
> 1: https://lore.kernel.org/linux-csky/1568896556-28769-1-git-send-email-guoren@kernel.org/T/#u
> -- 
> Best Regards
>  Guo Ren
> 
> ML: https://lore.kernel.org/linux-csky/

WARNING: multiple messages have this Message-ID (diff)
From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Guo Ren <guoren@kernel.org>
Cc: aou@eecs.berkeley.edu,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	suzuki.poulose@arm.com, Marc Zyngier <marc.zyngier@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Palmer Dabbelt <palmer@sifive.com>,
	christoffer.dall@arm.com, iommu@lists.linux-foundation.org,
	Mike Rapoport <rppt@linux.ibm.com>,
	Anup Patel <anup.Patel@wdc.com>,
	Atish Patra <Atish.Patra@wdc.com>,
	Julien Grall <julien.grall@arm.com>,
	james.morse@arm.com, gary@garyguo.net,
	Paul Walmsley <paul.walmsley@sifive.com>,
	linux-riscv@lists.infradead.org, Will Deacon <will@kernel.org>,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH RFC 11/14] arm64: Move the ASID allocator code in a separate file
Date: Thu, 19 Sep 2019 17:18:44 +0200	[thread overview]
Message-ID: <20190919151844.GG1013538@lophozonia> (raw)
In-Reply-To: <CAJF2gTRbyfrUqAULPqJTXdxx8YOscPqAEuMsoJ+dTNobNrUV1g@mail.gmail.com>

On Thu, Sep 19, 2019 at 09:07:15PM +0800, Guo Ren wrote:
> > The solution I had to this problem is pinning the ASID [1] used by the
> > IOMMU, to prevent the CPU from recycling the ASID on rollover. This way
> > the CPU doesn't have to wait for IOMMU invalidations to complete, when
> > scheduling a task that might not even have anything to do with the IOMMU.
> >
> 
> > In the Arm SMMU, ASID and IOASID (PASID) are separate identifiers. IOASID
> > indexes an entry in the context descriptor table, which contains the ASID.
> > So with unpinned shared ASID you don't need to invalidate the ATC on
> > rollover, since the IOASID doesn't change, but you do need to modify the
> > context descriptor and invalidate cached versions of it.
> The terminology confused me a lot. I perfer use PASID for IOMMU and
> ASID is for CPU.
> Arm's entry of the context descriptor table contains a "IOASID"

The terminology I've been using so far is different:
* IOASID is PASID
* The entry in the context descriptor table contains an ASID, which
  is either "shared" with CPUs or "private" to the SMMU (the SMMU spec
  says "shared" or "non-shared").
* So the CPU and SMMU TLBs use ASIDs, and the PCI ATC uses IOASID

> IOASID != ASID for CPU_TLB and IOMMU_TLB.
> 
> When you say "since the IOASID doesn't change",Is it PASID or my IOASID ? -_*!

I was talking about PASID. Maybe we can drop "IOASID" and talk only
about ASID and PASID :)

> PASID in PCI-sig was used to determine transfer address space.
> For intel, the entry which is indexed by PASID also contain S1/S2.PGD
> and DID(VMID).
> For arm, the entry which is indexed by PASID only contain S1.PGD and
> IOASID. Compare to Intel Vt-d Scalable mode, arm's design can't
> support PCI Virtual Function.

The SMMU does support PCI Virtual Function - an hypervisor can assign a
VF to a guest, and let that guest partition the VF into smaller contexts
by using PASID.  What it can't support is assigning partitions of a PCI
function (VF or PF) to multiple Virtual Machines, since there is a
single S2 PGD per function (in the Stream Table Entry), rather than one
S2 PGD per PASID context.

Thanks,
Jean

> > Once you have pinned ASIDs, you could also declare that IOASID = ASID. I
> > don't remember finding an argument to strictly forbid it, even though ASID
> > and IOASID have different sizes on Arm (respectively 8/16 and 20 bits).
> ASID and IOASID are hard to keep the same between CPU system and IOMMU
> system. So I introduce S1/S2.PGD.PPN as a bridge between CPUs and
> IOMMUs.
> See my proposal [1]
> 
> 1: https://lore.kernel.org/linux-csky/1568896556-28769-1-git-send-email-guoren@kernel.org/T/#u
> -- 
> Best Regards
>  Guo Ren
> 
> ML: https://lore.kernel.org/linux-csky/

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Guo Ren <guoren@kernel.org>
Cc: aou@eecs.berkeley.edu,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	suzuki.poulose@arm.com, Marc Zyngier <marc.zyngier@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Palmer Dabbelt <palmer@sifive.com>,
	christoffer.dall@arm.com, iommu@lists.linux-foundation.org,
	Mike Rapoport <rppt@linux.ibm.com>,
	Anup Patel <anup.Patel@wdc.com>,
	Atish Patra <Atish.Patra@wdc.com>,
	Julien Grall <julien.grall@arm.com>,
	james.morse@arm.com, gary@garyguo.net,
	Paul Walmsley <paul.walmsley@sifive.com>,
	linux-riscv@lists.infradead.org, Will Deacon <will@kernel.org>,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH RFC 11/14] arm64: Move the ASID allocator code in a separate file
Date: Thu, 19 Sep 2019 17:18:44 +0200	[thread overview]
Message-ID: <20190919151844.GG1013538@lophozonia> (raw)
In-Reply-To: <CAJF2gTRbyfrUqAULPqJTXdxx8YOscPqAEuMsoJ+dTNobNrUV1g@mail.gmail.com>

On Thu, Sep 19, 2019 at 09:07:15PM +0800, Guo Ren wrote:
> > The solution I had to this problem is pinning the ASID [1] used by the
> > IOMMU, to prevent the CPU from recycling the ASID on rollover. This way
> > the CPU doesn't have to wait for IOMMU invalidations to complete, when
> > scheduling a task that might not even have anything to do with the IOMMU.
> >
> 
> > In the Arm SMMU, ASID and IOASID (PASID) are separate identifiers. IOASID
> > indexes an entry in the context descriptor table, which contains the ASID.
> > So with unpinned shared ASID you don't need to invalidate the ATC on
> > rollover, since the IOASID doesn't change, but you do need to modify the
> > context descriptor and invalidate cached versions of it.
> The terminology confused me a lot. I perfer use PASID for IOMMU and
> ASID is for CPU.
> Arm's entry of the context descriptor table contains a "IOASID"

The terminology I've been using so far is different:
* IOASID is PASID
* The entry in the context descriptor table contains an ASID, which
  is either "shared" with CPUs or "private" to the SMMU (the SMMU spec
  says "shared" or "non-shared").
* So the CPU and SMMU TLBs use ASIDs, and the PCI ATC uses IOASID

> IOASID != ASID for CPU_TLB and IOMMU_TLB.
> 
> When you say "since the IOASID doesn't change",Is it PASID or my IOASID ? -_*!

I was talking about PASID. Maybe we can drop "IOASID" and talk only
about ASID and PASID :)

> PASID in PCI-sig was used to determine transfer address space.
> For intel, the entry which is indexed by PASID also contain S1/S2.PGD
> and DID(VMID).
> For arm, the entry which is indexed by PASID only contain S1.PGD and
> IOASID. Compare to Intel Vt-d Scalable mode, arm's design can't
> support PCI Virtual Function.

The SMMU does support PCI Virtual Function - an hypervisor can assign a
VF to a guest, and let that guest partition the VF into smaller contexts
by using PASID.  What it can't support is assigning partitions of a PCI
function (VF or PF) to multiple Virtual Machines, since there is a
single S2 PGD per function (in the Stream Table Entry), rather than one
S2 PGD per PASID context.

Thanks,
Jean

> > Once you have pinned ASIDs, you could also declare that IOASID = ASID. I
> > don't remember finding an argument to strictly forbid it, even though ASID
> > and IOASID have different sizes on Arm (respectively 8/16 and 20 bits).
> ASID and IOASID are hard to keep the same between CPU system and IOMMU
> system. So I introduce S1/S2.PGD.PPN as a bridge between CPUs and
> IOMMUs.
> See my proposal [1]
> 
> 1: https://lore.kernel.org/linux-csky/1568896556-28769-1-git-send-email-guoren@kernel.org/T/#u
> -- 
> Best Regards
>  Guo Ren
> 
> ML: https://lore.kernel.org/linux-csky/
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Guo Ren <guoren@kernel.org>
Cc: aou@eecs.berkeley.edu,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Palmer Dabbelt <palmer@sifive.com>,
	iommu@lists.linux-foundation.org,
	Mike Rapoport <rppt@linux.ibm.com>,
	Anup Patel <anup.Patel@wdc.com>,
	Atish Patra <Atish.Patra@wdc.com>,
	Julien Grall <julien.grall@arm.com>,
	gary@garyguo.net, Paul Walmsley <paul.walmsley@sifive.com>,
	linux-riscv@lists.infradead.org, Will Deacon <will@kernel.org>,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH RFC 11/14] arm64: Move the ASID allocator code in a separate file
Date: Thu, 19 Sep 2019 17:18:44 +0200	[thread overview]
Message-ID: <20190919151844.GG1013538@lophozonia> (raw)
In-Reply-To: <CAJF2gTRbyfrUqAULPqJTXdxx8YOscPqAEuMsoJ+dTNobNrUV1g@mail.gmail.com>

On Thu, Sep 19, 2019 at 09:07:15PM +0800, Guo Ren wrote:
> > The solution I had to this problem is pinning the ASID [1] used by the
> > IOMMU, to prevent the CPU from recycling the ASID on rollover. This way
> > the CPU doesn't have to wait for IOMMU invalidations to complete, when
> > scheduling a task that might not even have anything to do with the IOMMU.
> >
> 
> > In the Arm SMMU, ASID and IOASID (PASID) are separate identifiers. IOASID
> > indexes an entry in the context descriptor table, which contains the ASID.
> > So with unpinned shared ASID you don't need to invalidate the ATC on
> > rollover, since the IOASID doesn't change, but you do need to modify the
> > context descriptor and invalidate cached versions of it.
> The terminology confused me a lot. I perfer use PASID for IOMMU and
> ASID is for CPU.
> Arm's entry of the context descriptor table contains a "IOASID"

The terminology I've been using so far is different:
* IOASID is PASID
* The entry in the context descriptor table contains an ASID, which
  is either "shared" with CPUs or "private" to the SMMU (the SMMU spec
  says "shared" or "non-shared").
* So the CPU and SMMU TLBs use ASIDs, and the PCI ATC uses IOASID

> IOASID != ASID for CPU_TLB and IOMMU_TLB.
> 
> When you say "since the IOASID doesn't change",Is it PASID or my IOASID ? -_*!

I was talking about PASID. Maybe we can drop "IOASID" and talk only
about ASID and PASID :)

> PASID in PCI-sig was used to determine transfer address space.
> For intel, the entry which is indexed by PASID also contain S1/S2.PGD
> and DID(VMID).
> For arm, the entry which is indexed by PASID only contain S1.PGD and
> IOASID. Compare to Intel Vt-d Scalable mode, arm's design can't
> support PCI Virtual Function.

The SMMU does support PCI Virtual Function - an hypervisor can assign a
VF to a guest, and let that guest partition the VF into smaller contexts
by using PASID.  What it can't support is assigning partitions of a PCI
function (VF or PF) to multiple Virtual Machines, since there is a
single S2 PGD per function (in the Stream Table Entry), rather than one
S2 PGD per PASID context.

Thanks,
Jean

> > Once you have pinned ASIDs, you could also declare that IOASID = ASID. I
> > don't remember finding an argument to strictly forbid it, even though ASID
> > and IOASID have different sizes on Arm (respectively 8/16 and 20 bits).
> ASID and IOASID are hard to keep the same between CPU system and IOMMU
> system. So I introduce S1/S2.PGD.PPN as a bridge between CPUs and
> IOMMUs.
> See my proposal [1]
> 
> 1: https://lore.kernel.org/linux-csky/1568896556-28769-1-git-send-email-guoren@kernel.org/T/#u
> -- 
> Best Regards
>  Guo Ren
> 
> ML: https://lore.kernel.org/linux-csky/
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

WARNING: multiple messages have this Message-ID (diff)
From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Guo Ren <guoren@kernel.org>
Cc: aou@eecs.berkeley.edu,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	suzuki.poulose@arm.com, Marc Zyngier <marc.zyngier@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Palmer Dabbelt <palmer@sifive.com>,
	christoffer.dall@arm.com, iommu@lists.linux-foundation.org,
	Mike Rapoport <rppt@linux.ibm.com>,
	Anup Patel <anup.Patel@wdc.com>,
	Atish Patra <Atish.Patra@wdc.com>,
	Julien Grall <julien.grall@arm.com>,
	james.morse@arm.com, gary@garyguo.net,
	Paul Walmsley <paul.walmsley@sifive.com>,
	linux-riscv@lists.infradead.org, Will Deacon <will@kernel.org>,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH RFC 11/14] arm64: Move the ASID allocator code in a separate file
Date: Thu, 19 Sep 2019 17:18:44 +0200	[thread overview]
Message-ID: <20190919151844.GG1013538@lophozonia> (raw)
In-Reply-To: <CAJF2gTRbyfrUqAULPqJTXdxx8YOscPqAEuMsoJ+dTNobNrUV1g@mail.gmail.com>

On Thu, Sep 19, 2019 at 09:07:15PM +0800, Guo Ren wrote:
> > The solution I had to this problem is pinning the ASID [1] used by the
> > IOMMU, to prevent the CPU from recycling the ASID on rollover. This way
> > the CPU doesn't have to wait for IOMMU invalidations to complete, when
> > scheduling a task that might not even have anything to do with the IOMMU.
> >
> 
> > In the Arm SMMU, ASID and IOASID (PASID) are separate identifiers. IOASID
> > indexes an entry in the context descriptor table, which contains the ASID.
> > So with unpinned shared ASID you don't need to invalidate the ATC on
> > rollover, since the IOASID doesn't change, but you do need to modify the
> > context descriptor and invalidate cached versions of it.
> The terminology confused me a lot. I perfer use PASID for IOMMU and
> ASID is for CPU.
> Arm's entry of the context descriptor table contains a "IOASID"

The terminology I've been using so far is different:
* IOASID is PASID
* The entry in the context descriptor table contains an ASID, which
  is either "shared" with CPUs or "private" to the SMMU (the SMMU spec
  says "shared" or "non-shared").
* So the CPU and SMMU TLBs use ASIDs, and the PCI ATC uses IOASID

> IOASID != ASID for CPU_TLB and IOMMU_TLB.
> 
> When you say "since the IOASID doesn't change",Is it PASID or my IOASID ? -_*!

I was talking about PASID. Maybe we can drop "IOASID" and talk only
about ASID and PASID :)

> PASID in PCI-sig was used to determine transfer address space.
> For intel, the entry which is indexed by PASID also contain S1/S2.PGD
> and DID(VMID).
> For arm, the entry which is indexed by PASID only contain S1.PGD and
> IOASID. Compare to Intel Vt-d Scalable mode, arm's design can't
> support PCI Virtual Function.

The SMMU does support PCI Virtual Function - an hypervisor can assign a
VF to a guest, and let that guest partition the VF into smaller contexts
by using PASID.  What it can't support is assigning partitions of a PCI
function (VF or PF) to multiple Virtual Machines, since there is a
single S2 PGD per function (in the Stream Table Entry), rather than one
S2 PGD per PASID context.

Thanks,
Jean

> > Once you have pinned ASIDs, you could also declare that IOASID = ASID. I
> > don't remember finding an argument to strictly forbid it, even though ASID
> > and IOASID have different sizes on Arm (respectively 8/16 and 20 bits).
> ASID and IOASID are hard to keep the same between CPU system and IOMMU
> system. So I introduce S1/S2.PGD.PPN as a bridge between CPUs and
> IOMMUs.
> See my proposal [1]
> 
> 1: https://lore.kernel.org/linux-csky/1568896556-28769-1-git-send-email-guoren@kernel.org/T/#u
> -- 
> Best Regards
>  Guo Ren
> 
> ML: https://lore.kernel.org/linux-csky/

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-09-19 15:18 UTC|newest]

Thread overview: 211+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-21 16:36 [PATCH RFC 00/14] kvm/arm: Align the VMID allocation with the arm64 ASID one Julien Grall
2019-03-21 16:36 ` Julien Grall
2019-03-21 16:36 ` [PATCH RFC 01/14] arm64/mm: Introduce asid_info structure and move asid_generation/asid_map to it Julien Grall
2019-03-21 16:36   ` Julien Grall
2019-03-21 17:03   ` Suzuki K Poulose
2019-03-21 17:03     ` Suzuki K Poulose
2019-03-21 17:27     ` Julien Grall
2019-03-21 17:27       ` Julien Grall
2019-03-21 16:36 ` [PATCH RFC 02/14] arm64/mm: Move active_asids and reserved_asids to asid_info Julien Grall
2019-03-21 16:36   ` Julien Grall
2019-03-21 16:36   ` Julien Grall
2019-03-21 16:36 ` [PATCH RFC 03/14] arm64/mm: Move bits " Julien Grall
2019-03-21 16:36   ` Julien Grall
2019-03-21 16:36   ` Julien Grall
2019-03-21 16:36 ` [PATCH RFC 04/14] arm64/mm: Move the variable lock and tlb_flush_pending " Julien Grall
2019-03-21 16:36   ` Julien Grall
2019-03-21 16:36   ` Julien Grall
2019-03-21 16:36 ` [PATCH RFC 05/14] arm64/mm: Remove dependency on MM in new_context Julien Grall
2019-03-21 16:36   ` Julien Grall
2019-03-21 16:36 ` [PATCH RFC 06/14] arm64/mm: Store the number of asid allocated per context Julien Grall
2019-03-21 16:36   ` Julien Grall
2019-03-21 16:36   ` Julien Grall
2019-03-21 16:36 ` [PATCH RFC 07/14] arm64/mm: Introduce NUM_ASIDS Julien Grall
2019-03-21 16:36   ` Julien Grall
2019-03-21 16:36 ` [PATCH RFC 08/14] arm64/mm: Split asid_inits in 2 parts Julien Grall
2019-03-21 16:36   ` Julien Grall
2019-03-21 16:36   ` Julien Grall
2019-03-21 16:36 ` [PATCH RFC 09/14] arm64/mm: Split the function check_and_switch_context in 3 parts Julien Grall
2019-03-21 16:36   ` Julien Grall
2019-03-21 16:36   ` Julien Grall
2019-03-21 16:36 ` [PATCH RFC 10/14] arm64/mm: Introduce a callback to flush the local context Julien Grall
2019-03-21 16:36   ` Julien Grall
2019-03-21 16:36   ` Julien Grall
2019-03-21 16:36 ` [PATCH RFC 11/14] arm64: Move the ASID allocator code in a separate file Julien Grall
2019-03-21 16:36   ` Julien Grall
2019-06-05 16:56   ` Julien Grall
2019-06-05 16:56     ` Julien Grall
2019-06-05 16:56     ` Julien Grall
2019-06-05 16:56     ` Julien Grall
2019-06-05 20:41     ` Palmer Dabbelt
2019-06-05 20:41       ` Palmer Dabbelt
2019-06-05 20:41       ` Palmer Dabbelt
2019-06-05 20:41       ` Palmer Dabbelt
2019-06-11  1:56       ` Gary Guo
2019-06-11  1:56         ` Gary Guo
2019-06-11  1:56         ` Gary Guo
2019-06-11  1:56         ` Gary Guo
2019-06-19  8:07     ` Guo Ren
2019-06-19  8:07       ` Guo Ren
2019-06-19  8:07       ` Guo Ren
2019-06-19  8:07       ` Guo Ren
2019-06-19  8:54       ` Julien Grall
2019-06-19  8:54         ` Julien Grall
2019-06-19  8:54         ` Julien Grall
2019-06-19  8:54         ` Julien Grall
2019-06-19  9:12         ` Will Deacon
2019-06-19  9:12           ` Will Deacon
2019-06-19  9:12           ` Will Deacon
2019-06-19  9:12           ` Will Deacon
2019-06-19 12:18           ` Guo Ren
2019-06-19 12:18             ` Guo Ren
2019-06-19 12:18             ` Guo Ren
2019-06-19 12:18             ` Guo Ren
2019-06-19 12:39             ` Will Deacon
2019-06-19 12:39               ` Will Deacon
2019-06-19 12:39               ` Will Deacon
2019-06-19 12:39               ` Will Deacon
2019-06-20  9:33               ` Guo Ren
2019-06-20  9:33                 ` Guo Ren
2019-06-20  9:33                 ` Guo Ren
2019-06-20  9:33                 ` Guo Ren
2019-06-24 10:40                 ` Will Deacon
2019-06-24 10:40                   ` Will Deacon
2019-06-24 10:40                   ` Will Deacon
2019-06-24 10:40                   ` Will Deacon
2019-06-25  7:25                   ` Palmer Dabbelt
2019-06-25  7:25                     ` Palmer Dabbelt
2019-06-25  7:25                     ` Palmer Dabbelt
2019-06-25  7:25                     ` Palmer Dabbelt
2019-09-07 23:52                   ` Guo Ren
2019-09-07 23:52                     ` Guo Ren
2019-09-07 23:52                     ` Guo Ren
2019-09-07 23:52                     ` Guo Ren
2019-09-07 23:52                     ` Guo Ren
2019-09-12 14:02                     ` Will Deacon
2019-09-12 14:02                       ` Will Deacon
2019-09-12 14:02                       ` Will Deacon
2019-09-12 14:02                       ` Will Deacon
2019-09-12 14:02                       ` Will Deacon
2019-09-12 14:59                       ` Guo Ren
2019-09-12 14:59                         ` Guo Ren
2019-09-12 14:59                         ` Guo Ren
2019-09-12 14:59                         ` Guo Ren
2019-09-12 14:59                         ` Guo Ren
2019-09-13  7:13                         ` Guo Ren
2019-09-13  7:13                           ` Guo Ren
2019-09-14  8:49                           ` Guo Ren
2019-09-14  8:49                             ` Guo Ren
2019-09-14  8:49                             ` Guo Ren
2019-09-14  8:49                             ` Guo Ren
2019-09-14  8:49                             ` Guo Ren
2019-09-16 12:57                           ` Jean-Philippe Brucker
2019-09-16 12:57                             ` Jean-Philippe Brucker
2019-09-16 12:57                             ` Jean-Philippe Brucker
2019-09-16 12:57                             ` Jean-Philippe Brucker
2019-09-16 12:57                             ` Jean-Philippe Brucker
2019-09-19 13:07                             ` Guo Ren
2019-09-19 13:07                               ` Guo Ren
2019-09-19 13:07                               ` Guo Ren
2019-09-19 13:07                               ` Guo Ren
2019-09-19 13:07                               ` Guo Ren
2019-09-19 15:18                               ` Jean-Philippe Brucker [this message]
2019-09-19 15:18                                 ` Jean-Philippe Brucker
2019-09-19 15:18                                 ` Jean-Philippe Brucker
2019-09-19 15:18                                 ` Jean-Philippe Brucker
2019-09-19 15:18                                 ` Jean-Philippe Brucker
2019-09-20  0:07                                 ` Guo Ren
2019-09-20  0:07                                   ` Guo Ren
2019-09-20  0:07                                   ` Guo Ren
2019-09-20  0:07                                   ` Guo Ren
2019-09-20  0:07                                   ` Guo Ren
2019-09-20  7:18                                   ` Jean-Philippe Brucker
2019-09-20  7:18                                     ` Jean-Philippe Brucker
2019-09-20  7:18                                     ` Jean-Philippe Brucker
2019-09-20  7:18                                     ` Jean-Philippe Brucker
2019-09-20  7:18                                     ` Jean-Philippe Brucker
2019-09-14 14:01                       ` Palmer Dabbelt
2019-09-14 14:01                         ` Palmer Dabbelt
2019-09-14 14:01                         ` Palmer Dabbelt
2019-09-14 14:01                         ` Palmer Dabbelt
2019-09-14 14:01                         ` Palmer Dabbelt
2019-09-15  5:03                         ` Anup Patel
2019-09-15  5:03                           ` Anup Patel
2019-09-15  5:03                           ` Anup Patel
2019-09-15  5:03                           ` Anup Patel
2019-09-15  5:03                           ` Anup Patel
2019-09-16 18:18                           ` Will Deacon
2019-09-16 18:18                             ` Will Deacon
2019-09-16 18:18                             ` Will Deacon
2019-09-16 18:18                             ` Will Deacon
2019-09-16 18:18                             ` Will Deacon
2019-09-16 18:28                             ` Palmer Dabbelt
2019-09-16 18:28                               ` Palmer Dabbelt
2019-09-16 18:28                               ` Palmer Dabbelt
2019-09-16 18:28                               ` Palmer Dabbelt
2019-09-16 18:28                               ` Palmer Dabbelt
2019-09-17  3:42                             ` Anup Patel
2019-09-17  3:42                               ` Anup Patel
2019-09-17  3:42                               ` Anup Patel
2019-09-17  3:42                               ` Anup Patel
2019-09-17  3:42                               ` Anup Patel
2019-09-19 13:36                               ` Guo Ren
2019-09-19 13:36                                 ` Guo Ren
2019-09-19 13:36                                 ` Guo Ren
2019-09-19 13:36                                 ` Guo Ren
2019-09-19 13:36                                 ` Guo Ren
2019-06-19 11:51         ` Guo Ren
2019-06-19 11:51           ` Guo Ren
2019-06-19 11:51           ` Guo Ren
2019-06-19 11:51           ` Guo Ren
2019-06-19 12:52           ` Julien Grall
2019-06-19 12:52             ` Julien Grall
2019-06-19 12:52             ` Julien Grall
2019-06-19 12:52             ` Julien Grall
2019-06-21 14:16           ` Catalin Marinas
2019-06-21 14:16             ` Catalin Marinas
2019-06-21 14:16             ` Catalin Marinas
2019-06-21 14:16             ` Catalin Marinas
2019-06-23 16:35             ` Guo Ren
2019-06-23 16:35               ` Guo Ren
2019-06-23 16:35               ` Guo Ren
2019-06-23 16:35               ` Guo Ren
2019-06-24 10:22               ` Will Deacon
2019-06-24 10:22                 ` Will Deacon
2019-06-24 10:22                 ` Will Deacon
2019-06-24 10:22                 ` Will Deacon
2019-06-27  9:41                 ` qi.fuli
2019-06-27  9:41                   ` qi.fuli
2019-06-27  9:41                   ` qi.fuli
2019-06-27  9:41                   ` qi.fuli
2019-06-27 10:26                   ` Will Deacon
2019-06-27 10:26                     ` Will Deacon
2019-06-27 10:26                     ` Will Deacon
2019-06-27 10:26                     ` Will Deacon
2019-06-24 15:38               ` Catalin Marinas
2019-06-24 15:38                 ` Catalin Marinas
2019-06-24 15:38                 ` Catalin Marinas
2019-06-24 15:38                 ` Catalin Marinas
2019-06-30  4:29                 ` Guo Ren
2019-06-30  4:29                   ` Guo Ren
2019-06-30  4:29                   ` Guo Ren
2019-06-30  4:29                   ` Guo Ren
2019-07-01  9:17                   ` Catalin Marinas
2019-07-01  9:17                     ` Catalin Marinas
2019-07-01  9:17                     ` Catalin Marinas
2019-07-01  9:17                     ` Catalin Marinas
2019-07-16  3:31                     ` Guo Ren
2019-07-16  3:31                       ` Guo Ren
2019-07-16  3:31                       ` Guo Ren
2019-07-16  3:31                       ` Guo Ren
2019-07-22 16:38                       ` Catalin Marinas
2019-07-22 16:38                         ` Catalin Marinas
2019-07-22 16:38                         ` Catalin Marinas
2019-07-22 16:38                         ` Catalin Marinas
2019-03-21 16:36 ` [PATCH RFC 12/14] arm64/lib: asid: Allow user to update the context under the lock Julien Grall
2019-03-21 16:36   ` Julien Grall
2019-03-21 16:36 ` [PATCH RFC 13/14] arm/kvm: Introduce a new VMID allocator Julien Grall
2019-03-21 16:36   ` Julien Grall
2019-03-21 16:36 ` [PATCH RFC 14/14] kvm/arm: Align the VMID allocation with the arm64 ASID one Julien Grall
2019-03-21 16:36   ` Julien Grall
2019-03-21 16:36   ` Julien Grall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190919151844.GG1013538@lophozonia \
    --to=jean-philippe@linaro.org \
    --cc=Atish.Patra@wdc.com \
    --cc=anup.Patel@wdc.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=christoffer.dall@arm.com \
    --cc=gary@garyguo.net \
    --cc=guoren@kernel.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=james.morse@arm.com \
    --cc=julien.grall@arm.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=marc.zyngier@arm.com \
    --cc=palmer@sifive.com \
    --cc=paul.walmsley@sifive.com \
    --cc=rppt@linux.ibm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.