On 2/3/25 08:31, Akihiko Odaki wrote: ... >> Requirements don't vary much. For example virglrenderer minigbm support >> is mandatory for crosvm, while for QEMU it's not. > > Is that true? It seems that virglrenderer uses builds without minigbm > support to run tests on GitLab CI.
CI is running in a headless mode using software renderer. For a full-featured crosvm support running on a baremetal, minigbm should be needed, along with other downstream features. > Anyway, if there is any variance in the build procedure, that may > justify having a separate build instruction in QEMU tree to avoid > confusion. Otherwise, it's better to have a documentation shared with > other VMMs. > >> >>> I'm not entirely sure the documentation will stay as is for that long. >>> The requirements of Intel native context refer to merge requests that >>> can be merged sooner or later. Asahi may need more updates if you >>> document it too because its DRM ABI is still unstable. >> >> The unstable parts of course will need to be updated sooner, but the >> stable should be solid for years. I expect that about a year later >> requirements will need to be revisited. >> > > It will be some burden in the future. Now you are adding this > documentation just for QEMU, but crosvm and libkrun may gain similar > documentation. The DRM native context support for Intel and Asahi is in > development, and I guess nvk will support it someday. > > So, a very rough estimation of future documentation updates will be: > (number of VMMs) * (number of DRM native contexts in development) > = 3 * 3 > = 9 > > That's manageable but suboptimal. I don't mind deferring the doc addition if that's preferred. Either way is fine with me. Yet it's better to have doc than not. In my view crosvm and libkrun exist separately from QEMU, they serve a different purpose. Majority of QEMU users likely never heard about those other VMMs. A unified doc won't be a worthwhile effort, IMO. -- Best regards, Dmitry
