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=-8.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham 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 2830FC433E2 for ; Fri, 4 Sep 2020 02:46:37 +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 D4663206B7 for ; Fri, 4 Sep 2020 02:46:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="d+JJ6HvL" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D4663206B7 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]:44802 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kE1kJ-00009I-Tw for qemu-devel@archiver.kernel.org; Thu, 03 Sep 2020 22:46:35 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44348) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kE1jL-00082h-DP for qemu-devel@nongnu.org; Thu, 03 Sep 2020 22:45:35 -0400 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:47495) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1kE1jH-0000i6-RQ for qemu-devel@nongnu.org; Thu, 03 Sep 2020 22:45:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1599187529; 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=Y/8HaoGKswsbKahWY+edg6GphdVhXum5MOzh6CpUhds=; b=d+JJ6HvLNRu6cbaDocwt6WJqysUSt97mZzqeBHPcbzZVJdttVO77akpCzuRoTPHPmmP8DA xV2GHzOomomBu4apajWd9TS0Wgg9kSR3uqNBJ3e8YgJzzO6Hoh0GMFvARthJCXT4FtRJO3 hheo2+bm4OFahT5y7whBpD73/9GqkTY= 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-436-dpA9qz0kNnmokx2XgDsCTQ-1; Thu, 03 Sep 2020 22:45:25 -0400 X-MC-Unique: dpA9qz0kNnmokx2XgDsCTQ-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 7009381F004; Fri, 4 Sep 2020 02:45:24 +0000 (UTC) Received: from [10.72.13.157] (ovpn-13-157.pek2.redhat.com [10.72.13.157]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0316881190; Fri, 4 Sep 2020 02:45:14 +0000 (UTC) Subject: Re: [RFC 0/3] try to solve the DMA to MMIO issue To: Peter Maydell , Li Qiang References: <20200902162206.101872-1-liq3ea@163.com> From: Jason Wang Message-ID: Date: Fri, 4 Sep 2020 10:45:13 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=jasowang@redhat.com X-Mimecast-Spam-Score: 0.001 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Received-SPF: pass client-ip=63.128.21.124; envelope-from=jasowang@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/03 22:45:29 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -44 X-Spam_score: -4.5 X-Spam_bar: ---- X-Spam_report: (-4.5 / 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, NICE_REPLY_A=-2.403, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=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: Dmitry Fleytman , "Michael S. Tsirkin" , Li Qiang , QEMU Developers , Alexander Bulekov , Gerd Hoffmann , Paolo Bonzini Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On 2020/9/3 下午7:19, Peter Maydell wrote: > On Thu, 3 Sep 2020 at 12:11, Li Qiang wrote: >> Peter Maydell 于2020年9月3日周四 下午6:53写道： >>> On Thu, 3 Sep 2020 at 04:55, Jason Wang wrote: >>>> I think we still need to seek a way to address this issue completely. >>>> >>>> How about adding a flag in MemoryRegionOps and detect the reentrancy >>>> through that flag? >>> This won't catch everything. Consider this situation: >>> Device A makes DMA access to device B >>> Device B's write-handling causes it to raise an >>> outbound qemu_irq signal >>> The qemu_irq signal is connected to device A >> Here mean device A is an interrupt controller? > No. Any device can have an inbound or outbound qemu_irq line. > We use them not just for actual IRQ lines but for any > situation where we need to pass an on-or-off signal from > one device to another. > >> This is special case I think. > It's an example of why looking purely at MMIO is not > sufficient. We should prefer to see if we can come up with > a design principle that works for all between-device > coordination before we implement something that is specific > to MMIO. As discussed, maybe we can track the pending operations in device itself and check it in all the possible entry of device codes (irq, MMIO or what ever else). This may be easier for stable backport. Thanks > > thanks > -- PMM >