From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: Xen with dom0 pvops on ultra-recent "git tip" kernel on x86_64 Date: Tue, 20 Jan 2009 12:08:44 -0800 Message-ID: <49762F4C.1040801@goop.org> References: <49690103.5020706@wol.de> <1231619339.5616.15.camel@leto.intern.saout.de> <20090110203706.GW15052@edu.joroinen.fi> <1231622029.4778.1.camel@leto.intern.saout.de> <1231683478.4809.43.camel@leto.intern.saout.de> <1231685561.4809.50.camel@leto.intern.saout.de> <1231691732.5342.3.camel@leto.intern.saout.de> <1231769868.4838.4.camel@leto.intern.saout.de> <1231778480.4742.3.camel@leto.intern.saout.de> <1231838888.4823.5.camel@leto.intern.saout.de> <20090113153302.GZ15052@edu.joroinen.fi> <1231864918.5257.6.camel@leto.intern.saout.de> <1231865847.5257.8.camel@leto.intern.saout.de> <4970C2A7.8010702@goop.org> <1232209746.5342.7.camel@leto.intern.saout.de> <1232309411.5653.16.camel@leto.intern.saout.de> <1232314122.5653.53.camel@leto.intern.saout.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1232314122.5653.53.camel@leto.intern.saout.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Christophe Saout Cc: xen-devel List-Id: xen-devel@lists.xenproject.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