Hi folks, On Tue, Jun 02, 2015 at 11:46:43PM +0200, Manuel Bouyer wrote: > > > Yes, it looks like the IDE emulation in qemu is not working as it should > > > with LBA48 ... > > As per suggestion on chat, i changed back to xentools41 and had to revert back > > to xenkernel41 too. It feels more responsive but it still has the same mapping > > issue, so far no luck. What strikes me is that it is near bit 28, a kind of > > odd number unless the top 4 bits mean something else to code somewhere in the > > whole chain. > > Yes, that's the IDE interface. The initial interface ony allowed 28 bits > sectors addressing (the the 8bits sector register, the 16bits cylinder > register and the 4bits head regiter - the other 4 bits are used for something > else). Later the spec reused these registers for 28bit sector adressing. > When drives larger than 128GB did show up, the spec was updated again by > duplicating the LBA registers - writing the complete values requires 2 > registers writes (the first set of writes writes the high 24 bits, > the second the low 24 bits). > > I suspect that qemu-dm doesn't properly emulate this two-step write, > and the second set of writes just erases the previous write, effectively > truncating the sector address to the low 24 bits > (it works up to 128GB - 2^28 sectors - because the driver will use LBA > and not LBA48 when possible). Fixing this will require a patch to qemu-dm. > Maybe this has already been fixed in newer qemu versions ... It sure isn't fixed in xenkernel45/xentools45 as it shows the same issue.... Why is it using the `traditional' qemu btw? This has the ide.c that isn't in the newer qemu since those have an ide directory! Reinoud
Attachment:
pgpTttdos_dIR.pgp
Description: PGP signature