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

["Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>]

> 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