All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Alexandru Stefan ISAILA <aisaila@bitdefender.com>
Cc: "Kevin Tian" <kevin.tian@intel.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Julien Grall" <julien@xen.org>, "Wei Liu" <wl@xen.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	"George Dunlap" <George.Dunlap@eu.citrix.com>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Ian Jackson" <ian.jackson@eu.citrix.com>,
	"Jun Nakajima" <jun.nakajima@intel.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH V2] x86/altp2m: Hypercall to set altp2m view visibility
Date: Mon, 17 Feb 2020 15:14:00 +0100	[thread overview]
Message-ID: <e20d6574-0e76-acf8-8b33-fb5a4fce7908@suse.com> (raw)
In-Reply-To: <20200130130649.14538-1-aisaila@bitdefender.com>

On 30.01.2020 14:07, Alexandru Stefan ISAILA wrote:
> @@ -4814,6 +4815,30 @@ static int do_altp2m_op(
>          break;
>      }
>  
> +    case HVMOP_altp2m_set_visibility:
> +    {
> +        uint16_t altp2m_idx = a.u.set_visibility.altp2m_idx;
> +
> +        if ( a.u.set_visibility.pad || a.u.set_visibility.pad2 )
> +            rc = -EINVAL;
> +        else
> +        {
> +            if ( !altp2m_active(d) || !hap_enabled(d) )

Doesn't altp2m_active() imply hap_enabled()? At the very least
there's no other use of hap_enabled() in do_altp2m_op().

> +            {
> +                rc = -EOPNOTSUPP;
> +                break;
> +            }
> +
> +            if ( a.u.set_visibility.visible )
> +                d->arch.altp2m_working_eptp[altp2m_idx] =
> +                d->arch.altp2m_eptp[altp2m_idx];
> +            else
> +                d->arch.altp2m_working_eptp[altp2m_idx] =
> +                mfn_x(INVALID_MFN);
> +        }
> +        break;

Also the code here lends itself to reduction of indentation
depth:

    case HVMOP_altp2m_set_visibility:
    {
        uint16_t altp2m_idx = a.u.set_visibility.altp2m_idx;

        if ( a.u.set_visibility.pad || a.u.set_visibility.pad2 )
            rc = -EINVAL;
        else if ( !altp2m_active(d) || !hap_enabled(d) )
                rc = -EOPNOTSUPP;
        else if ( a.u.set_visibility.visible )
            d->arch.altp2m_working_eptp[altp2m_idx] =
                d->arch.altp2m_eptp[altp2m_idx];
        else
            d->arch.altp2m_working_eptp[altp2m_idx] =
                mfn_x(INVALID_MFN);

        break;
    }


Also note the altered indentation of the assignments.

> --- a/xen/arch/x86/mm/hap/hap.c
> +++ b/xen/arch/x86/mm/hap/hap.c
> @@ -488,8 +488,17 @@ int hap_enable(struct domain *d, u32 mode)
>              goto out;
>          }
>  
> +        if ( (d->arch.altp2m_working_eptp = alloc_xenheap_page()) == NULL )
> +        {
> +            rv = -ENOMEM;
> +            goto out;
> +        }

Isn't there a pre-existing error handling issue here which you
widen, in that later encountered errors don't cause clean up
of what had already succeeded before?

> @@ -2651,6 +2652,8 @@ int p2m_destroy_altp2m_by_id(struct domain *d, unsigned int idx)
>              p2m_reset_altp2m(d, idx, ALTP2M_DEACTIVATE);
>              d->arch.altp2m_eptp[array_index_nospec(idx, MAX_EPTP)] =
>              mfn_x(INVALID_MFN);
> +            d->arch.altp2m_working_eptp[array_index_nospec(idx, MAX_EPTP)] =
> +            mfn_x(INVALID_MFN);

Like above, and irrespective of you cloning existing code -
indentation of the 2nd line is wrong here.

> --- a/xen/include/public/hvm/hvm_op.h
> +++ b/xen/include/public/hvm/hvm_op.h
> @@ -317,6 +317,13 @@ struct xen_hvm_altp2m_get_vcpu_p2m_idx {
>      uint16_t altp2m_idx;
>  };
>  
> +struct xen_hvm_altp2m_set_visibility {
> +    uint16_t altp2m_idx;
> +    uint8_t visible;
> +    uint8_t pad;
> +    uint32_t pad2;
> +};

What is pad2 good/intended for? 32-bit padding fields in some
other structures are needed because one or more uint64_t
fields follow, but this isn't the case here.

Jan

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

  parent reply	other threads:[~2020-02-17 14:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-30 13:07 [Xen-devel] [PATCH V2] x86/altp2m: Hypercall to set altp2m view visibility Alexandru Stefan ISAILA
2020-02-07  8:54 ` Alexandru Stefan ISAILA
2020-02-17 11:52 ` [Xen-devel] Ping: " Alexandru Stefan ISAILA
2020-02-17 14:14 ` Jan Beulich [this message]
2020-02-18  8:13   ` [Xen-devel] " Alexandru Stefan ISAILA
2020-02-18 14:42     ` Alexandru Stefan ISAILA
2020-02-18 14:47       ` Jan Beulich

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=e20d6574-0e76-acf8-8b33-fb5a4fce7908@suse.com \
    --to=jbeulich@suse.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=aisaila@bitdefender.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=julien@xen.org \
    --cc=jun.nakajima@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=konrad.wilk@oracle.com \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --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.