Re: [Xen-devel] [PATCH] xen: fix ring resize of /dev/evtchn

[David Vrabel <david.vrabel@xxxxxxxxxx>]

On 04/05/16 14:02, Jan Beulich wrote:
> The copying of ring data was wrong for two cases: For a full ring
> nothing got copied at all (as in that case the canonicalized producer
> and consumer indexes are identical). And in case one or both of the
> canonicalized (after the resize) indexes would point into the second
> half of the buffer, the copied data ended up in the wrong (free) part
> of the new buffer. In both cases uninitialized data would get passed
> back to the caller.
> 
> Fix this by simply copying the old ring contents twice: Once to the
> low half of the new buffer, and a second time to the high half.
> 
> This addresses the inability to boot a HVM guest with 64 or more
> vCPU-s, which was reported by Konrad Rzeszutek Wilk
> <konrad.wilk@xxxxxxxxxx>.
[...]

Can you include the commit that introduced this regression and which
kernel versions it affects as this is a stable candidate.

> @@ -344,22 +343,13 @@ static int evtchn_resize_ring(struct per
>       spin_lock_irq(&u->ring_prod_lock);
>  
>       /*
> -      * Copy the old ring contents to the new ring.
> -      *
> -      * If the ring contents crosses the end of the current ring,
> -      * it needs to be copied in two chunks.
> -      *
> -      * +---------+    +------------------+
> -      * |34567  12| -> |       1234567    |
> -      * +-----p-c-+    +------------------+
> +      * Copy the old ring contents to the new ring. To take care of
> +      * wrapping, a full ring, and the new canonicalized index pointing
> +      * into the second half, simply copy the old contents twice.

Could you keep the ascii art?

e.g.,

 * +---------+    +------------------+
 * |34567  12| -> |34567  1234567  12|
 * +-----p-c-+    +-------c------p---+

So it is obvious that the double copy does the right thing.

Thanks.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel