search for: evtchn_upcall_pending

...toilets and such) work today. I have come across this line of code that really I''m not sure what the intent was..in xen/include/sched.h #define hypercall_preempt_check() (unlikely( \ softirq_pending(smp_processor_id()) | \ (!!current->vcpu_info->evtchn_upcall_pending & \ !current->vcpu_info->evtchn_upcall_mask) \ )) the part where we have !!current->vcpu_info_evtchen_upcall pending should this be..should the "!! just be "!"? And if so shouldn''t this just be changed to #define hypercall_preempt_check()...

...h/x86/hvm/irq.c +++ b/xen/arch/x86/hvm/irq.c @@ -395,16 +395,16 @@ struct hvm_intack hvm_vcpu_has_pending_i struct hvm_domain *plat = &v->domain->arch.hvm_domain; int vector; - if ( (plat->irq.callback_via_type == HVMIRQ_callback_vector) - && vcpu_info(v, evtchn_upcall_pending) ) - return hvm_intack_vector(plat->irq.callback_via.vector); - if ( unlikely(v->nmi_pending) ) return hvm_intack_nmi; if ( unlikely(v->mce_pending) ) return hvm_intack_mce; + if ( (plat->irq.callback_via_type == HVMIRQ_callback_vector) +...

...flags in case any other notifications * are pending. */ - if ( d->shared_info->evtchn_pending[port/BITS_PER_LONG] ) - set_bit(port/BITS_PER_LONG, &v->vcpu_info->evtchn_pending_sel); - if ( v->vcpu_info->evtchn_pending_sel ) - v->vcpu_info->evtchn_upcall_pending = 1; + set_bit(port/BITS_PER_LONG, &v->vcpu_info->evtchn_pending_sel); + v->vcpu_info->evtchn_upcall_pending = 1; } void hvm_safe_block(void) @@ -735,12 +733,15 @@ for ( ; ; ) { /* Clear master flag & selector flag so we will wake from block. */ -...

...nsigned int l1i, l2i, port; - int irq; + int irq, owned; unsigned long flags; shared_info_t *s = HYPERVISOR_shared_info; vcpu_info_t *vcpu_info = &s->vcpu_data[smp_processor_id()]; local_irq_save(flags); - while ( s->vcpu_data[0].evtchn_upcall_pending ) + while ( vcpu_info->evtchn_upcall_pending ) { - s->vcpu_data[0].evtchn_upcall_pending = 0; + vcpu_info->evtchn_upcall_pending = 0; /* NB. No need for a barrier here -- XCHG is a barrier on x86. */ l1 = xen_xchg(&vcpu_info->evtchn_pending_se...

This patch is ported one from 534:77db69c38249 of linux-2.6.18-xen.hg. Use wmb instead of rmb to enforce ordering between evtchn_upcall_pending and evtchn_pending_sel stores in xen_evtchn_do_upcall(). Cc: Samuel Thibault <samuel.thibault at eu.citrix.com> Signed-off-by: Isaku Yamahata <yamahata at valinux.co.jp> --- drivers/xen/events.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/xen/even...

We seem to find an interesting bug, but not for sure. Each time before xen returns to hvm domain, it checks local_events_need_delivery to see whether any events pending and if yes, inject event by callback_irq into the virtual interrupt controller. However, the interesting point is, we never found any place, either in xen or in PV drivers, to clear evtchn_upcall_mask at any time. The initial

I''m just doing some testing on the gplpv drivers with different ways of handling interrupts, and I''m trying a scheme where each xen device (eg vbd/vif) driver attaches to the same IRQ as the pci driver, and each handles it in sequence. In testing though, I noticed the following when logging what each ISR is doing: 60.32381439 - evtchn event on port 5 60.32384109 - port 5

...h> +#ifdef CONFIG_COMPAT +#include <compat/xen.h> +#endif #include <asm/fixmap.h> #include <asm/hardirq.h> @@ -95,9 +98,15 @@ void __dummy__(void) OFFSET(VMCB_tsc_offset, struct vmcb_struct, tsc_offset); BLANK(); - OFFSET(VCPUINFO_upcall_pending, vcpu_info_t, evtchn_upcall_pending); - OFFSET(VCPUINFO_upcall_mask, vcpu_info_t, evtchn_upcall_mask); + OFFSET(VCPUINFO_upcall_pending, struct vcpu_info, evtchn_upcall_pending); + OFFSET(VCPUINFO_upcall_mask, struct vcpu_info, evtchn_upcall_mask); + BLANK(); + +#ifdef CONFIG_COMPAT + OFFSET(COMPAT_VCPUINFO_upcall_pend...

This topic came up months ago (under the thread "make hypercall_preempt_check() a little more sensitive"), but since then, due to a misunderstanding, PPC has been running with a hack instead of a solution. So anyways, I''ve been digging into this again. PowerPC domains are allowed to write to the "interrupts enabled" bit (called External Exceptions, or EE) in the

...intk("%d: masked=%d pending=%d event_sel %08lx\n ", i, - (get_irq_regs() && i == cpu) ? !(get_irq_regs()->flags & X86_EFLAGS_IF) : v->evtchn_upcall_mask, + (get_irq_regs() && i == cpu) ? xen_irqs_disabled(get_irq_regs()) : v->evtchn_upcall_mask, v->evtchn_upcall_pending, v->evtchn_pending_sel); } @@ -527,7 +527,10 @@ void xen_evtchn_do_upcall(struct pt_regs *regs) if (__get_cpu_var(nesting_count)++) goto out; - /* NB. No need for a barrier here -- XCHG is a barrier on x86. */ +#ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x...

...intk("%d: masked=%d pending=%d event_sel %08lx\n ", i, - (get_irq_regs() && i == cpu) ? !(get_irq_regs()->flags & X86_EFLAGS_IF) : v->evtchn_upcall_mask, + (get_irq_regs() && i == cpu) ? xen_irqs_disabled(get_irq_regs()) : v->evtchn_upcall_mask, v->evtchn_upcall_pending, v->evtchn_pending_sel); } @@ -527,7 +527,10 @@ void xen_evtchn_do_upcall(struct pt_regs *regs) if (__get_cpu_var(nesting_count)++) goto out; - /* NB. No need for a barrier here -- XCHG is a barrier on x86. */ +#ifndef CONFIG_X86 /* No need for a barrier -- XCHG is a barrier on x...

...erruptDpc\n")); @@ -81,7 +80,6 @@ EvtChn_Interrupt(WDFINTERRUPT Interrupt, { int cpu = 0; vcpu_info_t *vcpu_info; - int i; unsigned long evt_words, evt_word; unsigned long evt_bit; unsigned long port; @@ -96,8 +94,8 @@ EvtChn_Interrupt(WDFINTERRUPT Interrupt, vcpu_info->evtchn_upcall_pending = 0; - evt_words = _InterlockedExchange(&vcpu_info->evtchn_pending_sel, 0); - + evt_words = _InterlockedExchange((volatile LONG *)&vcpu_info->evtchn_pending_sel, 0); + while (_BitScanForward(&evt_word, evt_words)) { evt_words &= ~(1 << evt_word); @@ -114,7...

...atic inline void evtchn_check_unblock(struct vcpu *v) +{ + if ( v->vcpu_info->evtchn_upcall_mask && (v->vcpu_flags & VCPUF_blocked) ) + vcpu_unblock(v); +} /* * EVENT-CHANNEL NOTIFICATIONS @@ -35,6 +45,10 @@ !test_and_set_bit(0, &v->vcpu_info->evtchn_upcall_pending) ) { evtchn_notify(v); + } + else + { + evtchn_check_unblock(v); } } @@ -69,4 +83,7 @@ /* Bind a local event-channel port to the specified VCPU. */ extern long evtchn_bind_vcpu(unsigned int port, unsigned int vcpu_id); +#define evtchn_pending(s, e)...

...\ +(pred) movl clob = XSI_PSR_I_ADDR \ + ;; \ +(pred) ld8 clob = [clob] \ + ;; \ + /* if (pred) vpsr.i = 1 */ \ + /* if (pred) (vcpu->vcpu_info->evtchn_upcall_mask)=0 */ \ +(pred) st1 [clob] = r0, MASK_TO_PEND_OFS \ + ;; \ + /* if (vcpu->vcpu_info->evtchn_upcall_pending) */ \ +(pred) ld1 clob = [clob] \ + ;; \ +(pred) cmp.ne.unc pred_clob, p0 = clob, r0 \ + ;; \ +(pred_clob)XEN_HYPER_SSM_I /* do areal ssm psr.i */ + +#define RSM_PSR_I(pred, clob0, clob1) \ + movl clob0 = XSI_PSR_I_ADDR; \ + mov clob1 = 1; \ + ;; \ + ld8 clob0 = [clob0];...

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

I''m having trouble switching into user mode with my domU kernel -- everytime I call __HYPERVISOR_iret, the hypervisor calls into my kernel via the registered callback handler. None of the bits in the event channel pending arrays are set. If I return via the iret call, the hypervisor immediately calls back into the handler. The user RIP never changes, so it is clearly not making forward

...* CPU frequency (Hz): + * ((10^9 << 32) / tsc_to_system_mul) >> tsc_shift + */ + uint32_t tsc_to_system_mul; + int8_t tsc_shift; + int8_t pad1[3]; +}; /* 32 bytes */ +typedef struct vcpu_time_info vcpu_time_info_t; + +struct vcpu_info { + /* + * ''evtchn_upcall_pending'' is written non-zero by Xen to indicate + * a pending notification for a particular VCPU. It is then cleared + * by the guest OS /before/ checking for pending work, thus avoiding + * a set-and-check race. Note that the mask is only accessed by Xen + * on the CPU that is cu...

Hi. Recently the xen-ia64 community started to make efforts to merge xen/ia64 Linux to upstream. The first step is to merge up domU portion. This patchset is preliminary for xen/ia64 domU linux making the current xen/x86 domU code more arch generic and adding missing definitions and files. Diffstat: arch/x86/xen/Makefile | 4 +- arch/x86/xen/grant-table.c | 91

Hi. Recently the xen-ia64 community started to make efforts to merge xen/ia64 Linux to upstream. The first step is to merge up domU portion. This patchset is preliminary for xen/ia64 domU linux making the current xen/x86 domU code more arch generic and adding missing definitions and files. Diffstat: arch/x86/xen/Makefile | 4 +- arch/x86/xen/grant-table.c | 91

Hi. Recently the xen-ia64 community started to make efforts to merge xen/ia64 Linux to upstream. The first step is to merge up domU portion. This patchset is preliminary for xen/ia64 domU linux making the current xen/x86 domU code more arch generic and adding missing definitions and files. Diffstat: arch/x86/xen/Makefile | 4 +- arch/x86/xen/grant-table.c | 91