Description: Boot up a rhel 6 guest and set the harddisk with hdparm it will fail, and return this message: /dev/sda: setting fs readahead to 64 setting unmaskirq to 0 (off) HDIO_SET_UNMASKINTR failed: Inappropriate ioctl for device setting using_dma to 0 (off) HDIO_SET_DMA failed: Inappropriate ioctl for device HDIO_GET_UNMASKINTR failed: Inappropriate ioctl for device HDIO_GET_DMA failed: Inappropriate ioctl for device readahead = 64 (on) The same operate will pass in RHEL6 host. Version-Release number of selected component (if applicable): Host: 2.6.18-236.el5 Guest: 2.6.32-71.7.1.el6 Qemu: rpm -qa |grep kvm kmod-kvm-83-222.el5 etherboot-roms-kvm-5.4.4-13.el5 kmod-kvm-debug-83-222.el5 etherboot-zroms-kvm-5.4.4-13.el5 kvm-qemu-img-83-222.el5 kvm-tools-83-222.el5 kvm-debuginfo-83-222.el5 kvm-83-222.el5 How reproducible: Always Steps to Reproduce: 1.Boot up a rhel 6 guest 2.change the harddisk status with hdparm # hdparm -a64 -d0 -u0 /dev/sda Actual results: Can not set it in guest. Expected results: Harddisk should be set to low performance, and works well. Additional info: 1.Host cpuinfo processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 37 model name : Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz stepping : 2 cpu MHz : 1199.000 cache size : 3072 KB physical id : 0 siblings : 4 core id : 2 cpu cores : 2 apicid : 5 initial apicid : 5 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt aes lahf_lm ida arat tpr_shadow vnmi flexpriority ept vpid bogomips : 4788.19 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
We don't implement a lot of the ATA SETFEATURES command. Given that messing with this settings won't have an effect anyway I'm not sure there's too much of a point implementing these subcommands. If we absolutely want to get rid of the warnings I can look into implementing mostly no-op stubs for it - although that's not quite as easy as it sounds as we need to store state that the GETFEATURES call later on will return the changed values, and we need to save that state for migrations, etc.