Re: HVM disc corruption (was Re: Xen won't start its device backend?)

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Tue, Jun 02, 2015 at 11:03:31PM +0200, Reinoud Zandijk wrote:
> Hi
> 
> On Tue, Jun 02, 2015 at 08:55:38PM +0200, Manuel Bouyer wrote:
> > On Tue, Jun 02, 2015 at 08:50:17PM +0200, Reinoud Zandijk wrote:
> > > The error only starts to show between block 250.000.000 (27.89 bits) and block
> > > 300.000.000 (28.16 bits). And indeed, block 268.435.456 (2^28) maps to sector
> > > 0 but block 268.435.455 is wrong already.
> > > 
> > > Looking at the dmesg, am I right that the piixide in compatibility mode is
> > > thus resulting in this error since the hvm wd0 uses LBA48 addressing.
> > 
> > Yes, it looks like the IDE emulation in qemu is not working as it should
> > with LBA48
> 
> wd0 reports it supports LBA48 still but i don't see a line claiming its using.
> It only reports PIO mode 4, DMA mode 2.

I don't think it will be printed when in use:
wd0 at atabus1 drive 0
wd0: <ST1000DL002-9TT153>
wd0: drive supports 16-sector PIO transfers, LBA48 addressing
wd0: 931 GB, 1938021 cyl, 16 head, 63 sec, 512 bytes/sect x 1953525168 sectors
wd0: 32-bit data port
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
wd0(piixide1:0:0): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133) (using DMA)

but it's of course using LBA48, otherwise I would not be abe to use
the whole drive.


> 
> > > As a side notice, the network in hvm is VERY slow most likely due to the
> > > number of watchdog timeouts i get from re0. Dumping got into the 4kb/sec ;)
> > > 
> > > I used
> > >   vif = [ 'mac=90:e6:ba:6c:6f:d2,bridge=bridge0' ]
> > 
> > You could try to add 'type=ioemu, model=e1000' to the entry above.
> > I found that the e1000 emulation (wm(4) under NetBSD) gives much better
> > performances.
> 
> Quite so! The network speed is now upto par again! thanks for the tip.
> 
> 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 ...

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--