BTW, not sure why but my MUA (Mutt 11.0.3) seems to add everyone on Cc to the To: field on reply, and drops your email address from the list. I don't see a 'Reply-to:' on the headers, so I'm not sure why it does that, but you might want to check your config.
I have to manually fix the headers to properly set the To: field to your address and the Cc to everyone else. On Tue, May 26, 2020 at 12:12:03PM +0200, Martin Lucina wrote: > On Tuesday, 26.05.2020 at 12:03, Roger Pau Monné wrote: > > On Tue, May 26, 2020 at 11:34:21AM +0200, Roger Pau Monné wrote: > > > On Tue, May 26, 2020 at 10:52:21AM +0200, Martin Lucina wrote: > > > > On Monday, 25.05.2020 at 17:59, Andrew Cooper wrote: > > > > > On 25/05/2020 17:42, Jürgen Groß wrote: > > > > > > You need to setup virtual addressing and enable 64 bit mode before > > > > > > using > > > > > > 64-bit GDT. > > > > > > > > > > > > See Mini-OS source arch/x86/x86_hvm.S > > > > > > > > > > Or > > > > > https://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen-test-framework.git;a=blob;f=arch/x86/hvm/head.S;h=f7dc72b58ab9ec68538f0087969ab6f72d181d80;hb=HEAD > > > > > > > > > > But yes - Juergen is correct. Until you have enabled long mode, lgdt > > > > > will only load the bottom 32 bits of GDTR.base. > > > > > > > > Ah, I missed Jurgen's and your reply here. > > > > > > > > LGDT loading only the bottom 32 bits of GDTR.base shouldn't matter. > > > > Examining gdt_ptr some more: > > > > > > > > (gdb) set architecture i386 > > > > The target architecture is assumed to be i386 > > > > (gdb) x /xh 0x108040 > > > > 0x108040: 0x002f > > > > (gdb) x /xw 0x108042 > > > > 0x108042: 0x00108000 > > > > (gdb) x /6xb 0x108040 > > > > 0x108040: 0x2f 0x00 0x00 0x80 0x10 0x00 > > > > (gdb) x /8xb 0x108040 > > > > 0x108040: 0x2f 0x00 0x00 0x80 0x10 0x00 0x00 > > > > 0x00 > > > > > > Could you also print the GDT entry at 0x10 (ie: 0x108000 + 0x10), just > > > to make sure it contains the right descriptor? > > > > Forgot to ask, but can you also add the output of readelf -lW > > <kernel>? > > Elf file type is EXEC (Executable file) > Entry point 0x1001e0 > There are 7 program headers, starting at offset 64 > > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz > MemSiz Flg Align > INTERP 0x001000 0x0000000000100000 0x0000000000100000 0x000018 > 0x000018 R 0x8 > [Requesting program interpreter: /nonexistent/solo5/] > LOAD 0x001000 0x0000000000100000 0x0000000000100000 0x00626c > 0x00626c R E 0x1000 > LOAD 0x008000 0x0000000000107000 0x0000000000107000 0x007120 > 0x00ed48 RW 0x1000 > NOTE 0x0080ac 0x00000000001070ac 0x00000000001070ac 0x000018 > 0x000018 R 0x4 > NOTE 0x00f120 0x00000000001070c4 0x00000000001070c4 0x000014 > 0x000000 R 0x4 > NOTE 0x008088 0x0000000000107088 0x0000000000107088 0x000024 > 0x000024 R 0x4 > NOTE 0x008000 0x0000000000107000 0x0000000000107000 0x000088 > 0x000088 R 0x4 > > Section to Segment mapping: > Segment Sections... > 00 .interp > 01 .interp .text .rodata .eh_frame > 02 .note.solo5.manifest .note.solo5.abi .note.solo5.not-openbsd > .data .bss > 03 .note.solo5.not-openbsd > 04 .note.solo5.xen > 05 .note.solo5.abi > 06 .note.solo5.manifest > > The PT_INTERP and multiple PT_NOTE headers are that way due to specifics of > how Solo5 ABIs work, but I've verified that the domain builder is > interpreting XEN_ELFNOTE_PHYS32_ENTRY correctly. Right, just wanted to double check that virtaddr == physaddr since you didn't use any offset to get the physical address of symbols, but I guess that if this wasn't correct you won't be even able to execute the first instruction anyway. Thanks, Roger.
