[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Front-end back-end connection



On Wed, 2011-10-12 at 08:13 +0100, Daniel Castro wrote:
> Hello All,
> 
> I am in the process of conecting my front-end to my back end.
> The process is like this:
> 1. Set up xenstore conection
> 2. initiate front rings
> 3. Initiate gran table
> 4. Take my rings mfn address and set it up as a entry (more on this)
> 5. create a unbound port for front-back ring communication (more on this )
> 5.1 I start by changing state to XenbusStateInitialising
> 5.2 ring-ref entry (step 4)
> 5.3 port entry (step 5)
> 5.4 backend state is XenbusStateInitWait
> 5.4 change state to XenbusStateInitialised
> 5.5 back end state is XenbusStateClosing meaning there is an error or
> something is missing.
> 6. on sucess end
> 
> More on step 4: I got my grant page table like this:
>       struct gnttab_setup_table gst;
>       grant_entries = (struct grant_entry_v1 *) memalign_high(4096, 4096);
> //asume malloc
>       memset(grant_entries,0,4096);
>       gst.dom = DOMID_SELF; //&me
>       gst.nr_frames = 1; //a single page
>       //gst.frame_list = grant_entries; (I have no idea how to handle this :P 
> )
>       res = hypercall_grant_table_op(GNTTABOP_map_grant_ref, &gst, 1);
> I think this works, but maybe I am wrong.

I'm afraid you are.

For one thing simply not initialising one of the fields in the argument
structure is unlikely to be correct.

Secondly the argument to GNTTABOP_map_grant_ref is a pointer to "struct
gnttab_map_grant_ref" not "struct gnttab_setup_table", likewise "struct
gnttab_setup_table" goes with GNTTABOP_setup_table. I think this should
be pretty clear from the way the GNTTABOP_* and struct definitions are
laid out in xen/include/public/grant_table.h and the naming convention
what goes with what. There are also comments in that header describing
each operation.

If you are trying to setup the grant table itself then
GNTTABOP_setup_table is what you want. GNTTABOP_map_grant_ref is used
for mapping a grant reference which you have been given by another
domain.

drivers/xen/grant-table.c:gnttab_map should provide a rough idea how
this needs to be done. Because this is an HVM domain you need to do a
XENMEM_add_to_physmap of XENMAPSPACE_grant_table before you do the
GNTTABOP_setup_table.

>  This is needed on step 5, so..
> More on step 5:
> I consider the grant table an array of type struct grant_entry_v1.
> So I simply do grant_entry_v1[0] for my first grant entry, and so
> forth. For this case I read on the list some time ago that entry 0 did
> not work, so I work with entry 1, like this:
> grant_entries[aval_grant].domid = ext_domid;
> grant_entries[aval_grant].frame = _frame; where frame is: (u32)sring
> >> PAGE_SHIFT //meaning mfn of my rings.
> grant_entries[aval_grant].flags = GTF_permit_access;

This looks approximately correct _if_ you were actually writing to some
memory which was your grant table but due to the above I think you are
not.

> These last two steps I described may be wrong... I know this because
> the backend state is not XenbusStateConnected.

That fact alone can't tell you much other than _something_ went wrong.

Since the backend will have transitioned to XenbusStateClosing by
calling xenbus_dev_fatal() it will have written some error information
to xenstore and the dom0 console which should hint at what actually went
wrong. I expect you will see the message "mapping ring-ref %lu port %u"
because xen_blkif_map will have failed during map_frontend_page().

> I think my mistake is on step 5, so can someone please shed some light
> on this small issue.
> 
> And thank you very much for taking the time to read.
> 
> Daniel
> 



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.