Re: [Qemu-devel] [PATCH v2 3/3] tests: Enhance qobject output to cover partial visit
Eric Blake writes:
> On 11/03/2016 11:42 AM, Markus Armbruster wrote:
>> Eric Blake writes:
>>
>>> Add a test that proves (at least when run under valgrind) that
>>> we are correctly handling allocated memory even when a visit
>>> is aborted in the middle for whatever other reason.
>>>
>>> See commit f24582d "qapi: fix double free in
>>> qmp_output_visitor_cleanup()" for a fix that was lacking
>>> testsuite exposure prior to this patch.
>>>
>>> Signed-off-by: Eric Blake
>
>>> +static void test_visitor_out_partial_visit(TestOutputVisitorData *data,
>>> + const void *unused)
>>> +{
>>> +/* Various checks that a mid-visit abort doesn't leak or double-free.
>>> */
>>> +const char *str = "hi";
>>> +Error *err = NULL;
>>> +UserDefAlternate uda = { .type = QTYPE_QDICT,
>>> + .u.udfu = { .integer = 1,
>>> + .string = (char *) "bye",
>>> + .enum1 = -1 } };
>
> ^ Not a valid enum value...
Now I see.
>>> +
>>> +/* Abort in the middle of an alternate. Alternates can't be
>>> + * virtually visited, so we get to inline the first half of
>>> + * visit_type_UserDefAlternate(). */
>>> +visit_start_alternate(data->ov, NULL, (GenericAlternate **)&obj,
>>> + sizeof(uda), false, &error_abort);
>>> +visit_start_struct(data->ov, NULL, NULL, 0, &error_abort);
>>> +visit_type_UserDefUnionBase_members(data->ov,
>>> +(UserDefUnionBase *)&uda.u.udfu,
>>> +&err);
>>> +error_free_or_abort(&err);
>>
>> Why does this fail?
>
> ...so visiting the UnionBase_members gripes loudly. But I see your
> point that more comments would be helpful.
Would you like to suggest a fixup for me to squash in on commit?
Re: [Qemu-devel] [RFC 13/17] pseries: Move CPU compatibility property to machine
On 30/10/16 22:12, David Gibson wrote:
> Server class POWER CPUs have a "compat" property, which is used to set the
> backwards compatibility mode for the processor. However, this only makes
> sense for machine types which don't give the guest access to hypervisor
> privilege - otherwise the compatibility level is under the guest's control.
>
> To reflect this, this removes the CPU 'compat' property and instead
> creates a 'max-cpu-compat' property on the pseries machine. Strictly
> speaking this breaks compatibility, but AFAIK the 'compat' option was
> never (directly) used with -device or device_add.
>
> The option was used with -cpu. So, to maintain compatibility, this patch
> adds a hack to the cpu option parsing to strip out any compat options
> supplied with -cpu and set them on the machine property instead of the new
> removed cpu property.
>
> Signed-off-by: David Gibson
> ---
> hw/ppc/spapr.c | 6 +++-
> hw/ppc/spapr_cpu_core.c | 47 +++--
> hw/ppc/spapr_hcall.c| 2 +-
> include/hw/ppc/spapr.h | 10 +--
> target-ppc/compat.c | 65
> target-ppc/cpu.h| 6 ++--
> target-ppc/translate_init.c | 73
> -
> 7 files changed, 127 insertions(+), 82 deletions(-)
>
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 6c78889..b983faa 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -1849,7 +1849,7 @@ static void ppc_spapr_init(MachineState *machine)
> machine->cpu_model = kvm_enabled() ? "host" : smc->tcg_default_cpu;
> }
>
> -ppc_cpu_parse_features(machine->cpu_model);
> +spapr_cpu_parse_features(spapr);
>
> spapr_init_cpus(spapr);
>
> @@ -2191,6 +2191,10 @@ static void spapr_machine_initfn(Object *obj)
> " place of standard EPOW events when
> possible"
> " (required for memory hot-unplug
> support)",
> NULL);
> +
> +object_property_add(obj, "max-cpu-compat", "str",
> +ppc_compat_prop_get, ppc_compat_prop_set,
> +NULL, &spapr->max_compat_pvr, &error_fatal);
> }
>
> static void spapr_machine_finalizefn(Object *obj)
> diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c
> index ee5cd14..0319516 100644
> --- a/hw/ppc/spapr_cpu_core.c
> +++ b/hw/ppc/spapr_cpu_core.c
> @@ -18,6 +18,49 @@
> #include "target-ppc/mmu-hash64.h"
> #include "sysemu/numa.h"
>
> +void spapr_cpu_parse_features(sPAPRMachineState *spapr)
> +{
> +/*
> + * Backwards compatibility hack:
> +
> + * CPUs had a "compat=" property which didn't make sense for
> + * anything except pseries. It was replaced by "max-cpu-compat"
> + * machine option. This supports old command lines like
> + * -cpu POWER8,compat=power7
> + * By stripping the compat option and applying it to the machine
> + * before passing it on to the cpu level parser.
> + */
> +gchar **inpieces, **outpieces;
> +int n, i, j;
> +gchar *compat_str = NULL;
> +gchar *filtered_model;
> +
> +inpieces = g_strsplit(MACHINE(spapr)->cpu_model, ",", 0);
> +n = g_strv_length(inpieces);
> +outpieces = g_new0(gchar *, g_strv_length(inpieces));
> +
> +/* inpieces[0] is the actual model string */
> +for (i = 0, j = 0; i < n; i++) {
> +if (g_str_has_prefix(inpieces[i], "compat=")) {
> +compat_str = inpieces[i];
> +} else {
> +outpieces[j++] = g_strdup(inpieces[i]);
> +}
> +}
> +
> +if (compat_str) {
> +char *val = compat_str + strlen("compat=");
> +object_property_set_str(OBJECT(spapr), val, "max-cpu-compat",
> +&error_fatal);
This part is ok.
> +}
> +
> +filtered_model = g_strjoinv(",", outpieces);
> +ppc_cpu_parse_features(filtered_model);
Rather than reducing the CPU parameters string from the command line, I'd
keep "dc->props = powerpc_servercpu_properties" and make them noop + warn
to use the machine option instead. One day QEMU may start calling the CPU
features parser itself and somebody will have to hack this thing again.
> +
> +g_strfreev(inpieces);
> +g_strfreev(outpieces);
> +}
> +
> static void spapr_cpu_reset(void *opaque)
> {
> sPAPRMachineState *spapr = SPAPR_MACHINE(qdev_get_machine());
> @@ -60,10 +103,10 @@ static void spapr_cpu_init(sPAPRMachineState *spapr,
> PowerPCCPU *cpu,
> cpu_ppc_set_vhyp(cpu, PPC_VIRTUAL_HYPERVISOR(spapr));
> cpu_ppc_set_papr(cpu);
>
> -if (cpu->max_compat) {
> +if (spapr->max_compat_pvr) {
> Error *local_err = NULL;
>
> -ppc_set_compat(cpu, cpu->max_compat, &local_err);
> +ppc_set_compat(cpu, spapr->max_compat_pvr, &local_err);
> if (local_err) {
> error_propagate(errp, loc
Re: [Qemu-devel] [RFC 14/17] pseries: Reset CPU compatibility mode
On 30/10/16 22:12, David Gibson wrote:
> Currently, the CPU compatibility mode is set when the cpu is initialized,
> then again when the guest negotiates features. This means if a guest
> negotiates a compatibility mode, then reboots, that compatibility mode
> will be retained across the reset.
>
> Usually that will get overridden when features are negotiated on the next
> boot, but it's still not really correct. This patch moves the initial set
> up of the compatibility mode from cpu init to reset time. The mode *is*
> retained if the reboot was caused by the feature negotiation (it might
> be important in that case, though it's unlikely).
>
> Signed-off-by: David Gibson
Reviewed-by: Alexey Kardashevskiy
> ---
> hw/ppc/spapr.c | 2 ++
> hw/ppc/spapr_cpu_core.c | 10 --
> 2 files changed, 2 insertions(+), 10 deletions(-)
>
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index b983faa..2aa0900 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -1169,6 +1169,8 @@ static void ppc_spapr_reset(void)
> if (!spapr->cas_reboot) {
> spapr_ovec_cleanup(spapr->ov5_cas);
> spapr->ov5_cas = spapr_ovec_new();
> +
> +ppc_set_compat_all(spapr->max_compat_pvr, &error_abort);
> }
>
> fdt = spapr_build_fdt(spapr, rtas_addr, spapr->rtas_size);
> diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c
> index 0319516..4b6134b 100644
> --- a/hw/ppc/spapr_cpu_core.c
> +++ b/hw/ppc/spapr_cpu_core.c
> @@ -103,16 +103,6 @@ static void spapr_cpu_init(sPAPRMachineState *spapr,
> PowerPCCPU *cpu,
> cpu_ppc_set_vhyp(cpu, PPC_VIRTUAL_HYPERVISOR(spapr));
> cpu_ppc_set_papr(cpu);
>
> -if (spapr->max_compat_pvr) {
> -Error *local_err = NULL;
> -
> -ppc_set_compat(cpu, spapr->max_compat_pvr, &local_err);
> -if (local_err) {
> -error_propagate(errp, local_err);
> -return;
> -}
> -}
> -
> /* Set NUMA node for the added CPUs */
> i = numa_get_node_for_cpu(cs->cpu_index);
> if (i < nb_numa_nodes) {
>
--
Alexey
Re: [Qemu-devel] [RFC 15/17] ppc: Check that CPU model stays consistent across migration
On 30/10/16 22:12, David Gibson wrote:
> When a vmstate for the ppc cpu was first introduced (a90db15 "target-ppc:
> Convert ppc cpu savevm to VMStateDescription"), a VMSTATE_EQUAL was used
> to ensure that identical CPU models were used at source and destination
> as based on the PVR (Processor Version Register).
>
> However this was a problem for HV KVM, where due to hardware limitations
> we always need to use the real PVR of the host CPU. So, to allow
> migration between hosts with "similar enough" CPUs, the PVR check was
> removed in 569be9f0 "target-ppc: Remove PVR check from migration". This
> left the onus on user / management to only attempt migration between
> compatible CPUs.
>
> Now that we've reworked the handling of compatiblity modes, we have the
> information to actually determine if we're making a compatible migration.
> So this patch partially restores the PVR check. If the source was running
> in a compatibility mode, we just make sure that the destination cpu can
> also run in that compatibility mode. However, if the source was running
> in "raw" mode, we verify that the destination has the same PVR value.
>
> Signed-off-by: David Gibson
> ---
> target-ppc/machine.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/target-ppc/machine.c b/target-ppc/machine.c
> index 5d87ff6..62b9e94 100644
> --- a/target-ppc/machine.c
> +++ b/target-ppc/machine.c
> @@ -173,10 +173,12 @@ static int cpu_post_load(void *opaque, int version_id)
> target_ulong msr;
>
> /*
> - * We always ignore the source PVR. The user or management
> - * software has to take care of running QEMU in a compatible mode.
> + * If we're operating in compat mode, we should be ok as long as
> + * the destination supports the same compatiblity mode.
> + *
> + * Otherwise, however, we require that the destination has exactly
> + * the same CPU model as the source.
> */
> -env->spr[SPR_PVR] = env->spr_cb[SPR_PVR].default_value;
>
> #if defined(TARGET_PPC64)
> if (cpu->compat_pvr) {
> @@ -188,8 +190,13 @@ static int cpu_post_load(void *opaque, int version_id)
> error_free(local_err);
> return -1;
> }
> -}
> +} else
> #endif
> +{
> +if (env->spr[SPR_PVR] != env->spr_cb[SPR_PVR].default_value) {
> +return -1;
> +}
> +}
This should break migration from host with PVR=004d0200 to host with
PVR=004d0201, what is the benefit of such limitation?
>
> env->lr = env->spr[SPR_LR];
> env->ctr = env->spr[SPR_CTR];
>
--
Alexey
Re: [Qemu-devel] [PATCH v5 0/5] nvdimm: hotplug support
On 11/04/2016 12:22 PM, Michael S. Tsirkin wrote:
On Fri, Nov 04, 2016 at 06:01:54AM +0200, Michael S. Tsirkin wrote:
On Fri, Nov 04, 2016 at 11:50:19AM +0800, Xiao Guangrong wrote:
On 11/04/2016 02:36 AM, Xiao Guangrong wrote:
Hi Michael,
This patchset can replace the patches from [PULL 36/47] to [PULL 39/47]
in your pull request:
[PULL 36/47] nvdimm acpi: prebuild nvdimm devices for available slots
[PULL 37/47] nvdimm acpi: introduce fit buffer
[PULL 38/47] nvdimm acpi: introduce _FIT
[PULL 39/47] pc: memhp: enable nvdimm device hotplug
Thanks for your patience also thank Igor and Stefan for their review.
Hi,
As the pull request has been upstream (Cool! :)), i will post
diff changes based on that.
Thanks!
Igor prefers seeing revert+patches, I prefer seeing a diff.
Can you send both? A global diff would be ok for me
as it's small and easy enough to generate.
Okay, this is the diff comparing upstream and this version (v5):
diff --git a/default-configs/mips-softmmu-common.mak
b/default-configs/mips-softmmu-common.mak
index 0394514..f0676f5 100644
--- a/default-configs/mips-softmmu-common.mak
+++ b/default-configs/mips-softmmu-common.mak
@@ -17,6 +17,7 @@ CONFIG_FDC=y
CONFIG_ACPI=y
CONFIG_ACPI_X86=y
CONFIG_ACPI_MEMORY_HOTPLUG=y
+CONFIG_ACPI_NVDIMM=y
CONFIG_ACPI_CPU_HOTPLUG=y
CONFIG_APM=y
CONFIG_I8257=y
diff --git a/docs/specs/acpi_mem_hotplug.txt b/docs/specs/acpi_mem_hotplug.txt
index cb26dd2..3df3620 100644
--- a/docs/specs/acpi_mem_hotplug.txt
+++ b/docs/specs/acpi_mem_hotplug.txt
@@ -4,9 +4,6 @@ QEMU<->ACPI BIOS memory hotplug interface
ACPI BIOS GPE.3 handler is dedicated for notifying OS about memory hot-add
and hot-remove events.
-ACPI BIOS GPE.4 handler is dedicated for notifying OS about nvdimm device
-hot-add and hot-remove events.
-
Memory hot-plug interface (IO port 0xa00-0xa17, 1-4 byte access):
---
0xa00:
diff --git a/docs/specs/acpi_nvdimm.txt b/docs/specs/acpi_nvdimm.txt
index 4aa5e3d..9ab6d9a 100644
--- a/docs/specs/acpi_nvdimm.txt
+++ b/docs/specs/acpi_nvdimm.txt
@@ -65,8 +65,8 @@ _FIT(Firmware Interface Table)
The detailed definition of the structure can be found at ACPI 6.0: 5.2.25
NVDIMM Firmware Interface Table (NFIT).
-QEMU NVDIMM Implemention
-
+QEMU NVDIMM Implementation
+==
QEMU uses 4 bytes IO Port starting from 0x0a18 and a RAM-based memory page
for NVDIMM ACPI.
@@ -82,6 +82,16 @@ Memory:
ACPI writes _DSM Input Data (based on the offset in the page):
[0x0 - 0x3]: 4 bytes, NVDIMM Device Handle, 0 is reserved for NVDIMM
Root device.
+
+The handle is completely QEMU internal thing, the values in
+range [1, 0x] indicate nvdimm device. Other values are
+reserved for other purposes.
+
+Reserved handles:
+0 is reserved for nvdimm root device named NVDR.
+0x1 is reserved for QEMU internal DSM function called on
+the root device.
+
[0x4 - 0x7]: 4 bytes, Revision ID, that is the Arg1 of _DSM method.
[0x8 - 0xB]: 4 bytes. Function Index, that is the Arg2 of _DSM method.
[0xC - 0xFFF]: 4084 bytes, the Arg3 of _DSM method.
@@ -127,28 +137,17 @@ _DSM process diagram:
| result from the page | | |
+--+ +--+
-Device Handle Reservation
--
-As we mentioned above, byte 0 ~ byte 3 in the DSM memory save NVDIMM device
-handle. The handle is completely QEMU internal thing, the values in range
-[0, 0x] indicate nvdimm device (O means nvdimm root device named NVDR),
-other values are reserved by other purpose.
-
-Current reserved handle:
-0x1 is reserved for QEMU internal DSM function called on the root
-device.
+NVDIMM hotplug
+--
+ACPI BIOS GPE.4 handler is dedicated for notifying OS about nvdimm device
+hot-add event.
QEMU internal use only _DSM function
-UUID, 648B9CF2-CDA1-4312-8AD9-49C4AF32BD62, is reserved for QEMU internal
-DSM function.
-
-There is the function introduced by QEMU and only used by QEMU internal.
-
1) Read FIT
- As we only reserved one page for NVDIMM ACPI it is impossible to map the
- whole FIT data to guest's address space. This function is used by _FIT
- method to read a piece of FIT data from QEMU.
+ _FIT method uses _DSM method to fetch NFIT structures blob from QEMU
+ in 1 page sized increments which are then concatenated and returned
+ as _FIT method result.
Input parameters:
Arg0 – UUID {set to 648B9CF2-CDA1-4312-8AD9-49C4AF32BD62}
@@ -156,29 +155,34 @@ There is the function introduced by QEMU and only used by
QEMU internal.
Arg2 - Function Index, 0x1
Arg3 - A package containing a buffer whose layout is as follows:
- +--+-+-+---
Re: [Qemu-devel] [PATCH v2 2/3] target-m68k: implement 680x0 movem
Le 03/11/2016 à 21:47, Richard Henderson a écrit :
> On 11/02/2016 03:15 PM, Laurent Vivier wrote:
>> +for (i = 15; i >= 0; i--, mask >>= 1) {
>> +if (mask & 1) {
>> +if ((insn & 7) + 8 == i &&
>> +m68k_feature(s->env, M68K_FEATURE_EXT_FULL)) {
>> +/* M68020+: if the addressing register is the
>> + * register moved to memory, the value written
>> + * is the initial value decremented by the
>> size of
>> + * the operation
>> + * M68000/M68010: the value is the initial value
>> + */
>> +TCGv tmp = tcg_temp_new();
>> +tcg_gen_sub_i32(tmp, mreg(i), incr);
>> +gen_store(s, opsize, addr, tmp);
>> +tcg_temp_free(tmp);
>> +} else {
>> +gen_store(s, opsize, addr, mreg(i));
>> +}
>> +if (mask != 1) {
>> +tcg_gen_sub_i32(addr, addr, incr);
>> +}
>> +}
>
> One more thing: This is pre-decrement. Why are you decrementing after
> the store? Seems to me this should be
>
>if (mask & 1) {
>tcg_gen_sub_i32(addr, addr, incr);
>if (REG(insn, 0) + 8 == i ...)
>...
>}
>
Because it has already been decremented by gen_lea()... so this a
problem if we have page fault, except if we use your "areg writeback"
series, and we will.
Thanks,
Laurent
Re: [Qemu-devel] [PATCH] s390x/kvm: fix run_on_cpu sigp conversions
On 11/02/2016 05:21 PM, Cornelia Huck wrote:
> Commit 14e6fe12a ("*_run_on_cpu: introduce run_on_cpu_data type")
> attempted to convert all users of run_on_cpu to use the new
> run_on_cpu_data type. It missed to change the called sigp_* routines,
> however. Fix that.
>
> Fixes: 14e6fe12a ("*_run_on_cpu: introduce run_on_cpu_data type")
> Signed-off-by: Cornelia Huck
> ---
> Peter, Stefan: This fixes building for s390x which is currently
> broken (at least with kvm enabled). Two questions:
> - Will you pick this up as a build fix, or should I do a pull req?
> - Can we do anything more to catch errors like this?
I think if Peter could apply this immediately this would help testing
the softfreeze code.
Acked-by: Christian Borntraeger
> ---
> target-s390x/kvm.c | 36 ++--
> 1 file changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
> index 36b4847..97afe02 100644
> --- a/target-s390x/kvm.c
> +++ b/target-s390x/kvm.c
> @@ -1401,10 +1401,10 @@ static void set_sigp_status(SigpInfo *si, uint64_t
> status)
> si->cc = SIGP_CC_STATUS_STORED;
> }
>
> -static void sigp_start(CPUState *cs, void *arg)
> +static void sigp_start(CPUState *cs, run_on_cpu_data arg)
> {
> S390CPU *cpu = S390_CPU(cs);
> -SigpInfo *si = arg;
> +SigpInfo *si = arg.host_ptr;
>
> if (s390_cpu_get_state(cpu) != CPU_STATE_STOPPED) {
> si->cc = SIGP_CC_ORDER_CODE_ACCEPTED;
> @@ -1415,10 +1415,10 @@ static void sigp_start(CPUState *cs, void *arg)
> si->cc = SIGP_CC_ORDER_CODE_ACCEPTED;
> }
>
> -static void sigp_stop(CPUState *cs, void *arg)
> +static void sigp_stop(CPUState *cs, run_on_cpu_data arg)
> {
> S390CPU *cpu = S390_CPU(cs);
> -SigpInfo *si = arg;
> +SigpInfo *si = arg.host_ptr;
> struct kvm_s390_irq irq = {
> .type = KVM_S390_SIGP_STOP,
> };
> @@ -1501,10 +1501,10 @@ static int kvm_s390_store_status(S390CPU *cpu, hwaddr
> addr, bool store_arch)
> return 0;
> }
>
> -static void sigp_stop_and_store_status(CPUState *cs, void *arg)
> +static void sigp_stop_and_store_status(CPUState *cs, run_on_cpu_data arg)
> {
> S390CPU *cpu = S390_CPU(cs);
> -SigpInfo *si = arg;
> +SigpInfo *si = arg.host_ptr;
> struct kvm_s390_irq irq = {
> .type = KVM_S390_SIGP_STOP,
> };
> @@ -1529,10 +1529,10 @@ static void sigp_stop_and_store_status(CPUState *cs,
> void *arg)
> si->cc = SIGP_CC_ORDER_CODE_ACCEPTED;
> }
>
> -static void sigp_store_status_at_address(CPUState *cs, void *arg)
> +static void sigp_store_status_at_address(CPUState *cs, run_on_cpu_data arg)
> {
> S390CPU *cpu = S390_CPU(cs);
> -SigpInfo *si = arg;
> +SigpInfo *si = arg.host_ptr;
> uint32_t address = si->param & 0x7e00u;
>
> /* cpu has to be stopped */
> @@ -1550,10 +1550,10 @@ static void sigp_store_status_at_address(CPUState
> *cs, void *arg)
> si->cc = SIGP_CC_ORDER_CODE_ACCEPTED;
> }
>
> -static void sigp_store_adtl_status(CPUState *cs, void *arg)
> +static void sigp_store_adtl_status(CPUState *cs, run_on_cpu_data arg)
> {
> S390CPU *cpu = S390_CPU(cs);
> -SigpInfo *si = arg;
> +SigpInfo *si = arg.host_ptr;
>
> if (!s390_has_feat(S390_FEAT_VECTOR)) {
> set_sigp_status(si, SIGP_STAT_INVALID_ORDER);
> @@ -1581,10 +1581,10 @@ static void sigp_store_adtl_status(CPUState *cs, void
> *arg)
> si->cc = SIGP_CC_ORDER_CODE_ACCEPTED;
> }
>
> -static void sigp_restart(CPUState *cs, void *arg)
> +static void sigp_restart(CPUState *cs, run_on_cpu_data arg)
> {
> S390CPU *cpu = S390_CPU(cs);
> -SigpInfo *si = arg;
> +SigpInfo *si = arg.host_ptr;
> struct kvm_s390_irq irq = {
> .type = KVM_S390_RESTART,
> };
> @@ -1612,11 +1612,11 @@ int kvm_s390_cpu_restart(S390CPU *cpu)
> return 0;
> }
>
> -static void sigp_initial_cpu_reset(CPUState *cs, void *arg)
> +static void sigp_initial_cpu_reset(CPUState *cs, run_on_cpu_data arg)
> {
> S390CPU *cpu = S390_CPU(cs);
> S390CPUClass *scc = S390_CPU_GET_CLASS(cpu);
> -SigpInfo *si = arg;
> +SigpInfo *si = arg.host_ptr;
>
> cpu_synchronize_state(cs);
> scc->initial_cpu_reset(cs);
> @@ -1624,11 +1624,11 @@ static void sigp_initial_cpu_reset(CPUState *cs, void
> *arg)
> si->cc = SIGP_CC_ORDER_CODE_ACCEPTED;
> }
>
> -static void sigp_cpu_reset(CPUState *cs, void *arg)
> +static void sigp_cpu_reset(CPUState *cs, run_on_cpu_data arg)
> {
> S390CPU *cpu = S390_CPU(cs);
> S390CPUClass *scc = S390_CPU_GET_CLASS(cpu);
> -SigpInfo *si = arg;
> +SigpInfo *si = arg.host_ptr;
>
> cpu_synchronize_state(cs);
> scc->cpu_reset(cs);
> @@ -1636,10 +1636,10 @@ static void sigp_cpu_reset(CPUState *cs, void *arg)
> si->cc = SIGP_CC_ORDER_CODE_ACCEPTED;
> }
>
> -static void sigp_set_prefix(CPUState *cs, void *arg)
> +static void sigp_set_prefix(CPUState *cs, run_on_cpu_data arg)
> {
> S390CPU
Re: [Qemu-devel] [PATCH] s390x/kvm: fix run_on_cpu sigp conversions
On 11/04/2016 09:23 AM, Christian Borntraeger wrote:
> On 11/02/2016 05:21 PM, Cornelia Huck wrote:
>> Commit 14e6fe12a ("*_run_on_cpu: introduce run_on_cpu_data type")
>> attempted to convert all users of run_on_cpu to use the new
>> run_on_cpu_data type. It missed to change the called sigp_* routines,
>> however. Fix that.
>>
>> Fixes: 14e6fe12a ("*_run_on_cpu: introduce run_on_cpu_data type")
>> Signed-off-by: Cornelia Huck
>> ---
>> Peter, Stefan: This fixes building for s390x which is currently
>> broken (at least with kvm enabled). Two questions:
>> - Will you pick this up as a build fix, or should I do a pull req?
>> - Can we do anything more to catch errors like this?
>
> I think if Peter could apply this immediately this would help testing
> the softfreeze code.
> Acked-by: Christian Borntraeger
>
s/Peter/Stefan/ of course.
>
>> ---
>> target-s390x/kvm.c | 36 ++--
>> 1 file changed, 18 insertions(+), 18 deletions(-)
>>
>> diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
>> index 36b4847..97afe02 100644
>> --- a/target-s390x/kvm.c
>> +++ b/target-s390x/kvm.c
>> @@ -1401,10 +1401,10 @@ static void set_sigp_status(SigpInfo *si, uint64_t
>> status)
>> si->cc = SIGP_CC_STATUS_STORED;
>> }
>>
>> -static void sigp_start(CPUState *cs, void *arg)
>> +static void sigp_start(CPUState *cs, run_on_cpu_data arg)
>> {
>> S390CPU *cpu = S390_CPU(cs);
>> -SigpInfo *si = arg;
>> +SigpInfo *si = arg.host_ptr;
>>
>> if (s390_cpu_get_state(cpu) != CPU_STATE_STOPPED) {
>> si->cc = SIGP_CC_ORDER_CODE_ACCEPTED;
>> @@ -1415,10 +1415,10 @@ static void sigp_start(CPUState *cs, void *arg)
>> si->cc = SIGP_CC_ORDER_CODE_ACCEPTED;
>> }
>>
>> -static void sigp_stop(CPUState *cs, void *arg)
>> +static void sigp_stop(CPUState *cs, run_on_cpu_data arg)
>> {
>> S390CPU *cpu = S390_CPU(cs);
>> -SigpInfo *si = arg;
>> +SigpInfo *si = arg.host_ptr;
>> struct kvm_s390_irq irq = {
>> .type = KVM_S390_SIGP_STOP,
>> };
>> @@ -1501,10 +1501,10 @@ static int kvm_s390_store_status(S390CPU *cpu,
>> hwaddr addr, bool store_arch)
>> return 0;
>> }
>>
>> -static void sigp_stop_and_store_status(CPUState *cs, void *arg)
>> +static void sigp_stop_and_store_status(CPUState *cs, run_on_cpu_data arg)
>> {
>> S390CPU *cpu = S390_CPU(cs);
>> -SigpInfo *si = arg;
>> +SigpInfo *si = arg.host_ptr;
>> struct kvm_s390_irq irq = {
>> .type = KVM_S390_SIGP_STOP,
>> };
>> @@ -1529,10 +1529,10 @@ static void sigp_stop_and_store_status(CPUState *cs,
>> void *arg)
>> si->cc = SIGP_CC_ORDER_CODE_ACCEPTED;
>> }
>>
>> -static void sigp_store_status_at_address(CPUState *cs, void *arg)
>> +static void sigp_store_status_at_address(CPUState *cs, run_on_cpu_data arg)
>> {
>> S390CPU *cpu = S390_CPU(cs);
>> -SigpInfo *si = arg;
>> +SigpInfo *si = arg.host_ptr;
>> uint32_t address = si->param & 0x7e00u;
>>
>> /* cpu has to be stopped */
>> @@ -1550,10 +1550,10 @@ static void sigp_store_status_at_address(CPUState
>> *cs, void *arg)
>> si->cc = SIGP_CC_ORDER_CODE_ACCEPTED;
>> }
>>
>> -static void sigp_store_adtl_status(CPUState *cs, void *arg)
>> +static void sigp_store_adtl_status(CPUState *cs, run_on_cpu_data arg)
>> {
>> S390CPU *cpu = S390_CPU(cs);
>> -SigpInfo *si = arg;
>> +SigpInfo *si = arg.host_ptr;
>>
>> if (!s390_has_feat(S390_FEAT_VECTOR)) {
>> set_sigp_status(si, SIGP_STAT_INVALID_ORDER);
>> @@ -1581,10 +1581,10 @@ static void sigp_store_adtl_status(CPUState *cs,
>> void *arg)
>> si->cc = SIGP_CC_ORDER_CODE_ACCEPTED;
>> }
>>
>> -static void sigp_restart(CPUState *cs, void *arg)
>> +static void sigp_restart(CPUState *cs, run_on_cpu_data arg)
>> {
>> S390CPU *cpu = S390_CPU(cs);
>> -SigpInfo *si = arg;
>> +SigpInfo *si = arg.host_ptr;
>> struct kvm_s390_irq irq = {
>> .type = KVM_S390_RESTART,
>> };
>> @@ -1612,11 +1612,11 @@ int kvm_s390_cpu_restart(S390CPU *cpu)
>> return 0;
>> }
>>
>> -static void sigp_initial_cpu_reset(CPUState *cs, void *arg)
>> +static void sigp_initial_cpu_reset(CPUState *cs, run_on_cpu_data arg)
>> {
>> S390CPU *cpu = S390_CPU(cs);
>> S390CPUClass *scc = S390_CPU_GET_CLASS(cpu);
>> -SigpInfo *si = arg;
>> +SigpInfo *si = arg.host_ptr;
>>
>> cpu_synchronize_state(cs);
>> scc->initial_cpu_reset(cs);
>> @@ -1624,11 +1624,11 @@ static void sigp_initial_cpu_reset(CPUState *cs,
>> void *arg)
>> si->cc = SIGP_CC_ORDER_CODE_ACCEPTED;
>> }
>>
>> -static void sigp_cpu_reset(CPUState *cs, void *arg)
>> +static void sigp_cpu_reset(CPUState *cs, run_on_cpu_data arg)
>> {
>> S390CPU *cpu = S390_CPU(cs);
>> S390CPUClass *scc = S390_CPU_GET_CLASS(cpu);
>> -SigpInfo *si = arg;
>> +SigpInfo *si = arg.host_ptr;
>>
>> cpu_synchronize_state(cs);
>> scc->cpu_reset(cs);
>> @@ -1636,10 +1636,10 @@ static void sigp_cpu_reset(CPUS
Re: [Qemu-devel] [PATCH v2 1/2] virtio: rename virtqueue_discard to virtqueue_unpop
On Fri, 4 Nov 2016 07:19:16 +0100 Ladi Prosek wrote: > On Fri, Nov 4, 2016 at 3:42 AM, Alexey Kardashevskiy wrote: > > On 03/11/16 19:55, Ladi Prosek wrote: > >> The function undoes the effect of virtqueue_pop and doesn't do anything > >> destructive or irreversible so virtqueue_unpop is a more fitting name. > > > > virtqueue_undo_pop() is even better, it was suggested by native english > > speaker (i.e. not myself) :) > > virtqueue_undo_pop sounds good too, I have no preference between the > two really :) Thanks! If you need a tie breaker: I like virtqueue_undo_pop() better :)
Re: [Qemu-devel] [PATCH v2 2/2] virtio: make virtqueue_alloc_element static
On Thu, 3 Nov 2016 09:55:50 +0100 Ladi Prosek wrote: > The function does not fully initialize the returned VirtQueueElement and > should > be used only internally from the virtio module. > > Signed-off-by: Ladi Prosek > --- > hw/virtio/virtio.c | 2 +- > include/hw/virtio/virtio.h | 1 - > 2 files changed, 1 insertion(+), 2 deletions(-) Reviewed-by: Cornelia Huck ...although I'm wondering if the callers could not pass in the index value as well? (Still keeping this internal to virtio.c makes sense.)
[Qemu-devel] [PATCH 0/3] vhost: fix vring layout
The vhost code currently assumes vring are mapped in memory following the
legacy virtio layout. This may cause QEMU to fail with virtio 1 devices
if the used ring is mapped below the descriptor table.
---
Greg Kurz (3):
vhost: adapt vhost_verify_ring_mappings() to virtio 1 ring layout
vhost: drop legacy vring layout bits
virtio: drop virtio_queue_get_ring_{size,addr}()
hw/virtio/vhost.c | 92 +---
hw/virtio/virtio.c | 11 -
include/hw/virtio/vhost.h |7 ++-
include/hw/virtio/virtio.h |2 -
4 files changed, 64 insertions(+), 48 deletions(-)
--
Greg
[Qemu-devel] [PATCH 1/3] vhost: adapt vhost_verify_ring_mappings() to virtio 1 ring layout
With virtio 1, the vring layout is split in 3 separate regions of
contiguous memory for the descriptor table, the available ring and the
used ring, as opposed with legacy virtio which uses a single region.
In case of memory re-mapping, the code ensures it doesn't affect the
vring mapping. This is done in vhost_verify_ring_mappings() which assumes
the device is legacy.
This patch changes vhost_verify_ring_mappings() to check the mappings of
each part of the vring separately.
Signed-off-by: Greg Kurz
---
hw/virtio/vhost.c | 79 ++---
include/hw/virtio/vhost.h |4 ++
2 files changed, 64 insertions(+), 19 deletions(-)
diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
index 131f1643b2a4..10133f12ebba 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vhost.c
@@ -421,32 +421,73 @@ static inline void vhost_dev_log_resize(struct vhost_dev
*dev, uint64_t size)
dev->log_size = size;
}
+
+static int vhost_verify_ring_part_mapping(void *part,
+ uint64_t part_addr,
+ uint64_t part_size,
+ uint64_t start_addr,
+ uint64_t size)
+{
+hwaddr l;
+void *p;
+int r = 0;
+
+if (!ranges_overlap(start_addr, size, part_addr, part_size)) {
+return 0;
+}
+l = part_size;
+p = cpu_physical_memory_map(part_addr, &l, 1);
+if (!p || l != part_size) {
+r = -ENOMEM;
+}
+if (p != part) {
+r = -EBUSY;
+}
+cpu_physical_memory_unmap(p, l, 0, 0);
+return r;
+}
+
static int vhost_verify_ring_mappings(struct vhost_dev *dev,
uint64_t start_addr,
uint64_t size)
{
-int i;
+int i, j;
int r = 0;
+const char *part_name[] = {
+"descriptor table",
+"available ring",
+"used ring"
+};
-for (i = 0; !r && i < dev->nvqs; ++i) {
+for (i = 0; i < dev->nvqs; ++i) {
struct vhost_virtqueue *vq = dev->vqs + i;
-hwaddr l;
-void *p;
-if (!ranges_overlap(start_addr, size, vq->ring_phys, vq->ring_size)) {
-continue;
+j = 0;
+r = vhost_verify_ring_part_mapping(vq->desc, vq->desc_phys,
+ vq->desc_size, start_addr, size);
+if (!r) {
+break;
}
-l = vq->ring_size;
-p = cpu_physical_memory_map(vq->ring_phys, &l, 1);
-if (!p || l != vq->ring_size) {
-error_report("Unable to map ring buffer for ring %d", i);
-r = -ENOMEM;
+
+j++;
+r = vhost_verify_ring_part_mapping(vq->avail, vq->avail_phys,
+ vq->avail_size, start_addr, size);
+if (!r) {
+break;
}
-if (p != vq->ring) {
-error_report("Ring buffer relocated for ring %d", i);
-r = -EBUSY;
+
+j++;
+r = vhost_verify_ring_part_mapping(vq->used, vq->used_phys,
+ vq->used_size, start_addr, size);
+if (!r) {
+break;
}
-cpu_physical_memory_unmap(p, l, 0, 0);
+}
+
+if (r == -ENOMEM) {
+error_report("Unable to map %s for ring %d", part_name[j], i);
+} else if (r == -EBUSY) {
+error_report("%s relocated for ring %d", part_name[j], i);
}
return r;
}
@@ -860,15 +901,15 @@ static int vhost_virtqueue_start(struct vhost_dev *dev,
}
}
-s = l = virtio_queue_get_desc_size(vdev, idx);
-a = virtio_queue_get_desc_addr(vdev, idx);
+vq->desc_size = s = l = virtio_queue_get_desc_size(vdev, idx);
+vq->desc_phys = a = virtio_queue_get_desc_addr(vdev, idx);
vq->desc = cpu_physical_memory_map(a, &l, 0);
if (!vq->desc || l != s) {
r = -ENOMEM;
goto fail_alloc_desc;
}
-s = l = virtio_queue_get_avail_size(vdev, idx);
-a = virtio_queue_get_avail_addr(vdev, idx);
+vq->avail_size = s = l = virtio_queue_get_avail_size(vdev, idx);
+vq->avail_phys = a = virtio_queue_get_avail_addr(vdev, idx);
vq->avail = cpu_physical_memory_map(a, &l, 0);
if (!vq->avail || l != s) {
r = -ENOMEM;
diff --git a/include/hw/virtio/vhost.h b/include/hw/virtio/vhost.h
index e433089ea97f..56b567f1997f 100644
--- a/include/hw/virtio/vhost.h
+++ b/include/hw/virtio/vhost.h
@@ -14,6 +14,10 @@ struct vhost_virtqueue {
void *avail;
void *used;
int num;
+unsigned long long desc_phys;
+unsigned desc_size;
+unsigned long long avail_phys;
+unsigned avail_size;
unsigned long long used_phys;
unsigned used_size;
void *ring;
[Qemu-devel] [PATCH 3/3] virtio: drop virtio_queue_get_ring_{size, addr}()
These are not used anymore.
Signed-off-by: Greg Kurz
---
hw/virtio/virtio.c | 11 ---
include/hw/virtio/virtio.h |2 --
2 files changed, 13 deletions(-)
diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index bcbcfe063c19..8f3e07effcb0 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -1935,11 +1935,6 @@ hwaddr virtio_queue_get_used_addr(VirtIODevice *vdev,
int n)
return vdev->vq[n].vring.used;
}
-hwaddr virtio_queue_get_ring_addr(VirtIODevice *vdev, int n)
-{
-return vdev->vq[n].vring.desc;
-}
-
hwaddr virtio_queue_get_desc_size(VirtIODevice *vdev, int n)
{
return sizeof(VRingDesc) * vdev->vq[n].vring.num;
@@ -1957,12 +1952,6 @@ hwaddr virtio_queue_get_used_size(VirtIODevice *vdev,
int n)
sizeof(VRingUsedElem) * vdev->vq[n].vring.num;
}
-hwaddr virtio_queue_get_ring_size(VirtIODevice *vdev, int n)
-{
-return vdev->vq[n].vring.used - vdev->vq[n].vring.desc +
- virtio_queue_get_used_size(vdev, n);
-}
-
uint16_t virtio_queue_get_last_avail_idx(VirtIODevice *vdev, int n)
{
return vdev->vq[n].last_avail_idx;
diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
index ac65d6a5941d..87c0c70cb407 100644
--- a/include/hw/virtio/virtio.h
+++ b/include/hw/virtio/virtio.h
@@ -255,11 +255,9 @@ typedef struct VirtIORNGConf VirtIORNGConf;
hwaddr virtio_queue_get_desc_addr(VirtIODevice *vdev, int n);
hwaddr virtio_queue_get_avail_addr(VirtIODevice *vdev, int n);
hwaddr virtio_queue_get_used_addr(VirtIODevice *vdev, int n);
-hwaddr virtio_queue_get_ring_addr(VirtIODevice *vdev, int n);
hwaddr virtio_queue_get_desc_size(VirtIODevice *vdev, int n);
hwaddr virtio_queue_get_avail_size(VirtIODevice *vdev, int n);
hwaddr virtio_queue_get_used_size(VirtIODevice *vdev, int n);
-hwaddr virtio_queue_get_ring_size(VirtIODevice *vdev, int n);
uint16_t virtio_queue_get_last_avail_idx(VirtIODevice *vdev, int n);
void virtio_queue_set_last_avail_idx(VirtIODevice *vdev, int n, uint16_t idx);
void virtio_queue_invalidate_signalled_used(VirtIODevice *vdev, int n);
[Qemu-devel] [PATCH 2/3] vhost: drop legacy vring layout bits
The legacy vring layout is not used anymore. This patch simply removes it.
This also fixes a bug with virtio 1 devices when the vring descriptor table
is mapped at a higher address than the used vring because the following
function may return an insanely great value:
hwaddr virtio_queue_get_ring_size(VirtIODevice *vdev, int n)
{
return vdev->vq[n].vring.used - vdev->vq[n].vring.desc +
virtio_queue_get_used_size(vdev, n);
}
and the mapping fails.
Signed-off-by: Greg Kurz
---
hw/virtio/vhost.c | 13 -
include/hw/virtio/vhost.h |3 ---
2 files changed, 16 deletions(-)
diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
index 10133f12ebba..9fa81c9b65cb 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vhost.c
@@ -923,14 +923,6 @@ static int vhost_virtqueue_start(struct vhost_dev *dev,
goto fail_alloc_used;
}
-vq->ring_size = s = l = virtio_queue_get_ring_size(vdev, idx);
-vq->ring_phys = a = virtio_queue_get_ring_addr(vdev, idx);
-vq->ring = cpu_physical_memory_map(a, &l, 1);
-if (!vq->ring || l != s) {
-r = -ENOMEM;
-goto fail_alloc_ring;
-}
-
r = vhost_virtqueue_set_addr(dev, vq, vhost_vq_index, dev->log_enabled);
if (r < 0) {
r = -errno;
@@ -971,9 +963,6 @@ static int vhost_virtqueue_start(struct vhost_dev *dev,
fail_vector:
fail_kick:
fail_alloc:
-cpu_physical_memory_unmap(vq->ring, virtio_queue_get_ring_size(vdev, idx),
- 0, 0);
-fail_alloc_ring:
cpu_physical_memory_unmap(vq->used, virtio_queue_get_used_size(vdev, idx),
0, 0);
fail_alloc_used:
@@ -1014,8 +1003,6 @@ static void vhost_virtqueue_stop(struct vhost_dev *dev,
vhost_vq_index);
}
-cpu_physical_memory_unmap(vq->ring, virtio_queue_get_ring_size(vdev, idx),
- 0, virtio_queue_get_ring_size(vdev, idx));
cpu_physical_memory_unmap(vq->used, virtio_queue_get_used_size(vdev, idx),
1, virtio_queue_get_used_size(vdev, idx));
cpu_physical_memory_unmap(vq->avail, virtio_queue_get_avail_size(vdev,
idx),
diff --git a/include/hw/virtio/vhost.h b/include/hw/virtio/vhost.h
index 56b567f1997f..1fe5aadef5ce 100644
--- a/include/hw/virtio/vhost.h
+++ b/include/hw/virtio/vhost.h
@@ -20,9 +20,6 @@ struct vhost_virtqueue {
unsigned avail_size;
unsigned long long used_phys;
unsigned used_size;
-void *ring;
-unsigned long long ring_phys;
-unsigned ring_size;
EventNotifier masked_notifier;
};
Re: [Qemu-devel] [PATCH 1/5] ARM BE8/BE32 semihosting and gdbstub support.
On 04/11/2016 00:34, Julian Brown wrote: > > So (IIRC!) the gdbstub needs to interpret some of these read/write > values on the host, i.e. in host byte ordering. "Traditionally", the > ldl_p and stl_p (etc.) macros would byteswap depending on the > TARGET_WORDS_BIGENDIAN setting -- that's how come our internal testing > using QEMU worked at all in the past. But that's changed with the > single-binary-for-all-endiannesses patches. I'm not sure what you mean here... BE8 wasn't supported at all in system emulation mode before those patches, and there are still two binaries for user-mode little-endian on one side and BE8/BE32 on the other. The details of how QEMU distinguished BE8 from BE32 changed (from bswap_code to SCTLR.B and CPSR.E) but TARGET_WORDS_BIGENDIAN remained set for qemu-armeb. The difference for user-mode in fact was very small; for system mode emulation it was larger because QEMU grew support for all three of CPSR.E, SCTLR.B and SCTLR.EE. But then again there was no qemu-system-armeb before, maybe it was something you had in your internal QEMU? That said, if indeed gdb expects wire endianness to match ELF endianness, you have to do something about it indeed in the gdbstub. But it seems weird to look at CPSR.E, as that would flip values across SETEND. SCTLR.B|SCTLR.EE seems more plausible. The addition of a CPU property for reset, as suggested by Peter, would then make a lot of sense. Each CPU initfn would then look at that property and use it to initialize (depending on the model) either SCTLR.B or SCTLR.EE. The change to arm_cpu_memory_rw_debug for BE32 is also interesting. gdb documentation says The stub need not use any particular size or alignment when gathering data from memory for the response; even if ADDR is word-aligned and LENGTH is a multiple of the word size, the stub is free to use byte accesses, or not. while your change means that gdb actually wants you to do byte accesses. Paolo > So -- all uses of ld*_p and st*_p, and the TARGET_WORDS_BIGENDIAN > macro, are now suspect in ARM system-emulation mode. The gdbstub.c > changes appear to fix some of those, but... yeah, there may be > subtleties remaining, like run-time endian switching by the target. > Generally it's not ideal, but I'm not sure how to do better.
Re: [Qemu-devel] [PATCH v2 0/3] target-m68k areg writeback
Le 03/11/2016 à 21:50, Richard Henderson a écrit : > Changes since v1: > * writeback_mask initialized > * the two cmpm patches are squashed. > Applied to git://github.com/vivier/qemu-m68k.git m68k-for-2.9 Waiting the end of freeze... Thanks, Laurent
Re: [Qemu-devel] [PATCH 4/5] ARM BE32 watchpoint fix.
On 04/11/2016 00:20, Julian Brown wrote:
> On Thu, 3 Nov 2016 23:14:05 +
> Peter Maydell wrote:
>
>> On 3 November 2016 at 17:30, Julian Brown
>> wrote:
>>> In BE32 mode, sub-word size watchpoints can fail to trigger because
>>> the address of the access is adjusted in the opcode helpers before
>>> being compared with the watchpoint registers. This patch reversed
>>> the address adjustment before performing the comparison.
>>>
>>> Signed-off-by: Julian Brown
>>> ---
>>> exec.c | 13 +
>>> 1 file changed, 13 insertions(+)
>>>
>>> diff --git a/exec.c b/exec.c
>>> index 4c84389..eadab54 100644
>>> --- a/exec.c
>>> +++ b/exec.c
>>> @@ -2047,6 +2047,19 @@ static void check_watchpoint(int offset, int
>>> len, MemTxAttrs attrs, int flags) return;
>>> }
>>> vaddr = (cpu->mem_io_vaddr & TARGET_PAGE_MASK) + offset;
>>> +#if defined(TARGET_ARM) && !defined(CONFIG_USER_ONLY)
>>> +/* In BE32 system mode, target memory is stored byteswapped
>>> (FIXME:
>>> + relative to a little-endian host system), and by the time
>>> we reach here
>>> + (via an opcode helper) the addresses of subword accesses
>>> have been
>>> + adjusted to account for that, which means that watchpoints
>>> will not
>>> + match. Undo the adjustment here. */
>>> +if (arm_sctlr_b(env)) {
>>> +if (len == 1)
>>> +vaddr ^= 3;
>>> +else if (len == 2)
>>> +vaddr ^= 2;
>>> +}
>>> +#endif
>>
>> No target-CPU specific code in exec.c, please...
>
> Yeah, I'd imagine not. I struggled with this one. Any suggestions for a
> better way to do this?
You can add a function pointer to CPUClass and call it from here. It's
how cc->debug_check_watchpoint is being called already.
Paolo
Re: [Qemu-devel] [PATCH 3/5] Fix arm_semi_flen_cb for BE32 system mode.
On 03/11/2016 18:30, Julian Brown wrote:
> +#ifdef CONFIG_USER_ONLY
> size = be32_to_cpu(size);
> +#else
> +/* If we're running in BE32 system mode, we don't need to do an explicit
> + * byte swap, because (I think) target memory is already stored in
> + * byte-swapped format.
Isn't this true also of user-mode (both BE8 and BE32)?
Paolo
> + */
> +if (!arm_sctlr_b(env)) {
> +size = be32_to_cpu(size);
> +}
> +#endif
Re: [Qemu-devel] [PATCH 1/5] ARM BE8/BE32 semihosting and gdbstub support.
On 03/11/2016 23:23, Peter Maydell wrote: > (For the rest of the series: you've missed the 2.8 > freeze, and I'm on holiday for most of November, so > it may be a while before I can get to it; hopefully > somebody else will step up and have a look at it.) 2/4/5 are relatively obvious bugfixes (in particular patch 5 is completely trivial). I commented separately on patch 3. Paolo
Re: [Qemu-devel] [PATCH] s390x/kvm: fix run_on_cpu sigp conversions
On 02/11/2016 17:21, Cornelia Huck wrote:
> Commit 14e6fe12a ("*_run_on_cpu: introduce run_on_cpu_data type")
> attempted to convert all users of run_on_cpu to use the new
> run_on_cpu_data type. It missed to change the called sigp_* routines,
> however. Fix that.
>
> Fixes: 14e6fe12a ("*_run_on_cpu: introduce run_on_cpu_data type")
> Signed-off-by: Cornelia Huck
> ---
> Peter, Stefan: This fixes building for s390x which is currently
> broken (at least with kvm enabled). Two questions:
> - Will you pick this up as a build fix, or should I do a pull req?
> - Can we do anything more to catch errors like this?
Fam, can we use the linux-user support in tests/docker to build QEMU
with KVM support on ARM/MIPS/s390? It would be already much better,
even if it obviously cannot run with KVM.
Paolo
Re: [Qemu-devel] [PATCH v5 0/5] nvdimm: hotplug support
On Fri, Nov 04, 2016 at 06:22:26AM +0200, Michael S. Tsirkin wrote: > On Fri, Nov 04, 2016 at 06:01:54AM +0200, Michael S. Tsirkin wrote: > > On Fri, Nov 04, 2016 at 11:50:19AM +0800, Xiao Guangrong wrote: > > > On 11/04/2016 02:36 AM, Xiao Guangrong wrote: > > > > Hi Michael, > > > > > > > > This patchset can replace the patches from [PULL 36/47] to [PULL 39/47] > > > > in your pull request: > > > > [PULL 36/47] nvdimm acpi: prebuild nvdimm devices for available slots > > > > [PULL 37/47] nvdimm acpi: introduce fit buffer > > > > [PULL 38/47] nvdimm acpi: introduce _FIT > > > > [PULL 39/47] pc: memhp: enable nvdimm device hotplug > > > > > > > > Thanks for your patience also thank Igor and Stefan for their review. > > > > > > Hi, > > > > > > As the pull request has been upstream (Cool! :)), i will post > > > diff changes based on that. > > > > > > Thanks! > > > > Igor prefers seeing revert+patches, I prefer seeing a diff. > > Can you send both? A global diff would be ok for me > > as it's small and easy enough to generate. > > Stefan, I wonder what's easier for you to review? Since it has been merged into qemu.git/master I'd now like to see follow-up patches. Not a global diff but real individual changes on top of qemu.git/master. These fixes can be merged during softfreeze. Stefan signature.asc Description: PGP signature
Re: [Qemu-devel] [PATCH v2] target-sh4: add atomic tas
On 11/03/2016 05:21 PM, Laurent Vivier wrote: > It should,:the problem was reported by Adrian (cc:) while compiling ghc > in qemu-sh4, but I have just tested the functionality with the softmmu > version, not the atomicity. > > Adrian, could you test this patch? Will absolutely do that. Awesome to see progress here :). I just can't do it right now as I just returned from Asia and just came to the office to go through a long backlog of work and mail. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [Qemu-devel] Mentor Summit notes
Hey Stefan, Thanks for the feedback. Le 01/11/2016 à 10:31, Stefan Hajnoczi a écrit : Valentine and I attended Google Summer of Code Mentor Summit on behalf of QEMU. The event brings together GSoC mentors from all participating organizations. A lot of people benefit from QEMU and told me so at the summit. There are also many who hadn't heard of QEMU before. I gave a lightning talk about Pranith Kumar's MTTCG project since it's a good example of a QEMU project: https://docs.google.com/presentation/d/1kidkMp4k-ak180aI-eZQfWuIEpQoeY-0N-oqt9eZo20/edit?usp=sharing Feedback from Mentor Summit: 1. Pavel Pisa wants to upstream CAN bus support. I asked him to rebase and submit the patches. Please take a look when patches are posted. I'm interested in this and can help for the review. Thanks, Fred 2. RTEMS mentioned they sometimes rely on out-of-tree QEMU targets and want to encourage authors to upstream their code. Xilinx was mentioned in particular. 3. Wine brainstormed x86 Windows applications on ARM using qemu-user-x86 + wine (x86). Probably requires multithreaded TCG. Work required to get OpenGL and other native features passed through. Talk to Stefan Dösinger (Wine) if interested. Stefan
[Qemu-devel] [PATCH RFC v2] tcmu: Introduce qemu-tcmu
libtcmu is a Linux library for userspace programs to handle TCMU protocol, which is a SCSI transport between the target_core_user.ko and a userspace backend implementation. The former can be seen as a kernel SCSI Low-Level-Driver that forwards scsi requests to userspace via a UIO ring buffer. By linking to libtcmu, a program can serve as a scsi HBA. This patch adds qemu-tcmu utility that serves as a LIO userspace backend. Apart from how it interacts with the rest of the world, the role of qemu-tcmu is much alike to qemu-nbd: it can export any format/protocol that QEMU supports (in iscsi/loopback instead of NBD), for local or remote access. The main advantage with qemu-tcmu lies in the more flexible command protocol (SCSI) and more flexible iscsi or loopback frontends, the latter of which can theoretically allow zero-copy I/O from local machine, which makes qemu-tcmu potentially possible to serve data in better performance. RFC because only minimal scsi commands are now handled. The plan is to refactor and reuse scsi-disk emulation code. Also there is no test code. Similar to NBD, there will be QMP commands to start built-in targets so that guest images can be exported as well. Usage example script (tested on Fedora 24): set -e # For targetcli integration sudo systemctl start tcmu-runner qemu-img create test-img 1G # libtcmu needs to open UIO, give it access sudo chmod 777 /dev/uio0 qemu-tcmu test-img & sleep 1 IQN=iqn.2003-01.org.linux-iscsi.lemon.x8664:sn.4939fc29108f # Check that we have initialized correctly sudo targetcli ls | grep -q user:qemu # Create iscsi target sudo targetcli ls | grep -q $IQN || sudo targetcli /iscsi create wwn=$IQN sudo targetcli /iscsi/$IQN/tpg1 set attribute \ authentication=0 generate_node_acls=1 demo_mode_write_protect=0 \ prod_mode_write_protect=0 # Create the qemu-tcmu target sudo targetcli ls | grep -q d0 || \ sudo targetcli /backstores/user:qemu create d0 1G @drive # Export it as an iscsi LUN sudo targetcli ls | grep -q lun0 || \ sudo targetcli /iscsi/$IQN/tpg1/luns create storage_object=/backstores/user:qemu/d0 # Inspect the nodes again sudo targetcli ls # Test that the LIO export works qemu-img info iscsi://127.0.0.1/$IQN/0 qemu-io iscsi://127.0.0.1/$IQN/0 \ -c 'read -P 1 4k 1k' \ -c 'write -P 2 4k 1k' \ -c 'read -P 2 4k 1k' \ Signed-off-by: Fam Zheng --- v2: Two small fixes to help proof testing of this prototype: Fix READ CAPACITY. [Prasanna] Fix qiov. [Stefan] --- Makefile| 1 + Makefile.objs | 4 +- configure | 45 ++ include/scsi/tcmu.h | 11 ++ qemu-tcmu.c | 401 scsi/Makefile.objs | 5 + scsi/tcmu.c | 338 +++ 7 files changed, 803 insertions(+), 2 deletions(-) create mode 100644 include/scsi/tcmu.h create mode 100644 qemu-tcmu.c create mode 100644 scsi/Makefile.objs create mode 100644 scsi/tcmu.c diff --git a/Makefile b/Makefile index 474cc5e..200cdad 100644 --- a/Makefile +++ b/Makefile @@ -251,6 +251,7 @@ qemu-img.o: qemu-img-cmds.h qemu-img$(EXESUF): qemu-img.o $(block-obj-y) $(crypto-obj-y) $(io-obj-y) $(qom-obj-y) libqemuutil.a libqemustub.a qemu-nbd$(EXESUF): qemu-nbd.o $(block-obj-y) $(crypto-obj-y) $(io-obj-y) $(qom-obj-y) libqemuutil.a libqemustub.a qemu-io$(EXESUF): qemu-io.o $(block-obj-y) $(crypto-obj-y) $(io-obj-y) $(qom-obj-y) libqemuutil.a libqemustub.a +qemu-tcmu$(EXESUF): qemu-tcmu.o $(block-obj-y) $(crypto-obj-y) $(io-obj-y) $(qom-obj-y) libqemuutil.a libqemustub.a qemu-bridge-helper$(EXESUF): qemu-bridge-helper.o libqemuutil.a libqemustub.a diff --git a/Makefile.objs b/Makefile.objs index 06f74b8..303eb25 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -13,11 +13,11 @@ block-obj-y += block.o blockjob.o block-obj-y += main-loop.o iohandler.o qemu-timer.o block-obj-$(CONFIG_POSIX) += aio-posix.o block-obj-$(CONFIG_WIN32) += aio-win32.o -block-obj-y += block/ +block-obj-y += block/ scsi/ block-obj-y += qemu-io-cmds.o block-obj-$(CONFIG_REPLICATION) += replication.o -block-obj-m = block/ +block-obj-m = block/ scsi/ ### # crypto-obj-y is code used by both qemu system emulation and qemu-img diff --git a/configure b/configure index fd6f898..8c756ad 100755 --- a/configure +++ b/configure @@ -209,6 +209,7 @@ netmap="no" pixman="" sdl="" sdlabi="" +tcmu="" virtfs="" vnc="yes" sparse="no" @@ -830,6 +831,10 @@ for opt do ;; --without-pixman) pixman="none" ;; + --enable-tcmu) tcmu="yes" + ;; + --disable-tcmu) tcmu="no" + ;; --disable-sdl) sdl="no" ;; --enable-sdl) sdl="yes" @@ -3128,6 +3133,36 @@ else fi ## +# tcmu support probe + +if test "$tcmu" != "no"; then + #
Re: [Qemu-devel] [PATCH 1/3] vhost: adapt vhost_verify_ring_mappings() to virtio 1 ring layout
On Fri, 04 Nov 2016 09:39:15 +0100 Greg Kurz wrote: > With virtio 1, the vring layout is split in 3 separate regions of > contiguous memory for the descriptor table, the available ring and the > used ring, as opposed with legacy virtio which uses a single region. > > In case of memory re-mapping, the code ensures it doesn't affect the > vring mapping. This is done in vhost_verify_ring_mappings() which assumes > the device is legacy. > > This patch changes vhost_verify_ring_mappings() to check the mappings of > each part of the vring separately. Add "This will work for legacy mappings as well." ? > > Signed-off-by: Greg Kurz > --- > hw/virtio/vhost.c | 79 > ++--- > include/hw/virtio/vhost.h |4 ++ > 2 files changed, 64 insertions(+), 19 deletions(-) Reviewed-by: Cornelia Huck
Re: [Qemu-devel] [PULL 0/2] tags/xen-20161102-tag
On Wed, Nov 02, 2016 at 01:54:25PM -0700, Stefano Stabellini wrote: > The following changes since commit 4eb28abd52d48657cff6ff45e8dbbbefe4dbb414: > > Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20161101-2' into > staging (2016-11-01 16:53:05 +) > > are available in the git repository at: > > > git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20161102-tag > > for you to fetch changes up to 021746c131cdfeab9d82ff918795a9f18d20d7ae: > > PCMachineState: introduce acpi_build_enabled field (2016-11-02 12:26:12 > -0700) > > > Xen 2016/11/02 > > > Thomas Huth (1): > hw/xen/xen_pvdev: Include qemu/log.h for qemu_log_vprintf() > > Wei Liu (1): > PCMachineState: introduce acpi_build_enabled field > > hw/i386/acpi-build.c | 2 +- > hw/i386/pc.c | 2 ++ > hw/xen/xen_pvdev.c | 2 +- > include/hw/i386/pc.h | 2 ++ > xen-common.c | 6 ++ > 5 files changed, 12 insertions(+), 2 deletions(-) > Thanks, applied to my staging tree: https://github.com/stefanha/qemu/commits/staging Stefan signature.asc Description: PGP signature
Re: [Qemu-devel] [PATCH 2/3] vhost: drop legacy vring layout bits
On Fri, 04 Nov 2016 09:39:22 +0100
Greg Kurz wrote:
> The legacy vring layout is not used anymore.
"as we use separate mappings even for legacy devices." ?
Otherwise, this may confuse the casual reader into thinking legacy is
not supported anymore.
> This patch simply removes it.
>
> This also fixes a bug with virtio 1 devices when the vring descriptor table
> is mapped at a higher address than the used vring because the following
> function may return an insanely great value:
>
> hwaddr virtio_queue_get_ring_size(VirtIODevice *vdev, int n)
> {
> return vdev->vq[n].vring.used - vdev->vq[n].vring.desc +
>virtio_queue_get_used_size(vdev, n);
> }
>
> and the mapping fails.
>
> Signed-off-by: Greg Kurz
> ---
> hw/virtio/vhost.c | 13 -
> include/hw/virtio/vhost.h |3 ---
> 2 files changed, 16 deletions(-)
Reviewed-by: Cornelia Huck
Re: [Qemu-devel] [PATCH 3/3] virtio: drop virtio_queue_get_ring_{size, addr}()
On Fri, 04 Nov 2016 09:39:29 +0100 Greg Kurz wrote: > These are not used anymore. > > Signed-off-by: Greg Kurz > --- > hw/virtio/virtio.c | 11 --- > include/hw/virtio/virtio.h |2 -- > 2 files changed, 13 deletions(-) Reviewed-by: Cornelia Huck
Re: [Qemu-devel] [PATCH RFC v2] tcmu: Introduce qemu-tcmu
Hi, Your series failed automatic build test. Please find the testing commands and their output below. If you have docker installed, you can probably reproduce it locally. Type: series Subject: [Qemu-devel] [PATCH RFC v2] tcmu: Introduce qemu-tcmu Message-id: 1478252049-15867-1-git-send-email-f...@redhat.com === TEST SCRIPT BEGIN === #!/bin/bash set -e git submodule update --init dtc # Let docker tests dump environment info export SHOW_ENV=1 export J=16 make docker-test-quick@centos6 make docker-test-mingw@fedora === TEST SCRIPT END === Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384 Switched to a new branch 'test' 2b58d20 tcmu: Introduce qemu-tcmu === OUTPUT BEGIN === Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc' Cloning into 'dtc'... Submodule path 'dtc': checked out '65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf' BUILD centos6 make[1]: Entering directory `/var/tmp/patchew-tester-tmp-pybbxn5_/src' ARCHIVE qemu.tgz ARCHIVE dtc.tgz COPYRUNNER RUN test-quick in qemu:centos6 Packages installed: SDL-devel-1.2.14-7.el6_7.1.x86_64 ccache-3.1.6-2.el6.x86_64 epel-release-6-8.noarch gcc-4.4.7-17.el6.x86_64 git-1.7.1-4.el6_7.1.x86_64 glib2-devel-2.28.8-5.el6.x86_64 libfdt-devel-1.4.0-1.el6.x86_64 make-3.81-23.el6.x86_64 package g++ is not installed pixman-devel-0.32.8-1.el6.x86_64 tar-1.23-15.el6_8.x86_64 zlib-devel-1.2.3-29.el6.x86_64 Environment variables: PACKAGES=libfdt-devel ccache tar git make gcc g++ zlib-devel glib2-devel SDL-devel pixman-devel epel-release HOSTNAME=6c16958c3a1e TERM=xterm MAKEFLAGS= -j16 HISTSIZE=1000 J=16 USER=root CCACHE_DIR=/var/tmp/ccache EXTRA_CONFIGURE_OPTS= V= SHOW_ENV=1 MAIL=/var/spool/mail/root PATH=/usr/lib/ccache:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin PWD=/ LANG=en_US.UTF-8 TARGET_LIST= HISTCONTROL=ignoredups SHLVL=1 HOME=/root TEST_DIR=/tmp/qemu-test LOGNAME=root LESSOPEN=||/usr/bin/lesspipe.sh %s FEATURES= dtc DEBUG= G_BROKEN_FILENAMES=1 CCACHE_HASHDIR= _=/usr/bin/env Configure options: --enable-werror --target-list=x86_64-softmmu,aarch64-softmmu --prefix=/var/tmp/qemu-build/install No C++ compiler available; disabling C++ specific optional code Install prefix/var/tmp/qemu-build/install BIOS directory/var/tmp/qemu-build/install/share/qemu binary directory /var/tmp/qemu-build/install/bin library directory /var/tmp/qemu-build/install/lib module directory /var/tmp/qemu-build/install/lib/qemu libexec directory /var/tmp/qemu-build/install/libexec include directory /var/tmp/qemu-build/install/include config directory /var/tmp/qemu-build/install/etc local state directory /var/tmp/qemu-build/install/var Manual directory /var/tmp/qemu-build/install/share/man ELF interp prefix /usr/gnemul/qemu-%M Source path /tmp/qemu-test/src C compilercc Host C compiler cc C++ compiler Objective-C compiler cc ARFLAGS rv CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g QEMU_CFLAGS -I/usr/include/pixman-1-pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -fPIE -DPIE -m64 -mcx16 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all LDFLAGS -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g make make install install pythonpython -B smbd /usr/sbin/smbd module supportno host CPU x86_64 host big endian no target list x86_64-softmmu aarch64-softmmu tcg debug enabled no gprof enabled no sparse enabledno strip binariesyes profiler no static build no pixmansystem SDL support yes (1.2.14) GTK support no GTK GL supportno VTE support no TLS priority NORMAL GNUTLS supportno GNUTLS rndno libgcrypt no libgcrypt kdf no nettleno nettle kdfno libtasn1 no curses supportno virgl support no curl support no mingw32 support no Audio drivers oss Block whitelist (rw) Block whitelist (ro) VirtFS supportno VNC support yes VNC SASL support no VNC JPEG support no VNC PNG support no xen support no brlapi supportno bluez supportno Documentation no PIE yes vde support no netmap supportno Linux AIO support no ATTR/XATTR support yes Install blobs yes KVM support yes COLO support yes RDMA support no TCG interpreter no fdt support yes preadv supportyes fdatasync yes madvise yes posix_madvise yes libcap-ng support no vhost-net support yes vhost-scsi support yes vhost-vs
Re: [Qemu-devel] [PATCH v2] target-sh4: add atomic tas
On 11/04/2016 10:23 AM, John Paul Adrian Glaubitz wrote: > On 11/03/2016 05:21 PM, Laurent Vivier wrote: >> It should,:the problem was reported by Adrian (cc:) while compiling ghc >> in qemu-sh4, but I have just tested the functionality with the softmmu >> version, not the atomicity. >> >> Adrian, could you test this patch? > > Will absolutely do that. Awesome to see progress here :). Ok, I couldn't wait. It doesn't help with the GHC issue, unfortunately: root@ikarus:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) qemu-sh4-static: /home/glaubitz/upstream/qemu/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. qemu-sh4-static: /home/glaubitz/upstream/qemu/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. Segmentation fault root@ikarus:~/ghc-7.8.4/utils/ghc-pwd# I've also seen it lock up and strace showing it hanging in a futex lock. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
[Qemu-devel] [QEMU PATCH] kvmclock: advance clock by time window between vm_stop and pre_save
This patch, relative to pre-copy migration codepath,
measures the time between vm_stop() and pre_save(),
which includes copying the remaining RAM to destination,
and advances the clock by that amount.
In a VM with 5 seconds downtime, this reduces the guest
clock difference on destination from 5s to 0.2s.
Please do not apply this yet as some codepaths still need
checking, submitting early for comments.
Signed-off-by: Marcelo Tosatti
diff --git a/hw/i386/kvm/clock.c b/hw/i386/kvm/clock.c
index 0f75dd3..1bd8fd6 100644
--- a/hw/i386/kvm/clock.c
+++ b/hw/i386/kvm/clock.c
@@ -22,9 +22,11 @@
#include "kvm_i386.h"
#include "hw/sysbus.h"
#include "hw/kvm/clock.h"
+#include "migration/migration.h"
#include
#include
+#include
#define TYPE_KVM_CLOCK "kvmclock"
#define KVM_CLOCK(obj) OBJECT_CHECK(KVMClockState, (obj), TYPE_KVM_CLOCK)
@@ -35,7 +37,11 @@ typedef struct KVMClockState {
/*< public >*/
uint64_t clock;
+uint64_t ns;
bool clock_valid;
+
+uint64_t advance_clock;
+struct timespec t_aftervmstop;
} KVMClockState;
struct pvclock_vcpu_time_info {
@@ -100,6 +106,11 @@ static void kvmclock_vm_state_change(void *opaque, int
running,
s->clock = time_at_migration;
}
+if (s->advance_clock && s->clock + s->advance_clock > s->clock) {
+s->clock += s->advance_clock;
+s->advance_clock = 0;
+}
+
data.clock = s->clock;
ret = kvm_vm_ioctl(kvm_state, KVM_SET_CLOCK, &data);
if (ret < 0) {
@@ -135,6 +146,18 @@ static void kvmclock_vm_state_change(void *opaque, int
running,
abort();
}
s->clock = data.clock;
+/*
+ * Transition from VM-running to VM-stopped via migration?
+ * Record when the VM was stopped.
+ */
+
+if (state == RUN_STATE_FINISH_MIGRATE &&
+!migration_in_postcopy(migrate_get_current())) {
+clock_gettime(CLOCK_MONOTONIC, &s->t_aftervmstop);
+} else {
+s->t_aftervmstop.tv_sec = 0;
+s->t_aftervmstop.tv_nsec = 0;
+}
/*
* If the VM is stopped, declare the clock state valid to
@@ -152,12 +175,66 @@ static void kvmclock_realize(DeviceState *dev, Error
**errp)
qemu_add_vm_change_state_handler(kvmclock_vm_state_change, s);
}
+static uint64_t clock_delta(struct timespec *before, struct timespec *after)
+{
+if (before->tv_sec > after->tv_sec ||
+(before->tv_sec == after->tv_sec &&
+ before->tv_nsec > after->tv_nsec)) {
+fprintf(stderr, "clock_delta failed: before=(%ld sec, %ld nsec),"
+"after=(%ld sec, %ld nsec)\n", before->tv_sec,
+before->tv_nsec, after->tv_sec, after->tv_nsec);
+abort();
+}
+
+return (after->tv_sec - before->tv_sec) * 10ULL +
+after->tv_nsec - before->tv_nsec;
+}
+
+static void kvmclock_pre_save(void *opaque)
+{
+KVMClockState *s = opaque;
+struct timespec now;
+uint64_t ns;
+
+if (s->t_aftervmstop.tv_sec == 0) {
+return;
+}
+
+clock_gettime(CLOCK_MONOTONIC, &now);
+
+ns = clock_delta(&s->t_aftervmstop, &now);
+
+/*
+ * Linux guests can overflow if time jumps
+ * forward in large increments.
+ * Cap maximum adjustment to 10 minutes.
+ */
+ns = MIN(ns, 6000ULL);
+
+if (s->clock + ns > s->clock) {
+s->ns = ns;
+}
+}
+
+static int kvmclock_post_load(void *opaque, int version_id)
+{
+KVMClockState *s = opaque;
+
+/* save the value from incoming migration */
+s->advance_clock = s->ns;
+
+return 0;
+}
+
static const VMStateDescription kvmclock_vmsd = {
.name = "kvmclock",
-.version_id = 1,
+.version_id = 2,
.minimum_version_id = 1,
+.pre_save = kvmclock_pre_save,
+.post_load = kvmclock_post_load,
.fields = (VMStateField[]) {
VMSTATE_UINT64(clock, KVMClockState),
+VMSTATE_UINT64_V(ns, KVMClockState, 2),
VMSTATE_END_OF_LIST()
}
};
Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support
On Thu, Oct 20, 2016 at 01:31:15AM +, Ketan Nilangekar wrote: > 2. The idea of having multi-threaded epoll based network client was to drive > more throughput by using multiplexed epoll implementation and (fairly) > distributing IOs from several vdisks (typical VM assumed to have atleast 2) > across 8 connections. > Each connection is serviced by single epoll and does not share its context > with other connections/epoll. All memory pools/queues are in the context of a > connection/epoll. > The qemu thread enqueues IO request in one of the 8 epoll queues using a > round-robin. Responses are also handled in the context of an epoll loop and > do not share context with other epolls. Any synchronization code that you see > today in the driver callback is code that handles the split IOs which we plan > to address by a) implementing readv in libqnio and b) removing the 4MB limit > on write IO size. > The number of client epoll threads (8) is a #define in qnio and can easily be > changed. However our tests indicate that we are able to drive a good number > of IOs using 8 threads/epolls. > I am sure there are ways to simplify the library implementation, but for now > the performance of the epoll threads is more than satisfactory. Have you benchmarked against just 1 epoll thread with 8 connections? Stefan signature.asc Description: PGP signature
Re: [Qemu-devel] [Qemu-ppc] [RFC 03/17] pseries: Always use core objects for CPU construction
On Thu, 3 Nov 2016 19:11:48 +1100
Alexey Kardashevskiy wrote:
> On 30/10/16 22:11, David Gibson wrote:
> > Currently the pseries machine has two paths for constructing CPUs. On
> > newer machine type versions, which support cpu hotplug, it constructs
> > cpu core objects, which in turn construct CPU threads. For older machine
> > versions it individually constructs the CPU threads.
> >
> > This division is going to make some future changes to the cpu construction
> > harder, so this patch unifies them. Now cpu core objects are always
> > created. This requires some updates to allow core objects to be created
> > without a full complement of threads (since older versions allowed a
> > number of cpus not a multiple of the threads-per-core). Likewise it needs
> > some changes to the cpu core hot/cold plug path so as not to choke on the
> > old machine types without hotplug support.
> >
> > For good measure, we move the cpu construction to its own subfunction,
> > spapr_init_cpus().
> >
> > Signed-off-by: David Gibson
> > ---
> > hw/ppc/spapr.c | 125
> > +++-
> > hw/ppc/spapr_cpu_core.c | 30 +++-
> > include/hw/ppc/spapr.h | 1 -
> > 3 files changed, 89 insertions(+), 67 deletions(-)
> >
> > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > index c8e2921..ad68a9d 100644
> > --- a/hw/ppc/spapr.c
> > +++ b/hw/ppc/spapr.c
> > @@ -1688,11 +1688,80 @@ static void spapr_validate_node_memory(MachineState
> > *machine, Error **errp)
> > }
> > }
> >
> > +static void spapr_init_cpus(sPAPRMachineState *spapr)
> > +{
> > +MachineState *machine = MACHINE(spapr);
> > +MachineClass *mc = MACHINE_GET_CLASS(machine);
> > +char *type = spapr_get_cpu_core_type(machine->cpu_model);
> > +int smt = kvmppc_smt_threads();
> > +int spapr_max_cores, spapr_cores;
> > +int i;
> > +
> > +if (!type) {
> > +error_report("Unable to find sPAPR CPU Core definition");
> > +exit(1);
> > +}
> > +
> > +if (mc->query_hotpluggable_cpus) {
> > +if (smp_cpus % smp_threads) {
> > +error_report("smp_cpus (%u) must be multiple of threads (%u)",
> > + smp_cpus, smp_threads);
> > +exit(1);
> > +}
> > +if (max_cpus % smp_threads) {
> > +error_report("max_cpus (%u) must be multiple of threads (%u)",
> > + max_cpus, smp_threads);
> > +exit(1);
> > +}
> > +
> > +spapr_max_cores = max_cpus / smp_threads;
> > +spapr_cores = smp_cpus / smp_threads;
> > +} else {
> > +if (max_cpus != smp_cpus) {
> > +error_report("This machine version does not support CPU
> > hotplug");
> > +exit(1);
> > +}
> > +
> > +spapr_max_cores = QEMU_ALIGN_UP(smp_cpus, smp_threads) /
> > smp_threads;
> > +spapr_cores = spapr_max_cores;
> > +}
> > +
> > +spapr->cores = g_new0(Object *, spapr_max_cores);
> > +for (i = 0; i < spapr_max_cores; i++) {
> > +int core_id = i * smp_threads;
> > +
> > +if (mc->query_hotpluggable_cpus) {
> > +sPAPRDRConnector *drc =
> > +spapr_dr_connector_new(OBJECT(spapr),
> > + SPAPR_DR_CONNECTOR_TYPE_CPU,
> > + (core_id / smp_threads) * smt);
> > +
> > +qemu_register_reset(spapr_drc_reset, drc);
> > +}
> > +
> > +if (i < spapr_cores) {
> > +Object *core = object_new(type);
> > +int nr_threads = smp_threads;
> > +
> > +/* Handle the partially filled core for older machine types */
> > +if ((i + 1) * smp_threads >= smp_cpus) {
> > +nr_threads = smp_cpus - i * smp_threads;
> > +}
>
>
> What is this exactly for? Older machines report "qemu-system-ppc64: threads
> must be 8" when I do "-smp 12,threads=8 -machine pseries-2.2".
>
IIUC, this lowers nr_threads for the last core to end up with the requested
number of vCPUs... but spapr_core_pre_plug() doesn't like partially filled
cores.
if (cc->nr_threads != smp_threads) {
error_setg(&local_err, "threads must be %d", smp_threads);
goto out;
}
BTW, this error message looks weird when ones has passed "-smp threads=8"...
It should better reads:
"unsupported partially filled core (%d threads, should have %d)"
If this check is removed, then we hit:
qemu-system-ppc64: core id 8 out of range
because of:
int spapr_max_cores = max_cpus / smp_threads;
index = cc->core_id / smp_threads;
if (index < 0 || index >= spapr_max_cores) {
error_setg(&local_err, "core id %d out of range", cc->core_id);
goto out;
}
Since the cc->core_id / smp_threads pattern is only used on the plug/unplug
paths, maybe these checks in spapr_core_pre_plug() should only be done
when mc->query_hotpluggable_cpus != NU
Re: [Qemu-devel] [PATCH v5 0/5] nvdimm: hotplug support
On Fri, 4 Nov 2016 09:15:48 + Stefan Hajnoczi wrote: > On Fri, Nov 04, 2016 at 06:22:26AM +0200, Michael S. Tsirkin wrote: > > On Fri, Nov 04, 2016 at 06:01:54AM +0200, Michael S. Tsirkin wrote: > > > On Fri, Nov 04, 2016 at 11:50:19AM +0800, Xiao Guangrong wrote: > > > > On 11/04/2016 02:36 AM, Xiao Guangrong wrote: > > > > > Hi Michael, > > > > > > > > > > This patchset can replace the patches from [PULL 36/47] to [PULL > > > > > 39/47] > > > > > in your pull request: > > > > > [PULL 36/47] nvdimm acpi: prebuild nvdimm devices for available slots > > > > > [PULL 37/47] nvdimm acpi: introduce fit buffer > > > > > [PULL 38/47] nvdimm acpi: introduce _FIT > > > > > [PULL 39/47] pc: memhp: enable nvdimm device hotplug > > > > > > > > > > Thanks for your patience also thank Igor and Stefan for their review. > > > > > > > > > > > > > Hi, > > > > > > > > As the pull request has been upstream (Cool! :)), i will post > > > > diff changes based on that. > > > > > > > > Thanks! > > > > > > Igor prefers seeing revert+patches, I prefer seeing a diff. > > > Can you send both? A global diff would be ok for me > > > as it's small and easy enough to generate. > > > > Stefan, I wonder what's easier for you to review? > > Since it has been merged into qemu.git/master I'd now like to see > follow-up patches. Not a global diff but real individual changes on top > of qemu.git/master. These fixes can be merged during softfreeze. Incremental followup patches will make review a bit harder as they should remove code that's shouldn't have been there is the first place and would be fixing existing mess. But since majority prefers incremental followup patches lets do it this way. > > Stefan
Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support
On Thu, Oct 20, 2016 at 01:31:15AM +, Ketan Nilangekar wrote: > 2. The idea of having multi-threaded epoll based network client was to drive > more throughput by using multiplexed epoll implementation and (fairly) > distributing IOs from several vdisks (typical VM assumed to have atleast 2) > across 8 connections. > Each connection is serviced by single epoll and does not share its context > with other connections/epoll. All memory pools/queues are in the context of a > connection/epoll. > The qemu thread enqueues IO request in one of the 8 epoll queues using a > round-robin. Responses are also handled in the context of an epoll loop and > do not share context with other epolls. Any synchronization code that you see > today in the driver callback is code that handles the split IOs which we plan > to address by a) implementing readv in libqnio and b) removing the 4MB limit > on write IO size. > The number of client epoll threads (8) is a #define in qnio and can easily be > changed. However our tests indicate that we are able to drive a good number > of IOs using 8 threads/epolls. > I am sure there are ways to simplify the library implementation, but for now > the performance of the epoll threads is more than satisfactory. By the way, when you benchmark with 8 epoll threads, are there any other guests with vxhs running on the machine? In a real-life situation where multiple VMs are running on a single host it may turn out that giving each VM 8 epoll threads doesn't help at all because the host CPUs are busy with other tasks. Stefan signature.asc Description: PGP signature
Re: [Qemu-devel] [PATCH v2] target-sh4: add atomic tas
Le 04/11/2016 à 10:43, John Paul Adrian Glaubitz a écrit : > On 11/04/2016 10:23 AM, John Paul Adrian Glaubitz wrote: >> On 11/03/2016 05:21 PM, Laurent Vivier wrote: >>> It should,:the problem was reported by Adrian (cc:) while compiling ghc >>> in qemu-sh4, but I have just tested the functionality with the softmmu >>> version, not the atomicity. >>> >>> Adrian, could you test this patch? >> >> Will absolutely do that. Awesome to see progress here :). > > Ok, I couldn't wait. It doesn't help with the GHC issue, unfortunately: > > root@ikarus:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs > [1 of 1] Compiling Main ( Main.hs, Main.o ) > qemu-sh4-static: /home/glaubitz/upstream/qemu/translate-all.c:175: tb_lock: > Assertion `!have_tb_lock' failed. > qemu-sh4-static: /home/glaubitz/upstream/qemu/translate-all.c:175: tb_lock: > Assertion `!have_tb_lock' failed. > Segmentation fault > root@ikarus:~/ghc-7.8.4/utils/ghc-pwd# > > I've also seen it lock up and strace showing it hanging in a futex lock. I think it's more likely a linux-user bug than a target-sh4 bug. As you report in a mail to me in February, "do_futex()" must be protected against parallel execution for some futex commands. Thanks, Laurent
Re: [Qemu-devel] [PATCH 1/3] vhost: adapt vhost_verify_ring_mappings() to virtio 1 ring layout
On Fri, 4 Nov 2016 10:38:32 +0100 Cornelia Huck wrote: > On Fri, 04 Nov 2016 09:39:15 +0100 > Greg Kurz wrote: > > > With virtio 1, the vring layout is split in 3 separate regions of > > contiguous memory for the descriptor table, the available ring and the > > used ring, as opposed with legacy virtio which uses a single region. > > > > In case of memory re-mapping, the code ensures it doesn't affect the > > vring mapping. This is done in vhost_verify_ring_mappings() which assumes > > the device is legacy. > > > > This patch changes vhost_verify_ring_mappings() to check the mappings of > > each part of the vring separately. > > Add "This will work for legacy mappings as well." ? > Sure! > > > > Signed-off-by: Greg Kurz > > --- > > hw/virtio/vhost.c | 79 > > ++--- > > include/hw/virtio/vhost.h |4 ++ > > 2 files changed, 64 insertions(+), 19 deletions(-) > > Reviewed-by: Cornelia Huck >
Re: [Qemu-devel] [PATCH 2/3] vhost: drop legacy vring layout bits
On Fri, 4 Nov 2016 10:40:44 +0100
Cornelia Huck wrote:
> On Fri, 04 Nov 2016 09:39:22 +0100
> Greg Kurz wrote:
>
> > The legacy vring layout is not used anymore.
>
> "as we use separate mappings even for legacy devices." ?
>
> Otherwise, this may confuse the casual reader into thinking legacy is
> not supported anymore.
>
Yeah you're right. I'll add this too.
> > This patch simply removes it.
> >
> > This also fixes a bug with virtio 1 devices when the vring descriptor table
> > is mapped at a higher address than the used vring because the following
> > function may return an insanely great value:
> >
> > hwaddr virtio_queue_get_ring_size(VirtIODevice *vdev, int n)
> > {
> > return vdev->vq[n].vring.used - vdev->vq[n].vring.desc +
> >virtio_queue_get_used_size(vdev, n);
> > }
> >
> > and the mapping fails.
> >
> > Signed-off-by: Greg Kurz
> > ---
> > hw/virtio/vhost.c | 13 -
> > include/hw/virtio/vhost.h |3 ---
> > 2 files changed, 16 deletions(-)
>
> Reviewed-by: Cornelia Huck
>
Re: [Qemu-devel] [PATCH v2] target-sh4: add atomic tas
On 11/04/2016 10:53 AM, Laurent Vivier wrote: > I think it's more likely a linux-user bug than a target-sh4 bug. > > As you report in a mail to me in February, "do_futex()" must be > protected against parallel execution for some futex commands. FWIW, it works fine on qemu-user-armel last time I tested. I could build GHC completely on qemu-user for armel without any issues. Btw, if anyone wants to test themselves: $ wget http://users.physik.fu-berlin.de/~glaubitz/sid-sh4-sbuild-ghc.tgz $ tar xf sid-sh4-sbuild-ghc.tgz (compile qemu with --target-list=sh4-linux-user --static) $ cp -av qemu-sh4 sid-sh4-sbuild-ghc/usr/bin/qemu-sh4-static $ chroot sid-sh4-sbuild-ghc (in chroot): $ cd /root/ghc-7.8.4/utils/ghc-pwd $ ghc Main.hs Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [Qemu-devel] [PATCH v5 2/5] nvdimm acpi: introduce fit buffer
On Fri, 4 Nov 2016 02:36:23 +0800
Xiao Guangrong wrote:
> The buffer is used to save the FIT info for all the presented nvdimm
> devices which is updated after the nvdimm device is plugged or
> unplugged. In the later patch, it will be used to construct NVDIMM
> ACPI _FIT method which reflects the presented nvdimm devices after
> nvdimm hotplug
>
> As FIT buffer can not completely mapped into guest address space,
^^ be
> OSPM will exit to QEMU multiple times, however, there is the race
> condition - FIT may be changed during these multiple exits, so that
> we mark @dirty whenever the buffer is updated.
>
> @dirty is cleared for the first time OSPM gets fit buffer, if
> dirty is detected in the later access, OSPM will restart the
> access
s/presented/present/g
> Signed-off-by: Xiao Guangrong
> ---
> hw/acpi/nvdimm.c| 59
> +++--
> hw/i386/acpi-build.c| 2 +-
> hw/i386/pc.c| 4
> include/hw/mem/nvdimm.h | 21 +-
> 4 files changed, 62 insertions(+), 24 deletions(-)
>
> diff --git a/hw/acpi/nvdimm.c b/hw/acpi/nvdimm.c
> index 58bc5c6..73db3a7 100644
> --- a/hw/acpi/nvdimm.c
> +++ b/hw/acpi/nvdimm.c
> @@ -33,35 +33,30 @@
> #include "hw/nvram/fw_cfg.h"
> #include "hw/mem/nvdimm.h"
>
> -static int nvdimm_plugged_device_list(Object *obj, void *opaque)
> +static int nvdimm_device_list(Object *obj, void *opaque)
> {
> GSList **list = opaque;
>
> if (object_dynamic_cast(obj, TYPE_NVDIMM)) {
> -DeviceState *dev = DEVICE(obj);
> -
> -if (dev->realized) { /* only realized NVDIMMs matter */
> -*list = g_slist_append(*list, DEVICE(obj));
> -}
> +*list = g_slist_append(*list, DEVICE(obj));
> }
>
> -object_child_foreach(obj, nvdimm_plugged_device_list, opaque);
> +object_child_foreach(obj, nvdimm_device_list, opaque);
> return 0;
> }
above hunk should be in a separate patch, to reduce noise caused by rename
>
> /*
> - * inquire plugged NVDIMM devices and link them into the list which is
> + * inquire NVDIMM devices and link them into the list which is
> * returned to the caller.
> *
> * Note: it is the caller's responsibility to free the list to avoid
> * memory leak.
> */
> -static GSList *nvdimm_get_plugged_device_list(void)
> +static GSList *nvdimm_get_device_list(void)
> {
> GSList *list = NULL;
>
> -object_child_foreach(qdev_get_machine(), nvdimm_plugged_device_list,
> - &list);
> +object_child_foreach(qdev_get_machine(), nvdimm_device_list, &list);
> return list;
> }
>
> @@ -219,7 +214,7 @@ static uint32_t nvdimm_slot_to_dcr_index(int slot)
> static NVDIMMDevice *nvdimm_get_device_by_handle(uint32_t handle)
> {
> NVDIMMDevice *nvdimm = NULL;
> -GSList *list, *device_list = nvdimm_get_plugged_device_list();
> +GSList *list, *device_list = nvdimm_get_device_list();
>
> for (list = device_list; list; list = list->next) {
> NVDIMMDevice *nvd = list->data;
> @@ -348,8 +343,9 @@ static void nvdimm_build_structure_dcr(GArray
> *structures, DeviceState *dev)
> (DSM) in DSM Spec Rev1.*/);
> }
>
> -static GArray *nvdimm_build_device_structure(GSList *device_list)
> +static GArray *nvdimm_build_device_structure(void)
> {
> +GSList *device_list = nvdimm_get_device_list();
> GArray *structures = g_array_new(false, true /* clear */, 1);
>
> for (; device_list; device_list = device_list->next) {
> @@ -367,14 +363,32 @@ static GArray *nvdimm_build_device_structure(GSList
> *device_list)
> /* build NVDIMM Control Region Structure. */
> nvdimm_build_structure_dcr(structures, dev);
> }
> +g_slist_free(device_list);
>
> return structures;
> }
>
> -static void nvdimm_build_nfit(GSList *device_list, GArray *table_offsets,
> +static void nvdimm_init_fit_buffer(NvdimmFitBuffer *fit_buf)
> +{
> +fit_buf->fit = g_array_new(false, true /* clear */, 1);
> +}
> +
> +static void nvdimm_build_fit_buffer(NvdimmFitBuffer *fit_buf)
> +{
> +g_array_free(fit_buf->fit, true);
> +fit_buf->fit = nvdimm_build_device_structure();
> +fit_buf->dirty = true;
> +}
> +
> +void nvdimm_plug(AcpiNVDIMMState *state)
> +{
> +nvdimm_build_fit_buffer(&state->fit_buf);
> +}
> +
> +static void nvdimm_build_nfit(AcpiNVDIMMState *state, GArray *table_offsets,
>GArray *table_data, BIOSLinker *linker)
> {
> -GArray *structures = nvdimm_build_device_structure(device_list);
> +NvdimmFitBuffer *fit_buf = &state->fit_buf;
> unsigned int header;
>
> acpi_add_table(table_offsets, table_data);
> @@ -383,12 +397,11 @@ static void nvdimm_build_nfit(GSList *device_list,
> GArray *table_offsets,
> header = table_data->len;
> acpi_data_push(table_data, sizeof(NvdimmNfitHeader));
> /* NVDIMM device structur
Re: [Qemu-devel] [PATCH v5 0/5] nvdimm: hotplug support
On 11/04/2016 05:51 PM, Igor Mammedov wrote: But since majority prefers incremental followup patches lets do it this way. Okay, then i will make this patchset on the top of upstream.
Re: [Qemu-devel] [PATCH v2] target-sh4: add atomic tas
On 04/11/2016 11:00, John Paul Adrian Glaubitz wrote: > On 11/04/2016 10:53 AM, Laurent Vivier wrote: >> I think it's more likely a linux-user bug than a target-sh4 bug. >> >> As you report in a mail to me in February, "do_futex()" must be >> protected against parallel execution for some futex commands. > > FWIW, it works fine on qemu-user-armel last time I tested. I could > build GHC completely on qemu-user for armel without any issues. > > Btw, if anyone wants to test themselves: > > $ wget http://users.physik.fu-berlin.de/~glaubitz/sid-sh4-sbuild-ghc.tgz > $ tar xf sid-sh4-sbuild-ghc.tgz > (compile qemu with --target-list=sh4-linux-user --static) > $ cp -av qemu-sh4 sid-sh4-sbuild-ghc/usr/bin/qemu-sh4-static > $ chroot sid-sh4-sbuild-ghc > (in chroot): > $ cd /root/ghc-7.8.4/utils/ghc-pwd > $ ghc Main.hs If Haskell is compiled to use the "negative sp" trick that Richard mentioned, it would rely on the SH machine being uniprocessor. Try running chroot with "taskset -c 0". Paolo
Re: [Qemu-devel] [PATCH v2] target-sh4: add atomic tas
On 11/04/2016 11:13 AM, Paolo Bonzini wrote: >> $ wget http://users.physik.fu-berlin.de/~glaubitz/sid-sh4-sbuild-ghc.tgz >> $ tar xf sid-sh4-sbuild-ghc.tgz >> (compile qemu with --target-list=sh4-linux-user --static) >> $ cp -av qemu-sh4 sid-sh4-sbuild-ghc/usr/bin/qemu-sh4-static >> $ chroot sid-sh4-sbuild-ghc >> (in chroot): >> $ cd /root/ghc-7.8.4/utils/ghc-pwd >> $ ghc Main.hs > > If Haskell is compiled to use the "negative sp" trick that Richard > mentioned, it would rely on the SH machine being uniprocessor. Try > running chroot with "taskset -c 0". Doesn't help unfortunately, still either crashes or locks up like this: root@ikarus:~# strace -p 32415 strace: Process 32415 attached futex(0x7f836c8bd4c8, FUTEX_WAIT_PRIVATE, 7, NULL with 32415 being the qemu ghc process. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [Qemu-devel] [PATCH 3/3] Split ISA and sysbus versions of m48t59 device
Needs a rebase. First error:
CC hw/timer/m48t59.o
In file included from /work/armbru/qemu/include/exec/cpu-common.h:7:0,
from /work/armbru/qemu/include/exec/memory.h:24,
from /work/armbru/qemu/include/hw/isa/isa.h:6,
from /work/armbru/qemu/hw/timer/m48t59-isa.c:25:
/work/armbru/qemu/include/exec/hwaddr.h:11:9: error: unknown type name
‘uint64_t’
typedef uint64_t hwaddr;
^
David Gibson writes:
> The m48t59 device supports both ISA and direct sysbus attached versions of
> the device in the one .c file. This can be awkward for some embedded
> machine types which need the sysbus M48T59, but don't want to pull in the
> ISA bus code and its other dependencies.
>
> Therefore, this patch splits out the code for the ISA attached M48T59 into
> its own C file. It will be built when both CONFIG_M48T59 and
> CONFIG_ISA_BUS are enabled.
>
> Signed-off-by: David Gibson
> ---
> hw/timer/Makefile.objs | 3 +
> hw/timer/m48t59-internal.h | 82
> hw/timer/m48t59-isa.c | 180 +++
> hw/timer/m48t59.c | 228
> -
> 4 files changed, 283 insertions(+), 210 deletions(-)
> create mode 100644 hw/timer/m48t59-internal.h
> create mode 100644 hw/timer/m48t59-isa.c
>
> diff --git a/hw/timer/Makefile.objs b/hw/timer/Makefile.objs
> index 7ba8c23..bf3ea3c 100644
> --- a/hw/timer/Makefile.objs
> +++ b/hw/timer/Makefile.objs
> @@ -6,6 +6,9 @@ common-obj-$(CONFIG_DS1338) += ds1338.o
> common-obj-$(CONFIG_HPET) += hpet.o
> common-obj-$(CONFIG_I8254) += i8254_common.o i8254.o
> common-obj-$(CONFIG_M48T59) += m48t59.o
> +ifeq ($(CONFIG_ISA_BUS),y)
> +common-obj-$(CONFIG_M48T59) += m48t59-isa.o
> +endif
> common-obj-$(CONFIG_PL031) += pl031.o
> common-obj-$(CONFIG_PUV3) += puv3_ost.o
> common-obj-$(CONFIG_TWL92230) += twl92230.o
> diff --git a/hw/timer/m48t59-internal.h b/hw/timer/m48t59-internal.h
> new file mode 100644
> index 000..c50f134
> --- /dev/null
> +++ b/hw/timer/m48t59-internal.h
> @@ -0,0 +1,82 @@
> +/*
> + * QEMU M48T59 and M48T08 NVRAM emulation (common header)
> + *
> + * Copyright (c) 2003-2005, 2007 Jocelyn Mayer
> + * Copyright (c) 2013 Hervé Poussineau
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> copy
> + * of this software and associated documentation files (the "Software"), to
> deal
> + * in the Software without restriction, including without limitation the
> rights
> + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> + * copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> FROM,
> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> + * THE SOFTWARE.
> + */
> +#ifndef HW_M48T59_H
> +#define HW_M48T59_H 1
> +
> +//#define DEBUG_NVRAM
> +
> +#if defined(DEBUG_NVRAM)
> +#define NVRAM_PRINTF(fmt, ...) do { printf(fmt , ## __VA_ARGS__); } while (0)
> +#else
> +#define NVRAM_PRINTF(fmt, ...) do { } while (0)
> +#endif
> +
> +/*
> + * The M48T02, M48T08 and M48T59 chips are very similar. The newer '59 has
> + * alarm and a watchdog timer and related control registers. In the
> + * PPC platform there is also a nvram lock function.
> + */
> +
> +typedef struct M48txxInfo {
> +const char *bus_name;
> +uint32_t model; /* 2 = m48t02, 8 = m48t08, 59 = m48t59 */
> +uint32_t size;
> +} M48txxInfo;
> +
> +typedef struct M48t59State {
> +/* Hardware parameters */
> +qemu_irq IRQ;
> +MemoryRegion iomem;
> +uint32_t size;
> +int32_t base_year;
> +/* RTC management */
> +time_t time_offset;
> +time_t stop_time;
> +/* Alarm & watchdog */
> +struct tm alarm;
> +QEMUTimer *alrm_timer;
> +QEMUTimer *wd_timer;
> +/* NVRAM storage */
> +uint8_t *buffer;
> +/* Model parameters */
> +uint32_t model; /* 2 = m48t02, 8 = m48t08, 59 = m48t59 */
> +/* NVRAM storage */
> +uint16_t addr;
> +uint8_t lock;
> +} M48t59State;
> +
> +uint32_t m48t59_read(M48t59State *NVRAM, uint32_t addr);
> +void m48t59_write(M48t59State *NVRAM, uint32_t addr, uint32_t val);
> +void m48t59_reset_common(M48t59State *NVRAM);
> +void m48t59_realize_common(M48t59State *s, Error **errp);
> +
> +static inline void m48t59_toggle_lock(M48t59State *NVRAM, int lock)
> +{
> +
Re: [Qemu-devel] [PATCH 1/5] ARM BE8/BE32 semihosting and gdbstub support.
On Fri, 4 Nov 2016 09:48:06 +0100 Paolo Bonzini wrote: > On 04/11/2016 00:34, Julian Brown wrote: > > > > So (IIRC!) the gdbstub needs to interpret some of these read/write > > values on the host, i.e. in host byte ordering. "Traditionally", the > > ldl_p and stl_p (etc.) macros would byteswap depending on the > > TARGET_WORDS_BIGENDIAN setting -- that's how come our internal > > testing using QEMU worked at all in the past. But that's changed > > with the single-binary-for-all-endiannesses patches. > > I'm not sure what you mean here... BE8 wasn't supported at all in > system emulation mode before those patches, and there are still two > binaries for user-mode little-endian on one side and BE8/BE32 on the > other. The details of how QEMU distinguished BE8 from BE32 changed > (from bswap_code to SCTLR.B and CPSR.E) but TARGET_WORDS_BIGENDIAN > remained set for qemu-armeb. > > The difference for user-mode in fact was very small; for system mode > emulation it was larger because QEMU grew support for all three of > CPSR.E, SCTLR.B and SCTLR.EE. But then again there was no > qemu-system-armeb before, maybe it was something you had in your > internal QEMU? Yes, exactly. I think we more-or-less just added a armeb-softmmu.mak and things worked -- at least as far as BE32 mode, and bearing in mind that we were only interested in instruction-set simulation. BE8 mode is (ahem) a different matter, i.e. we (as in Mentor) might just have been getting that wrong. Oops! > That said, if indeed gdb expects wire endianness to match ELF > endianness, you have to do something about it indeed in the gdbstub. > But it seems weird to look at CPSR.E, as that would flip values across > SETEND. SCTLR.B|SCTLR.EE seems more plausible. The addition of a CPU > property for reset, as suggested by Peter, would then make a lot of > sense. Each CPU initfn would then look at that property and use it to > initialize (depending on the model) either SCTLR.B or SCTLR.EE. OK, that makes sense, thanks. > The change to arm_cpu_memory_rw_debug for BE32 is also interesting. > gdb documentation says > > The stub need not use any particular size or alignment when > gathering data from memory for the response; even if ADDR is > word-aligned and LENGTH is a multiple of the word size, the stub > is free to use byte accesses, or not. > > while your change means that gdb actually wants you to do byte > accesses. The splitting-into-bytes is just an implementation convenience -- the simplest way I could see of handling the low-order address bit reversal without breaking abstractions more or shuffling lots of code around. I'm not sure if GDB was actually requesting sub-word access sizes. Thanks, Julian
Re: [Qemu-devel] [PATCH v5 4/5] nvdimm acpi: introduce _FIT method
On Fri, 4 Nov 2016 02:36:25 +0800
Xiao Guangrong wrote:
> _FIT is required for hotplug support, guest will inquire the
> updated device info from it if a hotplug event is received
>
> As FIT buffer is not completely mapped into guest address space,
> Read_FIT method is introduced to read NFIT structures blob from
> QEMU, The buffer is concatenated before _FIT return
>
> Refer to docs/specs/acpi-nvdimm.txt for detailed design
>
> Signed-off-by: Xiao Guangrong
> ---
> docs/specs/acpi_nvdimm.txt | 61 --
> hw/acpi/nvdimm.c | 198
> -
> 2 files changed, 252 insertions(+), 7 deletions(-)
>
> diff --git a/docs/specs/acpi_nvdimm.txt b/docs/specs/acpi_nvdimm.txt
> index 0fdd251..63cb63f 100644
> --- a/docs/specs/acpi_nvdimm.txt
> +++ b/docs/specs/acpi_nvdimm.txt
> @@ -65,8 +65,8 @@ _FIT(Firmware Interface Table)
> The detailed definition of the structure can be found at ACPI 6.0: 5.2.25
> NVDIMM Firmware Interface Table (NFIT).
>
> -QEMU NVDIMM Implemention
> -
> +QEMU NVDIMM Implementation
> +==
> QEMU uses 4 bytes IO Port starting from 0x0a18 and a RAM-based memory page
> for NVDIMM ACPI.
>
> @@ -82,6 +82,16 @@ Memory:
> ACPI writes _DSM Input Data (based on the offset in the page):
> [0x0 - 0x3]: 4 bytes, NVDIMM Device Handle, 0 is reserved for NVDIMM
> Root device.
> +
> +The handle is completely QEMU internal thing, the values in
> +range [1, 0x] indicate nvdimm device. Other values are
> +reserved for other purposes.
> +
> +Reserved handles:
> +0 is reserved for nvdimm root device named NVDR.
> +0x1 is reserved for QEMU internal DSM function called on
> +the root device.
> +
> [0x4 - 0x7]: 4 bytes, Revision ID, that is the Arg1 of _DSM method.
> [0x8 - 0xB]: 4 bytes. Function Index, that is the Arg2 of _DSM method.
> [0xC - 0xFFF]: 4084 bytes, the Arg3 of _DSM method.
> @@ -127,6 +137,47 @@ _DSM process diagram:
> | result from the page | | |
> +--+ +--+
>
> - _FIT implementation
> - ---
> - TODO (will fill it when nvdimm hotplug is introduced)
> +QEMU internal use only _DSM function
> +
> +1) Read FIT
> + _FIT method uses _DSM method to fetch NFIT structures blob from QEMU
> + in 1 page sized increments which are then concatenated and returned
> + as _FIT method result.
> +
> + Input parameters:
> + Arg0 – UUID {set to 648B9CF2-CDA1-4312-8AD9-49C4AF32BD62}
> + Arg1 – Revision ID (set to 1)
> + Arg2 - Function Index, 0x1
> + Arg3 - A package containing a buffer whose layout is as follows:
> +
> + +--+++---+
> + | Field | Length | Offset | Description |
> + +--+++---+
> + | offset | 4| 0| offset in QEMU's NFIT structures blob to |
> + | ||| read from |
> + +--+++---+
> +
> + Output layout in the dsm memory page:
> + +--+++---+
> + | Field | Length | Offset | Description |
> + +--+++---+
> + | length | 4| 0| length of entire returned data|
> + | ||| (including the header)|
s/the header/this header/
> + +--+-+---+
> + | ||| return status codes |
> + | ||| 0x0 - success |
> + | ||| 0x100 - error caused by NFIT update while |
> + | status | 4| 4| read by _FIT wasn't completed, other |
> + | ||| codes follow Chapter 3 in DSM Spec Rev1 |
> + +--+-+---+
> + | fit data | Varies | 8| contains FIT data, this field is present |
> + | ||| if status field is 0; |
> + +--+++---+
> +
> + The FIT offset is maintained by the OSPM itself, current offset plus
> + the size of the fit data returned by the function is the next offset
> + OSPM should read. When all FIT data has been read out, zero length is
> + returned.
you mean here fit data length rather then what is in 'length' field,
you should talk here in terms of 'length'
[Qemu-devel] [Bug 1129571] Re: libreoffice armhf FTBFS
Can you still reproduce this issue with the latest upstream version of QEMU? ** Changed in: qemu Status: New => Confirmed ** Changed in: qemu Status: Confirmed => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1129571 Title: libreoffice armhf FTBFS Status in QEMU: Incomplete Status in qemu package in Ubuntu: Confirmed Bug description: We have been experiencing FTBFS of LibreOffice 3.5.7, 12.04, armhf in the launchpad buildds. We believe this is likely due to an error in qemu. While we do not have a small test case yet, we do have a build log (attaching here). The relevant snippet from the build log is: 3.5.7/solver/unxlngr.pro/bin/jaxp.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/juh.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/parser.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/xt.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/unoil.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/ridl.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/jurt.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/xmlsearch.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/LuceneHelpWrapper.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/HelpIndexerTool.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/lucene-core-2.3.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/lucene-analyzers-2.3.jar" com.sun.star.help.HelpIndexerTool -lang cs -mod swriter -zipdir ../../unxlngr.pro/misc/ziptmpswriter_cs -o ../../unxlngr.pro/bin/swriter_cs.zip.unxlngr.pro dmake: Error code 132, while making '../../unxlngr.pro/bin/swriter_cs.zip' We believe this is from bash error code 128 + 4, where 4 is illegal instruction, thus leading us to suspect qemu. Any help in tracking this down would be appreciated. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1129571/+subscriptions
Re: [Qemu-devel] Intel HDA and ALSA audio driver hogging event loop
On Thu, Oct 20, 2016 at 9:40 AM, Stefan Hajnoczi wrote:
> Hi Gerd,
Gerd: Ping
> A RHEL 7.2 guest sometimes hangs when I play back a wav file on the
> Intel HDA emulated sound card using the QEMU ALSA audio driver.
>
> I can only trigger this with the GTK UI but I think that may be a
> timing issue. The GTK UI has a GSource .prepare() function that calls
> recvmsg(2) on a non-blocking UNIX domain socket for X11. I think this
> affects the timing and increases the chance of hanging the guest.
>
> Note that this problem occurs both with the default ALSA->PulseAudio
> software device and the physical soundcard (PulseAudio disabled on
> host):
> QEMU_AUDIO_DRV=alsa QEMU_ALSA_DAC_DEV=sysdefault:CARD=PCH
> QEMU_ALSA_ADC_DEV=sysdefault:CARD=PCH
> x86_64-softmmu/qemu-system-x86_64 -net none -enable-kvm -m 1024 -cpu
> host -drive if=virtio,file=test.img,format=raw -soundhw hda
>
> intel_hda_xfer() transfers samples between the emulated card and the
> QEMU audio subsystem. The following case causes a problem:
> if (st->ctl & (1 << 26)) {
> /*
> * Wait with the next DMA xfer until the guest
> * has acked the buffer completion interrupt
> */
> return false;
> }
>
> If the guest hasn't acked the interrupt yet then Intel HDA returns
> without providing any samples. The QEMU ALSA driver keeps monitoring
> the file descriptor so the next event loop iteration will try to
> transfer samples again.
>
> If the guest hasn't acked the interrupt then the QEMU main loop spins.
> Depending on whether the main loop drops the global mutex and how long
> it executes for, we can starve the vcpu thread. The result is that
> performance is terrible and the guest appears hung.
>
> I think the QEMU ALSA sound driver should not be monitoring the
> playback file descriptor if the emulated sound card decides it needs
> to wait for the guest.
>
> Any thoughts on this issue?
>
> Should we add an AUD_plug_out()/AUD_unplug_out() interface to the QEMU
> audio subsystem so soundcards can suspend file descriptor monitoring?
>
> Stefan
[Qemu-devel] [Bug 1399943] Re: qemu-system-sparc loses serial console data on EAGAIN
The automated test infrastructure of the NetBSD project is based on qemu, and runs some 100 CPU-hours per day of full system tests of NetBSD-current on emulated i386, amd64, and sparc systems. This is all still running on qemu 0.15 (!). The main obstacle to upgrading to a current version of qemu is this three-year-old regression which breaks the sparc tests by losing some of the serial console output. It would be really nice if this could be fixed. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1399943 Title: qemu-system-sparc loses serial console data on EAGAIN Status in QEMU: New Bug description: When running a guest OS with a serial console under "qemu-system-sparc -nographic", parts of the serial console output are sometimes lost. This happens when a write() to standard output by qemu returns EAGAIN, as may be the case when the guest is generating console output faster than the tty (or pty/pipe/socket, etc.) connected to qemu's standard output accepts it. The bug affects all releases of qemu since 1.5, which was the first version to set stdout to O_NONBLOCK mode. Version 1.4.2 and earlier work correctly. To reproduce the bug, you will need a guest OS configured with a serial console, and a host with a slow tty. The attached shell script "sparc-test.sh" does this by using Aboriginal Linux as the serial console guest, and a pty controlled by a Python script and the "pexpect" Python module as the slow tty. A "seq" command is sent to the guest to generate 100,000 lines of output containing sequential integers, and the output is checked for gaps. The script limits the tty output rate by occasionally sleeping for 1/10 of a second. This bug was originally reported against qemu-system-i386 as bug #1335444, and has since been fixed in qemu-system-i386, but remains in qemu-system-sparc as of today's git sources (d00e6cddc220de993573dfb5fd160ac72ccd49ab). I am opening this separate bug for the sparc case because I was asked to do so by Paolo Bonzini in #1335444. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1399943/+subscriptions
Re: [Qemu-devel] [RFC 04/17] pseries: Make cpu_update during CAS unconditional
On 30.10.2016 12:11, David Gibson wrote: > spapr_h_cas_compose_response() includes a cpu_update parameter which > controls whether it includes updated information on the CPUs in the device > tree fragment returned from the ibm,client-architecture-support (CAS) call. > > Providing the updated information is essential when CAS has negotiated > compatibility options which require different cpu information to be > presented to the guest. However, it should be safe to provide in other > cases (it will just override the existing data in the device tree with > identical data). This simplifies the code by removing the parameter and > always providing the cpu update information. But updating the CPU device tree again and again will also increase the QEMU start-up time... Considering that guest start up time is sometimes also an issue, do you think that this code simplification really worth the effort here? Thomas
Re: [Qemu-devel] [Qemu-block] [PATCH] Added iopmem device emulation
On Tue, Oct 18, 2016 at 03:55:11PM -0600, Logan Gunthorpe wrote:
> An iopmem device is one which exposes volatile or non-volatile memory mapped
> directly to a BAR region. One purpose is to provide buffers to do peer
> to peer transfers on the bus. As such this device uses QEMU's drive
> backing store to simulate non-volatile memory and provides through a
> mapped BAR window.
>
> This patch creates an emulated device which helps to test and debug the
> kernel driver for iopmem while hardware availability is poor. A kernel
> patch for a driver is being prepared simultaneously.
>
> Signed-off-by: Logan Gunthorpe
> Signed-off-by: Stephen Bates
QEMU already has NVDIMM support (https://pmem.io/). It can be used both
for passthrough and fake non-volatile memory:
qemu-system-x86_64 \
-M pc,nvdimm=on \
-m 1024,maxmem=$((4096 * 1024 * 1024)),slots=2 \
-object memory-backend-file,id=mem0,mem-path=/tmp/foo,size=$((64 * 1024 *
1024)) \
-device nvdimm,memdev=mem0
Please explain where iopmem comes from, where the hardware spec is, etc?
Perhaps you could use nvdimm instead of adding a new device?
> ---
> default-configs/pci.mak | 1 +
> hw/block/Makefile.objs | 1 +
> hw/block/iopmem.c| 141
> +++
> include/hw/pci/pci_ids.h | 2 +
> 4 files changed, 145 insertions(+)
> create mode 100644 hw/block/iopmem.c
>
> diff --git a/default-configs/pci.mak b/default-configs/pci.mak
> index fff7ce3..aef2b35 100644
> --- a/default-configs/pci.mak
> +++ b/default-configs/pci.mak
> @@ -39,3 +39,4 @@ CONFIG_VGA=y
> CONFIG_VGA_PCI=y
> CONFIG_IVSHMEM=$(CONFIG_EVENTFD)
> CONFIG_ROCKER=y
> +CONFIG_IOPMEM_PCI=y
> diff --git a/hw/block/Makefile.objs b/hw/block/Makefile.objs
> index d4c3ab7..1c8044b 100644
> --- a/hw/block/Makefile.objs
> +++ b/hw/block/Makefile.objs
> @@ -8,6 +8,7 @@ common-obj-$(CONFIG_XEN_BACKEND) += xen_disk.o
> common-obj-$(CONFIG_ECC) += ecc.o
> common-obj-$(CONFIG_ONENAND) += onenand.o
> common-obj-$(CONFIG_NVME_PCI) += nvme.o
> +common-obj-$(CONFIG_IOPMEM_PCI) += iopmem.o
>
> obj-$(CONFIG_SH4) += tc58128.o
>
> diff --git a/hw/block/iopmem.c b/hw/block/iopmem.c
> new file mode 100644
> index 000..9c2d716
> --- /dev/null
> +++ b/hw/block/iopmem.c
> @@ -0,0 +1,141 @@
> +/*
> + * QEMU iopmem Controller
> + *
> + * Copyright (c) 2016, Microsemi Corporation
> + *
> + * Written by Logan Gunthorpe
> + *
> + * This code is licensed under the GNU GPL v2 or later.
> + */
> +
> +
> +/**
> + * Usage: add options:
> + * -drive file=,if=none,id=
> + * -device iopmem,drive=,id=
> + */
> +
> +#include "qemu/osdep.h"
> +#include "hw/pci/pci.h"
> +#include "sysemu/block-backend.h"
> +
> +typedef struct IoPmemCtrl {
> +PCIDeviceparent_obj;
> +MemoryRegion iomem;
> +BlockBackend *blk;
> +uint64_t size;
> +} IoPmemCtrl;
> +
> +#define TYPE_IOPMEM "iopmem"
> +#define IOPMEM(obj) \
> +OBJECT_CHECK(IoPmemCtrl, (obj), TYPE_IOPMEM)
> +
> +static uint64_t iopmem_bar_read(void *opaque, hwaddr addr, unsigned size)
> +{
> +IoPmemCtrl *ipm = (IoPmemCtrl *)opaque;
> +uint64_t val;
> +
> +blk_pread(ipm->blk, addr, &val, size);
> +
> +return val;
> +}
> +
> +static void iopmem_bar_write(void *opaque, hwaddr addr, uint64_t data,
> + unsigned size)
> +{
> +IoPmemCtrl *ipm = (IoPmemCtrl *)opaque;
> +
> +if (addr & 3) {
> +return;
> +}
> +
> +blk_pwrite(ipm->blk, addr, &data, size, 0);
> +}
This has terrible performance because blk_pread()/blk_pwrite() are
synchronous operations. The vcpu thread is paused while QEMU is waiting
for I/O.
signature.asc
Description: PGP signature
Re: [Qemu-devel] [PATCH v2] target-sh4: add atomic tas
On 04/11/2016 11:16, John Paul Adrian Glaubitz wrote: >> > >> > If Haskell is compiled to use the "negative sp" trick that Richard >> > mentioned, it would rely on the SH machine being uniprocessor. Try >> > running chroot with "taskset -c 0". > Doesn't help unfortunately, still either crashes or locks up like this: > > root@ikarus:~# strace -p 32415 > strace: Process 32415 attached > futex(0x7f836c8bd4c8, FUTEX_WAIT_PRIVATE, 7, NULL > > with 32415 being the qemu ghc process. Indeed you would still need luck. :( Paolo
Re: [Qemu-devel] [PATCH RFC] iothread: Add "spawns" property
On Wed, Oct 19, 2016 at 04:04:50PM +0800, Fam Zheng wrote:
> The option specifies how many threads to spawn under the iothread
> object. All threads share the same AioContext so they can safely run
> (contend) together.
>
> With AioContext going away, the spawns will natually enable the block
> multi-queue work.
>
> Signed-off-by: Fam Zheng
>
> ---
>
> Based on v2 of Paolo's RFifoLock removal series, with which the
> symmetric contention on the single AioContext is no longer a busy
> preempt loop.
> ---
> include/sysemu/iothread.h | 19 --
> iothread.c| 148
> ++
> 2 files changed, 125 insertions(+), 42 deletions(-)
I'm not happy with "IOThread" becoming a group of threads. IOThread
should stay the way it is. Instead you should add a new object type
that simply groups IOThreads for convenient assignment to devices, e.g.
IOThreadGroup. Then multiqueue devices can use an IOThreadGroup to work
inside multiple IOThreads.
> @@ -161,22 +225,32 @@ static int query_one_iothread(Object *object, void
> *opaque)
> IOThreadInfoList *elem;
> IOThreadInfo *info;
> IOThread *iothread;
> +char *id;
> +int i;
>
> iothread = (IOThread *)object_dynamic_cast(object, TYPE_IOTHREAD);
> if (!iothread) {
> return 0;
> }
>
> -info = g_new0(IOThreadInfo, 1);
> -info->id = iothread_get_id(iothread);
> -info->thread_id = iothread->thread_id;
> +id = iothread_get_id(iothread);
> +for (i = 0; i < iothread->nspawns; ++i) {
> +info = g_new0(IOThreadInfo, 1);
> +info->thread_id = iothread->spawns[i].thread_id;
> +if (iothread->nspawns > 1) {
> +info->id = g_strdup_printf("%s[%d]", id, i);
> +} else {
> +info->id = g_strdup(id);
> +}
>
> -elem = g_new0(IOThreadInfoList, 1);
> -elem->value = info;
> -elem->next = NULL;
> +elem = g_new0(IOThreadInfoList, 1);
> +elem->value = info;
> +elem->next = NULL;
>
> -**prev = elem;
> -*prev = &elem->next;
> +**prev = elem;
> +*prev = &elem->next;
> +}
> +g_free(id);
^-- yikes, now we're pretending to the QMP client that there are
multiple IOThread objects but internally we only have one. Let's not go
down that road.
signature.asc
Description: PGP signature
Re: [Qemu-devel] [RFC 06/17] ppc: Rename cpu_version to compat_pvr
On 30.10.2016 12:11, David Gibson wrote: > The 'cpu_version' field in PowerPCCPU is badly named. It's named after the > 'cpu-version' device tree property where it is advertised, but that meaning > may not be obvious in most places it appears. > > Worse, it doesn't even really correspond to that device tree property. The > property contains either the processor's PVR, or, if the CPU is running in > a compatibility mode, a special "logical PVR" representing which mode. > > Rename the cpu_version field, and a number of related variables to > compat_pvr to make this clearer. > > Signed-off-by: David Gibson > --- > hw/ppc/spapr.c | 4 ++-- > hw/ppc/spapr_hcall.c| 30 +++--- > target-ppc/cpu.h| 6 +++--- > target-ppc/kvm.c| 4 ++-- > target-ppc/kvm_ppc.h| 4 ++-- > target-ppc/translate_init.c | 10 +- > 6 files changed, 29 insertions(+), 29 deletions(-) Reviewed-by: Thomas Huth
[Qemu-devel] [PATCH 1/2] virtio: allow per-device-class legacy features
Legacy features are those that transitional devices only
expose on the legacy interface.
Allow different ones per device class.
Signed-off-by: Michael S. Tsirkin
---
include/hw/virtio/virtio.h | 5 +
hw/s390x/virtio-ccw.c | 4 +++-
hw/virtio/virtio-pci.c | 4 +++-
hw/virtio/virtio.c | 2 ++
4 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
index f12a1a8..bdb3c4b 100644
--- a/include/hw/virtio/virtio.h
+++ b/include/hw/virtio/virtio.h
@@ -113,6 +113,11 @@ typedef struct VirtioDeviceClass {
void (*set_config)(VirtIODevice *vdev, const uint8_t *config);
void (*reset)(VirtIODevice *vdev);
void (*set_status)(VirtIODevice *vdev, uint8_t val);
+/* For transitional devices, this is a bitmap of features
+ * that are only exposed on the legacy interface but not
+ * the modern one.
+ */
+uint64_t legacy_features;
/* Test and clear event pending status.
* Should be called after unmask to avoid losing events.
* If backend does not support masking,
diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
index 7d7f8f6..f5c1d98 100644
--- a/hw/s390x/virtio-ccw.c
+++ b/hw/s390x/virtio-ccw.c
@@ -303,6 +303,8 @@ static int virtio_ccw_cb(SubchDev *sch, CCW1 ccw)
if (!ccw.cda) {
ret = -EFAULT;
} else {
+VirtioDeviceClass *vdc = VIRTIO_DEVICE_GET_CLASS(vdev);
+
features.index = address_space_ldub(&address_space_memory,
ccw.cda
+ sizeof(features.features),
@@ -312,7 +314,7 @@ static int virtio_ccw_cb(SubchDev *sch, CCW1 ccw)
if (dev->revision >= 1) {
/* Don't offer legacy features for modern devices. */
features.features = (uint32_t)
-(vdev->host_features & ~VIRTIO_LEGACY_FEATURES);
+(vdev->host_features & ~vdc->legacy_features);
} else {
features.features = (uint32_t)vdev->host_features;
}
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 62001b4..97b32fe 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -1175,7 +1175,9 @@ static uint64_t virtio_pci_common_read(void *opaque,
hwaddr addr,
break;
case VIRTIO_PCI_COMMON_DF:
if (proxy->dfselect <= 1) {
-val = (vdev->host_features & ~VIRTIO_LEGACY_FEATURES) >>
+VirtioDeviceClass *vdc = VIRTIO_DEVICE_GET_CLASS(vdev);
+
+val = (vdev->host_features & ~vdc->legacy_features) >>
(32 * proxy->dfselect);
}
break;
diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 1df5f4e..72ee06b 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -2214,6 +2214,8 @@ static void virtio_device_class_init(ObjectClass *klass,
void *data)
dc->props = virtio_properties;
vdc->start_ioeventfd = virtio_device_start_ioeventfd_impl;
vdc->stop_ioeventfd = virtio_device_stop_ioeventfd_impl;
+
+vdc->legacy_features |= VIRTIO_LEGACY_FEATURES;
}
bool virtio_device_ioeventfd_enabled(VirtIODevice *vdev)
--
MST
Re: [Qemu-devel] [PATCH 1/5] ARM BE8/BE32 semihosting and gdbstub support.
On 04/11/2016 11:25, Julian Brown wrote: > > The change to arm_cpu_memory_rw_debug for BE32 is also interesting. > > gdb documentation says > > > > The stub need not use any particular size or alignment when > > gathering data from memory for the response; even if ADDR is > > word-aligned and LENGTH is a multiple of the word size, the stub > > is free to use byte accesses, or not. > > > > while your change means that gdb actually wants you to do byte > > accesses. > > The splitting-into-bytes is just an implementation convenience -- the > simplest way I could see of handling the low-order address bit reversal > without breaking abstractions more or shuffling lots of code around. > I'm not sure if GDB was actually requesting sub-word access sizes. Right, the question is what GDB actually wants. I don't really understand how BE32 is compatible with "the stub need not use any particular size or alignment", unless GDB takes care of tweaking the address on its end (and possibly taking care of always reading full words when len>4?!?). Also, it would not depend on SCTLR.B, but rather on the CFGEND property and on CFGEND being tied to SCTLR.B. Thanks, Paolo
Re: [Qemu-devel] [PATCH RFC] iothread: Add "spawns" property
On Fri, Nov 04, 2016 at 10:58:04AM +, Stefan Hajnoczi wrote: > On Wed, Oct 19, 2016 at 04:04:50PM +0800, Fam Zheng wrote: > > The option specifies how many threads to spawn under the iothread > > object. All threads share the same AioContext so they can safely run > > (contend) together. > > > > With AioContext going away, the spawns will natually enable the block > > multi-queue work. > > > > Signed-off-by: Fam Zheng > > > > --- > > > > Based on v2 of Paolo's RFifoLock removal series, with which the > > symmetric contention on the single AioContext is no longer a busy > > preempt loop. > > --- > > include/sysemu/iothread.h | 19 -- > > iothread.c| 148 > > ++ > > 2 files changed, 125 insertions(+), 42 deletions(-) > > I'm not happy with "IOThread" becoming a group of threads. IOThread > should stay the way it is. Instead you should add a new object type > that simply groups IOThreads for convenient assignment to devices, e.g. > IOThreadGroup. Then multiqueue devices can use an IOThreadGroup to work > inside multiple IOThreads. Do we even need a IOThreadGroup object ? Can't we just explicitly pass a list of IOThread object IDs to the device. eg something like -device virtio-blk-pci,iothread=t1,iothread=t2,iothread=t3 Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o-http://search.cpan.org/~danberr/ :|
[Qemu-devel] [PATCH 2/2] virtio-net: mark VIRTIO_NET_F_GSO as legacy
virtio 1.0 spec says this is a legacy feature bit,
hide it from guests in legacy mode.
Note: for cross-version migration compatibility,
we keep the bit set in host_features.
The result will be that a guest migrating cross-version
will see host features change under it.
As guests only seem to read it once, this should
not be an issue. Meanwhile, will work to fix guests to
ignore this bit in virtio1 mode, too.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Michael S. Tsirkin
---
hw/net/virtio-net.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 20aa63e..b68c69d 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -1942,6 +1942,7 @@ static void virtio_net_class_init(ObjectClass *klass,
void *data)
vdc->guest_notifier_pending = virtio_net_guest_notifier_pending;
vdc->load = virtio_net_load_device;
vdc->save = virtio_net_save_device;
+vdc->legacy_features |= (0x1 << VIRTIO_NET_F_GSO);
}
static const TypeInfo virtio_net_info = {
--
MST
[Qemu-devel] [PATCH 0/2] virtio-net: spec compatibility fix
Virtio 1.0 spec lists VIRTIO_NET_F_GSO as a legacy-only flag, by mistake we exposed it on the modern interface too, this is a spec violation. I decided it's not worth it to implement a compatibility bit here as we already shipped virtio 1.0 support, we want to fix compatibility for old machine types too. While changing feature bits under guest's feet might be surprising, the spec doesn't exactly say it's illegal. Michael S. Tsirkin (2): virtio: allow per-device-class legacy features virtio-net: mark VIRTIO_NET_F_GSO as legacy include/hw/virtio/virtio.h | 5 + hw/net/virtio-net.c| 1 + hw/s390x/virtio-ccw.c | 4 +++- hw/virtio/virtio-pci.c | 4 +++- hw/virtio/virtio.c | 2 ++ 5 files changed, 14 insertions(+), 2 deletions(-) -- MST
Re: [Qemu-devel] alpha platform is missing files after initrd load
On Thu, Oct 20, 2016 at 12:45:37PM +0200, Dennis Luehring wrote: > qemu: 2.7.x (git head) > platform: Alpha (Clipper) Two options: 1. Not many people use Alpha. You may need to debug this yourself by learning about the Linux alpha boot protocol (where the initramfs is loaded and how big that region of memory may be). Then you can verify the memory contents after QEMU has loaded the kernel/initramfs using monitor commands to read memory. You may need to look at QEMU's kernel/initramfs loading code to see what it's doing. 2. If it worked in a previous QEMU version, please use git-bisect(1) to find out which commit broke it. Good luck! > kernel: 4.7.0 > gcc: 6.1 > > i don't know if its an qemu oder linux kernel problem > > i've got an ~360MB big_initrd.cpio and it sometimes happen(seems so) that > there are files missing after the kernel loaded the initrd > this does not happen with the same programs/initrd compiled for the sparc64 > platform using qemu > > i've got a small C/C++-based init that prints some infos about the system > and > prints the content of the /tools/bin folder and there a some files missing > that are > definitely in the cpio file > > im starting qemu with > > alpha-softmmu/qemu-system-alpha -m 1GB -nographic -monitor > telnet::4440,server,nowait -serial telnet::3000,server -kernel clfskernel > -append 'console=ttyS0' -initrd big_initrd.cpio > > i've found a problem description on stackoverflow going in the same > direction but im not using an in-kernel-ramfs > http://stackoverflow.com/questions/31524636/files-disappearing-from-initramfs > > i've uploaded my complete test here: > http://www.filedropper.com/testalpha-linux-470gcc-610 (~66MB) > > containing files: > big_initrd.cpio -> the big cpio which misses files after load > clfskernel -> linux 4.7.0 (default settings) > config -> used config > init.cpp -> my init > initrd.cpio -> only kernel+init cpio > kernel.out.txt -> output of the kernel and init > start_big.sh -> my starting script for qemu loading big_initrd.cpio > start_small.sh -> my starting script for qemu loading initrd.cpio > System.map -> kernel map file > tools_dir_after_load.txt -> files in /tools/bin (copy&paste+sort from > kernel.out.txt printdir /tools/bin) > tools_dir_in_cpio.txt -> files in the cpio:/tools/bin > > signature.asc Description: PGP signature
Re: [Qemu-devel] Crashing in tcp_close
On Thu, Oct 20, 2016 at 10:53:50PM +0100, Brian Candler wrote: CCing slirp maintainers to get attention on this bug > I have some reproducible-ish segfaults in qemu 2.7.0 (built from source) > running under ubuntu 16.04, on a quad-core i7 Mac Mini Server. > > I can reproduce these problems on a different Mac Mini, and I also replaced > the RAM on mine, so I'm sure it's not hardware related. > > It's somewhat painful to reproduce (taking about 30 minutes each attempt, > and using a lot of network bandwidth). > > This is using packer (packer.io) to create a VM and then using ansible to do > a whole load of package installation and provisioning inside that VM. > packer starts qemu with a user-mode network interface. > > If I part-build the VM, I can continue the build by restarting it under gdb > and qemu directly at the command line, and get a backtrace. Here's the first > one: > > Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. > 0x76a1bb5b in _int_free (av=0x76d5fb20 , > p=, have_lock=0) at malloc.c:4006 > 4006malloc.c: No such file or directory. > (gdb) bt > #0 0x76a1bb5b in _int_free (av=0x76d5fb20 , > p=, have_lock=0) > at malloc.c:4006 > #1 0x76a1fabc in __GI___libc_free (mem=) at > malloc.c:2969 > #2 0x559a6c0f in tcp_close (tp=tp@entry=0x56621ed0) at > slirp/tcp_subr.c:334 > #3 0x559a6c8f in tcp_drop (tp=tp@entry=0x56621ed0, > err=) at slirp/tcp_subr.c:298 > #4 0x559a816b in tcp_timers (timer=, > tp=0x56621ed0) at slirp/tcp_timer.c:179 > #5 tcp_slowtimo (slirp=slirp@entry=0x5658ecf0) at slirp/tcp_timer.c:89 > #6 0x559a0be8 in slirp_pollfds_poll (pollfds=0x56531f20, > select_error=select_error@entry=0) > at slirp/slirp.c:576 > #7 0x559d4b0c in main_loop_wait (nonblocking=) at > main-loop.c:508 > #8 0x5573fea1 in main_loop () at vl.c:1908 > #9 main (argc=, argv=, envp=) > at vl.c:4604 > (gdb) > > So: > > * Is this of interest? Yes. Thank you for reporting it. > * If so, what additional gdb output would you like me to provide? I wonder if this connection has already been closed/freed before and the timer fires shortly afterward. That's just a guess based on the backtrace. > * If developers want to reproduce this, let me know and I can probably send > the VM qcow2 file and/or packer source privately off-list [I need to check > permission for that] > > Thanks, > > Brian Candler. > > signature.asc Description: PGP signature
Re: [Qemu-devel] [PATCH v2] MAINTAINERS: Add some ARM related files to the corresponding sections
On 12.10.2016 15:34, Alistair Francis wrote: > On Wed, Oct 12, 2016 at 11:57 AM, Thomas Huth wrote: >> The files w/cpu/a*mpcore.c are already assigned to the ARM CPU >> section, but the corresponding headers include/hw/cpu/a*mpcore.h >> are still missing. >> >> The file hw/*/imx* are already assigned to the i.MX31 machine, but >> the corresponding header files include/hw/*/imx* are still missing. >> >> The file hw/misc/arm_integrator_debug.c seems to belong to Integrator >> CP, hw/cpu/realview_mpcore.c seems to belong to Real View, and >> hw/misc/mst_fpga.c seems to belong to PXA2XX. >> >> And the files hw/misc/zynq* and include/hw/misc/zynq* seem to belong >> to the Xilinx Zynq machine. >> >> Signed-off-by: Thomas Huth >> --- >> v2: >> - Added some more file >> - Dropped hw/misc/arm_sysctl.c since it's unclear right now how to >>represent a file that belong to multiple machines >> >> MAINTAINERS | 8 +++- >> 1 file changed, 7 insertions(+), 1 deletion(-) >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 8c1c0a1..7fc5c9d 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -107,6 +107,7 @@ S: Maintained >> F: target-arm/ >> F: hw/arm/ >> F: hw/cpu/a*mpcore.c >> +F: include/hw/cpu/a*mpcore.h >> F: disas/arm.c >> F: disas/arm-a64.cc >> F: disas/libvixl/ >> @@ -408,6 +409,7 @@ M: Peter Chubb >> L: qemu-...@nongnu.org >> S: Odd fixes >> F: hw/*/imx* >> +F: include/hw/*/imx* >> F: hw/arm/kzm.c >> F: include/hw/arm/fsl-imx31.h >> >> @@ -416,6 +418,7 @@ M: Peter Maydell >> L: qemu-...@nongnu.org >> S: Maintained >> F: hw/arm/integratorcp.c >> +F: hw/misc/arm_integrator_debug.c >> >> Musicpal >> M: Jan Kiszka >> @@ -440,6 +443,7 @@ M: Peter Maydell >> L: qemu-...@nongnu.org >> S: Maintained >> F: hw/arm/realview* >> +F: hw/cpu/realview_mpcore.c >> F: hw/intc/realview_gic.c >> F: include/hw/intc/realview_gic.h >> >> @@ -452,6 +456,7 @@ F: hw/arm/spitz.c >> F: hw/arm/tosa.c >> F: hw/arm/z2.c >> F: hw/*/pxa2xx* >> +F: hw/misc/mst_fpga.c >> F: include/hw/arm/pxa.h >> >> Stellaris >> @@ -473,7 +478,8 @@ L: qemu-...@nongnu.org >> S: Maintained >> F: hw/*/xilinx_* >> F: hw/*/cadence_* >> -F: hw/misc/zynq_slcr.c >> +F: hw/misc/zynq* >> +F: include/hw/misc/zynq* >> X: hw/ssi/xilinx_* > > For the Zynq/Xilinx part: > > Reviewed-by: Alistair Francis *ping* - Peter, do you think this update to MAINTAINERS is OK now? Thomas signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v4 1/8] tests: check-qom-proplist: Remove duplicate "bv" property
Eduardo Habkost writes: > The object_property_add_bool() call in dummy_init() is always > failing because there is an existing "bv" class property. We need > to remove either the "bv" class property or the "bv" instance > property. > > Remove the class property so both object properties and class > properties are covered by the test code. > > Reviewed-by: Igor Mammedov > Signed-off-by: Eduardo Habkost I accidentally reviewed an older version of this patch. Just in case: Reviewed-by: Markus Armbruster The multiple colons in the subject are a bit odd. Suggest "tests/check-qom-proplist:".
Re: [Qemu-devel] [PATCH 1/2] virtio: allow per-device-class legacy features
On Fri, 4 Nov 2016 13:01:37 +0200 "Michael S. Tsirkin" wrote: > Legacy features are those that transitional devices only > expose on the legacy interface. > Allow different ones per device class. > > Signed-off-by: Michael S. Tsirkin > --- > include/hw/virtio/virtio.h | 5 + > hw/s390x/virtio-ccw.c | 4 +++- > hw/virtio/virtio-pci.c | 4 +++- > hw/virtio/virtio.c | 2 ++ > 4 files changed, 13 insertions(+), 2 deletions(-) Reviewed-by: Cornelia Huck
Re: [Qemu-devel] [PATCH] target-i386/machine:fix migrate faile because of Hyper-V HV_X64_MSR_VP_RUNTIME
On 04/11/2016 09:16, Zhuangyanying wrote:
> From: ZhuangYanying
>
> Hyper-V HV_X64_MSR_VP_RUNTIME was introduced in linux-4.4 + qemu-2.5.
>
> As long as the KVM module supports, qemu will save / load the
> vmstate_msr_hyperv_runtime register during the migration.
>
> Regardless of whether the hyperv_runtime configuration of x86_cpu_properties
> is
> enabled.
>
> The qemu-2.3 does not support this feature, of course, failed to migrate.
>
> linux-BGSfqC:/home/qemu # ./x86_64-softmmu/qemu-system-x86_64 --enable-kvm
> -nodefaults -machine pc-i440fx-2.3,accel=kvm,usb=off -smp 4 -m 4096 -drive
> file=/work/suse/sles11sp3.img.bak,format=raw,if=none,id=drive-virtio-disk0,cache=none
>
> -device
> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0
>
> -vnc :99 -device cirrus-vga,id=video0,vgamem_mb=8,bus=pci.0,addr=0x2 -monitor
> vc
>
> save_section_header:se->section_id=3,se->idstr:ram,se->instance_id=0,se->version_id=4
>
> save_section_header:se->section_id=0,se->idstr:timer,se->instance_id=0,se->version_id=2
>
> save_section_header:se->section_id=4,se->idstr:cpu_common,se->instance_id=0,se->version_id=1
>
> save_section_header:se->section_id=5,se->idstr:cpu,se->instance_id=0,se->version_id=12
>
> vmstate_subsection_save:vmsd->name:cpu/async_pf_msr
>
> hyperv_runtime_enable_needed:env->msr_hv_runtime=128902811
>
> vmstate_subsection_save:vmsd->name:cpu/msr_hyperv_runtime
>
> Since hyperv_runtime is false, vm will not use hv->runtime_offset, then
> vmstate_msr_hyperv_runtime is no need to transfer while migrating.
>
> Signed-off-by: ann.zhuangyany...@huawei.com
Thanks, the patch is good.
Paolo
> ---
> Hi,
>
> Recently, I tested cross-version migration/rollback between qemu tag v2.3.1
> and
> qemu-master, found that rollback failed.
>
> linux-rIVrzS:/home/git/qemu # ./x86_64-softmmu/qemu-system-x86_64
> --enable-kvm
> -nodefaults -machine pc-i440fx-2.3,accel=kvm,usb=off -smp 4 -m 4096 -drive
> file=/work/suse/sles11sp3.img.bak,format=raw,if=none,id=drive-virtio-disk0,cache=none
>
> -device
> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0
>
> -vnc :99 -device cirrus-vga,id=video0,vgamem_mb=8,bus=pci.0,addr=0x2 -monitor
> vc
> -incoming tcp:0:
>
> qemu-system-x86_64: error while loading state for instance 0x0 of device 'cpu'
>
> qemu-system-x86_64: load of migration failed: No such file or directory
>
> Maybe set compat_props on PC_COMPAT_2_5 ? Any better idea?
> ---
> target-i386/machine.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/target-i386/machine.c b/target-i386/machine.c
> index 48037f1..e984d77 100644
> --- a/target-i386/machine.c
> +++ b/target-i386/machine.c
> @@ -709,6 +709,10 @@ static bool hyperv_runtime_enable_needed(void *opaque)
> X86CPU *cpu = opaque;
> CPUX86State *env = &cpu->env;
>
> +if (!cpu->hyperv_runtime) {
> +return 0;
> +}
> +
> return env->msr_hv_runtime != 0;
> }
>
>
Re: [Qemu-devel] [PATCH 2/2] virtio-net: mark VIRTIO_NET_F_GSO as legacy
On Fri, 4 Nov 2016 13:01:40 +0200
"Michael S. Tsirkin" wrote:
> virtio 1.0 spec says this is a legacy feature bit,
> hide it from guests in legacy mode.
>
> Note: for cross-version migration compatibility,
> we keep the bit set in host_features.
> The result will be that a guest migrating cross-version
> will see host features change under it.
> As guests only seem to read it once, this should
> not be an issue. Meanwhile, will work to fix guests to
> ignore this bit in virtio1 mode, too.
This also means that guest may see a different feature set if it is
e.g. rebooted after migration. But I agree that this should not be an
issue.
>
> Cc: qemu-sta...@nongnu.org
You also need to cc: the previous patch to stable.
> Signed-off-by: Michael S. Tsirkin
> ---
> hw/net/virtio-net.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> index 20aa63e..b68c69d 100644
> --- a/hw/net/virtio-net.c
> +++ b/hw/net/virtio-net.c
> @@ -1942,6 +1942,7 @@ static void virtio_net_class_init(ObjectClass *klass,
> void *data)
> vdc->guest_notifier_pending = virtio_net_guest_notifier_pending;
> vdc->load = virtio_net_load_device;
> vdc->save = virtio_net_save_device;
> +vdc->legacy_features |= (0x1 << VIRTIO_NET_F_GSO);
> }
>
> static const TypeInfo virtio_net_info = {
Reviewed-by: Cornelia Huck
Re: [Qemu-devel] [PATCH v2] MAINTAINERS: Add some ARM related files to the corresponding sections
On 4 November 2016 at 11:18, Thomas Huth wrote: > On 12.10.2016 15:34, Alistair Francis wrote: >> On Wed, Oct 12, 2016 at 11:57 AM, Thomas Huth wrote: >>> The files w/cpu/a*mpcore.c are already assigned to the ARM CPU >>> section, but the corresponding headers include/hw/cpu/a*mpcore.h >>> are still missing. >>> >>> The file hw/*/imx* are already assigned to the i.MX31 machine, but >>> the corresponding header files include/hw/*/imx* are still missing. >>> >>> The file hw/misc/arm_integrator_debug.c seems to belong to Integrator >>> CP, hw/cpu/realview_mpcore.c seems to belong to Real View, and >>> hw/misc/mst_fpga.c seems to belong to PXA2XX. >>> >>> And the files hw/misc/zynq* and include/hw/misc/zynq* seem to belong >>> to the Xilinx Zynq machine. >>> >>> Signed-off-by: Thomas Huth >>> --- > *ping* - Peter, do you think this update to MAINTAINERS is OK now? Yeah, looks OK. Acked-by: Peter Maydell -- PMM
Re: [Qemu-devel] [PATCH v2 03/11] qapi: fix missing symbol @prefix
- Original Message -
> Marc-André Lureau writes:
>
> > Signed-off-by: Marc-André Lureau
> > ---
> > qapi-schema.json | 4 ++--
> > qapi/block-core.json | 4 ++--
> > qapi/crypto.json | 36 ++--
> > 3 files changed, 22 insertions(+), 22 deletions(-)
> >
> > diff --git a/qapi-schema.json b/qapi-schema.json
> > index f07ffd7..3091993 100644
> > --- a/qapi-schema.json
> > +++ b/qapi-schema.json
> > @@ -4526,7 +4526,7 @@
> > { 'include': 'qapi/rocker.json' }
> >
> > ##
> > -# ReplayMode:
> > +# @ReplayMode:
> > #
> > # Mode of the replay subsystem.
> > #
> > @@ -4594,7 +4594,7 @@
> > { 'command': 'query-gic-capabilities', 'returns': ['GICCapability'] }
> >
> > ##
> > -# CpuInstanceProperties
> > +# @CpuInstanceProperties
> > #
> > # List of properties to be used for hotplugging a CPU instance,
> > # it should be passed by management with device_add command when
>
> The example in qapi-code-gen.txt has a colon after the symbol name:
>
> ##
> # @BlockStats:
>
> The text doesn't mention it. Tne schema uses colons inconsistently, as
> visible above. Let's enforce colons.
Ok, it's a bit more tricky though, because we have documentation that uses @arg
inside text to refer to various symbols (args, commands etc). I've fixed all
@symbol: (for sections and members), but I don't see an easy way to enforce
this without conflicting with the @arg syntax.
>
> > diff --git a/qapi/block-core.json b/qapi/block-core.json
> > index cf8e980..73f4180 100644
> > --- a/qapi/block-core.json
> > +++ b/qapi/block-core.json
> > @@ -1149,7 +1149,7 @@
> >'data': 'DriveMirror' }
> >
> > ##
> > -# DriveMirror
> > +# @DriveMirror
> > #
> > # A set of parameters describing drive mirror setup.
> > #
> > @@ -1373,7 +1373,7 @@
> >'data': 'BlockIOThrottle' }
> >
> > ##
> > -# BlockIOThrottle
> > +# @BlockIOThrottle
> > #
> > # A set of parameters describing block throttling.
> > #
> > diff --git a/qapi/crypto.json b/qapi/crypto.json
> > index 6933b13..4ac3034 100644
> > --- a/qapi/crypto.json
> > +++ b/qapi/crypto.json
> > @@ -3,7 +3,7 @@
> > # QAPI crypto definitions
> >
> > ##
> > -# QCryptoTLSCredsEndpoint:
> > +# @QCryptoTLSCredsEndpoint:
> > #
> > # The type of network endpoint that will be using the credentials.
> > # Most types of credential require different setup / structures
> > @@ -22,7 +22,7 @@
> >
> >
> > ##
> > -# QCryptoSecretFormat:
> > +# @QCryptoSecretFormat:
> > #
> > # The data format that the secret is provided in
> > #
> > @@ -36,7 +36,7 @@
> >
> >
> > ##
> > -# QCryptoHashAlgorithm:
> > +# @QCryptoHashAlgorithm:
> > #
> > # The supported algorithms for computing content digests
> > #
> > @@ -55,7 +55,7 @@
> >
> >
> > ##
> > -# QCryptoCipherAlgorithm:
> > +# @QCryptoCipherAlgorithm:
> > #
> > # The supported algorithms for content encryption ciphers
> > #
> > @@ -82,7 +82,7 @@
> >
> >
> > ##
> > -# QCryptoCipherMode:
> > +# @QCryptoCipherMode:
> > #
> > # The supported modes for content encryption ciphers
> > #
> > @@ -97,7 +97,7 @@
> >
> >
> > ##
> > -# QCryptoIVGenAlgorithm:
> > +# @QCryptoIVGenAlgorithm:
> > #
> > # The supported algorithms for generating initialization
> > # vectors for full disk encryption. The 'plain' generator
> > @@ -115,7 +115,7 @@
> >'data': ['plain', 'plain64', 'essiv']}
> >
> > ##
> > -# QCryptoBlockFormat:
> > +# @QCryptoBlockFormat:
> > #
> > # The supported full disk encryption formats
> > #
> > @@ -130,7 +130,7 @@
> >'data': ['qcow', 'luks']}
> >
> > ##
> > -# QCryptoBlockOptionsBase:
> > +# @QCryptoBlockOptionsBase:
> > #
> > # The common options that apply to all full disk
> > # encryption formats
> > @@ -143,7 +143,7 @@
> >'data': { 'format': 'QCryptoBlockFormat' }}
> >
> > ##
> > -# QCryptoBlockOptionsQCow:
> > +# @QCryptoBlockOptionsQCow:
> > #
> > # The options that apply to QCow/QCow2 AES-CBC encryption format
> > #
> > @@ -157,7 +157,7 @@
> >'data': { '*key-secret': 'str' }}
> >
> > ##
> > -# QCryptoBlockOptionsLUKS:
> > +# @QCryptoBlockOptionsLUKS:
> > #
> > # The options that apply to LUKS encryption format
> > #
> > @@ -171,7 +171,7 @@
> >
> >
> > ##
> > -# QCryptoBlockCreateOptionsLUKS:
> > +# @QCryptoBlockCreateOptionsLUKS:
> > #
> > # The options that apply to LUKS encryption format initialization
> > #
> > @@ -201,7 +201,7 @@
> >
> >
> > ##
> > -# QCryptoBlockOpenOptions:
> > +# @QCryptoBlockOpenOptions:
> > #
> > # The options that are available for all encryption formats
> > # when opening an existing volume
> > @@ -216,7 +216,7 @@
> >
> >
> > ##
> > -# QCryptoBlockCreateOptions:
> > +# @QCryptoBlockCreateOptions:
> > #
> > # The options that are available for all encryption formats
> > # when initializing a new volume
> > @@ -231,7 +231,7 @@
> >
> >
> > ##
> > -# QCryptoBlockInfoBase:
> > +# @QCryptoBlockInfoBase:
> > #
> > # The common information that
Re: [Qemu-devel] [PATCH RFC] iothread: Add "spawns" property
On Fri, 11/04 11:03, Daniel P. Berrange wrote: > On Fri, Nov 04, 2016 at 10:58:04AM +, Stefan Hajnoczi wrote: > > On Wed, Oct 19, 2016 at 04:04:50PM +0800, Fam Zheng wrote: > > > The option specifies how many threads to spawn under the iothread > > > object. All threads share the same AioContext so they can safely run > > > (contend) together. > > > > > > With AioContext going away, the spawns will natually enable the block > > > multi-queue work. > > > > > > Signed-off-by: Fam Zheng > > > > > > --- > > > > > > Based on v2 of Paolo's RFifoLock removal series, with which the > > > symmetric contention on the single AioContext is no longer a busy > > > preempt loop. > > > --- > > > include/sysemu/iothread.h | 19 -- > > > iothread.c| 148 > > > ++ > > > 2 files changed, 125 insertions(+), 42 deletions(-) > > > > I'm not happy with "IOThread" becoming a group of threads. IOThread > > should stay the way it is. Instead you should add a new object type > > that simply groups IOThreads for convenient assignment to devices, e.g. > > IOThreadGroup. Then multiqueue devices can use an IOThreadGroup to work > > inside multiple IOThreads. > > Do we even need a IOThreadGroup object ? Can't we just explicitly pass > a list of IOThread object IDs to the device. eg something like > >-device virtio-blk-pci,iothread=t1,iothread=t2,iothread=t3 Is that a supported syntax by qdev/QOM? Fam
Re: [Qemu-devel] [PATCH v2 02/11] qapi: fix schema symbol sections
Hi
- Original Message -
> Marc-André Lureau writes:
>
> > According to documentation, there needs to be '##' to start a symbol
>
> Suggest to be explicit, and say "According to docs/qapi-code-gen.txt".
>
ok
> > section, that's also what the documentation parser expects.
>
> Does the doc parser complain when its expectation isn't met? I haven't
> reviewed it, yet...
I have improved the error reporting in the next iteration, it will raise an
error in this case and others.
>
> In my opinion, qapi-code-gen.txt should demand everything the doc parser
> needs (it may demand more), and the doc parser should complain about
> everything qapi-code-gen.txt demands and the schema doesn't provide.
>
> > Signed-off-by: Marc-André Lureau
>
> The patch fixes all missing '##' at the beginning of definition comment
> blocks. Good.
>
> qapi-code-gen.txt also demands '##' at the end. Does the parser rely on
> it? Offenders:
fixed
>
> diff --git a/qapi-schema.json b/qapi-schema.json
> index fc732cb..0cc9ee6 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -780,6 +780,7 @@
> # command.
> #
> # Since: 2.5
> +##
> { 'command': 'migrate-start-postcopy' }
>
> ##
> @@ -4429,7 +4430,7 @@
> #
> # @DIMM: memory slot
> # @CPU: logical CPU slot (since 2.7)
> -#
> +##
> { 'enum': 'ACPISlotType', 'data': [ 'DIMM', 'CPU' ] }
>
> ##
>
Re: [Qemu-devel] [PATCH v2 2/3] target-m68k: implement 680x0 movem
On 11/04/2016 01:59 AM, Laurent Vivier wrote:
Le 03/11/2016 à 21:47, Richard Henderson a écrit :
On 11/02/2016 03:15 PM, Laurent Vivier wrote:
+for (i = 15; i >= 0; i--, mask >>= 1) {
+if (mask & 1) {
+if ((insn & 7) + 8 == i &&
+m68k_feature(s->env, M68K_FEATURE_EXT_FULL)) {
+/* M68020+: if the addressing register is the
+ * register moved to memory, the value written
+ * is the initial value decremented by the
size of
+ * the operation
+ * M68000/M68010: the value is the initial value
+ */
+TCGv tmp = tcg_temp_new();
+tcg_gen_sub_i32(tmp, mreg(i), incr);
+gen_store(s, opsize, addr, tmp);
+tcg_temp_free(tmp);
+} else {
+gen_store(s, opsize, addr, mreg(i));
+}
+if (mask != 1) {
+tcg_gen_sub_i32(addr, addr, incr);
+}
+}
One more thing: This is pre-decrement. Why are you decrementing after
the store? Seems to me this should be
if (mask & 1) {
tcg_gen_sub_i32(addr, addr, incr);
if (REG(insn, 0) + 8 == i ...)
...
}
Because it has already been decremented by gen_lea()... so this a
problem if we have page fault, except if we use your "areg writeback"
series, and we will.
Ah, I see. No, gen_lea doesn't writeback; only gen_ea does. But I wonder if
this couldn't be cleaned up a tad. I'll get back to you.
r~
Re: [Qemu-devel] [QEMU PATCH] kvmclock: advance clock by time window between vm_stop and pre_save
Marcelo Tosatti wrote:
> This patch, relative to pre-copy migration codepath,
> measures the time between vm_stop() and pre_save(),
> which includes copying the remaining RAM to destination,
> and advances the clock by that amount.
>
> In a VM with 5 seconds downtime, this reduces the guest
> clock difference on destination from 5s to 0.2s.
>
> Please do not apply this yet as some codepaths still need
> checking, submitting early for comments.
>
> Signed-off-by: Marcelo Tosatti
You can use an optional section, and then you don't need to increase the
version number.
I believe you that the clock manipulation is right, only talking about
the migration bits.
> +static uint64_t clock_delta(struct timespec *before, struct timespec *after)
> +{
> +if (before->tv_sec > after->tv_sec ||
> +(before->tv_sec == after->tv_sec &&
> + before->tv_nsec > after->tv_nsec)) {
> +fprintf(stderr, "clock_delta failed: before=(%ld sec, %ld nsec),"
> +"after=(%ld sec, %ld nsec)\n", before->tv_sec,
> +before->tv_nsec, after->tv_sec, after->tv_nsec);
> +abort();
> +}
> +
> +return (after->tv_sec - before->tv_sec) * 10ULL +
> +after->tv_nsec - before->tv_nsec;
> +}
I can't believe that we don't have a helper function already to
calculate this
> +
> +static void kvmclock_pre_save(void *opaque)
> +{
> +KVMClockState *s = opaque;
> +struct timespec now;
> +uint64_t ns;
> +
> +if (s->t_aftervmstop.tv_sec == 0) {
> +return;
> +}
You have your test here.
> +
> +clock_gettime(CLOCK_MONOTONIC, &now);
> +
> +ns = clock_delta(&s->t_aftervmstop, &now);
> +
> +/*
> + * Linux guests can overflow if time jumps
> + * forward in large increments.
> + * Cap maximum adjustment to 10 minutes.
> + */
> +ns = MIN(ns, 6000ULL);
> +
> +if (s->clock + ns > s->clock) {
> +s->ns = ns;
Would it be a good idea to print an error message here? If it has been more
than 10mins since we did the vmstop, something got wrong here.
> +}
> +}
> +
> +static int kvmclock_post_load(void *opaque, int version_id)
> +{
> +KVMClockState *s = opaque;
> +
> +/* save the value from incoming migration */
> +s->advance_clock = s->ns;
> +
> +return 0;
> +}
> +
> static const VMStateDescription kvmclock_vmsd = {
> .name = "kvmclock",
> -.version_id = 1,
> +.version_id = 2,
> .minimum_version_id = 1,
> +.pre_save = kvmclock_pre_save,
> +.post_load = kvmclock_post_load,
> .fields = (VMStateField[]) {
> VMSTATE_UINT64(clock, KVMClockState),
> +VMSTATE_UINT64_V(ns, KVMClockState, 2),
> VMSTATE_END_OF_LIST()
> }
> };
If you need help with the subsection stuff, just ask.
Later, Juan.
Re: [Qemu-devel] [PATCH 01/18] migration: add has_postcopy savevm handler
Vladimir Sementsov-Ogievskiy wrote: > Now postcopy-able states are recognized by not NULL > save_live_complete_postcopy handler. But when we have several different > postcopy-able states, it is not convenient. Ram postcopy may be > disabled, while some other postcopy enabled, in this case Ram state > should behave as it is not postcopy-able. > > This patch add separate has_postcopy handler to specify behaviour of > savevm state. > > Signed-off-by: Vladimir Sementsov-Ogievskiy Reviewed-by: Juan Quintela
Re: [Qemu-devel] [PATCH 02/18] migration: fix ram_save_pending
Vladimir Sementsov-Ogievskiy wrote: > Fill postcopy-able pending only if ram postcopy is enabled. > It is necessary because of there will be other postcopy-able states and > when ram postcopy is disabled, it should not spoil common postcopy > related pending. > > Signed-off-by: Vladimir Sementsov-Ogievskiy Reviewed-by: Juan Quintela
Re: [Qemu-devel] [QEMU PATCH] kvmclock: advance clock by time window between vm_stop and pre_save
On Fri, Nov 04, 2016 at 01:28:48PM +0100, Juan Quintela wrote:
> Marcelo Tosatti wrote:
> > This patch, relative to pre-copy migration codepath,
> > measures the time between vm_stop() and pre_save(),
> > which includes copying the remaining RAM to destination,
> > and advances the clock by that amount.
> >
> > In a VM with 5 seconds downtime, this reduces the guest
> > clock difference on destination from 5s to 0.2s.
> >
> > Please do not apply this yet as some codepaths still need
> > checking, submitting early for comments.
> >
> > Signed-off-by: Marcelo Tosatti
>
> You can use an optional section, and then you don't need to increase the
> version number.
Optional section is more appropriate, thanks.
> I believe you that the clock manipulation is right, only talking about
> the migration bits.
>
> > +static uint64_t clock_delta(struct timespec *before, struct timespec
> > *after)
> > +{
> > +if (before->tv_sec > after->tv_sec ||
> > +(before->tv_sec == after->tv_sec &&
> > + before->tv_nsec > after->tv_nsec)) {
> > +fprintf(stderr, "clock_delta failed: before=(%ld sec, %ld nsec),"
> > +"after=(%ld sec, %ld nsec)\n", before->tv_sec,
> > +before->tv_nsec, after->tv_sec, after->tv_nsec);
> > +abort();
> > +}
> > +
> > +return (after->tv_sec - before->tv_sec) * 10ULL +
> > +after->tv_nsec - before->tv_nsec;
> > +}
>
> I can't believe that we don't have a helper function already to
> calculate this
Couldnt find any...
> > +
> > +static void kvmclock_pre_save(void *opaque)
> > +{
> > +KVMClockState *s = opaque;
> > +struct timespec now;
> > +uint64_t ns;
> > +
> > +if (s->t_aftervmstop.tv_sec == 0) {
> > +return;
> > +}
>
> You have your test here.
>
> > +
> > +clock_gettime(CLOCK_MONOTONIC, &now);
> > +
> > +ns = clock_delta(&s->t_aftervmstop, &now);
> > +
> > +/*
> > + * Linux guests can overflow if time jumps
> > + * forward in large increments.
> > + * Cap maximum adjustment to 10 minutes.
> > + */
> > +ns = MIN(ns, 6000ULL);
> > +
> > +if (s->clock + ns > s->clock) {
> > +s->ns = ns;
>
> Would it be a good idea to print an error message here? If it has been more
> than 10mins since we did the vmstop, something got wrong here.
Not sure... is it not possible for the user to stop migration in some
way?
What if network is very slow and maxdowntime very high?
> > +}
> > +}
> > +
> > +static int kvmclock_post_load(void *opaque, int version_id)
> > +{
> > +KVMClockState *s = opaque;
> > +
> > +/* save the value from incoming migration */
> > +s->advance_clock = s->ns;
> > +
> > +return 0;
> > +}
> > +
> > static const VMStateDescription kvmclock_vmsd = {
> > .name = "kvmclock",
> > -.version_id = 1,
> > +.version_id = 2,
> > .minimum_version_id = 1,
> > +.pre_save = kvmclock_pre_save,
> > +.post_load = kvmclock_post_load,
> > .fields = (VMStateField[]) {
> > VMSTATE_UINT64(clock, KVMClockState),
> > +VMSTATE_UINT64_V(ns, KVMClockState, 2),
> > VMSTATE_END_OF_LIST()
> > }
> > };
>
>
> If you need help with the subsection stuff, just ask.
>
> Later, Juan.
Ok, i'll try to cook up an optional section and lets see what happens.
Thanks Juan.
Re: [Qemu-devel] qemu-ga virtio-serial socket clarification
On Tue, Oct 25, 2016 at 02:14:24PM -0400, Matt Broadstone wrote:
> Hi,
>
> I've been attempting an experimental qemu agent using a node.js daemon on
> the host side, and have run into an issue I was hoping someone here might
> be able to help with:
>
> Using libvirt I've set up a 'unix' channel for a domain using virtio-serial
> (the same way you would for the existing qemu agent) with the name
> 'test.agent', in order to bypass libvirt taking ownership of the domain
> socket. This works as expected, and so does the following test:
>
> - [host] $ echo "testing" | nc -U
> /var/lib/libvirt/qemu/channel/target/domain-T40001/test.agent
> - [guest] $ cat -v < /dev/virtio-ports/test.agent
>
> Then I tried the same test, converting the host->guest communication to
> node.js:
>
> 'use strict';
> const net = require('net');
> const socketPath =
> '/var/lib/libvirt/qemu/channel/target/domain-T40001/test.agent';
> let socket = net.createConnection(socketPath);
> socket.write('testing');
>
> In this case the data makes it across to the guest, however until I
> explicitly close the socket on the sender side (`socket.write('testing', ()
> => socket.end())`) both sides block indefinitely. I understand closing the
> socket brings the node example to parity with the netcat one, however after
> perusing the qemu-ga and libvirt repositories it looks like glib's io
> channels are being used on a single socket, and effectively handling
> bidirectional data.
>
> Is this the expected behavior?
I have reproduced your test and it is expected behavior.
The virtio-serial port inside the guest has two states: connected and
disconnected. When the port is disconnected read(2) returns 0 (EOF).
When the port is connect read(2) blocks or returns whatever data is
currently available.
Regarding node.js: node.js is an event loop so the process continues
running until your Javascript code terminates the event loop (your
script never does). Since the virtio-serial port is kept open by the
node.js process on the host, the guest is in the connected state and
read(2) blocks inside the guest.
Here is a ping-pong test with node.js:
'use strict';
const net = require('net');
const socketPath = '/tmp/test.agent';
let socket = net.createConnection(socketPath);
socket.on('data', (data) => {
let i = Number(data);
socket.write(i + 1 + '\n');
});
socket.write('0\n');
Inside the guest I can alternate between "cat
signature.asc
Description: PGP signature
[Qemu-devel] [Bug 1129571] Re: libreoffice armhf FTBFS
The attachment "FUTEX_WAIT_BITSET.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team. [This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.] -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1129571 Title: libreoffice armhf FTBFS Status in QEMU: Incomplete Status in qemu package in Ubuntu: Confirmed Bug description: We have been experiencing FTBFS of LibreOffice 3.5.7, 12.04, armhf in the launchpad buildds. We believe this is likely due to an error in qemu. While we do not have a small test case yet, we do have a build log (attaching here). The relevant snippet from the build log is: 3.5.7/solver/unxlngr.pro/bin/jaxp.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/juh.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/parser.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/xt.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/unoil.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/ridl.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/jurt.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/xmlsearch.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/LuceneHelpWrapper.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/HelpIndexerTool.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/lucene-core-2.3.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/lucene-analyzers-2.3.jar" com.sun.star.help.HelpIndexerTool -lang cs -mod swriter -zipdir ../../unxlngr.pro/misc/ziptmpswriter_cs -o ../../unxlngr.pro/bin/swriter_cs.zip.unxlngr.pro dmake: Error code 132, while making '../../unxlngr.pro/bin/swriter_cs.zip' We believe this is from bash error code 128 + 4, where 4 is illegal instruction, thus leading us to suspect qemu. Any help in tracking this down would be appreciated. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1129571/+subscriptions
Re: [Qemu-devel] vmx support for qemu
On Wed, Oct 26, 2016 at 03:16:25PM +0300, poletaev wrote: > Hello. I am trying to make realization of vmx for qemu. > > For now it can: > > - decode vmx instructions, vmx determination and vmx MSRs reading is > supported > > - handle interrupts, exceptions, vm exits due to cr 0/4 exits, cr shadowing > is supported > > - run bios POST and some amount of guest code in VirtualBox (tested on 5+ > version). Current problem here is a strange wish of hypervisor to change > processor mode in vmx non-root to vm86 and find ill_op there. I have no > ideas, why VirtualBox wants it (may be someone knows?). > > - configure guest in kvm, but guest can't run due to #PF which kvm can't > handle right on my realization. Details: when kvm configures guest and > enters in it, #PF with 0xfe05b address happens. Kvm goes to handle #PF. > kvm_mmu_page_fault goes to nonpaging_page_fault, which don't find page in > cache and calls nonpaging_map. nonpaging_map exits after critical section > before out_unlock label. For me reaction looks normal, but I didn't dig > deeper. After #PF handling kvm enters to guest again and falls to kvm again > with #PF on 0xfe05b. This situation repeats infinitely. > > > > If somebody have an interest in subject, he can find sources here > https://github.com/ispras/qemu.git , branch vmx. If you want more attention I suggest sending an RFC patch series to qemu-devel@nongnu.org. Guidelines for submitting patches are here: http://qemu-project.org/Contribute/SubmitAPatch Stefan signature.asc Description: PGP signature
Re: [Qemu-devel] [PATCH 03/18] migration: split common postcopy out of ram postcopy
Vladimir Sementsov-Ogievskiy wrote:
> Split common postcopy staff from ram postcopy staff.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> diff --git a/migration/savevm.c b/migration/savevm.c
> index d2efeeb..cce542f 100644
> --- a/migration/savevm.c
> +++ b/migration/savevm.c
> @@ -73,7 +73,7 @@ static struct mig_cmd_args {
> [MIG_CMD_INVALID] = { .len = -1, .name = "INVALID" },
> [MIG_CMD_OPEN_RETURN_PATH] = { .len = 0, .name = "OPEN_RETURN_PATH" },
> [MIG_CMD_PING] = { .len = sizeof(uint32_t), .name = "PING" },
> -[MIG_CMD_POSTCOPY_ADVISE] = { .len = 16, .name = "POSTCOPY_ADVISE" },
> +[MIG_CMD_POSTCOPY_ADVISE] = { .len = -1, .name = "POSTCOPY_ADVISE" },
Not sure if it is a good idea to change postcopy_advise or create a new
one.
Dave, can you comment?
Re: [Qemu-devel] [PATCH 04/18] migration: introduce postcopy-only pending
Vladimir Sementsov-Ogievskiy wrote:
> There would be savevm states (dirty-bitmap) which can migrate only in
> postcopy stage. The corresponding pending is introduced here.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> include/migration/vmstate.h | 5 +++--
> include/sysemu/sysemu.h | 5 +++--
> migration/block.c | 7 ---
> migration/migration.c | 15 ---
> migration/ram.c | 9 +
> migration/savevm.c | 12 +++-
> migration/trace-events | 2 +-
> 7 files changed, 31 insertions(+), 24 deletions(-)
>
> diff --git a/include/migration/vmstate.h b/include/migration/vmstate.h
> index 5c30ef7..dc656be 100644
> --- a/include/migration/vmstate.h
> +++ b/include/migration/vmstate.h
> @@ -58,8 +58,9 @@ typedef struct SaveVMHandlers {
> /* This runs outside the iothread lock! */
> int (*save_live_setup)(QEMUFile *f, void *opaque);
> void (*save_live_pending)(QEMUFile *f, void *opaque, uint64_t max_size,
> - uint64_t *non_postcopiable_pending,
> - uint64_t *postcopiable_pending);
> + uint64_t *res_precopy_only,
> + uint64_t *res_compatible,
> + uint64_t *res_postcopy_only);
Ouch, we really need to move to use an struct here :p
But ugliness was already here.
BTW, with only this patch, it is not clear to me what res_compatible mean
> @@ -1133,7 +1135,7 @@ void qemu_savevm_state_pending(QEMUFile *f, uint64_t
> max_size,
> }
> }
> se->ops->save_live_pending(f, se->opaque, max_size,
> - res_non_postcopiable, res_postcopiable);
> +res_precopy_only, res_compatible, res_postcopy_only);
Indentation is wrong.
Re: [Qemu-devel] [PATCH] travis: trim out most clang builds
On Thu, Oct 27, 2016 at 03:23:45PM +0200, Daniel P. Berrange wrote: > We test with both gcc and clang in order to detect cases > where clang issues warnings that gcc misses. To achieve > this though we don't need to build QEMU in multiple > different configurations. Just a single clang-on-linux > build will be sufficient, if we have an "all enabled" > config. > > This cuts the number of build jobs from 21 to 16, > reducing the load imposed on shared Travis CI infra. > This will make it practical to enable jobs for other > interesting & useful configurations without DOS'ing > Travis to much. > > Signed-off-by: Daniel P. Berrange > --- > .travis.yml | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) Reviewed-by: Stefan Hajnoczi signature.asc Description: PGP signature
Re: [Qemu-devel] Intel HDA and ALSA audio driver hogging event loop
Hi, > > I think the QEMU ALSA sound driver should not be monitoring the > > playback file descriptor if the emulated sound card decides it needs > > to wait for the guest. I think it should never monitor the file descriptor. > > Should we add an AUD_plug_out()/AUD_unplug_out() interface to the QEMU > > audio subsystem so soundcards can suspend file descriptor monitoring? spiceaudio has a rate control which calculates the number of audio samples based on time. That works pretty well and I think it is the best way to handle it. The other audio drivers do the same. Trying to keep the alsa audio buffers full (by watching the playback file handle) does not only cause problems in case the guest hasn't enough audio data to fill them, it also increases the latency in the audio playback pipeline. cheers, Gerd
[Qemu-devel] [Bug 1639225] [NEW] qcow2 - filesize 8.1Petabyte
Public bug reported: problem : Filesystem Size Used Avail Use% Mounted on /dev/sdd1 120G 63G 57G 53% /storage/kvmstorage4ssd # pwd /storage/kvmstorage4ssd/images # qemu-img info vsys19_ssd1.qcow2 image: vsys19_ssd1.qcow2 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 11G cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: true refcount bits: 16 corrupt: true # ls -lah vsys19_* -rw--- 1 root root 8.1P Nov 4 13:16 vsys19_ssd1.qcow2 # ls -la vsys19_* -rw--- 1 root root 9007203702079488 Nov 4 13:16 vsys19_ssd1.qcow2 # qemu-img check vsys19_ssd1.qcow2 qemu-img: Check failed: File too large # xfs_repair /dev/sdd1 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done # pwd /storage/kvmstorage4ssd/images guest OS: # uname -a Linux vsys19 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux cat /etc/debian_version stretch/sid Nov 4 01:23:26 vsys19 kernel: [7654313.024844] end_request: I/O error, dev vdk, sector 8691272 Nov 4 01:23:26 vsys19 kernel: [7654313.025328] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 s tarting block 1085897) Nov 4 01:23:26 vsys19 kernel: [7654313.025334] Buffer I/O error on device dm-1, logical block 1085897 Nov 4 01:23:26 vsys19 kernel: [7654313.025488] Buffer I/O error on device dm-1, logical block 1085898 Nov 4 01:23:26 vsys19 kernel: [7654313.025632] Buffer I/O error on device dm-1, logical block 1085899 Nov 4 01:23:26 vsys19 kernel: [7654313.025776] Buffer I/O error on device dm-1, logical block 1085900 Nov 4 01:23:26 vsys19 kernel: [7654313.025920] Buffer I/O error on device dm-1, logical block 1085901 Nov 4 01:23:26 vsys19 kernel: [7654313.026064] Buffer I/O error on device dm-1, logical block 1085902 Nov 4 01:23:26 vsys19 kernel: [7654313.026207] Buffer I/O error on device dm-1, logical block 1085903 Nov 4 01:23:26 vsys19 kernel: [7654313.026350] Buffer I/O error on device dm-1, logical block 1085904 Nov 4 01:23:26 vsys19 kernel: [7654313.026500] Buffer I/O error on device dm-1, logical block 1085905 Nov 4 01:23:26 vsys19 kernel: [7654313.028837] Buffer I/O error on device dm-1, logical block 1085906 Nov 4 01:23:26 vsys19 kernel: [7654313.031122] end_request: I/O error, dev vdk, sector 8692280 Nov 4 01:23:26 vsys19 kernel: [7654313.031325] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 starting block 1086023) Nov 4 01:23:26 vsys19 kernel: [7654313.031388] end_request: I/O error, dev vdk, sector 8693288 Nov 4 01:23:26 vsys19 kernel: [7654313.031527] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 starting block 1086149) Nov 4 01:23:26 vsys19 kernel: [7654313.031598] end_request: I/O error, dev vdk, sector 8694296 Nov 4 01:23:26 vsys19 kernel: [7654313.031736] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 starting block 1086275) Nov 4 01:23:26 vsys19 kernel: [7654313.031798] end_request: I/O error, dev vdk, sector 8695304 Nov 4 01:23:26 vsys19 kernel: [7654313.031933] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 starting block 1086401) KVM host : # cat /etc/debian_version stretch/sid Debian # uname -a Linux asus1 4.5.5-custom #1 SMP Sun May 22 21:14:57 CEST 2016 x86_64 GNU/Linux # dpkg -l | grep -i qemu ii ipxe-qemu 1.0.0+git-20150424.a25a16d-1all PXE boot firmware - ROM images for qemu ii qemu 1:2.5+dfsg-5+b1 amd64 fast processor emulator ii qemu-kvm 1:2.5+dfsg-5+b1 amd64 QEMU Full virtualization on x86 hardware ii qe
[Qemu-devel] [Bug 1639225] Re: qcow2 - filesize 8.1Petabyte
thereis any chance to fix this qcow2 image? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1639225 Title: qcow2 - filesize 8.1Petabyte Status in QEMU: New Bug description: problem : Filesystem Size Used Avail Use% Mounted on /dev/sdd1 120G 63G 57G 53% /storage/kvmstorage4ssd # pwd /storage/kvmstorage4ssd/images # qemu-img info vsys19_ssd1.qcow2 image: vsys19_ssd1.qcow2 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 11G cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: true refcount bits: 16 corrupt: true # ls -lah vsys19_* -rw--- 1 root root 8.1P Nov 4 13:16 vsys19_ssd1.qcow2 # ls -la vsys19_* -rw--- 1 root root 9007203702079488 Nov 4 13:16 vsys19_ssd1.qcow2 # qemu-img check vsys19_ssd1.qcow2 qemu-img: Check failed: File too large # xfs_repair /dev/sdd1 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done # pwd /storage/kvmstorage4ssd/images guest OS: # uname -a Linux vsys19 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux cat /etc/debian_version stretch/sid Nov 4 01:23:26 vsys19 kernel: [7654313.024844] end_request: I/O error, dev vdk, sector 8691272 Nov 4 01:23:26 vsys19 kernel: [7654313.025328] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 s tarting block 1085897) Nov 4 01:23:26 vsys19 kernel: [7654313.025334] Buffer I/O error on device dm-1, logical block 1085897 Nov 4 01:23:26 vsys19 kernel: [7654313.025488] Buffer I/O error on device dm-1, logical block 1085898 Nov 4 01:23:26 vsys19 kernel: [7654313.025632] Buffer I/O error on device dm-1, logical block 1085899 Nov 4 01:23:26 vsys19 kernel: [7654313.025776] Buffer I/O error on device dm-1, logical block 1085900 Nov 4 01:23:26 vsys19 kernel: [7654313.025920] Buffer I/O error on device dm-1, logical block 1085901 Nov 4 01:23:26 vsys19 kernel: [7654313.026064] Buffer I/O error on device dm-1, logical block 1085902 Nov 4 01:23:26 vsys19 kernel: [7654313.026207] Buffer I/O error on device dm-1, logical block 1085903 Nov 4 01:23:26 vsys19 kernel: [7654313.026350] Buffer I/O error on device dm-1, logical block 1085904 Nov 4 01:23:26 vsys19 kernel: [7654313.026500] Buffer I/O error on device dm-1, logical block 1085905 Nov 4 01:23:26 vsys19 kernel: [7654313.028837] Buffer I/O error on device dm-1, logical block 1085906 Nov 4 01:23:26 vsys19 kernel: [7654313.031122] end_request: I/O error, dev vdk, sector 8692280 Nov 4 01:23:26 vsys19 kernel: [7654313.031325] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 starting block 1086023) Nov 4 01:23:26 vsys19 kernel: [7654313.031388] end_request: I/O error, dev vdk, sector 8693288 Nov 4 01:23:26 vsys19 kernel: [7654313.031527] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 starting block 1086149) Nov 4 01:23:26 vsys19 kernel: [7654313.031598] end_request: I/O error, dev vdk, sector 8694296 Nov 4 01:23:26 vsys19 kernel: [7654313.031736] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 starting block 1086275) Nov 4 01:23:26 vsys19 kernel: [7654313.031798] end_request: I/O error, dev vdk, sector 8695304 Nov 4 01:23:26 vsys19 kernel: [7654313.031933] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 starting block 1086401) KVM host : # cat /etc/debian_version stretch/sid Debian # uname -a Linux asus1 4.5.5-custom #
Re: [Qemu-devel] Intel HDA and ALSA audio driver hogging event loop
On Fri, Nov 4, 2016 at 12:55 PM, Gerd Hoffmann wrote: >> > I think the QEMU ALSA sound driver should not be monitoring the >> > playback file descriptor if the emulated sound card decides it needs >> > to wait for the guest. > > I think it should never monitor the file descriptor. > >> > Should we add an AUD_plug_out()/AUD_unplug_out() interface to the QEMU >> > audio subsystem so soundcards can suspend file descriptor monitoring? > > spiceaudio has a rate control which calculates the number of audio > samples based on time. That works pretty well and I think it is the > best way to handle it. The other audio drivers do the same. > > Trying to keep the alsa audio buffers full (by watching the playback > file handle) does not only cause problems in case the guest hasn't > enough audio data to fill them, it also increases the latency in the > audio playback pipeline. Okay, then the ALSA backend needs to be changed. Thanks for explaining. I probably won't have time to look into this issue. Stefan
Re: [Qemu-devel] [PATCH 5/5] Fix typo in arm_cpu_do_interrupt_aarch32.
On 3 November 2016 at 21:26, Julian Brown wrote:
> This appears to be a typo in arm_cpu_do_interrupt_aarch32 (OR'ing with ~CPSR_E
> instead of CPSR_E).
>
> Signed-off-by: Julian Brown
> ---
> target-arm/helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target-arm/helper.c b/target-arm/helper.c
> index 25b15dc..b5b65ca 100644
> --- a/target-arm/helper.c
> +++ b/target-arm/helper.c
> @@ -6438,7 +6438,7 @@ static void arm_cpu_do_interrupt_aarch32(CPUState *cs)
> /* Set new mode endianness */
> env->uncached_cpsr &= ~CPSR_E;
> if (env->cp15.sctlr_el[arm_current_el(env)] & SCTLR_EE) {
> -env->uncached_cpsr |= ~CPSR_E;
> +env->uncached_cpsr |= CPSR_E;
> }
> env->daif |= mask;
> /* this is a lie, as the was no c1_sys on V4T/V5, but who cares
> --
> 1.9.1
This is an obvious bugfix so I've applied it to target-arm.next
for 2.8. I tweaked the commit message a bit to say what the
effects of the bug were.
thanks
-- PMM
Re: [Qemu-devel] [PATCH v4] This patch adds support for a new block device type called "vxhs".
Please keep using "block/vxhs: Add Veritas HyperScale VxHS block device support" as the cover letter email subject. This way tools are able to automatically mark old versions of this patch series as obsolete. signature.asc Description: PGP signature
Re: [Qemu-devel] [PATCH 12/18] migration: add postcopy migration of dirty bitmaps
Vladimir Sementsov-Ogievskiy wrote:
> Postcopy migration of dirty bitmaps. Only named dirty bitmaps,
> associated with root nodes and non-root named nodes are migrated.
>
> If destination qemu is already containing a dirty bitmap with the same name
> as a migrated bitmap (for the same node), than, if their granularities are
> the same the migration will be done, otherwise the error will be generated.
>
> If destination qemu doesn't contain such bitmap it will be created.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> diff --git a/migration/block-dirty-bitmap.c b/migration/block-dirty-bitmap.c
> new file mode 100644
> index 000..c668d02
> --- /dev/null
> +++ b/migration/block-dirty-bitmap.c
> @@ -0,0 +1,699 @@
> +/*
> + * QEMU dirty bitmap migration
> + *
> + * Postcopy migration of dirty bitmaps. Only named dirty bitmaps, associated
> + * with root nodes and non-root named nodes are migrated.
> + *
> + * If destination qemu is already containing a dirty bitmap with the same
> name
> + * as a migrated bitmap (for the same node), than, if their granularities are
> + * the same the migration will be done, otherwise the error will be
> generated.
> + *
> + * If destination qemu doesn't contain such bitmap it will be created.
> + *
> + * format of migration:
> + *
> + * # Header (shared for different chunk types)
> + * 1, 2 or 4 bytes: flags (see qemu_{put,put}_flags)
> + * [ 1 byte: node name size ] \ flags & DEVICE_NAME
> + * [ n bytes: node name ] /
> + * [ 1 byte: bitmap name size ] \ flags & BITMAP_NAME
> + * [ n bytes: bitmap name ] /
> + *
> + * # Start of bitmap migration (flags & START)
> + * header
> + * be64: granularity
> + * 1 byte: bitmap enabled flag
> + *
> + * # Complete of bitmap migration (flags & COMPLETE)
> + * header
> + *
> + * # Data chunk of bitmap migration
> + * header
> + * be64: start sector
> + * be32: number of sectors
> + * [ be64: buffer size ] \ ! (flags & ZEROES)
> + * [ n bytes: buffer] /
> + *
> + * The last chunk in stream should contain flags & EOS. The chunk may skip
> + * device and/or bitmap names, assuming them to be the same with the previous
> + * chunk.
> + *
> + *
> + * This file is derived from migration/block.c
> + *
> + * Author:
> + * Vladimir Sementsov-Ogievskiy
> + *
> + * original copyright message:
> + * =
> + * Copyright IBM, Corp. 2009
> + *
> + * Authors:
> + * Liran Schour
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2. See
> + * the COPYING file in the top-level directory.
> + *
> + * Contributions after 2012-01-13 are licensed under the terms of the
> + * GNU GPL, version 2 or (at your option) any later version.
> + * =
> + */
I think that the normal practice is putting first the copyright and then
the comment of the file.
> +static void qemu_put_bitmap_flags(QEMUFile *f, uint32_t flags)
> +{
> +if (!(flags & 0xff00)) {
> +qemu_put_byte(f, flags);
> +return;
> +}
> +
> +if (!(flags & 0x)) {
> +qemu_put_be16(f, flags | DIRTY_BITMAP_MIG_FLAGS_SIZE_16);
> +return;
> +}
> +
> +qemu_put_be32(f, flags | DIRTY_BITMAP_MIG_FLAGS_SIZE_32);
> +}
Do need flags so many times to be a good idea to spend two flags and
make the code more complex? Couldn't just sent always the 32bit word
and call it a day?
I have only looked at the stuff quickly from the migration point of
view, not about the bitmap stuff.
> +static void send_bitmap_complete(QEMUFile *f, DirtyBitmapMigBitmapState
> *dbms)
> +{
> +send_bitmap_header(f, dbms, DIRTY_BITMAP_MIG_FLAG_COMPLETE);
> +}
> +
> +static void send_bitmap_bits(QEMUFile *f, DirtyBitmapMigBitmapState *dbms,
> + uint64_t start_sector, uint32_t nr_sectors)
> +{
> +/* align for buffer_is_zero() */
> +uint64_t align = 4 * sizeof(long);
> +uint64_t unaligned_size =
> +bdrv_dirty_bitmap_serialization_size(dbms->bitmap,
> + start_sector, nr_sectors);
> +uint64_t buf_size = (unaligned_size + align - 1) & ~(align - 1);
> +uint8_t *buf = g_malloc0(buf_size);
> +uint32_t flags = DIRTY_BITMAP_MIG_FLAG_BITS;
> +
> +bdrv_dirty_bitmap_serialize_part(dbms->bitmap, buf,
> + start_sector, nr_sectors);
> +
> +if (buffer_is_zero(buf, buf_size)) {
> +g_free(buf);
> +buf = NULL;
> +flags |= DIRTY_BITMAP_MIG_FLAG_ZEROES;
> +}
> +
> +DPRINTF("parameters:"
> +"\n flags:%x"
> +"\n start_sector: %" PRIu64
> +"\n nr_sectors: %" PRIu32
> +"\n data_size:%" PRIu64 "\n",
> +flags, start_sector, nr_sectors, buf_size);
Now we are adding traces, not DPRINF's to new code in general.
Same for all DPRINTFs
> +
> +send_bitmap_header(f, dbms,
[Qemu-devel] [PATCH for-2.8] migration: Fix return code of ram_save_iterate()
qemu_savevm_state_iterate() expects the iterators to return 1
when they are done, and 0 if there is still something left to do.
However, ram_save_iterate() does not obey this rule and returns
the number of saved pages instead. This causes a fatal hang with
ppc64 guests when you run QEMU like this (also works with TCG):
qemu-img create -f qcow2 /tmp/test.qcow2 1M
qemu-system-ppc64 -nographic -nodefaults -m 256 \
-hda /tmp/test.qcow2 -serial mon:stdio
... then switch to the monitor by pressing CTRL-a c and try to
save a snapshot with "savevm test1" for example.
After the first iteration, ram_save_iterate() always returns 0 here,
so that qemu_savevm_state_iterate() hangs in an endless loop and you
can only "kill -9" the QEMU process.
Fix it by using proper return values in ram_save_iterate().
Signed-off-by: Thomas Huth
---
migration/ram.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/migration/ram.c b/migration/ram.c
index fb9252d..a1c8089 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -1987,7 +1987,7 @@ static int ram_save_iterate(QEMUFile *f, void *opaque)
int ret;
int i;
int64_t t0;
-int pages_sent = 0;
+int done = 0;
rcu_read_lock();
if (ram_list.version != last_version) {
@@ -2007,9 +2007,9 @@ static int ram_save_iterate(QEMUFile *f, void *opaque)
pages = ram_find_and_save_block(f, false, &bytes_transferred);
/* no more pages to sent */
if (pages == 0) {
+done = 1;
break;
}
-pages_sent += pages;
acct_info.iterations++;
/* we want to check in the 1st loop, just in case it was the 1st time
@@ -2044,7 +2044,7 @@ static int ram_save_iterate(QEMUFile *f, void *opaque)
return ret;
}
-return pages_sent;
+return done;
}
/* Called with iothread lock */
--
1.8.3.1
Re: [Qemu-devel] ping Re: [PATCH 00/18] Dirty bitmaps postcopy migration
"Denis V. Lunev" wrote: > On 11/02/2016 02:13 PM, Stefan Hajnoczi wrote: >> On Tue, Oct 25, 2016 at 04:04:35PM +0300, Vladimir Sementsov-Ogievskiy wrote: >>> ping >>> >>> For now there are some notes mostly about accessory patches. What about >>> migration itself? Is it ok? Has it a chance of being merged one day? >> This series mostly touches migration/ code. Juan or DaveG? > yep. this is the problem :( > > or they can just accept ;) I just commented on almost all the migration bits of the patches (and noticed that fam/john snow commented on almost all the block ones). Later, Juan.
Re: [Qemu-devel] A question about virtual machine communication with Guest through serial device
On Mon, Oct 31, 2016 at 06:41:23AM +, Liu Pedroa wrote: > Hi Everyone. > > > I have a sample question. As the subset description. > > > Guest OS : Ubuntu OS > > QEMU : linux kernel 4.8 > > > so i want the virtual client OS can communication( can send and receive > messages through serial device) with Guest OS. what should i do? Add a chardev to your QEMU command-line (try -serial unix:/tmp/test.sock,server,nowait). Read the qemu(1) man page for details on chardevs and all the options. Inside the guest you need to access the serial port (e.g. /dev/ttyS0 on Linux but make sure no login tty is running on that port). On the host you can access the UNIX domain socket given on your QEMU command-line. That would be /tmp/test.sock in this example. Also consider using virtio-serial instead of the traditional ISA serial device. It allows you to add/remove named (e.g. org.myproject.agent.0) ports at run-time. Search online to find example syntax. Stefan signature.asc Description: PGP signature
[Qemu-devel] [PATCH v2 3.5/3] fixup! tests: Enhance qobject output to cover partial visit
[adds comments. No commit body change]
Signed-off-by: Eric Blake
---
tests/test-qobject-output-visitor.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/tests/test-qobject-output-visitor.c
b/tests/test-qobject-output-visitor.c
index fdae0d5..7646bb4 100644
--- a/tests/test-qobject-output-visitor.c
+++ b/tests/test-qobject-output-visitor.c
@@ -260,10 +260,12 @@ static void
test_visitor_out_partial_visit(TestOutputVisitorData *data,
/* Various checks that a mid-visit abort doesn't leak or double-free. */
const char *str = "hi";
Error *err = NULL;
-UserDefAlternate uda = { .type = QTYPE_QDICT,
- .u.udfu = { .integer = 1,
- .string = (char *) "bye",
- .enum1 = -1 } };
+UserDefAlternate uda = {
+.type = QTYPE_QDICT,
+.u.udfu = { .integer = 1,
+.string = (char *) "bye",
+.enum1 = -1 } /* intentionally bad */
+};
UserDefAlternate *obj = &uda;
/* Abort within a nested object with no data members */
@@ -286,6 +288,7 @@ static void
test_visitor_out_partial_visit(TestOutputVisitorData *data,
visit_type_UserDefUnionBase_members(data->ov,
(UserDefUnionBase *)&uda.u.udfu,
&err);
+/* error expected because of bad "enum1" discriminator value */
error_free_or_abort(&err);
visitor_reset(data);
}
--
2.7.4
Re: [Qemu-devel] [PATCH] README: Add linux to macOS build info
On Mon, Oct 31, 2016 at 05:01:30PM +, Peter Maydell wrote: > The README lists the URLs for the wiki pages describing > how to build on Linux and Windows; add the equivalent > link for building on macOS. > > Signed-off-by: Peter Maydell > --- > README | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Stefan Hajnoczi signature.asc Description: PGP signature
[Qemu-devel] [Bug 1639225] Re: qcow2 - filesize 8.1Petabyte
Seems like you are using the QEMU from your Linux distribution (Debian?). If you want to have support for that version, you should use the bug tracker from your distro instead. Otherwise, can you please try again with the latest version from http://wiki.qemu-project.org/Download to see whether the bug is already fixed there? Thanks! ** Changed in: qemu Status: New => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1639225 Title: qcow2 - filesize 8.1Petabyte Status in QEMU: Incomplete Bug description: problem : Filesystem Size Used Avail Use% Mounted on /dev/sdd1 120G 63G 57G 53% /storage/kvmstorage4ssd # pwd /storage/kvmstorage4ssd/images # qemu-img info vsys19_ssd1.qcow2 image: vsys19_ssd1.qcow2 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 11G cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: true refcount bits: 16 corrupt: true # ls -lah vsys19_* -rw--- 1 root root 8.1P Nov 4 13:16 vsys19_ssd1.qcow2 # ls -la vsys19_* -rw--- 1 root root 9007203702079488 Nov 4 13:16 vsys19_ssd1.qcow2 # qemu-img check vsys19_ssd1.qcow2 qemu-img: Check failed: File too large # xfs_repair /dev/sdd1 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done # pwd /storage/kvmstorage4ssd/images guest OS: # uname -a Linux vsys19 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux cat /etc/debian_version stretch/sid Nov 4 01:23:26 vsys19 kernel: [7654313.024844] end_request: I/O error, dev vdk, sector 8691272 Nov 4 01:23:26 vsys19 kernel: [7654313.025328] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 s tarting block 1085897) Nov 4 01:23:26 vsys19 kernel: [7654313.025334] Buffer I/O error on device dm-1, logical block 1085897 Nov 4 01:23:26 vsys19 kernel: [7654313.025488] Buffer I/O error on device dm-1, logical block 1085898 Nov 4 01:23:26 vsys19 kernel: [7654313.025632] Buffer I/O error on device dm-1, logical block 1085899 Nov 4 01:23:26 vsys19 kernel: [7654313.025776] Buffer I/O error on device dm-1, logical block 1085900 Nov 4 01:23:26 vsys19 kernel: [7654313.025920] Buffer I/O error on device dm-1, logical block 1085901 Nov 4 01:23:26 vsys19 kernel: [7654313.026064] Buffer I/O error on device dm-1, logical block 1085902 Nov 4 01:23:26 vsys19 kernel: [7654313.026207] Buffer I/O error on device dm-1, logical block 1085903 Nov 4 01:23:26 vsys19 kernel: [7654313.026350] Buffer I/O error on device dm-1, logical block 1085904 Nov 4 01:23:26 vsys19 kernel: [7654313.026500] Buffer I/O error on device dm-1, logical block 1085905 Nov 4 01:23:26 vsys19 kernel: [7654313.028837] Buffer I/O error on device dm-1, logical block 1085906 Nov 4 01:23:26 vsys19 kernel: [7654313.031122] end_request: I/O error, dev vdk, sector 8692280 Nov 4 01:23:26 vsys19 kernel: [7654313.031325] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 starting block 1086023) Nov 4 01:23:26 vsys19 kernel: [7654313.031388] end_request: I/O error, dev vdk, sector 8693288 Nov 4 01:23:26 vsys19 kernel: [7654313.031527] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 starting block 1086149) Nov 4 01:23:26 vsys19 kernel: [7654313.031598] end_request: I/O error, dev vdk, sector 8694296 Nov 4 01:23:26 vsys19 kernel: [7654313.031736] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 starting block 1086275) Nov 4 01:23:26 vsys19 kernel: [7654313.03
Re: [Qemu-devel] [PATCH v2 05/11] docs: add qapi texi template
Hi
- Original Message -
> Marc-André Lureau writes:
>
> > The qapi2texi scripts uses a template for the texi file. Since we are
> > going to generate the documentation in multiple formats, move qmp-intro
> > to qemu-qapi template. (it would be nice to write something similar for
> > qemu-ga, but this is left for a future patch)
> >
> > Signed-off-by: Marc-André Lureau
>
> I'm not exactly a Texinfo expert, but I can compare to the Texinfo
> manual.
>
> Lots of comments below. Please don't let them discourage you! Your two
> manuals are pretty slick already, and a most welcome step forward.
I based it on some older version of qemu-doc.texi. Many of your remarks are
also valid for it.
>
> > ---
> > docs/qemu-ga-qapi.template.texi | 58
> > docs/qemu-qapi.template.texi| 148
> >
> > docs/qmp-intro.txt | 87 ---
> > 3 files changed, 206 insertions(+), 87 deletions(-)
> > create mode 100644 docs/qemu-ga-qapi.template.texi
> > create mode 100644 docs/qemu-qapi.template.texi
> > delete mode 100644 docs/qmp-intro.txt
> >
> > diff --git a/docs/qemu-ga-qapi.template.texi
> > b/docs/qemu-ga-qapi.template.texi
> > new file mode 100644
> > index 000..3ddbf56
> > --- /dev/null
> > +++ b/docs/qemu-ga-qapi.template.texi
> > @@ -0,0 +1,58 @@
> > +\input texinfo
>
> The Texinfo manual uses
>
>\input texinfo @c -*-texinfo-*-
>
> but my version of Emacs seems to be fine without this.
Shouldn't be necessary imho (in general, I am not fond of modeline unless
necessary)
>
> > +@setfilename qemu-ga-qapi
>
> Not wrong, but the Texinfo manual recommends to replace the extension
> (here: .texi) with .info, so let's do that:
>
>@setfilename qemu-ga-qapi.info
ok
>
> > +@documentlanguage en
>
> This overrides the default en_US to just en. Is that what we want?
let's keep the default
>
> > +@exampleindent 0
> > +@paragraphindent 0
> > +
> > +@settitle QEMU-GA QAPI Reference Manual
>
> What is "QAPI", and why would the reader care? I think the manual is
> about the QEMU Guest Agent Protocol. The fact that its implementation
> relies on QAPI is immaterial here. What about:
>
>@settitle QEMU Guest Agent Protocol Reference
>
> But then the filenames are off. Rename to qemu-ga-ref.*.
fine by me
>
> > +
>
> I think we need a copyright note. Something like:
>
>@copying
>This is the QEMU Guest Agent QAPI reference manual.
>
>Copyright @copyright{} 2016 The QEMU Project developers
>
>@quotation
>Permission is granted to ...
>@end quotation
>@end copying
>
> > +@ifinfo
>
>@dircategory QEMU
ok
> Should be added to qemu-doc.texi as well.
I'll leave that for another series
>
> > +@direntry
> > +* QEMU-GA-QAPI: (qemu-doc).QEMU-GA QAPI Reference Manual
>
> Pasto: (qemu-doc)
>
> The description should start at column 32, not 31.
>
> If we retitle and rename as suggested, this becomes:
>
>* QEMU-GA-Ref: (qemu-ga-ref): QEMU Guest Agent Protocol Reference
>
ok
> > +@end direntry
> > +@end ifinfo
>
> Are you sure we need @ifinfo?
Probably not, but it looks more explicit to me that this part is only for .info
> > +
> > +@iftex
> > +@titlepage
> > +@sp 7
> > +@center @titlefont{{QEMU Guest Agent {version}}}
>
> {version} seems to get replaced by qapi2texi.py. Worth a comment.
>
ok
> > +@sp 1
> > +@center @titlefont{{QAPI Reference Manual}}
>
> Protocol Reference Manual
>
> > +@sp 3
>
> Isn't @sp right before @end titlepage redundant?
ok
>
> We need to include the copyright notice:
>
>@page
>@vskip 0pt plus 1filll
>@insertcopying
>
ok
> > +@end titlepage
> > +@end iftex
>
> Are you sure we need @iftex?
Same as qemu-doc.texi, I suppose it looks better with info.
>
> We can also let Texinfo do the spacing, like this:
>
>@titlepage
>@title QEMU Guest Agent {version}
>@subtitle Protocol Reference Manual
>@page
>@vskip 0pt plus 1filll
>@insertcopying
>@end titlepage
>
That ends up with a different results than qapi-doc, but I also prefer it
> The @title isn't really the title, though. Could reshuffle things a
> bit, e.g.
>
>@title QEMU Guest Agent Protocol Reference Manual
>@subtitle for QEMU {version}
>
> Your choice.
Yep, looks good, altough doesn't fit on a single line, I am dropping the
leading QEMU
> The examples in Texinfo manual Appendix C "Sample Texinfo Files" have
> @contents right here, after the title page.
>
Ok
> > +
> > +@ifnottex
> > +@node Top
> > +@top
>
>@top QEMU Guest Agent QAPI reference
>
> > +
> > +This is the QEMU Guest Agent QAPI reference for QEMU {version}.
>
> "protocol reference manual for"
>
> According to the Texinfo manual's examples, the @end ifnottex goes
> here...
Removing it, now redundant with @copying text
>
> > +
> > +@menu
> > +* API Reference::
> > +* Commands and Events Index::
> > +* Data Types Index::
> > +
Re: [Qemu-devel] [PATCH 3/3] Split ISA and sysbus versions of m48t59 device
On 11/04/2016 05:22 AM, Markus Armbruster wrote: > Needs a rebase. First error: > > CC hw/timer/m48t59.o > In file included from /work/armbru/qemu/include/exec/cpu-common.h:7:0, > from /work/armbru/qemu/include/exec/memory.h:24, > from /work/armbru/qemu/include/hw/isa/isa.h:6, > from /work/armbru/qemu/hw/timer/m48t59-isa.c:25: > /work/armbru/qemu/include/exec/hwaddr.h:11:9: error: unknown type name > ‘uint64_t’ > typedef uint64_t hwaddr; > ^ > >> index 000..3a521dc >> --- /dev/null >> +++ b/hw/timer/m48t59-isa.c >> + * THE SOFTWARE. >> + */ >> +#include "hw/isa/isa.h" Probably because you forgot osdep.h as the first include. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 2/5] Fix Thumb-1 BE32 execution and disassembly.
On 3 November 2016 at 17:30, Julian Brown wrote:
> Thumb-1 code has some issues in BE32 mode (as currently implemented). In
> short, since bytes are swapped within words at load time for BE32
> executables, this also swaps pairs of adjacent Thumb-1 instructions.
>
> This patch un-swaps those pairs of instructions again, both for execution,
> and for disassembly.
>
> Signed-off-by: Julian Brown
> ---
> disas/arm.c | 46 +++---
> include/disas/bfd.h | 1 +
> target-arm/arm_ldst.h | 10 +-
> target-arm/cpu.c | 4
> 4 files changed, 49 insertions(+), 12 deletions(-)
>
> diff --git a/disas/arm.c b/disas/arm.c
> index 93c6503..4807ba3 100644
> --- a/disas/arm.c
> +++ b/disas/arm.c
> @@ -3863,10 +3863,11 @@ print_insn_arm (bfd_vma pc, struct disassemble_info
> *info)
>int is_data = false;
>unsigned int size = 4;
>void (*printer) (bfd_vma, struct disassemble_info *, long);
> - int little;
> + int little, is_thumb1_be32 = false;
>
>little = (info->endian == BFD_ENDIAN_LITTLE);
>is_thumb |= (pc & 1);
> + is_thumb1_be32 = (info->flags & INSN_ARM_THUMB1_BE32) != 0;
>pc &= ~(bfd_vma)1;
>
>if (force_thumb)
> @@ -3915,11 +3916,22 @@ print_insn_arm (bfd_vma pc, struct disassemble_info
> *info)
>info->bytes_per_chunk = 2;
>size = 2;
>
> - status = info->read_memory_func (pc, (bfd_byte *)b, 2, info);
> - if (little)
> - given = (b[0]) | (b[1] << 8);
> - else
> - given = (b[1]) | (b[0] << 8);
> + if (is_thumb1_be32) {
> + status = info->read_memory_func(pc & ~3, (bfd_byte *)b, 4, info);
> + assert(little);
> + if ((pc & 2) == 0) {
> + given = b[2] | (b[3] << 8);
> + } else {
> + given = b[0] | (b[1] << 8);
> + }
> + } else {
> + status = info->read_memory_func(pc, (bfd_byte *)b, 2, info);
> + if (little) {
> + given = (b[0]) | (b[1] << 8);
> + } else {
> + given = (b[1]) | (b[0] << 8);
> + }
> + }
Could we do this instead by changing the read_memory_func() so that it
did the appropriate XORing of addresses ? (Chaining through to
the original read_memory_func would be a bit irritating as you'd
need to find a place to stash that function pointer where you
could get at it again from the new read_memory_func.)
thanks
-- PMM
Re: [Qemu-devel] [PATCH RFC] iothread: Add "spawns" property
On 11/04/2016 07:10 AM, Fam Zheng wrote: >> Do we even need a IOThreadGroup object ? Can't we just explicitly pass >> a list of IOThread object IDs to the device. eg something like >> >>-device virtio-blk-pci,iothread=t1,iothread=t2,iothread=t3 > > Is that a supported syntax by qdev/QOM? With all the qdict_crumple conversation going on, we definitely want SOME sort of list syntax. The CLI currently allows repetitive specification of a key to create a list, although we may change the syntax to iothread.0=t1,iothread.1=t2,iothread.2=t3 to explicitly call out that we are passing a list. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
[Qemu-devel] [Bug 590552] Re: New default network card doesn't work with tap networking
Seems like you were using the QEMU from your Linux distribution (Debian). If you want to have support for that version, you should use the bug tracker from your distro instead. Otherwise, can you please try again with the latest version from http://wiki.qemu-project.org/Download to see whether the bug is already fixed there? Thanks! ** Changed in: qemu Status: New => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/590552 Title: New default network card doesn't work with tap networking Status in QEMU: Incomplete Bug description: Unfortunately, I can provide very little information. Hope this will be useful anyway. I've upgraded qemu using debian apt to lastest unstable (QEMU PC emulator version 0.12.4 (Debian 0.12.4+dfsg-2), Copyright (c) 2003-2008 Fabrice Bellard): looks like at some point the default network card for -net nic option was switched to intel gigabit instead of the good old ne2k_pci. I was using -net tap -net nic options and my network stopped working. When not working, - tcpdump on the host shows me taht all packets are sent and received fine from guest - tcpdump on guest shows that packets from host are NOT received obviously, both host tap interface and guest eth0 interfaces, routing tables, dns, firewall, etc... are well configured. Having banged my head for a while, I finally stopped the host and started it again using -net nic,model=ne2k_pci option, then my network magically started working again. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/590552/+subscriptions
[Qemu-devel] [Bug 612297] Re: qemu-kvm fails to detect mouse while Windows 95 setup
Seems like you were using the QEMU from your Linux distribution. If you want to have support for that version, you should use the bug tracker from your distro instead. Otherwise, can you please try again with the latest version from http://wiki.qemu-project.org/Download to see whether the bug is already fixed there? Thanks! ** Changed in: qemu Status: New => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/612297 Title: qemu-kvm fails to detect mouse while Windows 95 setup Status in QEMU: Incomplete Bug description: CPU: AMD Phenom II X4 945 KVM-Version: qemu-kvm-0.12.4+dfsg (Debian package) Kernel: linux-2.6.26.8-rt16 arch: x86_64 Guest: Windows 95 B I'm trying to install Windows 95 B on qemu-kvm with this options: kvm /var/mmn/vm/Win95/Win95.img -name "Windows 95" -M pc-0.12 -m 512M -rtc base=localtime -k de -soundhw sb16 -vga cirrus -net user,hostname=w95vm -net nic,model=ne2k_pci -boot a -fda /var/mmn/vm/floppy/win95B_Drive-D-boot.img -cdrom /var/mmn/vm/CD/win95-setup.iso -no-acpi -no-kvm -usb I've also tried some other option, but always the same: no ps/2 mouse detection. And usb mouse is not supported by Windows 95 B while setup process. This is only possible later by installing the extension usbsupp.exe after the system setup. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/612297/+subscriptions
