All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tamas K Lengyel <tamas.k.lengyel@gmail.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Tamas K Lengyel" <tamas.lengyel@intel.com>,
	"Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 01/18] x86/hvm: introduce hvm_copy_context_and_params
Date: Thu, 16 Jan 2020 07:06:51 -0700	[thread overview]
Message-ID: <CABfawhmFHic1xHOJLNP9ScyLoqi8Wc2kaKqzoAKjGmovgmtfjw@mail.gmail.com> (raw)
In-Reply-To: <e99f9fea-3173-83c8-110f-a7d5d72d2961@suse.com>

On Thu, Jan 16, 2020 at 5:28 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 08.01.2020 18:13, Tamas K Lengyel wrote:
> > @@ -4129,49 +4130,32 @@ static int hvm_allow_set_param(struct domain *d,
> >      return rc;
> >  }
> >
> > -static int hvmop_set_param(
> > -    XEN_GUEST_HANDLE_PARAM(xen_hvm_param_t) arg)
> > +static int hvm_set_param(struct domain *d, uint32_t index, uint64_t value)
> >  {
> >      struct domain *curr_d = current->domain;
> > -    struct xen_hvm_param a;
> > -    struct domain *d;
> > -    struct vcpu *v;
> >      int rc;
> > +    struct vcpu *v;
>
> Nit: Personally I'd prefer if "rc" remained last.
>
> > +int hvmop_set_param(
> > +    XEN_GUEST_HANDLE_PARAM(xen_hvm_param_t) arg)
> > +{
> > +    struct xen_hvm_param a;
> > +    struct domain *d;
> > +    int rc;
> > +
> > +    if ( copy_from_guest(&a, arg, 1) )
> > +        return -EFAULT;
> > +
> > +    if ( a.index >= HVM_NR_PARAMS )
> > +        return -EINVAL;
> > +
> > +    /* Make sure the above bound check is not bypassed during speculation. */
> > +    block_speculation();
> > +
> > +    d = rcu_lock_domain_by_any_id(a.domid);
> > +    if ( d == NULL )
> > +        return -ESRCH;
> > +
> > +    rc = -EINVAL;
> > +    if ( !is_hvm_domain(d) )
> > +        goto out;
> > +
> > +    rc = hvm_set_param(d, a.index, a.value);
>
> With
>
>     rc = -EINVAL;
>     if ( is_hvm_domain(d) )
>         rc = hvm_set_param(d, a.index, a.value);
>
> the function wouldn't need an "out" label (and hence any goto)
> anymore. I know others are less picky about goto-s than me, but
> I think in cases where it's easy to avoid them they would better
> be avoided.
>
> > @@ -4400,6 +4414,43 @@ static int hvm_allow_get_param(struct domain *d,
> >      return rc;
> >  }
> >
> > +static int hvm_get_param(struct domain *d, uint32_t index, uint64_t *value)
> > +{
> > +    int rc;
> > +
> > +    if ( index >= HVM_NR_PARAMS || !value )
> > +        return -EINVAL;
>
> I don't think the range check is needed here: It's redundant with
> that in hvmop_get_param() and pointless for the new function you
> add. (Same for "set" then, but I noticed it here first.) I also
> don't think value needs checking against NULL in a case like this
> one (we don't typically do so elsewhere in similar situations).
>
> > @@ -5266,6 +5294,37 @@ void hvm_set_segment_register(struct vcpu *v, enum x86_segment seg,
> >      alternative_vcall(hvm_funcs.set_segment_register, v, seg, reg);
> >  }
> >
> > +int hvm_copy_context_and_params(struct domain *src, struct domain *dst)
>
> Following memcpy() and alike, perhaps better to have dst first and
> src second?
>
> > +{
> > +    int rc, i;
>
> unsigned int for i please.
>
> > +    struct hvm_domain_context c = { };
> > +
> > +    c.size = hvm_save_size(src);
>
> Put in the variable's initializer?
>
> > +    if ( (c.data = xmalloc_bytes(c.size)) == NULL )
>
> How likely is it for this to be more than a page's worth of space?
> IOW wouldn't it be better to use vmalloc() here right away, even if
> right now this may still fit in a page (which I'm not sure it does)?

I'm not sure what the size is normally, never checked.

>
> > +        return -ENOMEM;
> > +
> > +    for ( i = 0; i < HVM_NR_PARAMS; i++ )
> > +    {
> > +        uint64_t value = 0;
> > +
> > +        if ( hvm_get_param(src, i, &value) || !value )
> > +            continue;
> > +
> > +        if ( (rc = hvm_set_param(dst, i, value)) )
> > +            goto out;
> > +    }
> > +
> > +    if ( (rc = hvm_save(src, &c)) )
> > +        goto out;
>
> Better do this ahead of the loop? There's no point in fiddling with
> dst if this fails, I would think.

Thanks for the review, I don't have any objections to the things you
pointed out.

Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2020-01-16 14:08 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-08 17:13 [Xen-devel] [PATCH v4 00/18] VM forking Tamas K Lengyel
2020-01-08 17:13 ` [Xen-devel] [PATCH v4 01/18] x86/hvm: introduce hvm_copy_context_and_params Tamas K Lengyel
2020-01-16 12:27   ` Jan Beulich
2020-01-16 14:06     ` Tamas K Lengyel [this message]
2020-01-08 17:13 ` [Xen-devel] [PATCH v4 02/18] xen/x86: Make hap_get_allocation accessible Tamas K Lengyel
2020-01-08 17:14 ` [Xen-devel] [PATCH v4 03/18] x86/mem_sharing: make get_two_gfns take locks conditionally Tamas K Lengyel
2020-01-08 17:14 ` [Xen-devel] [PATCH v4 04/18] x86/mem_sharing: drop flags from mem_sharing_unshare_page Tamas K Lengyel
2020-01-08 17:14 ` [Xen-devel] [PATCH v4 05/18] x86/mem_sharing: don't try to unshare twice during page fault Tamas K Lengyel
2020-01-16 14:53   ` Jan Beulich
2020-01-16 15:59     ` Tamas K Lengyel
2020-01-16 16:03       ` Jan Beulich
2020-01-08 17:14 ` [Xen-devel] [PATCH v4 06/18] x86/mem_sharing: define mem_sharing_domain to hold some scattered variables Tamas K Lengyel
2020-01-16 15:23   ` Jan Beulich
2020-01-16 16:05     ` Tamas K Lengyel
2020-01-16 16:08       ` Jan Beulich
2020-01-08 17:14 ` [Xen-devel] [PATCH v4 07/18] x86/mem_sharing: Use INVALID_MFN and p2m_is_shared in relinquish_shared_pages Tamas K Lengyel
2020-01-16 15:40   ` Jan Beulich
2020-01-08 17:14 ` [Xen-devel] [PATCH v4 08/18] x86/mem_sharing: Make add_to_physmap static and shorten name Tamas K Lengyel
2020-01-16 15:40   ` Jan Beulich
2020-01-08 17:14 ` [Xen-devel] [PATCH v4 09/18] x86/mem_sharing: Convert MEM_SHARING_DESTROY_GFN to a bool Tamas K Lengyel
2020-01-16 15:42   ` Jan Beulich
2020-01-08 17:14 ` [Xen-devel] [PATCH v4 10/18] x86/mem_sharing: Replace MEM_SHARING_DEBUG with gdprintk Tamas K Lengyel
2020-01-16 16:01   ` Jan Beulich
2020-01-08 17:14 ` [Xen-devel] [PATCH v4 11/18] x86/mem_sharing: ASSERT that p2m_set_entry succeeds Tamas K Lengyel
2020-01-16 16:07   ` Jan Beulich
2020-01-16 16:12     ` Tamas K Lengyel
2020-01-17  9:23       ` Jan Beulich
2020-01-17 16:59         ` Tamas K Lengyel
2020-01-08 17:14 ` [Xen-devel] [PATCH v4 12/18] x86/mem_sharing: Enable mem_sharing on first memop Tamas K Lengyel
2020-01-16 16:18   ` Jan Beulich
2020-01-16 16:34     ` Tamas K Lengyel
2020-01-08 17:14 ` [Xen-devel] [PATCH v4 13/18] x86/mem_sharing: Skip xen heap pages in memshr nominate Tamas K Lengyel
2020-01-20 16:23   ` Jan Beulich
2020-01-20 16:32     ` Tamas K Lengyel
2020-01-20 16:38       ` Jan Beulich
2020-01-08 17:14 ` [Xen-devel] [PATCH v4 14/18] x86/mem_sharing: check page type count earlier Tamas K Lengyel
2020-01-20 16:34   ` Jan Beulich
2020-01-20 16:46     ` Tamas K Lengyel
2020-01-08 17:14 ` [Xen-devel] [PATCH v4 15/18] xen/mem_sharing: VM forking Tamas K Lengyel
2020-01-09 10:28   ` Julien Grall
2020-01-09 13:41     ` Tamas K Lengyel
2020-01-09 15:10       ` Roger Pau Monné
2020-01-09 15:34         ` Jan Beulich
2020-01-09 15:57           ` Tamas K Lengyel
2020-01-09 16:03             ` Jan Beulich
2020-01-09 16:06               ` Tamas K Lengyel
2020-01-09 15:54         ` Tamas K Lengyel
2020-01-08 17:14 ` [Xen-devel] [PATCH v4 16/18] xen/mem_access: Use __get_gfn_type_access in set_mem_access Tamas K Lengyel
2020-01-08 17:14 ` [Xen-devel] [PATCH v4 17/18] x86/mem_sharing: reset a fork Tamas K Lengyel
2020-01-09 10:30   ` Julien Grall
2020-01-08 17:14 ` [Xen-devel] [PATCH v4 18/18] xen/tools: VM forking toolstack side Tamas K Lengyel
2020-01-16 15:47 ` [Xen-devel] [PATCH v4 00/18] VM forking Jan Beulich
2020-01-16 16:24   ` Tamas K Lengyel
2020-01-17  9:12     ` Jan Beulich
2020-01-17 11:15       ` Anthony PERARD
2020-01-17 14:22         ` Tamas K Lengyel
2020-01-17 14:25       ` Tamas K Lengyel

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=CABfawhmFHic1xHOJLNP9ScyLoqi8Wc2kaKqzoAKjGmovgmtfjw@mail.gmail.com \
    --to=tamas.k.lengyel@gmail.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=roger.pau@citrix.com \
    --cc=tamas.lengyel@intel.com \
    --cc=wl@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.