Re: Xen 4.0 crashes with pvops kernel

["Jan Beulich" <JBeulich@novell.com>]

>>> On 24.06.10 at 11:29, Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> On 06/15/2010 02:57 PM, Jan Beulich wrote:
>> 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().
>>   
> 
> So that ioremap() itself will return an error if Xen prevents a mapping?

Exactly.

>> 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?
>>   
> 
> If the pte has _PAGE_IO set (which all ioremap ptes should), then it
> will call xen_set_iomap_pte. This can't fail (not return code), so if

Ah, right, I apparently looked at the upstream (i.e. DomU-only)
implementation rather than your tree.

> the hypercall fails then it will leave it unmapped.  It should at least
> print a warn-on in that case.

Yes, that's the minimal requirement I would say.

Jan