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/
Home Products Support Community News


[Xen-ia64-devel] RE: paravirt_ops support in IA64

To: "Robin Holt" <holt@xxxxxxx>, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
Subject: [Xen-ia64-devel] RE: paravirt_ops support in IA64
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Mon, 18 Feb 2008 21:58:27 +0800
Cc: Jack Steiner <steiner@xxxxxxx>, linux-ia64@xxxxxxxxxxxxxxx, jeremy@xxxxxxxxxxxxx, kvm-ia64-devel@xxxxxxxxxxxxxxxxxxxxx, Rusty Russell <rusty@xxxxxxxxxxxxxxx>, Avi Kivity <avi@xxxxxxxxxxxx>, xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>, Christoph Lameter <clameter@xxxxxxx>
Delivery-date: Mon, 18 Feb 2008 05:58:44 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20080218115434.GC11391@xxxxxxx>
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>
References: <10EA09EFD8728347A513008B6B0DA77A02C8234B@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <42DFA526FC41B1429CE7279EF83C6BDCDF2356@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20080218115434.GC11391@xxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AchyJRz3ytckpgPWR+qSor2PY2I+2AAAyUQA
Thread-topic: paravirt_ops support in IA64
Robin Holt wrote:
> those should be discussed here.  Also, could you repost the patches?

The work is just started, so sorry we don't have patches in hand right
But we can provide some example code for better reference.

> On a different note, I am willingly and woefully unaware of what the
> paravirt _NEEDS_ are.  Could those be summarised as well?  I will

Sure. In both X86 & IA64, the classical processor architecture is not
virtualizable (before VT and similar HW technology are invented), so
para_virtualization technology is invented by modifying guest Linux
source code to work with hypervisor cooperatively, such as Xen.

But this kind of paravirtualization technology needs to modify Linux
source a lot and get a lot of debate in community. The original
Xen PV patches are not accepted so far and it is a 
big issue to OSVs to maintain 2 version of Linux OS (guest Linux
and bare metal Linux). Meanwhile there are new hypervisors come 
in which need different modification to Linux. VMware proposed 
VMI (Virtual Machine Interface) in 06 OLS to replace sensitive
by VMI so that same Linux binary can run for both native and guest. 

Later on Rusty Russell proposed a function table based solution called 
paravirt_ops (pv_ops) and eventually get community buy in. Today the
X86/32 bits support is in upstream.

The basic idea of X86 pv_ops is to replace original processor sensitive 
instructions such as cli/sti to a call to a pv_ops function table, whose

contents are initialized for each hypervisor.  For example:

--- xx  2008-02-18 20:09:32.000000000 +0800
+++ entry_32.S  2007-12-18 16:22:59.000000000 +0800
@@ -264,7 +264,7 @@

-       cli
        cmpl $0,TI_preempt_count(%ebp)  # non-zero preempt_count ?
        jnz restore_nocheck

        The definition of DISABLE_INTERRUPTS behavior like (pseudo

#define DISABLE_INTERRUPTS(clb) pv_irq_ops->irq_disable()

        At the Linux startup time, the initialization code will set
pv_irq_ops->irq_disable to xen_irqdisable if underlying hyperviosr is
native_irqdisable if on bare metal for example.

> admit to being completely ignorant about how paravirt works on x86.
> Please don't state them in terms of we want to change the code this
> way, but rather in terms of we need to intercept these points in the
> kernel for this reason/purpose.

Agree, basically IA64 side has same maintenance issue for OSVs
such as Redhat to release 2 images for native & Xen guest today. 
to be more important, today Xen PV (paravirtualized) guest only support
2.6.18 Linux, forward porting to latest Linux needs a lot of effort. So
we want to push those changes to upstream. That is the whole purpose.

People ever pushed current Xen/IA64 PV Linux changes to upstream, 
but didn't get promising result yet. Due to the ermeging pv_ops support
in X86 side, if IA64 side also takes pv_ops based solution, we can reuse
a lot of common code and thus less patch than before. It also can
 different hypervisor in future easily such as KVM for

Current Xen/IA64 is not doing pv_ops yet, we are still in brainstorming/
design phase. If we could get more comments from you guys before we 
choose a way to go, that would save us a lot of effort. 

Yes, right now we are mainly focusing on entry.S & ivt.S changes.

> Thanks,
> Robin
> -
Thanks, Eddie

Xen-ia64-devel mailing list

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