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

["Dong, Eddie" <eddie.dong@xxxxxxxxx>]

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