Re: [Qemu-devel] problem using AHCI on xen fvm

[Stefano Stabellini]

On Thu, 19 Jun 2014, Zhang, Eniac wrote:
> Hi,
> 
> I am trying to use AHCI controllers with xen.  The main reason for that is 
> because windows is so picky about which type of
> controller it can boot on, and if you don’t have the right registry settings, 
> you get Error 7B
> (http://support.microsoft.com/kb/324103)
> 
> So here’s my attempt (in "hw/i386/pc_piix.c"):
> 
>     ide_drive_get(hd, MAX_IDE_BUS);
> 
>     if (pci_enabled) {
> 
>         PCIDevice *dev;
> 
> #if 1 // Eniac
> 
>         dev = pci_create_simple_multifunction(pci_bus,
> 
>             piix3_devfn + 1, true, "ich9-ahci");
> 
> #else // original code
> 
>         if (xen_enabled()) {
> 
>             dev = pci_piix3_xen_ide_init(pci_bus, hd, piix3_devfn + 1);
> 
>         } else {
> 
>             dev = pci_piix3_ide_init(pci_bus, hd, piix3_devfn + 1);
> 
>         }
> 
> #endif // Eniac
> 
>         idebus[0] = qdev_get_child_bus(&dev->qdev, "ide.0");
> 
>         idebus[1] = qdev_get_child_bus(&dev->qdev, "ide.1");
> 
>     } else {
> 
>         for(i = 0; i < MAX_IDE_BUS; i++) {
> 
>             ISADevice *dev;
> 
>             dev = isa_ide_init(isa_bus, ide_iobase[i], ide_iobase2[i],
> 
>                                ide_irq[i],
> 
>                                hd[MAX_IDE_DEVS * i], hd[MAX_IDE_DEVS * i + 
> 1]);
> 
>             idebus[i] = qdev_get_child_bus(DEVICE(dev), "ide.0");
> 
>         }
> 
> }
> 
>  
> 
> And the config file to start xen fvm:
> 
> name = 'personal'
> 
> builder = 'hvm'
> 
> device_model_version = 'qemu-xen'
> 
> device_model_override = '/vm/qemu161test/qemu-161-vanilla'
> 
>  
> 
> vcpus = 4
> 
> memory = 2848
> 
> maxmem = 2848
> 
>  
> 
> usb = 1
> 
> usbdevice = 'tablet'
> 
> vnc = 1
> 
> vnclisten = '0.0.0.0:0'
> 
> serial='pty'
> 
>  
> 
> boot = "d"
> 
> device_model_args = [ "-drive", "if=none,file=/dev/sda,id=hd", "-device", 
> "ide-hd,drive=hd,bus=ide.0", "-drive",
> "if=none,file=/vm/qemu161test/output.iso,id=cd", "-device", 
> "ide-cd,drive=cd,bus=ide.1" ]
> 
>  
> 
> It works… but not flawlessly.  The grub can load the Ubuntu menu, kernel and 
> initrd but then crash when it’s trying to mount the
> rootfs.  In other words, bios int13h can read the disk fine but Linux kernel 
> driver can’t.  I’ve seen similar corruption
> happening on Windows boot as well.  After several days of triage, I realized 
> that it might have to do with async read.  I found
> a defect report on this and applied that
> (https://code.grnet.gr/projects/qemu/repository/revisions/8464b273d69c61e33c55347e5b6bc0659687bae2)
>  but the problem persists. 
> Here’s the command I used to demonstrate the corruption:
> 
> bash-4.2# for k in `seq 20`; do dd if=/dev/sr0 bs=51200 count=10 2>/dev/null 
> |>
> 
> 2393220578 512000
> 
> 2393220578 512000
> 
> 1498197434 512000
> 
> 2393220578 512000
> 
> 2393220578 512000
> 
> 2393220578 512000
> 
> 2393220578 512000
> 
> 2393220578 512000
> 
> 2393220578 512000
> 
> 2393220578 512000
> 
> 2393220578 512000
> 
> 2393220578 512000
> 
> 2393220578 512000
> 
> 2393220578 512000
> 
> 2393220578 512000
> 
> 1652232720 512000
> 
> 2393220578 512000
> 
> 2393220578 512000
> 
> 2393220578 512000
> 
> 2393220578 512000
> 
>  
> 
> One may need to run it several times to see the corruption.  It looks like a 
> random racing condition.
> 
>  
> 
> I then tried several test with vanilla qemu:
> 
> # non-xen test
> 
> Qemu-1.6.1-vanilla with q35 chipset: no corruption
> 
> Qemu-1.6.1-vanilla with 440fx chipset: no corruption
> 
> Qemu-1.6.1 with AHCI patch and 440fx chipset: no corruption
> 
>  
> 
> # test with vanilla-xen
> 
> Qemu-1.6.1-vanilla with 440fx chipset: no corruption
> 
> Qemu-1.6.1 with AHCI patch and 440fx chipset: corruption

Can you try with a more recent QEMU version? Maybe QEMU 2.0?


> So the problem lies between the interaction between AHCI controller and xen.  
> Has anyone else tried this and/or can take a look
> to see what’s happening here?

In these cases it is usually a mapcache (see xen-mapcache.c) problem.
Not a bug in the mapcache per se, but maybe it is not called correctly
from common code. To give you an idea of a possible bad interaction
between the mapcache and common code, see:

commit a41087bc7110e8378cd49ddd06aa7c9d361f3673
Author: Stefano Stabellini <address@hidden>
Date:   Thu Jan 30 12:46:05 2014 +0000

    address_space_translate: do not cross page boundaries