Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 07 7月, 2016 1 次提交
  3. 27 6月, 2016 2 次提交
  5. 24 6月, 2016 1 次提交
  7. 17 6月, 2016 1 次提交
    • I
      QMP: Add query-hotpluggable-cpus · d4633541
      由 Igor Mammedov 提交于 
      It will allow mgmt to query present and hotpluggable CPU objects,
it is required from a target platform that wishes to support command
to implement and set MachineClass.query_hotpluggable_cpus callback,
which will return a list of possible CPU objects with options that
would be needed for hotplugging possible CPU objects.

There are:
'type': 'str' - QOM CPU object type for usage with device_add
'vcpus-count': 'int' - number of logical VCPU threads per
                        CPU object (mgmt needs to know)

and a set of optional fields that are to used for hotplugging a CPU
objects and would allows mgmt tools to know what/where it could be
hotplugged;
[node],[socket],[core],[thread]

For present CPUs there is a 'qom-path' field which would allow mgmt to
inspect whatever object/abstraction the target platform considers
as CPU object.
Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NBharata B Rao <bharata@linux.vnet.ibm.com>
Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      d4633541
  9. 16 6月, 2016 2 次提交
  11. 13 6月, 2016 1 次提交
  13. 26 5月, 2016 2 次提交
    • D
      migration: define 'tls-creds' and 'tls-hostname' migration parameters · 69ef1f36
      由 Daniel P. Berrange 提交于 
      Define two new migration parameters to be used with TLS encryption.
The 'tls-creds' parameter provides the ID of an instance of the
'tls-creds' object type, or rather a subclass such as 'tls-creds-x509'.
Providing these credentials will enable use of TLS on the migration
data stream.

If using x509 certificates, together with a migration URI that does
not include a hostname, the 'tls-hostname' parameter provides the
hostname to use when verifying the server's x509 certificate. This
allows TLS to be used in combination with fd: and exec: protocols
where a TCP connection is established by a 3rd party outside of
QEMU.

NB, this requires changing the migrate_set_parameter method in the
HMP to accept a 's' (string) value instead of 'i' (integer). This
is backwards compatible, because the parsing of strings allows the
quotes to be optional, thus any integer is also a valid string.
Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Message-Id: <1461751518-12128-26-git-send-email-berrange@redhat.com>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
      69ef1f36
    • D
      migration: add reporting of errors for outgoing migration · d59ce6f3
      由 Daniel P. Berrange 提交于 
      Currently if an application initiates an outgoing migration,
it may or may not, get an error reported back on failure. If
the error occurs synchronously to the 'migrate' command
execution, the client app will see the error message. This
is the case for DNS lookup failures. If the error occurs
asynchronously to the monitor command though, the error
will be thrown away and the client left guessing about
what went wrong. This is the case for failure to connect
to the TCP server (eg due to wrong port, or firewall
rules, or other similar errors).

In the future we'll be adding more scope for errors to
happen asynchronously with the TLS protocol handshake.
TLS errors are hard to diagnose even when they are well
reported, so discarding errors entirely will make it
impossible to debug TLS connection problems.

Management apps which do migration are already using
'query-migrate' / 'info migrate' to check up on progress
of background migration operations and to see their end
status. This is a fine place to also include the error
message when things go wrong.

This patch thus adds an 'error-desc' field to the
MigrationInfo struct, which will be populated when
the 'status' is set to 'failed':

(qemu) migrate -d tcp:localhost:9001
(qemu) info migrate
capabilities: xbzrle: off rdma-pin-all: off auto-converge: off zero-blocks: off compress: off events: off x-postcopy-ram: off
Migration status: failed (Error connecting to socket: Connection refused)
total time: 0 milliseconds

In the HMP, when doing non-detached migration, it is
also possible to display this error message directly
to the app.

(qemu) migrate tcp:localhost:9001
Error connecting to socket: Connection refused

Or with QMP

  {
    "execute": "query-migrate",
    "arguments": {}
  }
  {
    "return": {
      "status": "failed",
      "error-desc": "address resolution failed for myhost:9000: No address associated with hostname"
    }
  }
Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Reviewed-by: NJuan Quintela <quintela@redhat.com>
Message-Id: <1461751518-12128-11-git-send-email-berrange@redhat.com>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
      d59ce6f3
  15. 23 5月, 2016 1 次提交
  17. 01 4月, 2016 1 次提交
  19. 31 3月, 2016 1 次提交
    • P
      arm: qmp: add query-gic-capabilities interface · ae50a770
      由 Peter Xu 提交于 
      This patch add "query-gic-capabilities" but does not implement it. The
command is ARM-only. The command will return a list of GICCapability
structs that describes all GIC versions that current QEMU and system
support.

Libvirt is possibly the first consumer of this new command.

Before this patch, a libvirt user can successfully configure all kinds
of GIC devices for ARM guests, no matter whether current QEMU/kernel
supports them. If the specified GIC version/type is not supported, the
user will get an ambiguous "QEMU boot failure" error when trying to start
the VM. This is not user-friendly.

With this patch, libvirt should be able to query which type (and which
version) of GIC device is supported. Using this information, libvirt
can warn the user during configuration of guests when specified GIC
device type is not supported. Or better, we can just list those versions
that we support, and filter out the unsupported ones.

For example, if we got the query result:

{"return": [{"emulated": false, "version": 3, "kernel": true},
            {"emulated": true, "version": 2, "kernel": false}]}

then it means that we support emulated GIC version 2 using:

  qemu-system-aarch64 -M virt,accel=tcg,gic-version=2 ...

or KVM-accelerated GIC version 3 using:

  qemu-system-aarch64 -M virt,accel=kvm,gic-version=3 ...

If we specify other explicit GIC versions rather than the above, QEMU
will not be able to boot.

The community is working on a more generic way to query these kinds of
information about valid values of machine properties. However, due to
the importance of supporting this specific use case, weecided to first
implement this ad-hoc one; then when the generic method is ready, we
can move on to that one smoothly.
Signed-off-by: NPeter Xu <peterx@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Message-id: 1458788142-17509-2-git-send-email-peterx@redhat.com
[PMM: tweaked commit message a bit; monitor.o is CONFIG_SOFTMMU only]
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      ae50a770
  21. 29 3月, 2016 1 次提交
  23. 23 3月, 2016 1 次提交
  25. 18 3月, 2016 1 次提交
    • E
      qapi: Use anonymous bases in QMP flat unions · 3666a97f
      由 Eric Blake 提交于 
      Now that the generator supports it, we might as well use an
anonymous base rather than breaking out a single-use Base
structure, for all three of our current QMP flat unions.

Oddly enough, this change does not affect the resulting
introspection output (because we already inline the members of
a base type into an object, and had no independent use of the
base type reachable from a command).

The case_whitelist now has to list the name of an implicit
type; which is not too bad (consider it a feature if it makes
it harder for developers to make the whitelist grow :)
Signed-off-by: NEric Blake <eblake@redhat.com>
Message-Id: <1458254921-17042-16-git-send-email-eblake@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      3666a97f
  27. 15 3月, 2016 1 次提交
  29. 11 3月, 2016 1 次提交
  31. 05 3月, 2016 1 次提交
  33. 01 3月, 2016 4 次提交
  35. 23 2月, 2016 3 次提交
  37. 26 1月, 2016 1 次提交
    • D
      char: introduce support for TLS encrypted TCP chardev backend · a8fb5427
      由 Daniel P. Berrange 提交于 
      This integrates support for QIOChannelTLS object in the TCP
chardev backend. If the 'tls-creds=NAME' option is passed with
the '-chardev tcp' argument, then it will setup the chardev
such that the client is required to establish a TLS handshake
when connecting. There is no support for checking the client
certificate against ACLs in this initial patch. This is pending
work to QOM-ify the ACL object code.

A complete invocation to run QEMU as the server for a TLS
encrypted serial dev might be

  $ qemu-system-x86_64 \
      -nodefconfig -nodefaults -device sga -display none \
      -chardev socket,id=s0,host=127.0.0.1,port=9000,tls-creds=tls0,server \
      -device isa-serial,chardev=s0 \
      -object tls-creds-x509,id=tls0,endpoint=server,verify-peer=off,\
         dir=/home/berrange/security/qemutls

To test with the gnutls-cli tool as the client:

  $ gnutls-cli --priority=NORMAL -p 9000 \
       --x509cafile=/home/berrange/security/qemutls/ca-cert.pem \
       127.0.0.1

If QEMU was told to use 'anon' credential type, then use the
priority string 'NORMAL:+ANON-DH' with gnutls-cli

Alternatively, if setting up a chardev to operate as a client,
then the TLS credentials registered must be for the client
endpoint. First a TLS server must be setup, which can be done
with the gnutls-serv tool

  $ gnutls-serv --priority=NORMAL -p 9000 --echo \
       --x509cafile=/home/berrange/security/qemutls/ca-cert.pem \
       --x509certfile=/home/berrange/security/qemutls/server-cert.pem \
       --x509keyfile=/home/berrange/security/qemutls/server-key.pem

Then QEMU can connect with

  $ qemu-system-x86_64 \
      -nodefconfig -nodefaults -device sga -display none \
      -chardev socket,id=s0,host=127.0.0.1,port=9000,tls-creds=tls0 \
      -device isa-serial,chardev=s0 \
      -object tls-creds-x509,id=tls0,endpoint=client,\
        dir=/home/berrange/security/qemutls
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Message-Id: <1453202071-10289-5-git-send-email-berrange@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      a8fb5427
  39. 16 1月, 2016 1 次提交
    • D
      qemu-char: add logfile facility to all chardev backends · d0d7708b
      由 Daniel P. Berrange 提交于 
      Typically a UNIX guest OS will log boot messages to a serial
port in addition to any graphical console. An admin user
may also wish to use the serial port for an interactive
console. A virtualization management system may wish to
collect system boot messages by logging the serial port,
but also wish to allow admins interactive access.

Currently providing such a feature forces the mgmt app
to either provide 2 separate serial ports, one for
logging boot messages and one for interactive console
login, or to proxy all output via a separate service
that can multiplex the two needs onto one serial port.
While both are valid approaches, they each have their
own downsides. The former causes confusion and extra
setup work for VM admins creating disk images. The latter
places an extra burden to re-implement much of the QEMU
chardev backends logic in libvirt or even higher level
mgmt apps and adds extra hops in the data transfer path.

A simpler approach that is satisfactory for many use
cases is to allow the QEMU chardev backends to have a
"logfile" property associated with them.

 $QEMU -chardev socket,host=localhost,port=9000,\
                server=on,nowait,id-charserial0,\
		logfile=/var/log/libvirt/qemu/test-serial0.log
       -device isa-serial,chardev=charserial0,id=serial0

This patch introduces a 'ChardevCommon' struct which
is setup as a base for all the ChardevBackend types.
Ideally this would be registered directly as a base
against ChardevBackend, rather than each type, but
the QAPI generator doesn't allow that since the
ChardevBackend is a non-discriminated union. The
ChardevCommon struct provides the optional 'logfile'
parameter, as well as 'logappend' which controls
whether QEMU truncates or appends (default truncate).
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Message-Id: <1452516281-27519-1-git-send-email-berrange@redhat.com>
[Call qemu_chr_parse_common if cd->parse is NULL. - Paolo]
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      d0d7708b
  41. 15 1月, 2016 1 次提交
  43. 19 12月, 2015 1 次提交
  45. 18 12月, 2015 1 次提交
  47. 17 12月, 2015 1 次提交
    • E
      cpu: Convert CpuInfo into flat union · 86f4b687
      由 Eric Blake 提交于 
      The CpuInfo struct is used only by the 'query-cpus' output
command, so we are free to modify it by adding fields (clients
are already supposed to ignore unknown output fields), or by
changing optional members to mandatory, while still keeping
QMP wire compatibility with older versions of qemu.

When qapi type CpuInfo was originally created for 0.14, we had
no notion of a flat union, and instead just listed a bunch of
optional fields with documentation about the mutually-exclusive
choice of which instruction pointer field(s) would be provided
for a given architecture.  But now that we have flat unions and
introspection, it is better to segregate off which fields will
be provided according to the actual architecture.  With this in
place, we no longer need the fields to be optional, because the
choice of the new 'arch' discriminator serves that role.

This has an additional benefit: the old all-in-one struct was
the only place in the code base that had a case-sensitive
naming of members 'pc' vs. 'PC'.  Separating these spellings
into different branches of the flat union will allow us to add
restrictions against future case-insensitive collisions, since
that is generally a poor interface practice.
Signed-off-by: NEric Blake <eblake@redhat.com>
Message-Id: <1447836791-369-25-git-send-email-eblake@redhat.com>
[Spelling of CPUInfo{SPARC,PPC,MIPS} fixed]
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      86f4b687
  49. 17 11月, 2015 1 次提交
    • E
      input: Document why x-input-send-event is still experimental · 513e7cdb
      由 Eric Blake 提交于 
      The x-input-send-event command was introduced in 2.2 with mention
that it is experimental, but now that several releases have elapsed
without any changes, it would be nice to document why that was done
and should still remain experimental in 2.5.

Meanwhile, our documentation states that we prefer 'lower-case',
rather than 'CamelCase', for qapi enum values.  The InputButton and
InputAxis enums violate this convention.  However, because they are
currently used primarily for generating code that is used internally;
and their only exposure through QMP is via the experimental
'x-input-send-event' command, we are free to change their spelling.
Of course, it would be nicer to delay such a change until the same
time we promote the command to non-experimental.  Adding
documentation will help us remember to do that rename.

We have plans to tighten the qapi generator to flag instances of
inconsistent use of naming conventions; if that lands first, it
will just need to whitelist these exceptions until the time we
settle on the final interface.

Fix a typo in the docs for InputAxis while at it.
Signed-off-by: NEric Blake <eblake@redhat.com>
Message-Id: <1447354243-31825-1-git-send-email-eblake@redhat.com>
Reviewed-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      513e7cdb
  51. 13 11月, 2015 1 次提交
  53. 12 11月, 2015 2 次提交
  55. 11 11月, 2015 3 次提交
  57. 10 11月, 2015 1 次提交