[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |