* Makedumpfile help for 5.4.0.rc3 : Arm
@ 2019-10-21 16:09 John Donnelly
2019-10-21 18:53 ` Bhupesh Sharma
0 siblings, 1 reply; 10+ messages in thread
From: John Donnelly @ 2019-10-21 16:09 UTC (permalink / raw
To: kexec
Hello,
Kazuhito Hagio asked me to share my test results on this patch for makedumpfile :
https://sourceforge.net/p/makedumpfile/code/ci/7bdb468c2c99dd780c9a5321f93c79cbfdce2527/
And I was successfully able to get vmcore dumps on vmlinuz-5.3.6 and 5.4.0-rc3 Intel ( x86-64) kernels.
I am still having difficulties getting vmcores on 5.4.0.rc3 Arm kernels with this update to makedumpfile.
I get this message;
Buffer size for the cyclic mode: 3145728
va_bits : 47
page_offset : ffffc00000000000
calculate_plat_config: PAGE SIZE 0x10000 and VA Bits 47 not supported
get_machdep_info_arm64: Can't determine platform config values
makedumpfile Failed.
Any suggestions welcomed
—
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Makedumpfile help for 5.4.0.rc3 : Arm
2019-10-21 16:09 Makedumpfile help for 5.4.0.rc3 : Arm John Donnelly
@ 2019-10-21 18:53 ` Bhupesh Sharma
2019-10-21 19:16 ` John Donnelly
0 siblings, 1 reply; 10+ messages in thread
From: Bhupesh Sharma @ 2019-10-21 18:53 UTC (permalink / raw
To: John Donnelly; +Cc: kexec mailing list
Hello John,
On Mon, Oct 21, 2019 at 9:39 PM John Donnelly
<john.p.donnelly@oracle.com> wrote:
>
>
>
> Hello,
>
>
> Kazuhito Hagio asked me to share my test results on this patch for makedumpfile :
>
>
> https://sourceforge.net/p/makedumpfile/code/ci/7bdb468c2c99dd780c9a5321f93c79cbfdce2527/
>
> And I was successfully able to get vmcore dumps on vmlinuz-5.3.6 and 5.4.0-rc3 Intel ( x86-64) kernels.
>
> I am still having difficulties getting vmcores on 5.4.0.rc3 Arm kernels with this update to makedumpfile.
>
> I get this message;
>
>
> Buffer size for the cyclic mode: 3145728
> va_bits : 47
> page_offset : ffffc00000000000
> calculate_plat_config: PAGE SIZE 0x10000 and VA Bits 47 not supported
> get_machdep_info_arm64: Can't determine platform config values
>
> makedumpfile Failed.
>
>
> Any suggestions welcomed
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").
The suggestions during the last set of reviews (my v3 patchset) was to
introduce arch specific details like TCR_EL1.TxSZ in the vmcoreinfo
and also to wait for the 52-bit changes to make way upstream (as I
raised a couple of issues/kernel panic issues) earlier with the 52-bit
VA changes from Steve.
I plan to send out the v4 patchset later this week (and will Cc you so
that you can test the same).
Thanks,
Bhupesh
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Makedumpfile help for 5.4.0.rc3 : Arm
2019-10-21 18:53 ` Bhupesh Sharma
@ 2019-10-21 19:16 ` John Donnelly
2019-10-22 7:52 ` Bhupesh Sharma
0 siblings, 1 reply; 10+ messages in thread
From: John Donnelly @ 2019-10-21 19:16 UTC (permalink / raw
To: Bhupesh Sharma; +Cc: kexec mailing list
Hi Bhupesh
> On Oct 21, 2019, at 1:53 PM, Bhupesh Sharma <bhsharma@redhat.com> wrote:
>
> Hello John,
>
> On Mon, Oct 21, 2019 at 9:39 PM John Donnelly
> <john.p.donnelly@oracle.com> wrote:
>>
>>
>>
>> Hello,
>>
>>
>> Kazuhito Hagio asked me to share my test results on this patch for makedumpfile :
>>
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceforge.net_p_makedumpfile_code_ci_7bdb468c2c99dd780c9a5321f93c79cbfdce2527_&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=UkLq9rpRCDj7DqKa-5dVlvS7yMZxB7jvNd9aGutvEu0&s=d9TLmOPVO4PFtvcFwVOeZRcMg0UOmy04XdgztVxXWyg&e=
>>
>> And I was successfully able to get vmcore dumps on vmlinuz-5.3.6 and 5.4.0-rc3 Intel ( x86-64) kernels.
>>
>> I am still having difficulties getting vmcores on 5.4.0.rc3 Arm kernels with this update to makedumpfile.
>>
>> I get this message;
>>
>>
>> Buffer size for the cyclic mode: 3145728
>> va_bits : 47
>> page_offset : ffffc00000000000
>> calculate_plat_config: PAGE SIZE 0x10000 and VA Bits 47 not supported
>> get_machdep_info_arm64: Can't determine platform config values
>>
>> makedumpfile Failed.
>>
>>
>> Any suggestions welcomed
>
> 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 ?
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Makedumpfile help for 5.4.0.rc3 : Arm
2019-10-21 19:16 ` John Donnelly
@ 2019-10-22 7:52 ` Bhupesh Sharma
2019-10-28 20:49 ` Kazuhito Hagio
0 siblings, 1 reply; 10+ messages in thread
From: Bhupesh Sharma @ 2019-10-22 7:52 UTC (permalink / raw
To: John Donnelly; +Cc: kexec mailing list
Hi John,
On Tue, Oct 22, 2019 at 12:47 AM John Donnelly
<john.p.donnelly@oracle.com> wrote:
>
> Hi Bhupesh
>
> > On Oct 21, 2019, at 1:53 PM, Bhupesh Sharma <bhsharma@redhat.com> wrote:
> >
> > Hello John,
> >
> > On Mon, Oct 21, 2019 at 9:39 PM John Donnelly
> > <john.p.donnelly@oracle.com> wrote:
> >>
> >>
> >>
> >> Hello,
> >>
> >>
> >> Kazuhito Hagio asked me to share my test results on this patch for makedumpfile :
> >>
> >>
> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceforge.net_p_makedumpfile_code_ci_7bdb468c2c99dd780c9a5321f93c79cbfdce2527_&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=UkLq9rpRCDj7DqKa-5dVlvS7yMZxB7jvNd9aGutvEu0&s=d9TLmOPVO4PFtvcFwVOeZRcMg0UOmy04XdgztVxXWyg&e=
> >>
> >> And I was successfully able to get vmcore dumps on vmlinuz-5.3.6 and 5.4.0-rc3 Intel ( x86-64) kernels.
> >>
> >> I am still having difficulties getting vmcores on 5.4.0.rc3 Arm kernels with this update to makedumpfile.
> >>
> >> I get this message;
> >>
> >>
> >> Buffer size for the cyclic mode: 3145728
> >> va_bits : 47
> >> page_offset : ffffc00000000000
> >> calculate_plat_config: PAGE SIZE 0x10000 and VA Bits 47 not supported
> >> get_machdep_info_arm64: Can't determine platform config values
> >>
> >> makedumpfile Failed.
> >>
> >>
> >> Any suggestions welcomed
> >
> > 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@arm.com>
Date: Wed Aug 7 16:55:22 2019 +0100
arm64: mm: Introduce 52-bit Kernel VAs
Thanks,
Bhupesh
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Makedumpfile help for 5.4.0.rc3 : Arm
2019-10-22 7:52 ` Bhupesh Sharma
@ 2019-10-28 20:49 ` Kazuhito Hagio
2019-10-29 19:10 ` Bhupesh Sharma
2019-11-07 20:31 ` Bhupesh Sharma
0 siblings, 2 replies; 10+ messages in thread
From: Kazuhito Hagio @ 2019-10-28 20:49 UTC (permalink / raw
To: Bhupesh Sharma; +Cc: John Donnelly, kexec mailing list
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@arm.com>
> 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
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?
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..
Your thoughts?
Thanks,
Kazu
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Makedumpfile help for 5.4.0.rc3 : Arm
2019-10-28 20:49 ` Kazuhito Hagio
@ 2019-10-29 19:10 ` Bhupesh Sharma
2019-10-30 15:08 ` Kazuhito Hagio
2019-11-07 20:31 ` Bhupesh Sharma
1 sibling, 1 reply; 10+ messages in thread
From: Bhupesh Sharma @ 2019-10-29 19:10 UTC (permalink / raw
To: Kazuhito Hagio; +Cc: John Donnelly, kexec mailing list
Hi Kazu,
Sorry for top posting, but I am on leave for Diwali Holidays and will
return to the office in a couple of days.
I have the solution/patchset ready and I just need to finish the
commit messages to make sure they are self-explanatory for upstream
acceptance.
I will try to post them and also answer your email in detail when I
return back from holidays.
Thanks for your patience.
Regards,
Bhupesh
(Sent from my Android Phone)
On Tue, Oct 29, 2019 at 2:23 AM Kazuhito Hagio <k-hagio@ab.jp.nec.com> 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@arm.com>
> > 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
> 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?
>
> 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..
>
> Your thoughts?
>
> Thanks,
> Kazu
>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Makedumpfile help for 5.4.0.rc3 : Arm
2019-10-29 19:10 ` Bhupesh Sharma
@ 2019-10-30 15:08 ` Kazuhito Hagio
2019-10-30 15:18 ` John Donnelly
0 siblings, 1 reply; 10+ messages in thread
From: Kazuhito Hagio @ 2019-10-30 15:08 UTC (permalink / raw
To: Bhupesh Sharma, John Donnelly; +Cc: kexec mailing list
Hi Bhupesh,
OK, thanks for letting me know that in your holidays. Have good ones.
I just thought that it might be good to share our understanding before
posting a kernel patch so that I can do something to support you if
need be.
Hi John,
You see that error with my test patch, which is only for testing though,
as I wrote below
> > 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),
that patch requires a kernel fix to have these in vmcoreinfo.
Did you try it?
Thanks,
Kazu
> -----Original Message-----
> Hi Kazu,
>
> Sorry for top posting, but I am on leave for Diwali Holidays and will
> return to the office in a couple of days.
>
> I have the solution/patchset ready and I just need to finish the
> commit messages to make sure they are self-explanatory for upstream
> acceptance.
>
> I will try to post them and also answer your email in detail when I
> return back from holidays.
>
> Thanks for your patience.
>
> Regards,
> Bhupesh
>
> (Sent from my Android Phone)
>
> On Tue, Oct 29, 2019 at 2:23 AM Kazuhito Hagio <k-hagio@ab.jp.nec.com> 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@arm.com>
> > > 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
> > 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?
> >
> > 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..
> >
> > Your thoughts?
> >
> > Thanks,
> > Kazu
> >
>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Makedumpfile help for 5.4.0.rc3 : Arm
2019-10-30 15:08 ` Kazuhito Hagio
@ 2019-10-30 15:18 ` John Donnelly
2019-10-30 17:01 ` Kazuhito Hagio
0 siblings, 1 reply; 10+ messages in thread
From: John Donnelly @ 2019-10-30 15:18 UTC (permalink / raw
To: Kazuhito Hagio, Bhupesh Sharma; +Cc: kexec mailing list
On 10/30/19 10:08 AM, Kazuhito Hagio wrote:
> Hi Bhupesh,
>
> OK, thanks for letting me know that in your holidays. Have good ones.
> I just thought that it might be good to share our understanding before
> posting a kernel patch so that I can do something to support you if
> need be.
>
>
> Hi John,
>
> You see that error with my test patch, which is only for testing though,
> as I wrote below
>
Hi,
If there are corresponding kernel patches being considered to make
makedumpfile work on v8 and v8.x systems I would be interesting in
testing those also.
makedumpfile should be able to work with a variety of VAbits as 48, or
52 settings.
>>> 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),
>
> that patch requires a kernel fix to have these in vmcoreinfo.
> Did you try it?
>
> Thanks,
> Kazu
>
>> -----Original Message-----
>> Hi Kazu,
>>
>> Sorry for top posting, but I am on leave for Diwali Holidays and will
>> return to the office in a couple of days.
>>
>> I have the solution/patchset ready and I just need to finish the
>> commit messages to make sure they are self-explanatory for upstream
>> acceptance.
>>
>> I will try to post them and also answer your email in detail when I
>> return back from holidays.
>>
>> Thanks for your patience.
>>
>> Regards,
>> Bhupesh
>>
>> (Sent from my Android Phone)
>>
>> On Tue, Oct 29, 2019 at 2:23 AM Kazuhito Hagio <k-hagio@ab.jp.nec.com> 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@arm.com>
>>>> 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
>>> 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?
>>>
>>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_k-2Dhagio_makedumpfile_commit_fd9d86ea05b38e9edbb8c0ac3ebd612d5d485df3&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=D3owhCFsJR8X0Bhl0Tja3Jh5BFhvKkuKpiPnj9aZnZE&s=ZLnu3rvxqa6NPURmGNYpCG6g0H9yE3CCazQMWO40qOo&e=
>>>
>>> (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..
>>>
>>> Your thoughts?
>>>
>>> Thanks,
>>> Kazu
>>>
>>
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_kexec&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=D3owhCFsJR8X0Bhl0Tja3Jh5BFhvKkuKpiPnj9aZnZE&s=JlcDD-35oacdsLbznVvfU3Gl93zp1N53P2XcC6_Wcus&e=
>
--
Thank You,
John
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Makedumpfile help for 5.4.0.rc3 : Arm
2019-10-30 15:18 ` John Donnelly
@ 2019-10-30 17:01 ` Kazuhito Hagio
0 siblings, 0 replies; 10+ messages in thread
From: Kazuhito Hagio @ 2019-10-30 17:01 UTC (permalink / raw
To: John Donnelly; +Cc: Bhupesh Sharma, kexec mailing list
> -----Original Message-----
> If there are corresponding kernel patches being considered to make
> makedumpfile work on v8 and v8.x systems I would be interesting in
> testing those also.
>
>
> makedumpfile should be able to work with a variety of VAbits as 48, or
> 52 settings.
Yes, Bhupesh will post his patches to do so.
The v3 patchset that was mentioned earlier is this:
https://lore.kernel.org/linux-arm-kernel/1553058574-18606-1-git-send-email-bhsharma@redhat.com/
We have to export things that we need and arm maintainers can export
to vmcoreinfo.
Thanks,
Kazu
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Makedumpfile help for 5.4.0.rc3 : Arm
2019-10-28 20:49 ` Kazuhito Hagio
2019-10-29 19:10 ` Bhupesh Sharma
@ 2019-11-07 20:31 ` Bhupesh Sharma
1 sibling, 0 replies; 10+ messages in thread
From: Bhupesh Sharma @ 2019-11-07 20:31 UTC (permalink / raw
To: Kazuhito Hagio; +Cc: John Donnelly, kexec mailing list
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@ab.jp.nec.com> 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@arm.com>
> > 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@redhat.com/>,
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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2019-11-07 20:32 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-10-21 16:09 Makedumpfile help for 5.4.0.rc3 : Arm John Donnelly
2019-10-21 18:53 ` Bhupesh Sharma
2019-10-21 19:16 ` John Donnelly
2019-10-22 7:52 ` Bhupesh Sharma
2019-10-28 20:49 ` Kazuhito Hagio
2019-10-29 19:10 ` Bhupesh Sharma
2019-10-30 15:08 ` Kazuhito Hagio
2019-10-30 15:18 ` John Donnelly
2019-10-30 17:01 ` Kazuhito Hagio
2019-11-07 20:31 ` Bhupesh Sharma
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.