marmarek has quit [Remote host closed the connection]
marmarek has joined #mirage
mahartma3 has joined #mirage
dobson` has joined #mirage
dinosaure has quit [Ping timeout: 268 seconds]
dinosaure has joined #mirage
damjan_ has joined #mirage
engil1 has joined #mirage
dobson has quit [Ping timeout: 240 seconds]
mahartma has quit [Ping timeout: 240 seconds]
engil has quit [Ping timeout: 240 seconds]
damjan has quit [Ping timeout: 240 seconds]
_whitelogger has joined #mirage
Haudegen has quit [Ping timeout: 255 seconds]
mahartma36 has joined #mirage
enma has quit [Ping timeout: 256 seconds]
mahartma3 has quit [*.net *.split]
mahartma36 is now known as mahartma3
anji has joined #mirage
_whitelogger has joined #mirage
_whitelogger has joined #mirage
<h01ger>
o/
_whitelogger has joined #mirage
gasche has joined #mirage
mahartma3 is now known as mahartma
samoht has joined #mirage
dinosaure has quit [Quit: WeeChat 2.3]
dinosaure has joined #mirage
gasche has quit [Ping timeout: 272 seconds]
damjan_ is now known as damjan
mahmudov has quit [Ping timeout: 256 seconds]
Haudegen has joined #mirage
<dinosaure>
if someone has an access to the opam-repository, I have few PRs about some softwares, it's possible ot merge them :3
hannes_qubes has joined #mirage
<hannes_qubes>
hello
<hannes_qubes>
goal is: get minios-master to build with mirageos (minios-master has pvh support)
<hannes_qubes>
now, mirageos uses things from start_info (which seems to be mapped at a static address in pv mode, but is different for pvh)
<hannes_qubes>
hmm, and now lunch is ready... I'm getting linker errors, and was curious whether anyone knows which parts of start_info are actually used in MirageOS (and whether anything apart from mirage-xen uses it -- i figured mirage-bootvar-xen uses the start_info->cmdline)?
<marmarek>
hannes_qubes: yes, I have some idea :)
<h01ger>
enjoy lunch
<hannes_qubes>
marmarek: we should be able to get the information from the pvh-start-info structure, or is there anything (crucial) missing?
<marmarek>
at least xenbus/xenstore page address
<hannes_qubes>
i should eat some lunch first... but may look into it just after lunch again... can't be too hard
<hannes_qubes>
(famous last words)
<marmarek>
:)
<marmarek>
disclaimer - talking based on unikraft code base, not current minios - some of it may be already done in minios
<marmarek>
the things that are different are at least xenstore page/evtchn, console page/evtchn, hypercall page (probably handled by minios already)
<marmarek>
start_info on PVH is almost empty (just cmdline and modules like initramfs, plus optional memory map)
<marmarek>
most things are mapped dynamically using hypercalls, instead of being provided already mapped with address in start_info
<marmarek>
the hypercall page itself is a tricky case, as you can't use hypercall for it yet; it's done with some cpuid + msr magic
<hannes_qubes>
OS.Xs.(immediate client (fun x -> read x "vm")) >>= fun vm -> OS.Xs.(immediate client (fun x -> read x (vm^"/image/cmdline"))))
<hannes_qubes>
to me it looks like reading it from xenstore is not worth it (I also don't have too much faith in the xen/arm port)
<marmarek>
I don't see this xenstore entry for my PVH vms
<hannes_qubes>
(what I managed from a detour is: use a more up-to-date minios, and PV mode, and get a mirage hello world to boot on qubesos -- so now it is really only about pv -> pvh (which the newer mini-os supports (and I verified that a mini-os in pvh boots on qubesos as well))
<marmarek>
looks to be PV only
<hannes_qubes>
thanks for checking :)
<marmarek>
where is the canonical mini-os repository, what is its status?
<marmarek>
so, it would mean in practice mini-os maintained solely for mirage, right?
<marmarek>
is that an issue?
<hannes_qubes>
well, from my current point of view: unikraft is actively maintained, but does not have pvh (and is pretty complex)
<hannes_qubes>
mini-os serves as an example, i expect if xen people do API changes they'll not break mini-os
<hannes_qubes>
the line of patches we have (from mindy, talex5) are pretty smallish
<hannes_qubes>
and it supports pvh out of the box (and did i mention it is smaller?)
<hannes_qubes>
last year in summer i tried 2 days to get the unikraft-pvh-xen stuff to compile and run on my machine, this was pretty intricate and in the end we're stuck in that some communication misbehaviour (unclear to me what fails there exactly, i added lots of printf code in unikraft + ocaml)
<hannes_qubes>
so i thought i'll spend one or two days on mini-os goes pvh with mirageos, and look how that feels like.
adhux0x0f0x3f has quit [Remote host closed the connection]
<hannes_qubes>
now, half a day in, i already feel much more successful than the two days spent on unikraft. i understand the concern of "the future [tm]" and maintainence, and am open for suggestions how to move
adhux0x0f0x3f has joined #mirage
<hannes_qubes>
my point of view is: update minios, get pvh to work (drop pv, drop arm32 since i don't know anyone using it), separately rebase the mirage-xen-ocaml/mirage-xen-posix on ocaml-freestanding (which is better maintained)
<hannes_qubes>
i have not read/heard of any "end of life" for mini-os from the xen project, thus i suspect it'll be maintained (i may be wrong here)
<marmarek>
commits history in repo doesn't looks like maintained...
<marmarek>
anyway, yes, unikraft is definitely more work
<marmarek>
does the update of mini-os + adding pvh mean some API changes for mirage-xen?
<marmarek>
or rather - how invasive, how many other libraries are affected?
<marmarek>
I wonder how much of this would need to be redone when (at some point in time, if any) switching to unikraft
<hannes_qubes>
marmarek: I am not entirely sure about this, there are for sure some changes (API and implementation) for mirage-xen. I'll try to get there
<marmarek>
I think a reasonable plan would be not touching unikraft until it gets PVH support natively
<marmarek>
I may have some time (myself or someone else from the team) this year to add pvh to unikraft, but I can't commit to this right now
<hannes_qubes>
marmarek: that sounds good. I'll spend some more hours on the minios-pvh and if this works by the end of the weekend, I think it is a reasonable intermediate solution tbh. but you know xen much better, so if you say there are flaws in minios-pvh which need to be addressed, maybe it is not worth for me spending time on it!?
mahmudov has joined #mirage
<mato>
hello
<hannes_qubes>
is there any reason to keep PV support in mirage-xen? (i.e. any valid user of xen/pv in the wild?)
<hannes_qubes>
hi mato! :)
<mato>
lots of activity here, good to see. i've been a bit preoccupied with other things after cancelling the trip to marrakesh
<mato>
will be around more over the next days
<mato>
hannes_qubes: hi
<mato>
hannes_qubes: re-reading the lastlog, your approach of trying to get mirageos working with minios upstream master seems like the quickest way to upgrade the Xen stack (at least partially) to me.
<mato>
hannes_qubes: regarding bootvar. ISTR there was a discussion years ago about whether or not to get the command line (and possibly "other stuff") from xenstore, or just use start_info
<mato>
hannes_qubes: I suspect there are bits and pieces of each in the code.
<hannes_qubes>
mato: yes, well, I completely ignore the ocaml-freestanding stuff for that line of work right now (it is a separate work item). and I'm doing this mainly because I'm sick of OCaml package maintenance ;)
<hannes_qubes>
mato: marek said the cmdline with xenstore is not around on pvh...
<mato>
i don't follow -- xenstore is just as much around. IIRC the "cmdline via xenstore" is an alternative approach, but i really don't know, it was ages ago i last touched any of this.
<hannes_qubes>
mato: xenstore is around, the cmdline is not present in the store according to his experiments (for pvh guests)
<mato>
it wouldn't have been -- the "cmdline via xenstore" is some mirageos "extension"
<mato>
so, IMO just doing whatever makes 'append="foo"' in an xl.cfg(5) work is fine (probably start_info)
<mato>
hannes_qubes: anyway. more importantly, IMO moving to ocaml-freestanding would be better rather than not doing so. are you thinking of steps where a) 1st get the existing xen stack working with mini-os master (and thus PVH) and only then maybe b) look at integrating ocaml-freestanding ?
<mato>
regarding dropping PV or not. If it's easy to keep, then keep it. But , for example, can the same mini-os image boot on PV and PVH? i.e. without recompilation?
<hannes_qubes>
mato: yes (a) was upgrade mini-os to master (+our patches), get a hello world to run (this is done, drops arm32 support)
<mato>
if not, then that's an obvious case for going PVH-only, since otherwise we'd have to have multiple xen targets all the way down the stack
<hannes_qubes>
(b) is get mirage-xen and pvh to work (now that mini-os does pvh)
<mato>
i.e. mirage configure -t xen | xenpvh or similar... which is probably not worth the trouble.
<hannes_qubes>
(c) is then port it to ocaml-freestanding
<hannes_qubes>
so mini-os has a compile-time flag "use PARAVIRT or not" -- i.e. there are different images for PV and PVH
<hannes_qubes>
mato: that's convincing to me, thanks.
<hannes_qubes>
I as well agree that the ocaml-freestanding port is crucial for maintenance, but I like to limit the scope for my brain for now ;)
<mato>
in that case i think (given the intended userbase, i.e. mainly qubes) we should just drop PV and go with PVH only (i.e. -t xen becomes "Xen PVH")
<mato>
but, i would double-check with marmarek
<mato>
and yes, just drop arm32, xen-on-arm is such a niche of a niche that it's not worth our effort
<mato>
so yeah, try for (a) and (b), and we can look at (c) later (there are complications there, ping me when you want to discuss them)
<mato>
hannes_qubes: please say hi to everyone in marrakesh from me (especially hana and siham)
<hannes_qubes>
I'll look into (b) :)
mahmudov has quit [Ping timeout: 258 seconds]
talex5 has joined #mirage
smondet has joined #mirage
<marmarek>
hannes_qubes: technically it is possible to build a binary that is pv+pvh, but that's probably a lot of work for mini-os
<marmarek>
hannes_qubes: so, if no other use cases for Xen PV outside of qubes, I'd drop pv
matolucina[m] is now known as mato[m]
mahmudov has joined #mirage
hannes_qubes has quit [Remote host closed the connection]
hannes_qubes has joined #mirage
jnavila has quit [Ping timeout: 256 seconds]
talex5 has quit [Ping timeout: 260 seconds]
talex5 has joined #mirage
talex5 has quit [Ping timeout: 240 seconds]
mahmudov has quit [Ping timeout: 240 seconds]
samoht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
samoht has joined #mirage
samoht_ has joined #mirage
samoht_ has quit [Client Quit]
samoht[m] has joined #mirage
<samoht[m]>
I'm testing being here with a Matrix client
<samoht>
hello samoht!
<samoht[m]>
hum that seems to be lagging quite a bit...
<mato[m]>
samoht: Yeah, it seems that the matrix.org public server is a bit slow / overloaded.
<mato[m]>
Not much we can do about that, other than run our own server.
talex5 has joined #mirage
mahmudov has joined #mirage
<hannes_qubes>
I pushed branches to mini-os, mirage-xen, mirage-bootvar-xen, mirage-platform -- result is a mirageos hello-world using pvh which outputs (minios stuff), and then page faults
hannes_qubes has quit [Remote host closed the connection]
<anji>
talex5 on irc? must be fake..
<hannes>
so, on the way the minios seems to work fine.. it's likely some of the code in mirage-xen that is broken now (should re-check initialization procedure etc.)
talex5 has quit [Ping timeout: 256 seconds]
free_beard has joined #mirage
free_beard has quit [Ping timeout: 255 seconds]
free_beard has joined #mirage
free_beard has quit [Ping timeout: 260 seconds]
jnavila has joined #mirage
free_beard has joined #mirage
free_beard has quit [Ping timeout: 255 seconds]
<marmarek>
hannes: I guess access some PV-specific variable that isn't initialized now
<marmarek>
do you have call trace?
jnavila has quit [Ping timeout: 272 seconds]
adhux0x0f0x3f-- has joined #mirage
adhux0x0f0x3f has quit [Ping timeout: 240 seconds]