Re: [Qemu-devel] OEM Windows in Qemu
On Friday, December 23, 2011, 7:11:08, in...@expertcomputerrepair.com wrote: I think the key is those specific memory addresses I mentioned earlier. That's the exact reason - the strings have to be present in the correct memory region. You can use SLICToolkit (in SLP1.0 tab) to verify if the strings are present at the right address. -- Jernej Simončič http://eternallybored.org/ Nature will tell you a direct lie if she can. -- Darwin's Observation
Re: [Qemu-devel] OEM Windows in Qemu
Jernej Simon?i? jer...@ena.si wrote: That's the exact reason - the strings have to be present in the correct memory region. You can use SLICToolkit (in SLP1.0 tab) to verify if the strings are present at the right address. Alright then, do you know how to modify those values in qemu? Brian
Re: [Qemu-devel] OEM Windows in Qemu
My patch does not produce any SLIC at all. The instructions mentions using SLIC from your machine - my patch is just a way to _embed_ a given data into VM, not a way to produce anything. You get in your VM what you have outside, either in a file or in your own BIOS, depending on where you took that data from. Right, I meant to say simply that it did copy the SLIC in a recognizable form and embed it into the BIOS. Yes, the patch only changes RSDT to match SLIC - this is what win7 verifies, all other tables does not matter for win7. And yes, it might be different for winXP - you may try setting all tables in VM to be of DELL OEM and see what happens. I had high hopes for this, but no joy. All the DMI tables now read Dell Inc but XP refuses to activate. I think the key is those specific memory addresses I mentioned earlier. I tried raw write of Dell Inc into the specified address space, but there are 2 problems with this. First is that the address space already contains data so I overwrote something. Second even then Windows did not activate, I think the activation check only occurs at certain times, probably on boot, so I made my changes after it checked and it didn't check again and so didn't see the changes I made. I need to modify the BIOS to contain the string so it is visible on boot without me having to manually edit it. Is there a way to hardcode the string into a specific memory address when I compile the BIOS? Brian
Re: [Qemu-devel] OEM Windows in Qemu
Why not just buy a non-OEM version ? They are surely not tied to a specific piece of hardware and its licence should allow to run on arbitrary PC HW you happen to want to install/run it on once activated On Fri, Dec 23, 2011 at 5:11 PM, in...@expertcomputerrepair.com wrote: My patch does not produce any SLIC at all. The instructions mentions using SLIC from your machine - my patch is just a way to _embed_ a given data into VM, not a way to produce anything. You get in your VM what you have outside, either in a file or in your own BIOS, depending on where you took that data from. Right, I meant to say simply that it did copy the SLIC in a recognizable form and embed it into the BIOS. Yes, the patch only changes RSDT to match SLIC - this is what win7 verifies, all other tables does not matter for win7. And yes, it might be different for winXP - you may try setting all tables in VM to be of DELL OEM and see what happens. I had high hopes for this, but no joy. All the DMI tables now read Dell Inc but XP refuses to activate. I think the key is those specific memory addresses I mentioned earlier. I tried raw write of Dell Inc into the specified address space, but there are 2 problems with this. First is that the address space already contains data so I overwrote something. Second even then Windows did not activate, I think the activation check only occurs at certain times, probably on boot, so I made my changes after it checked and it didn't check again and so didn't see the changes I made. I need to modify the BIOS to contain the string so it is visible on boot without me having to manually edit it. Is there a way to hardcode the string into a specific memory address when I compile the BIOS? Brian
Re: [Qemu-devel] OEM Windows in Qemu
Michael, Thanks for the response. Since you wrote the patch I'm using I'd say you are the most qualified to answer questions about it. :) Note that for winXP, the only thing needed from the bios is to _mention_ - anywhere in its memory - name of your manufacturer. That is, you can add any table with just a string - say - ASUS_Notebook in it, winXP does an equivalent of memmem() function on the bios content to find if it is supposed to be right OEM. I'm not an expert on this by any means, but what I've read on the net is that Windows looks for some special bytes in RAM that correspond to the OEM manufacturer. Apparently this is set in the OEMBIOS.DAT or .CAT file on the installation cd rom along with the location in memory where it looks for the data. This is an example listing which I've read specifies the RAM addresses, offset, and bytes to look for. DELL (OEMBIOS.CAT CRC32=B6F0EEFD) f000,e076,0010,Dell System f000,e840,0010,Dell Computer f000,49a9,0010,Dell System f000,e05e,0010,Dell System f000,e838,0018,Dell Inc WinXP requires SLIC version 1.0, which is reduced to just having a string with the name of your OEM in the bios (one possible place is the SLIC table). More recent version of SLIC (2.1 I think) is needed to activate windows7. This is the part that is confusing me. I've read that SLIC 2.0 is backward compatible with SLIC 1.0 so XP should activate just fine with a working SLIC 2.0. And your patch does apparently produce a signed SLIC 2.0 But my OEM copy of XP complains about the BIOS produced with your patch. I can only guess there is some critical piece missing that Windows 7 doesn't care about. While I'm the author of the howto you mentioned, so my opinion here is biased, but still I can say that several other people used this way to run oem versions of windows7 and windowsVista in their VMs, and sent me their thanks. I also found this way mentioned in vmware-related forums. You can add my name to the list of people offers thanks for that patch. :) I'm sure I'll want to install Windows 7 at some point also. I've no idea what does these tools do. For testing I just boot linux and check if it can see the tables with the content I've used (somewhere in /sys/firmware/acpi/tables). For further testing I boot my OEM-preinstalled copy of windows to verify it still thinks it is OEM-activated. I also tried to actually activate win7 in a VM, using slic+certificate from a random OEM (these are available on the 'net despite being M$ high-secret), and it worked just fine too. I haven't yet installed a linux VM to check the acpi/tables but here is what is on the host: /* * Intel ACPI Component Architecture * AML Disassembler version 20100528 * * Disassembly of slic.dat, Mon Dec 19 22:31:44 2011 * * ACPI Data Table [SLIC] * * Format: [HexOffset DecimalOffset ByteLength] FieldName : FieldValue */ [000h 4]Signature : SLIC/* Software Licensing Description Table */ [004h 0004 4] Table Length : 0176 [008h 0008 1] Revision : 01 [009h 0009 1] Checksum : 5F [00Ah 0010 6] Oem ID : DELL [010h 0016 8] Oem Table ID : M07 [018h 0024 4] Oem Revision : 27D80202 [01Ch 0028 4] Asl Compiler ID : ASL [020h 0032 4]Asl Compiler Revision : 0061 These are the results of a dmidecode -t0 SMBIOS 2.4 present. Handle 0x, DMI type 0, 24 bytes BIOS Information Vendor: Dell Inc. Version: A06 Release Date: 02/02/2008 Address: 0xF Runtime Size: 64 kB ROM Size: 576 kB I'm guessing this may be significant because the DMI data is different in the VM. Looking at a memory dump of the VM ACPI tables I see several tables: RSDP, RSDT, FACP, SSDT, APIC, HPET, SLIC, FACS, and DSDT. RSDT and SLIC shows what we would expect: OEM ID= DELL OEM Table ID = M07 OEM Revision = 27D80202. In other words all the exported SLIC data. But the other tables show OEM ID = BOCHS OEM Table ID = BXPC OEM Revision = 0001 Maybe Windows XP reads from the wrong tables? I assume Seabios reads all of that from src/config.h is that right? I could just change that data and recompile, but would I need to change anything else also? Would that create maybe some other problems down the road? Besides all this, you obviously should have the right OEM version of windows, wich knows this very OEM you're pretending to be (if you're installing new VM and not using a pre-installed copy). For win7 this means valid certificate belonging to this OEM is installed in the system. Right. It bears mentioning that the OEM cd I have activates properly when installed directly on the host. I wont provide any further details about it, because someone thinks it is hackish and blackish territory. You can mail me offlist for that if you like. :) Brian
Re: [Qemu-devel] OEM Windows in Qemu
On 22.12.2011 08:44, in...@expertcomputerrepair.com wrote: [] WinXP requires SLIC version 1.0, which is reduced to just having a string with the name of your OEM in the bios (one possible place is the SLIC table). More recent version of SLIC (2.1 I think) is needed to activate windows7. This is the part that is confusing me. I've read that SLIC 2.0 is backward compatible with SLIC 1.0 so XP should activate just fine with a working SLIC 2.0. And your patch does apparently produce a signed SLIC 2.0 My patch does not produce any SLIC at all. The instructions mentions using SLIC from your machine - my patch is just a way to _embed_ a given data into VM, not a way to produce anything. You get in your VM what you have outside, either in a file or in your own BIOS, depending on where you took that data from. But my OEM copy of XP complains about the BIOS produced with your patch. I can only guess there is some critical piece missing that Windows 7 doesn't care about. Well. It should be both - win7 in my case cared about alot more details than winXP. But I must admit that I never actually installed oem version of winXP, -- I used an installed version to verify what it needs, and found that I can just mention the right string in the BIOS. Maybe it is not sufficient for actual activation procedure, I dunno. [] I'm guessing this may be significant because the DMI data is different in the VM. Looking at a memory dump of the VM ACPI tables I see several tables: RSDP, RSDT, FACP, SSDT, APIC, HPET, SLIC, FACS, and DSDT. RSDT and SLIC shows what we would expect: OEM ID= DELL OEM Table ID = M07 OEM Revision = 27D80202. In other words all the exported SLIC data. But the other tables show OEM ID = BOCHS OEM Table ID = BXPC OEM Revision = 0001 Maybe Windows XP reads from the wrong tables? Yes, the patch only changes RSDT to match SLIC - this is what win7 verifies, all other tables does not matter for win7. And yes, it might be different for winXP - you may try setting all tables in VM to be of DELL OEM and see what happens. I assume Seabios reads all of that from src/config.h is that right? I could just change that data and recompile, but would I need to change anything else also? Would that create maybe some other problems down the road? neither seabios nor qemu/kvm actually use these OEM strings, so there should be no problems. /mjt
Re: [Qemu-devel] OEM Windows in Qemu
On Tue, Dec 20, 2011 at 12:09:41AM -0700, in...@expertcomputerrepair.com wrote: htmlbodyspan style=font-family:Verdana; color:#00; font-size:10pt;divI've been trying for several days now to get my OEM copy of Windows XP to pre-activate properly in Qemu-kvm.nbsp; I saw the instructions for patching the seabios here:/divdiva href=http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg03080.html;http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg03080.html/abr/divdivbr/divdivThat seems to have worked as expected.nbsp; When I boot, it shows the newly compiled BIOS, but Windows fails to detect the SLIC codes which I copied from my working Dell system as per the instructions.nbsp; My research so far has turned up the existence of multiple versions of SLP/SLIC which I think may account for this./divdivbr/divdivCan anyone confirm what version of SLP the patch posted to this list is effective at emulating?nbsp; Is there an easy way to modify the patch to support a different version of SLP?/divdivbr/divdivI've installed several low level BIOS scanning tools in the VM to troubleshoot and gather information.nbsp; None of the tools I've used (OEMSCAN, Oembios) show a valid SLP 1.0 OEM data in the BIOS/RAM.nbsp; But another tool (ReadWrite) shows a valid Dell SLP 2.0 signature.nbsp; This leads me to believe that either I didn't copy the right SLIC information from my Dell PC or the patch is set up to create SLP 2.0 and not 1.0./divdivbr/divdivAny advice or help would be appreciated./divdivbr/divdivBrianbr/divdivbr/divdivbr/div/span/body/html Please send plain text emails, not HTML to the qemu-devel mailing list. Your email client or webmail should have an option to choose between text-only, HTML-only, and text-and-HTML. Either text-only or text-and-HTML is fine. Thanks, Stefan
Re: [Qemu-devel] OEM Windows in Qemu
Sorry, I don't normally use this email and didn't realize it was set to html. I've been trying for several days now to get my OEM copy of Windows XP to pre-activate properly in Qemu-kvm. I saw the instructions for patching the seabios here: http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg03080.html That seems to have worked as expected. When I boot, it shows the newly compiled BIOS, but Windows fails to detect the SLIC codes which I copied from my working Dell system as per the instructions. My research so far has turned up the existence of multiple versions of SLP/SLIC which I think may account for this. Can anyone confirm what version of SLP the patch posted to this list is effective at emulating? Is there an easy way to modify the patch to support a different version of SLP? I've installed several low level BIOS scanning tools in the VM to troubleshoot and gather information. None of the tools I've used (OEMSCAN, Oembios) show a valid SLP 1.0 OEM data in the BIOS/RAM. But another tool (ReadWrite) shows a valid Dell SLP 2.0 signature. This leads me to believe that either I didn't copy the right SLIC information from my Dell PC or the patch is set up to create SLP 2.0 and not 1.0. Any advice or help would be appreciated. Brian ___ Please send plain text emails, not HTML to the qemu-devel mailing list. Your email client or webmail should have an option to choose between text-only, HTML-only, and text-and-HTML. Either text-only or text-and-HTML is fine. Thanks, Stefan
Re: [Qemu-devel] OEM Windows in Qemu
On 20.12.2011 22:23, in...@expertcomputerrepair.com wrote: Sorry, I don't normally use this email and didn't realize it was set to html. I've been trying for several days now to get my OEM copy of Windows XP to pre-activate properly in Qemu-kvm. I saw the instructions for patching the seabios here: http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg03080.html Note that for winXP, the only thing needed from the bios is to _mention_ - anywhere in its memory - name of your manufacturer. That is, you can add any table with just a string - say - ASUS_Notebook in it, winXP does an equivalent of memmem() function on the bios content to find if it is supposed to be right OEM. That seems to have worked as expected. When I boot, it shows the newly compiled BIOS, but Windows fails to detect the SLIC codes which I copied from my working Dell system as per the instructions. My research so far has turned up the existence of multiple versions of SLP/SLIC which I think may account for this. WinXP requires SLIC version 1.0, which is reduced to just having a string with the name of your OEM in the bios (one possible place is the SLIC table). More recent version of SLIC (2.1 I think) is needed to activate windows7. Can anyone confirm what version of SLP the patch posted to this list is effective at emulating? Is there an easy way to modify the patch to support a different version of SLP? While I'm the author of the howto you mentioned, so my opinion here is biased, but still I can say that several other people used this way to run oem versions of windows7 and windowsVista in their VMs, and sent me their thanks. I also found this way mentioned in vmware-related forums. I've installed several low level BIOS scanning tools in the VM to troubleshoot and gather information. None of the tools I've used (OEMSCAN, Oembios) show a valid SLP 1.0 OEM data in the BIOS/RAM. But another tool (ReadWrite) shows a valid Dell SLP 2.0 signature. This leads me to believe that either I didn't copy the right SLIC information from my Dell PC or the patch is set up to create SLP 2.0 and not 1.0. I've no idea what does these tools do. For testing I just boot linux and check if it can see the tables with the content I've used (somewhere in /sys/firmware/acpi/tables). For further testing I boot my OEM-preinstalled copy of windows to verify it still thinks it is OEM-activated. I also tried to actually activate win7 in a VM, using slic+certificate from a random OEM (these are available on the 'net despite being M$ high-secret), and it worked just fine too. This is about win7, not winXP, for which I used real bios modification way in the past to just put a single string into BIOS of my machine for it to recognize the OEM-ness. Besides all this, you obviously should have the right OEM version of windows, wich knows this very OEM you're pretending to be (if you're installing new VM and not using a pre-installed copy). For win7 this means valid certificate belonging to this OEM is installed in the system. I wont provide any further details about it, because someone thinks it is hackish and blackish territory. Thanks, /mjt
[Qemu-devel] OEM Windows in Qemu
I've been trying for several days now to get my OEM copy of Windows XP to pre-activate properly in Qemu-kvm. I saw the instructions for patching the seabios here:http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg03080.htmlThat seems to have worked as expected. When I boot, it shows the newly compiled BIOS, but Windows fails to detect the SLIC codes which I copied from my working Dell system as per the instructions. My research so far has turned up the existence of multiple versions of SLP/SLIC which I think may account for this.Can anyone confirm what version of SLP the patch posted to this list is effective at emulating? Is there an easy way to modify the patch to support a different version of SLP?I've installed several low level BIOS scanning tools in the VM to troubleshoot and gather information. None of the tools I've used (OEMSCAN, Oembios) show a valid SLP 1.0 OEM data in the BIOS/RAM. But another tool (ReadWrite) shows a valid Dell SLP 2.0 signature. This leads me to believe that either I didn't copy the right SLIC information from my Dell PC or the patch is set up to create SLP 2.0 and not 1.0.Any advice or help would be appreciated.Brian
Re: [Qemu-devel] OEM Windows in qemu/kvm again (mini-howto)
Hi. SLIC table can be fed dynamically by utilize the existing fw_cfg interface.
Something like this. (This requires your qemu patch.)
This is just for showing the idea.
thanks,
diff --git a/src/acpi.c b/src/acpi.c
index 6428d9c..e0815bd 100644
--- a/src/acpi.c
+++ b/src/acpi.c
@@ -627,6 +627,7 @@ acpi_bios_init(void)
ACPI_INIT_TABLE(build_srat());
u16 i, external_tables = qemu_cfg_acpi_additional_tables();
+bool slic = false;
for(i = 0; i external_tables; i++) {
u16 len = qemu_cfg_next_acpi_table_len();
@@ -635,7 +636,12 @@ 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 == SLIC_SIGNATURE) {
+slic = true;
+}
+ACPI_INIT_TABLE(header);
if (tbl_idx == MAX_ACPI_TABLES) {
warn_noalloc();
break;
@@ -654,6 +660,9 @@ acpi_bios_init(void)
memcpy(rsdt-table_offset_entry, tables, sizeof(u32) * tbl_idx);
build_header((void*)rsdt, RSDT_SIGNATURE, rsdt_len, 1);
+if (slic) {
+// fix up rsdt-oem_id and check sum
+}
// Build rsdp pointer table
memset(rsdp, 0, sizeof(*rsdp));
On Thu, Mar 31, 2011 at 05:00:08PM +0400, Michael Tokarev wrote:
Here's a quick-n-dirty howto about running OEM version
of windows7 or vista in qemu/kvm, assuming you own a
computer with pre-installed OEM version of such operating
system so you have rights to run it there.
Windows 7 Vista OEM activation are based on a special
OEM marker in BIOS in a form of one ACPI table named SLIC.
The idea is to take content of that table from your computer
and present it in the virtual machine.
This table can be taken directly from /sys/firmware/acpi/tables/SLIC
(it's a small binary file), and hopefully qemu will be able
to use that directly (I submitted a patch to do that a few
days ago).
But there's on caveat still: windows apparently checks not only
the SLIC table/marker, but also verifies that the Vendor ID
fields in SLIC and RSDT tables matches each other. So just
presenting SLIC into a VM isn't enough, one have to modify
at least two fields in RSDT table too.
And since there's no way currently to do that using qemu
command line, I took another approach and modified seabios
code a bit. Here's a small howto to do that at home.
1) First of all, you need seabios source code appropriate
for your qemu/kvm. See http://www.seabios.org/ for that.
Also you need tools to recompile it, obviously.
2) after getting and extracting seabios sources, cd to
the source directory.
3) You need to build slic table to be used by a C compiler,
like this:
xxd -i /sys/firmware/acpi/tables/SLIC |
grep -v len |
sed 's/unsigned char.*/static char SLIC[] = {/'
src/acpi-slic.hex
this produces file src/acpi-slic.hex with content like
this:
static char SLIC[] = {
0x53, 0x4c, 0x49, 0x43, 0x76, 0x01, ...
};
4) apply the following patch to src/acpi.c:
= cut =
--- a/src/acpi.c
+++ b/src/acpi.c
@@ -199,4 +199,9 @@ struct srat_memory_affinity
#include acpi-dsdt.hex
+#define CONFIG_OEM_SLIC
+#ifdef CONFIG_OEM_SLIC
+#include acpi-slic.hex
+#endif
+
static void
build_header(struct acpi_table_header *h, u32 sig, int len, u8 rev)
@@ -211,4 +216,8 @@ build_header(struct acpi_table_header *h, u32 sig, int
len, u8 rev)
h-oem_revision = cpu_to_le32(1);
h-asl_compiler_revision = cpu_to_le32(1);
+#ifdef CONFIG_OEM_SLIC
+if (sig == RSDT_SIGNATURE) // only RSDT is checked by win7 vista
+ memcpy(h-oem_id, ((struct acpi_table_header*)SLIC)-oem_id, 14);
+#endif
h-checksum -= checksum(h, len);
}
@@ -627,4 +636,15 @@ acpi_bios_init(void)
ACPI_INIT_TABLE(build_srat());
+#ifdef CONFIG_OEM_SLIC
+{ void *buf = malloc_high(sizeof(SLIC));
+ if (!buf)
+warn_noalloc();
+ else {
+memcpy(buf, SLIC, sizeof(SLIC));
+ACPI_INIT_TABLE(buf);
+ }
+}
+#endif
+
u16 i, external_tables = qemu_cfg_acpi_additional_tables();
= cut =
The patch above arranges for your SLIC table to be
included inside the (virtual) bios (that table does
exactly nothing for the bios itself and for other
system components) and also modifies OEM identification
information in RSDT table to match SLIC table.
5) build the bios as usual by issuing `make' in the top
source directory. You'll get out/bios.bin file.
Place it somewhere like /usr/share/qemu/bios-asus.bin
or anywhere like you want.
6) and finally, specify that bios file when running your
preinstalled windows:
qemu -hda /dev/sda -bios /usr/share/qemu/bios-asus.bin
[...other options...]
(But be
[Qemu-devel] OEM Windows in qemu/kvm again (mini-howto)
Here's a quick-n-dirty howto about running OEM version
of windows7 or vista in qemu/kvm, assuming you own a
computer with pre-installed OEM version of such operating
system so you have rights to run it there.
Windows 7 Vista OEM activation are based on a special
OEM marker in BIOS in a form of one ACPI table named SLIC.
The idea is to take content of that table from your computer
and present it in the virtual machine.
This table can be taken directly from /sys/firmware/acpi/tables/SLIC
(it's a small binary file), and hopefully qemu will be able
to use that directly (I submitted a patch to do that a few
days ago).
But there's on caveat still: windows apparently checks not only
the SLIC table/marker, but also verifies that the Vendor ID
fields in SLIC and RSDT tables matches each other. So just
presenting SLIC into a VM isn't enough, one have to modify
at least two fields in RSDT table too.
And since there's no way currently to do that using qemu
command line, I took another approach and modified seabios
code a bit. Here's a small howto to do that at home.
1) First of all, you need seabios source code appropriate
for your qemu/kvm. See http://www.seabios.org/ for that.
Also you need tools to recompile it, obviously.
2) after getting and extracting seabios sources, cd to
the source directory.
3) You need to build slic table to be used by a C compiler,
like this:
xxd -i /sys/firmware/acpi/tables/SLIC |
grep -v len |
sed 's/unsigned char.*/static char SLIC[] = {/'
src/acpi-slic.hex
this produces file src/acpi-slic.hex with content like
this:
static char SLIC[] = {
0x53, 0x4c, 0x49, 0x43, 0x76, 0x01, ...
};
4) apply the following patch to src/acpi.c:
= cut =
--- a/src/acpi.c
+++ b/src/acpi.c
@@ -199,4 +199,9 @@ struct srat_memory_affinity
#include acpi-dsdt.hex
+#define CONFIG_OEM_SLIC
+#ifdef CONFIG_OEM_SLIC
+#include acpi-slic.hex
+#endif
+
static void
build_header(struct acpi_table_header *h, u32 sig, int len, u8 rev)
@@ -211,4 +216,8 @@ build_header(struct acpi_table_header *h, u32 sig, int len,
u8 rev)
h-oem_revision = cpu_to_le32(1);
h-asl_compiler_revision = cpu_to_le32(1);
+#ifdef CONFIG_OEM_SLIC
+if (sig == RSDT_SIGNATURE) // only RSDT is checked by win7 vista
+ memcpy(h-oem_id, ((struct acpi_table_header*)SLIC)-oem_id, 14);
+#endif
h-checksum -= checksum(h, len);
}
@@ -627,4 +636,15 @@ acpi_bios_init(void)
ACPI_INIT_TABLE(build_srat());
+#ifdef CONFIG_OEM_SLIC
+{ void *buf = malloc_high(sizeof(SLIC));
+ if (!buf)
+warn_noalloc();
+ else {
+memcpy(buf, SLIC, sizeof(SLIC));
+ACPI_INIT_TABLE(buf);
+ }
+}
+#endif
+
u16 i, external_tables = qemu_cfg_acpi_additional_tables();
= cut =
The patch above arranges for your SLIC table to be
included inside the (virtual) bios (that table does
exactly nothing for the bios itself and for other
system components) and also modifies OEM identification
information in RSDT table to match SLIC table.
5) build the bios as usual by issuing `make' in the top
source directory. You'll get out/bios.bin file.
Place it somewhere like /usr/share/qemu/bios-asus.bin
or anywhere like you want.
6) and finally, specify that bios file when running your
preinstalled windows:
qemu -hda /dev/sda -bios /usr/share/qemu/bios-asus.bin
[...other options...]
(But be careful and choose appropriate boot entry, do
not boot linux itself in your virtual machine :)
Something like that. This is formed as a quick-n-dirty
howto because there's quite alot of questions lately about
this very stuff (how to run activated windows in qemu),
and I wanted to write an instruction so that less
expirienced people will be able to do that.
Kevin, do you remember why this code is present in
acpi.c:
build_header(struct acpi_table_header *h, u32 sig, int len, u8 rev)
{
memcpy(h-oem_id, CONFIG_APPNAME6, 6);
memcpy(h-oem_table_id, CONFIG_APPNAME4, 4);
memcpy(h-asl_compiler_id, CONFIG_APPNAME4, 4);
memcpy(h-oem_table_id + 4, (void*)sig, 4); === this
To me it looks like we need another #define, like
CONFIG_APPNAME8, to be used for whole oem_table_id
field. And also, maybe made all this stuff configurable
somehow (starting from the build config in out/autoconf.h
etc) ?
Thanks!
/mjt
