From: Keir Fraser <keir.fraser@eu.citrix.com>
To: James Harper <james.harper@bendigoit.com.au>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: "Iomem mapping not permitted" during windows crash dump under GPLPV
Date: Sat, 30 Jan 2010 08:23:05 +0000 [thread overview]
Message-ID: <C7899CE9.D310%keir.fraser@eu.citrix.com> (raw)
In-Reply-To: <AEC6C66638C05B468B556EA548C1A77D01898E1C@trantor>
It's not really an i/o page. All 1s means INVALID_MFN, which means the p2m
lookup failed. I suppose Windows may think it is a valid pfn (e.g., an
emulated device?) but that kind of mem can't be granted and never could be.
-- Keir
On 30/01/2010 05:26, "James Harper" <james.harper@bendigoit.com.au> wrote:
> I've recently noticed that my windows crash dumps fail at around 40-50%
> under GPLPV. 'xm dmesg' shows the following:
>
> (XEN) grant_table.c:350:d0 Iomem mapping not permitted ffffffffffffffff
> (domain 865)
>
> At first I thought that the cause was just a bug in my grant ref code
> but it just occurred to me that this could be happening when Windows
> tries to write out the physical page I have mapped for some other xen
> function. grant_table.c:350 is around here:
>
> if ( !iomem_access_permitted(rd, frame, frame) )
> {
> gdprintk(XENLOG_WARNING,
> "Iomem mapping not permitted %lx (domain %d)\n",
> frame, rd->domain_id);
> rc = GNTST_general_error;
> goto undo_out;
> }
>
> So is that likely to be the cause? I haven't yet checked the pfn that is
> failing against the pages I've mapped for various things but the number
> seems plausible. It used to work... is that check new under 3.4.1-ish?
>
> And whats the solution? At this stage the only think I can think of is
> that it might be reasonable to ignore a small amount of failed writes
> during a crash dump... I haven't yet researched if there is a way to
> tell windows not to write out a given page of memory when doing a crash
> dump.
>
> Thanks
>
> James
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
next prev parent reply other threads:[~2010-01-30 8:23 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-30 5:26 "Iomem mapping not permitted" during windows crash dump under GPLPV James Harper
2010-01-30 8:23 ` Keir Fraser [this message]
2010-01-30 8:30 ` James Harper
2010-01-30 9:33 ` Keir Fraser
2010-02-02 10:24 ` Paul Durrant
2010-02-02 10:47 ` James Harper
2010-02-02 11:02 ` Paul Durrant
2010-02-02 11:07 ` James Harper
2010-02-02 11:27 ` Jan Beulich
2010-02-02 13:30 ` Keir Fraser
2010-02-02 13:58 ` Tim Deegan
2010-02-02 16:54 ` Paul Durrant
2010-02-02 17:15 ` Tim Deegan
2010-02-02 18:08 ` Paul Durrant
2010-02-02 22:01 ` "Iomem mapping not permitted" during windows crashdump " James Harper
2010-02-02 14:26 ` "Iomem mapping not permitted" during windows crash dump " Jan Beulich
2010-02-02 14:33 ` Keir Fraser
2010-02-02 20:32 ` Steven Smith
2010-02-02 21:57 ` James Harper
2010-02-02 11:34 ` Paul Durrant
2010-02-02 11:41 ` James Harper
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=C7899CE9.D310%keir.fraser@eu.citrix.com \
--to=keir.fraser@eu.citrix.com \
--cc=james.harper@bendigoit.com.au \
--cc=xen-devel@lists.xensource.com \
/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).