RE: [Xen-ia64-devel] [PATCH][RFC][TAKE4] the P2M/VP patches

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Isaku Yamahata [mailto:yamahata@xxxxxxxxxxxxx]
>Sent: 2006年4月7日 15:48
>I'll post a quick hack patch for xenLinux/x86 (but only compile-test)
>when I post this patch.
>
>A new conversion function needs to be introduced.
>unsigned long pfn_to_mfn_for_dma(unsigned long pfn)
>{
>        if (xen_feature(XENFEAT_auto_translated_dmaaddr))
>                return pfn;
>        return real_pfn_to_mfn(pfn);
>}
>
>unsigned long pfn_to_mfn(unsigned long pfn)
>{
>        if (xen_feature(XENFEAT_auto_translated_physmap))
>                return pfn;
>        return real_pfn_to_mfn(pfn);
>}

OK.

>>
>> Does this patch only save one hypercall overhead? We can always
>> tell guest the auto_translated bit is true when guest hypercalls to
>> query feature bits into xen_feature array.
>
>No.
>I agree that we can go without this patch by telling the bit always 1.
>The reasons why I wrote this patch are as follows
>
>- It is more explicit than telling auto_translated bit always 1.
>  Perhaps code readers expect that the auto_translated feature
>  can be determined at run-time even for xen/ia64, not requirement.
>  This is only a readability issue.
>  Telling auto_translated bit 1 makes code harder-to-read a bit.
>
>- Compiler can optimize better.

Maybe I'm not clear here. You can see from setup_xen_features 
where a hypercall is issued to query what on earth this domain is 
configured with. That feature info can be passed in from config file. 
So I think even xen/ia64 wants to hardcode auto_translated bit as 1, 
it's better to do within xen with xenlinux inferface unchanged to query. 
Anyway, we don't want to eliminate future possibility that dom0 may 
also see physmap directly for performance. :-) But yes, seems this 
feature need to be queried earlier which seems difficult for current 
xen/ia64 model. So it may be better to hardcode xen_features array 
for now.

How do you think?

Thanks,
Kevin

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