Re: [Xen-devel] [PATCH V8 2/4] x86/altp2m: Add hypercall to set a range of sve bits

[Jan Beulich <jbeulich@xxxxxxxx>]

On 17.01.2020 14:31, Alexandru Stefan ISAILA wrote:
> By default the sve bits are not set.
> This patch adds a new hypercall, xc_altp2m_set_supress_ve_multi(),
> to set a range of sve bits.
> The core function, p2m_set_suppress_ve_multi(), does not break in case
> of a error and it is doing a best effort for setting the bits in the
> given range. A check for continuation is made in order to have
> preemption on large ranges.
> The gfn of the first error is stored in
> xen_hvm_altp2m_suppress_ve_multi.first_error_gfn and the error code is
> stored in xen_hvm_altp2m_suppress_ve_multi.first_error.
> If no error occurred the values will be 0.

I'm sorry for being nitpicky here, but this still isn't fully in
line with ...

> --- a/xen/include/public/hvm/hvm_op.h
> +++ b/xen/include/public/hvm/hvm_op.h
> @@ -46,6 +46,16 @@ struct xen_hvm_altp2m_suppress_ve {
>      uint64_t gfn;
>  };
>  
> +struct xen_hvm_altp2m_suppress_ve_multi {
> +    uint16_t view;
> +    uint8_t suppress_ve; /* Boolean type. */
> +    uint8_t pad1;
> +    int32_t first_error; /* Should be set to 0. */
> +    uint64_t first_gfn; /* Value may be updated. */
> +    uint64_t last_gfn;
> +    uint64_t first_error_gfn; /* Gfn of the first error. */
> +};

... this: There's nothing said here about zeroing first_error_gfn
(and FAOD there doesn't need to be), and even first_error correctly
says only "should". Hence the values will be non-zero when there
was no error only if the caller had set them to zero. Anyway, this
alone surely is no reason for a v9, so take it just as a benign
(for the moment) remark.

Jan

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