WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Arun Sharma" <arun.sharma@xxxxxxxxx>
Subject: RE: Device model architecture (Was Re: [Xen-devel] Re: Are linkerscripts needed?)
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
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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.

Ian



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>