From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45297) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBclV-000276-7B for qemu-devel@nongnu.org; Sat, 24 Mar 2012 22:01:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SBclT-0005Be-7p for qemu-devel@nongnu.org; Sat, 24 Mar 2012 22:01:04 -0400 Received: from mail-bk0-f45.google.com ([209.85.214.45]:56701) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBclS-0005BJ-Ut for qemu-devel@nongnu.org; Sat, 24 Mar 2012 22:01:03 -0400 Received: by bkcjg9 with SMTP id jg9so3945514bkc.4 for ; Sat, 24 Mar 2012 19:00:59 -0700 (PDT) Message-ID: <4F6E7C4E.9090409@gmail.com> Date: Sun, 25 Mar 2012 06:00:46 +0400 From: Max Filippov MIME-Version: 1.0 References: <4F671F55.4050004@redhat.com> <4F673DEE.3040508@redhat.com> In-Reply-To: <4F673DEE.3040508@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Xtensa misuse of tb_invalidate_phys_page_range()? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Jan Kiszka , qemu-devel >>> void HELPER(wsr_ibreaka)(uint32_t i, uint32_t v) >>> { >>> if (env->sregs[IBREAKENABLE]& (1<< i)&& env->sregs[IBREAKA + i] >>> != v) { >>> tb_invalidate_phys_page_range( >>> env->sregs[IBREAKA + i], env->sregs[IBREAKA + i] + 1, 0); >>> tb_invalidate_phys_page_range(v, v + 1, 0); >>> } >>> env->sregs[IBREAKA + i] = v; >>> } >>> >>> tb_invalidate_phys_page_range() expects a virtual address in user mode, >>> and a ram_addr_t in system mode. I'm guessing that v is a virtual address? >> >> Yes, it's a virtual address here, as well as in wsr_lbeg/wsr_lend helpers. >> I made a test for it and it actually fails. I wonder how could it stay unnoticed >> that long :() > > There are many silent breakages like that, don't worry. > >>> This needs to be fixed for system mode if so (and in any case - even if >>> it's a physical address, it needs to be translated to a ram_addr_t). >> >> Sure. Will try to fix it, though it's completely unclear to me now >> how to do it efficiently. > > Since I'm rewriting this area, don't worry about efficiency. Let's get > it correct and after the rewrite we can reexamine efficiency. > > I imagine you'll need something like breakpoint_invalidate(). The following RFC patch takes the obvious approach of sharing the breakpoint_invalidate implementation to address this issue. But if we're talking about correctness it's not 100% correct, because guest TLB is independent of both instruction breakpoints and zero overhead loops, and at the moment of TB invalidation relevant TLB mapping may not exist. Even if we managed to record physical addresses of TBs at the current IBREAKA/LEND, it's not enough because we need to invalidate TBs both at the old and at the new IBREAKA/LEND virtual addresses. What do you think, do we need yet another address-to-TB map? -- Thanks. -- Max