The code to check enumeration value policy can see special feature
flag 'deprecated' in QEnumLookup member flags[value]. I want to make
feature flag 'unstable' visible there as well, so I can add policy for
it.
Instead of extending flags[], replace it by @special_features (a
bitset of QapiSpecialFeature), because that's how special features get
passed around elsewhere.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Acked-by: John Snow <jsnow@redhat.com>
Message-Id: <20211028102520.747396-8-armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
The code to check command policy can see special feature flag
'deprecated' as command flag QCO_DEPRECATED. I want to make feature
flag 'unstable' visible there as well, so I can add policy for it.
To let me make it visible, add member @special_features (a bitset of
QapiSpecialFeature) to QmpCommand, and adjust the generator to pass it
through qmp_register_command(). Then replace "QCO_DEPRECATED in
@flags" by QAPI_DEPRECATED in @special_features", and drop
QCO_DEPRECATED.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Acked-by: John Snow <jsnow@redhat.com>
Message-Id: <20211028102520.747396-7-armbru@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
The generated visitor functions call visit_deprecated_accept() and
visit_deprecated() when visiting a struct member with special feature
flag 'deprecated'. This makes the feature flag visible to the actual
visitors. I want to make feature flag 'unstable' visible there as
well, so I can add policy for it.
To let me make it visible, replace these functions by
visit_policy_reject() and visit_policy_skip(), which take the member's
special features as an argument. Note that the new functions have the
opposite sense, i.e. the return value flips.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20211028102520.747396-6-armbru@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
[Unbreak forward visitor]
New enum QapiSpecialFeature enumerates the special feature flags.
New helper gen_special_features() returns code to represent a
collection of special feature flags as a bitset.
The next few commits will put them to use.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Message-Id: <20211028102520.747396-5-armbru@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Message-Id: <20211028102520.747396-4-armbru@redhat.com>
Add special feature 'unstable' everywhere the name starts with 'x-',
except for InputBarrierProperties member x-origin and
MemoryBackendProperties member x-use-canonical-path-for-ramblock-id,
because these two are actually stable.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Acked-by: John Snow <jsnow@redhat.com>
Message-Id: <20211028102520.747396-3-armbru@redhat.com>
By convention, names starting with "x-" are experimental. The parts
of external interfaces so named may be withdrawn or changed
incompatibly in future releases.
The naming convention makes unstable interfaces easy to recognize.
Promoting something from experimental to stable involves a name
change. Client code needs to be updated. Occasionally bothersome.
Worse, the convention is not universally observed:
* QOM type "input-barrier" has properties "x-origin", "y-origin".
Looks accidental, but it's ABI since 4.2.
* QOM types "memory-backend-file", "memory-backend-memfd",
"memory-backend-ram", and "memory-backend-epc" have a property
"x-use-canonical-path-for-ramblock-id" that is documented to be
stable despite its name.
We could document these exceptions, but documentation helps only
humans. We want to recognize "unstable" in code, like "deprecated".
So support recognizing it the same way: introduce new special feature
flag "unstable". It will be treated specially by the QAPI generator,
like the existing feature flag "deprecated", and unlike regular
feature flags.
This commit updates documentation and prepares tests. The next commit
updates the QAPI schema. The remaining patches update the QAPI
generator and wire up -compat policy checking.
Management applications can then use query-qmp-schema and -compat to
manage or guard against use of unstable interfaces the same way as for
deprecated interfaces.
docs/devel/qapi-code-gen.txt no longer mandates the naming convention.
Using it anyway might help writers of programs that aren't
full-fledged management applications. Not using it can save us
bothersome renames. We'll see how that shakes out.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Message-Id: <20211028102520.747396-2-armbru@redhat.com>
* First patch fixes suboptimal I/O performance on guest due to previously
incorrect block size being transmitted to 9p client.
* Subsequent patches are cleanup ones intended to reduce code complexity.
-----BEGIN PGP SIGNATURE-----
iQJLBAABCgA1FiEEltjREM96+AhPiFkBNMK1h2Wkc5UFAmF5UZoXHHFlbXVfb3Nz
QGNydWRlYnl0ZS5jb20ACgkQNMK1h2Wkc5XGSw//XdlI3Xj90uyoRKRgsMmnFOi6
4q4dDiigC4ut2BAsMnJOBT3me4Dj+6/fipargxVWDaSrpaAfMKIGbRItiMsrM4sp
3ILZEMF33lxF1ITw36pQlztaTccdZlFCbwQ/SrRphhX7AzDkDVuFfZvMxw6/FC8j
yXv8fmKDr7BU5Q0uCiisx9hvTmzXgywPTDoRsJVrtcnwhD9EGl8Fx8RSBRElC8Zb
c7+tvtSsSyEhqNyH9NdLB6IF/+7cSp8AU99pXwq9qEV2I3UmHS4TceYslHjuGkvg
xaBHLcYYvV0wP3SNjv+bSRj3WDdrNvrkj35JutgR5NdhSlLxF1eRkk3F+1DzpOCW
DXBRpxptMdOyX9nEu3+1tZ480AUIbxcHrf3HYUzMNBExnpS1JftpVyRu5gYOCXUd
nPSnWTAMI9YwkmNag4Gm0mZdnNyO15PtFZ5lF+HjG6Nam/MCBJBB8rCGGuTQkGQf
JwS1GrLvGjSFAgWF9Zm84aCX6f0Mzy84k+6vKVYk3jzicNmY9rdX+4x+e0ffHgol
BxvL2i077ZYcu1NXXawaWmLmcA5V6VKcRzXbSrgWknMJ4xB6nK2B1mXpCjIzFVgl
WDzZy6+rzk4tBbHRc1okmgc70gRk1EafYfg29Y2NvdGnNX+UUp5vpwUSqNpaYr2X
cGyAuS+H7bxi//DRk+U=
=2P3q
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/cschoenebeck/tags/pull-9p-20211027' into staging
9pfs: performance fix and cleanup
* First patch fixes suboptimal I/O performance on guest due to previously
incorrect block size being transmitted to 9p client.
* Subsequent patches are cleanup ones intended to reduce code complexity.
* remotes/cschoenebeck/tags/pull-9p-20211027:
9pfs: use P9Array in v9fs_walk()
9pfs: make V9fsPath usable via P9Array API
9pfs: make V9fsString usable via P9Array API
fsdev/p9array.h: check scalar type in P9ARRAY_NEW()
9pfs: introduce P9Array
9pfs: simplify blksize_to_iounit()
9pfs: deduplicate iounit code
9pfs: fix wrong I/O block size in Rgetattr
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
This copies the code implementing the policy from qapi/qmp-dispatch.c
to qapi/qobject-input-visitor.c. Tolerable, but if we acquire more
copies, we should look into factoring them out.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Tested-by: Peter Krempa <pkrempa@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
Message-Id: <20211025042405.3762351-5-armbru@redhat.com>
The next commit needs to access compat policy from the generic visitor
core. Move it there from qobject input and output visitor.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20211025042405.3762351-4-armbru@redhat.com>
This is quite similar to commit 84ab008687 "qapi: Add feature flags to
struct members", only for enums instead of structs.
Special feature flag 'deprecated' is silently ignored there. This is
okay only because it will be implemented shortly.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20211025042405.3762351-3-armbru@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
The next commit will add feature flags to enum members. There's a
problem, though: query-qmp-schema shows an enum type's members as an
array of member names (SchemaInfoEnum member @values). If it showed
an array of objects with a name member, we could simply add more
members to these objects. Since it's just strings, we can't.
I can see three ways to correct this design mistake:
1. Do it the way we should have done it, plus compatibility goo.
We want a ['SchemaInfoEnumMember'] member in SchemaInfoEnum. Since
changing @values would be a compatibility break, add a new member
@members instead.
@values is now redundant. In my testing, output of
qemu-system-x86_64's query-qmp-schema grows by 11% (18.5KiB).
We can deprecate @values now and drop it later. This will break
outmoded clients. Well-behaved clients such as libvirt are
expected to break cleanly.
2. Like 1, but omit "boring" elements of @member, and empty @member.
@values does not become redundant. @members augments it. Somewhat
cumbersome, but output of query-qmp-schema grows only as we make
enum members non-boring.
There is nothing to deprecate here.
3. Versioned query-qmp-schema.
query-qmp-schema provides either @values or @members. The QMP
client can select which version it wants. There is no redundant
output.
We can deprecate old versions and eventually drop them. This will
break outmoded clients. Breaking cleanly is easier than for 1.
While 1 and 2 operate within the common rules for compatible
evolution apply (section "Compatibility considerations" in
docs/devel/qapi-code-gen.rst), 3 bypasses them. Attractive when
operating within the rules is just too awkward. Not the case here.
This commit implements 1. Libvirt developers prefer it.
Deprecate @values in favour of @members. Since query-qmp-schema
compatibility is pretty fundamental for management applications, an
extended grace period is advised.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Tested-by: Peter Krempa <pkrempa@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
Message-Id: <20211025042405.3762351-2-armbru@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
The error message claims the parameter is invalid:
$ qemu-system-x86_64 -object qom-type=nonexistent
qemu-system-x86_64: -object qom-type=nonexistent: Invalid parameter 'nonexistent'
What's wrong is actually the *value* 'nonexistent'. Improve the
message to
qemu-system-x86_64: -object qom-type=nonexistent: Parameter 'qom-type' does not accept value 'nonexistent'
Fixes: https://gitlab.com/qemu-project/qemu/-/issues/608
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20211020180231.434071-1-armbru@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Make sure at compile time that the scalar type of the array
requested to be created via P9ARRAY_NEW() matches the scalar
type of the passed auto reference variable (unique pointer).
Suggested-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <c1965e2a096835dc9e1d4d659dfb15d96755cbe0.1633097129.git.qemu_oss@crudebyte.com>
Implements deep auto free of arrays while retaining common C-style
squared bracket access. Main purpose of this API is to get rid of
error prone individual array deallocation pathes in user code, i.e.
turning something like this:
void doSomething(size_t n) {
Foo *foos = malloc(n * sizeof(Foo));
for (...) {
foos[i].s = malloc(...);
if (...) {
goto out;
}
}
out:
if (...) {
for (...) {
/* deep deallocation */
free(foos[i].s);
}
/* array deallocation */
free(foos);
}
}
into something more simple and safer like:
void doSomething(size_t n) {
P9ARRAY_REF(Foo) foos = NULL;
P9ARRAY_NEW(Foo, foos, n);
for (...) {
foos[i].s = malloc(...);
if (...) {
return; /* array auto freed here */
}
}
/* array auto freed here */
}
Unlike GArray, P9Array does not require special macros, function
calls or struct member dereferencing to access the individual array
elements:
C-array = P9Array: vs. GArray:
for (...) { | for (...) {
... = arr[i].m; | ... = g_array_index(arr, Foo, i).m;
arr[i].m = ... ; | g_array_index(arr, Foo, i).m = ... ;
} | }
So existing C-style array code can be retained with only very little
changes; basically limited to replacing array allocation call and of
course removing individual array deallocation pathes.
In this initial version P9Array only supports the concept of unique
pointers, i.e. it does not support reference counting. The array (and
all dynamically allocated memory of individual array elements) is auto
freed once execution leaves the scope of the reference variable (unique
pointer) associated with the array.
Internally a flex array struct is used in combination with macros
spanned over a continuous memory space for both the array's meta data
(private) and the actual C-array user data (public):
struct P9Array##scalar_type {
size_t len; /* private, hidden from user code */
scalar_type first[]; /* public, directly exposed to user code */
};
Which has the advantage that the compiler automatically takes care
about correct padding, alignment and overall size for all scalar data
types on all systems and that the user space exposed pointer can
directly be translated back and forth between user space C-array
pointer and internal P9Array struct whenever needed, in a type-safe
manner.
This header file is released under MIT license, to allow this file
being used in other C-projects as well. The common QEMU license
GPL2+ might have construed a conflict for other projects.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <a954ef47b5ac26085a16c5c2aec8695374e0424d.1633097129.git.qemu_oss@crudebyte.com>
Use QEMU_ALIGN_DOWN() macro to reduce code and to make it
more human readable.
Suggested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <b84eb324d2ebdcc6f9c442c97b5b4d01eecb4f43.1632758315.git.qemu_oss@crudebyte.com>
When client sent a 9p Tgetattr request then the wrong I/O block
size value was returned by 9p server; instead of host file
system's I/O block size it should rather return an I/O block
size according to 9p session's 'msize' value, because the value
returned to client should be an "optimum" block size for I/O
(i.e. to maximize performance), it should not reflect the actual
physical block size of the underlying storage media.
The I/O block size of a host filesystem is typically 4k, so the
value returned was far too low for good 9p I/O performance.
This patch adds stat_to_iounit() with a similar approach as the
existing get_iounit() function.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <E1mT2Js-0000DW-OH@lizzy.crudebyte.com>
New 'unsupported' feature for xattr mapping
Good for hiding selinux
Plus some tidy ups and error handling.
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEERfXHG0oMt/uXep+pBRYzHrxb/ecFAmF32FwACgkQBRYzHrxb
/ecd7g/+JiFBnOhP6a8Vh2L5P4juGRVDHibKmT7FlQIBga47Cn6EtUTRBlI12aKl
LVOrEkicpEeg1f/xMJRICO/XSDfH6NTz1VPJtofpIdK9+vLr6Ny5An2VtO4zgPxq
1dswxGlr2qt1rxyXtiuC9FI+7zKpz8ynvDFPGVWmfnJBY8UIPb7fAxoL/+yM5x0M
1xI33xCzpzXvQMXRiB8fmH9F+kmF/HInz4hcZktuL/36bqFGeCkj15vdtfTuH+h9
qecSUmgBIPK+nYchjvbt0EeTO4jABc48Pmd7f7HHk7HkJc5r5iaMMXA+JTTcT37L
AE4EAdS9DhUr8XMMYf+1NC3UE0YrYg4PRWScdS5bmF9xwxaMklNDZUpmLylVJQ5F
QCoLUZQBEPaYnwAqrB5djQsxYDaKSk46ezeqeo8lbmyMU6hNe6l51V5k1e1YhDI/
0j4maCk36Ma7aWGJGOKxZE1tT2mqkLtAe/cWb8tqwy0L7MJ8kJ8JgQYqc12HlRuL
6wtakDjLjxMLEQ3dqqgu+SjqxdMvhL/siqyYJTsrohSYlQmWmZwXkcL54fNDy6+k
NDLtb502R7piM3VdM7yqQEL+5Z4w6u5Rgeklo8xb6hWiS0gEdgsyC069SHLKRE4+
jxp9izFOzUqFDpxv7aWT7CkzwFkJgIE9Grn00GBwVeYWT5oenhA=
=HDue
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/dagrh/tags/pull-virtiofs-20211026' into staging
Virtiofsd pull 2021-10-26
New 'unsupported' feature for xattr mapping
Good for hiding selinux
Plus some tidy ups and error handling.
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
# gpg: Signature made Tue 26 Oct 2021 03:28:44 AM PDT
# gpg: using RSA key 45F5C71B4A0CB7FB977A9FA90516331EBC5BFDE7
# gpg: Good signature from "Dr. David Alan Gilbert (RH2) <dgilbert@redhat.com>" [full]
* remotes/dagrh/tags/pull-virtiofs-20211026:
virtiofsd: Error on bad socket group name
virtiofsd: Add a helper to stop all queues
virtiofsd: Add a helper to send element on virtqueue
virtiofsd: Remove unused virtio_fs_config definition
virtiofsd: xattr mapping add a new type "unsupported"
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Make the '--socket-group=' option fail if the group name is unknown:
./tools/virtiofsd/virtiofsd .... --socket-group=zaphod
vhost socket: unable to find group 'zaphod'
Reported-by: Xiaoling Gao <xiagao@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20211014122554.34599-1-dgilbert@redhat.com>
Reviewed-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Use a helper to stop all the queues. Later in the patch series I am
planning to use this helper at one more place later in the patch series.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Message-Id: <20210930153037.1194279-6-vgoyal@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
We have open coded logic to take locks and push element on virtqueue at
three places. Add a helper and use it everywhere. Code is easier to read and
less number of lines of code.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Message-Id: <20210930153037.1194279-5-vgoyal@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
"struct virtio_fs_config" definition seems to be unused in fuse_virtio.c.
Remove it.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Message-Id: <20210930153037.1194279-4-vgoyal@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Right now for xattr remapping, we support types of "prefix", "ok" or "bad".
Type "bad" returns -EPERM on setxattr and hides xattr in listxattr. For
getxattr, mapping code returns -EPERM but getxattr code converts it to -ENODATA.
I need a new semantics where if an xattr is unsupported, then
getxattr()/setxattr() return -ENOTSUP and listxattr() should hide the xattr.
This is needed to simulate that security.selinux is not supported by
virtiofs filesystem and in that case client falls back to some default
label specified by policy.
So add a new type "unsupported" which returns -ENOTSUP on getxattr() and
setxattr() and hides xattrs in listxattr().
For example, one can use following mapping rule to not support
security.selinux xattr and allow others.
"-o xattrmap=/unsupported/all/security.selinux/security.selinux//ok/all///"
Suggested-by: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Message-Id: <YUt9qbmgAfCFfg5t@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
When we try to use 'analyze-migration.py -x' with python3,
we have the following errors:
Traceback (most recent call last):
File "scripts/analyze-migration.py", line 593, in <module>
f.write(jsonenc.encode(dump.vmsd_desc))
TypeError: a bytes-like object is required, not 'str'
Traceback (most recent call last):
File "scripts/analyze-migration.py", line 601, in <module>
f.write(jsonenc.encode(dict))
TypeError: a bytes-like object is required, not 'str'
This happens because the file 'f' is open in binary mode while
jsonenc.encode() returns a string.
The results are human-readable files, 'desc.json' and 'state.json',
so there is no reason to use the binary mode.
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20211015131645.501281-3-lvivier@redhat.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
The parameters of '-d' can be either 'state' or 'desc', not 'dump'
as it is reported in the error message.
Fixes: b17425701d ("Add migration stream analyzation script")
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20211015131645.501281-2-lvivier@redhat.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
All of these pages live in the wiki, not in the main web site.
Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Tested-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <163456470882.196333.17366490695504718038.stgit@bahia.huguette>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Signed-off-by: Tong Ho <tong.ho@xilinx.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Reviewed-by: Francisco Iglesias <frasse.iglesias@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20211015203532.2463705-4-tong.ho@xilinx.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Signed-off-by: Tong Ho <tong.ho@xilinx.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Reviewed-by: Francisco Iglesias <frasse.iglesias@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20211015203532.2463705-3-tong.ho@xilinx.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Signed-off-by: Tong Ho <tong.ho@xilinx.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Reviewed-by: Francisco Iglesias <frasse.iglesias@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20211015203532.2463705-2-tong.ho@xilinx.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Fix the comment to match what the code is doing, as explained in
the changelog of commit 86cf9e1546
that introduced the change:
Commit 9458a9a1df added synchronization
of vCPU and migration operations through calling run_on_cpu operation.
However, in replay mode this synchronization is unneeded, because
I/O and vCPU threads are already synchronized.
This patch disables such synchronization for record/replay mode.
Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: David Hildenbrand <david@redhat.com>
Message-Id: <163429018454.1146856.3429437540871060739.stgit@bahia.huguette>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
In order to help Eduardo and Marcel with the machine
core API, add myself as reviewer. That will also help
me to learn more about this subsystem :)
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Message-Id: <20211007093108.323223-1-philmd@redhat.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
- Vector extension bug fixes
- Bit manipulation extension bug fix
- Support vhost-user and numa mem options on all boards
- Rationalise XLEN and operand lengths
- Bump the OpenTitan FPGA support
- Remove the Ibex PLIC
- General code cleanup
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEE9sSsRtSTSGjTuM6PIeENKd+XcFQFAmFyvkoACgkQIeENKd+X
cFRvOQgAmSgFMu7BbiuLJ7W/0kK/a8vM53+HAMFyFvYiTS7ae2NRmxKyeR/OhFLf
qm36G/SbBhymWAvJysACa7mjvn104WnXkMdhLYGimkne/65IbnQOImzpXk81WP/n
45p/y0DdCs5pP2JNf9aIVxMMzgH2Lo4IgKxLFz+qpnphxtZGjdpocrCz837BOZQH
p61hadfi3rTc06w0Auq8A4Zr+Rp/gpoGzXmB0ujfRGfqi+brg40TV4EAX33e3BJi
249922MbFy2KqqO8H8So9rTZiK4gb/KJ0vGp61nwPcGsf1JPWXpeeb2g6L1syXHW
8J9VezmnIs8bs2SXDvkf0aZpEvDrIA==
=AKR1
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/alistair23/tags/pull-riscv-to-apply-20211022-2' into staging
Fourth RISC-V PR for QEMU 6.2
- Vector extension bug fixes
- Bit manipulation extension bug fix
- Support vhost-user and numa mem options on all boards
- Rationalise XLEN and operand lengths
- Bump the OpenTitan FPGA support
- Remove the Ibex PLIC
- General code cleanup
# gpg: Signature made Fri 22 Oct 2021 06:36:10 AM PDT
# gpg: using RSA key F6C4AC46D4934868D3B8CE8F21E10D29DF977054
# gpg: Good signature from "Alistair Francis <alistair@alistair23.me>" [full]
* remotes/alistair23/tags/pull-riscv-to-apply-20211022-2: (33 commits)
hw/riscv: spike: Use MachineState::ram and MachineClass::default_ram_id
hw/riscv: sifive_u: Use MachineState::ram and MachineClass::default_ram_id
hw/riscv: sifive_e: Use MachineState::ram and MachineClass::default_ram_id
hw/riscv: shakti_c: Use MachineState::ram and MachineClass::default_ram_id
hw/riscv: opentitan: Use MachineState::ram and MachineClass::default_ram_id
hw/riscv: microchip_pfsoc: Use MachineState::ram and MachineClass::default_ram_id
hw/intc: sifive_plic: Cleanup the irq_request function
hw/intc: sifive_plic: Cleanup the realize function
hw/intc: sifive_plic: Move the properties
hw/intc: Remove the Ibex PLIC
hw/riscv: opentitan: Update to the latest build
target/riscv: Compute mstatus.sd on demand
target/riscv: Use riscv_csrrw_debug for cpu_dump
target/riscv: Use gen_shift*_per_ol for RVB, RVI
target/riscv: Use gen_unary_per_ol for RVB
target/riscv: Adjust trans_rev8_32 for riscv64
target/riscv: Use gen_arith_per_ol for RVM
target/riscv: Replace DisasContext.w with DisasContext.ol
target/riscv: Replace is_32bit with get_xl/get_xlen
target/riscv: Properly check SEW in amo_op
...
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Since commit 12b6e9b27d ("disas: Clean up CPUDebug initialization")
the disassemble_info->bfd_endian enum is set for all targets in
target_disas(). We can directly call print_insn_nios2() and simplify.
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20210807110939.95853-3-f4bug@amsat.org>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
We are going to modify this function, fix its style first.
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20210807110939.95853-2-f4bug@amsat.org>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
* New fp5280g2-bmc board (John)
* Small cleanup in Aspeed SMC model (Cedric)
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEoPZlSPBIlev+awtgUaNDx8/77KEFAmFybmYACgkQUaNDx8/7
7KEqzRAAigdJJDS+F7uVYN9srdu8GtbXKRaGYgBcaPIGMzC42Ot9hE46UMUPPbf/
72QXynB09IvtkFgkX7xCaR3Lu1II7Ag+vf/VrjPltX1F05tdj9hTjPflJnPxWbBo
2nTU1vlUPXseaD5HQV/0ygYzqvbqyjCIhjSn0RKoMgKwrimBo52UByemOzh1unbV
nS4eCtQZlUj8ZPiwKViXk1XHscVyQY/7NhTTgdAUzkU74eIlf+op/mMRl3RWMOma
TsarphUoAfzCiYYZwg7IkWZWhTZt/zNR8OslNRfMbRFDfzFicCK3iu9L45jLaUix
W+N8z0xt1QxjWjzAAqHWVaNQion9zZS1Y219pI7rS76FI7m5CNDQ394lD3Pz3fqk
iW1JOtJACL9majRnZ58P7ScdVk68R/2Kt9VVcR93mkL4uAdrdxiWFScMssI1GmwR
CQ6m/Ktupw2YPqx87qNprsjpJriEx7ooU5SGdKpX7eLf2v5pcQRXLArfHOmL6mCe
xK0GGGTyz8E+GqzV8KciZpz9sEz0FoxPyqTjqboArvRPNCGnBvSSBISi24KXPXj3
MnOXiqLQ9BCAQRsSUMvWtof/X6DeAH7eQ8Pfk3+GxmnSsSInT6pOfbDESajMy7SY
ADji7W87JzIPqXO46JCgKU5yXmxaNfUKrJHm5nH0nlmQDUVT21E=
=qbBN
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/clg/tags/pull-aspeed-20211022' into staging
Aspeed patches :
* New fp5280g2-bmc board (John)
* Small cleanup in Aspeed SMC model (Cedric)
# gpg: Signature made Fri 22 Oct 2021 12:55:18 AM PDT
# gpg: using RSA key A0F66548F04895EBFE6B0B6051A343C7CFFBECA1
# gpg: Good signature from "Cédric Le Goater <clg@kaod.org>" [marginal]
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg: It is not certain that the signature belongs to the owner.
# Primary key fingerprint: A0F6 6548 F048 95EB FE6B 0B60 51A3 43C7 CFFB ECA1
* remotes/clg/tags/pull-aspeed-20211022:
speed/sdhci: Add trace events
aspeed/smc: Use a container for the flash mmio address space
aspeed: Add support for the fp5280g2-bmc board
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Using memory_region_init_ram(), which can't possibly handle vhost-user,
and can't work as expected with '-numa node,memdev' options.
Use MachineState::ram instead of manually initializing RAM memory
region, as well as by providing MachineClass::default_ram_id to
opt in to memdev scheme.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 20211020014112.7336-7-bmeng.cn@gmail.com
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Using memory_region_init_ram(), which can't possibly handle vhost-user,
and can't work as expected with '-numa node,memdev' options.
Use MachineState::ram instead of manually initializing RAM memory
region, as well as by providing MachineClass::default_ram_id to
opt in to memdev scheme.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 20211020014112.7336-6-bmeng.cn@gmail.com
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Using memory_region_init_ram(), which can't possibly handle vhost-user,
and can't work as expected with '-numa node,memdev' options.
Use MachineState::ram instead of manually initializing RAM memory
region, as well as by providing MachineClass::default_ram_id to
opt in to memdev scheme.
While at it add check for user supplied RAM size and error out if it
mismatches board expected value.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-id: 20211020014112.7336-5-bmeng.cn@gmail.com
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Using memory_region_init_ram(), which can't possibly handle vhost-user,
and can't work as expected with '-numa node,memdev' options.
Use MachineState::ram instead of manually initializing RAM memory
region, as well as by providing MachineClass::default_ram_id to
opt in to memdev scheme.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 20211020014112.7336-4-bmeng.cn@gmail.com
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Using memory_region_init_ram(), which can't possibly handle vhost-user,
and can't work as expected with '-numa node,memdev' options.
Use MachineState::ram instead of manually initializing RAM memory
region, as well as by providing MachineClass::default_ram_id to
opt in to memdev scheme.
While at it add check for user supplied RAM size and error out if it
mismatches board expected value.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-id: 20211020014112.7336-3-bmeng.cn@gmail.com
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Using memory_region_init_ram(), which can't possibly handle vhost-user,
and can't work as expected with '-numa node,memdev' options.
Use MachineState::ram instead of manually initializing RAM memory
region, as well as by providing MachineClass::default_ram_id to
opt in to memdev scheme.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-id: 20211020014112.7336-2-bmeng.cn@gmail.com
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
