"Jason A. Donenfeld" <ja...@zx2c4.com> writes:
> Hi Alex, > > On Thu, Jul 21, 2022 at 08:36:10PM +0100, Alex Bennée wrote: >> >> Paolo Bonzini <pbonz...@redhat.com> writes: >> <snip> >> > uint64_t reg_attr[2] = {cpu_to_be64(s->addr), cpu_to_be64(size)}; >> > + uint8_t rng_seed[32]; >> > >> > if (!fdt) { >> > error_setg(errp, "Cannot modify FDT fields if the machine has >> > none"); >> > @@ -55,6 +57,9 @@ static void loader_insert_platform_data(GuestLoaderState >> > *s, int size, >> > qemu_fdt_add_subnode(fdt, node); >> > qemu_fdt_setprop(fdt, node, "reg", ®_attr, sizeof(reg_attr)); >> > >> > + qemu_guest_getrandom_nofail(rng_seed, sizeof(rng_seed)); >> > + qemu_fdt_setprop(fdt, node, "rng-seed", rng_seed, sizeof(rng_seed)); >> > + >> >> Why are we inserting this here? The guest-loader is only building on >> what the machine type has already constructed which in the case of -M >> virt for riscv and ARM already has code for this. > > Wish you would have replied to the list patch before Paolo queued it. I'm sorry if I didn't get to it in the *checks notes* 2 days since it was posted. I've been on holiday. > I don't know this mechanism well but I assumed it would pass a unique > seed to each chained loader. Let me know if I'm misunderstanding the > purpose; I have no qualms about dropping this patch. All the guest-loader does is add the information about where in memory a guest and/or it's initrd have been placed in memory to the DTB. It's entirely up to the initial booted code (usually a hypervisor in this case) to decide what gets passed up the chain to any subsequent guests. -- Alex Bennée