Re: [Qemu-devel] [PATCH v4 0/6] save/restore on Xen

[Avi Kivity <avi@redhat.com>]

On 01/24/2012 03:25 PM, Anthony Liguori wrote:
>
>>
>>>> To my understanding, QXL will break identically on Xen for the same
>>>> reason: the reset handler assumes it can deal with the VRAM as it
>>>> likes.
>>
>> Yes.  Some data structures for host<->  guest communication are living
>> in device memory, and a reset initializes these.
>
> This should be done by firmware or system software.  

It should be done in the way the device spec says it does.  What does
the qxl spec says?  If it's lacking, we need to fill it up from existing
practice.

> Devices don't initialize memory with data structures on power up.  The
> first problem with doing this is that it assumes a reset order which
> would lengthen the quiescing process.  The second problem is that this
> would require fairly sophisticated logic that could just as well live
> in firmware.

If it's in device firmware, there's no way to tell.  Nothing prevents
the device from clearing its on-board memory during reset.

>
> The advantage of not enabling a device to behave like this is it lets
> us do a much simpler reset model.  To model this properly, we would
> have to support multiple reset propagation hooks (at least a preorder
> and postorder hook).  This adds a fair amount of complication for not
> a lot of benefit (the only benefit is moving firmware logic into QEMU
> which is really a downside :-)).
>

You're arguing about changing a device so it could fit qemu better.  It
should be the other way around.  Granted this is a paravirt device so we
have more leeway, but still qxl is out there and we can't change it.

-- 
error compiling committee.c: too many arguments to function