On Fri, 27 Feb 2026 at 14:51, Markus Armbruster <[email protected]> wrote: > > Peter Maydell <[email protected]> writes: > > > On Fri, 27 Feb 2026 at 12:10, Markus Armbruster <[email protected]> wrote: > >> The larger problem is that we generally fail at documenting device and > >> machine properties. I'm not asking you to boil that ocean :) > >> > >> The narrow problem is providing guidance on watchdog configuration. > >> What and where? > >> > >> Regarding where: you proposed to add a machine property of QAPI enum > >> type. > >> > >> The property can have a description, and you give it one. Sadly, it's > >> basically invisible. As far as I know, the only way you can get at it > >> is qom-list-properties and such. I doubt anybody is going to read the > >> description there. > > > > I think it also will appear if you run e.g. > > qemu-system-arm -M virt,help > > > > (which produces a list of all properties with their short descriptions) > > You're right! > > > For board-specific properties, we should be documenting these in > > the manual page for the board. For instance "virt" does that here: > > > > https://www.qemu.org/docs/master/system/arm/virt.html#machine-specific-options > > Every board should have such a page. Even if it's just a placeholder. > Placeholders would remind us where the gaps are.
I agree. For Arm I believe every board should already have a docs page, even if a very minimal one. (Some closely related boards get described on a single page that covers that whole family of boards.) The full list of pages is here: https://www.qemu.org/docs/master/system/target-arm.html We follow the same pattern (but not always with complete coverage) in most but not all the other target architectures. I don't think there's currently any automatic way to get a list of undocumented boards, because there isn't any tagging of the boards that are documented except in as much as the board names are listed in the title of the relevant pages. -- PMM
