search for: mfn_list

...tup.c index 15c6c68..ad0047f 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -61,9 +61,9 @@ char * __init xen_memory_setup(void) * - xen_start_info * See comment above "struct start_info" in <xen/interface/xen.h> */ - e820_add_region(__pa(xen_start_info->mfn_list), - xen_start_info->pt_base - xen_start_info->mfn_list, - E820_RESERVED); + reserve_early(__pa(xen_start_info->mfn_list), + __pa(xen_start_info->pt_base), + "XEN START INFO"); sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map); -- 1.6.0.6...

Last year we had a discussion[1] about how the hypercall ABI unfortunately contains fields that change width between 32- and 64-bit builds. This is a huge problem as we come up on the python management stack for ppc64, since the distributions ship 32-bit python. A 32-bit python/libxc cannot currently manage a 64-bit hypervisor. I had a patch but was unable to test it, and some other things were

...2,8 @@ page = balloon_retrieve(); BUG_ON(page == NULL); - pfn = page - mem_map; - BUG_ON(phys_to_machine_mapping[pfn] != INVALID_P2M_ENTRY); + pfn = page_to_pfn(page); + BUG_ON(phys_to_machine_mapping_valid(pfn)); /* Update P->M and M->P tables. */ set_phys_to_machine(pfn, mfn_list[i]); @@ -253,8 +253,8 @@ break; } - pfn = page - mem_map; - mfn_list[i] = phys_to_machine_mapping[pfn]; + pfn = page_to_pfn(page); + mfn_list[i] = pfn_to_mfn(pfn); if (!PageHighMem(page)) { v = phys_to_virt(pfn << PAGE_SHIFT); @@ -444,6 +444,9 @@ IPRINTK("Initia...

This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which adds fields to specify the hardware subarchitecture and some

This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which adds fields to specify the hardware subarchitecture and some

This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which adds fields to specify the hardware subarchitecture and some

[ This patch depends on the cross-architecture ELF cleanup patch. ] This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which

[ This patch depends on the cross-architecture ELF cleanup patch. ] This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which

...t;] And I get this output when I try xl create -c vtpmmgr-stubdom.cfg: Parsing config from /home/xen_images/vtpmmgr-stubdom.cfg Daemon running with PID 5048 Xen Minimal OS! start_info: 0xa2000(VA) nr_pages: 0x1000 shared_inf: 0x44e09000(MA) pt_base: 0xa5000(VA) nr_pt_frames: 0x5 mfn_list: 0x9a000(VA) mod_start: 0x0(VA) mod_len: 0 flags: 0x0 cmd_line: stack: 0x597e0-0x797e0 MM: Init _text: 0x0(VA) _etext: 0x39357(VA) _erodata: 0x45000(VA) _edata: 0x47c40(VA) stack start: 0x597e0(VA) _end: 0x99e00(VA) start_pfn: ad max_pfn: 10...

...uot;] name="vtpmmgr" iomem=["fed40,1"] ==== It prints out with below: ======= Parsing config from vtpmmgr.cfg Daemon running with PID 2406 Xen Minimal OS! start_info: 0xa2000(VA) nr_pages: 0x1000 shared_inf: 0xcd7b0000(MA) pt_base: 0xa5000(VA) nr_pt_frames: 0x5 mfn_list: 0x9a000(VA) mod_start: 0x0(VA) mod_len: 0 flags: 0x0 cmd_line: stack: 0x597e0-0x797e0 MM: Init _text: 0x0(VA) _etext: 0x39357(VA) _erodata: 0x45000(VA) _edata: 0x47c40(VA) stack start: 0x597e0(VA) _end: 0x99e00(VA) start_pfn: ad max_pfn: 10...

...uot;] name="vtpmmgr" iomem=["fed40,1"] ==== It prints out with below: ======= Parsing config from vtpmmgr.cfg Daemon running with PID 2406 Xen Minimal OS! start_info: 0xa2000(VA) nr_pages: 0x1000 shared_inf: 0xcd7b0000(MA) pt_base: 0xa5000(VA) nr_pt_frames: 0x5 mfn_list: 0x9a000(VA) mod_start: 0x0(VA) mod_len: 0 flags: 0x0 cmd_line: stack: 0x597e0-0x797e0 MM: Init _text: 0x0(VA) _etext: 0x39357(VA) _erodata: 0x45000(VA) _edata: 0x47c40(VA) stack start: 0x597e0(VA) _end: 0x99e00(VA) start_pfn: ad max_pfn: 10...

Hi Jeremy. Here are the 3 patches for ia64/xen support. The first one is just to move manage.c under drivers/xen. This is trivial. The second and third ones are for compilation fix on ia64. You may want to postpone those 2 patches to make your merge task easy as you said before. thanks, Diffstat arch/x86/xen/Makefile | 2 +- drivers/xen/Makefile | 2 +-

Hi Jeremy. Here are the 3 patches for ia64/xen support. The first one is just to move manage.c under drivers/xen. This is trivial. The second and third ones are for compilation fix on ia64. You may want to postpone those 2 patches to make your merge task easy as you said before. thanks, Diffstat arch/x86/xen/Makefile | 2 +- drivers/xen/Makefile | 2 +-

The following dump-core patches changes its format into ELF, adds PFN-GMFN table, HVM support, and adds experimental IA64 support. - ELF format Program header and note section are adopted. - HVM domain support To know the memory area to dump, XENMEM_set_memory_map is added. XENMEM_memory_map hypercall is for current domain, so new one is created. and hvm domain builder tell xen its

...t;] And I get this output when I try xl create -c vtpmmgr-stubdom.cfg: Parsing config from /home/xen_images/vtpmmgr-stubdom.cfg Daemon running with PID 5048 Xen Minimal OS! start_info: 0xa2000(VA) nr_pages: 0x1000 shared_inf: 0x44e09000(MA) pt_base: 0xa5000(VA) nr_pt_frames: 0x5 mfn_list: 0x9a000(VA) mod_start: 0x0(VA) mod_len: 0 flags: 0x0 cmd_line: stack: 0x597e0-0x797e0 MM: Init _text: 0x0(VA) _etext: 0x39357(VA) _erodata: 0x45000(VA) _edata: 0x47c40(VA) stack start: 0x597e0(VA) _end: 0x99e00(VA) start_pfn: ad max_pfn: 10...

...lt; pend); /* Activate guest address space to relocate guest image */ - mmu_switch_ttb(gpt & ~(0x4000 - 1)); + set_ttbr((unsigned long)(gpt) & ~(0x4000 - 1)); elf.dest = (void *)ventry; elf_load_binary(&elf); @@ -192,7 +192,7 @@ int domain_construct(struct domain *d, si->mfn_list = 0; si->first_p2m_pfn = pstart >> PAGE_SHIFT; si->flags = 0; - si->min_mfn = pstart >> PAGE_SHIFT; + //si->min_mfn = pstart >> PAGE_SHIFT; if (d->domain_id == 0) { si->flags = SIF_PRIVILEGED | SIF_INITDOMAIN; @@ -202,7 +202,7 @@ int domain_c...

...nfo_start + PAGE_SIZE, + vstartinfo_start + PAGE_SIZE, vstartinfo_end, vstack_start, vstack_end, dsi.v_start, v_end); printf(" ENTRY ADDRESS: %08lx\n", dsi.v_kernentry); @@ -261,6 +265,8 @@ start_info->nr_pt_frames = nr_pt_pages; start_info->mfn_list = vphysmap_start; start_info->domain_controller_evtchn = control_evtchn; + start_info->store_page = vstartinfo_start + PAGE_SIZE; + start_info->store_evtchn = store_evtchn; if ( initrd_len != 0 ) { start_info->mod_start = vinitrd_start; @@ -270,6 +...

Hi, I hope I''m right here. If not then please point me in the right direction. My problem in short: I have problems using (pinning, mmu_update) physical pages from 0x900000 to 0xB1000 usualy. I''m writing my own little amd64 64bit toy kernel (based on Mini-OS as starting point) for xen and I run into problems with the way the start of day sets up the physical pages. My kernel

Hi, I‘m trying to install vTPM based on Xen-4.2.2, linux-kernel 3.9.1 (Dom0) and TPM emulator. However, I cannot find the TPM backed driver in this version of Dom0 linux kernel. There is no CONFIG_XEN_TPMDEV_BACKEND in the kernel config file. The config file for Dom0 is attached. Maybe it provides some useful information. So, how to install a Xen TPM backend driver in the Dom0 linux-kernel.

.... + * If the load address is not 4MB aligned then the address is rounded down. + * 4. 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] + * d. start_info_t structure [register ESI (x86)] + * e. bootstrap page tables [pt_base, CR3 (x86)] + * f. bootstrap stack [register ESP (x86)] + * 5. Bootstrap elements are packed together, but each is 4kB-aligned. + * 6. The initial ram di...