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.xenproject.org (lists.xenproject.org [192.237.175.120]) (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 66F69EB64D7 for ; Wed, 21 Jun 2023 08:40:21 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.552542.862677 (Exim 4.92) (envelope-from ) id 1qBtNZ-0001sH-Cn; Wed, 21 Jun 2023 08:39:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 552542.862677; Wed, 21 Jun 2023 08:39:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qBtNZ-0001sA-A7; Wed, 21 Jun 2023 08:39:53 +0000 Received: by outflank-mailman (input) for mailman id 552542; Wed, 21 Jun 2023 08:39:52 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qBtNY-0001s2-3B for xen-devel@lists.xenproject.org; Wed, 21 Jun 2023 08:39:52 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 2f09f1ac-100f-11ee-b236-6b7b168915f2; Wed, 21 Jun 2023 10:39:50 +0200 (CEST) Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-643-nOT0jC-nMhCavQXxm-kAig-1; Wed, 21 Jun 2023 04:39:43 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id DCD4C280BC88; Wed, 21 Jun 2023 08:39:42 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.126]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5C9DD4087C6D; Wed, 21 Jun 2023 08:39:42 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 1AF931800381; Wed, 21 Jun 2023 10:39:41 +0200 (CEST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2f09f1ac-100f-11ee-b236-6b7b168915f2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1687336789; 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=OinvM39eNcyuqTY4ayH3U9HRb8PC8b84eJfHXMZWEzo=; b=JFC/cGq8K8QSYa8ZXU8JfLtbyt0HS3Qwixl0/YMRXneD/E3JoA69A05icozCOSoTUmXac6 hz4SS+aUueJAqvR4vWQ1sNA7Xud2rF0saaDH6Sh7Sn4M+3TGmYyEJ24ptmP5XD0+dSd1sw 2c/7BES4zLqkYDBh6m5fH59DOPa13iU= X-MC-Unique: nOT0jC-nMhCavQXxm-kAig-1 Date: Wed, 21 Jun 2023 10:39:41 +0200 From: Gerd Hoffmann To: Robert Beckett Cc: "Chen, Jiqian" , =?utf-8?Q?Marc-Andr=C3=A9?= Lureau , Damien Hedde , "Michael S . Tsirkin" , Stefano Stabellini , Anthony PERARD , Roger Pau =?utf-8?B?TW9ubsOp?= , Jan Beulich , "Dr . David Alan Gilbert" , "qemu-devel@nongnu.org" , "xen-devel@lists.xenproject.org" , "Deucher, Alexander" , "Koenig, Christian" , "Hildebrand, Stewart" , Xenia Ragiadakou , "Huang, Honglei1" , "Zhang, Julia" , "Huang, Ray" Subject: Re: [QEMU PATCH 1/1] virtgpu: do not destroy resources when guest suspend Message-ID: <2s33vb2tfogntkyk5laxzcmgexf42mhkpwr2gh3gjvpitav6ez@h5zbmuklzmv5> References: <20230608025655.1674357-1-Jiqian.Chen@amd.com> <20230608025655.1674357-2-Jiqian.Chen@amd.com> <2164ff79-aa09-d959-cc61-c7a2a21db5e3@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2164ff79-aa09-d959-cc61-c7a2a21db5e3@collabora.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 On Tue, Jun 20, 2023 at 01:26:15PM +0100, Robert Beckett wrote: > > On 20/06/2023 10:41, Gerd Hoffmann wrote: > > Hi, > > > > > > The guest driver should be able to restore resources after resume. > > > Thank you for your suggestion! > > > As far as I know, resources are created on host side and guest has no backup, if resources are destroyed, guest can't restore them. > > > Or do you mean guest driver need to send commands to re-create resources after resume? > > The later. The guest driver knows which resources it has created, > > it can restore them after suspend. > > Are you sure that this is viable? > > How would you propose that a guest kernel could reproduce a resource, > including pixel data upload during a resume? > > The kernel would not have any of the pixel data to transfer to host. Depends on the of resource type. For resources which are created by uploading pixel data (using VIRTIO_GPU_CMD_TRANSFER_TO_HOST_*) a guest mirror exists which can be used for re-upload. For resources filled by gl rendering ops this is indeed not the case. > Could you explain how you anticipate the guest being able to reproduce the > resources please? Same you do on physical hardware? Suspend can poweroff your PCI devices, so there must be some standard way to handle that situation for resources stored in gpu device memory, which is very similar to the problem we have here. take care, Gerd