Re: [Xen-devel] start of day, special pages

[Vladimir 'Ï-coder/phcoder' Serbinenko <phcoder@xxxxxxxxx>]

On 30.10.2013 14:03, Konrad Rzeszutek Wilk wrote:
> On Wed, Oct 30, 2013 at 01:32:30PM +0100, Vladimir 'Ï-coder/phcoder' 
> Serbinenko wrote:
>> Hello, all. I'm writing pvgrub2 ( for those interested
>> http://git.savannah.gnu.org/cgit/grub.git/log/?h=phcoder/newports/xen )
>> Now I'm able to load pvgrub2 from pvgrub2. Now I'm trying to load
>> NetBSD. Apparently NetBSD assumes that console interface is mapping in
>> start-of-day layout and I paid special care not to map any special pages
>> in start-of-day. Which special pages have to be mapped and where?
>> Accoring to xen.h:
>>  *  1. The domain is started within contiguous virtual-memory region.
>>  *  2. The contiguous region ends on an aligned 4MB boundary.
>>  *  3. This the order of bootstrap elements in the initial virtual region:
>>  *      a. relocated kernel image
>>  *      b. initial ram disk              [mod_start, mod_len]
>>  *      c. list of allocated page frames [mfn_list, nr_pages]
>>  *         (unless relocated due to XEN_ELFNOTE_INIT_P2M)
>>  *      d. start_info_t structure        [register ESI (x86)]
> 
> That structure has the information:
> 
> 
> #ifdef XEN_HAVE_PV_GUEST_ENTRY
> struct start_info {
>     /* THE FOLLOWING ARE FILLED IN BOTH ON INITIAL BOOT AND ON RESUME.    */
>     char magic[32];             /* "xen-<version>-<platform>".            */
>     unsigned long nr_pages;     /* Total pages allocated to this domain.  */
>     unsigned long shared_info;  /* MACHINE address of shared info struct. */
>     uint32_t flags;             /* SIF_xxx flags.                         */
>     xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    */
>     uint32_t store_evtchn;      /* Event channel for store communication. */
>     union {
>         struct {
>             xen_pfn_t mfn;      /* MACHINE page number of console page.   */  
> <====
>             uint32_t  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;
>     /* THE FOLLOWING ARE ONLY FILLED IN ON INITIAL BOOT (NOT RESUME).     */
>     unsigned long pt_base;      /* VIRTUAL address of page directory.     */
>     unsigned long nr_pt_frames; /* Number of bootstrap p.t. frames.       */
>     unsigned long mfn_list;     /* VIRTUAL address of page-frame list.    */
>     unsigned long mod_start;    /* VIRTUAL address of pre-loaded module   */
>                                 /* (PFN of pre-loaded module if           */
>                                 /*  SIF_MOD_START_PFN set in flags).      */
>     unsigned long mod_len;      /* Size (bytes) of pre-loaded module.     */
> #define MAX_GUEST_CMDLINE 1024
>     int8_t cmd_line[MAX_GUEST_CMDLINE];
>     /* The pfn range here covers both page table and p->m table frames.   */
>     unsigned long first_p2m_pfn;/* 1st pfn forming initial P->M table.    */
>     unsigned long nr_p2m_frames;/* # of pfns forming initial P->M table.  */
> };
> 
> You need to consult console.domU.mfn.
> 
Yes, I understand that but it's not my question. My question is where I
should map it to when handing off control to another kernel.
> 
>>  *      e. bootstrap page tables         [pt_base and CR3 (x86)]
>>  *      f. bootstrap stack               [register ESP (x86)]
>>  *  4. Bootstrap elements are packed together, but each is 4kB-aligned.
>>  *  5. The initial ram disk may be omitted.
>>  *  6. The list of page frames forms a contiguous 'pseudo-physical' memory
>>  *     layout for the domain. In particular, the bootstrap virtual-memory
>>  *     region is a 1:1 mapping to the first section of the
>> pseudo-physical map.
>>  *  7. All bootstrap elements are mapped read-writable for the guest OS. The
>>  *     only exception is the bootstrap page table, which is mapped
>> read-only.
>>  *  8. There is guaranteed to be at least 512kB padding after the final
>>  *     bootstrap element. If necessary, the bootstrap virtual region is
>>  *     extended by an extra 4MB to ensure this.
>>
>> I see no mention of mapped console interface at all.
>>
> 
> 
> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxx
>> http://lists.xen.org/xen-devel
> 
>

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel