Hi Kevin,
Commit 8b0c509e7cdb broke S3 resume on QEMU. Before this commit QEMU compiled bios with S3_RESUME_VGA_INIT enabled. After it this is no longer an option.
-- Gleb.
On Wed, Jan 18, 2012 at 11:40:28AM +0200, Gleb Natapov wrote:
Hi Kevin,
Commit 8b0c509e7cdb broke S3 resume on QEMU. Before this commit QEMU compiled bios with S3_RESUME_VGA_INIT enabled. After it this is no longer an option.
I didn't know QEmu used custom compile options. I don't see this in the QEmu source - where does it set it?
Moving the option from compile time to run time should be better all around. Can QEmu just set the flag in fwcfg if this functionality is needed?
-Kevin
On Wed, Jan 18, 2012 at 08:27:31AM -0500, Kevin O'Connor wrote:
On Wed, Jan 18, 2012 at 11:40:28AM +0200, Gleb Natapov wrote:
Hi Kevin,
Commit 8b0c509e7cdb broke S3 resume on QEMU. Before this commit QEMU compiled bios with S3_RESUME_VGA_INIT enabled. After it this is no longer an option.
I didn't know QEmu used custom compile options. I don't see this in the QEmu source - where does it set it?
I not sure what QEMU upstream does. In RHEL we have local patch to change the setting. Without it resume does not work correctly.
Moving the option from compile time to run time should be better all around. Can QEmu just set the flag in fwcfg if this functionality is needed?
It can I suppose, but then you will not be able to use newer Seabios with older QEMU. The question is if such an option is the way to go forward since for QEMU it will always be set anyway.
-- Gleb.
On Wed, Jan 18, 2012 at 04:09:45PM +0200, Gleb Natapov wrote:
On Wed, Jan 18, 2012 at 08:27:31AM -0500, Kevin O'Connor wrote:
On Wed, Jan 18, 2012 at 11:40:28AM +0200, Gleb Natapov wrote:
Hi Kevin,
Commit 8b0c509e7cdb broke S3 resume on QEMU. Before this commit QEMU compiled bios with S3_RESUME_VGA_INIT enabled. After it this is no longer an option.
I didn't know QEmu used custom compile options. I don't see this in the QEmu source - where does it set it?
I not sure what QEMU upstream does. In RHEL we have local patch to change the setting. Without it resume does not work correctly.
Moving the option from compile time to run time should be better all around. Can QEmu just set the flag in fwcfg if this functionality is needed?
It can I suppose, but then you will not be able to use newer Seabios with older QEMU. The question is if such an option is the way to go forward since for QEMU it will always be set anyway.
The current SeaBIOS checks fwcfg for a "file" named "etc/s3-resume-vga-init" - if it exists it will use it. This works on all versions of qemu (though, of course, on current qemu the file isn't found and the default is to not run the vgabios on resume).
As for the option always being set - we discussed this some time back. My read of the ACPI spec says that the firmware should not need to do any device initialization on resume (including running the vga bios). The ACPI spec definitely doesn't require the firmware to run the vga bios (or even allude to the possibility). Further, I haven't seen any spec that indicates the vga bios should be prepared to be executed on a resume. So, in the general case, I see running the vga bios as potentially harmful to the resume process. (We would be executing third-party code in a restricted environment and expecting it to not touch any memory, with no apparent spec documenting that fact.)
If someone can point out a spec to the contrary I'd be happy to change the default in SeaBIOS.
-Kevin
On Wed, Jan 18, 2012 at 09:37:18PM -0500, Kevin O'Connor wrote:
On Wed, Jan 18, 2012 at 04:09:45PM +0200, Gleb Natapov wrote:
On Wed, Jan 18, 2012 at 08:27:31AM -0500, Kevin O'Connor wrote:
On Wed, Jan 18, 2012 at 11:40:28AM +0200, Gleb Natapov wrote:
Hi Kevin,
Commit 8b0c509e7cdb broke S3 resume on QEMU. Before this commit QEMU compiled bios with S3_RESUME_VGA_INIT enabled. After it this is no longer an option.
I didn't know QEmu used custom compile options. I don't see this in the QEmu source - where does it set it?
I not sure what QEMU upstream does. In RHEL we have local patch to change the setting. Without it resume does not work correctly.
Moving the option from compile time to run time should be better all around. Can QEmu just set the flag in fwcfg if this functionality is needed?
It can I suppose, but then you will not be able to use newer Seabios with older QEMU. The question is if such an option is the way to go forward since for QEMU it will always be set anyway.
The current SeaBIOS checks fwcfg for a "file" named "etc/s3-resume-vga-init" - if it exists it will use it. This works on all versions of qemu (though, of course, on current qemu the file isn't found and the default is to not run the vgabios on resume).
This is strange definition of "works" :) It does not run vga rom on resume which makes Linux fail to resume properly. I wouldn't call that "works". We can provide "etc/s3-resume-vga-init" through fwcfg in QEMU, but this will not make older QEMUs magically work.
If it can be shown that with QEMU there is a situation when running vgabios on resume is actually harmful, then I agree we should add a command line option to dynamically enable this behaviour and use "etc/s3-resume-vga-init" to communicate the setting to the SeaBIOS.
As for the option always being set - we discussed this some time back. My read of the ACPI spec says that the firmware should not need to do any device initialization on resume (including running the vga bios). The ACPI spec definitely doesn't require the firmware to run the vga bios (or even allude to the possibility). Further, I haven't seen any spec that indicates the vga bios should be prepared to be executed on a resume. So, in the general case, I see running the vga bios as potentially harmful to the resume process. (We would be executing third-party code in a restricted environment and expecting it to not touch any memory, with no apparent spec documenting that fact.)
Yes, it was discussed here: http://www.seabios.org/pipermail/seabios/2010-February/000346.html
And there I pointed out that many BIOSes has an option to run vga BIOS on resume and even link to a post with description of the same problem we have in QEMU + Linux resuming to console. So the problem is a not product of my imagination.
If someone can point out a spec to the contrary I'd be happy to change the default in SeaBIOS.
There is spec and there is real life. Real life should take precedence. There is not way OSMP can restore unknown state of a random vga card without special driver for that card. This is why vgabios exists in the first place.
I am also not asking to change SeaBIOS default. Just get us back compile time option to always enable it.
-- Gleb.
Gleb Natapov wrote:
If someone can point out a spec to the contrary I'd be happy to change the default in SeaBIOS.
There is spec and there is real life. Real life should take precedence.
In real life, SeaBIOS does not need to run the VGA BIOS when I resume my ThinkPad with coreboot.
Why should QEMU impose an artificial requirement which additionally aligns poorly with the common specifications?
"This is how it always was" is fine to have some temporary legacy support, but it's not an excuse to not fix the problem properly, in the right place.
There is not way OSMP can restore unknown state of a random vga card without special driver for that card.
It sounds like QEMU just needs a simple KMS driver. Isn't there actually one already, which might fit well?
This is why vgabios exists in the first place.
VGA BIOS exists because 30 years ago it seemed like a good idea to abstract graphics hardware, so that the only operating system at the time did not have to know hardware details.
That model completely and utterly fails with every operating system today, where indeed there are, must be and should be, device drivers.
I am also not asking to change SeaBIOS default. Just get us back compile time option to always enable it.
It seems older QEMU would work fine also without the option given the right OS drivers. In case they aren't actually available I guess a SeaBIOS compile time option is the only workaround.
//Peter
On Thu, Jan 19, 2012 at 08:59:50AM +0100, Peter Stuge wrote:
Gleb Natapov wrote:
If someone can point out a spec to the contrary I'd be happy to change the default in SeaBIOS.
There is spec and there is real life. Real life should take precedence.
In real life, SeaBIOS does not need to run the VGA BIOS when I resume my ThinkPad with coreboot.
So do not run it on a ThinkPad. BTW are you resuming to X? Can you switch to a console and suspend/resume there to see if it works?
Why should QEMU impose an artificial requirement which additionally aligns poorly with the common specifications?
There is nothing artificial about the requirement. It exists on real HW. Here for instance: http://www.nvnews.net/vbulletin/showthread.php?t=130909
"This is how it always was" is fine to have some temporary legacy support, but it's not an excuse to not fix the problem properly, in the right place.
There is not way OSMP can restore unknown state of a random vga card without special driver for that card.
It sounds like QEMU just needs a simple KMS driver. Isn't there actually one already, which might fit well?
QEMU has no drivers. It has devices.
This is why vgabios exists in the first place.
VGA BIOS exists because 30 years ago it seemed like a good idea to abstract graphics hardware, so that the only operating system at the time did not have to know hardware details.
That model completely and utterly fails with every operating system today, where indeed there are, must be and should be, device drivers.
And meanwhile, in real life, you cannot resume Linux into console. This abstract graphics HW surely helped Linux adoption. Without it you wouldn't be able to run Linux even in a text mode on most HW in late 90s since nobody published HW spec and wrote drivers for Linux.
I am also not asking to change SeaBIOS default. Just get us back compile time option to always enable it.
It seems older QEMU would work fine also without the option given the right OS drivers. In case they aren't actually available I guess a SeaBIOS compile time option is the only workaround.
-- Gleb.
Hi,
The current SeaBIOS checks fwcfg for a "file" named "etc/s3-resume-vga-init" - if it exists it will use it. This works on all versions of qemu (though, of course, on current qemu the file isn't found and the default is to not run the vgabios on resume).
This is strange definition of "works" :) It does not run vga rom on resume which makes Linux fail to resume properly. I wouldn't call that "works". We can provide "etc/s3-resume-vga-init" through fwcfg in QEMU, but this will not make older QEMUs magically work.
S3 support in qemu isn't (yet) very useful anyway, so I don't think we have to worry too much, especially about older versions. Beside that I guess older qemus don't work anyway, for me it works like this (with rhel-5 as guest):
Setting etc/s3-resume-vga-init to 1 makes resume hang with "Running option rom at c000:0003" being the last line seabios prints. Maybe vgabios attempts to do something which is illegal on resume and blows up.
When setting etc/s3-resume-vga-init to 0 linux resumes fine. vga text console is dead indeed. Serial console works fine though and the system is alive. When suspending with cirrus vga and X11 being active the system comes out of standby with vga console being functional too.
I am also not asking to change SeaBIOS default. Just get us back compile time option to always enable it.
I think using etc/s3-resume-vga-init to control this is just fine ...
cheers, Gerd
On Thu, Jan 19, 2012 at 10:52:19AM +0100, Gerd Hoffmann wrote:
Hi,
The current SeaBIOS checks fwcfg for a "file" named "etc/s3-resume-vga-init" - if it exists it will use it. This works on all versions of qemu (though, of course, on current qemu the file isn't found and the default is to not run the vgabios on resume).
This is strange definition of "works" :) It does not run vga rom on resume which makes Linux fail to resume properly. I wouldn't call that "works". We can provide "etc/s3-resume-vga-init" through fwcfg in QEMU, but this will not make older QEMUs magically work.
S3 support in qemu isn't (yet) very useful anyway, so I don't think we have to worry too much, especially about older versions. Beside that I guess older qemus don't work anyway, for me it works like this (with rhel-5 as guest):
Setting etc/s3-resume-vga-init to 1 makes resume hang with "Running option rom at c000:0003" being the last line seabios prints. Maybe vgabios attempts to do something which is illegal on resume and blows up.
I did a lot of suspend and resumes with different qemus and never saw this problem. Furthermore WHQL testing does suspend and resumes and I never got similar bug report from those who run it too. So lets not make big "OMG S3 is completely broken" issue from your specific problem before we even know what is the reason behind it.
There is absolutely nothing that vgabios may attempt to do that is illegal on resume and may cause this kind of hang. The only thing that is illegal on resume is to use non reserved RAM, but this will cause OS to fail after resume, not vgabios to hang.
When setting etc/s3-resume-vga-init to 0 linux resumes fine. vga text console is dead indeed. Serial console works fine though and the system is alive. When suspending with cirrus vga and X11 being active the system comes out of standby with vga console being functional too.
X has i8086 interpreter to run vgabios. It is very likely what it does here. BTW there is vga_reset utility in svgalib package that runs vgabios in emulator and can restore working console after resume too.
I am also not asking to change SeaBIOS default. Just get us back compile time option to always enable it.
I think using etc/s3-resume-vga-init to control this is just fine ...
If and only if QEMU will enable it conditionally it is appropriate to introduce it. Otherwise compile time option, that served us well, should be reintroduced.
-- Gleb.
Gleb Natapov wrote:
In real life, SeaBIOS does not need to run the VGA BIOS when I resume my ThinkPad with coreboot.
So do not run it on a ThinkPad.
If it's not needed on my machine, why would it be the right solution anywhere else?
BTW are you resuming to X? Can you switch to a console and suspend/resume there to see if it works?
Both work fine. The KMS driver restores the hardware correctly.
Why should QEMU impose an artificial requirement which additionally aligns poorly with the common specifications?
There is nothing artificial about the requirement. It exists on real HW. Here for instance: http://www.nvnews.net/vbulletin/showthread.php?t=130909
It *is* rtificial because it is obviously not always neccessary.
In the above forum post it's also clear that the problem is that the graphics driver is unable to resume properly. During the three years since that post maybe the NVIDIA driver situation has improved. (I haven't used NVIDIA graphics in a while, so I can't say there.)
There is not way OSMP can restore unknown state of a random vga card without special driver for that card.
It sounds like QEMU just needs a simple KMS driver. Isn't there actually one already, which might fit well?
QEMU has no drivers. It has devices.
Yeah. You mentioned "driver" so I did the same. Sorry for not making it more explicit that like you I also refered to a driver in the operating system.
That model completely and utterly fails with every operating system today, where indeed there are, must be and should be, device drivers.
And meanwhile, in real life, you cannot resume Linux into console.
It works fine for me. Try it on your machine with a KMS driver. They've been around for a few years now, and as I mentioned I believe there is a KMS driver intended for guest use too.
This abstract graphics HW surely helped Linux adoption. Without it you wouldn't be able to run Linux even in a text mode on most HW in late 90s since nobody published HW spec and wrote drivers for Linux.
20 years later the software and hardware landscape is very different.
//Peter
On Thu, Jan 19, 2012 at 05:15:58PM +0100, Peter Stuge wrote:
Gleb Natapov wrote:
In real life, SeaBIOS does not need to run the VGA BIOS when I resume my ThinkPad with coreboot.
So do not run it on a ThinkPad.
If it's not needed on my machine, why would it be the right solution anywhere else?
That's the strange question. Because it does not work for others may be?
BTW are you resuming to X? Can you switch to a console and suspend/resume there to see if it works?
Both work fine. The KMS driver restores the hardware correctly.
Why should QEMU impose an artificial requirement which additionally aligns poorly with the common specifications?
There is nothing artificial about the requirement. It exists on real HW. Here for instance: http://www.nvnews.net/vbulletin/showthread.php?t=130909
It *is* rtificial because it is obviously not always neccessary.
That's strange definition of artificial. Something that is not always necessary is not artificial.
In the above forum post it's also clear that the problem is that the graphics driver is unable to resume properly. During the three years since that post maybe the NVIDIA driver situation has improved. (I haven't used NVIDIA graphics in a while, so I can't say there.)
He does not use X. He does not need proprietary NVIDIA driver.
There is not way OSMP can restore unknown state of a random vga card without special driver for that card.
It sounds like QEMU just needs a simple KMS driver. Isn't there actually one already, which might fit well?
QEMU has no drivers. It has devices.
Yeah. You mentioned "driver" so I did the same. Sorry for not making it more explicit that like you I also refered to a driver in the operating system.
That model completely and utterly fails with every operating system today, where indeed there are, must be and should be, device drivers.
And meanwhile, in real life, you cannot resume Linux into console.
It works fine for me. Try it on your machine with a KMS driver.
On my machine I install any standard distribution and it does not work. I tried several Red Hats, Fedoras and Debian.
They've been around for a few years now, and as I mentioned I believe there is a KMS driver intended for guest use too.
This abstract graphics HW surely helped Linux adoption. Without it you wouldn't be able to run Linux even in a text mode on most HW in late 90s since nobody published HW spec and wrote drivers for Linux.
20 years later the software and hardware landscape is very different.
And resume on standard vga still does not work.
-- Gleb.
On Thu, Jan 19, 2012 at 09:02:09AM +0200, Gleb Natapov wrote:
And there I pointed out that many BIOSes has an option to run vga BIOS on resume and even link to a post with description of the same problem we have in QEMU + Linux resuming to console. So the problem is a not product of my imagination.
It is a real issue. Running the vgabios helps some people on real hardware too. That's why the option is in seabios, and it's why the option was made runtime instead of compile time.
If someone can point out a spec to the contrary I'd be happy to change the default in SeaBIOS.
There is spec and there is real life. Real life should take precedence. There is not way OSMP can restore unknown state of a random vga card without special driver for that card. This is why vgabios exists in the first place.
I am also not asking to change SeaBIOS default. Just get us back compile time option to always enable it.
I'm sorry the 8b0c509e7cdb change bit you. I didn't know of the dependency on the compile time option - had I known I would have made the change more clear.
I do think moving from compile time options to runtime options is important. If you need a quick fix to get your build working, the patch to seabios is below. I do think we should try to figure out how we can get options passed into SeaBIOS effectively.
-Kevin
--- a/src/optionroms.c +++ b/src/optionroms.c @@ -423,7 +423,7 @@ vga_setup(void)
// Load some config settings that impact VGA. EnforceChecksum = romfile_loadint("etc/optionroms-checksum", 1); - S3ResumeVgaInit = romfile_loadint("etc/s3-resume-vga-init", 0); + S3ResumeVgaInit = romfile_loadint("etc/s3-resume-vga-init", 1); ScreenAndDebug = romfile_loadint("etc/screen-and-debug", 1);
if (CONFIG_OPTIONROMS_DEPLOYED) {
On Thu, Jan 19, 2012 at 12:16:25PM +0200, Gleb Natapov wrote:
There is absolutely nothing that vgabios may attempt to do that is illegal on resume and may cause this kind of hang. The only thing that is illegal on resume is to use non reserved RAM, but this will cause OS to fail after resume, not vgabios to hang.
On an S3 resume, the bios isn't required to init hardware - in particular, the current seabios resume code doesn't initialize PCI or initialize the standard timer. It's not clear to me that the VGA BIOS will run properly if these services aren't setup.
Further, no spec I've seen says an option rom must handle being executed a second time. The option rom can self modify - re-running a modified rom may crash it. Thinking about this further, the vgabios in the seabios repo wont handle being executed twice properly (which, of course, should be fixed).
To be clear, I really don't know the exact interactions between an off the shelf BIOS and a "real world" vga bios on resume. If someone can find a spec or document clarifying that - I'd be happy to conform to it.
I am also not asking to change SeaBIOS default. Just get us back compile time option to always enable it.
I think using etc/s3-resume-vga-init to control this is just fine ...
If and only if QEMU will enable it conditionally it is appropriate to introduce it. Otherwise compile time option, that served us well, should be reintroduced.
QEMU upstream uses SeaBIOS defaults afaik. So, I don't really understand your statement.
-Kevin
On 01/20/12 02:40, Kevin O'Connor wrote:
On Thu, Jan 19, 2012 at 12:16:25PM +0200, Gleb Natapov wrote:
There is absolutely nothing that vgabios may attempt to do that is illegal on resume and may cause this kind of hang. The only thing that is illegal on resume is to use non reserved RAM, but this will cause OS to fail after resume, not vgabios to hang.
On an S3 resume, the bios isn't required to init hardware - in particular, the current seabios resume code doesn't initialize PCI or initialize the standard timer. It's not clear to me that the VGA BIOS will run properly if these services aren't setup.
The vga bios tries to find the vga memory bar in pci config space (for VBE, both bochs+cirrus, using pcibios). Will that work?
cheers, Gerd
Hi,
I do think moving from compile time options to runtime options is important. If you need a quick fix to get your build working, the patch to seabios is below. I do think we should try to figure out how we can get options passed into SeaBIOS effectively.
Current runtime option is easy to handle on the qemu side, see attached patch.
cheers, Gerd
On Thu, Jan 19, 2012 at 08:22:00PM -0500, Kevin O'Connor wrote:
On Thu, Jan 19, 2012 at 09:02:09AM +0200, Gleb Natapov wrote:
And there I pointed out that many BIOSes has an option to run vga BIOS on resume and even link to a post with description of the same problem we have in QEMU + Linux resuming to console. So the problem is a not product of my imagination.
It is a real issue. Running the vgabios helps some people on real hardware too. That's why the option is in seabios, and it's why the option was made runtime instead of compile time.
For coreboot where video HW is unknown it make sense. For QEMU we know that it is needed so we can set it in compile time.
If someone can point out a spec to the contrary I'd be happy to change the default in SeaBIOS.
There is spec and there is real life. Real life should take precedence. There is not way OSMP can restore unknown state of a random vga card without special driver for that card. This is why vgabios exists in the first place.
I am also not asking to change SeaBIOS default. Just get us back compile time option to always enable it.
I'm sorry the 8b0c509e7cdb change bit you. I didn't know of the dependency on the compile time option - had I known I would have made the change more clear.
I do think moving from compile time options to runtime options is important. If you need a quick fix to get your build working, the patch to seabios is below. I do think we should try to figure out how we can get options passed into SeaBIOS effectively.
It is easy to pass the option, but is not needed. I don't like adding code that is unneeded.
-Kevin
--- a/src/optionroms.c +++ b/src/optionroms.c @@ -423,7 +423,7 @@ vga_setup(void)
// Load some config settings that impact VGA. EnforceChecksum = romfile_loadint("etc/optionroms-checksum", 1);
- S3ResumeVgaInit = romfile_loadint("etc/s3-resume-vga-init", 0);
- S3ResumeVgaInit = romfile_loadint("etc/s3-resume-vga-init", 1);
So why not return compile time option to set the default?
ScreenAndDebug = romfile_loadint("etc/screen-and-debug", 1); if (CONFIG_OPTIONROMS_DEPLOYED) {
-- Gleb.
On Thu, Jan 19, 2012 at 08:40:45PM -0500, Kevin O'Connor wrote:
On Thu, Jan 19, 2012 at 12:16:25PM +0200, Gleb Natapov wrote:
There is absolutely nothing that vgabios may attempt to do that is illegal on resume and may cause this kind of hang. The only thing that is illegal on resume is to use non reserved RAM, but this will cause OS to fail after resume, not vgabios to hang.
On an S3 resume, the bios isn't required to init hardware - in
Yes, because it is assumed that OSMP has a driver.
particular, the current seabios resume code doesn't initialize PCI or initialize the standard timer. It's not clear to me that the VGA BIOS will run properly if these services aren't setup.
Further, no spec I've seen says an option rom must handle being executed a second time. The option rom can self modify - re-running a modified rom may crash it. Thinking about this further, the vgabios in the seabios repo wont handle being executed twice properly (which, of course, should be fixed).
Not sure how thing works on real HW, but on QEMU S3 actually invokes HW reset. The same reset that is done on reboot, so option rom should be reset to its pristine state. I expect that on real HW things should be similar if device powered down on S3.
To be clear, I really don't know the exact interactions between an off the shelf BIOS and a "real world" vga bios on resume. If someone can find a spec or document clarifying that - I'd be happy to conform to it.
I am not asking to change how Seabios works on real HW. What it does currently on real HW has a lot of sense and models behaviour of real BIOSes as far as I can tell.
I am also not asking to change SeaBIOS default. Just get us back compile time option to always enable it.
I think using etc/s3-resume-vga-init to control this is just fine ...
If and only if QEMU will enable it conditionally it is appropriate to introduce it. Otherwise compile time option, that served us well, should be reintroduced.
QEMU upstream uses SeaBIOS defaults afaik. So, I don't really understand your statement.
Checking QEMU upstream is not the only (or even best) thing to do! Distributions package their own SeaBIOS and distribution I care about has this option set.
-- Gleb.
On Fri, Jan 20, 2012 at 12:08:39PM +0100, Gerd Hoffmann wrote:
Hi,
I do think moving from compile time options to runtime options is important. If you need a quick fix to get your build working, the patch to seabios is below. I do think we should try to figure out how we can get options passed into SeaBIOS effectively.
Current runtime option is easy to handle on the qemu side, see attached patch.
The patch adds 10 lines of code that should be there.
cheers, Gerd
From 311be2fd346b75c296856299250ada7c5ffbf207 Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann kraxel@redhat.com Date: Thu, 19 Jan 2012 11:46:55 +0100 Subject: [PATCH] enable s3-resume-vga-init
Signed-off-by: Gerd Hoffmann kraxel@redhat.com
hw/fw_cfg.c | 9 +++++++++ hw/fw_cfg.h | 1 + 2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/hw/fw_cfg.c b/hw/fw_cfg.c index f953532..87ae272 100644 --- a/hw/fw_cfg.c +++ b/hw/fw_cfg.c @@ -460,6 +460,14 @@ int fw_cfg_add_file(FWCfgState *s, const char *filename, uint8_t *data, return 1; }
+/* see romfile_loadint() in src/paravirt.c in seabios */ +void fw_cfg_romfile_storeint(FWCfgState *s, const char *fn, uint64_t val) +{
- uint64_t *st = g_malloc(sizeof(*st));
- *st = val;
- fw_cfg_add_file(s, fn, (void *)st, sizeof(*st));
+}
static void fw_cfg_machine_ready(struct Notifier *n, void *data) { uint32_t len; @@ -467,6 +475,7 @@ static void fw_cfg_machine_ready(struct Notifier *n, void *data) char *bootindex = get_boot_devices_list(&len);
fw_cfg_add_file(s, "bootorder", (uint8_t*)bootindex, len);
- fw_cfg_romfile_storeint(s, "etc/s3-resume-vga-init", 1);
}
FWCfgState *fw_cfg_init(uint32_t ctl_port, uint32_t data_port, diff --git a/hw/fw_cfg.h b/hw/fw_cfg.h index 856bf91..f2ba50d 100644 --- a/hw/fw_cfg.h +++ b/hw/fw_cfg.h @@ -62,6 +62,7 @@ int fw_cfg_add_callback(FWCfgState *s, uint16_t key, FWCfgCallback callback, void *callback_opaque, uint8_t *data, size_t len); int fw_cfg_add_file(FWCfgState *s, const char *filename, uint8_t *data, uint32_t len); +void fw_cfg_romfile_storeint(FWCfgState *s, const char *fn, uint64_t val); FWCfgState *fw_cfg_init(uint32_t ctl_port, uint32_t data_port, target_phys_addr_t crl_addr, target_phys_addr_t data_addr);
-- 1.7.1
-- Gleb.
On Fri, Jan 20, 2012 at 12:08:39PM +0100, Gerd Hoffmann wrote:
Hi,
I do think moving from compile time options to runtime options is important. If you need a quick fix to get your build working, the patch to seabios is below. I do think we should try to figure out how we can get options passed into SeaBIOS effectively.
Current runtime option is easy to handle on the qemu side, see attached patch.
[...]
+/* see romfile_loadint() in src/paravirt.c in seabios */ +void fw_cfg_romfile_storeint(FWCfgState *s, const char *fn, uint64_t val) +{
- uint64_t *st = g_malloc(sizeof(*st));
- *st = val;
- fw_cfg_add_file(s, fn, (void *)st, sizeof(*st));
Be sure to store the value in little-endian format.
-Kevin
On Fri, Jan 20, 2012 at 01:50:15PM +0200, Gleb Natapov wrote:
On Thu, Jan 19, 2012 at 08:40:45PM -0500, Kevin O'Connor wrote:
Further, no spec I've seen says an option rom must handle being executed a second time. The option rom can self modify - re-running a modified rom may crash it. Thinking about this further, the vgabios in the seabios repo wont handle being executed twice properly (which, of course, should be fixed).
Not sure how thing works on real HW, but on QEMU S3 actually invokes HW reset. The same reset that is done on reboot, so option rom should be reset to its pristine state. I expect that on real HW things should be similar if device powered down on S3.
I'm 99% sure that wont work. Option roms have to be copied from PCI bars to low memory. If seabios copies the option rom again (to reset its state) then all option roms would need to be copied (the initial option rom size could be larger than the final option rom size). Running all option roms again is surely going to break something.
To be clear, I really don't know the exact interactions between an off the shelf BIOS and a "real world" vga bios on resume. If someone can find a spec or document clarifying that - I'd be happy to conform to it.
I am not asking to change how Seabios works on real HW. What it does currently on real HW has a lot of sense and models behaviour of real BIOSes as far as I can tell.
I understand your point about requesting QEMU specific code. I really prefer to keep things general where ever possible, however. I think both projects are better off if the most code possible can be shared. If QEMU *always* needed this setting, I could see adding it to the init phase of seabios. However, Windows doesn't seem to need it, and it's unclear what VGA pass-through would require (though granted, that has many other hurdles).
-Kevin
On Fri, Jan 20, 2012 at 08:48:39AM -0500, Kevin O'Connor wrote:
On Fri, Jan 20, 2012 at 01:50:15PM +0200, Gleb Natapov wrote:
On Thu, Jan 19, 2012 at 08:40:45PM -0500, Kevin O'Connor wrote:
Further, no spec I've seen says an option rom must handle being executed a second time. The option rom can self modify - re-running a modified rom may crash it. Thinking about this further, the vgabios in the seabios repo wont handle being executed twice properly (which, of course, should be fixed).
Not sure how thing works on real HW, but on QEMU S3 actually invokes HW reset. The same reset that is done on reboot, so option rom should be reset to its pristine state. I expect that on real HW things should be similar if device powered down on S3.
I'm 99% sure that wont work. Option roms have to be copied from PCI
You 99% sure it wont work on real HW or on QEMU? IIRC QEMU puts vgabios into 0xc0000 directly.
bars to low memory. If seabios copies the option rom again (to reset its state) then all option roms would need to be copied (the initial option rom size could be larger than the final option rom size). Running all option roms again is surely going to break something.
I do not think I ever talked about running all option roms :)
To be clear, I really don't know the exact interactions between an off the shelf BIOS and a "real world" vga bios on resume. If someone can find a spec or document clarifying that - I'd be happy to conform to it.
I am not asking to change how Seabios works on real HW. What it does currently on real HW has a lot of sense and models behaviour of real BIOSes as far as I can tell.
I understand your point about requesting QEMU specific code. I really prefer to keep things general where ever possible, however. I think both projects are better off if the most code possible can be shared. If QEMU *always* needed this setting, I could see adding it to the init phase of seabios.
I think we can do both. Share the code and be QEMU specific. We can do it like this:
S3ResumeVgaInit = romfile_loadint("etc/s3-resume-vga-init", !CONFIG_COREBOOT);
This way default will be different on QEMU and if QEMU will ever need to disable the option (for vga path through may be) it will be able to do so.
However, Windows doesn't seem to need it, andit's unclear what VGA pass-through would require (though granted, that has many other hurdles).
Windows is actually smart. It knows that it can support S3 resume on generic VGA so it does not allow you to do S3 suspend when one is in use. We managed to trick WindowsXP + cirrus to allow S3 suspend by DSDT magic, but after resume GUI is not usable. Still good enough for running WHQL. The only way S3 works on all Windowses is by using QXL device and driver that supports S3.
-- Gleb.
Hi,
I'm 99% sure that wont work. Option roms have to be copied from PCI
You 99% sure it wont work on real HW or on QEMU? IIRC QEMU puts vgabios into 0xc0000 directly.
That is looooooooooooooooong history, it went away about the same time qemu switched from bochs bios to seabios.
These days seabios loads them from either pci rom bar or via fw_cfg.
Windows is actually smart. It knows that it can support S3 resume on generic VGA so it does not allow you to do S3 suspend when one is in use. We managed to trick WindowsXP + cirrus to allow S3 suspend by DSDT magic, but after resume GUI is not usable. Still good enough for running WHQL. The only way S3 works on all Windowses is by using QXL device and driver that supports S3.
If you ask the linux graphics guys the situation is simliar on linux. S3 without kms driver doesn't work reliably and isn't supported[1]. Only difference is that linux doesn't enforce this by refusing to suspend without kms.
cheers, Gerd
[1] summary of a longish discussion, don't remember where though.
On Fri, Jan 20, 2012 at 04:23:15PM +0100, Gerd Hoffmann wrote:
Hi,
I'm 99% sure that wont work. Option roms have to be copied from PCI
You 99% sure it wont work on real HW or on QEMU? IIRC QEMU puts vgabios into 0xc0000 directly.
That is looooooooooooooooong history, it went away about the same time qemu switched from bochs bios to seabios.
These days seabios loads them from either pci rom bar or via fw_cfg.
Ah yeah fw_cfg. How could I forget about it :) Still we know what our vgabios is doing so we can make sure it works. bochs bios had to be fixed to make S3 work too.
Windows is actually smart. It knows that it can support S3 resume on generic VGA so it does not allow you to do S3 suspend when one is in use. We managed to trick WindowsXP + cirrus to allow S3 suspend by DSDT magic, but after resume GUI is not usable. Still good enough for running WHQL. The only way S3 works on all Windowses is by using QXL device and driver that supports S3.
If you ask the linux graphics guys the situation is simliar on linux.
Well it is obviously not :) Microsoft makes sure resume works if suspend is allowed.
S3 without kms driver doesn't work reliably and isn't supported[1]. Only difference is that linux doesn't enforce this by refusing to suspend without kms.
If it isn't supported it should not be allowed. Why Linux graphics guys do not send patch that disables S3 on unsupported configurations? Did this come up in [1]?
But I want to understand their support statement a little bit better. Do you need kms driver for resume to be "supported" even if X is running? Because if X is not enough we may as well remove S3 from dsdt.
BTW does QXL have kms driver?
cheers, Gerd
[1] summary of a longish discussion, don't remember where though.
-- Gleb.
On Sun, Jan 22, 2012 at 12:46:43PM +0200, Gleb Natapov wrote:
On Fri, Jan 20, 2012 at 04:23:15PM +0100, Gerd Hoffmann wrote:
Hi,
I'm 99% sure that wont work. Option roms have to be copied from PCI
You 99% sure it wont work on real HW or on QEMU? IIRC QEMU puts vgabios into 0xc0000 directly.
That is looooooooooooooooong history, it went away about the same time qemu switched from bochs bios to seabios.
These days seabios loads them from either pci rom bar or via fw_cfg.
Ah yeah fw_cfg. How could I forget about it :) Still we know what our vgabios is doing so we can make sure it works. bochs bios had to be fixed to make S3 work too.
Windows is actually smart. It knows that it can support S3 resume on generic VGA so it does not allow you to do S3 suspend when one is in use. We managed to trick WindowsXP + cirrus to allow S3 suspend by DSDT magic, but after resume GUI is not usable. Still good enough for running WHQL. The only way S3 works on all Windowses is by using QXL device and driver that supports S3.
If you ask the linux graphics guys the situation is simliar on linux.
Well it is obviously not :) Microsoft makes sure resume works if suspend is allowed.
S3 without kms driver doesn't work reliably and isn't supported[1]. Only difference is that linux doesn't enforce this by refusing to suspend without kms.
If it isn't supported it should not be allowed. Why Linux graphics guys do not send patch that disables S3 on unsupported configurations? Did this come up in [1]?
But I want to understand their support statement a little bit better. Do you need kms driver for resume to be "supported" even if X is running? Because if X is not enough we may as well remove S3 from dsdt.
BTW does QXL have kms driver?
No. (== not yet.. I'm actually working on this)
cheers, Gerd
[1] summary of a longish discussion, don't remember where though.
-- Gleb.
SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
-
Alon Levy -
Gerd Hoffmann -
Gleb Natapov -
Kevin O'Connor -
Peter Stuge