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

RE: [Xen-devel] Re: Are linker scripts needed?

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] Re: Are linker scripts needed?
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Tue, 24 May 2005 13:54:07 +0100
Cc: "Sharma, Arun" <arun.sharma@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, "Li, Susie" <susie.li@xxxxxxxxx>
Delivery-date: Tue, 24 May 2005 12:54:04 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcVflh4X4tpm0xgnRx21dU5PZMmD2AAAH/oAAB5kVhAADmNWAAAEFcXQ
Thread-topic: [Xen-devel] Re: Are linker scripts needed?
 

> Then, after some look at vmxassist mechanism and with some 
> discussion with Susie Li, I'm now aware that my previous 
> understanding completely bias from your intent. :) Following 
> the 'hack' you mentioned, that DM may finally be standalone 
> component, without any dependency with upper vmx domain. 
> Control panel can load it to appropriate position, which has 
> its own trap table, own page table (maybe fixed), device 
> emulation logic, simplified event channel interface, similar 
> assist hook in HV for context save/restore, etc. No need to 
> have memory management, since DMA buffer will only be touched 
> by backend. En... now I'm clearer about the feasibility, 
> which is always the first thing for me to care when learning 
> new things. :)

I don't quite follow your terminiology, but I think we're on the same
wavelength.

I guess the first step would be getting mini-os working on the unstable
tree again -- shouldn't be hard. 
 
> Regarding performance, it saves many context switches between 
> kernel and user space, compared to current DM model which 
> runs as application in service's OS. But the maximum 
> granularity of this model is still instruction level when vmx 
> domain tries to do mmio access. Instead, for some specific 
> device, frontend driver module may be more effective to 
> utilize frontend-backend model, since it's based on 
> transaction/session.
> The example is the recent VBD/VNIF driver by Xiaofeng Lin, 
> which can be installed into vmx domain dynamically and then 
> talk to backend effectively.

Yep, performance won't be as good as the real para-virtualized drivers,
but if we pick the device to emulate carefully it should be possible to
get half decent performance. [We'll probably use the qemu models in the
first instance, but ideally we want to emulate a network device that
supports DMA and cheksum offload. Using the L4/Afterburner team's
DP83820 emulation code might actually be a better starting point than
qemu. ]

Only question is, who's going to do the work? :-)  

Best,
Ian



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