[PATCH 0/4] rest of xen host s3 patches

[PATCH 0/4] rest of xen host s3 patches

[Tian, Kevin]

Hi, Keir,
	Per your previous comments, now comes the rest part of xen host 
s3 patches:

[PATCH 1/4] ACPI sleep info and interface
[PATCH 2/4] SMP support to Xen PM
[PATCH 3/4] Create -xen version for necessary archfiles
[PATCH 4/4] Enable ACPI sleep in XenLinux

	One comment from you is held, that acpi sleep option
(s3_bios/s3_mode) is still required to be passed from dom0, since 
VGA has been given to dom0 only which knows the VGA mode before 
sleep.

Thanks,
Kevin

Re: [PATCH 0/4] rest of xen host s3 patches

[Keir Fraser]

On 19/7/07 11:01, "Tian, Kevin" <kevin.tian@intel.com> wrote:

> One comment from you is held, that acpi sleep option
> (s3_bios/s3_mode) is still required to be passed from dom0, since
> VGA has been given to dom0 only which knows the VGA mode before
> sleep.

But Xen set the mode in the first place. If dom0 changed it subsequently, by
means unknown to Xen, then dom0 can re-set that mode on wakeup. The most you
should need at the Xen interface is a 'don't-touch-video-state' boolean
flag. What if dom0 has installed a gfx driver that bashes the hardware
directly?

 -- Keir

RE: [PATCH 0/4] rest of xen host s3 patches

[Tian, Kevin]

>From: Keir Fraser [mailto:keir@xensource.com]
>Sent: 2007年7月19日 18:07
>On 19/7/07 11:01, "Tian, Kevin" <kevin.tian@intel.com> wrote:
>
>> One comment from you is held, that acpi sleep option
>> (s3_bios/s3_mode) is still required to be passed from dom0, since
>> VGA has been given to dom0 only which knows the VGA mode before
>> sleep.
>
>But Xen set the mode in the first place. If dom0 changed it subsequently,
>by
>means unknown to Xen, then dom0 can re-set that mode on wakeup.
>The most you
>should need at the Xen interface is a 'don't-touch-video-state' boolean
>flag. What if dom0 has installed a gfx driver that bashes the hardware
>directly?
>
> -- Keir

But why do we need to restore Xen mode first and then let dom0 
recover its own later if any difference? Xen doesn’t require VGA at 
resume actually since it's assigned to dom0 at boot. Dom0's 
VGA resume code is like Xen's wakeup stub which runs in real 
mode, which is unused now. Do you want to support that then? 

Thanks,
Kevin

Re: [PATCH 0/4] rest of xen host s3 patches

[Keir Fraser]

On 19/7/07 11:29, "Tian, Kevin" <kevin.tian@intel.com> wrote:

> But why do we need to restore Xen mode first and then let dom0
> recover its own later if any difference? Xen doesn¹t require VGA at
> resume actually since it's assigned to dom0 at boot. Dom0's
> VGA resume code is like Xen's wakeup stub which runs in real
> mode, which is unused now. Do you want to support that then?

Dom0 cannot have changed the video mode via the bios. So what's the issue,
exactly? Xen set the mode, Xen knows the mode number, end of story as far as
I can see.

 -- Keir

Re: [PATCH 0/4] rest of xen host s3 patches

[Alan Cox]

> Dom0 cannot have changed the video mode via the bios. So what's the issue,

Thats untrue. The X VESA servers use the BIOS for video mode control.

> exactly? Xen set the mode, Xen knows the mode number, end of story as far as
> I can see.

Call the BIOS methods on most cards on a resume from RAM and the machine
crashes because you have to reprogram the video state.

Alan

Re: [PATCH 0/4] rest of xen host s3 patches

[Keir Fraser]

On 19/7/07 11:47, "Alan Cox" <alan@lxorguk.ukuu.org.uk> wrote:

>> Dom0 cannot have changed the video mode via the bios. So what's the issue,
> 
> Thats untrue. The X VESA servers use the BIOS for video mode control.

I don't think that Linux's S3 wakeup code would take such a mode-change into
account though, right? It looks like saved_video_mode gets latched on bootup
and is never subsequently changed. As you say, it looks like the right thing
to do in most cases is not touch the video bios at all on wakeup.

 -- Keir

RE: [PATCH 0/4] rest of xen host s3 patches

[Tian, Kevin]

>From: Keir Fraser [mailto:keir@xensource.com]
>Sent: 2007年7月19日 19:08
>
>On 19/7/07 11:47, "Alan Cox" <alan@lxorguk.ukuu.org.uk> wrote:
>
>>> Dom0 cannot have changed the video mode via the bios. So what's
>the issue,
>>
>> Thats untrue. The X VESA servers use the BIOS for video mode
>control.
>
>I don't think that Linux's S3 wakeup code would take such a
>mode-change into
>account though, right? It looks like saved_video_mode gets latched on
>bootup
>and is never subsequently changed. As you say, it looks like the right
>thing
>to do in most cases is not touch the video bios at all on wakeup.
>
> -- Keir

I don't think we should take existing Linux mode-change into account, 
since it may change later and why do we add such assumption here. 
Anyway, the most right way to do VGA resume is by BIOS, if such 
VGA repost BIOS option is provided at S3 resume. All above options 
(mode/bios) are just work-around there in case they may work with 
some cards.

Currently Linux recovers its VGA mode (if s3_mode is chosen) done 
in wakeup assembly code. In xen case, since xen provides the wakeup 
stub and hypercall return will recover vcpu context of dom0, dom0's 
wakeup logic is actually disabled by resuming to next instruction after 
hypercall.

If we want to follow your suggestion to let dom0 recover its own mode, 
that means either to add vm86 support in Xen to walk dom0 wakeup 
path, or write a new code for VGA mode reset. But that makes xenlinux 
difference from base more and is it worthy?

Though ideally the owner of device should take care of it in most cases, 
VGA is only one special and current approach is simplest, IMO.

Thanks,
Kevin