On Tue, Oct 4, 2022 at 1:39 PM BALATON Zoltan <balaton@xxxxxxxxxx> wrote: > > On Tue, 4 Oct 2022, Jason A. Donenfeld wrote: > > On Tue, Oct 4, 2022 at 1:03 PM Peter Maydell <peter.maydell@xxxxxxxxxx> wrote: > >> What I'm asking, I guess, is why you're messing with this board > >> model at all if you haven't added this functionality to u-boot. > >> This is just an emulation of an ancient bit of MIPS hardware, which > >> nobody really cares about very much I hope. > > > > I think most people emulating MIPS would disagree. This is basically a > > reference platform for most intents and purposes. As I mentioned, this > > involves `-kernel` -- the thing that's used when you explicitly opt-in > > to not using a bootloader, so when you sign up for QEMU arranging the > > kernel image and its environment. Neglecting to pass an RNG seed would > > be a grave mistake. > > > >> I'm not saying this is a bad patch -- I'm just saying that > >> QEMU should not be in the business of defining bootloader-to-kernel > >> interfaces if it can avoid it, so usually the expectation is > >> that we are just implementing interfaces that are already > >> defined, documented and implemented by a real bootloader and kernel. > > > > Except that's not really the way things have ever worked here. The > > kernel now has the "rngseed" env var functionality, which is useful > > for a variety of scenarios -- kexec, firmware, and *most importantly* > > for QEMU. Don't block progress here. > > > >> -kernel generally means "emulate the platform's boot loader" > > > > And here, a platform bootloader could pass this, just as is the case > > with m68k's BI_RNG_SEED or x86's setup_data RNG SEED or device tree's > > rng-seed or EFI's LINUX_EFI_RANDOM_SEED_TABLE_GUID or MIPS' "rngseed" > > fw environment variable. These are important facilities to have. > > Bootloaders and hypervisors alike must implement them. *Do not block > > progress here.* > > Cool dowm. Peter does not want to block progress here. What he said was > that the malta is (or should be) emulating a real piece of hardware so > adding some stuff to it which is not on that real hardware may not be > preferred. If you want to experiment with generic mips hardware maybe you > need a virt board instead that is free from such restrictions to emulate a > real hardware. Some archs already have such board and there seems to be > loongson3-virt but no generic mips virt machine yet. Defining and > implementing such board may be more than you want to do for this but maybe > that would be a better way to go. This is the bikeshed suggestion that puts along the path of nothing ever getting done. This is an interface that's available for real firmware; there's no reason not to implement it here. It's the same situation as the MIPS boston board setting the rng-seed device tree property. There's nothing new or unusual about this, and it fits with how things work elsewhere on the architecture and QEMU at large. Besides, "malta" is the de facto platform used for emulating MIPS. Again, this is obvious progress blocking in action. Look how it's done elsewhere; look at how it's done in this patch; there's no difference. This patch is boring and unoffensive. We don't need to waste time bikeshedding it. Jason
