[Qemu-devel] Re: [PATCH 11/11] QMP: Command-line flag to enable control mode

[Jan Kiszka <jan.kiszka@siemens.com>]

Avi Kivity wrote:
> On 06/23/2009 01:54 PM, Jan Kiszka wrote:
>>> It would be a nightmare, consider both libvirt and a user hotplugging
>>> something into the same pci slot, or a user starting migration, or
>>> quitting, or ...
>>>      
>>
>> Migration, yes, but hot-plugging is resolvable - given config update
>> events.
>>    
> 
> I'm not saying it's impossible, just that we don't want to do it.

I agree it's not something that is mandatory for the first versions, but
disagree that we should not strive for achieving this level of support
mid- to long-term. No design decision made today should prevent it, but
rather keep that door open. Also for robustness reasons (if you loose
contact to your qemu backend and need to resync the management frontend).

> 
>>> Having -monitor readonly makes sense.
>>>      
>>
>> But not for all features, only those libvirt is capable to handle (I
>> think there are quite a few qemu specifics libvirt does not bother
>> about) and only as long as there is no proper synchronization. Again,
>> migration and save/restore will continue to require exclusive access,
>> but the rest is just a question of proper synchronization IMHO.
>>    
> 
> If libvirt "doesn't bother" about something useful, that's a libvirt
> bug.  It's wierd to have something controlled by two parallel management
> channels.

I think the libvirt policy is that things which are not generic enough
to be supported by >1 hypervisor are left alone.

> 
>> See, I don't want to kill my management app just because I attached to a
>> guest via gdb and start injecting reconfiguration events for testing
>> purposes (e.g. attach/detach a USB device for which I develop a driver).
>>    
> 
> You're talking about a usb developer, not a qemu developer, working in
> some virtual lab environment?  In that case, libvirt and the management
> app should certainly support usb.  A random usb developer shouldn't need
> to ever talk to the qemu monitor.

I'm talking about, just as one example, sitting in front of my gdb
[frontend], doing guest kernel [driver] debugging and issuing "monitor
whatever" commands from one place, ie. not having to switch between
management app and debugging interface back and forth.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux