hotpot33 has quit [Quit: No Ping reply in 180 seconds.]
hotpot33 has joined #mirage
adhux0x0f0x3f-- has quit [Ping timeout: 240 seconds]
aion has joined #mirage
busu has quit [Ping timeout: 250 seconds]
jerith has quit [Ping timeout: 268 seconds]
jerith has joined #mirage
Haudegen has joined #mirage
jnavila has joined #mirage
jnavila has quit [Ping timeout: 256 seconds]
talex5 has joined #mirage
_whitelogger has joined #mirage
<talex5>
marmarek: how are you using gdb with guests? Should I create a guest directly with "xl create" and then run gdbsx?
<marmarek>
talex5: I use virsh -c xen start --paused <vmname>
<marmarek>
re-using xml definition that qubes registered in libvirt
<talex5>
That sounds useful, but it just says "libxenlight failed to create new domain 'mirage-test'".
<talex5>
`qvm-start mirage-test` works though.
<marmarek>
ah, yes
<marmarek>
I had to edit it first to remove disks
<marmarek>
virsh -c xen edit
<marmarek>
and on write ignore validation error ("i")
<talex5>
Ah, that worked - thanks!
<aion>
"remove disks" means "running as a dom0-deployed kernel"?
mahmudov has quit [Ping timeout: 256 seconds]
mahmudov has joined #mirage
<talex5>
Looks like the .rodata section has been overwritten from about 0xff000 to 0x100000.
<talex5>
aion: Not sure what you mean. I just deleted the <disk> elements from the XML.
<talex5>
marmarek: mato says that using addresses below 1 MB on x86 is probably a bad idea, and that might be why .rodata is getting overwritten. Do you know what the restrictions are for PVH guests?
<talex5>
As I know nothing about x86, I'm going to do some other work for a bit. But this looks close to working - mirage hello does work if I pull in libraries of the right size to avoid the memory holes :-)
<marmarek>
PVH guest is very similar to HVM, just without qemu
<mato>
I'm about 99% sure that ignoring x86 legacy memory holes is the cause of the problem
<mato>
I may be able to look at this in a day or two, but will need to install Qubes (or at least a relevant version of Xen) somewhere. So not right now, working on other stuff.
<marmarek>
start_info contains memory map, mini-os prints it at the start
<marmarek>
Memory map:
<marmarek>
0000000ff000-0000000fffff: ACPI
<marmarek>
0000fc001000-0000fc007fff: ACPI
<marmarek>
0000fc000000-0000fc000fff: ACPI
<marmarek>
000000000000-0000fa0003ff: RAM
<mato>
There you go
<mato>
0000000ff000-0000000fffff: ACPI
<mato>
now I'm 100% sure :-)
<mato>
So, the mini-os linker script needs to be changed to locate all code, data, bss at 0x100000
<mato>
However, as that script contains a ton of "stuff", off the top of my head you can't just change ". = 0x0" in it, since I'm assuming that PVH relies on more x86 legacy crap in low memory.
<mato>
Would need some focussed time to look at it properly without cargo-culting anything :-)
<marmarek>
just changing ". = 0x0" leads to #GP somewhere, haven't debugged it yet
<marmarek>
I mapping zero-page at 0x0 currently assumes something is there at 0x0 initially
<marmarek>
haven't found where exactly it is done
<mato>
I said that won't work :-)
<mato>
You need to know what the actual PVH ABI is on the Xen side
<mato>
It probably has some fixed physical start address (probably 0x0 since that's where _start is in mini-os)
<mato>
Which implies that the linker script needs to deal with memory holes. Which is ...not easy.
<mato>
<rant>Gotta love x86 legacy nonsense.</rant>
<marmarek>
not really, it uses elf note to point at entry point
<aion>
talex5: two ways to run mirage on qubes. your docs describe the "as a kernel in dom0" way, the other is "as a template" via qubes-builder. the "as a template" actualy "needs" the disks (because thats where the mirage unikernel actualy is stored)
adhux0x0f0x3f has joined #mirage
Haudegen has joined #mirage
Desetude has joined #mirage
<talex5>
aion: ah, OK; I haven't used qubes-builder.