Re: [Qemu-devel] [PATCH v2 01/16] scripts/git.orderfile: Match QAPI schema more precisely

2019-09-09 Thread Philippe Mathieu-Daudé
On 9/10/19 8:37 AM, Markus Armbruster wrote:
> Pattern *.json also matches the tests/qapi-schema/*.json.  Separates
> them from the tests/qapi-schema/*.{err,exit,out} in diffs.  I hate
> that.  Change the pattern to match just the "real" QAPI schemata.
> 
> Signed-off-by: Markus Armbruster 
> ---
>  scripts/git.orderfile | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/scripts/git.orderfile b/scripts/git.orderfile
> index ac699700b1..e89790941c 100644
> --- a/scripts/git.orderfile
> +++ b/scripts/git.orderfile
> @@ -19,11 +19,11 @@ Makefile*
>  *.mak
>  
>  # qapi schema
> -*.json
> +qapi/*.json
> +qga/*.json
>  
>  # headers
>  *.h
>  
>  # code
>  *.c
> -
> 

Reviewed-by: Philippe Mathieu-Daudé 



[Qemu-devel] [PATCH v2 15/16] docs/devel/qapi-code-gen: Improve QAPI schema language doc

2019-09-09 Thread Markus Armbruster
We document the language by giving patterns of valid JSON objects.
The patterns contain placeholders we don't define anywhere; their
names have to speak for themselves.  I guess they do, but I'd prefer a
bit more rigor.  Provide a grammar instead, and rework the text
accordingly.

Documentation for QAPI schema conditionals (commit 967c885108,
6cc32b0e14, 87adbbffd4..3e270dcacc) and feature flags (commit
6a8c0b5102) was bolted on.  The sections documenting types, commands
and events don't mention them.  Section "Features" and "Configuring
the schema" then provide additional syntax for types, commands and
events.  I hate that.  Fix the sections documenting types, commands
and events to provide accurate syntax, and point to "Features" and
"Configuring the schema" for details.

We talk about "(top-level) expressions other than include and pragma".
Adopt more convenient terminology: a (top-level) expression is either
a directive (include or pragma) or a definition (anything else).

Avoid the terms "dictionary" and "key".  Stick to JSON terminology
"object" and "member name" instead.

While there, make spacing more consistent.

Signed-off-by: Markus Armbruster 
---
 docs/devel/qapi-code-gen.txt | 592 ++-
 1 file changed, 369 insertions(+), 223 deletions(-)

diff --git a/docs/devel/qapi-code-gen.txt b/docs/devel/qapi-code-gen.txt
index 54a324cc69..90a24c1bd5 100644
--- a/docs/devel/qapi-code-gen.txt
+++ b/docs/devel/qapi-code-gen.txt
@@ -4,12 +4,12 @@ Copyright IBM Corp. 2011
 Copyright (C) 2012-2016 Red Hat, Inc.
 
 This work is licensed under the terms of the GNU GPL, version 2 or
-later. See the COPYING file in the top-level directory.
+later.  See the COPYING file in the top-level directory.
 
 == Introduction ==
 
 QAPI is a native C API within QEMU which provides management-level
-functionality to internal and external users. For external
+functionality to internal and external users.  For external
 users/processes, this interface is made available by a JSON-based wire
 format for the QEMU Monitor Protocol (QMP) for controlling qemu, as
 well as the QEMU Guest Agent (QGA) for communicating with the guest.
@@ -54,23 +54,46 @@ Differences:
 
 * Numbers are not supported.
 
-A QAPI schema consists of a series of top-level expressions (JSON
-objects).  Their order does not matter.
+A second layer of syntax defines the sequences of JSON texts that are
+a correctly structured QAPI schema.  We provide a grammar for this
+syntax in an EBNF-like notation:
 
-The order of keys within JSON objects does not matter unless
+* Production rules look like non-terminal = expression
+* Concatenation: Expression A B matches expression A, then B
+* Alternation: Expression A | B matches expression A or B
+* Repetition: Expression A... matches zero or more occurences of
+  expression A; expression A, ... likewise, but separated by ,
+* Grouping: Expression ( A ) matches expression A
+* JSON's structural characters are terminals: { } [ ] : ,
+* JSON's literal names are terminals: false true null
+* String literals enclosed in 'single quotes' are terminal, and match
+  this JSON string, with a leading '*' stripped off
+* When JSON object member's name starts with '*', the member is
+  optional.
+* The symbol STRING is a terminal, and matches any JSON string
+* The symbol BOOL is a terminal, and matches JSON false or true
+* ALL-CAPS words other than STRING are non-terminals
+
+The order of members within JSON objects does not matter unless
 explicitly noted.
 
-There are eight kinds of top-level expressions: 'include', 'pragma',
-'command', 'struct', 'enum', 'union', 'alternate', and 'event'.  These
-are discussed in detail below.
-
-In the rest of this document, usage lines are given for each
-expression type, with literal strings written in lower case and
-placeholders written in capitals.  If a literal string includes a
-prefix of '*', that key/value pair can be omitted from the expression.
-For example, a usage statement that includes '*base':STRUCT-NAME
-means that an expression has an optional key 'base', which if present
-must have a value that forms a struct name.
+A QAPI schema consists of a series of top-level expressions:
+
+SCHEMA = TOP-LEVEL-EXPR...
+
+The top-level expressions are all JSON objects.  Their order does not
+matter.
+
+A top-level expressions is either a directive or a definition:
+
+TOP-LEVEL-EXPR = DIRECTIVE | DEFINITION
+
+There are two kinds of directives and six kinds of definitions:
+
+DIRECTIVE = INCLUDE | PRAGMA
+DEFINITION = ENUM | STRUCT | UNION | ALTERNATE | COMMAND | EVENT
+
+These are discussed in detail below.
 
 
 === Built-in Types ===
@@ -100,16 +123,16 @@ The following types are predefined, and map to C as 
follows:
 
 === Include directives ===
 
-Usage: { 'include': STRING }
+Syntax:
+INCLUDE = { 'include': STRING }
 
 The QAPI schema definitions can be modularized using the 'include' directive:
 
  { 'include': 'path/to/file.json' }

[Qemu-devel] [PATCH v2 08/16] qapi: Permit 'boxed' with empty type

2019-09-09 Thread Markus Armbruster
We reject empty types with 'boxed': true.  We don't really need that
to work, but making it work is actually simpler than rejecting it, so
do that.

Signed-off-by: Markus Armbruster 
---
 tests/test-qmp-cmds.c   |  4 
 scripts/qapi/commands.py|  4 ++--
 scripts/qapi/common.py  | 14 ++
 scripts/qapi/events.py  | 10 +-
 tests/Makefile.include  |  1 -
 tests/qapi-schema/args-boxed-empty.err  |  1 -
 tests/qapi-schema/args-boxed-empty.exit |  1 -
 tests/qapi-schema/args-boxed-empty.json |  3 ---
 tests/qapi-schema/args-boxed-empty.out  |  0
 tests/qapi-schema/qapi-schema-test.json |  2 ++
 tests/qapi-schema/qapi-schema-test.out  |  4 
 11 files changed, 19 insertions(+), 25 deletions(-)
 delete mode 100644 tests/qapi-schema/args-boxed-empty.err
 delete mode 100644 tests/qapi-schema/args-boxed-empty.exit
 delete mode 100644 tests/qapi-schema/args-boxed-empty.json
 delete mode 100644 tests/qapi-schema/args-boxed-empty.out

diff --git a/tests/test-qmp-cmds.c b/tests/test-qmp-cmds.c
index ab389f42da..36fdf5b115 100644
--- a/tests/test-qmp-cmds.c
+++ b/tests/test-qmp-cmds.c
@@ -97,6 +97,10 @@ void qmp_boxed_union(UserDefListUnion *arg, Error **errp)
 {
 }
 
+void qmp_boxed_empty(Empty1 *arg, Error **errp)
+{
+}
+
 __org_qemu_x_Union1 *qmp___org_qemu_x_command(__org_qemu_x_EnumList *a,
   __org_qemu_x_StructList *b,
   __org_qemu_x_Union2 *c,
diff --git a/scripts/qapi/commands.py b/scripts/qapi/commands.py
index b929e07be4..7e3dd1068a 100644
--- a/scripts/qapi/commands.py
+++ b/scripts/qapi/commands.py
@@ -30,7 +30,7 @@ def gen_call(name, arg_type, boxed, ret_type):
 
 argstr = ''
 if boxed:
-assert arg_type and not arg_type.is_empty()
+assert arg_type
 argstr = '&arg, '
 elif arg_type:
 assert not arg_type.variants
@@ -96,7 +96,7 @@ def gen_marshal_decl(name):
 
 
 def gen_marshal(name, arg_type, boxed, ret_type):
-have_args = arg_type and not arg_type.is_empty()
+have_args = boxed or (arg_type and not arg_type.is_empty())
 
 ret = mcgen('''
 
diff --git a/scripts/qapi/common.py b/scripts/qapi/common.py
index f5583d3eac..6e25479939 100644
--- a/scripts/qapi/common.py
+++ b/scripts/qapi/common.py
@@ -1684,12 +1684,7 @@ class QAPISchemaCommand(QAPISchemaEntity):
 self.arg_type = schema.lookup_type(self._arg_type_name)
 assert isinstance(self.arg_type, QAPISchemaObjectType)
 self.arg_type.check(schema)
-if self.boxed:
-if self.arg_type.is_empty():
-raise QAPISemError(self.info,
-   "Cannot use 'boxed' with empty type")
-else:
-assert not self.arg_type.variants
+assert not self.arg_type.variants or self.boxed
 elif self.boxed:
 raise QAPISemError(self.info, "Use of 'boxed' requires 'data'")
 if self._ret_type_name:
@@ -1718,12 +1713,7 @@ class QAPISchemaEvent(QAPISchemaEntity):
 self.arg_type = schema.lookup_type(self._arg_type_name)
 assert isinstance(self.arg_type, QAPISchemaObjectType)
 self.arg_type.check(schema)
-if self.boxed:
-if self.arg_type.is_empty():
-raise QAPISemError(self.info,
-   "Cannot use 'boxed' with empty type")
-else:
-assert not self.arg_type.variants
+assert not self.arg_type.variants or self.boxed
 elif self.boxed:
 raise QAPISemError(self.info, "Use of 'boxed' requires 'data'")
 
diff --git a/scripts/qapi/events.py b/scripts/qapi/events.py
index b732581046..e0abfef7b0 100644
--- a/scripts/qapi/events.py
+++ b/scripts/qapi/events.py
@@ -65,6 +65,8 @@ def gen_event_send(name, arg_type, boxed, event_enum_name, 
event_emit):
 # practice, we can rename our local variables with a leading _ prefix,
 # or split the code into a wrapper function that creates a boxed
 # 'param' object then calls another to do the real work.
+have_args = boxed or (arg_type and not arg_type.is_empty())
+
 ret = mcgen('''
 
 %(proto)s
@@ -73,15 +75,13 @@ def gen_event_send(name, arg_type, boxed, event_enum_name, 
event_emit):
 ''',
 proto=build_event_send_proto(name, arg_type, boxed))
 
-if arg_type and not arg_type.is_empty():
+if have_args:
 ret += mcgen('''
 QObject *obj;
 Visitor *v;
 ''')
 if not boxed:
 ret += gen_param_var(arg_type)
-else:
-assert not boxed
 
 ret += mcgen('''
 
@@ -90,7 +90,7 @@ def gen_event_send(name, arg_type, boxed, event_enum_name, 
event_emit):
 ''',
  name=name)
 
-if arg_type and not arg_type.is_empty():
+if have_args:
 ret += mcgen('''
 v = qobject_out

[Qemu-devel] [PATCH v2 00/16] qapi: Schema language cleanups & doc improvements

2019-09-09 Thread Markus Armbruster
v2:
* PATCH v1 05: Dropped
* PATCH 01,05,07-11,16: New
* PATCH 03:
  - Commit message typo fixed
  - Assertions tightened
* PATCH 04:
  - Document member name 'u' is reserved
  - Drop an accidental change to section "Enumeration types"
  - Typo fixed
* PATCH 06:
  - Outlaw anything but printable ASCII, not just control characters
* PATCH 15:
  - Adopt more convenient terminology: directive, definition
  - Explanation of grammar notation missed grouping
  - Drop a more text redundant with the grammar
  - Drop more text redundant with section "Naming rules and reserved
names"
  - Turn "boxed needs data: STRING" into syntax
  - Improve section "Documentation comments" some more
  - Minor phrasing tweaks

Markus Armbruster (16):
  scripts/git.orderfile: Match QAPI schema more precisely
  qapi: Drop check_type()'s redundant parameter @allow_optional
  qapi: Drop support for boxed alternate arguments
  docs/devel/qapi-code-gen: Minor specification fixes
  tests/qapi-schema: Demonstrate bad reporting of funny characters
  qapi: Restrict strings to printable ASCII
  qapi: Drop support for escape sequences other than \\
  qapi: Permit 'boxed' with empty type
  qapi: Permit alternates with just one branch
  qapi: Permit omitting all flat union branches
  qapi: Adjust frontend errors to say enum value, not member
  docs/devel/qapi-code-gen: Reorder sections for readability
  docs/devel/qapi-code-gen: Rewrite compatibility considerations
  docs/devel/qapi-code-gen: Rewrite introduction to schema
  docs/devel/qapi-code-gen: Improve QAPI schema language doc
  qapi: Tweak code to match docs/devel/qapi-code-gen.txt

 docs/devel/qapi-code-gen.txt  | 1068 ++---
 tests/test-qmp-cmds.c |4 +
 scripts/git.orderfile |4 +-
 scripts/qapi/commands.py  |4 +-
 scripts/qapi/common.py|  144 +--
 scripts/qapi/events.py|   10 +-
 tests/Makefile.include|7 +-
 tests/qapi-schema/alternate-empty.err |2 +-
 tests/qapi-schema/alternate-empty.json|4 +-
 tests/qapi-schema/args-boxed-empty.err|1 -
 tests/qapi-schema/args-boxed-empty.json   |3 -
 tests/qapi-schema/args-invalid.err|2 +-
 tests/qapi-schema/doc-missing.err |2 +-
 tests/qapi-schema/doc-no-symbol.err   |2 +-
 tests/qapi-schema/enum-bad-name.err   |2 +-
 tests/qapi-schema/enum-bad-name.json  |3 +-
 tests/qapi-schema/enum-clash-member.err   |2 +-
 .../qapi-schema/enum-dict-member-unknown.err  |2 +-
 tests/qapi-schema/enum-member-case.err|2 +-
 tests/qapi-schema/escape-outside-string.err   |1 -
 tests/qapi-schema/escape-outside-string.json  |3 -
 tests/qapi-schema/escape-too-big.err  |1 -
 tests/qapi-schema/escape-too-big.exit |1 -
 tests/qapi-schema/escape-too-big.json |3 -
 tests/qapi-schema/escape-too-big.out  |0
 tests/qapi-schema/escape-too-short.err|1 -
 tests/qapi-schema/escape-too-short.exit   |1 -
 tests/qapi-schema/escape-too-short.json   |3 -
 tests/qapi-schema/escape-too-short.out|0
 tests/qapi-schema/flat-union-empty.err|2 +-
 tests/qapi-schema/flat-union-empty.json   |2 +-
 tests/qapi-schema/ident-with-escape.err   |1 +
 tests/qapi-schema/ident-with-escape.exit  |2 +-
 tests/qapi-schema/ident-with-escape.json  |2 +-
 tests/qapi-schema/ident-with-escape.out   |   16 -
 tests/qapi-schema/pragma-non-dict.err |2 +-
 tests/qapi-schema/qapi-schema-test.json   |   13 +-
 tests/qapi-schema/qapi-schema-test.out|   21 +-
 tests/qapi-schema/string-code-point-127.err   |1 +
 ...-empty.exit => string-code-point-127.exit} |0
 tests/qapi-schema/string-code-point-127.json  |2 +
 ...ed-empty.out => string-code-point-127.out} |0
 tests/qapi-schema/string-code-point-31.err|1 +
 ...-string.exit => string-code-point-31.exit} |0
 tests/qapi-schema/string-code-point-31.json   |2 +
 ...de-string.out => string-code-point-31.out} |0
 tests/qapi-schema/struct-data-invalid.err |2 +-
 tests/qapi-schema/unicode-str.err |1 -
 tests/qapi-schema/unicode-str.exit|1 -
 tests/qapi-schema/unicode-str.json|2 -
 tests/qapi-schema/unicode-str.out |0
 tests/qapi-schema/union-empty.err |2 +-
 tests/qapi-schema/union-empty.json|2 +-
 tests/qapi-schema/unknown-escape.json |2 +-
 54 files changed, 737 insertions(+), 624 deletions(-)
 delete mode 100644 tests/qapi-schema/args-boxed-empty.err
 delete mode 100644 tests/qapi-schema/args-boxed-empty.json
 delete mode 100644 tests/qapi-schema/escape-outside-string.err
 delete mode 100644 tests/qapi-schema/escape-outside-string.json
 delete mod

[Qemu-devel] [PATCH v2 09/16] qapi: Permit alternates with just one branch

2019-09-09 Thread Markus Armbruster
A union or alternate without branches makes no sense and doesn't work:
it can't be instantiated.  A union or alternate with just one branch
works, but is degenerate.  We accept the former, but reject the
latter.  Weird.  docs/devel/qapi-code-gen.txt doesn't mention the
difference.  It claims an alternate definition is "is similar to a
simple union type".

Permit degenerate alternates to make them consistent with unions.

Signed-off-by: Markus Armbruster 
---
 scripts/qapi/common.py  | 6 ++
 tests/qapi-schema/alternate-empty.err   | 2 +-
 tests/qapi-schema/alternate-empty.json  | 4 ++--
 tests/qapi-schema/qapi-schema-test.json | 4 +++-
 tests/qapi-schema/qapi-schema-test.out  | 6 --
 5 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/scripts/qapi/common.py b/scripts/qapi/common.py
index 6e25479939..46a4b07a04 100644
--- a/scripts/qapi/common.py
+++ b/scripts/qapi/common.py
@@ -917,11 +917,9 @@ def check_alternate(expr, info):
 members = expr['data']
 types_seen = {}
 
-# Check every branch; require at least two branches
-if len(members) < 2:
+if len(members) == 0:
 raise QAPISemError(info,
-   "Alternate '%s' should have at least two branches "
-   "in 'data'" % name)
+   "Alternate '%s' cannot have empty 'data'" % name)
 for (key, value) in members.items():
 check_name(info, "Member of alternate '%s'" % name, key)
 check_known_keys(info,
diff --git a/tests/qapi-schema/alternate-empty.err 
b/tests/qapi-schema/alternate-empty.err
index bb06c5bfec..86dbc666eb 100644
--- a/tests/qapi-schema/alternate-empty.err
+++ b/tests/qapi-schema/alternate-empty.err
@@ -1 +1 @@
-tests/qapi-schema/alternate-empty.json:2: Alternate 'Alt' should have at least 
two branches in 'data'
+tests/qapi-schema/alternate-empty.json:2: Alternate 'Alt' cannot have empty 
'data'
diff --git a/tests/qapi-schema/alternate-empty.json 
b/tests/qapi-schema/alternate-empty.json
index fff15baf16..9f445474e6 100644
--- a/tests/qapi-schema/alternate-empty.json
+++ b/tests/qapi-schema/alternate-empty.json
@@ -1,2 +1,2 @@
-# alternates must list at least two types to be useful
-{ 'alternate': 'Alt', 'data': { 'i': 'int' } }
+# alternates cannot be empty
+{ 'alternate': 'Alt', 'data': { } }
diff --git a/tests/qapi-schema/qapi-schema-test.json 
b/tests/qapi-schema/qapi-schema-test.json
index e6dbbbd328..8b0d47c4ab 100644
--- a/tests/qapi-schema/qapi-schema-test.json
+++ b/tests/qapi-schema/qapi-schema-test.json
@@ -186,19 +186,21 @@
 
 # test that we correctly compile downstream extensions, as well as munge
 # ticklish names
+# also test union and alternate with just one branch
 { 'enum': '__org.qemu_x-Enum', 'data': [ '__org.qemu_x-value' ] }
 { 'struct': '__org.qemu_x-Base',
   'data': { '__org.qemu_x-member1': '__org.qemu_x-Enum' } }
 { 'struct': '__org.qemu_x-Struct', 'base': '__org.qemu_x-Base',
   'data': { '__org.qemu_x-member2': 'str', '*wchar-t': 'int' } }
 { 'union': '__org.qemu_x-Union1', 'data': { '__org.qemu_x-branch': 'str' } }
+{ 'alternate': '__org.qemu_x-Alt1', 'data': { '__org.qemu_x-branch': 'str' } }
 { 'struct': '__org.qemu_x-Struct2',
   'data': { 'array': ['__org.qemu_x-Union1'] } }
 { 'union': '__org.qemu_x-Union2', 'base': '__org.qemu_x-Base',
   'discriminator': '__org.qemu_x-member1',
   'data': { '__org.qemu_x-value': '__org.qemu_x-Struct2' } }
 { 'alternate': '__org.qemu_x-Alt',
-  'data': { '__org.qemu_x-branch': 'str', 'b': '__org.qemu_x-Base' } }
+  'data': { '__org.qemu_x-branch': '__org.qemu_x-Base' } }
 { 'event': '__ORG.QEMU_X-EVENT', 'data': '__org.qemu_x-Struct' }
 { 'command': '__org.qemu_x-command',
   'data': { 'a': ['__org.qemu_x-Enum'], 'b': ['__org.qemu_x-Struct'],
diff --git a/tests/qapi-schema/qapi-schema-test.out 
b/tests/qapi-schema/qapi-schema-test.out
index fb00a21996..bea7976bbb 100644
--- a/tests/qapi-schema/qapi-schema-test.out
+++ b/tests/qapi-schema/qapi-schema-test.out
@@ -274,6 +274,9 @@ object __org.qemu_x-Union1
 member type: __org.qemu_x-Union1Kind optional=False
 tag type
 case __org.qemu_x-branch: q_obj_str-wrapper
+alternate __org.qemu_x-Alt1
+tag type
+case __org.qemu_x-branch: str
 array __org.qemu_x-Union1List __org.qemu_x-Union1
 object __org.qemu_x-Struct2
 member array: __org.qemu_x-Union1List optional=False
@@ -283,8 +286,7 @@ object __org.qemu_x-Union2
 case __org.qemu_x-value: __org.qemu_x-Struct2
 alternate __org.qemu_x-Alt
 tag type
-case __org.qemu_x-branch: str
-case b: __org.qemu_x-Base
+case __org.qemu_x-branch: __org.qemu_x-Base
 event __ORG.QEMU_X-EVENT __org.qemu_x-Struct
boxed=False
 array __org.qemu_x-EnumList __org.qemu_x-Enum
-- 
2.21.0




[Qemu-devel] [PATCH v2 13/16] docs/devel/qapi-code-gen: Rewrite compatibility considerations

2019-09-09 Thread Markus Armbruster
We have some compatibility advice buried in sections "Enumeration
types" and "Struct types".  Compatibility is actually about commands
and events.  It devolves to the types used there.  All kinds of types,
not just enumerations and structs.

Replace the existing advice by a new section "Compatibility
considerations".

Signed-off-by: Markus Armbruster 
---
 docs/devel/qapi-code-gen.txt | 95 +++-
 1 file changed, 60 insertions(+), 35 deletions(-)

diff --git a/docs/devel/qapi-code-gen.txt b/docs/devel/qapi-code-gen.txt
index 663ef10a56..d09232009e 100644
--- a/docs/devel/qapi-code-gen.txt
+++ b/docs/devel/qapi-code-gen.txt
@@ -178,14 +178,11 @@ While the C code starts numbering at 0, it is better to 
use explicit
 comparisons to enum values than implicit comparisons to 0; the C code
 will also include a generated enum member ending in _MAX for tracking
 the size of the enum, useful when using common functions for
-converting between strings and enum values.  Since the wire format
-always passes by name, it is acceptable to reorder or add new
-enumeration members in any location without breaking clients of Client
-JSON Protocol; however, removing enum values would break
-compatibility.  For any struct that has a member that will only contain
-a finite set of string values, using an enum type for that member is
-better than open-coding the member to be type 'str'.
+converting between strings and enum values.
 
+For any struct that has a member that will only contain a finite set
+of string values, using an enum type for that member is better than
+open-coding the member to be type 'str'.
 
 === Struct types ===
 
@@ -203,34 +200,6 @@ name.  An example of a struct is:
 The use of '*' as a prefix to the name means the member is optional in
 the corresponding JSON protocol usage.
 
-The default initialization value of an optional argument should not be changed
-between versions of QEMU unless the new default maintains backward
-compatibility to the user-visible behavior of the old default.
-
-With proper documentation, this policy still allows some flexibility; for
-example, documenting that a default of 0 picks an optimal buffer size allows
-one release to declare the optimal size at 512 while another release declares
-the optimal size at 4096 - the user-visible behavior is not the bytes used by
-the buffer, but the fact that the buffer was optimal size.
-
-On input structures (only mentioned in the 'data' side of a command), changing
-from mandatory to optional is safe (older clients will supply the option, and
-newer clients can benefit from the default); changing from optional to
-mandatory is backwards incompatible (older clients may be omitting the option,
-and must continue to work).
-
-On output structures (only mentioned in the 'returns' side of a command),
-changing from mandatory to optional is in general unsafe (older clients may be
-expecting the member, and could crash if it is missing), although it
-can be done if the only way that the optional argument will be omitted
-is when it is triggered by the presence of a new input flag to the
-command that older clients don't know to send.  Changing from optional
-to mandatory is safe.
-
-A structure that is used in both input and output of various commands
-must consider the backwards compatibility constraints of both directions
-of use.
-
 A struct definition can specify another struct as its base.
 In this case, the members of the base type are included as top-level members
 of the new struct's dictionary in the Client JSON Protocol wire
@@ -1037,6 +1006,62 @@ the names of built-in types.  Clients should examine 
member
 "json-type" instead of hard-coding names of built-in types.
 
 
+== Compatibility considerations ==
+
+Maintaining backward compatibility at the Client JSON Protocol level
+while evolving the schema requires some care.  This section is about
+syntactic compatibility.  Necessary, but not sufficient for actual
+compatibility.
+
+Clients send commands with argument data, and receive command
+responses with return data and events with event data.
+
+Adding opt-in functionality to the send direction is backwards
+compatible: adding commands, optional arguments, enumeration values,
+union and alternate branches; turning an argument type into an
+alternate of that type; making mandatory arguments optional.  Clients
+oblivious of the new functionality continue to work.
+
+Incompatible changes include removing commands, command arguments,
+enumeration values, union and alternate branches, adding mandatory
+command arguments, and making optional arguments mandatory.
+
+The specified behavior of an absent optional argument should remain
+the same.  With proper documentation, this policy still allows some
+flexibility; for example, when an optional 'buffer-size' argument is
+specified to default to a sensible buffer size, the actual default
+value can still be changed.  The specified default behavior is not the
+exa

[Qemu-devel] [PATCH v2 02/16] qapi: Drop check_type()'s redundant parameter @allow_optional

2019-09-09 Thread Markus Armbruster
check_type() uses @allow_optional only when @value is a dictionary and
@allow_dict is True.  All callers that pass allow_dict=True also pass
allow_optional=True.

Therefore, @allow_optional is always True when check_type() uses it.
Drop the redundant parameter.

Signed-off-by: Markus Armbruster 
---
 scripts/qapi/common.py | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/scripts/qapi/common.py b/scripts/qapi/common.py
index d61bfdc526..9aefcfe015 100644
--- a/scripts/qapi/common.py
+++ b/scripts/qapi/common.py
@@ -783,9 +783,8 @@ def check_if(expr, info):
 check_if_str(ifcond, info)
 
 
-def check_type(info, source, value, allow_array=False,
-   allow_dict=False, allow_optional=False,
-   allow_metas=[]):
+def check_type(info, source, value,
+   allow_array=False, allow_dict=False, allow_metas=[]):
 global all_names
 
 if value is None:
@@ -821,7 +820,7 @@ def check_type(info, source, value, allow_array=False,
 # value is a dictionary, check that each member is okay
 for (key, arg) in value.items():
 check_name(info, "Member of %s" % source, key,
-   allow_optional=allow_optional)
+   allow_optional=True)
 if c_name(key, False) == 'u' or c_name(key, False).startswith('has_'):
 raise QAPISemError(info, "Member of %s uses reserved name '%s'"
% (source, key))
@@ -843,14 +842,14 @@ def check_command(expr, info):
 if boxed:
 args_meta += ['union', 'alternate']
 check_type(info, "'data' for command '%s'" % name,
-   expr.get('data'), allow_dict=not boxed, allow_optional=True,
+   expr.get('data'), allow_dict=not boxed,
allow_metas=args_meta)
 returns_meta = ['union', 'struct']
 if name in returns_whitelist:
 returns_meta += ['built-in', 'alternate', 'enum']
 check_type(info, "'returns' for command '%s'" % name,
expr.get('returns'), allow_array=True,
-   allow_optional=True, allow_metas=returns_meta)
+   allow_metas=returns_meta)
 
 
 def check_event(expr, info):
@@ -861,7 +860,7 @@ def check_event(expr, info):
 if boxed:
 meta += ['union', 'alternate']
 check_type(info, "'data' for event '%s'" % name,
-   expr.get('data'), allow_dict=not boxed, allow_optional=True,
+   expr.get('data'), allow_dict=not boxed,
allow_metas=meta)
 
 
@@ -889,7 +888,7 @@ def check_union(expr, info):
 else:
 # The object must have a string or dictionary 'base'.
 check_type(info, "'base' for union '%s'" % name,
-   base, allow_dict=True, allow_optional=True,
+   base, allow_dict=True,
allow_metas=['struct'])
 if not base:
 raise QAPISemError(info, "Flat union '%s' must have a base"
@@ -1012,7 +1011,7 @@ def check_struct(expr, info):
 features = expr.get('features')
 
 check_type(info, "'data' for struct '%s'" % name, members,
-   allow_dict=True, allow_optional=True)
+   allow_dict=True)
 check_type(info, "'base' for struct '%s'" % name, expr.get('base'),
allow_metas=['struct'])
 
-- 
2.21.0




[Qemu-devel] [PATCH v2 16/16] qapi: Tweak code to match docs/devel/qapi-code-gen.txt

2019-09-09 Thread Markus Armbruster
The previous commit made qapi-code-gen.txt define "(top-level)
expression" as either "directive" or "definition".  The code still
uses "expression" when it really means "definition".  Tidy up.

The previous commit made qapi-code-gen.txt use "object" rather than
"dictionary".  The code still uses "dictionary".  Tidy up.

Signed-off-by: Markus Armbruster 
---
 scripts/qapi/common.py| 24 +--
 tests/qapi-schema/args-invalid.err|  2 +-
 tests/qapi-schema/doc-missing.err |  2 +-
 tests/qapi-schema/doc-no-symbol.err   |  2 +-
 .../qapi-schema/enum-dict-member-unknown.err  |  2 +-
 tests/qapi-schema/pragma-non-dict.err |  2 +-
 tests/qapi-schema/struct-data-invalid.err |  2 +-
 7 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/scripts/qapi/common.py b/scripts/qapi/common.py
index f4630a5dd3..e86d196e5f 100644
--- a/scripts/qapi/common.py
+++ b/scripts/qapi/common.py
@@ -103,11 +103,11 @@ class QAPISemError(QAPIError):
 
 class QAPIDoc(object):
 """
-A documentation comment block, either expression or free-form
+A documentation comment block, either definition or free-form
 
-Expression documentation blocks consist of
+Definition documentation blocks consist of
 
-* a body section: one line naming the expression, followed by an
+* a body section: one line naming the definition, followed by an
   overview (any number of lines)
 
 * argument sections: a description of each argument (for commands
@@ -200,9 +200,9 @@ class QAPIDoc(object):
 Process a line of documentation text in the body section.
 
 If this a symbol line and it is the section's first line, this
-is an expression documentation block for that symbol.
+is a definition documentation block for that symbol.
 
-If it's an expression documentation block, another symbol line
+If it's a definition documentation block, another symbol line
 begins the argument section for the argument named by it, and
 a section tag begins an additional section.  Start that
 section and append the line to it.
@@ -220,7 +220,7 @@ class QAPIDoc(object):
 if not self.symbol:
 raise QAPIParseError(self._parser, "Invalid name")
 elif self.symbol:
-# This is an expression documentation block
+# This is a definition documentation block
 if name.startswith('@') and name.endswith(':'):
 self._append_line = self._append_args_line
 self._append_args_line(line)
@@ -428,7 +428,7 @@ class QAPISchemaParser(object):
 pragma = expr['pragma']
 if not isinstance(pragma, dict):
 raise QAPISemError(
-info, "Value of 'pragma' must be a dictionary")
+info, "Value of 'pragma' must be an object")
 for name, value in pragma.items():
 self._pragma(name, value, info)
 else:
@@ -437,7 +437,7 @@ class QAPISchemaParser(object):
 if cur_doc:
 if not cur_doc.symbol:
 raise QAPISemError(
-cur_doc.info, "Expression documentation required")
+cur_doc.info, "Definition documentation required")
 expr_elem['doc'] = cur_doc
 self.exprs.append(expr_elem)
 cur_doc = None
@@ -786,7 +786,7 @@ def check_type(info, source, value,
 
 if not isinstance(value, OrderedDict):
 raise QAPISemError(info,
-   "%s should be a dictionary or type name" % source)
+   "%s should be an object or type name" % source)
 
 # value is a dictionary, check that each member is okay
 for (key, arg) in value.items():
@@ -968,8 +968,8 @@ def check_enum(expr, info):
"Enum '%s' requires a string for 'prefix'" % name)
 
 for member in members:
-source = "dictionary member of enum '%s'" % name
-check_known_keys(info, source, member, ['name'], ['if'])
+check_known_keys(info, "member of enum '%s'" % name, member,
+ ['name'], ['if'])
 check_if(member, info)
 check_name(info, "Member of enum '%s'" % name, member['name'],
enum_member=True)
@@ -1078,7 +1078,7 @@ def check_exprs(exprs):
 
 if not doc and doc_required:
 raise QAPISemError(info,
-   "Expression missing documentation comment")
+   "Definition missing documentation comment")
 
 if 'enum' in expr:
 meta = 'enum'
diff --git a/tests/qapi-schema/args-invalid.err 
b/tests/qapi-schema/args-invalid.err
index fe1e94975b..bfb2e4133e 100644
--- a/tests/qapi-schema/args-invalid.err
+++ b/tests/qapi-schema/args-invalid.err
@@

[Qemu-devel] [PATCH v2 07/16] qapi: Drop support for escape sequences other than \\

2019-09-09 Thread Markus Armbruster
Since the previous commit restricted strings to printable ASCII,
\u's only use is obfuscation.  Drop it.

This leaves \\, \/, \', and \".  Since QAPI schema strings are all
names, and names are restricted to ASCII letters, digits, hyphen, and
underscore, none of them is useful.

The latter three have no test coverage.  Drop them.

Keep \\ to avoid (more) gratuitous incompatibility with JSON.

Signed-off-by: Markus Armbruster 
---
 scripts/qapi/common.py   | 22 +---
 tests/Makefile.include   |  3 ---
 tests/qapi-schema/escape-outside-string.err  |  1 -
 tests/qapi-schema/escape-outside-string.exit |  1 -
 tests/qapi-schema/escape-outside-string.json |  3 ---
 tests/qapi-schema/escape-outside-string.out  |  0
 tests/qapi-schema/escape-too-big.err |  1 -
 tests/qapi-schema/escape-too-big.exit|  1 -
 tests/qapi-schema/escape-too-big.json|  3 ---
 tests/qapi-schema/escape-too-big.out |  0
 tests/qapi-schema/escape-too-short.err   |  1 -
 tests/qapi-schema/escape-too-short.exit  |  1 -
 tests/qapi-schema/escape-too-short.json  |  3 ---
 tests/qapi-schema/escape-too-short.out   |  0
 tests/qapi-schema/ident-with-escape.err  |  1 +
 tests/qapi-schema/ident-with-escape.exit |  2 +-
 tests/qapi-schema/ident-with-escape.json |  2 +-
 tests/qapi-schema/ident-with-escape.out  | 16 --
 tests/qapi-schema/unknown-escape.json|  2 +-
 19 files changed, 5 insertions(+), 58 deletions(-)
 delete mode 100644 tests/qapi-schema/escape-outside-string.err
 delete mode 100644 tests/qapi-schema/escape-outside-string.exit
 delete mode 100644 tests/qapi-schema/escape-outside-string.json
 delete mode 100644 tests/qapi-schema/escape-outside-string.out
 delete mode 100644 tests/qapi-schema/escape-too-big.err
 delete mode 100644 tests/qapi-schema/escape-too-big.exit
 delete mode 100644 tests/qapi-schema/escape-too-big.json
 delete mode 100644 tests/qapi-schema/escape-too-big.out
 delete mode 100644 tests/qapi-schema/escape-too-short.err
 delete mode 100644 tests/qapi-schema/escape-too-short.exit
 delete mode 100644 tests/qapi-schema/escape-too-short.json
 delete mode 100644 tests/qapi-schema/escape-too-short.out

diff --git a/scripts/qapi/common.py b/scripts/qapi/common.py
index c3dfad024f..f5583d3eac 100644
--- a/scripts/qapi/common.py
+++ b/scripts/qapi/common.py
@@ -523,27 +523,7 @@ class QAPISchemaParser(object):
 if ch == '\n':
 raise QAPIParseError(self, 'Missing terminating "\'"')
 if esc:
-if ch == 'u':
-value = 0
-for _ in range(0, 4):
-ch = self.src[self.cursor]
-self.cursor += 1
-if ch not in '0123456789abcdefABCDEF':
-raise QAPIParseError(self,
- '\\u escape needs 4 '
- 'hex digits')
-value = (value << 4) + int(ch, 16)
-# If Python 2 and 3 didn't disagree so much on
-# how to handle Unicode, then we could allow
-# Unicode string defaults.  But most of QAPI is
-# ASCII-only, so we aren't losing much for now.
-if not value or value > 0x7f:
-raise QAPIParseError(self,
- 'For now, \\u escape '
- 'only supports non-zero '
- 'values up to \\u007f')
-ch = chr(value)
-elif ch not in '\\/\'"':
+if ch != '\\':
 raise QAPIParseError(self,
  "Unknown escape \\%s" % ch)
 esc = False
diff --git a/tests/Makefile.include b/tests/Makefile.include
index 403748579f..3723496959 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -375,9 +375,6 @@ qapi-schema += enum-int-member.json
 qapi-schema += enum-member-case.json
 qapi-schema += enum-missing-data.json
 qapi-schema += enum-wrong-data.json
-qapi-schema += escape-outside-string.json
-qapi-schema += escape-too-big.json
-qapi-schema += escape-too-short.json
 qapi-schema += event-boxed-empty.json
 qapi-schema += event-case.json
 qapi-schema += event-member-invalid-dict.json
diff --git a/tests/qapi-schema/escape-outside-string.err 
b/tests/qapi-schema/escape-outside-string.err
deleted file mode 100644
index b9b8837fd2..00
--- a/tests/qapi-schema/escape-outside-string.err
+++ /dev/null
@@ -1 +0,0 @@
-tests/qapi-schema/escape-outs

[Qemu-devel] [PATCH v2 14/16] docs/devel/qapi-code-gen: Rewrite introduction to schema

2019-09-09 Thread Markus Armbruster
The introduction to the QAPI schema is somewhat rambling.  Rewrite for
clarity.

Signed-off-by: Markus Armbruster 
---
 docs/devel/qapi-code-gen.txt | 106 ---
 1 file changed, 47 insertions(+), 59 deletions(-)

diff --git a/docs/devel/qapi-code-gen.txt b/docs/devel/qapi-code-gen.txt
index d09232009e..54a324cc69 100644
--- a/docs/devel/qapi-code-gen.txt
+++ b/docs/devel/qapi-code-gen.txt
@@ -16,65 +16,53 @@ well as the QEMU Guest Agent (QGA) for communicating with 
the guest.
 The remainder of this document uses "Client JSON Protocol" when
 referring to the wire contents of a QMP or QGA connection.
 
-To map Client JSON Protocol interfaces to the native C QAPI
-implementations, a JSON-based schema is used to define types and
-function signatures, and a set of scripts is used to generate types,
-signatures, and marshaling/dispatch code. This document will describe
-how the schemas, scripts, and resulting code are used.
-
-
-== QMP/Guest agent schema ==
-
-A QAPI schema file is designed to be loosely based on JSON
-(http://www.ietf.org/rfc/rfc8259.txt) with changes for quoting style
-and the use of comments; a QAPI schema file is then parsed by a python
-code generation program.  A valid QAPI schema consists of a series of
-top-level expressions, with no commas between them.  Where
-dictionaries (JSON objects) are used, they are parsed as python
-OrderedDicts so that ordering is preserved (for predictable layout of
-generated C structs and parameter lists).  Ordering doesn't matter
-between top-level expressions or the keys within an expression, but
-does matter within dictionary values for 'data' and 'returns' members
-of a single expression.  QAPI schema input is written using 'single
-quotes' instead of JSON's "double quotes" (in contrast, Client JSON
-Protocol uses no comments, and while input accepts 'single quotes' as
-an extension, output is strict JSON using only "double quotes").  As
-in JSON, trailing commas are not permitted in arrays or dictionaries.
-Input must be ASCII (although QMP supports full Unicode strings, the
-QAPI parser does not).  At present, there is no place where a QAPI
-schema requires the use of JSON numbers or null.
-
-
-=== Comments ===
-
-Comments are allowed; anything between an unquoted # and the following
-newline is ignored.
-
-
-=== Schema overview ===
-
-The schema sets up a series of types, as well as commands and events
-that will use those types.  Forward references are allowed: the parser
-scans in two passes, where the first pass learns all type names, and
-the second validates the schema and generates the code.  This allows
-the definition of complex structs that can have mutually recursive
-types, and allows for indefinite nesting of Client JSON Protocol that
-satisfies the schema.  A type name should not be defined more than
-once.  It is permissible for the schema to contain additional types
-not used by any commands or events in the Client JSON Protocol, for
-the side effect of generated C code used internally.
-
-There are eight top-level expressions recognized by the parser:
-'include', 'pragma', 'command', 'struct', 'enum', 'union',
-'alternate', and 'event'.  There are several groups of types: simple
-types (a number of built-in types, such as 'int' and 'str'; as well as
-enumerations), complex types (structs and two flavors of unions), and
-alternate types (a choice between other types).  The 'command' and
-'event' expressions can refer to existing types by name, or list an
-anonymous type as a dictionary. Listing a type name inside an array
-refers to a single-dimension array of that type; multi-dimension
-arrays are not directly supported (although an array of a complex
-struct that contains an array member is possible).
+To map between Client JSON Protocol interfaces and the native C API,
+we generate C code from a QAPI schema.  This document describes the
+QAPI schema language, and how it gets mapped to the Client JSON
+Protocol and to C.  It additionally provides guidance on maintaining
+Client JSON Protocol compatibility.
+
+
+== The QAPI schema language ==
+
+The QAPI schema defines the Client JSON Protocol's commands and
+events, as well as types used by them.  Forward references are
+allowed.
+
+It is permissible for the schema to contain additional types not used
+by any commands or events, for the side effect of generated C code
+used internally.
+
+There are several kinds of types: simple types (a number of built-in
+types, such as 'int' and 'str'; as well as enumerations), arrays,
+complex types (structs and two flavors of unions), and alternate types
+(a choice between other types).
+
+
+=== Schema syntax ===
+
+Syntax is loosely based on JSON (http://www.ietf.org/rfc/rfc8259.txt).
+Differences:
+
+* Comments: start with a hash character (#) that is not part of a
+  string, and extend to the end of the line.
+
+* Strings are enclosed in 'single quotes', not "double quotes".
+
+* Strings are restricted to ASCII.

[Qemu-devel] [PATCH v2 01/16] scripts/git.orderfile: Match QAPI schema more precisely

2019-09-09 Thread Markus Armbruster
Pattern *.json also matches the tests/qapi-schema/*.json.  Separates
them from the tests/qapi-schema/*.{err,exit,out} in diffs.  I hate
that.  Change the pattern to match just the "real" QAPI schemata.

Signed-off-by: Markus Armbruster 
---
 scripts/git.orderfile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/git.orderfile b/scripts/git.orderfile
index ac699700b1..e89790941c 100644
--- a/scripts/git.orderfile
+++ b/scripts/git.orderfile
@@ -19,11 +19,11 @@ Makefile*
 *.mak
 
 # qapi schema
-*.json
+qapi/*.json
+qga/*.json
 
 # headers
 *.h
 
 # code
 *.c
-
-- 
2.21.0




[Qemu-devel] [PATCH v2 11/16] qapi: Adjust frontend errors to say enum value, not member

2019-09-09 Thread Markus Armbruster
For consistency with docs/devel/qapi-code-gen.txt.

Signed-off-by: Markus Armbruster 
---
 scripts/qapi/common.py  | 11 ---
 tests/qapi-schema/enum-clash-member.err |  2 +-
 tests/qapi-schema/enum-member-case.err  |  2 +-
 3 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/scripts/qapi/common.py b/scripts/qapi/common.py
index b797924539..f4630a5dd3 100644
--- a/scripts/qapi/common.py
+++ b/scripts/qapi/common.py
@@ -1337,7 +1337,7 @@ class QAPISchemaEnumType(QAPISchemaType):
 def __init__(self, name, info, doc, ifcond, members, prefix):
 QAPISchemaType.__init__(self, name, info, doc, ifcond)
 for m in members:
-assert isinstance(m, QAPISchemaMember)
+assert isinstance(m, QAPISchemaEnumMember)
 m.set_owner(name)
 assert prefix is None or isinstance(prefix, str)
 self.members = members
@@ -1548,6 +1548,10 @@ class QAPISchemaMember(object):
 return "'%s' %s" % (self.name, self._pretty_owner())
 
 
+class QAPISchemaEnumMember(QAPISchemaMember):
+role = 'value'
+
+
 class QAPISchemaFeature(QAPISchemaMember):
 role = 'feature'
 
@@ -1804,7 +1808,8 @@ class QAPISchema(object):
 return [QAPISchemaFeature(f['name'], f.get('if')) for f in features]
 
 def _make_enum_members(self, values):
-return [QAPISchemaMember(v['name'], v.get('if')) for v in values]
+return [QAPISchemaEnumMember(v['name'], v.get('if'))
+for v in values]
 
 def _make_implicit_enum_type(self, name, info, ifcond, values):
 # See also QAPISchemaObjectTypeMember._pretty_owner()
@@ -2220,7 +2225,7 @@ const QEnumLookup %(c_name)s_lookup = {
 
 def gen_enum(name, members, prefix=None):
 # append automatically generated _MAX value
-enum_members = members + [QAPISchemaMember('_MAX')]
+enum_members = members + [QAPISchemaEnumMember('_MAX')]
 
 ret = mcgen('''
 
diff --git a/tests/qapi-schema/enum-clash-member.err 
b/tests/qapi-schema/enum-clash-member.err
index 5403c78507..8238d2e807 100644
--- a/tests/qapi-schema/enum-clash-member.err
+++ b/tests/qapi-schema/enum-clash-member.err
@@ -1 +1 @@
-tests/qapi-schema/enum-clash-member.json:2: 'one_two' (member of MyEnum) 
collides with 'one-two' (member of MyEnum)
+tests/qapi-schema/enum-clash-member.json:2: 'one_two' (value of MyEnum) 
collides with 'one-two' (value of MyEnum)
diff --git a/tests/qapi-schema/enum-member-case.err 
b/tests/qapi-schema/enum-member-case.err
index 3c67a3a067..5d689e92d5 100644
--- a/tests/qapi-schema/enum-member-case.err
+++ b/tests/qapi-schema/enum-member-case.err
@@ -1 +1 @@
-tests/qapi-schema/enum-member-case.json:4: 'Value' (member of 
NoWayThisWillGetWhitelisted) should not use uppercase
+tests/qapi-schema/enum-member-case.json:4: 'Value' (value of 
NoWayThisWillGetWhitelisted) should not use uppercase
-- 
2.21.0




[Qemu-devel] [PATCH v2 03/16] qapi: Drop support for boxed alternate arguments

2019-09-09 Thread Markus Armbruster
Commands and events can define their argument type inline (default) or
by referring to another type ('boxed': true, since commit c818408e44
"qapi: Implement boxed types for commands/events", v2.7.0).  The
unboxed inline definition is an (anonymous) struct type.  The boxed
type may be a struct, union, or alternate type.

The latter is problematic: docs/interop/qemu-spec.txt requires the
value of the 'data' key to be a json-object, but any non-degenerate
alternate type has at least one branch that isn't.

Fortunately, we haven't made use of alternates in this context outside
tests/.  Drop support for them.

QAPISchemaAlternateType.is_empty() is now unused.  Drop it, too.

Signed-off-by: Markus Armbruster 
---
 docs/devel/qapi-code-gen.txt| 12 ++--
 scripts/qapi/common.py  | 15 ---
 tests/qapi-schema/qapi-schema-test.json |  2 +-
 tests/qapi-schema/qapi-schema-test.out  |  2 +-
 4 files changed, 12 insertions(+), 19 deletions(-)

diff --git a/docs/devel/qapi-code-gen.txt b/docs/devel/qapi-code-gen.txt
index e8ec8ac1de..3d3931fb7a 100644
--- a/docs/devel/qapi-code-gen.txt
+++ b/docs/devel/qapi-code-gen.txt
@@ -612,9 +612,9 @@ the command.  Normally, 'data' is a dictionary for an 
anonymous type,
 or names a struct type (possibly empty, but not a union), and its
 members are passed as separate arguments to this function.  If the
 command definition includes a key 'boxed' with the boolean value true,
-then 'data' is instead the name of any non-empty complex type
-(struct, union, or alternate), and a pointer to that QAPI type is
-passed as a single argument.
+then 'data' is instead the name of any non-empty complex type (struct
+or union), and a pointer to that QAPI type is passed as a single
+argument.
 
 The generator also emits a marshalling function that extracts
 arguments for the user's function out of an input QDict, calls the
@@ -714,9 +714,9 @@ The generator emits a function to send the event.  
Normally, 'data' is
 a dictionary for an anonymous type, or names a struct type (possibly
 empty, but not a union), and its members are passed as separate
 arguments to this function.  If the event definition includes a key
-'boxed' with the boolean value true, then 'data' is instead the name of
-any non-empty complex type (struct, union, or alternate), and a
-pointer to that QAPI type is passed as a single argument.
+'boxed' with the boolean value true, then 'data' is instead the name
+of any non-empty complex type (struct or union), and a pointer to that
+QAPI type is passed as a single argument.
 
 
 === Features ===
diff --git a/scripts/qapi/common.py b/scripts/qapi/common.py
index 9aefcfe015..54d02458b5 100644
--- a/scripts/qapi/common.py
+++ b/scripts/qapi/common.py
@@ -840,7 +840,7 @@ def check_command(expr, info):
 
 args_meta = ['struct']
 if boxed:
-args_meta += ['union', 'alternate']
+args_meta += ['union']
 check_type(info, "'data' for command '%s'" % name,
expr.get('data'), allow_dict=not boxed,
allow_metas=args_meta)
@@ -858,7 +858,7 @@ def check_event(expr, info):
 
 meta = ['struct']
 if boxed:
-meta += ['union', 'alternate']
+meta += ['union']
 check_type(info, "'data' for event '%s'" % name,
expr.get('data'), allow_dict=not boxed,
allow_metas=meta)
@@ -1690,9 +1690,6 @@ class QAPISchemaAlternateType(QAPISchemaType):
 visitor.visit_alternate_type(self.name, self.info, self.ifcond,
  self.variants)
 
-def is_empty(self):
-return False
-
 
 class QAPISchemaCommand(QAPISchemaEntity):
 def __init__(self, name, info, doc, ifcond, arg_type, ret_type,
@@ -1714,15 +1711,13 @@ class QAPISchemaCommand(QAPISchemaEntity):
 QAPISchemaEntity.check(self, schema)
 if self._arg_type_name:
 self.arg_type = schema.lookup_type(self._arg_type_name)
-assert (isinstance(self.arg_type, QAPISchemaObjectType) or
-isinstance(self.arg_type, QAPISchemaAlternateType))
+assert isinstance(self.arg_type, QAPISchemaObjectType)
 self.arg_type.check(schema)
 if self.boxed:
 if self.arg_type.is_empty():
 raise QAPISemError(self.info,
"Cannot use 'boxed' with empty type")
 else:
-assert not isinstance(self.arg_type, QAPISchemaAlternateType)
 assert not self.arg_type.variants
 elif self.boxed:
 raise QAPISemError(self.info, "Use of 'boxed' requires 'data'")
@@ -1750,15 +1745,13 @@ class QAPISchemaEvent(QAPISchemaEntity):
 QAPISchemaEntity.check(self, schema)
 if self._arg_type_name:
 self.arg_type = schema.lookup_type(self._arg_type_name)
-assert (isinstance(self.arg_type, QAPISchemaObjectType) or
-isinstance(self.arg_ty

[Qemu-devel] [PATCH v2 06/16] qapi: Restrict strings to printable ASCII

2019-09-09 Thread Markus Armbruster
RFC 8259 on string contents:

   All Unicode characters may be placed within the quotation marks,
   except for the characters that MUST be escaped: quotation mark,
   reverse solidus, and the control characters (U+ through
   U+001F).

The QAPI schema parser accepts both less and more than JSON: it
accepts only ASCII with \u (less), and accepts control characters
other than LF (new line) unescaped.  How it treats unescaped non-ASCII
input differs between Python 2 and Python 3.

Make it accept strictly less: require printable ASCII.  Drop support
for \b, \f, \n, \r, \t.

Signed-off-by: Markus Armbruster 
---
 scripts/qapi/common.py| 25 ++-
 tests/Makefile.include|  3 ++-
 tests/qapi-schema/string-code-point-127.err   |  1 +
 ...de-str.exit => string-code-point-127.exit} |  0
 tests/qapi-schema/string-code-point-127.json  |  2 ++
 ...code-str.out => string-code-point-127.out} |  0
 tests/qapi-schema/string-code-point-31.err|  1 +
 tests/qapi-schema/string-code-point-31.exit   |  1 +
 tests/qapi-schema/string-code-point-31.json   |  2 ++
 tests/qapi-schema/string-code-point-31.out|  0
 tests/qapi-schema/unicode-str.err |  1 -
 tests/qapi-schema/unicode-str.json|  2 --
 12 files changed, 17 insertions(+), 21 deletions(-)
 create mode 100644 tests/qapi-schema/string-code-point-127.err
 rename tests/qapi-schema/{unicode-str.exit => string-code-point-127.exit} 
(100%)
 create mode 100644 tests/qapi-schema/string-code-point-127.json
 rename tests/qapi-schema/{unicode-str.out => string-code-point-127.out} (100%)
 create mode 100644 tests/qapi-schema/string-code-point-31.err
 create mode 100644 tests/qapi-schema/string-code-point-31.exit
 create mode 100644 tests/qapi-schema/string-code-point-31.json
 create mode 100644 tests/qapi-schema/string-code-point-31.out
 delete mode 100644 tests/qapi-schema/unicode-str.err
 delete mode 100644 tests/qapi-schema/unicode-str.json

diff --git a/scripts/qapi/common.py b/scripts/qapi/common.py
index 54d02458b5..c3dfad024f 100644
--- a/scripts/qapi/common.py
+++ b/scripts/qapi/common.py
@@ -523,17 +523,7 @@ class QAPISchemaParser(object):
 if ch == '\n':
 raise QAPIParseError(self, 'Missing terminating "\'"')
 if esc:
-if ch == 'b':
-string += '\b'
-elif ch == 'f':
-string += '\f'
-elif ch == 'n':
-string += '\n'
-elif ch == 'r':
-string += '\r'
-elif ch == 't':
-string += '\t'
-elif ch == 'u':
+if ch == 'u':
 value = 0
 for _ in range(0, 4):
 ch = self.src[self.cursor]
@@ -552,20 +542,21 @@ class QAPISchemaParser(object):
  'For now, \\u escape '
  'only supports non-zero '
  'values up to \\u007f')
-string += chr(value)
-elif ch in '\\/\'"':
-string += ch
-else:
+ch = chr(value)
+elif ch not in '\\/\'"':
 raise QAPIParseError(self,
  "Unknown escape \\%s" % ch)
 esc = False
 elif ch == '\\':
 esc = True
+continue
 elif ch == "'":
 self.val = string
 return
-else:
-string += ch
+if ord(ch) < 32 or ord(ch) >= 127:
+raise QAPIParseError(
+self, "Funny character in string")
+string += ch
 elif self.src.startswith('true', self.pos):
 self.val = True
 self.cursor += 3
diff --git a/tests/Makefile.include b/tests/Makefile.include
index f5ac09549c..403748579f 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -452,6 +452,8 @@ qapi-schema += returns-array-bad.json
 qapi-schema += returns-dict.json
 qapi-schema += returns-unknown.json
 qapi-schema += returns-whitelist.json
+qapi-schema += string-code-point-31.json
+qapi-schema += string-code-point-127.json
 qapi-schema += struct-base-clash-deep.json
 qapi-schema += struct-base-clash.json
 qapi-schema += struct-data-invalid.json
@@ -463,7 +465,6 @@ qapi-schema += type-bypass-bad-gen.json
 qapi-schema += unclosed-list.json
 qapi-schema += unclosed-object.json
 

[Qemu-devel] [PATCH v2 04/16] docs/devel/qapi-code-gen: Minor specification fixes

2019-09-09 Thread Markus Armbruster
The specification claims "Each expression that isn't an include
directive may be preceded by a documentation block", but the code also
rejects them for pragma directives.  The code is correct.  Fix the
specification.

The specification reserves member names starting with 'has_', but the
code also reserves name 'u'.  Fix the specification.

The specification claims "The string 'max' is not allowed as an enum
value".  Untrue.  Fix the specification.  While there, delete the
naming advice, because it's redundant with the naming rules in section
"Schema overview"

The specification claims "No branch of the union can be named 'max',
as this would collide with the implicit enum".  Untrue.  Fix the
specification.

The specification claims "It is not allowed to name an event 'MAX',
since the generator also produces a C enumeration of all event names
with a generated _MAX value at the end."  Untrue.  Fix the
specification.

The specification claims "All branches of the union must be complex
types", but the code permits only struct types.  The code is correct.
Fix the specification.

The specification claims a command's return type "must be the string
name of a complex or built-in type, a one-element array containing the
name of a complex or built-in type" unless the command is in pragma
'returns-whitelist'.  The code does not permit built-in types.  Fix
the specification.

Signed-off-by: Markus Armbruster 
---
 docs/devel/qapi-code-gen.txt | 34 --
 1 file changed, 16 insertions(+), 18 deletions(-)

diff --git a/docs/devel/qapi-code-gen.txt b/docs/devel/qapi-code-gen.txt
index 3d3931fb7a..4ce67752a7 100644
--- a/docs/devel/qapi-code-gen.txt
+++ b/docs/devel/qapi-code-gen.txt
@@ -117,9 +117,9 @@ Example:
 
  Expression documentation 
 
-Each expression that isn't an include directive may be preceded by a
-documentation block.  Such blocks are called expression documentation
-blocks.
+Expressions other than include and pragma directives may be preceded
+by a documentation block.  Such blocks are called expression
+documentation blocks.
 
 When documentation is required (see pragma 'doc-required'), expression
 documentation blocks are mandatory.
@@ -243,8 +243,9 @@ underscore.
 
 Event names should be ALL_CAPS with words separated by underscore.
 
-Member names starting with 'has-' or 'has_' are reserved for the
-generator, which uses them for tracking optional members.
+Member name 'u' and names starting with 'has-' or 'has_' are reserved
+for the generator, which uses them for unions and for tracking
+optional members.
 
 Any name (command, event, type, member, or enum value) beginning with
 "x-" is marked experimental, and may be withdrawn or changed
@@ -460,15 +461,14 @@ discriminator value, as in these examples:
 
 The generated C code uses a struct containing a union. Additionally,
 an implicit C enum 'NameKind' is created, corresponding to the union
-'Name', for accessing the various branches of the union.  No branch of
-the union can be named 'max', as this would collide with the implicit
-enum.  The value for each branch can be of any type.
+'Name', for accessing the various branches of the union.  The value
+for each branch can be of any type.
 
 A flat union definition avoids nesting on the wire, and specifies a
 set of common members that occur in all variants of the union.  The
 'base' key must specify either a type name (the type must be a
 struct, not a union), or a dictionary representing an anonymous type.
-All branches of the union must be complex types, and the top-level
+All branches of the union must be struct types, and the top-level
 members of the union dictionary on the wire will be combination of
 members from both the base type and the appropriate branch type (when
 merging two dictionaries, there must be no keys in common).  The
@@ -578,8 +578,8 @@ The 'returns' member describes what will appear in the 
"return" member
 of a Client JSON Protocol reply on successful completion of a command.
 The member is optional from the command declaration; if absent, the
 "return" member will be an empty dictionary.  If 'returns' is present,
-it must be the string name of a complex or built-in type, a
-one-element array containing the name of a complex or built-in type.
+it must be the string name of a complex type, or a
+one-element array containing the name of a complex type.
 To return anything else, you have to list the command in pragma
 'returns-whitelist'.  If you do this, the command cannot be extended
 to return additional information in the future.  Use of
@@ -691,13 +691,11 @@ started with --preconfig.
 Usage: { 'event': STRING, '*data': COMPLEX-TYPE-NAME-OR-DICT,
  '*boxed': true }
 
-Events are defined with the keyword 'event'.  It is not allowed to
-name an event 'MAX', since the generator also produces a C enumeration
-of all event names with a generated _MAX value at the end.  When
-'data' is also specified, additional info will be included i

[Qemu-devel] [PATCH v2 12/16] docs/devel/qapi-code-gen: Reorder sections for readability

2019-09-09 Thread Markus Armbruster
Section "QMP/Guest agent schema" starts with a brief introduction,
then subsection "Comments", then subsection "Schema overview" (more
elaborate introduction), and only then talks about schema entities
like types, commands, and so forth.

Subsection "Comments" is long and tiring: almost 500 words, mostly
about doc comments.  Move the doc comment part to its own subsection
"Documentation comments" at the very end of "QMP/Guest agent schema".

Subsection "Schema overview" explains naming rules at considerable
length: 250 words.  Move this part to its own subsection "Naming rules
and reserved names" right after the subsections on schema entities.

Subsection "Enumeration types" is wedged between "Struct types" and
"Union types".  Move it before "Struct types".

Signed-off-by: Markus Armbruster 
---
 docs/devel/qapi-code-gen.txt | 436 ++-
 1 file changed, 221 insertions(+), 215 deletions(-)

diff --git a/docs/devel/qapi-code-gen.txt b/docs/devel/qapi-code-gen.txt
index ec2d374483..663ef10a56 100644
--- a/docs/devel/qapi-code-gen.txt
+++ b/docs/devel/qapi-code-gen.txt
@@ -50,147 +50,6 @@ schema requires the use of JSON numbers or null.
 Comments are allowed; anything between an unquoted # and the following
 newline is ignored.
 
-A multi-line comment that starts and ends with a '##' line is a
-documentation comment.  These are parsed by the documentation
-generator, which recognizes certain markup detailed below.
-
-
- Documentation markup 
-
-Comment text starting with '=' is a section title:
-
-# = Section title
-
-Double the '=' for a subsection title:
-
-# == Subsection title
-
-'|' denotes examples:
-
-# | Text of the example, may span
-# | multiple lines
-
-'*' starts an itemized list:
-
-# * First item, may span
-#   multiple lines
-# * Second item
-
-You can also use '-' instead of '*'.
-
-A decimal number followed by '.' starts a numbered list:
-
-# 1. First item, may span
-#multiple lines
-# 2. Second item
-
-The actual number doesn't matter.  You could even use '*' instead of
-'2.' for the second item.
-
-Lists can't be nested.  Blank lines are currently not supported within
-lists.
-
-Additional whitespace between the initial '#' and the comment text is
-permitted.
-
-*foo* and _foo_ are for strong and emphasis styles respectively (they
-do not work over multiple lines). @foo is used to reference a name in
-the schema.
-
-Example:
-
-##
-# = Section
-# == Subsection
-#
-# Some text foo with *strong* and _emphasis_
-# 1. with a list
-# 2. like that
-#
-# And some code:
-# | $ echo foo
-# | -> do this
-# | <- get that
-#
-##
-
-
- Expression documentation 
-
-Expressions other than include and pragma directives may be preceded
-by a documentation block.  Such blocks are called expression
-documentation blocks.
-
-When documentation is required (see pragma 'doc-required'), expression
-documentation blocks are mandatory.
-
-The documentation block consists of a first line naming the
-expression, an optional overview, a description of each argument (for
-commands and events) or member (for structs, unions and alternates),
-and optional tagged sections.
-
-FIXME: the parser accepts these things in almost any order.
-
-Extensions added after the expression was first released carry a
-'(since x.y.z)' comment.
-
-A tagged section starts with one of the following words:
-"Note:"/"Notes:", "Since:", "Example"/"Examples", "Returns:", "TODO:".
-The section ends with the start of a new section.
-
-A 'Since: x.y.z' tagged section lists the release that introduced the
-expression.
-
-For example:
-
-##
-# @BlockStats:
-#
-# Statistics of a virtual block device or a block backing device.
-#
-# @device: If the stats are for a virtual block device, the name
-#  corresponding to the virtual block device.
-#
-# @node-name: The node name of the device. (since 2.3)
-#
-# ... more members ...
-#
-# Since: 0.14.0
-##
-{ 'struct': 'BlockStats',
-  'data': {'*device': 'str', '*node-name': 'str',
-   ... more members ... } }
-
-##
-# @query-blockstats:
-#
-# Query the @BlockStats for all virtual block devices.
-#
-# @query-nodes: If true, the command will query all the
-#   block nodes ... explain, explain ...  (since 2.3)
-#
-# Returns: A list of @BlockStats for each virtual block devices.
-#
-# Since: 0.14.0
-#
-# Example:
-#
-# -> { "execute": "query-blockstats" }
-# <- {
-#  ... lots of output ...
-#}
-#
-##
-{ 'command': 'query-blockstats',
-  'data': { '*query-nodes': 'bool' },
-  'returns': ['BlockStats'] }
-
- Free-form documentation 
-
-A documentation block that isn't an expression documentation block is
-a free-form documentation block.  These may be used to provide
-additional text and structuring content.
-
 
 === Schema overview ===
 
@@ -217,43 +76,6 @@ refers to a single-dimension array of that type; 
multi-dimension
 arrays are not directly supported (although an array of a co

[Qemu-devel] [PATCH v2 05/16] tests/qapi-schema: Demonstrate bad reporting of funny characters

2019-09-09 Thread Markus Armbruster
Invalid name 'not\\possible' is reported as 'not\possible'.  Control
characters (quoted or not) are even more confusing.  Mark FIXME.

Signed-off-by: Markus Armbruster 
---
 tests/qapi-schema/enum-bad-name.err  | 2 +-
 tests/qapi-schema/enum-bad-name.json | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/tests/qapi-schema/enum-bad-name.err 
b/tests/qapi-schema/enum-bad-name.err
index 9c3c1002b7..26a09f84ad 100644
--- a/tests/qapi-schema/enum-bad-name.err
+++ b/tests/qapi-schema/enum-bad-name.err
@@ -1 +1 @@
-tests/qapi-schema/enum-bad-name.json:2: Member of enum 'MyEnum' uses invalid 
name 'not^possible'
+tests/qapi-schema/enum-bad-name.json:3: Member of enum 'MyEnum' uses invalid 
name 'not\possible'
diff --git a/tests/qapi-schema/enum-bad-name.json 
b/tests/qapi-schema/enum-bad-name.json
index 8506562b31..b233fdc825 100644
--- a/tests/qapi-schema/enum-bad-name.json
+++ b/tests/qapi-schema/enum-bad-name.json
@@ -1,2 +1,3 @@
 # we ensure all enum names can map to C
-{ 'enum': 'MyEnum', 'data': [ 'not^possible' ] }
+# FIXME reports 'not\posible' instead of 'not\\possible'
+{ 'enum': 'MyEnum', 'data': [ 'not\\possible' ] }
-- 
2.21.0




[Qemu-devel] [PATCH v2 10/16] qapi: Permit omitting all flat union branches

2019-09-09 Thread Markus Armbruster
Absent flat union branches default to the empty struct (since commit
800877bb16 "qapi: allow empty branches in flat unions").  But am
attempt to omit all of them is rejected with "Union 'FOO' has no
branches".  Harmless oddity, but it's easy to avoid, so do that.

Signed-off-by: Markus Armbruster 
---
 docs/devel/qapi-code-gen.txt|  3 +--
 scripts/qapi/common.py  | 16 
 tests/qapi-schema/flat-union-empty.err  |  2 +-
 tests/qapi-schema/flat-union-empty.json |  2 +-
 tests/qapi-schema/qapi-schema-test.json |  5 +
 tests/qapi-schema/qapi-schema-test.out  |  9 +
 tests/qapi-schema/union-empty.err   |  2 +-
 tests/qapi-schema/union-empty.json  |  2 +-
 8 files changed, 27 insertions(+), 14 deletions(-)

diff --git a/docs/devel/qapi-code-gen.txt b/docs/devel/qapi-code-gen.txt
index 4ce67752a7..ec2d374483 100644
--- a/docs/devel/qapi-code-gen.txt
+++ b/docs/devel/qapi-code-gen.txt
@@ -436,8 +436,7 @@ Union types are used to let the user choose between several 
different
 variants for an object.  There are two flavors: simple (no
 discriminator or base), and flat (both discriminator and base).  A union
 type is defined using a data dictionary as explained in the following
-paragraphs.  The data dictionary for either type of union must not
-be empty.
+paragraphs.  Unions must have at least one branch.
 
 A simple union type defines a mapping from automatic discriminator
 values to data types like in this example:
diff --git a/scripts/qapi/common.py b/scripts/qapi/common.py
index 46a4b07a04..b797924539 100644
--- a/scripts/qapi/common.py
+++ b/scripts/qapi/common.py
@@ -849,7 +849,7 @@ def check_union(expr, info):
 
 # With no discriminator it is a simple union.
 if discriminator is None:
-enum_define = None
+enum_values = members.keys()
 allow_metas = ['built-in', 'union', 'alternate', 'struct', 'enum']
 if base is not None:
 raise QAPISemError(info, "Simple union '%s' must not have a base" %
@@ -882,16 +882,17 @@ def check_union(expr, info):
'must not be conditional' %
(base, discriminator, name))
 enum_define = enum_types.get(discriminator_value['type'])
-allow_metas = ['struct']
 # Do not allow string discriminator
 if not enum_define:
 raise QAPISemError(info,
"Discriminator '%s' must be of enumeration "
"type" % discriminator)
+enum_values = enum_get_names(enum_define)
+allow_metas = ['struct']
+
+if (len(enum_values) == 0):
+raise QAPISemError(info, "Union '%s' has no branches" % name)
 
-# Check every branch; don't allow an empty union
-if len(members) == 0:
-raise QAPISemError(info, "Union '%s' cannot have empty 'data'" % name)
 for (key, value) in members.items():
 check_name(info, "Member of union '%s'" % name, key)
 
@@ -904,8 +905,8 @@ def check_union(expr, info):
 
 # If the discriminator names an enum type, then all members
 # of 'data' must also be members of the enum type.
-if enum_define:
-if key not in enum_get_names(enum_define):
+if discriminator is not None:
+if key not in enum_values:
 raise QAPISemError(info,
"Discriminator value '%s' is not found in "
"enum '%s'"
@@ -1575,7 +1576,6 @@ class QAPISchemaObjectTypeVariants(object):
 assert bool(tag_member) != bool(tag_name)
 assert (isinstance(tag_name, str) or
 isinstance(tag_member, QAPISchemaObjectTypeMember))
-assert len(variants) > 0
 for v in variants:
 assert isinstance(v, QAPISchemaObjectTypeVariant)
 self._tag_name = tag_name
diff --git a/tests/qapi-schema/flat-union-empty.err 
b/tests/qapi-schema/flat-union-empty.err
index 15754f54eb..fedbc0d1cf 100644
--- a/tests/qapi-schema/flat-union-empty.err
+++ b/tests/qapi-schema/flat-union-empty.err
@@ -1 +1 @@
-tests/qapi-schema/flat-union-empty.json:4: Union 'Union' cannot have empty 
'data'
+tests/qapi-schema/flat-union-empty.json:4: Union 'Union' has no branches
diff --git a/tests/qapi-schema/flat-union-empty.json 
b/tests/qapi-schema/flat-union-empty.json
index 77f1d9abfb..83e1cc7b96 100644
--- a/tests/qapi-schema/flat-union-empty.json
+++ b/tests/qapi-schema/flat-union-empty.json
@@ -1,4 +1,4 @@
-# flat unions cannot be empty
+# flat union discriminator cannot be empty
 { 'enum': 'Empty', 'data': [ ] }
 { 'struct': 'Base', 'data': { 'type': 'Empty' } }
 { 'union': 'Union', 'base': 'Base', 'discriminator': 'type', 'data': { } }
diff --git a/tests/qapi-schema/qapi-schema-test.json 
b/tests/qapi-schema/qapi-schema-test.json
index 8b0d47c4ab..75c42eb0e3 100644
--- a/tests/qapi-schema/qapi-schema-test.json
+++ b/tests/qapi-schema/qapi-schema-test.

Re: [Qemu-devel] [PATCH] ahci: enable pci bus master MemoryRegion before loading ahci engines

2019-09-09 Thread andychiu via Qemu-devel
Hi John, This issue can only be reproduced on Windows 10. I've observed and 
compared the behavior of Windows 10 and Windows 7. It seems Windows 7 wouldn't 
disable the PCI_COMMAND_MASTER flag when disabling ahci devices. That's why 
this issue won't happen on Win7. Here's the trace log on both guest OS, on 
disabling and re-engaging SATA disk: Windows 10, disabling SATA disk: 
ahci_port_write ahci(0x7f6da4eb1400)[0]: port write [reg:PxCI] @ 0x38: 
0x0004 handle_cmd_fis_dump ahci(0x7f6da4eb1400)[0]: FIS: 0x00: 27 80 ea 00 
00 00 00 a0 00 00 00 00 00 00 00 00 0x10: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 0x20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x30: 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x40: 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 0x50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x60: 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x70: 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 ahci_cmd_done ahci(0x7f6da4eb1400)[0]: cmd done 
ahci_port_write ahci(0x7f6da4eb1400)[0]: port write [reg:PxIS] @ 0x10: 
0x0001 ahci_mem_write_host ahci(0x7f6da4eb1400) write4 [reg:IS] @ 0x8: 
0x0001 ahci_port_write ahci(0x7f6da4eb1400)[0]: port write 
[reg:PxCI] @ 0x38: 0x0008 handle_cmd_fis_dump ahci(0x7f6da4eb1400)[0]: FIS: 
0x00: 27 80 e0 00 00 00 00 a0 00 00 00 00 00 00 00 00 0x10: 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 0x20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 0x30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x40: 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 0x50: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 0x60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x70: 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 ahci_cmd_done 
ahci(0x7f6da4eb1400)[0]: cmd done ahci_port_write ahci(0x7f6da4eb1400)[0]: port 
write [reg:PxIS] @ 0x10: 0x0001 ahci_mem_write_host ahci(0x7f6da4eb1400) 
write4 [reg:IS] @ 0x8: 0x0001 ahci_mem_write_host 
ahci(0x7f6da4eb1400) write4 [reg:GHC] @ 0x4: 0x8000 pci_cfg_write 
ich9-ahci 26:0 @0x4 <- 0x507 pci_cfg_write ich9-ahci 26:0 @0x82 <- 0x80 
pci_cfg_write ich9-ahci 26:0 @0x4 <- 0x500 pci_update_mappings_del 
d=0x7f6da4eb0b20 00:1a.0 4,0xc0a0+0x20 pci_update_mappings_del d=0x7f6da4eb0b20 
00:1a.0 5,0xfebf1000+0x1000 
-
 Windows 10, re-engaging SATA disk: pci_cfg_write ich9-ahci 26:0 @0x14 <- 0x0 
pci_cfg_write ich9-ahci 26:0 @0x18 <- 0x0 pci_cfg_write ich9-ahci 26:0 @0x1c <- 
0x0 pci_cfg_write ich9-ahci 26:0 @0x20 <- 0xc0a0 pci_cfg_write ich9-ahci 26:0 
@0x24 <- 0xfebf1000 pci_cfg_write ich9-ahci 26:0 @0x30 <- 0x0 pci_cfg_write 
ich9-ahci 26:0 @0x3c <- 0x0 pci_cfg_write ich9-ahci 26:0 @0xc <- 0x0 
pci_cfg_write ich9-ahci 26:0 @0xd <- 0x0 pci_cfg_write ich9-ahci 26:0 @0x4 <- 
0x500 pci_cfg_write ich9-ahci 26:0 @0x4 <- 0x507 pci_update_mappings_add 
d=0x7f6da4eb0b20 00:1a.0 4,0xc0a0+0x20 pci_update_mappings_add d=0x7f6da4eb0b20 
00:1a.0 5,0xfebf1000+0x1000 pci_cfg_write ich9-ahci 26:0 @0x6 <- 0xf900 
pci_cfg_write ich9-ahci 26:0 @0x4 <- 0x507 pci_cfg_write ich9-ahci 26:0 @0x82 
<- 0x80 pci_cfg_write ich9-ahci 26:0 @0x84 <- 0xfee0100c pci_cfg_write 
ich9-ahci 26:0 @0x88 <- 0x0 pci_cfg_write ich9-ahci 26:0 @0x8c <- 0x49a1 
pci_cfg_write ich9-ahci 26:0 @0x82 <- 0x81 ahci_mem_write_host 
ahci(0x7f6da4eb1400) write4 [reg:GHC] @ 0x4: 0x8002 ahci_port_write 
ahci(0x7f6da4eb1400)[1]: port write [reg:PxCLB] @ 0x0: 0x7fe9f000 
ahci_port_write ahci(0x7f6da4eb1400)[1]: port write [reg:PxCLBU] @ 0x4: 
0x ahci_port_write ahci(0x7f6da4eb1400)[1]: port write [reg:PxFB] @ 
0x8: 0x7fe9f400 ahci_port_write ahci(0x7f6da4eb1400)[1]: port write [reg:PxFBU] 
@ 0xc: 0x ahci_port_write ahci(0x7f6da4eb1400)[1]: port write 
[reg:PxCMD] @ 0x18: 0x0006 ahci_port_write ahci(0x7f6da4eb1400)[2]: port 
write [reg:PxCLB] @ 0x0: 0x7fea5000 ahci_port_write ahci(0x7f6da4eb1400)[2]: 
port write [reg:PxCLBU] @ 0x4: 0x ahci_port_write 
ahci(0x7f6da4eb1400)[2]: port write [reg:PxFB] @ 0x8: 0x7fea5400 
ahci_port_write ahci(0x7f6da4eb1400)[2]: port write [reg:PxFBU] @ 0xc: 
0x ahci_port_write ahci(0x7f6da4eb1400)[2]: port write [reg:PxCMD] @ 
0x18: 0x0006 ahci_port_write ahci(0x7f6da4eb1400)[3]: port write 
[reg:PxCLB] @ 0x0: 0x7feab000 ahci_port_write ahci(0x7f6da4eb1400)[3]: port 
write [reg:PxCLBU] @ 0x4: 0x ahci_port_write ahci(0x7f6da4eb1400)[3]: 
port write [reg:PxFB] @ 0x8: 0x7feab400 ahci_port_write 
ahci(0x7f6da4eb1400)[3]: port write [reg:PxFBU] @ 0xc: 0x 
ahci_port_write ahci(0x7f6da4eb1400)[3]: port write [reg:PxCMD] @ 0x18: 
0x0006 ahci_port_write ahci(0x7f6da4eb1400)[4]: port write [reg:PxCLB] @ 
0x0: 0x7feb1000 ahci_port_write ahci(0x7f6da4eb1400)[4]: port write 
[reg:PxCLBU] @ 0x4: 0x ahci_port_write ahci(0x7f6da4eb1400)[4]: port 
write [reg:PxFB] @ 0x8: 0x7feb1400 ahci_port_write ahci(0x7f6da4eb1400)[4]: 
port write [reg

[Qemu-devel] [PATCH] spapr/irq: Only claim VALID interrupts at the KVM level

2019-09-09 Thread Cédric Le Goater
A typical pseries VM with 16 vCPUs, one disk, one network adapater
uses less than 100 interrupts but the whole IRQ number space of the
QEMU machine is allocated at reset time and it is 8K wide. This is
wasting considerably the global IRQ space of the overall system which
has 1M interrupts per socket on a POWER9.

To optimise the HW resources, only request at the KVM level interrupts
which have been claimed. This will help up increase the maximum number
of VMs per system.

To keep migration compatibility, we introduce a machine class
attribute to adapt the reset behavior on older pseries machines.

Signed-off-by: Cédric Le Goater 
---
 include/hw/ppc/spapr.h  |  1 +
 include/hw/ppc/spapr_xive.h |  1 +
 include/hw/ppc/xics.h   |  6 ++
 hw/intc/spapr_xive.c|  1 +
 hw/intc/spapr_xive_kvm.c| 34 +++---
 hw/intc/xics.c  |  1 +
 hw/intc/xics_kvm.c  | 14 ++
 hw/ppc/spapr.c  |  1 +
 hw/ppc/spapr_irq.c  | 13 +++--
 9 files changed, 63 insertions(+), 9 deletions(-)

diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
index 03111fd55bc8..6c622954a60c 100644
--- a/include/hw/ppc/spapr.h
+++ b/include/hw/ppc/spapr.h
@@ -131,6 +131,7 @@ struct SpaprMachineClass {
 SpaprResizeHpt resize_hpt_default;
 SpaprCapabilities default_caps;
 SpaprIrq *irq;
+bool irq_reset_all;
 };
 
 /**
diff --git a/include/hw/ppc/spapr_xive.h b/include/hw/ppc/spapr_xive.h
index bfd40f01d882..b33913eb0f28 100644
--- a/include/hw/ppc/spapr_xive.h
+++ b/include/hw/ppc/spapr_xive.h
@@ -45,6 +45,7 @@ typedef struct SpaprXive {
 void  *tm_mmap;
 MemoryRegion  tm_mmio_kvm;
 VMChangeStateEntry *change;
+bool  reset_all;
 } SpaprXive;
 
 /*
diff --git a/include/hw/ppc/xics.h b/include/hw/ppc/xics.h
index f2a8d6a4b4f9..856815362406 100644
--- a/include/hw/ppc/xics.h
+++ b/include/hw/ppc/xics.h
@@ -117,6 +117,7 @@ struct ICSState {
 DeviceState parent_obj;
 /*< public >*/
 uint32_t nr_irqs;
+bool reset_all;
 uint32_t offset;
 ICSIRQState *irqs;
 XICSFabric *xics;
@@ -179,6 +180,11 @@ void ics_simple_write_xive(ICSState *ics, int nr, int 
server,
uint8_t priority, uint8_t saved_priority);
 void ics_simple_set_irq(void *opaque, int srcno, int val);
 
+static inline bool ics_irq_free(ICSState *ics, uint32_t srcno)
+{
+return !(ics->irqs[srcno].flags & XICS_FLAGS_IRQ_MASK);
+}
+
 void ics_set_irq_type(ICSState *ics, int srcno, bool lsi);
 void icp_pic_print_info(ICPState *icp, Monitor *mon);
 void ics_pic_print_info(ICSState *ics, Monitor *mon);
diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
index c1c97192a7d2..b717d9e09314 100644
--- a/hw/intc/spapr_xive.c
+++ b/hw/intc/spapr_xive.c
@@ -492,6 +492,7 @@ static Property spapr_xive_properties[] = {
 DEFINE_PROP_UINT32("nr-ends", SpaprXive, nr_ends, 0),
 DEFINE_PROP_UINT64("vc-base", SpaprXive, vc_base, SPAPR_XIVE_VC_BASE),
 DEFINE_PROP_UINT64("tm-base", SpaprXive, tm_base, SPAPR_XIVE_TM_BASE),
+DEFINE_PROP_BOOL("reset-all", ICSState, reset_all, false),
 DEFINE_PROP_END_OF_LIST(),
 };
 
diff --git a/hw/intc/spapr_xive_kvm.c b/hw/intc/spapr_xive_kvm.c
index 17af4d19f54e..225abce36270 100644
--- a/hw/intc/spapr_xive_kvm.c
+++ b/hw/intc/spapr_xive_kvm.c
@@ -253,13 +253,23 @@ void kvmppc_xive_source_reset_one(XiveSource *xsrc, int 
srcno, Error **errp)
   true, errp);
 }
 
+static bool xive_source_skip_reset(SpaprXive *xive, int srcno)
+{
+return !xive->reset_all && !xive_eas_is_valid(&xive->eat[srcno]);
+}
+
 static void kvmppc_xive_source_reset(XiveSource *xsrc, Error **errp)
 {
+SpaprXive *xive = SPAPR_XIVE(xsrc->xive);
 int i;
 
 for (i = 0; i < xsrc->nr_irqs; i++) {
 Error *local_err = NULL;
 
+if (xive_source_skip_reset(xive, i)) {
+continue;
+}
+
 kvmppc_xive_source_reset_one(xsrc, i, &local_err);
 if (local_err) {
 error_propagate(errp, local_err);
@@ -328,11 +338,18 @@ uint64_t kvmppc_xive_esb_rw(XiveSource *xsrc, int srcno, 
uint32_t offset,
 
 static void kvmppc_xive_source_get_state(XiveSource *xsrc)
 {
+SpaprXive *xive = SPAPR_XIVE(xsrc->xive);
 int i;
 
 for (i = 0; i < xsrc->nr_irqs; i++) {
+uint8_t pq;
+
+if (xive_source_skip_reset(xive, i)) {
+continue;
+}
+
 /* Perform a load without side effect to retrieve the PQ bits */
-uint8_t pq = xive_esb_read(xsrc, i, XIVE_ESB_GET);
+pq = xive_esb_read(xsrc, i, XIVE_ESB_GET);
 
 /* and save PQ locally */
 xive_source_esb_set(xsrc, i, pq);
@@ -521,9 +538,14 @@ static void kvmppc_xive_change_state_handler(void *opaque, 
int running,
  */
 if (running) {
 for (i = 0; i < xsrc->nr_irqs; i++) {
-uint8_t pq = xive_source_esb_get(xsrc, i);
+uint8_t pq;
 uint8_t old_pq;
 
+ 

[Qemu-devel] [Bug 1832250] Re: arm32v6/golang:1.10-alpine is broken for qemu 2.8 on MacOS cross-compilation

2019-09-09 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1832250

Title:
  arm32v6/golang:1.10-alpine is broken for qemu 2.8 on MacOS cross-
  compilation

Status in QEMU:
  Expired

Bug description:
  FROM arm32v6/golang:1.10-alpine

  docker build -t openhorizon/ibm.gps_arm:2.0.7 -f ./Dockerfile.arm .
  Sending build context to Docker daemon  110.6kB
  Step 1/12 : FROM arm32v6/golang:1.10-alpine
  1.10-alpine: Pulling from arm32v6/golang
  05276f4299f2: Pull complete 
  5657e63df536: Pull complete 
  febca98d0249: Pull complete 
  5053a7aa5dea: Pull complete 
  d048463a3701: Pull complete 
  b628c679d668: Pull complete 
  Digest: 
sha256:94c5fd97b17d0e9fe89e011446bedda4784cb0af7a60494989e2a21c0dcba92f
  Status: Downloaded newer image for arm32v6/golang:1.10-alpine
   ---> 3110964e8c9a
  Step 2/12 : RUN apk --no-cache update && apk add git
   ---> Running in 14ffb11506bb
  fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/main/armhf/APKINDEX.tar.gz
  fetch 
http://dl-cdn.alpinelinux.org/alpine/v3.9/community/armhf/APKINDEX.tar.gz
  v3.9.4-24-g4e2ff29bbe [http://dl-cdn.alpinelinux.org/alpine/v3.9/main]
  v3.9.4-25-g65097c9cdc [http://dl-cdn.alpinelinux.org/alpine/v3.9/community]
  OK: 9547 distinct packages available
  fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/main/armhf/APKINDEX.tar.gz
  fetch 
http://dl-cdn.alpinelinux.org/alpine/v3.9/community/armhf/APKINDEX.tar.gz
  (1/7) Installing nghttp2-libs (1.35.1-r0)
  (2/7) Installing libssh2 (1.8.2-r0)
  (3/7) Installing libcurl (7.64.0-r2)
  (4/7) Installing libgcc (8.3.0-r0)
  (5/7) Installing expat (2.2.6-r0)
  (6/7) Installing pcre2 (10.32-r1)
  (7/7) Installing git (2.20.1-r0)
  Executing busybox-1.29.3-r10.trigger
  OK: 18 MiB in 22 packages
  Removing intermediate container 14ffb11506bb
   ---> 6890ea7ed09b
  Step 3/12 : RUN mkdir -p /build/bin
   ---> Running in 44e52d78d7b4
  Removing intermediate container 44e52d78d7b4
   ---> 0763afda41d1
  Step 4/12 : COPY src /build/src
   ---> 05bab9a72a34
  Step 5/12 : WORKDIR /build
   ---> Running in 5a663caff249
  Removing intermediate container 5a663caff249
   ---> 5a6ca53c00de
  Step 6/12 : RUN env GOPATH=/build GOOPTIONS_ARM='CGO_ENABLED=0 GOOS=linux 
GOARCH=arm GOARM=6' go get github.com/kellydunn/golang-geo
   ---> Running in 05b09ee0c206
  Removing intermediate container 05b09ee0c206
   ---> e68c6e222e51
  Step 7/12 : RUN env GOPATH=/build GOOPTIONS_ARM='CGO_ENABLED=0 GOOS=linux 
GOARCH=arm GOARM=6' go build -o /build/bin/armv6_gps /build/src/main.go
   ---> Running in ea6d2707e35f
  qemu-arm: /build/qemu-rwi8RH/qemu-2.8+dfsg/translate-all.c:175: tb_lock: 
Assertion `!have_tb_lock' failed.
  qemu-arm: /build/qemu-rwi8RH/qemu-2.8+dfsg/translate-all.c:175: tb_lock: 
Assertion `!have_tb_lock' failed.
  The command '/bin/sh -c env GOPATH=/build GOOPTIONS_ARM='CGO_ENABLED=0 
GOOS=linux GOARCH=arm GOARM=6' go build -o /build/bin/armv6_gps 
/build/src/main.go' returned a non-zero code: 139
  make: *** [build] Error 139

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1832250/+subscriptions



[Qemu-devel] [Bug 1805256] Re: qemu-img hangs on high core count ARM system

2019-09-09 Thread Rafael David Tinoco
Alright,

I'm still investigating this but wanted to share some findings... I
haven't got a kernel dump yet after the task is frozen, I have analyzed
only the userland part of it (although I have checked if code was
running inside kernel with perf cycles:u/cycles:k at some point).

The big picture is this: Whenever qemu-img hangs, we have 3 hung tasks
basically with these stacks:



TRHREAD #1
__GI_ppoll (../sysdeps/unix/sysv/linux/ppoll.c:39)
ppoll (/usr/include/aarch64-linux-gnu/bits/poll2.h:77)
qemu_poll_ns (./util/qemu-timer.c:322)
os_host_main_loop_wait (./util/main-loop.c:233)
main_loop_wait (./util/main-loop.c:497)
convert_do_copy (./qemu-img.c:1981)
img_convert (./qemu-img.c:2457)
main (./qemu-img.c:4976)

got stack traces:

./33293/stack  ./33293/stack 
[<0>] __switch_to+0xc0/0x218   [<0>] __switch_to+0xc0/0x218  
[<0>] ptrace_stop+0x148/0x2b0  [<0>] do_sys_poll+0x508/0x5c0 
[<0>] get_signal+0x5a4/0x730   [<0>] __arm64_sys_ppoll+0xc0/0x118
[<0>] do_notify_resume+0x158/0x358 [<0>] el0_svc_common+0xa0/0x168   
[<0>] work_pending+0x8/0x10[<0>] el0_svc_handler+0x38/0x78   
   [<0>] el0_svc+0x8/0xc  

root@d06-1:~$ perf record -F  -e cycles:u -p 33293 -- sleep 10
[ perf record: Woken up 6 times to write data ]
[ perf record: Captured and wrote 1.871 MB perf.data (48730 samples) ]

root@d06-1:~$ perf report --stdio
# Overhead  Command   Shared Object   Symbol
#     ..  ..
#
37.82%  qemu-img  libc-2.29.so[.] 0x000df710
21.81%  qemu-img  [unknown]   [k] 0x10099504
14.23%  qemu-img  [unknown]   [k] 0x10085dc0
 9.13%  qemu-img  [unknown]   [k] 0x1008fff8
 6.47%  qemu-img  libc-2.29.so[.] 0x000df708
 5.69%  qemu-img  qemu-img[.] qemu_event_reset
 2.57%  qemu-img  libc-2.29.so[.] 0x000df678
 0.63%  qemu-img  libc-2.29.so[.] 0x000df700
 0.49%  qemu-img  libc-2.29.so[.] __sigtimedwait
 0.42%  qemu-img  libpthread-2.29.so  [.] __libc_sigwait



TRHREAD #3
__GI___sigtimedwait (../sysdeps/unix/sysv/linux/sigtimedwait.c:29)
__sigwait (linux/sigwait.c:28)
qemu_thread_start (./util/qemu-thread-posix.c:498)
start_thread (pthread_create.c:486)
thread_start (linux/aarch64/clone.S:78)


./33303/stack  ./33303/stack
   
[<0>] __switch_to+0xc0/0x218   [<0>] __switch_to+0xc0/0x218 
   
[<0>] ptrace_stop+0x148/0x2b0  [<0>] do_sigtimedwait.isra.9+0x194/0x288 
   
[<0>] get_signal+0x5a4/0x730   [<0>] 
__arm64_sys_rt_sigtimedwait+0xac/0x110
[<0>] do_notify_resume+0x158/0x358 [<0>] el0_svc_common+0xa0/0x168  
   
[<0>] work_pending+0x8/0x10[<0>] el0_svc_handler+0x38/0x78  
   
   [<0>] el0_svc+0x8/0xc   

root@d06-1:~$ perf record -F  -e cycles:u -p 33303 -- sleep 10
[ perf record: Woken up 6 times to write data ]
[ perf record: Captured and wrote 1.905 MB perf.data (49647 samples) ]

root@d06-1:~$ perf report --stdio
# Overhead  Command   Shared Object   Symbol
#     ..  ..
#
45.37%  qemu-img  libc-2.29.so[.] 0x000df710
23.52%  qemu-img  [unknown]   [k] 0x10099504
 9.08%  qemu-img  [unknown]   [k] 0x1008fff8
 8.89%  qemu-img  [unknown]   [k] 0x10085dc0
 5.56%  qemu-img  libc-2.29.so[.] 0x000df708
 3.66%  qemu-img  libc-2.29.so[.] 0x000df678
 1.01%  qemu-img  libc-2.29.so[.] __sigtimedwait
 0.80%  qemu-img  libc-2.29.so[.] 0x000df700
 0.64%  qemu-img  qemu-img[.] qemu_event_reset
 0.55%  qemu-img  libc-2.29.so[.] 0x000df718
 0.52%  qemu-img  libpthread-2.29.so  [.] __libc_sigwait



TRHREAD #2
syscall (linux/aarch64/syscall.S:38)
qemu_futex_wait (./util/qemu-thread-posix.c:438)
qemu_event_wait (./util/qemu-thread-posix.c:442)
call_rcu_thread (./util/rcu.c:261)
qemu_thread_start (./util/qemu-thread-posix.c:498)
start_thread (pthread_create.c:486)
thread_start (linux/aarch64/clone.S:78)

./33302/stack  ./33302/stack   
[<0>] __switch_to+0xc0/0x218   [<0>] __switch_to+0xc0/0x218
[<0>] ptrace_stop+0x148/0x2b0  [<0>] ptrace_stop+0x148/0x2b0   
[<0>] get_signal+0x5a4/0x730   [<0>] get_signal+0x5a4/0x730
[<0>] do_notify_resume+0x1c4/0x358 [<0>] do_notify_resume+0x1c4/0x358  
[<0>] work_pending+0x8/0x10[<0>] work_pending+0x8/0x10



root@d06-1:~$ perf report --stdio
# Overhead  Command   Shared Object   Symbol
#     ..

Re: [Qemu-devel] [PATCH v2 4/4] audio: paaudio: ability to specify stream name

2019-09-09 Thread Zoltán Kővágó

On 2019-08-28 12:39, Maxim Levitsky wrote:

On Wed, 2019-08-28 at 11:26 +0100, Daniel P. Berrangé wrote:

On Wed, Aug 28, 2019 at 01:14:03PM +0300, Maxim Levitsky wrote:

On Wed, 2019-08-28 at 10:53 +0100, Daniel P. Berrangé wrote:

On Wed, Aug 28, 2019 at 12:43:49AM +0200, Zoltán Kővágó wrote:

On 2019-08-27 07:42, Gerd Hoffmann wrote:

On Mon, Aug 26, 2019 at 09:59:04PM +0200, Kővágó, Zoltán wrote:

This can be used to identify stream in tools like pavucontrol when one
creates multiple -audiodevs or runs multiple qemu instances.


Hmm, can we create an useful name automatically, without yet another
config option?

Useful choices could be the device name (usb-audio, ...) or the device
id (whatever -device id=xxx was specified on the command line).


I'm afraid this is not going to work with the current architecture: due
to mixeng even if you have multiple devices, they'll be mixed to a
single stream and the audio backend will only see this one mixed stream.
  As a workaround we could do something like concat all device names or
ids, but I don't like that idea.

Alternatively we could use the id of the audiodev instead, and no more
problems with mixeng.  However, with mixeng off (implemented in my next
patch series) suddenly soundcards will have suddenly end up as different
streams.  (This can be worked around by creating multiple audiodevs,
like what you have to use now to get multiple streams from pa, so this
is probably a smaller problem.)

Currently I'm leaning for the audiodev's id option, unless someone
proposes something better.


Using the audiodev id is not a good idea. If you have multiple QEMU's
on your host, it is highly likely that libvirt will have assigned
the same audiodev id to all of them.  Using the vm name would be ok,
but only if you assume that each gust only has a single audio device.

Using a combination of vm name + audidev id is going to be unique
per host, but not especially friendly as a user visible name. It
would be ok as a default, but I'd think we should let the mgmt app
specify stream name explicitly, so that something user friendly
can be set.


No, no!
It seems that pulseaudio has a name for each connection, and a name for each
steam within that connection.

The suggestion is that we use the VM name for the connection,
(which will be unique per VM usually, at least the user can make it be so)
and then use the audiodev id for each stream. Of course for multiple VMs,
the audiodev ids will be the same, but this is all right since you can
always distinguish them that the streams come from different VMs.


Ok, if I'm reading the code correctly, it seems we do take care to
re-use a single connection to PA for all audiodevs we create. So a
VMname is fine for the connection.


Also note that this thing is cosmetic from the correctness point of view,
that is pulse-audio internally has no problem with duplicate IDs.

The thing is useful mostly for tweaking the output streams in the pavucontrol,
where the names will allow you to easily know which steam is which.


Yep, I wasn't really concerned about internals - from the user POV being
able to accurately distinguish streams in pavucontrol is very important
though, so we should ensure that's possible. If we use 'id'  for the
stream as a default though, we should still allow an override, as 'id'
values are not really intended as end user visible data. If a guest
has multiple devices I'd expect to be able to give them names that are
meaningful to me as a user, not something libvirt auto-generates for
its own machine oriented use.


I have absolutely nothing against user specified override!
Just that if the idea is shot down, lets at least have device id instead.


For the reference this is how currently the sound streams are shown,
without any patches applied
https://imgur.com/a/I8HZhgx

Gnome sound panel only shows application names,
but pavucontrol shows both the application name and stream name.

Best regards,
Maxim Levitsky



Ping.

If I understand the situation correctly, the current consensus is:

* use VM name for PA server connection
* audiodev id is a good default for PA stream name

What is not clear whether we need a separate qapi option for stream 
name, or just always use the audiodev id.  I don't use pulseaudio or 
libvirt, so I can't really comment about this issue.


Ideally I'd like to create a new patch with this change and a fix for 
the coverity issue reported in [1].


Regards,
Zoltan

[1]: https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg01543.html



Re: [Qemu-devel] [PATCH] spapr-tpm-proxy: Drop misleading check

2019-09-09 Thread David Gibson
On Mon, Sep 09, 2019 at 08:10:09PM +0200, Greg Kurz wrote:
> Coverity is reporting in CID 1405304 that tpm_execute() may pass a NULL
> tpm_proxy->host_path pointer to open(). This is based on the fact that
> h_tpm_comm() does a NULL check on tpm_proxy->host_path and then passes
> tpm_proxy to tpm_execute().
> 
> The check in h_tpm_comm() is abusive actually since a spapr-proxy-tpm
> requires a non NULL host_path property, as checked during realize.
> 
> Fixes: 0fb6bd073230
> Signed-off-by: Greg Kurz 

Applied to ppc-for-4.2, thanks.

> ---
>  hw/ppc/spapr_tpm_proxy.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/ppc/spapr_tpm_proxy.c b/hw/ppc/spapr_tpm_proxy.c
> index b835d25be6f6..ca1caec113f0 100644
> --- a/hw/ppc/spapr_tpm_proxy.c
> +++ b/hw/ppc/spapr_tpm_proxy.c
> @@ -114,7 +114,7 @@ static target_ulong h_tpm_comm(PowerPCCPU *cpu,
>  return H_FUNCTION;
>  }
>  
> -trace_spapr_h_tpm_comm(tpm_proxy->host_path ?: "null", op);
> +trace_spapr_h_tpm_comm(tpm_proxy->host_path, op);
>  
>  switch (op) {
>  case TPM_COMM_OP_EXECUTE:
> 

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature


Re: [Qemu-devel] [Qemu-block] [PATCH v4 1/5] tests/qemu-iotests: Fix qemu-io related output in 026.out.nocache

2019-09-09 Thread John Snow



On 8/16/19 11:30 AM, Vladimir Sementsov-Ogievskiy wrote:
> qemu-io now prefixes its error and warnings with "qemu-io:".
> 36b9986b08787019e fixed a lot of iotests output but forget about
> 026.out.nocache. Fix it too.
> 
> Fixes: 99e98d7c9fc1a1639fad ("qemu-io: Use error_[gs]et_progname()")
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> ---
>  tests/qemu-iotests/026.out.nocache | 168 ++---
>  1 file changed, 84 insertions(+), 84 deletions(-)
> 

Thanks!

Reviewed-by: John Snow 

--js



Re: [Qemu-devel] [PATCH 3/3] hw/mips/mips_jazz: Remove no-longer-necessary override of do_unassigned_access

2019-09-09 Thread Hervé Poussineau

Le 02/08/2019 à 18:04, Peter Maydell a écrit :

Now that the MIPS CPU implementation uses the new
do_transaction_failed hook, we can remove the old code that handled
the do_unassigned_access hook.

Signed-off-by: Peter Maydell 
---
  hw/mips/mips_jazz.c | 27 ---
  1 file changed, 4 insertions(+), 23 deletions(-)


Tested-by: Hervé Poussineau 




Re: [Qemu-devel] [PATCH 2/3] target/mips: Switch to do_transaction_failed() hook

2019-09-09 Thread Hervé Poussineau

Le 02/08/2019 à 18:04, Peter Maydell a écrit :

Switch the MIPS target from the old unassigned_access hook to the new
do_transaction_failed hook.

Unlike the old hook, do_transaction_failed is only ever called from
the TCG memory access paths, so there is no need for the "ignore this
if we're using KVM" hack that we were previously using to work around
the way unassigned_access was called for all kinds of memory accesses
to unassigned physical addresses.

The MIPS target does not ever do direct memory reads by physical
address (via either ldl_phys etc or address_space_ldl etc), so the
only memory accesses this affects are the 'normal' guest loads and
stores, which will be handled by the new hook; their behaviour is
unchanged.

Signed-off-by: Peter Maydell 
---
  target/mips/internal.h  |  8 +---
  target/mips/cpu.c   |  2 +-
  target/mips/op_helper.c | 24 
  3 files changed, 14 insertions(+), 20 deletions(-)


Tested-by: Hervé Poussineau 




Re: [Qemu-devel] [PATCH 1/3] hw/mips/mips_jazz: Override do_transaction_failed hook

2019-09-09 Thread Hervé Poussineau

Le 02/08/2019 à 18:04, Peter Maydell a écrit :

The MIPS Jazz ('magnum' and 'pica61') boards have some code which
overrides the CPU's do_unassigned_access hook, so they can intercept
it and not raise exceptions on data accesses to invalid addresses,
only for instruction fetches.

We want to switch MIPS over to using the do_transaction_failed
hook instead, so add an intercept for that as well, and make
the board code install whichever hook the CPU is actually using.
Once we've changed the CPU implementation we can remove the
redundant code for the old hook.

Note: I am suspicious that the behaviour as implemented here may not
be what the hardware really does.  It was added in commit
54e755588cf1e90f0b14 to restore the behaviour that was broken by
commit c658b94f6e8c206c59d.  But prior to commit c658b94f6e8c206c59d
every MIPS board generated exceptions for instruction access to
invalid addresses but not for data accesses; and other boards,
notably Malta, were fixed by making all invalid accesses behave as
reads-as-zero (see the call to empty_slot_init() in
mips_malta_init()).  Hardware that raises exceptions for instruction
access and not data access seems to me to be an unlikely design, and
it's possible that the right way to emulate this is to make the Jazz
boards do what we did with Malta (or some variation of that).
Nonetheless, since I don't have access to real hardware to test
against I have taken the approach of "make QEMU continue to behave
the same way it did before this commit".  I have updated the comment
to correct the parts that are no longer accurate and note that
the hardware might behave differently.

The test case for the need for the hook-hijacking is in
https://bugs.launchpad.net/qemu/+bug/1245924 That BIOS will boot OK
either with this overriding of both hooks, or with a simple "global
memory region to ignore bad accesses of all types", so it doesn't
provide evidence either way, unfortunately.

Signed-off-by: Peter Maydell 


Tested-by: Hervé Poussineau 



Re: [Qemu-devel] [PATCH v9 0/9] hw/m68k: add Apple Machintosh Quadra 800 machine

2019-09-09 Thread no-reply
Patchew URL: https://patchew.org/QEMU/20190909155813.27760-1-laur...@vivier.eu/



Hi,

This series seems to have some coding style problems. See output below for
more information:

Subject: [Qemu-devel] [PATCH v9 0/9] hw/m68k: add Apple Machintosh Quadra 800 
machine
Message-id: 20190909155813.27760-1-laur...@vivier.eu
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
cf83360 hw/m68k: define Macintosh Quadra 800
71c320f hw/m68k: add a dummy SWIM floppy controller
b05e213 hw/m68k: add Nubus support for macfb video card
08872a1 hw/m68k: add Nubus support
cb97e9d hw/m68k: add macfb video card
dba185b hw/m68k: implement ADB bus support for via
6afa5ce hw/m68k: add via support
bb86a96 dp8393x: manage big endian bus
9748f16 esp: add pseudo-DMA as used by Macintosh

=== OUTPUT BEGIN ===
1/9 Checking commit 9748f16f724c (esp: add pseudo-DMA as used by Macintosh)
2/9 Checking commit bb86a967e965 (dp8393x: manage big endian bus)
3/9 Checking commit 6afa5cebce7e (hw/m68k: add via support)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#39: 
new file mode 100644

ERROR: space prohibited after that '&&' (ctx:WxW)
#387: FILE: hw/misc/mac_via.c:344:
+if (!(v1s->last_b & VIA1B_vRTCClk) && (s->b & VIA1B_vRTCClk)) {
^

total: 1 errors, 1 warnings, 814 lines checked

Patch 3/9 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

4/9 Checking commit dba185b57340 (hw/m68k: implement ADB bus support for via)
5/9 Checking commit cb97e9d367cf (hw/m68k: add macfb video card)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#53: 
new file mode 100644

total: 0 errors, 1 warnings, 504 lines checked

Patch 5/9 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
6/9 Checking commit 08872a17deea (hw/m68k: add Nubus support)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#38: 
new file mode 100644

total: 0 errors, 1 warnings, 518 lines checked

Patch 6/9 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
7/9 Checking commit b05e213d7499 (hw/m68k: add Nubus support for macfb video 
card)
8/9 Checking commit 71c320fb3e01 (hw/m68k: add a dummy SWIM floppy controller)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#37: 
new file mode 100644

total: 0 errors, 1 warnings, 510 lines checked

Patch 8/9 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
9/9 Checking commit cf833602d89e (hw/m68k: define Macintosh Quadra 800)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#96: 
new file mode 100644

total: 0 errors, 1 warnings, 539 lines checked

Patch 9/9 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20190909155813.27760-1-laur...@vivier.eu/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [Qemu-devel] [Qemu-block] [PATCH 6/6] curl: Check curl_multi_add_handle()'s return code

2019-09-09 Thread John Snow



On 8/27/19 12:34 PM, Max Reitz wrote:
> If we had done that all along, debugging would have been much simpler.
> (Also, I/O errors are better than hangs.)
> 
> Signed-off-by: Max Reitz 
> ---
>  block/curl.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/block/curl.c b/block/curl.c
> index 5e0cca601d..4a7aff02a6 100644
> --- a/block/curl.c
> +++ b/block/curl.c
> @@ -894,7 +894,13 @@ static void curl_setup_preadv(BlockDriverState *bs, 
> CURLAIOCB *acb)
>  trace_curl_setup_preadv(acb->bytes, start, state->range);
>  curl_easy_setopt(state->curl, CURLOPT_RANGE, state->range);
>  
> -curl_multi_add_handle(s->multi, state->curl);
> +if (curl_multi_add_handle(s->multi, state->curl) != CURLM_OK) {
> +state->acb[0] = NULL;
> +acb->ret = -EIO;
> +
> +curl_clean_state(state);
> +goto out;
> +}
>  
>  /* Tell curl it needs to kick things off */
>  curl_multi_socket_action(s->multi, CURL_SOCKET_TIMEOUT, 0, &running);
> 

And, well, looks fine. I think there's just a refactoring typo and maybe
explaining some curiosities to me that I am fairly sure are fine, actually.

--js



Re: [Qemu-devel] [Qemu-block] [PATCH 5/6] curl: Handle success in multi_check_completion

2019-09-09 Thread John Snow



On 8/27/19 12:34 PM, Max Reitz wrote:
> Background: As of cURL 7.59.0, it verifies that several functions are
> not called from within a callback.  Among these functions is
> curl_multi_add_handle().
> 
> curl_read_cb() is a callback from cURL and not a coroutine.  Waking up
> acb->co will lead to entering it then and there, which means the current
> request will settle and the caller (if it runs in the same coroutine)
> may then issue the next request.  In such a case, we will enter
> curl_setup_preadv() effectively from within curl_read_cb().
> 
> Calling curl_multi_add_handle() will then fail and the new request will
> not be processed.
> 
> Fix this by not letting curl_read_cb() wake up acb->co.  Instead, leave
> the whole business of settling the AIOCB objects to
> curl_multi_check_completion() (which is called from our timer callback
> and our FD read handler, so not from any cURL callbacks).
> 
> Reported-by: Natalie Gavrielov 
> Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1740193
> Cc: qemu-sta...@nongnu.org
> Signed-off-by: Max Reitz 
> ---
>  block/curl.c | 69 ++--
>  1 file changed, 29 insertions(+), 40 deletions(-)
> 
> diff --git a/block/curl.c b/block/curl.c
> index bc70f39fcb..5e0cca601d 100644
> --- a/block/curl.c
> +++ b/block/curl.c
> @@ -231,7 +231,6 @@ static size_t curl_read_cb(void *ptr, size_t size, size_t 
> nmemb, void *opaque)
>  {
>  CURLState *s = ((CURLState*)opaque);
>  size_t realsize = size * nmemb;
> -int i;
>  
>  trace_curl_read_cb(realsize);
>  
> @@ -247,32 +246,6 @@ static size_t curl_read_cb(void *ptr, size_t size, 
> size_t nmemb, void *opaque)
>  memcpy(s->orig_buf + s->buf_off, ptr, realsize);
>  s->buf_off += realsize;
>  
> -for(i=0; i -CURLAIOCB *acb = s->acb[i];
> -
> -if (!acb)
> -continue;
> -
> -if ((s->buf_off >= acb->end)) {

This changes from a conditional,

> -size_t request_length = acb->bytes;
> -
> -qemu_iovec_from_buf(acb->qiov, 0, s->orig_buf + acb->start,
> -acb->end - acb->start);
> -
> -if (acb->end - acb->start < request_length) {
> -size_t offset = acb->end - acb->start;
> -qemu_iovec_memset(acb->qiov, offset, 0,
> -  request_length - offset);
> -}
> -
> -acb->ret = 0;
> -s->acb[i] = NULL;
> -qemu_mutex_unlock(&s->s->mutex);
> -aio_co_wake(acb->co);
> -qemu_mutex_lock(&s->s->mutex);
> -}
> -}
> -
>  read_end:
>  /* curl will error out if we do not return this value */
>  return size * nmemb;
> @@ -353,13 +326,14 @@ static void curl_multi_check_completion(BDRVCURLState 
> *s)
>  break;
>  
>  if (msg->msg == CURLMSG_DONE) {
> +int i;
>  CURLState *state = NULL;
> +bool error = msg->data.result != CURLE_OK;
> +
>  curl_easy_getinfo(msg->easy_handle, CURLINFO_PRIVATE,
>(char **)&state);
>  
> -/* ACBs for successful messages get completed in curl_read_cb */
> -if (msg->data.result != CURLE_OK) {
> -int i;
> +if (error) {
>  static int errcount = 100;
>  
>  /* Don't lose the original error message from curl, since
> @@ -371,20 +345,35 @@ static void curl_multi_check_completion(BDRVCURLState 
> *s)
>  error_report("curl: further errors suppressed");
>  }
>  }
> +}
>  
> -for (i = 0; i < CURL_NUM_ACB; i++) {
> -CURLAIOCB *acb = state->acb[i];
> +for (i = 0; i < CURL_NUM_ACB; i++) {
> +CURLAIOCB *acb = state->acb[i];
>  
> -if (acb == NULL) {
> -continue;
> -}
> +if (acb == NULL) {
> +continue;
> +}
> +
> +if (!error) {
> +/* Assert that we have read all data */
> +assert(state->buf_off >= acb->end);

To an assertion. This makes me feel better (What happens if that was
ever false in the old code, we just drop the callback?) but is it
definitely always gonna be true?

Well, you are asserting it is, so I will believe you.

> +
> +qemu_iovec_from_buf(acb->qiov, 0,
> +state->orig_buf + acb->start,
> +acb->end - acb->start);
>  
> -acb->ret = -EIO;
> -state->acb[i] = NULL;
> -qemu_mutex_unlock(&s->mutex);
> -aio_co_wake(acb->co);
> -qemu_mutex_lock(&s->mutex);
> +if (acb->end - acb->start < acb->bytes) {
> +

Re: [Qemu-devel] [Qemu-block] [PATCH 4/6] curl: Report only ready sockets

2019-09-09 Thread John Snow



On 8/27/19 12:34 PM, Max Reitz wrote:
> Instead of reporting all sockets to cURL, only report the one that has
> caused curl_multi_do_locked() to be called.  This lets us get rid of the
> QLIST_FOREACH_SAFE() list, which was actually wrong: SAFE foreaches are
> only safe when the current element is removed in each iteration.  If it
> possible for the list to be concurrently modified, we cannot guarantee
> that only the current element will be removed.  Therefore, we must not
> use QLIST_FOREACH_SAFE() here.
> 
> Fixes: ff5ca1664af85b24a4180d595ea6873fd3deac57
> Cc: qemu-sta...@nongnu.org
> Signed-off-by: Max Reitz 
> ---
>  block/curl.c | 17 ++---
>  1 file changed, 6 insertions(+), 11 deletions(-)
> 
> diff --git a/block/curl.c b/block/curl.c
> index 05f77a38c2..bc70f39fcb 100644
> --- a/block/curl.c
> +++ b/block/curl.c
> @@ -394,24 +394,19 @@ static void curl_multi_check_completion(BDRVCURLState 
> *s)
>  }
>  
>  /* Called with s->mutex held.  */
> -static void curl_multi_do_locked(CURLSocket *ready_socket)
> +static void curl_multi_do_locked(CURLSocket *socket)

Only a momentary hiccup, then.

>  {
> -CURLSocket *socket, *next_socket;
> -CURLState *s = socket->state;
> +BDRVCURLState *s = socket->state->s;
>  int running;
>  int r;
>  
> -if (!s->s->multi) {
> +if (!s->multi) {
>  return;
>  }
>  
> -/* Need to use _SAFE because curl_multi_socket_action() may trigger
> - * curl_sock_cb() which might modify this list */
> -QLIST_FOREACH_SAFE(socket, &s->sockets, next, next_socket) {
> -do {
> -r = curl_multi_socket_action(s->s->multi, socket->fd, 0, 
> &running);
> -} while (r == CURLM_CALL_MULTI_PERFORM);
> -}
> +do {
> +r = curl_multi_socket_action(s->multi, socket->fd, 0, &running);
> +} while (r == CURLM_CALL_MULTI_PERFORM);
>  }
>  
>  static void curl_multi_do(void *arg)
> 

We were just calling this spuriously on whatever sockets before?

Seems like a clear improvement, then.



Re: [Qemu-devel] [Qemu-block] [PATCH 3/6] curl: Pass CURLSocket to curl_multi_{do, read}()

2019-09-09 Thread John Snow



On 8/27/19 12:34 PM, Max Reitz wrote:
> curl_multi_do_locked() currently marks all sockets as ready.  That is
> not only inefficient, but in fact unsafe (the loop is).  A follow-up
> patch will change that, but to do so, curl_multi_do_locked() needs to
> know exactly which socket is ready; and that is accomplished by this
> patch here.
> 
> Cc: qemu-sta...@nongnu.org
> Signed-off-by: Max Reitz 
> ---
>  block/curl.c | 29 -
>  1 file changed, 16 insertions(+), 13 deletions(-)
> 
> diff --git a/block/curl.c b/block/curl.c
> index 8a45b371cc..05f77a38c2 100644
> --- a/block/curl.c
> +++ b/block/curl.c
> @@ -189,15 +189,15 @@ static int curl_sock_cb(CURL *curl, curl_socket_t fd, 
> int action,
>  switch (action) {
>  case CURL_POLL_IN:
>  aio_set_fd_handler(s->aio_context, fd, false,
> -   curl_multi_read, NULL, NULL, state);
> +   curl_multi_read, NULL, NULL, socket);
>  break;
>  case CURL_POLL_OUT:
>  aio_set_fd_handler(s->aio_context, fd, false,
> -   NULL, curl_multi_do, NULL, state);
> +   NULL, curl_multi_do, NULL, socket);
>  break;
>  case CURL_POLL_INOUT:
>  aio_set_fd_handler(s->aio_context, fd, false,
> -   curl_multi_read, curl_multi_do, NULL, state);
> +   curl_multi_read, curl_multi_do, NULL, socket);
>  break;
>  case CURL_POLL_REMOVE:
>  aio_set_fd_handler(s->aio_context, fd, false,
> @@ -394,9 +394,10 @@ static void curl_multi_check_completion(BDRVCURLState *s)
>  }
>  
>  /* Called with s->mutex held.  */
> -static void curl_multi_do_locked(CURLState *s)
> +static void curl_multi_do_locked(CURLSocket *ready_socket)
>  {
>  CURLSocket *socket, *next_socket;
> +CURLState *s = socket->state;

Did you mean to use ready_socket here instead?

>  int running;
>  int r;
>  
> @@ -415,21 +416,23 @@ static void curl_multi_do_locked(CURLState *s)
>  
>  static void curl_multi_do(void *arg)
>  {
> -CURLState *s = (CURLState *)arg;
> +CURLSocket *socket = arg;
> +BDRVCURLState *s = socket->state->s;
>  
> -qemu_mutex_lock(&s->s->mutex);
> -curl_multi_do_locked(s);
> -qemu_mutex_unlock(&s->s->mutex);
> +qemu_mutex_lock(&s->mutex);
> +curl_multi_do_locked(socket);
> +qemu_mutex_unlock(&s->mutex);
>  }
>  
>  static void curl_multi_read(void *arg)
>  {
> -CURLState *s = (CURLState *)arg;
> +CURLSocket *socket = arg;
> +BDRVCURLState *s = socket->state->s;
>  
> -qemu_mutex_lock(&s->s->mutex);
> -curl_multi_do_locked(s);
> -curl_multi_check_completion(s->s);
> -qemu_mutex_unlock(&s->s->mutex);

bye bye &s->s->mutex ! you're very nasty !!

> +qemu_mutex_lock(&s->mutex);
> +curl_multi_do_locked(socket);
> +curl_multi_check_completion(s);
> +qemu_mutex_unlock(&s->mutex);
>  }
>  
>  static void curl_multi_timeout_do(void *arg)
> 



Re: [Qemu-devel] [Qemu-block] [PATCH 2/6] curl: Keep *socket until the end of curl_sock_cb()

2019-09-09 Thread John Snow



On 8/27/19 12:34 PM, Max Reitz wrote:
> This does not really change anything, but it makes the code a bit easier
> to follow once we use @socket as the opaque pointer for
> aio_set_fd_handler().
> 
> (Also, this change stops us from creating new CURLSocket objects when
> the cURL library just wants to stop listening on an existing socket that
> we do not recognize.  With a well-behaving cURL, that should never
> happen anyway.)
> 
> Cc: qemu-sta...@nongnu.org
> Signed-off-by: Max Reitz 
> ---
>  block/curl.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/block/curl.c b/block/curl.c
> index 92dc2f630e..8a45b371cc 100644
> --- a/block/curl.c
> +++ b/block/curl.c
> @@ -174,18 +174,16 @@ static int curl_sock_cb(CURL *curl, curl_socket_t fd, 
> int action,
>  if (socket->fd == fd) {
>  if (action == CURL_POLL_REMOVE) {
>  QLIST_REMOVE(socket, next);
> -g_free(socket);
>  }
>  break;
>  }
>  }

> -if (!socket) {
> +if (action != CURL_POLL_REMOVE && !socket) {
>  socket = g_new0(CURLSocket, 1);
>  socket->fd = fd;
>  socket->state = state;
>  QLIST_INSERT_HEAD(&state->sockets, socket, next);
>  }
> -socket = NULL;
>  
>  trace_curl_sock_cb(action, (int)fd);
>  switch (action) {
> @@ -207,6 +205,9 @@ static int curl_sock_cb(CURL *curl, curl_socket_t fd, int 
> action,
>  break;
>  }
>  
> +if (action == CURL_POLL_REMOVE) {
> +g_free(socket);
> +}
>  return 0;
>  }
>  
> 

Very naive question: why is CURL_POLL_REMOVE handled so early in the
function? Why not handle both QLIST_REMOVE and g_free under the
switch(action) construct entirely?



Re: [Qemu-devel] [PATCH v9 0/9] hw/m68k: add Apple Machintosh Quadra 800 machine

2019-09-09 Thread no-reply
Patchew URL: https://patchew.org/QEMU/20190909155813.27760-1-laur...@vivier.eu/



Hi,

This series seems to have some coding style problems. See output below for
more information:

Subject: [Qemu-devel] [PATCH v9 0/9] hw/m68k: add Apple Machintosh Quadra 800 
machine
Message-id: 20190909155813.27760-1-laur...@vivier.eu
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
3825476 hw/m68k: define Macintosh Quadra 800
114a77d hw/m68k: add a dummy SWIM floppy controller
d84838f hw/m68k: add Nubus support for macfb video card
2aab199 hw/m68k: add Nubus support
0a3fcc1 hw/m68k: add macfb video card
0f6aae6 hw/m68k: implement ADB bus support for via
6254996 hw/m68k: add via support
4b96a1e dp8393x: manage big endian bus
80774ea esp: add pseudo-DMA as used by Macintosh

=== OUTPUT BEGIN ===
1/9 Checking commit 80774ead22c0 (esp: add pseudo-DMA as used by Macintosh)
2/9 Checking commit 4b96a1e36bb1 (dp8393x: manage big endian bus)
3/9 Checking commit 625499666ea0 (hw/m68k: add via support)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#39: 
new file mode 100644

ERROR: space prohibited after that '&&' (ctx:WxW)
#387: FILE: hw/misc/mac_via.c:344:
+if (!(v1s->last_b & VIA1B_vRTCClk) && (s->b & VIA1B_vRTCClk)) {
^

total: 1 errors, 1 warnings, 814 lines checked

Patch 3/9 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

4/9 Checking commit 0f6aae654fdc (hw/m68k: implement ADB bus support for via)
5/9 Checking commit 0a3fcc15c079 (hw/m68k: add macfb video card)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#53: 
new file mode 100644

total: 0 errors, 1 warnings, 504 lines checked

Patch 5/9 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
6/9 Checking commit 2aab199032d6 (hw/m68k: add Nubus support)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#38: 
new file mode 100644

total: 0 errors, 1 warnings, 518 lines checked

Patch 6/9 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
7/9 Checking commit d84838f24a5e (hw/m68k: add Nubus support for macfb video 
card)
8/9 Checking commit 114a77d1bfc8 (hw/m68k: add a dummy SWIM floppy controller)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#37: 
new file mode 100644

total: 0 errors, 1 warnings, 510 lines checked

Patch 8/9 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
9/9 Checking commit 382547623d98 (hw/m68k: define Macintosh Quadra 800)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#96: 
new file mode 100644

total: 0 errors, 1 warnings, 539 lines checked

Patch 9/9 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20190909155813.27760-1-laur...@vivier.eu/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [Qemu-devel] [Qemu-block] [PATCH 1/6] curl: Keep pointer to the CURLState in CURLSocket

2019-09-09 Thread John Snow



On 8/27/19 12:34 PM, Max Reitz wrote:
> A follow-up patch will make curl_multi_do() and curl_multi_read() take a
> CURLSocket instead of the CURLState.  They still need the latter,
> though, so add a pointer to it to the former.
> 
> Cc: qemu-sta...@nongnu.org
> Signed-off-by: Max Reitz 
> ---
>  block/curl.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/block/curl.c b/block/curl.c
> index d4c8e94f3e..92dc2f630e 100644
> --- a/block/curl.c
> +++ b/block/curl.c
> @@ -80,6 +80,7 @@ static CURLMcode __curl_multi_socket_action(CURLM 
> *multi_handle,

The line that git/diff chooses as context is sometimes so very funny.

>  #define CURL_BLOCK_OPT_TIMEOUT_DEFAULT 5
>  
>  struct BDRVCURLState;
> +struct CURLState;
>  
>  static bool libcurl_initialized;
>  
> @@ -97,6 +98,7 @@ typedef struct CURLAIOCB {
>  
>  typedef struct CURLSocket {
>  int fd;
> +struct CURLState *state;
>  QLIST_ENTRY(CURLSocket) next;
>  } CURLSocket;
>  
> @@ -180,6 +182,7 @@ static int curl_sock_cb(CURL *curl, curl_socket_t fd, int 
> action,
>  if (!socket) {
>  socket = g_new0(CURLSocket, 1);
>  socket->fd = fd;
> +socket->state = state;
>  QLIST_INSERT_HEAD(&state->sockets, socket, next);
>  }
>  socket = NULL;
> 

So a State contains a list of sockets, and the socket has a link to the
state that created it. OK.

So far so harmless.

Reviewed-by: John Snow 



Re: [Qemu-devel] [PATCH] q35: lpc: allow to lock down 128K RAM at default SMBASE address

2019-09-09 Thread Laszlo Ersek
On 09/09/19 21:15, Laszlo Ersek wrote:

> ... I've done some testing too. Applying the QEMU patch on top of
> 89ea03a7dc83, my plan was:
> 
> - do not change OVMF, just see if it continues booting with the QEMU
> patch
> 
> - then negotiate bit#1 too, in step (1a) -- this is when I'd expect (3a)
> to break.
> 
> Unfortunately, the result is worse than that; even without negotiating
> bit#1 (i.e. in the baseline test), the firmware crashes (reboots) in
> step (3a). I've checked "info mtree", and all occurences of
> "smbase-blackhole" and "smbase-blackhole" are marked [disabled]. I'm not
> sure what's wrong with the baseline test (i.e. without negotiating
> bit#1). If I drop the patch (build QEMU at 89ea03a7dc83), then things
> work fine.

Sorry, there's a typo above: I pasted "smbase-blackhole" twice. The
second instance was meant to be "smbase-window". I checked all instances
of both regions in the info mtree output, I just fumbled the pasting.

Thanks
Laszlo



Re: [Qemu-devel] [PATCH] q35: lpc: allow to lock down 128K RAM at default SMBASE address

2019-09-09 Thread Laszlo Ersek
Hi Igor,

On 09/05/19 17:49, Igor Mammedov wrote:
> lpc already has SMI negotiation feature, extend it by adding
> optin ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT to supported features.
>
> Writing this bit into "etc/smi/requested-features" fw_cfg file,
> tells QEMU to alias 0x3,128K RAM range into SMRAM address
> space and mask this region from normal RAM address space
> (reads return 0xff and writes are ignored, i.e. guest code
> should be able to deal with not usable 0x3,128K RAM range
> once ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT is activated).
>
> To make negotiated change effective, guest should read
> "etc/smi/features-ok" fw_cfg file, which activates negotiated
> features and locks down negotiating capabilities until hard reset.
>
> Flow for initializing SMI handler on guest side:
>  1. set SMI handler entry point at default SMBASE location
>  2. check that host supports ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT
> in "etc/smi/supported-features" and set if supported set
> it in "etc/smi/requested-features"
>  3. read "etc/smi/features-ok", if returned value is 1
> negotiated at step 2 features are activated successfully.

Tying the [0x3+128K) lockdown to the broadcast SMI negotiation is a
simplification for QEMU, but it is a complication for OVMF.

(This QEMU patch ties those things together in effect because
"etc/smi/features-ok" can be selected for lockdown only once.)

In OVMF, at least 6 modules are involved in SMM setup. Here I'm only
going to list some steps for 4 modules (skipping
"OvmfPkg/SmmAccess/SmmAccess2Dxe.inf" and
"UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf").


(1) The "OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf" driver is launched,
and it produces the EFI_SMM_CONTROL2_PROTOCOL.

EFI_SMM_CONTROL2_PROTOCOL.Trigger() is the standard / abstract method
for synchronously raising an SMI. The OVMF implementation writes to IO
port 0xB2.

Because OVMF exposes this protocol to the rest of the firmware, it first
negotiates SMI broadcast, if QEMU offers it. The idea is that, without
negotiating SMI broadcast (if it's available), EFI_SMM_CONTROL2_PROTOCOL
is not fully configured, and should not be exposed. (Because, Trigger()
wouldn't work properly). Incomplete / halfway functional protocols are
not to be published.

That is, we have

(1a) negotiate SMI broadcast
(1b) install EFI_SMM_CONTROL2_PROTOCOL.


(2) Dependent on EFI_SMM_CONTROL2_PROTOCOL, the SMM IPL (Initial Program
Load -- "MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf") is launched.

This module
(2a) registers a callback for EFI_SMM_CONFIGURATION_PROTOCOL,
(2b) loads the SMM Core ("MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf")
 into SMRAM and starts it.


(3) The SMM Core launches the SMM processor driver
("UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf").

The SMM processor driver
(3a) performs the initial SMBASE relocation,
(3b) and then installs EFI_SMM_CONFIGURATION_PROTOCOL.

(Side remark: the SMM processor driver does not use IO port 0xB2 (it
does not call Trigger()); it uses LAPIC accesses. This is by design (PI
spec); Trigger() is supposed to be called  after the relocation is done,
and not for starting the relocation.)


(4) The SMM IPL's callback fires. It uses EFI_SMM_CONFIGURATION_PROTOCOL
to connect the platform-independent SMM entry point (= central
high-level SMI handler), which is in the SMM Core, into the low-level
(CPU-specific) SMI handler in the SMM processor driver.

At this point, SMIs are considered fully functional. General drivers
that are split into privileged (SMM) and unprivileged (runtime DXE)
halves, such as the variable service driver, can use
EFI_SMM_COMMUNICATION_PROTOCOL to submit messages to the privileged
(SMM) halves. And that boils down to EFI_SMM_CONTROL2_PROTOCOL.Trigger()
calls, which depends on SMI broadcast.

--*--

The present QEMU patch requires the firmware to (i) negotiate SMI
broadcast and to (ii) lock down [0x3+128K) at the same time.

If OVMF does both in step (1a) -- i.e. where it currently negotiates the
broadcast --, then step (3a) breaks: because the initial SMBASE
relocation depends on RAM at [0x3+128K).

In a theoretical ordering perspective, we could perhaps move the logic
from step (1a) between steps (3a) and (3b). There are two problems with
that:

- The platform logic from step (1a) doesn't belong in the SMM processor
driver (even if we managed to hook it in).

- In step (1b), we'd be installing a protocol
(EFI_SMM_CONTROL2_PROTOCOL) that is simply not set up correctly -- it's
incomplete.


Can QEMU offer this new "[0x3+128K) lockdown" hardware feature in a
separate platform device? (Such as a PCI device with fixed
(QEMU-specified) B/D/F, and config space register(s).)

It would be less difficult to lock such hardware down in isolation: I
wouldn't even attempt to inject that action between steps (3a) and (3b),
but write it as a new, independent End-of-DXE handler, in
"OvmfPkg/SmmAccess/SmmAccess2Dxe.inf". (That driver already offers SMRAM
open/close/lock services.) I would als

Re: [Qemu-devel] [PATCH] spapr-tpm-proxy: Drop misleading check

2019-09-09 Thread Michael Roth
Quoting Greg Kurz (2019-09-09 13:10:09)
> Coverity is reporting in CID 1405304 that tpm_execute() may pass a NULL
> tpm_proxy->host_path pointer to open(). This is based on the fact that
> h_tpm_comm() does a NULL check on tpm_proxy->host_path and then passes
> tpm_proxy to tpm_execute().
> 
> The check in h_tpm_comm() is abusive actually since a spapr-proxy-tpm
> requires a non NULL host_path property, as checked during realize.
> 
> Fixes: 0fb6bd073230
> Signed-off-by: Greg Kurz 

Reviewed-by: Michael Roth 

Thanks for the quick fix!

> ---
>  hw/ppc/spapr_tpm_proxy.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/ppc/spapr_tpm_proxy.c b/hw/ppc/spapr_tpm_proxy.c
> index b835d25be6f6..ca1caec113f0 100644
> --- a/hw/ppc/spapr_tpm_proxy.c
> +++ b/hw/ppc/spapr_tpm_proxy.c
> @@ -114,7 +114,7 @@ static target_ulong h_tpm_comm(PowerPCCPU *cpu,
>  return H_FUNCTION;
>  }
> 
> -trace_spapr_h_tpm_comm(tpm_proxy->host_path ?: "null", op);
> +trace_spapr_h_tpm_comm(tpm_proxy->host_path, op);
> 
>  switch (op) {
>  case TPM_COMM_OP_EXECUTE:
> 



Re: [Qemu-devel] [PATCH v2 2/3] iotests: add protocol support to initialization info

2019-09-09 Thread John Snow



On 9/9/19 6:09 AM, Max Reitz wrote:
> On 29.07.19 23:35, John Snow wrote:
>> This will add supported_protocols and unsupported_protocols to all of
>> iotests.main, iotests.script_main, and iotests.script_initialize.
>>
>> Signed-off-by: John Snow 
>> ---
>>  tests/qemu-iotests/207| 4 ++--
>>  tests/qemu-iotests/210| 4 ++--
>>  tests/qemu-iotests/211| 4 ++--
>>  tests/qemu-iotests/212| 4 ++--
>>  tests/qemu-iotests/213| 4 ++--
>>  tests/qemu-iotests/iotests.py | 5 -
>>  6 files changed, 14 insertions(+), 11 deletions(-)
> 
> Hm...  Most of the other script-style tests that do not pass
> supported_protocols yet should probably do so, actually.  I’m fairly
> certain most of them actually only support 'file'.

Sounds like a follow-up patch.

I guess the protocol information patch you talked about is not at
origin/master yet. Can you point me to it if I need to rebase on top of it?

My V3 still applies cleanly to master and appears to be correct.

--js



Re: [Qemu-devel] [PATCH v6 0/4] 9p: Fix file ID collisions

2019-09-09 Thread Junio C Hamano
Eric Blake  writes:

> How hard would it be to improve 'git format-patch'/'git send-email' to
> have an option to ALWAYS output a From: line in the body, even when the
> sender is the author, for the case of a mailing list that munges the
> mail headers due to DMARC/DKIM reasons?

I'd say that it shouldn't be so hard to implement than realizing
what ahd why it is needed, designing what the end-user interaction
would be (i.e.  command line options?  configuration variables?
should it be per send-email destination?) and stating all of the
above clearly in the documentation and the proposed commit log
message.

The reason you are asking is...?  Am I smelling a volunteer?



Re: [Qemu-devel] [PATCH] ahci: enable pci bus master MemoryRegion before loading ahci engines

2019-09-09 Thread no-reply
Patchew URL: 
https://patchew.org/QEMU/1568049517-10261-1-git-send-email-andyc...@synology.com/



Hi,

This series seems to have some coding style problems. See output below for
more information:

Subject: [Qemu-devel] [PATCH] ahci: enable pci bus master MemoryRegion before 
loading ahci engines
Message-id: 1568049517-10261-1-git-send-email-andyc...@synology.com
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 - [tag update]  patchew/20190909155813.27760-1-laur...@vivier.eu -> 
patchew/20190909155813.27760-1-laur...@vivier.eu
Switched to a new branch 'test'
3073672 ahci: enable pci bus master MemoryRegion before loading ahci engines

=== OUTPUT BEGIN ===
ERROR: Author email address is mangled by the mailing list
#2: 
Author: andychiu via Qemu-devel 

total: 1 errors, 0 warnings, 69 lines checked

Commit 307367238e8f (ahci: enable pci bus master MemoryRegion before loading 
ahci engines) has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/1568049517-10261-1-git-send-email-andyc...@synology.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [Qemu-devel] [PATCH v2 1/3] iotests: add script_initialize

2019-09-09 Thread John Snow



On 9/9/19 6:06 AM, Max Reitz wrote:
> On 29.07.19 23:35, John Snow wrote:
>> Like script_main, but doesn't require a single point of entry.
>> Replace all existing initialization sections with this drop-in replacement.
>>
>> This brings debug support to all existing script-style iotests.
>>
>> Note: supported_oses=['linux'] was omitted, as it is a default argument.
>> Signed-off-by: John Snow 
>> ---
> 
> Looks good to me, but I’m afraid I looked at this series too late (that
> is, now), so I sent my own version of your 2/3, sorry. :-/
> 

You're replying to v2; there was a v3.

I'll rebase V3 and re-send, especially if your version of 2/3 already
hit master.

--js



Re: [Qemu-devel] [PATCH v9 8/9] hw/m68k: add a dummy SWIM floppy controller

2019-09-09 Thread Laurent Vivier
Le 09/09/2019 à 18:11, Peter Maydell a écrit :
> On Mon, 9 Sep 2019 at 17:05, Laurent Vivier  wrote:
>>
>> Co-developed-by: Mark Cave-Ayland 
>> Signed-off-by: Mark Cave-Ayland 
>> Signed-off-by: Laurent Vivier 
>> Reviewed-by: Hervé Poussineau 
> 
>> +static void sysbus_swim_class_init(ObjectClass *oc, void *data)
>> +{
>> +DeviceClass *dc = DEVICE_CLASS(oc);
>> +
>> +dc->realize = sysbus_swim_realize;
>> +}
> 
> Missing reset and VMState for migration. These should be
> baseline requirements for adding new device models to the
> tree, because in an ideal world every device would support
> both -- we should be gradually fixing the existing devices
> which are missing these, and not letting new devices in,
> so the situation gets gradually better, not worse.

OK, I'm going to add reset and VMState.

Thanks,
Laurent




Re: [Qemu-devel] [PATCH] ahci: enable pci bus master MemoryRegion before loading ahci engines

2019-09-09 Thread John Snow



On 9/9/19 1:18 PM, andychiu via Qemu-devel wrote:
> If Windows 10 guests have enabled 'turn off hard disk after idle'
> option in power settings, and the guest has a SATA disk plugged in,
> the SATA disk will be turned off after a specified idle time.
> If the guest is live migrated or saved/loaded with its SATA disk
> turned off, the following error will occur:
> 
> qemu-system-x86_64: AHCI: Failed to start FIS receive engine: bad FIS receive 
> buffer address
> qemu-system-x86_64: Failed to load ich9_ahci:ahci
> qemu-system-x86_64: error while loading state for instance 0x0 of device 
> ':00:1a.0/ich9_ahci'
> qemu-system-x86_64: load of migration failed: Operation not permitted
> 

Oof. That can't have been fun to discover.

> Observation from trace logs shows that a while after Windows 10 turns off
> a SATA disk (IDE disks don't have the following behavior),
> it will disable the PCI_COMMAND_MASTER flag of the pci device containing
> the ahci device. When the the disk is turning back on,
> the PCI_COMMAND_MASTER flag will be restored first.
> But if the guest is migrated or saved/loaded while the disk is off,
> the post_load callback of ahci device, ahci_state_post_load(), will fail
> at ahci_cond_start_engines() if the MemoryRegion
> pci_dev->bus_master_enable_region is not enabled, with pci_dev pointing
> to the PCIDevice struct containing the ahci device.
> 
> This patch enables pci_dev->bus_master_enable_region before calling
> ahci_cond_start_engines() in ahci_state_post_load(), and restore the
> MemoryRegion to its original state afterwards.>

This looks good to me from an AHCI perspective, but I'm not as clear on
the implications of toggling the MemoryRegion, so I have some doubts.


MST, can you chime in and clear my confusion?

I suppose when the PCI_COMMAND_MASTER bit is turned off, we disable the
memory region, as a guest would be unable to establish a new mapping in
this time, so it makes sense that the attempt to map it fails.

What's less clear to me is what happens to existing mappings when a
region is disabled. Are they invalidated? If so, does it make sense that
we are trying to establish a mapping here at all? Maybe it's absolutely
correct that this fails.

(I suppose, though, that the simple toggling of the region won't be a
guest-visible event, so it's probably safe to do. Right?)

What I find weird for AHCI is this: We try to engage the CLB mapping
before the FIS mapping, but we fail at the FIS mapping. So why is
PORT_CMD_FIS_RX set while PORT_CMD_START is unset?

It kind of looks like we only half-heartedly stopped the AHCI device.
Maybe that's just what Windows does, but I wonder if there's a bug where
we're erroneously leaving PORT_CMD_FIS_RX set when we've been disabled.
It seems like the guest would need to re-set the mappings anyway, so
maybe trying to restore a stale mapping is not the right thing to do.



Andy, if you have traces left over: What AHCI registers does Windows
touch when it disables the AHCI device? What registers does it touch
when it re-engages it?

I just want to make sure I'm not leaving something dangling by accident.

--js

> Signed-off-by: andychiu 
> ---
>  hw/ide/ahci.c | 53 -
>  1 file changed, 36 insertions(+), 17 deletions(-)
> 
> diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
> index d45393c..83f8c30 100644
> --- a/hw/ide/ahci.c
> +++ b/hw/ide/ahci.c
> @@ -1649,33 +1649,52 @@ static const VMStateDescription vmstate_ahci_device = 
> {
>  },
>  };
>  
> +static int ahci_state_load_engines(AHCIState *s, AHCIDevice *ad)
> +{
> +AHCIPortRegs *pr = &ad->port_regs;
> +DeviceState *dev_state = s->container;
> +PCIDevice *pci_dev = (PCIDevice *) object_dynamic_cast(OBJECT(dev_state),
> +   TYPE_PCI_DEVICE);
> +bool pci_bus_master_enabled = pci_dev->bus_master_enable_region.enabled;
> +
> +if (!(pr->cmd & PORT_CMD_START) && (pr->cmd & PORT_CMD_LIST_ON)) {
> +error_report("AHCI: DMA engine should be off, but status bit "
> + "indicates it is still running.");
> +return -1;
> +}
> +if (!(pr->cmd & PORT_CMD_FIS_RX) && (pr->cmd & PORT_CMD_FIS_ON)) {
> +error_report("AHCI: FIS RX engine should be off, but status bit "
> + "indicates it is still running.");
> +return -1;
> +}
> +
> +memory_region_set_enabled(&pci_dev->bus_master_enable_region, true);
> +
> +/*
> + * After a migrate, the DMA/FIS engines are "off" and
> + * need to be conditionally restarted
> + */
> +pr->cmd &= ~(PORT_CMD_LIST_ON | PORT_CMD_FIS_ON);
> +if (ahci_cond_start_engines(ad) != 0) {
> +return -1;
> +}
> +memory_region_set_enabled(&pci_dev->bus_master_enable_region,
> +  pci_bus_master_enabled);
> +
> +return 0;
> +}
> +
>  static int ahci_state_post_load(void *opaque, int version_id)
>  {
>  int 

[Qemu-devel] [PATCH] spapr-tpm-proxy: Drop misleading check

2019-09-09 Thread Greg Kurz
Coverity is reporting in CID 1405304 that tpm_execute() may pass a NULL
tpm_proxy->host_path pointer to open(). This is based on the fact that
h_tpm_comm() does a NULL check on tpm_proxy->host_path and then passes
tpm_proxy to tpm_execute().

The check in h_tpm_comm() is abusive actually since a spapr-proxy-tpm
requires a non NULL host_path property, as checked during realize.

Fixes: 0fb6bd073230
Signed-off-by: Greg Kurz 
---
 hw/ppc/spapr_tpm_proxy.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/ppc/spapr_tpm_proxy.c b/hw/ppc/spapr_tpm_proxy.c
index b835d25be6f6..ca1caec113f0 100644
--- a/hw/ppc/spapr_tpm_proxy.c
+++ b/hw/ppc/spapr_tpm_proxy.c
@@ -114,7 +114,7 @@ static target_ulong h_tpm_comm(PowerPCCPU *cpu,
 return H_FUNCTION;
 }
 
-trace_spapr_h_tpm_comm(tpm_proxy->host_path ?: "null", op);
+trace_spapr_h_tpm_comm(tpm_proxy->host_path, op);
 
 switch (op) {
 case TPM_COMM_OP_EXECUTE:




Re: [Qemu-devel] [PATCH v9 0/9] hw/m68k: add Apple Machintosh Quadra 800 machine

2019-09-09 Thread no-reply
Patchew URL: https://patchew.org/QEMU/20190909155813.27760-1-laur...@vivier.eu/



Hi,

This series seems to have some coding style problems. See output below for
more information:

Subject: [Qemu-devel] [PATCH v9 0/9] hw/m68k: add Apple Machintosh Quadra 800 
machine
Message-id: 20190909155813.27760-1-laur...@vivier.eu
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

From https://github.com/patchew-project/qemu
 - [tag update]  patchew/20190909155813.27760-1-laur...@vivier.eu -> 
patchew/20190909155813.27760-1-laur...@vivier.eu
Switched to a new branch 'test'
a20a341 hw/m68k: define Macintosh Quadra 800
8685d1d hw/m68k: add a dummy SWIM floppy controller
49fd148 hw/m68k: add Nubus support for macfb video card
0b80050 hw/m68k: add Nubus support
7a65c7d hw/m68k: add macfb video card
0bc554d hw/m68k: implement ADB bus support for via
7b79e17 hw/m68k: add via support
085d45e dp8393x: manage big endian bus
3f9b63e esp: add pseudo-DMA as used by Macintosh

=== OUTPUT BEGIN ===
1/9 Checking commit 3f9b63e16821 (esp: add pseudo-DMA as used by Macintosh)
2/9 Checking commit 085d45ea3778 (dp8393x: manage big endian bus)
3/9 Checking commit 7b79e179e50a (hw/m68k: add via support)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#39: 
new file mode 100644

ERROR: space prohibited after that '&&' (ctx:WxW)
#387: FILE: hw/misc/mac_via.c:344:
+if (!(v1s->last_b & VIA1B_vRTCClk) && (s->b & VIA1B_vRTCClk)) {
^

total: 1 errors, 1 warnings, 814 lines checked

Patch 3/9 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

4/9 Checking commit 0bc554d357f0 (hw/m68k: implement ADB bus support for via)
5/9 Checking commit 7a65c7dd3399 (hw/m68k: add macfb video card)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#53: 
new file mode 100644

total: 0 errors, 1 warnings, 504 lines checked

Patch 5/9 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
6/9 Checking commit 0b8005090759 (hw/m68k: add Nubus support)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#38: 
new file mode 100644

total: 0 errors, 1 warnings, 518 lines checked

Patch 6/9 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
7/9 Checking commit 49fd148f8fb3 (hw/m68k: add Nubus support for macfb video 
card)
8/9 Checking commit 8685d1dd8843 (hw/m68k: add a dummy SWIM floppy controller)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#37: 
new file mode 100644

total: 0 errors, 1 warnings, 510 lines checked

Patch 8/9 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
9/9 Checking commit a20a341157b7 (hw/m68k: define Macintosh Quadra 800)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#96: 
new file mode 100644

total: 0 errors, 1 warnings, 539 lines checked

Patch 9/9 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20190909155813.27760-1-laur...@vivier.eu/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [Qemu-devel] [PATCH] Replace '-machine accel=xyz' with '-accel xyz'

2019-09-09 Thread Thomas Huth
On 09/09/2019 19.06, Paolo Bonzini wrote:
[...]
> 
> Thanks.  While "-accel kvm:tcg" is not going to be supported, the above
> replacement are all good.

I guess we should really do something about that before people start
using it in the wild...

 Thomas



[Qemu-devel] [PATCH] MAINTAINERS: update virtio-rng and virtio-serial maintainer

2019-09-09 Thread Laurent Vivier
As discussed with Amit, I volunteer to maintain virtio-rng and virtio-serial
previously maintained by Amit.

Signed-off-by: Laurent Vivier 
---
 MAINTAINERS | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 50eaf005f40e..db916ade55cd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1554,7 +1554,8 @@ F: include/hw/virtio/virtio-input.h
 F: contrib/vhost-user-input/*
 
 virtio-serial
-M: Amit Shah 
+M: Laurent Vivier 
+R: Amit Shah 
 S: Supported
 F: hw/char/virtio-serial-bus.c
 F: hw/char/virtio-console.c
@@ -1563,7 +1564,8 @@ F: tests/virtio-console-test.c
 F: tests/virtio-serial-test.c
 
 virtio-rng
-M: Amit Shah 
+M: Laurent Vivier 
+R: Amit Shah 
 S: Supported
 F: hw/virtio/virtio-rng.c
 F: include/hw/virtio/virtio-rng.h
-- 
2.21.0




Re: [Qemu-devel] [PULL 20/42] spapr: initial implementation for H_TPM_COMM/spapr-tpm-proxy

2019-09-09 Thread Greg Kurz
On Mon, 9 Sep 2019 18:23:20 +0100
Peter Maydell  wrote:

> On Wed, 21 Aug 2019 at 08:26, David Gibson  
> wrote:
> >
> > From: Michael Roth 
> >
> > This implements the H_TPM_COMM hypercall, which is used by an
> > Ultravisor to pass TPM commands directly to the host's TPM device, or
> > a TPM Resource Manager associated with the device.
> >
> > This also introduces a new virtual device, spapr-tpm-proxy, which
> > is used to configure the host TPM path to be used to service
> > requests sent by H_TPM_COMM hcalls, for example:
> >
> >   -device spapr-tpm-proxy,id=tpmp0,host-path=/dev/tpmrm0
> >
> > By default, no spapr-tpm-proxy will be created, and hcalls will return
> > H_FUNCTION.
> >
> > The full specification for this hypercall can be found in
> > docs/specs/ppc-spapr-uv-hcalls.txt
> >
> > Since SVM-related hcalls like H_TPM_COMM use a reserved range of
> > 0xEF00-0xEF80, we introduce a separate hcall table here to handle
> > them.
> >
> > Signed-off-by: Michael Roth  > Message-Id: <20190717205842.17827-3-mdr...@linux.vnet.ibm.com>
> > [dwg: Corrected #include for upstream change]
> > Signed-off-by: David Gibson 
> 
> Hi; Coverity reports an issue in this change (CID 1405304):
> 
> > +static ssize_t tpm_execute(SpaprTpmProxy *tpm_proxy, target_ulong *args)
> > +{
> > +uint64_t data_in = ppc64_phys_to_real(args[1]);
> > +target_ulong data_in_size = args[2];
> > +uint64_t data_out = ppc64_phys_to_real(args[3]);
> > +target_ulong data_out_size = args[4];
> > +uint8_t buf_in[TPM_SPAPR_BUFSIZE];
> > +uint8_t buf_out[TPM_SPAPR_BUFSIZE];
> > +ssize_t ret;
> > +
> > +trace_spapr_tpm_execute(data_in, data_in_size, data_out, 
> > data_out_size);
> > +
> > +if (data_in_size > TPM_SPAPR_BUFSIZE) {
> > +error_report("invalid TPM input buffer size: " TARGET_FMT_lu,
> > + data_in_size);
> > +return H_P3;
> > +}
> > +
> > +if (data_out_size < TPM_SPAPR_BUFSIZE) {
> > +error_report("invalid TPM output buffer size: " TARGET_FMT_lu,
> > + data_out_size);
> > +return H_P5;
> > +}
> > +
> > +if (tpm_proxy->host_fd == -1) {
> > +tpm_proxy->host_fd = open(tpm_proxy->host_path, O_RDWR);
> > +if (tpm_proxy->host_fd == -1) {
> > +error_report("failed to open TPM device %s: %d",
> > + tpm_proxy->host_path, errno);
> > +return H_RESOURCE;
> > +}
> > +}
> > +
> > +cpu_physical_memory_read(data_in, buf_in, data_in_size);
> > +
> > +do {
> > +ret = write(tpm_proxy->host_fd, buf_in, data_in_size);
> > +if (ret > 0) {
> > +data_in_size -= ret;
> > +}
> > +} while ((ret >= 0 && data_in_size > 0) || (ret == -1 && errno == 
> > EINTR));
> > +
> > +if (ret == -1) {
> > +error_report("failed to write to TPM device %s: %d",
> > + tpm_proxy->host_path, errno);
> > +return H_RESOURCE;
> > +}
> > +
> > +do {
> > +ret = read(tpm_proxy->host_fd, buf_out, data_out_size);
> > +} while (ret == 0 || (ret == -1 && errno == EINTR));
> > +
> > +if (ret == -1) {
> > +error_report("failed to read from TPM device %s: %d",
> > + tpm_proxy->host_path, errno);
> 
> The tpm_execute() function can unconditionally dereference
> tpm_proxy->host_path, implying it can never be NULL...
> 
> > +return H_RESOURCE;
> > +}
> > +
> > +cpu_physical_memory_write(data_out, buf_out, ret);
> > +args[0] = ret;
> > +
> > +return H_SUCCESS;
> > +}
> > +
> > +static target_ulong h_tpm_comm(PowerPCCPU *cpu,
> > +   SpaprMachineState *spapr,
> > +   target_ulong opcode,
> > +   target_ulong *args)
> > +{
> > +target_ulong op = args[0];
> > +SpaprTpmProxy *tpm_proxy = spapr->tpm_proxy;
> > +
> > +if (!tpm_proxy) {
> > +error_report("TPM proxy not available");
> > +return H_FUNCTION;
> > +}
> > +
> > +trace_spapr_h_tpm_comm(tpm_proxy->host_path ?: "null", op);
> 
> ...but in this tracing at the callsite we check for whether
> it is NULL or not, implying that it can be NULL.
> 

And we have this in the device realize function:

static void spapr_tpm_proxy_realize(DeviceState *d, Error **errp)
{
SpaprTpmProxy *tpm_proxy = SPAPR_TPM_PROXY(d);

if (tpm_proxy->host_path == NULL) {
error_setg(errp, "must specify 'host-path' option for device");
return;
}
[...]
}

so we can safely assume host_path is never NULL. I guess the fix is to
stop checking tpm_proxy->host_path in the trace callsite above.

> > +
> > +switch (op) {
> > +case TPM_COMM_OP_EXECUTE:
> > +return tpm_execute(tpm_proxy, args);
> > +case TPM_COMM_OP_CLOSE_SESSION:
> > +spapr_tpm_proxy_reset(tpm_proxy);
> > +return H_SUCCESS;
> > +default:
> > +return H_PARAMETER;
> > +}

Re: [Qemu-devel] qcow2 lock

2019-09-09 Thread Vladimir Sementsov-Ogievskiy
09.09.2019 15:57, Kevin Wolf wrote:
> Am 09.09.2019 um 14:16 hat Vladimir Sementsov-Ogievskiy geschrieben:
>> 09.09.2019 13:47, Kevin Wolf wrote:
>>> Am 09.09.2019 um 12:13 hat Vladimir Sementsov-Ogievskiy geschrieben:
 Hi!

 I have a (may be stupid) question: what is BDRVQcow2State.lock for and 
 when should it be locked?


 I faced SIGSEGV here:

 #0  qcow2_process_discards (bs=bs@entry=0x564b93bc8000, ret=ret@entry=0) 
 at block/qcow2-refcount.c:737
 #1  0x564b90e9f15f in qcow2_cluster_discard 
 (bs=bs@entry=0x564b93bc8000, offset=0, offset@entry=3062890496, 
 bytes=bytes@entry=134217728, type=type@entry=QCOW2_DISCARD_REQUEST,
full_discard=full_discard@entry=false) at block/qcow2-cluster.c:1853
 #2  0x564b90e8f720 in qcow2_co_pdiscard (bs=0x564b93bc8000, 
 offset=3062890496, bytes=134217728) at block/qcow2.c:3749
 #3  0x564b90ec565d in bdrv_co_pdiscard (bs=0x564b93bc8000, 
 offset=3062890496, bytes=134217728) at block/io.c:2939
 #4  0x564b90eb5c04 in blk_aio_pdiscard_entry (opaque=0x564b94f968c0) 
 at block/block-backend.c:1527
 #5  0x564b90f681ea in coroutine_trampoline (i0=, 
 i1=) at util/coroutine-ucontext.c:116

 SIGSEGV is on QTAILQ_REMOVE in qcow2_process_discards:
 (gdb) list
 732 {
 733 BDRVQcow2State *s = bs->opaque;
 734 Qcow2DiscardRegion *d, *next;
 735
 736 QTAILQ_FOREACH_SAFE(d, &s->discards, next, next) {
 737 QTAILQ_REMOVE(&s->discards, d, next);
 738
 739 /* Discard is optional, ignore the return value */
 740 if (ret >= 0) {
 741 bdrv_pdiscard(bs->file->bs, d->offset, d->bytes);


 (you see bs->file->bs, yes it's old code based on 2.12, but still,
 I need some help on the following)

 and problem is that d is already deleted:
 (gdb) p d->next
 $50 = {tqe_next = 0x564b94b0b140, tqe_prev = 0x0}

 Such problems may occur when there is an interleaving of such
 removing loops with other usage of the queue. And this is possible,
 as we call bdrv_pdiscard inside the loop which may yield.

 go to frame #5, and print co->caller stack:

 #0  0x564b90f68180 in qemu_coroutine_switch ()
 #1  0x564b90f66c84 in qemu_aio_coroutine_enter ()
 #2  0x564b90f50764 in aio_co_enter ()
 #3  0x564b90f50ea9 in thread_pool_completion_bh ()
 #4  0x564b90f500d1 in aio_bh_poll ()
 #5  0x564b90f5360b in aio_poll ()
 #6  0x564b90ec59cd in bdrv_pdiscard ()
 #7  0x564b90e96a36 in qcow2_process_discards ()
 #8  0x564b90e97785 in update_refcount ()
 #9  0x564b90e96bdd in qcow2_free_clusters ()
 #10 0x564b90ea29c7 in update_ext_header_and_dir ()
 #11 0x564b90ea3a14 in qcow2_remove_persistent_dirty_bitmap ()
 #12 0x564b90ce7bce in qmp_block_dirty_bitmap_remove ()
 #13 0x564b90cf5390 in qmp_marshal_block_dirty_bitmap_remove ()
 #14 0x564b90f46080 in qmp_dispatch ()
 #15 0x564b90bedc74 in monitor_qmp_dispatch_one ()
 #16 0x564b90bee04a in monitor_qmp_bh_dispatcher ()
 #17 0x564b90f500d1 in aio_bh_poll ()
 #18 0x564b90f53430 in aio_dispatch ()
 #19 0x564b90f4ffae in aio_ctx_dispatch ()
 #20 0x7f0a8e3e9049 in g_main_context_dispatch () from 
 /lib64/libglib-2.0.so.0
 #21 0x564b90f52727 in main_loop_wait ()
 #22 0x564b90ba0c07 in main ()


 And this (at least partly) confirms my guess.

 So, my actual question is, what should be fixed here:

 1. yielding in qcow2_process_discards, like this:

 --- a/block/qcow2-refcount.c
 +++ b/block/qcow2-refcount.c
 @@ -732,9 +732,13 @@ void qcow2_process_discards(BlockDriverState *bs, int 
 ret)
 {
 BDRVQcow2State *s = bs->opaque;
 Qcow2DiscardRegion *d, *next;
 +QTAILQ_HEAD (, Qcow2DiscardRegion) discards;

 -QTAILQ_FOREACH_SAFE(d, &s->discards, next, next) {
 -QTAILQ_REMOVE(&s->discards, d, next);
 +discards = s->discards;
 +QTAILQ_INIT(&s->discards);
 +
 +QTAILQ_FOREACH_SAFE(d, &discards, next, next) {
 +QTAILQ_REMOVE(&discards, d, next);

 /* Discard is optional, ignore the return value */
 if (ret >= 0) {
>>>
>>> I think this is not enough.
>>>
>>> If you don't hold s->lock here, concurrent requests could (re-)allocate
>>> the clusters to be discarded and then you'd discard new data instead of
>>> the old one.
>>>
>>> So I believe that qcow2_process_discards() must always be called before
>>> the image can be unlocked after adding something to the discard queue.
>>>
 or
 2. calling qcow2_remove_persistent_dirty_bitmap without taking lock, like 
 this:

 --- a/block/qcow2-bitmap.c
 +++ b/blo

Re: [Qemu-devel] [PATCH] hw/i386: Move CONFIG_ACPI_PCI to CONFIG_PC

2019-09-09 Thread Paolo Bonzini
On 09/09/19 19:34, Cole Robinson wrote:
> CONFIG_ACPI_PCI is a hard requirement of acpi-build.c, which is built
> unconditionally for x86 target. Putting it in default-configs/ suggests
> that it can be easily disabled, which isn't true.
> 
> Relocate the symbol with the other acpi-build.c requirements, under
> 'config PC'. This is similar to what is done for the arm 'virt' machine
> type and CONFIG_ACPI_PCI
> 
> Signed-off-by: Cole Robinson 
> ---
>  default-configs/i386-softmmu.mak | 1 -
>  hw/i386/Kconfig  | 1 +
>  2 files changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/default-configs/i386-softmmu.mak 
> b/default-configs/i386-softmmu.mak
> index cd5ea391e8..ba3fb3ff50 100644
> --- a/default-configs/i386-softmmu.mak
> +++ b/default-configs/i386-softmmu.mak
> @@ -25,4 +25,3 @@
>  CONFIG_ISAPC=y
>  CONFIG_I440FX=y
>  CONFIG_Q35=y
> -CONFIG_ACPI_PCI=y
> diff --git a/hw/i386/Kconfig b/hw/i386/Kconfig
> index 6350438036..c7a9d6315c 100644
> --- a/hw/i386/Kconfig
> +++ b/hw/i386/Kconfig
> @@ -29,6 +29,7 @@ config PC
>  select MC146818RTC
>  # For ACPI builder:
>  select SERIAL_ISA
> +select ACPI_PCI
>  select ACPI_VMGENID
>  select VIRTIO_PMEM_SUPPORTED
>  
> 

Queued, thanks.

Paolo



Re: [Qemu-devel] [PATCH v9 8/9] hw/m68k: add a dummy SWIM floppy controller

2019-09-09 Thread Aleksandar Markovic
09.09.2019. 18.32, "Aleksandar Markovic"  је
написао/ла:
>
>
> 09.09.2019. 18.03, "Laurent Vivier"  је написао/ла:
> >
> > Co-developed-by: Mark Cave-Ayland 
> > Signed-off-by: Mark Cave-Ayland 
> > Signed-off-by: Laurent Vivier 
> > Reviewed-by: Hervé Poussineau 
> > ---
>
> Laurent, hi!
>
> I am not sure how "Co-developed-by:" fits in our workflow. There was some
recent talk on restricting those marks to only a handful of them, and
preventing new ones from introducing (the starter example was something
like "Regression-tested-by:"). Perhaps a final sentence "This patch was
co-developed with Mark..." would be better?
>
> Aleksandar

Laurent,

I noticed I overlooked that there is a paragraph on "Co-developed-by:" in
the Linux kernel "how to submit a patch", so it is fine.

Sorry about noise.

Aleksandar

> >  hw/block/Kconfig|   3 +
> >  hw/block/Makefile.objs  |   1 +
> >  hw/block/swim.c | 421 
> >  include/hw/block/swim.h |  76 
> >  4 files changed, 501 insertions(+)
> >  create mode 100644 hw/block/swim.c
> >  create mode 100644 include/hw/block/swim.h
> >
> > diff --git a/hw/block/Kconfig b/hw/block/Kconfig
> > index df96dc5dcc..2d17f481ad 100644
> > --- a/hw/block/Kconfig
> > +++ b/hw/block/Kconfig
> > @@ -37,3 +37,6 @@ config VHOST_USER_BLK
> >  # Only PCI devices are provided for now
> >  default y if VIRTIO_PCI
> >  depends on VIRTIO && VHOST_USER && LINUX
> > +
> > +config SWIM
> > +bool
> > diff --git a/hw/block/Makefile.objs b/hw/block/Makefile.objs
> > index f5f643f0cc..28c2495a00 100644
> > --- a/hw/block/Makefile.objs
> > +++ b/hw/block/Makefile.objs
> > @@ -8,6 +8,7 @@ common-obj-$(CONFIG_XEN) += xen-block.o
> >  common-obj-$(CONFIG_ECC) += ecc.o
> >  common-obj-$(CONFIG_ONENAND) += onenand.o
> >  common-obj-$(CONFIG_NVME_PCI) += nvme.o
> > +common-obj-$(CONFIG_SWIM) += swim.o
> >
> >  obj-$(CONFIG_SH4) += tc58128.o
> >
> > diff --git a/hw/block/swim.c b/hw/block/swim.c
> > new file mode 100644
> > index 00..6e26915238
> > --- /dev/null
> > +++ b/hw/block/swim.c
> > @@ -0,0 +1,421 @@
> > +/*
> > + * QEMU Macintosh floppy disk controller emulator (SWIM)
> > + *
> > + * Copyright (c) 2014-2018 Laurent Vivier 
> > + *
> > + * This work is licensed under the terms of the GNU GPL, version 2.
See
> > + * the COPYING file in the top-level directory.
> > + *
> > + */
> > +
> > +#include "qemu/osdep.h"
> > +#include "qemu/main-loop.h"
> > +#include "qapi/error.h"
> > +#include "sysemu/block-backend.h"
> > +#include "hw/sysbus.h"
> > +#include "hw/block/block.h"
> > +#include "hw/block/swim.h"
> > +#include "hw/qdev-properties.h"
> > +
> > +/* IWM registers */
> > +
> > +#define IWM_PH0L0
> > +#define IWM_PH0H1
> > +#define IWM_PH1L2
> > +#define IWM_PH1H3
> > +#define IWM_PH2L4
> > +#define IWM_PH2H5
> > +#define IWM_PH3L6
> > +#define IWM_PH3H7
> > +#define IWM_MTROFF  8
> > +#define IWM_MTRON   9
> > +#define IWM_INTDRIVE10
> > +#define IWM_EXTDRIVE11
> > +#define IWM_Q6L 12
> > +#define IWM_Q6H 13
> > +#define IWM_Q7L 14
> > +#define IWM_Q7H 15
> > +
> > +/* SWIM registers */
> > +
> > +#define SWIM_WRITE_DATA 0
> > +#define SWIM_WRITE_MARK 1
> > +#define SWIM_WRITE_CRC  2
> > +#define SWIM_WRITE_PARAMETER3
> > +#define SWIM_WRITE_PHASE4
> > +#define SWIM_WRITE_SETUP5
> > +#define SWIM_WRITE_MODE06
> > +#define SWIM_WRITE_MODE17
> > +
> > +#define SWIM_READ_DATA  8
> > +#define SWIM_READ_MARK  9
> > +#define SWIM_READ_ERROR 10
> > +#define SWIM_READ_PARAMETER 11
> > +#define SWIM_READ_PHASE 12
> > +#define SWIM_READ_SETUP 13
> > +#define SWIM_READ_STATUS14
> > +#define SWIM_READ_HANDSHAKE 15
> > +
> > +#define REG_SHIFT   9
> > +
> > +#define SWIM_MODE_IWM  0
> > +#define SWIM_MODE_SWIM 1
> > +
> > +/* bits in phase register */
> > +
> > +#define SWIM_SEEK_NEGATIVE   0x074
> > +#define SWIM_STEP0x071
> > +#define SWIM_MOTOR_ON0x072
> > +#define SWIM_MOTOR_OFF   0x076
> > +#define SWIM_INDEX   0x073
> > +#define SWIM_EJECT   0x077
> > +#define SWIM_SETMFM  0x171
> > +#define SWIM_SETGCR  0x175
> > +#define SWIM_RELAX   0x033
> > +#define SWIM_LSTRB   0x008
> > +#define SWIM_CA_MASK 0x077
> > +
> > +/* Select values for swim_select and swim_readbit */
> > +
> > +#define SWIM_READ_DATA_0 0x074
> > +#define SWIM_TWOMEG_DRIVE0x075
> > +#define SWIM_SINGLE_SIDED0x076
> > +#define SWIM_DRIVE_PRESENT   0x077
> > +#define SWIM_DISK_IN 0x170
> > +#define SWIM_WRITE_PROT  0x171
> > +#define SWIM_TRACK_ZERO  0x172
> > +#define SWIM_TACHO   0x173

Re: [Qemu-devel] [PULL 01/12] util/iov: introduce qemu_iovec_init_extended

2019-09-09 Thread Peter Maydell
On Tue, 27 Aug 2019 at 21:16, Stefan Hajnoczi  wrote:
>
> From: Vladimir Sementsov-Ogievskiy 
>
> Introduce new initialization API, to create requests with padding. Will
> be used in the following patch. New API uses qemu_iovec_init_buf if
> resulting io vector has only one element, to avoid extra allocations.
> So, we need to update qemu_iovec_destroy to support destroying such
> QIOVs.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> Acked-by: Stefan Hajnoczi 
> Message-id: 20190604161514.262241-2-vsement...@virtuozzo.com
> Message-Id: <20190604161514.262241-2-vsement...@virtuozzo.com>
> Signed-off-by: Stefan Hajnoczi 

Hi -- Coverity thinks this new function could have an
out-of-bounds read (CID 1405302):

> +/*
> + * Compile new iovec, combining @head_buf buffer, sub-qiov of @mid_qiov,
> + * and @tail_buf buffer into new qiov.
> + */
> +void qemu_iovec_init_extended(
> +QEMUIOVector *qiov,
> +void *head_buf, size_t head_len,
> +QEMUIOVector *mid_qiov, size_t mid_offset, size_t mid_len,
> +void *tail_buf, size_t tail_len)
> +{
> +size_t mid_head, mid_tail;
> +int total_niov, mid_niov = 0;
> +struct iovec *p, *mid_iov;
> +
> +if (mid_len) {
> +mid_iov = qiov_slice(mid_qiov, mid_offset, mid_len,
> + &mid_head, &mid_tail, &mid_niov);
> +}
> +
> +total_niov = !!head_len + mid_niov + !!tail_len;
> +if (total_niov == 1) {
> +qemu_iovec_init_buf(qiov, NULL, 0);
> +p = &qiov->local_iov;
> +} else {
> +qiov->niov = qiov->nalloc = total_niov;
> +qiov->size = head_len + mid_len + tail_len;
> +p = qiov->iov = g_new(struct iovec, qiov->niov);
> +}
> +
> +if (head_len) {
> +p->iov_base = head_buf;
> +p->iov_len = head_len;
> +p++;
> +}
> +
> +if (mid_len) {
> +memcpy(p, mid_iov, mid_niov * sizeof(*p));
> +p[0].iov_base = (uint8_t *)p[0].iov_base + mid_head;
> +p[0].iov_len -= mid_head;
> +p[mid_niov - 1].iov_len -= mid_tail;
> +p += mid_niov;
> +}
> +
> +if (tail_len) {
> +p->iov_base = tail_buf;
> +p->iov_len = tail_len;
> +}
> +}

but I'm not familiar enough with the code to be able to tell
if it's correct or if it's just getting confused. Could
somebody have a look? (It's possible it's getting confused
because the calculation of 'total_niov' uses 'mid_niov',
but the condition guarding the code that fills in that part
of the vector is 'mid_len', so it thinks it can take the
"total_niov == 1" codepath and also the "head_len == true"
and "mid_len != 0" paths; in which case using "if (mid_niov)"
instead might make it happier.)

thanks
-- PMM



Re: [Qemu-devel] [RFC] docs: vhost-user: add in-band kick/call messages

2019-09-09 Thread Johannes Berg
On Mon, 2019-09-09 at 18:00 +0200, Stefan Hajnoczi wrote:

> Is this really necessary?  

Yes* :)

> Can the simulation interpose between the
> call/kick eventfds in order to control when events happen?
> 
>   CPU --cpu_kickfd--> Simulation --vhost_kickfd--> vhost-user device
> 
> and:
> 
>   vhost-user device --vhost_callfd--> Simulation -->cpu_callfd-> CPU
> 
> The simluation controls when the CPU's kick is seen by the device and
> also when the call is seen by the CPU.

The point isn't to let the simulation know about anything that happens.
The CPU and the device are *part* of the simulation.

> I don't understand why new vhost-user protocol messages are required.

I guess I haven't really explained it well then :-)

So let's say, WLOG, I have a simulated network and a bunch of Linux
machines that are running on simulation time. Today I can do that only
with user-mode Linux, but we'll see.

Now in order to run everything on simulation time, *everything* that
happens in the simulation needs to request a simulation calendar entry,
and gets told when that entry is scheduled.

So think, for example, you have

CPU ---[kick]---> device

Now, this is essentially triggering an interrupt in the device. However,
the simulation code has to ensure that the simulated device's interrupt
handling only happens at a scheduler entry. Fundamentally, the
simulation serializes all processing, contrary to what you want in a
real system.

Now, this means that the CPU (that's part of the simulation) has to
*wait* for the device to add an entry to the simulation calendar in
response to the kick... That means that it really has to look like

CPU   device   calendar
 ---[kick]-->
 ---[add entry]-->
 <---[return]-
 <-[return]--

so that the CPU won't get to idle or some other processing where it asks
the simulation calendar for its own next entry...

Yes, like I said before, I realize that all of this is completely
opposed to what you want in a real system, but then in a real system you
also have real timeouts, and don't just skip time forward when the
simulation calendar says so ...


* Now, of course I lied, this is software after all. The *concept* is
necessary, but it's not strictly necessary to do this in-band in the
vhost-user protocol.
We could do an out-of-band simulation socket for the kick signal and
just pretend we're using polling mode as far as the vhost-user protocol
is concerned, but it'd probably be harder to implement, and we couldn't
do it in a way that we could actually contribute anything upstream.
There are quite a few papers proposing such simulation systems, I only
found the VMSimInt one publishing their code, but even that is some
hacks on top of qemu 1.6.0...

johannes




[Qemu-devel] [PATCH] hw/i386: Move CONFIG_ACPI_PCI to CONFIG_PC

2019-09-09 Thread Cole Robinson
CONFIG_ACPI_PCI is a hard requirement of acpi-build.c, which is built
unconditionally for x86 target. Putting it in default-configs/ suggests
that it can be easily disabled, which isn't true.

Relocate the symbol with the other acpi-build.c requirements, under
'config PC'. This is similar to what is done for the arm 'virt' machine
type and CONFIG_ACPI_PCI

Signed-off-by: Cole Robinson 
---
 default-configs/i386-softmmu.mak | 1 -
 hw/i386/Kconfig  | 1 +
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index cd5ea391e8..ba3fb3ff50 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -25,4 +25,3 @@
 CONFIG_ISAPC=y
 CONFIG_I440FX=y
 CONFIG_Q35=y
-CONFIG_ACPI_PCI=y
diff --git a/hw/i386/Kconfig b/hw/i386/Kconfig
index 6350438036..c7a9d6315c 100644
--- a/hw/i386/Kconfig
+++ b/hw/i386/Kconfig
@@ -29,6 +29,7 @@ config PC
 select MC146818RTC
 # For ACPI builder:
 select SERIAL_ISA
+select ACPI_PCI
 select ACPI_VMGENID
 select VIRTIO_PMEM_SUPPORTED
 
-- 
2.21.0




Re: [Qemu-devel] [PULL 1/9] qapi: Add InetSocketAddress member keep-alive

2019-09-09 Thread Peter Maydell
On Thu, 15 Aug 2019 at 19:34, Eric Blake  wrote:
>
> From: Vladimir Sementsov-Ogievskiy 
>
> It's needed to provide keepalive for nbd client to track server
> availability.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> Message-Id: <20190725094937.32454-1-vsement...@virtuozzo.com>
> Reviewed-by: Markus Armbruster 
> Acked-by: Daniel P. Berrangé 
> [eblake: Fix error message typo]
> Signed-off-by: Eric Blake 

Hi; Coverity spots a bug in this change (CID 1405300):

> @@ -458,6 +464,19 @@ int inet_connect_saddr(InetSocketAddress *saddr, Error 
> **errp)
>  }

At this point in the function, we might be in one of
two cases:
 (1) sock >= 0 : the connect succeeded
 (2) sock < 0 : connect failed, we have just called
 error_propagate() and are using the same end-of-function
 codepath to free 'res' before returning the error code.

>
>  freeaddrinfo(res);
> +
> +if (saddr->keep_alive) {
> +int val = 1;
> +int ret = qemu_setsockopt(sock, SOL_SOCKET, SO_KEEPALIVE,
> +  &val, sizeof(val));

...but here we use 'sock' assuming it is valid.

> +
> +if (ret < 0) {
> +error_setg_errno(errp, errno, "Unable to set KEEPALIVE");
> +close(sock);
> +return -1;
> +}
> +}
> +
>  return sock;
>  }

If we want to add more "actual work" at this point in
the function we should probably separate out the failed-case
codepath, eg by changing


if (sock < 0) {
error_propagate(errp, local_err);
}

freeaddrinfo(res);

into

freeaddrinfo(res);

if (sock < 0) {
error_propagate(errp, local_err);
return sock;
}



thanks
-- PMM



Re: [Qemu-devel] [PATCH-for-4.2 v2] Only enable the halt poll control MSR if it is supported by the host

2019-09-09 Thread Paolo Bonzini
On 28/08/19 19:22, Mark Kanda wrote:
> Gentle ping - I would like to confirm this patch is acceptable.

Yes, it was squashed in Marcelo's patch (commit
d645e1328726b38b3c79525eb57842ce29c1df7c).

Paolo

> Thanks/regards,
> -Mark
> 
> On 7/17/2019 9:38 AM, Mark Kanda wrote:
>> The halt poll control MSR should only be enabled on hosts which
>> support it.
>>
>> Fixes: ("kvm: i386: halt poll control MSR support")
>>
>> Signed-off-by: Mark Kanda 
>>
>> ---
>> v2: Remove unnecessary hunks which break migration with older hosts
>> (Paolo)
>> ---
>>   target/i386/cpu.c | 1 -
>>   1 file changed, 1 deletion(-)
>>
>> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
>> index a8bafdb8b9..543bc25f64 100644
>> --- a/target/i386/cpu.c
>> +++ b/target/i386/cpu.c
>> @@ -2838,7 +2838,6 @@ static PropValue kvm_default_props[] = {
>>   { "kvm-asyncpf", "on" },
>>   { "kvm-steal-time", "on" },
>>   { "kvm-pv-eoi", "on" },
>> -    { "kvm-poll-control", "on" },
>>   { "kvmclock-stable-bit", "on" },
>>   { "x2apic", "on" },
>>   { "acpi", "off" },
>>




Re: [Qemu-devel] [PULL v2 01/16] qemu-io: add pattern file for write command

2019-09-09 Thread Peter Maydell
On Tue, 3 Sep 2019 at 14:35, Max Reitz  wrote:
>
> From: Denis Plotnikov 
>
> The patch allows to provide a pattern file for write
> command. There was no similar ability before.
>
> Signed-off-by: Denis Plotnikov 
> Message-id: 20190820164616.4072-1-dplotni...@virtuozzo.com
> Reviewed-by: Eric Blake 
> [mreitz: Keep optstring in alphabetical order]
> Signed-off-by: Max Reitz 

Hi; Coverity finds a FILE* leak in this code (CID 1405303):



> +/*
> + * qemu_io_alloc_from_file()
> + *
> + * Allocates the buffer and populates it with the content of the given file
> + * up to @len bytes. If the file length is less than @len, then the buffer
> + * is populated with the file content cyclically.
> + *
> + * @blk - the block backend where the buffer content is going to be written 
> to
> + * @len - the buffer length
> + * @file_name - the file to read the content from
> + *
> + * Returns: the buffer pointer on success
> + *  NULL on error
> + */
> +static void *qemu_io_alloc_from_file(BlockBackend *blk, size_t len,
> + const char *file_name)
> +{
> +char *buf, *buf_origin;
> +FILE *f = fopen(file_name, "r");

Here we allocate the FILE*...

> +int pattern_len;
> +
> +if (!f) {
> +perror(file_name);
> +return NULL;
> +}
> +
> +if (qemuio_misalign) {
> +len += MISALIGN_OFFSET;
> +}
> +
> +buf_origin = buf = blk_blockalign(blk, len);
> +
> +if (qemuio_misalign) {
> +buf_origin += MISALIGN_OFFSET;
> +buf += MISALIGN_OFFSET;
> +len -= MISALIGN_OFFSET;
> +}
> +
> +pattern_len = fread(buf_origin, 1, len, f);
> +
> +if (ferror(f)) {
> +perror(file_name);
> +goto error;

...but in this error-exit path...

> +}
> +
> +if (pattern_len == 0) {
> +fprintf(stderr, "%s: file is empty\n", file_name);
> +goto error;

...and this one...

> +}
> +
> +fclose(f);
> +
> +if (len > pattern_len) {
> +len -= pattern_len;
> +buf += pattern_len;
> +
> +while (len > 0) {
> +size_t len_to_copy = MIN(pattern_len, len);
> +
> +memcpy(buf, buf_origin, len_to_copy);
> +
> +len -= len_to_copy;
> +buf += len_to_copy;
> +}
> +}
> +
> +return buf_origin;
> +
> +error:
> +qemu_io_free(buf_origin);
> +return NULL;

...we go to the 'error' label and leave the function without
ever calling fclose(f).

> +}

thanks
-- PMM



Re: [Qemu-devel] IOTEST 162

2019-09-09 Thread John Snow



On 9/6/19 1:25 PM, Maxim Levitsky wrote:
> Hi!
> 
> I just had a very fun rabbit hole dive, and I want to share it with you.
> 
> I notice for some time that iotest 162 fails with that:
> 
> -qemu-img: Could not open 'json:{"driver": "nbd", "host": 42}': Failed to 
> connect socket: Invalid argument
> +qemu-img: Could not open 'json:{"driver": "nbd", "host": 42}': Failed to 
> connect socket:
> Connection timed out
> 
> 
> I didn't bother to report it yet as it started failing more or less when qemu 
> 4.2 merge window opened,
> so I thought that maybe something got broken, or maybe something broken in my 
> environment 
> (ahem, AF_UNIX path is too long, ahem)
> 
> I just didn't had enough time to pay attention to this. Until today.
> 
> So I asked Kevin Wolf today, just by the way why I see for some time that
> iotest 162 fails. for me.
> 
> 
> He told me that it works for him.
> So I look at the test and I see that it just does
> 
> qemu-img info 'json:{"driver": "nbd", "host": 42}'
> 
> Supposedly it should fail because 42 is not quoted, and it 
> doesn't look like a valid host name.
> 
> I try with disto's qemu-img (2.11) and I still see that I get the 'Connection 
> timed out'
> 
> Then I ask him to try on his system with '42' quoted and it still passes.
> 
> All right - this means that this 42 is parsed. He also mentions that he uses 
> fedora 29 and I still
> use fedora 28. So I start a VM with fedora 30, and yep, there it does work 
> correctly.
> 
> All right, that 42 must be parsed as a host name. Yep. 'ping 42' on my 
> machine tries to ping 0.0.0.42,
> and in VM exits immediately with 'Invalid argument'
> All right, lets ping 0.0.0.42. Maybe something in hostname parsing changed, 
> maybe something parses this on DNS level?
> Nope, ping 0.0.0.42 works on my machine, fails with invalid argument in VM...
> 
> All right lets strace it
> 
> connect(5, {sa_family=AF_INET, sin_port=htons(1025), 
> sin_addr=inet_addr("0.0.0.42")}, 16) = -1 EINVAL (Invalid argument)
> 
> Same thing passes on my machine
> 
> Hmm... this is something in the kernel. Maybe something in iptables/etc. I 
> don't yet know that
> area that well to be honest.
> 
> So I googled a bit and look what I found:
> 
> https://lwn.net/Articles/791086/
> 
> And yes, while my machine runs fedora 28, it as usual runs vanilla git master
> kernel, which I compile from time to time. Currently I am on 5.3.0-rc4+.
> 
> So I must say that nothing less but kernel 5.3.0, breaks iotest 162.
> 
> I''l prepare a patch soon to fix this.

I wonder if I am seeing some related problems, though I am running
5.2.11 right now and not 5.3.x:

162 is failing in this way:

-qemu-img: Could not open 'json:{"driver": "ssh", "host": "localhost",
"port": "0", "path": "/foo"}': Failed to connect socket: Connection refused
-qemu-img: Could not open 'driver=ssh,host=localhost,port=0,path=/foo':
Failed to connect socket: Connection refused
+qemu-img: Could not open 'json:{"driver": "ssh", "host": "localhost",
"port": "0", "path": "/foo"}': Failed to connect socket: Connection
timed out
+qemu-img: Could not open 'driver=ssh,host=localhost,port=0,path=/foo':
Failed to connect socket: Connection timed out
 qemu-img: Could not open 'json:{"driver": "ssh", "host": "localhost",
"port": 0.42, "path": "/foo"}': Parameter 'port' expects a number
 qemu-img: Could not open
'driver=ssh,host=localhost,port=0.42,path=/foo': Parameter 'port'
expects a number


and 147 is failing this way:

+  File "147", line 243, in test_inet6
+if self._try_server_up(address):
+  File "147", line 156, in _try_server_up
+self.assert_qmp(result, 'return', {})
+  File "/home/bos/jhuston/src/qemu/tests/qemu-iotests/iotests.py", line
685, in assert_qmp
+result = self.dictpath(d, path)
+  File "/home/bos/jhuston/src/qemu/tests/qemu-iotests/iotests.py", line
661, in dictpath
+self.fail('failed path traversal for "%s" in "%s"' % (path, str(d)))
+AssertionError: failed path traversal for "return" in "{'error':
{'class': 'GenericError', 'desc': 'Failed to bind socket: Cannot assign
requested address'}}"



I'm not sure when the failure started -- this is the first time I'm
seeing it -- I'm fairly certain I ran these tests Thursday or Friday
last week.



Re: [Qemu-devel] [PULL 20/42] spapr: initial implementation for H_TPM_COMM/spapr-tpm-proxy

2019-09-09 Thread Peter Maydell
On Wed, 21 Aug 2019 at 08:26, David Gibson  wrote:
>
> From: Michael Roth 
>
> This implements the H_TPM_COMM hypercall, which is used by an
> Ultravisor to pass TPM commands directly to the host's TPM device, or
> a TPM Resource Manager associated with the device.
>
> This also introduces a new virtual device, spapr-tpm-proxy, which
> is used to configure the host TPM path to be used to service
> requests sent by H_TPM_COMM hcalls, for example:
>
>   -device spapr-tpm-proxy,id=tpmp0,host-path=/dev/tpmrm0
>
> By default, no spapr-tpm-proxy will be created, and hcalls will return
> H_FUNCTION.
>
> The full specification for this hypercall can be found in
> docs/specs/ppc-spapr-uv-hcalls.txt
>
> Since SVM-related hcalls like H_TPM_COMM use a reserved range of
> 0xEF00-0xEF80, we introduce a separate hcall table here to handle
> them.
>
> Signed-off-by: Michael Roth  Message-Id: <20190717205842.17827-3-mdr...@linux.vnet.ibm.com>
> [dwg: Corrected #include for upstream change]
> Signed-off-by: David Gibson 

Hi; Coverity reports an issue in this change (CID 1405304):

> +static ssize_t tpm_execute(SpaprTpmProxy *tpm_proxy, target_ulong *args)
> +{
> +uint64_t data_in = ppc64_phys_to_real(args[1]);
> +target_ulong data_in_size = args[2];
> +uint64_t data_out = ppc64_phys_to_real(args[3]);
> +target_ulong data_out_size = args[4];
> +uint8_t buf_in[TPM_SPAPR_BUFSIZE];
> +uint8_t buf_out[TPM_SPAPR_BUFSIZE];
> +ssize_t ret;
> +
> +trace_spapr_tpm_execute(data_in, data_in_size, data_out, data_out_size);
> +
> +if (data_in_size > TPM_SPAPR_BUFSIZE) {
> +error_report("invalid TPM input buffer size: " TARGET_FMT_lu,
> + data_in_size);
> +return H_P3;
> +}
> +
> +if (data_out_size < TPM_SPAPR_BUFSIZE) {
> +error_report("invalid TPM output buffer size: " TARGET_FMT_lu,
> + data_out_size);
> +return H_P5;
> +}
> +
> +if (tpm_proxy->host_fd == -1) {
> +tpm_proxy->host_fd = open(tpm_proxy->host_path, O_RDWR);
> +if (tpm_proxy->host_fd == -1) {
> +error_report("failed to open TPM device %s: %d",
> + tpm_proxy->host_path, errno);
> +return H_RESOURCE;
> +}
> +}
> +
> +cpu_physical_memory_read(data_in, buf_in, data_in_size);
> +
> +do {
> +ret = write(tpm_proxy->host_fd, buf_in, data_in_size);
> +if (ret > 0) {
> +data_in_size -= ret;
> +}
> +} while ((ret >= 0 && data_in_size > 0) || (ret == -1 && errno == 
> EINTR));
> +
> +if (ret == -1) {
> +error_report("failed to write to TPM device %s: %d",
> + tpm_proxy->host_path, errno);
> +return H_RESOURCE;
> +}
> +
> +do {
> +ret = read(tpm_proxy->host_fd, buf_out, data_out_size);
> +} while (ret == 0 || (ret == -1 && errno == EINTR));
> +
> +if (ret == -1) {
> +error_report("failed to read from TPM device %s: %d",
> + tpm_proxy->host_path, errno);

The tpm_execute() function can unconditionally dereference
tpm_proxy->host_path, implying it can never be NULL...

> +return H_RESOURCE;
> +}
> +
> +cpu_physical_memory_write(data_out, buf_out, ret);
> +args[0] = ret;
> +
> +return H_SUCCESS;
> +}
> +
> +static target_ulong h_tpm_comm(PowerPCCPU *cpu,
> +   SpaprMachineState *spapr,
> +   target_ulong opcode,
> +   target_ulong *args)
> +{
> +target_ulong op = args[0];
> +SpaprTpmProxy *tpm_proxy = spapr->tpm_proxy;
> +
> +if (!tpm_proxy) {
> +error_report("TPM proxy not available");
> +return H_FUNCTION;
> +}
> +
> +trace_spapr_h_tpm_comm(tpm_proxy->host_path ?: "null", op);

...but in this tracing at the callsite we check for whether
it is NULL or not, implying that it can be NULL.

> +
> +switch (op) {
> +case TPM_COMM_OP_EXECUTE:
> +return tpm_execute(tpm_proxy, args);
> +case TPM_COMM_OP_CLOSE_SESSION:
> +spapr_tpm_proxy_reset(tpm_proxy);
> +return H_SUCCESS;
> +default:
> +return H_PARAMETER;
> +}
> +}

Coverity isn't happy about the possible use-after-NULL-check.

thanks
-- PMM



Re: [Qemu-devel] [PULL 03/15] audio: basic support for multi backend audio

2019-09-09 Thread Peter Maydell
On Wed, 21 Aug 2019 at 09:49, Gerd Hoffmann  wrote:
>
> From: Kővágó, Zoltán 
>
> Audio functions no longer access glob_audio_state, instead they get an
> AudioState as a parameter.  This is required in order to support
> multiple backends.
>
> glob_audio_state is also gone, and replaced with a tailq so we can store
> more than one states.
>
> Signed-off-by: Kővágó, Zoltán 
> Message-id: 
> 67aef54f9e729a7160fe95c465351115e392164b.1566168923.git.dirty.ice...@gmail.com
> Signed-off-by: Gerd Hoffmann 

Hi; Coverity spotted an issue in this patch:


> diff --git a/audio/audio_template.h b/audio/audio_template.h
> index c721fed75d7d..54f07338e76f 100644
> --- a/audio/audio_template.h
> +++ b/audio/audio_template.h
> @@ -428,7 +428,7 @@ SW *glue (AUD_open_, TYPE) (
>  struct audsettings *as
>  )
>  {
> -AudioState *s = &glob_audio_state;
> +AudioState *s = card->state;

Here we dereference 'card'...

>  AudiodevPerDirectionOptions *pdo = glue(audio_get_pdo_, TYPE)(s->dev);
>
>  if (audio_bug(__func__, !card || !name || !callback_fn || !as)) {

...but that is before this check on whether card is NULL.
The deref needs to go after the NULL-check.

This is issues CID 1405305 and 1405301 (one each for
AUD_open_in and AUD_open_out).

thanks
-- PMM



[Qemu-devel] [PATCH] ahci: enable pci bus master MemoryRegion before loading ahci engines

2019-09-09 Thread andychiu via Qemu-devel
If Windows 10 guests have enabled 'turn off hard disk after idle'
option in power settings, and the guest has a SATA disk plugged in,
the SATA disk will be turned off after a specified idle time.
If the guest is live migrated or saved/loaded with its SATA disk
turned off, the following error will occur:

qemu-system-x86_64: AHCI: Failed to start FIS receive engine: bad FIS receive 
buffer address
qemu-system-x86_64: Failed to load ich9_ahci:ahci
qemu-system-x86_64: error while loading state for instance 0x0 of device 
':00:1a.0/ich9_ahci'
qemu-system-x86_64: load of migration failed: Operation not permitted

Observation from trace logs shows that a while after Windows 10 turns off
a SATA disk (IDE disks don't have the following behavior),
it will disable the PCI_COMMAND_MASTER flag of the pci device containing
the ahci device. When the the disk is turning back on,
the PCI_COMMAND_MASTER flag will be restored first.
But if the guest is migrated or saved/loaded while the disk is off,
the post_load callback of ahci device, ahci_state_post_load(), will fail
at ahci_cond_start_engines() if the MemoryRegion
pci_dev->bus_master_enable_region is not enabled, with pci_dev pointing
to the PCIDevice struct containing the ahci device.

This patch enables pci_dev->bus_master_enable_region before calling
ahci_cond_start_engines() in ahci_state_post_load(), and restore the
MemoryRegion to its original state afterwards.

Signed-off-by: andychiu 
---
 hw/ide/ahci.c | 53 -
 1 file changed, 36 insertions(+), 17 deletions(-)

diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
index d45393c..83f8c30 100644
--- a/hw/ide/ahci.c
+++ b/hw/ide/ahci.c
@@ -1649,33 +1649,52 @@ static const VMStateDescription vmstate_ahci_device = {
 },
 };
 
+static int ahci_state_load_engines(AHCIState *s, AHCIDevice *ad)
+{
+AHCIPortRegs *pr = &ad->port_regs;
+DeviceState *dev_state = s->container;
+PCIDevice *pci_dev = (PCIDevice *) object_dynamic_cast(OBJECT(dev_state),
+   TYPE_PCI_DEVICE);
+bool pci_bus_master_enabled = pci_dev->bus_master_enable_region.enabled;
+
+if (!(pr->cmd & PORT_CMD_START) && (pr->cmd & PORT_CMD_LIST_ON)) {
+error_report("AHCI: DMA engine should be off, but status bit "
+ "indicates it is still running.");
+return -1;
+}
+if (!(pr->cmd & PORT_CMD_FIS_RX) && (pr->cmd & PORT_CMD_FIS_ON)) {
+error_report("AHCI: FIS RX engine should be off, but status bit "
+ "indicates it is still running.");
+return -1;
+}
+
+memory_region_set_enabled(&pci_dev->bus_master_enable_region, true);
+
+/*
+ * After a migrate, the DMA/FIS engines are "off" and
+ * need to be conditionally restarted
+ */
+pr->cmd &= ~(PORT_CMD_LIST_ON | PORT_CMD_FIS_ON);
+if (ahci_cond_start_engines(ad) != 0) {
+return -1;
+}
+memory_region_set_enabled(&pci_dev->bus_master_enable_region,
+  pci_bus_master_enabled);
+
+return 0;
+}
+
 static int ahci_state_post_load(void *opaque, int version_id)
 {
 int i, j;
 struct AHCIDevice *ad;
 NCQTransferState *ncq_tfs;
-AHCIPortRegs *pr;
 AHCIState *s = opaque;
 
 for (i = 0; i < s->ports; i++) {
 ad = &s->dev[i];
-pr = &ad->port_regs;
-
-if (!(pr->cmd & PORT_CMD_START) && (pr->cmd & PORT_CMD_LIST_ON)) {
-error_report("AHCI: DMA engine should be off, but status bit "
- "indicates it is still running.");
-return -1;
-}
-if (!(pr->cmd & PORT_CMD_FIS_RX) && (pr->cmd & PORT_CMD_FIS_ON)) {
-error_report("AHCI: FIS RX engine should be off, but status bit "
- "indicates it is still running.");
-return -1;
-}
 
-/* After a migrate, the DMA/FIS engines are "off" and
- * need to be conditionally restarted */
-pr->cmd &= ~(PORT_CMD_LIST_ON | PORT_CMD_FIS_ON);
-if (ahci_cond_start_engines(ad) != 0) {
+if (ahci_state_load_engines(s, ad)) {
 return -1;
 }
 
-- 
2.7.4




Re: [Qemu-devel] [PATCH] vnc: fix memory leak when vnc disconnect

2019-09-09 Thread Paolo Bonzini
On 02/09/19 11:02, Daniel P. Berrangé wrote:
>>> === OUTPUT BEGIN ===
>>> ERROR: spaces required around that '*' (ctx:WxB)
>>> #118: FILE: ui/vnc-enc-tight.c:355:
>>> +data = (uint##bpp##_t *)vs->tight->tight.buffer;\
>>>^
>>>
>>>
>> Hello Paolo and the Checkpatch maintainers,
>>
>> I also see this error in scripts/checkpatch.pl.
>> However when I add sapces around '*". I got following error:
>>
>> ERROR: space prohibited before that close parenthesis ')'
>>
>> #124: FILE: ui/vnc-enc-tight.c:355:
>>
>> +data = (uint##bpp##_t * )vs->tight->tight.buffer;   \
>>
>>
>>
>> So I'm confused how to make checkpatch.pl happy.
>>
>>
>> Any one has suggests? Or we need a patch for checkpatch.pl?
> Either ignore this patch warning, or figure out how to fix
> checkpatch.pl though the latter quite be quite hard

checkpatch is confuesd by ##.  It's probably possible to do something
like commit e20122ff0faf07cb701d35e39e106d1783c07725 to fix it, but your
patch is okay without the space after "*".

Paolo



Re: [Qemu-devel] [PATCH v9 0/9] hw/m68k: add Apple Machintosh Quadra 800 machine

2019-09-09 Thread no-reply
Patchew URL: https://patchew.org/QEMU/20190909155813.27760-1-laur...@vivier.eu/



Hi,

This series seems to have some coding style problems. See output below for
more information:

Subject: [Qemu-devel] [PATCH v9 0/9] hw/m68k: add Apple Machintosh Quadra 800 
machine
Message-id: 20190909155813.27760-1-laur...@vivier.eu
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

From https://github.com/patchew-project/qemu
 - [tag update]  patchew/20190909155813.27760-1-laur...@vivier.eu -> 
patchew/20190909155813.27760-1-laur...@vivier.eu
Switched to a new branch 'test'
c2d6100 hw/m68k: define Macintosh Quadra 800
faa8087 hw/m68k: add a dummy SWIM floppy controller
b107670 hw/m68k: add Nubus support for macfb video card
074d549 hw/m68k: add Nubus support
e286de1 hw/m68k: add macfb video card
113a594 hw/m68k: implement ADB bus support for via
579567e hw/m68k: add via support
dcd3348 dp8393x: manage big endian bus
173e471 esp: add pseudo-DMA as used by Macintosh

=== OUTPUT BEGIN ===
1/9 Checking commit 173e4715350e (esp: add pseudo-DMA as used by Macintosh)
2/9 Checking commit dcd334895d20 (dp8393x: manage big endian bus)
3/9 Checking commit 579567e8e64f (hw/m68k: add via support)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#39: 
new file mode 100644

ERROR: space prohibited after that '&&' (ctx:WxW)
#387: FILE: hw/misc/mac_via.c:344:
+if (!(v1s->last_b & VIA1B_vRTCClk) && (s->b & VIA1B_vRTCClk)) {
^

total: 1 errors, 1 warnings, 814 lines checked

Patch 3/9 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

4/9 Checking commit 113a5948138a (hw/m68k: implement ADB bus support for via)
5/9 Checking commit e286de13043d (hw/m68k: add macfb video card)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#53: 
new file mode 100644

total: 0 errors, 1 warnings, 504 lines checked

Patch 5/9 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
6/9 Checking commit 074d549a6e03 (hw/m68k: add Nubus support)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#38: 
new file mode 100644

total: 0 errors, 1 warnings, 518 lines checked

Patch 6/9 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
7/9 Checking commit b107670bf36a (hw/m68k: add Nubus support for macfb video 
card)
8/9 Checking commit faa8087e7199 (hw/m68k: add a dummy SWIM floppy controller)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#37: 
new file mode 100644

total: 0 errors, 1 warnings, 510 lines checked

Patch 8/9 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
9/9 Checking commit c2d6100612f7 (hw/m68k: define Macintosh Quadra 800)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#96: 
new file mode 100644

total: 0 errors, 1 warnings, 539 lines checked

Patch 9/9 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20190909155813.27760-1-laur...@vivier.eu/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [Qemu-devel] [Qemu-arm] [RFC PATCH 12/14] hw/arm/bcm2836: Add the BCM2838 which uses a GICv2

2019-09-09 Thread Philippe Mathieu-Daudé
Hi Luc,

On 9/5/19 10:41 AM, Luc Michel wrote:
> On 9/4/19 7:13 PM, Philippe Mathieu-Daudé wrote:
>> The BCM2838 is improvement of the BCM2837:
>> - Cortex-A72 instead of the A53
>> - peripheral block and local soc controller are mapped differently,
>> - GICv2
>> - PCIe block
>> - exhanced MMU to address over 4GiB of SDRAM
>>
>> See https://www.raspberrypi.org/forums/viewtopic.php?t=244479&start=25
>> and https://patchwork.kernel.org/patch/11053097/
>>
>> This patch starts mapping the GICv2 but interrupt lines are NOT
>> wired (yet).
>>
>> This is enough to start running the Ubuntu kernel8.img from [1].
>>
>> Extract the kernel with:
>>
>>$ mkdir bootpart
>>$ guestfish \
>>--ro \
>>-a ubuntu-18.04.3-preinstalled-server-arm64+raspi4.img \
>>-m /dev/sda1
>>Welcome to guestfish, the guest filesystem shell for
>>editing virtual machine filesystems and disk images.
>>
>>> ls /
>>COPYING.linux
>>LICENCE.broadcom
>>System.map
>>armstub8-gic.bin
>>bcm2710-rpi-3-b-plus.dtb
>>bcm2710-rpi-3-b.dtb
>>bcm2710-rpi-cm3.dtb
>>bcm2711-rpi-4-b.dtb
>>bcm2837-rpi-3-b-plus.dtb
>>bcm2837-rpi-3-b.dtb
>>cmdline.txt
>>config.txt
>>fixup4.dat
>>fixup4cd.dat
>>fixup4db.dat
>>fixup4x.dat
>>kernel8.img
>>overlays
>>start4.elf
>>start4cd.elf
>>start4db.elf
>>start4x.elf
>>> copy-out / bootpart/
>>> q
>>
>> Then some progress can be noticed running:
>>
>>$ qemu-system-aarch64 -d unimp,guest_errors,int,in_asm \
>>-M raspi4 \
>>-kernel bootpart/kernel8.img \
>>-dtb bootpart/bcm2711-rpi-4-b.dtb \
>>-initrd bootpart/boot/initrd.img \
>>-append \
>>   "earlycon=pl011,0xfe201000 console=ttyAMA0 console=tty1 loglevel=8"
>>
>> Not very interesting, but it runs until configuring the GIC.
>> (remove 'in_asm' if too verbose).
>>
>> TODO:
>>
>> - wire IRQs to the GIC :)
>>
>> - map the SPI bootrom from [3] (boot sequence: [4])
>>
>> - per [2] we could try booting without using the GIC, adding "enable_gic=0"
>>in config.txt. this variable is parsed by the firmware:
>>
>>$ fgrep -r enable_gic bootpart
>>Binary file bootpart/start4x.elf matches
>>Binary file bootpart/start4.elf matches
>>Binary file bootpart/start4db.elf matches
>>Binary file bootpart/start4cd.elf matches
>>bootpart/config.txt:enable_gic=1
>>
>>the stub [5] doesn't seem to check a register for it.
>>maybe it falls back to kernel7l?
>>
>> - decompile start4.elf to check how 'enable_gic' is used
>>using vc4 toolchain from [6]
>>
>> [1] https://github.com/TheRemote/Ubuntu-Server-raspi4-unofficial/releases
>> [2] 
>> https://jamesachambers.com/raspberry-pi-ubuntu-server-18-04-2-installation-guide/
>> [3] 
>> https://www.raspberrypi.org/documentation/hardware/raspberrypi/booteeprom.md
>> [4] 
>> https://raspberrypi.stackexchange.com/questions/10442/what-is-the-boot-sequence
>> [5] 
>> https://github.com/raspberrypi/tools/commit/7f4a937e1bacbc111a22552169bc890b4bb26a94#diff-8c41083e9fa0c98f1c3015e11b897444
>> [6] https://github.com/christinaa/rpi-open-firmware
>>
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ---
>>   hw/arm/bcm2836.c | 75 
>>   include/hw/arm/bcm2836.h |  3 ++
>>   2 files changed, 78 insertions(+)
>>
>> diff --git a/hw/arm/bcm2836.c b/hw/arm/bcm2836.c
>> index 019e67b906..d89d7cd71d 100644
>> --- a/hw/arm/bcm2836.c
>> +++ b/hw/arm/bcm2836.c
>> @@ -21,6 +21,7 @@ struct BCM283XInfo {
>>   const char *cpu_type;
>>   hwaddr peri_base; /* Peripheral base address seen by the CPU */
>>   hwaddr ctrl_base; /* Interrupt controller and mailboxes etc. */
>> +hwaddr gic_base;
>>   int clusterid;
>>   };
>>   
>> @@ -40,9 +41,25 @@ static const BCM283XInfo bcm283x_socs[] = {
>>   .ctrl_base = 0x4000,
>>   .clusterid = 0x0,
>>   },
>> +{
>> +.name = TYPE_BCM2838,
>> +.cpu_type = ARM_CPU_TYPE_NAME("cortex-a72"),
>> +.peri_base = 0xfe00,
>> +.ctrl_base = 0xff80,
>> +.gic_base = 0x4,
>> +},
>>   #endif
>>   };
>>   
>> +#define GIC_NUM_IRQS256
>> +
>> +#define GIC_BASE_OFS0x
>> +#define GIC_DIST_OFS0x1000
>> +#define GIC_CPU_OFS 0x2000
>> +#define GIC_VIFACE_THIS_OFS 0x4000
>> +#define GIC_VIFACE_OTHER_OFS(cpu)  (0x5000 + (cpu) * 0x200)
>> +#define GIC_VCPU_OFS0x6000
>> +
>>   static void bcm2836_init(Object *obj)
>>   {
>>   BCM283XState *s = BCM283X(obj);
>> @@ -55,6 +72,11 @@ static void bcm2836_init(Object *obj)
>>   info->cpu_type, &error_abort, NULL);
>>   }
>>   
>> +if (info->gic_base) {
>> +sysbus_init_child_obj(obj, "gic", &s->gic, sizeof(s->gic),
>> +  TYPE_ARM_GIC);
>> +}
>> +
>>   sysbus_init_child_obj(obj, "control", &s->con

Re: [Qemu-devel] [PATCH] Replace '-machine accel=xyz' with '-accel xyz'

2019-09-09 Thread Paolo Bonzini
On 04/09/19 07:27, Thomas Huth wrote:
> We've got a separate option to configure the accelerator nowadays, which
> is shorter to type and the preferred way of specifying an accelerator.
> Use it in the source and examples to show that it is the favored option.
> (However, do not touch the places yet which also specify other machine
> options or multiple accelerators - these are currently still better
> handled with one single "-machine" statement instead)
> 
> Signed-off-by: Thomas Huth 
> ---
>  python/qemu/qtest.py| 2 +-
>  qemu-deprecated.texi| 3 +--
>  qemu-options.hx | 2 +-
>  tests/libqtest.c| 2 +-
>  tests/migration/guestperf/engine.py | 2 +-
>  tests/qemu-iotests/172  | 2 +-
>  6 files changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/python/qemu/qtest.py b/python/qemu/qtest.py
> index eebcc233ed..3f1d2cb325 100644
> --- a/python/qemu/qtest.py
> +++ b/python/qemu/qtest.py
> @@ -96,7 +96,7 @@ class QEMUQtestMachine(QEMUMachine):
>  def _base_args(self):
>  args = super(QEMUQtestMachine, self)._base_args()
>  args.extend(['-qtest', 'unix:path=' + self._qtest_path,
> - '-machine', 'accel=qtest'])
> + '-accel', 'qtest'])
>  return args
>  
>  def _pre_launch(self):
> diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
> index 00a4b6f350..0982e41698 100644
> --- a/qemu-deprecated.texi
> +++ b/qemu-deprecated.texi
> @@ -26,8 +26,7 @@ The @option{enforce-config-section} parameter is replaced 
> by the
>  
>  @subsection -no-kvm (since 1.3.0)
>  
> -The ``-no-kvm'' argument is now a synonym for setting
> -``-machine accel=tcg''.
> +The ``-no-kvm'' argument is now a synonym for setting ``-accel tcg''.
>  
>  @subsection -usbdevice (since 2.10.0)
>  
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 09e6439646..e0bba2abd1 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -4156,7 +4156,7 @@ STEXI
>  Enable FIPS 140-2 compliance mode.
>  ETEXI
>  
> -HXCOMM Deprecated by -machine accel=tcg property
> +HXCOMM Deprecated by -accel tcg
>  DEF("no-kvm", 0, QEMU_OPTION_no_kvm, "", QEMU_ARCH_I386)
>  
>  DEF("msg", HAS_ARG, QEMU_OPTION_msg,
> diff --git a/tests/libqtest.c b/tests/libqtest.c
> index 2713b86cf7..67e39c59e7 100644
> --- a/tests/libqtest.c
> +++ b/tests/libqtest.c
> @@ -238,7 +238,7 @@ QTestState *qtest_init_without_qmp_handshake(const char 
> *extra_args)
>"-qtest-log %s "
>"-chardev socket,path=%s,id=char0 "
>"-mon chardev=char0,mode=control "
> -  "-machine accel=qtest "
> +  "-accel qtest "
>"-display none "
>"%s", qemu_binary, socket_path,
>getenv("QTEST_LOG") ? "/dev/fd/2" : 
> "/dev/null",
> diff --git a/tests/migration/guestperf/engine.py 
> b/tests/migration/guestperf/engine.py
> index f13dbea800..1dd04ce33b 100644
> --- a/tests/migration/guestperf/engine.py
> +++ b/tests/migration/guestperf/engine.py
> @@ -287,7 +287,7 @@ class Engine(object):
>  cmdline = "'" + cmdline + "'"
>  
>  argv = [
> -"-machine", "accel=kvm",
> +"-accel", "kvm",
>  "-cpu", "host",
>  "-kernel", self._kernel,
>  "-initrd", self._initrd,
> diff --git a/tests/qemu-iotests/172 b/tests/qemu-iotests/172
> index ba7dad9057..d67997e5f6 100755
> --- a/tests/qemu-iotests/172
> +++ b/tests/qemu-iotests/172
> @@ -55,7 +55,7 @@ do_run_qemu()
>  done
>  fi
>  echo quit
> -) | $QEMU -machine accel=qtest -nographic -monitor stdio -serial none 
> "$@"
> +) | $QEMU -accel qtest -nographic -monitor stdio -serial none "$@"
>  echo
>  }
>  
> 

Acked-by: Paolo Bonzini 

Thanks.  While "-accel kvm:tcg" is not going to be supported, the above
replacement are all good.

Paolo



Re: [Qemu-devel] [PATCH 2/2] block/nvme: add support for discard

2019-09-09 Thread John Snow



On 9/9/19 5:25 AM, Max Reitz wrote:
> On 05.09.19 19:27, John Snow wrote:
> 
> [...]
> 
>> You also probably require review (or at least an ACK) from Keith Busch
>> who maintains this file.
> 
> Keith actually maintains the NVMe guest device; technically, Fam is the
> NVMe block driver maintainer.

W h o o p s. Thanks for correcting me.

Well, if it's Fam -- he seems a little busier lately -- it's probably
not so crucial to gate on his approval. I thought it'd be nice to at
least get an ACK from someone who has used this module before, because I
haven't -- I was just giving some style review to help push it along.

(On that note, if you felt like my style review was wrong or isn't worth
doing -- it is always perfectly fair to just say so, along with some
reason as to why you won't -- that way patches won't rot on the list
when people may have gotten the impression that a V2 is warranted.)

--js



Re: [Qemu-devel] Greetings qemu folks

2019-09-09 Thread Peter Maydell
On Mon, 9 Sep 2019 at 17:56, John Snow  wrote:
> On 9/7/19 9:58 AM, Toe Dev wrote:
> > 2) My main target is to output a lot of this to console cause I new to qemu
> > and I want fastfeedback on stuff like this. I try start
> > qemu with -D option but the log files never have been  written
> > by qemu, but either no success.
> >
>
> QEMU doesn't output a lot of information by default, `-D` might be kind
> of misleading. (Actually, I've never used it...)

-D just sets the filename for output of -d debug logging. It won't
actually log anything there unless you use the -d option to specify
what to log.

The -d logs are largely useful for doing TCG (emulation) development
work; if KVM is what you care about then tracepoints are probably
more helpful. (Tracepoints work with TCG as well.)

thanks
-- PMM



Re: [Qemu-devel] [PATCH v2 0/3] tests/tcg: disentangle makefiles

2019-09-09 Thread Paolo Bonzini
On 04/09/19 16:27, Alex Bennée wrote:
>> Ping?
> 
> Sorry I should have said I've queued it to testing/next. I'll post the
> series shortly after I've squashed the last annoying python 3.<>6
> problem.

Great, thanks.

Paolo



Re: [Qemu-devel] [PATCH v9 0/9] hw/m68k: add Apple Machintosh Quadra 800 machine

2019-09-09 Thread no-reply
Patchew URL: https://patchew.org/QEMU/20190909155813.27760-1-laur...@vivier.eu/



Hi,

This series seems to have some coding style problems. See output below for
more information:

Subject: [Qemu-devel] [PATCH v9 0/9] hw/m68k: add Apple Machintosh Quadra 800 
machine
Message-id: 20190909155813.27760-1-laur...@vivier.eu
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 - [tag update]  patchew/20190906113534.10907-1-th...@redhat.com -> 
patchew/20190906113534.10907-1-th...@redhat.com
 - [tag update]  patchew/20190906113920.11271-1-th...@redhat.com -> 
patchew/20190906113920.11271-1-th...@redhat.com
 - [tag update]  patchew/20190906152624.14784-1-th...@redhat.com -> 
patchew/20190906152624.14784-1-th...@redhat.com
 * [new tag] patchew/20190909155813.27760-1-laur...@vivier.eu -> 
patchew/20190909155813.27760-1-laur...@vivier.eu
Switched to a new branch 'test'
0d8a805 hw/m68k: define Macintosh Quadra 800
2e809f8 hw/m68k: add a dummy SWIM floppy controller
9db1a83 hw/m68k: add Nubus support for macfb video card
9d82148 hw/m68k: add Nubus support
abe34f5 hw/m68k: add macfb video card
355e9ab hw/m68k: implement ADB bus support for via
1d18ba6 hw/m68k: add via support
fbb1ecf dp8393x: manage big endian bus
d60e6a9 esp: add pseudo-DMA as used by Macintosh

=== OUTPUT BEGIN ===
1/9 Checking commit d60e6a94ac0b (esp: add pseudo-DMA as used by Macintosh)
2/9 Checking commit fbb1ecfe661f (dp8393x: manage big endian bus)
3/9 Checking commit 1d18ba67a8ff (hw/m68k: add via support)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#39: 
new file mode 100644

ERROR: space prohibited after that '&&' (ctx:WxW)
#387: FILE: hw/misc/mac_via.c:344:
+if (!(v1s->last_b & VIA1B_vRTCClk) && (s->b & VIA1B_vRTCClk)) {
^

total: 1 errors, 1 warnings, 814 lines checked

Patch 3/9 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

4/9 Checking commit 355e9ab8413e (hw/m68k: implement ADB bus support for via)
5/9 Checking commit abe34f53667b (hw/m68k: add macfb video card)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#53: 
new file mode 100644

total: 0 errors, 1 warnings, 504 lines checked

Patch 5/9 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
6/9 Checking commit 9d821480d8d9 (hw/m68k: add Nubus support)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#38: 
new file mode 100644

total: 0 errors, 1 warnings, 518 lines checked

Patch 6/9 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
7/9 Checking commit 9db1a839919c (hw/m68k: add Nubus support for macfb video 
card)
8/9 Checking commit 2e809f800609 (hw/m68k: add a dummy SWIM floppy controller)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#37: 
new file mode 100644

total: 0 errors, 1 warnings, 510 lines checked

Patch 8/9 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
9/9 Checking commit 0d8a80538968 (hw/m68k: define Macintosh Quadra 800)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#96: 
new file mode 100644

total: 0 errors, 1 warnings, 539 lines checked

Patch 9/9 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20190909155813.27760-1-laur...@vivier.eu/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

[Qemu-devel] [Bug 1805256] Re: qemu-img hangs on high core count ARM system

2019-09-09 Thread Rafael David Tinoco
Alright, with a d06 aarch64 machine I was able to reproduce it after 8
attempts.I'll debug it today and provide feedback on my findings.

(gdb) bt full
#0  0xb0b2181c in __GI_ppoll (fds=0xce5ab770, nfds=4, 
timeout=, timeout@entry=0x0,
sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:39
_x3tmp = 0
_x0tmp = 187650583213936
_x0 = 187650583213936
_x3 = 0
_x4tmp = 8
_x1tmp = 4
_x1 = 4
_x4 = 8
_x2tmp = 
_x2 = 0
_x8 = 73
_sys_result = 
_sys_result = 
sc_cancel_oldtype = 0
sc_ret = 
tval = {tv_sec = 0, tv_nsec = 187650583137792}
#1  0xcd2a773c in ppoll (__ss=0x0, __timeout=0x0, __nfds=, __fds=)
at /usr/include/aarch64-linux-gnu/bits/poll2.h:77
No locals.
#2  qemu_poll_ns (fds=, nfds=, 
timeout=timeout@entry=-1) at ./util/qemu-timer.c:322
No locals.
#3  0xcd2a8764 in os_host_main_loop_wait (timeout=-1) at 
./util/main-loop.c:233
context = 0xce599d90
ret = 
context = 
ret = 
#4  main_loop_wait (nonblocking=) at ./util/main-loop.c:497
ret = 
timeout = 4294967295
timeout_ns = 
#5  0xcd1df454 in convert_do_copy (s=0xf9b2b1d8) at 
./qemu-img.c:1981
ret = 
i = 
n = 
sector_num = 
ret = 
i = 
n = 
sector_num = 
#6  img_convert (argc=, argv=) at 
./qemu-img.c:2457
c = 
bs_i = 
flags = 16898
src_flags = 0
fmt = 0xf9b2bad1 "qcow2"
out_fmt = 
cache = 0xcd2cb1c8 "unsafe"
src_cache = 0xcd2ca9c0 "writeback"
out_baseimg = 
out_filename = 
out_baseimg_param = 
snapshot_name = 0x0
drv = 
proto_drv = 
bdi = {cluster_size = 65536, vm_state_offset = 32212254720, is_dirty = 
false, unallocated_blocks_are_zero = true,
  needs_compressed_writes = false}
out_bs = 
opts = 0xce5ab390
sn_opts = 0x0
create_opts = 0xce5ab0c0
open_opts = 
options = 0x0
local_err = 0x0
writethrough = false
src_writethrough = false
quiet = 
image_opts = false
skip_create = false
progress = 
tgt_image_opts = false
ret = 
force_share = false
explict_min_sparse = false
s = {src = 0xce577240, src_sectors = 0xce577300, src_num = 1, 
total_sectors = 62914560,allocated_sectors = 9572096, allocated_done = 6541440, 
sector_num = 8863744, wr_offs = 8859776, status = BLK_DATA, sector_next_status 
= 8863744, target = 0xce5bd2a0, has_zero_init = true,compressed = false, 
unallocated_blocks_are_zero = true, target_has_backing = false, 
target_backing_sectors = -1, wr_in_order = true, copy_range = false, min_sparse 
= 8, alignment = 8,cluster_sectors = 128, buf_sectors = 4096, num_coroutines = 
8, running_coroutines = 8, co = {0xce5ceda0,0xce5cef50, 0xce5cf100, 
0xce5cf2b0, 0xce5cf460, 0xce5cf610, 0xce5cf7c0,0xce5cf970, 
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, wait_sector_num = {-1, 8859904, 
8860928, 8863360,8861952, 8862976, 8862592, 8861440, 0, 0, 0, 0, 0, 0, 0, 0}, 
lock = {locked = 0, ctx = 0x0, from_push = {slh_first = 0x0}, to_pop = 
{slh_first = 0x0}, handoff = 0, sequence = 0, holder = 0x0}, ret = -115}
__PRETTY_FUNCTION__ = "img_convert"
#7  0xcd1d8400 in main (argc=7, argv=) at 
./qemu-img.c:4976
cmd = 0xcd34ad78 
cmdname = 
local_error = 0x0
trace_file = 0x0
c = 
long_options = {{name = 0xcd2cbbb0 "help", has_arg = 0, flag = 0x0, 
val = 104}, {
name = 0xcd2cbc78 "version", has_arg = 0, flag = 0x0, val = 
86}, {name = 0xcd2cbc80 "trace",
has_arg = 1, flag = 0x0, val = 84}, {name = 0x0, has_arg = 0, flag 
= 0x0, val = 0}}

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1805256

Title:
  qemu-img hangs on high core count ARM system

Status in QEMU:
  Confirmed
Status in qemu package in Ubuntu:
  In Progress

Bug description:
  On the HiSilicon D06 system - a 96 core NUMA arm64 box - qemu-img
  frequently hangs (~50% of the time) with this command:

  qemu-img convert -f qcow2 -O qcow2 /tmp/cloudimg /tmp/cloudimg2

  Where "cloudimg" is a standard qcow2 Ubuntu cloud image. This
  qcow2->qcow2 conversion happens to be something uvtool does every time
  it fetches images.

  Once hung, attaching gdb gives the following backtrace:

  (gdb) bt
  #0  0xae4f8154 in __GI_ppoll (fds=0xe8a67dc0, 
nfds=187650274213760, 
  timeout=, timeout@entry=0x0, sigmask=0xc123b950)
  at ../sysdeps/unix/sysv/linux/ppoll.c:39
  #1  0xbbefaf00 in ppoll (__ss=0x0, __timeout=0x0, __nfds=, 
  __fds=) at /usr/include/aarch64

Re: [Qemu-devel] Greetings qemu folks

2019-09-09 Thread John Snow



On 9/7/19 9:58 AM, Toe Dev wrote:
> I am new in QEMU developing and I have general questions about QEMU source
> code as I could not find any guidelines about it.
> 

Hi, welcome!

> 1) I have no success running qemu in nographic mode.
>The internet says using chardev driver to redirect kernel output to host
> OS...
>what is the right way to do that?

What have you tried and what were the results?

For me, with standard Fedora installations, I can usually just pass
`-monitor stdio` and get a console in my terminal (along with a GTK window.)

`-nographic` also seems to work just fine.

Post your command line, QEMU version, and the version of the guest OS
you're trying to boot. The guest OS may or may not need to be configured
to actually send output to the console.

> 
> 2) My main target is to output a lot of this to console cause I new to qemu
> and I want fastfeedback on stuff like this. I try start
> qemu with -D option but the log files never have been  written
> by qemu, but either no success.
> 

QEMU doesn't output a lot of information by default, `-D` might be kind
of misleading. (Actually, I've never used it...)

We have a tracing subsystem, but it might differ from logging in that
you enable tracepoints on a per-trace basis.

Take a look at qemu/docs/devel/tracing.txt for information on driving
the tracing module.

> 3) What is the right way to do logging in qemu for development purposes?
> 

The tracing subsystem.

> Best Regards,
> 
> Yali.
> 



Re: [Qemu-devel] [PATCH v9 8/9] hw/m68k: add a dummy SWIM floppy controller

2019-09-09 Thread Laurent Vivier
Le 09/09/2019 à 18:32, Aleksandar Markovic a écrit :
> 
> 09.09.2019. 18.03, "Laurent Vivier"  > је написао/ла:
>>
>> Co-developed-by: Mark Cave-Ayland  >
>> Signed-off-by: Mark Cave-Ayland  >
>> Signed-off-by: Laurent Vivier  >
>> Reviewed-by: Hervé Poussineau  >
>> ---
> 
> Laurent, hi!
> 
> I am not sure how "Co-developed-by:" fits in our workflow. There was
> some recent talk on restricting those marks to only a handful of them,
> and preventing new ones from introducing (the starter example was
> something like "Regression-tested-by:"). Perhaps a final sentence "This
> patch was co-developed with Mark..." would be better?
> 

"Co-developed-by:" is described in
linux/Documentation/process/submitting-patches.rst [1] whereas
"Regression-tested-by:" is not.

So as I'm not aware of the discussions you point out, are we in the same
situation here?

Thanks,
Laurent

[1] https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html



Re: [Qemu-devel] [PATCH] nbd/client: Add hint when TLS is missing

2019-09-09 Thread Eric Blake
On 9/9/19 4:13 AM, Daniel P. Berrangé wrote:
> On Sat, Sep 07, 2019 at 12:20:55PM -0500, Eric Blake wrote:
>> I received an off-list report of failure to connect to an NBD server
>> expecting an x509 certificate, when the client was attempting something
>> similar to this command line:
>>

>> +++ b/nbd/client.c
>> @@ -204,6 +204,7 @@ static int nbd_handle_reply_err(QIOChannel *ioc, 
>> NBDOptionReply *reply,
>>  case NBD_REP_ERR_TLS_REQD:
>>  error_setg(errp, "TLS negotiation required before option %" PRIu32
>> " (%s)", reply->option, nbd_opt_lookup(reply->option));
>> +error_append_hint(errp, "Did you forget a valid tls-creds?\n");
>>  break;
>>
>>  case NBD_REP_ERR_UNKNOWN:
> 
> Reviewed-by: Daniel P. Berrangé 


Thanks. I should really learn to finish my iotest runs before posting,
because I have to squash this in before queuing through my NBD tree.

diff --git i/tests/qemu-iotests/233.out w/tests/qemu-iotests/233.out
index 24321efa113b..c3c344811b2b 100644
--- i/tests/qemu-iotests/233.out
+++ w/tests/qemu-iotests/233.out
@@ -21,8 +21,10 @@ server reported: TLS not configured

 == check plain client to TLS server fails ==
 qemu-img: Could not open 'nbd://localhost:PORT': TLS negotiation
required before option 7 (go)
+Did you forget a valid tls-creds?
 server reported: Option 0x7 not permitted before TLS
 qemu-nbd: TLS negotiation required before option 3 (list)
+Did you forget a valid tls-creds?
 server reported: Option 0x3 not permitted before TLS

 == check TLS works ==


-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH] tests/qemu-iotests/check: Replace "tests" with "iotests" in final status text

2019-09-09 Thread John Snow



On 9/6/19 7:39 AM, Thomas Huth wrote:
> When running "make check -j8" or something similar, the iotests are
> running in parallel with the other tests. So when they are printing
> out "Passed all xx tests" or a similar status message at the end,
> it might not be quite clear that this message belongs to the iotests,
> since the output might be mixed with the other tests. Thus change the
> word "tests" here to "iotests" instead to avoid confusion.
> 
> Signed-off-by: Thomas Huth 

Yeah, why not? Being explicit is nice.

Reviewed-by: John Snow 

> ---
>  tests/qemu-iotests/check | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/tests/qemu-iotests/check b/tests/qemu-iotests/check
> index c24874ff4a..2f1cf72abc 100755
> --- a/tests/qemu-iotests/check
> +++ b/tests/qemu-iotests/check
> @@ -694,12 +694,12 @@ END{ if (NR > 0) {
>  if [ ! -z "$n_bad" -a $n_bad != 0 ]
>  then
>  echo "Failures:$bad"
> -echo "Failed $n_bad of $try tests"
> +echo "Failed $n_bad of $try iotests"
>  echo "Failures:$bad" | fmt >>check.log
> -echo "Failed $n_bad of $try tests" >>check.log
> +echo "Failed $n_bad of $try iotests" >>check.log
>  else
> -echo "Passed all $try tests"
> -echo "Passed all $try tests" >>check.log
> +echo "Passed all $try iotests"
> +echo "Passed all $try iotests" >>check.log
>  fi
>  needwrap=false
>  fi
> 




Re: [Qemu-devel] [PATCH] tests/Makefile: Do not print the name of the check-block.sh shell script

2019-09-09 Thread John Snow



On 9/6/19 7:35 AM, Thomas Huth wrote:
> The check script is already printing out which iotest is currently
> running, so printing out the name of the check-block.sh shell script
> looks superfluous here.
> 
> Signed-off-by: Thomas Huth 

Makes sense.

Acked-by: John Snow 

> ---
>  tests/Makefile.include | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tests/Makefile.include b/tests/Makefile.include
> index f5ac09549c..a36317ac87 100644
> --- a/tests/Makefile.include
> +++ b/tests/Makefile.include
> @@ -1097,7 +1097,7 @@ QEMU_IOTESTS_HELPERS-$(call 
> land,$(CONFIG_SOFTMMU),$(CONFIG_LINUX)) = tests/qemu
>  check-tests/check-block.sh: tests/check-block.sh qemu-img$(EXESUF) \
>   qemu-io$(EXESUF) qemu-nbd$(EXESUF) $(QEMU_IOTESTS_HELPERS-y) \
>   $(patsubst %,%/all,$(filter %-softmmu,$(TARGET_DIRS)))
> - $<
> + @$<
>  
>  .PHONY: $(patsubst %, check-%, $(check-qapi-schema-y))
>  $(patsubst %, check-%, $(check-qapi-schema-y)): check-%.json: 
> $(SRC_PATH)/%.json
> 



Re: [Qemu-devel] [PATCH] tests/Makefile: test-char does not need libqtest

2019-09-09 Thread John Snow



On 9/6/19 11:26 AM, Thomas Huth wrote:
> No need to link the libqtest objects here.
> 
> Signed-off-by: Thomas Huth 

Reviewed-by: John Snow 

> ---
>  tests/Makefile.include | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tests/Makefile.include b/tests/Makefile.include
> index a35431ca0a..7ee2f9cb5d 100644
> --- a/tests/Makefile.include
> +++ b/tests/Makefile.include
> @@ -525,7 +525,7 @@ tests/check-qlit$(EXESUF): tests/check-qlit.o 
> $(test-util-obj-y)
>  tests/check-qom-interface$(EXESUF): tests/check-qom-interface.o 
> $(test-qom-obj-y)
>  tests/check-qom-proplist$(EXESUF): tests/check-qom-proplist.o 
> $(test-qom-obj-y)
>  
> -tests/test-char$(EXESUF): tests/test-char.o $(test-util-obj-y) 
> $(qtest-obj-y) $(test-io-obj-y) $(chardev-obj-y) tests/socket-helpers.o
> +tests/test-char$(EXESUF): tests/test-char.o $(test-util-obj-y) 
> $(test-io-obj-y) $(chardev-obj-y) tests/socket-helpers.o
>  tests/test-coroutine$(EXESUF): tests/test-coroutine.o $(test-block-obj-y)
>  tests/test-aio$(EXESUF): tests/test-aio.o $(test-block-obj-y)
>  tests/test-aio-multithread$(EXESUF): tests/test-aio-multithread.o 
> $(test-block-obj-y)
> 



Re: [Qemu-devel] [PATCH v9 8/9] hw/m68k: add a dummy SWIM floppy controller

2019-09-09 Thread Laurent Vivier
Le 09/09/2019 à 18:18, Dr. David Alan Gilbert a écrit :
> * Peter Maydell (peter.mayd...@linaro.org) wrote:
>> On Mon, 9 Sep 2019 at 17:05, Laurent Vivier  wrote:
>>>
>>> Co-developed-by: Mark Cave-Ayland 
>>> Signed-off-by: Mark Cave-Ayland 
>>> Signed-off-by: Laurent Vivier 
>>> Reviewed-by: Hervé Poussineau 
>>
>>> +static void sysbus_swim_class_init(ObjectClass *oc, void *data)
>>> +{
>>> +DeviceClass *dc = DEVICE_CLASS(oc);
>>> +
>>> +dc->realize = sysbus_swim_realize;
>>> +}
>>
>> Missing reset and VMState for migration. These should be
>> baseline requirements for adding new device models to the
>> tree, because in an ideal world every device would support
>> both -- we should be gradually fixing the existing devices
>> which are missing these, and not letting new devices in,
>> so the situation gets gradually better, not worse.
> 
> I'm happy to see things marked unmigratable instead for obscure
> devices; I don't see the need to worry about migration for stuff
> that's not going to be migrated.
> 

I think in this case it's better to mark it unmigratable because the
structure will change in the future to really manage floppy and it
avoids to introduces a new version of the migration data stream.

Thanks,
Laurent




Re: [Qemu-devel] [PATCH v9 8/9] hw/m68k: add a dummy SWIM floppy controller

2019-09-09 Thread Aleksandar Markovic
09.09.2019. 18.03, "Laurent Vivier"  је написао/ла:
>
> Co-developed-by: Mark Cave-Ayland 
> Signed-off-by: Mark Cave-Ayland 
> Signed-off-by: Laurent Vivier 
> Reviewed-by: Hervé Poussineau 
> ---

Laurent, hi!

I am not sure how "Co-developed-by:" fits in our workflow. There was some
recent talk on restricting those marks to only a handful of them, and
preventing new ones from introducing (the starter example was something
like "Regression-tested-by:"). Perhaps a final sentence "This patch was
co-developed with Mark..." would be better?

Aleksandar

>  hw/block/Kconfig|   3 +
>  hw/block/Makefile.objs  |   1 +
>  hw/block/swim.c | 421 
>  include/hw/block/swim.h |  76 
>  4 files changed, 501 insertions(+)
>  create mode 100644 hw/block/swim.c
>  create mode 100644 include/hw/block/swim.h
>
> diff --git a/hw/block/Kconfig b/hw/block/Kconfig
> index df96dc5dcc..2d17f481ad 100644
> --- a/hw/block/Kconfig
> +++ b/hw/block/Kconfig
> @@ -37,3 +37,6 @@ config VHOST_USER_BLK
>  # Only PCI devices are provided for now
>  default y if VIRTIO_PCI
>  depends on VIRTIO && VHOST_USER && LINUX
> +
> +config SWIM
> +bool
> diff --git a/hw/block/Makefile.objs b/hw/block/Makefile.objs
> index f5f643f0cc..28c2495a00 100644
> --- a/hw/block/Makefile.objs
> +++ b/hw/block/Makefile.objs
> @@ -8,6 +8,7 @@ common-obj-$(CONFIG_XEN) += xen-block.o
>  common-obj-$(CONFIG_ECC) += ecc.o
>  common-obj-$(CONFIG_ONENAND) += onenand.o
>  common-obj-$(CONFIG_NVME_PCI) += nvme.o
> +common-obj-$(CONFIG_SWIM) += swim.o
>
>  obj-$(CONFIG_SH4) += tc58128.o
>
> diff --git a/hw/block/swim.c b/hw/block/swim.c
> new file mode 100644
> index 00..6e26915238
> --- /dev/null
> +++ b/hw/block/swim.c
> @@ -0,0 +1,421 @@
> +/*
> + * QEMU Macintosh floppy disk controller emulator (SWIM)
> + *
> + * Copyright (c) 2014-2018 Laurent Vivier 
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2.  See
> + * the COPYING file in the top-level directory.
> + *
> + */
> +
> +#include "qemu/osdep.h"
> +#include "qemu/main-loop.h"
> +#include "qapi/error.h"
> +#include "sysemu/block-backend.h"
> +#include "hw/sysbus.h"
> +#include "hw/block/block.h"
> +#include "hw/block/swim.h"
> +#include "hw/qdev-properties.h"
> +
> +/* IWM registers */
> +
> +#define IWM_PH0L0
> +#define IWM_PH0H1
> +#define IWM_PH1L2
> +#define IWM_PH1H3
> +#define IWM_PH2L4
> +#define IWM_PH2H5
> +#define IWM_PH3L6
> +#define IWM_PH3H7
> +#define IWM_MTROFF  8
> +#define IWM_MTRON   9
> +#define IWM_INTDRIVE10
> +#define IWM_EXTDRIVE11
> +#define IWM_Q6L 12
> +#define IWM_Q6H 13
> +#define IWM_Q7L 14
> +#define IWM_Q7H 15
> +
> +/* SWIM registers */
> +
> +#define SWIM_WRITE_DATA 0
> +#define SWIM_WRITE_MARK 1
> +#define SWIM_WRITE_CRC  2
> +#define SWIM_WRITE_PARAMETER3
> +#define SWIM_WRITE_PHASE4
> +#define SWIM_WRITE_SETUP5
> +#define SWIM_WRITE_MODE06
> +#define SWIM_WRITE_MODE17
> +
> +#define SWIM_READ_DATA  8
> +#define SWIM_READ_MARK  9
> +#define SWIM_READ_ERROR 10
> +#define SWIM_READ_PARAMETER 11
> +#define SWIM_READ_PHASE 12
> +#define SWIM_READ_SETUP 13
> +#define SWIM_READ_STATUS14
> +#define SWIM_READ_HANDSHAKE 15
> +
> +#define REG_SHIFT   9
> +
> +#define SWIM_MODE_IWM  0
> +#define SWIM_MODE_SWIM 1
> +
> +/* bits in phase register */
> +
> +#define SWIM_SEEK_NEGATIVE   0x074
> +#define SWIM_STEP0x071
> +#define SWIM_MOTOR_ON0x072
> +#define SWIM_MOTOR_OFF   0x076
> +#define SWIM_INDEX   0x073
> +#define SWIM_EJECT   0x077
> +#define SWIM_SETMFM  0x171
> +#define SWIM_SETGCR  0x175
> +#define SWIM_RELAX   0x033
> +#define SWIM_LSTRB   0x008
> +#define SWIM_CA_MASK 0x077
> +
> +/* Select values for swim_select and swim_readbit */
> +
> +#define SWIM_READ_DATA_0 0x074
> +#define SWIM_TWOMEG_DRIVE0x075
> +#define SWIM_SINGLE_SIDED0x076
> +#define SWIM_DRIVE_PRESENT   0x077
> +#define SWIM_DISK_IN 0x170
> +#define SWIM_WRITE_PROT  0x171
> +#define SWIM_TRACK_ZERO  0x172
> +#define SWIM_TACHO   0x173
> +#define SWIM_READ_DATA_1 0x174
> +#define SWIM_MFM_MODE0x175
> +#define SWIM_SEEK_COMPLETE   0x176
> +#define SWIM_ONEMEG_MEDIA0x177
> +
> +/* Bits in handshake register */
> +
> +#define SWIM_MARK_BYTE   0x01
> +#define SWIM_CRC_ZERO0x02
> +#define SWIM_RDDATA  0x04
> +#define SWIM_SENSE   0x08
> +#define SWIM_MOTEN   0x10
> +#define SWIM_ERROR   0x20
> +#define SWIM_DAT2BYTE0x40
> +#define SWIM_DAT1BYTE0x80
> +
> +/* bit

Re: [Qemu-devel] [qemu-s390x] [PATCH v3 3/5] s390: vfio_pci: Use a PCI Group structure

2019-09-09 Thread Matthew Rosato
On 9/9/19 1:18 AM, Thomas Huth wrote:
> On 07/09/2019 02.16, Matthew Rosato wrote:
>> From: Pierre Morel 
>>
>> We use a S390PCIGroup structure to hold the information
>> related to zPCI Function group.
>>
>> This allows us to be ready to support multiple groups and to retrieve
>> the group information from the host.
>>
>> Signed-off-by: Pierre Morel 
>> ---
>>  hw/s390x/s390-pci-bus.c  | 42 ++
>>  hw/s390x/s390-pci-bus.h  | 11 ++-
>>  hw/s390x/s390-pci-inst.c | 22 +-
>>  3 files changed, 65 insertions(+), 10 deletions(-)
>>
>> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
>> index 963a41c..e625217 100644
>> --- a/hw/s390x/s390-pci-bus.c
>> +++ b/hw/s390x/s390-pci-bus.c
>> @@ -730,6 +730,46 @@ static void s390_pci_iommu_free(S390pciState *s, PCIBus 
>> *bus, int32_t devfn)
>>  object_unref(OBJECT(iommu));
>>  }
>>  
>> +static S390PCIGroup *s390_grp_create(int ug)
>> +{
>> +S390PCIGroup *grp;
>> +S390pciState *s = s390_get_phb();
>> +
>> +grp = g_new0(S390PCIGroup, 1);
>> +grp->ug = ug;
>> +QTAILQ_INSERT_TAIL(&s->zpci_grps, grp, link);
>> +return grp;
>> +}
> 
> Maybe an ignorant question, but shouldn't there also be some kind of
> clean up function that also frees the memory again, e.g. during a
> machine reset? Or are these groups supposed to survive a machine reset?

Hmm..  Well, I think it is in line with the way the devices themselves
are handled during reset (they are not removed during a reset unless
there was a pending unplug and their info persists).  But you have a
point in that it seems sketchy to leave the group information around,
particularly in cases where the last device associated with the group
has been unplugged.

So yes, I think there is some work to be done here.  I need to
investigate whether a precautionary wiping of the list (minus the
default group) at machine reset is really good enough or whether we need
to remove group info sooner (device unplug).

Thanks,
Matt



Re: [Qemu-devel] [PATCH v9 8/9] hw/m68k: add a dummy SWIM floppy controller

2019-09-09 Thread Peter Maydell
On Mon, 9 Sep 2019 at 17:18, Dr. David Alan Gilbert  wrote:
>
> * Peter Maydell (peter.mayd...@linaro.org) wrote:
> > Missing reset and VMState for migration. These should be
> > baseline requirements for adding new device models to the
> > tree, because in an ideal world every device would support
> > both -- we should be gradually fixing the existing devices
> > which are missing these, and not letting new devices in,
> > so the situation gets gradually better, not worse.
>
> I'm happy to see things marked unmigratable instead for obscure
> devices; I don't see the need to worry about migration for stuff
> that's not going to be migrated.

VM snapshot save/restore is a useful debug tool. But yes,
"mark as nonmigratable explicitly" is OK too -- at least
that way if the user tries it they get a clear error message,
and we can later on look through to find what devices
are missing the capability. (Personally I find it's just
as easy to just implement the vmstate struct, though.)

thanks
-- PMM



Re: [Qemu-devel] [PATCH v8 21/32] riscv: sifive: Implement PRCI model for FU540

2019-09-09 Thread Palmer Dabbelt

On Fri, 06 Sep 2019 09:20:08 PDT (-0700), bmeng...@gmail.com wrote:

This adds a simple PRCI model for FU540 (sifive_u). It has different
register layout from the existing PRCI model for FE310 (sifive_e).

Signed-off-by: Bin Meng 
Reviewed-by: Alistair Francis 

---

Changes in v8: None
Changes in v7: None
Changes in v6:
- fix incorrectly indented comment lines
- remove unneeded brackets around assignment

Changes in v5:
- change to use defines instead of enums
- change to use qemu_log_mask(LOG_GUEST_ERROR,...) in sifive_u_prci
- creating a 32-bit val variable and using that instead of casting
  everywhere in sifive_u_prci_write()
- move all register initialization to sifive_u_prci_reset() function
- drop sifive_u_prci_create()
- s/codes that worked/code that works/g

Changes in v4:
- prefix all macros/variables/functions with SIFIVE_U/sifive_u
  in the sifive_u_prci driver

Changes in v3: None
Changes in v2: None

 hw/riscv/Makefile.objs   |   1 +
 hw/riscv/sifive_u_prci.c | 169 +++
 include/hw/riscv/sifive_u_prci.h |  81 +++
 3 files changed, 251 insertions(+)
 create mode 100644 hw/riscv/sifive_u_prci.c
 create mode 100644 include/hw/riscv/sifive_u_prci.h

diff --git a/hw/riscv/Makefile.objs b/hw/riscv/Makefile.objs
index c859697..b95bbd5 100644
--- a/hw/riscv/Makefile.objs
+++ b/hw/riscv/Makefile.objs
@@ -8,6 +8,7 @@ obj-$(CONFIG_SIFIVE) += sifive_gpio.o
 obj-$(CONFIG_SIFIVE) += sifive_plic.o
 obj-$(CONFIG_SIFIVE) += sifive_test.o
 obj-$(CONFIG_SIFIVE_U) += sifive_u.o
+obj-$(CONFIG_SIFIVE_U) += sifive_u_prci.o
 obj-$(CONFIG_SIFIVE) += sifive_uart.o
 obj-$(CONFIG_SPIKE) += spike.o
 obj-$(CONFIG_RISCV_VIRT) += virt.o
diff --git a/hw/riscv/sifive_u_prci.c b/hw/riscv/sifive_u_prci.c
new file mode 100644
index 000..4fa590c
--- /dev/null
+++ b/hw/riscv/sifive_u_prci.c
@@ -0,0 +1,169 @@
+/*
+ * QEMU SiFive U PRCI (Power, Reset, Clock, Interrupt)
+ *
+ * Copyright (c) 2019 Bin Meng 
+ *
+ * Simple model of the PRCI to emulate register reads made by the SDK BSP
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2 or later, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include "qemu/osdep.h"
+#include "hw/sysbus.h"
+#include "qemu/log.h"
+#include "qemu/module.h"
+#include "hw/riscv/sifive_u_prci.h"
+
+static uint64_t sifive_u_prci_read(void *opaque, hwaddr addr, unsigned int 
size)
+{
+SiFiveUPRCIState *s = opaque;
+
+switch (addr) {
+case SIFIVE_U_PRCI_HFXOSCCFG:
+return s->hfxosccfg;
+case SIFIVE_U_PRCI_COREPLLCFG0:
+return s->corepllcfg0;
+case SIFIVE_U_PRCI_DDRPLLCFG0:
+return s->ddrpllcfg0;
+case SIFIVE_U_PRCI_DDRPLLCFG1:
+return s->ddrpllcfg1;
+case SIFIVE_U_PRCI_GEMGXLPLLCFG0:
+return s->gemgxlpllcfg0;
+case SIFIVE_U_PRCI_GEMGXLPLLCFG1:
+return s->gemgxlpllcfg1;
+case SIFIVE_U_PRCI_CORECLKSEL:
+return s->coreclksel;
+case SIFIVE_U_PRCI_DEVICESRESET:
+return s->devicesreset;
+case SIFIVE_U_PRCI_CLKMUXSTATUS:
+return s->clkmuxstatus;
+}
+
+qemu_log_mask(LOG_GUEST_ERROR, "%s: read: addr=0x%" HWADDR_PRIx "\n",
+  __func__, addr);
+
+return 0;
+}
+
+static void sifive_u_prci_write(void *opaque, hwaddr addr,
+uint64_t val64, unsigned int size)
+{
+SiFiveUPRCIState *s = opaque;
+uint32_t val32 = (uint32_t)val64;
+
+switch (addr) {
+case SIFIVE_U_PRCI_HFXOSCCFG:
+s->hfxosccfg = val32;
+/* OSC stays ready */
+s->hfxosccfg |= SIFIVE_U_PRCI_HFXOSCCFG_RDY;
+break;
+case SIFIVE_U_PRCI_COREPLLCFG0:
+s->corepllcfg0 = val32;
+/* internal feedback */
+s->corepllcfg0 |= SIFIVE_U_PRCI_PLLCFG0_FSE;
+/* PLL stays locked */
+s->corepllcfg0 |= SIFIVE_U_PRCI_PLLCFG0_LOCK;
+break;
+case SIFIVE_U_PRCI_DDRPLLCFG0:
+s->ddrpllcfg0 = val32;
+/* internal feedback */
+s->ddrpllcfg0 |= SIFIVE_U_PRCI_PLLCFG0_FSE;
+/* PLL stays locked */
+s->ddrpllcfg0 |= SIFIVE_U_PRCI_PLLCFG0_LOCK;
+break;
+case SIFIVE_U_PRCI_DDRPLLCFG1:
+s->ddrpllcfg1 = val32;
+break;
+case SIFIVE_U_PRCI_GEMGXLPLLCFG0:
+s->gemgxlpllcfg0 = val32;
+/* internal feedback */
+s->gemgxlpllcfg0 |= SIFIVE_U_PRCI_PLLCFG0_FSE;
+/* PLL stays locked */
+s->gemgxlpllcfg0 |= SIFIVE_U_PRCI_PLLCFG0_LOCK;
+break;
+ 

Re: [Qemu-devel] [PATCH v8 01/32] riscv: hw: Remove duplicated "hw/hw.h" inclusion

2019-09-09 Thread Palmer Dabbelt

On Fri, 06 Sep 2019 09:19:48 PDT (-0700), bmeng...@gmail.com wrote:

Commit a27bd6c779ba ("Include hw/qdev-properties.h less") wrongly
added "hw/hw.h" to sifive_prci.c and sifive_test.c.

Another inclusion of "hw/hw.h" was later added via
commit 650d103d3ea9 ("Include hw/hw.h exactly where needed"), that
resulted in duplicated inclusion of "hw/hw.h".

Fixes: a27bd6c779ba ("Include hw/qdev-properties.h less")
Signed-off-by: Bin Meng 

---

Changes in v8:
- newly included in v8 to ease patch inter dependencies

 hw/riscv/sifive_prci.c | 1 -
 hw/riscv/sifive_test.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/hw/riscv/sifive_prci.c b/hw/riscv/sifive_prci.c
index 9837b61..562bc3d 100644
--- a/hw/riscv/sifive_prci.c
+++ b/hw/riscv/sifive_prci.c
@@ -19,7 +19,6 @@
  */

 #include "qemu/osdep.h"
-#include "hw/hw.h"
 #include "hw/sysbus.h"
 #include "qemu/module.h"
 #include "target/riscv/cpu.h"
diff --git a/hw/riscv/sifive_test.c b/hw/riscv/sifive_test.c
index afbb3aa..3a14f9f 100644
--- a/hw/riscv/sifive_test.c
+++ b/hw/riscv/sifive_test.c
@@ -19,7 +19,6 @@
  */

 #include "qemu/osdep.h"
-#include "hw/hw.h"
 #include "hw/sysbus.h"
 #include "qemu/module.h"
 #include "target/riscv/cpu.h"


Revieweb-by: Palmer Dabbelt 



Re: [Qemu-devel] [PATCH v9 8/9] hw/m68k: add a dummy SWIM floppy controller

2019-09-09 Thread Dr. David Alan Gilbert
* Peter Maydell (peter.mayd...@linaro.org) wrote:
> On Mon, 9 Sep 2019 at 17:05, Laurent Vivier  wrote:
> >
> > Co-developed-by: Mark Cave-Ayland 
> > Signed-off-by: Mark Cave-Ayland 
> > Signed-off-by: Laurent Vivier 
> > Reviewed-by: Hervé Poussineau 
> 
> > +static void sysbus_swim_class_init(ObjectClass *oc, void *data)
> > +{
> > +DeviceClass *dc = DEVICE_CLASS(oc);
> > +
> > +dc->realize = sysbus_swim_realize;
> > +}
> 
> Missing reset and VMState for migration. These should be
> baseline requirements for adding new device models to the
> tree, because in an ideal world every device would support
> both -- we should be gradually fixing the existing devices
> which are missing these, and not letting new devices in,
> so the situation gets gradually better, not worse.

I'm happy to see things marked unmigratable instead for obscure
devices; I don't see the need to worry about migration for stuff
that's not going to be migrated.

Dave

> thanks
> -- PMM
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK



Re: [Qemu-devel] [RFC] docs: vhost-user: add in-band kick/call messages

2019-09-09 Thread Stefan Hajnoczi
On Thu, Sep 05, 2019 at 10:28:33PM +0200, Johannes Berg wrote:
>  
> > +``VHOST_USER_VQ_CALL``
> > +  :id: 34
> > +  :equivalent ioctl: N/A
> > +  :slave payload: vring state description
> > +  :master payload: N/A
> 
> Oops. This message should be called VHOST_USER_VRING_KICK.
> 
> This file doesn't take about virtqueues, just vrings, and I inverted the
> call/kick.
> 
> [...]
>  
> > +``VHOST_USER_VQ_KICK``
> > +  :id: 4
> > +  :equivalent ioctl: N/A
> > +  :slave payload: vring state description
> > +  :master payload: N/A
> 
> Similarly, that should be called VHOST_USER_SLAVE_VRING_CALL.
> 
> Anyway, some comments would be appreciated. I'm working on an
> implementation now for my simulation environment, and I guess I can keep
> that private etc. but if there's interest I can submit an (optional)
> implementation of this for libvhost-user too, I think.

Is this really necessary?  Can the simulation interpose between the
call/kick eventfds in order to control when events happen?

  CPU --cpu_kickfd--> Simulation --vhost_kickfd--> vhost-user device

and:

  vhost-user device --vhost_callfd--> Simulation -->cpu_callfd-> CPU

The simluation controls when the CPU's kick is seen by the device and
also when the call is seen by the CPU.

I don't understand why new vhost-user protocol messages are required.

Stefan


signature.asc
Description: PGP signature


Re: [Qemu-devel] [PATCH v6 04/42] block: Add child access functions

2019-09-09 Thread Kevin Wolf
Am 09.09.2019 um 16:04 hat Max Reitz geschrieben:
> On 09.09.19 11:36, Kevin Wolf wrote:
> > Am 09.09.2019 um 09:56 hat Max Reitz geschrieben:
> >> On 04.09.19 18:16, Kevin Wolf wrote:
> >>> Am 09.08.2019 um 18:13 hat Max Reitz geschrieben:
>  There are BDS children that the general block layer code can access,
>  namely bs->file and bs->backing.  Since the introduction of filters and
>  external data files, their meaning is not quite clear.  bs->backing can
>  be a COW source, or it can be an R/W-filtered child; bs->file can be an
>  R/W-filtered child, it can be data and metadata storage, or it can be
>  just metadata storage.
> 
>  This overloading really is not helpful.  This patch adds function that
>  retrieve the correct child for each exact purpose.  Later patches in
>  this series will make use of them.  Doing so will allow us to handle
>  filter nodes and external data files in a meaningful way.
> 
>  Signed-off-by: Max Reitz 
>  Reviewed-by: Vladimir Sementsov-Ogievskiy 
> >>>
> >>> Each time I look at this patch, I'm confused by the function names.
> >>> Maybe I should just ask what the idea there was, or more specifically:
> >>> What does the "filtered" in "filtered child" really mean?
> >>>
> >>> Apparently any child of a filter node is "filtered" (which makes sense),
> >>
> >> It isn’t, filters can have non-filter children.  For example, backup-top
> >> could have the source as a filtered child and the target as a non-filter
> >> child.
> > 
> > Hm, okay, makes sense. I had a definition in mind that says that filter
> > nodes only have a single child node. Is it that a filter may have only a
> > single _filtered_ child node?
> 
> Well, there’s Quorum...

Ah, nice, quorum sets is_filter = true even though it neither fulfulls
the conditions for it before this series, nor the changed conditions
after this series.

So either quorum lies and isn't actually a filter driver, or our
definition in the documentation of is_filter is wrong.

> >>> but also bs->backing of a qcow2 image, while bs->file of qcow2 isn't.
> >>> raw doesn't have any "filtered" child. What's the system behind this?
> >>
> >> “filtered” means: If the parent node returns data from this child, it
> >> won’t modify it, neither its content nor its position.  COW and R/W
> >> filters differ in how they handle writes; R/W filters pass them through
> >> to the filtered child, COW filters copy them off to some other child
> >> node (and then the filtered child’s data will no longer be visible at
> >> that location).
> > 
> > But there is no reason why a node couldn't fulfill this condition for
> > more than one child node. bdrv_filtered_child() isn't well-defined then.
> > Technically, the description "Return any filtered child" is correct
> > because "any" can be interpreted as "an arbitrary", but obviously that
> > makes the function useless.
> 
> Which is why it currently returns NULL for Quorum.

Which is about the only possible choice that breaks the contract...

 * Return any filtered child, independently of how it reacts to write
 * accesses and whether data is copied onto this BDS through COR.

Maybe the documentation of bdrv_filtered_child() needs to be rephrased?

Going back to qcow2, it's really not much different as it has multiple
(two) filtered children, too. So if quorum returns NULL to mean "no
unambiguous result", why does it return bs->backing instead of NULL for
a qcow2 node?

(Yes, I know, because it's useful. But I'm trying to get some basic
consistency into these interfaces.)

> > Specficially, according to your definition, qcow2 filters both the
> > backing file (COW filter) and the external data file (R/W filter).
> 
> Not wrong.  But the same question as for raw arises: Is there any use to
> declaring qcow2 an R/W filter driver just because it fits the definition?

Wait, where is there even a place where this could be declared?

The once thing I see that a driver even can declare is drv->is_filter,
which is about the whole driver and not about nodes. It is false for
qcow2.

Then you made some criteria above that tell us whether a specific child
of a node is a filtered child or not. As it happens, qcow2 (which is not
a filter driver) can have two children that match the criteria for being
filtered children.

I already think this is a bit inconsistent, because why should a driver
that declares itself a non-filter be considered to filter children?
Okay, you say a broader definition of a filtered child is useful because
you can then include all BdrvChild links in a backing/filter chain. Fair
enough, it's not intuitive, but use a broader definition then.

But the point where you say that even though two of the children
are filtered children under your broader definition, for the purpose of
the API only one of them should be considered because the other one
isn't that useful, that's really one inconsistency too much for me. You
can't use a broad definition and th

Re: [Qemu-devel] [PATCH v9 8/9] hw/m68k: add a dummy SWIM floppy controller

2019-09-09 Thread Peter Maydell
On Mon, 9 Sep 2019 at 17:05, Laurent Vivier  wrote:
>
> Co-developed-by: Mark Cave-Ayland 
> Signed-off-by: Mark Cave-Ayland 
> Signed-off-by: Laurent Vivier 
> Reviewed-by: Hervé Poussineau 

> +static void sysbus_swim_class_init(ObjectClass *oc, void *data)
> +{
> +DeviceClass *dc = DEVICE_CLASS(oc);
> +
> +dc->realize = sysbus_swim_realize;
> +}

Missing reset and VMState for migration. These should be
baseline requirements for adding new device models to the
tree, because in an ideal world every device would support
both -- we should be gradually fixing the existing devices
which are missing these, and not letting new devices in,
so the situation gets gradually better, not worse.

thanks
-- PMM



[Qemu-devel] [PATCH v9 3/9] hw/m68k: add via support

2019-09-09 Thread Laurent Vivier
Co-developed-by: Mark Cave-Ayland 
Signed-off-by: Mark Cave-Ayland 
Signed-off-by: Laurent Vivier 
Reviewed-by: Hervé Poussineau 
---
 hw/misc/Kconfig   |   4 +
 hw/misc/Makefile.objs |   1 +
 hw/misc/mac_via.c | 692 ++
 include/hw/misc/mac_via.h | 107 ++
 4 files changed, 804 insertions(+)
 create mode 100644 hw/misc/mac_via.c
 create mode 100644 include/hw/misc/mac_via.h

diff --git a/hw/misc/Kconfig b/hw/misc/Kconfig
index 51754bb47c..18a5dc9c09 100644
--- a/hw/misc/Kconfig
+++ b/hw/misc/Kconfig
@@ -120,4 +120,8 @@ config AUX
 config UNIMP
 bool
 
+config MAC_VIA
+bool
+select MOS6522
+
 source macio/Kconfig
diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
index e4aad707fb..c4836dd5c3 100644
--- a/hw/misc/Makefile.objs
+++ b/hw/misc/Makefile.objs
@@ -76,6 +76,7 @@ obj-$(CONFIG_PVPANIC) += pvpanic.o
 obj-$(CONFIG_AUX) += auxbus.o
 obj-$(CONFIG_ASPEED_SOC) += aspeed_xdma.o
 obj-$(CONFIG_ASPEED_SOC) += aspeed_scu.o aspeed_sdmc.o
+obj-$(CONFIG_MAC_VIA) += mac_via.o
 obj-$(CONFIG_MSF2) += msf2-sysreg.o
 obj-$(CONFIG_NRF51_SOC) += nrf51_rng.o
 
diff --git a/hw/misc/mac_via.c b/hw/misc/mac_via.c
new file mode 100644
index 00..64914b806e
--- /dev/null
+++ b/hw/misc/mac_via.c
@@ -0,0 +1,692 @@
+/*
+ * QEMU m68k Macintosh VIA device support
+ *
+ * Copyright (c) 2011-2018 Laurent Vivier
+ * Copyright (c) 2018 Mark Cave-Ayland
+ *
+ * Some parts from hw/misc/macio/cuda.c
+ *
+ * Copyright (c) 2004-2007 Fabrice Bellard
+ * Copyright (c) 2007 Jocelyn Mayer
+ *
+ * some parts from linux-2.6.29, arch/m68k/include/asm/mac_via.h
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+#include "hw/sysbus.h"
+#include "hw/irq.h"
+#include "qemu/timer.h"
+#include "hw/misc/mac_via.h"
+#include "hw/misc/mos6522.h"
+#include "hw/input/adb.h"
+#include "sysemu/runstate.h"
+#include "qapi/error.h"
+#include "qemu/cutils.h"
+
+
+/*
+ * VIAs: There are two in every machine,
+ */
+
+#define VIA_SIZE (0x2000)
+
+/*
+ * Not all of these are true post MacII I think.
+ * CSA: probably the ones CHRP marks as 'unused' change purposes
+ * when the IWM becomes the SWIM.
+ * http://www.rs6000.ibm.com/resource/technology/chrpio/via5.mak.html
+ * ftp://ftp.austin.ibm.com/pub/technology/spec/chrp/inwork/CHRP_IORef_1.0.pdf
+ *
+ * also, http://developer.apple.com/technotes/hw/hw_09.html claims the
+ * following changes for IIfx:
+ * VIA1A_vSccWrReq not available and that VIA1A_vSync has moved to an IOP.
+ * Also, "All of the functionality of VIA2 has been moved to other chips".
+ */
+
+#define VIA1A_vSccWrReq 0x80   /*
+* SCC write. (input)
+* [CHRP] SCC WREQ: Reflects the state of the
+* Wait/Request pins from the SCC.
+* [Macintosh Family Hardware]
+* as CHRP on SE/30,II,IIx,IIcx,IIci.
+* on IIfx, "0 means an active request"
+*/
+#define VIA1A_vRev8 0x40   /*
+* Revision 8 board ???
+* [CHRP] En WaitReqB: Lets the WaitReq_L
+* signal from port B of the SCC appear on
+* the PA7 input pin. Output.
+* [Macintosh Family] On the SE/30, this
+* is the bit to flip screen buffers.
+* 0=alternate, 1=main.
+* on II,IIx,IIcx,IIci,IIfx this is a bit
+* for Rev ID. 0=II,IIx, 1=IIcx,IIci,IIfx
+*/
+#define VIA1A_vHeadSel  0x20   /*
+* Head select for IWM.
+* [CHRP] unused.
+* [Macintosh Family] "Floppy disk
+* state-control line SEL" on all but IIfx
+*/
+#define VIA1A_vOverlay  0x10   /*
+* [Macintosh Family] On SE/30,II,IIx,IIcx
+* this bit enables the "Overlay" address
+* map in the address decoders as it is on
+* reset for mapping the ROM over the reset
+* vector. 1=use overlay map.
+* On the IIci,IIfx it is another bit of the
+* CPU ID: 0=normal IIci, 1=IIci with parity
+* feature or IIfx.
+* [CHRP] En WaitReqA: Lets the WaitReq_L
+* signal from port A of the SCC appear
+* on the PA7 inpu

[Qemu-devel] [PATCH v9 9/9] hw/m68k: define Macintosh Quadra 800

2019-09-09 Thread Laurent Vivier
If you want to test the machine, it doesn't yet boot a MacROM, but you can
boot a linux kernel from the command line.

You can install your own disk using debian-installer with:

./qemu-system-m68k \
-M q800 \
-serial none -serial mon:stdio \
-m 1000M -drive file=m68k.qcow2,format=qcow2 \
-net nic,model=dp83932,addr=09:00:07:12:34:57 \
-append "console=ttyS0 vga=off" \
-kernel vmlinux-4.15.0-2-m68k \
-initrd initrd.gz \
-drive file=debian-9.0-m68k-NETINST-1.iso \
-drive file=m68k.qcow2,format=qcow2 \
-nographic

If you use a graphic adapter instead of "-nographic", you can use "-g" to set 
the
size of the display (I use "-g 1600x800x24").

Co-developed-by: Mark Cave-Ayland 
Signed-off-by: Mark Cave-Ayland 
Signed-off-by: Laurent Vivier 
---
 MAINTAINERS  |  14 ++
 default-configs/m68k-softmmu.mak |   1 +
 hw/m68k/Kconfig  |  12 +
 hw/m68k/Makefile.objs|   1 +
 hw/m68k/bootinfo.h   | 114 +
 hw/m68k/q800.c   | 382 +++
 6 files changed, 524 insertions(+)
 create mode 100644 hw/m68k/bootinfo.h
 create mode 100644 hw/m68k/q800.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 50eaf005f4..3c71dbb3a3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -917,6 +917,20 @@ F: hw/m68k/next-*.c
 F: hw/display/next-fb.c
 F: include/hw/m68k/next-cube.h
 
+q800
+M: Laurent Vivier 
+S: Maintained
+F: hw/block/swim.c
+F: hw/m68k/bootinfo.h
+F: hw/display/macfb.c
+F: hw/m68k/q800.c
+F: hw/misc/mac_via.c
+F: hw/nubus/*
+F: include/hw/block/swim.h
+F: include/hw/display/macfb.h
+F: include/hw/misc/mac_via.h
+F: include/hw/nubus/*
+
 MicroBlaze Machines
 ---
 petalogix_s3adsp1800
diff --git a/default-configs/m68k-softmmu.mak b/default-configs/m68k-softmmu.mak
index d67ab8b96d..6629fd2aa3 100644
--- a/default-configs/m68k-softmmu.mak
+++ b/default-configs/m68k-softmmu.mak
@@ -7,3 +7,4 @@ CONFIG_SEMIHOSTING=y
 CONFIG_AN5206=y
 CONFIG_MCF5208=y
 CONFIG_NEXTCUBE=y
+CONFIG_Q800=y
diff --git a/hw/m68k/Kconfig b/hw/m68k/Kconfig
index a74fac5abd..f782210b92 100644
--- a/hw/m68k/Kconfig
+++ b/hw/m68k/Kconfig
@@ -12,3 +12,15 @@ config NEXTCUBE
 bool
 select FRAMEBUFFER
 select ESCC
+
+config Q800
+bool
+select FRAMEBUFFER
+select ADB
+select MAC_VIA
+select ESCC
+select ESP
+select MACFB
+select NUBUS
+select DP8393X
+select SWIM
diff --git a/hw/m68k/Makefile.objs b/hw/m68k/Makefile.objs
index f25854730d..b2c9e5ab12 100644
--- a/hw/m68k/Makefile.objs
+++ b/hw/m68k/Makefile.objs
@@ -1,3 +1,4 @@
 obj-$(CONFIG_AN5206) += an5206.o mcf5206.o
 obj-$(CONFIG_MCF5208) += mcf5208.o mcf_intc.o
 obj-$(CONFIG_NEXTCUBE) += next-kbd.o next-cube.o
+obj-$(CONFIG_Q800) += q800.o
diff --git a/hw/m68k/bootinfo.h b/hw/m68k/bootinfo.h
new file mode 100644
index 00..5f8ded2686
--- /dev/null
+++ b/hw/m68k/bootinfo.h
@@ -0,0 +1,114 @@
+/*
+ * SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
+ *
+ * Bootinfo tags from linux bootinfo.h and bootinfo-mac.h:
+ * This is an easily parsable and extendable structure containing all
+ * information to be passed from the bootstrap to the kernel
+ *
+ * This structure is copied right after the kernel by the bootstrap
+ * routine.
+ */
+
+#ifndef HW_M68K_BOOTINFO_H
+#define HW_M68K_BOOTINFO_H
+struct bi_record {
+uint16_t tag;/* tag ID */
+uint16_t size;   /* size of record */
+uint32_t data[0];/* data */
+};
+
+/* machine independent tags */
+
+#define BI_LAST 0x /* last record */
+#define BI_MACHTYPE 0x0001 /* machine type (u_long) */
+#define BI_CPUTYPE  0x0002 /* cpu type (u_long) */
+#define BI_FPUTYPE  0x0003 /* fpu type (u_long) */
+#define BI_MMUTYPE  0x0004 /* mmu type (u_long) */
+#define BI_MEMCHUNK 0x0005 /* memory chunk address and size */
+   /* (struct mem_info) */
+#define BI_RAMDISK  0x0006 /* ramdisk address and size */
+   /* (struct mem_info) */
+#define BI_COMMAND_LINE 0x0007 /* kernel command line parameters */
+   /* (string) */
+
+/*  Macintosh-specific tags (all u_long) */
+
+#define BI_MAC_MODEL0x8000  /* Mac Gestalt ID (model type) */
+#define BI_MAC_VADDR0x8001  /* Mac video base address */
+#define BI_MAC_VDEPTH   0x8002  /* Mac video depth */
+#define BI_MAC_VROW 0x8003  /* Mac video rowbytes */
+#define BI_MAC_VDIM 0x8004  /* Mac video dimensions */
+#define BI_MAC_VLOGICAL 0x8005  /* Mac video logical base */
+#define BI_MAC_SCCBASE  0x8006  /* Mac SCC base address */
+#define BI_MAC_BTIME0x8007  /* Mac boot time */
+#define BI_MAC_GMTBIAS  0x8008  /* Mac GMT timezone offset */
+#define BI_MAC_MEMSIZE  0x8009  /* Mac RAM size (sanity check) */
+#define BI_MAC_CPUID0x800a  /* Mac CPU type (sanity check) */
+#define BI_MAC_ROMBASE  0x800b  /* Mac system ROM base address */
+
+/*  Macintosh hardware 

[Qemu-devel] [PATCH v9 6/9] hw/m68k: add Nubus support

2019-09-09 Thread Laurent Vivier
Co-developed-by: Mark Cave-Ayland 
Signed-off-by: Mark Cave-Ayland 
Signed-off-by: Laurent Vivier 
Reviewed-by: Thomas Huth 
---
 hw/Kconfig  |   1 +
 hw/Makefile.objs|   1 +
 hw/nubus/Kconfig|   2 +
 hw/nubus/Makefile.objs  |   4 +
 hw/nubus/mac-nubus-bridge.c |  45 ++
 hw/nubus/nubus-bridge.c |  34 +
 hw/nubus/nubus-bus.c| 111 ++
 hw/nubus/nubus-device.c | 215 
 include/hw/nubus/mac-nubus-bridge.h |  24 
 include/hw/nubus/nubus.h|  69 +
 10 files changed, 506 insertions(+)
 create mode 100644 hw/nubus/Kconfig
 create mode 100644 hw/nubus/Makefile.objs
 create mode 100644 hw/nubus/mac-nubus-bridge.c
 create mode 100644 hw/nubus/nubus-bridge.c
 create mode 100644 hw/nubus/nubus-bus.c
 create mode 100644 hw/nubus/nubus-device.c
 create mode 100644 include/hw/nubus/mac-nubus-bridge.h
 create mode 100644 include/hw/nubus/nubus.h

diff --git a/hw/Kconfig b/hw/Kconfig
index b45db3c813..0501a55315 100644
--- a/hw/Kconfig
+++ b/hw/Kconfig
@@ -21,6 +21,7 @@ source isa/Kconfig
 source mem/Kconfig
 source misc/Kconfig
 source net/Kconfig
+source nubus/Kconfig
 source nvram/Kconfig
 source pci-bridge/Kconfig
 source pci-host/Kconfig
diff --git a/hw/Makefile.objs b/hw/Makefile.objs
index ece6cc3755..457b95e28d 100644
--- a/hw/Makefile.objs
+++ b/hw/Makefile.objs
@@ -37,6 +37,7 @@ devices-dirs-y += virtio/
 devices-dirs-y += watchdog/
 devices-dirs-y += xen/
 devices-dirs-$(CONFIG_MEM_DEVICE) += mem/
+devices-dirs-$(CONFIG_NUBUS) += nubus/
 devices-dirs-y += semihosting/
 devices-dirs-y += smbios/
 endif
diff --git a/hw/nubus/Kconfig b/hw/nubus/Kconfig
new file mode 100644
index 00..8fb8b22189
--- /dev/null
+++ b/hw/nubus/Kconfig
@@ -0,0 +1,2 @@
+config NUBUS
+bool
diff --git a/hw/nubus/Makefile.objs b/hw/nubus/Makefile.objs
new file mode 100644
index 00..135ba7878d
--- /dev/null
+++ b/hw/nubus/Makefile.objs
@@ -0,0 +1,4 @@
+common-obj-y += nubus-device.o
+common-obj-y += nubus-bus.o
+common-obj-y += nubus-bridge.o
+common-obj-$(CONFIG_Q800) += mac-nubus-bridge.o
diff --git a/hw/nubus/mac-nubus-bridge.c b/hw/nubus/mac-nubus-bridge.c
new file mode 100644
index 00..7c329300b8
--- /dev/null
+++ b/hw/nubus/mac-nubus-bridge.c
@@ -0,0 +1,45 @@
+/*
+ *  Copyright (c) 2013-2018 Laurent Vivier 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "hw/sysbus.h"
+#include "hw/nubus/mac-nubus-bridge.h"
+
+
+static void mac_nubus_bridge_init(Object *obj)
+{
+MacNubusState *s = MAC_NUBUS_BRIDGE(obj);
+SysBusDevice *sbd = SYS_BUS_DEVICE(obj);
+
+s->bus = NUBUS_BUS(qbus_create(TYPE_NUBUS_BUS, DEVICE(s), NULL));
+
+sysbus_init_mmio(sbd, &s->bus->super_slot_io);
+sysbus_init_mmio(sbd, &s->bus->slot_io);
+}
+
+static void mac_nubus_bridge_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+
+dc->desc = "Nubus bridge";
+}
+
+static const TypeInfo mac_nubus_bridge_info = {
+.name  = TYPE_MAC_NUBUS_BRIDGE,
+.parent= TYPE_NUBUS_BRIDGE,
+.instance_init = mac_nubus_bridge_init,
+.instance_size = sizeof(MacNubusState),
+.class_init= mac_nubus_bridge_class_init,
+};
+
+static void mac_nubus_bridge_register_types(void)
+{
+type_register_static(&mac_nubus_bridge_info);
+}
+
+type_init(mac_nubus_bridge_register_types)
diff --git a/hw/nubus/nubus-bridge.c b/hw/nubus/nubus-bridge.c
new file mode 100644
index 00..cd8c6a91eb
--- /dev/null
+++ b/hw/nubus/nubus-bridge.c
@@ -0,0 +1,34 @@
+/*
+ * QEMU Macintosh Nubus
+ *
+ * Copyright (c) 2013-2018 Laurent Vivier 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "hw/sysbus.h"
+#include "hw/nubus/nubus.h"
+
+static void nubus_bridge_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+
+dc->fw_name = "nubus";
+}
+
+static const TypeInfo nubus_bridge_info = {
+.name  = TYPE_NUBUS_BRIDGE,
+.parent= TYPE_SYS_BUS_DEVICE,
+.instance_size = sizeof(SysBusDevice),
+.class_init= nubus_bridge_class_init,
+};
+
+static void nubus_register_types(void)
+{
+type_register_static(&nubus_bridge_info);
+}
+
+type_init(nubus_register_types)
diff --git a/hw/nubus/nubus-bus.c b/hw/nubus/nubus-bus.c
new file mode 100644
index 00..942a6d5342
--- /dev/null
+++ b/hw/nubus/nubus-bus.c
@@ -0,0 +1,111 @@
+/*
+ * QEMU Macintosh Nubus
+ *
+ * Copyright (c) 2013-2018 Laurent Vivier 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "

[Qemu-devel] [PATCH v9 5/9] hw/m68k: add macfb video card

2019-09-09 Thread Laurent Vivier
Co-developed-by: Mark Cave-Ayland 
Signed-off-by: Mark Cave-Ayland 
Signed-off-by: Laurent Vivier 
Reviewed-by: Hervé Poussineau 
Reviewed-by: Thomas Huth 
---
 arch_init.c|   4 +
 hw/display/Kconfig |   3 +
 hw/display/Makefile.objs   |   1 +
 hw/display/macfb.c | 421 +
 include/hw/display/macfb.h |  43 
 qemu-options.hx|   2 +-
 vl.c   |   3 +-
 7 files changed, 475 insertions(+), 2 deletions(-)
 create mode 100644 hw/display/macfb.c
 create mode 100644 include/hw/display/macfb.h

diff --git a/arch_init.c b/arch_init.c
index 0a1531124c..705d0b94ad 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -38,6 +38,10 @@
 int graphic_width = 1024;
 int graphic_height = 768;
 int graphic_depth = 8;
+#elif defined(TARGET_M68K)
+int graphic_width = 800;
+int graphic_height = 600;
+int graphic_depth = 8;
 #else
 int graphic_width = 800;
 int graphic_height = 600;
diff --git a/hw/display/Kconfig b/hw/display/Kconfig
index cbdf7b1a67..867b47673c 100644
--- a/hw/display/Kconfig
+++ b/hw/display/Kconfig
@@ -132,3 +132,6 @@ config ATI_VGA
 select VGA
 select BITBANG_I2C
 select DDC
+
+config MACFB
+bool
diff --git a/hw/display/Makefile.objs b/hw/display/Makefile.objs
index 5a4066383b..f2182e3bef 100644
--- a/hw/display/Makefile.objs
+++ b/hw/display/Makefile.objs
@@ -26,6 +26,7 @@ common-obj-$(CONFIG_EXYNOS4) += exynos4210_fimd.o
 common-obj-$(CONFIG_FRAMEBUFFER) += framebuffer.o
 obj-$(CONFIG_MILKYMIST) += milkymist-vgafb.o
 common-obj-$(CONFIG_ZAURUS) += tc6393xb.o
+common-obj-$(CONFIG_MACFB) += macfb.o
 
 obj-$(CONFIG_MILKYMIST_TMU2) += milkymist-tmu2.o
 milkymist-tmu2.o-cflags := $(X11_CFLAGS) $(OPENGL_CFLAGS)
diff --git a/hw/display/macfb.c b/hw/display/macfb.c
new file mode 100644
index 00..d7c5ef296e
--- /dev/null
+++ b/hw/display/macfb.c
@@ -0,0 +1,421 @@
+/*
+ * QEMU Motorola 680x0 Macintosh Video Card Emulation
+ * Copyright (c) 2012-2018 Laurent Vivier
+ *
+ * some parts from QEMU G364 framebuffer Emulator.
+ * Copyright (c) 2007-2011 Herve Poussineau
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/units.h"
+#include "hw/sysbus.h"
+#include "ui/console.h"
+#include "ui/pixel_ops.h"
+#include "hw/display/macfb.h"
+#include "qapi/error.h"
+#include "hw/qdev-properties.h"
+#include "migration/vmstate.h"
+
+#define VIDEO_BASE 0x1000
+#define DAFB_BASE  0x0080
+
+#define MACFB_PAGE_SIZE 4096
+#define MACFB_VRAM_SIZE (4 * MiB)
+
+#define DAFB_RESET  0x200
+#define DAFB_LUT0x213
+
+
+typedef void macfb_draw_line_func(MacfbState *s, uint8_t *d, uint32_t addr,
+  int width);
+
+static inline uint8_t macfb_read_byte(MacfbState *s, uint32_t addr)
+{
+return s->vram[addr & s->vram_bit_mask];
+}
+
+/* 1-bit color */
+static void macfb_draw_line1(MacfbState *s, uint8_t *d, uint32_t addr,
+ int width)
+{
+uint8_t r, g, b;
+int x;
+
+for (x = 0; x < width; x++) {
+int bit = x & 7;
+int idx = (macfb_read_byte(s, addr) >> (7 - bit)) & 1;
+r = g = b  = ((1 - idx) << 7);
+addr += (bit == 7);
+
+*(uint32_t *)d = rgb_to_pixel32(r, g, b);
+d += 4;
+}
+}
+
+/* 2-bit color */
+static void macfb_draw_line2(MacfbState *s, uint8_t *d, uint32_t addr,
+ int width)
+{
+uint8_t r, g, b;
+int x;
+
+for (x = 0; x < width; x++) {
+int bit = (x & 3);
+int idx = (macfb_read_byte(s, addr) >> ((3 - bit) << 1)) & 3;
+r = s->color_palette[idx * 3];
+g = s->color_palette[idx * 3 + 1];
+b = s->color_palette[idx * 3 + 2];
+addr += (bit == 3);
+
+*(uint32_t *)d = rgb_to_pixel32(r, g, b);
+d += 4;
+}
+}
+
+/* 4-bit color */
+static void macfb_draw_line4(MacfbState *s, uint8_t *d, uint32_t addr,
+ int width)
+{
+uint8_t r, g, b;
+int x;
+
+for (x = 0; x < width; x++) {
+int bit = x & 1;
+int idx = (macfb_read_byte(s, addr) >> ((1 - bit) << 2)) & 15;
+r = s->color_palette[idx * 3];
+g = s->color_palette[idx * 3 + 1];
+b = s->color_palette[idx * 3 + 2];
+addr += (bit == 1);
+
+*(uint32_t *)d = rgb_to_pixel32(r, g, b);
+d += 4;
+}
+}
+
+/* 8-bit color */
+static void macfb_draw_line8(MacfbState *s, uint8_t *d, uint32_t addr,
+ int width)
+{
+uint8_t r, g, b;
+int x;
+
+for (x = 0; x < width; x++) {
+r = s->color_palette[macfb_read_byte(s, addr) * 3];
+g = s->color_palette[macfb_read_byte(s, addr) * 3 + 1];
+b = s->color_palette[macfb_read_byte(s, addr) * 3 + 2];
+addr++;
+
+*(uint32_t *)d = rgb_to_pixel32(r, g, b);
+d += 4;
+  

[Qemu-devel] [PATCH v9 1/9] esp: add pseudo-DMA as used by Macintosh

2019-09-09 Thread Laurent Vivier
There is no DMA in Quadra 800, so the CPU reads/writes the data from the
PDMA register (offset 0x100, ESP_PDMA in hw/m68k/q800.c) and copies them
to/from the memory.

There is a nice assembly loop in the kernel to do that, see
linux/drivers/scsi/mac_esp.c:MAC_ESP_PDMA_LOOP().

The start of the transfer is triggered by the DREQ interrupt (see linux
mac_esp_send_pdma_cmd()), the CPU polls on the IRQ flag to start the
transfer after a SCSI command has been sent (in Quadra 800 it goes
through the VIA2, the via2-irq line and the vIFR register)

The Macintosh hardware includes hardware handshaking to prevent the CPU
from reading invalid data or writing data faster than the peripheral
device can accept it.

This is the "blind mode", and from the doc:
"Approximate maximum SCSI transfer rates within a blocks are 1.4 MB per
second for blind transfers in the Macintosh II"

Some references can be found in:
  Apple Macintosh Family Hardware Reference, ISBN 0-201-19255-1
  Guide to the Macintosh Family Hardware, ISBN-0-201-52405-8

Co-developed-by: Mark Cave-Ayland 
Signed-off-by: Mark Cave-Ayland 
Signed-off-by: Laurent Vivier 
---
 hw/scsi/esp.c | 296 +-
 include/hw/scsi/esp.h |   7 +
 2 files changed, 274 insertions(+), 29 deletions(-)

diff --git a/hw/scsi/esp.c b/hw/scsi/esp.c
index 841d79b60e..ffbeee9f3c 100644
--- a/hw/scsi/esp.c
+++ b/hw/scsi/esp.c
@@ -38,6 +38,8 @@
  * 
http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/NCR89C100.txt
  * and
  * http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/NCR53C9X.txt
+ *
+ * On Macintosh Quadra it is a NCR53C96.
  */
 
 static void esp_raise_irq(ESPState *s)
@@ -58,6 +60,16 @@ static void esp_lower_irq(ESPState *s)
 }
 }
 
+static void esp_raise_drq(ESPState *s)
+{
+qemu_irq_raise(s->irq_data);
+}
+
+static void esp_lower_drq(ESPState *s)
+{
+qemu_irq_lower(s->irq_data);
+}
+
 void esp_dma_enable(ESPState *s, int irq, int level)
 {
 if (level) {
@@ -84,29 +96,11 @@ void esp_request_cancelled(SCSIRequest *req)
 }
 }
 
-static uint32_t get_cmd(ESPState *s, uint8_t *buf, uint8_t buflen)
+static int get_cmd_cb(ESPState *s)
 {
-uint32_t dmalen;
 int target;
 
 target = s->wregs[ESP_WBUSID] & BUSID_DID;
-if (s->dma) {
-dmalen = s->rregs[ESP_TCLO];
-dmalen |= s->rregs[ESP_TCMID] << 8;
-dmalen |= s->rregs[ESP_TCHI] << 16;
-if (dmalen > buflen) {
-return 0;
-}
-s->dma_memory_read(s->dma_opaque, buf, dmalen);
-} else {
-dmalen = s->ti_size;
-if (dmalen > TI_BUFSZ) {
-return 0;
-}
-memcpy(buf, s->ti_buf, dmalen);
-buf[0] = buf[2] >> 5;
-}
-trace_esp_get_cmd(dmalen, target);
 
 s->ti_size = 0;
 s->ti_rptr = 0;
@@ -125,8 +119,48 @@ static uint32_t get_cmd(ESPState *s, uint8_t *buf, uint8_t 
buflen)
 s->rregs[ESP_RINTR] = INTR_DC;
 s->rregs[ESP_RSEQ] = SEQ_0;
 esp_raise_irq(s);
+return -1;
+}
+return 0;
+}
+
+static uint32_t get_cmd(ESPState *s, uint8_t *buf, uint8_t buflen)
+{
+int target;
+uint32_t dmalen;
+
+target = s->wregs[ESP_WBUSID] & BUSID_DID;
+if (s->dma) {
+dmalen = s->rregs[ESP_TCLO];
+dmalen |= s->rregs[ESP_TCMID] << 8;
+dmalen |= s->rregs[ESP_TCHI] << 16;
+if (dmalen > buflen) {
+return 0;
+}
+if (s->dma_memory_read) {
+s->dma_memory_read(s->dma_opaque, buf, dmalen);
+} else {
+memcpy(s->pdma_buf, buf, dmalen);
+s->pdma_len = dmalen;
+s->pdma_start = s->pdma_buf;
+s->pdma_cur = s->pdma_buf;
+esp_raise_drq(s);
+return 0;
+}
+} else {
+dmalen = s->ti_size;
+if (dmalen > TI_BUFSZ) {
+return 0;
+}
+memcpy(buf, s->ti_buf, dmalen);
+buf[0] = buf[2] >> 5;
+}
+trace_esp_get_cmd(dmalen, target);
+
+if (get_cmd_cb(s) < 0) {
 return 0;
 }
+
 return dmalen;
 }
 
@@ -165,6 +199,16 @@ static void do_cmd(ESPState *s, uint8_t *buf)
 do_busid_cmd(s, &buf[1], busid);
 }
 
+static void satn_pdma_cb(ESPState *s)
+{
+if (get_cmd_cb(s) < 0) {
+return;
+}
+if (s->pdma_cur != s->pdma_start) {
+do_cmd(s, s->pdma_start);
+}
+}
+
 static void handle_satn(ESPState *s)
 {
 uint8_t buf[32];
@@ -174,11 +218,22 @@ static void handle_satn(ESPState *s)
 s->dma_cb = handle_satn;
 return;
 }
+s->pdma_cb = satn_pdma_cb;
 len = get_cmd(s, buf, sizeof(buf));
 if (len)
 do_cmd(s, buf);
 }
 
+static void s_without_satn_pdma_cb(ESPState *s)
+{
+if (get_cmd_cb(s) < 0) {
+return;
+}
+if (s->pdma_cur != s->pdma_start) {
+do_busid_cmd(s, s->pdma_start, 0);
+}
+}
+
 static void handle_s_without_atn(ESPState *s)
 {
 uint8_t buf[32];
@@ -188,18 +243,36 @@ static void hand

[Qemu-devel] [PATCH v9 8/9] hw/m68k: add a dummy SWIM floppy controller

2019-09-09 Thread Laurent Vivier
Co-developed-by: Mark Cave-Ayland 
Signed-off-by: Mark Cave-Ayland 
Signed-off-by: Laurent Vivier 
Reviewed-by: Hervé Poussineau 
---
 hw/block/Kconfig|   3 +
 hw/block/Makefile.objs  |   1 +
 hw/block/swim.c | 421 
 include/hw/block/swim.h |  76 
 4 files changed, 501 insertions(+)
 create mode 100644 hw/block/swim.c
 create mode 100644 include/hw/block/swim.h

diff --git a/hw/block/Kconfig b/hw/block/Kconfig
index df96dc5dcc..2d17f481ad 100644
--- a/hw/block/Kconfig
+++ b/hw/block/Kconfig
@@ -37,3 +37,6 @@ config VHOST_USER_BLK
 # Only PCI devices are provided for now
 default y if VIRTIO_PCI
 depends on VIRTIO && VHOST_USER && LINUX
+
+config SWIM
+bool
diff --git a/hw/block/Makefile.objs b/hw/block/Makefile.objs
index f5f643f0cc..28c2495a00 100644
--- a/hw/block/Makefile.objs
+++ b/hw/block/Makefile.objs
@@ -8,6 +8,7 @@ common-obj-$(CONFIG_XEN) += xen-block.o
 common-obj-$(CONFIG_ECC) += ecc.o
 common-obj-$(CONFIG_ONENAND) += onenand.o
 common-obj-$(CONFIG_NVME_PCI) += nvme.o
+common-obj-$(CONFIG_SWIM) += swim.o
 
 obj-$(CONFIG_SH4) += tc58128.o
 
diff --git a/hw/block/swim.c b/hw/block/swim.c
new file mode 100644
index 00..6e26915238
--- /dev/null
+++ b/hw/block/swim.c
@@ -0,0 +1,421 @@
+/*
+ * QEMU Macintosh floppy disk controller emulator (SWIM)
+ *
+ * Copyright (c) 2014-2018 Laurent Vivier 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/main-loop.h"
+#include "qapi/error.h"
+#include "sysemu/block-backend.h"
+#include "hw/sysbus.h"
+#include "hw/block/block.h"
+#include "hw/block/swim.h"
+#include "hw/qdev-properties.h"
+
+/* IWM registers */
+
+#define IWM_PH0L0
+#define IWM_PH0H1
+#define IWM_PH1L2
+#define IWM_PH1H3
+#define IWM_PH2L4
+#define IWM_PH2H5
+#define IWM_PH3L6
+#define IWM_PH3H7
+#define IWM_MTROFF  8
+#define IWM_MTRON   9
+#define IWM_INTDRIVE10
+#define IWM_EXTDRIVE11
+#define IWM_Q6L 12
+#define IWM_Q6H 13
+#define IWM_Q7L 14
+#define IWM_Q7H 15
+
+/* SWIM registers */
+
+#define SWIM_WRITE_DATA 0
+#define SWIM_WRITE_MARK 1
+#define SWIM_WRITE_CRC  2
+#define SWIM_WRITE_PARAMETER3
+#define SWIM_WRITE_PHASE4
+#define SWIM_WRITE_SETUP5
+#define SWIM_WRITE_MODE06
+#define SWIM_WRITE_MODE17
+
+#define SWIM_READ_DATA  8
+#define SWIM_READ_MARK  9
+#define SWIM_READ_ERROR 10
+#define SWIM_READ_PARAMETER 11
+#define SWIM_READ_PHASE 12
+#define SWIM_READ_SETUP 13
+#define SWIM_READ_STATUS14
+#define SWIM_READ_HANDSHAKE 15
+
+#define REG_SHIFT   9
+
+#define SWIM_MODE_IWM  0
+#define SWIM_MODE_SWIM 1
+
+/* bits in phase register */
+
+#define SWIM_SEEK_NEGATIVE   0x074
+#define SWIM_STEP0x071
+#define SWIM_MOTOR_ON0x072
+#define SWIM_MOTOR_OFF   0x076
+#define SWIM_INDEX   0x073
+#define SWIM_EJECT   0x077
+#define SWIM_SETMFM  0x171
+#define SWIM_SETGCR  0x175
+#define SWIM_RELAX   0x033
+#define SWIM_LSTRB   0x008
+#define SWIM_CA_MASK 0x077
+
+/* Select values for swim_select and swim_readbit */
+
+#define SWIM_READ_DATA_0 0x074
+#define SWIM_TWOMEG_DRIVE0x075
+#define SWIM_SINGLE_SIDED0x076
+#define SWIM_DRIVE_PRESENT   0x077
+#define SWIM_DISK_IN 0x170
+#define SWIM_WRITE_PROT  0x171
+#define SWIM_TRACK_ZERO  0x172
+#define SWIM_TACHO   0x173
+#define SWIM_READ_DATA_1 0x174
+#define SWIM_MFM_MODE0x175
+#define SWIM_SEEK_COMPLETE   0x176
+#define SWIM_ONEMEG_MEDIA0x177
+
+/* Bits in handshake register */
+
+#define SWIM_MARK_BYTE   0x01
+#define SWIM_CRC_ZERO0x02
+#define SWIM_RDDATA  0x04
+#define SWIM_SENSE   0x08
+#define SWIM_MOTEN   0x10
+#define SWIM_ERROR   0x20
+#define SWIM_DAT2BYTE0x40
+#define SWIM_DAT1BYTE0x80
+
+/* bits in setup register */
+
+#define SWIM_S_INV_WDATA 0x01
+#define SWIM_S_3_5_SELECT0x02
+#define SWIM_S_GCR   0x04
+#define SWIM_S_FCLK_DIV2 0x08
+#define SWIM_S_ERROR_CORR0x10
+#define SWIM_S_IBM_DRIVE 0x20
+#define SWIM_S_GCR_WRITE 0x40
+#define SWIM_S_TIMEOUT   0x80
+
+/* bits in mode register */
+
+#define SWIM_CLFIFO  0x01
+#define SWIM_ENBL1   0x02
+#define SWIM_ENBL2   0x04
+#define SWIM_ACTION  0x08
+#define SWIM_WRITE_MODE  0x10
+#define SWIM_HEDSEL  0x20
+#define SWIM_MOTON   0x80
+
+static void swim_change_cb(void *opaque, bool load, Error **errp)
+{
+FDrive *drive = opaque;
+
+if (!load)

[Qemu-devel] [PATCH v9 2/9] dp8393x: manage big endian bus

2019-09-09 Thread Laurent Vivier
This is needed by Quadra 800, this card can run on little-endian
or big-endian bus.

Signed-off-by: Laurent Vivier 
Tested-by: Hervé Poussineau 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Hervé Poussineau 
---
 hw/net/dp8393x.c | 88 +++-
 1 file changed, 57 insertions(+), 31 deletions(-)

diff --git a/hw/net/dp8393x.c b/hw/net/dp8393x.c
index a5678e11fa..693e244ce6 100644
--- a/hw/net/dp8393x.c
+++ b/hw/net/dp8393x.c
@@ -153,6 +153,7 @@ typedef struct dp8393xState {
 
 /* Hardware */
 uint8_t it_shift;
+bool big_endian;
 qemu_irq irq;
 #ifdef DEBUG_SONIC
 int irq_level;
@@ -223,6 +224,29 @@ static uint32_t dp8393x_wt(dp8393xState *s)
 return s->regs[SONIC_WT1] << 16 | s->regs[SONIC_WT0];
 }
 
+static uint16_t dp8393x_get(dp8393xState *s, int width, uint16_t *base,
+int offset)
+{
+uint16_t val;
+
+if (s->big_endian) {
+val = be16_to_cpu(base[offset * width + width - 1]);
+} else {
+val = le16_to_cpu(base[offset * width]);
+}
+return val;
+}
+
+static void dp8393x_put(dp8393xState *s, int width, uint16_t *base, int offset,
+uint16_t val)
+{
+if (s->big_endian) {
+base[offset * width + width - 1] = cpu_to_be16(val);
+} else {
+base[offset * width] = cpu_to_le16(val);
+}
+}
+
 static void dp8393x_update_irq(dp8393xState *s)
 {
 int level = (s->regs[SONIC_IMR] & s->regs[SONIC_ISR]) ? 1 : 0;
@@ -254,12 +278,12 @@ static void dp8393x_do_load_cam(dp8393xState *s)
 /* Fill current entry */
 address_space_rw(&s->as, dp8393x_cdp(s),
 MEMTXATTRS_UNSPECIFIED, (uint8_t *)data, size, 0);
-s->cam[index][0] = data[1 * width] & 0xff;
-s->cam[index][1] = data[1 * width] >> 8;
-s->cam[index][2] = data[2 * width] & 0xff;
-s->cam[index][3] = data[2 * width] >> 8;
-s->cam[index][4] = data[3 * width] & 0xff;
-s->cam[index][5] = data[3 * width] >> 8;
+s->cam[index][0] = dp8393x_get(s, width, data, 1) & 0xff;
+s->cam[index][1] = dp8393x_get(s, width, data, 1) >> 8;
+s->cam[index][2] = dp8393x_get(s, width, data, 2) & 0xff;
+s->cam[index][3] = dp8393x_get(s, width, data, 2) >> 8;
+s->cam[index][4] = dp8393x_get(s, width, data, 3) & 0xff;
+s->cam[index][5] = dp8393x_get(s, width, data, 3) >> 8;
 DPRINTF("load cam[%d] with %02x%02x%02x%02x%02x%02x\n", index,
 s->cam[index][0], s->cam[index][1], s->cam[index][2],
 s->cam[index][3], s->cam[index][4], s->cam[index][5]);
@@ -272,7 +296,7 @@ static void dp8393x_do_load_cam(dp8393xState *s)
 /* Read CAM enable */
 address_space_rw(&s->as, dp8393x_cdp(s),
 MEMTXATTRS_UNSPECIFIED, (uint8_t *)data, size, 0);
-s->regs[SONIC_CE] = data[0 * width];
+s->regs[SONIC_CE] = dp8393x_get(s, width, data, 0);
 DPRINTF("load cam done. cam enable mask 0x%04x\n", s->regs[SONIC_CE]);
 
 /* Done */
@@ -293,10 +317,10 @@ static void dp8393x_do_read_rra(dp8393xState *s)
 MEMTXATTRS_UNSPECIFIED, (uint8_t *)data, size, 0);
 
 /* Update SONIC registers */
-s->regs[SONIC_CRBA0] = data[0 * width];
-s->regs[SONIC_CRBA1] = data[1 * width];
-s->regs[SONIC_RBWC0] = data[2 * width];
-s->regs[SONIC_RBWC1] = data[3 * width];
+s->regs[SONIC_CRBA0] = dp8393x_get(s, width, data, 0);
+s->regs[SONIC_CRBA1] = dp8393x_get(s, width, data, 1);
+s->regs[SONIC_RBWC0] = dp8393x_get(s, width, data, 2);
+s->regs[SONIC_RBWC1] = dp8393x_get(s, width, data, 3);
 DPRINTF("CRBA0/1: 0x%04x/0x%04x, RBWC0/1: 0x%04x/0x%04x\n",
 s->regs[SONIC_CRBA0], s->regs[SONIC_CRBA1],
 s->regs[SONIC_RBWC0], s->regs[SONIC_RBWC1]);
@@ -411,12 +435,12 @@ static void dp8393x_do_transmit_packets(dp8393xState *s)
 tx_len = 0;
 
 /* Update registers */
-s->regs[SONIC_TCR] = data[0 * width] & 0xf000;
-s->regs[SONIC_TPS] = data[1 * width];
-s->regs[SONIC_TFC] = data[2 * width];
-s->regs[SONIC_TSA0] = data[3 * width];
-s->regs[SONIC_TSA1] = data[4 * width];
-s->regs[SONIC_TFS] = data[5 * width];
+s->regs[SONIC_TCR] = dp8393x_get(s, width, data, 0) & 0xf000;
+s->regs[SONIC_TPS] = dp8393x_get(s, width, data, 1);
+s->regs[SONIC_TFC] = dp8393x_get(s, width, data, 2);
+s->regs[SONIC_TSA0] = dp8393x_get(s, width, data, 3);
+s->regs[SONIC_TSA1] = dp8393x_get(s, width, data, 4);
+s->regs[SONIC_TFS] = dp8393x_get(s, width, data, 5);
 
 /* Handle programmable interrupt */
 if (s->regs[SONIC_TCR] & SONIC_TCR_PINT) {
@@ -442,9 +466,9 @@ static void dp8393x_do_transmit_packets(dp8393xState *s)
 address_space_rw(&s->as,
 dp8393x_ttda(s) + sizeof(uint16_t) * (4 + 3 * i) * width,
 MEMTXATTRS_UNSPECIFIED, (uint8_t *)data, size, 0);
-s->regs[SONIC_TSA0

[Qemu-devel] [PATCH v9 4/9] hw/m68k: implement ADB bus support for via

2019-09-09 Thread Laurent Vivier
Co-developed-by: Mark Cave-Ayland 
Signed-off-by: Mark Cave-Ayland 
Signed-off-by: Laurent Vivier 
Reviewed-by: Hervé Poussineau 
Reviewed-by: Thomas Huth 
---
 hw/misc/mac_via.c | 190 ++
 include/hw/misc/mac_via.h |   7 ++
 2 files changed, 197 insertions(+)

diff --git a/hw/misc/mac_via.c b/hw/misc/mac_via.c
index 64914b806e..76cb5f8883 100644
--- a/hw/misc/mac_via.c
+++ b/hw/misc/mac_via.c
@@ -263,10 +263,16 @@
  * Table 19-10 ADB transaction states
  */
 
+#define ADB_STATE_NEW   0
+#define ADB_STATE_EVEN  1
+#define ADB_STATE_ODD   2
+#define ADB_STATE_IDLE  3
+
 #define VIA1B_vADB_StateMask(VIA1B_vADBS1 | VIA1B_vADBS2)
 #define VIA1B_vADB_StateShift   4
 
 #define VIA_TIMER_FREQ (783360)
+#define VIA_ADB_POLL_FREQ 50 /* XXX: not real */
 
 /* VIA returns time offset from Jan 1, 1904, not 1970 */
 #define RTC_OFFSET 2082844800
@@ -448,6 +454,181 @@ static void via1_rtc_update(MacVIAState *m)
 }
 }
 
+static int adb_via_poll(MacVIAState *s, int state, uint8_t *data)
+{
+if (state != ADB_STATE_IDLE) {
+return 0;
+}
+
+if (s->adb_data_in_size < s->adb_data_in_index) {
+return 0;
+}
+
+if (s->adb_data_out_index != 0) {
+return 0;
+}
+
+s->adb_data_in_index = 0;
+s->adb_data_out_index = 0;
+s->adb_data_in_size = adb_poll(&s->adb_bus, s->adb_data_in, 0x);
+
+if (s->adb_data_in_size) {
+*data = s->adb_data_in[s->adb_data_in_index++];
+qemu_irq_raise(s->adb_data_ready);
+}
+
+return s->adb_data_in_size;
+}
+
+static int adb_via_send(MacVIAState *s, int state, uint8_t data)
+{
+switch (state) {
+case ADB_STATE_NEW:
+s->adb_data_out_index = 0;
+break;
+case ADB_STATE_EVEN:
+if ((s->adb_data_out_index & 1) == 0) {
+return 0;
+}
+break;
+case ADB_STATE_ODD:
+if (s->adb_data_out_index & 1) {
+return 0;
+}
+break;
+case ADB_STATE_IDLE:
+return 0;
+}
+
+assert(s->adb_data_out_index < sizeof(s->adb_data_out) - 1);
+
+s->adb_data_out[s->adb_data_out_index++] = data;
+qemu_irq_raise(s->adb_data_ready);
+return 1;
+}
+
+static int adb_via_receive(MacVIAState *s, int state, uint8_t *data)
+{
+switch (state) {
+case ADB_STATE_NEW:
+return 0;
+
+case ADB_STATE_EVEN:
+if (s->adb_data_in_size <= 0) {
+qemu_irq_raise(s->adb_data_ready);
+return 0;
+}
+
+if (s->adb_data_in_index >= s->adb_data_in_size) {
+*data = 0;
+qemu_irq_raise(s->adb_data_ready);
+return 1;
+}
+
+if ((s->adb_data_in_index & 1) == 0) {
+return 0;
+}
+
+break;
+
+case ADB_STATE_ODD:
+if (s->adb_data_in_size <= 0) {
+qemu_irq_raise(s->adb_data_ready);
+return 0;
+}
+
+if (s->adb_data_in_index >= s->adb_data_in_size) {
+*data = 0;
+qemu_irq_raise(s->adb_data_ready);
+return 1;
+}
+
+if (s->adb_data_in_index & 1) {
+return 0;
+}
+
+break;
+
+case ADB_STATE_IDLE:
+if (s->adb_data_out_index == 0) {
+return 0;
+}
+
+s->adb_data_in_size = adb_request(&s->adb_bus, s->adb_data_in,
+  s->adb_data_out,
+  s->adb_data_out_index);
+s->adb_data_out_index = 0;
+s->adb_data_in_index = 0;
+if (s->adb_data_in_size < 0) {
+*data = 0xff;
+qemu_irq_raise(s->adb_data_ready);
+return -1;
+}
+
+if (s->adb_data_in_size == 0) {
+return 0;
+}
+
+break;
+}
+
+assert(s->adb_data_in_index < sizeof(s->adb_data_in) - 1);
+
+*data = s->adb_data_in[s->adb_data_in_index++];
+qemu_irq_raise(s->adb_data_ready);
+if (*data == 0xff || *data == 0) {
+return 0;
+}
+return 1;
+}
+
+static void via1_adb_update(MacVIAState *m)
+{
+MOS6522Q800VIA1State *v1s = MOS6522_Q800_VIA1(&m->mos6522_via1);
+MOS6522State *s = MOS6522(v1s);
+int state;
+int ret;
+
+state = (s->b & VIA1B_vADB_StateMask) >> VIA1B_vADB_StateShift;
+
+if (s->acr & VIA1ACR_vShiftOut) {
+/* output mode */
+ret = adb_via_send(m, state, s->sr);
+if (ret > 0) {
+s->b &= ~VIA1B_vADBInt;
+} else {
+s->b |= VIA1B_vADBInt;
+}
+} else {
+/* input mode */
+ret = adb_via_receive(m, state, &s->sr);
+if (ret > 0 && s->sr != 0xff) {
+s->b &= ~VIA1B_vADBInt;
+} else {
+s->b |= VIA1B_vADBInt;
+}
+}
+}
+
+static void via_adb_poll(void *opaque)
+{
+MacVIAState *m = opaque;
+MOS6522Q800VIA1State *v1s = MOS6522_Q800_VIA1(&m->mos6522_via1);
+MOS6522State *s = MOS6522(

[Qemu-devel] [PATCH v9 7/9] hw/m68k: add Nubus support for macfb video card

2019-09-09 Thread Laurent Vivier
From: Mark Cave-Ayland 

Co-developed-by: Mark Cave-Ayland 
Signed-off-by: Mark Cave-Ayland 
Signed-off-by: Laurent Vivier 
Reviewed-by: Hervé Poussineau 
---
 hw/display/Kconfig |  1 +
 hw/display/macfb.c | 56 ++
 include/hw/display/macfb.h | 21 ++
 3 files changed, 78 insertions(+)

diff --git a/hw/display/Kconfig b/hw/display/Kconfig
index 867b47673c..02163048cd 100644
--- a/hw/display/Kconfig
+++ b/hw/display/Kconfig
@@ -135,3 +135,4 @@ config ATI_VGA
 
 config MACFB
 bool
+depends on NUBUS
diff --git a/hw/display/macfb.c b/hw/display/macfb.c
index d7c5ef296e..f4fa8e3206 100644
--- a/hw/display/macfb.c
+++ b/hw/display/macfb.c
@@ -15,6 +15,7 @@
 #include "hw/sysbus.h"
 #include "ui/console.h"
 #include "ui/pixel_ops.h"
+#include "hw/nubus/nubus.h"
 #include "hw/display/macfb.h"
 #include "qapi/error.h"
 #include "hw/qdev-properties.h"
@@ -382,12 +383,38 @@ static void macfb_sysbus_realize(DeviceState *dev, Error 
**errp)
 sysbus_init_mmio(SYS_BUS_DEVICE(s), &ms->mem_vram);
 }
 
+const uint8_t macfb_rom[] = {
+255, 0, 0, 0,
+};
+
+static void macfb_nubus_realize(DeviceState *dev, Error **errp)
+{
+NubusDevice *nd = NUBUS_DEVICE(dev);
+MacfbNubusState *s = NUBUS_MACFB(dev);
+MacfbNubusDeviceClass *ndc = MACFB_NUBUS_GET_CLASS(dev);
+MacfbState *ms = &s->macfb;
+
+ndc->parent_realize(dev, errp);
+
+macfb_common_realize(dev, ms, errp);
+memory_region_add_subregion(&nd->slot_mem, DAFB_BASE, &ms->mem_ctrl);
+memory_region_add_subregion(&nd->slot_mem, VIDEO_BASE, &ms->mem_vram);
+
+nubus_register_rom(nd, macfb_rom, sizeof(macfb_rom), 1, 9, 0xf);
+}
+
 static void macfb_sysbus_reset(DeviceState *d)
 {
 MacfbSysBusState *s = MACFB(d);
 macfb_reset(&s->macfb);
 }
 
+static void macfb_nubus_reset(DeviceState *d)
+{
+MacfbNubusState *s = NUBUS_MACFB(d);
+macfb_reset(&s->macfb);
+}
+
 static Property macfb_sysbus_properties[] = {
 DEFINE_PROP_UINT32("width", MacfbSysBusState, macfb.width, 640),
 DEFINE_PROP_UINT32("height", MacfbSysBusState, macfb.height, 480),
@@ -395,6 +422,13 @@ static Property macfb_sysbus_properties[] = {
 DEFINE_PROP_END_OF_LIST(),
 };
 
+static Property macfb_nubus_properties[] = {
+DEFINE_PROP_UINT32("width", MacfbNubusState, macfb.width, 640),
+DEFINE_PROP_UINT32("height", MacfbNubusState, macfb.height, 480),
+DEFINE_PROP_UINT8("depth", MacfbNubusState, macfb.depth, 8),
+DEFINE_PROP_END_OF_LIST(),
+};
+
 static void macfb_sysbus_class_init(ObjectClass *klass, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(klass);
@@ -406,6 +440,19 @@ static void macfb_sysbus_class_init(ObjectClass *klass, 
void *data)
 dc->props = macfb_sysbus_properties;
 }
 
+static void macfb_nubus_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+MacfbNubusDeviceClass *ndc = MACFB_NUBUS_DEVICE_CLASS(klass);
+
+device_class_set_parent_realize(dc, macfb_nubus_realize,
+&ndc->parent_realize);
+dc->desc = "Nubus Macintosh framebuffer";
+dc->reset = macfb_nubus_reset;
+dc->vmsd = &vmstate_macfb;
+dc->props = macfb_nubus_properties;
+}
+
 static TypeInfo macfb_sysbus_info = {
 .name  = TYPE_MACFB,
 .parent= TYPE_SYS_BUS_DEVICE,
@@ -413,9 +460,18 @@ static TypeInfo macfb_sysbus_info = {
 .class_init= macfb_sysbus_class_init,
 };
 
+static TypeInfo macfb_nubus_info = {
+.name  = TYPE_NUBUS_MACFB,
+.parent= TYPE_NUBUS_DEVICE,
+.instance_size = sizeof(MacfbNubusState),
+.class_init= macfb_nubus_class_init,
+.class_size= sizeof(MacfbNubusDeviceClass),
+};
+
 static void macfb_register_types(void)
 {
 type_register_static(&macfb_sysbus_info);
+type_register_static(&macfb_nubus_info);
 }
 
 type_init(macfb_register_types)
diff --git a/include/hw/display/macfb.h b/include/hw/display/macfb.h
index 3fe2592735..26367ae2c4 100644
--- a/include/hw/display/macfb.h
+++ b/include/hw/display/macfb.h
@@ -40,4 +40,25 @@ typedef struct {
 MacfbState macfb;
 } MacfbSysBusState;
 
+#define MACFB_NUBUS_DEVICE_CLASS(class) \
+OBJECT_CLASS_CHECK(MacfbNubusDeviceClass, (class), TYPE_NUBUS_MACFB)
+#define MACFB_NUBUS_GET_CLASS(obj) \
+OBJECT_GET_CLASS(MacfbNubusDeviceClass, (obj), TYPE_NUBUS_MACFB)
+
+typedef struct MacfbNubusDeviceClass {
+DeviceClass parent_class;
+
+DeviceRealize parent_realize;
+} MacfbNubusDeviceClass;
+
+#define TYPE_NUBUS_MACFB "nubus-macfb"
+#define NUBUS_MACFB(obj) \
+OBJECT_CHECK(MacfbNubusState, (obj), TYPE_NUBUS_MACFB)
+
+typedef struct {
+NubusDevice busdev;
+
+MacfbState macfb;
+} MacfbNubusState;
+
 #endif
-- 
2.21.0




[Qemu-devel] [PATCH v9 0/9] hw/m68k: add Apple Machintosh Quadra 800 machine

2019-09-09 Thread Laurent Vivier
I'm rebasing some of these patches for seven years now,
too many years...

if you want to test the machine, I'm sorry, it doesn't boot
a MacROM, but you can boot a linux kernel from the command line.

You can install your own disk using debian-installer, with:

...
-M q800 \
-serial none -serial mon:stdio \
-m 1000M \
-net nic,model=dp83932,addr=09:00:07:12:34:57 \
-append "console=ttyS0 vga=off" \
-kernel vmlinux-4.16.0-1-m68k \
-initrd initrd.gz \
-drive file=debian-10.0-m68k-NETINST-1.iso,media=cdrom \
-drive file=m68k.qcow2,format=qcow2 \
-nographic

If you use a graphic adapter instead of "-nographic", you can use "-g" to set 
the
size of the display (I use "-g 1600x800x24").

You can get the ISO from:

https://cdimage.debian.org/cdimage/ports/10.0/m68k/iso-cd/debian-10.0-m68k-NETINST-1.iso

and extract the kernel and initrd.gz:

guestfish --add debian-10.0-m68k-NETINST-1.iso --ro \
  --mount /dev/sda:/ <<_EOF_
copy-out /install/cdrom/initrd.gz .
copy-out /install/kernels/vmlinux-4.16.0-1-m68k .
_EOF_

The mirror to use is: http://ftp.ports.debian.org/debian-ports/
when it fails, continue without boot loader.

In the same way, you can extract the kernel and the initramfs from the qcow2
image to use it with "-kernel" and "-initrd":

guestfish --add m68k.qcow2 --mount /dev/sda2:/ <<_EOF_
copy-out /boot/vmlinux-4.16.0-1-m68k .
copy-out /boot/initrd.img-4.16.0-1-m68k .
_EOF_

and boot with:

   ...
   -append "root=/dev/sda2 rw console=ttyS0 console=tty \
   -kernel vmlinux-4.16.0-1-m68k \
   -initrd initrd.img-4.16.0-1-m68k

NOTE: DHCP doesn't work but you can assign a static IP address.
  We need some patches for dp8393x that are not ready to be merged.
  See http://patchwork.ozlabs.org/patch/927020/
  http://patchwork.ozlabs.org/patch/927030/
  http://patchwork.ozlabs.org/patch/927026/

v9: Fix comments format
rebase on top of NeXTcube

v8: rebase (new blk_new(), add "qemu-common.h")
update bootinfo information and license
add some braces
Rename Q800IRQState to GLUEState:
it's more like a Logic Unit than an IRQ controller,
and Apple calls it "GLUE" (Mark: I prefer to keep it
like this for the moment, in the future this part
need to be reworked, we have to review the IRQ levels
and to wire NUBUS IRQ. The implementation is really trivial
for the moment and we will move it to QOM in the future)

v7: rebase and port to Kconfig
move IRQ controller back to q800.c (we don't need an object for this)
update log message for ESP changes and add some g_assert()
re-order patches: put esp, escc and dp8393x first

v6: Rebase onto git master (this now includes the m68k EXCP_ILLEGAL fix required
  for this patchset to boot)
Add Hervé's R-B tags
Drop ASC (Apple Sound Chip) device since the Linux driver is broken and
  it is not required for a successful boot
Remove extra esp_raise_irq() from ESP pseudo-DMA patch (Hervé)
Remove "return" from unimplemented write functions and instead add a
  "read only" comment (Hervé)
Rename MAX_FD to SWIM_MAX_FD in SWIM floppy controller patch to prevent
  potential conflicts with other files (Hervé)

v5: Rebase onto git master
Add Philippe's R-B to patch 10
Include the command line to boot a Linux kernel under the q800 machine in 
the
commit message for patch 11 (Philippe)
Fix up comments in hw/misc/mac_via.c (Thomas)
Add asserts to VIA ADB support to prevent potential buffer overflows 
(Thomas)
Move macfb surface/resolution checks to realise and remove hw_error (Thomas)
Move macfb draw_line functions inline and remove macfb-template.h (Mark)
Use guest address rather than source pointer in draw_line functions - this 
brings
  macfb in line with the VGA device and can prevent a potential buffer 
overflow
Use g_strdup_printf() for memory region names in NuBus devices instead of
  hardcoded length char arrays (Thomas)
Move NuBus QOM types from patch 7 to patch 8 (spotted by Thomas)
Move CONFIG_COLDFIRE sections together in hw/m68k/Makefile.objs (Thomas)
Remove obsolete comment from q800.c in patch 11 (Thomas)

v4: Drop RFC from subject prefix as this is getting close to final
Rebased onto master (fixing ESP, rom_ptr() conflicts)
Reworked q800.c based upon Thomas' comments about cpu_init() and
  qemu_check_nic_model()
Address Thomas' comments on using error_report() instead of hw_error()
Change the NuBus memory regions from DEVICE_NATIVE_ENDIAN to
  DEVICE_BIG_ENDIAN
Split macfb Nubus support into separate commit
Change VMSTATE_BUFFER_UNSAFE() to VMSTATE_UINT8_ARRAY() in macfb.c as
  suggested by David
Remove dummy Apple Sound Chip migration state as pointed out by David
Keep VIA ADB state and buffers in the mac_via device rather than adding
  to existing ADBState (this matches the pattern used in the PPC CUDA/PMU
  VIAs)

Re: [Qemu-devel] [RFC] libvhost-user: implement VHOST_USER_PROTOCOL_F_KICK_CALL_MSGS

2019-09-09 Thread Johannes Berg
On Mon, 2019-09-09 at 11:45 -0400, Michael S. Tsirkin wrote:
> On Mon, Sep 09, 2019 at 05:34:13PM +0200, Johannes Berg wrote:
> > On Mon, 2019-09-09 at 17:26 +0200, Johannes Berg wrote:
> > > Maybe instead we should just add a "VHOST_USER_REPLY_ERROR" bit (e.g.
> > > bit 4 after NEED_REPLY). Qemu in vhost_user_read_header() validates that
> > > it received REPLY_MASK | VERSION, so it would reject the message at that
> > > point.
> > > 
> > > Another possibility would be to define the highest bit of the 'request'
> > > field to indicate an error, so for GET_FEATURES we'd return the value
> > > 0x8000 | GET_FEATURES.
> > 
> > However, one way or another, that basically leaves us with three
> > different ways of indicating an error:
> > 
> >  1) already defined errors in existing messages - we can't change them
> > since those are handled at runtime now, e.g. VHOST_USER_POSTCOPY_END
> > returns a u64 value with an error status, and current code cannot
> > deal with an error flag in the 'request' or 'flags' field
> >  2) F_REPLY_ACK errors to messages that do not specify a response at all
> >  3) this new way of indicating an error back from messages that specify
> > a response, but the response has no inherent way of returning an
> > error
> > 
> > To me that really feels a bit too complex from the spec POV. But I don't
> > see a way to generalize this without another extension, and again the
> > device cannot choose which extensions it supports since the master
> > chooses them and just sets them.
> > 
> > Perhaps I really should just stick a "g_assert()" into the code at that
> > point,
> 
> There's the old way: close the socket.
> This will make reads fail gracefully.
> If we don't want complexity right now, I'd go with that.

D'oh, good point. OK, I'll do that. Though it's almost equivalent in
libvhost-user to just asserting, since it's mostly set up to just handle
a single connection and then quit.

Alright, thanks. Like I said, I'll send some more patches all around
once I get it working, right now I'm crashing in some weird ways that I
need to debug :)

johannes




Re: [Qemu-devel] [RFC] libvhost-user: implement VHOST_USER_PROTOCOL_F_KICK_CALL_MSGS

2019-09-09 Thread Michael S. Tsirkin
On Mon, Sep 09, 2019 at 05:34:13PM +0200, Johannes Berg wrote:
> On Mon, 2019-09-09 at 17:26 +0200, Johannes Berg wrote:
> > 
> > Maybe instead we should just add a "VHOST_USER_REPLY_ERROR" bit (e.g.
> > bit 4 after NEED_REPLY). Qemu in vhost_user_read_header() validates that
> > it received REPLY_MASK | VERSION, so it would reject the message at that
> > point.
> > 
> > Another possibility would be to define the highest bit of the 'request'
> > field to indicate an error, so for GET_FEATURES we'd return the value
> > 0x8000 | GET_FEATURES.
> 
> However, one way or another, that basically leaves us with three
> different ways of indicating an error:
> 
>  1) already defined errors in existing messages - we can't change them
> since those are handled at runtime now, e.g. VHOST_USER_POSTCOPY_END
> returns a u64 value with an error status, and current code cannot
> deal with an error flag in the 'request' or 'flags' field
>  2) F_REPLY_ACK errors to messages that do not specify a response at all
>  3) this new way of indicating an error back from messages that specify
> a response, but the response has no inherent way of returning an
> error
> 
> To me that really feels a bit too complex from the spec POV. But I don't
> see a way to generalize this without another extension, and again the
> device cannot choose which extensions it supports since the master
> chooses them and just sets them.
> 
> Perhaps I really should just stick a "g_assert()" into the code at that
> point,

There's the old way: close the socket.
This will make reads fail gracefully.
If we don't want complexity right now, I'd go with that.


> and have it crash, since it's likely that F_KICK_CALL_MSGS isn't
> even going to be implemented in qemu (unless it grows simulation support
> and then it'd all be conditional on some simulation command-line option)
> 
> 
> 
> And actually ... you got the order wrong:
> 
> > > Next command is GET_FEATURES. Return an error response from that
> > > and device init will fail.
> 
> That's not the case. We *start* with GET_FEATURES, if that includes
> protocol features then we do GET_PROTOCOL_FEATURES next, and then we get
> the # of queues next ...
> 
> Though the whole discussion pretty much applies equivalently to
> GET_QUEUES_NUM instead of GET_FEATURES.
> 
> johannes



  1   2   3   >