From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: Re: pv_ops & gntdev?
Date: Wed, 04 Mar 2009 07:16:59 -0800
Message-ID: <49AE9B6B.6070301@goop.org>
References: <49A44030.2070709@redhat.com>
	<49A4640E.1000807@goop.org>	<49A470DD.2000008@redhat.com>
	<49A517F6.30005@redhat.com>	<49A58506.2020407@goop.org>
	<49A58FFF.3050604@redhat.com>	<49A5A4BD.7080207@goop.org>
	<49A5B5DD.60309@redhat.com>	<49A5B9AA.7010709@goop.org>
	<49A5BB7E.8030503@redhat.com>	<49A5BC9D.5010801@goop.org>
	<49A5C208.2040509@redhat.com>	<49A5C5FB.6080000@goop.org>
	<49A5C957.7060205@redhat.com>	<49A5CD57.2010300@goop.org>
	<49AC635F.5010906@redhat.com> <49ADB656.7080404@goop.org>
	<49AE396D.2090503@redhat.com> <49AE9592.2060202@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <49AE9592.2060202@redhat.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Xen Development Mailing List <xen-devel@lists.xensource.com>
List-Id: xen-devel@lists.xenproject.org

Gerd Hoffmann wrote:
> Gerd Hoffmann wrote:
>   
>> Jeremy Fitzhardinge wrote:
>>     
>>> Do you have a test program?
>>>       
>
>   
>> usage:
>> qemu -M xenpv -xen-create -uuid $(uuidgen) \
>>   -kernel <bzImage> -initrd <initrd> \
>>   -drive media=disk,if=xen,file=<diskimage> \
>>   -net nic,model=xen,macaddr=<addr> \
>>   -serial <yourconsolehere>
>>     
>
> "-m 256" is needed too.
>
>   
>>>> +    BUG_ON(pgnr >= map->count);
>>>> +    mpte  = (u64)pfn_to_mfn(page_to_pfn(token)) << PAGE_SHIFT;
>>>> +    mpte |= (unsigned long)pte & ~PAGE_MASK;
>>>>   
>>>>         
>>> (!) You're casting pte_t * to unsigned long, masking off the lower bits
>>> then oring them into your pte.  That doesn't look like it will mean very
>>> much...  I guess this explains your not-unmapping bug.
>>>
>>> This should probably be using mfn_pte() anyway:
>>>
>>>     mfn = pfn_to_mfn(page_to_pfn(token));
>>>     pgprot = __pgprot(pte->pte & PTE_FLAGS_MASK);
>>>     mpte = mfn_pte(mfn, pgprot);
>>>       
>> Looks better indeed.  Unclean stuff carried over from 2.6.18 ...
>>     
>
> Well, no.  mpte (bad name indeed) isn't a pte, but the *pointer*
> (machine address) to the pte.
>   

Yes, but it *looks* better ;) Yes, my "cleanup" will have screwed up the 
actual functional parts in that case.   Hiding the PAGE_MASK in a 
tactical application of PAGE_OFFSET will probably help make it clearer.

    J