Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

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

切换分支/标签
  1. 29 3月, 2016 1 次提交
  3. 15 3月, 2016 1 次提交
  5. 08 3月, 2016 2 次提交
    • G
      input: linux evdev support · e0d2bd51
      由 Gerd Hoffmann 提交于 
      This patch adds support for reading input events directly from linux
evdev devices and forward them to the guest.  Unlike virtio-input-host
which simply passes on all events to the guest without looking at them
this will interpret the events and feed them into the qemu input
subsystem.

Therefore this is limited to what the qemu input subsystem and the
emulated input devices are able to handle.  Also there is no support for
absolute coordinates (tablet/touchscreen).  So we are talking here about
basic mouse and keyboard support.

The advantage is that it'll work without virtio-input drivers in the
guest, the events are delivered to the usual ps/2 or usb input devices
(depending on what the machine happens to have).  And for keyboards
qemu is able to switch the keyboard between guest and host on hotkey.
The hotkey is hard-coded for now (both control keys), initialy the
guest owns the keyboard.

Probably most useful when assigning vga devices with vfio and using a
physical monitor instead of vnc/spice/gtk as guest display.

Usage:  Add '-input-linux /dev/input/event<nr>' to the qemu command
line.  Note that udev has rules which populate /dev/input/by-{id,path}
with static names, which might be more convinient to use.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Message-id: 1457087116-4379-2-git-send-email-kraxel@redhat.com
      e0d2bd51
    • Z
      filter: Add 'status' property for filter object · 338d3f41
      由 zhanghailiang 提交于 
      With this property, users can control if this filter is 'on'
or 'off'. The default behavior for filter is 'on'.

For some types of filters, they may need to react to status changing,
So here, we introduced status changing callback/notifier for filter class.

We will skip the disabled ('off') filter when delivering packets in net layer.
Signed-off-by: Nzhanghailiang <zhang.zhanghailiang@huawei.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Yang Hongyang <hongyang.yang@easystack.cn>
Signed-off-by: NJason Wang <jasowang@redhat.com>
      338d3f41
  7. 07 3月, 2016 1 次提交
  9. 28 2月, 2016 1 次提交
  11. 23 2月, 2016 1 次提交
    • G
      spice: add opengl/virgl/dmabuf support · 474114b7
      由 Gerd Hoffmann 提交于 
      This adds support for dma-buf passing to spice.  This makes virtio-gpu
with 3d acceleration work with spice.

Workflow:
 * virglrenderer renders the guest command stream into a texture.
 * qemu exports the texture as dma-buf and passes on that dma-buf
   to spice-server.
 * spice-server passes the dma-buf to spice-client, using unix
   socket file descriptor passing.
 * spice-client asks the window systems composer to render the
   dma-buf to the screen.

Requires cutting edge spice (server) and spice-gtk (client) builds,
from git master branch.

Also requires libvirt managing your qemu instance, and using
"virt-viewer --attach $guest".  libvirt will connect spice-server and
spice-client using unix sockets instead of tcp sockets then, which
is required for file descriptor passing.

Works for the local case (spice server and client on the same machine)
only.  Supporting remote too is planned (by feeding the dma-bufs into
gpu-assisted video encoder), but not there yet.

gl mode is turned off by default, use "-spice gl=on,$otherargs" to
enable it.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      474114b7
  13. 20 2月, 2016 1 次提交
  15. 07 2月, 2016 1 次提交
  17. 03 2月, 2016 3 次提交
  19. 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
  21. 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
  23. 23 12月, 2015 2 次提交
  25. 19 12月, 2015 2 次提交
    • D
      crypto: add support for loading encrypted x509 keys · 1d7b5b4a
      由 Daniel P. Berrange 提交于 
      Make use of the QCryptoSecret object to support loading of
encrypted x509 keys. The optional 'passwordid' parameter
to the tls-creds-x509 object type, provides the ID of a
secret object instance that holds the decryption password
for the PEM file.

 # printf "123456" > mypasswd.txt
 # $QEMU \
    -object secret,id=sec0,filename=mypasswd.txt \
    -object tls-creds-x509,passwordid=sec0,id=creds0,\
            dir=/home/berrange/.pki/qemu,endpoint=server \
    -vnc :1,tls-creds=creds0

This requires QEMU to be linked to GNUTLS >= 3.1.11. If
GNUTLS is too old an error will be reported if an attempt
is made to pass a decryption password.
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      1d7b5b4a
    • D
      crypto: add QCryptoSecret object class for password/key handling · ac1d8878
      由 Daniel P. Berrange 提交于 
      Introduce a new QCryptoSecret object class which will be used
for providing passwords and keys to other objects which need
sensitive credentials.

The new object can provide secret values directly as properties,
or indirectly via a file. The latter includes support for file
descriptor passing syntax on UNIX platforms. Ordinarily passing
secret values directly as properties is insecure, since they
are visible in process listings, or in log files showing the
CLI args / QMP commands. It is possible to use AES-256-CBC to
encrypt the secret values though, in which case all that is
visible is the ciphertext.  For ad hoc developer testing though,
it is fine to provide the secrets directly without encryption
so this is not explicitly forbidden.

The anticipated scenario is that libvirtd will create a random
master key per QEMU instance (eg /var/run/libvirt/qemu/$VMNAME.key)
and will use that key to encrypt all passwords it provides to
QEMU via '-object secret,....'.  This avoids the need for libvirt
(or other mgmt apps) to worry about file descriptor passing.

It also makes life easier for people who are scripting the
management of QEMU, for whom FD passing is significantly more
complex.

Providing data inline (insecure, only for ad hoc dev testing)

  $QEMU -object secret,id=sec0,data=letmein

Providing data indirectly in raw format

  printf "letmein" > mypasswd.txt
  $QEMU -object secret,id=sec0,file=mypasswd.txt

Providing data indirectly in base64 format

  $QEMU -object secret,id=sec0,file=mykey.b64,format=base64

Providing data with encryption

  $QEMU -object secret,id=master0,file=mykey.b64,format=base64 \
        -object secret,id=sec0,data=[base64 ciphertext],\
	           keyid=master0,iv=[base64 IV],format=base64

Note that 'format' here refers to the format of the ciphertext
data. The decrypted data must always be in raw byte format.

More examples are shown in the updated docs.
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      ac1d8878
  27. 18 12月, 2015 1 次提交
  29. 06 11月, 2015 1 次提交
  31. 27 10月, 2015 1 次提交
  33. 19 10月, 2015 1 次提交
  35. 12 10月, 2015 1 次提交
  37. 24 9月, 2015 1 次提交
  39. 15 9月, 2015 3 次提交
    • D
      ui: convert VNC server to use QCryptoTLSSession · 3e305e4a
      由 Daniel P. Berrange 提交于 
      Switch VNC server over to using the QCryptoTLSSession object
for the TLS session. This removes the direct use of gnutls
from the VNC server code. It also removes most knowledge
about TLS certificate handling from the VNC server code.
This has the nice effect that all the CONFIG_VNC_TLS
conditionals go away and the user gets an actual error
message when requesting TLS instead of it being silently
ignored.

With this change, the existing configuration options for
enabling TLS with -vnc are deprecated.

Old syntax for anon-DH credentials:

  -vnc hostname:0,tls

New syntax:

  -object tls-creds-anon,id=tls0,endpoint=server \
  -vnc hostname:0,tls-creds=tls0

Old syntax for x509 credentials, no client certs:

  -vnc hostname:0,tls,x509=/path/to/certs

New syntax:

  -object tls-creds-x509,id=tls0,dir=/path/to/certs,endpoint=server,verify-peer=no \
  -vnc hostname:0,tls-creds=tls0

Old syntax for x509 credentials, requiring client certs:

  -vnc hostname:0,tls,x509verify=/path/to/certs

New syntax:

  -object tls-creds-x509,id=tls0,dir=/path/to/certs,endpoint=server,verify-peer=yes \
  -vnc hostname:0,tls-creds=tls0

This aligns VNC with the way TLS credentials are to be
configured in the future for chardev, nbd and migration
backends. It also has the benefit that the same TLS
credentials can be shared across multiple VNC server
instances, if desired.

If someone uses the deprecated syntax, it will internally
result in the creation of a 'tls-creds' object with an ID
based on the VNC server ID. This allows backwards compat
with the CLI syntax, while still deleting all the original
TLS code from the VNC server.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      3e305e4a
    • D
      crypto: introduce new module for TLS x509 credentials · 85bcbc78
      由 Daniel P. Berrange 提交于 
      Introduce a QCryptoTLSCredsX509 class which is used to
manage x509 certificate TLS credentials. This will be
the preferred credential type offering strong security
characteristics

Example CLI configuration:

 $QEMU -object tls-creds-x509,id=tls0,endpoint=server,\
               dir=/path/to/creds/dir,verify-peer=yes

The 'id' value in the -object args will be used to associate the
credentials with the network services. For example, when the VNC
server is later converted it would use

 $QEMU -object tls-creds-x509,id=tls0,.... \
       -vnc 127.0.0.1:1,tls-creds=tls0
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
      85bcbc78
    • D
      crypto: introduce new module for TLS anonymous credentials · e00adf6c
      由 Daniel P. Berrange 提交于 
      Introduce a QCryptoTLSCredsAnon class which is used to
manage anonymous TLS credentials. Use of this class is
generally discouraged since it does not offer strong
security, but it is required for backwards compatibility
with the current VNC server implementation.

Simple example CLI configuration:

 $QEMU -object tls-creds-anon,id=tls0,endpoint=server

Example using pre-created diffie-hellman parameters

 $QEMU -object tls-creds-anon,id=tls0,endpoint=server,\
               dir=/path/to/creds/dir

The 'id' value in the -object args will be used to associate the
credentials with the network services. For example, when the VNC
server is later converted it would use

 $QEMU -object tls-creds-anon,id=tls0,.... \
       -vnc 127.0.0.1:1,tls-creds=tls0
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
      e00adf6c
  41. 11 9月, 2015 2 次提交
  43. 10 9月, 2015 1 次提交
  45. 07 9月, 2015 1 次提交
  47. 24 7月, 2015 1 次提交
  49. 20 7月, 2015 1 次提交
  51. 02 7月, 2015 2 次提交
    • P
      block/iscsi: restore compatiblity with libiscsi 1.9.0 · 9049736e
      由 Peter Lieven 提交于 
      RHEL7 and others are stuck with libiscsi 1.9.0 since there
unfortunately was an ABI breakage after that release.
Signed-off-by: NPeter Lieven <pl@kamp.de>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Message-id: 1435313881-19366-1-git-send-email-pl@kamp.de
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      9049736e
    • P
      block/iscsi: add support for request timeouts · 5dd7a535
      由 Peter Lieven 提交于 
      libiscsi starting with 1.15 will properly support timeout of iscsi
commands. The default will remain no timeout, but this can
be changed via cmdline parameters, e.g.:

qemu -iscsi timeout=30 -drive file=iscsi://...

If a timeout occurs a reconnect is scheduled and the timed out command
will be requeued for processing after a successful reconnect.

The required API call iscsi_set_timeout is present since libiscsi
1.10 which was released in October 2013. However, due to some bugs
in the libiscsi code the use is not recommended before version 1.15.

Please note that this patch bumps the libiscsi requirement to 1.10
to have all function and macros defined. The patch fixes also a
off-by-one error in the NOP timeout calculation which was fixed
while touching these code parts.
Signed-off-by: NPeter Lieven <pl@kamp.de>
Message-id: 1434455107-19328-1-git-send-email-pl@kamp.de
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      5dd7a535
  53. 26 6月, 2015 1 次提交
  55. 24 6月, 2015 2 次提交
  57. 20 6月, 2015 1 次提交
  59. 19 6月, 2015 1 次提交
    • L
      semihosting: add --semihosting-config arg sub-argument · a59d31a1
      由 Leon Alrae 提交于 
      Add new "arg" sub-argument to the --semihosting-config allowing the user
to pass multiple input arguments separately. It is required for example
by UHI semihosting to construct argc and argv.

Also, update ARM semihosting to support new option (at the moment it is
the only target which cares about arguments).

If the semihosting is enabled and no semihosting args have been specified,
then fall back to -kernel/-append. The -append string is split on whitespace
before initializing semihosting.argv[1..n]; this is different from what
QEMU MIPS machines' pseudo-bootloaders do (i.e. argv[1] contains the whole
-append), but is more intuitive from UHI user's point of view and Linux
kernel just does not care as it concatenates argv[1..n] into single cmdline
string anyway.
Signed-off-by: NLeon Alrae <leon.alrae@imgtec.com>
Message-id: 1434643256-16858-3-git-send-email-leon.alrae@imgtec.com
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      a59d31a1