RISC-V Memory Hot Plugging To Be Introduced With Linux 6.11

[phoronix]

Phoronix: RISC-V Memory Hot Plugging To Be Introduced With Linux 6.11

The RISC-V kernel port with Linux 6.11 is introducing the ability to handle memory hot plugging/unplugging...

https://www.phoronix.com/news/RISC-V-Linux-6.11-Hot-Memory

[uid313]

So how does RISC-V compare to x86 and ARM in terms of support in the Linux kernel?
Does it support UEFI? UEFI Secure Boot? TPM 2.0? ACPI? firmware updates? RISCV as a guest, RISC-V as a host, hypervisor? What doesn't it support?

[klara]

UEFI as well as ACPI seems to be supported:

Symbol: EFI [=y]
Type  : bool
Defined at arch/riscv/Kconfig:967
  Prompt: UEFI runtime support
  Depends on: OF [=y] && !XIP_KERNEL [=n] && MMU [=y]
  Location:
    -> Boot options
(1)   -> UEFI runtime support (EFI [=y])
Selects: ARCH_SUPPORTS_ACPI [=y] && EFI_GENERIC_STUB [=y] && EFI_PARAMS_FROM_FDT [=y] && EFI_RUNTIME_WRAPPERS [=y] && EFI_STUB [=y] && LIBFDT  [=y] && RISCV_ISA_C [=y] && UCS2_STRING [=y]
Selected by [y]:
  - PORTABLE [=y]

I'm not sure if there is hardware that implements UEFI directly, but U-Boot can provide a UEFI environment with the 'bootefi' command. I'm also unsure about secure boot, that's probably more on the firmware side. U-Boot also has a flavor of verified boot that's different. TPM is not arch specific and should probably work as long as the hardware is available, but I'm not an expert.

Firmware updates will depend on the platform, but if it uses U-boot plus OpenSBI stored on flash that shouldn't be a large problem. Though if the support is not upstream it will also depend on the vendor whether there are any updates.

KVM is experimental:

Symbol: KVM [=m]
Type  : tristate
Defined at arch/riscv/kvm/Kconfig:20
  Prompt: Kernel-based Virtual Machine (KVM) support (EXPERIMENTAL)
  Depends on: VIRTUALIZATION [=y] && RISCV_SBI [=y] && MMU [=y]
  Location:
    -> Virtualization (VIRTUALIZATION [=y])
(1)   -> Kernel-based Virtual Machine (KVM) support (EXPERIMENTAL) (KVM [=m])
Selects: HAVE_KVM_IRQCHIP [=y] && HAVE_KVM_IRQ_ROUTING [=y] && HAVE_KVM_MSI [=y] && HAVE_KVM_VCPU_ASYNC_IOCTL [=y] && HAVE_KVM_READONLY_MEM [=y] && KVM_COMMON [=y] && KVM_GENERIC_DIRTYLOG_READ_PROTECT [=y] && KVM_GENERIC_HARDWARE_ENABLING [=y] && KVM_MMIO [=y] && KVM_MMIO [=y] && KVM_XFER_TO_GUEST_WORK [=y] && KVM_GENERIC_MMU_NOTIFIER [=y] && SCHED_INFO [=y]

I can confirm directly that running RISC-V as a guest from a x86_64 system works in QEMU, but that is obviously without KVM.

[mantide]

So how does RISC-V compare to x86 and ARM in terms of support in the Linux kernel?
Does it support UEFI? UEFI Secure Boot? TPM 2.0? ACPI? firmware updates? RISCV as a guest, RISC-V as a host, hypervisor? What doesn't it support?

I know KVM and QEMU is actively developing on RISCV. Heck I think the only major thing on that front is RISC-V.
Details aside, I think your question is how usable is RISC-V now. For now it's not that widely accepted. RISCV just have the spec v1 finalized? However, I think we are not far from commercialized products. And more importantly, I see it to match ARM in terms of usability in this decade. After that there will only be one of them left.

[blackiwid]

I'm not sure if there is hardware that implements UEFI directly, but U-Boot can provide a UEFI environment with the 'bootefi' command. I'm also unsure about secure boot, that's probably more on the firmware side. U-Boot also has a flavor of verified boot that's different. TPM is not arch specific and should probably work as long as the hardware is available, but I'm not an expert.

Is there no alternative like just gnu boot like legacy boot or something 3rd? I literally start more and more hate EFI, because it's so much harder to manually to make it work, with old bios you just had a /root normaly formated... your system install the grub in mbr and you were done, now the only way I can make it work without intense research is to just install some linux fresh. Just recently transfered back for hours with pvmove I think the data to the old ssd because I could not make it boot, so I transfered it back so that I can boot it in the old pc with bios shit, then installed fedora normally and copied the /home directory luckily besides installing 1-2 software that was good enough.

But if we can presume that nobody has local access on a home pc but the user, it literally brings nothing or even if so the price of massive more complexity is not worth it.

I mean if there would be easy tools and not "ubuntu-fix-boot" or something... I don't use such software under fedora I am sorry... be my guest but without understanding it you don't really can fix each situation and hope the magic tools does the 5000 right steps necessary to fix it the way you want.

Sorry for the rant, but give me a break and spare me as home user this corporate paranoia Bullshit that makes everything bad, like ssl that is not real security often and expires private blogs left and right like a time bomb just for the interests of some stupid corporations... it's not the encryption that is the problem with ssl but the certificate with the dictatorship of google and co to accept that.

Maybe a fdisk "X" (create all the necessary 50 partitions in the right size and order)
would be a start... to make it more doable...

[Quackdoc]

So how does RISC-V compare to x86 and ARM in terms of support in the Linux kernel?
Does it support UEFI? UEFI Secure Boot? TPM 2.0? ACPI? firmware updates? RISCV as a guest, RISC-V as a host, hypervisor? What doesn't it support?

currently mainline support isn't super great when compared to ARM. However we are seeing a lot of players who have been volleying patches for riscv SBCs so I can safely say right now it's not superbe, but in the future it will be good. I've seen activity from most of the larger players in the consumer SBC world trying to get things upstreamed like milkv, sipeed etc.

sophgo even has a mainline tracker here https://github.com/sophgo/linux/wiki (the most recent dates and versions arent entirely accurate but paint a good picture)

but very short term, don't expect to be running on entirely mainline kernels anytime soon except for some specific hardware.

EDIT: I think that hardware actually includes the hardware based onjh7110 maybe...

[HEX0]

I literally start more and more hate EFI, because it's so much harder to manually to make it work

It was quite common 15+ years ago for UEFI to suck, because hardware vendors produced broken, buggy, incomplete firmware and only vaguely followed the UEFI spec. 32bit UEFI could be quite problematic too.

These days it seems fine.

I'm assuming you are trying to boot MBR formatted system in UEFI mode. I think all you need is GPT and a fat32 efi system partition and you should be good to go.

I recommend reading this

https://www.happyassassin.net/posts/2014/01/25/uefi-boot-how-does-that-actually-work-then/

[blackiwid]

I'm assuming you are trying to boot MBR formatted system in UEFI mode. I think all you need is GPT and a fat32 efi system partition and you should be good to go.

Yes and the 1. partition must be at a exact byte point... don't remember what but it must be starting at a specific point, 1 thing I have to remember a easy N partition doesn't work. then you need at least a specific size if it's only 1 byte it would not work I assume? And then you need the right bios setting, and then what grub-install /dev/sda probably not... whatever magic secret commands I need...

Move a bios install to a new device that is not bios boot... have fun... even with GPT what of course also sucks with all the dual formated shit and what not... 1000 variables you can get wrong

I recommend reading this

https://www.happyassassin.net/posts/2014/01/25/uefi-boot-how-does-that-actually-work-then/

You want me to read a 100 sites long document to understand it for real?

[luno]

So how does RISC-V compare to x86 and ARM in terms of support in the Linux kernel?
Does it support UEFI? UEFI Secure Boot? TPM 2.0? ACPI? firmware updates? RISCV as a guest, RISC-V as a host, hypervisor? What doesn't it support?

they have SIGs for almost all of those, so atleast they are planning support those.