[vfio-users] Steam blocking VMs in csgo?

[Ethan Bugden]

Just to clarify, you did repair the steam service in an elevated command
prompt/as admin, not a regular one? I've never had this problem occur and
have it not solved by a repair, at least it should work long enough to
finish your match. It does sound like this is an actual issue with playing
in VMs being flagged in the first place though. I just did another 45mins
of Valve DM in my VM without issues, I'll keep playing in VM when I play to
gather some more info. I call qemu through the CLI, my CPU line is: -cpu
host,hv_time,hv_vapic,hv_relaxed,hv_spinlocks=0x1fff, I don't hide KVM. I
think we'd probably get better results emailing the VAC and/or CSGO teams
than submitting a ticket. We only want to use one instance of the game, so
hopefully if they're at least aware of this use case they can keep it in
mind during future developments. Or if they fixed the native client that
would be nice....

On Mon, Feb 27, 2017 at 1:43 PM, Brandon Ganem <brandonganem at gmail.com>
wrote:

> I'll give it a go again if I get kicked after these changes. Thanks for
> your help!
>
> On Sun, Feb 26, 2017 at 9:41 PM, Taiidan at gmx.com <Taiidan at gmx.com> wrote:
>
>> Damn, like I said you should submit a support ticket with valve.
>>
>> I am sure there is a way, no matter how hard the web 2.0 companies try to
>> make it.
>>
>>
>> On 02/26/2017 09:39 PM, Brandon Ganem wrote:
>>
>>> Updated to the following:
>>>    <features>
>>>      <acpi/>
>>>      <hyperv>
>>>        <relaxed state='on'/>
>>>        <vapic state='on'/>
>>>        <spinlocks state='on' retries='8191'/>
>>>      </hyperv>
>>>      <kvm>
>>>        <hidden state='on'/>
>>>      </kvm>
>>>    </features>
>>>    <cpu mode='host-passthrough'>
>>>      <topology sockets='1' cores='6' threads='2'/>
>>>    </cpu>
>>>    <clock offset='localtime'>
>>>      <timer name='hypervclock' present='yes'/>
>>>    </clock>
>>>
>>> So far i'm in a game, but it typically takes anywhere from 30 minutes to
>>> an
>>> hour to get VAC'd based on the last 3 attempts.
>>>
>>> On Sun, Feb 26, 2017 at 9:34 PM, Taiidan at gmx.com <Taiidan at gmx.com>
>>> wrote:
>>>
>>> You need to use a newer version of libvirt that has the vendor tag
>>>> workaround to be able to get past that, it should also give you better
>>>> performance to use all the hyperv enhancements.
>>>>
>>>> This
>>>> <vendor_id state='on' value='whatever'/>
>>>> needs to be supported but I forgot which version added it
>>>>
>>>>
>>>> On 02/26/2017 09:30 PM, Brandon Ganem wrote:
>>>>
>>>> Looks like I've got the opposite of all of that enabled, probably was
>>>>> for
>>>>> code 43 issues. I'll update to recommended hyper-v settings and see.
>>>>>
>>>>> On Sun, Feb 26, 2017 at 9:12 PM, Taiidan at gmx.com <Taiidan at gmx.com>
>>>>> wrote:
>>>>>
>>>>> Did you try the hyperV clock? it could be a timer issue.
>>>>>
>>>>>>
>>>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20170227/6117f1e5/attachment.htm>