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: [PATCH] fix ia64 breakage with PHYSDEVOP_pirq_eoi_mfn (was Re: [Xen-

To: Jan Beulich <jbeulich@xxxxxxxxxx>
Subject: Re: [PATCH] fix ia64 breakage with PHYSDEVOP_pirq_eoi_mfn (was Re: [Xen-devel] [PATCH 2/2] linux/x86: use shared page indicating the need for an EOI notification)
From: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Date: Tue, 9 Dec 2008 19:43:10 +0900
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Tue, 09 Dec 2008 02:43:36 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <493E50D7.76E4.0078.0@xxxxxxxxxx>
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: <493D30D6.76E4.0078.0@xxxxxxxxxx> <20081209034038.GO5454%yamahata@xxxxxxxxxxxxx> <493E50D7.76E4.0078.0@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.6i
On Tue, Dec 09, 2008 at 10:04:55AM +0000, Jan Beulich wrote:
> >>> Isaku Yamahata <yamahata@xxxxxxxxxxxxx> 09.12.08 04:40 >>>
> >Sorry for breakage.
> >How about moving arbitrary_virt_to_machine() from pgtable.h to maddr.h?
> >(Yes, this is a work around. and you wouldn't like it...)
> 
> No, that wouldn't work for x86 either, because the macro uses
> lookup_address(), which in turn is also only declared in pgtable.h. I
> wouldn't really mind moving arbitrary_virt_to_machine(), but it would
> then require duplicating (not moving) the lookup_address() declaration.
> 
> >> Looking at how ia64 defines virt_to_machine() at present I would be
> >> inclined to say that all current users (tpmfront, blktap, and gntdev) of
> >> that macro don't get what they expect, and the implementation you
> >> added for arbitary_virt_to_machine() really ought to be the one for
> >> virt_to_machine(), given your description above.
> >
> >Looking the x86 virt_to_machine definition, virt_to_machine()
> >assumes the passed address in the straight mapping area.
> >So the ia64 assumption is same to x86.
> 
> Not exactly: Addresses of kernel objects *can* be passed to
> virt_to_machine() on x86 (minus a supposed compiler issue demanding
> the special __pa_symbol() to be used on x86-64 - I'm trying to find out
> how relevant this still is), but they can't be on ia64. This is what seemed
> wrong to me. But otoh as I understand it you can't pass kernel
> addresses through __pa() either, but (to my surprise) ia64 apparently
> has no problem with this wrt architecture independent code (but making
> necessary work-arounds like paddr_vmcoreinfo_note()).

You are the first person to pass the kernel symbol address
to virt_to_machine() in arch independent code.
Is there any necessity to allocate pirq_needs_eoi statically?
(except it did before)
If no, can we allocate the pages for them dynamically?
Then the issue will go away.


> >Hmm, ia64 and x86_64 have nothing to do with highmem,
> >but x86_32 has to deal with highmem. So x86_32 with highmem
> >seems to have the issue you described above.
> >If ptep which is passed to virt_to_machine is highmem,
> >I don't see how it works. So all virt_to_machine() shouldn't
> >be changed to arbitrary_virt_to_machine()?
> 
> Actually, looking at it a second time, tpmfront uses the result of the result
> of __get_free_page() here, so the address is always in the 1:1 mapping.
> 
> But I think you're quite right about the HIGHPTE implications on blktap and
> gntdev - these ought to be fixed, perhaps indeed by using
> arbitrary_virt_to_machine() there (but I'd want to make this conditional
> upon the HIGHPTE config option, so to not affect performance of other
> configurations: possibly this ought to be an architecture-defined macro
> like ptep_virt_to_machine(), as I wouldn't want to place an x86-specific
> conditional in there that would risk breaking any future supported
> architecture without explicit notice).

Introduce ptep_to_machine() or something like that?

-- 
yamahata

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

<Prev in Thread] Current Thread [Next in Thread>