Use the real-mode address ffff:0010 to access the linear address 0x100000, and so test whether or not the A20 gate is enabled without requiring a switch into flat real mode (or some other addressing mode). This speeds up CPU mode transitions, and also avoids breaking the NBP from IBM's Tivoli Provisioning Manager for Operating System Deployment. This NBP makes some calls to iPXE in VM86 mode rather than true real mode and does not correctly emulate our transition into flat real mode. Interestingly, Tivoli's VMM *does* allow us to switch into protected mode (though it patches our GDT so that we execute in ring 1 rather than ring 0). However, paging is still disabled and we have a 4GB segment limit. Being in ring 1 does not, therefore, restrict us in any meaningful way; this has been verified by deliberately writing garbage over Tivoli's own GDT (at address 0x02201010) during a nominally VM86-mode PXE API call. It's unclear precisely what protection this VMM is supposed to be offering. Suggested-by: Joshua Oreman <oremanj@rwcr.net> Signed-off-by: Michael Brown <mcb30@ipxe.org>tags/v1.20.1
|
|
||
165 |
|
165 |
|
166 |
|
166 |
|
167 |
|
167 |
|
|
168 |
|
|
|
169 |
|
|
168 |
|
170 |
|
169 |
|
|
|
170 |
|
|
|
|
171 |
|
|
|
172 |
|
|
|
173 |
|
|
|
174 |
|
|
|
175 |
|
|
171 |
|
176 |
|
172 |
|
177 |
|
173 |
|
|
|
174 |
|
|
|
175 |
|
|
|
|
178 |
|
|
|
179 |
|
|
|
180 |
|
|
|
181 |
|
|
|
182 |
|
|
|
183 |
|
|
|
184 |
|
|
176 |
|
185 |
|
177 |
|
186 |
|
178 |
|
187 |
|
|
|
||
182 |
|
191 |
|
183 |
|
192 |
|
184 |
|
193 |
|
|
194 |
|
|
|
195 |
|
|
185 |
|
196 |
|
186 |
|
197 |
|
187 |
|
198 |
|
188 |
|
199 |
|
189 |
|
200 |
|
190 |
|
|
|
191 |
|
|
|
192 |
|
|
|
193 |
|
|
|
194 |
|
|
|
195 |
|
|
|
196 |
|
201 |
|
197 |
|
202 |
|
198 |
|
203 |
|
|
|
||
414 |
|
419 |
|
415 |
|
420 |
|
416 |
|
421 |
|
417 |
|
|
|
|
422 |
|
|
|
423 |
|
|
418 |
|
424 |
|
419 |
|
425 |
|