[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Device model architecture (Was Re: [Xen-devel] Re: Are linkerscripts needed?)

  • To: "Arun Sharma" <arun.sharma@xxxxxxxxx>
  • From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
  • Date: Mon, 30 May 2005 18:21:19 +0100
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 30 May 2005 17:20:34 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcVlOGWh8Yc5HJ2mSrWVUtEMR3LLHgAAjvQA
  • Thread-topic: Device model architecture (Was Re: [Xen-devel] Re: Are linkerscripts needed?)

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


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.