>> 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.
