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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

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. :)

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.

Thanks,
Kevin

>-----Original Message-----
>From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Tian, Kevin
>Sent: Tuesday, May 24, 2005 11:41 AM
>To: Ian Pratt; Keir Fraser
>Cc: Sharma, Arun; xen-devel@xxxxxxxxxxxxxxxxxxx
>Subject: RE: [Xen-devel] Re: Are linker scripts needed?
>
>>> I thought that VMX provided a virtual equivalent of SMM,
>>> where management and emulation code can run under the OS's
>>> feet without it realising? If this is not provided then I do
>>> not think the trick can work, as you would need to steal some
>>> virtual address space in which to execute the qemu code.
>>
>>I'd be inclined to move to a model where we execute the device
>emulation
>>in the root (monitor) VMCS, using the same protection mechanism we use
>>for para-virtualized guests e.g. segmentation for x86, paging for
>>x86_64. The device emulation should should work like a normal
front-end
>>driver, connecting via a device channel to a normal backend.
>
>I like the idea. :) but where is the resource of device emulation
>component getting allocation from, like physical frame allocated to
that
>module? If it's managed by vmx domain's kernel, I'm not sure it's easy
>for such type of DM to acquire system resource and also access the user
>eco system across multiple space, like:
>       - page fault handle
>       - Access special files like /proc/privcmd
>       - Where are configuration files of qemu saved? In service OS
>file system, or in vmx domain's FS?
>       - How to sync between DM and corresponding vmx domain?
>       ...
>
>Also that style of DM will be another type of domain, which has to been
>considered by HV specially with resource and schedule...
>
>Just some immature concerns, and like to learn more in this direction.
>:)
>
>Thanks,
>Kevin
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-devel

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