Re: [Qemu-devel] [PATCH] spapr: add splpar hcalls H_JOIN, H_PROD, H_CONFER

[no-reply]

Patchew URL: https://patchew.org/QEMU/20190412054214.707-1-npig...@gmail.com/



Hi,

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

Message-id: 20190412054214.707-1-npig...@gmail.com
Subject: [Qemu-devel] [PATCH] spapr: add splpar hcalls H_JOIN, H_PROD, H_CONFER
Type: series

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 t [tag update]
patchew/1554822037-329838-1-git-send-email-imamm...@redhat.com -> 
patchew/1554822037-329838-1-git-send-email-imamm...@redhat.com
 t [tag update]patchew/20190411161013.4514-1-...@kaod.org -> 
patchew/20190411161013.4514-1-...@kaod.org
 * [new tag]   patchew/20190412054214.707-1-npig...@gmail.com -> 
patchew/20190412054214.707-1-npig...@gmail.com
Switched to a new branch 'test'
2f73cb0a80 spapr: add splpar hcalls H_JOIN, H_PROD, H_CONFER

=== OUTPUT BEGIN ===
ERROR: braces {} are necessary for all arms of this statement
#28: FILE: hw/ppc/spapr_hcall.c:1074:
+if (env->msr & (1ULL << MSR_EE))
[...]

ERROR: braces {} are necessary for all arms of this statement
#53: FILE: hw/ppc/spapr_hcall.c:1099:
+if (target != -1 && !CPU(spapr_find_cpu(target)))
[...]

ERROR: braces {} are necessary for all arms of this statement
#61: FILE: hw/ppc/spapr_hcall.c:1107:
+if (cpu == spapr_find_cpu(target))
[...]

ERROR: braces {} are necessary for all arms of this statement
#93: FILE: hw/ppc/spapr_hcall.c:1139:
+if (!cs)
[...]

total: 4 errors, 0 warnings, 96 lines checked

Commit 2f73cb0a80a1 (spapr: add splpar hcalls H_JOIN, H_PROD, H_CONFER) has 
style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
=== OUTPUT END ===

Test command exited with code: 1


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

Re: [Qemu-devel] [RFC PATCH 3/3] hw/acpi: Extract build_mcfg

[Wei Yang]

On Tue, Apr 09, 2019 at 04:54:15PM +0200, Igor Mammedov wrote:
>> 
>> Let's see a normal hotplug case first. 
>> 
>> I did one test to see the how a guest with hot-plug cpu migrate to
>> destination.  It looks the migration fails if I just do hot-plug at
>> source. So I have to do hot-plug both at source and at destination. This
>> will expand the table_mr both at source and destination.
>> 
>> Then let's see the effect of hotplug more devices to exceed original padded
>> size. There are two cases, before re-sizable MemoryRegion and after.
>> 
>> 1) Before re-sizable MemoryRegion introduced
>> 
>> Before re-sizable MemoryRegion introduced, we just pad table_mr to 4K. 
>> And
>> this size never gets bigger, if I am right. To be accurate, the 
>> table_blob
>> would grow to next padded size if we hot-add more cpus/pci bridge, but we
>> just copy the original size of MemoryRegion. Even without migration, the
>> ACPI table is corrupted when we expand to next padded size.
>> 
>> Is my understanding correct here?
>> 
>> 2) After re-sizable MemoryRegion introduced
>> 
>> This time both tabl_blob and MemoryRegion grows when it expand to next
>> padded size. Since we need to hot-add device at both side, ACPI table
>> grows at the same pace.
>> 
>> Every thing looks good, until one of it exceed the resizable
>> MemoryRegion's max size. (Not sure this is possible in reality, while
>> possible in theory). Actually, this looks like case 1) when resizable
>> MemoryRegion is not introduced. The too big ACPI table get corrupted.
>> 
>> So if my understanding is correct, the procedure you mentioned "expand from
>> initial padded size to next padded size" only applies to two different max
>> size resizable MemoryRegion. For other cases, the procedure corrupt the ACPI
>> table itself.
>> 
>> Then when we look at
>> 
>> commit 07fb61760cdea7c3f1b9c897513986945bca8e89
>> Author: Paolo Bonzini 
>> Date:   Mon Jul 28 17:34:15 2014 +0200
>> 
>> pc: hack for migration compatibility from QEMU 2.0
>> 
>> This fix ACPI migration issue before resizable MemoryRegion is
>> introduced(introduced in 2015-01-08). This looks expand to next padded size
>> always corrupt ACPI table at that time. And it make me think expand to next
>> padded size is not the procedure we should do?
>> 
>> And my colleague Wei Wang(in cc) mentioned, to make migration succeed, the
>> MemoryRegion has to be the same size at both side. So I guess the problem
>> doesn't lie in hotplug but in "main table" size difference.
>
>It's true only for pre-resizable MemoryRegion QEMU versions,
>after that size doesn't affect migration anymore.
>
>
>> For example, we have two version of Qemu: v1 and v2. Their "main table" size
>> is:
>> 
>> v1: 3990
>> v2: 4020
>> 
>> At this point, their ACPI table all padded to 4k, which is the same.
>> 
>> Then we create a machine with 1 more vcpu by these two versions. This will
>> expand the table to:
>> 
>> v1: 4095
>> v2: 4125
>> 
>> After padding, v1's ACPI table size is still 4k but v2's is 8k. Now the
>> migration is broken.
>> 
>> If this analysis is correct, the relationship between migration failure and
>> ACPI table is "the change of ACPI table size". Any size change of any
>you should make distinction between used_length and max_length here.
>Migration puts on wire used_length and that's what matter for keeping migration
>working.
>
>> ACPI table would break migration. While of course, since we pad the table,
>> only some combinations of tables would result in a visible real size change 
>> in
>> MemoryRegion.
>> 
>> Then the principle for future ACPI development is to keep all ACPI table size
>> unchanged.
>once again it applies only for QEMU (versions < 2.1) and that was
>the problem (i.e. there always would be configurations that would create
>differently sized tables regardless of arbitrary size we would preallocate)
>resizable MemoryRegions solved.
> 
>> Now let's back to mcfg table. As the comment mentioned, guest could
>> enable/disable MCFG, so the code here reserve table no matter it is enabled 
>> or
>> not. This behavior ensures ACPI table size not changed. So do we need to find
>> the machine type as you suggested before?
>We should be able to drop mcgf 'padding' hack since machine version
>which was introduced in the QEMU version that introduced resizable MemoryRegion
>as well.
>
>I'll send a patch to address that

Hi, Igor,

We have found the qemu version 2.1 which is with resizable MemoryRegion
enabled and q35 will stop support version before 2.3. The concern about ACPI
mcfg table breaking live migration is solved, right?

If so, I would prepare mcfg refactor patch based on your cleanup.

-- 
Wei Yang
Help you, Help me

[Qemu-devel] [PATCH] spapr: add splpar hcalls H_JOIN, H_PROD, H_CONFER

[Nicholas Piggin]

These implementations have a few deficiencies that are noted, but are
good enough for Linux to use.

Signed-off-by: Nicholas Piggin 

---
This has been tested with TCG with some Linux hacks to use H_JOIN/H_PROD
for suspend and CPU unplug (plus an implementation of ibm,suspend-me to
do the suspend). Not sure if KVM might need some more work to support
H_JOIN properly, but right now Linux only uses it on PowerVM.


 hw/ppc/spapr_hcall.c | 84 
 1 file changed, 84 insertions(+)

diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
index 8a736797b9..6829cadcd3 100644
--- a/hw/ppc/spapr_hcall.c
+++ b/hw/ppc/spapr_hcall.c
@@ -1065,6 +1065,86 @@ static target_ulong h_cede(PowerPCCPU *cpu, 
SpaprMachineState *spapr,
 return H_SUCCESS;
 }
 
+static target_ulong h_join(PowerPCCPU *cpu, SpaprMachineState *spapr,
+   target_ulong opcode, target_ulong *args)
+{
+CPUPPCState *env = >env;
+CPUState *cs = CPU(cpu);
+
+if (env->msr & (1ULL << MSR_EE))
+return H_BAD_MODE;
+
+/*
+ * This should check for single-threaded mode. In practice, Linux
+ * does not try to H_JOIN all CPUs.
+ */
+
+cs->halted = 1;
+cs->exception_index = EXCP_HALTED;
+cs->exit_request = 1;
+
+return H_SUCCESS;
+}
+
+static target_ulong h_confer(PowerPCCPU *cpu, SpaprMachineState *spapr,
+   target_ulong opcode, target_ulong *args)
+{
+target_long target = args[0];
+CPUState *cs = CPU(cpu);
+
+/*
+ * This does not do a targeted yield or confer, but check the parameter
+ * anyway. -1 means confer to all/any other CPUs.
+ */
+if (target != -1 && !CPU(spapr_find_cpu(target)))
+return H_PARAMETER;
+
+/*
+ * H_CONFER with target == this is not exactly the same as H_JOIN
+ * according to PAPR (e.g., MSR[EE] check and single threaded check
+ * is not done in this case), but unlikely to matter.
+ */
+if (cpu == spapr_find_cpu(target))
+return h_join(cpu, spapr, opcode, args);
+
+/*
+ * This does not implement the dispatch sequence check that PAPR calls for,
+ * but PAPR also specifies a stronger implementation where the target must
+ * be run (or EE, or H_PROD) before H_CONFER returns. Without such a hard
+ * scheduling requirement implemented, there is no correctness reason to
+ * implement the dispatch sequence check.
+ */
+cs->exception_index = EXCP_YIELD;
+cpu_loop_exit(cs);
+
+return H_SUCCESS;
+}
+
+/*
+ * H_PROD and H_CONFER are specified to only modify GPR r3, which is not
+ * achievable running under KVM, although KVM already implements H_CONFER
+ * this way.
+ */
+static target_ulong h_prod(PowerPCCPU *cpu, SpaprMachineState *spapr,
+   target_ulong opcode, target_ulong *args)
+{
+target_long target = args[0];
+CPUState *cs;
+
+/*
+ * This does not maintain a prod flag for the vCPU that PAPR asks for.
+ */
+
+cs = CPU(spapr_find_cpu(target));
+if (!cs)
+return H_PARAMETER;
+
+cs->halted = 0;
+qemu_cpu_kick(cs);
+
+return H_SUCCESS;
+}
+
 static target_ulong h_rtas(PowerPCCPU *cpu, SpaprMachineState *spapr,
target_ulong opcode, target_ulong *args)
 {
@@ -1860,6 +1940,10 @@ static void hypercall_register_types(void)
 /* hcall-splpar */
 spapr_register_hypercall(H_REGISTER_VPA, h_register_vpa);
 spapr_register_hypercall(H_CEDE, h_cede);
+spapr_register_hypercall(H_CONFER, h_confer);
+spapr_register_hypercall(H_JOIN, h_join);
+spapr_register_hypercall(H_PROD, h_prod);
+
 spapr_register_hypercall(H_SIGNAL_SYS_RESET, h_signal_sys_reset);
 
 /* processor register resource access h-calls */
-- 
2.20.1

[Qemu-devel] [PATCH v2 1/2] hw: timer: Add ASPEED RTC device

[Joel Stanley]

Signed-off-by: Joel Stanley 
Signed-off-by: Cédric Le Goater 
---
v2:
 Use g_assert_not_reached
 Add vmstate
 Add reset callback
 Annotate fall through cases

 hw/timer/Makefile.objs|   2 +-
 hw/timer/aspeed_rtc.c | 180 ++
 hw/timer/trace-events |   4 +
 include/hw/timer/aspeed_rtc.h |  31 ++
 4 files changed, 216 insertions(+), 1 deletion(-)
 create mode 100644 hw/timer/aspeed_rtc.c
 create mode 100644 include/hw/timer/aspeed_rtc.h

diff --git a/hw/timer/Makefile.objs b/hw/timer/Makefile.objs
index 0e9a4530f848..123d92c9692c 100644
--- a/hw/timer/Makefile.objs
+++ b/hw/timer/Makefile.objs
@@ -41,7 +41,7 @@ obj-$(CONFIG_MC146818RTC) += mc146818rtc.o
 obj-$(CONFIG_ALLWINNER_A10_PIT) += allwinner-a10-pit.o
 
 common-obj-$(CONFIG_STM32F2XX_TIMER) += stm32f2xx_timer.o
-common-obj-$(CONFIG_ASPEED_SOC) += aspeed_timer.o
+common-obj-$(CONFIG_ASPEED_SOC) += aspeed_timer.o aspeed_rtc.o
 
 common-obj-$(CONFIG_SUN4V_RTC) += sun4v-rtc.o
 common-obj-$(CONFIG_CMSDK_APB_TIMER) += cmsdk-apb-timer.o
diff --git a/hw/timer/aspeed_rtc.c b/hw/timer/aspeed_rtc.c
new file mode 100644
index ..19f061c846e8
--- /dev/null
+++ b/hw/timer/aspeed_rtc.c
@@ -0,0 +1,180 @@
+/*
+ * ASPEED Real Time Clock
+ * Joel Stanley 
+ *
+ * Copyright 2019 IBM Corp
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+#include "hw/timer/aspeed_rtc.h"
+#include "qemu/log.h"
+#include "qemu/timer.h"
+
+#include "trace.h"
+
+#define COUNTER1(0x00 / 4)
+#define COUNTER2(0x04 / 4)
+#define ALARM   (0x08 / 4)
+#define CONTROL (0x10 / 4)
+#define ALARM_STATUS(0x14 / 4)
+
+#define RTC_UNLOCKEDBIT(1)
+#define RTC_ENABLED BIT(0)
+
+static void aspeed_rtc_calc_offset(AspeedRtcState *rtc)
+{
+struct tm tm;
+uint32_t year, cent;
+uint32_t reg1 = rtc->reg[COUNTER1];
+uint32_t reg2 = rtc->reg[COUNTER2];
+
+tm.tm_mday = (reg1 >> 24) & 0x1f;
+tm.tm_hour = (reg1 >> 16) & 0x1f;
+tm.tm_min = (reg1 >> 8) & 0x3f;
+tm.tm_sec = (reg1 >> 0) & 0x3f;
+
+cent = (reg2 >> 16) & 0x1f;
+year = (reg2 >> 8) & 0x7f;
+tm.tm_mon = ((reg2 >>  0) & 0x0f) - 1;
+tm.tm_year = year + (cent * 100) - 1900;
+
+rtc->offset = qemu_timedate_diff();
+}
+
+static uint32_t aspeed_rtc_get_counter(AspeedRtcState *rtc, int r)
+{
+uint32_t year, cent;
+struct tm now;
+
+qemu_get_timedate(, rtc->offset);
+
+switch (r) {
+case COUNTER1:
+return (now.tm_mday << 24) | (now.tm_hour << 16) |
+(now.tm_min << 8) | now.tm_sec;
+case COUNTER2:
+cent = (now.tm_year + 1900) / 100;
+year = now.tm_year % 100;
+return ((cent & 0x1f) << 16) | ((year & 0x7f) << 8) |
+((now.tm_mon + 1) & 0xf);
+default:
+g_assert_not_reached();
+}
+}
+
+static uint64_t aspeed_rtc_read(void *opaque, hwaddr addr,
+unsigned size)
+{
+AspeedRtcState *rtc = opaque;
+uint64_t val;
+uint32_t r = addr >> 2;
+
+switch (r) {
+case COUNTER1:
+case COUNTER2:
+if (rtc->reg[CONTROL] & RTC_ENABLED) {
+rtc->reg[r] = aspeed_rtc_get_counter(rtc, r);
+}
+/* fall through */
+case CONTROL:
+val = rtc->reg[r];
+break;
+case ALARM:
+case ALARM_STATUS:
+default:
+qemu_log_mask(LOG_UNIMP, "%s: 0x%" HWADDR_PRIx "\n", __func__, addr);
+return 0;
+}
+
+trace_aspeed_rtc_read(addr, val);
+
+return val;
+}
+
+static void aspeed_rtc_write(void *opaque, hwaddr addr,
+ uint64_t val, unsigned size)
+{
+AspeedRtcState *rtc = opaque;
+uint32_t r = addr >> 2;
+
+switch (r) {
+case COUNTER1:
+case COUNTER2:
+if (!(rtc->reg[CONTROL] & RTC_UNLOCKED)) {
+break;
+}
+/* fall through */
+case CONTROL:
+rtc->reg[r] = val;
+aspeed_rtc_calc_offset(rtc);
+break;
+case ALARM:
+case ALARM_STATUS:
+default:
+qemu_log_mask(LOG_UNIMP, "%s: 0x%" HWADDR_PRIx "\n", __func__, addr);
+break;
+}
+trace_aspeed_rtc_write(addr, val);
+}
+
+static void aspeed_rtc_reset(DeviceState *d)
+{
+AspeedRtcState *rtc = ASPEED_RTC(d);
+
+rtc->offset = 0;
+memset(rtc->reg, 0, sizeof(rtc->reg));
+}
+
+static const MemoryRegionOps aspeed_rtc_ops = {
+.read = aspeed_rtc_read,
+.write = aspeed_rtc_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
+};
+
+static const VMStateDescription vmstate_aspeed_rtc = {
+.name = TYPE_ASPEED_RTC,
+.version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UINT32_ARRAY(reg, AspeedRtcState, 0x18),
+VMSTATE_INT32(offset, AspeedRtcState),
+VMSTATE_INT32(offset, AspeedRtcState),
+VMSTATE_END_OF_LIST()
+}
+};
+
+static void aspeed_rtc_realize(DeviceState *dev, Error **errp)
+{
+SysBusDevice *sbd = SYS_BUS_DEVICE(dev);

Re: [Qemu-devel] [PATCH 2/3] aspeed: add a per SoC mapping for the memory space

[Cédric Le Goater]

On 4/12/19 5:24 AM, Andrew Jeffery wrote:
> 
> 
> On Fri, 12 Apr 2019, at 11:48, Joel Stanley wrote:
>> On Thu, 11 Apr 2019 at 16:10, Cédric Le Goater  wrote:
>>>
>>> This will simplify the definition of new SoCs, like the AST2600 which
>>> should use a slightly different address space and have a different set
>>> of controllers.
>>>
>>> Signed-off-by: Cédric Le Goater 
>>
>>> diff --git a/hw/arm/aspeed_soc.c b/hw/arm/aspeed_soc.c
>>> index 5bbd1fb87d18..9b601709e93c 100644
>>> --- a/hw/arm/aspeed_soc.c
>>> +++ b/hw/arm/aspeed_soc.c
>>
>>> +static const hwaddr aspeed_soc_ast2400_memmap[] = {
>>
>>> +static const hwaddr aspeed_soc_ast2500_memmap[] = {
>>
>> Most of these arrays is common. And some of it will stay common in the
>> 2600. Any ideas how we could avoid duplication?
> 
> I dunno, I feel that any attempt to create some "common" layout concept is
> more distracting than having soc-specific, complete layouts described.

yes. I rather duplicate some values and see in one glance the full 
address space.

Thanks,

C.
  
> 
> There's no reason why they're common beyond coincidence (i.e. it's at
> ASPEED's whim). I think this is fine.
> 
> Reviewed-by: Andrew Jeffery 
> 
>>
>> This is fine for now.
>>
>> Reviewed-by: Joel Stanley 
>>

Re: [Qemu-devel] [PATCH] ppc/spapr: Add H_PROD and H_CONFER

[Cédric Le Goater]

On 4/12/19 5:28 AM, Nicholas Piggin wrote:
> Cédric Le Goater's on April 11, 2019 4:34 pm:
>> From: Benjamin Herrenschmidt 
>>
>> H_PROD should be fully functional, H_CEDE is modified to
>> ignore a proded CPU. H_CONFER is a stub to avoid returning
>> an error.
> 
> Huh, I just implemented these a couple of days ago to test pseries
> suspend, also H_JOIN.

Cool. Can you send your version instead ?

Thanks,

C.

> 
> ---
>  hw/ppc/spapr_hcall.c | 79 
>  1 file changed, 79 insertions(+)
> 
> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
> index 8a736797b9..47ee93 100644
> --- a/hw/ppc/spapr_hcall.c
> +++ b/hw/ppc/spapr_hcall.c
> @@ -1065,6 +1065,81 @@ static target_ulong h_cede(PowerPCCPU *cpu, 
> SpaprMachineState *spapr,
>  return H_SUCCESS;
>  }
>  
> +static target_ulong h_join(PowerPCCPU *cpu, SpaprMachineState *spapr,
> +   target_ulong opcode, target_ulong *args)
> +{
> +CPUPPCState *env = >env;
> +CPUState *cs = CPU(cpu);
> +
> +if (env->msr & (1ULL << MSR_EE))
> +return H_BAD_MODE;
> +
> +/*
> + * This should check for single-threaded mode. In practice, Linux
> + * does not try to H_JOIN all CPUs.
> + */
> +
> +cs->halted = 1;
> +cs->exception_index = EXCP_HALTED;
> +cs->exit_request = 1;
> +
> +return H_SUCCESS;
> +}
> +
> +static target_ulong h_confer(PowerPCCPU *cpu, SpaprMachineState *spapr,
> +   target_ulong opcode, target_ulong *args)
> +{
> +target_long target = args[0];
> +CPUState *cs = CPU(cpu);
> +
> +/*
> + * This does not do a targeted yield, but check the parameter anyway.
> + */
> +if (target != -1 && !CPU(spapr_find_cpu(target)))
> +return H_PARAMETER;
> +
> +/*
> + * H_CONFER with target == this is not exactly the same as H_JOIN
> + * according to PAPR (e.g., MSR[EE] check and single threaded check
> + * is not done in this case), but unlikely to matter.
> + */
> +if (cpu == spapr_find_cpu(target))
> +return h_join(cpu, spapr, opcode, args);
> +
> +/*
> + * This does not implement the dispatch sequence check.
> + */
> +cs->exception_index = EXCP_YIELD;
> +cpu_loop_exit(cs);
> +
> +return H_SUCCESS;
> +}
> +
> +/*
> + * H_PROD and H_CONFER are specified to only modify GPR r3, which is not
> + * achievable running under KVM, although KVM already implements H_CONFER
> + * this way.
> + */
> +static target_ulong h_prod(PowerPCCPU *cpu, SpaprMachineState *spapr,
> +   target_ulong opcode, target_ulong *args)
> +{
> +target_long target = args[0];
> +CPUState *cs;
> +
> +/*
> + * Should set the prod flag in the VPA.
> + */
> +
> +cs = CPU(spapr_find_cpu(target));
> +if (!cs)
> +return H_PARAMETER;
> +
> +cs->halted = 0;
> +qemu_cpu_kick(cs);
> +
> +return H_SUCCESS;
> +}
> +
>  static target_ulong h_rtas(PowerPCCPU *cpu, SpaprMachineState *spapr,
> target_ulong opcode, target_ulong *args)
>  {
> @@ -1860,6 +1935,10 @@ static void hypercall_register_types(void)
>  /* hcall-splpar */
>  spapr_register_hypercall(H_REGISTER_VPA, h_register_vpa);
>  spapr_register_hypercall(H_CEDE, h_cede);
> +spapr_register_hypercall(H_CONFER, h_confer);
> +spapr_register_hypercall(H_JOIN, h_join);
> +spapr_register_hypercall(H_PROD, h_prod);
> +
>  spapr_register_hypercall(H_SIGNAL_SYS_RESET, h_signal_sys_reset);
>  
>  /* processor register resource access h-calls */
> 

[Qemu-devel] [PATCH v2 0/2] arm: aspeed: Add RTC Model

[Joel Stanley]

v2: Minor fixes, added vmstate and reset, and rebased on Cédric's series

Based-on: 20190411161013.4514-4-...@kaod.org
[PATCH 3/3] aspeed: use sysbus_init_child_obj() to initialize children

A model for the ASPEED BMC real time clock (RTC). The model is sufficient
for running the guest Linux kernel driver, and ticks in time with the
host when programmed.

It does not implement the alarm functionality, which includes the
interrupt.

Joel Stanley (2):
  hw: timer: Add ASPEED RTC device
  hw/arm/aspeed: Add RTC to SoC

 hw/arm/aspeed_soc.c   |  13 +++
 hw/timer/Makefile.objs|   2 +-
 hw/timer/aspeed_rtc.c | 180 ++
 hw/timer/trace-events |   4 +
 include/hw/arm/aspeed_soc.h   |   2 +
 include/hw/timer/aspeed_rtc.h |  31 ++
 6 files changed, 231 insertions(+), 1 deletion(-)
 create mode 100644 hw/timer/aspeed_rtc.c
 create mode 100644 include/hw/timer/aspeed_rtc.h

-- 
2.20.1

Re: [Qemu-devel] [Qemu-trivial] [PATCH 0/4] Header cleanups

[Aruna Jayasena]

Thanks!

On Fri, Apr 12, 2019 at 1:50 AM, Laurent Vivier  wrote:

> On 10/04/2019 07:17, Markus Armbruster wrote:
> > Peter Maydell  writes:
> >
> >> On Tue, 9 Apr 2019 at 17:42, Aruna Jayasena 
> wrote:
> >>>
> >>> Yeah this is a stand alone patch.
> >>
> >> OK, thanks -- just wanted to check there wasn't a missing
> >> bit. I think this could go in via the qemu-trivial tree
> >> so I have cc'd them.
> >>
> >> We're in the middle of a release at the moment, but we
> >> should reopen for development in a couple of weeks. If
> >> this patch still hasn't gone anywhere by a week or so after
> >> that then please follow up with a 'ping' to check it hasn't
> >> been forgotten by accident.
> >
> > Hopefully, qemu-trivial won't wait for the next development cycle to
> > begin just to queue patches for it.
> >
> > Regardless, patch submitters should watch their patches and inquire when
> > they don't get up within a reasonable time frame.  Normally, waiting for
> > two weeks feels about right.  Perhaps give it an extra week or so when
> > the release circus is in town (like now).
> >
>
> Applied to my trivial-patches branch.
>
> Thanks,
> Laurent
>
-- 
*Aruna* Jayasena
Embedded Systems and Computer Science Engineering Undergraduate
University of Moratuwa
*✆ **+94719872152 *
✉  ⌨  in

Re: [Qemu-devel] [PATCH] ppc/spapr: Add H_PROD and H_CONFER

[Nicholas Piggin]

Cédric Le Goater's on April 11, 2019 4:34 pm:
> From: Benjamin Herrenschmidt 
> 
> H_PROD should be fully functional, H_CEDE is modified to
> ignore a proded CPU. H_CONFER is a stub to avoid returning
> an error.

Huh, I just implemented these a couple of days ago to test pseries
suspend, also H_JOIN.

---
 hw/ppc/spapr_hcall.c | 79 
 1 file changed, 79 insertions(+)

diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
index 8a736797b9..47ee93 100644
--- a/hw/ppc/spapr_hcall.c
+++ b/hw/ppc/spapr_hcall.c
@@ -1065,6 +1065,81 @@ static target_ulong h_cede(PowerPCCPU *cpu, 
SpaprMachineState *spapr,
 return H_SUCCESS;
 }
 
+static target_ulong h_join(PowerPCCPU *cpu, SpaprMachineState *spapr,
+   target_ulong opcode, target_ulong *args)
+{
+CPUPPCState *env = >env;
+CPUState *cs = CPU(cpu);
+
+if (env->msr & (1ULL << MSR_EE))
+return H_BAD_MODE;
+
+/*
+ * This should check for single-threaded mode. In practice, Linux
+ * does not try to H_JOIN all CPUs.
+ */
+
+cs->halted = 1;
+cs->exception_index = EXCP_HALTED;
+cs->exit_request = 1;
+
+return H_SUCCESS;
+}
+
+static target_ulong h_confer(PowerPCCPU *cpu, SpaprMachineState *spapr,
+   target_ulong opcode, target_ulong *args)
+{
+target_long target = args[0];
+CPUState *cs = CPU(cpu);
+
+/*
+ * This does not do a targeted yield, but check the parameter anyway.
+ */
+if (target != -1 && !CPU(spapr_find_cpu(target)))
+return H_PARAMETER;
+
+/*
+ * H_CONFER with target == this is not exactly the same as H_JOIN
+ * according to PAPR (e.g., MSR[EE] check and single threaded check
+ * is not done in this case), but unlikely to matter.
+ */
+if (cpu == spapr_find_cpu(target))
+return h_join(cpu, spapr, opcode, args);
+
+/*
+ * This does not implement the dispatch sequence check.
+ */
+cs->exception_index = EXCP_YIELD;
+cpu_loop_exit(cs);
+
+return H_SUCCESS;
+}
+
+/*
+ * H_PROD and H_CONFER are specified to only modify GPR r3, which is not
+ * achievable running under KVM, although KVM already implements H_CONFER
+ * this way.
+ */
+static target_ulong h_prod(PowerPCCPU *cpu, SpaprMachineState *spapr,
+   target_ulong opcode, target_ulong *args)
+{
+target_long target = args[0];
+CPUState *cs;
+
+/*
+ * Should set the prod flag in the VPA.
+ */
+
+cs = CPU(spapr_find_cpu(target));
+if (!cs)
+return H_PARAMETER;
+
+cs->halted = 0;
+qemu_cpu_kick(cs);
+
+return H_SUCCESS;
+}
+
 static target_ulong h_rtas(PowerPCCPU *cpu, SpaprMachineState *spapr,
target_ulong opcode, target_ulong *args)
 {
@@ -1860,6 +1935,10 @@ static void hypercall_register_types(void)
 /* hcall-splpar */
 spapr_register_hypercall(H_REGISTER_VPA, h_register_vpa);
 spapr_register_hypercall(H_CEDE, h_cede);
+spapr_register_hypercall(H_CONFER, h_confer);
+spapr_register_hypercall(H_JOIN, h_join);
+spapr_register_hypercall(H_PROD, h_prod);
+
 spapr_register_hypercall(H_SIGNAL_SYS_RESET, h_signal_sys_reset);
 
 /* processor register resource access h-calls */
-- 
2.20.1

Re: [Qemu-devel] [PATCH 2/3] aspeed: add a per SoC mapping for the memory space

[Andrew Jeffery]

On Fri, 12 Apr 2019, at 11:48, Joel Stanley wrote:
> On Thu, 11 Apr 2019 at 16:10, Cédric Le Goater  wrote:
> >
> > This will simplify the definition of new SoCs, like the AST2600 which
> > should use a slightly different address space and have a different set
> > of controllers.
> >
> > Signed-off-by: Cédric Le Goater 
> 
> > diff --git a/hw/arm/aspeed_soc.c b/hw/arm/aspeed_soc.c
> > index 5bbd1fb87d18..9b601709e93c 100644
> > --- a/hw/arm/aspeed_soc.c
> > +++ b/hw/arm/aspeed_soc.c
> 
> > +static const hwaddr aspeed_soc_ast2400_memmap[] = {
> 
> > +static const hwaddr aspeed_soc_ast2500_memmap[] = {
> 
> Most of these arrays is common. And some of it will stay common in the
> 2600. Any ideas how we could avoid duplication?

I dunno, I feel that any attempt to create some "common" layout concept is
more distracting than having soc-specific, complete layouts described.

There's no reason why they're common beyond coincidence (i.e. it's at
ASPEED's whim). I think this is fine.

Reviewed-by: Andrew Jeffery 

> 
> This is fine for now.
> 
> Reviewed-by: Joel Stanley 
>

Re: [Qemu-devel] [PATCH 1/2] hw: timer: Add ASPEED RTC device

[Joel Stanley]

Thanks for the review Peter and Cedric.

On Thu, 11 Apr 2019 at 15:30, Cédric Le Goater  wrote:
>
> On 4/11/19 5:25 PM, Peter Maydell wrote:
> >> +
> >> +#define COUNTER1(0x00 / 4)
> >> +#define COUNTER2(0x04 / 4)
> >> +#define ALARM   (0x08 / 4)
> >> +#define CONTROL (0x10 / 4)
> >> +#define ALARM_STATUS(0x14 / 4)
> >
> > Not mandatory, but you might like the REG32() macro in
> > hw/registerfields.h which defines A_FOO and R_FOO
> > constants for you for the addresses and the indexes.
>
> Yes. May be we should start using these macros in all our models.

I don't like them as you can no longer jump between the definition and
the use of the defines.

>
> >
> >> +
> >> +#define RTC_UNLOCKEDBIT(1)
> >> +#define RTC_ENABLED BIT(0)
> >> +
> >> +static void aspeed_rtc_calc_offset(AspeedRtcState *rtc)
> >> +{
> >> +struct tm tm;
> >> +uint32_t year, cent;
> >> +uint32_t reg1 = rtc->reg[COUNTER1];
> >> +uint32_t reg2 = rtc->reg[COUNTER2];
> >> +
> >> +tm.tm_mday = (reg1 >> 24) & 0x1f;
> >> +tm.tm_hour = (reg1 >> 16) & 0x1f;
> >> +tm.tm_min = (reg1 >> 8) & 0x3f;
> >> +tm.tm_sec = (reg1 >> 0) & 0x3f;
> >
> > Shift by zero ?
> >
> > Consider using extract32() rather than by-hand shift and mask.

I looked at these and found them more confusing than writing what was
actually happening.

This code came from the Linux kernel driver, which I wrote, so I know
it's correct. The shift by zero is there to follow the pattern of the
code proceeding it, again to stop mistakes.

If we require using these helper macros then I can make the change. If
it's optional then I would prefer to leave it as is.

>
> What about the FIELD*() macros in hw/registerfields.h ?
>

> >> +static void aspeed_rtc_class_init(ObjectClass *klass, void *data)
> >> +{
> >> +DeviceClass *dc = DEVICE_CLASS(klass);
> >> +
> >> +dc->realize = aspeed_rtc_realize;
> >
> > This is missing a reset function and vmstate.

Ok, I can add those.

vmstate and migration is a foreign concept for the small ARM machines.
As well as being a developer, I am an end user of Qemu for them (the
aspeeds, microbit), and the use case is to boot up a firmware and
check that it does correct thing. I've never considered saving the
state and resming it, and can't think of a situation where that would
be done.

If we're adding it for consistency then I understand. I don't think it
sees any testing though.

Cheers,

Joel

Re: [Qemu-devel] [PATCH 3/3] aspeed: use sysbus_init_child_obj() to initialize children

[Andrew Jeffery]

On Fri, 12 Apr 2019, at 01:40, Cédric Le Goater wrote:
> Signed-off-by: Cédric Le Goater 

Reviewed-by: Andrew Jeffery 

> ---
>  hw/arm/aspeed_soc.c | 50 ++---
>  1 file changed, 20 insertions(+), 30 deletions(-)
> 
> diff --git a/hw/arm/aspeed_soc.c b/hw/arm/aspeed_soc.c
> index 9b601709e93c..110956828c44 100644
> --- a/hw/arm/aspeed_soc.c
> +++ b/hw/arm/aspeed_soc.c
> @@ -212,12 +212,11 @@ static void aspeed_soc_init(Object *obj)
>  AspeedSoCClass *sc = ASPEED_SOC_GET_CLASS(s);
>  int i;
>  
> -object_initialize(>cpu, sizeof(s->cpu), sc->info->cpu_type);
> -object_property_add_child(obj, "cpu", OBJECT(>cpu), NULL);
> +object_initialize_child(obj, "cpu", OBJECT(>cpu), sizeof(s->cpu),
> +sc->info->cpu_type, _abort, NULL);
>  
> -object_initialize(>scu, sizeof(s->scu), TYPE_ASPEED_SCU);
> -object_property_add_child(obj, "scu", OBJECT(>scu), NULL);
> -qdev_set_parent_bus(DEVICE(>scu), sysbus_get_default());
> +sysbus_init_child_obj(obj, "scu", OBJECT(>scu), sizeof(s->scu),
> +  TYPE_ASPEED_SCU);
>  qdev_prop_set_uint32(DEVICE(>scu), "silicon-rev",
>   sc->info->silicon_rev);
>  object_property_add_alias(obj, "hw-strap1", OBJECT(>scu),
> @@ -227,36 +226,29 @@ static void aspeed_soc_init(Object *obj)
>  object_property_add_alias(obj, "hw-prot-key", OBJECT(>scu),
>"hw-prot-key", _abort);
>  
> -object_initialize(>vic, sizeof(s->vic), TYPE_ASPEED_VIC);
> -object_property_add_child(obj, "vic", OBJECT(>vic), NULL);
> -qdev_set_parent_bus(DEVICE(>vic), sysbus_get_default());
> +sysbus_init_child_obj(obj, "vic", OBJECT(>vic), sizeof(s->vic),
> +  TYPE_ASPEED_VIC);
>  
> -object_initialize(>timerctrl, sizeof(s->timerctrl), 
> TYPE_ASPEED_TIMER);
> -object_property_add_child(obj, "timerctrl", OBJECT(>timerctrl), NULL);
> +sysbus_init_child_obj(obj, "timerctrl", OBJECT(>timerctrl),
> +  sizeof(s->timerctrl), TYPE_ASPEED_TIMER);
>  object_property_add_const_link(OBJECT(>timerctrl), "scu",
> OBJECT(>scu), _abort);
> -qdev_set_parent_bus(DEVICE(>timerctrl), sysbus_get_default());
>  
> -object_initialize(>i2c, sizeof(s->i2c), TYPE_ASPEED_I2C);
> -object_property_add_child(obj, "i2c", OBJECT(>i2c), NULL);
> -qdev_set_parent_bus(DEVICE(>i2c), sysbus_get_default());
> +sysbus_init_child_obj(obj, "i2c", OBJECT(>i2c), sizeof(s->i2c),
> +  TYPE_ASPEED_I2C);
>  
> -object_initialize(>fmc, sizeof(s->fmc), sc->info->fmc_typename);
> -object_property_add_child(obj, "fmc", OBJECT(>fmc), NULL);
> -qdev_set_parent_bus(DEVICE(>fmc), sysbus_get_default());
> +sysbus_init_child_obj(obj, "fmc", OBJECT(>fmc), sizeof(s->fmc),
> +  sc->info->fmc_typename);
>  object_property_add_alias(obj, "num-cs", OBJECT(>fmc), "num-cs",
>_abort);
>  
>  for (i = 0; i < sc->info->spis_num; i++) {
> -object_initialize(>spi[i], sizeof(s->spi[i]),
> -  sc->info->spi_typename[i]);
> -object_property_add_child(obj, "spi[*]", OBJECT(>spi[i]), NULL);
> -qdev_set_parent_bus(DEVICE(>spi[i]), sysbus_get_default());
> +sysbus_init_child_obj(obj, "spi[*]", OBJECT(>spi[i]),
> +  sizeof(s->spi[i]), sc->info->spi_typename[i]);
>  }
>  
> -object_initialize(>sdmc, sizeof(s->sdmc), TYPE_ASPEED_SDMC);
> -object_property_add_child(obj, "sdmc", OBJECT(>sdmc), NULL);
> -qdev_set_parent_bus(DEVICE(>sdmc), sysbus_get_default());
> +sysbus_init_child_obj(obj, "sdmc", OBJECT(>sdmc), sizeof(s->sdmc),
> +  TYPE_ASPEED_SDMC);
>  qdev_prop_set_uint32(DEVICE(>sdmc), "silicon-rev",
>   sc->info->silicon_rev);
>  object_property_add_alias(obj, "ram-size", OBJECT(>sdmc),
> @@ -265,16 +257,14 @@ static void aspeed_soc_init(Object *obj)
>"max-ram-size", _abort);
>  
>  for (i = 0; i < sc->info->wdts_num; i++) {
> -object_initialize(>wdt[i], sizeof(s->wdt[i]), TYPE_ASPEED_WDT);
> -object_property_add_child(obj, "wdt[*]", OBJECT(>wdt[i]), NULL);
> -qdev_set_parent_bus(DEVICE(>wdt[i]), sysbus_get_default());
> +sysbus_init_child_obj(obj, "wdt[*]", OBJECT(>wdt[i]),
> +  sizeof(s->wdt[i]), TYPE_ASPEED_WDT);
>  qdev_prop_set_uint32(DEVICE(>wdt[i]), "silicon-rev",
>  sc->info->silicon_rev);
>  }
>  
> -object_initialize(>ftgmac100, sizeof(s->ftgmac100), TYPE_FTGMAC100);
> -object_property_add_child(obj, "ftgmac100", OBJECT(>ftgmac100), NULL);
> -qdev_set_parent_bus(DEVICE(>ftgmac100), sysbus_get_default());
> +sysbus_init_child_obj(obj, "ftgmac100", 

Re: [Qemu-devel] [PATCH 1/3] aspeed: add a per SoC mapping for the interrupt space

[Andrew Jeffery]

On Fri, 12 Apr 2019, at 02:13, Philippe Mathieu-Daudé wrote:
> Hi Cédric,
> 
> On 4/11/19 6:10 PM, Cédric Le Goater wrote:
> > This will simplify the definition of new SoCs, like the AST2600 which
> > should use a different CPU and a different IRQ number layout.
> > 
> > Signed-off-by: Cédric Le Goater 
> > ---
> >  include/hw/arm/aspeed_soc.h |  1 +
> >  hw/arm/aspeed_soc.c | 93 +
> >  2 files changed, 86 insertions(+), 8 deletions(-)
> > 
> > diff --git a/include/hw/arm/aspeed_soc.h b/include/hw/arm/aspeed_soc.h
> > index 11ec0179db50..b0d266434288 100644
> > --- a/include/hw/arm/aspeed_soc.h
> > +++ b/include/hw/arm/aspeed_soc.h
> > @@ -57,6 +57,7 @@ typedef struct AspeedSoCInfo {
> >  const char *fmc_typename;
> >  const char **spi_typename;
> >  int wdts_num;
> > +const int *irqmap;
> >  } AspeedSoCInfo;
> >  
> >  typedef struct AspeedSoCClass {
> > diff --git a/hw/arm/aspeed_soc.c b/hw/arm/aspeed_soc.c
> > index a27233d4876b..5bbd1fb87d18 100644
> > --- a/hw/arm/aspeed_soc.c
> > +++ b/hw/arm/aspeed_soc.c
> > @@ -22,6 +22,42 @@
> >  #include "hw/i2c/aspeed_i2c.h"
> >  #include "net/net.h"
> >  
> > +enum {
> > +ASPEED_IOMEM,
> > +ASPEED_UART1,
> > +ASPEED_UART2,
> > +ASPEED_UART3,
> > +ASPEED_UART4,
> > +ASPEED_UART5,
> > +ASPEED_VUART,
> > +ASPEED_FMC,
> > +ASPEED_SPI1,
> > +ASPEED_SPI2,
> > +ASPEED_VIC,
> > +ASPEED_SDMC,
> > +ASPEED_SCU,
> > +ASPEED_ADC,
> > +ASPEED_SRAM,
> > +ASPEED_GPIO,
> > +ASPEED_RTC,
> > +ASPEED_TIMER1,
> > +ASPEED_TIMER2,
> > +ASPEED_TIMER3,
> > +ASPEED_TIMER4,
> > +ASPEED_TIMER5,
> > +ASPEED_TIMER6,
> > +ASPEED_TIMER7,
> > +ASPEED_TIMER8,
> 
> You use an enum to define const values. It is recommended to also define
> the value, to avoid problems if someone add/remove a value in the list
> (unlikely, but we never know... imagine someone wants to try this SoC
> with 9 timers and add ASPEED_TIMER9) ;)

The enum's not used outside of aspeed_soc.c though, so it should all be
self-consistent? Adding ASPEED_TIMER9 would just adjust the designated
initialiser index values in aspeed_soc_ast2400_irqmap declaration below.
Am I missing something?

Specifying enum values seems tedious in this case.

Andrew

> 
> > +ASPEED_WDT,
> > +ASPEED_PWM,
> > +ASPEED_LPC,
> > +ASPEED_IBT,
> > +ASPEED_I2C,
> > +ASPEED_ETH1,
> > +ASPEED_ETH2,
> > +ASPEED_SDRAM,
> > +};
> > +
> >  #define ASPEED_SOC_UART_5_BASE  0x00184000
> >  #define ASPEED_SOC_IOMEM_SIZE   0x0020
> >  #define ASPEED_SOC_IOMEM_BASE   0x1E60
> > @@ -38,12 +74,42 @@
> >  #define ASPEED_SOC_ETH1_BASE0x1E66
> >  #define ASPEED_SOC_ETH2_BASE0x1E68
> >  
> > -static const int uart_irqs[] = { 9, 32, 33, 34, 10 };
> > -static const int timer_irqs[] = { 16, 17, 18, 35, 36, 37, 38, 39, };
> > +static const int aspeed_soc_ast2400_irqmap[] = {
> > +[ASPEED_UART1]  = 9,
> > +[ASPEED_UART2]  = 32,
> > +[ASPEED_UART3]  = 33,
> > +[ASPEED_UART4]  = 34,
> > +[ASPEED_UART5]  = 10,
> > +[ASPEED_VUART]  = 8,
> > +[ASPEED_FMC]= 19,
> > +[ASPEED_SDMC]   = 0,
> > +[ASPEED_SCU]= 21,
> > +[ASPEED_ADC]= 31,
> > +[ASPEED_GPIO]   = 20,
> > +[ASPEED_RTC]= 22,
> > +[ASPEED_TIMER1] = 16,
> > +[ASPEED_TIMER2] = 17,
> > +[ASPEED_TIMER3] = 18,
> > +[ASPEED_TIMER4] = 35,
> > +[ASPEED_TIMER5] = 36,
> > +[ASPEED_TIMER6] = 37,
> > +[ASPEED_TIMER7] = 38,
> > +[ASPEED_TIMER8] = 39,
> > +[ASPEED_WDT]= 27,
> > +[ASPEED_PWM]= 28,
> > +[ASPEED_LPC]= 8,
> > +[ASPEED_IBT]= 8, /* LPC */
> > +[ASPEED_I2C]= 12,
> > +[ASPEED_ETH1]   = 2,
> > +[ASPEED_ETH2]   = 3,
> > +};
> >  
> >  #define AST2400_SDRAM_BASE   0x4000
> >  #define AST2500_SDRAM_BASE   0x8000
> >  
> > +/* AST2500 uses the same IRQs as the AST2400 */
> > +#define aspeed_soc_ast2500_irqmap aspeed_soc_ast2400_irqmap
> > +
> >  static const hwaddr aspeed_soc_ast2400_spi_bases[] = { ASPEED_SOC_SPI_BASE 
> > };
> >  static const char *aspeed_soc_ast2400_typenames[] = { "aspeed.smc.spi" };
> >  
> > @@ -64,6 +130,7 @@ static const AspeedSoCInfo aspeed_socs[] = {
> >  .fmc_typename = "aspeed.smc.fmc",
> >  .spi_typename = aspeed_soc_ast2400_typenames,
> >  .wdts_num = 2,
> > +.irqmap   = aspeed_soc_ast2400_irqmap,
> >  }, {
> >  .name = "ast2400-a1",
> >  .cpu_type = ARM_CPU_TYPE_NAME("arm926"),
> > @@ -75,6 +142,7 @@ static const AspeedSoCInfo aspeed_socs[] = {
> >  .fmc_typename = "aspeed.smc.fmc",
> >  .spi_typename = aspeed_soc_ast2400_typenames,
> >  .wdts_num = 2,
> > +.irqmap   = aspeed_soc_ast2400_irqmap,
> >  }, {
> >  .name = "ast2400",
> >  .cpu_type = 

Re: [Qemu-devel] [PATCH for-4.0] spapr_pci: Fix broken naming of PCI bus

[David Gibson]

On Thu, Apr 11, 2019 at 06:32:24PM +0200, Greg Kurz wrote:
> Recent commit 5cf0d326a0fe fixed a regression which was preventing the
> guest to access the extended config space of a PCIe device. This was
> done by introducing a new PCI bus subtype for PAPR. The original fix
> was causing PCI busses to be named "spapr-pci-host-bridge-root-bus.N"
> instead of "pci.N", which was making upper layers unhappy of course.
> This got worked around by hardcoding the PCI bus name to "pci.0", but
> this only works for the default PHB. And we're now hitting:
> 
> # qemu-system-ppc64 \
>  -device spapr-pci-host-bridge,index=1 \
>  -device e1000e,bus=pci.0 \
>  -device e1000e,bus=pci.1
> qemu-system-ppc64: -device e1000e,bus=pci.1: Bus 'pci.1' not found
> 
> David already posted some patches [1] to control PCI extended config
> space accesses with a new flag in the base PCI bus class instead of
> subtyping. These patches are a bit more intrusive though, and
> are targetted for 4.1.
> 
> When no name is passed to pci_register_bus(), the core device code
> generates a lowercase name based on the QOM typename. The typename
> for the base PCI bus class is "PCI", hence the "pci.0", "pci.1"
> bus names. Rename the type of the PAPR PCI bus to "pci", so that
> the QOM code can generate proper names. This is a hack but it is
> enough to fix the regression. And all this will be reworked properly
> in 4.1.
> 
> [1] https://patchwork.ozlabs.org/project/qemu-devel/list/?series=100486
> 
> Fixes: 5cf0d326a0fe
> Signed-off-by: Greg Kurz 

Oof.  That's a hack-and-a-half.  But, I don't see a better way of
fixing this quickly, and as you say, I already have clean ups for this
ready to go for 4.1.  Applied to ppc-for-4.0, and I'll try to rush out
a pull request today.

> ---
>  hw/ppc/spapr_pci.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
> index f0b6b23afc9b..f62e6833b8c9 100644
> --- a/hw/ppc/spapr_pci.c
> +++ b/hw/ppc/spapr_pci.c
> @@ -1652,7 +1652,7 @@ static void spapr_phb_root_bus_class_init(ObjectClass 
> *klass, void *data)
>  pbc->allows_extended_config_space = 
> spapr_phb_allows_extended_config_space;
>  }
>  
> -#define TYPE_SPAPR_PHB_ROOT_BUS "spapr-pci-host-bridge-root-bus"
> +#define TYPE_SPAPR_PHB_ROOT_BUS "pci"
>  
>  static const TypeInfo spapr_phb_root_bus_info = {
>  .name = TYPE_SPAPR_PHB_ROOT_BUS,
> @@ -1761,7 +1761,7 @@ static void spapr_phb_realize(DeviceState *dev, Error 
> **errp)
>  memory_region_add_subregion(get_system_memory(), sphb->io_win_addr,
>  >iowindow);
>  
> -bus = pci_register_root_bus(dev, "pci.0",
> +bus = pci_register_root_bus(dev, NULL,
>  pci_spapr_set_irq, pci_spapr_map_irq, sphb,
>  >memspace, >iospace,
>  PCI_DEVFN(0, 0), PCI_NUM_PINS,
> 

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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH 2/3] aspeed: add a per SoC mapping for the memory space

[Joel Stanley]

On Thu, 11 Apr 2019 at 16:10, Cédric Le Goater  wrote:
>
> This will simplify the definition of new SoCs, like the AST2600 which
> should use a slightly different address space and have a different set
> of controllers.
>
> Signed-off-by: Cédric Le Goater 

> diff --git a/hw/arm/aspeed_soc.c b/hw/arm/aspeed_soc.c
> index 5bbd1fb87d18..9b601709e93c 100644
> --- a/hw/arm/aspeed_soc.c
> +++ b/hw/arm/aspeed_soc.c

> +static const hwaddr aspeed_soc_ast2400_memmap[] = {

> +static const hwaddr aspeed_soc_ast2500_memmap[] = {

Most of these arrays is common. And some of it will stay common in the
2600. Any ideas how we could avoid duplication?

This is fine for now.

Reviewed-by: Joel Stanley 

Re: [Qemu-devel] [PATCH 3/3] aspeed: use sysbus_init_child_obj() to initialize children

[Joel Stanley]

On Thu, 11 Apr 2019 at 16:10, Cédric Le Goater  wrote:
>
> Signed-off-by: Cédric Le Goater 

Reviewed-by: Joel Stanley 

Re: [Qemu-devel] [PATCH 1/3] aspeed: add a per SoC mapping for the interrupt space

[Joel Stanley]

On Thu, 11 Apr 2019 at 16:10, Cédric Le Goater  wrote:
>
> This will simplify the definition of new SoCs, like the AST2600 which
> should use a different CPU and a different IRQ number layout.
>
> Signed-off-by: Cédric Le Goater 

Reviewed-by: Joel Stanley 

Re: [Qemu-devel] [RISU v2] i386: Add avx512 state to reginfo_t

[Jan Bobek]

Looks fine to me. I suppose if I had written it, I would have included
more comments and/or #define's to make some bits more obvious (all the
magic constants look a bit scary until you read the Intel manual), but
nevermind that.

I guess the other remaining part now is extending risugen to actually
generate the test blobs.

-Jan

On 4/9/19 2:54 AM, Richard Henderson wrote:
> The state expected for a given test must be specifically requested
> with the --xfeatures=mask command-line argument.  This is recorded
> with the saved state so that it is obvious if the apprentice is given
> a different argument.  Any features beyond what are present on the
> running cpu will read as zero.
> 
> Signed-off-by: Richard Henderson 
> ---
> 
> More fiddling.  This puts an --xfeature=mask argument on the command
> line that must agree the test case being tested.  This requires somewhat
> deeper knowledge of the cpu than I would otherwise like, but I cannot
> disconnect this knowledge with that required for writing the test in
> the first place.
> 
> Usual values for mask are 3 (SSE), 7 (AVX), 0xe7 (AVX512), and well
> documented in the "Managing state using the XSAVE feature set"
> chapter of the Intel architecture manual.
> 
> Thoughts?
> 
> 
> r~



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] Question: can we hot plug a PCIe switch on machine "virt"

[Heyi Guo]

Hi Eric and Michael,

Appreciate your sharing of this information. But sorry I'm still a little 
confused due to my poor English...


On 2019/4/11 20:19, Auger Eric wrote:

Hi Heyi,

On 4/11/19 1:30 PM, Heyi Guo wrote:

Hi Eric,

Could you help to confirm?

Practically I have not tried anything else than hot-plugging the
downstream port downstream to the upstream port. This looks not
supported as documented.

Do you mean you *have* tried hot-plugging the downstream port to the upstream 
port? Have you succeeded? Could you tell how to do that?



Michael answered that up to him, the downstream port could only be
plugged downto the upstream port.

Is only code-plugging supported here, or hot-plugging is supported as well?

Thanks,
Heyi



On my side I have not aware of any usage of the downstream port outside
of the switch's scope.

Thanks

Eric

Thanks,

Heyi


On 2019/4/7 9:59, Heyi Guo wrote:

Hi Eric,

My real interesting is about the hotplug of PCIe switch, which means
we don't need to provide lots of PCIe root ports or PCIe down stream
ports at the beginning, but we can extend the capacity by hot adding
PCIe switches which can provide more hot-pluggable slots for endpoint
devices.

The document docs/pcie.txt says "PCI Express Downstream Ports can't be
hot-plugged into an existing PCI Express Upstream Port" which confuses
me. Does it actually mean Downstream Ports can't be hot-plugged? For
they can't be hot-plugged into an existing Upstream Port as the doc
says, either they can't be hot-plugged into an non-existing Upstream
Port or another place...

Thanks,

Heyi


On 2019/4/4 15:39, Auger Eric wrote:

Hi Heyi,

On 4/3/19 8:50 PM, Michael S. Tsirkin wrote:

On Wed, Apr 03, 2019 at 03:32:09PM +0800, Heyi Guo wrote:

Hi folks,

In physical world, a PCIe switch including one upstream port and
several downstream ports is a single physical device, however we
treat each port as a device in qemu world. In qemu docs/pcie.txt,
we have below statements:

Line 230: Be aware that PCI Express Downstream Ports can't be
hot-plugged into
Line 231: an existing PCI Express Upstream Port.

To my understanding, it implies PCIe downstream ports *can* be
hot-plugged into something which is not an existing upstream port.
If it is true, how can we do that? AFAIK monitor command device_add
can only add one device at a time.

Please help to show the truth.

Thanks,

Heyi


afaik they can only be plugged into upstearm ports with or without
hotplug.

Hotplug on upstream port does not look supported, as mentionned in
the doc:
(QEMU) device_add driver=xio3130-downstream id=down0 bus=upstream_port1
{"error": {"class": "GenericError", "desc": "Bus 'upstream_port1' does
not support hotplugging"}}

Looks the std way to use the downstream port is the one documented in
2.2.3:

2.2.3 Plugging a PCI Express device into a Switch:
-device ioh3420,id=root_port1,chassis=x,slot=y[,bus=pcie.0][,addr=z]
-device x3130-upstream,id=upstream_port1,bus=root_port1[,addr=x]
-device
xio3130-downstream,id=downstream_port1,bus=upstream_port1,chassis=x1,slot=y1[,addr=z1]]

-device ,bus=downstream_port1

For my curiosity why do you want to hotplug a downstream port in another
place than an upstream port?

Thanks

Eric


.




.

Re: [Qemu-devel] [RFC PATCH] hw/arm/virt: use variable size of flash device to save memory

[Xiang Zheng]

On 2019/4/11 20:22, Kevin Wolf wrote:
> Okay, so your problem is that blk_pread() writes to the whole buffer,
> writing explicit zeroes for unallocated parts of the image, while you
> would like to leave those parts of the buffer untouched so that we don't
> actually allocate the memory, but can just use the shared zero page.
> 
> If you just want to read the non-zero parts of the image, that can be
> done by using a loop that calls bdrv_block_status() and only reads from
> the image if the BDRV_BLOCK_ZERO bit is clear.
> 
> Would this solve your problem?

Sounds good! What if guest tried to read/write the zero parts?

-- 

Thanks,
Xiang

Re: [Qemu-devel] [RISU PATCH 0/5] Fix RISU build for i386

[Jan Bobek]

Sorry for the delayed reply, the U.S. tax deadline has caught up with
me, so I spent the last two evenings doing my taxes. (Yuck!)

Anyway...

On 4/8/19 6:18 PM, Richard Henderson wrote:
> On 4/8/19 8:27 AM, Jan Bobek wrote:
>> 2. Note the '-std=c99' switch in the command-line above; without it,
>>GCC defines the symbol 'i386' to 1 and the preprocessor magic for
>>including arch-specific headers in risu.h breaks. Does anyone have
>>an idea how to fix this in a more robust way?
> 
> Adding -U$(ARCH) to the command line is probably as good a fix as any.

I didn't know about -U, nice!

>> 3. gas (the GNU assembler) chokes on the syntax of test_i386.s; that's
>>why I'm using nasm as the assembler above. Is that intentional? I
>>haven't found the nasm dependency mentioned anywhere.
> 
> I think rewriting to not require nasm is better.

Agreed.

>>Also, nasm will happily emit the UD1 opcode (0F B9) with no
>>operands (see test_i386.s). That's a bit surprising to me, since
>>Intel's Software Developer's Manual says UD1 has two operands; I'd
>>expect at least a follow-up ModR/M byte. gas refuses to assemble
>>UD1 with no operands, and gdb's disassembler gets confused when I
>>load up the nasm's binary into risu. Is there something obvious
>>that I'm missing?
> 
> You are not missing anything -- ud1 should require a modrm byte.
> 
> My suggestion is to use only UD1 as the "break" insn, with the different OP_*
> codes encoded into the modrm byte.

I had to laugh when I read this; this is *exactly* what I had in mind,
but then I found out there was no ModR/M byte.

>> P.S. This is my first time using git send-email, so please bear with
>>  me if something goes wrong and/or let me know how I can improve
>>  my future submissions. Thank you!
> 
> You've done well with git send-email.  ;-)

Thanks a lot! :)

-Jan



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [PATCH v2] target/i386: sev: add 'sev-max-guests' field to 'query-sev-capabilities'

[Singh, Brijesh]

There are limited numbers of the SEV guests that can be run concurrently.
A management applications may need to know this limit so that it can place
SEV VMs on hosts which have suitable resources available.

Currently, this limit is not exposed to the application. Add a new
'sev-max-guest' field in the query-sev-capabilities to provide this
information.

Cc: Paolo Bonzini 
Cc: Markus Armbruster 
Cc: Eric Blake 
Cc: Daniel P. Berrangé 
Cc: Laszlo Ersek 
Cc: Erik Skultety 
Cc: Tom Lendacky 
Signed-off-by: Brijesh Singh 
---

changes since v1:
 - document the new field and add (since 4.1) annotation.

 qapi/target.json  | 9 +++--
 target/i386/sev.c | 9 +++--
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/qapi/target.json b/qapi/target.json
index 1d4d54b600..8cd4fc7919 100644
--- a/qapi/target.json
+++ b/qapi/target.json
@@ -177,13 +177,17 @@
 # @reduced-phys-bits: Number of physical Address bit reduction when SEV is
 # enabled
 #
+# @sev-max-guests: maximum number of concurrent SEV guest with SEV-ES disabled
+#  (since 4.1)
+#
 # Since: 2.12
 ##
 { 'struct': 'SevCapability',
   'data': { 'pdh': 'str',
 'cert-chain': 'str',
 'cbitpos': 'int',
-'reduced-phys-bits': 'int'},
+'reduced-phys-bits': 'int',
+'sev-max-guests': 'int'},
   'if': 'defined(TARGET_I386)' }
 
 ##
@@ -200,7 +204,8 @@
 #
 # -> { "execute": "query-sev-capabilities" }
 # <- { "return": { "pdh": "8CCDD8DDD", "cert-chain": "888CCCDDDEE",
-#  "cbitpos": 47, "reduced-phys-bits": 5}}
+#  "cbitpos": 47, "reduced-phys-bits": 5,
+#  "sev-max-guests" : 15}}
 #
 ##
 { 'command': 'query-sev-capabilities', 'returns': 'SevCapability',
diff --git a/target/i386/sev.c b/target/i386/sev.c
index cd77f6b5d4..6829586fbe 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -488,7 +488,7 @@ sev_get_capabilities(void)
 guchar *pdh_data = NULL;
 guchar *cert_chain_data = NULL;
 size_t pdh_len = 0, cert_chain_len = 0;
-uint32_t ebx;
+uint32_t ebx, ecx, edx;
 int fd;
 
 fd = open(DEFAULT_SEV_DEVICE, O_RDWR);
@@ -507,7 +507,7 @@ sev_get_capabilities(void)
 cap->pdh = g_base64_encode(pdh_data, pdh_len);
 cap->cert_chain = g_base64_encode(cert_chain_data, cert_chain_len);
 
-host_cpuid(0x801F, 0, NULL, , NULL, NULL);
+host_cpuid(0x801F, 0, NULL, , , );
 cap->cbitpos = ebx & 0x3f;
 
 /*
@@ -516,6 +516,11 @@ sev_get_capabilities(void)
  */
 cap->reduced_phys_bits = 1;
 
+/*
+ * The maximum number of SEV guests with SEV-ES disabled that can run
+ * simultaneously.
+ */
+cap->sev_max_guests = ecx - edx + 1;
 out:
 g_free(pdh_data);
 g_free(cert_chain_data);
-- 
2.17.1

Re: [Qemu-devel] [PATCH for-4.1] q35: acpi: do not create dummy MCFG table

[Wei Yang]

On Tue, Apr 09, 2019 at 05:00:37PM +0200, Igor Mammedov wrote:
>Dummy table (with signature "QEMU") creation came from original SeaBIOS
>codebase. And QEMU would have to keep it around if there were Q35 machine
>that depended on keeping ACPI tables blob constant size. Luckily there
>were no versioned Q35 machine types before commit:
>  (since 2.3) a1666142db acpi-build: make ROMs RAM blocks resizeable
>which obsoleted need to keep ACPI tables blob the same size on 
>source/destination.
>
>Considering the 1st versioned machine is pc-q35-2.4, the dummy table
>is not really necessary and it's safe to drop it without breaking
>cross version migration in both directions unconditionally.
>
>Signed-off-by: Igor Mammedov 

Reviewed-by: Wei Yang 

>---
> hw/i386/acpi-build.c | 18 --
> 1 file changed, 4 insertions(+), 14 deletions(-)
>
>diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
>index 416da31..8671e25 100644
>--- a/hw/i386/acpi-build.c
>+++ b/hw/i386/acpi-build.c
>@@ -2401,7 +2401,6 @@ static void
> build_mcfg_q35(GArray *table_data, BIOSLinker *linker, AcpiMcfgInfo *info)
> {
> AcpiTableMcfg *mcfg;
>-const char *sig;
> int len = sizeof(*mcfg) + 1 * sizeof(mcfg->allocation[0]);
> 
> mcfg = acpi_data_push(table_data, len);
>@@ -2411,19 +2410,7 @@ build_mcfg_q35(GArray *table_data, BIOSLinker *linker, 
>AcpiMcfgInfo *info)
> mcfg->allocation[0].start_bus_number = 0;
> mcfg->allocation[0].end_bus_number = PCIE_MMCFG_BUS(info->mcfg_size - 1);
> 
>-/* MCFG is used for ECAM which can be enabled or disabled by guest.
>- * To avoid table size changes (which create migration issues),
>- * always create the table even if there are no allocations,
>- * but set the signature to a reserved value in this case.
>- * ACPI spec requires OSPMs to ignore such tables.
>- */
>-if (info->mcfg_base == PCIE_BASE_ADDR_UNMAPPED) {
>-/* Reserved signature: ignored by OSPM */
>-sig = "QEMU";
>-} else {
>-sig = "MCFG";
>-}
>-build_header(linker, table_data, (void *)mcfg, sig, len, 1, NULL, NULL);
>+build_header(linker, table_data, (void *)mcfg, "MCFG", len, 1, NULL, 
>NULL);
> }
> 
> /*
>@@ -2592,6 +2579,9 @@ static bool acpi_get_mcfg(AcpiMcfgInfo *mcfg)
> }
> mcfg->mcfg_base = qnum_get_uint(qobject_to(QNum, o));
> qobject_unref(o);
>+if (mcfg->mcfg_base == PCIE_BASE_ADDR_UNMAPPED) {
>+return false;
>+}
> 
> o = object_property_get_qobject(pci_host, PCIE_HOST_MCFG_SIZE, NULL);
> assert(o);
>-- 
>2.7.4
>

-- 
Wei Yang
Help you, Help me

Re: [Qemu-devel] [PATCH for-4.1] q35: acpi: do not create dummy MCFG table

[Wei Yang]

On Thu, Apr 11, 2019 at 01:46:27PM +0200, Igor Mammedov wrote:
>On Thu, 11 Apr 2019 09:32:11 +0800
>Wei Yang  wrote:
>

[...]

>> To be honest, this is what I feel confused in your previous reply.
>> 
>> First I want to confirm both fields in RAMBlock affects the migration:
>> 
>> * used_length
>> * max_length
>> 
>> Both of them should be the same on both source/destination, otherwise the
>> migration would fail.
>well, it works fine for me.
>Where do you see max_length being used during migration?
>

I asked my colleague, but seems you are right.

>
>> Then I thought the migration would be broken if source/destination has
>> different knowledge about acpi table size. Because this will introduce
>> different value of used_length, even we have resizable MemoryRegion.
>> 
>> The 1st time ACPI generation flow:
>> 
>> acpi_add_rom_blob
>> rom_add_blob
>> rom_set_mr
>> memory_region_init_resizable_ram
>> qemu_ram_alloc_resizable
>>  new_block->used_length = size
>>  new_block->max_length = max_size
>> 
>> The 2nd time ACPI generation flow:
>> 
>> acpi_ram_update
>> memory_regioin_ram_resize
>> qemu_ram_resize
>> block->used_length = new_size
>> 
>> The max_length is always the same, while used_length would be changed to the
>> actual table_blob size.
>> 
>> In case source/destination has different knowledge about acpi table size, the
>> table_blob size(even after aligned) could be different.
>> 
>> This is why I thought there is still some chance to break migration after
>> resizable MemoryRegion.
>> 
>> Do I miss something?
>yes, you did, max_length does not influence migration stream.
>see what above mentioned commits and ram_load() -> "if (length != 
>block->used_length)" do.
>

I see this in the code.

So the destination will check length and adjust self's length if it
doesn't equal to the source.

Thanks :-)

-- 
Wei Yang
Help you, Help me

[Qemu-devel] [Bug 1823458] Re: race condition between vhost_net_stop and CHR_EVENT_CLOSED on shutdown crashes qemu

[Dan Streetman]

test builds in https://launchpad.net/~ddstreet/+archive/ubuntu/lp1823458

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

Title:
  race condition between vhost_net_stop and CHR_EVENT_CLOSED on shutdown
  crashes qemu

Status in QEMU:
  In Progress
Status in qemu package in Ubuntu:
  In Progress
Status in qemu source package in Trusty:
  In Progress
Status in qemu source package in Xenial:
  In Progress
Status in qemu source package in Bionic:
  In Progress
Status in qemu source package in Cosmic:
  In Progress
Status in qemu source package in Disco:
  In Progress

Bug description:
  [impact]

  on shutdown of a guest, there is a race condition that results in qemu
  crashing instead of normally shutting down.  The bt looks similar to
  this (depending on the specific version of qemu, of course; this is
  taken from 2.5 version of qemu):

  (gdb) bt
  #0  __GI___pthread_mutex_lock (mutex=0x0) at ../nptl/pthread_mutex_lock.c:66
  #1  0x5636c0bc4389 in qemu_mutex_lock (mutex=mutex@entry=0x0) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/util/qemu-thread-posix.c:73
  #2  0x5636c0988130 in qemu_chr_fe_write_all (s=s@entry=0x0, 
buf=buf@entry=0x7ffe65c086a0 "\v", len=len@entry=20) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/qemu-char.c:205
  #3  0x5636c08f3483 in vhost_user_write (msg=msg@entry=0x7ffe65c086a0, 
fds=fds@entry=0x0, fd_num=fd_num@entry=0, dev=0x5636c1bf6b70, 
dev=0x5636c1bf6b70)
  at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/vhost-user.c:195
  #4  0x5636c08f411c in vhost_user_get_vring_base (dev=0x5636c1bf6b70, 
ring=0x7ffe65c087e0) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/vhost-user.c:364
  #5  0x5636c08efff0 in vhost_virtqueue_stop (dev=dev@entry=0x5636c1bf6b70, 
vdev=vdev@entry=0x5636c2853338, vq=0x5636c1bf6d00, idx=1) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/vhost.c:895
  #6  0x5636c08f2944 in vhost_dev_stop (hdev=hdev@entry=0x5636c1bf6b70, 
vdev=vdev@entry=0x5636c2853338) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/vhost.c:1262
  #7  0x5636c08db2a8 in vhost_net_stop_one (net=0x5636c1bf6b70, 
dev=dev@entry=0x5636c2853338) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/hw/net/vhost_net.c:293
  #8  0x5636c08dbe5b in vhost_net_stop (dev=dev@entry=0x5636c2853338, 
ncs=0x5636c209d110, total_queues=total_queues@entry=1) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/hw/net/vhost_net.c:371
  #9  0x5636c08d7745 in virtio_net_vhost_status (status=7 '\a', 
n=0x5636c2853338) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/net/virtio-net.c:150
  #10 virtio_net_set_status (vdev=, status=) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/hw/net/virtio-net.c:162
  #11 0x5636c08ec42c in virtio_set_status (vdev=0x5636c2853338, 
val=) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/virtio.c:624
  #12 0x5636c098fed2 in vm_state_notify (running=running@entry=0, 
state=state@entry=RUN_STATE_SHUTDOWN) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/vl.c:1605
  #13 0x5636c089172a in do_vm_stop (state=RUN_STATE_SHUTDOWN) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/cpus.c:724
  #14 vm_stop (state=RUN_STATE_SHUTDOWN) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/cpus.c:1407
  #15 0x5636c085d240 in main_loop_should_exit () at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/vl.c:1883
  #16 main_loop () at /build/qemu-7I4i1R/qemu-2.5+dfsg/vl.c:1931
  #17 main (argc=, argv=, envp=) 
at /build/qemu-7I4i1R/qemu-2.5+dfsg/vl.c:4683

  [test case]

  unfortunately since this is a race condition, it's very hard to
  arbitrarily reproduce; it depends very much on the overall
  configuration of the guest as well as how exactly it's shut down -
  specifically, its vhost user net must be closed from the host side at
  a specific time during qemu shutdown.

  I have someone with such a setup who has reported to me their setup is
  able to reproduce this reliably, but the config is too complex for me
  to reproduce so I have relied on their reproduction and testing to
  debug and craft the patch for this.

  [regression potential]

  the change adds flags to prevent repeated calls to both
  vhost_net_stop() and vhost_net_cleanup() (really, prevents repeated
  calls to vhost_dev_cleanup(), but vhost_net_cleanup() does nothing
  else).  Any regression would be seen when stopping and/or cleaning up
  a vhost net.  Regressions might include failure to hot-remove a vhost
  net from a guest, or failure to cleanup (i.e. mem leak), or crashes
  during cleanup or stopping a vhost net.

  However, the flags are very unintrusive, and only in the shutdown path
  (of a vhost_dev or vhost_net), and are unlikely to cause any
  regressions.

  [other info]

  this was originally seen in the 2.5 version of qemu - specifically,
  the UCA version in trusty-mitaka (which uses the xenial qemu
  codebase).  However, this appears to still apply upstream, and I am
  sending a patch to the qemu list to patch upstream as well.

  The specific race condition for this (in the qemu 2.5 

Re: [Qemu-devel] [PATCH v4 1/6] vfio-ccw: make it safe to access channel programs

[Eric Farman]

On 4/10/19 10:59 PM, Eric Farman wrote:



On 4/9/19 7:34 PM, Halil Pasic wrote:

On Mon, 8 Apr 2019 19:07:47 +0200


...snip...


I'm just running fio on a pass-through DASD and on some virto-blk disks
in parallel. My QEMU is today's vfio-ccw-caps from your repo.

I see stuff like this:
qemu-git: vfio-ccw: wirte I/O region failed with errno=16[1811/7332/0 
iops] [eta 26m:34s]


Without knowing what the I/O was that failed, this is a guessing game. 
But I encountered something similar just now running fio.


qemu:
2019-04-11T02:06:09.524838Z qemu-system-s390x: vfio-ccw: wirte I/O 
region failed with errno=16


...snip...

 From the associated I/O, I think this is fixed by a series I am nearly 
ready to send for review.  I'll try again with those fixes on top of the 
two series here, and report back.


So, I've run enough combinations to feel comfortable saying that the 
error (EBUSY) I saw last night (and presumably the one Halil saw) exists 
in today's code and is not introduced by this series.  It also appears 
to be addressed by one of the patches in a series I'm working on, but 
which that series still has some further problems.  Sigh, there are too 
many branches and too many interrupts.


 - Eric

[Qemu-devel] [Bug 1823458] Re: race condition between vhost_net_stop and CHR_EVENT_CLOSED on shutdown crashes qemu

[Dan Streetman]

** Description changed:

  [impact]
  
  on shutdown of a guest, there is a race condition that results in qemu
  crashing instead of normally shutting down.  The bt looks similar to
  this (depending on the specific version of qemu, of course; this is
  taken from 2.5 version of qemu):
  
  (gdb) bt
  #0  __GI___pthread_mutex_lock (mutex=0x0) at ../nptl/pthread_mutex_lock.c:66
  #1  0x5636c0bc4389 in qemu_mutex_lock (mutex=mutex@entry=0x0) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/util/qemu-thread-posix.c:73
  #2  0x5636c0988130 in qemu_chr_fe_write_all (s=s@entry=0x0, 
buf=buf@entry=0x7ffe65c086a0 "\v", len=len@entry=20) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/qemu-char.c:205
  #3  0x5636c08f3483 in vhost_user_write (msg=msg@entry=0x7ffe65c086a0, 
fds=fds@entry=0x0, fd_num=fd_num@entry=0, dev=0x5636c1bf6b70, 
dev=0x5636c1bf6b70)
  at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/vhost-user.c:195
  #4  0x5636c08f411c in vhost_user_get_vring_base (dev=0x5636c1bf6b70, 
ring=0x7ffe65c087e0) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/vhost-user.c:364
  #5  0x5636c08efff0 in vhost_virtqueue_stop (dev=dev@entry=0x5636c1bf6b70, 
vdev=vdev@entry=0x5636c2853338, vq=0x5636c1bf6d00, idx=1) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/vhost.c:895
  #6  0x5636c08f2944 in vhost_dev_stop (hdev=hdev@entry=0x5636c1bf6b70, 
vdev=vdev@entry=0x5636c2853338) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/vhost.c:1262
  #7  0x5636c08db2a8 in vhost_net_stop_one (net=0x5636c1bf6b70, 
dev=dev@entry=0x5636c2853338) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/hw/net/vhost_net.c:293
  #8  0x5636c08dbe5b in vhost_net_stop (dev=dev@entry=0x5636c2853338, 
ncs=0x5636c209d110, total_queues=total_queues@entry=1) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/hw/net/vhost_net.c:371
  #9  0x5636c08d7745 in virtio_net_vhost_status (status=7 '\a', 
n=0x5636c2853338) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/net/virtio-net.c:150
  #10 virtio_net_set_status (vdev=, status=) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/hw/net/virtio-net.c:162
  #11 0x5636c08ec42c in virtio_set_status (vdev=0x5636c2853338, 
val=) at /build/qemu-7I4i1R/qemu-2.5+dfsg/hw/virtio/virtio.c:624
  #12 0x5636c098fed2 in vm_state_notify (running=running@entry=0, 
state=state@entry=RUN_STATE_SHUTDOWN) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/vl.c:1605
  #13 0x5636c089172a in do_vm_stop (state=RUN_STATE_SHUTDOWN) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/cpus.c:724
  #14 vm_stop (state=RUN_STATE_SHUTDOWN) at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/cpus.c:1407
  #15 0x5636c085d240 in main_loop_should_exit () at 
/build/qemu-7I4i1R/qemu-2.5+dfsg/vl.c:1883
  #16 main_loop () at /build/qemu-7I4i1R/qemu-2.5+dfsg/vl.c:1931
  #17 main (argc=, argv=, envp=) 
at /build/qemu-7I4i1R/qemu-2.5+dfsg/vl.c:4683
  
  [test case]
  
  unfortunately since this is a race condition, it's very hard to
  arbitrarily reproduce; it depends very much on the overall configuration
  of the guest as well as how exactly it's shut down - specifically, its
  vhost user net must be closed from the host side at a specific time
  during qemu shutdown.
  
  I have someone with such a setup who has reported to me their setup is
  able to reproduce this reliably, but the config is too complex for me to
  reproduce so I have relied on their reproduction and testing to debug
  and craft the patch for this.
  
  [regression potential]
  
  the change adds flags to prevent repeated calls to both vhost_net_stop()
  and vhost_net_cleanup() (really, prevents repeated calls to
- vhost_dev_cleanup()).  Any regression would be seen when stopping and/or
- cleaning up a vhost net.  Regressions might include failure to hot-
- remove a vhost net from a guest, or failure to cleanup (i.e. mem leak),
- or crashes during cleanup or stopping a vhost net.
+ vhost_dev_cleanup(), but vhost_net_cleanup() does nothing else).  Any
+ regression would be seen when stopping and/or cleaning up a vhost net.
+ Regressions might include failure to hot-remove a vhost net from a
+ guest, or failure to cleanup (i.e. mem leak), or crashes during cleanup
+ or stopping a vhost net.
+ 
+ However, the flags are very unintrusive, and only in the shutdown path
+ (of a vhost_dev or vhost_net), and are unlikely to cause any
+ regressions.
  
  [other info]
  
  this was originally seen in the 2.5 version of qemu - specifically, the
  UCA version in trusty-mitaka (which uses the xenial qemu codebase).
  However, this appears to still apply upstream, and I am sending a patch
  to the qemu list to patch upstream as well.
  
  The specific race condition for this (in the qemu 2.5 code version) is:
  
  as shown in above bt, thread A starts shutting down qemu, e.g.:
  
  vm_stop->do_vm_stop->vm_state_notify
    virtio_set_status
  virtio_net_set_status
    virtio_net_vhost_status
  
  in this function, code gets to an if-else check for (!n->vhost_started),
  which is false (i.e. vhost_started is true) and enters the else code
  block, which 

[Qemu-devel] [Bug 1823790] Re: QEMU mishandling of SO_PEERSEC forces systemd into tight loop

[Matthias Lüscher]

I have just studied a bit the systemd code and this brought me to the
following idea/temporary workaround: What about returning -1 (error) and
setting errno when getsockopt(fd, SOL_SOCKET, SO_PEERSEC, ...) gets
called? This would then let systemd know that SO_PEERSEC is not (yet)
implemented.

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

Title:
  QEMU mishandling of SO_PEERSEC forces systemd into tight loop

Status in QEMU:
  New

Bug description:
  While building Debian images for embedded ARM target systems I
  detected that QEMU seems to force newer systemd daemons into a tight
  loop.

  My setup is the following:

  Host machine: Ubuntu 18.04, amd64
  LXD container: Debian Buster, arm64, systemd 241
  QEMU: qemu-aarch64-static, 4.0.0-rc2 (custom build) and 3.1.0 (Debian 
1:3.1+dfsg-7)

  To easily reproduce the issue I have created the following repository:
  https://github.com/lueschem/edi-qemu

  The call where systemd gets looping is the following:
  2837 getsockopt(3,1,31,274891889456,274887218756,274888927920) = -1 errno=34 
(Numerical result out of range)

  Furthermore I also verified that the issue is not related to LXD.
  The same behavior can be reproduced using systemd-nspawn.

  This issue reported against systemd seems to be related:
  https://github.com/systemd/systemd/issues/11557

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

[Qemu-devel] [Bug 1823790] Re: QEMU mishandling of SO_PEERSEC forces systemd into tight loop

[Matthias Lüscher]

This is probably the tight loop that gets triggered:
https://github.com/systemd/systemd/commit/217d89678269334f461e9abeeffed57077b21454

It looks like the previous implementation was just a bit more
"tolerant".

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

Title:
  QEMU mishandling of SO_PEERSEC forces systemd into tight loop

Status in QEMU:
  New

Bug description:
  While building Debian images for embedded ARM target systems I
  detected that QEMU seems to force newer systemd daemons into a tight
  loop.

  My setup is the following:

  Host machine: Ubuntu 18.04, amd64
  LXD container: Debian Buster, arm64, systemd 241
  QEMU: qemu-aarch64-static, 4.0.0-rc2 (custom build) and 3.1.0 (Debian 
1:3.1+dfsg-7)

  To easily reproduce the issue I have created the following repository:
  https://github.com/lueschem/edi-qemu

  The call where systemd gets looping is the following:
  2837 getsockopt(3,1,31,274891889456,274887218756,274888927920) = -1 errno=34 
(Numerical result out of range)

  Furthermore I also verified that the issue is not related to LXD.
  The same behavior can be reproduced using systemd-nspawn.

  This issue reported against systemd seems to be related:
  https://github.com/systemd/systemd/issues/11557

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

Re: [Qemu-devel] [PATCH for 4.1 v3 2/6] target/riscv: Fall back to generating a RISC-V CPU

[Alistair Francis]

On Thu, Apr 11, 2019 at 5:18 AM Igor Mammedov  wrote:
>
> On Wed, 10 Apr 2019 23:10:25 +
> Alistair Francis  wrote:
>
> > If a user specifies a CPU that we don't understand then we want to fall
> > back to a CPU generated from the ISA string.
> It might look like a nice thing to do at the beginning, but
> fallbacks become a source of pain in future and get in the way
> of refactorings if there is a promise to maintain defaults (fallbacks)
> stable.
>
> I suggest do not fallback to anything, just fail cleanly
> with informative error telling users what is wrong and let user
> fix their invalid CLI in the first place.

Maybe fall back isn't the right word then, as this is the goal of this
series. Here is what I want to happen:

User runs QEMU RISC-V without -cpu option:
The user gets a CPU that supports "standard" ISA extensions, as
what happens now

User runs QEMU RISC-V with a CPU model that is hard coded in cpu.h
(such as TYPE_RISCV_CPU_SIFIVE_U54):
The user gets a CPU that matches that hard coded CPU string/init

User runs QEMU RISC-V with a RISC-V ISA string that isn't hardcoded
(for example rv64gcsuh):
QEMU will dynamically create a CPU based on the specified bit
length (rv32/rv64) and the ISA extensions supported
The goal of this is to allow new extensions to be enabled and
disabled as required. For example when we add a new extension maybe we
don't want it on by default but we want an option to enable it. Or
maybe a user wants to test their code on a model without compressed
instruction (c extension) support.

Alistair

>
>
> > At the moment the generated CPU is assumed to be a privledge spec
> > version 1.10 CPU with an MMU. This can be changed in the future.
> >
> > Signed-off-by: Alistair Francis 
> > ---
> > v3:
> >  - Ensure a minimal length so we don't run off the end of the string.
> >  - Don't parse the rv32/rv64 in the loop
> >  target/riscv/cpu.c | 101 -
> >  target/riscv/cpu.h |   2 +
> >  2 files changed, 102 insertions(+), 1 deletion(-)
> >
> > diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> > index d61bce6d55..27be9e412a 100644
> > --- a/target/riscv/cpu.c
> > +++ b/target/riscv/cpu.c
> > @@ -19,6 +19,7 @@
> >
> >  #include "qemu/osdep.h"
> >  #include "qemu/log.h"
> > +#include "qemu/error-report.h"
> >  #include "cpu.h"
> >  #include "exec/exec-all.h"
> >  #include "qapi/error.h"
> > @@ -103,6 +104,99 @@ static void set_resetvec(CPURISCVState *env, int 
> > resetvec)
> >  #endif
> >  }
> >
> > +static void riscv_generate_cpu_init(Object *obj)
> > +{
> > +RISCVCPU *cpu = RISCV_CPU(obj);
> > +CPURISCVState *env = >env;
> > +RISCVCPUClass *mcc = RISCV_CPU_GET_CLASS(cpu);
> > +const char *riscv_cpu = mcc->isa_str;
> > +target_ulong target_misa = 0;
> > +target_ulong rvxlen = 0;
> > +int i;
> > +bool valid = false;
> > +
> > +/*
> > + * We need at least 5 charecters for the string to be valid. Check that
> > + * now so we can be lazier later.
> > + */
> > +if (strlen(riscv_cpu) < 5) {
> > +error_report("'%s' does not appear to be a valid RISC-V ISA 
> > string",
> > + riscv_cpu);
> > +exit(1);
> > +}
> > +
> > +if (riscv_cpu[0] == 'r' && riscv_cpu[1] == 'v') {
> > +/* Starts with "rv" */
> > +if (riscv_cpu[2] == '3' && riscv_cpu[3] == '2') {
> > +valid = true;
> > +rvxlen = RV32;
> > +}
> > +if (riscv_cpu[2] == '6' && riscv_cpu[3] == '4') {
> > +valid = true;
> > +rvxlen = RV64;
> > +}
> > +}
> > +
> > +if (!valid) {
> > +error_report("'%s' does not appear to be a valid RISC-V CPU",
> > + riscv_cpu);
> > +exit(1);
> > +}
> > +
> > +for (i = 4; i < strlen(riscv_cpu); i++) {
> > +switch (riscv_cpu[i]) {
> > +case 'i':
> > +if (target_misa & RVE) {
> > +error_report("I and E extensions are incompatible");
> > +exit(1);
> > +}
> > +target_misa |= RVI;
> > +continue;
> > +case 'e':
> > +if (target_misa & RVI) {
> > +error_report("I and E extensions are incompatible");
> > +exit(1);
> > +}
> > +target_misa |= RVE;
> > +continue;
> > +case 'g':
> > +target_misa |= RVI | RVM | RVA | RVF | RVD;
> > +continue;
> > +case 'm':
> > +target_misa |= RVM;
> > +continue;
> > +case 'a':
> > +target_misa |= RVA;
> > +continue;
> > +case 'f':
> > +target_misa |= RVF;
> > +continue;
> > +case 'd':
> > +target_misa |= RVD;
> > +continue;
> > +case 'c':
> > +target_misa |= RVC;
> > +continue;
> > +case 's':
> > +

Re: [Qemu-devel] [PATCH for 4.1 v3 6/6] riscv: Add a generic spike machine

[Alistair Francis]

On Thu, Apr 11, 2019 at 5:18 AM Peter Maydell  wrote:
>
> On Thu, 11 Apr 2019 at 13:07, Igor Mammedov  wrote:
> >
> > On Wed, 10 Apr 2019 23:11:00 +
> > Alistair Francis  wrote:
> > > +/* register system main memory (actual RAM) */
> > > +memory_region_init_ram(main_mem, NULL, "riscv.spike.ram",
> > > +   machine->ram_size, _fatal);
> > do you really care about migration? if not then _nomigrate flavor would
> > be more suitable.
>
> Every machine model should care about migration, at least to
> the extent of making savevm/loadvm snapshots work. Using
> memory_region_init_ram_nomigrate() is a bad idea in new
> code: it exists only for the benefit of older code which
> is handling the migration of the backing RAM by hand for
> migration-compatibility reasons.

Ok, I'll leave this as is then.

>
> > >  /* Initialize SOC */
> > >  object_initialize_child(OBJECT(machine), "soc", >soc, 
> > > sizeof(s->soc),
> > >  TYPE_RISCV_HART_ARRAY, _abort, NULL);
> > > @@ -254,6 +343,12 @@ static void spike_v1_09_1_board_init(MachineState 
> > > *machine)
> > >  MemoryRegion *mask_rom = g_new(MemoryRegion, 1);
> > >  int i;
> > >
> > > +if (!qtest_enabled()) {
> > > +info_report("The Spike v1.09.1 machine has been depreceated. "
> > > +"Please use the deneric spike machine and specify 
> > > the ISA "
>
> "generic"

Fixed in v4.

Alistair

>
> > > +"versions using -cpu.");
> > > +}
> > > +
>
> thanks
> -- PMM

Re: [Qemu-devel] [PATCH for 4.1 v3 6/6] riscv: Add a generic spike machine

[Alistair Francis]

On Thu, Apr 11, 2019 at 5:06 AM Igor Mammedov  wrote:
>
> On Wed, 10 Apr 2019 23:11:00 +
> Alistair Francis  wrote:
>
> > Add a generic spike machine (not tied to a version) and deprecate the
> > spike mahines that are tied to a specific version. As we can now specify
> > the CPU via the command line we no londer need specific versions of the
> > spike machines.
> >
> > Signed-off-by: Alistair Francis 
>
> For cpu and initial RAM related parts:
>
> Acked-by: Igor Mammedov 
>
> a couple of questions below.
> > ---
> >  hw/riscv/spike.c | 106 ++-
> >  1 file changed, 105 insertions(+), 1 deletion(-)
> >
> > diff --git a/hw/riscv/spike.c b/hw/riscv/spike.c
> > index 2a000a5800..9d3f7cec4d 100644
> > --- a/hw/riscv/spike.c
> > +++ b/hw/riscv/spike.c
> > @@ -39,6 +39,7 @@
> >  #include "chardev/char.h"
> >  #include "sysemu/arch_init.h"
> >  #include "sysemu/device_tree.h"
> > +#include "sysemu/qtest.h"
> >  #include "exec/address-spaces.h"
> >  #include "elf.h"
> >
> > @@ -160,7 +161,89 @@ static void create_fdt(SpikeState *s, const struct 
> > MemmapEntry *memmap,
> >  qemu_fdt_add_subnode(fdt, "/chosen");
> >  qemu_fdt_setprop_string(fdt, "/chosen", "bootargs", cmdline);
> >  }
> > - }
> > +}
> > +
> > +static void spike_board_init(MachineState *machine)
> > +{
> > +const struct MemmapEntry *memmap = spike_memmap;
> > +
> > +SpikeState *s = g_new0(SpikeState, 1);
> > +MemoryRegion *system_memory = get_system_memory();
> > +MemoryRegion *main_mem = g_new(MemoryRegion, 1);
> > +MemoryRegion *mask_rom = g_new(MemoryRegion, 1);
> > +int i;
> > +
> > +/* Initialize SOC */
> > +object_initialize_child(OBJECT(machine), "soc", >soc, 
> > sizeof(s->soc),
> > +TYPE_RISCV_HART_ARRAY, _abort, NULL);
> > +object_property_set_str(OBJECT(>soc), machine->cpu_type, "cpu-type",
> > +_abort);
> > +object_property_set_int(OBJECT(>soc), smp_cpus, "num-harts",
> > +_abort);
> > +object_property_set_bool(OBJECT(>soc), true, "realized",
> > +_abort);
> > +
> > +/* register system main memory (actual RAM) */
> > +memory_region_init_ram(main_mem, NULL, "riscv.spike.ram",
> > +   machine->ram_size, _fatal);
> do you really care about migration? if not then _nomigrate flavor would
> be more suitable.
>
> > +memory_region_add_subregion(system_memory, memmap[SPIKE_DRAM].base,
> > +main_mem);
> > +
> > +/* create device tree */
> > +create_fdt(s, memmap, machine->ram_size, machine->kernel_cmdline);
> > +
> > +/* boot rom */
> > +memory_region_init_rom(mask_rom, NULL, "riscv.spike.mrom",
> > +   memmap[SPIKE_MROM].size, _fatal);
> > +memory_region_add_subregion(system_memory, memmap[SPIKE_MROM].base,
> > +mask_rom);
> > +
> > +if (machine->kernel_filename) {
> > +load_kernel(machine->kernel_filename);
> > +}
> > +
> > +/* reset vector */
> > +uint32_t reset_vec[8] = {
> > +0x0297,  /* 1:  auipc  t0, %pcrel_hi(dtb) */
> > +0x02028593,  /* addi   a1, t0, %pcrel_lo(1b) */
> > +0xf1402573,  /* csrr   a0, mhartid  */
> > +#if defined(TARGET_RISCV32)
> > +0x0182a283,  /* lw t0, 24(t0) */
> > +#elif defined(TARGET_RISCV64)
> > +0x0182b283,  /* ld t0, 24(t0) */
> > +#endif
> > +0x00028067,  /* jr t0 */
> > +0x,
> > +memmap[SPIKE_DRAM].base, /* start: .dword DRAM_BASE */
> > +0x,
> > + /* dtb: */
> > +};
> > +
> > +/* copy in the reset vector in little_endian byte order */
> > +for (i = 0; i < sizeof(reset_vec) >> 2; i++) {
> > +reset_vec[i] = cpu_to_le32(reset_vec[i]);
> > +}
> > +rom_add_blob_fixed_as("mrom.reset", reset_vec, sizeof(reset_vec),
> > +  memmap[SPIKE_MROM].base, _space_memory);
> > +
> > +/* copy in the device tree */
> > +if (fdt_pack(s->fdt) || fdt_totalsize(s->fdt) >
> > +memmap[SPIKE_MROM].size - sizeof(reset_vec)) {
> > +error_report("not enough space to store device-tree");
> > +exit(1);
> > +}
> > +qemu_fdt_dumpdtb(s->fdt, fdt_totalsize(s->fdt));
> > +rom_add_blob_fixed_as("mrom.fdt", s->fdt, fdt_totalsize(s->fdt),
> > +  memmap[SPIKE_MROM].base + sizeof(reset_vec),
> > +  _space_memory);
> > +
> > +/* initialize HTIF using symbols found in load_kernel */
> > +htif_mm_init(system_memory, mask_rom, >soc.harts[0].env, 
> > serial_hd(0));
> > +
> > +/* Core Local Interruptor (timer and IPI) */
> > +sifive_clint_create(memmap[SPIKE_CLINT].base, 

Re: [Qemu-devel] [Qemu-trivial] [PATCH 0/4] Header cleanups

[Laurent Vivier]

On 10/04/2019 07:17, Markus Armbruster wrote:
> Peter Maydell  writes:
> 
>> On Tue, 9 Apr 2019 at 17:42, Aruna Jayasena  wrote:
>>>
>>> Yeah this is a stand alone patch.
>>
>> OK, thanks -- just wanted to check there wasn't a missing
>> bit. I think this could go in via the qemu-trivial tree
>> so I have cc'd them.
>>
>> We're in the middle of a release at the moment, but we
>> should reopen for development in a couple of weeks. If
>> this patch still hasn't gone anywhere by a week or so after
>> that then please follow up with a 'ping' to check it hasn't
>> been forgotten by accident.
> 
> Hopefully, qemu-trivial won't wait for the next development cycle to
> begin just to queue patches for it.
> 
> Regardless, patch submitters should watch their patches and inquire when
> they don't get up within a reasonable time frame.  Normally, waiting for
> two weeks feels about right.  Perhaps give it an extra week or so when
> the release circus is in town (like now).
> 

Applied to my trivial-patches branch.

Thanks,
Laurent

Re: [Qemu-devel] [Qemu-trivial] [PATCH] Update configure

[Laurent Vivier]

On 09/04/2019 07:33, Stefan Weil wrote:
> The last *.aml file was removed in commit 
> 13b1881aacc7e5018773bd545bbaf8d5476699ee.
> 
> Signed-off-by: Stefan Weil 
> ---
>  configure | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/configure b/configure
> index 1c563a7027..9c5d9a8c96 100755
> --- a/configure
> +++ b/configure
> @@ -7886,7 +7886,6 @@ LINKS="$LINKS python"
>  for bios_file in \
>  $source_path/pc-bios/*.bin \
>  $source_path/pc-bios/*.lid \
> -$source_path/pc-bios/*.aml \
>  $source_path/pc-bios/*.rom \
>  $source_path/pc-bios/*.dtb \
>  $source_path/pc-bios/*.img \
> 

Applied to my trivial-patches branch.

Thanks,
Laurent

Re: [Qemu-devel] [PATCH v3 2/4] target/mips: add or remove space to fix checkpatch errors

[Aleksandar Markovic]

> From: Jules Irenge 
> Subject: [PATCH v3 2/4] target/mips: add or remove space to fix checkpatch 
> errors
>
> Add or remove space to fix errors issued by checkpatch.pl tool
> "ERROR: spaces required around ..."
> "ERROR: space required after that"
> "ERROR: space required before the open parenthesis"
> "ERROR: space prohibited between function name and open parenthesis"
> within "target/mips/cpu.h" file.
> 
> Signed-off-by: Jules Irenge 
> ---

Hi, Jules,

I think if you merge this patch (2/4) and the next one (3/4), your series would 
be good to go.

Sincerely,
Aleksandar

Re: [Qemu-devel] [Qemu-trivial] [PATCH] qom: use object_new_with_type in object_new_with_propv

[Laurent Vivier]

On 02/04/2019 08:27, Markus Armbruster wrote:
> Stefano Garzarella  writes:
> 
>> On Mon, Mar 11, 2019 at 04:32:34PM +0800, Wei Yang wrote:
>>> Function object_new_with_propv already get the Type of the object, so we
>>> could leverage object_new_with_type here.
>>>
>>> [make check test pass]
>>>
>>> Signed-off-by: Wei Yang 
>>> ---
>>>  qom/object.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> LGTM. Just a note for future patches:
>> I think that info like "[make check test pass]" should go after the
>> three dashes to avoid to store it in the commit message.
> 
> Yes.  Whoever applies  should delete this line.
> 
>> Reviewed-by: Stefano Garzarella 
> 
> Cc: qemu-trivial for merging.
> 

Applied to my trivial-patches branch with updated commit message.

Thanks,
Laurent

Re: [Qemu-devel] [PATCH 1/2] pflash_cfi01: New pflash_cfi01_legacy_drive()

[Laszlo Ersek]

On 04/11/19 21:50, Laszlo Ersek wrote:
> On 04/11/19 21:35, Laszlo Ersek wrote:
>> On 04/11/19 15:56, Markus Armbruster wrote:
>>> Factored out of pc_system_firmware_init() so the next commit can reuse
>>> it in hw/arm/virt.c.
>>>
>>> Signed-off-by: Markus Armbruster 
>>> ---
>>>  hw/block/pflash_cfi01.c  | 30 ++
>>>  hw/i386/pc_sysfw.c   | 19 ++-
>>>  include/hw/block/flash.h |  1 +
>>>  3 files changed, 33 insertions(+), 17 deletions(-)
>>>
>>> diff --git a/hw/block/pflash_cfi01.c b/hw/block/pflash_cfi01.c
>>> index 16dfae14b8..eba01b1447 100644
>>> --- a/hw/block/pflash_cfi01.c
>>> +++ b/hw/block/pflash_cfi01.c
>>> @@ -44,9 +44,12 @@
>>>  #include "qapi/error.h"
>>>  #include "qemu/timer.h"
>>>  #include "qemu/bitops.h"
>>> +#include "qemu/error-report.h"
>>>  #include "qemu/host-utils.h"
>>>  #include "qemu/log.h"
>>> +#include "qemu/option.h"
>>>  #include "hw/sysbus.h"
>>> +#include "sysemu/blockdev.h"
>>>  #include "sysemu/sysemu.h"
>>>  #include "trace.h"
>>>  
>>> @@ -968,6 +971,33 @@ MemoryRegion *pflash_cfi01_get_memory(PFlashCFI01 *fl)
>>>  return >mem;
>>>  }
>>>  
>>> +/*
>>> + * Handle -drive if=pflash for machines that use machine properties.
>>
>> (1) Can we improve readability with quotes? "-drive if=pflash"
>>
>>> + * Map unit#i (0 < i <= @ndev) to @dev[i]'s property "drive".
>>
>> (2) I think you meant (0 <= i < @ndev)
>>
>>> + */
>>> +void pflash_cfi01_legacy_drive(PFlashCFI01 *dev[], int ndev)
>>> +{
>>> +int i;
>>
>> (3) For utter pedantry, "ndev"  and "i" should have type "size_t" (in
>> particular because we expect the caller to fill "ndev" with ARRAY_SIZE().
>>
>> But, this would go beyond refactoring -- the original "int"s have served
>> us just fine, and we're usually counting up (exclusively) to the huge
>> number... two. :)
>>
>>> +DriveInfo *dinfo;
>>> +Location loc;
>>> +
>>> +for (i = 0; i < ndev; i++) {
>>> +dinfo = drive_get(IF_PFLASH, 0, i);
>>> +if (!dinfo) {
>>> +continue;
>>> +}
>>> +loc_push_none();
>>> +qemu_opts_loc_restore(dinfo->opts);
>>> +if (dev[i]->blk) {
>>
>> (4) Is this really identical to the code being removed? The above
>> controlling expression amounts to:
>>
>>   pcms->flash[i]->blk
>>
>> but the original boils down to
>>
>>   pflash_cfi01_get_blk(pcms->flash[i])
>>
>> Hmm... looking at pflash_cfi01_get_blk(), they are the same. Is there a
>> particular reason for not using the wrapper function any longer? As in:
>>
>>   pflash_cfi01_get_blk(dev[i])
>>
>>> +error_report("clashes with -machine");
>>> +exit(1);
>>> +}
>>> +qdev_prop_set_drive(DEVICE(dev[i]), "drive",
>>> +blk_by_legacy_dinfo(dinfo), _fatal);
>>> +loc_pop();
>>> +}
>>> +}
>>> +
>>>  static void postload_update_cb(void *opaque, int running, RunState state)
>>>  {
>>>  PFlashCFI01 *pfl = opaque;
>>> diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
>>> index c628540774..d58e47184c 100644
>>> --- a/hw/i386/pc_sysfw.c
>>> +++ b/hw/i386/pc_sysfw.c
>>> @@ -269,32 +269,17 @@ void pc_system_firmware_init(PCMachineState *pcms,
>>>  {
>>>  PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
>>>  int i;
>>> -DriveInfo *pflash_drv;
>>>  BlockBackend *pflash_blk[ARRAY_SIZE(pcms->flash)];
>>> -Location loc;
>>>  
>>>  if (!pcmc->pci_enabled) {
>>>  old_pc_system_rom_init(rom_memory, true);
>>>  return;
>>>  }
>>>  
>>> -/* Map legacy -drive if=pflash to machine properties */
>>> +pflash_cfi01_legacy_drive(pcms->flash, ARRAY_SIZE(pcms->flash));
>>> +
>>>  for (i = 0; i < ARRAY_SIZE(pcms->flash); i++) {
>>>  pflash_blk[i] = pflash_cfi01_get_blk(pcms->flash[i]);
>>> -pflash_drv = drive_get(IF_PFLASH, 0, i);
>>> -if (!pflash_drv) {
>>> -continue;
>>> -}
>>> -loc_push_none();
>>> -qemu_opts_loc_restore(pflash_drv->opts);
>>> -if (pflash_blk[i]) {
>>> -error_report("clashes with -machine");
>>> -exit(1);
>>> -}
>>> -pflash_blk[i] = blk_by_legacy_dinfo(pflash_drv);
>>> -qdev_prop_set_drive(DEVICE(pcms->flash[i]),
>>> -"drive", pflash_blk[i], _fatal);
>>> -loc_pop();
>>>  }
>>
>> (5) I think you deleted too much here. After this loop, post-patch, for
>> all "i", we'll have
>>
>>   pflash_blk[i] = pflash_cfi01_get_blk(pcms->flash[i]);
>>
>> But pre-patch, for all "i" where the "continue" didn't fire, we'd end up
>> with:
>>
>>   pflash_blk[i] = blk_by_legacy_dinfo(pflash_drv);
>>
>> IOW the original loop both verifies and *collects*, for the gap check
>> that comes just below.
>>
>> IIRC, this allows for mixing "-drive if=pflash,unit=N" with the machine
>> properties, as long as you have neither conflicts, nor gaps.
>>
>> Post-patch however, this kind of mixing would break, because we'd 

Re: [Qemu-devel] [Qemu-trivial] [PATCH] configure: fix pam test warning

[Laurent Vivier]

On 04/04/2019 11:19, Daniel P. Berrangé wrote:
> CC trivial
> 
> On Thu, Apr 04, 2019 at 10:17:25AM +0100, Dr. David Alan Gilbert (git) wrote:
>> From: "Dr. David Alan Gilbert" 
>>
>> The pam test generates a warning on Fedora 29 with -O3 compilation
>> because the headers declare that the pam_conversation pointer to
>> pam_start must be non-NULL.  Change it to use the same 0 initialised
>> structure as we actually use in qauthz.
>>
>> Signed-off-by: Dr. David Alan Gilbert 
>> ---
>>  configure | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> Acked-by: Daniel P. Berrangé 
> 
>>
>> diff --git a/configure b/configure
>> index 1c563a7027..73f7ad2be0 100755
>> --- a/configure
>> +++ b/configure
>> @@ -2946,9 +2946,9 @@ if test "$auth_pam" != "no"; then
>>  int main(void) {
>> const char *service_name = "qemu";
>> const char *user = "frank";
>> -   const struct pam_conv *pam_conv = NULL;
>> +   const struct pam_conv pam_conv = { 0 };
>> pam_handle_t *pamh = NULL;
>> -   pam_start(service_name, user, pam_conv, );
>> +   pam_start(service_name, user, _conv, );
>> return 0;
>>  }
>>  EOF
> 
> Regards,
> Daniel
> 

Applied to my trivial-patches branch.

Thanks,
Laurent

Re: [Qemu-devel] [PATCH RFC 2/3] pxtool: Add new qemu-img command info generation tool

[John Snow]

On 4/11/19 2:22 AM, Markus Armbruster wrote:
> John Snow  writes:
> 
>> On 4/10/19 1:54 AM, Markus Armbruster wrote:
>>> John Snow  writes:
>>>
 Presently we use hxtool and a .hx format to generate a few things like
 the qemu_img subcommand dispatch table, the qemu_img help() display output,
 and a help output in qemu-img.texi.

 Unfortunately, this means that this information is duplicated in at least
 three places:

 (1) in qemu-img-cmds.hx as a human readable string
 (2) in qemu-img-cmds.hx as a texi string
 (3) in qemu-img.texi again, as a texi string

 We can do a little better, though: all of these sources can be generated
 from a single json file. Add a new small tool ("pxtool") that can do this.

 This tool can at least handle generating (1) and (2) from the same source
 without needing to reduplicate that information. Deduplicating (3) happens
 in the next patch.

 Notes:
  - The json format was chosen to be very "stupid", and the command line
documentation is being kept one-per-line to make future diffs easier
to read.
  - It's easy enough to generate the human-readable output from the texi
output by removing '@var{foo}' with 'foo'.
  - The qemu-img command dispatch always calls img_cmdname, so we don't
need to store this information separately, either.
  - The need for DEF() macros could be removed as well, but I left it in
to create a minimally disruptive patch.
 Signed-off-by: John Snow 
>>>
>>> We got just five .hx:
>>>
>>> qemu-img.cmds.hxkilled off by this patch
>>> qemu-options.hx CLI QAPIfication should kill this off
>>> hw/audio/pl041.hx   misnamed, not actually food for hxtool
>>> hmp-commands.hx no exit strategy
>>> hmp-commands-info.hxfor these two, yet
>>>
>>> CLI QAPIfication got stuck in the back-burner, and as long as that's the
>>> case, it's not an alternative to your patches.
>>>
>>
>> Good to know. I figure that at least while we wait on something more
>> comprehensive there's no real short term harm in tidying up.
>>
>> Something I'd really like to do is define a python/json-esque
>> configuration file that allows you to specify some "common options" that
>> are shared between all of the sub-commands, and then define each command
>> in terms of both which common options it possesses, and then any local
>> command-specific options it has.
>>
>> (Why the common options design? So that argument names and command
>> options can be encouraged to be identical and identically documented
>> between all subcommands that use them.)
> 
> In QAPI, you'd define a common base type.
> 
>> Then, from the configuration file, generate all of the necessary C
>> parsers (I have a protoype for this, it's not difficult to do in at
>> least the basic case) that can return boxed command arguments, and then
>> also generate the help strings from that metadata.
> 
> With QAPI, we generate reference documentation from the doc comments.
> 
> My RFC patches for command line QAPIfication generate a CLI parser using
> getopt_long_only().
> 
> They keep help texts in the QAPI schema.  Generating their formal part
> from the type definition should be feasible.  Generating it without
> regressing readability might turn out to be non-trivial.
> 
> My patches generate *one* CLI parser.  We have many, and some of them
> want to share types.  There's more than one way to skin this cat, but
> it'll have to be skinned.
> 
>> I suspect that work *IS* something that might brush up against / should
>> use (or extend) QAPI code.
> 
> Seems likely.
> 
>> Then, I'd like to find a way to split qemu-img.texi into sub-command
>> files and find a way to source the same "informative text" for both:
>>
>> (1) The texi output, as per usual, and
>> (2) qemu-img subcommand --help
>>
>> such that --help, when passed as an argument to the subcommand, prints
>> out help only relevant to the subcommand instead, e.g.
>>
>> `qemu-img check --help`
>>
>> might print the "common options" section only as it relates to commands
>> actually used by the check command, then prints the check section of the
>> texi as formatted for terminals.
>>
>> This way, we can have manpages, html pages, and interactive help text
>> all derived from the same semi-automated sources, always up to date and
>> much easier to read/discover/parse by human eyeballs.
>>
>> That's what I'd like to accomplish, ultimately.
>>
>> For now, I think this RFC set is not harmful and won't bother anybody.
>> It's definitely not worse than what we have now, fragility of removing
>> @var{} tokens and all.
> 
> Makes sense.  I just hope we can avoid duplicating work.
> 

I'm not going to proceed any further than this RFC without us having a
meeting to discuss the work. I'm willing to learn QAPI and do it a bit,
it's a thread I'd rather like to pull, but I don't want 

Re: [Qemu-devel] [Qemu-trivial] [PATCH] doc: fix the configuration path

[Laurent Vivier]

On 30/03/2019 17:30, Thomas Huth wrote:
> On 07/02/2019 17.31, Philippe Mathieu-Daudé wrote:
>> On 11/26/18 11:51 AM, Marc-André Lureau wrote:
>>> Use a CONFDIR variable to show the configured sysconf path in the
>>> generated documentations (html, man pages etc).
>>>
>>> Related to:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1644985
>>>
>>> Signed-off-by: Marc-André Lureau 
>>
>> Reviewed-by: Philippe Mathieu-Daudé 
>>
>>> ---
>>>  Makefile | 9 ++---
>>>  qemu-ga.texi | 4 ++--
>>>  2 files changed, 8 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/Makefile b/Makefile
>>> index 9cc4dae1a6..a39c231d1c 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -932,11 +932,14 @@ ui/shader.o: $(SRC_PATH)/ui/shader.c \
>>>  MAKEINFO=makeinfo
>>>  MAKEINFOINCLUDES= -I docs -I $(>>  MAKEINFOFLAGS=--no-split --number-sections $(MAKEINFOINCLUDES)
>>> -TEXI2PODFLAGS=$(MAKEINFOINCLUDES) "-DVERSION=$(VERSION)"
>>> +TEXI2PODFLAGS=$(MAKEINFOINCLUDES) -DVERSION="$(VERSION)" 
>>> -DCONFDIR="$(qemu_confdir)"
>>>  TEXI2PDFFLAGS=$(if $(V),,--quiet) -I $(SRC_PATH) $(MAKEINFOINCLUDES)
>>>  
>>> -docs/version.texi: $(SRC_PATH)/VERSION
>>> -   $(call quiet-command,echo "@set VERSION $(VERSION)" > $@,"GEN","$@")
>>> +docs/version.texi: $(SRC_PATH)/VERSION config-host.mak
>>> +   $(call quiet-command,(\
>>> +   echo "@set VERSION $(VERSION)" && \
>>> +   echo "@set CONFDIR $(qemu_confdir)" \
>>> +   )> $@,"GEN","$@")
>>>  
>>>  %.html: %.texi docs/version.texi
>>> $(call quiet-command,LC_ALL=C $(MAKEINFO) $(MAKEINFOFLAGS) --no-headers 
>>> \
>>> diff --git a/qemu-ga.texi b/qemu-ga.texi
>>> index 4c7a8fd163..f00ad830f2 100644
>>> --- a/qemu-ga.texi
>>> +++ b/qemu-ga.texi
>>> @@ -30,7 +30,7 @@ set user's password
>>>  @end itemize
>>>  
>>>  qemu-ga will read a system configuration file on startup (located at
>>> -@file{/etc/qemu/qemu-ga.conf} by default), then parse remaining
>>> +@file{@value{CONFDIR}/qemu-ga.conf} by default), then parse remaining
>>>  configuration options on the command line. For the same key, the last
>>>  option wins, but the lists accumulate (see below for configuration
>>>  file format).
>>> @@ -58,7 +58,7 @@ file format).
>>>Enable fsfreeze hook. Accepts an optional argument that specifies
>>>script to run on freeze/thaw. Script will be called with
>>>'freeze'/'thaw' arguments accordingly (default is
>>> -  @samp{/etc/qemu/fsfreeze-hook}). If using -F with an argument, do
>>> +  @samp{@value{CONFDIR}/fsfreeze-hook}). If using -F with an argument, do
>>>not follow -F with a space (for example:
>>>@samp{-F/var/run/fsfreezehook.sh}).
> 
> Ping^2
> 
> I think this could also go via qemu-trivial...?
> 
>  Thomas
> 

Applied to my trivial-patches branch.

Thanks,
Laurent

Re: [Qemu-devel] [Qemu-trivial] [PATCH v2 1/2] block/vhdx: Remove redundant IEC binary prefixes definition

[Laurent Vivier]

On 11/04/2019 21:54, Laurent Vivier wrote:
> On 27/03/2019 10:56, Stefano Garzarella wrote:
>> IEC binary prefixes are already defined in "qemu/units.h",
>> so we can remove redundant definitions in "block/vhdx.h".
>>
>> Signed-off-by: Stefano Garzarella 
>> ---
>>  block/vhdx.c | 3 ++-
>>  block/vhdx.h | 6 +-
>>  2 files changed, 3 insertions(+), 6 deletions(-)
>>
>> diff --git a/block/vhdx.c b/block/vhdx.c
>> index b785aef4b7..7cd1fc3731 100644
>> --- a/block/vhdx.c
>> +++ b/block/vhdx.c
>> @@ -1889,7 +1889,8 @@ static int coroutine_fn 
>> vhdx_co_create(BlockdevCreateOptions *opts,
>>  return -EINVAL;
>>  }
>>  if (block_size > VHDX_BLOCK_SIZE_MAX) {
>> -error_setg(errp, "Block size must not exceed %d", 
>> VHDX_BLOCK_SIZE_MAX);
>> +error_setg(errp, "Block size must not exceed %" PRId64,
>> +   VHDX_BLOCK_SIZE_MAX);
>>  return -EINVAL;
>>  }
>>  
>> diff --git a/block/vhdx.h b/block/vhdx.h
>> index 1bfb4e4f73..bf72090c8f 100644
>> --- a/block/vhdx.h
>> +++ b/block/vhdx.h
>> @@ -17,11 +17,7 @@
>>  
>>  #ifndef BLOCK_VHDX_H
>>  #define BLOCK_VHDX_H
>> -
>> -#define KiB  (1 * 1024)
>> -#define MiB(KiB * 1024)
>> -#define GiB(MiB * 1024)
>> -#define TiB ((uint64_t) GiB * 1024)
>> +#include "qemu/units.h"
>>  
>>  #define DEFAULT_LOG_SIZE 1048576 /* 1MiB */
>>  /* Structures and fields present in the VHDX file */
>>
> 
> Applied to my trivial-patches branch.

Removed as Kevin already applied it to block-next.

Thanks,
Laurent

Re: [Qemu-devel] [Qemu-trivial] [PATCH v2 1/2] block/vhdx: Remove redundant IEC binary prefixes definition

[Laurent Vivier]

On 27/03/2019 10:56, Stefano Garzarella wrote:
> IEC binary prefixes are already defined in "qemu/units.h",
> so we can remove redundant definitions in "block/vhdx.h".
> 
> Signed-off-by: Stefano Garzarella 
> ---
>  block/vhdx.c | 3 ++-
>  block/vhdx.h | 6 +-
>  2 files changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/block/vhdx.c b/block/vhdx.c
> index b785aef4b7..7cd1fc3731 100644
> --- a/block/vhdx.c
> +++ b/block/vhdx.c
> @@ -1889,7 +1889,8 @@ static int coroutine_fn 
> vhdx_co_create(BlockdevCreateOptions *opts,
>  return -EINVAL;
>  }
>  if (block_size > VHDX_BLOCK_SIZE_MAX) {
> -error_setg(errp, "Block size must not exceed %d", 
> VHDX_BLOCK_SIZE_MAX);
> +error_setg(errp, "Block size must not exceed %" PRId64,
> +   VHDX_BLOCK_SIZE_MAX);
>  return -EINVAL;
>  }
>  
> diff --git a/block/vhdx.h b/block/vhdx.h
> index 1bfb4e4f73..bf72090c8f 100644
> --- a/block/vhdx.h
> +++ b/block/vhdx.h
> @@ -17,11 +17,7 @@
>  
>  #ifndef BLOCK_VHDX_H
>  #define BLOCK_VHDX_H
> -
> -#define KiB  (1 * 1024)
> -#define MiB(KiB * 1024)
> -#define GiB(MiB * 1024)
> -#define TiB ((uint64_t) GiB * 1024)
> +#include "qemu/units.h"
>  
>  #define DEFAULT_LOG_SIZE 1048576 /* 1MiB */
>  /* Structures and fields present in the VHDX file */
> 

Applied to my trivial-patches branch.

Thanks,
Laurent

Re: [Qemu-devel] [PATCH 1/2] pflash_cfi01: New pflash_cfi01_legacy_drive()

[Laszlo Ersek]

On 04/11/19 21:35, Laszlo Ersek wrote:
> On 04/11/19 15:56, Markus Armbruster wrote:
>> Factored out of pc_system_firmware_init() so the next commit can reuse
>> it in hw/arm/virt.c.
>>
>> Signed-off-by: Markus Armbruster 
>> ---
>>  hw/block/pflash_cfi01.c  | 30 ++
>>  hw/i386/pc_sysfw.c   | 19 ++-
>>  include/hw/block/flash.h |  1 +
>>  3 files changed, 33 insertions(+), 17 deletions(-)
>>
>> diff --git a/hw/block/pflash_cfi01.c b/hw/block/pflash_cfi01.c
>> index 16dfae14b8..eba01b1447 100644
>> --- a/hw/block/pflash_cfi01.c
>> +++ b/hw/block/pflash_cfi01.c
>> @@ -44,9 +44,12 @@
>>  #include "qapi/error.h"
>>  #include "qemu/timer.h"
>>  #include "qemu/bitops.h"
>> +#include "qemu/error-report.h"
>>  #include "qemu/host-utils.h"
>>  #include "qemu/log.h"
>> +#include "qemu/option.h"
>>  #include "hw/sysbus.h"
>> +#include "sysemu/blockdev.h"
>>  #include "sysemu/sysemu.h"
>>  #include "trace.h"
>>  
>> @@ -968,6 +971,33 @@ MemoryRegion *pflash_cfi01_get_memory(PFlashCFI01 *fl)
>>  return >mem;
>>  }
>>  
>> +/*
>> + * Handle -drive if=pflash for machines that use machine properties.
> 
> (1) Can we improve readability with quotes? "-drive if=pflash"
> 
>> + * Map unit#i (0 < i <= @ndev) to @dev[i]'s property "drive".
> 
> (2) I think you meant (0 <= i < @ndev)
> 
>> + */
>> +void pflash_cfi01_legacy_drive(PFlashCFI01 *dev[], int ndev)
>> +{
>> +int i;
> 
> (3) For utter pedantry, "ndev"  and "i" should have type "size_t" (in
> particular because we expect the caller to fill "ndev" with ARRAY_SIZE().
> 
> But, this would go beyond refactoring -- the original "int"s have served
> us just fine, and we're usually counting up (exclusively) to the huge
> number... two. :)
> 
>> +DriveInfo *dinfo;
>> +Location loc;
>> +
>> +for (i = 0; i < ndev; i++) {
>> +dinfo = drive_get(IF_PFLASH, 0, i);
>> +if (!dinfo) {
>> +continue;
>> +}
>> +loc_push_none();
>> +qemu_opts_loc_restore(dinfo->opts);
>> +if (dev[i]->blk) {
> 
> (4) Is this really identical to the code being removed? The above
> controlling expression amounts to:
> 
>   pcms->flash[i]->blk
> 
> but the original boils down to
> 
>   pflash_cfi01_get_blk(pcms->flash[i])
> 
> Hmm... looking at pflash_cfi01_get_blk(), they are the same. Is there a
> particular reason for not using the wrapper function any longer? As in:
> 
>   pflash_cfi01_get_blk(dev[i])
> 
>> +error_report("clashes with -machine");
>> +exit(1);
>> +}
>> +qdev_prop_set_drive(DEVICE(dev[i]), "drive",
>> +blk_by_legacy_dinfo(dinfo), _fatal);
>> +loc_pop();
>> +}
>> +}
>> +
>>  static void postload_update_cb(void *opaque, int running, RunState state)
>>  {
>>  PFlashCFI01 *pfl = opaque;
>> diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
>> index c628540774..d58e47184c 100644
>> --- a/hw/i386/pc_sysfw.c
>> +++ b/hw/i386/pc_sysfw.c
>> @@ -269,32 +269,17 @@ void pc_system_firmware_init(PCMachineState *pcms,
>>  {
>>  PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
>>  int i;
>> -DriveInfo *pflash_drv;
>>  BlockBackend *pflash_blk[ARRAY_SIZE(pcms->flash)];
>> -Location loc;
>>  
>>  if (!pcmc->pci_enabled) {
>>  old_pc_system_rom_init(rom_memory, true);
>>  return;
>>  }
>>  
>> -/* Map legacy -drive if=pflash to machine properties */
>> +pflash_cfi01_legacy_drive(pcms->flash, ARRAY_SIZE(pcms->flash));
>> +
>>  for (i = 0; i < ARRAY_SIZE(pcms->flash); i++) {
>>  pflash_blk[i] = pflash_cfi01_get_blk(pcms->flash[i]);
>> -pflash_drv = drive_get(IF_PFLASH, 0, i);
>> -if (!pflash_drv) {
>> -continue;
>> -}
>> -loc_push_none();
>> -qemu_opts_loc_restore(pflash_drv->opts);
>> -if (pflash_blk[i]) {
>> -error_report("clashes with -machine");
>> -exit(1);
>> -}
>> -pflash_blk[i] = blk_by_legacy_dinfo(pflash_drv);
>> -qdev_prop_set_drive(DEVICE(pcms->flash[i]),
>> -"drive", pflash_blk[i], _fatal);
>> -loc_pop();
>>  }
> 
> (5) I think you deleted too much here. After this loop, post-patch, for
> all "i", we'll have
> 
>   pflash_blk[i] = pflash_cfi01_get_blk(pcms->flash[i]);
> 
> But pre-patch, for all "i" where the "continue" didn't fire, we'd end up
> with:
> 
>   pflash_blk[i] = blk_by_legacy_dinfo(pflash_drv);
> 
> IOW the original loop both verifies and *collects*, for the gap check
> that comes just below.
> 
> IIRC, this allows for mixing "-drive if=pflash,unit=N" with the machine
> properties, as long as you have neither conflicts, nor gaps.
> 
> Post-patch however, this kind of mixing would break, because we'd report
> gaps for the legacy ("-drive if=pflash") options.
> 
> 
> In addition, it could break the "use ROM mode" branch below, which is
> based on pflash_blk[0].
> 
> I 

Re: [Qemu-devel] [Qemu-trivial] [PATCH v6 2/2] CODING_STYLE: indent example code as all others

[Laurent Vivier]

On 04/03/2019 08:16, Wei Yang wrote:
> All the example code are indented with four spaces except this one.
> 
> Fix this by adding four spaces here.
> 
> Signed-off-by: Wei Yang 
> Reviewed-by: Eric Blake 
> Reviewed-by: Philippe Mathieu-Daudé 
> Reviewed-by: Igor Mammedov 
> ---
>  CODING_STYLE | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/CODING_STYLE b/CODING_STYLE
> index 90321e9c28..cb8edcbb36 100644
> --- a/CODING_STYLE
> +++ b/CODING_STYLE
> @@ -147,10 +147,10 @@ block to a separate function altogether.
>  When comparing a variable for (in)equality with a constant, list the
>  constant on the right, as in:
>  
> -if (a == 1) {
> -/* Reads like: "If a equals 1" */
> -do_something();
> -}
> +if (a == 1) {
> +/* Reads like: "If a equals 1" */
> +do_something();
> +}
>  
>  Rationale: Yoda conditions (as in 'if (1 == a)') are awkward to read.
>  Besides, good compilers already warn users when '==' is mis-typed as '=',
> 

Applied to my trivial-patches branch.

Thanks,
Laurent

Re: [Qemu-devel] [Qemu-trivial] [PATCH] Clean up includes

[Laurent Vivier]

On 21/03/2019 10:21, Thomas Huth wrote:
> On 13/03/2019 17.28, Markus Armbruster wrote:
>> Clean up includes so that osdep.h is included first and headers
>> which it implies are not included manually.
>>
>> This commit was created with scripts/clean-includes, with the changes
>> to the following files manually reverted:
>>
>> contrib/libvhost-user/libvhost-user-glib.h
>> contrib/libvhost-user/libvhost-user.c
>> contrib/libvhost-user/libvhost-user.h
>> linux-user/mips64/cpu_loop.c
>> linux-user/mips64/signal.c
>> linux-user/sparc64/cpu_loop.c
>> linux-user/sparc64/signal.c
>> linux-user/x86_64/cpu_loop.c
>> linux-user/x86_64/signal.c
>> slirp/src/*
>> target/s390x/gen-features.c
>> tests/migration/s390x/a-b-bios.c
>> tests/test-rcu-simpleq.c
>> tests/test-rcu-tailq.c
>> tests/uefi-test-tools/UefiTestToolsPkg/BiosTablesTest/BiosTablesTest.c
>>
>> We're in the process of spinning out slirp/.  tests/uefi-test-tools/
>> is guest software.  The remaining reverts are the same as in commit
>> b7d89466dde.
>>
>> Signed-off-by: Markus Armbruster 
>> ---
>>  contrib/elf2dmp/main.c   | 3 +--
>>  contrib/elf2dmp/pdb.c| 3 +--
>>  hw/display/ati.c | 1 +
>>  hw/display/ati_2d.c  | 1 +
>>  hw/display/ati_dbg.c | 1 +
>>  hw/display/ati_int.h | 1 -
>>  include/hw/cpu/cluster.h | 1 -
>>  tests/fp/platform.h  | 1 -
>>  tests/libqos/qgraph.h| 4 
>>  tests/qos-test.c | 2 +-
>>  10 files changed, 6 insertions(+), 12 deletions(-)
> 
> Reviewed-by: Thomas Huth 
> 


Applied to my trivial-patches branch.

Thanks,
Laurent

Re: [Qemu-devel] [PATCH for-4.1] hw/input: Add a CONFIG_PS2 switch for the ps2.c file

[Philippe Mathieu-Daudé]

On 4/11/19 8:22 PM, Thomas Huth wrote:
> ps2.c only needs to be compiled if we are building pckbd.c or pl050.c.

Hehe I have the same patch staged locally =)

> Signed-off-by: Thomas Huth 

Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 

> ---
>  hw/input/Kconfig   | 5 +
>  hw/input/Makefile.objs | 2 +-
>  2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/input/Kconfig b/hw/input/Kconfig
> index e2e66f0858..316573f782 100644
> --- a/hw/input/Kconfig
> +++ b/hw/input/Kconfig
> @@ -8,10 +8,15 @@ config LM832X
>  config PCKBD
>  bool
>  default y
> +select PS2
>  depends on ISA_BUS
>  
>  config PL050
>  bool
> +select PS2
> +
> +config PS2
> +bool
>  
>  config STELLARIS_INPUT
>  bool
> diff --git a/hw/input/Makefile.objs b/hw/input/Makefile.objs
> index c8b00f71ec..6db5ee0e71 100644
> --- a/hw/input/Makefile.objs
> +++ b/hw/input/Makefile.objs
> @@ -3,7 +3,7 @@ common-obj-y += hid.o
>  common-obj-$(CONFIG_LM832X) += lm832x.o
>  common-obj-$(CONFIG_PCKBD) += pckbd.o
>  common-obj-$(CONFIG_PL050) += pl050.o
> -common-obj-y += ps2.o
> +common-obj-$(CONFIG_PS2) += ps2.o
>  common-obj-$(CONFIG_STELLARIS_INPUT) += stellaris_input.o
>  common-obj-$(CONFIG_TSC2005) += tsc2005.o
>  
> 

Re: [Qemu-devel] [Qemu-trivial] [PATCH v6 1/2] CODING_STYLE: specify the indent rule for multiline code

[Laurent Vivier]

On 04/03/2019 08:16, Wei Yang wrote:
> We didn't specify the indent rule for multiline code here, which may
> mislead users. And in current code, the code use various styles.
> 
> Add this rule in CODING_STYLE to make sure this is clear to every one.
> 
> Signed-off-by: Wei Yang 
> Suggested-by: Igor Mammedov 
> 
> ---
> v6:
>* add ) for last example of function
> v5:
>* different rules -> various styles
>* describe function variants separately
>* take struct out
> v4:
>* widths -> width
>* add an exception example for function
> v3:
>* misleading -> mislead
>* add comma after arg2 in example
> v2:
>* rephrase changelog suggested by Eric Blake
>  - remove one redundant line
>  - fix some awkward grammar
>  - add { ; at the end of example
> ---
>  CODING_STYLE | 39 +++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/CODING_STYLE b/CODING_STYLE
> index ec075dedc4..90321e9c28 100644
> --- a/CODING_STYLE
> +++ b/CODING_STYLE
> @@ -29,6 +29,45 @@ Spaces of course are superior to tabs because:
>  
>  Do not leave whitespace dangling off the ends of lines.
>  
> +1.1 Multiline Indent
> +
> +There are several places where indent is necessary:
> +
> + - if/else
> + - while/for
> + - function definition & call
> +
> +When breaking up a long line to fit within line width, we need a proper 
> indent
> +for the following lines.
> +
> +In case of if/else, while/for, align the secondary lines just after the
> +opening parenthesis of the first.
> +
> +For example:
> +
> +if (a == 1 &&
> +b == 2) {
> +
> +while (a == 1 &&
> +   b == 2) {
> +
> +In case of function, there are several variants:
> +
> +* 4 spaces indent from the beginning
> +* align the secondary lines just after the opening parenthesis of the
> +  first
> +
> +For example:
> +
> +do_something(x, y,
> +z);
> +
> +do_something(x, y,
> + z);
> +
> +do_something(x, do_another(y,
> +   z));
> +
>  2. Line width
>  
>  Lines should be 80 characters; try not to make them longer.
> 

Applied to my trivial-patches branch.

Thanks,
Laurent

Re: [Qemu-devel] [PATCH 1/2] pflash_cfi01: New pflash_cfi01_legacy_drive()

[Laszlo Ersek]

On 04/11/19 15:56, Markus Armbruster wrote:
> Factored out of pc_system_firmware_init() so the next commit can reuse
> it in hw/arm/virt.c.
> 
> Signed-off-by: Markus Armbruster 
> ---
>  hw/block/pflash_cfi01.c  | 30 ++
>  hw/i386/pc_sysfw.c   | 19 ++-
>  include/hw/block/flash.h |  1 +
>  3 files changed, 33 insertions(+), 17 deletions(-)
> 
> diff --git a/hw/block/pflash_cfi01.c b/hw/block/pflash_cfi01.c
> index 16dfae14b8..eba01b1447 100644
> --- a/hw/block/pflash_cfi01.c
> +++ b/hw/block/pflash_cfi01.c
> @@ -44,9 +44,12 @@
>  #include "qapi/error.h"
>  #include "qemu/timer.h"
>  #include "qemu/bitops.h"
> +#include "qemu/error-report.h"
>  #include "qemu/host-utils.h"
>  #include "qemu/log.h"
> +#include "qemu/option.h"
>  #include "hw/sysbus.h"
> +#include "sysemu/blockdev.h"
>  #include "sysemu/sysemu.h"
>  #include "trace.h"
>  
> @@ -968,6 +971,33 @@ MemoryRegion *pflash_cfi01_get_memory(PFlashCFI01 *fl)
>  return >mem;
>  }
>  
> +/*
> + * Handle -drive if=pflash for machines that use machine properties.

(1) Can we improve readability with quotes? "-drive if=pflash"

> + * Map unit#i (0 < i <= @ndev) to @dev[i]'s property "drive".

(2) I think you meant (0 <= i < @ndev)

> + */
> +void pflash_cfi01_legacy_drive(PFlashCFI01 *dev[], int ndev)
> +{
> +int i;

(3) For utter pedantry, "ndev"  and "i" should have type "size_t" (in
particular because we expect the caller to fill "ndev" with ARRAY_SIZE().

But, this would go beyond refactoring -- the original "int"s have served
us just fine, and we're usually counting up (exclusively) to the huge
number... two. :)

> +DriveInfo *dinfo;
> +Location loc;
> +
> +for (i = 0; i < ndev; i++) {
> +dinfo = drive_get(IF_PFLASH, 0, i);
> +if (!dinfo) {
> +continue;
> +}
> +loc_push_none();
> +qemu_opts_loc_restore(dinfo->opts);
> +if (dev[i]->blk) {

(4) Is this really identical to the code being removed? The above
controlling expression amounts to:

  pcms->flash[i]->blk

but the original boils down to

  pflash_cfi01_get_blk(pcms->flash[i])

Hmm... looking at pflash_cfi01_get_blk(), they are the same. Is there a
particular reason for not using the wrapper function any longer? As in:

  pflash_cfi01_get_blk(dev[i])

> +error_report("clashes with -machine");
> +exit(1);
> +}
> +qdev_prop_set_drive(DEVICE(dev[i]), "drive",
> +blk_by_legacy_dinfo(dinfo), _fatal);
> +loc_pop();
> +}
> +}
> +
>  static void postload_update_cb(void *opaque, int running, RunState state)
>  {
>  PFlashCFI01 *pfl = opaque;
> diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
> index c628540774..d58e47184c 100644
> --- a/hw/i386/pc_sysfw.c
> +++ b/hw/i386/pc_sysfw.c
> @@ -269,32 +269,17 @@ void pc_system_firmware_init(PCMachineState *pcms,
>  {
>  PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
>  int i;
> -DriveInfo *pflash_drv;
>  BlockBackend *pflash_blk[ARRAY_SIZE(pcms->flash)];
> -Location loc;
>  
>  if (!pcmc->pci_enabled) {
>  old_pc_system_rom_init(rom_memory, true);
>  return;
>  }
>  
> -/* Map legacy -drive if=pflash to machine properties */
> +pflash_cfi01_legacy_drive(pcms->flash, ARRAY_SIZE(pcms->flash));
> +
>  for (i = 0; i < ARRAY_SIZE(pcms->flash); i++) {
>  pflash_blk[i] = pflash_cfi01_get_blk(pcms->flash[i]);
> -pflash_drv = drive_get(IF_PFLASH, 0, i);
> -if (!pflash_drv) {
> -continue;
> -}
> -loc_push_none();
> -qemu_opts_loc_restore(pflash_drv->opts);
> -if (pflash_blk[i]) {
> -error_report("clashes with -machine");
> -exit(1);
> -}
> -pflash_blk[i] = blk_by_legacy_dinfo(pflash_drv);
> -qdev_prop_set_drive(DEVICE(pcms->flash[i]),
> -"drive", pflash_blk[i], _fatal);
> -loc_pop();
>  }

(5) I think you deleted too much here. After this loop, post-patch, for
all "i", we'll have

  pflash_blk[i] = pflash_cfi01_get_blk(pcms->flash[i]);

But pre-patch, for all "i" where the "continue" didn't fire, we'd end up
with:

  pflash_blk[i] = blk_by_legacy_dinfo(pflash_drv);

IOW the original loop both verifies and *collects*, for the gap check
that comes just below.

IIRC, this allows for mixing "-drive if=pflash,unit=N" with the machine
properties, as long as you have neither conflicts, nor gaps.

Post-patch however, this kind of mixing would break, because we'd report
gaps for the legacy ("-drive if=pflash") options.


In addition, it could break the "use ROM mode" branch below, which is
based on pflash_blk[0].

I think we should extend pflash_cfi01_legacy_drive() to populate
"pflash_blk[0..(ndev-1)]" on output (assuming pflash_blk is not NULL on
input).

(Because, I'm assuming that qdev_prop_set_drive() -- which now occurs in
the factored-out loop 

Re: [Qemu-devel] [Qemu-ppc] [PATCH for-4.1] hw: add compat machines for 4.1

[Greg Kurz]

On Thu, 11 Apr 2019 12:20:25 +0200
Cornelia Huck  wrote:

> Add 4.1 machine types for arm/i440fx/q35/s390x/spapr.
> 
> Signed-off-by: Cornelia Huck 
> ---
> 

For spapr part:

Acked-by: Greg Kurz 

> IIRC, we agreed last time that we want to merge a patch introducing
> the new compat machines first thing in a new development cycle. So
> here's that patch for 4.1.
> 
> ---
>  hw/arm/virt.c  |  9 -
>  hw/core/machine.c  |  3 +++
>  hw/i386/pc.c   |  3 +++
>  hw/i386/pc_piix.c  | 14 +-
>  hw/i386/pc_q35.c   | 13 -
>  hw/ppc/spapr.c | 15 +--
>  hw/s390x/s390-virtio-ccw.c | 14 +-
>  include/hw/boards.h|  3 +++
>  include/hw/i386/pc.h   |  3 +++
>  9 files changed, 71 insertions(+), 6 deletions(-)
> 
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index ce2664a30b7f..16ba67f7a768 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -1978,10 +1978,17 @@ static void machvirt_machine_init(void)
>  }
>  type_init(machvirt_machine_init);
>  
> +static void virt_machine_4_1_options(MachineClass *mc)
> +{
> +}
> +DEFINE_VIRT_MACHINE_AS_LATEST(4, 1)
> +
>  static void virt_machine_4_0_options(MachineClass *mc)
>  {
> +virt_machine_4_1_options(mc);
> +compat_props_add(mc->compat_props, hw_compat_4_0, hw_compat_4_0_len);
>  }
> -DEFINE_VIRT_MACHINE_AS_LATEST(4, 0)
> +DEFINE_VIRT_MACHINE(4, 0)
>  
>  static void virt_machine_3_1_options(MachineClass *mc)
>  {
> diff --git a/hw/core/machine.c b/hw/core/machine.c
> index 743fef28982c..5d046a43e3d2 100644
> --- a/hw/core/machine.c
> +++ b/hw/core/machine.c
> @@ -24,6 +24,9 @@
>  #include "hw/pci/pci.h"
>  #include "hw/mem/nvdimm.h"
>  
> +GlobalProperty hw_compat_4_0[] = {};
> +const size_t hw_compat_4_0_len = G_N_ELEMENTS(hw_compat_4_0);
> +
>  GlobalProperty hw_compat_3_1[] = {
>  { "pcie-root-port", "x-speed", "2_5" },
>  { "pcie-root-port", "x-width", "1" },
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index f2c15bf1f2c3..868303cf6427 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -115,6 +115,9 @@ struct hpet_fw_config hpet_cfg = {.count = UINT8_MAX};
>  /* Physical Address of PVH entry point read from kernel ELF NOTE */
>  static size_t pvh_start_addr;
>  
> +GlobalProperty pc_compat_4_0[] ={};
> +const size_t pc_compat_4_0_len = G_N_ELEMENTS(pc_compat_4_0);
> +
>  GlobalProperty pc_compat_3_1[] = {
>  { "intel-iommu", "dma-drain", "off" },
>  { "Opteron_G3" "-" TYPE_X86_CPU, "rdtscp", "off" },
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index 8ad8e885c6b1..2a7700b564d3 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -428,13 +428,25 @@ static void pc_i440fx_machine_options(MachineClass *m)
>  machine_class_allow_dynamic_sysbus_dev(m, TYPE_RAMFB_DEVICE);
>  }
>  
> -static void pc_i440fx_4_0_machine_options(MachineClass *m)
> +static void pc_i440fx_4_1_machine_options(MachineClass *m)
>  {
>  pc_i440fx_machine_options(m);
>  m->alias = "pc";
>  m->is_default = 1;
>  }
>  
> +DEFINE_I440FX_MACHINE(v4_1, "pc-i440fx-4.1", NULL,
> +  pc_i440fx_4_1_machine_options);
> +
> +static void pc_i440fx_4_0_machine_options(MachineClass *m)
> +{
> +pc_i440fx_4_1_machine_options(m);
> +m->alias = NULL;
> +m->is_default = 0;
> +compat_props_add(m->compat_props, hw_compat_4_0, hw_compat_4_0_len);
> +compat_props_add(m->compat_props, pc_compat_4_0, pc_compat_4_0_len);
> +}
> +
>  DEFINE_I440FX_MACHINE(v4_0, "pc-i440fx-4.0", NULL,
>pc_i440fx_4_0_machine_options);
>  
> diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
> index 372c6b73bebd..37dd350511a9 100644
> --- a/hw/i386/pc_q35.c
> +++ b/hw/i386/pc_q35.c
> @@ -365,12 +365,23 @@ static void pc_q35_machine_options(MachineClass *m)
>  m->max_cpus = 288;
>  }
>  
> -static void pc_q35_4_0_machine_options(MachineClass *m)
> +static void pc_q35_4_1_machine_options(MachineClass *m)
>  {
>  pc_q35_machine_options(m);
>  m->alias = "q35";
>  }
>  
> +DEFINE_Q35_MACHINE(v4_1, "pc-q35-4.1", NULL,
> +   pc_q35_4_1_machine_options);
> +
> +static void pc_q35_4_0_machine_options(MachineClass *m)
> +{
> +pc_q35_4_1_machine_options(m);
> +m->alias = NULL;
> +compat_props_add(m->compat_props, hw_compat_4_0, hw_compat_4_0_len);
> +compat_props_add(m->compat_props, pc_compat_4_0, pc_compat_4_0_len);
> +}
> +
>  DEFINE_Q35_MACHINE(v4_0, "pc-q35-4.0", NULL,
> pc_q35_4_0_machine_options);
>  
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index b52b82d298ef..8438741ec23c 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -4344,15 +4344,26 @@ static const TypeInfo spapr_machine_info = {
>  }\
>  type_init(spapr_machine_register_##suffix)
>  
> +/*
> + * pseries-4.1
> + */
> +static void spapr_machine_4_1_class_options(MachineClass *mc)
> +{
> +/* 

Re: [Qemu-devel] [PATCH] target/i386: sev: add 'sev-max-guests' field to 'query-sev-capabilities'

[Singh, Brijesh]

On 4/11/19 1:10 PM, Laszlo Ersek wrote:
> On 04/11/19 19:59, Singh, Brijesh wrote:
>> There are limited numbers of the SEV guests that can be run concurrently.
>> A management applications may need to know this limit so that it can place
>> SEV VMs on hosts which have suitable resources available.
>>
>> Currently, this limit is not exposed to the application. Add a new
>> 'sev-max-guest' field in the query-sev-capabilities to provide this
>> information.
>>
>> Cc: Paolo Bonzini 
>> Cc: Markus Armbruster 
>> Cc: Eric Blake 
>> Cc: Daniel P. Berrangé 
>> Cc: Laszlo Ersek 
>> Cc: Erik Skultety 
>> Signed-off-by: Brijesh Singh 
>> ---
>>   qapi/target.json  | 6 --
>>   target/i386/sev.c | 6 --
>>   2 files changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/qapi/target.json b/qapi/target.json
>> index 1d4d54b600..b45121d30b 100644
>> --- a/qapi/target.json
>> +++ b/qapi/target.json
>> @@ -183,7 +183,8 @@
>> 'data': { 'pdh': 'str',
>>   'cert-chain': 'str',
>>   'cbitpos': 'int',
>> -'reduced-phys-bits': 'int'},
>> +'reduced-phys-bits': 'int',
>> +'sev-max-guests': 'int'},
> 
> Would it be useful to make this new field optional? E.g. if it was
> missing, libvirtd could assume "no limit".
> 

I am not sure if we need to make this field optional - mainly because
in SEV context hardware will always have some limits (at least in
foreseeable future). The architecture provides us a CPUID to query
this capabilities so I am assuming that future CPUs will populate
some values in it.

> Again, not sure if that's useful, but it's not hard to introduce the
> field as optional now. Removing mandatory fields later is impossible.
> 

Re: [Qemu-devel] [PATCH] target/i386: sev: add 'sev-max-guests' field to 'query-sev-capabilities'

[Laszlo Ersek]

On 04/11/19 20:10, Laszlo Ersek wrote:
> On 04/11/19 19:59, Singh, Brijesh wrote:
>> There are limited numbers of the SEV guests that can be run concurrently.
>> A management applications may need to know this limit so that it can place
>> SEV VMs on hosts which have suitable resources available.
>>
>> Currently, this limit is not exposed to the application. Add a new
>> 'sev-max-guest' field in the query-sev-capabilities to provide this
>> information.
>>
>> Cc: Paolo Bonzini 
>> Cc: Markus Armbruster 
>> Cc: Eric Blake 
>> Cc: Daniel P. Berrangé 
>> Cc: Laszlo Ersek 
>> Cc: Erik Skultety 
>> Signed-off-by: Brijesh Singh 
>> ---
>>  qapi/target.json  | 6 --
>>  target/i386/sev.c | 6 --
>>  2 files changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/qapi/target.json b/qapi/target.json
>> index 1d4d54b600..b45121d30b 100644
>> --- a/qapi/target.json
>> +++ b/qapi/target.json
>> @@ -183,7 +183,8 @@
>>'data': { 'pdh': 'str',
>>  'cert-chain': 'str',
>>  'cbitpos': 'int',
>> -'reduced-phys-bits': 'int'},
>> +'reduced-phys-bits': 'int',
>> +'sev-max-guests': 'int'},
> 
> Would it be useful to make this new field optional? E.g. if it was
> missing, libvirtd could assume "no limit".
> 
> Again, not sure if that's useful, but it's not hard to introduce the
> field as optional now. Removing mandatory fields later is impossible.

On second thought, if we're sure the hardware / encryption engine will
always have this kind of limitation, then mandatory looks fine.

Thanks
Laszlo

Re: [Qemu-devel] [PATCH] slirp: Gcc 9 -O3 fix

[Samuel Thibault]

Hello,

Dr. David Alan Gilbert, le lun. 08 avril 2019 09:46:53 +0100, a ecrit:
> 'soread' has the comment:
> 
> /*
>  * No need to check if there's enough room to read.
>  * soread wouldn't have been called if there weren't
>  */
> sopreprbuf(so, iov, );
> 
> the compiler doesn't realise that, and is moaning about the case
> where the if (len <=0) return happens and the following 
> code tries to use iov.

I see. Perhaps we should make this an assert then? In case this isn't
true, i.e. soread() is called even if no room is available, returning 0
would probably just let the caller just try again, and we should rather
just plainly crash than hang?

Samuel

[Qemu-devel] [PATCH for-4.1] hw/input: Add a CONFIG_PS2 switch for the ps2.c file

[Thomas Huth]

ps2.c only needs to be compiled if we are building pckbd.c or pl050.c.

Signed-off-by: Thomas Huth 
---
 hw/input/Kconfig   | 5 +
 hw/input/Makefile.objs | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/hw/input/Kconfig b/hw/input/Kconfig
index e2e66f0858..316573f782 100644
--- a/hw/input/Kconfig
+++ b/hw/input/Kconfig
@@ -8,10 +8,15 @@ config LM832X
 config PCKBD
 bool
 default y
+select PS2
 depends on ISA_BUS
 
 config PL050
 bool
+select PS2
+
+config PS2
+bool
 
 config STELLARIS_INPUT
 bool
diff --git a/hw/input/Makefile.objs b/hw/input/Makefile.objs
index c8b00f71ec..6db5ee0e71 100644
--- a/hw/input/Makefile.objs
+++ b/hw/input/Makefile.objs
@@ -3,7 +3,7 @@ common-obj-y += hid.o
 common-obj-$(CONFIG_LM832X) += lm832x.o
 common-obj-$(CONFIG_PCKBD) += pckbd.o
 common-obj-$(CONFIG_PL050) += pl050.o
-common-obj-y += ps2.o
+common-obj-$(CONFIG_PS2) += ps2.o
 common-obj-$(CONFIG_STELLARIS_INPUT) += stellaris_input.o
 common-obj-$(CONFIG_TSC2005) += tsc2005.o
 
-- 
2.21.0

Re: [Qemu-devel] [PATCH] target/i386: sev: add 'sev-max-guests' field to 'query-sev-capabilities'

[Singh, Brijesh]

On 4/11/19 1:05 PM, Daniel P. Berrangé wrote:
> On Thu, Apr 11, 2019 at 05:59:50PM +, Singh, Brijesh wrote:
>> There are limited numbers of the SEV guests that can be run concurrently.
>> A management applications may need to know this limit so that it can place
>> SEV VMs on hosts which have suitable resources available.
>>
>> Currently, this limit is not exposed to the application. Add a new
>> 'sev-max-guest' field in the query-sev-capabilities to provide this
>> information.
>>
>> Cc: Paolo Bonzini 
>> Cc: Markus Armbruster 
>> Cc: Eric Blake 
>> Cc: Daniel P. Berrangé 
>> Cc: Laszlo Ersek 
>> Cc: Erik Skultety 
>> Signed-off-by: Brijesh Singh 
>> ---
>>   qapi/target.json  | 6 --
>>   target/i386/sev.c | 6 --
>>   2 files changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/qapi/target.json b/qapi/target.json
>> index 1d4d54b600..b45121d30b 100644
>> --- a/qapi/target.json
>> +++ b/qapi/target.json
>> @@ -183,7 +183,8 @@
> 
> A few lines above here you need to document the new field
> with (since 4.1) annotation.
> 

noted. thanks

Re: [Qemu-devel] [Qemu-trivial] [PATCH] hw/net/pcnet: Use qemu_log_mask(GUEST_ERROR) instead of fprintf

[Laurent Vivier]

On 11/03/2019 11:27, Philippe Mathieu-Daudé wrote:
> Avoid to clutter stdout until explicitly requested
> (with -d guest_errors):
> 
>   $ qemu-system-mips -M malta -m 512 -kernel vmlinux-3.2.0-4-4kc-malta
>   Bad SWSTYLE=0x04
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> Helge patch "pcnet: Avoid warning when switching back to 16bit mode"
> remembered me I had this one somewhere.
> ---
>  hw/net/pcnet.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/net/pcnet.c b/hw/net/pcnet.c
> index d9ba04bdfc..16683091c9 100644
> --- a/hw/net/pcnet.c
> +++ b/hw/net/pcnet.c
> @@ -36,6 +36,7 @@
>   */
>  
>  #include "qemu/osdep.h"
> +#include "qemu/log.h"
>  #include "hw/qdev.h"
>  #include "net/net.h"
>  #include "net/eth.h"
> @@ -1501,7 +1502,8 @@ static void pcnet_bcr_writew(PCNetState *s, uint32_t 
> rap, uint32_t val)
>  val |= 0x0300;
>  break;
>  default:
> -printf("Bad SWSTYLE=0x%02x\n", val & 0xff);
> +qemu_log_mask(LOG_GUEST_ERROR, "pcnet: Bad SWSTYLE=0x%02x\n",
> +  val & 0xff);
>  val = 0x0200;
>  break;
>  }
> 

Applied to my trivial-patches branch.

Thanks,
Laurent

Re: [Qemu-devel] [PATCH] target/i386: sev: add 'sev-max-guests' field to 'query-sev-capabilities'

[Laszlo Ersek]

On 04/11/19 19:59, Singh, Brijesh wrote:
> There are limited numbers of the SEV guests that can be run concurrently.
> A management applications may need to know this limit so that it can place
> SEV VMs on hosts which have suitable resources available.
> 
> Currently, this limit is not exposed to the application. Add a new
> 'sev-max-guest' field in the query-sev-capabilities to provide this
> information.
> 
> Cc: Paolo Bonzini 
> Cc: Markus Armbruster 
> Cc: Eric Blake 
> Cc: Daniel P. Berrangé 
> Cc: Laszlo Ersek 
> Cc: Erik Skultety 
> Signed-off-by: Brijesh Singh 
> ---
>  qapi/target.json  | 6 --
>  target/i386/sev.c | 6 --
>  2 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/qapi/target.json b/qapi/target.json
> index 1d4d54b600..b45121d30b 100644
> --- a/qapi/target.json
> +++ b/qapi/target.json
> @@ -183,7 +183,8 @@
>'data': { 'pdh': 'str',
>  'cert-chain': 'str',
>  'cbitpos': 'int',
> -'reduced-phys-bits': 'int'},
> +'reduced-phys-bits': 'int',
> +'sev-max-guests': 'int'},

Would it be useful to make this new field optional? E.g. if it was
missing, libvirtd could assume "no limit".

Again, not sure if that's useful, but it's not hard to introduce the
field as optional now. Removing mandatory fields later is impossible.

Thanks
Laszlo

>'if': 'defined(TARGET_I386)' }
>  
>  ##
> @@ -200,7 +201,8 @@
>  #
>  # -> { "execute": "query-sev-capabilities" }
>  # <- { "return": { "pdh": "8CCDD8DDD", "cert-chain": "888CCCDDDEE",
> -#  "cbitpos": 47, "reduced-phys-bits": 5}}
> +#  "cbitpos": 47, "reduced-phys-bits": 5,
> +#  "sev-max-guests" : 15}}
>  #
>  ##
>  { 'command': 'query-sev-capabilities', 'returns': 'SevCapability',
> diff --git a/target/i386/sev.c b/target/i386/sev.c
> index cd77f6b5d4..bb0cd79acd 100644
> --- a/target/i386/sev.c
> +++ b/target/i386/sev.c
> @@ -488,7 +488,7 @@ sev_get_capabilities(void)
>  guchar *pdh_data = NULL;
>  guchar *cert_chain_data = NULL;
>  size_t pdh_len = 0, cert_chain_len = 0;
> -uint32_t ebx;
> +uint32_t ebx, ecx, edx;
>  int fd;
>  
>  fd = open(DEFAULT_SEV_DEVICE, O_RDWR);
> @@ -507,7 +507,7 @@ sev_get_capabilities(void)
>  cap->pdh = g_base64_encode(pdh_data, pdh_len);
>  cap->cert_chain = g_base64_encode(cert_chain_data, cert_chain_len);
>  
> -host_cpuid(0x801F, 0, NULL, , NULL, NULL);
> +host_cpuid(0x801F, 0, NULL, , , );
>  cap->cbitpos = ebx & 0x3f;
>  
>  /*
> @@ -516,6 +516,8 @@ sev_get_capabilities(void)
>   */
>  cap->reduced_phys_bits = 1;
>  
> +/* the maximum number of SEV guests that can run simultaneously */
> +cap->sev_max_guests = ecx - edx + 1;
>  out:
>  g_free(pdh_data);
>  g_free(cert_chain_data);
> 

Re: [Qemu-devel] [qemu-s390x] [PATCH v4 1/6] vfio-ccw: make it safe to access channel programs

[Halil Pasic]

On Thu, 11 Apr 2019 18:36:48 +0200
Cornelia Huck  wrote:

> On Thu, 11 Apr 2019 12:25:38 -0400
> Eric Farman  wrote:
> 
> > On 4/11/19 11:58 AM, Halil Pasic wrote:
> > > On Wed, 10 Apr 2019 22:59:41 -0400
> > > Eric Farman  wrote:
> > >   
> > >> r the next release :) It would be one thing less on my plate...  
> >  
> > >>>
> > >>> Sorry I was not able to spend any significant amount of time on this
> > >>> lately.
> > >>>
> > >>> Gave the combined set (this + Farhans fio-ccw fixes for kernel
> > >>> stacktraces v2) it a bit of smoke testing after some minor adjustments
> > >>> to make it compile:
> > >>>
> > >>> --- a/drivers/s390/cio/vfio_ccw_ops.c
> > >>> +++ b/drivers/s390/cio/vfio_ccw_ops.c
> > >>> @@ -13,6 +13,7 @@
> > >>>#include 
> > >>>#include 
> > >>>#include 
> > >>> +#include 
> > >>>
> > >>>#include "vfio_ccw_private.h"
> > >>>
> > >>>  
> > >>
> > >> Hrm...  Taking today's master, and the two series you mention (slight
> > >> adjustment to apply patch 3 of Connie's series, because part of it was
> > >> split out a few weeks ago), and I don't encounter this.  Tried switching
> > >> between SLUB/SLAB, but still compiles fine.  
> > > 
> > > Let me guess: you have CONFIG_PCI in our .config, right?
> > > 
> > > In arch/s390/include/asm/pci_io.h we have
> > > 
> > > #ifndef _ASM_S390_PCI_IO_H
> > > #define _ASM_S390_PCI_IO_H
> > > 
> > > #ifdef CONFIG_PCI
> > > 
> > > #include 
> > > #include 
> > > 
> > > and pci_io.h comes in via
> > > 
> > > include/linux/vfio.h
> > > include/linux/iommu.h
> > > include/linux/scatterlist.h
> > > arch/s390/include/asm/io.h
> > > arch/s390/include/asm/pci_io.h
> > > 
> > > 
> > > Figured it out with help from Farhan. Took me quite some time.  
> > 
> > That would have been useful information up front.
> 
> Indeed. It's trivial to fold that change in, though :) (Should be in
> patch 4, if I see it correctly.)
> 

#4 vfio-ccw: add capabilities chain it is!

Cheers,
Halil

Re: [Qemu-devel] [PATCH] target/i386: sev: add 'sev-max-guests' field to 'query-sev-capabilities'

[Daniel P . Berrangé]

On Thu, Apr 11, 2019 at 05:59:50PM +, Singh, Brijesh wrote:
> There are limited numbers of the SEV guests that can be run concurrently.
> A management applications may need to know this limit so that it can place
> SEV VMs on hosts which have suitable resources available.
> 
> Currently, this limit is not exposed to the application. Add a new
> 'sev-max-guest' field in the query-sev-capabilities to provide this
> information.
> 
> Cc: Paolo Bonzini 
> Cc: Markus Armbruster 
> Cc: Eric Blake 
> Cc: Daniel P. Berrangé 
> Cc: Laszlo Ersek 
> Cc: Erik Skultety 
> Signed-off-by: Brijesh Singh 
> ---
>  qapi/target.json  | 6 --
>  target/i386/sev.c | 6 --
>  2 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/qapi/target.json b/qapi/target.json
> index 1d4d54b600..b45121d30b 100644
> --- a/qapi/target.json
> +++ b/qapi/target.json
> @@ -183,7 +183,8 @@

A few lines above here you need to document the new field
with (since 4.1) annotation.

>'data': { 'pdh': 'str',
>  'cert-chain': 'str',
>  'cbitpos': 'int',
> -'reduced-phys-bits': 'int'},
> +'reduced-phys-bits': 'int',
> +'sev-max-guests': 'int'},
>'if': 'defined(TARGET_I386)' }
>  
>  ##
> @@ -200,7 +201,8 @@
>  #
>  # -> { "execute": "query-sev-capabilities" }
>  # <- { "return": { "pdh": "8CCDD8DDD", "cert-chain": "888CCCDDDEE",
> -#  "cbitpos": 47, "reduced-phys-bits": 5}}
> +#  "cbitpos": 47, "reduced-phys-bits": 5,
> +#  "sev-max-guests" : 15}}
>  #
>  ##
>  { 'command': 'query-sev-capabilities', 'returns': 'SevCapability',
> diff --git a/target/i386/sev.c b/target/i386/sev.c
> index cd77f6b5d4..bb0cd79acd 100644
> --- a/target/i386/sev.c
> +++ b/target/i386/sev.c
> @@ -488,7 +488,7 @@ sev_get_capabilities(void)
>  guchar *pdh_data = NULL;
>  guchar *cert_chain_data = NULL;
>  size_t pdh_len = 0, cert_chain_len = 0;
> -uint32_t ebx;
> +uint32_t ebx, ecx, edx;
>  int fd;
>  
>  fd = open(DEFAULT_SEV_DEVICE, O_RDWR);
> @@ -507,7 +507,7 @@ sev_get_capabilities(void)
>  cap->pdh = g_base64_encode(pdh_data, pdh_len);
>  cap->cert_chain = g_base64_encode(cert_chain_data, cert_chain_len);
>  
> -host_cpuid(0x801F, 0, NULL, , NULL, NULL);
> +host_cpuid(0x801F, 0, NULL, , , );
>  cap->cbitpos = ebx & 0x3f;
>  
>  /*
> @@ -516,6 +516,8 @@ sev_get_capabilities(void)
>   */
>  cap->reduced_phys_bits = 1;
>  
> +/* the maximum number of SEV guests that can run simultaneously */
> +cap->sev_max_guests = ecx - edx + 1;
>  out:
>  g_free(pdh_data);
>  g_free(cert_chain_data);

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [libvirt] [PATCH for-QEMU-4.1] Declare -realtime as deprecated

[Daniel P . Berrangé]

On Thu, Apr 11, 2019 at 07:53:45PM +0200, Thomas Huth wrote:
> The old -realtime mlock=on|off parameter does exactly the same as the
> new -overcommit mem-lock=on|off parameter. Additionally, "-realtime"
> does not activate any additional "realtime" capabilities as the name
> might indicate. We should avoid to confuse the users this way, so
> let's deprecate the old -realtime option.

FYI libvirt currently uses  -realtime mlock=on so will need adapting
to cope with this change.

> 
> Signed-off-by: Thomas Huth 
> ---
>  Deprecation has already been suggested last year:
>   https://patchwork.kernel.org/patch/10480963/#22026215
>  ... but apparently we forgot to really do it.
> 
>  qemu-deprecated.texi | 5 +
>  vl.c | 2 ++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
> index 2219386769..2c45204f3f 100644
> --- a/qemu-deprecated.texi
> +++ b/qemu-deprecated.texi
> @@ -72,6 +72,11 @@ backend settings instead of environment variables.  To 
> ease migration to
>  the new format, the ``-audiodev-help'' option can be used to convert
>  the current values of the environment variables to ``-audiodev'' options.
>  
> +@subsection -realtime (since 4.1)
> +
> +The @code{-realtime mlock=on|off} argument has been replaced by the
> +@code{-overcommit mem-lock=on|off} argument.
> +
>  @section QEMU Machine Protocol (QMP) commands
>  
>  @subsection block-dirty-bitmap-add "autoload" parameter (since 2.12.0)
> diff --git a/vl.c b/vl.c
> index c696ad2a13..d6a2779b70 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -3912,6 +3912,8 @@ int main(int argc, char **argv, char **envp)
>  }
>  break;
>  case QEMU_OPTION_realtime:
> +warn_report("'-realtime mlock=...' is deprecated, please use 
> "
> + "'-overcommit mem-lock=...' instead");
>  opts = qemu_opts_parse_noisily(qemu_find_opts("realtime"),
> optarg, false);
>  if (!opts) {
> -- 
> 2.21.0
> 
> --
> libvir-list mailing list
> libvir-l...@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

[Qemu-devel] [PATCH] target/i386: sev: add 'sev-max-guests' field to 'query-sev-capabilities'

[Singh, Brijesh]

There are limited numbers of the SEV guests that can be run concurrently.
A management applications may need to know this limit so that it can place
SEV VMs on hosts which have suitable resources available.

Currently, this limit is not exposed to the application. Add a new
'sev-max-guest' field in the query-sev-capabilities to provide this
information.

Cc: Paolo Bonzini 
Cc: Markus Armbruster 
Cc: Eric Blake 
Cc: Daniel P. Berrangé 
Cc: Laszlo Ersek 
Cc: Erik Skultety 
Signed-off-by: Brijesh Singh 
---
 qapi/target.json  | 6 --
 target/i386/sev.c | 6 --
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/qapi/target.json b/qapi/target.json
index 1d4d54b600..b45121d30b 100644
--- a/qapi/target.json
+++ b/qapi/target.json
@@ -183,7 +183,8 @@
   'data': { 'pdh': 'str',
 'cert-chain': 'str',
 'cbitpos': 'int',
-'reduced-phys-bits': 'int'},
+'reduced-phys-bits': 'int',
+'sev-max-guests': 'int'},
   'if': 'defined(TARGET_I386)' }
 
 ##
@@ -200,7 +201,8 @@
 #
 # -> { "execute": "query-sev-capabilities" }
 # <- { "return": { "pdh": "8CCDD8DDD", "cert-chain": "888CCCDDDEE",
-#  "cbitpos": 47, "reduced-phys-bits": 5}}
+#  "cbitpos": 47, "reduced-phys-bits": 5,
+#  "sev-max-guests" : 15}}
 #
 ##
 { 'command': 'query-sev-capabilities', 'returns': 'SevCapability',
diff --git a/target/i386/sev.c b/target/i386/sev.c
index cd77f6b5d4..bb0cd79acd 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -488,7 +488,7 @@ sev_get_capabilities(void)
 guchar *pdh_data = NULL;
 guchar *cert_chain_data = NULL;
 size_t pdh_len = 0, cert_chain_len = 0;
-uint32_t ebx;
+uint32_t ebx, ecx, edx;
 int fd;
 
 fd = open(DEFAULT_SEV_DEVICE, O_RDWR);
@@ -507,7 +507,7 @@ sev_get_capabilities(void)
 cap->pdh = g_base64_encode(pdh_data, pdh_len);
 cap->cert_chain = g_base64_encode(cert_chain_data, cert_chain_len);
 
-host_cpuid(0x801F, 0, NULL, , NULL, NULL);
+host_cpuid(0x801F, 0, NULL, , , );
 cap->cbitpos = ebx & 0x3f;
 
 /*
@@ -516,6 +516,8 @@ sev_get_capabilities(void)
  */
 cap->reduced_phys_bits = 1;
 
+/* the maximum number of SEV guests that can run simultaneously */
+cap->sev_max_guests = ecx - edx + 1;
 out:
 g_free(pdh_data);
 g_free(cert_chain_data);
-- 
2.17.1

[Qemu-devel] [PATCH for-QEMU-4.1] Declare -realtime as deprecated

[Thomas Huth]

The old -realtime mlock=on|off parameter does exactly the same as the
new -overcommit mem-lock=on|off parameter. Additionally, "-realtime"
does not activate any additional "realtime" capabilities as the name
might indicate. We should avoid to confuse the users this way, so
let's deprecate the old -realtime option.

Signed-off-by: Thomas Huth 
---
 Deprecation has already been suggested last year:
  https://patchwork.kernel.org/patch/10480963/#22026215
 ... but apparently we forgot to really do it.

 qemu-deprecated.texi | 5 +
 vl.c | 2 ++
 2 files changed, 7 insertions(+)

diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
index 2219386769..2c45204f3f 100644
--- a/qemu-deprecated.texi
+++ b/qemu-deprecated.texi
@@ -72,6 +72,11 @@ backend settings instead of environment variables.  To ease 
migration to
 the new format, the ``-audiodev-help'' option can be used to convert
 the current values of the environment variables to ``-audiodev'' options.
 
+@subsection -realtime (since 4.1)
+
+The @code{-realtime mlock=on|off} argument has been replaced by the
+@code{-overcommit mem-lock=on|off} argument.
+
 @section QEMU Machine Protocol (QMP) commands
 
 @subsection block-dirty-bitmap-add "autoload" parameter (since 2.12.0)
diff --git a/vl.c b/vl.c
index c696ad2a13..d6a2779b70 100644
--- a/vl.c
+++ b/vl.c
@@ -3912,6 +3912,8 @@ int main(int argc, char **argv, char **envp)
 }
 break;
 case QEMU_OPTION_realtime:
+warn_report("'-realtime mlock=...' is deprecated, please use "
+ "'-overcommit mem-lock=...' instead");
 opts = qemu_opts_parse_noisily(qemu_find_opts("realtime"),
optarg, false);
 if (!opts) {
-- 
2.21.0

[Qemu-devel] [PATCH] hw/smbios: handle both file formats regardless of machine type

[Bruce Rogers]

It's easy enough to handle either per-spec or legacy smbios structures
in the smbios file input without regard to the machine type used, by
simply applying the basic smbios formatting rules. then depending on
what is detected. terminal numm bytes are added or removed for machine
type specific processing.

Signed-off-by: Bruce Rogers 
---
 hw/smbios/smbios.c | 43 +++
 1 file changed, 39 insertions(+), 4 deletions(-)

diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
index 47be9071fa..d4b95ebc84 100644
--- a/hw/smbios/smbios.c
+++ b/hw/smbios/smbios.c
@@ -960,6 +960,7 @@ void smbios_entry_add(QemuOpts *opts, Error **errp)
 struct smbios_structure_header *header;
 int size;
 struct smbios_table *table; /* legacy mode only */
+uint8_t *dbl_nulls, *orig_end;
 
 qemu_opts_validate(opts, qemu_smbios_file_opts, );
 if (err) {
@@ -974,11 +975,21 @@ void smbios_entry_add(QemuOpts *opts, Error **errp)
 }
 
 /*
- * NOTE: standard double '\0' terminator expected, per smbios spec.
- * (except in legacy mode, where the second '\0' is implicit and
- *  will be inserted by the BIOS).
+ * NOTE: standard double '\0' terminator expected, per smbios spec,
+ * unless the data is formatted for legacy mode, which is used by
+ * pc-i440fx-2.0 and earlier machine types. Legacy mode structures
+ * without strings have no '\0' terminators, and those with strings
+ * also don't have an additional '\0' terminator at the end of the
+ * final string '\0' terminator. The BIOS will add the '\0' terminators
+ * to comply with the smbios spec.
+ * For greater compatibility, regardless of the machine type used,
+ * either format is accepted.
  */
-smbios_tables = g_realloc(smbios_tables, smbios_tables_len + size);
+smbios_tables = g_realloc(smbios_tables, smbios_tables_len + size + 2);
+orig_end = smbios_tables + smbios_tables_len + size;
+/* add extra null bytes to end in case of legacy file data */
+*orig_end = '\0';
+*(orig_end + 1) = '\0';
 header = (struct smbios_structure_header *)(smbios_tables +
 smbios_tables_len);
 
@@ -993,6 +1004,19 @@ void smbios_entry_add(QemuOpts *opts, Error **errp)
header->type);
 return;
 }
+for (dbl_nulls = smbios_tables + smbios_tables_len + header->length;
+ dbl_nulls + 2 <= orig_end; dbl_nulls++) {
+if (*dbl_nulls == '\0' && *(dbl_nulls + 1) == '\0') {
+break;
+}
+}
+if (dbl_nulls + 2  < orig_end) {
+error_setg(errp, "SMBIOS file data malformed");
+return;
+}
+/* increase size by how many extra nulls were actually needed */
+size += dbl_nulls + 2 - orig_end;
+smbios_tables = g_realloc(smbios_tables, smbios_tables_len + size);
 set_bit(header->type, have_binfile_bitmap);
 
 if (header->type == 4) {
@@ -1013,6 +1037,17 @@ void smbios_entry_add(QemuOpts *opts, Error **errp)
  *   delete the one we don't need from smbios_set_defaults(),
  *   once we know which machine version has been requested.
  */
+if (dbl_nulls + 2 == orig_end) {
+/* chop off nulls to get legacy format */
+if (header->length + 2 == size) {
+size -= 2;
+} else {
+size -= 1;
+}
+} else {
+/* undo conversion from legacy format to per-spec format */
+size -= dbl_nulls + 2 - orig_end;
+}
 if (!smbios_entries) {
 smbios_entries_len = sizeof(uint16_t);
 smbios_entries = g_malloc0(smbios_entries_len);
-- 
2.21.0

Re: [Qemu-devel] [PATCH v2] target/riscv: Remove unused include of riscv_htif.h for virt board riscv

[Alistair Francis]

On Thu, Apr 11, 2019 at 8:10 AM Jonathan Behrens  wrote:
>
> Signed-off-by: Jonathan Behrens 

Awesome! Thanks for the patch.

Reviewed-by: Alistair Francis 

Alistair

> ---
>  hw/riscv/virt.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> index fc4c6b306e..3526463034 100644
> --- a/hw/riscv/virt.c
> +++ b/hw/riscv/virt.c
> @@ -29,7 +29,6 @@
>  #include "hw/sysbus.h"
>  #include "hw/char/serial.h"
>  #include "target/riscv/cpu.h"
> -#include "hw/riscv/riscv_htif.h"
>  #include "hw/riscv/riscv_hart.h"
>  #include "hw/riscv/sifive_plic.h"
>  #include "hw/riscv/sifive_clint.h"
> --
> 2.20.1

Re: [Qemu-devel] [RFC 0/3] VirtIO RDMA

[Yuval Shaia]

On Thu, Apr 11, 2019 at 08:34:20PM +0300, Yuval Shaia wrote:
> On Thu, Apr 11, 2019 at 05:24:08PM +, Jason Gunthorpe wrote:
> > On Thu, Apr 11, 2019 at 07:02:15PM +0200, Cornelia Huck wrote:
> > > On Thu, 11 Apr 2019 14:01:54 +0300
> > > Yuval Shaia  wrote:
> > > 
> > > > Data center backends use more and more RDMA or RoCE devices and more and
> > > > more software runs in virtualized environment.
> > > > There is a need for a standard to enable RDMA/RoCE on Virtual Machines.
> > > > 
> > > > Virtio is the optimal solution since is the de-facto para-virtualizaton
> > > > technology and also because the Virtio specification
> > > > allows Hardware Vendors to support Virtio protocol natively in order to
> > > > achieve bare metal performance.
> > > > 
> > > > This RFC is an effort to addresses challenges in defining the RDMA/RoCE
> > > > Virtio Specification and a look forward on possible implementation
> > > > techniques.
> > > > 
> > > > Open issues/Todo list:
> > > > List is huge, this is only start point of the project.
> > > > Anyway, here is one example of item in the list:
> > > > - Multi VirtQ: Every QP has two rings and every CQ has one. This means 
> > > > that
> > > >   in order to support for example 32K QPs we will need 64K VirtQ. Not 
> > > > sure
> > > >   that this is reasonable so one option is to have one for all and
> > > >   multiplex the traffic on it. This is not good approach as by design it
> > > >   introducing an optional starvation. Another approach would be multi
> > > >   queues and round-robin (for example) between them.
> > > > 
> > > > Expectations from this posting:
> > > > In general, any comment is welcome, starting from hey, drop this as it 
> > > > is a
> > > > very bad idea, to yeah, go ahead, we really want it.
> > > > Idea here is that since it is not a minor effort i first want to know if
> > > > there is some sort interest in the community for such device.
> > > 
> > > My first reaction is: Sounds sensible, but it would be good to have a
> > > spec for this :)
> > 
> > I'm unclear why you'd want to have a virtio queue for anything other
> > that some kind of command channel.
> > 
> > I'm not sure a QP or CQ benefits from this??
> 
> Virtqueue is a standard mechanism to pass data from guest to host. By

And vice versa (CQ?)

> saying that - it really sounds like QP send and recv rings. So my thought
> is to use a standard way for rings. As i've learned this is how it is used
> by other virtio devices ex virtio-net.
> 
> > 
> > Jason
> 

Re: [Qemu-devel] [RFC 0/3] VirtIO RDMA

[Jason Gunthorpe]

On Thu, Apr 11, 2019 at 08:34:20PM +0300, Yuval Shaia wrote:
> On Thu, Apr 11, 2019 at 05:24:08PM +, Jason Gunthorpe wrote:
> > On Thu, Apr 11, 2019 at 07:02:15PM +0200, Cornelia Huck wrote:
> > > On Thu, 11 Apr 2019 14:01:54 +0300
> > > Yuval Shaia  wrote:
> > > 
> > > > Data center backends use more and more RDMA or RoCE devices and more and
> > > > more software runs in virtualized environment.
> > > > There is a need for a standard to enable RDMA/RoCE on Virtual Machines.
> > > > 
> > > > Virtio is the optimal solution since is the de-facto para-virtualizaton
> > > > technology and also because the Virtio specification
> > > > allows Hardware Vendors to support Virtio protocol natively in order to
> > > > achieve bare metal performance.
> > > > 
> > > > This RFC is an effort to addresses challenges in defining the RDMA/RoCE
> > > > Virtio Specification and a look forward on possible implementation
> > > > techniques.
> > > > 
> > > > Open issues/Todo list:
> > > > List is huge, this is only start point of the project.
> > > > Anyway, here is one example of item in the list:
> > > > - Multi VirtQ: Every QP has two rings and every CQ has one. This means 
> > > > that
> > > >   in order to support for example 32K QPs we will need 64K VirtQ. Not 
> > > > sure
> > > >   that this is reasonable so one option is to have one for all and
> > > >   multiplex the traffic on it. This is not good approach as by design it
> > > >   introducing an optional starvation. Another approach would be multi
> > > >   queues and round-robin (for example) between them.
> > > > 
> > > > Expectations from this posting:
> > > > In general, any comment is welcome, starting from hey, drop this as it 
> > > > is a
> > > > very bad idea, to yeah, go ahead, we really want it.
> > > > Idea here is that since it is not a minor effort i first want to know if
> > > > there is some sort interest in the community for such device.
> > > 
> > > My first reaction is: Sounds sensible, but it would be good to have a
> > > spec for this :)
> > 
> > I'm unclear why you'd want to have a virtio queue for anything other
> > that some kind of command channel.
> > 
> > I'm not sure a QP or CQ benefits from this??
> 
> Virtqueue is a standard mechanism to pass data from guest to host. By
> saying that - it really sounds like QP send and recv rings. So my thought
> is to use a standard way for rings. As i've learned this is how it is used
> by other virtio devices ex virtio-net.

I doubt you can use virtio queues from userspace securely? Usually
needs a dedicated page for each user space process

Jason

Re: [Qemu-devel] [RFC 0/3] VirtIO RDMA

[Yuval Shaia]

On Thu, Apr 11, 2019 at 05:24:08PM +, Jason Gunthorpe wrote:
> On Thu, Apr 11, 2019 at 07:02:15PM +0200, Cornelia Huck wrote:
> > On Thu, 11 Apr 2019 14:01:54 +0300
> > Yuval Shaia  wrote:
> > 
> > > Data center backends use more and more RDMA or RoCE devices and more and
> > > more software runs in virtualized environment.
> > > There is a need for a standard to enable RDMA/RoCE on Virtual Machines.
> > > 
> > > Virtio is the optimal solution since is the de-facto para-virtualizaton
> > > technology and also because the Virtio specification
> > > allows Hardware Vendors to support Virtio protocol natively in order to
> > > achieve bare metal performance.
> > > 
> > > This RFC is an effort to addresses challenges in defining the RDMA/RoCE
> > > Virtio Specification and a look forward on possible implementation
> > > techniques.
> > > 
> > > Open issues/Todo list:
> > > List is huge, this is only start point of the project.
> > > Anyway, here is one example of item in the list:
> > > - Multi VirtQ: Every QP has two rings and every CQ has one. This means 
> > > that
> > >   in order to support for example 32K QPs we will need 64K VirtQ. Not sure
> > >   that this is reasonable so one option is to have one for all and
> > >   multiplex the traffic on it. This is not good approach as by design it
> > >   introducing an optional starvation. Another approach would be multi
> > >   queues and round-robin (for example) between them.
> > > 
> > > Expectations from this posting:
> > > In general, any comment is welcome, starting from hey, drop this as it is 
> > > a
> > > very bad idea, to yeah, go ahead, we really want it.
> > > Idea here is that since it is not a minor effort i first want to know if
> > > there is some sort interest in the community for such device.
> > 
> > My first reaction is: Sounds sensible, but it would be good to have a
> > spec for this :)
> 
> I'm unclear why you'd want to have a virtio queue for anything other
> that some kind of command channel.
> 
> I'm not sure a QP or CQ benefits from this??

Virtqueue is a standard mechanism to pass data from guest to host. By
saying that - it really sounds like QP send and recv rings. So my thought
is to use a standard way for rings. As i've learned this is how it is used
by other virtio devices ex virtio-net.

> 
> Jason

Re: [Qemu-devel] [RFC 0/3] VirtIO RDMA

[Jason Gunthorpe]

On Thu, Apr 11, 2019 at 07:02:15PM +0200, Cornelia Huck wrote:
> On Thu, 11 Apr 2019 14:01:54 +0300
> Yuval Shaia  wrote:
> 
> > Data center backends use more and more RDMA or RoCE devices and more and
> > more software runs in virtualized environment.
> > There is a need for a standard to enable RDMA/RoCE on Virtual Machines.
> > 
> > Virtio is the optimal solution since is the de-facto para-virtualizaton
> > technology and also because the Virtio specification
> > allows Hardware Vendors to support Virtio protocol natively in order to
> > achieve bare metal performance.
> > 
> > This RFC is an effort to addresses challenges in defining the RDMA/RoCE
> > Virtio Specification and a look forward on possible implementation
> > techniques.
> > 
> > Open issues/Todo list:
> > List is huge, this is only start point of the project.
> > Anyway, here is one example of item in the list:
> > - Multi VirtQ: Every QP has two rings and every CQ has one. This means that
> >   in order to support for example 32K QPs we will need 64K VirtQ. Not sure
> >   that this is reasonable so one option is to have one for all and
> >   multiplex the traffic on it. This is not good approach as by design it
> >   introducing an optional starvation. Another approach would be multi
> >   queues and round-robin (for example) between them.
> > 
> > Expectations from this posting:
> > In general, any comment is welcome, starting from hey, drop this as it is a
> > very bad idea, to yeah, go ahead, we really want it.
> > Idea here is that since it is not a minor effort i first want to know if
> > there is some sort interest in the community for such device.
> 
> My first reaction is: Sounds sensible, but it would be good to have a
> spec for this :)

I'm unclear why you'd want to have a virtio queue for anything other
that some kind of command channel.

I'm not sure a QP or CQ benefits from this??

Jason

[Qemu-devel] [PATCH v6 7/7] iotests: test nbd reconnect

[Vladimir Sementsov-Ogievskiy]

Add test, which starts backup to nbd target and restarts nbd server
during backup.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 tests/qemu-iotests/249| 63 +++
 tests/qemu-iotests/249.out| 10 ++
 tests/qemu-iotests/group  |  1 +
 tests/qemu-iotests/iotests.py |  4 +++
 4 files changed, 78 insertions(+)
 create mode 100755 tests/qemu-iotests/249
 create mode 100644 tests/qemu-iotests/249.out

diff --git a/tests/qemu-iotests/249 b/tests/qemu-iotests/249
new file mode 100755
index 00..a29a276207
--- /dev/null
+++ b/tests/qemu-iotests/249
@@ -0,0 +1,63 @@
+#!/usr/bin/env python
+#
+# Test nbd reconnect
+#
+# Copyright (c) 2019 Virtuozzo International GmbH. All rights reserved.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+#
+
+import time
+
+import iotests
+from iotests import qemu_img_create, file_path, qemu_nbd_popen, log
+
+disk_a, disk_b, nbd_sock = file_path('disk_a', 'disk_b', 'nbd-sock')
+
+qemu_img_create('-f', iotests.imgfmt, disk_a, '5M')
+qemu_img_create('-f', iotests.imgfmt, disk_b, '5M')
+srv = qemu_nbd_popen('-k', nbd_sock, '-f', iotests.imgfmt, disk_b)
+time.sleep(1)
+
+vm = iotests.VM().add_drive(disk_a)
+vm.launch()
+vm.hmp_qemu_io('drive0', 'write 0 5M')
+
+vm.qmp_log('blockdev-add', filters=[iotests.filter_qmp_testfiles],
+   **{'node_name': 'backup0',
+  'driver': 'raw',
+  'file': {'driver': 'nbd',
+   'server': {'type': 'unix', 'path': nbd_sock},
+   'reconnect-delay': 10}})
+vm.qmp_log('blockdev-backup', device='drive0', sync='full', target='backup0')
+
+time.sleep(1)
+log('Kill NBD server')
+srv.kill()
+
+jobs = vm.qmp('query-block-jobs')['return']
+if jobs and jobs[0]['offset'] < jobs[0]['len']:
+log('Backup job is still in progress')
+
+time.sleep(1)
+
+log('Start NBD server')
+srv = qemu_nbd_popen('-k', nbd_sock, '-f', iotests.imgfmt, disk_b)
+
+e = vm.event_wait('BLOCK_JOB_COMPLETED')
+log('Backup completed: {}'.format(e['data']['offset']))
+
+vm.qmp_log('blockdev-del', node_name='backup0')
+srv.kill()
+vm.shutdown()
diff --git a/tests/qemu-iotests/249.out b/tests/qemu-iotests/249.out
new file mode 100644
index 00..15a82ddefb
--- /dev/null
+++ b/tests/qemu-iotests/249.out
@@ -0,0 +1,10 @@
+{"execute": "blockdev-add", "arguments": {"driver": "raw", "file": {"driver": 
"nbd", "reconnect-delay": 10, "server": {"path": "TEST_DIR/PID-nbd-sock", 
"type": "unix"}}, "node-name": "backup0"}}
+{"return": {}}
+{"execute": "blockdev-backup", "arguments": {"device": "drive0", "sync": 
"full", "target": "backup0"}}
+{"return": {}}
+Kill NBD server
+Backup job is still in progress
+Start NBD server
+Backup completed: 5242880
+{"execute": "blockdev-del", "arguments": {"node-name": "backup0"}}
+{"return": {}}
diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group
index bae7718380..7ac9a5ea4a 100644
--- a/tests/qemu-iotests/group
+++ b/tests/qemu-iotests/group
@@ -248,3 +248,4 @@
 246 rw auto quick
 247 rw auto quick
 248 rw auto quick
+249 rw auto quick
diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
index 997dc910cb..3a1f16dbfd 100644
--- a/tests/qemu-iotests/iotests.py
+++ b/tests/qemu-iotests/iotests.py
@@ -218,6 +218,10 @@ def qemu_nbd_pipe(*args):
   ' '.join(qemu_nbd_args + ['--fork'] + list(args
 return exitcode, subp.communicate()[0]
 
+def qemu_nbd_popen(*args):
+'''Run qemu-nbd in daemon mode and return the parent's exit code'''
+return subprocess.Popen(qemu_nbd_args + ['--persistent'] + list(args))
+
 def compare_images(img1, img2, fmt1=imgfmt, fmt2=imgfmt):
 '''Return True if two image files are identical'''
 return qemu_img('compare', '-f', fmt1,
-- 
2.18.0

[Qemu-devel] [PATCH v6 2/7] block/nbd-client: use non-blocking io channel for nbd negotiation

[Vladimir Sementsov-Ogievskiy]

No reason to use blocking channel for negotiation and we'll benefit in
further reconnect feature, as qio_channel reads and writes will do
qemu_coroutine_yield while waiting for io completion.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 include/block/nbd.h |  3 ++-
 block/nbd-client.c  | 16 +++-
 nbd/client.c| 16 +++-
 qemu-nbd.c  |  2 +-
 4 files changed, 21 insertions(+), 16 deletions(-)

diff --git a/include/block/nbd.h b/include/block/nbd.h
index 6d05983a55..6961835654 100644
--- a/include/block/nbd.h
+++ b/include/block/nbd.h
@@ -290,7 +290,8 @@ struct NBDExportInfo {
 };
 typedef struct NBDExportInfo NBDExportInfo;
 
-int nbd_receive_negotiate(QIOChannel *ioc, QCryptoTLSCreds *tlscreds,
+int nbd_receive_negotiate(AioContext *aio_context, QIOChannel *ioc,
+  QCryptoTLSCreds *tlscreds,
   const char *hostname, QIOChannel **outioc,
   NBDExportInfo *info, Error **errp);
 void nbd_free_export_list(NBDExportInfo *info, int count);
diff --git a/block/nbd-client.c b/block/nbd-client.c
index facf8f8099..f9cee25865 100644
--- a/block/nbd-client.c
+++ b/block/nbd-client.c
@@ -1123,6 +1123,7 @@ static int nbd_client_connect(BlockDriverState *bs,
   Error **errp)
 {
 NBDClientSession *client = nbd_get_client_session(bs);
+AioContext *aio_context = bdrv_get_aio_context(bs);
 int ret;
 
 /*
@@ -1137,15 +1138,16 @@ static int nbd_client_connect(BlockDriverState *bs,
 
 /* NBD handshake */
 logout("session init %s\n", export);
-qio_channel_set_blocking(QIO_CHANNEL(sioc), true, NULL);
+qio_channel_set_blocking(QIO_CHANNEL(sioc), false, NULL);
+qio_channel_attach_aio_context(QIO_CHANNEL(sioc), aio_context);
 
 client->info.request_sizes = true;
 client->info.structured_reply = true;
 client->info.base_allocation = true;
 client->info.x_dirty_bitmap = g_strdup(x_dirty_bitmap);
 client->info.name = g_strdup(export ?: "");
-ret = nbd_receive_negotiate(QIO_CHANNEL(sioc), tlscreds, hostname,
->ioc, >info, errp);
+ret = nbd_receive_negotiate(aio_context, QIO_CHANNEL(sioc), tlscreds,
+hostname, >ioc, >info, errp);
 g_free(client->info.x_dirty_bitmap);
 g_free(client->info.name);
 if (ret < 0) {
@@ -1180,17 +1182,13 @@ static int nbd_client_connect(BlockDriverState *bs,
 object_ref(OBJECT(client->ioc));
 }
 
-qio_channel_set_blocking(QIO_CHANNEL(sioc), false, NULL);
-qio_channel_attach_aio_context(client->ioc, bdrv_get_aio_context(bs));
-
 logout("Established connection with NBD server\n");
 return 0;
 
  fail:
 /*
- * We have connected, but must fail for other reasons. The
- * connection is still blocking; send NBD_CMD_DISC as a courtesy
- * to the server.
+ * We have connected, but must fail for other reasons.
+ * Send NBD_CMD_DISC as a courtesy to the server.
  */
 {
 NBDRequest request = { .type = NBD_CMD_DISC };
diff --git a/nbd/client.c b/nbd/client.c
index 4de30630c7..8f524c3e35 100644
--- a/nbd/client.c
+++ b/nbd/client.c
@@ -867,7 +867,8 @@ static int nbd_list_meta_contexts(QIOChannel *ioc,
  *  2: server is newstyle, but lacks structured replies
  *  3: server is newstyle and set up for structured replies
  */
-static int nbd_start_negotiate(QIOChannel *ioc, QCryptoTLSCreds *tlscreds,
+static int nbd_start_negotiate(AioContext *aio_context, QIOChannel *ioc,
+   QCryptoTLSCreds *tlscreds,
const char *hostname, QIOChannel **outioc,
bool structured_reply, bool *zeroes,
Error **errp)
@@ -934,6 +935,10 @@ static int nbd_start_negotiate(QIOChannel *ioc, 
QCryptoTLSCreds *tlscreds,
 return -EINVAL;
 }
 ioc = *outioc;
+if (aio_context) {
+qio_channel_set_blocking(ioc, false, NULL);
+qio_channel_attach_aio_context(ioc, aio_context);
+}
 } else {
 error_setg(errp, "Server does not support STARTTLS");
 return -EINVAL;
@@ -998,7 +1003,8 @@ static int nbd_negotiate_finish_oldstyle(QIOChannel *ioc, 
NBDExportInfo *info,
  * Returns: negative errno: failure talking to server
  *  0: server is connected
  */
-int nbd_receive_negotiate(QIOChannel *ioc, QCryptoTLSCreds *tlscreds,
+int nbd_receive_negotiate(AioContext *aio_context, QIOChannel *ioc,
+  QCryptoTLSCreds *tlscreds,
   const char *hostname, QIOChannel **outioc,
   NBDExportInfo *info, Error **errp)
 {
@@ -1009,7 +1015,7 @@ int nbd_receive_negotiate(QIOChannel *ioc, 
QCryptoTLSCreds *tlscreds,
 assert(info->name);
 

[Qemu-devel] [PATCH v6 4/7] block/nbd: add cmdline and qapi parameter reconnect-delay

[Vladimir Sementsov-Ogievskiy]

Reconnect will be implemented in the following commit, so for now,
in semantics below, disconnect itself is a "serious error".

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 qapi/block-core.json | 12 +++-
 block/nbd-client.h   |  1 +
 block/nbd-client.c   |  1 +
 block/nbd.c  | 16 +++-
 4 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/qapi/block-core.json b/qapi/block-core.json
index 7ccbfff9d0..815258bd89 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -3798,13 +3798,23 @@
 #  traditional "base:allocation" block status (see
 #  NBD_OPT_LIST_META_CONTEXT in the NBD protocol) (since 3.0)
 #
+# @reconnect-delay: Reconnect delay. On unexpected disconnect, nbd client tries
+#   to connect again, until success or serious error. During
+#   first @reconnect-delay seconds of reconnecting loop all
+#   requests are paused and have a chance to rerun, if
+#   successful connect occurs during this time. After
+#   @reconnect-delay seconds all delayed requests are failed
+#   and all following requests will be failed too (until
+#   successful reconnect). Default 0 (Since 4.1)
+#
 # Since: 2.9
 ##
 { 'struct': 'BlockdevOptionsNbd',
   'data': { 'server': 'SocketAddress',
 '*export': 'str',
 '*tls-creds': 'str',
-'*x-dirty-bitmap': 'str' } }
+'*x-dirty-bitmap': 'str',
+'*reconnect-delay': 'uint32' } }
 
 ##
 # @BlockdevOptionsRaw:
diff --git a/block/nbd-client.h b/block/nbd-client.h
index e45b7b0a14..91a6b32bdd 100644
--- a/block/nbd-client.h
+++ b/block/nbd-client.h
@@ -52,6 +52,7 @@ int nbd_client_init(BlockDriverState *bs,
 QCryptoTLSCreds *tlscreds,
 const char *hostname,
 const char *x_dirty_bitmap,
+uint32_t reconnect_delay,
 Error **errp);
 void nbd_client_close(BlockDriverState *bs);
 
diff --git a/block/nbd-client.c b/block/nbd-client.c
index 9f5c86eaa3..1359aff162 100644
--- a/block/nbd-client.c
+++ b/block/nbd-client.c
@@ -1218,6 +1218,7 @@ int nbd_client_init(BlockDriverState *bs,
 QCryptoTLSCreds *tlscreds,
 const char *hostname,
 const char *x_dirty_bitmap,
+uint32_t reconnect_delay,
 Error **errp)
 {
 int ret;
diff --git a/block/nbd.c b/block/nbd.c
index 208be59602..cffb2aee89 100644
--- a/block/nbd.c
+++ b/block/nbd.c
@@ -360,6 +360,18 @@ static QemuOptsList nbd_runtime_opts = {
 .help = "experimental: expose named dirty bitmap in place of "
 "block status",
 },
+{
+.name = "reconnect-delay",
+.type = QEMU_OPT_NUMBER,
+.help = "Reconnect delay. On unexpected disconnect, nbd client "
+"tries to connect again, until success or serious error. "
+"During first @reconnect-delay seconds of reconnecting "
+"loop all requests are paused and have a chance to rerun, "
+"if successful connect occurs during this time. After"
+"@reconnect-delay seconds all delayed requests are failed"
+"and all following requests will be failed too (until"
+"successful reconnect). Default 0",
+},
 { /* end of list */ }
 },
 };
@@ -411,7 +423,9 @@ static int nbd_open(BlockDriverState *bs, QDict *options, 
int flags,
 
 /* NBD handshake */
 ret = nbd_client_init(bs, s->saddr, s->export, tlscreds, hostname,
-  qemu_opt_get(opts, "x-dirty-bitmap"), errp);
+  qemu_opt_get(opts, "x-dirty-bitmap"),
+  qemu_opt_get_number(opts, "reconnect-delay", 0),
+  errp);
 
  error:
 if (tlscreds) {
-- 
2.18.0

[Qemu-devel] [PATCH v6 3/7] block/nbd-client: move from quit to state

[Vladimir Sementsov-Ogievskiy]

To implement reconnect we need several states for the client:
CONNECTED, QUIT and two different CONNECTING states. CONNECTING states
will be added in the following patches. This patch implements CONNECTED
and QUIT.

QUIT means, that we should close the connection and fail all current
and further requests (like old quit = true).

CONNECTED means that connection is ok, we can send requests (like old
quit = false).

For receiving loop we use a comparison of the current state with QUIT,
because reconnect will be in the same loop, so it should be looping
until the end.

Opposite, for requests we use a comparison of the current state with
CONNECTED, as we don't want to send requests in future CONNECTING
states.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 block/nbd-client.h |  7 ++-
 block/nbd-client.c | 51 --
 2 files changed, 37 insertions(+), 21 deletions(-)

diff --git a/block/nbd-client.h b/block/nbd-client.h
index 09e03013d2..e45b7b0a14 100644
--- a/block/nbd-client.h
+++ b/block/nbd-client.h
@@ -23,6 +23,11 @@ typedef struct {
 bool receiving; /* waiting for connection_co? */
 } NBDClientRequest;
 
+typedef enum NBDClientState {
+NBD_CLIENT_CONNECTED,
+NBD_CLIENT_QUIT
+} NBDClientState;
+
 typedef struct NBDClientSession {
 QIOChannelSocket *sioc; /* The master data channel */
 QIOChannel *ioc; /* The current I/O channel which may differ (eg TLS) */
@@ -32,11 +37,11 @@ typedef struct NBDClientSession {
 CoQueue free_sema;
 Coroutine *connection_co;
 int in_flight;
+NBDClientState state;
 
 NBDClientRequest requests[MAX_NBD_REQUESTS];
 NBDReply reply;
 BlockDriverState *bs;
-bool quit;
 } NBDClientSession;
 
 NBDClientSession *nbd_get_client_session(BlockDriverState *bs);
diff --git a/block/nbd-client.c b/block/nbd-client.c
index f9cee25865..9f5c86eaa3 100644
--- a/block/nbd-client.c
+++ b/block/nbd-client.c
@@ -36,6 +36,12 @@
 #define HANDLE_TO_INDEX(bs, handle) ((handle) ^ (uint64_t)(intptr_t)(bs))
 #define INDEX_TO_HANDLE(bs, index)  ((index)  ^ (uint64_t)(intptr_t)(bs))
 
+/* @ret will be used for reconnect in future */
+static void nbd_channel_error(NBDClientSession *s, int ret)
+{
+s->state = NBD_CLIENT_QUIT;
+}
+
 static void nbd_recv_coroutines_wake_all(NBDClientSession *s)
 {
 int i;
@@ -75,7 +81,7 @@ static coroutine_fn void nbd_connection_entry(void *opaque)
 int ret = 0;
 Error *local_err = NULL;
 
-while (!s->quit) {
+while (s->state != NBD_CLIENT_QUIT) {
 /*
  * The NBD client can only really be considered idle when it has
  * yielded from qio_channel_readv_all_eof(), waiting for data. This is
@@ -93,6 +99,7 @@ static coroutine_fn void nbd_connection_entry(void *opaque)
 error_free(local_err);
 }
 if (ret <= 0) {
+nbd_channel_error(s, ret ? ret : -EIO);
 break;
 }
 
@@ -106,6 +113,7 @@ static coroutine_fn void nbd_connection_entry(void *opaque)
 !s->requests[i].receiving ||
 (nbd_reply_is_structured(>reply) && !s->info.structured_reply))
 {
+nbd_channel_error(s, -EINVAL);
 break;
 }
 
@@ -124,7 +132,6 @@ static coroutine_fn void nbd_connection_entry(void *opaque)
 qemu_coroutine_yield();
 }
 
-s->quit = true;
 nbd_recv_coroutines_wake_all(s);
 bdrv_dec_in_flight(s->bs);
 
@@ -137,12 +144,18 @@ static int nbd_co_send_request(BlockDriverState *bs,
QEMUIOVector *qiov)
 {
 NBDClientSession *s = nbd_get_client_session(bs);
-int rc, i;
+int rc, i = -1;
 
 qemu_co_mutex_lock(>send_mutex);
 while (s->in_flight == MAX_NBD_REQUESTS) {
 qemu_co_queue_wait(>free_sema, >send_mutex);
 }
+
+if (s->state != NBD_CLIENT_CONNECTED) {
+rc = -EIO;
+goto err;
+}
+
 s->in_flight++;
 
 for (i = 0; i < MAX_NBD_REQUESTS; i++) {
@@ -160,16 +173,12 @@ static int nbd_co_send_request(BlockDriverState *bs,
 
 request->handle = INDEX_TO_HANDLE(s, i);
 
-if (s->quit) {
-rc = -EIO;
-goto err;
-}
 assert(s->ioc);
 
 if (qiov) {
 qio_channel_set_cork(s->ioc, true);
 rc = nbd_send_request(s->ioc, request);
-if (rc >= 0 && !s->quit) {
+if (rc >= 0 && s->state == NBD_CLIENT_CONNECTED) {
 if (qio_channel_writev_all(s->ioc, qiov->iov, qiov->niov,
NULL) < 0) {
 rc = -EIO;
@@ -184,9 +193,11 @@ static int nbd_co_send_request(BlockDriverState *bs,
 
 err:
 if (rc < 0) {
-s->quit = true;
-s->requests[i].coroutine = NULL;
-s->in_flight--;
+nbd_channel_error(s, rc);
+if (i != -1) {
+s->requests[i].coroutine = NULL;
+s->in_flight--;
+}
 qemu_co_queue_next(>free_sema);
 }
 qemu_co_mutex_unlock(>send_mutex);
@@ -477,7 

[Qemu-devel] [PATCH v6 6/7] block/nbd-client: nbd reconnect

[Vladimir Sementsov-Ogievskiy]

Implement reconnect. To achieve this:

1. add new modes:
   connecting-wait: means, that reconnecting is in progress, and there
 were small number of reconnect attempts, so all requests are
 waiting for the connection.
   connecting-nowait: reconnecting is in progress, there were a lot of
 attempts of reconnect, all requests will return errors.

   two old modes are used too:
   connected: normal state
   quit: exiting after fatal error or on close

Possible transitions are:

   * -> quit
   connecting-* -> connected
   connecting-wait -> connecting-nowait (transition is done after
  reconnect-delay seconds in connecting-wait mode)
   connected -> connecting-wait

2. Implement reconnect in connection_co. So, in connecting-* mode,
connection_co, tries to reconnect unlimited times.

3. Retry nbd queries on channel error, if we are in connecting-wait
state.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 block/nbd-client.h |   7 +
 block/nbd-client.c | 336 +++--
 2 files changed, 273 insertions(+), 70 deletions(-)

diff --git a/block/nbd-client.h b/block/nbd-client.h
index 91a6b32bdd..f366c90e5e 100644
--- a/block/nbd-client.h
+++ b/block/nbd-client.h
@@ -24,6 +24,8 @@ typedef struct {
 } NBDClientRequest;
 
 typedef enum NBDClientState {
+NBD_CLIENT_CONNECTING_WAIT,
+NBD_CLIENT_CONNECTING_NOWAIT,
 NBD_CLIENT_CONNECTED,
 NBD_CLIENT_QUIT
 } NBDClientState;
@@ -38,10 +40,15 @@ typedef struct NBDClientSession {
 Coroutine *connection_co;
 int in_flight;
 NBDClientState state;
+int connect_status;
+Error *connect_err;
+bool wait_in_flight;
 
 NBDClientRequest requests[MAX_NBD_REQUESTS];
 NBDReply reply;
 BlockDriverState *bs;
+
+uint32_t reconnect_delay;
 } NBDClientSession;
 
 NBDClientSession *nbd_get_client_session(BlockDriverState *bs);
diff --git a/block/nbd-client.c b/block/nbd-client.c
index 1359aff162..b829a1a1bd 100644
--- a/block/nbd-client.c
+++ b/block/nbd-client.c
@@ -1,6 +1,7 @@
 /*
  * QEMU Block driver for  NBD
  *
+ * Copyright (c) 2019 Virtuozzo International GmbH. All rights reserved.
  * Copyright (C) 2016 Red Hat, Inc.
  * Copyright (C) 2008 Bull S.A.S.
  * Author: Laurent Vivier 
@@ -36,10 +37,27 @@
 #define HANDLE_TO_INDEX(bs, handle) ((handle) ^ (uint64_t)(intptr_t)(bs))
 #define INDEX_TO_HANDLE(bs, index)  ((index)  ^ (uint64_t)(intptr_t)(bs))
 
-/* @ret will be used for reconnect in future */
+static int nbd_client_connect(BlockDriverState *bs,
+  SocketAddress *saddr,
+  const char *export,
+  QCryptoTLSCreds *tlscreds,
+  const char *hostname,
+  const char *x_dirty_bitmap,
+  Error **errp);
+
 static void nbd_channel_error(NBDClientSession *s, int ret)
 {
-s->state = NBD_CLIENT_QUIT;
+if (ret == -EIO) {
+if (s->state == NBD_CLIENT_CONNECTED) {
+s->state = s->reconnect_delay ? NBD_CLIENT_CONNECTING_WAIT :
+NBD_CLIENT_CONNECTING_NOWAIT;
+}
+} else {
+if (s->state == NBD_CLIENT_CONNECTED) {
+qio_channel_shutdown(s->ioc, QIO_CHANNEL_SHUTDOWN_BOTH, NULL);
+}
+s->state = NBD_CLIENT_QUIT;
+}
 }
 
 static void nbd_recv_coroutines_wake_all(NBDClientSession *s)
@@ -59,24 +77,133 @@ static void nbd_teardown_connection(BlockDriverState *bs)
 {
 NBDClientSession *client = nbd_get_client_session(bs);
 
-assert(client->ioc);
-
-/* finish any pending coroutines */
-qio_channel_shutdown(client->ioc,
- QIO_CHANNEL_SHUTDOWN_BOTH,
- NULL);
+if (client->state == NBD_CLIENT_CONNECTED) {
+/* finish any pending coroutines */
+assert(client->ioc);
+qio_channel_shutdown(client->ioc, QIO_CHANNEL_SHUTDOWN_BOTH, NULL);
+}
+client->state = NBD_CLIENT_QUIT;
+if (client->connection_co) {
+qemu_co_sleep_wake(client->connection_co);
+}
 BDRV_POLL_WHILE(bs, client->connection_co);
+}
+
+typedef struct NBDConnection {
+BlockDriverState *bs;
+SocketAddress *saddr;
+const char *export;
+QCryptoTLSCreds *tlscreds;
+const char *hostname;
+const char *x_dirty_bitmap;
+} NBDConnection;
+
+static bool nbd_client_connecting(NBDClientSession *client)
+{
+return client->state == NBD_CLIENT_CONNECTING_WAIT ||
+   client->state == NBD_CLIENT_CONNECTING_NOWAIT;
+}
+
+static bool nbd_client_connecting_wait(NBDClientSession *client)
+{
+return client->state == NBD_CLIENT_CONNECTING_WAIT;
+}
+
+static coroutine_fn void nbd_reconnect_attempt(NBDConnection *con)
+{
+NBDClientSession *s = nbd_get_client_session(con->bs);
+Error *local_err = NULL;
+
+if (!nbd_client_connecting(s)) {
+return;
+}
+

[Qemu-devel] [PATCH v6 5/7] qemu-coroutine-sleep: introduce qemu_co_sleep_wake

[Vladimir Sementsov-Ogievskiy]

Introduce a function to gracefully wake-up a coroutine, sleeping in
qemu_co_sleep_ns() sleep.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 include/qemu/coroutine.h|  6 ++
 util/qemu-coroutine-sleep.c | 20 
 2 files changed, 22 insertions(+), 4 deletions(-)

diff --git a/include/qemu/coroutine.h b/include/qemu/coroutine.h
index 9801e7f5a4..ec765c26f0 100644
--- a/include/qemu/coroutine.h
+++ b/include/qemu/coroutine.h
@@ -278,6 +278,12 @@ void qemu_co_rwlock_unlock(CoRwlock *lock);
  */
 void coroutine_fn qemu_co_sleep_ns(QEMUClockType type, int64_t ns);
 
+/*
+ * Wake a coroutine if it is sleeping by qemu_co_sleep_ns. Timer will be
+ * deleted.
+ */
+void qemu_co_sleep_wake(Coroutine *co);
+
 /**
  * Yield until a file descriptor becomes readable
  *
diff --git a/util/qemu-coroutine-sleep.c b/util/qemu-coroutine-sleep.c
index 4bfdd30cbf..bcc6afca3e 100644
--- a/util/qemu-coroutine-sleep.c
+++ b/util/qemu-coroutine-sleep.c
@@ -17,13 +17,24 @@
 #include "qemu/timer.h"
 #include "block/aio.h"
 
+const char *qemu_co_sleep_ns__scheduled = "qemu_co_sleep_ns";
+
+void qemu_co_sleep_wake(Coroutine *co)
+{
+/* Write of schedule protected by barrier write in aio_co_schedule */
+const char *scheduled = atomic_cmpxchg(>scheduled,
+   qemu_co_sleep_ns__scheduled, NULL);
+
+if (scheduled == qemu_co_sleep_ns__scheduled) {
+aio_co_wake(co);
+}
+}
+
 static void co_sleep_cb(void *opaque)
 {
 Coroutine *co = opaque;
 
-/* Write of schedule protected by barrier write in aio_co_schedule */
-atomic_set(>scheduled, NULL);
-aio_co_wake(co);
+qemu_co_sleep_wake(co);
 }
 
 void coroutine_fn qemu_co_sleep_ns(QEMUClockType type, int64_t ns)
@@ -32,7 +43,8 @@ void coroutine_fn qemu_co_sleep_ns(QEMUClockType type, 
int64_t ns)
 QEMUTimer *ts;
 Coroutine *co = qemu_coroutine_self();
 
-const char *scheduled = atomic_cmpxchg(>scheduled, NULL, __func__);
+const char *scheduled = atomic_cmpxchg(>scheduled, NULL,
+   qemu_co_sleep_ns__scheduled);
 if (scheduled) {
 fprintf(stderr,
 "%s: Co-routine was already scheduled in '%s'\n",
-- 
2.18.0

[Qemu-devel] [PATCH v6 1/7] block/nbd-client: split connection_co start out of nbd_client_connect

[Vladimir Sementsov-Ogievskiy]

nbd_client_connect is going to be used from connection_co, so, let's
refactor nbd_client_connect in advance, leaving io channel
configuration all in nbd_client_connect.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 block/nbd-client.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/block/nbd-client.c b/block/nbd-client.c
index 790ecc1ee1..facf8f8099 100644
--- a/block/nbd-client.c
+++ b/block/nbd-client.c
@@ -1180,12 +1180,8 @@ static int nbd_client_connect(BlockDriverState *bs,
 object_ref(OBJECT(client->ioc));
 }
 
-/* Now that we're connected, set the socket to be non-blocking and
- * kick the reply mechanism.  */
 qio_channel_set_blocking(QIO_CHANNEL(sioc), false, NULL);
-client->connection_co = qemu_coroutine_create(nbd_connection_entry, 
client);
-bdrv_inc_in_flight(bs);
-nbd_client_attach_aio_context(bs, bdrv_get_aio_context(bs));
+qio_channel_attach_aio_context(client->ioc, bdrv_get_aio_context(bs));
 
 logout("Established connection with NBD server\n");
 return 0;
@@ -1215,12 +1211,22 @@ int nbd_client_init(BlockDriverState *bs,
 const char *x_dirty_bitmap,
 Error **errp)
 {
+int ret;
 NBDClientSession *client = nbd_get_client_session(bs);
 
 client->bs = bs;
 qemu_co_mutex_init(>send_mutex);
 qemu_co_queue_init(>free_sema);
 
-return nbd_client_connect(bs, saddr, export, tlscreds, hostname,
-  x_dirty_bitmap, errp);
+ret = nbd_client_connect(bs, saddr, export, tlscreds, hostname,
+ x_dirty_bitmap, errp);
+if (ret < 0) {
+return ret;
+}
+
+client->connection_co = qemu_coroutine_create(nbd_connection_entry, 
client);
+bdrv_inc_in_flight(bs);
+aio_co_schedule(bdrv_get_aio_context(bs), client->connection_co);
+
+return 0;
 }
-- 
2.18.0

[Qemu-devel] [PATCH v6 0/7] NBD reconnect

[Vladimir Sementsov-Ogievskiy]

Here is NBD reconnect. Previously, if connection failed all current
and future requests will fail. After the series, nbd-client driver
will try to reconnect unlimited times. During first @reconnect-delay
seconds of reconnecting all requests will wait for the connection,
and if it is established requests will be resent. After
@reconnect-delay period all requests will be failed (until successful
reconnect).

v4->v6:
 (some preparing patches from v4 was merged as v5)
01: new
02: new
03: - drop unused things
   - future states
   - future s/break/continue/
04: - fix typos
- s/3.1/4.1/
- set 0 as default
05: new
06: - new states and s/break/continue/ moved here from 03
- drop NBDClientSession.receiving, as now in_flight
  requests used instread
- add copyright
- go to NBD_CLIENT_CONNECTING_NOWAIT immediately if
  reconnect_delay is 0 (so, reconnect_delay moved to
  NBDClientSession)
- on close, do qemu_co_sleep_wake(client->connection_co),
  to not wait for reconnect loop iteration
- handle state transition to QUIT during reconnect loop
  (assert(nbd_client_connecting(s)) was bad idea)
- don't try to fail on protocol errors after
  nbd_client_connect, as we can't distinguish them
- decrement in_flight around reconnect sleep to make
  it possible to drain and exit during it
  (v4 was based on something before in_flight logic
   introduced into nbd-client)
- changed logic in nbd_client_attach_aio_context 
07: - refactor, using log and qmp_log
- drop export name
- drop strange try/except
- add reconnect-delay option (as 0 is a default now)


Vladimir Sementsov-Ogievskiy (7):
  block/nbd-client: split connection_co start out of nbd_client_connect
  block/nbd-client: use non-blocking io channel for nbd negotiation
  block/nbd-client: move from quit to state
  block/nbd: add cmdline and qapi parameter reconnect-delay
  qemu-coroutine-sleep: introduce qemu_co_sleep_wake
  block/nbd-client: nbd reconnect
  iotests: test nbd reconnect

 qapi/block-core.json  |  12 +-
 block/nbd-client.h|  15 +-
 include/block/nbd.h   |   3 +-
 include/qemu/coroutine.h  |   6 +
 block/nbd-client.c| 416 +-
 block/nbd.c   |  16 +-
 nbd/client.c  |  16 +-
 qemu-nbd.c|   2 +-
 util/qemu-coroutine-sleep.c   |  20 +-
 tests/qemu-iotests/249|  63 +
 tests/qemu-iotests/249.out|  10 +
 tests/qemu-iotests/group  |   1 +
 tests/qemu-iotests/iotests.py |   4 +
 13 files changed, 468 insertions(+), 116 deletions(-)
 create mode 100755 tests/qemu-iotests/249
 create mode 100644 tests/qemu-iotests/249.out

-- 
2.18.0

Re: [Qemu-devel] [PULL 16/71] nbd: Increase bs->in_flight during AioContext switch

[Vladimir Sementsov-Ogievskiy]

11.04.2019 20:13, Vladimir Sementsov-Ogievskiy wrote:
> 11.04.2019 19:48, Kevin Wolf wrote:
>> Am 11.04.2019 um 16:48 hat Vladimir Sementsov-Ogievskiy geschrieben:
>>> 11.04.2019 17:15, Kevin Wolf wrote:
 Am 11.04.2019 um 15:40 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 25.02.2019 18:19, Kevin Wolf wrote:
>> bdrv_drain() must not leave connection_co scheduled, so bs->in_flight
>> needs to be increased while the coroutine is waiting to be scheduled
>> in the new AioContext after nbd_client_attach_aio_context().
>
> Hi!
>
> I have some questions, could you explain, please?
>
> "bdrv_drain() must not leave connection_co scheduled" - it's because we 
> want to be
> sure that connection_co yielded from nbd_read_eof, yes?
>
> But it is guaranteed by aio_wait_bh_oneshot.. Why do we need 
> additioinally inc/dec
> bs->in_flight ?

 Without incrementing bs->in_flight, nothing would guarantee that
 aio_poll() is called and the BH is actually executed before bdrv_drain()
 returns.
>>>
>>> Don't follow.. Don't we want exactly this, we want BH to be executed while 
>>> node is still
>>> drained, as you write in comment?
>>
>> Yes, exactly. But if bs->in_flight == 0, the AIO_WAIT_WHILE() condition
>> in the drain code could become false, so aio_poll() would not be called
>> again and drain would return even if the BH is still pending.
>>
> 
> Ah, oops, sorry my English, I read it like "nothing would prevent". 
> Understand now, thanks.

Or not again.. We will not return to drain code, as we will loop in 
aio_wait_bh_oneshot,
which will not return until BH handled

> 

>>
>> Signed-off-by: Kevin Wolf 
>> ---
>>     block/nbd-client.c | 20 ++--
>>     1 file changed, 18 insertions(+), 2 deletions(-)
>>
>> diff --git a/block/nbd-client.c b/block/nbd-client.c
>> index 60f38f0320..bfbaf7ebe9 100644
>> --- a/block/nbd-client.c
>> +++ b/block/nbd-client.c
>> @@ -977,14 +977,30 @@ void 
>> nbd_client_detach_aio_context(BlockDriverState *bs)
>>     qio_channel_detach_aio_context(QIO_CHANNEL(client->ioc));
>>     }
>> +static void nbd_client_attach_aio_context_bh(void *opaque)
>> +{
>> +    BlockDriverState *bs = opaque;
>> +    NBDClientSession *client = nbd_get_client_session(bs);
>> +
>> +    /* The node is still drained, so we know the coroutine has yielded 
>> in
>> + * nbd_read_eof(), the only place where bs->in_flight can reach 0, 
>> or it is
>> + * entered for the first time. Both places are safe for entering the
>> + * coroutine.*/
>> +    qemu_aio_coroutine_enter(bs->aio_context, client->connection_co);
>> +    bdrv_dec_in_flight(bs);
>> +}
>> +
>>     void nbd_client_attach_aio_context(BlockDriverState *bs,
>>    AioContext *new_context)
>>     {
>>     NBDClientSession *client = nbd_get_client_session(bs);
>>     qio_channel_attach_aio_context(QIO_CHANNEL(client->ioc), 
>> new_context);
>> -    /* FIXME Really need a bdrv_inc_in_flight() here */
>> -    aio_co_schedule(new_context, client->connection_co);
>> +    bdrv_inc_in_flight(bs);
>> +
>> +    /* Need to wait here for the BH to run because the BH must run 
>> while the
>> + * node is still drained. */
>> +    aio_wait_bh_oneshot(new_context, nbd_client_attach_aio_context_bh, 
>> bs);
>>     }
>>     void nbd_client_close(BlockDriverState *bs)
>>
>
>
> -- 
> Best regards,
> Vladimir
>>>
>>>
>>> -- 
>>> Best regards,
>>> Vladimir
> 
> 


-- 
Best regards,
Vladimir

Re: [Qemu-devel] [PULL 16/71] nbd: Increase bs->in_flight during AioContext switch

[Vladimir Sementsov-Ogievskiy]

11.04.2019 19:48, Kevin Wolf wrote:
> Am 11.04.2019 um 16:48 hat Vladimir Sementsov-Ogievskiy geschrieben:
>> 11.04.2019 17:15, Kevin Wolf wrote:
>>> Am 11.04.2019 um 15:40 hat Vladimir Sementsov-Ogievskiy geschrieben:
 25.02.2019 18:19, Kevin Wolf wrote:
> bdrv_drain() must not leave connection_co scheduled, so bs->in_flight
> needs to be increased while the coroutine is waiting to be scheduled
> in the new AioContext after nbd_client_attach_aio_context().

 Hi!

 I have some questions, could you explain, please?

 "bdrv_drain() must not leave connection_co scheduled" - it's because we 
 want to be
 sure that connection_co yielded from nbd_read_eof, yes?

 But it is guaranteed by aio_wait_bh_oneshot.. Why do we need additioinally 
 inc/dec
 bs->in_flight ?
>>>
>>> Without incrementing bs->in_flight, nothing would guarantee that
>>> aio_poll() is called and the BH is actually executed before bdrv_drain()
>>> returns.
>>
>> Don't follow.. Don't we want exactly this, we want BH to be executed while 
>> node is still
>> drained, as you write in comment?
> 
> Yes, exactly. But if bs->in_flight == 0, the AIO_WAIT_WHILE() condition
> in the drain code could become false, so aio_poll() would not be called
> again and drain would return even if the BH is still pending.
> 

Ah, oops, sorry my English, I read it like "nothing would prevent". Understand 
now, thanks.

>>>
>
> Signed-off-by: Kevin Wolf 
> ---
> block/nbd-client.c | 20 ++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/block/nbd-client.c b/block/nbd-client.c
> index 60f38f0320..bfbaf7ebe9 100644
> --- a/block/nbd-client.c
> +++ b/block/nbd-client.c
> @@ -977,14 +977,30 @@ void nbd_client_detach_aio_context(BlockDriverState 
> *bs)
> qio_channel_detach_aio_context(QIO_CHANNEL(client->ioc));
> }
> 
> +static void nbd_client_attach_aio_context_bh(void *opaque)
> +{
> +BlockDriverState *bs = opaque;
> +NBDClientSession *client = nbd_get_client_session(bs);
> +
> +/* The node is still drained, so we know the coroutine has yielded in
> + * nbd_read_eof(), the only place where bs->in_flight can reach 0, 
> or it is
> + * entered for the first time. Both places are safe for entering the
> + * coroutine.*/
> +qemu_aio_coroutine_enter(bs->aio_context, client->connection_co);
> +bdrv_dec_in_flight(bs);
> +}
> +
> void nbd_client_attach_aio_context(BlockDriverState *bs,
>AioContext *new_context)
> {
> NBDClientSession *client = nbd_get_client_session(bs);
> qio_channel_attach_aio_context(QIO_CHANNEL(client->ioc), 
> new_context);
> 
> -/* FIXME Really need a bdrv_inc_in_flight() here */
> -aio_co_schedule(new_context, client->connection_co);
> +bdrv_inc_in_flight(bs);
> +
> +/* Need to wait here for the BH to run because the BH must run while 
> the
> + * node is still drained. */
> +aio_wait_bh_oneshot(new_context, nbd_client_attach_aio_context_bh, 
> bs);
> }
> 
> void nbd_client_close(BlockDriverState *bs)
>


 -- 
 Best regards,
 Vladimir
>>
>>
>> -- 
>> Best regards,
>> Vladimir


-- 
Best regards,
Vladimir

Re: [Qemu-devel] [PATCH RFC 1/1] block/rbd: increase dynamically the image size

[Jason Dillaman]

On Thu, Apr 11, 2019 at 9:02 AM Stefano Garzarella  wrote:
>
> On Thu, Apr 11, 2019 at 08:35:44AM -0400, Jason Dillaman wrote:
> > On Thu, Apr 11, 2019 at 7:00 AM Stefano Garzarella  
> > wrote:
> > >
> > > RBD APIs don't allow us to write more than the size set with rbd_create()
> > > or rbd_resize().
> > > In order to support growing images (eg. qcow2), we resize the image
> > > before RW operations that exceed the current size.
> >
> > What's the use-case for storing qcow2 images within a RBD image? RBD
> > images are already thinly provisioned, they support snapshots, they
> > can form a parent/child linked image hierarchy.
> >
>
> Hi Jason,
> I understand your point of view, maybe one use case could be if you have
> a qcow2 image and you want to put it in the rdb pool without convert it.
>
> I'm going through this BZ [1] and I'll ask if they have other
> use cases in mind.

Assuming no good use-cases, perhaps it would just be better to make
the qemu-img error messages more clear.

> Anyway, if we want to support only raw format on RBD driver, maybe we
> should return something different from current behaviour, also avoiding
> to create the image:
>
> $ qemu-img create -f qcow2 rbd:test/qcow.img 1G
>   qemu-img: rbd:test/qcow.img: Could not write qcow2 header: Invalid argument
>
> What do you think?
>
> Thanks,
> Stefano
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1171007



-- 
Jason

Re: [Qemu-devel] [RFC 0/3] VirtIO RDMA

[Cornelia Huck]

On Thu, 11 Apr 2019 14:01:54 +0300
Yuval Shaia  wrote:

> Data center backends use more and more RDMA or RoCE devices and more and
> more software runs in virtualized environment.
> There is a need for a standard to enable RDMA/RoCE on Virtual Machines.
> 
> Virtio is the optimal solution since is the de-facto para-virtualizaton
> technology and also because the Virtio specification
> allows Hardware Vendors to support Virtio protocol natively in order to
> achieve bare metal performance.
> 
> This RFC is an effort to addresses challenges in defining the RDMA/RoCE
> Virtio Specification and a look forward on possible implementation
> techniques.
> 
> Open issues/Todo list:
> List is huge, this is only start point of the project.
> Anyway, here is one example of item in the list:
> - Multi VirtQ: Every QP has two rings and every CQ has one. This means that
>   in order to support for example 32K QPs we will need 64K VirtQ. Not sure
>   that this is reasonable so one option is to have one for all and
>   multiplex the traffic on it. This is not good approach as by design it
>   introducing an optional starvation. Another approach would be multi
>   queues and round-robin (for example) between them.
> 
> Expectations from this posting:
> In general, any comment is welcome, starting from hey, drop this as it is a
> very bad idea, to yeah, go ahead, we really want it.
> Idea here is that since it is not a minor effort i first want to know if
> there is some sort interest in the community for such device.

My first reaction is: Sounds sensible, but it would be good to have a
spec for this :)

You'll need a spec if you want this to go forward anyway, so at least a
sketch would be good to answer questions such as how many virtqueues
you use for which purpose, what is actually put on the virtqueues,
whether there are negotiable features, and what the expectations for
the device and the driver are. It also makes it easier to understand
how this is supposed to work in practice.

If folks agree that this sounds useful, the next step would be to
reserve an id for the device type.

> 
> The scope of the implementation is limited to probing the device and doing
> some basic ibverbs commands. Data-path is not yet implemented. So with this
> one can expect only that driver is (partialy) loaded and basic queries and
> resource allocation is done.
> 
> One note regarding the patchset.
> I know it is not standard to collaps patches from several repos as i did
> here (qemu and linux) but decided to do it anyway so the whole picture can
> be seen.
> 
> patch 1: virtio-net: Move some virtio-net-pci decl to include/hw/virtio
>   This is a prelimenary patch just as a hack so i will not need to
>   impelement new netdev
> patch 2: hw/virtio-rdma: VirtIO rdma device
>   The implementation of the device
> patch 3: RDMA/virtio-rdma: VirtIO rdma driver
>   The device driver
> 

Re: [Qemu-devel] [PATCH 1/2] hw: timer: Add ASPEED RTC device

[Peter Maydell]

On Thu, 11 Apr 2019 at 17:37, Philippe Mathieu-Daudé  wrote:
>
> Hi Peter,
>
> On 4/11/19 5:30 PM, Cédric Le Goater wrote:
> > On 4/11/19 5:25 PM, Peter Maydell wrote:
> >> This is missing a reset function and vmstate.
>
> Is vmstate mandatory for new devices.

Yes, I think so. You can have vmstate that says
"this can't be migrated" if you absolutely must, but
it's generally easy enough to make it properly migratable.
If the device generally has no state to migrate it
should at least provide a comment saying so.
(I think we should add a way to say this in a vmstate,
so that we can then assert that every device sets its
vmsd pointer to something.)

Failing to provide a vmstate means you have a machine
which will silently break if the user tries to do
savevm/loadvm, which is not very nice.

thanks
-- PMM

Re: [Qemu-devel] [PULL 16/71] nbd: Increase bs->in_flight during AioContext switch

[Kevin Wolf]

Am 11.04.2019 um 16:48 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 11.04.2019 17:15, Kevin Wolf wrote:
> > Am 11.04.2019 um 15:40 hat Vladimir Sementsov-Ogievskiy geschrieben:
> >> 25.02.2019 18:19, Kevin Wolf wrote:
> >>> bdrv_drain() must not leave connection_co scheduled, so bs->in_flight
> >>> needs to be increased while the coroutine is waiting to be scheduled
> >>> in the new AioContext after nbd_client_attach_aio_context().
> >>
> >> Hi!
> >>
> >> I have some questions, could you explain, please?
> >>
> >> "bdrv_drain() must not leave connection_co scheduled" - it's because we 
> >> want to be
> >> sure that connection_co yielded from nbd_read_eof, yes?
> >>
> >> But it is guaranteed by aio_wait_bh_oneshot.. Why do we need additioinally 
> >> inc/dec
> >> bs->in_flight ?
> > 
> > Without incrementing bs->in_flight, nothing would guarantee that
> > aio_poll() is called and the BH is actually executed before bdrv_drain()
> > returns.
> 
> Don't follow.. Don't we want exactly this, we want BH to be executed while 
> node is still
> drained, as you write in comment?

Yes, exactly. But if bs->in_flight == 0, the AIO_WAIT_WHILE() condition
in the drain code could become false, so aio_poll() would not be called
again and drain would return even if the BH is still pending.

Kevin

> > 
> >>>
> >>> Signed-off-by: Kevin Wolf 
> >>> ---
> >>>block/nbd-client.c | 20 ++--
> >>>1 file changed, 18 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/block/nbd-client.c b/block/nbd-client.c
> >>> index 60f38f0320..bfbaf7ebe9 100644
> >>> --- a/block/nbd-client.c
> >>> +++ b/block/nbd-client.c
> >>> @@ -977,14 +977,30 @@ void nbd_client_detach_aio_context(BlockDriverState 
> >>> *bs)
> >>>qio_channel_detach_aio_context(QIO_CHANNEL(client->ioc));
> >>>}
> >>>
> >>> +static void nbd_client_attach_aio_context_bh(void *opaque)
> >>> +{
> >>> +BlockDriverState *bs = opaque;
> >>> +NBDClientSession *client = nbd_get_client_session(bs);
> >>> +
> >>> +/* The node is still drained, so we know the coroutine has yielded in
> >>> + * nbd_read_eof(), the only place where bs->in_flight can reach 0, 
> >>> or it is
> >>> + * entered for the first time. Both places are safe for entering the
> >>> + * coroutine.*/
> >>> +qemu_aio_coroutine_enter(bs->aio_context, client->connection_co);
> >>> +bdrv_dec_in_flight(bs);
> >>> +}
> >>> +
> >>>void nbd_client_attach_aio_context(BlockDriverState *bs,
> >>>   AioContext *new_context)
> >>>{
> >>>NBDClientSession *client = nbd_get_client_session(bs);
> >>>qio_channel_attach_aio_context(QIO_CHANNEL(client->ioc), 
> >>> new_context);
> >>>
> >>> -/* FIXME Really need a bdrv_inc_in_flight() here */
> >>> -aio_co_schedule(new_context, client->connection_co);
> >>> +bdrv_inc_in_flight(bs);
> >>> +
> >>> +/* Need to wait here for the BH to run because the BH must run while 
> >>> the
> >>> + * node is still drained. */
> >>> +aio_wait_bh_oneshot(new_context, nbd_client_attach_aio_context_bh, 
> >>> bs);
> >>>}
> >>>
> >>>void nbd_client_close(BlockDriverState *bs)
> >>>
> >>
> >>
> >> -- 
> >> Best regards,
> >> Vladimir
> 
> 
> -- 
> Best regards,
> Vladimir

Re: [Qemu-devel] [PATCH 1/3] aspeed: add a per SoC mapping for the interrupt space

[Philippe Mathieu-Daudé]

Hi Cédric,

On 4/11/19 6:10 PM, Cédric Le Goater wrote:
> This will simplify the definition of new SoCs, like the AST2600 which
> should use a different CPU and a different IRQ number layout.
> 
> Signed-off-by: Cédric Le Goater 
> ---
>  include/hw/arm/aspeed_soc.h |  1 +
>  hw/arm/aspeed_soc.c | 93 +
>  2 files changed, 86 insertions(+), 8 deletions(-)
> 
> diff --git a/include/hw/arm/aspeed_soc.h b/include/hw/arm/aspeed_soc.h
> index 11ec0179db50..b0d266434288 100644
> --- a/include/hw/arm/aspeed_soc.h
> +++ b/include/hw/arm/aspeed_soc.h
> @@ -57,6 +57,7 @@ typedef struct AspeedSoCInfo {
>  const char *fmc_typename;
>  const char **spi_typename;
>  int wdts_num;
> +const int *irqmap;
>  } AspeedSoCInfo;
>  
>  typedef struct AspeedSoCClass {
> diff --git a/hw/arm/aspeed_soc.c b/hw/arm/aspeed_soc.c
> index a27233d4876b..5bbd1fb87d18 100644
> --- a/hw/arm/aspeed_soc.c
> +++ b/hw/arm/aspeed_soc.c
> @@ -22,6 +22,42 @@
>  #include "hw/i2c/aspeed_i2c.h"
>  #include "net/net.h"
>  
> +enum {
> +ASPEED_IOMEM,
> +ASPEED_UART1,
> +ASPEED_UART2,
> +ASPEED_UART3,
> +ASPEED_UART4,
> +ASPEED_UART5,
> +ASPEED_VUART,
> +ASPEED_FMC,
> +ASPEED_SPI1,
> +ASPEED_SPI2,
> +ASPEED_VIC,
> +ASPEED_SDMC,
> +ASPEED_SCU,
> +ASPEED_ADC,
> +ASPEED_SRAM,
> +ASPEED_GPIO,
> +ASPEED_RTC,
> +ASPEED_TIMER1,
> +ASPEED_TIMER2,
> +ASPEED_TIMER3,
> +ASPEED_TIMER4,
> +ASPEED_TIMER5,
> +ASPEED_TIMER6,
> +ASPEED_TIMER7,
> +ASPEED_TIMER8,

You use an enum to define const values. It is recommended to also define
the value, to avoid problems if someone add/remove a value in the list
(unlikely, but we never know... imagine someone wants to try this SoC
with 9 timers and add ASPEED_TIMER9) ;)

> +ASPEED_WDT,
> +ASPEED_PWM,
> +ASPEED_LPC,
> +ASPEED_IBT,
> +ASPEED_I2C,
> +ASPEED_ETH1,
> +ASPEED_ETH2,
> +ASPEED_SDRAM,
> +};
> +
>  #define ASPEED_SOC_UART_5_BASE  0x00184000
>  #define ASPEED_SOC_IOMEM_SIZE   0x0020
>  #define ASPEED_SOC_IOMEM_BASE   0x1E60
> @@ -38,12 +74,42 @@
>  #define ASPEED_SOC_ETH1_BASE0x1E66
>  #define ASPEED_SOC_ETH2_BASE0x1E68
>  
> -static const int uart_irqs[] = { 9, 32, 33, 34, 10 };
> -static const int timer_irqs[] = { 16, 17, 18, 35, 36, 37, 38, 39, };
> +static const int aspeed_soc_ast2400_irqmap[] = {
> +[ASPEED_UART1]  = 9,
> +[ASPEED_UART2]  = 32,
> +[ASPEED_UART3]  = 33,
> +[ASPEED_UART4]  = 34,
> +[ASPEED_UART5]  = 10,
> +[ASPEED_VUART]  = 8,
> +[ASPEED_FMC]= 19,
> +[ASPEED_SDMC]   = 0,
> +[ASPEED_SCU]= 21,
> +[ASPEED_ADC]= 31,
> +[ASPEED_GPIO]   = 20,
> +[ASPEED_RTC]= 22,
> +[ASPEED_TIMER1] = 16,
> +[ASPEED_TIMER2] = 17,
> +[ASPEED_TIMER3] = 18,
> +[ASPEED_TIMER4] = 35,
> +[ASPEED_TIMER5] = 36,
> +[ASPEED_TIMER6] = 37,
> +[ASPEED_TIMER7] = 38,
> +[ASPEED_TIMER8] = 39,
> +[ASPEED_WDT]= 27,
> +[ASPEED_PWM]= 28,
> +[ASPEED_LPC]= 8,
> +[ASPEED_IBT]= 8, /* LPC */
> +[ASPEED_I2C]= 12,
> +[ASPEED_ETH1]   = 2,
> +[ASPEED_ETH2]   = 3,
> +};
>  
>  #define AST2400_SDRAM_BASE   0x4000
>  #define AST2500_SDRAM_BASE   0x8000
>  
> +/* AST2500 uses the same IRQs as the AST2400 */
> +#define aspeed_soc_ast2500_irqmap aspeed_soc_ast2400_irqmap
> +
>  static const hwaddr aspeed_soc_ast2400_spi_bases[] = { ASPEED_SOC_SPI_BASE };
>  static const char *aspeed_soc_ast2400_typenames[] = { "aspeed.smc.spi" };
>  
> @@ -64,6 +130,7 @@ static const AspeedSoCInfo aspeed_socs[] = {
>  .fmc_typename = "aspeed.smc.fmc",
>  .spi_typename = aspeed_soc_ast2400_typenames,
>  .wdts_num = 2,
> +.irqmap   = aspeed_soc_ast2400_irqmap,
>  }, {
>  .name = "ast2400-a1",
>  .cpu_type = ARM_CPU_TYPE_NAME("arm926"),
> @@ -75,6 +142,7 @@ static const AspeedSoCInfo aspeed_socs[] = {
>  .fmc_typename = "aspeed.smc.fmc",
>  .spi_typename = aspeed_soc_ast2400_typenames,
>  .wdts_num = 2,
> +.irqmap   = aspeed_soc_ast2400_irqmap,
>  }, {
>  .name = "ast2400",
>  .cpu_type = ARM_CPU_TYPE_NAME("arm926"),
> @@ -86,6 +154,7 @@ static const AspeedSoCInfo aspeed_socs[] = {
>  .fmc_typename = "aspeed.smc.fmc",
>  .spi_typename = aspeed_soc_ast2400_typenames,
>  .wdts_num = 2,
> +.irqmap   = aspeed_soc_ast2400_irqmap,
>  }, {
>  .name = "ast2500-a1",
>  .cpu_type = ARM_CPU_TYPE_NAME("arm1176"),
> @@ -97,9 +166,17 @@ static const AspeedSoCInfo aspeed_socs[] = {
>  .fmc_typename = "aspeed.smc.ast2500-fmc",
>  .spi_typename = aspeed_soc_ast2500_typenames,
>  .wdts_num = 3,
> +.irqmap   = aspeed_soc_ast2500_irqmap,
>  },
>  };
>  
> 

Re: [Qemu-devel] [PATCH 1/2] hw: timer: Add ASPEED RTC device

[Philippe Mathieu-Daudé]

Hi Peter,

On 4/11/19 5:30 PM, Cédric Le Goater wrote:
> On 4/11/19 5:25 PM, Peter Maydell wrote:
>> On Thu, 28 Mar 2019 at 06:22, Joel Stanley  wrote:
>>>
>>> Signed-off-by: Joel Stanley 
>>> Signed-off-by: Cédric Le Goater 
>>> ---
>>>  hw/timer/Makefile.objs|   2 +-
>>>  hw/timer/aspeed_rtc.c | 157 ++
>>>  hw/timer/trace-events |   4 +
>>>  include/hw/timer/aspeed_rtc.h |  31 +++
>>>  4 files changed, 193 insertions(+), 1 deletion(-)
>>>  create mode 100644 hw/timer/aspeed_rtc.c
>>>  create mode 100644 include/hw/timer/aspeed_rtc.h
>>>
>>> diff --git a/hw/timer/Makefile.objs b/hw/timer/Makefile.objs
>>> index 0e9a4530f848..123d92c9692c 100644
>>> --- a/hw/timer/Makefile.objs
>>> +++ b/hw/timer/Makefile.objs
>>> @@ -41,7 +41,7 @@ obj-$(CONFIG_MC146818RTC) += mc146818rtc.o
>>>  obj-$(CONFIG_ALLWINNER_A10_PIT) += allwinner-a10-pit.o
>>>
>>>  common-obj-$(CONFIG_STM32F2XX_TIMER) += stm32f2xx_timer.o
>>> -common-obj-$(CONFIG_ASPEED_SOC) += aspeed_timer.o
>>> +common-obj-$(CONFIG_ASPEED_SOC) += aspeed_timer.o aspeed_rtc.o
>>>
>>>  common-obj-$(CONFIG_SUN4V_RTC) += sun4v-rtc.o
>>>  common-obj-$(CONFIG_CMSDK_APB_TIMER) += cmsdk-apb-timer.o
>>> diff --git a/hw/timer/aspeed_rtc.c b/hw/timer/aspeed_rtc.c
>>> new file mode 100644
>>> index ..daccf00eccdc
>>> --- /dev/null
>>> +++ b/hw/timer/aspeed_rtc.c
>>> @@ -0,0 +1,157 @@
>>> +/*
>>> + * ASPEED Real Time Clock
>>> + * Joel Stanley 
>>> + *
>>> + * Copyright 2019 IBM Corp
>>> + * SPDX-License-Identifier: GPL-2.0-or-later
>>> + */
>>> +
>>> +#include "qemu/osdep.h"
>>> +#include "qemu-common.h"
>>> +#include "hw/timer/aspeed_rtc.h"
>>> +#include "qemu/log.h"
>>> +#include "qemu/timer.h"
>>> +
>>> +#include "trace.h"
>>> +
>>> +#define COUNTER1(0x00 / 4)
>>> +#define COUNTER2(0x04 / 4)
>>> +#define ALARM   (0x08 / 4)
>>> +#define CONTROL (0x10 / 4)
>>> +#define ALARM_STATUS(0x14 / 4)
>>
>> Not mandatory, but you might like the REG32() macro in
>> hw/registerfields.h which defines A_FOO and R_FOO
>> constants for you for the addresses and the indexes.
> 
> Yes. May be we should start using these macros in all our models.
> 
>>
>>> +
>>> +#define RTC_UNLOCKEDBIT(1)
>>> +#define RTC_ENABLED BIT(0)
>>> +
>>> +static void aspeed_rtc_calc_offset(AspeedRtcState *rtc)
>>> +{
>>> +struct tm tm;
>>> +uint32_t year, cent;
>>> +uint32_t reg1 = rtc->reg[COUNTER1];
>>> +uint32_t reg2 = rtc->reg[COUNTER2];
>>> +
>>> +tm.tm_mday = (reg1 >> 24) & 0x1f;
>>> +tm.tm_hour = (reg1 >> 16) & 0x1f;
>>> +tm.tm_min = (reg1 >> 8) & 0x3f;
>>> +tm.tm_sec = (reg1 >> 0) & 0x3f;
>>
>> Shift by zero ?
>>
>> Consider using extract32() rather than by-hand shift and mask.
> 
> What about the FIELD*() macros in hw/registerfields.h ?
> 
> Thanks,
> 
> C.
> 
>>
>>> +
>>> +cent = (reg2 >> 16) & 0x1f;
>>> +year = (reg2 >> 8) & 0x7f;
>>> +tm.tm_mon = ((reg2 >>  0) & 0x0f) - 1;
>>> +tm.tm_year = year + (cent * 100) - 1900;
>>> +
>>> +rtc->offset = qemu_timedate_diff();
>>> +}
>>> +
>>> +static uint32_t aspeed_rtc_get_counter(AspeedRtcState *rtc, int r)
>>> +{
>>> +uint32_t year, cent;
>>> +struct tm now;
>>> +
>>> +qemu_get_timedate(, rtc->offset);
>>> +
>>> +switch (r) {
>>> +case COUNTER1:
>>> +return (now.tm_mday << 24) | (now.tm_hour << 16) |
>>> +(now.tm_min << 8) | now.tm_sec;
>>> +case COUNTER2:
>>> +cent = (now.tm_year + 1900) / 100;
>>> +year = now.tm_year % 100;
>>> +return ((cent & 0x1f) << 16) | ((year & 0x7f) << 8) |
>>> +((now.tm_mon + 1) & 0xf);
>>> +default:
>>> +abort();
>>
>> More usually written g_assert_not_reached().
>>
>>> +}
>>> +}
>>> +
>>> +static uint64_t aspeed_rtc_read(void *opaque, hwaddr addr,
>>> +unsigned size)
>>> +{
>>> +AspeedRtcState *rtc = opaque;
>>> +uint64_t val;
>>> +uint32_t r = addr >> 2;
>>> +
>>> +switch (r) {
>>> +case COUNTER1:
>>> +case COUNTER2:
>>> +if (rtc->reg[CONTROL] & RTC_ENABLED) {
>>> +rtc->reg[r] = aspeed_rtc_get_counter(rtc, r);
>>> +}
>>
>> If this is deliberately going to fall through to the next
>> case then it should have a /* fall through */ comment
>> (ditto in the write fn).
>>
>>> +case ALARM:
>>> +case CONTROL:
>>> +case ALARM_STATUS:
>>> +val = rtc->reg[r];
>>> +break;
>>> +default:
>>> +qemu_log_mask(LOG_UNIMP, "%s: 0x%" HWADDR_PRIx "\n", __func__, 
>>> addr);
>>> +return 0;
>>> +}
>>> +
>>> +trace_aspeed_rtc_read(addr, val);
>>> +
>>> +return val;
>>> +}
>>
>>> +static void aspeed_rtc_class_init(ObjectClass *klass, void *data)
>>> +{
>>> +DeviceClass *dc = DEVICE_CLASS(klass);
>>> +
>>> +dc->realize = aspeed_rtc_realize;
>>
>> This is missing a reset function and vmstate.

Is vmstate mandatory for new devices?

>>
>> thanks
>> -- 

Re: [Qemu-devel] [qemu-s390x] [PATCH v4 1/6] vfio-ccw: make it safe to access channel programs

[Cornelia Huck]

On Thu, 11 Apr 2019 12:25:38 -0400
Eric Farman  wrote:

> On 4/11/19 11:58 AM, Halil Pasic wrote:
> > On Wed, 10 Apr 2019 22:59:41 -0400
> > Eric Farman  wrote:
> >   
> >> r the next release :) It would be one thing less on my plate...  
>  
> >>>
> >>> Sorry I was not able to spend any significant amount of time on this
> >>> lately.
> >>>
> >>> Gave the combined set (this + Farhans fio-ccw fixes for kernel
> >>> stacktraces v2) it a bit of smoke testing after some minor adjustments
> >>> to make it compile:
> >>>
> >>> --- a/drivers/s390/cio/vfio_ccw_ops.c
> >>> +++ b/drivers/s390/cio/vfio_ccw_ops.c
> >>> @@ -13,6 +13,7 @@
> >>>#include 
> >>>#include 
> >>>#include 
> >>> +#include 
> >>>
> >>>#include "vfio_ccw_private.h"
> >>>
> >>>  
> >>
> >> Hrm...  Taking today's master, and the two series you mention (slight
> >> adjustment to apply patch 3 of Connie's series, because part of it was
> >> split out a few weeks ago), and I don't encounter this.  Tried switching
> >> between SLUB/SLAB, but still compiles fine.  
> > 
> > Let me guess: you have CONFIG_PCI in our .config, right?
> > 
> > In arch/s390/include/asm/pci_io.h we have
> > 
> > #ifndef _ASM_S390_PCI_IO_H
> > #define _ASM_S390_PCI_IO_H
> > 
> > #ifdef CONFIG_PCI
> > 
> > #include 
> > #include 
> > 
> > and pci_io.h comes in via
> > 
> > include/linux/vfio.h
> > include/linux/iommu.h
> > include/linux/scatterlist.h
> > arch/s390/include/asm/io.h
> > arch/s390/include/asm/pci_io.h
> > 
> > 
> > Figured it out with help from Farhan. Took me quite some time.  
> 
> That would have been useful information up front.

Indeed. It's trivial to fold that change in, though :) (Should be in
patch 4, if I see it correctly.)

[Qemu-devel] [PATCH for-4.0] spapr_pci: Fix broken naming of PCI bus

[Greg Kurz]

Recent commit 5cf0d326a0fe fixed a regression which was preventing the
guest to access the extended config space of a PCIe device. This was
done by introducing a new PCI bus subtype for PAPR. The original fix
was causing PCI busses to be named "spapr-pci-host-bridge-root-bus.N"
instead of "pci.N", which was making upper layers unhappy of course.
This got worked around by hardcoding the PCI bus name to "pci.0", but
this only works for the default PHB. And we're now hitting:

# qemu-system-ppc64 \
 -device spapr-pci-host-bridge,index=1 \
 -device e1000e,bus=pci.0 \
 -device e1000e,bus=pci.1
qemu-system-ppc64: -device e1000e,bus=pci.1: Bus 'pci.1' not found

David already posted some patches [1] to control PCI extended config
space accesses with a new flag in the base PCI bus class instead of
subtyping. These patches are a bit more intrusive though, and
are targetted for 4.1.

When no name is passed to pci_register_bus(), the core device code
generates a lowercase name based on the QOM typename. The typename
for the base PCI bus class is "PCI", hence the "pci.0", "pci.1"
bus names. Rename the type of the PAPR PCI bus to "pci", so that
the QOM code can generate proper names. This is a hack but it is
enough to fix the regression. And all this will be reworked properly
in 4.1.

[1] https://patchwork.ozlabs.org/project/qemu-devel/list/?series=100486

Fixes: 5cf0d326a0fe
Signed-off-by: Greg Kurz 
---
 hw/ppc/spapr_pci.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
index f0b6b23afc9b..f62e6833b8c9 100644
--- a/hw/ppc/spapr_pci.c
+++ b/hw/ppc/spapr_pci.c
@@ -1652,7 +1652,7 @@ static void spapr_phb_root_bus_class_init(ObjectClass 
*klass, void *data)
 pbc->allows_extended_config_space = spapr_phb_allows_extended_config_space;
 }
 
-#define TYPE_SPAPR_PHB_ROOT_BUS "spapr-pci-host-bridge-root-bus"
+#define TYPE_SPAPR_PHB_ROOT_BUS "pci"
 
 static const TypeInfo spapr_phb_root_bus_info = {
 .name = TYPE_SPAPR_PHB_ROOT_BUS,
@@ -1761,7 +1761,7 @@ static void spapr_phb_realize(DeviceState *dev, Error 
**errp)
 memory_region_add_subregion(get_system_memory(), sphb->io_win_addr,
 >iowindow);
 
-bus = pci_register_root_bus(dev, "pci.0",
+bus = pci_register_root_bus(dev, NULL,
 pci_spapr_set_irq, pci_spapr_map_irq, sphb,
 >memspace, >iospace,
 PCI_DEVFN(0, 0), PCI_NUM_PINS,

Re: [Qemu-devel] [qemu-s390x] [PATCH v4 1/6] vfio-ccw: make it safe to access channel programs

[Eric Farman]

On 4/11/19 11:58 AM, Halil Pasic wrote:

On Wed, 10 Apr 2019 22:59:41 -0400
Eric Farman  wrote:


r the next release :) It would be one thing less on my plate...
  


Sorry I was not able to spend any significant amount of time on this
lately.

Gave the combined set (this + Farhans fio-ccw fixes for kernel
stacktraces v2) it a bit of smoke testing after some minor adjustments
to make it compile:

--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -13,6 +13,7 @@
   #include 
   #include 
   #include 
+#include 
   
   #include "vfio_ccw_private.h"


   


Hrm...  Taking today's master, and the two series you mention (slight
adjustment to apply patch 3 of Connie's series, because part of it was
split out a few weeks ago), and I don't encounter this.  Tried switching
between SLUB/SLAB, but still compiles fine.


Let me guess: you have CONFIG_PCI in our .config, right?

In arch/s390/include/asm/pci_io.h we have

#ifndef _ASM_S390_PCI_IO_H
#define _ASM_S390_PCI_IO_H

#ifdef CONFIG_PCI

#include 
#include 

and pci_io.h comes in via

include/linux/vfio.h
include/linux/iommu.h
include/linux/scatterlist.h
arch/s390/include/asm/io.h
arch/s390/include/asm/pci_io.h


Figured it out with help from Farhan. Took me quite some time.


That would have been useful information up front.



Regards,
Halil

Re: [Qemu-devel] [PATCH v5 1/6] libnvdimm: nd_region flush callback support

[Pankaj Gupta]

> > > > This patch adds functionality to perform flush from guest
> > > > to host over VIRTIO. We are registering a callback based
> > > > on 'nd_region' type. virtio_pmem driver requires this special
> > > > flush function. For rest of the region types we are registering
> > > > existing flush function. Report error returned by host fsync
> > > > failure to userspace.
> > > >
> > > > This also handles asynchronous flush requests from the block layer
> > > > by creating a child bio and chaining it with parent bio.
> > > >
> > > > Signed-off-by: Pankaj Gupta 
> > > > ---bio_chain Dan williams
> > > [..]
> > > > diff --git a/drivers/nvdimm/region_devs.c
> > > > b/drivers/nvdimm/region_devs.c
> > > > index b4ef7d9ff22e..fb1041ab32a6 100644
> > > > --- a/drivers/nvdimm/region_devs.c
> > > > +++ b/drivers/nvdimm/region_devs.c
> > > > @@ -295,7 +295,9 @@ static ssize_t deep_flush_store(struct device *dev,
> > > > struct device_attribute *att
> > > > return rc;
> > > > if (!flush)
> > > > return -EINVAL;
> > > > -   nvdimm_flush(nd_region);
> > > > +   rc = nvdimm_flush(nd_region, NULL, false);
> > > > +   if (rc)
> > > > +   return rc;
> > > >
> > > > return len;
> > > >  }
> > > > @@ -1085,6 +1087,11 @@ static struct nd_region *nd_region_create(struct
> > > > nvdimm_bus *nvdimm_bus,
> > > > dev->of_node = ndr_desc->of_node;
> > > > nd_region->ndr_size = resource_size(ndr_desc->res);
> > > > nd_region->ndr_start = ndr_desc->res->start;
> > > > +   if (ndr_desc->flush)
> > > > +   nd_region->flush = ndr_desc->flush;
> > > > +   else
> > > > +   nd_region->flush = generic_nvdimm_flush;
> > > > +
> > > > nd_device_register(dev);
> > > >
> > > > return nd_region;
> > > > @@ -1125,11 +1132,36 @@ struct nd_region
> > > > *nvdimm_volatile_region_create(struct nvdimm_bus *nvdimm_bus,
> > > >  }
> > > >  EXPORT_SYMBOL_GPL(nvdimm_volatile_region_create);
> > > >
> > > > +int nvdimm_flush(struct nd_region *nd_region, struct bio *bio, bool
> > > > async)
> > > > +{
> > >
> > > I don't quite see the point of the 'async' argument. All the usages of
> > > this routine are either
> > >
> > > nvdimm_flush(nd_region, bio, true)
> > > ...or:
> > > nvdimm_flush(nd_region, NULL, false)
> >
> > Agree.
> >
> > >
> > > ...so why not gate async behavior on the presence of the 'bio' argument?
> >
> > Sure.
> >
> > >
> > >
> > > > +   int rc = 0;
> > > > +
> > > > +   /* Create child bio for asynchronous flush and chain with
> > > > +* parent bio. Otherwise directly call nd_region flush.
> > > > +*/
> > > > +   if (async && bio->bi_iter.bi_sector != -1) {
> > > > +
> > > > +   struct bio *child = bio_alloc(GFP_ATOMIC, 0);
> > > > +
> > > > +   if (!child)
> > > > +   return -ENOMEM;
> > > > +   bio_copy_dev(child, bio);
> > > > +   child->bi_opf = REQ_PREFLUSH;
> > > > +   child->bi_iter.bi_sector = -1;
> > > > +   bio_chain(child, bio);
> > > > +   submit_bio(child);
> > >
> > > I understand how this works, but it's a bit too "magical" for my
> > > taste. I would prefer that all flush implementations take an optional
> > > 'bio' argument rather than rely on the make_request implementation to
> > > stash the bio away on a driver specific list.
> >
> > I did this to make use of "bio_chain" for chaining child bio for async
> > flush
> > suggested [1]. Are you saying to remove this and just call "flush" based on
> > bio argument? Or I implemented the 'bio_chain' request entirely wrong?
> 
> No, I think you implemented it correctly. I'm just asking for the
> chaining to be performed internal to the ->flush() callback rather
> than in the common nvdimm_flush() front-end.

Sure. Perfect!

Thank you very much for all the suggestions. 

Best regards,
Pankaj
> 

[Qemu-devel] [PATCH 2/3] aspeed: add a per SoC mapping for the memory space

[Cédric Le Goater]

This will simplify the definition of new SoCs, like the AST2600 which
should use a slightly different address space and have a different set
of controllers.

Signed-off-by: Cédric Le Goater 
---
 include/hw/arm/aspeed_soc.h |   2 +-
 hw/arm/aspeed_soc.c | 121 ++--
 2 files changed, 77 insertions(+), 46 deletions(-)

diff --git a/include/hw/arm/aspeed_soc.h b/include/hw/arm/aspeed_soc.h
index b0d266434288..eda9094660b5 100644
--- a/include/hw/arm/aspeed_soc.h
+++ b/include/hw/arm/aspeed_soc.h
@@ -53,11 +53,11 @@ typedef struct AspeedSoCInfo {
 hwaddr sdram_base;
 uint64_t sram_size;
 int spis_num;
-const hwaddr *spi_bases;
 const char *fmc_typename;
 const char **spi_typename;
 int wdts_num;
 const int *irqmap;
+const hwaddr *memmap;
 } AspeedSoCInfo;
 
 typedef struct AspeedSoCClass {
diff --git a/hw/arm/aspeed_soc.c b/hw/arm/aspeed_soc.c
index 5bbd1fb87d18..9b601709e93c 100644
--- a/hw/arm/aspeed_soc.c
+++ b/hw/arm/aspeed_soc.c
@@ -58,21 +58,58 @@ enum {
 ASPEED_SDRAM,
 };
 
-#define ASPEED_SOC_UART_5_BASE  0x00184000
 #define ASPEED_SOC_IOMEM_SIZE   0x0020
-#define ASPEED_SOC_IOMEM_BASE   0x1E60
-#define ASPEED_SOC_FMC_BASE 0x1E62
-#define ASPEED_SOC_SPI_BASE 0x1E63
-#define ASPEED_SOC_SPI2_BASE0x1E631000
-#define ASPEED_SOC_VIC_BASE 0x1E6C
-#define ASPEED_SOC_SDMC_BASE0x1E6E
-#define ASPEED_SOC_SCU_BASE 0x1E6E2000
-#define ASPEED_SOC_SRAM_BASE0x1E72
-#define ASPEED_SOC_TIMER_BASE   0x1E782000
-#define ASPEED_SOC_WDT_BASE 0x1E785000
-#define ASPEED_SOC_I2C_BASE 0x1E78A000
-#define ASPEED_SOC_ETH1_BASE0x1E66
-#define ASPEED_SOC_ETH2_BASE0x1E68
+
+static const hwaddr aspeed_soc_ast2400_memmap[] = {
+[ASPEED_IOMEM]  = 0x1E60,
+[ASPEED_FMC]= 0x1E62,
+[ASPEED_SPI1]   = 0x1E63,
+[ASPEED_VIC]= 0x1E6C,
+[ASPEED_SDMC]   = 0x1E6E,
+[ASPEED_SCU]= 0x1E6E2000,
+[ASPEED_ADC]= 0x1E6E9000,
+[ASPEED_SRAM]   = 0x1E72,
+[ASPEED_GPIO]   = 0x1E78,
+[ASPEED_RTC]= 0x1E781000,
+[ASPEED_TIMER1] = 0x1E782000,
+[ASPEED_WDT]= 0x1E785000,
+[ASPEED_PWM]= 0x1E786000,
+[ASPEED_LPC]= 0x1E789000,
+[ASPEED_IBT]= 0x1E789140,
+[ASPEED_I2C]= 0x1E78A000,
+[ASPEED_ETH1]   = 0x1E66,
+[ASPEED_ETH2]   = 0x1E68,
+[ASPEED_UART1]  = 0x1E783000,
+[ASPEED_UART5]  = 0x1E784000,
+[ASPEED_VUART]  = 0x1E787000,
+[ASPEED_SDRAM]  = 0x4000,
+};
+
+static const hwaddr aspeed_soc_ast2500_memmap[] = {
+[ASPEED_IOMEM]  = 0x1E60,
+[ASPEED_FMC]= 0x1E62,
+[ASPEED_SPI1]   = 0x1E63,
+[ASPEED_SPI2]   = 0x1E631000,
+[ASPEED_VIC]= 0x1E6C,
+[ASPEED_SDMC]   = 0x1E6E,
+[ASPEED_SCU]= 0x1E6E2000,
+[ASPEED_ADC]= 0x1E6E9000,
+[ASPEED_SRAM]   = 0x1E72,
+[ASPEED_GPIO]   = 0x1E78,
+[ASPEED_RTC]= 0x1E781000,
+[ASPEED_TIMER1] = 0x1E782000,
+[ASPEED_WDT]= 0x1E785000,
+[ASPEED_PWM]= 0x1E786000,
+[ASPEED_LPC]= 0x1E789000,
+[ASPEED_IBT]= 0x1E789140,
+[ASPEED_I2C]= 0x1E78A000,
+[ASPEED_ETH1]   = 0x1E66,
+[ASPEED_ETH2]   = 0x1E68,
+[ASPEED_UART1]  = 0x1E783000,
+[ASPEED_UART5]  = 0x1E784000,
+[ASPEED_VUART]  = 0x1E787000,
+[ASPEED_SDRAM]  = 0x8000,
+};
 
 static const int aspeed_soc_ast2400_irqmap[] = {
 [ASPEED_UART1]  = 9,
@@ -104,17 +141,9 @@ static const int aspeed_soc_ast2400_irqmap[] = {
 [ASPEED_ETH2]   = 3,
 };
 
-#define AST2400_SDRAM_BASE   0x4000
-#define AST2500_SDRAM_BASE   0x8000
-
-/* AST2500 uses the same IRQs as the AST2400 */
 #define aspeed_soc_ast2500_irqmap aspeed_soc_ast2400_irqmap
 
-static const hwaddr aspeed_soc_ast2400_spi_bases[] = { ASPEED_SOC_SPI_BASE };
 static const char *aspeed_soc_ast2400_typenames[] = { "aspeed.smc.spi" };
-
-static const hwaddr aspeed_soc_ast2500_spi_bases[] = { ASPEED_SOC_SPI_BASE,
-   ASPEED_SOC_SPI2_BASE};
 static const char *aspeed_soc_ast2500_typenames[] = {
 "aspeed.smc.ast2500-spi1", "aspeed.smc.ast2500-spi2" };
 
@@ -123,50 +152,50 @@ static const AspeedSoCInfo aspeed_socs[] = {
 .name = "ast2400-a0",
 .cpu_type = ARM_CPU_TYPE_NAME("arm926"),
 .silicon_rev  = AST2400_A0_SILICON_REV,
-.sdram_base   = AST2400_SDRAM_BASE,
+.sdram_base   = aspeed_soc_ast2400_memmap[ASPEED_SDRAM],
 .sram_size= 0x8000,
 .spis_num = 1,
-.spi_bases= aspeed_soc_ast2400_spi_bases,
 .fmc_typename = "aspeed.smc.fmc",
 .spi_typename = aspeed_soc_ast2400_typenames,
 .wdts_num = 2,
 .irqmap   = aspeed_soc_ast2400_irqmap,
+.memmap   = aspeed_soc_ast2400_memmap,
 }, {
 .name = 

[Qemu-devel] [PATCH 3/3] aspeed: use sysbus_init_child_obj() to initialize children

[Cédric Le Goater]

Signed-off-by: Cédric Le Goater 
---
 hw/arm/aspeed_soc.c | 50 ++---
 1 file changed, 20 insertions(+), 30 deletions(-)

diff --git a/hw/arm/aspeed_soc.c b/hw/arm/aspeed_soc.c
index 9b601709e93c..110956828c44 100644
--- a/hw/arm/aspeed_soc.c
+++ b/hw/arm/aspeed_soc.c
@@ -212,12 +212,11 @@ static void aspeed_soc_init(Object *obj)
 AspeedSoCClass *sc = ASPEED_SOC_GET_CLASS(s);
 int i;
 
-object_initialize(>cpu, sizeof(s->cpu), sc->info->cpu_type);
-object_property_add_child(obj, "cpu", OBJECT(>cpu), NULL);
+object_initialize_child(obj, "cpu", OBJECT(>cpu), sizeof(s->cpu),
+sc->info->cpu_type, _abort, NULL);
 
-object_initialize(>scu, sizeof(s->scu), TYPE_ASPEED_SCU);
-object_property_add_child(obj, "scu", OBJECT(>scu), NULL);
-qdev_set_parent_bus(DEVICE(>scu), sysbus_get_default());
+sysbus_init_child_obj(obj, "scu", OBJECT(>scu), sizeof(s->scu),
+  TYPE_ASPEED_SCU);
 qdev_prop_set_uint32(DEVICE(>scu), "silicon-rev",
  sc->info->silicon_rev);
 object_property_add_alias(obj, "hw-strap1", OBJECT(>scu),
@@ -227,36 +226,29 @@ static void aspeed_soc_init(Object *obj)
 object_property_add_alias(obj, "hw-prot-key", OBJECT(>scu),
   "hw-prot-key", _abort);
 
-object_initialize(>vic, sizeof(s->vic), TYPE_ASPEED_VIC);
-object_property_add_child(obj, "vic", OBJECT(>vic), NULL);
-qdev_set_parent_bus(DEVICE(>vic), sysbus_get_default());
+sysbus_init_child_obj(obj, "vic", OBJECT(>vic), sizeof(s->vic),
+  TYPE_ASPEED_VIC);
 
-object_initialize(>timerctrl, sizeof(s->timerctrl), TYPE_ASPEED_TIMER);
-object_property_add_child(obj, "timerctrl", OBJECT(>timerctrl), NULL);
+sysbus_init_child_obj(obj, "timerctrl", OBJECT(>timerctrl),
+  sizeof(s->timerctrl), TYPE_ASPEED_TIMER);
 object_property_add_const_link(OBJECT(>timerctrl), "scu",
OBJECT(>scu), _abort);
-qdev_set_parent_bus(DEVICE(>timerctrl), sysbus_get_default());
 
-object_initialize(>i2c, sizeof(s->i2c), TYPE_ASPEED_I2C);
-object_property_add_child(obj, "i2c", OBJECT(>i2c), NULL);
-qdev_set_parent_bus(DEVICE(>i2c), sysbus_get_default());
+sysbus_init_child_obj(obj, "i2c", OBJECT(>i2c), sizeof(s->i2c),
+  TYPE_ASPEED_I2C);
 
-object_initialize(>fmc, sizeof(s->fmc), sc->info->fmc_typename);
-object_property_add_child(obj, "fmc", OBJECT(>fmc), NULL);
-qdev_set_parent_bus(DEVICE(>fmc), sysbus_get_default());
+sysbus_init_child_obj(obj, "fmc", OBJECT(>fmc), sizeof(s->fmc),
+  sc->info->fmc_typename);
 object_property_add_alias(obj, "num-cs", OBJECT(>fmc), "num-cs",
   _abort);
 
 for (i = 0; i < sc->info->spis_num; i++) {
-object_initialize(>spi[i], sizeof(s->spi[i]),
-  sc->info->spi_typename[i]);
-object_property_add_child(obj, "spi[*]", OBJECT(>spi[i]), NULL);
-qdev_set_parent_bus(DEVICE(>spi[i]), sysbus_get_default());
+sysbus_init_child_obj(obj, "spi[*]", OBJECT(>spi[i]),
+  sizeof(s->spi[i]), sc->info->spi_typename[i]);
 }
 
-object_initialize(>sdmc, sizeof(s->sdmc), TYPE_ASPEED_SDMC);
-object_property_add_child(obj, "sdmc", OBJECT(>sdmc), NULL);
-qdev_set_parent_bus(DEVICE(>sdmc), sysbus_get_default());
+sysbus_init_child_obj(obj, "sdmc", OBJECT(>sdmc), sizeof(s->sdmc),
+  TYPE_ASPEED_SDMC);
 qdev_prop_set_uint32(DEVICE(>sdmc), "silicon-rev",
  sc->info->silicon_rev);
 object_property_add_alias(obj, "ram-size", OBJECT(>sdmc),
@@ -265,16 +257,14 @@ static void aspeed_soc_init(Object *obj)
   "max-ram-size", _abort);
 
 for (i = 0; i < sc->info->wdts_num; i++) {
-object_initialize(>wdt[i], sizeof(s->wdt[i]), TYPE_ASPEED_WDT);
-object_property_add_child(obj, "wdt[*]", OBJECT(>wdt[i]), NULL);
-qdev_set_parent_bus(DEVICE(>wdt[i]), sysbus_get_default());
+sysbus_init_child_obj(obj, "wdt[*]", OBJECT(>wdt[i]),
+  sizeof(s->wdt[i]), TYPE_ASPEED_WDT);
 qdev_prop_set_uint32(DEVICE(>wdt[i]), "silicon-rev",
 sc->info->silicon_rev);
 }
 
-object_initialize(>ftgmac100, sizeof(s->ftgmac100), TYPE_FTGMAC100);
-object_property_add_child(obj, "ftgmac100", OBJECT(>ftgmac100), NULL);
-qdev_set_parent_bus(DEVICE(>ftgmac100), sysbus_get_default());
+sysbus_init_child_obj(obj, "ftgmac100", OBJECT(>ftgmac100),
+  sizeof(s->ftgmac100), TYPE_FTGMAC100);
 }
 
 static void aspeed_soc_realize(DeviceState *dev, Error **errp)
-- 
2.20.1

[Qemu-devel] [PATCH 1/3] aspeed: add a per SoC mapping for the interrupt space

[Cédric Le Goater]

This will simplify the definition of new SoCs, like the AST2600 which
should use a different CPU and a different IRQ number layout.

Signed-off-by: Cédric Le Goater 
---
 include/hw/arm/aspeed_soc.h |  1 +
 hw/arm/aspeed_soc.c | 93 +
 2 files changed, 86 insertions(+), 8 deletions(-)

diff --git a/include/hw/arm/aspeed_soc.h b/include/hw/arm/aspeed_soc.h
index 11ec0179db50..b0d266434288 100644
--- a/include/hw/arm/aspeed_soc.h
+++ b/include/hw/arm/aspeed_soc.h
@@ -57,6 +57,7 @@ typedef struct AspeedSoCInfo {
 const char *fmc_typename;
 const char **spi_typename;
 int wdts_num;
+const int *irqmap;
 } AspeedSoCInfo;
 
 typedef struct AspeedSoCClass {
diff --git a/hw/arm/aspeed_soc.c b/hw/arm/aspeed_soc.c
index a27233d4876b..5bbd1fb87d18 100644
--- a/hw/arm/aspeed_soc.c
+++ b/hw/arm/aspeed_soc.c
@@ -22,6 +22,42 @@
 #include "hw/i2c/aspeed_i2c.h"
 #include "net/net.h"
 
+enum {
+ASPEED_IOMEM,
+ASPEED_UART1,
+ASPEED_UART2,
+ASPEED_UART3,
+ASPEED_UART4,
+ASPEED_UART5,
+ASPEED_VUART,
+ASPEED_FMC,
+ASPEED_SPI1,
+ASPEED_SPI2,
+ASPEED_VIC,
+ASPEED_SDMC,
+ASPEED_SCU,
+ASPEED_ADC,
+ASPEED_SRAM,
+ASPEED_GPIO,
+ASPEED_RTC,
+ASPEED_TIMER1,
+ASPEED_TIMER2,
+ASPEED_TIMER3,
+ASPEED_TIMER4,
+ASPEED_TIMER5,
+ASPEED_TIMER6,
+ASPEED_TIMER7,
+ASPEED_TIMER8,
+ASPEED_WDT,
+ASPEED_PWM,
+ASPEED_LPC,
+ASPEED_IBT,
+ASPEED_I2C,
+ASPEED_ETH1,
+ASPEED_ETH2,
+ASPEED_SDRAM,
+};
+
 #define ASPEED_SOC_UART_5_BASE  0x00184000
 #define ASPEED_SOC_IOMEM_SIZE   0x0020
 #define ASPEED_SOC_IOMEM_BASE   0x1E60
@@ -38,12 +74,42 @@
 #define ASPEED_SOC_ETH1_BASE0x1E66
 #define ASPEED_SOC_ETH2_BASE0x1E68
 
-static const int uart_irqs[] = { 9, 32, 33, 34, 10 };
-static const int timer_irqs[] = { 16, 17, 18, 35, 36, 37, 38, 39, };
+static const int aspeed_soc_ast2400_irqmap[] = {
+[ASPEED_UART1]  = 9,
+[ASPEED_UART2]  = 32,
+[ASPEED_UART3]  = 33,
+[ASPEED_UART4]  = 34,
+[ASPEED_UART5]  = 10,
+[ASPEED_VUART]  = 8,
+[ASPEED_FMC]= 19,
+[ASPEED_SDMC]   = 0,
+[ASPEED_SCU]= 21,
+[ASPEED_ADC]= 31,
+[ASPEED_GPIO]   = 20,
+[ASPEED_RTC]= 22,
+[ASPEED_TIMER1] = 16,
+[ASPEED_TIMER2] = 17,
+[ASPEED_TIMER3] = 18,
+[ASPEED_TIMER4] = 35,
+[ASPEED_TIMER5] = 36,
+[ASPEED_TIMER6] = 37,
+[ASPEED_TIMER7] = 38,
+[ASPEED_TIMER8] = 39,
+[ASPEED_WDT]= 27,
+[ASPEED_PWM]= 28,
+[ASPEED_LPC]= 8,
+[ASPEED_IBT]= 8, /* LPC */
+[ASPEED_I2C]= 12,
+[ASPEED_ETH1]   = 2,
+[ASPEED_ETH2]   = 3,
+};
 
 #define AST2400_SDRAM_BASE   0x4000
 #define AST2500_SDRAM_BASE   0x8000
 
+/* AST2500 uses the same IRQs as the AST2400 */
+#define aspeed_soc_ast2500_irqmap aspeed_soc_ast2400_irqmap
+
 static const hwaddr aspeed_soc_ast2400_spi_bases[] = { ASPEED_SOC_SPI_BASE };
 static const char *aspeed_soc_ast2400_typenames[] = { "aspeed.smc.spi" };
 
@@ -64,6 +130,7 @@ static const AspeedSoCInfo aspeed_socs[] = {
 .fmc_typename = "aspeed.smc.fmc",
 .spi_typename = aspeed_soc_ast2400_typenames,
 .wdts_num = 2,
+.irqmap   = aspeed_soc_ast2400_irqmap,
 }, {
 .name = "ast2400-a1",
 .cpu_type = ARM_CPU_TYPE_NAME("arm926"),
@@ -75,6 +142,7 @@ static const AspeedSoCInfo aspeed_socs[] = {
 .fmc_typename = "aspeed.smc.fmc",
 .spi_typename = aspeed_soc_ast2400_typenames,
 .wdts_num = 2,
+.irqmap   = aspeed_soc_ast2400_irqmap,
 }, {
 .name = "ast2400",
 .cpu_type = ARM_CPU_TYPE_NAME("arm926"),
@@ -86,6 +154,7 @@ static const AspeedSoCInfo aspeed_socs[] = {
 .fmc_typename = "aspeed.smc.fmc",
 .spi_typename = aspeed_soc_ast2400_typenames,
 .wdts_num = 2,
+.irqmap   = aspeed_soc_ast2400_irqmap,
 }, {
 .name = "ast2500-a1",
 .cpu_type = ARM_CPU_TYPE_NAME("arm1176"),
@@ -97,9 +166,17 @@ static const AspeedSoCInfo aspeed_socs[] = {
 .fmc_typename = "aspeed.smc.ast2500-fmc",
 .spi_typename = aspeed_soc_ast2500_typenames,
 .wdts_num = 3,
+.irqmap   = aspeed_soc_ast2500_irqmap,
 },
 };
 
+static qemu_irq aspeed_soc_get_irq(AspeedSoCState *s, int ctrl)
+{
+AspeedSoCClass *sc = ASPEED_SOC_GET_CLASS(s);
+
+return qdev_get_gpio_in(DEVICE(>vic), sc->info->irqmap[ctrl]);
+}
+
 static void aspeed_soc_init(Object *obj)
 {
 AspeedSoCState *s = ASPEED_SOC(obj);
@@ -226,14 +303,14 @@ static void aspeed_soc_realize(DeviceState *dev, Error 
**errp)
 return;
 }
 sysbus_mmio_map(SYS_BUS_DEVICE(>timerctrl), 0, ASPEED_SOC_TIMER_BASE);
-for (i = 0; i < ARRAY_SIZE(timer_irqs); i++) {
-qemu_irq irq = qdev_get_gpio_in(DEVICE(>vic), timer_irqs[i]);
+for (i = 

[Qemu-devel] [PATCH 0/3] aspeed: cleanups and extenstions

[Cédric Le Goater]

Hello,

Here is a series adding a couple of cleanups to the Aspeed SoCs to
prepare ground for extensions and new SoCs.

Thanks,

C.

Cédric Le Goater (3):
  aspeed: add a per SoC mapping for the interrupt space
  aspeed: add a per SoC mapping for the memory space
  aspeed: use sysbus_init_child_obj() to initialize children

 include/hw/arm/aspeed_soc.h |   3 +-
 hw/arm/aspeed_soc.c | 266 
 2 files changed, 184 insertions(+), 85 deletions(-)

-- 
2.20.1

Re: [Qemu-devel] [PATCH v5 1/6] libnvdimm: nd_region flush callback support

[Dan Williams]

On Thu, Apr 11, 2019 at 9:02 AM Pankaj Gupta  wrote:
>
>
>
> > >
> > > This patch adds functionality to perform flush from guest
> > > to host over VIRTIO. We are registering a callback based
> > > on 'nd_region' type. virtio_pmem driver requires this special
> > > flush function. For rest of the region types we are registering
> > > existing flush function. Report error returned by host fsync
> > > failure to userspace.
> > >
> > > This also handles asynchronous flush requests from the block layer
> > > by creating a child bio and chaining it with parent bio.
> > >
> > > Signed-off-by: Pankaj Gupta 
> > > ---bio_chain Dan williams
> > [..]
> > > diff --git a/drivers/nvdimm/region_devs.c b/drivers/nvdimm/region_devs.c
> > > index b4ef7d9ff22e..fb1041ab32a6 100644
> > > --- a/drivers/nvdimm/region_devs.c
> > > +++ b/drivers/nvdimm/region_devs.c
> > > @@ -295,7 +295,9 @@ static ssize_t deep_flush_store(struct device *dev,
> > > struct device_attribute *att
> > > return rc;
> > > if (!flush)
> > > return -EINVAL;
> > > -   nvdimm_flush(nd_region);
> > > +   rc = nvdimm_flush(nd_region, NULL, false);
> > > +   if (rc)
> > > +   return rc;
> > >
> > > return len;
> > >  }
> > > @@ -1085,6 +1087,11 @@ static struct nd_region *nd_region_create(struct
> > > nvdimm_bus *nvdimm_bus,
> > > dev->of_node = ndr_desc->of_node;
> > > nd_region->ndr_size = resource_size(ndr_desc->res);
> > > nd_region->ndr_start = ndr_desc->res->start;
> > > +   if (ndr_desc->flush)
> > > +   nd_region->flush = ndr_desc->flush;
> > > +   else
> > > +   nd_region->flush = generic_nvdimm_flush;
> > > +
> > > nd_device_register(dev);
> > >
> > > return nd_region;
> > > @@ -1125,11 +1132,36 @@ struct nd_region
> > > *nvdimm_volatile_region_create(struct nvdimm_bus *nvdimm_bus,
> > >  }
> > >  EXPORT_SYMBOL_GPL(nvdimm_volatile_region_create);
> > >
> > > +int nvdimm_flush(struct nd_region *nd_region, struct bio *bio, bool 
> > > async)
> > > +{
> >
> > I don't quite see the point of the 'async' argument. All the usages of
> > this routine are either
> >
> > nvdimm_flush(nd_region, bio, true)
> > ...or:
> > nvdimm_flush(nd_region, NULL, false)
>
> Agree.
>
> >
> > ...so why not gate async behavior on the presence of the 'bio' argument?
>
> Sure.
>
> >
> >
> > > +   int rc = 0;
> > > +
> > > +   /* Create child bio for asynchronous flush and chain with
> > > +* parent bio. Otherwise directly call nd_region flush.
> > > +*/
> > > +   if (async && bio->bi_iter.bi_sector != -1) {
> > > +
> > > +   struct bio *child = bio_alloc(GFP_ATOMIC, 0);
> > > +
> > > +   if (!child)
> > > +   return -ENOMEM;
> > > +   bio_copy_dev(child, bio);
> > > +   child->bi_opf = REQ_PREFLUSH;
> > > +   child->bi_iter.bi_sector = -1;
> > > +   bio_chain(child, bio);
> > > +   submit_bio(child);
> >
> > I understand how this works, but it's a bit too "magical" for my
> > taste. I would prefer that all flush implementations take an optional
> > 'bio' argument rather than rely on the make_request implementation to
> > stash the bio away on a driver specific list.
>
> I did this to make use of "bio_chain" for chaining child bio for async flush
> suggested [1]. Are you saying to remove this and just call "flush" based on
> bio argument? Or I implemented the 'bio_chain' request entirely wrong?

No, I think you implemented it correctly. I'm just asking for the
chaining to be performed internal to the ->flush() callback rather
than in the common nvdimm_flush() front-end.

Re: [Qemu-devel] [PATCH v4 10/10] iotests: test nbd reconnect

[Vladimir Sementsov-Ogievskiy]

16.01.2019 20:11, Eric Blake wrote:
> On 7/31/18 12:30 PM, Vladimir Sementsov-Ogievskiy wrote:
>> Add test, which starts backup to nbd target and restarts nbd server
>> during backup.
>>
>> Signed-off-by: Vladimir Sementsov-Ogievskiy 
>> ---
>>   tests/qemu-iotests/220| 67 
>> +++
>>   tests/qemu-iotests/220.out|  7 +
>>   tests/qemu-iotests/group  |  1 +
>>   tests/qemu-iotests/iotests.py |  4 +++
>>   4 files changed, 79 insertions(+)
>>   create mode 100755 tests/qemu-iotests/220
>>   create mode 100644 tests/qemu-iotests/220.out
>>
> 
> Test 220 has been created in the meantime; the obvious resolution is to
> pick a new test number.
> 
>> diff --git a/tests/qemu-iotests/220 b/tests/qemu-iotests/220
>> new file mode 100755
>> index 00..c9702a7dad
>> --- /dev/null
>> +++ b/tests/qemu-iotests/220
>> @@ -0,0 +1,67 @@
>> +#!/usr/bin/env python
> 
>> +
>> +import iotests
>> +from iotests import qemu_img_create, file_path, qemu_nbd_popen
>> +
>> +disk_a, disk_b, nbd_sock = file_path('disk_a', 'disk_b', 'nbd-sock')
>> +nbd_uri = 'nbd+unix:///exp?socket=' + nbd_sock
>> +
>> +qemu_img_create('-f', iotests.imgfmt, disk_a, '5M')
>> +qemu_img_create('-f', iotests.imgfmt, disk_b, '5M')
>> +srv = qemu_nbd_popen('-k', nbd_sock, '-x', 'exp', '-f', iotests.imgfmt, 
>> disk_b)
>> +time.sleep(1)
>> +
>> +vm = iotests.VM().add_drive(disk_a)
>> +vm.launch()
>> +vm.hmp_qemu_io('drive0', 'write 0 5M')
>> +
>> +print 'blockdev-add:', vm.qmp('blockdev-add', node_name='backup0', 
>> driver='raw',
>> +  file={'driver':'nbd',
>> +'export': 'exp',
>> +'server': {'type': 'unix',
>> +   'path': nbd_sock}})
>> +print 'blockdev-backup:', vm.qmp('blockdev-backup', device='drive0',
>> + sync='full', target='backup0')
>> +
>> +time.sleep(1)
>> +print 'Kill NBD server'
>> +srv.kill()
>> +
>> +jobs = vm.qmp('query-block-jobs')['return']
>> +if jobs and jobs[0]['offset'] < jobs[0]['len']:
>> +print 'Backup job is still in progress'
>> +
>> +time.sleep(1)
> 
> That's a lot of sleep()s for a test marked quick. Are we sure it won't
> fail under heavy load? Can you make the test more reliable by looking
> for specific events rather than just a fixed-length sleep?

Hmm.. 3 seconds is still quick I think.

Firstly I want nbd server to be actually started, but it has no events. Then I 
want
backup to do some progress, again, no event for progress. And the last one 
actual server
unavailable time.. So, I don't have better idea.

> 
>> +
>> +print 'Start NBD server'
>> +srv = qemu_nbd_popen('-k', nbd_sock, '-x', 'exp', '-f', iotests.imgfmt, 
>> disk_b)
>> +
>> +try:
>> +e = vm.event_wait('BLOCK_JOB_COMPLETED')
>> +print e['event'], ':', e['data']
>> +except:
>> +pass
>> +
>> +print 'blockdev-del:', vm.qmp('blockdev-del', node_name='backup0')
>> +srv.kill()
>> +vm.shutdown()
>> diff --git a/tests/qemu-iotests/220.out b/tests/qemu-iotests/220.out
>> new file mode 100644
>> index 00..dae1a49d9f
>> --- /dev/null
>> +++ b/tests/qemu-iotests/220.out
>> @@ -0,0 +1,7 @@
>> +blockdev-add: {u'return': {}}
>> +blockdev-backup: {u'return': {}}
>> +Kill NBD server
>> +Backup job is still in progress
>> +Start NBD server
>> +BLOCK_JOB_COMPLETED : {u'device': u'drive0', u'type': u'backup', u'speed': 
>> 0, u'len': 5242880, u'offset': 5242880}
>> +blockdev-del: {u'return': {}}
>> diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group
>> index b973dc842d..ee2473c6a3 100644
>> --- a/tests/qemu-iotests/group
>> +++ b/tests/qemu-iotests/group
>> @@ -219,6 +219,7 @@
>>   217 rw auto quick
>>   218 rw auto quick
>>   219 rw auto
>> +220 rw auto quick
>>   221 rw auto quick
>>   222 rw auto quick
>>   223 rw auto quick
>> diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
>> index 4e67fbbe96..17bc8c8e32 100644
>> --- a/tests/qemu-iotests/iotests.py
>> +++ b/tests/qemu-iotests/iotests.py
>> @@ -185,6 +185,10 @@ def qemu_nbd(*args):
>>   '''Run qemu-nbd in daemon mode and return the parent's exit code'''
>>   return subprocess.call(qemu_nbd_args + ['--fork'] + list(args))
>>   
>> +def qemu_nbd_popen(*args):
>> +'''Run qemu-nbd in daemon mode and return the parent's exit code'''
>> +return subprocess.Popen(qemu_nbd_args + ['--persistent'] + list(args))
>> +
>>   def compare_images(img1, img2, fmt1=imgfmt, fmt2=imgfmt):
>>   '''Return True if two image files are identical'''
>>   return qemu_img('compare', '-f', fmt1,
>>
> 


-- 
Best regards,
Vladimir

Re: [Qemu-devel] [qemu-s390x] [PATCH v4 1/6] vfio-ccw: make it safe to access channel programs

[Halil Pasic]

On Wed, 10 Apr 2019 22:59:41 -0400
Eric Farman  wrote:

> r the next release :) It would be one thing less on my plate...
> >>  
> > 
> > Sorry I was not able to spend any significant amount of time on this
> > lately.
> > 
> > Gave the combined set (this + Farhans fio-ccw fixes for kernel
> > stacktraces v2) it a bit of smoke testing after some minor adjustments
> > to make it compile:
> > 
> > --- a/drivers/s390/cio/vfio_ccw_ops.c
> > +++ b/drivers/s390/cio/vfio_ccw_ops.c
> > @@ -13,6 +13,7 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >   
> >   #include "vfio_ccw_private.h"
> > 
> >   
> 
> Hrm...  Taking today's master, and the two series you mention (slight 
> adjustment to apply patch 3 of Connie's series, because part of it was 
> split out a few weeks ago), and I don't encounter this.  Tried switching 
> between SLUB/SLAB, but still compiles fine.

Let me guess: you have CONFIG_PCI in our .config, right?

In arch/s390/include/asm/pci_io.h we have

#ifndef _ASM_S390_PCI_IO_H
#define _ASM_S390_PCI_IO_H

#ifdef CONFIG_PCI

#include 
#include 

and pci_io.h comes in via 

include/linux/vfio.h
include/linux/iommu.h
include/linux/scatterlist.h
arch/s390/include/asm/io.h
arch/s390/include/asm/pci_io.h


Figured it out with help from Farhan. Took me quite some time.

Regards,
Halil

Re: [Qemu-devel] [PATCH v5 1/6] libnvdimm: nd_region flush callback support

[Pankaj Gupta]

> >
> > This patch adds functionality to perform flush from guest
> > to host over VIRTIO. We are registering a callback based
> > on 'nd_region' type. virtio_pmem driver requires this special
> > flush function. For rest of the region types we are registering
> > existing flush function. Report error returned by host fsync
> > failure to userspace.
> >
> > This also handles asynchronous flush requests from the block layer
> > by creating a child bio and chaining it with parent bio.
> >
> > Signed-off-by: Pankaj Gupta 
> > ---bio_chain Dan williams
> [..]
> > diff --git a/drivers/nvdimm/region_devs.c b/drivers/nvdimm/region_devs.c
> > index b4ef7d9ff22e..fb1041ab32a6 100644
> > --- a/drivers/nvdimm/region_devs.c
> > +++ b/drivers/nvdimm/region_devs.c
> > @@ -295,7 +295,9 @@ static ssize_t deep_flush_store(struct device *dev,
> > struct device_attribute *att
> > return rc;
> > if (!flush)
> > return -EINVAL;
> > -   nvdimm_flush(nd_region);
> > +   rc = nvdimm_flush(nd_region, NULL, false);
> > +   if (rc)
> > +   return rc;
> >
> > return len;
> >  }
> > @@ -1085,6 +1087,11 @@ static struct nd_region *nd_region_create(struct
> > nvdimm_bus *nvdimm_bus,
> > dev->of_node = ndr_desc->of_node;
> > nd_region->ndr_size = resource_size(ndr_desc->res);
> > nd_region->ndr_start = ndr_desc->res->start;
> > +   if (ndr_desc->flush)
> > +   nd_region->flush = ndr_desc->flush;
> > +   else
> > +   nd_region->flush = generic_nvdimm_flush;
> > +
> > nd_device_register(dev);
> >
> > return nd_region;
> > @@ -1125,11 +1132,36 @@ struct nd_region
> > *nvdimm_volatile_region_create(struct nvdimm_bus *nvdimm_bus,
> >  }
> >  EXPORT_SYMBOL_GPL(nvdimm_volatile_region_create);
> >
> > +int nvdimm_flush(struct nd_region *nd_region, struct bio *bio, bool async)
> > +{
> 
> I don't quite see the point of the 'async' argument. All the usages of
> this routine are either
> 
> nvdimm_flush(nd_region, bio, true)
> ...or:
> nvdimm_flush(nd_region, NULL, false)

Agree.

> 
> ...so why not gate async behavior on the presence of the 'bio' argument?

Sure.

> 
> 
> > +   int rc = 0;
> > +
> > +   /* Create child bio for asynchronous flush and chain with
> > +* parent bio. Otherwise directly call nd_region flush.
> > +*/
> > +   if (async && bio->bi_iter.bi_sector != -1) {
> > +
> > +   struct bio *child = bio_alloc(GFP_ATOMIC, 0);
> > +
> > +   if (!child)
> > +   return -ENOMEM;
> > +   bio_copy_dev(child, bio);
> > +   child->bi_opf = REQ_PREFLUSH;
> > +   child->bi_iter.bi_sector = -1;
> > +   bio_chain(child, bio);
> > +   submit_bio(child);
> 
> I understand how this works, but it's a bit too "magical" for my
> taste. I would prefer that all flush implementations take an optional
> 'bio' argument rather than rely on the make_request implementation to
> stash the bio away on a driver specific list.

I did this to make use of "bio_chain" for chaining child bio for async flush
suggested [1]. Are you saying to remove this and just call "flush" based on 
bio argument? Or I implemented the 'bio_chain' request entirely wrong?

[1] https://lkml.org/lkml/2018/9/27/1028

> 
> > +   } else {
> > +   if (nd_region->flush(nd_region))
> > +   rc = -EIO;
> 
> Given the common case wants to be fast and synchronous I think we
> should try to avoid retpoline overhead by default. So something like
> this:
> 
> if (nd_region->flush == generic_nvdimm_flush)
> rc = generic_nvdimm_flush(...);

Sure.

Thanks,
Pankaj
> 
> 

Re: [Qemu-devel] [PATCH 00/17] Clean up and simplify around fprintf_function

[no-reply]

Patchew URL: https://patchew.org/QEMU/20190411152520.10061-1-arm...@redhat.com/



Hi,

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

Message-id: 20190411152520.10061-1-arm...@redhat.com
Subject: [Qemu-devel] [PATCH 00/17] Clean up and simplify around 
fprintf_function
Type: series

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag]   patchew/20190411152520.10061-1-arm...@redhat.com -> 
patchew/20190411152520.10061-1-arm...@redhat.com
 * [new tag]   
patchew/20190411153942.4533-1-peter.mayd...@linaro.org -> 
patchew/20190411153942.4533-1-peter.mayd...@linaro.org
Switched to a new branch 'test'
c57bf406e7 include: Move fprintf_function to disas/
3f40e31e61 disas: Rename include/disas/bfd.h back to include/disas/dis-asm.h
fc467535fe monitor: Clean up how monitor_disas() funnels output to monitor
2fee322e6c qom/cpu: Simplify how CPUClass:cpu_dump_state() prints
9cb032aa41 qemu-print: New qemu_fprintf(), qemu_vfprintf()
6266a2acbd qom/cpu: Simplify how CPUClass::dump_statistics() prints
46444d62f8 target/i386: Simplify how x86_cpu_dump_local_apic_state() prints
97d83bc9d1 target: Clean up how the dump_mmu() print
c218e3496f target: Simplify how the TARGET_cpu_list() print
de4fa45d1e memory: Clean up how mtree_info() prints
1776a3be10 block/qapi: Clean up how we print to monitor or stdout
7ab595d193 qsp: Simplify how qsp_report() prints
e21527b143 tcg: Simplify how dump_drift_info() prints
866fc3c2b0 tcg: Simplify how dump_exec_info() prints
2cb3665cd5 tcg: Simplify how dump_opcount_info() prints
251bcf57b3 trace: Simplify how st_print_trace_file_status() prints
d81fd6300c include: Include fprintf-fn.h only where needed

=== OUTPUT BEGIN ===
1/17 Checking commit d81fd6300c43 (include: Include fprintf-fn.h only where 
needed)
2/17 Checking commit 251bcf57b37a (trace: Simplify how 
st_print_trace_file_status() prints)
3/17 Checking commit 2cb3665cd56c (tcg: Simplify how dump_opcount_info() prints)
4/17 Checking commit 866fc3c2b030 (tcg: Simplify how dump_exec_info() prints)
5/17 Checking commit e21527b143e1 (tcg: Simplify how dump_drift_info() prints)
6/17 Checking commit 7ab595d1932b (qsp: Simplify how qsp_report() prints)
7/17 Checking commit 1776a3be104f (block/qapi: Clean up how we print to monitor 
or stdout)
8/17 Checking commit de4fa45d1ebc (memory: Clean up how mtree_info() prints)
9/17 Checking commit c218e3496fc1 (target: Simplify how the TARGET_cpu_list() 
print)
10/17 Checking commit 97d83bc9d139 (target: Clean up how the dump_mmu() print)
WARNING: line over 80 characters
#949: FILE: target/xtensa/mmu_helper.c:784:
+qemu_printf("\tVaddr   Paddr   ASID  Attr RWX 
Cache\n"

total: 0 errors, 1 warnings, 848 lines checked

Patch 10/17 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
11/17 Checking commit 46444d62f83d (target/i386: Simplify how 
x86_cpu_dump_local_apic_state() prints)
12/17 Checking commit 6266a2acbdda (qom/cpu: Simplify how 
CPUClass::dump_statistics() prints)
13/17 Checking commit 9cb032aa41f9 (qemu-print: New qemu_fprintf(), 
qemu_vfprintf())
14/17 Checking commit 2fee322e6cb8 (qom/cpu: Simplify how 
CPUClass:cpu_dump_state() prints)
ERROR: line over 90 characters
#1077: FILE: target/i386/helper.c:419:
+qemu_fprintf(f, "RAX=%016" PRIx64 " RBX=%016" PRIx64 " RCX=%016" 
PRIx64 " RDX=%016" PRIx64 "\n"

ERROR: line over 90 characters
#1078: FILE: target/i386/helper.c:420:
+ "RSI=%016" PRIx64 " RDI=%016" PRIx64 " RBP=%016" PRIx64 " 
RSP=%016" PRIx64 "\n"

ERROR: line over 90 characters
#1079: FILE: target/i386/helper.c:421:
+ "R8 =%016" PRIx64 " R9 =%016" PRIx64 " R10=%016" PRIx64 " 
R11=%016" PRIx64 "\n"

ERROR: line over 90 characters
#1080: FILE: target/i386/helper.c:422:
+ "R12=%016" PRIx64 " R13=%016" PRIx64 " R14=%016" PRIx64 " 
R15=%016" PRIx64 "\n"

ERROR: line over 90 characters
#1081: FILE: target/i386/helper.c:423:
+ "RIP=%016" PRIx64 " RFL=%08x [%c%c%c%c%c%c%c] CPL=%d 
II=%d A20=%d SMM=%d HLT=%d\n",

WARNING: line over 80 characters
#1189: FILE: target/i386/helper.c:494:
+qemu_fprintf(f, "CR0=%08x CR2=%016" PRIx64 " CR3=%016" PRIx64 " 
CR4=%08x\n",

WARNING: line over 80 characters
#1790: FILE: target/mips/translate.c:29791:
+qemu_fprintf(f, "CP0 Status  0x%08x Cause   0x%08x EPC0x" 
TARGET_FMT_lx "\n",

total: 5 errors, 2 warnings, 2583 lines checked

Patch 14/17 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, 

Re: [Qemu-devel] [PATCH v2 03/15] char-pty: Drop "char device redirected to" message

[Markus Armbruster]

Paolo Bonzini  writes:

> On 11/04/19 16:52, Markus Armbruster wrote:
>> char_pty_open() prints a "char device redirected to PTY_NAME (label
>> LABEL)" message to the current monitor or else to stderr.  No other
>> ChardevClass::open() prints anything on success.  Drop the message.
>> 
>> Cc: "Marc-André Lureau" 
>> Cc: Paolo Bonzini 
>> Signed-off-by: Markus Armbruster 
>> Reviewed-by: Marc-André Lureau 
>> ---
>>  chardev/char-pty.c | 2 --
>>  1 file changed, 2 deletions(-)
>> 
>> diff --git a/chardev/char-pty.c b/chardev/char-pty.c
>> index b034332edd..a48d3e5d20 100644
>> --- a/chardev/char-pty.c
>> +++ b/chardev/char-pty.c
>> @@ -211,8 +211,6 @@ static void char_pty_open(Chardev *chr,
>>  qemu_set_nonblock(master_fd);
>>  
>>  chr->filename = g_strdup_printf("pty:%s", pty_name);
>> -error_printf("char device redirected to %s (label %s)\n",
>> - pty_name, chr->label);
>>  
>>  s = PTY_CHARDEV(chr);
>>  s->ioc = QIO_CHANNEL(qio_channel_file_new_fd(master_fd));
>
> The reason for the message is that the char device is completely useless
> until the user knows the /dev/pts/N path[1].  You can get it with "info
> chardev" (aka query-chardev for QMP) but there's an interesting chicken
> and egg problem if the pty is for your monitor...
>
> Paolo

During review of v1, I wrote:

If we should decide the message is still useful enough to be worth
keeping, I could direct it to stdout instead of dropping it.

No clear conclusion emerged, so I did nothing for v2.  If we conclude to
keep the message now, I'll gladly do that.

> [1] once you know it, you can use the monitor's readline interface with
> e.g. "socat STDIO,cfmakeraw FILE:/dev/pts/1"

There's also

$ socat UNIX:/path/to/socket 
READLINE,history=$HOME/.hmp_history,prompt='(qemu) '

Lacks completion.  But then our very own reimplementation of readline
lacks any number of other features.

Re: [Qemu-devel] [PATCH 1/2] hw: timer: Add ASPEED RTC device

[Cédric Le Goater]

On 4/11/19 5:25 PM, Peter Maydell wrote:
> On Thu, 28 Mar 2019 at 06:22, Joel Stanley  wrote:
>>
>> Signed-off-by: Joel Stanley 
>> Signed-off-by: Cédric Le Goater 
>> ---
>>  hw/timer/Makefile.objs|   2 +-
>>  hw/timer/aspeed_rtc.c | 157 ++
>>  hw/timer/trace-events |   4 +
>>  include/hw/timer/aspeed_rtc.h |  31 +++
>>  4 files changed, 193 insertions(+), 1 deletion(-)
>>  create mode 100644 hw/timer/aspeed_rtc.c
>>  create mode 100644 include/hw/timer/aspeed_rtc.h
>>
>> diff --git a/hw/timer/Makefile.objs b/hw/timer/Makefile.objs
>> index 0e9a4530f848..123d92c9692c 100644
>> --- a/hw/timer/Makefile.objs
>> +++ b/hw/timer/Makefile.objs
>> @@ -41,7 +41,7 @@ obj-$(CONFIG_MC146818RTC) += mc146818rtc.o
>>  obj-$(CONFIG_ALLWINNER_A10_PIT) += allwinner-a10-pit.o
>>
>>  common-obj-$(CONFIG_STM32F2XX_TIMER) += stm32f2xx_timer.o
>> -common-obj-$(CONFIG_ASPEED_SOC) += aspeed_timer.o
>> +common-obj-$(CONFIG_ASPEED_SOC) += aspeed_timer.o aspeed_rtc.o
>>
>>  common-obj-$(CONFIG_SUN4V_RTC) += sun4v-rtc.o
>>  common-obj-$(CONFIG_CMSDK_APB_TIMER) += cmsdk-apb-timer.o
>> diff --git a/hw/timer/aspeed_rtc.c b/hw/timer/aspeed_rtc.c
>> new file mode 100644
>> index ..daccf00eccdc
>> --- /dev/null
>> +++ b/hw/timer/aspeed_rtc.c
>> @@ -0,0 +1,157 @@
>> +/*
>> + * ASPEED Real Time Clock
>> + * Joel Stanley 
>> + *
>> + * Copyright 2019 IBM Corp
>> + * SPDX-License-Identifier: GPL-2.0-or-later
>> + */
>> +
>> +#include "qemu/osdep.h"
>> +#include "qemu-common.h"
>> +#include "hw/timer/aspeed_rtc.h"
>> +#include "qemu/log.h"
>> +#include "qemu/timer.h"
>> +
>> +#include "trace.h"
>> +
>> +#define COUNTER1(0x00 / 4)
>> +#define COUNTER2(0x04 / 4)
>> +#define ALARM   (0x08 / 4)
>> +#define CONTROL (0x10 / 4)
>> +#define ALARM_STATUS(0x14 / 4)
> 
> Not mandatory, but you might like the REG32() macro in
> hw/registerfields.h which defines A_FOO and R_FOO
> constants for you for the addresses and the indexes.

Yes. May be we should start using these macros in all our models.

> 
>> +
>> +#define RTC_UNLOCKEDBIT(1)
>> +#define RTC_ENABLED BIT(0)
>> +
>> +static void aspeed_rtc_calc_offset(AspeedRtcState *rtc)
>> +{
>> +struct tm tm;
>> +uint32_t year, cent;
>> +uint32_t reg1 = rtc->reg[COUNTER1];
>> +uint32_t reg2 = rtc->reg[COUNTER2];
>> +
>> +tm.tm_mday = (reg1 >> 24) & 0x1f;
>> +tm.tm_hour = (reg1 >> 16) & 0x1f;
>> +tm.tm_min = (reg1 >> 8) & 0x3f;
>> +tm.tm_sec = (reg1 >> 0) & 0x3f;
> 
> Shift by zero ?
> 
> Consider using extract32() rather than by-hand shift and mask.

What about the FIELD*() macros in hw/registerfields.h ?

Thanks,

C.

> 
>> +
>> +cent = (reg2 >> 16) & 0x1f;
>> +year = (reg2 >> 8) & 0x7f;
>> +tm.tm_mon = ((reg2 >>  0) & 0x0f) - 1;
>> +tm.tm_year = year + (cent * 100) - 1900;
>> +
>> +rtc->offset = qemu_timedate_diff();
>> +}
>> +
>> +static uint32_t aspeed_rtc_get_counter(AspeedRtcState *rtc, int r)
>> +{
>> +uint32_t year, cent;
>> +struct tm now;
>> +
>> +qemu_get_timedate(, rtc->offset);
>> +
>> +switch (r) {
>> +case COUNTER1:
>> +return (now.tm_mday << 24) | (now.tm_hour << 16) |
>> +(now.tm_min << 8) | now.tm_sec;
>> +case COUNTER2:
>> +cent = (now.tm_year + 1900) / 100;
>> +year = now.tm_year % 100;
>> +return ((cent & 0x1f) << 16) | ((year & 0x7f) << 8) |
>> +((now.tm_mon + 1) & 0xf);
>> +default:
>> +abort();
> 
> More usually written g_assert_not_reached().
> 
>> +}
>> +}
>> +
>> +static uint64_t aspeed_rtc_read(void *opaque, hwaddr addr,
>> +unsigned size)
>> +{
>> +AspeedRtcState *rtc = opaque;
>> +uint64_t val;
>> +uint32_t r = addr >> 2;
>> +
>> +switch (r) {
>> +case COUNTER1:
>> +case COUNTER2:
>> +if (rtc->reg[CONTROL] & RTC_ENABLED) {
>> +rtc->reg[r] = aspeed_rtc_get_counter(rtc, r);
>> +}
> 
> If this is deliberately going to fall through to the next
> case then it should have a /* fall through */ comment
> (ditto in the write fn).
> 
>> +case ALARM:
>> +case CONTROL:
>> +case ALARM_STATUS:
>> +val = rtc->reg[r];
>> +break;
>> +default:
>> +qemu_log_mask(LOG_UNIMP, "%s: 0x%" HWADDR_PRIx "\n", __func__, 
>> addr);
>> +return 0;
>> +}
>> +
>> +trace_aspeed_rtc_read(addr, val);
>> +
>> +return val;
>> +}
> 
>> +static void aspeed_rtc_class_init(ObjectClass *klass, void *data)
>> +{
>> +DeviceClass *dc = DEVICE_CLASS(klass);
>> +
>> +dc->realize = aspeed_rtc_realize;
> 
> This is missing a reset function and vmstate.
> 
> thanks
> -- PMM
> 

Re: [Qemu-devel] [PATCH v4 08/10] block/nbd: add cmdline and qapi parameter reconnect-delay

[Vladimir Sementsov-Ogievskiy]

05.01.2019 1:25, Eric Blake wrote:
> On 7/31/18 12:30 PM, Vladimir Sementsov-Ogievskiy wrote:
>> Reconnect will be implemented in the following commit, so for now,
>> in semantics below, disconnect itself is a "serious error".
>>
>> Signed-off-by: Vladimir Sementsov-Ogievskiy 
>> ---
>>   qapi/block-core.json | 12 +++-
>>   block/nbd-client.h   |  1 +
>>   block/nbd-client.c   |  1 +
>>   block/nbd.c  | 16 +++-
>>   4 files changed, 28 insertions(+), 2 deletions(-)
>>
>> diff --git a/qapi/block-core.json b/qapi/block-core.json
>> index 5b9084a394..cf03402ec5 100644
>> --- a/qapi/block-core.json
>> +++ b/qapi/block-core.json
>> @@ -3511,13 +3511,23 @@
>>   #  traditional "base:allocation" block status (see
>>   #  NBD_OPT_LIST_META_CONTEXT in the NBD protocol) (since 
>> 3.0)
>>   #
>> +# @reconnect-delay: Reconnect delay. On disconnect, nbd client tries to 
>> connect
> 
> Maybe 'On unexpected disconnect', since intentional disconnect is not
> unexpected.
> 
>> +#   again, until success or serious error. During first
>> +#   @reconnect-delay seconds of reconnecting loop all 
>> requests
>> +#   are paused and have a chance to rerun, if successful
>> +#   connect occures during this time. After @reconnect-delay
> 
> occurs
> 
>> +#   seconds all delayed requests are failed and all 
>> following
>> +#   requests will be failed to (until successfull 
>> reconnect).
> 
> successful
> 
>> +#   Default 300 seconds (Since 3.1)
> 
> My delay in reviewing means this now has to be 4.0.
> 
> I'm guessing that a delay of 0 means disable auto-reconnect.

I doubt, as reconnect-delay=0 is a valid case, when all request are failed
(pre-patch behavior), but we still try to reconnect in background. Any reason
not to try? If any, I suggest one of the following:

1. treat absence of the option as no-reconnect-at-all. So absence and 0 would be
not the same

2. use -1 value as no-reconnect-at-all

3. additional bool option "reconnect"

>  From a
> backwards-compatibility standpoint, no auto-reconnect is more in line
> with what we previously had - but from a usability standpoint, trying to
> reconnect can avoid turning transient network hiccups into permanent
> loss of a device to EIO errors, especially if the retry timeout is long
> enough to allow an administrator to reroute the network to an
> alternative server.  So I'm probably okay with the default being
> non-zero - but it DOES mean that where you used to get instant EIO
> failures when a network connection was severed, you now have to wait for
> the reconnect delay to expire, and 5 minutes can be a long wait.  Since
> the long delay is guest-observable, can we run into issues where a guest
> that is currently used to instant EIO and total loss of the device could
> instead get confused by not getting any response for up to 5 minutes,
> whether or not that response eventually turns out to be EIO or a
> successful recovery?
> 
>> +++ b/block/nbd.c
>> @@ -360,6 +360,18 @@ static QemuOptsList nbd_runtime_opts = {
>>   .help = "experimental: expose named dirty bitmap in place of "
>>   "block status",
>>   },
>> +{
>> +.name = "reconnect-delay",
>> +.type = QEMU_OPT_NUMBER,
>> +.help = "Reconnect delay. On disconnect, nbd client tries to"
>> +"connect again, until success or serious error. During"
>> +"first @reconnect-delay seconds of reconnecting loop 
>> all"
>> +"requests are paused and have a chance to rerun, if"
>> +"successful connect occures during this time. After"
>> +"@reconnect-delay seconds all delayed requests are 
>> failed"
>> +"and all following requests will be failed to (until"
>> +"successfull reconnect). Default 300 seconds",
> 
> Same typos as in qapi.
> 
> The UI aspects look fine, now I need to review the patch series for code
> issues :)
> 
> 


-- 
Best regards,
Vladimir

Re: [Qemu-devel] [PATCH 2/2] hw/arm/aspeed: Add RTC to SoC

[Peter Maydell]

On Thu, 28 Mar 2019 at 06:22, Joel Stanley  wrote:
>
> Signed-off-by: Joel Stanley 
> Signed-off-by: Cédric Le Goater 
> ---
>  hw/arm/aspeed_soc.c | 15 +++
>  include/hw/arm/aspeed_soc.h |  2 ++
>  2 files changed, 17 insertions(+)
>
> diff --git a/hw/arm/aspeed_soc.c b/hw/arm/aspeed_soc.c
> index a27233d4876b..628ec633c91a 100644
> --- a/hw/arm/aspeed_soc.c
> +++ b/hw/arm/aspeed_soc.c
> @@ -32,6 +32,7 @@
>  #define ASPEED_SOC_SDMC_BASE0x1E6E
>  #define ASPEED_SOC_SCU_BASE 0x1E6E2000
>  #define ASPEED_SOC_SRAM_BASE0x1E72
> +#define ASPEED_SOC_RTC_BASE 0x1E781000
>  #define ASPEED_SOC_TIMER_BASE   0x1E782000
>  #define ASPEED_SOC_WDT_BASE 0x1E785000
>  #define ASPEED_SOC_I2C_BASE 0x1E78A000
> @@ -135,6 +136,10 @@ static void aspeed_soc_init(Object *obj)
>  object_property_add_child(obj, "i2c", OBJECT(>i2c), NULL);
>  qdev_set_parent_bus(DEVICE(>i2c), sysbus_get_default());
>
> +object_initialize(>rtc, sizeof(s->rtc), TYPE_ASPEED_RTC);
> +object_property_add_child(obj, "rtc", OBJECT(>rtc), NULL);
> +qdev_set_parent_bus(DEVICE(>rtc), sysbus_get_default());

These three lines should be written
   sysbus_init_child_obj(obj, "rtc", >rtc, sizeof(s->rtc),
 TYPE_ASPEED_RTC);

which is both shorter and also avoids leaking a reference to
the child object.

(We should also at some point fix the existing uses of this
pattern in this file.)


thanks
-- PMM