On 12/7/20 5:56 AM, Claudio Fontana wrote: > On 12/7/20 12:50 PM, Peter Maydell wrote: >> On Mon, 7 Dec 2020 at 11:39, Claudio Fontana <[email protected]> wrote: >>> >>> As in Subject, >>> >>> am I understanding correctly that the one or the other is redundant? >>> >>> Should we keep only one of them? >> >> I think that perhaps the idea at one point was that we >> might have a version of linux-user which used a softmmu >> (this would allow better control of the guest's view of >> its address space, so guest mmap() to fixed addresses >> would work better, for instance). But nobody's ever actually >> tried to implement that, so I imagine that if we ever did >> we'd find that some CONFIG_SOFTMMU and some CONFIG_USER_ONLY >> defines were the wrong way around... >> >> thanks >> -- PMM >> > > Hi Peter, > > thanks for the background, > > indeed I am seeing some of these cases, target/XXX/cpu.c is protecting code > with #ifndef CONFIG_USER_ONLY, > > but the header files in include/hw/core/cpu.h and others use #ifdef > CONFIG_SOFTMMU.
In an ideal future in which linux-user could use softmmu, I would have softmmu be a runtime option rather than a compile-time option. The option would merely affect how TCG generates code. So while in that ideal future only CONFIG_USER_ONLY would remain, in an ideal present CONFIG_SOFTMMU would mark those places where a runtime check should be added. But the present is not ideal, and system-ness (or non-user-only-ness) and actual mmu emulation are often confused. Cleanups welcome. ;-) r~
