Hi Kazu,
Sorry I had a lot of back-log to clear after I returned from my
holidays and just got to answering this now.
On Tue, Oct 29, 2019 at 2:23 AM Kazuhito Hagio <k-hagio@xxxxxxxxxxxxx> wrote:
>
> Hi Bhupesh,
>
> > -----Original Message-----
> > > > I am working on the changes in the vmcoreinfo after the 52-bit VA
> > > > changes from Steve were accepted in Linux 5.4-rc1 ("Support for 52-bit
> > > > virtual addressing in kernel space”).
> > >
> > >
> > > I don’t see a commit with this title in linux-stable ; Could you be a little more specific what
> > file that was applied to ?
> >
> > You can have a look at the following commit (and dependencies) in
> > Linus's tree (git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git)
> > which introduced 52-bit kernel VAs for arm64 architecture:
> >
> > commit b6d00d47e81a49f6cf462518c10408f37a3e6785
> > Author: Steve Capper <steve.capper@xxxxxxx>
> > Date: Wed Aug 7 16:55:22 2019 +0100
> >
> > arm64: mm: Introduce 52-bit Kernel VAs
>
> Thank you for working on this.
>
> I've also had a look at them, and my understanding is that we need
> in vmcoreinfo at least:
>
> - TCR_EL1.T1SZ (almost equals to vabits_actual) to determine:
> o PAGE_OFFSET
Indeed. There are several small little changes we need:
For now for ARMv8.2, we need to export TCR_EL1.T1SZ (which indicates
the vabits_actual). It will be useful for ARMv8.3
pointer-authentication stuff as well (but I will send it out later as
a separate patchset).
The ARM maintainers suggest to export TCR_EL1.T0SZ as well (for
helping with 52-bit user-space VA applications working on older 48-bit
VA kernel), but again I think it would be a separate (if such a
use-case arises) patch. I am trying to understand from fedora arm64
users if they really have such use-cases presently.
> o whether the kernel has the "flipped" linear map and the others.
> We need a fix to __pa() with it. (see the patch below)
>
> - PA_BITS or MAX_PHYSMEM_BITS to determine:
> o whether SPARSEMEM_EXTREME or not, in is_sparsemem_extreme()
> o whether the kernel has 48-bit or 52-bit PA to switch
> the calculation of pte-to-paddr. (this might be unnecessary?)
>
> Is this right?
Indeed.
> And wrote a very draft patch, which works on a 5.4-rc4 kernel that
> I modified to have NUMBER(vabits_actual) and NUMBER(MAX_PHYSMEM_BITS),
> with VA_BITS=48 config or VA_BITS=52 config running in 48-bit mode.
> https://github.com/k-hagio/makedumpfile/commit/fd9d86ea05b38e9edbb8c0ac3ebd612d5d485df3
>
> (I don't intend to export them as they are, it's just for an experiment.
> And no support for --mem-usage option, "real" 52-bit PA, and so on.)
>
> As for MAX_PHYSMEM_BITS, I don't stick to export it for all architectures,
> although I told you that it would be better to do so in the past.
> If it's hard to do so, it's fine with me to export it or something similar
> only for arm64 for now..
Thanks for working on the changes. I think the makedumpfile changes
are quite simpler (other than the --mem-usage option which might be
broken for the 1st round of 52-bit changes), but the kernel patches
would need discussion and closure with ARM maintainers.
I have already sent out a cleanup patch
<https://lore.kernel.org/linux-arm-kernel/1572904606-27961-1-git-send-email-bhsharma@xxxxxxxxxx/>,
which has been queued for 5.5, as there is no longer any scenario
where user VA != kernel VA size from a kernel configuration p-o-v.
I am discussing another fix-up patch with the ARM maintainers (which
they believe needs more testing) for the 52-bit VA changes in the
kernel for an issue I am seeing on my board. So, I will keep
working/debugging on this for now.
My current course of action is to send at least the following two
patches for exporting:
- TCR_EL1.T1SZ in vmcoreinfo (for ARM64 ARCH),
- crash_core, vmcoreinfo: Append 'MAX_PHYSMEM_BITS' to vmcoreinfo (for
all ARCHs).
Subsequently I will send the makedumpfile patches as well.
I will Cc you and John to the same.
Regards,
Bhupesh
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
