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=-6.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS 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 281E9C2D0D1 for ; Mon, 6 Jan 2020 10:38:23 +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 D32F62072E for ; Mon, 6 Jan 2020 10:38:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=daynix-com.20150623.gappssmtp.com header.i=@daynix-com.20150623.gappssmtp.com header.b="PK0ohHlk" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D32F62072E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=daynix.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:50360 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ioPmA-0006Fl-2u for qemu-devel@archiver.kernel.org; Mon, 06 Jan 2020 05:38:22 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:44132) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ioPlS-0005pH-AX for qemu-devel@nongnu.org; Mon, 06 Jan 2020 05:37:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ioPlQ-0000U3-Gk for qemu-devel@nongnu.org; Mon, 06 Jan 2020 05:37:38 -0500 Received: from mail-io1-xd41.google.com ([2607:f8b0:4864:20::d41]:43367) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ioPlQ-0000T6-2r for qemu-devel@nongnu.org; Mon, 06 Jan 2020 05:37:36 -0500 Received: by mail-io1-xd41.google.com with SMTP id n21so46536891ioo.10 for ; Mon, 06 Jan 2020 02:37:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daynix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kioC//NqP9XNmF4R0cNN0EdcSnlckdmgMPs0Vb2JKSo=; b=PK0ohHlk6G5wqJAzYsp5Db3dsMjuVLpjTGvIGlKogGKVl74CW37pW1RPhpxnROnFFN isECpZwu642TdvmZiGPsPEuFBmItLppIIcucPm/FfB7AzKieu+2k5BEu0pNurnJsLJeH WF4KjCUzN87JdPphEh5llqQ3KzJsxby6SM4QjS52ozDGhrC7/wG0hXBw1pBUChafHpoS PKbzDcwjbTbbRvMfFgW157UtLVc+nwIPL3zeerRxtwIkhN4+Cs8LsN9g4F0p8AdBa4Cy HmQXAe7yHjpq8YaID6znUl27/UVT4WVjcn/Tw7GcnSv+0zP5y4G98WD7MbZkH5x9MXST MHgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kioC//NqP9XNmF4R0cNN0EdcSnlckdmgMPs0Vb2JKSo=; b=Hw4Mu5RfmqCdHE5fyh02ZaGpLq86eY63fV7g1e0oI6c9xFa5dtrIKqcQNCMid6WwBP 6PWoJV1PZHZEN+5cLr4ZvzdTRKscewHjygNNNLJff+wmdyZzJCYqki2dr6tVDPKV55WH uoJJz/sDexCAjaHH/8hnjUqG+UL8rBXisQm4IC+1BFrsyBVgXEx1+IpTU9gUZVPO27nl 3X48aK9XigzZxxLO2rybNyeAfjRSiPqkK1SUGKzr5LJ4dalJCclI+pKSBpFA3zq110i+ dXsBfT8FMvVx7pBZ/BGiCuTtvbtkUSLbodxVnH8FxRrQR4+eCnw+TTQyLoT6BaftzzdI EazA== X-Gm-Message-State: APjAAAUjKW9muDxNQzPezlCenc82vvxtJEpDTxYeqSxJSpSBLV8E7kI0 XXjdPfKgvujEdJcUh000+/g24VYASa5Id7G9+/sb6w== X-Google-Smtp-Source: APXvYqwxCM5+YXGZ4Qt80gWfInCNKtpyqxcej1Ov9dpsnA1AhFz/joj1Dy1sEZdodJtdL3mwVmVkScjwvBprQTjvvtg= X-Received: by 2002:a6b:7119:: with SMTP id q25mr63294938iog.148.1578307055126; Mon, 06 Jan 2020 02:37:35 -0800 (PST) MIME-Version: 1.0 References: <20191226043649.14481-1-yuri.benditovich@daynix.com> <20191226043649.14481-2-yuri.benditovich@daynix.com> <05ead321-e93f-1b07-01cc-e0b023be8168@redhat.com> <20200101184425-mutt-send-email-mst@kernel.org> <20200105063518-mutt-send-email-mst@kernel.org> <20200106044351-mutt-send-email-mst@kernel.org> In-Reply-To: <20200106044351-mutt-send-email-mst@kernel.org> From: Yuri Benditovich Date: Mon, 6 Jan 2020 12:37:21 +0200 Message-ID: Subject: Re: [PATCH 1/2] virtio: reset region cache when on queue deletion To: "Michael S. Tsirkin" Content-Type: multipart/alternative; boundary="0000000000005e1ce7059b763f7a" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::d41 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: Yan Vugenfirer , pbonzini@redhat.com, Jason Wang , qemu-devel@nongnu.org Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --0000000000005e1ce7059b763f7a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 6, 2020 at 11:58 AM Michael S. Tsirkin wrote: > I guess it somehow has to do with the following: > > if (proxy->disable_legacy =3D=3D ON_OFF_AUTO_AUTO) { > proxy->disable_legacy =3D pcie_port ? ON_OFF_AUTO_ON : > ON_OFF_AUTO_OFF; > } > > so by default device on an express port does not have a legacy interface. > > Somehow having a legacy interface fixes things? > I'll check it. > Does enabling legacy on q35 without this patch fix things? > I'll check it also. > And does disabling legacy on PIIX without this patch break thing? > I'll check it also. > > How can having a legacy interface fix things if it's not > even active? I don't know. Is there a chance windows drivers use the > legacy interface on a transitional device by mistake? > > I'll recheck it. I do not think we use legacy interface on modern device even if it has one. > > On Mon, Jan 06, 2020 at 11:10:18AM +0200, Yuri Benditovich wrote: > > Michael, > > Can you please comment on Jason's question: why we have a problem only > with q35 > > and not with legacy pc? > > If you have a simple answer, it will help us in further work with other > hot > > plug/unplug problems. > > > > Thanks, > > Yuri Benditovich > > > > On Sun, Jan 5, 2020 at 6:21 PM Yuri Benditovich < > yuri.benditovich@daynix.com> > > wrote: > > > > > > > > On Sun, Jan 5, 2020 at 1:39 PM Michael S. Tsirkin > wrote: > > > > On Thu, Jan 02, 2020 at 09:09:04AM +0200, Yuri Benditovich wrot= e: > > > > > > > > > On Thu, Jan 2, 2020 at 1:50 AM Michael S. Tsirkin < > mst@redhat.com> > > wrote: > > > > > > On Thu, Dec 26, 2019 at 11:29:50AM +0200, Yuri Benditovic= h > wrote: > > > > On Thu, Dec 26, 2019 at 10:58 AM Jason Wang < > > jasowang@redhat.com> wrote: > > > > > > > > > > > > > > > On 2019/12/26 =E4=B8=8B=E5=8D=8812:36, Yuri Benditovi= ch wrote: > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=3D17084= 80 > > > > > > Fix leak of region reference that prevents complete > > > > > > device deletion on hot unplug. > > > > > > > > > > > > > > > More information is needed here, the bug said only q3= 5 > can > > meet this > > > > > issue. What makes q35 different here? > > > > > > > > > > > > > I do not have any ready answer, I did not dig into it > too much. > > > > Probably Michael Tsirkin or Paolo Bonzini can answer > without > > digging. > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Yuri Benditovich < > > yuri.benditovich@daynix.com> > > > > > > --- > > > > > > hw/virtio/virtio.c | 5 +++++ > > > > > > 1 file changed, 5 insertions(+) > > > > > > > > > > > > diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.= c > > > > > > index 04716b5f6c..baadec8abc 100644 > > > > > > --- a/hw/virtio/virtio.c > > > > > > +++ b/hw/virtio/virtio.c > > > > > > @@ -2340,6 +2340,11 @@ void > virtio_del_queue(VirtIODevice > > *vdev, int > > > n) > > > > > > vdev->vq[n].vring.num_default =3D 0; > > > > > > vdev->vq[n].handle_output =3D NULL; > > > > > > vdev->vq[n].handle_aio_output =3D NULL; > > > > > > + /* > > > > > > + * with vring.num =3D 0 the queue will be igno= red > > > > > > + * in later loops of region cache reset > > > > > > + */ > > > > > > > > > > > > > > > I can't get the meaning of this comment. > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > + > virtio_virtqueue_reset_region_cache(&vdev->vq[n]); > > > > > > > > > Do we need to drop this from virtio_device_free_virtqueue= s > then? > > > > > > > > > > > > Not mandatory. Repetitive > virtio_virtqueue_reset_region_cache does > > not do > > > anything bad. > > > Some of virtio devices do not do 'virtio_del_queue' at all. > > Currently > > > virtio_device_free_virtqueues resets region cache for them. > > > IMO, not calling 'virtio_del_queue' is a bug, but not in the > scope of > > current > > > series, I'll take care of that later. > > > > Maybe we should just del all queues in virtio_device_unrealize? > > Will allow us to drop some logic tracking which vqs were create= d. > > > > > > > > Yes, this is also possible with some rework of > > virtio_device_free_virtqueues. > > virtio-net has some additional operations around queue deletion, it > deletes > > queues when switches from single queue to multiple. > > > > > > > > > > > > > > > g_free(vdev->vq[n].used_elems); > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > --0000000000005e1ce7059b763f7a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Jan 6, 2020 at 11:58 AM Michael S= . Tsirkin <mst@redhat.com> wrot= e:
I guess it so= mehow has to do with the following:

=C2=A0 =C2=A0 if (proxy->disable_legacy =3D=3D ON_OFF_AUTO_AUTO) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 proxy->disable_legacy =3D pcie_port ? ON_OFF= _AUTO_ON : ON_OFF_AUTO_OFF;
=C2=A0 =C2=A0 }

so by default device on an express port does not have a legacy interface.
Somehow having a legacy interface fixes things?

I'll check it.
=C2=A0
Does enabling legacy on q35 without this patch fix things?
=

I'll check it also.
=C2=A0
And does disabling legacy on PIIX without this patch break thing?

I'll check it also.
=C2=A0

How can having a legacy interface fix things if it's not
even active? I don't know. Is there a chance windows drivers use the legacy interface on a transitional device by mistake?


I'll recheck it. I do not thi= nk we use legacy interface on modern device even if it has one.
<= /div>
=C2=A0

On Mon, Jan 06, 2020 at 11:10:18AM +0200, Yuri Benditovich wrote:
> Michael,
> Can you please comment on Jason's question: why we have a problem = only with q35
> and not with legacy pc?
> If you have a simple answer, it will help us in further work with othe= r hot
> plug/unplug problems.
>
> Thanks,
> Yuri Benditovich
>
> On Sun, Jan 5, 2020 at 6:21 PM Yuri Benditovich <yuri.benditovich@daynix.com<= /a>>
> wrote:
>
>
>
>=C2=A0 =C2=A0 =C2=A0On Sun, Jan 5, 2020 at 1:39 PM Michael S. Tsirkin &= lt;
mst@redhat.com&g= t; wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Thu, Jan 02, 2020 at 09:09:04AM +0= 200, Yuri Benditovich wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> On Thu, Jan 2, 2020 at 1:50 AM M= ichael S. Tsirkin <m= st@redhat.com>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0On Thu, Dec 2= 6, 2019 at 11:29:50AM +0200, Yuri Benditovich wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> On Thu, = Dec 26, 2019 at 10:58 AM Jason Wang <
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0jasowang@redhat.com> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > On = 2019/12/26 =E4=B8=8B=E5=8D=8812:36, Yuri Benditovich wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > >= ; https://bugzilla.redhat.com/show_bug.cgi?id= =3D1708480
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > >= ; Fix leak of region reference that prevents complete
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > >= ; device deletion on hot unplug.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > Mor= e information is needed here, the bug said only q35 can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0meet this
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > iss= ue. What makes q35 different here?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> I do not= have any ready answer, I did not dig into it too much.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Probably= Michael Tsirkin or Paolo Bonzini can answer without
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0digging.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > >= ;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > >= ; Signed-off-by: Yuri Benditovich <
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yuri.benditovich@daynix.com>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > >= ; ---
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > >= ;=C2=A0 =C2=A0hw/virtio/virtio.c | 5 +++++
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > >= ;=C2=A0 =C2=A01 file changed, 5 insertions(+)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > >= ;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > >= ; diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > >= ; index 04716b5f6c..baadec8abc 100644
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > >= ; --- a/hw/virtio/virtio.c
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > >= ; +++ b/hw/virtio/virtio.c
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > >= ; @@ -2340,6 +2340,11 @@ void virtio_del_queue(VirtIODevice
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*vdev, int
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0n)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > >= ;=C2=A0 =C2=A0 =C2=A0 =C2=A0vdev->vq[n].vring.num_default =3D 0;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > >= ;=C2=A0 =C2=A0 =C2=A0 =C2=A0vdev->vq[n].handle_output =3D NULL;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > >= ;=C2=A0 =C2=A0 =C2=A0 =C2=A0vdev->vq[n].handle_aio_output =3D NULL;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > >= ; +=C2=A0 =C2=A0 /*
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > >= ; +=C2=A0 =C2=A0 =C2=A0* with vring.num =3D 0 the queue will be ignored
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > >= ; +=C2=A0 =C2=A0 =C2=A0* in later loops of region cache reset
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > >= ; +=C2=A0 =C2=A0 =C2=A0*/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > I c= an't get the meaning of this comment.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > Tha= nks
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > >= ; +=C2=A0 =C2=A0 virtio_virtqueue_reset_region_cache(&vdev->vq[n]);<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Do we need to= drop this from virtio_device_free_virtqueues then?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Not mandatory. Repetitive=C2=A0 = virtio_virtqueue_reset_region_cache=C2=A0does
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0not do
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> anything bad.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Some of virtio devices do not do= 'virtio_del_queue' at all.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Currently=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> virtio_device_free_virtqueues re= sets region cache for them.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> IMO, not calling 'virtio_del= _queue' is a bug, but not in the scope of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0current
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> series, I'll take care of th= at later.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Maybe we should just del all queues i= n virtio_device_unrealize?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Will allow us to drop some logic trac= king which vqs were created.
>
>
>
>=C2=A0 =C2=A0 =C2=A0Yes, this is also possible with some rework of
>=C2=A0 =C2=A0 =C2=A0virtio_device_free_virtqueues.
>=C2=A0 =C2=A0 =C2=A0virtio-net has some additional operations around qu= eue deletion, it deletes
>=C2=A0 =C2=A0 =C2=A0queues when switches from single queue to multiple.=
>=C2=A0 =C2=A0 =C2=A0=C2=A0
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > >= ;=C2=A0 =C2=A0 =C2=A0 =C2=A0g_free(vdev->vq[n].used_elems);
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > >= ;=C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > >= ;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>
>

--0000000000005e1ce7059b763f7a--