Re: [PATCH] dt-bindings: Improve phandle-array schemas
On Tue, Jan 18, 2022 at 07:50:38PM -0600, Rob Herring wrote: > The 'phandle-array' type is a bit ambiguous. It can be either just an > array of phandles or an array of phandles plus args. Many schemas for > phandle-array properties aren't clear in the schema which case applies > though the description usually describes it. > > The array of phandles case boils down to needing: > > items: > maxItems: 1 > > The phandle plus args cases should typically take this form: > > items: > - items: > - description: A phandle > - description: 1st arg cell > - description: 2nd arg cell > > With this change, some examples need updating so that the bracketing of > property values matches the schema. > > Cc: Damien Le Moal > Cc: Herbert Xu > Cc: "David S. Miller" > Cc: Chun-Kuang Hu > Cc: Philipp Zabel > Cc: Laurent Pinchart > Cc: Kieran Bingham > Cc: Vinod Koul > Cc: Georgi Djakov > Cc: Thomas Gleixner > Cc: Marc Zyngier > Cc: Joerg Roedel > Cc: Lee Jones > Cc: Daniel Thompson > Cc: Jingoo Han > Cc: Pavel Machek > Cc: Mauro Carvalho Chehab > Cc: Krzysztof Kozlowski > Cc: Jakub Kicinski > Cc: Wolfgang Grandegger > Cc: Marc Kleine-Budde > Cc: Andrew Lunn > Cc: Vivien Didelot > Cc: Florian Fainelli > Cc: Vladimir Oltean > Cc: Kalle Valo > Cc: Viresh Kumar > Cc: Stephen Boyd > Cc: Kishon Vijay Abraham I > Cc: Linus Walleij > Cc: "Rafael J. Wysocki" > Cc: Kevin Hilman > Cc: Ulf Hansson > Cc: Sebastian Reichel > Cc: Mark Brown > Cc: Mathieu Poirier > Cc: Daniel Lezcano > Cc: Zhang Rui > Cc: Greg Kroah-Hartman > Cc: Thierry Reding > Cc: Jonathan Hunter > Cc: Sudeep Holla > Cc: Geert Uytterhoeven > Cc: linux-...@vger.kernel.org > Cc: linux-cry...@vger.kernel.org > Cc: dri-de...@lists.freedesktop.org > Cc: dmaeng...@vger.kernel.org > Cc: linux...@vger.kernel.org > Cc: iommu@lists.linux-foundation.org > Cc: linux-l...@vger.kernel.org > Cc: linux-me...@vger.kernel.org > Cc: net...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux-wirel...@vger.kernel.org > Cc: linux-...@lists.infradead.org > Cc: linux-g...@vger.kernel.org > Cc: linux-ri...@lists.infradead.org > Cc: linux-remotep...@vger.kernel.org > Cc: alsa-de...@alsa-project.org > Cc: linux-...@vger.kernel.org > Signed-off-by: Rob Herring Acked-by: Greg Kroah-Hartman ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] dt-bindings: Improve phandle-array schemas
Hi Rob, On Wed, Jan 19, 2022 at 2:50 AM Rob Herring wrote: > The 'phandle-array' type is a bit ambiguous. It can be either just an > array of phandles or an array of phandles plus args. Many schemas for > phandle-array properties aren't clear in the schema which case applies > though the description usually describes it. > > The array of phandles case boils down to needing: > > items: > maxItems: 1 > > The phandle plus args cases should typically take this form: > > items: > - items: > - description: A phandle > - description: 1st arg cell > - description: 2nd arg cell > > With this change, some examples need updating so that the bracketing of > property values matches the schema. > Signed-off-by: Rob Herring The Renesas parts look good to me. Reviewed-by: Geert Uytterhoeven Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] dt-bindings: Improve phandle-array schemas
On Wed, 19 Jan 2022 at 02:50, Rob Herring wrote: > > The 'phandle-array' type is a bit ambiguous. It can be either just an > array of phandles or an array of phandles plus args. Many schemas for > phandle-array properties aren't clear in the schema which case applies > though the description usually describes it. > > The array of phandles case boils down to needing: > > items: > maxItems: 1 > > The phandle plus args cases should typically take this form: > > items: > - items: > - description: A phandle > - description: 1st arg cell > - description: 2nd arg cell > > With this change, some examples need updating so that the bracketing of > property values matches the schema. > > Cc: Damien Le Moal > Cc: Herbert Xu > Cc: "David S. Miller" > Cc: Chun-Kuang Hu > Cc: Philipp Zabel > Cc: Laurent Pinchart > Cc: Kieran Bingham > Cc: Vinod Koul > Cc: Georgi Djakov > Cc: Thomas Gleixner > Cc: Marc Zyngier > Cc: Joerg Roedel > Cc: Lee Jones > Cc: Daniel Thompson > Cc: Jingoo Han > Cc: Pavel Machek > Cc: Mauro Carvalho Chehab > Cc: Krzysztof Kozlowski > Cc: Jakub Kicinski > Cc: Wolfgang Grandegger > Cc: Marc Kleine-Budde > Cc: Andrew Lunn > Cc: Vivien Didelot > Cc: Florian Fainelli > Cc: Vladimir Oltean > Cc: Kalle Valo > Cc: Viresh Kumar > Cc: Stephen Boyd > Cc: Kishon Vijay Abraham I > Cc: Linus Walleij > Cc: "Rafael J. Wysocki" > Cc: Kevin Hilman > Cc: Ulf Hansson > Cc: Sebastian Reichel > Cc: Mark Brown > Cc: Mathieu Poirier > Cc: Daniel Lezcano > Cc: Zhang Rui > Cc: Greg Kroah-Hartman > Cc: Thierry Reding > Cc: Jonathan Hunter > Cc: Sudeep Holla > Cc: Geert Uytterhoeven > Cc: linux-...@vger.kernel.org > Cc: linux-cry...@vger.kernel.org > Cc: dri-de...@lists.freedesktop.org > Cc: dmaeng...@vger.kernel.org > Cc: linux...@vger.kernel.org > Cc: iommu@lists.linux-foundation.org > Cc: linux-l...@vger.kernel.org > Cc: linux-me...@vger.kernel.org > Cc: net...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux-wirel...@vger.kernel.org > Cc: linux-...@lists.infradead.org > Cc: linux-g...@vger.kernel.org > Cc: linux-ri...@lists.infradead.org > Cc: linux-remotep...@vger.kernel.org > Cc: alsa-de...@alsa-project.org > Cc: linux-...@vger.kernel.org > Signed-off-by: Rob Herring > --- For CPUs and PM domains: Acked-by: Ulf Hansson Kind regards Uffe ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] dt-bindings: Improve phandle-array schemas
On 19.01.22 3:50, Rob Herring wrote: The 'phandle-array' type is a bit ambiguous. It can be either just an array of phandles or an array of phandles plus args. Many schemas for phandle-array properties aren't clear in the schema which case applies though the description usually describes it. The array of phandles case boils down to needing: items: maxItems: 1 The phandle plus args cases should typically take this form: items: - items: - description: A phandle - description: 1st arg cell - description: 2nd arg cell With this change, some examples need updating so that the bracketing of property values matches the schema. [..] .../bindings/interconnect/qcom,rpmh.yaml | 2 + Acked-by: Georgi Djakov ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] dt-bindings: Improve phandle-array schemas
On Wed, Jan 19, 2022 at 4:35 AM Vladimir Oltean wrote: > > On Tue, Jan 18, 2022 at 07:50:38PM -0600, Rob Herring wrote: > > The 'phandle-array' type is a bit ambiguous. It can be either just an > > array of phandles or an array of phandles plus args. Many schemas for > > phandle-array properties aren't clear in the schema which case applies > > though the description usually describes it. > > > > The array of phandles case boils down to needing: > > > > items: > > maxItems: 1 > > > > The phandle plus args cases should typically take this form: > > > > items: > > - items: > > - description: A phandle > > - description: 1st arg cell > > - description: 2nd arg cell > > > > With this change, some examples need updating so that the bracketing of > > property values matches the schema. > > --- > (...) > > diff --git a/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml > > b/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml > > index 702df848a71d..c504feeec6db 100644 > > --- a/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml > > +++ b/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml > > @@ -34,6 +34,8 @@ properties: > >full routing information must be given, not just the one hop > >routes to neighbouring switches > > $ref: /schemas/types.yaml#/definitions/phandle-array > > +items: > > + maxItems: 1 > > > >ethernet: > > description: > > For better or worse, the mainline cases of this property all take the > form of: > > arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts > link = <&switch1port9 &switch2port9>; > link = <&switch1port10 &switch0port10>; > arch/arm/boot/dts/vf610-zii-dev-rev-b.dts > link = <&switch1port6 > &switch2port9>; > link = <&switch1port5 > &switch0port5>; > arch/arm/boot/dts/vf610-zii-scu4-aib.dts > link = <&switch1port10 > &switch3port10 > &switch2port10>; > link = <&switch3port10 > &switch2port10>; > link = <&switch1port9 > &switch0port10>; > > So not really an array of phandles. Either form is an array. The DT yaml encoding maintains the bracketing, so how the schema is defined matters. To some extent the tools will process the schema to support both forms of bracketing, but this has turned out to be fragile and just doesn't work for phandle arrays. I'm working on further changes that will get rid of the yaml encoded DT format and validate DTB files directly. These obviously have no bracketing and needing the DTS source files to change goes away. However, to be able to construct the internal format for validation, I do need the schemas to have more information on what exactly the phandle-array contains. Rob ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] dt-bindings: Improve phandle-array schemas
On Wed, Jan 19, 2022 at 9:22 AM Arnaud POULIQUEN wrote: > > Hello Rob, > > On 1/19/22 2:50 AM, Rob Herring wrote: > > The 'phandle-array' type is a bit ambiguous. It can be either just an > > array of phandles or an array of phandles plus args. Many schemas for > > phandle-array properties aren't clear in the schema which case applies > > though the description usually describes it. > > > > The array of phandles case boils down to needing: > > > > items: > > maxItems: 1 > > > > The phandle plus args cases should typically take this form: > > > > items: > > - items: > > - description: A phandle > > - description: 1st arg cell > > - description: 2nd arg cell > > > > With this change, some examples need updating so that the bracketing of > > property values matches the schema. > > > > Cc: Damien Le Moal > > Cc: Herbert Xu > > Cc: "David S. Miller" > > Cc: Chun-Kuang Hu > > Cc: Philipp Zabel > > Cc: Laurent Pinchart > > Cc: Kieran Bingham > > Cc: Vinod Koul > > Cc: Georgi Djakov > > Cc: Thomas Gleixner > > Cc: Marc Zyngier > > Cc: Joerg Roedel > > Cc: Lee Jones > > Cc: Daniel Thompson > > Cc: Jingoo Han > > Cc: Pavel Machek > > Cc: Mauro Carvalho Chehab > > Cc: Krzysztof Kozlowski > > Cc: Jakub Kicinski > > Cc: Wolfgang Grandegger > > Cc: Marc Kleine-Budde > > Cc: Andrew Lunn > > Cc: Vivien Didelot > > Cc: Florian Fainelli > > Cc: Vladimir Oltean > > Cc: Kalle Valo > > Cc: Viresh Kumar > > Cc: Stephen Boyd > > Cc: Kishon Vijay Abraham I > > Cc: Linus Walleij > > Cc: "Rafael J. Wysocki" > > Cc: Kevin Hilman > > Cc: Ulf Hansson > > Cc: Sebastian Reichel > > Cc: Mark Brown > > Cc: Mathieu Poirier > > Cc: Daniel Lezcano > > Cc: Zhang Rui > > Cc: Greg Kroah-Hartman > > Cc: Thierry Reding > > Cc: Jonathan Hunter > > Cc: Sudeep Holla > > Cc: Geert Uytterhoeven > > Cc: linux-...@vger.kernel.org > > Cc: linux-cry...@vger.kernel.org > > Cc: dri-de...@lists.freedesktop.org > > Cc: dmaeng...@vger.kernel.org > > Cc: linux...@vger.kernel.org > > Cc: iommu@lists.linux-foundation.org > > Cc: linux-l...@vger.kernel.org > > Cc: linux-me...@vger.kernel.org > > Cc: net...@vger.kernel.org > > Cc: linux-...@vger.kernel.org > > Cc: linux-wirel...@vger.kernel.org > > Cc: linux-...@lists.infradead.org > > Cc: linux-g...@vger.kernel.org > > Cc: linux-ri...@lists.infradead.org > > Cc: linux-remotep...@vger.kernel.org > > Cc: alsa-de...@alsa-project.org > > Cc: linux-...@vger.kernel.org > > Signed-off-by: Rob Herring > > --- > > [...] > > > .../bindings/remoteproc/st,stm32-rproc.yaml | 33 ++-- > > [...] > > > diff --git > > a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml > > b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml > > index b587c97c282b..be3d9b0e876b 100644 > > --- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml > > +++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml > > @@ -29,17 +29,22 @@ properties: > > > >st,syscfg-holdboot: > > description: remote processor reset hold boot > > - - Phandle of syscon block. > > - - The offset of the hold boot setting register. > > - - The field mask of the hold boot. > > $ref: "/schemas/types.yaml#/definitions/phandle-array" > > -maxItems: 1 > > +items: > > + - items: > > + - description: Phandle of syscon block > > + - description: The offset of the hold boot setting register > > + - description: The field mask of the hold boot > > > >st,syscfg-tz: > > description: > >Reference to the system configuration which holds the RCC trust zone > > mode > > $ref: "/schemas/types.yaml#/definitions/phandle-array" > > -maxItems: 1 > > +items: > > + - items: > > + - description: Phandle of syscon block > > + - description: FIXME > > + - description: FIXME > > - description: The offset of the trust zone setting register > - description: The field mask of the trust zone state > > > > >interrupts: > > description: Should contain the WWDG1 watchdog reset interrupt > > @@ -93,20 +98,32 @@ properties: > > $ref: "/schemas/types.yaml#/definitions/phandle-array" > > description: | > >Reference to the system configuration which holds the remote > > -maxItems: 1 > > +items: > > + - items: > > + - description: Phandle of syscon block > > + - description: FIXME > > + - description: FIXME > > - description: The offset of the power setting register > - description: The field mask of the PDDS selection > > > > >st,syscfg-m4-state: > > $ref: "/schemas/types.yaml#/definitions/phandle-array" > > description: | > >Reference to the tamp register which exposes the Cortex-M4 state. > > -maxItems: 1 > > +items: > > + - items: > > + - description: Phandle of syscon block with the tamp register > > +
Re: [PATCH] dt-bindings: Improve phandle-array schemas
Hello Rob, On 1/19/22 2:50 AM, Rob Herring wrote: > The 'phandle-array' type is a bit ambiguous. It can be either just an > array of phandles or an array of phandles plus args. Many schemas for > phandle-array properties aren't clear in the schema which case applies > though the description usually describes it. > > The array of phandles case boils down to needing: > > items: > maxItems: 1 > > The phandle plus args cases should typically take this form: > > items: > - items: > - description: A phandle > - description: 1st arg cell > - description: 2nd arg cell > > With this change, some examples need updating so that the bracketing of > property values matches the schema. > > Cc: Damien Le Moal > Cc: Herbert Xu > Cc: "David S. Miller" > Cc: Chun-Kuang Hu > Cc: Philipp Zabel > Cc: Laurent Pinchart > Cc: Kieran Bingham > Cc: Vinod Koul > Cc: Georgi Djakov > Cc: Thomas Gleixner > Cc: Marc Zyngier > Cc: Joerg Roedel > Cc: Lee Jones > Cc: Daniel Thompson > Cc: Jingoo Han > Cc: Pavel Machek > Cc: Mauro Carvalho Chehab > Cc: Krzysztof Kozlowski > Cc: Jakub Kicinski > Cc: Wolfgang Grandegger > Cc: Marc Kleine-Budde > Cc: Andrew Lunn > Cc: Vivien Didelot > Cc: Florian Fainelli > Cc: Vladimir Oltean > Cc: Kalle Valo > Cc: Viresh Kumar > Cc: Stephen Boyd > Cc: Kishon Vijay Abraham I > Cc: Linus Walleij > Cc: "Rafael J. Wysocki" > Cc: Kevin Hilman > Cc: Ulf Hansson > Cc: Sebastian Reichel > Cc: Mark Brown > Cc: Mathieu Poirier > Cc: Daniel Lezcano > Cc: Zhang Rui > Cc: Greg Kroah-Hartman > Cc: Thierry Reding > Cc: Jonathan Hunter > Cc: Sudeep Holla > Cc: Geert Uytterhoeven > Cc: linux-...@vger.kernel.org > Cc: linux-cry...@vger.kernel.org > Cc: dri-de...@lists.freedesktop.org > Cc: dmaeng...@vger.kernel.org > Cc: linux...@vger.kernel.org > Cc: iommu@lists.linux-foundation.org > Cc: linux-l...@vger.kernel.org > Cc: linux-me...@vger.kernel.org > Cc: net...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux-wirel...@vger.kernel.org > Cc: linux-...@lists.infradead.org > Cc: linux-g...@vger.kernel.org > Cc: linux-ri...@lists.infradead.org > Cc: linux-remotep...@vger.kernel.org > Cc: alsa-de...@alsa-project.org > Cc: linux-...@vger.kernel.org > Signed-off-by: Rob Herring > --- [...] > .../bindings/remoteproc/st,stm32-rproc.yaml | 33 ++-- [...] > diff --git a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml > b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml > index b587c97c282b..be3d9b0e876b 100644 > --- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml > +++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml > @@ -29,17 +29,22 @@ properties: > >st,syscfg-holdboot: > description: remote processor reset hold boot > - - Phandle of syscon block. > - - The offset of the hold boot setting register. > - - The field mask of the hold boot. > $ref: "/schemas/types.yaml#/definitions/phandle-array" > -maxItems: 1 > +items: > + - items: > + - description: Phandle of syscon block > + - description: The offset of the hold boot setting register > + - description: The field mask of the hold boot > >st,syscfg-tz: > description: >Reference to the system configuration which holds the RCC trust zone > mode > $ref: "/schemas/types.yaml#/definitions/phandle-array" > -maxItems: 1 > +items: > + - items: > + - description: Phandle of syscon block > + - description: FIXME > + - description: FIXME - description: The offset of the trust zone setting register - description: The field mask of the trust zone state > >interrupts: > description: Should contain the WWDG1 watchdog reset interrupt > @@ -93,20 +98,32 @@ properties: > $ref: "/schemas/types.yaml#/definitions/phandle-array" > description: | >Reference to the system configuration which holds the remote > -maxItems: 1 > +items: > + - items: > + - description: Phandle of syscon block > + - description: FIXME > + - description: FIXME - description: The offset of the power setting register - description: The field mask of the PDDS selection > >st,syscfg-m4-state: > $ref: "/schemas/types.yaml#/definitions/phandle-array" > description: | >Reference to the tamp register which exposes the Cortex-M4 state. > -maxItems: 1 > +items: > + - items: > + - description: Phandle of syscon block with the tamp register > + - description: FIXME > + - description: FIXME - description: The offset of the tamp register - description: The field mask of the Cortex-M4 state > >st,syscfg-rsc-tbl: > $ref: "/schemas/types.yaml#/definitions/phandle-array" > description: | >Reference to the tamp register which references the C
Re: [PATCH] dt-bindings: Improve phandle-array schemas
On Tue, Jan 18, 2022 at 07:50:38PM -0600, Rob Herring wrote: > The 'phandle-array' type is a bit ambiguous. It can be either just an > array of phandles or an array of phandles plus args. Many schemas for > phandle-array properties aren't clear in the schema which case applies > though the description usually describes it. Acked-by: Mark Brown signature.asc Description: PGP signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] iommu/arm-smmu-v3: fix event handling soft lockup
During event processing, events are read from the event queue one by one until the queue is empty.If the master device continuously requests address access at the same time and the SMMU generates events, the cyclic processing of the event takes a long time and softlockup warnings may be reported. arm-smmu-v3 arm-smmu-v3.34.auto: event 0x0a received: arm-smmu-v3 arm-smmu-v3.34.auto:0x7f22280a arm-smmu-v3 arm-smmu-v3.34.auto:0x107e arm-smmu-v3 arm-smmu-v3.34.auto:0x034e8670 watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [irq/268-arm-smm:247] Call trace: _dev_info+0x7c/0xa0 arm_smmu_evtq_thread+0x1c0/0x230 irq_thread_fn+0x30/0x80 irq_thread+0x128/0x210 kthread+0x134/0x138 ret_from_fork+0x10/0x1c Kernel panic - not syncing: softlockup: hung tasks Fix this by calling cond_resched() after the event information is printed. Signed-off-by: Zhou Guanghui --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c index 6dc6d8b6b368..f60381cdf1c4 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c @@ -1558,6 +1558,7 @@ static irqreturn_t arm_smmu_evtq_thread(int irq, void *dev) dev_info(smmu->dev, "\t0x%016llx\n", (unsigned long long)evt[i]); + cond_resched(); } /* -- 2.17.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] dt-bindings: Improve phandle-array schemas
On Tue, Jan 18, 2022 at 07:50:38PM -0600, Rob Herring wrote: > The 'phandle-array' type is a bit ambiguous. It can be either just an > array of phandles or an array of phandles plus args. Many schemas for > phandle-array properties aren't clear in the schema which case applies > though the description usually describes it. > > The array of phandles case boils down to needing: > > items: > maxItems: 1 > > The phandle plus args cases should typically take this form: > > items: > - items: > - description: A phandle > - description: 1st arg cell > - description: 2nd arg cell > > With this change, some examples need updating so that the bracketing of > property values matches the schema. > --- (...) > diff --git a/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml > b/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml > index 702df848a71d..c504feeec6db 100644 > --- a/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml > +++ b/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml > @@ -34,6 +34,8 @@ properties: >full routing information must be given, not just the one hop >routes to neighbouring switches > $ref: /schemas/types.yaml#/definitions/phandle-array > +items: > + maxItems: 1 > >ethernet: > description: For better or worse, the mainline cases of this property all take the form of: arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts link = <&switch1port9 &switch2port9>; link = <&switch1port10 &switch0port10>; arch/arm/boot/dts/vf610-zii-dev-rev-b.dts link = <&switch1port6 &switch2port9>; link = <&switch1port5 &switch0port5>; arch/arm/boot/dts/vf610-zii-scu4-aib.dts link = <&switch1port10 &switch3port10 &switch2port10>; link = <&switch3port10 &switch2port10>; link = <&switch1port9 &switch0port10>; So not really an array of phandles. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] iommu/vt-d: Do not dump pasid table entries in kdump kernel
In kdump kernel PASID translations won't be copied from previous kernel even if scalable-mode is enabled, so pages of PASID translations are non-present in kdump kernel. Attempt to access those address will cause PF fault: [ 13.396476] DMAR: DRHD: handling fault status reg 3 [ 13.396478] DMAR: [DMA Read NO_PASID] Request device [81:00.0] fault addr 0xd000 [fault reason 0x59] SM: Present bit in PA$ [ 13.396480] DMAR: Dump dmar5 table entries for IOVA 0xd000 [ 13.396481] DMAR: scalable mode root entry: hi 0x, low 0x460d1001 [ 13.396482] DMAR: context entry: hi 0x0008, low 0x0010c4237401 [ 13.396485] BUG: unable to handle page fault for address: ff110010c4237000 [ 13.396486] #PF: supervisor read access in kernel mode [ 13.396487] #PF: error_code(0x) - not-present page [ 13.396488] PGD 5d201067 P4D 5d202067 PUD 0 [ 13.396490] Oops: [#1] PREEMPT SMP NOPTI [ 13.396491] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.16.0-rc6-next-20211224+ #6 [ 13.396493] Hardware name: Intel Corporation EAGLESTREAM/EAGLESTREAM, BIOS EGSDCRB1.86B.0067.D12.2110190950 10/19/2021 [ 13.396494] RIP: 0010:dmar_fault_dump_ptes+0x13b/0x295 Hence skip dumping pasid table entries if in kdump kernel. Fixes: 914ff7719e8a (“iommu/vt-d: Dump DMAR translation structure when DMA fault occurs”) Signed-off-by: Zelin Deng --- drivers/iommu/intel/iommu.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 92fea3fb..f0134cf 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -1074,6 +1074,12 @@ void dmar_fault_dump_ptes(struct intel_iommu *iommu, u16 source_id, if (!sm_supported(iommu)) goto pgtable_walk; + /* PASID translations is not copied, skip dumping pasid table entries +* otherwise non-present page will be accessed. +*/ + if (is_kdump_kernel()) + goto pgtable_walk; + /* get the pointer to pasid directory entry */ dir = phys_to_virt(ctx_entry->lo & VTD_PAGE_MASK); if (!dir) { -- 1.8.3.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v4 0/7] Use pageblock_order for cma and alloc_contig_range alignment.
From: Zi Yan Hi all, This patchset tries to remove the MAX_ORDER-1 alignment requirement for CMA and alloc_contig_range(). It prepares for my upcoming changes to make MAX_ORDER adjustable at boot time[1]. It is on top of mmotm-2021-12-29-20-07. Changelog from RFC === 1. Dropped two irrelevant patches on non-lru compound page handling, as it is not supported upstream. 2. Renamed migratetype_has_fallback() to migratetype_is_mergeable(). 3. Always check whether two pageblocks can be merged in __free_one_page() when order is >= pageblock_order, as the case (not mergeable pageblocks are isolated, CMA, and HIGHATOMIC) becomes more common. 3. Moving has_unmovable_pages() is now a separate patch. 4. Removed MAX_ORDER-1 alignment requirement in the comment in virtio_mem code. Description === The MAX_ORDER - 1 alignment requirement comes from that alloc_contig_range() isolates pageblocks to remove free memory from buddy allocator but isolating only a subset of pageblocks within a page spanning across multiple pageblocks causes free page accounting issues. Isolated page might not be put into the right free list, since the code assumes the migratetype of the first pageblock as the whole free page migratetype. This is based on the discussion at [2]. To remove the requirement, this patchset: 1. still isolates pageblocks at MAX_ORDER - 1 granularity; 2. but saves the pageblock migratetypes outside the specified range of alloc_contig_range() and restores them after all pages within the range become free after __alloc_contig_migrate_range(); 3. only checks unmovable pages within the range instead of MAX_ORDER - 1 aligned range during isolation to avoid alloc_contig_range() failure when pageblocks within a MAX_ORDER - 1 aligned range are allocated separately. 3. splits free pages spanning multiple pageblocks at the beginning and the end of the range and puts the split pages to the right migratetype free lists based on the pageblock migratetypes; 4. returns pages not in the range as it did before. Isolation needs to be done at MAX_ORDER - 1 granularity, because otherwise either 1) it is needed to detect to-be-isolated page size (free, PageHuge, THP, or other PageCompound) to make sure all pageblocks belonging to a single page are isolated together and later restore pageblock migratetypes outside the range, or 2) assuming isolation happens at pageblock granularity, a free page with multi-migratetype pageblocks can seen in free page path and needs to be split and freed at pageblock granularity. One optimization might come later: 1. make MIGRATE_ISOLATE a separate bit to avoid saving and restoring existing migratetypes before and after isolation respectively. Feel free to give comments and suggestions. Thanks. [1] https://lore.kernel.org/linux-mm/20210805190253.2795604-1-zi@sent.com/ [2] https://lore.kernel.org/linux-mm/d19fb078-cb9b-f60f-e310-fdeea1b94...@redhat.com/ Zi Yan (7): mm: page_alloc: avoid merging non-fallbackable pageblocks with others. mm: page_isolation: move has_unmovable_pages() to mm/page_isolation.c mm: page_isolation: check specified range for unmovable pages mm: make alloc_contig_range work at pageblock granularity mm: cma: use pageblock_order as the single alignment drivers: virtio_mem: use pageblock size as the minimum virtio_mem size. arch: powerpc: adjust fadump alignment to be pageblock aligned. arch/powerpc/include/asm/fadump-internal.h | 4 +- drivers/virtio/virtio_mem.c| 7 +- include/linux/mmzone.h | 16 +- include/linux/page-isolation.h | 3 +- kernel/dma/contiguous.c| 2 +- mm/cma.c | 6 +- mm/memory_hotplug.c| 12 +- mm/page_alloc.c| 337 +++-- mm/page_isolation.c| 154 +- 9 files changed, 352 insertions(+), 189 deletions(-) -- 2.34.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v4 1/7] mm: page_alloc: avoid merging non-fallbackable pageblocks with others.
From: Zi Yan This is done in addition to MIGRATE_ISOLATE pageblock merge avoidance. It prepares for the upcoming removal of the MAX_ORDER-1 alignment requirement for CMA and alloc_contig_range(). MIGRARTE_HIGHATOMIC should not merge with other migratetypes like MIGRATE_ISOLATE and MIGRARTE_CMA[1], so this commit prevents that too. Also add MIGRARTE_HIGHATOMIC to fallbacks array for completeness. [1] https://lore.kernel.org/linux-mm/20211130100853.gp3...@techsingularity.net/ Signed-off-by: Zi Yan --- include/linux/mmzone.h | 11 +++ mm/page_alloc.c| 37 - 2 files changed, 31 insertions(+), 17 deletions(-) diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h index aed44e9b5d89..71b77aab748d 100644 --- a/include/linux/mmzone.h +++ b/include/linux/mmzone.h @@ -83,6 +83,17 @@ static inline bool is_migrate_movable(int mt) return is_migrate_cma(mt) || mt == MIGRATE_MOVABLE; } +/* + * Check whether a migratetype can be merged with another migratetype. + * + * It is only mergeable when it can fall back to other migratetypes for + * allocation. See fallbacks[MIGRATE_TYPES][3] in page_alloc.c. + */ +static inline bool migratetype_is_mergeable(int mt) +{ + return mt < MIGRATE_PCPTYPES; +} + #define for_each_migratetype_order(order, type) \ for (order = 0; order < MAX_ORDER; order++) \ for (type = 0; type < MIGRATE_TYPES; type++) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 8dd6399bafb5..15de65215c02 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -1117,25 +1117,24 @@ static inline void __free_one_page(struct page *page, } if (order < MAX_ORDER - 1) { /* If we are here, it means order is >= pageblock_order. -* We want to prevent merge between freepages on isolate -* pageblock and normal pageblock. Without this, pageblock -* isolation could cause incorrect freepage or CMA accounting. +* We want to prevent merge between freepages on pageblock +* without fallbacks and normal pageblock. Without this, +* pageblock isolation could cause incorrect freepage or CMA +* accounting or HIGHATOMIC accounting. * * We don't want to hit this code for the more frequent * low-order merging. */ - if (unlikely(has_isolate_pageblock(zone))) { - int buddy_mt; + int buddy_mt; - buddy_pfn = __find_buddy_pfn(pfn, order); - buddy = page + (buddy_pfn - pfn); - buddy_mt = get_pageblock_migratetype(buddy); + buddy_pfn = __find_buddy_pfn(pfn, order); + buddy = page + (buddy_pfn - pfn); + buddy_mt = get_pageblock_migratetype(buddy); - if (migratetype != buddy_mt - && (is_migrate_isolate(migratetype) || - is_migrate_isolate(buddy_mt))) - goto done_merging; - } + if (migratetype != buddy_mt + && (!migratetype_is_mergeable(migratetype) || + !migratetype_is_mergeable(buddy_mt))) + goto done_merging; max_order = order + 1; goto continue_merging; } @@ -2484,6 +2483,7 @@ static int fallbacks[MIGRATE_TYPES][3] = { [MIGRATE_UNMOVABLE] = { MIGRATE_RECLAIMABLE, MIGRATE_MOVABLE, MIGRATE_TYPES }, [MIGRATE_MOVABLE] = { MIGRATE_RECLAIMABLE, MIGRATE_UNMOVABLE, MIGRATE_TYPES }, [MIGRATE_RECLAIMABLE] = { MIGRATE_UNMOVABLE, MIGRATE_MOVABLE, MIGRATE_TYPES }, + [MIGRATE_HIGHATOMIC] = { MIGRATE_TYPES }, /* Never used */ #ifdef CONFIG_CMA [MIGRATE_CMA] = { MIGRATE_TYPES }, /* Never used */ #endif @@ -2795,8 +2795,8 @@ static void reserve_highatomic_pageblock(struct page *page, struct zone *zone, /* Yoink! */ mt = get_pageblock_migratetype(page); - if (!is_migrate_highatomic(mt) && !is_migrate_isolate(mt) - && !is_migrate_cma(mt)) { + /* Only reserve normal pageblocks (i.e., they can merge with others) */ + if (migratetype_is_mergeable(mt)) { zone->nr_reserved_highatomic += pageblock_nr_pages; set_pageblock_migratetype(page, MIGRATE_HIGHATOMIC); move_freepages_block(zone, page, MIGRATE_HIGHATOMIC, NULL); @@ -3545,8 +3545,11 @@ int __isolate_free_page(struct page *page, unsigned int order) struct page *endpage = page + (1 << order) - 1; for (; page < endpage; page += pageblock_nr_pages) { int mt = get_pageblock_migratetype(page); - if (!is_migrate_isolate(mt) && !is
[PATCH v4 2/7] mm: page_isolation: move has_unmovable_pages() to mm/page_isolation.c
From: Zi Yan has_unmovable_pages() is only used in mm/page_isolation.c. Move it from mm/page_alloc.c and make it static. Signed-off-by: Zi Yan --- include/linux/page-isolation.h | 2 - mm/page_alloc.c| 119 - mm/page_isolation.c| 119 + 3 files changed, 119 insertions(+), 121 deletions(-) diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h index 572458016331..e14eddf6741a 100644 --- a/include/linux/page-isolation.h +++ b/include/linux/page-isolation.h @@ -33,8 +33,6 @@ static inline bool is_migrate_isolate(int migratetype) #define MEMORY_OFFLINE 0x1 #define REPORT_FAILURE 0x2 -struct page *has_unmovable_pages(struct zone *zone, struct page *page, -int migratetype, int flags); void set_pageblock_migratetype(struct page *page, int migratetype); int move_freepages_block(struct zone *zone, struct page *page, int migratetype, int *num_movable); diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 15de65215c02..1d812268c2a9 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -8859,125 +8859,6 @@ void *__init alloc_large_system_hash(const char *tablename, return table; } -/* - * This function checks whether pageblock includes unmovable pages or not. - * - * PageLRU check without isolation or lru_lock could race so that - * MIGRATE_MOVABLE block might include unmovable pages. And __PageMovable - * check without lock_page also may miss some movable non-lru pages at - * race condition. So you can't expect this function should be exact. - * - * Returns a page without holding a reference. If the caller wants to - * dereference that page (e.g., dumping), it has to make sure that it - * cannot get removed (e.g., via memory unplug) concurrently. - * - */ -struct page *has_unmovable_pages(struct zone *zone, struct page *page, -int migratetype, int flags) -{ - unsigned long iter = 0; - unsigned long pfn = page_to_pfn(page); - unsigned long offset = pfn % pageblock_nr_pages; - - if (is_migrate_cma_page(page)) { - /* -* CMA allocations (alloc_contig_range) really need to mark -* isolate CMA pageblocks even when they are not movable in fact -* so consider them movable here. -*/ - if (is_migrate_cma(migratetype)) - return NULL; - - return page; - } - - for (; iter < pageblock_nr_pages - offset; iter++) { - page = pfn_to_page(pfn + iter); - - /* -* Both, bootmem allocations and memory holes are marked -* PG_reserved and are unmovable. We can even have unmovable -* allocations inside ZONE_MOVABLE, for example when -* specifying "movablecore". -*/ - if (PageReserved(page)) - return page; - - /* -* If the zone is movable and we have ruled out all reserved -* pages then it should be reasonably safe to assume the rest -* is movable. -*/ - if (zone_idx(zone) == ZONE_MOVABLE) - continue; - - /* -* Hugepages are not in LRU lists, but they're movable. -* THPs are on the LRU, but need to be counted as #small pages. -* We need not scan over tail pages because we don't -* handle each tail page individually in migration. -*/ - if (PageHuge(page) || PageTransCompound(page)) { - struct page *head = compound_head(page); - unsigned int skip_pages; - - if (PageHuge(page)) { - if (!hugepage_migration_supported(page_hstate(head))) - return page; - } else if (!PageLRU(head) && !__PageMovable(head)) { - return page; - } - - skip_pages = compound_nr(head) - (page - head); - iter += skip_pages - 1; - continue; - } - - /* -* We can't use page_count without pin a page -* because another CPU can free compound page. -* This check already skips compound tails of THP -* because their page->_refcount is zero at all time. -*/ - if (!page_ref_count(page)) { - if (PageBuddy(page)) - iter += (1 << buddy_order(page)) - 1; - continue; - } - - /* -* The HWPoisoned page may be not in buddy system, and -
[PATCH v4 3/7] mm: page_isolation: check specified range for unmovable pages
From: Zi Yan Enable set_migratetype_isolate() to check specified sub-range for unmovable pages during isolation. Page isolation is done at max(MAX_ORDER_NR_PAEGS, pageblock_nr_pages) granularity, but not all pages within that granularity are intended to be isolated. For example, alloc_contig_range(), which uses page isolation, allows ranges without alignment. This commit makes unmovable page check only look for interesting pages, so that page isolation can succeed for any non-overlapping ranges. Signed-off-by: Zi Yan --- include/linux/page-isolation.h | 1 + mm/memory_hotplug.c| 12 +++- mm/page_alloc.c| 2 +- mm/page_isolation.c| 53 +- 4 files changed, 46 insertions(+), 22 deletions(-) diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h index e14eddf6741a..a4d2687ed4e6 100644 --- a/include/linux/page-isolation.h +++ b/include/linux/page-isolation.h @@ -42,6 +42,7 @@ int move_freepages_block(struct zone *zone, struct page *page, */ int start_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn, +unsigned long isolate_start, unsigned long isolate_end, unsigned migratetype, int flags); /* diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index 0139b77c51d5..5db84c3fa882 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -1901,8 +1901,18 @@ int __ref offline_pages(unsigned long start_pfn, unsigned long nr_pages, zone_pcp_disable(zone); lru_cache_disable(); - /* set above range as isolated */ + /* +* set above range as isolated +* +* start_pfn and end_pfn are the same as isolate_start and isolate_end, +* because start_pfn and end_pfn are already PAGES_PER_SECTION +* (>= MAX_ORDER_NR_PAGES) aligned; if start_pfn is +* pageblock_nr_pages aligned in memmap_on_memory case, there is no +* need to isolate pages before start_pfn, since they are used by +* memmap thus not user visible. +*/ ret = start_isolate_page_range(start_pfn, end_pfn, + start_pfn, end_pfn, MIGRATE_MOVABLE, MEMORY_OFFLINE | REPORT_FAILURE); if (ret) { diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 1d812268c2a9..812cf557b20f 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -9016,7 +9016,7 @@ int alloc_contig_range(unsigned long start, unsigned long end, * put back to page allocator so that buddy can use them. */ - ret = start_isolate_page_range(pfn_max_align_down(start), + ret = start_isolate_page_range(start, end, pfn_max_align_down(start), pfn_max_align_up(end), migratetype, 0); if (ret) return ret; diff --git a/mm/page_isolation.c b/mm/page_isolation.c index 6c841274bf46..d17ad9a7d4bf 100644 --- a/mm/page_isolation.c +++ b/mm/page_isolation.c @@ -16,7 +16,8 @@ #include /* - * This function checks whether pageblock includes unmovable pages or not. + * This function checks whether pageblock within [start_pfn, end_pfn) includes + * unmovable pages or not. * * PageLRU check without isolation or lru_lock could race so that * MIGRATE_MOVABLE block might include unmovable pages. And __PageMovable @@ -29,11 +30,14 @@ * */ static struct page *has_unmovable_pages(struct zone *zone, struct page *page, -int migratetype, int flags) +int migratetype, int flags, +unsigned long start_pfn, unsigned long end_pfn) { - unsigned long iter = 0; - unsigned long pfn = page_to_pfn(page); - unsigned long offset = pfn % pageblock_nr_pages; + unsigned long first_pfn = max(page_to_pfn(page), start_pfn); + unsigned long pfn = first_pfn; + unsigned long last_pfn = min(ALIGN(pfn + 1, pageblock_nr_pages), end_pfn); + + page = pfn_to_page(pfn); if (is_migrate_cma_page(page)) { /* @@ -47,8 +51,8 @@ static struct page *has_unmovable_pages(struct zone *zone, struct page *page, return page; } - for (; iter < pageblock_nr_pages - offset; iter++) { - page = pfn_to_page(pfn + iter); + for (pfn = first_pfn; pfn < last_pfn; pfn++) { + page = pfn_to_page(pfn); /* * Both, bootmem allocations and memory holes are marked @@ -85,7 +89,7 @@ static struct page *has_unmovable_pages(struct zone *zone, struct page *page, } skip_pages = compound_nr(head) - (page - head); - iter += skip_pages - 1; + pfn += skip_pages - 1; continue; } @@ -97,7 +101,7 @@ static s
[PATCH v4 5/7] mm: cma: use pageblock_order as the single alignment
From: Zi Yan Now alloc_contig_range() works at pageblock granularity. Change CMA allocation, which uses alloc_contig_range(), to use pageblock_order alignment. Signed-off-by: Zi Yan --- include/linux/mmzone.h | 5 + kernel/dma/contiguous.c | 2 +- mm/cma.c| 6 ++ mm/page_alloc.c | 6 +++--- 4 files changed, 7 insertions(+), 12 deletions(-) diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h index 71b77aab748d..7bd3694b24b4 100644 --- a/include/linux/mmzone.h +++ b/include/linux/mmzone.h @@ -54,10 +54,7 @@ enum migratetype { * * The way to use it is to change migratetype of a range of * pageblocks to MIGRATE_CMA which can be done by -* __free_pageblock_cma() function. What is important though -* is that a range of pageblocks must be aligned to -* MAX_ORDER_NR_PAGES should biggest page be bigger than -* a single pageblock. +* __free_pageblock_cma() function. */ MIGRATE_CMA, #endif diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c index 3d63d91cba5c..ac35b14b0786 100644 --- a/kernel/dma/contiguous.c +++ b/kernel/dma/contiguous.c @@ -399,7 +399,7 @@ static const struct reserved_mem_ops rmem_cma_ops = { static int __init rmem_cma_setup(struct reserved_mem *rmem) { - phys_addr_t align = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order); + phys_addr_t align = PAGE_SIZE << pageblock_order; phys_addr_t mask = align - 1; unsigned long node = rmem->fdt_node; bool default_cma = of_get_flat_dt_prop(node, "linux,cma-default", NULL); diff --git a/mm/cma.c b/mm/cma.c index bc9ca8f3c487..d171158bd418 100644 --- a/mm/cma.c +++ b/mm/cma.c @@ -180,8 +180,7 @@ int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size, return -EINVAL; /* ensure minimal alignment required by mm core */ - alignment = PAGE_SIZE << - max_t(unsigned long, MAX_ORDER - 1, pageblock_order); + alignment = PAGE_SIZE << pageblock_order; /* alignment should be aligned with order_per_bit */ if (!IS_ALIGNED(alignment >> PAGE_SHIFT, 1 << order_per_bit)) @@ -268,8 +267,7 @@ int __init cma_declare_contiguous_nid(phys_addr_t base, * migratetype page by page allocator's buddy algorithm. In the case, * you couldn't get a contiguous memory, which is not what we want. */ - alignment = max(alignment, (phys_addr_t)PAGE_SIZE << - max_t(unsigned long, MAX_ORDER - 1, pageblock_order)); + alignment = max(alignment, (phys_addr_t)PAGE_SIZE << pageblock_order); if (fixed && base & (alignment - 1)) { ret = -EINVAL; pr_err("Region at %pa must be aligned to %pa bytes\n", diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 6ed506234efa..a8ced1a00ce8 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -9008,8 +9008,8 @@ static inline void split_free_page_into_pageblocks(struct page *free_page, * be either of the two. * @gfp_mask: GFP mask to use during compaction * - * The PFN range does not have to be pageblock or MAX_ORDER_NR_PAGES - * aligned. The PFN range must belong to a single zone. + * The PFN range does not have to be pageblock aligned. The PFN range must + * belong to a single zone. * * The first thing this routine does is attempt to MIGRATE_ISOLATE all * pageblocks in the range. Once isolated, the pageblocks should not @@ -9125,7 +9125,7 @@ int alloc_contig_range(unsigned long start, unsigned long end, ret = 0; /* -* Pages from [start, end) are within a MAX_ORDER_NR_PAGES +* Pages from [start, end) are within a pageblock_nr_pages * aligned blocks that are marked as MIGRATE_ISOLATE. What's * more, all pages in [start, end) are free in page allocator. * What we are going to do is to allocate all pages from -- 2.34.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v4 7/7] arch: powerpc: adjust fadump alignment to be pageblock aligned.
From: Zi Yan CMA only requires pageblock alignment now. Change CMA alignment in fadump too. Signed-off-by: Zi Yan --- arch/powerpc/include/asm/fadump-internal.h | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/powerpc/include/asm/fadump-internal.h b/arch/powerpc/include/asm/fadump-internal.h index 52189928ec08..fbfca85b4200 100644 --- a/arch/powerpc/include/asm/fadump-internal.h +++ b/arch/powerpc/include/asm/fadump-internal.h @@ -20,9 +20,7 @@ #define memblock_num_regions(memblock_type)(memblock.memblock_type.cnt) /* Alignment per CMA requirement. */ -#define FADUMP_CMA_ALIGNMENT (PAGE_SIZE << \ -max_t(unsigned long, MAX_ORDER - 1,\ -pageblock_order)) +#define FADUMP_CMA_ALIGNMENT (PAGE_SIZE << pageblock_order) /* FAD commands */ #define FADUMP_REGISTER1 -- 2.34.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v4 4/7] mm: make alloc_contig_range work at pageblock granularity
From: Zi Yan alloc_contig_range() worked at MAX_ORDER-1 granularity to avoid merging pageblocks with different migratetypes. It might unnecessarily convert extra pageblocks at the beginning and at the end of the range. Change alloc_contig_range() to work at pageblock granularity. It is done by restoring pageblock types and split >pageblock_order free pages after isolating at MAX_ORDER-1 granularity and migrating pages away at pageblock granularity. The reason for this process is that during isolation, some pages, either free or in-use, might have >pageblock sizes and isolating part of them can cause free accounting issues. Restoring the migratetypes of the pageblocks not in the interesting range later is much easier. Signed-off-by: Zi Yan --- mm/page_alloc.c | 175 ++-- 1 file changed, 155 insertions(+), 20 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 812cf557b20f..6ed506234efa 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -8862,8 +8862,8 @@ void *__init alloc_large_system_hash(const char *tablename, #ifdef CONFIG_CONTIG_ALLOC static unsigned long pfn_max_align_down(unsigned long pfn) { - return pfn & ~(max_t(unsigned long, MAX_ORDER_NR_PAGES, -pageblock_nr_pages) - 1); + return ALIGN_DOWN(pfn, max_t(unsigned long, MAX_ORDER_NR_PAGES, +pageblock_nr_pages)); } static unsigned long pfn_max_align_up(unsigned long pfn) @@ -8952,6 +8952,52 @@ static int __alloc_contig_migrate_range(struct compact_control *cc, return 0; } +static inline int save_migratetypes(unsigned char *migratetypes, + unsigned long start_pfn, unsigned long end_pfn) +{ + unsigned long pfn = start_pfn; + int num = 0; + + while (pfn < end_pfn) { + migratetypes[num] = get_pageblock_migratetype(pfn_to_page(pfn)); + num++; + pfn += pageblock_nr_pages; + } + return num; +} + +static inline int restore_migratetypes(unsigned char *migratetypes, + unsigned long start_pfn, unsigned long end_pfn) +{ + unsigned long pfn = start_pfn; + int num = 0; + + while (pfn < end_pfn) { + set_pageblock_migratetype(pfn_to_page(pfn), migratetypes[num]); + num++; + pfn += pageblock_nr_pages; + } + return num; +} + +static inline void split_free_page_into_pageblocks(struct page *free_page, + int order, struct zone *zone) +{ + unsigned long pfn; + + spin_lock(&zone->lock); + del_page_from_free_list(free_page, zone, order); + for (pfn = page_to_pfn(free_page); +pfn < page_to_pfn(free_page) + (1UL << order); +pfn += pageblock_nr_pages) { + int mt = get_pfnblock_migratetype(pfn_to_page(pfn), pfn); + + __free_one_page(pfn_to_page(pfn), pfn, zone, pageblock_order, + mt, FPI_NONE); + } + spin_unlock(&zone->lock); +} + /** * alloc_contig_range() -- tries to allocate given range of pages * @start: start PFN to allocate @@ -8977,8 +9023,15 @@ int alloc_contig_range(unsigned long start, unsigned long end, unsigned migratetype, gfp_t gfp_mask) { unsigned long outer_start, outer_end; + unsigned long isolate_start = pfn_max_align_down(start); + unsigned long isolate_end = pfn_max_align_up(end); + unsigned long alloc_start = ALIGN_DOWN(start, pageblock_nr_pages); + unsigned long alloc_end = ALIGN(end, pageblock_nr_pages); + unsigned long num_pageblock_to_save; unsigned int order; int ret = 0; + unsigned char *saved_mt; + int num; struct compact_control cc = { .nr_migratepages = 0, @@ -8992,11 +9045,30 @@ int alloc_contig_range(unsigned long start, unsigned long end, }; INIT_LIST_HEAD(&cc.migratepages); + /* +* TODO: make MIGRATE_ISOLATE a standalone bit to avoid overwriting +* the exiting migratetype. Then, we will not need the save and restore +* process here. +*/ + + /* Save the migratepages of the pageblocks before start and after end */ + num_pageblock_to_save = (alloc_start - isolate_start) / pageblock_nr_pages + + (isolate_end - alloc_end) / pageblock_nr_pages; + saved_mt = + kmalloc_array(num_pageblock_to_save, + sizeof(unsigned char), GFP_KERNEL); + if (!saved_mt) + return -ENOMEM; + + num = save_migratetypes(saved_mt, isolate_start, alloc_start); + + num = save_migratetypes(&saved_mt[num], alloc_end, isolate_end); + /* * What we do here is we mark all pageblocks in range as * MIGRATE_ISOLATE. Because pageblock and max order pages
[PATCH v4 6/7] drivers: virtio_mem: use pageblock size as the minimum virtio_mem size.
From: Zi Yan alloc_contig_range() now only needs to be aligned to pageblock_order, drop virtio_mem size requirement that it needs to be the max of pageblock_order and MAX_ORDER. Signed-off-by: Zi Yan --- drivers/virtio/virtio_mem.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c index a6a78685cfbe..eafba2119ae3 100644 --- a/drivers/virtio/virtio_mem.c +++ b/drivers/virtio/virtio_mem.c @@ -2476,13 +2476,12 @@ static int virtio_mem_init_hotplug(struct virtio_mem *vm) VIRTIO_MEM_DEFAULT_OFFLINE_THRESHOLD); /* -* We want subblocks to span at least MAX_ORDER_NR_PAGES and -* pageblock_nr_pages pages. This: +* We want subblocks to span at least pageblock_nr_pages pages. +* This: * - Is required for now for alloc_contig_range() to work reliably - * it doesn't properly handle smaller granularity on ZONE_NORMAL. */ - sb_size = max_t(uint64_t, MAX_ORDER_NR_PAGES, - pageblock_nr_pages) * PAGE_SIZE; + sb_size = pageblock_nr_pages * PAGE_SIZE; sb_size = max_t(uint64_t, vm->device_block_size, sb_size); if (sb_size < memory_block_size_bytes() && !force_bbm) { -- 2.34.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] dt-bindings: Improve phandle-array schemas
Quoting Rob Herring (2022-01-18 17:50:38) > The 'phandle-array' type is a bit ambiguous. It can be either just an > array of phandles or an array of phandles plus args. Many schemas for > phandle-array properties aren't clear in the schema which case applies > though the description usually describes it. > > The array of phandles case boils down to needing: > > items: > maxItems: 1 > > The phandle plus args cases should typically take this form: > > items: > - items: > - description: A phandle > - description: 1st arg cell > - description: 2nd arg cell > > With this change, some examples need updating so that the bracketing of > property values matches the schema. [..] > Signed-off-by: Rob Herring > --- Acked-by: Stephen Boyd ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/vt-d: Do not dump pasid table entries in kdump kernel
On 1/19/22 5:07 PM, Zelin Deng wrote: In kdump kernel PASID translations won't be copied from previous kernel even if scalable-mode is enabled, so pages of PASID translations are Yes. The copy table support for scalable mode is still in my task list. non-present in kdump kernel. Attempt to access those address will cause PF fault: [ 13.396476] DMAR: DRHD: handling fault status reg 3 [ 13.396478] DMAR: [DMA Read NO_PASID] Request device [81:00.0] fault addr 0xd000 [fault reason 0x59] SM: Present bit in PA$ [ 13.396480] DMAR: Dump dmar5 table entries for IOVA 0xd000 [ 13.396481] DMAR: scalable mode root entry: hi 0x, low 0x460d1001 [ 13.396482] DMAR: context entry: hi 0x0008, low 0x0010c4237401 [ 13.396485] BUG: unable to handle page fault for address: ff110010c4237000 [ 13.396486] #PF: supervisor read access in kernel mode [ 13.396487] #PF: error_code(0x) - not-present page [ 13.396488] PGD 5d201067 P4D 5d202067 PUD 0 [ 13.396490] Oops: [#1] PREEMPT SMP NOPTI [ 13.396491] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.16.0-rc6-next-20211224+ #6 [ 13.396493] Hardware name: Intel Corporation EAGLESTREAM/EAGLESTREAM, BIOS EGSDCRB1.86B.0067.D12.2110190950 10/19/2021 [ 13.396494] RIP: 0010:dmar_fault_dump_ptes+0x13b/0x295 Hence skip dumping pasid table entries if in kdump kernel. This just asks dmar_fault_dump_ptes() to keep silent. The problem is that the context entry is mis-configured. Perhaps we should disable copy table for scalable mode for now. How about below change? --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -3337,10 +3337,11 @@ static int __init init_dmars(void) init_translation_status(iommu); - if (translation_pre_enabled(iommu) && !is_kdump_kernel()) { + if (translation_pre_enabled(iommu) && + (!is_kdump_kernel() || sm_supported(iommu))) { iommu_disable_translation(iommu); clear_translation_pre_enabled(iommu); - pr_warn("Translation was enabled for %s but we are not in kdump mode\n", + pr_warn("Translation was enabled for %s but we are not in kdump mode or copy table not supported\n", iommu->name); } Fixes: 914ff7719e8a (“iommu/vt-d: Dump DMAR translation structure when DMA fault occurs”) Signed-off-by: Zelin Deng --- drivers/iommu/intel/iommu.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 92fea3fb..f0134cf 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -1074,6 +1074,12 @@ void dmar_fault_dump_ptes(struct intel_iommu *iommu, u16 source_id, if (!sm_supported(iommu)) goto pgtable_walk; + /* PASID translations is not copied, skip dumping pasid table entries +* otherwise non-present page will be accessed. +*/ + if (is_kdump_kernel()) + goto pgtable_walk; + /* get the pointer to pasid directory entry */ dir = phys_to_virt(ctx_entry->lo & VTD_PAGE_MASK); if (!dir) { Best regards, baolu ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/vt-d: Do not dump pasid table entries in kdump kernel
在 2022/1/20 上午10:58, Lu Baolu 写道: On 1/19/22 5:07 PM, Zelin Deng wrote: In kdump kernel PASID translations won't be copied from previous kernel even if scalable-mode is enabled, so pages of PASID translations are Yes. The copy table support for scalable mode is still in my task list. non-present in kdump kernel. Attempt to access those address will cause PF fault: [ 13.396476] DMAR: DRHD: handling fault status reg 3 [ 13.396478] DMAR: [DMA Read NO_PASID] Request device [81:00.0] fault addr 0xd000 [fault reason 0x59] SM: Present bit in PA$ [ 13.396480] DMAR: Dump dmar5 table entries for IOVA 0xd000 [ 13.396481] DMAR: scalable mode root entry: hi 0x, low 0x460d1001 [ 13.396482] DMAR: context entry: hi 0x0008, low 0x0010c4237401 [ 13.396485] BUG: unable to handle page fault for address: ff110010c4237000 [ 13.396486] #PF: supervisor read access in kernel mode [ 13.396487] #PF: error_code(0x) - not-present page [ 13.396488] PGD 5d201067 P4D 5d202067 PUD 0 [ 13.396490] Oops: [#1] PREEMPT SMP NOPTI [ 13.396491] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.16.0-rc6-next-20211224+ #6 [ 13.396493] Hardware name: Intel Corporation EAGLESTREAM/EAGLESTREAM, BIOS EGSDCRB1.86B.0067.D12.2110190950 10/19/2021 [ 13.396494] RIP: 0010:dmar_fault_dump_ptes+0x13b/0x295 Hence skip dumping pasid table entries if in kdump kernel. This just asks dmar_fault_dump_ptes() to keep silent. The problem is that the context entry is mis-configured. Perhaps we should disable copy table for scalable mode for now. How about below change? Yep. The change looks good to me. Actually I had encountered another issue which had blocked virtio-net device when scalable mode is enabled in kdump kernel so that I had made the same change as yours -- 'to disable translation if sm_on in kdump kernel' in our internal tree. I only observe this issue on our dragonfly baremetal server with virtio-net device inside, I did't send the fix to upstream as I am not sure if it is reasonable to disable translation in kdump kernel. --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -3337,10 +3337,11 @@ static int __init init_dmars(void) init_translation_status(iommu); - if (translation_pre_enabled(iommu) && !is_kdump_kernel()) { + if (translation_pre_enabled(iommu) && + (!is_kdump_kernel() || sm_supported(iommu))) { iommu_disable_translation(iommu); clear_translation_pre_enabled(iommu); - pr_warn("Translation was enabled for %s but we are not in kdump mode\n", + pr_warn("Translation was enabled for %s but we are not in kdump mode or copy table not supported\n", iommu->name); } Fixes: 914ff7719e8a (“iommu/vt-d: Dump DMAR translation structure when DMA fault occurs”) Signed-off-by: Zelin Deng --- drivers/iommu/intel/iommu.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 92fea3fb..f0134cf 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -1074,6 +1074,12 @@ void dmar_fault_dump_ptes(struct intel_iommu *iommu, u16 source_id, if (!sm_supported(iommu)) goto pgtable_walk; + /* PASID translations is not copied, skip dumping pasid table entries + * otherwise non-present page will be accessed. + */ + if (is_kdump_kernel()) + goto pgtable_walk; + /* get the pointer to pasid directory entry */ dir = phys_to_virt(ctx_entry->lo & VTD_PAGE_MASK); if (!dir) { Best regards, baolu ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] dt-bindings: Improve phandle-array schemas
On 18-01-22, 19:50, Rob Herring wrote: > The 'phandle-array' type is a bit ambiguous. It can be either just an > array of phandles or an array of phandles plus args. Many schemas for > phandle-array properties aren't clear in the schema which case applies > though the description usually describes it. > > The array of phandles case boils down to needing: > > items: > maxItems: 1 > > The phandle plus args cases should typically take this form: > > items: > - items: > - description: A phandle > - description: 1st arg cell > - description: 2nd arg cell > > With this change, some examples need updating so that the bracketing of > property values matches the schema. Acked-By: Vinod Koul -- ~Vinod ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu