From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=50144 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PGa34-0005Pt-AF for qemu-devel@nongnu.org; Thu, 11 Nov 2010 11:30:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PGa33-0007hR-Ax for qemu-devel@nongnu.org; Thu, 11 Nov 2010 11:30:54 -0500 Received: from mail-yw0-f45.google.com ([209.85.213.45]:62477) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PGa33-0007hE-8D for qemu-devel@nongnu.org; Thu, 11 Nov 2010 11:30:53 -0500 Received: by ywh2 with SMTP id 2so94959ywh.4 for ; Thu, 11 Nov 2010 08:30:52 -0800 (PST) Message-ID: <4CDC1A37.9020306@codemonkey.ws> Date: Thu, 11 Nov 2010 10:30:47 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/3] QMP: Introduce Human Monitor passthrough command References: <1288362514-31407-1-git-send-email-lcapitulino@redhat.com> <1288362514-31407-3-git-send-email-lcapitulino@redhat.com> <20101110113637.05d5a202@doriath> <20101111155555.GM22152@redhat.com> In-Reply-To: <20101111155555.GM22152@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: aliguori@us.ibm.com, Luiz Capitulino , Markus Armbruster , qemu-devel@nongnu.org On 11/11/2010 09:55 AM, Daniel P. Berrange wrote: > On Thu, Nov 11, 2010 at 04:47:41PM +0100, Markus Armbruster wrote: > >> Luiz Capitulino writes: >> >> >>> On Wed, 10 Nov 2010 14:20:12 +0100 >>> Markus Armbruster wrote: >>> >>> >>>> Luiz Capitulino writes: >>>> >> [...] >> >>>>> diff --git a/qmp-commands.hx b/qmp-commands.hx >>>>> index 793cf1c..b344096 100644 >>>>> --- a/qmp-commands.hx >>>>> +++ b/qmp-commands.hx >>>>> @@ -761,6 +761,51 @@ Example: >>>>> >>>>> Note: This command must be issued before issuing any other command. >>>>> >>>>> +EQMP >>>>> + >>>>> + { >>>>> + .name = "hmp_passthrough", >>>>> + .args_type = "command-line:s,cpu-index:i?", >>>>> + .params = "", >>>>> + .help = "", >>>>> + .user_print = monitor_user_noop, >>>>> + .mhandler.cmd_new = do_hmp_passthrough, >>>>> + }, >>>>> + >>>>> +SQMP >>>>> +hmp_passthrough >>>>> +--------------- >>>>> + >>>>> +Execute a Human Monitor command. >>>>> + >>>>> +Arguments: >>>>> + >>>>> +- command-line: the command name and its arguments, just like the >>>>> + Human Monitor's shell (json-string) >>>>> +- cpu-index: select the CPU number to be used by commands which access CPU >>>>> + data, like 'info registers'. The Monitor selects CPU 0 if this >>>>> + argument is not provided (json-int, optional) >>>>> + >>>>> +Example: >>>>> + >>>>> +-> { "execute": "hmp_passthrough", "arguments": { "command-line": "info kvm" } } >>>>> +<- { "return": "kvm support: enabled\r\n" } >>>>> + >>>>> +Notes: >>>>> + >>>>> +(1) The Human Monitor is NOT an stable interface, this means that command >>>>> + names, arguments and responses can change or be removed at ANY time. >>>>> + Applications that rely on long term stability guarantees should NOT >>>>> + use this command >>>>> + >>>>> +(2) Limitations: >>>>> + >>>>> + o This command is stateless, this means that commands that depend >>>>> + on state information (such as getfd) might not work >>>>> + >>>>> + o Commands that prompt the user for data (eg. 'cont' when the block >>>>> + device is encrypted) don't currently work >>>>> + >>>>> 3. Query Commands >>>>> ================= >>>>> >>>> In the real human monitor, cpu-index is state (Monitor member mon_cpu). >>>> For pass through, you shift that state into the client (argument >>>> cpu-index). Is there any other state that could need shifting? You >>>> mention getfd. >>>> >>> Surprisingly or not, this is a very important question for QMP itself. >>> >>> Anthony has said that we should make it stateless, and I do think this >>> is good because it seems to simplify things considerably. >>> >>> However, I haven't thought about how to make things like getfd stateless. >>> >> Hmm, that sounds like we should investigate the getfd problem sooner >> rather than later. >> > The SCM_RIGHTS code allows you to send/receive multiple file handles in a > single sendmsg/recvmsg call. So why don't we just allow sending of the > file handles with the monitor command that actually needs them, instead of > ahead of time using send_fd. This simplifies life for the client because > they also don't have to worry about cleanup using close_fd if the command > using the FD fails. > How do we identify file descriptors and then map them to a command? Regards, Anthony Liguori > Regards, > Daniel >