[Xen-devel] Hypercall interface changes for PAE

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 31 May 2005, at 12:36, Gerd Knorr wrote:

> Thanks.  At least the "pae-support" patches being merged would
> be really nice as it touches many places and breaks all the time
> due to some updates in xen.  The hypercall interface changes
> probably need some more work in the tools, I'm trying to get
> domU's up with the changed hypercall interface.
Gerd,

Having looked at the PAE patch and thought about the issue some more, 
I'm actually inclined not to split pfn and flags at the hypercall 
interface (e.g., mmu_update_t, do_update_va_mapping()). IIRC I think 
you wanted not to do this in the first place. :-)
I now think that this is a rather arbitrary interface to impose on 
guests. Also it means that we increase the size of mmu_update_t on 
non-PAE, and change the interface unnecessarily for non-PAE. The thing 
that really changed my mind is that the no-execute bit is bit 63 of a 
page-table entry -- so we would need to 'cook' that down into a 32-bit 
flags value to pass across the hypercall interface. Another arbitrary 
and frankly gross thing to have to do.
I think changing val to u64 in mmu_update_t (for 32-bit PAE builds), 
and changing the val to u64 in update_va_mapping(), is probably the way 
to go. Of course, the machine address of the PTE to be modified will 
also need to be a u64. :-)
The downside of this approach is that the C declarations of 
mmu_update_t, update_va_mapping, etc are different on 32-bit PAE 
builds. But only low-level guest code will touch those interfaces 
anyway, and there is unlikely to be code sharing between PAE and 
non-PAE at that level.
What do you think?

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel