Messages in this thread | | | Date | Tue, 23 Oct 2012 10:07:53 -0400 | From | Konrad Rzeszutek Wilk <> | Subject | Re: [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?
| |