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.5 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 1B1F3C2D0A3 for ; Thu, 12 Nov 2020 15:27:38 +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 7900520A8B for ; Thu, 12 Nov 2020 15:27:37 +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="AQspDKTM" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7900520A8B 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]:39042 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kdEVc-00059X-Bj for qemu-devel@archiver.kernel.org; Thu, 12 Nov 2020 10:27:36 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:53756) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kdEV1-0004bf-40 for qemu-devel@nongnu.org; Thu, 12 Nov 2020 10:26:59 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:55829) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1kdEUz-0004Hh-Al for qemu-devel@nongnu.org; Thu, 12 Nov 2020 10:26:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1605194816; 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=YqZGJ1O856sik/5Eu4CLdJLS9iwG0y81oo1dB6lhaQg=; b=AQspDKTMVXjbG45aHAWK+7r/DSFatOL6SjWSnK9kvR4DqHNXxpQ3/dtVSTMSPuuVZ89IGu mhtkXzqGErl7NEDBqxYn8NUpM90Ju/iC+r2fmixr/dRTmE/PZIXrI+qQe1GTkMw2nXxwUw lWnsuRGoDMfmoKw6rK0WziYQiyRnthE= 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-345-T9OpRehtOleQziVtrAzp1g-1; Thu, 12 Nov 2020 10:26:54 -0500 X-MC-Unique: T9OpRehtOleQziVtrAzp1g-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 2E882107B26B; Thu, 12 Nov 2020 15:26:53 +0000 (UTC) Received: from gondolin (ovpn-113-69.ams2.redhat.com [10.36.113.69]) by smtp.corp.redhat.com (Postfix) with ESMTP id D142955765; Thu, 12 Nov 2020 15:26:36 +0000 (UTC) Date: Thu, 12 Nov 2020 16:26:33 +0100 From: Cornelia Huck To: "Daniel P. =?UTF-8?B?QmVycmFuZ8Op?=" Subject: Re: [RFC v3] VFIO Migration Message-ID: <20201112162633.67a5d8a6.cohuck@redhat.com> In-Reply-To: <20201111154850.GG906488@redhat.com> References: <20201110095349.GA1082456@stefanha-x1.localdomain> <64fb6a41-fbfa-994c-9619-4df41ac97fde@redhat.com> <20201111143615.GA1421166@stefanha-x1.localdomain> <20201111154850.GG906488@redhat.com> Organization: Red Hat GmbH MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=cohuck@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=216.205.24.124; envelope-from=cohuck@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/12 08:00:44 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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: John G Johnson , "Tian, Kevin" , mtsirkin@redhat.com, Yan Zhao , quintela@redhat.com, Jason Wang , "Zeng, Xin" , qemu-devel@nongnu.org, "Dr. David Alan Gilbert" , Kirti Wankhede , Thanos Makatos , Alex Williamson , Gerd Hoffmann , Stefan Hajnoczi , Felipe Franciosi , Christophe de Dinechin , Paolo Bonzini Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Wed, 11 Nov 2020 15:48:50 +0000 Daniel P. Berrang=C3=A9 wrote: > In terms of validation I can't help but feel the whole proposal is > really very complicated. >=20 > In validating QEMU migration compatibility we merely compare the > versioned machine type. >=20 > IIUC, in this proposal, it would be more like exploding the machine > type into all its 100's of properties and then comparing each one > individually. >=20 > I really prefer the simpler model of QEMU versioned machine types > where compatibility is a simple string comparison, hiding the > 100's of individual config parameters. =20 >=20 > Of course there are scenarios where this will lead a mgmt app to > refuse a migration, when it could in fact have permitted it. >=20 > eg consider pc-i440fx-4.0 and pc-i440fx-5.0 machine types, > which only differ in the value "foo=3D7" and "foo=3D8" respectively. >=20 > Now if the target only supported machine type pc-i440fx-5.0, then > with a basic string comparison of machine type versin, we can't > migrate from a host uing pc-i440fx-4.0 >=20 > If we exploded the machine type into its params, we could see that > we can migrate from pc-i440fx-4.0 to pc-i440fx-5.0, simply by > overriding the value of "foo". >=20 > So, yes, dealing with individual params is more flexible, but it > comes at an enourmous cost in complexity to process all the > parameters. I'm not convinced this is a good tradeoff.=20 For mdev devices, we could have something similar to versioned machine types by introducing versioned mdev types. (Which would fit well with mdev types having to match strictly for migration to be possible.) For other use cases, we would need to introduce a new construct.