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:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
