xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@novell.com>
To: Cris Daniluk <cris.daniluk@gmail.com>,
	Jeremy Fitzhardinge <jeremy@goop.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir.fraser@eu.citrix.com>
Subject: Re: Xen 4.0 crashes with pvops kernel
Date: Tue, 15 Jun 2010 14:57:45 +0100	[thread overview]
Message-ID: <4C17A2F9020000780000688F@vpn.id2.novell.com> (raw)
In-Reply-To: <4C179A47020000780000683A@vpn.id2.novell.com>

>>> On 15.06.10 at 15:20, "Jan Beulich" <JBeulich@novell.com> wrote:
>>>> On 15.06.10 at 14:56, Keir Fraser <keir.fraser@eu.citrix.com> wrote:
>> On 15/06/2010 13:50, "Jan Beulich" <JBeulich@novell.com> wrote:
>> 
>>> But even if we verify that the references come from some ACPI
>>> method(s), likely the only way to address this is to fix the kernel
>>> side error handling.
>>> 
>>> Keir, assuming these are reads only, would it make sense to permit
>>> Dom0 to map the IO-APIC space read-only? Perhaps even
>>> transparently converting writeable mappings to read-only ones
>>> (since drivers/acpi/osl.c tries to establish writeable mappings
>>> irrespective of the actual needs)? The obvious danger in doing
>>> so is that going forward there may appear fields in that page
>>> reads of which aren't side effect free...
>> 
>> Well, how come it works with other Linux kernels -- presumably they have
>> some extra error handling in the ACPI subsystem? Shouldn't that just be
>> added to this kernel?
> 
> I'm rather suspecting there's new code (compared to 2.6.18) that's
> lacking proper error handling, though I didn't look in detail so far.
> 
> Hmm, looking a little more closely it seems they indeed try to write
> to that space - this we for sure can't allow. I'll see if I can follow
> the code path (unfortunately the stack trace is an imprecise one).

Actually, that's a difference to non-pv-ops that I strongly
believe should be fixed: While in the traditional kernel
__direct_remap_pfn_range() is used to establish I/O memory
mappings (and hence there is a way to propagate errors), the
pv-ops kernel appears to use ioremap_page_range() - just like
native - which can only return -ENOMEM (upon page table
allocation failure), due to the lack of a return value from
set_pte_at().

But then again I must be missing something here, since
xen_set_pte_at() falls back to xen_set_pte() if the hypercall
it tries first fails, and that one would fault when establishing
the mapping, not when trying to first use it. Jeremy?

Jan

  parent reply	other threads:[~2010-06-15 13:57 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-14 22:10 Xen 4.0 crashes with pvops kernel Cris Daniluk
2010-06-15  6:54 ` Jan Beulich
     [not found]   ` <AANLkTimslcbXQnihpIB0c-ceWbD7H-eyUY_BV2igyfzv@mail.gmail.com>
2010-06-15 12:50     ` Jan Beulich
2010-06-15 12:56       ` Keir Fraser
2010-06-15 13:20         ` Jan Beulich
2010-06-15 13:24           ` Cris Daniluk
2010-06-15 13:43             ` Jan Beulich
2010-06-15 13:49               ` Cris Daniluk
2010-06-15 14:13                 ` Jan Beulich
2010-06-15 14:35                   ` Cris Daniluk
2010-06-15 14:58                     ` Jan Beulich
2010-06-15 15:01                       ` Cris Daniluk
2010-06-15 15:21                         ` Jan Beulich
2010-06-15 16:18                           ` Boris Derzhavets
2010-06-15 14:17               ` Pasi Kärkkäinen
2010-06-15 15:11                 ` Konrad Rzeszutek Wilk
2010-06-16 14:42                   ` Jan Beulich
2010-06-15 13:57           ` Jan Beulich [this message]
2010-06-15 15:15             ` Konrad Rzeszutek Wilk
2010-06-16 14:36               ` Jan Beulich
2010-06-24  9:29             ` Jeremy Fitzhardinge
2010-06-24 11:30               ` Jan Beulich
2010-06-24 21:25                 ` Jeremy Fitzhardinge

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=4C17A2F9020000780000688F@vpn.id2.novell.com \
    --to=jbeulich@novell.com \
    --cc=cris.daniluk@gmail.com \
    --cc=jeremy@goop.org \
    --cc=keir.fraser@eu.citrix.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).