WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Use of XEN_GUEST_HANDLE

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] Use of XEN_GUEST_HANDLE
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Sat, 24 May 2008 23:10:44 +0100
Cc: sandesh <sandesh.ahiremath@xxxxxxxxx>
Delivery-date: Sat, 24 May 2008 15:11:09 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <17357081.post@xxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <17357081.post@xxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.9
>    I have recently started to go through xen source. I want to know the
> usage of XEN_GUEST_HANDLE.
>  I see thats its just a macro which will prefix each data type with
> __guest_handle_ . And DEFINE_XEN_GUEST_HANDLE(name) will just typedefs
> '__guest_handle_name' to be a pointer to a data type 'name ' .

I think this was introduced for use on non-x86 architectures where it wouldn't 
necessarily be possible to simply pass a virtual address to a data structure 
down to Xen.  I'm not clear on the details but you can search for the 
discussion on the xen-devel list, it happened quite a long time ago but if 
you look for threads mentioning guest handles, Keir Fraser and Hollis 
Blanchard that should help you narrow it down ;-)

> What is the reason for such abstraction?

On x86, Xen lives at the top of the process address space, so it's possible to 
pass virtual address pointers to structures in the guest's application memory 
space (in practice, these are in the address space of the dom0 control 
processes) directly down to Xen.  On other architectures such as PPC (which 
is not supported anymore, anyhow) Xen ran in physical addressing mode and so 
couldn't access virtual addresses directly at all.

The guest handle abstraction was put in place to allow PPC (and potentially 
other) ports to implement a different way of addressing structures that 
assumed less x86-like architecture behaviour.

I'm afraid I'm not familiar with the details, although if you look back in the 
hg history to before the PPC port was removed a few weeks ago you might be 
able to see some more examples of it being used.  The IA64 port may use it 
too, I'm not sure...

> And how this XEN_GUEST_HANDLE different from 'guest_xc' field of 'struct
> xc_dom_image', which gets initialized with xc_handle.

That's a completely different thing, actually.  The xc_handle is just a file 
descriptor pointing to the privcmd interface in dom0.  The control tools open 
the privcmd virtual file and then they call the integer file descriptor 
the "xc handle".

I'm not sure exactly why xc_handle values would be stored in guest_xc rather 
than elsewhere.  Maybe that's just an easy way of keeping track of things.

> I have serached the net extensively for answers, but unable to get any. So
> any info or pointers would be highly appriciated.

Hope this info helps.  Also, since it's now in the mailing list archives I 
hope that anybody searching for this in future will find more useful 
information :-)

Cheers,
Mark


-- 
Push Me Pull You - Distributed SCM tool (http://www.cl.cam.ac.uk/~maw48/pmpu/)

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

<Prev in Thread] Current Thread [Next in Thread>