[vfio-users] Steam blocking VMs in csgo?

Tue Feb 28 03:08:26 UTC 2017

I'd be interesting if they were detecting VMs for, or just the presence 
of, clock jitter, skew and drift. I don't know much about CS:GO but I 
wonder if it might adversely affect game play network data.

It might be interesting for you to track those in the VM and sync 
tightly with NTP. Besides Windows' own NTP client perhaps one might 
experiment with something like:

http://www.bytefusion.com/products/ntm/ptnt/whatispresentense.htm

On 27 Feb 2017, at 17:26, Brandon Ganem wrote:

> I've emailed and attempted to submit tickets. Asking valve is a heck 
> of a
> lot easier said than done.
>
> On Mon, Feb 27, 2017 at 8:22 PM, Taiidan at gmx.com <Taiidan at gmx.com> 
> wrote:
>
>> You guys really should ask valve :<
>> Something worth doing for better latency is an IOMMU attached 
>> networking
>> device.
>> The best choice for performance/latency is an SR-IOV networking 
>> device set
>> up with the new libvirt method (so the mac address stays the same)
>>
>>
>> On 02/27/2017 08:19 PM, Brandon Ganem wrote:
>>
>> I've got a pretty normal network setup where i'm bridged to my wired. 
>> I can
>> reproduce every time I play, somewhere between 15 minutes and 45 
>> minutes.
>> It's happened 5 or so times now.
>>
>> On Mon, Feb 27, 2017 at 8:17 PM, Scott <shewless at unleashed-web.org> 
>> <shewless at unleashed-web.org> wrote:
>>
>>
>> Why not just nat?
>>
>> scott
>>
>> On Feb 27, 2017 8:10 PM, "Ethan Bugden" <ethan961 at gmail.com> 
>> <ethan961 at gmail.com> wrote:
>>
>>
>> I got kicked after ~45 mins of DMing again, waited a couple minutes 
>> then
>> it said "Your connection to matchmaking servers is not reliable" or 
>> similar
>> attempting to find a game, while it let me join a local server. 
>> Repaired
>> steam service and it let me on official servers yet again... wonder 
>> if it's
>> due to networking differences. I use ARP proxy between my wireless 
>> card and
>> a TAP device.
>>
>> On Mon, Feb 27, 2017 at 2:06 PM, Brandon Ganem 
>> <brandonganem at gmail.com> <brandonganem at gmail.com>
>> wrote:
>>
>>
>> Just got kicked again from a casual game. I had not been running it 
>> as
>> admin, but doing so just now was not enough to let me back into a 
>> game.
>>
>> I'll do my best to find some contact points with Valve and reference
>> this thread as well. Thanks again!
>>
>> On Sun, Feb 26, 2017 at 9:59 PM, Ethan Bugden <ethan961 at gmail.com> 
>> <ethan961 at gmail.com>
>> wrote:
>>
>>
>> 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> <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> 
>> <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> 
>> <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> 
>> <Taiidan at gmx.com>
>> wrote:
>>
>> Did you try the hyperV clock? it could be a timer issue.
>>
>>
>>  _______________________________________________
>> vfio-users mailing 
>> listvfio-users at redhat.comhttps://www.redhat.com/mailman/listinfo/vfio-users
>>
>>
>>
>> _______________________________________________
>> vfio-users mailing 
>> listvfio-users at redhat.comhttps://www.redhat.com/mailman/listinfo/vfio-users
>>
>>
>>

> _______________________________________________
> vfio-users mailing list
> vfio-users at redhat.com
> https://www.redhat.com/mailman/listinfo/vfio-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20170227/9b60b8d8/attachment.htm>