Re: VMI Interface Proposal Documentation for I386, Part 5

[Pavel Machek <pavel@ucw.cz>]

Hi!

> >>   VMI_EnableInterrupts
> >>
> >>      VMICALL void VMI_EnableInterrupts(void);
> >>
> >>      Enable maskable interrupts on the processor.  Note that the
> >>      current implementation always will deliver any pending interrupts
> >>      on a call which enables interrupts, for compatibility with kernel
> >>      code which expects this behavior.  Whether this should be required
> >>      is open for debate.
> >>    
> >
> >Mind if i push this debate slightly forward? If we were to move the 
> >dispatch of pending interrupts elsewhere, where would that be? In 
> >particular, for a device which won't issue any more interrupts until it's 
> >previous interrupt is serviced. Perhaps injection at arbitrary points 
> >during runtime when interrupts are enabled?
> >  
> 
> Thanks for the response.
> 
> This is exactly what I was hoping for - discussion.  Think about this 
> from the hypervisor perspective - if the guest enables interrupts, and 
> you have something pending to deliver, for correctness, you have to 
> deliver it, right now.  But does the kernel truly require that interrupt 
> deliver immediately - in most cases, no.  In particular, on the fast 

I'd say PCI hardware can delay interrupts for any arbitrary
delay... so if driver expects to get them "immediately", I'd say it is
broken. It should be enough to deliver them "soon enough", like not
more than 1msec late...
								Pavel
-- 
29: