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... -- Dr Thomas Leonard http://roscidus.com/blog/ GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list [email protected] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
