xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Keir Fraser <keir.fraser@eu.citrix.com>
To: "Dong, Eddie" <eddie.dong@intel.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>, "He, Qing" <qing.he@intel.com>
Subject: Re: [PATCH 06/16] vmx: nest: handling VMX instruction exits
Date: Mon, 20 Sep 2010 09:08:02 +0100	[thread overview]
Message-ID: <C8BCD4F2.2380F%keir.fraser@eu.citrix.com> (raw)
In-Reply-To: <1A42CE6F5F474C41B63392A5F80372B22A95F800@shsmsx501.ccr.corp.intel.com>

On 20/09/2010 04:13, "Dong, Eddie" <eddie.dong@intel.com> wrote:

>>>> 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?
>> 
>> Well. It'd be better if just worked really, wouldn't it? :-) How hard
>> can it be?
> 
> You are right. It is easy to do, but we have dillemma to either write-protect
> guest I/O bitmap page, or have to create the shadow I/O bitmap at each
> vmresume of L2 guest.

You need that anyway don't you, regardless of whether you are accurately
deciding whether to inject-to-L1 or emulate-L2 on vmexit to L0? Whether you
inject or emulate, ports that L1 has disallowed for L2 must be properly
represented in the shadow I/O bitmap page.

> Currently we are injecting to L1 guest, but may be not correct in theory. For
> now, VMX can trap L2 guest I/O and emulate them in L0, we can revisit some
> time later to see if we need write-protection of guest I/O bitmap page :)

Are you suggesting to always emulate instead of always inject-to-L1? That's
still not accurate virtualisation of this VMX feature.

Hmm... Are you currently setting up to always vmexit on I/O port accesses by
L2? Even if you are, that doesn't stop you looking at the virtual I/O bitmap
from in your L0 vmexit handler, and doing the right thing (emulate versus
inject-to-L1).

 -- Keir

> But, yes, L0 VMM needs to emulate L2 instruction here :)

  reply	other threads:[~2010-09-20  8:08 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
2010-09-15 13:12                       ` Keir Fraser
2010-09-20  3:13                         ` Dong, Eddie
2010-09-20  8:08                           ` Keir Fraser [this message]
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=C8BCD4F2.2380F%keir.fraser@eu.citrix.com \
    --to=keir.fraser@eu.citrix.com \
    --cc=Christoph.Egger@amd.com \
    --cc=Tim.Deegan@eu.citrix.com \
    --cc=eddie.dong@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).