OSDev.org

Posted: **Thu Oct 09, 2014 5:45 am**

Heyho

I've decided to add multiprocessor support to Ghost. So I wrote parsers for the ACPI tables to get the required APIC information. I'm doing it all as said in the specification, use the XSDT when available (and in 32bit range), otherwise the RSDT. This works fine in QEMU, VirtualBox and Bochs, but the XSDT in VMWare for some reason contains a pointer to a structure that seems very bogus:

Code: Select all

[rsdplookup] base part of RSDP is valid
[rsdplookup] extended part of RSDP is valid
[rsdplookup] found valid pointer: oemId: 'PTLTD ', acpiVersion: 3.0
      [acpi] found XSDT in 32bit range
      [acpi] root table starts at phys 0x5A6F0804
      [acpi] SDT: 'XSDT' (phys 0x5A6F0804)
                oemId: 'INTEL ', oemTableId: '440BX   '
                revision: 0x00000001, creatorId: 0x20574D56
                creatorRevision: 0x01324272
                length: 0x0000004C, checksum: 0x00000039
      [acpi] is available
      [acpi] SDT: 'FACP' (phys 0x5A6FEE98)
                oemId: 'INTEL ', oemTableId: '440BX   '
                revision: 0x00000004, creatorId: 0x204C5450
                creatorRevision: 0x000F4240
                length: 0x000000F4, checksum: 0x000000AA
      [acpi] SDT: 'ij(DC4)(SO)' (phys 0x5A6F0994)
                oemId: 'PTLTD ', oemTableId: '$SBFTBL$'
                revision: 0x00000001, creatorId: 0x50544C20
                creatorRevision: 0x00000001
                length: 0x00000028, checksum: 0x000000A5
      [acpi] SDT: 'APIC' (phys 0x5A6F0944)
                oemId: 'PTLTD ', oemTableId: '	 APIC  '
                revision: 0x00000001, creatorId: 0x50544C20
                creatorRevision: 0x00000000
                length: 0x00000050, checksum: 0x00000073
      [acpi] multiple APIC descriptor table found
      [madt] listing entries in MADT:
              lapic, id: 0, processorId: 0
              ioapic, id: 1, address: 0xFEC00000
              interrupt source overdrive, irqSource: 0, busSource: 0
      [madt] device of unknown type 4 in MADT

The second SDT that is found in the XSDT has a weird signature (its 4 chars, the "DC4" and "SO" chars can't be displayed here). Worse is that it sometimes contains a length thats not possible, like 0x4423FA42.

Can this really happen/is this "normal"?? I'm near to 100% sure that I don't write values to these physical pages (my PPA never even gave these pages out)..

EDIT: I am a 100% sure that I don't write anything to these physical pages accidentally, because GRUB reports them to me as not usable and therefore I don't make them accessible to my PPA.

Any ideas would be great.
Thanks in advance

Greets, Max

Posted: **Thu Oct 09, 2014 6:50 am**

I believe that is the "BOOT" table. It should have a signature of "BOOT". I'm not sure why you are getting those chars though. But everything else looks correct compared to my "BOOT" table.

You could test it out by just checking the signature at that address at the start of your boot loader...

Also I think you can safely display the Creator ID as an ASCII string.

Posted: **Thu Oct 09, 2014 7:33 am**

myself wrote:Man-oh-man, nevermind, I'm a drunken banana
gave wrong values to my printf
So ashamed
/thread

Hm no, it was not; the signature output was actually wrong. But there is still junk in the length field. The weird thing is that it happens only on every n-th boot. I'll have a check whats in there right after the start.

EDIT: Okay. What the hell. This code:

Code: Select all

Logger_infoln("1. access: %h", ((ACPISDTHeader* )(address))->length);
Logger_infoln("2. access: %h", ((ACPISDTHeader* )(address))->length);

Gives me the output:

Code: Select all

1. access: 0x4154535F
2. access: 0x00000028

This must have to do with the TLB. There is no code running in parallel.

Posted: **Fri Oct 10, 2014 4:03 am**

max wrote:Any ideas would be great.

Here was a thread, where ACPI correctness was discussed. The idea is the correctness can be compromised by system vendors. The suggested ways to circumvent the problem were to use reference implementation ACPI parser or to include as much correctness checking as possible (and some means to recover if something incorrect is found).

Posted: **Fri Oct 10, 2014 4:28 am**

embryo wrote:Here was a thread, where ACPI correctness was discussed. The idea is the correctness can be compromised by system vendors. The suggested ways to circumvent the problem were to use reference implementation ACPI parser or to include as much correctness checking as possible (and some means to recover if something incorrect is found).

I don't want to use an existing implementation, that wouldn't be fun. I do already check correctness, and simply ignore tables that fail in either the length or the validity check. I just wonder if someone else has encountered similar issues with VMWare

Posted: **Fri Oct 10, 2014 6:52 am**

Based on your test code above getting different values from the same address back to back, I would think that this would happen for the other tables as well... And maybe even other addresses. Is this problem happening anywhere else?

Posted: **Fri Oct 10, 2014 7:03 am**

SpyderTL wrote:Based on your test code above getting different values from the same address back to back, I would think that this would happen for the other tables as well... And maybe even other addresses. Is this problem happening anywhere else?

No, this never happened anywhere else ever, seriously.. All the other tables contain correct information, but every n-th boot the table is corrupted. But as I said, only in VMWare. Once I even got this:

Da-fuq.

Posted: **Fri Oct 10, 2014 7:16 am**

Strange - which VMWare version are you using? I never had any problem like this. (Currently VMWare 6.0.2, Ubuntu 14.04)

Posted: **Fri Oct 10, 2014 8:22 am**

XenOS wrote:Strange - which VMWare version are you using? I never had any problem like this. (Currently VMWare 6.0.2, Ubuntu 14.04)

7.1.6 on Windows. Need to check this with a different version.

Posted: **Fri Oct 10, 2014 8:46 am**

max wrote:
XenOS wrote:Strange - which VMWare version are you using? I never had any problem like this. (Currently VMWare 6.0.2, Ubuntu 14.04)
7.1.6 on Windows. Need to check this with a different version.

I have VMware Workstation 10.0.1 (build 1379776) if you need someone to test it on another version.

OSDev.org

Junk SDT referenced from RSDT in VMWare

Junk SDT referenced from RSDT in VMWare

Re: Junk SDT referenced from RSDT in VMWare

Re: Junk SDT referenced from RSDT in VMWare

Re: Junk SDT referenced from RSDT in VMWare

Re: Junk SDT referenced from RSDT in VMWare

Re: Junk SDT referenced from RSDT in VMWare

Re: Junk SDT referenced from RSDT in VMWare

Re: Junk SDT referenced from RSDT in VMWare

Re: Junk SDT referenced from RSDT in VMWare

Re: Junk SDT referenced from RSDT in VMWare