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

[Jeremy Fitzhardinge <jeremy@goop.org>]

Christophe Saout wrote:
> 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.
>   

Well, I'm taking a different approach for this.  The problem is that 
there's two distinct address spaces: the dom0 pseudo-physical address 
space, and the machine's real physical address space.  When you're 
mapping devices, you need to map the real machine addresses rather than 
the pseudo-phys ones.  When you map with PAGE_IOMAP then the existing 
Xen pte-setup pvops will do the appropriate things to set up a hardware 
mapping.  Therefore, to map devices from userspace, you just need to 
make sure that PAGE_IOMAP gets set appropriately - which is the tricky 
question.

> 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?
>   

You have to remove any foreign mappings (ie, established with a grant 
table operation) before unpinning.  My plan is to do something a bit 
different from this, by using a shadow pagetable to keep track of the 
grant references, and use a page flag in the pgd when there's a grant 
reference present in a pagetable (which is uncommon).

> 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.
>   

Yes, that's an open mystery.  For me AHCI fails immediately (fails to 
probe drives).  Others have varying degrees of success.  Several minutes 
uptime is very good.

    J