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)

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

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

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.

Jan


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