From: "Michael S. Tsirkin" <mst@redhat.com>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC] copy OEM ACPI parameters from SLIC table to RSDT
Date: Sun, 6 Apr 2014 13:53:35 +0300 [thread overview]
Message-ID: <20140406105335.GB8485@redhat.com> (raw)
In-Reply-To: <1396777751-10995-1-git-send-email-mjt@msgid.tls.msk.ru>
On Sun, Apr 06, 2014 at 01:49:11PM +0400, Michael Tokarev wrote:
> When building RSDT table, pick OEM ID fields from uer-supplied SLIC
> table instead of using hard-coded QEMU defaults. This way, say,
> OEM version of Windows7 can be run inside qemu using the same OEM
> activation as on bare metal, by pointing at system firmware:
>
> -acpitable file=/sys/firmware/acpi/tables/SLIC
Right, so this doesn't work in 1.7 either, right?
It's not a regression?
> Windows7 requires that OEM ID in RSDT matches those in SLIC to
> consider SLIC to be valid.
Which fields need to match which, exactly?
> This is somewhat hackish approach, but it works fairy well in
> practice.
>
> I'm not asking to apply this directly, but instead am trying to
> show what's needed to get win to work. Maybe a new command-line
> option for that will do, maybe something else.
>
> Thanks,
>
> /mjt
I think it's kind of reasonable - seems better than
adding more flags - but I'd like to avoid
poking at acpi_tables array in acpi-build.c
How about an API to set/query OEM ID?
> ---
> hw/acpi/core.c | 5 +++++
> hw/i386/acpi-build.c | 7 +++++++
> 2 files changed, 12 insertions(+)
>
> diff --git a/hw/acpi/core.c b/hw/acpi/core.c
> index 79414b4..a8a3f26 100644
> --- a/hw/acpi/core.c
> +++ b/hw/acpi/core.c
> @@ -53,6 +53,7 @@ static const char unsigned dfl_hdr[ACPI_TABLE_HDR_SIZE - ACPI_TABLE_PFX_SIZE] =
>
> char unsigned *acpi_tables;
> size_t acpi_tables_len;
> +size_t slic_table_offset;
>
> static QemuOptsList qemu_acpi_opts = {
> .name = "acpi",
> @@ -226,6 +227,10 @@ static void acpi_table_install(const char unsigned *blob, size_t bloblen,
> /* recalculate checksum */
> ext_hdr->checksum = acpi_checksum((const char unsigned *)ext_hdr +
> ACPI_TABLE_PFX_SIZE, acpi_payload_size);
> +
> + if (memcmp(ext_hdr->sig, "SLIC", 4) == 0) {
> + slic_table_offset = acpi_tables_len - acpi_payload_size;
> + }
> }
>
> void acpi_table_add(const QemuOpts *opts, Error **errp)
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index a5d3fbf..9e0e16a 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -224,6 +224,8 @@ static void acpi_get_pci_info(PcPciInfo *info)
> #define ACPI_BUILD_TABLE_FILE "etc/acpi/tables"
> #define ACPI_BUILD_RSDP_FILE "etc/acpi/rsdp"
>
> +extern size_t slic_table_offset;
> +
> static void
> build_header(GArray *linker, GArray *table_data,
> AcpiTableHeader *h, const char *sig, int len, uint8_t rev)
> @@ -237,6 +239,11 @@ build_header(GArray *linker, GArray *table_data,
> h->oem_revision = cpu_to_le32(1);
> memcpy(h->asl_compiler_id, ACPI_BUILD_APPNAME4, 4);
> h->asl_compiler_revision = cpu_to_le32(1);
> + if (memcmp(sig, "RSDT", 4) == 0 && slic_table_offset) {
> + /* for win7: OEM info in RSDT and SLIC should be the same */
> + AcpiTableHeader *s = (AcpiTableHeader *)(acpi_tables + slic_table_offset);
> + memcpy(h->oem_id, s->oem_id, 6 + 4 + 4);
what does 6 + 4 +4 mean?
I see:
uint8_t oem_id [6]; /* OEM identification */ \
uint8_t oem_table_id [8]; /* OEM table identification */ \
uint32_t oem_revision; /* OEM revision number */ \
Do table id have to match? It seems a bit wrong to have two tables
with the same id.
> + }
> h->checksum = 0;
> /* Checksum to be filled in by Guest linker */
> bios_linker_loader_add_checksum(linker, ACPI_BUILD_TABLE_FILE,
> --
> 1.7.10.4
>
next prev parent reply other threads:[~2014-04-06 10:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-06 9:49 [Qemu-devel] [RFC] copy OEM ACPI parameters from SLIC table to RSDT Michael Tokarev
2014-04-06 10:53 ` Michael S. Tsirkin [this message]
2014-04-06 11:08 ` Michael Tokarev
2014-04-06 12:21 ` Laszlo Ersek
2014-04-07 15:38 ` Chris Evich
2014-04-06 12:25 ` Michael S. Tsirkin
2014-04-06 13:58 ` Michael Tokarev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140406105335.GB8485@redhat.com \
--to=mst@redhat.com \
--cc=mjt@tls.msk.ru \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).