Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

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

切换分支/标签
  1. 01 3月, 2016 3 次提交
  3. 23 2月, 2016 3 次提交
  5. 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
  7. 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
  9. 15 1月, 2016 1 次提交
  11. 19 12月, 2015 1 次提交
  13. 18 12月, 2015 1 次提交
  15. 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
  17. 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
  19. 13 11月, 2015 1 次提交
  21. 12 11月, 2015 2 次提交
  23. 11 11月, 2015 3 次提交
  25. 10 11月, 2015 3 次提交
  27. 05 11月, 2015 1 次提交
  29. 02 11月, 2015 1 次提交
  31. 20 10月, 2015 1 次提交
  33. 15 10月, 2015 1 次提交
    • E
      qapi: Lazy creation of array types · 9f08c8ec
      由 Eric Blake 提交于 
      Commit ac88219a had several TODO markers about whether we needed
to automatically create the corresponding array type alongside
any other type.  It turns out that most of the time, we don't!

There are a few exceptions: 1) We have a few situations where we
use an array type in internal code but do not expose that type
through QMP; fix it by declaring a dummy type that forces the
generator to see that we want to use the array type.

2) The builtin arrays (such as intList for QAPI ['int']) must
always be generated, because of the way our QAPI_TYPES_BUILTIN
compile guard works: we have situations (at the very least
tests/test-qmp-output-visitor.c) that include both top-level
"qapi-types.h" (via "error.h") and a secondary
"test-qapi-types.h". If we were to only emit the builtin types
when used locally, then the first .h file would not include all
types, but the second .h does not declare anything at all because
the first .h set QAPI_TYPES_BUILTIN, and we would end up with
compilation error due to things like unknown type 'int8List'.

Actually, we may need to revisit how we do type guards, and
change from a single QAPI_TYPES_BUILTIN over to a different
usage pattern that does one #ifdef per qapi type - right now,
the only types that are declared multiple times between two qapi
.json files for inclusion by a single .c file happen to be the
builtin arrays.  But now that we have QAPI 'include' statements,
it is logical to assume that we will soon reach a point where
we want to reuse non-builtin types (yes, I'm thinking about what
it will take to add introspection to QGA, where we will want to
reuse the SchemaInfo type and friends).  One #ifdef per type
will help ensure that generating the same qapi type into more
than one qapi-types.h won't cause collisions when both are
included in the same .c file; but we also have to solve how to
avoid creating duplicate qapi-types.c entry points.  So that
is a problem left for another day.

Generated code for qapi-types and qapi-visit is drastically
reduced; less than a third of the arrays that were blindly
created were actually needed (a quick grep shows we dropped
from 219 to 69 *List types), and the .o files lost more than
30% of their bulk.  [For best results, diff the generated
files with 'git diff --patience --no-index pre post'.]

Interestingly, the introspection output is unchanged - this is
because we already cull all types that are not indirectly
reachable from a command or event, so introspection was already
using only a subset of array types.  The subset of types
introspected is now a much larger percentage of the overall set
of array types emitted in qapi-types.h (since the larger set
shrunk), but still not 100% (evidence that the array types
emitted for our new Dummy structs, and the new struct itself,
don't affect QMP).
Signed-off-by: NEric Blake <eblake@redhat.com>
Message-Id: <1444710158-8723-9-git-send-email-eblake@redhat.com>
[Moved array info tracking to a later patch]
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      9f08c8ec
  35. 12 10月, 2015 1 次提交
  37. 30 9月, 2015 2 次提交
  39. 24 9月, 2015 1 次提交
  41. 22 9月, 2015 1 次提交
    • D
      monitor: allow device_del to accept QOM paths · 6287d827
      由 Daniel P. Berrange 提交于 
      Currently device_del requires that the client provide the
device short ID. device_add allows devices to be created
without giving an ID, at which point there is no way to
delete them with device_del. The QOM object path, however,
provides an alternative way to identify the devices.

Allowing device_del to accept an object path ensures all
devices are deletable regardless of whether they have an
ID.

 (qemu) device_add usb-mouse
 (qemu) qom-list /machine/peripheral-anon
 device[0] (child<usb-mouse>)
 type (string)
 (qemu) device_del /machine/peripheral-anon/device[0]

Devices are required to be marked as hotpluggable
otherwise an error is raised

 (qemu) device_del /machine/unattached/device[4]
 Device 'PIIX3' does not support hotplugging
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Message-Id: <1441974836-17476-1-git-send-email-berrange@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
[Commit message touched up, accidental white-space change dropped]
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      6287d827
  43. 21 9月, 2015 3 次提交
    • M
      qapi: New QMP command query-qmp-schema for QMP introspection · 39a18158
      由 Markus Armbruster 提交于 
      qapi/introspect.json defines the introspection schema.  It's designed
for QMP introspection, but should do for similar uses, such as QGA.

The introspection schema does not reflect all the rules and
restrictions that apply to QAPI schemata.  A valid QAPI schema has an
introspection value conforming to the introspection schema, but the
converse is not true.

Introspection lowers away a number of schema details, and makes
implicit things explicit:

* The built-in types are declared with their JSON type.

  All integer types are mapped to 'int', because how many bits we use
  internally is an implementation detail.  It could be pressed into
  external interface service as very approximate range information,
  but that's a bad idea.  If we need range information, we better do
  it properly.

* Implicit type definitions are made explicit, and given
  auto-generated names:

  - Array types, named by appending "List" to the name of their
    element type, like in generated C.

  - The enumeration types implicitly defined by simple union types,
    named by appending "Kind" to the name of their simple union type,
    like in generated C.

  - Types that don't occur in generated C.  Their names start with ':'
    so they don't clash with the user's names.

* All type references are by name.

* The struct and union types are generalized into an object type.

* Base types are flattened.

* Commands take a single argument and return a single result.

  Dictionary argument or list result is an implicit type definition.

  The empty object type is used when a command takes no arguments or
  produces no results.

  The argument is always of object type, but the introspection schema
  doesn't reflect that.

  The 'gen': false directive is omitted as implementation detail.

  The 'success-response' directive is omitted as well for now, even
  though it's not an implementation detail, because it's not used by
  QMP.

* Events carry a single data value.

  Implicit type definition and empty object type use, just like for
  commands.

  The value is of object type, but the introspection schema doesn't
  reflect that.

* Types not used by commands or events are omitted.

  Indirect use counts as use.

* Optional members have a default, which can only be null right now

  Instead of a mandatory "optional" flag, we have an optional default.
  No default means mandatory, default null means optional without
  default value.  Non-null is available for optional with default
  (possible future extension).

* Clients should *not* look up types by name, because type names are
  not ABI.  Look up the command or event you're interested in, then
  follow the references.

  TODO Should we hide the type names to eliminate the temptation?

New generator scripts/qapi-introspect.py computes an introspection
value for its input, and generates a C variable holding it.

It can generate awfully long lines.  Marked TODO.

A new test-qmp-input-visitor test case feeds its result for both
tests/qapi-schema/qapi-schema-test.json and qapi-schema.json to a
QmpInputVisitor to verify it actually conforms to the schema.

New QMP command query-qmp-schema takes its return value from that
variable.  Its reply is some 85KiBytes for me right now.

If this turns out to be too much, we have a couple of options:

* We can use shorter names in the JSON.  Not the QMP style.

* Optionally return the sub-schema for commands and events given as
  arguments.

  Right now qmp_query_schema() sends the string literal computed by
  qmp-introspect.py.  To compute sub-schema at run time, we'd have to
  duplicate parts of qapi-introspect.py in C.  Unattractive.

* Let clients cache the output of query-qmp-schema.

  It changes only on QEMU upgrades, i.e. rarely.  Provide a command
  query-qmp-schema-hash.  Clients can have a cache indexed by hash,
  and re-query the schema only when they don't have it cached.  Even
  simpler: put the hash in the QMP greeting.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
      39a18158
    • M
      qapi-schema: Fix up misleading specification of netdev_add · b8a98326
      由 Markus Armbruster 提交于 
      It doesn't take a 'props' argument, let alone one in the format
"NAME=VALUE,..."

The bogus arguments specification doesn't matter due to 'gen': false.
Clean it up to be incomplete rather than wrong, and document the
incompleteness.

While there, improve netdev_add usage example in the manual: add a
device option to show how it's done.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
Message-Id: <1442401589-24189-24-git-send-email-armbru@redhat.com>
      b8a98326
    • M
      qom: Don't use 'gen': false for qom-get, qom-set, object-add · 6eb3937e
      由 Markus Armbruster 提交于 
      With the previous commit, the generated marshalers just work, and save
us a bit of handwritten code.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
Message-Id: <1442401589-24189-23-git-send-email-armbru@redhat.com>
      6eb3937e
  45. 15 9月, 2015 1 次提交
    • D
      crypto: introduce new base module for TLS credentials · a090187d
      由 Daniel P. Berrange 提交于 
      Introduce a QCryptoTLSCreds class to act as the base class for
storing TLS credentials. This will be later subclassed to provide
handling of anonymous and x509 credential types. The subclasses
will be user creatable objects, so instances can be created &
deleted via 'object-add' and 'object-del' QMP commands respectively,
or via the -object command line arg.

If the credentials cannot be initialized an error will be reported
as a QMP reply, or on stderr respectively.

The idea is to make it possible to represent and manage TLS
credentials independently of the network service that is using
them. This will enable multiple services to use the same set of
credentials and minimize code duplication. A later patch will
convert the current VNC server TLS code over to use this object.

The representation of credentials will be functionally equivalent
to that currently implemented in the VNC server with one exception.
The new code has the ability to (optionally) load a pre-generated
set of diffie-hellman parameters, if the file dh-params.pem exists,
whereas the current VNC server will always generate them on startup.
This is beneficial for admins who wish to avoid the (small) time
sink of generating DH parameters at startup and/or avoid depleting
entropy.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      a090187d
  47. 11 9月, 2015 1 次提交
  49. 03 9月, 2015 1 次提交
  51. 28 7月, 2015 1 次提交
  53. 20 7月, 2015 1 次提交
  55. 07 7月, 2015 1 次提交