Messages in this thread | | | Subject | Re: [PATCH 1/6] xen/pvh: Support ParaVirtualized Hardware extensions. | From | Ian Campbell <> | Date | Wed, 24 Oct 2012 10:29:40 +0100 |
| |
On Tue, 2012-10-23 at 15:07 +0100, Konrad Rzeszutek Wilk wrote: > > +/* > > + * 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.
A relatively simple one, but yes.
> So I think it makes sense to modify this to be 32 and 64-bit > clean, something like this:
That works. We could just swap the domid and gpfn members around, although that ordering reads a bit unnaturally.
> > { > 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?
| |