search for: map_domain_pirq

...include <xen/keyhandler.h> #include <asm/mc146818rtc.h> #include <asm/smp.h> @@ -2493,12 +2491,10 @@ int ioapic_guest_write(unsigned long phy add_pin_to_irq(irq, apic, pin); } - spin_lock(&pcidevs_lock); spin_lock(&dom0->event_lock); ret = map_domain_pirq(dom0, pirq, irq, MAP_PIRQ_TYPE_GSI, NULL); spin_unlock(&dom0->event_lock); - spin_unlock(&pcidevs_lock); if ( ret < 0 ) return ret; --- a/xen/arch/x86/irq.c +++ b/xen/arch/x86/irq.c @@ -1661,10 +1661,7 @@ int map_domain_pirq( struct pirq *info...

..._free_pirq(struct domain *d, int type, int index) { int i; - if ( d == NULL ) - return -EINVAL; - - ASSERT(spin_is_locked(&d->arch.irq_lock)); + ASSERT(spin_is_locked(&d->evtchn_lock)); if ( type == MAP_PIRQ_TYPE_GSI ) { @@ -64,11 +58,10 @@ static int map_domain_pirq(struct domain int ret = 0; int old_vector, old_pirq; struct msi_info msi; - - if ( d == NULL ) - return -EINVAL; - - ASSERT(spin_is_locked(&d->arch.irq_lock)); + irq_desc_t *desc; + unsigned long flags; + + ASSERT(spin_is_locked(&d->evtchn_lock));...

...evelopers in community. Thanks, -- Shohei Fujiwara. Signed-off-by: Shohei Fujiwara <fujiwara-sxa@necst.nec.co.jp> diff -r b9721b2766c1 xen/arch/x86/irq.c --- a/xen/arch/x86/irq.c Wed Jan 07 11:25:00 2009 +0000 +++ b/xen/arch/x86/irq.c Thu Jan 08 18:58:36 2009 +0900 @@ -857,7 +857,7 @@ int map_domain_pirq( if ( type == MAP_PIRQ_TYPE_MSI ) return -EINVAL; - if ( !IS_PRIV(current->domain) ) + if ( !IS_PRIV_FOR(current->domain, d) ) return -EPERM; if ( pirq < 0 || pirq >= NR_IRQS || vector < 0 || vector >= NR_VECTORS ) @@ -931,7 +931,7 @@ int unma...

...0000000 0000000000000000 (XEN)    00000000edab3ed4 000000000000000d 0000000000000000 0000000000000000 (XEN)    0000000000000000 0000000000000000 0000000000000021 000000000a0fa004 (XEN) Xen call trace: (XEN)    [<ffff82c480161a08>] pci_enable_msi+0x464/0x960 (XEN)    [<ffff82c480163850>] map_domain_pirq+0x20f/0x309 (XEN)    [<ffff82c4802121d0>] compat_physdev_op+0x9e0/0x1420 (XEN)    [<ffff82c480214ec1>] compat_hypercall+0xa1/0xfa (XEN) (XEN) Xen WARN at msi.c:648 (XEN) ----[ Xen-4.1.0.rc2.pre  x86_64  debug=y  Not tainted ]---- (XEN) CPU:    7 (XEN) RIP:    e008:[<ffff82c480161a8c&...

...eated as edge-triggered interrupts, except * when there is no proper way to mask them. */ - if ( desc->handler == &pci_msi_type ) + if ( desc->msi_desc ) return msi_maskable_irq(desc->msi_desc) ? ACKTYPE_NONE : ACKTYPE_EOI; /* @@ -1722,7 +1722,7 @@ int map_domain_pirq( if ( desc->handler != &no_irq_type ) dprintk(XENLOG_G_ERR, "dom%d: irq %d in use\n", d->domain_id, irq); - desc->handler = &pci_msi_type; + setup_msi_handler(desc, msi_desc); if ( opt_irq_vector_map == O...

...of how to use the user field in the security context. Debug output: [PATCH 01/10] xsm: Add security labels to event-channel dump [PATCH 02/10] xsm: Add security label to IRQ debug output MSI interrupt fixes: [PATCH 03/10] xsm/flask: Use PCI device label for PCI-MSI IRQs [PATCH 04/10] xsm: Add xsm_map_domain_pirq hook [PATCH 05/10] xsm: Use mapped IRQ not PIRQ in unmap_domain_pirq Cleanup: [PATCH 06/10] xsm/flask: Improve error reporting for ocontexts [PATCH 07/10] xsm/flask: Remove useless back pointers [PATCH 08/10] flask/policy: Policy build updates [PATCH 09/10] flask/policy: Add user and constraint ex...

...cifically does not introduce a command line argument for this mode to avoid needing to carry it forever more for compatibility reasons. Unfortunately, the per-device logic is going to be very complicated to fix. Under the current irq architecture, by the time you can work out you have a problem in map_domain_pirq(), it is far too late to fix it in a compatible way. It would be possible to "fix" the issue by failing the hypercall, but is not acceptable IMO. One logical way to fix the issue would be to reassign one of the irqs to a different vector, but that requires waiting for another interrupt,...

...db9d608 00000000000007c9 (XEN) 0000000000000217 0000000000000000 ffff88002bab02a0 ffff88002e45ac00 (XEN) 0000000000000021 ffffffff8100142a 0000000000000000 ffff88002db9d568 (XEN) Xen call trace: (XEN) [<ffff82c48015b450>] pci_enable_msi+0x466/0x945 (XEN) [<ffff82c48015cd07>] map_domain_pirq+0x28a/0x377 (XEN) [<ffff82c4801700a2>] do_physdev_op+0x7f2/0x1040 (XEN) [<ffff82c4801fb8e2>] syscall_enter+0xf2/0x14c (XEN) (XEN) Xen WARN at msi.c:649 (XEN) ----[ Xen-4.1-unstable x86_64 debug=y Not tainted ]---- (XEN) CPU: 3 (XEN) RIP: e008:[<ffff82c48015b4ce>...

Hi, I''ve still have problems with ACPI(?) on Xen. After some system startup or resume CPU temperature goes high although all domUs (and dom0) are idle. On "good" system startup it is about 50-55C, on "bad" - above 67C (most time above 70C). I''ve noticed difference in C-states repored by Xen (attached files). On "bad" startups in addition suspend

Hey, It looks like one of the patches that went in Xen 4.1 blows up. This used to work over the weekend, so I can only surmise it is one the three patches. This is with a debug=y build (which has been working nicely for the last month or more). It looks like one of the patches that went in Xen 4.1 blows up. This used to work a day ago - that is c/s 23551 worked nicely. ----- Forwarded message