qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2] acpi: Permit OEM ID and OEM table ID fields to be changed


From: Paolo Bonzini
Subject: Re: [PATCH v2] acpi: Permit OEM ID and OEM table ID fields to be changed
Date: Tue, 22 Dec 2020 23:46:15 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0

On 22/12/20 16:39, Marian Posteuca wrote:
Qemu's ACPI table generation sets the fields OEM ID and OEM table ID
to "BOCHS " and "BXPCxxxx" where "xxxx" is replaced by the ACPI
table name.

Some games like Red Dead Redemption 2 seem to check the ACPI OEM ID
and OEM table ID for the strings "BOCHS" and "BXPC" and if they are
found, the game crashes(this may be an intentional detection
mechanism to prevent playing the game in a virtualized environment).
This isn't a technical question/comment about the patch itself, but
about something different.  Do we really want to play this whack-a-mole
game? If we change ACPI table IDs, those who want to disallow running
their software inside qemu/kvm will find some other way to check for
this environment. We will change that, - just to be found again. And
so on.. is it productive? I don't think so.

My personal opinion is that as long as it's not too difficult to mask
that the guest is running in a virtualized environment we should try to
do these changes. But I guess this can only be judged on per change basis.

I don't have any particular opinion against the "arms race"/"whack-a-mole" situation. We played the game (and sort of won, they got tired of changing the drivers) against NVIDIA already.

For 6.0 I'm already planning to revamp a bunch of machine properties, for example making -acpitable file=xxx a synonym for "-machine acpi.tables.N.file=xxx". Perhaps we could plan for that and make the option "-machine acpi.oem_id".

Paolo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]