Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp986583yba; Thu, 9 May 2019 08:57:06 -0700 (PDT) X-Google-Smtp-Source: APXvYqxHuZKTJdtcTSpwTXU3qsd3ZrAD/V2GwiN7uxKCt2G2SYeTDbmTMh9yPub6xeP/MOkASGOt X-Received: by 2002:a62:6582:: with SMTP id z124mr6530844pfb.0.1557417426500; Thu, 09 May 2019 08:57:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557417426; cv=none; d=google.com; s=arc-20160816; b=0x/fPc9vcDY90NJkd9esvEEQ/lno92q0TSQvGCaAFH4X9Q/7wdLzrLcN8PfrVgZ4ci pg2PYHe7/vQ2KRtVI5w+ZHULNFXI96ALza8BsQHthEtnLN/AjFH9ULvlHQSzRAztXxaW hos/ambwUXXpeRZT+YDGg6psprj6GJX1iNLURxgYdguoCOSoS0PczNHdt49r3+A02Uzr 9tL9jdjOtH+kRFL5WP77crmWxYANlee+uxqUqkciwS2eNu3ueYM1pVRZhw5paXpT34Id yo5HpOA8QerDJ0DsaFkI9XqG+7yMvVuPLkF7/KRjLmL6H+LyDH8bHdSHbJUkrA6tviP3 8GoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=9nn9yEspi3wk26+v0cSOPUniVz6LW2eH7QZxKcO425Q=; b=eft45xc50TX0JfqeAG3jgRzGqSvJnoei0/03Mh0CNZsv9G9fNWOHyob1zB+zu6lNcv bNFDfYuj4eceTuFI5TZfZv4Y8g9JvmI857xpOR4OKMHAGv5J9iq6mTJKtFbA9k0HHslU VOgFmWwp4uiZ7Tly7mkt7CwC4VwkZb1vnKClXqM1eaSrT6SXivJ0BVczkGwEZRrmUCMk vuK7My6h59/dKOQPxeqI7fnPmbIBe30NMoDzzD3kUgnLxDIrWFll/lXMbQmdOEYOuAAR pRwOonhvpam9tTQdagYciClGyrbcDuwjvUDOakL6p4xJqXC7zzKAsZ+thUUbaFK6IIWI 1ZIg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m12si3164677pgv.586.2019.05.09.08.56.49; Thu, 09 May 2019 08:57:06 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726682AbfEIPye (ORCPT + 99 others); Thu, 9 May 2019 11:54:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37136 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726187AbfEIPye (ORCPT ); Thu, 9 May 2019 11:54:34 -0400 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 22D1599C1D; Thu, 9 May 2019 15:54:28 +0000 (UTC) Received: from gondolin (dhcp-192-213.str.redhat.com [10.33.192.213]) by smtp.corp.redhat.com (Postfix) with ESMTP id B360F1001E65; Thu, 9 May 2019 15:54:06 +0000 (UTC) Date: Thu, 9 May 2019 17:54:04 +0200 From: Cornelia Huck To: "Dr. David Alan Gilbert" Cc: Alex Williamson , Yan Zhao , intel-gvt-dev@lists.freedesktop.org, arei.gonglei@huawei.com, aik@ozlabs.ru, Zhengxiao.zx@alibaba-inc.com, shuangtai.tst@alibaba-inc.com, qemu-devel@nongnu.org, eauger@redhat.com, yi.l.liu@intel.com, ziye.yang@intel.com, mlevitsk@redhat.com, pasic@linux.ibm.com, felipe@nutanix.com, changpeng.liu@intel.com, Ken.Xue@amd.com, jonathan.davies@nutanix.com, shaopeng.he@intel.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, libvir-list@redhat.com, eskultet@redhat.com, kevin.tian@intel.com, zhenyuw@linux.intel.com, zhi.a.wang@intel.com, cjia@nvidia.com, kwankhede@nvidia.com, berrange@redhat.com, dinechin@redhat.com Subject: Re: [PATCH v2 1/2] vfio/mdev: add version attribute for mdev device Message-ID: <20190509175404.512ae7aa.cohuck@redhat.com> In-Reply-To: <20190509154857.GF2868@work-vm> References: <20190506014514.3555-1-yan.y.zhao@intel.com> <20190506014904.3621-1-yan.y.zhao@intel.com> <20190507151826.502be009@x1.home> <20190509173839.2b9b2b46.cohuck@redhat.com> <20190509154857.GF2868@work-vm> Organization: Red Hat GmbH MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 09 May 2019 15:54:33 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 9 May 2019 16:48:57 +0100 "Dr. David Alan Gilbert" wrote: > * Cornelia Huck (cohuck@redhat.com) wrote: > > On Tue, 7 May 2019 15:18:26 -0600 > > Alex Williamson wrote: > > > > > On Sun, 5 May 2019 21:49:04 -0400 > > > Yan Zhao wrote: > > > > > > + Errno: > > > > + If vendor driver wants to claim a mdev device incompatible to all other mdev > > > > + devices, it should not register version attribute for this mdev device. But if > > > > + a vendor driver has already registered version attribute and it wants to claim > > > > + a mdev device incompatible to all other mdev devices, it needs to return > > > > + -ENODEV on access to this mdev device's version attribute. > > > > + If a mdev device is only incompatible to certain mdev devices, write of > > > > + incompatible mdev devices's version strings to its version attribute should > > > > + return -EINVAL; > > > > > > I think it's best not to define the specific errno returned for a > > > specific situation, let the vendor driver decide, userspace simply > > > needs to know that an errno on read indicates the device does not > > > support migration version comparison and that an errno on write > > > indicates the devices are incompatible or the target doesn't support > > > migration versions. > > > > I think I have to disagree here: It's probably valuable to have an > > agreed error for 'cannot migrate at all' vs 'cannot migrate between > > those two particular devices'. Userspace might want to do different > > things (e.g. trying with different device pairs). > > Trying to stuff these things down an errno seems a bad idea; we can't > get much information that way. So, what would be a reasonable approach? Userspace should first read the version attributes on both devices (to find out whether migration is supported at all), and only then figure out via writing whether they are compatible? (Or just go ahead and try, if it does not care about the reason.)