>>> Isaku Yamahata <yamahata@xxxxxxxxxxxxx> 03.12.08 09:44 >>>
>On Wed, Dec 03, 2008 at 07:58:56AM +0000, Jan Beulich wrote:
>> >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.
>>
>> The same applies to x86-64, but virt_to_bus() (or rather the underlying
>> virt_to_phys()) is prepared to deal with that situation. So it rather sounds
>> like a shortcoming of the ia64 variant to me...
>
>Oh I forgot the x86-64 case.
>
>virt_to_bus() is intended only for virtual address of the kernel
>identity mapping area, I think.
>virt_to_bus() can't be used to the vmalloc area, for example.
>
>On the other hand, there is no guarantee that global variables
>lay in the kernel identity mapping area.
>On i386 and x86-64, the kernel global variables happen to
>be in kaddr, but it isn't the case on ia64 nor more generally
>for global variables of the kernel modules which are allocated
>from the vmalloc area.
>So I think virt_to_bus() shouldn't be used for global variables.
You seem to contradict yourself then: The variable we're talking about
is not in module space, so the vmalloc() argument wouldn't apply. If
however you think it is relevant, then you can't implement
arbitrary_virt_to_bus() on x86 by simply using virt_to_bus() - and even
without considering that aspect, the name on x86 doesn't hold what it
promises. So I think you either need to properly implement it for x86
(by using arbitary_virt_to_machine - and then you could simply use that
name on ia64 and don't change anything for x86), or you should abstract
out that aspect in evtchn.c.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home