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:03:07 +0100 Message-ID: <523C7FCB.6040202@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VN477-0000B3-GA for xen-devel@lists.xenproject.org; Fri, 20 Sep 2013 17:03:29 +0000 In-Reply-To: <523AE95E02000078000F4A31@nat28.tlf.novell.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 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? If not, what needs to change here? -George