Displaying 6 results from an estimated 6 matches for "virtio_gpu_cmd_memory_cr".
2019 Apr 12
2
[PATCH 3/3] virtio-gpu api: VIRTIO_GPU_F_RESSOURCE_V2
...> > > 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)
>
> Thanks for the clarification.
>
> >
> > You could also create a larger pool with VIRTIO_GPU_CMD_MEMORY_CREATE,
> > then go attach multiple resources to it.
> >
> > >...
2019 Apr 12
2
[PATCH 3/3] virtio-gpu api: VIRTIO_GPU_F_RESSOURCE_V2
...> > > 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)
>
> Thanks for the clarification.
>
> >
> > You could also create a larger pool with VIRTIO_GPU_CMD_MEMORY_CREATE,
> > then go attach multiple resources to it.
> >
> > >...
2019 Apr 10
0
[PATCH 2/3] virtio-gpu api: VIRTIO_GPU_F_MEMORY
Introduce the concept of memory regions to virtio-gpu. Initially only
memory regions composed of guest pages are supported (pretty much like
current backing storage for resources). I expect support for other
memory types will be added later on.
VIRTIO_GPU_CMD_MEMORY_CREATE:
creates a new memory region.
VIRTIO_GPU_CMD_MEMORY_UNREF:
destroys a memory region.
VIRTIO_GPU_CMD_RESOURCE_ATTACH_MEMORY:
Use memory region as backing storage for the given resource.
The existing VIRTIO_GPU_CMD_RESOURCE_DETACH_BACKING command
can be used to detach.
Moti...
2019 Apr 12
2
[PATCH 3/3] virtio-gpu api: VIRTIO_GPU_F_RESSOURCE_V2
...ays 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)
> >
> > Thanks for the clarification.
> >
> > >
> > > You could also create a larger pool with VIRTIO_GPU_CMD_MEMORY_CREATE,
> > > then go attach multiple resource...
2019 Apr 11
0
[PATCH 3/3] virtio-gpu api: VIRTIO_GPU_F_RESSOURCE_V2
..._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_M...
2019 Apr 10
0
[PATCH 3/3] virtio-gpu api: VIRTIO_GPU_F_RESSOURCE_V2
...pi/linux/virtio_gpu.h
@@ -58,6 +58,11 @@
*/
#define VIRTIO_GPU_F_MEMORY 2
+/*
+ * VIRTIO_GPU_CMD_RESOURCE_CREATE_V2 command
+ */
+#define VIRTIO_GPU_F_RESSOURCE_V2 3
+
enum virtio_gpu_ctrl_type {
VIRTIO_GPU_UNDEFINED = 0,
@@ -76,6 +81,7 @@ enum virtio_gpu_ctrl_type {
VIRTIO_GPU_CMD_MEMORY_CREATE,
VIRTIO_GPU_CMD_MEMORY_UNREF,
VIRTIO_GPU_CMD_RESOURCE_ATTACH_MEMORY,
+ VIRTIO_GPU_CMD_RESOURCE_CREATE_V2,
/* 3d commands */
VIRTIO_GPU_CMD_CTX_CREATE = 0x0200,
@@ -97,6 +103,7 @@ enum virtio_gpu_ctrl_type {
VIRTIO_GPU_RESP_OK_CAPSET_INFO,
VIRTIO_GPU_RESP_OK_CAPSET,
VIRTIO_GPU_RE...