Re: [Xen-devel] [PATCH 4/4] xen: Add V4V implementation

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.10.12 at 17:02, Jean Guyader <jean.guyader@xxxxxxxxx> wrote:
> On 4 October 2012 13:11, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>> On 04.10.12 at 14:03, Jean Guyader <jean.guyader@xxxxxxxxx> wrote:
>>> On 20 September 2012 13:20, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>>>> On 20.09.12 at 13:42, Jean Guyader <jean.guyader@xxxxxxxxxx> wrote:
>>>>>+        case V4VOP_register_ring:
>>>>>+            {
>>>>>+                XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd =
>>>>>+                    guest_handle_cast(arg1, v4v_ring_t);
>>>>>+                XEN_GUEST_HANDLE(xen_pfn_t) pfn_hnd =
>>>>>+                    guest_handle_cast(arg2, xen_pfn_t);
>>>>>+                uint32_t npage = arg3;
>>>>>+                if ( unlikely(!guest_handle_okay(ring_hnd, 1)) )
>>>>>+                    goto out;
>>>>>+                if ( unlikely(!guest_handle_okay(pfn_hnd, npage)) )
>>>>>+                    goto out;
>>>>
>>>> Here and below - this isn't sufficient for compat guests, or else
>>>> you give them a way to point into the compat m2p table.
>>>>
>>>
>>> I'll probably switch to uint64_t for the v4v mfn list instead of using
>>> xen_pfn_t which
>>> are unsigned long. That way I can save the need for a compat wrapper.
>>
>> But that comment of yours doesn't address the problem I pointed
>> out.
>>
> 
> I'm sorry, I don't really get what you mean them. I've tried to get
> all my struct
> layout such as all the offset for the field are the same for 64b and 32b, 
> this
> way I thought I could get away with doing a compat wrapper.

guest_handle_okay() simply isn't suitable for checking compat mode
pointers - compat_handle_okay() needs to be used for them instead.

Jan


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