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

[Jean Guyader <jean.guyader@xxxxxxxxx>]

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.
>

[Resent, CCing everyone this time]

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.

Thanks,
Jean

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