From: Gleb Natapov <gleb@redhat.com>
To: Sebastian Herbszt <herbszt@gmx.de>
Cc: bochs-developers@lists.sourceforge.net, qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [Bochs-developers] [PATCH 2/6] Add S3 state to DSDT. Handle resumeevent in the BIOS.
Date: Sun, 2 Nov 2008 12:04:32 +0200 [thread overview]
Message-ID: <20081102100432.GB16809@redhat.com> (raw)
In-Reply-To: <D2320D98C2C74774AD7F785CB3035DAB@FSCPC>
On Thu, Oct 30, 2008 at 11:41:28PM +0100, Sebastian Herbszt wrote:
> Gleb Natapov wrote:
>> diff --git a/bios/rombios.c b/bios/rombios.c
>> index 88eac04..46996fa 100644
>> --- a/bios/rombios.c
>> +++ b/bios/rombios.c
>> @@ -2198,6 +2198,31 @@ debugger_off()
>> outb(0xfedc, 0x00);
>> }
>>
>> +void
>> +s3_resume()
>> +{
>> + Bit32u s3_wakeup_vector;
>> + Bit8u s3_resume_flag;
>> +
>> + s3_resume_flag = read_byte(0x40, 0xb0);
>> + s3_wakeup_vector = read_dword(0x40, 0xb2);
>> +
>> + BX_INFO("S3 resume called %x 0x%lx\n", s3_resume_flag, s3_wakeup_vector);
>> + if (s3_resume_flag != 0xFE || !s3_wakeup_vector)
>> + return;
>> +
>> + write_byte(0x40, 0xb0, 0);
>> +
>> + /* setup wakeup vector */
>> + write_word(0x40, 0xb6, (s3_wakeup_vector & 0xF)); /* IP */
>> + write_word(0x40, 0xb8, (s3_wakeup_vector >> 4)); /* CS */
>
> Any reason not to use 0040h:0067h instead?
>
It is OS visible. OS can assume that a value written there will stay
there till overwritten by the OS itself.
>> -void rombios32_init(void)
>> +static uint32_t find_resume_vector(void)
>> {
>> - BX_INFO("Starting rombios32\n");
>> + unsigned long addr;
>> +
>> + if (bios_table_cur_addr == 0)
>> + return 0;
>
> BX_USE_EBDA_TABLES case
>
>> +
OK.
>> + for (addr = bios_table_cur_addr; addr < bios_table_end_addr; addr++) {
>> + if (!memcmp((void*)addr, "RSD PTR ", 8)) {
>> + struct rsdp_descriptor *rsdp = (void*)addr;
>> + struct rsdt_descriptor_rev1 *rsdt = (void*)rsdp->rsdt_physical_address;
>> + struct fadt_descriptor_rev1 *fadt = (void*)rsdt->table_offset_entry[0];
>> + struct facs_descriptor_rev1 *facs = (void*)fadt->firmware_ctrl;
>> + return facs->firmware_waking_vector;
>> + }
>> + }
>> +
>
> RSDP is on a 16-byte boundary
>
OK.
>> + return 0;
>> +}
>> +
>> +static void find_440fx(PCIDevice *d)
>> +{
>> + uint16_t vendor_id, device_id;
>> +
>> + vendor_id = pci_config_readw(d, PCI_VENDOR_ID);
>> + device_id = pci_config_readw(d, PCI_DEVICE_ID);
>> +
>> + if (vendor_id == 0x8086 && device_id == 0x1237)
>> + i440_pcidev = *d;
>
> Please use PCI_VENDOR_ID_INTEL and PCI_DEVICE_ID_INTEL_82441.
>
OK.
>> +}
>> +
>> +void rombios32_init(uint32_t *s3_resume_vector, uint8_t *shutdown_flag)
>> +{
>> + BX_INFO("Starting rombios32 %p %p %x\n", s3_resume_vector, shutdown_flag, *shutdown_flag);
>
> Maybe make it two lines and explain the values for the log:
>
> BX_INFO("Starting rombios32\n");
> BX_INFO("s3_resume_vector=%p ... \n", s3_resume_vector, ...
>
OK. Actually printing *shutdown_flag is enough. Pointer are always
same and were needed for debug only.
>>
>> #ifdef BX_QEMU
>> qemu_cfg_port = qemu_cfg_port_probe();
>> @@ -2025,6 +2070,24 @@ void rombios32_init(void)
>>
>> smp_probe();
>>
>> + if (find_bios_table_area() < 0)
>> + return;
>
> It should not return if BX_USE_EBDA_TABLES is defined.
> Is there a need to return at all?
>
Indeed. No need to return here.
>> +
>> + if (*shutdown_flag == 0xfe) {
>> + *s3_resume_vector = find_resume_vector();
>> + if (!*s3_resume_vector) {
>> + BX_INFO("This is S3 resume but wakeup vector is NULL\n");
>> + } else {
>> + BX_INFO("S3 resume vector %p\n", *s3_resume_vector);
>> + /* redirect bios read access to RAM */
>> + pci_for_each_device(find_440fx);
>> + bios_lock_shadow_ram(); /* bios is already copied */
>
> bios_shadow_init() is called in pci_bios_init(). Why do we need to lock it here?
>
Because we don't call pci_bios_init() if it is S3 resume.
>> + return;
>> + }
>> + }
>> +
>> + uuid_probe();
>> +
>> pci_bios_init();
>>
>> if (bios_table_cur_addr != 0) {
>>
>
> rombios32.c r1.32 got:
>
> smp_probe();
>
> pci_bios_init();
>
> if (bios_table_cur_addr != 0) {
>
> mptable_init();
>
> uuid_probe();
>
> The patch should remove uuid_probe() from the if-case.
>
Why? uuid_probe() is needed only if SMBIOS tables are built. And
smbios_init() call is in the same if. BTW judging by this if it
looks like BX_USE_EBDA_TABLES is not supported today too since
bios_table_cur_addr is always zero in this case.
--
Gleb.
next prev parent reply other threads:[~2008-11-02 10:04 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-27 10:12 [Qemu-devel] [PATCH 0/6] Support for S3 ACPI state (suspend to memory) in BIOS Gleb Natapov
2008-10-27 10:12 ` [Qemu-devel] [PATCH 1/6] Move PIC initialization out of line to save space in post code area Gleb Natapov
2008-10-27 10:13 ` [Qemu-devel] [PATCH 2/6] Add S3 state to DSDT. Handle resume event in the BIOS Gleb Natapov
2008-10-30 22:41 ` [Qemu-devel] Re: [Bochs-developers] [PATCH 2/6] Add S3 state to DSDT. Handle resumeevent " Sebastian Herbszt
2008-11-02 10:04 ` Gleb Natapov [this message]
2008-11-02 18:13 ` [Qemu-devel] Re: [Bochs-developers] [PATCH 2/6] Add S3 state to DSDT. Handleresumeevent " Sebastian Herbszt
2008-11-02 18:39 ` Gleb Natapov
2008-11-02 16:31 ` [Qemu-devel] Re: [Bochs-developers] [PATCH 2/6] Add S3 state to DSDT. Handle resumeevent " Kevin O'Connor
2008-11-02 23:28 ` [Qemu-devel] Re: [Bochs-developers] [PATCH 2/6] Add S3 state to DSDT. Handleresumeevent " Sebastian Herbszt
2008-11-03 0:03 ` Kevin O'Connor
2008-10-27 10:13 ` [Qemu-devel] [PATCH 3/6] Disable init of SMM Gleb Natapov
2008-10-27 10:13 ` [Qemu-devel] [PATCH 4/6] Execute rombios32 code from rom address 0xe0000 Gleb Natapov
2008-10-27 10:13 ` [Qemu-devel] [PATCH 5/6] Don't use unreserved memory in BIOS Gleb Natapov
2008-10-30 23:12 ` [Qemu-devel] Re: [Bochs-developers] " Sebastian Herbszt
2008-11-02 10:06 ` Gleb Natapov
2008-11-02 23:44 ` [Qemu-devel] Re: [Bochs-developers] [PATCH 5/6] Don't use unreserved memory inBIOS Sebastian Herbszt
2008-11-03 6:29 ` Gleb Natapov
2008-10-27 10:13 ` [Qemu-devel] [PATCH 6/6] Don't power down vga card on entering S3 state Gleb Natapov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081102100432.GB16809@redhat.com \
--to=gleb@redhat.com \
--cc=bochs-developers@lists.sourceforge.net \
--cc=herbszt@gmx.de \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.