I am trying to switch to real-mode to make some BIOS calls. However, when I try to remap kernel at virtual address 0 I get "Unable to handle kernel paging request at virtual address c06e0000" error. Here is where I get it: memcpy(swapper_pg_dir, swapper_pg_dir + USER_PGD_PTRS, sizeof(swapper_pg_dir[0]) * KERNEL_PGD_PTRS); swapper_pg_dir is 0xc06e0000, and user PGD pointers start at 0x400 and kernel pointers start at 0x100. Any idea why I get this? Thanks, Jayant Mangalampalli _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of > Jayant Mangalampalli > Sent: 05 June 2007 14:19 > To: ron minnich; xen-devel@lists.xensource.com > Subject: [Xen-devel] real-mode switch > > I am trying to switch to real-mode to make some BIOS calls. > However, when I try to remap kernel at virtual address 0 I > get "Unable to handle kernel paging request at virtual > address c06e0000" error. Here is where I get it: > > memcpy(swapper_pg_dir, swapper_pg_dir + USER_PGD_PTRS, > sizeof(swapper_pg_dir[0]) * KERNEL_PGD_PTRS);You can''t remap the kernel to 0 - you''ll have to use the Hypervisor if you want to get to real-mode, I think. There was some talk about making a hypercall to "call this bit of code as real-mode". -- Mats> > swapper_pg_dir is 0xc06e0000, and user PGD pointers start at > 0x400 and kernel pointers start at 0x100. Any idea why I get this? > > Thanks, > > Jayant Mangalampalli > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hmmm ... I am trying to add this code to the hypervisor since currently I am not aware of such support in xen. Is there a hypercall support to switch between real- and protected modes already? Thanks Jayant> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of > Jayant Mangalampalli > Sent: 05 June 2007 14:19 > To: ron minnich; xen-devel@lists.xensource.com > Subject: [Xen-devel] real-mode switch > > I am trying to switch to real-mode to make some BIOS calls. > However, when I try to remap kernel at virtual address 0 I > get "Unable to handle kernel paging request at virtual > address c06e0000" error. Here is where I get it: > > memcpy(swapper_pg_dir, swapper_pg_dir + USER_PGD_PTRS, > sizeof(swapper_pg_dir[0]) * KERNEL_PGD_PTRS);You can''t remap the kernel to 0 - you''ll have to use the Hypervisor if you want to get to real-mode, I think. There was some talk about making a hypercall to "call this bit of code as real-mode". -- Mats> > swapper_pg_dir is 0xc06e0000, and user PGD pointers start at > 0x400 and kernel pointers start at 0x100. Any idea why I get this? > > Thanks, > > Jayant Mangalampalli > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 5/6/07 14:24, "Petersson, Mats" <Mats.Petersson@amd.com> wrote:>> I am trying to switch to real-mode to make some BIOS calls. >> However, when I try to remap kernel at virtual address 0 I >> get "Unable to handle kernel paging request at virtual >> address c06e0000" error. Here is where I get it: >> >> memcpy(swapper_pg_dir, swapper_pg_dir + USER_PGD_PTRS, >> sizeof(swapper_pg_dir[0]) * KERNEL_PGD_PTRS); > > You can''t remap the kernel to 0 - you''ll have to use the Hypervisor if > you want to get to real-mode, I think. There was some talk about making > a hypercall to "call this bit of code as real-mode".Actually I changed my mind on this. Returning to real mode after system boot is just too dangerous. But anyway, the immediate problem in this case is the memcpy(). You have to update page directory entries with the mmu_update hypercall. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Can you please explain why you think it is dangerous? Especially if it is supported by functionality to switch to protected mode right after "real mode code" is done executing? Thanks Jayant -----Original Message----- From: Keir Fraser [mailto:keir@xensource.com] Sent: Tuesday, June 05, 2007 7:16 PM To: Petersson, Mats; Jayant Mangalampalli; ron minnich; xen-devel@lists.xensource.com Subject: Re: [Xen-devel] real-mode switch On 5/6/07 14:24, "Petersson, Mats" <Mats.Petersson@amd.com> wrote:>> I am trying to switch to real-mode to make some BIOS calls. >> However, when I try to remap kernel at virtual address 0 I >> get "Unable to handle kernel paging request at virtual >> address c06e0000" error. Here is where I get it: >> >> memcpy(swapper_pg_dir, swapper_pg_dir + USER_PGD_PTRS, >> sizeof(swapper_pg_dir[0]) * KERNEL_PGD_PTRS); > > You can''t remap the kernel to 0 - you''ll have to use the Hypervisor if > you want to get to real-mode, I think. There was some talk aboutmaking> a hypercall to "call this bit of code as real-mode".Actually I changed my mind on this. Returning to real mode after system boot is just too dangerous. But anyway, the immediate problem in this case is the memcpy(). You have to update page directory entries with the mmu_update hypercall. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> "Jayant Mangalampalli" <Jayant_Mangalampalli@phoenix.com> 06.06.07 07:16 >>> >Can you please explain why you think it is dangerous? Especially if it >is supported by functionality to switch to protected mode right after >"real mode code" is done executing?I''m not sure I understand the second part of your statement - by the time dom0 gets control, real mode execution has long stopped (in fact, in pure -unstable Xen there''s not a single bit of real mode execution at present, though there are patches to switch back to real mode very early during Xen startup to retrieve EDD and EDID info and in the future to establish a user selected video mode, but those haven''t been accepted so far). The problems with real mode code execution after initial boot is that once interrupts and certain types of exceptions got enabled, they would need to be masked over an unbounded time period, risking either losing of them or failing to handle them in time. On SMP systems, this would include either halting all remote CPUs or gracefully dealing with IPIs that may be sent against the CPU switching to or being in real mode (again over an unbounded period of time). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 6/6/07 08:08, "Jan Beulich" <jbeulich@novell.com> wrote:> The problems with real mode code execution after initial boot is that once > interrupts and certain types of exceptions got enabled, they would need > to be masked over an unbounded time period, risking either losing of them > or failing to handle them in time. On SMP systems, this would include either > halting all remote CPUs or gracefully dealing with IPIs that may be sent > against the CPU switching to or being in real mode (again over an > unbounded period of time).Also, it is usual to execute BIOS calls with interrupts enabled. That''s obviously bogus if protected-mode drivers have taken over devices, interrupt vectors have been remapped, etc. So we''re going to return to real mode only at beginning of Xen execution, and then down the road we''ll come up with a scheme to avoid needing to do that in cases like kexec of Xen (if anyone cares). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
The problem traces back to setting appropriate vesa mode after xen initialization is done. For that we need an ability to get into real mode briefly and we can set the mode back to ''protected'' after the vesa driver setting is done. -----Original Message----- From: Keir Fraser [mailto:keir@xensource.com] Sent: Wednesday, June 06, 2007 2:18 PM To: Jan Beulich; Jayant Mangalampalli Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] real-mode switch On 6/6/07 08:08, "Jan Beulich" <jbeulich@novell.com> wrote:> The problems with real mode code execution after initial boot is thatonce> interrupts and certain types of exceptions got enabled, they wouldneed> to be masked over an unbounded time period, risking either losing ofthem> or failing to handle them in time. On SMP systems, this would includeeither> halting all remote CPUs or gracefully dealing with IPIs that may besent> against the CPU switching to or being in real mode (again over an > unbounded period of time).Also, it is usual to execute BIOS calls with interrupts enabled. That''s obviously bogus if protected-mode drivers have taken over devices, interrupt vectors have been remapped, etc. So we''re going to return to real mode only at beginning of Xen execution, and then down the road we''ll come up with a scheme to avoid needing to do that in cases like kexec of Xen (if anyone cares). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I understand ... but wouldn''t it be helpful if we can have the ability to switch to real mode to execute a BIOS call and then come back to protected mode as soon as we are done. This feature could potentially be misused, but it could be real useful when we want to quickly update something through bios. Thanks Jayant -----Original Message----- From: Jan Beulich [mailto:jbeulich@novell.com] Sent: Wednesday, June 06, 2007 12:39 PM To: Jayant Mangalampalli Cc: xen-devel@lists.xensource.com Subject: RE: [Xen-devel] real-mode switch>>> "Jayant Mangalampalli" <Jayant_Mangalampalli@phoenix.com> 06.06.0707:16 >>>>Can you please explain why you think it is dangerous? Especially if it >is supported by functionality to switch to protected mode right after >"real mode code" is done executing?I''m not sure I understand the second part of your statement - by the time dom0 gets control, real mode execution has long stopped (in fact, in pure -unstable Xen there''s not a single bit of real mode execution at present, though there are patches to switch back to real mode very early during Xen startup to retrieve EDD and EDID info and in the future to establish a user selected video mode, but those haven''t been accepted so far). The problems with real mode code execution after initial boot is that once interrupts and certain types of exceptions got enabled, they would need to be masked over an unbounded time period, risking either losing of them or failing to handle them in time. On SMP systems, this would include either halting all remote CPUs or gracefully dealing with IPIs that may be sent against the CPU switching to or being in real mode (again over an unbounded period of time). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
As I said in my reply - this is exactly the one thing missing so far. But it ought to be done in Xen, not in dom0, and it is on my todo list. Jan>>> "Jayant Mangalampalli" <Jayant_Mangalampalli@phoenix.com> 06.06.07 12:32 >>>The problem traces back to setting appropriate vesa mode after xen initialization is done. For that we need an ability to get into real mode briefly and we can set the mode back to ''protected'' after the vesa driver setting is done. -----Original Message----- From: Keir Fraser [mailto:keir@xensource.com] Sent: Wednesday, June 06, 2007 2:18 PM To: Jan Beulich; Jayant Mangalampalli Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] real-mode switch On 6/6/07 08:08, "Jan Beulich" <jbeulich@novell.com> wrote:> The problems with real mode code execution after initial boot is thatonce> interrupts and certain types of exceptions got enabled, they wouldneed> to be masked over an unbounded time period, risking either losing ofthem> or failing to handle them in time. On SMP systems, this would includeeither> halting all remote CPUs or gracefully dealing with IPIs that may besent> against the CPU switching to or being in real mode (again over an > unbounded period of time).Also, it is usual to execute BIOS calls with interrupts enabled. That''s obviously bogus if protected-mode drivers have taken over devices, interrupt vectors have been remapped, etc. So we''re going to return to real mode only at beginning of Xen execution, and then down the road we''ll come up with a scheme to avoid needing to do that in cases like kexec of Xen (if anyone cares). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 6/6/07 11:32, "Jayant Mangalampalli" <Jayant_Mangalampalli@phoenix.com> wrote:> The problem traces back to setting appropriate vesa mode after xen > initialization is done. For that we need an ability to get into real > mode briefly and we can set the mode back to ''protected'' after the vesa > driver setting is done.This is in progress. We''ll set the vesa mode on entry to Xen however; not after Xen has booted. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I tried doing this in xen domain itself, but I see the system reboots on itself as soon as data segment registers are loaded with "real mode compatible" values. Any idea why this might be happening? I am unable to retrieve the logs ... Thanks Jayant -----Original Message----- From: Keir Fraser [mailto:keir@xensource.com] Sent: Wednesday, June 06, 2007 4:17 PM To: Jayant Mangalampalli; Jan Beulich Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] real-mode switch On 6/6/07 11:32, "Jayant Mangalampalli" <Jayant_Mangalampalli@phoenix.com> wrote:> The problem traces back to setting appropriate vesa mode after xen > initialization is done. For that we need an ability to get into real > mode briefly and we can set the mode back to ''protected'' after thevesa> driver setting is done.This is in progress. We''ll set the vesa mode on entry to Xen however; not after Xen has booted. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Because it''s just not supported. You can''t load real-mode segment values unless you are actually *in* real mode. Or vm86 mode. -- Keir On 6/6/07 14:45, "Jayant Mangalampalli" <Jayant_Mangalampalli@phoenix.com> wrote:> I tried doing this in xen domain itself, but I see the system reboots on > itself as soon as data segment registers are loaded with "real mode > compatible" values. Any idea why this might be happening? I am unable to > retrieve the logs ... > > Thanks > Jayant > > -----Original Message----- > From: Keir Fraser [mailto:keir@xensource.com] > Sent: Wednesday, June 06, 2007 4:17 PM > To: Jayant Mangalampalli; Jan Beulich > Cc: xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] real-mode switch > > > > > On 6/6/07 11:32, "Jayant Mangalampalli" > <Jayant_Mangalampalli@phoenix.com> > wrote: > >> The problem traces back to setting appropriate vesa mode after xen >> initialization is done. For that we need an ability to get into real >> mode briefly and we can set the mode back to ''protected'' after the > vesa >> driver setting is done. > > This is in progress. We''ll set the vesa mode on entry to Xen however; > not > after Xen has booted. > > -- Keir > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel