[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.