From: Laurent Vivier <laurent@vivier.eu>
To: Aurelien Jarno <aurelien@aurel32.net>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Riku Voipio <riku.voipio@iki.fi>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] linux-user: Avoid compilation error with --disable-guest-base
Date: Wed, 1 Jul 2015 20:21:03 +0200 [thread overview]
Message-ID: <55942F8F.9070106@vivier.eu> (raw)
In-Reply-To: <20150701131536.GD11361@aurel32.net>
Le 01/07/2015 15:15, Aurelien Jarno a écrit :
> On 2015-07-01 01:58, Laurent Vivier wrote:
>>
>>
>> Le 30/06/2015 19:20, Peter Maydell a écrit :
>>> On 30 June 2015 at 18:13, Laurent Vivier <laurent@vivier.eu> wrote:
>>>>
>>>>
>>>> Le 30/06/2015 18:45, Peter Maydell a écrit :
>>>>> On 30 June 2015 at 17:19, Laurent Vivier <laurent@vivier.eu> wrote:
>>>>>> When guest base is disabled, RESERVED_VA is 0, and
>>>>>> (__guest < RESERVED_VA) is always false as __guest is unsigned.
>>>>>>
>>>>>> With -Werror=type-limits, this triggers an error:
>>>>>>
>>>>>> include/exec/cpu_ldst.h:60:31: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits]
>>>>>> (!RESERVED_VA || (__guest < RESERVED_VA)); \
>>>>>>
>>>>>> This patch removes this comparison when guest base is disabled.
>>>>>
>>>>> Is there a useful reason to compile with --disable-guest-base
>>>>> (ie why we should retain the !CONFIG_USE_GUEST_BASE code
>>>>> in QEMU at all) ? It was originally optional because we
>>>>> didn't support it in all our TCG hosts, but we fixed that
>>>>> back in 2012...
>>>>
>>>> TCG generates less code, so performance is better (well, it is what I
>>>> guess).
>>>>
>>>> I've compiled a kernel with and without guest base in a chrooted
>>>> linux-user-qemu.
>>>> Without guest base it is ~1 minute less for a 13 minutes build.
>>>>
>>>> I can do more tests if you want.
>>>
>>> Hmm. That's a fair chunk of speedup. On the downside:
>>> * you only get this if you're willing to build QEMU from
>>> source with funny options
>>> * it won't work for all guest/host combinations (sometimes
>>> the guest really wants to be able to map at low addresses
>>> the host won't permit)
>>> * it's an extra configuration to maintain which we're
>>> clearly not testing at all upstream
>>>
>>> I'd still favour removing it completely, personally...
>>
>> In fact, I have made more measurements, it saves only ~10 seconds on a
>> 13 minutes build.
>>
>> my test is: "make -j 4 vmlinux"
>> (target: m68k, host: x86_64, 4 cores x 2 threads)
>
> Note that on x86_64, guest base is implemented by using the gs segment
> register. That explains why the impact should be relatively low, as your
> test shows.
I did a similar test on a PowerPC host, It is 2 seconds MORE on an 1m27s
build WITH --disable-guest-base.
So, definitively, I think the option can be dropped.
Laurent
next prev parent reply other threads:[~2015-07-01 18:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-30 16:19 [Qemu-devel] [PATCH] linux-user: Avoid compilation error with --disable-guest-base Laurent Vivier
2015-06-30 16:45 ` Peter Maydell
2015-06-30 17:13 ` Laurent Vivier
2015-06-30 17:20 ` Peter Maydell
2015-06-30 23:58 ` Laurent Vivier
2015-07-01 11:12 ` Peter Maydell
2015-07-01 13:15 ` Aurelien Jarno
2015-07-01 18:21 ` Laurent Vivier [this message]
2015-07-01 19:46 ` Aurelien Jarno
2015-07-21 6:51 ` Richard Henderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55942F8F.9070106@vivier.eu \
--to=laurent@vivier.eu \
--cc=aurelien@aurel32.net \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=riku.voipio@iki.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).