[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [Draft A] Boot ABI for HVM guests without a device-model
El 10/06/15 a les 15.15, Jan Beulich ha escrit: >>>> On 10.06.15 at 14:34, <roger.pau@xxxxxxxxxx> wrote: >> * XEN_ELFNOTE_PADDR_OFFSET: the offset of the ELF paddr field from the >> actual required physical address. > > Why would that be needed? I.e. why would there ever be an offset? For example a FreeBSD kernel has the following program headers: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x0000000001055b30 0x0000000001055b30 R E 200000 LOAD 0x0000000001055b30 0xffffffff81455b30 0xffffffff81455b30 0x0000000000135c88 0x0000000000532348 RW 200000 DYNAMIC 0x0000000001055b30 0xffffffff81455b30 0xffffffff81455b30 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 I thought the loader needs XEN_ELFNOTE_PADDR_OFFSET in order to figure out the physical address were it has to load the kernel by using PhysAddr - XEN_ELFNOTE_PADDR_OFFSET, but maybe that's not the case. Maybe I can also fix the FreeBSD kernel in order to have the right PhysAddr, but I'm not sure if that's going to screw native loading. > >> * XEN_ELFNOTE_PADDR_ENTRY: the 32bit entry point into the kernel. >> * XEN_ELFNOTE_FEATURES: features required by the guest kernel in order >> to run. >> >> The presence of the XEN_ELFNOTE_PADDR_ENTRY note indicates that the >> kernel supports the boot ABI described in this document. >> >> The domain builder will load the kernel into the guest memory space and >> jump into the entry point defined at XEN_ELFNOTE_PADDR_ENTRY with the >> following machine state: >> >> * esi: contains the physical memory address were the loader has placed >> the start_info page. >> >> * eax: contains the magic value 0xFF6BC1E2. > > On what basis was this value chosen? It's a completely random value. > For my taste, it's getting too > close to something that could be a legitimate 32-bit kernel pointer > (agreed, all values could be valid pointers in 32-bit OSes, but with > OSes tending to place themselves high in memory, a value numerically > closer to what multiboot1 uses would seem more desirable). I don't have any strong opinions here, does the following seem more suitable: 0x336ec578 ("xEn3" with the 0x80 bit of the "E" set) (from xc_dom_binloader.c) Or we can follow multiboot1 and use: 0x3BADB002 (note the 3 instead of the 2). > >> * cr0: bit 31 (PG) must be cleared. Bit 0 (PE) must be set. Other bits >> are all undefined. > > I see that grub1 documentation says so, but I doubt this is realistic > (even less so for cr4 bits): Some of the bits (including ones not > currently defined) may have a meaning even in non-paged protected > mode, and the environment should be as completely defined as possible. > I.e. I think most other bits should be defined to be zero upon handoff. > >> * cs: must be a 32-bit read/execute code segment with an offset of â0â >> and a limit of â0xFFFFFFFFâ. The exact value is undefined. > > I guess "exact value" really means "selector value". I think so, it's a literal copy from the multiboot1 spec. > >> * ds, es, fs, gs, ss: must be a 32-bit read/write data segment with an >> offset of â0â and a limit of â0xFFFFFFFFâ. The exact values are all >> undefined. > > Same here, plus I don't think fs and gs should be defined to have any > particular value, base, limit, or attributes (such that handing off with > them holding nul selectors would become acceptable). This is also copied from the multiboot1 spec. I don't have any issue with leaving fs and gs undefined. > >> * eflags: bit 17 (VM) must be cleared. Bit 9 (IF) must be cleared. >> Other bits are all undefined. >> >> * A20 gate: must be enabled. > > This is irrelevant on other than physical machines. I had my doubts on this one, glad to know it's not relevant. >> Comments for further discussion: >> >> Do we want to keep using the start_info page? Most of the fields there >> are not relevant for auto-translated guests, but without it we have to >> figure out how to pass the following information to the guest: >> >> - Flags: SIF_xxx flags, this could probably be done with cpuid instead. >> - cmd_line: ? >> - console mfn: ? >> - console evtchn: ? >> - console_info address: ? > > Yeah, settling on ideally a reasonably arch-independent mechanism > that doesn't place undue constraints on future ports would be nice. > And considering a hypothetical variant of x86 Xen not supporting PV > guests anymore, this would no longer define XEN_HAVE_PV_GUEST_ENTRY > and hence no longer have a struct start_info. So from a puristic pov > the information should indeed be conveyed another way. What about the following layout: struct hvm_start_info { /* THE FOLLOWING ARE FILLED IN BOTH ON INITIAL BOOT AND ON RESUME. */ char magic[32]; /* "xen-<version>-<platform>". */ union { struct { xen_pfn_t console_paddr; /* Physical address of console page. */ uint32_t console_evtchn; /* Event channel for console page. */ } domU; struct { uint32_t info_off; /* Offset of console_info struct. */ uint32_t info_size; /* Size of console_info struct from start.*/ } dom0; } console; unsigned long mod_start; /* Physical address of pre-loaded module */ unsigned long mod_len; /* Size (bytes) of pre-loaded module. */ #define MAX_GUEST_CMDLINE 1024 int8_t cmd_line[MAX_GUEST_CMDLINE]; }; We can even expand MAX_GUEST_CMDLINE if needed. Roger. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |