From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NYyHX-0006R0-K4
	for qemu-devel@nongnu.org; Sun, 24 Jan 2010 03:57:19 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NYyHS-0006QV-Su
	for qemu-devel@nongnu.org; Sun, 24 Jan 2010 03:57:19 -0500
Received: from [199.232.76.173] (port=47121 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NYyHS-0006QS-NA
	for qemu-devel@nongnu.org; Sun, 24 Jan 2010 03:57:14 -0500
Received: from mail-pz0-f190.google.com ([209.85.222.190]:58379)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <blauwirbel@gmail.com>) id 1NYyHS-0002N3-AJ
	for qemu-devel@nongnu.org; Sun, 24 Jan 2010 03:57:14 -0500
Received: by pzk28 with SMTP id 28so1048566pzk.4
	for <qemu-devel@nongnu.org>; Sun, 24 Jan 2010 00:57:13 -0800 (PST)
MIME-Version: 1.0
In-Reply-To: <fb8d4f71001231602n1c6cdf85j26fbd102d179e851@mail.gmail.com>
References: <fb8d4f71001231602n1c6cdf85j26fbd102d179e851@mail.gmail.com>
From: Blue Swirl <blauwirbel@gmail.com>
Date: Sun, 24 Jan 2010 10:56:53 +0200
Message-ID: <f43fc5581001240056o136a8bc3qaa2b6c6c4a6ab684@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: [Qemu-devel] Re: sparc solaris guest, hsfs_putpage: dirty HSFS page
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: Artyom Tarasenko <atar4qemu@googlemail.com>
Cc: qemu-devel <qemu-devel@nongnu.org>

On Sun, Jan 24, 2010 at 2:02 AM, Artyom Tarasenko
<atar4qemu@googlemail.com> wrote:
> All solaris versions which currently boot (from cd) regularly produce buc=
kets of
> "hsfs_putpage: dirty HSFS page" messages.
>
> High Sierra is a pretty old and stable stuff, so it is possible that
> the code is similar to OpenSolaris.
> I looked in debugger, and the function calls hierarchy looks pretty simil=
ar.
>
> Now in the OpenSolaris source code there is a nice comment:
> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/=
fs/hsfs/hsfs_vnops.c#1758
> /*
> * Normally pvn_getdirty() should return 0, which
> * impies that it has done the job for us.
> * The shouldn't-happen scenario is when it returns 1.
> * This means that the page has been modified and
> * needs to be put back.
> * Since we can't write on a CD, we fake a failed
> * I/O and force pvn_write_done() to destroy the page.
> */
> if (pvn_getdirty(pp, flags) =3D=3D 1) {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cmn_err(CE_NOTE,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0"hsfs_putpage: dirty HSFS page");
>
> Now the question: does the problem have to do with qemu caches (non-)emul=
ation?
> Can it be that we mark non-dirty pages dirty? Or does qemu always mark
> pages dirty exactly to avoid cache emulation?
>
> Otherwise it means something else goes astray and Solaris guest really
> modifies the pages it shouldn't.
>
> Just wonder what to dig first, MMU or IRQ emulation (the two most
> obvious suspects).

Maybe the stores via MMU bypass ASIs should use
st[bwlq]_phys_notdirty. It can break display handling, though.