ain.c | 64 +++-
1 file changed, 39 insertions(+), 25 deletions(-)
Nice code simplification.
Reviewed-by: Philippe Mathieu-Daudé
| 29 +++
23 files changed, 463 insertions(+), 445 deletions(-)
create mode 100644 arch/sparc/mm/execmem.c
Reviewed-by: Philippe Mathieu-Daudé
On 5/4/24 13:58, Paolo Bonzini wrote:
The only user was kvm_mmu_notifier_change_pte(), which is now gone.
Signed-off-by: Paolo Bonzini
---
virt/kvm/kvm_main.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé
--
kernel/events/uprobes.c | 5 ++---
mm/ksm.c | 4 ++--
mm/memory.c | 7 +--
mm/migrate_device.c | 8 ++--
5 files changed, 7 insertions(+), 19 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé
On Sat, Apr 17, 2021 at 02:06:44PM +0200, Borislav Petkov wrote:
> Nope, sorry, no joy. Zapping it from tip.
>
> With that patch, it fails booting on my test box with messages like
> (typing up from video I took):
>
> ...
> ata: softreset failed (1st FIS failed)
> ahci :03:00:1: AMD-Vi: Event
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 9f8614f5567eb4e38579422d38a1bdfeeb648ffc
Gitweb:
https://git.kernel.org/tip/9f8614f5567eb4e38579422d38a1bdfeeb648ffc
Author:Jean-Philippe Brucker
AuthorDate:Wed, 14 Apr 2021 10:26:34 +02:00
eardown_dma_ops() on x86 to clear the device's dma_ops
pointer during driver unbind.
Fixes: 08a27c1c3ecf ("iommu: Add support to change default domain of an iommu
group")
Signed-off-by: Jean-Philippe Brucker
---
arch/x86/Kconfig | 1 +
arch/x86/kernel/pci-dma.c | 7 +
gt; Link: https://lore.kernel.org/linux-iommu/YFhiMLR35WWMW%2FHu@myrica/
> Suggested-by: Jean-Philippe Brucker
> Signed-off-by: Jacob Pan
> ---
> drivers/dma/idxd/cdev.c | 2 +-
> drivers/dma/idxd/init.c | 6 +++---
> drivers/iommu
On Thu, Apr 08, 2021 at 10:08:56AM -0700, Jacob Pan wrote:
> diff --git a/drivers/iommu/iommu-sva-lib.c b/drivers/iommu/iommu-sva-lib.c
> index bd41405..bd99f6b 100644
> --- a/drivers/iommu/iommu-sva-lib.c
> +++ b/drivers/iommu/iommu-sva-lib.c
> @@ -12,27 +12,33 @@ static DECLARE_IOASID_SET(iommu_s
On Wed, Apr 07, 2021 at 04:36:54PM -0300, Jason Gunthorpe wrote:
> On Wed, Apr 07, 2021 at 08:43:50PM +0200, Jean-Philippe Brucker wrote:
>
> > * Get a container handle out of /dev/ioasid (or /dev/iommu, really.)
> > No operation available since we don't know wh
On Wed, Apr 07, 2021 at 08:17:50AM +, Tian, Kevin wrote:
> btw this discussion was raised when discussing the I/O page fault handling
> process. Currently the IOMMU layer implements a per-device fault reporting
> mechanism, which requires VFIO to register a handler to receive all faults
> on i
On Thu, Apr 01, 2021 at 07:04:01AM +, Liu, Yi L wrote:
> > - how about AMD and ARM's vSVA support? Their PASID allocation and page
> > table
> > happens within guest. They only need to bind the guest PASID table to
> > host.
In this case each VM has its own IOASID space, and the host IOASID
On Tue, Mar 30, 2021 at 10:07:55AM -0300, Jason Gunthorpe wrote:
> On Fri, Mar 26, 2021 at 09:06:42AM +0100, Jean-Philippe Brucker wrote:
>
> > It's not inconceivable to have a control queue doing DMA tagged with
> > PASID. The devices I know either use untagged DMA, or hav
On Fri, Mar 12, 2021 at 06:17:55PM +0530, Vivek Kumar Gautam wrote:
> > Regarding the overall design, I was initially assigning page directories
> > instead of whole PASID tables, which would simplify the driver and host
> > implementation. A major complication, however, is SMMUv3 accesses PASID
>
On Fri, Mar 12, 2021 at 06:39:05PM +0530, Vivek Kumar Gautam wrote:
> To complete the page request we would also need to send the response back to
> the host from virtio backend when handling page request. So the virtio
> command should also be accompanied with a vfio api to send the page request
>
On Fri, Mar 12, 2021 at 06:59:17PM +0530, Vivek Kumar Gautam wrote:
> > > + /* XXX HACK: set feature bit ARM_SMMU_FEAT_2_LVL_CDTAB */
> > > + pst_cfg->vendor.cfg.feat_flag |= (1 << 1);
> >
> > Oh right, this flag is missing. I'll add
> >
> >#define VIRTIO_IOMMU_PST_ARM_SMMU3_F_CD2L (1ULL << 1
On Thu, Mar 25, 2021 at 02:16:45PM -0300, Jason Gunthorpe wrote:
> On Thu, Mar 25, 2021 at 10:02:36AM -0700, Jacob Pan wrote:
> > Hi Jean-Philippe,
> >
> > On Thu, 25 Mar 2021 11:21:40 +0100, Jean-Philippe Brucker
> > wrote:
> >
> > > On Wed, Mar 24,
On Wed, Mar 24, 2021 at 10:02:46AM -0700, Jacob Pan wrote:
> > And a flag IOMMU_SVA_BIND_SUPERVISOR (not that I plan to implement it in
> > the SMMU, but I think we need to clean the current usage)
> >
> You mean move #define SVM_FLAG_SUPERVISOR_MODE out of Intel code to be a
> generic flag in iom
On Wed, Mar 24, 2021 at 03:12:30PM -0700, Jacob Pan wrote:
> Hi Jason,
>
> On Wed, 24 Mar 2021 14:03:38 -0300, Jason Gunthorpe wrote:
>
> > On Wed, Mar 24, 2021 at 10:02:46AM -0700, Jacob Pan wrote:
> > > > Also wondering about device driver allocating auxiliary domains for
> > > > their private
On Fri, Mar 19, 2021 at 11:22:21AM -0700, Jacob Pan wrote:
> Hi Jason,
>
> On Fri, 19 Mar 2021 10:54:32 -0300, Jason Gunthorpe wrote:
>
> > On Fri, Mar 19, 2021 at 02:41:32PM +0100, Jean-Philippe Brucker wrote:
> > > On Fri, Mar 19, 2021 at 09:46:45AM -0300, Jason Gu
On Fri, Mar 19, 2021 at 09:46:45AM -0300, Jason Gunthorpe wrote:
> On Fri, Mar 19, 2021 at 10:58:41AM +0100, Jean-Philippe Brucker wrote:
>
> > Although there is no use for it at the moment (only two upstream users and
> > it looks like amdkfd always uses current too), I quite l
Hi Jacob,
On Thu, Mar 18, 2021 at 05:22:34PM -0700, Jacob Pan wrote:
> Hi Jean,
>
> Slightly off the title. As we are moving to use cgroup to limit PASID
> allocations, it would be much simpler if we enforce on the current task.
Yes I think we should do that. Is there a problem with charging the
Hi Felix,
On Tue, Mar 09, 2021 at 11:30:19AM -0500, Felix Kuehling wrote:
> > I think the proper fix would be to not rely on custom hooks into a
> > particular
> > IOMMU driver, but to instead ensure that the amdgpu driver can do everything
> > it needs through the regular linux/iommu.h interface
Applied on drm-misc-next.
Many thanks Jagan for your patch and many thanks Thomas & Yannick for your
reviews & tests.
Philippe :-)
De : Linux-stm32 de la part
de Yannick FERTRE - foss
Envoyé : jeudi 4 mars 2021 09:49
À : Thomas Zimmermann; Ja
Hi Bhaskar,
On Fri, Mar 5, 2021 at 3:06 AM Bhaskar Chowdhury wrote:
>
>
>
> s/revelant/relevant/
Let me recommend you this great post explaining why and how you could
improve your patch subject and description:
https://www.freecodecamp.org/news/writing-good-commit-messages-a-practical-guide/#how
On Fri, Mar 05, 2021 at 09:30:49AM +0100, Jean-Philippe Brucker wrote:
> That works but isn't perfect, because the hardware resource of shared
> address spaces can be much lower that PID limit - 16k ASIDs on Arm. To
Sorry I meant 16-bit here - 64k
Thanks,
Jean
On Fri, Mar 5, 2021 at 11:16 AM Rafał Miłecki wrote:
>
> Hi,
>
> On 05.03.2021 10:58, Philippe Mathieu-Daudé wrote:
> > On Fri, Mar 5, 2021 at 6:55 AM Rafał Miłecki wrote:
> >>
> >> From: Rafał Miłecki
> >>
> >> 1. Use meaningful
Hi,
On Tue, Feb 23, 2021 at 10:06:15PM +0100, Eric Auger wrote:
> This patch adds the VFIO_IOMMU_SET_MSI_BINDING ioctl which aim
> to (un)register the guest MSI binding to the host. This latter
> then can use those stage 1 bindings to build a nested stage
> binding targeting the physical MSIs.
No
Hi,
On Thu, Mar 4, 2021 at 5:35 PM Qing Zhang wrote:
>
> The purpose of separating loongson_system_configuration from boot_param.h
> is to keep the other structure consistent with the firmware.
This is supposed to be a trivial patch, but the description actually
confuses me.
Why is the move out
Hi Rafał,
On Fri, Mar 5, 2021 at 6:55 AM Rafał Miłecki wrote:
>
> From: Rafał Miłecki
>
> 1. Use meaningful variable names (e.g. "flash_start", "res_size" instead
>of e.g. "iobase", "end")
> 2. Always operate on "offset" instead of mix of start, end, size, etc.
"instead of a mix"
> 3. Add
On Thu, Mar 04, 2021 at 09:46:03AM -0800, Jacob Pan wrote:
> Hi Jean-Philippe,
>
> On Thu, 4 Mar 2021 10:49:37 +0100, Jean-Philippe Brucker
> wrote:
>
> > On Wed, Mar 03, 2021 at 04:02:05PM -0800, Jacob Pan wrote:
> > > Hi Jacob,
> > >
> > &
On Wed, Mar 03, 2021 at 04:02:05PM -0800, Jacob Pan wrote:
> Hi Jacob,
>
> On Wed, 3 Mar 2021 13:17:26 -0800, Jacob Pan
> wrote:
>
> > Hi Tejun,
> >
> > On Wed, 3 Mar 2021 10:44:28 -0500, Tejun Heo wrote:
> >
> > > On Sat, Feb 27, 2021 at 02:01:23PM -0800, Jacob Pan wrote:
> > > > IOASIDs a
design.
The impedances given in this commit message refer to 3.3V operation.
Signed-off-by: Philippe Schenker
---
arch/arm/boot/dts/imx6ull-colibri.dtsi | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/imx6ull-colibri.dtsi
b/arch/arm/boot/dts
On Fri, Jan 15, 2021 at 05:43:40PM +0530, Vivek Gautam wrote:
[...]
> +static int viommu_setup_pgtable(struct viommu_endpoint *vdev,
> + struct viommu_domain *vdomain)
> +{
> + int ret, id;
> + u32 asid;
> + enum io_pgtable_fmt fmt;
> + struct io_pgtable_
gned-off-by: Vivek Gautam
> Cc: Joerg Roedel
> Cc: Will Deacon
> Cc: Michael S. Tsirkin
> Cc: Robin Murphy
> Cc: Jean-Philippe Brucker
> Cc: Eric Auger
> Cc: Alex Williamson
> Cc: Kevin Tian
> Cc: Jacob Pan
> Cc: Liu Yi L
> Cc: Lorenzo Pieralisi
> Cc: Sh
On Fri, Jan 15, 2021 at 05:43:36PM +0530, Vivek Gautam wrote:
> Add info about asid_bits and additional flags to table format
> probing header.
>
> Signed-off-by: Vivek Gautam
> Cc: Joerg Roedel
> Cc: Will Deacon
> Cc: Michael S. Tsirkin
> Cc: Robin Murphy
> Cc:
On Fri, Jan 15, 2021 at 05:43:35PM +0530, Vivek Gautam wrote:
> aisd_bits data is required to prepare stage-1 tables for arm-smmu-v3.
>
> Signed-off-by: Vivek Gautam
> Cc: Joerg Roedel
> Cc: Will Deacon
> Cc: Robin Murphy
> Cc: Jean-Philippe Brucker
> Cc: Eric Auge
On Fri, Jan 15, 2021 at 05:43:33PM +0530, Vivek Gautam wrote:
> From: Jean-Philippe Brucker
>
> Add required UAPI defines for probing table format for underlying
> iommu hardware. The device may provide information about hardware
> tables and additional capabilities for each
On Fri, Jan 15, 2021 at 05:43:32PM +0530, Vivek Gautam wrote:
> Te change allows different consumers of arm-smmu-v3-cd-lib to set
> their respective sync op for pasid entries.
>
> Signed-off-by: Vivek Gautam
> Cc: Joerg Roedel
> Cc: Will Deacon
> Cc: Robin Murphy
> C
On Fri, Jan 15, 2021 at 05:43:31PM +0530, Vivek Gautam wrote:
> Update base address information in vendor pasid table info to pass that
> to user-space for stage1 table management.
>
> Signed-off-by: Vivek Gautam
> Cc: Joerg Roedel
> Cc: Will Deacon
> Cc: Robin Murphy
;t too invasive. Even if we called directly
into the SMMU driver from the virtio one, we'd still need patch 3 and
separate TLB invalidations ops.
> Signed-off-by: Vivek Gautam
> Cc: Joerg Roedel
> Cc: Will Deacon
> Cc: Robin Murphy
> Cc: Jean-Philippe Brucker
> Cc:
On Mon, Mar 01, 2021 at 03:00:11PM -0800, Jacob Pan wrote:
> > functionality is not a problem without this patch on x86. But I think
> I feel the reason that x86 doesn't care is that mm->pasid is not used
> unless bind_mm is called.
I think vt-d also maintains the global_svm_list, that tells wheth
From: Fenghua Yu
When a new mm is created, its PASID should be cleared, i.e. the PASID is
initialized to its init state 0 on both ARM and X86.
Reviewed-by: Tony Luck
Signed-off-by: Fenghua Yu
Signed-off-by: Jean-Philippe Brucker
---
This patch was part of the series introducing mm->pa
MU's fw_cfg
> device")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1299
> Signed-off-by: Nathan Chancellor
> ---
> drivers/firmware/qemu_fw_cfg.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé
Hi Fenghua,
[Trimmed the Cc list]
On Mon, Jul 13, 2020 at 04:48:03PM -0700, Fenghua Yu wrote:
> When a new mm is created, its PASID should be cleared, i.e. the PASID is
> initialized to its init state 0 on both ARM and X86.
I just noticed this patch was dropped in v7, and am wondering whether we
On Tue, Feb 23, 2021 at 1:33 PM Maciej W. Rozycki wrote:
> On Tue, 23 Feb 2021, Philippe Mathieu-Daudé wrote:
>
> > > diff --git a/arch/mips/sgi-ip27/ip27-timer.c
> > > b/arch/mips/sgi-ip27/ip27-timer.c
> > > index 79c434fece52..444b5e0e935f 100644
> >
On Mon, Feb 22, 2021 at 5:22 PM Lukas Bulwahn wrote:
>
> The domain lookup for linux-mips.org fails for quite some time now.
> Further, the two links:
>
> http://decstation.unix-ag.org/
https://web.archive.org/web/20070609185805/http://decstation.unix-ag.org/
> http://www.computer-refuge.org
On Mon, Feb 22, 2021 at 5:22 PM Lukas Bulwahn wrote:
>
> This is a Copyright line, and just a typo slipped through.
>
> Signed-off-by: Lukas Bulwahn
> ---
> arch/mips/sgi-ip27/ip27-timer.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/mips/sgi-ip27/ip27-timer.
+-
> arch/mips/sgi-ip32/ip32-irq.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé
On Mon, Feb 22, 2021 at 5:22 PM Lukas Bulwahn wrote:
>
> The domain lookup for linux-mips.org fails for quite some time now. Hence,
> webpages, the patchwork instance and Ralf Baechle's email there is not
> reachable anymore.
>
> Remove all references of webpages from linux-mips.org in MAINTAINERS
Hi,
On Thu, Feb 04, 2021 at 06:52:10AM +, Tian, Kevin wrote:
> > >>> The static pinning and mapping problem in VFIO and possible solutions
> > >>> have been discussed a lot [1, 2]. One of the solutions is to add I/O
> > >>> page fault support for VFIO devices. Different from those relatively
>
Hi Keqian,
On Fri, Feb 05, 2021 at 05:13:50PM +0800, Keqian Zhu wrote:
> > We need to accommodate the firmware override as well if we need this to be
> > meaningful. Jean-Philippe is already carrying a suitable patch in the SVA
> > stack[1].
> Robin, Thanks for pointing it
txen-skew-psec = <0>;
> rxdv-skew-psec = <0>;
> rxd0-skew-psec = <0>;
> rxd1-skew-psec = <0>;
> rxd2-skew-psec = <0>;
> rxd3-skew-psec = <0>;
> rxc-skew-psec = <1860>;
> txc-skew-psec = <1860>;
> This
On Mon, Feb 01, 2021 at 08:26:41PM +0800, Keqian Zhu wrote:
> > +static int arm_smmu_insert_master(struct arm_smmu_device *smmu,
> > + struct arm_smmu_master *master)
> > +{
> > + int i;
> > + int ret = 0;
> > + struct arm_smmu_stream *new_stream, *cur_stream;
> >
/stm32mpu/wiki/MB1230
[2] https://www.st.com/en/evaluation-tools/stm32mp157a-ev1.html
Philippe :-)
-Original Message-
From: aleksandr.o.maka...@gmail.com
Sent: Saturday, January 16, 2021 12:40
To: Andrzej Hajda ; Neil Armstrong
; Laurent Pinchart
; Jonas Karlman ; Jernej
Skrabec
On Mon, Jan 18, 2021 at 10:55:52AM +, John Garry wrote:
> On 18/01/2021 10:08, Jean-Philippe Brucker wrote:
> > > > Any idea why that's happening? This fix seems ok but if we're expecting
> > > > allocation failures for the loaded magazine then we could
On Mon, Jan 18, 2021 at 09:24:17AM +, John Garry wrote:
> On 15/01/2021 17:30, Jean-Philippe Brucker wrote:
> > On Thu, Dec 10, 2020 at 02:23:08AM +0800, John Garry wrote:
> > > A similar crash to the following could be observed if initial CPU rcache
> > > m
On Thu, Dec 10, 2020 at 02:23:09AM +0800, John Garry wrote:
> Leizhen reported some time ago that IOVA performance may degrade over time
> [0], but unfortunately his solution to fix this problem was not given
> attention.
>
> To summarize, the issue is that as time goes by, the CPU rcache and depo
On Thu, Dec 10, 2020 at 02:23:08AM +0800, John Garry wrote:
> A similar crash to the following could be observed if initial CPU rcache
> magazine allocations fail in init_iova_rcaches():
Any idea why that's happening? This fix seems ok but if we're expecting
allocation failures for the loaded mag
>
> Signed-off-by: John Garry
> Tested-by: Xiang Chen
> Reviewed-by: Zhen Lei
Reviewed-by: Jean-Philippe Brucker
(unless we find a better solution for patch 3)
> ---
> drivers/iommu/iova.c | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> d
Hi Eric,
On Thu, Jan 14, 2021 at 05:58:27PM +0100, Auger Eric wrote:
> >> The uacce-devel branches from
> >>> https://github.com/Linaro/linux-kernel-uadk do provide this at the moment
> >>> (they track the latest sva/zip-devel branch
> >>> https://jpbrucker.net/git/linux/ which is roughly based o
On Wed, Jan 13, 2021 at 10:21:31AM +, Qais Yousef wrote:
> On 01/12/21 12:07, Andrii Nakryiko wrote:
> > > > > $ sudo ./test_progs -v -t module_attach
> > > >
> > > > use -vv when debugging stuff like that with test_progs, it will output
> > > > libbpf detailed logs, that often are very
On Wed, Jan 13, 2021 at 08:05:11PM +0800, Zhangfei Gao wrote:
> > > + /* Device-tree can set the stall property */
> > > + if (!pdev->dev.of_node &&
> > > + device_add_properties(&pdev->dev, properties))
> > Does this mean "dma-can-stall" *can* be set via DT, and if it is, this
> > quirk is not
Hi,
On Sat, Dec 19, 2020 at 10:34:55PM -0500, Sasha Levin wrote:
> From: Jean-Philippe Brucker
>
> [ Upstream commit 77ce220c0549dcc3db8226c61c60e83fc59dfafc ]
>
> The test fails because of a recent fix to the verifier, even though this
That fix is commit b02709587ea3 ("
t; ---
> arch/mips/boot/compressed/decompress.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Philippe Mathieu-Daudé
Hi Shameer,
On Thu, Dec 03, 2020 at 06:42:57PM +, Shameerali Kolothum Thodi wrote:
> Hi Jean/zhangfei,
> Is it possible to have a branch with minimum required SVA/UACCE related
> patches
> that are already public and can be a "stable" candidate for future respin of
> Eric's series?
> Please
Signed-off-by: Philippe Duplessis-Guindon
---
drivers/base/regmap/trace.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/base/regmap/trace.h b/drivers/base/regmap/trace.h
index d4066fa079ab..9abee14df9ee 100644
--- a/drivers/base/regmap/trace.h
+++ b/drivers/base/regmap/trace.h
@@ -12
signed:1;
field:__data_loc char[] status; offset:12; size:4;
signed:1;
field:__data_loc char[] type; offset:16; size:4;
signed:1;
print fmt: "%s type=%s status=%s", __get_str(name), __get_str(type),
__get_str(status)
Signed-off-by: Philip
Sorry Steven I forgot to reply all.
This is the original message:
Perfect,
I can prepare a patch, I think this would be a good learning opportunity
for me.
Thank you,
Philippe
On 2020-11-20 1:47 p.m., Steven Rostedt wrote:
On Fri, 20 Nov 2020 12:50:33 -0500
Philippe Duplessis-Guindon
On Wed, Oct 28, 2020 at 9:01 PM Colin King wrote:
>
> From: Colin Ian King
>
> There are a few spelling mistakes in the Kconfig, fix these.
>
> Signed-off-by: Colin Ian King
> ---
> arch/mips/Kconfig | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Re
On Fri, Oct 30, 2020 at 05:55:53AM +, Tian, Kevin wrote:
> > From: Lu Baolu
> > Sent: Friday, October 30, 2020 12:58 PM
> >
> > The aux-domain apis were designed for macro driver where the subdevices
> > are created and used inside a device driver. Use the device's bus iommu
> > ops instead o
On Mon, Oct 26, 2020 at 02:05:06PM -0700, Jacob Pan wrote:
> > This looks good to me, with small comments below.
> >
> Can I add your Reviewed-by tag after addressing the comments?
Yes sure, this took forever to review so I'm happy not to do another pass :)
> > > +Each IOASID set is created wit
Hi,
On Wed, Oct 28, 2020 at 09:36:57AM +0800, Yi Sun wrote:
> From: Jacob Pan
>
> original code fails when LAST_PAGE is set in flags.
LAST_PAGE is not documented to be a valid flags for page_response.
So isn't failing the right thing to do?
>
> Signed-off-by: Jacob Pan
> Signed-off-by: Liu Y
Hi,
On Mon, Oct 26, 2020 at 06:38:46PM +0100, Ard Biesheuvel wrote:
> > > > Note that even on plain be2881824ae9eb92, I get:
> > > >
> > > > aarch64-linux-gnu-ld: Unexpected GOT/PLT entries detected!
> > > > aarch64-linux-gnu-ld: Unexpected run-time procedure linkages
> > > > detected!
>
On Mon, Oct 19, 2020 at 02:16:08PM -0700, Raj, Ashok wrote:
> Hi Jean
>
> On Mon, Oct 19, 2020 at 04:08:24PM +0200, Jean-Philippe Brucker wrote:
> > On Sat, Oct 17, 2020 at 04:25:25AM -0700, Raj, Ashok wrote:
> > > > For devices that *don't* use a
On Mon, Oct 19, 2020 at 11:33:16AM -0700, Jacob Pan wrote:
> Hi Jean-Philippe,
>
> On Mon, 19 Oct 2020 16:08:24 +0200, Jean-Philippe Brucker
> wrote:
>
> > On Sat, Oct 17, 2020 at 04:25:25AM -0700, Raj, Ashok wrote:
> > > > For devices that *don't*
nb);
I think it's possible for ioasid_set_put_locked() to free the set right
after we release the lock, then this unregister() will be use-after-free.
Best keep holding the lock for this.
> + }
> + kfree(curr);
> + return;
> +
ter(&ioasid_notifier, nb);
> +}
> +EXPORT_SYMBOL_GPL(ioasid_register_notifier);
> +
Here as well, a comment saying that a reference to the set must be held,
though maybe that's obvious.
Thanks,
Jean
> +void ioasid_unregister_notifier(struct ioasid_set *set,
> + struct notifier_blo
On Mon, Sep 28, 2020 at 02:38:36PM -0700, Jacob Pan wrote:
> When an IOASID set is used for guest SVA, each VM will acquire its
> ioasid_set for IOASID allocations. IOASIDs within the VM must have a
> host/physical IOASID backing, mapping between guest and host IOASIDs can
> be non-identical. IOASI
gt; when the ioasid_set is freed, the user might perform the same cleanup
> operation on each IOASID.
>
> This patch adds an API to iterate all the IOASIDs within the set.
>
> Signed-off-by: Jacob Pan
Could add a short description of the function parameters, but
Reviewed-by: Jean-Philippe
On Mon, Sep 28, 2020 at 02:38:35PM -0700, Jacob Pan wrote:
> There can be multiple users of an IOASID, each user could have hardware
> contexts associated with the IOASID. In order to align lifecycles,
> reference counting is introduced in this patch. It is expected that when
> an IOASID is being f
SIDs already allocated within the set. The extra quota
> will be returned to the system-wide IOASID pool if the new quota is
> smaller than the existing one.
>
> Signed-off-by: Jacob Pan
Minor comments below, but
Reviewed-by: Jean-Philippe Brucker
> ---
>
On Mon, Sep 28, 2020 at 02:38:32PM -0700, Jacob Pan wrote:
> ioasid_set was introduced as an arbitrary token that is shared by a
> group of IOASIDs. For example, two IOASIDs allocated via the same
> ioasid_set pointer belong to the same set.
>
> For guest SVA usages, system-wide IOASID resources n
VT-d this is set during boot as part of the Intel IOMMU
> initialization.
>
> Signed-off-by: Jacob Pan
Reviewed-by: Jean-Philippe Brucker
> ---
> drivers/iommu/intel/iommu.c | 5 +
> drivers/iommu/ioasid.c | 20
> include/linux/ioasid.h |
() can
> then be used under spinlocks. In addition, this change makes the API
> symmetrical.
>
> Signed-off-by: Jacob Pan
A typo below, but
Reviewed-by: Jean-Philippe Brucker
> ---
> drivers/iommu/intel/svm.c | 4 ++--
> drivers/iommu/ioasid.c| 54
> +
On Mon, Sep 28, 2020 at 02:38:28PM -0700, Jacob Pan wrote:
> IOASID is used to identify address spaces that can be targeted by device
> DMA. It is a system-wide resource that is essential to its many users.
> This document is an attempt to help developers from all vendors navigate
> the APIs. At th
On Sat, Oct 17, 2020 at 04:25:25AM -0700, Raj, Ashok wrote:
> > For devices that *don't* use a stop marker, the PCIe spec says (10.4.1.2):
> >
> > To stop [using a PASID] without using a Stop Marker Message, the
> > function shall:
> > 1. Stop queueing new Page Request Messages for this PASI
On Thu, Oct 15, 2020 at 11:22:11AM -0700, Raj, Ashok wrote:
> Hi Jean
>
> + Baolu who is looking into this.
>
>
> On Thu, Oct 15, 2020 at 11:00:27AM +0200, Jean-Philippe Brucker wrote:
> > Add a parameter to iommu_sva_unbind_device() that tells the IOMMU driver
> &g
lienne
> Cc: Florian Fainelli
> Cc: Ray Jui
> Cc: Scott Branden
> Cc: bcm-kernel-feedback-l...@broadcom.com
> Cc: Maxime Coquelin
> Cc: Alexandre Torgue
> Cc: "Guido Gúnther"
> Cc: Robert Chiras
> Cc: Philippe Cornu
Hi Rob,
and many thanks for the patch.
For the stm32 part,
Reviewed-by: Philippe Cornu
Philippe :-)
dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
> drm_display_mode *mode,
>
> /* Select the color coding */
> dsi_update_bits(dsi, DSI_WCFGR, WCFGR_COLMUX,
> - dsi_color_from_mipi(format) << 1);
> + dsi_color_from_m
.
Add the IOMMU_UNBIND_FAULT_PENDING flags to unbind(), to tell the IOMMU
driver whether it's worth flushing the queue.
Signed-off-by: Jean-Philippe Brucker
---
include/linux/iommu.h | 31 +++
drivers/iommu/intel/svm.c | 3 ++-
drivers/iommu/iommu.c | 5
Provide a way for device drivers to tell IOMMU drivers about the device
state and the cleanup work to be done, when unbinding. No functional
change.
Signed-off-by: Jean-Philippe Brucker
---
include/linux/intel-iommu.h | 2 +-
include/linux/iommu.h | 7 ---
drivers/iommu/intel/svm.c
hould return whether faults are pending. This can be
added later once uacce has an actual PCIe user, but we need to
remember to do it.
Jean-Philippe Brucker (2):
iommu: Add flags to sva_unbind()
iommu: Add IOMMU_UNBIND_FAULT_PENDING flag
include/linux/intel-iommu.h | 2 +-
i
80 + 12 + 5,
> + .vtotal = 1280 + 12 + 5 + 12,
> .flags = 0,
> .width_mm = 68,
> .height_mm = 122,
>
Hi Yannick,
Tested-by: Philippe Cornu
Thank you,
Philippe
in padding, flags, and version are also checked.
> Details are documented in Documentation/userspace-api/iommu.rst
>
> Signed-off-by: Liu Yi L
> Signed-off-by: Jacob Pan
Reviewed-by: Jean-Philippe Brucker
Some comments below in case you're resending,
On Sun, Sep 20, 2020 at 11:09 PM Thomas Bogendoerfer
wrote:
>
> Remove unused heasder file asm/mach-malta/malta-pm.h.
Typo "header".
>
> Signed-off-by: Thomas Bogendoerfer
> ---
> arch/mips/include/asm/mach-malta/malta-pm.h | 33
> -
> 1 file changed, 33 deletions(
On Wed, Sep 16, 2020 at 03:39:37PM +0300, Yauheni Kaliuta wrote:
> If you start to amend extables, could you consider a change like
>
> 05a68e892e89 ("s390/kernel: expand exception table logic to allow new
> handling options")
>
> and implementation of BPF_PROBE_MEM then?
Commit 800834285361 ("
On Tue, Sep 15, 2020 at 02:11:03PM +0100, Will Deacon wrote:
> > ret = build_insn(insn, ctx, extra_pass);
> > if (ret > 0) {
> > i++;
> > if (ctx->image == NULL)
> > - ctx->offset[i] = ctx->idx;
> > +
(*get_timing)(void *priv_data, unsigned int lane_mbps,
> struct dw_mipi_dsi_dphy_timing *timing);
> + int (*get_esc_clk_rate)(void *priv_data, unsigned int *esc_clk_rate);
> };
>
> struct dw_mipi_dsi_host_ops {
>
Hi Neil,
Thank you for the patch
Reviewed-by: Philippe Cornu
Philippe :-)
On Sun, Sep 6, 2020 at 9:31 PM Paul Cercueil wrote:
>
> Check for the (already existing) "system_type" variable in the
> get_system_type() function. If non-NULL, return it as the system type.
Nitpick: It is not already "existing", simply declared in asm/bootinfo.h.
>
> Signed-off-by: Paul Cercue
1 - 100 of 1062 matches
Mail list logo
