From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Dong, Eddie" Subject: RE: [PATCH 06/16] vmx: nest: handling VMX instruction exits Date: Mon, 20 Sep 2010 17:33:31 +0800 Message-ID: <1A42CE6F5F474C41B63392A5F80372B22A95FB06@shsmsx501.ccr.corp.intel.com> References: <1A42CE6F5F474C41B63392A5F80372B22A95F800@shsmsx501.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser , Christoph Egger , "xen-devel@lists.xensource.com" Cc: Tim Deegan , "Dong, Eddie" , "He, Qing" List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > On 20/09/2010 04:13, "Dong, Eddie" wrote: >=20 >>>>> 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=20 >>>>=20 >>>> 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?=20 >>>=20 >>> Well. It'd be better if just worked really, wouldn't it? :-) How >>> hard can it be? >>=20 >> 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. >=20 > 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. VMX has a feature "always exit" for PIO which doesn't use I/O bitmap. >=20 >> 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 :)=20 >=20 > Are you suggesting to always emulate instead of always inject-to-L1? > That's still not accurate virtualisation of this VMX feature. L2 PIO is always exiting to L0. So we wither inject to L1, or emulate it in= L0, base on L1 I/O exiting and bitmap setting. >=20 > 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 Yes. > virtual I/O bitmap from in your L0 vmexit handler, and doing the No, we checked the L1 settings. > right thing (emulate versus inject-to-L1). >=20 BTW, does SVM side already implemented the write-protection of I/O bitmap &= MSR bitmap. it seems not. Thx, Eddie=