* Re: [PATCH] ppc64/fadump: fix inaccurate CPU state info in vmcore generated with panic
From: Hari Bathini @ 2021-11-17 6:09 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev, Michael Ellerman; +Cc: mahesh, sourabhjain
In-Reply-To: <1636636120.84ownze0a9.astroid@bobo.none>
On 11/11/21 6:50 pm, Nicholas Piggin wrote:
> Excerpts from Hari Bathini's message of November 11, 2021 10:06 pm:
>>
>>
>> On 11/11/21 11:44 am, Michael Ellerman wrote:
>>> Hari Bathini <hbathini@linux.ibm.com> writes:
>>>> In panic path, fadump is triggered via a panic notifier function.
>>>> Before calling panic notifier functions, smp_send_stop() gets called,
>>>> which stops all CPUs except the panic'ing CPU. Commit 8389b37dffdc
>>>> ("powerpc: stop_this_cpu: remove the cpu from the online map.") and
>>>> again commit bab26238bbd4 ("powerpc: Offline CPU in stop_this_cpu()")
>>>> started marking CPUs as offline while stopping them. So, if a kernel
>>>> has either of the above commits, vmcore captured with fadump via panic
>>>> path would show only the panic'ing CPU as online. Sample output of
>>>> crash-utility with such vmcore:
>>>>
>>>> # crash vmlinux vmcore
>>>> ...
>>>> KERNEL: vmlinux
>>>> DUMPFILE: vmcore [PARTIAL DUMP]
>>>> CPUS: 1
>>>> DATE: Wed Nov 10 09:56:34 EST 2021
>>>> UPTIME: 00:00:42
>>>> LOAD AVERAGE: 2.27, 0.69, 0.24
>>>> TASKS: 183
>>>> NODENAME: XXXXXXXXX
>>>> RELEASE: 5.15.0+
>>>> VERSION: #974 SMP Wed Nov 10 04:18:19 CST 2021
>>>> MACHINE: ppc64le (2500 Mhz)
>>>> MEMORY: 8 GB
>>>> PANIC: "Kernel panic - not syncing: sysrq triggered crash"
>>>> PID: 3394
>>>> COMMAND: "bash"
>>>> TASK: c0000000150a5f80 [THREAD_INFO: c0000000150a5f80]
>>>> CPU: 1
>>>> STATE: TASK_RUNNING (PANIC)
>>>>
>>>> crash> p -x __cpu_online_mask
>>>> __cpu_online_mask = $1 = {
>>>> bits = {0x2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
>>>> }
>>>> crash>
>>>> crash>
>>>> crash> p -x __cpu_active_mask
>>>> __cpu_active_mask = $2 = {
>>>> bits = {0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
>>>> }
>>>> crash>
>>>>
>>>> While this has been the case since fadump was introduced, the issue
>>>> was not identified for two probable reasons:
>>>>
>>>> - In general, the bulk of the vmcores analyzed were from crash
>>>> due to exception.
>>>>
>>>> - The above did change since commit 8341f2f222d7 ("sysrq: Use
>>>> panic() to force a crash") started using panic() instead of
>>>> deferencing NULL pointer to force a kernel crash. But then
>>>> commit de6e5d38417e ("powerpc: smp_send_stop do not offline
>>>> stopped CPUs") stopped marking CPUs as offline till kernel
>>>> commit bab26238bbd4 ("powerpc: Offline CPU in stop_this_cpu()")
>>>> reverted that change.
>>>>
>>>> To avoid vmcore from showing only one CPU as online in panic path,
>>>> skip marking non panic'ing CPUs as offline while stopping them
>>>> during fadump crash.
>>>
>>> Is this really worth the added complexity/bug surface?
>>>
>>> Why does it matter if the vmcore shows only one CPU online?
>>
>> We lose out on backtrace/register data of non-crashing CPUs as they
>> are explicitly marked offline.
>>
>> Actually, the state of CPU resources is explicitly changed after the
>> panic though the aim of vmcore is to capture the system state at the
>> time of panic...
>>
>> Alternatively, how about moving crash_fadump() call from panic notifier
>> into panic() function explicitly, just like __crash_kexec() - before the
>> smp_send_stop() call, so as to remove dependency with smp_send_stop()
>> implementation altogether...
>
> Does the crash dump code snapshot the CPUs with send_debuggr_break? I
> can't remember the exact flow. But if it sends NMI IPIs to all other
> CPUs then maybe it could be moved before smp_send_stop, good idea.
Except for crashing CPU, snapshot of register data for all other CPUs is
collected by f/w on ibm,os-term rtas call.
>>> The comment talks about printk_safe_flush_on_panic(), and this change
>>> would presumably break that. Except that printk_safe_flush_on_panic() no
>>> longer exists.
>>>
>>> So do we need to set the CPU online here at all?
>>>
>>> ie. could we revert bab26238bbd4 ("powerpc: Offline CPU in stop_this_cpu()")
>>> now that printk_safe_flush_on_panic() no longer exists?
>>
>> Yeah, sounds like the logical thing to do but I guess, Nick would be in
>> a better position to answer this..
>
> Maybe we could look at reverting it, it would be nice. But I think it
> would be good to consider moving crash_fadump as well. There is at
OK, I will try moving crash_fadump() instead and post the patch..
Thanks
Hari
^ permalink raw reply
* Re: [PATCH v2 1/2] powerpc/rtas: rtas_busy_delay() improvements
From: Nathan Lynch @ 2021-11-17 6:13 UTC (permalink / raw)
To: linuxppc-dev; +Cc: aik, tyreld, cheloha, ldufour, ajd
In-Reply-To: <20211117060259.957178-2-nathanl@linux.ibm.com>
Nathan Lynch <nathanl@linux.ibm.com> writes:
>
> Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
> ---
>
> Notes:
> This could be considered a sequel to:
>
> https://lore.kernel.org/linuxppc-dev/20210504030358.1715034-1-nathanl@linux.ibm.com/
>
> which tried to address both the suboptimal delay behavior as well as naming
> issues. The present change achieves the performance improvement and leaves
> the matter of naming for another time.
>
> I've incorporated Alexey's feedback from that series to avoid division when
> calculating the arguments to usleep_range().
Oops, this part is redundant with information in the cover. Git should
discard it if/when applied, though.
^ permalink raw reply
* Re: [RESEND PATCH v5 0/4] Add perf interface to expose nvdimm
From: kajoljain @ 2021-11-17 6:17 UTC (permalink / raw)
To: LEROY Christophe, mpe@ellerman.id.au,
linuxppc-dev@lists.ozlabs.org, nvdimm@lists.linux.dev,
linux-kernel@vger.kernel.org, peterz@infradead.org,
dan.j.williams@intel.com, ira.weiny@intel.com,
vishal.l.verma@intel.com
Cc: santosh@fossix.org, maddy@linux.ibm.com, rnsastry@linux.ibm.com,
aneesh.kumar@linux.ibm.com, atrajeev@linux.vnet.ibm.com,
vaibhav@linux.ibm.com
In-Reply-To: <8bc3f62b-881f-d919-8726-95610d1bc133@csgroup.eu>
On 11/16/21 8:29 PM, LEROY Christophe wrote:
> Hi
>
> Le 16/11/2021 à 05:49, Kajol Jain a écrit :
>> Patchset adds performance stats reporting support for nvdimm.
>> Added interface includes support for pmu register/unregister
>> functions. A structure is added called nvdimm_pmu to be used for
>> adding arch/platform specific data such as cpumask, nvdimm device
>> pointer and pmu event functions like event_init/add/read/del.
>> User could use the standard perf tool to access perf events
>> exposed via pmu.
>>
>> Interface also defines supported event list, config fields for the
>> event attributes and their corresponding bit values which are exported
>> via sysfs. Patch 3 exposes IBM pseries platform nmem* device
>> performance stats using this interface.
>
> You resending your v5 series ? Is there any news since your submittion
> last month that's awaiting in patchwork here at
> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=264422 ?
Hi Christophe,
There is no code side changes from the last v5 version. Since, I
am looking for reviews, again posted this patchset with RESEND tag.
Thanks,
Kajol Jain
>
> Christophe
>
>
>>
>> Result from power9 pseries lpar with 2 nvdimm device:
>>
>> Ex: List all event by perf list
>>
>> command:# perf list nmem
>>
>> nmem0/cache_rh_cnt/ [Kernel PMU event]
>> nmem0/cache_wh_cnt/ [Kernel PMU event]
>> nmem0/cri_res_util/ [Kernel PMU event]
>> nmem0/ctl_res_cnt/ [Kernel PMU event]
>> nmem0/ctl_res_tm/ [Kernel PMU event]
>> nmem0/fast_w_cnt/ [Kernel PMU event]
>> nmem0/host_l_cnt/ [Kernel PMU event]
>> nmem0/host_l_dur/ [Kernel PMU event]
>> nmem0/host_s_cnt/ [Kernel PMU event]
>> nmem0/host_s_dur/ [Kernel PMU event]
>> nmem0/med_r_cnt/ [Kernel PMU event]
>> nmem0/med_r_dur/ [Kernel PMU event]
>> nmem0/med_w_cnt/ [Kernel PMU event]
>> nmem0/med_w_dur/ [Kernel PMU event]
>> nmem0/mem_life/ [Kernel PMU event]
>> nmem0/poweron_secs/ [Kernel PMU event]
>> ...
>> nmem1/mem_life/ [Kernel PMU event]
>> nmem1/poweron_secs/ [Kernel PMU event]
>>
>> Patch1:
>> Introduces the nvdimm_pmu structure
>> Patch2:
>> Adds common interface to add arch/platform specific data
>> includes nvdimm device pointer, pmu data along with
>> pmu event functions. It also defines supported event list
>> and adds attribute groups for format, events and cpumask.
>> It also adds code for cpu hotplug support.
>> Patch3:
>> Add code in arch/powerpc/platform/pseries/papr_scm.c to expose
>> nmem* pmu. It fills in the nvdimm_pmu structure with pmu name,
>> capabilities, cpumask and event functions and then registers
>> the pmu by adding callbacks to register_nvdimm_pmu.
>> Patch4:
>> Sysfs documentation patch
>>
>> Changelog
>> ---
>> v4 -> v5:
>> - Remove multiple variables defined in nvdimm_pmu structure include
>> name and pmu functions(event_int/add/del/read) as they are just
>> used to copy them again in pmu variable. Now we are directly doing
>> this step in arch specific code as suggested by Dan Williams.
>>
>> - Remove attribute group field from nvdimm pmu structure and
>> defined these attribute groups in common interface which
>> includes format, event list along with cpumask as suggested by
>> Dan Williams.
>> Since we added static defination for attrbute groups needed in
>> common interface, removes corresponding code from papr.
>>
>> - Add nvdimm pmu event list with event codes in the common interface.
>>
>> - Remove Acked-by/Reviewed-by/Tested-by tags as code is refactored
>> to handle review comments from Dan.
>>
>> - Make nvdimm_pmu_free_hotplug_memory function static as reported
>> by kernel test robot, also add corresponding Reported-by tag.
>>
>> - Link to the patchset v4: https://lkml.org/lkml/2021/9/3/45
>>
>> v3 -> v4
>> - Rebase code on top of current papr_scm code without any logical
>> changes.
>>
>> - Added Acked-by tag from Peter Zijlstra and Reviewed by tag
>> from Madhavan Srinivasan.
>>
>> - Link to the patchset v3: https://lkml.org/lkml/2021/6/17/605
>>
>> v2 -> v3
>> - Added Tested-by tag.
>>
>> - Fix nvdimm mailing list in the ABI Documentation.
>>
>> - Link to the patchset v2: https://lkml.org/lkml/2021/6/14/25
>>
>> v1 -> v2
>> - Fix hotplug code by adding pmu migration call
>> incase current designated cpu got offline. As
>> pointed by Peter Zijlstra.
>>
>> - Removed the retun -1 part from cpu hotplug offline
>> function.
>>
>> - Link to the patchset v1: https://lkml.org/lkml/2021/6/8/500
>>
>> Kajol Jain (4):
>> drivers/nvdimm: Add nvdimm pmu structure
>> drivers/nvdimm: Add perf interface to expose nvdimm performance stats
>> powerpc/papr_scm: Add perf interface support
>> docs: ABI: sysfs-bus-nvdimm: Document sysfs event format entries for
>> nvdimm pmu
>>
>> Documentation/ABI/testing/sysfs-bus-nvdimm | 35 +++
>> arch/powerpc/include/asm/device.h | 5 +
>> arch/powerpc/platforms/pseries/papr_scm.c | 225 ++++++++++++++
>> drivers/nvdimm/Makefile | 1 +
>> drivers/nvdimm/nd_perf.c | 328 +++++++++++++++++++++
>> include/linux/nd.h | 41 +++
>> 6 files changed, 635 insertions(+)
>> create mode 100644 drivers/nvdimm/nd_perf.c
^ permalink raw reply
* Re: [PATCH 3/7] KVM: s390: Use Makefile.kvm for common files
From: Christian Borntraeger @ 2021-11-17 7:29 UTC (permalink / raw)
To: David Woodhouse, Paolo Bonzini, kvm
Cc: Anup Patel, wanpengli @ tencent . com, Catalin Marinas,
Joao Martins, Will Deacon, kvmarm, linux-s390,
joro @ 8bytes . org, Huacai Chen, Aleksandar Markovic, karahmed,
Suzuki K Poulose, Boris Ostrovsky, Alexandru Elisei,
linux-arm-kernel, jmattson @ google . com, seanjc @ google . com,
mtosatti @ redhat . com, linux-mips, James Morse, kvm-riscv,
Marc Zyngier, vkuznets @ redhat . com, linuxppc-dev
In-Reply-To: <20211116115051.119956-3-dwmw2@infradead.org>
Am 16.11.21 um 12:50 schrieb David Woodhouse:
> From: David Woodhouse <dwmw@amazon.co.uk>
>
> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Looks good.
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
> arch/s390/kvm/Makefile | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/s390/kvm/Makefile b/arch/s390/kvm/Makefile
> index b3aaadc60ead..e4f50453cf7f 100644
> --- a/arch/s390/kvm/Makefile
> +++ b/arch/s390/kvm/Makefile
> @@ -3,13 +3,11 @@
> #
> # Copyright IBM Corp. 2008
>
> -KVM := ../../../virt/kvm
> -common-objs = $(KVM)/kvm_main.o $(KVM)/eventfd.o $(KVM)/async_pf.o \
> - $(KVM)/irqchip.o $(KVM)/vfio.o $(KVM)/binary_stats.o
> +include $(srctree)/virt/kvm/Makefile.kvm
>
> ccflags-y := -Ivirt/kvm -Iarch/s390/kvm
>
> -kvm-objs := $(common-objs) kvm-s390.o intercept.o interrupt.o priv.o sigp.o
> +kvm-objs := kvm-s390.o intercept.o interrupt.o priv.o sigp.o
> kvm-objs += diag.o gaccess.o guestdbg.o vsie.o pv.o
>
> obj-$(CONFIG_KVM) += kvm.o
>
^ permalink raw reply
* Re: Build regressions/improvements in v5.16-rc1
From: Geert Uytterhoeven @ 2021-11-17 8:24 UTC (permalink / raw)
To: Nick Terrell
Cc: Hector Martin, Peter Zijlstra, linux-pci, DRI Development,
open list:BROADCOM NVRAM DRIVER, James E.J. Bottomley,
Andrey Ryabinin, Stan Skowronek, Herbert Xu, Helge Deller,
kasan-dev, Sergio Paracuellos, Anton Altaparmakov, linux-arm-msm,
open list:GPIO SUBSYSTEM, Joey Gouly, André Almeida,
Linux ARM, Thomas Bogendoerfer, Parisc List,
linux-ntfs-dev@lists.sourceforge.net, Randy Dunlap,
Linux Kernel Mailing List, Rob Clark, Linux Crypto Mailing List,
linuxppc-dev
In-Reply-To: <B57193D6-1FD4-45D3-8045-8D2DE691E24E@fb.com>
Hi Nick,
On Wed, Nov 17, 2021 at 3:20 AM Nick Terrell <terrelln@fb.com> wrote:
> > On Nov 16, 2021, at 6:05 PM, Randy Dunlap <rdunlap@infradead.org> wrote:
> > On 11/16/21 5:59 PM, Nick Terrell wrote:
> >> I’ll send the PR to Linus tomorrow. I’ve been informed that it
> >> isn't strictly necessary to send the patches to the mailing list
> >> for bug fixes, but its already done, so I’ll wait and see if there
> >> is any feedback.
> >
> > IMO several (or many more) people would disagree with that.
> >
> > "strictly?" OK, it's probably possible that almost any patch
> > could be merged without being on a mailing list, but it's not
> > desirable (except in the case of "security" patches).
>
> Good to know! Thanks for the advice, I wasn’t really sure what
> the best practice is for sending patches to your own tree, as I
> didn't see anything about it in the maintainer guide.
All patches must be sent to public mailing lists for review.
You might get away with not doing that for a simple and trivial fix,
but be prepared to end up on people's "special" lists if you did get
it wrong.
We are Legion. We do not forgive. We do not forget ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
^ permalink raw reply
* Re: [PATCH kernel 0/4] Fixes for powerpc/pseries/iommu: Make use of DDW for indirect mapping
From: Frederic Barrat @ 2021-11-17 10:19 UTC (permalink / raw)
To: Michael Ellerman, Alexey Kardashevskiy, linuxppc-dev
Cc: Leonardo Bras, Brian King
In-Reply-To: <163582100676.1804905.10010614237761858649.b4-ty@ellerman.id.au>
On 02/11/2021 03:43, Michael Ellerman wrote:
> On Thu, 21 Oct 2021 00:23:11 +1100, Alexey Kardashevskiy wrote:
>> Found some issues on SRIOV enabled PHYP.
>> It probably should be one patch, or not?
>>
>> Please comment. Thanks.
>>
>>
>>
>> [...]
>
> Patches 2-4 applied to powerpc/fixes.
Any reason why patch 1 was not applied? The indents are still wrong in
5.16-rc1
Fred
> [2/4] powerpc/pseries/iommu: Use correct vfree for it_map
> https://git.kernel.org/powerpc/c/41ee7232fa5f3c034f22baa52bc287e494e2129a
> [3/4] powerpc/pseries/iommu: Check if the default window in use before removing it
> https://git.kernel.org/powerpc/c/92fe01b7c655b9767724e7d62bdded0761d232ff
> [4/4] powerpc/pseries/iommu: Create huge DMA window if no MMIO32 is present
> https://git.kernel.org/powerpc/c/d853adc7adf601d7d6823afe3ed396065a3e08d1
>
> cheers
>
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: delete scanlog
From: Michael Ellerman @ 2021-11-17 10:37 UTC (permalink / raw)
To: Nathan Lynch, linuxppc-dev; +Cc: tyreld
In-Reply-To: <87sfvvijjw.fsf@linux.ibm.com>
Nathan Lynch <nathanl@linux.ibm.com> writes:
> Nathan Lynch <nathanl@linux.ibm.com> writes:
>> Remove the pseries scanlog driver.
>>
>> This code supports functions from Power4-era servers that are not present
>> on targets currently supported by arch/powerpc. System manuals from this
>> time have this description:
>>
>> Scan Dump data is a set of chip data that the service processor gathers
>> after a system malfunction. It consists of chip scan rings, chip trace
>> arrays, and Scan COM (SCOM) registers. This data is stored in the
>> scan-log partition of the system’s Nonvolatile Random Access
>> Memory (NVRAM).
>>
>> PowerVM partition firmware development doesn't recognize the associated
>> function call or property, and they don't see any references to them in
>> their codebase. It seems to have been specific to non-virtualized
>> pseries.
>
> Just bumping this to see if there are any objections.
Not an objection, I like nothing better than dropping old unused cruft,
but are we sure it's safe to remove the proc file?
I see that rtas_errd still looks for it, have you checked that it will
handle the absence of the file gracefully and continue doing whatever
else it does?
On further inspection it looks like the code that looks for it in
rtas_errd is #if 0'ed out (??), so maybe it's dead.
Anyway if you can test that rtas_errd still works that'd be good.
Presumably there's no other code that cares about the proc file.
cheers
^ permalink raw reply
* Re: [PATCH kernel 0/4] Fixes for powerpc/pseries/iommu: Make use of DDW for indirect mapping
From: Frederic Barrat @ 2021-11-17 10:58 UTC (permalink / raw)
To: Michael Ellerman, Alexey Kardashevskiy, linuxppc-dev
Cc: Leonardo Bras, Brian King
In-Reply-To: <98447986-ecef-13eb-1fd3-a635cb75fba7@linux.ibm.com>
On 17/11/2021 11:19, Frederic Barrat wrote:
>
>
> On 02/11/2021 03:43, Michael Ellerman wrote:
>> On Thu, 21 Oct 2021 00:23:11 +1100, Alexey Kardashevskiy wrote:
>>> Found some issues on SRIOV enabled PHYP.
>>> It probably should be one patch, or not?
>>>
>>> Please comment. Thanks.
>>>
>>>
>>>
>>> [...]
>>
>> Patches 2-4 applied to powerpc/fixes.
>
>
> Any reason why patch 1 was not applied? The indents are still wrong in
> 5.16-rc1
Ah, Alexey has reposted it later:
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20211108040320.3857636-3-aik@ozlabs.ru/
Apologies for the noise...
Fred
>
>> [2/4] powerpc/pseries/iommu: Use correct vfree for it_map
>>
>> https://git.kernel.org/powerpc/c/41ee7232fa5f3c034f22baa52bc287e494e2129a
>> [3/4] powerpc/pseries/iommu: Check if the default window in use before
>> removing it
>>
>> https://git.kernel.org/powerpc/c/92fe01b7c655b9767724e7d62bdded0761d232ff
>> [4/4] powerpc/pseries/iommu: Create huge DMA window if no MMIO32 is
>> present
>>
>> https://git.kernel.org/powerpc/c/d853adc7adf601d7d6823afe3ed396065a3e08d1
>>
>> cheers
>>
^ permalink raw reply
* Re: Build regressions/improvements in v5.16-rc1
From: Helge Deller @ 2021-11-17 11:22 UTC (permalink / raw)
To: Nick Terrell, Randy Dunlap
Cc: Peter Zijlstra, linux-pci, DRI Development,
open list:BROADCOM NVRAM DRIVER, James E.J. Bottomley,
Andrey Ryabinin, Stan Skowronek, Herbert Xu, kasan-dev,
Sergio Paracuellos, Geert Uytterhoeven, Anton Altaparmakov,
linux-arm-msm, open list:GPIO SUBSYSTEM, Joey Gouly,
André Almeida, Linux ARM, Thomas Bogendoerfer, Parisc List,
linux-ntfs-dev@lists.sourceforge.net, Hector Martin,
Linux Kernel Mailing List, Rob Clark, Linux Crypto Mailing List,
linuxppc-dev
In-Reply-To: <B57193D6-1FD4-45D3-8045-8D2DE691E24E@fb.com>
On 11/17/21 03:19, Nick Terrell wrote:
>
>
>> On Nov 16, 2021, at 6:05 PM, Randy Dunlap <rdunlap@infradead.org> wrote:
>>
>> On 11/16/21 5:59 PM, Nick Terrell wrote:
>>>> On Nov 15, 2021, at 8:44 AM, Helge Deller <deller@gmx.de> wrote:
>>>>
>>>> On 11/15/21 17:12, Geert Uytterhoeven wrote:
>>>>> On Mon, Nov 15, 2021 at 4:54 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>>>>> Below is the list of build error/warning regressions/improvements in
>>>>>> v5.16-rc1[1] compared to v5.15[2].
>>>>>>
>>>>>> Summarized:
>>>>>> - build errors: +20/-13
>>>>>> - build warnings: +3/-28
>>>>>>
>>>>>> Happy fixing! ;-)
>>>>>>
>>>>>> Thanks to the linux-next team for providing the build service.
>>>>>>
>>>>>> [1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf/ (all 90 configs)
>>>>>> [2] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/8bb7eca972ad531c9b149c0a51ab43a417385813/ (all 90 configs)
>>>>>>
>>>>>>
>>>>>> *** ERRORS ***
>>>>>>
>>>>>> 20 error regressions:
>>>>>> + /kisskb/src/arch/parisc/include/asm/jump_label.h: error: expected ':' before '__stringify': => 33:4, 18:4
>>>>>> + /kisskb/src/arch/parisc/include/asm/jump_label.h: error: label 'l_yes' defined but not used [-Werror=unused-label]: => 38:1, 23:1
>>>>>
>>>>> due to static_branch_likely() in crypto/api.c
>>>>>
>>>>> parisc-allmodconfig
>>>>
>>>> fixed now in the parisc for-next git tree.
>>>>
>>>>
>>>>>> + /kisskb/src/drivers/gpu/drm/msm/msm_drv.h: error: "COND" redefined [-Werror]: => 531
>>>>>> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size of 3252 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 47:1
>>>>>> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size of 3360 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 499:1
>>>>>> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size of 5344 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 334:1
>>>>>> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size of 5380 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 354:1
>>>>>> + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 1824 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 372:1
>>>>>> + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 2224 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 204:1
>>>>>> + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 3800 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 476:1
>>>>>
>>>>> parisc-allmodconfig
>>>>
>>>> parisc needs much bigger frame sizes, so I'm not astonished here.
>>>> During the v5.15 cycl I increased it to 1536 (from 1280), so I'm simply tempted to
>>>> increase it this time to 4096, unless someone has a better idea....
>>> This patch set should fix the zstd stack size warnings [0]. I’ve
>>> verified the fix using the same tooling: gcc-8-hppa-linux-gnu.
>>> I’ll send the PR to Linus tomorrow. I’ve been informed that it
>>> isn't strictly necessary to send the patches to the mailing list
>>> for bug fixes, but its already done, so I’ll wait and see if there
>>> is any feedback.
>>
>> IMO several (or many more) people would disagree with that.
>>
>> "strictly?" OK, it's probably possible that almost any patch
>> could be merged without being on a mailing list, but it's not
>> desirable (except in the case of "security" patches).
>
> Good to know! Thanks for the advice, I wasn’t really sure what
> the best practice is for sending patches to your own tree, as I
> didn't see anything about it in the maintainer guide.
Nick, thanks a lot for your efforts to get the frame size usage down!
I've applied your patch series to the parisc for-next tree [1], so that it
gets some testing in the upstream for-next tree.
My tests so far are good, although I'm only using gcc-11.
If you don't mind, and if it doesn't generate issues for other
platforms & architectures I could submit them upstream to Linus when
I send the next pull request.
Helge
[1] https://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git/log/?h=for-next
^ permalink raw reply
* Re: [PATCH kernel 0/3] powerpc/pseries/ddw: Fixes for persistent memory case
From: Michael Ellerman @ 2021-11-17 11:23 UTC (permalink / raw)
To: linuxppc-dev, Alexey Kardashevskiy
Cc: Frederic Barrat, Leonardo Bras, Brian King
In-Reply-To: <20211108040320.3857636-1-aik@ozlabs.ru>
On Mon, 8 Nov 2021 15:03:16 +1100, Alexey Kardashevskiy wrote:
> This is based on sha1
> f855455dee0b Michael Ellerman "Automatic merge of 'next' into merge (2021-11-05 22:19)".
>
> Please comment. Thanks.
>
>
>
> [...]
Applied to powerpc/fixes.
[1/3] powerpc/pseries/ddw: Revert "Extend upper limit for huge DMA window for persistent memory"
https://git.kernel.org/powerpc/c/2d33f5504490a9d90924476dbccd4a5349ee1ad0
[2/3] powerpc/pseries/ddw: simplify enable_ddw()
https://git.kernel.org/powerpc/c/fb4ee2b30cd09e95524640149e4ee0d7f22c3e7b
[3/3] powerpc/pseries/ddw: Do not try direct mapping with persistent memory and one window
https://git.kernel.org/powerpc/c/ad3976025b311cdeb822ad3e7a7554018cb0f83f
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/8xx: Fix pinned TLBs with CONFIG_STRICT_KERNEL_RWX
From: Michael Ellerman @ 2021-11-17 11:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Christophe Leroy
Cc: linuxppc-dev, linux-kernel, stable
In-Reply-To: <a21e9a057fe2d247a535aff0d157a54eefee017a.1636963688.git.christophe.leroy@csgroup.eu>
On Mon, 15 Nov 2021 09:08:36 +0100, Christophe Leroy wrote:
> As spotted and explained in commit c12ab8dbc492 ("powerpc/8xx: Fix
> Oops with STRICT_KERNEL_RWX without DEBUG_RODATA_TEST"), the selection
> of STRICT_KERNEL_RWX without selecting DEBUG_RODATA_TEST has spotted
> the lack of the DIRTY bit in the pinned kernel data TLBs.
>
> This problem should have been detected a lot earlier if things had
> been working as expected. But due to an incredible level of chance or
> mishap, this went undetected because of a set of bugs: In fact the
> DTLBs were not pinned, because instead of setting the reserve bit
> in MD_CTR, it was set in MI_CTR that is the register for ITLBs.
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/8xx: Fix pinned TLBs with CONFIG_STRICT_KERNEL_RWX
https://git.kernel.org/powerpc/c/1e35eba4055149c578baf0318d2f2f89ea3c44a0
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/book3e: Fix TLBCAM preset at boot
From: Michael Ellerman @ 2021-11-17 11:23 UTC (permalink / raw)
To: Michael Ellerman, Paul Mackerras, Christophe Leroy,
Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-kernel, Christian Zigotzky
In-Reply-To: <d319f2a9367d4d08fd2154e506101bd5f100feeb.1636967119.git.christophe.leroy@csgroup.eu>
On Mon, 15 Nov 2021 10:05:32 +0100, Christophe Leroy wrote:
> Commit 52bda69ae8b5 ("powerpc/fsl_booke: Tell map_mem_in_cams() if
> init is done") was supposed to just add an additional parameter to
> map_mem_in_cams() and always set it to 'true' at that time.
>
> But a few call sites were messed up. Fix them.
>
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/book3e: Fix TLBCAM preset at boot
https://git.kernel.org/powerpc/c/5b54860943dc4681be5de2fc287408c7ce274dfc
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/signal32: Fix sigset_t copy
From: Michael Ellerman @ 2021-11-17 11:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Christophe Leroy
Cc: Finn Thain, Stan Johnson, linux-kernel, stable,
Christopher M . Riedl, linuxppc-dev
In-Reply-To: <99ef38d61c0eb3f79c68942deb0c35995a93a777.1636966353.git.christophe.leroy@csgroup.eu>
On Mon, 15 Nov 2021 09:52:55 +0100, Christophe Leroy wrote:
> The conversion from __copy_from_user() to __get_user() by
> commit d3ccc9781560 ("powerpc/signal: Use __get_user() to copy
> sigset_t") introduced a regression in __get_user_sigset() for
> powerpc/32. The bug was subsequently moved into
> unsafe_get_user_sigset().
>
> The bug is due to the copied 64 bit value being truncated to
> 32 bits while being assigned to dst->sig[0]
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/signal32: Fix sigset_t copy
https://git.kernel.org/powerpc/c/5499802b2284331788a440585869590f1bd63f7f
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: clean vdso32 and vdso64 directories
From: Michael Ellerman @ 2021-11-17 11:23 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev, Benjamin Herrenschmidt,
Masahiro Yamada, Paul Mackerras
Cc: Aneesh Kumar K.V, Nicholas Piggin, linux-kernel, Ard Biesheuvel
In-Reply-To: <20211109185015.615517-1-masahiroy@kernel.org>
On Wed, 10 Nov 2021 03:50:15 +0900, Masahiro Yamada wrote:
> Since commit bce74491c300 ("powerpc/vdso: fix unnecessary rebuilds of
> vgettimeofday.o"), "make ARCH=powerpc clean" does not clean up the
> arch/powerpc/kernel/{vdso32,vdso64} directories.
>
> Use the subdir- trick to let "make clean" descend into them.
>
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc: clean vdso32 and vdso64 directories
https://git.kernel.org/powerpc/c/964c33cd0be621b291b5d253d8731eb2680082cb
cheers
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S HV: Use GLOBAL_TOC for kvmppc_h_set_dabr/xdabr()
From: Michael Ellerman @ 2021-11-17 11:23 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: mikey, npiggin
In-Reply-To: <20210923151031.72408-1-mpe@ellerman.id.au>
On Fri, 24 Sep 2021 01:10:31 +1000, Michael Ellerman wrote:
> kvmppc_h_set_dabr(), and kvmppc_h_set_xdabr() which jumps into
> it, need to use _GLOBAL_TOC to setup the kernel TOC pointer, because
> kvmppc_h_set_dabr() uses LOAD_REG_ADDR() to load dawr_force_enable.
>
> When called from hcall_try_real_mode() we have the kernel TOC in r2,
> established near the start of kvmppc_interrupt_hv(), so there is no
> issue.
>
> [...]
Applied to powerpc/fixes.
[1/1] KVM: PPC: Book3S HV: Use GLOBAL_TOC for kvmppc_h_set_dabr/xdabr()
https://git.kernel.org/powerpc/c/dae581864609d36fb58855fd59880b4941ce9d14
cheers
^ permalink raw reply
* Re: [PATCH v2 1/2] powerpc/pseries: rename numa_dist_table to form2_distances
From: Michael Ellerman @ 2021-11-17 11:23 UTC (permalink / raw)
To: linuxppc-dev, Nicholas Piggin; +Cc: Aneesh Kumar K . V
In-Reply-To: <20211109064900.2041386-1-npiggin@gmail.com>
On Tue, 9 Nov 2021 16:48:59 +1000, Nicholas Piggin wrote:
> The name of the local variable holding the "form2" property address
> conflicts with the numa_distance_table global.
>
> This patch does 's/numa_dist_table/form2_distances/g' over the function,
> which also renames numa_dist_table_length to form2_distances_length.
>
>
> [...]
Applied to powerpc/fixes.
[1/2] powerpc/pseries: rename numa_dist_table to form2_distances
https://git.kernel.org/powerpc/c/0bd81274e3f1195ee7c820ef02d62f31077c42c3
[2/2] powerpc/pseries: Fix numa FORM2 parsing fallback code
https://git.kernel.org/powerpc/c/302039466f6a3b9421ecb9a6a2c528801dc24a86
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/83xx/mpc8349emitx: Drop unused variable
From: Michael Ellerman @ 2021-11-17 11:23 UTC (permalink / raw)
To: Michael Ellerman, Scott Wood, Uwe Kleine-König
Cc: Anders Roxell, Naresh Kamboju, Paul Mackerras, kernel,
Linux Kernel Functional Testing, linuxppc-dev
In-Reply-To: <20211110110739.1072634-1-u.kleine-koenig@pengutronix.de>
On Wed, 10 Nov 2021 12:07:39 +0100, Uwe Kleine-König wrote:
> Commit 5d354dc35ebb ("powerpc/83xx/mpc8349emitx: Make
> mcu_gpiochip_remove() return void") removed the usage of the variable
> ret, but failed to remove the variable itself, resulting in:
>
> arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c: In function ‘mcu_remove’:
> arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c:189:6: error: unused variable ‘ret’ [-Werror=unused-variable]
> 189 | int ret;
> | ^~~
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/83xx/mpc8349emitx: Drop unused variable
https://git.kernel.org/powerpc/c/2da516d7ed0865bf9835830907f2f6631006d628
cheers
^ permalink raw reply
* powerpc: pervasive.c:: error: unannotated fall-through between switch labels
From: Naresh Kamboju @ 2021-11-17 12:53 UTC (permalink / raw)
To: linuxppc-dev, open list, Linux-Next Mailing List
Cc: Stephen Rothwell, Arnd Bergmann, lkft-triage, Paul Mackerras
Regression found on ppc clang-nightly build.
Following build warnings / errors reported on linux next 20211117.
metadata:
git_describe: next-20211117
git_repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next
git_short_log: fd96a4057bd0 (\"Add linux-next specific files for 20211117\")
target_arch: ppc
toolchain: clang-nightly
build error :
--------------
<stdin>:1559:2: warning: syscall futex_waitv not implemented [-W#warnings]
#warning syscall futex_waitv not implemented
^
1 warning generated.
arch/powerpc/platforms/cell/pervasive.c:81:2: error: unannotated
fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case SRR1_WAKEEE:
^
arch/powerpc/platforms/cell/pervasive.c:81:2: note: insert 'break;' to
avoid fall-through
case SRR1_WAKEEE:
^
break;
1 error generated.
Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
build link:
-----------
https://builds.tuxbuild.com/211sfsuxt3flikHFzRts8cFUwqe/build.log
build config:
-------------
https://builds.tuxbuild.com/211sfsuxt3flikHFzRts8cFUwqe/config
# To install tuxmake on your system globally
# sudo pip3 install -U tuxmake
tuxmake --runtime podman --target-arch powerpc --toolchain
clang-nightly --kconfig defconfig LLVM_IAS=0
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply
* Re: [PATCH kernel 0/4] Fixes for powerpc/pseries/iommu: Make use of DDW for indirect mapping
From: Michael Ellerman @ 2021-11-17 13:01 UTC (permalink / raw)
To: Frederic Barrat, Michael Ellerman, Alexey Kardashevskiy,
linuxppc-dev
Cc: Leonardo Bras, Brian King
In-Reply-To: <98447986-ecef-13eb-1fd3-a635cb75fba7@linux.ibm.com>
Frederic Barrat <fbarrat@linux.ibm.com> writes:
> On 02/11/2021 03:43, Michael Ellerman wrote:
>> On Thu, 21 Oct 2021 00:23:11 +1100, Alexey Kardashevskiy wrote:
>>> Found some issues on SRIOV enabled PHYP.
>>> It probably should be one patch, or not?
>>>
>>> Please comment. Thanks.
>>>
>>> [...]
>>
>> Patches 2-4 applied to powerpc/fixes.
>
>
> Any reason why patch 1 was not applied? The indents are still wrong in
> 5.16-rc1
Just because it was late in the rc series, and it wasn't crucial that
the whitespace fix go into 5.15.
And yeah Alexey has now reposted it and I have picked that series up.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: delete scanlog
From: Nathan Lynch @ 2021-11-17 14:47 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: tyreld
In-Reply-To: <877dd7m5jd.fsf@mpe.ellerman.id.au>
Michael Ellerman <mpe@ellerman.id.au> writes:
> Nathan Lynch <nathanl@linux.ibm.com> writes:
>> Nathan Lynch <nathanl@linux.ibm.com> writes:
>>> Remove the pseries scanlog driver.
>>>
>>> This code supports functions from Power4-era servers that are not present
>>> on targets currently supported by arch/powerpc. System manuals from this
>>> time have this description:
>>>
>>> Scan Dump data is a set of chip data that the service processor gathers
>>> after a system malfunction. It consists of chip scan rings, chip trace
>>> arrays, and Scan COM (SCOM) registers. This data is stored in the
>>> scan-log partition of the system’s Nonvolatile Random Access
>>> Memory (NVRAM).
>>>
>>> PowerVM partition firmware development doesn't recognize the associated
>>> function call or property, and they don't see any references to them in
>>> their codebase. It seems to have been specific to non-virtualized
>>> pseries.
>>
>> Just bumping this to see if there are any objections.
>
> Not an objection, I like nothing better than dropping old unused cruft,
> but are we sure it's safe to remove the proc file?
>
> I see that rtas_errd still looks for it, have you checked that it will
> handle the absence of the file gracefully and continue doing whatever
> else it does?
Uhh. I will stop forgetting to check ppc64_diag when making such
changes. Thanks for pointing this out.
> On further inspection it looks like the code that looks for it in
> rtas_errd is #if 0'ed out (??), so maybe it's dead.
Yes it seems so. From rtas_errd's main():
#if 0
/*
* Check to see if a new scanlog dump is available; if so, copy it to
* the filesystem and associate the dump with the first error processed.
*/
check_scanlog_dump();
#endif
And that's the only entry point into the code that collects the scanlog
data. And that dead code appears to deal with the absence of
/proc/ppc64/scan-log-dump gracefully. It has been like that since
initial git import in 2013.
> Anyway if you can test that rtas_errd still works that'd be good.
I've verified that it starts normally and logs EPOW events associated
with partition migration.
> Presumably there's no other code that cares about the proc file.
AFAIK this is right. powerpc-utils and librtas do not use it. librtas
has a wrapper for the calling the associated RTAS function directly, but
that's fine.
I tried using GitHub's search to find instances of "scan-log-dump" that
weren't from Linux or ppc64_diag (need to be logged in I think):
https://github.com/search?q=%22scan-log-dump%22+-path%3Aarch%2Fpowerpc+-filename%3Ascanlog.c+-extension%3Apatch&type=Code&ref=advsearch&l=&l=
This hasn't yielded any unexpected users. There may be better search
terms but that's what a few minutes of fiddling with it got me.
^ permalink raw reply
* Re: [PATCH] powerpc: clean vdso32 and vdso64 directories
From: Masahiro Yamada @ 2021-11-17 14:58 UTC (permalink / raw)
To: Christophe Leroy
Cc: Linux Kernel Mailing List, Nicholas Piggin, Paul Mackerras,
Aneesh Kumar K.V, linuxppc-dev, Ard Biesheuvel
In-Reply-To: <0cdd39b2-73f8-e0c1-bfa2-7940d4b788f0@csgroup.eu>
On Wed, Nov 17, 2021 at 12:38 AM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
>
> Hi Masahiro,
>
> Le 09/11/2021 à 19:50, Masahiro Yamada a écrit :
> > Since commit bce74491c300 ("powerpc/vdso: fix unnecessary rebuilds of
> > vgettimeofday.o"), "make ARCH=powerpc clean" does not clean up the
> > arch/powerpc/kernel/{vdso32,vdso64} directories.
> >
> > Use the subdir- trick to let "make clean" descend into them.
> >
> > Fixes: bce74491c300 ("powerpc/vdso: fix unnecessary rebuilds of vgettimeofday.o")
> > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> > ---
> >
> > arch/powerpc/kernel/Makefile | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> > index 0e3640e14eb1..5fa68c2ef1f8 100644
> > --- a/arch/powerpc/kernel/Makefile
> > +++ b/arch/powerpc/kernel/Makefile
> > @@ -196,3 +196,6 @@ clean-files := vmlinux.lds
> > # Force dependency (incbin is bad)
> > $(obj)/vdso32_wrapper.o : $(obj)/vdso32/vdso32.so.dbg
> > $(obj)/vdso64_wrapper.o : $(obj)/vdso64/vdso64.so.dbg
> > +
> > +# for cleaning
> > +subdir- += vdso32 vdso64
> >
>
> This patch make me think about one thing I would have liked to do, but I
> don't know Makefiles well enough to be able to do it. You could probably
> help me with it.
>
> vdso32 and vdso64 contain a lot of redundant sources. I would like to
> merge them into a new single directory, let say 'vdso', and use the
> files in that directory to build both vdso32.so and vdso64.so. I have a
> feeling that x86 is doing it that way, but I've not been able to figure
> out how to build two objects using the same C/S files.
>
> Thanks
> Christophe
Changing the code as follows might work.
$(obj-vdso32): %-32.o: %.S FORCE
$(call if_changed_dep,vdso32as)
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH v3 10/12] KVM: x86/xen: Maintain valid mapping of Xen shared_info page
From: David Woodhouse @ 2021-11-17 17:40 UTC (permalink / raw)
To: Paolo Bonzini, kvm
Cc: Anup Patel, wanpengli @ tencent . com, Catalin Marinas,
Joao Martins, Will Deacon, kvmarm, linux-s390,
joro @ 8bytes . org, Huacai Chen, Christian Borntraeger,
Aleksandar Markovic, karahmed, Suzuki K Poulose, Boris Ostrovsky,
Alexandru Elisei, linux-arm-kernel, jmattson @ google . com,
seanjc @ google . com, mtosatti @ redhat . com, linux-mips,
James Morse, kvm-riscv, Marc Zyngier, vkuznets @ redhat . com,
linuxppc-dev
In-Reply-To: <20211117174003.297096-1-dwmw2@infradead.org>
From: David Woodhouse <dwmw@amazon.co.uk>
Use the newly reinstated gfn_to_pfn_cache to maintain a kernel mapping
of the Xen shared_info page so that it can be accessed in atomic context.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
arch/x86/include/asm/kvm_host.h | 2 +-
arch/x86/kvm/xen.c | 25 ++++++++++++++-----------
2 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 6ac61f85e07b..4b2b4ecf3b46 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1014,7 +1014,7 @@ struct msr_bitmap_range {
struct kvm_xen {
bool long_mode;
u8 upcall_vector;
- gfn_t shinfo_gfn;
+ struct gfn_to_pfn_cache shinfo_cache;
};
enum kvm_irqchip_mode {
diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c
index dff2bdf9507a..32a915a4fe20 100644
--- a/arch/x86/kvm/xen.c
+++ b/arch/x86/kvm/xen.c
@@ -23,16 +23,21 @@ DEFINE_STATIC_KEY_DEFERRED_FALSE(kvm_xen_enabled, HZ);
static int kvm_xen_shared_info_init(struct kvm *kvm, gfn_t gfn)
{
+ struct gfn_to_pfn_cache *gpc = &kvm->arch.xen.shinfo_cache;
gpa_t gpa = gfn_to_gpa(gfn);
int wc_ofs, sec_hi_ofs;
int ret = 0;
int idx = srcu_read_lock(&kvm->srcu);
- if (kvm_is_error_hva(gfn_to_hva(kvm, gfn))) {
- ret = -EFAULT;
+ if (gfn == GPA_INVALID) {
+ kvm_gfn_to_pfn_cache_destroy(kvm, gpc);
goto out;
}
- kvm->arch.xen.shinfo_gfn = gfn;
+
+ ret = kvm_gfn_to_pfn_cache_init(kvm, gpc, NULL, false, true, gpa,
+ PAGE_SIZE, true);
+ if (ret)
+ goto out;
/* Paranoia checks on the 32-bit struct layout */
BUILD_BUG_ON(offsetof(struct compat_shared_info, wc) != 0x900);
@@ -260,15 +265,9 @@ int kvm_xen_hvm_set_attr(struct kvm *kvm, struct kvm_xen_hvm_attr *data)
break;
case KVM_XEN_ATTR_TYPE_SHARED_INFO:
- if (data->u.shared_info.gfn == GPA_INVALID) {
- kvm->arch.xen.shinfo_gfn = GPA_INVALID;
- r = 0;
- break;
- }
r = kvm_xen_shared_info_init(kvm, data->u.shared_info.gfn);
break;
-
case KVM_XEN_ATTR_TYPE_UPCALL_VECTOR:
if (data->u.vector && data->u.vector < 0x10)
r = -EINVAL;
@@ -299,7 +298,10 @@ int kvm_xen_hvm_get_attr(struct kvm *kvm, struct kvm_xen_hvm_attr *data)
break;
case KVM_XEN_ATTR_TYPE_SHARED_INFO:
- data->u.shared_info.gfn = kvm->arch.xen.shinfo_gfn;
+ if (kvm->arch.xen.shinfo_cache.active)
+ data->u.shared_info.gfn = gpa_to_gfn(kvm->arch.xen.shinfo_cache.gpa);
+ else
+ data->u.shared_info.gfn = GPA_INVALID;
r = 0;
break;
@@ -661,11 +663,12 @@ int kvm_xen_hvm_config(struct kvm *kvm, struct kvm_xen_hvm_config *xhc)
void kvm_xen_init_vm(struct kvm *kvm)
{
- kvm->arch.xen.shinfo_gfn = GPA_INVALID;
}
void kvm_xen_destroy_vm(struct kvm *kvm)
{
+ kvm_gfn_to_pfn_cache_destroy(kvm, &kvm->arch.xen.shinfo_cache);
+
if (kvm->arch.xen_hvm_config.msr)
static_branch_slow_dec_deferred(&kvm_xen_enabled);
}
--
2.31.1
^ permalink raw reply related
* [PATCH v3 01/12] KVM: Introduce CONFIG_HAVE_KVM_DIRTY_RING
From: David Woodhouse @ 2021-11-17 17:39 UTC (permalink / raw)
To: Paolo Bonzini, kvm
Cc: Anup Patel, wanpengli @ tencent . com, Catalin Marinas,
Joao Martins, Will Deacon, kvmarm, linux-s390,
joro @ 8bytes . org, Huacai Chen, Christian Borntraeger,
Aleksandar Markovic, karahmed, Suzuki K Poulose, Boris Ostrovsky,
Alexandru Elisei, linux-arm-kernel, jmattson @ google . com,
seanjc @ google . com, mtosatti @ redhat . com, linux-mips,
James Morse, kvm-riscv, Marc Zyngier, vkuznets @ redhat . com,
linuxppc-dev
In-Reply-To: <20211117174003.297096-1-dwmw2@infradead.org>
From: David Woodhouse <dwmw@amazon.co.uk>
I'd like to make the build include dirty_ring.c based on whether the
arch wants it or not. That's a whole lot simpler if there's a config
symbol instead of doing it implicitly on KVM_DIRTY_LOG_PAGE_OFFSET
being set to something non-zero.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
arch/x86/kvm/Kconfig | 1 +
include/linux/kvm_dirty_ring.h | 8 ++++----
virt/kvm/Kconfig | 3 +++
virt/kvm/kvm_main.c | 4 ++--
4 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
index 619186138176..d7fa0a42ac25 100644
--- a/arch/x86/kvm/Kconfig
+++ b/arch/x86/kvm/Kconfig
@@ -27,6 +27,7 @@ config KVM
select MMU_NOTIFIER
select HAVE_KVM_IRQCHIP
select HAVE_KVM_IRQFD
+ select HAVE_KVM_DIRTY_RING
select IRQ_BYPASS_MANAGER
select HAVE_KVM_IRQ_BYPASS
select HAVE_KVM_IRQ_ROUTING
diff --git a/include/linux/kvm_dirty_ring.h b/include/linux/kvm_dirty_ring.h
index 120e5e90fa1d..4da8d4a4140b 100644
--- a/include/linux/kvm_dirty_ring.h
+++ b/include/linux/kvm_dirty_ring.h
@@ -27,9 +27,9 @@ struct kvm_dirty_ring {
int index;
};
-#if (KVM_DIRTY_LOG_PAGE_OFFSET == 0)
+#ifndef CONFIG_HAVE_KVM_DIRTY_RING
/*
- * If KVM_DIRTY_LOG_PAGE_OFFSET not defined, kvm_dirty_ring.o should
+ * If CONFIG_HAVE_HVM_DIRTY_RING not defined, kvm_dirty_ring.o should
* not be included as well, so define these nop functions for the arch.
*/
static inline u32 kvm_dirty_ring_get_rsvd_entries(void)
@@ -74,7 +74,7 @@ static inline bool kvm_dirty_ring_soft_full(struct kvm_dirty_ring *ring)
return true;
}
-#else /* KVM_DIRTY_LOG_PAGE_OFFSET == 0 */
+#else /* CONFIG_HAVE_KVM_DIRTY_RING */
u32 kvm_dirty_ring_get_rsvd_entries(void);
int kvm_dirty_ring_alloc(struct kvm_dirty_ring *ring, int index, u32 size);
@@ -98,6 +98,6 @@ struct page *kvm_dirty_ring_get_page(struct kvm_dirty_ring *ring, u32 offset);
void kvm_dirty_ring_free(struct kvm_dirty_ring *ring);
bool kvm_dirty_ring_soft_full(struct kvm_dirty_ring *ring);
-#endif /* KVM_DIRTY_LOG_PAGE_OFFSET == 0 */
+#endif /* CONFIG_HAVE_KVM_DIRTY_RING */
#endif /* KVM_DIRTY_RING_H */
diff --git a/virt/kvm/Kconfig b/virt/kvm/Kconfig
index 62b39149b8c8..97cf5413ac25 100644
--- a/virt/kvm/Kconfig
+++ b/virt/kvm/Kconfig
@@ -13,6 +13,9 @@ config HAVE_KVM_IRQFD
config HAVE_KVM_IRQ_ROUTING
bool
+config HAVE_KVM_DIRTY_RING
+ bool
+
config HAVE_KVM_EVENTFD
bool
select EVENTFD
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 9646bb9112c1..356d636e037d 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -3411,7 +3411,7 @@ EXPORT_SYMBOL_GPL(kvm_vcpu_on_spin);
static bool kvm_page_in_dirty_ring(struct kvm *kvm, unsigned long pgoff)
{
-#if KVM_DIRTY_LOG_PAGE_OFFSET > 0
+#ifdef CONFIG_HAVE_KVM_DIRTY_RING
return (pgoff >= KVM_DIRTY_LOG_PAGE_OFFSET) &&
(pgoff < KVM_DIRTY_LOG_PAGE_OFFSET +
kvm->dirty_ring_size / PAGE_SIZE);
@@ -4114,7 +4114,7 @@ static long kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg)
case KVM_CAP_NR_MEMSLOTS:
return KVM_USER_MEM_SLOTS;
case KVM_CAP_DIRTY_LOG_RING:
-#if KVM_DIRTY_LOG_PAGE_OFFSET > 0
+#ifdef KVM_HAVE_KVM_DIRTY_RING
return KVM_DIRTY_RING_MAX_ENTRIES * sizeof(struct kvm_dirty_gfn);
#else
return 0;
--
2.31.1
^ permalink raw reply related
* [PATCH v3 05/12] KVM: RISC-V: Use Makefile.kvm for common files
From: David Woodhouse @ 2021-11-17 17:39 UTC (permalink / raw)
To: Paolo Bonzini, kvm
Cc: Anup Patel, wanpengli @ tencent . com, Catalin Marinas,
Joao Martins, Will Deacon, kvmarm, linux-s390,
joro @ 8bytes . org, Huacai Chen, Christian Borntraeger,
Aleksandar Markovic, karahmed, Suzuki K Poulose, Boris Ostrovsky,
Alexandru Elisei, linux-arm-kernel, jmattson @ google . com,
seanjc @ google . com, mtosatti @ redhat . com, linux-mips,
James Morse, kvm-riscv, Marc Zyngier, vkuznets @ redhat . com,
linuxppc-dev
In-Reply-To: <20211117174003.297096-1-dwmw2@infradead.org>
From: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
arch/riscv/kvm/Makefile | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/riscv/kvm/Makefile b/arch/riscv/kvm/Makefile
index 30cdd1df0098..300590225348 100644
--- a/arch/riscv/kvm/Makefile
+++ b/arch/riscv/kvm/Makefile
@@ -5,14 +5,10 @@
ccflags-y += -I $(srctree)/$(src)
-KVM := ../../../virt/kvm
+include $(srctree)/virt/kvm/Makefile.kvm
obj-$(CONFIG_KVM) += kvm.o
-kvm-y += $(KVM)/kvm_main.o
-kvm-y += $(KVM)/coalesced_mmio.o
-kvm-y += $(KVM)/binary_stats.o
-kvm-y += $(KVM)/eventfd.o
kvm-y += main.o
kvm-y += vm.o
kvm-y += vmid.o
--
2.31.1
^ permalink raw reply related
* [PATCH v3 12/12] KVM: x86: First attempt at converting nested virtual APIC page to gpc
From: David Woodhouse @ 2021-11-17 17:40 UTC (permalink / raw)
To: Paolo Bonzini, kvm
Cc: Anup Patel, wanpengli @ tencent . com, Catalin Marinas,
Joao Martins, Will Deacon, kvmarm, linux-s390,
joro @ 8bytes . org, Huacai Chen, Christian Borntraeger,
Aleksandar Markovic, karahmed, Suzuki K Poulose, Boris Ostrovsky,
Alexandru Elisei, linux-arm-kernel, jmattson @ google . com,
seanjc @ google . com, mtosatti @ redhat . com, linux-mips,
James Morse, kvm-riscv, Marc Zyngier, vkuznets @ redhat . com,
linuxppc-dev
In-Reply-To: <20211117174003.297096-1-dwmw2@infradead.org>
From: David Woodhouse <dwmw@amazon.co.uk>
This is what evolved during the discussion at
https://lore.kernel.org/kvm/960E233F-EC0B-4FB5-BA2E-C8D2CCB38B12@infradead.org/T/#m11d75fcfe2da357ec1dabba0d0e3abb91fd13665
As discussed, an alternative approach might be to augment
kvm_arch_memslots_updated() to raise KVM_REQ_GET_NESTED_STATE_PAGES to
each vCPU (and make that req only do anything on a given vCPU if that
vCPU is actually in L2 guest mode).
That would mean the reload gets actively triggered even on memslot
changes rather than only on MMU notifiers as is the case now. It could
*potentially* mean we can drop the new 'check_guest_maps' function.
The 'check_guest_maps' function could be a lot simpler than it is,
though. It only really needs to get kvm->memslots->generation, then
check each gpc->generation against that, and each gpc->valid.
Also I suspect we *shouldn't* destroy the virtual_apic_cache in
nested_vmx_vmexit(). We can just leave it there for next time the
vCPU enters guest mode. If it happens to get invalidated in the
meantime, that's fine and we'll refresh it on the way back in.
We probably *would* want to actively do something on memslot changes
in that case though, to ensure that even if the vCPU isn't in guest
mode any more, we *release* the cached page.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/vmx/nested.c | 50 ++++++++++++++++++++++++++++-----
arch/x86/kvm/vmx/vmx.c | 12 +++++---
arch/x86/kvm/vmx/vmx.h | 2 +-
arch/x86/kvm/x86.c | 10 +++++++
5 files changed, 63 insertions(+), 12 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 6ea2446ab851..24f6f3e2de47 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1511,6 +1511,7 @@ struct kvm_x86_nested_ops {
int (*enable_evmcs)(struct kvm_vcpu *vcpu,
uint16_t *vmcs_version);
uint16_t (*get_evmcs_version)(struct kvm_vcpu *vcpu);
+ void (*check_guest_maps)(struct kvm_vcpu *vcpu);
};
struct kvm_x86_init_ops {
diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index 1e2f66951566..794aa6021188 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -309,7 +309,7 @@ static void free_nested(struct kvm_vcpu *vcpu)
kvm_release_page_clean(vmx->nested.apic_access_page);
vmx->nested.apic_access_page = NULL;
}
- kvm_vcpu_unmap(vcpu, &vmx->nested.virtual_apic_map, true);
+ kvm_gfn_to_pfn_cache_destroy(vcpu->kvm, &vmx->nested.virtual_apic_cache);
kvm_vcpu_unmap(vcpu, &vmx->nested.pi_desc_map, true);
vmx->nested.pi_desc = NULL;
@@ -3179,10 +3179,12 @@ static bool nested_get_vmcs12_pages(struct kvm_vcpu *vcpu)
}
if (nested_cpu_has(vmcs12, CPU_BASED_TPR_SHADOW)) {
- map = &vmx->nested.virtual_apic_map;
+ struct gfn_to_pfn_cache *gpc = &vmx->nested.virtual_apic_cache;
- if (!kvm_vcpu_map(vcpu, gpa_to_gfn(vmcs12->virtual_apic_page_addr), map)) {
- vmcs_write64(VIRTUAL_APIC_PAGE_ADDR, pfn_to_hpa(map->pfn));
+ if (!kvm_gfn_to_pfn_cache_init(vcpu->kvm, gpc, vcpu, true, true,
+ vmcs12->virtual_apic_page_addr,
+ PAGE_SIZE, true)) {
+ vmcs_write64(VIRTUAL_APIC_PAGE_ADDR, pfn_to_hpa(gpc->pfn));
} else if (nested_cpu_has(vmcs12, CPU_BASED_CR8_LOAD_EXITING) &&
nested_cpu_has(vmcs12, CPU_BASED_CR8_STORE_EXITING) &&
!nested_cpu_has2(vmcs12, SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES)) {
@@ -3207,6 +3209,9 @@ static bool nested_get_vmcs12_pages(struct kvm_vcpu *vcpu)
if (nested_cpu_has_posted_intr(vmcs12)) {
map = &vmx->nested.pi_desc_map;
+ if (kvm_vcpu_mapped(map))
+ kvm_vcpu_unmap(vcpu, map, true);
+
if (!kvm_vcpu_map(vcpu, gpa_to_gfn(vmcs12->posted_intr_desc_addr), map)) {
vmx->nested.pi_desc =
(struct pi_desc *)(((void *)map->hva) +
@@ -3251,6 +3256,29 @@ static bool vmx_get_nested_state_pages(struct kvm_vcpu *vcpu)
return true;
}
+static void nested_vmx_check_guest_maps(struct kvm_vcpu *vcpu)
+{
+ struct vmcs12 *vmcs12 = get_vmcs12(vcpu);
+ struct vcpu_vmx *vmx = to_vmx(vcpu);
+ struct gfn_to_pfn_cache *gpc;
+
+ int valid;
+
+ if (nested_cpu_has_posted_intr(vmcs12)) {
+ gpc = &vmx->nested.virtual_apic_cache;
+
+ read_lock(&gpc->lock);
+ valid = kvm_gfn_to_pfn_cache_check(vcpu->kvm, gpc,
+ vmcs12->virtual_apic_page_addr,
+ PAGE_SIZE);
+ read_unlock(&gpc->lock);
+ if (!valid) {
+ kvm_make_request(KVM_REQ_GET_NESTED_STATE_PAGES, vcpu);
+ return;
+ }
+ }
+}
+
static int nested_vmx_write_pml_buffer(struct kvm_vcpu *vcpu, gpa_t gpa)
{
struct vmcs12 *vmcs12;
@@ -3749,9 +3777,15 @@ static int vmx_complete_nested_posted_interrupt(struct kvm_vcpu *vcpu)
max_irr = find_last_bit((unsigned long *)vmx->nested.pi_desc->pir, 256);
if (max_irr != 256) {
- vapic_page = vmx->nested.virtual_apic_map.hva;
- if (!vapic_page)
+ struct gfn_to_pfn_cache *gpc = &vmx->nested.virtual_apic_cache;
+
+ read_lock(&gpc->lock);
+ if (!kvm_gfn_to_pfn_cache_check(vcpu->kvm, gpc, gpc->gpa, PAGE_SIZE)) {
+ read_unlock(&gpc->lock);
goto mmio_needed;
+ }
+
+ vapic_page = gpc->khva;
__kvm_apic_update_irr(vmx->nested.pi_desc->pir,
vapic_page, &max_irr);
@@ -3761,6 +3795,7 @@ static int vmx_complete_nested_posted_interrupt(struct kvm_vcpu *vcpu)
status |= (u8)max_irr;
vmcs_write16(GUEST_INTR_STATUS, status);
}
+ read_unlock(&gpc->lock);
}
nested_mark_vmcs12_pages_dirty(vcpu);
@@ -4581,7 +4616,7 @@ void nested_vmx_vmexit(struct kvm_vcpu *vcpu, u32 vm_exit_reason,
kvm_release_page_clean(vmx->nested.apic_access_page);
vmx->nested.apic_access_page = NULL;
}
- kvm_vcpu_unmap(vcpu, &vmx->nested.virtual_apic_map, true);
+ kvm_gfn_to_pfn_cache_destroy(vcpu->kvm, &vmx->nested.virtual_apic_cache);
kvm_vcpu_unmap(vcpu, &vmx->nested.pi_desc_map, true);
vmx->nested.pi_desc = NULL;
@@ -6756,4 +6791,5 @@ struct kvm_x86_nested_ops vmx_nested_ops = {
.write_log_dirty = nested_vmx_write_pml_buffer,
.enable_evmcs = nested_enable_evmcs,
.get_evmcs_version = nested_get_evmcs_version,
+ .check_guest_maps = nested_vmx_check_guest_maps,
};
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index ba66c171d951..6c61faef86d3 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -3839,19 +3839,23 @@ void pt_update_intercept_for_msr(struct kvm_vcpu *vcpu)
static bool vmx_guest_apic_has_interrupt(struct kvm_vcpu *vcpu)
{
struct vcpu_vmx *vmx = to_vmx(vcpu);
- void *vapic_page;
+ struct gfn_to_pfn_cache *gpc = &vmx->nested.virtual_apic_cache;
u32 vppr;
int rvi;
if (WARN_ON_ONCE(!is_guest_mode(vcpu)) ||
!nested_cpu_has_vid(get_vmcs12(vcpu)) ||
- WARN_ON_ONCE(!vmx->nested.virtual_apic_map.gfn))
+ WARN_ON_ONCE(gpc->gpa == GPA_INVALID))
return false;
rvi = vmx_get_rvi();
- vapic_page = vmx->nested.virtual_apic_map.hva;
- vppr = *((u32 *)(vapic_page + APIC_PROCPRI));
+ read_lock(&gpc->lock);
+ if (!kvm_gfn_to_pfn_cache_check(vcpu->kvm, gpc, gpc->gpa, PAGE_SIZE))
+ vppr = *((u32 *)(gpc->khva + APIC_PROCPRI));
+ else
+ vppr = 0xff;
+ read_unlock(&gpc->lock);
return ((rvi & 0xf0) > (vppr & 0xf0));
}
diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h
index 4df2ac24ffc1..8364e7fc92a0 100644
--- a/arch/x86/kvm/vmx/vmx.h
+++ b/arch/x86/kvm/vmx/vmx.h
@@ -195,7 +195,7 @@ struct nested_vmx {
* pointers, so we must keep them pinned while L2 runs.
*/
struct page *apic_access_page;
- struct kvm_host_map virtual_apic_map;
+ struct gfn_to_pfn_cache virtual_apic_cache;
struct kvm_host_map pi_desc_map;
struct kvm_host_map msr_bitmap_map;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 6f7669c94c79..caf35aa85ae3 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -9739,6 +9739,8 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
if (kvm_check_request(KVM_REQ_UPDATE_CPU_DIRTY_LOGGING, vcpu))
static_call(kvm_x86_update_cpu_dirty_logging)(vcpu);
+ if (kvm_check_request(KVM_REQ_GPC_INVALIDATE, vcpu))
+ ; /* Nothing to do. It just wanted to wake us */
}
if (kvm_check_request(KVM_REQ_EVENT, vcpu) || req_int_win ||
@@ -9785,6 +9787,14 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
local_irq_disable();
vcpu->mode = IN_GUEST_MODE;
+ /*
+ * If the guest requires direct access to mapped L1 pages, check
+ * the caches are valid. Will raise KVM_REQ_GET_NESTED_STATE_PAGES
+ * to go and revalidate them, if necessary.
+ */
+ if (is_guest_mode(vcpu) && kvm_x86_ops.nested_ops->check_guest_maps)
+ kvm_x86_ops.nested_ops->check_guest_maps(vcpu);
+
srcu_read_unlock(&vcpu->kvm->srcu, vcpu->srcu_idx);
/*
--
2.31.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox