{"action":"created","issue":{"url":"https://api.github.com/repos/mirleft/ocaml-nocrypto/issues/70","labels_url":"https://api.github.com/repos/mirleft/ocaml-nocrypto/issues/70/labels{/name}","comments_url":"https://api.github.com/repos/mirleft/ocaml-nocrypto/issues/70/comments","events_url":"https://api.github.com/repos/mirleft/ocaml-nocrypto/issues/70/events","html_url":"https://github.com/mirleft/ocaml-nocrypto/issues/70","id":90074976,"number":70,"title":"--enable-modernity results in instacrash for xen unikernels","user":{"login":"yomimono","id":4086825,"avatar_url":"https://avatars.githubusercontent.com/u/4086825?v=3","gravatar_id":"","url":"https://api.github.com/users/yomimono","html_url":"https://github.com/yomimono","followers_url":"https://api.github.com/users/yomimono/followers","following_url":"https://api.github.com/users/yomimono/following{/other_user}","gists_url":"https://api.github.com/users/yomimono/gists{/gist_id}","starred_url":"https://api.github.com/users/yomimono/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/yomimono/subscriptions","organizations_url":"https://api.github.com/users/yomimono/orgs","repos_url":"https://api.github.com/users/yomimono/repos","events_url":"https://api.github.com/users/yomimono/events{/privacy}","received_events_url":"https://api.github.com/users/yomimono/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":8,"created_at":"2015-06-22T11:31:01Z","updated_at":"2015-06-23T15:35:01Z","closed_at":null,"body":"I'm building unikernels with `mirage-seal` version 0.3.1.  I have the following pins set:\r\n\r\n$ opam pin list\r\nnocrypto.0.4.0            path     /home/dothraki/ocaml-nocrypto\r\ntls.0.5.0                 git      https://github.com/mirleft/ocaml-tls#naming-updates\r\nx509.0.3.1                git      https://github.com/mirleft/ocaml-x509#naming\r\n\r\nThe local FS pin of nocrypto is master as of 61023ea .  Running mirage-seal with this configuration results in a unikernel which crashes on boot (the results of `xl dump-core` for such a run are available if helpful):\r\n\r\n```\r\n$ sudo xl create seal.xl -c\r\nParsing config from seal.xl\r\nXen Minimal OS!\r\n  start_info: 00000000003e6000(VA)\r\n    nr_pages: 0x2000\r\n  shared_inf: 0xd9678000(MA)\r\n     pt_base: 00000000003e9000(VA)\r\nnr_pt_frames: 0x7\r\n    mfn_list: 00000000003d6000(VA)\r\n   mod_start: 0x0(VA)\r\n     mod_len: 0\r\n       flags: 0x0\r\n    cmd_line: \r\n       stack: 00000000003b5820-00000000003d5820\r\nMM: Init\r\n      _text: 0000000000000000(VA)\r\n     _etext: 000000000020fe1f(VA)\r\n   _erodata: 0000000000272000(VA)\r\n     _edata: 000000000037bc20(VA)\r\nstack start: 00000000003b5820(VA)\r\n       _end: 00000000003d5820(VA)\r\n  start_pfn: 3f3\r\n    max_pfn: 2000\r\nMapping memory range 0x800000 - 0x2000000\r\nsetting 0000000000000000-0000000000272000 readonly\r\nskipped 1000\r\nMM: Initialise page allocator for 3ff000(3ff000)-2000000(2000000)\r\nMM: done\r\nDemand map pfns at 2001000-0000002002001000.\r\nInitialising timer interface\r\nInitialising console ... done.\r\ngnttab_table mapped at 0000000002001000.\r\ngetenv(OCAMLRUNPARAM) -> null\r\ngetenv(CAMLRUNPARAM) -> null\r\ngetenv(PATH) -> null\r\nUnsupported function lseek called in Mini-OS kernel\r\nUnsupported function lseek called in Mini-OS kernel\r\nUnsupported function lseek called in Mini-OS kernel\r\ngetenv(OCAMLRUNPARAM) -> null\r\ngetenv(CAMLRUNPARAM) -> null\r\ngetenv(TMPDIR) -> null\r\ngetenv(TEMP) -> null\r\nGPF rip: 197eec, error_code=0\r\nRIP: e030:[<0000000000197eec>] \r\nRSP: e02b:00000000003cfe38  EFLAGS: 00010046\r\nRAX: 0000000000412b48 RBX: 0000000000000001 RCX: 000000000000000e\r\nRDX: 0000000000fbcab0 RSI: 0000000000412b08 RDI: 0000000000fbcae8\r\nRBP: 000000000032b918 R08: 0000000000000008 R09: 0000000000000010\r\nR10: 0000000000000001 R11: 000000000037f500 R12: 0000000000141268\r\nR13: 000000000035abf8 R14: 00000000003cfee0 R15: 000000000090d470\r\nbase is 0x32b918 caller is 0x7\r\nbase is 0x6e00 caller is 0x86e6058d4830ef83\r\nbase is 0x49c7894808ec8348 GPF rip: 20f797, error_code=0\r\nRIP: e030:[<000000000020f797>] \r\nRSP: e02b:00000000003cfd58  EFLAGS: 00010016\r\nRAX: 000000000000001b RBX: 49c7894808ec8348 RCX: 0000000000000713\r\nRDX: 0000000000000713 RSI: 00000000003cfba8 RDI: 0000000000000004\r\nRBP: 00000000003cfd88 R08: 0000000000000712 R09: 0000000000000020\r\nR10: 000000000000001b R11: 0000000000000000 R12: 0000000000141268\r\nR13: 000000000035abf8 R14: 00000000003cfee0 R15: 000000000090d470\r\nbase is 0x3cfd88 caller is 0x3cfee0\r\nbase is 0x90d470 caller is 0x1e1\r\nbase is 0x400 Page fault at linear address 408, rip 20f797, regs 00000000003cfbc8, sp 3cfc78, our_sp 00000000003cfb88, code 0\r\nRIP: e030:[<000000000020f797>] \r\nRSP: e02b:00000000003cfc78  EFLAGS: 00010012\r\nRAX: 000000000000000e RBX: 0000000000000400 RCX: 0000000000000925\r\nRDX: 0000000000000925 RSI: 00000000003cfad8 RDI: 0000000000000004\r\nRBP: 00000000003cfca8 R08: 0000000000000124 R09: 0000000000000020\r\nR10: 000000000000000e R11: 0000000000000000 R12: 0000000000141268\r\nR13: 000000000035abf8 R14: 00000000003cfee0 R15: 000000000090d470\r\nbase is 0x3cfca8 caller is 0x3cfee0\r\nbase is 0x90d470 caller is 0x1e1\r\nbase is 0x400 Page fault in pagetable walk (access to invalid memory?).\r\n```\r\n\r\nRebuilding against a nocrypto built with with `--disable-modernity` results in a normally booting unikernel.\r\n\r\nPlease let me know if there's more information I can provide, or any other way I can help."},"comment":{"url":"https://api.github.com/repos/mirleft/ocaml-nocrypto/issues/comments/114547973","html_url":"https://github.com/mirleft/ocaml-nocrypto/issues/70#issuecomment-114547973","issue_url":"https://api.github.com/repos/mirleft/ocaml-nocrypto/issues/70","id":114547973,"user":{"login":"pqwy","id":325535,"avatar_url":"https://avatars.githubusercontent.com/u/325535?v=3","gravatar_id":"","url":"https://api.github.com/users/pqwy","html_url":"https://github.com/pqwy","followers_url":"https://api.github.com/users/pqwy/followers","following_url":"https://api.github.com/users/pqwy/following{/other_user}","gists_url":"https://api.github.com/users/pqwy/gists{/gist_id}","starred_url":"https://api.github.com/users/pqwy/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pqwy/subscriptions","organizations_url":"https://api.github.com/users/pqwy/orgs","repos_url":"https://api.github.com/users/pqwy/repos","events_url":"https://api.github.com/users/pqwy/events{/privacy}","received_events_url":"https://api.github.com/users/pqwy/received_events","type":"User","site_admin":false},"created_at":"2015-06-23T15:35:01Z","updated_at":"2015-06-23T15:35:01Z","body":"@yomimono Thank you! I just wanted to check if it's the CPU feature set. It is not. The next thing that would be helpful is to add printfs to the beginning of these [two](https://github.com/mirleft/ocaml-nocrypto/blob/61023ea43fdb96db10183ba13b54f18830e16572/src/fortuna.ml#L37) [functions](https://github.com/mirleft/ocaml-nocrypto/blob/61023ea43fdb96db10183ba13b54f18830e16572/src/fortuna.ml#L54), because I think the first brush with this code is in the early RNG seeding. Another helpful printf-case is confirming that the `start` function of the unikernel is never even reached.\r\n\r\nIn more detail, for the purposes of my question, it makes no difference whatsoever whether you ran the Unix test without Xen in sight, or in dom0, or domU. It especially does not matter if it didn't explode, because we can immediately rule out the CPU limitation on your own computer.\r\n\r\nXen itself obviously \"supports\" SSE in that these are not privileged instructions, are not trapped in HVM and are not hindered by having no access to ring0 in PVM. There is no difference between dom0 and domU in this respect, as both are actually virtualized. dom0 might be allowed access to memory regions peripherals are mapped to, but runs under the same regime of CPU virtualization. And as @avsm alluded to, actual lack of support for SSE under Xen would make Linux bomb out immediately.\r\n\r\nSSE requires OS cooperation at least in order to preserve the extended register set on context-switch. I *suspect*, but at this point without knowing for a fact, that the OS also needs to enable them, and that MiniOS never does it. I also think there is no other SSE code running in MiniOS as it doesn't use the standard libc, so this is the first time MiniOS was prodded into running SSE.\r\n\r\n@avsm It's specifically using SSE2 unaligned-access `MOVDQU` via `_mm_loadu_si128` to move data from memory into the SSE registers. Do you think alignment matters anyway?\r\n\r\nOff to untar my Xen-debugging rig...\r\n"}}