qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] What is the meaning of "Device automatic Partial to Slu


From: John Snow
Subject: Re: [Qemu-devel] What is the meaning of "Device automatic Partial to Slumber transitions"?
Date: Wed, 9 Sep 2015 09:56:08 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0


On 09/09/2015 06:51 AM, Peter Teoh wrote:
> I am trying to compare the difference between hdparm running inside
> qemu (as checkout from latest development git tree) and running on
> native.   My /dev/sdb is an Intel SSD harddisk.
> 
> So running this:
> 
> sudo qemu-system-x86_64 -m 1024 -boot c -enable-kvm -net nic -net user \
> -device virtio-scsi-pci \
> -drive if=none,file=/dev/sdb,id=sdb,cache=off,format=raw \
> -device scsi-block,drive=sdb \
> -hda fedora_hdd.img  \
> -monitor stdio -vga std
> 
> and then followed by "hdparm -I --verbose /dev/sdb" inside the qemu
> guest, versus the hdparm running on the native machine, I can see that
> only this entry is identified as "Unknown 76 (14)"  but whereas on the
> native machine it is listed as:
> 
>         "Device automatic Partial to Slumber transitions",/* word 76 bit 14 */
> 
> Can someone explained the difference (and its meaning) in the virtio 
> emulation?
> 

In your QEMU invocation, you are not "passing through" this SATA device
directly to QEMU, but rather you are passing through just the /data/,
and QEMU is emulating a SCSI block device for you.

When you query this device inside of QEMU, it's going to be answering as
an emulated SCSI device. When you query it on your native machine, it
will be answering as a SATA device.

That should explain differences you see.

As for what this feature bit means; It's defined in the SATA spec as
part of S/ATA's IDENTIFY DEVICE command; the feature is described in
section 13.17. It has to do with automatic power state transitions --
something we generally ignore for SATA emulation in QEMU (and I assume
the same of any similar features for SCSI, etc.)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]