[Top][All Lists]

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

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

From: Struan Bartlett
Subject: Re: APM bug Re: [Qemu-devel] Re: Suggestion - trap window-close of VM
Date: Thu, 31 Mar 2005 12:38:18 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041007 Debian/1.7.3-5

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


Qemu-devel mailing list

reply via email to

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