[Qemu-devel] problem using AHCI on xen fvm

[Zhang, Eniac]

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

 

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?

 

Regards/Eniac