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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 59F6BC46467 for ; Mon, 16 Jan 2023 08:19:55 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pHKhs-0000d1-5j; Mon, 16 Jan 2023 03:19:04 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pHKhp-0000co-1L for qemu-devel@nongnu.org; Mon, 16 Jan 2023 03:19:01 -0500 Received: from szxga02-in.huawei.com ([45.249.212.188]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pHKhl-0007KD-Ab for qemu-devel@nongnu.org; Mon, 16 Jan 2023 03:19:00 -0500 Received: from dggpeml500023.china.huawei.com (unknown [172.30.72.57]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4NwPy63vBRzJrYl; Mon, 16 Jan 2023 16:17:02 +0800 (CST) Received: from kwepemm600016.china.huawei.com (7.193.23.20) by dggpeml500023.china.huawei.com (7.185.36.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Mon, 16 Jan 2023 16:18:23 +0800 Received: from kwepemm600016.china.huawei.com ([7.193.23.20]) by kwepemm600016.china.huawei.com ([7.193.23.20]) with mapi id 15.01.2375.034; Mon, 16 Jan 2023 16:18:22 +0800 To: "Michael S. Tsirkin" , Stefan Hajnoczi , Peter Maydell CC: "qemu-devel@nongnu.org" , "Wubin (H)" , "Chentao (Boby)" , "Wanghaibin (D)" , "Zhangbo (Oscar)" , "limingwang (A)" , Wangyan , lihuachao Subject: [QUESTION] About virtio and eventloop Thread-Topic: [QUESTION] About virtio and eventloop Thread-Index: AdkpcTID0pd8MGv+T9eTVpvXILZMZQ== Date: Mon, 16 Jan 2023 08:18:22 +0000 Message-ID: <63b89ae069d644b897ea97cc41b030ab@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.174.187.224] Content-Type: multipart/alternative; boundary="_000_63b89ae069d644b897ea97cc41b030abhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Received-SPF: pass client-ip=45.249.212.188; envelope-from=zhukeqian1@huawei.com; helo=szxga02-in.huawei.com X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-to: zhukeqian From: zhukeqian via Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org --_000_63b89ae069d644b897ea97cc41b030abhuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all maintainers and community friends, Recently I am reviewing and learning the virtio and eventloop implementatio= n of latest QEMU, and now I have a questions for help: In general, the IO requests of virtio is popped in iothread/mainloop and ma= y submitted to "async IO Engine" (io_uring/linux aio/threadpool). Once the IO operation is done, th= e "async IO engine" will send notification to iothread/mainloop through evenfd or bottomhalf, and the completion actio= n for the IO request (add used ring and notify guest) is done in iothread/mainloop. And let's look at the "deactive" procedure of virtio-pci devices (when gues= t write 0 to device status or system triggered reset), the basic requirement is that device should stop handling= IO requests and accessing virtqueue before returning back to guest, as the guest may destroy virqueue once deactivati= on is done. QEMU invokes stop_ioeventfd() callback to perform above actions. It unregis= ters ioeventfd from eventloop and KVM, 1. but I can't find code that ensuring IO operations in "async IO engine= " are done. 2. And if IO operation is blocked, is vCPU thread will blocked when do d= eactivate? It's great that if anyone can help! Thanks, Keqian --_000_63b89ae069d644b897ea97cc41b030abhuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all maintainers and community friends,=

 

Recently I am reviewing and learning the virtio and = eventloop implementation of latest QEMU,

and now I have a questions for help:

 

In general, the IO requests of virtio is popped in i= othread/mainloop and may submitted to “async IO

Engine”  (io_uring/linux aio/threadpool).= Once the IO operation is done, the “async IO engine” will send= notification

to iothread/mainloop through evenfd or bottomhalf, a= nd the completion action for the IO request (add used ring and

notify guest) is done in iothread/mainloop.

 

And let’s look at the “deactive” p= rocedure of virtio-pci devices (when guest write 0 to  device status o= r system

triggered reset), the basic requirement is that devi= ce should stop handling IO requests and accessing virtqueue before

returning back to guest, as the guest may destroy vi= rqueue  once deactivation is done.

 

QEMU invokes stop_ioeventfd() callback to perform ab= ove actions. It unregisters ioeventfd from eventloop and KVM,

  1. but I can’t find code that ensuring IO operations in “async IO engine” are done.  =
  2. And if IO operation is blocked, is vCPU thread will = blocked when do deactivate?

 

It’s great that if anyone can help!=

 

Thanks,       &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             

Keqian

--_000_63b89ae069d644b897ea97cc41b030abhuaweicom_--