After a series of tries, I finally made my OEM copy of Windows 7 to work in KVM using the original registration key.
In short, one need SCIC table from the BIOS on the original hardware, -- it should be in the BIOS in the virtual machine too. And second part is that other tables in our virtual BIOS need to have the same OEM identification as the SLIC table - namely FACP (in case of kmv), and also XSDT and RSDT if present. The way to insert custom acpi table is using -acpitable parameter. But unfortunately kvm does not provide a way to insert whole table this way, together with the header -- instead, it expects the header on the command line. It is possible to extract the header into printable form for the command line, and cut it from the slic.bin, but I used different way: I modified hw/acpi.c load whole thing from the given file. After doing that, and giving -acpitable file=slic.bin (with file= parameter being my quick-n-dirty addition) to kvm, I were able to see the correct SLIC table in /sys/firmware/ acpi/tables/SLIC in linux. But windows refused to activate. So the next step was to modify seabios OEM string which it placed to other tables. For that, in src/acpi.c I just added memcpy(h->oem_id, "_ASUS_Notebook", 14); to build_header() routine (yes it is a notebook from Asus with licensed version of windows7 professional). And after that step windows happily told me that I'm now using genuine copy of it and the activation is completed. As far as I can see I have right to run my licensed copy this way, on the same notebook it were purchased with. So.. the real question is: while this quick-n-dirty proof of concept works, it's not the way to go. What can be done to simplify the whole thing and to do it the Right Way? At least having a way to accept complete acpi table (with header and checksum and everything) is - IMHO - a good thing. But I'm not sure about the OEM ID strings in other tables in seabios, -- it is quite ugly, both in implementation (how to tell bios to change its identify?) and in the whole fact of it, since we're lying to the (virtual) machine. But from another point of view, it should be a good debugging tool, since some software behaves differently given one or another strings in the BIOS... Comments, anyone? Thanks! /mjt -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
