From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zoltan Kiss Subject: Re: Grant unmap error checking in Dom0 Date: Tue, 18 Mar 2014 15:42:56 +0000 Message-ID: <53286980.3050204@citrix.com> References: <5328484E.5060701@citrix.com> <20140318133834.GC25364@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20140318133834.GC25364@phenom.dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Konrad Rzeszutek Wilk Cc: Ian Campbell , David Vrabel , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 18/03/14 13:38, Konrad Rzeszutek Wilk wrote: > On Tue, Mar 18, 2014 at 01:21:18PM +0000, Zoltan Kiss wrote: >> Hi, >> >> Just out of curiosity I've checked how Dom0 handles errors during >> grant unmapping. Usually there is a BUG_ON(ret) for the return value >> of gnttab_unmap_refs in blkback and netback, gntdev drops just a >> WARN. >> The return value can be non-zero only if Xen failed to copy the map >> operations back and forth to the guest supplied memory, so it's >> reasonable to crash there. However I'm wondering why gntdev is happy >> with just a WARN. >> Another thing, we don't check the status of the operations if the >> return value is zero. We shouldn't normally do that, Xen logs info >> messages in some cases, but not always (e.g. XSM or IOMMU problems). >> For debugging purposes however it could be useful to have the >> ability to turn on checking in Dom0. A quick and dirty way to do >> this is to use printk_get_level to figure out if the loglevel is >> e.g. KERN_NOTICE or lower, but I'm sure there is a better way to do >> this :) It would be an overkill to introduce new config option, I'm >> thinking a runtime parameter to check in an unlikely(), so it won't >> cause performance penalty for normal operation. Any opinions on >> that? > > One can always just have printk(KERN_DEBUG and if the user did not > boot with 'debug' the messages go to /dev/null. Checking through the unmap_ops array itself can take a considerable amount of cycles, I think it would be better to avoid that. Zoli