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=-2.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 7E929C5DF60 for ; Thu, 7 Nov 2019 06:48:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 40F6821882 for ; Thu, 7 Nov 2019 06:48:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="ZteAsuAv" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726467AbfKGGsb (ORCPT ); Thu, 7 Nov 2019 01:48:31 -0500 Received: from us-smtp-2.mimecast.com ([205.139.110.61]:43228 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725763AbfKGGsb (ORCPT ); Thu, 7 Nov 2019 01:48:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573109310; 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=CN2ulGtul0X2pd3Lw/bT87JsQKQsHK/UR87J4cDQl/k=; b=ZteAsuAvkH7Tjja8RIMyJS50GVUYcDYaPcgcEgqHwQN3ENuEcORALC7V6TqCFFKTzZwBVk 9d4MTiIc5lm1Beuhgz8z176Q0LpkYZlKQQ1oKVJHQNcmT6vcxLDI2o3zKMTCIL1baceeM8 CxV2B7Y4lCUYTgG44xf8fczvMoVWIPU= 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-280-0cipqxXqMOu9hvOV8Hxp6w-1; Thu, 07 Nov 2019 01:48:23 -0500 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 057661800D6B; Thu, 7 Nov 2019 06:48:21 +0000 (UTC) Received: from sirius.home.kraxel.org (ovpn-116-69.ams2.redhat.com [10.36.116.69]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3FE6C1A7E2; Thu, 7 Nov 2019 06:48:19 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 0397416E08; Thu, 7 Nov 2019 07:48:18 +0100 (CET) Date: Thu, 7 Nov 2019 07:48:17 +0100 From: Gerd Hoffmann To: Geoffrey McRae Cc: David Stevens , Keiichi Watanabe , Tomasz Figa , Dmitry Morozov , Alexandre Courbot , Alex Lau , Dylan Reid , =?utf-8?B?U3TDqXBoYW5l?= Marchesin , Pawel Osciak , Hans Verkuil , Daniel Vetter , Gurchetan Singh , Linux Media Mailing List , virtio-dev@lists.oasis-open.org, qemu-devel@nongnu.org Subject: Re: guest / host buffer sharing ... Message-ID: <20191107064817.j3sfzl6viea4qigc@sirius.home.kraxel.org> References: <20191105105456.7xbhtistnbp272lj@sirius.home.kraxel.org> <20191106124101.fsfxibdkypo4rswv@sirius.home.kraxel.org> <72712fe048af1489368f7416faa92c45@hostfission.com> MIME-Version: 1.0 In-Reply-To: <72712fe048af1489368f7416faa92c45@hostfission.com> User-Agent: NeoMutt/20180716 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-MC-Unique: 0cipqxXqMOu9hvOV8Hxp6w-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org > On 2019-11-06 23:41, Gerd Hoffmann wrote: > > On Wed, Nov 06, 2019 at 05:36:22PM +0900, David Stevens wrote: > > > > (1) The virtio device > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > Has a single virtio queue, so the guest can send commands to regist= er > > > > and unregister buffers. Buffers are allocated in guest ram. Each = buffer > > > > has a list of memory ranges for the data. Each buffer also has some > > >=20 > > > Allocating from guest ram would work most of the time, but I think > > > it's insufficient for many use cases. It doesn't really support thing= s > > > such as contiguous allocations, allocations from carveouts or <4GB, > > > protected buffers, etc. > >=20 > > If there are additional constrains (due to gpu hardware I guess) > > I think it is better to leave the buffer allocation to virtio-gpu. >=20 > The entire point of this for our purposes is due to the fact that we can > not allocate the buffer, it's either provided by the GPU driver or > DirectX. If virtio-gpu were to allocate the buffer we might as well forge= t > all this and continue using the ivshmem device. Well, virtio-gpu resources are in guest ram, like the buffers of a virtio-buffers device would be. So it isn't much of a difference. If the buffer provided by the (nvidia/amd/intel) gpu driver lives in ram you can create a virtio-gpu resource for it. On the linux side that is typically handled with dma-buf, one driver exports the dma-buf and the other imports it. virtio-gpu doesn't support that fully yet though (import is being worked on, export is done and will land upstream in the next merge window). No clue how this looks like for windows guests ... > Currently IVSHMEM is used by two projects that I am aware of, Looking > Glass and SCREAM. While Looking Glass is solving a problem that is out of > scope for QEMU, SCREAM is working around the audio problems in QEMU that > have been present for years now. Side note: sound in qemu 3.1+ should be alot better than in 2.x versions. cheers, Gerd 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=-2.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 E64B7C5DF61 for ; Thu, 7 Nov 2019 06:49:21 +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 AF39321882 for ; Thu, 7 Nov 2019 06:49:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="ZteAsuAv" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AF39321882 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]:39312 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iSbbc-0007to-Oy for qemu-devel@archiver.kernel.org; Thu, 07 Nov 2019 01:49:20 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:40116) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iSbas-0007Sg-5r for qemu-devel@nongnu.org; Thu, 07 Nov 2019 01:48:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iSbap-0007Xu-OV for qemu-devel@nongnu.org; Thu, 07 Nov 2019 01:48:32 -0500 Received: from us-smtp-2.mimecast.com ([205.139.110.61]:33279 helo=us-smtp-delivery-1.mimecast.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iSbap-0007VT-DM for qemu-devel@nongnu.org; Thu, 07 Nov 2019 01:48:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573109310; 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=CN2ulGtul0X2pd3Lw/bT87JsQKQsHK/UR87J4cDQl/k=; b=ZteAsuAvkH7Tjja8RIMyJS50GVUYcDYaPcgcEgqHwQN3ENuEcORALC7V6TqCFFKTzZwBVk 9d4MTiIc5lm1Beuhgz8z176Q0LpkYZlKQQ1oKVJHQNcmT6vcxLDI2o3zKMTCIL1baceeM8 CxV2B7Y4lCUYTgG44xf8fczvMoVWIPU= 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-280-0cipqxXqMOu9hvOV8Hxp6w-1; Thu, 07 Nov 2019 01:48:23 -0500 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 057661800D6B; Thu, 7 Nov 2019 06:48:21 +0000 (UTC) Received: from sirius.home.kraxel.org (ovpn-116-69.ams2.redhat.com [10.36.116.69]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3FE6C1A7E2; Thu, 7 Nov 2019 06:48:19 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 0397416E08; Thu, 7 Nov 2019 07:48:18 +0100 (CET) Date: Thu, 7 Nov 2019 07:48:17 +0100 From: Gerd Hoffmann To: Geoffrey McRae Subject: Re: guest / host buffer sharing ... Message-ID: <20191107064817.j3sfzl6viea4qigc@sirius.home.kraxel.org> References: <20191105105456.7xbhtistnbp272lj@sirius.home.kraxel.org> <20191106124101.fsfxibdkypo4rswv@sirius.home.kraxel.org> <72712fe048af1489368f7416faa92c45@hostfission.com> MIME-Version: 1.0 In-Reply-To: <72712fe048af1489368f7416faa92c45@hostfission.com> User-Agent: NeoMutt/20180716 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-MC-Unique: 0cipqxXqMOu9hvOV8Hxp6w-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 205.139.110.61 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: Hans Verkuil , Alex Lau , Alexandre Courbot , virtio-dev@lists.oasis-open.org, qemu-devel@nongnu.org, Tomasz Figa , Keiichi Watanabe , David Stevens , Daniel Vetter , =?utf-8?B?U3TDqXBoYW5l?= Marchesin , Dylan Reid , Gurchetan Singh , Dmitry Morozov , Pawel Osciak , Linux Media Mailing List Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" > On 2019-11-06 23:41, Gerd Hoffmann wrote: > > On Wed, Nov 06, 2019 at 05:36:22PM +0900, David Stevens wrote: > > > > (1) The virtio device > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > Has a single virtio queue, so the guest can send commands to regist= er > > > > and unregister buffers. Buffers are allocated in guest ram. Each = buffer > > > > has a list of memory ranges for the data. Each buffer also has some > > >=20 > > > Allocating from guest ram would work most of the time, but I think > > > it's insufficient for many use cases. It doesn't really support thing= s > > > such as contiguous allocations, allocations from carveouts or <4GB, > > > protected buffers, etc. > >=20 > > If there are additional constrains (due to gpu hardware I guess) > > I think it is better to leave the buffer allocation to virtio-gpu. >=20 > The entire point of this for our purposes is due to the fact that we can > not allocate the buffer, it's either provided by the GPU driver or > DirectX. If virtio-gpu were to allocate the buffer we might as well forge= t > all this and continue using the ivshmem device. Well, virtio-gpu resources are in guest ram, like the buffers of a virtio-buffers device would be. So it isn't much of a difference. If the buffer provided by the (nvidia/amd/intel) gpu driver lives in ram you can create a virtio-gpu resource for it. On the linux side that is typically handled with dma-buf, one driver exports the dma-buf and the other imports it. virtio-gpu doesn't support that fully yet though (import is being worked on, export is done and will land upstream in the next merge window). No clue how this looks like for windows guests ... > Currently IVSHMEM is used by two projects that I am aware of, Looking > Glass and SCREAM. While Looking Glass is solving a problem that is out of > scope for QEMU, SCREAM is working around the audio problems in QEMU that > have been present for years now. Side note: sound in qemu 3.1+ should be alot better than in 2.x versions. cheers, Gerd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-6293-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 33EB7985EFA for ; Thu, 7 Nov 2019 06:48:31 +0000 (UTC) Date: Thu, 7 Nov 2019 07:48:17 +0100 From: Gerd Hoffmann Message-ID: <20191107064817.j3sfzl6viea4qigc@sirius.home.kraxel.org> References: <20191105105456.7xbhtistnbp272lj@sirius.home.kraxel.org> <20191106124101.fsfxibdkypo4rswv@sirius.home.kraxel.org> <72712fe048af1489368f7416faa92c45@hostfission.com> MIME-Version: 1.0 In-Reply-To: <72712fe048af1489368f7416faa92c45@hostfission.com> Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: [virtio-dev] Re: guest / host buffer sharing ... To: Geoffrey McRae Cc: David Stevens , Keiichi Watanabe , Tomasz Figa , Dmitry Morozov , Alexandre Courbot , Alex Lau , Dylan Reid , =?utf-8?B?U3TDqXBoYW5l?= Marchesin , Pawel Osciak , Hans Verkuil , Daniel Vetter , Gurchetan Singh , Linux Media Mailing List , virtio-dev@lists.oasis-open.org, qemu-devel@nongnu.org List-ID: > On 2019-11-06 23:41, Gerd Hoffmann wrote: > > On Wed, Nov 06, 2019 at 05:36:22PM +0900, David Stevens wrote: > > > > (1) The virtio device > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > Has a single virtio queue, so the guest can send commands to regist= er > > > > and unregister buffers. Buffers are allocated in guest ram. Each = buffer > > > > has a list of memory ranges for the data. Each buffer also has some > > >=20 > > > Allocating from guest ram would work most of the time, but I think > > > it's insufficient for many use cases. It doesn't really support thing= s > > > such as contiguous allocations, allocations from carveouts or <4GB, > > > protected buffers, etc. > >=20 > > If there are additional constrains (due to gpu hardware I guess) > > I think it is better to leave the buffer allocation to virtio-gpu. >=20 > The entire point of this for our purposes is due to the fact that we can > not allocate the buffer, it's either provided by the GPU driver or > DirectX. If virtio-gpu were to allocate the buffer we might as well forge= t > all this and continue using the ivshmem device. Well, virtio-gpu resources are in guest ram, like the buffers of a virtio-buffers device would be. So it isn't much of a difference. If the buffer provided by the (nvidia/amd/intel) gpu driver lives in ram you can create a virtio-gpu resource for it. On the linux side that is typically handled with dma-buf, one driver exports the dma-buf and the other imports it. virtio-gpu doesn't support that fully yet though (import is being worked on, export is done and will land upstream in the next merge window). No clue how this looks like for windows guests ... > Currently IVSHMEM is used by two projects that I am aware of, Looking > Glass and SCREAM. While Looking Glass is solving a problem that is out of > scope for QEMU, SCREAM is working around the audio problems in QEMU that > have been present for years now. Side note: sound in qemu 3.1+ should be alot better than in 2.x versions. cheers, Gerd --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org