> > +/* VIRTIO_GPU_CMD_RESOURCE_CREATE_V2 */ > > +struct virtio_gpu_cmd_resource_create_v2 { > > + struct virtio_gpu_ctrl_hdr hdr; > > + __le32 resource_id; > > + __le32 format; > > + __le32 width; > > + __le32 height; > > + /* 3d only */ > > + __le32 target; > > + __le32 bind; > > + __le32 depth; > > + __le32 array_size; > > + __le32 last_level; > > + __le32 nr_samples; > > + __le32 flags; > > +}; > > > I assume this is always backed by some host side allocation, without any > guest side pages associated with it?
No. It is not backed at all yet. Workflow would be like this: (1) VIRTIO_GPU_CMD_RESOURCE_CREATE_V2 (2) VIRTIO_GPU_CMD_MEMORY_CREATE (see patch 2) (3) VIRTIO_GPU_CMD_RESOURCE_MEMORY_ATTACH (see patch 2) You could also create a larger pool with VIRTIO_GPU_CMD_MEMORY_CREATE, then go attach multiple resources to it. > If so, do we want the option for the guest allocate? Allocation options are handled by VIRTIO_GPU_CMD_MEMORY_CREATE (initially guest allocated only, i.e. what virtio-gpu supports today, the plan is to add other allocation types later on). > > +/* VIRTIO_GPU_RESP_OK_RESOURCE_INFO */ > > +struct virtio_gpu_resp_resource_info { > > + struct virtio_gpu_ctrl_hdr hdr; > > + __le32 stride[4]; > > + __le32 size[4]; > > +}; > > offsets[4] needed too That is in VIRTIO_GPU_CMD_RESOURCE_MEMORY_ATTACH ... cheers, Gerd _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization