| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: Device model architecture (Was Re: [Xen-devel] Re: Are linker script
In xen.devel, you wrote:
>
>> > - why is this better than running the device models inside the VMX
>> > domain? Do you expect switching to the helper domain to be
>> faster than
>> > a vmx world switch?
>>
>> Depends on whether you can make the CPU do a direct switch,
>> or if you need to 'bounce' through root VMCS (taking an extra
>> cr3 switch).
>
> The 'monitor_table' will also be the (single) pagetable for device
> emulator and Xen.
>
> There should be no need for extra cr3 switches (other than that incurred
> by the vmexit).
>
> When switching between the vmcs guest and the minios, we just need to
> switch new values into the guest_table variable and the shadow_mode
> variable and then all the Xen logic will do the right thing. (no cr3
> flush in incurred)
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.
This should give us some of the same management benefits that running
them inside a VMX domain would give us (memory sharing, device models
go away when the domain is destroyed etc).
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.
-Arun
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home