| Message ID | 1315989802-18753-1-git-send-email-agraf@suse.de |
|---|---|
| State | New |
| Headers | show |
On 14 September 2011 09:42, Alexander Graf <agraf@suse.de> wrote: > The MPIC exports a register set for each CPU connected to it. They can all > be accessed through specific registers or using a shadow page that is mapped > differently depending on which CPU accesses it. > > This patch implements the shadow map, making it possible for guests to access > the CPU local registers using the same address on each CPU. > +static int get_current_cpu(void) > +{ > + return cpu_single_env->cpu_index; > +} This is the standard way of doing this (we use it on ARM as well), but it's pretty clearly a hack. "which master sent this memory transaction" is an attribute that ought to be passed down to the MMIO read/write functions, really (along with other interesting things like "priv or not?" and probably architecture specific attributes like ARM's "secure/non-secure"); this matches how hardware does it where the attributes are passed along as extra signals in the bus fabric. (Sometimes hardware also does this by having buses from the different cores be totally separate paths at the point where this kind of device is connected, before merging together later; we don't really support modelling that either :-)) Not a nak, just an observation while I'm thinking about it. -- PMM
Am 14.09.2011 um 12:07 schrieb Peter Maydell <peter.maydell@linaro.org>: > On 14 September 2011 09:42, Alexander Graf <agraf@suse.de> wrote: >> The MPIC exports a register set for each CPU connected to it. They can all >> be accessed through specific registers or using a shadow page that is mapped >> differently depending on which CPU accesses it. >> >> This patch implements the shadow map, making it possible for guests to access >> the CPU local registers using the same address on each CPU. > >> +static int get_current_cpu(void) >> +{ >> + return cpu_single_env->cpu_index; >> +} > > This is the standard way of doing this (we use it on ARM as well), but > it's pretty clearly a hack. "which master sent this memory transaction" > is an attribute that ought to be passed down to the MMIO read/write > functions, really (along with other interesting things like "priv or > not?" and probably architecture specific attributes like ARM's > "secure/non-secure"); this matches how hardware does it where the > attributes are passed along as extra signals in the bus fabric. > (Sometimes hardware also does this by having buses from the different > cores be totally separate paths at the point where this kind of device > is connected, before merging together later; we don't really support > modelling that either :-)) > > Not a nak, just an observation while I'm thinking about it. Yeah, I tend to agree in general. I'm not 100% sure in this case, as it's almost an in-cpu device. But it would be nice to pass this information on the mmio callbacks. However, right now this is the only way to do it, as we don't have the pretty flexible one implemented yet ;). Alex >
On 2011-09-14 12:07, Peter Maydell wrote: > On 14 September 2011 09:42, Alexander Graf <agraf@suse.de> wrote: >> The MPIC exports a register set for each CPU connected to it. They can all >> be accessed through specific registers or using a shadow page that is mapped >> differently depending on which CPU accesses it. >> >> This patch implements the shadow map, making it possible for guests to access >> the CPU local registers using the same address on each CPU. > >> +static int get_current_cpu(void) >> +{ >> + return cpu_single_env->cpu_index; >> +} > > This is the standard way of doing this (we use it on ARM as well), but > it's pretty clearly a hack. "which master sent this memory transaction" > is an attribute that ought to be passed down to the MMIO read/write > functions, really (along with other interesting things like "priv or > not?" and probably architecture specific attributes like ARM's > "secure/non-secure"); this matches how hardware does it where the > attributes are passed along as extra signals in the bus fabric. > (Sometimes hardware also does this by having buses from the different > cores be totally separate paths at the point where this kind of device > is connected, before merging together later; we don't really support > modelling that either :-)) > > Not a nak, just an observation while I'm thinking about it. Same problem has to be solved on x86. The way the local APIC is hooked up right now is totally broken, just works by chance because normal guests don't seriously stress the architecture. If we start dispatching CPU memory accesses via per-CPU memory roots, the problem can be solved without passing additional source information to the callbacks. Jan
On 09/14/2011 01:22 PM, Jan Kiszka wrote: > > > > This is the standard way of doing this (we use it on ARM as well), but > > it's pretty clearly a hack. "which master sent this memory transaction" > > is an attribute that ought to be passed down to the MMIO read/write > > functions, really (along with other interesting things like "priv or > > not?" and probably architecture specific attributes like ARM's > > "secure/non-secure"); this matches how hardware does it where the > > attributes are passed along as extra signals in the bus fabric. > > (Sometimes hardware also does this by having buses from the different > > cores be totally separate paths at the point where this kind of device > > is connected, before merging together later; we don't really support > > modelling that either :-)) > > > > Not a nak, just an observation while I'm thinking about it. > > Same problem has to be solved on x86. The way the local APIC is hooked > up right now is totally broken, just works by chance because normal > guests don't seriously stress the architecture. That, plus SMRAM. > If we start dispatching CPU memory accesses via per-CPU memory roots, > the problem can be solved without passing additional source information > to the callbacks. For that we need a full conversion.
Hi Aurelien / Blue, This is my current patch queue for ppc. Please pull. Alex The following changes since commit 44520db10b1b92f272348ab7028e7afc68ac3edf: Fabien Chouteau (1): Gdbstub: Fix back-trace on SPARC32 are available in the git repository at: git://repo.or.cz/qemu/agraf.git ppc-next Alexander Graf (38): PPC: Move openpic to target specific code compilation PPC: Add CPU local MMIO regions to MPIC PPC: Extend MPIC MMIO range PPC: Fix IPI support in MPIC PPC: Set MPIC IDE for IPI to 0 PPC: MPIC: Remove read functionality for WO registers PPC: MPIC: Fix CI bit definitions PPC: Bump MPIC up to 32 supported CPUs PPC: E500: create multiple envs PPC: E500: Generate IRQ lines for many CPUs device tree: add nop_node PPC: bamboo: Move host fdt copy to target PPC: KVM: Add generic function to read host clockfreq PPC: E500: Use generic kvm function for freq PPC: E500: Remove mpc8544_copy_soc_cell PPC: bamboo: Use kvm api for freq and clock frequencies PPC: KVM: Remove kvmppc_read_host_property PPC: KVM: Add stubs for kvm helper functions PPC: E500: Update freqs for all CPUs PPC: E500: Remove unneeded CPU nodes PPC: E500: Add PV spinning code PPC: E500: Update cpu-release-addr property in cpu nodes device tree: add add_subnode command device tree: dont fail operations device tree: give dt more size MPC8544DS: Remove CPU nodes MPC8544DS: Generate CPU nodes on init PPC: E500: Bump CPU count to 15 PPC: Add new target config for pseries KVM: update kernel headers PPC: Enable to use PAPR with PR style KVM PPC: SPAPR: Use KVM function for time info KVM: Update kernel headers openpic: Unfold read_IRQreg openpic: Unfold write_IRQreg PPC: Fix via-cuda memory registration PPC: Fix heathrow PIC to use little endian MMIO KVM: Update kernel headers David Gibson (8): pseries: Bugfixes for interrupt numbering in XICS code pseries: Add a phandle to the xicp interrupt controller device tree node pseries: interrupt controller should not have a 'reg' property pseries: More complete WIMG validation in H_ENTER code pseries: Add real mode debugging hcalls Implement POWER7's CFAR in TCG pseries: Implement hcall-bulk hypervisor interface pseries: Update SLOF firmware image Elie Richa (1): PPC: Fix sync instructions problem in SMP Fabien Chouteau (1): Gdbstub: handle read of fpscr Laurent Vivier (1): ppc: move ADB stuff from ppc_mac.h to adb.h Nishanth Aravamudan (1): pseries: use macro for firmware filename Paolo Bonzini (4): spapr: proper qdevification spapr: prepare for qdevification of irq spapr: make irq customizable via qdev vscsi: send the CHECK_CONDITION status down together with autosense data Scott Wood (3): kvm: ppc: booke206: use MMU API ppc: booke206: add "info tlb" support ppc: booke206: use MAV=2.0 TSIZE definition, fix 4G pages Stefan Hajnoczi (1): ppc405: use RAM_ADDR_FMT instead of %08lx Makefile.objs | 1 - Makefile.target | 10 +- configure | 3 + cpu-exec.c | 1 + device_tree.c | 92 ++++++++++-- device_tree.h | 2 + gdbstub.c | 2 +- hmp-commands.hx | 2 +- hw/adb.c | 2 +- hw/adb.h | 67 +++++++++ hw/cuda.c | 29 +++-- hw/heathrow_pic.c | 2 +- hw/openpic.c | 289 +++++++++++++++++++++----------------- hw/ppc405_boards.c | 5 +- hw/ppc440_bamboo.c | 16 ++- hw/ppc_mac.h | 42 ------ hw/ppc_newworld.c | 1 + hw/ppc_oldworld.c | 1 + hw/ppce500_mpc8544ds.c | 195 +++++++++++++++----------- hw/ppce500_spin.c | 186 ++++++++++++++++++++++++ hw/spapr.c | 52 ++++--- hw/spapr.h | 9 ++ hw/spapr_hcall.c | 220 +++++++++++++++++++++++++++-- hw/spapr_llan.c | 11 +-- hw/spapr_vio.c | 11 ++ hw/spapr_vio.h | 18 ++-- hw/spapr_vscsi.c | 13 +-- hw/spapr_vty.c | 10 +- hw/xics.c | 17 +-- linux-headers/asm-powerpc/kvm.h | 59 ++++++++- linux-headers/asm-x86/kvm_para.h | 14 ++ linux-headers/linux/kvm.h | 42 +++++- linux-headers/linux/kvm_para.h | 1 + monitor.c | 5 +- pc-bios/README | 2 +- pc-bios/mpc8544ds.dtb | Bin 2277 -> 2028 bytes pc-bios/mpc8544ds.dts | 12 -- pc-bios/slof.bin | Bin 579072 -> 578888 bytes target-ppc/cpu.h | 16 ++- target-ppc/helper.c | 93 ++++++++++++- target-ppc/kvm.c | 192 +++++++++++++++++++++++++ target-ppc/kvm_ppc.c | 65 --------- target-ppc/kvm_ppc.h | 44 ++++-- target-ppc/translate.c | 28 ++++ target-ppc/translate_init.c | 26 +++- 45 files changed, 1424 insertions(+), 484 deletions(-) create mode 100644 hw/adb.h create mode 100644 hw/ppce500_spin.c