search for: guest_cpu_user_regs

This series consists of improvements to Xen''s ability to print traces of its own stack, and specifically for the stack overflow case to be able to use frame pointers in a debug build. I have dev tested the series in debug and non-debug cases, with and without memory guards, and I believe that all the stack traces look correct. However, I would greatly appreciate a second opinion on the

...--git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c index 7d1a5ad..39b9775 100644 --- a/xen/arch/arm/vgic.c +++ b/xen/arch/arm/vgic.c @@ -160,7 +160,7 @@ static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info) { struct hsr_dabt dabt = info->dabt; struct cpu_user_regs *regs = guest_cpu_user_regs(); - uint32_t *r = &regs->r0 + dabt.reg; + uint32_t *r = select_user_reg(regs, dabt.reg); struct vgic_irq_rank *rank; int offset = (int)(info->gpa - VGIC_DISTR_BASE_ADDRESS); int gicd_reg = REG(offset); @@ -372,7 +372,7 @@ static int vgic_distr_mmio_write(struct vcpu...

...is happens early in HVM guest boot, I suggest adding tracing to >vmx_vmexit_handler() to dump registers on every MSR write. >Something like >this early on in the function: > if ( reason == EXIT_REASON_MSR_WRITE ) { > printk("regs==%p, guest_regs==%p\n", &regs, >guest_cpu_user_regs()); > show_registers(&regs); > } > >This will let us see if the EAX/EDX are garbage on entry to C code >immediately after VMEXIT. This patch doesn''t help, after applying it, all is OK. -Xin _______________________________________________ Xen-devel mailing list Xen-...

...ig/xen/arch/x86/hvm/svm/svm.c 2007-06-15 14:05:46.000000000 +0200 +++ 2007-06-18/xen/arch/x86/hvm/svm/svm.c 2007-06-18 10:23:05.000000000 +0200 @@ -1477,7 +1477,7 @@ static void svm_io_instruction(struct vc /* Copy current guest state into io instruction state structure. */ memcpy(regs, guest_cpu_user_regs(), HVM_CONTEXT_STACK_BYTES); - hvm_store_cpu_guest_regs(v, regs, NULL); + svm_store_cpu_guest_regs(v, regs, NULL); info.bytes = vmcb->exitinfo1; Index: 2007-06-18/xen/arch/x86/hvm/vmx/vmx.c =================================================================== --- 2007-06-18.orig/xen...

...ed to keep my variant because I had done regression testing already and did not unnecessarily change code. Jan's proposal: @@ -1364,7 +1358,6 @@ void vmx_inject_hw_exception(int trap, i switch ( trap ) { case TRAP_debug: - type = X86_EVENTTYPE_SW_EXCEPTION; if ( guest_cpu_user_regs()->eflags & X86_EFLAGS_TF ) { __restore_debug_registers(curr); @@ -1379,9 +1372,11 @@ void vmx_inject_hw_exception(int trap, i domain_pause_for_debugger(); return; } - - type = X86_EVENTTYPE_SW_EXCEPTION; - __vmwrite(VM_E...

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

Changes from v1 to v2: - Use a macro to replace the hardcode in patch 1/3. This patchset fixes issues about IA32_VMX_MISC MSR emulation, VMCS guest area synchronization about PAGE_FAULT_ERROR_CODE_MASK/PAGE_FAULT_ERROR_CODE_MATCH, and CR0/CR4 emulation. Please help to review and pull. Thanks, Dongxiao Dongxiao Xu (3): nested vmx: emulate IA32_VMX_MISC MSR nested vmx: synchronize page

...     Wed Feb 24 11:11:05 2010 +0000 > @@ -144,11 +144,13 @@ static void ns16550_interrupt( >     } >  } > > -static void ns16550_poll(void *data) > -{ > -    struct serial_port *port = data; > -    struct ns16550 *uart = port->uart; > -    struct cpu_user_regs *regs = guest_cpu_user_regs(); > +/* Safe: ns16550_poll() runs in softirq context so not reentrant on a given CPU. */ > +static DEFINE_PER_CPU(struct serial_port *, poll_port); > + > +static void __ns16550_poll(struct cpu_user_regs *regs) > +{ > +    struct serial_port *port = this_cpu(poll_port); > +    ...

...struct trap_info *ti; @@ -852,6 +863,8 @@ void propagate_page_fault(unsigned long v->domain->domain_id, v->vcpu_id, error_code); show_page_walk(addr); } + else if ( unlikely(error_code & PFEC_reserved_bit) ) + reserved_bit_page_fault(1, addr, guest_cpu_user_regs()); } static int handle_gdt_ldt_mapping_fault( @@ -1034,8 +1047,10 @@ static int fixup_page_fault(unsigned lon struct vcpu *v = current; struct domain *d = v->domain; - /* No fixups in interrupt context or when interrupts are disabled. */ - if ( in_irq() || !(regs->efl...

...et correct instruction + * length. + */ void vmx_inject_hw_exception(int trap, int error_code) { unsigned long intr_info; @@ -1365,7 +1378,6 @@ void vmx_inject_hw_exception(int trap, i switch ( trap ) { case TRAP_debug: - type = X86_EVENTTYPE_SW_EXCEPTION; if ( guest_cpu_user_regs()->eflags & X86_EFLAGS_TF ) { __restore_debug_registers(curr); @@ -1383,16 +1395,14 @@ void vmx_inject_hw_exception(int trap, i return; } - type = X86_EVENTTYPE_SW_EXCEPTION; - __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* int3 */ -...

Changes from v1: - Define new struct hvm_trap to represent information of trap, include instruction length. - Renames hvm_inject_exception to hvm_inject_trap. Then define a couple of wrappers around that function for existing callers, so that their parameter lists actually *shrink*. This series of patches fix the mistake for debug exception(#DB), overflow exception(#OF) and INT3(#BP),

...++#define multicall_ret(call) \ ++ (unlikely((call)->op == __HYPERVISOR_iret) \ ++ ? mc_exit \ ++ : likely(guest_kernel_mode(current, \ ++ guest_cpu_user_regs())) \ ++ ? mc_continue : mc_preempt) ++ + #define do_multicall_call(_call) \ +- do { \ ++ ({ \ + __asm__ __volatile__ (...

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

Moritz Muehlenhoff writes ("Re: Xen package security updates for jessie 4.4, XSA-213, XSA-214"): > On Thu, May 04, 2017 at 05:06:07PM +0100, Ian Jackson wrote: > > I have fixed these in stretch but the jessie package remains unfixed. > > I think I may be able to find some backports somewhere. Would that be > > useful ? Is anyone else working on this ? > >

This series of patches fix the mistake for debug exception(#DB), overflow exception(#OF) and INT3(#BP), INTn instruction emulation. Introduce new function vmx_inject_sw_exception() which deliver the software excetion, software interrupt and privileged software exception. Split hardware exception as a seperate function(old function vmx_inject_hw_exception()). Also Passed down intruction length

This patch series implements SMP boot for arch/arm, as far as getting all CPUs up and running the idle loop. Changes from v1: - moved barriers out of loop in udelay() - dropped broken GIC change in favour of explanatory comment - made the increment of ready_cpus atomic (I couldn''t move the increment to before signalling the next CPU because the PT switch has to happen between

Hi all, this small patch series implement guest SMP support for ARM, using the ARM PSCI interface for secondary cpu bringup. Stefano Stabellini (4): xen/arm: basic PSCI support, implement cpu_on xen/arm: support for guest SGI xen/arm: support vcpu_op hypercalls xen: move VCPUOP_register_vcpu_info to common code xen/arch/arm/domain.c | 66 ++++++++++++++++++++++++

First off, Apologies for the massive patch series... This series boots a 32-bit dom0 kernel to a command prompt on an ARMv8 (AArch64) model. The kernel is the same one as I am currently using with the 32 bit hypervisor I haven''t yet tried starting a guest or anything super advanced like that ;-). Also there is not real support for 64-bit domains at all, although in one or two places I

This series consists of improvements to Xen''s ability to print traces of its own stack, and specifically for the stack overflow case to be able to use frame pointers in a debug build. I have dev tested the series in debug and non-debug cases, with and without memory guards, and I believe that all the stack traces look correct (given the available information Xen has), and that the

This round implements all of the review comments from V2 and all patches are now acked. Unless there are any objections I intend to apply later this morning. Ian.