From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NZopN-0004bz-1P for qemu-devel@nongnu.org; Tue, 26 Jan 2010 12:03:45 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NZopG-0004XU-Kn for qemu-devel@nongnu.org; Tue, 26 Jan 2010 12:03:43 -0500 Received: from [199.232.76.173] (port=45103 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NZopG-0004XJ-CB for qemu-devel@nongnu.org; Tue, 26 Jan 2010 12:03:38 -0500 Received: from mail-pw0-f43.google.com ([209.85.160.43]:53486) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NZopF-0000MW-Um for qemu-devel@nongnu.org; Tue, 26 Jan 2010 12:03:38 -0500 Received: by pwj11 with SMTP id 11so3397431pwj.2 for ; Tue, 26 Jan 2010 09:03:36 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: From: Artyom Tarasenko Date: Tue, 26 Jan 2010 18:03:16 +0100 Message-ID: Content-Type: text/plain; charset=ISO-8859-1 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: Blue Swirl Cc: qemu-devel 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 bu= ckets 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 simi= lar. >> >> 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) { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cmn_err(CE_NOTE, >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"hsfs_putpage: di= rty HSFS page"); >> >> Now the question: does the problem have to do with qemu caches (non-)emu= lation? >> 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? > 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. --=20 Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/