>> Can the host refuse due to lack of resources? > > Yes. virtgpu_ctrl_hdr.type in the response will be set to > VIRTGPU_RESP_ERR_* then. Current implementation does that only on > malloc() failure, there is no accounting (yet) to limit the amout of > memory the guest is allowed to allocate. We do probably need to work out some sort of accounting system, it can probably reliably only be a total value of resources, since we've no idea if the host driver will store them in VRAM or main memory. Quite how to fail gracefully is a question, probably need to report to the guest what context did the allocation and see if we can destroy it. >> > + >> > +VIRTGPU_CMD_RESOURCE_INVAL_BACKING: >> > + Command: struct virtgpu_resource_inval_backing >> >> Why is it called INVAL_BACKING instead of DETACH_BACKING? "Detach" is >> logical since there is also an "attach" command. > > No particular reason I think. Dave? > Not reason I can remember, I think I was thinking of having separate inval and detach at one point, but it didn't really make any sense, so renaming to detach is fine with me. Dave. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
