ATA/ATAPI6 device emulation in bhyve

[iateaca]

Summary

This patch implements the ATA/ATAPI6 device emulation in bhyve.
The userspace bhyve tree sources must be patched. For example:

patch -d bhyve/ < bhyve_ata_atapi6.patch

[mav]

It was definitely significant amount of work, but I am not sure what motivation was behind it. Why do we need it after already having much more featured AHCI-based ATA/ATAPI emulation? Are there any significant OS not supporting AHCI? There is significant amount of code duplication between implementations, plus this one obviously requires more work to be complete.

[iateaca]

In D5473#117324, @mav wrote:

It was definitely significant amount of work, but I am not sure what motivation was behind it. Why do we need it after already having much more featured AHCI-based ATA/ATAPI emulation? Are there any significant OS not supporting AHCI? There is significant amount of code duplication between implementations, plus this one obviously requires more work to be complete.

The motivation is to run older versions of operating systems such as FreeBSD 4 which does not have AHCI drivers.
What do you mean by code duplication ? I think only the ATAPI CDROM logic could be common but the current implementation from AHCI can not be used with the ATA data strcutures. If we want to achive this, I think a redesign of AHCI ATAPI is required too.

[mav]

In D5473#117346, @iateaca wrote:

The motivation is to run older versions of operating systems such as FreeBSD 4 which does not have AHCI drivers.
What do you mean by code duplication ? I think only the ATAPI CDROM logic could be common but the current implementation from AHCI can not be used with the ATA data strcutures. If we want to achive this, I think a redesign of AHCI ATAPI is required too.

I personally see quite little sense in supporting so old legacy guests. I agree that there can be "some cases", but I am not sure they worth the time spent and code size growth. Other then legacy guests support this code does not give us anything useful -- legacy ATA will be by definition much slower and less functional then its AHCI counterpart. It will require dozens of emulated register accesses per I/O, comparing to only several for AHCI, and won't support command queuing.

Though obviously nice and clean unified implementation would look better. In your patch you are one more time reimplementing some subsets of ATA and ATAPI commands handling, already done much wider for AHCI. It would be much better to have single device emulation code, interfacing with different controller code parts. But it would also take much more time (you are rigth that it would require existing code redesign), for the same little reason, so I am not sure how good is that idea. It needs investigation.

[iateaca]

In D5473#117352, @mav wrote:

In D5473#117346, @iateaca wrote:

The motivation is to run older versions of operating systems such as FreeBSD 4 which does not have AHCI drivers.
What do you mean by code duplication ? I think only the ATAPI CDROM logic could be common but the current implementation from AHCI can not be used with the ATA data strcutures. If we want to achive this, I think a redesign of AHCI ATAPI is required too.

I personally see quite little sense in supporting so old legacy guests. I agree that there can be "some cases", but I am not sure they worth the time spent and code size growth. Other then legacy guests support this code does not give us anything useful -- legacy ATA will be by definition much slower and less functional then its AHCI counterpart. It will require dozens of emulated register accesses per I/O, comparing to only several for AHCI, and won't support command queuing.

Though obviously nice and clean unified implementation would look better. In your patch you are one more time reimplementing some subsets of ATA and ATAPI commands handling, already done much wider for AHCI. It would be much better to have single device emulation code, interfacing with different controller code parts. But it would also take much more time (you are rigth that it would require existing code redesign), for the same little reason, so I am not sure how good is that idea. It needs investigation.

Totally agree with you, there are no many reasons to use ATA instead of AHCI when you have support for it. Though I think there is a good reason having the ATA/ATAPI emulation in bhyve since Peter came with this idea.

[grehan]

Support for legacy o/s's has driven much of bhyve development. I'm all for this, though I agree there should be some consolidation of code that could be shared between ATA/ATAPI and AHCI.

[iateaca]

In D5473#117481, @grehan wrote:

Support for legacy o/s's has driven much of bhyve development. I'm all for this, though I agree there should be some consolidation of code that could be shared between ATA/ATAPI and AHCI.

Do you propose to postpone the review until we combine somehow the ATA/ATAPI and AHCI ?

[editor_callfortesting.org]

Support for FreeBSD 6 and older, even if for historical/academic purposes, is a topic that keeps coming up. Legacy systems come in all shapes and sizes and I can think of at least one point-of-sale vendor that spans generations of FreeBSD and other Unix systems.

Is this code in a usable state?

I think making it easy for the various interested parties to use it would better drive its direction.

FYI: You can also use my account 'dexter' on this system.

[iateaca]

In D5473#151356, @editor_callfortesting.org wrote:

Support for FreeBSD 6 and older, even if for historical/academic purposes, is a topic that keeps coming up. Legacy systems come in all shapes and sizes and I can think of at least one point-of-sale vendor that spans generations of FreeBSD and other Unix systems.

Is this code in a usable state?

I think making it easy for the various interested parties to use it would better drive its direction.

FYI: You can also use my account 'dexter' on this system.

Yes, this code is in a usable state. I have tested both the ata-hd and atapi features with the ATA Legacy FreeBSD guest driver. It might be a good idea to test it with other guest though, an older Linux distribution maybe. I will test it after I finish with the GSOC project.

[editor_callfortesting.org]

iateaca,

Several people would like to see this through. Please add a copyright and license to the work.

Thanks!

dexter

[iateaca]

add Copyright and license

[iateaca]

remove sectors_per_block field from the ata channel
allow seccount to be set smaller than ATA_SECTORS_PER_BLOCK

[editor_callfortesting.org]

In my testing, this appears to be based on FreeBSD 10.1, which is well supported by AHCI emulation. Supporting back to 5.0 or earlier would make this much more useful.