From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33)
	id 1CSfPB-0001Ry-8s
	for qemu-devel@nongnu.org; Fri, 12 Nov 2004 12:40:13 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33)
	id 1CSfPA-0001RJ-2Z
	for qemu-devel@nongnu.org; Fri, 12 Nov 2004 12:40:12 -0500
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.33) id 1CSfP9-0001RG-Td
	for qemu-devel@nongnu.org; Fri, 12 Nov 2004 12:40:12 -0500
Received: from [193.49.184.17] (helo=gip.u-picardie.fr)
	by monty-python.gnu.org with esmtp (Exim 4.34) id 1CSfG2-0006Nd-Oz
	for qemu-devel@nongnu.org; Fri, 12 Nov 2004 12:30:46 -0500
From: "Olivier Cozette" <olivier.cozette@u-picardie.fr>
Subject: RE : Another related question Re: [Qemu-devel] Question about softmmu
Date: Fri, 12 Nov 2004 18:30:52 +0100
Message-ID: <002e01c4c8dd$5b7cce10$f618100a@Olivier>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <1100161300.41932114cac38@webaccess.umail.ucsb.edu>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: 'Ye Wen' <wen@umail.ucsb.edu>
Cc: qemu-devel@nongnu.org

	I Ye,


I understand your problem, but in this case, you must change the mapping =
and
so you must send this change to the processor (access special memory,
explicitly invalidate one page), so the page is flushed
(tlb_flush_page/exec.c) and all tb in this page are invalidate
(tb_invalidate/exec.c). So tb_invalidate delete all tb that call this =
tb.
This function deletes all jmp to this tb.=20

So, in my opinion, you problem won't occur.


	Olivier


>Actually I'm thinking of a special case:
>1. A basic block is translated and the PC value patched in is
>   the virtual address when it is translated. At this time,
>   the address mapping is virtual page 0 -> physical page 0
>2. Now the mapping changes. virtual page 1 -> physical page 0,
>   which means the physical location of the block doesn't change
>   but its virtual address changes.
>3. Since page table changes, the virtual pc hash flushed. But we
>   still can find the block using physical hash.
>4. Now the block is executed again. But since the embedded pc value
>   is still the old value, will this cause problem?