From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NZr0i-0000vy-Ff for qemu-devel@nongnu.org; Tue, 26 Jan 2010 14:23:36 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NZr0e-0000vT-RF for qemu-devel@nongnu.org; Tue, 26 Jan 2010 14:23:36 -0500 Received: from [199.232.76.173] (port=52133 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NZr0e-0000vP-LQ for qemu-devel@nongnu.org; Tue, 26 Jan 2010 14:23:32 -0500 Received: from mail-px0-f189.google.com ([209.85.216.189]:43193) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NZr0d-0000pF-Bc for qemu-devel@nongnu.org; Tue, 26 Jan 2010 14:23:32 -0500 Received: by pxi27 with SMTP id 27so3310632pxi.4 for ; Tue, 26 Jan 2010 11:23:24 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: From: Blue Swirl Date: Tue, 26 Jan 2010 21:23:04 +0200 Message-ID: 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: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Artyom Tarasenko Cc: qemu-devel On Tue, Jan 26, 2010 at 7:03 PM, Artyom Tarasenko wrote: > 2010/1/24 Blue Swirl : >> On Sun, Jan 24, 2010 at 2:02 AM, Artyom Tarasenko >> wrote: >>> All solaris versions which currently boot (from cd) regularly produce b= uckets 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 sim= ilar. >>> >>> Now in the OpenSolaris source code there is a nice comment: >>> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/commo= n/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-)em= ulation? >>> 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 > > why bypass stores? What about the non-bypass ones? Because their use should update the PTE dirty bits. >> should use >> st[bwlq]_phys_notdirty. > > Seems that st[bw]_phys_notdirty are not implemeted yet? > > I've changed [lq] for asi 0x20 and 21-2f and see no difference. Also I > put some debug printfs and see that none of these ASIs is called after > the Solaris kernel is loaded. > >> It can break display handling, though. > > > -- > Regards, > Artyom Tarasenko > > solaris/sparc under qemu blog: http://tyom.blogspot.com/ >