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:03:07 +0100 [thread overview]
Message-ID: <523C7FCB.6040202@eu.citrix.com> (raw)
In-Reply-To: <523AE95E02000078000F4A31@nat28.tlf.novell.com>
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?
If not, what needs to change here?
-George
next prev parent reply other threads:[~2013-09-20 17:03 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 [this message]
2013-09-20 17:06 ` George Dunlap
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=523C7FCB.6040202@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).