lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20190417095750.lre3xrg4dlgskfjg@sirius.home.kraxel.org> Date: Wed, 17 Apr 2019 11:57:50 +0200 From: Gerd Hoffmann <kraxel@...hat.com> To: Chia-I Wu <olvaffe@...il.com> Cc: Gurchetan Singh <gurchetansingh@...omium.org>, Tomeu Vizoso <tomeu.vizoso@...labora.com>, "Michael S. Tsirkin" <mst@...hat.com>, David Airlie <airlied@...ux.ie>, Jason Wang <jasowang@...hat.com>, open list <linux-kernel@...r.kernel.org>, ML dri-devel <dri-devel@...ts.freedesktop.org>, "open list:VIRTIO CORE, NET AND BLOCK DRIVERS" <virtualization@...ts.linux-foundation.org>, David Airlie <airlied@...hat.com>, virtio@...ts.oasis-open.org Subject: Re: [PATCH 3/3] virtio-gpu api: VIRTIO_GPU_F_RESSOURCE_V2 On Fri, Apr 12, 2019 at 04:34:20PM -0700, Chia-I Wu wrote: > Hi, > > I am still new to virgl, and missed the last round of discussion about > resource_create_v2. > > From the discussion below, semantically resource_create_v2 creates a host > resource object _without_ any storage; memory_create creates a host memory > object which provides the storage. Is that correct? Right now all resource_create_* variants create a resource object with host storage. memory_create creates guest storage, and resource_attach_memory binds things together. Then you have to transfer the data. Hmm, maybe we need a flag indicating that host storage is not needed, for resources where we want establish some kind of shared mapping later on. > Do we expect these new commands to be supported by OpenGL, which does not > separate resources and memories? Well, for opengl you need a 1:1 relationship between memory region and resource. > > Yes, even though it is not clear yet how we are going to handle > > host-allocated buffers in the vhost-user case ... > > This might be another dumb question, but is this only an issue for > vhost-user(-gpu) case? What mechanisms are used to map host dma-buf into > the guest address space? qemu can change the address space, that includes mmap()ing stuff there. An external vhost-user process can't do this, it can only read the address space layout, and read/write from/to guest memory. > But one needs to create the resource first to know which memory types can > be attached to it. I think the metadata needs to be returned with > resource_create_v2. There is a resource_info reply for that. > That should be good enough. But by returning alignments, we can minimize > the gaps when attaching multiple resources, especially when the resources > are only used by GPU. We can add alignments to the resource_info reply. cheers, Gerd
Powered by blists - more mailing lists