Am I correct in saying that setting HVM_PARAM_CALLBACK_IRQ to 0 disables interrupts in a HVM domain? I''m finding that an interrupt in a HVM domain is getting called well after I do the above. My theory is that there is something about the way HVM stuff works that an interrupt could be ''in the pipeline'' and could still occur even though I set HVM_PARAM_CALLBACK_IRQ to 0 and mask off the interrupts (evtchn_upcall_mask = 1 for all CPU''s) If that could happen, I''ll need to work around it... Thanks james _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
The evtchn_upcall_mask is not respected for HVM guests. When you set HVM_PARAM_CALLBACK_IRQ to 0, no more interrupts will be generated at the PIC or IO-APIC. But any interrupts queued up at either of those will eventually get propagated to the CPU. Is there a way to de-register from an IRQ and hence get Windows to mask the PIC/IO-APIC line? -- Keir On 25/7/08 06:34, "James Harper" <james.harper@bendigoit.com.au> wrote:> Am I correct in saying that setting HVM_PARAM_CALLBACK_IRQ to 0 disables > interrupts in a HVM domain? > > I''m finding that an interrupt in a HVM domain is getting called well > after I do the above. My theory is that there is something about the way > HVM stuff works that an interrupt could be ''in the pipeline'' and could > still occur even though I set HVM_PARAM_CALLBACK_IRQ to 0 and mask off > the interrupts (evtchn_upcall_mask = 1 for all CPU''s) > > If that could happen, I''ll need to work around it... > > Thanks > > james > > _______________________________________________ > 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
> > The evtchn_upcall_mask is not respected for HVM guests. When you set > HVM_PARAM_CALLBACK_IRQ to 0, no more interrupts will be generated atthe> PIC or IO-APIC. But any interrupts queued up at either of those will > eventually get propagated to the CPU.Thanks. I wish I''d known that earlier :|> Is there a way to de-register from an IRQ and > hence get Windows to mask the PIC/IO-APIC line?Yes, I was doing that previously but under Windows you can only register and unregister an interrupt at PASSIVE_LEVEL (all interrupts and thread switching enabled), which I didn''t want to do as when I disable interrupts for a save/suspend, I don''t want windows doing that sort of thing (eg trying to perform a paging operation or something). I''ve worked around it for now by just flipping a flag to say to the ISR to just return if it gets an interrupt after a certain point. Save/restore suddenly seems to work perfectly! Just to clarify, if I have masked the interrupts via HVM_PARAM_CALLBACK_IRQ = 0, it is safe to do nothing when the interrupt occurs right? I don''t need to unset the ''pending'' bits or anything? Thanks James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 25/7/08 08:02, "James Harper" <james.harper@bendigoit.com.au> wrote:> Just to clarify, if I have masked the interrupts via > HVM_PARAM_CALLBACK_IRQ = 0, it is safe to do nothing when the interrupt > occurs right? I don''t need to unset the ''pending'' bits or anything?Yes, as soon as HVM_PARAM_CALLBACK_IRQ=0 the ''interrupt wire'' is de-asserted. You only get a single spurious interrupt if the wire status was latched by the PIC or IO-APIC before you cleared HVM_PARAM_CALLBACK_IRQ. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel