qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why do we have both CONFIG_SOFTMMU and CONFIG_USER_ONLY?


From: Richard Henderson
Subject: Re: Why do we have both CONFIG_SOFTMMU and CONFIG_USER_ONLY?
Date: Tue, 8 Dec 2020 12:10:55 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

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 <cfontana@suse.de> 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~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]