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 92269C433EF for ; Fri, 3 Sep 2021 16:14:36 +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 10983610CF for ; Fri, 3 Sep 2021 16:14:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 10983610CF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=nongnu.org Received: from localhost ([::1]:45790 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mMBpp-0000LI-Tz for qemu-devel@archiver.kernel.org; Fri, 03 Sep 2021 12:14:34 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59634) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mMBet-0007Bu-N4 for qemu-devel@nongnu.org; Fri, 03 Sep 2021 12:03:15 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:54082) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mMBep-0006Q2-A5 for qemu-devel@nongnu.org; Fri, 03 Sep 2021 12:03:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1630684990; 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: in-reply-to:in-reply-to:references:references; bh=nfl5cANcb13xzAB4QtzWnMS9ZhzuUogRQzvHhQGjLV0=; b=Cdts5owLvs9wKSSYsSrHyB6QlO16VK73vPBsz5JvVhdcav82nhLY+VbaJcw70Ol/oLFqQS 0vS9MU83Js5hdoVR3qtpVjVv9638MYRjIOY3q4ls1uT7yf0uIDAXG8BvzPcwNdJMinzNdT uB9WMdwvFeySszprNti05AwE00H3gXY= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-504-RPJAEw40M1mRE_ppEbW5rA-1; Fri, 03 Sep 2021 12:03:09 -0400 X-MC-Unique: RPJAEw40M1mRE_ppEbW5rA-1 Received: by mail-qv1-f71.google.com with SMTP id b8-20020a0562141148b02902f1474ce8b7so6098575qvt.20 for ; Fri, 03 Sep 2021 09:03:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=nfl5cANcb13xzAB4QtzWnMS9ZhzuUogRQzvHhQGjLV0=; b=WrljDqG+Sz1YIYI0wJzE1u2i5RWMyfPdYf9jTO7LNydZYZcgdg3ynj5egrULwfdFDm wnGg7/6dE/MjdGYx1XC3a2LPf2kp4Kj1aG6hrJC18ykN0tCxrUHw0Lc0XLF//q4ThOj5 iHwSTuINiNiZurheJGyTjmHx8a1x+3la6Y0QlBOTxm0Pe/AhkGwIc6ZV35SGt2V2IcIF cIgl2pO+B05FWDq18kjlh/iHBZcLhfLuEFFSZUl4ByXDtT9ssMVzUs1gcZY5PVhqdHey XvBn63OAqvbT24HRoOGlZiCx5gJume96ieQwhYrTND9+s4U40H7L3wXzpuhfqIAj5tkn XMgQ== X-Gm-Message-State: AOAM533ZDPM5AU1JcO7H3CdpPlqvSWGaYePfMb3NMZ3oSAydCKt2oxPq h3bG7HWu0oArAOz4qPAw9v3E1EnRtaExk14WTbeVJFXCzBt46dOE6ehbQaJ2iZITsENH5gf/rUX J3a6e4m0PIKCIbbA= X-Received: by 2002:a0c:cb03:: with SMTP id o3mr4455911qvk.36.1630684989015; Fri, 03 Sep 2021 09:03:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwTS1XPHK2w6+XjLrjRtqiYS7bKAawOirh1IO664j6ZfDNFJYPkG9VRUzajU62ApSa92vTNVg== X-Received: by 2002:a0c:cb03:: with SMTP id o3mr4455891qvk.36.1630684988792; Fri, 03 Sep 2021 09:03:08 -0700 (PDT) Received: from t490s ([2607:fea8:56a3:500::ad7f]) by smtp.gmail.com with ESMTPSA id o7sm3254413qtw.87.2021.09.03.09.03.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Sep 2021 09:03:08 -0700 (PDT) Date: Fri, 3 Sep 2021 12:03:06 -0400 From: Peter Xu To: Igor Mammedov Subject: Re: [PATCH 4/4] vl: Prioritize realizations of devices Message-ID: References: <87h7fdg12w.fsf@dusky.pond.sub.org> <87y28oy6rm.fsf@dusky.pond.sub.org> <20210826133629.2ddd3b88@redhat.com> <20210902102616.1b596104@redhat.com> <20210903150005.58afaf10@redhat.com> MIME-Version: 1.0 In-Reply-To: <20210903150005.58afaf10@redhat.com> Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=peterx@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Received-SPF: pass client-ip=170.10.133.124; envelope-from=peterx@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -31 X-Spam_score: -3.2 X-Spam_bar: --- X-Spam_report: (-3.2 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.392, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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: Daniel P =?utf-8?B?LiBCZXJyYW5nw6k=?= , Eduardo Habkost , "Michael S . Tsirkin" , Jason Wang , qemu-devel@nongnu.org, Markus Armbruster , Eric Auger , Alex Williamson , Paolo Bonzini , "Dr . David Alan Gilbert" Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Fri, Sep 03, 2021 at 03:00:05PM +0200, Igor Mammedov wrote: > PS: > Another, albeit machine depended approach to resolve IOMMU ordering problem > can be adding to a specific machine pre_plug hook, an IOMMU handling. > Which is called during IOMMU realize time and check if existing buses > without bypass enabled (iommu managed) have any children. And if they > have devices attached, error out telling user to reorder '-device iommu' > before affected devices/bus. > It should cover mixed IOMMU+bypass case and doesn't require fixing > vfio-pci address space initialization nor defining any priorities > for PCI devices. This sounds appealing among the approaches. Does it need to be a pre_plug hook? I thought we might just need a flag in the pci device classes showing that it should be after vIOMMUs, then in vIOMMU realize functions we walk pci bus to make sure no such device exist? We could have a base vIOMMU class, then that could be in the realize() of the common class. > > (but I think it's more a hack compared earlier suggested > address space initialization at reset time, and it would need to be > done for every affected machine) Agreed. -- Peter Xu