From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:52504)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <JBeulich@suse.com>) id 1c9UuP-0007Ce-9X
	for qemu-devel@nongnu.org; Wed, 23 Nov 2016 05:36:10 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <JBeulich@suse.com>) id 1c9UuJ-0000os-D7
	for qemu-devel@nongnu.org; Wed, 23 Nov 2016 05:36:09 -0500
Received: from prv-mh.provo.novell.com ([137.65.248.74]:36320)
	by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
	(Exim 4.71) (envelope-from <JBeulich@suse.com>) id 1c9UuJ-0000nI-3m
	for qemu-devel@nongnu.org; Wed, 23 Nov 2016 05:36:03 -0500
Message-Id: <58357F200200007800121344@prv-mh.provo.novell.com>
Date: Wed, 23 Nov 2016 03:36:00 -0700
From: "Jan Beulich" <JBeulich@suse.com>
References: <58356D610200007800121289@prv-mh.provo.novell.com>
	<58356E480200007800121296@prv-mh.provo.novell.com>
	<27145c26bfa849779baa52deddd09294@AMSPEX02CL03.citrite.net>
In-Reply-To: <27145c26bfa849779baa52deddd09294@AMSPEX02CL03.citrite.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Subject: Re: [Qemu-devel] [PATCH 1/3] xen: fix quad word bufioreq handling
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel/>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paul Durrant <Paul.Durrant@citrix.com>
Cc: Anthony Perard <anthony.perard@citrix.com>, Stefano Stabellini <sstabellini@kernel.org>, xen-devel <xen-devel@lists.xenproject.org>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>

>>> On 23.11.16 at 10:48, <Paul.Durrant@citrix.com> wrote:
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: 23 November 2016 09:24
>>=20
>> We should not consume the second slot if it didn't get written yet.
>> Normal writers - i.e. Xen - would not update write_pointer between the
>> two writes, but the page may get fiddled with by the guest itself, and
>> we're better off entering an infinite loop in that case.
>>=20
>=20
> Xen would never put QEMU in this situation and the guest can't =
actually=20
> modify the page whilst it's in use, since activation of the IOREQ =
server=20
> removes the page from the guest's p2m so the premise of the patch is =
not=20
> correct.

Is that the case even for pre-ioreq-server Xen versions? The issue
here was reported together with what became XSA-197, and it's
not been assigned its own XSA just because there are other ways
for a guest to place high load on its qemu process (and there are
ways to deal with such high load situations).

Jan