You might be right, though at present it seems like it doesn't hurt anything that I am aware of to claim that our mapping is 1:1 in such cases.
Patches welcome; especially if there is any proof that this has caused any problems anywhere. --js -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1896342 Title: IDE ATA IDENTIFY WORD 106 Status in QEMU: New Bug description: The code at line 202 in hw/ide/core.c (https://git.qemu.org/?p=qemu.git;a=blob;f=hw/ide/core.c;#l201) hard codes bit 13 set. However, get_physical_block_exp() can and may return 0, which is a valid response. If get_physical_block_exp() does return zero, bit 13 should not be set. ATAPI8 states (Section 7.17.7.73): "Bit 13 of word 106 shall be set to one to indicate that the device has more than one logical sector per physical sector" and gives the examples: Bits (3:0): 0 = 2^0 = 1 logical sector per physical sector Bits (3:0): 1 = 2^1 = 2 logical sector per physical sector Bits (3:0): 2 = 2^2 = 4 logical sector per physical sector Bits (3:0): 3 = 2^3 = 8 logical sector per physical sector Therefore, if bit 13 is set, bits 3:0 must be greater than zero. If get_physical_block_exp() returns zero then there is a 1:1 ratio and bit 13 must be 0. Just my opinion. Thanks, Ben To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1896342/+subscriptions
