On 21 Dec 2015, at 17:51, Thomas Leonard <[email protected]> wrote: > > On 21 December 2015 at 10:42, Thomas Leonard <[email protected]> wrote: >> I'm trying to use a Mirage Xen unikernel to provide networking to >> other client VMs, using the experimental new netback support [1]. >> >> It works fine when the client is also a Mirage unikernel, but Linux >> clients kernel panic: > > OK, mystery solved! There was a bug in TX.Response.write that meant it > didn't set the ID field. Since the slot had just been used for the > Request, the gref field from the request ended up being sent as the id > field in the reply. > > The Linux netfront driver doesn't check that the ID it got back > corresponds to one it actually sent, but just takes whatever's at that > index in its table (or whatever is at the location that would be that > index of the table if the table were that big). This is typically 0, > which it interprets as grant ref 0 rather than "invalid" and then > complains that ref 0 is still mapped. > > The Mirage netfront driver always uses the gref as the ID, so it > worked anyway there. > > Actually, using the gref as ID doesn't make sense, because two > requests can share the same gref. Lwt_ring didn't notice, because it > uses Hashtbl.add instead of Hashtbl.replace and so allows multiple > requests with the same ID. Presumably they get ack'd in the wrong > order, causing some pages to be returned to the free pool too soon. > Will fix...
Fantastic detective work! So this also means that the Linux netfront driver doesn't obey the grant protocol correctly with respect to out of order responses on the ring... We should get a mirage-net-xen release out with these fixes asap though; is your current PR enough to improve the state of affairs, or do you want to wait until the gref-as-ID assumption is fixed? Anil _______________________________________________ MirageOS-devel mailing list [email protected] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
