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=-3.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 7BD5FC433E1 for ; Tue, 18 Aug 2020 09:06:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 58CAC206B5 for ; Tue, 18 Aug 2020 09:06:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="f1bSGFXc" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726605AbgHRJGo (ORCPT ); Tue, 18 Aug 2020 05:06:44 -0400 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:53789 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726473AbgHRJGo (ORCPT ); Tue, 18 Aug 2020 05:06:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1597741603; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7T9mpdruf8/QbUxmM0HKIFYsILTP2sJfo1DUZlpHsno=; b=f1bSGFXcw8iFqBoFMDZT7kmVP9X55zfYHd8+mqKOHEWCm8C3eEfIxNBs8CyS2Ft8EiduHr 6BztyuflYYYw39yPU8//G/dUGI6SNZz0aw8plW5ADhEUep17wg/u073stFNt0SKmvzjR2w K14LhMSt27XVeAGXG5vG5RCBAbCebpI= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-342-vpgG3SJYObuxw_q781AWlQ-1; Tue, 18 Aug 2020 05:06:41 -0400 X-MC-Unique: vpgG3SJYObuxw_q781AWlQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id EC45C81F02B; Tue, 18 Aug 2020 09:06:38 +0000 (UTC) Received: from gondolin (ovpn-112-221.ams2.redhat.com [10.36.112.221]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9ED7F5C716; Tue, 18 Aug 2020 09:06:19 +0000 (UTC) Date: Tue, 18 Aug 2020 11:06:17 +0200 From: Cornelia Huck To: "Daniel P. =?UTF-8?B?QmVycmFuZ8Op?=" Cc: Jason Wang , Yan Zhao , kvm@vger.kernel.org, libvir-list@redhat.com, qemu-devel@nongnu.org, kwankhede@nvidia.com, eauger@redhat.com, xin-ran.wang@intel.com, corbet@lwn.net, openstack-discuss@lists.openstack.org, shaohe.feng@intel.com, kevin.tian@intel.com, Parav Pandit , jian-feng.ding@intel.com, dgilbert@redhat.com, zhenyuw@linux.intel.com, hejie.xu@intel.com, bao.yumeng@zte.com.cn, Alex Williamson , eskultet@redhat.com, smooney@redhat.com, intel-gvt-dev@lists.freedesktop.org, Jiri Pirko , dinechin@redhat.com, devel@ovirt.org Subject: Re: device compatibility interface for live migration with assigned devices Message-ID: <20200818110617.05def37c.cohuck@redhat.com> In-Reply-To: <20200818085527.GB20215@redhat.com> References: <20200805021654.GB30485@joy-OptiPlex-7040> <2624b12f-3788-7e2b-2cb7-93534960bcb7@redhat.com> <20200805075647.GB2177@nanopsycho> <20200805093338.GC30485@joy-OptiPlex-7040> <20200805105319.GF2177@nanopsycho> <20200810074631.GA29059@joy-OptiPlex-7040> <20200814051601.GD15344@joy-OptiPlex-7040> <20200818085527.GB20215@redhat.com> Organization: Red Hat GmbH MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Tue, 18 Aug 2020 09:55:27 +0100 Daniel P. Berrang=C3=A9 wrote: > On Tue, Aug 18, 2020 at 11:24:30AM +0800, Jason Wang wrote: > > Another point, as we discussed in another thread, it's really hard to m= ake > > sure the above API work for all types of devices and frameworks. So hav= ing a > > vendor specific API looks much better. =20 >=20 > From the POV of userspace mgmt apps doing device compat checking / migrat= ion, > we certainly do NOT want to use different vendor specific APIs. We want to > have an API that can be used / controlled in a standard manner across ven= dors. As we certainly will need to have different things to check for different device types and vendor drivers, would it still be fine to have differing (say) attributes, as long as they are presented (and can be discovered) in a standardized way? (See e.g. what I came up with for vfio-ccw in a different branch of this thread.) E.g. version=3D .type_specific_value0=3D .type_specific_value1=3D .vendor_driver_specific_value0=3D with a type or vendor driver having some kind of get_supported_attributes method? 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=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 4A104C433DF for ; Tue, 18 Aug 2020 09:07:22 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (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 179EF206B5 for ; Tue, 18 Aug 2020 09:07:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="g6cTwlqN" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 179EF206B5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:38916 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k7xaT-0007TJ-BD for qemu-devel@archiver.kernel.org; Tue, 18 Aug 2020 05:07:21 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55244) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k7xZw-0006zA-Od for qemu-devel@nongnu.org; Tue, 18 Aug 2020 05:06:48 -0400 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:47463) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1k7xZu-0007KS-Ol for qemu-devel@nongnu.org; Tue, 18 Aug 2020 05:06:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1597741605; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7T9mpdruf8/QbUxmM0HKIFYsILTP2sJfo1DUZlpHsno=; b=g6cTwlqNzZerIo556oNEAycAKm5s/5yJ6osmW+pE1ppYEQMbCSIJFBSrODQW2Zt1KXRrR4 jr+z7Smypjl90H1uUpfT7g/9og2YhKZx0WiKiflEN4uZhBBLtfSt0DlOAcJLPhFynjXB94 2Zj5ryE8SHTlx8Uw4VjcX9juXvyMW/4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-342-vpgG3SJYObuxw_q781AWlQ-1; Tue, 18 Aug 2020 05:06:41 -0400 X-MC-Unique: vpgG3SJYObuxw_q781AWlQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id EC45C81F02B; Tue, 18 Aug 2020 09:06:38 +0000 (UTC) Received: from gondolin (ovpn-112-221.ams2.redhat.com [10.36.112.221]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9ED7F5C716; Tue, 18 Aug 2020 09:06:19 +0000 (UTC) Date: Tue, 18 Aug 2020 11:06:17 +0200 From: Cornelia Huck To: "Daniel P. =?UTF-8?B?QmVycmFuZ8Op?=" Subject: Re: device compatibility interface for live migration with assigned devices Message-ID: <20200818110617.05def37c.cohuck@redhat.com> In-Reply-To: <20200818085527.GB20215@redhat.com> References: <20200805021654.GB30485@joy-OptiPlex-7040> <2624b12f-3788-7e2b-2cb7-93534960bcb7@redhat.com> <20200805075647.GB2177@nanopsycho> <20200805093338.GC30485@joy-OptiPlex-7040> <20200805105319.GF2177@nanopsycho> <20200810074631.GA29059@joy-OptiPlex-7040> <20200814051601.GD15344@joy-OptiPlex-7040> <20200818085527.GB20215@redhat.com> Organization: Red Hat GmbH MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Received-SPF: none client-ip=63.128.21.124; envelope-from=cohuck@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/18 02:02:19 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -30 X-Spam_score: -3.1 X-Spam_bar: --- X-Spam_report: (-3.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-1, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kvm@vger.kernel.org, libvir-list@redhat.com, Jason Wang , qemu-devel@nongnu.org, kwankhede@nvidia.com, eauger@redhat.com, xin-ran.wang@intel.com, corbet@lwn.net, openstack-discuss@lists.openstack.org, shaohe.feng@intel.com, kevin.tian@intel.com, Yan Zhao , Parav Pandit , jian-feng.ding@intel.com, dgilbert@redhat.com, zhenyuw@linux.intel.com, hejie.xu@intel.com, bao.yumeng@zte.com.cn, Alex Williamson , smooney@redhat.com, intel-gvt-dev@lists.freedesktop.org, eskultet@redhat.com, Jiri Pirko , dinechin@redhat.com, devel@ovirt.org Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Tue, 18 Aug 2020 09:55:27 +0100 Daniel P. Berrang=C3=A9 wrote: > On Tue, Aug 18, 2020 at 11:24:30AM +0800, Jason Wang wrote: > > Another point, as we discussed in another thread, it's really hard to m= ake > > sure the above API work for all types of devices and frameworks. So hav= ing a > > vendor specific API looks much better. =20 >=20 > From the POV of userspace mgmt apps doing device compat checking / migrat= ion, > we certainly do NOT want to use different vendor specific APIs. We want to > have an API that can be used / controlled in a standard manner across ven= dors. As we certainly will need to have different things to check for different device types and vendor drivers, would it still be fine to have differing (say) attributes, as long as they are presented (and can be discovered) in a standardized way? (See e.g. what I came up with for vfio-ccw in a different branch of this thread.) E.g. version=3D .type_specific_value0=3D .type_specific_value1=3D .vendor_driver_specific_value0=3D with a type or vendor driver having some kind of get_supported_attributes method?