[PATCH 0/4] HVM Virtual S3 These set of patches are our prototype for HVM virtual ACPI S3 support: - patch 1/4: Xen interface for HVM S3 - patch 2/4: QEMU interface for HVM S3 - patch 3/4: rombios interface for HVM S3 - patch 4/4: xend interface for HVM S3 The main idea is: - emulate ACPI PM1A control resiger in QEMU to capture guest S3 request - when QEMU capture guest S3 request, it call hypercall to trap to Xen - Xen will suspend HVM by reseting all vcpus - on resume, "xm resume" will call hypercall to trap to Xen - Xen will resume HVM by setting HVM vcpu EIP to VMXASSIST BASE, which will start rombios post code - rombios post code will start s3 resume by jumping to wakeup vector set by guest OS. How to use it: - apply this patch to changeset 15050:05c128b0188a - create and boot HVM domain - In HVM guest, enter S3 state * for Linux, "echo mem >/sys/power/state" * for Windows, shutdown windows by Standby - to resume HVM domain, "xm resume <domid>" Note: FC6 guest can successfully S3 suspend/resume in both text mode and X window. However, Windows guest can not suspend, because the windows driver for QEMU VGA and monitor has no power management support, and windows refuse to enter S3 sleep state. Kevin/Ke _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 16/5/07 17:48, "Yu, Ke" <ke.yu@intel.com> wrote:> The main idea is: > - emulate ACPI PM1A control resiger in QEMU to capture guest S3 request > - when QEMU capture guest S3 request, it call hypercall to trap to XenSo why emulate this register in QEMU at all, rather than directly in Xen? Xen already knows the address of the pm1a block of ports because it emulates the pmtimer. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 16/5/07 17:48, "Yu, Ke" <ke.yu@intel.com> wrote:> - apply this patch to changeset 15050:05c128b0188a > - create and boot HVM domain > - In HVM guest, enter S3 state > * for Linux, "echo mem >/sys/power/state" > * for Windows, shutdown windows by Standby > - to resume HVM domain, "xm resume <domid>"Noone''s seriously going to want to use S3-S5 in this way though, are they. Keeping domains hanging around in sleep states taking up memory doesn''t make sense -- users will want to save the domain off to disc and restore later. So this only makes sense at all if integrated with existing HVM save/restore. As I understand it, the only difference between S3 and S5 is that RAM contents are maintained when the machine awakens. In this case S3 is like a simpler version of current save/restore where we do not necessarily need to save device state (but we might decide to if it makes the implementation easier). I think actually this isn''t far off from being what we want. If the s3_suspend hypercall put the domain into suspend state, this would then neatly trigger xc_save to do its stuff. Then you can strip out s3_resume because you should automatically start executing BIOS code when xc_resume restores VCPU state and kicks the domain to start running again. The sleep_state domain variable you added shouldn''t be necessary imo. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 16/5/07 22:59, "Keir Fraser" <Keir.Fraser@cl.cam.ac.uk> wrote:>> The main idea is: >> - emulate ACPI PM1A control resiger in QEMU to capture guest S3 request >> - when QEMU capture guest S3 request, it call hypercall to trap to Xen > > So why emulate this register in QEMU at all, rather than directly in Xen? > Xen already knows the address of the pm1a block of ports because it emulates > the pmtimer.Oh, I see there is device state to be reset in QEMU. Emulating the port access in QEMU makes sense then, but I wonder if rather than adding an extra hypercall command we could emulate it in both Xen and QEMU: Xen emulates the instruction, resets state and triggers domain shutdown, then passes the port access up to QEMU so it does its thing also. We do this emulate-in-both for other things already (e.g., the CMOS index register I believe). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser wrote on 6:34:> On 16/5/07 22:59, "Keir Fraser" <Keir.Fraser@cl.cam.ac.uk> wrote: > >>> The main idea is: >>> - emulate ACPI PM1A control resiger in QEMU to capture guest S3 >>> request >>> - when QEMU capture guest S3 request, it call hypercall to trap to >>> Xen >> >> So why emulate this register in QEMU at all, rather than directly in >> Xen? Xen already knows the address of the pm1a block of ports >> because it emulates the pmtimer. > > Oh, I see there is device state to be reset in QEMU. Emulating the > port access in QEMU makes sense then, but I wonder if rather than > adding an extra hypercall command we could emulate it in both Xen and > QEMU: Xen emulates the instruction, resets state and triggers domain > shutdown, then passes the port access up to QEMU so it does its thing > also. We do this emulate-in-both for other things already (e.g., the > CMOS index register I believe). > > -- KeirYes. that''s a good idea. The only disadvantage is that it scatter the ACPI register logic from QEMU, and make it a little bit harder for maintaince. But it is a acceptable tradeoff. Best Regards Ke _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser wrote on 2007年5月17日 6:30:> On 16/5/07 17:48, "Yu, Ke" <ke.yu@intel.com> wrote: > >> - apply this patch to changeset 15050:05c128b0188a >> - create and boot HVM domain >> - In HVM guest, enter S3 state >> * for Linux, "echo mem >/sys/power/state" >> * for Windows, shutdown windows by Standby >> - to resume HVM domain, "xm resume <domid>" > > Noone''s seriously going to want to use S3-S5 in this way though, are > they. Keeping domains hanging around in sleep states taking up memory > doesn''t make sense -- users will want to save the domain off to disc > and restore later. So this only makes sense at all if integrated with > existing HVM save/restore. > > As I understand it, the only difference between S3 and S5 is that RAM > contents are maintained when the machine awakens. In this case S3 is > like a simpler version of current save/restore where we do not > necessarily need to save device state (but we might decide to if it > makes the implementation easier). > > I think actually this isn''t far off from being what we want. If the > s3_suspend hypercall put the domain into suspend state, this would > then neatly trigger xc_save to do its stuff. Then you can strip out > s3_resume because you should automatically start executing BIOS code > when xc_resume restores VCPU state and kicks the domain to start > running again. The sleep_state domain variable you added shouldn''t be > necessary imo. > > -- KeirMy concern here is that: save/restore is a heavy operation just like S4 (hibernate), while the purpose of S3 is quick suspend and quick resume comapred to S4. if we implement S3 like save/restore, I don''t see the value here, because HVM save/resotre or HVM S4 is just enough. How do you think? Best Regards Ke _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Can you please shed some more light on Windows guest s3 behavior? Is it due to inadequate ACPI support in rombios? -Kaushik -----Original Message----- From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Yu, Ke Sent: Wednesday, May 16, 2007 9:48 AM To: xen-devel@lists.xensource.com Subject: [Xen-devel] [PATCH 0/4] HVM Virtual S3 [PATCH 0/4] HVM Virtual S3 These set of patches are our prototype for HVM virtual ACPI S3 support: - patch 1/4: Xen interface for HVM S3 - patch 2/4: QEMU interface for HVM S3 - patch 3/4: rombios interface for HVM S3 - patch 4/4: xend interface for HVM S3 The main idea is: - emulate ACPI PM1A control resiger in QEMU to capture guest S3 request - when QEMU capture guest S3 request, it call hypercall to trap to Xen - Xen will suspend HVM by reseting all vcpus - on resume, "xm resume" will call hypercall to trap to Xen - Xen will resume HVM by setting HVM vcpu EIP to VMXASSIST BASE, which will start rombios post code - rombios post code will start s3 resume by jumping to wakeup vector set by guest OS. How to use it: - apply this patch to changeset 15050:05c128b0188a - create and boot HVM domain - In HVM guest, enter S3 state * for Linux, "echo mem >/sys/power/state" * for Windows, shutdown windows by Standby - to resume HVM domain, "xm resume <domid>" Note: FC6 guest can successfully S3 suspend/resume in both text mode and X window. However, Windows guest can not suspend, because the windows driver for QEMU VGA and monitor has no power management support, and windows refuse to enter S3 sleep state. Kevin/Ke _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
The symptom is that: if use stdvga in config file, the windows guest will not show "standby" in shutdown menu, which means S3 is disabled. The following link explains why. http://support.microsoft.com/?scid=kb%3Ben-us%3B257562&x=16&y=12 When use cirrus_vga, the "standby" appears in shutdown menu. However, after "standby" is pressed, windows will pop up a dialog box, saying default monitor driver has no power management support, so windows refuse to go further. I think Windows has strict checking on standby. it won''t do standby until the required device driver has suspend/resume support. so it is due to qemu device emulation, not ACPI in rombios. Best Regards Ke Kaushik Barde wrote on 11:14:> Can you please shed some more light on Windows guest s3 behavior? > > Is it due to inadequate ACPI support in rombios? > > -Kaushik >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 17/5/07 03:32, "Yu, Ke" <ke.yu@intel.com> wrote:> My concern here is that: save/restore is a heavy operation just like S4 > (hibernate), while the purpose of S3 is quick suspend and quick resume > comapred to S4. if we implement S3 like save/restore, I don''t see the value > here, because HVM save/resotre or HVM S4 is just enough. How do you think?I do not think that pure virtual S3 by itself makes sense. Unless the whole machine is going into S3, what really is the difference between a HVM guest in S3 and an HVM guest that simply is idle and so has all its VCPUs HLTed 99.9% of the time? Both are tying up memory resource, neither is burning significant CPU resource or I/O resource. Virtual S3 *does* make sense with HVM save/restore because it makes even an HVM guest without PV drivers aware of the save/restore event so it can do things like resync its clock. That is why we are interested in virtual S3: only as an adjunct to save/restore. Another application would be as part of host S3. Given that those patches currently save/restore all domains (which actually I think is stupid, but that''s for a separate email) you should automatically improve host S3 by integrating with save/restore. However, again, the benefit is not the effects of the state the guest finds itself in --- since S3 is not enormously meaningful in a virtualised environment --- but because of the side effects we enjoy when the guest awakens and resyncs its world. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> The symptom is that: if use stdvga in config file, the windows guest > will not show "standby" in shutdown menu, which means S3 is disabled. > The following link explains why. > http://support.microsoft.com/?scid=kb%3Ben-us%3B257562&x=16&y=12 > > When use cirrus_vga, the "standby" appears in shutdown menu. However, > after "standby" is pressed, windows will pop up a dialog box, saying > default monitor driver has no power management support, so windows > refuse to go further.Is the stdvga driver what''s used if you use qemu-dm 0.9.0''s VESA FB emulation or does windows have a more advanced driver for VESA mode, hopefully one that supports S3? Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser wrote on 2007年5月17日 15:41:> On 17/5/07 03:32, "Yu, Ke" <ke.yu@intel.com> wrote: > >> My concern here is that: save/restore is a heavy operation just like >> S4 (hibernate), while the purpose of S3 is quick suspend and quick >> resume comapred to S4. if we implement S3 like save/restore, I don''t >> see the value here, because HVM save/resotre or HVM S4 is just >> enough. How do you think? > > I do not think that pure virtual S3 by itself makes sense. Unless the > whole machine is going into S3, what really is the difference between > a HVM guest in S3 and an HVM guest that simply is idle and so has all > its VCPUs HLTed > 99.9% of the time? Both are tying up memory resource, neither is > burning significant CPU resource or I/O resource.Agree.Virtual S3 itself don''t have practical value.> > Virtual S3 *does* make sense with HVM save/restore because it makes > even an HVM guest without PV drivers aware of the save/restore event > so it can do things like resync its clock. That is why we are > interested in virtual S3: only as an adjunct to save/restore.I see your point. Virtual S3 can be used to assist HVM save/resotor. It is fine.> > Another application would be as part of host S3. Given that those > patches currently save/restore all domains (which actually I think is > stupid, but that''s for a separate email) you should automatically > improve host S3 by integrating with save/restore. However, again, the > benefit is not the effects of the state the guest finds itself in --- > since S3 is not enormously meaningful in a virtualised environment > --- but because of the side effects we enjoy when the guest awakens > and resyncs its world. > > -- KeirVirtual S3 is also an important part of host S3, when HVM domain is assigned with physical device, e.g. with VT-d introduced. When host S3 begins, HVM domain should suspend its physical device, otherwise the physical device may not work after resume. This is the reason why we develop the vritaul S3 feature: help VT-d HVM domain to do power management. In this case, integrating save/resotre with virtual S3 is not necessary, and it actually brings extra overhead. To summary, virtual S3 can have two functionality - assist HVM to do save/restore - assist HVM to do vt-d device power management The first item need to call save/restore while the second item do not. So is it possible that we have two code path, and use flags to tell virtual S3 which path it should go? BTW, I did not see current host S3 patches save/restore all domains. Could you please elabroate more? Best Regards Ke _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi Yuke,> BTW, I did not see current host S3 patches save/restore all domains. Could you please elabroate more?I have tested Kevin''s patches about Dom0-S3. I found the host can resume the HVM after its waking. That is to say host sleep-wake course does not impact the HVM guest on it. My test steps are: 1. Create HVM guest 2. echo "mem" > /sys/power/state on host 3. Wake up the host by Wake-On-Lan 4. Checking "xm lis" and "xm console <Domain_id>" is OK. -----Original Message----- From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Yu, Ke Sent: 2007年5月17日 20:40 To: Keir Fraser; xen-devel@lists.xensource.com Subject: RE: [Xen-devel] [PATCH 0/4] HVM Virtual S3 Keir Fraser wrote on 2007年5月17日 15:41:> On 17/5/07 03:32, "Yu, Ke" <ke.yu@intel.com> wrote: > >> My concern here is that: save/restore is a heavy operation just like >> S4 (hibernate), while the purpose of S3 is quick suspend and quick >> resume comapred to S4. if we implement S3 like save/restore, I don''t >> see the value here, because HVM save/resotre or HVM S4 is just >> enough. How do you think? > > I do not think that pure virtual S3 by itself makes sense. Unless the > whole machine is going into S3, what really is the difference between > a HVM guest in S3 and an HVM guest that simply is idle and so has all > its VCPUs HLTed > 99.9% of the time? Both are tying up memory resource, neither is > burning significant CPU resource or I/O resource.Agree.Virtual S3 itself don''t have practical value.> > Virtual S3 *does* make sense with HVM save/restore because it makes > even an HVM guest without PV drivers aware of the save/restore event > so it can do things like resync its clock. That is why we are > interested in virtual S3: only as an adjunct to save/restore.I see your point. Virtual S3 can be used to assist HVM save/resotor. It is fine.> > Another application would be as part of host S3. Given that those > patches currently save/restore all domains (which actually I think is > stupid, but that''s for a separate email) you should automatically > improve host S3 by integrating with save/restore. However, again, the > benefit is not the effects of the state the guest finds itself in --- > since S3 is not enormously meaningful in a virtualised environment > --- but because of the side effects we enjoy when the guest awakens > and resyncs its world. > > -- KeirVirtual S3 is also an important part of host S3, when HVM domain is assigned with physical device, e.g. with VT-d introduced. When host S3 begins, HVM domain should suspend its physical device, otherwise the physical device may not work after resume. This is the reason why we develop the vritaul S3 feature: help VT-d HVM domain to do power management. In this case, integrating save/resotre with virtual S3 is not necessary, and it actually brings extra overhead. To summary, virtual S3 can have two functionality - assist HVM to do save/restore - assist HVM to do vt-d device power management The first item need to call save/restore while the second item do not. So is it possible that we have two code path, and use flags to tell virtual S3 which path it should go? BTW, I did not see current host S3 patches save/restore all domains. Could you please elabroate more? Best Regards Ke _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 17/5/07 13:39, "Yu, Ke" <ke.yu@intel.com> wrote:> Virtual S3 is also an important part of host S3, when HVM domain is assigned > with physical device, e.g. with VT-d introduced. When host S3 begins, HVM > domain should suspend its physical device, otherwise the physical device may > not work after resume. This is the reason why we develop the vritaul S3 > feature: help VT-d HVM domain to do power management. In this case, > integrating save/resotre with virtual S3 is not necessary, and it actually > brings extra overhead. > > To summary, virtual S3 can have two functionality > - assist HVM to do save/restore > - assist HVM to do vt-d device power management > The first item need to call save/restore while the second item do not.Yes I absolutely agree with all the above. I don''t think we want full save/restore for host S3 at all. We just want to give the domains a little kick so that they at least resync their clocks, maybe regain DHCP leases, etc, when the system comes back up.> So is it possible that we have two code path, and use flags to tell virtual S3 > which path it should go?I think we''ll end up with something like this in the tools, yes. But let''s get the save/restore one plumbed in first. The second case needs integration with VT-d patches and host S3 patches, which aren''t yet in the tree.> BTW, I did not see current host S3 patches save/restore all domains. Could you > please elabroate more?They were posted by your Intel colleague Kevin Tian just a few days ago. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser wrote on 2007年5月17日 21:07:> > I think we''ll end up with something like this in the tools, yes. But > let''s get the save/restore one plumbed in first. The second case > needs integration with VT-d patches and host S3 patches, which aren''t > yet in the tree.Fine to me.> >> BTW, I did not see current host S3 patches save/restore all domains. >> Could you please elabroate more? > > They were posted by your Intel colleague Kevin Tian just a few days > ago.Yes, I see the patches. But as far as I can see, these patches does not save/restore all domains. It only reuse some driver domain suspend/resume logic to suspend/resume the physical devices that driver domain owns. - Ke> > -- Keir_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 17/5/07 14:16, "Yu, Ke" <ke.yu@intel.com> wrote:>> They were posted by your Intel colleague Kevin Tian just a few days >> ago. > > Yes, I see the patches. But as far as I can see, these patches does not > save/restore all domains. It only reuse some driver domain suspend/resume > logic to suspend/resume the physical devices that driver domain owns.Ah, okay, it looks like I misunderstood. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Pratt wrote on 17:54:> > Is the stdvga driver what''s used if you use qemu-dm 0.9.0''s VESA FB > emulation or does windows have a more advanced driver for VESA mode, > hopefully one that supports S3? > > IanIn VGA card side, the VESA FB emulation has not been tried yet, but the cirrus_vga works fine with Windows. Windows has cirrus VGA driver, which supports S3, So this issue is resolved. Current issue is that Windows is not happy with the standard monitor driver. And unfortunately, seems there is no monitor emulation code in QEMU, so there may be no way to change the QEMU monitor type. It would be better if someone can tell how to change that. Best Regards Ke _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> In VGA card side, the VESA FB emulation has not been tried yet, butthe> cirrus_vga works fine with Windows. Windows has cirrus VGA driver,which> supports S3, So this issue is resolved. > > Current issue is that Windows is not happy with the standard monitor > driver. And unfortunately, seems there is no monitor emulation code in > QEMU, so there may be no way to change the QEMU monitor type. It would > be better if someone can tell how to change that.But presumably the monitor driver changes if you use VESA FB as the DDC information is available via VESA calls? Hopefully this supports S3. Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Pratt wrote on 2007年5月17日 22:15:>> In VGA card side, the VESA FB emulation has not been tried yet, but >> the cirrus_vga works fine with Windows. Windows has cirrus VGA >> driver, which supports S3, So this issue is resolved. >> >> Current issue is that Windows is not happy with the standard monitor >> driver. And unfortunately, seems there is no monitor emulation code >> in QEMU, so there may be no way to change the QEMU monitor type. It >> would be better if someone can tell how to change that. > > But presumably the monitor driver changes if you use VESA FB as the > DDC information is available via VESA calls? Hopefully this supports > S3. > > > IanOh, I will try that. Thanks for the info. - Ke _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I don''t believe so.. We intend to use this support (with some additional ACPI enhancements) as elaborated by Ke. -Kaushik -----Original Message----- From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Keir Fraser Sent: Wednesday, May 16, 2007 3:30 PM To: Yu, Ke; xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH 0/4] HVM Virtual S3 On 16/5/07 17:48, "Yu, Ke" <ke.yu@intel.com> wrote:> - apply this patch to changeset 15050:05c128b0188a > - create and boot HVM domain > - In HVM guest, enter S3 state > * for Linux, "echo mem >/sys/power/state" > * for Windows, shutdown windows by Standby > - to resume HVM domain, "xm resume <domid>"Noone''s seriously going to want to use S3-S5 in this way though, are they. Keeping domains hanging around in sleep states taking up memory doesn''t make sense -- users will want to save the domain off to disc and restore later. So this only makes sense at all if integrated with existing HVM save/restore. As I understand it, the only difference between S3 and S5 is that RAM contents are maintained when the machine awakens. In this case S3 is like a simpler version of current save/restore where we do not necessarily need to save device state (but we might decide to if it makes the implementation easier). I think actually this isn''t far off from being what we want. If the s3_suspend hypercall put the domain into suspend state, this would then neatly trigger xc_save to do its stuff. Then you can strip out s3_resume because you should automatically start executing BIOS code when xc_resume restores VCPU state and kicks the domain to start running again. The sleep_state domain variable you added shouldn''t be necessary imo. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kaushik Barde wrote on 4:25:> I don''t believe so.. We intend to use this support (with some > additional ACPI enhancements) as elaborated by Ke. > > > -Kaushik >Nice to know virtual S3 has other usage model. Do you want to use that for S3 validation? - Ke _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>From: Keir Fraser >Sent: 2007年5月17日 21:34 > >On 17/5/07 14:16, "Yu, Ke" <ke.yu@intel.com> wrote: > >>> They were posted by your Intel colleague Kevin Tian just a few days >>> ago. >> >> Yes, I see the patches. But as far as I can see, these patches does not >> save/restore all domains. It only reuse some driver domain >suspend/resume >> logic to suspend/resume the physical devices that driver domain owns. > >Ah, okay, it looks like I misunderstood. > > -- Keir >Great that people are looking at host S3 side. :-) The host S3 patch only tackles dom0/xen, and leave user level to notify all para-domUs and HVM domains before requesting real S3 switch. So basically to make a complete eco-system: - Need to trigger virtual S3 to HVM domain - Need light weight suspend/resume to para-domU (without domain destroy) for fast resume. Actually I sent out months ago and you suggested to re-send after basic host S3 is ready Currently host S3 only imposes a last level means to force all domains paused in case they''re not doing well. Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>From: Keir Fraser >Sent: 2007年5月17日 6:34 > >Oh, I see there is device state to be reset in QEMU. Emulating the port >access in QEMU makes sense then, but I wonder if rather than adding >an extra >hypercall command we could emulate it in both Xen and QEMU: Xen >emulates the >instruction, resets state and triggers domain shutdown, then passes the >port >access up to QEMU so it does its thing also. We do this emulate-in-both >for >other things already (e.g., the CMOS index register I believe). > > -- Keir >I doubt whether this will bring some tricky issues if Qemu happens to inject some event after Xen''s reset but before Qemu''s reset. If that event results a stale pending interrupt after Xen resets vPIC or vIOAPIC, will that result a spurious interrupt after HVM is resumed? By current style, Qemu first reset all virtual devices and thus stop interrupt sources. Then it''s safe to let Xen do a full reset subsequently. Also normally the reason to put Qemu logic into Xen is for performance. For virtual S3 interception, it doesn''t matter since only resume time is the concern. Just doubt whether it''s worthy of such split anyway. :-) Of course above concern is only for one path per your on-going discussion. For the other path on top of save/restore, it''s always OK since domain is re-created. Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Absolutely.. Is this (Virtual S3) patch independent of Xen i.e. can we use it with 3.0.4? Thanks. -Kaushik -----Original Message----- From: Yu, Ke [mailto:ke.yu@intel.com] Sent: Thursday, May 17, 2007 7:06 PM To: Kaushik Barde; Keir Fraser; xen-devel@lists.xensource.com Subject: RE: [Xen-devel] [PATCH 0/4] HVM Virtual S3 Kaushik Barde wrote on 4:25:> I don''t believe so.. We intend to use this support (with some > additional ACPI enhancements) as elaborated by Ke. > > > -Kaushik >Nice to know virtual S3 has other usage model. Do you want to use that for S3 validation? - Ke _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kaushik Barde wrote on 12:22:> Absolutely.. Is this (Virtual S3) patch independent of Xen i.e. can > we use it with 3.0.4? > > Thanks. > > -Kaushik >It should be able to work in Xen 3.0.4. You need rebase and the rebase effort is small. - Ke _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 18/5/07 03:38, "Tian, Kevin" <kevin.tian@intel.com> wrote:> I doubt whether this will bring some tricky issues if Qemu happens > to inject some event after Xen''s reset but before Qemu''s reset. If > that event results a stale pending interrupt after Xen resets vPIC or > vIOAPIC, will that result a spurious interrupt after HVM is resumed? > By current style, Qemu first reset all virtual devices and thus stop > interrupt sources. Then it''s safe to let Xen do a full reset subsequently. > > Also normally the reason to put Qemu logic into Xen is for performance. For > virtual S3 interception, it doesn''t matter since only resume time is > the concern. > > Just doubt whether it''s worthy of such split anyway. :-)Okay, let''s rename this s3_suspend hypercall to system_reset instead, and leave it that. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser wrote on 2007年5月17日 21:07:> > I think we''ll end up with something like this in the tools, yes. But > let''s get the save/restore one plumbed in first. The second case > needs integration with VT-d patches and host S3 patches, which aren''t > yet in the tree. > > -- KeirHi Keir, I just discuss with Edwin and Kevin on the HVM save/restore integration with virtual S3. Basically, the following things need to be done: 1. For HVM without PV, QEMU call xc_save, qemu_savevm,... at the virtual S3 final stage. 2. For HVM with PV, need also add PV driver suspend/resume interface to disconnect/reconnect xenbus connection. Since I am not familiar with the HVM save/restore, how about the following working model: - I implement the basic Virtual S3 code and leave interface for save/restore - You or the PV maintainer add the above save/restore logic upon the basic virtual S3 code. Best Regards Ke _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 21/5/07 04:10, "Yu, Ke" <ke.yu@intel.com> wrote:> 1. For HVM without PV, QEMU call xc_save, qemu_savevm,... at the virtual S3 > final stage.In this case S3 should somehow be an option to ''xm save'', so an alternative to doing an immediate remote shutdown on the HVM guest. Instead we would inject a S3 event and when the guest enters S3 qemu would do the remote shutdown at that point. This has to be an option to ''xm save'', or perhaps a domain config option, because not all guests will respond to PM events to enter S3 state.> 2. For HVM with PV, need also add PV driver suspend/resume interface to > disconnect/reconnect xenbus connection.Possibly we can leave the S3 kickoff to the PV drivers. So xend notifies PV drivers to suspend, they do their thing, kick S3 code in a guest-OS-specific way, guest enters S3, qemu does remote shutdown. Then on wakeup the S3 restore code runs before PV-driver restore. -- Keir> - I implement the basic Virtual S3 code and leave interface for save/restore > - You or the PV maintainer add the above save/restore logic upon the basic > virtual S3 code._______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
At 22:17 +0800 on 17 May (1179440232), Yu, Ke wrote:> Ian Pratt wrote on 2007??5??17?? 22:15: > >> In VGA card side, the VESA FB emulation has not been tried yet, but > >> the cirrus_vga works fine with Windows. Windows has cirrus VGA > >> driver, which supports S3, So this issue is resolved. > >> > >> Current issue is that Windows is not happy with the standard monitor > >> driver. And unfortunately, seems there is no monitor emulation code > >> in QEMU, so there may be no way to change the QEMU monitor type. It > >> would be better if someone can tell how to change that.Sorry for joining this thread quite late - I''ve been away for a few weeks. I found that the attached patch to the Cirrus VGA BIOS helps Windows along (but not quite enough). It adds some VBE power-management calls to the BIOS, telling Windows that it''s capable of putting the screen to sleep. Unfortunately, this just changes the error from the monitor driver refusing to allow S3 to the Cirrus driver refusing to allow it. :| Tracing the BIOS and I/O activity of Windows, the next most likely culprit is when the Cirrus driver tries to talk DDC2B to the monitor at start of day (by frobbing the line state manually via Cirrus control registers) and gets no response. Since it can''t read the monitor''s descriptor tables it can''t be sure that it''s possible to put it to sleep properly. Since implementing a DDC2B state machine and faking out the tables sounds nasty, I agree with Ian that the VESA/VBE device model is probably the way forward, in the hope of getting Windows to use BIOS calls for all this. Cheers, Tim. -- Tim Deegan <Tim.Deegan@xensource.com>, XenSource UK Limited Registered office c/o EC2Y 5EB, UK; company number 05334508 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel