win-pvdrivers

changeset 181:762547e8a0db

add James' description of what's going on in HwScsiInterruptTarget
author Andy Grover <andy.grover@oracle.com>
date Mon Feb 11 15:54:10 2008 -0800 (2008-02-11)
parents a4744cb1e51a
children 1034a8ecd391
files xenvbd/xenvbd.c
line diff
     1.1 --- a/xenvbd/xenvbd.c	Mon Feb 11 13:48:53 2008 -0800
     1.2 +++ b/xenvbd/xenvbd.c	Mon Feb 11 15:54:10 2008 -0800
     1.3 @@ -154,8 +154,22 @@ XenVbd_HwScsiInterruptTarget(PVOID Devic
     1.4      {
     1.5        rep = XenVbd_GetResponse(TargetData, i);
     1.6  
     1.7 -//KdPrint((__DRIVER_NAME "     rep = %p\n", rep));
     1.8 -//KdPrint((__DRIVER_NAME "     rep->id = %d\n", rep->id));
     1.9 +      //KdPrint((__DRIVER_NAME "     rep = %p\n", rep));
    1.10 +      //KdPrint((__DRIVER_NAME "     rep->id = %d\n", rep->id));
    1.11 +
    1.12 +      /*
    1.13 +       * This code is to automatically detect if the backend is using the same
    1.14 +       * bit width or a different bit width to us. Later versions of Xen do this
    1.15 +       * via a xenstore value, but not all. That 0x0fffffff (notice
    1.16 +       * that the msb is not actually set, so we don't have any problems with
    1.17 +       * sign extending) is to signify the last entry on the right, which is
    1.18 +       * different under 32 and 64 bits, and that is why we set it up there.
    1.19 +
    1.20 +       * To do the detection, we put two initial entries on the ring, with an op
    1.21 +       * of 0xff (which is invalid). The first entry is mostly okay, but the
    1.22 +       * second will be grossly misaligned if the backend bit width is different,
    1.23 +       * and we detect this and switch frontend structures.
    1.24 +       */
    1.25        switch (TargetData->ring_detect_state)
    1.26        {
    1.27        case 0: