qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/3] xen: fix quad word bufioreq handling


From: Paul Durrant
Subject: Re: [Qemu-devel] [PATCH 1/3] xen: fix quad word bufioreq handling
Date: Wed, 23 Nov 2016 09:48:09 +0000

> -----Original Message-----
> From: Jan Beulich [mailto:address@hidden
> Sent: 23 November 2016 09:24
> To: address@hidden
> Cc: Anthony Perard <address@hidden>; Paul Durrant
> <address@hidden>; Stefano Stabellini <address@hidden>; xen-
> devel <address@hidden>
> Subject: [PATCH 1/3] xen: fix quad word bufioreq handling
> 
> 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.
> 

Xen would never put QEMU in this situation and the guest can't actually modify 
the page whilst it's in use, since activation of the IOREQ server removes the 
page from the guest's p2m so the premise of the patch is not correct.

  Paul

> Reported-by: yanghongke <address@hidden>
> Signed-off-by: Jan Beulich <address@hidden>
> ---
> TBD: Alternatively we could call e.g. hw_error() instead.
> 
> --- a/xen-hvm.c
> +++ b/xen-hvm.c
> @@ -1021,6 +1021,9 @@ static int handle_buffered_iopage(XenIOS
>          xen_rmb();
>          qw = (req.size == 8);
>          if (qw) {
> +            if (rdptr + 1 == wrptr) {
> +                break;
> +            }
>              buf_req = &buf_page->buf_ioreq[(rdptr + 1) %
>                                             IOREQ_BUFFER_SLOT_NUM];
>              req.data |= ((uint64_t)buf_req->data) << 32;
> 
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]