From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arun Sharma Subject: Re: Device model architecture (Was Re: Re: Are linkerscripts needed?) Date: Mon, 30 May 2005 09:55:22 -0700 Message-ID: <429B457A.2030402@intel.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Pratt Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Ian Pratt wrote: > > > 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. > 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. 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. This is possible in the current design. -Arun