lkml.org 
[lkml]   [2012]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/6] xen/pvh: Support ParaVirtualized Hardware extensions.
    > +/*
    > + * Unmaps the page appearing at a particular GPFN from the specified guest's
    > + * pseudophysical address space.
    > + * arg == addr of xen_remove_from_physmap_t.
    > + */
    > +#define XENMEM_remove_from_physmap 15
    > +struct xen_remove_from_physmap {
    > + /* Which domain to change the mapping for. */
    > + domid_t domid;
    > +
    > + /* GPFN of the current mapping of the page. */
    > + xen_pfn_t gpfn;
    > +};

    I just realized that this a bit of unfortunate. We end up
    with on 64-bit with this layout:

    {
    0->1 [domid]
    2->7 [nothing]
    8->16 [gpfn]

    }

    which if one were to do a 32-bit build you would get:
    {
    0->1 [domid]
    2->3 [nothing]
    4->7 [gpfn]
    }
    which means another compat layer in Xen.

    So I think it makes sense to modify this to be 32 and 64-bit
    clean, something like this:

    {
    domid_t domid;
    u8 pad[6];
    xen_pfn_t gpfn;
    /* xen_pfn_t under 32-bit x86 is 4 bytes, so extend it */
    #ifdef CONFIG_X86_32
    __u8 pad1[4];
    #endif
    }

    that way the structure is exactly the same size and the offsets
    align.

    Mukesh, you OK with that?


    \
     
     \ /
      Last update: 2012-10-23 19:21    [W:4.067 / U:0.116 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site