search for: virq

...-xen/evtchn.c --- a/freebsd-5.3-xen-sparse/i386-xen/i386-xen/evtchn.c 2005-04-30 17:06:55 -07:00 +++ b/freebsd-5.3-xen-sparse/i386-xen/i386-xen/evtchn.c 2005-04-30 17:06:55 -07:00 @@ -31,8 +31,9 @@ static int evtchn_to_irq[NR_EVENT_CHANNELS]; static int irq_to_evtchn[NR_IRQS]; -/* IRQ <-> VIRQ mapping. */ -static int virq_to_irq[NR_VIRQS]; +static int virq_to_irq[MAX_VIRT_CPUS][NR_VIRQS]; +static int ipi_to_evtchn[MAX_VIRT_CPUS][NR_VIRQS]; + /* Reference counts for bindings to IRQs. */ static int irq_bindcount[NR_IRQS]; @@ -120,7 +121,7 @@ mtx_lock(&irq_mapping_update_lock...

about VIRQ &amp; PIRQ what is VIRQ  ?How VIRQ is different from PIRQ ?How VIRQ &amp; PIRQ are related each other ? DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) a...

...received the maintenance interrupt. As a consequence if a vcpu is migrated to a different pcpu, the irq is going to be EOI''ed on the wrong pcpu. This covers the case where dom0 vcpu0 is running on pcpu1 for example (you can test this scenario by using xl vcpu-pin). Changes in v2: - pass virq by value to gic_irq_eoi; - EOI the interrupt without any spin locks held and with interrupt enabled. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> CC: keir@xen.org --- xen/arch/arm/gic.c | 24 +++++++++++++++++++++++- xen/arch/arm/vgic.c | 7 ++...

I''ve been looking into bug [1]#195 and I have a couple of questions on how timer interrupts and virqs are handled. Is it possible for dom0 linux to irq balance timer interrupts to different cpus? That is, if xen sends a VIRQ_TIMER to vcpu0, backed by cpu0, is it possible for that interrupt to be handled by vcpu1, backed by cpu1 ? After putting in some debug code in to timer_interrupt in linux...

...-- drivers/xen/events.c | 27 --------------------------- 1 files changed, 0 insertions(+), 27 deletions(-) diff --git a/drivers/xen/events.c b/drivers/xen/events.c index abad71b..d43957a 100644 --- a/drivers/xen/events.c +++ b/drivers/xen/events.c @@ -131,13 +131,6 @@ static struct irq_info mk_virq_info(unsigned short evtchn, unsigned short virq) .cpu = 0, .u.virq = virq }; } -static struct irq_info mk_pirq_info(unsigned short evtchn, - unsigned short gsi, unsigned short vector) -{ - return (struct irq_info) { .type = IRQT_PIRQ, .evtchn = evtchn, - .cpu = 0, .u.pirq = { .gsi =...

...-- drivers/xen/events.c | 27 --------------------------- 1 files changed, 0 insertions(+), 27 deletions(-) diff --git a/drivers/xen/events.c b/drivers/xen/events.c index abad71b..d43957a 100644 --- a/drivers/xen/events.c +++ b/drivers/xen/events.c @@ -131,13 +131,6 @@ static struct irq_info mk_virq_info(unsigned short evtchn, unsigned short virq) .cpu = 0, .u.virq = virq }; } -static struct irq_info mk_pirq_info(unsigned short evtchn, - unsigned short gsi, unsigned short vector) -{ - return (struct irq_info) { .type = IRQT_PIRQ, .evtchn = evtchn, - .cpu = 0, .u.pirq = { .gsi =...

...-- drivers/xen/events.c | 27 --------------------------- 1 files changed, 0 insertions(+), 27 deletions(-) diff --git a/drivers/xen/events.c b/drivers/xen/events.c index abad71b..d43957a 100644 --- a/drivers/xen/events.c +++ b/drivers/xen/events.c @@ -131,13 +131,6 @@ static struct irq_info mk_virq_info(unsigned short evtchn, unsigned short virq) .cpu = 0, .u.virq = virq }; } -static struct irq_info mk_pirq_info(unsigned short evtchn, - unsigned short gsi, unsigned short vector) -{ - return (struct irq_info) { .type = IRQT_PIRQ, .evtchn = evtchn, - .cpu = 0, .u.pirq = { .gsi =...

...ng to be EOI''ed on the wrong pcpu. This covers the case where dom0 vcpu0 is running on pcpu1 for example (you can test this scenario by using xl vcpu-pin). Changes in v3: - use an int rather than a cpumask to store the EOI cpu; - adds the eoi cpu to arch_irq_desc. Changes in v2: - pass virq by value to gic_irq_eoi; - EOI the interrupt without any spin locks held and with interrupt enabled. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> CC: keir@xen.org --- xen/arch/arm/gic.c | 23 ++++++++++++++++++++++- xen/arch/arm/irq.c | 1 + xen/in...

Hi, How can I raise VIRQ from hypervisor? -- Srujan D. Kotikela _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

''cat /proc/interrupts'' in a Linux PV domain shows interrupts starting at 256 and labelled as ''Dynamic-irq''. Are these available in a HVM domain, eg under Windows? Thanks James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

drivers/xen/balloon.c:50: WARNING: Use #include <linux/uaccess.h> instead of <asm/uaccess.h> drivers/xen/balloon.c:158: ERROR: else should follow close brace '}' drivers/xen/balloon.c:277: ERROR: do not use assignment in if condition drivers/xen/balloon.c:293: ERROR: code indent should use tabs where possible drivers/xen/balloon.c:364: ERROR: that open brace { should be on the

drivers/xen/balloon.c:50: WARNING: Use #include <linux/uaccess.h> instead of <asm/uaccess.h> drivers/xen/balloon.c:158: ERROR: else should follow close brace '}' drivers/xen/balloon.c:277: ERROR: do not use assignment in if condition drivers/xen/balloon.c:293: ERROR: code indent should use tabs where possible drivers/xen/balloon.c:364: ERROR: that open brace { should be on the

drivers/xen/balloon.c:50: WARNING: Use #include <linux/uaccess.h> instead of <asm/uaccess.h> drivers/xen/balloon.c:158: ERROR: else should follow close brace '}' drivers/xen/balloon.c:277: ERROR: do not use assignment in if condition drivers/xen/balloon.c:293: ERROR: code indent should use tabs where possible drivers/xen/balloon.c:364: ERROR: that open brace { should be on the

...tup uses hypercall bounce - Xenstore stub domain syslog support re-enabled Changes from v2: - configuration support added to mini-os build system - add mini-os support for conditionally compiling frontends, xenbus - XENMEM_remove_from_physmap moved out of arch-specific code - use uint32_t for virqs - warn when dropping grant v2-only flags when switching versions - IOCTL_XENBUS_BACKEND_SETUP name changed so userspace can implement compat - ioctl now returns -EEXIST if xenstored has already been connected - various cosmetic cleanups, shuffling Changes from v1: - set_virq_handler implemen...

...gt;Add a new console interface using a seperate shared page and event channel >instead of passing the console input/output over control messages. >Update xenconsoled to use the new console interface. >Make xenconsoled garbage collect dying domains by subscribing to >the domain exception virq. > > Why are we listening for virq? The polling method used before is considerably more robust. The virq''s aren''t always delivered on domain destruction (they are only delivered if a domain crashes or is shutdown). Moreover, I thought the overriding goal of this was t...

Checking 'irq < 0' doesn't work when 'irq' is unsigned. The assigned bind_evtchn_to_irq() and bind_virq_to_irq() return int, so using int appears appropriate. Signed-off-by: Nicolas Kaiser <nikai at nikai.net> --- drivers/xen/events.c | 6 ++---- 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/xen/events.c b/drivers/xen/events.c index 036343b..589f0a5 100644 --- a/dr...

Checking 'irq < 0' doesn't work when 'irq' is unsigned. The assigned bind_evtchn_to_irq() and bind_virq_to_irq() return int, so using int appears appropriate. Signed-off-by: Nicolas Kaiser <nikai at nikai.net> --- drivers/xen/events.c | 6 ++---- 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/xen/events.c b/drivers/xen/events.c index 036343b..589f0a5 100644 --- a/dr...

Checking 'irq < 0' doesn't work when 'irq' is unsigned. The assigned bind_evtchn_to_irq() and bind_virq_to_irq() return int, so using int appears appropriate. Signed-off-by: Nicolas Kaiser <nikai at nikai.net> --- drivers/xen/events.c | 6 ++---- 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/xen/events.c b/drivers/xen/events.c index 036343b..589f0a5 100644 --- a/dr...

Three of the patches could be squashed in one, but it makes more sense to review them as three. These patches fix the case of an PVHVM guest not being able to resume propely b/c of hitting: 142 BUG_ON(info->type != IRQT_UNBOUND && info->type != type); (in events.c) and also adds a WARN to catch situations like these. The reason for this is that the Xen python toolstack

I am currently looking at a bug report[1] which is happening when a Xen PVM guest with multiple VCPUs is running a high IO database load (a test script is available in the bug report). In experimenting it seems that this happens (or is getting more likely) when the number of VCPUs is 8 or higher (though I have not tried 6, only 2 and 4), having autogroup enabled seems to make it more likely, too