All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will@kernel.org>
To: "Isaac J. Manjarres" <isaacm@codeaurora.org>
Cc: robh@kernel.org, kernel-team@android.com,
	tomeu.vizoso@collabora.com, pdaly@codeaurora.org,
	airlied@linux.ie, robin.murphy@arm.com,
	iommu@lists.linux-foundation.org,
	dri-devel@lists.freedesktop.org, steven.price@arm.com,
	alyssa.rosenzweig@collabora.com, daniel@ffwll.ch,
	freedreno@lists.freedesktop.org, sean@poorly.run,
	linux-arm-kernel@lists.infradead.org, pratikp@codeaurora.org
Subject: Re: [PATCH RESEND 0/7] iommu: Permit modular builds of io-pgtable drivers
Date: Wed, 6 Jan 2021 12:34:28 +0000	[thread overview]
Message-ID: <20210106123428.GA1798@willie-the-truck> (raw)
In-Reply-To: <1609832205-10055-1-git-send-email-isaacm@codeaurora.org>

On Mon, Jan 04, 2021 at 11:36:38PM -0800, Isaac J. Manjarres wrote:
> The goal of the Generic Kernel Image (GKI) effort is to have a common
> kernel image that works across multiple Android devices. This involves
> generating a kernel image that has core features integrated into it,
> while SoC specific functionality can be added to the kernel for the
> device as a module.
> 
> Along with modularizing IOMMU drivers, this also means building the
> io-pgtable code as modules, which allows for SoC vendors to only include
> the io-pgtable implementations that they use. For example, GKI for arm64
> must include support for both the IOMMU ARM LPAE/V7S formats at the
> moment. Having the code for both formats as modules allows SoC vendors
> to only provide the page table format that they use, along with their
> IOMMU driver.

Why is this desirable for upstream? This code isn't especially large, and
the formats we support are largely architectural, meaning that they are
shared between different IOMMU drivers. I think that making this modular
just means that out-of-tree modifications are likely to generate page-tables
which are specific to a particular IOMMU, and lead to horrible problems
(crashes and data corruption) if another IOMMU driver tries to use them.

Please can you upstream whatever changes you want to make instead?

Will
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID
From: Will Deacon <will@kernel.org>
To: "Isaac J. Manjarres" <isaacm@codeaurora.org>
Cc: kernel-team@android.com, tomeu.vizoso@collabora.com,
	pdaly@codeaurora.org, airlied@linux.ie, robin.murphy@arm.com,
	joro@8bytes.org, iommu@lists.linux-foundation.org,
	dri-devel@lists.freedesktop.org, steven.price@arm.com,
	robdclark@gmail.com, alyssa.rosenzweig@collabora.com,
	daniel@ffwll.ch, freedreno@lists.freedesktop.org,
	sean@poorly.run, linux-arm-kernel@lists.infradead.org,
	pratikp@codeaurora.org
Subject: Re: [PATCH RESEND 0/7] iommu: Permit modular builds of io-pgtable drivers
Date: Wed, 6 Jan 2021 12:34:28 +0000	[thread overview]
Message-ID: <20210106123428.GA1798@willie-the-truck> (raw)
In-Reply-To: <1609832205-10055-1-git-send-email-isaacm@codeaurora.org>

On Mon, Jan 04, 2021 at 11:36:38PM -0800, Isaac J. Manjarres wrote:
> The goal of the Generic Kernel Image (GKI) effort is to have a common
> kernel image that works across multiple Android devices. This involves
> generating a kernel image that has core features integrated into it,
> while SoC specific functionality can be added to the kernel for the
> device as a module.
> 
> Along with modularizing IOMMU drivers, this also means building the
> io-pgtable code as modules, which allows for SoC vendors to only include
> the io-pgtable implementations that they use. For example, GKI for arm64
> must include support for both the IOMMU ARM LPAE/V7S formats at the
> moment. Having the code for both formats as modules allows SoC vendors
> to only provide the page table format that they use, along with their
> IOMMU driver.

Why is this desirable for upstream? This code isn't especially large, and
the formats we support are largely architectural, meaning that they are
shared between different IOMMU drivers. I think that making this modular
just means that out-of-tree modifications are likely to generate page-tables
which are specific to a particular IOMMU, and lead to horrible problems
(crashes and data corruption) if another IOMMU driver tries to use them.

Please can you upstream whatever changes you want to make instead?

Will

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

WARNING: multiple messages have this Message-ID
From: Will Deacon <will@kernel.org>
To: "Isaac J. Manjarres" <isaacm@codeaurora.org>
Cc: kernel-team@android.com, tomeu.vizoso@collabora.com,
	pdaly@codeaurora.org, airlied@linux.ie, robin.murphy@arm.com,
	joro@8bytes.org, iommu@lists.linux-foundation.org,
	dri-devel@lists.freedesktop.org, steven.price@arm.com,
	alyssa.rosenzweig@collabora.com, freedreno@lists.freedesktop.org,
	sean@poorly.run, linux-arm-kernel@lists.infradead.org,
	pratikp@codeaurora.org
Subject: Re: [PATCH RESEND 0/7] iommu: Permit modular builds of io-pgtable drivers
Date: Wed, 6 Jan 2021 12:34:28 +0000	[thread overview]
Message-ID: <20210106123428.GA1798@willie-the-truck> (raw)
In-Reply-To: <1609832205-10055-1-git-send-email-isaacm@codeaurora.org>

On Mon, Jan 04, 2021 at 11:36:38PM -0800, Isaac J. Manjarres wrote:
> The goal of the Generic Kernel Image (GKI) effort is to have a common
> kernel image that works across multiple Android devices. This involves
> generating a kernel image that has core features integrated into it,
> while SoC specific functionality can be added to the kernel for the
> device as a module.
> 
> Along with modularizing IOMMU drivers, this also means building the
> io-pgtable code as modules, which allows for SoC vendors to only include
> the io-pgtable implementations that they use. For example, GKI for arm64
> must include support for both the IOMMU ARM LPAE/V7S formats at the
> moment. Having the code for both formats as modules allows SoC vendors
> to only provide the page table format that they use, along with their
> IOMMU driver.

Why is this desirable for upstream? This code isn't especially large, and
the formats we support are largely architectural, meaning that they are
shared between different IOMMU drivers. I think that making this modular
just means that out-of-tree modifications are likely to generate page-tables
which are specific to a particular IOMMU, and lead to horrible problems
(crashes and data corruption) if another IOMMU driver tries to use them.

Please can you upstream whatever changes you want to make instead?

Will
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2021-01-06 12:34 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-05  7:36 Isaac J. Manjarres
2021-01-05  7:36 ` Isaac J. Manjarres
2021-01-05  7:36 ` [PATCH RESEND 1/7] iommu/io-pgtable: Introduce dynamic io-pgtable format registration Isaac J. Manjarres
2021-01-05  7:36   ` Isaac J. Manjarres
2021-01-05  7:36 ` [PATCH RESEND 2/7] iommu/io-pgtable: Add refcounting for io-pgtable format modules Isaac J. Manjarres
2021-01-05  7:36   ` Isaac J. Manjarres
2021-01-05  7:36 ` [PATCH RESEND 3/7] iommu/arm-smmu: Add dependency on " Isaac J. Manjarres
2021-01-05  7:36   ` Isaac J. Manjarres
2021-01-05  7:36 ` [PATCH RESEND 4/7] iommu/arm-smmu-v3: Add dependency on io-pgtable-arm format module Isaac J. Manjarres
2021-01-05  7:36   ` Isaac J. Manjarres
2021-01-05  7:36 ` [PATCH RESEND 5/7] drm/msm: " Isaac J. Manjarres
2021-01-05  7:36   ` Isaac J. Manjarres
2021-01-05  7:36 ` [PATCH RESEND 6/7] drm/panfrost: " Isaac J. Manjarres
2021-01-05  7:36   ` Isaac J. Manjarres
2021-01-05  7:36 ` [PATCH RESEND 7/7] iommu/io-pgtable-arm: Allow building modular io-pgtable formats Isaac J. Manjarres
2021-01-05  7:36   ` Isaac J. Manjarres
2021-01-06 12:34 ` Will Deacon [this message]
2021-01-06 12:34   ` [PATCH RESEND 0/7] iommu: Permit modular builds of io-pgtable drivers Will Deacon
2021-01-06 12:34   ` Will Deacon

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=20210106123428.GA1798@willie-the-truck \
    --to=will@kernel.org \
    --cc=airlied@linux.ie \
    --cc=alyssa.rosenzweig@collabora.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=isaacm@codeaurora.org \
    --cc=kernel-team@android.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=pdaly@codeaurora.org \
    --cc=pratikp@codeaurora.org \
    --cc=robh@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=sean@poorly.run \
    --cc=steven.price@arm.com \
    --cc=tomeu.vizoso@collabora.com \
    --subject='Re: [PATCH RESEND 0/7] iommu: Permit modular builds of io-pgtable drivers' \
    /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

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.