Skip to content
Snippets Groups Projects
Select Git revision
  • feature/libtcg-rebase default protected
1 result
Search by author
  • Any Author
  • Anton Anton anjo
1 author
  1. Feb 13, 2017
    • Peter Maydell's avatar
      Merge remote-tracking branch 'remotes/awilliam/tags/vfio-updates-20170210.0' into staging · ed3d90df
      Peter Maydell authored 
      
VFIO updates 2017-02-10

 - Fix GTT wrap-around for Skylake IGD assignment (Alex Williamson)
 - Tag vfio-pci-igd-lpc-bridge as bridge device category (Thomas Huth)
 - Don't build calxeda-xgmac or amd-xgbe except on ARM (Thomas Huth)

# gpg: Signature made Fri 10 Feb 2017 21:34:33 GMT
# gpg:                using RSA key 0x239B9B6E3BB08B22
# gpg: Good signature from "Alex Williamson <alex.williamson@redhat.com>"
# gpg:                 aka "Alex Williamson <alex@shazbot.org>"
# gpg:                 aka "Alex Williamson <alwillia@redhat.com>"
# gpg:                 aka "Alex Williamson <alex.l.williamson@gmail.com>"
# Primary key fingerprint: 42F6 C04E 540B D1A9 9E7B  8A90 239B 9B6E 3BB0 8B22

* remotes/awilliam/tags/vfio-updates-20170210.0:
  hw/vfio: Add CONFIG switches for calxeda-xgmac and amd-xgbe
  hw/vfio/pci-quirks: Set category of the "vfio-pci-igd-lpc-bridge" device
  vfio-pci: Fix GTT wrap-around for Skylake+ IGD

Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      ed3d90df
  3. Feb 10, 2017
  5. Feb 09, 2017
  7. Feb 08, 2017
    • Daniel P. Berrangé's avatar
      ui: refactor VncDisplay to allow multiple listening sockets · 4ee74fa7
      Daniel P. Berrangé authored 
      
Currently there is only a single listener for plain VNC and
a single listener for websockets VNC. This means that if
getaddrinfo() returns multiple IP addresses, for a hostname,
the VNC server can only listen on one of them. This is
just bearable if listening on wildcard interface, or if
the host only has a single network interface to listen on,
but if there are multiple NICs and the VNC server needs
to listen on 2 or more specific IP addresses, it can't be
done.

This refactors the VncDisplay state so that it holds an
array of listening sockets, but still only listens on
one socket.

Reviewed-by: default avatarEric Blake <eblake@redhat.com>
Signed-off-by: default avatarDaniel P. Berrange <berrange@redhat.com>
Message-id: 20170203120649.15637-4-berrange@redhat.com
Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      4ee74fa7
    • Daniel P. Berrangé's avatar
      ui: fix reporting of VNC auth in query-vnc-servers · 2a7e6857
      Daniel P. Berrangé authored 
      
Currently the VNC authentication info is emitted at the
top level of the query-vnc-servers data. This is wrong
because the authentication scheme differs between plain
and websockets when TLS is enabled. We should instead
report auth against the individual servers. e.g.

(QEMU) query-vnc-servers
{
    "return": [
        {
            "clients": [],
            "id": "default",
            "auth": "vencrypt",
            "vencrypt": "x509-vnc",
            "server": [
                {
                    "host": "127.0.0.1"
                    "service": "5901",
                    "websocket": false,
                    "family": "ipv4",
                    "auth": "vencrypt",
                    "vencrypt": "x509-vnc"
                },
                {
                    "host": "127.0.0.1",
                    "service": "5902",
                    "websocket": true,
                    "family": "ipv4",
                    "auth": "vnc"
                }
            ]
        }
    ]
}

This also future proofs the QMP schema so that we can
cope with multiple VNC server instances, listening on
different interfaces or ports, with different auth
setup.

Reviewed-by: default avatarEric Blake <eblake@redhat.com>
Signed-off-by: default avatarDaniel P. Berrange <berrange@redhat.com>
Message-id: 20170203120649.15637-3-berrange@redhat.com
Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      2a7e6857
    • Daniel P. Berrangé's avatar
      ui: fix regression handling bare 'websocket' option to -vnc · 1b1aeb58
      Daniel P. Berrangé authored 
      
The -vnc argument is documented as accepting two syntaxes for
the 'websocket' option, either a bare option name, or a port
number. If using the bare option name, it is supposed to apply
the display number as an offset to base port 5700. e.g.

  -vnc localhost:3,websocket

should listen on port 5703, however, this was broken in 2.3.0 since

  commit 4db14629
  Author: Gerd Hoffmann <kraxel@redhat.com>
  Date:   Tue Sep 16 12:33:03 2014 +0200

    vnc: switch to QemuOpts, allow multiple servers

instead qemu tries to listen on port "on" which gets looked up in
/etc/services and fails.

Fixes bug: #1455912

Reviewed-by: default avatarEric Blake <eblake@redhat.com>
Signed-off-by: default avatarDaniel P. Berrange <berrange@redhat.com>
Message-id: 20170203120649.15637-2-berrange@redhat.com
Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      1b1aeb58
    • Michael Tokarev's avatar
      vnc: do not disconnect on EAGAIN · 537848ee
      Michael Tokarev authored 
      
When qemu vnc server is trying to send large update to clients,
there might be a situation when system responds with something
like EAGAIN, indicating that there's no system memory to send
that much data (depending on the network speed, client and server
and what is happening).  In this case, something like this happens
on qemu side (from strace):

sendmsg(16, {msg_name(0)=NULL,
        msg_iov(1)=[{"\244\"..., 729186}],
        msg_controllen=0, msg_flags=0}, 0) = 103950
sendmsg(16, {msg_name(0)=NULL,
        msg_iov(1)=[{"lz\346"..., 1559618}],
        msg_controllen=0, msg_flags=0}, 0) = -1 EAGAIN
sendmsg(-1, {msg_name(0)=NULL,
        msg_iov(1)=[{"lz\346"..., 1559618}],
        msg_controllen=0, msg_flags=0}, 0) = -1 EBADF

qemu closes the socket before the retry, and obviously it gets EBADF
when trying to send to -1.

This is because there WAS a special handling for EAGAIN, but now it doesn't
work anymore, after commit 04d2529d, because
now in all error-like cases we initiate vnc disconnect.

This change were introduced in qemu 2.6, and caused numerous grief for many
people, resulting in their vnc clients reporting sporadic random disconnects
from vnc server.

Fix that by doing the disconnect only when necessary, i.e. omitting this
very case of EAGAIN.

Hopefully the existing condition (comparing with QIO_CHANNEL_ERR_BLOCK)
is sufficient, as the original code (before the above commit) were
checking for other errno values too.

Apparently there's another (semi?)bug exist somewhere here, since the
code tries to write to fd# -1, it probably should check if the connection
is open before. But this isn't important.

Signed-off-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
Reviewed-by: default avatarDaniel P. Berrange <berrange@redhat.com>
Message-id: 1486115549-9398-1-git-send-email-mjt@msgid.tls.msk.ru
Fixes: 04d2529d
Cc: Daniel P. Berrange <berrange@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      537848ee
    • Peter Maydell's avatar
      ui/vnc: Drop unused vnc_has_job() and vnc_jobs_clear() · c3ff04b6
      Peter Maydell authored 
      
The functions vnc_has_job() and vnc_jobs_clear() are
never used; remove them.

Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: default avatarGonglei <arei.gonglei@huawei.com>
Message-id: 1486146260-8092-1-git-send-email-peter.maydell@linaro.org
Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      c3ff04b6
  9. Feb 07, 2017