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: [Xen-ia64-devel] [PATCH] [RFC] [TAKE3] P2M/VP (incomplete) patches

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Subject: Re: [Xen-ia64-devel] [PATCH] [RFC] [TAKE3] P2M/VP (incomplete) patches
From: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Date: Mon, 27 Mar 2006 17:28:06 +0900
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 27 Mar 2006 08:29:24 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <571ACEFD467F7749BC50E0A98C17CDD8094E79CD@pdsmsx403>
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: <571ACEFD467F7749BC50E0A98C17CDD8094E79CD@pdsmsx403>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.2.1i
Hi.

On Fri, Mar 24, 2006 at 11:11:38PM +0800, Tian, Kevin wrote:
>       A quality writing and good work by far. Due to memory model as the 
> most critical/basic component, your work is actually extended to cover 
> many areas as the issues posted below. :-) Maybe you have to make a 
> priority list, and see whether some core components can be split into 
> self-contained parts with major cleanup efforts paid for them first.

Here is the categorized and prioritized list of issues.
These priority is for short/middle term(1-3 months).
Although others might think differently with these priority,
I hope this list helps.


* Issues directly related to the P2M/VP patches.
The following issues are directly related the P2M/VP patches.
Perhaps performance tuning/benchmarking can be done in parallel.

- High  discussion on grant table API clean up/performance tuning
- High  grant table API clean up
        This must be after the discussion.
- High  ballon driver
        XENMEM_populate_physmap, XENMEM_decrease_reservation,
        XENMEM_increase_reservation
- High  SMP
        Currently nosmp option to xen/IA64 is needed.
        This will be addressed after grant table API clean up.
        This must be before grant table performance tuning
- High  performance tuning related to grant table.
        - micro benchmark?
          Is there already suitable benchmarks or should it be developed?
- High  performance tuning unrelated to grant table.
- Med   grant table mapped page reference count and domain destruction
        This should be after grant table API clean up and performance tuning.
        If a domain is destroyed when it maps a foreign domain's page
        via grant table, its page reference count will be leaked.
        Page freeing code is needed.
- Low   xen_start_info->{console_mfn, store_mfn}
        These are defined as machine frame number. However on Xen/IA64 with
        P2M/VP model, these should be pseudo physical frame number.
        So they should be gmfn instead of mfn.
- Low   IOCTL_PRIVCMD_MMAP, IOCTL_PRIVCMD_MMAPBATCH
        re-implement xen/IA64 implementation using PageForeign() and
        its families.
- Low   blktap


* Issues which can be worked independently of P2M/VP model.
The following issues are unrelated the P2M/VP patches or
depends on the stabilized part of P2M/VP patches
so that they can be worked independently of the P2M/VP model patches.

** Platform support
- Low   HP ZX1
  High for HP(?)
        Some modification is necessary for
        linux/arch/ia64/hp/common/sba_iommu.c.
- Low   SGI Altix
  High for SGI(?)
        There are many custom drivers under linux/arch/ia64/sn directory.
        They also need modifications.
- Low   ski simulator
        simscsi, simeth are broken. dom0 can't boot.

** Testing
- Low   AGP
        AGP should work, but I haven't tested it.
- Low   virtualized driver
        Only vbd and vnif are tested.
        Other virtual devices except balloon and blktap should work.
- Low   transparent para-virtualization
        Some of xen/IA64 developers value transparent para-virtualization.
        "if (running_on_xen) { }" is be used, but it isn't tested.
        Or is it worthwhile to define a kind of switch which is determined at
        boot up time ?
- Low   Stability test, benchmark
        This might be too early to begin.

** Bug fixes and misc
- High  copy_to_guest(), copy_from_guest()
        They are broken.
        Their copy may success or may result in EFAULT depending on tlb cache
        state.
        Fortunately xen/PPC port already solved similar problems.
        Discussion is needed.
- Low   panic_domain()
        This function is called when a domain behaves a way xen can't handle
        well.
        A domain should be stopped, but xen should continue to run.
        But the current implementation results in BUG() in xen or drops to
        debugger so that xen itself stops.
- Low   SUBARCH
- Low   dltb miss handler optimization
- Low   itlb miss handler fix
        fix dom0 startup environment to remove alt itlb miss which occurs
        at dom0 boot time.


* My plan
high priority
- discussion on grant table API clean up / performance tuning
- getting balloon driver to work

- grant table API clean up
- SMP
- performance tuning related to grant table

- performance tuning unrelated to grant table.
- stability/testing/benchmark
- merge effort
low priority


-- 
yamahata

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