From: Robin Murphy <robin.murphy@arm.com> To: Bhupesh Sharma <bhsharma@redhat.com>, James Morse <james.morse@arm.com> Cc: Mark Rutland <mark.rutland@arm.com>, ard.biesheuvel@linaro.org, catalin.marinas@arm.com, kexec@lists.infradead.org, Will Deacon <will.deacon@arm.com>, AKASHI Takahiro <takahiro.akashi@linaro.org>, bhupesh.linux@gmail.com, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] arm64, vmcoreinfo : Append 'MAX_USER_VA_BITS' and 'MAX_PHYSMEM_BITS' to vmcoreinfo Date: Tue, 12 Feb 2019 10:49:55 +0000 [thread overview] Message-ID: <5256fbd8-6e96-0de7-c538-acbec6387c41@arm.com> (raw) In-Reply-To: <f4905b1c-c3f0-f5a1-193e-2997a0047b9c@redhat.com> On 12/02/2019 04:55, Bhupesh Sharma wrote: > Hi Robin, > > On 02/04/2019 09:01 PM, Robin Murphy wrote: >> On 04/02/2019 14:35, Bhupesh Sharma wrote: >> [...] >>>> Also hardcoding the PTE calculation to use the high address bit mask >>>> always will break the backward compatibility with older kernels >>>> (which don't support 52-bit address space extensions). >> >> No it won't. There's no difference between an old kernel, a new kernel >> on a CPU without ARMv8.2-LPA, or a new kernel on a CPU with >> ARMv8.2-LPA in a system which happens to have less than 49 bits of >> physical memory map - in all those cases the relevant bits are either >> RES0 or just actually 0 in the PTE, so replacing 4 bits of zeros with >> 4 bits of other zeros in the final physical address has no effect >> whatsoever other than taking a couple of extra instructions to perform. > > Right, but lets think this from a distribution user p-o-v. Why would a > user with newer kernel and CPU which doesn't support ARMv8.2 LPA want to > update a user-space utility? Well unless something is broken in the > user-space. Requesting an upgrade is easier in this case, as the > user-space components like crash-utility/kexec-tools (or for that matter > any user-space tool which requires a page-table walk to determine > vaddr/paddr values) are indeed broken with this combination. Huh? Nothing gets broken unless we go out of our way to break it. The point I'm making is that the format of vmcoreinfo *does not* need to change in order for the userspace tool to support LPA. There is no compatibility issue either way. If a user's machine doesn't support or make use of LPA, then yeah, they should absolutely not have to upgrade their tools for the sake of LPA regardless of what kernel they use. > On the other hand, if a user a having a old kernel, CPU which doesn't > support LPA, but if we still want them to upgrade to a newer version of > user-space utility (with a upgrade fix note reading something like: "Add > 52-bit PA support"), surely that would not be an ideal case requiring an > upgrade as his underlying environment doesn't support the same. I don't get why we would "still want them to upgrade" if there's no technical reason for them to do so. That sounds like the kind of crap that proprietary OS vendors pull :/ > That's what I meant when I said that we need to take care of the > backward compatibility also when we propose new code changes to > user-space packages. And what I meant is that you can trivially update the userspace tools to support LPA entirely transparently, without requiring kernel changes or creating any compatibility issues in any direction. Robin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com> To: Bhupesh Sharma <bhsharma@redhat.com>, James Morse <james.morse@arm.com> Cc: Mark Rutland <mark.rutland@arm.com>, ard.biesheuvel@linaro.org, catalin.marinas@arm.com, kexec@lists.infradead.org, Will Deacon <will.deacon@arm.com>, AKASHI Takahiro <takahiro.akashi@linaro.org>, bhupesh.linux@gmail.com, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] arm64, vmcoreinfo : Append 'MAX_USER_VA_BITS' and 'MAX_PHYSMEM_BITS' to vmcoreinfo Date: Tue, 12 Feb 2019 10:49:55 +0000 [thread overview] Message-ID: <5256fbd8-6e96-0de7-c538-acbec6387c41@arm.com> (raw) In-Reply-To: <f4905b1c-c3f0-f5a1-193e-2997a0047b9c@redhat.com> On 12/02/2019 04:55, Bhupesh Sharma wrote: > Hi Robin, > > On 02/04/2019 09:01 PM, Robin Murphy wrote: >> On 04/02/2019 14:35, Bhupesh Sharma wrote: >> [...] >>>> Also hardcoding the PTE calculation to use the high address bit mask >>>> always will break the backward compatibility with older kernels >>>> (which don't support 52-bit address space extensions). >> >> No it won't. There's no difference between an old kernel, a new kernel >> on a CPU without ARMv8.2-LPA, or a new kernel on a CPU with >> ARMv8.2-LPA in a system which happens to have less than 49 bits of >> physical memory map - in all those cases the relevant bits are either >> RES0 or just actually 0 in the PTE, so replacing 4 bits of zeros with >> 4 bits of other zeros in the final physical address has no effect >> whatsoever other than taking a couple of extra instructions to perform. > > Right, but lets think this from a distribution user p-o-v. Why would a > user with newer kernel and CPU which doesn't support ARMv8.2 LPA want to > update a user-space utility? Well unless something is broken in the > user-space. Requesting an upgrade is easier in this case, as the > user-space components like crash-utility/kexec-tools (or for that matter > any user-space tool which requires a page-table walk to determine > vaddr/paddr values) are indeed broken with this combination. Huh? Nothing gets broken unless we go out of our way to break it. The point I'm making is that the format of vmcoreinfo *does not* need to change in order for the userspace tool to support LPA. There is no compatibility issue either way. If a user's machine doesn't support or make use of LPA, then yeah, they should absolutely not have to upgrade their tools for the sake of LPA regardless of what kernel they use. > On the other hand, if a user a having a old kernel, CPU which doesn't > support LPA, but if we still want them to upgrade to a newer version of > user-space utility (with a upgrade fix note reading something like: "Add > 52-bit PA support"), surely that would not be an ideal case requiring an > upgrade as his underlying environment doesn't support the same. I don't get why we would "still want them to upgrade" if there's no technical reason for them to do so. That sounds like the kind of crap that proprietary OS vendors pull :/ > That's what I meant when I said that we need to take care of the > backward compatibility also when we propose new code changes to > user-space packages. And what I meant is that you can trivially update the userspace tools to support LPA entirely transparently, without requiring kernel changes or creating any compatibility issues in any direction. Robin. _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2019-02-12 10:50 UTC|newest] Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-01-30 12:23 [PATCH] arm64, vmcoreinfo : Append 'MAX_USER_VA_BITS' and 'MAX_PHYSMEM_BITS' to vmcoreinfo Bhupesh Sharma 2019-01-30 12:23 ` Bhupesh Sharma 2019-01-30 15:21 ` James Morse 2019-01-30 15:21 ` James Morse 2019-01-30 21:39 ` Bhupesh Sharma 2019-01-30 21:39 ` Bhupesh Sharma 2019-02-04 14:35 ` Bhupesh Sharma 2019-02-04 14:35 ` Bhupesh Sharma 2019-02-04 15:31 ` Robin Murphy 2019-02-04 15:31 ` Robin Murphy 2019-02-12 4:55 ` Bhupesh Sharma 2019-02-12 4:55 ` Bhupesh Sharma 2019-02-12 10:49 ` Robin Murphy [this message] 2019-02-12 10:49 ` Robin Murphy 2019-02-04 16:56 ` James Morse 2019-02-04 16:56 ` James Morse 2019-01-31 1:48 ` Dave Young 2019-01-31 1:48 ` Dave Young 2019-01-31 10:00 ` Bhupesh Sharma 2019-01-31 10:00 ` Bhupesh Sharma 2019-01-31 14:03 ` Dave Anderson 2019-01-31 14:03 ` Dave Anderson 2019-02-04 16:04 ` Kazuhito Hagio 2019-02-04 16:04 ` Kazuhito Hagio 2019-02-12 5:07 ` Bhupesh Sharma 2019-02-12 5:07 ` Bhupesh Sharma 2019-02-12 10:44 ` Dave Young 2019-02-12 10:44 ` Dave Young 2019-02-12 19:59 ` Bhupesh Sharma 2019-02-12 19:59 ` Bhupesh Sharma 2019-02-12 23:03 ` Kazuhito Hagio 2019-02-12 23:03 ` Kazuhito Hagio 2019-02-13 11:15 ` Dave Young 2019-02-13 11:15 ` Dave Young 2019-02-13 18:22 ` James Morse 2019-02-13 18:22 ` James Morse 2019-02-13 19:52 ` Kazuhito Hagio 2019-02-13 19:52 ` Kazuhito Hagio 2019-02-15 17:34 ` James Morse 2019-02-15 17:34 ` James Morse 2019-02-15 18:01 ` Bhupesh Sharma 2019-02-15 18:01 ` Bhupesh Sharma 2019-02-18 15:27 ` Steve Capper 2019-02-18 15:27 ` Steve Capper 2019-02-21 16:08 ` Bhupesh Sharma 2019-02-21 16:08 ` Bhupesh Sharma 2019-02-19 20:47 ` Kazuhito Hagio 2019-02-19 20:47 ` Kazuhito Hagio 2019-02-21 16:20 ` Bhupesh Sharma 2019-02-21 16:20 ` Bhupesh Sharma 2019-02-21 16:42 ` Dave Anderson 2019-02-21 16:42 ` Dave Anderson 2019-02-21 19:02 ` Kazuhito Hagio 2019-02-21 19:02 ` Kazuhito Hagio 2019-03-01 4:01 ` Bhupesh Sharma 2019-03-01 4:01 ` Bhupesh Sharma 2019-02-14 19:30 ` Bhupesh Sharma 2019-02-14 19:30 ` Bhupesh Sharma
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=5256fbd8-6e96-0de7-c538-acbec6387c41@arm.com \ --to=robin.murphy@arm.com \ --cc=ard.biesheuvel@linaro.org \ --cc=bhsharma@redhat.com \ --cc=bhupesh.linux@gmail.com \ --cc=catalin.marinas@arm.com \ --cc=james.morse@arm.com \ --cc=kexec@lists.infradead.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=mark.rutland@arm.com \ --cc=takahiro.akashi@linaro.org \ --cc=will.deacon@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.