wait the backend-id has been created by Xen before trying to read it

[palainp]

This is needed to avoid an exception when we want to connect the uplink (See #106 (reopen and discussion there?) and mirage/qubes-mirage-firewall#156 for details. I'm now facing that issue when I want to be ablke to dynamically change the qubes-mirage-firewall netvm, see https://github.com/palainp/qubes-mirage-firewall/tree/common-vif).

Steps to reproduce are like (in the context of Qubes, but I assume there's something similar with plain Xen):

• connect to backend Netif.connect "0" >>= fun net ->
• change the netvm in Qubes (that will change our backend and we need to disconnect and reconnect)
• Disconnect Netif.disconnect net;
• And reconnect as step 1

That will trigger a Enoent exception (it seems that the backend-id key is not written fast enough) from xenstore.ml:265:

Fatal error: exception Xs_protocol.Enoent("read")
Raised at Xs_protocol.response in file "duniverse/ocaml-xenstore/core/xs_protocol.ml", line 681, characters 20-39
Called from Xs_client_lwt.Client.rpc.(fun) in file "duniverse/ocaml-xenstore/client_lwt/xs_client_lwt.ml", line 318, characters 13-50
Called from Lwt.Sequential_composition.bind.create_result_promise_and_callback_if_deferred.callback in file "duniverse/lwt/src/core/lwt.ml", line 1849, characters 23-26
Re-raised at Lwt.Miscellaneous.poll in file "duniverse/lwt/src/core/lwt.ml", line 3077, characters 20-29
Called from Xen_os__Main.run.aux in file "duniverse/mirage-xen/lib/main.ml", line 37, characters 10-20
Called from Dune__exe__Main.run in file "main.ml" (inlined), line 3, characters 12-29
Called from Dune__exe__Main in file "main.ml", line 114, characters 5-10
Solo5: solo5_exit(2) called

With that PR I don't see anymore the exception, but maybe there is other places to put that "wait before read"? Or maybe it should be a default behavior and read becomes read_unsafe?

[djs55]

Thanks for the PR!

To be honest I've never been sure exactly when various keys are written (and whether they are written in a transaction with other keys or not).

I think it's a reasonable approach to use a xenstore watch here.

[palainp]

Dear @djs55 , thanks for your comment!

In the last commit I fixed the CI errors, and I'll leave the choice of extending safe_read to other reads for later, for now I want to be conservative :)