|
From: | Zhang, Eniac |
Subject: | [Qemu-devel] problem using AHCI on xen fvm |
Date: | Thu, 19 Jun 2014 15:01:11 +0000 |
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 |
[Prev in Thread] | Current Thread | [Next in Thread] |