[PULL 070/113] vl: separate qemu_resolve_machine_memdev
This is a bit nasty: the machine is storing a string and later
resolving it. We probably want to remove the memdev property
and instead make this a memory-set command. "-M memdev" can be
handled a legacy option that is special cased by
machine_set_property.
Reviewed-by: Igor Mammedov
Signed-off-by: Paolo Bonzini
---
softmmu/vl.c | 70 +++-
1 file changed, 37 insertions(+), 33 deletions(-)
diff --git a/softmmu/vl.c b/softmmu/vl.c
index acf09b2040..891f959572 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -2846,6 +2846,42 @@ static bool have_custom_ram_size(void)
return !!qemu_opt_get_size(opts, "size", 0);
}
+static void qemu_resolve_machine_memdev(void)
+{
+if (current_machine->ram_memdev_id) {
+Object *backend;
+ram_addr_t backend_size;
+
+backend = object_resolve_path_type(current_machine->ram_memdev_id,
+ TYPE_MEMORY_BACKEND, NULL);
+if (!backend) {
+error_report("Memory backend '%s' not found",
+ current_machine->ram_memdev_id);
+exit(EXIT_FAILURE);
+}
+backend_size = object_property_get_uint(backend, "size",
_abort);
+if (have_custom_ram_size() && backend_size != ram_size) {
+error_report("Size specified by -m option must match size of "
+ "explicitly specified 'memory-backend' property");
+exit(EXIT_FAILURE);
+}
+if (mem_path) {
+error_report("'-mem-path' can't be used together with"
+ "'-machine memory-backend'");
+exit(EXIT_FAILURE);
+}
+ram_size = backend_size;
+}
+
+if (!xen_enabled()) {
+/* On 32-bit hosts, QEMU is limited by virtual address space */
+if (ram_size > (2047 << 20) && HOST_LONG_BITS == 32) {
+error_report("at most 2047 MB RAM can be simulated");
+exit(1);
+}
+}
+}
+
static void set_memory_options(MachineClass *mc)
{
uint64_t sz;
@@ -4474,39 +4510,7 @@ void qemu_init(int argc, char **argv, char **envp)
current_machine->cpu_type = parse_cpu_option(cpu_option);
}
-if (current_machine->ram_memdev_id) {
-Object *backend;
-ram_addr_t backend_size;
-
-backend = object_resolve_path_type(current_machine->ram_memdev_id,
- TYPE_MEMORY_BACKEND, NULL);
-if (!backend) {
-error_report("Memory backend '%s' not found",
- current_machine->ram_memdev_id);
-exit(EXIT_FAILURE);
-}
-backend_size = object_property_get_uint(backend, "size",
_abort);
-if (have_custom_ram_size() && backend_size != ram_size) {
-error_report("Size specified by -m option must match size of "
- "explicitly specified 'memory-backend' property");
-exit(EXIT_FAILURE);
-}
-if (mem_path) {
-error_report("'-mem-path' can't be used together with"
- "'-machine memory-backend'");
-exit(EXIT_FAILURE);
-}
-ram_size = backend_size;
-}
-
-if (!xen_enabled()) {
-/* On 32-bit hosts, QEMU is limited by virtual address space */
-if (ram_size > (2047 << 20) && HOST_LONG_BITS == 32) {
-error_report("at most 2047 MB RAM can be simulated");
-exit(1);
-}
-}
-
+qemu_resolve_machine_memdev();
parse_numa_opts(current_machine);
/* do monitor/qmp handling at preconfig state if requested */
--
2.26.2
[PULL 037/113] cris: do not use ram_size global
Use the machine properties instead.
Signed-off-by: Paolo Bonzini
---
hw/cris/axis_dev88.c | 1 +
hw/cris/boot.c | 2 +-
hw/cris/boot.h | 1 +
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/hw/cris/axis_dev88.c b/hw/cris/axis_dev88.c
index dab7423c73..b0cb6d84af 100644
--- a/hw/cris/axis_dev88.c
+++ b/hw/cris/axis_dev88.c
@@ -333,6 +333,7 @@ void axisdev88_init(MachineState *machine)
if (kernel_filename) {
li.image_filename = kernel_filename;
li.cmdline = kernel_cmdline;
+li.ram_size = machine->ram_size;
cris_load_image(cpu, );
} else if (!qtest_enabled()) {
fprintf(stderr, "Kernel image must be specified\n");
diff --git a/hw/cris/boot.c b/hw/cris/boot.c
index aa8d2756d6..9fa09cfd83 100644
--- a/hw/cris/boot.c
+++ b/hw/cris/boot.c
@@ -81,7 +81,7 @@ void cris_load_image(CRISCPU *cpu, struct cris_load_info *li)
if (image_size < 0) {
/* Takes a kimage from the axis devboard SDK. */
image_size = load_image_targphys(li->image_filename, 0x40004000,
- ram_size);
+ li->ram_size);
li->entry = 0x40004000;
}
diff --git a/hw/cris/boot.h b/hw/cris/boot.h
index 218854e5d1..9f1e0e340c 100644
--- a/hw/cris/boot.h
+++ b/hw/cris/boot.h
@@ -6,6 +6,7 @@ struct cris_load_info
const char *image_filename;
const char *cmdline;
int image_size;
+ram_addr_t ram_size;
hwaddr entry;
};
--
2.26.2
[PULL 060/113] vl: extract various command line desugaring snippets to a new function
Keep the machine initialization sequence free of miscellaneous command
line parsing actions.
The only difference is that preallocation will always be done with one
thread if -smp is not provided; previously it was using mc->default_cpus,
which is almost always 1 anyway.
Reviewed-by: Igor Mammedov
Signed-off-by: Paolo Bonzini
---
softmmu/vl.c | 40 ++--
1 file changed, 22 insertions(+), 18 deletions(-)
diff --git a/softmmu/vl.c b/softmmu/vl.c
index 98994e10fa..85b23d51be 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -126,6 +126,7 @@ static const char *boot_once;
static const char *incoming;
static const char *loadvm;
enum vga_retrace_method vga_retrace_method = VGA_RETRACE_DUMB;
+static int mem_prealloc; /* force preallocation of physical target memory */
int display_opengl;
const char* keyboard_layout = NULL;
static ram_addr_t ram_size;
@@ -158,7 +159,7 @@ int fd_bootchk = 1;
static int no_reboot;
int no_shutdown = 0;
int graphic_rotate = 0;
-const char *watchdog;
+static const char *watchdog;
QEMUOptionRom option_rom[MAX_OPTION_ROMS];
int nb_option_roms;
int old_param = 0;
@@ -2914,6 +2915,25 @@ static void qemu_validate_options(void)
#endif
}
+static void qemu_process_sugar_options(void)
+{
+if (mem_prealloc) {
+char *val;
+
+val = g_strdup_printf("%d",
+ (uint32_t)
qemu_opt_get_number(qemu_find_opts_singleton("smp-opts"), "cpus", 1));
+object_register_sugar_prop("memory-backend", "prealloc-threads", val);
+g_free(val);
+object_register_sugar_prop("memory-backend", "prealloc", "on");
+}
+
+if (watchdog) {
+int i = select_watchdog(watchdog);
+if (i > 0)
+exit (i == 1 ? 1 : 0);
+}
+}
+
static void qemu_process_early_options(void)
{
char **dirs;
@@ -3175,7 +3195,6 @@ static void qemu_machine_creation_done(void)
void qemu_init(int argc, char **argv, char **envp)
{
-int i;
int snapshot = 0;
QemuOpts *opts, *machine_opts;
QemuOpts *icount_opts = NULL, *accel_opts = NULL;
@@ -3194,7 +3213,6 @@ void qemu_init(int argc, char **argv, char **envp)
bool have_custom_ram_size;
BlockdevOptionsQueue bdo_queue = QSIMPLEQ_HEAD_INITIALIZER(bdo_queue);
QemuPluginList plugin_list = QTAILQ_HEAD_INITIALIZER(plugin_list);
-int mem_prealloc = 0; /* force preallocation of physical target memory */
qemu_add_opts(_drive_opts);
qemu_add_drive_opts(_legacy_drive_opts);
@@ -4106,6 +4124,7 @@ void qemu_init(int argc, char **argv, char **envp)
loc_set_none();
qemu_validate_options();
+qemu_process_sugar_options();
/*
* These options affect everything else and should be processed
@@ -4159,15 +4178,6 @@ void qemu_init(int argc, char **argv, char **envp)
machine_smp_parse(current_machine,
qemu_opts_find(qemu_find_opts("smp-opts"), NULL), _fatal);
-if (mem_prealloc) {
-char *val;
-
-val = g_strdup_printf("%d", current_machine->smp.cpus);
-object_register_sugar_prop("memory-backend", "prealloc-threads", val);
-g_free(val);
-object_register_sugar_prop("memory-backend", "prealloc", "on");
-}
-
/*
* Get the default machine options from the machine if it is not already
* specified either by the configuration file or by the command line.
@@ -4426,12 +4436,6 @@ void qemu_init(int argc, char **argv, char **envp)
select_vgahw(machine_class, vga_model);
}
-if (watchdog) {
-i = select_watchdog(watchdog);
-if (i > 0)
-exit (i == 1 ? 1 : 0);
-}
-
/* This checkpoint is required by replay to separate prior clock
reading from the other reads, because timer polling functions query
clock values from the log. */
--
2.26.2
[PULL 050/113] hw/char/serial: Clean up unnecessary code
From: Philippe Mathieu-Daudé
Since commit 5ec3a23e6c8 ("serial: convert PIO to new memory
api read/write") we don't need to worry about accesses bigger
than 8-bit. Use the extract()/deposit() functions to access
the correct part of the 16-bit 'divider' register.
Reported-by: Jonathan D. Belanger
Buglink: https://bugs.launchpad.net/qemu/+bug/1904331
Signed-off-by: Philippe Mathieu-Daudé
Message-Id: <20201120161933.2514089-1-f4...@amsat.org>
Signed-off-by: Paolo Bonzini
---
hw/char/serial.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/hw/char/serial.c b/hw/char/serial.c
index 97f71879ff..62c627f486 100644
--- a/hw/char/serial.c
+++ b/hw/char/serial.c
@@ -24,6 +24,7 @@
*/
#include "qemu/osdep.h"
+#include "qemu/bitops.h"
#include "hw/char/serial.h"
#include "hw/irq.h"
#include "migration/vmstate.h"
@@ -338,11 +339,7 @@ static void serial_ioport_write(void *opaque, hwaddr addr,
uint64_t val,
default:
case 0:
if (s->lcr & UART_LCR_DLAB) {
-if (size == 1) {
-s->divider = (s->divider & 0xff00) | val;
-} else {
-s->divider = val;
-}
+s->divider = deposit32(s->divider, 8 * addr, 8, val);
serial_update_parameters(s);
} else {
s->thr = (uint8_t) val;
@@ -364,7 +361,7 @@ static void serial_ioport_write(void *opaque, hwaddr addr,
uint64_t val,
break;
case 1:
if (s->lcr & UART_LCR_DLAB) {
-s->divider = (s->divider & 0x00ff) | (val << 8);
+s->divider = deposit32(s->divider, 8 * addr, 8, val);
serial_update_parameters(s);
} else {
uint8_t changed = (s->ier ^ val) & 0x0f;
@@ -478,7 +475,7 @@ static uint64_t serial_ioport_read(void *opaque, hwaddr
addr, unsigned size)
default:
case 0:
if (s->lcr & UART_LCR_DLAB) {
-ret = s->divider & 0xff;
+ret = extract16(s->divider, 8 * addr, 8);
} else {
if(s->fcr & UART_FCR_FE) {
ret = fifo8_is_empty(>recv_fifo) ?
@@ -502,7 +499,7 @@ static uint64_t serial_ioport_read(void *opaque, hwaddr
addr, unsigned size)
break;
case 1:
if (s->lcr & UART_LCR_DLAB) {
-ret = (s->divider >> 8) & 0xff;
+ret = extract16(s->divider, 8 * addr, 8);
} else {
ret = s->ier;
}
--
2.26.2
[PULL 102/113] scripts: kernel-doc: fix typedef identification
From: Mauro Carvalho Chehab
Some typedef expressions are output as normal functions.
As we need to be clearer about the type with Sphinx 3.x,
detect such cases.
While here, fix a wrongly-indented block.
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Paolo Bonzini
Message-Id: <20201117165312.118257-21-pbonz...@redhat.com>
Signed-off-by: Paolo Bonzini
---
scripts/kernel-doc | 64 +-
1 file changed, 41 insertions(+), 23 deletions(-)
diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 35d60af834..0c31e9ad66 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -1748,30 +1748,48 @@ sub dump_function($$) {
return;
}
- my $prms = join " ", @parameterlist;
- check_sections($file, $declaration_name, "function", $sectcheck, $prms);
-
-# This check emits a lot of warnings at the moment, because many
-# functions don't have a 'Return' doc section. So until the number
-# of warnings goes sufficiently down, the check is only performed in
-# verbose mode.
-# TODO: always perform the check.
-if ($verbose && !$noret) {
-check_return_section($file, $declaration_name, $return_type);
-}
+my $prms = join " ", @parameterlist;
+check_sections($file, $declaration_name, "function", $sectcheck, $prms);
+
+# This check emits a lot of warnings at the moment, because many
+# functions don't have a 'Return' doc section. So until the number
+# of warnings goes sufficiently down, the check is only performed in
+# verbose mode.
+# TODO: always perform the check.
+if ($verbose && !$noret) {
+ check_return_section($file, $declaration_name, $return_type);
+}
-output_declaration($declaration_name,
- 'function',
- {'function' => $declaration_name,
- 'module' => $modulename,
- 'functiontype' => $return_type,
- 'parameterlist' => \@parameterlist,
- 'parameterdescs' => \%parameterdescs,
- 'parametertypes' => \%parametertypes,
- 'sectionlist' => \@sectionlist,
- 'sections' => \%sections,
- 'purpose' => $declaration_purpose
- });
+# The function parser can be called with a typedef parameter.
+# Handle it.
+if ($return_type =~ /typedef/) {
+ output_declaration($declaration_name,
+ 'function',
+ {'function' => $declaration_name,
+ 'typedef' => 1,
+ 'module' => $modulename,
+ 'functiontype' => $return_type,
+ 'parameterlist' => \@parameterlist,
+ 'parameterdescs' => \%parameterdescs,
+ 'parametertypes' => \%parametertypes,
+ 'sectionlist' => \@sectionlist,
+ 'sections' => \%sections,
+ 'purpose' => $declaration_purpose
+ });
+} else {
+ output_declaration($declaration_name,
+ 'function',
+ {'function' => $declaration_name,
+ 'module' => $modulename,
+ 'functiontype' => $return_type,
+ 'parameterlist' => \@parameterlist,
+ 'parameterdescs' => \%parameterdescs,
+ 'parametertypes' => \%parametertypes,
+ 'sectionlist' => \@sectionlist,
+ 'sections' => \%sections,
+ 'purpose' => $declaration_purpose
+ });
+}
}
sub reset_state {
--
2.26.2
[PULL 100/113] scripts: kernel-doc: fix troubles with line counts
From: Mauro Carvalho Chehab
There's currently a bug with the way kernel-doc script
counts line numbers that can be seen with:
$ ./scripts/kernel-doc -rst -enable-lineno include/linux/math64.h >all
&& ./scripts/kernel-doc -rst -internal -enable-lineno include/linux/math64.h
>int && diff -U0 int all
--- int 2020-09-28 12:58:08.927486808 +0200
+++ all 2020-09-28 12:58:08.905486845 +0200
@@ -1 +1 @@
-#define LINENO 27
+#define LINENO 26
@@ -3 +3 @@
-#define LINENO 16
+#define LINENO 15
@@ -9 +9 @@
-#define LINENO 17
+#define LINENO 16
...
This is happening with perl version 5.30.3, but I'm not
so sure if this is a perl bug, or if this is due to something
else.
In any case, fixing it is easy. Basically, when "-internal"
parameter is used, the process_export_file() function opens the
handle "IN". This makes the line number to be incremented, as the
handler for the main open is also "IN".
Fix the problem by using a different handler for the
main open().
While here, add a missing close for it.
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Paolo Bonzini
Message-Id: <20201117165312.118257-19-pbonz...@redhat.com>
Signed-off-by: Paolo Bonzini
---
scripts/kernel-doc | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 75ddd3b5e6..f33a4b1cc7 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -2268,7 +2268,7 @@ sub process_file($) {
$file = map_filename($orig_file);
-if (!open(IN,"<$file")) {
+if (!open(IN_FILE,"<$file")) {
print STDERR "Error: Cannot open file $file\n";
++$errors;
return;
@@ -2277,9 +2277,9 @@ sub process_file($) {
$. = 1;
$section_counter = 0;
-while () {
+while () {
while (s/\\\s*$//) {
- $_ .= ;
+ $_ .= ;
}
# Replace tabs by spaces
while ($_ =~ s/\t+/' ' x (length($&) * 8 - length($`) % 8)/e) {};
@@ -2311,6 +2311,7 @@ sub process_file($) {
print STDERR "${file}:1: warning: no structured comments found\n";
}
}
+close IN_FILE;
}
--
2.26.2
[PATCH 03/28] qemu-option: clean up id vs. list->merge_lists
Looking at all merge-lists QemuOptsList, here is how they access their
QemuOpts:
reopen_opts in qemu-io-cmds.c ("qemu-img reopen -o")
qemu_opts_find(_opts, NULL)
empty_opts in qemu-io.c ("qemu-io open -o")
qemu_opts_find(_opts, NULL)
qemu_rtc_opts ("-rtc")
qemu_find_opts_singleton("rtc")
qemu_machine_opts ("-M")
qemu_find_opts_singleton("machine")
qemu_boot_opts ("-boot")
QTAILQ_FIRST(_find_opts("bootopts")->head)
qemu_name_opts ("-name")
qemu_opts_foreach->parse_name
parse_name does not use id
qemu_mem_opts ("-m")
qemu_find_opts_singleton("memory")
qemu_icount_opts ("-icount")
qemu_opts_foreach->do_configuree_icount
do_configure_icount->icount_configure
icount_configure does not use id
qemu_smp_opts ("-smp")
qemu_opts_find(qemu_find_opts("smp-opts"), NULL)
qemu_spice_opts ("-spice")
QTAILQ_FIRST(_spice_opts.head)
i.e. they don't need an id. Sometimes its presence is ignored
(e.g. when using qemu_opts_foreach), sometimes all the options
with the id are skipped, sometimes only the first option on the
command line is considered. With this patch we just forbid id
on merge-lists QemuOptsLists; if the command line still works,
it has the same semantics as before.
qemu_opts_create's fail_if_exists parameter is now unnecessary:
- it is unused if id is NULL
- opts_parse only passes false if reached from qemu_opts_set_defaults,
in which case this patch enforces that id must be NULL
- other callers that can pass a non-NULL id always set it to true
Assert that it is true in the only case where "fail_if_exists" matters,
i.e. "id && !lists->merge_lists". This means that if an id is present,
duplicates are always forbidden, which was already the status quo.
Discounting the case that aborts as it's not user-controlled (it's
"just" a matter of inspecting qemu_opts_create callers), the paths
through qemu_opts_create can be summarized as:
- merge_lists = true: singleton opts with NULL id; non-NULL id fails
- merge_lists = false: always return new opts; non-NULL id fails if dup
Signed-off-by: Paolo Bonzini
---
util/qemu-option.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/util/qemu-option.c b/util/qemu-option.c
index c88e159f18..91f4120ce1 100644
--- a/util/qemu-option.c
+++ b/util/qemu-option.c
@@ -619,7 +619,17 @@ QemuOpts *qemu_opts_create(QemuOptsList *list, const char
*id,
{
QemuOpts *opts = NULL;
-if (id) {
+if (list->merge_lists) {
+if (id) {
+error_setg(errp, QERR_INVALID_PARAMETER, "id");
+return NULL;
+}
+opts = qemu_opts_find(list, NULL);
+if (opts) {
+return opts;
+}
+} else if (id) {
+assert(fail_if_exists);
if (!id_wellformed(id)) {
error_setg(errp, QERR_INVALID_PARAMETER_VALUE, "id",
"an identifier");
@@ -629,17 +639,8 @@ QemuOpts *qemu_opts_create(QemuOptsList *list, const char
*id,
}
opts = qemu_opts_find(list, id);
if (opts != NULL) {
-if (fail_if_exists && !list->merge_lists) {
-error_setg(errp, "Duplicate ID '%s' for %s", id, list->name);
-return NULL;
-} else {
-return opts;
-}
-}
-} else if (list->merge_lists) {
-opts = qemu_opts_find(list, NULL);
-if (opts) {
-return opts;
+error_setg(errp, "Duplicate ID '%s' for %s", id, list->name);
+return NULL;
}
}
opts = g_malloc0(sizeof(*opts));
@@ -893,7 +894,7 @@ static QemuOpts *opts_parse(QemuOptsList *list, const char
*params,
* (if unlikely) future misuse:
*/
assert(!defaults || list->merge_lists);
-opts = qemu_opts_create(list, id, !defaults, errp);
+opts = qemu_opts_create(list, id, !list->merge_lists, errp);
g_free(id);
if (opts == NULL) {
return NULL;
--
2.26.2
[PATCH 08/28] tests: convert check-qom-proplist to keyval
The command-line creation test is using QemuOpts. Switch it to keyval,
since all the -object command line options will follow
qemu-storage-daemon and do the same.
Signed-off-by: Paolo Bonzini
---
tests/check-qom-proplist.c | 58 +-
1 file changed, 38 insertions(+), 20 deletions(-)
diff --git a/tests/check-qom-proplist.c b/tests/check-qom-proplist.c
index 1b76581980..8dba26fb3c 100644
--- a/tests/check-qom-proplist.c
+++ b/tests/check-qom-proplist.c
@@ -21,6 +21,8 @@
#include "qemu/osdep.h"
#include "qapi/error.h"
+#include "qapi/qmp/qdict.h"
+#include "qapi/qmp/qobject.h"
#include "qom/object.h"
#include "qemu/module.h"
#include "qemu/option.h"
@@ -400,42 +402,58 @@ static void test_dummy_createlist(void)
static void test_dummy_createcmdl(void)
{
-QemuOpts *opts;
+QDict *qdict;
DummyObject *dobj;
Error *err = NULL;
+bool help;
const char *params = TYPE_DUMMY \
",id=dev0," \
"bv=yes,sv=Hiss hiss hiss,av=platypus";
-qemu_add_opts(_object_opts);
-opts = qemu_opts_parse(_object_opts, params, true, );
+qdict = keyval_parse(params, "qom-type", , );
g_assert(err == NULL);
-g_assert(opts);
+g_assert(qdict);
+g_assert(!help);
-dobj = DUMMY_OBJECT(user_creatable_add_opts(opts, ));
+g_assert(user_creatable_add_dict(qdict, true, ));
g_assert(err == NULL);
+qobject_unref(qdict);
+
+dobj =
DUMMY_OBJECT(object_resolve_path_component(object_get_objects_root(),
+ "dev0"));
g_assert(dobj);
g_assert_cmpstr(dobj->sv, ==, "Hiss hiss hiss");
g_assert(dobj->bv == true);
g_assert(dobj->av == DUMMY_PLATYPUS);
+qdict = keyval_parse(params, "qom-type", , );
+g_assert(!user_creatable_add_dict(qdict, true, ));
+g_assert(err);
+g_assert(object_resolve_path_component(object_get_objects_root(), "dev0")
+ == OBJECT(dobj));
+qobject_unref(qdict);
+error_free(err);
+err = NULL;
+
+qdict = keyval_parse(params, "qom-type", , );
user_creatable_del("dev0", _abort);
+g_assert(object_resolve_path_component(object_get_objects_root(), "dev0")
+ == NULL);
-object_unref(OBJECT(dobj));
-
-/*
- * cmdline-parsing via qemu_opts_parse() results in a QemuOpts entry
- * corresponding to the Object's ID to be added to the QemuOptsList
- * for objects. To avoid having this entry conflict with future
- * Objects using the same ID (which can happen in cases where
- * qemu_opts_parse() is used to parse the object params, such as
- * with hmp_object_add() at the time of this comment), we need to
- * check for this in user_creatable_del() and remove the QemuOpts if
- * it is present.
- *
- * The below check ensures this works as expected.
- */
-g_assert_null(qemu_opts_find(_object_opts, "dev0"));
+g_assert(user_creatable_add_dict(qdict, true, ));
+g_assert(err == NULL);
+qobject_unref(qdict);
+
+dobj =
DUMMY_OBJECT(object_resolve_path_component(object_get_objects_root(),
+ "dev0"));
+g_assert(dobj);
+g_assert_cmpstr(dobj->sv, ==, "Hiss hiss hiss");
+g_assert(dobj->bv == true);
+g_assert(dobj->av == DUMMY_PLATYPUS);
+g_assert(object_resolve_path_component(object_get_objects_root(), "dev0")
+ == OBJECT(dobj));
+
+object_unparent(OBJECT(dobj));
}
static void test_dummy_badenum(void)
--
2.26.2
Re: [PATCH v3 6/6] linux-user: Add support for MIPS Loongson 2F/3E
On 12/2/20 2:01 AM, chen huacai wrote:
> Hi, Philippe,
>
> On Wed, Dec 2, 2020 at 3:31 AM Philippe Mathieu-Daudé wrote:
>>
>> Userland ELF binaries using Longsoon SIMD instructions have the
>> HWCAP_LOONGSON_MMI bit set [1].
>> Binaries compiled for Longsoon 3E [2] have the HWCAP_LOONGSON_EXT
>> bit set for the LQ / SQ instructions.
> What is Loongson-3E? I think you want to say Loongson-3A?
Yes =) I have been confused because I looked at the INSN_LOONGSON2E
and INSN_LOONGSON2F definitions earlier.
Are you OK with this patch if I change
- 3E -> 3A in subject and body
- Longsoon -> Loongson in body?
As you maybe noticed, since Loongson is currently the single MIPS
area with contributions, I am trying to strengthen it and ease its
maintenance by adding (and running) more tests.
>
> Huacai
>>
>> [1] commit 8e2d5831e4b ("target/mips: Legalize Loongson insn flags")
>> [2] commit af868995e1b ("target/mips: Add Loongson-3 CPU definition")
>>
>> Reviewed-by: Richard Henderson
>> Signed-off-by: Philippe Mathieu-Daudé
>> ---
>> linux-user/elfload.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/linux-user/elfload.c b/linux-user/elfload.c
>> index 2ba42d8e4bd..5a39a7dc021 100644
>> --- a/linux-user/elfload.c
>> +++ b/linux-user/elfload.c
>> @@ -1023,6 +1023,8 @@ static uint32_t get_elf_hwcap(void)
>>
>> GET_FEATURE_REG_EQU(CP0_Config0, CP0C0_AR, 3, 2, HWCAP_MIPS_R6);
>> GET_FEATURE_REG_SET(CP0_Config3, 1 << CP0C3_MSAP, HWCAP_MIPS_MSA);
>> +GET_FEATURE_INSN(ASE_LMMI, HWCAP_LOONGSON_MMI);
>> +GET_FEATURE_INSN(ASE_LEXT, HWCAP_LOONGSON_EXT);
>>
>> return hwcaps;
>> }
>> --
>> 2.26.2
>
Re: [PATCH 0/4] Use lock guard macros in block
On 02/12/20 10:22, Markus Armbruster wrote: Did this fall through the cracks? Gan Qixin writes: Hi all, I saw some tasks to replace manual lock()/unlock() calls with lock guard macros in BiteSizedTasks. I am very interested in this and modified some of the files under block. Could someone help me check the code? Thanks, Gan Qixin Gan Qixin (4): block/accounting.c: Use lock guard macros block/curl.c: Use lock guard macros block/throttle-groups.c: Use lock guard macros block/iscsi.c: Use lock guard macros block/accounting.c | 32 +-- block/curl.c| 28 block/iscsi.c | 28 +++- block/throttle-groups.c | 48 - 4 files changed, 65 insertions(+), 71 deletions(-) Yes, it did. Reviewed-by: Paolo Bonzini Paolo
Re: [PATCH v2 00/27] Virtio net failover fixes
On Wed, Nov 18, 2020 at 09:37:21AM +0100, Juan Quintela wrote: > Hi I tagged this for after the release. To help make sure this is not lost pls ping me after the release. Thanks! > This is a big rework of the network failover setup. General idea is: > * We don't cache the name of the primary/standby devices > We have several problems there with stale pointers > * After this: > - We can always remove either the primary/standby devices without trouble > - Pluggin/unplugging works > - We go to device opts to see what the failover device are. > Notice that we are plugging/unplugging the device, so it is not critical. > - Once there, I "fixed" managedsave for libvirt (now gives an error instead o= > f just hanging) > * Fields not cached anymore: > - primary_device_dict > - primary_device_opts > - standby_id > - primary_device_id > - primary_dev > * I renamed the should_be_hidden() callback to hide device, but if > people preffer the old name I can leave it. > * Add (some) doc to some functions > * Remove almost 100 lines of code while fixing things. > > Please review. > > Later, Juan. > > Juan Quintela (27): > migration: Network Failover can't work with a paused guest > failover: fix indentantion > failover: Use always atomics for primary_should_be_hidden > failover: primary bus is only used once, and where it is set > failover: Remove unused parameter > failover: Remove external partially_hotplugged property > failover: qdev_device_add() returns err or dev set > failover: Rename bool to failover_primary_hidden > failover: g_strcmp0() knows how to handle NULL > failover: Remove primary_device_opts > failover: remove standby_id variable > failover: Remove primary_device_dict > failover: Remove memory leak > failover: simplify virtio_net_find_primary() > failover: should_be_hidden() should take a bool > failover: Rename function to hide_device() > failover: virtio_net_connect_failover_devices() does nothing > failover: Rename to failover_find_primary_device() > failover: simplify qdev_device_add() failover case > failover: simplify qdev_device_add() > failover: make sure that id always exist > failover: remove failover_find_primary_device() error parameter > failover: split failover_find_primary_device_id() > failover: We don't need to cache primary_device_id anymore > failover: Caller of this two functions already have primary_dev > failover: simplify failover_unplug_primary > failover: Remove primary_dev member > > include/hw/qdev-core.h | 28 ++-- > include/hw/virtio/virtio-net.h | 9 +- > hw/core/qdev.c | 19 +-- > hw/net/virtio-net.c| 298 + > migration/migration.c | 13 ++ > softmmu/qdev-monitor.c | 43 ++--- > 6 files changed, 167 insertions(+), 243 deletions(-) > > --=20 > 2.26.2 >
Re: [PATCH v2 01/27] migration: Network Failover can't work with a paused guest
On Wed, Dec 02, 2020 at 05:31:53AM -0500, Michael S. Tsirkin wrote: > On Wed, Dec 02, 2020 at 10:27:18AM +, Daniel P. Berrangé wrote: > > On Wed, Dec 02, 2020 at 05:13:18AM -0500, Michael S. Tsirkin wrote: > > > On Wed, Nov 18, 2020 at 09:37:22AM +0100, Juan Quintela wrote: > > > > If we have a paused guest, it can't unplug the network VF device, so > > > > we wait there forever. Just change the code to give one error on that > > > > case. > > > > > > > > Signed-off-by: Juan Quintela > > > > > > It's certainly possible but it's management that created > > > this situation after all - why do we bother to enforce > > > a policy? It is possible that management will unpause immediately > > > afterwards and everything will proceed smoothly. > > > > > > Yes migration will not happen until guest is > > > unpaused but the same it true of e.g. a guest that is stuck > > > because of a bug. > > > > That's pretty different behaviour from how migration normally handles > > a paused guest, which is that it is guaranteed to complete the migration > > in as short a time as network bandwidth allows. > > > > Just ignoring the situation I think will lead to surprise apps / admins, > > because the person/entity invoking the migration is not likely to have > > checked wether this particular guest uses net failover or not before > > invoking - they'll just be expecting a paused migration to run fast and > > be guaranteed to complete. > > > > Regards, > > Daniel > > Okay I guess. But then shouldn't we handle the reverse situation too: > pausing guest after migration started but before device was > unplugged? > Thinking of which, I have no idea how we'd handle it - fail pausing guest until migration is cancelled? All this seems heavy handed to me ... > > -- > > |: https://berrange.com -o-https://www.flickr.com/photos/dberrange > > :| > > |: https://libvirt.org -o-https://fstop138.berrange.com > > :| > > |: https://entangle-photo.org-o-https://www.instagram.com/dberrange > > :|
[PULL 4/6] memory: Add IOMMU_NOTIFIER_DEVIOTLB_UNMAP IOMMUTLBNotificationType
From: Eugenio Pérez
This allows us to differentiate between regular IOMMU map/unmap events
and DEVIOTLB unmap. Doing so, notifiers that only need device IOTLB
invalidations will not receive regular IOMMU unmappings.
Adapt intel and vhost to use it.
Signed-off-by: Eugenio Pérez
Reviewed-by: Peter Xu
Reviewed-by: Juan Quintela
Acked-by: Jason Wang
Message-Id: <20201116165506.31315-4-epere...@redhat.com>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
include/exec/memory.h | 7 ++-
hw/i386/intel_iommu.c | 2 +-
hw/virtio/vhost.c | 2 +-
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/include/exec/memory.h b/include/exec/memory.h
index e86b5e92da..521d9901d7 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -97,9 +97,14 @@ typedef enum {
IOMMU_NOTIFIER_UNMAP = 0x1,
/* Notify entry changes (newly created entries) */
IOMMU_NOTIFIER_MAP = 0x2,
+/* Notify changes on device IOTLB entries */
+IOMMU_NOTIFIER_DEVIOTLB_UNMAP = 0x04,
} IOMMUNotifierFlag;
-#define IOMMU_NOTIFIER_ALL (IOMMU_NOTIFIER_MAP | IOMMU_NOTIFIER_UNMAP)
+#define IOMMU_NOTIFIER_IOTLB_EVENTS (IOMMU_NOTIFIER_MAP | IOMMU_NOTIFIER_UNMAP)
+#define IOMMU_NOTIFIER_DEVIOTLB_EVENTS IOMMU_NOTIFIER_DEVIOTLB_UNMAP
+#define IOMMU_NOTIFIER_ALL (IOMMU_NOTIFIER_IOTLB_EVENTS | \
+IOMMU_NOTIFIER_DEVIOTLB_EVENTS)
struct IOMMUNotifier;
typedef void (*IOMMUNotify)(struct IOMMUNotifier *notifier,
diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index 56180b1c43..edc3090f91 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_iommu.c
@@ -2468,7 +2468,7 @@ static bool vtd_process_device_iotlb_desc(IntelIOMMUState
*s,
sz = VTD_PAGE_SIZE;
}
-event.type = IOMMU_NOTIFIER_UNMAP;
+event.type = IOMMU_NOTIFIER_DEVIOTLB_UNMAP;
event.entry.target_as = _dev_as->as;
event.entry.addr_mask = sz - 1;
event.entry.iova = addr;
diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
index 614ccc2bcb..28c7d78172 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vhost.c
@@ -718,7 +718,7 @@ static void vhost_iommu_region_add(MemoryListener *listener,
iommu_idx = memory_region_iommu_attrs_to_index(iommu_mr,
MEMTXATTRS_UNSPECIFIED);
iommu_notifier_init(>n, vhost_iommu_unmap_notify,
-IOMMU_NOTIFIER_UNMAP,
+IOMMU_NOTIFIER_DEVIOTLB_UNMAP,
section->offset_within_region,
int128_get64(end),
iommu_idx);
--
MST
Re: [PATCH 12/15] plugin: propagate errors
Paolo Bonzini writes: > qemu_finish_machine_init currently can only exit QEMU if it fails. > Prepare for giving it proper error propagation, and possibly for > adding a plugin_add monitor command that calls an accelerator > method. > > While at it, make all errors from plugin_load look the same. > > Signed-off-by: Paolo Bonzini Acked-by: Alex Bennée -- Alex Bennée
Re: [PATCH v2] hw/arm/virt enable support for virtio-mem
On Wed, 2 Dec 2020 05:02:57 -0500 "Michael S. Tsirkin" wrote: > On Wed, Nov 25, 2020 at 02:56:59PM +, Jonathan Cameron wrote: > > Cool. I'll run a few more comprehensive tests then send out the > > trivial patch to enable the kernel option + v2 of the qemu support. > > IIUC there will be another version of this patch, right? > Yes. Busy period so might be a little while yet to complete testing before v2. Jonathan
[PULL 3/6] memory: Add IOMMUTLBEvent
From: Eugenio Pérez
This way we can tell between regular IOMMUTLBEntry (entry of IOMMU
hardware) and notifications.
In the notifications, we set explicitly if it is a MAPs or an UNMAP,
instead of trusting in entry permissions to differentiate them.
Signed-off-by: Eugenio Pérez
Reviewed-by: Peter Xu
Reviewed-by: Juan Quintela
Acked-by: Jason Wang
Message-Id: <20201116165506.31315-3-epere...@redhat.com>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
Reviewed-by: Matthew Rosato
Acked-by: David Gibson
---
include/exec/memory.h| 27 ++--
hw/arm/smmu-common.c | 13 +++---
hw/arm/smmuv3.c | 13 +++---
hw/i386/intel_iommu.c| 88 ++--
hw/misc/tz-mpc.c | 32 ---
hw/ppc/spapr_iommu.c | 15 +++
hw/s390x/s390-pci-inst.c | 27 +++-
hw/virtio/virtio-iommu.c | 30 +++---
softmmu/memory.c | 20 -
9 files changed, 143 insertions(+), 122 deletions(-)
diff --git a/include/exec/memory.h b/include/exec/memory.h
index d8456ccf52..e86b5e92da 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -116,6 +116,11 @@ struct IOMMUNotifier {
};
typedef struct IOMMUNotifier IOMMUNotifier;
+typedef struct IOMMUTLBEvent {
+IOMMUNotifierFlag type;
+IOMMUTLBEntry entry;
+} IOMMUTLBEvent;
+
/* RAM is pre-allocated and passed into qemu_ram_alloc_from_ptr */
#define RAM_PREALLOC (1 << 0)
@@ -1326,24 +1331,18 @@ uint64_t
memory_region_iommu_get_min_page_size(IOMMUMemoryRegion *iommu_mr);
/**
* memory_region_notify_iommu: notify a change in an IOMMU translation entry.
*
- * The notification type will be decided by entry.perm bits:
- *
- * - For UNMAP (cache invalidation) notifies: set entry.perm to IOMMU_NONE.
- * - For MAP (newly added entry) notifies: set entry.perm to the
- * permission of the page (which is definitely !IOMMU_NONE).
- *
* Note: for any IOMMU implementation, an in-place mapping change
* should be notified with an UNMAP followed by a MAP.
*
* @iommu_mr: the memory region that was changed
* @iommu_idx: the IOMMU index for the translation table which has changed
- * @entry: the new entry in the IOMMU translation table. The entry
- * replaces all old entries for the same virtual I/O address range.
- * Deleted entries have .@perm == 0.
+ * @event: TLB event with the new entry in the IOMMU translation table.
+ * The entry replaces all old entries for the same virtual I/O address
+ * range.
*/
void memory_region_notify_iommu(IOMMUMemoryRegion *iommu_mr,
int iommu_idx,
-IOMMUTLBEntry entry);
+IOMMUTLBEvent event);
/**
* memory_region_notify_iommu_one: notify a change in an IOMMU translation
@@ -1353,12 +1352,12 @@ void memory_region_notify_iommu(IOMMUMemoryRegion
*iommu_mr,
* notifies a specific notifier, not all of them.
*
* @notifier: the notifier to be notified
- * @entry: the new entry in the IOMMU translation table. The entry
- * replaces all old entries for the same virtual I/O address range.
- * Deleted entries have .@perm == 0.
+ * @event: TLB event with the new entry in the IOMMU translation table.
+ * The entry replaces all old entries for the same virtual I/O address
+ * range.
*/
void memory_region_notify_iommu_one(IOMMUNotifier *notifier,
- IOMMUTLBEntry *entry);
+IOMMUTLBEvent *event);
/**
* memory_region_register_iommu_notifier: register a notifier for changes to
diff --git a/hw/arm/smmu-common.c b/hw/arm/smmu-common.c
index 88d2c454f0..405d5c5325 100644
--- a/hw/arm/smmu-common.c
+++ b/hw/arm/smmu-common.c
@@ -465,14 +465,15 @@ IOMMUMemoryRegion *smmu_iommu_mr(SMMUState *s, uint32_t
sid)
/* Unmap the whole notifier's range */
static void smmu_unmap_notifier_range(IOMMUNotifier *n)
{
-IOMMUTLBEntry entry;
+IOMMUTLBEvent event;
-entry.target_as = _space_memory;
-entry.iova = n->start;
-entry.perm = IOMMU_NONE;
-entry.addr_mask = n->end - n->start;
+event.type = IOMMU_NOTIFIER_UNMAP;
+event.entry.target_as = _space_memory;
+event.entry.iova = n->start;
+event.entry.perm = IOMMU_NONE;
+event.entry.addr_mask = n->end - n->start;
-memory_region_notify_iommu_one(n, );
+memory_region_notify_iommu_one(n, );
}
/* Unmap all notifiers attached to @mr */
diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
index 273f5f7dce..bbca0e9f20 100644
--- a/hw/arm/smmuv3.c
+++ b/hw/arm/smmuv3.c
@@ -800,7 +800,7 @@ static void smmuv3_notify_iova(IOMMUMemoryRegion *mr,
uint8_t tg, uint64_t num_pages)
{
SMMUDevice *sdev = container_of(mr, SMMUDevice, iommu);
-IOMMUTLBEntry entry;
+IOMMUTLBEvent event;
uint8_t granule = tg;
if (!tg) {
@@ -823,12 +823,13 @@ static void
Re: [PULL 000/113] First batch of misc (i386, kernel-doc, memory, vl.c) changes for QEMU 6.0
Patchew URL: https://patchew.org/QEMU/20201202080849.4125477-1-pbonz...@redhat.com/ Hi, This series seems to have some coding style problems. See output below for more information: Type: series Message-id: 20201202080849.4125477-1-pbonz...@redhat.com Subject: [PULL 000/113] First batch of misc (i386, kernel-doc, memory, vl.c) changes for QEMU 6.0 === 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 * [new tag] patchew/20201202080849.4125477-1-pbonz...@redhat.com -> patchew/20201202080849.4125477-1-pbonz...@redhat.com * [new tag] patchew/20201202101042.11967-1-luwei.k...@intel.com -> patchew/20201202101042.11967-1-luwei.k...@intel.com Switched to a new branch 'test' a4add9d scripts: kernel-doc: remove unnecesssary change wrt Linux a12200d Revert "docs: temporarily disable the kernel-doc extension" f913504 scripts: kernel-doc: use :c:union when needed 0948494 scripts: kernel-doc: split typedef complex regex 69e58d5 scripts: kernel-doc: fix typedef parsing 729a65a Revert "kernel-doc: Handle function typedefs that return pointers" d74922c Revert "kernel-doc: Handle function typedefs without asterisks" 2cfa827 scripts: kernel-doc: try to use c:function if possible 49b1924 scripts: kernel-doc: fix line number handling 599bd60 scripts: kernel-doc: allow passing desired Sphinx C domain dialect ccd0a99 scripts: kernel-doc: don't mangle with parameter list c8041c1 scripts: kernel-doc: fix typedef identification 6619dbb scripts: kernel-doc: reimplement -nofunction argument 871d904 scripts: kernel-doc: fix troubles with line counts 2c31789 scripts: kernel-doc: use a less pedantic markup for funcs on Sphinx 3.x 47720be scripts: kernel-doc: make it more compatible with Sphinx 3.x 34e04d1 Revert "kernel-doc: Use c:struct for Sphinx 3.0 and later" f8d8ba0 Revert "scripts/kerneldoc: For Sphinx 3 use c:macro for macros with arguments" c8cf35b scripts: kernel-doc: add support for typedef enum ef6d10d kernel-doc: add support for cacheline_aligned attribute 5a89198 kernel-doc: include line numbers for function prototypes 98f7e32 scripts/kernel-doc: optionally treat warnings as errors c164b21 scripts/kernel-doc: handle function pointer prototypes 8176521 scripts/kernel-doc: parse __ETHTOOL_DECLARE_LINK_MODE_MASK 8bb93e4 Replace HTTP links with HTTPS ones: documentation 16067ba scripts: kernel-doc: accept blank lines on parameter description 1069fce scripts: kernel-doc: accept negation like !@var 901c775 scripts: kernel-doc: proper handle @foo->bar() ae759fa scripts/kernel-doc: Add support for named variable macro arguments ca93033 kernel-doc: add support for cacheline_aligned_in_smp attribute 3222311 kernel-doc: fix processing nested structs with attributes 172c67f docs: temporarily disable the kernel-doc extension 34ec2d3 config-file: move -set implementation to vl.c b3b2b33 vl: clean up -boot variables 0df7ae4 vl: remove serial_max_hds b2d4a21 vl: extract softmmu/rtc.c 56b895b vl: extract machine done notifiers 9077c47 vl: extract softmmu/datadir.c cd666a4 hmp: introduce cmd_available ca5aed00 vl: start VM via qmp_cont 64d36f6 migration, vl: start migration via qmp_migrate_incoming c4ff80b vl: move -global check earlier 2c5bb35 vl: initialize displays before preconfig loop add091a vl: separate qemu_resolve_machine_memdev f77baee vl: separate qemu_apply_machine_options ba665b8 vl: separate qemu_create_machine efd7675 vl: separate qemu_create_late_backends 6558486 vl: separate qemu_create_early_backends 25838a4 vl: move CHECKPOINT_INIT after preconfig ac306e3 vl: extract default devices to separate functions 847be0b vl: load plugins as late as possible edaf366 vl: create "-net nic -net user" default earlier aab2f9e qemu-option: restrict qemu_opts_set to merge-lists QemuOpts 87e13df vl: extract various command line desugaring snippets to a new function 4e2dfcb vl: preconfig and loadvm are mutually exclusive 6a2d4ef vl: extract various command line validation snippets to a new function 3c7c482 vl: move prelaunch part of qemu_init to new functions 6ac7d06 vl: extract qemu_init_subsystems 60ee017 vl: move various initialization routines out of qemu_init 020c4c9 vl: split various early command line options to a separate function ab08620 vl: remove bogus check e8e842d vl: extract validation of -smp to machine.c 833cfa8 treewide: do not use short-form boolean options 98cfa88 hw/char/serial: Clean up unnecessary code 510df76 make ram_size local to vl.c d84de6d sparc64: do not use ram_size global 00ebf53 s390x: do not use ram_size global 9ff7cc4 riscv: do not use ram_size global 98cf13e ppc: do not use ram_size global ed74abd nios2: do not use ram_size global d00dcd5 moxie: do not use ram_size
Re: [PATCH 18/23] tests/docker: auto-generate centos7 with lcitool
Hi, > +RUN echo 'skip_missing_names_on_install=0' >> /etc/yum.conf && \ > +yum install -y epel-release && \ > +yum install -y centos-release-xen-48 && \ > +yum update -y && \ > +yum install -y \ > +SDL2-devel \ More a comment for lcitool I guess: rpmbuild generates provides entries for pkg-config files, so 'SDL2-devel' can be replaced with 'pkgconfig(sdl2)'. Which should work fine on any rpm-based distro, no matter how the package is actually named. Dunno whenever apt/deb has something simliar or whenever that actually can simplify things for lcitool ... take care, Gerd
Re: [PATCH 00/18] qapi/qom: QAPIfy object-add
On 02/12/20 11:38, Kevin Wolf wrote: Am 02.12.2020 um 10:30 hat Paolo Bonzini geschrieben: On 01/12/20 23:08, Eduardo Habkost wrote: Properties are only a useful concept if they have a use. If -object/object_add/object-add can do the same job without properties, properties are not needed anymore. Do you mean "not needed for -object anymore"? Properties are still used by internal C code (esp. board code), -device/device_add, -machine, -cpu, and debugging commands (like "info qtree" and qom-list/qom-get/qom-set). Yes. Are internal uses mostly just right after object creation, or do we make a lot of use of them during runtime? Not "a lot" but enough to be nasty. There are a couple uses of "well-known" QOM properties (e.g. to access the RTC time or the balloon stats), plus "info qtree". Paolo
Re: check-tcg errors (build-user, build-user-plugins) again
Claudio Fontana writes: > On 12/2/20 12:16 PM, Alex Bennée wrote: >> >> Claudio Fontana writes: >> >>> Hi Alex and all, >>> >>> when trying to use check-tcg (master), I am getting often these errors: >>> >>> $ ../configure --disable-system --disable-tools >>> >>> $ make -j12 check-tcg >>> >>> ERRO[] cannot find mappings for user claudio: No subgid ranges found >>> for group "claudio" in /etc/subgid >>> ERRO[] cannot find mappings for user claudio: No subgid ranges found >>> for group "claudio" in /etc/subgid >>> ERRO[] cannot find mappings for user claudio: No subgid ranges found >>> for group "claudio" in /etc/subgid >>> Trying to pull registry.gitlab.com/qemu-project/qemu/qemu/debian11... >>> Trying to pull >>> registry.gitlab.com/qemu-project/qemu/qemu/fedora-cris-cross... >>> Trying to pull registry.gitlab.com/qemu-project/qemu/qemu/debian10... >>> ERRO[] cannot find mappings for user claudio: No subgid ranges found >>> for group "claudio" in /etc/subgid >>> >>> [...] >>> TESTlinux-test on x86_64 >>> timeout: failed to run command >>> ‘/home/claudio/git/qemu/build/qemu-x86_64’timeout: : No such file or >>> directoryfailed to run command ‘/home/claudio/git/qemu/build/qemu-x86_64’ >>> >>> [...] >>> >>> >>> Is there some pre-configuration on the host necessary to be able to >>> run check-tcg? >> >> There shouldn't be but those errors remind me of some of the tweaks I >> had to make to me Gentoo system when using podman (instead of docker). >> In the end I think I just ended up adding the lines: >> >> alex:10:65536 >> >> to /etc/subgid and /etc/subgid- >> >> Marc-André may have some better pointers as he added podman support to >> the builder scripts. > > > I did that and things seem a bit better, but still a lot of errors: > > > 63 ../sysdeps/x86_64/start.S: No such file or directory. > > Error: error creating build container: The following failures happened while > trying to pull image specified by "debian:bullseye-slim" based on search > registries in /etc/containers/registries.conf: > * "localhost/debian:bullseye-slim": Error initializing source > docker://localhost/debian:bullseye-slim: error pinging docker registry > localhost: Get https://localhost/v2/: dial tcp [::1]:443: connect: connection > refused > * "docker.io/library/debian:bullseye-slim": Error committing the finished > image: error adding layer with blob > "sha256:ae63fcbbc3b289e425e4c8840ccde4314f4a060cbc0345e6871a28bdc72f6fe8": > Error processing tar file(exit status 1): there might not be enough IDs > available in the namespace (requested 0:42 for /etc/gshadow): lchown > /etc/gshadow: invalid argument > Traceback (most recent call last): > File "/home/claudio/git/qemu-pristine/qemu/tests/docker/docker.py", line > 709, in > sys.exit(main()) > File "/home/claudio/git/qemu-pristine/qemu/tests/docker/docker.py", line > 705, in main > return args.cmdobj.run(args, argv) > File "/home/claudio/git/qemu-pristine/qemu/tests/docker/docker.py", line > 501, in run > extra_files_cksum=cksum) > File "/home/claudio/git/qemu-pristine/qemu/tests/docker/docker.py", line > 354, in build_image > quiet=quiet) > File "/home/claudio/git/qemu-pristine/qemu/tests/docker/docker.py", line > 244, in _do_check > return subprocess.check_call(self._command + cmd, **kwargs) > File "/usr/lib64/python3.6/subprocess.py", line 311, in check_call > raise CalledProcessError(retcode, cmd) > > > [...] > Error: error pulling image > "registry.gitlab.com/qemu-project/qemu/qemu/fedora-cris-cross": unable to > pull registry.gitlab.com/qemu-project/ > I'm guessing this can be fixed by adding gitlab to /etc/containers/registries.conf I'll see if I can resurrect my podman setup because it was working before we added the caching from gitlab. > [...] > > > >> >> The main difference between the images on the registry and the local >> versions is most add the current user so there is a clean mapping >> between the container user and the host file-system. It's the last step >> of the build so we still use the cached layers from the registry >> versions. >> >>> I see these errors in gitlab also for >>> >>> build-user >>> build-user-plugin >>> >>> Maybe this is what Philippe mentioned before though, that this is >>> expected at the moment due to a temporary Meson shortcoming? >> >> That is odd - I'm not seeing anything like that on the master builds: >> >> https://gitlab.com/qemu-project/qemu/-/jobs/883985106 >> https://gitlab.com/qemu-project/qemu/-/jobs/883985113 >> >> AFAIK GitLab is still using Docker to build it's containers (albeit with >> BUILDKIT enabled). > > > I am running again on gitlab the master branch, maybe there is something I > need to fix, but to do that I need to enable check-tcg successfully I think. > > Thanks! > > Claudio > >> >>> >>> Ciao, >>> >>> Claudio >> >> -- Alex Bennée
Re: [PATCH 06/15] arc: TCG instruction definitions
Hi Richard,
Thank you so much for your reviews.
I will start working on improving the code straight away to try to
minimize waiting times.
However lets just address the elephant in the room.
Indeed we have the TCG definitions being generated.
However we are very serious about wanting to upstream our port and we
will certainly maintain this code.
I totally understand your concerns with generated code.
To explain our decision, we have an internal database that we are able
to describe the architecture and map encoding with hw semantics, and
for the sake of saving us debug time generating each and every
instruction, we use it to generate both the TCG and instruction
decoding tables that you have already reviewed.
This tool is not only used in QEmu but through all our tools code,
allowing us to cross validate the content of the database.
Considering our situation and current state of the port, what would
you think is a reasonable compromise?
Once again thanks for the reviews.
Best regards,
Cupertino
On Tue, Dec 1, 2020 at 11:09 PM Richard Henderson
wrote:
>
> On 11/11/20 10:17 AM, cupertinomira...@gmail.com wrote:
> > +case 0x09:
> > +/* (N & V & !Z) | (!N & !V & !Z) */
>
> This is xnor(N, V) & !Z, and since as you now know xnor = eqv, you can perform
> this in just two steps.
>
> tcg_gen_eqv_tl(ret, cpu_Nf, cpu_Vf);
> tcg_gen_andc_tl(ret, ret, cpu_Zf);
>
> > +/* GE */
> > +case 0x0A:
> > +/* (N & V) | (!N & !V) */
>
> xnor(N, V)
>
> > +/* LT */
> > +case 0x0B:
> > +/* (N & !V) | (!N & V) */
>
> xor(N, V)
>
> > +/* LE */
> > +case 0x0C:
> > +/* Z | (N & !V) | (!N & V) */
>
> xor(N, V) | Z
>
> > +/* HI */
> > +case 0x0D:
> > +/* !C & !Z */
> > +tcg_gen_xori_tl(nC, cpu_Cf, 1);
> > +tcg_gen_xori_tl(nZ, cpu_Zf, 1);
> > +
> > +tcg_gen_and_tl(ret, nC, nZ);
>
> !A & !B -> !(A | B), so one fewer xor.
>
> > +/* PNZ */
> > +case 0x0F:
> > +/* !N & !Z */
>
> Likewise.
>
> > +void arc_gen_set_memory(DisasCtxt *ctx, TCGv vaddr, int size,
> > +TCGv src, bool sign_extend)
> > +{
> > +switch (size) {
> > +case 0x00:
> > +tcg_gen_qemu_st_tl(src, vaddr, MEMIDX, MO_UL);
> > +break;
>
> Surely you'd put all of this size+sign-extend mapping into a table and issue
> just one tcg_gen_qemu_st_tl.
>
> > +void arc_gen_get_memory(DisasCtxt *ctx, TCGv dest, TCGv vaddr,
> > +int size, bool sign_extend)
> > +{
>
> And re-use the same table here, it would appear.
>
> > +void arc_gen_no_further_loads_pending(DisasCtxt *ctx, TCGv ret)
> > +{
> > +tcg_gen_movi_tl(ret, 1);
> > +}
>
> Huh? A missing TODO, perhaps?
>
> > +extern bool enabled_interrupts;
>
> Race condition. What is a global variable doing being set by a translation
> thread?
>
>
> > +void
> > +arc_gen_execute_delayslot(DisasCtxt *ctx, TCGv bta, TCGv take_branch)
> > +{
> > +static int in_delay_slot = false;
>
> And another one. Surely these belong in DisasContext.
>
> > +
> > +assert(ctx->insn.limm_p == 0 && !in_delay_slot);
> > +
> > +if (ctx->insn.limm_p == 0 && !in_delay_slot) {
> > +in_delay_slot = true;
> > +uint32_t cpc = ctx->cpc;
> > +uint32_t pcl = ctx->pcl;
> > +insn_t insn = ctx->insn;
> > +
> > +ctx->cpc = ctx->npc;
> > +ctx->pcl = ctx->cpc & 0xfffc;
> > +
> > +++ctx->ds;
> > +
> > +TCGLabel *do_not_set_bta_and_de = gen_new_label();
> > +tcg_gen_brcondi_i32(TCG_COND_NE, take_branch, 1,
> > do_not_set_bta_and_de);
> > +/*
> > + * In case an exception should be raised during the execution
> > + * of delay slot, bta value is used to set erbta.
> > + */
> > +tcg_gen_mov_tl(cpu_bta, bta);
> > +/* We are in a delay slot */
> > +tcg_gen_mov_tl(cpu_DEf, take_branch);
> > +gen_set_label(do_not_set_bta_and_de);
> > +
> > +tcg_gen_movi_tl(cpu_is_delay_slot_instruction, 1);
> > +
> > +/* Set the pc to the next pc */
> > +tcg_gen_movi_tl(cpu_pc, ctx->npc);
> > +/* Necessary for the likely call to restore_state_to_opc() */
> > +tcg_gen_insn_start(ctx->npc);
>
> Wow, this looks wrong.
>
> It doesn't work with icount or single-stepping. You need to be able to begin
> a
> TB at any instruction, including a delay slot.
>
> You should have a look at some of the other targets that handle this, e.g.
> openrisc or sparc. Since you've got NPC already, for looping, sparc is
> probably the better match.
>
> There should be no reason why you'd need to emit insn_start outside of
> arc_tr_insn_start.
>
> > +void arc_gen_set_register(enum arc_registers reg, TCGv value)
> > +{
> > +switch (reg) {
> > +case R_SP:
> > +tcg_gen_mov_i32(cpu_sp, value);
> > +break;
> > +case R_STATUS32:
> > +gen_helper_set_status32(cpu_env, value);
>
> Lots of changes to status imply a significant change to
Re: [PATCH v2 1/8] libvhost-user: replace qemu/bswap.h with glibc endian.h
On Wed, Nov 25, 2020 at 02:06:33PM +0400, marcandre.lur...@redhat.com wrote: > From: Marc-André Lureau > > Signed-off-by: Marc-André Lureau > Reviewed-by: Dr. David Alan Gilbert > Reviewed-by: Stefan Hajnoczi > --- > contrib/libvhost-user/libvhost-user.c | 77 ++- > 1 file changed, 40 insertions(+), 37 deletions(-) Reviewed-by: Stefan Hajnoczi signature.asc Description: PGP signature
Re: [PATCH v2 5/8] libvhost-user: make it a meson subproject
On Wed, Nov 25, 2020 at 02:06:37PM +0400, marcandre.lur...@redhat.com wrote:
> diff --git a/meson.build b/meson.build
> index 5062407c70..1b14998691 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1476,7 +1476,12 @@ trace_events_subdirs += [
>'util',
> ]
>
> -subdir('contrib/libvhost-user')
> +vhost_user = not_found
> +if 'CONFIG_VHOST_USER' in config_host
> + libvhost_user = subproject('libvhost-user')
> + vhost_user = libvhost_user.get_variable('vhost_user_dep')
> +endif
> +
> subdir('qapi')
> subdir('qobject')
> subdir('stubs')
I wonder if qemu-system-ARCH and qemu-storage-daemon targets will break
with ./configure --disable-vhost-user because of util/meson.build:
util_ss.add(when: 'CONFIG_LINUX', if_true: [
files('vhost-user-server.c'), vhost_user
])
Stefan
signature.asc
Description: PGP signature
Re: check-tcg errors (build-user, build-user-plugins) again
On 12/2/20 12:25 PM, Claudio Fontana wrote: > On 12/2/20 12:16 PM, Alex Bennée wrote: >> Claudio Fontana writes: >>> Is there some pre-configuration on the host necessary to be able to >>> run check-tcg? >> >> There shouldn't be but those errors remind me of some of the tweaks I >> had to make to me Gentoo system when using podman (instead of docker). >> In the end I think I just ended up adding the lines: >> >> alex:10:65536 >> >> to /etc/subgid and /etc/subgid- >> >> Marc-André may have some better pointers as he added podman support to >> the builder scripts. Not sure if helpful, but what worked for me is remove podman and use docker... For sure I'm not testing podman, enough to deal with docker. > I did that and things seem a bit better, but still a lot of errors: > > > 63 ../sysdeps/x86_64/start.S: No such file or directory. > > Error: error creating build container: The following failures happened while > trying to pull image specified by "debian:bullseye-slim" based on search > registries in /etc/containers/registries.conf: > * "localhost/debian:bullseye-slim": Error initializing source > docker://localhost/debian:bullseye-slim: error pinging docker registry > localhost: Get https://localhost/v2/: dial tcp [::1]:443: connect: connection > refused > * "docker.io/library/debian:bullseye-slim": Error committing the finished > image: error adding layer with blob > "sha256:ae63fcbbc3b289e425e4c8840ccde4314f4a060cbc0345e6871a28bdc72f6fe8": > Error processing tar file(exit status 1): there might not be enough IDs > available in the namespace (requested 0:42 for /etc/gshadow): lchown > /etc/gshadow: invalid argument > Traceback (most recent call last): > File "/home/claudio/git/qemu-pristine/qemu/tests/docker/docker.py", line > 709, in > sys.exit(main()) > File "/home/claudio/git/qemu-pristine/qemu/tests/docker/docker.py", line > 705, in main > return args.cmdobj.run(args, argv) > File "/home/claudio/git/qemu-pristine/qemu/tests/docker/docker.py", line > 501, in run > extra_files_cksum=cksum) > File "/home/claudio/git/qemu-pristine/qemu/tests/docker/docker.py", line > 354, in build_image > quiet=quiet) > File "/home/claudio/git/qemu-pristine/qemu/tests/docker/docker.py", line > 244, in _do_check > return subprocess.check_call(self._command + cmd, **kwargs) > File "/usr/lib64/python3.6/subprocess.py", line 311, in check_call > raise CalledProcessError(retcode, cmd) > > > [...] > Error: error pulling image > "registry.gitlab.com/qemu-project/qemu/qemu/fedora-cris-cross": unable to > pull registry.gitlab.com/qemu-project/ Maybe you need "use explicit docker.io registry" from Daniel: https://www.mail-archive.com/qemu-devel@nongnu.org/msg763484.html [...]
Re: [PATCH v2 8/8] .gitlab-ci: add build-libvhost-user
On 11/25/20 11:06 AM, marcandre.lur...@redhat.com wrote: > From: Marc-André Lureau > > Signed-off-by: Marc-André Lureau > --- > .gitlab-ci.yml | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml > index d0173e82b1..e517506c35 100644 > --- a/.gitlab-ci.yml > +++ b/.gitlab-ci.yml > @@ -455,6 +455,17 @@ check-dco: >variables: > GIT_DEPTH: 1000 > > +build-libvhost-user: > + stage: build > + image: $CI_REGISTRY_IMAGE/qemu/fedora:latest > + before_script: > +- dnf install -y meson ninja-build > + script: > +- mkdir subprojects/libvhost-user/build > +- cd subprojects/libvhost-user/build > +- meson > +- ninja > + It would be better to have this job in a separate Yaml so you can cover it in MAINTAINERS. > pages: >image: $CI_REGISTRY_IMAGE/qemu/ubuntu2004:latest >stage: test >
Re: [PATCH 24/29] migration, vl: start migration via qmp_migrate_incoming
* Paolo Bonzini (pbonz...@redhat.com) wrote:
> On 20/11/20 16:34, Igor Mammedov wrote:
> > > qapi_event_send_migration(MIGRATION_STATUS_SETUP);
> > > -if (!strcmp(uri, "defer")) {
> > > -deferred_incoming_migration(errp);
> > > -} else if (strstart(uri, "tcp:", ) ||
> > > - strstart(uri, "unix:", NULL) ||
> > > - strstart(uri, "vsock:", NULL)) {
> > considering the last hunk does won't call qmp_migrate_incoming
> > if 'defer' was used, wouldn't we will lose QAPI event here?
> > not sure how important it to users,
>
> Hmm yeah that's true. That might even be considered a bugfix (no setup is
> done until the "real" migrate-incoming command), but I can also add the
> event manually in qemu_init.
>
> (Libvirt doesn't use the SETUP case of the event but that's of course only
> part of the story).
I'm more worried about how this stops a repeated 'migrate incoming'
or a 'migrate_incoming' that's issued following a qemu that's been
started with -incoming tcp:... but which a socket hasn't yet connected
to.
Dave
> Paolo
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH v2 3/8] libvhost-user: remove qemu/compiler.h usage
On Wed, Nov 25, 2020 at 02:06:35PM +0400, marcandre.lur...@redhat.com wrote: > From: Marc-André Lureau > > Signed-off-by: Marc-André Lureau > --- > contrib/libvhost-user/libvhost-user.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) Reviewed-by: Stefan Hajnoczi signature.asc Description: PGP signature
Re: [PATCH] hw/pci-host/pam: Replace magic number by PAM_REGIONS_COUNT definition
On Wed, Dec 2, 2020 at 2:24 PM Philippe Mathieu-Daudé wrote: > > While this change helps triskaidekaphobic developers, it > is a good practice to avoid magic values and using constant > definitions instead. > > Introduce the PAM_REGIONS_COUNT and use it. No logical change. > > Signed-off-by: Philippe Mathieu-Daudé > --- > include/hw/pci-host/i440fx.h | 2 +- > include/hw/pci-host/pam.h| 2 ++ > include/hw/pci-host/q35.h| 2 +- > hw/pci-host/pam.c| 2 +- > hw/pci-host/q35.c| 2 +- > 5 files changed, 6 insertions(+), 4 deletions(-) :D Reviewed-by: Julia Suvorova
Re: [PATCH 00/18] qapi/qom: QAPIfy object-add
Am 02.12.2020 um 14:54 hat Eduardo Habkost geschrieben:
> On Wed, Dec 02, 2020 at 02:26:44PM +0100, Paolo Bonzini wrote:
> > On 02/12/20 13:51, Eduardo Habkost wrote:
> > > > > I'm liking the direction this is taking. However, I would still
> > > > > like to have a clearer and feasible plan that would work for
> > > > > -device, -machine, and -cpu.
> > > >
> > > > -cpu is not a problem since it's generally created with a static
> > > > configuration (now done with global properties, in the future it could
> > > > be a
> > > > struct).
> > >
> > > It is a problem if it requires manually converting existing code
> > > defining CPU properties and we don't have a transition plan.
> >
> > We do not have to convert everything _if_ for some objects there are good
> > reasons to do programmatically-generated properties. CPUs might be one of
> > those cases (or if we decide to convert them, they might endure some more
> > code duplication than other devices because they have so many properties).
>
> OK, we just need to agree on what the transition will look like
> when we do it. I think we should put as much care into
> transition/glue infrastructure as we put into the new
> infrastructure.
>
>
> >
> > > Would a -device conversion also involve non-user-creatable
> > > devices, or would we keep existing internal usage of QOM
> > > properties?
> > >
> > > Even if it's just for user-creatable devices, getting rid of QOM
> > > property usage in devices sounds like a very ambitious goal. I'd
> > > like us to have a good transition plan, in addition to declaring
> > > what's our ideal end goal.
> >
> > For user-creatable objects Kevin is doing work in lockstep on all classes;
> > but once we have the infrastructure for QAPI object configuration schemas we
> > can proceed in the other direction and operate on one device at a time.
> >
> > With some handwaving, something like (see create_unimplemented_device)
> >
> > DeviceState *dev = qdev_new(TYPE_UNIMPLEMENTED_DEVICE);
> >
> > qdev_prop_set_string(dev, "name", name);
> > qdev_prop_set_uint64(dev, "size", size);
> > sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), _fatal);
> >
> > might become something like
> >
> > { 'object': 'unimplemented-device',
> > 'config': {
> > 'name': 'str',
> > 'size': 'size'
> > },
> > }
> >
> > DeviceState *dev = qapi_Unimplemented_new(&(
> > (UnimplementedDeviceOptions) {
> > .name = name,
> > .size = size
> > }, _fatal);
> > object_unref(dev);
> >
> > (i.e. all typesafe!) and the underlying code would be something like
> [...]
> >
>
> Looks nice as end goal. Then, these are a few questions I would
> have about the transition plan:
>
> Would it require changing both device implementation and device
> users in lockstep? Should we have a compatibility layer to allow
> existing qdev_new()+qdev_prop_set_*() code to keep working after
> the devices are converted to the new system? If not, why not?
Technically, it doesn't strictly require a lockstep update. You can have
two code paths leading to a fully initialised device, one being the
traditional way of setting properties and finally calling dc->realize,
the other being a new method that takes the configuration in its
parameters and also sets dev->realized = true at the end.
If at all possible, I would however prefer a lockstep update because
having two paths is a weird intermediate state and the code paths could
easily diverge. Keeping the old way around for a device also means that
property setters are still doing two different jobs (initial
configuration and updates at runtime).
> If we add a compatibility layer, is the end goal to convert all
> existing qdev_new() users to the new system? If yes, why? If
> not, why not?
My personal goal is covering -object and -device, i.e. the external
interfaces. Converting purely internally created devices is not as
interesting (especially as long as we focus only on object creation),
but might be desirable for consistency.
> What about subclasses? Would base classes need to be converted
> in lockstep with all subclasses? How would the transition
> process of (e.g.) PCI devices look like?
I don't think so.
If you want to convert base classes first, you may need to take the
path shown above where both initialisation paths coexist while the
children are converted because instantiation of a child class involves
setting properties of the base class. So you can only restrict these
properties to runtime-only after all children have been converted.
The other way around might be easier: You will need to describe the
properties of base classes in the QAPI schema from the beginning, but
that doesn't mean that their initialisation code has to change just yet.
The child classes will need to forward the part of their configuration
that belongs to the base class. The downside is that this code will have
to be changed again
Re: [PATCH v1 1/1] security-process: update process information
On Mon, Nov 30, 2020 at 07:19:07PM +0530, P J P wrote: > From: Prasad J Pandit > > We are about to introduce a qemu-security mailing list to report > and triage QEMU security issues. > > Update the QEMU security process web page with new mailing list > and triage details. > > Signed-off-by: Prasad J Pandit > --- > contribute/security-process.md | 134 - > 1 file changed, 80 insertions(+), 54 deletions(-) > +* List members follow a **responsible disclosure** policy. Any non-public > + information you share about security issues, is kept confidential within > the > + respective affiliated companies. Such information shall not be passed on to > + any third parties, including Xen Security Project, without your prior > + permission. Why this explicit note about the Xen project ? What if we decide to want a member of the Xen security team on the QEMU security mailing list so that we can collaborate on triage ? Perhaps Any non-public information you share about security issues, is kept confidential between members of the QEMU security team, and a minimal number of supporting staff in their affliated companies. Information will not be disclosed to other third party organizations/individuals without prior permission from the reporter > +* We aim to process security issues within maximum of **60 days**. That is > not > + to say that issues will remain private for 60 days, nope. After the > triaging > + step above > +- If issue is found to be less severe, an upstream public bug (or an > + issue) will be created immediately. No need to repeat "or an issue". I think it would read more clearly as - If the severity of the issue is sufficiently low, an upstream public bug may be created immediately. > +- If issue is found to be severe, an embargo process below is followed, > + and public bug (or an issue) will be opened at the end of the set > + embargo period. - If the severity of the issue requires co-ordinated disclosure at a future date, then the embargo process below is followed, and public bug will be opened at the end of the set embargo period. Somewhere around here is probably a good place to link to: https://www.qemu.org/docs/master/system/security.html which describes why we'll consider some things to be not security issues > ### Publication embargo > > -If a security issue is reported that is not already publicly disclosed, an > -embargo date may be assigned and communicated to the reporter. Embargo > -periods will be negotiated by mutual agreement between members of the > security > -team and other relevant parties to the problem. Members of the security > contact > -list agree not to publicly disclose any details of the security issue until > -the embargo date expires. > +* If a security issue is reported that is not already public and is severe > + enough, an embargo date may be assigned and communicated to the > + reporter(s). * If a security issue is reported that is not already public and its severity requires coordinated disclosure, an embargo date may be assigned and communicated to the reporter(s). > +* Embargo periods will be negotiated by mutual agreement between reporter(s), > + members of the security list and other relevant parties to the problem. > + Such embargo period is generally upto [2 > weeks](https://oss-security.openwall.org/wiki/mailing-lists/distros). "The preferred embargo period will be upto 2 weeks, however, longer embargoes can be negotiated if the severity of the issues requires it." > + > +* Members of the security list agree not to publicly disclose any details of > + an embargoed security issue until its embargo date expires. > > ### CVE allocation Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [PATCH v11 2/7] block/nbd.c: Add yank feature
On Wed, 2 Dec 2020 15:18:48 +0300 Vladimir Sementsov-Ogievskiy wrote: > 15.11.2020 14:36, Lukas Straub wrote: > > Register a yank function which shuts down the socket and sets > > s->state = NBD_CLIENT_QUIT. This is the same behaviour as if an > > error occured. > > > > Signed-off-by: Lukas Straub > > Acked-by: Stefan Hajnoczi > > Hi! Could I ask, what's the reason for qatomic_load_acquire access to > s->state? Is there same bug fixed? Or is it related somehow to new feature? > Hi, This is for the new feature, as the yank function runs in a separate thread. Regards, Lukas Straub -- pgpjxfyYqOi2q.pgp Description: OpenPGP digital signature
virtiofsd-rs: A rust virtiofs daemon
Hi, Sergio has been working on virtiofsd-rs, a virtiofs daemon written in rust, and which can be found at: https://gitlab.com/virtio-fs/virtiofsd-rs It started life originally as part of the crosvm project, got ported to vhost-user as part of the Cloud Hypervisor project, and has now been split out. While the C version of virtiofsd isn't going away for now, the hope is to stabilise virtiofsd-rs, add some missing features and start preferentially adding new features and new work onto the Rust version rather than the C version. So please try it, and let the list (and Sergio!) know how you get on. Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH 00/18] qapi/qom: QAPIfy object-add
On 02/12/20 11:27, Kevin Wolf wrote: Declaring read-only QOM properties is trivial. Trivial sounds like it's something the computer should be doing. Possibly, but not necessarily. There's always a cost to automatic code generation. If things are _too_ trivial and easy to get right, the cost of automatic code generation exceeds the cost of doing things by hand. You pretty much proved that ucc->complete is hard enough to get right, that it benefits from code generation. But I am a bit more conservative about extending that to the rest of QOM. I'm just worried about having yet another incomplete transition. Would you really feel at home in a QEMU without incomplete transitions? One can always dream. :) But since you had already posted RFC patches a while ago to address this, I considered it solved. Yup, I posted the non-RFC today. 1. This series (mostly for documentation and introspection) 2. -object and HMP object_add (so that we get QAPI's validation, and to make sure that forgetting to update the schema means that the new options just doesn't work) 3. Create a separate 'object' entity in QAPI, generate ucc->complete implementations that call a create function in the C source code with type-specific parameters (like QMP command handlers) If we agree on all of these that's already a pretty good place to be in. The decreasing length of the replies to the thread suggests that we are. I wouldn't mind an example of (3) that is hand-coded and may only work for one object type (even a simple one such as iothread), to show what the generated QAPI code would look like. It's not a blocker as far as I am concerned, but it would be nice. More important, Markus and John should agree with the plan before (1) is committed. That may also require the aforementioned example, but it's up to them. What's still open: Should QAPI cover run-time properties, too? Should run-time properties even exist at all in the final state? What is the exact QAPI representation of everything? (The last one includes that I need to have a closer look at how QAPI can best be taught about inheritance.) Run-time properties will exist but they will probably be cut down substantially, and most of them will be read-only (they already are as far as external code is concerned, i.e. they have a setter but qom-set always fails because it's called too late). Paolo
Re: [PATCH 00/18] qapi/qom: QAPIfy object-add
On 02/12/20 13:51, Eduardo Habkost wrote:
I'm liking the direction this is taking. However, I would still
like to have a clearer and feasible plan that would work for
-device, -machine, and -cpu.
-cpu is not a problem since it's generally created with a static
configuration (now done with global properties, in the future it could be a
struct).
It is a problem if it requires manually converting existing code
defining CPU properties and we don't have a transition plan.
We do not have to convert everything _if_ for some objects there are
good reasons to do programmatically-generated properties. CPUs might be
one of those cases (or if we decide to convert them, they might endure
some more code duplication than other devices because they have so many
properties).
Would a -device conversion also involve non-user-creatable
devices, or would we keep existing internal usage of QOM
properties?
Even if it's just for user-creatable devices, getting rid of QOM
property usage in devices sounds like a very ambitious goal. I'd
like us to have a good transition plan, in addition to declaring
what's our ideal end goal.
For user-creatable objects Kevin is doing work in lockstep on all
classes; but once we have the infrastructure for QAPI object
configuration schemas we can proceed in the other direction and operate
on one device at a time.
With some handwaving, something like (see create_unimplemented_device)
DeviceState *dev = qdev_new(TYPE_UNIMPLEMENTED_DEVICE);
qdev_prop_set_string(dev, "name", name);
qdev_prop_set_uint64(dev, "size", size);
sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), _fatal);
might become something like
{ 'object': 'unimplemented-device',
'config': {
'name': 'str',
'size': 'size'
},
}
DeviceState *dev = qapi_Unimplemented_new(&(
(UnimplementedDeviceOptions) {
.name = name,
.size = size
}, _fatal);
object_unref(dev);
(i.e. all typesafe!) and the underlying code would be something like
void (*init_properties)(Object *obj, Visitor *v, Error **errp);
...
// QAPI generated constructor
UnimplementedDevice *qapi_Unimplemented_new(
UnimplementedDeviceOptions *opt, Error **errp)
{
Object *obj = object_new(TYPE_UNIMPLEMENTED_DEVICE);
if (!qapi_Unimplemented_init_properties(obj, opt, errp)) {
object_unref(obj);
return NULL;
}
return obj;
}
// QAPI generated Visitor->struct adapter
bool qapi_Unimplemented_init_properties(
Object *obj, Visitor *v, Error **errp)
{
UnimplementedDeviceOptions opt;
Error *local_err = NULL;
visit_type_UnimplementedDeviceOptions(v, NULL,
, _err);
if (local_err) {
error_propagate(errp, local_err);
return false;
}
unimplemented_init_properties(UNIMPLEMENTED_DEVICE(obj),
, _err);
if (local_err) {
error_propagate(errp, local_err);
return false;
}
return true;
}
// Hand-written (?) initializer:
void unimplemented_init_properties(Object *obj,
UnimplementedDeviceOptions *opt, Error **errp)
{
obj->name = name;
obj->size = size;
device_realize(obj, errp);
}
// class_init code:
oc->init_properties = qapi_Unimplemented_init_properties;
and all read-only-after-realize QOM properties could be made *really*
read-only.
Paolo
Re: [PATCH v1 1/1] security-process: update process information
Hi Prasad, On 11/30/20 2:49 PM, P J P wrote: > From: Prasad J Pandit > ... > +## How we respond: > + > +* Process of handling security issues can be divided in two halves. > + Maybe: 0) **Acknowledge reception** - A non-automated response email is sent to acknowledge the reception of the request. This is the starting date for the maximum **60 days** required to process the issue, including bullets 1) and 2). > + 1) **Triage:** > +- Examine the issue details and confirm whether the issue is genuine > +- Validate if it can be misused for malicious purposes > +- Determine its worst case impact and severity > + [Low/Moderate/Important/Critical] > + > + 2) **Response:** > +- Negotiate embargo timeline (if required, depending on severity) > +- Request a CVE and open an upstream > + [bug](https://bugs.launchpad.net/qemu/+bug/) > + or a [GitLab](https://gitlab.com/groups/qemu-project/-/issues) issue > +- Create an upstream fix patch with the proper Buglink/CVE/Reported-by tags. - Participate in the review process until the patch is merged. Test the fix updates with the private reproducer if required. - Close the upstream [bug] with 'Fix released', including the commit SHA-1 of the fix. > + > +* Above security lists are operated by select analysts, maintainers and/or > + representatives from downstream communities. > + > +* List members follow a **responsible disclosure** policy. Any non-public > + information you share about security issues, is kept confidential within > the > + respective affiliated companies. Such information shall not be passed on to > + any third parties, including Xen Security Project, without your prior > + permission. > + > +* We aim to process security issues within maximum of **60 days**. That is > not > + to say that issues will remain private for 60 days, nope. After the > triaging > + step above > +- If issue is found to be less severe, an upstream public bug (or an > + issue) will be created immediately. > +- If issue is found to be severe, an embargo process below is followed, > + and public bug (or an issue) will be opened at the end of the set > + embargo period. > + > + This will allow upstream contributors to create, test and track fix > patch(es). > > Email sent to us is read and acknowledged with a non-automated response. For > issues that are complicated and require significant attention, we will open > an ^^^ You can remove that, as now covered by bullet 0). Regards, Phil.
Re: [PATCH v2 8/8] .gitlab-ci: add build-libvhost-user
On Wed, Nov 25, 2020 at 02:06:40PM +0400, marcandre.lur...@redhat.com wrote: > From: Marc-André Lureau > > Signed-off-by: Marc-André Lureau > --- > .gitlab-ci.yml | 11 +++ > 1 file changed, 11 insertions(+) Reviewed-by: Stefan Hajnoczi signature.asc Description: PGP signature
RE: [raw] Guest stuck during live live-migration
Do you think that, applying this patch ( replacing by "#if 0" there : https://github.com/qemu/qemu/blob/master/block/file-posix.c#L2601 ), could affect for any reason the customer data ? As we are on full NVME and 10G networks it should fix our vm which completely freeze. Quentin De : Qemu-devel de la part de Quentin Grolleau Envoyé : mardi 24 novembre 2020 13:58:53 À : Kevin Wolf Cc : qemu-devel@nongnu.org; qemu-bl...@nongnu.org Objet : RE: [raw] Guest stuck during live live-migration Thanks Kevin, > > Hello, > > > > In our company, we are hosting a large number of Vm, hosted behind > > Openstack (so libvirt/qemu). > > A large majority of our Vms are runnign with local data only, stored on > > NVME, and most of them are RAW disks. > > > > With Qemu 4.0 (can be even with older version) we see strange > > live-migration comportement: > First of all, 4.0 is relatively old. Generally it is worth retrying with > the most recent code (git master or 5.2.0-rc2) before having a closer > look at problems, because it is frustrating to spend considerable time > debugging an issue and then find out it has already been fixed a year > ago. > I will try to build it the most recent code I will try to build with the most recent code, but it will take me some time to do it > > - some Vms live migrate at very high speed without issue (> 6 Gbps) > > - some Vms are running correctly, but migrating at a strange low speed > > (3Gbps) > > - some Vms are migrating at a very low speed (1Gbps, sometime less) and > > during the migration the guest is completely I/O stuck > > > > When this issue happen the VM is completly block, iostat in the Vm show us > > a latency of 30 secs > Can you get the stack backtraces of all QEMU threads while the VM is > blocked (e.g. with gdb or pstack)? (gdb) thread apply all bt Thread 20 (Thread 0x7f8a0effd700 (LWP 201248)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x56520139878b in qemu_cond_wait_impl (cond=0x5652020f27b0, mutex=0x5652020f27e8, file=0x5652014e4178 "/root/qemu_debug_LSEEK/qemu_debug/qemu/ui/vnc-jobs.c", line=214) at /root/qemu_debug_LSEEK/qemu_debug/qemu/util/qemu-thread-posix.c:161 #2 0x5652012a264d in vnc_worker_thread_loop (queue=queue@entry=0x5652020f27b0) at /root/qemu_debug_LSEEK/qemu_debug/qemu/ui/vnc-jobs.c:214 #3 0x5652012a2c18 in vnc_worker_thread (arg=arg@entry=0x5652020f27b0) at /root/qemu_debug_LSEEK/qemu_debug/qemu/ui/vnc-jobs.c:324 #4 0x565201398116 in qemu_thread_start (args=) at /root/qemu_debug_LSEEK/qemu_debug/qemu/util/qemu-thread-posix.c:502 #5 0x7f8a5e24a6ba in start_thread (arg=0x7f8a0effd700) at pthread_create.c:333 #6 0x7f8a5df8041d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 19 (Thread 0x7f8a0700 (LWP 201222)): #0 __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 #1 0x7f8a5e24cdbd in __GI___pthread_mutex_lock (mutex=mutex@entry=0x565201adb680 ) at ../nptl/pthread_mutex_lock.c:80 #2 0x565201398263 in qemu_mutex_lock_impl (mutex=0x565201adb680 , file=0x5652013d7c68 "/root/qemu_debug_LSEEK/qemu_debug/qemu/accel/kvm/kvm-all.c", line=2089) at /root/qemu_debug_LSEEK/qemu_debug/qemu/util/qemu-thread-posix.c:66 #3 0x565200f7d00e in qemu_mutex_lock_iothread_impl (file=file@entry=0x5652013d7c68 "/root/qemu_debug_LSEEK/qemu_debug/qemu/accel/kvm/kvm-all.c", line=line@entry=2089) at /root/qemu_debug_LSEEK/qemu_debug/qemu/cpus.c:1850 #4 0x565200fa7ca8 in kvm_cpu_exec (cpu=cpu@entry=0x565202354480) at /root/qemu_debug_LSEEK/qemu_debug/qemu/accel/kvm/kvm-all.c:2089 #5 0x565200f7d1ce in qemu_kvm_cpu_thread_fn (arg=arg@entry=0x565202354480) at /root/qemu_debug_LSEEK/qemu_debug/qemu/cpus.c:1281 #6 0x565201398116 in qemu_thread_start (args=) at /root/qemu_debug_LSEEK/qemu_debug/qemu/util/qemu-thread-posix.c:502 #7 0x7f8a5e24a6ba in start_thread (arg=0x7f8a0700) at pthread_create.c:333 #8 0x7f8a5df8041d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 18 (Thread 0x7f8a2cff9700 (LWP 201221)): #0 __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 #1 0x7f8a5e24cdbd in __GI___pthread_mutex_lock (mutex=mutex@entry=0x565201adb680 ) at ../nptl/pthread_mutex_lock.c:80 #2 0x565201398263 in qemu_mutex_lock_impl (mutex=0x565201adb680 , file=0x5652013d7c68 "/root/qemu_debug_LSEEK/qemu_debug/qemu/accel/kvm/kvm-all.c", line=2089) at /root/qemu_debug_LSEEK/qemu_debug/qemu/util/qemu-thread-posix.c:66 #3 0x565200f7d00e in qemu_mutex_lock_iothread_impl (file=file@entry=0x5652013d7c68 "/root/qemu_debug_LSEEK/qemu_debug/qemu/accel/kvm/kvm-all.c", line=line@entry=2089) at /root/qemu_debug_LSEEK/qemu_debug/qemu/cpus.c:1850 #4 0x565200fa7ca8 in kvm_cpu_exec (cpu=cpu@entry=0x565202331320) at
Re: [PATCH 0/4] vhost-user: avoid g_return_val_if() in get/set_config()
On Wed, Nov 18, 2020 at 07:21:15PM +0400, Marc-André Lureau wrote: > Hi > > On Wed, Nov 18, 2020 at 1:17 PM Stefan Hajnoczi wrote: > > > Markus Armbruster pointed out that g_return_val_if() is meant for > > programming > > errors. It must not be used for input validation since it can be compiled > > out. > > Use explicit if statements instead. > > > > This patch series converts vhost-user device backends that use > > g_return_val_if() in get/set_config(). > > > > Stefan Hajnoczi (4): > > contrib/vhost-user-blk: avoid g_return_val_if() input validation > > contrib/vhost-user-gpu: avoid g_return_val_if() input validation > > contrib/vhost-user-input: avoid g_return_val_if() input validation > > block/export: avoid g_return_val_if() input validation > > > > > The condition is the same for all the patches, checking the message config > payload is large enough. Afaict, the value is set by the client, so it > could be a runtime error, and thus explicit checking is required. > > Nevertheless, one nice thing about g_return* macros, is that it provides an > error message when the condition fails, which helps. Could you replace it? > > (fwiw, I think g_return* macros are so convenient, I would simply make > G_DISABLE_CHECKS forbidden and call it a day) I'll add an error message in v2. Stefan signature.asc Description: PGP signature
[PATCH v2 1/4] contrib/vhost-user-blk: avoid g_return_val_if() input validation
Do not validate input with g_return_val_if(). This API is intended for
checking programming errors and is compiled out with -DG_DISABLE_CHECKS.
Use an explicit if statement for input validation so it cannot
accidentally be compiled out.
Suggested-by: Markus Armbruster
Signed-off-by: Stefan Hajnoczi
---
contrib/vhost-user-blk/vhost-user-blk.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/contrib/vhost-user-blk/vhost-user-blk.c
b/contrib/vhost-user-blk/vhost-user-blk.c
index dc981bf945..60e3c9ed37 100644
--- a/contrib/vhost-user-blk/vhost-user-blk.c
+++ b/contrib/vhost-user-blk/vhost-user-blk.c
@@ -404,7 +404,11 @@ vub_get_config(VuDev *vu_dev, uint8_t *config, uint32_t
len)
VugDev *gdev;
VubDev *vdev_blk;
-g_return_val_if_fail(len <= sizeof(struct virtio_blk_config), -1);
+if (len > sizeof(struct virtio_blk_config)) {
+fprintf(stderr, "Invalid get_config len %u, expected <= %zu\n",
+len, sizeof(struct virtio_blk_config));
+return -1;
+}
gdev = container_of(vu_dev, VugDev, parent);
vdev_blk = container_of(gdev, VubDev, parent);
--
2.28.0
[PATCH v2 2/4] contrib/vhost-user-gpu: avoid g_return_val_if() input validation
Do not validate input with g_return_val_if(). This API is intended for
checking programming errors and is compiled out with -DG_DISABLE_CHECKS.
Use an explicit if statement for input validation so it cannot
accidentally be compiled out.
Suggested-by: Markus Armbruster
Signed-off-by: Stefan Hajnoczi
---
contrib/vhost-user-gpu/vhost-user-gpu.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/contrib/vhost-user-gpu/vhost-user-gpu.c
b/contrib/vhost-user-gpu/vhost-user-gpu.c
index a019d0a9ac..534bad24d1 100644
--- a/contrib/vhost-user-gpu/vhost-user-gpu.c
+++ b/contrib/vhost-user-gpu/vhost-user-gpu.c
@@ -1044,7 +1044,11 @@ vg_get_config(VuDev *dev, uint8_t *config, uint32_t len)
{
VuGpu *g = container_of(dev, VuGpu, dev.parent);
-g_return_val_if_fail(len <= sizeof(struct virtio_gpu_config), -1);
+if (len > sizeof(struct virtio_gpu_config)) {
+g_critical("%s: len %u is larger than %zu",
+ __func__, len, sizeof(struct virtio_gpu_config));
+return -1;
+}
if (opt_virgl) {
g->virtio_config.num_capsets = vg_virgl_get_num_capsets();
--
2.28.0
[PATCH v2 0/4] vhost-user: avoid g_return_val_if() in get/set_config()
v2: * Print errors [Marc-André] Markus Armbruster pointed out that g_return_val_if() is meant for programming errors. It must not be used for input validation since it can be compiled out. Use explicit if statements instead. This patch series converts vhost-user device backends that use g_return_val_if() in get/set_config(). Stefan Hajnoczi (4): contrib/vhost-user-blk: avoid g_return_val_if() input validation contrib/vhost-user-gpu: avoid g_return_val_if() input validation contrib/vhost-user-input: avoid g_return_val_if() input validation block/export: avoid g_return_val_if() input validation block/export/vhost-user-blk-server.c| 6 +- contrib/vhost-user-blk/vhost-user-blk.c | 6 +- contrib/vhost-user-gpu/vhost-user-gpu.c | 6 +- contrib/vhost-user-input/main.c | 6 +- 4 files changed, 20 insertions(+), 4 deletions(-) -- 2.28.0
[RFC PATCH] configure: add --without-default-features
By default QEMU enables a lot of features if it can probe and find the support libraries. It also enables a bunch of features by default. This patch adds the ability to build --without-default-features which can be paired with a --without-default-devices for a barely functional build. The main use case for this is testing our build assumptions and for minimising the amount of stuff you build if you just want to test a particular feature on your relatively slow emulated test system. Signed-off-by: Alex Bennée --- configure | 161 ++ 1 file changed, 89 insertions(+), 72 deletions(-) diff --git a/configure b/configure index 18c26e0389..23fa6f9421 100755 --- a/configure +++ b/configure @@ -291,10 +291,24 @@ unset target_list_exclude # # Always add --enable-foo and --disable-foo command line args. # Distributions want to ensure that several features are compiled in, and it -# is impossible without a --enable-foo that exits if a feature is not found. +# is impossible without a --enable-foo that exits if a feature is not +# found. -brlapi="" -curl="" +default_feature="" +default_yes_feature="yes" +# parse CC options second +for opt do + optarg=$(expr "x$opt" : 'x[^=]*=\(.*\)') + case "$opt" in + --without-default-features) + default_feature="no" + default_yes_feature="no" + ;; + esac +done + +brlapi="$default_feature" +curl="$default_feature" iconv="auto" curses="auto" docs="auto" @@ -303,59 +317,59 @@ netmap="no" sdl="auto" sdl_image="auto" virtiofsd="auto" -virtfs="" +virtfs="$default_feature" libudev="auto" mpath="auto" vnc="enabled" sparse="auto" -vde="" +vde="$default_feature" vnc_sasl="auto" vnc_jpeg="auto" vnc_png="auto" xkbcommon="auto" -xen="" -xen_ctrl_version="" +xen="$default_feature" +xen_ctrl_version="$default_feature" xen_pci_passthrough="auto" -linux_aio="" -linux_io_uring="" -cap_ng="" -attr="" -libattr="" -xfs="" +linux_aio="$default_feature" +linux_io_uring="$default_feature" +cap_ng="$default_feature" +attr="$default_feature" +libattr="$default_feature" +xfs="$default_feature" tcg="enabled" -membarrier="" -vhost_net="" -vhost_crypto="" -vhost_scsi="" -vhost_vsock="" +membarrier="$default_feature" +vhost_net="$default_feature" +vhost_crypto="$default_feature" +vhost_scsi="$default_feature" +vhost_vsock="$default_feature" vhost_user="no" vhost_user_blk_server="auto" -vhost_user_fs="" +vhost_user_fs="$default_feature" kvm="auto" hax="auto" hvf="auto" whpx="auto" -rdma="" -pvrdma="" +rdma="$default_feature" +pvrdma="$default_feature" gprof="no" debug_tcg="no" debug="no" sanitizers="no" tsan="no" -fortify_source="" +fortify_source="$default_feature" strip_opt="yes" tcg_interpreter="no" bigendian="no" mingw32="no" gcov="no" -EXESUF="" +EXESUF="$default_feature" HOST_DSOSUF=".so" modules="no" module_upgrades="no" prefix="/usr/local" qemu_suffix="qemu" slirp="auto" -oss_lib="" +oss_lib="$default_feature" bsd="no" linux="no" solaris="no" @@ -370,81 +384,81 @@ pie="" qom_cast_debug="yes" trace_backends="log" trace_file="trace" -spice="" -rbd="" -smartcard="" +spice="$default_feature" +rbd="$default_feature" +smartcard="$default_feature" u2f="auto" -libusb="" -usb_redir="" -opengl="" +libusb="$default_feature" +usb_redir="$default_feature" +opengl="$default_feature" opengl_dmabuf="no" cpuid_h="no" -avx2_opt="" +avx2_opt="$default_feature" capstone="auto" -lzo="" -snappy="" -bzip2="" -lzfse="" -zstd="" -guest_agent="" +lzo="$default_feature" +snappy="$default_feature" +bzip2="$default_feature" +lzfse="$default_feature" +zstd="$default_feature" +guest_agent="$default_feature" guest_agent_with_vss="no" guest_agent_ntddscsi="no" -guest_agent_msi="" -vss_win32_sdk="" +guest_agent_msi="$default_feature" +vss_win32_sdk="$default_feature" win_sdk="no" -want_tools="" -libiscsi="" -libnfs="" +want_tools="$default_feature" +libiscsi="$default_feature" +libnfs="$default_feature" coroutine="" -coroutine_pool="" +coroutine_pool="$default_feature" debug_stack_usage="no" crypto_afalg="no" -seccomp="" -glusterfs="" +seccomp="$default_feature" +glusterfs="$default_feature" glusterfs_xlator_opt="no" glusterfs_discard="no" glusterfs_fallocate="no" glusterfs_zerofill="no" glusterfs_ftruncate_has_stat="no" glusterfs_iocb_has_stat="no" -gtk="" +gtk="$default_feature" gtk_gl="no" tls_priority="NORMAL" -gnutls="" -nettle="" +gnutls="$default_feature" +nettle="$default_feature" nettle_xts="no" -gcrypt="" +gcrypt="$default_feature" gcrypt_hmac="no" gcrypt_xts="no" qemu_private_xts="yes" -auth_pam="" -vte="" -virglrenderer="" -tpm="" -libssh="" -live_block_migration="yes" -numa="" +auth_pam="$default_feature" +vte="$default_feature" +virglrenderer="$default_feature" +tpm="$default_feature" +libssh="$default_feature" +live_block_migration="$default_yes_feature" +numa="$default_feature" tcmalloc="no" jemalloc="no" -replication="yes" -bochs="yes" -cloop="yes" -dmg="yes"
Re: [PATCH] ide:atapi: check io_buffer_index in ide_atapi_cmd_reply_end
Hi, [doing a combined reply] +-- On Tue, 1 Dec 2020, Philippe Mathieu-Daudé wrote --+ | Is it possible to release the reproducer to the community, so we can work on | a fix and test it? * No, we can not release/share reproducers on a public list. * We can request reporters to do so by their volition. | What happens to reproducers when a CVE is assigned, but the bug is marked as | "out of the QEMU security boundary"? | +-- On Tue, 1 Dec 2020, Peter Maydell wrote --+ | Also, why are we assigning CVEs for bugs we don't consider security bugs? * We need to mark these componets 'out of security scope' at the source level, rather than on each bug. * Easiest could be to just have a list of such components in the git text file. At least till the time we device --security build and run time option discussed earlier. -> https://lists.nongnu.org/archive/html/qemu-devel/2020-07/msg04680.html +-- On Tue, 1 Dec 2020, Paolo Bonzini wrote --+ | qtests are not just helpful. Adding regression tests for bugs is a *basic* | software engineering principle. If you don't have time to write tests, you | (or your organization) should find it. * I've been doing the patch work out of my own interest. * We generally rely on upstream/engineering for fix patches, because of our narrower understanding of the code base. +-- On Wed, 2 Dec 2020, Markus Armbruster wrote --+ | Paolo Bonzini writes: | > you need at least to enclose the reproducer, otherwise you're posting a | > puzzle not a patch. :) | | Indeed. Posting puzzles is a negative-sum game.] * Agreed. I think the upcoming 'qemu-security' list may help in this regard. As issue reports+reproducer details shall go there. * Even then, we'll need to ask reporter's permission before sharing their reproducers on a public list OR with non-members. * Best is if reporters share/release reproducers themselves. Maybe we can have a public git repository and they can send a PR to include their reproducers in the repository. * That way multiple reproducers for the same issue can be held together. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
Re: [PATCH v2 4/8] libvhost-user: drop qemu/osdep.h dependency
On Wed, Nov 25, 2020 at 02:06:36PM +0400, marcandre.lur...@redhat.com wrote: > From: Marc-André Lureau > > Signed-off-by: Marc-André Lureau > --- > contrib/libvhost-user/libvhost-user-glib.c | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-) Reviewed-by: Stefan Hajnoczi signature.asc Description: PGP signature
Re: [PATCH v2 2/8] libvhost-user: replace qemu/memfd.h usage
On Wed, Nov 25, 2020 at 02:06:34PM +0400, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau
>
> Undo the damage from commit 5f9ff1eff3 ("libvhost-user: Support tracking
> inflight I/O in shared memory") which introduced glib dependency through
> osdep.h inclusion.
>
> libvhost-user.c tries to stay free from glib usage.
>
> Use glibc memfd_create directly when available (assumed so when
> MFD_ALLOW_SEALING is defined). A following commit will make the project
> standalone and check for memfd API at configure time, instead of a
> panic at runtime.
>
> Signed-off-by: Marc-André Lureau
> Reviewed-by: Stefan Hajnoczi
> ---
> contrib/libvhost-user/libvhost-user.c | 50 +++
> 1 file changed, 43 insertions(+), 7 deletions(-)
Reviewed-by: Stefan Hajnoczi
signature.asc
Description: PGP signature
Re: [PATCH v6] hw/i386/pc: add max combined fw size as machine configuration option
Sure, no problem. From: Michael S. Tsirkin Sent: Wednesday, December 2, 2020 3:56 AM To: McMillan, Erich Cc: qemu-devel@nongnu.org ; ler...@redhat.com ; dgilb...@redhat.com ; marcel.apfelb...@gmail.com ; imamm...@redhat.com ; kra...@redhat.com Subject: Re: [PATCH v6] hw/i386/pc: add max combined fw size as machine configuration option Could you help by rebasing this on master? Shouldn't be hard ... Thanks!
Re: [PATCH v1 1/1] security-process: update process information
Hello Konrad, all +-- On Tue, 1 Dec 2020, Konrad Rzeszutek Wilk wrote --+ | On Mon, Nov 30, 2020 at 07:19:07PM +0530, P J P wrote: | > We are about to introduce a qemu-security mailing list to report | > and triage QEMU security issues. | > Update the QEMU security process web page with new mailing list | > and triage details. | | Thank you for doing it! | Reviewed-by: Konrad Rzeszutek Wilk Thank you. | with one change below. | | > +- Request a CVE and open an upstream | > + [bug](https://bugs.launchpad.net/qemu/+bug/) | > + or a [GitLab](https://gitlab.com/groups/qemu-project/-/issues) issue | | You may want to clarify that this step in the process will not disclose the | details of the issue to the public. Yes, this is covered in the following process text and under publication embargo section: === + * We aim to process ... 60 days ... After the triaging step above + +- If issue is found to be less severe, an upstream public bug (or an + issue) will be created immediately. +- If issue is found to be severe, an embargo process below is followed, + and public bug (or an issue) will be opened at the end of the set + embargo period. ... +* Embargo periods will be negotiated by mutual agreement between reporter(s), + members of the security list and other relevant parties to the problem. + Such embargo period is generally upto [2 weeks] + +* Members of the security list agree not to publicly disclose any details of + an embargoed security issue until its embargo date expires. === Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
Re: [PATCH 00/18] qapi/qom: QAPIfy object-add
On Wed, Dec 02, 2020 at 10:30:11AM +0100, Paolo Bonzini wrote:
> On 01/12/20 23:08, Eduardo Habkost wrote:
> > > Properties are only a useful concept if they have a use. If
> > > -object/object_add/object-add can do the same job without properties,
> > > properties are not needed anymore.
> >
> > Do you mean "not needed for -object anymore"? Properties are
> > still used by internal C code (esp. board code),
> > -device/device_add, -machine, -cpu, and debugging commands (like
> > "info qtree" and qom-list/qom-get/qom-set).
>
> Yes.
>
> > > Right now QOM is all about exposing properties, and having multiple
> > > interfaces to set them (by picking a different visitor). But in practice
> > > most QOM objects have a lifetime that consists of 1) set properties 2)
> > > flip
> > > a switch (realized/complete/open) 3) let the object live on its own. 1+2
> > > are a single monitor command or CLI option; during 3 you access the object
> > > through monitor commands, not properties.
> >
> > I agree with this, except for the word "all" in "QOM is all
> > about". QOM is also an extensively used internal QEMU API,
> > including internal usage of the QOM property system.
>
> Yeah, "all about exposing properties" includes internal usage. And you're
> right that some "phase 3" monitor commands do work at the property level
> (mostly "info qtree", but also "qom-get" because there are some cases of
> public run-time properties).
I still disagree on the "all about" part even for internal usage.
But this shouldn't really matter for this discussion, I guess.
>
> > I'm liking the direction this is taking. However, I would still
> > like to have a clearer and feasible plan that would work for
> > -device, -machine, and -cpu.
>
> -cpu is not a problem since it's generally created with a static
> configuration (now done with global properties, in the future it could be a
> struct).
It is a problem if it requires manually converting existing code
defining CPU properties and we don't have a transition plan.
>
> -machine and -device in principle could be done the same way as -object,
> just through a different registry (_not_ a huge struct; that's an acceptable
> stopgap for -object but that's it). The static aka field properties would
> remain as read-only, with defaults moved to instance_init or realize. But
> there would be again "triplication" with a trivial conversion:
>
> 1) in the QAPI schema, e.g. 'num_queues': 'int16'
>
> 2) in the struct, "int16_t num_queues;"
>
> 3) in the realize function,
>
> s->num_queues = cfg->has_num_queues ? cfg->num_queues : 8;
>
> So having a mechanism for defaults in the QAPI schema would be good. Maybe
> 'num_queues': { 'type': 'int16', 'default': '8' }?
>
Would a -device conversion also involve non-user-creatable
devices, or would we keep existing internal usage of QOM
properties?
Even if it's just for user-creatable devices, getting rid of QOM
property usage in devices sounds like a very ambitious goal. I'd
like us to have a good transition plan, in addition to declaring
what's our ideal end goal.
> I also need to review more the part of this code with respect to the
> application of global properties. I wonder if there are visitor tricks that
> we can do, so that global properties keep working but correspond to QAPI
> fields instead of QOM properties.
>
> Paolo
>
--
Eduardo
Re: [PATCH 24/29] migration, vl: start migration via qmp_migrate_incoming
On Wed, Dec 02, 2020 at 01:10:37PM +, Dr. David Alan Gilbert wrote:
> * Paolo Bonzini (pbonz...@redhat.com) wrote:
> > On 20/11/20 16:34, Igor Mammedov wrote:
> > > > qapi_event_send_migration(MIGRATION_STATUS_SETUP);
> > > > -if (!strcmp(uri, "defer")) {
> > > > -deferred_incoming_migration(errp);
> > > > -} else if (strstart(uri, "tcp:", ) ||
> > > > - strstart(uri, "unix:", NULL) ||
> > > > - strstart(uri, "vsock:", NULL)) {
> > > considering the last hunk does won't call qmp_migrate_incoming
> > > if 'defer' was used, wouldn't we will lose QAPI event here?
> > > not sure how important it to users,
> >
> > Hmm yeah that's true. That might even be considered a bugfix (no setup is
> > done until the "real" migrate-incoming command), but I can also add the
> > event manually in qemu_init.
> >
> > (Libvirt doesn't use the SETUP case of the event but that's of course only
> > part of the story).
>
> I'm more worried about how this stops a repeated 'migrate incoming'
> or a 'migrate_incoming' that's issued following a qemu that's been
> started with -incoming tcp:... but which a socket hasn't yet connected
> to.
Can someone remind me why we need to have an -incoming arg at all ?
With snapshots, we can just start QEMU normally, using -S if desired,
and then invoke "loadvm" to restore from a snapshot at any time.
What is different thet means we can't just run "migrate_incoming" on
any QEMU at any time, ignoring -incoming entirely ?
Regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [PATCH 24/29] migration, vl: start migration via qmp_migrate_incoming
On 02/12/20 14:15, Daniel P. Berrangé wrote: Can someone remind me why we need to have an -incoming arg at all ? With snapshots, we can just start QEMU normally, using -S if desired, and then invoke "loadvm" to restore from a snapshot at any time. What is different thet means we can't just run "migrate_incoming" on any QEMU at any time, ignoring -incoming entirely ? There are some parts of QEMU that operate differently based on RUN_STATE_INCOMING. Removing those is one of the things that these patches should enable, though there are also some uses in Xen that I'm more worried about. Paolo
Re: [PATCH] linux-user/elfload: Fix handling of pure BSS segments
Stephen Long writes:
> Alex Bennee writes:
>
>>> Apologies for the unclear commit msg. I was also seeing a SIGSEGV in
>>> zero_bss() with the binaries I was generating. I was using LLD to generate
>>> the binaries. The binaries all had LOAD segments with a file size of
>>> 0.
>>
>> How hairy is the generation of these binaries? If it's all doable with
>> standard gcc/ldd command lines it would be useful to add them as a
>> tcg/multiarch test case.
>
> We are linking with an old version of musl. I was able to produce an
> ELF with a LOAD segment just for the BSS with the following:
>
> volatile int num;
>
> int main(void) {
> return num;
> }
>
> and compiling it with just aarch64-linux-gnu-gcc -fuse-ld=lld -static and
> linking with cross compiled musl v1.1.9 on Ubuntu. I tried it with glibc and
> it has a bunch of non-BSS variables, so the data section gets created.
Hmm I tried the following patch but evidently there is more to be done
to convince it:
13:26:24 [alex@zen:~/l/q/b/arm.all] virtio/vhost-user-rpmb-v2|✚4…(+6/-3) 2 +
make build-tcg-tests-aarch64-linux-user -j9 V=1
make -f /home/alex/lsrc/qemu.git/tests/tcg/Makefile.qemu
SRC_PATH=/home/alex/lsrc/qemu.git V="1" TARGET="aarch64-linux-user" guest-tests
make[1]: Entering directory '/home/alex/lsrc/qemu.git/builds/arm.all'
(mkdir -p tests/tcg/aarch64-linux-user && cd tests/tcg/aarch64-linux-user &&
make -f ../Makefile.target TARGET="aarch64-linux-user"
CC="aarch64-linux-gnu-gcc" SRC_PATH="/home/alex/lsrc/qemu.git" BUILD_STATIC=y
EXTRA_CFLAGS="")
make[2]: Entering directory
'/home/alex/lsrc/qemu.git/builds/arm.all/tests/tcg/aarch64-linux-user'
aarch64-linux-gnu-gcc -Wall -O0 -g -fno-strict-aliasing
/home/alex/lsrc/qemu.git/tests/tcg/aarch64/zero-bss.c -o zero-bss -static
-fuse-ld=lld
collect2: fatal error: cannot find 'ld'
compilation terminated.
make[2]: *** [../Makefile.target:103: zero-bss] Error 1
make[2]: Leaving directory
'/home/alex/lsrc/qemu.git/builds/arm.all/tests/tcg/aarch64-linux-user'
make[1]: *** [/home/alex/lsrc/qemu.git/tests/tcg/Makefile.qemu:42:
cross-build-guest-tests] Error 2
make[1]: Leaving directory '/home/alex/lsrc/qemu.git/builds/arm.all'
make: *** [/home/alex/lsrc/qemu.git/tests/Makefile.include:54:
build-tcg-tests-aarch64-linux-user] Error 2
--8<---cut here---start->8---
tests/tcg: try and add a zero-bss test case (WIP)
3 files changed, 17 insertions(+), 1 deletion(-)
tests/tcg/aarch64/zero-bss.c| 13 +
tests/docker/dockerfiles/debian-arm64-test-cross.docker | 2 +-
tests/tcg/aarch64/Makefile.target | 3 +++
new file tests/tcg/aarch64/zero-bss.c
@@ -0,0 +1,13 @@
+/*
+ * Zero BSS Test case
+ *
+ * Copyright (c) 2020 Linaro Ltd
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+volatile int num;
+
+int main(void) {
+return num;
+}
modified tests/docker/dockerfiles/debian-arm64-test-cross.docker
@@ -10,4 +10,4 @@ RUN dpkg --add-architecture arm64
RUN apt update && \
DEBIAN_FRONTEND=noninteractive eatmydata \
apt install -y --no-install-recommends \
-crossbuild-essential-arm64 gcc-10-aarch64-linux-gnu
+crossbuild-essential-arm64 gcc-10-aarch64-linux-gnu musl-dev:arm64
modified tests/tcg/aarch64/Makefile.target
@@ -84,4 +84,7 @@ endif
endif
+AARCH64_TESTS += zero-bss
+zero-bss: LDFLAGS+=-fuse-ld=lld
+
TESTS += $(AARCH64_TESTS)
--8<---cut here---end--->8---
--
Alex Bennée
Re: [RFC PATCH v2 0/5] eBPF RSS support for virtio-net
On 2020/11/19 下午7:13, Andrew Melnychenko wrote: This set of patches introduces the usage of eBPF for packet steering and RSS hash calculation: * RSS(Receive Side Scaling) is used to distribute network packets to guest virtqueues by calculating packet hash * Additionally adding support for the usage of RSS with vhost The eBPF works on kernels 5.8+ On earlier kerneld it fails to load and the RSS feature is reported only without vhost and implemented in 'in-qemu' software. Implementation notes: Linux TAP TUNSETSTEERINGEBPF ioctl was used to set the eBPF program. Added libbpf dependency and eBPF support. The eBPF program is part of the qemu and presented as an array of BPF ELF file data. The compilation of eBPF is not part of QEMU build and can be done using provided Makefile.ebpf(need to adjust 'linuxhdrs'). Added changes to virtio-net and vhost, primary eBPF RSS is used. 'in-qemu' RSS used in the case of hash population and as a fallback option. For vhost, the hash population feature is not reported to the guest. Please also see the documentation in PATCH 5/5. I am sending those patches as RFC to initiate the discussions and get feedback on the following points: * Fallback when eBPF is not supported by the kernel * Live migration to the kernel that doesn't have eBPF support * Integration with current QEMU build * Additional usage for eBPF for packet filtering Known issues: * hash population not supported by eBPF RSS: 'in-qemu' RSS used as a fallback, also, hash population feature is not reported to guests with vhost. * big-endian BPF support: for now, eBPF isn't supported on big-endian systems. Can be added in future if required. * huge .h file with eBPF binary. The size of .h file containing eBPF binary is currently ~5K lines, because the binary is built with debug information. The binary without debug/BTF info can't be loaded by libbpf. We're looking for possibilities to reduce the size of the .h files. Adding Toke for sharing more idea from eBPF side. We had some discussion on the eBPF issues: 1) Whether or not to use libbpf. Toke strongly suggest to use libbpf 2) Whether or not to use BTF. Toke confirmed that if we don't access any skb metadata, BTF is not strictly required for CO-RE. But it might still useful for e.g debugging. 3) About the huge (5K lines, see patch #2 Toke). Toke confirmed that we can strip debug symbols, but Yuri found some sections can't be stripped, we can keep discussing here. Toke, feel free to correct me if I was wrong. Thanks Changes since v1: * using libbpf instead of direct 'bpf' system call. * added libbpf dependency to the configure/meson scripts. * changed python script for eBPF .h file generation. * changed eBPF program - reading L3 proto from ethernet frame. * added TUNSETSTEERINGEBPF define for TUN. * changed the maintainer's info. * added license headers. * refactored code. Andrew (5): net: Added SetSteeringEBPF method for NetClientState. ebpf: Added eBPF RSS program. ebpf: Added eBPF RSS loader. virtio-net: Added eBPF RSS to virtio-net. docs: Added eBPF RSS documentation. MAINTAINERS|7 + configure | 33 + docs/ebpf_rss.rst | 133 + ebpf/EbpfElf_to_C.py | 36 + ebpf/Makefile.ebpf | 33 + ebpf/ebpf_rss-stub.c | 40 + ebpf/ebpf_rss.c| 186 ++ ebpf/ebpf_rss.h| 44 + ebpf/meson.build |1 + ebpf/rss.bpf.c | 505 +++ ebpf/tun_rss_steering.h| 5439 hw/net/vhost_net.c |2 + hw/net/virtio-net.c| 120 +- include/hw/virtio/virtio-net.h |4 + include/net/net.h |2 + meson.build| 11 + net/tap-bsd.c |5 + net/tap-linux.c| 13 + net/tap-linux.h|1 + net/tap-solaris.c |5 + net/tap-stub.c |5 + net/tap.c |9 + net/tap_int.h |1 + net/vhost-vdpa.c |2 + 24 files changed, 6633 insertions(+), 4 deletions(-) create mode 100644 docs/ebpf_rss.rst create mode 100644 ebpf/EbpfElf_to_C.py create mode 100755 ebpf/Makefile.ebpf create mode 100644 ebpf/ebpf_rss-stub.c create mode 100644 ebpf/ebpf_rss.c create mode 100644 ebpf/ebpf_rss.h create mode 100644 ebpf/meson.build create mode 100644 ebpf/rss.bpf.c create mode 100644 ebpf/tun_rss_steering.h
[Bug 1906516] [NEW] [RISCV] sfence.vma need to end the translation block
Public bug reported: QEMU emulator version 5.0.0 sfence.vma will flush the tlb, so after this instruction, the translation block should be end. The following code will only work in single step mode: ``` relocate: li a0, OFFSET la t0, 1f add t0, t0, a0 csrw stvec, t0 la t0, early_pgtbl srl t0, t0, PAGE_SHIFT li t1, SATP_SV39 or t0, t1, t0 csrw satp, t0 1: sfence.vma la t0, trap_s csrw stvec, t0 ret ``` In this code, I want to relocate pc to virtual address with the OFFSET prefix, before writing to satp, pc run at physic address, stvec has been set a label 1 with a virtual prefix and virtual address has been mapping in early_pgtbl, after writing satp, there will throw a page fault, and pc will set to virtual address of label 1. The problem is that, in this situation, the translation block will not end after sfence.vma, and stvec will be set to trap_s, ``` IN: Priv: 1; Virt: 0 0x80dc: 00a080b3 add ra,ra,a0 0x80e0: 7297 auipc t0,28672# 0x800070e0 0x80e4: f2028293 addit0,t0,-224 0x80e8: 00c2d293 srlit0,t0,12 0x80ec: fff0031b addiw t1,zero,-1 0x80f0: 03f31313 sllit1,t1,63 0x80f4: 005362b3 or t0,t1,t0 0x80f8: 18029073 csrrw zero,satp,t0 IN: Priv: 1; Virt: 0 0x80fc: 1273 sfence.vma zero,zero 0x8100: 0297 auipc t0,0# 0x8100 0x8104: 1c828293 addit0,t0,456 0x8108: 10529073 csrrw zero,stvec,t0 riscv_raise_exception: 12 riscv_raise_exception: 12 riscv_raise_exception: 12 riscv_raise_exception: 12 ... ``` So, the program will crash, and the program will work in single step mode: ``` IN: Priv: 1; Virt: 0 0x80f8: 18029073 csrrw zero,satp,t0 IN: Priv: 1; Virt: 0 0x80fc: 1273 sfence.vma zero,zero riscv_raise_exception: 12 IN: Priv: 1; Virt: 0 0x80fc: 1273 sfence.vma zero,zero IN: Priv: 1; Virt: 0 0x8100: 0297 auipc t0,0# 0x8100 ``` The pc will set to label 1, instead of trap_s. I try to patch the code in fence.i in trans_rvi.inc.c to sfence.vma: ``` tcg_gen_movi_tl(cpu_pc, ctx->pc_succ_insn); exit_tb(ctx); ctx->base.is_jmp = DISAS_NORETURN; ``` This codes can help to end the tranlate block, since I'm not a qemu guy, I'm not sure if this is a corret method. ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1906516 Title: [RISCV] sfence.vma need to end the translation block Status in QEMU: New Bug description: QEMU emulator version 5.0.0 sfence.vma will flush the tlb, so after this instruction, the translation block should be end. The following code will only work in single step mode: ``` relocate: li a0, OFFSET la t0, 1f add t0, t0, a0 csrw stvec, t0 la t0, early_pgtbl srl t0, t0, PAGE_SHIFT li t1, SATP_SV39 or t0, t1, t0 csrw satp, t0 1: sfence.vma la t0, trap_s csrw stvec, t0 ret ``` In this code, I want to relocate pc to virtual address with the OFFSET prefix, before writing to satp, pc run at physic address, stvec has been set a label 1 with a virtual prefix and virtual address has been mapping in early_pgtbl, after writing satp, there will throw a page fault, and pc will set to virtual address of label 1. The problem is that, in this situation, the translation block will not end after sfence.vma, and stvec will be set to trap_s, ``` IN: Priv: 1; Virt: 0 0x80dc: 00a080b3 add ra,ra,a0 0x80e0: 7297 auipc t0,28672# 0x800070e0 0x80e4: f2028293 addit0,t0,-224 0x80e8: 00c2d293 srlit0,t0,12 0x80ec: fff0031b addiw t1,zero,-1 0x80f0: 03f31313 sllit1,t1,63 0x80f4: 005362b3 or t0,t1,t0 0x80f8: 18029073 csrrw zero,satp,t0 IN: Priv: 1; Virt: 0 0x80fc: 1273 sfence.vma zero,zero 0x8100: 0297 auipc t0,0#
Re: [PATCH v2 6/8] libvhost-user: check memfd API
On Wed, Nov 25, 2020 at 02:06:38PM +0400, marcandre.lur...@redhat.com wrote: > From: Marc-André Lureau > > Do not compile potentially panicking code, instead check memfd API is > present during configure time. > > Signed-off-by: Marc-André Lureau > --- > subprojects/libvhost-user/libvhost-user.c | 6 -- > subprojects/libvhost-user/meson.build | 12 > 2 files changed, 12 insertions(+), 6 deletions(-) Runtime checks are useful in environments where the QEMU and kernel version are not matched. In other words, if QEMU can be built against new kernel headers and launched on an old kernel then it needs to handle ENOSYS. But in some cases this situation is unlikely and we can stick to static feature checks. I'm not sure if it matters here, so... Reviewed-by: Stefan Hajnoczi signature.asc Description: PGP signature
Re: [PATCH v2 7/8] libvhost-user: add a simple link test without glib
On Wed, Nov 25, 2020 at 02:06:39PM +0400, marcandre.lur...@redhat.com wrote: > From: Marc-André Lureau > > Signed-off-by: Marc-André Lureau > --- > subprojects/libvhost-user/link-test.c | 45 +++ > subprojects/libvhost-user/meson.build | 4 +++ > 2 files changed, 49 insertions(+) > create mode 100644 subprojects/libvhost-user/link-test.c Reviewed-by: Stefan Hajnoczi signature.asc Description: PGP signature
[PATCH] hw/block: m25p80: Implement AAI-WP command support for SST flashes
From: Xuzhou Cheng
Auto Address Increment (AAI) Word-Program is a special command of
SST flashes. AAI-WP allows multiple bytes of data to be programmed
without re-issuing the next sequential address location.
Signed-off-by: Xuzhou Cheng
Signed-off-by: Bin Meng
---
hw/block/m25p80.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c
index 9b36762df9..f225d9c96d 100644
--- a/hw/block/m25p80.c
+++ b/hw/block/m25p80.c
@@ -359,6 +359,7 @@ typedef enum {
QPP_4 = 0x34,
RDID_90 = 0x90,
RDID_AB = 0xab,
+AAI_WP = 0xad,
ERASE_4K = 0x20,
ERASE4_4K = 0x21,
@@ -449,6 +450,7 @@ struct Flash {
bool four_bytes_address_mode;
bool reset_enable;
bool quad_enable;
+bool aai_enable;
uint8_t ear;
int64_t dirty_page;
@@ -661,6 +663,7 @@ static void complete_collecting_data(Flash *s)
case PP:
case PP4:
case PP4_4:
+case AAI_WP:
s->state = STATE_PAGE_PROGRAM;
break;
case READ:
@@ -1010,6 +1013,9 @@ static void decode_new_cmd(Flash *s, uint32_t value)
case WRDI:
s->write_enable = false;
+if (get_man(s) == MAN_SST) {
+s->aai_enable = false;
+}
break;
case WREN:
s->write_enable = true;
@@ -1162,6 +1168,17 @@ static void decode_new_cmd(Flash *s, uint32_t value)
case RSTQIO:
s->quad_enable = false;
break;
+case AAI_WP:
+if (get_man(s) == MAN_SST && s->write_enable) {
+if (s->aai_enable) {
+s->state = STATE_PAGE_PROGRAM;
+} else {
+s->aai_enable = true;
+s->needed_bytes = get_addr_length(s);
+s->state = STATE_COLLECTING_DATA;
+}
+}
+break;
default:
s->pos = 0;
s->len = 1;
--
2.25.1
Re: [PATCH 24/29] migration, vl: start migration via qmp_migrate_incoming
* Paolo Bonzini (pbonz...@redhat.com) wrote:
> On 02/12/20 14:10, Dr. David Alan Gilbert wrote:
> > I'm more worried about how this stops a repeated 'migrate incoming'
> > or a 'migrate_incoming' that's issued following a qemu that's been
> > started with -incoming tcp:... but which a socket hasn't yet connected
> > to.
>
> Good question, fortunately it is simply handled answer:
>
> void qmp_migrate_incoming(const char *uri, Error **errp)
> {
> Error *local_err = NULL;
> static bool once = true;
>
> if (!once) {
> error_setg(errp, "The incoming migration has already been started");
> return;
> }
> if (!runstate_check(RUN_STATE_INMIGRATE)) {
> error_setg(errp, "'-incoming' was not specified on the command
> line");
> return;
> }
>
> qemu_start_incoming_migration(uri, _err);
>
> if (local_err) {
> error_propagate(errp, local_err);
> return;
> }
>
> once = false;
> }
>
> This patch can simplify things because every incoming migrations (no matter
> if '-incoming defer' or '-incoming tcp:...') goes through the
> qmp_migrate_incoming function above.
Yeh I think that's OK.
Dave
> Paolo
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [raw] Guest stuck during live live-migration
Am 02.12.2020 um 16:09 hat Quentin Grolleau geschrieben: > Do you think that, applying this patch ( replacing by "#if 0" there : > https://github.com/qemu/qemu/blob/master/block/file-posix.c#L2601 ), > could affect for any reason the customer data ? > > As we are on full NVME and 10G networks it should fix our vm which > completely freeze. It's not a real fix for the general case, of course, but yes, you can do that safely. It means that QEMU will assume that all of your raw images are fully allocated. Kevin > De : Qemu-devel > de la part de Quentin Grolleau > Envoyé : mardi 24 novembre 2020 13:58:53 > à : Kevin Wolf > Cc : qemu-devel@nongnu.org; qemu-bl...@nongnu.org > Objet : RE: [raw] Guest stuck during live live-migration > > Thanks Kevin, > > > > Hello, > > > > > > In our company, we are hosting a large number of Vm, hosted behind > > > Openstack (so libvirt/qemu). > > > A large majority of our Vms are runnign with local data only, stored on > > > NVME, and most of them are RAW disks. > > > > > > With Qemu 4.0 (can be even with older version) we see strange > > > live-migration comportement: > > > First of all, 4.0 is relatively old. Generally it is worth retrying with > > the most recent code (git master or 5.2.0-rc2) before having a closer > > look at problems, because it is frustrating to spend considerable time > > debugging an issue and then find out it has already been fixed a year > > ago. > > > I will try to build it the most recent code > > > I will try to build with the most recent code, but it will take me some time > to do it > > > > > - some Vms live migrate at very high speed without issue (> 6 Gbps) > > > - some Vms are running correctly, but migrating at a strange low > > > speed (3Gbps) > > > - some Vms are migrating at a very low speed (1Gbps, sometime less) > > > and during the migration the guest is completely I/O stuck > > > > > > When this issue happen the VM is completly block, iostat in the Vm show > > > us a latency of 30 secs > > > Can you get the stack backtraces of all QEMU threads while the VM is > > blocked (e.g. with gdb or pstack)? > > (gdb) thread apply all bt > > Thread 20 (Thread 0x7f8a0effd700 (LWP 201248)): > #0 pthread_cond_wait@@GLIBC_2.3.2 () at > ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 > #1 0x56520139878b in qemu_cond_wait_impl (cond=0x5652020f27b0, > mutex=0x5652020f27e8, file=0x5652014e4178 > "/root/qemu_debug_LSEEK/qemu_debug/qemu/ui/vnc-jobs.c", line=214) at > /root/qemu_debug_LSEEK/qemu_debug/qemu/util/qemu-thread-posix.c:161 > #2 0x5652012a264d in vnc_worker_thread_loop > (queue=queue@entry=0x5652020f27b0) at > /root/qemu_debug_LSEEK/qemu_debug/qemu/ui/vnc-jobs.c:214 > #3 0x5652012a2c18 in vnc_worker_thread (arg=arg@entry=0x5652020f27b0) at > /root/qemu_debug_LSEEK/qemu_debug/qemu/ui/vnc-jobs.c:324 > #4 0x565201398116 in qemu_thread_start (args=) at > /root/qemu_debug_LSEEK/qemu_debug/qemu/util/qemu-thread-posix.c:502 > #5 0x7f8a5e24a6ba in start_thread (arg=0x7f8a0effd700) at > pthread_create.c:333 > #6 0x7f8a5df8041d in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 > > Thread 19 (Thread 0x7f8a0700 (LWP 201222)): > #0 __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 > #1 0x7f8a5e24cdbd in __GI___pthread_mutex_lock > (mutex=mutex@entry=0x565201adb680 ) at > ../nptl/pthread_mutex_lock.c:80 > #2 0x565201398263 in qemu_mutex_lock_impl (mutex=0x565201adb680 > , file=0x5652013d7c68 > "/root/qemu_debug_LSEEK/qemu_debug/qemu/accel/kvm/kvm-all.c", line=2089) at > /root/qemu_debug_LSEEK/qemu_debug/qemu/util/qemu-thread-posix.c:66 > #3 0x565200f7d00e in qemu_mutex_lock_iothread_impl > (file=file@entry=0x5652013d7c68 > "/root/qemu_debug_LSEEK/qemu_debug/qemu/accel/kvm/kvm-all.c", > line=line@entry=2089) at /root/qemu_debug_LSEEK/qemu_debug/qemu/cpus.c:1850 > #4 0x565200fa7ca8 in kvm_cpu_exec (cpu=cpu@entry=0x565202354480) at > /root/qemu_debug_LSEEK/qemu_debug/qemu/accel/kvm/kvm-all.c:2089 > #5 0x565200f7d1ce in qemu_kvm_cpu_thread_fn > (arg=arg@entry=0x565202354480) at > /root/qemu_debug_LSEEK/qemu_debug/qemu/cpus.c:1281 > #6 0x565201398116 in qemu_thread_start (args=) at > /root/qemu_debug_LSEEK/qemu_debug/qemu/util/qemu-thread-posix.c:502 > #7 0x7f8a5e24a6ba in start_thread (arg=0x7f8a0700) at > pthread_create.c:333 > #8 0x7f8a5df8041d in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 > > Thread 18 (Thread 0x7f8a2cff9700 (LWP 201221)): > #0 __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 > #1 0x7f8a5e24cdbd in __GI___pthread_mutex_lock > (mutex=mutex@entry=0x565201adb680 ) at > ../nptl/pthread_mutex_lock.c:80 > #2 0x565201398263 in qemu_mutex_lock_impl (mutex=0x565201adb680 > , file=0x5652013d7c68 > "/root/qemu_debug_LSEEK/qemu_debug/qemu/accel/kvm/kvm-all.c", line=2089) at >
[PATCH] hw/pci-host/pam: Replace magic number by PAM_REGIONS_COUNT definition
While this change helps triskaidekaphobic developers, it
is a good practice to avoid magic values and using constant
definitions instead.
Introduce the PAM_REGIONS_COUNT and use it. No logical change.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/pci-host/i440fx.h | 2 +-
include/hw/pci-host/pam.h| 2 ++
include/hw/pci-host/q35.h| 2 +-
hw/pci-host/pam.c| 2 +-
hw/pci-host/q35.c| 2 +-
5 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/include/hw/pci-host/i440fx.h b/include/hw/pci-host/i440fx.h
index 6c16eaf876d..24fd53942ca 100644
--- a/include/hw/pci-host/i440fx.h
+++ b/include/hw/pci-host/i440fx.h
@@ -29,7 +29,7 @@ struct PCII440FXState {
MemoryRegion *system_memory;
MemoryRegion *pci_address_space;
MemoryRegion *ram_memory;
-PAMMemoryRegion pam_regions[13];
+PAMMemoryRegion pam_regions[PAM_REGIONS_COUNT];
MemoryRegion smram_region;
MemoryRegion smram, low_smram;
};
diff --git a/include/hw/pci-host/pam.h b/include/hw/pci-host/pam.h
index fec5cd35d60..c1fd06ba2ae 100644
--- a/include/hw/pci-host/pam.h
+++ b/include/hw/pci-host/pam.h
@@ -80,6 +80,8 @@
#define SMRAM_C_BASE_SEG_MASK ((uint8_t)0x7)
#define SMRAM_C_BASE_SEG ((uint8_t)0x2) /* hardwired to b010 */
+#define PAM_REGIONS_COUNT 13
+
typedef struct PAMMemoryRegion {
MemoryRegion alias[4]; /* index = PAM value */
unsigned current;
diff --git a/include/hw/pci-host/q35.h b/include/hw/pci-host/q35.h
index bbb95817656..ab989698ef8 100644
--- a/include/hw/pci-host/q35.h
+++ b/include/hw/pci-host/q35.h
@@ -44,7 +44,7 @@ struct MCHPCIState {
MemoryRegion *pci_address_space;
MemoryRegion *system_memory;
MemoryRegion *address_space_io;
-PAMMemoryRegion pam_regions[13];
+PAMMemoryRegion pam_regions[PAM_REGIONS_COUNT];
MemoryRegion smram_region, open_high_smram;
MemoryRegion smram, low_smram, high_smram;
MemoryRegion tseg_blackhole, tseg_window;
diff --git a/hw/pci-host/pam.c b/hw/pci-host/pam.c
index a4962057833..454dd120db9 100644
--- a/hw/pci-host/pam.c
+++ b/hw/pci-host/pam.c
@@ -62,7 +62,7 @@ void init_pam(DeviceState *dev, MemoryRegion *ram_memory,
void pam_update(PAMMemoryRegion *pam, int idx, uint8_t val)
{
-assert(0 <= idx && idx <= 12);
+assert(0 <= idx && idx < PAM_REGIONS_COUNT);
memory_region_set_enabled(>alias[pam->current], false);
pam->current = (val >> ((!(idx & 1)) * 4)) & PAM_ATTR_MASK;
diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
index b67cb9c29f8..2eb729dff58 100644
--- a/hw/pci-host/q35.c
+++ b/hw/pci-host/q35.c
@@ -641,7 +641,7 @@ static void mch_realize(PCIDevice *d, Error **errp)
init_pam(DEVICE(mch), mch->ram_memory, mch->system_memory,
mch->pci_address_space, >pam_regions[0],
PAM_BIOS_BASE, PAM_BIOS_SIZE);
-for (i = 0; i < 12; ++i) {
+for (i = 0; i < ARRAY_SIZE(mch->pam_regions) - 1; ++i) {
init_pam(DEVICE(mch), mch->ram_memory, mch->system_memory,
mch->pci_address_space, >pam_regions[i+1],
PAM_EXPAN_BASE + i * PAM_EXPAN_SIZE, PAM_EXPAN_SIZE);
--
2.26.2
Re: [PATCH] ide:atapi: check io_buffer_index in ide_atapi_cmd_reply_end
On 02/12/20 14:17, P J P wrote: Hi, [doing a combined reply] +-- On Tue, 1 Dec 2020, Philippe Mathieu-Daudé wrote --+ | Is it possible to release the reproducer to the community, so we can work on | a fix and test it? * No, we can not release/share reproducers on a public list. We do not need researchers to release or share reproducers though, we "only" encourage people who contribute bugfixes (esp. for security-sensitive issues) to add a qtest testcase. Often the testcase would have no resemblance to the original reproducer (or even always, except for fuzzed issues). Would that be allowed? If not, we have a problem, because it means we cannot follow the basic principle of regression testing. * I've been doing the patch work out of my own interest. Ok, that at least wasn't clear to me. Thanks for making it clearer. Paolo
[PATCH] i386/cpu: Fix Icelake Server model number
See arch/x86/include/asm/intel-family.h in the Kernel:
#define INTEL_FAM6_ICELAKE_X 0x6A
Signed-off-by: Tim Wiederhake
---
target/i386/cpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 5a8c96072e..67e3f92f98 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -3381,7 +3381,7 @@ static X86CPUDefinition builtin_x86_defs[] = {
.level = 0xd,
.vendor = CPUID_VENDOR_INTEL,
.family = 6,
-.model = 134,
+.model = 106,
.stepping = 0,
.features[FEAT_1_EDX] =
CPUID_VME | CPUID_SSE2 | CPUID_SSE | CPUID_FXSR | CPUID_MMX |
--
2.26.2
Re: [PATCH] tests/acceptance: fix timeout for vm.wait
On 12/2/20 1:31 AM, Pavel Dovgalyuk wrote: This patch adds timeout parameter to vm.wait() calls, because the default value is just 30 seconds, and tests may last for more time. This doesn't sound right -- the timeout isn't meant to be for the entire duration of the test, the timeout is from the time of issuing a shutdown command until the time the VM actually shuts down. Ideally, that should not take a particularly long time in a well-behaved test. Why is it lasting longer than 30 seconds? These are complex Linux boot tests. Such loading process could take more than 30 seconds. E.g., BootLinux tests have timeout of 900 seconds. This timeout should only count towards the time spent *shutting down*, not the time to run the entire test. 30 seconds used to be enough time for this to happen on gitlab, if it's taking longer than that I am worried that something has gone wrong. Where were the failures observed, and on what tests? Are there logs I can review? --js
[PATCH v2 4/4] block/export: avoid g_return_val_if() input validation
Do not validate input with g_return_val_if(). This API is intended for
checking programming errors and is compiled out with -DG_DISABLE_CHECKS.
Use an explicit if statement for input validation so it cannot
accidentally be compiled out.
Suggested-by: Markus Armbruster
Signed-off-by: Stefan Hajnoczi
---
block/export/vhost-user-blk-server.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/block/export/vhost-user-blk-server.c
b/block/export/vhost-user-blk-server.c
index 62672d1cb9..bccbc98d57 100644
--- a/block/export/vhost-user-blk-server.c
+++ b/block/export/vhost-user-blk-server.c
@@ -267,7 +267,11 @@ vu_blk_get_config(VuDev *vu_dev, uint8_t *config, uint32_t
len)
VuServer *server = container_of(vu_dev, VuServer, vu_dev);
VuBlkExport *vexp = container_of(server, VuBlkExport, vu_server);
-g_return_val_if_fail(len <= sizeof(struct virtio_blk_config), -1);
+if (len > sizeof(struct virtio_blk_config)) {
+error_report("Invalid get_config len %u, expected <= %zu",
+ len, sizeof(struct virtio_blk_config));
+return -1;
+}
memcpy(config, >blkcfg, len);
return 0;
--
2.28.0
Re: [PATCH 24/29] migration, vl: start migration via qmp_migrate_incoming
On 02/12/20 14:10, Dr. David Alan Gilbert wrote:
I'm more worried about how this stops a repeated 'migrate incoming'
or a 'migrate_incoming' that's issued following a qemu that's been
started with -incoming tcp:... but which a socket hasn't yet connected
to.
Good question, fortunately it is simply handled answer:
void qmp_migrate_incoming(const char *uri, Error **errp)
{
Error *local_err = NULL;
static bool once = true;
if (!once) {
error_setg(errp, "The incoming migration has already been
started");
return;
}
if (!runstate_check(RUN_STATE_INMIGRATE)) {
error_setg(errp, "'-incoming' was not specified on the command
line");
return;
}
qemu_start_incoming_migration(uri, _err);
if (local_err) {
error_propagate(errp, local_err);
return;
}
once = false;
}
This patch can simplify things because every incoming migrations (no
matter if '-incoming defer' or '-incoming tcp:...') goes through the
qmp_migrate_incoming function above.
Paolo
Re: [PATCH] ide:atapi: check io_buffer_index in ide_atapi_cmd_reply_end
On 12/2/20 2:17 PM, P J P wrote: > +-- On Tue, 1 Dec 2020, Philippe Mathieu-Daudé wrote --+ > | Is it possible to release the reproducer to the community, so we can work > on > | a fix and test it? > > * No, we can not release/share reproducers on a public list. > > * We can request reporters to do so by their volition. > [...] > > * Even then, we'll need to ask reporter's permission before sharing their > reproducers on a public list OR with non-members. > > * Best is if reporters share/release reproducers themselves. Maybe we can > have > a public git repository and they can send a PR to include their reproducers > in the repository. While EDK2 security workflow has its own drawbacks (inherent to the project), a fair part is to ask the reporter to attach its reproducer to the private BZ, then when the embargo expires the BZ becomes public (as the reproducer). Thus the community can look at how the bug was handled, how it was reviewed/tested, by who, etc. https://github.com/tianocore/tianocore.github.io/wiki/Reporting-Security-Issues > > * That way multiple reproducers for the same issue can be held together.
Re: [PATCH 00/18] qapi/qom: QAPIfy object-add
On Wed, Dec 02, 2020 at 02:26:44PM +0100, Paolo Bonzini wrote:
> On 02/12/20 13:51, Eduardo Habkost wrote:
> > > > I'm liking the direction this is taking. However, I would still
> > > > like to have a clearer and feasible plan that would work for
> > > > -device, -machine, and -cpu.
> > >
> > > -cpu is not a problem since it's generally created with a static
> > > configuration (now done with global properties, in the future it could be
> > > a
> > > struct).
> >
> > It is a problem if it requires manually converting existing code
> > defining CPU properties and we don't have a transition plan.
>
> We do not have to convert everything _if_ for some objects there are good
> reasons to do programmatically-generated properties. CPUs might be one of
> those cases (or if we decide to convert them, they might endure some more
> code duplication than other devices because they have so many properties).
OK, we just need to agree on what the transition will look like
when we do it. I think we should put as much care into
transition/glue infrastructure as we put into the new
infrastructure.
>
> > Would a -device conversion also involve non-user-creatable
> > devices, or would we keep existing internal usage of QOM
> > properties?
> >
> > Even if it's just for user-creatable devices, getting rid of QOM
> > property usage in devices sounds like a very ambitious goal. I'd
> > like us to have a good transition plan, in addition to declaring
> > what's our ideal end goal.
>
> For user-creatable objects Kevin is doing work in lockstep on all classes;
> but once we have the infrastructure for QAPI object configuration schemas we
> can proceed in the other direction and operate on one device at a time.
>
> With some handwaving, something like (see create_unimplemented_device)
>
> DeviceState *dev = qdev_new(TYPE_UNIMPLEMENTED_DEVICE);
>
> qdev_prop_set_string(dev, "name", name);
> qdev_prop_set_uint64(dev, "size", size);
> sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), _fatal);
>
> might become something like
>
> { 'object': 'unimplemented-device',
> 'config': {
> 'name': 'str',
> 'size': 'size'
> },
> }
>
> DeviceState *dev = qapi_Unimplemented_new(&(
> (UnimplementedDeviceOptions) {
> .name = name,
> .size = size
> }, _fatal);
> object_unref(dev);
>
> (i.e. all typesafe!) and the underlying code would be something like
[...]
>
Looks nice as end goal. Then, these are a few questions I would
have about the transition plan:
Would it require changing both device implementation and device
users in lockstep? Should we have a compatibility layer to allow
existing qdev_new()+qdev_prop_set_*() code to keep working after
the devices are converted to the new system? If not, why not?
If we add a compatibility layer, is the end goal to convert all
existing qdev_new() users to the new system? If yes, why? If
not, why not?
What about subclasses? Would base classes need to be converted
in lockstep with all subclasses? How would the transition
process of (e.g.) PCI devices look like?
--
Eduardo
Re: virtiofsd-rs: A rust virtiofs daemon
On Wed, Dec 02, 2020 at 12:34:10PM +, Dr. David Alan Gilbert wrote: > Sergio has been working on virtiofsd-rs, a virtiofs daemon > written in rust, and which can be found at: > > https://gitlab.com/virtio-fs/virtiofsd-rs > > It started life originally as part of the crosvm project, got > ported to vhost-user as part of the Cloud Hypervisor project, and > has now been split out. > > While the C version of virtiofsd isn't going away for now, the hope > is to stabilise virtiofsd-rs, add some missing features and start > preferentially adding new features and new work onto the Rust version > rather than the C version. > > So please try it, and let the list (and Sergio!) know how you get on. Awesome, really happy that the Rust daemon has come so far. Thanks Chirantan, Sebastien, Sergio, and everyone else who developed it. I talked to Sergio and he is currently looking at what's missing for feature parity with C virtiofsd. This is an opportunity for anyone who wants to contribute. Stefan signature.asc Description: PGP signature
Re: check-tcg errors (build-user, build-user-plugins) again
On 12/2/20 1:52 PM, Alex Bennée wrote: > > Claudio Fontana writes: > >> On 12/2/20 12:16 PM, Alex Bennée wrote: >>> >>> Claudio Fontana writes: >>> Hi Alex and all, when trying to use check-tcg (master), I am getting often these errors: $ ../configure --disable-system --disable-tools $ make -j12 check-tcg ERRO[] cannot find mappings for user claudio: No subgid ranges found for group "claudio" in /etc/subgid ERRO[] cannot find mappings for user claudio: No subgid ranges found for group "claudio" in /etc/subgid ERRO[] cannot find mappings for user claudio: No subgid ranges found for group "claudio" in /etc/subgid Trying to pull registry.gitlab.com/qemu-project/qemu/qemu/debian11... Trying to pull registry.gitlab.com/qemu-project/qemu/qemu/fedora-cris-cross... Trying to pull registry.gitlab.com/qemu-project/qemu/qemu/debian10... ERRO[] cannot find mappings for user claudio: No subgid ranges found for group "claudio" in /etc/subgid [...] TESTlinux-test on x86_64 timeout: failed to run command ‘/home/claudio/git/qemu/build/qemu-x86_64’timeout: : No such file or directoryfailed to run command ‘/home/claudio/git/qemu/build/qemu-x86_64’ [...] Is there some pre-configuration on the host necessary to be able to run check-tcg? >>> >>> There shouldn't be but those errors remind me of some of the tweaks I >>> had to make to me Gentoo system when using podman (instead of docker). >>> In the end I think I just ended up adding the lines: >>> >>> alex:10:65536 >>> >>> to /etc/subgid and /etc/subgid- >>> >>> Marc-André may have some better pointers as he added podman support to >>> the builder scripts. >> >> >> I did that and things seem a bit better, but still a lot of errors: >> >> >> 63 ../sysdeps/x86_64/start.S: No such file or directory. >> >> Error: error creating build container: The following failures happened while >> trying to pull image specified by "debian:bullseye-slim" based on search >> registries in /etc/containers/registries.conf: >> * "localhost/debian:bullseye-slim": Error initializing source >> docker://localhost/debian:bullseye-slim: error pinging docker registry >> localhost: Get https://localhost/v2/: dial tcp [::1]:443: connect: >> connection refused >> * "docker.io/library/debian:bullseye-slim": Error committing the finished >> image: error adding layer with blob >> "sha256:ae63fcbbc3b289e425e4c8840ccde4314f4a060cbc0345e6871a28bdc72f6fe8": >> Error processing tar file(exit status 1): there might not be enough IDs >> available in the namespace (requested 0:42 for /etc/gshadow): lchown >> /etc/gshadow: invalid argument >> Traceback (most recent call last): >> File "/home/claudio/git/qemu-pristine/qemu/tests/docker/docker.py", line >> 709, in >> sys.exit(main()) >> File "/home/claudio/git/qemu-pristine/qemu/tests/docker/docker.py", line >> 705, in main >> return args.cmdobj.run(args, argv) >> File "/home/claudio/git/qemu-pristine/qemu/tests/docker/docker.py", line >> 501, in run >> extra_files_cksum=cksum) >> File "/home/claudio/git/qemu-pristine/qemu/tests/docker/docker.py", line >> 354, in build_image >> quiet=quiet) >> File "/home/claudio/git/qemu-pristine/qemu/tests/docker/docker.py", line >> 244, in _do_check >> return subprocess.check_call(self._command + cmd, **kwargs) >> File "/usr/lib64/python3.6/subprocess.py", line 311, in check_call >> raise CalledProcessError(retcode, cmd) >> >> >> [...] >> Error: error pulling image >> "registry.gitlab.com/qemu-project/qemu/qemu/fedora-cris-cross": unable to >> pull registry.gitlab.com/qemu-project/ >> > > I'm guessing this can be fixed by adding gitlab to > /etc/containers/registries.conf Hi Alex, I added: [registries.search] registries = ["docker.io", "registry.gitlab.com"] I get: Storing signatures Error processing tar file(exit status 1): there might not be enough IDs available in the namespace (requested 0:42 for /etc/gshadow): lchown /etc/gshadow: invalid argument Error: error pulling image "registry.gitlab.com/qemu-project/qemu/qemu/debian11": unable to pull registry.gitlab.com/qemu-project/qemu/qemu/debian11: unable to pull image: Error committing the finished image: error adding layer with blob "sha256:ae63fcbbc3b289e425e4c8840ccde4314f4a060cbc0345e6871a28bdc72f6fe8": Error processing tar file(exit status 1): there might not be enough IDs available in the namespace (requested 0:42 for /etc/gshadow): lchown /etc/gshadow: invalid argument Any idea? > > I'll see if I can resurrect my podman setup because it was working before > we added the caching from gitlab. > >> [...] >> >> >> >>> >>> The main difference between the images on the registry and the local >>> versions is most add the current user so there is a clean mapping >>> between the container user and the
Re: [RFC PATCH v2 0/5] eBPF RSS support for virtio-net
Jason Wang writes: > On 2020/11/19 下午7:13, Andrew Melnychenko wrote: >> This set of patches introduces the usage of eBPF for packet steering >> and RSS hash calculation: >> * RSS(Receive Side Scaling) is used to distribute network packets to >> guest virtqueues by calculating packet hash >> * Additionally adding support for the usage of RSS with vhost >> >> The eBPF works on kernels 5.8+ >> On earlier kerneld it fails to load and the RSS feature is reported >> only without vhost and implemented in 'in-qemu' software. >> >> Implementation notes: >> Linux TAP TUNSETSTEERINGEBPF ioctl was used to set the eBPF program. >> Added libbpf dependency and eBPF support. >> The eBPF program is part of the qemu and presented as an array >> of BPF ELF file data. >> The compilation of eBPF is not part of QEMU build and can be done >> using provided Makefile.ebpf(need to adjust 'linuxhdrs'). >> Added changes to virtio-net and vhost, primary eBPF RSS is used. >> 'in-qemu' RSS used in the case of hash population and as a fallback option. >> For vhost, the hash population feature is not reported to the guest. >> >> Please also see the documentation in PATCH 5/5. >> >> I am sending those patches as RFC to initiate the discussions and get >> feedback on the following points: >> * Fallback when eBPF is not supported by the kernel >> * Live migration to the kernel that doesn't have eBPF support >> * Integration with current QEMU build >> * Additional usage for eBPF for packet filtering >> >> Known issues: >> * hash population not supported by eBPF RSS: 'in-qemu' RSS used >> as a fallback, also, hash population feature is not reported to guests >> with vhost. >> * big-endian BPF support: for now, eBPF isn't supported on >> big-endian systems. Can be added in future if required. >> * huge .h file with eBPF binary. The size of .h file containing >> eBPF binary is currently ~5K lines, because the binary is built with debug >> information. >> The binary without debug/BTF info can't be loaded by libbpf. >> We're looking for possibilities to reduce the size of the .h files. > > > Adding Toke for sharing more idea from eBPF side. > > We had some discussion on the eBPF issues: > > 1) Whether or not to use libbpf. Toke strongly suggest to use libbpf > 2) Whether or not to use BTF. Toke confirmed that if we don't access any > skb metadata, BTF is not strictly required for CO-RE. But it might still > useful for e.g debugging. > 3) About the huge (5K lines, see patch #2 Toke). Toke confirmed that we > can strip debug symbols, but Yuri found some sections can't be stripped, > we can keep discussing here. I just tried simply running 'strip' on a sample trivial XDP program, which brought its size down from ~5k to ~1k and preserved the BTF information without me having to do anything. As a side note, though, instead of embedding the BPF program into a .h, you could simply ship it as a .o and load it from the file system. We do that with xdp-tools and install the bpf object files into /usr/$LIB/bpf/. -Toke
[PATCH v2 1/2] hw/ssi: imx_spi: Use a macro for number of chip selects supported
From: Bin Meng
Avoid using a magic number (4) everywhere for the number of chip
selects supported.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
---
(no changes since v1)
hw/ssi/imx_spi.c | 4 ++--
include/hw/ssi/imx_spi.h | 5 -
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/hw/ssi/imx_spi.c b/hw/ssi/imx_spi.c
index d8885ae454..e605049a21 100644
--- a/hw/ssi/imx_spi.c
+++ b/hw/ssi/imx_spi.c
@@ -361,7 +361,7 @@ static void imx_spi_write(void *opaque, hwaddr offset,
uint64_t value,
/* We are in master mode */
-for (i = 0; i < 4; i++) {
+for (i = 0; i < ECSPI_NUM_CS; i++) {
qemu_set_irq(s->cs_lines[i],
i == imx_spi_selected_channel(s) ? 0 : 1);
}
@@ -424,7 +424,7 @@ static void imx_spi_realize(DeviceState *dev, Error **errp)
sysbus_init_mmio(SYS_BUS_DEVICE(dev), >iomem);
sysbus_init_irq(SYS_BUS_DEVICE(dev), >irq);
-for (i = 0; i < 4; ++i) {
+for (i = 0; i < ECSPI_NUM_CS; ++i) {
sysbus_init_irq(SYS_BUS_DEVICE(dev), >cs_lines[i]);
}
diff --git a/include/hw/ssi/imx_spi.h b/include/hw/ssi/imx_spi.h
index b82b17f364..eeaf49bbac 100644
--- a/include/hw/ssi/imx_spi.h
+++ b/include/hw/ssi/imx_spi.h
@@ -77,6 +77,9 @@
#define EXTRACT(value, name) extract32(value, name##_SHIFT, name##_LENGTH)
+/* number of chip selects supported */
+#define ECSPI_NUM_CS 4
+
#define TYPE_IMX_SPI "imx.spi"
OBJECT_DECLARE_SIMPLE_TYPE(IMXSPIState, IMX_SPI)
@@ -89,7 +92,7 @@ struct IMXSPIState {
qemu_irq irq;
-qemu_irq cs_lines[4];
+qemu_irq cs_lines[ECSPI_NUM_CS];
SSIBus *bus;
--
2.25.1
[PATCH v2 2/2] hw/ssi: imx_spi: Disable chip selects in imx_spi_reset()
From: Xuzhou Cheng
When a write to ECSPI_CONREG register to disable the SPI controller,
imx_spi_reset() is called to reset the controller, during which CS
lines should have been disabled, otherwise the state machine of any
devices (e.g.: SPI flashes) connected to the SPI master is stuck to
its last state and responds incorrectly to any follow-up commands.
Fixes: c906a3a01582 ("i.MX: Add the Freescale SPI Controller")
Signed-off-by: Xuzhou Cheng
Signed-off-by: Bin Meng
Acked-by: Alistair Francis
---
Changes in v2:
- Fix the "Fixes" tag in the commit message
hw/ssi/imx_spi.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/hw/ssi/imx_spi.c b/hw/ssi/imx_spi.c
index e605049a21..85c172e815 100644
--- a/hw/ssi/imx_spi.c
+++ b/hw/ssi/imx_spi.c
@@ -231,6 +231,7 @@ static void imx_spi_flush_txfifo(IMXSPIState *s)
static void imx_spi_reset(DeviceState *dev)
{
IMXSPIState *s = IMX_SPI(dev);
+int i;
DPRINTF("\n");
@@ -243,6 +244,10 @@ static void imx_spi_reset(DeviceState *dev)
imx_spi_update_irq(s);
+for (i = 0; i < ECSPI_NUM_CS; i++) {
+qemu_set_irq(s->cs_lines[i], 1);
+}
+
s->burst_length = 0;
}
--
2.25.1
[PATCH v2 3/4] contrib/vhost-user-input: avoid g_return_val_if() input validation
Do not validate input with g_return_val_if(). This API is intended for
checking programming errors and is compiled out with -DG_DISABLE_CHECKS.
Use an explicit if statement for input validation so it cannot
accidentally be compiled out.
Suggested-by: Markus Armbruster
Signed-off-by: Stefan Hajnoczi
---
contrib/vhost-user-input/main.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/contrib/vhost-user-input/main.c b/contrib/vhost-user-input/main.c
index 6020c6f33a..1d79c61200 100644
--- a/contrib/vhost-user-input/main.c
+++ b/contrib/vhost-user-input/main.c
@@ -212,7 +212,11 @@ static int vi_get_config(VuDev *dev, uint8_t *config,
uint32_t len)
{
VuInput *vi = container_of(dev, VuInput, dev.parent);
-g_return_val_if_fail(len <= sizeof(*vi->sel_config), -1);
+if (len > sizeof(*vi->sel_config)) {
+g_critical("%s: len %u is larger than %zu",
+ __func__, len, sizeof(*vi->sel_config));
+return -1;
+}
if (vi->sel_config) {
memcpy(config, vi->sel_config, len);
--
2.28.0
[PATCH 4/9] target/mips: Simplify MSA TCG logic
Only decode MSA opcodes if MSA is present (implemented).
Now than check_msa_access() will only be called if MSA is
present, the only way to have MIPS_HFLAG_MSA unset is if
MSA is disabled (bit CP0C5_MSAEn cleared, see previous
commit). Therefore we can remove the 'reserved instruction'
exception.
Signed-off-by: Philippe Mathieu-Daudé
---
target/mips/translate.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/target/mips/translate.c b/target/mips/translate.c
index 803ffefba2c..a05c25e50b8 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -28697,13 +28697,8 @@ static inline int check_msa_access(DisasContext *ctx)
}
if (unlikely(!(ctx->hflags & MIPS_HFLAG_MSA))) {
-if (ctx->insn_flags & ASE_MSA) {
-generate_exception_end(ctx, EXCP_MSADIS);
-return 0;
-} else {
-generate_exception_end(ctx, EXCP_RI);
-return 0;
-}
+generate_exception_end(ctx, EXCP_MSADIS);
+return 0;
}
return 1;
}
@@ -30547,7 +30542,7 @@ static void gen_msa_vec(CPUMIPSState *env, DisasContext
*ctx)
static void gen_msa(CPUMIPSState *env, DisasContext *ctx)
{
uint32_t opcode = ctx->opcode;
-check_insn(ctx, ASE_MSA);
+
check_msa_access(ctx);
switch (MASK_MSA_MINOR(opcode)) {
@@ -31194,9 +31189,10 @@ static void decode_opc(CPUMIPSState *env, DisasContext
*ctx)
case OPC_BNZ_H:
case OPC_BNZ_W:
case OPC_BNZ_D:
-check_insn(ctx, ASE_MSA);
-gen_msa_branch(env, ctx, op1);
-break;
+if (ase_msa_available(env)) {
+gen_msa_branch(env, ctx, op1);
+break;
+}
default:
MIPS_INVAL("cp1");
generate_exception_end(ctx, EXCP_RI);
@@ -31385,7 +31381,9 @@ static void decode_opc(CPUMIPSState *env, DisasContext
*ctx)
#endif
} else {
/* MDMX: Not implemented. */
-gen_msa(env, ctx);
+if (ase_msa_available(env)) {
+gen_msa(env, ctx);
+}
}
break;
case OPC_PCREL:
--
2.26.2
[PATCH 5/9] target/mips: Remove now unused ASE_MSA definition
We don't use ASE_MSA anymore (replaced by ase_msa_available()
checking MSAP bit from CP0_Config3). Remove it.
Signed-off-by: Philippe Mathieu-Daudé
---
target/mips/mips-defs.h | 1 -
target/mips/translate_init.c.inc | 8
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/target/mips/mips-defs.h b/target/mips/mips-defs.h
index ed6a7a9e545..805034b8956 100644
--- a/target/mips/mips-defs.h
+++ b/target/mips/mips-defs.h
@@ -45,7 +45,6 @@
#define ASE_MT0x4000ULL
#define ASE_SMARTMIPS 0x8000ULL
#define ASE_MICROMIPS 0x0001ULL
-#define ASE_MSA 0x0002ULL
/*
* bits 40-51: vendor-specific base instruction sets
*/
diff --git a/target/mips/translate_init.c.inc b/target/mips/translate_init.c.inc
index 3b069190ed8..2170f8ace6f 100644
--- a/target/mips/translate_init.c.inc
+++ b/target/mips/translate_init.c.inc
@@ -408,7 +408,7 @@ const mips_def_t mips_defs[] =
.CP1_fcr31_rw_bitmask = 0xFF83,
.SEGBITS = 32,
.PABITS = 40,
-.insn_flags = CPU_MIPS32R5 | ASE_MSA,
+.insn_flags = CPU_MIPS32R5,
.mmu_type = MMU_TYPE_R4000,
},
{
@@ -719,7 +719,7 @@ const mips_def_t mips_defs[] =
.MSAIR = 0x03 << MSAIR_ProcID,
.SEGBITS = 48,
.PABITS = 48,
-.insn_flags = CPU_MIPS64R6 | ASE_MSA,
+.insn_flags = CPU_MIPS64R6,
.mmu_type = MMU_TYPE_R4000,
},
{
@@ -759,7 +759,7 @@ const mips_def_t mips_defs[] =
.MSAIR = 0x03 << MSAIR_ProcID,
.SEGBITS = 48,
.PABITS = 48,
-.insn_flags = CPU_MIPS64R6 | ASE_MSA,
+.insn_flags = CPU_MIPS64R6,
.mmu_type = MMU_TYPE_R4000,
},
{
@@ -885,7 +885,7 @@ const mips_def_t mips_defs[] =
.CP1_fcr31_rw_bitmask = 0xFF83,
.SEGBITS = 48,
.PABITS = 48,
-.insn_flags = CPU_LOONGSON3A | ASE_MSA,
+.insn_flags = CPU_LOONGSON3A,
.mmu_type = MMU_TYPE_R4000,
},
{
--
2.26.2
[PATCH v3 00/10] hvf: Implement Apple Silicon Support
Now that Apple Silicon is widely available, people are obviously excited to try and run virtualized workloads on them, such as Linux and Windows. This patch set implements a fully functional version to get the ball going on that. With this applied, I can successfully run both Linux and Windows as guests. I am not aware of any limitations specific to Hypervisor.framework apart from: - Live migration / savevm - gdbstub debugging (SP register) Enjoy! Alex v1 -> v2: - New patch: hvf: Actually set SIG_IPI mask - New patch: hvf: Introduce hvf vcpu struct - New patch: hvf: arm: Mark CPU as dirty on reset - Removed patch: hw/arm/virt: Disable highmem when on hypervisor.framework - Removed patch: arm: Synchronize CPU on PSCI on - Fix build on 32bit arm - Merge vcpu kick function patch into ARM enablement - Implement WFI handling (allows vCPUs to sleep) - Synchronize system registers (fixes OVMF crashes and reboot) - Don't always call cpu_synchronize_state() - Use more fine grained iothread locking - Populate aa64mmfr0 from hardware - Make safe to ctrl-C entitlement application v2 -> v3: - Removed patch: hvf: Actually set SIG_IPI mask - New patch: hvf: arm: Add support for GICv3 - New patch: hvf: arm: Implement -cpu host - Advance PC on SMC - Use cp list interface for sysreg syncs - Do not set current_cpu - Fix sysreg isread mask - Move sysreg handling to functions - Remove WFI logic again - Revert to global iothread locking Alexander Graf (9): hvf: Add hypervisor entitlement to output binaries hvf: Move common code out hvf: Introduce hvf vcpu struct arm: Set PSCI to 0.2 for HVF hvf: arm: Mark CPU as dirty on reset hvf: Add Apple Silicon support arm: Add Hypervisor.framework build target hvf: arm: Add support for GICv3 hvf: arm: Implement -cpu host Peter Collingbourne (1): arm/hvf: Add a WFI handler MAINTAINERS | 14 +- accel/hvf/entitlements.plist | 8 + accel/hvf/hvf-all.c | 56 +++ accel/hvf/hvf-cpus.c | 481 accel/hvf/meson.build| 7 + accel/meson.build| 1 + include/hw/core/cpu.h| 3 +- include/sysemu/hvf.h | 2 + include/sysemu/hvf_int.h | 77 meson.build | 41 +- scripts/entitlement.sh | 13 + target/arm/arm-powerctl.c| 1 + target/arm/cpu.c | 15 +- target/arm/cpu.h | 2 + target/arm/hvf/hvf.c | 857 +++ target/arm/hvf/meson.build | 3 + target/arm/kvm_arm.h | 2 - target/arm/meson.build | 2 + target/i386/hvf/hvf-cpus.c | 131 -- target/i386/hvf/hvf-cpus.h | 25 - target/i386/hvf/hvf-i386.h | 48 +- target/i386/hvf/hvf.c| 462 +++ target/i386/hvf/meson.build | 1 - target/i386/hvf/vmx.h| 24 +- target/i386/hvf/x86.c| 28 +- target/i386/hvf/x86_descr.c | 26 +- target/i386/hvf/x86_emu.c| 62 +-- target/i386/hvf/x86_mmu.c| 4 +- target/i386/hvf/x86_task.c | 12 +- target/i386/hvf/x86hvf.c | 221 - target/i386/hvf/x86hvf.h | 2 - 31 files changed, 1818 insertions(+), 813 deletions(-) create mode 100644 accel/hvf/entitlements.plist create mode 100644 accel/hvf/hvf-all.c create mode 100644 accel/hvf/hvf-cpus.c create mode 100644 accel/hvf/meson.build create mode 100644 include/sysemu/hvf_int.h create mode 100755 scripts/entitlement.sh create mode 100644 target/arm/hvf/hvf.c create mode 100644 target/arm/hvf/meson.build delete mode 100644 target/i386/hvf/hvf-cpus.c delete mode 100644 target/i386/hvf/hvf-cpus.h -- 2.24.3 (Apple Git-128)
[PATCH v3 09/10] hvf: arm: Add support for GICv3
We currently only support GICv2 emulation. To also support GICv3, we will
need to pass a few system registers into their respective handler functions.
This patch adds handling for all of the required system registers, so that
we can run with more than 8 vCPUs.
Signed-off-by: Alexander Graf
---
target/arm/hvf/hvf.c | 141 +++
1 file changed, 141 insertions(+)
diff --git a/target/arm/hvf/hvf.c b/target/arm/hvf/hvf.c
index 79aeeb237b..dfdf0827e4 100644
--- a/target/arm/hvf/hvf.c
+++ b/target/arm/hvf/hvf.c
@@ -23,6 +23,7 @@
#include "exec/address-spaces.h"
#include "hw/irq.h"
+#include "hw/intc/gicv3_internal.h"
#include "qemu/main-loop.h"
#include "sysemu/accel.h"
#include "sysemu/cpus.h"
@@ -47,6 +48,33 @@
#define SYSREG_CNTPCT_EL0 SYSREG(3, 3, 1, 14, 0)
#define SYSREG_PMCCNTR_EL0SYSREG(3, 3, 0, 9, 13)
+#define SYSREG_ICC_AP0R0_EL1 SYSREG(3, 0, 4, 12, 8)
+#define SYSREG_ICC_AP0R1_EL1 SYSREG(3, 0, 5, 12, 8)
+#define SYSREG_ICC_AP0R2_EL1 SYSREG(3, 0, 6, 12, 8)
+#define SYSREG_ICC_AP0R3_EL1 SYSREG(3, 0, 7, 12, 8)
+#define SYSREG_ICC_AP1R0_EL1 SYSREG(3, 0, 0, 12, 9)
+#define SYSREG_ICC_AP1R1_EL1 SYSREG(3, 0, 1, 12, 9)
+#define SYSREG_ICC_AP1R2_EL1 SYSREG(3, 0, 2, 12, 9)
+#define SYSREG_ICC_AP1R3_EL1 SYSREG(3, 0, 3, 12, 9)
+#define SYSREG_ICC_ASGI1R_EL1SYSREG(3, 0, 6, 12, 11)
+#define SYSREG_ICC_BPR0_EL1 SYSREG(3, 0, 3, 12, 8)
+#define SYSREG_ICC_BPR1_EL1 SYSREG(3, 0, 3, 12, 12)
+#define SYSREG_ICC_CTLR_EL1 SYSREG(3, 0, 4, 12, 12)
+#define SYSREG_ICC_DIR_EL1 SYSREG(3, 0, 1, 12, 11)
+#define SYSREG_ICC_EOIR0_EL1 SYSREG(3, 0, 1, 12, 8)
+#define SYSREG_ICC_EOIR1_EL1 SYSREG(3, 0, 1, 12, 12)
+#define SYSREG_ICC_HPPIR0_EL1SYSREG(3, 0, 2, 12, 8)
+#define SYSREG_ICC_HPPIR1_EL1SYSREG(3, 0, 2, 12, 12)
+#define SYSREG_ICC_IAR0_EL1 SYSREG(3, 0, 0, 12, 8)
+#define SYSREG_ICC_IAR1_EL1 SYSREG(3, 0, 0, 12, 12)
+#define SYSREG_ICC_IGRPEN0_EL1 SYSREG(3, 0, 6, 12, 12)
+#define SYSREG_ICC_IGRPEN1_EL1 SYSREG(3, 0, 7, 12, 12)
+#define SYSREG_ICC_PMR_EL1 SYSREG(3, 0, 0, 4, 6)
+#define SYSREG_ICC_RPR_EL1 SYSREG(3, 0, 3, 12, 11)
+#define SYSREG_ICC_SGI0R_EL1 SYSREG(3, 0, 7, 12, 11)
+#define SYSREG_ICC_SGI1R_EL1 SYSREG(3, 0, 5, 12, 11)
+#define SYSREG_ICC_SRE_EL1 SYSREG(3, 0, 5, 12, 12)
+
#define WFX_IS_WFE (1 << 0)
struct hvf_reg_match {
@@ -419,6 +447,38 @@ void hvf_kick_vcpu_thread(CPUState *cpu)
hv_vcpus_exit(>hvf->fd, 1);
}
+static uint32_t hvf_reg2cp_reg(uint32_t reg)
+{
+return ENCODE_AA64_CP_REG(CP_REG_ARM64_SYSREG_CP,
+ (reg >> 10) & 0xf,
+ (reg >> 1) & 0xf,
+ (reg >> 20) & 0x3,
+ (reg >> 14) & 0x7,
+ (reg >> 17) & 0x7);
+}
+
+static uint64_t hvf_sysreg_read_cp(CPUState *cpu, uint32_t reg)
+{
+ARMCPU *arm_cpu = ARM_CPU(cpu);
+CPUARMState *env = _cpu->env;
+const ARMCPRegInfo *ri;
+uint64_t val = 0;
+
+ri = get_arm_cp_reginfo(arm_cpu->cp_regs, hvf_reg2cp_reg(reg));
+if (ri) {
+if (ri->type & ARM_CP_CONST) {
+val = ri->resetvalue;
+} else if (ri->readfn) {
+val = ri->readfn(env, ri);
+} else {
+val = CPREG_FIELD64(env, ri);
+}
+DPRINTF("vgic read from %s [val=%016llx]", ri->name, val);
+}
+
+return val;
+}
+
static uint64_t hvf_sysreg_read(CPUState *cpu, uint32_t reg)
{
ARMCPU *arm_cpu = ARM_CPU(cpu);
@@ -432,6 +492,39 @@ static uint64_t hvf_sysreg_read(CPUState *cpu, uint32_t
reg)
case SYSREG_PMCCNTR_EL0:
val = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
break;
+case SYSREG_ICC_AP0R0_EL1:
+case SYSREG_ICC_AP0R1_EL1:
+case SYSREG_ICC_AP0R2_EL1:
+case SYSREG_ICC_AP0R3_EL1:
+case SYSREG_ICC_AP1R0_EL1:
+case SYSREG_ICC_AP1R1_EL1:
+case SYSREG_ICC_AP1R2_EL1:
+case SYSREG_ICC_AP1R3_EL1:
+case SYSREG_ICC_ASGI1R_EL1:
+case SYSREG_ICC_BPR0_EL1:
+case SYSREG_ICC_BPR1_EL1:
+case SYSREG_ICC_DIR_EL1:
+case SYSREG_ICC_EOIR0_EL1:
+case SYSREG_ICC_EOIR1_EL1:
+case SYSREG_ICC_HPPIR0_EL1:
+case SYSREG_ICC_HPPIR1_EL1:
+case SYSREG_ICC_IAR0_EL1:
+case SYSREG_ICC_IAR1_EL1:
+case SYSREG_ICC_IGRPEN0_EL1:
+case SYSREG_ICC_IGRPEN1_EL1:
+case SYSREG_ICC_PMR_EL1:
+case SYSREG_ICC_SGI0R_EL1:
+case SYSREG_ICC_SGI1R_EL1:
+case SYSREG_ICC_SRE_EL1:
+val = hvf_sysreg_read_cp(cpu, reg);
+break;
+case SYSREG_ICC_CTLR_EL1:
+val = hvf_sysreg_read_cp(cpu, reg);
+
+/* AP0R registers above 0 don't trap, expose less PRIs to fit */
+val &= ~ICC_CTLR_EL1_PRIBITS_MASK;
+val |= 4 << ICC_CTLR_EL1_PRIBITS_SHIFT;
+break;
default:
DPRINTF("unhandled sysreg read %08x (op0=%d op1=%d op2=%d "
"crn=%d crm=%d)", reg, (reg >> 20) & 0x3,
[PATCH v3 05/10] hvf: arm: Mark CPU as dirty on reset
When clearing internal state of a CPU, we should also make sure that HVF
knows about it and can push the new values down to vcpu state.
Make sure that with HVF enabled, we tell it that it should synchronize
CPU state on next entry after a reset.
This fixes PSCI handling, because now newly pushed state such as X0 and
PC on remote CPU enablement also get pushed into HVF.
Signed-off-by: Alexander Graf
---
target/arm/arm-powerctl.c | 1 +
target/arm/cpu.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/target/arm/arm-powerctl.c b/target/arm/arm-powerctl.c
index b75f813b40..a49a5b32e6 100644
--- a/target/arm/arm-powerctl.c
+++ b/target/arm/arm-powerctl.c
@@ -15,6 +15,7 @@
#include "arm-powerctl.h"
#include "qemu/log.h"
#include "qemu/main-loop.h"
+#include "sysemu/hw_accel.h"
#ifndef DEBUG_ARM_POWERCTL
#define DEBUG_ARM_POWERCTL 0
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index db6f7c34ed..9a501ea4bd 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -411,6 +411,8 @@ static void arm_cpu_reset(DeviceState *dev)
#ifndef CONFIG_USER_ONLY
if (kvm_enabled()) {
kvm_arm_reset_vcpu(cpu);
+} else if (hvf_enabled()) {
+s->vcpu_dirty = true;
}
#endif
--
2.24.3 (Apple Git-128)
[PATCH v3 04/10] arm: Set PSCI to 0.2 for HVF
In Hypervisor.framework, we just pass PSCI calls straight on to the QEMU
emulation
of it. That means, if TCG is compatible with PSCI 0.2, so are we. Let's
transpose
that fact in code too.
Signed-off-by: Alexander Graf
---
target/arm/cpu.c | 4
1 file changed, 4 insertions(+)
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 07492e9f9a..db6f7c34ed 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -1062,6 +1062,10 @@ static void arm_cpu_initfn(Object *obj)
if (tcg_enabled()) {
cpu->psci_version = 2; /* TCG implements PSCI 0.2 */
}
+
+if (hvf_enabled()) {
+cpu->psci_version = 2; /* HVF uses TCG's PSCI */
+}
}
static Property arm_cpu_gt_cntfrq_property =
--
2.24.3 (Apple Git-128)
Re: [RFC PATCH] configure: add --without-default-features
Alex Bennée writes: > By default QEMU enables a lot of features if it can probe and find the > support libraries. It also enables a bunch of features by default. > This patch adds the ability to build --without-default-features which > can be paired with a --without-default-devices for a barely functional > build. > > The main use case for this is testing our build assumptions and for > minimising the amount of stuff you build if you just want to test a > particular feature on your relatively slow emulated test system. > > Signed-off-by: Alex Bennée > --- > configure | 161 ++ > 1 file changed, 89 insertions(+), 72 deletions(-) > > diff --git a/configure b/configure > index 18c26e0389..23fa6f9421 100755 > --- a/configure > +++ b/configure > -oss_lib="" > +oss_lib="$default_feature" As oss_lib gets passed bare as the library to use this bit needs to be dropped. -- Alex Bennée
[PATCH v3 10/10] hvf: arm: Implement -cpu host
Now that we have working system register sync, we push more target CPU
properties into the virtual machine. That might be useful in some
situations, but is not the typical case that users want.
So let's add a -cpu host option that allows them to explicitly pass all
CPU capabilities of their host CPU into the guest.
Signed-off-by: Alexander Graf
---
include/sysemu/hvf.h | 2 ++
target/arm/cpu.c | 9 ++---
target/arm/cpu.h | 2 ++
target/arm/hvf/hvf.c | 41 +
target/arm/kvm_arm.h | 2 --
5 files changed, 51 insertions(+), 5 deletions(-)
diff --git a/include/sysemu/hvf.h b/include/sysemu/hvf.h
index f893768df9..7eb61cf094 100644
--- a/include/sysemu/hvf.h
+++ b/include/sysemu/hvf.h
@@ -19,6 +19,8 @@
#ifdef CONFIG_HVF
uint32_t hvf_get_supported_cpuid(uint32_t func, uint32_t idx,
int reg);
+struct ARMCPU;
+void hvf_arm_set_cpu_features_from_host(struct ARMCPU *cpu);
extern bool hvf_allowed;
#define hvf_enabled() (hvf_allowed)
#else /* !CONFIG_HVF */
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 9a501ea4bd..087c6292b6 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -2279,12 +2279,16 @@ static void arm_cpu_class_init(ObjectClass *oc, void
*data)
#endif
}
-#ifdef CONFIG_KVM
+#if defined(CONFIG_KVM) || defined(CONFIG_HVF)
static void arm_host_initfn(Object *obj)
{
ARMCPU *cpu = ARM_CPU(obj);
+#ifdef CONFIG_KVM
kvm_arm_set_cpu_features_from_host(cpu);
+#else
+hvf_arm_set_cpu_features_from_host(cpu);
+#endif
if (arm_feature(>env, ARM_FEATURE_AARCH64)) {
aarch64_add_sve_properties(obj);
}
@@ -2296,7 +2300,6 @@ static const TypeInfo host_arm_cpu_type_info = {
.parent = TYPE_AARCH64_CPU,
.instance_init = arm_host_initfn,
};
-
#endif
static void arm_cpu_instance_init(Object *obj)
@@ -2355,7 +2358,7 @@ static void arm_cpu_register_types(void)
type_register_static(_cpu_type_info);
-#ifdef CONFIG_KVM
+#if defined(CONFIG_KVM) || defined(CONFIG_HVF)
type_register_static(_arm_cpu_type_info);
#endif
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index e5514c8286..e54963aa8b 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -2823,6 +2823,8 @@ bool write_cpustate_to_list(ARMCPU *cpu, bool kvm_sync);
#define ARM_CPU_TYPE_NAME(name) (name ARM_CPU_TYPE_SUFFIX)
#define CPU_RESOLVING_TYPE TYPE_ARM_CPU
+#define TYPE_ARM_HOST_CPU "host-" TYPE_ARM_CPU
+
#define cpu_signal_handler cpu_arm_signal_handler
#define cpu_list arm_cpu_list
diff --git a/target/arm/hvf/hvf.c b/target/arm/hvf/hvf.c
index dfdf0827e4..9442e2f232 100644
--- a/target/arm/hvf/hvf.c
+++ b/target/arm/hvf/hvf.c
@@ -373,6 +373,47 @@ static uint64_t hvf_get_reg(CPUState *cpu, int rt)
return val;
}
+void hvf_arm_set_cpu_features_from_host(ARMCPU *cpu)
+{
+ARMISARegisters host_isar;
+const struct isar_regs {
+int reg;
+uint64_t *val;
+} regs[] = {
+{ HV_SYS_REG_ID_AA64PFR0_EL1, _isar.id_aa64pfr0 },
+{ HV_SYS_REG_ID_AA64PFR1_EL1, _isar.id_aa64pfr1 },
+{ HV_SYS_REG_ID_AA64DFR0_EL1, _isar.id_aa64dfr0 },
+{ HV_SYS_REG_ID_AA64DFR1_EL1, _isar.id_aa64dfr1 },
+{ HV_SYS_REG_ID_AA64ISAR0_EL1, _isar.id_aa64isar0 },
+{ HV_SYS_REG_ID_AA64ISAR1_EL1, _isar.id_aa64isar1 },
+{ HV_SYS_REG_ID_AA64MMFR0_EL1, _isar.id_aa64mmfr0 },
+{ HV_SYS_REG_ID_AA64MMFR1_EL1, _isar.id_aa64mmfr1 },
+{ HV_SYS_REG_ID_AA64MMFR2_EL1, _isar.id_aa64mmfr2 },
+};
+hv_vcpu_t fd;
+hv_vcpu_exit_t *exit;
+int i;
+
+cpu->dtb_compatible = "arm,arm-v8";
+cpu->env.features = (1ULL << ARM_FEATURE_V8) |
+(1ULL << ARM_FEATURE_NEON) |
+(1ULL << ARM_FEATURE_AARCH64) |
+(1ULL << ARM_FEATURE_PMU) |
+(1ULL << ARM_FEATURE_GENERIC_TIMER);
+
+/* We set up a small vcpu to extract host registers */
+
+assert_hvf_ok(hv_vcpu_create(, , NULL));
+for (i = 0; i < ARRAY_SIZE(regs); i++) {
+assert_hvf_ok(hv_vcpu_get_sys_reg(fd, regs[i].reg, regs[i].val));
+}
+assert_hvf_ok(hv_vcpu_get_sys_reg(fd, HV_SYS_REG_MIDR_EL1, >midr));
+assert_hvf_ok(hv_vcpu_destroy(fd));
+
+cpu->isar = host_isar;
+cpu->reset_sctlr = 0x00c50078;
+}
+
void hvf_arch_vcpu_destroy(CPUState *cpu)
{
}
diff --git a/target/arm/kvm_arm.h b/target/arm/kvm_arm.h
index eb81b7059e..081727a37e 100644
--- a/target/arm/kvm_arm.h
+++ b/target/arm/kvm_arm.h
@@ -214,8 +214,6 @@ bool kvm_arm_create_scratch_host_vcpu(const uint32_t
*cpus_to_try,
*/
void kvm_arm_destroy_scratch_host_vcpu(int *fdarray);
-#define TYPE_ARM_HOST_CPU "host-" TYPE_ARM_CPU
-
/**
* ARMHostCPUFeatures: information about the host CPU (identified
* by asking the host kernel)
--
2.24.3 (Apple Git-128)
Re: [PATCH v2 1/1] Fix to show vfio migration stat in migration status
On Wed, 2 Dec 2020 00:43:14 +0530
Kirti Wankhede wrote:
> Header file where CONFIG_VFIO is defined is not included in migration.c
> file.
>
> Moved populate_vfio_info() to hw/vfio/common.c file. Added its stub in
> stubs/vfio.c file. Updated header files and meson file accordingly.
>
> Fixes: 3710586caa5d ("qapi: Add VFIO devices migration stats in Migration
> stats")
>
> Signed-off-by: Kirti Wankhede
> ---
> hw/vfio/common.c | 12 +++-
> include/hw/vfio/vfio-common.h | 1 -
> include/hw/vfio/vfio.h| 2 ++
> migration/migration.c | 16 +---
> stubs/meson.build | 1 +
> stubs/vfio.c | 7 +++
> 6 files changed, 22 insertions(+), 17 deletions(-)
> create mode 100644 stubs/vfio.c
>
> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> index 6ff1daa763f8..4868c0fef504 100644
> --- a/hw/vfio/common.c
> +++ b/hw/vfio/common.c
> @@ -25,6 +25,7 @@
> #endif
> #include
>
> +#include "qapi/qapi-types-migration.h"
> #include "hw/vfio/vfio-common.h"
> #include "hw/vfio/vfio.h"
> #include "exec/address-spaces.h"
> @@ -292,7 +293,7 @@ const MemoryRegionOps vfio_region_ops = {
> * Device state interfaces
> */
>
> -bool vfio_mig_active(void)
> +static bool vfio_mig_active(void)
> {
> VFIOGroup *group;
> VFIODevice *vbasedev;
> @@ -311,6 +312,15 @@ bool vfio_mig_active(void)
> return true;
> }
>
> +void populate_vfio_info(MigrationInfo *info)
> +{
> +if (vfio_mig_active()) {
> +info->has_vfio = true;
> +info->vfio = g_malloc0(sizeof(*info->vfio));
> +info->vfio->transferred = vfio_mig_bytes_transferred();
> +}
> +}
> +
> static bool vfio_devices_all_saving(VFIOContainer *container)
> {
> VFIOGroup *group;
> diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-common.h
> index 6141162d7aea..cc47bd7d4456 100644
> --- a/include/hw/vfio/vfio-common.h
> +++ b/include/hw/vfio/vfio-common.h
> @@ -205,7 +205,6 @@ extern const MemoryRegionOps vfio_region_ops;
> typedef QLIST_HEAD(VFIOGroupList, VFIOGroup) VFIOGroupList;
> extern VFIOGroupList vfio_group_list;
>
> -bool vfio_mig_active(void);
> int64_t vfio_mig_bytes_transferred(void);
>
> #ifdef CONFIG_LINUX
> diff --git a/include/hw/vfio/vfio.h b/include/hw/vfio/vfio.h
> index 86248f54360a..d1e6f4b26f35 100644
> --- a/include/hw/vfio/vfio.h
> +++ b/include/hw/vfio/vfio.h
> @@ -4,4 +4,6 @@
> bool vfio_eeh_as_ok(AddressSpace *as);
> int vfio_eeh_as_op(AddressSpace *as, uint32_t op);
>
> +void populate_vfio_info(MigrationInfo *info);
> +
> #endif
> diff --git a/migration/migration.c b/migration/migration.c
> index 87a9b59f83f4..c164594c1d8d 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -56,10 +56,7 @@
> #include "net/announce.h"
> #include "qemu/queue.h"
> #include "multifd.h"
> -
> -#ifdef CONFIG_VFIO
> -#include "hw/vfio/vfio-common.h"
> -#endif
> +#include "hw/vfio/vfio.h"
>
> #define MAX_THROTTLE (128 << 20) /* Migration transfer speed
> throttling */
>
> @@ -1041,17 +1038,6 @@ static void populate_disk_info(MigrationInfo *info)
> }
> }
>
> -static void populate_vfio_info(MigrationInfo *info)
> -{
> -#ifdef CONFIG_VFIO
> -if (vfio_mig_active()) {
> -info->has_vfio = true;
> -info->vfio = g_malloc0(sizeof(*info->vfio));
> -info->vfio->transferred = vfio_mig_bytes_transferred();
> -}
> -#endif
> -}
> -
> static void fill_source_migration_info(MigrationInfo *info)
> {
> MigrationState *s = migrate_get_current();
> diff --git a/stubs/meson.build b/stubs/meson.build
> index 82b7ba60abe5..909956674847 100644
> --- a/stubs/meson.build
> +++ b/stubs/meson.build
> @@ -53,3 +53,4 @@ if have_system
>stub_ss.add(files('semihost.c'))
>stub_ss.add(files('xen-hw-stub.c'))
> endif
> +stub_ss.add(files('vfio.c'))
> diff --git a/stubs/vfio.c b/stubs/vfio.c
> new file mode 100644
> index ..9cc8753cd102
> --- /dev/null
> +++ b/stubs/vfio.c
> @@ -0,0 +1,7 @@
> +#include "qemu/osdep.h"
> +#include "qapi/qapi-types-migration.h"
> +#include "hw/vfio/vfio.h"
> +
> +void populate_vfio_info(MigrationInfo *info)
> +{
> +}
[989/8466] Compiling C object libqemu-s390x-softmmu.fa.p/hw_vfio_ap.c.o
FAILED: libqemu-s390x-softmmu.fa.p/hw_vfio_ap.c.o
cc -Ilibqemu-s390x-softmmu.fa.p -I. -I.. -Itarget/s390x -I../target/s390x
-Iqapi -Itrace -Iui -Iui/shader -I/usr/include/spice-1
-I/usr/include/spice-server -I/usr/include/cacard -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include -I/usr/include/nss3 -I/usr/include/nspr4
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/pixman-1
-I/usr/include/capstone -fdiagnostics-color=auto -pipe -Wall -Winvalid-pch
-std=gnu99 -O2 -g -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -m64 -mcx16
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes
-Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes
-fno-strict-aliasing -fno-common -fwrapv
Re: [PATCH] hw/block: m25p80: Fix fast read for SST flashes
On Sun, Nov 29, 2020 at 6:55 PM Bin Meng wrote:
>
> From: Bin Meng
>
> SST flashes require a dummy byte after the address bits.
>
> Signed-off-by: Bin Meng
I couldn't find a datasheet that says this... But the actual code
change looks fine, so:
Acked-by: Alistair Francis
Alistair
> ---
>
> hw/block/m25p80.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c
> index 483925f..9b36762 100644
> --- a/hw/block/m25p80.c
> +++ b/hw/block/m25p80.c
> @@ -825,6 +825,9 @@ static void decode_fast_read_cmd(Flash *s)
> s->needed_bytes = get_addr_length(s);
> switch (get_man(s)) {
> /* Dummy cycles - modeled with bytes writes instead of bits */
> +case MAN_SST:
> +s->needed_bytes += 1;
> +break;
> case MAN_WINBOND:
> s->needed_bytes += 8;
> break;
> --
> 2.7.4
>
>
[PATCH 6/9] target/mips: Alias MSA vector registers on FPU scalar registers
Commits 863f264d10f ("add msa_reset(), global msa register") and
cb269f273fd ("fix multiple TCG registers covering same data")
removed the FPU scalar registers and replaced them by aliases to
the MSA vector registers.
While this might be the case for CPU implementing MSA, this makes
QEMU code incoherent for CPU not implementing it. It is simpler
to inverse the logic and alias the MSA vector registers on the
FPU scalar ones.
Signed-off-by: Philippe Mathieu-Daudé
---
target/mips/translate.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/target/mips/translate.c b/target/mips/translate.c
index a05c25e50b8..41880f21abd 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -31682,16 +31682,20 @@ void mips_tcg_init(void)
offsetof(CPUMIPSState,
active_tc.gpr[i]),
regnames[i]);
-
for (i = 0; i < 32; i++) {
int off = offsetof(CPUMIPSState, active_fpu.fpr[i].wr.d[0]);
-msa_wr_d[i * 2] =
-tcg_global_mem_new_i64(cpu_env, off, msaregnames[i * 2]);
+
+fpu_f64[i] = tcg_global_mem_new_i64(cpu_env, off, msaregnames[i * 2]);
+}
+/* MSA */
+for (i = 0; i < 32; i++) {
+int off = offsetof(CPUMIPSState, active_fpu.fpr[i].wr.d[0]);
+
/*
- * The scalar floating-point unit (FPU) registers are mapped on
- * the MSA vector registers.
+ * The MSA vector registers are mapped on the
+ * scalar floating-point unit (FPU) registers.
*/
-fpu_f64[i] = msa_wr_d[i * 2];
+msa_wr_d[i * 2] = fpu_f64[i];
off = offsetof(CPUMIPSState, active_fpu.fpr[i].wr.d[1]);
msa_wr_d[i * 2 + 1] =
tcg_global_mem_new_i64(cpu_env, off, msaregnames[i * 2 + 1]);
--
2.26.2
Re: [PATCH] docs: set CONFDIR when running sphinx
On Wed, Dec 02, 2020 at 10:05:50AM +0100, Paolo Bonzini wrote:
> On 01/12/20 19:37, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau
> >
> > The default configuration path /etc/qemu can be overriden with configure
> > options, and the generated documentation used to reflect it.
> >
> > Fixes regression introduced in commit
> > f8aa24ea9a82da38370470c6bc0eaa393999edfe ("meson: sphinx-build").
> >
> > Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1902537
> > Signed-off-by: Marc-André Lureau
> > ---
> > docs/meson.build | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/docs/meson.build b/docs/meson.build
> > index ebd85d59f9..bb8fe4c9e4 100644
> > --- a/docs/meson.build
> > +++ b/docs/meson.build
> > @@ -9,7 +9,7 @@ endif
> > # Check if tools are available to build documentation.
> > build_docs = false
> > if sphinx_build.found()
> > - SPHINX_ARGS = [sphinx_build]
> > + SPHINX_ARGS = ['env', 'CONFDIR=' + qemu_confdir, sphinx_build]
> > # If we're making warnings fatal, apply this to Sphinx runs as well
> > if get_option('werror')
> > SPHINX_ARGS += [ '-W' ]
> >
>
> I can queue the patch, but I also wouldn't mind removing support for
> /etc/qemu completely. I'm not sure why one would use it. Eduardo?
I agree, and I had a series for this 3 years ago.
I guess I need to my keep my word and finally submit v5 of the series:
https://lore.kernel.org/qemu-devel/20171005123414.GE4015@localhost.localdomain/
--
Eduardo
Re: [PATCH v3 3/3] arm/hvf: Add a WFI handler
On Wed, Dec 2, 2020 at 10:49 AM Alexander Graf wrote: > > > On 02.12.20 05:44, Peter Collingbourne wrote: > > Sleep on WFI until the VTIMER is due but allow ourselves to be woken > > up on IPI. > > > > Signed-off-by: Peter Collingbourne > > --- > > v3: > > - move the simplified locking to a separate patch > > - spin on sleep <2ms > > > > v2: > > - simplify locking further > > - wait indefinitely on disabled or masked timers > > > > accel/hvf/hvf-cpus.c | 4 +-- > > include/sysemu/hvf_int.h | 1 + > > target/arm/hvf/hvf.c | 56 > > 3 files changed, 59 insertions(+), 2 deletions(-) > > > > diff --git a/accel/hvf/hvf-cpus.c b/accel/hvf/hvf-cpus.c > > index e613c22ad0..b2c8fb57f6 100644 > > --- a/accel/hvf/hvf-cpus.c > > +++ b/accel/hvf/hvf-cpus.c > > @@ -344,8 +344,8 @@ static int hvf_init_vcpu(CPUState *cpu) > > sigact.sa_handler = dummy_signal; > > sigaction(SIG_IPI, , NULL); > > > > -pthread_sigmask(SIG_BLOCK, NULL, ); > > -sigdelset(, SIG_IPI); > > +pthread_sigmask(SIG_BLOCK, NULL, >hvf->unblock_ipi_mask); > > +sigdelset(>hvf->unblock_ipi_mask, SIG_IPI); > > > That turns set into an unused variable, no? I'll fix it up while > applying though. The rest looks great, I'll push it as part of my next > patch set. Yes, thanks for spotting that, your fixup looks good. Peter
Re: [PATCH v3 3/3] arm/hvf: Add a WFI handler
On 02.12.20 05:44, Peter Collingbourne wrote: Sleep on WFI until the VTIMER is due but allow ourselves to be woken up on IPI. Signed-off-by: Peter Collingbourne --- v3: - move the simplified locking to a separate patch - spin on sleep <2ms v2: - simplify locking further - wait indefinitely on disabled or masked timers accel/hvf/hvf-cpus.c | 4 +-- include/sysemu/hvf_int.h | 1 + target/arm/hvf/hvf.c | 56 3 files changed, 59 insertions(+), 2 deletions(-) diff --git a/accel/hvf/hvf-cpus.c b/accel/hvf/hvf-cpus.c index e613c22ad0..b2c8fb57f6 100644 --- a/accel/hvf/hvf-cpus.c +++ b/accel/hvf/hvf-cpus.c @@ -344,8 +344,8 @@ static int hvf_init_vcpu(CPUState *cpu) sigact.sa_handler = dummy_signal; sigaction(SIG_IPI, , NULL); -pthread_sigmask(SIG_BLOCK, NULL, ); -sigdelset(, SIG_IPI); +pthread_sigmask(SIG_BLOCK, NULL, >hvf->unblock_ipi_mask); +sigdelset(>hvf->unblock_ipi_mask, SIG_IPI); That turns set into an unused variable, no? I'll fix it up while applying though. The rest looks great, I'll push it as part of my next patch set. Alex
[PATCH v3 07/10] arm: Add Hypervisor.framework build target
Now that we have all logic in place that we need to handle Hypervisor.framework
on Apple Silicon systems, let's add CONFIG_HVF for aarch64 as well so that we
can build it.
Signed-off-by: Alexander Graf
---
v1 -> v2:
- Fix build on 32bit arm
---
meson.build| 11 ++-
target/arm/hvf/meson.build | 3 +++
target/arm/meson.build | 2 ++
3 files changed, 15 insertions(+), 1 deletion(-)
create mode 100644 target/arm/hvf/meson.build
diff --git a/meson.build b/meson.build
index 2a7ff5560c..bff3fe7089 100644
--- a/meson.build
+++ b/meson.build
@@ -74,16 +74,25 @@ else
endif
accelerator_targets = { 'CONFIG_KVM': kvm_targets }
+
+if cpu in ['x86', 'x86_64']
+ hvf_targets = ['i386-softmmu', 'x86_64-softmmu']
+elif cpu in ['aarch64']
+ hvf_targets = ['aarch64-softmmu']
+else
+ hvf_targets = []
+endif
+
if cpu in ['x86', 'x86_64', 'arm', 'aarch64']
# i368 emulator provides xenpv machine type for multiple architectures
accelerator_targets += {
'CONFIG_XEN': ['i386-softmmu', 'x86_64-softmmu'],
+'CONFIG_HVF': hvf_targets,
}
endif
if cpu in ['x86', 'x86_64']
accelerator_targets += {
'CONFIG_HAX': ['i386-softmmu', 'x86_64-softmmu'],
-'CONFIG_HVF': ['x86_64-softmmu'],
'CONFIG_WHPX': ['i386-softmmu', 'x86_64-softmmu'],
}
endif
diff --git a/target/arm/hvf/meson.build b/target/arm/hvf/meson.build
new file mode 100644
index 00..855e6cce5a
--- /dev/null
+++ b/target/arm/hvf/meson.build
@@ -0,0 +1,3 @@
+arm_softmmu_ss.add(when: [hvf, 'CONFIG_HVF'], if_true: files(
+ 'hvf.c',
+))
diff --git a/target/arm/meson.build b/target/arm/meson.build
index f5de2a77b8..95bebae216 100644
--- a/target/arm/meson.build
+++ b/target/arm/meson.build
@@ -56,5 +56,7 @@ arm_softmmu_ss.add(files(
'psci.c',
))
+subdir('hvf')
+
target_arch += {'arm': arm_ss}
target_softmmu_arch += {'arm': arm_softmmu_ss}
--
2.24.3 (Apple Git-128)
Re: [PATCH v3 00/10] hvf: Implement Apple Silicon Support
Patchew URL: https://patchew.org/QEMU/20201202190408.2041-1-ag...@csgraf.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20201202190408.2041-1-ag...@csgraf.de
Subject: [PATCH v3 00/10] hvf: Implement Apple Silicon Support
=== 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
* [new tag] patchew/20201202190408.2041-1-ag...@csgraf.de ->
patchew/20201202190408.2041-1-ag...@csgraf.de
Switched to a new branch 'test'
4d827f3 hvf: arm: Implement -cpu host
bde0110 hvf: arm: Add support for GICv3
5c824d7 arm/hvf: Add a WFI handler
68f28c6 arm: Add Hypervisor.framework build target
ae48800 hvf: Add Apple Silicon support
ced03a5 hvf: arm: Mark CPU as dirty on reset
9830bf6 arm: Set PSCI to 0.2 for HVF
b2218df hvf: Introduce hvf vcpu struct
0d5f075 hvf: Move common code out
6ae373a hvf: Add hypervisor entitlement to output binaries
=== OUTPUT BEGIN ===
1/10 Checking commit 6ae373af35d9 (hvf: Add hypervisor entitlement to output
binaries)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#16:
new file mode 100644
total: 0 errors, 1 warnings, 63 lines checked
Patch 1/10 has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
2/10 Checking commit 0d5f07559d56 (hvf: Move common code out)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#38:
new file mode 100644
total: 0 errors, 1 warnings, 1088 lines checked
Patch 2/10 has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
3/10 Checking commit b2218df9dabc (hvf: Introduce hvf vcpu struct)
WARNING: line over 80 characters
#138: FILE: target/i386/hvf/hvf.c:213:
+wvmcs(cpu->hvf->fd, VMCS_ENTRY_CTLS,
cap2ctrl(hvf_state->hvf_caps->vmx_cap_entry,
ERROR: "(foo*)" should be "(foo *)"
#746: FILE: target/i386/hvf/x86hvf.c:85:
+if (hv_vcpu_write_fpstate(cpu_state->hvf->fd, (void*)xsave, 4096)) {
ERROR: "(foo*)" should be "(foo *)"
#827: FILE: target/i386/hvf/x86hvf.c:167:
+if (hv_vcpu_read_fpstate(cpu_state->hvf->fd, (void*)xsave, 4096)) {
total: 2 errors, 1 warnings, 996 lines checked
Patch 3/10 has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
4/10 Checking commit 9830bf633313 (arm: Set PSCI to 0.2 for HVF)
5/10 Checking commit ced03a5fa1eb (hvf: arm: Mark CPU as dirty on reset)
6/10 Checking commit ae4880007b12 (hvf: Add Apple Silicon support)
WARNING: architecture specific defines should be avoided
#47: FILE: accel/hvf/hvf-cpus.c:63:
+#ifdef __aarch64__
WARNING: architecture specific defines should be avoided
#58: FILE: accel/hvf/hvf-cpus.c:350:
+#ifdef __aarch64__
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#111:
new file mode 100644
WARNING: line over 80 characters
#575: FILE: target/arm/hvf/hvf.c:460:
+hv_vcpu_set_pending_interrupt(cpu->hvf->fd, HV_INTERRUPT_TYPE_FIQ,
true);
WARNING: line over 80 characters
#580: FILE: target/arm/hvf/hvf.c:465:
+hv_vcpu_set_pending_interrupt(cpu->hvf->fd, HV_INTERRUPT_TYPE_IRQ,
true);
total: 0 errors, 5 warnings, 688 lines checked
Patch 6/10 has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
7/10 Checking commit 68f28c62f682 (arm: Add Hypervisor.framework build target)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#47:
new file mode 100644
total: 0 errors, 1 warnings, 36 lines checked
Patch 7/10 has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
8/10 Checking commit 5c824d7a4a5e (arm/hvf: Add a WFI handler)
9/10 Checking commit bde0110d9163 (hvf: arm: Add support for GICv3)
10/10 Checking commit 4d827f39b205 (hvf: arm: Implement -cpu host)
=== OUTPUT END ===
Test command exited with code: 1
The full log is available at
http://patchew.org/logs/20201202190408.2041-1-ag...@csgraf.de/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com
[PATCH v13 09/10] stream: skip filters when writing backing file name to QCOW2 header
Avoid writing a filter JSON file name and a filter format name to QCOW2
image when the backing file is being changed after the block stream
job. It can occur due to a concurrent commit job on the same backing
chain.
A user is still able to assign the 'backing-file' parameter for a
block-stream job keeping in mind the possible issue mentioned above.
If the user does not specify the 'backing-file' parameter, QEMU will
assign it automatically.
Signed-off-by: Andrey Shinkevich
---
block/stream.c | 21 +++--
blockdev.c | 8 +---
2 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/block/stream.c b/block/stream.c
index 6e281c7..061268b 100644
--- a/block/stream.c
+++ b/block/stream.c
@@ -17,6 +17,7 @@
#include "block/blockjob_int.h"
#include "qapi/error.h"
#include "qapi/qmp/qerror.h"
+#include "qemu/error-report.h"
#include "qemu/ratelimit.h"
#include "sysemu/block-backend.h"
@@ -65,6 +66,8 @@ static int stream_prepare(Job *job)
BlockDriverState *bs = blk_bs(bjob->blk);
BlockDriverState *unfiltered_bs = bdrv_skip_filters(bs);
BlockDriverState *base = bdrv_filter_or_cow_bs(s->above_base);
+BlockDriverState *base_unfiltered;
+BlockDriverState *backing_bs;
Error *local_err = NULL;
int ret = 0;
@@ -75,8 +78,22 @@ static int stream_prepare(Job *job)
const char *base_id = NULL, *base_fmt = NULL;
if (base) {
base_id = s->backing_file_str;
-if (base->drv) {
-base_fmt = base->drv->format_name;
+if (base_id) {
+backing_bs = bdrv_find_backing_image(bs, base_id);
+if (backing_bs && backing_bs->drv) {
+base_fmt = backing_bs->drv->format_name;
+} else {
+error_report("Format not found for backing file %s",
+ s->backing_file_str);
+}
+} else {
+base_unfiltered = bdrv_skip_filters(base);
+if (base_unfiltered) {
+base_id = base_unfiltered->filename;
+if (base_unfiltered->drv) {
+base_fmt = base_unfiltered->drv->format_name;
+}
+}
}
}
bdrv_set_backing_hd(unfiltered_bs, base, _err);
diff --git a/blockdev.c b/blockdev.c
index c917625..70900f4 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -2508,7 +2508,6 @@ void qmp_block_stream(bool has_job_id, const char
*job_id, const char *device,
BlockDriverState *base_bs = NULL;
AioContext *aio_context;
Error *local_err = NULL;
-const char *base_name = NULL;
int job_flags = JOB_DEFAULT;
if (!has_on_error) {
@@ -2536,7 +2535,6 @@ void qmp_block_stream(bool has_job_id, const char
*job_id, const char *device,
goto out;
}
assert(bdrv_get_aio_context(base_bs) == aio_context);
-base_name = base;
}
if (has_base_node) {
@@ -2551,7 +2549,6 @@ void qmp_block_stream(bool has_job_id, const char
*job_id, const char *device,
}
assert(bdrv_get_aio_context(base_bs) == aio_context);
bdrv_refresh_filename(base_bs);
-base_name = base_bs->filename;
}
/* Check for op blockers in the whole chain between bs and base */
@@ -2571,9 +2568,6 @@ void qmp_block_stream(bool has_job_id, const char
*job_id, const char *device,
goto out;
}
-/* backing_file string overrides base bs filename */
-base_name = has_backing_file ? backing_file : base_name;
-
if (has_auto_finalize && !auto_finalize) {
job_flags |= JOB_MANUAL_FINALIZE;
}
@@ -2581,7 +2575,7 @@ void qmp_block_stream(bool has_job_id, const char
*job_id, const char *device,
job_flags |= JOB_MANUAL_DISMISS;
}
-stream_start(has_job_id ? job_id : NULL, bs, base_bs, base_name,
+stream_start(has_job_id ? job_id : NULL, bs, base_bs, backing_file,
job_flags, has_speed ? speed : 0, on_error,
filter_node_name, _err);
if (local_err) {
--
1.8.3.1
[PATCH 8/9] target/mips: Remove CPUMIPSState* argument from gen_msa*() methods
The gen_msa*() methods don't use the "CPUMIPSState *env"
argument. Remove it to simplify.
Signed-off-by: Philippe Mathieu-Daudé
---
target/mips/translate.c | 57 -
1 file changed, 28 insertions(+), 29 deletions(-)
diff --git a/target/mips/translate.c b/target/mips/translate.c
index a5112acc351..5311e6ced62 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -28744,7 +28744,7 @@ static void gen_check_zero_element(TCGv tresult,
uint8_t df, uint8_t wt)
tcg_temp_free_i64(t1);
}
-static void gen_msa_branch(CPUMIPSState *env, DisasContext *ctx, uint32_t op1)
+static void gen_msa_branch(DisasContext *ctx, uint32_t op1)
{
uint8_t df = (ctx->opcode >> 21) & 0x3;
uint8_t wt = (ctx->opcode >> 16) & 0x1f;
@@ -28789,7 +28789,7 @@ static void gen_msa_branch(CPUMIPSState *env,
DisasContext *ctx, uint32_t op1)
ctx->hflags |= MIPS_HFLAG_BDS32;
}
-static void gen_msa_i8(CPUMIPSState *env, DisasContext *ctx)
+static void gen_msa_i8(DisasContext *ctx)
{
#define MASK_MSA_I8(op)(MASK_MSA_MINOR(op) | (op & (0x03 << 24)))
uint8_t i8 = (ctx->opcode >> 16) & 0xff;
@@ -28847,7 +28847,7 @@ static void gen_msa_i8(CPUMIPSState *env, DisasContext
*ctx)
tcg_temp_free_i32(ti8);
}
-static void gen_msa_i5(CPUMIPSState *env, DisasContext *ctx)
+static void gen_msa_i5(DisasContext *ctx)
{
#define MASK_MSA_I5(op)(MASK_MSA_MINOR(op) | (op & (0x7 << 23)))
uint8_t df = (ctx->opcode >> 21) & 0x3;
@@ -28920,7 +28920,7 @@ static void gen_msa_i5(CPUMIPSState *env, DisasContext
*ctx)
tcg_temp_free_i32(timm);
}
-static void gen_msa_bit(CPUMIPSState *env, DisasContext *ctx)
+static void gen_msa_bit(DisasContext *ctx)
{
#define MASK_MSA_BIT(op)(MASK_MSA_MINOR(op) | (op & (0x7 << 23)))
uint8_t dfm = (ctx->opcode >> 16) & 0x7f;
@@ -29004,7 +29004,7 @@ static void gen_msa_bit(CPUMIPSState *env, DisasContext
*ctx)
tcg_temp_free_i32(tws);
}
-static void gen_msa_3r(CPUMIPSState *env, DisasContext *ctx)
+static void gen_msa_3r(DisasContext *ctx)
{
#define MASK_MSA_3R(op)(MASK_MSA_MINOR(op) | (op & (0x7 << 23)))
uint8_t df = (ctx->opcode >> 21) & 0x3;
@@ -29986,7 +29986,7 @@ static void gen_msa_3r(CPUMIPSState *env, DisasContext
*ctx)
tcg_temp_free_i32(tdf);
}
-static void gen_msa_elm_3e(CPUMIPSState *env, DisasContext *ctx)
+static void gen_msa_elm_3e(DisasContext *ctx)
{
#define MASK_MSA_ELM_DF3E(op) (MASK_MSA_MINOR(op) | (op & (0x3FF << 16)))
uint8_t source = (ctx->opcode >> 11) & 0x1f;
@@ -30018,8 +30018,7 @@ static void gen_msa_elm_3e(CPUMIPSState *env,
DisasContext *ctx)
tcg_temp_free_i32(tsr);
}
-static void gen_msa_elm_df(CPUMIPSState *env, DisasContext *ctx, uint32_t df,
-uint32_t n)
+static void gen_msa_elm_df(DisasContext *ctx, uint32_t df, uint32_t n)
{
#define MASK_MSA_ELM(op)(MASK_MSA_MINOR(op) | (op & (0xf << 22)))
uint8_t ws = (ctx->opcode >> 11) & 0x1f;
@@ -30129,7 +30128,7 @@ static void gen_msa_elm_df(CPUMIPSState *env,
DisasContext *ctx, uint32_t df,
tcg_temp_free_i32(tdf);
}
-static void gen_msa_elm(CPUMIPSState *env, DisasContext *ctx)
+static void gen_msa_elm(DisasContext *ctx)
{
uint8_t dfn = (ctx->opcode >> 16) & 0x3f;
uint32_t df = 0, n = 0;
@@ -30148,17 +30147,17 @@ static void gen_msa_elm(CPUMIPSState *env,
DisasContext *ctx)
df = DF_DOUBLE;
} else if (dfn == 0x3E) {
/* CTCMSA, CFCMSA, MOVE.V */
-gen_msa_elm_3e(env, ctx);
+gen_msa_elm_3e(ctx);
return;
} else {
generate_exception_end(ctx, EXCP_RI);
return;
}
-gen_msa_elm_df(env, ctx, df, n);
+gen_msa_elm_df(ctx, df, n);
}
-static void gen_msa_3rf(CPUMIPSState *env, DisasContext *ctx)
+static void gen_msa_3rf(DisasContext *ctx)
{
#define MASK_MSA_3RF(op)(MASK_MSA_MINOR(op) | (op & (0xf << 22)))
uint8_t df = (ctx->opcode >> 21) & 0x1;
@@ -30316,7 +30315,7 @@ static void gen_msa_3rf(CPUMIPSState *env, DisasContext
*ctx)
tcg_temp_free_i32(tdf);
}
-static void gen_msa_2r(CPUMIPSState *env, DisasContext *ctx)
+static void gen_msa_2r(DisasContext *ctx)
{
#define MASK_MSA_2R(op) (MASK_MSA_MINOR(op) | (op & (0x1f << 21)) | \
(op & (0x7 << 18)))
@@ -30400,7 +30399,7 @@ static void gen_msa_2r(CPUMIPSState *env, DisasContext
*ctx)
tcg_temp_free_i32(tdf);
}
-static void gen_msa_2rf(CPUMIPSState *env, DisasContext *ctx)
+static void gen_msa_2rf(DisasContext *ctx)
{
#define MASK_MSA_2RF(op)(MASK_MSA_MINOR(op) | (op & (0x1f << 21)) | \
(op & (0xf << 17)))
@@ -30471,7 +30470,7 @@ static void gen_msa_2rf(CPUMIPSState *env, DisasContext
*ctx)
tcg_temp_free_i32(tdf);
}
-static void gen_msa_vec_v(CPUMIPSState *env, DisasContext *ctx)
+static void gen_msa_vec_v(DisasContext *ctx)
{
#define MASK_MSA_VEC(op)(MASK_MSA_MINOR(op) | (op & (0x1f << 21)))
uint8_t wt = (ctx->opcode >>
[PATCH 7/9] target/mips: Extract msa_translate_init() from mips_tcg_init()
Extract the logic initialization of the MSA registers from
the generic initialization.
Signed-off-by: Philippe Mathieu-Daudé
---
target/mips/translate.c | 35 ---
1 file changed, 20 insertions(+), 15 deletions(-)
diff --git a/target/mips/translate.c b/target/mips/translate.c
index 41880f21abd..a5112acc351 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -31672,6 +31672,24 @@ void mips_cpu_dump_state(CPUState *cs, FILE *f, int
flags)
}
}
+static void msa_translate_init(void)
+{
+int i;
+
+for (i = 0; i < 32; i++) {
+int off = offsetof(CPUMIPSState, active_fpu.fpr[i].wr.d[0]);
+
+/*
+ * The MSA vector registers are mapped on the
+ * scalar floating-point unit (FPU) registers.
+ */
+msa_wr_d[i * 2] = fpu_f64[i];
+off = offsetof(CPUMIPSState, active_fpu.fpr[i].wr.d[1]);
+msa_wr_d[i * 2 + 1] =
+tcg_global_mem_new_i64(cpu_env, off, msaregnames[i * 2 + 1]);
+}
+}
+
void mips_tcg_init(void)
{
int i;
@@ -31685,22 +31703,9 @@ void mips_tcg_init(void)
for (i = 0; i < 32; i++) {
int off = offsetof(CPUMIPSState, active_fpu.fpr[i].wr.d[0]);
-fpu_f64[i] = tcg_global_mem_new_i64(cpu_env, off, msaregnames[i * 2]);
+fpu_f64[i] = tcg_global_mem_new_i64(cpu_env, off, fregnames[i]);
}
-/* MSA */
-for (i = 0; i < 32; i++) {
-int off = offsetof(CPUMIPSState, active_fpu.fpr[i].wr.d[0]);
-
-/*
- * The MSA vector registers are mapped on the
- * scalar floating-point unit (FPU) registers.
- */
-msa_wr_d[i * 2] = fpu_f64[i];
-off = offsetof(CPUMIPSState, active_fpu.fpr[i].wr.d[1]);
-msa_wr_d[i * 2 + 1] =
-tcg_global_mem_new_i64(cpu_env, off, msaregnames[i * 2 + 1]);
-}
-
+msa_translate_init();
cpu_PC = tcg_global_mem_new(cpu_env,
offsetof(CPUMIPSState, active_tc.PC), "PC");
for (i = 0; i < MIPS_DSP_ACC; i++) {
--
2.26.2
[PATCH v3 03/10] hvf: Introduce hvf vcpu struct
We will need more than a single field for hvf going forward. To keep
the global vcpu struct uncluttered, let's allocate a special hvf vcpu
struct, similar to how hax does it.
Signed-off-by: Alexander Graf
---
accel/hvf/hvf-cpus.c| 8 +-
include/hw/core/cpu.h | 3 +-
include/sysemu/hvf_int.h| 4 +
target/i386/hvf/hvf.c | 102 +-
target/i386/hvf/vmx.h | 24 +++--
target/i386/hvf/x86.c | 28 ++---
target/i386/hvf/x86_descr.c | 26 ++---
target/i386/hvf/x86_emu.c | 62 +--
target/i386/hvf/x86_mmu.c | 4 +-
target/i386/hvf/x86_task.c | 12 +--
target/i386/hvf/x86hvf.c| 210 ++--
11 files changed, 247 insertions(+), 236 deletions(-)
diff --git a/accel/hvf/hvf-cpus.c b/accel/hvf/hvf-cpus.c
index 4d1cca9d6e..a423f629d5 100644
--- a/accel/hvf/hvf-cpus.c
+++ b/accel/hvf/hvf-cpus.c
@@ -314,10 +314,12 @@ static void hvf_cpu_synchronize_pre_loadvm(CPUState *cpu)
static void hvf_vcpu_destroy(CPUState *cpu)
{
-hv_return_t ret = hv_vcpu_destroy(cpu->hvf_fd);
+hv_return_t ret = hv_vcpu_destroy(cpu->hvf->fd);
assert_hvf_ok(ret);
hvf_arch_vcpu_destroy(cpu);
+free(cpu->hvf);
+cpu->hvf = NULL;
}
static void dummy_signal(int sig)
@@ -328,6 +330,8 @@ static int hvf_init_vcpu(CPUState *cpu)
{
int r;
+cpu->hvf = g_malloc0(sizeof(*cpu->hvf));
+
/* init cpu signals */
sigset_t set;
struct sigaction sigact;
@@ -339,7 +343,7 @@ static int hvf_init_vcpu(CPUState *cpu)
pthread_sigmask(SIG_BLOCK, NULL, );
sigdelset(, SIG_IPI);
-r = hv_vcpu_create((hv_vcpuid_t *)>hvf_fd, HV_VCPU_DEFAULT);
+r = hv_vcpu_create((hv_vcpuid_t *)>hvf->fd, HV_VCPU_DEFAULT);
cpu->vcpu_dirty = 1;
assert_hvf_ok(r);
diff --git a/include/hw/core/cpu.h b/include/hw/core/cpu.h
index 3d92c967ff..6032d8a52c 100644
--- a/include/hw/core/cpu.h
+++ b/include/hw/core/cpu.h
@@ -280,6 +280,7 @@ struct KVMState;
struct kvm_run;
struct hax_vcpu_state;
+struct hvf_vcpu_state;
#define TB_JMP_CACHE_BITS 12
#define TB_JMP_CACHE_SIZE (1 << TB_JMP_CACHE_BITS)
@@ -463,7 +464,7 @@ struct CPUState {
struct hax_vcpu_state *hax_vcpu;
-int hvf_fd;
+struct hvf_vcpu_state *hvf;
/* track IOMMUs whose translations we've cached in the TCG TLB */
GArray *iommu_notifiers;
diff --git a/include/sysemu/hvf_int.h b/include/sysemu/hvf_int.h
index de9bad23a8..7967e33727 100644
--- a/include/sysemu/hvf_int.h
+++ b/include/sysemu/hvf_int.h
@@ -58,6 +58,10 @@ struct HVFState {
};
extern HVFState *hvf_state;
+struct hvf_vcpu_state {
+int fd;
+};
+
void assert_hvf_ok(hv_return_t ret);
int hvf_get_registers(CPUState *cpu);
int hvf_put_registers(CPUState *cpu);
diff --git a/target/i386/hvf/hvf.c b/target/i386/hvf/hvf.c
index 8b96ecd619..08b4adecd9 100644
--- a/target/i386/hvf/hvf.c
+++ b/target/i386/hvf/hvf.c
@@ -80,11 +80,11 @@ void vmx_update_tpr(CPUState *cpu)
int tpr = cpu_get_apic_tpr(x86_cpu->apic_state) << 4;
int irr = apic_get_highest_priority_irr(x86_cpu->apic_state);
-wreg(cpu->hvf_fd, HV_X86_TPR, tpr);
+wreg(cpu->hvf->fd, HV_X86_TPR, tpr);
if (irr == -1) {
-wvmcs(cpu->hvf_fd, VMCS_TPR_THRESHOLD, 0);
+wvmcs(cpu->hvf->fd, VMCS_TPR_THRESHOLD, 0);
} else {
-wvmcs(cpu->hvf_fd, VMCS_TPR_THRESHOLD, (irr > tpr) ? tpr >> 4 :
+wvmcs(cpu->hvf->fd, VMCS_TPR_THRESHOLD, (irr > tpr) ? tpr >> 4 :
irr >> 4);
}
}
@@ -92,7 +92,7 @@ void vmx_update_tpr(CPUState *cpu)
static void update_apic_tpr(CPUState *cpu)
{
X86CPU *x86_cpu = X86_CPU(cpu);
-int tpr = rreg(cpu->hvf_fd, HV_X86_TPR) >> 4;
+int tpr = rreg(cpu->hvf->fd, HV_X86_TPR) >> 4;
cpu_set_apic_tpr(x86_cpu->apic_state, tpr);
}
@@ -194,43 +194,43 @@ int hvf_arch_init_vcpu(CPUState *cpu)
}
/* set VMCS control fields */
-wvmcs(cpu->hvf_fd, VMCS_PIN_BASED_CTLS,
+wvmcs(cpu->hvf->fd, VMCS_PIN_BASED_CTLS,
cap2ctrl(hvf_state->hvf_caps->vmx_cap_pinbased,
VMCS_PIN_BASED_CTLS_EXTINT |
VMCS_PIN_BASED_CTLS_NMI |
VMCS_PIN_BASED_CTLS_VNMI));
-wvmcs(cpu->hvf_fd, VMCS_PRI_PROC_BASED_CTLS,
+wvmcs(cpu->hvf->fd, VMCS_PRI_PROC_BASED_CTLS,
cap2ctrl(hvf_state->hvf_caps->vmx_cap_procbased,
VMCS_PRI_PROC_BASED_CTLS_HLT |
VMCS_PRI_PROC_BASED_CTLS_MWAIT |
VMCS_PRI_PROC_BASED_CTLS_TSC_OFFSET |
VMCS_PRI_PROC_BASED_CTLS_TPR_SHADOW) |
VMCS_PRI_PROC_BASED_CTLS_SEC_CONTROL);
-wvmcs(cpu->hvf_fd, VMCS_SEC_PROC_BASED_CTLS,
+wvmcs(cpu->hvf->fd, VMCS_SEC_PROC_BASED_CTLS,
cap2ctrl(hvf_state->hvf_caps->vmx_cap_procbased2,
VMCS_PRI_PROC_BASED2_CTLS_APIC_ACCESSES));
-wvmcs(cpu->hvf_fd, VMCS_ENTRY_CTLS,
cap2ctrl(hvf_state->hvf_caps->vmx_cap_entry,
+wvmcs(cpu->hvf->fd, VMCS_ENTRY_CTLS,
cap2ctrl(hvf_state->hvf_caps->vmx_cap_entry,
0));
-
[PATCH v3 02/10] hvf: Move common code out
Until now, Hypervisor.framework has only been available on x86_64 systems.
With Apple Silicon shipping now, it extends its reach to aarch64. To
prepare for support for multiple architectures, let's move common code out
into its own accel directory.
Signed-off-by: Alexander Graf
---
MAINTAINERS | 9 +-
accel/hvf/hvf-all.c | 56 +
accel/hvf/hvf-cpus.c| 464
accel/hvf/meson.build | 7 +
accel/meson.build | 1 +
include/sysemu/hvf_int.h| 69 ++
target/i386/hvf/hvf-cpus.c | 131 --
target/i386/hvf/hvf-cpus.h | 25 --
target/i386/hvf/hvf-i386.h | 48 +---
target/i386/hvf/hvf.c | 360 +---
target/i386/hvf/meson.build | 1 -
target/i386/hvf/x86hvf.c| 11 +-
target/i386/hvf/x86hvf.h| 2 -
13 files changed, 615 insertions(+), 569 deletions(-)
create mode 100644 accel/hvf/hvf-all.c
create mode 100644 accel/hvf/hvf-cpus.c
create mode 100644 accel/hvf/meson.build
create mode 100644 include/sysemu/hvf_int.h
delete mode 100644 target/i386/hvf/hvf-cpus.c
delete mode 100644 target/i386/hvf/hvf-cpus.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 68bc160f41..ca4b6d9279 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -444,9 +444,16 @@ M: Cameron Esfahani
M: Roman Bolshakov
W: https://wiki.qemu.org/Features/HVF
S: Maintained
-F: accel/stubs/hvf-stub.c
F: target/i386/hvf/
+
+HVF
+M: Cameron Esfahani
+M: Roman Bolshakov
+W: https://wiki.qemu.org/Features/HVF
+S: Maintained
+F: accel/hvf/
F: include/sysemu/hvf.h
+F: include/sysemu/hvf_int.h
WHPX CPUs
M: Sunil Muthuswamy
diff --git a/accel/hvf/hvf-all.c b/accel/hvf/hvf-all.c
new file mode 100644
index 00..47d77a472a
--- /dev/null
+++ b/accel/hvf/hvf-all.c
@@ -0,0 +1,56 @@
+/*
+ * QEMU Hypervisor.framework support
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ *
+ * Contributions after 2012-01-13 are licensed under the terms of the
+ * GNU GPL, version 2 or (at your option) any later version.
+ */
+
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+#include "qemu/error-report.h"
+#include "sysemu/hvf.h"
+#include "sysemu/hvf_int.h"
+#include "sysemu/runstate.h"
+
+#include "qemu/main-loop.h"
+#include "sysemu/accel.h"
+
+#include
+
+bool hvf_allowed;
+HVFState *hvf_state;
+
+void assert_hvf_ok(hv_return_t ret)
+{
+if (ret == HV_SUCCESS) {
+return;
+}
+
+switch (ret) {
+case HV_ERROR:
+error_report("Error: HV_ERROR");
+break;
+case HV_BUSY:
+error_report("Error: HV_BUSY");
+break;
+case HV_BAD_ARGUMENT:
+error_report("Error: HV_BAD_ARGUMENT");
+break;
+case HV_NO_RESOURCES:
+error_report("Error: HV_NO_RESOURCES");
+break;
+case HV_NO_DEVICE:
+error_report("Error: HV_NO_DEVICE");
+break;
+case HV_UNSUPPORTED:
+error_report("Error: HV_UNSUPPORTED");
+break;
+default:
+error_report("Unknown Error");
+}
+
+abort();
+}
diff --git a/accel/hvf/hvf-cpus.c b/accel/hvf/hvf-cpus.c
new file mode 100644
index 00..4d1cca9d6e
--- /dev/null
+++ b/accel/hvf/hvf-cpus.c
@@ -0,0 +1,464 @@
+/*
+ * Copyright 2008 IBM Corporation
+ * 2008 Red Hat, Inc.
+ * Copyright 2011 Intel Corporation
+ * Copyright 2016 Veertu, Inc.
+ * Copyright 2017 The Android Open Source Project
+ *
+ * QEMU Hypervisor.framework support
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of version 2 of the GNU General Public
+ * License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that 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
[PATCH v3 06/10] hvf: Add Apple Silicon support
With Apple Silicon available to the masses, it's a good time to add support
for driving its virtualization extensions from QEMU.
This patch adds all necessary architecture specific code to get basic VMs
working. It's still pretty raw, but definitely functional.
Known limitations:
- Vtimer acknowledgement is hacky
- Should implement more sysregs and fault on invalid ones then
- WFI handling is missing, need to marry it with vtimer
Signed-off-by: Alexander Graf
---
v1 -> v2:
- Merge vcpu kick function patch
- Implement WFI handling (allows vCPUs to sleep)
- Synchronize system registers (fixes OVMF crashes and reboot)
- Don't always call cpu_synchronize_state()
- Use more fine grained iothread locking
- Populate aa64mmfr0 from hardware
v2 -> v3:
- Advance PC on SMC
- Use cp list interface for sysreg syncs
- Do not set current_cpu
- Fix sysreg isread mask
- Move sysreg handling to functions
- Remove WFI logic again
- Revert to global iothread locking
---
MAINTAINERS | 5 +
accel/hvf/hvf-cpus.c | 14 +
include/sysemu/hvf_int.h | 5 +-
target/arm/hvf/hvf.c | 620 +++
4 files changed, 643 insertions(+), 1 deletion(-)
create mode 100644 target/arm/hvf/hvf.c
diff --git a/MAINTAINERS b/MAINTAINERS
index ca4b6d9279..9cd1d9d448 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -439,6 +439,11 @@ F: accel/accel.c
F: accel/Makefile.objs
F: accel/stubs/Makefile.objs
+Apple Silicon HVF CPUs
+M: Alexander Graf
+S: Maintained
+F: target/arm/hvf/
+
X86 HVF CPUs
M: Cameron Esfahani
M: Roman Bolshakov
diff --git a/accel/hvf/hvf-cpus.c b/accel/hvf/hvf-cpus.c
index a423f629d5..e613c22ad0 100644
--- a/accel/hvf/hvf-cpus.c
+++ b/accel/hvf/hvf-cpus.c
@@ -60,6 +60,10 @@
#include
+#ifdef __aarch64__
+#define HV_VM_DEFAULT NULL
+#endif
+
/* Memory slots */
struct mac_slot {
@@ -343,7 +347,11 @@ static int hvf_init_vcpu(CPUState *cpu)
pthread_sigmask(SIG_BLOCK, NULL, );
sigdelset(, SIG_IPI);
+#ifdef __aarch64__
+r = hv_vcpu_create(>hvf->fd, (hv_vcpu_exit_t **)>hvf->exit,
NULL);
+#else
r = hv_vcpu_create((hv_vcpuid_t *)>hvf->fd, HV_VCPU_DEFAULT);
+#endif
cpu->vcpu_dirty = 1;
assert_hvf_ok(r);
@@ -414,8 +422,14 @@ static void hvf_start_vcpu_thread(CPUState *cpu)
cpu, QEMU_THREAD_JOINABLE);
}
+__attribute__((weak)) void hvf_kick_vcpu_thread(CPUState *cpu)
+{
+cpus_kick_thread(cpu);
+}
+
static const CpusAccel hvf_cpus = {
.create_vcpu_thread = hvf_start_vcpu_thread,
+.kick_vcpu_thread = hvf_kick_vcpu_thread,
.synchronize_post_reset = hvf_cpu_synchronize_post_reset,
.synchronize_post_init = hvf_cpu_synchronize_post_init,
diff --git a/include/sysemu/hvf_int.h b/include/sysemu/hvf_int.h
index 7967e33727..5f15119184 100644
--- a/include/sysemu/hvf_int.h
+++ b/include/sysemu/hvf_int.h
@@ -11,6 +11,7 @@
#ifndef HVF_INT_H
#define HVF_INT_H
+#include "qemu/osdep.h"
#include
#define HVF_MAX_VCPU 0x10
@@ -59,7 +60,8 @@ struct HVFState {
extern HVFState *hvf_state;
struct hvf_vcpu_state {
-int fd;
+uint64_t fd;
+void *exit;
};
void assert_hvf_ok(hv_return_t ret);
@@ -69,5 +71,6 @@ int hvf_arch_init_vcpu(CPUState *cpu);
void hvf_arch_vcpu_destroy(CPUState *cpu);
int hvf_vcpu_exec(CPUState *cpu);
hvf_slot *hvf_find_overlap_slot(uint64_t, uint64_t);
+void hvf_kick_vcpu_thread(CPUState *cpu);
#endif
diff --git a/target/arm/hvf/hvf.c b/target/arm/hvf/hvf.c
new file mode 100644
index 00..5ecce36d4a
--- /dev/null
+++ b/target/arm/hvf/hvf.c
@@ -0,0 +1,620 @@
+/*
+ * QEMU Hypervisor.framework support for Apple Silicon
+
+ * Copyright 2020 Alexander Graf
+ *
+ * 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 "qemu/error-report.h"
+
+#include "sysemu/runstate.h"
+#include "sysemu/hvf.h"
+#include "sysemu/hvf_int.h"
+#include "sysemu/hw_accel.h"
+
+#include
+
+#include "exec/address-spaces.h"
+#include "hw/irq.h"
+#include "qemu/main-loop.h"
+#include "sysemu/accel.h"
+#include "sysemu/cpus.h"
+#include "target/arm/cpu.h"
+#include "target/arm/internals.h"
+
+#define HVF_DEBUG 0
+#define DPRINTF(...)\
+if (HVF_DEBUG) {\
+fprintf(stderr, "HVF %s:%d ", __func__, __LINE__); \
+fprintf(stderr, __VA_ARGS__); \
+fprintf(stderr, "\n"); \
+}
+
+#define HVF_SYSREG(crn, crm, op0, op1, op2) \
+ENCODE_AA64_CP_REG(CP_REG_ARM64_SYSREG_CP, crn, crm, op0, op1, op2)
+#define PL1_WRITE_MASK 0x4
+
+#define SYSREG(op0, op1, op2, crn, crm) \
+((op0 << 20) | (op2 << 17) | (op1 << 14) | (crn << 10) | (crm << 1))
+#define SYSREG_MASK SYSREG(0x3, 0x7, 0x7, 0xf, 0xf)
+#define SYSREG_CNTPCT_EL0
[PATCH-for-5.2? 1/1] Acceptance tests: bump Fedora to 32
Currently in use Fedora 31 has been moved out of the standard download
locations that are supported by the functionality provided by
avocado.utils.vmimage. So right now, the boot_linux.py tests will get
canceled by not being able to find those specific images.
Ideally, this would be bumped to version 33. But, I've found issues
with the aarch64 images, with various systemd services failing to
start. So to keep all archs consistent, I've settled on 32.
Signed-off-by: Cleber Rosa
---
tests/acceptance/boot_linux.py | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tests/acceptance/boot_linux.py b/tests/acceptance/boot_linux.py
index 1da4a53d6a..0824de008e 100644
--- a/tests/acceptance/boot_linux.py
+++ b/tests/acceptance/boot_linux.py
@@ -42,13 +42,13 @@ class BootLinuxBase(Test):
vmimage.QEMU_IMG = qemu_img
self.log.info('Downloading/preparing boot image')
-# Fedora 31 only provides ppc64le images
+# Fedora 32 only provides ppc64le images
image_arch = self.arch
if image_arch == 'ppc64':
image_arch = 'ppc64le'
try:
boot = vmimage.get(
-'fedora', arch=image_arch, version='31',
+'fedora', arch=image_arch, version='32',
checksum=self.chksum,
algorithm='sha256',
cache_dir=self.cache_dirs[0],
@@ -111,7 +111,7 @@ class BootLinuxX8664(BootLinux):
:avocado: tags=arch:x86_64
"""
-chksum = 'e3c1b309d9203604922d6e255c2c5d098a309c2d46215d8fc026954f3c5c27a0'
+chksum = '423a4ce32fa32c50c11e3d3ff392db97a762533b81bef9d00599de518a7469c8'
def test_pc_i440fx_tcg(self):
"""
@@ -161,7 +161,7 @@ class BootLinuxAarch64(BootLinux):
:avocado: tags=machine:gic-version=2
"""
-chksum = '1e18d9c0cf734940c4b5d5ec592facaed2af0ad0329383d5639c997fdf16fe49'
+chksum = 'b367755c664a2d7a26955bbfff985855adfa2ca15e908baf15b4b176d68d3967'
def add_common_args(self):
self.vm.add_args('-bios',
@@ -217,7 +217,7 @@ class BootLinuxPPC64(BootLinux):
:avocado: tags=arch:ppc64
"""
-chksum = '7c3528b85a3df4b2306e892199a9e1e43f991c506f2cc390dc4efa2026ad2f58'
+chksum = 'dd989a078d641713c55720ba3e4320b204ade6954e2bfe4570c8058dc36e2e5d'
def test_pseries_tcg(self):
"""
@@ -235,7 +235,7 @@ class BootLinuxS390X(BootLinux):
:avocado: tags=arch:s390x
"""
-chksum = '4caaab5a434fd4d1079149a072fdc7891e354f834d355069ca982fdcaf5a122d'
+chksum = '93e49b98fa016797a6864a95cbb7beaec86ffd61dbcd42a951158ae732dae1ec'
@skipIf(os.getenv('GITLAB_CI'), 'Running on GitLab')
def test_s390_ccw_virtio_tcg(self):
--
2.25.4
[PATCH-for-5.2? 0/1] Acceptance tests: bump Fedora to 32
I believe this may be a candidate for "right now" because the code changes here simply sync with external infrastructure changes, that is, the retirement of Fedora 31 from the official repository locations). The following jobs contain a validation of this bump: - https://gitlab.com/cleber.gnu/qemu/-/jobs/886864642#L72 - https://gitlab.com/cleber.gnu/qemu/-/jobs/886864633#L72 Thanks, - Cleber. Cleber Rosa (1): Acceptance tests: bump Fedora to 32 tests/acceptance/boot_linux.py | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) -- 2.25.4
[PATCH 1/9] target/mips: Introduce ase_msa_available() helper
Instead of accessing CP0_Config3 directly and checking
the 'MSA Present' bit, introduce an explicit helper,
making the code easier to read.
Signed-off-by: Philippe Mathieu-Daudé
---
target/mips/internal.h | 6 ++
target/mips/kvm.c | 12 ++--
target/mips/translate.c | 8 +++-
3 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/target/mips/internal.h b/target/mips/internal.h
index dd8a7809b64..f882ac1580c 100644
--- a/target/mips/internal.h
+++ b/target/mips/internal.h
@@ -80,6 +80,12 @@ enum CPUMIPSMSADataFormat {
DF_DOUBLE
};
+/* Check presence of MSA implementation */
+static inline bool ase_msa_available(CPUMIPSState *env)
+{
+return env->CP0_Config3 & (1 << CP0C3_MSAP);
+}
+
void mips_cpu_do_interrupt(CPUState *cpu);
bool mips_cpu_exec_interrupt(CPUState *cpu, int int_req);
void mips_cpu_dump_state(CPUState *cpu, FILE *f, int flags);
diff --git a/target/mips/kvm.c b/target/mips/kvm.c
index 72637a1e021..9bfd67ede39 100644
--- a/target/mips/kvm.c
+++ b/target/mips/kvm.c
@@ -81,7 +81,7 @@ int kvm_arch_init_vcpu(CPUState *cs)
}
}
-if (kvm_mips_msa_cap && env->CP0_Config3 & (1 << CP0C3_MSAP)) {
+if (kvm_mips_msa_cap && ase_msa_available(env)) {
ret = kvm_vcpu_enable_cap(cs, KVM_CAP_MIPS_MSA, 0, 0);
if (ret < 0) {
/* mark unsupported so it gets disabled on reset */
@@ -107,7 +107,7 @@ void kvm_mips_reset_vcpu(MIPSCPU *cpu)
warn_report("KVM does not support FPU, disabling");
env->CP0_Config1 &= ~(1 << CP0C1_FP);
}
-if (!kvm_mips_msa_cap && env->CP0_Config3 & (1 << CP0C3_MSAP)) {
+if (!kvm_mips_msa_cap && ase_msa_available(env)) {
warn_report("KVM does not support MSA, disabling");
env->CP0_Config3 &= ~(1 << CP0C3_MSAP);
}
@@ -624,7 +624,7 @@ static int kvm_mips_put_fpu_registers(CPUState *cs, int
level)
* FPU register state is a subset of MSA vector state, so don't put FPU
* registers if we're emulating a CPU with MSA.
*/
-if (!(env->CP0_Config3 & (1 << CP0C3_MSAP))) {
+if (!ase_msa_available(env)) {
/* Floating point registers */
for (i = 0; i < 32; ++i) {
if (env->CP0_Status & (1 << CP0St_FR)) {
@@ -643,7 +643,7 @@ static int kvm_mips_put_fpu_registers(CPUState *cs, int
level)
}
/* Only put MSA state if we're emulating a CPU with MSA */
-if (env->CP0_Config3 & (1 << CP0C3_MSAP)) {
+if (ase_msa_available(env)) {
/* MSA Control Registers */
if (level == KVM_PUT_FULL_STATE) {
err = kvm_mips_put_one_reg(cs, KVM_REG_MIPS_MSA_IR,
@@ -704,7 +704,7 @@ static int kvm_mips_get_fpu_registers(CPUState *cs)
* FPU register state is a subset of MSA vector state, so don't save
FPU
* registers if we're emulating a CPU with MSA.
*/
-if (!(env->CP0_Config3 & (1 << CP0C3_MSAP))) {
+if (!ase_msa_available(env)) {
/* Floating point registers */
for (i = 0; i < 32; ++i) {
if (env->CP0_Status & (1 << CP0St_FR)) {
@@ -723,7 +723,7 @@ static int kvm_mips_get_fpu_registers(CPUState *cs)
}
/* Only get MSA state if we're emulating a CPU with MSA */
-if (env->CP0_Config3 & (1 << CP0C3_MSAP)) {
+if (ase_msa_available(env)) {
/* MSA Control Registers */
err = kvm_mips_get_one_reg(cs, KVM_REG_MIPS_MSA_IR,
>msair);
diff --git a/target/mips/translate.c b/target/mips/translate.c
index c64a1bc42e1..a7c01c2ea5b 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -25049,8 +25049,7 @@ static void decode_opc_special(CPUMIPSState *env,
DisasContext *ctx)
gen_trap(ctx, op1, rs, rt, -1);
break;
case OPC_LSA: /* OPC_PMON */
-if ((ctx->insn_flags & ISA_MIPS32R6) ||
-(env->CP0_Config3 & (1 << CP0C3_MSAP))) {
+if ((ctx->insn_flags & ISA_MIPS32R6) || ase_msa_available(env)) {
decode_opc_special_r6(env, ctx);
} else {
/* Pmon entry point, also R4010 selsl */
@@ -25152,8 +25151,7 @@ static void decode_opc_special(CPUMIPSState *env,
DisasContext *ctx)
}
break;
case OPC_DLSA:
-if ((ctx->insn_flags & ISA_MIPS32R6) ||
-(env->CP0_Config3 & (1 << CP0C3_MSAP))) {
+if ((ctx->insn_flags & ISA_MIPS32R6) || ase_msa_available(env)) {
decode_opc_special_r6(env, ctx);
}
break;
@@ -32000,7 +31998,7 @@ void cpu_state_reset(CPUMIPSState *env)
}
/* MSA */
-if (env->CP0_Config3 & (1 << CP0C3_MSAP)) {
+if (ase_msa_available(env)) {
msa_reset(env);
}
--
2.26.2
[PATCH 2/9] target/mips: Simplify msa_reset()
Call msa_reset() inconditionally, but only reset
the MSA registers if MSA is implemented.
Signed-off-by: Philippe Mathieu-Daudé
---
Maybe not very useful.
---
target/mips/translate.c | 5 +
target/mips/translate_init.c.inc | 4
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/target/mips/translate.c b/target/mips/translate.c
index a7c01c2ea5b..803ffefba2c 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -31997,10 +31997,7 @@ void cpu_state_reset(CPUMIPSState *env)
env->hflags |= MIPS_HFLAG_M16;
}
-/* MSA */
-if (ase_msa_available(env)) {
-msa_reset(env);
-}
+msa_reset(env);
compute_hflags(env);
restore_fp_status(env);
diff --git a/target/mips/translate_init.c.inc b/target/mips/translate_init.c.inc
index 79f75ed863c..3b069190ed8 100644
--- a/target/mips/translate_init.c.inc
+++ b/target/mips/translate_init.c.inc
@@ -1018,6 +1018,10 @@ static void mvp_init (CPUMIPSState *env, const
mips_def_t *def)
static void msa_reset(CPUMIPSState *env)
{
+if (!ase_msa_available(env)) {
+return;
+}
+
#ifdef CONFIG_USER_ONLY
/* MSA access enabled */
env->CP0_Config5 |= 1 << CP0C5_MSAEn;
--
2.26.2
[PATCH 0/9] target/mips: Simplify MSA TCG logic
I converted MSA opcodes to decodetree. To keep the series small I split it in 2, this is the non-decodetree specific patches (so non-decodetree experts can review it ;) ). First we stop using env->insn_flags to check for MSAi presence, then we restrict TCG functions to DisasContext*. Based-on: <20201130102228.2395100-1-f4...@amsat.org> "target/mips: Allow executing MSA instructions on Loongson-3A4000" Philippe Mathieu-Daudé (9): target/mips: Introduce ase_msa_available() helper target/mips: Simplify msa_reset() target/mips: Use CP0_Config3 to set MIPS_HFLAG_MSA target/mips: Simplify MSA TCG logic target/mips: Remove now unused ASE_MSA definition target/mips: Alias MSA vector registers on FPU scalar registers target/mips: Extract msa_translate_init() from mips_tcg_init() target/mips: Remove CPUMIPSState* argument from gen_msa*() methods target/mips: Explode gen_msa_branch() as gen_msa_BxZ_V/BxZ() target/mips/internal.h | 8 +- target/mips/mips-defs.h | 1 - target/mips/kvm.c| 12 +- target/mips/translate.c | 206 ++- target/mips/translate_init.c.inc | 12 +- 5 files changed, 138 insertions(+), 101 deletions(-) -- 2.26.2
[DISCUSSION] How to set properties of non-pluggable devices?
Hi. Suppose I want to set a property of a non-pluggable device that cannot be set after the device has been realized (e.g., I can't use qmp to set the property after QEMU has started). Being non-pluggable means I can't use "-device foo,bar=baz" on the command line. [But I can use "-device foo,help" to list its properties :-) (if I also specify -M bar) ] How do people do this? The device is part of a "machine" (board really), so I could add the property to the machine to be passed on to the device when it's realized (at least I think I can), but that doesn't feel right: The machine has lots of devices -> it feels cleaner to associate the property with the device and not the machine (lest the machine over time collect a myriad of random properties to pass on to its devices). Things get a little complicated because the machine can have multiple copies of a device: specifying the device's name is insufficient. The device has an object path: /machine/foo/bar/device[0]. There's also /.../device[1]. IWBN to be able to do something along the lines of: -device-property /device/path[,PROP1=VALUE1,...] copying the syntax used for "-object". It's perhaps even nicer if this could be accomplished with -device: avoiding further confusion on what -device can and can't be used for (e.g., can I use -device-property to set a property that could also be set with -device?). If what I'm asking for is reasonable and isn't doable today (I'm certainly willing to believe I'm missing something), I'm happy to work on the patch (with some guidance as to what would be acceptable). One thought that comes to mind is to use -object, store the properties there, and have the machine collect them from there when realizing its devices. Or is that an abuse of -object ?
