From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756032AbdDEWTW (ORCPT ); Wed, 5 Apr 2017 18:19:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38290 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750825AbdDEWTO (ORCPT ); Wed, 5 Apr 2017 18:19:14 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com ECD01EEF20 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=alex.williamson@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com ECD01EEF20 Date: Wed, 5 Apr 2017 16:19:10 -0600 From: Alex Williamson To: "Michael S. Tsirkin" Cc: Cao jin , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, qemu-devel@nongnu.org, izumi.taku@jp.fujitsu.com Subject: Re: [PATCH v6] vfio error recovery: kernel support Message-ID: <20170405161910.26fee7d1@t450s.home> In-Reply-To: <20170406004845-mutt-send-email-mst@kernel.org> References: <1490260051-6046-1-git-send-email-caoj.fnst@cn.fujitsu.com> <20170324161238.366ce6a7@t450s.home> <58DA6954.2000601@cn.fujitsu.com> <20170328101233.74f50a92@t450s.home> <20170329000148.GA18849@redhat.com> <20170328205513.21b97381@t450s.home> <20170330205823-mutt-send-email-mst@kernel.org> <20170330121652.2ac8fa62@t450s.home> <58E4B0C9.50109@cn.fujitsu.com> <20170405133822.76cda620@t450s.home> <20170406004845-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Wed, 05 Apr 2017 22:19:14 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 6 Apr 2017 00:50:22 +0300 "Michael S. Tsirkin" wrote: > On Wed, Apr 05, 2017 at 01:38:22PM -0600, Alex Williamson wrote: > > The previous intention of trying to handle all sorts of AER faults > > clearly had more value, though even there the implementation and > > configuration requirements restricted the practicality. For instance > > is AER support actually useful to a customer if it requires all ports > > of a multifunction device assigned to the VM? This seems more like a > > feature targeting whole system partitioning rather than general VM > > device assignment use cases. Maybe that's ok, but it should be a clear > > design decision. > > Alex, what kind of testing do you expect to be necessary? > Would you say testing on real hardware and making it trigger > AER errors is a requirement? Testing various fatal, non-fatal, and corrected errors with aer-inject, especially in multfunction configurations (where more than one port is actually usable) would certainly be required. If we have cases where the driver for a companion function can escalate a non-fatal error to a bus reset, that should be tested, even if it requires temporary hacks to the host driver for the companion function to trigger that case. AER handling is not something that the typical user is going to experience, so it should to be thoroughly tested to make sure it works when needed or there's little point to doing it at all. Thanks, Alex