@@ -362,8 +362,9 @@ static void ppc_spapr_init(ram_addr_t ram_size,
for (i = 0; i < MAX_SERIAL_PORTS; i++, irq++) {
if (serial_hds[i]) {
- spapr_vty_create(spapr->vio_bus, i, serial_hds[i],
- xics_find_qirq(spapr->icp, irq), irq);
+ spapr_vty_create(spapr->vio_bus, SPAPR_VTY_BASE_ADDRESS + i,
+ serial_hds[i], xics_find_qirq(spapr->icp, irq),
+ irq);
}
}
@@ -44,7 +44,8 @@ static void rtas_display_character(sPAPREnvironment *spapr,
uint32_t nret, target_ulong rets)
{
uint8_t c = rtas_ld(args, 0);
- VIOsPAPRDevice *sdev = spapr_vio_find_by_reg(spapr->vio_bus, 0);
+ VIOsPAPRDevice *sdev = spapr_vio_find_by_reg(spapr->vio_bus,
+ SPAPR_VTY_BASE_ADDRESS);
if (!sdev) {
rtas_st(rets, 0, -1);
@@ -32,6 +32,8 @@ enum VIOsPAPR_TCEAccess {
SPAPR_TCE_RW = 3,
};
+#define SPAPR_VTY_BASE_ADDRESS 0x30000000
+
struct VIOsPAPRDevice;
typedef struct VIOsPAPR_RTCE {
Currently the qemu pseries machine numbers its virtual serial devices from 0. However, existing pSeries machines running pHyp number them from 0x30000000. In theory these indices are arbitrary, since everything necessary for the kernel to find them is advertised in the device tree. However the debian installer, at least, incorrectly looks for a device named vty@30... to determine whether to use the hypervisor console. Therefore this patch moves the numbers we use to match the existing pHyp practice, in order to workaround broken userspace apps of this type. Signed-off-by: David Gibson <dwg@au1.ibm.com> --- hw/spapr.c | 5 +++-- hw/spapr_rtas.c | 3 ++- hw/spapr_vio.h | 2 ++ 3 files changed, 7 insertions(+), 3 deletions(-)