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=-5.0 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 3CAB2C433E1 for ; Tue, 18 Aug 2020 09:26:30 +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 079C320639 for ; Tue, 18 Aug 2020 09:26:29 +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="fFIS52Ns" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 079C320639 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]:51308 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k7xsz-0005UI-8d for qemu-devel@archiver.kernel.org; Tue, 18 Aug 2020 05:26:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59688) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k7xsB-0004ya-MN for qemu-devel@nongnu.org; Tue, 18 Aug 2020 05:25:39 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:30952) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1k7xs9-0001Bo-G9 for qemu-devel@nongnu.org; Tue, 18 Aug 2020 05:25:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1597742735; h=from:from:reply-to: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=eeB+hN1zCN47COQrIpjM7VIX4w9eY1mJ1G21fPz14lw=; b=fFIS52NsO+w7i22jSGk6gNpRufkazoCQkLr8VILA1XWVFsNUB8lLwoZqIxACYgJhpFAudV Kcnhz8XkgexY9XLo4ZqIGb330OxqNKidX4Ez4zaLuxXkZ4yhq9iZFy4NdIeDuCP7IhOh9f PBX3PR2a0UgO709O3SLGJmMPXe+G8Oc= 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-117-jjuG8ppIN9-XvLxq3nqeZA-1; Tue, 18 Aug 2020 05:24:54 -0400 X-MC-Unique: jjuG8ppIN9-XvLxq3nqeZA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C76231014DEE; Tue, 18 Aug 2020 09:24:51 +0000 (UTC) Received: from redhat.com (unknown [10.36.110.26]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0B5F82617B; Tue, 18 Aug 2020 09:24:35 +0000 (UTC) Date: Tue, 18 Aug 2020 10:24:33 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Cornelia Huck Subject: Re: device compatibility interface for live migration with assigned devices Message-ID: <20200818092433.GD20215@redhat.com> References: <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> <20200818110617.05def37c.cohuck@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200818110617.05def37c.cohuck@redhat.com> User-Agent: Mutt/1.14.5 (2020-06-23) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Received-SPF: none client-ip=216.205.24.124; envelope-from=berrange@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/18 03:22:11 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -40 X-Spam_score: -4.1 X-Spam_bar: ---- X-Spam_report: (-4.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, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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: , Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= 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, Aug 18, 2020 at 11:06:17AM +0200, Cornelia Huck wrote: > On Tue, 18 Aug 2020 09:55:27 +0100 > Daniel P. Berrangé 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 make > > > sure the above API work for all types of devices and frameworks. So having a > > > vendor specific API looks much better. > > > > From the POV of userspace mgmt apps doing device compat checking / migration, > > 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 vendors. > > 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? Yes, the control API and algorithm to deal with the problem needs to have standardization, but the data passed in/out of the APIs can vary. Essentially the key is that vendors should be able to create devices at the kernel, and those devices should "just work" with the existing generic userspace migration / compat checking code, without needing extra vendor specific logic to be added. Note, I'm not saying that the userspace decisions would be perfectly optimal based on generic code. They might be making a simplified decision that while functionally safe, is not the ideal solution. Adding vendor specific code might be able to optimize the userspace decisions, but that should be considered just optimization, not a core must have for any opertion. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|