Luiz Capitulino [Fri, 27 Nov 2009 00:59:09 +0000 (22:59 -0200)]
QMP: Introduce qmp-shell
This is a very simple shell written in Python for demonstration
purposes.
Unfortunately it's a bit awkward right now, as the user has
to specify the arguments names and the printed data can be
a raw dictionary or list, like the following example:
It's worth to note that the shell is broken into two files.
One is the shell itself, the other is the QMP class which
handles the communication with QEMU.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Luiz Capitulino [Fri, 27 Nov 2009 00:59:02 +0000 (22:59 -0200)]
QMP: Allow 'query-' commands
The 'info' command makes sense for the user protocol, but for QMP
it doesn't, as its return data is not well defined. That is, it
can return anything.
To fix this Avi proposes having 'query-' commands when in protocol
mode. For example, 'info balloon' would become 'query-balloon'.
The right way of supporting this would probably be to move all
info handlers to qemu-monitor.hx, add a flags field to mon_cmd_t
to identify them and then modify do_info() to do its search based
on that flag.
Unfortunately, this would require a big change in the Monitor.
To make things simpler for now, this commit takes a different
approach: a check for commands starting with "query-" is added to
toplevel QMP code, if it's true we setup things so that do_info()
is called with the appropriate arguments.
This is a hack, but is a temporary one and guarantees that query-
commands will work from the first day.
Also note that 'info' is not allowed in protocol mode.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Luiz Capitulino [Fri, 27 Nov 2009 00:59:01 +0000 (22:59 -0200)]
QMP: Input support
The JSON stream parser is used to do QMP input. When there
are enough characters to be parsed it calls Monitor's
handle_qmp_command() function to handle the input.
This function's job is to check if the input is correct and
call the appropriate handler. In other words, it does for QMP
what handle_user_command() does for the user protocol.
This means that handle_qmp_command() also has to parse the
(ugly) "args_type" format to able to get the arguments names
and types expected by the handler.
The format to input commands in QMP is as follows:
Luiz Capitulino [Fri, 27 Nov 2009 00:58:59 +0000 (22:58 -0200)]
QMP: Output support
In the new Monitor output is always performed by only two
functions: do_info() and monitor_call_handler().
To support QMP output, we modify those functions to check if we
are in control mode. If so, we call monitor_protocol_emitter()
to emit QMP output, otherwise we do regular output.
QMP has two types of responses to issued commands: success and
error. The outputed data is always a JSON object.
Luiz Capitulino [Fri, 27 Nov 2009 00:58:58 +0000 (22:58 -0200)]
QMP: Initial support
This commit adds initial QMP support in QEMU. It's important
to notice that most QMP code will be part of the Monitor.
Input will be read by monitor_control_read(). Currently it
does nothing but next patches will add proper input support.
The function monitor_json_emitter(), as its name implies, is
used by the Monitor to emit JSON output. In this commit it's
used by monitor_control_event() to print our greeting message.
Finally, control mode support is also added to monitor_init(),
allowing QMP to be really enabled.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Luiz Capitulino [Thu, 19 Nov 2009 01:05:31 +0000 (23:05 -0200)]
monitor: QError support
This commit adds QError support in the Monitor.
A QError member is added to the Monitor struct. This new member
stores error information and is also used to check if an error
has occurred when the called handler returns.
Additionally, a new macro called qemu_error_new() is introduced.
It builds on top of the QemuErrorSink API and should be used in
place of qemu_error().
When all conversion to qemu_error_new() is done, qemu_error() can
be turned private.
Basically, Monitor's error flow is something like this:
1. An error occurs in the handler, it calls qemu_error_new()
2. qemu_error_new() builds a new QError object and stores it in
the Monitor struct
3. The handler returns
4. Top level Monitor code checks the Monitor struct and calls
qerror_print() to print the error
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Luiz Capitulino [Thu, 19 Nov 2009 01:05:30 +0000 (23:05 -0200)]
Introduce QError
QError is a high-level data type which represents an exception
in QEMU, it stores the following error information:
- class Error class name (eg. "ServiceUnavailable")
- description A detailed error description, which can contain
references to run-time error data
- filename The file name of where the error occurred
- line number The exact line number of the error
- function The function name of where the error occurred
- run-time data Any run-time error data
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
linux-user build on fedora 11 breaks because fallocate
is broken on that system if -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
are specified, which is what QEMU uses.
We do have a configure check to catch this and disable fallocate,
however, it turns out that default QEMU_CFLAGS/LDFLAGS were assigned in
script *after* all compiler checks: so during checks we were not running
compiler with same flags that we used for build later.
Fix this by moving QEMU_CFLAGS to before compiler checks, and using
comple_prog when checking for fallocate. This also fixes the fact that
we do some compiler checks while assigning the flags, right below a
comment that says "no cc tests beyond this point".
Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
PCI spec states:
if a masked vector has its Pending bit set, and the associated
underlying interrupt events are somehow satisfied (usually by software
though the exact manner is function-specific), the function must clear
the Pending bit, to avoid sending a spurious interrupt message later
when software unmasks the vector.
In our case this happens if vector becomes unused.
Clear pending bit in this case.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
On reset, we currently clear all bits in msix control register *except*
enable bit. This is wrong: the spec says we should clear writeable
bits: function mask and enable bit.
Correct this.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Isaku Yamahata [Thu, 12 Nov 2009 05:58:41 +0000 (14:58 +0900)]
pci: move typedef, PCIHostState, PCIExpressHost to qemu-common.h.
This patch moves two typedefs, PCIHostState and PCIExpressHost to
qemu-common.h for consistency as PCIBus and PCIDevice are typedefed
in qemu-common.h.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Isaku Yamahata [Thu, 12 Nov 2009 05:58:34 +0000 (14:58 +0900)]
pci: shorten pci_host_{conf, data}_register_xxx function a bit.
pci_host_data_register_io_memory and its variants are too long a bit.
So shorten them. Now they are
pci_host_{conf, data}_register_{mmio, mmio_noswap, ioport}()
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Isaku Yamahata [Thu, 12 Nov 2009 11:17:23 +0000 (13:17 +0200)]
pci: rename (pci_/pcie_mmcfg_)addr_to_dev
This patch renames pci_addr_to_dev(), pcie_mmcfg_addr_to_dev()
to pci_dev_find_by_addr(), pcie_dev_find_by_mmcfg_addr()
as "Michael S. Tsirkin" <mst@redhat.com> suggested.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Isaku Yamahata [Thu, 12 Nov 2009 05:58:30 +0000 (14:58 +0900)]
pci: move pci_data_{read, write}() declaration from pci.h to pci_host.h
Now pci host stuff has been moved from pci.[hc] to pci_host.[hc]
so the declaration of pci_data_{read, write}() should be in
pci_host.h
This patch moves them from pci.h to pci_host.h for consistency.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Aurelien Jarno [Sat, 17 Oct 2009 12:17:47 +0000 (14:17 +0200)]
tcg: initial mips support
Based on a patch from Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org>
A few words about design choices:
* Two registers, at and t0, are reserved for TCG internal use. They are
useful for bswap and 64-bit ops.
* Most ops supports a constant argument with value 0, which is actually
mapped to the zero register.
* While the at register is available for constant loading, ops only
support a limited range of constants. TCG does a better job doing the
register allocation and constant loading by itself. There are plenty of
registers available anyway.