On Wed, 23 Nov 2016, Jan Beulich wrote:
> >>> On 23.11.16 at 11:45, wrote:
> > No, if QEMU is using a default ioreq server (i.e. the legacy way of doing
> > things) then it's vulnerable to the guest messing with the rings and I'd
> > forgotten that migrated-in guests from old QEMUs also end up u
>>> On 23.11.16 at 11:45, wrote:
> No, if QEMU is using a default ioreq server (i.e. the legacy way of doing
> things) then it's vulnerable to the guest messing with the rings and I'd
> forgotten that migrated-in guests from old QEMUs also end up using the
> default
> server, so I guess this i
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 23 November 2016 10:36
> To: Paul Durrant
> Cc: Anthony Perard ; Stefano Stabellini
> ; xen-devel ;
> qemu-devel@nongnu.org
> Subject: RE: [PATCH 1/3] xen: fix quad word bufioreq handling
>
> >>> On 23.11.16 at 10
>>> On 23.11.16 at 10:48, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 23 November 2016 09:24
>>
>> 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
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 23 November 2016 09:24
> To: qemu-devel@nongnu.org
> Cc: Anthony Perard ; Paul Durrant
> ; Stefano Stabellini ; xen-
> devel
> Subject: [PATCH 1/3] xen: fix quad word bufioreq handling
>
> We should not consume th
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.
Reported-by: yanghongke
Signed
