[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.


Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.