| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
|
|
|
| |
|
Home