search for: start_info

...--- arch/x86/xen/setup.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.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...

Running with Xen option dom0_mem=6G and kernel option mem=8G, I would have expected that I would see the system with a 2G balloon right after boot. However, the balloon is empty. Briefly looking at this, it would seem to me that, with all pages being reserved when the system starts and only the populated ones getting the reserved status cleared in __free_pages_bootmem(), the condition to put pages

Hi all, This is a trivial patch which adds the two fields to start_info_t for the shared page and event channel port for the share. Feel free to destroy this in any way. The python binding just fills zeros in for the moment, making it harmless. Mike Wray has a nicer version in his tree, but this is the minimal version. (Thanks to Mike for the .esp fix, too). Cheers...

...i wrote: > >> Hi all, > >> > >> I''m reading Mini-OS''s codes and to estimate the amount of work porting it to > >> ARM (Ian''s GSoC idea this year). > >> > >> While Xen is booting Mini-OS on x86 platform, it passes the start_info_t to > >> the guest through ESI register. And Mini-OS would use this structure as the > >> argument of start_kernel. However, I didn''t see codes handle the > >> start_info_t on ARM side. Instead, I see a more standard protocal when > >> booting ARM'...

...z" memory=16 disk=["file:/var/vtpmmgr-stubdom.img,hda,w"] name="vtpmmgr" iomem=["fed40,5"] 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...

...bootloader to tell the booted kernel what kind of environment its coming up under. We can use this to tell the kernel to unambigiously tell that its booting under Xen. There's also an extra field for storing some environment-specific data; we use this to store the Xen start_info pointer. 2. The 32-part of the bzImage code, which includes a decompressor and the compressed data for the actual kernel, is wrapped in an ELF file. This allows us to decorate it with the Xen-spceific ELF notes, and also use the PHDRs to specify how much memory Xen needs...

...bootloader to tell the booted kernel what kind of environment its coming up under. We can use this to tell the kernel to unambigiously tell that its booting under Xen. There's also an extra field for storing some environment-specific data; we use this to store the Xen start_info pointer. 2. The 32-part of the bzImage code, which includes a decompressor and the compressed data for the actual kernel, is wrapped in an ELF file. This allows us to decorate it with the Xen-spceific ELF notes, and also use the PHDRs to specify how much memory Xen needs...

...bootloader to tell the booted kernel what kind of environment its coming up under. We can use this to tell the kernel to unambigiously tell that its booting under Xen. There's also an extra field for storing some environment-specific data; we use this to store the Xen start_info pointer. 2. The 32-part of the bzImage code, which includes a decompressor and the compressed data for the actual kernel, is wrapped in an ELF file. This allows us to decorate it with the Xen-spceific ELF notes, and also use the PHDRs to specify how much memory Xen needs...

...==== kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz" memory=16 disk=["file:/var/vtpmmgr-stubdom.img,hda,w"] 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...

...==== kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz" memory=16 disk=["file:/var/vtpmmgr-stubdom.img,hda,w"] 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...

...in the hypervisor. Otherwise, the pirq returned from PHYSDEVOP_map_pirq may collide with the dynamic IRQs in the kernel or even be out of range altogether. Therefore I think that NR_PIRQS has to become a variable defaulting to 256 but getting initialized from a hypervisor reported value (perhaps in start_info, or else from a new (sub-)hypercall). 2) While pci_restore_msi_state() properly checks the success of msi_map_pirq_to_vector(), pci_restore_msix_state() doesn''t. Is this for a reason, or just because the code would get more complex if the error needs to be handled? 3) The type parameter...

...----- 1 files changed, 1 insertions(+), 15 deletions(-) diff --git a/arch/x86/include/asm/xen/hypervisor.h b/arch/x86/include/asm/xen/hypervisor.h index 125f344..d866959 100644 --- a/arch/x86/include/asm/xen/hypervisor.h +++ b/arch/x86/include/asm/xen/hypervisor.h @@ -40,21 +40,7 @@ extern struct start_info *xen_start_info; static inline uint32_t xen_cpuid_base(void) { - uint32_t base, eax, ebx, ecx, edx; - char signature[13]; - - for (base = 0x40000000; base < 0x40010000; base += 0x100) { - cpuid(base, &eax, &ebx, &ecx, &edx); - *(uint32_t *)(signature + 0) = ebx; - *(uint32...

...----- 1 files changed, 1 insertions(+), 15 deletions(-) diff --git a/arch/x86/include/asm/xen/hypervisor.h b/arch/x86/include/asm/xen/hypervisor.h index 125f344..d866959 100644 --- a/arch/x86/include/asm/xen/hypervisor.h +++ b/arch/x86/include/asm/xen/hypervisor.h @@ -40,21 +40,7 @@ extern struct start_info *xen_start_info; static inline uint32_t xen_cpuid_base(void) { - uint32_t base, eax, ebx, ecx, edx; - char signature[13]; - - for (base = 0x40000000; base < 0x40010000; base += 0x100) { - cpuid(base, &eax, &ebx, &ecx, &edx); - *(uint32_t *)(signature + 0) = ebx; - *(uint32...

...----- 1 files changed, 1 insertions(+), 15 deletions(-) diff --git a/arch/x86/include/asm/xen/hypervisor.h b/arch/x86/include/asm/xen/hypervisor.h index 125f344..d866959 100644 --- a/arch/x86/include/asm/xen/hypervisor.h +++ b/arch/x86/include/asm/xen/hypervisor.h @@ -40,21 +40,7 @@ extern struct start_info *xen_start_info; static inline uint32_t xen_cpuid_base(void) { - uint32_t base, eax, ebx, ecx, edx; - char signature[13]; - - for (base = 0x40000000; base < 0x40010000; base += 0x100) { - cpuid(base, &eax, &ebx, &ecx, &edx); - *(uint32_t *)(signature + 0) = ebx; - *(uint32...

...d found something which seems strange to me: the build_pagetable() function in mm.c. This function aims at building up the additional page tables which were not allocated by the hypervisor during the domain construction (domain_build.c). I do not understand the following calculation: pfn_to_map = (start_info.nr_pt_frames - NOT_L1_FRAMES) * L1_PAGETABLE_ENTRIES; pfn_to_map is supposed to be the first page frame number to be mapped by the function. However, the guest OS gets a list of pfns (start_pfn - max_pfn, including the phys_to_machine table) assigned by the hypervisor, and the first pfns are suppo...

...z" memory=16 disk=["file:/var/vtpmmgr-stubdom.img,hda,w"] name="vtpmmgr" iomem=["fed40,5"] 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...

...eason = SHUTDOWN_reboot; + else + /* Unknown */ + shutdown_reason = SHUTDOWN_crash; + wmb(); + do_shutdown = 1; + wmb(); + wake_up(&shutdown_queue); +} + + /* This should be overridden by the application we are linked against. */ __attribute__((weak)) int app_main(start_info_t *si) { @@ -126,6 +160,8 @@ /* Init XenBus */ init_xenbus(); + create_thread("shutdown", shutdown_thread, NULL); + /* Call (possibly overridden) app_main() */ app_main(&start_info); diff -r fdf241ea6ff4 extras/mini-os/test.c --- a/extras/mini-os/test.c Wed...

...r; > #else >@@ -264,39 +257,22 @@ > /*** Forcibly flush console data before dying. ***/ > void xencons_force_flush(void) > { >- ctrl_msg_t msg; > int sz; > > /* Emergency console is synchronous, so there''s nothing to flush. */ > if ( xen_start_info.flags & SIF_INITDOMAIN ) > return; > >- /* >- * We use dangerous control-interface functions that require a quiescent >- * system and no interrupts. Try to ensure this with a global cli(). >- */ >- local_irq_disable(); /* XXXsmp */ > >...

I last posted this back in April to critical acclaim (AKA near total silence). I''m not sure who looks after tools/include/xen-foreign. I had thought it was Jan but I think I was confused and was thinking of the semi-related xen/include/compat stuff. IOW I think nobody felt "responsible". Unless there''s any objection lets just treat this as coming under tools. The

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