Xen devel - Feb 2008 - determining dom0 version and bit size from domU

To overcome the problems I am having with the windows vbd drivers when
DomU bit width != Dom0 bit width, I would like to implement a kludge
with an algorithm something like:

"
if Dom0 Xen version >= 3.1.1
  set ''protocol'' and it''s business as usual
else
  if Dom0 is 64 bits
    align the blkif structures to 8 bytes
  else
    align the blkif structures to 4 bytes
"

Unfortunately, it doesn''t look like I can determine the version of Xen
that the Dom0 kernel was compiled against, nor the bit width of Dom0. I
think I can get some indication of the hypervisor version, but that is
irrelevant.

Am I out of luck here? If I need to implement anything in Dom0 to do it
then I''ll just document the Windows Xen PV drivers as being compatible
only with 3.1.1 and above if you want to mix and match bit widths... but
it would be nice to support older code.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> Unfortunately, it doesn''t look like I can determine the version of
Xen
> that the Dom0 kernel was compiled against, nor the bit width of Dom0.
I
> think I can get some indication of the hypervisor version, but that is
> irrelevant.
The more I look at this the more I think that Dom0 just doesn''t make
this information available.

So another possible solution I have for determining what is going on is:

1. Write a request (op = 0xff, id = 0) to the ring, and fill all the
seg[] entries with 0xff too.
2. Wait for the response from Dom0, confirm that we get a failure (I''m
assuming that Dom0 will just return ''BLKIF_RSP_ERROR'' here)
3. Write another request (op = 0xff, id = 0xffffffffffffffff to the
ring)
4. Wait for the response from Dom0, if we get the same response as
before then we are done and can continue as normal.
5. If we didn''t get the same response, then switch bit widths (32 ->
64,
or 64 -> 32), then continue as normal.

Sounds like it might work in theory, as long as Dom0 doesn''t have a
huge
panic attack when it gets op=0xff, or a completely misaligned request
(the id = 0xffffffffffffffff and seg[..] = 0xff is so that if we have
our alignments wrong, the backend still see''s a request of 0xff and not
a bizarre read operation).

Any thoughts?

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 2/2/08 02:40, "James Harper" <james.harper@bendigoit.com.au>
wrote:
> Am I out of luck here? If I need to implement anything in Dom0 to do it
> then I''ll just document the Windows Xen PV drivers as being
compatible
> only with 3.1.1 and above if you want to mix and match bit widths... but
> it would be nice to support older code.
Requiring 3.1.1+ is probably not unreasonable.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> On 2/2/08 02:40, "James Harper"
<james.harper@bendigoit.com.au> wrote:
> 
> > Am I out of luck here? If I need to implement anything in Dom0 to do
it
> > then I''ll just document the Windows Xen PV drivers as being
compatible
> > only with 3.1.1 and above if you want to mix and match bit widths...
but
> > it would be nice to support older code.
> 
> Requiring 3.1.1+ is probably not unreasonable.
> 
Maybe unless you are running Debian... Debian ''testing'' has
3.1.1
hypervisor and tools, but the kernels are built against something a bit
older, as they have no protocol detection capability.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> So another possible solution I have for determining what is going on
is:
> 
> 1. Write a request (op = 0xff, id = 0) to the ring, and fill all the
> seg[] entries with 0xff too.
> 2. Wait for the response from Dom0, confirm that we get a failure
(I''m
> assuming that Dom0 will just return ''BLKIF_RSP_ERROR''
here)
> 3. Write another request (op = 0xff, id = 0xffffffffffffffff to the
> ring)
> 4. Wait for the response from Dom0, if we get the same response as
> before then we are done and can continue as normal.
> 5. If we didn''t get the same response, then switch bit widths (32
->
64,
> or 64 -> 32), then continue as normal.
> 
> Sounds like it might work in theory, as long as Dom0 doesn''t have
a
huge
> panic attack when it gets op=0xff, or a completely misaligned request
> (the id = 0xffffffffffffffff and seg[..] = 0xff is so that if we have
> our alignments wrong, the backend still see''s a request of 0xff
and
not
> a bizarre read operation).
> 
I have implemented this and it works just fine. xenvbd writes two
invalid (op = 0xff) requests on loading, before letting windows send any
requests. If the second request doesn''t come through with op == 0xff
then I switch ring structures (eg if we are a 32 bit domU then switch to
64 bit structures).

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel