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
