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: Fri, 27 May 2005 11:49:05 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 27 May 2005 10:50:04 +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: AcVhvkk+1Mb0QrW3TEyI8Wo8pEHHWAA250Rw
Thread-topic: Device model architecture (Was Re: [Xen-devel] Re: Are linkerscripts needed?)
 > > 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.
 
> 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).

Yep. It also makes them interact with backend drivers in an identical
way to normal paravirtualized front ends. Ideally, we'd pick devices to
emulate that use DMA and descriptor rings so that the only time a VMexit
would occur would when the virtual device is 'kicked' when making the tx
ring non-empty, or the receive interrupt. Performance should be pretty
good, and if you want maximum performance, install the paravirtualzed
drivers that are able to do page flipping.

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

The vmx_domain to mini-OS switch happens as part of the vmexit. Work
will get queued just like a normal frontend talking to a backend, so I
don't think there's a performance issue here -- it will certainly be
faster than the current situation. 

Devices such as the APIC/IOAPIC/PIT etc can all be emulated without
calling out of the device model, and should work with just the same
performance as having them in Xen as we do today.

Best,
Ian 

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

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