On 06/02/2019 07:40, Jan Beulich wrote: > Benign exceptions, no matter whether they're first or second, will never > cause #DF (a benign exception being second can basically only be #AC, as > in the XSA-156 scenario).
#DB can happen as well, but I'm not sure if this example is relevant here. Both of those loops where repeated exceptions caused by trying to deliver the first exception, rather than an issue of priority amongst simultaneous exceptions during the execution of an instruction. For VT-x, we're supposed to fill in the PENDING_DBG control rather than raise #DB directly, explicitly to allow the priority of interrupts to be expressed correctly. There is a very large quantity of untangling working to do, and very clear I'm not going to have time to fix even the STI/Singlestep issue in the 4.12 timeframe. > Sadly neither AMD nor Intel really define what happens with two benign > exceptions - the term "sequentially" used by both is poisoned by how the > combining of benign and non-benign exceptions is described. Since NMI, > #MC, and hardware interrupts are all benign and (perhaps with the > exception of #MC) can't occur second, favor the first in order to not > lose it. #MC has the highest priority so should only be recognised immediately after an instruction boundary. The interesting subset is then a #DB from task switch, then NMI, then #DB from other pending traps from the previous instruction, so I think it is quite possible for us to end up with a #DB stacked on top of the head of the NMI/#MC handler, if we follow a sequential model. (Lucky for XSA-260 then, if this case actually exists.) I don't however see a way of stacking #AC, because you can't know that one has occured until later in the instruction cycle than all other sources. What would happen is that you'd raise #AC from previous instruction, and then recognise #MC while starting to execute the #AC entry point. (I think) ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
