On Wed, Nov 06, 2019 at 05:36:22PM +0900, David Stevens wrote: > > (1) The virtio device > > ===================== > > > > Has a single virtio queue, so the guest can send commands to register > > 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 > > 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 things > such as contiguous allocations, allocations from carveouts or <4GB, > protected buffers, etc. If there are additional constrains (due to gpu hardware I guess) I think it is better to leave the buffer allocation to virtio-gpu. virtio-gpu can't do that right now, but we have to improve virtio-gpu memory management for vulkan support anyway. > > properties to carry metadata, some fixed (id, size, application), but > > What exactly do you mean by application? Basically some way to group buffers. A wayland proxy for example would add a "application=wayland-proxy" tag to the buffers it creates in the guest, and the host side part of the proxy could ask qemu (or another vmm) to notify about all buffers with that tag. So in case multiple applications are using the device in parallel they don't interfere with each other. > > also allow free form (name = value, framebuffers would have > > width/height/stride/format for example). > > Is this approach expected to handle allocating buffers with > hardware-specific constraints such as stride/height alignment or > tiling? Or would there need to be some alternative channel for > determining those values and then calculating the appropriate buffer > size? No parameter negotiation. cheers, Gerd
