* [Qemu-devel] [PULL 1/5] i.MX: move i.MX31 CCM object to register array
2016-01-11 14:34 [Qemu-devel] [PULL 0/5] target-arm queue Peter Maydell
@ 2016-01-11 14:34 ` Peter Maydell
2016-01-11 14:34 ` [Qemu-devel] [PULL 2/5] hw/dma/xilinx_axidma: remove dead code Peter Maydell
` (3 subsequent siblings)
4 siblings, 0 replies; 16+ messages in thread
From: Peter Maydell @ 2016-01-11 14:34 UTC (permalink / raw)
To: qemu-devel
From: Jean-Christophe DUBOIS <jcd@tribudubois.net>
With this i.MX25 and i.MX31 will have closer implementations.
Moreover all i.MX31 CCM registers are now present.
Signed-off-by: Jean-Christophe Dubois <jcd@tribudubois.net>
Reviewed-by: Peter Crosthwaite <crosthwaite.peter@gmail.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
hw/misc/imx31_ccm.c | 188 ++++++++++++++++++++------------------------
include/hw/misc/imx31_ccm.h | 38 +++++++--
2 files changed, 115 insertions(+), 111 deletions(-)
diff --git a/hw/misc/imx31_ccm.c b/hw/misc/imx31_ccm.c
index b92d2e0..47d6ead 100644
--- a/hw/misc/imx31_ccm.c
+++ b/hw/misc/imx31_ccm.c
@@ -29,77 +29,73 @@
static char const *imx31_ccm_reg_name(uint32_t reg)
{
+ static char unknown[20];
+
switch (reg) {
- case 0:
+ case IMX31_CCM_CCMR_REG:
return "CCMR";
- case 1:
+ case IMX31_CCM_PDR0_REG:
return "PDR0";
- case 2:
+ case IMX31_CCM_PDR1_REG:
return "PDR1";
- case 3:
+ case IMX31_CCM_RCSR_REG:
return "RCSR";
- case 4:
+ case IMX31_CCM_MPCTL_REG:
return "MPCTL";
- case 5:
+ case IMX31_CCM_UPCTL_REG:
return "UPCTL";
- case 6:
+ case IMX31_CCM_SPCTL_REG:
return "SPCTL";
- case 7:
+ case IMX31_CCM_COSR_REG:
return "COSR";
- case 8:
+ case IMX31_CCM_CGR0_REG:
return "CGR0";
- case 9:
+ case IMX31_CCM_CGR1_REG:
return "CGR1";
- case 10:
+ case IMX31_CCM_CGR2_REG:
return "CGR2";
- case 11:
+ case IMX31_CCM_WIMR_REG:
return "WIMR";
- case 12:
+ case IMX31_CCM_LDC_REG:
return "LDC";
- case 13:
+ case IMX31_CCM_DCVR0_REG:
return "DCVR0";
- case 14:
+ case IMX31_CCM_DCVR1_REG:
return "DCVR1";
- case 15:
+ case IMX31_CCM_DCVR2_REG:
return "DCVR2";
- case 16:
+ case IMX31_CCM_DCVR3_REG:
return "DCVR3";
- case 17:
+ case IMX31_CCM_LTR0_REG:
return "LTR0";
- case 18:
+ case IMX31_CCM_LTR1_REG:
return "LTR1";
- case 19:
+ case IMX31_CCM_LTR2_REG:
return "LTR2";
- case 20:
+ case IMX31_CCM_LTR3_REG:
return "LTR3";
- case 21:
+ case IMX31_CCM_LTBR0_REG:
return "LTBR0";
- case 22:
+ case IMX31_CCM_LTBR1_REG:
return "LTBR1";
- case 23:
+ case IMX31_CCM_PMCR0_REG:
return "PMCR0";
- case 24:
+ case IMX31_CCM_PMCR1_REG:
return "PMCR1";
- case 25:
+ case IMX31_CCM_PDR2_REG:
return "PDR2";
default:
- return "???";
+ sprintf(unknown, "[%d ?]", reg);
+ return unknown;
}
}
static const VMStateDescription vmstate_imx31_ccm = {
.name = TYPE_IMX31_CCM,
- .version_id = 1,
- .minimum_version_id = 1,
+ .version_id = 2,
+ .minimum_version_id = 2,
.fields = (VMStateField[]) {
- VMSTATE_UINT32(ccmr, IMX31CCMState),
- VMSTATE_UINT32(pdr0, IMX31CCMState),
- VMSTATE_UINT32(pdr1, IMX31CCMState),
- VMSTATE_UINT32(mpctl, IMX31CCMState),
- VMSTATE_UINT32(spctl, IMX31CCMState),
- VMSTATE_UINT32_ARRAY(cgr, IMX31CCMState, 3),
- VMSTATE_UINT32(pmcr0, IMX31CCMState),
- VMSTATE_UINT32(pmcr1, IMX31CCMState),
+ VMSTATE_UINT32_ARRAY(reg, IMX31CCMState, IMX31_CCM_MAX_REG),
VMSTATE_END_OF_LIST()
},
};
@@ -109,10 +105,10 @@ static uint32_t imx31_ccm_get_pll_ref_clk(IMXCCMState *dev)
uint32_t freq = 0;
IMX31CCMState *s = IMX31_CCM(dev);
- if ((s->ccmr & CCMR_PRCS) == 2) {
- if (s->ccmr & CCMR_FPME) {
+ if ((s->reg[IMX31_CCM_CCMR_REG] & CCMR_PRCS) == 2) {
+ if (s->reg[IMX31_CCM_CCMR_REG] & CCMR_FPME) {
freq = CKIL_FREQ;
- if (s->ccmr & CCMR_FPMF) {
+ if (s->reg[IMX31_CCM_CCMR_REG] & CCMR_FPMF) {
freq *= 1024;
}
}
@@ -130,7 +126,8 @@ static uint32_t imx31_ccm_get_mpll_clk(IMXCCMState *dev)
uint32_t freq;
IMX31CCMState *s = IMX31_CCM(dev);
- freq = imx_ccm_calc_pll(s->mpctl, imx31_ccm_get_pll_ref_clk(dev));
+ freq = imx_ccm_calc_pll(s->reg[IMX31_CCM_MPCTL_REG],
+ imx31_ccm_get_pll_ref_clk(dev));
DPRINTF("freq = %d\n", freq);
@@ -142,7 +139,8 @@ static uint32_t imx31_ccm_get_mcu_main_clk(IMXCCMState *dev)
uint32_t freq;
IMX31CCMState *s = IMX31_CCM(dev);
- if ((s->ccmr & CCMR_MDS) || !(s->ccmr & CCMR_MPE)) {
+ if ((s->reg[IMX31_CCM_CCMR_REG] & CCMR_MDS) ||
+ !(s->reg[IMX31_CCM_CCMR_REG] & CCMR_MPE)) {
freq = imx31_ccm_get_pll_ref_clk(dev);
} else {
freq = imx31_ccm_get_mpll_clk(dev);
@@ -158,7 +156,8 @@ static uint32_t imx31_ccm_get_mcu_clk(IMXCCMState *dev)
uint32_t freq;
IMX31CCMState *s = IMX31_CCM(dev);
- freq = imx31_ccm_get_mcu_main_clk(dev) / (1 + EXTRACT(s->pdr0, MCU));
+ freq = imx31_ccm_get_mcu_main_clk(dev)
+ / (1 + EXTRACT(s->reg[IMX31_CCM_PDR0_REG], MCU));
DPRINTF("freq = %d\n", freq);
@@ -170,7 +169,8 @@ static uint32_t imx31_ccm_get_hsp_clk(IMXCCMState *dev)
uint32_t freq;
IMX31CCMState *s = IMX31_CCM(dev);
- freq = imx31_ccm_get_mcu_main_clk(dev) / (1 + EXTRACT(s->pdr0, HSP));
+ freq = imx31_ccm_get_mcu_main_clk(dev)
+ / (1 + EXTRACT(s->reg[IMX31_CCM_PDR0_REG], HSP));
DPRINTF("freq = %d\n", freq);
@@ -182,7 +182,8 @@ static uint32_t imx31_ccm_get_hclk_clk(IMXCCMState *dev)
uint32_t freq;
IMX31CCMState *s = IMX31_CCM(dev);
- freq = imx31_ccm_get_mcu_main_clk(dev) / (1 + EXTRACT(s->pdr0, MAX));
+ freq = imx31_ccm_get_mcu_main_clk(dev)
+ / (1 + EXTRACT(s->reg[IMX31_CCM_PDR0_REG], MAX));
DPRINTF("freq = %d\n", freq);
@@ -194,7 +195,8 @@ static uint32_t imx31_ccm_get_ipg_clk(IMXCCMState *dev)
uint32_t freq;
IMX31CCMState *s = IMX31_CCM(dev);
- freq = imx31_ccm_get_hclk_clk(dev) / (1 + EXTRACT(s->pdr0, IPG));
+ freq = imx31_ccm_get_hclk_clk(dev)
+ / (1 + EXTRACT(s->reg[IMX31_CCM_PDR0_REG], IPG));
DPRINTF("freq = %d\n", freq);
@@ -237,14 +239,24 @@ static void imx31_ccm_reset(DeviceState *dev)
DPRINTF("()\n");
- s->ccmr = 0x074b0b7d;
- s->pdr0 = 0xff870b48;
- s->pdr1 = 0x49fcfe7f;
- s->mpctl = 0x04001800;
- s->cgr[0] = s->cgr[1] = s->cgr[2] = 0xffffffff;
- s->spctl = 0x04043001;
- s->pmcr0 = 0x80209828;
- s->pmcr1 = 0x00aa0000;
+ memset(s->reg, 0, sizeof(uint32_t) * IMX31_CCM_MAX_REG);
+
+ s->reg[IMX31_CCM_CCMR_REG] = 0x074b0b7d;
+ s->reg[IMX31_CCM_PDR0_REG] = 0xff870b48;
+ s->reg[IMX31_CCM_PDR1_REG] = 0x49fcfe7f;
+ s->reg[IMX31_CCM_RCSR_REG] = 0x007f0000;
+ s->reg[IMX31_CCM_MPCTL_REG] = 0x04001800;
+ s->reg[IMX31_CCM_UPCTL_REG] = 0x04051c03;
+ s->reg[IMX31_CCM_SPCTL_REG] = 0x04043001;
+ s->reg[IMX31_CCM_COSR_REG] = 0x00000280;
+ s->reg[IMX31_CCM_CGR0_REG] = 0xffffffff;
+ s->reg[IMX31_CCM_CGR1_REG] = 0xffffffff;
+ s->reg[IMX31_CCM_CGR2_REG] = 0xffffffff;
+ s->reg[IMX31_CCM_WIMR_REG] = 0xffffffff;
+ s->reg[IMX31_CCM_LTR1_REG] = 0x00004040;
+ s->reg[IMX31_CCM_PMCR0_REG] = 0x80209828;
+ s->reg[IMX31_CCM_PMCR1_REG] = 0x00aa0000;
+ s->reg[IMX31_CCM_PDR2_REG] = 0x00000285;
}
static uint64_t imx31_ccm_read(void *opaque, hwaddr offset, unsigned size)
@@ -252,41 +264,11 @@ static uint64_t imx31_ccm_read(void *opaque, hwaddr offset, unsigned size)
uint32 value = 0;
IMX31CCMState *s = (IMX31CCMState *)opaque;
- switch (offset >> 2) {
- case 0: /* CCMR */
- value = s->ccmr;
- break;
- case 1:
- value = s->pdr0;
- break;
- case 2:
- value = s->pdr1;
- break;
- case 4:
- value = s->mpctl;
- break;
- case 6:
- value = s->spctl;
- break;
- case 8:
- value = s->cgr[0];
- break;
- case 9:
- value = s->cgr[1];
- break;
- case 10:
- value = s->cgr[2];
- break;
- case 18: /* LTR1 */
- value = 0x00004040;
- break;
- case 23:
- value = s->pmcr0;
- break;
- default:
+ if ((offset >> 2) < IMX31_CCM_MAX_REG) {
+ value = s->reg[offset >> 2];
+ } else {
qemu_log_mask(LOG_GUEST_ERROR, "[%s]%s: Bad register at offset 0x%"
HWADDR_PRIx "\n", TYPE_IMX31_CCM, __func__, offset);
- break;
}
DPRINTF("reg[%s] => 0x%" PRIx32 "\n", imx31_ccm_reg_name(offset >> 2),
@@ -304,29 +286,29 @@ static void imx31_ccm_write(void *opaque, hwaddr offset, uint64_t value,
(uint32_t)value);
switch (offset >> 2) {
- case 0:
- s->ccmr = CCMR_FPMF | (value & 0x3b6fdfff);
+ case IMX31_CCM_CCMR_REG:
+ s->reg[IMX31_CCM_CCMR_REG] = CCMR_FPMF | (value & 0x3b6fdfff);
break;
- case 1:
- s->pdr0 = value & 0xff9f3fff;
+ case IMX31_CCM_PDR0_REG:
+ s->reg[IMX31_CCM_PDR0_REG] = value & 0xff9f3fff;
break;
- case 2:
- s->pdr1 = value;
+ case IMX31_CCM_PDR1_REG:
+ s->reg[IMX31_CCM_PDR1_REG] = value;
break;
- case 4:
- s->mpctl = value & 0xbfff3fff;
+ case IMX31_CCM_MPCTL_REG:
+ s->reg[IMX31_CCM_MPCTL_REG] = value & 0xbfff3fff;
break;
- case 6:
- s->spctl = value & 0xbfff3fff;
+ case IMX31_CCM_SPCTL_REG:
+ s->reg[IMX31_CCM_SPCTL_REG] = value & 0xbfff3fff;
break;
- case 8:
- s->cgr[0] = value;
+ case IMX31_CCM_CGR0_REG:
+ s->reg[IMX31_CCM_CGR0_REG] = value;
break;
- case 9:
- s->cgr[1] = value;
+ case IMX31_CCM_CGR1_REG:
+ s->reg[IMX31_CCM_CGR1_REG] = value;
break;
- case 10:
- s->cgr[2] = value;
+ case IMX31_CCM_CGR2_REG:
+ s->reg[IMX31_CCM_CGR2_REG] = value;
break;
default:
qemu_log_mask(LOG_GUEST_ERROR, "[%s]%s: Bad register at offset 0x%"
diff --git a/include/hw/misc/imx31_ccm.h b/include/hw/misc/imx31_ccm.h
index fcae36d..c376fad 100644
--- a/include/hw/misc/imx31_ccm.h
+++ b/include/hw/misc/imx31_ccm.h
@@ -13,6 +13,34 @@
#include "hw/misc/imx_ccm.h"
+#define IMX31_CCM_CCMR_REG 0
+#define IMX31_CCM_PDR0_REG 1
+#define IMX31_CCM_PDR1_REG 2
+#define IMX31_CCM_RCSR_REG 3
+#define IMX31_CCM_MPCTL_REG 4
+#define IMX31_CCM_UPCTL_REG 5
+#define IMX31_CCM_SPCTL_REG 6
+#define IMX31_CCM_COSR_REG 7
+#define IMX31_CCM_CGR0_REG 8
+#define IMX31_CCM_CGR1_REG 9
+#define IMX31_CCM_CGR2_REG 10
+#define IMX31_CCM_WIMR_REG 11
+#define IMX31_CCM_LDC_REG 12
+#define IMX31_CCM_DCVR0_REG 13
+#define IMX31_CCM_DCVR1_REG 14
+#define IMX31_CCM_DCVR2_REG 15
+#define IMX31_CCM_DCVR3_REG 16
+#define IMX31_CCM_LTR0_REG 17
+#define IMX31_CCM_LTR1_REG 18
+#define IMX31_CCM_LTR2_REG 19
+#define IMX31_CCM_LTR3_REG 20
+#define IMX31_CCM_LTBR0_REG 21
+#define IMX31_CCM_LTBR1_REG 22
+#define IMX31_CCM_PMCR0_REG 23
+#define IMX31_CCM_PMCR1_REG 24
+#define IMX31_CCM_PDR2_REG 25
+#define IMX31_CCM_MAX_REG 26
+
/* CCMR */
#define CCMR_FPME (1<<0)
#define CCMR_MPE (1<<3)
@@ -53,14 +81,8 @@ typedef struct IMX31CCMState {
/* <public> */
MemoryRegion iomem;
- uint32_t ccmr;
- uint32_t pdr0;
- uint32_t pdr1;
- uint32_t mpctl;
- uint32_t spctl;
- uint32_t cgr[3];
- uint32_t pmcr0;
- uint32_t pmcr1;
+ uint32_t reg[IMX31_CCM_MAX_REG];
+
} IMX31CCMState;
#endif /* IMX31_CCM_H */
--
1.9.1
^ permalink raw reply related [flat|nested] 16+ messages in thread* [Qemu-devel] [PULL 2/5] hw/dma/xilinx_axidma: remove dead code
2016-01-11 14:34 [Qemu-devel] [PULL 0/5] target-arm queue Peter Maydell
2016-01-11 14:34 ` [Qemu-devel] [PULL 1/5] i.MX: move i.MX31 CCM object to register array Peter Maydell
@ 2016-01-11 14:34 ` Peter Maydell
2016-01-11 14:34 ` [Qemu-devel] [PULL 3/5] xlnx-zynqmp: Add support for high DDR memory regions Peter Maydell
` (2 subsequent siblings)
4 siblings, 0 replies; 16+ messages in thread
From: Peter Maydell @ 2016-01-11 14:34 UTC (permalink / raw)
To: qemu-devel
From: Andrew Jones <drjones@redhat.com>
stream_desc_show() (and DEBUG_ENET) appear to be unused, as the
function isn't compilable (there are broken PRI format strings).
Signed-off-by: Andrew Jones <drjones@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@xilinx.com>
Message-id: 1452084792-17424-1-git-send-email-drjones@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
hw/dma/xilinx_axidma.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/hw/dma/xilinx_axidma.c b/hw/dma/xilinx_axidma.c
index b1cfa11..f5ebc1f 100644
--- a/hw/dma/xilinx_axidma.c
+++ b/hw/dma/xilinx_axidma.c
@@ -177,16 +177,6 @@ static inline int streamid_from_addr(hwaddr addr)
return sid;
}
-#ifdef DEBUG_ENET
-static void stream_desc_show(struct SDesc *d)
-{
- qemu_log("buffer_addr = " PRIx64 "\n", d->buffer_address);
- qemu_log("nxtdesc = " PRIx64 "\n", d->nxtdesc);
- qemu_log("control = %x\n", d->control);
- qemu_log("status = %x\n", d->status);
-}
-#endif
-
static void stream_desc_load(struct Stream *s, hwaddr addr)
{
struct SDesc *d = &s->desc;
--
1.9.1
^ permalink raw reply related [flat|nested] 16+ messages in thread* [Qemu-devel] [PULL 3/5] xlnx-zynqmp: Add support for high DDR memory regions
2016-01-11 14:34 [Qemu-devel] [PULL 0/5] target-arm queue Peter Maydell
2016-01-11 14:34 ` [Qemu-devel] [PULL 1/5] i.MX: move i.MX31 CCM object to register array Peter Maydell
2016-01-11 14:34 ` [Qemu-devel] [PULL 2/5] hw/dma/xilinx_axidma: remove dead code Peter Maydell
@ 2016-01-11 14:34 ` Peter Maydell
2016-01-11 14:34 ` [Qemu-devel] [PULL 5/5] hw/arm/virt: Support legacy -nic command line syntax Peter Maydell
2016-01-11 16:11 ` [Qemu-devel] [PULL 0/5] target-arm queue Peter Maydell
4 siblings, 0 replies; 16+ messages in thread
From: Peter Maydell @ 2016-01-11 14:34 UTC (permalink / raw)
To: qemu-devel
From: Alistair Francis <alistair.francis@xilinx.com>
The Xilinx ZynqMP SoC and EP108 board supports three memory regions:
- A 2GB region starting at 0
- A 32GB region starting at 32GB
- A 256GB region starting at 768GB
This patch adds support for the first two memory regions, which is
automatically created based on the size specified by the QEMU memory
command line argument.
On hardware the physical memory region is one continuous region, it is then
mapped into the three different regions by the DDRC. As we don't model the
DDRC this is done at startup by QEMU. The board creates the memory region and
then passes that memory region to the SoC. The SoC then maps the memory
regions.
Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
Reviewed-by: Peter Crosthwaite <crosthwaite.peter@gmail.com>
Message-id: 629c613cae9234bed1e7d362209a2ea1d6f92a21.1452031236.git.alistair.francis@xilinx.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
hw/arm/xlnx-ep108.c | 35 ++++++++++++++++++-----------------
hw/arm/xlnx-zynqmp.c | 37 +++++++++++++++++++++++++++++++++++++
include/hw/arm/xlnx-zynqmp.h | 12 ++++++++++++
3 files changed, 67 insertions(+), 17 deletions(-)
diff --git a/hw/arm/xlnx-ep108.c b/hw/arm/xlnx-ep108.c
index 85b978f..1c34774 100644
--- a/hw/arm/xlnx-ep108.c
+++ b/hw/arm/xlnx-ep108.c
@@ -25,9 +25,6 @@ typedef struct XlnxEP108 {
MemoryRegion ddr_ram;
} XlnxEP108;
-/* Max 2GB RAM */
-#define EP108_MAX_RAM_SIZE 0x80000000ull
-
static struct arm_boot_info xlnx_ep108_binfo;
static void xlnx_ep108_init(MachineState *machine)
@@ -35,20 +32,12 @@ static void xlnx_ep108_init(MachineState *machine)
XlnxEP108 *s = g_new0(XlnxEP108, 1);
Error *err = NULL;
- object_initialize(&s->soc, sizeof(s->soc), TYPE_XLNX_ZYNQMP);
- object_property_add_child(OBJECT(machine), "soc", OBJECT(&s->soc),
- &error_abort);
-
- object_property_set_bool(OBJECT(&s->soc), true, "realized", &err);
- if (err) {
- error_report("%s", error_get_pretty(err));
- exit(1);
- }
-
- if (machine->ram_size > EP108_MAX_RAM_SIZE) {
+ /* Create the memory region to pass to the SoC */
+ if (machine->ram_size > XLNX_ZYNQMP_MAX_RAM_SIZE) {
error_report("WARNING: RAM size " RAM_ADDR_FMT " above max supported, "
- "reduced to %llx", machine->ram_size, EP108_MAX_RAM_SIZE);
- machine->ram_size = EP108_MAX_RAM_SIZE;
+ "reduced to %llx", machine->ram_size,
+ XLNX_ZYNQMP_MAX_RAM_SIZE);
+ machine->ram_size = XLNX_ZYNQMP_MAX_RAM_SIZE;
}
if (machine->ram_size < 0x08000000) {
@@ -58,7 +47,19 @@ static void xlnx_ep108_init(MachineState *machine)
memory_region_allocate_system_memory(&s->ddr_ram, NULL, "ddr-ram",
machine->ram_size);
- memory_region_add_subregion(get_system_memory(), 0, &s->ddr_ram);
+
+ object_initialize(&s->soc, sizeof(s->soc), TYPE_XLNX_ZYNQMP);
+ object_property_add_child(OBJECT(machine), "soc", OBJECT(&s->soc),
+ &error_abort);
+
+ object_property_set_link(OBJECT(&s->soc), OBJECT(&s->ddr_ram),
+ "ddr-ram", &error_abort);
+
+ object_property_set_bool(OBJECT(&s->soc), true, "realized", &err);
+ if (err) {
+ error_report("%s", error_get_pretty(err));
+ exit(1);
+ }
xlnx_ep108_binfo.ram_size = machine->ram_size;
xlnx_ep108_binfo.kernel_filename = machine->kernel_filename;
diff --git a/hw/arm/xlnx-zynqmp.c b/hw/arm/xlnx-zynqmp.c
index 87553bb..b9b8bee 100644
--- a/hw/arm/xlnx-zynqmp.c
+++ b/hw/arm/xlnx-zynqmp.c
@@ -90,6 +90,11 @@ static void xlnx_zynqmp_init(Object *obj)
&error_abort);
}
+ object_property_add_link(obj, "ddr-ram", TYPE_MEMORY_REGION,
+ (Object **)&s->ddr_ram,
+ qdev_prop_allow_set_link_before_realize,
+ OBJ_PROP_LINK_UNREF_ON_RELEASE, &error_abort);
+
object_initialize(&s->gic, sizeof(s->gic), TYPE_ARM_GIC);
qdev_set_parent_bus(DEVICE(&s->gic), sysbus_get_default());
@@ -119,10 +124,42 @@ static void xlnx_zynqmp_realize(DeviceState *dev, Error **errp)
XlnxZynqMPState *s = XLNX_ZYNQMP(dev);
MemoryRegion *system_memory = get_system_memory();
uint8_t i;
+ uint64 ram_size;
const char *boot_cpu = s->boot_cpu ? s->boot_cpu : "apu-cpu[0]";
+ ram_addr_t ddr_low_size, ddr_high_size;
qemu_irq gic_spi[GIC_NUM_SPI_INTR];
Error *err = NULL;
+ ram_size = memory_region_size(s->ddr_ram);
+
+ /* Create the DDR Memory Regions. User friendly checks should happen at
+ * the board level
+ */
+ if (ram_size > XLNX_ZYNQMP_MAX_LOW_RAM_SIZE) {
+ /* The RAM size is above the maximum available for the low DDR.
+ * Create the high DDR memory region as well.
+ */
+ assert(ram_size <= XLNX_ZYNQMP_MAX_RAM_SIZE);
+ ddr_low_size = XLNX_ZYNQMP_MAX_LOW_RAM_SIZE;
+ ddr_high_size = ram_size - XLNX_ZYNQMP_MAX_LOW_RAM_SIZE;
+
+ memory_region_init_alias(&s->ddr_ram_high, NULL,
+ "ddr-ram-high", s->ddr_ram,
+ ddr_low_size, ddr_high_size);
+ memory_region_add_subregion(get_system_memory(),
+ XLNX_ZYNQMP_HIGH_RAM_START,
+ &s->ddr_ram_high);
+ } else {
+ /* RAM must be non-zero */
+ assert(ram_size);
+ ddr_low_size = ram_size;
+ }
+
+ memory_region_init_alias(&s->ddr_ram_low, NULL,
+ "ddr-ram-low", s->ddr_ram,
+ 0, ddr_low_size);
+ memory_region_add_subregion(get_system_memory(), 0, &s->ddr_ram_low);
+
/* Create the four OCM banks */
for (i = 0; i < XLNX_ZYNQMP_NUM_OCM_BANKS; i++) {
char *ocm_name = g_strdup_printf("zynqmp.ocm_ram_bank_%d", i);
diff --git a/include/hw/arm/xlnx-zynqmp.h b/include/hw/arm/xlnx-zynqmp.h
index d116092..1eba937 100644
--- a/include/hw/arm/xlnx-zynqmp.h
+++ b/include/hw/arm/xlnx-zynqmp.h
@@ -51,6 +51,14 @@
#define XLNX_ZYNQMP_GIC_REGION_SIZE 0x1000
#define XLNX_ZYNQMP_GIC_ALIASES (0x10000 / XLNX_ZYNQMP_GIC_REGION_SIZE - 1)
+#define XLNX_ZYNQMP_MAX_LOW_RAM_SIZE 0x80000000ull
+
+#define XLNX_ZYNQMP_MAX_HIGH_RAM_SIZE 0x800000000ull
+#define XLNX_ZYNQMP_HIGH_RAM_START 0x800000000ull
+
+#define XLNX_ZYNQMP_MAX_RAM_SIZE (XLNX_ZYNQMP_MAX_LOW_RAM_SIZE + \
+ XLNX_ZYNQMP_MAX_HIGH_RAM_SIZE)
+
typedef struct XlnxZynqMPState {
/*< private >*/
DeviceState parent_obj;
@@ -60,8 +68,12 @@ typedef struct XlnxZynqMPState {
ARMCPU rpu_cpu[XLNX_ZYNQMP_NUM_RPU_CPUS];
GICState gic;
MemoryRegion gic_mr[XLNX_ZYNQMP_GIC_REGIONS][XLNX_ZYNQMP_GIC_ALIASES];
+
MemoryRegion ocm_ram[XLNX_ZYNQMP_NUM_OCM_BANKS];
+ MemoryRegion *ddr_ram;
+ MemoryRegion ddr_ram_low, ddr_ram_high;
+
CadenceGEMState gem[XLNX_ZYNQMP_NUM_GEMS];
CadenceUARTState uart[XLNX_ZYNQMP_NUM_UARTS];
SysbusAHCIState sata;
--
1.9.1
^ permalink raw reply related [flat|nested] 16+ messages in thread* [Qemu-devel] [PULL 5/5] hw/arm/virt: Support legacy -nic command line syntax
2016-01-11 14:34 [Qemu-devel] [PULL 0/5] target-arm queue Peter Maydell
` (2 preceding siblings ...)
2016-01-11 14:34 ` [Qemu-devel] [PULL 3/5] xlnx-zynqmp: Add support for high DDR memory regions Peter Maydell
@ 2016-01-11 14:34 ` Peter Maydell
2016-01-18 13:29 ` Eric Auger
2016-01-11 16:11 ` [Qemu-devel] [PULL 0/5] target-arm queue Peter Maydell
4 siblings, 1 reply; 16+ messages in thread
From: Peter Maydell @ 2016-01-11 14:34 UTC (permalink / raw)
To: qemu-devel
From: Ashok Kumar <ashoks@broadcom.com>
Support the legacy -nic syntax for creating PCI network devices
as well as the new-style -device options. This makes life easier
for people moving from x86 KVM virtualization to ARM KVM virtualization
and expecting their network configuration options to work the same
way for both setups.
We use "virtio" as the default NIC model if the user doesn't specify one.
Signed-off-by: Ashok Kumar <ashoks@broadcom.com>
Message-id: 1452091659-17698-1-git-send-email-ashoks@broadcom.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
[PMM: expanded and clarified commit message]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
hw/arm/virt.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index acc1fcb..fd52b76 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -808,6 +808,7 @@ static void create_pcie(const VirtBoardInfo *vbi, qemu_irq *pic,
DeviceState *dev;
char *nodename;
int i;
+ PCIHostState *pci;
dev = qdev_create(NULL, TYPE_GPEX_HOST);
qdev_init_nofail(dev);
@@ -847,6 +848,19 @@ static void create_pcie(const VirtBoardInfo *vbi, qemu_irq *pic,
sysbus_connect_irq(SYS_BUS_DEVICE(dev), i, pic[irq + i]);
}
+ pci = PCI_HOST_BRIDGE(dev);
+ if (pci->bus) {
+ for (i = 0; i < nb_nics; i++) {
+ NICInfo *nd = &nd_table[i];
+
+ if (!nd->model) {
+ nd->model = g_strdup("virtio");
+ }
+
+ pci_nic_init_nofail(nd, pci->bus, nd->model, NULL);
+ }
+ }
+
nodename = g_strdup_printf("/pcie@%" PRIx64, base);
qemu_fdt_add_subnode(vbi->fdt, nodename);
qemu_fdt_setprop_string(vbi->fdt, nodename,
--
1.9.1
^ permalink raw reply related [flat|nested] 16+ messages in thread* Re: [Qemu-devel] [PULL 5/5] hw/arm/virt: Support legacy -nic command line syntax
2016-01-11 14:34 ` [Qemu-devel] [PULL 5/5] hw/arm/virt: Support legacy -nic command line syntax Peter Maydell
@ 2016-01-18 13:29 ` Eric Auger
2016-01-18 13:34 ` Peter Maydell
0 siblings, 1 reply; 16+ messages in thread
From: Eric Auger @ 2016-01-18 13:29 UTC (permalink / raw)
To: Peter Maydell, qemu-devel, ashoks
Cc: Alex Williamson, eric.auger@st.com, Christoffer Dall
Hi,
How is it supposed to live with Passthrough'ed NIC? Current way to
instantiate a VFIO platform NIC looks like:
-device vfio-amd-xgbe,host=e0900000.xgmac
where vfio-amd-xgbe is the name of the VFIO AMD XGBE platform QEMU
device and e0900000.xgmac is the name of the device in
/sys/bus/platform/devices.
Before that commit I was able to instantiate this VFIO device and got
networking working, testing it with ping. Now ping don't work anymore. I
Guess I now use this other default NIC?
Curiously it does not seem to prevent networking with upstreamed Calxeda
Midway device and I did not figure why yet?
Thank you in advance
Best Regards
Eric
On 01/11/2016 03:34 PM, Peter Maydell wrote:
> From: Ashok Kumar <ashoks@broadcom.com>
>
> Support the legacy -nic syntax for creating PCI network devices
> as well as the new-style -device options. This makes life easier
> for people moving from x86 KVM virtualization to ARM KVM virtualization
> and expecting their network configuration options to work the same
> way for both setups.
>
> We use "virtio" as the default NIC model if the user doesn't specify one.
>
> Signed-off-by: Ashok Kumar <ashoks@broadcom.com>
> Message-id: 1452091659-17698-1-git-send-email-ashoks@broadcom.com
> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
> [PMM: expanded and clarified commit message]
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> hw/arm/virt.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index acc1fcb..fd52b76 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -808,6 +808,7 @@ static void create_pcie(const VirtBoardInfo *vbi, qemu_irq *pic,
> DeviceState *dev;
> char *nodename;
> int i;
> + PCIHostState *pci;
>
> dev = qdev_create(NULL, TYPE_GPEX_HOST);
> qdev_init_nofail(dev);
> @@ -847,6 +848,19 @@ static void create_pcie(const VirtBoardInfo *vbi, qemu_irq *pic,
> sysbus_connect_irq(SYS_BUS_DEVICE(dev), i, pic[irq + i]);
> }
>
> + pci = PCI_HOST_BRIDGE(dev);
> + if (pci->bus) {
> + for (i = 0; i < nb_nics; i++) {
> + NICInfo *nd = &nd_table[i];
> +
> + if (!nd->model) {
> + nd->model = g_strdup("virtio");
> + }
> +
> + pci_nic_init_nofail(nd, pci->bus, nd->model, NULL);
> + }
> + }
> +
> nodename = g_strdup_printf("/pcie@%" PRIx64, base);
> qemu_fdt_add_subnode(vbi->fdt, nodename);
> qemu_fdt_setprop_string(vbi->fdt, nodename,
>
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [Qemu-devel] [PULL 5/5] hw/arm/virt: Support legacy -nic command line syntax
2016-01-18 13:29 ` Eric Auger
@ 2016-01-18 13:34 ` Peter Maydell
2016-01-18 13:57 ` Eric Auger
0 siblings, 1 reply; 16+ messages in thread
From: Peter Maydell @ 2016-01-18 13:34 UTC (permalink / raw)
To: Eric Auger
Cc: Christoffer Dall, Alex Williamson, eric.auger@st.com,
QEMU Developers, Ashok Kumar
On 18 January 2016 at 13:29, Eric Auger <eric.auger@linaro.org> wrote:
> How is it supposed to live with Passthrough'ed NIC? Current way to
> instantiate a VFIO platform NIC looks like:
>
> -device vfio-amd-xgbe,host=e0900000.xgmac
> where vfio-amd-xgbe is the name of the VFIO AMD XGBE platform QEMU
> device and e0900000.xgmac is the name of the device in
> /sys/bus/platform/devices.
> Before that commit I was able to instantiate this VFIO device and got
> networking working, testing it with ping. Now ping don't work anymore. I
> Guess I now use this other default NIC?
>
> Curiously it does not seem to prevent networking with upstreamed Calxeda
> Midway device and I did not figure why yet?
Hmm, I guess this is changing things in that we now will have a
virtio PCI device appearing if you use the default (-net nic -net user)
settings. But I don't see why that would particularly interfere
with VFIO passthrough, except in as much as the guest now has
two network cards in it and might be preferring one as eth0
rather than the other...
thanks
-- PMM
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] [PULL 5/5] hw/arm/virt: Support legacy -nic command line syntax
2016-01-18 13:34 ` Peter Maydell
@ 2016-01-18 13:57 ` Eric Auger
2016-01-18 14:14 ` Peter Maydell
0 siblings, 1 reply; 16+ messages in thread
From: Eric Auger @ 2016-01-18 13:57 UTC (permalink / raw)
To: Peter Maydell
Cc: Christoffer Dall, Alex Williamson, eric.auger@st.com,
QEMU Developers, Ashok Kumar
Hi Peter,
On 01/18/2016 02:34 PM, Peter Maydell wrote:
> On 18 January 2016 at 13:29, Eric Auger <eric.auger@linaro.org> wrote:
>> How is it supposed to live with Passthrough'ed NIC? Current way to
>> instantiate a VFIO platform NIC looks like:
>>
>> -device vfio-amd-xgbe,host=e0900000.xgmac
>> where vfio-amd-xgbe is the name of the VFIO AMD XGBE platform QEMU
>> device and e0900000.xgmac is the name of the device in
>> /sys/bus/platform/devices.
>
>> Before that commit I was able to instantiate this VFIO device and got
>> networking working, testing it with ping. Now ping don't work anymore. I
>> Guess I now use this other default NIC?
>>
>> Curiously it does not seem to prevent networking with upstreamed Calxeda
>> Midway device and I did not figure why yet?
>
> Hmm, I guess this is changing things in that we now will have a
> virtio PCI device appearing if you use the default (-net nic -net user)
> settings. But I don't see why that would particularly interfere
> with VFIO passthrough, except in as much as the guest now has
> two network cards in it and might be preferring one as eth0
> rather than the other...
Yes that's what currently happens I think. I get the slirp thing on eth0
and my passthrough'ed device on eth1. That's not very straightforward
for the end-user to get those 2 NIC's now. In case I passthrough some
NIC's I would have expected this default NIC not be instantiated?
Alex, how do you manage on x86 platforms with VFIO-PCI NIC?
Thanks
Eric
>
> thanks
> -- PMM
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] [PULL 5/5] hw/arm/virt: Support legacy -nic command line syntax
2016-01-18 13:57 ` Eric Auger
@ 2016-01-18 14:14 ` Peter Maydell
2016-01-18 14:54 ` Eric Auger
0 siblings, 1 reply; 16+ messages in thread
From: Peter Maydell @ 2016-01-18 14:14 UTC (permalink / raw)
To: Eric Auger
Cc: Christoffer Dall, Alex Williamson, eric.auger@st.com,
QEMU Developers, Ashok Kumar
On 18 January 2016 at 13:57, Eric Auger <eric.auger@linaro.org> wrote:
> Hi Peter,
> On 01/18/2016 02:34 PM, Peter Maydell wrote:
>> Hmm, I guess this is changing things in that we now will have a
>> virtio PCI device appearing if you use the default (-net nic -net user)
>> settings. But I don't see why that would particularly interfere
>> with VFIO passthrough, except in as much as the guest now has
>> two network cards in it and might be preferring one as eth0
>> rather than the other...
> Yes that's what currently happens I think. I get the slirp thing on eth0
> and my passthrough'ed device on eth1. That's not very straightforward
> for the end-user to get those 2 NIC's now. In case I passthrough some
> NIC's I would have expected this default NIC not be instantiated?
The QEMU networking layer only knows about networking controlled
by the -net or -netdev options (and in those cases it does disable
the default network device). Because the back-end for passthrough
NICs is completely unknown to QEMU (it is all done in hardware),
I'm not sure we have any way to know that the thing you've passed through
is a NIC and not some other random PCI device...
> Alex, how do you manage on x86 platforms with VFIO-PCI NIC?
...but presumably the x86 folks have been here before us
and know how this should work :-)
thanks
-- PMM
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] [PULL 5/5] hw/arm/virt: Support legacy -nic command line syntax
2016-01-18 14:14 ` Peter Maydell
@ 2016-01-18 14:54 ` Eric Auger
2016-01-18 15:55 ` Alex Williamson
0 siblings, 1 reply; 16+ messages in thread
From: Eric Auger @ 2016-01-18 14:54 UTC (permalink / raw)
To: Peter Maydell
Cc: Christoffer Dall, Alex Williamson, eric.auger@st.com,
QEMU Developers, Ashok Kumar
On 01/18/2016 03:14 PM, Peter Maydell wrote:
> On 18 January 2016 at 13:57, Eric Auger <eric.auger@linaro.org> wrote:
>> Hi Peter,
>> On 01/18/2016 02:34 PM, Peter Maydell wrote:
>>> Hmm, I guess this is changing things in that we now will have a
>>> virtio PCI device appearing if you use the default (-net nic -net user)
>>> settings. But I don't see why that would particularly interfere
>>> with VFIO passthrough, except in as much as the guest now has
>>> two network cards in it and might be preferring one as eth0
>>> rather than the other...
>> Yes that's what currently happens I think. I get the slirp thing on eth0
>> and my passthrough'ed device on eth1. That's not very straightforward
>> for the end-user to get those 2 NIC's now. In case I passthrough some
>> NIC's I would have expected this default NIC not be instantiated?
>
> The QEMU networking layer only knows about networking controlled
> by the -net or -netdev options (and in those cases it does disable
> the default network device). Because the back-end for passthrough
> NICs is completely unknown to QEMU (it is all done in hardware),
> I'm not sure we have any way to know that the thing you've passed through
> is a NIC and not some other random PCI device...
>
>> Alex, how do you manage on x86 platforms with VFIO-PCI NIC?
>
> ...but presumably the x86 folks have been here before us
> and know how this should work :-)
Yes. maybe we could create a new network backend VFIO and use that kind
of cmd line:
NET_OPTIONS="-netdev VFIO,id=myeth0 \
-device vfio-amd-xgbe,host=e0900000.xgmac,netdev=myeth0"
In the specialized VFIO-Platform device I can easily add a dummy NICConf
field and add
static Property amd_xgbe_properties[] = {
DEFINE_NIC_PROPERTIES(VFIOAmdXgbeDevice, conf),
DEFINE_PROP_END_OF_LIST(),
};
But it complexifies the user command line quite a lot and not sure it is
worth the candle?
Thanks
Eric
>
> thanks
> -- PMM
>
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [Qemu-devel] [PULL 5/5] hw/arm/virt: Support legacy -nic command line syntax
2016-01-18 14:54 ` Eric Auger
@ 2016-01-18 15:55 ` Alex Williamson
2016-01-18 15:57 ` Eric Auger
2016-01-18 16:00 ` Peter Maydell
0 siblings, 2 replies; 16+ messages in thread
From: Alex Williamson @ 2016-01-18 15:55 UTC (permalink / raw)
To: Eric Auger, Peter Maydell
Cc: Christoffer Dall, eric.auger@st.com, QEMU Developers, Ashok Kumar
On Mon, 2016-01-18 at 15:54 +0100, Eric Auger wrote:
> On 01/18/2016 03:14 PM, Peter Maydell wrote:
> > On 18 January 2016 at 13:57, Eric Auger <eric.auger@linaro.org>
> > wrote:
> > > Hi Peter,
> > > On 01/18/2016 02:34 PM, Peter Maydell wrote:
> > > > Hmm, I guess this is changing things in that we now will have a
> > > > virtio PCI device appearing if you use the default (-net nic
> > > > -net user)
> > > > settings. But I don't see why that would particularly interfere
> > > > with VFIO passthrough, except in as much as the guest now has
> > > > two network cards in it and might be preferring one as eth0
> > > > rather than the other...
> > > Yes that's what currently happens I think. I get the slirp thing
> > > on eth0
> > > and my passthrough'ed device on eth1. That's not very
> > > straightforward
> > > for the end-user to get those 2 NIC's now. In case I passthrough
> > > some
> > > NIC's I would have expected this default NIC not be instantiated?
> >
> > The QEMU networking layer only knows about networking controlled
> > by the -net or -netdev options (and in those cases it does disable
> > the default network device). Because the back-end for passthrough
> > NICs is completely unknown to QEMU (it is all done in hardware),
> > I'm not sure we have any way to know that the thing you've passed
> > through
> > is a NIC and not some other random PCI device...
> >
> > > Alex, how do you manage on x86 platforms with VFIO-PCI NIC?
> >
> > ...but presumably the x86 folks have been here before us
> > and know how this should work :-)
No, we haven't. vfio-pci devices are opaque on x86, we don't know or
care that they're NICs or HBAs or GPUs or whatever. If you don't want the default NIC, turn it off with -net none. Don't want graphics, -nographics. Default QEMU devices may be useful for the commandline, but do they really matter in practical use?
> Yes. maybe we could create a new network backend VFIO and use that kind
> of cmd line:
>
> NET_OPTIONS="-netdev VFIO,id=myeth0 \
> -device vfio-amd-xgbe,host=e0900000.xgmac,netdev=myeth0"
>
> In the specialized VFIO-Platform device I can easily add a dummy NICConf
> field and add
>
> static Property amd_xgbe_properties[] = {
> DEFINE_NIC_PROPERTIES(VFIOAmdXgbeDevice, conf),
> DEFINE_PROP_END_OF_LIST(),
> };
>
> But it complexifies the user command line quite a lot and not sure it is
> worth the candle?
In the general case, I don't see vfio-pci going in this direction. We
do not want to know this much about the device. Thanks,
Alex
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [Qemu-devel] [PULL 5/5] hw/arm/virt: Support legacy -nic command line syntax
2016-01-18 15:55 ` Alex Williamson
@ 2016-01-18 15:57 ` Eric Auger
2016-01-18 16:00 ` Peter Maydell
1 sibling, 0 replies; 16+ messages in thread
From: Eric Auger @ 2016-01-18 15:57 UTC (permalink / raw)
To: Alex Williamson, Peter Maydell
Cc: Christoffer Dall, eric.auger@st.com, QEMU Developers, Ashok Kumar
On 01/18/2016 04:55 PM, Alex Williamson wrote:
> On Mon, 2016-01-18 at 15:54 +0100, Eric Auger wrote:
>> On 01/18/2016 03:14 PM, Peter Maydell wrote:
>>> On 18 January 2016 at 13:57, Eric Auger <eric.auger@linaro.org>
>>> wrote:
>>>> Hi Peter,
>>>> On 01/18/2016 02:34 PM, Peter Maydell wrote:
>>>>> Hmm, I guess this is changing things in that we now will have a
>>>>> virtio PCI device appearing if you use the default (-net nic
>>>>> -net user)
>>>>> settings. But I don't see why that would particularly interfere
>>>>> with VFIO passthrough, except in as much as the guest now has
>>>>> two network cards in it and might be preferring one as eth0
>>>>> rather than the other...
>>>> Yes that's what currently happens I think. I get the slirp thing
>>>> on eth0
>>>> and my passthrough'ed device on eth1. That's not very
>>>> straightforward
>>>> for the end-user to get those 2 NIC's now. In case I passthrough
>>>> some
>>>> NIC's I would have expected this default NIC not be instantiated?
>>>
>>> The QEMU networking layer only knows about networking controlled
>>> by the -net or -netdev options (and in those cases it does disable
>>> the default network device). Because the back-end for passthrough
>>> NICs is completely unknown to QEMU (it is all done in hardware),
>>> I'm not sure we have any way to know that the thing you've passed
>>> through
>>> is a NIC and not some other random PCI device...
>>>
>>>> Alex, how do you manage on x86 platforms with VFIO-PCI NIC?
>>>
>>> ...but presumably the x86 folks have been here before us
>>> and know how this should work :-)
>
> No, we haven't. vfio-pci devices are opaque on x86, we don't know or
> care that they're NICs or HBAs or GPUs or whatever. If you don't want the default NIC, turn it off with -net none.
Ah OK. That's perfect then ;-)
Thanks
Eric
Don't want graphics, -nographics. Default QEMU devices may be useful
for the commandline, but do they really matter in practical use?
>
>> Yes. maybe we could create a new network backend VFIO and use that kind
>> of cmd line:
>>
>> NET_OPTIONS="-netdev VFIO,id=myeth0 \
>> -device vfio-amd-xgbe,host=e0900000.xgmac,netdev=myeth0"
>>
>> In the specialized VFIO-Platform device I can easily add a dummy NICConf
>> field and add
>>
>> static Property amd_xgbe_properties[] = {
>> DEFINE_NIC_PROPERTIES(VFIOAmdXgbeDevice, conf),
>> DEFINE_PROP_END_OF_LIST(),
>> };
>>
>> But it complexifies the user command line quite a lot and not sure it is
>> worth the candle?
>
> In the general case, I don't see vfio-pci going in this direction. We
> do not want to know this much about the device. Thanks,
>
> Alex
>
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [Qemu-devel] [PULL 5/5] hw/arm/virt: Support legacy -nic command line syntax
2016-01-18 15:55 ` Alex Williamson
2016-01-18 15:57 ` Eric Auger
@ 2016-01-18 16:00 ` Peter Maydell
2016-01-18 16:29 ` Markus Armbruster
2016-01-18 16:32 ` Alex Williamson
1 sibling, 2 replies; 16+ messages in thread
From: Peter Maydell @ 2016-01-18 16:00 UTC (permalink / raw)
To: Alex Williamson
Cc: Christoffer Dall, eric.auger@st.com, QEMU Developers, Ashok Kumar,
Eric Auger
On 18 January 2016 at 15:55, Alex Williamson <alex.williamson@redhat.com> wrote:
> On Mon, 2016-01-18 at 15:54 +0100, Eric Auger wrote:
>> On 01/18/2016 03:14 PM, Peter Maydell wrote:
>> > ...but presumably the x86 folks have been here before us
>> > and know how this should work :-)
>
> No, we haven't. vfio-pci devices are opaque on x86, we don't
> know or care that they're NICs or HBAs or GPUs or whatever.
> If you don't want the default NIC, turn it off with -net none.
> Don't want graphics, -nographics. Default QEMU devices may be
> useful for the commandline, but do they really matter in
> practical use?
"User is expected to use -net none" is a fine answer to "how
this should work"...
(I was thrown off track because http://wiki.qemu.org/Documentation/Networking
doesn't document '-net none', and also -net is the legacy
syntax -- is there a -netdev equivalent?)
thanks
-- PMM
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] [PULL 5/5] hw/arm/virt: Support legacy -nic command line syntax
2016-01-18 16:00 ` Peter Maydell
@ 2016-01-18 16:29 ` Markus Armbruster
2016-01-18 16:32 ` Alex Williamson
1 sibling, 0 replies; 16+ messages in thread
From: Markus Armbruster @ 2016-01-18 16:29 UTC (permalink / raw)
To: Peter Maydell
Cc: eric.auger@st.com, Eric Auger, QEMU Developers, Alex Williamson,
Ashok Kumar, Christoffer Dall
Peter Maydell <peter.maydell@linaro.org> writes:
> On 18 January 2016 at 15:55, Alex Williamson <alex.williamson@redhat.com> wrote:
>> On Mon, 2016-01-18 at 15:54 +0100, Eric Auger wrote:
>>> On 01/18/2016 03:14 PM, Peter Maydell wrote:
>>> > ...but presumably the x86 folks have been here before us
>>> > and know how this should work :-)
>>
>> No, we haven't. vfio-pci devices are opaque on x86, we don't
>> know or care that they're NICs or HBAs or GPUs or whatever.
>> If you don't want the default NIC, turn it off with -net none.
>> Don't want graphics, -nographics. Default QEMU devices may be
>> useful for the commandline, but do they really matter in
>> practical use?
>
> "User is expected to use -net none" is a fine answer to "how
> this should work"...
>
> (I was thrown off track because http://wiki.qemu.org/Documentation/Networking
> doesn't document '-net none', and also -net is the legacy
> syntax -- is there a -netdev equivalent?)
-nodefaults ;-P
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] [PULL 5/5] hw/arm/virt: Support legacy -nic command line syntax
2016-01-18 16:00 ` Peter Maydell
2016-01-18 16:29 ` Markus Armbruster
@ 2016-01-18 16:32 ` Alex Williamson
1 sibling, 0 replies; 16+ messages in thread
From: Alex Williamson @ 2016-01-18 16:32 UTC (permalink / raw)
To: Peter Maydell
Cc: Christoffer Dall, eric.auger@st.com, QEMU Developers, Ashok Kumar,
Eric Auger
On Mon, 2016-01-18 at 16:00 +0000, Peter Maydell wrote:
> On 18 January 2016 at 15:55, Alex Williamson <alex.williamson@redhat.
> com> wrote:
> > On Mon, 2016-01-18 at 15:54 +0100, Eric Auger wrote:
> > > On 01/18/2016 03:14 PM, Peter Maydell wrote:
> > > > ...but presumably the x86 folks have been here before us
> > > > and know how this should work :-)
> >
> > No, we haven't. vfio-pci devices are opaque on x86, we don't
> > know or care that they're NICs or HBAs or GPUs or whatever.
> > If you don't want the default NIC, turn it off with -net none.
> > Don't want graphics, -nographics. Default QEMU devices may be
> > useful for the commandline, but do they really matter in
> > practical use?
>
> "User is expected to use -net none" is a fine answer to "how
> this should work"...
>
> (I was thrown off track because http://wiki.qemu.org/Documentation/Ne
> tworking
> doesn't document '-net none', and also -net is the legacy
> syntax -- is there a -netdev equivalent?)
My guess would be that -netdev is often used in conjunction with
-nodefaults and therefore it becomes unnecessary to explicitly disable
it. Thanks,
Alex
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] [PULL 0/5] target-arm queue
2016-01-11 14:34 [Qemu-devel] [PULL 0/5] target-arm queue Peter Maydell
` (3 preceding siblings ...)
2016-01-11 14:34 ` [Qemu-devel] [PULL 5/5] hw/arm/virt: Support legacy -nic command line syntax Peter Maydell
@ 2016-01-11 16:11 ` Peter Maydell
4 siblings, 0 replies; 16+ messages in thread
From: Peter Maydell @ 2016-01-11 16:11 UTC (permalink / raw)
To: QEMU Developers
On 11 January 2016 at 14:34, Peter Maydell <peter.maydell@linaro.org> wrote:
> Not very many patches here, but no point holding on to them.
> I'm not going to email out the libvixl upgrade patch because
> it's so big it'd get blocked by the list server anyway.
>
> thanks
> -- PMM
>
>
> The following changes since commit 692a5519ab1510ff48bdde9701017b9425643058:
>
> Merge remote-tracking branch 'remotes/mjt/tags/pull-trivial-patches-2016-01-11' into staging (2016-01-11 12:56:58 +0000)
>
> are available in the git repository at:
>
>
> git://git.linaro.org/people/pmaydell/qemu-arm.git tags/pull-target-arm-20160111
>
> for you to fetch changes up to fe84fe5e2a59d5e83f043226114153bd3ccb1c51:
>
> hw/arm/virt: Support legacy -nic command line syntax (2016-01-11 14:23:03 +0000)
>
> ----------------------------------------------------------------
> target-arm queue:
> * i.MX: move i.MX31 CCM object to register array
> * xilinx_axidma: remove dead code
> * xlnx-zynqmp: Add support for high DDR memory regions
> * disas/libvixl: Update to upstream VIXL 1.12
> * virt: Support legacy -nic command line syntax
>
There was a compile issue with the "xlnx-zynqmp: Add support for high DDR
memory regions" patch; I have dropped it and will redo the pull.
thanks
-- PMM
^ permalink raw reply [flat|nested] 16+ messages in thread