|
[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 |