From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Wei Liu <wei.liu2@citrix.com>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Ian Jackson <ian.jackson@eu.citrix.com>,
mpohlack@amazon.de, ross.lagerwall@citrix.com,
Julien Grall <julien.grall@arm.com>,
Stefano Stabellini <stefano.stabellini@citrix.com>,
xen-devel@lists.xenproject.org,
Daniel De Graaf <dgdegra@tycho.nsa.gov>,
Keir Fraser <keir@xen.org>,
sasha.levin@oracle.com
Subject: Re: [PATCH v4 04/34] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
Date: Tue, 22 Mar 2016 11:52:51 -0400 [thread overview]
Message-ID: <20160322155251.GB20062@char.us.oracle.com> (raw)
In-Reply-To: <56EFFAF802000078000DED1F@prv-mh.provo.novell.com>
On Mon, Mar 21, 2016 at 06:45:28AM -0600, Jan Beulich wrote:
> >>> On 18.03.16 at 20:22, <konrad.wilk@oracle.com> wrote:
> >> > + * return the number of bytes requested for the operation. Or an
> >> > + * negative value if an error is encountered.
> >> > + */
> >> > +
> >> > +typedef uint64_t xen_version_op_val_t;
> >> > +DEFINE_XEN_GUEST_HANDLE(xen_version_op_val_t);
> >> > +
> >> > +typedef void xen_version_op_buf_t;
> >> > +DEFINE_XEN_GUEST_HANDLE(xen_version_op_buf_t);
> >>
> >> Are these actually useful for anything? And for the various strings,
> >
> > The xen_version_op_val_t is definitly used by the toolstack.
> >
> >> wouldn't a "char" handle be more natural?
> >
> > Heh. It was char[] before but Andrew liked it as void.
>
> But that was because you used it for non string types too,
> wasn't it?
Yes. For the build-id which is a binary blob. And as you noticed - also
the domain handle which can be anything.
>
> > @@ -380,6 +388,133 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
> > return -ENOSYS;
> > }
> >
> > +static const char *capabilities_info(unsigned int *len)
> > +{
> > + static xen_capabilities_info_t __read_mostly cached_cap;
> > + static unsigned int __read_mostly cached_cap_len;
> > + static bool_t cached;
> > +
> > + if ( unlikely(!cached) )
> > + {
> > + arch_get_xen_caps(&cached_cap);
> > + cached_cap_len = strlen(cached_cap) + 1;
> > + cached = 1;
> > + }
>
> I'm sorry for noticing this only now, but without any locking this is
> unsafe: x86's arch_get_xen_caps() using safe_strcat() to fill the
> buffer, simultaneous invocations would possibly produce garbled
> output to all (i.e. also subsequently started) guests. Either use a
> real lock here, or make the guard a tristate one, which gets
> transitioned e.g. from 0 to -1 by the first one coming here (doing
> the initialization), with everyone else waiting for it to become +1
> (to which the initializing party sets it once it is done).
That would indeed be bad.
What if an _init_ code called this to 'pre-cache' it?
>
> > +DO(version_op)(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) arg,
> > + unsigned int len)
> > +{
> > + union {
> > + xen_version_op_val_t val;
> > + xen_feature_info_t fi;
> > + } u = {};
> > + unsigned int sz = 0;
> > + const void *ptr = NULL;
> > + int rc = xsm_version_op(XSM_OTHER, cmd);
> > +
> > + /* We can safely return -EPERM! */
> > + if ( rc )
> > + return rc;
> > +
> > + /*
> > + * The HYPERVISOR_xen_version differs in that some return the value,
> > + * and some copy it on back on argument. We follow the same rule for all
> > + * sub-ops: return 0 on success, positive value of bytes returned, and
> > + * always copy the result in arg. Yeey sanity!
> > + */
> > + switch ( cmd )
> > + {
> > + case XEN_VERSION_version:
> > + sz = sizeof(xen_version_op_val_t);
> > + u.val = (xen_major_version() << 16) | xen_minor_version();
> > + break;
> > +
> > + case XEN_VERSION_extraversion:
> > + sz = strlen(xen_extra_version()) + 1;
> > + ptr = xen_extra_version();
> > + break;
> > +
> > + case XEN_VERSION_capabilities:
> > + ptr = capabilities_info(&sz);
> > + break;
> > +
> > + case XEN_VERSION_changeset:
> > + sz = strlen(xen_changeset()) + 1;
> > + ptr = xen_changeset();
> > + break;
> > +
> > + case XEN_VERSION_platform_parameters:
> > + sz = sizeof(xen_version_op_val_t);
> > + u.val = HYPERVISOR_VIRT_START;
> > + break;
> > +
> > + case XEN_VERSION_get_features:
> > + if ( copy_from_guest(&u.fi, arg, 1) )
>
> Afaict this is incompatible with the null handle check further down (i.e.
> you also need to check for a null handle here).
Oh my. Indeed.
>
> > --- a/xen/include/public/arch-arm.h
> > +++ b/xen/include/public/arch-arm.h
> > @@ -128,6 +128,9 @@
> > * * VCPUOP_register_vcpu_info
> > * * VCPUOP_register_runstate_memory_area
> > *
> > + * HYPERVISOR_version_op
> > + * All generic sub-operations
> > + *
> > *
> > * Other notes on the ARM ABI:
>
> I don't think the extra almost blank line is warranted here.
>
> > --- a/xen/include/public/version.h
> > +++ b/xen/include/public/version.h
> > @@ -30,7 +30,15 @@
> >
> > #include "xen.h"
> >
> > -/* NB. All ops return zero on success, except XENVER_{version,pagesize} */
> > +/*
> > + * There are two hypercalls mentioned in here. The XENVER_ are for
> > + * HYPERCALL_xen_version (17), while VERSION_ are for the
> > + * HYPERCALL_version_op (41).
> > + *
> > + * The subops are very similar except that the later hypercall has a
> > + * sane interface.
> > + */
> > +
> >
> > /* arg == NULL; returns major:minor (16:16). */
>
> Nor is the extra blank one here.
>
> > @@ -87,6 +95,66 @@ typedef struct xen_feature_info xen_feature_info_t;
> > #define XENVER_commandline 9
> > typedef char xen_commandline_t[1024];
> >
> > +
> > +
> > +/*
> > + * The HYPERCALL_version_op has a set of sub-ops which mirror the
>
> And three consecutive blank lines are too much in any event. (If
> for no other reason that because that provides extremely bad
> patch context if a later change happened right next to these three
> lines.)
>
> > +/*
> > + * arg == char.
> > + *
> > + * The toolstack fills it out for guest consumption. It is intended to hold
> > + * the UUID of the guest.
> > + */
> > +#define XEN_VERSION_guest_handle 8
>
> So this is the place where I agree with Andrew char is not an
> appropriate type. A void or uint8 handle seems like what you
> want here.
/me nods.
>
> > --- a/xen/include/xsm/dummy.h
> > +++ b/xen/include/xsm/dummy.h
> > @@ -751,3 +751,22 @@ static XSM_INLINE int xsm_xen_version (XSM_DEFAULT_ARG uint32_t op)
> > return xsm_default_action(XSM_PRIV, current->domain, NULL);
> > }
> > }
> > +
> > +static XSM_INLINE int xsm_version_op (XSM_DEFAULT_ARG uint32_t op)
> > +{
> > + XSM_ASSERT_ACTION(XSM_OTHER);
> > + switch ( op )
> > + {
> > + case XEN_VERSION_version:
> > + case XEN_VERSION_extraversion:
> > + case XEN_VERSION_capabilities:
> > + case XEN_VERSION_platform_parameters:
> > + case XEN_VERSION_get_features:
> > + case XEN_VERSION_pagesize:
> > + case XEN_VERSION_guest_handle:
> > + /* These MUST always be accessible to any guest by default. */
> > + return xsm_default_action(XSM_HOOK, current->domain, NULL);
> > + default:
> > + return xsm_default_action(XSM_PRIV, current->domain, NULL);
>
> Considering that we seem to have settled on some exceptions here
> for the change adding XSM check to the legacy version op, do you
> really think going with no exception at all here is the right approach?
> Because if we do, that'll prevent guests getting fully converted over
> to the new interface. Of course, we could also make this conversion
> specifically a non-goal, and omit e.g. XEN_VERSION_VERSION from
> this new interface.
No no. I think convesion is the right long-term goal.
However the nice thing about this hypercall is that it can return -EPERM.
Making it always return an value for XEN_VERSION_version,
XEN_VERSION_platform_parameters, XEN_VERSION_get_features means that
there are some exceptions to this "can return -EPERM" as they will
be guaranteed an postive return value. They can ignore the -EPERM
case.
And means that guest can still take shortcuts.
I agree with you that guests need these hypercalls but at the same
time I am not sure what can be done so they don't fall flat on their
faces if they are presented with -EPERM. The Linux xenbus_init can be
modified to deal with this returning -EPERM where it makes some assumptions.
But in a likelyhood it is the bad assumption!
Andrew, what do you think?
>
> Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-03-22 15:53 UTC|newest]
Thread overview: 124+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-15 17:56 [PATCH v4] xSplice v1 design and implementation Konrad Rzeszutek Wilk
2016-03-15 17:56 ` [PATCH v4 01/34] compat/x86: Remove unncessary #define Konrad Rzeszutek Wilk
2016-03-15 18:57 ` Andrew Cooper
2016-03-16 11:08 ` Jan Beulich
2016-03-17 0:44 ` Konrad Rzeszutek Wilk
2016-03-17 7:45 ` Jan Beulich
2016-03-15 17:56 ` [PATCH v4 02/34] libxc: Remove dead code (XENVER_capabilities) Konrad Rzeszutek Wilk
2016-03-15 18:04 ` Andrew Cooper
2016-03-15 18:08 ` Konrad Rzeszutek Wilk
2016-03-16 18:11 ` Wei Liu
2016-03-15 17:56 ` [PATCH v4 03/34] xsm/xen_version: Add XSM for the xen_version hypercall Konrad Rzeszutek Wilk
2016-03-18 11:55 ` Jan Beulich
2016-03-18 17:26 ` Konrad Rzeszutek Wilk
2016-03-21 11:22 ` Jan Beulich
2016-03-22 16:10 ` Konrad Rzeszutek Wilk
2016-03-22 17:54 ` Daniel De Graaf
2016-03-22 17:49 ` Daniel De Graaf
2016-03-24 15:34 ` anshul makkar
2016-03-24 19:19 ` Konrad Rzeszutek Wilk
2016-03-15 17:56 ` [PATCH v4 04/34] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane Konrad Rzeszutek Wilk
2016-03-15 18:29 ` Andrew Cooper
2016-03-15 20:19 ` Konrad Rzeszutek Wilk
2016-03-17 1:38 ` Konrad Rzeszutek Wilk
2016-03-17 14:28 ` Andrew Cooper
2016-03-18 12:36 ` Jan Beulich
2016-03-18 19:22 ` Konrad Rzeszutek Wilk
2016-03-21 12:45 ` Jan Beulich
2016-03-22 15:52 ` Konrad Rzeszutek Wilk [this message]
2016-03-22 16:06 ` Jan Beulich
2016-03-22 18:57 ` Konrad Rzeszutek Wilk
2016-03-22 19:28 ` Andrew Cooper
2016-03-22 20:39 ` Konrad Rzeszutek Wilk
2016-03-23 8:56 ` Jan Beulich
2016-03-24 2:37 ` Konrad Rzeszutek Wilk
2016-03-24 9:15 ` Jan Beulich
2016-03-24 11:39 ` Konrad Rzeszutek Wilk
2016-03-22 17:51 ` Daniel De Graaf
2016-03-15 17:56 ` [PATCH v4 05/34] libxc/libxl/python/xenstat: Use new XEN_VERSION_OP hypercall Konrad Rzeszutek Wilk
2016-03-15 18:45 ` Andrew Cooper
2016-03-16 12:31 ` George Dunlap
2016-03-16 18:11 ` Wei Liu
2016-03-17 1:08 ` Konrad Rzeszutek Wilk
2016-03-15 17:56 ` [PATCH v4 06/34] x86/arm: Add BUGFRAME_NR define and BUILD checks Konrad Rzeszutek Wilk
2016-03-15 18:54 ` Andrew Cooper
2016-03-16 11:49 ` Julien Grall
2016-03-18 12:40 ` Jan Beulich
2016-03-18 19:59 ` Konrad Rzeszutek Wilk
2016-03-21 12:49 ` Jan Beulich
2016-03-22 15:39 ` Konrad Rzeszutek Wilk
2016-03-22 15:58 ` Jan Beulich
2016-03-15 17:56 ` [PATCH v4 07/34] arm/x86: Use struct virtual_region to do bug, symbol, and (x86) exception tables Konrad Rzeszutek Wilk
2016-03-15 19:24 ` Andrew Cooper
2016-03-15 19:34 ` Konrad Rzeszutek Wilk
2016-03-15 19:51 ` Andrew Cooper
2016-03-15 20:02 ` Andrew Cooper
2016-03-16 10:33 ` Jan Beulich
2016-03-18 13:07 ` Jan Beulich
2016-03-22 20:18 ` Konrad Rzeszutek Wilk
2016-03-23 8:19 ` Jan Beulich
2016-03-23 11:17 ` Julien Grall
2016-03-23 11:21 ` Jan Beulich
2016-03-24 2:49 ` Konrad Rzeszutek Wilk
2016-03-24 9:20 ` Jan Beulich
2016-03-15 17:56 ` [PATCH v4 08/34] vmap: Make the while loop less fishy Konrad Rzeszutek Wilk
2016-03-15 19:33 ` Andrew Cooper
2016-03-17 11:49 ` Jan Beulich
2016-03-17 14:37 ` Andrew Cooper
2016-03-17 15:30 ` Jan Beulich
2016-03-17 16:06 ` Ian Jackson
2016-03-17 11:48 ` Jan Beulich
2016-03-17 16:08 ` Ian Jackson
2016-03-21 12:04 ` George Dunlap
2016-03-21 13:26 ` Jan Beulich
2016-03-21 14:22 ` George Dunlap
2016-03-21 15:05 ` Jan Beulich
2016-03-15 17:56 ` [PATCH v4 09/34] vmap: ASSERT on NULL Konrad Rzeszutek Wilk
2016-03-15 17:56 ` [PATCH v4 10/34] vmap: Add vmalloc_cb and vfree_cb Konrad Rzeszutek Wilk
2016-03-18 13:20 ` Jan Beulich
2016-03-15 17:56 ` [PATCH v4 11/34] xsplice: Design document Konrad Rzeszutek Wilk
2016-03-23 11:18 ` Jan Beulich
2016-03-23 20:12 ` Konrad Rzeszutek Wilk
2016-03-23 20:21 ` Konrad Rzeszutek Wilk
2016-03-24 3:15 ` Konrad Rzeszutek Wilk
2016-03-24 9:32 ` Jan Beulich
2016-03-15 17:56 ` [PATCH v4 12/34] xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op Konrad Rzeszutek Wilk
2016-03-16 12:12 ` Julien Grall
2016-03-16 19:58 ` Konrad Rzeszutek Wilk
2016-03-23 13:51 ` Jan Beulich
2016-03-24 3:13 ` Konrad Rzeszutek Wilk
2016-03-24 9:29 ` Jan Beulich
2016-03-15 17:56 ` [PATCH v4 13/34] libxc: Implementation of XEN_XSPLICE_op in libxc Konrad Rzeszutek Wilk
2016-03-16 18:12 ` Wei Liu
2016-03-16 20:36 ` Konrad Rzeszutek Wilk
2016-03-15 17:56 ` [PATCH v4 14/34] xen-xsplice: Tool to manipulate xsplice payloads Konrad Rzeszutek Wilk
2016-03-16 18:12 ` Wei Liu
2016-03-15 17:56 ` [PATCH v4 15/34] xsplice: Add helper elf routines Konrad Rzeszutek Wilk
2016-03-15 17:56 ` [PATCH v4 16/34] xsplice: Implement payload loading Konrad Rzeszutek Wilk
2016-03-22 17:25 ` Konrad Rzeszutek Wilk
2016-03-15 17:56 ` [PATCH v4 17/34] xsplice: Implement support for applying/reverting/replacing patches Konrad Rzeszutek Wilk
2016-03-15 17:56 ` [PATCH v4 18/34] x86/xen_hello_world.xsplice: Test payload for patching 'xen_extra_version' Konrad Rzeszutek Wilk
2016-03-15 17:56 ` [PATCH v4 19/34] xsplice, symbols: Implement symbol name resolution on address Konrad Rzeszutek Wilk
2016-03-15 17:56 ` [PATCH v4 20/34] x86, xsplice: Print payload's symbol name and payload name in backtraces Konrad Rzeszutek Wilk
2016-03-15 17:56 ` [PATCH v4 21/34] xsplice: Add .xsplice.hooks functions and test-case Konrad Rzeszutek Wilk
2016-03-15 17:56 ` [PATCH v4 22/34] xsplice: Add support for bug frames Konrad Rzeszutek Wilk
2016-03-15 17:56 ` [PATCH v4 23/34] xsplice: Add support for exception tables Konrad Rzeszutek Wilk
2016-03-15 17:56 ` [PATCH v4 24/34] xsplice: Add support for alternatives Konrad Rzeszutek Wilk
2016-03-15 17:56 ` [PATCH v4 25/34] build_id: Provide ld-embedded build-ids Konrad Rzeszutek Wilk
2016-03-16 18:34 ` Julien Grall
2016-03-16 21:02 ` Konrad Rzeszutek Wilk
2016-03-17 1:12 ` Konrad Rzeszutek Wilk
2016-03-17 11:08 ` Julien Grall
2016-03-17 13:39 ` Konrad Rzeszutek Wilk
2016-03-15 17:56 ` [PATCH v4 26/34] HYPERCALL_version_op: Add VERSION_OP_build_id to retrieve build-id Konrad Rzeszutek Wilk
2016-03-15 17:56 ` [PATCH v4 27/34] libxl: info: Display build_id of the hypervisor using XEN_VERSION_OP_build_id Konrad Rzeszutek Wilk
2016-03-16 18:12 ` Wei Liu
2016-03-15 17:56 ` [PATCH v4 28/34] xsplice: Print build_id in keyhandler and on bootup Konrad Rzeszutek Wilk
2016-03-15 17:56 ` [PATCH v4 29/34] xsplice: Stacking build-id dependency checking Konrad Rzeszutek Wilk
2016-03-15 17:56 ` [PATCH v4 30/34] xsplice/xen_replace_world: Test-case for XSPLICE_ACTION_REPLACE Konrad Rzeszutek Wilk
2016-03-15 17:56 ` [PATCH v4 31/34] xsplice: Print dependency and payloads build_id in the keyhandler Konrad Rzeszutek Wilk
2016-03-15 17:56 ` [PATCH v4 32/34] xsplice: Prevent duplicate payloads from being loaded Konrad Rzeszutek Wilk
2016-03-15 17:56 ` [PATCH v4 33/34] xsplice: Add support for shadow variables Konrad Rzeszutek Wilk
2016-03-15 17:56 ` [PATCH v4 34/34] MAINTAINERS/xsplice: Add myself and Ross as the maintainers Konrad Rzeszutek Wilk
2016-03-16 11:10 ` Jan Beulich
2016-03-17 0:44 ` Konrad Rzeszutek Wilk
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=20160322155251.GB20062@char.us.oracle.com \
--to=konrad.wilk@oracle.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=dgdegra@tycho.nsa.gov \
--cc=ian.jackson@eu.citrix.com \
--cc=julien.grall@arm.com \
--cc=keir@xen.org \
--cc=mpohlack@amazon.de \
--cc=ross.lagerwall@citrix.com \
--cc=sasha.levin@oracle.com \
--cc=stefano.stabellini@citrix.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=wei.liu2@citrix.com \
--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).