[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 10/13] xen: XEN_DOMCTL_sethvmcontext hypercall



On Thu, 2013-11-28 at 18:56 +0000, Andrew Cooper wrote:
> +   case VKI_XEN_DOMCTL_sethvmcontext:
> +       __PRE_XEN_DOMCTL_READ(sethvmcontext, hvmcontext, size);
> +       __PRE_XEN_DOMCTL_READ(sethvmcontext, hvmcontext, buffer);
> +       PRE_MEM_READ("XEN_DOMCTL_sethvmcontext *buffer",
> +                    (Addr)domctl->u.hvmcontext.buffer.p,

This is the common idiom so I don't intend to block this series for it,
but:

Do you think these uses of .p are correct? I'm wondering if we ought not
to actually be marking as read the entire struct, including the padded
"q" member, perhaps by making the guest handles be of some non-struct
type.

I'm thinking of a 32-on-64 situation where the 32-bit userland fills in
the bottom 4 bytes but the hypervisor actually reads all 8 and assumes
the top is 0 (which is done in the set_xen_guest_handle_raw definition
for x86_32).

Thoughts?

> +                    domctl->u.hvmcontext.size);
> +       break;
> +
>     case VKI_XEN_DOMCTL_max_mem:
>        PRE_XEN_DOMCTL_READ(max_mem, max_memkb);
>        break;
> @@ -1068,6 +1076,7 @@ POST(domctl){
>     case VKI_XEN_DOMCTL_setnodeaffinity:
>     case VKI_XEN_DOMCTL_set_cpuid:
>     case VKI_XEN_DOMCTL_unpausedomain:
> +   case VKI_XEN_DOMCTL_sethvmcontext:
>        /* No output fields */
>        break;
>  



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.