[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 02/10] IOMMU: handle IOMMU mapping and unmapping failures
>>> On 12.05.16 at 16:28, <quan.xu@xxxxxxxxx> wrote: > On May 10, 2016 2:54 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote: >> >>> On 10.05.16 at 05:41, <quan.xu@xxxxxxxxx> wrote: >> > On May 10, 2016 12:14 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote: >> >> >>> On 06.05.16 at 10:54, <quan.xu@xxxxxxxxx> wrote: >> For DomU the solution seems quite obvious: Only log a message if the domain >> is not already marked crashed. > > Jan, I am still confused about this sentence and your another sentence ( > _as said_ also avoid logging any message for already dying domains). The two say the same, so I don't see what you're confused about. Please be more precise. >> For Dom0 you'll need to get a little more >> creative (but by leveraging the fact that there's only one in the system, > this >> can't be too difficult a problem to solve: >> e.g. "manually" rate limit these messages - see printk_ratelimit() et al). >> > > Reading this thread again and again, sorry, I am still inclined to: > > + rc = hd->platform_ops->unmap_page(d, gfn); > + > + if ( unlikely(rc) ) > + { > + if ( printk_ratelimit() ) > + printk(XENLOG_ERR > + "dom%d: IOMMU unmapping gfn %#lx failed %d.", > + d->domain_id, gfn, rc); > + > + if ( !is_hardware_domain(d) ) > + domain_crash(d); > + } > + > + return rc; This is certainly better than unconditional logging, but will still produce more than one message per crashed guest (or for Dom0) on a batch of unmaps. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |