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