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
