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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Keir Fraser [mailto:keir@xxxxxxxxxxxxx]
>Sent: 2007年7月19日 19:08
>
>On 19/7/07 11:47, "Alan Cox" <alan@xxxxxxxxxxxxxxxxxxx> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel