[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
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
address@hidden
http://lists.nongnu.org/mailman/listinfo/qemu-devel
- Re: [Qemu-devel] Re: Suggestion - trap window-close of VM, (continued)
- Re: [Qemu-devel] Re: Suggestion - trap window-close of VM, Struan Bartlett, 2005/03/30
- Re: [Qemu-devel] Re: Suggestion - trap window-close of VM, Lennert Buytenhek, 2005/03/30
- Re: [Qemu-devel] Re: Suggestion - trap window-close of VM, Struan Bartlett, 2005/03/30
- Re: [Qemu-devel] Re: Suggestion - trap window-close of VM, Lennert Buytenhek, 2005/03/30
- Re: [Qemu-devel] Re: Suggestion - trap window-close of VM, Leonardo E. Reiter, 2005/03/30
- Re: [Qemu-devel] Re: Suggestion - trap window-close of VM, Struan Bartlett, 2005/03/30
- Re: [Qemu-devel] Re: Suggestion - trap window-close of VM, John R. Hogerhuis, 2005/03/31
- Re: [Qemu-devel] Re: Suggestion - trap window-close of VM, Lennert Buytenhek, 2005/03/31
- Re: [Qemu-devel] Re: Suggestion - trap window-close of VM, Lennert Buytenhek, 2005/03/30
- APM bug Re: [Qemu-devel] Re: Suggestion - trap window-close of VM, Struan Bartlett, 2005/03/30
- Re: APM bug Re: [Qemu-devel] Re: Suggestion - trap window-close of VM,
Struan Bartlett <=
- Re: APM bug Re: [Qemu-devel] Re: Suggestion - trap window-close of VM, Struan Bartlett, 2005/03/31
- RE: APM bug Re: [Qemu-devel] Re: Suggestion - trap window-close of VM, Andreas Bollhalder, 2005/03/31
- Re: APM bug Re: [Qemu-devel] Re: Suggestion - trap window-close of VM, Jason Gress, 2005/03/31
Re: [Qemu-devel] Suggestion - trap window-close of VM, Mark Williamson, 2005/03/28