search for: pirq_guest_bind

@@ -491,16 +512,15 @@ int pirq_guest_bind(struct vcpu *v, int int rc = 0; cpumask_t cpumask = CPU_MASK_NONE; + WARN_ON(!spin_is_locked(&v->domain->evtchn_lock)); I find this WARN_ON() is triggered harmlessly when I assign device to HVM guest. The call trace is XEN_DOMCTL_bind_pt_irq ->...

...y_init-> msix_program_entries-> msix_mask_irq-> entry->masked = 1 request_irq-> __setup_irq-> irq_startup-> __startup_pirq-> EVTCHNOP_bind_pirq hypercall (trap into Xen) [Xen:] pirq_guest_bind-> startup_msi_irq-> unmask_msi_irq-> msi_set_mask_bit-> entry->msi_attrib.masked = 0 So entry->msi_attrib.masked in xen side always has newest value. entry->masked in initial domain is untouched and is 1 after msix_capability_init. Base...

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

...RQ 59 (error -22) [ 2.836780] xen:events: Failed to obtain physical IRQ 60 (error -22) [ 2.836793] xen:events: Failed to obtain physical IRQ 61 (error -22) There is a check: 463 if ( (pirq < 0) || (pirq >= d->nr_pirqs) ) 464 return -EINVAL; But there is also a call to pirq_guest_bind, which could return EINVAL. > Anyhow for PV guests in the hypervisor there is a check: > 414 if ( !is_hvm_domain(d) && !pirq_access_permitted(d, pirq) ) > 415 return -EPERM; > 416 > > And I wonder if the XEN_DOMCTL_irq_permission aka, xc_domain_irq_permis...

...ock(&d->arch.hvm_domain.msixtbl_list_lock); r = 0; diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c index 13002c0..17cb8c2 100644 --- a/xen/drivers/passthrough/io.c +++ b/xen/drivers/passthrough/io.c @@ -153,7 +153,8 @@ int pt_irq_create_bind( rc = pirq_guest_bind(d->vcpu[0], info, 0); if ( rc == 0 && pt_irq_bind->u.msi.gtable ) { - rc = msixtbl_pt_register(d, info, pt_irq_bind->u.msi.gtable); + rc = msixtbl_pt_register(d, info, pt_irq_bind->u.msi.gtable, +...

Hello everyone, this is the fourth version of the patch series that introduces ARMv7 with virtualization extensions support in Xen. The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile Express simulator. See the following announce email for more informations about what we are trying to achieve, as well as the original git history: See

Hello everyone, this is the very first version of the patch series that introduces ARMv7 with virtualization extensions support in Xen. The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile Express simulator. See the following announce email for more informations about what we are trying to achieve, as well as the original git history: See