[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: Fri, 27 May 2005 11:49:05 +0100
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 27 May 2005 10:50:04 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • 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.


Xen-devel mailing list



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