On Wed, Apr 29, 2015 at 5:08 PM, Alex Bennée <alex.bennee@xxxxxxxxxx> wrote: > > Christoffer Dall <christoffer.dall@xxxxxxxxxx> writes: > >> On Wed, Apr 29, 2015 at 10:18:18AM +0100, Alex Bennée wrote: >>> >>> Christoffer Dall <christoffer.dall@xxxxxxxxxx> writes: >>> >>> > On Tue, Apr 28, 2015 at 03:37:01PM +0100, Alex Bennée wrote: >>> >> >>> >> Christoffer Dall <christoffer.dall@xxxxxxxxxx> writes: >>> >> >>> >> > On Tue, Apr 28, 2015 at 10:34:12AM +0100, Peter Maydell wrote: >>> >> >> On 28 April 2015 at 09:42, Alex Bennée <alex.bennee@xxxxxxxxxx> wrote: >>> >> >> > Peter Maydell <peter.maydell@xxxxxxxxxx> writes: >>> >> >> >> Does the kernel already have a conveniently implemented "inject >>> >> >> >> exception into guest" lump of code? If so it might be less effort >>> >> >> >> to do it that way round, maybe. >>> >> >> > > <snip> >>> >> >>> >> Certainly there are some cases where the kernel doesn't have all the >>> >> information. For example it doesn't know if the soft break was inserted >>> >> by the guest or the host. That to me favours the "let userspace deal >>> >> with the ugly" approach. >>> >> >>> > Not sure I follow. >>> > >>> > If it's an exception for the guest, then that must be because the guest >>> > put in the breakpoint instruction, right? >>> >>> No the host can add breakpoint instructions as well. They both generate >>> the same (redirected) exception to the hypervisor which then has to >>> figure out who planted the breakpoint and where the eventual exception >>> will be handled. >> >> I understand this; let's just rewind here. >> >> If you've concluded that the exception is for the guest, then the guest >> must have placed the breakpoint instruction there, correct? Otherwise, >> the exception is for the hypervisor and the discussion about how to >> inject an exception for the guest is invalid. > > But only userspace has enough information to make that conclusion (after > searching the list of breakpoints it added to the code). So from > userspace we can: > > - re-enter KVM telling it to re-route the exception it just delivered > to userspace somehow > > or > > - make the changes to deliver the exception in userspace and re-enter > KVM as normal. > ok, we agree and are talking about the same thing. good. > It seems to me if we have already exited into userspace it may as well > clean up if it has all the information it needs? > depends on the complexity and size of the code really, imho. >> Or are you talking about the corner case where the host uses a soft >> breakpoint to get a breakpoint on an instruction which is also a >> breakpoint in the guest? > > I think in this case host debugging just wins. > ok -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
