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

[Marian Posteuca <posteuca@mutex.one>]

Paolo Bonzini <pbonzini@redhat.com> writes:

> 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".
This looks like a great idea.
Noob question here, should I change my patch in any way for this to happen?
>
> Paolo