On Tuesday 17 June 2014 03:02 PM, Benjamin Herrenschmidt wrote: > On Tue, 2014-06-17 at 11:25 +0200, Alexander Graf wrote: >> On 17.06.14 11:22, Benjamin Herrenschmidt wrote: >>> On Tue, 2014-06-17 at 10:54 +0200, Alexander Graf wrote: >>>> Also, why don't we use twi always or something else that actually is >>>> defined as illegal instruction? I would like to see this shared with >>>> book3s_32 PR. >>> twi will be directed to the guest on HV no ? We want a real illegal >>> because those go to the host (for potential emulation by the HV). >> >> Ah, good point. I guess we need different one for PR and HV then to >> ensure compatibility with older ISAs on PR. > > Well, we also need to be careful with what happens if a PR guest puts > that instruction in, do that stop its HV guest/host ? > Damn, my mail client is messed up. did not see the mail till now. I havent tried this incase of PR guest kernel. I will need to try this before commenting. > What if it's done in userspace ? Do that stop the kernel ? :-) > Basically flow is that, when we see this instruction, we return to host, and host checks for address in the SW array and if not it returns to kernel. > Maddy, I haven't checked, does your patch ensure that we only ever stop > if the instruction is at a recorded bkpt address ? It still means that a > userspace process can practically DOS its kernel by issuing a lot of > these causing a crapload of exits. > This is valid, userspace can create a mess, need to handle this, meaning incase if we dont find a valid SW breakpoint for this address in the HOST, we need to route it to guest and kill it at app. Regards Maddy > Cheers, > Ben. > >> Alex >> >>> I'm >>> trying to see if I can get the architect to set one in stone in a future >>> proof way. >>> >>> Cheers, >>> Ben. >>> >> >> -- >> To unsubscribe from this list: send the line "unsubscribe kvm" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
