All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arun Sharma <arun.sharma@intel.com>
To: Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>
Cc: xen-devel@lists.xensource.com
Subject: Re: Device model architecture (Was Re: Re: Are linkerscripts needed?)
Date: Mon, 30 May 2005 09:55:22 -0700	[thread overview]
Message-ID: <429B457A.2030402@intel.com> (raw)
In-Reply-To: <A95E2296287EAD4EB592B5DEEFCE0E9D281F28@liverpoolst.ad.cl.cam.ac.uk>

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

  parent reply	other threads:[~2005-05-30 16:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-27 10:49 Device model architecture (Was Re: Re: Are linkerscripts needed?) Ian Pratt
2005-05-27 18:06 ` Arun Sharma
2005-05-30 16:55 ` Arun Sharma [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-05-30 17:21 Ian Pratt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=429B457A.2030402@intel.com \
    --to=arun.sharma@intel.com \
    --cc=m+Ian.Pratt@cl.cam.ac.uk \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.