From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:33442)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <real@ispras.ru>) id 1ZHVQm-0002hK-Sl
	for qemu-devel@nongnu.org; Tue, 21 Jul 2015 07:09:53 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <real@ispras.ru>) id 1ZHVQj-0000Ku-Mt
	for qemu-devel@nongnu.org; Tue, 21 Jul 2015 07:09:52 -0400
Received: from smtp.ispras.ru ([83.149.199.79]:47190)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <real@ispras.ru>) id 1ZHVQj-0000Ht-Fc
	for qemu-devel@nongnu.org; Tue, 21 Jul 2015 07:09:49 -0400
Message-ID: <55AE287C.5070801@ispras.ru>
Date: Tue, 21 Jul 2015 14:09:48 +0300
From: =?UTF-8?B?0JXRhNC40LzQvtCyINCS0LDRgdC40LvQuNC5?= <real@ispras.ru>
MIME-Version: 1.0
References: <1437389593-15297-1-git-send-email-real@ispras.ru>
	<55ADF8CB.8050500@redhat.com>
In-Reply-To: <55ADF8CB.8050500@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [PATCH v2] PAM: make PAM emulation closer to
	documentation
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org
Cc: Kirill Batuzov <batuzovk@ispras.ru>, "Michael S. Tsirkin" <mst@redhat.com>

21.07.2015 10:46, Paolo Bonzini =D0=BF=D0=B8=D1=88=D0=B5=D1=82:

> Out of curiosity, would it be necessary to flush the TLB when the PAM
> registers change?
>
> In QEMU, the TLB also has the function of a cache in some sense
> (because, by pointing to a ram_addr_t, it prevents reads, writes or
> fetches from going through the slow MMIO path).
There is exec.c: tcg_commit callback. It calls
cpu-exec.c: cpu_reload_memory_map that calls cputlb.c:tlb_flush.

When PAM register is changed pam_update is called. Its call is
surrounded by memory_region_transaction_begin/_commit couple both in
i440fx and MCH9 host bridges. tcg_commit and pam_mem_commit are called
during memory_region_transaction_commit execution.

To summarize:
- TLB is flushed by existing code.
- Should I remove pam_update_redirection call from pam_set_current?
It will be called by pam_mem_commit soon? Note that a PAM API user
should call memory_region_transaction_begin/_commit in this case.
>
> Paolo
>
Vasily