Hello Nick,

On 16/08/24 07:50, Nicholas Piggin wrote:
<...snip...>
One little nit is MachineState.fdt vs PnvMachineState.fdt
which is now confusing. I would call the new PnvMachineState member
something like fdt_from_dtb, or fdt_override?
I agree. this is confusing. machine->fdt could be used instead ?
Yeah that could be another option. Test pnv.dtb or add a new bool
to pnv if you need to check whether the fdt has been provided by
cmdline.

Sure, I will use machine->fdt. Testing pnv.dtb should be good enough to check if -dtb was passed I think.


Regarding the conversation about CAS, I don't have idea on it, other than the minimum basics. But thanks to you and Cedric, got to know somethings.


Thanks,

Aditya Gupta

The other question... Some machines rebuild fdt at init, others at
reset time. As far as I understood, spapr has to rebuild on reset
because C-A-S call can update the fdt so you have to undo that on
reset.
C-A-S is a guest OS hcall. reset is called before the guest OS
is started.
Right, but when you reboot it needs to be reverted to initial
(pre-CAS) fdt.

Did powernv just copy that without really needing it, I wonder?
Maybe that rearranged to just do it at init time (e.g., see
hw/riscv/virt.c which is simpler).
The machine is aware of user created devices (on the command line)
only at reset time.
Ah, I should have followed a bit closer. riscv, arm use a
machine_done notifier for that (and x86, loongarch for ACPI / BIOS
tables). So that avoids fdt rebuild after the first reset I think.

Anyway I don't really mind then, following other archs would be okay,
but keeping similar with spapr and avoiding code change is also good.
Maybe add a small comment to we use reset rather than machine_done
notifier of other archs to be similar to spapr.

Thanks,
Nick

Reply via email to