Junk SDT referenced from RSDT in VMWare

[max]

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

[SpyderTL]

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.

[max]

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.

[embryo]

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).

[max]

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

[SpyderTL]

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?

[max]

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.

[xenos]

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

[max]

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.

[seuti]

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.