|
|
|
|
|
|
|
|
|
|
xen-devel
RE: Device model architecture (Was Re: [Xen-devel] Re: Are linkerscripts
> > 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.
Sure, we need to generate interrupts into the VMX domain (e.g. as a
result of an event from a backend to a frontend indicating a network
packet has been received). The ipi of receiving the event will cause a
vmexit, execute the device model, and then inject an interrupt into the
vmx guest.
> 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.
I'm not totally convinced about this. The frontend drivers are pretty
simple and take little in the way of CPU. Although its useful to overlap
backend execution with the domain, I'm not so sure its useful to overlap
frontend execution.
Ian
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|