From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:50301)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1RvUvT-0008QA-LJ
	for qemu-devel@nongnu.org; Thu, 09 Feb 2012 09:24:48 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1RvUvP-0002os-0Y
	for qemu-devel@nongnu.org; Thu, 09 Feb 2012 09:24:43 -0500
Received: from mx1.redhat.com ([209.132.183.28]:64322)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1RvUvO-0002oi-QA
	for qemu-devel@nongnu.org; Thu, 09 Feb 2012 09:24:38 -0500
Message-ID: <4F33D7F1.9050709@redhat.com>
Date: Thu, 09 Feb 2012 15:28:01 +0100
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
References: <1327962588-5230-1-git-send-email-agraf@suse.de>
In-Reply-To: <1327962588-5230-1-git-send-email-agraf@suse.de>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH] ATA: Allow WIN_SECURITY_FREEZE_LOCK as nop
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Alexander Graf <agraf@suse.de>
Cc: Jan Kiszka <jan.kiszka@siemens.com>, qemu-devel Developers <qemu-devel@nongnu.org>

Am 30.01.2012 23:29, schrieb Alexander Graf:
> When using Windows 8 with an AHCI disk drive, it issues a blue screen.
> The reason is that WIN_SECURITY_FREEZE_LOCK / CFA_WEAR_LEVEL is not
> supported by our ATA implementation, but Windows expects it to be there.

Is there anything that makes Windows believe that we support it? The
spec says bits in IDENTIFY word 82 and 128 must be set to indicate
support for the security feature set, and we don't set those.

Might be just a Windows bug, of course...

> Since without security stuff implemented, the lock would be a nop anyway
> and CFA_WEAR_LEVEL already is treated as a nop, let's just allow the cmd
> for HD drives as well. That way Windows is happy.

It sets the sector count register to 0, which isn't exactly nop. In any
case, the code would at the very least need a comment that it's used for
two separate commands, so that we still remember this when some time in
the future someone writes a real implementation.

Kevin