From: Richard Henderson <richard.henderson@linaro.org>
To: "Wu, Fei" <fei2.wu@intel.com>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [PATCH v2 01/28] accel/tcg: Introduce translator_use_goto_tb
Date: Tue, 14 Mar 2023 11:15:21 -0700 [thread overview]
Message-ID: <db955647-d769-e9fa-b314-6a3ee16b0b95@linaro.org> (raw)
In-Reply-To: <12e54d71-e208-507c-c9d2-c313f9301fc3@intel.com>
On 3/14/23 06:47, Wu, Fei wrote:
> On 3/13/2023 11:00 PM, Richard Henderson wrote:
>> On 3/13/23 07:13, Wu, Fei2 wrote:
>>> Hi Richard,
>>>
>>> Sorry for disturbing you. I'm doing some perf profiling on qemu-riscv64,
>>> I see 10%+ faster to build stress-ng without the following patch. I know
>>> it's incorrect to just skip this patch, I'm wondering if we can do
>>> something on intercepting mmap/mprotect (very rare), e.g. even
>>> invalidating all the TBs, but keep the cross-page block chaining.
>>
>> It also affects breakpoints.
>>
>> I have no good ideas for how to keep cross-page block chaining without
>> breaking either of these use cases. If you come up with a good idea,
>> please post on qemu-devel for discussion.
>>
> Thank you for reply. I am new to qemu/tcg, lots of details and
> backgrounds need to catch up.
>
> If we only want to address user-mode qemu, and assume this cross-page
> chain, first page -> second page:
>
> * breakpoints. If a new bp is added to second page, the chain is hard to
> maintain, but it looks acceptable to flush all TBs and fall back to
> current non-cross-page implementation during debugging? I think It's
> different from the full system situation here:
> https://gitlab.com/qemu-project/qemu/-/issues/404
>
> * mprotect. If the 2nd page remains 'X' permission after mprotect, the
> chain is still valid, if it's changed to non-X, then the syscall
> interceptor will change the permission of corresponding host page to
> non-X, it will be segfault as expected?
>
> * mmap. I cannot figure out the situation. Is there any unit test for
> this, or could you please shed some light?
Also munmap, but handled via the same path through page_set_flags, see
if (inval_tb) {
tb_invalidate_phys_range(start, end);
}
There is no unit test for mmap over an existing code page.
I believe we do have one for mprotect.
You could plausibly add a global variable choosing between link-all-pages and
link-one-page modes; it would be protected by mmap_lock. For link-all-pages mode, the
above tb_invalidate_phys_range becomes tb_flush. We probably want to start in
link-one-page mode if gdbstub is active, which is the only way to set breakpoints in
user-only mode.
I expect mprotect/mmap over existing executable pages to be extremely rare. I expect
munmap of existing executable pages to be rare-ish, with dlclose() being the most common
case. You might wish to change from link-all-pages mode to link-one-page mode after one
or more instances.
And as I said, this discussion should happen on qemu-devel.
r~
next parent reply other threads:[~2023-03-14 18:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <b160a8f7-10b0-5674-a040-b11ca4aed3c9@intel.com>
[not found] ` <714313d8-7828-196b-50ac-fe12d2143135@linaro.org>
[not found] ` <12e54d71-e208-507c-c9d2-c313f9301fc3@intel.com>
2023-03-14 18:15 ` Richard Henderson [this message]
2023-03-16 2:07 ` [PATCH v2 01/28] accel/tcg: Introduce translator_use_goto_tb Wu, Fei
2023-03-16 3:07 ` Wu, Fei
2021-06-30 18:31 [PATCH v2 00/28] " Richard Henderson
2021-06-30 18:31 ` [PATCH v2 01/28] " 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=db955647-d769-e9fa-b314-6a3ee16b0b95@linaro.org \
--to=richard.henderson@linaro.org \
--cc=fei2.wu@intel.com \
--cc=qemu-devel@nongnu.org \
/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).