Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu
切换分支/标签
  1. 26 2月, 2018 3 次提交
  3. 10 2月, 2018 1 次提交
  5. 21 12月, 2017 2 次提交
  7. 30 10月, 2017 1 次提交
  9. 02 10月, 2017 1 次提交
  11. 20 9月, 2017 1 次提交
  13. 14 9月, 2017 1 次提交
  15. 04 9月, 2017 14 次提交
  17. 31 7月, 2017 1 次提交
  19. 28 7月, 2017 1 次提交
  21. 27 7月, 2017 2 次提交
  23. 24 7月, 2017 3 次提交
    • M
      migration: Use JSON null instead of "" to reset parameter to default · 01fa5598
      由 Markus Armbruster 提交于 
      migrate-set-parameters sets migration parameters according to is
arguments like this:

* Present means "set the parameter to this value"

* Absent means "leave the parameter unchanged"

* Except for parameters tls_creds and tls_hostname, "" means "reset
  the parameter to its default value

The first two are perfectly normal: presence of the parameter makes
the command do something.

The third one overloads the parameter with a second meaning.  The
overloading is *implicit*, i.e. it's not visible in the types.  Works
here, because "" is neither a valid TLS credentials ID, nor a valid
host name.

Pressing argument values the schema accepts, but are semantically
invalid, into service to mean "reset to default" is not general, as
suitable invalid values need not exist.  I also find it ugly.

To clean this up, we could add a separate flag argument to ask for
"reset to default", or add a distinct value to @tls_creds and
@tls_hostname.  This commit implements the latter: add JSON null to
the values of @tls_creds and @tls_hostname, deprecate "".

Because we're so close to the 2.10 freeze, implement it in the
stupidest way possible: have qmp_migrate_set_parameters() rewrite null
to "" before anything else can see the null.  The proper way to do it
would be rewriting "" to null, but that requires fixing up code to
work with null.  Add TODO comments for that.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
      01fa5598
    • M
      migration: Unshare MigrationParameters struct for now · 1bda8b3c
      由 Markus Armbruster 提交于 
      Commit de63ab61 "migrate: Share common MigrationParameters struct"
reused MigrationParameters for the arguments of
migrate-set-parameters, with the following rationale:

    It is rather verbose, and slightly error-prone, to repeat
    the same set of parameters for input (migrate-set-parameters)
    as for output (query-migrate-parameters), where the only
    difference is whether the members are optional.  We can just
    document that the optional members will always be present
    on output, and then share a common struct between both
    commands.  The next patch can then reduce the amount of
    code needed on input.

I need to unshare them to correct a design flaw in a stupid, but
minimally invasive way, in the next commit.  We can restore the
sharing when we redo that patch in a less stupid way.  Add a suitable
TODO comment.

Note that I revert only the sharing part of commit de63ab61, not the
part that made the members of query-migrate-parameters' result
optional.  The schema (and thus introspection) remains inaccurate for
query-migrate-parameters.  If we decide not to restore the sharing, we
should revert that part, too.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
      1bda8b3c
    • M
      migration: Clean up around tls_creds, tls_hostname · 8cc99dcd
      由 Markus Armbruster 提交于 
      Optional MigrationParameters members tls_creds and tls_hostname can't
actually be absent outside qmp_migrate_set_parameters() since commit
4af245dc (v2.9.0).

Note that commit 4af245dc reverted the part of commit de63ab61 (v2.8.0)
that made tls_creds and tls_hostname absent instead of "" in the value
of query-migrate-parameters, even though commit de63ab61 called that a
mistake.  What a mess.

Drop the redundant tests for presence, and update documentation.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
      8cc99dcd
  25. 20 7月, 2017 1 次提交
  27. 18 7月, 2017 2 次提交
  29. 14 7月, 2017 1 次提交
    • A
      char: chardevice hotswap · 7bb86085
      由 Anton Nefedov 提交于 
      This patch adds a possibility to change a char device without a frontend
removal.

Ideally, it would have to happen transparently to a frontend, i.e.
frontend would continue its regular operation.
However, backends are not stateless and are set up by the frontends
via qemu_chr_fe_<> functions, and it's not (generally) possible to replay
that setup entirely in a backend code, as different chardevs respond
to the setup calls differently, so do frontends work differently basing
on those setup responses.
Moreover, some frontend can generally get and save the backend pointer
(qemu_chr_fe_get_driver()), and it will become invalid after backend change.

So, a frontend which would like to support chardev hotswap has to register
a "backend change" handler, and redo its backend setup there.
Signed-off-by: NAnton Nefedov <anton.nefedov@virtuozzo.com>
Reviewed-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <1499342940-56739-4-git-send-email-anton.nefedov@virtuozzo.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      7bb86085
  31. 11 7月, 2017 1 次提交
  33. 30 6月, 2017 1 次提交
  35. 28 6月, 2017 1 次提交
    • P
      migration: add "return-path" capability · c788ada8
      由 Peter Xu 提交于 
      When this capability is enabled, QEMU will use the return path even for
precopy migration. This is helpful at least in one case when destination
failed to load the image while source quited without confirmation. With
return path, source will wait for the last response from destination,
and if destination fails, it'll fail the migration on source, then the
guest can be run again on the source (rather than assuming to be good,
then the guest will be lost after source quits).

It needs to be enabled explicitly on source, otherwise disabled.
Signed-off-by: NPeter Xu <peterx@redhat.com>
Message-Id: <1498472935-14461-1-git-send-email-peterx@redhat.com>
Reviewed-by: NJuan Quintela <quintela@redhat.com>
Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>
      c788ada8
  37. 23 5月, 2017 1 次提交
  39. 19 5月, 2017 1 次提交