Re: [Qemu-devel] Re: [RESEND][PATCH] gdbstub: Add vCont support

[Jan Kiszka]

Jan Kiszka wrote:
> Paul Brook wrote:
>>>  a) Modeling cpus as processes buys us nothing compared to threads given
>>>     the fact that we cannot provide a stable memory mapping to the gdb
>>>     frontend anyway. (*)
>> I disagree. The process model fits perfectly. The whole point is that each 
>> CPU 
>> has its own virtual address space. Separate address spaces is the 
>> fundamental 
>> difference between a process and a thread.
>>
>> If you have a multicore system where several cores share a MMU[1] then 
>> modelling these as threads probably make sense.
>>
>> Don't confuse this with OS awareness in GDB (i.e. implementing a userspace 
>> debug environment via a bare metal kernel level debug interface). That's a 
>> completely separate issue.
> 
> You snipped away my argument under (*):
> 
>> (*) Process abstraction is, if used at all, guest business. At best we
>> could try to invent (likely OS-specific) heuristics to identify
>> identical mappings and call them processes. I don't see a reasonable
>> benefit compared to the expected effort and unreliability.
> 
> You cannot simply assign some CPU n to a virtual process n because the
> mapping you see on that CPU at some point in time may next pop up on
> some other CPU - and vice versa. You start to make gdb believe it sees
> consistent processes while you have no clue at all about the scheduling
> of your guest. So what do you gain?
> 
> I can tell you what you loose: If gdb starts to think that there are n
> separate processes, you will have to set separate breakpoints as well.
> Bad. And if some breakpoint assigned to process n suddenly hits you on
> process (CPU) m, only chaos is the result. E.g. kvm would re-inject it
> as guest-originated. Even worse.
> 
>>>  b) The model is already part of mainline qemu. This patch is just
>>>     about adding even more usefulness to it.
>> I have no problems with ripping out the bogus "thread" support once (or even 
>> before) proper process support is implemented.  Likewise I've no problem 
>> requiring a recent GDB if you want to do multicore debugging.
> 
> There was zero practical need for this so far. But maybe you can
> describe a _concrete_ debugging use case and the related steps in gdb -
> based on a potential process interface. I'm surely willing to learn
> about it if there is really such a great practical improvement feasible.
> What will be the user's benefit?

Maybe, if there are OSes in the field where a process model fits (surely
not Linux), we could find the compromise to add alternative support for
that model and let the user decide which one to use via some command
line switch or maintenance command. There are still a few 'ifs' for me
in this equation, including that gdb properly supports the model. But if
they can be removed, I'm surely open for such enhancements!

For now I would be very glad if we could agree on completing the thread
model implementation so that users can benefit from it without having to
patch qemu or kvm.

Jan

signature.asc
Description: OpenPGP digital signature