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)

[Isaku Yamahata <yamahata@xxxxxxxxxxxxx>]

On Mon, Dec 08, 2008 at 01:36:06PM +0000, Jan Beulich wrote:
> >>> Isaku Yamahata <yamahata@xxxxxxxxxxxxx> 03.12.08 10:20 >>>
> >Yes, you're correct. In fact I had the patch which you suggested,
> >but I was hesitated to change the x86 implementation so that
> >I had changed it to use virt_to_bus() on x86.
> >
> >
> >
> >evtchn, physdev: fix pirq_eoi_mfn for IA64 support.
> >
> >On ia64, global variables aren't in identity mapping area (i.e. kaddr)
> >so that there is no relationship between its virtual address and
> >its physical address. Thus virt_to_bus() can't be applied to them.
> >So introduce arbitrary_virt_to_bus() to wrap arch dependent function
> >and make use of it.
> 
> I needed to look into this again, because the use of 
> arbitary_virt_to_machine()
> in drivers/xen/core/evtchn.c fails to build for me (and I can't see how the
> 2.6.18 tree would build for x86 either, as I can't see how asm/pgtable.h
> would get included: it doesn't get included in any of my 2.6.16, 2.6.22,
> 2.6.25, and 2.6.27 based trees). Perhaps there's a configuration
> dependency, but that would then be wrong. And I'm hesitant to include
> asm/pgtable.h explicitly in that file, as it really shouldn't need it.

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...)


> 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.
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()?

-- 
yamahata

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