Re: [PULL 1/9] IDE: deprecate ide-drive
Paolo Bonzini writes: > On 31/10/19 11:58, John Snow wrote: >> It's an old compatibility shim that just delegates to ide-cd or ide-hd. >> I'd like to refactor these some day, and getting rid of the super-object >> will make that easier. >> >> Either way, we don't need this. > > Good idea. I will prepare a similar patch for scsi-disk, even though > technically we're already in soft freeze; it makes no sense to deprecate > only one of the two. We still use scsi-disk for -drive if=scsi,... and for the desugaring of the usb-storage device, via scsi_bus_legacy_add_drive(). I figure you'd need to either wean them off scsi-disk or deprecate them, too.
Re: [PATCH] fw_cfg: Allow reboot-timeout=-1 again
"Dr. David Alan Gilbert" writes:
> * Han Han (h...@redhat.com) wrote:
>> However, another important question is: how can we avoid such undocumented
>> incompatibility appears again?
>
> The reboot-timeout one was accidental - it was a documented qemu
> feature; just no one noticed it when the input check was added.
Yes. Mistakes happen. Integration tests can catch them. Perfection is
impossible there as well, though.
> Officially if we actually want to deprecate a feature we should actually
> follow qemu's deprecation guidelines.
Yes.
>> I can show another case caused by such incompatibile change:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1745868#c0
>>
>> For the qemu devices, attributes, values, qmp cmds, qmp cmds arguments used
>> by libvirt, could we get a way to inform libvirt
>> that an incompatibile qemu change is coming, please update libvirt code
>> ASAP to adjust to that change?
>> Or another way that is more gently: popping up the warning of depreciation
>> instead of dropping it, and then drop it in the version
>> after next version.
>
> Yes that should happen;
No argument. The question is how. I'm working on making it easier to
do and easier to consume for QAPI interfaces, i.e. most of QMP.
> with deprecated devices it's easier than more
> subtle features like command line things; I'm not sure how that gets
> introspected. I thought libvirt already asked qemu for a list of
> devices, so I'm confused why libvirt didn't spot it before starting the
> VM in 1745868.
Command line isn't really introspectable (see my KVM Forum 2017 talk).
That said, the list of devices *is* introspectable with QMP:
{"execute": "qom-list-types",
"arguments": {"implements": "device", "abstract": false}}
I'm not sure what exactly goes wrong in RHBZ 1745868.
Sparc Solaris 10
Hi, I like to find to find out if you have a working qemu on solaris 10 or 11. I have tried the qemu-sun4vniagara but without networking. Is the networking support for niagara version available? Regards Zai
Re: presentation at kvm forum and pagefaults
Regarding the presentation I gave at the kvm forum on pagefaults. Two points: 1. pagefaults are important not just for migration. They are important for performance features such as autonuma and huge pages, since this relies on moving pages around. Migration can maybe be solved by switch to software but this is not a good solution for numa and thp since at a given time some page is likely being moved. 2. For devices such as networking RX order in which buffers are used *does not matter*. Thus if a device gets a fault in response to attempt to store a buffer into memory, it can just re-try, using the next buffer in queue instead. This works because normally buffers can be used out of order by device. The faulted buffer will be reused by another buffer when driver notifies device page has been faulted in. Note buffers are processed by buffer in the order in which they have been used, *not* the order in which they have been put in the queue. So this will *not* cause any packet reordering for the driver. Packets will only get dropped if all buffers are swapped out, which should be rare with a large RX queue. As I said at the forum, a side buffer for X packets to be stored temporarily is also additionally possible. But with the above it is no longer strictly required. This conflicts with the IN_ORDER feature flag, I guess we will have to re-think this flag then. If we do feel we need to salvage IN_ORDER as is, maybe device can use the buffer with length 0 and driver will re-post it later, but I am not I am not sure about this since involving the VF driver seems inelegant. -- MST
[PATCH V2 3/4] net/awd.c: Load advanced watch dog worker thread job
From: Zhang Chen
This patch load pulse_timer and timeout_timer in the new iothread.
The pulse timer will send pulse info to awd_node, and the timeout timer
will check the reply pulse from awd_node. If timeout occur, it will send
opt_script's data to the notification_node.
Signed-off-by: Zhang Chen
---
net/awd.c | 193 ++
1 file changed, 193 insertions(+)
diff --git a/net/awd.c b/net/awd.c
index ad3d39c982..04f40e7cc8 100644
--- a/net/awd.c
+++ b/net/awd.c
@@ -40,17 +40,137 @@ typedef struct AwdState {
char *awd_node;
char *notification_node;
char *opt_script;
+char *opt_script_data;
uint32_t pulse_interval;
uint32_t timeout;
CharBackend chr_awd_node;
CharBackend chr_notification_node;
+SocketReadState awd_rs;
+
+QEMUTimer *pulse_timer;
+QEMUTimer *timeout_timer;
IOThread *iothread;
+GMainContext *worker_context;
} AwdState;
typedef struct AwdClass {
ObjectClass parent_class;
} AwdClass;
+static int awd_chr_send(AwdState *s,
+const uint8_t *buf,
+uint32_t size)
+{
+int ret = 0;
+uint32_t len = htonl(size);
+
+if (!size) {
+return 0;
+}
+
+ret = qemu_chr_fe_write_all(>chr_awd_node, (uint8_t *),
+sizeof(len));
+if (ret != sizeof(len)) {
+goto err;
+}
+
+ret = qemu_chr_fe_write_all(>chr_awd_node, (uint8_t *)buf,
+size);
+if (ret != size) {
+goto err;
+}
+
+return 0;
+
+err:
+return ret < 0 ? ret : -EIO;
+}
+
+static int awd_chr_can_read(void *opaque)
+{
+return AWD_READ_LEN_MAX;
+}
+
+static void awd_node_in(void *opaque, const uint8_t *buf, int size)
+{
+AwdState *s = AWD(opaque);
+int ret;
+
+ret = net_fill_rstate(>awd_rs, buf, size);
+if (ret == -1) {
+qemu_chr_fe_set_handlers(>chr_awd_node, NULL, NULL, NULL, NULL,
+ NULL, NULL, true);
+error_report("advanced-watchdog get pulse error");
+}
+}
+
+static void awd_send_pulse(void *opaque)
+{
+AwdState *s = opaque;
+char buf[] = "advanced-watchdog pulse";
+
+awd_chr_send(s, (uint8_t *)buf, sizeof(buf));
+}
+
+static void awd_regular_pulse(void *opaque)
+{
+AwdState *s = opaque;
+
+awd_send_pulse(s);
+timer_mod(s->pulse_timer, qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) +
+ s->pulse_interval);
+}
+
+static void awd_timeout(void *opaque)
+{
+AwdState *s = opaque;
+int ret = 0;
+
+ret = qemu_chr_fe_write_all(>chr_notification_node,
+(uint8_t *)s->opt_script_data,
+strlen(s->opt_script_data));
+if (ret) {
+error_report("advanced-watchdog notification failure");
+}
+}
+
+static void awd_timer_init(AwdState *s)
+{
+AioContext *ctx = iothread_get_aio_context(s->iothread);
+
+s->timeout_timer = aio_timer_new(ctx, QEMU_CLOCK_VIRTUAL, SCALE_MS,
+ awd_timeout, s);
+
+s->pulse_timer = aio_timer_new(ctx, QEMU_CLOCK_VIRTUAL, SCALE_MS,
+ awd_regular_pulse, s);
+
+if (!s->pulse_interval) {
+s->pulse_interval = AWD_PULSE_INTERVAL_DEFAULT;
+}
+
+if (!s->timeout) {
+s->timeout = AWD_TIMEOUT_DEFAULT;
+}
+
+timer_mod(s->pulse_timer, qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) +
+ s->pulse_interval);
+}
+
+static void awd_timer_del(AwdState *s)
+{
+if (s->pulse_timer) {
+timer_del(s->pulse_timer);
+timer_free(s->pulse_timer);
+s->pulse_timer = NULL;
+}
+
+if (s->timeout_timer) {
+timer_del(s->timeout_timer);
+timer_free(s->timeout_timer);
+s->timeout_timer = NULL;
+}
+ }
+
static char *awd_get_node(Object *obj, Error **errp)
{
AwdState *s = AWD(obj);
@@ -177,6 +297,22 @@ out:
error_propagate(errp, local_err);
}
+static void awd_rs_finalize(SocketReadState *awd_rs)
+{
+AwdState *s = container_of(awd_rs, AwdState, awd_rs);
+
+if (!s->server) {
+char buf[] = "advanced-watchdog reply pulse";
+
+awd_chr_send(s, (uint8_t *)buf, sizeof(buf));
+}
+
+timer_mod(s->timeout_timer, qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) +
+ s->timeout);
+
+error_report("advanced-watchdog got message : %s", awd_rs->buf);
+}
+
static int find_and_check_chardev(Chardev **chr,
char *chr_name,
Error **errp)
@@ -197,6 +333,46 @@ static int find_and_check_chardev(Chardev **chr,
return 0;
}
+static void awd_iothread(AwdState *s)
+{
+object_ref(OBJECT(s->iothread));
+s->worker_context = iothread_get_g_main_context(s->iothread);
+
+qemu_chr_fe_set_handlers(>chr_awd_node, awd_chr_can_read,
+ awd_node_in, NULL, NULL,
+ s,
[PATCH V2 1/4] net/awd.c: Introduce Advanced Watch Dog module framework
From: Zhang Chen
This patch introduce a new module named Advanced Watch Dog,
and defined the input and output parameter. AWD use standard chardev
as the way of communicationg with the outside world.
If you want to use it, please add "--enable-awd" when configure qemu.
Demo command:
-object
advanced-watchdog,id=heart1,server=on,awd_node=h1,notification_node=heartbeat0,opt_script=opt_script_path,iothread=iothread1,pulse_interval=1000,timeout=5000
Signed-off-by: Zhang Chen
---
configure | 9 ++
net/Makefile.objs | 1 +
net/awd.c | 261 ++
qemu-options.hx | 6 ++
4 files changed, 277 insertions(+)
create mode 100644 net/awd.c
diff --git a/configure b/configure
index 72553f98ea..a857a8c2d7 100755
--- a/configure
+++ b/configure
@@ -383,6 +383,7 @@ vhost_scsi=""
vhost_vsock=""
vhost_user=""
vhost_user_fs=""
+awd="no"
kvm="no"
hax="no"
hvf="no"
@@ -1303,6 +1304,10 @@ for opt do
;;
--enable-vhost-user-fs) vhost_user_fs="yes"
;;
+ --disable-awd) awd="no"
+ ;;
+ --enable-awd) awd="yes"
+ ;;
--disable-opengl) opengl="no"
;;
--enable-opengl) opengl="yes"
@@ -1779,6 +1784,7 @@ disabled with --disable-FEATURE, default is enabled if
available:
vhost-cryptovhost-user-crypto backend support
vhost-kernelvhost kernel backend support
vhost-user vhost-user backend support
+ awd Advanced Watch Dog support
spice spice
rbd rados block device (rbd)
libiscsiiscsi support
@@ -7002,6 +7008,9 @@ fi
if test "$vhost_user" = "yes" ; then
echo "CONFIG_VHOST_USER=y" >> $config_host_mak
fi
+if test "$awd" = "yes" ; then
+ echo "CONFIG_AWD=y" >> $config_host_mak
+fi
if test "$vhost_user_fs" = "yes" ; then
echo "CONFIG_VHOST_USER_FS=y" >> $config_host_mak
fi
diff --git a/net/Makefile.objs b/net/Makefile.objs
index c5d076d19c..187e655443 100644
--- a/net/Makefile.objs
+++ b/net/Makefile.objs
@@ -19,6 +19,7 @@ common-obj-y += colo-compare.o
common-obj-y += colo.o
common-obj-y += filter-rewriter.o
common-obj-y += filter-replay.o
+common-obj-$(CONFIG_AWD) += awd.o
tap-obj-$(CONFIG_LINUX) = tap-linux.o
tap-obj-$(CONFIG_BSD) = tap-bsd.o
diff --git a/net/awd.c b/net/awd.c
new file mode 100644
index 00..d42b4a7372
--- /dev/null
+++ b/net/awd.c
@@ -0,0 +1,261 @@
+/*
+ * Advanced Watch Dog
+ *
+ * COarse-grain LOck-stepping Virtual Machines for Non-stop Service (COLO)
+ * (a.k.a. Fault Tolerance or Continuous Replication)
+ *
+ * Copyright (c) 2019 Intel Corporation
+ *
+ * Author: Zhang Chen
+ *
+ * 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/error-report.h"
+#include "trace.h"
+#include "qemu-common.h"
+#include "qapi/error.h"
+#include "net/net.h"
+#include "qom/object_interfaces.h"
+#include "qom/object.h"
+#include "chardev/char-fe.h"
+#include "qemu/sockets.h"
+#include "sysemu/iothread.h"
+
+#define TYPE_AWD "advanced-watchdog"
+#define AWD(obj) OBJECT_CHECK(AwdState, (obj), TYPE_AWD)
+
+#define AWD_READ_LEN_MAX NET_BUFSIZE
+/* Default advanced watchdog pulse interval */
+#define AWD_PULSE_INTERVAL_DEFAULT 5000
+/* Default advanced watchdog timeout */
+#define AWD_TIMEOUT_DEFAULT 2000
+
+typedef struct AwdState {
+Object parent;
+
+bool server;
+char *awd_node;
+char *notification_node;
+char *opt_script;
+uint32_t pulse_interval;
+uint32_t timeout;
+IOThread *iothread;
+} AwdState;
+
+typedef struct AwdClass {
+ObjectClass parent_class;
+} AwdClass;
+
+static char *awd_get_node(Object *obj, Error **errp)
+{
+AwdState *s = AWD(obj);
+
+return g_strdup(s->awd_node);
+}
+
+static void awd_set_node(Object *obj, const char *value, Error **errp)
+{
+AwdState *s = AWD(obj);
+
+g_free(s->awd_node);
+s->awd_node = g_strdup(value);
+}
+
+static char *noti_get_node(Object *obj, Error **errp)
+{
+AwdState *s = AWD(obj);
+
+return g_strdup(s->notification_node);
+}
+
+static void noti_set_node(Object *obj, const char *value, Error **errp)
+{
+AwdState *s = AWD(obj);
+
+g_free(s->notification_node);
+s->notification_node = g_strdup(value);
+}
+
+static char *opt_script_get_node(Object *obj, Error **errp)
+{
+AwdState *s = AWD(obj);
+
+return g_strdup(s->opt_script);
+}
+
+static void opt_script_set_node(Object *obj, const char *value, Error **errp)
+{
+AwdState *s = AWD(obj);
+
+g_free(s->opt_script);
+s->opt_script = g_strdup(value);
+}
+
+static bool awd_get_server(Object *obj, Error **errp)
+{
+AwdState *s = AWD(obj);
+
+return s->server;
+}
+
+static void awd_set_server(Object *obj, bool value, Error **errp)
+{
+AwdState *s = AWD(obj);
+
+s->server = value;
+}
+
+static void awd_get_interval(Object *obj, Visitor *v,
+ const char *name, void *opaque,
+
[PATCH V2 4/4] vl.c: Make Advanced Watch Dog delayed initialization
From: Zhang Chen
Because Advanced Watch Dog module needs chardev socket
to initialize properly before.
Signed-off-by: Zhang Chen
---
vl.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/vl.c b/vl.c
index 6a65a64bfd..048fe458b9 100644
--- a/vl.c
+++ b/vl.c
@@ -2689,6 +2689,13 @@ static bool object_create_initial(const char *type,
QemuOpts *opts)
return false;
}
+/*
+ * Reason: Advanced Watch Dog property "chardev".
+ */
+if (g_str_equal(type, "advanced-watchdog")) {
+return false;
+}
+
/* Memory allocation by backends needs to be done
* after configure_accelerator() (due to the tcg_enabled()
* checks at memory_region_init_*()).
--
2.17.1
[PATCH V2 2/4] net/awd.c: Initailize input/output chardev
From: Zhang Chen
Find and check the chardev awd_node and notification_node,
The awd_node used for keep connect with outside(like VM client/other
host/Remote server), and the notification_node used for do some
operation when disconnect event occur.
Signed-off-by: Zhang Chen
---
net/awd.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/net/awd.c b/net/awd.c
index d42b4a7372..ad3d39c982 100644
--- a/net/awd.c
+++ b/net/awd.c
@@ -42,6 +42,8 @@ typedef struct AwdState {
char *opt_script;
uint32_t pulse_interval;
uint32_t timeout;
+CharBackend chr_awd_node;
+CharBackend chr_notification_node;
IOThread *iothread;
} AwdState;
@@ -175,9 +177,30 @@ out:
error_propagate(errp, local_err);
}
+static int find_and_check_chardev(Chardev **chr,
+ char *chr_name,
+ Error **errp)
+{
+*chr = qemu_chr_find(chr_name);
+if (*chr == NULL) {
+error_setg(errp, "Device '%s' not found",
+ chr_name);
+return 1;
+}
+
+if (!qemu_chr_has_feature(*chr, QEMU_CHAR_FEATURE_RECONNECTABLE)) {
+error_setg(errp, "chardev \"%s\" is not reconnectable",
+ chr_name);
+return 1;
+}
+
+return 0;
+}
+
static void awd_complete(UserCreatable *uc, Error **errp)
{
AwdState *s = AWD(uc);
+Chardev *chr;
if (!s->awd_node || !s->iothread ||
!s->notification_node || !s->opt_script) {
@@ -187,6 +210,20 @@ static void awd_complete(UserCreatable *uc, Error **errp)
return;
}
+if (find_and_check_chardev(, s->awd_node, errp) ||
+!qemu_chr_fe_init(>chr_awd_node, chr, errp)) {
+error_setg(errp, "advanced-watchdog can't find chardev awd_node: %s",
+ s->awd_node);
+return;
+}
+
+if (find_and_check_chardev(, s->notification_node, errp) ||
+!qemu_chr_fe_init(>chr_notification_node, chr, errp)) {
+error_setg(errp, "advanced-watchdog can't find "
+ "chardev notification_node: %s", s->notification_node);
+return;
+}
+
return;
}
--
2.17.1
[PATCH V2 0/4] Introduce Advanced Watch Dog module
From: Zhang Chen Advanced Watch Dog is an universal monitoring module on VMM side, it can be used to detect network down(VMM to guest, VMM to VMM, VMM to another remote server) and do previously set operation. Current AWD patch just accept any input as the signal to refresh the watchdog timer, and we can also make a certain interactive protocol here. For the output user can pre-write some command or some messages in the AWD opt-script. We noticed that there is no way for VMM communicate directly, maybe some people think we don't need such things(up layer software like openstack can handle it). But we engaged with real customer found that in some cases,they need a lightweight and efficient mechanism to solve some practical problems(openstack is too heavy). for example: When it detects lost connection with the paired node,it will send message to admin, notify another VMM, send qmp command to qemu do some operation like restart the VM, build VMM heartbeat system, etc. It make user have basic VM/Host network monitoring tools and basic false tolerance and recovery solution. Demo usage(for COLO heartbeat service): In primary node: -chardev socket,id=h1,host=3.3.3.3,port=9009,server,nowait -chardev socket,id=heartbeat0,host=3.3.3.3,port=4445 -object iothread,id=iothread2 -object advanced-watchdog,id=heart1,server=on,awd_node=h1,notification_node=heartbeat0,opt_script=colo_opt_script_path,iothread=iothread1,pulse_interval=1000,timeout=5000 In secondary node: -monitor tcp::4445,server,nowait -chardev socket,id=h1,host=3.3.3.3,port=9009,reconnect=1 -chardev socket,id=heart1,host=3.3.3.8,port=4445 -object iothread,id=iothread1 -object advanced-watchdog,id=heart1,server=off,awd_node=h1,notification_node=heart1,opt_script=colo_secondary_opt_script,iothread=iothread1,timeout=1 V2: - Addressed Philippe comments add configure selector for AWD. Initial: - Initial version. Zhang Chen (4): net/awd.c: Introduce Advanced Watch Dog module framework net/awd.c: Initailize input/output chardev net/awd.c: Load advanced watch dog worker thread job vl.c: Make Advanced Watch Dog delayed initialization configure | 9 + net/Makefile.objs | 1 + net/awd.c | 491 ++ qemu-options.hx | 6 + vl.c | 7 + 5 files changed, 514 insertions(+) create mode 100644 net/awd.c -- 2.17.1
Re: [PATCH] target/i386: return directly from hyperv_init_vcpu() if hyperv not enabled
Patchew URL: https://patchew.org/QEMU/20191101014528.14505-1-richardw.y...@linux.intel.com/ Hi, This series seems to have some coding style problems. See output below for more information: Subject: [PATCH] target/i386: return directly from hyperv_init_vcpu() if hyperv not enabled Type: series Message-id: 20191101014528.14505-1-richardw.y...@linux.intel.com === TEST SCRIPT BEGIN === #!/bin/bash git rev-parse base > /dev/null || exit 0 git config --local diff.renamelimit 0 git config --local diff.renames True git config --local diff.algorithm histogram ./scripts/checkpatch.pl --mailback base.. === TEST SCRIPT END === Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384 Switched to a new branch 'test' d7652b4 target/i386: return directly from hyperv_init_vcpu() if hyperv not enabled === OUTPUT BEGIN === ERROR: Missing Signed-off-by: line(s) total: 1 errors, 0 warnings, 9 lines checked Commit d7652b4f28ff (target/i386: return directly from hyperv_init_vcpu() if hyperv not enabled) has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in MAINTAINERS. === OUTPUT END === Test command exited with code: 1 The full log is available at http://patchew.org/logs/20191101014528.14505-1-richardw.y...@linux.intel.com/testing.checkpatch/?type=message. --- Email generated automatically by Patchew [https://patchew.org/]. Please send your feedback to patchew-de...@redhat.com
[PATCH] target/i386: return directly from hyperv_init_vcpu() if hyperv not enabled
If hyperv is not enabled, related features are not set or enabled.
No extra work to do, return directly.
---
First time touch hyperv, hope my understanding is correct.
Signed-off-by: Wei Yang
---
target/i386/kvm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index bfd09bd441..6532904f0c 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -1365,6 +1365,9 @@ static int hyperv_init_vcpu(X86CPU *cpu)
Error *local_err = NULL;
int ret;
+if (!hyperv_enabled(cpu))
+return 0;
+
if (cpu->hyperv_passthrough && hv_passthrough_mig_blocker == NULL) {
error_setg(_passthrough_mig_blocker,
"'hv-passthrough' CPU flag prevents migration, use explicit"
--
2.17.1
[PATCH v7 0/9] target/arm/kvm: enable SVE in guests
Hi Jones, Thanks for your patch. I have tested the v7 patch. All the test is passed. Please add Tested-by: Zhang Lei My test environment is below. *QEMU base + v7 pathc base is 58560ad254 (origin/master, origin/HEAD, master) Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-4.2-20191024' into staging *libvirt https://gitlab.com/abologna/libvirt.git commit fe6985c7098bf48fd7bade83ef42a98a4457ce84 Author: Andrea Bolognani Date: Thu Jul 25 15:38:38 2019 +0200 news: Update for ARM CPU features *Kernel linux-5.3.7 Best Regards, Lei Zhang
[Bug 1799792] Re: Broken scaling with gtk,gl=on on a hidpi display
Also happens on Ubuntu 19.10 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1799792 Title: Broken scaling with gtk,gl=on on a hidpi display Status in QEMU: New Bug description: Tested on QEMU 3.0.0 on Arch Linux. I'm using a hidpi screen, and therefore use those environment variables in order to have GTK+ apps properly scaled: GDK_SCALE=2 GDK_DPI_SCALE=0.5 However, QEMU, when launched with "-display gtk,gl=on" option, doesn't scale the window content properly, as seen on the attached screenshot. Switching to "-display gtk,gl=off" and "-display sdl,gl=on" makes it work fine. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1799792/+subscriptions
Re: [RFC] q800: fix I/O memory map
On 10/31/19 11:03 AM, Laurent Vivier wrote:
Linux kernel 5.4 will introduce a new memory map for SWIM device.
(aee6bff1c325 ("m68k: mac: Revisit floppy disc controller base addresses"))
Until this release all MMIO are mapped between 0x50f0 and 0x50f4,
but it appears that for real hardware 0x50f0 is not the base address:
the MMIO region spans 0x5000 through 0x6000, and 0x5004 through
0x5400 is repeated images of 0x5000 to 0x5004.
Fixed: 04e7ca8d0f ("hw/m68k: define Macintosh Quadra 800")
Signed-off-by: Laurent Vivier
---
hw/m68k/q800.c | 33 +
1 file changed, 25 insertions(+), 8 deletions(-)
diff --git a/hw/m68k/q800.c b/hw/m68k/q800.c
index 2b4842f8c6..8122e7c612 100644
--- a/hw/m68k/q800.c
+++ b/hw/m68k/q800.c
@@ -60,14 +60,14 @@
#define MACH_MAC3
#define Q800_MAC_CPU_ID 2
-#define VIA_BASE 0x50f0
-#define SONIC_PROM_BASE 0x50f08000
-#define SONIC_BASE0x50f0a000
-#define SCC_BASE 0x50f0c020
-#define ESP_BASE 0x50f1
-#define ESP_PDMA 0x50f10100
-#define ASC_BASE 0x50F14000
-#define SWIM_BASE 0x50F1E000
+#define VIA_BASE 0x5000
+#define SONIC_PROM_BASE 0x50008000
+#define SONIC_BASE0x5000a000
+#define SCC_BASE 0x5000c020
+#define ESP_BASE 0x5001
+#define ESP_PDMA 0x50010100
+#define ASC_BASE 0x50014000
+#define SWIM_BASE 0x5001E000
#define NUBUS_SUPER_SLOT_BASE 0x6000
#define NUBUS_SLOT_BASE 0xf000
@@ -135,6 +135,7 @@ static void q800_init(MachineState *machine)
int32_t initrd_size;
MemoryRegion *rom;
MemoryRegion *ram;
+int i;
ram_addr_t ram_size = machine->ram_size;
const char *kernel_filename = machine->kernel_filename;
const char *initrd_filename = machine->initrd_filename;
@@ -163,10 +164,26 @@ static void q800_init(MachineState *machine)
cpu = M68K_CPU(cpu_create(machine->cpu_type));
qemu_register_reset(main_cpu_reset, cpu);
+/* RAM */
ram = g_malloc(sizeof(*ram));
memory_region_init_ram(ram, NULL, "m68k_mac.ram", ram_size, _abort);
memory_region_add_subregion(get_system_memory(), 0, ram);
+/*
+ * Memory from VIA_BASE to VIA_BASE + 0x4 is repeated
+ * from VIA_BASE + 0x4 to VIA_BASE + 0x400
+ */
Maybe:
const size_t via_aliases_count = (0x400 / 0x4) - 1;
MemoryRegion *via_alias = g_new(MemoryRegion, via_aliases_count);
for (size_t i = 0; i < via_aliases_count; i++) {
...
memory_region_add_subregion(get_system_memory(),
VIA_BASE + (i + 1) * 0x4,
via_alias[i]);
...
}
+for (i = 1; i < 256; i++) {
+MemoryRegion *io = g_malloc(sizeof(*io));
+char *name = g_strdup_printf("mac_m68k.io[%d]", i);
+
+memory_region_init_alias(io, NULL, name, get_system_memory(),
+ VIA_BASE, 0x4);
+memory_region_add_subregion(get_system_memory(),
+VIA_BASE + i * 0x4, io);
+g_free(name);
+}
I'm trying to get ride of this pattern, so I plan to refactor this later
(and will use 256*KiB). Anyway not this patch problem.
Reviewed-by: Philippe Mathieu-Daudé
+
/* IRQ Glue */
irq = g_new0(GLUEState, 1);
[PATCH 2/2] vhost-user-scsi: reset the device if supported
If the vhost-user-scsi backend supports the VHOST_USER_F_RESET_DEVICE
protocol feature, then the device can be reset when requested.
If this feature is not supported, do not try a reset as this will send
a VHOST_USER_RESET_OWNER that the backend is not expecting,
potentially putting into an inoperable state.
Signed-off-by: David Vrabel
Signed-off-by: Raphael Norwitz
---
hw/scsi/vhost-user-scsi.c | 24
1 file changed, 24 insertions(+)
diff --git a/hw/scsi/vhost-user-scsi.c b/hw/scsi/vhost-user-scsi.c
index 6a6c15d..23f972d 100644
--- a/hw/scsi/vhost-user-scsi.c
+++ b/hw/scsi/vhost-user-scsi.c
@@ -39,6 +39,10 @@ static const int user_feature_bits[] = {
VHOST_INVALID_FEATURE_BIT
};
+enum VhostUserProtocolFeature {
+VHOST_USER_PROTOCOL_F_RESET_DEVICE = 13,
+};
+
static void vhost_user_scsi_set_status(VirtIODevice *vdev, uint8_t status)
{
VHostUserSCSI *s = (VHostUserSCSI *)vdev;
@@ -62,6 +66,25 @@ static void vhost_user_scsi_set_status(VirtIODevice *vdev,
uint8_t status)
}
}
+static void vhost_user_scsi_reset(VirtIODevice *vdev)
+{
+VHostSCSICommon *vsc = VHOST_SCSI_COMMON(vdev);
+struct vhost_dev *dev = >dev;
+
+/*
+ * Historically, reset was not implemented so only reset devices
+ * that are expecting it.
+ */
+if (!virtio_has_feature(dev->protocol_features,
+VHOST_USER_PROTOCOL_F_RESET_DEVICE)) {
+return;
+}
+
+if (dev->vhost_ops->vhost_reset_device) {
+dev->vhost_ops->vhost_reset_device(dev);
+}
+}
+
static void vhost_dummy_handle_output(VirtIODevice *vdev, VirtQueue *vq)
{
}
@@ -182,6 +205,7 @@ static void vhost_user_scsi_class_init(ObjectClass *klass,
void *data)
vdc->get_features = vhost_scsi_common_get_features;
vdc->set_config = vhost_scsi_common_set_config;
vdc->set_status = vhost_user_scsi_set_status;
+vdc->reset = vhost_user_scsi_reset;
fwc->get_dev_path = vhost_scsi_common_get_fw_dev_path;
}
--
1.8.3.1
[PATCH 0/2] vhost-user: add message for device reset
I have updated patches [1] sent by David Vrabel last year: [1] https://lists.gnu.org/archive/html/qemu-devel/2018-03/msg05077.html This change adds a new ???reset device??? feature to the vhost-user protocol and a corresponding VHOST_USER_RESET_DEVICE message to notify vhost-user backends when a virtio scsi device is reset by a guest. It also adds support for this new feature/message in vhost-user-scsi. Now, iff a vhost-user-scsi backend reports that it supports the new "reset device" feature, QEMU will send a VHOST_USER_RESET_DEVICE message when the guest resets the virtio device. Existing backends will be unaffected. Other types vhost-user backends can benefit from using this new message. Those built using libvhost-user, for example, rely on the depricated VHOST_USER_RESET_OWNER message to notify vhost-user backends about device resets and can be updated to use this new supported message. Raphael Raphael Norwitz (2): vhost-user: add VHOST_USER_RESET_DEVICE to reset devices vhost-user-scsi: reset the device if supported docs/interop/vhost-user.rst | 15 +++ hw/scsi/vhost-user-scsi.c | 24 hw/virtio/vhost-user.c | 8 +++- 3 files changed, 46 insertions(+), 1 deletion(-) -- 1.8.3.1
[PATCH 1/2] vhost-user: add VHOST_USER_RESET_DEVICE to reset devices
Add a VHOST_USER_RESET_DEVICE message which will reset the vhost user
backend. Disabling all rings, and resetting all internal state, ready
for the backend to be reinitialized.
A backend has to report it supports this features with the
VHOST_USER_PROTOCOL_F_RESET_DEVICE protocol feature bit. If it does
so, the new message is used instead of sending a RESET_OWNER which has
had inconsistent implementations.
Signed-off-by: David Vrabel
Signed-off-by: Raphael Norwitz
---
docs/interop/vhost-user.rst | 15 +++
hw/virtio/vhost-user.c | 8 +++-
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst
index 7827b71..d213d4a 100644
--- a/docs/interop/vhost-user.rst
+++ b/docs/interop/vhost-user.rst
@@ -785,6 +785,7 @@ Protocol features
#define VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD 10
#define VHOST_USER_PROTOCOL_F_HOST_NOTIFIER 11
#define VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD 12
+ #define VHOST_USER_PROTOCOL_F_RESET_DEVICE 13
Master message types
@@ -1190,6 +1191,20 @@ Master message types
ancillary data. The GPU protocol is used to inform the master of
rendering state and updates. See vhost-user-gpu.rst for details.
+``VHOST_USER_RESET_DEVICE``
+ :id: 34
+ :equivalent ioctl: N/A
+ :master payload: N/A
+ :slave payload: N/A
+
+ Ask the vhost user backend to disable all rings and reset all
+ internal device state to the initial state, ready to be
+ reinitialized. The backend retains ownership of the device
+ throughout the reset operation.
+
+ Only valid if the ``VHOST_USER_PROTOCOL_F_RESET_DEVICE`` protocol
+ feature is set by the backend.
+
Slave message types
---
diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
index 02a9b25..d27a10f 100644
--- a/hw/virtio/vhost-user.c
+++ b/hw/virtio/vhost-user.c
@@ -58,6 +58,7 @@ enum VhostUserProtocolFeature {
VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD = 10,
VHOST_USER_PROTOCOL_F_HOST_NOTIFIER = 11,
VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD = 12,
+VHOST_USER_PROTOCOL_F_RESET_DEVICE = 13,
VHOST_USER_PROTOCOL_F_MAX
};
@@ -98,6 +99,7 @@ typedef enum VhostUserRequest {
VHOST_USER_GET_INFLIGHT_FD = 31,
VHOST_USER_SET_INFLIGHT_FD = 32,
VHOST_USER_GPU_SET_SOCKET = 33,
+VHOST_USER_RESET_DEVICE = 34,
VHOST_USER_MAX
} VhostUserRequest;
@@ -890,10 +892,14 @@ static int vhost_user_set_owner(struct vhost_dev *dev)
static int vhost_user_reset_device(struct vhost_dev *dev)
{
VhostUserMsg msg = {
-.hdr.request = VHOST_USER_RESET_OWNER,
.hdr.flags = VHOST_USER_VERSION,
};
+msg.hdr.request = virtio_has_feature(dev->protocol_features,
+ VHOST_USER_PROTOCOL_F_RESET_DEVICE)
+? VHOST_USER_RESET_DEVICE
+: VHOST_USER_RESET_OWNER;
+
if (vhost_user_write(dev, , NULL, 0) < 0) {
return -1;
}
--
1.8.3.1
Re: [RFC PATCH 0/6] docs: integrate doc comments with Sphinx build
On 29/10/19 19:21, Peter Maydell wrote:
> On Tue, 29 Oct 2019 at 16:22, Paolo Bonzini wrote:
>>
>> Hello,
>>
>> this is an attempt at including kernel-doc, with small tweaks (see patch
>> 2) to support QEMU's doc comment format, in the Sphinx documentation
>> pipeline.
>>
>> The ugly part is patch 3, which disables Sphinx's "nitpicking" (warn on
>> invalid cross-reference) mode. It would probably be possible to use
>> the nitpick_ignore configuration entry instead.
>>
>> Paolo
>>
>> Paolo Bonzini (6):
>> docs: import Linux kernel-doc script and extension
>> docs: tweak kernel-doc for QEMU coding standards
>> docs: disable sphinx warning about missing cross references
>> memory: adjust API documentation to (modified) kerneldoc format
>> docs: add memory API reference
>> memory: include MemoryListener documentation and some missing function
>> parameters
>
> Could you briefly describe the differences between this patchset
> and the RFC I sent a while back:
> https://patchew.org/QEMU/20190521122519.12573-1-peter.mayd...@linaro.org/
> please?
Thanks for the pointer, I didn't remember it; my series is not based on
your work. The main difference is in patch 2 ("docs: tweak kernel-doc
for QEMU coding standards"), which tweaks kernel-doc to recognize camel
case types and QEMU's usage of "#" to indicate types (inspired by GTKDoc
and different from the "&" sigil used in the kernel sources).
As a result of this, the adjustments to be made to header files are much
smaller. In particular there are no hunks such as
/**
- * MemoryListener: callbacks structure for updates to the physical
memory map
+ * struct MemoryListener: callbacks structure for updates to the
physical memory map
*
The other difference is that this is based on newer kernel sources,
therefore I had to import the additional file docs/sphinx/kernellog.py.
On the other hand, I forgot to commit docs/sphinx/kerneldoc.py...
If we agree that nitpicking mode is unmaintainable, I can merge your
work with mine and repost.
Thanks,
Paolo
Re: [PATCH v5 11/13] hw/s390x/ipl: replace deprecated qdev_reset_all registration
On 10/18/19 5:06 PM, Damien Hedde wrote: Replace deprecated qdev_reset_all by resettable_cold_reset_fn for the ipl registration in the main reset handlers. This does not impact the behavior for the following reasons: + at this point resettable just call the old reset methods of devices and buses in the same order than qdev/qbus. + resettable handlers registered with qemu_register_reset are serialized; there is no interleaving. + eventual explicit calls to legacy reset API (device_reset or qdev/qbus_reset) inside this reset handler will not be masked out by resettable mechanism; they do not go through resettable api. Signed-off-by: Damien Hedde --- Cc: Cornelia Huck Cc: qemu-s3...@nongnu.org Cc: Christian Borntraeger Cc: Thomas Huth --- hw/s390x/ipl.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/hw/s390x/ipl.c b/hw/s390x/ipl.c index ca544d64c5..2689f7a017 100644 --- a/hw/s390x/ipl.c +++ b/hw/s390x/ipl.c @@ -237,7 +237,15 @@ static void s390_ipl_realize(DeviceState *dev, Error **errp) */ ipl->compat_start_addr = ipl->start_addr; ipl->compat_bios_start_addr = ipl->bios_start_addr; -qemu_register_reset(qdev_reset_all_fn, dev); +/* + * Because this Device is not on any bus in the qbus tree (it is + * not a sysbus device and it's not on some other bus like a PCI + * bus) it will not be automatically reset by the 'reset the + * sysbus' hook registered by vl.c like most devices. So we must + * manually register a reset hook for it. :) + * TODO: there should be a better way to do this. :( + */ +qemu_register_reset(resettable_cold_reset_fn, dev); Reviewed-by: Philippe Mathieu-Daudé error: error_propagate(errp, err); }
Re: [PATCH v5 08/13] hw/core: deprecate old reset functions and introduce new ones
On 10/18/19 5:06 PM, Damien Hedde wrote:
Deprecate device_legacy_reset(), qdev_reset_all() and
qbus_reset_all() to be replaced by new functions
device_cold_reset() and bus_cold_reset() which uses resettable API.
Also introduce resettable_cold_reset_fn() which may be used as a
replacement for qdev_reset_all_fn and qbus_reset_all_fn().
Following patches will be needed to look at legacy reset call sites
and switch to resettable api. The legacy functions will be removed
when unused.
Signed-off-by: Damien Hedde
---
I've removed the general helpers
+ device_reset(DeviceState *dev, ResetType type)
+ bus_reset(BusState *dev, ResetType type)
because with several reset types, all devices and buses will not
implement all of them. I think it is preferable to define a
type-specific helper every time it is needed for base classes
implementing the reset type (eg a device_pci_reset(PciDev*) for the
pci reset type if add that).
Agreed.
So device_reset()/bus_reset() symbol names are not taken anymore. I
don't have a strong opinion of what names should have the
device_cold_reset() and bus_cold_reset() function added in this
patch. It could be device/bus_hard_reset() (the current
qbus_reset_all() comment mention we do a "hard" reset) or simply
device/bus_reset() or anything else.
What do you think ? Any better idea ? It should be consistent with
the reset type name but we can change it also if cold is not what we
want.
Cold/hot are self-illustrative so seems fine. Hard/soft are used in
electronic but less in software I'd say.
Note that if we don't settle for device/bus_reset(). We can drop
the first patch that renames device_reset() to device_legacy_reset()
---
hw/core/bus.c | 5 +
hw/core/qdev.c | 5 +
hw/core/resettable.c| 5 +
include/hw/qdev-core.h | 27 +++
include/hw/resettable.h | 9 +
5 files changed, 51 insertions(+)
diff --git a/hw/core/bus.c b/hw/core/bus.c
index 7c05e80db8..5f9e261bb2 100644
--- a/hw/core/bus.c
+++ b/hw/core/bus.c
@@ -68,6 +68,11 @@ int qbus_walk_children(BusState *bus,
return 0;
}
+void bus_cold_reset(BusState *bus)
+{
+resettable_reset(OBJECT(bus), RESET_TYPE_COLD);
+}
+
bool bus_is_in_reset(BusState *bus)
{
return resettable_is_in_reset(OBJECT(bus));
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index c5d107ea4e..3e6600ce76 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -335,6 +335,11 @@ void qbus_reset_all_fn(void *opaque)
qbus_reset_all(bus);
}
+void device_cold_reset(DeviceState *dev)
+{
+resettable_reset(OBJECT(dev), RESET_TYPE_COLD);
+}
+
bool device_is_in_reset(DeviceState *dev)
{
return resettable_is_in_reset(OBJECT(dev));
diff --git a/hw/core/resettable.c b/hw/core/resettable.c
index 60d4285fcc..3d3200bdbc 100644
--- a/hw/core/resettable.c
+++ b/hw/core/resettable.c
@@ -252,6 +252,11 @@ void resettable_change_parent(Object *obj, Object *newp,
Object *oldp)
}
}
+void resettable_cold_reset_fn(void *opaque)
+{
+resettable_reset((Object *) opaque, RESET_TYPE_COLD);
Why not take a Object* argument?
+}
+
void resettable_class_set_parent_phases(ResettableClass *rc,
ResettableEnterPhase enter,
ResettableHoldPhase hold,
diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
index 2e3346600e..1e88cb2f6a 100644
--- a/include/hw/qdev-core.h
+++ b/include/hw/qdev-core.h
@@ -386,6 +386,13 @@ int qdev_walk_children(DeviceState *dev,
qdev_walkerfn *post_devfn, qbus_walkerfn *post_busfn,
void *opaque);
+/**
+ * @qdev_reset_all:
+ * Reset @dev. See @qbus_reset_all() for more details.
+ *
+ * Note: This function is deprecated and will be removed when it becomes
unused.
+ * Please use device_cold_reset() now.
+ */
void qdev_reset_all(DeviceState *dev);
void qdev_reset_all_fn(void *opaque);
@@ -398,10 +405,28 @@ void qdev_reset_all_fn(void *opaque);
* hard reset means that qbus_reset_all will reset all state of the device.
* For PCI devices, for example, this will include the base address registers
* or configuration space.
+ *
+ * Note: This function is deprecated and will be removed when it becomes
unused.
+ * Please use bus_cold_reset() now.
*/
void qbus_reset_all(BusState *bus);
void qbus_reset_all_fn(void *opaque);
+/**
+ * device_cold_reset:
+ * Reset device @dev and perform a recursive processing using the resettable
+ * interface. It triggers a RESET_TYPE_COLD.
+ */
+void device_cold_reset(DeviceState *dev);
+
+/**
+ * bus_cold_reset:
+ *
+ * Reset bus @bus and perform a recursive processing using the resettable
+ * interface. It triggers a RESET_TYPE_COLD.
+ */
+void bus_cold_reset(BusState *bus);
+
/**
* device_is_in_reset:
* Return true if the device @dev is currently being reset.
@@ -432,6 +457,8 @@ void qdev_machine_init(void);
*
Re: [PATCH v5 02/13] hw/core/qdev: add trace events to help with resettable transition
On 10/18/19 5:06 PM, Damien Hedde wrote:
Adds trace events to reset procedure and when updating the parent
bus of a device.
Signed-off-by: Damien Hedde
---
hw/core/qdev.c | 27 ---
hw/core/trace-events | 9 +
2 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 60be2f2fef..f230063189 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -38,6 +38,7 @@
#include "hw/boards.h"
#include "hw/sysbus.h"
#include "migration/vmstate.h"
+#include "trace.h"
bool qdev_hotplug = false;
static bool qdev_hot_added = false;
@@ -98,7 +99,9 @@ void qdev_set_parent_bus(DeviceState *dev, BusState *bus)
bool replugging = dev->parent_bus != NULL;
if (replugging) {
-/* Keep a reference to the device while it's not plugged into
+trace_qdev_update_parent_bus(dev, dev->parent_bus, bus);
Nitpicking, if you respin, can you add object_get_typename(OBJECT(dev)))
and object_get_typename(OBJECT(bus)))?
With/without it:
Reviewed-by: Philippe Mathieu-Daudé
+/*
+ * Keep a reference to the device while it's not plugged into
* any bus, to avoid it potentially evaporating when it is
* dereffed in bus_remove_child().
*/
@@ -272,6 +275,18 @@ HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev)
return hotplug_ctrl;
}
+static int qdev_prereset(DeviceState *dev, void *opaque)
+{
+trace_qdev_reset_tree(dev, object_get_typename(OBJECT(dev)));
+return 0;
+}
+
+static int qbus_prereset(BusState *bus, void *opaque)
+{
+trace_qbus_reset_tree(bus, object_get_typename(OBJECT(bus)));
+return 0;
+}
+
static int qdev_reset_one(DeviceState *dev, void *opaque)
{
device_legacy_reset(dev);
@@ -282,6 +297,7 @@ static int qdev_reset_one(DeviceState *dev, void *opaque)
static int qbus_reset_one(BusState *bus, void *opaque)
{
BusClass *bc = BUS_GET_CLASS(bus);
+trace_qbus_reset(bus, object_get_typename(OBJECT(bus)));
if (bc->reset) {
bc->reset(bus);
}
@@ -290,7 +306,9 @@ static int qbus_reset_one(BusState *bus, void *opaque)
void qdev_reset_all(DeviceState *dev)
{
-qdev_walk_children(dev, NULL, NULL, qdev_reset_one, qbus_reset_one, NULL);
+trace_qdev_reset_all(dev, object_get_typename(OBJECT(dev)));
+qdev_walk_children(dev, qdev_prereset, qbus_prereset,
+ qdev_reset_one, qbus_reset_one, NULL);
}
void qdev_reset_all_fn(void *opaque)
@@ -300,7 +318,9 @@ void qdev_reset_all_fn(void *opaque)
void qbus_reset_all(BusState *bus)
{
-qbus_walk_children(bus, NULL, NULL, qdev_reset_one, qbus_reset_one, NULL);
+trace_qbus_reset_all(bus, object_get_typename(OBJECT(bus)));
+qbus_walk_children(bus, qdev_prereset, qbus_prereset,
+ qdev_reset_one, qbus_reset_one, NULL);
}
void qbus_reset_all_fn(void *opaque)
@@ -1108,6 +1128,7 @@ void device_legacy_reset(DeviceState *dev)
{
DeviceClass *klass = DEVICE_GET_CLASS(dev);
+trace_qdev_reset(dev, object_get_typename(OBJECT(dev)));
if (klass->reset) {
klass->reset(dev);
}
diff --git a/hw/core/trace-events b/hw/core/trace-events
index fe47a9c8cb..1a669be0ea 100644
--- a/hw/core/trace-events
+++ b/hw/core/trace-events
@@ -1,2 +1,11 @@
# loader.c
loader_write_rom(const char *name, uint64_t gpa, uint64_t size, bool isrom) "%s:
@0x%"PRIx64" size=0x%"PRIx64" ROM=%d"
+
+# qdev.c
+qdev_reset(void *obj, const char *objtype) "obj=%p(%s)"
+qdev_reset_all(void *obj, const char *objtype) "obj=%p(%s)"
+qdev_reset_tree(void *obj, const char *objtype) "obj=%p(%s)"
+qbus_reset(void *obj, const char *objtype) "obj=%p(%s)"
+qbus_reset_all(void *obj, const char *objtype) "obj=%p(%s)"
+qbus_reset_tree(void *obj, const char *objtype) "obj=%p(%s)"
+qdev_update_parent_bus(void *obj, void *oldp, void *newp) "obj=%p old_parent=%p
new_parent=%p"
Re: [PULL 1/9] IDE: deprecate ide-drive
On 31/10/19 11:58, John Snow wrote:
> It's an old compatibility shim that just delegates to ide-cd or ide-hd.
> I'd like to refactor these some day, and getting rid of the super-object
> will make that easier.
>
> Either way, we don't need this.
Good idea. I will prepare a similar patch for scsi-disk, even though
technically we're already in soft freeze; it makes no sense to deprecate
only one of the two.
Paolo
> Signed-off-by: John Snow
> Reviewed-by: Thomas Huth
> Reviewed-by: Markus Armbruster
> ACKed-by: Peter Krempa
> Message-id: 20191009224303.10232-2-js...@redhat.com
> Signed-off-by: John Snow
> ---
> qemu-deprecated.texi | 5 +
> hw/ide/qdev.c | 3 +++
> tests/qemu-iotests/051.pc.out | 6 --
> 3 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
> index f727bd3932..296bfc93a3 100644
> --- a/qemu-deprecated.texi
> +++ b/qemu-deprecated.texi
> @@ -254,6 +254,11 @@ quite a bit. It will be removed without replacement
> unless some users speaks
> up at the @email{qemu-devel@@nongnu.org} mailing list with information about
> their usecases.
>
> +@subsection ide-drive (since 4.2)
> +
> +The 'ide-drive' device is deprecated. Users should use 'ide-hd' or
> +'ide-cd' as appropriate to get an IDE hard disk or CD-ROM as needed.
> +
> @section System emulator machines
>
> @subsection pc-0.12, pc-0.13, pc-0.14 and pc-0.15 (since 4.0)
> diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
> index 6fba6b62b8..3666e59721 100644
> --- a/hw/ide/qdev.c
> +++ b/hw/ide/qdev.c
> @@ -279,6 +279,9 @@ static void ide_drive_realize(IDEDevice *dev, Error
> **errp)
> {
> DriveInfo *dinfo = NULL;
>
> +warn_report("'ide-drive' is deprecated, "
> +"please use 'ide-hd' or 'ide-cd' instead");
> +
> if (dev->conf.blk) {
> dinfo = blk_legacy_dinfo(dev->conf.blk);
> }
> diff --git a/tests/qemu-iotests/051.pc.out b/tests/qemu-iotests/051.pc.out
> index 000557c7c8..34849dd172 100644
> --- a/tests/qemu-iotests/051.pc.out
> +++ b/tests/qemu-iotests/051.pc.out
> @@ -158,7 +158,8 @@ QEMU X.Y.Z monitor - type 'help' for more information
>
> Testing: -drive if=none,id=disk -device ide-drive,drive=disk
> QEMU X.Y.Z monitor - type 'help' for more information
> -(qemu) QEMU_PROG: -device ide-drive,drive=disk: Device needs media, but
> drive is empty
> +(qemu) QEMU_PROG: -device ide-drive,drive=disk: warning: 'ide-drive' is
> deprecated, please use 'ide-hd' or 'ide-cd' instead
> +QEMU_PROG: -device ide-drive,drive=disk: Device needs media, but drive is
> empty
>
> Testing: -drive if=none,id=disk -device ide-hd,drive=disk
> QEMU X.Y.Z monitor - type 'help' for more information
> @@ -228,7 +229,8 @@ QEMU X.Y.Z monitor - type 'help' for more information
>
> Testing: -drive file=TEST_DIR/t.qcow2,if=none,id=disk,readonly=on -device
> ide-drive,drive=disk
> QEMU X.Y.Z monitor - type 'help' for more information
> -(qemu) QEMU_PROG: -device ide-drive,drive=disk: Block node is read-only
> +(qemu) QEMU_PROG: -device ide-drive,drive=disk: warning: 'ide-drive' is
> deprecated, please use 'ide-hd' or 'ide-cd' instead
> +QEMU_PROG: -device ide-drive,drive=disk: Block node is read-only
>
> Testing: -drive file=TEST_DIR/t.qcow2,if=none,id=disk,readonly=on -device
> ide-hd,drive=disk
> QEMU X.Y.Z monitor - type 'help' for more information
>
logfile issue
We hit an issue when trying to change the log file from the monitor
console. The root of the issue here is that the qemu_logfile handle
is not thread safe. So when we try to close the file, we end up with
a seg fault. The full analysis is below along with some possible
solutions.
Will plan to post a patch soon, but any comments or opinions on our
proposed solution would be appreciated. Thanks.
The version of QEMU we are using is: master as of about Oct 15,
9020e9526cd08c4dc99d54dba48730de2908c970.
This is what we did to reproduce the issue.
First we enable logging and select the log file.
(qemu) log in_asm,out_asm,op
(qemu) logfile asm.out
Then we start this command in the guest. This just keeps the guest
performing operations that result in logging to be constantly
generated.
$ for i in {0..1000}; do ls -l; done
Next we switch to the monitor console and change the file.
(qemu) logfile asm_new.log
This action causes a seg fault. Please see the stack trace (below).
The code, which changes the log file unconditionally
(qemu_set_log_filename()), closes the qemu_logfile, sets it to NULL,
and then opens the new file.
Since the file handle is still in use, we end up with a seg fault when
the code which is trying to log ends up using a NULL file handle.
We are considering a few solutions.
A straightforward solution would be to simply prevent the file from
being changed while logging is enabled. In other words, force the
user to first disable logging before changing the log file.
This solution seems to cover the general case. However, if a user
were to disable logging and change the log file in quick succession,
we would still be subject to a similar race. A log call could still
make it through the logging enable check and proceed to use a file
handle that gets changed to NULL.
Another option is to add a mutex to prevent the qemu_logfile handle
from being changed while it is in use. This certainly works and has
the advantage of being fairly straightforward. Also we are thinking
that since the mutex would only be used when logging is enabled it has
the advantage of not having an effect on the normal case performance.
Another option is to implement a simple atomic ref count and prevent
the file from being changed while there are outstanding references.
We are leaning towards the mutex option, and plan to post a patch
soon, but would appreciate comments or opinions on this solution.
Thanks,
Rob Foley
stack trace
==
Thread 10 "qemu-system-aar" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x113f9d90 (LWP 9493)] __flockfile
(stream=0x0) at ../sysdeps/pthread/flockfile.c:27
27 ../sysdeps/pthread/flockfile.c: No such file or directory.
(gdb) bt
#0 __flockfile (stream=0x0) at ../sysdeps/pthread/flockfile.c:27
#1 0xe0fac8b8 in qemu_flockfile (f=) at
/home/rob/qemu/qemu_unchanged/include/sysemu/os-posix.h:87
#2 qemu_log_lock () at /home/rob/qemu/qemu_unchanged/include/qemu/log.h:57
#3 translator_loop (ops=0xe17f1348 ,
db=0x113f9088, db@entry=0x113f9098,
cpu=cpu@entry=0xaaab0a52bc50,
tb=tb@entry=0x4c92d000 ,
max_insns=max_insns@entry=512) at
/home/rob/qemu/qemu_unchanged/accel/tcg/translator.c:121
#4 0xe10c1c18 in gen_intermediate_code
(cpu=cpu@entry=0xaaab0a52bc50, tb=tb@entry=0x4c92d000
, max_insns=max_insns@entry=512)
at /home/rob/qemu/qemu_unchanged/target/arm/translate.c:11320
#5 0xe0fab248 in tb_gen_code (cpu=0xaaab0a52bc50,
cpu@entry=0xabe2a000, pc=187650897458448, cs_base=65536,
flags=43690, cflags=-16252928, cflags@entry=524288)
at /home/rob/qemu/qemu_unchanged/accel/tcg/translate-all.c:1738
#6 0xe0fa8e74 in tb_find (cf_mask=524288, tb_exit=0,
last_tb=0x4c92cc40 ,
cpu=0xabe2a000)
at /home/rob/qemu/qemu_unchanged/accel/tcg/cpu-exec.c:408
#7 cpu_exec (cpu=0xabe2a000, cpu@entry=0xaaab0a52bc50) at
/home/rob/qemu/qemu_unchanged/accel/tcg/cpu-exec.c:730
#8 0xe0f6de24 in tcg_cpu_exec (cpu=0xaaab0a52bc50) at
/home/rob/qemu/qemu_unchanged/cpus.c:1454
#9 0xe0f70908 in qemu_tcg_cpu_thread_fn (arg=0xaaab0a52bc50)
at /home/rob/qemu/qemu_unchanged/cpus.c:1762
#10 0xe145bd38 in qemu_thread_start (args=) at
/home/rob/qemu/qemu_unchanged/util/qemu-thread-posix.c:519
#11 0xabe0a088 in start_thread (arg=0xcc20410f) at
pthread_create.c:463
#12 0xabd7a4ec in thread_start () at
../sysdeps/unix/sysv/linux/aarch64/clone.S:78
Re: Missing PVR setting capability
So it's been a little while and I've been trying some different approaches. I think the problem I am having is because I don't have the required kernel modules loaded. When I run lsmod I only see the following two modules loaded: Module Size Used by nfsd 100940 11 exportfs6723 1 nfsd The archlinux website says the following modules need to be running: kvm_intel 245760 0 kvmgt 28672 0 mdev 20480 2 kvmgt,vfio_mdev vfio 32768 3 kvmgt,vfio_mdev,vfio_iommu_type1 kvm 737280 2 kvmgt,kvm_intel irqbypass 16384 1 kvm Granted that I am running on a powerpc processor not an intel processor, the modules that I myself to need to load will be a little different from that. But I can't find those modules to load on my device. For example, I can't find a kvm.ko file on the device despite the fact that I was able to find the kvm directories I mentioned earlier. Did I have to compile those modules myself? In the kvm module directory there is C code and a makefile, but just running make doesn't work. Note that I'm using a Yocto Linux system that I myself didn't build. My coworker built the Linux system on SD card and was in the process of trying to figure out if kvm was actually enabled on the system or not before he left the company. I'm learning about the system as I go. On Tue, Oct 22, 2019 at 1:46 PM Thomas Huth wrote: > On 22/10/2019 18.24, Wayne Li wrote: > > If I run "lsmod | grep kvm" nothing shows up but if I just do a "find . > > -name "kvm"" I get the following: > [...] > > ./sys/devices/virtual/misc/kvm > > ./sys/class/misc/kvm > > ./sys/kernel/debug/kvm > > ./sys/module/kvm > > > > I guess this shows my OS does have KVM on it? > > Alright, I guess that means that KVM compiled into the kernel ... should > be fine, I think. > > > I added the two flags you > > mentioned when running QEMU (the -cpu and the -machine flags) but the > > -cpu flag doesn't seem like it's doing anything as even when I put a > > clearly wrong argument after the flag no error related to the cpu is > > thrown. Also it says ppce500 is not a machine type and that the > > supported machines are: > > > > bamboo bamboo > > boeing-machine Boeing Machine > > none empty machine > > ref405ep ref405ep > > taihutaihu > > virtex-ml507 Xilinx Virtex ML507 reference design > > Oh, are you running qemu-system-ppc instead of qemu-system-ppc64? I > thought these e*500 CPUs are 64-bit? Is your host kernel 64-bit or 32-bit? > > Anyway, if you're using a modified version of QEMU, you should > definitely ask the people who did the modifications there. > > Thomas > >
[Bug 1850570] Re: Cannot use usb-host on Mac OS
Yes, I tried running as root. I also tried it on a different computer that is running Mac OS 10.13, and it gave the same errors. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1850570 Title: Cannot use usb-host on Mac OS Status in QEMU: New Bug description: Usb-host will not work on Mac OS 10.15. Qemu runs, though it gives these errors and the drive does not show up. Also, when Qemu is starting the drive ejects and remounts twice. Qemu built with ./configure --target-list=i386-softmmu,x86_64-softmmu --enable-sdl --disable-cocoa --enable-sdl-image. qemu-system-i386 image.qcow -usb -device usb-kbd -device usb-host,vendorid=0x0781,productid=0x5571 libusb: error [darwin_claim_interface] USBInterfaceOpen: another process has device opened for exclusive access libusb: error [darwin_claim_interface] interface not found libusb: error [darwin_claim_interface] interface not found libusb: error [darwin_claim_interface] interface not found libusb: error [darwin_claim_interface] interface not found libusb: error [darwin_claim_interface] interface not found libusb: error [darwin_claim_interface] interface not found libusb: error [darwin_claim_interface] interface not found libusb: error [darwin_claim_interface] interface not found libusb: error [darwin_claim_interface] interface not found libusb: error [darwin_claim_interface] interface not found libusb: error [darwin_claim_interface] interface not found libusb: error [darwin_claim_interface] interface not found libusb: error [darwin_claim_interface] interface not found libusb: error [darwin_claim_interface] interface not found libusb: error [darwin_claim_interface] interface not found libusb: error [darwin_claim_interface] USBInterfaceOpen: another process has device opened for exclusive access libusb: error [darwin_claim_interface] interface not found libusb: error [darwin_claim_interface] interface not found libusb: error [darwin_claim_interface] interface not found libusb: error [darwin_claim_interface] interface not found libusb: error [darwin_claim_interface] interface not found libusb: error [darwin_claim_interface] interface not found libusb: error [darwin_claim_interface] interface not found libusb: error [darwin_claim_interface] interface not found libusb: error [darwin_claim_interface] interface not found libusb: error [darwin_claim_interface] interface not found libusb: error [darwin_claim_interface] interface not found libusb: error [darwin_claim_interface] interface not found libusb: error [darwin_claim_interface] interface not found libusb: error [darwin_claim_interface] interface not found libusb: error [darwin_claim_interface] interface not found To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1850570/+subscriptions
Re: [PATCH v1 1/1] hw/arm/boot: Rebuild hflags when modifying CPUState at boot
On 10/31/19 5:08 AM, Edgar E. Iglesias wrote: > Rebuild hflags when modifying CPUState at boot. > > Fixes: e979972a6a > Signed-off-by: Edgar E. Iglesias Reviewed-by: Luc Michel > --- > hw/arm/boot.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/hw/arm/boot.c b/hw/arm/boot.c > index c264864c11..ef6724960c 100644 > --- a/hw/arm/boot.c > +++ b/hw/arm/boot.c > @@ -786,6 +786,7 @@ static void do_cpu_reset(void *opaque) > info->secondary_cpu_reset_hook(cpu, info); > } > } > +arm_rebuild_hflags(env); > } > } > >
Re: [PATCH 1/1] qga: Add "guest-get-memory-block-info" to blacklist
On Thu, Oct 17, 2019 at 2:35 PM Basil Salman wrote:
>
> From: Basil Salman
>
> Memory block commands are only supported for linux with sysfs,
> "guest-get-memory-block-info" was not in blacklist for other
> cases.
>
> Reported on:
> https://bugzilla.redhat.com/show_bug.cgi?id=1751431
>
> Signed-off-by: Basil Salman
Reviewed-by: Marc-André Lureau
> ---
> qga/commands-posix.c | 3 ++-
> qga/commands-win32.c | 2 +-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/qga/commands-posix.c b/qga/commands-posix.c
> index dfc05f5b8a..1c1a165dae 100644
> --- a/qga/commands-posix.c
> +++ b/qga/commands-posix.c
> @@ -2730,7 +2730,8 @@ GList *ga_command_blacklist_init(GList *blacklist)
> "guest-suspend-hybrid", "guest-network-get-interfaces",
> "guest-get-vcpus", "guest-set-vcpus",
> "guest-get-memory-blocks", "guest-set-memory-blocks",
> -"guest-get-memory-block-size", NULL};
> +"guest-get-memory-block-size", "guest-get-memory-block-info",
> +NULL};
> char **p = (char **)list;
>
> while (*p) {
> diff --git a/qga/commands-win32.c b/qga/commands-win32.c
> index 6b67f16faf..1c9ec9c094 100644
> --- a/qga/commands-win32.c
> +++ b/qga/commands-win32.c
> @@ -1894,7 +1894,7 @@ GList *ga_command_blacklist_init(GList *blacklist)
> "guest-suspend-hybrid",
> "guest-set-vcpus",
> "guest-get-memory-blocks", "guest-set-memory-blocks",
> -"guest-get-memory-block-size",
> +"guest-get-memory-block-size", "guest-get-memory-block-info",
> NULL};
> char **p = (char **)list_unsupported;
>
> --
> 2.17.2
>
>
--
Marc-André Lureau
[KVM Forum] Upstreaming device fuzzing discussion Fri 1 Nov 2019
Hi, Following Dima's presentation on virtio device fuzzing[1] and Alexander's "[PATCH v4 00/20] Add virtual device fuzzing support"[2] series on the mailing list, it's time discuss the roadmap for QEMU device fuzzing in qemu.git. We will meet at 13:45 CET on Fri 1st of November in the Forum 1/2/3 Foyer with a video conference connection for anyone not attending KVM Forum (https://bluejeans.com/6063766077). Anyone who currently has a private device fuzzing setup and is interested in seeing fuzzing infrastructure upstream in QEMU is welcome to participate. This session is not (primarily) about how to fuzz specific devices, so it won't be relevant if you want to start device fuzzing and do not have prior experience. Stefan [1] https://static.sched.com/hosted_files/kvmforum2019/76/kvmforum2019_virtio_device_fuzzing.pdf). [2] https://patchew.org/QEMU/20191030144926.11873-1-alx...@bu.edu/
Re: [PULL v2 0/9] Ide patches
On Thu, 31 Oct 2019 at 15:57, John Snow wrote: > > The following changes since commit 68d8ef4ec540682c3538d4963e836e43a211dd17: > > Merge remote-tracking branch > 'remotes/stsquad/tags/pull-tcg-plugins-281019-4' into staging (2019-10-30 > 14:10:32 +) > > are available in the Git repository at: > > https://github.com/jnsnow/qemu.git tags/ide-pull-request > > for you to fetch changes up to dc237c45aee52f268369dc6a485c623f1232e1d3: > > hd-geo-test: Add tests for lchs override (2019-10-31 11:47:43 -0400) > > > Pull request > > Applied, thanks. Please update the changelog at https://wiki.qemu.org/ChangeLog/4.2 for any user-visible changes. -- PMM
Re: [libvirt] [PULL v2 0/9] Ide patches
Patchew URL: https://patchew.org/QEMU/20191031155636.18589-1-js...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [libvirt] [PULL v2 0/9] Ide patches
Type: series
Message-id: 20191031155636.18589-1-js...@redhat.com
=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===
Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
514c990 hd-geo-test: Add tests for lchs override
417c06b bootdevice: FW_CFG interface for LCHS values
95cff25 bootdevice: Refactor get_boot_devices_list
8338ac4 bootdevice: Gather LCHS from all relevant devices
74e4c54 scsi: Propagate unrealize() callback to scsi-hd
89e99d5 bootdevice: Add interface to gather LCHS
38a1f79 block: Support providing LCHS from user
fdb21cf block: Refactor macros - fix tabbing
a72c719 IDE: deprecate ide-drive
=== OUTPUT BEGIN ===
1/9 Checking commit a72c71949c97 (IDE: deprecate ide-drive)
2/9 Checking commit fdb21cf1b99a (block: Refactor macros - fix tabbing)
ERROR: Macros with complex values should be enclosed in parenthesis
#58: FILE: include/hw/block/block.h:65:
+#define DEFINE_BLOCK_CHS_PROPERTIES(_state, _conf) \
+DEFINE_PROP_UINT32("cyls", _state, _conf.cyls, 0), \
+DEFINE_PROP_UINT32("heads", _state, _conf.heads, 0),\
DEFINE_PROP_UINT32("secs", _state, _conf.secs, 0)
total: 1 errors, 0 warnings, 37 lines checked
Patch 2/9 has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
3/9 Checking commit 38a1f79b0263 (block: Support providing LCHS from user)
4/9 Checking commit 89e99d5e95db (bootdevice: Add interface to gather LCHS)
5/9 Checking commit 74e4c54110a3 (scsi: Propagate unrealize() callback to
scsi-hd)
6/9 Checking commit 8338ac4726f1 (bootdevice: Gather LCHS from all relevant
devices)
7/9 Checking commit 95cff25ddcc7 (bootdevice: Refactor get_boot_devices_list)
8/9 Checking commit 417c06b79277 (bootdevice: FW_CFG interface for LCHS values)
9/9 Checking commit 514c99024108 (hd-geo-test: Add tests for lchs override)
WARNING: Block comments use a leading /* on a separate line
#607: FILE: tests/hd-geo-test.c:965:
+ "skipping hd-geo/override/* tests");
total: 0 errors, 1 warnings, 578 lines checked
Patch 9/9 has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
=== OUTPUT END ===
Test command exited with code: 1
The full log is available at
http://patchew.org/logs/20191031155636.18589-1-js...@redhat.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com
[PULL v2 9/9] hd-geo-test: Add tests for lchs override
From: Sam Eiderman
Add QTest tests to check the logical geometry override option.
The tests in hd-geo-test are out of date - they only test IDE and do not
test interesting MBRs.
Creating qcow2 disks with specific size and MBR layout is currently
unused - we only use a default empty MBR.
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Signed-off-by: Sam Eiderman
Signed-off-by: Sam Eiderman
Signed-off-by: John Snow
---
tests/hd-geo-test.c| 551 +
tests/Makefile.include | 2 +-
2 files changed, 552 insertions(+), 1 deletion(-)
diff --git a/tests/hd-geo-test.c b/tests/hd-geo-test.c
index 62eb624726..7e86c5416c 100644
--- a/tests/hd-geo-test.c
+++ b/tests/hd-geo-test.c
@@ -17,7 +17,12 @@
#include "qemu/osdep.h"
#include "qemu-common.h"
+#include "qemu/bswap.h"
+#include "qapi/qmp/qlist.h"
#include "libqtest.h"
+#include "libqos/fw_cfg.h"
+#include "libqos/libqos.h"
+#include "standard-headers/linux/qemu_fw_cfg.h"
#define ARGV_SIZE 256
@@ -388,6 +393,537 @@ static void test_ide_drive_cd_0(void)
qtest_quit(qts);
}
+typedef struct {
+bool active;
+uint32_t head;
+uint32_t sector;
+uint32_t cyl;
+uint32_t end_head;
+uint32_t end_sector;
+uint32_t end_cyl;
+uint32_t start_sect;
+uint32_t nr_sects;
+} MBRpartitions[4];
+
+static MBRpartitions empty_mbr = { {false, 0, 0, 0, 0, 0, 0, 0, 0},
+ {false, 0, 0, 0, 0, 0, 0, 0, 0},
+ {false, 0, 0, 0, 0, 0, 0, 0, 0},
+ {false, 0, 0, 0, 0, 0, 0, 0, 0} };
+
+static char *create_qcow2_with_mbr(MBRpartitions mbr, uint64_t sectors)
+{
+const char *template = "/tmp/qtest.XX";
+char *raw_path = strdup(template);
+char *qcow2_path = strdup(template);
+char cmd[100 + 2 * PATH_MAX];
+uint8_t buf[512];
+int i, ret, fd, offset;
+uint64_t qcow2_size = sectors * 512;
+uint8_t status, parttype, head, sector, cyl;
+char *qemu_img_path;
+char *qemu_img_abs_path;
+
+offset = 0xbe;
+
+for (i = 0; i < 4; i++) {
+status = mbr[i].active ? 0x80 : 0x00;
+g_assert(mbr[i].head < 256);
+g_assert(mbr[i].sector < 64);
+g_assert(mbr[i].cyl < 1024);
+head = mbr[i].head;
+sector = mbr[i].sector + ((mbr[i].cyl & 0x300) >> 2);
+cyl = mbr[i].cyl & 0xff;
+
+buf[offset + 0x0] = status;
+buf[offset + 0x1] = head;
+buf[offset + 0x2] = sector;
+buf[offset + 0x3] = cyl;
+
+parttype = 0;
+g_assert(mbr[i].end_head < 256);
+g_assert(mbr[i].end_sector < 64);
+g_assert(mbr[i].end_cyl < 1024);
+head = mbr[i].end_head;
+sector = mbr[i].end_sector + ((mbr[i].end_cyl & 0x300) >> 2);
+cyl = mbr[i].end_cyl & 0xff;
+
+buf[offset + 0x4] = parttype;
+buf[offset + 0x5] = head;
+buf[offset + 0x6] = sector;
+buf[offset + 0x7] = cyl;
+
+(*(uint32_t *)[offset + 0x8]) = cpu_to_le32(mbr[i].start_sect);
+(*(uint32_t *)[offset + 0xc]) = cpu_to_le32(mbr[i].nr_sects);
+
+offset += 0x10;
+}
+
+fd = mkstemp(raw_path);
+g_assert(fd);
+close(fd);
+
+fd = open(raw_path, O_WRONLY);
+g_assert(fd >= 0);
+ret = write(fd, buf, sizeof(buf));
+g_assert(ret == sizeof(buf));
+close(fd);
+
+fd = mkstemp(qcow2_path);
+g_assert(fd);
+close(fd);
+
+qemu_img_path = getenv("QTEST_QEMU_IMG");
+g_assert(qemu_img_path);
+qemu_img_abs_path = realpath(qemu_img_path, NULL);
+g_assert(qemu_img_abs_path);
+
+ret = snprintf(cmd, sizeof(cmd),
+ "%s convert -f raw -O qcow2 %s %s > /dev/null",
+ qemu_img_abs_path,
+ raw_path, qcow2_path);
+g_assert((0 < ret) && (ret <= sizeof(cmd)));
+ret = system(cmd);
+g_assert(ret == 0);
+
+ret = snprintf(cmd, sizeof(cmd),
+ "%s resize %s %" PRIu64 " > /dev/null",
+ qemu_img_abs_path,
+ qcow2_path, qcow2_size);
+g_assert((0 < ret) && (ret <= sizeof(cmd)));
+ret = system(cmd);
+g_assert(ret == 0);
+
+free(qemu_img_abs_path);
+
+unlink(raw_path);
+free(raw_path);
+
+return qcow2_path;
+}
+
+#define BIOS_GEOMETRY_MAX_SIZE 1
+
+typedef struct {
+uint32_t c;
+uint32_t h;
+uint32_t s;
+} CHS;
+
+typedef struct {
+const char *dev_path;
+CHS chs;
+} CHSResult;
+
+static void read_bootdevices(QFWCFG *fw_cfg, CHSResult expected[])
+{
+char *buf = g_malloc0(BIOS_GEOMETRY_MAX_SIZE);
+char *cur;
+GList *results = NULL, *cur_result;
+CHSResult *r;
+int i;
+int res;
+bool found;
+
+qfw_cfg_get_file(fw_cfg, "bios-geometry", buf, BIOS_GEOMETRY_MAX_SIZE);
+
+for (cur = buf; *cur; cur++) {
+if (*cur == '\n') {
+*cur = '\0';
+}
+}
+cur = buf;
+
+while (strlen(cur)) {
+
+r =
[PULL v2 7/9] bootdevice: Refactor get_boot_devices_list
From: Sam Eiderman
Move device name construction to a separate function.
We will reuse this function in the following commit to pass logical CHS
parameters through fw_cfg much like we currently pass bootindex.
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Sam Eiderman
Signed-off-by: Sam Eiderman
Tested-by: Philippe Mathieu-Daudé
Signed-off-by: John Snow
---
bootdevice.c | 61 +---
1 file changed, 34 insertions(+), 27 deletions(-)
diff --git a/bootdevice.c b/bootdevice.c
index bc5e1c2de4..2cf6b37c57 100644
--- a/bootdevice.c
+++ b/bootdevice.c
@@ -202,6 +202,39 @@ DeviceState *get_boot_device(uint32_t position)
return res;
}
+static char *get_boot_device_path(DeviceState *dev, bool ignore_suffixes,
+ const char *suffix)
+{
+char *devpath = NULL, *s = NULL, *d, *bootpath;
+
+if (dev) {
+devpath = qdev_get_fw_dev_path(dev);
+assert(devpath);
+}
+
+if (!ignore_suffixes) {
+if (dev) {
+d = qdev_get_own_fw_dev_path_from_handler(dev->parent_bus, dev);
+if (d) {
+assert(!suffix);
+s = d;
+} else {
+s = g_strdup(suffix);
+}
+} else {
+s = g_strdup(suffix);
+}
+}
+
+bootpath = g_strdup_printf("%s%s",
+ devpath ? devpath : "",
+ s ? s : "");
+g_free(devpath);
+g_free(s);
+
+return bootpath;
+}
+
/*
* This function returns null terminated string that consist of new line
* separated device paths.
@@ -218,36 +251,10 @@ char *get_boot_devices_list(size_t *size)
bool ignore_suffixes = mc->ignore_boot_device_suffixes;
QTAILQ_FOREACH(i, _boot_order, link) {
-char *devpath = NULL, *suffix = NULL;
char *bootpath;
-char *d;
size_t len;
-if (i->dev) {
-devpath = qdev_get_fw_dev_path(i->dev);
-assert(devpath);
-}
-
-if (!ignore_suffixes) {
-if (i->dev) {
-d = qdev_get_own_fw_dev_path_from_handler(i->dev->parent_bus,
- i->dev);
-if (d) {
-assert(!i->suffix);
-suffix = d;
-} else {
-suffix = g_strdup(i->suffix);
-}
-} else {
-suffix = g_strdup(i->suffix);
-}
-}
-
-bootpath = g_strdup_printf("%s%s",
- devpath ? devpath : "",
- suffix ? suffix : "");
-g_free(devpath);
-g_free(suffix);
+bootpath = get_boot_device_path(i->dev, ignore_suffixes, i->suffix);
if (total) {
list[total-1] = '\n';
--
2.21.0
Re: [PATCH v2] smb daemon get additional command line parameters from env variable
Hello,
Jordi Pujol, le jeu. 31 oct. 2019 14:33:00 +0100, a ecrit:
> The smbd daemon takes additional command line options
> from environment variable SMBDOPTIONS.
> Set the environment variable SMBDOPTIONS before executing qemu.
>
> Example:
>
> export SMBDOPTIONS="--option='server min protocol=CORE' -d 4"
>
> Signed-off-by: Jordi Pujol Palomer
> ---
> --- qemu-4.1-a/net/slirp.c
> +++ qemu_4.1-b/net/slirp.c
> @@ -909,6 +909,12 @@ static int slirp_smb(SlirpState* s, cons
> CONFIG_SMBD_COMMAND, s->smb_dir, smb_conf);
> g_free(smb_conf);
>
> +char *options = g_strdup(g_getenv("SMBDOPTIONS"));
Why strduping it? you can just use g_getenv.
> +if (options) {
> +smb_cmdline = g_strdup_printf("%s %s", smb_cmdline, options);
> +}
> +g_free(options);
> +
> if (slirp_add_exec(s->slirp, smb_cmdline, _addr, 139) < 0 ||
> slirp_add_exec(s->slirp, smb_cmdline, _addr, 445) < 0) {
> slirp_smb_cleanup(s);
>
> --- qemu-4.1-a/slirp/src/misc.c 2019-10-29 14:40:15.043120941 +0100
> +++ qemu-4.1-b/slirp/src/misc.c 2019-10-29 14:41:04.440235684 +0100
Please submit this part to https://gitlab.freedesktop.org/slirp/libslirp/
Make sure to note in the changelog that g_shell_parse_argv does only
tokenization, and no replacement.
Samuel
> @@ -168,7 +168,9 @@ g_spawn_async_with_fds_slirp(const gchar
> int fork_exec(struct socket *so, const char *ex)
> {
> GError *err = NULL;
> -char **argv;
> +gint argc = 0;
> +gchar **argv = NULL;
> +gboolean ret;
> int opt, sp[2];
>
> DEBUG_CALL("fork_exec");
> @@ -179,7 +181,13 @@ int fork_exec(struct socket *so, const c
> return 0;
> }
>
> -argv = g_strsplit(ex, " ", -1);
> +ret = g_shell_parse_argv(ex, , , );
> +if (err) {
> +g_critical("fork_exec invalid command: %s", err->message);
> +g_error_free(err);
> +return 0;
> +}
> +
> g_spawn_async_with_fds(NULL /* cwd */, argv, NULL /* env */,
> G_SPAWN_SEARCH_PATH, fork_exec_child_setup,
> NULL /* data */, NULL /* child_pid */, sp[1],
> sp[1],
> **
>
> Thanks,
>
> Jordi Pujol
>
[PULL v2 4/9] bootdevice: Add interface to gather LCHS
From: Sam Eiderman
Add an interface to provide direct logical CHS values for boot devices.
We will use this interface in the next commits.
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Signed-off-by: Sam Eiderman
Signed-off-by: Sam Eiderman
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Signed-off-by: John Snow
---
include/sysemu/sysemu.h | 3 +++
bootdevice.c| 55 +
2 files changed, 58 insertions(+)
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 44f18eb739..5bc5c79cbc 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -103,6 +103,9 @@ void device_add_bootindex_property(Object *obj, int32_t
*bootindex,
DeviceState *dev, Error **errp);
void restore_boot_order(void *opaque);
void validate_bootdevices(const char *devices, Error **errp);
+void add_boot_device_lchs(DeviceState *dev, const char *suffix,
+ uint32_t lcyls, uint32_t lheads, uint32_t lsecs);
+void del_boot_device_lchs(DeviceState *dev, const char *suffix);
/* handler to set the boot_device order for a specific type of MachineClass */
typedef void QEMUBootSetHandler(void *opaque, const char *boot_order,
diff --git a/bootdevice.c b/bootdevice.c
index 1d225202f9..bc5e1c2de4 100644
--- a/bootdevice.c
+++ b/bootdevice.c
@@ -343,3 +343,58 @@ void device_add_bootindex_property(Object *obj, int32_t
*bootindex,
/* initialize devices' bootindex property to -1 */
object_property_set_int(obj, -1, name, NULL);
}
+
+typedef struct FWLCHSEntry FWLCHSEntry;
+
+struct FWLCHSEntry {
+QTAILQ_ENTRY(FWLCHSEntry) link;
+DeviceState *dev;
+char *suffix;
+uint32_t lcyls;
+uint32_t lheads;
+uint32_t lsecs;
+};
+
+static QTAILQ_HEAD(, FWLCHSEntry) fw_lchs =
+QTAILQ_HEAD_INITIALIZER(fw_lchs);
+
+void add_boot_device_lchs(DeviceState *dev, const char *suffix,
+ uint32_t lcyls, uint32_t lheads, uint32_t lsecs)
+{
+FWLCHSEntry *node;
+
+if (!lcyls && !lheads && !lsecs) {
+return;
+}
+
+assert(dev != NULL || suffix != NULL);
+
+node = g_malloc0(sizeof(FWLCHSEntry));
+node->suffix = g_strdup(suffix);
+node->dev = dev;
+node->lcyls = lcyls;
+node->lheads = lheads;
+node->lsecs = lsecs;
+
+QTAILQ_INSERT_TAIL(_lchs, node, link);
+}
+
+void del_boot_device_lchs(DeviceState *dev, const char *suffix)
+{
+FWLCHSEntry *i;
+
+if (dev == NULL) {
+return;
+}
+
+QTAILQ_FOREACH(i, _lchs, link) {
+if ((!suffix || !g_strcmp0(i->suffix, suffix)) &&
+ i->dev == dev) {
+QTAILQ_REMOVE(_lchs, i, link);
+g_free(i->suffix);
+g_free(i);
+
+break;
+}
+}
+}
--
2.21.0
Re: [Bug 1850570] [NEW] Cannot use usb-host on Mac OS
> > Message: 9 > Date: Wed, 30 Oct 2019 01:46:54 - > From: John Canada <1850...@bugs.launchpad.net> > To: qemu-devel@nongnu.org > Subject: [Bug 1850570] [NEW] Cannot use usb-host on Mac OS > Message-ID: > < > 157240001496.28481.10507378472210680134.malone...@chaenomeles.canonical.com > > > > Content-Type: text/plain; charset="utf-8" > > Public bug reported: > > Usb-host will not work on Mac OS 10.15. Qemu runs, though it gives > these errors and the drive does not show up. Also, when Qemu is > starting the drive ejects and remounts twice. Qemu built with > ./configure --target-list=i386-softmmu,x86_64-softmmu --enable-sdl > --disable-cocoa --enable-sdl-image. > > qemu-system-i386 image.qcow -usb -device usb-kbd -device > usb-host,vendorid=0x0781,productid=0x5571 > libusb: error [darwin_claim_interface] USBInterfaceOpen: another process > has device opened for exclusive access > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] USBInterfaceOpen: another process > has device opened for exclusive access > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > > ** 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/1850570 > > Title: > Cannot use usb-host on Mac OS > > Status in QEMU: > New > > Bug description: > Usb-host will not work on Mac OS 10.15. Qemu runs, though it gives > these errors and the drive does not show up. Also, when Qemu is > starting the drive ejects and remounts twice. Qemu built with > ./configure --target-list=i386-softmmu,x86_64-softmmu --enable-sdl > --disable-cocoa --enable-sdl-image. > > qemu-system-i386 image.qcow -usb -device usb-kbd -device > usb-host,vendorid=0x0781,productid=0x5571 > libusb: error [darwin_claim_interface] USBInterfaceOpen: another process > has device opened for exclusive access > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] USBInterfaceOpen: another process > has device opened for exclusive access > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error [darwin_claim_interface] interface not found > libusb: error
[PULL v2 3/9] block: Support providing LCHS from user
From: Sam Eiderman
Add logical geometry variables to BlockConf.
A user can now supply "lcyls", "lheads" & "lsecs" for any HD device
that supports CHS ("cyls", "heads", "secs").
These devices include:
* ide-hd
* scsi-hd
* virtio-blk-pci
In future commits we will use the provided LCHS and pass it to the BIOS
through fw_cfg to be supplied using INT13 routines.
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Signed-off-by: Sam Eiderman
Signed-off-by: Sam Eiderman
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Signed-off-by: John Snow
---
include/hw/block/block.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/include/hw/block/block.h b/include/hw/block/block.h
index fd55a30bca..d7246f3862 100644
--- a/include/hw/block/block.h
+++ b/include/hw/block/block.h
@@ -26,6 +26,7 @@ typedef struct BlockConf {
uint32_t discard_granularity;
/* geometry, not all devices use this */
uint32_t cyls, heads, secs;
+uint32_t lcyls, lheads, lsecs;
OnOffAuto wce;
bool share_rw;
BlockdevOnError rerror;
@@ -65,7 +66,10 @@ static inline unsigned int get_physical_block_exp(BlockConf
*conf)
#define DEFINE_BLOCK_CHS_PROPERTIES(_state, _conf) \
DEFINE_PROP_UINT32("cyls", _state, _conf.cyls, 0), \
DEFINE_PROP_UINT32("heads", _state, _conf.heads, 0),\
-DEFINE_PROP_UINT32("secs", _state, _conf.secs, 0)
+DEFINE_PROP_UINT32("secs", _state, _conf.secs, 0), \
+DEFINE_PROP_UINT32("lcyls", _state, _conf.lcyls, 0),\
+DEFINE_PROP_UINT32("lheads", _state, _conf.lheads, 0), \
+DEFINE_PROP_UINT32("lsecs", _state, _conf.lsecs, 0)
#define DEFINE_BLOCK_ERROR_PROPERTIES(_state, _conf)\
DEFINE_PROP_BLOCKDEV_ON_ERROR("rerror", _state, _conf.rerror, \
--
2.21.0
[PULL v2 8/9] bootdevice: FW_CFG interface for LCHS values
From: Sam Eiderman
Using fw_cfg, supply logical CHS values directly from QEMU to the BIOS.
Non-standard logical geometries break under QEMU.
A virtual disk which contains an operating system which depends on
logical geometries (consistent values being reported from BIOS INT13
AH=08) will most likely break under QEMU/SeaBIOS if it has non-standard
logical geometries - for example 56 SPT (sectors per track).
No matter what QEMU will report - SeaBIOS, for large enough disks - will
use LBA translation, which will report 63 SPT instead.
In addition we cannot force SeaBIOS to rely on physical geometries at
all. A virtio-blk-pci virtual disk with 255 phyiscal heads cannot
report more than 16 physical heads when moved to an IDE controller,
since the ATA spec allows a maximum of 16 heads - this is an artifact of
virtualization.
By supplying the logical geometries directly we are able to support such
"exotic" disks.
We serialize this information in a similar way to the "bootorder"
interface.
The new fw_cfg entry is "bios-geometry".
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Sam Eiderman
Signed-off-by: Sam Eiderman
Tested-by: Philippe Mathieu-Daudé
Signed-off-by: John Snow
---
include/sysemu/sysemu.h | 1 +
bootdevice.c| 31 +++
hw/nvram/fw_cfg.c | 14 +++---
3 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 5bc5c79cbc..80c57fdc4e 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -106,6 +106,7 @@ void validate_bootdevices(const char *devices, Error
**errp);
void add_boot_device_lchs(DeviceState *dev, const char *suffix,
uint32_t lcyls, uint32_t lheads, uint32_t lsecs);
void del_boot_device_lchs(DeviceState *dev, const char *suffix);
+char *get_boot_devices_lchs_list(size_t *size);
/* handler to set the boot_device order for a specific type of MachineClass */
typedef void QEMUBootSetHandler(void *opaque, const char *boot_order,
diff --git a/bootdevice.c b/bootdevice.c
index 2cf6b37c57..03aaffcc8d 100644
--- a/bootdevice.c
+++ b/bootdevice.c
@@ -405,3 +405,34 @@ void del_boot_device_lchs(DeviceState *dev, const char
*suffix)
}
}
}
+
+char *get_boot_devices_lchs_list(size_t *size)
+{
+FWLCHSEntry *i;
+size_t total = 0;
+char *list = NULL;
+
+QTAILQ_FOREACH(i, _lchs, link) {
+char *bootpath;
+char *chs_string;
+size_t len;
+
+bootpath = get_boot_device_path(i->dev, false, i->suffix);
+chs_string = g_strdup_printf("%s %" PRIu32 " %" PRIu32 " %" PRIu32,
+ bootpath, i->lcyls, i->lheads, i->lsecs);
+
+if (total) {
+list[total - 1] = '\n';
+}
+len = strlen(chs_string) + 1;
+list = g_realloc(list, total + len);
+memcpy([total], chs_string, len);
+total += len;
+g_free(chs_string);
+g_free(bootpath);
+}
+
+*size = total;
+
+return list;
+}
diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index aef1727250..44a3c19326 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -949,13 +949,21 @@ void *fw_cfg_modify_file(FWCfgState *s, const char
*filename,
static void fw_cfg_machine_reset(void *opaque)
{
+MachineClass *mc = MACHINE_GET_CLASS(qdev_get_machine());
+FWCfgState *s = opaque;
void *ptr;
size_t len;
-FWCfgState *s = opaque;
-char *bootindex = get_boot_devices_list();
+char *buf;
-ptr = fw_cfg_modify_file(s, "bootorder", (uint8_t *)bootindex, len);
+buf = get_boot_devices_list();
+ptr = fw_cfg_modify_file(s, "bootorder", (uint8_t *)buf, len);
g_free(ptr);
+
+if (!mc->legacy_fw_cfg_order) {
+buf = get_boot_devices_lchs_list();
+ptr = fw_cfg_modify_file(s, "bios-geometry", (uint8_t *)buf, len);
+g_free(ptr);
+}
}
static void fw_cfg_machine_ready(struct Notifier *n, void *data)
--
2.21.0
[PULL v2 2/9] block: Refactor macros - fix tabbing
From: Sam Eiderman
Fixing tabbing in block related macros.
Signed-off-by: Sam Eiderman
Signed-off-by: Sam Eiderman
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: John Snow
---
include/hw/block/block.h | 16
hw/ide/qdev.c| 2 +-
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/include/hw/block/block.h b/include/hw/block/block.h
index 607539057a..fd55a30bca 100644
--- a/include/hw/block/block.h
+++ b/include/hw/block/block.h
@@ -50,21 +50,21 @@ static inline unsigned int get_physical_block_exp(BlockConf
*conf)
_conf.logical_block_size),\
DEFINE_PROP_BLOCKSIZE("physical_block_size", _state,\
_conf.physical_block_size), \
-DEFINE_PROP_UINT16("min_io_size", _state, _conf.min_io_size, 0), \
+DEFINE_PROP_UINT16("min_io_size", _state, _conf.min_io_size, 0),\
DEFINE_PROP_UINT32("opt_io_size", _state, _conf.opt_io_size, 0),\
-DEFINE_PROP_UINT32("discard_granularity", _state, \
- _conf.discard_granularity, -1), \
-DEFINE_PROP_ON_OFF_AUTO("write-cache", _state, _conf.wce, \
-ON_OFF_AUTO_AUTO), \
+DEFINE_PROP_UINT32("discard_granularity", _state, \
+ _conf.discard_granularity, -1), \
+DEFINE_PROP_ON_OFF_AUTO("write-cache", _state, _conf.wce, \
+ON_OFF_AUTO_AUTO), \
DEFINE_PROP_BOOL("share-rw", _state, _conf.share_rw, false)
#define DEFINE_BLOCK_PROPERTIES(_state, _conf) \
DEFINE_PROP_DRIVE("drive", _state, _conf.blk), \
DEFINE_BLOCK_PROPERTIES_BASE(_state, _conf)
-#define DEFINE_BLOCK_CHS_PROPERTIES(_state, _conf) \
-DEFINE_PROP_UINT32("cyls", _state, _conf.cyls, 0), \
-DEFINE_PROP_UINT32("heads", _state, _conf.heads, 0), \
+#define DEFINE_BLOCK_CHS_PROPERTIES(_state, _conf) \
+DEFINE_PROP_UINT32("cyls", _state, _conf.cyls, 0), \
+DEFINE_PROP_UINT32("heads", _state, _conf.heads, 0),\
DEFINE_PROP_UINT32("secs", _state, _conf.secs, 0)
#define DEFINE_BLOCK_ERROR_PROPERTIES(_state, _conf)\
diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
index 3666e59721..85cca6ec38 100644
--- a/hw/ide/qdev.c
+++ b/hw/ide/qdev.c
@@ -293,7 +293,7 @@ static void ide_drive_realize(IDEDevice *dev, Error **errp)
DEFINE_BLOCK_PROPERTIES(IDEDrive, dev.conf),\
DEFINE_BLOCK_ERROR_PROPERTIES(IDEDrive, dev.conf), \
DEFINE_PROP_STRING("ver", IDEDrive, dev.version), \
-DEFINE_PROP_UINT64("wwn", IDEDrive, dev.wwn, 0),\
+DEFINE_PROP_UINT64("wwn", IDEDrive, dev.wwn, 0), \
DEFINE_PROP_STRING("serial", IDEDrive, dev.serial),\
DEFINE_PROP_STRING("model", IDEDrive, dev.model)
--
2.21.0
[PULL v2 1/9] IDE: deprecate ide-drive
It's an old compatibility shim that just delegates to ide-cd or ide-hd.
I'd like to refactor these some day, and getting rid of the super-object
will make that easier.
Either way, we don't need this.
Signed-off-by: John Snow
Reviewed-by: Thomas Huth
Reviewed-by: Markus Armbruster
ACKed-by: Peter Krempa
Message-id: 20191009224303.10232-2-js...@redhat.com
Signed-off-by: John Snow
---
qemu-deprecated.texi | 5 +
hw/ide/qdev.c | 3 +++
tests/qemu-iotests/051.pc.out | 6 --
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
index f727bd3932..296bfc93a3 100644
--- a/qemu-deprecated.texi
+++ b/qemu-deprecated.texi
@@ -254,6 +254,11 @@ quite a bit. It will be removed without replacement unless
some users speaks
up at the @email{qemu-devel@@nongnu.org} mailing list with information about
their usecases.
+@subsection ide-drive (since 4.2)
+
+The 'ide-drive' device is deprecated. Users should use 'ide-hd' or
+'ide-cd' as appropriate to get an IDE hard disk or CD-ROM as needed.
+
@section System emulator machines
@subsection pc-0.12, pc-0.13, pc-0.14 and pc-0.15 (since 4.0)
diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
index 6fba6b62b8..3666e59721 100644
--- a/hw/ide/qdev.c
+++ b/hw/ide/qdev.c
@@ -279,6 +279,9 @@ static void ide_drive_realize(IDEDevice *dev, Error **errp)
{
DriveInfo *dinfo = NULL;
+warn_report("'ide-drive' is deprecated, "
+"please use 'ide-hd' or 'ide-cd' instead");
+
if (dev->conf.blk) {
dinfo = blk_legacy_dinfo(dev->conf.blk);
}
diff --git a/tests/qemu-iotests/051.pc.out b/tests/qemu-iotests/051.pc.out
index 000557c7c8..34849dd172 100644
--- a/tests/qemu-iotests/051.pc.out
+++ b/tests/qemu-iotests/051.pc.out
@@ -158,7 +158,8 @@ QEMU X.Y.Z monitor - type 'help' for more information
Testing: -drive if=none,id=disk -device ide-drive,drive=disk
QEMU X.Y.Z monitor - type 'help' for more information
-(qemu) QEMU_PROG: -device ide-drive,drive=disk: Device needs media, but drive
is empty
+(qemu) QEMU_PROG: -device ide-drive,drive=disk: warning: 'ide-drive' is
deprecated, please use 'ide-hd' or 'ide-cd' instead
+QEMU_PROG: -device ide-drive,drive=disk: Device needs media, but drive is empty
Testing: -drive if=none,id=disk -device ide-hd,drive=disk
QEMU X.Y.Z monitor - type 'help' for more information
@@ -228,7 +229,8 @@ QEMU X.Y.Z monitor - type 'help' for more information
Testing: -drive file=TEST_DIR/t.qcow2,if=none,id=disk,readonly=on -device
ide-drive,drive=disk
QEMU X.Y.Z monitor - type 'help' for more information
-(qemu) QEMU_PROG: -device ide-drive,drive=disk: Block node is read-only
+(qemu) QEMU_PROG: -device ide-drive,drive=disk: warning: 'ide-drive' is
deprecated, please use 'ide-hd' or 'ide-cd' instead
+QEMU_PROG: -device ide-drive,drive=disk: Block node is read-only
Testing: -drive file=TEST_DIR/t.qcow2,if=none,id=disk,readonly=on -device
ide-hd,drive=disk
QEMU X.Y.Z monitor - type 'help' for more information
--
2.21.0
[PULL v2 0/9] Ide patches
The following changes since commit 68d8ef4ec540682c3538d4963e836e43a211dd17: Merge remote-tracking branch 'remotes/stsquad/tags/pull-tcg-plugins-281019-4' into staging (2019-10-30 14:10:32 +) are available in the Git repository at: https://github.com/jnsnow/qemu.git tags/ide-pull-request for you to fetch changes up to dc237c45aee52f268369dc6a485c623f1232e1d3: hd-geo-test: Add tests for lchs override (2019-10-31 11:47:43 -0400) Pull request John Snow (1): IDE: deprecate ide-drive Sam Eiderman (8): block: Refactor macros - fix tabbing block: Support providing LCHS from user bootdevice: Add interface to gather LCHS scsi: Propagate unrealize() callback to scsi-hd bootdevice: Gather LCHS from all relevant devices bootdevice: Refactor get_boot_devices_list bootdevice: FW_CFG interface for LCHS values hd-geo-test: Add tests for lchs override qemu-deprecated.texi | 5 + include/hw/block/block.h | 22 +- include/hw/scsi/scsi.h| 1 + include/sysemu/sysemu.h | 4 + bootdevice.c | 147 +++-- hw/block/virtio-blk.c | 6 + hw/ide/qdev.c | 10 +- hw/nvram/fw_cfg.c | 14 +- hw/scsi/scsi-bus.c| 16 + hw/scsi/scsi-disk.c | 12 + tests/hd-geo-test.c | 551 ++ tests/Makefile.include| 2 +- tests/qemu-iotests/051.pc.out | 6 +- 13 files changed, 753 insertions(+), 43 deletions(-) -- 2.21.0
[PULL v2 6/9] bootdevice: Gather LCHS from all relevant devices
From: Sam Eiderman
Relevant devices are:
* ide-hd (and ide-cd, ide-drive)
* scsi-hd (and scsi-cd, scsi-disk, scsi-block)
* virtio-blk-pci
We do not call del_boot_device_lchs() for ide-* since we don't need to -
IDE block devices do not support unplugging.
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Signed-off-by: Sam Eiderman
Signed-off-by: Sam Eiderman
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Signed-off-by: John Snow
---
hw/block/virtio-blk.c | 6 ++
hw/ide/qdev.c | 5 +
hw/scsi/scsi-disk.c | 12
3 files changed, 23 insertions(+)
diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index 9fa2eaf890..4c357d2928 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -1200,6 +1200,11 @@ static void virtio_blk_device_realize(DeviceState *dev,
Error **errp)
blk_set_guest_block_size(s->blk, s->conf.conf.logical_block_size);
blk_iostatus_enable(s->blk);
+
+add_boot_device_lchs(dev, "/disk@0,0",
+ conf->conf.lcyls,
+ conf->conf.lheads,
+ conf->conf.lsecs);
}
static void virtio_blk_device_unrealize(DeviceState *dev, Error **errp)
@@ -1210,6 +1215,7 @@ static void virtio_blk_device_unrealize(DeviceState *dev,
Error **errp)
unsigned i;
blk_drain(s->blk);
+del_boot_device_lchs(dev, "/disk@0,0");
virtio_blk_data_plane_destroy(s->dataplane);
s->dataplane = NULL;
for (i = 0; i < conf->num_queues; i++) {
diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
index 85cca6ec38..374a791a45 100644
--- a/hw/ide/qdev.c
+++ b/hw/ide/qdev.c
@@ -220,6 +220,11 @@ static void ide_dev_initfn(IDEDevice *dev, IDEDriveKind
kind, Error **errp)
add_boot_device_path(dev->conf.bootindex, >qdev,
dev->unit ? "/disk@1" : "/disk@0");
+
+add_boot_device_lchs(>qdev, dev->unit ? "/disk@1" : "/disk@0",
+ dev->conf.lcyls,
+ dev->conf.lheads,
+ dev->conf.lsecs);
}
static void ide_dev_get_bootindex(Object *obj, Visitor *v, const char *name,
diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
index 68b1675fd9..07fb5ebdf1 100644
--- a/hw/scsi/scsi-disk.c
+++ b/hw/scsi/scsi-disk.c
@@ -35,6 +35,7 @@
#include "hw/block/block.h"
#include "hw/qdev-properties.h"
#include "sysemu/dma.h"
+#include "sysemu/sysemu.h"
#include "qemu/cutils.h"
#include "trace.h"
@@ -2414,6 +2415,16 @@ static void scsi_realize(SCSIDevice *dev, Error **errp)
blk_set_guest_block_size(s->qdev.conf.blk, s->qdev.blocksize);
blk_iostatus_enable(s->qdev.conf.blk);
+
+add_boot_device_lchs(>qdev, NULL,
+ dev->conf.lcyls,
+ dev->conf.lheads,
+ dev->conf.lsecs);
+}
+
+static void scsi_unrealize(SCSIDevice *dev, Error **errp)
+{
+del_boot_device_lchs(>qdev, NULL);
}
static void scsi_hd_realize(SCSIDevice *dev, Error **errp)
@@ -3018,6 +3029,7 @@ static void scsi_hd_class_initfn(ObjectClass *klass, void
*data)
SCSIDeviceClass *sc = SCSI_DEVICE_CLASS(klass);
sc->realize = scsi_hd_realize;
+sc->unrealize= scsi_unrealize;
sc->alloc_req= scsi_new_request;
sc->unit_attention_reported = scsi_disk_unit_attention_reported;
dc->desc = "virtual SCSI disk";
--
2.21.0
git-publish, --pull-request and --signoff (was: Re: [PULL 0/9] Ide patches)
On 10/31/19 11:02 AM, Peter Maydell wrote: > On Thu, 31 Oct 2019 at 10:59, John Snow wrote: >> >> The following changes since commit 68d8ef4ec540682c3538d4963e836e43a211dd17: >> >> Merge remote-tracking branch >> 'remotes/stsquad/tags/pull-tcg-plugins-281019-4' into staging (2019-10-30 >> 14:10:32 +) >> >> are available in the Git repository at: >> >> https://github.com/jnsnow/qemu.git tags/ide-pull-request >> >> for you to fetch changes up to c35564caf20e8d3431786dddf0fa513daa7d7f3c: >> >> hd-geo-test: Add tests for lchs override (2019-10-31 06:11:34 -0400) >> >> >> Pull request >> > > Hi -- this passed the merge tests but it looks like you forgot > to add your signed-off by line as the submaintainer to Sam's > patches. Could you fix that up and resend, please? > > thanks > -- PMM > I bit myself twice with this now: adding --signoff to a pull request signs the messages that get sent to list, but not the ones that get staged. Could always be a bug in my local copy, but I'm documenting it on the list, in case I don't get time to look at this in the next 24h. --js
[PULL v2 5/9] scsi: Propagate unrealize() callback to scsi-hd
From: Sam Eiderman
We will need to add LCHS removal logic to scsi-hd's unrealize() in the
next commit.
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Sam Eiderman
Signed-off-by: Sam Eiderman
Tested-by: Philippe Mathieu-Daudé
Signed-off-by: John Snow
---
include/hw/scsi/scsi.h | 1 +
hw/scsi/scsi-bus.c | 16
2 files changed, 17 insertions(+)
diff --git a/include/hw/scsi/scsi.h b/include/hw/scsi/scsi.h
index d77a92361b..332ef602f4 100644
--- a/include/hw/scsi/scsi.h
+++ b/include/hw/scsi/scsi.h
@@ -59,6 +59,7 @@ struct SCSIRequest {
typedef struct SCSIDeviceClass {
DeviceClass parent_class;
void (*realize)(SCSIDevice *dev, Error **errp);
+void (*unrealize)(SCSIDevice *dev, Error **errp);
int (*parse_cdb)(SCSIDevice *dev, SCSICommand *cmd, uint8_t *buf,
void *hba_private);
SCSIRequest *(*alloc_req)(SCSIDevice *s, uint32_t tag, uint32_t lun,
diff --git a/hw/scsi/scsi-bus.c b/hw/scsi/scsi-bus.c
index bccb7cc4c6..359d50d6d0 100644
--- a/hw/scsi/scsi-bus.c
+++ b/hw/scsi/scsi-bus.c
@@ -59,6 +59,14 @@ static void scsi_device_realize(SCSIDevice *s, Error **errp)
}
}
+static void scsi_device_unrealize(SCSIDevice *s, Error **errp)
+{
+SCSIDeviceClass *sc = SCSI_DEVICE_GET_CLASS(s);
+if (sc->unrealize) {
+sc->unrealize(s, errp);
+}
+}
+
int scsi_bus_parse_cdb(SCSIDevice *dev, SCSICommand *cmd, uint8_t *buf,
void *hba_private)
{
@@ -217,12 +225,20 @@ static void scsi_qdev_realize(DeviceState *qdev, Error
**errp)
static void scsi_qdev_unrealize(DeviceState *qdev, Error **errp)
{
SCSIDevice *dev = SCSI_DEVICE(qdev);
+Error *local_err = NULL;
if (dev->vmsentry) {
qemu_del_vm_change_state_handler(dev->vmsentry);
}
scsi_device_purge_requests(dev, SENSE_CODE(NO_SENSE));
+
+scsi_device_unrealize(dev, _err);
+if (local_err) {
+error_propagate(errp, local_err);
+return;
+}
+
blockdev_mark_auto_del(dev->conf.blk);
}
--
2.21.0
Re: [Virtio-fs] [PATCH] virtiofsd: Fix data corruption with O_APPEND wirte in writeback mode
On Thu, Oct 31, 2019 at 09:39:23AM +, misono.tomoh...@fujitsu.com wrote: [..] > > > > Hi Misono, > > > > > > > > Have you tried running pjdfstests. Looks like with the patch applied > > > > I see following tests failing which were passing without the patch. > > > > Can you please have a look. I ran daemon with options "-o > > > cache=always -o writeback" > > > > I see these errors in both with and without this patch but not always. > > Do you always see the failure? > > > > I use: > > Kernel: Fuse's for-next branch > > Qemu: virtio-fs-dev branch > > backend: XFS (relatime) > > > > These tests fail because a/c/m time is not updated as expected. > > So it seems this is related to the failure of xfstest generic/003. > > I will look into the problem more. > > > > Hi, > > So I fugured out the problem. > The failure occurs when guest clock is earlier than host clock in writeback > mode. > > The failure case checks: > 1. get current c/time of file > 2. sleep 1 second > 3. modify file's metadata/data > 4. check if c/mtime is updated > > And the tests fail because: > 1. when file is opened, guest inode's time is initialized by host's inode > information > 2. In writeback mode, guest clock is used for c/mtime update > 3. if guest clock is earlier than host clock, c/mtime could be updated > earlier than current inode time. > > I can reproduce the problem reliably by deliberately setting guest clock > earlier > than host clock. I'm not sure if virtiofs is to be blmaed in this case, but > should > we not update c/mtime in guest if it is earlier then current c/mtime? > > Anyway, I believe this O_APPEND fix patch is irrelevant to the problem, > could you please check it again? Hi Misono, Thanks for looking into it. I agree that a/c/m time updates with -o writeback is probably a different issue and not related to your patch. So I am fine with your patch. Thanks Vivek
Re: RFC: New device for zero-copy VM memory access
* ge...@hostfission.com (ge...@hostfission.com) wrote: > > > On 2019-11-01 01:52, Peter Maydell wrote: > > On Thu, 31 Oct 2019 at 14:26, wrote: > > > As the author of Looking Glass, I also have to consider the > > > maintenance > > > and the complexity of implementing the vhost protocol into the > > > project. > > > At this time a complete Porthole client can be implemented in 150 > > > lines > > > of C without external dependencies, and most of that is boilerplate > > > socket code. This IMO is a major factor in deciding to avoid > > > vhost-user. > > > > This is essentially a proposal that we should make our project and > > code more complicated so that your project and code can be simpler. > > I hope you can see why this isn't necessarily an argument that will hold > > very much weight for us :-) > > Certainly, I do which is why I am still going to see about using vhost, > however, a device that uses vhost is likely more complex then the device > as it stands right now and as such more maintenance would be involved on > your end also. Or have I missed something in that vhost-user can be used > directly as a device? The basic vhost-user stuff isn't actually that hard; if you aren't actually shuffling commands over the queues you should find it pretty simple - so I think your assumption about it being simpler if you avoid it might be wrong. It might be easier if you use it! Dave > > > > thanks > > -- PMM -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [Virtio-fs] [PATCH] virtiofsd: Fix data corruption with O_APPEND wirte in writeback mode
On Wed, Oct 23, 2019 at 09:25:23PM +0900, Misono Tomohiro wrote:
> When writeback mode is enabled (-o writeback), O_APPEND handling is
> done in kernel. Therefore virtiofsd clears O_APPEND flag when open.
> Otherwise O_APPEND flag takes precedence over pwrite() and write
> data may corrupt.
>
> Currently clearing O_APPEND flag is done in lo_open(), but we also
> need the same operation in lo_create(). So, factor out the flag
> update operation in lo_open() to update_open_flags() and call it
> in both lo_open() and lo_create().
>
> This fixes the failure of xfstest generic/069 in writeback mode
> (which tests O_APPEND write data integrity).
>
> Signed-off-by: Misono Tomohiro
Reviewed-by: Vivek Goyal
Thanks
Vivek
> ---
> contrib/virtiofsd/passthrough_ll.c | 56 +++---
> 1 file changed, 28 insertions(+), 28 deletions(-)
>
> diff --git a/contrib/virtiofsd/passthrough_ll.c
> b/contrib/virtiofsd/passthrough_ll.c
> index e8892c3c32..79fb78ecce 100644
> --- a/contrib/virtiofsd/passthrough_ll.c
> +++ b/contrib/virtiofsd/passthrough_ll.c
> @@ -1733,6 +1733,32 @@ static void lo_releasedir(fuse_req_t req, fuse_ino_t
> ino, struct fuse_file_info
> fuse_reply_err(req, 0);
> }
>
> +static void update_open_flags(int writeback, struct fuse_file_info *fi)
> +{
> + /* With writeback cache, kernel may send read requests even
> +when userspace opened write-only */
> + if (writeback && (fi->flags & O_ACCMODE) == O_WRONLY) {
> + fi->flags &= ~O_ACCMODE;
> + fi->flags |= O_RDWR;
> + }
> +
> + /* With writeback cache, O_APPEND is handled by the kernel.
> +This breaks atomicity (since the file may change in the
> +underlying filesystem, so that the kernel's idea of the
> +end of the file isn't accurate anymore). In this example,
> +we just accept that. A more rigorous filesystem may want
> +to return an error here */
> + if (writeback && (fi->flags & O_APPEND))
> + fi->flags &= ~O_APPEND;
> +
> + /*
> + * O_DIRECT in guest should not necessarily mean bypassing page
> + * cache on host as well. If somebody needs that behavior, it
> + * probably should be a configuration knob in daemon.
> + */
> + fi->flags &= ~O_DIRECT;
> +}
> +
> static void lo_create(fuse_req_t req, fuse_ino_t parent, const char *name,
> mode_t mode, struct fuse_file_info *fi)
> {
> @@ -1760,12 +1786,7 @@ static void lo_create(fuse_req_t req, fuse_ino_t
> parent, const char *name,
> if (err)
> goto out;
>
> - /*
> - * O_DIRECT in guest should not necessarily mean bypassing page
> - * cache on host as well. If somebody needs that behavior, it
> - * probably should be a configuration knob in daemon.
> - */
> - fi->flags &= ~O_DIRECT;
> + update_open_flags(lo->writeback, fi);
>
> fd = openat(parent_inode->fd, name,
> (fi->flags | O_CREAT) & ~O_NOFOLLOW, mode);
> @@ -1966,28 +1987,7 @@ static void lo_open(fuse_req_t req, fuse_ino_t ino,
> struct fuse_file_info *fi)
>
> fuse_log(FUSE_LOG_DEBUG, "lo_open(ino=%" PRIu64 ", flags=%d)\n", ino,
> fi->flags);
>
> - /* With writeback cache, kernel may send read requests even
> -when userspace opened write-only */
> - if (lo->writeback && (fi->flags & O_ACCMODE) == O_WRONLY) {
> - fi->flags &= ~O_ACCMODE;
> - fi->flags |= O_RDWR;
> - }
> -
> - /* With writeback cache, O_APPEND is handled by the kernel.
> -This breaks atomicity (since the file may change in the
> -underlying filesystem, so that the kernel's idea of the
> -end of the file isn't accurate anymore). In this example,
> -we just accept that. A more rigorous filesystem may want
> -to return an error here */
> - if (lo->writeback && (fi->flags & O_APPEND))
> - fi->flags &= ~O_APPEND;
> -
> - /*
> - * O_DIRECT in guest should not necessarily mean bypassing page
> - * cache on host as well. If somebody needs that behavior, it
> - * probably should be a configuration knob in daemon.
> - */
> - fi->flags &= ~O_DIRECT;
> + update_open_flags(lo->writeback, fi);
>
> sprintf(buf, "%i", lo_fd(req, ino));
> fd = openat(lo->proc_self_fd, buf, fi->flags & ~O_NOFOLLOW);
> --
> 2.21.0
>
> ___
> Virtio-fs mailing list
> virtio...@redhat.com
> https://www.redhat.com/mailman/listinfo/virtio-fs
Re: [PULL 0/9] Ide patches
On 10/31/19 11:02 AM, Peter Maydell wrote: > On Thu, 31 Oct 2019 at 10:59, John Snow wrote: >> >> The following changes since commit 68d8ef4ec540682c3538d4963e836e43a211dd17: >> >> Merge remote-tracking branch >> 'remotes/stsquad/tags/pull-tcg-plugins-281019-4' into staging (2019-10-30 >> 14:10:32 +) >> >> are available in the Git repository at: >> >> https://github.com/jnsnow/qemu.git tags/ide-pull-request >> >> for you to fetch changes up to c35564caf20e8d3431786dddf0fa513daa7d7f3c: >> >> hd-geo-test: Add tests for lchs override (2019-10-31 06:11:34 -0400) >> >> >> Pull request >> > > Hi -- this passed the merge tests but it looks like you forgot > to add your signed-off by line as the submaintainer to Sam's > patches. Could you fix that up and resend, please? > > thanks > -- PMM > Haha. I re-applied them to grab Phil's SOBs and that dropped mine. OK, re-spinning. (Note to self: add a check to git-publish --pull that looks for my SOB.)
Re: [PATCH] tests/boot_linux_console: Fetch assets from Debian snapshot archives
Philippe Mathieu-Daudé writes:
> The kernel packaged was fetched from an unstable repository.
> Use the stable snapshot archive instead.
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Alex Bennée
Tested-by: Alex Bennée
> ---
> tests/acceptance/boot_linux_console.py | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/tests/acceptance/boot_linux_console.py
> b/tests/acceptance/boot_linux_console.py
> index 4e9ac0ecc3..f5aa87317c 100644
> --- a/tests/acceptance/boot_linux_console.py
> +++ b/tests/acceptance/boot_linux_console.py
> @@ -479,7 +479,8 @@ class BootLinuxConsole(Test):
> :avocado: tags=arch:m68k
> :avocado: tags=machine:q800
> """
> -deb_url = ('http://ftp.ports.debian.org/debian-ports/pool-m68k/main'
> +deb_url = ('https://snapshot.debian.org/archive/debian-ports'
> + '/20190922T090906Z/pool-m68k/main'
> '/l/linux/kernel-image-5.2.0-2-m68k-di_5.2.9-2_m68k.udeb')
> deb_hash = '0797e05129595f22f3c0142db5e199769a723bf9'
> deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash)
--
Alex Bennée
Re: [PATCH v8 0/9] target/arm/kvm: enable SVE in guests
Patchew URL: https://patchew.org/QEMU/20191031142734.8590-1-drjo...@redhat.com/ Hi, This series failed the docker-quick@centos7 build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. === TEST SCRIPT BEGIN === #!/bin/bash make docker-image-centos7 V=1 NETWORK=1 time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1 === TEST SCRIPT END === TESTiotest-qcow2: 268 Failures: 161 Failed 1 of 108 iotests make: *** [check-tests/check-block.sh] Error 1 Traceback (most recent call last): File "./tests/docker/docker.py", line 662, in sys.exit(main()) --- raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', '--label', 'com.qemu.instance.uuid=6aff5e90fd114c4a8cc3d62d7826b87f', '-u', '1003', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', '-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', '/home/patchew2/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', '/var/tmp/patchew-tester-tmp-wmvp1fab/src/docker-src.2019-10-31-11.09.54.14548:/var/tmp/qemu:z,ro', 'qemu:centos7', '/var/tmp/qemu/run', 'test-quick']' returned non-zero exit status 2. filter=--filter=label=com.qemu.instance.uuid=6aff5e90fd114c4a8cc3d62d7826b87f make[1]: *** [docker-run] Error 1 make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-wmvp1fab/src' make: *** [docker-run-test-quick@centos7] Error 2 real11m59.421s user0m8.385s The full log is available at http://patchew.org/logs/20191031142734.8590-1-drjo...@redhat.com/testing.docker-quick@centos7/?type=message. --- Email generated automatically by Patchew [https://patchew.org/]. Please send your feedback to patchew-de...@redhat.com
Re: RFC: New device for zero-copy VM memory access
On 2019-11-01 01:52, Peter Maydell wrote: On Thu, 31 Oct 2019 at 14:26, wrote: As the author of Looking Glass, I also have to consider the maintenance and the complexity of implementing the vhost protocol into the project. At this time a complete Porthole client can be implemented in 150 lines of C without external dependencies, and most of that is boilerplate socket code. This IMO is a major factor in deciding to avoid vhost-user. This is essentially a proposal that we should make our project and code more complicated so that your project and code can be simpler. I hope you can see why this isn't necessarily an argument that will hold very much weight for us :-) Certainly, I do which is why I am still going to see about using vhost, however, a device that uses vhost is likely more complex then the device as it stands right now and as such more maintenance would be involved on your end also. Or have I missed something in that vhost-user can be used directly as a device? thanks -- PMM
Re: [PATCH v1 1/1] hw/arm/boot: Rebuild hflags when modifying CPUState at boot
Edgar E. Iglesias writes: > Rebuild hflags when modifying CPUState at boot. > > Fixes: e979972a6a > Signed-off-by: Edgar E. Iglesias > --- > hw/arm/boot.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/hw/arm/boot.c b/hw/arm/boot.c > index c264864c11..ef6724960c 100644 > --- a/hw/arm/boot.c > +++ b/hw/arm/boot.c > @@ -786,6 +786,7 @@ static void do_cpu_reset(void *opaque) > info->secondary_cpu_reset_hook(cpu, info); > } > } > +arm_rebuild_hflags(env); Do we just get away with armv7m_reset because there is no futzing about with execution state? Anyway: Reviewed-by: Alex Bennée > } > } -- Alex Bennée
Re: [PULL 0/9] Ide patches
On Thu, 31 Oct 2019 at 10:59, John Snow wrote: > > The following changes since commit 68d8ef4ec540682c3538d4963e836e43a211dd17: > > Merge remote-tracking branch > 'remotes/stsquad/tags/pull-tcg-plugins-281019-4' into staging (2019-10-30 > 14:10:32 +) > > are available in the Git repository at: > > https://github.com/jnsnow/qemu.git tags/ide-pull-request > > for you to fetch changes up to c35564caf20e8d3431786dddf0fa513daa7d7f3c: > > hd-geo-test: Add tests for lchs override (2019-10-31 06:11:34 -0400) > > > Pull request > Hi -- this passed the merge tests but it looks like you forgot to add your signed-off by line as the submaintainer to Sam's patches. Could you fix that up and resend, please? thanks -- PMM
Re: RFC: New device for zero-copy VM memory access
On Thu, 31 Oct 2019 at 14:26, wrote: > As the author of Looking Glass, I also have to consider the maintenance > and the complexity of implementing the vhost protocol into the project. > At this time a complete Porthole client can be implemented in 150 lines > of C without external dependencies, and most of that is boilerplate > socket code. This IMO is a major factor in deciding to avoid vhost-user. This is essentially a proposal that we should make our project and code more complicated so that your project and code can be simpler. I hope you can see why this isn't necessarily an argument that will hold very much weight for us :-) thanks -- PMM
[PATCH v8 5/9] target/arm/kvm64: Add kvm_arch_get/put_sve
These are the SVE equivalents to kvm_arch_get/put_fpsimd. Note, the
swabbing is different than it is for fpsmid because the vector format
is a little-endian stream of words.
Signed-off-by: Andrew Jones
Reviewed-by: Richard Henderson
Reviewed-by: Eric Auger
Tested-by: Masayoshi Mizuma
---
target/arm/kvm64.c | 183 ++---
1 file changed, 155 insertions(+), 28 deletions(-)
diff --git a/target/arm/kvm64.c b/target/arm/kvm64.c
index 28f6db57d5ee..4c0b11d105a4 100644
--- a/target/arm/kvm64.c
+++ b/target/arm/kvm64.c
@@ -671,11 +671,12 @@ int kvm_arch_destroy_vcpu(CPUState *cs)
bool kvm_arm_reg_syncs_via_cpreg_list(uint64_t regidx)
{
/* Return true if the regidx is a register we should synchronize
- * via the cpreg_tuples array (ie is not a core reg we sync by
- * hand in kvm_arch_get/put_registers())
+ * via the cpreg_tuples array (ie is not a core or sve reg that
+ * we sync by hand in kvm_arch_get/put_registers())
*/
switch (regidx & KVM_REG_ARM_COPROC_MASK) {
case KVM_REG_ARM_CORE:
+case KVM_REG_ARM64_SVE:
return false;
default:
return true;
@@ -721,10 +722,8 @@ int kvm_arm_cpreg_level(uint64_t regidx)
static int kvm_arch_put_fpsimd(CPUState *cs)
{
-ARMCPU *cpu = ARM_CPU(cs);
-CPUARMState *env = >env;
+CPUARMState *env = _CPU(cs)->env;
struct kvm_one_reg reg;
-uint32_t fpr;
int i, ret;
for (i = 0; i < 32; i++) {
@@ -742,17 +741,73 @@ static int kvm_arch_put_fpsimd(CPUState *cs)
}
}
-reg.addr = (uintptr_t)();
-fpr = vfp_get_fpsr(env);
-reg.id = AARCH64_SIMD_CTRL_REG(fp_regs.fpsr);
-ret = kvm_vcpu_ioctl(cs, KVM_SET_ONE_REG, );
-if (ret) {
-return ret;
+return 0;
+}
+
+/*
+ * SVE registers are encoded in KVM's memory in an endianness-invariant format.
+ * The byte at offset i from the start of the in-memory representation contains
+ * the bits [(7 + 8 * i) : (8 * i)] of the register value. As this means the
+ * lowest offsets are stored in the lowest memory addresses, then that nearly
+ * matches QEMU's representation, which is to use an array of host-endian
+ * uint64_t's, where the lower offsets are at the lower indices. To complete
+ * the translation we just need to byte swap the uint64_t's on big-endian
hosts.
+ */
+static uint64_t *sve_bswap64(uint64_t *dst, uint64_t *src, int nr)
+{
+#ifdef HOST_WORDS_BIGENDIAN
+int i;
+
+for (i = 0; i < nr; ++i) {
+dst[i] = bswap64(src[i]);
}
-reg.addr = (uintptr_t)();
-fpr = vfp_get_fpcr(env);
-reg.id = AARCH64_SIMD_CTRL_REG(fp_regs.fpcr);
+return dst;
+#else
+return src;
+#endif
+}
+
+/*
+ * KVM SVE registers come in slices where ZREGs have a slice size of 2048 bits
+ * and PREGS and the FFR have a slice size of 256 bits. However we simply hard
+ * code the slice index to zero for now as it's unlikely we'll need more than
+ * one slice for quite some time.
+ */
+static int kvm_arch_put_sve(CPUState *cs)
+{
+ARMCPU *cpu = ARM_CPU(cs);
+CPUARMState *env = >env;
+uint64_t tmp[ARM_MAX_VQ * 2];
+uint64_t *r;
+struct kvm_one_reg reg;
+int n, ret;
+
+for (n = 0; n < KVM_ARM64_SVE_NUM_ZREGS; ++n) {
+r = sve_bswap64(tmp, >vfp.zregs[n].d[0], cpu->sve_max_vq * 2);
+reg.addr = (uintptr_t)r;
+reg.id = KVM_REG_ARM64_SVE_ZREG(n, 0);
+ret = kvm_vcpu_ioctl(cs, KVM_SET_ONE_REG, );
+if (ret) {
+return ret;
+}
+}
+
+for (n = 0; n < KVM_ARM64_SVE_NUM_PREGS; ++n) {
+r = sve_bswap64(tmp, r = >vfp.pregs[n].p[0],
+DIV_ROUND_UP(cpu->sve_max_vq * 2, 8));
+reg.addr = (uintptr_t)r;
+reg.id = KVM_REG_ARM64_SVE_PREG(n, 0);
+ret = kvm_vcpu_ioctl(cs, KVM_SET_ONE_REG, );
+if (ret) {
+return ret;
+}
+}
+
+r = sve_bswap64(tmp, >vfp.pregs[FFR_PRED_NUM].p[0],
+DIV_ROUND_UP(cpu->sve_max_vq * 2, 8));
+reg.addr = (uintptr_t)r;
+reg.id = KVM_REG_ARM64_SVE_FFR(0);
ret = kvm_vcpu_ioctl(cs, KVM_SET_ONE_REG, );
if (ret) {
return ret;
@@ -765,6 +820,7 @@ int kvm_arch_put_registers(CPUState *cs, int level)
{
struct kvm_one_reg reg;
uint64_t val;
+uint32_t fpr;
int i, ret;
unsigned int el;
@@ -855,7 +911,27 @@ int kvm_arch_put_registers(CPUState *cs, int level)
}
}
-ret = kvm_arch_put_fpsimd(cs);
+if (cpu_isar_feature(aa64_sve, cpu)) {
+ret = kvm_arch_put_sve(cs);
+} else {
+ret = kvm_arch_put_fpsimd(cs);
+}
+if (ret) {
+return ret;
+}
+
+reg.addr = (uintptr_t)();
+fpr = vfp_get_fpsr(env);
+reg.id = AARCH64_SIMD_CTRL_REG(fp_regs.fpsr);
+ret = kvm_vcpu_ioctl(cs, KVM_SET_ONE_REG, );
+if (ret) {
+return ret;
+}
+
+reg.addr = (uintptr_t)();
+fpr = vfp_get_fpcr(env);
+reg.id = AARCH64_SIMD_CTRL_REG(fp_regs.fpcr);
+ret
[PATCH v8 9/9] target/arm/kvm: host cpu: Add support for sve properties
Allow cpu 'host' to enable SVE when it's available, unless the
user chooses to disable it with the added 'sve=off' cpu property.
Also give the user the ability to select vector lengths with the
sve properties. We don't adopt 'max' cpu's other sve property,
sve-max-vq, because that property is difficult to use with KVM.
That property assumes all vector lengths in the range from 1 up
to and including the specified maximum length are supported, but
there may be optional lengths not supported by the host in that
range. With KVM one must be more specific when enabling vector
lengths.
Signed-off-by: Andrew Jones
Reviewed-by: Eric Auger
Reviewed-by: Richard Henderson
Tested-by: Masayoshi Mizuma
---
docs/arm-cpu-features.rst | 19 ---
target/arm/cpu.c | 3 +++
target/arm/cpu.h | 2 ++
target/arm/cpu64.c| 33 +
target/arm/kvm64.c| 14 +-
tests/arm-cpu-features.c | 17 -
6 files changed, 55 insertions(+), 33 deletions(-)
diff --git a/docs/arm-cpu-features.rst b/docs/arm-cpu-features.rst
index bed218d44619..1b367e22e16e 100644
--- a/docs/arm-cpu-features.rst
+++ b/docs/arm-cpu-features.rst
@@ -272,31 +272,36 @@ SVE CPU Property Examples
$ qemu-system-aarch64 -M virt -cpu max
- 3) Only enable the 128-bit vector length::
+ 3) When KVM is enabled, implicitly enable all host CPU supported vector
+ lengths with the `host` CPU type::
+
+ $ qemu-system-aarch64 -M virt,accel=kvm -cpu host
+
+ 4) Only enable the 128-bit vector length::
$ qemu-system-aarch64 -M virt -cpu max,sve128=on
- 4) Disable the 512-bit vector length and all larger vector lengths,
+ 5) Disable the 512-bit vector length and all larger vector lengths,
since 512 is a power-of-two. This results in all the smaller,
uninitialized lengths (128, 256, and 384) defaulting to enabled::
$ qemu-system-aarch64 -M virt -cpu max,sve512=off
- 5) Enable the 128-bit, 256-bit, and 512-bit vector lengths::
+ 6) Enable the 128-bit, 256-bit, and 512-bit vector lengths::
$ qemu-system-aarch64 -M virt -cpu max,sve128=on,sve256=on,sve512=on
- 6) The same as (5), but since the 128-bit and 256-bit vector
+ 7) The same as (6), but since the 128-bit and 256-bit vector
lengths are required for the 512-bit vector length to be enabled,
then allow them to be auto-enabled::
$ qemu-system-aarch64 -M virt -cpu max,sve512=on
- 7) Do the same as (6), but by first disabling SVE and then re-enabling it::
+ 8) Do the same as (7), but by first disabling SVE and then re-enabling it::
$ qemu-system-aarch64 -M virt -cpu max,sve=off,sve512=on,sve=on
- 8) Force errors regarding the last vector length::
+ 9) Force errors regarding the last vector length::
$ qemu-system-aarch64 -M virt -cpu max,sve128=off
$ qemu-system-aarch64 -M virt -cpu max,sve=off,sve128=off,sve=on
@@ -308,5 +313,5 @@ The examples in "SVE CPU Property Examples" exhibit many
ways to select
vector lengths which developers may find useful in order to avoid overly
verbose command lines. However, the recommended way to select vector
lengths is to explicitly enable each desired length. Therefore only
-example's (1), (3), and (5) exhibit recommended uses of the properties.
+example's (1), (4), and (6) exhibit recommended uses of the properties.
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 17d1f2b2894d..7a4ac9339bf9 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -2670,6 +2670,9 @@ static void arm_host_initfn(Object *obj)
ARMCPU *cpu = ARM_CPU(obj);
kvm_arm_set_cpu_features_from_host(cpu);
+if (arm_feature(>env, ARM_FEATURE_AARCH64)) {
+aarch64_add_sve_properties(obj);
+}
arm_cpu_post_init(obj);
}
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index a044d6028b6a..e1a66a2d1cc0 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -977,11 +977,13 @@ int aarch64_cpu_gdb_write_register(CPUState *cpu, uint8_t
*buf, int reg);
void aarch64_sve_narrow_vq(CPUARMState *env, unsigned vq);
void aarch64_sve_change_el(CPUARMState *env, int old_el,
int new_el, bool el0_a64);
+void aarch64_add_sve_properties(Object *obj);
#else
static inline void aarch64_sve_narrow_vq(CPUARMState *env, unsigned vq) { }
static inline void aarch64_sve_change_el(CPUARMState *env, int o,
int n, bool a)
{ }
+static inline void aarch64_add_sve_properties(Object *obj) { }
#endif
#if !defined(CONFIG_TCG)
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index c161a146ff0d..68baf0482ffa 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -594,6 +594,21 @@ static void cpu_arm_set_sve(Object *obj, Visitor *v, const
char *name,
cpu->isar.id_aa64pfr0 = t;
}
+void aarch64_add_sve_properties(Object *obj)
+{
+uint32_t vq;
+
+object_property_add(obj, "sve", "bool", cpu_arm_get_sve,
[PATCH v8 3/9] target/arm: Allow SVE to be disabled via a CPU property
Since 97a28b0eeac14 ("target/arm: Allow VFP and Neon to be disabled via
a CPU property") we can disable the 'max' cpu model's VFP and neon
features, but there's no way to disable SVE. Add the 'sve=on|off'
property to give it that flexibility. We also rename
cpu_max_get/set_sve_vq to cpu_max_get/set_sve_max_vq in order for them
to follow the typical *_get/set_ pattern.
Signed-off-by: Andrew Jones
Reviewed-by: Richard Henderson
Reviewed-by: Eric Auger
Tested-by: Masayoshi Mizuma
Reviewed-by: Beata Michalska
---
target/arm/cpu.c | 3 ++-
target/arm/cpu64.c | 52 ++--
target/arm/monitor.c | 2 +-
tests/arm-cpu-features.c | 1 +
4 files changed, 49 insertions(+), 9 deletions(-)
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index ab3e1a036164..72a27ec4b0e3 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -200,7 +200,8 @@ static void arm_cpu_reset(CPUState *s)
env->cp15.cpacr_el1 = deposit64(env->cp15.cpacr_el1, 16, 2, 3);
env->cp15.cptr_el[3] |= CPTR_EZ;
/* with maximum vector length */
-env->vfp.zcr_el[1] = cpu->sve_max_vq - 1;
+env->vfp.zcr_el[1] = cpu_isar_feature(aa64_sve, cpu) ?
+ cpu->sve_max_vq - 1 : 0;
env->vfp.zcr_el[2] = env->vfp.zcr_el[1];
env->vfp.zcr_el[3] = env->vfp.zcr_el[1];
/*
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index d7f5bf610a7d..89a8ae77fe84 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -256,15 +256,23 @@ static void aarch64_a72_initfn(Object *obj)
define_arm_cp_regs(cpu, cortex_a72_a57_a53_cp_reginfo);
}
-static void cpu_max_get_sve_vq(Object *obj, Visitor *v, const char *name,
- void *opaque, Error **errp)
+static void cpu_max_get_sve_max_vq(Object *obj, Visitor *v, const char *name,
+ void *opaque, Error **errp)
{
ARMCPU *cpu = ARM_CPU(obj);
-visit_type_uint32(v, name, >sve_max_vq, errp);
+uint32_t value;
+
+/* All vector lengths are disabled when SVE is off. */
+if (!cpu_isar_feature(aa64_sve, cpu)) {
+value = 0;
+} else {
+value = cpu->sve_max_vq;
+}
+visit_type_uint32(v, name, , errp);
}
-static void cpu_max_set_sve_vq(Object *obj, Visitor *v, const char *name,
- void *opaque, Error **errp)
+static void cpu_max_set_sve_max_vq(Object *obj, Visitor *v, const char *name,
+ void *opaque, Error **errp)
{
ARMCPU *cpu = ARM_CPU(obj);
Error *err = NULL;
@@ -279,6 +287,34 @@ static void cpu_max_set_sve_vq(Object *obj, Visitor *v,
const char *name,
error_propagate(errp, err);
}
+static void cpu_arm_get_sve(Object *obj, Visitor *v, const char *name,
+void *opaque, Error **errp)
+{
+ARMCPU *cpu = ARM_CPU(obj);
+bool value = cpu_isar_feature(aa64_sve, cpu);
+
+visit_type_bool(v, name, , errp);
+}
+
+static void cpu_arm_set_sve(Object *obj, Visitor *v, const char *name,
+void *opaque, Error **errp)
+{
+ARMCPU *cpu = ARM_CPU(obj);
+Error *err = NULL;
+bool value;
+uint64_t t;
+
+visit_type_bool(v, name, , );
+if (err) {
+error_propagate(errp, err);
+return;
+}
+
+t = cpu->isar.id_aa64pfr0;
+t = FIELD_DP64(t, ID_AA64PFR0, SVE, value);
+cpu->isar.id_aa64pfr0 = t;
+}
+
/* -cpu max: if KVM is enabled, like -cpu host (best possible with this host);
* otherwise, a CPU with as many features enabled as our emulation supports.
* The version of '-cpu max' for qemu-system-arm is defined in cpu.c;
@@ -391,8 +427,10 @@ static void aarch64_max_initfn(Object *obj)
#endif
cpu->sve_max_vq = ARM_MAX_VQ;
-object_property_add(obj, "sve-max-vq", "uint32", cpu_max_get_sve_vq,
-cpu_max_set_sve_vq, NULL, NULL, _fatal);
+object_property_add(obj, "sve-max-vq", "uint32",
cpu_max_get_sve_max_vq,
+cpu_max_set_sve_max_vq, NULL, NULL, _fatal);
+object_property_add(obj, "sve", "bool", cpu_arm_get_sve,
+cpu_arm_set_sve, NULL, NULL, _fatal);
}
}
diff --git a/target/arm/monitor.c b/target/arm/monitor.c
index 560970de7f5c..2209b27b9a08 100644
--- a/target/arm/monitor.c
+++ b/target/arm/monitor.c
@@ -97,7 +97,7 @@ GICCapabilityList *qmp_query_gic_capabilities(Error **errp)
* then the order that considers those dependencies must be used.
*/
static const char *cpu_model_advertised_features[] = {
-"aarch64", "pmu",
+"aarch64", "pmu", "sve",
NULL
};
diff --git a/tests/arm-cpu-features.c b/tests/arm-cpu-features.c
index 6ebb03d7ad67..d5e18eb66622 100644
--- a/tests/arm-cpu-features.c
+++ b/tests/arm-cpu-features.c
@@ -197,6 +197,7 @@ static void test_query_cpu_model_expansion(const void *data)
if (g_str_equal(qtest_get_arch(), "aarch64")) {
[PATCH v8 7/9] target/arm/kvm: scratch vcpu: Preserve input kvm_vcpu_init features
kvm_arm_create_scratch_host_vcpu() takes a struct kvm_vcpu_init
parameter. Rather than just using it as an output parameter to
pass back the preferred target, use it also as an input parameter,
allowing a caller to pass a selected target if they wish and to
also pass cpu features. If the caller doesn't want to select a
target they can pass -1 for the target which indicates they want
to use the preferred target and have it passed back like before.
Signed-off-by: Andrew Jones
Reviewed-by: Richard Henderson
Reviewed-by: Eric Auger
Tested-by: Masayoshi Mizuma
Reviewed-by: Beata Michalska
---
target/arm/kvm.c | 20 +++-
target/arm/kvm32.c | 6 +-
target/arm/kvm64.c | 6 +-
3 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/target/arm/kvm.c b/target/arm/kvm.c
index f07332bbda30..5b82cefef608 100644
--- a/target/arm/kvm.c
+++ b/target/arm/kvm.c
@@ -66,7 +66,7 @@ bool kvm_arm_create_scratch_host_vcpu(const uint32_t
*cpus_to_try,
int *fdarray,
struct kvm_vcpu_init *init)
{
-int ret, kvmfd = -1, vmfd = -1, cpufd = -1;
+int ret = 0, kvmfd = -1, vmfd = -1, cpufd = -1;
kvmfd = qemu_open("/dev/kvm", O_RDWR);
if (kvmfd < 0) {
@@ -86,7 +86,14 @@ bool kvm_arm_create_scratch_host_vcpu(const uint32_t
*cpus_to_try,
goto finish;
}
-ret = ioctl(vmfd, KVM_ARM_PREFERRED_TARGET, init);
+if (init->target == -1) {
+struct kvm_vcpu_init preferred;
+
+ret = ioctl(vmfd, KVM_ARM_PREFERRED_TARGET, );
+if (!ret) {
+init->target = preferred.target;
+}
+}
if (ret >= 0) {
ret = ioctl(cpufd, KVM_ARM_VCPU_INIT, init);
if (ret < 0) {
@@ -98,10 +105,12 @@ bool kvm_arm_create_scratch_host_vcpu(const uint32_t
*cpus_to_try,
* creating one kind of guest CPU which is its preferred
* CPU type.
*/
+struct kvm_vcpu_init try;
+
while (*cpus_to_try != QEMU_KVM_ARM_TARGET_NONE) {
-init->target = *cpus_to_try++;
-memset(init->features, 0, sizeof(init->features));
-ret = ioctl(cpufd, KVM_ARM_VCPU_INIT, init);
+try.target = *cpus_to_try++;
+memcpy(try.features, init->features, sizeof(init->features));
+ret = ioctl(cpufd, KVM_ARM_VCPU_INIT, );
if (ret >= 0) {
break;
}
@@ -109,6 +118,7 @@ bool kvm_arm_create_scratch_host_vcpu(const uint32_t
*cpus_to_try,
if (ret < 0) {
goto err;
}
+init->target = try.target;
} else {
/* Treat a NULL cpus_to_try argument the same as an empty
* list, which means we will fail the call since this must
diff --git a/target/arm/kvm32.c b/target/arm/kvm32.c
index 2451a2d4bbef..32bf8d6757c4 100644
--- a/target/arm/kvm32.c
+++ b/target/arm/kvm32.c
@@ -53,7 +53,11 @@ bool kvm_arm_get_host_cpu_features(ARMHostCPUFeatures *ahcf)
QEMU_KVM_ARM_TARGET_CORTEX_A15,
QEMU_KVM_ARM_TARGET_NONE
};
-struct kvm_vcpu_init init;
+/*
+ * target = -1 informs kvm_arm_create_scratch_host_vcpu()
+ * to use the preferred target
+ */
+struct kvm_vcpu_init init = { .target = -1, };
if (!kvm_arm_create_scratch_host_vcpu(cpus_to_try, fdarray, )) {
return false;
diff --git a/target/arm/kvm64.c b/target/arm/kvm64.c
index 850da1b5e6aa..c7ecefbed720 100644
--- a/target/arm/kvm64.c
+++ b/target/arm/kvm64.c
@@ -502,7 +502,11 @@ bool kvm_arm_get_host_cpu_features(ARMHostCPUFeatures
*ahcf)
KVM_ARM_TARGET_CORTEX_A57,
QEMU_KVM_ARM_TARGET_NONE
};
-struct kvm_vcpu_init init;
+/*
+ * target = -1 informs kvm_arm_create_scratch_host_vcpu()
+ * to use the preferred target
+ */
+struct kvm_vcpu_init init = { .target = -1, };
if (!kvm_arm_create_scratch_host_vcpu(cpus_to_try, fdarray, )) {
return false;
--
2.21.0
[PATCH v8 6/9] target/arm/kvm64: max cpu: Enable SVE when available
Enable SVE in the KVM guest when the 'max' cpu type is configured
and KVM supports it. KVM SVE requires use of the new finalize
vcpu ioctl, so we add that now too. For starters SVE can only be
turned on or off, getting all vector lengths the host CPU supports
when on. We'll add the other SVE CPU properties in later patches.
Signed-off-by: Andrew Jones
Reviewed-by: Richard Henderson
Reviewed-by: Eric Auger
Tested-by: Masayoshi Mizuma
Reviewed-by: Beata Michalska
---
target/arm/cpu64.c | 17 ++---
target/arm/kvm.c | 5 +
target/arm/kvm64.c | 20 +++-
target/arm/kvm_arm.h | 27 +++
tests/arm-cpu-features.c | 4
5 files changed, 69 insertions(+), 4 deletions(-)
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index 34b0ba2cf6f7..a771a28daa56 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -493,6 +493,11 @@ static void cpu_arm_set_sve(Object *obj, Visitor *v, const
char *name,
return;
}
+if (value && kvm_enabled() && !kvm_arm_sve_supported(CPU(cpu))) {
+error_setg(errp, "'sve' feature not supported by KVM on this host");
+return;
+}
+
t = cpu->isar.id_aa64pfr0;
t = FIELD_DP64(t, ID_AA64PFR0, SVE, value);
cpu->isar.id_aa64pfr0 = t;
@@ -507,11 +512,16 @@ static void aarch64_max_initfn(Object *obj)
{
ARMCPU *cpu = ARM_CPU(obj);
uint32_t vq;
+uint64_t t;
if (kvm_enabled()) {
kvm_arm_set_cpu_features_from_host(cpu);
+if (kvm_arm_sve_supported(CPU(cpu))) {
+t = cpu->isar.id_aa64pfr0;
+t = FIELD_DP64(t, ID_AA64PFR0, SVE, 1);
+cpu->isar.id_aa64pfr0 = t;
+}
} else {
-uint64_t t;
uint32_t u;
aarch64_a57_initfn(obj);
@@ -612,8 +622,6 @@ static void aarch64_max_initfn(Object *obj)
object_property_add(obj, "sve-max-vq", "uint32",
cpu_max_get_sve_max_vq,
cpu_max_set_sve_max_vq, NULL, NULL, _fatal);
-object_property_add(obj, "sve", "bool", cpu_arm_get_sve,
-cpu_arm_set_sve, NULL, NULL, _fatal);
for (vq = 1; vq <= ARM_MAX_VQ; ++vq) {
char name[8];
@@ -622,6 +630,9 @@ static void aarch64_max_initfn(Object *obj)
cpu_arm_set_sve_vq, NULL, NULL, _fatal);
}
}
+
+object_property_add(obj, "sve", "bool", cpu_arm_get_sve,
+cpu_arm_set_sve, NULL, NULL, _fatal);
}
struct ARMCPUInfo {
diff --git a/target/arm/kvm.c b/target/arm/kvm.c
index b473c63edb1c..f07332bbda30 100644
--- a/target/arm/kvm.c
+++ b/target/arm/kvm.c
@@ -51,6 +51,11 @@ int kvm_arm_vcpu_init(CPUState *cs)
return kvm_vcpu_ioctl(cs, KVM_ARM_VCPU_INIT, );
}
+int kvm_arm_vcpu_finalize(CPUState *cs, int feature)
+{
+return kvm_vcpu_ioctl(cs, KVM_ARM_VCPU_FINALIZE, );
+}
+
void kvm_arm_init_serror_injection(CPUState *cs)
{
cap_has_inject_serror_esr = kvm_check_extension(cs->kvm_state,
diff --git a/target/arm/kvm64.c b/target/arm/kvm64.c
index 4c0b11d105a4..850da1b5e6aa 100644
--- a/target/arm/kvm64.c
+++ b/target/arm/kvm64.c
@@ -602,6 +602,13 @@ bool kvm_arm_aarch32_supported(CPUState *cpu)
return kvm_check_extension(s, KVM_CAP_ARM_EL1_32BIT);
}
+bool kvm_arm_sve_supported(CPUState *cpu)
+{
+KVMState *s = KVM_STATE(current_machine->accelerator);
+
+return kvm_check_extension(s, KVM_CAP_ARM_SVE);
+}
+
#define ARM_CPU_ID_MPIDR 3, 0, 0, 0, 5
int kvm_arch_init_vcpu(CPUState *cs)
@@ -630,13 +637,17 @@ int kvm_arch_init_vcpu(CPUState *cs)
cpu->kvm_init_features[0] |= 1 << KVM_ARM_VCPU_EL1_32BIT;
}
if (!kvm_check_extension(cs->kvm_state, KVM_CAP_ARM_PMU_V3)) {
-cpu->has_pmu = false;
+cpu->has_pmu = false;
}
if (cpu->has_pmu) {
cpu->kvm_init_features[0] |= 1 << KVM_ARM_VCPU_PMU_V3;
} else {
unset_feature(>features, ARM_FEATURE_PMU);
}
+if (cpu_isar_feature(aa64_sve, cpu)) {
+assert(kvm_arm_sve_supported(cs));
+cpu->kvm_init_features[0] |= 1 << KVM_ARM_VCPU_SVE;
+}
/* Do KVM_ARM_VCPU_INIT ioctl */
ret = kvm_arm_vcpu_init(cs);
@@ -644,6 +655,13 @@ int kvm_arch_init_vcpu(CPUState *cs)
return ret;
}
+if (cpu_isar_feature(aa64_sve, cpu)) {
+ret = kvm_arm_vcpu_finalize(cs, KVM_ARM_VCPU_SVE);
+if (ret) {
+return ret;
+}
+}
+
/*
* When KVM is in use, PSCI is emulated in-kernel and not by qemu.
* Currently KVM has its own idea about MPIDR assignment, so we
diff --git a/target/arm/kvm_arm.h b/target/arm/kvm_arm.h
index b4e19457a094..7c12f1501a8b 100644
--- a/target/arm/kvm_arm.h
+++ b/target/arm/kvm_arm.h
@@ -27,6 +27,20 @@
*/
int kvm_arm_vcpu_init(CPUState *cs);
+/**
+ * kvm_arm_vcpu_finalize
+ * @cs: CPUState
+ * @feature: int
+ *
+ * Finalizes the configuration of the specified VCPU feature by
+ *
[PATCH v8 1/9] target/arm/monitor: Introduce qmp_query_cpu_model_expansion
Add support for the query-cpu-model-expansion QMP command to Arm. We
do this selectively, only exposing CPU properties which represent
optional CPU features which the user may want to enable/disable.
Additionally we restrict the list of queryable cpu models to 'max',
'host', or the current type when KVM is in use. And, finally, we only
implement expansion type 'full', as Arm does not yet have a "base"
CPU type. More details and example queries are described in a new
document (docs/arm-cpu-features.rst).
Note, certainly more features may be added to the list of advertised
features, e.g. 'vfp' and 'neon'. The only requirement is that we can
detect invalid configurations and emit failures at QMP query time.
For 'vfp' and 'neon' this will require some refactoring to share a
validation function between the QMP query and the CPU realize
functions.
Signed-off-by: Andrew Jones
Reviewed-by: Richard Henderson
Reviewed-by: Eric Auger
Reviewed-by: Beata Michalska
---
docs/arm-cpu-features.rst | 137 +++
qapi/machine-target.json | 6 +-
target/arm/monitor.c | 146 ++
3 files changed, 286 insertions(+), 3 deletions(-)
create mode 100644 docs/arm-cpu-features.rst
diff --git a/docs/arm-cpu-features.rst b/docs/arm-cpu-features.rst
new file mode 100644
index ..c79dcffb5556
--- /dev/null
+++ b/docs/arm-cpu-features.rst
@@ -0,0 +1,137 @@
+
+ARM CPU Features
+
+
+Examples of probing and using ARM CPU features
+
+Introduction
+
+
+CPU features are optional features that a CPU of supporting type may
+choose to implement or not. In QEMU, optional CPU features have
+corresponding boolean CPU proprieties that, when enabled, indicate
+that the feature is implemented, and, conversely, when disabled,
+indicate that it is not implemented. An example of an ARM CPU feature
+is the Performance Monitoring Unit (PMU). CPU types such as the
+Cortex-A15 and the Cortex-A57, which respectively implement ARM
+architecture reference manuals ARMv7-A and ARMv8-A, may both optionally
+implement PMUs. For example, if a user wants to use a Cortex-A15 without
+a PMU, then the `-cpu` parameter should contain `pmu=off` on the QEMU
+command line, i.e. `-cpu cortex-a15,pmu=off`.
+
+As not all CPU types support all optional CPU features, then whether or
+not a CPU property exists depends on the CPU type. For example, CPUs
+that implement the ARMv8-A architecture reference manual may optionally
+support the AArch32 CPU feature, which may be enabled by disabling the
+`aarch64` CPU property. A CPU type such as the Cortex-A15, which does
+not implement ARMv8-A, will not have the `aarch64` CPU property.
+
+QEMU's support may be limited for some CPU features, only partially
+supporting the feature or only supporting the feature under certain
+configurations. For example, the `aarch64` CPU feature, which, when
+disabled, enables the optional AArch32 CPU feature, is only supported
+when using the KVM accelerator and when running on a host CPU type that
+supports the feature.
+
+CPU Feature Probing
+===
+
+Determining which CPU features are available and functional for a given
+CPU type is possible with the `query-cpu-model-expansion` QMP command.
+Below are some examples where `scripts/qmp/qmp-shell` (see the top comment
+block in the script for usage) is used to issue the QMP commands.
+
+(1) Determine which CPU features are available for the `max` CPU type
+(Note, we started QEMU with qemu-system-aarch64, so `max` is
+ implementing the ARMv8-A reference manual in this case)::
+
+ (QEMU) query-cpu-model-expansion type=full model={"name":"max"}
+ { "return": {
+"model": { "name": "max", "props": {
+"pmu": true, "aarch64": true
+
+
+We see that the `max` CPU type has the `pmu` and `aarch64` CPU features.
+We also see that the CPU features are enabled, as they are all `true`.
+
+(2) Let's try to disable the PMU::
+
+ (QEMU) query-cpu-model-expansion type=full
model={"name":"max","props":{"pmu":false}}
+ { "return": {
+"model": { "name": "max", "props": {
+"pmu": false, "aarch64": true
+
+
+We see it worked, as `pmu` is now `false`.
+
+(3) Let's try to disable `aarch64`, which enables the AArch32 CPU feature::
+
+ (QEMU) query-cpu-model-expansion type=full
model={"name":"max","props":{"aarch64":false}}
+ {"error": {
+ "class": "GenericError", "desc":
+ "'aarch64' feature cannot be disabled unless KVM is enabled and 32-bit
EL1 is supported"
+ }}
+
+It looks like this feature is limited to a configuration we do not
+currently have.
+
+(4) Let's try probing CPU features for the Cortex-A15 CPU type::
+
+ (QEMU) query-cpu-model-expansion type=full model={"name":"cortex-a15"}
+ {"return": {"model": {"name": "cortex-a15", "props": {"pmu": true
+
+Only the `pmu` CPU feature is available.
+
+A
[PATCH v8 8/9] target/arm/cpu64: max cpu: Support sve properties with KVM
Extend the SVE vq map initialization and validation with KVM's supported vector lengths when KVM is enabled. In order to determine and select supported lengths we add two new KVM functions for getting and setting the KVM_REG_ARM64_SVE_VLS pseudo-register. This patch has been co-authored with Richard Henderson, who reworked the target/arm/cpu64.c changes in order to push all the validation and auto-enabling/disabling steps into the finalizer, resulting in a nice LOC reduction. Signed-off-by: Andrew Jones Reviewed-by: Eric Auger Reviewed-by: Richard Henderson Tested-by: Masayoshi Mizuma --- docs/arm-cpu-features.rst | 45 +++--- target/arm/cpu64.c| 172 +- target/arm/kvm64.c| 100 +- target/arm/kvm_arm.h | 12 +++ tests/arm-cpu-features.c | 104 ++- 5 files changed, 377 insertions(+), 56 deletions(-) diff --git a/docs/arm-cpu-features.rst b/docs/arm-cpu-features.rst index 2ea4d6e90c02..bed218d44619 100644 --- a/docs/arm-cpu-features.rst +++ b/docs/arm-cpu-features.rst @@ -191,10 +191,18 @@ SVE CPU Property Dependencies and Constraints 1) At least one vector length must be enabled when `sve` is enabled. - 2) If a vector length `N` is enabled, then all power-of-two vector - lengths smaller than `N` must also be enabled. E.g. if `sve512` - is enabled, then the 128-bit and 256-bit vector lengths must also - be enabled. + 2) If a vector length `N` is enabled, then, when KVM is enabled, all + smaller, host supported vector lengths must also be enabled. If + KVM is not enabled, then only all the smaller, power-of-two vector + lengths must be enabled. E.g. with KVM if the host supports all + vector lengths up to 512-bits (128, 256, 384, 512), then if `sve512` + is enabled, the 128-bit vector length, 256-bit vector length, and + 384-bit vector length must also be enabled. Without KVM, the 384-bit + vector length would not be required. + + 3) If KVM is enabled then only vector lengths that the host CPU type + support may be enabled. If SVE is not supported by the host, then + no `sve*` properties may be enabled. SVE CPU Property Parsing Semantics -- @@ -209,8 +217,10 @@ SVE CPU Property Parsing Semantics an error is generated. 2) If SVE is enabled (`sve=on`), but no `sve` CPU properties are - provided, then all supported vector lengths are enabled, including - the non-power-of-two lengths. + provided, then all supported vector lengths are enabled, which when + KVM is not in use means including the non-power-of-two lengths, and, + when KVM is in use, it means all vector lengths supported by the host + processor. 3) If SVE is enabled, then an error is generated when attempting to disable the last enabled vector length (see constraint (1) of "SVE @@ -221,20 +231,31 @@ SVE CPU Property Parsing Semantics has been explicitly disabled, then an error is generated (see constraint (2) of "SVE CPU Property Dependencies and Constraints"). - 5) If one or more `sve` CPU properties are set `off`, but no `sve`, + 5) When KVM is enabled, if the host does not support SVE, then an error + is generated when attempting to enable any `sve*` properties (see + constraint (3) of "SVE CPU Property Dependencies and Constraints"). + + 6) When KVM is enabled, if the host does support SVE, then an error is + generated when attempting to enable any vector lengths not supported + by the host (see constraint (3) of "SVE CPU Property Dependencies and + Constraints"). + + 7) If one or more `sve` CPU properties are set `off`, but no `sve`, CPU properties are set `on`, then the specified vector lengths are disabled but the default for any unspecified lengths remains enabled. - Disabling a power-of-two vector length also disables all vector - lengths larger than the power-of-two length (see constraint (2) of - "SVE CPU Property Dependencies and Constraints"). + When KVM is not enabled, disabling a power-of-two vector length also + disables all vector lengths larger than the power-of-two length. + When KVM is enabled, then disabling any supported vector length also + disables all larger vector lengths (see constraint (2) of "SVE CPU + Property Dependencies and Constraints"). - 6) If one or more `sve` CPU properties are set to `on`, then they + 8) If one or more `sve` CPU properties are set to `on`, then they are enabled and all unspecified lengths default to disabled, except for the required lengths per constraint (2) of "SVE CPU Property Dependencies and Constraints", which will even be auto-enabled if they were not explicitly enabled. - 7) If SVE was disabled (`sve=off`), allowing all vector lengths to be + 9) If SVE was disabled (`sve=off`), allowing all vector lengths to be
[PATCH v8 4/9] target/arm/cpu64: max cpu: Introduce sve properties
Introduce cpu properties to give fine control over SVE vector lengths.
We introduce a property for each valid length up to the current
maximum supported, which is 2048-bits. The properties are named, e.g.
sve128, sve256, sve384, sve512, ..., where the number is the number of
bits. See the updates to docs/arm-cpu-features.rst for a description
of the semantics and for example uses.
Note, as sve-max-vq is still present and we'd like to be able to
support qmp_query_cpu_model_expansion with guests launched with e.g.
-cpu max,sve-max-vq=8 on their command lines, then we do allow
sve-max-vq and sve properties to be provided at the same time, but
this is not recommended, and is why sve-max-vq is not mentioned in the
document. If sve-max-vq is provided then it enables all lengths smaller
than and including the max and disables all lengths larger. It also has
the side-effect that no larger lengths may be enabled and that the max
itself cannot be disabled. Smaller non-power-of-two lengths may,
however, be disabled, e.g. -cpu max,sve-max-vq=4,sve384=off provides a
guest the vector lengths 128, 256, and 512 bits.
This patch has been co-authored with Richard Henderson, who reworked
the target/arm/cpu64.c changes in order to push all the validation and
auto-enabling/disabling steps into the finalizer, resulting in a nice
LOC reduction.
Signed-off-by: Andrew Jones
Reviewed-by: Richard Henderson
Reviewed-by: Eric Auger
Tested-by: Masayoshi Mizuma
Reviewed-by: Beata Michalska
---
docs/arm-cpu-features.rst | 168 +++--
include/qemu/bitops.h | 1 +
target/arm/cpu.c | 19
target/arm/cpu.h | 19
target/arm/cpu64.c| 192 -
target/arm/helper.c | 10 +-
target/arm/monitor.c | 12 +++
tests/arm-cpu-features.c | 194 ++
8 files changed, 606 insertions(+), 9 deletions(-)
diff --git a/docs/arm-cpu-features.rst b/docs/arm-cpu-features.rst
index c79dcffb5556..2ea4d6e90c02 100644
--- a/docs/arm-cpu-features.rst
+++ b/docs/arm-cpu-features.rst
@@ -48,18 +48,31 @@ block in the script for usage) is used to issue the QMP
commands.
(QEMU) query-cpu-model-expansion type=full model={"name":"max"}
{ "return": {
"model": { "name": "max", "props": {
-"pmu": true, "aarch64": true
+"sve1664": true, "pmu": true, "sve1792": true, "sve1920": true,
+"sve128": true, "aarch64": true, "sve1024": true, "sve": true,
+"sve640": true, "sve768": true, "sve1408": true, "sve256": true,
+"sve1152": true, "sve512": true, "sve384": true, "sve1536": true,
+"sve896": true, "sve1280": true, "sve2048": true
-We see that the `max` CPU type has the `pmu` and `aarch64` CPU features.
-We also see that the CPU features are enabled, as they are all `true`.
+We see that the `max` CPU type has the `pmu`, `aarch64`, `sve`, and many
+`sve` CPU features. We also see that all the CPU features are
+enabled, as they are all `true`. (The `sve` CPU features are all
+optional SVE vector lengths (see "SVE CPU Properties"). While with TCG
+all SVE vector lengths can be supported, when KVM is in use it's more
+likely that only a few lengths will be supported, if SVE is supported at
+all.)
(2) Let's try to disable the PMU::
(QEMU) query-cpu-model-expansion type=full
model={"name":"max","props":{"pmu":false}}
{ "return": {
"model": { "name": "max", "props": {
-"pmu": false, "aarch64": true
+"sve1664": true, "pmu": false, "sve1792": true, "sve1920": true,
+"sve128": true, "aarch64": true, "sve1024": true, "sve": true,
+"sve640": true, "sve768": true, "sve1408": true, "sve256": true,
+"sve1152": true, "sve512": true, "sve384": true, "sve1536": true,
+"sve896": true, "sve1280": true, "sve2048": true
We see it worked, as `pmu` is now `false`.
@@ -75,7 +88,22 @@ We see it worked, as `pmu` is now `false`.
It looks like this feature is limited to a configuration we do not
currently have.
-(4) Let's try probing CPU features for the Cortex-A15 CPU type::
+(4) Let's disable `sve` and see what happens to all the optional SVE
+vector lengths::
+
+ (QEMU) query-cpu-model-expansion type=full
model={"name":"max","props":{"sve":false}}
+ { "return": {
+"model": { "name": "max", "props": {
+"sve1664": false, "pmu": true, "sve1792": false, "sve1920": false,
+"sve128": false, "aarch64": true, "sve1024": false, "sve": false,
+"sve640": false, "sve768": false, "sve1408": false, "sve256": false,
+"sve1152": false, "sve512": false, "sve384": false, "sve1536": false,
+"sve896": false, "sve1280": false, "sve2048": false
+
+
+As expected they are now all `false`.
+
+(5) Let's try probing CPU features for the Cortex-A15 CPU type::
(QEMU) query-cpu-model-expansion type=full
[PATCH v8 0/9] target/arm/kvm: enable SVE in guests
Since Linux kernel v5.2-rc1 KVM has support for enabling SVE in guests. This series provides the QEMU bits for that enablement. First, we select existing CPU properties representing features we want to advertise in addition to the SVE vector lengths and prepare them for a qmp query. Then we introduce the qmp query, applying it immediately to those selected features. We also document ARM CPU features at this time. We next add a qtest for the selected CPU features that uses the qmp query for its tests - and we continue to add tests as we add CPU features with the following patches. So then, once we have the support we need for CPU feature querying and testing, we add our first SVE CPU feature property, 'sve', which just allows SVE to be completely enabled/disabled. Following that feature property, we add all 16 vector length properties along with the input validation they need and tests to prove the validation works. At this point the SVE features are still only for TCG, so we provide some patches to prepare for KVM and then a patch that allows the 'max' CPU type to enable SVE with KVM, but at first without vector length properties. After a bit more preparation we add the SVE vector length properties to the KVM-enabled 'max' CPU type along with the additional input validation and tests that that needs. Finally we allow the 'host' CPU type to also enjoy these properties by simply sharing them with it. v8: - Fixed another issue with the new make check tests. We weren't detecting kvm in a way that worked when running a cross-compiled aarch32 qemu on an aarch64 machine that had kvm. So now we detect kvm in a new, more robust way using the query-kvm qmp command. Besides some context changes after rebase, all the changes for this version are in 2/9, so I left all tags as they were. v7: - Fixed kvm32 tests and added a couple - Picked up r-b's from Beata and t-b's from Masa v6: - Adding missing visit_free() to an error path in qmp_query_cpu_model_expansion() in patch 1/9. - Rebased on latest master (applied cleanly) - Picked up r-b's from Richard and Eric v5: - Now generate an error if vector lengths have been explicitly enabled, but SVE is disabled - Fixed a bug in sve_zcr_len_for_el() - Fixed a bug in kvm_arch_put/get_sve() and brought back the put/get of FPSR/FPCR - A few document clarifications and added some new sentences - Added a couple more tests - Added BIT_ULL and use it in the test - Removed an unnecessary bitmap search - Moved a cpu_max_get_sve_max_vq() hunk from 4/9 to 3/9 and added a fix for it in 8/9 - Picked up some more tags from Eric v4: - Integrated Richard Henderson's rework for the sve property validation, in order to do all validating at finalize time and save several lines of code. - Fixed 'host' cpu SVE default. It was still off by default. - Cleaned up #ifdef's for sve_bswap64() - Removed redundant KVM_CAP_ARM_SVE extension check in kvm_arm_sve_get_vls() - Improved the KVM SVE qtest - Renamed sve to sve everywhere - Renamed power-of-2 to power-of-two everywhere - Picked up some more tags from Richard Thanks! drew Andrew Jones (9): target/arm/monitor: Introduce qmp_query_cpu_model_expansion tests: arm: Introduce cpu feature tests target/arm: Allow SVE to be disabled via a CPU property target/arm/cpu64: max cpu: Introduce sve properties target/arm/kvm64: Add kvm_arch_get/put_sve target/arm/kvm64: max cpu: Enable SVE when available target/arm/kvm: scratch vcpu: Preserve input kvm_vcpu_init features target/arm/cpu64: max cpu: Support sve properties with KVM target/arm/kvm: host cpu: Add support for sve properties docs/arm-cpu-features.rst | 317 ++ include/qemu/bitops.h | 1 + qapi/machine-target.json | 6 +- target/arm/cpu.c | 25 +- target/arm/cpu.h | 21 ++ target/arm/cpu64.c| 356 - target/arm/helper.c | 10 +- target/arm/kvm.c | 25 +- target/arm/kvm32.c| 6 +- target/arm/kvm64.c| 323 --- target/arm/kvm_arm.h | 39 +++ target/arm/monitor.c | 158 +++ tests/Makefile.include| 5 +- tests/arm-cpu-features.c | 540 ++ 14 files changed, 1775 insertions(+), 57 deletions(-) create mode 100644 docs/arm-cpu-features.rst create mode 100644 tests/arm-cpu-features.c -- 2.21.0 *** BLURB HERE *** Andrew Jones (9): target/arm/monitor: Introduce qmp_query_cpu_model_expansion tests: arm: Introduce cpu feature tests target/arm: Allow SVE to be disabled via a CPU property target/arm/cpu64: max cpu: Introduce sve properties target/arm/kvm64: Add kvm_arch_get/put_sve target/arm/kvm64: max cpu: Enable SVE when available target/arm/kvm: scratch vcpu: Preserve input kvm_vcpu_init features target/arm/cpu64: max cpu: Support sve properties with KVM target/arm/kvm: host cpu:
[PATCH v8 2/9] tests: arm: Introduce cpu feature tests
Now that Arm CPUs have advertised features lets add tests to ensure
we maintain their expected availability with and without KVM.
Signed-off-by: Andrew Jones
Reviewed-by: Eric Auger
---
tests/Makefile.include | 5 +-
tests/arm-cpu-features.c | 253 +++
2 files changed, 257 insertions(+), 1 deletion(-)
create mode 100644 tests/arm-cpu-features.c
diff --git a/tests/Makefile.include b/tests/Makefile.include
index 7715d8cd63ad..55f7bf9eef7c 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -262,6 +262,7 @@ check-qtest-sparc64-$(CONFIG_ISA_TESTDEV) =
tests/endianness-test$(EXESUF)
check-qtest-sparc64-y += tests/prom-env-test$(EXESUF)
check-qtest-sparc64-y += tests/boot-serial-test$(EXESUF)
+check-qtest-arm-y += tests/arm-cpu-features$(EXESUF)
check-qtest-arm-y += tests/microbit-test$(EXESUF)
check-qtest-arm-y += tests/m25p80-test$(EXESUF)
check-qtest-arm-y += tests/test-arm-mptimer$(EXESUF)
@@ -269,7 +270,8 @@ check-qtest-arm-y += tests/boot-serial-test$(EXESUF)
check-qtest-arm-y += tests/hexloader-test$(EXESUF)
check-qtest-arm-$(CONFIG_PFLASH_CFI02) += tests/pflash-cfi02-test$(EXESUF)
-check-qtest-aarch64-y = tests/numa-test$(EXESUF)
+check-qtest-aarch64-y += tests/arm-cpu-features$(EXESUF)
+check-qtest-aarch64-y += tests/numa-test$(EXESUF)
check-qtest-aarch64-y += tests/boot-serial-test$(EXESUF)
check-qtest-aarch64-y += tests/migration-test$(EXESUF)
# TODO: once aarch64 TCG is fixed on ARM 32 bit host, make test unconditional
@@ -841,6 +843,7 @@ tests/test-qapi-util$(EXESUF): tests/test-qapi-util.o
$(test-util-obj-y)
tests/numa-test$(EXESUF): tests/numa-test.o
tests/vmgenid-test$(EXESUF): tests/vmgenid-test.o tests/boot-sector.o
tests/acpi-utils.o
tests/cdrom-test$(EXESUF): tests/cdrom-test.o tests/boot-sector.o
$(libqos-obj-y)
+tests/arm-cpu-features$(EXESUF): tests/arm-cpu-features.o
tests/migration/stress$(EXESUF): tests/migration/stress.o
$(call quiet-command, $(LINKPROG) -static -O3 $(PTHREAD_LIB) -o $@ $<
,"LINK","$(TARGET_DIR)$@")
diff --git a/tests/arm-cpu-features.c b/tests/arm-cpu-features.c
new file mode 100644
index ..6ebb03d7ad67
--- /dev/null
+++ b/tests/arm-cpu-features.c
@@ -0,0 +1,253 @@
+/*
+ * Arm CPU feature test cases
+ *
+ * Copyright (c) 2019 Red Hat Inc.
+ * Authors:
+ * Andrew Jones
+ *
+ * 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 "libqtest.h"
+#include "qapi/qmp/qdict.h"
+#include "qapi/qmp/qjson.h"
+
+#define MACHINE "-machine virt,gic-version=max,accel=tcg "
+#define MACHINE_KVM "-machine virt,gic-version=max,accel=kvm:tcg "
+#define QUERY_HEAD "{ 'execute': 'query-cpu-model-expansion', " \
+" 'arguments': { 'type': 'full', "
+#define QUERY_TAIL "}}"
+
+static bool kvm_enabled(QTestState *qts)
+{
+QDict *resp, *qdict;
+bool enabled;
+
+resp = qtest_qmp(qts, "{ 'execute': 'query-kvm' }");
+g_assert(qdict_haskey(resp, "return"));
+qdict = qdict_get_qdict(resp, "return");
+g_assert(qdict_haskey(qdict, "enabled"));
+enabled = qdict_get_bool(qdict, "enabled");
+qobject_unref(resp);
+
+return enabled;
+}
+
+static QDict *do_query_no_props(QTestState *qts, const char *cpu_type)
+{
+return qtest_qmp(qts, QUERY_HEAD "'model': { 'name': %s }"
+ QUERY_TAIL, cpu_type);
+}
+
+static QDict *do_query(QTestState *qts, const char *cpu_type,
+ const char *fmt, ...)
+{
+QDict *resp;
+
+if (fmt) {
+QDict *args;
+va_list ap;
+
+va_start(ap, fmt);
+args = qdict_from_vjsonf_nofail(fmt, ap);
+va_end(ap);
+
+resp = qtest_qmp(qts, QUERY_HEAD "'model': { 'name': %s, "
+"'props': %p }"
+ QUERY_TAIL, cpu_type, args);
+} else {
+resp = do_query_no_props(qts, cpu_type);
+}
+
+return resp;
+}
+
+static const char *resp_get_error(QDict *resp)
+{
+QDict *qdict;
+
+g_assert(resp);
+
+qdict = qdict_get_qdict(resp, "error");
+if (qdict) {
+return qdict_get_str(qdict, "desc");
+}
+
+return NULL;
+}
+
+#define assert_error(qts, cpu_type, expected_error, fmt, ...) \
+({ \
+QDict *_resp; \
+const char *_error;\
+ \
+_resp = do_query(qts, cpu_type, fmt, ##__VA_ARGS__); \
+g_assert(_resp); \
+_error = resp_get_error(_resp);\
+g_assert(_error); \
+g_assert(g_str_equal(_error,
Re: [PATCH v2] smb daemon get additional command line parameters from env variable
Hello,
Many thanks Laurent,
This is the version 2 of this patch, has been modified according to
the qemu guidelines.
**
From: Jordi Pujol Palomer
Date: Thu, 31 Oct 2019 14:31:14 +0200
Subject: [PATCH v2] QEMU samba daemon: additional command line options
The smbd daemon takes additional command line options
from environment variable SMBDOPTIONS.
Set the environment variable SMBDOPTIONS before executing qemu.
Example:
export SMBDOPTIONS="--option='server min protocol=CORE' -d 4"
Signed-off-by: Jordi Pujol Palomer
---
--- qemu-4.1-a/net/slirp.c
+++ qemu_4.1-b/net/slirp.c
@@ -909,6 +909,12 @@ static int slirp_smb(SlirpState* s, cons
CONFIG_SMBD_COMMAND, s->smb_dir, smb_conf);
g_free(smb_conf);
+char *options = g_strdup(g_getenv("SMBDOPTIONS"));
+if (options) {
+smb_cmdline = g_strdup_printf("%s %s", smb_cmdline, options);
+}
+g_free(options);
+
if (slirp_add_exec(s->slirp, smb_cmdline, _addr, 139) < 0 ||
slirp_add_exec(s->slirp, smb_cmdline, _addr, 445) < 0) {
slirp_smb_cleanup(s);
--- qemu-4.1-a/slirp/src/misc.c 2019-10-29 14:40:15.043120941 +0100
+++ qemu-4.1-b/slirp/src/misc.c 2019-10-29 14:41:04.440235684 +0100
@@ -168,7 +168,9 @@ g_spawn_async_with_fds_slirp(const gchar
int fork_exec(struct socket *so, const char *ex)
{
GError *err = NULL;
-char **argv;
+gint argc = 0;
+gchar **argv = NULL;
+gboolean ret;
int opt, sp[2];
DEBUG_CALL("fork_exec");
@@ -179,7 +181,13 @@ int fork_exec(struct socket *so, const c
return 0;
}
-argv = g_strsplit(ex, " ", -1);
+ret = g_shell_parse_argv(ex, , , );
+if (err) {
+g_critical("fork_exec invalid command: %s", err->message);
+g_error_free(err);
+return 0;
+}
+
g_spawn_async_with_fds(NULL /* cwd */, argv, NULL /* env */,
G_SPAWN_SEARCH_PATH, fork_exec_child_setup,
NULL /* data */, NULL /* child_pid */, sp[1], sp[1],
**
Thanks,
Jordi Pujol
Re: RFC: New device for zero-copy VM memory access
On 2019-11-01 00:24, Dr. David Alan Gilbert wrote: * ge...@hostfission.com (ge...@hostfission.com) wrote: Hi Dave, On 2019-10-31 05:52, Dr. David Alan Gilbert wrote: > * ge...@hostfission.com (ge...@hostfission.com) wrote: > > Hi All, > > > > Over the past week, I have been working to come up with a solution > > to the > > memory transfer performance issues that hinder the Looking Glass > > Project. > > > > Currently Looking Glass works by using the IVSHMEM shared memory > > device > > which > > is fed by an application that captures the guest's video output. > > While this > > works it is sub-optimal because we first have to perform a CPU copy > > of the > > captured frame into shared RAM, and then back out again for display. > > Because > > the destination buffers are allocated by closed proprietary code > > (DirectX, > > or > > NVidia NvFBC) there is no way to have the frame placed directly into > > the > > IVSHMEM shared ram. > > > > This new device, currently named `introspection` (which needs a more > > suitable > > name, porthole perhaps?), provides a means of translating guest > > physical > > addresses to host virtual addresses, and finally to the host offsets > > in RAM > > for > > file-backed memory guests. It does this by means of a simple > > protocol over a > > unix socket (chardev) which is supplied the appropriate fd for the > > VM's > > system > > RAM. The guest (in this case, Windows), when presented with the > > address of a > > userspace buffer and size, will mlock the appropriate pages into RAM > > and > > pass > > guest physical addresses to the virtual device. > > Hi Geroggrey, > I wonder if the same thing can be done by using the existing > vhost-user > mechanism. > > vhost-user is intended for implementing a virtio device outside of the > qemu process; so it has a character device that qemu passes commands > down > to the other process, where qemu mostly passes commands via the virtio > queues. To be able to read the virtio queues, the external process > mmap's the same memory as the guest - it gets passed a 'set mem table' > command by qemu that includes fd's for the RAM, and includes base/offset > pairs saying that a particular chunk of RAM is mapped at a particular > guest physical address. > > Whether or not you make use of virtio queues, I think the mechanism > for the device to tell the external process the mappings might be what > you're after. > > Dave > While normally I would be all for re-using such code, the vhost-user while being very feature-complete from what I understand is overkill for our requirements. It will still allocate a communication ring and an events system that we will not be using. The goal of this device is to provide a dumb & simple method of sharing system ram, both for this project and for others that work on a simple polling mechanism, it is not intended to be an end-to-end solution like vhost-user is. If you still believe that vhost-user should be used, I will do what I can to implement it, but for such a simple device I honestly believe it is overkill. It's certainly worth having a look at vhost-user even if you don't use most of it; you can configure it down to 1 (maybe 0?) queues if you're really desperate - and you might find it comes in useful! The actual setup is pretty easy. The process of synchronising with (potentially changing) host memory mapping is a bit hairy; so if we can share it with vhost it's probably worth it. Thanks, I will have a deeper dive into it, however the issues with changing host memory, migration, and all that extra is of no concern or use to us. The audience that will be using this interface is not interested in such features as the primary reason for Looking Glass is to allow a for high-performance windows workstation for gaming and proprietary windows only software. In these scenarios features like ram ballooning are avoided like the plague as it hampers performance for use cases that require consistent low latency for competitive gameplay. As the author of Looking Glass, I also have to consider the maintenance and the complexity of implementing the vhost protocol into the project. At this time a complete Porthole client can be implemented in 150 lines of C without external dependencies, and most of that is boilerplate socket code. This IMO is a major factor in deciding to avoid vhost-user. I also have to weigh up the cost of developing and maintaining the windows driver for this device. I am very green when it comes to Windows driver programming, it took weeks to write the first IVSHMEM driver, and several days to write the Porthole driver which is far simpler than the IVSHMEM driver. I'd hate to think of the time investment in maintaining the vhost integration also (yes, I am aware there is a library). These drivers are not complex and I am sure an experienced windows driver developer could have thrown them together in a few hours, but since our requirements are so niche and
RE: [RFC v2 00/22] intel_iommu: expose Shared Virtual Addressing to VM
> From: Jason Wang [mailto:jasow...@redhat.com] > Sent: Thursday, October 31, 2019 5:33 AM > Subject: Re: [RFC v2 00/22] intel_iommu: expose Shared Virtual Addressing to > VM > > > On 2019/10/25 下午6:12, Tian, Kevin wrote: > >> From: Jason Wang [mailto:jasow...@redhat.com] > >> Sent: Friday, October 25, 2019 5:49 PM > >> > >> > >> On 2019/10/24 下午8:34, Liu Yi L wrote: > >>> Shared virtual address (SVA), a.k.a, Shared virtual memory (SVM) on > >>> Intel platforms allow address space sharing between device DMA and > >> applications. > >> > >> > >> Interesting, so the below figure demonstrates the case of VM. I > >> wonder how much differences if we compare it with doing SVM between > >> device and an ordinary process (e.g dpdk)? > >> > >> Thanks > > One difference is that ordinary process requires only stage-1 > > translation, while VM requires nested translation. > > > A silly question, then I believe there's no need for VFIO DMA API in this > case consider > the page table is shared between MMU and IOMMU? Echo Kevin's reply. We use nested translation here. For stage-1, yes, no need to use VFIO DMA API. For stage-2, we still use VFIO DMA API to program the GPA->HPA mapping to host. :-) Regards, Yi Liu > > Thanks > > >
Re: [PATCH v1 1/1] hw/arm/boot: Rebuild hflags when modifying CPUState at boot
On 10/31/19 5:08 AM, Edgar E. Iglesias wrote: Rebuild hflags when modifying CPUState at boot. Fixes: e979972a6a Signed-off-by: Edgar E. Iglesias --- hw/arm/boot.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/arm/boot.c b/hw/arm/boot.c index c264864c11..ef6724960c 100644 --- a/hw/arm/boot.c +++ b/hw/arm/boot.c @@ -786,6 +786,7 @@ static void do_cpu_reset(void *opaque) info->secondary_cpu_reset_hook(cpu, info); } } +arm_rebuild_hflags(env); } } Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH v6 4/4] tests/vm: update netbsd to version 8.1
On 10/31/19 9:53 AM, Gerd Hoffmann wrote: Signed-off-by: Gerd Hoffmann --- tests/vm/netbsd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/vm/netbsd b/tests/vm/netbsd index d1bfd0..33779402dd 100755 --- a/tests/vm/netbsd +++ b/tests/vm/netbsd @@ -22,7 +22,7 @@ class NetBSDVM(basevm.BaseVM): name = "netbsd" arch = "x86_64" -link = "https://cdn.netbsd.org/pub/NetBSD/NetBSD-8.0/images/NetBSD-8.0-amd64.iso; +link = "https://cdn.netbsd.org/pub/NetBSD/NetBSD-8.1/images/NetBSD-8.1-amd64.iso; size = "20G" pkgs = [ # tools Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH v6 3/4] tests/vm: use console_consume for netbsd
On 10/31/19 9:53 AM, Gerd Hoffmann wrote:
Use new helper to read all pending console output,
not just a single char. Unblocks installer boot.
Signed-off-by: Gerd Hoffmann
---
tests/vm/netbsd | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/vm/netbsd b/tests/vm/netbsd
index 5e04dcd9b1..d1bfd0 100755
--- a/tests/vm/netbsd
+++ b/tests/vm/netbsd
@@ -93,7 +93,7 @@ class NetBSDVM(basevm.BaseVM):
Why not use this by default for everything?
Anyway,
Reviewed-by: Philippe Mathieu-Daudé
for char in list("5consdev com0\n"):
time.sleep(0.2)
self.console_send(char)
-self.console_wait("")
+self.console_consume()
self.console_wait_send("> ", "boot\n")
self.console_wait_send("Terminal type","xterm\n")
[PATCH] tests/boot_linux_console: Fetch assets from Debian snapshot archives
The kernel packaged was fetched from an unstable repository.
Use the stable snapshot archive instead.
Signed-off-by: Philippe Mathieu-Daudé
---
tests/acceptance/boot_linux_console.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tests/acceptance/boot_linux_console.py
b/tests/acceptance/boot_linux_console.py
index 4e9ac0ecc3..f5aa87317c 100644
--- a/tests/acceptance/boot_linux_console.py
+++ b/tests/acceptance/boot_linux_console.py
@@ -479,7 +479,8 @@ class BootLinuxConsole(Test):
:avocado: tags=arch:m68k
:avocado: tags=machine:q800
"""
-deb_url = ('http://ftp.ports.debian.org/debian-ports/pool-m68k/main'
+deb_url = ('https://snapshot.debian.org/archive/debian-ports'
+ '/20190922T090906Z/pool-m68k/main'
'/l/linux/kernel-image-5.2.0-2-m68k-di_5.2.9-2_m68k.udeb')
deb_hash = '0797e05129595f22f3c0142db5e199769a723bf9'
deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash)
--
2.21.0
Re: [PATCH v6 2/4] tests/vm: add console_consume helper
On 10/31/19 9:53 AM, Gerd Hoffmann wrote:
Helper function to read all console output.
Signed-off-by: Gerd Hoffmann
---
tests/vm/basevm.py | 19 +++
1 file changed, 19 insertions(+)
diff --git a/tests/vm/basevm.py b/tests/vm/basevm.py
index 2929de23aa..086bfb2c66 100755
--- a/tests/vm/basevm.py
+++ b/tests/vm/basevm.py
@@ -242,6 +242,25 @@ class BaseVM(object):
return False
return True
+def console_consume(self):
+vm = self._guest
+output = ""
+vm.console_socket.setblocking(0)
+while True:
+try:
+chars = vm.console_socket.recv(1)
+except:
+break
+output += chars.decode("latin1")
I don't know enough decode(), but I'm very happy with the rest of
the patch, thanks a lot for fixing this long standing issue Gerd!
Reviewed-by: Philippe Mathieu-Daudé
+if "\r" in output or "\n" in output:
+lines = re.split("[\r\n]", output)
+output = lines.pop()
+if self.debug:
+self.console_log("\n".join(lines))
+if self.debug:
+self.console_log(output)
+vm.console_socket.setblocking(1)
+
def console_send(self, command):
vm = self._guest
if self.debug:
Re: [libvirt] [PULL 0/9] Ide patches
Patchew URL: https://patchew.org/QEMU/20191031105904.12194-1-js...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [libvirt] [PULL 0/9] Ide patches
Type: series
Message-id: 20191031105904.12194-1-js...@redhat.com
=== 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 ===
Switched to a new branch 'test'
d278ccf hd-geo-test: Add tests for lchs override
28807d7 bootdevice: FW_CFG interface for LCHS values
11f27f1 bootdevice: Refactor get_boot_devices_list
e032fef bootdevice: Gather LCHS from all relevant devices
74eb334 scsi: Propagate unrealize() callback to scsi-hd
e211495 bootdevice: Add interface to gather LCHS
a683977 block: Support providing LCHS from user
071ac63 block: Refactor macros - fix tabbing
90e6789 IDE: deprecate ide-drive
=== OUTPUT BEGIN ===
1/9 Checking commit 90e67898e3b9 (IDE: deprecate ide-drive)
2/9 Checking commit 071ac63ed092 (block: Refactor macros - fix tabbing)
ERROR: Macros with complex values should be enclosed in parenthesis
#58: FILE: include/hw/block/block.h:65:
+#define DEFINE_BLOCK_CHS_PROPERTIES(_state, _conf) \
+DEFINE_PROP_UINT32("cyls", _state, _conf.cyls, 0), \
+DEFINE_PROP_UINT32("heads", _state, _conf.heads, 0),\
DEFINE_PROP_UINT32("secs", _state, _conf.secs, 0)
total: 1 errors, 0 warnings, 37 lines checked
Patch 2/9 has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
3/9 Checking commit a68397755180 (block: Support providing LCHS from user)
4/9 Checking commit e21149531919 (bootdevice: Add interface to gather LCHS)
5/9 Checking commit 74eb33489f71 (scsi: Propagate unrealize() callback to
scsi-hd)
6/9 Checking commit e032fefe3098 (bootdevice: Gather LCHS from all relevant
devices)
7/9 Checking commit 11f27f1f9e10 (bootdevice: Refactor get_boot_devices_list)
8/9 Checking commit 28807d78bb01 (bootdevice: FW_CFG interface for LCHS values)
9/9 Checking commit d278ccfd1965 (hd-geo-test: Add tests for lchs override)
WARNING: Block comments use a leading /* on a separate line
#607: FILE: tests/hd-geo-test.c:965:
+ "skipping hd-geo/override/* tests");
total: 0 errors, 1 warnings, 578 lines checked
Patch 9/9 has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
=== OUTPUT END ===
Test command exited with code: 1
The full log is available at
http://patchew.org/logs/20191031105904.12194-1-js...@redhat.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com
[Bug 1847793] Re: qemu 4.1.0 - Corrupt guest filesystem after new vm install
Sorry for the delay,I was busy doing my job the last two weeks. I use XFS V5 on both main host (5.3.7-arch1-2-ARCH) and backup host (5.3.5-arch1-1-ARCH). It seems I ran in the first bug that has been fixed upstream. With git master (git clone at 18.10.) I could not reproduce the failure on my backup host. I installed an RedHat 7.6 VM as always and the VM works without any errors. The only thing I noticed was, the first boot after installation lasts longer as with qemu 4.0.0. After this I checked the archlinux repositories an found in AUR the qemu-git package. I removed the official qemu packages from my main host and installed this (qemu-git 8:v4.1.0.r1699.gf9bec78137-1). The behavior is the same as on the backup host, the VM installation works without any errors as well as additional tasks (i. e. complete the basic installation to an full desktop installation). The last days I used the main hosts with this package for my daily work. At the end of the day I checked the filesystems from the used existing, or new created VMs and didn't found any errors. May be for archlinux user who needs the 4.1.0 qemu version the qemu-git package from AUR is a possible workaround. Claus -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1847793 Title: qemu 4.1.0 - Corrupt guest filesystem after new vm install Status in QEMU: New Bug description: When I install a new vm with qemu 4.1.0 all the guest filesystems are corrupt. The first boot from the install dvd iso is ok and the installer work fine. But the guest system hangs after the installer finishes and I reboot the guest. I can see the grub boot menue but the system cannot load the initramfs. Testet with: - RedHat Enterprise Linux 7.5, 7.6 and 7.7 (RedHat uses xfs for the /boot and / partition) Guided install with the graphical installer, no lvm selected. - Debian Stable/Buster (Debian uses ext4 for / and /home partition) Guidet install with the graphical installer and default options. Used commandline to create the vm disk image: qemu-img create -f qcow2 /volumes/disk2-part2/vmdisks/vmtest10-1.qcow2 20G Used qemu commandline for vm installation: #!/bin/sh # vmtest10 Installation # /usr/bin/qemu-system-x86_64 -cpu SandyBridge-IBRS \ -soundhw hda \ -M q35 \ -k de \ -vga qxl \ -machine accel=kvm \ -m 4096 \ -display gtk \ -drive file=/volumes/disk2-part2/images/debian-10.0.0-amd64-DVD-1.iso,if=ide,media=cdrom \ -drive file=/volumes/disk2-part2/images/vmtest10-1.qcow2,if=virtio,media=disk,cache=writeback \ -boot once=d,menu=off \ -device virtio-net-pci,mac=52:54:00:2c:02:6c,netdev=vlan0 \ -netdev bridge,br=br0,id=vlan0 \ -rtc base=localtime \ -name "vmtest10" \ -usb -device usb-tablet \ -spice disable-ticketing \ -device virtio-serial-pci \ -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 \ -chardev spicevmc,id=spicechannel0,name=vdagent $* Host OS: Archlinux (last updated at 10.10.2019) Linux testing 5.3.5-arch1-1-ARCH #1 SMP PREEMPT Mon Oct 7 19:03:08 UTC 2019 x86_64 GNU/Linux No libvirt in use. With qemu 4.0.0 it works fine without any errors. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1847793/+subscriptions
Re: [PATCH] fw_cfg: Allow reboot-timeout=-1 again
* Han Han (h...@redhat.com) wrote:
> However, another important question is: how can we avoid such undocumented
> incompatibility appears again?
The reboot-timeout one was accidental - it was a documented qemu
feature; just no one noticed it when the input check was added.
Officially if we actually want to deprecate a feature we should actually
follow qemu's deprecation guidelines.
> I can show another case caused by such incompatibile change:
> https://bugzilla.redhat.com/show_bug.cgi?id=1745868#c0
>
> For the qemu devices, attributes, values, qmp cmds, qmp cmds arguments used
> by libvirt, could we get a way to inform libvirt
> that an incompatibile qemu change is coming, please update libvirt code
> ASAP to adjust to that change?
> Or another way that is more gently: popping up the warning of depreciation
> instead of dropping it, and then drop it in the version
> after next version.
Yes that should happen; with deprecated devices it's easier than more
subtle features like command line things; I'm not sure how that gets
introspected. I thought libvirt already asked qemu for a list of
devices, so I'm confused why libvirt didn't spot it before starting the
VM in 1745868.
Dave
>
> On Tue, Oct 29, 2019 at 1:59 PM Dr. David Alan Gilbert
> wrote:
>
> > * Markus Armbruster (arm...@redhat.com) wrote:
> > > "Dr. David Alan Gilbert" writes:
> > >
> > > > * Markus Armbruster (arm...@redhat.com) wrote:
> > > >> "Dr. David Alan Gilbert (git)" writes:
> > > >>
> > > >> > From: "Dr. David Alan Gilbert"
> > > >> >
> > > >> > Commit ee5d0f89de3e53cdb0dc added range checking on reboot-timeout
> > > >> > to only allow the range 0..65535; however both qemu and libvirt
> > document
> > > >> > the special value -1 to mean don't reboot.
> > > >> > Allow it again.
> > > >> >
> > > >> > Fixes: ee5d0f89de3e53cdb0dc ("fw_cfg: Fix -boot reboot-timeout
> > error checking")
> > > >> > RH bz: https://bugzilla.redhat.com/show_bug.cgi?id=1765443
> > > >> > Signed-off-by: Dr. David Alan Gilbert
> > > >> > ---
> > > >> > hw/nvram/fw_cfg.c | 5 +++--
> > > >> > 1 file changed, 3 insertions(+), 2 deletions(-)
> > > >> >
> > > >> > diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
> > > >> > index 7dc3ac378e..1a9ec44232 100644
> > > >> > --- a/hw/nvram/fw_cfg.c
> > > >> > +++ b/hw/nvram/fw_cfg.c
> > > >> > @@ -247,10 +247,11 @@ static void fw_cfg_reboot(FWCfgState *s)
> > > >> >
> > > >> > if (reboot_timeout) {
> > > >> > rt_val = qemu_opt_get_number(opts, "reboot-timeout", -1);
> > > >> > +
> > > >> > /* validate the input */
> > > >> > -if (rt_val < 0 || rt_val > 0x) {
> > > >> > +if (rt_val < -1 || rt_val > 0x) {
> > > >> > error_report("reboot timeout is invalid,"
> > > >> > - "it should be a value between 0 and
> > 65535");
> > > >> > + "it should be a value between -1 and
> > 65535");
> > > >> > exit(1);
> > > >> > }
> > > >> > }
> > > >>
> > > >> Semantic conflict with "PATCH] qemu-options.hx: Update for
> > > >> reboot-timeout parameter", Message-Id:
> > > >> <20191015151451.727323-1-h...@redhat.com>.
> > > >
> > > > Thanks for spotting that.
> > > > I think Han and also submitted patches to review it from libvirt
> > > > and it wasn't obvious what to do. (Cc'd Han in).
> > > >
> > > >> I'm too tired right now to risk an opinion on which one we want.
> > > >
> > > > As is everyone else ! The problem here is that its documented
> > > > as a valid thing to do, and libvirt does it, and you might have
> > > > a current XML file that did it. Now I think you could change libvirt
> > > > to omit the reboot-timeout parameter if it was called with -1.
> > > >
> > > > So given its a documented thing in both qemu and libvirt xml
> > > > if we want to remove it then it sohuld be deprecated properly - but
> > it's
> > > > already broken.
> > >
> > > Since commit ee5d0f89d, v4.0.0.
> > >
> > > If that commit had not made it into a release, we'd certainly treat the
> > > loss of "-1 means don't reboot" as regression.
> > >
> > > But it has. We can treat it as a regression anyway. We can also
> > > declare "ship has sailed".
> > >
> > > I'm leaning towads the former.
> > >
> > > If we restore "-1 means don't reboot", then I don't see a need to
> > > deprecate it. Just keep it.
> > >
> > > What do you think?
> >
> > That's also my view; especially since the problem seems to be an easy
> > fix.
> >
> > Dave
> >
> > --
> > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
> >
>
>
> --
> Best regards,
> ---
> Han Han
> Quality Engineer
> Redhat.
>
> Email: h...@redhat.com
> Phone: +861065339333
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: RFC: New device for zero-copy VM memory access
* ge...@hostfission.com (ge...@hostfission.com) wrote: > Hi Dave, > > On 2019-10-31 05:52, Dr. David Alan Gilbert wrote: > > * ge...@hostfission.com (ge...@hostfission.com) wrote: > > > Hi All, > > > > > > Over the past week, I have been working to come up with a solution > > > to the > > > memory transfer performance issues that hinder the Looking Glass > > > Project. > > > > > > Currently Looking Glass works by using the IVSHMEM shared memory > > > device > > > which > > > is fed by an application that captures the guest's video output. > > > While this > > > works it is sub-optimal because we first have to perform a CPU copy > > > of the > > > captured frame into shared RAM, and then back out again for display. > > > Because > > > the destination buffers are allocated by closed proprietary code > > > (DirectX, > > > or > > > NVidia NvFBC) there is no way to have the frame placed directly into > > > the > > > IVSHMEM shared ram. > > > > > > This new device, currently named `introspection` (which needs a more > > > suitable > > > name, porthole perhaps?), provides a means of translating guest > > > physical > > > addresses to host virtual addresses, and finally to the host offsets > > > in RAM > > > for > > > file-backed memory guests. It does this by means of a simple > > > protocol over a > > > unix socket (chardev) which is supplied the appropriate fd for the > > > VM's > > > system > > > RAM. The guest (in this case, Windows), when presented with the > > > address of a > > > userspace buffer and size, will mlock the appropriate pages into RAM > > > and > > > pass > > > guest physical addresses to the virtual device. > > > > Hi Geroggrey, > > I wonder if the same thing can be done by using the existing > > vhost-user > > mechanism. > > > > vhost-user is intended for implementing a virtio device outside of the > > qemu process; so it has a character device that qemu passes commands > > down > > to the other process, where qemu mostly passes commands via the virtio > > queues. To be able to read the virtio queues, the external process > > mmap's the same memory as the guest - it gets passed a 'set mem table' > > command by qemu that includes fd's for the RAM, and includes base/offset > > pairs saying that a particular chunk of RAM is mapped at a particular > > guest physical address. > > > > Whether or not you make use of virtio queues, I think the mechanism > > for the device to tell the external process the mappings might be what > > you're after. > > > > Dave > > > > While normally I would be all for re-using such code, the vhost-user while > being very feature-complete from what I understand is overkill for our > requirements. It will still allocate a communication ring and an events > system > that we will not be using. The goal of this device is to provide a dumb & > simple method of sharing system ram, both for this project and for others > that > work on a simple polling mechanism, it is not intended to be an end-to-end > solution like vhost-user is. > > If you still believe that vhost-user should be used, I will do what I can to > implement it, but for such a simple device I honestly believe it is > overkill. It's certainly worth having a look at vhost-user even if you don't use most of it; you can configure it down to 1 (maybe 0?) queues if you're really desperate - and you might find it comes in useful! The actual setup is pretty easy. The process of synchronising with (potentially changing) host memory mapping is a bit hairy; so if we can share it with vhost it's probably worth it. Dave > -Geoff > > > > This device and the windows driver have been designed in such a way > > > that > > > it's a > > > utility device for any project and/or application that could make > > > use of it. > > > The PCI subsystem vendor and device ID are used to provide a means > > > of device > > > identification in cases where multiple devices may be in use for > > > differing > > > applications. This also allows one common driver to be used for any > > > other > > > projects wishing to build on this device. > > > > > > My ultimate goal is to get this to a state where it could be accepted > > > upstream > > > into Qemu at which point Looking Glass would be modified to use it > > > instead > > > of > > > the IVSHMEM device. > > > > > > My git repository with the new device can be found at: > > > https://github.com/gnif/qemu > > > > > > The new device is: > > > https://github.com/gnif/qemu/blob/master/hw/misc/introspection.c > > > > > > Looking Glass: > > > https://looking-glass.hostfission.com/ > > > > > > The windows driver, while working, needs some cleanup before the > > > source is > > > published. I intend to maintain both this device and the windows > > > driver > > > including producing a signed Windows 10 driver if Redhat are > > > unwilling or > > > unable. > > > > > > Kind Regards, > > > Geoffrey McRae > > > > > > HostFission > > > https://hostfission.com > > > > > -- > >
Re: [PATCH 00/30] virtiofs daemon (base)
* Michael S. Tsirkin (m...@redhat.com) wrote: > On Wed, Oct 30, 2019 at 10:47:00AM +, Dr. David Alan Gilbert wrote: > > * Michael S. Tsirkin (m...@redhat.com) wrote: > > > On Mon, Oct 21, 2019 at 11:58:02AM +0100, Dr. David Alan Gilbert (git) > > > wrote: > > > > From: "Dr. David Alan Gilbert" > > > > > > > > Hi, > > > > This is the 1st set for the virtiofsd - a daemon > > > > that implements the user space side of virtiofs. > > > > > > > > The kernel and qemu device parts recently went in, > > > > so the daemon is the only thing missing to have a working > > > > set. > > > > > > > > > So I went back and forth on this but this is huge > > > and there's not a lot of time for review. > > > So I parked it + the security patches on a next branch in my tree. > > > I will rebase once after rc1 is out, and then stop. > > > > Thanks; I'll work on the extra sets that can go later (the > > threading and cleanups+fixes). > > > > Dave > > > Apropos I would really like to figure out > a better way to know that we did not miss > anything when adding the security patchset. Yep, it's worth at least having a lot of eyes on it, and better finding some more automation for the path checking. Dave > > > > > > > > This set is the absolute minimal base set of patches; > > > > it's not yet safe to use (from security or correctness); > > > > > > > > I'll follow up with ~3 more series in the next few days > > > > with: > > > > > > > > a) Security patches that add sandboxing and checking > > > >compared with normal fuse - that makes it safe. > > > > b) Performance improvements including threading > > > > c) Other fixes, including correctness. > > > > > > > > but, this is a good start and gets things rolling. > > > > > > > > The set pulls in a big chunk of the upstream libfuse library > > > > (unmodified so that it's easy to check it really is upstream), > > > > chops all the stuff out we don't need and then adds the > > > > new transport we need. > > > > > > > > For new files I've formatted the code according to qemu > > > > standards; for files that are from upstream libfuse > > > > I've kept with their standards for ease of future updating. > > > > > > > > We can't just link with libfuse, since we have to make ABI incompatible > > > > changes for the new transport. > > > > > > > > Running this daemon is typically done with: > > > > > > > >./virtiofsd -o vhost_user_socket=/path/socket -o source=/path/to/fs > > > > > > > > connected to a qemu that's then started with: > > > >-chardev socket,id=char0,path=/path/socket -device > > > > vhost-user-fs-pci,queue-size=1024,chardev=char0,tag=myfs > > > > > > > > and then in the guest mount with: > > > >mount -t virtiofs myfs /mnt > > > > > > > > Our development branch is: > > > > https://gitlab.com/virtio-fs/qemu/tree/virtio-fs-dev > > > > > > > > Dave > > > > > > > > > > > > Dr. David Alan Gilbert (22): > > > > virtiofsd: Pull in upstream headers > > > > virtiofsd: Pull in kernel's fuse.h > > > > virtiofsd: Add auxiliary .c's > > > > virtiofsd: Add fuse_lowlevel.c > > > > virtiofsd: Add passthrough_ll > > > > virtiofsd: Trim down imported files > > > > virtiofsd: Fix fuse_daemonize ignored return values > > > > virtiofsd: Fix common header and define for QEMU builds > > > > virtiofsd: fuse: Make iov_length usable outside fuse_lowlevel.c > > > > virtiofsd: Add options for virtio > > > > virtiofsd: Open vhost connection instead of mounting > > > > virtiofsd: Start wiring up vhost-user > > > > virtiofsd: Add main virtio loop > > > > virtiofsd: get/set features callbacks > > > > virtiofsd: Start queue threads > > > > virtiofsd: Poll kick_fd for queue > > > > virtiofsd: Start reading commands from queue > > > > virtiofsd: Send replies to messages > > > > virtiofsd: Keep track of replies > > > > virtiofsd: Add Makefile wiring for virtiofsd contrib > > > > virtiofsd: Fast path for virtio read > > > > virtiofs: Add maintainers entry > > > > > > > > Stefan Hajnoczi (7): > > > > virtiofsd: remove mountpoint dummy argument > > > > virtiofsd: remove unused notify reply support > > > > virtiofsd: add -o source=PATH to help output > > > > virtiofsd: add --fd=FDNUM fd passing option > > > > virtiofsd: make -f (foreground) the default > > > > virtiofsd: add vhost-user.json file > > > > virtiofsd: add --print-capabilities option > > > > > > > > Vivek Goyal (1): > > > > virtiofsd: Make fsync work even if only inode is passed in > > > > > > > > .gitignore |1 + > > > > MAINTAINERS |8 + > > > > Makefile|9 + > > > > Makefile.objs |1 + > > > > contrib/virtiofsd/50-qemu-virtiofsd.json.in |5 + > > > > contrib/virtiofsd/Makefile.objs | 10 + > > > > contrib/virtiofsd/buffer.c | 318 +++ > > > >
Re: [PATCH 0/1] BZ#1751431:guest-get-memory-block-info is not supported
PING On Thu, Oct 17, 2019 at 3:34 PM Basil Salman wrote: > From: Basil Salman > > "guest-get-memory-block-info" is enabled according to "get-info" output, > while the command is only supported for linux with sysfs. > > "guest-get-memory-block-info" command was added to blacklist. > > Basil Salman (1): > qga: Add "guest-get-memory-block-info" to blacklist > > qga/commands-posix.c | 3 ++- > qga/commands-win32.c | 2 +- > 2 files changed, 3 insertions(+), 2 deletions(-) > > -- > 2.17.2 > >
Re: [PATCH v3] qcow2-bitmap: Fix uint64_t left-shift overflow
30.10.2019 14:46, Tuguoyi wrote:
> There are two issues in In check_constraints_on_bitmap(),
> 1) The sanity check on the granularity will cause uint64_t
> integer left-shift overflow when cluster_size is 2M and the
> granularity is BIGGER than 32K.
> 2) The way to calculate image size that the maximum bitmap
> supported can map to is a bit incorrect.
> This patch fix it by add a helper function to calculate the
> number of bytes needed by a normal bitmap in image and compare
> it to the maximum bitmap bytes supported by qemu.
>
> Signed-off-by: Guoyi Tu
Please, where possible, mention commit where bug was introduced in
commit message. Also, add qemu-sta...@nongnu.org to CC when fixing
released bugs.
Fixes: 5f72826e7fc62167cf3a
Reviewed-by: Vladimir Sementsov-Ogievskiy
Thanks for fixing!
> ---
> block/qcow2-bitmap.c | 15 ---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/block/qcow2-bitmap.c b/block/qcow2-bitmap.c
> index 98294a7..34935bb 100644
> --- a/block/qcow2-bitmap.c
> +++ b/block/qcow2-bitmap.c
> @@ -142,6 +142,14 @@ static int check_table_entry(uint64_t entry, int
> cluster_size)
> return 0;
> }
>
> +static inline int64_t get_bitmap_bytes_needed(int64_t len,
AFAIK "inline" is no-op in this context, compiler will most probably inline it
anyway,
and "inline" word don't influence on this probability. So, better drop it.
> + uint32_t granularity)
> +{
> +int64_t num_bits = DIV_ROUND_UP(len, granularity);
> +
> +return DIV_ROUND_UP(num_bits, 8);
> +}
> +
> static int check_constraints_on_bitmap(BlockDriverState *bs,
> const char *name,
> uint32_t granularity,
> @@ -150,6 +158,7 @@ static int check_constraints_on_bitmap(BlockDriverState
> *bs,
> BDRVQcow2State *s = bs->opaque;
> int granularity_bits = ctz32(granularity);
> int64_t len = bdrv_getlength(bs);
> +int64_t bitmap_bytes;
>
> assert(granularity > 0);
> assert((granularity & (granularity - 1)) == 0);
> @@ -171,9 +180,9 @@ static int check_constraints_on_bitmap(BlockDriverState
> *bs,
> return -EINVAL;
> }
>
> -if ((len > (uint64_t)BME_MAX_PHYS_SIZE << granularity_bits) ||
> -(len > (uint64_t)BME_MAX_TABLE_SIZE * s->cluster_size <<
> - granularity_bits))
> +bitmap_bytes = get_bitmap_bytes_needed(len, granularity);
> +if ((bitmap_bytes > (uint64_t)BME_MAX_PHYS_SIZE) ||
> +(bitmap_bytes > (uint64_t)BME_MAX_TABLE_SIZE * s->cluster_size))
> {
> error_setg(errp, "Too much space will be occupied by the bitmap. "
> "Use larger granularity");
>
--
Best regards,
Vladimir
Re: [PATCH] iotests: Remove 130 from the "auto" group
On Tue, 29 Oct 2019 at 14:05, Max Reitz wrote: > > On 18.10.19 18:10, Thomas Huth wrote: > > Peter hit a "Could not open 'TEST_DIR/t.IMGFMT': Failed to get shared > > 'write' lock - Is another process using the image [TEST_DIR/t.IMGFMT]?" > > error with 130 already twice. Looks like this test is a little bit > > shaky, and currently nobody has a real clue what could be causing this > > issue, so for the time being, let's disable it from the "auto" group so > > that it does not gate the pull requests. > > > > Signed-off-by: Thomas Huth > > --- > > tests/qemu-iotests/group | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > Thanks, applied to my block branch: > > https://github.com/XanClic/qemu/commits/block I ran into this intermittent-on-s390 again this morning, so I've applied it to master in an attempt to improve the reliabliity of my merge testing. (The other current culprit for intermittent failures seems to be the various BSD builds for non-iotest reasons.) thanks -- PMM
Re: smb daemon get additional command line parameters from env variable
Hi, On 30/10/2019 08:55, Jordi Pujol wrote: > Hello, > > The new version 4 of Samba disables version 1 SMB protocols, now to > run old Win clients we must modify the temporary configuration of the > samba daemon to enable protocols before starting the samba client. > This patch gets the value of the environment variable SMBDOPTIONS and > appends it to the smbd command line; it allows the user to specify > additional samba daemon parameters before starting qemu. > It also patches the fork_exec function in misc.c, to parse correctly > command lines that contain spaces. > > Thanks, > > Jordi Pujol > cc'ed: qemu-devel and maintainers To contribute, please follow the guideline https://wiki.qemu.org/Contribute/SubmitAPatch Thanks, Laurent
Re: RFC: New device for zero-copy VM memory access
On Thu, 31 Oct 2019 at 02:56, wrote: > If you still believe that vhost-user should be used, I will do what I > can to > implement it, but for such a simple device I honestly believe it is > overkill. While not making a statement on whether vhost-user is technically suitable in this case, I would note that we have a strong bias towards "use facilities we already have rather than adding new ones", because having multiple ways to do something in QEMU is more maintenance effort and also confusing. It doesn't seem to me to matter if vhost-user provides extra features your specific use case doesn't need - just don't use them... thanks -- PMM
Re: RFC: New device for zero-copy VM memory access
Another update to this that adds support for unmap notification. The device has also been renamed to `porthole` and now resides here: https://github.com/gnif/qemu/blob/master/hw/misc/porthole.c And here is the updated Linux test client. https://gist.github.com/gnif/77e7fb54604b42a1a98ecb8bf3d2cf46 -Geoff On 2019-10-31 13:55, ge...@hostfission.com wrote: Hi Dave, On 2019-10-31 05:52, Dr. David Alan Gilbert wrote: * ge...@hostfission.com (ge...@hostfission.com) wrote: Hi All, Over the past week, I have been working to come up with a solution to the memory transfer performance issues that hinder the Looking Glass Project. Currently Looking Glass works by using the IVSHMEM shared memory device which is fed by an application that captures the guest's video output. While this works it is sub-optimal because we first have to perform a CPU copy of the captured frame into shared RAM, and then back out again for display. Because the destination buffers are allocated by closed proprietary code (DirectX, or NVidia NvFBC) there is no way to have the frame placed directly into the IVSHMEM shared ram. This new device, currently named `introspection` (which needs a more suitable name, porthole perhaps?), provides a means of translating guest physical addresses to host virtual addresses, and finally to the host offsets in RAM for file-backed memory guests. It does this by means of a simple protocol over a unix socket (chardev) which is supplied the appropriate fd for the VM's system RAM. The guest (in this case, Windows), when presented with the address of a userspace buffer and size, will mlock the appropriate pages into RAM and pass guest physical addresses to the virtual device. Hi Geroggrey, I wonder if the same thing can be done by using the existing vhost-user mechanism. vhost-user is intended for implementing a virtio device outside of the qemu process; so it has a character device that qemu passes commands down to the other process, where qemu mostly passes commands via the virtio queues. To be able to read the virtio queues, the external process mmap's the same memory as the guest - it gets passed a 'set mem table' command by qemu that includes fd's for the RAM, and includes base/offset pairs saying that a particular chunk of RAM is mapped at a particular guest physical address. Whether or not you make use of virtio queues, I think the mechanism for the device to tell the external process the mappings might be what you're after. Dave While normally I would be all for re-using such code, the vhost-user while being very feature-complete from what I understand is overkill for our requirements. It will still allocate a communication ring and an events system that we will not be using. The goal of this device is to provide a dumb & simple method of sharing system ram, both for this project and for others that work on a simple polling mechanism, it is not intended to be an end-to-end solution like vhost-user is. If you still believe that vhost-user should be used, I will do what I can to implement it, but for such a simple device I honestly believe it is overkill. -Geoff This device and the windows driver have been designed in such a way that it's a utility device for any project and/or application that could make use of it. The PCI subsystem vendor and device ID are used to provide a means of device identification in cases where multiple devices may be in use for differing applications. This also allows one common driver to be used for any other projects wishing to build on this device. My ultimate goal is to get this to a state where it could be accepted upstream into Qemu at which point Looking Glass would be modified to use it instead of the IVSHMEM device. My git repository with the new device can be found at: https://github.com/gnif/qemu The new device is: https://github.com/gnif/qemu/blob/master/hw/misc/introspection.c Looking Glass: https://looking-glass.hostfission.com/ The windows driver, while working, needs some cleanup before the source is published. I intend to maintain both this device and the windows driver including producing a signed Windows 10 driver if Redhat are unwilling or unable. Kind Regards, Geoffrey McRae HostFission https://hostfission.com -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PULL 0/3] a couple of CI fixes
Applied, thanks. Please update the changelog at https://wiki.qemu.org/ChangeLog/4.2 for any user-visible changes. -- PMM On Thu, 31 Oct 2019 at 10:02, Alex Bennée wrote: > > The following changes since commit 68d8ef4ec540682c3538d4963e836e43a211dd17: > > Merge remote-tracking branch > 'remotes/stsquad/tags/pull-tcg-plugins-281019-4' into staging (2019-10-30 > 14:10:32 +) > > are available in the Git repository at: > > https://github.com/stsquad/qemu.git tags/pull-testing-next-311019-1 > > for you to fetch changes up to 2ecde8b2fb046516a0f2f53fb56b86db92d6fc13: > > Acceptance test: update kernel for m68k/q800 test (2019-10-31 09:58:20 > +) > > > Fixes to get CI green again > > - fix m68k acceptance tests (Cleber) > - stop build breakage (Daniel) >
[PULL 8/9] bootdevice: FW_CFG interface for LCHS values
From: Sam Eiderman
Using fw_cfg, supply logical CHS values directly from QEMU to the BIOS.
Non-standard logical geometries break under QEMU.
A virtual disk which contains an operating system which depends on
logical geometries (consistent values being reported from BIOS INT13
AH=08) will most likely break under QEMU/SeaBIOS if it has non-standard
logical geometries - for example 56 SPT (sectors per track).
No matter what QEMU will report - SeaBIOS, for large enough disks - will
use LBA translation, which will report 63 SPT instead.
In addition we cannot force SeaBIOS to rely on physical geometries at
all. A virtio-blk-pci virtual disk with 255 phyiscal heads cannot
report more than 16 physical heads when moved to an IDE controller,
since the ATA spec allows a maximum of 16 heads - this is an artifact of
virtualization.
By supplying the logical geometries directly we are able to support such
"exotic" disks.
We serialize this information in a similar way to the "bootorder"
interface.
The new fw_cfg entry is "bios-geometry".
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Sam Eiderman
Signed-off-by: Sam Eiderman
Tested-by: Philippe Mathieu-Daudé
Signed-off-by: John Snow
---
include/sysemu/sysemu.h | 1 +
bootdevice.c| 31 +++
hw/nvram/fw_cfg.c | 14 +++---
3 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 5bc5c79cbc..80c57fdc4e 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -106,6 +106,7 @@ void validate_bootdevices(const char *devices, Error
**errp);
void add_boot_device_lchs(DeviceState *dev, const char *suffix,
uint32_t lcyls, uint32_t lheads, uint32_t lsecs);
void del_boot_device_lchs(DeviceState *dev, const char *suffix);
+char *get_boot_devices_lchs_list(size_t *size);
/* handler to set the boot_device order for a specific type of MachineClass */
typedef void QEMUBootSetHandler(void *opaque, const char *boot_order,
diff --git a/bootdevice.c b/bootdevice.c
index 2cf6b37c57..03aaffcc8d 100644
--- a/bootdevice.c
+++ b/bootdevice.c
@@ -405,3 +405,34 @@ void del_boot_device_lchs(DeviceState *dev, const char
*suffix)
}
}
}
+
+char *get_boot_devices_lchs_list(size_t *size)
+{
+FWLCHSEntry *i;
+size_t total = 0;
+char *list = NULL;
+
+QTAILQ_FOREACH(i, _lchs, link) {
+char *bootpath;
+char *chs_string;
+size_t len;
+
+bootpath = get_boot_device_path(i->dev, false, i->suffix);
+chs_string = g_strdup_printf("%s %" PRIu32 " %" PRIu32 " %" PRIu32,
+ bootpath, i->lcyls, i->lheads, i->lsecs);
+
+if (total) {
+list[total - 1] = '\n';
+}
+len = strlen(chs_string) + 1;
+list = g_realloc(list, total + len);
+memcpy([total], chs_string, len);
+total += len;
+g_free(chs_string);
+g_free(bootpath);
+}
+
+*size = total;
+
+return list;
+}
diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index aef1727250..44a3c19326 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -949,13 +949,21 @@ void *fw_cfg_modify_file(FWCfgState *s, const char
*filename,
static void fw_cfg_machine_reset(void *opaque)
{
+MachineClass *mc = MACHINE_GET_CLASS(qdev_get_machine());
+FWCfgState *s = opaque;
void *ptr;
size_t len;
-FWCfgState *s = opaque;
-char *bootindex = get_boot_devices_list();
+char *buf;
-ptr = fw_cfg_modify_file(s, "bootorder", (uint8_t *)bootindex, len);
+buf = get_boot_devices_list();
+ptr = fw_cfg_modify_file(s, "bootorder", (uint8_t *)buf, len);
g_free(ptr);
+
+if (!mc->legacy_fw_cfg_order) {
+buf = get_boot_devices_lchs_list();
+ptr = fw_cfg_modify_file(s, "bios-geometry", (uint8_t *)buf, len);
+g_free(ptr);
+}
}
static void fw_cfg_machine_ready(struct Notifier *n, void *data)
--
2.21.0
[PULL 9/9] hd-geo-test: Add tests for lchs override
From: Sam Eiderman
Add QTest tests to check the logical geometry override option.
The tests in hd-geo-test are out of date - they only test IDE and do not
test interesting MBRs.
Creating qcow2 disks with specific size and MBR layout is currently
unused - we only use a default empty MBR.
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Signed-off-by: Sam Eiderman
Signed-off-by: Sam Eiderman
Signed-off-by: John Snow
---
tests/hd-geo-test.c| 551 +
tests/Makefile.include | 2 +-
2 files changed, 552 insertions(+), 1 deletion(-)
diff --git a/tests/hd-geo-test.c b/tests/hd-geo-test.c
index 62eb624726..7e86c5416c 100644
--- a/tests/hd-geo-test.c
+++ b/tests/hd-geo-test.c
@@ -17,7 +17,12 @@
#include "qemu/osdep.h"
#include "qemu-common.h"
+#include "qemu/bswap.h"
+#include "qapi/qmp/qlist.h"
#include "libqtest.h"
+#include "libqos/fw_cfg.h"
+#include "libqos/libqos.h"
+#include "standard-headers/linux/qemu_fw_cfg.h"
#define ARGV_SIZE 256
@@ -388,6 +393,537 @@ static void test_ide_drive_cd_0(void)
qtest_quit(qts);
}
+typedef struct {
+bool active;
+uint32_t head;
+uint32_t sector;
+uint32_t cyl;
+uint32_t end_head;
+uint32_t end_sector;
+uint32_t end_cyl;
+uint32_t start_sect;
+uint32_t nr_sects;
+} MBRpartitions[4];
+
+static MBRpartitions empty_mbr = { {false, 0, 0, 0, 0, 0, 0, 0, 0},
+ {false, 0, 0, 0, 0, 0, 0, 0, 0},
+ {false, 0, 0, 0, 0, 0, 0, 0, 0},
+ {false, 0, 0, 0, 0, 0, 0, 0, 0} };
+
+static char *create_qcow2_with_mbr(MBRpartitions mbr, uint64_t sectors)
+{
+const char *template = "/tmp/qtest.XX";
+char *raw_path = strdup(template);
+char *qcow2_path = strdup(template);
+char cmd[100 + 2 * PATH_MAX];
+uint8_t buf[512];
+int i, ret, fd, offset;
+uint64_t qcow2_size = sectors * 512;
+uint8_t status, parttype, head, sector, cyl;
+char *qemu_img_path;
+char *qemu_img_abs_path;
+
+offset = 0xbe;
+
+for (i = 0; i < 4; i++) {
+status = mbr[i].active ? 0x80 : 0x00;
+g_assert(mbr[i].head < 256);
+g_assert(mbr[i].sector < 64);
+g_assert(mbr[i].cyl < 1024);
+head = mbr[i].head;
+sector = mbr[i].sector + ((mbr[i].cyl & 0x300) >> 2);
+cyl = mbr[i].cyl & 0xff;
+
+buf[offset + 0x0] = status;
+buf[offset + 0x1] = head;
+buf[offset + 0x2] = sector;
+buf[offset + 0x3] = cyl;
+
+parttype = 0;
+g_assert(mbr[i].end_head < 256);
+g_assert(mbr[i].end_sector < 64);
+g_assert(mbr[i].end_cyl < 1024);
+head = mbr[i].end_head;
+sector = mbr[i].end_sector + ((mbr[i].end_cyl & 0x300) >> 2);
+cyl = mbr[i].end_cyl & 0xff;
+
+buf[offset + 0x4] = parttype;
+buf[offset + 0x5] = head;
+buf[offset + 0x6] = sector;
+buf[offset + 0x7] = cyl;
+
+(*(uint32_t *)[offset + 0x8]) = cpu_to_le32(mbr[i].start_sect);
+(*(uint32_t *)[offset + 0xc]) = cpu_to_le32(mbr[i].nr_sects);
+
+offset += 0x10;
+}
+
+fd = mkstemp(raw_path);
+g_assert(fd);
+close(fd);
+
+fd = open(raw_path, O_WRONLY);
+g_assert(fd >= 0);
+ret = write(fd, buf, sizeof(buf));
+g_assert(ret == sizeof(buf));
+close(fd);
+
+fd = mkstemp(qcow2_path);
+g_assert(fd);
+close(fd);
+
+qemu_img_path = getenv("QTEST_QEMU_IMG");
+g_assert(qemu_img_path);
+qemu_img_abs_path = realpath(qemu_img_path, NULL);
+g_assert(qemu_img_abs_path);
+
+ret = snprintf(cmd, sizeof(cmd),
+ "%s convert -f raw -O qcow2 %s %s > /dev/null",
+ qemu_img_abs_path,
+ raw_path, qcow2_path);
+g_assert((0 < ret) && (ret <= sizeof(cmd)));
+ret = system(cmd);
+g_assert(ret == 0);
+
+ret = snprintf(cmd, sizeof(cmd),
+ "%s resize %s %" PRIu64 " > /dev/null",
+ qemu_img_abs_path,
+ qcow2_path, qcow2_size);
+g_assert((0 < ret) && (ret <= sizeof(cmd)));
+ret = system(cmd);
+g_assert(ret == 0);
+
+free(qemu_img_abs_path);
+
+unlink(raw_path);
+free(raw_path);
+
+return qcow2_path;
+}
+
+#define BIOS_GEOMETRY_MAX_SIZE 1
+
+typedef struct {
+uint32_t c;
+uint32_t h;
+uint32_t s;
+} CHS;
+
+typedef struct {
+const char *dev_path;
+CHS chs;
+} CHSResult;
+
+static void read_bootdevices(QFWCFG *fw_cfg, CHSResult expected[])
+{
+char *buf = g_malloc0(BIOS_GEOMETRY_MAX_SIZE);
+char *cur;
+GList *results = NULL, *cur_result;
+CHSResult *r;
+int i;
+int res;
+bool found;
+
+qfw_cfg_get_file(fw_cfg, "bios-geometry", buf, BIOS_GEOMETRY_MAX_SIZE);
+
+for (cur = buf; *cur; cur++) {
+if (*cur == '\n') {
+*cur = '\0';
+}
+}
+cur = buf;
+
+while (strlen(cur)) {
+
+r =
[PULL 5/9] scsi: Propagate unrealize() callback to scsi-hd
From: Sam Eiderman
We will need to add LCHS removal logic to scsi-hd's unrealize() in the
next commit.
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Sam Eiderman
Signed-off-by: Sam Eiderman
Tested-by: Philippe Mathieu-Daudé
Signed-off-by: John Snow
---
include/hw/scsi/scsi.h | 1 +
hw/scsi/scsi-bus.c | 16
2 files changed, 17 insertions(+)
diff --git a/include/hw/scsi/scsi.h b/include/hw/scsi/scsi.h
index d77a92361b..332ef602f4 100644
--- a/include/hw/scsi/scsi.h
+++ b/include/hw/scsi/scsi.h
@@ -59,6 +59,7 @@ struct SCSIRequest {
typedef struct SCSIDeviceClass {
DeviceClass parent_class;
void (*realize)(SCSIDevice *dev, Error **errp);
+void (*unrealize)(SCSIDevice *dev, Error **errp);
int (*parse_cdb)(SCSIDevice *dev, SCSICommand *cmd, uint8_t *buf,
void *hba_private);
SCSIRequest *(*alloc_req)(SCSIDevice *s, uint32_t tag, uint32_t lun,
diff --git a/hw/scsi/scsi-bus.c b/hw/scsi/scsi-bus.c
index bccb7cc4c6..359d50d6d0 100644
--- a/hw/scsi/scsi-bus.c
+++ b/hw/scsi/scsi-bus.c
@@ -59,6 +59,14 @@ static void scsi_device_realize(SCSIDevice *s, Error **errp)
}
}
+static void scsi_device_unrealize(SCSIDevice *s, Error **errp)
+{
+SCSIDeviceClass *sc = SCSI_DEVICE_GET_CLASS(s);
+if (sc->unrealize) {
+sc->unrealize(s, errp);
+}
+}
+
int scsi_bus_parse_cdb(SCSIDevice *dev, SCSICommand *cmd, uint8_t *buf,
void *hba_private)
{
@@ -217,12 +225,20 @@ static void scsi_qdev_realize(DeviceState *qdev, Error
**errp)
static void scsi_qdev_unrealize(DeviceState *qdev, Error **errp)
{
SCSIDevice *dev = SCSI_DEVICE(qdev);
+Error *local_err = NULL;
if (dev->vmsentry) {
qemu_del_vm_change_state_handler(dev->vmsentry);
}
scsi_device_purge_requests(dev, SENSE_CODE(NO_SENSE));
+
+scsi_device_unrealize(dev, _err);
+if (local_err) {
+error_propagate(errp, local_err);
+return;
+}
+
blockdev_mark_auto_del(dev->conf.blk);
}
--
2.21.0
[PULL 7/9] bootdevice: Refactor get_boot_devices_list
From: Sam Eiderman
Move device name construction to a separate function.
We will reuse this function in the following commit to pass logical CHS
parameters through fw_cfg much like we currently pass bootindex.
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Sam Eiderman
Signed-off-by: Sam Eiderman
Tested-by: Philippe Mathieu-Daudé
Signed-off-by: John Snow
---
bootdevice.c | 61 +---
1 file changed, 34 insertions(+), 27 deletions(-)
diff --git a/bootdevice.c b/bootdevice.c
index bc5e1c2de4..2cf6b37c57 100644
--- a/bootdevice.c
+++ b/bootdevice.c
@@ -202,6 +202,39 @@ DeviceState *get_boot_device(uint32_t position)
return res;
}
+static char *get_boot_device_path(DeviceState *dev, bool ignore_suffixes,
+ const char *suffix)
+{
+char *devpath = NULL, *s = NULL, *d, *bootpath;
+
+if (dev) {
+devpath = qdev_get_fw_dev_path(dev);
+assert(devpath);
+}
+
+if (!ignore_suffixes) {
+if (dev) {
+d = qdev_get_own_fw_dev_path_from_handler(dev->parent_bus, dev);
+if (d) {
+assert(!suffix);
+s = d;
+} else {
+s = g_strdup(suffix);
+}
+} else {
+s = g_strdup(suffix);
+}
+}
+
+bootpath = g_strdup_printf("%s%s",
+ devpath ? devpath : "",
+ s ? s : "");
+g_free(devpath);
+g_free(s);
+
+return bootpath;
+}
+
/*
* This function returns null terminated string that consist of new line
* separated device paths.
@@ -218,36 +251,10 @@ char *get_boot_devices_list(size_t *size)
bool ignore_suffixes = mc->ignore_boot_device_suffixes;
QTAILQ_FOREACH(i, _boot_order, link) {
-char *devpath = NULL, *suffix = NULL;
char *bootpath;
-char *d;
size_t len;
-if (i->dev) {
-devpath = qdev_get_fw_dev_path(i->dev);
-assert(devpath);
-}
-
-if (!ignore_suffixes) {
-if (i->dev) {
-d = qdev_get_own_fw_dev_path_from_handler(i->dev->parent_bus,
- i->dev);
-if (d) {
-assert(!i->suffix);
-suffix = d;
-} else {
-suffix = g_strdup(i->suffix);
-}
-} else {
-suffix = g_strdup(i->suffix);
-}
-}
-
-bootpath = g_strdup_printf("%s%s",
- devpath ? devpath : "",
- suffix ? suffix : "");
-g_free(devpath);
-g_free(suffix);
+bootpath = get_boot_device_path(i->dev, ignore_suffixes, i->suffix);
if (total) {
list[total-1] = '\n';
--
2.21.0
[PULL 4/9] bootdevice: Add interface to gather LCHS
From: Sam Eiderman
Add an interface to provide direct logical CHS values for boot devices.
We will use this interface in the next commits.
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Signed-off-by: Sam Eiderman
Signed-off-by: Sam Eiderman
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Signed-off-by: John Snow
---
include/sysemu/sysemu.h | 3 +++
bootdevice.c| 55 +
2 files changed, 58 insertions(+)
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 44f18eb739..5bc5c79cbc 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -103,6 +103,9 @@ void device_add_bootindex_property(Object *obj, int32_t
*bootindex,
DeviceState *dev, Error **errp);
void restore_boot_order(void *opaque);
void validate_bootdevices(const char *devices, Error **errp);
+void add_boot_device_lchs(DeviceState *dev, const char *suffix,
+ uint32_t lcyls, uint32_t lheads, uint32_t lsecs);
+void del_boot_device_lchs(DeviceState *dev, const char *suffix);
/* handler to set the boot_device order for a specific type of MachineClass */
typedef void QEMUBootSetHandler(void *opaque, const char *boot_order,
diff --git a/bootdevice.c b/bootdevice.c
index 1d225202f9..bc5e1c2de4 100644
--- a/bootdevice.c
+++ b/bootdevice.c
@@ -343,3 +343,58 @@ void device_add_bootindex_property(Object *obj, int32_t
*bootindex,
/* initialize devices' bootindex property to -1 */
object_property_set_int(obj, -1, name, NULL);
}
+
+typedef struct FWLCHSEntry FWLCHSEntry;
+
+struct FWLCHSEntry {
+QTAILQ_ENTRY(FWLCHSEntry) link;
+DeviceState *dev;
+char *suffix;
+uint32_t lcyls;
+uint32_t lheads;
+uint32_t lsecs;
+};
+
+static QTAILQ_HEAD(, FWLCHSEntry) fw_lchs =
+QTAILQ_HEAD_INITIALIZER(fw_lchs);
+
+void add_boot_device_lchs(DeviceState *dev, const char *suffix,
+ uint32_t lcyls, uint32_t lheads, uint32_t lsecs)
+{
+FWLCHSEntry *node;
+
+if (!lcyls && !lheads && !lsecs) {
+return;
+}
+
+assert(dev != NULL || suffix != NULL);
+
+node = g_malloc0(sizeof(FWLCHSEntry));
+node->suffix = g_strdup(suffix);
+node->dev = dev;
+node->lcyls = lcyls;
+node->lheads = lheads;
+node->lsecs = lsecs;
+
+QTAILQ_INSERT_TAIL(_lchs, node, link);
+}
+
+void del_boot_device_lchs(DeviceState *dev, const char *suffix)
+{
+FWLCHSEntry *i;
+
+if (dev == NULL) {
+return;
+}
+
+QTAILQ_FOREACH(i, _lchs, link) {
+if ((!suffix || !g_strcmp0(i->suffix, suffix)) &&
+ i->dev == dev) {
+QTAILQ_REMOVE(_lchs, i, link);
+g_free(i->suffix);
+g_free(i);
+
+break;
+}
+}
+}
--
2.21.0
[PULL 2/9] block: Refactor macros - fix tabbing
From: Sam Eiderman
Fixing tabbing in block related macros.
Signed-off-by: Sam Eiderman
Signed-off-by: Sam Eiderman
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: John Snow
---
include/hw/block/block.h | 16
hw/ide/qdev.c| 2 +-
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/include/hw/block/block.h b/include/hw/block/block.h
index 607539057a..fd55a30bca 100644
--- a/include/hw/block/block.h
+++ b/include/hw/block/block.h
@@ -50,21 +50,21 @@ static inline unsigned int get_physical_block_exp(BlockConf
*conf)
_conf.logical_block_size),\
DEFINE_PROP_BLOCKSIZE("physical_block_size", _state,\
_conf.physical_block_size), \
-DEFINE_PROP_UINT16("min_io_size", _state, _conf.min_io_size, 0), \
+DEFINE_PROP_UINT16("min_io_size", _state, _conf.min_io_size, 0),\
DEFINE_PROP_UINT32("opt_io_size", _state, _conf.opt_io_size, 0),\
-DEFINE_PROP_UINT32("discard_granularity", _state, \
- _conf.discard_granularity, -1), \
-DEFINE_PROP_ON_OFF_AUTO("write-cache", _state, _conf.wce, \
-ON_OFF_AUTO_AUTO), \
+DEFINE_PROP_UINT32("discard_granularity", _state, \
+ _conf.discard_granularity, -1), \
+DEFINE_PROP_ON_OFF_AUTO("write-cache", _state, _conf.wce, \
+ON_OFF_AUTO_AUTO), \
DEFINE_PROP_BOOL("share-rw", _state, _conf.share_rw, false)
#define DEFINE_BLOCK_PROPERTIES(_state, _conf) \
DEFINE_PROP_DRIVE("drive", _state, _conf.blk), \
DEFINE_BLOCK_PROPERTIES_BASE(_state, _conf)
-#define DEFINE_BLOCK_CHS_PROPERTIES(_state, _conf) \
-DEFINE_PROP_UINT32("cyls", _state, _conf.cyls, 0), \
-DEFINE_PROP_UINT32("heads", _state, _conf.heads, 0), \
+#define DEFINE_BLOCK_CHS_PROPERTIES(_state, _conf) \
+DEFINE_PROP_UINT32("cyls", _state, _conf.cyls, 0), \
+DEFINE_PROP_UINT32("heads", _state, _conf.heads, 0),\
DEFINE_PROP_UINT32("secs", _state, _conf.secs, 0)
#define DEFINE_BLOCK_ERROR_PROPERTIES(_state, _conf)\
diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
index 3666e59721..85cca6ec38 100644
--- a/hw/ide/qdev.c
+++ b/hw/ide/qdev.c
@@ -293,7 +293,7 @@ static void ide_drive_realize(IDEDevice *dev, Error **errp)
DEFINE_BLOCK_PROPERTIES(IDEDrive, dev.conf),\
DEFINE_BLOCK_ERROR_PROPERTIES(IDEDrive, dev.conf), \
DEFINE_PROP_STRING("ver", IDEDrive, dev.version), \
-DEFINE_PROP_UINT64("wwn", IDEDrive, dev.wwn, 0),\
+DEFINE_PROP_UINT64("wwn", IDEDrive, dev.wwn, 0), \
DEFINE_PROP_STRING("serial", IDEDrive, dev.serial),\
DEFINE_PROP_STRING("model", IDEDrive, dev.model)
--
2.21.0
[PULL 6/9] bootdevice: Gather LCHS from all relevant devices
From: Sam Eiderman
Relevant devices are:
* ide-hd (and ide-cd, ide-drive)
* scsi-hd (and scsi-cd, scsi-disk, scsi-block)
* virtio-blk-pci
We do not call del_boot_device_lchs() for ide-* since we don't need to -
IDE block devices do not support unplugging.
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Signed-off-by: Sam Eiderman
Signed-off-by: Sam Eiderman
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Signed-off-by: John Snow
---
hw/block/virtio-blk.c | 6 ++
hw/ide/qdev.c | 5 +
hw/scsi/scsi-disk.c | 12
3 files changed, 23 insertions(+)
diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index 9fa2eaf890..4c357d2928 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -1200,6 +1200,11 @@ static void virtio_blk_device_realize(DeviceState *dev,
Error **errp)
blk_set_guest_block_size(s->blk, s->conf.conf.logical_block_size);
blk_iostatus_enable(s->blk);
+
+add_boot_device_lchs(dev, "/disk@0,0",
+ conf->conf.lcyls,
+ conf->conf.lheads,
+ conf->conf.lsecs);
}
static void virtio_blk_device_unrealize(DeviceState *dev, Error **errp)
@@ -1210,6 +1215,7 @@ static void virtio_blk_device_unrealize(DeviceState *dev,
Error **errp)
unsigned i;
blk_drain(s->blk);
+del_boot_device_lchs(dev, "/disk@0,0");
virtio_blk_data_plane_destroy(s->dataplane);
s->dataplane = NULL;
for (i = 0; i < conf->num_queues; i++) {
diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
index 85cca6ec38..374a791a45 100644
--- a/hw/ide/qdev.c
+++ b/hw/ide/qdev.c
@@ -220,6 +220,11 @@ static void ide_dev_initfn(IDEDevice *dev, IDEDriveKind
kind, Error **errp)
add_boot_device_path(dev->conf.bootindex, >qdev,
dev->unit ? "/disk@1" : "/disk@0");
+
+add_boot_device_lchs(>qdev, dev->unit ? "/disk@1" : "/disk@0",
+ dev->conf.lcyls,
+ dev->conf.lheads,
+ dev->conf.lsecs);
}
static void ide_dev_get_bootindex(Object *obj, Visitor *v, const char *name,
diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
index 68b1675fd9..07fb5ebdf1 100644
--- a/hw/scsi/scsi-disk.c
+++ b/hw/scsi/scsi-disk.c
@@ -35,6 +35,7 @@
#include "hw/block/block.h"
#include "hw/qdev-properties.h"
#include "sysemu/dma.h"
+#include "sysemu/sysemu.h"
#include "qemu/cutils.h"
#include "trace.h"
@@ -2414,6 +2415,16 @@ static void scsi_realize(SCSIDevice *dev, Error **errp)
blk_set_guest_block_size(s->qdev.conf.blk, s->qdev.blocksize);
blk_iostatus_enable(s->qdev.conf.blk);
+
+add_boot_device_lchs(>qdev, NULL,
+ dev->conf.lcyls,
+ dev->conf.lheads,
+ dev->conf.lsecs);
+}
+
+static void scsi_unrealize(SCSIDevice *dev, Error **errp)
+{
+del_boot_device_lchs(>qdev, NULL);
}
static void scsi_hd_realize(SCSIDevice *dev, Error **errp)
@@ -3018,6 +3029,7 @@ static void scsi_hd_class_initfn(ObjectClass *klass, void
*data)
SCSIDeviceClass *sc = SCSI_DEVICE_CLASS(klass);
sc->realize = scsi_hd_realize;
+sc->unrealize= scsi_unrealize;
sc->alloc_req= scsi_new_request;
sc->unit_attention_reported = scsi_disk_unit_attention_reported;
dc->desc = "virtual SCSI disk";
--
2.21.0
[PULL 3/9] block: Support providing LCHS from user
From: Sam Eiderman
Add logical geometry variables to BlockConf.
A user can now supply "lcyls", "lheads" & "lsecs" for any HD device
that supports CHS ("cyls", "heads", "secs").
These devices include:
* ide-hd
* scsi-hd
* virtio-blk-pci
In future commits we will use the provided LCHS and pass it to the BIOS
through fw_cfg to be supplied using INT13 routines.
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Signed-off-by: Sam Eiderman
Signed-off-by: Sam Eiderman
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Signed-off-by: John Snow
---
include/hw/block/block.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/include/hw/block/block.h b/include/hw/block/block.h
index fd55a30bca..d7246f3862 100644
--- a/include/hw/block/block.h
+++ b/include/hw/block/block.h
@@ -26,6 +26,7 @@ typedef struct BlockConf {
uint32_t discard_granularity;
/* geometry, not all devices use this */
uint32_t cyls, heads, secs;
+uint32_t lcyls, lheads, lsecs;
OnOffAuto wce;
bool share_rw;
BlockdevOnError rerror;
@@ -65,7 +66,10 @@ static inline unsigned int get_physical_block_exp(BlockConf
*conf)
#define DEFINE_BLOCK_CHS_PROPERTIES(_state, _conf) \
DEFINE_PROP_UINT32("cyls", _state, _conf.cyls, 0), \
DEFINE_PROP_UINT32("heads", _state, _conf.heads, 0),\
-DEFINE_PROP_UINT32("secs", _state, _conf.secs, 0)
+DEFINE_PROP_UINT32("secs", _state, _conf.secs, 0), \
+DEFINE_PROP_UINT32("lcyls", _state, _conf.lcyls, 0),\
+DEFINE_PROP_UINT32("lheads", _state, _conf.lheads, 0), \
+DEFINE_PROP_UINT32("lsecs", _state, _conf.lsecs, 0)
#define DEFINE_BLOCK_ERROR_PROPERTIES(_state, _conf)\
DEFINE_PROP_BLOCKDEV_ON_ERROR("rerror", _state, _conf.rerror, \
--
2.21.0
[PULL 0/9] Ide patches
The following changes since commit 68d8ef4ec540682c3538d4963e836e43a211dd17: Merge remote-tracking branch 'remotes/stsquad/tags/pull-tcg-plugins-281019-4' into staging (2019-10-30 14:10:32 +) are available in the Git repository at: https://github.com/jnsnow/qemu.git tags/ide-pull-request for you to fetch changes up to c35564caf20e8d3431786dddf0fa513daa7d7f3c: hd-geo-test: Add tests for lchs override (2019-10-31 06:11:34 -0400) Pull request John Snow (1): IDE: deprecate ide-drive Sam Eiderman (8): block: Refactor macros - fix tabbing block: Support providing LCHS from user bootdevice: Add interface to gather LCHS scsi: Propagate unrealize() callback to scsi-hd bootdevice: Gather LCHS from all relevant devices bootdevice: Refactor get_boot_devices_list bootdevice: FW_CFG interface for LCHS values hd-geo-test: Add tests for lchs override qemu-deprecated.texi | 5 + include/hw/block/block.h | 22 +- include/hw/scsi/scsi.h| 1 + include/sysemu/sysemu.h | 4 + bootdevice.c | 147 +++-- hw/block/virtio-blk.c | 6 + hw/ide/qdev.c | 10 +- hw/nvram/fw_cfg.c | 14 +- hw/scsi/scsi-bus.c| 16 + hw/scsi/scsi-disk.c | 12 + tests/hd-geo-test.c | 551 ++ tests/Makefile.include| 2 +- tests/qemu-iotests/051.pc.out | 6 +- 13 files changed, 753 insertions(+), 43 deletions(-) -- 2.21.0
[PULL 1/9] IDE: deprecate ide-drive
It's an old compatibility shim that just delegates to ide-cd or ide-hd.
I'd like to refactor these some day, and getting rid of the super-object
will make that easier.
Either way, we don't need this.
Signed-off-by: John Snow
Reviewed-by: Thomas Huth
Reviewed-by: Markus Armbruster
ACKed-by: Peter Krempa
Message-id: 20191009224303.10232-2-js...@redhat.com
Signed-off-by: John Snow
---
qemu-deprecated.texi | 5 +
hw/ide/qdev.c | 3 +++
tests/qemu-iotests/051.pc.out | 6 --
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
index f727bd3932..296bfc93a3 100644
--- a/qemu-deprecated.texi
+++ b/qemu-deprecated.texi
@@ -254,6 +254,11 @@ quite a bit. It will be removed without replacement unless
some users speaks
up at the @email{qemu-devel@@nongnu.org} mailing list with information about
their usecases.
+@subsection ide-drive (since 4.2)
+
+The 'ide-drive' device is deprecated. Users should use 'ide-hd' or
+'ide-cd' as appropriate to get an IDE hard disk or CD-ROM as needed.
+
@section System emulator machines
@subsection pc-0.12, pc-0.13, pc-0.14 and pc-0.15 (since 4.0)
diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
index 6fba6b62b8..3666e59721 100644
--- a/hw/ide/qdev.c
+++ b/hw/ide/qdev.c
@@ -279,6 +279,9 @@ static void ide_drive_realize(IDEDevice *dev, Error **errp)
{
DriveInfo *dinfo = NULL;
+warn_report("'ide-drive' is deprecated, "
+"please use 'ide-hd' or 'ide-cd' instead");
+
if (dev->conf.blk) {
dinfo = blk_legacy_dinfo(dev->conf.blk);
}
diff --git a/tests/qemu-iotests/051.pc.out b/tests/qemu-iotests/051.pc.out
index 000557c7c8..34849dd172 100644
--- a/tests/qemu-iotests/051.pc.out
+++ b/tests/qemu-iotests/051.pc.out
@@ -158,7 +158,8 @@ QEMU X.Y.Z monitor - type 'help' for more information
Testing: -drive if=none,id=disk -device ide-drive,drive=disk
QEMU X.Y.Z monitor - type 'help' for more information
-(qemu) QEMU_PROG: -device ide-drive,drive=disk: Device needs media, but drive
is empty
+(qemu) QEMU_PROG: -device ide-drive,drive=disk: warning: 'ide-drive' is
deprecated, please use 'ide-hd' or 'ide-cd' instead
+QEMU_PROG: -device ide-drive,drive=disk: Device needs media, but drive is empty
Testing: -drive if=none,id=disk -device ide-hd,drive=disk
QEMU X.Y.Z monitor - type 'help' for more information
@@ -228,7 +229,8 @@ QEMU X.Y.Z monitor - type 'help' for more information
Testing: -drive file=TEST_DIR/t.qcow2,if=none,id=disk,readonly=on -device
ide-drive,drive=disk
QEMU X.Y.Z monitor - type 'help' for more information
-(qemu) QEMU_PROG: -device ide-drive,drive=disk: Block node is read-only
+(qemu) QEMU_PROG: -device ide-drive,drive=disk: warning: 'ide-drive' is
deprecated, please use 'ide-hd' or 'ide-cd' instead
+QEMU_PROG: -device ide-drive,drive=disk: Block node is read-only
Testing: -drive file=TEST_DIR/t.qcow2,if=none,id=disk,readonly=on -device
ide-hd,drive=disk
QEMU X.Y.Z monitor - type 'help' for more information
--
2.21.0
Re: [PATCH v6 3/4] tests/vm: use console_consume for netbsd
Thank you for this work. I hope it will be fine now.
On 31.10.2019 09:53, Gerd Hoffmann wrote:
> Use new helper to read all pending console output,
> not just a single char. Unblocks installer boot.
>
> Signed-off-by: Gerd Hoffmann
> ---
> tests/vm/netbsd | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tests/vm/netbsd b/tests/vm/netbsd
> index 5e04dcd9b1..d1bfd0 100755
> --- a/tests/vm/netbsd
> +++ b/tests/vm/netbsd
> @@ -93,7 +93,7 @@ class NetBSDVM(basevm.BaseVM):
> for char in list("5consdev com0\n"):
> time.sleep(0.2)
> self.console_send(char)
> -self.console_wait("")
> +self.console_consume()
> self.console_wait_send("> ", "boot\n")
>
> self.console_wait_send("Terminal type","xterm\n")
>
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] spapr/kvm: Set default cpu model for all machine classes
On Thu, Oct 31, 2019 at 09:15:56AM +0100, Greg Kurz wrote:
> On Wed, 30 Oct 2019 17:32:43 +0100
> David Gibson wrote:
>
> > We have to set the default model of all machine classes, not just for the
> > active one. Otherwise, "query-machines" will indicate the wrong CPU model
> > ("qemu-s390x-cpu" instead of "host-s390x-cpu") as "default-cpu-type".
> >
>
> A PPC cpu model might be better.
Indeed.
>
> > s390x already fixed this in de60a92e "s390x/kvm: Set default cpu model for
> > all machine classes". This patch applies a similar fix for the pseries-*
> > machine types on ppc64.
> >
> > Doing a
> > {"execute":"query-machines"}
> > under KVM now results in
> > {
> > "hotpluggable-cpus": true,
> > "name": "pseries-4.2",
> > "numa-mem-supported": true,
> > "default-cpu-type": "host-powerpc64-cpu",
> > "is-default": true,
> > "cpu-max": 1024,
> > "deprecated": false,
> > "alias": "pseries"
> > },
> > {
> > "hotpluggable-cpus": true,
> > "name": "pseries-4.1",
> > "numa-mem-supported": true,
> > "default-cpu-type": "host-powerpc64-cpu",
> > "cpu-max": 1024,
> > "deprecated": false
> > },
> > ...
> >
> > Libvirt probes all machines via "-machine none,accel=kvm:tcg" and will
> > currently see the wrong CPU model under KVM.
> >
> > Reported-by: Jiři Denemark
> > Cc: David Hildenbrand
> > Cc: Igor Mammedov
>
> Missing S-o-b.
Oops, fixed.
> With these fixed.
>
> Reviewed-by: Greg Kurz
>
> > ---
> > target/ppc/kvm.c | 21 +
> > 1 file changed, 13 insertions(+), 8 deletions(-)
> >
> > diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
> > index 7d2e8969ac..c77f9848ec 100644
> > --- a/target/ppc/kvm.c
> > +++ b/target/ppc/kvm.c
> > @@ -100,7 +100,7 @@ static bool kvmppc_is_pr(KVMState *ks)
> > return kvm_vm_check_extension(ks, KVM_CAP_PPC_GET_PVINFO) != 0;
> > }
> >
> > -static int kvm_ppc_register_host_cpu_type(MachineState *ms);
> > +static int kvm_ppc_register_host_cpu_type(void);
> > static void kvmppc_get_cpu_characteristics(KVMState *s);
> > static int kvmppc_get_dec_bits(void);
> >
> > @@ -147,7 +147,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
> > exit(1);
> > }
> >
> > -kvm_ppc_register_host_cpu_type(ms);
> > +kvm_ppc_register_host_cpu_type();
> >
> > return 0;
> > }
> > @@ -2534,13 +2534,19 @@ PowerPCCPUClass *kvm_ppc_get_host_cpu_class(void)
> > return pvr_pcc;
> > }
> >
> > -static int kvm_ppc_register_host_cpu_type(MachineState *ms)
> > +static void pseries_machine_class_fixup(ObjectClass *oc, void *opaque)
> > +{
> > +MachineClass *mc = MACHINE_CLASS(oc);
> > +
> > +mc->default_cpu_type = TYPE_HOST_POWERPC_CPU;
> > +}
> > +
> > +static int kvm_ppc_register_host_cpu_type(void)
> > {
> > TypeInfo type_info = {
> > .name = TYPE_HOST_POWERPC_CPU,
> > .class_init = kvmppc_host_cpu_class_init,
> > };
> > -MachineClass *mc = MACHINE_GET_CLASS(ms);
> > PowerPCCPUClass *pvr_pcc;
> > ObjectClass *oc;
> > DeviceClass *dc;
> > @@ -2552,10 +2558,9 @@ static int
> > kvm_ppc_register_host_cpu_type(MachineState *ms)
> > }
> > type_info.parent = object_class_get_name(OBJECT_CLASS(pvr_pcc));
> > type_register(_info);
> > -if (object_dynamic_cast(OBJECT(ms), TYPE_SPAPR_MACHINE)) {
> > -/* override TCG default cpu type with 'host' cpu model */
> > -mc->default_cpu_type = TYPE_HOST_POWERPC_CPU;
> > -}
> > +/* override TCG default cpu type with 'host' cpu model */
> > +object_class_foreach(pseries_machine_class_fixup, TYPE_SPAPR_MACHINE,
> > + false, NULL);
> >
> > oc = object_class_by_name(type_info.name);
> > g_assert(oc);
>
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
Re: [PATCH] spapr/kvm: Set default cpu model for all machine classes
On Wed, Oct 30, 2019 at 06:32:28PM +0100, David Hildenbrand wrote:
> On 30.10.19 17:32, David Gibson wrote:
> > We have to set the default model of all machine classes, not just for the
> > active one. Otherwise, "query-machines" will indicate the wrong CPU model
> > ("qemu-s390x-cpu" instead of "host-s390x-cpu") as "default-cpu-type".
>
> Maybe use ppc CPU models here instead of s390x ones :)
Oops, thanks.
>
> >
> > s390x already fixed this in de60a92e "s390x/kvm: Set default cpu model for
> > all machine classes". This patch applies a similar fix for the pseries-*
> > machine types on ppc64.
> >
> > Doing a
> > {"execute":"query-machines"}
> > under KVM now results in
> > {
> >"hotpluggable-cpus": true,
> >"name": "pseries-4.2",
> >"numa-mem-supported": true,
> >"default-cpu-type": "host-powerpc64-cpu",
> >"is-default": true,
> >"cpu-max": 1024,
> >"deprecated": false,
> >"alias": "pseries"
> > },
> > {
> >"hotpluggable-cpus": true,
> >"name": "pseries-4.1",
> >"numa-mem-supported": true,
> >"default-cpu-type": "host-powerpc64-cpu",
> >"cpu-max": 1024,
> >"deprecated": false
> > },
> > ...
> >
> > Libvirt probes all machines via "-machine none,accel=kvm:tcg" and will
> > currently see the wrong CPU model under KVM.
> >
> > Reported-by: Jiři Denemark
> > Cc: David Hildenbrand
> > Cc: Igor Mammedov
> > ---
> > target/ppc/kvm.c | 21 +
> > 1 file changed, 13 insertions(+), 8 deletions(-)
> >
> > diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
> > index 7d2e8969ac..c77f9848ec 100644
> > --- a/target/ppc/kvm.c
> > +++ b/target/ppc/kvm.c
> > @@ -100,7 +100,7 @@ static bool kvmppc_is_pr(KVMState *ks)
> > return kvm_vm_check_extension(ks, KVM_CAP_PPC_GET_PVINFO) != 0;
> > }
> > -static int kvm_ppc_register_host_cpu_type(MachineState *ms);
> > +static int kvm_ppc_register_host_cpu_type(void);
> > static void kvmppc_get_cpu_characteristics(KVMState *s);
> > static int kvmppc_get_dec_bits(void);
> > @@ -147,7 +147,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
> > exit(1);
> > }
> > -kvm_ppc_register_host_cpu_type(ms);
> > +kvm_ppc_register_host_cpu_type();
> > return 0;
> > }
> > @@ -2534,13 +2534,19 @@ PowerPCCPUClass *kvm_ppc_get_host_cpu_class(void)
> > return pvr_pcc;
> > }
> > -static int kvm_ppc_register_host_cpu_type(MachineState *ms)
> > +static void pseries_machine_class_fixup(ObjectClass *oc, void *opaque)
> > +{
> > +MachineClass *mc = MACHINE_CLASS(oc);
> > +
> > +mc->default_cpu_type = TYPE_HOST_POWERPC_CPU;
> > +}
> > +
> > +static int kvm_ppc_register_host_cpu_type(void)
> > {
> > TypeInfo type_info = {
> > .name = TYPE_HOST_POWERPC_CPU,
> > .class_init = kvmppc_host_cpu_class_init,
> > };
> > -MachineClass *mc = MACHINE_GET_CLASS(ms);
> > PowerPCCPUClass *pvr_pcc;
> > ObjectClass *oc;
> > DeviceClass *dc;
> > @@ -2552,10 +2558,9 @@ static int
> > kvm_ppc_register_host_cpu_type(MachineState *ms)
> > }
> > type_info.parent = object_class_get_name(OBJECT_CLASS(pvr_pcc));
> > type_register(_info);
> > -if (object_dynamic_cast(OBJECT(ms), TYPE_SPAPR_MACHINE)) {
> > -/* override TCG default cpu type with 'host' cpu model */
> > -mc->default_cpu_type = TYPE_HOST_POWERPC_CPU;
> > -}
> > +/* override TCG default cpu type with 'host' cpu model */
> > +object_class_foreach(pseries_machine_class_fixup, TYPE_SPAPR_MACHINE,
> > + false, NULL);
> > oc = object_class_by_name(type_info.name);
> > g_assert(oc);
> >
>
> Reviewed-by: David Hildenbrand
>
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
[RFC] q800: fix I/O memory map
Linux kernel 5.4 will introduce a new memory map for SWIM device.
(aee6bff1c325 ("m68k: mac: Revisit floppy disc controller base addresses"))
Until this release all MMIO are mapped between 0x50f0 and 0x50f4,
but it appears that for real hardware 0x50f0 is not the base address:
the MMIO region spans 0x5000 through 0x6000, and 0x5004 through
0x5400 is repeated images of 0x5000 to 0x5004.
Fixed: 04e7ca8d0f ("hw/m68k: define Macintosh Quadra 800")
Signed-off-by: Laurent Vivier
---
hw/m68k/q800.c | 33 +
1 file changed, 25 insertions(+), 8 deletions(-)
diff --git a/hw/m68k/q800.c b/hw/m68k/q800.c
index 2b4842f8c6..8122e7c612 100644
--- a/hw/m68k/q800.c
+++ b/hw/m68k/q800.c
@@ -60,14 +60,14 @@
#define MACH_MAC3
#define Q800_MAC_CPU_ID 2
-#define VIA_BASE 0x50f0
-#define SONIC_PROM_BASE 0x50f08000
-#define SONIC_BASE0x50f0a000
-#define SCC_BASE 0x50f0c020
-#define ESP_BASE 0x50f1
-#define ESP_PDMA 0x50f10100
-#define ASC_BASE 0x50F14000
-#define SWIM_BASE 0x50F1E000
+#define VIA_BASE 0x5000
+#define SONIC_PROM_BASE 0x50008000
+#define SONIC_BASE0x5000a000
+#define SCC_BASE 0x5000c020
+#define ESP_BASE 0x5001
+#define ESP_PDMA 0x50010100
+#define ASC_BASE 0x50014000
+#define SWIM_BASE 0x5001E000
#define NUBUS_SUPER_SLOT_BASE 0x6000
#define NUBUS_SLOT_BASE 0xf000
@@ -135,6 +135,7 @@ static void q800_init(MachineState *machine)
int32_t initrd_size;
MemoryRegion *rom;
MemoryRegion *ram;
+int i;
ram_addr_t ram_size = machine->ram_size;
const char *kernel_filename = machine->kernel_filename;
const char *initrd_filename = machine->initrd_filename;
@@ -163,10 +164,26 @@ static void q800_init(MachineState *machine)
cpu = M68K_CPU(cpu_create(machine->cpu_type));
qemu_register_reset(main_cpu_reset, cpu);
+/* RAM */
ram = g_malloc(sizeof(*ram));
memory_region_init_ram(ram, NULL, "m68k_mac.ram", ram_size, _abort);
memory_region_add_subregion(get_system_memory(), 0, ram);
+/*
+ * Memory from VIA_BASE to VIA_BASE + 0x4 is repeated
+ * from VIA_BASE + 0x4 to VIA_BASE + 0x400
+ */
+for (i = 1; i < 256; i++) {
+MemoryRegion *io = g_malloc(sizeof(*io));
+char *name = g_strdup_printf("mac_m68k.io[%d]", i);
+
+memory_region_init_alias(io, NULL, name, get_system_memory(),
+ VIA_BASE, 0x4);
+memory_region_add_subregion(get_system_memory(),
+VIA_BASE + i * 0x4, io);
+g_free(name);
+}
+
/* IRQ Glue */
irq = g_new0(GLUEState, 1);
--
2.21.0
[PULL 3/3] Acceptance test: update kernel for m68k/q800 test
From: Cleber Rosa
There's an updated version of the Debian package containing the m68k
Kernel.
Now, if the package gets updated again, the test won't fail, but will
be canceled. A more permanent solution is certainly needed.
Signed-off-by: Cleber Rosa
Reviewed-by: Alex Bennée
Tested-by: Alex Bennée
Message-Id: <20191029232320.12419-3-cr...@redhat.com>
Signed-off-by: Alex Bennée
diff --git a/tests/acceptance/boot_linux_console.py
b/tests/acceptance/boot_linux_console.py
index 880a4b31ee1..7e41cebd47d 100644
--- a/tests/acceptance/boot_linux_console.py
+++ b/tests/acceptance/boot_linux_console.py
@@ -480,14 +480,14 @@ class BootLinuxConsole(Test):
:avocado: tags=machine:q800
"""
deb_url = ('http://ftp.ports.debian.org/debian-ports/pool-m68k/main'
- '/l/linux/kernel-image-5.2.0-2-m68k-di_5.2.9-2_m68k.udeb')
-deb_hash = '0797e05129595f22f3c0142db5e199769a723bf9'
+ '/l/linux/kernel-image-5.3.0-1-m68k-di_5.3.7-1_m68k.udeb')
+deb_hash = '044954bb9be4160a3ce81f8bc1b5e856b75cccd1'
try:
deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash)
except OSError as exp:
self.cancel(exp)
kernel_path = self.extract_from_deb(deb_path,
-'/boot/vmlinux-5.2.0-2-m68k')
+'/boot/vmlinux-5.3.0-1-m68k')
self.vm.set_machine('q800')
self.vm.set_console()
--
2.20.1
[PULL 0/3] a couple of CI fixes
The following changes since commit 68d8ef4ec540682c3538d4963e836e43a211dd17: Merge remote-tracking branch 'remotes/stsquad/tags/pull-tcg-plugins-281019-4' into staging (2019-10-30 14:10:32 +) are available in the Git repository at: https://github.com/stsquad/qemu.git tags/pull-testing-next-311019-1 for you to fetch changes up to 2ecde8b2fb046516a0f2f53fb56b86db92d6fc13: Acceptance test: update kernel for m68k/q800 test (2019-10-31 09:58:20 +) Fixes to get CI green again - fix m68k acceptance tests (Cleber) - stop build breakage (Daniel) Cleber Rosa (2): Acceptance test: cancel test if m68k kernel packages goes missing Acceptance test: update kernel for m68k/q800 test Daniel P. Berrangé (1): tests: fix conditional for disabling XTS test tests/Makefile.include | 2 +- tests/acceptance/boot_linux_console.py | 11 +++ 2 files changed, 8 insertions(+), 5 deletions(-) -- 2.20.1
Re: [PULL for-4.2 0/1] softfp patch queue
On Wed, 30 Oct 2019 at 18:09, Richard Henderson wrote: > > Just one easy patch that made the cutoff. > > > r~ > > > The following changes since commit 16884391c750d0c5e863f55ad7146fc5181e: > > Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2019-10-29' > into staging (2019-10-29 20:06:08 +) > > are available in the Git repository at: > > https://github.com/rth7680/qemu.git tags/pull-sfp-20191030 > > for you to fetch changes up to 21381dcf0ca8fc822328e30570c8465ec4e52be9: > > softfp: Added hardfloat conversion from float32 to float64 (2019-10-30 > 19:03:37 +0100) > > > Use hardfloat for float32_to_float64 > > > Matus Kysel (1): > softfp: Added hardfloat conversion from float32 to float64 > > fpu/softfloat.c | 19 ++- Applied, thanks. Please update the changelog at https://wiki.qemu.org/ChangeLog/4.2 for any user-visible changes. -- PMM
