search for: instrlen

In hvm enviroment, acpi failed. why? centos5.1 =================================================== [root@hvm001 ~]# xm dmesg __ __ _____ _ ____ ___ ____ _ ____ \ \/ /___ _ __ |___ / / | |___ \ / _ \___ \ ___| | ___| \ // _ \ \047_ \ |_ \ | | __) |_| (_) |__) | / _ \ |___ \ / \ __/ | | | ___) || |_ / __/|__\__, / __/ | __/ |___) | /_/\_\___|_| |_| |____(_)_(_)_____| /_/_____(_)___|_|____/

Hi Andi, Here's a little batch of cleanups: - re-enable VDSO when PARAVIRT is enabled - make the parainstructions symbols match the other altinstructions naming convention - add kernel command-line options to disable altinstructions for smp and pv_ops Oh, and I'm mailing your noreplacement patch back at you, for no particularly good reason. J --

Hi Andi, Here's a little batch of cleanups: - re-enable VDSO when PARAVIRT is enabled - make the parainstructions symbols match the other altinstructions naming convention - add kernel command-line options to disable altinstructions for smp and pv_ops Oh, and I'm mailing your noreplacement patch back at you, for no particularly good reason. J --

Hi, all, I have difficulty on setting up lguest. Basic OS info: gcc 4.1.2 glibc: 2.5.1 binutils: 2.17 kernel: 2.6.23-rc1 Following lguest.txt instruction, I build lguest enaled kernel, disable CONFIG_COMPAT_VDSO, the host kernel boot fine, but when booting Qemu image using lguest laucher program, the guest kernel vmlinux panic, attached console.txt is console output, and config.txt is kernel

Hi, all, I have difficulty on setting up lguest. Basic OS info: gcc 4.1.2 glibc: 2.5.1 binutils: 2.17 kernel: 2.6.23-rc1 Following lguest.txt instruction, I build lguest enaled kernel, disable CONFIG_COMPAT_VDSO, the host kernel boot fine, but when booting Qemu image using lguest laucher program, the guest kernel vmlinux panic, attached console.txt is console output, and config.txt is kernel

...indirect CALL offset: 0x%x, CALL *0x%lx", + *(s32 *)(insnbuf + 2), + (unsigned long)instr + *(s32 *)(insnbuf + 2) + 6); + + } else if (a->replacementlen && is_jmp(replacement[0])) { + /* direct jump */ recompute_jump(a, instr, replacement, insnbuf); + } if (a->instrlen > a->replacementlen) { add_nops(insnbuf + a->replacementlen, -- 2.13.6

We found several issues in ChangeSet 10319. ChangeSet 10314 should work according to our test log. 1, xen0 can not be compiled for IA-32/IA-32pae host since ChangeSet 10318. We tried gcc 3.4.2 and 4.1.0 but both failed. 2. On IA32e host, VMX can not be created. "xm cr" complains: Error: Not an HVM capable platform, we stop creating. 3, On IA32e host, "reboot" can not

...8]: Leaving directory `/home/test1/xen-unstable/xen/arch/x86/hvm/vmx/x86_64'' ld -m elf_x86_64 -r -o built_in.o io.o vmcs.o vmx.o x86_64/built_in.o make[7]: Leaving directory `/home/test1/xen-unstable/xen/arch/x86/hvm/vmx'' ld -m elf_x86_64 -r -o built_in.o hvm.o i8254.o i8259.o instrlen.o intercept.o io.o platform.o vioapic.o vlapic.o svm/built_in.o vmx/built_in.o make[6]: Leaving directory `/home/test1/xen-unstable/xen/arch/x86/hvm'' make -f /home/test1/xen-unstable/xen/Rules.mk -C mm built_in.o make[6]: Entering directory `/home/test1/xen-unstable/xen/arch/x86/mm'...

> Hmmm... wouldn''t it be nice if we didn''t have a bespoke, > buggy & incomplete emulator for hvm mmio. ;-) In the process of solving this one, I''ve got to (another) of the blocking points... At the moment, we translate the virtual address from the guest in the page-fault-handler to guest physical address via the gva_to_gpa() function in svm.c/vmx.c:

OK, this is the revised paravirt.h (Andi has seen this before), then the second is the binary patching stuff. More things get added to the paravirt struct in future patches, but this basic stuff hasn't changed for some time. ==== This patch does the dumbest possible replacement of paravirtualized instructions: calls through a "paravirt_ops" structure. Currently these are function

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

This changes the pv ops code generation to more closely match reality. For example, instead of: callq *0xffffffff81e3a400 (pv_irq_ops.save_fl) vmlinux will now show: pushfq pop %rax nop nop nop nop nop which is what the runtime version of the code will show in most cases. This idea was suggested by Andy Lutomirski. The benefits are: - For the most common runtime cases

This changes the pv ops code generation to more closely match reality. For example, instead of: callq *0xffffffff81e3a400 (pv_irq_ops.save_fl) vmlinux will now show: pushfq pop %rax nop nop nop nop nop which is what the runtime version of the code will show in most cases. This idea was suggested by Andy Lutomirski. The benefits are: - For the most common runtime cases