date:20211126

Re: [RFC PATCH 0/2] QEMU/openbios: PPC Software TLB support in the G4 family

2021-11-26 Thread Mark Cave-Ayland

On 24/11/2021 22:00, Fabiano Rosas wrote:

Fabiano Rosas  writes:

Hi all,

We have this bug in QEMU which indicates that we haven't been able to
run openbios on a 7450 cpu for quite a long time:

https://gitlab.com/qemu-project/qemu/-/issues/86

OK:
   $ ./qemu-system-ppc -serial mon:stdio -nographic -cpu 7410

   >> =
   >> OpenBIOS 1.1 [Nov 1 2021 20:36]
   ...

NOK:
   $ ./qemu-system-ppc -serial mon:stdio -nographic -cpu 7450 -d int
   Raise exception at fff08cc4 => 004e (00)
   QEMU: Terminated

The actual issue is straightforward. There is a non-architected
feature that QEMU has enabled by default that openbios doesn't know
about. From the user manual:

"The MPC7540 has a set of implementation-specific registers,
exceptions, and instructions that facilitate very efficient software
searching of the page tables in memory for when software table
searching is enabled (HID0[STEN] = 1). This section describes those
resources and provides three example code sequences that can be used
in a MPC7540 system for an efficient search of the translation tables
in software. These three code sequences can be used as handlers for
the three exceptions requiring access to the PTEs in the page tables
in memory in this case-instruction TLB miss, data TLB miss on load,
and data TLB miss on store exceptions."

The current state:

1) QEMU does not check HID0[STEN] and makes the feature always enabled
by setting these cpus with the POWERPC_MMU_SOFT_74xx MMU model,
instead of the generic POWERPC_MMU_32B.

2) openbios does not recognize the PVRs for those cpus and also does
not have any handlers for the software TLB exceptions (vectors 0x1000,
0x1100, 0x1200).

Some assumptions (correct me if I'm wrong please):

- openbios is the only firmware we use for the following cpus: 7441,
7445, 7450, 7451, 7455, 7457, 7447, 7447a, 7448.
- without openbios, we cannot have a guest running on these cpus.

So to bring 7450 back to life we would need to either:

a) find another firmware/guest OS code that supports the feature;

b) implement the switching of the feature in QEMU and have the guest
code enable it only when supported. That would take some fiddling with
the MMU code to: merge POWERPC_MMU_SOFT_74xx into POWERPC_MMU_32B,
check the HID0[STEN] bit, figure out how to switch from HW TLB miss to
SW TLB miss on demand, block access to the TLBMISS register (and
others) when the feature is off, and so on;

c) leave the feature enabled in QEMU and implement the software TLB
miss handlers in openbios. The UM provides sample code, so this is
easy;

d) remove support for software TLB search for the 7450 family and
switch the cpus to the POWERPC_MMU_32B model. This is by far the
easiest solution, but could cause problems for any (which?) guest OS
code that actually uses the feature. All of the existing code for the
POWERPC_MMU_SOFT_74xx MMU model would probably be removed since it
would be dead code then;

Option (c) seemed to me like a good compromise so this is a patch
series for openbios doing that and also adding the necessary PVRs so
we can get a working guest with these cpus without too much effort.

I have also a patch for QEMU adding basic sanity check tests for the
7400 and 7450 families. I'll send that separately to the QEMU ml.

Fabiano Rosas (2):
   ppc: Add support for MPC7450 software TLB miss interrupts
   ppc: Add PVRs for the MPC7450 family

  arch/ppc/qemu/init.c  |  52 ++
  arch/ppc/qemu/start.S | 236 +-
  2 files changed, 285 insertions(+), 3 deletions(-)

(Adding Mark because his email got somehow dropped from the original
message)

So with these patches in OpenBIOS we could get a bit further and call
into the Linux kernel using the same image as the one used for the
7400. However there seems to be no support for the 7450 software TLB in
the kernel. There are only handlers for the 4xx, 8xx and 603 which are
different code altogether. There's no mention of the TLBMISS and
PTEHI/LO registers in the code as well.

Do we know of any guest OS that implements the 7450 software TLB at
vectors 0x1000, 0x1100 and 0x1200? Otherwise replacing the
POWERPC_MMU_SOFT_74xx model with POWERPC_MMU_32B might be the only way
of getting an OS to run in the 7450 family.

My experience of anything other than the default CPUs used on the PPC Mac machines is 
basically zero, so you're certainly in new territory :)

I could live with your proposed solution c) although it would be nice to guard the 
extra vectors so that they remain uninitialised for the non-7450 CPUs. My main 
question is if the kernel itself doesn't support software TLBs then does adding the 
new code help at all? Or are you eventually planning for solution b) to improve 
QEMU's 7450 CPU emulation for developers without real hardware?

ATB,

Mark.

Re: [PATCH 1/2] block-backend: Retain permissions after migration

2021-11-26 Thread Peng Liang via

On 11/25/2021 9:53 PM, Hanna Reitz wrote:
> After migration, the permissions the guest device wants to impose on its
> BlockBackend are stored in blk->perm and blk->shared_perm.  In
> blk_root_activate(), we take our permissions, but keep all shared
> permissions open by calling `blk_set_perm(blk->perm, BLK_PERM_ALL)`.
> 
> Only afterwards (immediately or later, depending on the runstate) do we
> restrict the shared permissions by calling
> `blk_set_perm(blk->perm, blk->shared_perm)`.  Unfortunately, our first
> call with shared_perm=BLK_PERM_ALL has overwritten blk->shared_perm to
> be BLK_PERM_ALL, so this is a no-op and the set of shared permissions is
> not restricted.
> 
> Fix this bug by saving the set of shared permissions before invoking
> blk_set_perm() with BLK_PERM_ALL and restoring it afterwards.
> 
> Fixes: 5f7772c4d0cf32f4e779fcd5a69ae4dae24aeebf
>("block-backend: Defer shared_perm tightening migration
>completion")
> Reported-by: Peng Liang 
> Signed-off-by: Hanna Reitz 
> ---
>  block/block-backend.c | 11 +++
>  1 file changed, 11 insertions(+)
> 

Thanks for your patch!

Tested-by: Peng Liang

Re: [RFC PATCH v2 21/30] hw/intc: Add LoongArch extioi interrupt controller(EIOINTC)

2021-11-26 Thread Mark Cave-Ayland


On 25/11/2021 08:20, yangxiaojuan wrote:


Hi Mark,

On 11/11/2021 10:49 PM, Mark Cave-Ayland wrote:

On 11/11/2021 01:35, Xiaojuan Yang wrote:


This patch realize the EIOINTC interrupt controller.

Signed-off-by: Xiaojuan Yang 
Signed-off-by: Song Gao 
---
   hw/intc/Kconfig|   3 +
   hw/intc/loongarch_extioi.c | 570 +
   hw/intc/meson.build|   1 +
   hw/loongarch/Kconfig   |   1 +
   include/hw/intc/loongarch_extioi.h |  99 +
   include/hw/loongarch/loongarch.h   |   1 +
   6 files changed, 675 insertions(+)
   create mode 100644 hw/intc/loongarch_extioi.c
   create mode 100644 include/hw/intc/loongarch_extioi.h

diff --git a/hw/intc/Kconfig b/hw/intc/Kconfig
index c0dc12dfa0..a2d9efd5aa 100644
--- a/hw/intc/Kconfig
+++ b/hw/intc/Kconfig
@@ -82,3 +82,6 @@ config LOONGARCH_PCH_MSI
   select MSI_NONBROKEN
   bool
   select UNIMP
+
+config LOONGARCH_EXTIOI
+bool
diff --git a/hw/intc/loongarch_extioi.c b/hw/intc/loongarch_extioi.c
new file mode 100644
index 00..592cd8d1e2
--- /dev/null
+++ b/hw/intc/loongarch_extioi.c
@@ -0,0 +1,570 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Loongson 3A5000 ext interrupt controller emulation
+ *
+ * Copyright (C) 2021 Loongson Technology Corporation Limited
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/module.h"
+#include "qemu/log.h"
+#include "hw/irq.h"
+#include "hw/sysbus.h"
+#include "hw/loongarch/loongarch.h"
+#include "hw/qdev-properties.h"
+#include "exec/address-spaces.h"
+#include "hw/intc/loongarch_extioi.h"
+#include "migration/vmstate.h"
+
+#define DEBUG_APIC 0
+
+#define DPRINTF(fmt, ...) \
+do { \
+if (DEBUG_APIC) { \
+fprintf(stderr, "APIC: " fmt , ## __VA_ARGS__); \
+} \
+} while (0)


Again please use trace-events insead of DPRINTF().


+static void extioi_update_irq(void *opaque, int irq_num, int level)
+{
+loongarch_extioi *s = opaque;
+uint8_t  ipnum, cpu;
+unsigned long found1, found2;
+
+ipnum = s->sw_ipmap[irq_num];
+cpu   = s->sw_coremap[irq_num];
+if (level == 1) {
+if (test_bit(irq_num, (void *)s->en_reg8) == false) {
+return;
+}
+bitmap_set((void *)s->coreisr_reg8[cpu], irq_num, 1);
+found1 = find_next_bit((void *)&(s->sw_ipisr[cpu][ipnum]),
+   EXTIOI_IRQS, 0);
+bitmap_set((void *)&(s->sw_ipisr[cpu][ipnum]), irq_num, 1);
+
+if (found1 >= EXTIOI_IRQS) {
+qemu_set_irq(s->parent_irq[cpu][ipnum], level);
+}
+} else {
+bitmap_clear((void *)s->coreisr_reg8[cpu], irq_num, 1);
+found1 = find_next_bit((void *)&(s->sw_ipisr[cpu][ipnum]),
+   EXTIOI_IRQS, 0);
+bitmap_clear((void *)&(s->sw_ipisr[cpu][ipnum]), irq_num, 1);
+found2 = find_next_bit((void *)&(s->sw_ipisr[cpu][ipnum]),
+   EXTIOI_IRQS, 0);
+
+if ((found1 < EXTIOI_IRQS) && (found2 >= EXTIOI_IRQS)) {
+qemu_set_irq(s->parent_irq[cpu][ipnum], level);
+}
+}
+}
+
+static void extioi_setirq(void *opaque, int irq, int level)
+{
+loongarch_extioi *s = opaque;
+extioi_update_irq(s, irq, level);
+}
+
+static void extioi_handler(void *opaque, int irq, int level)
+{
+loongarch_extioi *extioi = (loongarch_extioi *)opaque;
+
+qemu_set_irq(extioi->irq[irq], level);
+}
+
+static uint32_t extioi_readb(void *opaque, hwaddr addr)
+{
+loongarch_extioi *state = opaque;


Add a QOM cast here.


+unsigned long offset, reg_count;
+uint8_t ret;
+int cpu;
+
+offset = addr & 0x;
+
+if ((offset >= EXTIOI_ENABLE_START) && (offset < EXTIOI_ENABLE_END)) {
+reg_count = (offset - EXTIOI_ENABLE_START);
+ret = state->en_reg8[reg_count];
+} else if ((offset >= EXTIOI_BOUNCE_START) &&
+   (offset < EXTIOI_BOUNCE_END)) {
+reg_count = (offset - EXTIOI_BOUNCE_START);
+ret = state->bounce_reg8[reg_count];
+} else if ((offset >= EXTIOI_COREISR_START) &&
+   (offset < EXTIOI_COREISR_END)) {
+reg_count = ((offset - EXTIOI_COREISR_START) & 0x1f);
+cpu = ((offset - EXTIOI_COREISR_START) >> 8) & 0x3;
+ret = state->coreisr_reg8[cpu][reg_count];
+} else if ((offset >= EXTIOI_IPMAP_START) &&
+   (offset < EXTIOI_IPMAP_END)) {
+reg_count = (offset - EXTIOI_IPMAP_START);
+ret = state->ipmap_reg8[reg_count];
+} else if ((offset >= EXTIOI_COREMAP_START) &&
+   (offset < EXTIOI_COREMAP_END)) {
+reg_count = (offset - EXTIOI_COREMAP_START);
+ret = state->coremap_reg8[reg_count];
+} else if ((offset >= EXTIOI_NODETYPE_START) &&
+   (offset < EXTIOI_NODETYPE_END)) {
+reg_count = (offset - EXTIOI_NODETYPE_START);
+ret = state->nodetype_reg8[reg_count];
+}
+
+DPRINTF("readb reg 0x" TARGET_FMT_plx " = %x\n", addr, ret);
+retu

Re: [OpenBIOS] Re: [RFC PATCH 0/2] QEMU/openbios: PPC Software TLB support in the G4 family

2021-11-26 Thread Cédric Le Goater


Hello,

On 11/25/21 10:38, Segher Boessenkool wrote:

Hi!

On Thu, Nov 25, 2021 at 01:45:00AM +0100, BALATON Zoltan wrote:

As for guests, those running on the said PowerMac G4 should have support
for these CPUs so maybe you can try some Mac OS X versions (or maybe


OSX uses hardware pagetables.


MorphOS but that is not the best for debugging as there's no source
available nor any help from its owners but just to see if it boots it may
be sufficient, it should work on real PowerMac G4).


I have no idea what MorphOS uses, but I bet HPT as well.  That is
because HPT is fastest in general.  Software TLB reloads are good in
special cases only; the most common is real-time OSes, which can use its
lower guaranteed latency for some special address spaces (and can have a
simpler address map in general).


The support was added to QEMU knowing that Linux didn't handle soft TLBs.
And the commit says that it was kept disabled initially. I guess that was
broken these last years.

C.


$ git show 7dbe11acd807
commit 7dbe11acd807
Author: Jocelyn Mayer 
Date:   Mon Oct 1 05:16:57 2007 +

Handle all MMU models in switches, even if it's just to abort because of 
lack
  of supporting code.
Implement 74xx software TLB model.
Keep 74xx with software TLB disabled, as Linux is not able to handle TLB 
miss
  on those processors.

C.

Re: [RFC PATCH 0/2] QEMU/openbios: PPC Software TLB support in the G4 family

2021-11-26 Thread Cédric Le Goater

On 11/26/21 09:01, Mark Cave-Ayland wrote:

On 24/11/2021 22:00, Fabiano Rosas wrote:

Fabiano Rosas writes:

Hi all,

We have this bug in QEMU which indicates that we haven't been able to
run openbios on a 7450 cpu for quite a long time:

https://gitlab.com/qemu-project/qemu/-/issues/86

OK:
$ ./qemu-system-ppc -serial mon:stdio -nographic -cpu 7410

>> =
>> OpenBIOS 1.1 [Nov 1 2021 20:36]
...

NOK:
$ ./qemu-system-ppc -serial mon:stdio -nographic -cpu 7450 -d int
Raise exception at fff08cc4 => 004e (00)
QEMU: Terminated

The actual issue is straightforward. There is a non-architected
feature that QEMU has enabled by default that openbios doesn't know
about. From the user manual:

"The MPC7540 has a set of implementation-specific registers,
exceptions, and instructions that facilitate very efficient software
searching of the page tables in memory for when software table
searching is enabled (HID0[STEN] = 1). This section describes those
resources and provides three example code sequences that can be used
in a MPC7540 system for an efficient search of the translation tables
in software. These three code sequences can be used as handlers for
the three exceptions requiring access to the PTEs in the page tables
in memory in this case-instruction TLB miss, data TLB miss on load,
and data TLB miss on store exceptions."

The current state:

1) QEMU does not check HID0[STEN] and makes the feature always enabled
by setting these cpus with the POWERPC_MMU_SOFT_74xx MMU model,
instead of the generic POWERPC_MMU_32B.

2) openbios does not recognize the PVRs for those cpus and also does
not have any handlers for the software TLB exceptions (vectors 0x1000,
0x1100, 0x1200).

Some assumptions (correct me if I'm wrong please):

- openbios is the only firmware we use for the following cpus: 7441,
7445, 7450, 7451, 7455, 7457, 7447, 7447a, 7448.
- without openbios, we cannot have a guest running on these cpus.

So to bring 7450 back to life we would need to either:

a) find another firmware/guest OS code that supports the feature;

b) implement the switching of the feature in QEMU and have the guest
code enable it only when supported. That would take some fiddling with
the MMU code to: merge POWERPC_MMU_SOFT_74xx into POWERPC_MMU_32B,
check the HID0[STEN] bit, figure out how to switch from HW TLB miss to
SW TLB miss on demand, block access to the TLBMISS register (and
others) when the feature is off, and so on;

c) leave the feature enabled in QEMU and implement the software TLB
miss handlers in openbios. The UM provides sample code, so this is
easy;

d) remove support for software TLB search for the 7450 family and
switch the cpus to the POWERPC_MMU_32B model. This is by far the
easiest solution, but could cause problems for any (which?) guest OS
code that actually uses the feature. All of the existing code for the
POWERPC_MMU_SOFT_74xx MMU model would probably be removed since it
would be dead code then;

Option (c) seemed to me like a good compromise so this is a patch
series for openbios doing that and also adding the necessary PVRs so
we can get a working guest with these cpus without too much effort.

I have also a patch for QEMU adding basic sanity check tests for the
7400 and 7450 families. I'll send that separately to the QEMU ml.

Fabiano Rosas (2):
ppc: Add support for MPC7450 software TLB miss interrupts
ppc: Add PVRs for the MPC7450 family

arch/ppc/qemu/init.c | 52 ++
arch/ppc/qemu/start.S | 236 +-
2 files changed, 285 insertions(+), 3 deletions(-)

(Adding Mark because his email got somehow dropped from the original
message)

So with these patches in OpenBIOS we could get a bit further and call
into the Linux kernel using the same image as the one used for the
7400. However there seems to be no support for the 7450 software TLB in
the kernel. There are only handlers for the 4xx, 8xx and 603 which are
different code altogether. There's no mention of the TLBMISS and
PTEHI/LO registers in the code as well.

Do we know of any guest OS that implements the 7450 software TLB at
vectors 0x1000, 0x1100 and 0x1200? Otherwise replacing the
POWERPC_MMU_SOFT_74xx model with POWERPC_MMU_32B might be the only way
of getting an OS to run in the 7450 family.

My experience of anything other than the default CPUs used on the PPC Mac
machines is basically zero, so you're certainly in new territory :)

I could live with your proposed solution c) although it would be nice to guard the extra vectors so that they remain uninitialised for the non-7450 CPUs. My main question is if the kernel itself doesn't support software TLBs then does adding the new code help at all?

1 2 >

1 - 100 of 101 matches

Mail list logo