Re: AST2600 support in QEMU
On Tue, Aug 9, 2022 at 10:51 PM Cédric Le Goater wrote: > > Hello, > > On 8/10/22 04:37, Joel Stanley wrote: > > Hello Shivi, > > > > I've added others to cc who may have some input. > > > > On Tue, 9 Aug 2022 at 21:38, Shivi Fotedar wrote: > >> > >> Hello, we are looking for support for few features for AST2600 in QEMU, > >> specifically > >> > >> PCIe RC support so BMC can talk to downstream devices for management > >> functions. Normally the RC is the host CPU, BMC and the devices to be managed, which support MCTP-over-PCIe will be the endpoint (downstream) device as BMC. The MCTP message Peer transaction between BMC and managed device will using route-by-Id to RC(host) then down to endpoint. I am referring to DMTF DSP0238 spec. section 6.4 So what does the "PCIe RC support" means? the BMC will be the PCIe RC? or BMC will be PCIe-Endpoint connect to host PCIe RC. > > > > I haven't seen any PCIe work done yet. > > I haven't either. There is clearly a need now that we are moving > away from LPC. > > >> MCTP controller to run MCTP protocol on top of PCIe or I2C. > > > > What work would be required to do this on top of i2c? > > I think Jonathan and Klaus worked on this. See : > >https://lore.kernel.org/qemu-devel/20220525121422.3...@huawei.com/ > > >> I2C slave so BMC can talk to host CPU QEMU for IPMI > > > > Some support for slave mode was merged in v7.1. > > yes. > > Peter D. experimented with IPMI. See : > >https://lore.kernel.org/qemu-devel/20220630045133.32251-14...@pjd.dev/ > > We also merged a new machine including a BMC ast2600 running OpenBMC > and an ast1030 SoC running OpenBIC. Work to interconnect them on the > same I2C bus is in progress. > > Thanks, > > C. >
Re: [RFC] hw/block/m25p80: implement Octal SPI commands
On Sat, Aug 13, 2022 at 10:01 PM Anton Kochkov wrote:
>
> * Implement Octal SPI commands based on Micron MT35X series
> * Fix Micron 0x2C-based ID handling (incompatible with Numonyx)
> * Fix Micron configuration registers handling
>
> Signed-off-by: Anton Kochkov
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1148
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1149
+Edgar and Francisco, who are some of the Xilinx QEMU developers
Alistair
> ---
> hw/block/m25p80.c | 173 +-
> 1 file changed, 141 insertions(+), 32 deletions(-)
>
> diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c
> index a8d2519141..9342a3fe69 100644
> --- a/hw/block/m25p80.c
> +++ b/hw/block/m25p80.c
> @@ -127,6 +127,7 @@ typedef struct FlashPartInfo {
> .die_cnt = _die_cnt
>
> #define JEDEC_NUMONYX 0x20
> +#define JEDEC_MICRON 0x2C
> #define JEDEC_WINBOND 0xEF
> #define JEDEC_SPANSION 0x01
>
> @@ -149,6 +150,9 @@ typedef struct FlashPartInfo {
> #define NVCFG_4BYTE_ADDR_MASK (1 << 0)
> #define NVCFG_LOWER_SEGMENT_MASK (1 << 1)
>
> +/* Micron configuration register macros */
> +#define NVCFG_OCTAL_IO_MASK (1 << 5)
> +
> /* Numonyx (Micron) Flag Status Register macros */
> #define FSR_4BYTE_ADDR_MODE_ENABLED 0x1
> #define FSR_FLASH_READY (1 << 7)
> @@ -360,6 +364,9 @@ typedef enum {
> READ4 = 0x13,
> FAST_READ = 0x0b,
> FAST_READ4 = 0x0c,
> +O_FAST_READ = 0x9d,
> +O_FAST_READ4 = 0xfc,
> +OIOR_DDR = 0xfd,
> DOR = 0x3b,
> DOR4 = 0x3c,
> QOR = 0x6b,
> @@ -368,6 +375,11 @@ typedef enum {
> DIOR4 = 0xbc,
> QIOR = 0xeb,
> QIOR4 = 0xec,
> +OOR = 0x8b,
> +OOR4 = 0x8c,
> +OOR4_MT35X = 0x7c, /* according mt35x datasheet */
> +OIOR = 0xcb,
> +OIOR4 = 0xcc,
>
> PP = 0x02,
> PP4 = 0x12,
> @@ -378,6 +390,8 @@ typedef enum {
> RDID_90 = 0x90,
> RDID_AB = 0xab,
> AAI_WP = 0xad,
> +OPP = 0x82,
> +OPP4 = 0x84,
>
> ERASE_4K = 0x20,
> ERASE4_4K = 0x21,
> @@ -427,6 +441,7 @@ typedef enum {
> MAN_SPANSION,
> MAN_MACRONIX,
> MAN_NUMONYX,
> +MAN_MICRON,
> MAN_WINBOND,
> MAN_SST,
> MAN_ISSI,
> @@ -462,6 +477,9 @@ struct Flash {
> /* Configuration register for Macronix */
> uint32_t volatile_cfg;
> uint32_t enh_volatile_cfg;
> +/* Configuration register arrays for Micron */
> +uint32_t micron_volatile_cfg[8];
> +uint32_t micron_nonvolatile_cfg[8];
> /* Spansion cfg registers. */
> uint8_t spansion_cr1nv;
> uint8_t spansion_cr2nv;
> @@ -476,6 +494,7 @@ struct Flash {
> bool four_bytes_address_mode;
> bool reset_enable;
> bool quad_enable;
> +bool octal_enable;
> bool aai_enable;
> bool block_protect0;
> bool block_protect1;
> @@ -504,6 +523,8 @@ static inline Manufacturer get_man(Flash *s)
> switch (s->pi->id[0]) {
> case 0x20:
> return MAN_NUMONYX;
> +case 0x2C:
> +return MAN_MICRON;
> case 0xEF:
> return MAN_WINBOND;
> case 0x01:
> @@ -684,12 +705,17 @@ static inline int get_addr_length(Flash *s)
> case QPP_4:
> case READ4:
> case QIOR4:
> + case OIOR4:
> case ERASE4_4K:
> case ERASE4_32K:
> case ERASE4_SECTOR:
> case FAST_READ4:
> + case O_FAST_READ4:
> + case OIOR_DDR:
> case DOR4:
> case QOR4:
> + case OOR4:
> + case OOR4_MT35X:
> case DIOR4:
> return 4;
> default:
> @@ -719,9 +745,10 @@ static void complete_collecting_data(Flash *s)
> case DPP:
> case QPP:
> case QPP_4:
> +case OPP:
> case PP:
> +case OPP4:
> case PP4:
> -case PP4_4:
> s->state = STATE_PAGE_PROGRAM;
> break;
> case AAI_WP:
> @@ -732,15 +759,23 @@ static void complete_collecting_data(Flash *s)
> case READ:
> case READ4:
> case FAST_READ:
> -case FAST_READ4:
> +case O_FAST_READ:
> case DOR:
> -case DOR4:
> case QOR:
> -case QOR4:
> +case OOR:
> case DIOR:
> -case DIOR4:
> case QIOR:
> +case OIOR:
> +case FAST_READ4:
> +case O_FAST_READ4:
> +case OIOR_DDR:
> +case DOR4:
> +case QOR4:
> +case OOR4:
> +case OOR4_MT35X:
> +case DIOR4:
> case QIOR4:
> +case OIOR4:
> s->state = STATE_READ;
> break;
> case ERASE_4K:
> @@ -785,15 +820,40 @@ static void complete_collecting_data(Flash *s)
> s->write_enable = false;
> }
> break;
> -case BRWR:
> case EXTEND_ADDR_WRITE:
> s->ear = s->data[0];
> break;
> +case RNVCR:
> +g_assert(get_man(s) == MAN_MICRON);
> +s->data[0] = s->micron_volatile_cfg[s->cur_addr & 0xFF];
> +s->pos = 0;
> +s->len = 1;
> +s->state = STATE_READING_DATA;
> +s->data_read_loop = true;
> +break;
> +case RVCR:
> +g_assert(get_man(s) == MAN_MICRON);
> +
[PATCH v2 4/4] hw/ssi: ibex_spi: update reg addr
From: Wilfred Mallawa Updates the `EVENT_ENABLE` register to offset `0x34` as per OpenTitan spec [1]. [1] https://docs.opentitan.org/hw/ip/spi_host/doc/#Reg_event_enable Signed-off-by: Wilfred Mallawa --- hw/ssi/ibex_spi_host.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/ssi/ibex_spi_host.c b/hw/ssi/ibex_spi_host.c index 19dd094d76..3b8dcbce05 100644 --- a/hw/ssi/ibex_spi_host.c +++ b/hw/ssi/ibex_spi_host.c @@ -93,7 +93,7 @@ REG32(ERROR_STATUS, 0x30) FIELD(ERROR_STATUS, CMDINVAL, 3, 1) FIELD(ERROR_STATUS, CSIDINVAL, 4, 1) FIELD(ERROR_STATUS, ACCESSINVAL, 5, 1) -REG32(EVENT_ENABLE, 0x30) +REG32(EVENT_ENABLE, 0x34) FIELD(EVENT_ENABLE, RXFULL, 0, 1) FIELD(EVENT_ENABLE, TXEMPTY, 1, 1) FIELD(EVENT_ENABLE, RXWM, 2, 1) -- 2.37.1
[PATCH v2 3/4] hw/ssi: ibex_spi: fixup/add rw1c functionality
From: Wilfred Mallawa
This patch adds the `rw1c` functionality to the respective
registers. The status fields are cleared when the respective
field is set.
Signed-off-by: Wilfred Mallawa
Reviewed-by: Alistair Francis
---
hw/ssi/ibex_spi_host.c | 34 --
include/hw/ssi/ibex_spi_host.h | 4 ++--
2 files changed, 34 insertions(+), 4 deletions(-)
diff --git a/hw/ssi/ibex_spi_host.c b/hw/ssi/ibex_spi_host.c
index d377f1100c..19dd094d76 100644
--- a/hw/ssi/ibex_spi_host.c
+++ b/hw/ssi/ibex_spi_host.c
@@ -350,7 +350,17 @@ static void ibex_spi_host_write(void *opaque, hwaddr addr,
switch (addr) {
/* Skipping any R/O registers */
-case IBEX_SPI_HOST_INTR_STATE...IBEX_SPI_HOST_INTR_ENABLE:
+case IBEX_SPI_HOST_INTR_STATE:
+/* rw1c status register */
+if (FIELD_EX32(val32, INTR_STATE, ERROR)) {
+data = FIELD_DP32(data, INTR_STATE, ERROR, 0);
+}
+if (FIELD_EX32(val32, INTR_STATE, SPI_EVENT)) {
+data = FIELD_DP32(data, INTR_STATE, SPI_EVENT, 0);
+}
+s->regs[addr] = data;
+break;
+case IBEX_SPI_HOST_INTR_ENABLE:
s->regs[addr] = val32;
break;
case IBEX_SPI_HOST_INTR_TEST:
@@ -493,7 +503,27 @@ static void ibex_spi_host_write(void *opaque, hwaddr addr,
* When an error occurs, the corresponding bit must be cleared
* here before issuing any further commands
*/
-s->regs[addr] = val32;
+status = s->regs[addr];
+/* rw1c status register */
+if (FIELD_EX32(val32, ERROR_STATUS, CMDBUSY)) {
+status = FIELD_DP32(status, ERROR_STATUS, CMDBUSY, 0);
+}
+if (FIELD_EX32(val32, ERROR_STATUS, OVERFLOW)) {
+status = FIELD_DP32(status, ERROR_STATUS, OVERFLOW, 0);
+}
+if (FIELD_EX32(val32, ERROR_STATUS, UNDERFLOW)) {
+status = FIELD_DP32(status, ERROR_STATUS, UNDERFLOW, 0);
+}
+if (FIELD_EX32(val32, ERROR_STATUS, CMDINVAL)) {
+status = FIELD_DP32(status, ERROR_STATUS, CMDINVAL, 0);
+}
+if (FIELD_EX32(val32, ERROR_STATUS, CSIDINVAL)) {
+status = FIELD_DP32(status, ERROR_STATUS, CSIDINVAL, 0);
+}
+if (FIELD_EX32(val32, ERROR_STATUS, ACCESSINVAL)) {
+status = FIELD_DP32(status, ERROR_STATUS, ACCESSINVAL, 0);
+}
+s->regs[addr] = status;
break;
case IBEX_SPI_HOST_EVENT_ENABLE:
/* Controls which classes of SPI events raise an interrupt. */
diff --git a/include/hw/ssi/ibex_spi_host.h b/include/hw/ssi/ibex_spi_host.h
index 3fedcb6805..1f6d077766 100644
--- a/include/hw/ssi/ibex_spi_host.h
+++ b/include/hw/ssi/ibex_spi_host.h
@@ -40,7 +40,7 @@
OBJECT_CHECK(IbexSPIHostState, (obj), TYPE_IBEX_SPI_HOST)
/* SPI Registers */
-#define IBEX_SPI_HOST_INTR_STATE (0x00 / 4) /* rw */
+#define IBEX_SPI_HOST_INTR_STATE (0x00 / 4) /* rw1c */
#define IBEX_SPI_HOST_INTR_ENABLE(0x04 / 4) /* rw */
#define IBEX_SPI_HOST_INTR_TEST (0x08 / 4) /* wo */
#define IBEX_SPI_HOST_ALERT_TEST (0x0c / 4) /* wo */
@@ -54,7 +54,7 @@
#define IBEX_SPI_HOST_TXDATA (0x28 / 4)
#define IBEX_SPI_HOST_ERROR_ENABLE (0x2c / 4) /* rw */
-#define IBEX_SPI_HOST_ERROR_STATUS (0x30 / 4) /* rw */
+#define IBEX_SPI_HOST_ERROR_STATUS (0x30 / 4) /* rw1c */
#define IBEX_SPI_HOST_EVENT_ENABLE (0x34 / 4) /* rw */
/* FIFO Len in Bytes */
--
2.37.1
[PATCH v2 2/4] hw/ssi: ibex_spi: fixup coverity issue
From: Wilfred Mallawa
This patch addresses the coverity issues specified in [1],
as suggested, `FIELD_DP32()`/`FIELD_EX32()` macros have been
implemented to clean up the code.
Patch V2: Style changes have been made as suggested by
Andrew Jones, to promote code readability.
[1] https://www.mail-archive.com/qemu-devel@nongnu.org/msg887713.html
Fixes: Coverity CID 1488107
Signed-off-by: Wilfred Mallawa
---
hw/ssi/ibex_spi_host.c | 128 +
1 file changed, 65 insertions(+), 63 deletions(-)
diff --git a/hw/ssi/ibex_spi_host.c b/hw/ssi/ibex_spi_host.c
index 601041d719..d377f1100c 100644
--- a/hw/ssi/ibex_spi_host.c
+++ b/hw/ssi/ibex_spi_host.c
@@ -108,18 +108,20 @@ static inline uint8_t div4_round_up(uint8_t dividend)
static void ibex_spi_rxfifo_reset(IbexSPIHostState *s)
{
+uint32_t data = s->regs[IBEX_SPI_HOST_STATUS];
/* Empty the RX FIFO and assert RXEMPTY */
fifo8_reset(>rx_fifo);
-s->regs[IBEX_SPI_HOST_STATUS] &= ~R_STATUS_RXFULL_MASK;
-s->regs[IBEX_SPI_HOST_STATUS] |= R_STATUS_RXEMPTY_MASK;
+data = FIELD_DP32(data, STATUS, RXEMPTY, 1);
+s->regs[IBEX_SPI_HOST_STATUS] = data;
}
static void ibex_spi_txfifo_reset(IbexSPIHostState *s)
{
+uint32_t data = s->regs[IBEX_SPI_HOST_STATUS];
/* Empty the TX FIFO and assert TXEMPTY */
fifo8_reset(>tx_fifo);
-s->regs[IBEX_SPI_HOST_STATUS] &= ~R_STATUS_TXFULL_MASK;
-s->regs[IBEX_SPI_HOST_STATUS] |= R_STATUS_TXEMPTY_MASK;
+data = FIELD_DP32(data, STATUS, TXEMPTY, 1);
+s->regs[IBEX_SPI_HOST_STATUS] = data;
}
static void ibex_spi_host_reset(DeviceState *dev)
@@ -162,37 +164,38 @@ static void ibex_spi_host_reset(DeviceState *dev)
*/
static void ibex_spi_host_irq(IbexSPIHostState *s)
{
-bool error_en = s->regs[IBEX_SPI_HOST_INTR_ENABLE]
-& R_INTR_ENABLE_ERROR_MASK;
-bool event_en = s->regs[IBEX_SPI_HOST_INTR_ENABLE]
-& R_INTR_ENABLE_SPI_EVENT_MASK;
-bool err_pending = s->regs[IBEX_SPI_HOST_INTR_STATE]
-& R_INTR_STATE_ERROR_MASK;
-bool status_pending = s->regs[IBEX_SPI_HOST_INTR_STATE]
-& R_INTR_STATE_SPI_EVENT_MASK;
+uint32_t intr_test_reg = s->regs[IBEX_SPI_HOST_INTR_TEST];
+uint32_t intr_en_reg = s->regs[IBEX_SPI_HOST_INTR_ENABLE];
+uint32_t intr_state_reg = s->regs[IBEX_SPI_HOST_INTR_STATE];
+
+uint32_t err_en_reg = s->regs[IBEX_SPI_HOST_ERROR_ENABLE];
+uint32_t event_en_reg = s->regs[IBEX_SPI_HOST_EVENT_ENABLE];
+uint32_t err_status_reg = s->regs[IBEX_SPI_HOST_ERROR_STATUS];
+uint32_t status_reg = s->regs[IBEX_SPI_HOST_STATUS];
+
+
+bool error_en = FIELD_EX32(intr_en_reg, INTR_ENABLE, ERROR);
+bool event_en = FIELD_EX32(intr_en_reg, INTR_ENABLE, SPI_EVENT);
+bool err_pending = FIELD_EX32(intr_state_reg, INTR_STATE, ERROR);
+bool status_pending = FIELD_EX32(intr_state_reg, INTR_STATE, SPI_EVENT);
+
int err_irq = 0, event_irq = 0;
/* Error IRQ enabled and Error IRQ Cleared */
if (error_en && !err_pending) {
/* Event enabled, Interrupt Test Error */
-if (s->regs[IBEX_SPI_HOST_INTR_TEST] & R_INTR_TEST_ERROR_MASK) {
+if (FIELD_EX32(intr_test_reg, INTR_TEST, ERROR)) {
err_irq = 1;
-} else if ((s->regs[IBEX_SPI_HOST_ERROR_ENABLE]
-& R_ERROR_ENABLE_CMDBUSY_MASK) &&
-s->regs[IBEX_SPI_HOST_ERROR_STATUS]
-& R_ERROR_STATUS_CMDBUSY_MASK) {
+} else if (FIELD_EX32(err_en_reg, ERROR_ENABLE, CMDBUSY) &&
+FIELD_EX32(err_status_reg, ERROR_STATUS, CMDBUSY)) {
/* Wrote to COMMAND when not READY */
err_irq = 1;
-} else if ((s->regs[IBEX_SPI_HOST_ERROR_ENABLE]
-& R_ERROR_ENABLE_CMDINVAL_MASK) &&
-s->regs[IBEX_SPI_HOST_ERROR_STATUS]
-& R_ERROR_STATUS_CMDINVAL_MASK) {
+} else if (FIELD_EX32(err_en_reg, ERROR_ENABLE, CMDINVAL) &&
+FIELD_EX32(err_status_reg, ERROR_STATUS, CMDINVAL)) {
/* Invalid command segment */
err_irq = 1;
-} else if ((s->regs[IBEX_SPI_HOST_ERROR_ENABLE]
-& R_ERROR_ENABLE_CSIDINVAL_MASK) &&
-s->regs[IBEX_SPI_HOST_ERROR_STATUS]
-& R_ERROR_STATUS_CSIDINVAL_MASK) {
+} else if (FIELD_EX32(err_en_reg, ERROR_ENABLE, CSIDINVAL) &&
+FIELD_EX32(err_status_reg, ERROR_STATUS, CSIDINVAL)) {
/* Invalid value for CSID */
err_irq = 1;
}
@@ -204,22 +207,19 @@ static void ibex_spi_host_irq(IbexSPIHostState *s)
/* Event IRQ Enabled and Event IRQ Cleared */
if (event_en && !status_pending) {
-if (s->regs[IBEX_SPI_HOST_INTR_TEST] & R_INTR_TEST_SPI_EVENT_MASK) {
+if (FIELD_EX32(intr_test_reg, INTR_STATE, SPI_EVENT)) {
/* Event enabled, Interrupt Test Event
[PATCH v2 1/4] hw/ssi: ibex_spi: fixup typos in ibex_spi_host
From: Wilfred Mallawa
This patch fixes up minor typos in ibex_spi_host
Signed-off-by: Wilfred Mallawa
Reviewed-by: Alistair Francis
Reviewed-by: Andrew Jones
---
hw/ssi/ibex_spi_host.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/ssi/ibex_spi_host.c b/hw/ssi/ibex_spi_host.c
index d14580b409..601041d719 100644
--- a/hw/ssi/ibex_spi_host.c
+++ b/hw/ssi/ibex_spi_host.c
@@ -172,7 +172,7 @@ static void ibex_spi_host_irq(IbexSPIHostState *s)
& R_INTR_STATE_SPI_EVENT_MASK;
int err_irq = 0, event_irq = 0;
-/* Error IRQ enabled and Error IRQ Cleared*/
+/* Error IRQ enabled and Error IRQ Cleared */
if (error_en && !err_pending) {
/* Event enabled, Interrupt Test Error */
if (s->regs[IBEX_SPI_HOST_INTR_TEST] & R_INTR_TEST_ERROR_MASK) {
@@ -434,7 +434,7 @@ static void ibex_spi_host_write(void *opaque, hwaddr addr,
case IBEX_SPI_HOST_TXDATA:
/*
* This is a hardware `feature` where
- * the first word written TXDATA after init is omitted entirely
+ * the first word written to TXDATA after init is omitted entirely
*/
if (s->init_status) {
s->init_status = false;
@@ -487,7 +487,7 @@ static void ibex_spi_host_write(void *opaque, hwaddr addr,
break;
case IBEX_SPI_HOST_ERROR_STATUS:
/*
- * Indicates that any errors that have occurred.
+ * Indicates any errors that have occurred.
* When an error occurs, the corresponding bit must be cleared
* here before issuing any further commands
*/
--
2.37.1
[PATCH v2 0/4] hw/ssi: ibex_spi: cleanup and fixup bugs
From: Wilfred Mallawa This patch series (note V2) cleans up the ibex_spi driver, fixes the specified coverity issue, implements register rw1c functionality and updates an incorrect register offset. In V2, the following changes are made. - New patch [4/4] to isolate the register address offset update. - Adding the `ibex_spi` tag to commits - Split the register update to a seperate patch - Address all style suggestions made, to improve readability Testing: - Tested with Opentitan unit tests for TockOS. [OK] Wilfred Mallawa (4): hw/ssi: ibex_spi: fixup typos in ibex_spi_host hw/ssi: ibex_spi: fixup coverity issue hw/ssi: ibex_spi: fixup/add rw1c functionality hw/ssi: ibex_spi: update reg addr hw/ssi/ibex_spi_host.c | 170 - include/hw/ssi/ibex_spi_host.h | 4 +- 2 files changed, 103 insertions(+), 71 deletions(-) -- 2.37.1
Re: [PATCH for-7.2 v2 10/20] hw/ppc: set machine->fdt in spapr machine
On Fri, Aug 12, 2022 at 07:23:09PM -0300, Daniel Henrique Barboza wrote: > > > On 8/8/22 00:26, David Gibson wrote: > > On Fri, Aug 05, 2022 at 06:39:38AM -0300, Daniel Henrique Barboza wrote: > > > The pSeries machine never bothered with the common machine->fdt > > > attribute. We do all the FDT related work using spapr->fdt_blob. > > > > > > We're going to introduce HMP commands to read and save the FDT, which > > > will rely on setting machine->fdt properly to work across all machine > > > archs/types. > > > > > > Let's set machine->fdt in the two places where we manipulate the FDT: > > > spapr_machine_reset() and CAS. spapr->fdt_blob is left untouched: what > > > we want is a way to access the FDT from HMP, not replace > > > spapr->fdt_blob. > > > > Given there is now an fdt field in the generic MACHINE structure, we > > should be able to remove the one in spapr->fdt_blob, yes? > > I thought about it but I backed down when I realized that spapr->fdt_blob is > being migrated. > > At first glance it would be a matter of migrating ms->fdt and then removing > spapr->fdt_blob, but then I got confused about how a migration to an older > version would occur (e.g. QEMU 7.2 with ms->fdt to a QEMU 7.0 with > spapr->fdt_blob). > > Migration to a newer QEMU would require us to move the spapr->version_id to 4 > and then handle the old version accordingly in spapr_post_load(). > > Probably something to think about after this work is accepted. Fair enough. I'm confident the migration semantics can be worked out, but it will require some care. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: [PATCH for-7.2 v2 01/20] hw/arm: do not free machine->fdt in arm_load_dtb()
On Fri, Aug 12, 2022 at 07:03:26PM -0300, Daniel Henrique Barboza wrote:
> David,
>
> On 8/8/22 00:23, David Gibson wrote:
> > On Fri, Aug 05, 2022 at 06:39:29AM -0300, Daniel Henrique Barboza wrote:
> > > At this moment, arm_load_dtb() can free machine->fdt when
> > > binfo->dtb_filename is NULL. If there's no 'dtb_filename', 'fdt' will be
> > > retrieved by binfo->get_dtb(). If get_dtb() returns machine->fdt, as is
> > > the case of machvirt_dtb() from hw/arm/virt.c, fdt now has a pointer to
> > > machine->fdt. And, in that case, the existing g_free(fdt) at the end of
> > > arm_load_dtb() will make machine->fdt point to an invalid memory region.
> > >
> > > This is not an issue right now because there's no code that access
> > > machine->fdt after arm_load_dtb(), but we're going to add a couple do
> > > FDT HMP commands that will rely on machine->fdt being valid.
> > >
> > > Instead of freeing 'fdt' at the end of arm_load_dtb(), assign it to
> > > machine->fdt. This will allow the FDT of ARM machines that relies on
> > > arm_load_dtb() to be accessed later on.
> > >
> > > Since all ARM machines allocates the FDT only once, we don't need to
> > > worry about leaking the existing FDT during a machine reset (which is
> > > something that other machines have to look after, e.g. the ppc64 pSeries
> > > machine).
> > >
> > > Cc: Peter Maydell
> > > Cc: qemu-...@nongnu.org
> > > Signed-off-by: Daniel Henrique Barboza
> > > ---
> > > hw/arm/boot.c | 8 +++-
> > > 1 file changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/hw/arm/boot.c b/hw/arm/boot.c
> > > index ada2717f76..9f5ceb62d2 100644
> > > --- a/hw/arm/boot.c
> > > +++ b/hw/arm/boot.c
> > > @@ -684,7 +684,13 @@ int arm_load_dtb(hwaddr addr, const struct
> > > arm_boot_info *binfo,
> > >*/
> > > rom_add_blob_fixed_as("dtb", fdt, size, addr, as);
> > > -g_free(fdt);
> > > +/*
> > > + * Update the ms->fdt pointer to enable support for 'dumpdtb'
> > > + * and 'info fdt' commands. Use fdt_pack() to shrink the blob
> > > + * size we're going to store.
> > > + */
> > > +fdt_pack(fdt);
> > > +ms->fdt = fdt;
> > > return size;
> >
> > fdt_pack() could change (reduce) the effective size of the dtb blob,
> > so returning a 'size' value from above rather than the new value of
> > fdt_totalsize(fdt) doesn't see right.
>
> After some thought I think executing fdt_pack() like I'm doing here is not
> a good idea. The first problem is that I'm not returning the updated size,
> as you've said.
>
> But I can't just amend a 'return fdt_totalsize(fdt);' either. I'm packing the
> FDT **after** the machine store it in the guest physical memory. If I return
> the packed size, but the machine isn't packing the FDT before a
> cpu_physical_memory_write(), I'll be under-reporting the FDT size written.
Ah... good point.
> Machines such as e500 (patch 4) uses this returned value to put more stuff in
> the guest memory. In that case, returning a smaller size that what was
> actually
> written can cause the machine to overwrite the FDT by accident. In fact, only
> a handful of machines (ppc/pseries, ppc/pvn, riscv, oepenrisc) is doing a
> fdt_pack() before a cpu_physical_memory_write(). So this change would be
> potentially harmful to a lot of people.
>
> One alternative would be to do a fdt_pack() before the machine writes the
> FDT in the guest memory, but that is too intrusive to do because I can't say
> if each of these machines will be OK with that. I have a hunch that it would
> be OK, but a hunch isn't going to cut it.
Hmm.. I'd be fairly confident that would be ok. It certainly should
be ok for the fdt content itself, fdt_pack() doesn't change that
semantically. If the machine is using that size to put stuff after, I
can't really see how that could break, either. Unless the machine
were using the fdtsize in one place and a fixed size somewhere else to
address the same data, which would be a bug.
> I'll just drop the fdt_pack() for each of these patches. If the machine code
> is already packing it, fine. If not, that's fine too. Each maintainer can
> assess whether packing the FDT is worth it or not.
That's probably reasonable for the time being.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
Re: [PATCH v12 0/6] Improve PMU support
On Fri, Aug 12, 2022 at 12:05 PM Atish Patra wrote:
>
> On Tue, Aug 2, 2022 at 4:33 PM Atish Patra wrote:
> >
> > The latest version of the SBI specification includes a Performance
> > Monitoring
> > Unit(PMU) extension[1] which allows the supervisor to start/stop/configure
> > various PMU events. The Sscofpmf ('Ss' for Privileged arch and
> > Supervisor-level
> > extensions, and 'cofpmf' for Count OverFlow and Privilege Mode Filtering)
> > extension[2] allows the perf like tool to handle overflow interrupts and
> > filtering support.
> >
> > This series implements remaining PMU infrastructure to support
> > PMU in virt machine. The first seven patches from the original series
> > have been merged already.
> >
> > This will allow us to add any PMU events in future.
> > Currently, this series enables the following omu events.
> > 1. cycle count
> > 2. instruction count
> > 3. DTLB load/store miss
> > 4. ITLB prefetch miss
> >
> > The first two are computed using host ticks while last three are counted
> > during
> > cpu_tlb_fill. We can do both sampling and count from guest userspace.
> > This series has been tested on both RV64 and RV32. Both Linux[3] and
> > Opensbi[4]
> > patches are required to get the perf working.
> >
> > Here is an output of perf stat/report while running hackbench with latest
> > OpenSBI & Linux kernel.
> >
> > Perf stat:
> > ==
> > [root@fedora-riscv ~]# perf stat -e cycles -e instructions -e
> > dTLB-load-misses -e dTLB-store-misses -e iTLB-load-misses \
> > > perf bench sched messaging -g 1 -l 10
> > # Running 'sched/messaging' benchmark:
> > # 20 sender and receiver processes per group
> > # 1 groups == 40 processes run
> >
> > Total time: 0.265 [sec]
> >
> > Performance counter stats for 'perf bench sched messaging -g 1 -l 10':
> >
> > 4,167,825,362 cycles
> > 4,166,609,256 instructions #1.00 insn per cycle
> > 3,092,026 dTLB-load-misses
> >258,280 dTLB-store-misses
> > 2,068,966 iTLB-load-misses
> >
> >0.585791767 seconds time elapsed
> >
> >0.373802000 seconds user
> >1.042359000 seconds sys
> >
> > Perf record:
> >
> > [root@fedora-riscv ~]# perf record -e cycles -e instructions \
> > > -e dTLB-load-misses -e dTLB-store-misses -e iTLB-load-misses -c 1 \
> > > perf bench sched messaging -g 1 -l 10
> > # Running 'sched/messaging' benchmark:
> > # 20 sender and receiver processes per group
> > # 1 groups == 40 processes run
> >
> > Total time: 1.397 [sec]
> > [ perf record: Woken up 10 times to write data ]
> > Check IO/CPU overload!
> > [ perf record: Captured and wrote 8.211 MB perf.data (214486 samples) ]
> >
> > [root@fedora-riscv riscv]# perf report
> > Available samples
> > 107K cycles
> >◆
> > 107K instructions
> >▒
> > 250 dTLB-load-misses
> >▒
> > 13 dTLB-store-misses
> >▒
> > 172 iTLB-load-misses
> > ..
> >
> > Changes from v11->v12:
> > 1. Rebased on top of the apply-next.
> > 2. Aligned the write function & .min_priv to the previous line.
> > 3. Fixed the FDT generations for multi-socket scenario.
> > 4. Dropped interrupt property from the DT.
> > 5. Generate illegal instruction fault instead of virtual instruction fault
> >for VS/VU access while mcounteren is not set.
> >
> > Changes from v10->v11:
> > 1. Rebased on top of the master where first 7 patches were already merged.
> > 2. Removed unnecessary additional check in ctr predicate function.
> > 3. Removed unnecessary priv version checks in mcountinhibit read/write.
> > 4. Added Heiko's reviewed-by/tested-by tags.
> >
> > Changes from v8->v9:
> > 1. Added the write_done flags to the vmstate.
> > 2. Fixed the hpmcounter read access from M-mode.
> >
> > Changes from v7->v8:
> > 1. Removeding ordering constraints for mhpmcounter & mhpmevent.
> >
> > Changes from v6->v7:
> > 1. Fixed all the compilation errors for the usermode.
> >
> > Changes from v5->v6:
> > 1. Fixed compilation issue with PATCH 1.
> > 2. Addressed other comments.
> >
> > Changes from v4->v5:
> > 1. Rebased on top of the -next with following patches.
> >- isa extension
> >- priv 1.12 spec
> > 2. Addressed all the comments on v4
> > 3. Removed additional isa-ext DT node in favor of riscv,isa string update
> >
> > Changes from v3->v4:
> > 1. Removed the dummy events from pmu DT node.
> > 2. Fixed pmu_avail_counters mask generation.
> > 3. Added a patch to simplify the predicate function for counters.
> >
> > Changes from v2->v3:
> > 1. Addressed all the comments on PATCH1-4.
> > 2. Split patch1 into two separate patches.
> > 3. Added explicit comments to explain the event types in DT node.
> > 4. Rebased on latest Qemu.
> >
> > Changes from
Re: [PATCH] hw/riscv: microchip_pfsoc: fix kernel panics due to missing peripherals
On Mon, Aug 15, 2022 at 8:48 AM wrote: > > On 14/08/2022 23:08, Alistair Francis wrote: > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > > content is safe > > > > On Sat, Aug 13, 2022 at 11:51 PM Conor Dooley wrote: > >> QEMU support for PolarFire SoC seems to be fairly out of date at this > >> point. Running with a recent HSS, U-Boot etc doesn't work, partly due > >> to the unimplemented cache controller that the HSS tries to read from > >> (it needs to know the ways configuration now) and the rest seems to be > >> down to 64 bit address DMA to the sd card (not 100% on that yet). > >> There's some patches floating around internally that supposedly fixed > >> things for QEMU v6.something but I could not replicate & they're fairly > >> conflicty at this point. Plan is to clean them up, but no point sitting > >> on this patch until then as I have no ETA for that at this point. > > > > Awesome! It is great to see Microchip supporting open source projects > > Better late than never ehh.. > As I said, no ETA yet as I don't know just how far off the sd card stuff > is, but it's in the todo pile. In the meantime, I'll keep an eye out here > which I am ~certain we haven't been doing so far. I've added QEMU stuff > to my build/test scripts now that I've got the direct kernel boot working > for me so hopefully once things get fixed, they'll stay that way. Great! That is good to hear :) Alistair > > Thanks, > Conor.
Re: [PATCH] hw/riscv: microchip_pfsoc: fix kernel panics due to missing peripherals
On Sat, Aug 13, 2022 at 11:51 PM Conor Dooley wrote:
>
> From: Conor Dooley
>
> Booting using "Direct Kernel Boot" for PolarFire SoC & skipping u-boot
> entirely is probably not advisable, but it does at least show signs of
> life. Recent Linux kernel versions make use of peripherals that are
> missing definitions in QEMU and lead to kernel panics. These issues
> almost certain rear their head for other methods of booting, but I was
> unable to figure out a suitable HSS version that is recent enough to
> support these peripherals & works with QEMU.
>
> With these peripherals added, booting a kernel with the following hangs
> hangs waiting for the system controller's hwrng, but the kernel no
> longer panics. With the Linux driver for hwrng disabled, it boots to
> console.
>
> qemu-system-riscv64 -M microchip-icicle-kit \
> -m 2G -smp 5 \
> -kernel $(vmlinux_bin) \
> -dtb $(dtb)\
> -initrd $(initramfs) \
> -display none -serial null \
> -serial stdio
>
> More peripherals are added than strictly required to fix the panics in
> the hopes of avoiding a replication of this problem in the future.
> Some of the peripherals which are in the device tree for recent kernels
> are implemented in the FPGA fabric. The eMMC/SD mux, which exists as
> an unimplemented device is replaced by a wider entry. This updated
> entry covers both the mux & the remainder of the FPGA fabric connected
> to the MSS using Fabric Interrconnect (FIC) 3.
>
> Link:
> https://github.com/polarfire-soc/icicle-kit-reference-design#fabric-memory-map
> Link:
> https://ww1.microchip.com/downloads/aemDocuments/documents/FPGA/ProductDocuments/SupportingCollateral/V1_4_Register_Map.zip
> Signed-off-by: Conor Dooley
> ---
> QEMU support for PolarFire SoC seems to be fairly out of date at this
> point. Running with a recent HSS, U-Boot etc doesn't work, partly due
> to the unimplemented cache controller that the HSS tries to read from
> (it needs to know the ways configuration now) and the rest seems to be
> down to 64 bit address DMA to the sd card (not 100% on that yet).
> There's some patches floating around internally that supposedly fixed
> things for QEMU v6.something but I could not replicate & they're fairly
> conflicty at this point. Plan is to clean them up, but no point sitting
> on this patch until then as I have no ETA for that at this point.
>
> CC: Bin Meng
> CC: Palmer Dabbelt
> CC: Alistair Francis
> CC: Conor Dooley
> CC: qemu-ri...@nongnu.org
> CC: qemu-devel@nongnu.org
Thanks!
Applied to riscv-to-apply.next
Alistair
> ---
> hw/riscv/microchip_pfsoc.c | 67 +++---
> include/hw/riscv/microchip_pfsoc.h | 14 ++-
> 2 files changed, 74 insertions(+), 7 deletions(-)
>
> diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
> index 10a5d0e501..eb90a99660 100644
> --- a/hw/riscv/microchip_pfsoc.c
> +++ b/hw/riscv/microchip_pfsoc.c
> @@ -100,8 +100,11 @@ static const MemMapEntry microchip_pfsoc_memmap[] = {
> [MICROCHIP_PFSOC_L2LIM] = { 0x800, 0x200 },
> [MICROCHIP_PFSOC_PLIC] ={ 0xc00, 0x400 },
> [MICROCHIP_PFSOC_MMUART0] = { 0x2000, 0x1000 },
> +[MICROCHIP_PFSOC_WDOG0] = { 0x20001000, 0x1000 },
> [MICROCHIP_PFSOC_SYSREG] = { 0x20002000, 0x2000 },
> +[MICROCHIP_PFSOC_AXISW] = { 0x20004000, 0x1000 },
> [MICROCHIP_PFSOC_MPUCFG] = { 0x20005000, 0x1000 },
> +[MICROCHIP_PFSOC_FMETER] = { 0x20006000, 0x1000 },
> [MICROCHIP_PFSOC_DDR_SGMII_PHY] = { 0x20007000, 0x1000 },
> [MICROCHIP_PFSOC_EMMC_SD] = { 0x20008000, 0x1000 },
> [MICROCHIP_PFSOC_DDR_CFG] = { 0x2008,0x4 },
> @@ -109,19 +112,28 @@ static const MemMapEntry microchip_pfsoc_memmap[] = {
> [MICROCHIP_PFSOC_MMUART2] = { 0x20102000, 0x1000 },
> [MICROCHIP_PFSOC_MMUART3] = { 0x20104000, 0x1000 },
> [MICROCHIP_PFSOC_MMUART4] = { 0x20106000, 0x1000 },
> +[MICROCHIP_PFSOC_WDOG1] = { 0x20101000, 0x1000 },
> +[MICROCHIP_PFSOC_WDOG2] = { 0x20103000, 0x1000 },
> +[MICROCHIP_PFSOC_WDOG3] = { 0x20105000, 0x1000 },
> +[MICROCHIP_PFSOC_WDOG4] = { 0x20106000, 0x1000 },
> [MICROCHIP_PFSOC_SPI0] ={ 0x20108000, 0x1000 },
> [MICROCHIP_PFSOC_SPI1] ={ 0x20109000, 0x1000 },
> +[MICROCHIP_PFSOC_I2C0] ={ 0x2010a000, 0x1000 },
> [MICROCHIP_PFSOC_I2C1] ={ 0x2010b000, 0x1000 },
> +[MICROCHIP_PFSOC_CAN0] ={ 0x2010c000, 0x1000 },
> +[MICROCHIP_PFSOC_CAN1] ={ 0x2010d000, 0x1000 },
> [MICROCHIP_PFSOC_GEM0] ={ 0x2011, 0x2000 },
> [MICROCHIP_PFSOC_GEM1] ={ 0x20112000, 0x2000 },
> [MICROCHIP_PFSOC_GPIO0] =
Re: [PATCH v12 1/6] target/riscv: Add sscofpmf extension support
On Wed, Aug 3, 2022 at 9:33 AM Atish Patra wrote:
>
> The Sscofpmf ('Ss' for Privileged arch and Supervisor-level extensions,
> and 'cofpmf' for Count OverFlow and Privilege Mode Filtering)
> extension allows the perf to handle overflow interrupts and filtering
> support. This patch provides a framework for programmable
> counters to leverage the extension. As the extension doesn't have any
> provision for the overflow bit for fixed counters, the fixed events
> can also be monitoring using programmable counters. The underlying
> counters for cycle and instruction counters are always running. Thus,
> a separate timer device is programmed to handle the overflow.
>
> Tested-by: Heiko Stuebner
> Signed-off-by: Atish Patra
> Signed-off-by: Atish Patra
Reviewed-by: Alistair Francis
Alistair
> ---
> target/riscv/cpu.c | 12 ++
> target/riscv/cpu.h | 25 +++
> target/riscv/cpu_bits.h | 55 +++
> target/riscv/csr.c | 166 ++-
> target/riscv/machine.c | 1 +
> target/riscv/pmu.c | 357 +++-
> target/riscv/pmu.h | 7 +
> 7 files changed, 612 insertions(+), 11 deletions(-)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index d4635c7df46b..dc33b0dc9034 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -22,6 +22,7 @@
> #include "qemu/ctype.h"
> #include "qemu/log.h"
> #include "cpu.h"
> +#include "pmu.h"
> #include "internals.h"
> #include "exec/exec-all.h"
> #include "qapi/error.h"
> @@ -99,6 +100,7 @@ static const struct isa_ext_data isa_edata_arr[] = {
> ISA_EXT_DATA_ENTRY(zve64f, true, PRIV_VERSION_1_12_0, ext_zve64f),
> ISA_EXT_DATA_ENTRY(zhinx, true, PRIV_VERSION_1_12_0, ext_zhinx),
> ISA_EXT_DATA_ENTRY(zhinxmin, true, PRIV_VERSION_1_12_0, ext_zhinxmin),
> +ISA_EXT_DATA_ENTRY(sscofpmf, true, PRIV_VERSION_1_12_0, ext_sscofpmf),
> ISA_EXT_DATA_ENTRY(svinval, true, PRIV_VERSION_1_12_0, ext_svinval),
> ISA_EXT_DATA_ENTRY(svnapot, true, PRIV_VERSION_1_12_0, ext_svnapot),
> ISA_EXT_DATA_ENTRY(svpbmt, true, PRIV_VERSION_1_12_0, ext_svpbmt),
> @@ -882,6 +884,15 @@ static void riscv_cpu_realize(DeviceState *dev, Error
> **errp)
> set_misa(env, env->misa_mxl, ext);
> }
>
> +#ifndef CONFIG_USER_ONLY
> +if (cpu->cfg.pmu_num) {
> +if (!riscv_pmu_init(cpu, cpu->cfg.pmu_num) && cpu->cfg.ext_sscofpmf)
> {
> +cpu->pmu_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL,
> + riscv_pmu_timer_cb, cpu);
> +}
> + }
> +#endif
> +
> riscv_cpu_register_gdb_regs_for_features(cs);
>
> qemu_init_vcpu(cs);
> @@ -986,6 +997,7 @@ static Property riscv_cpu_extensions[] = {
> DEFINE_PROP_BOOL("v", RISCVCPU, cfg.ext_v, false),
> DEFINE_PROP_BOOL("h", RISCVCPU, cfg.ext_h, true),
> DEFINE_PROP_UINT8("pmu-num", RISCVCPU, cfg.pmu_num, 16),
> +DEFINE_PROP_BOOL("sscofpmf", RISCVCPU, cfg.ext_sscofpmf, false),
> DEFINE_PROP_BOOL("Zifencei", RISCVCPU, cfg.ext_ifencei, true),
> DEFINE_PROP_BOOL("Zicsr", RISCVCPU, cfg.ext_icsr, true),
> DEFINE_PROP_BOOL("Zihintpause", RISCVCPU, cfg.ext_zihintpause, true),
> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> index 4be4b82a837d..64d90586256d 100644
> --- a/target/riscv/cpu.h
> +++ b/target/riscv/cpu.h
> @@ -137,6 +137,8 @@ typedef struct PMUCTRState {
> /* Snapshort value of a counter in RV32 */
> target_ulong mhpmcounterh_prev;
> bool started;
> +/* Value beyond UINT32_MAX/UINT64_MAX before overflow interrupt trigger
> */
> +target_ulong irq_overflow_left;
> } PMUCTRState;
>
> struct CPUArchState {
> @@ -302,6 +304,9 @@ struct CPUArchState {
> /* PMU event selector configured values. First three are unused*/
> target_ulong mhpmevent_val[RV_MAX_MHPMEVENTS];
>
> +/* PMU event selector configured values for RV32*/
> +target_ulong mhpmeventh_val[RV_MAX_MHPMEVENTS];
> +
> target_ulong sscratch;
> target_ulong mscratch;
>
> @@ -439,6 +444,7 @@ struct RISCVCPUConfig {
> bool ext_zve32f;
> bool ext_zve64f;
> bool ext_zmmul;
> +bool ext_sscofpmf;
> bool rvv_ta_all_1s;
> bool rvv_ma_all_1s;
>
> @@ -486,6 +492,12 @@ struct ArchCPU {
>
> /* Configuration Settings */
> RISCVCPUConfig cfg;
> +
> +QEMUTimer *pmu_timer;
> +/* A bitmask of Available programmable counters */
> +uint32_t pmu_avail_ctrs;
> +/* Mapping of events to counters */
> +GHashTable *pmu_event_ctr_map;
> };
>
> static inline int riscv_has_ext(CPURISCVState *env, target_ulong ext)
> @@ -746,6 +758,19 @@ enum {
> CSR_TABLE_SIZE = 0x1000
> };
>
> +/**
> + * The event id are encoded based on the encoding specified in the
> + * SBI specification v0.3
> + */
> +
> +enum riscv_pmu_event_idx {
> +RISCV_PMU_EVENT_HW_CPU_CYCLES = 0x01,
> +RISCV_PMU_EVENT_HW_INSTRUCTIONS = 0x02,
> +RISCV_PMU_EVENT_CACHE_DTLB_READ_MISS = 0x10019,
> +
Re: [PATCH] xio3130_upstream: Add ACS (Access Control Services) capability
On Sun, Aug 14, 2022 at 11:59:51PM +0800, Paul Schlacter wrote: > What's wrong with not disabling the old version? Old versions have to behave in the same way as they did, or close enough. Changing that breaks migration between qemu versions. > > > On Sun, Aug 14, 2022 at 6:48 PM Michael S. Tsirkin wrote: > > On Sun, Aug 14, 2022 at 03:47:49PM +0800, Paul Schlacter wrote: > > If it is a pcie device, check that all devices on the path from > > > > the device to the root complex have ACS enabled, and then the > > > > device will become an iommu_group. > > > > it will have the effect of isolation > > > > > > Signed-off-by: wlfightup > > I don't think we can do this unconditionally. Has to have > a property and disabled for old versions. > > > --- > > > > hw/pci-bridge/xio3130_upstream.c | 3 +++ > > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/hw/pci-bridge/xio3130_upstream.c b/hw/pci-bridge/ > > xio3130_upstream.c > > > > index 5ff46ef050..2df95b 100644 > > > > --- a/hw/pci-bridge/xio3130_upstream.c > > > > +++ b/hw/pci-bridge/xio3130_upstream.c > > > > @@ -37,6 +37,8 @@ > > > > #define XIO3130_SSVID_SSID 0 > > > > #define XIO3130_EXP_OFFSET 0x90 > > > > #define XIO3130_AER_OFFSET 0x100 > > > > +#define XIO3130_ACS_OFFSET \ > > > > + (XIO3130_AER_OFFSET + PCI_ERR_SIZEOF) > > > > > > static void xio3130_upstream_write_config(PCIDevice *d, uint32_t > address, > > > > uint32_t val, int len) > > > > @@ -92,6 +94,7 @@ static void xio3130_upstream_realize(PCIDevice *d, > Error > > **errp) > > > > goto err; > > > > } > > > > > > + pcie_acs_init(d, XIO3130_ACS_OFFSET); > > > > return; > > > > > > err: > > > > -- > > > > 2.24.3 (Apple Git-128) > > > >
Re: [PATCH] hw/riscv: microchip_pfsoc: fix kernel panics due to missing peripherals
On 14/08/2022 23:08, Alistair Francis wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On Sat, Aug 13, 2022 at 11:51 PM Conor Dooley wrote: >> QEMU support for PolarFire SoC seems to be fairly out of date at this >> point. Running with a recent HSS, U-Boot etc doesn't work, partly due >> to the unimplemented cache controller that the HSS tries to read from >> (it needs to know the ways configuration now) and the rest seems to be >> down to 64 bit address DMA to the sd card (not 100% on that yet). >> There's some patches floating around internally that supposedly fixed >> things for QEMU v6.something but I could not replicate & they're fairly >> conflicty at this point. Plan is to clean them up, but no point sitting >> on this patch until then as I have no ETA for that at this point. > > Awesome! It is great to see Microchip supporting open source projects Better late than never ehh.. As I said, no ETA yet as I don't know just how far off the sd card stuff is, but it's in the todo pile. In the meantime, I'll keep an eye out here which I am ~certain we haven't been doing so far. I've added QEMU stuff to my build/test scripts now that I've got the direct kernel boot working for me so hopefully once things get fixed, they'll stay that way. Thanks, Conor.
Re: [PATCH v12 6/6] target/riscv: Remove additional priv version check for mcountinhibit
On Wed, Aug 3, 2022 at 9:34 AM Atish Patra wrote:
>
> With .min_priv_version, additiona priv version check is uncessary
> for mcountinhibit read/write functions.
>
> Reviewed-by: Heiko Stuebner
> Tested-by: Heiko Stuebner
> Signed-off-by: Atish Patra
Reviewed-by: Alistair Francis
Alistair
> ---
> target/riscv/csr.c | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/target/riscv/csr.c b/target/riscv/csr.c
> index 8753280e95b2..67367e678f38 100644
> --- a/target/riscv/csr.c
> +++ b/target/riscv/csr.c
> @@ -1489,10 +1489,6 @@ static RISCVException write_mtvec(CPURISCVState *env,
> int csrno,
> static RISCVException read_mcountinhibit(CPURISCVState *env, int csrno,
> target_ulong *val)
> {
> -if (env->priv_ver < PRIV_VERSION_1_11_0) {
> -return RISCV_EXCP_ILLEGAL_INST;
> -}
> -
> *val = env->mcountinhibit;
> return RISCV_EXCP_NONE;
> }
> @@ -1503,10 +1499,6 @@ static RISCVException
> write_mcountinhibit(CPURISCVState *env, int csrno,
> int cidx;
> PMUCTRState *counter;
>
> -if (env->priv_ver < PRIV_VERSION_1_11_0) {
> -return RISCV_EXCP_ILLEGAL_INST;
> -}
> -
> env->mcountinhibit = val;
>
> /* Check if any other counter is also monitoring cycles/instructions */
> --
> 2.25.1
>
>
Re: [PATCH] hw/riscv: opentitan: bump opentitan version
On Fri, Aug 12, 2022 at 10:54 AM Wilfred Mallawa
wrote:
>
> From: Wilfred Mallawa
>
> The following patch updates opentitan to match the new configuration,
> as per, lowRISC/opentitan@217a0168ba118503c166a9587819e3811eeb0c0c
>
> Note: with this patch we now skip the usage of the opentitan
> `boot_rom`. The Opentitan boot rom contains hw verification
> for devies which we are currently not supporting in qemu. As of now,
> the `boot_rom` has no major significance, however, would be good to
> support in the future.
>
> Tested by running utests from the latest tock [1]
> (that supports this version of OT).
>
> [1] https://github.com/tock/tock/pull/3056
>
> Signed-off-by: Wilfred Mallawa
Thanks!
Applied to riscv-to-apply.next
Alistair
> ---
> hw/riscv/opentitan.c | 12
> include/hw/riscv/opentitan.h | 11 ++-
> 2 files changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/hw/riscv/opentitan.c b/hw/riscv/opentitan.c
> index 4495a2c039..af13dbe3b1 100644
> --- a/hw/riscv/opentitan.c
> +++ b/hw/riscv/opentitan.c
> @@ -29,9 +29,9 @@
> #include "sysemu/sysemu.h"
>
> static const MemMapEntry ibex_memmap[] = {
> -[IBEX_DEV_ROM] ={ 0x8000, 16 * KiB },
> -[IBEX_DEV_RAM] ={ 0x1000, 0x1 },
> -[IBEX_DEV_FLASH] = { 0x2000, 0x8 },
> +[IBEX_DEV_ROM] ={ 0x8000, 0x8000 },
> +[IBEX_DEV_RAM] ={ 0x1000, 0x2 },
> +[IBEX_DEV_FLASH] = { 0x2000, 0x10 },
> [IBEX_DEV_UART] = { 0x4000, 0x1000 },
> [IBEX_DEV_GPIO] = { 0x4004, 0x1000 },
> [IBEX_DEV_SPI_DEVICE] = { 0x4005, 0x1000 },
> @@ -40,6 +40,7 @@ static const MemMapEntry ibex_memmap[] = {
> [IBEX_DEV_TIMER] = { 0x4010, 0x1000 },
> [IBEX_DEV_SENSOR_CTRL] ={ 0x4011, 0x1000 },
> [IBEX_DEV_OTP_CTRL] = { 0x4013, 0x4000 },
> +[IBEX_DEV_LC_CTRL] ={ 0x4014, 0x1000 },
> [IBEX_DEV_USBDEV] = { 0x4015, 0x1000 },
> [IBEX_DEV_SPI_HOST0] = { 0x4030, 0x1000 },
> [IBEX_DEV_SPI_HOST1] = { 0x4031, 0x1000 },
> @@ -141,7 +142,8 @@ static void lowrisc_ibex_soc_realize(DeviceState
> *dev_soc, Error **errp)
> _abort);
> object_property_set_int(OBJECT(>cpus), "num-harts", ms->smp.cpus,
> _abort);
> -object_property_set_int(OBJECT(>cpus), "resetvec", 0x8080,
> _abort);
> +object_property_set_int(OBJECT(>cpus), "resetvec", 0x2490,
> +_abort);
> sysbus_realize(SYS_BUS_DEVICE(>cpus), _fatal);
>
> /* Boot ROM */
> @@ -253,6 +255,8 @@ static void lowrisc_ibex_soc_realize(DeviceState
> *dev_soc, Error **errp)
> memmap[IBEX_DEV_SENSOR_CTRL].base,
> memmap[IBEX_DEV_SENSOR_CTRL].size);
> create_unimplemented_device("riscv.lowrisc.ibex.otp_ctrl",
> memmap[IBEX_DEV_OTP_CTRL].base, memmap[IBEX_DEV_OTP_CTRL].size);
> +create_unimplemented_device("riscv.lowrisc.ibex.lc_ctrl",
> +memmap[IBEX_DEV_LC_CTRL].base, memmap[IBEX_DEV_LC_CTRL].size);
> create_unimplemented_device("riscv.lowrisc.ibex.pwrmgr",
> memmap[IBEX_DEV_PWRMGR].base, memmap[IBEX_DEV_PWRMGR].size);
> create_unimplemented_device("riscv.lowrisc.ibex.rstmgr",
> diff --git a/include/hw/riscv/opentitan.h b/include/hw/riscv/opentitan.h
> index 68892cd8e5..26d960f288 100644
> --- a/include/hw/riscv/opentitan.h
> +++ b/include/hw/riscv/opentitan.h
> @@ -74,6 +74,7 @@ enum {
> IBEX_DEV_TIMER,
> IBEX_DEV_SENSOR_CTRL,
> IBEX_DEV_OTP_CTRL,
> +IBEX_DEV_LC_CTRL,
> IBEX_DEV_PWRMGR,
> IBEX_DEV_RSTMGR,
> IBEX_DEV_CLKMGR,
> @@ -105,11 +106,11 @@ enum {
> IBEX_UART0_RX_BREAK_ERR_IRQ = 6,
> IBEX_UART0_RX_TIMEOUT_IRQ = 7,
> IBEX_UART0_RX_PARITY_ERR_IRQ = 8,
> -IBEX_TIMER_TIMEREXPIRED0_0= 126,
> -IBEX_SPI_HOST0_ERR_IRQ= 150,
> -IBEX_SPI_HOST0_SPI_EVENT_IRQ = 151,
> -IBEX_SPI_HOST1_ERR_IRQ= 152,
> -IBEX_SPI_HOST1_SPI_EVENT_IRQ = 153,
> +IBEX_TIMER_TIMEREXPIRED0_0= 127,
> +IBEX_SPI_HOST0_ERR_IRQ= 151,
> +IBEX_SPI_HOST0_SPI_EVENT_IRQ = 152,
> +IBEX_SPI_HOST1_ERR_IRQ= 153,
> +IBEX_SPI_HOST1_SPI_EVENT_IRQ = 154,
> };
>
> #endif
> --
> 2.37.1
>
>
Re: [PATCH] hw/riscv: microchip_pfsoc: fix kernel panics due to missing peripherals
On Sat, Aug 13, 2022 at 11:51 PM Conor Dooley wrote:
>
> From: Conor Dooley
>
> Booting using "Direct Kernel Boot" for PolarFire SoC & skipping u-boot
> entirely is probably not advisable, but it does at least show signs of
> life. Recent Linux kernel versions make use of peripherals that are
> missing definitions in QEMU and lead to kernel panics. These issues
> almost certain rear their head for other methods of booting, but I was
> unable to figure out a suitable HSS version that is recent enough to
> support these peripherals & works with QEMU.
>
> With these peripherals added, booting a kernel with the following hangs
> hangs waiting for the system controller's hwrng, but the kernel no
> longer panics. With the Linux driver for hwrng disabled, it boots to
> console.
>
> qemu-system-riscv64 -M microchip-icicle-kit \
> -m 2G -smp 5 \
> -kernel $(vmlinux_bin) \
> -dtb $(dtb)\
> -initrd $(initramfs) \
> -display none -serial null \
> -serial stdio
>
> More peripherals are added than strictly required to fix the panics in
> the hopes of avoiding a replication of this problem in the future.
> Some of the peripherals which are in the device tree for recent kernels
> are implemented in the FPGA fabric. The eMMC/SD mux, which exists as
> an unimplemented device is replaced by a wider entry. This updated
> entry covers both the mux & the remainder of the FPGA fabric connected
> to the MSS using Fabric Interrconnect (FIC) 3.
>
> Link:
> https://github.com/polarfire-soc/icicle-kit-reference-design#fabric-memory-map
> Link:
> https://ww1.microchip.com/downloads/aemDocuments/documents/FPGA/ProductDocuments/SupportingCollateral/V1_4_Register_Map.zip
> Signed-off-by: Conor Dooley
> ---
> QEMU support for PolarFire SoC seems to be fairly out of date at this
> point. Running with a recent HSS, U-Boot etc doesn't work, partly due
> to the unimplemented cache controller that the HSS tries to read from
> (it needs to know the ways configuration now) and the rest seems to be
> down to 64 bit address DMA to the sd card (not 100% on that yet).
> There's some patches floating around internally that supposedly fixed
> things for QEMU v6.something but I could not replicate & they're fairly
> conflicty at this point. Plan is to clean them up, but no point sitting
> on this patch until then as I have no ETA for that at this point.
Awesome! It is great to see Microchip supporting open source projects
>
> CC: Bin Meng
> CC: Palmer Dabbelt
> CC: Alistair Francis
> CC: Conor Dooley
> CC: qemu-ri...@nongnu.org
> CC: qemu-devel@nongnu.org
Reviewed-by: Alistair Francis
Alistair
> ---
> hw/riscv/microchip_pfsoc.c | 67 +++---
> include/hw/riscv/microchip_pfsoc.h | 14 ++-
> 2 files changed, 74 insertions(+), 7 deletions(-)
>
> diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
> index 10a5d0e501..eb90a99660 100644
> --- a/hw/riscv/microchip_pfsoc.c
> +++ b/hw/riscv/microchip_pfsoc.c
> @@ -100,8 +100,11 @@ static const MemMapEntry microchip_pfsoc_memmap[] = {
> [MICROCHIP_PFSOC_L2LIM] = { 0x800, 0x200 },
> [MICROCHIP_PFSOC_PLIC] ={ 0xc00, 0x400 },
> [MICROCHIP_PFSOC_MMUART0] = { 0x2000, 0x1000 },
> +[MICROCHIP_PFSOC_WDOG0] = { 0x20001000, 0x1000 },
> [MICROCHIP_PFSOC_SYSREG] = { 0x20002000, 0x2000 },
> +[MICROCHIP_PFSOC_AXISW] = { 0x20004000, 0x1000 },
> [MICROCHIP_PFSOC_MPUCFG] = { 0x20005000, 0x1000 },
> +[MICROCHIP_PFSOC_FMETER] = { 0x20006000, 0x1000 },
> [MICROCHIP_PFSOC_DDR_SGMII_PHY] = { 0x20007000, 0x1000 },
> [MICROCHIP_PFSOC_EMMC_SD] = { 0x20008000, 0x1000 },
> [MICROCHIP_PFSOC_DDR_CFG] = { 0x2008,0x4 },
> @@ -109,19 +112,28 @@ static const MemMapEntry microchip_pfsoc_memmap[] = {
> [MICROCHIP_PFSOC_MMUART2] = { 0x20102000, 0x1000 },
> [MICROCHIP_PFSOC_MMUART3] = { 0x20104000, 0x1000 },
> [MICROCHIP_PFSOC_MMUART4] = { 0x20106000, 0x1000 },
> +[MICROCHIP_PFSOC_WDOG1] = { 0x20101000, 0x1000 },
> +[MICROCHIP_PFSOC_WDOG2] = { 0x20103000, 0x1000 },
> +[MICROCHIP_PFSOC_WDOG3] = { 0x20105000, 0x1000 },
> +[MICROCHIP_PFSOC_WDOG4] = { 0x20106000, 0x1000 },
> [MICROCHIP_PFSOC_SPI0] ={ 0x20108000, 0x1000 },
> [MICROCHIP_PFSOC_SPI1] ={ 0x20109000, 0x1000 },
> +[MICROCHIP_PFSOC_I2C0] ={ 0x2010a000, 0x1000 },
> [MICROCHIP_PFSOC_I2C1] ={ 0x2010b000, 0x1000 },
> +[MICROCHIP_PFSOC_CAN0] ={ 0x2010c000, 0x1000 },
> +[MICROCHIP_PFSOC_CAN1] ={ 0x2010d000, 0x1000 },
> [MICROCHIP_PFSOC_GEM0] ={ 0x2011, 0x2000 },
> [MICROCHIP_PFSOC_GEM1] ={
Re: [PATCH] riscv: Make semihosting configurable for all privilege modes
On Sat, Aug 13, 2022 at 8:20 PM Peter Maydell wrote: > > On Sat, 13 Aug 2022 at 01:53, Furquan Shaikh wrote: > > I ran into a problem when I was testing a project (with a microkernel > > in M-mode and tasks in U-mode) that uses semihosting for debugging. > > The semihosting worked fine for M-mode but not in U-mode. As I started > > digging into this, I realized that this is because qemu restricts > > semihosting to only M and S modes. > > Right. We should fix this by having a generic works-for-all-architectures > semihosting config knob, because this is not a riscv specific problem, > and we already have issues with different target architectures > developing their own solutions to things. I agree with Peter here. I don't see a strong use case for a RISC-V specific fine grained control. A user can either enable/disable semihosting for privilege or usermodes (with Peter's patchset). That seems like enough configuration options, it is unlikely that someone will need semihosting only available to S-mode for example. Alistair > > I'll see if I can dig out the half-done patchset I had for this. > > thanks > -- PMM >
Re: [PATCH 3/3] hw/ssi: fixup/add rw1c functionality
On Thu, Aug 11, 2022 at 11:05 AM Wilfred Mallawa
wrote:
>
> From: Wilfred Mallawa
>
> This patch adds the `rw1c` functionality to the respective
> registers. The status fields are cleared when the respective
> field is set.
>
> Signed-off-by: Wilfred Mallawa
Reviewed-by: Alistair Francis
Alistair
> ---
> hw/ssi/ibex_spi_host.c | 36 +++---
> include/hw/ssi/ibex_spi_host.h | 4 ++--
> 2 files changed, 35 insertions(+), 5 deletions(-)
>
> diff --git a/hw/ssi/ibex_spi_host.c b/hw/ssi/ibex_spi_host.c
> index 8c35bfa95f..935372506c 100644
> --- a/hw/ssi/ibex_spi_host.c
> +++ b/hw/ssi/ibex_spi_host.c
> @@ -352,7 +352,7 @@ static void ibex_spi_host_write(void *opaque, hwaddr addr,
> {
> IbexSPIHostState *s = opaque;
> uint32_t val32 = val64;
> -uint32_t shift_mask = 0xff, data;
> +uint32_t shift_mask = 0xff, data = 0;
> uint8_t txqd_len;
>
> trace_ibex_spi_host_write(addr, size, val64);
> @@ -362,7 +362,17 @@ static void ibex_spi_host_write(void *opaque, hwaddr
> addr,
>
> switch (addr) {
> /* Skipping any R/O registers */
> -case IBEX_SPI_HOST_INTR_STATE...IBEX_SPI_HOST_INTR_ENABLE:
> +case IBEX_SPI_HOST_INTR_STATE:
> +/* rw1c status register */
> +if (FIELD_EX32(val32, INTR_STATE, ERROR)) {
> +data = FIELD_DP32(data, INTR_STATE, ERROR, 0);
> +}
> +if (FIELD_EX32(val32, INTR_STATE, SPI_EVENT)) {
> +data = FIELD_DP32(data, INTR_STATE, SPI_EVENT, 0);
> +}
> +s->regs[addr] = data;
> +break;
> +case IBEX_SPI_HOST_INTR_ENABLE:
> s->regs[addr] = val32;
> break;
> case IBEX_SPI_HOST_INTR_TEST:
> @@ -506,7 +516,27 @@ static void ibex_spi_host_write(void *opaque, hwaddr
> addr,
> * When an error occurs, the corresponding bit must be cleared
> * here before issuing any further commands
> */
> -s->regs[addr] = val32;
> +data = s->regs[addr];
> +/* rw1c status register */
> +if (FIELD_EX32(val32, ERROR_STATUS, CMDBUSY)) {
> +data = FIELD_DP32(data, ERROR_STATUS, CMDBUSY, 0);
> +}
> +if (FIELD_EX32(val32, ERROR_STATUS, OVERFLOW)) {
> +data = FIELD_DP32(data, ERROR_STATUS, OVERFLOW, 0);
> +}
> +if (FIELD_EX32(val32, ERROR_STATUS, UNDERFLOW)) {
> +data = FIELD_DP32(data, ERROR_STATUS, UNDERFLOW, 0);
> +}
> +if (FIELD_EX32(val32, ERROR_STATUS, CMDINVAL)) {
> +data = FIELD_DP32(data, ERROR_STATUS, CMDINVAL, 0);
> +}
> +if (FIELD_EX32(val32, ERROR_STATUS, CSIDINVAL)) {
> +data = FIELD_DP32(data, ERROR_STATUS, CSIDINVAL, 0);
> +}
> +if (FIELD_EX32(val32, ERROR_STATUS, ACCESSINVAL)) {
> +data = FIELD_DP32(data, ERROR_STATUS, ACCESSINVAL, 0);
> +}
> +s->regs[addr] = data;
> break;
> case IBEX_SPI_HOST_EVENT_ENABLE:
> /* Controls which classes of SPI events raise an interrupt. */
> diff --git a/include/hw/ssi/ibex_spi_host.h b/include/hw/ssi/ibex_spi_host.h
> index 3fedcb6805..1f6d077766 100644
> --- a/include/hw/ssi/ibex_spi_host.h
> +++ b/include/hw/ssi/ibex_spi_host.h
> @@ -40,7 +40,7 @@
> OBJECT_CHECK(IbexSPIHostState, (obj), TYPE_IBEX_SPI_HOST)
>
> /* SPI Registers */
> -#define IBEX_SPI_HOST_INTR_STATE (0x00 / 4) /* rw */
> +#define IBEX_SPI_HOST_INTR_STATE (0x00 / 4) /* rw1c */
> #define IBEX_SPI_HOST_INTR_ENABLE(0x04 / 4) /* rw */
> #define IBEX_SPI_HOST_INTR_TEST (0x08 / 4) /* wo */
> #define IBEX_SPI_HOST_ALERT_TEST (0x0c / 4) /* wo */
> @@ -54,7 +54,7 @@
> #define IBEX_SPI_HOST_TXDATA (0x28 / 4)
>
> #define IBEX_SPI_HOST_ERROR_ENABLE (0x2c / 4) /* rw */
> -#define IBEX_SPI_HOST_ERROR_STATUS (0x30 / 4) /* rw */
> +#define IBEX_SPI_HOST_ERROR_STATUS (0x30 / 4) /* rw1c */
> #define IBEX_SPI_HOST_EVENT_ENABLE (0x34 / 4) /* rw */
>
> /* FIFO Len in Bytes */
> --
> 2.37.1
>
>
Re: [PATCH v3 3/4] hw/riscv: virt: fix syscon subnode paths
On Thu, Aug 11, 2022 at 5:06 AM Conor Dooley wrote:
>
> From: Conor Dooley
>
> The reset and poweroff features of the syscon were originally added to
> top level, which is a valid path for a syscon subnode. Subsequently a
> reorganisation was carried out while implementing NUMA in which the
> subnodes were moved into the /soc node. As /soc is a "simple-bus", this
> path is invalid, and so dt-validate produces the following warnings:
>
> /stuff/qemu/qemu.dtb: soc: poweroff: {'value': [[21845]], 'offset': [[0]],
> 'regmap': [[4]], 'compatible': ['syscon-poweroff']} should not be valid under
> {'type': 'object'}
> From schema:
> /home/conor/.local/lib/python3.9/site-packages/dtschema/schemas/simple-bus.yaml
> /stuff/qemu/qemu.dtb: soc: reboot: {'value': [[30583]], 'offset': [[0]],
> 'regmap': [[4]], 'compatible': ['syscon-reboot']} should not be valid under
> {'type': 'object'}
> From schema:
> /home/conor/.local/lib/python3.9/site-packages/dtschema/schemas/simple-bus.yaml
>
> Move the syscon subnodes back to the top level and silence the warnings.
>
> Reported-by: Rob Herring
> Link:
> https://lore.kernel.org/linux-riscv/20220803170552.ga2250266-r...@kernel.org/
> Fixes: 18df0b4695 ("hw/riscv: virt: Allow creating multiple NUMA sockets")
> Signed-off-by: Conor Dooley
Reviewed-by: Alistair Francis
Alistair
> ---
> I dropped your R-b Alistair intentionally.
> Tested both Linux and FreeBSD:
> [0.073406] device: 'poweroff': device_add
> [0.073441] bus: 'platform': add device poweroff
> [0.502347] bus: 'platform': add driver syscon-poweroff
> [0.502379] bus: 'platform': __driver_probe_device: matched device
> poweroff with driver syscon-poweroff
> [0.502397] bus: 'platform': really_probe: probing driver syscon-poweroff
> with device poweroff
> [0.502423] syscon-poweroff poweroff: no pinctrl handle
> [0.502681] syscon-poweroff poweroff: pm_power_off already claimed for
> sbi_srst_power_off
> [0.50] syscon-poweroff: probe of poweroff failed with error -16
> [0.073629] device: 'reboot': device_add
> [0.073664] bus: 'platform': add device reboot
> [0.500640] bus: 'platform': add driver syscon-reboot
> [0.500673] bus: 'platform': __driver_probe_device: matched device reboot
> with driver syscon-reboot
> [0.500694] bus: 'platform': really_probe: probing driver syscon-reboot
> with device reboot
> [0.500725] syscon-reboot reboot: no pinctrl handle
> [0.502168] driver: 'syscon-reboot': driver_bound: bound to device 'reboot'
> [0.502242] bus: 'platform': really_probe: bound device reboot to driver
> syscon-reboot
>
> syscon_power0: on ofwbus0
> syscon_power1: on ofwbus0
> ---
> hw/riscv/virt.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> index 8b2978076e..6f0fd1541b 100644
> --- a/hw/riscv/virt.c
> +++ b/hw/riscv/virt.c
> @@ -896,7 +896,7 @@ static void create_fdt_reset(RISCVVirtState *s, const
> MemMapEntry *memmap,
> test_phandle = qemu_fdt_get_phandle(mc->fdt, name);
> g_free(name);
>
> -name = g_strdup_printf("/soc/reboot");
> +name = g_strdup_printf("/reboot");
> qemu_fdt_add_subnode(mc->fdt, name);
> qemu_fdt_setprop_string(mc->fdt, name, "compatible", "syscon-reboot");
> qemu_fdt_setprop_cell(mc->fdt, name, "regmap", test_phandle);
> @@ -904,7 +904,7 @@ static void create_fdt_reset(RISCVVirtState *s, const
> MemMapEntry *memmap,
> qemu_fdt_setprop_cell(mc->fdt, name, "value", FINISHER_RESET);
> g_free(name);
>
> -name = g_strdup_printf("/soc/poweroff");
> +name = g_strdup_printf("/poweroff");
> qemu_fdt_add_subnode(mc->fdt, name);
> qemu_fdt_setprop_string(mc->fdt, name, "compatible", "syscon-poweroff");
> qemu_fdt_setprop_cell(mc->fdt, name, "regmap", test_phandle);
> --
> 2.37.1
>
>
Re: [PATCH for-7.1 3/4] target/loongarch: rename the TCG CPU "la464" to "qemu64-v1.00"
On 8/14/22 09:55, WANG Xuerui wrote: From: WANG Xuerui The only LoongArch CPU implemented is modeled after the Loongson 3A5000, but it is not the real thing, ... The 3A5000 is the SoC, as far as I could find, and the documentation of that says the core is named the la464. In general, high-fidelity models can and should be named after the real hardware model, while generic emulation-oriented models should be named after ISA levels. This wasn't intended to be a generic emulation model, as far as I know. There are missing features, but presumably those would eventually be filled in. For now, the best reference for LoongArch ISA levels is the revision number of the LoongArch ISA Manual, of which v1.00 is still the latest. (v1.01 and v1.02 are minor revisions without substantive change.) As defined by various specs, the vendor and model names are also reflected in respective CSRs, and are 8 bytes long. So, rename "la464" to "qemu64-v1.00", with "QEMU64" as vendor name and "v1.00" as model name. Eh, I suppose. I'm not really keen on this though, as I would presume there will be eventual forward progress on completing the real cpu model. We simply won't give any compatibility guarantees for loongarch until we are ready to do so. r~
Re: [PATCH for-7.1 2/4] target/loongarch: Trim type name suffix in -cpu help output
On 8/14/22 09:55, WANG Xuerui wrote:
From: WANG Xuerui
Also add a header and indentation for each entry, while at it.
Signed-off-by: WANG Xuerui
---
target/loongarch/cpu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/target/loongarch/cpu.c b/target/loongarch/cpu.c
index dc233ee209..4663539443 100644
--- a/target/loongarch/cpu.c
+++ b/target/loongarch/cpu.c
@@ -416,13 +416,15 @@ static void loongarch_la464_initfn(Object *obj)
static void loongarch_cpu_list_entry(gpointer data, gpointer user_data)
{
const char *typename = object_class_get_name(OBJECT_CLASS(data));
+int len = strlen(typename) - strlen(LOONGARCH_CPU_TYPE_SUFFIX);
-qemu_printf("%s\n", typename);
+qemu_printf(" %.*s\n", len, typename);
}
void loongarch_cpu_list(void)
{
GSList *list;
+qemu_printf("Available CPUs:\n");
list = object_class_get_list_sorted(TYPE_LOONGARCH_CPU, false);
g_slist_foreach(list, loongarch_cpu_list_entry, NULL);
g_slist_free(list);
This should be merged with the previous patch, so that we don't have an intermediate state
where help and loongarch_cpu_class_by_name disagree.
r~
Re: [PATCH for-7.1 1/4] target/loongarch: Only allow short -cpu arguments without type name suffix
On 8/14/22 09:55, WANG Xuerui wrote:
From: WANG Xuerui
Previously both "foo" and "foo-loongarch-cpu" are accepted for the -cpu
command-line option, the latter of which being excessively long and
redundant, hence unwanted. Remove support for consistency with other
targets and simpler code.
Signed-off-by: WANG Xuerui
This breaks testing, iirc, which is why both were accepted in the last change to this
code. You could allow just the short name so long as you don't try to provide the long
name in hw/loongarch/virt.c.
r~
---
target/loongarch/cpu.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/target/loongarch/cpu.c b/target/loongarch/cpu.c
index 941e2772bc..dc233ee209 100644
--- a/target/loongarch/cpu.c
+++ b/target/loongarch/cpu.c
@@ -573,14 +573,11 @@ static ObjectClass *loongarch_cpu_class_by_name(const
char *cpu_model)
{
ObjectClass *oc;
-oc = object_class_by_name(cpu_model);
+g_autofree char *typename = g_strdup_printf(LOONGARCH_CPU_TYPE_NAME("%s"),
+cpu_model);
+oc = object_class_by_name(typename);
if (!oc) {
-g_autofree char *typename
-= g_strdup_printf(LOONGARCH_CPU_TYPE_NAME("%s"), cpu_model);
-oc = object_class_by_name(typename);
-if (!oc) {
-return NULL;
-}
+return NULL;
}
if (object_class_dynamic_cast(oc, TYPE_LOONGARCH_CPU)
Re: [PULL 0/1] loongarch patch queue
On 8/14/22 08:47, Richard Henderson wrote: The following changes since commit 93f3dd604825824a7239aaf704baf74730aa3007: Merge tag 'pull-target-arm-20220812' of https://git.linaro.org/people/pmaydell/qemu-arm into staging (2022-08-12 10:46:43 -0700) are available in the Git repository at: https://gitlab.com/rth7680/qemu.git tags/pull-la-20220814 for you to fetch changes up to 1f90ce64fc6043470209f825c7763950ec2067a1: docs/system/loongarch: Update the LoongArch document (2022-08-13 04:45:03 -0700) Loongarch docs update Applied, thanks. Please update https://wiki.qemu.org/ChangeLog/7.1 as appropriate. r~ Xiaojuan Yang (1): docs/system/loongarch: Update the LoongArch document docs/system/loongarch/loongson3.rst | 104 +--- target/loongarch/README | 49 + 2 files changed, 97 insertions(+), 56 deletions(-)
Re: [PATCH] xio3130_upstream: Add ACS (Access Control Services) capability
What's wrong with not disabling the old version? On Sun, Aug 14, 2022 at 6:48 PM Michael S. Tsirkin wrote: > On Sun, Aug 14, 2022 at 03:47:49PM +0800, Paul Schlacter wrote: > > If it is a pcie device, check that all devices on the path from > > > > the device to the root complex have ACS enabled, and then the > > > > device will become an iommu_group. > > > > it will have the effect of isolation > > > > > > Signed-off-by: wlfightup > > I don't think we can do this unconditionally. Has to have > a property and disabled for old versions. > > > --- > > > > hw/pci-bridge/xio3130_upstream.c | 3 +++ > > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/hw/pci-bridge/xio3130_upstream.c b/hw/pci-bridge/ > > xio3130_upstream.c > > > > index 5ff46ef050..2df95b 100644 > > > > --- a/hw/pci-bridge/xio3130_upstream.c > > > > +++ b/hw/pci-bridge/xio3130_upstream.c > > > > @@ -37,6 +37,8 @@ > > > > #define XIO3130_SSVID_SSID 0 > > > > #define XIO3130_EXP_OFFSET 0x90 > > > > #define XIO3130_AER_OFFSET 0x100 > > > > +#define XIO3130_ACS_OFFSET \ > > > > +(XIO3130_AER_OFFSET + PCI_ERR_SIZEOF) > > > > > > static void xio3130_upstream_write_config(PCIDevice *d, uint32_t > address, > > > >uint32_t val, int len) > > > > @@ -92,6 +94,7 @@ static void xio3130_upstream_realize(PCIDevice *d, > Error > > **errp) > > > > goto err; > > > > } > > > > > > +pcie_acs_init(d, XIO3130_ACS_OFFSET); > > > > return; > > > > > > err: > > > > -- > > > > 2.24.3 (Apple Git-128) > > > >
[PATCH for-7.1 0/4] Last-minute LoongArch CPU model naming tweaks
Hi, Some people are already testing out the 7.1 RCs for the LoongArch emulation, and have suggested improvements to the CPU model naming scheme. While assessing the situation I also found the documentation already out-of-date, in addition to being especially hard to read (for a Chinese who could *not* understand Chinglish, though). Sorry for being really late (I've mostly been focusing on my day job and LLVM bringup work for LoongArch recently), but hopefully these changes could still be integrated, because target/loongarch is fresh addition for 7.1 nobody should have depended on its implementation details yet. Anyway, since the "new world" ecosystem isn't expected to mature and attract lots of users very soon, it could be acceptable to just punt this to 7.2, and issue incompatible change notices as usual. I personally would be fine with either. WANG Xuerui (4): target/loongarch: Only allow short -cpu arguments without type name suffix target/loongarch: Trim type name suffix in -cpu help output target/loongarch: rename the TCG CPU "la464" to "qemu64-v1.00" docs, target/loongarch: Rewrite the LoongArch docs docs/system/loongarch/loongson3.rst | 41 docs/system/loongarch/virt.rst | 41 hw/loongarch/virt.c | 14 +--- target/loongarch/README | 99 - target/loongarch/README.md | 75 ++ target/loongarch/cpu.c | 21 +++--- 6 files changed, 128 insertions(+), 163 deletions(-) delete mode 100644 docs/system/loongarch/loongson3.rst create mode 100644 docs/system/loongarch/virt.rst delete mode 100644 target/loongarch/README create mode 100644 target/loongarch/README.md -- 2.35.1
[PATCH v2 1/1] docs: pcie: describe PCIe option ROMs
Provide a descriptions of the options that control the emulation of option ROMS for PCIe devices. Signed-off-by: Heinrich Schuchardt --- v2: correct description of rombar property use romfile= to suppress option ROM loading --- docs/pcie.txt | 28 1 file changed, 28 insertions(+) diff --git a/docs/pcie.txt b/docs/pcie.txt index 89e3502075..b60f189bd4 100644 --- a/docs/pcie.txt +++ b/docs/pcie.txt @@ -292,6 +292,34 @@ PCI-PCI Bridge slots can be used for legacy PCI host devices. If you can see the "Express Endpoint" capability in the output, then the device is indeed PCI Express. +8. Option ROM += +PCIe devices may provide an option ROM. The following properties control the +emulation of the option ROM: + +``rombar`` (default: ``1``) + For vfio-pci devices a vendor and product ID based denylist exists which + controls if an available option ROM shall be probed. The 'rombar' option + allows to override this setting. The value is used as follows: + 0 = skip probing, 1 = force probing + +``romfile`` + Defines the name of the file to be loaded as option ROM. + The file size may neither exceed 2 GiB nor ``romsize``. + Some devices like virtio-net-pci define a default file name. + +``romsize`` (default: ``-1``) + Specifies the size of the option ROM in bytes. The value must be either + ``-1`` or a power of two. ``-1`` signifies unlimited size. + +Some QEMU PCIe devices like virtio-net-pci use an option ROM by default. In the +following example the option ROM of a virtio-net-pci device is disabled by +specifying an empty ``romfile`` property. This is useful for architectures where +QEMU does not supply an option ROM file. + +.. code-block:: console + +-device virtio-net-pci,netdev=eth1,mq=on,romfile= 7. Virtio devices = -- 2.36.1
[PATCH for-7.1 2/4] target/loongarch: Trim type name suffix in -cpu help output
From: WANG Xuerui
Also add a header and indentation for each entry, while at it.
Signed-off-by: WANG Xuerui
---
target/loongarch/cpu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/target/loongarch/cpu.c b/target/loongarch/cpu.c
index dc233ee209..4663539443 100644
--- a/target/loongarch/cpu.c
+++ b/target/loongarch/cpu.c
@@ -416,13 +416,15 @@ static void loongarch_la464_initfn(Object *obj)
static void loongarch_cpu_list_entry(gpointer data, gpointer user_data)
{
const char *typename = object_class_get_name(OBJECT_CLASS(data));
+int len = strlen(typename) - strlen(LOONGARCH_CPU_TYPE_SUFFIX);
-qemu_printf("%s\n", typename);
+qemu_printf(" %.*s\n", len, typename);
}
void loongarch_cpu_list(void)
{
GSList *list;
+qemu_printf("Available CPUs:\n");
list = object_class_get_list_sorted(TYPE_LOONGARCH_CPU, false);
g_slist_foreach(list, loongarch_cpu_list_entry, NULL);
g_slist_free(list);
--
2.35.1
[PATCH for-7.1 4/4] docs, target/loongarch: Rewrite the LoongArch docs
From: WANG Xuerui Much information is already outdated in its current form, not to mention the hard-to-understand Chinglish. Rewrite to hopefully de-duplicate and re-organize things, and reflect the latest status of LoongArch at upstream. Signed-off-by: WANG Xuerui --- docs/system/loongarch/loongson3.rst | 41 docs/system/loongarch/virt.rst | 41 target/loongarch/README | 99 - target/loongarch/README.md | 75 ++ 4 files changed, 116 insertions(+), 140 deletions(-) delete mode 100644 docs/system/loongarch/loongson3.rst create mode 100644 docs/system/loongarch/virt.rst delete mode 100644 target/loongarch/README create mode 100644 target/loongarch/README.md diff --git a/docs/system/loongarch/loongson3.rst b/docs/system/loongarch/loongson3.rst deleted file mode 100644 index fa3acd01c0..00 --- a/docs/system/loongarch/loongson3.rst +++ /dev/null @@ -1,41 +0,0 @@ -:orphan: - -== -loongson3 virt generic platform (``virt``) -== - -The ``virt`` machine use gpex host bridge, and there are some -emulated devices on virt board, such as loongson7a RTC device, -IOAPIC device, ACPI device and so on. - -Supported devices -- - -The ``virt`` machine supports: -- Gpex host bridge -- Ls7a RTC device -- Ls7a IOAPIC device -- Ls7a ACPI device -- Fw_cfg device -- PCI/PCIe devices -- Memory device -- CPU device. Type: Loongson-3A5000. - -CPU and machine Type - - -The ``qemu-system-loongarch64`` provides emulation for virt -machine. You can specify the machine type ``virt`` and -cpu type ``Loongson-3A5000``. - -Boot options - - -Now the ``virt`` machine can run test program in ELF format and the -method of compiling is in target/loongarch/README. - -.. code-block:: bash - - $ qemu-system-loongarch64 -machine virt -m 4G -cpu Loongson-3A5000 \ - -smp 1 -kernel hello -monitor none -display none \ - -chardev file,path=hello.out,id=output -serial chardev:output diff --git a/docs/system/loongarch/virt.rst b/docs/system/loongarch/virt.rst new file mode 100644 index 00..2d8f7e1db5 --- /dev/null +++ b/docs/system/loongarch/virt.rst @@ -0,0 +1,41 @@ +:orphan: + += +LoongArch generic virtualized platform (``virt``) += + +The ``virt`` machine has a GPEX host bridge, and some more emulated devices +such as the LS7A RTC, IOAPIC, ACPI device and so on. + +Being a machine type designed for virtualized use cases, the machine resembles +a Loongson 3A5000 + LS7A1000 board, but is not an exact emulation. +For example, only cascading of the EXTIOI interrupt is implemented. +Also, only the RTC block of the LS7A1000 is emulated; for the other devices +the QEMU models are used. +Normally you do not need to care about any of these. + +Supported devices +- + +The ``virt`` machine supports: + +- GPEX host bridge +- LS7A RTC device +- LS7A IOAPIC device +- LS7A ACPI device +- fw_cfg device +- PCI/PCIe devices +- Memory device +- CPU device. Defaults to ``qemu64-v1.00``. + +Boot options + + +Some more information could be found in the QEMU sources at +``target/loongarch/README.md``. A simple example being: + +.. code-block:: bash + + $ qemu-system-loongarch64 -machine virt -m 4G -smp 1 -kernel hello \ + -monitor none -display none \ + -chardev file,path=hello.out,id=output -serial chardev:output diff --git a/target/loongarch/README b/target/loongarch/README deleted file mode 100644 index 1823375d04..00 --- a/target/loongarch/README +++ /dev/null @@ -1,99 +0,0 @@ -- Introduction - - LoongArch is the general processor architecture of Loongson. - - The following versions of the LoongArch core are supported -core: 3A5000 - https://github.com/loongson/LoongArch-Documentation/releases/download/2021.08.17/LoongArch-Vol1-v1.00-EN.pdf - - We can get the latest loongarch documents at https://github.com/loongson/LoongArch-Documentation/tags. - - -- System emulation - - Mainly emulate a virt 3A5000 board and ls7a bridge that is not exactly the same as the host. - 3A5000 support multiple interrupt cascading while here we just emulate the extioi interrupt - cascading. LS7A1000 host bridge support multiple devices, such as sata, gmac, uart, rtc - and so on. But we just realize the rtc. Others use the qemu common devices. It does not affect - the general use. We also introduced the emulation of devices at docs/system/loongarch/virt.rst. - - This version only supports running binary files in ELF format, and does not depend on BIOS and kernel file. - You can compile the test program with 'make & make check-tcg' and run the test case with the following command: - - 1. Install LoongArch cross-tools on X86 machines. - -Download cross-tools. - -
[PATCH for-7.1 3/4] target/loongarch: rename the TCG CPU "la464" to "qemu64-v1.00"
From: WANG Xuerui
The only LoongArch CPU implemented is modeled after the Loongson 3A5000,
but it is not the real thing, and at least one feature [1] is missing
that actually made the model incompatible with the real 3A5000. What's
more, the model is currently named "la464", while none of the
micro-architecture-specific things are currently present, further making
things needlessly complex.
In general, high-fidelity models can and should be named after the real
hardware model, while generic emulation-oriented models should be named
after ISA levels. For now, the best reference for LoongArch ISA levels
is the revision number of the LoongArch ISA Manual, of which v1.00 is
still the latest. (v1.01 and v1.02 are minor revisions without
substantive change.)
As defined by various specs, the vendor and model names are also
reflected in respective CSRs, and are 8 bytes long. So, rename "la464"
to "qemu64-v1.00", with "QEMU64" as vendor name and "v1.00" as model
name.
As the QEMU 7.1 hasn't been officially released, no downstream is
expected to depend on the old name, so this change should be safe for
7.1.
[1]:
https://lore.kernel.org/loongarch/20220726094049.7200-2-maob...@loongson.cn/
Signed-off-by: WANG Xuerui
---
hw/loongarch/virt.c| 14 ++
target/loongarch/cpu.c | 6 +++---
2 files changed, 5 insertions(+), 15 deletions(-)
diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c
index 5cc0b05538..35e2174a17 100644
--- a/hw/loongarch/virt.c
+++ b/hw/loongarch/virt.c
@@ -626,7 +626,6 @@ static void
loongarch_direct_kernel_boot(LoongArchMachineState *lams)
static void loongarch_init(MachineState *machine)
{
LoongArchCPU *lacpu;
-const char *cpu_model = machine->cpu_type;
ram_addr_t offset = 0;
ram_addr_t ram_size = machine->ram_size;
uint64_t highram_size = 0;
@@ -634,15 +633,6 @@ static void loongarch_init(MachineState *machine)
LoongArchMachineState *lams = LOONGARCH_MACHINE(machine);
int i;
-if (!cpu_model) {
-cpu_model = LOONGARCH_CPU_TYPE_NAME("la464");
-}
-
-if (!strstr(cpu_model, "la464")) {
-error_report("LoongArch/TCG needs cpu type la464");
-exit(1);
-}
-
if (ram_size < 1 * GiB) {
error_report("ram_size must be greater than 1G.");
exit(1);
@@ -749,10 +739,10 @@ static void loongarch_class_init(ObjectClass *oc, void
*data)
{
MachineClass *mc = MACHINE_CLASS(oc);
-mc->desc = "Loongson-3A5000 LS7A1000 machine";
+mc->desc = "LoongArch64 v1.00-compatible LS7A1000 machine";
mc->init = loongarch_init;
mc->default_ram_size = 1 * GiB;
-mc->default_cpu_type = LOONGARCH_CPU_TYPE_NAME("la464");
+mc->default_cpu_type = LOONGARCH_CPU_TYPE_NAME("qemu64-v1.00");
mc->default_ram_id = "loongarch.ram";
mc->max_cpus = LOONGARCH_MAX_VCPUS;
mc->is_default = 1;
diff --git a/target/loongarch/cpu.c b/target/loongarch/cpu.c
index 4663539443..0a41509a0c 100644
--- a/target/loongarch/cpu.c
+++ b/target/loongarch/cpu.c
@@ -527,9 +527,9 @@ static uint64_t loongarch_qemu_read(void *opaque, hwaddr
addr, unsigned size)
return 1ULL << IOCSRF_MSI | 1ULL << IOCSRF_EXTIOI |
1ULL << IOCSRF_CSRIPI;
case VENDOR_REG:
-return 0x6e6f73676e6f6f4cULL; /* "Loongson" */
+return 0x3436554d4551ULL; /* "QEMU64" */
case CPUNAME_REG:
-return 0x303030354133ULL; /* "3A5000" */
+return 0x30302e3176ULL; /* "v1.00" */
case MISC_FUNC_REG:
return 1ULL << IOCSRM_EXTIOI_EN;
}
@@ -715,7 +715,7 @@ static const TypeInfo loongarch_cpu_type_infos[] = {
.class_size = sizeof(LoongArchCPUClass),
.class_init = loongarch_cpu_class_init,
},
-DEFINE_LOONGARCH_CPU_TYPE("la464", loongarch_la464_initfn),
+DEFINE_LOONGARCH_CPU_TYPE("qemu64-v1.00", loongarch_la464_initfn),
};
DEFINE_TYPES(loongarch_cpu_type_infos)
--
2.35.1
[PATCH for-7.1 1/4] target/loongarch: Only allow short -cpu arguments without type name suffix
From: WANG Xuerui
Previously both "foo" and "foo-loongarch-cpu" are accepted for the -cpu
command-line option, the latter of which being excessively long and
redundant, hence unwanted. Remove support for consistency with other
targets and simpler code.
Signed-off-by: WANG Xuerui
---
target/loongarch/cpu.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/target/loongarch/cpu.c b/target/loongarch/cpu.c
index 941e2772bc..dc233ee209 100644
--- a/target/loongarch/cpu.c
+++ b/target/loongarch/cpu.c
@@ -573,14 +573,11 @@ static ObjectClass *loongarch_cpu_class_by_name(const
char *cpu_model)
{
ObjectClass *oc;
-oc = object_class_by_name(cpu_model);
+g_autofree char *typename = g_strdup_printf(LOONGARCH_CPU_TYPE_NAME("%s"),
+cpu_model);
+oc = object_class_by_name(typename);
if (!oc) {
-g_autofree char *typename
-= g_strdup_printf(LOONGARCH_CPU_TYPE_NAME("%s"), cpu_model);
-oc = object_class_by_name(typename);
-if (!oc) {
-return NULL;
-}
+return NULL;
}
if (object_class_dynamic_cast(oc, TYPE_LOONGARCH_CPU)
--
2.35.1
[PULL 1/1] docs/system/loongarch: Update the LoongArch document
From: Xiaojuan Yang 1. Add some information about how to boot the LoongArch virt machine by uefi bios and linux kernel and how to access the source code or binary file. 2. Move the explanation of LoongArch system emulation in the target/loongarch/README to docs/system/loongarch/loongson3.rst Signed-off-by: Xiaojuan Yang Reviewed-by: Song Gao Message-Id: <20220812091957.3338126-1-yangxiaoj...@loongson.cn> Signed-off-by: Richard Henderson --- docs/system/loongarch/loongson3.rst | 104 +--- target/loongarch/README | 49 + 2 files changed, 97 insertions(+), 56 deletions(-) diff --git a/docs/system/loongarch/loongson3.rst b/docs/system/loongarch/loongson3.rst index fa3acd01c0..1bdab44e27 100644 --- a/docs/system/loongarch/loongson3.rst +++ b/docs/system/loongarch/loongson3.rst @@ -15,27 +15,115 @@ The ``virt`` machine supports: - Gpex host bridge - Ls7a RTC device - Ls7a IOAPIC device -- Ls7a ACPI device +- ACPI GED device - Fw_cfg device - PCI/PCIe devices - Memory device -- CPU device. Type: Loongson-3A5000. +- CPU device. Type: la464-loongarch-cpu. CPU and machine Type The ``qemu-system-loongarch64`` provides emulation for virt machine. You can specify the machine type ``virt`` and -cpu type ``Loongson-3A5000``. +cpu type ``la464-loongarch-cpu``. Boot options -Now the ``virt`` machine can run test program in ELF format and the -method of compiling is in target/loongarch/README. +We can boot the LoongArch virt machine by specifying the uefi bios, +initrd, and linux kernel. And those source codes and binary files +can be accessed by following steps. + +(1) booting command: .. code-block:: bash - $ qemu-system-loongarch64 -machine virt -m 4G -cpu Loongson-3A5000 \ - -smp 1 -kernel hello -monitor none -display none \ - -chardev file,path=hello.out,id=output -serial chardev:output + $ qemu-system-loongarch64 -machine virt -m 4G -cpu la464-loongarch-cpu \ + -smp 1 -bios QEMU_EFI.fd -kernel vmlinuz.efi -initrd initrd.img \ + -append "root=/dev/ram rdinit=/sbin/init consol e=ttyS0,115200" \ + --nographic + +Note: The running speed may be a little slow, as the performance of our +qemu and uefi bios is not perfect, and it is being fixed. + +(2) cross compiler tools: + +.. code-block:: bash + + wget https://github.com/loongson/build-tools/releases/download/ \ + 2022.05.29/loongarch64-clfs-5.0-cross-tools-gcc-full.tar.xz + + tar -vxf loongarch64-clfs-5.0-cross-tools-gcc-full.tar.xz + +(3) qemu compile configure option: + +.. code-block:: bash + + ./configure --disable-rdma --disable-pvrdma --prefix=usr \ + --target-list="loongarch64-softmmu" \ + --disable-libiscsi --disable-libnfs --disable-libpmem \ + --disable-glusterfs --enable-libusb --enable-usb-redir \ + --disable-opengl --disable-xen --enable-spice \ + --enable-debug --disable-capstone --disable-kvm \ + --enable-profiler + make + +(4) uefi bios source code and compile method: + +.. code-block:: bash + + git clone https://github.com/loongson/edk2-LoongarchVirt.git + + cd edk2-LoongarchVirt + + git submodule update --init + + export PATH=$YOUR_COMPILER_PATH/bin:$PATH + + export WORKSPACE=`pwd` + + export PACKAGES_PATH=$WORKSPACE/edk2-LoongarchVirt + + export GCC5_LOONGARCH64_PREFIX=loongarch64-unknown-linux-gnu- + + edk2-LoongarchVirt/edksetup.sh + + make -C edk2-LoongarchVirt/BaseTools + + build --buildtarget=DEBUG --tagname=GCC5 --arch=LOONGARCH64 --platform=OvmfPkg/LoongArchQemu/Loongson.dsc + + build --buildtarget=RELEASE --tagname=GCC5 --arch=LOONGARCH64 --platform=OvmfPkg/LoongArchQemu/Loongson.dsc + +The efi binary file path: + + Build/LoongArchQemu/DEBUG_GCC5/FV/QEMU_EFI.fd + + Build/LoongArchQemu/RELEASE_GCC5/FV/QEMU_EFI.fd + +(5) linux kernel source code and compile method: + +.. code-block:: bash + + git clone https://github.com/loongson/linux.git + + export PATH=$YOUR_COMPILER_PATH/bin:$PATH + + export LD_LIBRARY_PATH=$YOUR_COMPILER_PATH/lib:$LD_LIBRARY_PATH + + export LD_LIBRARY_PATH=$YOUR_COMPILER_PATH/loongarch64-unknown-linux-gnu/lib/:$LD_LIBRARY_PATH + + make ARCH=loongarch CROSS_COMPILE=loongarch64-unknown-linux-gnu- loongson3_defconfig + + make ARCH=loongarch CROSS_COMPILE=loongarch64-unknown-linux-gnu- + + make ARCH=loongarch CROSS_COMPILE=loongarch64-unknown-linux-gnu- install + + make ARCH=loongarch CROSS_COMPILE=loongarch64-unknown-linux-gnu- modules_install + +Note: The branch of linux source code is loongarch-next. + +(6) initrd file: + + You can use busybox tool and the linux modules to make a initrd file. Or you can access the + binary files: https://github.com/yangxiaojuan-loongson/qemu-binary diff --git a/target/loongarch/README b/target/loongarch/README index 1823375d04..0b9dc0d40a 100644 --- a/target/loongarch/README +++ b/target/loongarch/README @@ -11,54 +11,7 @@ - System
[PULL 0/1] loongarch patch queue
The following changes since commit 93f3dd604825824a7239aaf704baf74730aa3007: Merge tag 'pull-target-arm-20220812' of https://git.linaro.org/people/pmaydell/qemu-arm into staging (2022-08-12 10:46:43 -0700) are available in the Git repository at: https://gitlab.com/rth7680/qemu.git tags/pull-la-20220814 for you to fetch changes up to 1f90ce64fc6043470209f825c7763950ec2067a1: docs/system/loongarch: Update the LoongArch document (2022-08-13 04:45:03 -0700) Loongarch docs update Xiaojuan Yang (1): docs/system/loongarch: Update the LoongArch document docs/system/loongarch/loongson3.rst | 104 +--- target/loongarch/README | 49 + 2 files changed, 97 insertions(+), 56 deletions(-)
Re: [PATCH] xio3130_upstream: Add ACS (Access Control Services) capability
On Sun, Aug 14, 2022 at 03:47:49PM +0800, Paul Schlacter wrote: > If it is a pcie device, check that all devices on the path from > > the device to the root complex have ACS enabled, and then the > > device will become an iommu_group. > > it will have the effect of isolation > > > Signed-off-by: wlfightup I don't think we can do this unconditionally. Has to have a property and disabled for old versions. > --- > > hw/pci-bridge/xio3130_upstream.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > diff --git a/hw/pci-bridge/xio3130_upstream.c b/hw/pci-bridge/ > xio3130_upstream.c > > index 5ff46ef050..2df95b 100644 > > --- a/hw/pci-bridge/xio3130_upstream.c > > +++ b/hw/pci-bridge/xio3130_upstream.c > > @@ -37,6 +37,8 @@ > > #define XIO3130_SSVID_SSID 0 > > #define XIO3130_EXP_OFFSET 0x90 > > #define XIO3130_AER_OFFSET 0x100 > > +#define XIO3130_ACS_OFFSET \ > > + (XIO3130_AER_OFFSET + PCI_ERR_SIZEOF) > > > static void xio3130_upstream_write_config(PCIDevice *d, uint32_t address, > > uint32_t val, int len) > > @@ -92,6 +94,7 @@ static void xio3130_upstream_realize(PCIDevice *d, Error > **errp) > > goto err; > > } > > > + pcie_acs_init(d, XIO3130_ACS_OFFSET); > > return; > > > err: > > -- > > 2.24.3 (Apple Git-128) >
[PATCH] xio3130_upstream: Add ACS (Access Control Services) capability
If it is a pcie device, check that all devices on the path from the device to the root complex have ACS enabled, and then the device will become an iommu_group. it will have the effect of isolation Signed-off-by: wlfightup --- hw/pci-bridge/xio3130_upstream.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/hw/pci-bridge/xio3130_upstream.c b/hw/pci-bridge/xio3130_upstream.c index 5ff46ef050..2df95b 100644 --- a/hw/pci-bridge/xio3130_upstream.c +++ b/hw/pci-bridge/xio3130_upstream.c @@ -37,6 +37,8 @@ #define XIO3130_SSVID_SSID 0 #define XIO3130_EXP_OFFSET 0x90 #define XIO3130_AER_OFFSET 0x100 +#define XIO3130_ACS_OFFSET \ +(XIO3130_AER_OFFSET + PCI_ERR_SIZEOF) static void xio3130_upstream_write_config(PCIDevice *d, uint32_t address, uint32_t val, int len) @@ -92,6 +94,7 @@ static void xio3130_upstream_realize(PCIDevice *d, Error **errp) goto err; } +pcie_acs_init(d, XIO3130_ACS_OFFSET); return; err: -- 2.24.3 (Apple Git-128)
