From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6DF7FC433E1 for ; Thu, 28 May 2020 16:00:58 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3F2812071A for ; Thu, 28 May 2020 16:00:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=xen.org header.i=@xen.org header.b="VM3EVXMJ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3F2812071A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=xen.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jeKxG-0006uu-IA; Thu, 28 May 2020 16:00:26 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jeKxF-0006up-2c for xen-devel@lists.xenproject.org; Thu, 28 May 2020 16:00:25 +0000 X-Inumbo-ID: 56b86458-a0fc-11ea-a7fe-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 56b86458-a0fc-11ea-a7fe-12813bfff9fa; Thu, 28 May 2020 16:00:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=In-Reply-To:Content-Transfer-Encoding:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=jeBFJd2UNVo6GKio2LfOs9T6os+j2HtTsJirjHMMsvw=; b=VM3EVXMJRkn+n0wyplatkbnr9d 4FHQbkXCMmoz3X8A6niIWc0CSa1Ibmv1OTmTcWKXBFQF5VK+WD7dy8dStMkoSWRazsweertG2W820 feSXerwfvEfBpjr7b6ZX57QvP8nWN+gb0JNpKvjSL71wEYMdi3as8C2nXle0ytDhjoxA=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jeKxC-00080W-WD; Thu, 28 May 2020 16:00:23 +0000 Received: from [93.176.191.173] (helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jeKxC-0007ml-LX; Thu, 28 May 2020 16:00:22 +0000 Date: Thu, 28 May 2020 18:00:15 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Andrew Cooper Subject: Re: [PATCH] x86/hvm: Improve error information in handle_pio() Message-ID: <20200528160003.GG1195@Air-de-Roger> References: <20200528130738.12816-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200528130738.12816-1-andrew.cooper3@citrix.com> X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Paul Durrant , Wei Liu , Jan Beulich , Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, May 28, 2020 at 02:07:38PM +0100, Andrew Cooper wrote: > domain_crash() should always have a message which emitted even in release > builds, so something more useful than this is presented. > > (XEN) domain_crash called from io.c:171 > (XEN) domain_crash called from io.c:171 > (XEN) domain_crash called from io.c:171 > ... > > Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné > --- > CC: Jan Beulich > CC: Wei Liu > CC: Roger Pau Monné > CC: Paul Durrant > CC: Marek Marczykowski-Górecki > > Part of a bug reported by Marek. Something else is wonky in the IO emulation > state, and preventing us from yielding to the scheduler so the domain can > progress with being shut down. > --- > xen/arch/x86/hvm/io.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c > index a5b0a23f06..4e468bfb6b 100644 > --- a/xen/arch/x86/hvm/io.c > +++ b/xen/arch/x86/hvm/io.c > @@ -167,7 +167,9 @@ bool handle_pio(uint16_t port, unsigned int size, int dir) > break; > > default: > - gdprintk(XENLOG_ERR, "Weird HVM ioemulation status %d.\n", rc); > + gprintk(XENLOG_ERR, "Unexpected PIO status %d, port %#x %s 0x%0*lx\n", > + rc, port, dir == IOREQ_WRITE ? "write" : "read", > + size * 2, data & ((1ul << (size * 8)) - 1)); I wonder, should data be initialized to 0 in order to prevent writing garbage here if the buffer is not filled in the read case? Note sure it's better to print garbage or just 0 in that case, as in both cases it won't be possible to figure out if it's real data or just the emulation didn't get to fill it (unless the specific error path is checked). Thanks, Roger.