search for: xenlog_g_warn

...arch/x86/mm.c @@ -869,7 +869,7 @@ get_page_from_l1e( return -EINVAL; } - if ( !(l1f & _PAGE_RW) || IS_PRIV(pg_owner) || + if ( !(l1f & _PAGE_RW) || !rangeset_contains_singleton(mmio_ro_ranges, mfn) ) return 0; dprintk(XENLOG_G_WARNING, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

...dprintk(XENLOG_G_ERR, "dom%d: pirq %d not mapped\n", d->domain_id, pirq); @@ -158,20 +146,34 @@ static int unmap_domain_pirq(struct doma goto done; } + forced_unbind = (pirq_guest_unbind(d, pirq) == 0); + if ( forced_unbind ) + dprintk(XENLOG_G_WARNING, "dom%d: forcing unbind of pirq %d\n", + d->domain_id, pirq); + desc = &irq_desc[vector]; spin_lock_irqsave(&desc->lock, flags); + + BUG_ON(vector != d->arch.pirq_vector[pirq]); + if ( desc->msi_desc ) pci_disable_msi(vector...

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

(moving to xen-devel, xen-arm is for the older PV ARM port) On Tue, 2013-06-25 at 23:59 +0000, Eric Trudeau wrote: > Hi, I am trying to build the XEN tools for our port of XEN to our > Cortex A15-based platform. > > I am using the repo at git://xenbits.xenproject.org/xen.git to > cross-compile the tools into our rootfs. Which branch/changeset are you using? I've heard that

This patch series is a reworking of a series developed by Mukesh Rathor at Oracle. The entirety of the design and development was done by him; I have only reworked, reorganized, and simplified things in a way that I think makes more sense. The vast majority of the credit for this effort therefore goes to him. This version is labelled v13 because it is based on his most recent series, v11.

What are the outstanding things to do before we think we can start on the 4.2 -rc''s? Does anyone have a timetable in mind? hypervisor: * ??? - Keir, Tim, Jan? tools: * libxl stable API -- we would like 4.2 to define a stable API which downstream''s can start to rely on not changing. Aspects of this are: * event handling (IanJ working