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

[Anthony Liguori <anthony@codemonkey.ws>]

On 01/23/2012 11:31 AM, Jan Kiszka wrote:
> On 2012-01-23 18:18, Anthony Liguori wrote:
>> On 01/23/2012 11:13 AM, Jan Kiszka wrote:
>>>>>> To reply to your previous question more clearly: at restore time Qemu on
>>>>>> Xen would run in a non-standard scenario; the restore of the RAM happens
>>>>>> before QEMU is even started.
>>>>>>
>>>>>> That is unfortunate but it would be very hard to change (I can give you
>>>>>> more details if you are interested in the reasons why it would be so
>>>>>> difficult).
>>>>>
>>>>> If you can't change this, you need to properly introduce this new
>>>>> scenario - pre-initialized RAM - to the QEMU device model. Or you will
>>>>> see breakage outside cirrus sooner or later as well. So it might be good
>>>>> to explain the reason why it can't be changed under Xen when motivating
>>>>> this concept extension to QEMU.
>>>>
>>>> OK.
>>>> Are you thinking about introducing this concept as a new runstate?
>>>> This special runstate could be set at restore time only on Xen.
>>>>
>>>>
>>>> BTW the main reasons for having Xen saving the RAM are:
>>>>
>>>> - the need to support PV guests, that often run without Qemu;
>>>> - the current save format, that is built around the fact that Xen saves the memory;
>>>> - the fact that Qemu might be running in a very limited stub-domain.
>>>
>>> Your problem is not the fact that guest RAM is restored by an external
>>> component. Your problem is that QEMU has no control over the when. If
>>> you fix this, you could coordinate the restoring with the initial device
>>> reset and would solve all potential current and future issues, not only
>>> this single cirrus related one.
>>
>> Generally speaking, RAM is an independent device in most useful cases.  Onboard
>> RAM is a very special case because it's extremely unusual.
>>
>> But since some video cards can make use of dedicated external RAM, I don't think
>> any video card really depends on initial RAM state.
>>
>> What's most likely here is that the VGA BIOS of a Cirrus card sets an initial
>> RAM state during device initialization.
>>
>> We really should view RAM as just another device so I don't like the idea of
>> propagating a global concept of "when RAM is restored" because that treats it
>> specially compared to other devices.
>>
>> But viewing RAM as just another device, having Xen only restore a subset of
>> devices should be a reasonable thing to do moving forward.  The main problem
>> here I believe is that we have part of the VGA Bios functionality in the
>> hardware emulation.
>
> 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.

QXL also has a VGA BIOS that it could use to initialize VRAM.  A similar change 
could be made for it.

In general, devices shouldn't make assumptions about the state of other devices 
during reset.  Writing to RAM assumes that RAM has been fully initialized.  We 
don't express reset dependencies right now and it's not clear to me that this is 
something that we should be modeling.

Regards,

Anthony Liguori

>
> Jan
>