> -----Original Message-----
> From: Keir Fraser [mailto:keir@xxxxxxxxxxxxx]
> Sent: Friday, August 10, 2007 4:18 PM
> To: Guy Zana; xen-devel@xxxxxxxxxxxxxxxxxxx
> Cc: Alex Novik
> Subject: Re: [Xen-devel] [RFC] Pass-through Interdomain
> Interrupts Sharing (HVM/Dom0)
>
> On 10/8/07 12:50, "Guy Zana" <guy@xxxxxxxxxxxx> wrote:
>
> >> It would cycle through the priority list, moving frontmost
> to back at
> >> each stage, until the line is deasserted.
> >
> > 1. When will you deassert the HVM vline?
>
> I would turn vline assertions into pulses: the line would be
> asserted only instantaneously, to get latched by the
> VPIC/VIOAPIC. Actually I think this question is quite
> separate from whatever method we use for interrupt
> sharing: when would you deassert the vline when the interrupt
> is *not* shared? Whatever method we choose should be
> extendable to the shared case, and applied to whichever HVM
> guest we are currently choosing to deliver the interrupt to.
> So, whether the interrupt is shared or not, I see no value in
> modelling the state of the level-triggered vline.
Sounds good actually :-)
>
> > 2. How do you avoid HVM spurious interrupts?
>
> I avoid most of them by the fact that a HVM guest that is not
> handling interrupts will get pushed down the priority list.
> Of course this won't get rid of all spurious interrupts, but
> I'd expect it to get rid of enough (e.g., at least 50% even
> in some worst cases I can think of). So the question is: how
> sensitive is Windows to spurious interrupts? I know that
> Linux needs something like 99% of interrupts to be spurious
> for it to generate a warning. If Windows is similar then my
> approach would work just fine.
>From what I saw, Windows XP is not that sensitive to spurious interrupts (at
>least for ISA interrupts). In general, Windows tries hard to survive :-)
We'll have to check if a prioritize list will suffice, it would be simple, I
agree.
But you still do bad stuff and hope it'll go unnoticed, sounds like a recipe
for voodoo, it should be well tested at least.
Thanks,
Guy.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home