similar to: lguest re-review

This patch series is against 2.6.20; some things are in flux, so there might be issues as other things flow into the latest -git tree. >From the documentation: Lguest is designed to be a minimal hypervisor for the Linux kernel, for Linux developers and users to experiment with virtualization with the minimum of complexity. Nonetheless, it should have sufficient features to make it useful for

This patch series is against 2.6.20; some things are in flux, so there might be issues as other things flow into the latest -git tree. >From the documentation: Lguest is designed to be a minimal hypervisor for the Linux kernel, for Linux developers and users to experiment with virtualization with the minimum of complexity. Nonetheless, it should have sufficient features to make it useful for

Thanks to Andrew for pointing these out. This patch moves the parvirtprobe section into .init.data: it's only used in very very early boot, and for similar reasons, puts lguest_maybe_init and lguest_memory_setup in init.text. As well as fixing some warnings, this frees up a tiny bit more memory. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> diff -r ecec388180b2

Thanks to Andrew for pointing these out. This patch moves the parvirtprobe section into .init.data: it's only used in very very early boot, and for similar reasons, puts lguest_maybe_init and lguest_memory_setup in init.text. As well as fixing some warnings, this frees up a tiny bit more memory. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> diff -r ecec388180b2

The following patches introduce the core infrastructure needed to paravirtualize the 32-bit x86 Linux kernel. This is done by moving virtualization sensitive insn's or code paths to a function table, paravirt_ops. This structure can be populated with hypervisor specific calls or native stubs and currently support running on bare metal, VMI, Xen, or Lhype. These patches apply to

The following patches introduce the core infrastructure needed to paravirtualize the 32-bit x86 Linux kernel. This is done by moving virtualization sensitive insn's or code paths to a function table, paravirt_ops. This structure can be populated with hypervisor specific calls or native stubs and currently support running on bare metal, VMI, Xen, or Lhype. These patches apply to

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

The current code simply calls "start_kernel" directly if we're under a hypervisor and no paravirt_ops backend wants us, because paravirt.c registers that as a backend. This was always a vain hope; start_kernel won't get far without setup. It's also impossible for paravirt_ops backends which don't sit in the arch/i386/kernel directory: they can't link before

The current code simply calls "start_kernel" directly if we're under a hypervisor and no paravirt_ops backend wants us, because paravirt.c registers that as a backend. This was always a vain hope; start_kernel won't get far without setup. It's also impossible for paravirt_ops backends which don't sit in the arch/i386/kernel directory: they can't link before

[ 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

plain text document attachment (xx-paravirt-boot.patch) Boot up code modifications to get paravirt ops running. Signed-off-by: Steven Rostedt srostedt@redhat.com Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> Index: clean-start/arch/x86_64/kernel/head.S =================================================================== --- clean-start.orig/arch/x86_64/kernel/head.S +++

plain text document attachment (xx-paravirt-boot.patch) Boot up code modifications to get paravirt ops running. Signed-off-by: Steven Rostedt srostedt@redhat.com Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> Index: clean-start/arch/x86_64/kernel/head.S =================================================================== --- clean-start.orig/arch/x86_64/kernel/head.S +++

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

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

Red Hat 2.2.19-6.2.12 + 0.0.7a + https://listman.redhat.com/pipermail/ext3-users/2001-November/002258.html (not tuned in /proc yet) + journal 4MB on each fs + 6 ext3 fs on raid1 (hda+hdc) + 1 ext3 fs on another disk not on raid1 (hdd) While untarring (tar zxf) a file that was on a ext3/raid1 onto hdd I got: ksymoops 2.3.4 on i686 2.2.19-6.2.12.g1. Options used -V (default) -k

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,

Folks -- One more time with the PAE request, this time I''ve brought up the Linux kernel w/ a very recent version of Xen. (Just yesterday 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