* Re: [PATCH v3 net-next 1/8] sctp: setsockopt, expand some #defines
From: Marcelo Ricardo Leitner @ 2020-05-29 16:12 UTC (permalink / raw)
To: David Miller
Cc: David.Laight, vyasevich, nhorman, kuba, linux-sctp, netdev, hch
In-Reply-To: <20200526.153631.1486651154492951372.davem@davemloft.net>
On Tue, May 26, 2020 at 03:36:31PM -0700, David Miller wrote:
> From: David Laight <David.Laight@ACULAB.COM>
> Date: Tue, 26 May 2020 16:44:07 +0000
>
> > This should be 3/8.
>
> David just respin this at some point and with this fixed and also the
> header posting saying "0/8" properly instead of "0/1", this is really
> messy.
>
> Thanks.
I don't know why David's workflow is that cumbersome. I'll try to
respin this myself, on top of Christoph's latest changes.
^ permalink raw reply
* [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Discard a misplaced GGTT vma
From: Patchwork @ 2020-05-29 16:11 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
In-Reply-To: <20200529130019.17977-1-chris@chris-wilson.co.uk>
== Series Details ==
Series: drm/i915: Discard a misplaced GGTT vma
URL : https://patchwork.freedesktop.org/series/77786/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8553_full -> Patchwork_17818_full
====================================================
Summary
-------
**SUCCESS**
No regressions found.
Known issues
------------
Here are the changes found in Patchwork_17818_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_exec_whisper@basic-fds-forked-all:
- shard-hsw: [PASS][1] -> [INCOMPLETE][2] ([i915#61])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-hsw2/igt@gem_exec_whisper@basic-fds-forked-all.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-hsw2/igt@gem_exec_whisper@basic-fds-forked-all.html
* igt@i915_suspend@debugfs-reader:
- shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#180])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-apl4/igt@i915_suspend@debugfs-reader.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-apl4/igt@i915_suspend@debugfs-reader.html
* igt@kms_cursor_crc@pipe-a-cursor-64x64-random:
- shard-kbl: [PASS][5] -> [FAIL][6] ([i915#54] / [i915#93] / [i915#95])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-kbl1/igt@kms_cursor_crc@pipe-a-cursor-64x64-random.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-kbl4/igt@kms_cursor_crc@pipe-a-cursor-64x64-random.html
* igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
- shard-hsw: [PASS][7] -> [INCOMPLETE][8] ([i915#1926] / [i915#61])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-hsw2/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-hsw7/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy.html
* igt@kms_hdr@bpc-switch-dpms:
- shard-skl: [PASS][9] -> [FAIL][10] ([i915#1188])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-skl3/igt@kms_hdr@bpc-switch-dpms.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-skl6/igt@kms_hdr@bpc-switch-dpms.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#180])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-kbl1/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-kbl2/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min:
- shard-skl: [PASS][13] -> [FAIL][14] ([fdo#108145] / [i915#265])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-skl4/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-skl7/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html
* igt@kms_psr2_su@frontbuffer:
- shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109642] / [fdo#111068])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-iclb2/igt@kms_psr2_su@frontbuffer.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-iclb5/igt@kms_psr2_su@frontbuffer.html
* igt@kms_psr@psr2_cursor_render:
- shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-iclb2/igt@kms_psr@psr2_cursor_render.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-iclb6/igt@kms_psr@psr2_cursor_render.html
#### Possible fixes ####
* igt@gem_eio@in-flight-suspend:
- shard-apl: [DMESG-WARN][19] ([i915#180]) -> [PASS][20]
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-apl1/igt@gem_eio@in-flight-suspend.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-apl1/igt@gem_eio@in-flight-suspend.html
* {igt@gem_exec_reloc@basic-concurrent0}:
- shard-apl: [FAIL][21] ([i915#1930]) -> [PASS][22]
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-apl6/igt@gem_exec_reloc@basic-concurrent0.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-apl8/igt@gem_exec_reloc@basic-concurrent0.html
* igt@i915_suspend@fence-restore-untiled:
- shard-kbl: [DMESG-WARN][23] ([i915#180]) -> [PASS][24] +2 similar issues
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-kbl1/igt@i915_suspend@fence-restore-untiled.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-kbl4/igt@i915_suspend@fence-restore-untiled.html
* {igt@kms_atomic_transition@plane-all-modeset-transition-fencing@pipe-c}:
- shard-kbl: [DMESG-WARN][25] ([i915#165] / [i915#180]) -> [PASS][26]
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-kbl2/igt@kms_atomic_transition@plane-all-modeset-transition-fencing@pipe-c.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-kbl4/igt@kms_atomic_transition@plane-all-modeset-transition-fencing@pipe-c.html
* igt@kms_cursor_crc@pipe-c-cursor-64x64-onscreen:
- shard-skl: [FAIL][27] ([i915#54]) -> [PASS][28]
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-skl8/igt@kms_cursor_crc@pipe-c-cursor-64x64-onscreen.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-skl8/igt@kms_cursor_crc@pipe-c-cursor-64x64-onscreen.html
* igt@kms_cursor_legacy@cursora-vs-flipb-toggle:
- shard-glk: [DMESG-FAIL][29] ([i915#1925] / [i915#1926]) -> [PASS][30]
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-glk7/igt@kms_cursor_legacy@cursora-vs-flipb-toggle.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-glk7/igt@kms_cursor_legacy@cursora-vs-flipb-toggle.html
* igt@kms_fbcon_fbt@psr-suspend:
- shard-iclb: [INCOMPLETE][31] ([i915#1185]) -> [PASS][32]
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-iclb3/igt@kms_fbcon_fbt@psr-suspend.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-iclb4/igt@kms_fbcon_fbt@psr-suspend.html
* {igt@kms_flip@flip-vs-expired-vblank@b-edp1}:
- shard-skl: [FAIL][33] ([i915#79]) -> [PASS][34]
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-skl5/igt@kms_flip@flip-vs-expired-vblank@b-edp1.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-skl2/igt@kms_flip@flip-vs-expired-vblank@b-edp1.html
* igt@kms_hdr@bpc-switch:
- shard-skl: [FAIL][35] ([i915#1188]) -> [PASS][36]
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-skl8/igt@kms_hdr@bpc-switch.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-skl8/igt@kms_hdr@bpc-switch.html
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: [FAIL][37] ([fdo#108145] / [i915#265]) -> [PASS][38] +1 similar issue
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-skl8/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-skl8/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
* igt@kms_psr@psr2_sprite_mmap_gtt:
- shard-iclb: [SKIP][39] ([fdo#109441]) -> [PASS][40] +1 similar issue
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-iclb3/igt@kms_psr@psr2_sprite_mmap_gtt.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html
* igt@kms_setmode@basic:
- shard-kbl: [FAIL][41] ([i915#31]) -> [PASS][42]
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-kbl3/igt@kms_setmode@basic.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-kbl1/igt@kms_setmode@basic.html
* igt@perf@mi-rpc:
- shard-hsw: [INCOMPLETE][43] ([i915#61]) -> [PASS][44]
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-hsw5/igt@perf@mi-rpc.html
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-hsw4/igt@perf@mi-rpc.html
#### Warnings ####
* igt@i915_pm_dc@dc6-psr:
- shard-tglb: [FAIL][45] ([i915#454]) -> [SKIP][46] ([i915#468])
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-tglb1/igt@i915_pm_dc@dc6-psr.html
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-tglb2/igt@i915_pm_dc@dc6-psr.html
* igt@kms_content_protection@atomic:
- shard-apl: [FAIL][47] ([fdo#110321] / [fdo#110336]) -> [TIMEOUT][48] ([i915#1319] / [i915#1635])
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-apl6/igt@kms_content_protection@atomic.html
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-apl8/igt@kms_content_protection@atomic.html
* igt@kms_content_protection@legacy:
- shard-apl: [TIMEOUT][49] ([i915#1319] / [i915#1635]) -> [FAIL][50] ([fdo#110321] / [fdo#110336])
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-apl2/igt@kms_content_protection@legacy.html
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-apl7/igt@kms_content_protection@legacy.html
* igt@kms_content_protection@lic:
- shard-apl: [TIMEOUT][51] ([i915#1319]) -> [FAIL][52] ([fdo#110321] / [i915#95])
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8553/shard-apl7/igt@kms_content_protection@lic.html
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/shard-apl3/igt@kms_content_protection@lic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
[fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
[fdo#110321]: https://bugs.freedesktop.org/show_bug.cgi?id=110321
[fdo#110336]: https://bugs.freedesktop.org/show_bug.cgi?id=110336
[fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
[i915#1185]: https://gitlab.freedesktop.org/drm/intel/issues/1185
[i915#1188]: https://gitlab.freedesktop.org/drm/intel/issues/1188
[i915#1319]: https://gitlab.freedesktop.org/drm/intel/issues/1319
[i915#1542]: https://gitlab.freedesktop.org/drm/intel/issues/1542
[i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
[i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165
[i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
[i915#1925]: https://gitlab.freedesktop.org/drm/intel/issues/1925
[i915#1926]: https://gitlab.freedesktop.org/drm/intel/issues/1926
[i915#1930]: https://gitlab.freedesktop.org/drm/intel/issues/1930
[i915#1958]: https://gitlab.freedesktop.org/drm/intel/issues/1958
[i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265
[i915#31]: https://gitlab.freedesktop.org/drm/intel/issues/31
[i915#454]: https://gitlab.freedesktop.org/drm/intel/issues/454
[i915#468]: https://gitlab.freedesktop.org/drm/intel/issues/468
[i915#54]: https://gitlab.freedesktop.org/drm/intel/issues/54
[i915#58]: https://gitlab.freedesktop.org/drm/intel/issues/58
[i915#61]: https://gitlab.freedesktop.org/drm/intel/issues/61
[i915#79]: https://gitlab.freedesktop.org/drm/intel/issues/79
[i915#93]: https://gitlab.freedesktop.org/drm/intel/issues/93
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
[k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133
Participating hosts (11 -> 10)
------------------------------
Missing (1): pig-icl-1065g7
Build changes
-------------
* Linux: CI_DRM_8553 -> Patchwork_17818
CI-20190529: 20190529
CI_DRM_8553: 9f1b8b4fcb466dc714b1f825fd93e3bbd29c7de6 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5683: 757b6e72d546fd2dbc3801a73796d67b0854021b @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17818: c92c12f5de38ad38c279bbcd5f131392a3c78732 @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17818/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v8 5/5] dt-bindings: chosen: Document linux,low-memory-range for arm64 kdump
From: James Morse @ 2020-05-29 16:11 UTC (permalink / raw)
To: Rob Herring, chenzhou
Cc: Simon Horman, John.p.donnelly, Baoquan He, Will Deacon,
devicetree, Catalin Marinas, Linux Doc Mailing List, kexec,
linux-kernel@vger.kernel.org, Ingo Molnar, Arnd Bergmann,
Hanjun Guo, Thomas Gleixner, pkushwaha, dyoung,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20200526211800.GA352001@bogus>
Hi guys,
On 26/05/2020 22:18, Rob Herring wrote:
> On Fri, May 22, 2020 at 11:24:11AM +0800, chenzhou wrote:
>> On 2020/5/21 21:29, Rob Herring wrote:
>>> On Thu, May 21, 2020 at 3:35 AM Chen Zhou <chenzhou10@huawei.com> wrote:
>>>> Add documentation for DT property used by arm64 kdump:
>>>> linux,low-memory-range.
>>>> "linux,low-memory-range" is an another memory region used for crash
>>>> dump kernel devices.
>>>> diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
>>>> index 45e79172a646..bfe6fb6976e6 100644
>>>> --- a/Documentation/devicetree/bindings/chosen.txt
>>>> +++ b/Documentation/devicetree/bindings/chosen.txt
>>>> +linux,low-memory-range
>>>> +----------------------
>>>> +This property (arm64 only) holds a base address and size, describing a
>>>> +limited region below 4G. Similar to "linux,usable-memory-range", it is
>>>> +an another memory range which may be considered available for use by the
>>>> +kernel.
>>> Why can't you just add a range to "linux,usable-memory-range"? It
>>> shouldn't be hard to figure out which part is below 4G.
>> The comments from James:
>> Won't this break if your kdump kernel doesn't know what the extra parameters are?
>> Or if it expects two ranges, but only gets one? These DT properties should be treated as
>> ABI between kernel versions, we can't really change it like this.
>>
>> I think the 'low' region is an optional-extra, that is never mapped by the first kernel. I
>> think the simplest thing to do is to add an 'linux,low-memory-range' that we
>> memblock_add() after memblock_cap_memory_range() has been called.
>> If its missing, or the new kernel doesn't know what its for, everything keeps working.
>
>
> I don't think there's a compatibility issue here though. The current
> kernel doesn't care if the property is longer than 1 base+size. It only
> checks if the size is less than 1 base+size.
Aha! I missed that.
> And yes, we can rely on
> that implementation detail. It's only an ABI if an existing user
> notices.
>
> Now, if the low memory is listed first, then an older kdump kernel
> would get a different memory range. If that's a problem, then define
> that low memory goes last.
This first entry would need to be the 'crashkernel' range where the kdump kernel is
placed, otherwise an older kernel won't boot. The rest can be optional extras, as long as
we are tolerant of it being missing...
I'll try and look at the rest of this series on Monday,
Thanks,
James
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 5/5] dt-bindings: chosen: Document linux,low-memory-range for arm64 kdump
From: James Morse @ 2020-05-29 16:11 UTC (permalink / raw)
To: Rob Herring, chenzhou
Cc: Thomas Gleixner, Ingo Molnar, Catalin Marinas, Will Deacon,
dyoung, Baoquan He, Arnd Bergmann, John.p.donnelly, pkushwaha,
Simon Horman, Hanjun Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
devicetree, Linux Doc Mailing List, linux-kernel@vger.kernel.org,
kexec
In-Reply-To: <20200526211800.GA352001@bogus>
Hi guys,
On 26/05/2020 22:18, Rob Herring wrote:
> On Fri, May 22, 2020 at 11:24:11AM +0800, chenzhou wrote:
>> On 2020/5/21 21:29, Rob Herring wrote:
>>> On Thu, May 21, 2020 at 3:35 AM Chen Zhou <chenzhou10@huawei.com> wrote:
>>>> Add documentation for DT property used by arm64 kdump:
>>>> linux,low-memory-range.
>>>> "linux,low-memory-range" is an another memory region used for crash
>>>> dump kernel devices.
>>>> diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
>>>> index 45e79172a646..bfe6fb6976e6 100644
>>>> --- a/Documentation/devicetree/bindings/chosen.txt
>>>> +++ b/Documentation/devicetree/bindings/chosen.txt
>>>> +linux,low-memory-range
>>>> +----------------------
>>>> +This property (arm64 only) holds a base address and size, describing a
>>>> +limited region below 4G. Similar to "linux,usable-memory-range", it is
>>>> +an another memory range which may be considered available for use by the
>>>> +kernel.
>>> Why can't you just add a range to "linux,usable-memory-range"? It
>>> shouldn't be hard to figure out which part is below 4G.
>> The comments from James:
>> Won't this break if your kdump kernel doesn't know what the extra parameters are?
>> Or if it expects two ranges, but only gets one? These DT properties should be treated as
>> ABI between kernel versions, we can't really change it like this.
>>
>> I think the 'low' region is an optional-extra, that is never mapped by the first kernel. I
>> think the simplest thing to do is to add an 'linux,low-memory-range' that we
>> memblock_add() after memblock_cap_memory_range() has been called.
>> If its missing, or the new kernel doesn't know what its for, everything keeps working.
>
>
> I don't think there's a compatibility issue here though. The current
> kernel doesn't care if the property is longer than 1 base+size. It only
> checks if the size is less than 1 base+size.
Aha! I missed that.
> And yes, we can rely on
> that implementation detail. It's only an ABI if an existing user
> notices.
>
> Now, if the low memory is listed first, then an older kdump kernel
> would get a different memory range. If that's a problem, then define
> that low memory goes last.
This first entry would need to be the 'crashkernel' range where the kdump kernel is
placed, otherwise an older kernel won't boot. The rest can be optional extras, as long as
we are tolerant of it being missing...
I'll try and look at the rest of this series on Monday,
Thanks,
James
^ permalink raw reply
* Re: [PATCH v8 5/5] dt-bindings: chosen: Document linux,low-memory-range for arm64 kdump
From: James Morse @ 2020-05-29 16:11 UTC (permalink / raw)
To: Rob Herring, chenzhou
Cc: Simon Horman, John.p.donnelly, Baoquan He, Will Deacon,
devicetree, Catalin Marinas, Linux Doc Mailing List, kexec,
linux-kernel@vger.kernel.org, Ingo Molnar, Arnd Bergmann,
Hanjun Guo, Thomas Gleixner, pkushwaha, dyoung,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20200526211800.GA352001@bogus>
Hi guys,
On 26/05/2020 22:18, Rob Herring wrote:
> On Fri, May 22, 2020 at 11:24:11AM +0800, chenzhou wrote:
>> On 2020/5/21 21:29, Rob Herring wrote:
>>> On Thu, May 21, 2020 at 3:35 AM Chen Zhou <chenzhou10@huawei.com> wrote:
>>>> Add documentation for DT property used by arm64 kdump:
>>>> linux,low-memory-range.
>>>> "linux,low-memory-range" is an another memory region used for crash
>>>> dump kernel devices.
>>>> diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
>>>> index 45e79172a646..bfe6fb6976e6 100644
>>>> --- a/Documentation/devicetree/bindings/chosen.txt
>>>> +++ b/Documentation/devicetree/bindings/chosen.txt
>>>> +linux,low-memory-range
>>>> +----------------------
>>>> +This property (arm64 only) holds a base address and size, describing a
>>>> +limited region below 4G. Similar to "linux,usable-memory-range", it is
>>>> +an another memory range which may be considered available for use by the
>>>> +kernel.
>>> Why can't you just add a range to "linux,usable-memory-range"? It
>>> shouldn't be hard to figure out which part is below 4G.
>> The comments from James:
>> Won't this break if your kdump kernel doesn't know what the extra parameters are?
>> Or if it expects two ranges, but only gets one? These DT properties should be treated as
>> ABI between kernel versions, we can't really change it like this.
>>
>> I think the 'low' region is an optional-extra, that is never mapped by the first kernel. I
>> think the simplest thing to do is to add an 'linux,low-memory-range' that we
>> memblock_add() after memblock_cap_memory_range() has been called.
>> If its missing, or the new kernel doesn't know what its for, everything keeps working.
>
>
> I don't think there's a compatibility issue here though. The current
> kernel doesn't care if the property is longer than 1 base+size. It only
> checks if the size is less than 1 base+size.
Aha! I missed that.
> And yes, we can rely on
> that implementation detail. It's only an ABI if an existing user
> notices.
>
> Now, if the low memory is listed first, then an older kdump kernel
> would get a different memory range. If that's a problem, then define
> that low memory goes last.
This first entry would need to be the 'crashkernel' range where the kdump kernel is
placed, otherwise an older kernel won't boot. The rest can be optional extras, as long as
we are tolerant of it being missing...
I'll try and look at the rest of this series on Monday,
Thanks,
James
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* Re: [PATCH v4 04/11] thermal: Store device mode in struct thermal_zone_device
From: Andrzej Pietrasiewicz @ 2020-05-29 16:08 UTC (permalink / raw)
To: Guenter Roeck
Cc: Emmanuel Grumbach, Heiko Stuebner, Kalle Valo, linux-wireless,
Peter Kaestle, platform-driver-x86, Vishal Kulkarni, Luca Coelho,
Miquel Raynal, Shawn Guo, kernel, Fabio Estevam, Amit Kucheria,
linux-rockchip, Chunyan Zhang, Daniel Lezcano, linux-acpi,
linux-arm-kernel, Darren Hart, Zhang Rui, Gayatri Kammela,
NXP Linux Team, Johannes Berg, linux-pm, Sascha Hauer,
Intel Linux Wireless, Ido Schimmel, Niklas Söderlund,
Jiri Pirko, Orson Zhai, Thomas Gleixner, Allison Randal,
Support Opensource, netdev, Rafael J . Wysocki, Sebastian Reichel,
linux-renesas-soc, Bartlomiej Zolnierkiewicz,
Pengutronix Kernel Team, Baolin Wang, Len Brown, Enrico Weigelt,
David S . Miller, Andy Shevchenko
In-Reply-To: <20200529154205.GA157653@roeck-us.net>
Hi Guenter,
W dniu 29.05.2020 o 17:42, Guenter Roeck pisze:
> On Thu, May 28, 2020 at 09:20:44PM +0200, Andrzej Pietrasiewicz wrote:
>> Prepare for eliminating get_mode().
>>
> Might be worthwhile to explain (not only in the subject) what you are
> doing here.
>
>> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
>> ---
>> drivers/acpi/thermal.c | 18 ++++++----------
>> .../ethernet/mellanox/mlxsw/core_thermal.c | 21 +++++++------------
>> drivers/platform/x86/acerhdf.c | 15 ++++++-------
>> drivers/thermal/da9062-thermal.c | 6 ++----
>> drivers/thermal/imx_thermal.c | 17 +++++++--------
>> .../intel/int340x_thermal/int3400_thermal.c | 12 +++--------
>> .../thermal/intel/intel_quark_dts_thermal.c | 16 +++++++-------
>> drivers/thermal/thermal_of.c | 10 +++------
>
> After this patch is applied on top of the thermal 'testing' branch,
> there are still local instances of thermal_device_mode in
> drivers/thermal/st/stm_thermal.c
> drivers/thermal/ti-soc-thermal/ti-thermal-common.c
>
> If there is a reason not to replace those, it might make sense to explain
> it here.
>
My understanding is that these two are sensor devices which are "plugged"
into their "parent" thermal zone device. The latter is the "proper" tzd.
They both use thermal_zone_of_device_ops instead of thermal_zone_device_ops.
The former doesn't even have get_mode(). The thermal core, when it calls
get_mode(), operates on the "parent" thermal zone devices.
Consequently, the drivers you mention use their "mode" members for
their private purpose, not for the purpose of storing the "parent"
thermal zone device mode.
Andrzej
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 10/24] KVM: arm/arm64: Release kvm->mmu_lock in loop to prevent starvation
From: Marc Zyngier @ 2020-05-29 16:01 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Mark Rutland, kvmarm, kvm, Will Deacon, Suzuki K Poulose,
Keqian Zhu, Christoffer Dall, Jiang Yi, James Morse, Andrew Scull,
Zenghui Yu, Julien Thierry, David Brazdil, Alexandru Elisei,
Ard Biesheuvel, Fuad Tabba, linux-arm-kernel
In-Reply-To: <20200529160121.899083-1-maz@kernel.org>
From: Jiang Yi <giangyi@amazon.com>
Do cond_resched_lock() in stage2_flush_memslot() like what is done in
unmap_stage2_range() and other places holding mmu_lock while processing
a possibly large range of memory.
Signed-off-by: Jiang Yi <giangyi@amazon.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20200415084229.29992-1-giangyi@amazon.com
---
arch/arm64/kvm/mmu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 29d8f24df944..917363375e8a 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -422,6 +422,9 @@ static void stage2_flush_memslot(struct kvm *kvm,
next = stage2_pgd_addr_end(kvm, addr, end);
if (!stage2_pgd_none(kvm, *pgd))
stage2_flush_puds(kvm, pgd, addr, next);
+
+ if (next != end)
+ cond_resched_lock(&kvm->mmu_lock);
} while (pgd++, addr = next, addr != end);
}
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 13/24] KVM: arm64: Support enabling dirty log gradually in small chunks
From: Marc Zyngier @ 2020-05-29 16:01 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Mark Rutland, kvmarm, kvm, Will Deacon, Suzuki K Poulose,
Keqian Zhu, Christoffer Dall, Jiang Yi, James Morse, Andrew Scull,
Zenghui Yu, Julien Thierry, David Brazdil, Alexandru Elisei,
Ard Biesheuvel, Fuad Tabba, linux-arm-kernel
In-Reply-To: <20200529160121.899083-1-maz@kernel.org>
From: Keqian Zhu <zhukeqian1@huawei.com>
There is already support of enabling dirty log gradually in small chunks
for x86 in commit 3c9bd4006bfc ("KVM: x86: enable dirty log gradually in
small chunks"). This adds support for arm64.
x86 still writes protect all huge pages when DIRTY_LOG_INITIALLY_ALL_SET
is enabled. However, for arm64, both huge pages and normal pages can be
write protected gradually by userspace.
Under the Huawei Kunpeng 920 2.6GHz platform, I did some tests on 128G
Linux VMs with different page size. The memory pressure is 127G in each
case. The time taken of memory_global_dirty_log_start in QEMU is listed
below:
Page Size Before After Optimization
4K 650ms 1.8ms
2M 4ms 1.8ms
1G 2ms 1.8ms
Besides the time reduction, the biggest improvement is that we will minimize
the performance side effect (because of dissolving huge pages and marking
memslots dirty) on guest after enabling dirty log.
Signed-off-by: Keqian Zhu <zhukeqian1@huawei.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20200413122023.52583-1-zhukeqian1@huawei.com
---
Documentation/virt/kvm/api.rst | 2 +-
arch/arm64/include/asm/kvm_host.h | 3 +++
arch/arm64/kvm/mmu.c | 12 ++++++++++--
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index efbbe570aa9b..0017f63fa44f 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -5777,7 +5777,7 @@ will be initialized to 1 when created. This also improves performance because
dirty logging can be enabled gradually in small chunks on the first call
to KVM_CLEAR_DIRTY_LOG. KVM_DIRTY_LOG_INITIALLY_SET depends on
KVM_DIRTY_LOG_MANUAL_PROTECT_ENABLE (it is also only available on
-x86 for now).
+x86 and arm64 for now).
KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 was previously available under the name
KVM_CAP_MANUAL_DIRTY_LOG_PROTECT, but the implementation had bugs that make
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 32c8a675e5a4..a723f84fab83 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -46,6 +46,9 @@
#define KVM_REQ_RECORD_STEAL KVM_ARCH_REQ(3)
#define KVM_REQ_RELOAD_GICv4 KVM_ARCH_REQ(4)
+#define KVM_DIRTY_LOG_MANUAL_CAPS (KVM_DIRTY_LOG_MANUAL_PROTECT_ENABLE | \
+ KVM_DIRTY_LOG_INITIALLY_SET)
+
DECLARE_STATIC_KEY_FALSE(userspace_irqchip_in_use);
extern unsigned int kvm_sve_max_vl;
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 66eb8e3f6e8c..ddf85bf21897 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -2277,8 +2277,16 @@ void kvm_arch_commit_memory_region(struct kvm *kvm,
* allocated dirty_bitmap[], dirty pages will be tracked while the
* memory slot is write protected.
*/
- if (change != KVM_MR_DELETE && mem->flags & KVM_MEM_LOG_DIRTY_PAGES)
- kvm_mmu_wp_memory_region(kvm, mem->slot);
+ if (change != KVM_MR_DELETE && mem->flags & KVM_MEM_LOG_DIRTY_PAGES) {
+ /*
+ * If we're with initial-all-set, we don't need to write
+ * protect any pages because they're all reported as dirty.
+ * Huge pages and normal pages will be write protect gradually.
+ */
+ if (!kvm_dirty_log_manual_protect_and_init_set(kvm)) {
+ kvm_mmu_wp_memory_region(kvm, mem->slot);
+ }
+ }
}
int kvm_arch_prepare_memory_region(struct kvm *kvm,
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 4/4] net: remove kernel_setsockopt
From: Marcelo Ricardo Leitner @ 2020-05-29 16:10 UTC (permalink / raw)
To: Christoph Hellwig
Cc: David S. Miller, Jakub Kicinski, Vlad Yasevich, Neil Horman,
David Laight, linux-sctp, linux-kernel, cluster-devel, netdev
In-Reply-To: <20200529120943.101454-5-hch@lst.de>
On Fri, May 29, 2020 at 02:09:43PM +0200, Christoph Hellwig wrote:
> No users left.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Thanks.
> ---
> include/linux/net.h | 2 --
> net/socket.c | 31 -------------------------------
> 2 files changed, 33 deletions(-)
>
> diff --git a/include/linux/net.h b/include/linux/net.h
> index 74ef5d7315f70..e10f378194a59 100644
> --- a/include/linux/net.h
> +++ b/include/linux/net.h
> @@ -303,8 +303,6 @@ int kernel_connect(struct socket *sock, struct sockaddr *addr, int addrlen,
> int flags);
> int kernel_getsockname(struct socket *sock, struct sockaddr *addr);
> int kernel_getpeername(struct socket *sock, struct sockaddr *addr);
> -int kernel_setsockopt(struct socket *sock, int level, int optname, char *optval,
> - unsigned int optlen);
> int kernel_sendpage(struct socket *sock, struct page *page, int offset,
> size_t size, int flags);
> int kernel_sendpage_locked(struct sock *sk, struct page *page, int offset,
> diff --git a/net/socket.c b/net/socket.c
> index 81a98b6cbd087..976426d03f099 100644
> --- a/net/socket.c
> +++ b/net/socket.c
> @@ -3624,37 +3624,6 @@ int kernel_getpeername(struct socket *sock, struct sockaddr *addr)
> }
> EXPORT_SYMBOL(kernel_getpeername);
>
> -/**
> - * kernel_setsockopt - set a socket option (kernel space)
> - * @sock: socket
> - * @level: API level (SOL_SOCKET, ...)
> - * @optname: option tag
> - * @optval: option value
> - * @optlen: option length
> - *
> - * Returns 0 or an error.
> - */
> -
> -int kernel_setsockopt(struct socket *sock, int level, int optname,
> - char *optval, unsigned int optlen)
> -{
> - mm_segment_t oldfs = get_fs();
> - char __user *uoptval;
> - int err;
> -
> - uoptval = (char __user __force *) optval;
> -
> - set_fs(KERNEL_DS);
> - if (level == SOL_SOCKET)
> - err = sock_setsockopt(sock, level, optname, uoptval, optlen);
> - else
> - err = sock->ops->setsockopt(sock, level, optname, uoptval,
> - optlen);
> - set_fs(oldfs);
> - return err;
> -}
> -EXPORT_SYMBOL(kernel_setsockopt);
> -
> /**
> * kernel_sendpage - send a &page through a socket (kernel space)
> * @sock: socket
> --
> 2.26.2
>
^ permalink raw reply
* Re: [PATCH 4/4] net: remove kernel_setsockopt
From: Marcelo Ricardo Leitner @ 2020-05-29 16:10 UTC (permalink / raw)
To: Christoph Hellwig
Cc: David S. Miller, Jakub Kicinski, Vlad Yasevich, Neil Horman,
David Laight, linux-sctp, linux-kernel, cluster-devel, netdev
In-Reply-To: <20200529120943.101454-5-hch@lst.de>
On Fri, May 29, 2020 at 02:09:43PM +0200, Christoph Hellwig wrote:
> No users left.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Thanks.
> ---
> include/linux/net.h | 2 --
> net/socket.c | 31 -------------------------------
> 2 files changed, 33 deletions(-)
>
> diff --git a/include/linux/net.h b/include/linux/net.h
> index 74ef5d7315f70..e10f378194a59 100644
> --- a/include/linux/net.h
> +++ b/include/linux/net.h
> @@ -303,8 +303,6 @@ int kernel_connect(struct socket *sock, struct sockaddr *addr, int addrlen,
> int flags);
> int kernel_getsockname(struct socket *sock, struct sockaddr *addr);
> int kernel_getpeername(struct socket *sock, struct sockaddr *addr);
> -int kernel_setsockopt(struct socket *sock, int level, int optname, char *optval,
> - unsigned int optlen);
> int kernel_sendpage(struct socket *sock, struct page *page, int offset,
> size_t size, int flags);
> int kernel_sendpage_locked(struct sock *sk, struct page *page, int offset,
> diff --git a/net/socket.c b/net/socket.c
> index 81a98b6cbd087..976426d03f099 100644
> --- a/net/socket.c
> +++ b/net/socket.c
> @@ -3624,37 +3624,6 @@ int kernel_getpeername(struct socket *sock, struct sockaddr *addr)
> }
> EXPORT_SYMBOL(kernel_getpeername);
>
> -/**
> - * kernel_setsockopt - set a socket option (kernel space)
> - * @sock: socket
> - * @level: API level (SOL_SOCKET, ...)
> - * @optname: option tag
> - * @optval: option value
> - * @optlen: option length
> - *
> - * Returns 0 or an error.
> - */
> -
> -int kernel_setsockopt(struct socket *sock, int level, int optname,
> - char *optval, unsigned int optlen)
> -{
> - mm_segment_t oldfs = get_fs();
> - char __user *uoptval;
> - int err;
> -
> - uoptval = (char __user __force *) optval;
> -
> - set_fs(KERNEL_DS);
> - if (level = SOL_SOCKET)
> - err = sock_setsockopt(sock, level, optname, uoptval, optlen);
> - else
> - err = sock->ops->setsockopt(sock, level, optname, uoptval,
> - optlen);
> - set_fs(oldfs);
> - return err;
> -}
> -EXPORT_SYMBOL(kernel_setsockopt);
> -
> /**
> * kernel_sendpage - send a &page through a socket (kernel space)
> * @sock: socket
> --
> 2.26.2
>
^ permalink raw reply
* [Cluster-devel] [PATCH 4/4] net: remove kernel_setsockopt
From: Marcelo Ricardo Leitner @ 2020-05-29 16:10 UTC (permalink / raw)
To: cluster-devel.redhat.com
In-Reply-To: <20200529120943.101454-5-hch@lst.de>
On Fri, May 29, 2020 at 02:09:43PM +0200, Christoph Hellwig wrote:
> No users left.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Thanks.
> ---
> include/linux/net.h | 2 --
> net/socket.c | 31 -------------------------------
> 2 files changed, 33 deletions(-)
>
> diff --git a/include/linux/net.h b/include/linux/net.h
> index 74ef5d7315f70..e10f378194a59 100644
> --- a/include/linux/net.h
> +++ b/include/linux/net.h
> @@ -303,8 +303,6 @@ int kernel_connect(struct socket *sock, struct sockaddr *addr, int addrlen,
> int flags);
> int kernel_getsockname(struct socket *sock, struct sockaddr *addr);
> int kernel_getpeername(struct socket *sock, struct sockaddr *addr);
> -int kernel_setsockopt(struct socket *sock, int level, int optname, char *optval,
> - unsigned int optlen);
> int kernel_sendpage(struct socket *sock, struct page *page, int offset,
> size_t size, int flags);
> int kernel_sendpage_locked(struct sock *sk, struct page *page, int offset,
> diff --git a/net/socket.c b/net/socket.c
> index 81a98b6cbd087..976426d03f099 100644
> --- a/net/socket.c
> +++ b/net/socket.c
> @@ -3624,37 +3624,6 @@ int kernel_getpeername(struct socket *sock, struct sockaddr *addr)
> }
> EXPORT_SYMBOL(kernel_getpeername);
>
> -/**
> - * kernel_setsockopt - set a socket option (kernel space)
> - * @sock: socket
> - * @level: API level (SOL_SOCKET, ...)
> - * @optname: option tag
> - * @optval: option value
> - * @optlen: option length
> - *
> - * Returns 0 or an error.
> - */
> -
> -int kernel_setsockopt(struct socket *sock, int level, int optname,
> - char *optval, unsigned int optlen)
> -{
> - mm_segment_t oldfs = get_fs();
> - char __user *uoptval;
> - int err;
> -
> - uoptval = (char __user __force *) optval;
> -
> - set_fs(KERNEL_DS);
> - if (level == SOL_SOCKET)
> - err = sock_setsockopt(sock, level, optname, uoptval, optlen);
> - else
> - err = sock->ops->setsockopt(sock, level, optname, uoptval,
> - optlen);
> - set_fs(oldfs);
> - return err;
> -}
> -EXPORT_SYMBOL(kernel_setsockopt);
> -
> /**
> * kernel_sendpage - send a &page through a socket (kernel space)
> * @sock: socket
> --
> 2.26.2
>
^ permalink raw reply
* RE: [BlueZ,v3,4/4] fixing const decoration warnins on options.
From: bluez.test.bot @ 2020-05-29 16:10 UTC (permalink / raw)
To: linux-bluetooth, alainm
In-Reply-To: <20200529153814.213125-5-alainm@chromium.org>
[-- Attachment #1: Type: text/plain, Size: 408 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
While we are preparing for reviewing the patches, we found the following
issue/warning.
Test Result:
checkgitlint Failed
Outputs:
1: T3 Title has trailing punctuation (.): "fixing const decoration warnins on options."
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [BlueZ,v3,3/4] main:read default system configuration from the conf file.
From: bluez.test.bot @ 2020-05-29 16:10 UTC (permalink / raw)
To: linux-bluetooth, alainm
In-Reply-To: <20200529153814.213125-4-alainm@chromium.org>
[-- Attachment #1: Type: text/plain, Size: 423 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
While we are preparing for reviewing the patches, we found the following
issue/warning.
Test Result:
checkgitlint Failed
Outputs:
1: T3 Title has trailing punctuation (.): "main:read default system configuration from the conf file."
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [BlueZ,v3,2/4] adapter:set default system configuration if available
From: bluez.test.bot @ 2020-05-29 16:10 UTC (permalink / raw)
To: linux-bluetooth, alainm
In-Reply-To: <20200529153814.213125-3-alainm@chromium.org>
[-- Attachment #1: Type: text/plain, Size: 956 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
While we are preparing for reviewing the patches, we found the following
issue/warning.
Test Result:
checkpatch Failed
Outputs:
ERROR:INITIALISED_STATIC: do not initialise statics to false
#17: FILE: src/adapter.c:123:
+static bool kernel_set_system_params = false;
- total: 1 errors, 0 warnings, 320 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
Your patch has style problems, please review.
NOTE: Ignored message types: COMMIT_MESSAGE COMPLEX_MACRO CONST_STRUCT FILE_PATH_CHANGES MISSING_SIGN_OFF PREFER_PACKED SPLIT_STRING
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [PATCH 12/24] KVM: arm64: Unify handling THP backed host memory
From: Marc Zyngier @ 2020-05-29 16:01 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Mark Rutland, kvmarm, kvm, Will Deacon, Suzuki K Poulose,
Keqian Zhu, Christoffer Dall, Jiang Yi, James Morse, Andrew Scull,
Zenghui Yu, Julien Thierry, David Brazdil, Alexandru Elisei,
Ard Biesheuvel, Fuad Tabba, linux-arm-kernel
In-Reply-To: <20200529160121.899083-1-maz@kernel.org>
From: Suzuki K Poulose <suzuki.poulose@arm.com>
We support mapping host memory backed by PMD transparent hugepages
at stage2 as huge pages. However the checks are now spread across
two different places. Let us unify the handling of the THPs to
keep the code cleaner (and future proof for PUD THP support).
This patch moves transparent_hugepage_adjust() closer to the caller
to avoid a forward declaration for fault_supports_stage2_huge_mappings().
Also, since we already handle the case where the host VA and the guest
PA may not be aligned, the explicit VM_BUG_ON() is not required.
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20200507123546.1875-3-yuzenghui@huawei.com
---
arch/arm64/kvm/mmu.c | 115 ++++++++++++++++++++++---------------------
1 file changed, 60 insertions(+), 55 deletions(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index ccb44e7d30d9..66eb8e3f6e8c 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1375,47 +1375,6 @@ int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
return ret;
}
-static bool transparent_hugepage_adjust(kvm_pfn_t *pfnp, phys_addr_t *ipap)
-{
- kvm_pfn_t pfn = *pfnp;
- gfn_t gfn = *ipap >> PAGE_SHIFT;
-
- if (kvm_is_transparent_hugepage(pfn)) {
- unsigned long mask;
- /*
- * The address we faulted on is backed by a transparent huge
- * page. However, because we map the compound huge page and
- * not the individual tail page, we need to transfer the
- * refcount to the head page. We have to be careful that the
- * THP doesn't start to split while we are adjusting the
- * refcounts.
- *
- * We are sure this doesn't happen, because mmu_notifier_retry
- * was successful and we are holding the mmu_lock, so if this
- * THP is trying to split, it will be blocked in the mmu
- * notifier before touching any of the pages, specifically
- * before being able to call __split_huge_page_refcount().
- *
- * We can therefore safely transfer the refcount from PG_tail
- * to PG_head and switch the pfn from a tail page to the head
- * page accordingly.
- */
- mask = PTRS_PER_PMD - 1;
- VM_BUG_ON((gfn & mask) != (pfn & mask));
- if (pfn & mask) {
- *ipap &= PMD_MASK;
- kvm_release_pfn_clean(pfn);
- pfn &= ~mask;
- kvm_get_pfn(pfn);
- *pfnp = pfn;
- }
-
- return true;
- }
-
- return false;
-}
-
/**
* stage2_wp_ptes - write protect PMD range
* @pmd: pointer to pmd entry
@@ -1663,6 +1622,59 @@ static bool fault_supports_stage2_huge_mapping(struct kvm_memory_slot *memslot,
(hva & ~(map_size - 1)) + map_size <= uaddr_end;
}
+/*
+ * Check if the given hva is backed by a transparent huge page (THP) and
+ * whether it can be mapped using block mapping in stage2. If so, adjust
+ * the stage2 PFN and IPA accordingly. Only PMD_SIZE THPs are currently
+ * supported. This will need to be updated to support other THP sizes.
+ *
+ * Returns the size of the mapping.
+ */
+static unsigned long
+transparent_hugepage_adjust(struct kvm_memory_slot *memslot,
+ unsigned long hva, kvm_pfn_t *pfnp,
+ phys_addr_t *ipap)
+{
+ kvm_pfn_t pfn = *pfnp;
+
+ /*
+ * Make sure the adjustment is done only for THP pages. Also make
+ * sure that the HVA and IPA are sufficiently aligned and that the
+ * block map is contained within the memslot.
+ */
+ if (kvm_is_transparent_hugepage(pfn) &&
+ fault_supports_stage2_huge_mapping(memslot, hva, PMD_SIZE)) {
+ /*
+ * The address we faulted on is backed by a transparent huge
+ * page. However, because we map the compound huge page and
+ * not the individual tail page, we need to transfer the
+ * refcount to the head page. We have to be careful that the
+ * THP doesn't start to split while we are adjusting the
+ * refcounts.
+ *
+ * We are sure this doesn't happen, because mmu_notifier_retry
+ * was successful and we are holding the mmu_lock, so if this
+ * THP is trying to split, it will be blocked in the mmu
+ * notifier before touching any of the pages, specifically
+ * before being able to call __split_huge_page_refcount().
+ *
+ * We can therefore safely transfer the refcount from PG_tail
+ * to PG_head and switch the pfn from a tail page to the head
+ * page accordingly.
+ */
+ *ipap &= PMD_MASK;
+ kvm_release_pfn_clean(pfn);
+ pfn &= ~(PTRS_PER_PMD - 1);
+ kvm_get_pfn(pfn);
+ *pfnp = pfn;
+
+ return PMD_SIZE;
+ }
+
+ /* Use page mapping if we cannot use block mapping. */
+ return PAGE_SIZE;
+}
+
static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
struct kvm_memory_slot *memslot, unsigned long hva,
unsigned long fault_status)
@@ -1776,20 +1788,13 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
if (mmu_notifier_retry(kvm, mmu_seq))
goto out_unlock;
- if (vma_pagesize == PAGE_SIZE && !force_pte) {
- /*
- * Only PMD_SIZE transparent hugepages(THP) are
- * currently supported. This code will need to be
- * updated to support other THP sizes.
- *
- * Make sure the host VA and the guest IPA are sufficiently
- * aligned and that the block is contained within the memslot.
- */
- if (fault_supports_stage2_huge_mapping(memslot, hva, PMD_SIZE) &&
- transparent_hugepage_adjust(&pfn, &fault_ipa))
- vma_pagesize = PMD_SIZE;
- }
-
+ /*
+ * If we are not forced to use page mapping, check if we are
+ * backed by a THP and thus use block mapping if possible.
+ */
+ if (vma_pagesize == PAGE_SIZE && !force_pte)
+ vma_pagesize = transparent_hugepage_adjust(memslot, hva,
+ &pfn, &fault_ipa);
if (writable)
kvm_set_pfn_dirty(pfn);
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 22/24] KVM: arm64: Don't use empty structures as CPU reset state
From: Marc Zyngier @ 2020-05-29 16:01 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Mark Rutland, kvmarm, kvm, Will Deacon, Suzuki K Poulose,
Keqian Zhu, Christoffer Dall, Jiang Yi, James Morse, Andrew Scull,
Zenghui Yu, Julien Thierry, David Brazdil, Alexandru Elisei,
Ard Biesheuvel, Fuad Tabba, linux-arm-kernel
In-Reply-To: <20200529160121.899083-1-maz@kernel.org>
Keeping empty structure as the vcpu state initializer is slightly
wasteful: we only want to set pstate, and zero everything else.
Just do that.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/reset.c | 21 +++++++++------------
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 658f3a79617b..865c8aa670bc 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -36,15 +36,11 @@ static u32 kvm_ipa_limit;
/*
* ARMv8 Reset Values
*/
-static const struct kvm_regs default_regs_reset = {
- .regs.pstate = (PSR_MODE_EL1h | PSR_A_BIT | PSR_I_BIT |
- PSR_F_BIT | PSR_D_BIT),
-};
+#define VCPU_RESET_PSTATE_EL1 (PSR_MODE_EL1h | PSR_A_BIT | PSR_I_BIT | \
+ PSR_F_BIT | PSR_D_BIT)
-static const struct kvm_regs default_regs_reset32 = {
- .regs.pstate = (PSR_AA32_MODE_SVC | PSR_AA32_A_BIT |
- PSR_AA32_I_BIT | PSR_AA32_F_BIT),
-};
+#define VCPU_RESET_PSTATE_SVC (PSR_AA32_MODE_SVC | PSR_AA32_A_BIT | \
+ PSR_AA32_I_BIT | PSR_AA32_F_BIT)
static bool cpu_has_32bit_el1(void)
{
@@ -257,9 +253,9 @@ static int kvm_vcpu_enable_ptrauth(struct kvm_vcpu *vcpu)
*/
int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
{
- const struct kvm_regs *cpu_reset;
int ret = -EINVAL;
bool loaded;
+ u32 pstate;
/* Reset PMU outside of the non-preemptible section */
kvm_pmu_vcpu_reset(vcpu);
@@ -290,16 +286,17 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
if (test_bit(KVM_ARM_VCPU_EL1_32BIT, vcpu->arch.features)) {
if (!cpu_has_32bit_el1())
goto out;
- cpu_reset = &default_regs_reset32;
+ pstate = VCPU_RESET_PSTATE_SVC;
} else {
- cpu_reset = &default_regs_reset;
+ pstate = VCPU_RESET_PSTATE_EL1;
}
break;
}
/* Reset core registers */
- memcpy(vcpu_gp_regs(vcpu), cpu_reset, sizeof(*cpu_reset));
+ memset(vcpu_gp_regs(vcpu), 0, sizeof(*vcpu_gp_regs(vcpu)));
+ vcpu_gp_regs(vcpu)->regs.pstate = pstate;
/* Reset system registers */
kvm_reset_sys_regs(vcpu);
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: PANIC: double fault in fixup_bad_iret
From: Peter Zijlstra @ 2020-05-29 16:07 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Dmitry Vyukov, syzbot, LKML, syzkaller-bugs, Ingo Molnar,
Borislav Petkov, the arch/x86 maintainers, Oleg Nesterov
In-Reply-To: <87o8q6n38p.fsf@nanos.tec.linutronix.de>
On Fri, May 29, 2020 at 05:57:10PM +0200, Thomas Gleixner wrote:
> Dmitry,
>
> Dmitry Vyukov <dvyukov@google.com> writes:
> > On Fri, May 29, 2020 at 3:14 PM syzbot
> > <syzbot+dc1fa714cb070b184db5@syzkaller.appspotmail.com> wrote:
> >>
> >> Hello,
> >>
> >> syzbot found the following crash on:
> >>
> >> HEAD commit: 7b4cb0a4 Add linux-next specific files for 20200525
> >> git tree: linux-next
> >> console output: https://syzkaller.appspot.com/x/log.txt?x=15dc34ba100000
> >> kernel config: https://syzkaller.appspot.com/x/.config?x=47b0740d89299c10
> >> dashboard link: https://syzkaller.appspot.com/bug?extid=dc1fa714cb070b184db5
> >> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> >> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14678626100000
> >> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1017ef06100000
> >>
> >> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> >> Reported-by: syzbot+dc1fa714cb070b184db5@syzkaller.appspotmail.com
> >
> > From the reproducer it seems to be either x86 related or ptrace
> > related.
> >
> >> RIP: 0010:fixup_bad_iret+0x24/0x170 arch/x86/kernel/traps.c:665
>
> as a quick assumption that's related to KASAN in fixup_bad_iret() which
> is a frightenly bad idea. I'm about to verify.
Like with KCSAN, we should blanket kill KASAN/UBSAN and friends (at the
very least in arch/x86/) until they get that function attribute stuff
sorted.
^ permalink raw reply
* Re: new seccomp mode aims to improve performance
From: Kees Cook @ 2020-05-29 16:09 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: zhujianwei (C), bpf@vger.kernel.org,
linux-security-module@vger.kernel.org, Hehuazhen
In-Reply-To: <CAADnVQLnFuOR+Xk1QXpLFGHx-8StPCye7j5UgKbBoLrmKtygQA@mail.gmail.com>
On Fri, May 29, 2020 at 08:43:56AM -0700, Alexei Starovoitov wrote:
> On Fri, May 29, 2020 at 5:50 AM zhujianwei (C) <zhujianwei7@huawei.com> wrote:
> >
> > Hi, all
> >
> > We're using seccomp to increase container security, but bpf rules filter causes performance to deteriorate. So, is there a good solution to improve performance, or can we add a simplified seccomp mode to improve performance?
Yes, there are already plans for a simple syscall bitmap[1] seccomp feature.
> I don't think your hunch at where cpu is spending cycles is correct.
> Could you please do two experiments:
> 1. try trivial seccomp bpf prog that simply returns 'allow'
> 2. replace bpf_prog_run_pin_on_cpu() in seccomp.c with C code
> that returns 'allow' and make sure it's noinline or in a different C file,
> so that compiler doesn't optimize the whole seccomp_run_filters() into a nop.
>
> Then measure performance of both.
> I bet you'll see exactly the same numbers.
Android has already done this, it appeared to not be the same. Calling
into a SECCOMP_RET_ALLOW filter had a surprisingly high cost. I'll see
if I can get you the numbers. I was frankly quite surprised -- I
understood the bulk of the seccomp overhead to be in taking the TIF_WORK
path, copying arguments, etc, but something else is going on there.
-Kees
[1] https://lore.kernel.org/lkml/202005181120.971232B7B@keescook/
--
Kees Cook
^ permalink raw reply
* [PATCH 16/24] KVM: arm64: Fix incorrect comment on kvm_get_hyp_vector()
From: Marc Zyngier @ 2020-05-29 16:01 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Mark Rutland, kvmarm, kvm, Will Deacon, Suzuki K Poulose,
Keqian Zhu, Christoffer Dall, Jiang Yi, James Morse, Andrew Scull,
Zenghui Yu, Julien Thierry, David Brazdil, Alexandru Elisei,
Ard Biesheuvel, Fuad Tabba, linux-arm-kernel
In-Reply-To: <20200529160121.899083-1-maz@kernel.org>
From: David Brazdil <dbrazdil@google.com>
The comment used to say that kvm_get_hyp_vector is only called on VHE systems.
In fact, it is also called from the nVHE init function cpu_init_hyp_mode().
Fix the comment to stop confusing devs.
Signed-off-by: David Brazdil <dbrazdil@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20200515152550.83810-1-dbrazdil@google.com
---
arch/arm64/include/asm/kvm_mmu.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index 30b0e8d6b895..796f6a2e794a 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -473,7 +473,7 @@ static inline int kvm_write_guest_lock(struct kvm *kvm, gpa_t gpa,
extern void *__kvm_bp_vect_base;
extern int __kvm_harden_el2_vector_slot;
-/* This is only called on a VHE system */
+/* This is called on both VHE and !VHE systems */
static inline void *kvm_get_hyp_vector(void)
{
struct bp_hardening_data *data = arm64_get_bp_hardening_data();
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] cpuidle: Fix several reference count leaks.
From: Rafael J. Wysocki @ 2020-05-29 16:08 UTC (permalink / raw)
To: wu000273
Cc: Kangjie Lu, Rafael J. Wysocki, Daniel Lezcano, Linux PM,
Linux Kernel Mailing List
In-Reply-To: <20200528182046.845-1-wu000273@umn.edu>
On Thu, May 28, 2020 at 8:21 PM <wu000273@umn.edu> wrote:
>
> From: Qiushi Wu <wu000273@umn.edu>
>
> kobject_init_and_add() takes reference even when it fails.
> If this function returns an error, kobject_put() must be called to
> properly clean up the memory associated with the object. Previous
> commit "b8eb718348b8" fixed a similar problem.
>
> Signed-off-by: Qiushi Wu <wu000273@umn.edu>
> ---
> drivers/cpuidle/sysfs.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/cpuidle/sysfs.c b/drivers/cpuidle/sysfs.c
> index cdeedbf02646..55107565b319 100644
> --- a/drivers/cpuidle/sysfs.c
> +++ b/drivers/cpuidle/sysfs.c
> @@ -515,7 +515,7 @@ static int cpuidle_add_state_sysfs(struct cpuidle_device *device)
> ret = kobject_init_and_add(&kobj->kobj, &ktype_state_cpuidle,
> &kdev->kobj, "state%d", i);
> if (ret) {
> - kfree(kobj);
> + kobject_put(&kobj->kobj);
> goto error_state;
> }
> cpuidle_add_s2idle_attr_group(kobj);
> @@ -646,7 +646,7 @@ static int cpuidle_add_driver_sysfs(struct cpuidle_device *dev)
> ret = kobject_init_and_add(&kdrv->kobj, &ktype_driver_cpuidle,
> &kdev->kobj, "driver");
> if (ret) {
> - kfree(kdrv);
> + kobject_put(&kdrv->kobj);
> return ret;
> }
>
> @@ -740,7 +740,7 @@ int cpuidle_add_sysfs(struct cpuidle_device *dev)
> error = kobject_init_and_add(&kdev->kobj, &ktype_cpuidle, &cpu_dev->kobj,
> "cpuidle");
> if (error) {
> - kfree(kdev);
> + kobject_put(&kdev->kobj);
> return error;
> }
>
> --
Applied as 5.8 material, thanks!
^ permalink raw reply
* Re: [PATCH v4 04/11] thermal: Store device mode in struct thermal_zone_device
From: Andrzej Pietrasiewicz @ 2020-05-29 16:08 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-pm, linux-acpi, netdev, linux-wireless, platform-driver-x86,
linux-arm-kernel, linux-renesas-soc, linux-rockchip,
Emmanuel Grumbach, Heiko Stuebner, Rafael J . Wysocki,
Vishal Kulkarni, Luca Coelho, Miquel Raynal, kernel,
Fabio Estevam, Amit Kucheria, Chunyan Zhang, Daniel Lezcano,
Allison Randal, NXP Linux Team, Darren Hart, Zhang Rui,
Gayatri Kammela, Len Brown, Johannes Berg, Intel Linux Wireless,
Sascha Hauer, Ido Schimmel, Baolin Wang, Jiri Pirko, Orson Zhai,
Thomas Gleixner, Kalle Valo, Support Opensource, Enrico Weigelt,
Peter Kaestle, Sebastian Reichel, Bartlomiej Zolnierkiewicz,
Pengutronix Kernel Team, Niklas Söderlund, Shawn Guo,
David S . Miller, Andy Shevchenko
In-Reply-To: <20200529154205.GA157653@roeck-us.net>
Hi Guenter,
W dniu 29.05.2020 o 17:42, Guenter Roeck pisze:
> On Thu, May 28, 2020 at 09:20:44PM +0200, Andrzej Pietrasiewicz wrote:
>> Prepare for eliminating get_mode().
>>
> Might be worthwhile to explain (not only in the subject) what you are
> doing here.
>
>> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
>> ---
>> drivers/acpi/thermal.c | 18 ++++++----------
>> .../ethernet/mellanox/mlxsw/core_thermal.c | 21 +++++++------------
>> drivers/platform/x86/acerhdf.c | 15 ++++++-------
>> drivers/thermal/da9062-thermal.c | 6 ++----
>> drivers/thermal/imx_thermal.c | 17 +++++++--------
>> .../intel/int340x_thermal/int3400_thermal.c | 12 +++--------
>> .../thermal/intel/intel_quark_dts_thermal.c | 16 +++++++-------
>> drivers/thermal/thermal_of.c | 10 +++------
>
> After this patch is applied on top of the thermal 'testing' branch,
> there are still local instances of thermal_device_mode in
> drivers/thermal/st/stm_thermal.c
> drivers/thermal/ti-soc-thermal/ti-thermal-common.c
>
> If there is a reason not to replace those, it might make sense to explain
> it here.
>
My understanding is that these two are sensor devices which are "plugged"
into their "parent" thermal zone device. The latter is the "proper" tzd.
They both use thermal_zone_of_device_ops instead of thermal_zone_device_ops.
The former doesn't even have get_mode(). The thermal core, when it calls
get_mode(), operates on the "parent" thermal zone devices.
Consequently, the drivers you mention use their "mode" members for
their private purpose, not for the purpose of storing the "parent"
thermal zone device mode.
Andrzej
^ permalink raw reply
* linusw/for-next boot: 46 boots: 0 failed, 46 passed (v5.7-rc7-88-g5e9fc19f525b)
From: kernelci.org bot @ 2020-05-29 16:08 UTC (permalink / raw)
To: linux-gpio, fellows
******************************************
* WARNING: Boot tests are now deprecated *
******************************************
As kernelci.org is expanding its functional testing capabilities, the concept
of boot testing is now deprecated. Boot results are scheduled to be dropped on
*5th June 2020*. The full schedule for boot tests deprecation is available on
this GitHub issue: https://github.com/kernelci/kernelci-backend/issues/238
The new equivalent is the *baseline* test suite which also runs sanity checks
using dmesg and bootrr: https://github.com/kernelci/bootrr
See the *baseline results for this kernel revision* on this page:
https://kernelci.org/test/job/linusw/branch/for-next/kernel/v5.7-rc7-88-g5e9fc19f525b/plan/baseline/
-------------------------------------------------------------------------------
linusw/for-next boot: 46 boots: 0 failed, 46 passed (v5.7-rc7-88-g5e9fc19f525b)
Full Boot Summary: https://kernelci.org/boot/all/job/linusw/branch/for-next/kernel/v5.7-rc7-88-g5e9fc19f525b/
Full Build Summary: https://kernelci.org/build/linusw/branch/for-next/kernel/v5.7-rc7-88-g5e9fc19f525b/
Tree: linusw
Branch: for-next
Git Describe: v5.7-rc7-88-g5e9fc19f525b
Git Commit: 5e9fc19f525b67967cc10d3ca8e85214fc3c26bd
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/
Tested: 46 unique boards, 13 SoC families, 2 builds out of 5
---
For more info write to <info@kernelci.org>
^ permalink raw reply
* [PATCH 23/24] KVM: arm64: Parametrize exception entry with a target EL
From: Marc Zyngier @ 2020-05-29 16:01 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Mark Rutland, kvmarm, kvm, Will Deacon, Suzuki K Poulose,
Keqian Zhu, Christoffer Dall, Jiang Yi, James Morse, Andrew Scull,
Zenghui Yu, Julien Thierry, David Brazdil, Alexandru Elisei,
Ard Biesheuvel, Fuad Tabba, linux-arm-kernel
In-Reply-To: <20200529160121.899083-1-maz@kernel.org>
We currently assume that an exception is delivered to EL1, always.
Once we emulate EL2, this no longer will be the case. To prepare
for this, add a target_mode parameter.
While we're at it, merge the computing of the target PC and PSTATE in
a single function that updates both PC and CPSR after saving their
previous values in the corresponding ELR/SPSR. This ensures that they
are updated in the correct order (a pretty common source of bugs...).
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/include/asm/ptrace.h | 1 +
arch/arm64/kvm/inject_fault.c | 75 +++++++++++++++++----------------
2 files changed, 39 insertions(+), 37 deletions(-)
diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index bf57308fcd63..953b6a1ce549 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -35,6 +35,7 @@
#define GIC_PRIO_PSR_I_SET (1 << 4)
/* Additional SPSR bits not exposed in the UABI */
+#define PSR_MODE_THREAD_BIT (1 << 0)
#define PSR_IL_BIT (1 << 20)
/* AArch32-specific ptrace requests */
diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
index 6aafc2825c1c..e21fdd93027a 100644
--- a/arch/arm64/kvm/inject_fault.c
+++ b/arch/arm64/kvm/inject_fault.c
@@ -26,28 +26,12 @@ enum exception_type {
except_type_serror = 0x180,
};
-static u64 get_except_vector(struct kvm_vcpu *vcpu, enum exception_type type)
-{
- u64 exc_offset;
-
- switch (*vcpu_cpsr(vcpu) & (PSR_MODE_MASK | PSR_MODE32_BIT)) {
- case PSR_MODE_EL1t:
- exc_offset = CURRENT_EL_SP_EL0_VECTOR;
- break;
- case PSR_MODE_EL1h:
- exc_offset = CURRENT_EL_SP_ELx_VECTOR;
- break;
- case PSR_MODE_EL0t:
- exc_offset = LOWER_EL_AArch64_VECTOR;
- break;
- default:
- exc_offset = LOWER_EL_AArch32_VECTOR;
- }
-
- return vcpu_read_sys_reg(vcpu, VBAR_EL1) + exc_offset + type;
-}
-
/*
+ * This performs the exception entry at a given EL (@target_mode), stashing PC
+ * and PSTATE into ELR and SPSR respectively, and compute the new PC/PSTATE.
+ * The EL passed to this function *must* be a non-secure, privileged mode with
+ * bit 0 being set (PSTATE.SP == 1).
+ *
* When an exception is taken, most PSTATE fields are left unchanged in the
* handler. However, some are explicitly overridden (e.g. M[4:0]). Luckily all
* of the inherited bits have the same position in the AArch64/AArch32 SPSR_ELx
@@ -59,10 +43,35 @@ static u64 get_except_vector(struct kvm_vcpu *vcpu, enum exception_type type)
* Here we manipulate the fields in order of the AArch64 SPSR_ELx layout, from
* MSB to LSB.
*/
-static unsigned long get_except64_pstate(struct kvm_vcpu *vcpu)
+static void enter_exception64(struct kvm_vcpu *vcpu, unsigned long target_mode,
+ enum exception_type type)
{
- unsigned long sctlr = vcpu_read_sys_reg(vcpu, SCTLR_EL1);
- unsigned long old, new;
+ unsigned long sctlr, vbar, old, new, mode;
+ u64 exc_offset;
+
+ mode = *vcpu_cpsr(vcpu) & (PSR_MODE_MASK | PSR_MODE32_BIT);
+
+ if (mode == target_mode)
+ exc_offset = CURRENT_EL_SP_ELx_VECTOR;
+ else if ((mode | PSR_MODE_THREAD_BIT) == target_mode)
+ exc_offset = CURRENT_EL_SP_EL0_VECTOR;
+ else if (!(mode & PSR_MODE32_BIT))
+ exc_offset = LOWER_EL_AArch64_VECTOR;
+ else
+ exc_offset = LOWER_EL_AArch32_VECTOR;
+
+ switch (target_mode) {
+ case PSR_MODE_EL1h:
+ vbar = vcpu_read_sys_reg(vcpu, VBAR_EL1);
+ sctlr = vcpu_read_sys_reg(vcpu, SCTLR_EL1);
+ vcpu_write_elr_el1(vcpu, *vcpu_pc(vcpu));
+ break;
+ default:
+ /* Don't do that */
+ BUG();
+ }
+
+ *vcpu_pc(vcpu) = vbar + exc_offset + type;
old = *vcpu_cpsr(vcpu);
new = 0;
@@ -105,9 +114,10 @@ static unsigned long get_except64_pstate(struct kvm_vcpu *vcpu)
new |= PSR_I_BIT;
new |= PSR_F_BIT;
- new |= PSR_MODE_EL1h;
+ new |= target_mode;
- return new;
+ *vcpu_cpsr(vcpu) = new;
+ vcpu_write_spsr(vcpu, old);
}
static void inject_abt64(struct kvm_vcpu *vcpu, bool is_iabt, unsigned long addr)
@@ -116,11 +126,7 @@ static void inject_abt64(struct kvm_vcpu *vcpu, bool is_iabt, unsigned long addr
bool is_aarch32 = vcpu_mode_is_32bit(vcpu);
u32 esr = 0;
- vcpu_write_elr_el1(vcpu, *vcpu_pc(vcpu));
- *vcpu_pc(vcpu) = get_except_vector(vcpu, except_type_sync);
-
- *vcpu_cpsr(vcpu) = get_except64_pstate(vcpu);
- vcpu_write_spsr(vcpu, cpsr);
+ enter_exception64(vcpu, PSR_MODE_EL1h, except_type_sync);
vcpu_write_sys_reg(vcpu, addr, FAR_EL1);
@@ -148,14 +154,9 @@ static void inject_abt64(struct kvm_vcpu *vcpu, bool is_iabt, unsigned long addr
static void inject_undef64(struct kvm_vcpu *vcpu)
{
- unsigned long cpsr = *vcpu_cpsr(vcpu);
u32 esr = (ESR_ELx_EC_UNKNOWN << ESR_ELx_EC_SHIFT);
- vcpu_write_elr_el1(vcpu, *vcpu_pc(vcpu));
- *vcpu_pc(vcpu) = get_except_vector(vcpu, except_type_sync);
-
- *vcpu_cpsr(vcpu) = get_except64_pstate(vcpu);
- vcpu_write_spsr(vcpu, cpsr);
+ enter_exception64(vcpu, PSR_MODE_EL1h, except_type_sync);
/*
* Build an unknown exception, depending on the instruction
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v4 04/11] thermal: Store device mode in struct thermal_zone_device
From: Andrzej Pietrasiewicz @ 2020-05-29 16:08 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-pm, linux-acpi, netdev, linux-wireless, platform-driver-x86,
linux-arm-kernel, linux-renesas-soc, linux-rockchip,
Emmanuel Grumbach, Heiko Stuebner, Rafael J . Wysocki,
Vishal Kulkarni, Luca Coelho, Miquel Raynal, kernel,
Fabio Estevam, Amit Kucheria, Chunyan Zhang, Daniel Lezcano,
Allison Randal, NXP Linux Team
In-Reply-To: <20200529154205.GA157653@roeck-us.net>
Hi Guenter,
W dniu 29.05.2020 o 17:42, Guenter Roeck pisze:
> On Thu, May 28, 2020 at 09:20:44PM +0200, Andrzej Pietrasiewicz wrote:
>> Prepare for eliminating get_mode().
>>
> Might be worthwhile to explain (not only in the subject) what you are
> doing here.
>
>> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
>> ---
>> drivers/acpi/thermal.c | 18 ++++++----------
>> .../ethernet/mellanox/mlxsw/core_thermal.c | 21 +++++++------------
>> drivers/platform/x86/acerhdf.c | 15 ++++++-------
>> drivers/thermal/da9062-thermal.c | 6 ++----
>> drivers/thermal/imx_thermal.c | 17 +++++++--------
>> .../intel/int340x_thermal/int3400_thermal.c | 12 +++--------
>> .../thermal/intel/intel_quark_dts_thermal.c | 16 +++++++-------
>> drivers/thermal/thermal_of.c | 10 +++------
>
> After this patch is applied on top of the thermal 'testing' branch,
> there are still local instances of thermal_device_mode in
> drivers/thermal/st/stm_thermal.c
> drivers/thermal/ti-soc-thermal/ti-thermal-common.c
>
> If there is a reason not to replace those, it might make sense to explain
> it here.
>
My understanding is that these two are sensor devices which are "plugged"
into their "parent" thermal zone device. The latter is the "proper" tzd.
They both use thermal_zone_of_device_ops instead of thermal_zone_device_ops.
The former doesn't even have get_mode(). The thermal core, when it calls
get_mode(), operates on the "parent" thermal zone devices.
Consequently, the drivers you mention use their "mode" members for
their private purpose, not for the purpose of storing the "parent"
thermal zone device mode.
Andrzej
^ permalink raw reply
* [PATCH 11/24] KVM: arm64: Clean up the checking for huge mapping
From: Marc Zyngier @ 2020-05-29 16:01 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Mark Rutland, kvmarm, kvm, Will Deacon, Suzuki K Poulose,
Keqian Zhu, Christoffer Dall, Jiang Yi, James Morse, Andrew Scull,
Zenghui Yu, Julien Thierry, David Brazdil, Alexandru Elisei,
Ard Biesheuvel, Fuad Tabba, linux-arm-kernel
In-Reply-To: <20200529160121.899083-1-maz@kernel.org>
From: Suzuki K Poulose <suzuki.poulose@arm.com>
If we are checking whether the stage2 can map PAGE_SIZE,
we don't have to do the boundary checks as both the host
VMA and the guest memslots are page aligned. Bail the case
easily.
While we're at it, fixup a typo in the comment below.
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20200507123546.1875-2-yuzenghui@huawei.com
---
arch/arm64/kvm/mmu.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 917363375e8a..ccb44e7d30d9 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1610,6 +1610,10 @@ static bool fault_supports_stage2_huge_mapping(struct kvm_memory_slot *memslot,
hva_t uaddr_start, uaddr_end;
size_t size;
+ /* The memslot and the VMA are guaranteed to be aligned to PAGE_SIZE */
+ if (map_size == PAGE_SIZE)
+ return true;
+
size = memslot->npages * PAGE_SIZE;
gpa_start = memslot->base_gfn << PAGE_SHIFT;
@@ -1629,7 +1633,7 @@ static bool fault_supports_stage2_huge_mapping(struct kvm_memory_slot *memslot,
* |abcde|fgh Stage-1 block | Stage-1 block tv|xyz|
* +-----+--------------------+--------------------+---+
*
- * memslot->base_gfn << PAGE_SIZE:
+ * memslot->base_gfn << PAGE_SHIFT:
* +---+--------------------+--------------------+-----+
* |abc|def Stage-2 block | Stage-2 block |tvxyz|
* +---+--------------------+--------------------+-----+
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.