search for: physdev_map_pirq

...IV_FOR(current->domain, d) ) return -EINVAL; ASSERT(spin_is_locked(&pcidevs_lock)); diff -r b9721b2766c1 xen/arch/x86/physdev.c --- a/xen/arch/x86/physdev.c Wed Jan 07 11:25:00 2009 +0000 +++ b/xen/arch/x86/physdev.c Thu Jan 08 18:58:36 2009 +0900 @@ -34,9 +34,6 @@ static int physdev_map_pirq(struct physd struct msi_info _msi; void *map_data = NULL; - if ( !IS_PRIV(current->domain) ) - return -EPERM; - if ( !map ) return -EINVAL; @@ -49,6 +46,14 @@ static int physdev_map_pirq(struct physd { ret = -ESRCH; goto free_domain; +...

...SOURCE_UNSET | IORESOURCE_BUSY)) + return 0; + + return pci_resource_start(dev, bar); +} + /* * Protected by msi_lock */ static int msi_map_pirq_to_vector(struct pci_dev *dev, int pirq, - int entry_nr, int msi) + int entry_nr, u64 table_base) { struct physdev_map_pirq map_irq; int rc; @@ -254,10 +270,10 @@ map_irq.type = MAP_PIRQ_TYPE_MSI; map_irq.index = -1; map_irq.pirq = pirq; - map_irq.msi_info.bus = dev->bus->number; - map_irq.msi_info.devfn = dev->devfn; - map_irq.msi_info.entry_nr = entry_nr; - map_irq.msi_info.msi = msi; + map_i...

...rq_vector[pirq] = -vector; + d->arch.vector_pirq[vector] = -pirq; + } + spin_unlock_irqrestore(&desc->lock, flags); - - d->arch.pirq_vector[pirq] = d->arch.vector_pirq[vector] = 0; ret = irq_deny_access(d, pirq); if ( ret ) @@ -186,7 +188,6 @@ static int physdev_map_pirq(struct physd { struct domain *d; int vector, pirq, ret = 0; - unsigned long flags; if ( !IS_PRIV(current->domain) ) return -EPERM; @@ -243,8 +244,8 @@ static int physdev_map_pirq(struct physd goto free_domain; } - spin_lock_irqsave(&d->ar...

...hould try not to crash Xen as a result on guest input. :-) While generally I agree, I think in the given case this is unavoidable - Xen could apply some sanity check, but the passing of a machine address from Dom0 to Xen implies that Dom0 knows what it does, and Xen trusts it. Specifically, struct physdev_map_pirq has this contents according to the trace .domid = 00007ff0 .type = 00000000 .index = ffffffff .pirq = ffffffff .bus = 00000000 .devfn = 00000008 .entry_nr = 00000000 .table_base = f5861e4a00000001 table_base would seem like not having been initialized at all. I would guess that they use the struc...

...d to the xend event flow). Signed-off-by: Jan Beulich <jbeulich@suse.com> Tested-by: Andreas Falck <falck.andreas.lists@gmail.com> (on 4.1) Tested-by: Gordan Bobic <gordan@bobich.net> (on 4.2) --- a/tools/libxc/xc_physdev.c +++ b/tools/libxc/xc_physdev.c @@ -49,7 +49,7 @@ int xc_physdev_map_pirq(xc_interface *xc map.domid = domid; map.type = MAP_PIRQ_TYPE_GSI; map.index = index; - map.pirq = *pirq; + map.pirq = *pirq < 0 ? index : *pirq; rc = do_physdev_op(xch, PHYSDEVOP_map_pirq, &map, sizeof(map)); --- a/tools/python/xen/xend/server/pciif.py +++ b/too...

There is a BUG_ON() at xen/arch/x86/physdev.c:169 which appears to be dependent upon guest behavior (should close event channel before un-mapping pirq), rather than on internal hypervisor state. In 2.6.18, this likely goes unnoticed because pci_device_shutdown() only calls all the driver shutdown routines. In newer kernels, however, it also calls pci_msi_shutdown() and pci_msix_shutdown(), which