From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH RFC v12 16/21] pvh: Use PV handlers for emulated forced invalid ops, cpuid, and IO Date: Fri, 20 Sep 2013 18:06:25 +0100 Message-ID: <523C8091.7020408@eu.citrix.com> References: <1379089521-25720-1-git-send-email-george.dunlap@eu.citrix.com> <1379089521-25720-17-git-send-email-george.dunlap@eu.citrix.com> <5239E36502000078000F4761@nat28.tlf.novell.com> <20130918180226.0b19fd75@mantra.us.oracle.com> <523AE95E02000078000F4A31@nat28.tlf.novell.com> <523C7FCB.6040202@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VN4A5-0000H8-27 for xen-devel@lists.xenproject.org; Fri, 20 Sep 2013 17:06:33 +0000 In-Reply-To: <523C7FCB.6040202@eu.citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel , Keir Fraser , TimDeegan List-Id: xen-devel@lists.xenproject.org On 20/09/13 18:03, George Dunlap wrote: > On 19/09/13 11:09, Jan Beulich wrote: >>>>> On 19.09.13 at 03:02, Mukesh Rathor wrote: >>> On Wed, 18 Sep 2013 16:31:17 +0100 "Jan Beulich" >>> wrote: >>>>>>> On 13.09.13 at 18:25, George Dunlap >>>>>>> wrote: >>>>> @@ -1624,6 +1631,13 @@ static int guest_io_okay( >>>>> int user_mode = !(v->arch.flags & TF_kernel_mode); >>>>> #define TOGGLE_MODE() if ( user_mode ) toggle_guest_mode(v) >>>>> + /* >>>>> + * For PVH we check this in vmexit for >>>>> EXIT_REASON_IO_INSTRUCTION >>>>> + * and so don't need to check again here. >>>>> + */ >>>>> + if ( is_pvh_vcpu(v) ) >>>>> + return 1; >>>>> + >>>>> if ( !vm86_mode(regs) && >>>>> (v->arch.pv_vcpu.iopl >= (guest_kernel_mode(v, regs) ? >>>>> 1 : 3)) ) return 1; >>>> Hmm, am I missing something here? The check in the VMEXIT >>>> handler is just a privilege level one - where's the bitmap being >>>> consulted? _If_ the bitmap is being maintained properly for the >>>> guest (which I don't recall having seen), anything leading here >>>> would be for ports the guest was not permitted access to. Yet >>>> we would happily emulate the access for it then. >>> Not sure I understand which bitmap needs to be consulted. The bitmap >>> hvm_io_bitmap is used to set the intercepts which PVH also uses, with >>> HVM defaults. >> Actually I think I got confused by the IOPL checking in your >> VM exit handling code: _If_ you need to check the IOPL, then >> you also need to check the bitmap hanging off of the TSS. But >> aiui all the privilege level checks get done inside the guest, and >> only if those pass would the I/O bitmap hanging off of the VMCS >> be consulted. Hence neither the IOPL check nor the TSS-based >> bitmap check ought to be necessary here. > > I'm not quite following this. Are you saying that the iopl checks are > done by the hardware, and if failed it will already have delivered a > GPF; and if we've managed to get an IO_INSTRUCTION exit then they have > passed, so we don't need the iopl check in vmx.c? It does look as if the HVM path doesn't do any checking at all. -George