[Spice-devel] UMS memory management

[Hans de Goede]

Hi,

On 03/27/2013 12:04 PM, Søren Sandmann wrote:
> Hans de Goede <hdegoede at redhat.com> writes:
>
>> Hmm, I assume with host-memory you mean guest memory here, right? iow surfaces
>> will be moved by the driver from video-memory to X-server allocated memory (which
>> in a vm is guest memory). I'm assuming this is what you mean in the rest of
>> my reply.
>
> Right, "host" here means the host of the video device.
>
>>> ** IN_VIDEO => IN_HOST
>>>
>>> - update_area is issued for the surface in question
>>> - data is copied to pixman image
>>> - state is set to IN_HOST
>>> - destroy command is issued for the ID
>>
>> I assume the main use-case for this is freeing up video memory,
>> unfortunately due to glz compression and the drawing command tree
>> kept in the spice-server, it is possible that the server itself
>> still holds a reference to the surface, and sending the destroy
>> will not end up freeing any memory (atleast not directly), this
>> is esp. going to be a problem when doing these kind of evictions
>> with the intention of freeing up a larger block of memory
>> for a new surface.
>
> Indeed, this is a problem. The way I intend to deal with this was
> described later in the mail:
>
>      After issuing a destroy, need to wait for the command ring to go
>      idle, then garbage collect. Hopefully this will trigger a recycle
>      call, which will then free the associated memory.
>
> But if that fails, it will simply kick out another surface and try
> again.

Given how spice-server works, I'm worried this may nor work all to well.

But we'll just have to wait and see. I just want it to be clear, that
making changes to the virtual hardware to make life easier for the
driver is an option too.

Regards,

Hans