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

[Paolo Bonzini <pbonzini@redhat.com>]

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