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] Xen/IPF Unstable CS#18688, Linux#705, ioemu#629adb3

To: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>, "Zhang, Jingke" <jingke.zhang@xxxxxxxxx>
Subject: RE: [Xen-ia64-devel] Xen/IPF Unstable CS#18688, Linux#705, ioemu#629adb3f... Status --- no new issue, report 3 old bugs
From: "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
Date: Mon, 27 Oct 2008 16:36:38 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-ia64-devel@xxxxxxxxxxxxxxxxxxx" <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 27 Oct 2008 01:36:44 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20081024075340.GF21546%yamahata@xxxxxxxxxxxxx>
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/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
References: <BB1F052FCDB1EA468BD99786C8B1ED2C01CD14F94A@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20081024075340.GF21546%yamahata@xxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Ack1rak3xXy0KJ2IQA28+Xdhr3ccbgCYEbtA
Thread-topic: [Xen-ia64-devel] Xen/IPF Unstable CS#18688, Linux#705, ioemu#629adb3f... Status --- no new issue, report 3 old bugs
Isaku Yamahata wrote:
> On Fri, Oct 24, 2008 at 09:59:58AM +0800, Zhang, Jingke wrote:
>>     3. IPF-Xen can not boot up domain with dom_id > 62 (not
>> regression, should be there for a long time) 
> 
> Long ago, I posted the patch to address this issue.
> Probably there are two ways. (Is there other better way?)
> 
> a.) abandon the rid partitioning, and flush mTLB every time vcpu
>     context switch.

Current kvm adopts this method, we didn't find any performance regression 
through benchmark. But sine the architecture difference between xen and kvm, so 
maybe should investigate more through enough benchmark data. 

>     (some bits of rid space needs to be reserved for real mode
> emulation.) 
> 
> b.) keep the rid partitioning and allow rid collision.
>     When vcpu context switch, check the rid collision and
>     flush mTLB if necessary.
> 
> Benchmark would be necessary to decide which one is better and
> to estimate performance degradation.
> I implemented b). However no one has implemented a).
> So no further step was taken.

I thought Jingke isn't saying this  topic. What he found maybe he failed to 
create the domain when the domain is created and destoryed continuously for 
more 62 times. Seems the issue is from  the the algorithm for deallocating rid 
blocks doesn't work, when destroying the guest.  
Xiantao



> thanks,


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