oslib-devel

[Oslib-devel] how to...

[Juras B. <yb...@tu...>]

Hello oslib-devel,

  how to obtain CONTEXT for VM86-task of callBIOS
  to privide multitasking while a BIOS function is running?

-- 
Best regards,
 Juras                          mailto:yb...@tu...

Re: [Oslib-devel] how to...

[Luca A. <la...@mb...>]

Hi Juras,

sorry for the late reply...

>   how to obtain CONTEXT for VM86-task of callBIOS
>   to privide multitasking while a BIOS function is running?
Ok, here is how things work with vm86_callBIOS:
- There is a vm86 task that is used for performing bios calls. This is
  not a real task that can be scheduled together with the other ones (at
  least, I would not schedule it ;), but is considered to be
  nonpreemptable. It is only needed to switch to the vm86 mode (and
  back). It is not created through ll_context_create(), but by directly
  writing the TSS into the GDT (see vm86_init())
- The CONTEXT of a task is just a selector, indicating the position of
  its TSS in the GDT
- There is only a vm86 task (the BIOS is not reentrant), and its CONTEXT
  is X_VM86_TSS, defined in ll/i386/sel.h
- You can know the CONTEXT of the task that is currently running by
  using get_TR(), or context_save(), or ll_context_save() (they are more
  or less equivalent)
- Hence, if you want to see if you are running the vm86 task or not, you
  can do:
	CONTEXT c = get_TR();
	
	if (c == X_VM86_TSS) {
		/* We are in the vm86 task */
	} else {
		/* We are running some other task... */
	}
  See for example the emulate() function in examples/biosdemo.c

Ok, I hope this clarified things a little bit... If your scheduler is
driven by the timer interrupt, I would simply avoid to invoke it if the
interrupted task is the vm86 task.

				Luca

-- 
_________________________________________________________________________
Add this to your signature, if you think it is important
                       N O   W A R ! ! !

Re[2]: [Oslib-devel] how to...

[Juras B. <yb...@tu...>]

Hello Luca,

Friday, February 28, 2003, 4:13:12 PM, you wrote:

LA> Ok, I hope this clarified things a little bit... If your scheduler is
LA> driven by the timer interrupt, I would simply avoid to invoke it if the
LA> interrupted task is the vm86 task.

Do you mean something like this:

void mytimerhandler()
{
 if (vm86task)
  {
   // jump to vm86 timer handler through real mode interrupt table
   // by setting VM86 task's CS:IP pointer, pushing flags etc.
   return;
  }

  // switch to the next task in the scheduler's queue and
  // handle timer interrupt for 32-bit OS needs

}

?

I think this will HALT the task-switching mechanism while a VM86-task is not
yet finished and paralyze the system...

But maybe I should handle an interrupt twice, i.e. emulate interrupt for VM86
task (pushing flags, setting CS:IP...) and handle the interrupt as usual for OS
needs?



-- 
Best regards,
 Juras                            mailto:yb...@tu...

Re: [Oslib-devel] how to...

[Luca A. <luc...@em...>]

Hi Juras,

[...]

> Do you mean something like this:
> 
> void mytimerhandler()
> {
>  if (vm86task)
>   {
>    // jump to vm86 timer handler through real mode interrupt table
>    // by setting VM86 task's CS:IP pointer, pushing flags etc.
>    return;
>   }
> 
>   // switch to the next task in the scheduler's queue and
>   // handle timer interrupt for 32-bit OS needs
> 
> }
Yes, more or less... I don't know if the "jump to vm86 timer handler" part
is needed, hence I'd do something in the line of:

void mytimerhandler()
{
  if (<task is vm86>) {
    return;
  }

  <call scheduler and do your usual stuff>
}
 
> I think this will HALT the task-switching mechanism while a VM86-task is not
> yet finished and paralyze the system...
As I said, I would "play safe", and consider the vm86 task as nonpreemptable (or as the
highest priority task in a fixed priority scheduler).
This will surely have some effects on system latencies, but I don't think it will paralyze the
system. After verifying that this work, you can try more aggressive approaches, like
scheduling the vm86 task.

> But maybe I should handle an interrupt twice, i.e. emulate interrupt for VM86
> task (pushing flags, setting CS:IP...) and handle the interrupt as usual for OS
> needs?
I don't think this is needed. 

					Luca
-- 
                              N O    W A R ! ! !
     Copy this in your signature if you think it is important



--
Prendi GRATIS l'email universale che... risparmia: http://www.email.it/f

Sponsor:
Vai contro corrente! Inizia a mantenerti in forma da Natale: Oliviero Città dello Sport!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=1074&d=2-3