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 (diff)
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 (diff)
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
next prev 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 [PATCH RESEND 0/7] iommu: Permit modular builds of io-pgtable drivers 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 \
/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.