Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 05 Jul 2011 18:14:17 -0700
From:      Colin Percival <cperciva@freebsd.org>
To:        gibbs@freebsd.org
Cc:        "freebsd-xen@freebsd.org" <freebsd-xen@freebsd.org>
Subject:   Re: breakage in blkfront with ring_pages > 1
Message-ID:  <4E13B6E9.9070202@freebsd.org>
In-Reply-To: <4DF27EFF.5060005@FreeBSD.org>
References:  <4DF18EE5.5090704@freebsd.org> <4DF27EFF.5060005@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 06/10/11 13:30, Justin T. Gibbs wrote:
>  On 6/9/11 9:26 PM, Colin Percival wrote:
>> Has anyone seen anything like this? Is it possible that there's a bug
>> in how our blkfront negotiates the request ring? Does anyone have
>> ring_pages > 1 in use?
> 
> The only backend driver I know of that can support more than one ring page
> is FreeBSD.  So, the problem likely is that blkfront is getting the
> negotiation wrong and only 1 page is in use.

Turns out that the linux backend in question really does support multiple pages.
There's also an inconsistency about how multiple rings are negotiated:
We set:
  * ring-pages to the number of pages blkfront wants to use
  * ring-ref to the reference for the first page
  * ring-refXX to the references for other pages
while linux sets:
  * num-ring-pages to the number of pages blkfront wants to use
  * ring-refXX to the page references.

It seems to be impossible to be compatible with both, since Linux interprets
having a value set for ring-ref to indicate that the single-ring protocol is
being used and doesn't check anything else.

Is there any official source which defines the blkback/front protocol?  Maybe
the right option is to have a loader tunable dev.xn.linuxback to control which
version of the protocol is used?

-- 
Colin Percival
Security Officer, FreeBSD | freebsd.org | The power to serve
Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E13B6E9.9070202>