search for: get_current

Is there any particular reason why on 32-bits the order is VMLOAD then HVM_SAVE_ALL_NOSEGREGS, while on 64-bits its is the other way around? Trying to put in the saving of EAX, I could save a GET_CURRENT() on 32-bits if I could order things the same way as on 64-bits. Also, both versions seem to have a redundant GET_CURRENT() right after the clgi/sti sequence - again, is there a particular reason for this? Thanks, Jan _______________________________________________ Xen-devel mailing list Xen-d...

...275,13 @@ ENTRY(sysenter_entry) pushfq .globl sysenter_eflags_saved sysenter_eflags_saved: - pushq $0 - pushq $0 + pushq $3 /* ring 3 null cs */ + pushq $0 /* null rip */ pushq $0 movl $TRAP_syscall,4(%rsp) SAVE_ALL GET_CURRENT(%rbx) cmpb $0,VCPU_sysenter_disables_events(%rbx) - movq $0,UREGS_rip(%rsp) /* null rip */ - movl $3,UREGS_cs(%rsp) /* ring 3 null cs */ movq VCPU_sysenter_addr(%rbx),%rax setne %cl leaq VCPU_trap_bounce(%rbx),%rdx @@ -292,7 +290,6 @@ sysenter...

This set of patches converts the way frames gets created from using PUSHes/POPs to using MOVes, thus allowing (in certain cases) to avoid saving/restoring part of the register set. While the place where the (small) win from this comes from varies between CPUs, the net effect is a 1 to 2% reduction on a combined interruption entry and exit when the full state save can be avoided. 1: use MOV

...ding in the Mini-OS (on x86) has some problems: a) a stack overflow overwrites the pointer to the thread''s "struct thread". Perhaps one could a segment register to point to the thread control block? b) GCC seems to use ESP as general purpose register now and then. This makes get_current() or current return bogus values. A workaround to that is to not inline get_current() or use the pointer to a local variable (which is an approximation to the current stack pointer) to compute the struct thread pointer. c) All threads are limited to the same stack size. d) and yes, it''...

The self_nmi() code cause''s an NMI to be triggered by sending an APIC message to the local processor. However, NMIs are blocked by the VMEXIT, until the next iret or VMENTER. Volume 3 Chapter 27 Section 1 of the Intel SDM states: An NMI causes subsequent NMIs to be blocked, but only after the VM exit completes. As a result, as soon as the VMENTER happens, an immediate VMEXIT happens

...Cyclomatic Complexity 1 include/linux/log2.h:__ilog2_u32 Cyclomatic Complexity 1 include/linux/list.h:INIT_LIST_HEAD Cyclomatic Complexity 1 include/linux/list.h:__list_del Cyclomatic Complexity 1 include/linux/list.h:list_empty Cyclomatic Complexity 1 arch/x86/include/asm/current.h:get_current Cyclomatic Complexity 3 include/linux/string.h:memset Cyclomatic Complexity 5 include/linux/string.h:memcpy Cyclomatic Complexity 1 include/asm-generic/getorder.h:__get_order Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_dec_and_test Cyclomatic Complexity 1 includ...

...# CS - cmpw $FLAT_KERNEL_CS32,%r11 + cmpw $FLAT_USER_CS32,%r11 popq %r11 # RFLAGS popq %rsp # RSP je 1f @@ -127,6 +131,9 @@ ENTRY(syscall_enter) movl $TRAP_syscall,4(%rsp) SAVE_ALL GET_CURRENT(%rbx) + movq VCPU_domain(%rbx),%rcx + testb $1,DOMAIN_is_32bit_pv(%rcx) + jnz compat_syscall testb $TF_kernel_mode,VCPU_thread_flags(%rbx) jz switch_to_kernel @@ -224,6 +231,41 @@ bad_hypercall: movq $-ENOSYS,UREGS_rax(%rsp) jmp test...

...rch/x86/x86_32/entry.S =================================================================== --- 2007-03-19.orig/xen/arch/x86/x86_32/entry.S 2007-02-28 12:10:37.000000000 +0100 +++ 2007-03-19/xen/arch/x86/x86_32/entry.S 2007-03-27 12:12:51.000000000 +0200 @@ -173,7 +173,7 @@ ENTRY(hypercall) GET_CURRENT(%ebx) cmpl $NR_hypercalls,%eax jae bad_hypercall - PERFC_INCR(PERFC_hypercalls, %eax) + PERFC_INCR(PERFC_hypercalls, %eax, %ebx) #ifndef NDEBUG /* Create shadow parameters and corrupt those not used by this call. */ pushl %eax @@ -429,7 +429,7 @...

Hi Andrew, This patch series adds to the end of the existing i386-gdt-cleanups patches: allow-per-cpu-variables-to-be-page-aligned.patch i386-gdt-cleanups-use-per-cpu-variables-for-gdt-pda.patch i386-gdt-cleanups-use-per-cpu-gdt-immediately-upon-boot.patch i386-gdt-cleanups-use-per-cpu-gdt-immediately-upon-boot-fix.patch i386-gdt-cleanups-clean-up-cpu_init.patch

Hi Andrew, This patch series adds to the end of the existing i386-gdt-cleanups patches: allow-per-cpu-variables-to-be-page-aligned.patch i386-gdt-cleanups-use-per-cpu-variables-for-gdt-pda.patch i386-gdt-cleanups-use-per-cpu-gdt-immediately-upon-boot.patch i386-gdt-cleanups-use-per-cpu-gdt-immediately-upon-boot-fix.patch i386-gdt-cleanups-clean-up-cpu_init.patch

...ct(Int32 typeIndex) at System.Resources.ResourceReader.LoadObjectV2(Int32 pos, ResourceTypeCode& typeCode) at System.Resources.ResourceReader.LoadObject(Int32 pos) at System.Resources.ResourceReader.ResourceEnumerator.get_Entry() at System.Resources.ResourceReader.ResourceEnumerator.get_Current() at System.ComponentModel.ComponentResourceManager.FillResources(CultureInfo culture, ResourceSet& resourceSet) at System.ComponentModel.ComponentResourceManager.FillResources(CultureInfo culture, ResourceSet& resourceSet) at System.ComponentModel.ComponentResourceManager.FillReso...

Hi Jeremy, all, Sorry this took so long, spent last week in Japan at OSDL conf then netconf. After several false starts, I ended up with a very simple implementation, which clashes significantly with your work since then 8(. I've pushed the patches anyway, but it's going to be significant work for me to re-merge them, so I wanted your feedback first. The first patch simply changes

Hi Jeremy, all, Sorry this took so long, spent last week in Japan at OSDL conf then netconf. After several false starts, I ended up with a very simple implementation, which clashes significantly with your work since then 8(. I've pushed the patches anyway, but it's going to be significant work for me to re-merge them, so I wanted your feedback first. The first patch simply changes

From: Yang Zhang <yang.z.zhang@Intel.com> The follwoing patches are adding the Posted Interrupt supporting to Xen: Posted Interrupt allows vAPIC interrupts to inject into guest directly without any vmexit. - When delivering a interrupt to guest, if target vcpu is running, update Posted-interrupt requests bitmap and send a notification event to the vcpu. Then the vcpu will handle this

Hi Andi, This is a series of patches based on your latest queue (as of the other day, at least). It includes: - the most recent patch to compute the appropriate amount of percpu space to allocate, using a separate reservation for modules where needed. - make the percpu sections page-aligned, so that percpu variables can be page aligned if needed (which is used by gdt_page) -

Hi Andi, This is a series of patches based on your latest queue (as of the other day, at least). It includes: - the most recent patch to compute the appropriate amount of percpu space to allocate, using a separate reservation for modules where needed. - make the percpu sections page-aligned, so that percpu variables can be page aligned if needed (which is used by gdt_page) -

Hi: This series tries to fix various issues of vhost: - Patch 1 adds a missing write barrier between used idx updating and logging. - Patch 2-3 brings back the protection of device IOTLB through vq mutex, this fixes possible use after free in device IOTLB entries. - Patch 4 fixes the diry page logging when device IOTLB is enabled. We should done through GPA instead of GIOVA, this was done

Hi: This series tries to fix various issues of vhost: - Patch 1 adds a missing write barrier between used idx updating and logging. - Patch 2-3 brings back the protection of device IOTLB through vq mutex, this fixes possible use after free in device IOTLB entries. - Patch 4 fixes the diry page logging when device IOTLB is enabled. We should done through GPA instead of GIOVA, this was done

Hi Andi, This is a set of updates for the firstfloor patch queue. Quick rundown: revert-mm-x86_64-mm-account-for-module-percpu-space-separately-from-kernel-percpu.patch separate-module-percpu-space.patch Update the module percpu accounting patch fix-ff-allow-percpu-variables-to-be-page-aligned.patch Make sure the percpu memory allocation is page-aligned

Hi Andi, This is a set of updates for the firstfloor patch queue. Quick rundown: revert-mm-x86_64-mm-account-for-module-percpu-space-separately-from-kernel-percpu.patch separate-module-percpu-space.patch Update the module percpu accounting patch fix-ff-allow-percpu-variables-to-be-page-aligned.patch Make sure the percpu memory allocation is page-aligned