00:05 <haesbaert> we haz auth \o/

00:05 <haesbaert> debug3: authmethod_is_enabled password

00:05 <haesbaert> debug1: Next authentication method: password

00:05 <haesbaert> haesbaert@feanor's password:

00:06 <haesbaert> handling (Ssh_msg_service_request ssh-userauth)

00:06 <haesbaert> sending (Ssh_msg_userauth_failure ((password) false))

00:06 <haesbaert> service=ssh-connection

00:06 <haesbaert> handling (Ssh_msg_userauth_request (haesbaert ssh-connection None))

00:06 <haesbaert> sending (Ssh_msg_service_accept ssh-userauth)

00:06 <haesbaert> \o/

00:07 <dstolfa> kensan: Sorry, didn't have time to discuss today, will get back asap :)

00:07 <dstolfa> Off to bed now

00:27 <reynir> \o/

01:10 <dmj`> Had a question, so the unikernel “base layer”, used to be mini-os (pre-mirage v3.0), which supported the xen hypervisor only, but now come v3.0 solo5 was adopted and xen is no longer supported? Is this correct?

01:16 <gjaldon__> dmj`: xen is still supported in 3.0. more targets were just added, like ukvm, virtio, macosx and qubes(?)

01:22 <dmj`> gjaldon__: ah interesting, and solo5 isn’t “mirage-specific” right? It could be used with any other language runtime

01:24 <apache3> yes

01:29 <dmj`> apache3: but mini-os is only xen-specific

01:30 <apache3> solo5 is not mirage-specific

01:32 <dmj`> apache3: right, and that was the motivation for moving away from mini-os?

01:32 <dmj`> well, just that more hypervisors are supported I guess

01:33 <apache3> I would assume so, and I take it the design of solo5 was also deemed more viable long-term. But I was not involved in the decisions, so I have no idea.

15:36 <miragebot> mirage/master 26ebfe8 Anil Madhavapeddy: Merge pull request #810 from avsm/doc-odig-stay-with-me...

15:36 <miragebot> mirage/master e746f88 Anil Madhavapeddy: doc: stop uninstalling odig, remove anything that requires cmdliner<1

15:36 <miragebot> [mirage] avsm pushed 2 new commits to master: https://git.io/vyiII

15:40 <dstolfa> mato: Hey!

15:42 <dstolfa> mato: I've submitted the issue about the FreeBSD port, I was curious whether you have some paravirt features on the guest side for KVM, where you require an ABI by the hypervisor. Alas I've not had time to detailedly look at the implementation, but skimming across it, it seemed like you have something of sort on the guest side

15:45 <reynir> seliopou: Btw when I was packing my stuff in Marrakech I found two pens which I figured must have been yours. I brought them with me. I figure it's not worth sending :-)

15:56 <mato> dstolfa: Hi. I'm not sure what you're asking. ukvm is technically only paravirt, it's not intended to run a general purpose OS.

15:56 <mato> dstolfa: So it's paravirt in the sense that the interfaces provided are ukvm-specific, not those of a "normal PC" (for x86)

15:57 <dstolfa> mato: I guess I'm not phrasing it that well, but you've kind of answered my question with regards whether you use the hypercalls provided by KVM

15:57 <mato> dstolfa: We don't use hypercalls provided by KVM, it doesn't do that. It unfortunately steals the use of VMCALL for it's own purposes which we can't modify.

15:58 <mato> dstolfa: So, instead on x86 the hypercall ABI uses a PIO + memory mapped style mechanism, which should be the fastest code path for KVM.

15:58 <mato> dstolfa: This will become clearer once I get my refactoring in.

15:58 <dstolfa> mato: Ah okay. Makes sense.

15:58 <mato> (Currently the hypercall ABI is hidden away in the individual implementations)

15:59 <dstolfa> mato: hannes has mentioned that you've been looking at the fbt provider of DTrace as well?

15:59 <dstolfa> Or, something along the lines

15:59 <reynir> Will ukvm change name, or was that a joke? :)

16:00 <mato> reynir: It probably should, since it'll rapidly gain support for non-KVM hosts (Bhyve, Hypervisor.framework)

16:00 <mato> so no point having "KVM" in the name

16:00 <reynir> Cool!

16:00 <mato> dstolfa: No idea, we had some discussion of dtrace but nothing concrete, other things need doing first.

16:01 <mato> dstolfa: I do want to do some simple support for mirage-profile though.

16:01 <hannes> dstolfa: no. I mentioned it would be nice if someone would implement DTrace (fbt + static probes) support for OCaml

16:01 <dstolfa> hannes: Ah, my bad then, misunderstood

16:01 <hannes> it's all my fault.

16:02 <dstolfa> hannes: It wouldn't be the first time I misunderstood something :)

16:02 <dstolfa> mato: But yeah, that sounds good :)

16:02 <dstolfa> mato: Thanks for the information

16:03 <mato> You're welcome

16:21 <kensan> mato: Regarding refactoring: is there any code available which illustrates the new structure?

16:21 <kensan> mato: I have some minor stuff I want to clean up but otherwise my Solo5 Muen port is functionally complete.

16:22 <kensan> mato: minus block dev support.

16:23 <mato> kensan: Still in progress. I will publish a first cut this week.

16:25 <mato> kensan: I have most of the ukvm side done (all tests pass), now need to clean it up and document the interfaces + establish some new conventions to encourage writing safe code (as much as can be with C) on the ukvm side

16:41 <kensan> mato: Ah great, thanks for the info!

16:42 <kensan> mato: I am not sure you know, the Muen port is at https://github.com/codelabs-ch/solo5/tree/muen

22:14 <gjaldon__> has anyone here successfully ran a unikernel on Google Compute Engine? I've uploaded the unikernel as an image and created an instance using that unikernel. Basing on serial output for that instance, the unikernel is running fine except for the ff logs:

22:14 <gjaldon__> https://gist.github.com/gjaldon/332b3cea07c60d03237b6d3cf5208a64

22:15 <gjaldon__> what additional configuration do I need to do for the instance?

22:32 <kensan> gjaldon__: You probably need to either set an appropriate static IPv4 address or use DHCP to aquire one if there is a server running in that network.

22:42 <mattg> gjaldon__: https://cloud.google.com/compute/docs/configure-instance-ip-addresses section "Specifying an internal IP address at instance creation" might to the trick, or use DHCP

23:08 <gjaldon__> thanks for the responses kensan and mattg!

23:08 <gjaldon__> mattg: the link is especially helpful btw :)