[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [Patch] x86/HVM: Fix RTC interrupt modelling
At 13:31 +0000 on 11 Feb (1392121899), Jan Beulich wrote: > >>> On 11.02.14 at 14:15, Tim Deegan <tim@xxxxxxx> wrote: > > At 12:50 +0000 on 11 Feb (1392119457), Jan Beulich wrote: > >> Right, except you do this be reverting other stuff rather than > >> adding the missing functionality on top. > > > > Absolutely -- because once we went back to having PF set only when the > > interrupt was injected, it seemed better to reduce the amount of > > special-case plumbing for RTC than to add yet more. > > > > But for the case of an OS polling for PF with PIE clear, I guess we > > might need to keep all the current special cases. Was that a known > > observed bug or a theoretical one? > > A theoretical one. Along the lines of the general theme of all the > patches around that time: Get the emulation closer to what real > hardware does. Righto. > > I can't see a way of handling both that case and the w2k3 case. > > Since hardware can, software certainly could as well. Hardware doesn't have to do things like no-missed-ticks mode; it certainly doesn't have to deal with no-ack mode. :( > > Or do we have to treat 'masked in REG_B/IOAPIC' differently from > > 'masked by ISR/TPR/RFLAGS.IF/...'? > > ... this might be the right direction (albeit I think it would be REG_B > on one side and collectively IOAPIC/ISR/TPR/EFLAGS.IF). Yeah, maybe. Something like, if !PIE then we set PF and consume the tick in the early vpt callback, otherwise we do it in the late callback (and in both cases, the early vpt callback doesn't actually assert the line)? Or: we drop the early callback, and go back to setting PF|IRQF in the pt_intr_post callback (much like the patch under discussion), and disable the vpt when the guest clears PIE. Then in the REG_C read, if !PIE, we can set the PF bit if a tick should have happened since the last read (but saving ourselves the bother of running the actual timer). Then the only case where things are wrong is an OS which _both_ polls for the edge _and_ relies on the vpt logic for adding the right number of ticks after being descheduled. Or an OS which asks for interrupts, masks them in the *APIC/RFLAGS and then polls for PF. But that guest, I think, is indistinguishable from w2k3 in the stuck state. Actually that second patch doesn't sound too bad. If that sounds OK to you I can look into coding it up on Thursday. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |