Re: [Xen-devel] [PATCH v3 3/3] altp2m: Implement p2m_get_mem_access for altp2m views

["Lengyel, Tamas" <tlengyel@xxxxxxxxxxx>]

On Tue, Feb 9, 2016 at 10:17 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:

>>> On 05.02.16 at 22:22, <tlengyel@xxxxxxxxxxx> wrote:
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -423,11 +423,20 @@ struct xen_mem_access_op {
>Â Â Â /* xenmem_access_t */
>Â Â Â uint8_t access;
>Â Â Â domid_t domid;
> -Â Â /*
> -Â Â Â* Number of pages for set op
> -Â Â Â* Ignored on setting default access and other ops
> -Â Â Â*/
> -Â Â uint32_t nr;
> +Â Â union {
> +Â Â Â Â /*
> +Â Â Â Â Â* Number of pages for set op
> +Â Â Â Â Â* Ignored on setting default access and other ops
> +Â Â Â Â Â*/
> +Â Â Â Â uint32_t nr;
> +Â Â Â Â /*
> +Â Â Â Â Â* altp2m id used for get op, ignored for other ops
> +Â Â Â Â Â*/
> +Â Â Â Â struct altp2m {
> +Â Â Â Â Â Â uint16_t idx;
> +Â Â Â Â Â Â uint16_t pad;
> +Â Â Â Â } altp2m;
> +Â Â } u;

Am I overlooking something, or is this new padding field not being
checked to be zero on input (allowing seamless use for an actual
purpose later on)? It's a tools-only interface (i.e. not considered
stable), but anyway...

There is no plan to use it for anything in this context in the future so we could enforce it being zero. However, even if someone erroneously used the nr field and set some arbitrary large number in there, the altp2m idx is checked to be sure it's not larger then the max supported, so IMHO there is enough error checking on it in place already.

Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel