| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: Device model architecture (Was Re: [Xen-devel] Re: Are linkerscripts
Ian Pratt wrote:
> > 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.
We can't run them in the same non-root VMCS as the guest since we need
some virtual address space. Since the hardware does a cr3 switch to the
monitor_table when doing a vmexit, wwe might as well make better use of
this and treat the device models as just another paravirtualized guest.
I thought some more about this. We can't think of device models as a
bunch of code that run only during a vmexit. It needs to be able to
handle asynchronous events such as keyboard/mouse input or other sources
of events and inject interrupts into the VMX domain ASAP.
Specifically, on a dual CPU system or a HT system, we should be able to
run device models on one CPU and the VMX domains on another CPU. This is
possible in the current design.
-Arun
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home