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.
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?
> 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.
>
>>
>> > However, that's a separate discussion from that of *how* userspace or
>> > the kernel then injects an exception to the guest.
>> >
>> > By using some QEMU TCG functionality or by QEMU calling back into KVM
>> > and asking it to inject an exception for it.
>>
>> I don't know if there is explicit TCG functionality to use but QEMU can
>> set the registers and PC up for exception entry and re-enter KVM.
>>
>
> I also understand this. I think Peter's point was exactly that if we
> have existing code somewhere which we can reuse, then we should consider
> reusing it.
I'm not sure such code exists. The only injection code I know of in KVMs
handle_exit code where a +ve return value signals KVM to deliver the
exception to the guest. This is used by the hvc and svc handlers after
calling kvm_inject_undefined() and the wfx handler which advances the PC
first.
> Again, I don't care particularly which way, I just want the expected
> working behavior to be clearly defined.
I think it makes sense to do it in userspace. I have the kernels
inject_fault code for reference for what needs setting up but I'll see
if I can find anything in QEMU that already handles this for some other
thing (although I don't think it does at first glance).
--
Alex Bennée
--
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
