qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v1 1/2] scsi-disk: support reporting of rotation


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v1 1/2] scsi-disk: support reporting of rotation rate
Date: Wed, 4 Oct 2017 10:44:27 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0

On 10/04/2017 06:40 AM, Daniel P. Berrange wrote:
> The Linux kernel will query the SCSI "Block device characteristics"
> VPD to determine the rotations per minute of the disk. If this has
> the value 1, it is taken to be an SSD and so Linux sets the
> 'rotational' flag to 0 for the I/O queue and will stop using that
> disk as a source of random entropy. Other operating systems may
> also take into account rotation rate when setting up default
> behaviour.
> 
> Mgmt apps should be able to set the rotation rate for virtualized
> block devices, based on characteristics of the host storage in use,
> so that the guest OS gets sensible behaviour out of the box. This
> patch thus adds a 'rotation-rate' parameter for 'scsi-hd' and
> 'scsi-block' device types. For the latter, this parameter will be
> ignored unless the host device has TYPE_DISK.
> 
> Signed-off-by: Daniel P. Berrange <address@hidden>
> ---
>  hw/scsi/scsi-disk.c | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)

>      bool tray_locked;
> +    /*
> +     * 0x0000        - rotation rate not reported
> +     * 0x0001        - non-rotating medium (SSD)
> +     * 0x0002-0x0400 - reserved
> +     * 0x0401-0xffe  - rotations per minute

s/0xffe/0xfffe/

> +     * 0xffff        - reserved
> +     */
> +    uint16_t rotation_rate;
>  } SCSIDiskState;
>  
>  static bool scsi_handle_rw_error(SCSIDiskReq *r, int error, bool 
> acct_failed);
> @@ -605,6 +613,7 @@ static int scsi_disk_emulate_inquiry(SCSIRequest *req, 
> uint8_t *outbuf)
>              outbuf[buflen++] = 0x83; // device identification
>              if (s->qdev.type == TYPE_DISK) {
>                  outbuf[buflen++] = 0xb0; // block limits
> +                outbuf[buflen++] = 0xb1; /* block device characteristics */

This function is awkward - it is a non-local audit to see whether we are
 at risk of overflowing any buffers due to the new output.  But from
what I can see, I think you're safe.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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