WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

RE: Transparent paravirtualization vs. xen paravirtualization (was:RE: [

To: "Dong, Eddie" <eddie.dong@xxxxxxxxx>, "Tristan Gingold" <Tristan.Gingold@xxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: Transparent paravirtualization vs. xen paravirtualization (was:RE: [Xen-ia64-devel] IRQ management)
From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Date: Tue, 25 Oct 2005 06:48:32 -0700
Delivery-date: Tue, 25 Oct 2005 13:46:30 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcXYoH5VC58JP0jcTAKD11ElTp2+BAADaykAABRR42AAGmYeQA==
Thread-topic: Transparent paravirtualization vs. xen paravirtualization (was:RE: [Xen-ia64-devel] IRQ management)
Except for the irq handling differences (for which I agree
that some work should be done to come closer to Xen/x86),
most of the remaining design differences are due to the fact
that the x86 and ia64 processor architectures have different
virtual memory mechanisms.

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.

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.

I don't see "transparent paravirtualization" and
"Xen/x86-closeness" as incompatible.  Both are possible.
Indeed, I expect that the distros will be pushing Xen/x86 to
be transparently paravirtualized in the future.

Dan

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

<Prev in Thread] Current Thread [Next in Thread>