qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Artyom Tarasenko <atar4qemu@googlemail.com>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: [Qemu-devel] Re: sparc solaris guest, hsfs_putpage: dirty HSFS page
Date: Tue, 26 Jan 2010 23:42:13 +0100	[thread overview]
Message-ID: <fb8d4f71001261442l43a5b85em76d8f5d4595cbbfe@mail.gmail.com> (raw)
In-Reply-To: <f43fc5581001261123o5ff1d780y636404350561efb1@mail.gmail.com>

2010/1/26 Blue Swirl <blauwirbel@gmail.com>:
> On Tue, Jan 26, 2010 at 7:03 PM, Artyom Tarasenko
> <atar4qemu@googlemail.com> wrote:
>> 2010/1/24 Blue Swirl <blauwirbel@gmail.com>:
>>> 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 buckets 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 similar.
>>>>
>>>> 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) == 1) {
>>>>                cmn_err(CE_NOTE,
>>>>                            "hsfs_putpage: dirty HSFS page");
>>>>
>>>> Now the question: does the problem have to do with qemu caches (non-)emulation?
>>>> 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.

update !=always set. Where is it implemented? I guess the code is
shared between multiple architectures.
Is there a way to trace at what point certain page is getting dirty?

Since it's not the bypass ASIs it must be something else.

>>> 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.


-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/

  reply	other threads:[~2010-01-26 22:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-24  0:02 [Qemu-devel] sparc solaris guest, hsfs_putpage: dirty HSFS page Artyom Tarasenko
2010-01-24  8:56 ` [Qemu-devel] " Blue Swirl
2010-01-26 17:03   ` Artyom Tarasenko
2010-01-26 19:23     ` Blue Swirl
2010-01-26 22:42       ` Artyom Tarasenko [this message]
2010-01-27 18:01         ` Blue Swirl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fb8d4f71001261442l43a5b85em76d8f5d4595cbbfe@mail.gmail.com \
    --to=atar4qemu@googlemail.com \
    --cc=blauwirbel@gmail.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).