From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Jan Beulich <JBeulich@suse.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: Fri, 24 Jul 2015 14:35:04 -0400 [thread overview]
Message-ID: <55B28558.4020906@oracle.com> (raw)
In-Reply-To: <55B1147D0200007800094A8C@prv-mh.provo.novell.com>
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);
>
>> @@ -4951,6 +4950,29 @@ static hvm_hypercall_t *const pvh_hypercall64_table[NR_hypercalls] = {
>> [ __HYPERVISOR_arch_1 ] = (hvm_hypercall_t *)paging_domctl_continuation
>> };
>>
>> +extern int compat_mmuext_op(XEN_GUEST_HANDLE_PARAM(void) cmp_uops,
>> + unsigned int count,
>> + XEN_GUEST_HANDLE_PARAM(uint) pdone,
>> + unsigned int foreigndom);
>> +static hvm_hypercall_t *const pvh_hypercall32_table[NR_hypercalls] = {
>> + HYPERCALL(platform_op),
>> + COMPAT_CALL(memory_op),
>> + HYPERCALL(xen_version),
>> + HYPERCALL(console_io),
>> + [ __HYPERVISOR_grant_table_op ] =
>> + (hvm_hypercall_t *)hvm_grant_table_op_compat32,
>> + COMPAT_CALL(vcpu_op),
>> + COMPAT_CALL(mmuext_op),
>> + HYPERCALL(xsm_op),
>> + COMPAT_CALL(sched_op),
>> + HYPERCALL(event_channel_op),
>> + [ __HYPERVISOR_physdev_op ] = (hvm_hypercall_t *)hvm_physdev_op_compat32,
>> + HYPERCALL(hvm_op),
>> + HYPERCALL(sysctl),
>> + HYPERCALL(domctl),
>> + [ __HYPERVISOR_arch_1 ] = (hvm_hypercall_t *)paging_domctl_continuation
> Looks like you didn't fully sync with staging - did you forget that it
> was you who added xenpmu_op to the 64-bit counterpart?
I think I posted this before VPMU got committed. But yes...
> Without that ...
>
>> @@ -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?
-boris
next prev parent reply other threads:[~2015-07-24 18:35 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 [this message]
2015-08-11 9:32 ` Jan Beulich
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=55B28558.4020906@oracle.com \
--to=boris.ostrovsky@oracle.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.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).