Re: Switch from legacy ata(4) to CAM-based ATA

Sergey Kandaurov wrote:
> XENHVM uses it's own naming scheme and can name disks as daN or adN,
> depending on virtual block device id. atapci0/ata0/ata1 devices still present
> there (such as in Bruce Cran's dmesg), but no any disks attached from it:
> instead, all of them hung from device/vbd/N.
> [In a non-XENHVM mode they are attached from ataN channels, as usual.]
> 
> /*
>  * Translate Linux major/minor to an appropriate name and unit
>  * number. For HVM guests, this allows us to use the same drive names
>  * with blkfront as the emulated drives, easing transition slightly.
>  */
> 
> xenbusb_front0: <Xen Frontend Devices> on xenstore0
> xenbusb_back0: <Xen Backend Devices> on xenstore0
> xctrl0: <Xen Control Device> on xenstore0
> xbd0: 17000MB <Virtual Block Device> at device/vbd/768 on xenbusb_front0
> xbd0: attaching as ad0
> GEOM: ad0s1: geometry does not match label (16h,63s != 255h,63s).
> xbd1: 3812MB <Virtual Block Device> at device/vbd/2048 on xenbusb_front0
> xbd1: attaching as da0
> xbd2: 114439MB <Virtual Block Device> at device/vbd/2064 on xenbusb_front0
> xbd2: attaching as da1

OK, interesting question. I have built amd64 XENHVM kernel and booted it
under Xen 3.2. As result I've got double set of devices, via both
atapci0/ata0 and via blkfront:

ada0 at ata0 bus 0 scbus0 target 0 lun 0
ada0: <QEMU HARDDISK 0.9.0> ATA-7 device
ada0: Serial Number QM00001
ada0: 16.700MB/s transfers (WDMA2, PIO 8192bytes)
ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C)
ada0: Previously was known as ad0
ada1 at ata0 bus 0 scbus0 target 1 lun 0
ada1: <QEMU HARDDISK 0.9.0> ATA-7 device
ada1: Serial Number QM00002
ada1: 16.700MB/s transfers (WDMA2, PIO 8192bytes)
ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C)
ada1: Previously was known as ad1
xbd0: 476940MB <Virtual Block Device> at device/vbd/768 on xenbusb_front0
xbd0: attaching as ad0
xbd1: 476940MB <Virtual Block Device> at device/vbd/832 on xenbusb_front0
xbd1: attaching as ad1
Both of them were exported to GEOM. Extra set of adX devices caused
error messages. What am I doing wrong and why have I got those
duplicates? Was I required to remove non-PV drivers from my kernel?

> Probably, /sys/dev/xen/blkfront/blkfront.c needs updating by s/"ad"/"ada"/g;
> or such. I believe, xen generates sequential numbers starting from zero
> (or rather such numbers that can be converted to sequential numbers),
> similar to what ATA_CAM does.

According to what I see, blkfront follows ATA_STATIC_ID behavior: if I
configure Xen with single slave device (hdb), blkfront reports it as ad1.

-- 
Alexander Motin