Re: [Xen-devel] Xen with dom0 pvops on ultra-recent "git tip" kernel on x86_64

[Christophe Saout <christophe@xxxxxxxx>]

Hi again,

> and the later dies in the radeon driver with the bad memory / pagetable
> access in radeon_card_posted() in what seems to be the fast attempt to
> do an access to the card's MMIO area.

Uhoh,

diff -u ioremap.c ioremap-xen.c

suggests there is some more work to do. :-(

The native Xen kernel defines io_remap_pfn_range to
direct_remap_pfn_range, whereas !XEN defines it to remap_pfn_range
(which is also the case for the pv_ops kernel at the moment)

I guess that makes io_remap_pfn_range another candidate for a new
paravirt op.

However, in direct_remap_pfn_range() the first two lines are:

       if (xen_feature(XENFEAT_auto_translated_physmap))
               return remap_pfn_range(vma, address, mfn, size, prot);

I guess this is not the case on my system / hypervisor?

If this really has to be implemented, what about this in asm/mmu.h:

typedef struct {
...
#ifdef CONFIG_XEN
        unsigned has_foreign_mappings:1;
#endif
...
} mm_context_t;

There is some logic in the native Xen kernel which prevents a call to
mm_unpin if there are "foreign mappings", i.e. set by
direct_remap_pfn_range.  What's up with that?


Note that I noticed a completely unrelated issue:  After some minutes it
can happen that the AHCI goes dead on me.  Hard disk accesses hang and
in the log there are several tries to revive the controller (resets and
errors) until the kernel at some point decides to panic.

Cheers,
        Christophe



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel