WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] Re: [Xen-users] rebased openSUSE Xen dom0 Patches

To: "Jan Beulich" <JBeulich@xxxxxxxxxx>, "Andrew Lyon" <andrew.lyon@xxxxxxxxx>
Subject: RE: [Xen-devel] Re: [Xen-users] rebased openSUSE Xen dom0 Patches
From: "Simon Graham" <simon.graham@xxxxxxxxxxxxxxxxxxx>
Date: Mon, 19 Apr 2010 09:52:44 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 19 Apr 2010 07:53:44 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4BCC335C020000780003ACD0@xxxxxxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <BC8BC73D12649F439B502B4CB6FD58B10148E4A4@xxxxxxxxxxxxxxxxxxxxx> <4BC834C4020000780003A947@xxxxxxxxxxxxxxxxxx> <BC8BC73D12649F439B502B4CB6FD58B10148E91C@xxxxxxxxxxxxxxxxxxxxx> <4BCC335C020000780003ACD0@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcrfnCCKhTI5g6I5T/iYrwLaUYQeXwAMMvXQ
Thread-topic: [Xen-devel] Re: [Xen-users] rebased openSUSE Xen dom0 Patches
> >in turn means the page cant be turned into a page table page? Or is
> >there some other magic that occurs later on that should decrement the
> >page type ref count before attempting to use the page as a page table
> >page?
> 
> Are you observing this with both the .31 and .32 patches?
> 

We're only testing the .32 patches.

> >Here's the extract of the code I am talking about (yes, we are using
a
> >64-bit Dom0):
> >...
> 
> But that code is precisely what guarantees that the pages *can* be
> converted to page table pages (by completely unmapping them from
> the kernel image part of the address space). So your explanation is
> rather confusing than clarifying to me...

I agree that that is the intent of this code -- what we _seem_ to
observe (and this
is hard to prove) is that the page type ref count is not being
decremented by this
code which would imply that the unmapping is not happening for some
reason. The only
real evidence I have for this is that the failure always occurs on one
of these pages.

Now, the first of these hypercalls creates a pte with PAGE_KERNEL as the
opts and
I think this includes read-write access whereas the second one
completely deletes
the pte for the alternate mapping -- the combined affect should leave
the page type 
ref count as one shouldn't it? (for the read-write kernel mapping)

That being the case, I'm not sure how the page type ref count is
supposed to get to
zero when reusing one of these pages as a page table page later on.

Thanks for your help
Simon

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