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

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

  • To: "xen-devel" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
  • Date: Sat, 2 Feb 2008 22:58:48 +1100
  • Delivery-date: Sat, 02 Feb 2008 03:59:28 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AchlRQYpcQr7K5pVTZi8TpkCkQ4v3gABM8XQABIxXTA=
  • Thread-topic: [Xen-devel] determining dom0 version and bit size from domU

> So another possible solution I have for determining what is going on
> 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 ->
> or 64 -> 32), then continue as normal.
> Sounds like it might work in theory, as long as Dom0 doesn't have a
> 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
> 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).


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.