| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: Device model architecture (Was Re: [Xen-devel] Re: Are linkerscripts
Ian Pratt wrote:
I guess the main logic behind your argument is that there is
no need to fully virtualize the device models, so no need to
run them within a non-root VMCS.
We can't run them in the same non-root VMCS as the guest since we need
some virtual address space. [...]
You can, with a world switch using a different CR3.
The only comment I have is: for the case where the device
models require the services of a backend driver, you might be
paying more than what we currently pay (one domain switch)
i.e. vmx domain -> mini os -> backend. But it should be
faster for everything else.
The vmx_domain to mini-OS switch happens as part of the vmexit.
It's actually the vmexit + cost of upcall to the mini-os + cost of
domain switch to the backend (say dom0).
Right now, it's vmexit + cost of domain switch to dom0 + cost of dom0
kernel to user mode device model.
So the difference is
cost of dom0 kernel to user - cost of frontend to backend switch
I suspect that the delta is small and not much to worry about.
Devices such as the APIC/IOAPIC/PIT etc can all be emulated without
calling out of the device model, and should work with just the same
performance as having them in Xen as we do today.
True, it's definitely a win for devices that don't require communication
with the backend.
Also, some customers might want to use the split I/O model, where the
VMX domain directly wants to use a raw partition on real disk. I'd
rather have drivers in the OS hosting the device-models instead of going
through the backend.
-Arun
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home