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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2011-10-12 at 13:02 +0100, Daniel Castro wrote:
> On Wed, Oct 12, 2011 at 7:12 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> > 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.
> 
> Fixed. Yet, how can I confirm that the grant table was correctly
> mapped? The hypercall returned 0 and the status in the struct is also
> 0.
> After the mapping I am printing this:
> allocated grant_entries at 12 bytes at 0x0f7fc000, gpfn 0xf7fc
> GNTTABOP_setup_table return 0 status:0
> allocated shared info 2584 bytes at 0x0f7fa000, gpfn 0xf7fa

Did you also call XENMEM_add_to_physmap somewhere?

I'm afraid these messages are pretty meaningless without the
corresponding code, but you should certainly have already setup the
table before you start allocating grant_entries in it (or more
importantly writing to them). These messages suggest that is not the
case?

> I also found that the port I get from the EVTCHNOP_alloc_unbound is 4,
> but lsevtchn gets me this:
>   42: VCPU 0: Interdomain (Connected) - Remote Domain 5, Port 2
>   43: VCPU 0: Interdomain (Connected) - Remote Domain 5, Port 3
>   44: VCPU 0: Interdomain (Connected) - Remote Domain 5, Port 1
> Port 4 is not listed, is it because it is not connected yet?

If this is lsevtchn for dom0 then most likely yes. You should be able to
see the guest's state with lsevtchn <domid>.

In the backend the evtchn gets bound after the frontend's shared ring is
mapped so the fact that the evtchn didn't get bound suggests an error
before that point.

> I get no errors in xl dmesg, and in dmesg I get:
> vbd vbd-5-768: 2 reading /local/domain/5/device/vbd/768/ring-ref and
> event-channel

Do you see anything else in xenstore? 

> I guess there are the keys I write in the front-end, so they are being read.
> 
> Thanks for the help, I feel we are getting closer to the other side...
> 
> Daniel
> 
> >
> >>  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