xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Keir Fraser <keir@xen.org>, TimDeegan <tim@xen.org>
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	[thread overview]
Message-ID: <523C8091.7020408@eu.citrix.com> (raw)
In-Reply-To: <523C7FCB.6040202@eu.citrix.com>

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 <mukesh.rathor@oracle.com> wrote:
>>> On Wed, 18 Sep 2013 16:31:17 +0100 "Jan Beulich" <JBeulich@suse.com> 
>>> wrote:
>>>>>>> On 13.09.13 at 18:25, George Dunlap 
>>>>>>> <george.dunlap@eu.citrix.com> 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

  reply	other threads:[~2013-09-20 17:06 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-13 16:25 Introduce PVH domU support George Dunlap
2013-09-13 16:25 ` [PATCH RFC v12 01/21] Fix failure path in hvm_vcpu_initialise George Dunlap
2013-09-13 16:25 ` [PATCH RFC v12 02/21] Fix failure path in construct_vmcs George Dunlap
2013-09-13 16:25 ` [PATCH RFC v12 03/21] Remove an unnecessary assert from vmx_update_debug_state George Dunlap
2013-09-16 21:09   ` Mukesh Rathor
2013-09-18 10:39     ` George Dunlap
2013-09-18 12:38       ` Jan Beulich
2013-09-18 12:53         ` George Dunlap
2013-09-18 13:51           ` Jan Beulich
2013-09-13 16:25 ` [PATCH RFC v12 04/21] pvh prep: code motion George Dunlap
2013-09-18 12:59   ` Jan Beulich
2013-09-13 16:25 ` [PATCH RFC v12 05/21] Introduce pv guest type and has_hvm_container macros George Dunlap
2013-09-18 13:46   ` Jan Beulich
2013-09-19 16:27     ` George Dunlap
2013-09-20  8:11       ` Jan Beulich
2013-09-20  9:23         ` George Dunlap
2013-09-20  9:44           ` Jan Beulich
2013-09-19 16:58   ` George Dunlap
2013-09-20  8:38     ` Jan Beulich
2013-09-13 16:25 ` [PATCH RFC v12 06/21] pvh: Introduce PVH guest type George Dunlap
2013-09-18 14:10   ` Jan Beulich
2013-09-20 10:01     ` George Dunlap
2013-09-13 16:25 ` [PATCH RFC v12 07/21] pvh: Disable unneeded features of HVM containers George Dunlap
2013-09-13 16:36   ` George Dunlap
     [not found]     ` <CAGU+aus16muryVYd-aOzv-CAXPk_xxVh_e-R7Ug1RxGRJ_MAfQ@mail.gmail.com>
2013-09-13 21:33       ` Aravindh Puthiyaparambil (aravindp)
2013-09-16 23:17     ` Mukesh Rathor
2013-09-18 10:50       ` George Dunlap
2013-09-18 14:18   ` Jan Beulich
2013-09-18 14:43     ` George Dunlap
2013-09-18 14:47       ` Jan Beulich
2013-09-13 16:25 ` [PATCH RFC v12 08/21] pvh: vmx-specific changes George Dunlap
2013-09-13 16:38   ` George Dunlap
2013-09-16  7:37     ` Jan Beulich
2013-09-16  9:15       ` George Dunlap
2013-09-16 23:12     ` Mukesh Rathor
2013-09-17  8:48       ` George Dunlap
2013-09-18  0:13         ` Mukesh Rathor
2013-09-18 14:25   ` Jan Beulich
2013-09-20 13:07     ` George Dunlap
2013-09-13 16:25 ` [PATCH RFC v12 09/21] pvh: Do not allow PVH guests to change paging modes George Dunlap
2013-09-18 14:32   ` Jan Beulich
2013-09-13 16:25 ` [PATCH RFC v12 10/21] pvh: PVH access to hypercalls George Dunlap
2013-09-18 14:45   ` Jan Beulich
2013-09-13 16:25 ` [PATCH RFC v12 11/21] pvh: Use PV e820 George Dunlap
2013-09-18 14:48   ` Jan Beulich
2013-09-13 16:25 ` [PATCH RFC v12 12/21] pvh: Support guest_kernel_mode for PVH George Dunlap
2013-09-18 14:52   ` Jan Beulich
2013-09-13 16:25 ` [PATCH RFC v12 13/21] pvh: Support read_segment_register " George Dunlap
2013-09-18 14:56   ` Jan Beulich
2013-09-20 14:18     ` George Dunlap
2013-09-20 14:56       ` Jan Beulich
2013-09-13 16:25 ` [PATCH RFC v12 14/21] pvh: read_descriptor for PVH guests George Dunlap
2013-09-13 16:40   ` George Dunlap
2013-09-18 15:00   ` Jan Beulich
2013-09-13 16:25 ` [PATCH RFC v12 15/21] pvh: Set up more PV stuff in set_info_guest George Dunlap
2013-09-18 15:17   ` Jan Beulich
2013-09-20 14:50     ` George Dunlap
2013-09-20 14:58       ` Jan Beulich
2013-09-20 15:12         ` George Dunlap
2013-09-20 15:26           ` Jan Beulich
2013-09-13 16:25 ` [PATCH RFC v12 16/21] pvh: Use PV handlers for emulated forced invalid ops, cpuid, and IO George Dunlap
2013-09-18 15:31   ` Jan Beulich
2013-09-19  1:02     ` Mukesh Rathor
2013-09-19 10:09       ` Jan Beulich
2013-09-20 17:03         ` George Dunlap
2013-09-20 17:06           ` George Dunlap [this message]
2013-09-23  6:49           ` Jan Beulich
2013-09-23 13:48     ` George Dunlap
2013-09-23 14:09       ` Jan Beulich
2013-09-13 16:25 ` [PATCH RFC v12 17/21] pvh: Disable 32-bit guest support for now George Dunlap
2013-09-18 15:36   ` Jan Beulich
2013-09-13 16:25 ` [PATCH RFC v12 18/21] pvh: Restrict tsc_mode to NEVER_EMULATE " George Dunlap
2013-09-13 16:25 ` [PATCH RFC v12 19/21] pvh: Disable debug traps when doing pv emulation for PVH domains George Dunlap
2013-09-13 16:25 ` [PATCH RFC v12 20/21] pvh: Disable memevents for PVH guests for now George Dunlap
2013-09-13 16:25 ` [PATCH RFC v12 21/21] pvh: Documentation George Dunlap
2013-09-13 16:41 ` Introduce PVH domU support George Dunlap

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=523C8091.7020408@eu.citrix.com \
    --to=george.dunlap@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=keir@xen.org \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /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).