Re: APM bug Re: [Qemu-devel] Re: Suggestion - trap window-close of VM

[Struan Bartlett <struan@praguespringpeople.org>]

 From http://www.microsoft.com/whdc/archive/apm.mspx:

"APM support must be enabled in the BIOS when Windows 2000 is installed. 
Although APM can be disabled on many mobile systems, a non-ACPI system 
that has APM disabled in the BIOS will not have power-management 
capabilities installed under Windows 2000."

The way to test for this apparently is looking in the Registry at 
HKEY_LOCAL_MACHINE\ HARDWARE\ Description\ System\ MultifunctionAdapter: 
"If the Windows 2000 Ntdetect module finds an APM BIOS on the system, it 
creates a MultifunctionAdapter subkey with an entry for APM."

So to get APM working with Windows 2000 I surmise one would need to: a. 
get the 16-bit protected mode interface function working correctly; b. 
install Windows 2000 from scratch.

Struan

Struan Bartlett wrote:

> Having reviewed some of the APM1.2 specification, first impression is 
> that the APM bios is required to provide not only a real-mode and 
> protected 32-bit mode interface to its functions, but also a 16-bit 
> protected mode interface, which the apmbios.S code apparently does not 
> have.
>
> I've tried adding one - although I'm not sure it's correct - and 
> adjusting function 0x00 (APM installation check) to return 0x03 in cx 
> (instead of 0x02 to signify the availability of this 16-bit interface) 
> what's interesting is the debug statements immediately become slightly 
> more promising:
>
> APM: EAX=00005300
> APM: EAX=00005301
> APM: EAX=0000530e
> APM: EAX=00005300
> APM: EAX=00005304
> APM: EAX=00005302 [16-bit protected mode interface connect]
> APM: EAX=0000530e
>
> As we can see, after having disconnected the real-mode interface the 
> Windows APM driver seems to try to connect to the 16-bit protected 
> mode interface (function 0x02). It then calls the APM driver version 
> function (0x0e). But this isn't good enough. Windows 2000 still 
> appears to call no further APM functions as it boots and shuts down. 
> So, what's next?
>
> If it's fair to assume that the Windows 2000 APM driver needs to 
> interface with the APM bios using the 16-bit protected-mode interface 
> (instead of the 32-bit interface) then the first thing that seems 
> worth checking is my implementation of function 0x02, which I think it 
> could well be returning the wrong code and data segment addresses. 
> Here's the code:
>
> ;-----------------
> ; APM 16 bit protected mode interface connect
> APMSYM(02):
>  cmp al, #0x02
>  jne APMSYM(03)
>
>  mov ax, #0xffff // 16 bit code segment base
>  mov bx, #_apm16_entry
>  mov cx, #0xf000 // data segment address
>  // 16 bit code segment size
>  mov si, #0xfff0
>  mov di, #0xfff0 // data segment length
>  jmp APMSYM(ok)
>
> ;-----------------
> ; APM 32 bit protected mode interface connect
> APMSYM(03):
>  cmp al, #0x03
>  jne APMSYM(04)
>  mov ax, #0xf000 // 32 bit code segment base
>  mov ebx, #_apm32_entry
>  mov cx, #0xf000 // 16 bit code segment base
>  // 32 bit code segment size (low 16 bits)
>  // 16 bit code segment size (high 16 bits)
>  mov esi, #0xfff0fff0
>  mov dx, #0xf000 // data segment address
>  mov di, #0xfff0 // data segment length
>  jmp APMSYM(ok)
>
> Can anyone advise?
>
> Struan
>
> Struan Bartlett wrote:
>
>> Paul Brook wrote:
>>
>>> In theory windows should be able to "turn off" qemu using APM, like 
>>> it does on real machines. However there seem to be bugs in the qemu 
>>> implementation that stop this working.
>>
>>
>> I thought I'd have a little look into why Windows 2000 doesn't turn 
>> off qemu using APM properly. I enabled DEBUG_BIOS in hw/pc.c then 
>> downloaded the latest Debian source for the Bochs bios v1.121 and 
>> defined DEBUG_ROMBIOS and DEBUG_APM both to be 1. I recompiled and 
>> installed the bios and ran qemu to load up Windows 2000. What we get 
>> seems interesting. By the time Qemu boots Windows 2000 to its first 
>> progress-bar, it has printed the following debug statements (with my 
>> explanation added in square brackets):
>>
>> APM: EAX=00005300 [53 is the int 15h identifier for APM checked for 
>> in rombios.c. 00 is the APM installation check function]
>> APM: EAX=00005301 [01 is the APM real mode interface connect]
>> APM: EAX=0000530e [0e appears to request APM driver version]
>> APM: EAX=00005300 [00, again, is the APM installation check - why is 
>> this called twice?]
>> APM: EAX=00005304 [04 is APM interface disconnect]
>>
>> Then, while Windows 2000 boots and until shutdown is complete, I get 
>> no more debug statements. My question is, why not? I'm no APM expert 
>> but, judging from the 'apmbios.S' comments I might expect to see APM: 
>> EAX=00005303 [03 is APM 32 bit protected mode interface connect]. I 
>> could speculate that the return code from APM function 0e does not 
>> satisfy Windows 2000 for some reason, so it does another installation 
>> check and then disconnects the APM interface entirely - hence no APM 
>> functionality in Windows 2000.
>>
>> If I get more time I may research the APM functions more fully. In 
>> the meantime, if anyone can suggest any alternative theories or how 
>> to test them, I'd be curious.
>>
>> Struan
>>
>>
>>
>> _______________________________________________
>> Qemu-devel mailing list
>> Qemu-devel@nongnu.org
>> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel