search for: startup_32

On Wed, Jul 15, 2020 at 11:24:56AM +0200, Peter Zijlstra wrote: > Can we get some more words -- preferably in actual code comments, on > when exactly #VC happens? Sure, will add this as a comment before the actual runtime VC handler. > Because the only thing I remember is that #VC could happen on any memop, > but I also have vague memories of that being a later extention. Currently

On Wed, Jul 15, 2020 at 11:24:56AM +0200, Peter Zijlstra wrote: > Can we get some more words -- preferably in actual code comments, on > when exactly #VC happens? Sure, will add this as a comment before the actual runtime VC handler. > Because the only thing I remember is that #VC could happen on any memop, > but I also have vague memories of that being a later extention. Currently

...rday I pulled and updated my hg tree.) I still can''t set breakpoints within the guest domain: # gdb vmlinux GNU gdb 6.4-debian <...> (gdb) target remote roti.lab.netapp.com:9999 Remote debugging using roti.lab.netapp.com:9999 [New thread 0] [Switching to thread 0] 0xc0100000 in startup_32 () (gdb) b *0xc0100000 Breakpoint 1 at 0xc0100000 (gdb) s Single stepping until exit from function startup_32, which has no line number information. Warning: Cannot insert breakpoint 1. Error accessing memory address 0xc0100000: Input/output error. (gdb) My RS232 Xen console looks like: xenbr0:...

Hi, On Mon, Jul 20, 2020 at 06:09:19PM -0700, Erdem Aktas wrote: > It looks like there is an expectation that the bootloader will start > from the 64bit entry point in header_64.S. With the current patch > series, it will not boot up if the bootloader jumps to the startup_32 > entry, which might break some default distro images. > What are supported bootloaders and configurations? > I am using grub ( 2.02-2ubuntu8.15) and it fails to boot because of > this reason. I am not a grub expert, so I would appreciate any > pointers on this. This is right, the o...

...20 at 09:48:51AM -0700, Erdem Aktas wrote: > Yes, I am using OVMF with SEV-ES (sev-es-v12 patches applied). I am > running Ubuntu 18.04 distro. My grub target is x86_64-efi. I also > tried installing the grub-efi-amd64 package. In all cases, the grub is > running in 64bit but enters the startup_32 in 32 bit mode. I think > there should be a 32bit #VC handler just something very similar in the > OVMF patches to handle the cpuid when the CPU is still in 32bit mode. > As it is now, it will be a huge problem to support different distro images. > I wonder if I am the only one having t...

Folks, Regarding the Virtualization BoF, Ted Tso clarified that the remaining BoF sessons would just be scheduled on paper at OLS. We only need to use a scheduled BoF slot if we want to use a room there, I guess, else we can schedule at any free time and use a corridor or pub. Available BoF slots are only Friday evening, note. Since I don't believe the Xen team is available Friday evening,

Some concern was expressed over the lguest review status, so I shall send the patches out again for people to review, to test, to make observations about the author's personal appearance, etc. I'll plan on sending these patches off to Linus in a week's time, assuming all goes well. Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body

Some concern was expressed over the lguest review status, so I shall send the patches out again for people to review, to test, to make observations about the author's personal appearance, etc. I'll plan on sending these patches off to Linus in a week's time, assuming all goes well. Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body

I've updated the patches at http://ozlabs.org/~rusty/paravirt/?mf=33ba6c4fce13;path=/ to carve out the basic shape of how I see all this fitting together. These patches implement an initial set of Xen paravirt ops, as well as adapting head.S to set up a Xen-specific entrypoint. The head.S code does absolutely minimal setup, and then calls xen_start_kernel(). This installs the Xen

[ 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

This series: 1. Updates the boot protocol to version 2.07 2. Clean up the existing build process, to get rid of tools/build and make the linker do more heavy lifting 3. Make the bzImage payload an ELF file. The bootloader can extract this as a naked ELF file by skipping over boot_params.setup_sects worth of 16-bit setup code. 4. Update the boot_params to 2.07, and update the

This series: 1. Updates the boot protocol to version 2.07 2. Clean up the existing build process, to get rid of tools/build and make the linker do more heavy lifting 3. Make the bzImage payload an ELF file. The bootloader can extract this as a naked ELF file by skipping over boot_params.setup_sects worth of 16-bit setup code. 4. Update the boot_params to 2.07, and update the

Hi Rusty, I had a look over your 011-paravirt-head.S.patch. I'm struggling to come up with a list of any benefits over having separate entrypoints for each hypervisor. Multiple entry pros: * allows maximum startup flexibility for any given hypervisor * for Xen at least, it's pretty simple * the "what hypervisor am I under" question is answered trivially cons:

...#ifdef CONFIG_DEBUG_HOTPLUG_CPU0 extern int _debug_hotplug_cpu(int cpu, int action); #endif diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S index f66a6b90f954..aad62c677486 100644 --- a/arch/x86/kernel/head_32.S +++ b/arch/x86/kernel/head_32.S @@ -174,12 +174,12 @@ SYM_CODE_END(startup_32) * up already except stack. We just set up stack here. Then call * start_secondary(). */ -SYM_FUNC_START(start_cpu0) +SYM_FUNC_START(start_cpu) movl initial_stack, %ecx movl %ecx, %esp call *(initial_code) 1: jmp 1b -SYM_FUNC_END(start_cpu0) +SYM_FUNC_END(start_cpu) #endif /* diff...

...#ifdef CONFIG_DEBUG_HOTPLUG_CPU0 extern int _debug_hotplug_cpu(int cpu, int action); #endif diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S index 7ed84c282233..f63e1b7f4141 100644 --- a/arch/x86/kernel/head_32.S +++ b/arch/x86/kernel/head_32.S @@ -143,12 +143,12 @@ SYM_CODE_END(startup_32) * up already except stack. We just set up stack here. Then call * start_secondary(). */ -SYM_FUNC_START(start_cpu0) +SYM_FUNC_START(start_cpu) movl initial_stack, %ecx movl %ecx, %esp call *(initial_code) 1: jmp 1b -SYM_FUNC_END(start_cpu0) +SYM_FUNC_END(start_cpu) #endif /* diff...

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

...ecs+35755/73400] [tvecs+36079/73400] [__block_prepare_write+238/544] [cont_prepare_write+473/736] [fat_get_block+0/288] [fat_prepare_write+38/48] [fat_get_block+0/288] [generic_file_write+929/1344] [default_fat_file_write+34/96] [fat_file_write+45/64] [sys_write+214/256] [system_call+52/64] [startup_32+43/310] Code: 0f 0b 83 c4 0c b8 fb ff ff ff 5b 5e 5f 5d 83 c4 04 c3 8b 86 [extract from /usr/src/linux/fs/fat/file.c ] [snip] 68: if (!(iblock<<9 != MSDOS_I(inode)->mmu_private) { 69: BUG(); 70: return -EIO; 71: } [snip] - -- Best regards, Michiel mai...