| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: Interaction between Xen and XFS: stray RW mappings
|
To: |
Andi Kleen <andi@xxxxxxxxxxxxxx> |
|
Subject: |
[Xen-devel] Re: Interaction between Xen and XFS: stray RW mappings |
|
From: |
Nick Piggin <nickpiggin@xxxxxxxxxxxx> |
|
Date: |
Tue, 16 Oct 2007 00:56:46 +1000 |
|
Cc: |
Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, David Chinner <dgc@xxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Morten Bøgeskov <xen-users@xxxxxxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx, xfs-masters@xxxxxxxxxxx, Mark Williamson <mark.williamson@xxxxxxxxxxxx> |
|
Delivery-date: |
Mon, 15 Oct 2007 04:02:40 -0700 |
|
Domainkey-signature: |
a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=Received:X-YMail-OSG:From:To:Subject:Date:User-Agent:Cc:References:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id; b=PK5VT20zB8mpzQk1dP7cU2cmUpxCyjh1ydXDKL1ssj8aib32xSwpw7Z7m0Jt0IadfGiEqHfyY8izA2mGuYmNN6HcElfXQvId5r7nC8No2+IFbfYRTZhg8bCaswvMh/cB1hVYe3pFitnskVGpjvVePz8W65/mVu2VD/JIXjkeI30= ; |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<p731wbw4t3h.fsf@xxxxxxxxxxxxxx> |
|
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
|
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
|
List-post: |
<mailto:xen-devel@lists.xensource.com> |
|
List-subscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
|
List-unsubscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
|
References: |
<470FA7C3.90404@xxxxxxxx> <20071014225618.GN23367404@xxxxxxx> <p731wbw4t3h.fsf@xxxxxxxxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
User-agent: |
KMail/1.9.5 |
On Monday 15 October 2007 19:36, Andi Kleen wrote:
> David Chinner <dgc@xxxxxxx> writes:
> > And yes, we delay unmapping pages until we have a batch of them
> > to unmap. vmap and vunmap do not scale, so this is batching helps
> > alleviate some of the worst of the problems.
>
> You're keeping vmaps around for already freed pages?
> That will be a big problem for proper PAT support, which needs
> to track all mappings to memory. It's not just a problem for Xen.
>
> In fact I suspect it is already broken with DRM or AGP for example which
> can use UC and WC mappings -- if you keep the mapping around and
> DRM or AGP turns the page in another mapping uncacheable you're
> creating an illegal cache attribute alias. These are known to occasionally
> create cache corruptions on several x86s; giving ___VERY___ hard to debug
> bugs once a blue moon.
Is this true even if you don't write through those old mappings?
Is DRM or AGP then not also broken with lazy highmem flushing, or
how do they solve that?
> Probably it'll require some generic VM batching mechanism where
> Xen or PAT code can hook into the list or force unmap the mappings
> as needed.
Definitely.
> Definitely needs to be fixed if true. You're lucky that Xen caught it
> in time.
I've been thinking that a simple debug mode could be a good idea.
Have a new field in the struct page to count the number of possible
unflushed mappings to the page so that things like PAT could go
BUG_ON appropriate conditions. Would that be helpful?
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home