On 5/27/20 6:49 AM, Markus Armbruster wrote: > Philippe Mathieu-Daudé <phi...@redhat.com> writes: > >> On 5/26/20 11:31 AM, Philippe Mathieu-Daudé wrote: >>> +Laurent >>> >>> On 5/26/20 11:04 AM, Markus Armbruster wrote: >>>> Philippe Mathieu-Daudé <phi...@redhat.com> writes: >>>> >>>>> On 5/26/20 9:38 AM, Markus Armbruster wrote: >>>>>> Philippe Mathieu-Daudé <phi...@redhat.com> writes: >>>>>> >>>>>>> Signed-off-by: Philippe Mathieu-Daudé <phi...@redhat.com> >>>>>> >>>>>> A brief note on why restricting "to machine code" is useful would be >>>>>> nice. Same for the other patches. >>>>>> >>>>>> Acked-by: Markus Armbruster <arm...@redhat.com> >>>>>> >>>>> >>>>> What about this? >>>>> >>>>> "QEMU can do system-mode and user-mode emulation. >>>>> Only system mode emulate a machine. >>>>> Remove this feature from the user-mode emulation." >>>> >>>> Is is a feature of user-mode emulation before the patch? Or is it just >>>> dead code? >>>> >>>> Hint: QMP commands tend to be dead code when the program doesn't expose >>>> a QMP monitor :) >>> >>> Maybe a 'corollary' question, "How user-mode users use QMP?" >>> >> >> I can't find a way to start a user-mode process with a QMP socket, is >> there one? > > As far as I can tell, only qemu-system-FOO and qemu-storage-daemon > provide QMP monitors: > > * Monitors need to be initialized with monitor_init(). Two callers: > monitor_init_hmp(), monitor_init_qmp(). > > * monitor_init() calls both, and is the common wat to create a monitor. > Called by vl.c via monitor_init_opts(), and by qemu-storage-daemon. > > * monitor_init_hmp() has additional callers, but HMP doesn't matter > here. >
OK good to know. I'll reword the patch description, but also check if there isn't a simpler way to avoid pulling QMP code in user-mode builds first. Thanks! Phil.