RE: [Xen-devel] determining dom0 version and bit size from domU

["James Harper" <james.harper@xxxxxxxxxxxxxxxx>]

> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel