From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5229AC4361B for ; Mon, 7 Dec 2020 10:12:23 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 996D22311A for ; Mon, 7 Dec 2020 10:12:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 996D22311A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=free.fr Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:57672 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kmDVF-0004IP-HZ for qemu-devel@archiver.kernel.org; Mon, 07 Dec 2020 05:12:21 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:52062) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kmDTg-0003Pv-Sm for qemu-devel@nongnu.org; Mon, 07 Dec 2020 05:10:44 -0500 Received: from smtp5-g21.free.fr ([2a01:e0c:1:1599::14]:16024) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kmDTe-000748-Pv for qemu-devel@nongnu.org; Mon, 07 Dec 2020 05:10:44 -0500 Received: from wise (unknown [77.159.208.71]) (Authenticated sender: stephane.duverger@free.fr) by smtp5-g21.free.fr (Postfix) with ESMTPSA id AE73B5FFD8; Mon, 7 Dec 2020 11:10:32 +0100 (CET) Date: Mon, 7 Dec 2020 11:10:29 +0100 From: Stephane Duverger To: Richard Henderson , qemu-devel@nongnu.org Subject: Re: x86 TCG helpers clobbered registers Message-ID: <20201207101029.GA96540@wise> References: <20201204153446.GA66154@wise> <1d246e29-b364-099f-440c-5b644087b55f@linaro.org> <20201205013402.GA69224@wise> <5718f49e-8e17-17ae-45ec-94347f0a009d@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5718f49e-8e17-17ae-45ec-94347f0a009d@linaro.org> Received-SPF: none client-ip=2a01:e0c:1:1599::14; envelope-from=stephane.duverger@free.fr; helo=smtp5-g21.free.fr X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Paolo Bonzini Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Sat, Dec 05, 2020 at 06:38:25AM -0600, Richard Henderson wrote: > The difference is that the slow path is aware that there are input registers > that are live, containing data (addrlo, addrhi, datalo, datahi), which must be > stored into the arguments for the slow path call. Those input registers (and > all other call-clobbered registers) are dead *after* the slow path call. > > You are injecting your filter call while those input registers are still live. > They will be next used by the fast-path store. > > That is a very significant difference. Ok. That's why I saved REG_L1 (prepared by tlb_load) for both st/ld_direct use, plus datalo for st_direct only. I saw datahi is only used for MO_64 on 32bits tcg-target. And I better understand it thanks to you. This leads me to that simple reflection: If we want to filter on every memory accesses, *out of the fast-path*, the most natural place to do so would be in store_helper() and load_helper() from accel/tcg/cputlb.c. By doing so, every target would benefit from filtering, and even specific helpers using cpu_ldst functions would be intercepted. No ? For the remaining fast-path case, it could be interesting to generate it this time at IR level (tlb_load, jne to slow_path, direct load/store) ? Again every target would benefit from filtering without the need for a specific fast-path implementation in tcg//tcg-target.c.inc Wouldn't it be simplier than actual mem plugin implementation, which generate fitler callback *after* load/store and has specific extra work for tracking memory accesses performed from helpers (afaiu) ?