Patchwork ATA: Allow WIN_SECURITY_FREEZE_LOCK as nop

login
register
mail settings
Submitter Alexander Graf
Date Jan. 30, 2012, 10:29 p.m.
Message ID <1327962588-5230-1-git-send-email-agraf@suse.de>
Download mbox | patch
Permalink /patch/138665/
State New
Headers show

Comments

Alexander Graf - Jan. 30, 2012, 10:29 p.m.
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.

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.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 hw/ide/core.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
Andreas Färber - Feb. 7, 2012, 2:57 p.m.
Hi Alex,

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.
> 
> 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.

I tested this with Windows 2008 R2 and it does not resolve the blue
screen I'm getting there during installation. Unfortunately it reboots
so quickly that I cannot read what it says.

Could you share how you debugged your Windows 8 issue?

Andreas

> 
> Signed-off-by: Alexander Graf <agraf@suse.de>
> ---
>  hw/ide/core.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/hw/ide/core.c b/hw/ide/core.c
> index 56b219b..2c129f4 100644
> --- a/hw/ide/core.c
> +++ b/hw/ide/core.c
> @@ -969,7 +969,7 @@ static const uint8_t ide_cmd_table[0x100] = {
>      [WIN_IDENTIFY]                      = ALL_OK,
>      [WIN_SETFEATURES]                   = ALL_OK,
>      [IBM_SENSE_CONDITION]               = CFA_OK,
> -    [CFA_WEAR_LEVEL]                    = CFA_OK,
> +    [CFA_WEAR_LEVEL]                    = HD_CFA_OK,
>      [WIN_READ_NATIVE_MAX]               = ALL_OK,
>  };
>
Alexander Graf - Feb. 7, 2012, 3:01 p.m.
On 07.02.2012, at 15:57, Andreas Färber wrote:

> Hi Alex,
> 
> 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.
>> 
>> 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.
> 
> I tested this with Windows 2008 R2 and it does not resolve the blue
> screen I'm getting there during installation. Unfortunately it reboots
> so quickly that I cannot read what it says.

Phew, that's probably yet another issue then.

> Could you share how you debugged your Windows 8 issue?

I enabled printf debugging in hw/ide/core.c and looked through the commands close to the blue screen :)


Alex
Kevin Wolf - Feb. 9, 2012, 2:28 p.m.
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
Alexander Graf - Feb. 9, 2012, 2:49 p.m.
On 09.02.2012, at 15:28, Kevin Wolf wrote:

> 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...

IIUC it's mandatory in more recent ATA versions, so that's probably why it assumes it's there.

> 
>> 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.

Hrm. Good point.


Alex
Kevin Wolf - Feb. 9, 2012, 2:59 p.m.
Am 09.02.2012 15:49, schrieb Alexander Graf:
> 
> On 09.02.2012, at 15:28, Kevin Wolf wrote:
> 
>> 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...
> 
> IIUC it's mandatory in more recent ATA versions, so that's probably why it assumes it's there.

ACS-2 says it's optional for both ATA and ATAPI devices.

Kevin
Alexander Graf - Feb. 9, 2012, 3:01 p.m.
On 09.02.2012, at 15:59, Kevin Wolf wrote:

> Am 09.02.2012 15:49, schrieb Alexander Graf:
>> 
>> On 09.02.2012, at 15:28, Kevin Wolf wrote:
>> 
>>> 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...
>> 
>> IIUC it's mandatory in more recent ATA versions, so that's probably why it assumes it's there.
> 
> ACS-2 says it's optional for both ATA and ATAPI devices.

Ah, right. I was looking at the "Historical Command Assignments" table and figured C means it's required, but that of course is wrong.

Then I seriously have no idea why Windows is erroring out here. I mean, it does work just fine for IDE devices. And we don't tell the guest anything special for AHCI.


Alex
Alexander Graf - April 26, 2012, 10:46 a.m.
On 09.02.2012, at 15:28, Kevin Wolf wrote:

> 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...

That's what I would assume, since it only occurs with AHCI, but not with the normal IDE driver. The bug still exists with the current customer preview though.

> 
>> 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.

Alrighty, done :).


Alex

Patch

diff --git a/hw/ide/core.c b/hw/ide/core.c
index 56b219b..2c129f4 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -969,7 +969,7 @@  static const uint8_t ide_cmd_table[0x100] = {
     [WIN_IDENTIFY]                      = ALL_OK,
     [WIN_SETFEATURES]                   = ALL_OK,
     [IBM_SENSE_CONDITION]               = CFA_OK,
-    [CFA_WEAR_LEVEL]                    = CFA_OK,
+    [CFA_WEAR_LEVEL]                    = HD_CFA_OK,
     [WIN_READ_NATIVE_MAX]               = ALL_OK,
 };