On Thu, 2011-10-13 at 11:34 +0100, Daniel Castro wrote:
> On Wed, Oct 12, 2011 at 10:56 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx>
> wrote:
> > 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?
> Its working now after the changes, and also I noticed that back-end
> does not read key "port", instead read "event-channel" so I left both
> in case.
You only need to fill in the one which the backend reads. That is
"event-channel".
> For completeness and future references to the list here is my code:
> static struct grant_entry_v1 *grant_entries = NULL;
> struct xen_add_to_physmap xatp;
> if(grant_entries!=NULL)
> return grant_entries;
> xatp.domid = DOMID_SELF;
> xatp.space = XENMAPSPACE_grant_table;
> xatp.idx = 0;
> grant_entries = (struct grant_entry_v1 *) memalign_high(PAGE_SIZE,
> PAGE_SIZE);
> memset(grant_entries, 0, PAGE_SIZE);
> xatp.gpfn = ((unsigned long)grant_entries >> PAGE_SHIFT);
> dprintf(1, "allocated grant_entries at %d bytes at %p, gpfn
> 0x%lx\n",sizeof(*grant_entries), grant_entries, xatp.gpfn);
> if (hypercall_memory_op(XENMEM_add_to_physmap, &xatp) != 0)
> panic("MAP grant_entries info page fail");
> return grant_entries;
>
> struct gnttab_setup_table gst;
> grant_entries = (struct grant_entry_v1 *) get_grant_table();
> gst.dom = DOMID_SELF;
> gst.nr_frames = 1;
> //gst.frame_list = (struct grant_entry_v1 *) grant_entries;
This isn't needed? That would surprise me...
> res = hypercall_grant_table_op(GNTTABOP_setup_table, &gst, 1);
> if(res!=0){
> dprintf(1,"Error Mapping Grant Table... Abort...\n");
> panic("Map Grant Table Failed\n");
> }
> dprintf(1,"GNTTABOP_setup_table return %d status:%d\n",res,gst.status);
>
> After this two pieces of code I create the grant entry for the rings
> as previously discussed.
> Must fill in device details from xenstore, and, now that the back and
> front connect I have to handle requests, read and write.
>
> I guess is a matter of copy from buffer to ring, and from ring to buffer...
The block protocol involves granting the buffer and putting the ref on
the ring, not putting data inline in the ring.
However for simplicity I would suggest granting a static buffer to the
backend and copying from the SeaBIOS buffer to that.
>
> >
> > 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
|
Home