Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu
切换分支/标签
  1. 25 11月, 2015 1 次提交
    • M
      vhost-user: clarify start and enable · c61f09ed
      由 Michael S. Tsirkin 提交于 
      It seems that we currently have some duplication between
started and enabled states.

The actual reason is that enable is not documented correctly:
what it does is connecting ring to the backend.

This is important for MQ, because a Linux guest expects TX
packets to be completed even if it disables some queues
temporarily.

Cc: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Cc: Victor Kaplansky <victork@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      c61f09ed
  3. 17 11月, 2015 3 次提交
  5. 16 11月, 2015 1 次提交
  7. 12 11月, 2015 4 次提交
  9. 10 11月, 2015 3 次提交
    • D
      Add postcopy documentation · 2bfdd1c8
      由 Dr. David Alan Gilbert 提交于 
      Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: NAmit Shah <amit.shah@redhat.com>
Reviewed-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>
      2bfdd1c8
    • E
      qapi-introspect: Document lack of sorting · f5455044
      由 Eric Blake 提交于 
      qapi-code-gen.txt already claims that types, commands, and
events share a common namespace; set this in stone by further
documenting that our introspection output will never have
collisions with the same name tied to more than one meta-type.

Our largest QMP enum currently has 125 values, our largest
object type has 27 members, and the mean for each is less than
10.  These sizes are small enough that the per-element overhead
of O(log n) binary searching probably outweighs the speed
possible with direct O(n) linear searching (a better algorithm
with more overhead will only beat a leaner naive algorithm only
as you scale to larger input sizes).

Arguably, the overall SchemaInfo array could be sorted by name;
there, we currently have 531 entities, large enough for a binary
search to be faster than linear.  However, remember that we have
mutually-recursive types, which means there is no topological
ordering that will allow clients to learn all information about
that type in a single linear pass; thus clients will want to do
random access over the data, and they will probably read the
introspection output into a hashtable for O(1) lookup rather
than O(log n) binary searching, at which point, pre-sorting our
introspection output doesn't help the client.

It doesn't help that sorting can be subjective if you introduce
locales into the mix (I'm not experienced enough with Python
to know for sure, but at least it looks like it defaults to
sorting in the C locale even when run under a different locale).
And while our current introspection output is deterministic
(because we visit entities in a sorted order), we may want
to change that order in the future (such as using OrderedDict
to stick to .json declaration order).

For these reasons, we simply document that clients should not
rely on any particular order of items in introspection output.
And since it is now a documented part of the contract, we have
the freedom to later rearrange output if needed, without
worrying about breaking well-written clients.
Signed-off-by: NEric Blake <eblake@redhat.com>
Message-Id: <1446791754-23823-13-git-send-email-eblake@redhat.com>
[Commit message tweaked]
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      f5455044
    • E
      qapi: Provide nicer array names in introspection · ce5fcb47
      由 Eric Blake 提交于 
      For the sake of humans reading introspection output, it is nice
to have the name of implicit array types be recognizable as
arrays of the underlying type.  However, while this patch allows
humans to skip from a command with return type "[123]" straight
to the definition of type "123" without having to first inspect
type "[123]", document that this shortcut should not be taken by
client apps.

This makes the resulting introspection string slightly larger by
default (just over 200 bytes), but it's in the noise (less than
0.3% of the overall 70k size of 'query-qmp-capabilities').
Signed-off-by: NEric Blake <eblake@redhat.com>
Message-Id: <1446791754-23823-12-git-send-email-eblake@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      ce5fcb47
  11. 05 11月, 2015 1 次提交
  13. 02 11月, 2015 2 次提交
    • E
      qapi: Reserve 'q_*' and 'has_*' member names · 9fb081e0
      由 Eric Blake 提交于 
      c_name() produces names starting with 'q_' when protecting a
dictionary member name that would fail to directly compile, but
in doing so can cause clashes with any member name already
beginning with 'q-' or 'q_'.  Likewise, we create a C name 'has_'
for any optional member that can clash with any member name
beginning with 'has-' or 'has_'.

Technically, rather than blindly reserving the namespace,
we could try to complain about user names only when an actual
collision occurs, or even teach c_name() how to munge names
to avoid collisions.  But it is not trivial, especially when
collisions can occur across multiple types (such as via
inheritance or flat unions).  Besides, no existing .json
files are trying to use these names.  So it's easier to just
outright forbid the potential for collision.  We can always
relax things in the future if a real need arises for QMP to
express member names that have been forbidden here.

'has_' only has to be reserved for struct/union member names,
while 'q_' is reserved everywhere (matching the fact that
only members can be optional, while we use c_name() for munging
both members and entities).  Note that we could relax 'q_'
restrictions on entities independently from member names; for
example, c_name('qmp_' + 'unix') would result in a different
function name than our current 'qmp_' + c_name('unix').

Update and add tests to cover the new error messages.
Signed-off-by: NEric Blake <eblake@redhat.com>
Message-Id: <1445898903-12082-6-git-send-email-eblake@redhat.com>
[Consistently pass protect=False to c_name(); commit message tweaked
slightly]
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      9fb081e0
    • E
      qapi: Reserve '*List' type names for list types · 255960dd
      由 Eric Blake 提交于 
      Type names ending in 'List' can clash with qapi list types in
generated C.  We don't currently use such names. It is easier to
outlaw them now than to worry about how to resolve such a clash
in the future. For precedence, see commit 4dc2e690, which did the
same for names ending in 'Kind' versus implicit enum types for
qapi unions.

Update the testsuite to match.
Signed-off-by: NEric Blake <eblake@redhat.com>
Message-Id: <1445898903-12082-5-git-send-email-eblake@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      255960dd
  15. 30 10月, 2015 1 次提交
  17. 26 10月, 2015 1 次提交
  19. 25 10月, 2015 2 次提交
  21. 22 10月, 2015 3 次提交
  23. 19 10月, 2015 5 次提交
  25. 13 10月, 2015 3 次提交
    • E
      qapi: Consistent generated code: prefer visitor 'v' · f8b7f1a8
      由 Eric Blake 提交于 
      We had some pointless differences in the generated code for visit,
command marshalling, and events; unifying them makes it easier for
future patches to consolidate to common helper functions.
This is one patch of a series to clean up these differences.

This patch names the local visitor variable 'v' rather than 'm'.
Related objects, such as 'QapiDeallocVisitor', are also named by
their initials instead of an unrelated leading m.

No change in semantics to the generated code.
Signed-off-by: NEric Blake <eblake@redhat.com>
Message-Id: <1443565276-4535-12-git-send-email-eblake@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      f8b7f1a8
    • E
      qapi: Consistent generated code: prefer error 'err' · 2a0f50e8
      由 Eric Blake 提交于 
      We had some pointless differences in the generated code for visit,
command marshalling, and events; unifying them makes it easier for
future patches to consolidate to common helper functions.
This is one patch of a series to clean up these differences.

This patch consistently names the local error variable 'err' rather
than 'local_err'.

No change in semantics to the generated code.
Signed-off-by: NEric Blake <eblake@redhat.com>
Message-Id: <1443565276-4535-11-git-send-email-eblake@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      2a0f50e8
    • M
      docs: Move files from docs/qmp/ to docs/ · 9b89b6a2
      由 Markus Armbruster 提交于 
      Giving QMP its own subdirectory in docs/ is hardly worthwhile when we
have just four files, and one of them isn't even in the subdirectory.
Move the files from docs/qmp/ to docs/, renaming docs/qmp/README to
docs/qmp-intro.

Update MAINTAINERS.  The new pattern also captures the fourth file
docs/writing-qmp-commands.txt.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Message-Id: <1443111117-29831-2-git-send-email-armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NLuiz Capitulino <lcapitulino@redhat.com>
      9b89b6a2
  27. 09 10月, 2015 1 次提交
  29. 25 9月, 2015 2 次提交
  31. 24 9月, 2015 6 次提交
  33. 23 9月, 2015 1 次提交
    • B
      spapr: Support ibm,dynamic-reconfiguration-memory · 03d196b7
      由 Bharata B Rao 提交于 
      Parse ibm,architecture.vec table obtained from the guest and enable
memory node configuration via ibm,dynamic-reconfiguration-memory if guest
supports it. This is in preparation to support memory hotplug for
sPAPR guests.

This changes the way memory node configuration is done. Currently all
memory nodes are built upfront. But after this patch, only memory@0 node
for RMA is built upfront. Guest kernel boots with just that and rest of
the memory nodes (via memory@XXX or ibm,dynamic-reconfiguration-memory)
are built when guest does ibm,client-architecture-support call.

Note: This patch needs a SLOF enhancement which is already part of
SLOF binary in QEMU.
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>
      03d196b7