On Tue, 2008-06-10 at 10:12 -0500, Hollis Blanchard wrote: > On Mon, 2008-06-09 at 18:56 -0500, Jerone Young wrote: > > On Mon, 2008-06-09 at 17:56 -0500, Hollis Blanchard wrote: > > > On Mon, 2008-06-09 at 16:08 -0500, Jerone Young wrote: > > > > > > > > > You also have not addressed the case I pointed out where an IAC > > > > matches > > > > > after you've programmed it but before you've entered the guest. > > > > > > > > Basically can disable them in the dbcr0 before we do any switching out > > > > of registers. > > > > > > We'll have to enable DBCR0 some time, right? > > > > > Yes it gets enabled when when the guest cuts on the bits it wants & the > > we restre the host DBCR0. > > > > > > > > If an IAC is matched before we enter the guest it will be caught host > > > > that catches it. > > > > > > But that won't happen because you've disabled MSR[DE]. > > > > Ah... you don't rember the whole imprecise interrupts ;-) . When MSR[DE] > > =0 and an IAC will go off but not at the exact address. This was fun > > figuring out. > > Right. Now, when will the deferred debug event fire, and who will handle > it? What can we do about that? If the debug registers are turned off before we disable MSR[DE], there will be no debug events at all. This is what I was talking about in my first couple of emails. If a debug event does go off and the host does not handle it, the only way to know is the dbsr register (and there is no way to save that off). So in the end it could end up going off in the guest. This is why I said you should not do host debugging if you want to do guest debugging at the sametime, as a work around for now. Really can be addressed in a patch on top of this patch. Though I really don't want to linger on this problem as it is not critical at the moment as nobody is using these registers in the host currently. I can clear the dbsr registers also when disabling the debug interrupts as a solution? > > > I also have a bug in this patch. I placed the wrong definitions when > > disabling the debug interrupts. I'll respin again. Look things over more > > carefully this time. > > I think you're respinning these patches too frequently, before > conversation has concluded. I think respining has helped in the conversation to be honest. As I can better demonstrate what I am thinking (though better without mistakes). Also I figured this was concluded. I will not spin anymore patches till we can agree on an answer for everything. -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
