All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dong, Eddie" <eddie.dong@intel.com>
To: Keir Fraser <keir.fraser@eu.citrix.com>,
	Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Cc: Tim Deegan <Tim.Deegan@eu.citrix.com>,
	"Dong, Eddie" <eddie.dong@intel.com>,
	"He, Qing" <qing.he@intel.com>
Subject: RE: [PATCH 06/16] vmx: nest: handling VMX instruction exits
Date: Wed, 15 Sep 2010 20:36:56 +0800	[thread overview]
Message-ID: <1A42CE6F5F474C41B63392A5F80372B22A8C236B@shsmsx501.ccr.corp.intel.com> (raw)
In-Reply-To: <C8B66EFB.2304C%keir.fraser@eu.citrix.com>

Keir Fraser wrote:
> On 15/09/2010 10:08, "Dong, Eddie" <eddie.dong@intel.com> wrote:
> 
>>> But yes I can see that emulation of L2 guest instructions is needed
>>> in some other cases. Like instructions performing I/O in areas which
>>> L1 thinks it has given L2 direct unmediated access to, but which Xen
>>> is actually filtering or emulating.
>> 
>> That may be an issue in plan when we support virtual VT-d for nested
>> I/O performance. But not now :)
> 
> Actually it is an issue now. This has nothing to do with VT-d (ie.
> IOMMU, irq remapping, etc) but with basic core VMX functionality --
> per I/O port direct execute versus vmexit; per virtual-address page

I see, for the I/O port, right now we are letting L1 handle it though it doesn't expect to :(
How about to remove the capability of CPU_BASED_ACTIVATE_IO_BITMAP in L1 VMM for now to focus on framework?


> direct access versus #PF vmexit; per physical-frame direct access
> versus nexted-paging vmexit. In any of these cases the L1 may think

Didn't quit catch. The memory direct access is always guarded by L0 shadow or nested EPT/NPT. Missing something?

> it has given direct unfettered access to the L2, but L0 (Xen) is
> actually blocking it. In this case any resulting required instruction
> emulations have to be performed by Xen on behalf of the L2, without
> L1's help or knowledge. Consider that even in Xen we give all HVM
> guests direct access to thinks like port 0x80 for perf reasons. Maybe
> a VMM running in L1 would give direct access to more even than that
> -- in such cases Xen must be able to emulate those 'direct' accesses. 

Agree!

> 
> Now this shouldn't be hard to arrange anyhow. When you vmexit to Xen
> from running L2 guest, the saved general-purpose CPU state will be
> the L2's state, and that is what you would want x86_emulate to see.
> But it does require some thought, and it is merely not an extension
> to be dealt with later. It is core VMX stuff and hence core nested
> VMX stuff. 

Yes. For I/O issue, emulating by L0 should be fine.

Thx, Eddie

  reply	other threads:[~2010-09-15 12:36 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-08 15:22 [PATCH 00/16] Nested virtualization for VMX Qing He
2010-09-08 15:22 ` [PATCH 01/16] vmx: nest: rename host_vmcs Qing He
2010-09-10 13:27   ` Christoph Egger
2010-09-08 15:22 ` [PATCH 02/16] vmx: nest: wrapper for control update Qing He
2010-09-10 13:29   ` Christoph Egger
2010-09-08 15:22 ` [PATCH 03/16] vmx: nest: nested availability and status flags Qing He
2010-09-15 11:43   ` Christoph Egger
2010-09-15 14:18     ` Dong, Eddie
2010-09-08 15:22 ` [PATCH 04/16] vmx: nest: nested control structure Qing He
2010-09-09  6:13   ` Dong, Eddie
2010-09-15 11:27   ` Christoph Egger
2010-09-15 13:06     ` Dong, Eddie
2010-09-15 13:17       ` Christoph Egger
2010-09-15 13:31         ` Christoph Egger
2010-09-15 13:46           ` Dong, Eddie
2010-09-15 14:02             ` Christoph Egger
2010-09-08 15:22 ` [PATCH 05/16] vmx: nest: virtual vmcs layout Qing He
2010-09-13 10:29   ` Tim Deegan
2010-09-08 15:22 ` [PATCH 06/16] vmx: nest: handling VMX instruction exits Qing He
2010-09-10  7:05   ` Dong, Eddie
2010-09-13 11:11     ` Tim Deegan
2010-09-13 14:29       ` Dong, Eddie
2010-09-13 14:46         ` Tim Deegan
2010-09-13 11:10   ` Tim Deegan
2010-09-15  4:55     ` Dong, Eddie
2010-09-15  6:40       ` Keir Fraser
2010-09-15  6:49         ` Dong, Eddie
2010-09-15  7:31           ` Keir Fraser
2010-09-15  8:15             ` Christoph Egger
2010-09-15  8:23               ` Keir Fraser
2010-09-15  9:08                 ` Dong, Eddie
2010-09-15 11:39                   ` Keir Fraser
2010-09-15 12:36                     ` Dong, Eddie [this message]
2010-09-15 13:12                       ` Keir Fraser
2010-09-20  3:13                         ` Dong, Eddie
2010-09-20  8:08                           ` Keir Fraser
2010-09-20  9:33                             ` Dong, Eddie
2010-09-20  9:41                               ` Keir Fraser
2010-09-20 13:10                                 ` Dong, Eddie
2010-09-20  9:41                             ` Christoph Egger
2010-09-20 13:14                               ` Dong, Eddie
2010-09-15  7:17         ` Qing He
2010-09-15  7:38           ` Keir Fraser
2010-09-15  7:56             ` Dong, Eddie
2010-09-15  8:15               ` Keir Fraser
2010-09-15  9:26                 ` Tim Deegan
2010-09-15  9:56                   ` Dong, Eddie
2010-09-15 11:46                     ` Keir Fraser
2010-09-08 15:22 ` [PATCH 07/16] vmx: nest: switch current vmcs Qing He
2010-09-08 15:22 ` [PATCH 08/16] vmx: nest: vmresume/vmlaunch Qing He
2010-09-15  9:52   ` Christoph Egger
2010-09-15 11:30     ` Christoph Egger
2010-09-20  5:19       ` Dong, Eddie
2010-09-08 15:22 ` [PATCH 09/16] vmx: nest: shadow controls Qing He
2010-09-08 15:22 ` [PATCH 10/16] vmx: nest: L1 <-> L2 context switch Qing He
2010-09-08 15:22 ` [PATCH 11/16] vmx: nest: interrupt handling Qing He
2010-09-08 15:22 ` [PATCH 12/16] vmx: nest: VMExit handler in L2 Qing He
2010-09-08 15:22 ` [PATCH 13/16] vmx: nest: L2 tsc Qing He
2010-09-08 15:22 ` [PATCH 14/16] vmx: nest: CR0.TS and #NM Qing He
2010-09-08 15:22 ` [PATCH 15/16] vmx: nest: capability reporting MSRs Qing He
2010-09-13 12:45   ` Tim Deegan
2010-09-15 10:05   ` Christoph Egger
2010-09-15 14:28     ` Dong, Eddie
2010-09-15 14:45       ` Christoph Egger
2010-09-16 14:10         ` Dong, Eddie
2010-09-08 15:22 ` [PATCH 16/16] vmx: nest: expose cpuid and CR4.VMXE Qing He
2010-09-15  9:43   ` Christoph Egger
2010-09-13 13:10 ` [PATCH 00/16] Nested virtualization for VMX Tim Deegan

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=1A42CE6F5F474C41B63392A5F80372B22A8C236B@shsmsx501.ccr.corp.intel.com \
    --to=eddie.dong@intel.com \
    --cc=Christoph.Egger@amd.com \
    --cc=Tim.Deegan@eu.citrix.com \
    --cc=keir.fraser@eu.citrix.com \
    --cc=qing.he@intel.com \
    --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.