RE: Transparent paravirtualization vs. xen paravirtualization(was:RE: [Xen-ia64-devel] IRQ management)

["Yang, Fred" <fred.yang@xxxxxxxxx>]

Magenheimer, Dan (HP Labs Fort Collins) wrote:
> There are some implementation differences also that probably
> should be fixed, e.g. in evtchn and gnttab.  These arose because
> we weren't very efficient at getting patches into these
> files to convert x86-arch-dep code to arch-neutral code and,
> as a result, we created separate modules.
The community should try to reduce recurrent effort.  Key issue on
gnttab is Domain0 should also have PMT table support, which shouldn't
access machine physical with gpn=mpn directly.  This issue is also the
key reason causing major effort in porting VBD/DomainU for each upstream
merge.  This also blocks the forward VNIF effort due to page flipping
issue.
PMT is a must for gnttab to support VBD, VNIF and forward development of
Xen/ia64.   PMT would need to be shared between Domain and Xen for
performance
> 
> By fixing irq handling and clearly understanding and properly
> implementing architectural neutrality in event channels and
> grant tables, I think we will eliminate most of the rebasing
> difficulties.
Key issue is Xen/ia64 shouldn't derail from basic grant table design
-Fred
> 
>> -----Original Message-----
>> From: Dong, Eddie [mailto:eddie.dong@xxxxxxxxx]
>> Sent: Monday, October 24, 2005 11:50 PM
>> To: Magenheimer, Dan (HP Labs Fort Collins); Tristan Gingold;
>> xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>> Subject: Transparent paravirtualization vs. xen
>> paravirtualization (was:RE: [Xen-ia64-devel] IRQ management)
>> 
>> Dan & all:
>>      This mail reminder me various stuff that XEN/IA64 needs to face
>> as the results of difference paravirtualization approach, it
>> is time for
>> us to have a revisit.
>>      1: IPI and lSAPIC stuff.
>>              In deep virtualization solution (XEN/X86), xenlinux
>> never use direct IPI operation, instead it uses event
>> channel. Same with
>> APIC.
>>              XEN/IA64, using minimal paravirtualization (like
>> transparent virtualization), we have to implement IPI and APIC device
>> model in HV instead of changing xenlinux code. This becomes same with
>> VT-i implementation, so we and can reuse VT-i code, Tristan?.
>> 
>>      2: VBD/VNIF
>>              Current XEN VBD/VNIF uses a lot of deep
>> paravirtualization stuff like grant table, foreign map including page
>> swap and page sharing and etc. If we port them to Xen/IA64, we either
>> change VBD/VNIF design a lot that may have severe rebasing issue as
>> Xen/X86 continues evolving, or we implement those deep
>> paravirtualization technology in Xen/AI64. That at least need to let
>> dom0 and domU all be aware that gpn may not be same with mfn.
>> (current dom0 is assuming gpn=mfn). 
>> 
>>      3: writable pagetable.
>>              Again, Xen/x86 deep paravirtualization implements
>> writable pagetable for performance reason(compare with shadow page
>> table), and various other stuff are assuming this. While Xen/IA64
>> doesn't work in this way(it is much like shadow page table but not
>> exactly), time to time that will cause rebasing difficulty and
>> performance issue in future. 
>> 
>>      So, it looks like transparent paravirtualization can benfit in
>> reducing OSV's validation effort, but also introduces a lot of side
>> effort, especially with rapid development of Xen/X86
>> environment. Is it
>> time to think about more than transparent paravirtualization for
>> Xen/IA64? Or should we move to close more to Xen/X86?
>> Thanks,eddie
>> 
>> Magenheimer, Dan (HP Labs Fort Collins) wrote:
>>> Only the timer and serial port need to be virtualized.
>>> Serial console output is handled through common code
>>> in xen/drivers/char.  I believe this code is also used
>>> on Xen/x86 for serial console input but input has not
>>> yet been implemented on Xen/ia64... it's probably
>>> not hard to do but nobody has done it yet.
>>> 
>>> Dan
>>> 
>>>> -----Original Message-----
>>>> From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>>> [mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
>>>> Tristan Gingold Sent: Monday, October 24, 2005 8:43 AM
>>>> To: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>>>> Subject: [Xen-ia64-devel] IRQ management
>>>> 
>>>> Hi,
>>>> 
>>>> Recently I looked a little bit on how IRQs are managed.
>>>> Correct me if I am wrong but on xen-ia64, only LSAPIC is
>>>> virtualized.  IOSAPIC is not and devices interrupt are fully
>>>> managed by domain0. On xen-x86, IRQs are fully virtualized by xen.
>>>> 
>>>> Since they are not virtualized on xen-ia64, the serial console
>>>> input doesn't work, and we can't use the xenkeys.
>>>> 
>>>> Are IRQs planned to be virtualized ?
>>>> 
>>>> Tristan.
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Xen-ia64-devel mailing list
>>>> Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>>>> http://lists.xensource.com/xen-ia64-devel
>>>> 
>>> 
>>> _______________________________________________
>>> Xen-ia64-devel mailing list
>>> Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>>> http://lists.xensource.com/xen-ia64-devel
>> 
>> 
> 
> _______________________________________________
> Xen-ia64-devel mailing list
> Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-ia64-devel


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