From: "Jan Beulich" <JBeulich@suse.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: elena.ufimtseva@oracle.com, wei.liu2@citrix.com,
ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com,
xen-devel@lists.xen.org, roger.pau@citrix.com
Subject: Re: [PATCH v3 3/4] x86/pvh: Handle hypercalls for 32b PVH guests
Date: Tue, 11 Aug 2015 03:32:58 -0600 [thread overview]
Message-ID: <55C9DD6A020000780009970A@prv-mh.provo.novell.com> (raw)
In-Reply-To: <55B28558.4020906@oracle.com>
>>> On 24.07.15 at 20:35, <boris.ostrovsky@oracle.com> wrote:
> On 07/23/2015 10:21 AM, Jan Beulich wrote:
>>>>> On 11.07.15 at 00:20, <boris.ostrovsky@oracle.com> wrote:
>>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>> ---
>>> Changes in v3:
>>> * Defined compat_mmuext_op(). (XEN_GUEST_HANDLE_PARAM(mmuext_op_compat_t)
>>> is not defined in header files so I used 'void' type.
>> How is it not? It's in compat/xen.h (which is a generated header).
>
> compat/xen.h has DEFINE_COMPAT_HANDLE(mmuext_op_compat_t) (which is
> __compat_handle_mmuext_op_compat_t).
>
> We need XEN_GUEST_HANDLE(mmuext_op_compat_t), which is
> __guest_handle_mmuext_op_compat_t. And I wasn't sure it's worth
> explicitly adding it to a header file (like I think what we do for
> vcpu_runstate_info_compat_t in sched.h);
Hmm, indeed all other compat_..._op()-s use void handles (albeit in
most if not all of the cases their native counterparts do too). So I
guess using void here is fine then, or using COMPAT_HANDLE()
instead. It's not really relevant anyway since COMPAT_CALL()
casts the function pointer to the intended type anyway.
>>> @@ -4981,7 +5003,7 @@ int hvm_do_hypercall(struct cpu_user_regs *regs)
>>> return viridian_hypercall(regs);
>>>
>>> if ( (eax >= NR_hypercalls) ||
>>> - (is_pvh_domain(currd) ? !pvh_hypercall64_table[eax]
>>> + (is_pvh_domain(currd) ? !pvh_hypercall32_table[eax]
>>> : !hvm_hypercall32_table[eax]) )
>> ... this will break (as we're assuming 32- and 64-bit tables to be fully
>> in sync here; there's still the pending work item of constructing these
>> tables so that this has a better chance of not getting broken).
>
> So you prefer to have full check --- explicitly for both 32- and 64-bit,
> right?
No. Just adding the missing operation to the table will deal with it.
I wouldn't like to see more conditionals to be added to this code
path when we can avoid doing so. What we could do is add a
respective ASSERT() to the 64-bit path, albeit the NULL deref
would be observable as a fault without the ASSERT() too (and
adding one wouldn't help release builds [and their security]).
Jan
next prev parent reply other threads:[~2015-08-11 9:32 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-10 22:20 [PATCH v3 0/4] 32-bit domU PVH support Boris Ostrovsky
2015-07-10 22:20 ` [PATCH v3 1/4] x86/pvh: Set 32b PVH guest mode in XEN_DOMCTL_set_address_size Boris Ostrovsky
2015-07-23 13:59 ` Jan Beulich
2015-07-10 22:20 ` [PATCH v3 2/4] x86/compat: Test both PV and PVH guests for compat mode Boris Ostrovsky
2015-07-23 14:07 ` Jan Beulich
2015-07-23 14:13 ` Ian Campbell
2015-07-23 14:23 ` Jan Beulich
2015-07-24 17:54 ` Boris Ostrovsky
2015-08-11 9:19 ` Jan Beulich
2015-08-11 17:21 ` Boris Ostrovsky
2015-08-12 6:23 ` Jan Beulich
2015-08-12 15:02 ` Boris Ostrovsky
2015-07-10 22:20 ` [PATCH v3 3/4] x86/pvh: Handle hypercalls for 32b PVH guests Boris Ostrovsky
2015-07-23 14:21 ` Jan Beulich
2015-07-24 18:35 ` Boris Ostrovsky
2015-08-11 9:32 ` Jan Beulich [this message]
2015-07-10 22:20 ` [PATCH v3 4/4] libxc/x86/pvh: Allow creation of " Boris Ostrovsky
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=55C9DD6A020000780009970A@prv-mh.provo.novell.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=boris.ostrovsky@oracle.com \
--cc=elena.ufimtseva@oracle.com \
--cc=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=roger.pau@citrix.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.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).