From win-pv-devel-bounces@lists.xenproject.org Mon May 04 17:49:57 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 04 May 2020 17:49:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jVfE3-0002WC-A3; Mon, 04 May 2020 17:49:55 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jVeY7-0007VR-Hs for win-pv-devel@lists.xenproject.org; Mon, 04 May 2020 17:06:36 +0000 X-Inumbo-ID: 9ae756b0-8e29-11ea-9887-bc764e2007e4 Received: from mail.hamcom.de (unknown [2001:14f0:0:dc03::37:210]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9ae756b0-8e29-11ea-9887-bc764e2007e4; Mon, 04 May 2020 17:06:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=helimail.de ; s=201711; h=Content-Type:MIME-Version:Date:Message-ID:Subject:From:To: Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=dMWUgdUGyiiqTZ1+eveKtmVvx/oSpmhKy6/vDUunmCU=; b=pgI6osibhFHcKaSXUj+1QAj1wi drQpOJ5Udk12othflKBEqmB6PRQsf/S3DzIZwMzRuZVgh12+BvjBa7NZx1dQ2yW9QN3VybqxYz2xj AJkQ0OA1bdeb6gAZt3uyyaobYcv1Qt3hk6gdSpMD7ynHya/UppfNBgW2IIVTeaohJZO4=; Received: from [37.83.173.248] (port=56692 helo=[192.168.1.100]) by mail.hamcom.de with esmtpa (Exim 4.92.3) (envelope-from ) id 1jVeY4-0000pJ-Jh for win-pv-devel@lists.xenproject.org; Mon, 04 May 2020 19:06:33 +0200 X-HeLi-id: cfcd208495d565ef66e7dff9f98764da To: win-pv-devel@lists.xenproject.org From: Oliver Linden Subject: Likely bug in the PV driver v9.0 Message-ID: Date: Mon, 4 May 2020 19:06:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="B9fbUWreAzyONY3DkcOtbPahkkpPRi6Zf" X-Spam-Score: -1.0 X-Spam-Flag: NO X-Mailman-Approved-At: Mon, 04 May 2020 17:49:54 +0000 X-BeenThere: win-pv-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Developer list for the Windows PV Drivers subproject List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: win-pv-devel-bounces@lists.xenproject.org Sender: "win-pv-devel" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --B9fbUWreAzyONY3DkcOtbPahkkpPRi6Zf Content-Type: multipart/mixed; boundary="I5moycM16iDkvZneR5TGF74DfkrQotUaQ"; protected-headers="v1" From: Oliver Linden To: win-pv-devel@lists.xenproject.org Message-ID: Subject: Likely bug in the PV driver v9.0 --I5moycM16iDkvZneR5TGF74DfkrQotUaQ Content-Type: multipart/alternative; boundary="------------14C44BB94148E29E65CA0ADF" Content-Language: en-US This is a multi-part message in MIME format. --------------14C44BB94148E29E65CA0ADF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear all, I'm observing an annoying bug with the v9 Windows PV drivers. It's easy reproducible here on my side: Dom0: ubuntu 20.04 freshly installed around Easter with there version of Xen (4.11) and only using the xl tool-stack. DomU: With every fresh installation of Windows 10 v1909 German the following can be reproduced: * Everything is working but slow as expected * Installation of the v9 drivers works well without any issues and results in significantly improved speed but RDP connections to such a machine aren't possible anymore. The RDP service always asks for a user/PW but never accepts it. To be precise, the RDP connections are working * with the plain vanilla installation * with the v9 drivers being installed *except the network class & drive= r* Since I'm using my Windows machines predominately with RDP clients it would be great if this can be solved. Please let me know if you need any kind of details from my side. Best, Oliver --------------14C44BB94148E29E65CA0ADF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Dear all,

I'm observing an annoying bug with the v9 Windows PV drivers. It's easy reproducible here on my side:

Dom0:
ubuntu 20.04 freshly installed around Easter with there version of Xen (4.11) and only using the xl tool-stack.

DomU:
With every fresh installation of Windows 10 v1909 German the following can be reproduced:

  • Everything is working but slow as expected
  • Installation of the v9 drivers works well without any issues and results in significantly improved speed

but

RDP connections to such a machine aren't possible anymore. The RDP service always asks for a user/PW but never accepts it. To be precise, the RDP connections are working

  • with the plain vanilla installation
  • with the v9 drivers being installed except the network class & driver

Since I'm using my Windows machines predominately with RDP clients it would be great if this can be solved. Please let me know if you need any kind of details from my side.

Best, Oliver


--------------14C44BB94148E29E65CA0ADF-- --I5moycM16iDkvZneR5TGF74DfkrQotUaQ-- --B9fbUWreAzyONY3DkcOtbPahkkpPRi6Zf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQG14HRX/gP3AY3+bqqsNqQA1FaigUCXrBLkgAKCRCqsNqQA1Fa ishuAJwNXoflTXw9fnPDYg4lw4xyq2a8nACgz8n6mdCMr7PODNXsZPBbqcenjpA= =QSV7 -----END PGP SIGNATURE----- --B9fbUWreAzyONY3DkcOtbPahkkpPRi6Zf-- From win-pv-devel-bounces@lists.xenproject.org Tue May 05 13:56:42 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 05 May 2020 13:56:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jVy3s-0008TE-LX; Tue, 05 May 2020 13:56:40 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jVy3r-0008T9-Ua for win-pv-devel@lists.xenproject.org; Tue, 05 May 2020 13:56:40 +0000 X-Inumbo-ID: 3d79aa3c-8ed8-11ea-b9cf-bc764e2007e4 Received: from mail-ej1-x62d.google.com (unknown [2a00:1450:4864:20::62d]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 3d79aa3c-8ed8-11ea-b9cf-bc764e2007e4; Tue, 05 May 2020 13:56:38 +0000 (UTC) Received: by mail-ej1-x62d.google.com with SMTP id q8so1743568eja.2 for ; Tue, 05 May 2020 06:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=i1ANXolv6IUUrQtnT/KIF9n1kfEe2LNjA+Uufg9RE+4=; b=lV/kF+kti73UzJaHoyjqDPvE+2yF8y76CEJnblY1QAZ/adQH7okV8Fq/xpbSSNWJxx hJk13q2Vc2D5diC9tDAC/LnSu4E6ZqRHo2j7tCNWQC4s+h/Jn7/RKLZL8QeCKGYCsqYV sWN259Uj4exRqfZ/vwWT1jSyKbxZ4CUT1bM3KgBiXNKk+afJsAySDuLDhCiul2TyH3Kk IJaRJ7iBb20tqJbeVP6IJitglnTlD1nyoK7NE7E7/cWC7HktZ6fH7snI7fzK77xbt6CA 5B2aeRYDg0pvDB2/tffof2A6XaijleP1UjYnS/dNfBM+8k6ikLuJplyC1nQCjLDreniX 0XWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:references:in-reply-to:subject :date:message-id:mime-version:thread-index:content-language; bh=i1ANXolv6IUUrQtnT/KIF9n1kfEe2LNjA+Uufg9RE+4=; b=G9LazKZU8w1DCZ01/QxQeB9lJ9IoR43NdufOSf8iazupxhGB7BDYzxKvNKWxmCmxSH rbijK5HDBQ8m3ra5xSpcMFYX/D9hw215aJhKKQ2fVsEl4FutmziRkypF+5w677WDiKOS ZC7LTIusvsOwMxdX8MM84TLFxrl26tOuJxC5wnbuzpGpMupptzwQmdxwYNgvRU/I2g6b f44D4s1mVtLY4mpLDlHCX426yF98iB4+vdb6QfGQKb+PkB6iy/E/HQPFR2hARlDNYThp xQMPkzZU87S9vdEHIKsq6xX/G9ryFrlK/ouuK5kSQXOe5AnuyEYpMq+QTChPbd+pdnv2 0aWQ== X-Gm-Message-State: AGi0PuYGngGlx6Yb0NXQVcGBtCMPJaRLHVZk0E/0mxn0vVtPqYic/TMp dsIGrwBvPnA56lhG+D9IjXY= X-Google-Smtp-Source: APiQypIAEyprHw/jPwW5k4WpfodE0d9jwV+OrhCwdx+x0iqF8I4I0iH1xq5sui7VtMzGGv/PVZNPOg== X-Received: by 2002:a17:906:4810:: with SMTP id w16mr2753020ejq.226.1588686997995; Tue, 05 May 2020 06:56:37 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.185]) by smtp.gmail.com with ESMTPSA id i19sm286741edy.28.2020.05.05.06.56.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 May 2020 06:56:37 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Oliver Linden'" , References: In-Reply-To: Subject: RE: Likely bug in the PV driver v9.0 Date: Tue, 5 May 2020 14:56:36 +0100 Message-ID: <003701d622e4$fe8e12e0$fbaa38a0$@xen.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0038_01D622ED.6053DA70" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQG9IJ9vpX/oWXBdLX78RYa0vQCcNajLhtaA Content-Language: en-gb X-BeenThere: win-pv-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Developer list for the Windows PV Drivers subproject List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Errors-To: win-pv-devel-bounces@lists.xenproject.org Sender: "win-pv-devel" This is a multipart message in MIME format. ------=_NextPart_000_0038_01D622ED.6053DA70 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Oliver, =20 I can only think this is a checksumming issue. I can=E2=80=99t see how = else a network driver operating no higher than L4 (for checksum/LSO) = would be able to affect a very specific part of a higher level protocol. = Although, one thing to watch out for=E2=80=A6 in the past I have seen = Windows do things like re-enabling firewall rules when there is a change = in the network stack so you might want to check that. =20 Cheers, =20 Paul =20 From: win-pv-devel On Behalf = Of Oliver Linden Sent: 04 May 2020 18:06 To: win-pv-devel@lists.xenproject.org Subject: Likely bug in the PV driver v9.0 =20 Dear all, I'm observing an annoying bug with the v9 Windows PV drivers. It's easy = reproducible here on my side: Dom0: ubuntu 20.04 freshly installed around Easter with there version of Xen = (4.11) and only using the xl tool-stack. DomU: With every fresh installation of Windows 10 v1909 German the following = can be reproduced: * Everything is working but slow as expected * Installation of the v9 drivers works well without any issues and = results in significantly improved speed but RDP connections to such a machine aren't possible anymore. The RDP = service always asks for a user/PW but never accepts it. To be precise, = the RDP connections are working * with the plain vanilla installation * with the v9 drivers being installed except the network class & driver Since I'm using my Windows machines predominately with RDP clients it = would be great if this can be solved. Please let me know if you need any = kind of details from my side. Best, Oliver =20 ------=_NextPart_000_0038_01D622ED.6053DA70 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi = Oliver,

 =

=C2=A0 I can only think this is a = checksumming issue. I can=E2=80=99t see how = else a network driver operating no higher than L4 (for checksum/LSO) = would be able to affect a very specific part of a higher level protocol. = Although, one thing to watch out for=E2=80=A6 in the past I have seen = Windows do things like re-enabling firewall rules when there is a change = in the network stack so you might want to check = that.

 =

=C2=A0 Cheers,

 =

=C2=A0=C2=A0=C2=A0 = Paul

 =

From: win-pv-devel = <win-pv-devel-bounces@lists.xenproject.org> On Behalf Of = Oliver Linden
Sent: 04 May 2020 18:06
To: = win-pv-devel@lists.xenproject.org
Subject: Likely bug in the = PV driver v9.0

 

Dear all,

I'm = observing an annoying bug with the v9 Windows PV drivers. It's easy = reproducible here on my side:

Dom0:
ubuntu 20.04 = freshly installed around Easter with there version of Xen (4.11) and = only using the xl tool-stack.

DomU:
With every fresh = installation of Windows 10 v1909 German the following can be = reproduced:

  • Everything is = working but slow as expected
  • Installation of the = v9 drivers works well without any issues and results in significantly = improved = speed

but

RDP connections to = such a machine aren't possible anymore. The RDP service always asks for = a user/PW but never accepts it. To be precise, the RDP connections are = working

  • with the plain = vanilla installation
  • with the v9 drivers = being installed except the network class & = driver

Since I'm using my Windows = machines predominately with RDP clients it would be great if this can be = solved. Please let me know if you need any kind of details from my = side.

Best, Oliver

 

------=_NextPart_000_0038_01D622ED.6053DA70-- From win-pv-devel-bounces@lists.xenproject.org Wed May 06 07:26:59 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 06 May 2020 07:26:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jWESG-0004kh-Fu; Wed, 06 May 2020 07:26:56 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jWESE-0004kb-Nh for win-pv-devel@lists.xenproject.org; Wed, 06 May 2020 07:26:54 +0000 X-Inumbo-ID: f4f121bc-8f6a-11ea-ae69-bc764e2007e4 Received: from mail-wm1-x330.google.com (unknown [2a00:1450:4864:20::330]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f4f121bc-8f6a-11ea-ae69-bc764e2007e4; Wed, 06 May 2020 07:26:53 +0000 (UTC) Received: by mail-wm1-x330.google.com with SMTP id h4so1344765wmb.4 for ; Wed, 06 May 2020 00:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=6tWr9wMl4hpSUrR7ura876KwvjnvLCzMf3sQ/cp/HgA=; b=rui5T8qQR0AioWyZmCUJHql3CRwTqO94Kuo3BUDQ6qmWH3TyGo0NgeFl8NJNjpuf7R r13ugg/Od+X0uydTFdvH3uJFn8/xuOk7pvmI7UVBAbInF8/U9N0nJAKSOEReoxOlFBVF fk1B9pI4Uy7YcqDdovfRfo9ReoTDdqcNOaJVu2kskdm3kdO7sgDmWtRYKhYMBbJ32uVA tzYFPXMpVY2zk6tYIEZCbUBU3c0MY0rxVH2CBkjiKbeLFkgBqBH2ZInH2vpLKUwk8JdF rzWECBSnZ1KmFun3nXLGLQfoUFlWJMeLHMqqPM3/xmFCGINOvxNlYCj0wXNUKZwyAKZ3 /JGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:references:in-reply-to:subject :date:message-id:mime-version:thread-index:content-language; bh=6tWr9wMl4hpSUrR7ura876KwvjnvLCzMf3sQ/cp/HgA=; b=ac/B0O4d1VjKFQXskmrKfquz7gK+RzoA9cnVXqx0byd8GyZVltuiQY0/W1AlfGsXKk vj+EkTPNGCodE07c7TyDfHm8+dxnbb/14cFuvAUkuG10l4/jUk5t9vxbr7epT47I1QyQ K+j5tyjFnenBEOekNu3lgsUEqBWHWJt6uCbJM/85pPowiddgsxv+qsA+n6r0kdUKQTgf Uk4zDv/l50k1QI2aZjxKqII0lCBirgjlwQpksedWDpWv0b5DJl/+VEum6i7ZqppDddr4 ZTmbnkSnNJF2goL7lQwhJ+J4jD4kLV77kDFvXKBR2QSvioJ5iLUhftfwxYOW2OSFF/JY OJXg== X-Gm-Message-State: AGi0PuaHuURYx2q4JRtczMFaW3Md2MEJmyN70c+kx8JpCPjygO8H7zZ2 JMI9VSqXsFh83LWZp/zSo5nAhFLOrUI= X-Google-Smtp-Source: APiQypI+a6zAj29kPbFjRedpgbvoKvvS89tQgCaACNA9Do9tFz+BCWEBB+FO+LOGj/NlLxBg3+HY+A== X-Received: by 2002:a1c:dd8a:: with SMTP id u132mr2683843wmg.87.1588750012241; Wed, 06 May 2020 00:26:52 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.185]) by smtp.gmail.com with ESMTPSA id p8sm1265556wre.11.2020.05.06.00.26.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 May 2020 00:26:51 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Oliver Linden'" , References: <003701d622e4$fe8e12e0$fbaa38a0$@xen.org> <559b80d6-e1bf-e822-deaa-e5f06b1c2f9f@helimail.de> In-Reply-To: <559b80d6-e1bf-e822-deaa-e5f06b1c2f9f@helimail.de> Subject: RE: Likely bug in the PV driver v9.0 Date: Wed, 6 May 2020 08:26:50 +0100 Message-ID: <007d01d62377$b5fb3d30$21f1b790$@xen.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007E_01D62380.17C41200" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQG9IJ9vpX/oWXBdLX78RYa0vQCcNQK7bUz4AXOH5kioqzTYoA== Content-Language: en-gb X-BeenThere: win-pv-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Developer list for the Windows PV Drivers subproject List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Errors-To: win-pv-devel-bounces@lists.xenproject.org Sender: "win-pv-devel" This is a multipart message in MIME format. ------=_NextPart_000_007E_01D62380.17C41200 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Oliver, =20 Xen 4.9 and Ubuntu 18.04 are clearly both a little old. I guess it is = possible that changes in netback have caused problems. I think the next = step is probably to disable all offloads (checksum and LSO) in advanced = properties pane for the PV network frontend and see if the problem still = exists. If that doesn=E2=80=99t have any effect then next would be to = collect wireshark traces and look for oddities around RDP login. =20 Cheers, =20 Paul =20 =20 From: Oliver Linden =20 Sent: 05 May 2020 18:38 To: paul@xen.org; win-pv-devel@lists.xenproject.org Subject: Re: Likely bug in the PV driver v9.0 =20 Hello Paul, thanks a lot for your reply. I already reached out to the Xen IRC = channels but didn't get a response besides the email address I've used = for my initial email. The Windows firewall settings don't have any influence on the behavior. = I tested that already. But as far as I can recall I had the drivers = installed on a Windows 10 1909 DomU on my old server running an upgraded = ubuntu 18.04 with Xen 4.9 and xend still being active (originally server = install date was Dec 2012 with ubuntu 12.04 and their Xen version). With this setup the v9 drivers were working with RDP. Does this give you = any hint/idea? Best, Oliver Am 05.05.20 um 15:56 schrieb Paul Durrant: Hi Oliver, =20 I can only think this is a checksumming issue. I can=E2=80=99t see how = else a network driver operating no higher than L4 (for checksum/LSO) = would be able to affect a very specific part of a higher level protocol. = Although, one thing to watch out for=E2=80=A6 in the past I have seen = Windows do things like re-enabling firewall rules when there is a change = in the network stack so you might want to check that. =20 Cheers, =20 Paul =20 From: win-pv-devel = On Behalf Of Oliver Linden Sent: 04 May 2020 18:06 To: win-pv-devel@lists.xenproject.org = =20 Subject: Likely bug in the PV driver v9.0 =20 Dear all, I'm observing an annoying bug with the v9 Windows PV drivers. It's easy = reproducible here on my side: Dom0: ubuntu 20.04 freshly installed around Easter with there version of Xen = (4.11) and only using the xl tool-stack. DomU: With every fresh installation of Windows 10 v1909 German the following = can be reproduced: * Everything is working but slow as expected * Installation of the v9 drivers works well without any issues and = results in significantly improved speed but RDP connections to such a machine aren't possible anymore. The RDP = service always asks for a user/PW but never accepts it. To be precise, = the RDP connections are working * with the plain vanilla installation * with the v9 drivers being installed except the network class & driver Since I'm using my Windows machines predominately with RDP clients it = would be great if this can be solved. Please let me know if you need any = kind of details from my side. Best, Oliver =20 ------=_NextPart_000_007E_01D62380.17C41200 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi = Oliver,

 =

=C2=A0 Xen 4.9 and Ubuntu 18.04 are = clearly both a little old. I guess it is possible that changes in = netback have caused problems. I think the next step is probably to = disable all offloads (checksum and LSO) in advanced properties pane for = the PV network frontend and see if the problem still exists. If that = doesn=E2=80=99t have any effect then next would be to collect wireshark traces and look for oddities around RDP = login.

 =

=C2=A0 Cheers,

 =

=C2=A0=C2=A0=C2=A0 = Paul

 =

 =

From: Oliver Linden = <oliver_linden@helimail.de>
Sent: 05 May 2020 = 18:38
To: paul@xen.org; = win-pv-devel@lists.xenproject.org
Subject: Re: Likely bug in = the PV driver v9.0

 

Hello = Paul,

thanks a lot for your reply. I already reached = out to the Xen IRC channels but didn't get a response besides the email = address I've used for my initial email.

The Windows = firewall settings don't have any influence on the behavior. I tested = that already. But as far as I can recall I had the drivers installed on = a Windows 10 1909 DomU on my old server running an upgraded ubuntu 18.04 = with Xen 4.9 and xend still being active (originally server install date = was Dec 2012 with ubuntu 12.04 and their Xen = version).

With this setup the v9 drivers were working = with RDP. Does this give you any hint/idea?

Best, = Oliver

Am 05.05.20 um 15:56 = schrieb Paul Durrant:

Hi = Oliver,

 

=C2=A0 I can only think this is a = checksumming issue. I can=E2=80=99t see how else a network driver = operating no higher than L4 (for checksum/LSO) would be able to affect a = very specific part of a higher level protocol. Although, one thing to = watch out for=E2=80=A6 in the past I have seen Windows do things like = re-enabling firewall rules when there is a change in the network stack = so you might want to check that.

 

=C2=A0 Cheers,

 

=C2=A0=C2=A0=C2=A0 = Paul

 

From: win-pv-devel <win-pv-deve= l-bounces@lists.xenproject.org> On Behalf Of Oliver = Linden
Sent: 04 May 2020 18:06
To: win-pv-devel@lists.xenp= roject.org
Subject: Likely bug in the PV driver = v9.0

 

Dear all,

I'm = observing an annoying bug with the v9 Windows PV drivers. It's easy = reproducible here on my side:

Dom0:
ubuntu 20.04 = freshly installed around Easter with there version of Xen (4.11) and = only using the xl tool-stack.

DomU:
With every fresh = installation of Windows 10 v1909 German the following can be = reproduced:

  • Everything is = working but slow as expected
  • Installation of the = v9 drivers works well without any issues and results in significantly = improved = speed

but

RDP connections to = such a machine aren't possible anymore. The RDP service always asks for = a user/PW but never accepts it. To be precise, the RDP connections are = working

  • with the plain = vanilla installation
  • with the v9 drivers = being installed except the network class & = driver

Since I'm using my Windows = machines predominately with RDP clients it would be great if this can be = solved. Please let me know if you need any kind of details from my = side.

Best, Oliver

 

------=_NextPart_000_007E_01D62380.17C41200-- From win-pv-devel-bounces@lists.xenproject.org Wed May 06 07:27:18 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Wed, 06 May 2020 07:27:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jWESc-0004ly-J1; Wed, 06 May 2020 07:27:18 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jW1WM-0004ta-PC for win-pv-devel@lists.xenproject.org; Tue, 05 May 2020 17:38:19 +0000 X-Inumbo-ID: 33449382-8ef7-11ea-b07b-bc764e2007e4 Received: from mail.hamcom.de (unknown [2001:14f0:0:dc03::37:210]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 33449382-8ef7-11ea-b07b-bc764e2007e4; Tue, 05 May 2020 17:38:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=helimail.de ; s=201711; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=CAT6WBCVOBxFRJt/ksnjPOHMol38+RigH4BgtKrCiUA=; b=rkQ33zaaPt0xeqidRjOF0parMq 2+GUBciXhr7DUI0bZ+lFpbi7KFttlO9p0mcPvv2Mo7opNA5vLTrAXCFuq/pWA7tsp95KZLNiKw8Pp ZMB/y4lCQVo0Jot1oXbGDKWjTi2kINEzdlWmHDc3z802+ZfwCZjtMzOEpeCCmUQu6atM=; Received: from [37.83.173.248] (port=58504 helo=[192.168.1.100]) by mail.hamcom.de with esmtpa (Exim 4.92.3) (envelope-from ) id 1jW1WI-0007xA-Vd; Tue, 05 May 2020 19:38:15 +0200 X-HeLi-id: cfcd208495d565ef66e7dff9f98764da Subject: Re: Likely bug in the PV driver v9.0 To: paul@xen.org, win-pv-devel@lists.xenproject.org References: <003701d622e4$fe8e12e0$fbaa38a0$@xen.org> From: Oliver Linden Message-ID: <559b80d6-e1bf-e822-deaa-e5f06b1c2f9f@helimail.de> Date: Tue, 5 May 2020 19:38:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <003701d622e4$fe8e12e0$fbaa38a0$@xen.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lRoSFnY7tOlACtmi5i2syBMvc5MdompZy" X-Mailman-Approved-At: Wed, 06 May 2020 07:27:17 +0000 X-BeenThere: win-pv-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Developer list for the Windows PV Drivers subproject List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: win-pv-devel-bounces@lists.xenproject.org Sender: "win-pv-devel" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lRoSFnY7tOlACtmi5i2syBMvc5MdompZy Content-Type: multipart/mixed; boundary="gvSuV2MeaHyDBlAESCIwBMGy8fMYQ0eXn"; protected-headers="v1" From: Oliver Linden To: paul@xen.org, win-pv-devel@lists.xenproject.org Message-ID: <559b80d6-e1bf-e822-deaa-e5f06b1c2f9f@helimail.de> Subject: Re: Likely bug in the PV driver v9.0 References: <003701d622e4$fe8e12e0$fbaa38a0$@xen.org> In-Reply-To: <003701d622e4$fe8e12e0$fbaa38a0$@xen.org> --gvSuV2MeaHyDBlAESCIwBMGy8fMYQ0eXn Content-Type: multipart/alternative; boundary="------------26C653B3AC067534FB034A95" Content-Language: de-DE This is a multi-part message in MIME format. --------------26C653B3AC067534FB034A95 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Paul, thanks a lot for your reply. I already reached out to the Xen IRC channels but didn't get a response besides the email address I've used for my initial email. The Windows firewall settings don't have any influence on the behavior. I tested that already. But as far as I can recall I had the drivers installed on a Windows 10 1909 DomU on my old server running an upgraded ubuntu 18.04 with Xen 4.9 and xend still being active (originally server install date was Dec 2012 with ubuntu 12.04 and their Xen version). With this setup the v9 drivers were working with RDP. Does this give you any hint/idea? Best, Oliver Am 05.05.20 um 15:56 schrieb Paul Durrant: > > Hi Oliver, > > =C2=A0 > > =C2=A0 I can only think this is a checksumming issue. I can=E2=80=99t s= ee how else > a network driver operating no higher than L4 (for checksum/LSO) would > be able to affect a very specific part of a higher level protocol. > Although, one thing to watch out for=E2=80=A6 in the past I have seen W= indows > do things like re-enabling firewall rules when there is a change in > the network stack so you might want to check that. > > =C2=A0 > > =C2=A0 Cheers, > > =C2=A0 > > =C2=A0=C2=A0=C2=A0 Paul > > =C2=A0 > > *From:*win-pv-devel *On > Behalf Of *Oliver Linden > *Sent:* 04 May 2020 18:06 > *To:* win-pv-devel@lists.xenproject.org > *Subject:* Likely bug in the PV driver v9.0 > > =C2=A0 > > Dear all, > > I'm observing an annoying bug with the v9 Windows PV drivers. It's > easy reproducible here on my side: > > Dom0: > ubuntu 20.04 freshly installed around Easter with there version of Xen > (4.11) and only using the xl tool-stack. > > DomU: > With every fresh installation of Windows 10 v1909 German the following > can be reproduced: > > * Everything is working but slow as expected > * Installation of the v9 drivers works well without any issues and > results in significantly improved speed > > but > > RDP connections to such a machine aren't possible anymore. The RDP > service always asks for a user/PW but never accepts it. To be > precise, the RDP connections are working > > * with the plain vanilla installation > * with the v9 drivers being installed *except the network class & > driver* > > Since I'm using my Windows machines predominately with RDP clients it > would be great if this can be solved. Please let me know if you need > any kind of details from my side. > > Best, Oliver > > =C2=A0 > --------------26C653B3AC067534FB034A95 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hello Paul,

thanks a lot for your reply. I already reached out to the Xen IRC channels but didn't get a response besides the email address I've used for my initial email.

The Windows firewall settings don't have any influence on the behavior. I tested that already. But as far as I can recall I had the drivers installed on a Windows 10 1909 DomU on my old server running an upgraded ubuntu 18.04 with Xen 4.9 and xend still being active (originally server install date was Dec 2012 with ubuntu 12.04 and their Xen version).

With this setup the v9 drivers were working with RDP. Does this give you any hint/idea?

Best, Oliver

Am 05.05.20 um 15:56 schrieb Paul Durrant:

Hi Oliver,

=C2= =A0

=C2=A0 I can only think t= his is a checksumming issue. I can=E2=80=99t see how else a network driver operating no high= er than L4 (for checksum/LSO) would be able to affect a very specific part of a higher level protocol. Although, one thing to watch out for=E2=80=A6 in the past I have seen Windo= ws do things like re-enabling firewall rules when there is a change in the network stack so you might want to check that.<= o:p>

=C2= =A0

=C2=A0 Cheers,=

=C2= =A0

=C2=A0=C2=A0=C2=A0 Paul

=C2= =A0

From: win-pv-devel <win-pv-devel-bounces@lists.xenp= roject.org> On Behalf Of Oliver Linden
Sent: 04 May 2020 18:06
To: win-pv-devel@lists.xenproject.= org
Subject: Likely bug in the PV driver v9.0

=C2=A0

Dear all,

I'm observing an annoying bug with the v9 Windows PV drivers. It's easy reproducible here on my side:

Dom0:
ubuntu 20.04 freshly installed around Easter with there version of Xen (4.11) and only using the xl tool-stack.<= /o:p>

DomU:
With every fresh installation of Windows 10 v1909 German the following can be reproduced:

  • Everything is working but slow as expected
  • Installation of the v9 drivers works well without any issues and results in significantly improved speed

but

RDP connections to such a machine aren't possible anymore. The RDP service always asks for a user/PW but never accepts it. To be precise, the RDP connections are working

  • with the plain vanilla installation
  • with the v9 drivers being installed excep= t the network class & driver

Since I'm using my Windows machines predominately with RDP clients it would be great if this can be solved. Please let me know if you need any kind of details from my side.

Best, Oliver

=C2=A0

--------------26C653B3AC067534FB034A95-- --gvSuV2MeaHyDBlAESCIwBMGy8fMYQ0eXn-- --lRoSFnY7tOlACtmi5i2syBMvc5MdompZy Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQG14HRX/gP3AY3+bqqsNqQA1FaigUCXrGkgQAKCRCqsNqQA1Fa ivtsAKD4RmSmi56hxOFGtM7SxdufBpOSRwCgnP0IfhXg/37it8p63Tr38G/NcnY= =cg43 -----END PGP SIGNATURE----- --lRoSFnY7tOlACtmi5i2syBMvc5MdompZy-- From win-pv-devel-bounces@lists.xenproject.org Thu May 07 11:55:00 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 07 May 2020 11:55:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jWf7A-0003Ve-A3; Thu, 07 May 2020 11:54:56 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jWenO-0001jn-SH for win-pv-devel@lists.xenproject.org; Thu, 07 May 2020 11:34:31 +0000 X-Inumbo-ID: b5c90e86-9056-11ea-b07b-bc764e2007e4 Received: from mail.hamcom.de (unknown [2001:14f0:0:dc03::37:209]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b5c90e86-9056-11ea-b07b-bc764e2007e4; Thu, 07 May 2020 11:34:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=helimail.de ; s=201711; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=5ntPJpgvBBR62OgcCtVi/uIzXZ5sOe1Zxu1L8suMfEs=; b=U0CNlfZ6ojbb8CT0CWG5CXxyFr NtajGqOdJQig4K6CY4mTRaBG6MoIZ7O3Mzfmdx3NxKlfjMcfWAAyNc7UPQdpbafDBUTarMnDX4POW 34u+GB8qEMRd+01UvBt2RkbDFabiMmrgd0lVi5yquC+6xtdErlZ7cto8TrJj+5pHW2yk=; Received: from [37.83.173.248] (port=58932 helo=[192.168.1.100]) by mail.hamcom.de with esmtpa (Exim 4.92.3) (envelope-from ) id 1jWenL-0005MT-9S; Thu, 07 May 2020 13:34:27 +0200 X-HeLi-id: cfcd208495d565ef66e7dff9f98764da Subject: Re: Likely bug in the PV driver v9.0 To: paul@xen.org, win-pv-devel@lists.xenproject.org References: <003701d622e4$fe8e12e0$fbaa38a0$@xen.org> <559b80d6-e1bf-e822-deaa-e5f06b1c2f9f@helimail.de> <007d01d62377$b5fb3d30$21f1b790$@xen.org> From: Oliver Linden Message-ID: <49d5c710-2653-9fc3-22de-96b26250592a@helimail.de> Date: Thu, 7 May 2020 13:34:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <007d01d62377$b5fb3d30$21f1b790$@xen.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AwAffPDdP71kzZysItMpg54edQFRplDdp" X-Mailman-Approved-At: Thu, 07 May 2020 11:54:55 +0000 X-BeenThere: win-pv-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Developer list for the Windows PV Drivers subproject List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: win-pv-devel-bounces@lists.xenproject.org Sender: "win-pv-devel" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AwAffPDdP71kzZysItMpg54edQFRplDdp Content-Type: multipart/mixed; boundary="hogEV9cALVmAkz9X8h0ywVyVI66NQDPXF"; protected-headers="v1" From: Oliver Linden To: paul@xen.org, win-pv-devel@lists.xenproject.org Message-ID: <49d5c710-2653-9fc3-22de-96b26250592a@helimail.de> Subject: Re: Likely bug in the PV driver v9.0 References: <003701d622e4$fe8e12e0$fbaa38a0$@xen.org> <559b80d6-e1bf-e822-deaa-e5f06b1c2f9f@helimail.de> <007d01d62377$b5fb3d30$21f1b790$@xen.org> In-Reply-To: <007d01d62377$b5fb3d30$21f1b790$@xen.org> --hogEV9cALVmAkz9X8h0ywVyVI66NQDPXF Content-Type: multipart/alternative; boundary="------------DC3676B1D99BF998AADE53FB" Content-Language: en-US This is a multi-part message in MIME format. --------------DC3676B1D99BF998AADE53FB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Paul, that was a perfect hint! Disabling all features in the advanced properties pane allowed to reconnect via RDP. I subsequently activated the features and was able to nail it down to the two "TCP Checksum Offload (IPv[46])" entries. For those two you need to set them to either "Disabled" or "RX enabled". TX and RX&TX enabled are breaking RDP connectivity. Many thanks for your support, it's highly appreciated. Best, Oliver Am 06.05.20 um 09:26 schrieb Paul Durrant: > > Hi Oliver, > > =C2=A0 > > =C2=A0 Xen 4.9 and Ubuntu 18.04 are clearly both a little old. I guess = it > is possible that changes in netback have caused problems. I think the > next step is probably to disable all offloads (checksum and LSO) in > advanced properties pane for the PV network frontend and see if the > problem still exists. If that doesn=E2=80=99t have any effect then next= would > be to collect wireshark traces and look for oddities around RDP login. > > =C2=A0 > > =C2=A0 Cheers, > > =C2=A0 > > =C2=A0=C2=A0=C2=A0 Paul > > =C2=A0 > > =C2=A0 > > *From:*Oliver Linden > *Sent:* 05 May 2020 18:38 > *To:* paul@xen.org; win-pv-devel@lists.xenproject.org > *Subject:* Re: Likely bug in the PV driver v9.0 > > =C2=A0 > > Hello Paul, > > thanks a lot for your reply. I already reached out to the Xen IRC > channels but didn't get a response besides the email address I've used > for my initial email. > > The Windows firewall settings don't have any influence on the > behavior. I tested that already. But as far as I can recall I had the > drivers installed on a Windows 10 1909 DomU on my old server running > an upgraded ubuntu 18.04 with Xen 4.9 and xend still being active > (originally server install date was Dec 2012 with ubuntu 12.04 and > their Xen version). > > With this setup the v9 drivers were working with RDP. Does this give > you any hint/idea? > > Best, Oliver > > Am 05.05.20 um 15:56 schrieb Paul Durrant: > > Hi Oliver, > > =C2=A0 > > =C2=A0 I can only think this is a checksumming issue. I can=E2=80=99= t see how > else a network driver operating no higher than L4 (for > checksum/LSO) would be able to affect a very specific part of a > higher level protocol. Although, one thing to watch out for=E2=80=A6= in > the past I have seen Windows do things like re-enabling firewall > rules when there is a change in the network stack so you might > want to check that. > > =C2=A0 > > =C2=A0 Cheers, > > =C2=A0 > > =C2=A0=C2=A0=C2=A0 Paul > > =C2=A0 > > *From:*win-pv-devel > *On Behalf Of > *Oliver Linden > *Sent:* 04 May 2020 18:06 > *To:* win-pv-devel@lists.xenproject.org > > *Subject:* Likely bug in the PV driver v9.0 > > =C2=A0 > > Dear all, > > I'm observing an annoying bug with the v9 Windows PV drivers. It's > easy reproducible here on my side: > > Dom0: > ubuntu 20.04 freshly installed around Easter with there version of > Xen (4.11) and only using the xl tool-stack. > > DomU: > With every fresh installation of Windows 10 v1909 German the > following can be reproduced: > > * Everything is working but slow as expected > * Installation of the v9 drivers works well without any issues > and results in significantly improved speed > > but > > RDP connections to such a machine aren't possible anymore. The > RDP service always asks for a user/PW but never accepts it. To > be precise, the RDP connections are working > > * with the plain vanilla installation > * with the v9 drivers being installed *except the network class > & driver* > > Since I'm using my Windows machines predominately with RDP clients > it would be great if this can be solved. Please let me know if you > need any kind of details from my side. > > Best, Oliver > > =C2=A0 > --------------DC3676B1D99BF998AADE53FB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Paul,

that was a perfect hint!

Disabling all features in the advanced properties pane allowed to reconnect via RDP.

I subsequently activated the features and was able to nail it down to the two "TCP Checksum Offload (IPv[46])" entries. For those two you need to set them to either "Disabled" or "RX enabled". TX and RX&TX enabled are breaking RDP connectivity.

Many thanks for your support, it's highly appreciated.

Best, Oliver

Am 06.05.20 um 09:26 schrieb Paul Durrant:

Hi Oliver,

=C2= =A0

=C2=A0 Xen 4.9 and Ubuntu= 18.04 are clearly both a little old. I guess it is possible that changes in netback have caused problems. I think the next step is probably to disable all offloads (checksum and LSO) in advanced properties pane for the PV network frontend and see if the problem still exists. If that doesn=E2=80=99t = have any effect then next would be to collect wireshark traces and look for oddities around RDP login.

=C2= =A0

=C2=A0 Cheers,=

=C2= =A0

=C2=A0=C2=A0=C2=A0 Paul

=C2= =A0

=C2= =A0

From: Oliver Linden <oliver_linden@helimail.de> =
Sent: 05 May 2020 18:38
To: paul@xen.org; win-pv-devel@lists.xenproject.org Subject: Re: Likely bug in the PV driver v9.0

=C2=A0

Hello Paul,

thanks a lot for your reply. I already reached out to the Xen IRC channels but didn't get a response besides the email address I've used for my initial email.

The Windows firewall settings don't have any influence on the behavior. I tested that already. But as far as I can recall I had the drivers installed on a Windows 10 1909 DomU on my old server running an upgraded ubuntu 18.04 with Xen 4.9 and xend still being active (originally server install date was Dec 2012 with ubuntu 12.04 and their Xen version).

With this setup the v9 drivers were working with RDP. Does this give you any hint/idea?

Best, Oliver

Am 05.05.20 um 15:56 schrieb Paul Durrant:

Hi Oliver,

=C2=A0=

=C2=A0 I can only thi= nk this is a checksumming issue. I can=E2=80=99t see how els= e a network driver operating no higher than L4 (for checksum/LSO) would be able to affect a very specific part of a higher level protocol. Although, one thing to watch out for=E2=80=A6 in the past I have seen Windows do= things like re-enabling firewall rules when there is a change in the network stack so you might want to check that.

=C2=A0=

=C2=A0 Cheers,=

=C2=A0=

=C2=A0=C2=A0=C2=A0 Pa= ul

=C2=A0=

From: win-pv-devel <win-pv-devel-bounces= @lists.xenproject.org> On Behalf Of Oliver Linden
Sent: 04 May 2020 18:06
To: win-pv-devel@lists.xenpr= oject.org
Subject: Likely bug in the PV driver v9.0

=C2=A0

Dear all,

I'm observing an annoying bug with the v9 Windows PV drivers. It's easy reproducible here on my side:

Dom0:
ubuntu 20.04 freshly installed around Easter with there version of Xen (4.11) and only using the xl tool-stack.

DomU:
With every fresh installation of Windows 10 v1909 German the following can be reproduced:

  • Everything is working but slow as expected
  • Installation of the v9 drivers works well without any issues and results in significantly improved speed

but

=

RDP connections to such a machine aren't possible anymore. The RDP service always asks for a user/PW but never accepts it. To be precise, the RDP connections are working

  • with the plain vanilla installation
  • with the v9 drivers being installed e= xcept the network class & driver

Since I'm using my Windows machines predominately with RDP clients it would be great if this can be solved. Please let me know if you need any kind of details from my side.

Best, Oliver

=

=C2=A0

--------------DC3676B1D99BF998AADE53FB-- --hogEV9cALVmAkz9X8h0ywVyVI66NQDPXF-- --AwAffPDdP71kzZysItMpg54edQFRplDdp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQG14HRX/gP3AY3+bqqsNqQA1FaigUCXrPyPQAKCRCqsNqQA1Fa iryiAKC4C1Clyxd6QVlwP2lojnpDX9I4RQCeKcci2sMJvmHAgEiktIvZ7TCYXPM= =2fg5 -----END PGP SIGNATURE----- --AwAffPDdP71kzZysItMpg54edQFRplDdp-- From win-pv-devel-bounces@lists.xenproject.org Thu May 07 12:03:53 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 07 May 2020 12:03:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jWfFp-0004Kf-4Q; Thu, 07 May 2020 12:03:53 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jWfFn-0004Ka-EV for win-pv-devel@lists.xenproject.org; Thu, 07 May 2020 12:03:51 +0000 X-Inumbo-ID: cfa940b0-905a-11ea-ae69-bc764e2007e4 Received: from mail-wr1-x433.google.com (unknown [2a00:1450:4864:20::433]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id cfa940b0-905a-11ea-ae69-bc764e2007e4; Thu, 07 May 2020 12:03:49 +0000 (UTC) Received: by mail-wr1-x433.google.com with SMTP id i15so5628170wrx.10 for ; Thu, 07 May 2020 05:03:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=2NKQctc/yYYlXczaNDW+W+ZykkbtsV/+aOV8poNaZMg=; b=V0PEtKPmSVXgW2OO6E5NUdG7LqZtKyN+bMw0Lc3eQowtbtAZ+6Nl6wXpzY7WZs8I6V WbOAcj3CDyZL1Db/SAvSQ2A9OeUW0nB37wA5xHB9LY6wrIHVgCyVGT9yUB8sPjSn9mMX YI9vsXEleJs+Ddz8x7hIm8Jc0AilVfYnN/UL0JztLAKN8nQgtmWT3qJ9REba3EzNWf9F i0U14ct2t+eGoABh+TvU2recz0+Vlyy/H7fYTWQrLTOBCH2Arq8isx97s8yPxGDBcVXS 1mPL9AibUtps6Ut8RjGIt0TETfWjepGpu9GbfJzbfSGszu4BiNFLdiYpKuI8NASljcea pFDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:references:in-reply-to:subject :date:message-id:mime-version:thread-index:content-language; bh=2NKQctc/yYYlXczaNDW+W+ZykkbtsV/+aOV8poNaZMg=; b=SFjE+P9OC74AiJJJEr50H0edO/vw162w6QyT1Yod/RhM+8+xPPp/qlaMr2mOCPlrIa D3erIQiyUVLxR3OpYDelLvQB2OeLyQS8eMPL/Ob9gCQeyjvaTUxk70rN7irpYAM0yiV4 S/CyNAHSl2/TOj+1aQSr9kZKdCuIDtMQ2HlSX2qi3Vl9ag4XattrqP3cfw3fAlXu1EbG PCqNbL1eEAWSMHJSTB1g5AXwyVh2xq8cYfGgBBFxIOct2n17633ihMk77nCMA6WXrpQW e4/9KJZXLn7BDe48P2Hqv7zJ65xWAKiFumXTfhFtHS66ckhhM1fUzkI7URoL90mGPG3U hvwQ== X-Gm-Message-State: AGi0PuYFVLgkVjf8nf8sVc21v0297caFex96dZgWQSMlaocvIq4IzJg6 n4fuxU3m0yRzAHplbzfyGcw= X-Google-Smtp-Source: APiQypJEFaea1rggK6hRQ22DkFzMdkfCstkSMOlGsFNzfKdi8qvdUY5+cYOyy6fIbVeOsYkNux3jmw== X-Received: by 2002:adf:ee87:: with SMTP id b7mr15434653wro.104.1588853028970; Thu, 07 May 2020 05:03:48 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.187]) by smtp.gmail.com with ESMTPSA id x13sm7804131wmc.5.2020.05.07.05.03.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 May 2020 05:03:48 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Oliver Linden'" , References: <003701d622e4$fe8e12e0$fbaa38a0$@xen.org> <559b80d6-e1bf-e822-deaa-e5f06b1c2f9f@helimail.de> <007d01d62377$b5fb3d30$21f1b790$@xen.org> <49d5c710-2653-9fc3-22de-96b26250592a@helimail.de> In-Reply-To: <49d5c710-2653-9fc3-22de-96b26250592a@helimail.de> Subject: RE: Likely bug in the PV driver v9.0 Date: Thu, 7 May 2020 13:03:46 +0100 Message-ID: <002e01d62467$909e1940$b1da4bc0$@xen.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01D6246F.F2645600" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQG9IJ9vpX/oWXBdLX78RYa0vQCcNQK7bUz4AXOH5kgBCCOG1QJRl87kqJJGCIA= Content-Language: en-gb X-BeenThere: win-pv-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Developer list for the Windows PV Drivers subproject List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Errors-To: win-pv-devel-bounces@lists.xenproject.org Sender: "win-pv-devel" This is a multipart message in MIME format. ------=_NextPart_000_002F_01D6246F.F2645600 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Oliver, =20 That=E2=80=99s interesting. It suggests a bug in the guest tx side = checksum calculation. This is normally done by netback setting up = metadata in skb and having either the kernel or the h/w driver do the = calculation. Disabling the option in the guest means the calculation = will be done in-guest by XENVIF before the segment is passed to netback. = Hence, it sounds like your problem may actually be in your dom0 or NIC = (possibly failing to handle some quirk of the RDP packets). =20 Cheers, =20 Paul =20 =20 From: Oliver Linden =20 Sent: 07 May 2020 12:34 To: paul@xen.org; win-pv-devel@lists.xenproject.org Subject: Re: Likely bug in the PV driver v9.0 =20 Hi Paul, that was a perfect hint! Disabling all features in the advanced properties pane allowed to = reconnect via RDP. I subsequently activated the features and was able to nail it down to = the two "TCP Checksum Offload (IPv[46])" entries. For those two you need = to set them to either "Disabled" or "RX enabled". TX and RX&TX enabled = are breaking RDP connectivity. Many thanks for your support, it's highly appreciated. Best, Oliver Am 06.05.20 um 09:26 schrieb Paul Durrant: Hi Oliver, =20 Xen 4.9 and Ubuntu 18.04 are clearly both a little old. I guess it is = possible that changes in netback have caused problems. I think the next = step is probably to disable all offloads (checksum and LSO) in advanced = properties pane for the PV network frontend and see if the problem still = exists. If that doesn=E2=80=99t have any effect then next would be to = collect wireshark traces and look for oddities around RDP login. =20 Cheers, =20 Paul =20 =20 From: Oliver Linden = =20 Sent: 05 May 2020 18:38 To: paul@xen.org ; = win-pv-devel@lists.xenproject.org = =20 Subject: Re: Likely bug in the PV driver v9.0 =20 Hello Paul, thanks a lot for your reply. I already reached out to the Xen IRC = channels but didn't get a response besides the email address I've used = for my initial email. The Windows firewall settings don't have any influence on the behavior. = I tested that already. But as far as I can recall I had the drivers = installed on a Windows 10 1909 DomU on my old server running an upgraded = ubuntu 18.04 with Xen 4.9 and xend still being active (originally server = install date was Dec 2012 with ubuntu 12.04 and their Xen version). With this setup the v9 drivers were working with RDP. Does this give you = any hint/idea? Best, Oliver Am 05.05.20 um 15:56 schrieb Paul Durrant: Hi Oliver, =20 I can only think this is a checksumming issue. I can=E2=80=99t see how = else a network driver operating no higher than L4 (for checksum/LSO) = would be able to affect a very specific part of a higher level protocol. = Although, one thing to watch out for=E2=80=A6 in the past I have seen = Windows do things like re-enabling firewall rules when there is a change = in the network stack so you might want to check that. =20 Cheers, =20 Paul =20 From: win-pv-devel = On Behalf Of Oliver Linden Sent: 04 May 2020 18:06 To: win-pv-devel@lists.xenproject.org = =20 Subject: Likely bug in the PV driver v9.0 =20 Dear all, I'm observing an annoying bug with the v9 Windows PV drivers. It's easy = reproducible here on my side: Dom0: ubuntu 20.04 freshly installed around Easter with there version of Xen = (4.11) and only using the xl tool-stack. DomU: With every fresh installation of Windows 10 v1909 German the following = can be reproduced: * Everything is working but slow as expected * Installation of the v9 drivers works well without any issues and = results in significantly improved speed but RDP connections to such a machine aren't possible anymore. The RDP = service always asks for a user/PW but never accepts it. To be precise, = the RDP connections are working * with the plain vanilla installation * with the v9 drivers being installed except the network class & driver Since I'm using my Windows machines predominately with RDP clients it = would be great if this can be solved. Please let me know if you need any = kind of details from my side. Best, Oliver =20 ------=_NextPart_000_002F_01D6246F.F2645600 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Oliver,

 =

=C2=A0 That=E2=80=99s interesting. It = suggests a bug in the guest tx side checksum = calculation. This is normally done by netback setting up metadata in = skb and having either the kernel or the h/w = driver do the calculation. Disabling the option in the guest means the = calculation will be done in-guest by XENVIF before the segment is passed = to netback. Hence, it sounds like your problem may actually be in your = dom0 or NIC (possibly failing to handle some quirk of the RDP = packets).

 =

=C2=A0 Cheers,

 =

=C2=A0 Paul

 =

 =

From: Oliver Linden = <oliver_linden@helimail.de>
Sent: 07 May 2020 = 12:34
To: paul@xen.org; = win-pv-devel@lists.xenproject.org
Subject: Re: Likely bug in = the PV driver v9.0

 

Hi Paul,

that = was a perfect hint!

Disabling all features in the = advanced properties pane allowed to reconnect via = RDP.

I subsequently activated the features and was able = to nail it down to the two "TCP Checksum Offload (IPv[46])" = entries. For those two you need to set them to either = "Disabled" or "RX enabled". TX and RX&TX enabled = are breaking RDP connectivity.

Many thanks for your = support, it's highly appreciated.

Best, = Oliver

Am 06.05.20 um 09:26 = schrieb Paul Durrant:

Hi = Oliver,

 

=C2=A0 Xen 4.9 and Ubuntu 18.04 are = clearly both a little old. I guess it is possible that changes in = netback have caused problems. I think the next step is probably to = disable all offloads (checksum and LSO) in advanced properties pane for = the PV network frontend and see if the problem still exists. If that = doesn=E2=80=99t have any effect then next would be to collect wireshark = traces and look for oddities around RDP login.

 

=C2=A0 Cheers,

 

=C2=A0=C2=A0=C2=A0 = Paul

 

 

From: Oliver Linden <oliver_linden@helimail.de&g= t;
Sent: 05 May 2020 18:38
To: paul@xen.org; win-pv-devel@lists.xenp= roject.org
Subject: Re: Likely bug in the PV driver = v9.0

 

Hello = Paul,

thanks a lot for your reply. I already reached = out to the Xen IRC channels but didn't get a response besides the email = address I've used for my initial email.

The Windows = firewall settings don't have any influence on the behavior. I tested = that already. But as far as I can recall I had the drivers installed on = a Windows 10 1909 DomU on my old server running an upgraded ubuntu 18.04 = with Xen 4.9 and xend still being active (originally server install date = was Dec 2012 with ubuntu 12.04 and their Xen = version).

With this setup the v9 drivers were working = with RDP. Does this give you any hint/idea?

Best, = Oliver

Am 05.05.20 um 15:56 = schrieb Paul Durrant:

Hi = Oliver,

 

=C2=A0 I can only think this is a = checksumming issue. I can=E2=80=99t see how else a network driver = operating no higher than L4 (for checksum/LSO) would be able to affect a = very specific part of a higher level protocol. Although, one thing to = watch out for=E2=80=A6 in the past I have seen Windows do things like = re-enabling firewall rules when there is a change in the network stack = so you might want to check that.

 

=C2=A0 Cheers,

 

=C2=A0=C2=A0=C2=A0 = Paul

 

From: win-pv-devel <win-pv-deve= l-bounces@lists.xenproject.org> On Behalf Of Oliver = Linden
Sent: 04 May 2020 18:06
To: win-pv-devel@lists.xenp= roject.org
Subject: Likely bug in the PV driver = v9.0

 

Dear all,

I'm = observing an annoying bug with the v9 Windows PV drivers. It's easy = reproducible here on my side:

Dom0:
ubuntu 20.04 = freshly installed around Easter with there version of Xen (4.11) and = only using the xl tool-stack.

DomU:
With every fresh = installation of Windows 10 v1909 German the following can be = reproduced:

  • Everything is = working but slow as expected
  • Installation of the = v9 drivers works well without any issues and results in significantly = improved = speed

but

RDP connections to = such a machine aren't possible anymore. The RDP service always asks for = a user/PW but never accepts it. To be precise, the RDP connections are = working

  • with the plain = vanilla installation
  • with the v9 drivers = being installed except the network class & = driver

Since I'm using my Windows = machines predominately with RDP clients it would be great if this can be = solved. Please let me know if you need any kind of details from my = side.

Best, Oliver

 

------=_NextPart_000_002F_01D6246F.F2645600-- From win-pv-devel-bounces@lists.xenproject.org Thu May 07 12:49:02 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 07 May 2020 12:49:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jWfxT-0007fb-R9; Thu, 07 May 2020 12:48:59 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jWfbx-00064U-FC for win-pv-devel@lists.xenproject.org; Thu, 07 May 2020 12:26:46 +0000 X-Inumbo-ID: 01b8163c-905e-11ea-b9cf-bc764e2007e4 Received: from mail.hamcom.de (unknown [2001:14f0:0:dc03::37:215]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 01b8163c-905e-11ea-b9cf-bc764e2007e4; Thu, 07 May 2020 12:26:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=helimail.de ; s=201711; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=eyYiKq3kB8KH4MQsmAYC5mQgL3qG3ZUkHvVsGn2fR7o=; b=ZtAIL8RIpEPZqoWmCLepIMjXJU L4J1ouQQdg/L3DxGNq8pkyN6bBl+WfH7p3vYsaUu5sesZViWFIIJR0agynPXhUw+gdcMJXD/ir3Po TcQVZJSB7bHVhcEDyUK9e4kj49JMU3oCcXvX09n8mqa2CR2hjK7RadCxBpP1TAw6Z+dQ=; Received: from [37.83.173.248] (port=59192 helo=[192.168.1.100]) by mail.hamcom.de with esmtpa (Exim 4.92.3) (envelope-from ) id 1jWfbs-00033Y-W2; Thu, 07 May 2020 14:26:41 +0200 X-HeLi-id: cfcd208495d565ef66e7dff9f98764da Subject: Re: Likely bug in the PV driver v9.0 To: paul@xen.org, win-pv-devel@lists.xenproject.org References: <003701d622e4$fe8e12e0$fbaa38a0$@xen.org> <559b80d6-e1bf-e822-deaa-e5f06b1c2f9f@helimail.de> <007d01d62377$b5fb3d30$21f1b790$@xen.org> <49d5c710-2653-9fc3-22de-96b26250592a@helimail.de> <002e01d62467$909e1940$b1da4bc0$@xen.org> From: Oliver Linden Message-ID: <46f028b2-e14c-4889-6ee6-04aa6621778e@helimail.de> Date: Thu, 7 May 2020 14:26:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <002e01d62467$909e1940$b1da4bc0$@xen.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1eMyn2xGgEFom0i7i6Ir06vpG0gLNRWj4" X-Mailman-Approved-At: Thu, 07 May 2020 12:48:59 +0000 X-BeenThere: win-pv-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Developer list for the Windows PV Drivers subproject List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: win-pv-devel-bounces@lists.xenproject.org Sender: "win-pv-devel" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1eMyn2xGgEFom0i7i6Ir06vpG0gLNRWj4 Content-Type: multipart/mixed; boundary="hPimY4JyONbH2fCaKEQM2nzaFnut1jzer"; protected-headers="v1" From: Oliver Linden To: paul@xen.org, win-pv-devel@lists.xenproject.org Message-ID: <46f028b2-e14c-4889-6ee6-04aa6621778e@helimail.de> Subject: Re: Likely bug in the PV driver v9.0 References: <003701d622e4$fe8e12e0$fbaa38a0$@xen.org> <559b80d6-e1bf-e822-deaa-e5f06b1c2f9f@helimail.de> <007d01d62377$b5fb3d30$21f1b790$@xen.org> <49d5c710-2653-9fc3-22de-96b26250592a@helimail.de> <002e01d62467$909e1940$b1da4bc0$@xen.org> In-Reply-To: <002e01d62467$909e1940$b1da4bc0$@xen.org> --hPimY4JyONbH2fCaKEQM2nzaFnut1jzer Content-Type: multipart/alternative; boundary="------------7D06FD939DAED6A48E579565" Content-Language: de-DE This is a multi-part message in MIME format. --------------7D06FD939DAED6A48E579565 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGkgUGF1bCwKCnRoZSBEb20wIGlzIHNpdHRpbmcgb24gYnJhbmQgbmV3IGhhcmR3YXJlIHdp dGggYSBmcmVzaCBpbnN0YWxsZWQgdWJ1bnR1CjIwLjA0IGFuZCB0aGUgTklDIGJlaW5nIHVz ZWQgaXMgdGhlIG9uYm9hcmQgb25lOgoKbHNwY2kgLXZ2OgowOTowMC4wIEV0aGVybmV0IGNv bnRyb2xsZXI6IFJlYWx0ZWsgU2VtaWNvbmR1Y3RvciBDby4sIEx0ZC4KUlRMODExMS84MTY4 Lzg0MTEgUENJIEV4cHJlc3MgR2lnYWJpdCBFdGhlcm5ldCBDb250cm9sbGVyIChyZXYgMTUp CsKgwqDCoMKgwqDCoMKgIFN1YnN5c3RlbTogQVNSb2NrIEluY29ycG9yYXRpb24gTW90aGVy Ym9hcmQgKG9uZSBvZiBtYW55KQrCoMKgwqDCoMKgwqDCoCBDb250cm9sOiBJL08rIE1lbSsg QnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLQpQYXJFcnItIFN0ZXBw aW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4KwrCoMKgwqDCoMKgwqDCoCBTdGF0dXM6IENh cCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LQo8 VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCsKgwqDCoMKgwqDCoMKgIExh dGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMKwqDCoMKgwqDCoMKgwqAgSW50 ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDM1CsKgwqDCoMKgwqDCoMKgIFJlZ2lvbiAw OiBJL08gcG9ydHMgYXQgYjAwMCBbc2l6ZT0yNTZdCsKgwqDCoMKgwqDCoMKgIFJlZ2lvbiAy OiBNZW1vcnkgYXQgZmMzMDQwMDAgKDY0LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9 NEtdCsKgwqDCoMKgwqDCoMKgIFJlZ2lvbiA0OiBNZW1vcnkgYXQgZmMzMDAwMDAgKDY0LWJp dCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9MTZLXQrCoMKgwqDCoMKgwqDCoCBDYXBhYmls aXRpZXM6IFs0MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMKwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIEZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50 PTM3NW1BClBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkKykKwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIFN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5hYmxlLSBEU2Vs PTAgRFNjYWxlPTAgUE1FLQrCoMKgwqDCoMKgwqDCoCBDYXBhYmlsaXRpZXM6IFs1MF0gTVNJ OiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrCsKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCBBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwwqAgRGF0YTogMDAwMArC oMKgwqDCoMKgwqDCoCBDYXBhYmlsaXRpZXM6IFs3MF0gRXhwcmVzcyAodjIpIEVuZHBvaW50 LCBNU0kgMDEKwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIERldkNhcDogTWF4UGF5 bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcwo8NTEybnMsIEwxIDw2 NHVzCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgRXh0 VGFnLSBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0KU2xvdFBvd2Vy TGltaXQgMjYuMDAwVwrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgRGV2Q3RsOiBD b3JyRXJyLSBOb25GYXRhbEVyci0gRmF0YWxFcnItIFVuc3VwUmVxLQrCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFJseGRPcmQrIEV4dFRhZy0gUGhh bnRGdW5jLSBBdXhQd3ItIE5vU25vb3AtCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgNDA5 NiBieXRlcwrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgRGV2U3RhOiBDb3JyRXJy KyBOb25GYXRhbEVyci0gRmF0YWxFcnItIFVuc3VwUmVxLQpBdXhQd3IrIFRyYW5zUGVuZC0K wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIExua0NhcDogUG9ydCAjMCwgU3BlZWQg Mi41R1QvcywgV2lkdGggeDEsIEFTUE0gTDBzIEwxLApFeGl0IExhdGVuY3kgTDBzIHVubGlt aXRlZCwgTDEgPDY0dXMKwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCBDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LSBBU1BNT3B0Q29t cCsKwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIExua0N0bDogQVNQTSBMMSBFbmFi bGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIENvbW1DbGsrCsKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgRXh0U3luY2gtIENsb2NrUE0tIEF1dFdp ZERpcy0gQldJbnQtIEF1dEJXSW50LQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg TG5rU3RhOiBTcGVlZCAyLjVHVC9zIChvayksIFdpZHRoIHgxIChvaykKwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBUckVyci0gVHJhaW4tIFNsb3RD bGsrIERMQWN0aXZlLSBCV01nbXQtIEFCV01nbXQtCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCBEZXZDYXAyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IFJhbmdlIEFCQ0QsIFRpbWVv dXREaXMrLApOUk9QclByUC0sIExUUisKwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIDEwQml0VGFnQ29tcC0sIDEwQml0VGFnUmVxLSwgT0JGRiBW aWEKbWVzc2FnZS9XQUtFIywgRXh0Rm10LSwgRUVUTFBQcmVmaXgtCsKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBFbWVyZ2VuY3lQb3dlclJlZHVj dGlvbiBOb3QgU3VwcG9ydGVkLApFbWVyZ2VuY3lQb3dlclJlZHVjdGlvbkluaXQtCsKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBGUlMtLCBUUEhD b21wLSwgRXh0VFBIQ29tcC0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIEF0b21pY09wc0NhcDogMzJiaXQtIDY0Yml0LSAxMjhiaXRDQVMtCsKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVv dXQ6IDUwdXMgdG8gNTBtcywgVGltZW91dERpcy0sCkxUUi0sIE9CRkYgRGlzYWJsZWQKwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIEF0b21pY09w c0N0bDogUmVxRW4tCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBMbmtDdGwyOiBU YXJnZXQgTGluayBTcGVlZDogMi41R1QvcywgRW50ZXJDb21wbGlhbmNlLQpTcGVlZERpcy0K wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFRyYW5z bWl0IE1hcmdpbjogTm9ybWFsIE9wZXJhdGluZyBSYW5nZSwKRW50ZXJNb2RpZmllZENvbXBs aWFuY2UtIENvbXBsaWFuY2VTT1MtCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCCsKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBMbmtTdGEyOiBDdXJyZW50IERlLWVtcGhhc2lzIExl dmVsOiAtNmRCLApFcXVhbGl6YXRpb25Db21wbGV0ZS0sIEVxdWFsaXphdGlvblBoYXNlMS0K wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIEVxdWFs aXphdGlvblBoYXNlMi0sIEVxdWFsaXphdGlvblBoYXNlMy0sCkxpbmtFcXVhbGl6YXRpb25S ZXF1ZXN0LQrCoMKgwqDCoMKgwqDCoCBDYXBhYmlsaXRpZXM6IFtiMF0gTVNJLVg6IEVuYWJs ZSsgQ291bnQ9NCBNYXNrZWQtCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBWZWN0 b3IgdGFibGU6IEJBUj00IG9mZnNldD0wMDAwMDAwMArCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgUEJBOiBCQVI9NCBvZmZzZXQ9MDAwMDA4MDAKwqDCoMKgwqDCoMKgwqAgQ2Fw YWJpbGl0aWVzOiBbMTAwIHYyXSBBZHZhbmNlZCBFcnJvciBSZXBvcnRpbmcKwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIFVFU3RhOsKgIERMUC0gU0RFUy0gVExQLSBGQ1AtIENt cGx0VE8tIENtcGx0QWJydC0KVW54Q21wbHQtIFJ4T0YtIE1hbGZUTFAtIEVDUkMtIFVuc3Vw UmVxLSBBQ1NWaW9sLQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgVUVNc2s6wqAg RExQLSBTREVTLSBUTFAtIEZDUC0gQ21wbHRUTy0gQ21wbHRBYnJ0LQpVbnhDbXBsdC0gUnhP Ri0gTWFsZlRMUC0gRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtCsKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCBVRVN2cnQ6IERMUCsgU0RFUysgVExQLSBGQ1ArIENtcGx0VE8tIENt cGx0QWJydC0KVW54Q21wbHQtIFJ4T0YrIE1hbGZUTFArIEVDUkMtIFVuc3VwUmVxLSBBQ1NW aW9sLQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgQ0VTdGE6wqAgUnhFcnItIEJh ZFRMUC0gQmFkRExMUC0gUm9sbG92ZXItIFRpbWVvdXQtCkFkdk5vbkZhdGFsRXJyLQrCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgQ0VNc2s6wqAgUnhFcnItIEJhZFRMUC0gQmFk RExMUC0gUm9sbG92ZXItIFRpbWVvdXQtCkFkdk5vbkZhdGFsRXJyKwrCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgQUVSQ2FwOiBGaXJzdCBFcnJvciBQb2ludGVyOiAwMCwgRUNS Q0dlbkNhcCsgRUNSQ0dlbkVuLQpFQ1JDQ2hrQ2FwKyBFQ1JDQ2hrRW4tCsKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgTXVsdEhkclJlY0NhcC0gTXVs dEhkclJlY0VuLSBUTFBQZnhQcmVzLSBIZHJMb2dDYXAtCsKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCBIZWFkZXJMb2c6IDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAw MDAwCsKgwqDCoMKgwqDCoMKgIENhcGFiaWxpdGllczogWzE0MCB2MV0gVmlydHVhbCBDaGFu bmVsCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBDYXBzOsKgwqAgTFBFVkM9MCBS ZWZDbGs9MTAwbnMgUEFURW50cnlCaXRzPTEKwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIEFyYjrCoMKgwqAgRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4LQrCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgQ3RybDrCoMKgIEFyYlNlbGVjdD1GaXhlZArCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgU3RhdHVzOiBJblByb2dyZXNzLQrCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgVkMwOsKgwqDCoCBDYXBzOsKgwqAgUEFUT2Zmc2V0PTAw IE1heFRpbWVTbG90cz0xIFJlalNub29wVHJhbnMtCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgQXJiOsKgwqDCoCBGaXhlZC0gV1JSMzItIFdSUjY0 LSBXUlIxMjgtIFRXUlIxMjgtCldSUjI1Ni0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCBDdHJsOsKgwqAgRW5hYmxlKyBJRD0wIEFyYlNlbGVjdD1G aXhlZCBUQy9WQz0wMQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIFN0YXR1czogTmVnb1BlbmRpbmctIEluUHJvZ3Jlc3MtCsKgwqDCoMKgwqDCoMKg IENhcGFiaWxpdGllczogWzE2MCB2MV0gRGV2aWNlIFNlcmlhbCBOdW1iZXIgN2EtOTYtMWEt NTktYTEtYTgtMDAtMDAKwqDCoMKgwqDCoMKgwqAgQ2FwYWJpbGl0aWVzOiBbMTcwIHYxXSBM YXRlbmN5IFRvbGVyYW5jZSBSZXBvcnRpbmcKwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIE1heCBzbm9vcCBsYXRlbmN5OiAwbnMKwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIE1heCBubyBzbm9vcCBsYXRlbmN5OiAwbnMKwqDCoMKgwqDCoMKgwqAgQ2FwYWJpbGl0 aWVzOiBbMTc4IHYxXSBMMSBQTSBTdWJzdGF0ZXMKwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIEwxU3ViQ2FwOiBQQ0ktUE1fTDEuMisgUENJLVBNX0wxLjErIEFTUE1fTDEuMisK QVNQTV9MMS4xKyBMMV9QTV9TdWJzdGF0ZXMrCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFBvcnRDb21tb25Nb2RlUmVzdG9yZVRpbWU9MTUw dXMKUG9ydFRQb3dlck9uVGltZT0xNTB1cwrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgTDFTdWJDdGwxOiBQQ0ktUE1fTDEuMi0gUENJLVBNX0wxLjEtIEFTUE1fTDEuMi0gQVNQ TV9MMS4xLQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIFRfQ29tbW9uTW9kZT0wdXMgTFRSMS4yX1RocmVzaG9sZD0wbnMKwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIEwxU3ViQ3RsMjogVF9Qd3JPbj0xMHVzCsKgwqDCoMKg wqDCoMKgIEtlcm5lbCBkcml2ZXIgaW4gdXNlOiByODE2OQrCoMKgwqDCoMKgwqDCoCBLZXJu ZWwgbW9kdWxlczogcjgxNjkKCkFsbCBzZXR0aW5ncyBhcmUgb24gZGVmYXVsdC4KCkJlc3Qs IE9saXZlcgoKCkFtIDA3LjA1LjIwIHVtIDE0OjAzIHNjaHJpZWIgUGF1bCBEdXJyYW50Ogo+ Cj4gT2xpdmVyLAo+Cj4gwqAKPgo+IMKgIFRoYXTigJlzIGludGVyZXN0aW5nLiBJdCBzdWdn ZXN0cyBhIGJ1ZyBpbiB0aGUgZ3Vlc3QgdHggc2lkZSBjaGVja3N1bQo+IGNhbGN1bGF0aW9u LiBUaGlzIGlzIG5vcm1hbGx5IGRvbmUgYnkgbmV0YmFjayBzZXR0aW5nIHVwIG1ldGFkYXRh IGluCj4gc2tiIGFuZCBoYXZpbmcgZWl0aGVyIHRoZSBrZXJuZWwgb3IgdGhlIGgvdyBkcml2 ZXIgZG8gdGhlIGNhbGN1bGF0aW9uLgo+IERpc2FibGluZyB0aGUgb3B0aW9uIGluIHRoZSBn dWVzdCBtZWFucyB0aGUgY2FsY3VsYXRpb24gd2lsbCBiZSBkb25lCj4gaW4tZ3Vlc3QgYnkg WEVOVklGIGJlZm9yZSB0aGUgc2VnbWVudCBpcyBwYXNzZWQgdG8gbmV0YmFjay4gSGVuY2Us IGl0Cj4gc291bmRzIGxpa2UgeW91ciBwcm9ibGVtIG1heSBhY3R1YWxseSBiZSBpbiB5b3Vy IGRvbTAgb3IgTklDIChwb3NzaWJseQo+IGZhaWxpbmcgdG8gaGFuZGxlIHNvbWUgcXVpcmsg b2YgdGhlIFJEUCBwYWNrZXRzKS4KPgo+IMKgCj4KPiDCoCBDaGVlcnMsCj4KPiDCoAo+Cj4g wqAgUGF1bAo+Cj4gwqAKPgo+IMKgCj4KPiAqRnJvbToqT2xpdmVyIExpbmRlbiA8b2xpdmVy X2xpbmRlbkBoZWxpbWFpbC5kZT4KPiAqU2VudDoqIDA3IE1heSAyMDIwIDEyOjM0Cj4gKlRv OiogcGF1bEB4ZW4ub3JnOyB3aW4tcHYtZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKPiAq U3ViamVjdDoqIFJlOiBMaWtlbHkgYnVnIGluIHRoZSBQViBkcml2ZXIgdjkuMAo+Cj4gwqAK Pgo+IEhpIFBhdWwsCj4KPiB0aGF0IHdhcyBhIHBlcmZlY3QgaGludCEKPgo+IERpc2FibGlu ZyBhbGwgZmVhdHVyZXMgaW4gdGhlIGFkdmFuY2VkIHByb3BlcnRpZXMgcGFuZSBhbGxvd2Vk IHRvCj4gcmVjb25uZWN0IHZpYSBSRFAuCj4KPiBJIHN1YnNlcXVlbnRseSBhY3RpdmF0ZWQg dGhlIGZlYXR1cmVzIGFuZCB3YXMgYWJsZSB0byBuYWlsIGl0IGRvd24gdG8KPiB0aGUgdHdv ICJUQ1AgQ2hlY2tzdW0gT2ZmbG9hZCAoSVB2WzQ2XSkiIGVudHJpZXMuIEZvciB0aG9zZSB0 d28geW91Cj4gbmVlZCB0byBzZXQgdGhlbSB0byBlaXRoZXIgIkRpc2FibGVkIiBvciAiUlgg ZW5hYmxlZCIuIFRYIGFuZCBSWCZUWAo+IGVuYWJsZWQgYXJlIGJyZWFraW5nIFJEUCBjb25u ZWN0aXZpdHkuCj4KPiBNYW55IHRoYW5rcyBmb3IgeW91ciBzdXBwb3J0LCBpdCdzIGhpZ2hs eSBhcHByZWNpYXRlZC4KPgo+IEJlc3QsIE9saXZlcgo+Cj4gQW0gMDYuMDUuMjAgdW0gMDk6 MjYgc2NocmllYiBQYXVsIER1cnJhbnQ6Cj4KPiAgICAgSGkgT2xpdmVyLAo+Cj4gICAgIMKg Cj4KPiAgICAgwqAgWGVuIDQuOSBhbmQgVWJ1bnR1IDE4LjA0IGFyZSBjbGVhcmx5IGJvdGgg YSBsaXR0bGUgb2xkLiBJIGd1ZXNzCj4gICAgIGl0IGlzIHBvc3NpYmxlIHRoYXQgY2hhbmdl cyBpbiBuZXRiYWNrIGhhdmUgY2F1c2VkIHByb2JsZW1zLiBJCj4gICAgIHRoaW5rIHRoZSBu ZXh0IHN0ZXAgaXMgcHJvYmFibHkgdG8gZGlzYWJsZSBhbGwgb2ZmbG9hZHMgKGNoZWNrc3Vt Cj4gICAgIGFuZCBMU08pIGluIGFkdmFuY2VkIHByb3BlcnRpZXMgcGFuZSBmb3IgdGhlIFBW IG5ldHdvcmsgZnJvbnRlbmQKPiAgICAgYW5kIHNlZSBpZiB0aGUgcHJvYmxlbSBzdGlsbCBl eGlzdHMuIElmIHRoYXQgZG9lc27igJl0IGhhdmUgYW55Cj4gICAgIGVmZmVjdCB0aGVuIG5l eHQgd291bGQgYmUgdG8gY29sbGVjdCB3aXJlc2hhcmsgdHJhY2VzIGFuZCBsb29rIGZvcgo+ ICAgICBvZGRpdGllcyBhcm91bmQgUkRQIGxvZ2luLgo+Cj4gICAgIMKgCj4KPiAgICAgwqAg Q2hlZXJzLAo+Cj4gICAgIMKgCj4KPiAgICAgwqDCoMKgIFBhdWwKPgo+ICAgICDCoAo+Cj4g ICAgIMKgCj4KPiAgICAgKkZyb206Kk9saXZlciBMaW5kZW4gPG9saXZlcl9saW5kZW5AaGVs aW1haWwuZGU+Cj4gICAgIDxtYWlsdG86b2xpdmVyX2xpbmRlbkBoZWxpbWFpbC5kZT4KPiAg ICAgKlNlbnQ6KiAwNSBNYXkgMjAyMCAxODozOAo+ICAgICAqVG86KiBwYXVsQHhlbi5vcmcg PG1haWx0bzpwYXVsQHhlbi5vcmc+Owo+ICAgICB3aW4tcHYtZGV2ZWxAbGlzdHMueGVucHJv amVjdC5vcmcKPiAgICAgPG1haWx0bzp3aW4tcHYtZGV2ZWxAbGlzdHMueGVucHJvamVjdC5v cmc+Cj4gICAgICpTdWJqZWN0OiogUmU6IExpa2VseSBidWcgaW4gdGhlIFBWIGRyaXZlciB2 OS4wCj4KPiAgICAgwqAKPgo+ICAgICBIZWxsbyBQYXVsLAo+Cj4gICAgIHRoYW5rcyBhIGxv dCBmb3IgeW91ciByZXBseS4gSSBhbHJlYWR5IHJlYWNoZWQgb3V0IHRvIHRoZSBYZW4gSVJD Cj4gICAgIGNoYW5uZWxzIGJ1dCBkaWRuJ3QgZ2V0IGEgcmVzcG9uc2UgYmVzaWRlcyB0aGUg ZW1haWwgYWRkcmVzcyBJJ3ZlCj4gICAgIHVzZWQgZm9yIG15IGluaXRpYWwgZW1haWwuCj4K PiAgICAgVGhlIFdpbmRvd3MgZmlyZXdhbGwgc2V0dGluZ3MgZG9uJ3QgaGF2ZSBhbnkgaW5m bHVlbmNlIG9uIHRoZQo+ICAgICBiZWhhdmlvci4gSSB0ZXN0ZWQgdGhhdCBhbHJlYWR5LiBC dXQgYXMgZmFyIGFzIEkgY2FuIHJlY2FsbCBJIGhhZAo+ICAgICB0aGUgZHJpdmVycyBpbnN0 YWxsZWQgb24gYSBXaW5kb3dzIDEwIDE5MDkgRG9tVSBvbiBteSBvbGQgc2VydmVyCj4gICAg IHJ1bm5pbmcgYW4gdXBncmFkZWQgdWJ1bnR1IDE4LjA0IHdpdGggWGVuIDQuOSBhbmQgeGVu ZCBzdGlsbCBiZWluZwo+ICAgICBhY3RpdmUgKG9yaWdpbmFsbHkgc2VydmVyIGluc3RhbGwg ZGF0ZSB3YXMgRGVjIDIwMTIgd2l0aCB1YnVudHUKPiAgICAgMTIuMDQgYW5kIHRoZWlyIFhl biB2ZXJzaW9uKS4KPgo+ICAgICBXaXRoIHRoaXMgc2V0dXAgdGhlIHY5IGRyaXZlcnMgd2Vy ZSB3b3JraW5nIHdpdGggUkRQLiBEb2VzIHRoaXMKPiAgICAgZ2l2ZSB5b3UgYW55IGhpbnQv aWRlYT8KPgo+ICAgICBCZXN0LCBPbGl2ZXIKPgo+ICAgICBBbSAwNS4wNS4yMCB1bSAxNTo1 NiBzY2hyaWViIFBhdWwgRHVycmFudDoKPgo+ICAgICAgICAgSGkgT2xpdmVyLAo+Cj4gICAg ICAgICDCoAo+Cj4gICAgICAgICDCoCBJIGNhbiBvbmx5IHRoaW5rIHRoaXMgaXMgYSBjaGVj a3N1bW1pbmcgaXNzdWUuIEkgY2Fu4oCZdCBzZWUKPiAgICAgICAgIGhvdyBlbHNlIGEgbmV0 d29yayBkcml2ZXIgb3BlcmF0aW5nIG5vIGhpZ2hlciB0aGFuIEw0IChmb3IKPiAgICAgICAg IGNoZWNrc3VtL0xTTykgd291bGQgYmUgYWJsZSB0byBhZmZlY3QgYSB2ZXJ5IHNwZWNpZmlj IHBhcnQgb2YKPiAgICAgICAgIGEgaGlnaGVyIGxldmVsIHByb3RvY29sLiBBbHRob3VnaCwg b25lIHRoaW5nIHRvIHdhdGNoIG91dCBmb3LigKYKPiAgICAgICAgIGluIHRoZSBwYXN0IEkg aGF2ZSBzZWVuIFdpbmRvd3MgZG8gdGhpbmdzIGxpa2UgcmUtZW5hYmxpbmcKPiAgICAgICAg IGZpcmV3YWxsIHJ1bGVzIHdoZW4gdGhlcmUgaXMgYSBjaGFuZ2UgaW4gdGhlIG5ldHdvcmsg c3RhY2sgc28KPiAgICAgICAgIHlvdSBtaWdodCB3YW50IHRvIGNoZWNrIHRoYXQuCj4KPiAg ICAgICAgIMKgCj4KPiAgICAgICAgIMKgIENoZWVycywKPgo+ICAgICAgICAgwqAKPgo+ICAg ICAgICAgwqDCoMKgIFBhdWwKPgo+ICAgICAgICAgwqAKPgo+ICAgICAgICAgKkZyb206Kndp bi1wdi1kZXZlbAo+ICAgICAgICAgPHdpbi1wdi1kZXZlbC1ib3VuY2VzQGxpc3RzLnhlbnBy b2plY3Qub3JnPgo+ICAgICAgICAgPG1haWx0bzp3aW4tcHYtZGV2ZWwtYm91bmNlc0BsaXN0 cy54ZW5wcm9qZWN0Lm9yZz4gKk9uIEJlaGFsZgo+ICAgICAgICAgT2YgKk9saXZlciBMaW5k ZW4KPiAgICAgICAgICpTZW50OiogMDQgTWF5IDIwMjAgMTg6MDYKPiAgICAgICAgICpUbzoq IHdpbi1wdi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZwo+ICAgICAgICAgPG1haWx0bzp3 aW4tcHYtZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmc+Cj4gICAgICAgICAqU3ViamVjdDoq IExpa2VseSBidWcgaW4gdGhlIFBWIGRyaXZlciB2OS4wCj4KPiAgICAgICAgIMKgCj4KPiAg ICAgICAgIERlYXIgYWxsLAo+Cj4gICAgICAgICBJJ20gb2JzZXJ2aW5nIGFuIGFubm95aW5n IGJ1ZyB3aXRoIHRoZSB2OSBXaW5kb3dzIFBWIGRyaXZlcnMuCj4gICAgICAgICBJdCdzIGVh c3kgcmVwcm9kdWNpYmxlIGhlcmUgb24gbXkgc2lkZToKPgo+ICAgICAgICAgRG9tMDoKPiAg ICAgICAgIHVidW50dSAyMC4wNCBmcmVzaGx5IGluc3RhbGxlZCBhcm91bmQgRWFzdGVyIHdp dGggdGhlcmUKPiAgICAgICAgIHZlcnNpb24gb2YgWGVuICg0LjExKSBhbmQgb25seSB1c2lu ZyB0aGUgeGwgdG9vbC1zdGFjay4KPgo+ICAgICAgICAgRG9tVToKPiAgICAgICAgIFdpdGgg ZXZlcnkgZnJlc2ggaW5zdGFsbGF0aW9uIG9mIFdpbmRvd3MgMTAgdjE5MDkgR2VybWFuIHRo ZQo+ICAgICAgICAgZm9sbG93aW5nIGNhbiBiZSByZXByb2R1Y2VkOgo+Cj4gICAgICAgICAg ICogRXZlcnl0aGluZyBpcyB3b3JraW5nIGJ1dCBzbG93IGFzIGV4cGVjdGVkCj4gICAgICAg ICAgICogSW5zdGFsbGF0aW9uIG9mIHRoZSB2OSBkcml2ZXJzIHdvcmtzIHdlbGwgd2l0aG91 dCBhbnkKPiAgICAgICAgICAgICBpc3N1ZXMgYW5kIHJlc3VsdHMgaW4gc2lnbmlmaWNhbnRs eSBpbXByb3ZlZCBzcGVlZAo+Cj4gICAgICAgICBidXQKPgo+ICAgICAgICAgICAgIFJEUCBj b25uZWN0aW9ucyB0byBzdWNoIGEgbWFjaGluZSBhcmVuJ3QgcG9zc2libGUgYW55bW9yZS4K PiAgICAgICAgICAgICBUaGUgUkRQIHNlcnZpY2UgYWx3YXlzIGFza3MgZm9yIGEgdXNlci9Q VyBidXQgbmV2ZXIKPiAgICAgICAgICAgICBhY2NlcHRzIGl0LiBUbyBiZSBwcmVjaXNlLCB0 aGUgUkRQIGNvbm5lY3Rpb25zIGFyZSB3b3JraW5nCj4KPiAgICAgICAgICAgKiB3aXRoIHRo ZSBwbGFpbiB2YW5pbGxhIGluc3RhbGxhdGlvbgo+ICAgICAgICAgICAqIHdpdGggdGhlIHY5 IGRyaXZlcnMgYmVpbmcgaW5zdGFsbGVkICpleGNlcHQgdGhlIG5ldHdvcmsKPiAgICAgICAg ICAgICBjbGFzcyAmIGRyaXZlcioKPgo+ICAgICAgICAgU2luY2UgSSdtIHVzaW5nIG15IFdp bmRvd3MgbWFjaGluZXMgcHJlZG9taW5hdGVseSB3aXRoIFJEUAo+ICAgICAgICAgY2xpZW50 cyBpdCB3b3VsZCBiZSBncmVhdCBpZiB0aGlzIGNhbiBiZSBzb2x2ZWQuIFBsZWFzZSBsZXQg bWUKPiAgICAgICAgIGtub3cgaWYgeW91IG5lZWQgYW55IGtpbmQgb2YgZGV0YWlscyBmcm9t IG15IHNpZGUuCj4KPiAgICAgICAgIEJlc3QsIE9saXZlcgo+Cj4gICAgICAgICAgICAgwqAK Pgo= --------------7D06FD939DAED6A48E579565 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Paul,

the Dom0 is sitting on brand new hardware with a fresh installed ubuntu 20.04 and the NIC being used is the onboard one:

lspci -vv:
09:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)<= br> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Subsystem: ASRock Incorp= oration Motherboard (one of many)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Control: I/O+ Mem+ BusMa= ster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Status: Cap+ 66MHz- UDF-= FastB2B- ParErr- DEVSEL=3Dfast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Latency: 0, Cache Line S= ize: 64 bytes
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Interrupt: pin A routed = to IRQ 35
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Region 0: I/O ports at b= 000 [size=3D256]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Region 2: Memory at fc30= 4000 (64-bit, non-prefetchable) [size=3D4K]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Region 4: Memory at fc30= 0000 (64-bit, non-prefetchable) [size=3D16K]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Capabilities: [40] Power= Management version 3
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=3D375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Status: D0 NoSoftRst+ PME-Enable- DSel=3D0 DScale=3D= 0 PME-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Capabilities: [50] MSI: = Enable- Count=3D1/1 Maskable- 64bit+
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Address: 0000000000000000=C2=A0 Data: 0000
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Capabilities: [70] Expre= ss (v2) Endpoint, MSI 01
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ext= Tag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 26.000W
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Rlx= dOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Max= Payload 128 bytes, MaxReadReq 4096 bytes
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq- AuxPwr+ TransPend-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s unlimited, L1 <64us
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Clo= ckPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- CommClk+
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ext= Synch- ClockPM- AutWidDis- BWInt- AutBWInt-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 LnkSta: Speed 2.5GT/s (ok), Width x1 (ok)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TrE= rr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, NROPrPrP-, LTR+
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= 10BitTagComp-, 10BitTagReq-, OBFF Via message/WAKE#, ExtFmt-, EETLPPrefix-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= FRS-, TPHComp-, ExtTPHComp-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= AtomicOpsCap: 32bit- 64bit- 128bitCAS-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= AtomicOpsCtl: ReqEn-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Compliance De-emphasis: -6dB
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Capabilities: [b0] MSI-X= : Enable+ Count=3D4 Masked-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Vector table: BAR=3D4 offset=3D00000000
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 PBA: BAR=3D4 offset=3D00000800
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Capabilities: [100 v2] A= dvanced Error Reporting
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 UESta:=C2=A0 DLP- SDES- TLP- FCP- CmpltTO- CmpltAbr= t- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 UEMsk:=C2=A0 DLP- SDES- TLP- FCP- CmpltTO- CmpltAbr= t- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 CESta:=C2=A0 RxErr- BadTLP- BadDLLP- Rollover- Time= out- AdvNonFatalErr-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 CEMsk:=C2=A0 RxErr- BadTLP- BadDLLP- Rollover- Time= out- AdvNonFatalErr+
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Mul= tHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 HeaderLog: 00000000 00000000 00000000 00000000
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Capabilities: [140 v1] V= irtual Channel
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Caps:=C2=A0=C2=A0 LPEVC=3D0 RefClk=3D100ns PATEntry= Bits=3D1
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Arb:=C2=A0=C2=A0=C2=A0 Fixed- WRR32- WRR64- WRR128-=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Ctrl:=C2=A0=C2=A0 ArbSelect=3DFixed
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Status: InProgress-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 VC0:=C2=A0=C2=A0=C2=A0 Caps:=C2=A0=C2=A0 PATOffset=3D= 00 MaxTimeSlots=3D1 RejSnoopTrans-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Arb= :=C2=A0=C2=A0=C2=A0 Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ctr= l:=C2=A0=C2=A0 Enable+ ID=3D0 ArbSelect=3DFixed TC/VC=3D01
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Sta= tus: NegoPending- InProgress-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Capabilities: [160 v1] D= evice Serial Number 7a-96-1a-59-a1-a8-00-00
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Capabilities: [170 v1] L= atency Tolerance Reporting
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Max snoop latency: 0ns
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Max no snoop latency: 0ns
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Capabilities: [178 v1] L= 1 PM Substates
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 PortCommonModeRestoreTime=3D150us PortTPowerOnTime=3D150us
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 T_CommonMode=3D0us LTR1.2_Threshold=3D0ns
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 L1SubCtl2: T_PwrOn=3D10us
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Kernel driver in use: r8= 169
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Kernel modules: r8169

All settings are on default.

Best, Oliver


Am 07.05.20 um 14:03 schrieb Paul Durrant:

Oliver,=

=C2= =A0

=C2=A0 That=E2=80=99s int= eresting. It suggests a bug in the guest tx side checksum calculation. This is normally done by netback setting up metadata in skb and having either the kernel or the h/w driver do the calculation. Disabling the option in the guest means the calculation will be done in-guest by XENVIF before the segment is passed to netback. Hence, it sounds like your problem may actually be in your dom0 or NIC (possibly failing to handle some quirk of the RDP packets).<= /span>

=C2= =A0

=C2=A0 Cheers,=

=C2= =A0

=C2=A0 Paul

=C2= =A0

=C2= =A0

From: Oliver Linden <oliver_linden@helimail.de> =
Sent: 07 May 2020 12:34
To: paul@xen.org; win-pv-devel@lists.xenproject.org Subject: Re: Likely bug in the PV driver v9.0

=C2=A0

Hi Paul,

that was a perfect hint!

Disabling all features in the advanced properties pane allowed to reconnect via RDP.

I subsequently activated the features and was able to nail it down to the two "TCP Checksum Offload (IPv[46])" entries. For those two you need to set them to either "Disabled" or "RX enabled". TX and RX&TX enabled are breaking RDP connectivity.

Many thanks for your support, it's highly appreciated.<= /o:p>

Best, Oliver

Am 06.05.20 um 09:26 schrieb Paul Durrant:

Hi Oliver,

=C2=A0=

=C2=A0 Xen 4.9 and Ub= untu 18.04 are clearly both a little old. I guess it is possible that changes in netback have caused problems. I think the next step is probably to disable all offloads (checksum and LSO) in advanced properties pane for the PV network frontend and see if the problem still exists. If that doesn=E2=80=99t have any effect then next would b= e to collect wireshark traces and look for oddities around RDP login.

=C2=A0=

=C2=A0 Cheers,=

=C2=A0=

=C2=A0=C2=A0=C2=A0 Pa= ul

=C2=A0=

=C2=A0=

From: Oliver Linden <oliver_linden@helima= il.de>
Sent: 05 May 2020 18:38
To: paul@xen.org; win-pv-devel@lists.xenpr= oject.org
Subject: Re: Likely bug in the PV driver v9.0

=C2=A0

Hello Paul,

thanks a lot for your reply. I already reached out to the Xen IRC channels but didn't get a response besides the email address I've used for my initial email.

The Windows firewall settings don't have any influence on the behavior. I tested that already. But as far as I can recall I had the drivers installed on a Windows 10 1909 DomU on my old server running an upgraded ubuntu 18.04 with Xen 4.9 and xend still being active (originally server install date was Dec 2012 with ubuntu 12.04 and their Xen version).

With this setup the v9 drivers were working with RDP. Does this give you any hint/idea?

Best, Oliver

Am 05.05.20 um 15:56 schrieb Paul Durrant:

=

= Hi Oliver,

= =C2=A0

= =C2=A0 I can only= think this is a checksumming issue. I can=E2=80=99t s= ee how else a network driver operating no higher than L4 (for checksum/LSO) would be able to affect a very specific part of a higher level protocol. Although, one thing to watch out for=E2=80=A6 in the past I hav= e seen Windows do things like re-enabling firewall rules when there is a change in the network stack so you might want to check that.

= =C2=A0

= =C2=A0 Cheers,

= =C2=A0

= =C2=A0=C2=A0=C2=A0 Paul

= =C2=A0

From: win-pv-devel <win-pv-devel-bou= nces@lists.xenproject.org> On Behalf Of Oliver Linden
Sent: 04 May 2020 18:06
To: win-pv-devel@lists.x= enproject.org
Subject: Likely bug in the PV driver v9.0

=C2=A0

Dear all,

I'm observing an annoying bug with the v9 Windows PV drivers. It's easy reproducible here on my side:

Dom0:
ubuntu 20.04 freshly installed around Easter with there version of Xen (4.11) and only using the xl tool-stack.

DomU:
With every fresh installation of Windows 10 v1909 German the following can be reproduced:

  • Everything is working but slow as expected
  • Installation of the v9 drivers works well without any issues and results in significantly improved speed

but

RDP connections to such a machine aren't possible anymore. The RDP service always asks for a user/PW but never accepts it. To be precise, the RDP connections are working

  • with the plain vanilla installation<= /span>
  • with the v9 drivers being installed except the network class & driver

Since I'm using my Windows machines predominately with RDP clients it would be great if this can be solved. Please let me know if you need any kind of details from my side.

Best, Oliver

=C2=A0

--------------7D06FD939DAED6A48E579565-- --hPimY4JyONbH2fCaKEQM2nzaFnut1jzer-- --1eMyn2xGgEFom0i7i6Ir06vpG0gLNRWj4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQG14HRX/gP3AY3+bqqsNqQA1FaigUCXrP+egAKCRCqsNqQA1Fa irN5AJwJNK+E/3WT0NHiOWyqCaWuArabrQCfftUyiW+6WUBK6fyFFtSvx36g14c= =gj2P -----END PGP SIGNATURE----- --1eMyn2xGgEFom0i7i6Ir06vpG0gLNRWj4-- From win-pv-devel-bounces@lists.xenproject.org Thu May 07 13:00:19 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 07 May 2020 13:00:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jWg8O-0000si-73; Thu, 07 May 2020 13:00:16 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jWg8M-0000sW-Uf for win-pv-devel@lists.xenproject.org; Thu, 07 May 2020 13:00:15 +0000 X-Inumbo-ID: b024f524-9062-11ea-ae69-bc764e2007e4 Received: from mail-ed1-x529.google.com (unknown [2a00:1450:4864:20::529]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b024f524-9062-11ea-ae69-bc764e2007e4; Thu, 07 May 2020 13:00:12 +0000 (UTC) Received: by mail-ed1-x529.google.com with SMTP id f12so5248041edn.12 for ; Thu, 07 May 2020 06:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=e3/O248jW0mFy0lcM9TX/+VkxMaUULgPqqRdyq3V+yU=; b=vcc4ThtWqQ+Mz8XLT8ihkNh5bOGbwzkQWTERsZu7eo9X0LrGgCXRFDjOLz/GONDoDg jo4mYjirg8QIG48goqXtFJYY7xv91m/tET8UWB1TMKAUXVDkT7WTD5BGisM+je7rJz3K 4iSur8gA2LBT6CDBDiuix0uvK7PQrOCiNDPAPSmnWw6FHQ7uOZe7+YUUIz7fXLvwISxJ Z6qos7ujzB+5gNI/f483b+GmhleKZZkyksmKDLXXZh1zNSFZJEd02PDbzC8lhMGRiL3W E3w2ymZ6HfnK9bp0hZDsVk4NHsWI57e0XCkIwPGvLCqpBFbnA2MPL9gRjXjP7WaAKj0j 8wqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:references:in-reply-to:subject :date:message-id:mime-version:thread-index:content-language; bh=e3/O248jW0mFy0lcM9TX/+VkxMaUULgPqqRdyq3V+yU=; b=OwMaw3lFtyPev0RzgK6vccp3ES6NoPJkqOTLP5/OGKjzwcF6/kheNqpXhHU0x2lqbA MnIpO5XdhyjczJmVcPFYW+zWud9GzrxJfzA1cAyi59zGHQR5YRshGGi8qgG8o4yOWKJd Ju0t7sxgobbWYYWHNNj5833ciZYYe53vesd+IB+nEkPtkGPuXmGCm87P/4LlwaO/TRaK RIAekzRljh+0c0MHLJ9uZvRR4FmdXYiuKlXdUEgWJVb+16mm06YLKLKjbrfiSZHZLTi3 kQxwuLmPgtRfnio6d/FgzqmtoH5rvOFtjnwqgIPjDDDrcd8bPWMhBgjHBh3kBJPtsodT VkaQ== X-Gm-Message-State: AGi0PuYQcRrHX2TgDa3Yow7BcMkPXut11twfxkoh7kYKPDhTs6egESNu 0xDEC45nZ3eia36m16ML/i0maHmwTJ4= X-Google-Smtp-Source: APiQypLRonXAAi3fgjn/+AhWgYkdtU5Q61qTMyeNFxOzU9h7W1EK/AGuze59VpxnGipgJjB65UxC0w== X-Received: by 2002:aa7:cdcb:: with SMTP id h11mr11196180edw.264.1588856411940; Thu, 07 May 2020 06:00:11 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.185]) by smtp.gmail.com with ESMTPSA id q17sm608941ejm.91.2020.05.07.06.00.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 May 2020 06:00:11 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Oliver Linden'" , References: <003701d622e4$fe8e12e0$fbaa38a0$@xen.org> <559b80d6-e1bf-e822-deaa-e5f06b1c2f9f@helimail.de> <007d01d62377$b5fb3d30$21f1b790$@xen.org> <49d5c710-2653-9fc3-22de-96b26250592a@helimail.de> <002e01d62467$909e1940$b1da4bc0$@xen.org> <46f028b2-e14c-4889-6ee6-04aa6621778e@helimail.de> In-Reply-To: <46f028b2-e14c-4889-6ee6-04aa6621778e@helimail.de> Subject: RE: Likely bug in the PV driver v9.0 Date: Thu, 7 May 2020 14:00:09 +0100 Message-ID: <008001d6246f$70f91470$52eb3d50$@xen.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0081_01D62477.D2C14D00" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQG9IJ9vpX/oWXBdLX78RYa0vQCcNQK7bUz4AXOH5kgBCCOG1QJRl87kAjbS5y4B9WnOdqhw9Zjw Content-Language: en-gb X-BeenThere: win-pv-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Developer list for the Windows PV Drivers subproject List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Errors-To: win-pv-devel-bounces@lists.xenproject.org Sender: "win-pv-devel" This is a multipart message in MIME format. ------=_NextPart_000_0081_01D62477.D2C14D00 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Oliver, =20 This thread may be marginally interesting: = https://lore.kernel.org/netdev/217e3fa9-7782-08c7-1f2b-8dabacaa83f9@gmail= .com/T/ =20 It suggests that the Realtek driver might have some issues. =20 Cheers, =20 Paul =20 =20 From: Oliver Linden =20 Sent: 07 May 2020 13:27 To: paul@xen.org; win-pv-devel@lists.xenproject.org Subject: Re: Likely bug in the PV driver v9.0 =20 Hi Paul, the Dom0 is sitting on brand new hardware with a fresh installed ubuntu = 20.04 and the NIC being used is the onboard one: lspci -vv: 09:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. = RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15) Subsystem: ASRock Incorporation Motherboard (one of many) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- = ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast >TAbort- = SERR- = =20 Sent: 07 May 2020 12:34 To: paul@xen.org ; = win-pv-devel@lists.xenproject.org = =20 Subject: Re: Likely bug in the PV driver v9.0 =20 Hi Paul, that was a perfect hint! Disabling all features in the advanced properties pane allowed to = reconnect via RDP. I subsequently activated the features and was able to nail it down to = the two "TCP Checksum Offload (IPv[46])" entries. For those two you need = to set them to either "Disabled" or "RX enabled". TX and RX&TX enabled = are breaking RDP connectivity. Many thanks for your support, it's highly appreciated. Best, Oliver Am 06.05.20 um 09:26 schrieb Paul Durrant: Hi Oliver, =20 Xen 4.9 and Ubuntu 18.04 are clearly both a little old. I guess it is = possible that changes in netback have caused problems. I think the next = step is probably to disable all offloads (checksum and LSO) in advanced = properties pane for the PV network frontend and see if the problem still = exists. If that doesn=E2=80=99t have any effect then next would be to = collect wireshark traces and look for oddities around RDP login. =20 Cheers, =20 Paul =20 =20 From: Oliver Linden = =20 Sent: 05 May 2020 18:38 To: paul@xen.org ; = win-pv-devel@lists.xenproject.org = =20 Subject: Re: Likely bug in the PV driver v9.0 =20 Hello Paul, thanks a lot for your reply. I already reached out to the Xen IRC = channels but didn't get a response besides the email address I've used = for my initial email. The Windows firewall settings don't have any influence on the behavior. = I tested that already. But as far as I can recall I had the drivers = installed on a Windows 10 1909 DomU on my old server running an upgraded = ubuntu 18.04 with Xen 4.9 and xend still being active (originally server = install date was Dec 2012 with ubuntu 12.04 and their Xen version). With this setup the v9 drivers were working with RDP. Does this give you = any hint/idea? Best, Oliver Am 05.05.20 um 15:56 schrieb Paul Durrant: Hi Oliver, =20 I can only think this is a checksumming issue. I can=E2=80=99t see how = else a network driver operating no higher than L4 (for checksum/LSO) = would be able to affect a very specific part of a higher level protocol. = Although, one thing to watch out for=E2=80=A6 in the past I have seen = Windows do things like re-enabling firewall rules when there is a change = in the network stack so you might want to check that. =20 Cheers, =20 Paul =20 From: win-pv-devel = On Behalf Of Oliver Linden Sent: 04 May 2020 18:06 To: win-pv-devel@lists.xenproject.org = =20 Subject: Likely bug in the PV driver v9.0 =20 Dear all, I'm observing an annoying bug with the v9 Windows PV drivers. It's easy = reproducible here on my side: Dom0: ubuntu 20.04 freshly installed around Easter with there version of Xen = (4.11) and only using the xl tool-stack. DomU: With every fresh installation of Windows 10 v1909 German the following = can be reproduced: * Everything is working but slow as expected * Installation of the v9 drivers works well without any issues and = results in significantly improved speed but RDP connections to such a machine aren't possible anymore. The RDP = service always asks for a user/PW but never accepts it. To be precise, = the RDP connections are working * with the plain vanilla installation * with the v9 drivers being installed except the network class & driver Since I'm using my Windows machines predominately with RDP clients it = would be great if this can be solved. Please let me know if you need any = kind of details from my side. Best, Oliver =20 ------=_NextPart_000_0081_01D62477.D2C14D00 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi = Oliver,

 =

=C2=A0 This thread may be marginally = interesting: = https://lore.kernel.org/netdev/217e3fa9-7782-08c7-1f2b-8dabacaa83f9@gmail= .com/T/

 =

=C2=A0 It suggests that the Realtek driver might have some = issues.

 =

=C2=A0 Cheers,

 =

=C2=A0=C2=A0=C2=A0 = Paul

 =

 =

From: Oliver Linden = <oliver_linden@helimail.de>
Sent: 07 May 2020 = 13:27
To: paul@xen.org; = win-pv-devel@lists.xenproject.org
Subject: Re: Likely bug in = the PV driver v9.0

 

Hi Paul,

the = Dom0 is sitting on brand new hardware with a fresh installed ubuntu = 20.04 and the NIC being used is the onboard one:

lspci = -vv:
09:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. = RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev = 15)
        Subsystem: ASRock = Incorporation Motherboard (one of = many)
        Control: I/O+ Mem+ = BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- = FastB2B- DisINTx+
        Status: = Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast >TAbort- <TAbort- = <MAbort- >SERR- <PERR- = INTx-
        Latency: 0, Cache = Line Size: 64 bytes
        = Interrupt: pin A routed to IRQ = 35
        Region 0: I/O ports at = b000 [size=3D256]
        Region = 2: Memory at fc304000 (64-bit, non-prefetchable) = [size=3D4K]
        Region 4: = Memory at fc300000 (64-bit, non-prefetchable) = [size=3D16K]
        Capabilities: = [40] Power Management version = 3
           &n= bsp;    Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=3D375mA = PME(D0+,D1+,D2+,D3hot+,D3cold+)
      &n= bsp;         Status: D0 = NoSoftRst+ PME-Enable- DSel=3D0 DScale=3D0 = PME-
        Capabilities: [50] = MSI: Enable- Count=3D1/1 Maskable- = 64bit+
          &nb= sp;     Address: 0000000000000000  Data: = 0000
        Capabilities: [70] = Express (v2) Endpoint, MSI = 01
           &= nbsp;    DevCap: MaxPayload 128 bytes, PhantFunc 0, = Latency L0s <512ns, L1 = <64us
          &= nbsp;           &n= bsp; ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit = 26.000W
          &n= bsp;     DevCtl: CorrErr- NonFatalErr- FatalErr- = UnsupReq-
          =             &= nbsp; RlxdOrd+ ExtTag- PhantFunc- AuxPwr- = NoSnoop-
          &= nbsp;           &n= bsp; MaxPayload 128 bytes, MaxReadReq 4096 = bytes
          &nbs= p;     DevSta: CorrErr+ NonFatalErr- FatalErr- = UnsupReq- AuxPwr+ = TransPend-
          = ;      LnkCap: Port #0, Speed 2.5GT/s, Width = x1, ASPM L0s L1, Exit Latency L0s unlimited, L1 = <64us
          &= nbsp;           &n= bsp; ClockPM+ Surprise- LLActRep- BwNot- = ASPMOptComp+
         &nb= sp;      LnkCtl: ASPM L1 Enabled; RCB 64 bytes = Disabled- = CommClk+
          &= nbsp;           &n= bsp; ExtSynch- ClockPM- AutWidDis- BWInt- = AutBWInt-
          =       LnkSta: Speed 2.5GT/s (ok), Width x1 = (ok)
           = ;            = TrErr- Train- SlotClk+ DLActive- BWMgmt- = ABWMgmt-
          &= nbsp;     DevCap2: Completion Timeout: Range ABCD, = TimeoutDis+, NROPrPrP-, = LTR+
           = ;            =   10BitTagComp-, 10BitTagReq-, OBFF Via message/WAKE#, ExtFmt-, = EETLPPrefix-
         &nb= sp;           &nbs= p;   EmergencyPowerReduction Not Supported, = EmergencyPowerReductionInit-
       = ;            =       FRS-, TPHComp-, = ExtTPHComp-
         &nbs= p;            = ;   AtomicOpsCap: 32bit- 64bit- = 128bitCAS-
          = ;      DevCtl2: Completion Timeout: 50us to = 50ms, TimeoutDis-, LTR-, OBFF = Disabled
          &= nbsp;           &n= bsp;  AtomicOpsCtl: = ReqEn-
          &nb= sp;     LnkCtl2: Target Link Speed: 2.5GT/s, = EnterCompliance- = SpeedDis-
          =             &= nbsp;  Transmit Margin: Normal Operating Range, = EnterModifiedCompliance- = ComplianceSOS-
         &= nbsp;           &n= bsp;   Compliance De-emphasis: = -6dB
           = ;     LnkSta2: Current De-emphasis Level: -6dB, = EqualizationComplete-, = EqualizationPhase1-
        &n= bsp;           &nb= sp;    EqualizationPhase2-, EqualizationPhase3-, = LinkEqualizationRequest-
        = Capabilities: [b0] MSI-X: Enable+ Count=3D4 = Masked-
          &n= bsp;     Vector table: BAR=3D4 = offset=3D00000000
        &nbs= p;       PBA: BAR=3D4 = offset=3D00000800
        = Capabilities: [100 v2] Advanced Error = Reporting
          =       UESta:  DLP- SDES- TLP- FCP- = CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- = ACSViol-
          &= nbsp;     UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- = CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- = ACSViol-
          &= nbsp;     UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- = CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- = ACSViol-
          &= nbsp;     CESta:  RxErr- BadTLP- BadDLLP- = Rollover- Timeout- = AdvNonFatalErr-
         =        CEMsk:  RxErr- BadTLP- = BadDLLP- Rollover- Timeout- = AdvNonFatalErr+
         =        AERCap: First Error Pointer: 00, = ECRCGenCap+ ECRCGenEn- ECRCChkCap+ = ECRCChkEn-
          = ;            =   MultHdrRecCap- MultHdrRecEn- TLPPfxPres- = HdrLogCap-
          = ;      HeaderLog: 00000000 00000000 00000000 = 00000000
        Capabilities: = [140 v1] Virtual = Channel
          &n= bsp;     Caps:   LPEVC=3D0 RefClk=3D100ns = PATEntryBits=3D1
         = ;       Arb:    Fixed- = WRR32- WRR64- = WRR128-
          &n= bsp;     Ctrl:   = ArbSelect=3DFixed
        &nbs= p;       Status: = InProgress-
         &nbs= p;      VC0:    = Caps:   PATOffset=3D00 MaxTimeSlots=3D1 = RejSnoopTrans-
         &= nbsp;           &n= bsp;  Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- = WRR256-
          &n= bsp;           &nb= sp; Ctrl:   Enable+ ID=3D0 ArbSelect=3DFixed = TC/VC=3D01
          = ;            =   Status: NegoPending- = InProgress-
        Capabilities: = [160 v1] Device Serial Number = 7a-96-1a-59-a1-a8-00-00
        = Capabilities: [170 v1] Latency Tolerance = Reporting
          =       Max snoop latency: = 0ns
           =      Max no snoop latency: = 0ns
        Capabilities: [178 v1] = L1 PM = Substates
          =       L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ = ASPM_L1.2+ ASPM_L1.1+ = L1_PM_Substates+
         = ;            =      PortCommonModeRestoreTime=3D150us = PortTPowerOnTime=3D150us
       &nb= sp;        L1SubCtl1: PCI-PM_L1.2- = PCI-PM_L1.1- ASPM_L1.2- = ASPM_L1.1-
          = ;            =      T_CommonMode=3D0us = LTR1.2_Threshold=3D0ns
        = ;        L1SubCtl2: = T_PwrOn=3D10us
        Kernel = driver in use: r8169
        = Kernel modules: r8169

All settings are on = default.

Best, = Oliver

 

Am 07.05.20 um 14:03 schrieb Paul = Durrant:

Oliver,<= /o:p>

 

=C2=A0 That=E2=80=99s interesting. It = suggests a bug in the guest tx side checksum calculation. This is = normally done by netback setting up metadata in skb and having either = the kernel or the h/w driver do the calculation. Disabling the option in = the guest means the calculation will be done in-guest by XENVIF before = the segment is passed to netback. Hence, it sounds like your problem may = actually be in your dom0 or NIC (possibly failing to handle some quirk = of the RDP packets).

 

=C2=A0 Cheers,

 

=C2=A0 Paul

 

 

From: Oliver Linden <oliver_linden@helimail.de&g= t;
Sent: 07 May 2020 12:34
To: paul@xen.org; win-pv-devel@lists.xenp= roject.org
Subject: Re: Likely bug in the PV driver = v9.0

 

Hi Paul,

that = was a perfect hint!

Disabling all features in the = advanced properties pane allowed to reconnect via = RDP.

I subsequently activated the features and was able = to nail it down to the two "TCP Checksum Offload (IPv[46])" = entries. For those two you need to set them to either = "Disabled" or "RX enabled". TX and RX&TX enabled = are breaking RDP connectivity.

Many thanks for your = support, it's highly appreciated.

Best, = Oliver

Am 06.05.20 um 09:26 = schrieb Paul Durrant:

Hi = Oliver,

 

=C2=A0 Xen 4.9 and Ubuntu 18.04 are = clearly both a little old. I guess it is possible that changes in = netback have caused problems. I think the next step is probably to = disable all offloads (checksum and LSO) in advanced properties pane for = the PV network frontend and see if the problem still exists. If that = doesn=E2=80=99t have any effect then next would be to collect wireshark = traces and look for oddities around RDP login.

 

=C2=A0 Cheers,

 

=C2=A0=C2=A0=C2=A0 = Paul

 

 

From: Oliver Linden <oliver_linden@helimail.de&g= t;
Sent: 05 May 2020 18:38
To: paul@xen.org; win-pv-devel@lists.xenp= roject.org
Subject: Re: Likely bug in the PV driver = v9.0

 

Hello = Paul,

thanks a lot for your reply. I already reached = out to the Xen IRC channels but didn't get a response besides the email = address I've used for my initial email.

The Windows = firewall settings don't have any influence on the behavior. I tested = that already. But as far as I can recall I had the drivers installed on = a Windows 10 1909 DomU on my old server running an upgraded ubuntu 18.04 = with Xen 4.9 and xend still being active (originally server install date = was Dec 2012 with ubuntu 12.04 and their Xen = version).

With this setup the v9 drivers were working = with RDP. Does this give you any hint/idea?

Best, = Oliver

Am 05.05.20 um 15:56 = schrieb Paul Durrant:

Hi = Oliver,

 

=C2=A0 I can only think this is a = checksumming issue. I can=E2=80=99t see how else a network driver = operating no higher than L4 (for checksum/LSO) would be able to affect a = very specific part of a higher level protocol. Although, one thing to = watch out for=E2=80=A6 in the past I have seen Windows do things like = re-enabling firewall rules when there is a change in the network stack = so you might want to check that.

 

=C2=A0 Cheers,

 

=C2=A0=C2=A0=C2=A0 = Paul

 

From: win-pv-devel <win-pv-deve= l-bounces@lists.xenproject.org> On Behalf Of Oliver = Linden
Sent: 04 May 2020 18:06
To: win-pv-devel@lists.xenp= roject.org
Subject: Likely bug in the PV driver = v9.0

 

Dear all,

I'm = observing an annoying bug with the v9 Windows PV drivers. It's easy = reproducible here on my side:

Dom0:
ubuntu 20.04 = freshly installed around Easter with there version of Xen (4.11) and = only using the xl tool-stack.

DomU:
With every fresh = installation of Windows 10 v1909 German the following can be = reproduced:

  • Everything is = working but slow as expected
  • Installation of the = v9 drivers works well without any issues and results in significantly = improved = speed

but

RDP connections to = such a machine aren't possible anymore. The RDP service always asks for = a user/PW but never accepts it. To be precise, the RDP connections are = working

  • with the plain = vanilla installation
  • with the v9 drivers = being installed except the network class & = driver

Since I'm using my Windows = machines predominately with RDP clients it would be great if this can be = solved. Please let me know if you need any kind of details from my = side.

Best, Oliver

 

------=_NextPart_000_0081_01D62477.D2C14D00-- From win-pv-devel-bounces@lists.xenproject.org Thu May 21 23:57:56 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 21 May 2020 23:57:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jbv4T-0001VS-KF; Thu, 21 May 2020 23:57:53 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jbv4S-0001VN-LN for win-pv-devel@lists.xenproject.org; Thu, 21 May 2020 23:57:52 +0000 X-Inumbo-ID: e150dc8c-9bbe-11ea-ae69-bc764e2007e4 Received: from mail-pg1-x529.google.com (unknown [2607:f8b0:4864:20::529]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e150dc8c-9bbe-11ea-ae69-bc764e2007e4; Thu, 21 May 2020 23:57:51 +0000 (UTC) Received: by mail-pg1-x529.google.com with SMTP id u35so4121667pgk.6 for ; Thu, 21 May 2020 16:57:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:reply-to:to:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=JO7GJTmS0jWzwVSahy7N+aasMfZQC65Bf0UdykxpH60=; b=VlVKR7on7wUXW37bNSDYdHyjXv9hKu04ayejiKwTSFaHxtG66cSvt4m4HlKZBbilq4 FrbcQ/JXzQ0npyHfMRro9fhGpp9jbtvNXk+nMX5dwLJFO8qKzADE1qel7A7X4iboL/Oc GeAKd2g8OaYxhxVuCohI4ETOCnx+7Tx/LeRXN+/2K2uQF4BYB5zoNoS7owAX1KGV/Kca zRhPom4w98zrs2Mi5VPvExCy0elLh2K3kKu00Sn/fzRZBtFqjhkAAqRSZRgpfEm9mdbt abY7/VWt3jrJ5Z5bT9woaL3Cz8DgH7R0Bh7uiCxa4bEclb5CaEdEHuhfYFfrjNgc6yE+ TrtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:reply-to:to:message-id:date :user-agent:mime-version:content-transfer-encoding:content-language; bh=JO7GJTmS0jWzwVSahy7N+aasMfZQC65Bf0UdykxpH60=; b=efJ44nkcOX6ipAftqex7NnW5mPYGkJ+5SDksRGfRBMf+mYZhnZ0JzHEYBoIkAb7Jpg +rEdf6tbKsoCg1YCUKPSFSGMG0hfwk8w/7APbPCqqug77cDnIVKPcHsQIs+4Xgc2o/GV QXvDoYFvUAp/Klod8kR35mbCDLPdcNPevV8InzE6KJD1hnICUOFFJEZ1Qf+EATKQ9a3X 4eOhrm/k9zXoh+XyAQ9/uk6VcKceqPRNboBCCOPARwGuzM2rtOVaHjOF0AfB8SqoDKN+ RRNC8KA5y/66UGH3+Fr7IpG8OykdoOM21T9eYxYOyHAT7xy1ok/qZW9gUaTa8pYDjYSS Rx3Q== X-Gm-Message-State: AOAM533f3JmTQexkJ5zixTm5UhbcvRPNuC07G+67zTJuXTniOwHJ6+/6 WR6NmFfI5Ms9Hk1evoDRpvqY0C58 X-Google-Smtp-Source: ABdhPJyUepyknoo9TbCg2ulED0IH5BMb3bg+BoXCqCS2GH1shK8/FCw5RB0brP7dJ9+dfZKB4ZBh1Q== X-Received: by 2002:a62:794e:: with SMTP id u75mr1197531pfc.5.1590105470565; Thu, 21 May 2020 16:57:50 -0700 (PDT) Received: from [10.10.15.22] ([103.227.170.10]) by smtp.gmail.com with ESMTPSA id f26sm5148671pfn.183.2020.05.21.16.57.48 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 May 2020 16:57:49 -0700 (PDT) From: Jan Bakuwel Subject: Windows 2019 server crashing with 8.2 To: win-pv-devel@lists.xenproject.org Message-ID: Date: Fri, 22 May 2020 11:57:44 +1200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: win-pv-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Developer list for the Windows PV Drivers subproject List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: jan.bakuwel@gmail.com Errors-To: win-pv-devel-bounces@lists.xenproject.org Sender: "win-pv-devel" Hi all, Not sure if this list is the right place for my question, but here goes :-) We've used the 8.2 drivers with a Windows 2008R2 server for years without any issues. When Windows 2008R2 was retired, we migrated to a Windows 2019 server using the same drivers (details below). The server is mostly fine but occasionally reboots itself due to a bugcheck: The computer has rebooted from a bugcheck.  The bugcheck was: 0x00000139 (0x000000000000001e, 0xffffd40aaa444fb0, 0xffffd40aaa444f08, 0x0000000000000000). A dump was saved in: C:\Windows\MEMORY.DMP. We don't know if this is caused by a bug in the Xen drivers but as far as we know the Xen drivers are the most likely candidate. Which version of the Xen drivers should we use on this system? Is remove8.2-reboot-install-reboot the correct procedure? Ending up with a system that won't boot anymore would be quite a nightmare. Any help, pointers are much appreciated. regards, Jan Interface (8.2.0.4) PV Bus (8.2.0.4) PV Network Class (8.2.0.6) PV Network Device (8.2.0.6) PV Storage Host Adapter (8.2.0.9) From win-pv-devel-bounces@lists.xenproject.org Thu May 21 23:58:13 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Thu, 21 May 2020 23:58:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jbv4n-0001WR-MG; Thu, 21 May 2020 23:58:13 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jbv4m-0001WK-Uk for win-pv-devel@lists.xenproject.org; Thu, 21 May 2020 23:58:12 +0000 X-Inumbo-ID: edaec778-9bbe-11ea-b07b-bc764e2007e4 Received: from mail-pl1-x62d.google.com (unknown [2607:f8b0:4864:20::62d]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id edaec778-9bbe-11ea-b07b-bc764e2007e4; Thu, 21 May 2020 23:58:12 +0000 (UTC) Received: by mail-pl1-x62d.google.com with SMTP id u22so3660345plq.12 for ; Thu, 21 May 2020 16:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:reply-to:to:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=qZ53df/9KbDEwHT4vTxxin5u5uHIGNjljxFFaaVIDP4=; b=XoG1c2H/BxAnxDy7ZAyiEK/95GPlQH/2wboqrYIAw0yoXw3HjzoXtQCt2H9dnjU/yu uprQGPvog+6nK+xnSCleEj9FA+zEql8/fvnbCJNinvR0PYJH9BHfNWcbISKpRjpvQYyw YsjzHMXX6+qws/0zsWt1ox6I9ks7gJnmevq8Gyo9vgdm6BWil5h1vzGyE/F/KP16wR2J UYgXsCYY5YXGFBzHZ9T47FaTAnuO8iFnjJ5ZT4oUjd6A7hv7SaZXu3GlWYD1OZ8SWCq8 oWKHtLRMfIlZnfXxbb1ECQFO14OZUW9MaDnsfd4s7brECvcy6tkxEH3Q6uEGrnGR8s9C rLsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:reply-to:to:message-id:date :user-agent:mime-version:content-transfer-encoding:content-language; bh=qZ53df/9KbDEwHT4vTxxin5u5uHIGNjljxFFaaVIDP4=; b=S8zp5X2izhCEmHYEjuAtKi+DC+9rYGo/hYUYbkjjnHZ0155YVlMW9NzhtY6Zksj3cY 10seoPxektvVIUDRiA/jktMBYGHmx/q/ECB37Lo5KiVyzHFbv9REUaA8Jn/5R7fnGWbM vxnbX2ysUk/V7g/ewBY/afOlCOk2j60QFwCHtL+fCWUNlQ11a0u9/Oi7TQqJRWscy2WO Z57N85wafU/HhQFVG5MArIQ01orkQBrRAyY5rM3IoW+ADAroYqvBaH0lVbvFhg5i7ghT QR3wclMdT8bGADLi5GSlMh/iEdIoryGy8dkP1j8nEsgL9c32He5dTLeI3tyc2lyGkaNF YDZw== X-Gm-Message-State: AOAM532vUIXJz6vX8RnOHNMb5xXM0zdMB1bxmIKN6AfCk1K03VPN0sq/ YFN0NK9M0qnXNpvHJJOZhIt3uOv8 X-Google-Smtp-Source: ABdhPJz888nZuFE9AA1DeaTyoX1nCCw44xRMqG9elKMlP1/Z8CtLwEUSLUSyr9SQs3hrGUksWLQ/FA== X-Received: by 2002:a17:90a:ad49:: with SMTP id w9mr1208415pjv.20.1590105491365; Thu, 21 May 2020 16:58:11 -0700 (PDT) Received: from [10.10.15.22] ([103.227.170.10]) by smtp.gmail.com with ESMTPSA id w12sm3784768pjb.11.2020.05.21.16.58.09 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 May 2020 16:58:10 -0700 (PDT) From: Jan Bakuwel Subject: Installing WinPV drivers on Windows 2019 To: win-pv-devel@lists.xenproject.org Message-ID: Date: Fri, 22 May 2020 11:58:05 +1200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: win-pv-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Developer list for the Windows PV Drivers subproject List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: jan.bakuwel@gmail.com Errors-To: win-pv-devel-bounces@lists.xenproject.org Sender: "win-pv-devel" Hi all, Additionally to the email I sent yesterday.... I've removed the old v8.2.0 drivers from the Windows 2019 server and installed the v8.2.2 drivers. Windows doesn't seem to be happy with those though; after rebooting Windows wanted to "repair" the system and now crashes with an "inaccessible boot device". Any suggestions how to proceed from here? I had to enable test signing to install the drivers but ultimately my small business client should not see a desktop that says "Test mode". Is there a way to run production systems with the WinPV drivers or is it still considered experimental/test only? kind regards, Jan From win-pv-devel-bounces@lists.xenproject.org Fri May 22 00:22:16 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 22 May 2020 00:22:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jbvS2-0004gN-PI; Fri, 22 May 2020 00:22:14 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jbvS1-0004gI-LR for win-pv-devel@lists.xenproject.org; Fri, 22 May 2020 00:22:13 +0000 X-Inumbo-ID: 4838229a-9bc2-11ea-ae69-bc764e2007e4 Received: from mail-ed1-x532.google.com (unknown [2a00:1450:4864:20::532]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4838229a-9bc2-11ea-ae69-bc764e2007e4; Fri, 22 May 2020 00:22:13 +0000 (UTC) Received: by mail-ed1-x532.google.com with SMTP id e10so8029807edq.0 for ; Thu, 21 May 2020 17:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2dKbjglWP1CwOttgezOAQC850qaPah1Id8+9Uz8Canw=; b=qWxcMkYGdWUiEWzFu5xP1QaLgnqG7BFeAlzKQvVcy7VSkDvlUU6UZUw7+/2lXfo3PF xng1IgBoUSB/gNTQjrL3hn5xCH9TJOOEhpcj1O7AWUMKlHznEwhpq9zRkHoj9qT1doDy 22l9d4QWf9RDbYSlhqONIHHadi1rqOdvtb51uaZDJ4Vn8ZyVxCLe8nG1bUHHu/Qn3zbG n44KNuS4eBHMsfSoV1lZ3eZQdZG78iAaEWLOyqike71irCn+1VLiQhPbrF507pbiq7Du 5/i/DhVK9dmUmH/mZtGMpT6ODxzfOwVaKFEdWqDuZM/KKa749Gm8+jXJTD5eRxA5YI2s 2flQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2dKbjglWP1CwOttgezOAQC850qaPah1Id8+9Uz8Canw=; b=E4q/9XZzYsq4TgtbWm4t9jxaCukBwPX69l+eN3QyhqjTdMDAZA54T3An5bd7vlggHn aw+aFxjPgKClRn+Mjt2zgUUcWZo0lHEDfw8zxp04ucDZCkVexUeZsQZ5ZVNyyxymyV7R UuCzTa69MnkwiDoEzk7TmtWt1pXwCHxt1ZRtA4SBMflRe/ljdgm/AdR7ukHB53YaRcVJ mP1AHR3JVNZ12bzetfQa2doJ047bvXdbsP81MHH2o/AbOvEIjyA4spk2XXbtQ4YEUedx FGRi5YPyaovpux9pA8FMe42gdt4mtI7qyJQpsK07HYg+dOz/2gIKdxUy5o8n3jMr1vVC JgaQ== X-Gm-Message-State: AOAM5323PE/+Zcm7R79ifT8VEuo1Hm0ed5DVaE3jrzC+S4XvS1shLYOa EukqEfySUTtLAOMON3T/j9B8lnu0IonTaqlWZnc= X-Google-Smtp-Source: ABdhPJyj3bGmYlkQj8ro8jI32DeoOJU0nzlQG9rtVegWNe/y38aWy+kjsew3zHsrhFdgZwiL+unof4/rs6sDv8f57v8= X-Received: by 2002:a50:ec8d:: with SMTP id e13mr1178377edr.8.1590106932134; Thu, 21 May 2020 17:22:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dustin Marquess Date: Thu, 21 May 2020 19:22:00 -0500 Message-ID: Subject: Re: Installing WinPV drivers on Windows 2019 To: jan.bakuwel@gmail.com Content-Type: text/plain; charset="UTF-8" X-BeenThere: win-pv-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Developer list for the Windows PV Drivers subproject List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: win-pv-devel@lists.xenproject.org Errors-To: win-pv-devel-bounces@lists.xenproject.org Sender: "win-pv-devel" I have the 9.0.0 drivers working fine on 2019. Only gotcha I had was that I had to install the HID drivers last. -Dustin On Thu, May 21, 2020 at 6:58 PM Jan Bakuwel wrote: > > Hi all, > > Additionally to the email I sent yesterday.... > > I've removed the old v8.2.0 drivers from the Windows 2019 server and > installed the v8.2.2 drivers. Windows doesn't seem to be happy with > those though; after rebooting Windows wanted to "repair" the system and > now crashes with an "inaccessible boot device". Any suggestions how to > proceed from here? > > I had to enable test signing to install the drivers but ultimately my > small business client should not see a desktop that says "Test mode". Is > there a way to run production systems with the WinPV drivers or is it > still considered experimental/test only? > > kind regards, > Jan > > > > From win-pv-devel-bounces@lists.xenproject.org Fri May 22 08:58:35 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 22 May 2020 08:58:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jc3Vg-0001dc-Fi; Fri, 22 May 2020 08:58:32 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jc3Vf-0001dX-4u for win-pv-devel@lists.xenproject.org; Fri, 22 May 2020 08:58:31 +0000 X-Inumbo-ID: 68454bec-9c0a-11ea-b9cf-bc764e2007e4 Received: from mail-wm1-x32e.google.com (unknown [2a00:1450:4864:20::32e]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 68454bec-9c0a-11ea-b9cf-bc764e2007e4; Fri, 22 May 2020 08:58:30 +0000 (UTC) Received: by mail-wm1-x32e.google.com with SMTP id f5so830549wmh.2 for ; Fri, 22 May 2020 01:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=ty4ZRJ+T/Aj/+4pB8bjc7q1YQQcf14R3viqB6+uZDDI=; b=J0+wQYGyYqsNU6u3miE84PLo1d0/MeTd8RAIMABA1lYru5cFRdnYm9Eek/Es1+7vTE hpomDmmDMCa3f3H0NUWpR+9esCIc2pdFwFZKvW09VWTwxxmYxxs3VYL3ciR6Rt+DTQLD ERrc4CsjOnzoIgwRXfIQ0zGfyCw8CjEAqslUWerY/A5rZk60aKRaB6kQgReakxK8SJB9 wOP/wukk1ES56WOK+bkogEJCLOl2a6i2EWt/+U4mWfx8V5upx+CEBQxqUtfq61FLRP7H lL3j2oMDRQ3stmNFVcDP2ycRAP/Dctn7kwzPrfHKDjORmEo5rHzfLIUNByciA3eE5/m/ ay7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=ty4ZRJ+T/Aj/+4pB8bjc7q1YQQcf14R3viqB6+uZDDI=; b=eRzYoBHr+HC1hOBmSGvQv/ILUUWYn2qpXmwdqlcvxPQdMctFoGn/gfI7vKXS32bedz UsScBrpHz/zHLYDWsqSn2OKq0LtKh1MQnmt72dKU9ps+LEJdguAcXHJ6PJ68P4Yee2KO S9rqnlDNFnA3+fGy1cqWKswMbnKaksfDUvAIlULpcFfthGS32W9oozQPGQzpPhsJOsU/ 8rJ7lvQlWGmxFQ59a4C4ST3G2ibTPeiZ5jOcKE/xZVD3+pDn0pKf8/BZuspzQl7nR0Fi fobvY14qcecBHBRRJxAz1Jq6mt09pFYOCUt5BMWKbQbf8oq37klYL+MTM5eH3G7GL0Xy xcEQ== X-Gm-Message-State: AOAM533ALODz+3Pbok+bSkwUAacltHHgY5WHGOhAtsxxi21MaNtUv0QL n2p679YFRNhT/FesVCsfWYc= X-Google-Smtp-Source: ABdhPJx1oPAkXWDOMh6YQUiCyrSFpUaKIAre/3Q8O0TKlD+g+q4Sj/j99JoxLmGfDQYSxE7n2qGVRA== X-Received: by 2002:a7b:c193:: with SMTP id y19mr12287703wmi.158.1590137909693; Fri, 22 May 2020 01:58:29 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.185]) by smtp.gmail.com with ESMTPSA id u10sm8916812wmc.31.2020.05.22.01.58.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 May 2020 01:58:29 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: , References: In-Reply-To: Subject: RE: Installing WinPV drivers on Windows 2019 Date: Fri, 22 May 2020 09:58:27 +0100 Message-ID: <000301d63017$29592f20$7c0b8d60$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQKmfdhS0zU5AzZ9bnw/nfbxk8vVcqcTLGaQ X-BeenThere: win-pv-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Developer list for the Windows PV Drivers subproject List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Errors-To: win-pv-devel-bounces@lists.xenproject.org Sender: "win-pv-devel" > -----Original Message----- > From: win-pv-devel On Behalf Of Jan Bakuwel > Sent: 22 May 2020 00:58 > To: win-pv-devel@lists.xenproject.org > Subject: Installing WinPV drivers on Windows 2019 > > Hi all, > > Additionally to the email I sent yesterday.... > > I've removed the old v8.2.0 drivers from the Windows 2019 server and > installed the v8.2.2 drivers. Windows doesn't seem to be happy with > those though; after rebooting Windows wanted to "repair" the system and > now crashes with an "inaccessible boot device". Any suggestions how to > proceed from here? Did you definitely install the signed release of the drivers (from https://xenbits.xen.org/pvdrivers/win/8.2.2/)? Paul > > I had to enable test signing to install the drivers but ultimately my > small business client should not see a desktop that says "Test mode". Is > there a way to run production systems with the WinPV drivers or is it > still considered experimental/test only? > > kind regards, > Jan > > > From win-pv-devel-bounces@lists.xenproject.org Fri May 22 09:01:21 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 22 May 2020 09:01:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jc3YO-0002RI-Nk; Fri, 22 May 2020 09:01:20 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jc3YN-0002RD-JS for win-pv-devel@lists.xenproject.org; Fri, 22 May 2020 09:01:19 +0000 X-Inumbo-ID: cb289090-9c0a-11ea-ab9c-12813bfff9fa Received: from mail.hldns.com (unknown [199.249.188.77]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id cb289090-9c0a-11ea-ab9c-12813bfff9fa; Fri, 22 May 2020 09:01:17 +0000 (UTC) Received: from [192.168.0.36] (71-209-223-236.phnx.qwest.net [71.209.223.236]) by mail.hldns.com (Postfix) with ESMTPSA id 9A4EF8F87A5; Fri, 22 May 2020 02:01:16 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hldns.com; s=mail-dkim; t=1590138076; bh=9LNTS7J3fCVJvLq35fhFQlexTVKz7E6NqLrlBiU5uhA=; h=Content-Type:Content-Transfer-Encoding:From:Mime-Version:Subject: Date:Message-Id:References:Cc:In-Reply-To:To; b=2eMuXpGvH+Tb0i+uNgHqmSw+mW/hXG8/Xx+AeoJejUJlAqwnafuvCVTxPj50TblTK XS9tt65XDNbUaPzxj16yIdiZqjTOYSizpn0L2OHhdXcey+y3cW4ebvZ2vXsmoKikam dpUn/ApIF95kdAhIZK6FxcH/piMjfFxAr42nF/Cu+aIM282m8ZxnCS++3ptBhHf3UF WkjFzzuzVxFUwl7zTL5P9eR3RfmRciQOSYERMjPaztQBT6fCdcLDZL2kwRDIAqHP1N WQREdGHy5cWpOSUHN5hnKapFHA2QVH0JLSDoWRdasbq/7wALW0WQ03+qxfeZodMErq u3vSORyMXm1qg== Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Steffan Cline Mime-Version: 1.0 (1.0) Subject: Re: Installing WinPV drivers on Windows 2019 Date: Fri, 22 May 2020 02:01:15 -0700 Message-Id: References: <000301d63017$29592f20$7c0b8d60$@xen.org> In-Reply-To: <000301d63017$29592f20$7c0b8d60$@xen.org> To: paul@xen.org X-Mailer: iPhone Mail (17E262) X-BeenThere: win-pv-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Developer list for the Windows PV Drivers subproject List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: win-pv-devel@lists.xenproject.org, jan.bakuwel@gmail.com Errors-To: win-pv-devel-bounces@lists.xenproject.org Sender: "win-pv-devel" Paul, this is the same type issue I just reported a month ago. Once the driv= ers are installed, upgrades don=E2=80=99t work. You can only remove and rein= stall the same version drivers.=20 Thanks, Steffan Cline steffan@hldns.com 602-793-0014 > On May 22, 2020, at 1:58 AM, Paul Durrant wrote: >=20 > =EF=BB=BF >>=20 >> -----Original Message----- >> From: win-pv-devel On Behalf O= f Jan Bakuwel >> Sent: 22 May 2020 00:58 >> To: win-pv-devel@lists.xenproject.org >> Subject: Installing WinPV drivers on Windows 2019 >>=20 >> Hi all, >>=20 >> Additionally to the email I sent yesterday.... >>=20 >> I've removed the old v8.2.0 drivers from the Windows 2019 server and >> installed the v8.2.2 drivers. Windows doesn't seem to be happy with >> those though; after rebooting Windows wanted to "repair" the system and >> now crashes with an "inaccessible boot device". Any suggestions how to >> proceed from here? >=20 > Did you definitely install the signed release of the drivers (from https:/= /xenbits.xen.org/pvdrivers/win/8.2.2/)? >=20 > Paul >=20 >>=20 >> I had to enable test signing to install the drivers but ultimately my >> small business client should not see a desktop that says "Test mode". Is >> there a way to run production systems with the WinPV drivers or is it >> still considered experimental/test only? >>=20 >> kind regards, >> Jan >>=20 >>=20 >>=20 >=20 >=20 >=20 From win-pv-devel-bounces@lists.xenproject.org Fri May 22 09:26:44 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 22 May 2020 09:26:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jc3wx-0004yY-Ne; Fri, 22 May 2020 09:26:43 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jc3ww-0004yP-Cc for win-pv-devel@lists.xenproject.org; Fri, 22 May 2020 09:26:42 +0000 X-Inumbo-ID: 584d1fcc-9c0e-11ea-ae69-bc764e2007e4 Received: from mail-wm1-x330.google.com (unknown [2a00:1450:4864:20::330]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 584d1fcc-9c0e-11ea-ae69-bc764e2007e4; Fri, 22 May 2020 09:26:41 +0000 (UTC) Received: by mail-wm1-x330.google.com with SMTP id u1so8022601wmn.3 for ; Fri, 22 May 2020 02:26:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=iUXO4zw12LmwAodEdQqB+hHs8WJtmJQPp06Y4N2ZK68=; b=fxz9At2wJwBLvIvY5DM8ENLG20HNcOTuTF6/nhtTZHsFwIEi4FvDkyeU3TmmzDF635 iWUaaaILShBGUdxoMg1C1JCmzwcUW0gq6ax5wNe5KawT8LWukdKJZYqQRf0DsQ8J4iI9 QdmktuhYe6TkwP5siZGIR59bOTXO184+jEPvySHJ3q7EKkRQRkGdQkK8XrxaqlcN67fQ +tU0P0eii8C32goNVEIqWpjamcB7TKjuAxoopgCZEjdrFgd8+Njn+PMZ4qzw5CAl276S ByWCfmY/Bjatu0lg+V8bC01cmA6a7H4uix9PQNvBsq0QnDvtFg3ajOnQVICefJ0gRowS mLDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=iUXO4zw12LmwAodEdQqB+hHs8WJtmJQPp06Y4N2ZK68=; b=nvaqgypRAKUgu1+8h9KDzNy2RT4k+mav6dkhN7W9OweqeDFu8JtinIs1LqJcfM0cay tRvSO42erAwc1oHj/PbYS/PuWEDGbI5SdlKRt/EwtYgYH1GhQhuxiR/wul/E3wtTyeDA YB6bkdAxWm8UmMU8Eyjv3t0f/4iGQsRl186p+S9OgOS877DkjrWoiE9Ir1yh4mF3gPOb D13fCPIeQYTJuNrY0DT6LbvDAhONMEVjXXzEoKdVlGexrFriC7UTWb/S57uJG5N+kGgN w9jAExaEw1NCh3enmgeeX83mNqaWda1jLMX31apQCLJO83oruN2OSgsj6+ug9mrenxIw mC4A== X-Gm-Message-State: AOAM5330x7feHLs2Ogjw9e+HGxv+4cf1ud1IibtBzz9SJ6GJGcr5R2aJ JBR7QIoZuWeDCpcL2lghPfs= X-Google-Smtp-Source: ABdhPJx8KtliFTbKdJSIS5h1GcnC1hxx11reVBWTs+YybNVyf0gd1DUvfQIsxcL7DT2L/8SkjEsYfA== X-Received: by 2002:a7b:c8c1:: with SMTP id f1mr13323950wml.66.1590139600926; Fri, 22 May 2020 02:26:40 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.186]) by smtp.gmail.com with ESMTPSA id z16sm455185wmf.3.2020.05.22.02.26.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 May 2020 02:26:40 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Steffan Cline'" References: <000301d63017$29592f20$7c0b8d60$@xen.org> In-Reply-To: Subject: RE: Installing WinPV drivers on Windows 2019 Date: Fri, 22 May 2020 10:26:39 +0100 Message-ID: <000601d6301b$1967eda0$4c37c8e0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQE/w0gEIgD5a8tqQXXEqSYVa9klxwHtzAOLqdFAhVA= X-BeenThere: win-pv-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Developer list for the Windows PV Drivers subproject List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: win-pv-devel@lists.xenproject.org, jan.bakuwel@gmail.com Errors-To: win-pv-devel-bounces@lists.xenproject.org Sender: "win-pv-devel" > -----Original Message----- > From: Steffan Cline > Sent: 22 May 2020 10:01 > To: paul@xen.org > Cc: jan.bakuwel@gmail.com; win-pv-devel@lists.xenproject.org > Subject: Re: Installing WinPV drivers on Windows 2019 >=20 > Paul, this is the same type issue I just reported a month ago. Once = the drivers are installed, > upgrades don=E2=80=99t work. You can only remove and reinstall the = same version drivers. It doesn't sound quite the same. You were upgrading to 9.0.0 and had = test signing on, right? This appears to be an issue with 8.2.2 which is = solved *if* testsigning is turned on... which should not be necessary = for release-signed drivers. Paul >=20 >=20 > Thanks, > Steffan Cline > steffan@hldns.com > 602-793-0014 >=20 > > On May 22, 2020, at 1:58 AM, Paul Durrant = wrote: > > > >=20 > >> > >> -----Original Message----- > >> From: win-pv-devel On = Behalf Of Jan Bakuwel > >> Sent: 22 May 2020 00:58 > >> To: win-pv-devel@lists.xenproject.org > >> Subject: Installing WinPV drivers on Windows 2019 > >> > >> Hi all, > >> > >> Additionally to the email I sent yesterday.... > >> > >> I've removed the old v8.2.0 drivers from the Windows 2019 server = and > >> installed the v8.2.2 drivers. Windows doesn't seem to be happy with > >> those though; after rebooting Windows wanted to "repair" the system = and > >> now crashes with an "inaccessible boot device". Any suggestions how = to > >> proceed from here? > > > > Did you definitely install the signed release of the drivers (from > https://xenbits.xen.org/pvdrivers/win/8.2.2/)? > > > > Paul > > > >> > >> I had to enable test signing to install the drivers but ultimately = my > >> small business client should not see a desktop that says "Test = mode". Is > >> there a way to run production systems with the WinPV drivers or is = it > >> still considered experimental/test only? > >> > >> kind regards, > >> Jan > >> > >> > >> > > > > > > From win-pv-devel-bounces@lists.xenproject.org Fri May 22 16:24:10 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Fri, 22 May 2020 16:24:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jcASu-0007Sh-AG; Fri, 22 May 2020 16:24:08 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jcASs-0007Sc-VZ for win-pv-devel@lists.xenproject.org; Fri, 22 May 2020 16:24:07 +0000 X-Inumbo-ID: a809ce9a-9c48-11ea-abf8-12813bfff9fa Received: from mail.hldns.com (unknown [199.249.188.77]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id a809ce9a-9c48-11ea-abf8-12813bfff9fa; Fri, 22 May 2020 16:24:06 +0000 (UTC) Received: from [192.168.0.36] (71-209-223-236.phnx.qwest.net [71.209.223.236]) by mail.hldns.com (Postfix) with ESMTPSA id 490638F87A5; Fri, 22 May 2020 09:24:04 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hldns.com; s=mail-dkim; t=1590164644; bh=YPnbf3VhxmGPGpy3l28SJDV1iLKgAya4eILSxtCEDCw=; h=Content-Type:Content-Transfer-Encoding:From:Mime-Version:Subject: Date:Message-Id:References:Cc:In-Reply-To:To; b=2PwoDKgGoa7qtZYLikQdFZBmkxX1p6wbs8eeCLT+a9bdlxQ4wavxZVWUuFAlD+MKC 043PxpSrBybU57fepksSvO2ymspwVZ3OvkN2MsTHQaHyr3Q43J2uCCOXgULv1dbXf4 H/N7YriDd+uzVHVqjjc+djQGZ8+f87ciZ6adokfUjlYGpzJvl10LS84GgjCyIGqr6Q eBprKXaKNxBnDWjsYaIwlh9hJZt73G2yZgf2KZGlcLqqV2/k52cM8pMAKoG8l5ZBhM /2bMg+xh8VZofN2fgD82DjmZx36B+8b+kZd1wjCAtV+hu7j5yJT6j+irGs2gYtR0YU wm8f/jZhaAu5A== Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Steffan Cline Mime-Version: 1.0 (1.0) Subject: Re: Installing WinPV drivers on Windows 2019 Date: Fri, 22 May 2020 09:24:03 -0700 Message-Id: References: <000601d6301b$1967eda0$4c37c8e0$@xen.org> In-Reply-To: <000601d6301b$1967eda0$4c37c8e0$@xen.org> To: paul@xen.org X-Mailer: iPhone Mail (17E262) X-BeenThere: win-pv-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Developer list for the Windows PV Drivers subproject List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: win-pv-devel@lists.xenproject.org, jan.bakuwel@gmail.com Errors-To: win-pv-devel-bounces@lists.xenproject.org Sender: "win-pv-devel" Paul, No, test signing was not on. This issue has hit me in the past with the same= versions he has. I always thought it was me and either reverted to the orig= inal version or built a new VM with newer OS and drivers.=20 Thanks, Steffan Cline steffan@hldns.com 602-793-0014 > On May 22, 2020, at 2:26 AM, Paul Durrant wrote: >=20 > =EF=BB=BF >>=20 >> -----Original Message----- >> From: Steffan Cline >> Sent: 22 May 2020 10:01 >> To: paul@xen.org >> Cc: jan.bakuwel@gmail.com; win-pv-devel@lists.xenproject.org >> Subject: Re: Installing WinPV drivers on Windows 2019 >>=20 >> Paul, this is the same type issue I just reported a month ago. Once the d= rivers are installed, >> upgrades don=E2=80=99t work. You can only remove and reinstall the same v= ersion drivers. >=20 > It doesn't sound quite the same. You were upgrading to 9.0.0 and had test s= igning on, right? This appears to be an issue with 8.2.2 which is solved *if= * testsigning is turned on... which should not be necessary for release-sign= ed drivers. >=20 > Paul >=20 >>=20 >>=20 >> Thanks, >> Steffan Cline >> steffan@hldns.com >> 602-793-0014 >>=20 >>>> On May 22, 2020, at 1:58 AM, Paul Durrant wrote: >>>=20 >>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: win-pv-devel On Behal= f Of Jan Bakuwel >>>> Sent: 22 May 2020 00:58 >>>> To: win-pv-devel@lists.xenproject.org >>>> Subject: Installing WinPV drivers on Windows 2019 >>>>=20 >>>> Hi all, >>>>=20 >>>> Additionally to the email I sent yesterday.... >>>>=20 >>>> I've removed the old v8.2.0 drivers from the Windows 2019 server and >>>> installed the v8.2.2 drivers. Windows doesn't seem to be happy with >>>> those though; after rebooting Windows wanted to "repair" the system and= >>>> now crashes with an "inaccessible boot device". Any suggestions how to >>>> proceed from here? >>>=20 >>> Did you definitely install the signed release of the drivers (from >> https://xenbits.xen.org/pvdrivers/win/8.2.2/)? >>>=20 >>> Paul >>>=20 >>>>=20 >>>> I had to enable test signing to install the drivers but ultimately my >>>> small business client should not see a desktop that says "Test mode". I= s >>>> there a way to run production systems with the WinPV drivers or is it >>>> still considered experimental/test only? >>>>=20 >>>> kind regards, >>>> Jan >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >=20 >=20 From win-pv-devel-bounces@lists.xenproject.org Sat May 23 04:29:55 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Sat, 23 May 2020 04:29:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jcLnF-0008Cu-Fp; Sat, 23 May 2020 04:29:53 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jcLnE-0008Cp-4J for win-pv-devel@lists.xenproject.org; Sat, 23 May 2020 04:29:52 +0000 X-Inumbo-ID: 0acddc78-9cae-11ea-9887-bc764e2007e4 Received: from mail-pj1-x102e.google.com (unknown [2607:f8b0:4864:20::102e]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0acddc78-9cae-11ea-9887-bc764e2007e4; Sat, 23 May 2020 04:29:51 +0000 (UTC) Received: by mail-pj1-x102e.google.com with SMTP id nu7so5859184pjb.0 for ; Fri, 22 May 2020 21:29:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=reply-to:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=pYHFpyKSNcTJKpa4AoFl8I775utBBrqXZ07KQHm7uS4=; b=axdWUCP7S3UMTclnKRL6e/ygsAKbVcZI0QdQ38qyPsEtVtgxCE+4lqCfQlsIbbAoh+ zRSoySvZbcQPHsukWTVwq0og5oF9g5UX8HNJq3eYs8XN6e+C73bpy76Z7pQ/RcfxYV3T nHxrFEeHo++Auo+mTjSlWGEfYoNF1LGgDY4Sq53qiUerHXu7zTb1yFV/s92jt+KpkoEO gAi3OBhsUyi6XK+J6GF3t3rgDHNMzOwCbt2p3ME3MZW1qAHkpgQvgdLEmtit9/FpXjmd nIU718DoH7cS0kYWRYEsqFOWl3f2bvte0g+9XF1HOPDR8o68BznbA9I++HrT3hmMGvzb cJcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=pYHFpyKSNcTJKpa4AoFl8I775utBBrqXZ07KQHm7uS4=; b=B5IP9XpF0yrQM0opu/JPtKfoycwEINAsM9xXIG12yII+E0ZIRmuGaN0k+flf/WcJZW kpk9Ja4a2di95aBKTUlQO2SMSQdY8OjoFY4Fg+tGxDKWotpi43zcvxJFRy+BJjpmdJK6 635Y8dTx4F5kWfC+5oN8gOYa8HhGEszXQg6P8aQw9VpXdVzxUce5MvhJBiQoVENhOKPu Odv8awXhPGkc5l48W13jdSDeq1HNTjqQYXH7tcHsOC8ZuOd3ysXgQzfPfu2cxj5NI3fY VILfOJarHPGePmILZxJBUyJSSnMzUzTcZ1Z+UQanGjj0eTaqaOqY8HZgArUFU95FPggo /DAw== X-Gm-Message-State: AOAM533oSJR/7uvZu7Kr1BGuDuiUPvQu0/YHRek/FyQL3osXtuNSBFT6 hXNR8bT30fNFhhvmZbi3PMa0okaQ X-Google-Smtp-Source: ABdhPJzJWpgRTMrIW3OeTvppWZCQdOqsaQIkaj4rosu39YnlXbBFr2P6G1ObQdmfLz4w1zuLJA/ISQ== X-Received: by 2002:a17:902:cb03:: with SMTP id c3mr18567438ply.307.1590208189842; Fri, 22 May 2020 21:29:49 -0700 (PDT) Received: from [10.10.15.22] ([103.227.170.10]) by smtp.gmail.com with ESMTPSA id fw4sm7988929pjb.31.2020.05.22.21.29.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 22 May 2020 21:29:48 -0700 (PDT) Subject: Re: Installing WinPV drivers on Windows 2019 To: paul@xen.org, win-pv-devel@lists.xenproject.org References: <000301d63017$29592f20$7c0b8d60$@xen.org> From: Jan Bakuwel Message-ID: <37934f7a-fb96-274c-e5e4-95de2bab55e6@gmail.com> Date: Sat, 23 May 2020 16:29:44 +1200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <000301d63017$29592f20$7c0b8d60$@xen.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: win-pv-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Developer list for the Windows PV Drivers subproject List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: jan.bakuwel@gmail.com Errors-To: win-pv-devel-bounces@lists.xenproject.org Sender: "win-pv-devel" Hi Paul, On 22/05/20 8:58 pm, Paul Durrant wrote: >> -----Original Message----- >> From: win-pv-devel On Behalf Of Jan Bakuwel >> Sent: 22 May 2020 00:58 >> To: win-pv-devel@lists.xenproject.org >> Subject: Installing WinPV drivers on Windows 2019 >> >> Hi all, >> >> Additionally to the email I sent yesterday.... >> >> I've removed the old v8.2.0 drivers from the Windows 2019 server and >> installed the v8.2.2 drivers. Windows doesn't seem to be happy with >> those though; after rebooting Windows wanted to "repair" the system and >> now crashes with an "inaccessible boot device". Any suggestions how to >> proceed from here? > Did you definitely install the signed release of the drivers (from https://xenbits.xen.org/pvdrivers/win/8.2.2/)? Are there also unsigned 8.2.2 drivers available to download and install? I'm pretty sure I downloaded the ones you're referring to. I could not install the 8.2.2 drivers until I enabled test signing: the setup immediately fails when attempting with test signing off. It had been a while since I installed those drivers and I had a vague recollection of having to install the certificates to get around the "Test Mode" shown on the desktop. So, I imported the 5 certificates from the source trees, then installed the drivers with test signing enabled. Then Windows needed to "repair" the system and ended up with an inaccessible boot device. I restored the VM from backup, removed the 8.2.0 drivers, then installed https://github.com/xcp-ng/win-pv-drivers/releases. These have been fine for a few days now on the test VM but we yet have to see what happens on a production system. After all the 8.2.0 drivers also worked fine for months until the system went into production and then started crashing, sometimes once every few weeks, sometimes multiple times in a week or day. Which version of the drivers should I install on a production system? The ones released by XCP-NG (even though I'm running Xen Open Source, not XCP-NG? 8.2.2 or 9.0.0? I'm happy to give it another go with the version you recommend. Should I check remaining registry entries or should the uninstaller (via Control Panel) take care of removing those? regards, Jan > > Paul > >> I had to enable test signing to install the drivers but ultimately my >> small business client should not see a desktop that says "Test mode". Is >> there a way to run production systems with the WinPV drivers or is it >> still considered experimental/test only? >> >> kind regards, >> Jan >> >> >> > > . From win-pv-devel-bounces@lists.xenproject.org Mon May 25 10:40:26 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 25 May 2020 10:40:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jdAWt-0004va-FG; Mon, 25 May 2020 10:40:23 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jcBhT-0006QK-VV for win-pv-devel@lists.xenproject.org; Fri, 22 May 2020 17:43:16 +0000 X-Inumbo-ID: b4fef265-9c53-11ea-ac02-12813bfff9fa Received: from mail-40131.protonmail.ch (unknown [185.70.40.131]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b4fef265-9c53-11ea-ac02-12813bfff9fa; Fri, 22 May 2020 17:43:13 +0000 (UTC) Date: Fri, 22 May 2020 17:43:05 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1590169392; bh=klLQqxa6K6ffz+UXv5vXc3Fble6INGfE8YzAjH4k1oo=; h=Date:To:From:Reply-To:Subject:From; b=Q40w8u2LCU7jZQVAb0JMzZLZ1Dof/UqpzIvTAmPIsIWNKYo5X/acekr4YKTNCmo4b CMYdMV7j27wx1Tsm5aN5eT5db1KJaqHtnxa6y73JozMCJmznAgIHmBGhQVKgmXUJ2N vI9ap5dUCRklt+8lzYEy5trWuxVNaCwbvOIMPXAU= To: "win-pv-devel@lists.xenproject.org" From: Connor Davis Subject: Bug in GnttabQueryReference Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Mailman-Approved-At: Mon, 25 May 2020 10:40:22 +0000 X-BeenThere: win-pv-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Developer list for the Windows PV Drivers subproject List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: Connor Davis Errors-To: win-pv-devel-bounces@lists.xenproject.org Sender: "win-pv-devel" Hi All, There appears to be a bug in xenbus/src/xenbus/gnttab.c:GnttabQueryReferenc= e. The check for a ReadOnly entry uses (Context->Table[Reference].frame & GTF_readonly) instead of (Context->Table[Reference].flags & GTF_readonly) I grepped across all the PV drivers and it looks like this function is only used for the store and console references, which pass NULL to ReadOnly= , so the bug hasn't actually manifested yet. Cheers, Connor Davis From win-pv-devel-bounces@lists.xenproject.org Mon May 25 10:46:30 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 25 May 2020 10:46:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jdAcm-00054H-UP; Mon, 25 May 2020 10:46:28 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jdAcm-00054C-61 for win-pv-devel@lists.xenproject.org; Mon, 25 May 2020 10:46:28 +0000 X-Inumbo-ID: fbb8e3a4-9e74-11ea-ae69-bc764e2007e4 Received: from mail-wr1-x435.google.com (unknown [2a00:1450:4864:20::435]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id fbb8e3a4-9e74-11ea-ae69-bc764e2007e4; Mon, 25 May 2020 10:46:27 +0000 (UTC) Received: by mail-wr1-x435.google.com with SMTP id j16so4218219wrb.7 for ; Mon, 25 May 2020 03:46:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=84AGxXAqzhAg75kqyxmahw5pZhK4Xvf+RYk/Qz3pDkM=; b=F/pIaMDLaoXnbSsedIWmYpo2qUM7iBMNwJ9FOfnOfVmvYyJrwRnDWFZwls9IlILfol yB4cwb8vrSuXXxpm1InyMpmM06+S/CnEQrVqboascFBQq9mQ9vSgwSi8bzdH1qKhVmNb ioPDsR6YOoVgCekHIikgXnl2YsKic2CaPBo0lrvk98x7oHPt/tutYKMRddyYN9ddsUZZ /HvLeC6LhVCzup0qcouoFLoC7UD6eqX7SnMMb78Zw0NnC7psgn/GRRCoi4u8sBAgddmv WjQjY/LcsxJNicxRgBw/wWn4r2uiH5KU1Q1Vulw44rlv3Hf2RYaryEij/xFUArq2mbyW L58A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=84AGxXAqzhAg75kqyxmahw5pZhK4Xvf+RYk/Qz3pDkM=; b=lcJwoMdydEIG3JBGnq2FmmXDpEmr65q/a7cncLyOf5Ljwh9ZGkk9hU3imiIVQxTfBu xAzhfWzM+Y+KxemVS4Spb29wsGU0Rb50OtLN50CbJLMgixxMt8ymL23IuI9xxgbNWUSl x0aOZYgSdZSjA1FGmK+dVH1BE+Ah9+QR7u0cIfHZRHv8gQvGUgBCaimBlv6YQ06CxMvu lGy7ujtJNiPTcBQZX2IFQgqWDOdjAM725ShpFY3MejMtsAAg5KrBX2WfAOEox5cIeGt3 dBYrbUNcd1hFxskfUEftoHeV5VstwzBvHo6v2AkxNxkJ1FytO0Sm/iaFM+0rENDAhQ4B TcKw== X-Gm-Message-State: AOAM532NskG0HlzVx/Uy2qaugpNZNwcV1i8/H5XjdvTpfW/cZlnekt6I TfkyhpROg2d0+WbH48i2/Aw= X-Google-Smtp-Source: ABdhPJxnzaUepiK5O1/qJAvtOT1p3aUlMwe3XyBpzl3kQO2/1JB5KBFG5Nszpupck/isiAFwn2GFKw== X-Received: by 2002:adf:aa9a:: with SMTP id h26mr6046168wrc.61.1590403586105; Mon, 25 May 2020 03:46:26 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.187]) by smtp.gmail.com with ESMTPSA id a12sm12364754wrs.70.2020.05.25.03.46.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 May 2020 03:46:25 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: , References: <000301d63017$29592f20$7c0b8d60$@xen.org> <37934f7a-fb96-274c-e5e4-95de2bab55e6@gmail.com> In-Reply-To: <37934f7a-fb96-274c-e5e4-95de2bab55e6@gmail.com> Subject: RE: Installing WinPV drivers on Windows 2019 Date: Mon, 25 May 2020 11:46:24 +0100 Message-ID: <001d01d63281$bcd9ab00$368d0100$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQKmfdhS0zU5AzZ9bnw/nfbxk8vVcgE/w0gEAiov3K+m/LaRYA== X-BeenThere: win-pv-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Developer list for the Windows PV Drivers subproject List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Errors-To: win-pv-devel-bounces@lists.xenproject.org Sender: "win-pv-devel" > -----Original Message----- > From: Jan Bakuwel > Sent: 23 May 2020 05:30 > To: paul@xen.org; win-pv-devel@lists.xenproject.org > Subject: Re: Installing WinPV drivers on Windows 2019 >=20 > Hi Paul, >=20 Hi Jan, > On 22/05/20 8:58 pm, Paul Durrant wrote: > >> -----Original Message----- > >> From: win-pv-devel On = Behalf Of Jan Bakuwel > >> Sent: 22 May 2020 00:58 > >> To: win-pv-devel@lists.xenproject.org > >> Subject: Installing WinPV drivers on Windows 2019 > >> > >> Hi all, > >> > >> Additionally to the email I sent yesterday.... > >> > >> I've removed the old v8.2.0 drivers from the Windows 2019 server = and > >> installed the v8.2.2 drivers. Windows doesn't seem to be happy with > >> those though; after rebooting Windows wanted to "repair" the system = and > >> now crashes with an "inaccessible boot device". Any suggestions how = to > >> proceed from here? > > Did you definitely install the signed release of the drivers (from > https://xenbits.xen.org/pvdrivers/win/8.2.2/)? >=20 > Are there also unsigned 8.2.2 drivers available to download and = install? No, the 8.2.2 drivers should all be signed now. I'm not aware of an = unsigned build being available for download any more. > I'm pretty sure I downloaded the ones you're referring to. >=20 > I could not install the 8.2.2 drivers until I enabled test signing: = the > setup immediately fails when attempting with test signing off. >=20 This should not happen with the drivers currently available. If it does = then there is something wrong. > It had been a while since I installed those drivers and I had a vague > recollection of having to install the certificates to get around the > "Test Mode" shown on the desktop. So, I imported the 5 certificates = from > the source trees, then installed the drivers with test signing = enabled. > Then Windows needed to "repair" the system and ended up with an > inaccessible boot device. >=20 > I restored the VM from backup, removed the 8.2.0 drivers, then = installed > https://github.com/xcp-ng/win-pv-drivers/releases. These have been = fine > for a few days now on the test VM but we yet have to see what happens = on > a production system. After all the 8.2.0 drivers also worked fine for > months until the system went into production and then started = crashing, > sometimes once every few weeks, sometimes multiple times in a week or = day. >=20 > Which version of the drivers should I install on a production system? > The ones released by XCP-NG (even though I'm running Xen Open Source, > not XCP-NG? 8.2.2 or 9.0.0? >=20 > I'm happy to give it another go with the version you recommend. Should = I > check remaining registry entries or should the uninstaller (via = Control > Panel) take care of removing those? >=20 The XCP-NG drivers *should* be fine. I have not tried them myself for a = while though. The fact they are bundled with an installer does make them = more convenient so I suggest you do give them a go. Paul From win-pv-devel-bounces@lists.xenproject.org Mon May 25 10:48:28 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 25 May 2020 10:48:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jdAei-00058W-42; Mon, 25 May 2020 10:48:28 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jdAeh-00058R-6z for win-pv-devel@lists.xenproject.org; Mon, 25 May 2020 10:48:27 +0000 X-Inumbo-ID: 43190864-9e75-11ea-b9cf-bc764e2007e4 Received: from mail-wm1-x32a.google.com (unknown [2a00:1450:4864:20::32a]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 43190864-9e75-11ea-b9cf-bc764e2007e4; Mon, 25 May 2020 10:48:26 +0000 (UTC) Received: by mail-wm1-x32a.google.com with SMTP id r9so4559328wmh.2 for ; Mon, 25 May 2020 03:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=3KkuTov4h6xUHVgoGOGU9h80v31nqu7ANtXEQsQtByM=; b=nPaIWZJ4h4zzKWmX0aocEfrPLhnljhOeMAET77QWMqxs/MUrm1EXIRxXs7k8ApqOSk dR88lQkuMVEV7RV7PFLYAP+qKpn4PC6gnaAxruTprzdUUs6wT2/DAVhwh//lHOpaUP4u H9h62q9OtxPyQ8a5I7hrpslPlpOgGnQjzqV6+HO6CllnV4SKPwJItqUCNgA0uR9Ya5IJ +RLuINa7bxXxVFMr++ueTDj7aSkBSLtjq08Ydb4TxrKyHwIXxOmphS7supGIpmhfFcmR vDFQACb+TqOJMSAp8QdW1/EP76S+nMmVtYnJ2k7ORTYRfddgjhHit7Vbu+9O0e6KmYqE S5Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=3KkuTov4h6xUHVgoGOGU9h80v31nqu7ANtXEQsQtByM=; b=F1f9wN1lqtI1+wnfI7RqlkCC66n5UdsPNwQuvnJzzDVC/RUsyB5hcG/44nAMZVCDRn rwTrCrMjrrteN0xuxwqxXpHbF6ZkdQTTK6ubS+El6ADQQeI2MhBrJPIqh7KBB6VNoVzP xSbC0IkCWS1/exm4HvbmtTUuNcPDFQpaka6ZIgvUL+reso9AHuawa3fDtreclLY9tp6C T0KJZjb3i5yTuN3JZof6GeViQL7O64+KoGvu/5ACw2kVmW4gi/5oKnYuuZk2H8k2/q3z Mid0XEncPn7UX15pySRmeKRhzA/hPzFITnU1AfJIHc87sHBRPnwLXZrwBrrXHaDEbftM yQMw== X-Gm-Message-State: AOAM531hBKhspcguxW9ra9oXZCaKqwbCV6AvEdDY3sFZh0IMLZYlYLOV V3rK9el5rKwTiWQGvpvWxtA= X-Google-Smtp-Source: ABdhPJzUoKNXnFuO1HQxQhzKRxq7C1ZAr1TONBqharNrl14mmkjLYrZe8u9qaFb2DfEs1vfn/a6KZA== X-Received: by 2002:a1c:4c8:: with SMTP id 191mr766709wme.14.1590403705914; Mon, 25 May 2020 03:48:25 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.186]) by smtp.gmail.com with ESMTPSA id a15sm6083311wra.86.2020.05.25.03.48.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 May 2020 03:48:25 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Connor Davis'" , References: In-Reply-To: Subject: RE: Bug in GnttabQueryReference Date: Mon, 25 May 2020 11:48:24 +0100 Message-ID: <001e01d63282$043863b0$0ca92b10$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQGsWevlDjs4ziQRw63s/MOUGpKtRakMT7YA X-BeenThere: win-pv-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Developer list for the Windows PV Drivers subproject List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Errors-To: win-pv-devel-bounces@lists.xenproject.org Sender: "win-pv-devel" > -----Original Message----- > From: win-pv-devel On Behalf Of Connor Davis > Sent: 22 May 2020 18:43 > To: win-pv-devel@lists.xenproject.org > Subject: Bug in GnttabQueryReference > > Hi All, > > There appears to be a bug in xenbus/src/xenbus/gnttab.c:GnttabQueryReference. > The check for a ReadOnly entry uses > > (Context->Table[Reference].frame & GTF_readonly) > > instead of > > (Context->Table[Reference].flags & GTF_readonly) > > I grepped across all the PV drivers and it looks like this function is > only used for the store and console references, which pass NULL to ReadOnly, > so the bug hasn't actually manifested yet. Yes, that is indeed a bug. Good spot! I'll send a patch to fix it shortly. Paul > > Cheers, > Connor Davis From win-pv-devel-bounces@lists.xenproject.org Mon May 25 11:11:32 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Mon, 25 May 2020 11:11:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jdB10-0007XK-QA; Mon, 25 May 2020 11:11:30 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jdB10-0007XF-63 for win-pv-devel@lists.xenproject.org; Mon, 25 May 2020 11:11:30 +0000 X-Inumbo-ID: 7af74e1f-9e78-11ea-aebe-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 7af74e1f-9e78-11ea-aebe-12813bfff9fa; Mon, 25 May 2020 11:11:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Eflpm6CRgAL9r7XYlm99pXzcnI1YPpvenT/OkqjpvFw=; b=xF4XH372YUcMMMVOCFz31pRj0S YbxwTSq/rhJ/5XrhByE1u72g8mZn9KikZxGezfpVZdxHwhe9b4tQNYSeIa2ntoGfY6KyDtm8NvQ2I ibbPJG6LjPLd99B33B3whgnMdm0uAocbJBoMTeJrVFzloGW3qy3VyboTQRWGbrGRrkck=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jdB0y-0000Q0-Q9; Mon, 25 May 2020 11:11:28 +0000 Received: from [54.239.6.187] (helo=CBG-R90WXYV0.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jdB0y-000506-Gr; Mon, 25 May 2020 11:11:28 +0000 From: Paul Durrant To: win-pv-devel@lists.xenproject.org Subject: [PATCH xenbus] GnttabQueryReference() incorrectly checks for GTF_readonly Date: Mon, 25 May 2020 12:11:24 +0100 Message-Id: <20200525111124.77-1-paul@xen.org> X-Mailer: git-send-email 2.17.1 X-BeenThere: win-pv-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Developer list for the Windows PV Drivers subproject List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Paul Durrant Errors-To: win-pv-devel-bounces@lists.xenproject.org Sender: "win-pv-devel" From: Paul Durrant GTF_readonly should be checked in the 'flags' field, not 'frame'. This patch fixes the issue. Reported-by: Connor Davis Signed-off-by: Paul Durrant --- src/xenbus/gnttab.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/xenbus/gnttab.c b/src/xenbus/gnttab.c index e590a5c..3fe52aa 100644 --- a/src/xenbus/gnttab.c +++ b/src/xenbus/gnttab.c @@ -587,7 +587,7 @@ GnttabQueryReference( *Pfn = Context->Table[Reference].frame; if (ReadOnly != NULL) - *ReadOnly = (Context->Table[Reference].frame & GTF_readonly) ? TRUE : FALSE; + *ReadOnly = (Context->Table[Reference].flags & GTF_readonly) ? TRUE : FALSE; return STATUS_SUCCESS; -- 2.17.1 From win-pv-devel-bounces@lists.xenproject.org Tue May 26 23:36:59 2020 Return-path: Envelope-to: archives@lists.xenproject.org Delivery-date: Tue, 26 May 2020 23:36:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jdj7x-0006Zk-1B; Tue, 26 May 2020 23:36:57 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jdj7v-0006Z0-Iq for win-pv-devel@lists.xenproject.org; Tue, 26 May 2020 23:36:55 +0000 X-Inumbo-ID: c845b5ac-9fa9-11ea-9947-bc764e2007e4 Received: from mail-pj1-x1030.google.com (unknown [2607:f8b0:4864:20::1030]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c845b5ac-9fa9-11ea-9947-bc764e2007e4; Tue, 26 May 2020 23:36:55 +0000 (UTC) Received: by mail-pj1-x1030.google.com with SMTP id ci21so528714pjb.3 for ; Tue, 26 May 2020 16:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=reply-to:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=EOoj3yGbgDeDHzjTxOIUi1Ml8XSQyV+EKlnGxsQ/t+0=; b=UjrONbgWvoghByWBMTDAvGMEnw/PopOf9CMoLAV+pBR0LyFLIKt8OMIolzPeD3fzeX D2RFOXg+u6jPAEWIwBf7kANaD0Y0O0l9kEEd9dy5k0mqn+0hoxQyORppF8UjEejF9LAd oy/sl/uwgOjkhmedOg4Wf+S5D+vezJVw6dN+Ze11Hni46RuvX1uYTX/29UKkPu+nTLYT wozpFggyDbjZ4iEdClacTXTkZ4OYzaPDOsaoYjBeoPCIyUj8ZH2P2w/qe60SKJykn11a XzLwV5Q3JOe2563GilG3Ca33yYNKYjEtdtWP4+ca3H12hGYRR9oQ+HY/ZLlTwrbG5By0 sdmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=EOoj3yGbgDeDHzjTxOIUi1Ml8XSQyV+EKlnGxsQ/t+0=; b=VAdSqgdEOy8iotBY3NogmgCS+oRk+tvERSB/NCoIDNOBZjhCja2XwRC0JODsGR34VZ yhGQahG6pm814TSdDwqPooyii2yO7M1INH2jJcYRDTsIrdx+4h5YtVDHYha9oRFknHN/ 9lRxwQU0cxxqHDGhzganLKPAHmqh+OZgD+5p2UuB2jvGJLxTXs8mtNdR9qLKsgd3Vzs3 ucPvNADpoWMnks+9K84LWzBXDgAwywtqrF9ubSHPK8y0rIk0ZLO1TPQMGbSh1oIsR93n APaL2b4E+i9olYf3YMpu3F2h5CbjFg/LbCaEt53LtP+LX2h11k8bfWazEx6SuhMMDHuB b5xw== X-Gm-Message-State: AOAM5314YWJntn7YPaqsq/Mj5B7MECIXFmtGOyq+2pvn5+uJmn8XGuGU Ey8cegiP2Yzzw1j/DtF25LiobIE/ X-Google-Smtp-Source: ABdhPJw4kHaAbJZxtsrSuP4M1fYELms4u1x1iFrmGwogCrjrI5fOLUZfhm29vqS31ngF40gzW5HEfA== X-Received: by 2002:a17:90a:d317:: with SMTP id p23mr1752745pju.107.1590536213737; Tue, 26 May 2020 16:36:53 -0700 (PDT) Received: from [10.10.15.22] ([103.227.170.10]) by smtp.gmail.com with ESMTPSA id w12sm480786pjn.21.2020.05.26.16.36.51 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2020 16:36:52 -0700 (PDT) Subject: Re: Installing WinPV drivers on Windows 2019 To: win-pv-devel@lists.xenproject.org References: <000301d63017$29592f20$7c0b8d60$@xen.org> <37934f7a-fb96-274c-e5e4-95de2bab55e6@gmail.com> <001d01d63281$bcd9ab00$368d0100$@xen.org> From: Jan Bakuwel Message-ID: Date: Wed, 27 May 2020 11:36:48 +1200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <001d01d63281$bcd9ab00$368d0100$@xen.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: win-pv-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Developer list for the Windows PV Drivers subproject List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: jan.bakuwel@gmail.com Errors-To: win-pv-devel-bounces@lists.xenproject.org Sender: "win-pv-devel" Hi Paul, .... >> Which version of the drivers should I install on a production system? >> The ones released by XCP-NG (even though I'm running Xen Open Source, >> not XCP-NG? 8.2.2 or 9.0.0? >> >> I'm happy to give it another go with the version you recommend. Should I >> check remaining registry entries or should the uninstaller (via Control >> Panel) take care of removing those? >> > The XCP-NG drivers *should* be fine. I have not tried them myself for a while though. The fact they are bundled with an installer does make them more convenient so I suggest you do give them a go. Thanks for your reply. I've installed the XCP-NG drivers on the production VM. Fingers crossed that resolves the issue. Regards, Jan