Hi Drew, On Tue, Sep 17, 2024 at 5:45 AM Andrew Jones <ajo...@ventanamicro.com> wrote: > > On Mon, Sep 09, 2024 at 01:27:05PM GMT, Alistair Francis wrote: > > On Tue, Aug 6, 2024 at 7:05 AM Gregor Haas <gregorhaas1...@gmail.com> wrote: > > > > > > This patch series adds support for specifying OpenSBI domains on the QEMU > > > command line. A simple example of what this looks like is below, including > > > mapping the board's UART into the secondary domain: > > > > Thanks for the patch, sorry it took me so long to look into this > > > > > > > > qemu-system-riscv64 -machine virt -bios fw_jump.bin -cpu max -smp 2 -m 4G > > > -nographic \ > > > -device > > > opensbi-memregion,id=mem,base=0xBC000000,order=26,mmio=false \ > > > -device > > > opensbi-memregion,id=uart,base=0x10000000,order=12,mmio=true,device0="/soc/serial@10000000" > > > \ > > > -device > > > opensbi-domain,id=domain,possible-harts=0-1,boot-hart=0x0,next-addr=0xBC000000,next-mode=1,region0=mem,perms0=0x3f,region1=uart,perms1=0x3f > > > > This will need documentation added under docs (probably under > > docs/system/riscv) of how this should be used. > > > > I'm not convinced this is something we want though. A user can dump > > the QEMU DTB and edit it to support OpenSBI domains if they want. > > > > I also feel like this is just pushing the population of device tree > nodes from an editor of a .dts file to the QEMU command line. If some > generation is needed, then maybe we need a script, possibly one which > has the same command line inputs as proposed here. afaik, we haven't > typically taken patches which help overlay the generated devicetree > with additional nodes. For example, see [1] for one such proposal > and rejection. > > [1] https://lore.kernel.org/all/20210926183410.256484-1-...@chromium.org/ > Thanks, > drew
Thanks for the link! After reading through that chain, I can see that there is typically high resistance to guest-specific device tree patches. As such, I'll probably abandon this patch series rather than doing more work to clean it up. I do wonder why there is so much resistance to these types of changes when the need for them arises so often in various boot firmwares. Thanks, Gregor
