From: Nick Kossifidis <mick@ics.forth.gr>
To: Palmer Dabbelt <palmer@dabbelt.com>
Cc: david.abdurachmanov@sifive.com, anup@brainfault.org,
Atish Patra <Atish.Patra@wdc.com>,
yibin_liu@c-sky.com, zong.li@sifive.com,
Paul Walmsley <paul.walmsley@sifive.com>,
mick@ics.forth.gr, linux-riscv@lists.infradead.org
Subject: Re: [PATCH v2 2/3] RISC-V: Add kdump support
Date: Thu, 16 Jul 2020 18:31:29 +0300 [thread overview]
Message-ID: <3e3af982459083a8467662ca1114007c@mailhost.ics.forth.gr> (raw)
In-Reply-To: <mhng-8b167c99-bbdf-420c-95a4-40ad9d706d45@palmerdabbelt-glaptop1>
Στις 2020-07-11 06:59, Palmer Dabbelt έγραψε:
> On Tue, 23 Jun 2020 08:05:11 PDT (-0700), mick@ics.forth.gr wrote:
>>
>> +
>> + /* Switch to physical addressing */
>> + csrw sptbr, zero
>
> I guess I'm missing something, but I'd assume that we would need some
> sort of
> tvec juggling here like we usually do when jumping between virtual and
> physical
> spaces. I get that we're not relocating the kernel that we're jumping
> to, but
> I don't understand how PAGE_OFFSET works.
>
We only clean up registers after this, interrupts are disabled, and jalr
will be called with an absolute physical address after satp is zero. I
don't see how we can end up with a trap but I can add a1 to stvec just
in case if you want.
>> +
>> + /* Pass the arguments to the next kernel / Cleanup*/
>
> Missing space in that comment.
>
ACK
>> + /* Add /memory regions to the resource tree */
>> + for_each_memblock(memory, region) {
>> + res = memblock_alloc(sizeof(struct resource), SMP_CACHE_BYTES);
>> + if (!res)
>> + panic("%s: Failed to allocate %zu bytes\n", __func__,
>> + sizeof(struct resource));
>> +
>> + if (unlikely(memblock_is_nomap(region))) {
>> + res->name = "Reserved";
>> + res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
>
> This differs from what I ended up with in that I don't have
> IORESOURCE_BUSY. I
> just copied this blindly from arm64 so I don't actually know what the
> difference is.
>
For now since we don't mark any /memory regions with the NOMAP flag (ARM
for example does this for the kernel image region) this code won't be
executed, I put it there for completeness in case we do so in the
future. In any case the idea is to prevent a region marked with NOMAP to
be accessible through /dev/mem when STRICT_DEVMEM & IO_STRICT_DEVMEM is
enabled. On devmem_is_allowed(), the default page_is_ram() will check
for IORESOURCE_SYSTEM_RAM flag so it will not prevent this region from
being mapped through /dev/mem since it's flaged with IORESOURCE_MEM
instead. The idea is to rely on iomem_is_exclusive() to do the work, and
for that we need the region to be marked as busy
(https://elixir.bootlin.com/linux/v5.8-rc4/source/kernel/resource.c#L1614).
I wanted to do something to also honor the no_map flag on the
/reserved-memory regions that according to the device tree spec,
shouldn't be available to any other than the driver (so we should also
prevent them from being accessible through /dev/mem), and I noticed that
other archs don't deal with this. However this was a bit off-topic since
it had nothing to do with kexec/kdump.
>
> If you split out init_resource() then I can take it before the rest of
> the
> kexec stuff.
I'll send a patch for populating ioresources and also add the extra
sauce for handling no_map for /reserved-memory regions. Then I'll send
kdump / crashkernel on top. Is it OK if I remove the existing code from
mm/init.c and add the new one on kernel/setup.c ? After all it's not
related to mm, ioresources is a different thing and other archs also
handle this on setup.c.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2020-07-16 15:32 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-23 15:05 [PATCH v2 0/3] RISC-V: Add kexec/kdump support Nick Kossifidis
2020-06-23 15:05 ` [PATCH v2 1/3] RISC-V: Add kexec support Nick Kossifidis
2020-07-11 3:59 ` Palmer Dabbelt
2020-07-16 14:57 ` Nick Kossifidis
2020-06-23 15:05 ` [PATCH v2 2/3] RISC-V: Add kdump support Nick Kossifidis
2020-07-11 3:59 ` Palmer Dabbelt
2020-07-16 15:31 ` Nick Kossifidis [this message]
2020-06-23 15:05 ` [PATCH v2 3/3] RISC-V: Add crash kernel support Nick Kossifidis
2020-07-11 3:59 ` Palmer Dabbelt
2020-07-16 15:52 ` Nick Kossifidis
2020-07-11 3:59 ` BPATCH=20v2=200/3=5D=20RISC-V=3A=20Add=20kexec/kdump=20support=E2=80=8B?= Palmer Dabbelt
2020-07-16 14:04 ` BPATCH=20v2=200/3=5D=20RISC-V=3A=20Add=20kexec/kdump=20support=E2=80=8B?= Nick Kossifidis
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=3e3af982459083a8467662ca1114007c@mailhost.ics.forth.gr \
--to=mick@ics.forth.gr \
--cc=Atish.Patra@wdc.com \
--cc=anup@brainfault.org \
--cc=david.abdurachmanov@sifive.com \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=yibin_liu@c-sky.com \
--cc=zong.li@sifive.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).