On Fri, 2023-12-08 at 09:21 -0500, Anthony Krowiak wrote: > > On 12/8/23 6:24 AM, Eric Farman wrote: > > On Fri, 2023-12-08 at 11:31 +0100, Janosch Frank wrote: > > > On 12/1/23 19:16, Eric Farman wrote: > > > > The various errors that are possible when processing a PQAP > > > > instruction (the absence of a driver hook, an error FROM that > > > > hook), all correctly set the PSW condition code to 3. But if > > > > that processing works successfully, CC0 needs to be set to > > > > convey that everything was fine. > > > > > > > > Fix the check so that the guest can examine the condition code > > > > to determine whether GPR1 has meaningful data. > > > > > > > Hey Eric, I have yet to see this produce a fail in my AP KVM unit > > > tests. > > > If you find some spare time I'd like to discuss how I can extend > > > my > > > test > > > so that I can see the fail before it's fixed. > > > > > Hi Janosch, absolutely. I had poked around kvm-unit-tests before I > > sent > > this up to see if I could adapt something to show this scenario, > > but > > came up empty and didn't want to go too far down that rabbit hole > > creating something from scratch. I'll ping you offline to find a > > time > > to talk. > > > If this is recreateable, I'd like to know how. I don't see any code > path > that would cause this result. Janosch and I spoke offline... He was using a proposed series of kvm- unit-tests [1] as a base, but the condition code of the PSW was zero at the time of the PQAP, meaning everything seemed fine. By dirtying the CC before the PQAP, this problem pops up quite easily, and this patch gets things back in line. [1] https://lore.kernel.org/kvm/20231117151939.971079-1-frankja@xxxxxxxxxxxxx/ > > > > > > Eric > > >
