[Qemu-devel] [Patch] Small fix for qemu APIC for Mac OS X support

[Qemu-devel] [Patch] Small fix for qemu APIC for Mac OS X support

[adq]

This patch ups the APIC version from 0x11 to 0x14. After that Mac OS X
loads successfully (with appropriate kexts, applesmc ain't hooked up
properly yet I see unfortunately).

According to to the Intel IA-32 Software Developers Manual Vol 3 page
290, the version should be 0x14 Pentium 4/Xeon CPUs anyway.

Signed-off-by: Andrew de Quincey <adq@lidskialf.net>

diff --git a/hw/apic.c b/hw/apic.c
index 5f4a87c..20304e0 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -704,7 +704,7 @@ static uint32_t apic_mem_readl(void *opaque,
target_phys_addr_t addr)
         val = s->id << 24;
         break;
     case 0x03: /* version */
-        val = 0x11 | ((APIC_LVT_NB - 1) << 16); /* version 0x11 */
+        val = 0x14 | ((APIC_LVT_NB - 1) << 16); /* version 0x14 */
         break;
     case 0x08:
         val = s->tpr;

Re: [Qemu-devel] [Patch] Small fix for qemu APIC for Mac OS X support

[Alexander Graf]

On 23.11.2010, at 22:25, adq wrote:

> This patch ups the APIC version from 0x11 to 0x14. After that Mac OS X
> loads successfully (with appropriate kexts, applesmc ain't hooked up
> properly yet I see unfortunately).

AppleSMC emulation is upstream, but the ACPI entries are missing. Once you add those, all is fine.

> According to to the Intel IA-32 Software Developers Manual Vol 3 page
> 290, the version should be 0x14 Pentium 4/Xeon CPUs anyway.
> 
> Signed-off-by: Andrew de Quincey <adq@lidskialf.net>
> 
> diff --git a/hw/apic.c b/hw/apic.c
> index 5f4a87c..20304e0 100644
> --- a/hw/apic.c
> +++ b/hw/apic.c
> @@ -704,7 +704,7 @@ static uint32_t apic_mem_readl(void *opaque,
> target_phys_addr_t addr)
>         val = s->id << 24;
>         break;
>     case 0x03: /* version */
> -        val = 0x11 | ((APIC_LVT_NB - 1) << 16); /* version 0x11 */
> +        val = 0x14 | ((APIC_LVT_NB - 1) << 16); /* version 0x14 */

What exactly changed between the versions? Did new registers get introduced or subtle behavior change? Is there some proper documentation on the changed between the apic versions?


Alex

Re: [Qemu-devel] [Patch] Small fix for qemu APIC for Mac OS X support

[adq]

On 23 November 2010 23:41, Alexander Graf <agraf@suse.de> wrote:
>
> On 23.11.2010, at 22:25, adq wrote:
>
>> This patch ups the APIC version from 0x11 to 0x14. After that Mac OS X
>> loads successfully (with appropriate kexts, applesmc ain't hooked up
>> properly yet I see unfortunately).
>)
> AppleSMC emulation is upstream, but the ACPI entries are missing. Once you add those, all is fine.

Ah yeah, I've just this minute added the DSDT entry from your patch
for the SMC device and it now works with the vanilla SMC driver. Nice
work!

It *is* annoying that IASL now erroneously(?) complains about the
hypen in "Name (_CID, "smc-napa")" though.

Adding the HPET DSDT data causes it  to claim it can't support the
hardware (and a zillion more DSDT errors); I'll have a play about with
that (perhaps its just the new DSDT validation stuff)..

I'm assuming we'll eventually be able to use the upcoming AHCI support
instead of adding ICH drivers or hacking the PIIX kext's plist (I'm
doing the latter).

Note: the boot loader from your site unfortunately didn't work with SL
- its just hangs loading the kernel. I'm successfully using the latest
"boot" file extracted from Chameleon and supplying it to qemu with a
"-kernel" parameter.

>> According to to the Intel IA-32 Software Developers Manual Vol 3 page
>> 290, the version should be 0x14 Pentium 4/Xeon CPUs anyway.
>>
>> Signed-off-by: Andrew de Quincey <adq@lidskialf.net>
>>
>> diff --git a/hw/apic.c b/hw/apic.c
>> index 5f4a87c..20304e0 100644
>> --- a/hw/apic.c
>> +++ b/hw/apic.c
>> @@ -704,7 +704,7 @@ static uint32_t apic_mem_readl(void *opaque,
>> target_phys_addr_t addr)
>>         val = s->id << 24;
>>         break;
>>     case 0x03: /* version */
>> -        val = 0x11 | ((APIC_LVT_NB - 1) << 16); /* version 0x11 */
>> +        val = 0x14 | ((APIC_LVT_NB - 1) << 16); /* version 0x14 */
>
> What exactly changed between the versions? Did new registers get introduced or subtle behavior change? Is there some proper documentation on the changed between the apic versions?

I've been trying to find out; I'm still searching intel's docs to find
an 0x11 version to compare with :(

The failure mode is that mac os X SL whines about the APIC being an
unexpected version (0x11) and it wants 0x14 as a minimum.

Re: [Qemu-devel] [Patch] Small fix for qemu APIC for Mac OS X support

[Alexander Graf]

On 24.11.2010, at 03:40, adq wrote:

> On 23 November 2010 23:41, Alexander Graf <agraf@suse.de> wrote:
>> 
>> On 23.11.2010, at 22:25, adq wrote:
>> 
>>> This patch ups the APIC version from 0x11 to 0x14. After that Mac OS X
>>> loads successfully (with appropriate kexts, applesmc ain't hooked up
>>> properly yet I see unfortunately).
>> )
>> AppleSMC emulation is upstream, but the ACPI entries are missing. Once you add those, all is fine.
> 
> Ah yeah, I've just this minute added the DSDT entry from your patch
> for the SMC device and it now works with the vanilla SMC driver. Nice
> work!
> 
> It *is* annoying that IASL now erroneously(?) complains about the
> hypen in "Name (_CID, "smc-napa")" though.
> 
> Adding the HPET DSDT data causes it  to claim it can't support the
> hardware (and a zillion more DSDT errors); I'll have a play about with
> that (perhaps its just the new DSDT validation stuff)..

Interesting. I was also thinking that maybe we can leverage overriding mechanisms that are already available. Maybe it's possible to squeeze the HPET node into an SSDT. Maybe we need to override the whole DSDT from the command line.

> I'm assuming we'll eventually be able to use the upcoming AHCI support
> instead of adding ICH drivers or hacking the PIIX kext's plist (I'm
> doing the latter).

That's the goal :). I haven't even tried to use it with osx yet though. If you feel adventurous, I'd love to hear if it works.

> Note: the boot loader from your site unfortunately didn't work with SL
> - its just hangs loading the kernel. I'm successfully using the latest
> "boot" file extracted from Chameleon and supplying it to qemu with a
> "-kernel" parameter.

Yeah, I think I do have a version that loads SL successfully somewhere local back from the days when it wasn't released yet. But if recent Chmeleon can load it just fine, it's probably the way forward to just use that and rip out all the illegal and ugly parts.

> 
>>> According to to the Intel IA-32 Software Developers Manual Vol 3 page
>>> 290, the version should be 0x14 Pentium 4/Xeon CPUs anyway.
>>> 
>>> Signed-off-by: Andrew de Quincey <adq@lidskialf.net>
>>> 
>>> diff --git a/hw/apic.c b/hw/apic.c
>>> index 5f4a87c..20304e0 100644
>>> --- a/hw/apic.c
>>> +++ b/hw/apic.c
>>> @@ -704,7 +704,7 @@ static uint32_t apic_mem_readl(void *opaque,
>>> target_phys_addr_t addr)
>>>         val = s->id << 24;
>>>         break;
>>>     case 0x03: /* version */
>>> -        val = 0x11 | ((APIC_LVT_NB - 1) << 16); /* version 0x11 */
>>> +        val = 0x14 | ((APIC_LVT_NB - 1) << 16); /* version 0x14 */
>> 
>> What exactly changed between the versions? Did new registers get introduced or subtle behavior change? Is there some proper documentation on the changed between the apic versions?
> 
> I've been trying to find out; I'm still searching intel's docs to find
> an 0x11 version to compare with :(

Please try very hard. I haven't found anything myself either yet, but without a spec it's hard to justify these changes upstream :(.

> The failure mode is that mac os X SL whines about the APIC being an
> unexpected version (0x11) and it wants 0x14 as a minimum.

Yup, I remember that issue. To really make this all useful, we also need to change the numbers in KVM though.


Alex

Re: [Qemu-devel] [Patch] Small fix for qemu APIC for Mac OS X support

[adq]

On 24 November 2010 11:00, Alexander Graf <agraf@suse.de> wrote:
>
> On 24.11.2010, at 03:40, adq wrote:
>
>> On 23 November 2010 23:41, Alexander Graf <agraf@suse.de> wrote:
>>>
>>> On 23.11.2010, at 22:25, adq wrote:
>>>
>>>> This patch ups the APIC version from 0x11 to 0x14. After that Mac OS X
>>>> loads successfully (with appropriate kexts, applesmc ain't hooked up
>>>> properly yet I see unfortunately).
>>> )
>>> AppleSMC emulation is upstream, but the ACPI entries are missing. Once you add those, all is fine.
>>
>> Ah yeah, I've just this minute added the DSDT entry from your patch
>> for the SMC device and it now works with the vanilla SMC driver. Nice
>> work!
>>
>> It *is* annoying that IASL now erroneously(?) complains about the
>> hypen in "Name (_CID, "smc-napa")" though.
>>
>> Adding the HPET DSDT data causes it  to claim it can't support the
>> hardware (and a zillion more DSDT errors); I'll have a play about with
>> that (perhaps its just the new DSDT validation stuff)..
>
> Interesting. I was also thinking that maybe we can leverage overriding mechanisms that are already available. Maybe it's possible to squeeze the HPET node into an SSDT. Maybe we need to override the whole DSDT from the command line.

We'll definitely need to override the DSDT for the applesmc device. I
was thinking something along the lines of an additional DSDT binary
supplied with QEMU for use when emulating apple hardware as you
suggest.


>> I'm assuming we'll eventually be able to use the upcoming AHCI support
>> instead of adding ICH drivers or hacking the PIIX kext's plist (I'm
>> doing the latter).
>
> That's the goal :). I haven't even tried to use it with osx yet though. If you feel adventurous, I'd love to hear if it works.
>
>> Note: the boot loader from your site unfortunately didn't work with SL
>> - its just hangs loading the kernel. I'm successfully using the latest
>> "boot" file extracted from Chameleon and supplying it to qemu with a
>> "-kernel" parameter.
>
> Yeah, I think I do have a version that loads SL successfully somewhere local back from the days when it wasn't released yet. But if recent Chmeleon can load it just fine, it's probably the way forward to just use that and rip out all the illegal and ugly parts.
>
>>
>>>> According to to the Intel IA-32 Software Developers Manual Vol 3 page
>>>> 290, the version should be 0x14 Pentium 4/Xeon CPUs anyway.
>>>>
>>>> Signed-off-by: Andrew de Quincey <adq@lidskialf.net>
>>>>
>>>> diff --git a/hw/apic.c b/hw/apic.c
>>>> index 5f4a87c..20304e0 100644
>>>> --- a/hw/apic.c
>>>> +++ b/hw/apic.c
>>>> @@ -704,7 +704,7 @@ static uint32_t apic_mem_readl(void *opaque,
>>>> target_phys_addr_t addr)
>>>>         val = s->id << 24;
>>>>         break;
>>>>     case 0x03: /* version */
>>>> -        val = 0x11 | ((APIC_LVT_NB - 1) << 16); /* version 0x11 */
>>>> +        val = 0x14 | ((APIC_LVT_NB - 1) << 16); /* version 0x14 */
>>>
>>> What exactly changed between the versions? Did new registers get introduced or subtle behavior change? Is there some proper documentation on the changed between the apic versions?
>>
>> I've been trying to find out; I'm still searching intel's docs to find
>> an 0x11 version to compare with :(
>
> Please try very hard. I haven't found anything myself either yet, but without a spec it's hard to justify these changes upstream :(.
>
>> The failure mode is that mac os X SL whines about the APIC being an
>> unexpected version (0x11) and it wants 0x14 as a minimum.
>
> Yup, I remember that issue. To really make this all useful, we also need to change the numbers in KVM though.

Hi, I /think/ the 0x11 APIC version might be from the pentium pro era.
However the only proof is this random dmesg trace I found at:
http://www.sfires.net/evil/dmesg.txt
"Processor #6 Pentium(tm) Pro APIC version 17"

The Pentium Pro software manual vol 3 can be found here:
http://www.biblio.deis.unibo.it/Testi_Liberi/Pentiumpro/PentiumPro_Vol3.pdf

I've not had time to look at the registers contents in detail yet, but
there are definitely a few new registers in the latest arch software
manual from Intel.


Incidentally, I just tried updating a VM to SL 10.6.5; it can boot
darwin fine, but doesn't start the macosx GUI. Its the same behaviour
as if the applesmc device is not present. It /does/ say "DSMOS has
arrived", but there are a few other SMC-comms errors reported.

Re: [Qemu-devel] [Patch] Small fix for qemu APIC for Mac OS X support

[Isaku Yamahata]

On Wed, Nov 24, 2010 at 02:08:16PM +0000, adq wrote:
> > Interesting. I was also thinking that maybe we can leverage overriding mechanisms that are already available. Maybe it's possible to squeeze the HPET node into an SSDT. Maybe we need to override the whole DSDT from the command line.
> 
> We'll definitely need to override the DSDT for the applesmc device. I
> was thinking something along the lines of an additional DSDT binary
> supplied with QEMU for use when emulating apple hardware as you
> suggest.

The patches for qemu and seabios have been floating around.
I wrote them for Q35 chipset support, but no one has gotten interested in it.
But now, you are there. I'm willing to rebase/resend them.
-- 
yamahata

Re: [Qemu-devel] [Patch] Small fix for qemu APIC for Mac OS X support

[adq]

On 25 November 2010 11:28, Isaku Yamahata <yamahata@valinux.co.jp> wrote:
> On Wed, Nov 24, 2010 at 02:08:16PM +0000, adq wrote:
>> > Interesting. I was also thinking that maybe we can leverage overriding mechanisms that are already available. Maybe it's possible to squeeze the HPET node into an SSDT. Maybe we need to override the whole DSDT from the command line.
>>
>> We'll definitely need to override the DSDT for the applesmc device. I
>> was thinking something along the lines of an additional DSDT binary
>> supplied with QEMU for use when emulating apple hardware as you
>> suggest.
>
> The patches for qemu and seabios have been floating around.
> I wrote them for Q35 chipset support, but no one has gotten interested in it.
> But now, you are there. I'm willing to rebase/resend them.

I'd definitely be interested to see those!

Re: [Qemu-devel] [Patch] Small fix for qemu APIC for Mac OS X support

[Isaku Yamahata]

On Thu, Nov 25, 2010 at 08:18:45PM +0000, adq wrote:
> On 25 November 2010 11:28, Isaku Yamahata <yamahata@valinux.co.jp> wrote:
> > On Wed, Nov 24, 2010 at 02:08:16PM +0000, adq wrote:
> >> > Interesting. I was also thinking that maybe we can leverage overriding mechanisms that are already available. Maybe it's possible to squeeze the HPET node into an SSDT. Maybe we need to override the whole DSDT from the command line.
> >>
> >> We'll definitely need to override the DSDT for the applesmc device. I
> >> was thinking something along the lines of an additional DSDT binary
> >> supplied with QEMU for use when emulating apple hardware as you
> >> suggest.
> >
> > The patches for qemu and seabios have been floating around.
> > I wrote them for Q35 chipset support, but no one has gotten interested in it.
> > But now, you are there. I'm willing to rebase/resend them.
> 
> I'd definitely be interested to see those!

Here is qemu part. I rebased and just compiled it.

>From df45b74ca7217d40981cd8895fb1b270fb8039ec Mon Sep 17 00:00:00 2001
Message-Id: <df45b74ca7217d40981cd8895fb1b270fb8039ec.1290775119.git.yamahata@valinux.co.jp>
In-Reply-To: <cover.1290775119.git.yamahata@valinux.co.jp>
References: <cover.1290775119.git.yamahata@valinux.co.jp>
From: Isaku Yamahata <yamahata@valinux.co.jp>
Date: Fri, 26 Nov 2010 21:25:26 +0900
Subject: [PATCH 1/1] acpi: add option, load_header, for -acpitable to load acpi header

This patch adds load_header option to -acpitable to load acpi
table which includes acpi header.
With this option and with seabios patches, alternative dsdt table
can be passed to BIOS.

Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
---
 hw/acpi.c       |   26 +++++++++++++++++++++++---
 qemu-options.hx |    2 ++
 2 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/hw/acpi.c b/hw/acpi.c
index 8071e7b..fe9bede 100644
--- a/hw/acpi.c
+++ b/hw/acpi.c
@@ -47,6 +47,7 @@ static int acpi_checksum(const uint8_t *data, int len)
 int acpi_table_add(const char *t)
 {
     static const char *dfl_id = "QEMUQEMU";
+    bool load_header = false;
     char buf[1024], *p, *f;
     struct acpi_table_header acpi_hdr;
     unsigned long val;
@@ -54,6 +55,17 @@ int acpi_table_add(const char *t)
     struct acpi_table_header *acpi_hdr_p;
     size_t off;
 
+    if (strncmp(t, "load_header", strlen("load_header")) == 0) {
+        /* the files includes acpi header to load.
+         * the acpi header options, sig, rev, ... will be ignored.
+         */
+        load_header = true;
+        t += strlen("load_header");
+        if (*t == ',') {
+            t++;
+        }
+    }
+
     memset(&acpi_hdr, 0, sizeof(acpi_hdr));
   
     if (get_param_value(buf, sizeof(buf), "sig", t)) {
@@ -110,7 +122,11 @@ int acpi_table_add(const char *t)
          buf[0] = '\0';
     }
 
-    length = sizeof(acpi_hdr);
+    if (load_header) {
+        length = 0;
+    } else {
+        length = sizeof(acpi_hdr);
+    }
 
     f = buf;
     while (buf[0]) {
@@ -140,8 +156,12 @@ int acpi_table_add(const char *t)
 
     *(uint16_t*)p = cpu_to_le32(length);
     p += sizeof(uint16_t);
-    memcpy(p, &acpi_hdr, sizeof(acpi_hdr));
-    off = sizeof(acpi_hdr);
+    if (load_header) {
+        off = 0;
+    } else {
+        off = sizeof(acpi_hdr);
+        memcpy(p, &acpi_hdr, sizeof(acpi_hdr));
+    }
 
     f = buf;
     while (buf[0]) {
diff --git a/qemu-options.hx b/qemu-options.hx
index 4d99a58..c30eb2a 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -981,9 +981,11 @@ ETEXI
 
 DEF("acpitable", HAS_ARG, QEMU_OPTION_acpitable,
     "-acpitable [sig=str][,rev=n][,oem_id=str][,oem_table_id=str][,oem_rev=n][,asl_compiler_id=str][,asl_compiler_rev=n][,data=file1[:file2]...]\n"
+    "-acpitable [load_header][,data=file1[:file2]...]\n"
     "                ACPI table description\n", QEMU_ARCH_I386)
 STEXI
 @item -acpitable [sig=@var{str}][,rev=@var{n}][,oem_id=@var{str}][,oem_table_id=@var{str}][,oem_rev=@var{n}] [,asl_compiler_id=@var{str}][,asl_compiler_rev=@var{n}][,data=@var{file1}[:@var{file2}]...]
+@item -acpitable [load_header][,data=@var{file1}[:@var{file2}]...]
 @findex -acpitable
 Add ACPI table with specified header fields and context from specified files.
 ETEXI
-- 
1.7.1.1



-- 
yamahata

Re: [Qemu-devel] [Patch] Small fix for qemu APIC for Mac OS X support

[Isaku Yamahata]

On Thu, Nov 25, 2010 at 08:18:45PM +0000, adq wrote:
> On 25 November 2010 11:28, Isaku Yamahata <yamahata@valinux.co.jp> wrote:
> > On Wed, Nov 24, 2010 at 02:08:16PM +0000, adq wrote:
> >> > Interesting. I was also thinking that maybe we can leverage overriding mechanisms that are already available. Maybe it's possible to squeeze the HPET node into an SSDT. Maybe we need to override the whole DSDT from the command line.
> >>
> >> We'll definitely need to override the DSDT for the applesmc device. I
> >> was thinking something along the lines of an additional DSDT binary
> >> supplied with QEMU for use when emulating apple hardware as you
> >> suggest.
> >
> > The patches for qemu and seabios have been floating around.
> > I wrote them for Q35 chipset support, but no one has gotten interested in it.
> > But now, you are there. I'm willing to rebase/resend them.
> 
> I'd definitely be interested to see those!

Here is seabios part.

>From 7a6e97b74bc0d25aca42a43cabcc68836edaf6c0 Mon Sep 17 00:00:00 2001
Message-Id: <7a6e97b74bc0d25aca42a43cabcc68836edaf6c0.1290774988.git.yamahata@valinux.co.jp>
In-Reply-To: <cover.1290774988.git.yamahata@valinux.co.jp>
References: <cover.1290774988.git.yamahata@valinux.co.jp>
From: Isaku Yamahata <yamahata@valinux.co.jp>
Date: Tue, 15 Jun 2010 12:41:13 +0900
Subject: [PATCH 1/1] seabios: acpi: allow qemu to load dsdt as external acpi table.

allow qemu to load dsdt as external acpi table.

Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>

---
changes v1 -> v2.
- load qemu table first and they try default dsdt table if
  qemu doesn't supply dsdt.
  Thus unnecessary malloc_high()/free() is avoided.
---
 src/acpi.c |   44 ++++++++++++++++++++++++++++++++++++--------
 1 files changed, 36 insertions(+), 8 deletions(-)

diff --git a/src/acpi.c b/src/acpi.c
index 18830dc..f4e0780 100644
--- a/src/acpi.c
+++ b/src/acpi.c
@@ -54,6 +54,11 @@ struct facs_descriptor_rev1
 
 
 /*
+ * Differentiated System Descrition Table (DSDT)
+ */
+#define DSDT_SIGNATURE 0x54445344 // DSDT
+
+/*
  * MADT values and structures
  */
 
@@ -221,14 +226,20 @@ static const struct pci_device_id fadt_init_tbl[] = {
     PCI_DEVICE_END
 };
 
+static void fill_dsdt(struct fadt_descriptor_rev1 *fadt, void *dsdt)
+{
+    fadt->dsdt = cpu_to_le32((u32)dsdt);
+    fadt->checksum -= checksum(fadt, sizeof(*fadt));
+    dprintf(1, "ACPI DSDT=%p\n", dsdt);
+}
+
 static void*
 build_fadt(int bdf)
 {
     struct fadt_descriptor_rev1 *fadt = malloc_high(sizeof(*fadt));
     struct facs_descriptor_rev1 *facs = memalign_high(64, sizeof(*facs));
-    void *dsdt = malloc_high(sizeof(AmlCode));
 
-    if (!fadt || !facs || !dsdt) {
+    if (!fadt || !facs) {
         warn_noalloc();
         return NULL;
     }
@@ -238,13 +249,11 @@ build_fadt(int bdf)
     facs->signature = FACS_SIGNATURE;
     facs->length = cpu_to_le32(sizeof(*facs));
 
-    /* DSDT */
-    memcpy(dsdt, AmlCode, sizeof(AmlCode));
-
     /* FADT */
     memset(fadt, 0, sizeof(*fadt));
     fadt->firmware_ctrl = cpu_to_le32((u32)facs);
-    fadt->dsdt = cpu_to_le32((u32)dsdt);
+    fadt->dsdt = 0;  /* dsdt will be filled later in acpi_bios_init()
+                        by fill_dsdt() */
     fadt->model = 1;
     fadt->reserved1 = 0;
     int pm_sci_int = pci_config_readb(bdf, PCI_INTERRUPT_LINE);
@@ -620,7 +629,8 @@ acpi_bios_init(void)
     } while(0)
 
     // Add tables
-    ACPI_INIT_TABLE(build_fadt(bdf));
+    struct fadt_descriptor_rev1 *fadt = build_fadt(bdf);
+    ACPI_INIT_TABLE(fadt);
     ACPI_INIT_TABLE(build_ssdt());
     ACPI_INIT_TABLE(build_madt());
     ACPI_INIT_TABLE(build_hpet());
@@ -635,12 +645,30 @@ acpi_bios_init(void)
             warn_noalloc();
             continue;
         }
-        ACPI_INIT_TABLE(qemu_cfg_next_acpi_table_load(addr, len));
+        struct acpi_table_header *header =
+            qemu_cfg_next_acpi_table_load(addr, len);
+        if (header->signature == DSDT_SIGNATURE) {
+            if (fadt) {
+                fill_dsdt(fadt, addr);
+            }
+        } else {
+            ACPI_INIT_TABLE(header);
+        }
         if (tbl_idx == MAX_ACPI_TABLES) {
             warn_noalloc();
             break;
         }
     }
+    if (fadt && !fadt->dsdt) {
+        /* default DSDT */
+        void *dsdt = malloc_high(sizeof(AmlCode));
+        if (!dsdt) {
+            warn_noalloc();
+            return;
+        }
+        memcpy(dsdt, AmlCode, sizeof(AmlCode));
+        fill_dsdt(fadt, dsdt);
+    }
 
     struct rsdt_descriptor_rev1 *rsdt;
     size_t rsdt_len = sizeof(*rsdt) + sizeof(u32) * tbl_idx;
-- 
1.7.1.1



-- 
yamahata

Re: [Qemu-devel] [Patch] Small fix for qemu APIC for Mac OS X support

[adq]

On 26 November 2010 12:40, Isaku Yamahata <yamahata@valinux.co.jp> wrote:
> On Thu, Nov 25, 2010 at 08:18:45PM +0000, adq wrote:
>> On 25 November 2010 11:28, Isaku Yamahata <yamahata@valinux.co.jp> wrote:
>> > On Wed, Nov 24, 2010 at 02:08:16PM +0000, adq wrote:
>> >> > Interesting. I was also thinking that maybe we can leverage overriding mechanisms that are already available. Maybe it's possible to squeeze the HPET node into an SSDT. Maybe we need to override the whole DSDT from the command line.
>> >>
>> >> We'll definitely need to override the DSDT for the applesmc device. I
>> >> was thinking something along the lines of an additional DSDT binary
>> >> supplied with QEMU for use when emulating apple hardware as you
>> >> suggest.
>> >
>> > The patches for qemu and seabios have been floating around.
>> > I wrote them for Q35 chipset support, but no one has gotten interested in it.
>> > But now, you are there. I'm willing to rebase/resend them.
>>
>> I'd definitely be interested to see those!
>
> Here is seabios part.
>
> From 7a6e97b74bc0d25aca42a43cabcc68836edaf6c0 Mon Sep 17 00:00:00 2001
> Message-Id: <7a6e97b74bc0d25aca42a43cabcc68836edaf6c0.1290774988.git.yamahata@valinux.co.jp>
> In-Reply-To: <cover.1290774988.git.yamahata@valinux.co.jp>
> References: <cover.1290774988.git.yamahata@valinux.co.jp>
> From: Isaku Yamahata <yamahata@valinux.co.jp>
> Date: Tue, 15 Jun 2010 12:41:13 +0900
> Subject: [PATCH 1/1] seabios: acpi: allow qemu to load dsdt as external acpi table.
>
> allow qemu to load dsdt as external acpi table.
>
> Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
>
> ---
> changes v1 -> v2.
> - load qemu table first and they try default dsdt table if
>  qemu doesn't supply dsdt.
>  Thus unnecessary malloc_high()/free() is avoided.
> ---
>  src/acpi.c |   44 ++++++++++++++++++++++++++++++++++++--------
>  1 files changed, 36 insertions(+), 8 deletions(-)
>
> diff --git a/src/acpi.c b/src/acpi.c
> index 18830dc..f4e0780 100644
> --- a/src/acpi.c
> +++ b/src/acpi.c
> @@ -54,6 +54,11 @@ struct facs_descriptor_rev1
>
>
>  /*
> + * Differentiated System Descrition Table (DSDT)
> + */
> +#define DSDT_SIGNATURE 0x54445344 // DSDT
> +
> +/*
>  * MADT values and structures
>  */
>
> @@ -221,14 +226,20 @@ static const struct pci_device_id fadt_init_tbl[] = {
>     PCI_DEVICE_END
>  };
>
> +static void fill_dsdt(struct fadt_descriptor_rev1 *fadt, void *dsdt)
> +{
> +    fadt->dsdt = cpu_to_le32((u32)dsdt);
> +    fadt->checksum -= checksum(fadt, sizeof(*fadt));
> +    dprintf(1, "ACPI DSDT=%p\n", dsdt);
> +}
> +
>  static void*
>  build_fadt(int bdf)
>  {
>     struct fadt_descriptor_rev1 *fadt = malloc_high(sizeof(*fadt));
>     struct facs_descriptor_rev1 *facs = memalign_high(64, sizeof(*facs));
> -    void *dsdt = malloc_high(sizeof(AmlCode));
>
> -    if (!fadt || !facs || !dsdt) {
> +    if (!fadt || !facs) {
>         warn_noalloc();
>         return NULL;
>     }
> @@ -238,13 +249,11 @@ build_fadt(int bdf)
>     facs->signature = FACS_SIGNATURE;
>     facs->length = cpu_to_le32(sizeof(*facs));
>
> -    /* DSDT */
> -    memcpy(dsdt, AmlCode, sizeof(AmlCode));
> -
>     /* FADT */
>     memset(fadt, 0, sizeof(*fadt));
>     fadt->firmware_ctrl = cpu_to_le32((u32)facs);
> -    fadt->dsdt = cpu_to_le32((u32)dsdt);
> +    fadt->dsdt = 0;  /* dsdt will be filled later in acpi_bios_init()
> +                        by fill_dsdt() */
>     fadt->model = 1;
>     fadt->reserved1 = 0;
>     int pm_sci_int = pci_config_readb(bdf, PCI_INTERRUPT_LINE);
> @@ -620,7 +629,8 @@ acpi_bios_init(void)
>     } while(0)
>
>     // Add tables
> -    ACPI_INIT_TABLE(build_fadt(bdf));
> +    struct fadt_descriptor_rev1 *fadt = build_fadt(bdf);
> +    ACPI_INIT_TABLE(fadt);
>     ACPI_INIT_TABLE(build_ssdt());
>     ACPI_INIT_TABLE(build_madt());
>     ACPI_INIT_TABLE(build_hpet());
> @@ -635,12 +645,30 @@ acpi_bios_init(void)
>             warn_noalloc();
>             continue;
>         }
> -        ACPI_INIT_TABLE(qemu_cfg_next_acpi_table_load(addr, len));
> +        struct acpi_table_header *header =
> +            qemu_cfg_next_acpi_table_load(addr, len);
> +        if (header->signature == DSDT_SIGNATURE) {
> +            if (fadt) {
> +                fill_dsdt(fadt, addr);
> +            }
> +        } else {
> +            ACPI_INIT_TABLE(header);
> +        }
>         if (tbl_idx == MAX_ACPI_TABLES) {
>             warn_noalloc();
>             break;
>         }
>     }
> +    if (fadt && !fadt->dsdt) {
> +        /* default DSDT */
> +        void *dsdt = malloc_high(sizeof(AmlCode));
> +        if (!dsdt) {
> +            warn_noalloc();
> +            return;
> +        }
> +        memcpy(dsdt, AmlCode, sizeof(AmlCode));
> +        fill_dsdt(fadt, dsdt);
> +    }
>
>     struct rsdt_descriptor_rev1 *rsdt;
>     size_t rsdt_len = sizeof(*rsdt) + sizeof(u32) * tbl_idx;

Hi, looks great, sorry for the delay in answering, I got caught up
with other things.

I'm currently figuring out why the e1000 doesn't work; I suspect
something is slightly wrong with qemu/macosx's microwire bitbanging
implementation (and I've verified macosx is using microwire) causing
eeprom reads to fail.

Re: [Qemu-devel] [Patch] Small fix for qemu APIC for Mac OS X support

[Andreas Färber]

Am 26.11.2010 um 13:40 schrieb Isaku Yamahata:

> On Thu, Nov 25, 2010 at 08:18:45PM +0000, adq wrote:
>> On 25 November 2010 11:28, Isaku Yamahata <yamahata@valinux.co.jp>  
>> wrote:
>>> On Wed, Nov 24, 2010 at 02:08:16PM +0000, adq wrote:
>>>>> Interesting. I was also thinking that maybe we can leverage  
>>>>> overriding mechanisms that are already available. Maybe it's  
>>>>> possible to squeeze the HPET node into an SSDT. Maybe we need to  
>>>>> override the whole DSDT from the command line.
>>>>
>>>> We'll definitely need to override the DSDT for the applesmc  
>>>> device. I
>>>> was thinking something along the lines of an additional DSDT binary
>>>> supplied with QEMU for use when emulating apple hardware as you
>>>> suggest.
>>>
>>> The patches for qemu and seabios have been floating around.
>>> I wrote them for Q35 chipset support, but no one has gotten  
>>> interested in it.
>>> But now, you are there. I'm willing to rebase/resend them.
>>
>> I'd definitely be interested to see those!
>
> Here is seabios part.
>
> From 7a6e97b74bc0d25aca42a43cabcc68836edaf6c0 Mon Sep 17 00:00:00 2001
> Message-Id: <7a6e97b74bc0d25aca42a43cabcc68836edaf6c0.1290774988.git.yamahata@valinux.co.jp 
> >
> In-Reply-To: <cover.1290774988.git.yamahata@valinux.co.jp>
> References: <cover.1290774988.git.yamahata@valinux.co.jp>
> From: Isaku Yamahata <yamahata@valinux.co.jp>
> Date: Tue, 15 Jun 2010 12:41:13 +0900
> Subject: [PATCH 1/1] seabios: acpi: allow qemu to load dsdt as  
> external acpi table.
>
> allow qemu to load dsdt as external acpi table.
>
> Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
>
> ---
> changes v1 -> v2.
> - load qemu table first and they try default dsdt table if
>  qemu doesn't supply dsdt.
>  Thus unnecessary malloc_high()/free() is avoided.
> ---
> src/acpi.c |   44 ++++++++++++++++++++++++++++++++++++--------
> 1 files changed, 36 insertions(+), 8 deletions(-)
>
> diff --git a/src/acpi.c b/src/acpi.c
> index 18830dc..f4e0780 100644
> --- a/src/acpi.c
> +++ b/src/acpi.c
> @@ -54,6 +54,11 @@ struct facs_descriptor_rev1
>
>
> /*
> + * Differentiated System Descrition Table (DSDT)

Typo: Description

Andreas

[Qemu-devel] Re: [Patch] Small fix for qemu APIC for Mac OS X support

[Jan Kiszka]

Am 24.11.2010 12:00, Alexander Graf wrote:
>>>> According to to the Intel IA-32 Software Developers Manual Vol 3 page
>>>> 290, the version should be 0x14 Pentium 4/Xeon CPUs anyway.
>>>>
>>>> Signed-off-by: Andrew de Quincey <adq@lidskialf.net>
>>>>
>>>> diff --git a/hw/apic.c b/hw/apic.c
>>>> index 5f4a87c..20304e0 100644
>>>> --- a/hw/apic.c
>>>> +++ b/hw/apic.c
>>>> @@ -704,7 +704,7 @@ static uint32_t apic_mem_readl(void *opaque,
>>>> target_phys_addr_t addr)
>>>>         val = s->id << 24;
>>>>         break;
>>>>     case 0x03: /* version */
>>>> -        val = 0x11 | ((APIC_LVT_NB - 1) << 16); /* version 0x11 */
>>>> +        val = 0x14 | ((APIC_LVT_NB - 1) << 16); /* version 0x14 */
>>>
>>> What exactly changed between the versions? Did new registers get introduced or subtle behavior change? Is there some proper documentation on the changed between the apic versions?
>>
>> I've been trying to find out; I'm still searching intel's docs to find
>> an 0x11 version to compare with :(
> 
> Please try very hard. I haven't found anything myself either yet, but without a spec it's hard to justify these changes upstream :(.
> 
>> The failure mode is that mac os X SL whines about the APIC being an
>> unexpected version (0x11) and it wants 0x14 as a minimum.
> 
> Yup, I remember that issue. To really make this all useful, we also need to change the numbers in KVM though.

Also, the version has to be set depending on the emulated CPU (even more
when there will be emulation differences).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

[Qemu-devel] Re: [Patch] Small fix for qemu APIC for Mac OS X support

[adq]

On 25 November 2010 11:46, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> Am 24.11.2010 12:00, Alexander Graf wrote:
>>>>> According to to the Intel IA-32 Software Developers Manual Vol 3 page
>>>>> 290, the version should be 0x14 Pentium 4/Xeon CPUs anyway.
>>>>>
>>>>> Signed-off-by: Andrew de Quincey <adq@lidskialf.net>
>>>>>
>>>>> diff --git a/hw/apic.c b/hw/apic.c
>>>>> index 5f4a87c..20304e0 100644
>>>>> --- a/hw/apic.c
>>>>> +++ b/hw/apic.c
>>>>> @@ -704,7 +704,7 @@ static uint32_t apic_mem_readl(void *opaque,
>>>>> target_phys_addr_t addr)
>>>>>         val = s->id << 24;
>>>>>         break;
>>>>>     case 0x03: /* version */
>>>>> -        val = 0x11 | ((APIC_LVT_NB - 1) << 16); /* version 0x11 */
>>>>> +        val = 0x14 | ((APIC_LVT_NB - 1) << 16); /* version 0x14 */
>>>>
>>>> What exactly changed between the versions? Did new registers get introduced or subtle behavior change? Is there some proper documentation on the changed between the apic versions?
>>>
>>> I've been trying to find out; I'm still searching intel's docs to find
>>> an 0x11 version to compare with :(
>>
>> Please try very hard. I haven't found anything myself either yet, but without a spec it's hard to justify these changes upstream :(.
>>
>>> The failure mode is that mac os X SL whines about the APIC being an
>>> unexpected version (0x11) and it wants 0x14 as a minimum.
>>
>> Yup, I remember that issue. To really make this all useful, we also need to change the numbers in KVM though.
>
> Also, the version has to be set depending on the emulated CPU (even more
> when there will be emulation differences).

Indeed. However, I've just been comparing the two docs (and yes it IS
a huge pain in the bum!).

The differences between the pentium/P6 (0x11 "APIC") and pentium4/xeon
(0x14 "xAPIC") so far are:
* LVT themal sensor 0xfee0330 is new in xAPIC -- this is already
implemented in hw/apic.c
* APIC ID register is 8 bits in xAPIC, 4 bits in APIC (top 4 are
undefined) -- already 8 bit wide in hw/apic.c
* APIC LVT count should be 4 in APIC, 6 in xAPIC -- already hardcoded
to 6 in hw/apic.c
* Spurious interrupt vector should have the lower 4 bits hardcoded to
1 in APIC -- this is not done in hw/apic.c - they're modifable.
* Base address of LAPIC can be changed using an MSR in xAPIC,
suppposedly not possible in APIC - hw/apic.c allows it no matter what.

(I'm still reading)

>From what I can see hw/apic.c already unconditionally supports all the
features of the newer APICs anyway, and any changes are really just
incremental tweaks.

The other major difference between APIC and xAPIC is how they talk to
each other in hardware: APIC has an APIC bus, xAPIC uses the system
bus. I suspect this isn't a concern for emulated hardware though...

[Qemu-devel] Re: [Patch] Small fix for qemu APIC for Mac OS X support

[Alexander Graf]

On 25.11.2010, at 22:03, adq wrote:

> On 25 November 2010 11:46, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>> Am 24.11.2010 12:00, Alexander Graf wrote:
>>>>>> According to to the Intel IA-32 Software Developers Manual Vol 3 page
>>>>>> 290, the version should be 0x14 Pentium 4/Xeon CPUs anyway.
>>>>>> 
>>>>>> Signed-off-by: Andrew de Quincey <adq@lidskialf.net>
>>>>>> 
>>>>>> diff --git a/hw/apic.c b/hw/apic.c
>>>>>> index 5f4a87c..20304e0 100644
>>>>>> --- a/hw/apic.c
>>>>>> +++ b/hw/apic.c
>>>>>> @@ -704,7 +704,7 @@ static uint32_t apic_mem_readl(void *opaque,
>>>>>> target_phys_addr_t addr)
>>>>>>         val = s->id << 24;
>>>>>>         break;
>>>>>>     case 0x03: /* version */
>>>>>> -        val = 0x11 | ((APIC_LVT_NB - 1) << 16); /* version 0x11 */
>>>>>> +        val = 0x14 | ((APIC_LVT_NB - 1) << 16); /* version 0x14 */
>>>>> 
>>>>> What exactly changed between the versions? Did new registers get introduced or subtle behavior change? Is there some proper documentation on the changed between the apic versions?
>>>> 
>>>> I've been trying to find out; I'm still searching intel's docs to find
>>>> an 0x11 version to compare with :(
>>> 
>>> Please try very hard. I haven't found anything myself either yet, but without a spec it's hard to justify these changes upstream :(.
>>> 
>>>> The failure mode is that mac os X SL whines about the APIC being an
>>>> unexpected version (0x11) and it wants 0x14 as a minimum.
>>> 
>>> Yup, I remember that issue. To really make this all useful, we also need to change the numbers in KVM though.
>> 
>> Also, the version has to be set depending on the emulated CPU (even more
>> when there will be emulation differences).
> 
> Indeed. However, I've just been comparing the two docs (and yes it IS
> a huge pain in the bum!).
> 
> The differences between the pentium/P6 (0x11 "APIC") and pentium4/xeon
> (0x14 "xAPIC") so far are:
> * LVT themal sensor 0xfee0330 is new in xAPIC -- this is already
> implemented in hw/apic.c
> * APIC ID register is 8 bits in xAPIC, 4 bits in APIC (top 4 are
> undefined) -- already 8 bit wide in hw/apic.c
> * APIC LVT count should be 4 in APIC, 6 in xAPIC -- already hardcoded
> to 6 in hw/apic.c
> * Spurious interrupt vector should have the lower 4 bits hardcoded to
> 1 in APIC -- this is not done in hw/apic.c - they're modifable.
> * Base address of LAPIC can be changed using an MSR in xAPIC,
> suppposedly not possible in APIC - hw/apic.c allows it no matter what.

Very interesting indeed.

> 
> (I'm still reading)
> 
> From what I can see hw/apic.c already unconditionally supports all the
> features of the newer APICs anyway, and any changes are really just
> incremental tweaks.

Yes, if you can prove that the one we're emulating basically already is an xAPIC and the only difference is the incorrect version, then I'd completely Ack the patch.

> 
> The other major difference between APIC and xAPIC is how they talk to
> each other in hardware: APIC has an APIC bus, xAPIC uses the system
> bus. I suspect this isn't a concern for emulated hardware though...

The internal bus structure doesn't matter to the emulation, no :).


Alex

Re: [Qemu-devel] [Patch] Small fix for qemu APIC for Mac OS X support

[adq]

On 24 November 2010 11:00, Alexander Graf <agraf@suse.de> wrote:
>
> On 24.11.2010, at 03:40, adq wrote:
>
>> On 23 November 2010 23:41, Alexander Graf <agraf@suse.de> wrote:
>>>
>>> On 23.11.2010, at 22:25, adq wrote:
>>>
>>>> This patch ups the APIC version from 0x11 to 0x14. After that Mac OS X
>>>> loads successfully (with appropriate kexts, applesmc ain't hooked up
>>>> properly yet I see unfortunately).
>>> )
>>> AppleSMC emulation is upstream, but the ACPI entries are missing. Once you add those, all is fine.
>>
>> Ah yeah, I've just this minute added the DSDT entry from your patch
>> for the SMC device and it now works with the vanilla SMC driver. Nice
>> work!
>>
>> It *is* annoying that IASL now erroneously(?) complains about the
>> hypen in "Name (_CID, "smc-napa")" though.
>>
>> Adding the HPET DSDT data causes it  to claim it can't support the
>> hardware (and a zillion more DSDT errors); I'll have a play about with
>> that (perhaps its just the new DSDT validation stuff)..
>
> Interesting. I was also thinking that maybe we can leverage overriding mechanisms that are already available. Maybe it's possible to squeeze the HPET node into an SSDT. Maybe we need to override the whole DSDT from the command line.

The HPET issue was actually because the seabios already contained an
HPET definition and mac os X didn't know quite what to do with a CPU
with two APICs :)

I removed the spare HPET def, and it doesn't moan about unsupported
hardware anymore.

However AppleIntelCPUPowerManagement dies with a bad opcode error and
no useful information on why.. I get the impression that worked OK
unmodified with your original suite of patches? Obviously if you
disable the KEXT its no longer a problem, but it would be nice not to
have to.

10.6.5 still doesn't start the GUI though, and I've still no idea why yet.

Also, mac os x reports that an emulated e1000 device has an all-zero
MAC address. I'm going to look into this first since the rtl8139 only
has 32 bit drivers it seems.

Re: [Qemu-devel] [Patch] Small fix for qemu APIC for Mac OS X support

[Alexander Graf]

On 25.11.2010, at 21:24, adq wrote:

> On 24 November 2010 11:00, Alexander Graf <agraf@suse.de> wrote:
>> 
>> On 24.11.2010, at 03:40, adq wrote:
>> 
>>> On 23 November 2010 23:41, Alexander Graf <agraf@suse.de> wrote:
>>>> 
>>>> On 23.11.2010, at 22:25, adq wrote:
>>>> 
>>>>> This patch ups the APIC version from 0x11 to 0x14. After that Mac OS X
>>>>> loads successfully (with appropriate kexts, applesmc ain't hooked up
>>>>> properly yet I see unfortunately).
>>>> )
>>>> AppleSMC emulation is upstream, but the ACPI entries are missing. Once you add those, all is fine.
>>> 
>>> Ah yeah, I've just this minute added the DSDT entry from your patch
>>> for the SMC device and it now works with the vanilla SMC driver. Nice
>>> work!
>>> 
>>> It *is* annoying that IASL now erroneously(?) complains about the
>>> hypen in "Name (_CID, "smc-napa")" though.
>>> 
>>> Adding the HPET DSDT data causes it  to claim it can't support the
>>> hardware (and a zillion more DSDT errors); I'll have a play about with
>>> that (perhaps its just the new DSDT validation stuff)..
>> 
>> Interesting. I was also thinking that maybe we can leverage overriding mechanisms that are already available. Maybe it's possible to squeeze the HPET node into an SSDT. Maybe we need to override the whole DSDT from the command line.
> 
> The HPET issue was actually because the seabios already contained an
> HPET definition and mac os X didn't know quite what to do with a CPU
> with two APICs :)

HPET == APIC? And why would it have two?

> 
> I removed the spare HPET def, and it doesn't moan about unsupported
> hardware anymore.
> 
> However AppleIntelCPUPowerManagement dies with a bad opcode error and
> no useful information on why.. I get the impression that worked OK
> unmodified with your original suite of patches? Obviously if you
> disable the KEXT its no longer a problem, but it would be nice not to
> have to.

Are you using KVM? To have that kext do something reasonable, we need major tweaks in KVM. For simple use cases, ignoring some MSRs should be enough. Qemu ignores unknown MSRs by default.

> 10.6.5 still doesn't start the GUI though, and I've still no idea why yet.

Could be anything really :(. I assume you're already starting with -v? Mac OS X also stores crash dumps somewhere, so you could reboot into single user mode (-s) and check if you can make sense of anything there.

> Also, mac os x reports that an emulated e1000 device has an all-zero
> MAC address. I'm going to look into this first since the rtl8139 only
> has 32 bit drivers it seems.

Yeah, the e1000 didn't work for me either. The rtl8139 back then didn't work 100% because of its broken timer implementation, but there should have been some fixes for that in the meantime. At least for the rtl8139 the driver was published open source on the apple developer web page. Not sure if that's still the case with 10.6.


Alex