From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@novell.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: bogus check in get_page_from_l1e()?
Date: Tue, 08 Mar 2011 15:19:04 +0000 [thread overview]
Message-ID: <C99BF968.144FE%keir.xen@gmail.com> (raw)
In-Reply-To: <4D761C0D0200007800035236@vpn.id2.novell.com>
On 08/03/2011 11:07, "Jan Beulich" <JBeulich@novell.com> wrote:
> Keir,
>
> in the I/O page code path, we have
>
> if ( !iomem_access_permitted(pg_owner, mfn, mfn) )
> {
> if ( mfn != (PADDR_MASK >> PAGE_SHIFT) ) /* INVALID_MFN? */
> MEM_LOG("Non-privileged (%u) attempt to map I/O space %08lx",
> pg_owner->domain_id, mfn);
> return 0;
> }
>
> What is the reason to suppress the warning for the one specific
> (PADDR_MASK >> PAGE_SHIFT) MFN value, i.e. where could this
> validly come from and hence warrant not to issue the warning?
>
> Also, the message seems to be having the potential of being
> misleading (these days at least, but perhaps it always was), as
> it clearly is possible for Dom0 to also be denied a mapping here
> (and hence the "Non-privileged" can be wrong).
>
> Bottom line question: Should we issue the warning unconditionally,
> just stating the domain ID?
Long time a go, but ISTR that some PV guests (e.g., some versions of our
Linux patches) would attempt to map things during boot that they may not
have access to, and this would manifest as failed attempt to map
INVALID_MFN. Since it's not a genuine real I/O address that is failing to be
mapped, it also seems not so useful to log it.
That said, I'd be open to removing the check if it turns out that these days
failed mappings of INVALID_MFN never 'legitimately' happen. I'm skeptical of
that though.
-- Keir
> Thanks, Jan
>
prev parent reply other threads:[~2011-03-08 15:19 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-08 11:07 bogus check in get_page_from_l1e()? Jan Beulich
2011-03-08 15:19 ` Keir Fraser [this message]
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=C99BF968.144FE%keir.xen@gmail.com \
--to=keir.xen@gmail.com \
--cc=JBeulich@novell.com \
--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).