[Qemu-devel] [Bug 618533] [NEW] OpenSolaris guest fails to see the Solaris partitions of a physical disk in qemu-kvm-9999 (GIT)
Public bug reported: # qemu-kvm --version QEMU emulator version 0.13.50 (qemu-kvm-devel), Copyright (c) 2003-2008 Fabrice Bellard The following disk is presented to guest as IDE disk with /dev/sdd as path. # fdisk -l /dev/sdd Disk /dev/sdd: 750.2 GB, 750156374016 bytes 255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x7f3a03aa Device Boot Start End Blocks Id System /dev/sdd1 63 7887914 3943926 1b Hidden W95 FAT32 /dev/sdd2 7887915 980736119 486424102+ 83 Linux /dev/sdd3 * 980736120 108315049451207187+ bf Solaris /dev/sdd4 1083150495 1465144064 1909967855 Extended /dev/sdd5 1083150558 110774600912297726 83 Linux /dev/sdd6 1107746073 1465144064 1786989967 HPFS/NTFS The prtvtoc output is attached from both VirtualBox and Qemu-KVM. As can be seen in the screenshots, a valid Solaris partition table (which is inside the /dev/sdd3, marked 'bf' in Linux fdisk output) is not seen in Qemu but seen in Virtualbox. This makes the guest unbootable in Qemu because the root FS is not found but its bootable in Virtualbox. ** Affects: qemu Importance: Undecided Status: New -- OpenSolaris guest fails to see the Solaris partitions of a physical disk in qemu-kvm- (GIT) https://bugs.launchpad.net/bugs/618533 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: # qemu-kvm --version QEMU emulator version 0.13.50 (qemu-kvm-devel), Copyright (c) 2003-2008 Fabrice Bellard The following disk is presented to guest as IDE disk with /dev/sdd as path. # fdisk -l /dev/sdd Disk /dev/sdd: 750.2 GB, 750156374016 bytes 255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x7f3a03aa Device Boot Start End Blocks Id System /dev/sdd1 63 7887914 3943926 1b Hidden W95 FAT32 /dev/sdd2 7887915 980736119 486424102+ 83 Linux /dev/sdd3 * 980736120 108315049451207187+ bf Solaris /dev/sdd4 1083150495 1465144064 1909967855 Extended /dev/sdd5 1083150558 110774600912297726 83 Linux /dev/sdd6 1107746073 1465144064 1786989967 HPFS/NTFS The prtvtoc output is attached from both VirtualBox and Qemu-KVM. As can be seen in the screenshots, a valid Solaris partition table (which is inside the /dev/sdd3, marked 'bf' in Linux fdisk output) is not seen in Qemu but seen in Virtualbox. This makes the guest unbootable in Qemu because the root FS is not found but its bootable in Virtualbox.
[Qemu-devel] [Bug 618533] Re: OpenSolaris guest fails to see the Solaris partitions of a physical disk in qemu-kvm-9999 (GIT)
** Attachment added: qemu's version on Solaris partition table https://bugs.launchpad.net/bugs/618533/+attachment/1492913/+files/opensolaris-qemu.png -- OpenSolaris guest fails to see the Solaris partitions of a physical disk in qemu-kvm- (GIT) https://bugs.launchpad.net/bugs/618533 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: # qemu-kvm --version QEMU emulator version 0.13.50 (qemu-kvm-devel), Copyright (c) 2003-2008 Fabrice Bellard The following disk is presented to guest as IDE disk with /dev/sdd as path. # fdisk -l /dev/sdd Disk /dev/sdd: 750.2 GB, 750156374016 bytes 255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x7f3a03aa Device Boot Start End Blocks Id System /dev/sdd1 63 7887914 3943926 1b Hidden W95 FAT32 /dev/sdd2 7887915 980736119 486424102+ 83 Linux /dev/sdd3 * 980736120 108315049451207187+ bf Solaris /dev/sdd4 1083150495 1465144064 1909967855 Extended /dev/sdd5 1083150558 110774600912297726 83 Linux /dev/sdd6 1107746073 1465144064 1786989967 HPFS/NTFS The prtvtoc output is attached from both VirtualBox and Qemu-KVM. As can be seen in the screenshots, a valid Solaris partition table (which is inside the /dev/sdd3, marked 'bf' in Linux fdisk output) is not seen in Qemu but seen in Virtualbox. This makes the guest unbootable in Qemu because the root FS is not found but its bootable in Virtualbox.
[Qemu-devel] [Bug 618533] Re: OpenSolaris guest fails to see the Solaris partitions of a physical disk in qemu-kvm-9999 (GIT)
** Attachment added: VirtualBox's version of Solaris partition table. https://bugs.launchpad.net/qemu/+bug/618533/+attachment/1492914/+files/opensolaris-vbox.png -- OpenSolaris guest fails to see the Solaris partitions of a physical disk in qemu-kvm- (GIT) https://bugs.launchpad.net/bugs/618533 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: # qemu-kvm --version QEMU emulator version 0.13.50 (qemu-kvm-devel), Copyright (c) 2003-2008 Fabrice Bellard The following disk is presented to guest as IDE disk with /dev/sdd as path. # fdisk -l /dev/sdd Disk /dev/sdd: 750.2 GB, 750156374016 bytes 255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x7f3a03aa Device Boot Start End Blocks Id System /dev/sdd1 63 7887914 3943926 1b Hidden W95 FAT32 /dev/sdd2 7887915 980736119 486424102+ 83 Linux /dev/sdd3 * 980736120 108315049451207187+ bf Solaris /dev/sdd4 1083150495 1465144064 1909967855 Extended /dev/sdd5 1083150558 110774600912297726 83 Linux /dev/sdd6 1107746073 1465144064 1786989967 HPFS/NTFS The prtvtoc output is attached from both VirtualBox and Qemu-KVM. As can be seen in the screenshots, a valid Solaris partition table (which is inside the /dev/sdd3, marked 'bf' in Linux fdisk output) is not seen in Qemu but seen in Virtualbox. This makes the guest unbootable in Qemu because the root FS is not found but its bootable in Virtualbox.
[Qemu-devel] [Bug 618533] Re: OpenSolaris guest fails to see the Solaris partitions of a physical disk in qemu-kvm-9999 (GIT)
Qemu's version of partition table is gotten using a OpenSolaris b134 livecd because I couldn't really boot the disk. Basically, somehow all the slice labels are missing when booted in Qemu. OpenSolaris thinks that /dev/sdd3 (which is a primary Solaris 'bf' type partition) is not sliced. Hence, its showing 2 unmountable slices and 1 reserved slice. When booted in VirtualBox, the correct slice table is seen. We can see slice 0 being 'root' slice of about 16GB, slice 1 being 'swap' slice of size about 6GB and slice 6 being the 'data' slice of about 26GB. -- OpenSolaris guest fails to see the Solaris partitions of a physical disk in qemu-kvm- (GIT) https://bugs.launchpad.net/bugs/618533 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: # qemu-kvm --version QEMU emulator version 0.13.50 (qemu-kvm-devel), Copyright (c) 2003-2008 Fabrice Bellard The following disk is presented to guest as IDE disk with /dev/sdd as path. # fdisk -l /dev/sdd Disk /dev/sdd: 750.2 GB, 750156374016 bytes 255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x7f3a03aa Device Boot Start End Blocks Id System /dev/sdd1 63 7887914 3943926 1b Hidden W95 FAT32 /dev/sdd2 7887915 980736119 486424102+ 83 Linux /dev/sdd3 * 980736120 108315049451207187+ bf Solaris /dev/sdd4 1083150495 1465144064 1909967855 Extended /dev/sdd5 1083150558 110774600912297726 83 Linux /dev/sdd6 1107746073 1465144064 1786989967 HPFS/NTFS The prtvtoc output is attached from both VirtualBox and Qemu-KVM. As can be seen in the screenshots, a valid Solaris partition table (which is inside the /dev/sdd3, marked 'bf' in Linux fdisk output) is not seen in Qemu but seen in Virtualbox. This makes the guest unbootable in Qemu because the root FS is not found but its bootable in Virtualbox.
[Qemu-devel] [Bug 618533] Re: OpenSolaris guest fails to see the Solaris partitions of a physical disk in qemu-kvm-9999 (GIT)
This is a showstopper bug for me to adopt KVM as the virtualization solution because I just can't boot my OpenSolaris guest. I want to move to KVM because of in-kernel support and better SMP support. -- OpenSolaris guest fails to see the Solaris partitions of a physical disk in qemu-kvm- (GIT) https://bugs.launchpad.net/bugs/618533 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: # qemu-kvm --version QEMU emulator version 0.13.50 (qemu-kvm-devel), Copyright (c) 2003-2008 Fabrice Bellard The following disk is presented to guest as IDE disk with /dev/sdd as path. # fdisk -l /dev/sdd Disk /dev/sdd: 750.2 GB, 750156374016 bytes 255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x7f3a03aa Device Boot Start End Blocks Id System /dev/sdd1 63 7887914 3943926 1b Hidden W95 FAT32 /dev/sdd2 7887915 980736119 486424102+ 83 Linux /dev/sdd3 * 980736120 108315049451207187+ bf Solaris /dev/sdd4 1083150495 1465144064 1909967855 Extended /dev/sdd5 1083150558 110774600912297726 83 Linux /dev/sdd6 1107746073 1465144064 1786989967 HPFS/NTFS The prtvtoc output is attached from both VirtualBox and Qemu-KVM. As can be seen in the screenshots, a valid Solaris partition table (which is inside the /dev/sdd3, marked 'bf' in Linux fdisk output) is not seen in Qemu but seen in Virtualbox. This makes the guest unbootable in Qemu because the root FS is not found but its bootable in Virtualbox.
[Qemu-devel] USB-Mass-Storage and OpenBSD 4.7 problem
Hello list, I am trying to write to an usb image file using OpenBSD 4.7 as guest and a fresh QEMU emulator version 0.12.90. While trying to access the device I got the following error messages: snip~~~ umass0 at uhub0 port 1 configuration 1 interface 0 QEMU 0.12.90 QEMU USB HARDDRIVE rev 1.00/0.00 addr 2 umass0: using SCSI over Bulk-Only scsibus2 at umass0: 2 targets, initiator 0 sd0 at scsibus2 targ 1 lun 0: QEMU, QEMU HARDDISK, 0.12 SCSI3 0/direct fixed sd0: 1024MB, 512 bytes/sec, 2097152 sec total umass0: Invalid CSW: sig 0x should be 0x53425355 umass0: Invalid CSW: sig 0x should be 0x53425355 # newfs /dev/rsd0a /dev/rsd0a: 1024.0MB in 2097088 sectors of 512 bytes 6 cylinder groups of 202.47MB, 12958 blocks, 25984 inodes each super-block backups (for fsck -b #) at: umass0: Invalid CSW: sig 0x should be 0x53425355 newfs: wtfs: write error on block 192: Input/output error # disklabel sd0 # /dev/rsd0c: type: SCSI disk: SCSI disk label: QEMU HARDDISK flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 130 total sectors: 2097152 rpm: 3600 interleave: 1 boundstart: 0 boundend: 2097152 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a: 2097089 63 4.2BSD 2048 163841 c: 20971520 unused # ~~~snip Using some hardware USB-Stick (plugged into the host and forward it to the guest) works fine. Anyone have a clue about it? Please cc me in your replies because I am not subscribed to the list. Cheers, Sebastian
[Qemu-devel] Re: Unmaintained QEMU builds
On 08/15/2010 11:42 PM, Anthony Liguori wrote: Given that it's known to have a lot of issues, I would suggest that we schedule Windows host support for deprecation in 0.15. I would not recommend that we remove any of the WIN32 code from the build but basically stop trying to make it even build until someone steps up to really actively maintain and enhance the Windows port. I would still suggest we take patches if anyone wants to submit them but we should not avoid patches that are known to break win32 (unless the fix is trivial). I was planning to submit a qemu-thread port for Win32 for 0.14, which of course means doing some basic sanity testing of the port. However, I'm not in any way trying to support anything more complicated than raw images and SDL/VNC. In particular, I'm not going to test networking. Paolo
[Qemu-devel] Re: [qemu-kvm] build fail on i386 RHEL5u4
On 08/16/2010 04:27 AM, Hao, Xudong wrote: Appears to be a gcc bug. I opened https://bugzilla.redhat.com/show_bug.cgi?id=624279 to track this. Meanwhile, installing the gcc44 package and building with it (./configure --cc=gcc44) appears to work. Avi, Gcc44 works for me. I saw Jakub marked this bug closed with only i486 support that, but RHEL5 use -march=i386, so do we have ongoing fix on qemu-kvm? Should be easy to add a ./configure test for this. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
[Qemu-devel] Re: [PATCH 15/15] xen: Add a Xen specific ACPI Implementation to target-xen
On Fri, 13 Aug 2010, Anthony Liguori wrote: On 08/13/2010 02:37 PM, Stefano Stabellini wrote: On Fri, 13 Aug 2010, Anthony Liguori wrote: On 08/12/2010 09:10 AM, stefano.stabell...@eu.citrix.com wrote: From: Anthony PERARDanthony.per...@citrix.com Xen currently uses a different BIOS (hvmloader + rombios) therefore the Qemu acpi_piix4 implementation wouldn't work correctly with Xen. We plan on fixing this properly but at the moment we are just adding a new Xen specific acpi_piix4 implementation. This patch is optional; without it the VM boots but it cannot shutdown properly or go to S3. What's the long term plan? Will Xen adopt SeaBIOS or will you adapt your BIOS to cope with our ACPI implementation? I think it shouldn't be too difficult to adapt our current BIOS, but we'll need few xen specific hooks in acpi_piix4. The price that we'll have to pay doing so is loosing live-migration compatibility with older xen installations. Does Xen migrate roms (like the BIOS) in such a way that the persist after a reboot? No, I don't think so. However it is common practice not to require any VM reboot on host upgrade. I noticed there was only one machine type defined. In our experience, to preserve compatibility with migration, it's useful to have versioned machine names. We also have some special machine parameters to support compatibility with qdev. Thanks for the tip, we'll look into it. Knowing that we would have the BIOS problem mentioned above, we didn't try yet any save/restore or migration compatibility between old qemu-xen and new qemu. How does Xen handle hvm migration machine model compatibility? We use per-device save state versions and we tend to use always the same set of devices.
[Qemu-devel] Re: [PATCH 08/15] xen: Read and write the state of the VM in xenstore
On Sun, 15 Aug 2010, Paolo Bonzini wrote: On 08/13/2010 02:53 PM, Anthony Liguori wrote: On 08/12/2010 09:09 AM, stefano.stabell...@eu.citrix.com wrote: From: Anthony PERARDanthony.per...@citrix.com Introduce functions to read and write the state of the VM in xenstore. This basically creates a new management interface for QEMU via the xenstore. Our management interface is QMP. If you want to maintain compatibility, you'll need to write a QMP - xenstore daemon that maps events appropriately. This would belong in xl/libxl. Yes, but considering that we don't want a xenstore-based management interface I would gladly do without the compatibility daemon. We'll try to reduce all the xenstore interaction to the bare minimum, and use QMP everywhere else.
[Qemu-devel] [Bug 521994] Re: Windows 98 doesn't detect mouse on qemu and SeaBIOS.
Looks to be fixed by commit 14ac15d3ac8e0ef1c91204e2ac772b6412a6b99e Author: Anthony Liguori aligu...@us.ibm.com Date: Tue May 11 07:56:30 2010 -0500 Update SeaBIOS - 7d09d0e Fix virtio compile errors on various gcc versions. - 89acfa3 Support for booting from virtio disks - 6d66316 smbios: avoid counting io hole as ram - e5cd945 Fix error causing USB HID boot protocol to not be enabled. - 0e88576 Add support for USB mice. - dd5a8a6 When USB keyboard active, don't send keyboard commands to ps2 port. - 5718d56 Document usb-hid.c functions. - e438b0c Further parallelize init when using CONFIG_THREAD_OPTIONROMS. - f59b5ac Handle unknown function addresses in tools/checkstack.py. - 9ba1dea Simplify build by manually resolving external symbols in layoutrom.py. - 698d3f9 USB EHCI should yield() whil waiting for controller to ack reset. - f9a774c Add __attribute__((__malloc__)) declaration to internal malloc funcs. - b7045ce Minor - remove redundant check from ata_try_dma. - 67f6d37 Fix possible unitialized variable issue in usb msc. - a7eb8fc Some improvements to optionrom preemption support. - d28b0fe Refactor USB hub code. - ba28541 Prep version for next release. - 12bffd5 Update version to 0.6.0. - 87ab2fb Improve USB EHCI timing. - d705e5a Disable inlining on old compilers. - bca0736 Force use of indirect function calls in inline assembler. - d7eb27e Don't move EBDA while an optionrom is running (CONFIG_THREAD_OPTIONROMS). - 7415270 Call to int1552 (from int1346) should set regs-dl. - 9dc243e Adjust debug levels of device discovery. - d9c9361 Default CONFIG_COREBOOT_FLASH on; make depend on CONFIG_COREBOOT. - c35e1e5 Restore segment limits in handle_1589 code. - 11cc662 Extend time for rtc to be ready. - 4ed378a Backup and restore registers when calling out to user funcs. - 68c5139 Enable irqs in kbd/clock calls that caller might spin on. - f628244 Process event on ps2 keyboard irq even if event already read. - a5d8458 Revert Unify ps2 port data processing. - b9ed5e2 Handle variable length return of ps2 port GETID command. - 67a9eec Prevent ps2 irqs from messing up ps2 init. - 6704cf9 Revert Rework disabling of ps2 port irqs. - 808939c Fix smp cpu detect on gcc 4.5. - a979c1c Improvements to tools/checkstack.py. - 190cc62 Add USB EHCI controller support. - 0770d67 Some USB UHCI and OHCI fixes and cleanups. - bfe7ca7 Minor - USB OHCI interrupt queue should be one larger. - 09e2f7c Reduce size of USB 'struct uhci_td'. - 406fad6 Dynamically allocate USB controller structures. - 4547eb9 Replace USB encoded 'u32 endp' scheme with explicit struct fields. - 8ebcac0 Further parallelize USB init by launching a thread per usb port. - e908665 Introduce simple mutex locking code. - 3b79f8b Only compile usb-hub.c and paravirt.c with 32bit code. - 357bdfa Prefer passing a USB pipe structure over a USB endp encoding. - 7fb8ba8 Add a generic internal error warning function. Signed-off-by: Anthony Liguori aligu...@us.ibm.com :04 04 e1b3c6d95f0d7cbd709b4b6c28bdb91a0ee1a69b 2e871a4a7ac2e8d4c2fdceb585da8295e3f8348e M pc-bios :04 04 4e12b72f4dca9f76592f70e3b9649a634d5894ff 06c34280852bb7a4809b180d7ba897993727caee M roms -- Windows 98 doesn't detect mouse on qemu and SeaBIOS. https://bugs.launchpad.net/bugs/521994 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: Confirmed Status in “qemu-kvm” package in Debian: Fix Committed Bug description: A windows 98 guest doesn't detect mouse on recent qemu. I bisected and the result is fd646122418ecefcde228d43821d07da79dd99bb is the first bad commit commit fd646122418ecefcde228d43821d07da79dd99bb Author: Anthony Liguori aligu...@us.ibm.com Date: Fri Oct 30 09:06:09 2009 -0500 Switch pc bios from pc-bios to seabios SeaBIOS is a port of pc-bios to GCC. Besides using a more modern tool chain, SeaBIOS introduces a number of new features including PMM support, better BEV and BCV support, and better PnP support. Signed-off-by: Anthony Liguori aligu...@us.ibm.com I got following messages with DEBUG_BIOS Start bios (version 0.5.1-20100111_132716-squirrel.codemonkey.ws) Ram Size=0x0800 (0x high) CPU Mhz=2271 Found 1 cpu(s) max supported 1 cpu(s) PIIX3/PIIX4 init: elcr=00 0c PCI: bus=0 devfn=0x00: vendor_id=0x8086 device_id=0x1237 PCI: bus=0 devfn=0x08: vendor_id=0x8086 device_id=0x7000 PCI: bus=0 devfn=0x09: vendor_id=0x8086 device_id=0x7010 region 4: 0xc000 PCI: bus=0 devfn=0x0b: vendor_id=0x8086 device_id=0x7113 PCI: bus=0 devfn=0x10: vendor_id=0x1013 device_id=0x00b8 region 0: 0xe000 region 1: 0xe200 region 6: 0xe201 MP table addr=0x000f89b0 MPC table addr=0x000f89c0
[Qemu-devel] Re: [PATCH 08/15] xen: Read and write the state of the VM in xenstore
On 08/16/2010 01:15 PM, Stefano Stabellini wrote: On Sun, 15 Aug 2010, Paolo Bonzini wrote: On 08/13/2010 02:53 PM, Anthony Liguori wrote: On 08/12/2010 09:09 AM, stefano.stabell...@eu.citrix.com wrote: From: Anthony PERARDanthony.per...@citrix.com Introduce functions to read and write the state of the VM in xenstore. This basically creates a new management interface for QEMU via the xenstore. Our management interface is QMP. If you want to maintain compatibility, you'll need to write a QMP - xenstore daemon that maps events appropriately. This would belong in xl/libxl. Yes, but considering that we don't want a xenstore-based management interface I would gladly do without the compatibility daemon. We'll try to reduce all the xenstore interaction to the bare minimum, and use QMP everywhere else. Yes, I was just pointing out that you don't need a new compatibility daemon. Since xl is already daemonizing itself to handle on_crash and friends, it could also set up all the watches it cares about, and convert them to QMP commands. It's all more code that needs to be written of course, and boring stuff even. :) Paolo
[Qemu-devel] Re: [PATCH 08/15] xen: Read and write the state of the VM in xenstore
On Mon, 16 Aug 2010, Paolo Bonzini wrote: On 08/16/2010 01:15 PM, Stefano Stabellini wrote: On Sun, 15 Aug 2010, Paolo Bonzini wrote: On 08/13/2010 02:53 PM, Anthony Liguori wrote: On 08/12/2010 09:09 AM, stefano.stabell...@eu.citrix.com wrote: From: Anthony PERARDanthony.per...@citrix.com Introduce functions to read and write the state of the VM in xenstore. This basically creates a new management interface for QEMU via the xenstore. Our management interface is QMP. If you want to maintain compatibility, you'll need to write a QMP - xenstore daemon that maps events appropriately. This would belong in xl/libxl. Yes, but considering that we don't want a xenstore-based management interface I would gladly do without the compatibility daemon. We'll try to reduce all the xenstore interaction to the bare minimum, and use QMP everywhere else. Yes, I was just pointing out that you don't need a new compatibility daemon. Since xl is already daemonizing itself to handle on_crash and friends, it could also set up all the watches it cares about, and convert them to QMP commands. It's all more code that needs to be written of course, and boring stuff even. :) Well yes, but after all you cannot write interesting code all the time :)
Re: [Qemu-devel] [PATCH 02/15] xen: Add xen_machine_fv
Am 12.08.2010 16:09, schrieb stefano.stabell...@eu.citrix.com: From: Anthony PERARD anthony.per...@citrix.com Add the Xen FV (Fully Virtualized) machine to Qemu; this is groundwork to add Xen device model support in Qemu. Signed-off-by: Anthony PERARD anthony.per...@citrix.com Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com Why does this need its own machine type? Shouldn't an HVM machine really look like a PC? And indeed most of this code looks like a (slightly outdated) copy of pc_piix.c with !pci_enabled code paths removed. Kevin
Re: [Qemu-devel] [PATCH 02/15] xen: Add xen_machine_fv
On Mon, 16 Aug 2010, Kevin Wolf wrote: Am 12.08.2010 16:09, schrieb stefano.stabell...@eu.citrix.com: From: Anthony PERARD anthony.per...@citrix.com Add the Xen FV (Fully Virtualized) machine to Qemu; this is groundwork to add Xen device model support in Qemu. Signed-off-by: Anthony PERARD anthony.per...@citrix.com Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com Why does this need its own machine type? Shouldn't an HVM machine really look like a PC? And indeed most of this code looks like a (slightly outdated) copy of pc_piix.c with !pci_enabled code paths removed. The main reason is that we need some xen specific initializations, as you can see from xen_init_fv. But considering that we have been asked to remove target-xen and that will cause a major refactoring of this series, xen_machine_fv could change significantly in the next iterations anyway...
Re: [Qemu-devel] [PATCH 02/15] xen: Add xen_machine_fv
Am 16.08.2010 16:04, schrieb Stefano Stabellini: On Mon, 16 Aug 2010, Kevin Wolf wrote: Am 12.08.2010 16:09, schrieb stefano.stabell...@eu.citrix.com: From: Anthony PERARD anthony.per...@citrix.com Add the Xen FV (Fully Virtualized) machine to Qemu; this is groundwork to add Xen device model support in Qemu. Signed-off-by: Anthony PERARD anthony.per...@citrix.com Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com Why does this need its own machine type? Shouldn't an HVM machine really look like a PC? And indeed most of this code looks like a (slightly outdated) copy of pc_piix.c with !pci_enabled code paths removed. The main reason is that we need some xen specific initializations, as you can see from xen_init_fv. Right, there are some more Xen specific things added later. However, the main part of it is duplicated from pc_piix.c. I'm sure that with some refactoring we could call these functions instead of copying and modifying them. The problem with the latter is that they will inevitably diverge even for changes that make sense for both. I'm not even sure that the machine is the right place to do these Xen specific initializations (expect for the Xen platform PCI device). As far as I understand, the QEMUMachine is considered guest state whereas most of these initializations concern host state. But considering that we have been asked to remove target-xen and that will cause a major refactoring of this series, xen_machine_fv could change significantly in the next iterations anyway... Basically, the request to remove target-xen and my comment both aim in the same direction, namely making Xen less special and integrate it better in existing structures. Kevin
Re: [Qemu-devel] [PATCH 02/15] xen: Add xen_machine_fv
On 08/16/2010 09:13 AM, Kevin Wolf wrote: Am 16.08.2010 16:04, schrieb Stefano Stabellini: On Mon, 16 Aug 2010, Kevin Wolf wrote: Am 12.08.2010 16:09, schrieb stefano.stabell...@eu.citrix.com: From: Anthony PERARDanthony.per...@citrix.com Add the Xen FV (Fully Virtualized) machine to Qemu; this is groundwork to add Xen device model support in Qemu. Signed-off-by: Anthony PERARDanthony.per...@citrix.com Signed-off-by: Stefano Stabellinistefano.stabell...@eu.citrix.com Why does this need its own machine type? Shouldn't an HVM machine really look like a PC? And indeed most of this code looks like a (slightly outdated) copy of pc_piix.c with !pci_enabled code paths removed. The main reason is that we need some xen specific initializations, as you can see from xen_init_fv. Right, there are some more Xen specific things added later. However, the main part of it is duplicated from pc_piix.c. I'm sure that with some refactoring we could call these functions instead of copying and modifying them. The problem with the latter is that they will inevitably diverge even for changes that make sense for both. I'm not even sure that the machine is the right place to do these Xen specific initializations (expect for the Xen platform PCI device). As far as I understand, the QEMUMachine is considered guest state whereas most of these initializations concern host state. To be honest, I think we'll need KVM, Xen, and QEMU specific machines. The right default set of hardware for all three is different. Going back to an old series of mine, they might share a MachineCore, but they'll ultimately need to be different machines. Regards, Anthony Liguori But considering that we have been asked to remove target-xen and that will cause a major refactoring of this series, xen_machine_fv could change significantly in the next iterations anyway... Basically, the request to remove target-xen and my comment both aim in the same direction, namely making Xen less special and integrate it better in existing structures. Kevin
Re: [Qemu-devel] [PATCH 02/15] xen: Add xen_machine_fv
Am 16.08.2010 16:38, schrieb Anthony Liguori: On 08/16/2010 09:13 AM, Kevin Wolf wrote: Am 16.08.2010 16:04, schrieb Stefano Stabellini: On Mon, 16 Aug 2010, Kevin Wolf wrote: Am 12.08.2010 16:09, schrieb stefano.stabell...@eu.citrix.com: From: Anthony PERARDanthony.per...@citrix.com Add the Xen FV (Fully Virtualized) machine to Qemu; this is groundwork to add Xen device model support in Qemu. Signed-off-by: Anthony PERARDanthony.per...@citrix.com Signed-off-by: Stefano Stabellinistefano.stabell...@eu.citrix.com Why does this need its own machine type? Shouldn't an HVM machine really look like a PC? And indeed most of this code looks like a (slightly outdated) copy of pc_piix.c with !pci_enabled code paths removed. The main reason is that we need some xen specific initializations, as you can see from xen_init_fv. Right, there are some more Xen specific things added later. However, the main part of it is duplicated from pc_piix.c. I'm sure that with some refactoring we could call these functions instead of copying and modifying them. The problem with the latter is that they will inevitably diverge even for changes that make sense for both. I'm not even sure that the machine is the right place to do these Xen specific initializations (expect for the Xen platform PCI device). As far as I understand, the QEMUMachine is considered guest state whereas most of these initializations concern host state. To be honest, I think we'll need KVM, Xen, and QEMU specific machines. The right default set of hardware for all three is different. Right, I agree. This is why I put the exception for the platform device. There are probably some more devices for which the same applies. But these exceptions all about guest state. If qdev was finished, this would be a matter of having a different configuration file, right? This series, as I understand it, is adding much more to the Xen FV machine. Things that are not about which devices a VM contains, but about some implementation details of the host. Kevin
Re: [Qemu-devel] [PATCH 02/15] xen: Add xen_machine_fv
On Mon, 16 Aug 2010, Kevin Wolf wrote: Right, I agree. This is why I put the exception for the platform device. There are probably some more devices for which the same applies. But these exceptions all about guest state. If qdev was finished, this would be a matter of having a different configuration file, right? This series, as I understand it, is adding much more to the Xen FV machine. Things that are not about which devices a VM contains, but about some implementation details of the host. We could probably move the mapcache initialization and the ioreq and buffered ioreq page setup to another place, but apart from that the rest is about emulated devices.
Re: [Qemu-devel] [PATCH 02/15] xen: Add xen_machine_fv
On 08/16/2010 09:51 AM, Kevin Wolf wrote: Am 16.08.2010 16:38, schrieb Anthony Liguori: To be honest, I think we'll need KVM, Xen, and QEMU specific machines. The right default set of hardware for all three is different. Right, I agree. This is why I put the exception for the platform device. There are probably some more devices for which the same applies. But these exceptions all about guest state. If qdev was finished, this would be a matter of having a different configuration file, right? This series, as I understand it, is adding much more to the Xen FV machine. Things that are not about which devices a VM contains, but about some implementation details of the host. Yeah, but dropping the target-xen will probably fix most of that stuff. Regards, Anthony Liguori Kevin
Re: [Qemu-devel] [PATCH 2/4] scsi-disk: fix the mode data header returned by the MODE SENSE(10) command
Am 02.08.2010 17:31, schrieb Bernhard Kohl:
The header for the MODE SENSE(10) command is 8 bytes long.
Signed-off-by: Bernhard Kohl bernhard.k...@nsn.com
---
hw/scsi-disk.c | 35 ---
1 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index 57439f4..927df54 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -606,6 +606,7 @@ static int scsi_disk_emulate_mode_sense(SCSIRequest *req,
uint8_t *outbuf)
uint64_t nb_sectors;
int page, dbd, buflen;
uint8_t *p;
+uint8_t dev_specific_param;
dbd = req-cmd.buf[1] 0x8;
page = req-cmd.buf[2] 0x3f;
@@ -613,16 +614,31 @@ static int scsi_disk_emulate_mode_sense(SCSIRequest
*req, uint8_t *outbuf)
memset(outbuf, 0, req-cmd.xfer);
p = outbuf;
-p[1] = 0; /* Default media type. */
-p[3] = 0; /* Block descriptor length. */
-if (bdrv_is_read_only(s-bs)) {
-p[2] = 0x80; /* Readonly. */
+if (bdrv_get_type_hint(s-bs) == BDRV_TYPE_CDROM ||
+bdrv_is_read_only(s-bs)) {
This looks like a mismerge. The check for CDROMs was removed when they
became read-only by definition. Please don't reintroduce it.
+dev_specific_param = 0x80; /* Readonly. */
+} else {
+dev_specific_param = 0x00;
+}
+
+if (req-cmd.buf[0] == MODE_SENSE) {
+p[1] = 0; /* Default media type. */
+p[2] = dev_specific_param;
+p[3] = 0; /* Block descriptor length. */
+p += 4;
+} else { /* MODE_SENSE_10 */
+p[2] = 0; /* Default media type. */
+p[3] = dev_specific_param;
+p[6] = p[7] = 0; /* Block descriptor length. */
+p += 8;
}
-p += 4;
bdrv_get_geometry(s-bs, nb_sectors);
if ((~dbd) nb_sectors) {
-outbuf[3] = 8; /* Block descriptor length */
+if (req-cmd.buf[0] == MODE_SENSE)
+outbuf[3] = 8; /* Block descriptor length */
+else /* MODE_SENSE_10 */
+outbuf[7] = 8; /* Block descriptor length */
Please add curly braces here (see CODING_STYLE).
Kevin
Re: [Qemu-devel] [PATCH 3/4] scsi-disk: fix changeable values returned by the MODE SENSE command
Am 02.08.2010 17:31, schrieb Bernhard Kohl:
If the page control (PC) field in the MODE SENSE command defines Changeable
Values to be returned in the mode pages, don't return any mode page as there
is no support to change any values.
Signed-off-by: Bernhard Kohl bernhard.k...@nsn.com
---
hw/scsi-disk.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index 927df54..26f7345 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -604,13 +604,15 @@ static int scsi_disk_emulate_mode_sense(SCSIRequest
*req, uint8_t *outbuf)
{
SCSIDiskState *s = DO_UPCAST(SCSIDiskState, qdev, req-dev);
uint64_t nb_sectors;
-int page, dbd, buflen;
+int page, dbd, buflen, page_control;
uint8_t *p;
uint8_t dev_specific_param;
dbd = req-cmd.buf[1] 0x8;
page = req-cmd.buf[2] 0x3f;
-DPRINTF(Mode Sense (page %d, len %zd)\n, page, req-cmd.xfer);
+page_control = (req-cmd.buf[2] 0xc0) 6;
+DPRINTF(Mode Sense(%d) (page %d, len %d, page_control %d)\n,
+(req-cmd.buf[0] == MODE_SENSE) ? 6 : 10, page, len, page_control);
memset(outbuf, 0, req-cmd.xfer);
p = outbuf;
@@ -654,7 +656,8 @@ static int scsi_disk_emulate_mode_sense(SCSIRequest *req,
uint8_t *outbuf)
p += 8;
}
-switch (page) {
+/* Don't return pages if Changeable Values (1) are requested. */
+if (page_control != 1) switch (page) {
Coding style (missing braces, and switch belongs on its own line).
case 0x04:
case 0x05:
case 0x08:
I don't think this is enough. Wouldn't this still let the command return
successfully? In fact we need it to fail:
If the logical unit does not implement changeable parameters mode pages
and the device server receives a MODE SENSE command with 01b in the PC
field, then the command shall be terminated with CHECK CONDITION status,
with the sense key set to ILLEGAL REQUEST, and the additional sense code
set to INVALID FIELD IN CDB.
This should do it if I'm not mistaken:
if (page_control == 0x01) {
return -1;
}
Kevin
Re: [Qemu-devel] [PATCH 4/4] scsi-disk: fix the block descriptor returned by the MODE SENSE command
Am 02.08.2010 17:31, schrieb Bernhard Kohl:
The block descriptor contains the number of blocks, not the highest LBA.
Real hard disks return 0 if the number of blocks exceed the maximum 0xFF.
SCSI-Spec:
http://ldkelley.com/SCSI2/SCSI2/SCSI2-08.html#8.3.3
The number of blocks field specifies the number of logical blocks on the
medium
to which the density code and block length fields apply. A value of zero
indicates that all of the remaining logical blocks of the logical unit shall
have the medium characteristics specified.
Signed-off-by: Bernhard Kohl bernhard.k...@nsn.com
---
hw/scsi-disk.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index 26f7345..519513c 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -642,9 +642,8 @@ static int scsi_disk_emulate_mode_sense(SCSIRequest *req,
uint8_t *outbuf)
else /* MODE_SENSE_10 */
outbuf[7] = 8; /* Block descriptor length */
nb_sectors /= s-cluster_size;
-nb_sectors--;
if (nb_sectors 0xff)
-nb_sectors = 0xff;
+nb_sectors = 0;
p[0] = 0; /* media density code */
p[1] = (nb_sectors 16) 0xff;
p[2] = (nb_sectors 8) 0xff;
The patch itself looks okay. However, it made me wonder what this line
wants to tell us:
if ((~dbd) nb_sectors) {
Is it just me or doesn't this make any sense at all? dbd is a single
bit, 0x8 if set or 0x0 otherwise. nb_sectors is the number of sectors.
Can this operation have any meaningful result? I suppose it was meant to
be something like:
if (!dbd nb_sectors) {
Can you please check this and add a patch 5/4 if necessary?
Kevin
Re: [Qemu-devel] [PATCH 0/4] scsi-disk: improve the emulation of the MODE SENSE command
Am 02.08.2010 17:31, schrieb Bernhard Kohl: This series fixes some issues with the MODE SENSE command. I have an OS which fails during this command. It works fine with real SCSI disk hardware. In general this series looks fine. I had some minor comments that I'd like to have addressed before merging it. I'd expect that v2 gets the remaining things right, though, it's not complicated stuff. Kevin
[Qemu-devel] Re: [PATCH 3/7] AMD IOMMU emulation
On Sun, Aug 15, 2010 at 7:27 PM, Eduard - Gabriel Munteanu eduard.munte...@linux360.ro wrote: This introduces emulation for the AMD IOMMU, described in AMD I/O Virtualization Technology (IOMMU) Specification. Signed-off-by: Eduard - Gabriel Munteanu eduard.munte...@linux360.ro --- Makefile.target | 2 + hw/amd_iommu.c | 688 +++ hw/pc.c | 2 + hw/pci_ids.h | 2 + hw/pci_regs.h | 1 + 5 files changed, 695 insertions(+), 0 deletions(-) create mode 100644 hw/amd_iommu.c diff --git a/Makefile.target b/Makefile.target index 70a9c1b..6b80a37 100644 --- a/Makefile.target +++ b/Makefile.target @@ -219,6 +219,8 @@ obj-i386-y += pcspk.o i8254.o obj-i386-$(CONFIG_KVM_PIT) += i8254-kvm.o obj-i386-$(CONFIG_KVM_DEVICE_ASSIGNMENT) += device-assignment.o +obj-i386-y += amd_iommu.o + # Hardware support obj-ia64-y += ide.o pckbd.o vga.o $(SOUND_HW) dma.o $(AUDIODRV) obj-ia64-y += fdc.o mc146818rtc.o serial.o i8259.o ipf.o diff --git a/hw/amd_iommu.c b/hw/amd_iommu.c new file mode 100644 index 000..2e20888 --- /dev/null +++ b/hw/amd_iommu.c @@ -0,0 +1,688 @@ +/* + * AMD IOMMU emulation + * + * Copyright (c) 2010 Eduard - Gabriel Munteanu + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the Software), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + +#include pc.h +#include hw.h +#include pci.h +#include qlist.h + +/* Capability registers */ +#define CAPAB_HEADER 0x00 +#define CAPAB_REV_TYPE 0x02 +#define CAPAB_FLAGS 0x03 +#define CAPAB_BAR_LOW 0x04 +#define CAPAB_BAR_HIGH 0x08 +#define CAPAB_RANGE 0x0C +#define CAPAB_MISC 0x10 + +#define CAPAB_SIZE 0x14 + +/* Capability header data */ +#define CAPAB_FLAG_IOTLBSUP (1 0) +#define CAPAB_FLAG_HTTUNNEL (1 1) +#define CAPAB_FLAG_NPCACHE (1 2) +#define CAPAB_INIT_REV (1 3) +#define CAPAB_INIT_TYPE 3 +#define CAPAB_INIT_REV_TYPE (CAPAB_REV | CAPAB_TYPE) +#define CAPAB_INIT_FLAGS (CAPAB_FLAG_NPCACHE | CAPAB_FLAG_HTTUNNEL) +#define CAPAB_INIT_MISC (64 15) | (48 8) +#define CAPAB_BAR_MASK ~((1UL 14) - 1) + +/* MMIO registers */ +#define MMIO_DEVICE_TABLE 0x +#define MMIO_COMMAND_BASE 0x0008 +#define MMIO_EVENT_BASE 0x0010 +#define MMIO_CONTROL 0x0018 +#define MMIO_EXCL_BASE 0x0020 +#define MMIO_EXCL_LIMIT 0x0028 +#define MMIO_COMMAND_HEAD 0x2000 +#define MMIO_COMMAND_TAIL 0x2008 +#define MMIO_EVENT_HEAD 0x2010 +#define MMIO_EVENT_TAIL 0x2018 +#define MMIO_STATUS 0x2020 + +#define MMIO_SIZE 0x4000 + +#define MMIO_DEVTAB_SIZE_MASK ((1ULL 12) - 1) +#define MMIO_DEVTAB_BASE_MASK (((1ULL 52) - 1) ~MMIO_DEVTAB_SIZE_MASK) +#define MMIO_DEVTAB_ENTRY_SIZE 32 +#define MMIO_DEVTAB_SIZE_UNIT 4096 + +#define MMIO_CMDBUF_SIZE_BYTE (MMIO_COMMAND_BASE + 7) +#define MMIO_CMDBUF_SIZE_MASK 0x0F +#define MMIO_CMDBUF_BASE_MASK MMIO_DEVTAB_BASE_MASK +#define MMIO_CMDBUF_DEFAULT_SIZE 8 +#define MMIO_CMDBUF_HEAD_MASK (((1ULL 19) - 1) ~0x0F) +#define MMIO_CMDBUF_TAIL_MASK MMIO_EVTLOG_HEAD_MASK + +#define MMIO_EVTLOG_SIZE_BYTE (MMIO_EVENT_BASE + 7) +#define MMIO_EVTLOG_SIZE_MASK MMIO_CMDBUF_SIZE_MASK +#define MMIO_EVTLOG_BASE_MASK MMIO_CMDBUF_BASE_MASK +#define MMIO_EVTLOG_DEFAULT_SIZE MMIO_CMDBUF_DEFAULT_SIZE +#define MMIO_EVTLOG_HEAD_MASK (((1ULL 19) - 1) ~0x0F) +#define MMIO_EVTLOG_TAIL_MASK MMIO_EVTLOG_HEAD_MASK + +#define MMIO_EXCL_BASE_MASK MMIO_DEVTAB_BASE_MASK +#define MMIO_EXCL_ENABLED_MASK (1ULL 0) +#define MMIO_EXCL_ALLOW_MASK (1ULL 1) +#define MMIO_EXCL_LIMIT_MASK MMIO_DEVTAB_BASE_MASK +#define MMIO_EXCL_LIMIT_LOW 0xFFF + +#define
[Qemu-devel] Re: [PATCH 1/5] HACKING: add preprocessor rules
On Sun, Aug 15, 2010 at 9:27 PM, Andreas Schwab sch...@linux-m68k.org wrote:
Blue Swirl blauwir...@gmail.com writes:
+For variadic macros, stick with C99 syntax:
+
+#define DPRINTF(fmt, ...) \
+ do { printf(IRQ: fmt, ## __VA_ARGS__); } while (0)
That's not C99 syntax, the combination with ## is a gcc extension. In
C99 you cannot have an empty __VA_ARGS__.
That's too bad, I picked the example from one of our current macros.
Maybe just s/C99/this/ or perhaps we shouldn't specify any
non-standard syntax.
Re: [Qemu-devel] [PATCH 2/5] HACKING: add C type rules
On Sun, Aug 15, 2010 at 9:37 PM, Anthony Liguori anth...@codemonkey.ws wrote:
Hi Blue,
Thanks for putting this document together. It should be quiet helpful!
On 08/15/2010 12:50 PM, Blue Swirl wrote:
Add C type rules, adapted from libvirt HACKING. Also include
a description of special QEMU scalar types.
Move typedef rule from CODING_STYLE rule 3 to HACKING rule 6
where it belongs.
Signed-off-by: Blue Swirlblauwir...@gmail.com
---
CODING_STYLE | 3 --
HACKING | 64
++
2 files changed, 64 insertions(+), 3 deletions(-)
diff --git a/CODING_STYLE b/CODING_STYLE
index 92036f3..2c8268d 100644
--- a/CODING_STYLE
+++ b/CODING_STYLE
@@ -46,9 +46,6 @@ names are
lower_case_with_underscores_ending_with_a_t, like the POSIX
uint64_t and family. Note that this last convention contradicts POSIX
and is therefore likely to be changed.
-Typedefs are used to eliminate the redundant 'struct' keyword. It is the
-QEMU coding style.
-
When wrapping standard library functions, use the prefix qemu_ to alert
readers that they are seeing a wrapped version; otherwise avoid this
prefix.
diff --git a/HACKING b/HACKING
index e60aa48..7c6b49e 100644
--- a/HACKING
+++ b/HACKING
@@ -4,3 +4,67 @@ For variadic macros, stick with C99 syntax:
#define DPRINTF(fmt, ...) \
do { printf(IRQ: fmt, ## __VA_ARGS__); } while (0)
+
+2. C types
+
+It should be common sense to use the right type, but we have collected
+a few useful guidelines here.
+
+2.1. Scalars
+
+If you're using int or long, odds are good that there's a better
type.
+If a variable is counting something, it should be declared with an
+unsigned type.
+
+If it's host memory-size related, size_t should be a good choice (use
+ssize_t only if required). Guest RAM memory offsets must use ram_addr_t,
+but only for RAM, it may not cover whole guest address space.
This needs a little more explanation. There are two different address
spaces. target_phys_addr_t represents guest RAM physical addresses.
Not only RAM, it can be MMIO.
ram_addr_t is a QEMU internal address space that maps guest RAM physical
addresses into an intermediate address space that can map to host virtual
address spaces.
Generally speaking, the size of guest memory can always fit into ram_addr_t
but it would not be correct to store an actual guest physical address in a
ram_addr_t.
I'll add this to the next version.
+If it's file-size related, use off_t.
+If it's file-offset related (i.e., signed), use off_t.
+If it's just counting small numbers use unsigned int;
+(on all but oddball embedded systems, you can assume that that
+type is at least four bytes wide).
+
+In the event that you require a specific width, use a standard type
+like int32_t, uint32_t, uint64_t, etc. The specific types are
+mandatory for VMState fields.
+
+Don't use Linux kernel internal types like u32, __u32 or __le32.
+
+Use target_phys_addr_t for hardware physical addresses except pcibus_t
+for PCI addresses. Use target_ulong (or abi_ulong) for CPU
+virtual addresses, however devices should not need to use target_ulong.
+
+While using bool is good for readability, it comes with minor caveats:
+ - Don't use bool in places where the type size must be constant across
+ all systems, like public interfaces and on-the-wire protocols.
+ - Don't compare a bool variable against the literal, true,
+ since a value with a logical non-false value need not be 1.
+ I.e., don't write if (seen == true) Rather, write if
(seen)
+
+Of course, take all of the above with a grain of salt. If you're about
+to use some system interface that requires a type like size_t, pid_t or
+off_t, use matching types for any corresponding variables.
+
+Also, if you try to use e.g., unsigned int as a type, and that
+conflicts with the signedness of a related variable, sometimes
+it's best just to use the *wrong* type, if pulling the thread
+and fixing all related variables would be too invasive.
+
+Finally, while using descriptive types is important, be careful not to
+go overboard. If whatever you're doing causes warnings, or requires
+casts, then reconsider or ask for help.
+
+2.2. Pointers
+
+Ensure that all of your pointers are const-correct.
+Unless a pointer is used to modify the pointed-to storage,
+give it the const attribute. That way, the reader knows
+up-front that this is a read-only pointer. Perhaps more
+importantly, if we're diligent about this, when you see a non-const
+pointer, you're guaranteed that it is used to modify the storage
+it points to, or it is aliased to another pointer that is.
+
+2.3. Typedefs
+Typedefs are used to eliminate the redundant 'struct' keyword.
It's worth mention the reserved namespaces in C. That is, underscore
capital, double underscore, and underscore 't' suffixes should be avoid.
Re: [Qemu-devel] Re: [PATCH 1/5] HACKING: add preprocessor rules
On 08/16/2010 01:05 PM, Blue Swirl wrote:
On Sun, Aug 15, 2010 at 9:27 PM, Andreas Schwabsch...@linux-m68k.org wrote:
Blue Swirlblauwir...@gmail.com writes:
+For variadic macros, stick with C99 syntax:
+
+#define DPRINTF(fmt, ...) \
+do { printf(IRQ: fmt, ## __VA_ARGS__); } while (0)
That's not C99 syntax, the combination with ## is a gcc extension. In
C99 you cannot have an empty __VA_ARGS__.
That's too bad, I picked the example from one of our current macros.
Maybe just s/C99/this/ or perhaps we shouldn't specify any
non-standard syntax.
We definitely should discourage the GCC syntax [#define fn(arg...)] as
it's deprecated by the new C99 syntax. Very specifically, only the '##'
is an extension and it's a widely adopted one.
Regards,
Anthony Liguori
Re: [Qemu-devel] Unmaintained QEMU builds
On Sun, Aug 15, 2010 at 9:42 PM, Anthony Liguori anth...@codemonkey.ws wrote: On 08/11/2010 11:34 AM, Blue Swirl wrote: On Wed, Aug 11, 2010 at 10:58 AM, Stefan Weilw...@mail.berlios.de wrote: Hi, since several months, QEMU for Windows (and mingw32 cross builds) no longer builds without error. Not true for mingw32, it was building fine here until the latest commit. I suspect that the same is true for QEMU on Darwin (lots of errors like darwin-user/qemu.h:149: error: cast to pointer from integer of different size), but I'm not sure here because I have no valid Darwin test environment. Maybe someone can test this. What about these environments? They have no maintainers. Should they be marked as unsupported? Are they still used? Or should they be removed? I compile test mingw32 very often, it's part of my build test setup. If the build breaks, I may even fix the problem But do you do any testing with the Windows build? Sometime I do a boot test with Wine. Historically, even when Windows builds, it spends large periods of time not actually working. I think Stefan can confirm this. Much of the platform specific code is way behind (like the block layer) and has been for many years. I can't remember the last time someone sent a Win32 enhancement for platform code. Given that it's known to have a lot of issues, I would suggest that we schedule Windows host support for deprecation in 0.15. I would not recommend that we remove any of the WIN32 code from the build but basically stop trying to make it even build until someone steps up to really actively maintain and enhance the Windows port. I would still suggest we take patches if anyone wants to submit them but we should not avoid patches that are known to break win32 (unless the fix is trivial). The same strategy applied to all hosts would probably eventually break everything but Linux on x86 with KVM. There have been very few patches for Darwin, *Solaris, AIX or BSDs, non-x86 targets or non-x86 host CPUs. Without Darwin or BSD host support, darwin-user and bsd-user will be useless. When did we get Xen patches last time before the recent patch set? What about other uncommon and possibly already broken (or never finished) features, like Parallels, VVFAT or VMDK support? What about new features, do we know in advance that they will be actively maintained? But I'm not completely against this. Maybe we should make a list of features and check which of those work. Features which don't pass are scheduled for deprecation or removal. For instance, I know that some downstreams (like Android) depend heavily on Win32 so an official statement of deprecation might cause them to push some of their fixes upstream and be more active in upstream maintenance. We haven't received any patches from VirtualBox downstream either, but maybe they are still using 0.9.0, so they don't have any.
[Qemu-devel] Re: [PATCH] sparc escc IUS improvements (SunOS 4.1.4 fix)
Thanks, applied.
On Sun, Aug 15, 2010 at 2:04 PM, Artyom Tarasenko
atar4q...@googlemail.com wrote:
According to scc_escc_um.pdf:
- Reset Highest IUS must update irq status to allow processing
of the next priority interrupt.
- rx interrupt has always higher priority than tx on same channel
The documentation only explicitly says that Reset Highest IUS
command (0x38) clears IUS bits, not that it clears the corresponding
interrupt too, so don't clear interrupts on this command.
The patch allows SunOS 4.1.4 to use the serial ports
Signed-off-by: Artyom Tarasenko atar4q...@gmail.com
---
hw/escc.c | 56 ++--
1 files changed, 30 insertions(+), 26 deletions(-)
diff --git a/hw/escc.c b/hw/escc.c
index 6d2fd36..8714239 100644
--- a/hw/escc.c
+++ b/hw/escc.c
@@ -65,6 +65,8 @@
* 2006-Aug-10 Igor Kovalenko : Renamed KBDQueue to SERIOQueue,
implemented
* serial mouse queue.
* Implemented serial mouse protocol.
+ *
+ * 2010-May-23 Artyom Tarasenko: Reworked IUS logic
*/
#ifdef DEBUG_SERIAL
@@ -279,7 +281,7 @@ static uint32_t get_queue(void *opaque)
static int escc_update_irq_chn(ChannelState *s)
{
- if s-wregs[W_INTR] INTR_TXINT) s-txint == 1) ||
+ if s-wregs[W_INTR] INTR_TXINT) (s-txint == 1)) ||
// tx ints enabled, pending
s-wregs[W_INTR] INTR_RXMODEMSK) == INTR_RXINT1ST) ||
((s-wregs[W_INTR] INTR_RXMODEMSK) == INTR_RXINTALL))
@@ -342,24 +344,22 @@ static void escc_reset(DeviceState *d)
static inline void set_rxint(ChannelState *s)
{
s-rxint = 1;
- if (!s-txint_under_svc) {
- s-rxint_under_svc = 1;
- if (s-chn == chn_a) {
- if (s-wregs[W_MINTR] MINTR_STATUSHI)
- s-otherchn-rregs[R_IVEC] = IVEC_HIRXINTA;
- else
- s-otherchn-rregs[R_IVEC] = IVEC_LORXINTA;
- } else {
- if (s-wregs[W_MINTR] MINTR_STATUSHI)
- s-rregs[R_IVEC] = IVEC_HIRXINTB;
- else
- s-rregs[R_IVEC] = IVEC_LORXINTB;
- }
- }
- if (s-chn == chn_a)
+ /* XXX: missing daisy chainnig: chn_b rx should have a lower priority
+ than chn_a rx/tx/special_condition service*/
+ s-rxint_under_svc = 1;
+ if (s-chn == chn_a) {
s-rregs[R_INTR] |= INTR_RXINTA;
- else
+ if (s-wregs[W_MINTR] MINTR_STATUSHI)
+ s-otherchn-rregs[R_IVEC] = IVEC_HIRXINTA;
+ else
+ s-otherchn-rregs[R_IVEC] = IVEC_LORXINTA;
+ } else {
s-otherchn-rregs[R_INTR] |= INTR_RXINTB;
+ if (s-wregs[W_MINTR] MINTR_STATUSHI)
+ s-rregs[R_IVEC] = IVEC_HIRXINTB;
+ else
+ s-rregs[R_IVEC] = IVEC_LORXINTB;
+ }
escc_update_irq(s);
}
@@ -369,19 +369,17 @@ static inline void set_txint(ChannelState *s)
if (!s-rxint_under_svc) {
s-txint_under_svc = 1;
if (s-chn == chn_a) {
+ s-rregs[R_INTR] |= INTR_TXINTA;
if (s-wregs[W_MINTR] MINTR_STATUSHI)
s-otherchn-rregs[R_IVEC] = IVEC_HITXINTA;
else
s-otherchn-rregs[R_IVEC] = IVEC_LOTXINTA;
} else {
s-rregs[R_IVEC] = IVEC_TXINTB;
+ s-otherchn-rregs[R_INTR] |= INTR_TXINTB;
}
- }
- if (s-chn == chn_a)
- s-rregs[R_INTR] |= INTR_TXINTA;
- else
- s-otherchn-rregs[R_INTR] |= INTR_TXINTB;
escc_update_irq(s);
+ }
}
static inline void clr_rxint(ChannelState *s)
@@ -417,6 +415,7 @@ static inline void clr_txint(ChannelState *s)
s-otherchn-rregs[R_IVEC] = IVEC_LONOINT;
s-rregs[R_INTR] = ~INTR_TXINTA;
} else {
+ s-otherchn-rregs[R_INTR] = ~INTR_TXINTB;
if (s-wregs[W_MINTR] MINTR_STATUSHI)
s-rregs[R_IVEC] = IVEC_HINOINT;
else
@@ -515,10 +514,15 @@ static void escc_mem_writeb(void *opaque,
target_phys_addr_t addr, uint32_t val)
clr_txint(s);
break;
case CMD_CLR_IUS:
- if (s-rxint_under_svc)
- clr_rxint(s);
- else if (s-txint_under_svc)
- clr_txint(s);
+ if (s-rxint_under_svc) {
+ s-rxint_under_svc = 0;
+ if (s-txint) {
+ set_txint(s);
+ }
+ } else if (s-txint_under_svc) {
+ s-txint_under_svc = 0;
+ }
+ escc_update_irq(s);
break;
default:
break;
--
1.7.2.1
Re: [Qemu-devel] Unknown command 0xffffff in SVGA command FIFO
I came up with this version, it kind of reverses the logic of your patch but reuses the _items function (renamed _length), please see if it looks ok and possibly even works. [sorry about the delay, I was out of office for a while] Yes, your version works (both on paper and in practice). I'm not quite sure I like the way it breaches the apparent abstraction of the FIFO handling routines (if you can call it that) or the way it first gives FIFO slots back to the guest but then rewinds them back. Not that either of those concerns necessarily matter much. BTW, now that I look at it, if either HW_FILL_ACCEL or HW_RECT_ACCEL is not set 'badcmd' will be called, but args won't be set (as far as I can see). Isn't that wrong? Although I think the bug was there even before your changes.
Re: [Qemu-devel] Unmaintained QEMU builds
On 08/16/2010 01:51 PM, Blue Swirl wrote: On Sun, Aug 15, 2010 at 9:42 PM, Anthony Liguorianth...@codemonkey.ws wrote: On 08/11/2010 11:34 AM, Blue Swirl wrote: On Wed, Aug 11, 2010 at 10:58 AM, Stefan Weilw...@mail.berlios.de wrote: Hi, since several months, QEMU for Windows (and mingw32 cross builds) no longer builds without error. Not true for mingw32, it was building fine here until the latest commit. I suspect that the same is true for QEMU on Darwin (lots of errors like darwin-user/qemu.h:149: error: cast to pointer from integer of different size), but I'm not sure here because I have no valid Darwin test environment. Maybe someone can test this. What about these environments? They have no maintainers. Should they be marked as unsupported? Are they still used? Or should they be removed? I compile test mingw32 very often, it's part of my build test setup. If the build breaks, I may even fix the problem But do you do any testing with the Windows build? Sometime I do a boot test with Wine. Historically, even when Windows builds, it spends large periods of time not actually working. I think Stefan can confirm this. Much of the platform specific code is way behind (like the block layer) and has been for many years. I can't remember the last time someone sent a Win32 enhancement for platform code. Given that it's known to have a lot of issues, I would suggest that we schedule Windows host support for deprecation in 0.15. I would not recommend that we remove any of the WIN32 code from the build but basically stop trying to make it even build until someone steps up to really actively maintain and enhance the Windows port. I would still suggest we take patches if anyone wants to submit them but we should not avoid patches that are known to break win32 (unless the fix is trivial). The same strategy applied to all hosts would probably eventually break everything but Linux on x86 with KVM I don't think that's true but I do agree that we'd lose a lot of features. But if the features aren't being used by anyone and they consistently don't work, does it matter? . There have been very few patches for Darwin, *Solaris, AIX or BSDs, non-x86 targets or non-x86 host CPUs. Without Darwin or BSD host support, darwin-user and bsd-user will be useless. When did we get Xen patches last time before the recent patch set? Let's put things in perspective though. Win32 support has been in bad shape for years and no one really seems to care. It's been sorely behind since at least when Fabrice introduced AIO support for Linux without ever doing it properly in Windows. TBH, I think dropping kqemu resulted in the last few win32 users moving on to something else. What about other uncommon and possibly already broken (or never finished) features, like Parallels, VVFAT or VMDK support? What about new features, do we know in advance that they will be actively maintained? We ought to separately consider features that are isolated and features that are invasive. For something like VMDK or VVFAT, there's very little burden that the rest of the code base endures simply by the code existing. Win32 seems to be a constant source of pain though. But I'm not completely against this. Maybe we should make a list of features and check which of those work. Features which don't pass are scheduled for deprecation or removal. Yes, I think this is exactly what we need to do. For instance, I know that some downstreams (like Android) depend heavily on Win32 so an official statement of deprecation might cause them to push some of their fixes upstream and be more active in upstream maintenance. We haven't received any patches from VirtualBox downstream either, but maybe they are still using 0.9.0, so they don't have any. VBox seems to be a lost cause. At least the Android folks have expressed some willingness to work upstream. Regards, Anthony Liguori
[Qemu-devel] KVM forum 2010 presentations
http://www.linux-kvm.org/page/KvmForum2010 Video's will follow as well (thanks Andrew). Thanks for everyone for your participation, looking forward for 2011! Dor
[Qemu-devel] KVM Forum 2010: presentations online
KVM Forum 2010 was quite a success, many thanks to all who participated! For those who couldn't attend, the presentations are available online now: (thanks to Andrew Cathrow for pushing them all up) http://www.linux-kvm.org/page/KVM_Forum_2010#Presentations We were also able to video the speakers, and will send a note when the videos are available. (and thanks again to Andrew Cathrow for making this happen) thanks, -chris
[Qemu-devel] Re: KVM Forum 2010: presentations online
On 08/17/2010 12:50 AM, Chris Wright wrote: KVM Forum 2010 was quite a success, many thanks to all who participated! For those who couldn't attend, the presentations are available online now: (thanks to Andrew Cathrow for pushing them all up) http://www.linux-kvm.org/page/KVM_Forum_2010#Presentations I Beat you in a second ;-) We were also able to video the speakers, and will send a note when the videos are available. (and thanks again to Andrew Cathrow for making this happen) thanks, -chris -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Qemu-devel] Re: KVM Forum 2010: presentations online
* Dor Laor (dl...@redhat.com) wrote: On 08/17/2010 12:50 AM, Chris Wright wrote: KVM Forum 2010 was quite a success, many thanks to all who participated! For those who couldn't attend, the presentations are available online now: (thanks to Andrew Cathrow for pushing them all up) http://www.linux-kvm.org/page/KVM_Forum_2010#Presentations I Beat you in a second ;-) Assuming accurate local clocks...6 seconds even ;)
[Qemu-devel] KVM call agenda for August 17
Please send in any agenda items you are interested in covering. thanks, -chris
[Qemu-devel] [Bug 618533] Re: OpenSolaris guest fails to see the Solaris partitions of a physical disk in qemu-kvm-9999 (GIT)
I ran qemu from command line with debugcon: # /usr/bin/qemu-system-x86_64 --enable-kvm -M pc-0.12 -enable-kvm -m 1024 -smp 2,sockets=2,cores=1,threads=1 -name opensolaris -uuid 7efc6da0-e40f-a1c5-0e85-763dc7ff209c -nodefaults -rtc base=localtime -boot dc -device lsi,id=scsi0,bus=pci.0,addr=0x6 -drive file=Korona4.4.5.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=/dev/sdd,if=none,id=drive-ide0-0-0,format=raw -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -usb -device usb-tablet,id=input0 -sdl -vga vmware -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios Start bios (version pre-0.6.1-20100713_085324-titi) Ram Size=0x4000 (0x high) CPU Mhz=2814 PCI: pci_bios_init_bus_rec bus = 0x0 PIIX3/PIIX4 init: elcr=00 0c PCI: bus=0 devfn=0x00: vendor_id=0x8086 device_id=0x1237 PCI: bus=0 devfn=0x08: vendor_id=0x8086 device_id=0x7000 PCI: bus=0 devfn=0x09: vendor_id=0x8086 device_id=0x7010 region 4: 0xc000 PCI: bus=0 devfn=0x0a: vendor_id=0x8086 device_id=0x7020 region 4: 0xc020 PCI: bus=0 devfn=0x0b: vendor_id=0x8086 device_id=0x7113 PCI: bus=0 devfn=0x10: vendor_id=0x15ad device_id=0x0405 region 0: 0xc040 region 1: 0xf000 region 2: 0xf100 PCI: bus=0 devfn=0x30: vendor_id=0x1000 device_id=0x0012 region 0: 0xc100 region 1: 0xf101 region 2: 0xf1012000 Found 2 cpu(s) max supported 2 cpu(s) MP table addr=0x000fdbe0 MPC table addr=0x000fdbf0 size=244 SMBIOS ptr=0x000fdbc0 table=0x3ec0 ACPI tables: RSDP=0x000fdb90 RSDT=0x3fffde10 Scan for VGA option rom Running option rom at c000:0003 Turning on vga text mode console Starting SeaBIOS (version pre-0.6.1-20100713_085324-titi) UHCI init on dev 00:01.2 (io=c020) Found 0 lpt ports Found 0 serial ports ATA controller 0 at 1f0/3f4/0 (irq 14 dev 9) ATA controller 1 at 170/374/0 (irq 15 dev 9) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (698 GiBytes) drive 0x000fdb40: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 s=1465149168 ata1-0: QEMU DVD-ROM ATAPI-4 DVD/CD PS2 keyboard initialized WARNING - Timeout at wait_qh:218! Timeout on wait_qh 0x3ffef990 (td=0x3ffef8f0 s=40 c=c1/0) All threads complete. Scan for option roms Running option rom at ca00:0003 ebda moved from 9fc00 to 9f400 Returned 53248 bytes of ZoneHigh e820 map has 7 items: 0: - 0009f400 = 1 1: 0009f400 - 000a = 2 2: 000f - 0010 = 2 3: 0010 - 3fffd000 = 1 4: 3fffd000 - 4000 = 2 5: fffc - 0001 = 2 6: feffd000 - ff001000 = 0 enter handle_19: NULL Booting from DVD/CD... 1368MB medium detected Booting from :7c00 Why are PCHS and LCHS both wrong? -- OpenSolaris guest fails to see the Solaris partitions of a physical disk in qemu-kvm- (GIT) https://bugs.launchpad.net/bugs/618533 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: # qemu-kvm --version QEMU emulator version 0.13.50 (qemu-kvm-devel), Copyright (c) 2003-2008 Fabrice Bellard The following disk is presented to guest as IDE disk with /dev/sdd as path. # fdisk -l /dev/sdd Disk /dev/sdd: 750.2 GB, 750156374016 bytes 255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x7f3a03aa Device Boot Start End Blocks Id System /dev/sdd1 63 7887914 3943926 1b Hidden W95 FAT32 /dev/sdd2 7887915 980736119 486424102+ 83 Linux /dev/sdd3 * 980736120 108315049451207187+ bf Solaris /dev/sdd4 1083150495 1465144064 1909967855 Extended /dev/sdd5 1083150558 110774600912297726 83 Linux /dev/sdd6 1107746073 1465144064 1786989967 HPFS/NTFS The prtvtoc output is attached from both VirtualBox and Qemu-KVM. As can be seen in the screenshots, a valid Solaris partition table (which is inside the /dev/sdd3, marked 'bf' in Linux fdisk output) is not seen in Qemu but seen in Virtualbox. This makes the guest unbootable in Qemu because the root FS is not found but its bootable in Virtualbox.
[Qemu-devel] [Bug 618533] Re: OpenSolaris guest fails to see the Solaris partitions of a physical disk in qemu-kvm-9999 (GIT)
I thought C*H*S was equal to the physical size. if c 16384, h16, s63 for the physical, then max size disk it can support is about 8GB. what gives? And C*H*S IS equal to the disk size as shown in the fdisk -l output above. -- OpenSolaris guest fails to see the Solaris partitions of a physical disk in qemu-kvm- (GIT) https://bugs.launchpad.net/bugs/618533 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: # qemu-kvm --version QEMU emulator version 0.13.50 (qemu-kvm-devel), Copyright (c) 2003-2008 Fabrice Bellard The following disk is presented to guest as IDE disk with /dev/sdd as path. # fdisk -l /dev/sdd Disk /dev/sdd: 750.2 GB, 750156374016 bytes 255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x7f3a03aa Device Boot Start End Blocks Id System /dev/sdd1 63 7887914 3943926 1b Hidden W95 FAT32 /dev/sdd2 7887915 980736119 486424102+ 83 Linux /dev/sdd3 * 980736120 108315049451207187+ bf Solaris /dev/sdd4 1083150495 1465144064 1909967855 Extended /dev/sdd5 1083150558 110774600912297726 83 Linux /dev/sdd6 1107746073 1465144064 1786989967 HPFS/NTFS The prtvtoc output is attached from both VirtualBox and Qemu-KVM. As can be seen in the screenshots, a valid Solaris partition table (which is inside the /dev/sdd3, marked 'bf' in Linux fdisk output) is not seen in Qemu but seen in Virtualbox. This makes the guest unbootable in Qemu because the root FS is not found but its bootable in Virtualbox.
[Qemu-devel] [Bug 618533] Re: OpenSolaris guest fails to see the Solaris partitions of a physical disk in qemu-kvm-9999 (GIT)
Since I have been battling this issue alone in this bug report, here is the deal: Attached is the patch which applies to 12.5 and 13.5 and fixes the issue. Can someone please verify the integrity and apply? ** Patch added: Fix some wrong ATA commands. https://bugs.launchpad.net/qemu/+bug/618533/+attachment/1494591/+files/qemu-kvm-ide-ata.patch -- OpenSolaris guest fails to see the Solaris partitions of a physical disk in qemu-kvm- (GIT) https://bugs.launchpad.net/bugs/618533 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: # qemu-kvm --version QEMU emulator version 0.13.50 (qemu-kvm-devel), Copyright (c) 2003-2008 Fabrice Bellard The following disk is presented to guest as IDE disk with /dev/sdd as path. # fdisk -l /dev/sdd Disk /dev/sdd: 750.2 GB, 750156374016 bytes 255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x7f3a03aa Device Boot Start End Blocks Id System /dev/sdd1 63 7887914 3943926 1b Hidden W95 FAT32 /dev/sdd2 7887915 980736119 486424102+ 83 Linux /dev/sdd3 * 980736120 108315049451207187+ bf Solaris /dev/sdd4 1083150495 1465144064 1909967855 Extended /dev/sdd5 1083150558 110774600912297726 83 Linux /dev/sdd6 1107746073 1465144064 1786989967 HPFS/NTFS The prtvtoc output is attached from both VirtualBox and Qemu-KVM. As can be seen in the screenshots, a valid Solaris partition table (which is inside the /dev/sdd3, marked 'bf' in Linux fdisk output) is not seen in Qemu but seen in Virtualbox. This makes the guest unbootable in Qemu because the root FS is not found but its bootable in Virtualbox.
