Re: [Qemu-devel] [Qemu-ppc] [PATCH v2] spapr: ignore decr interrupts when MSR_EE is disabled

On Fri, 2017-07-14 at 09:34 +0530, Nikunj A Dadhania wrote: > Rebooting a SMP TCG guest is broken for both single/multi threaded TCG. > > When reset happens, all the CPUs are in halted state. First CPU is brought out > of reset and secondary CPUs would be initialized by the guest kernel using a >

Re: [Qemu-devel] [RFC PATCH 03/26] target/ppc/POWER9: add POWERPC_EXCP_POWER9

On Tue, 2017-07-11 at 15:52 +0200, Cédric Le Goater wrote: > > > Just as we could build a POWER9 with XICS in qemu, we could build a > > POWER8 with XIVE. > > That might be the case with a POWER9 running in POWER8 compat mode. > I need to check. Yes. In "compat" mode (or more generally if

Re: [Qemu-devel] [RFC PATCH 03/26] target/ppc/POWER9: add POWERPC_EXCP_POWER9

On Mon, 2017-07-10 at 14:49 +0200, Cédric Le Goater wrote: > On 07/10/2017 12:26 PM, David Gibson wrote: > > On Wed, Jul 05, 2017 at 07:13:16PM +0200, Cédric Le Goater wrote: > > > Prepare ground for the new exception model XIVE of POWER9. > > > > I'm a bit confused by this. The excp_model is

Re: [Qemu-devel] [Qemu-ppc] [PATCH RFC v1 0/3] Enable MTTCG on PPC64

On Tue, 2017-04-11 at 14:28 +0200, Cédric Le Goater wrote: > I really don't know.  > > Ben, now that we have mttcg activated by default on ppc, it takes  > a while for the linux kernel to do the early setup. I think we are > in the code section where we spin loop the secondaries. Most of the >

Re: [Qemu-devel] [PATCH 20/21] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge

On Mon, 2017-04-10 at 18:14 +1000, David Gibson wrote: > > +    switch (size) { > > +    case 1: > > +    break; > > +    case 2: > > +    val = bswap16(val); > > An unconditional bswap() seems unlikely to be correct.  What's the > purpose of thise? Though it is :-) I *think* ... I did

Re: [Qemu-devel] [PATCH 03/21] ppc/pnv: Add support for POWER8+ LPC Controller

On Thu, 2017-04-06 at 14:44 +0200, Cédric Le Goater wrote: > May be we could move that under the LPC object even if it is not > strictly > correct from a HW pov ?  I'm not fan of this. It's really not part of the LPC controller and it's specific to a certain crop of P8 machines. Cheers, Ben.

Re: [Qemu-devel] [PATCH 04/21] ppc/pnv: enable only one LPC bus

On Thu, 2017-04-06 at 14:35 +0200, Cédric Le Goater wrote: > but real HW (2 sockets OpenPOWER systems, garrison and firestone) > does  > not expose the LPC bus on the second chip, should we do so in qemu ? It's not so much HW as it it HostBoot. Not a huge deal. Cheers, Ben.

Re: [Qemu-devel] [PATCH 04/21] ppc/pnv: enable only one LPC bus

On Thu, 2017-04-06 at 13:50 +0200, Cédric Le Goater wrote: > > So, looking at hostboot, the lower level firmware, I think the > initial  > patch is more in sync with it :  > >    https://github.com/open-power/hostboot/blob/master-p8/src/usr/devt > ree/bld_devtree.C#L1038 > > David, can we keep

Re: [Qemu-devel] [PATCH 04/21] ppc/pnv: enable only one LPC bus

On Thu, 2017-04-06 at 11:06 +0200, Cédric Le Goater wrote: > The object will be initialized which raises some concern because we don't  > have the chip id at the moment but the object is still valid in some way.  > I think I need to remove it from the list of children of the chip or use  > a

Re: [Qemu-devel] [Qemu-ppc] [PATCH 48/77] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge

On Fri, 2017-03-17 at 09:24 +0100, Cédric Le Goater wrote: > I changed that to : > >     pnv_phb3_msi_update_config(phb->msis, comp, count - PHB_NUM_LSI); > > else the IRQ numbers overlap with the LSI and I think this why we > were  > uselessly looping on the EOI. > > Correct ?  Quite possibly

Re: [Qemu-devel] [PATCH for-2.10 6/8] ppc/pnv: Add cut down PSI bridge model and hookup external interrupt

On Wed, 2017-03-15 at 17:16 +1100, David Gibson wrote: > It might be cleaner to just revaluate the irq level from scratch > here, > and set the level, rather than doing this complicated dance to work > out if it has changed. Hrm... there was a reason I did it this way but I can't quite remember

Re: [Qemu-devel] [Qemu-ppc] [RFC PATCH qemu] spapr_pci: Create PCI-express root bus by default

On Wed, 2016-12-14 at 20:26 +0200, Marcel Apfelbaum wrote: > > > The Root complex includes the PCI bus, some configuration > > > registers if > > > needed, provides access to the configuration space, translates > > > relevant CPU > > > reads/writes to PCI(e) transactions... > > > > Do those

Re: [Qemu-devel] [Qemu-ppc] [RFC PATCH qemu] spapr_pci: Create PCI-express root bus by default

On Tue, 2016-12-13 at 14:25 +0200, Marcel Apfelbaum wrote: > > > Hrm, the suggestion of providing both a vanilla-PCI and PCI-E host > > > bridge came up before.  I think one of us spotted a problem with that, > > > but I don't recall what it was now.  I guess one is how libvirt would > > > map

Re: [Qemu-devel] [Qemu-ppc] [RFC PATCH qemu] spapr_pci: Create PCI-express root bus by default

On Fri, 2016-12-02 at 16:50 +1100, David Gibson wrote: > > Uh.. I don't entirely follow you.  From the host point of view there > are multiple iommu groups (PEs), but from the guest point of view > there's only one.  On the guest side iommu granularity is always > per-vPHB. Ok so the H_PUT_TCE

Re: [Qemu-devel] [Qemu-ppc] [RFC PATCH qemu] spapr_pci: Create PCI-express root bus by default

On Fri, 2016-12-02 at 15:18 +1100, David Gibson wrote: > But if you pass through multiple groups, things get weird.  On q35, > you'd generally expect physically separate (different slot) devices to > appear under separate root complexes.  Whereas on pseries they'll > appear as siblings on a

Re: [Qemu-devel] [Qemu-ppc] [PATCH] ppc: Make uninorth interrupt swizzling identical to Grackle

On Tue, 2016-11-22 at 02:34 +0100, BALATON Zoltan wrote: > > Is this going in for 2.8? If so, I'll need to apply the corresponding > > patch to OpenBIOS to match and also do a PPC testing cycle to make sure > > that there are no regressions on other OSs. Plus it would be useful to > > get both

Re: [Qemu-devel] [PATCH] ppc: BOOK3E: nothing should be done when MSR:PR is set

d-off-by: Vladimir Svoboda <ze.v...@gmail.com> Acked-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> > --- >  target-ppc/helper_regs.h | 11 +++ >  1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/target-ppc/helper_regs.h b/target-ppc/

Re: [Qemu-devel] [RFC] powernv: CPU compatibility modes don't make sense for powernv

On Fri, 2016-10-28 at 18:40 +0200, Cédric Le Goater wrote: >  > It makes perfect sense. The "cpu-version" property is for PAPR, not > for OPAL. > hostboot and skiboot put SPR_PVR in this property.  > > I will be careful using 'CPU_CORE(pc)->nr_threads' in the ICP patches > also.  No, the

Re: [Qemu-devel] target-ppc: gdbstub breakpoints get stuck in an infinite loop on next/continue

On Mon, 2016-10-24 at 12:00 +1100, David Gibson wrote: > Ben, does it look like the other extraneous changes in bd6fefe are at > least correct, apart from being in the wrong patch? It looks like part of my big rewrite of the exception stuff, so I'd assume it's mostly correct minus a few bugs I

Re: [Qemu-devel] target-ppc: gdbstub breakpoints get stuck in an infinite loop on next/continue

On Fri, 2016-10-21 at 15:18 +0100, Mark Cave-Ayland wrote: >  > bd6fefe71cec5a0c7d2be4ac96307f25db56abf9 is the first bad commit > commit bd6fefe71cec5a0c7d2be4ac96307f25db56abf9 > Author: Benjamin Herrenschmidt <b...@kernel.crashing.org> > Date:   Wed Jul 27 16:56:32 2016 +10

Re: [Qemu-devel] [PATCH v4 17/20] ppc/pnv: Add cut down PSI bridge model and hookup external interrupt

On Fri, 2016-10-14 at 17:32 +1100, David Gibson wrote: > >  static void pnv_lpc_isa_irq_handler_cpld(void *opaque, int n, int level) > >  { > > -    /* We don't yet emulate the PSI bridge which provides the external > > - * interrupt, so just drop interrupts on the floor > > - */ > > +   

Re: [Qemu-devel] [PATCH v4 03/20] ppc/pnv: add a core mask to PnvChip

On Fri, 2016-10-07 at 15:32 +1100, David Gibson wrote: > On Mon, Oct 03, 2016 at 09:24:39AM +0200, Cédric Le Goater wrote: > > This will be used to build real HW ids for the cores and enforce > some > > limits on the available cores per chip. > > Is there actually a practical reason to allow the

Re: [Qemu-devel] [PATCH v3 07/10] ppc/pnv: add XSCOM infrastructure

On Tue, 2016-09-27 at 11:10 +0200, Cédric Le Goater wrote: > >  > > > > > > +PowerPCCPU *cpu = POWERPC_CPU(cs); > > > +CPUPPCState *env = >env; > > > + > > > +cpu_synchronize_state(cs); > > > +env->spr[SPR_HMER] |= hmer_bits; > > > + > > > +/* XXX Need a CPU helper to set

Re: [Qemu-devel] [PATCH v3 07/10] ppc/pnv: add XSCOM infrastructure

On Tue, 2016-09-27 at 11:30 +0200, Cédric Le Goater wrote: > On 09/27/2016 11:10 AM, Cédric Le Goater wrote: > > > > > > > > > > > > > +#include > > > > + > > > > +static void xscom_complete(uint64_t hmer_bits) > > > > +{ > > > > +CPUState *cs = current_cpu; > > > > > > Hmm.. is

Re: [Qemu-devel] [PATCH v3 07/10] ppc/pnv: add XSCOM infrastructure

On Tue, 2016-09-27 at 07:54 +0200, Cédric Le Goater wrote: > > > but I guess if you have the decoding of those "core" registers  > > here as well, then that doesn't make so much sense. Those core registers may well change with P9, we havne't looked closely yet... > yes and there is also the

Re: [Qemu-devel] pseries-2.6 migration from QEMU-2.6 to QEMU-2.7 broken

On Fri, 2016-09-23 at 11:37 +1000, David Gibson wrote: > > For KVM HV there's a bit of a nit: that would disallow migration > between host cpus which aren't exactly the same model, but are close > enough that migration will work in practice. In that case we should use the architected PVR

Re: [Qemu-devel] pseries-2.6 migration from QEMU-2.6 to QEMU-2.7 broken

On Thu, 2016-09-22 at 13:27 +0200, Cédric Le Goater wrote: > > TCG migration succeeds and proceeds ahead. But fails somewhere > > ahead in > > powerpc exception handler: > > > > [qemu]$ ./ppc64-softmmu/qemu-system-ppc64  -machine pseries- > > 2.6,usb=off -vga none -nographic -m 2G   

Re: [Qemu-devel] pseries-2.6 migration from QEMU-2.6 to QEMU-2.7 broken

On Thu, 2016-09-22 at 12:32 +0200, Paolo Bonzini wrote: > *However* a better fix would be to preserve the old flags for > pseries-2.6, and only set the newer flags for pseries-2.7.  I'm not > saying you have to do this, but if it's not hard (no idea) why not learn > how to do it right. > > The

Re: [Qemu-devel] pseries-2.6 migration from QEMU-2.6 to QEMU-2.7 broken

On Thu, 2016-09-22 at 20:34 +1000, Alexey Kardashevskiy wrote: > > diff --git a/target-ppc/machine.c b/target-ppc/machine.c > > index 4820f22..1cf3779 100644 > > --- a/target-ppc/machine.c > > +++ b/target-ppc/machine.c > > @@ -563,8 +563,8 @@ const VMStateDescription vmstate_ppc_cpu = { > >   > > 

Re: [Qemu-devel] pseries-2.6 migration from QEMU-2.6 to QEMU-2.7 broken

On Thu, 2016-09-22 at 14:34 +0530, Nikunj A Dadhania wrote: > Something like this works for KVM: > > diff --git a/target-ppc/machine.c b/target-ppc/machine.c > index 4820f22..1cf3779 100644 > --- a/target-ppc/machine.c > +++ b/target-ppc/machine.c > @@ -563,8 +563,8 @@ const VMStateDescription

Re: [Qemu-devel] pseries-2.6 migration from QEMU-2.6 to QEMU-2.7 broken

On Thu, 2016-09-22 at 11:45 +0530, Bharata B Rao wrote: > On Thu, Sep 22, 2016 at 04:07:21PM +1000, Benjamin Herrenschmidt wrote: > > > > On Thu, 2016-09-22 at 10:51 +0530, Bharata B Rao wrote: > > > > > > The flag values are expected to remain same for a machin

Re: [Qemu-devel] pseries-2.6 migration from QEMU-2.6 to QEMU-2.7 broken

On Thu, 2016-09-22 at 10:51 +0530, Bharata B Rao wrote: > The flag values are expected to remain same for a machine version for > the migration to succeed, but this expectation is broken now. Should > we make the addition of these flags conditional on machine type > version ? > But these flags are

Re: [Qemu-devel] [PATCH] Add resolutions via the command-line

On Wed, 2016-09-21 at 19:18 -0400, G 3 wrote: >  > That can be done, but I was hoping to be able to do this via a   > command-line switch. But you still do that ! Your switch puts stuff in /options which OpenBIOS then picks up to construct the final list that it puts in the driver node. > That

Re: [Qemu-devel] [PATCH] Add resolutions via the command-line

On Wed, 2016-09-21 at 14:26 -0400, G 3 wrote: > > Nodes like chose, aliases, openprom are of class IOService. options   > is of class IODTNVRAM. It looks like this class has problems. I'm   > thinking since Alexander Graf did work in the mac_nvram.c file, he   > might know what is wrong. What is

[Qemu-devel] [PATCH] Fix tlb_vaddr_to_host with CONFIG_USER_ONLY

We use the wrong argument name for the g2h() macro ! The result ends up being something like (target_ulong)(uint64) + guest_base which is obviously wrong. Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- include/exec/cpu_ldst.h | 2 +- 1 file changed, 1 insertion

Re: [Qemu-devel] [PATCH] net: Add SunGEM device emulation as found on Apple UniNorth

On Wed, 2016-09-21 at 11:16 +0100, Alex Bennée wrote: >  > > > > > > total: 428 errors, 73 warnings, 1950 lines checked > > > > > > Your patch has style problems, please review.If any of these > > > errors > > > are false positives report them to the maintainer, see > > > CHECKPATCH in

Re: [Qemu-devel] [Qemu-ppc] [PATCH] net: Add SunGEM device emulation as found on Apple UniNorth

On Wed, 2016-09-21 at 13:18 +1000, David Gibson wrote: > > There are actually a couple of places where I agree with the style > > change, so I'll include that in a futher post after more useful > review > > has been posted (seriously, stylebots are just infuriating). > > So.. as irritating as you

Re: [Qemu-devel] [PATCH] Add resolutions via the command-line

On Tue, 2016-09-20 at 22:54 -0400, G 3 wrote: > You really want to remove the included list of resolutions? I was   > thinking about adding a lot more built-in resolutions in another   > patch. A built-in list is very convenient. I mean remove it from the driver and put it in OpenBIOS instead.

Re: [Qemu-devel] [PATCH v3 07/10] ppc/pnv: add XSCOM infrastructure

On Wed, 2016-09-21 at 15:56 +1000, David Gibson wrote: > > Yes, I think that's the way to go. > > That also means on P9 you can potentially just map the scom address > space directly into address_space_memory, instead of requiring a > redispatcher to do the address mangling. No. You still need

Re: [Qemu-devel] [PATCH v3 05/10] ppc/pnv: add a PnvCore object

On Wed, 2016-09-21 at 11:51 +1000, David Gibson wrote: > Ok, as noted elsewhere, I think you need to disassociate the PIR value > from the cpu_index.  It may be a little less elegant, but it'll make > your life much easier in the short and medium term. > > Apart from that, this looks pretty good,

Re: [Qemu-devel] [PATCH v3 04/10] ppc/pnv: add a PIR handler to PnvChip

On Wed, 2016-09-21 at 11:29 +1000, David Gibson wrote: > On Thu, Sep 15, 2016 at 02:45:54PM +0200, Cédric Le Goater wrote: > > > > P9 and P8 have some differences in the CPU PIR encoding. > > The thread id isn't in the PIR at all? Yes it is. Though on P9 there could be different encodings

Re: [Qemu-devel] [PATCH] Add resolutions via the command-line

On Tue, 2016-09-20 at 20:35 -0400, G 3 wrote: > > When I use the -prom-env option I can easily add properties to the   > options node. > Can something like this be done with the chosen node? We can make it so. That or we can add code to OpenBIOS to copy the list of resolutions into the

Re: [Qemu-devel] [PATCH] Add resolutions via the command-line

On Tue, 2016-09-20 at 00:01 -0400, G 3 wrote: > > Something is wrong with the options node in OpenBIOS. It is   > inaccessible from Mac OS X. When trying to access the options node,   > IORegistryExplorer always crashes. The other nodes are accessible.   > I'm not certain what the problem could

Re: [Qemu-devel] [PATCH v2] add resolutions via command-line

On Tue, 2016-09-20 at 09:51 -0400, G 3 wrote: > > The malloc() function used in this driver is used to allocate a > very   > small amount of space at most. We are realistically talking under > 2k.   > Running out of space is highly unlikely. I'm sure the user could do   > something evil to try to

Re: [Qemu-devel] [PATCH v2] add resolutions via command-line

On Tue, 2016-09-20 at 09:51 -0400, G 3 wrote: >  > > Is it worth renaming this to make it obvious that it is your > > (non-optimal) replacement, intentionally because you don't want to > > use > > the libc version? > > I originally thought about adding a prefix to all my functions. Ben   > what

Re: [Qemu-devel] KVM-PR is broken with current QEMU

On Tue, 2016-09-20 at 13:44 +0200, Thomas Huth wrote: > > Seems like KVM PR is using the "degraded" ISA variants (without the > 1TB > segments), but the new POWERPC_MMU_64K flag has not been added to > those. > Has this been done on purpose, or was this just by accident? > I can make KVM PR

Re: [Qemu-devel] [PATCH v2] add resolutions via command-line

Also .. your patch was all HTML and email-damaged... On Tue, 2016-09-20 at 19:01 +1000, Benjamin Herrenschmidt wrote: > On Tue, 2016-09-20 at 00:28 -0400, G 3 wrote: > > > + RegEntryID *entry_id; > > + OSErr err; > > + OSStatus os_status = noErr; > > +

Re: [Qemu-devel] [PATCH v2] add resolutions via command-line

On Tue, 2016-09-20 at 00:28 -0400, G 3 wrote: > + RegEntryID *entry_id; > + OSErr err; > + OSStatus os_status = noErr; > + Boolean is_done; > + void *value; > + RegPropertyValueSize property_size = -1; > + int index, res_set_count; > + char *set_str; > + > +

Re: [Qemu-devel] [PATCH v2 01/11] target-ppc: exceptions handling in icount mode

On Tue, 2016-09-20 at 11:42 +0300, Pavel Dovgalyuk wrote: > > > > From: David Gibson [mailto:da...@gibson.dropbear.id.au] > > On Thu, Sep 15, 2016 at 11:09:59AM +0300, Pavel Dovgalyuk wrote: > > > > > > From: Pavel Dovgalyuk > > > > > > This patch fixes exception

Re: [Qemu-devel] [PATCH] Add resolutions via the command-line

On Mon, 2016-09-19 at 08:44 -0400, G 3 wrote: > On Sep 19, 2016, at 2:24 AM, Benjamin Herrenschmidt wrote: > > > > > On Sat, 2016-09-17 at 23:31 -0400, G 3 wrote: > > > > > > Add the ability to add resolutions from the command-line. This > > > patc

Re: [Qemu-devel] [PATCH] Add resolutions via the command-line

On Sat, 2016-09-17 at 23:31 -0400, G 3 wrote: > Add the ability to add resolutions from the command-line. This > patch   > works by > looking for a property called 'resolutions' in the options node of   > OpenBIOS. > If it is found all the resolutions are parsed and loaded. > > Example

Re: [Qemu-devel] VGA driver debug output

On Fri, 2016-09-16 at 22:53 -0400, G 3 wrote: > Is there a way to make the VGA driver print information? I tried   > building the debug settings in CodeWarrior but it ends with an error.   > I'm trying to add a feature to the driver that will allow the user to   > add resolutions via the

Re: [Qemu-devel] Adding resolutions to the VGA driver

On Fri, 2016-09-16 at 12:58 +0200, Gerd Hoffmann wrote: > On Fr, 2016-09-16 at 08:06 +1000, Benjamin Herrenschmidt wrote: > > > > On Thu, 2016-09-15 at 13:21 -0400, Programmingkid wrote: > > > > > > There has been talk about what resolutions to add support for

Re: [Qemu-devel] Adding resolutions to the VGA driver

On Fri, 2016-09-16 at 12:13 +0200, Michael Fritscher wrote: > at least in Windows, the GUI doesn't display the CGA/EGA resolution, but  > the driver supports them and can be accessed via API. Some (rather old)  > games used that for example. For MacOS I wouldn't fret it. A lot of Apple monitors

Re: [Qemu-devel] Adding resolutions to the VGA driver

On Fri, 2016-09-16 at 10:37 +0200, Michael Fritscher wrote: >  > I assume that you left out the common CGA/EGA resolution > intentionally? It's not because a resolution exists somewhere that we need it in the driver's menu :-) Cheers, Ben.

Re: [Qemu-devel] [PATCH v3 09/10] ppc/pnv: add a LPC controller

On Thu, 2016-09-15 at 14:45 +0200, Cédric Le Goater wrote: > This version of the LPC controller model doesn't yet implement > support for the SerIRQ deserializer present in the Naples version > of the chip though some preliminary work is there. The version in my branch has this support btw.

Re: [Qemu-devel] [PATCH v3 07/10] ppc/pnv: add XSCOM infrastructure

On Thu, 2016-09-15 at 14:45 +0200, Cédric Le Goater wrote: >  - The PCB translation is too much of a constraint for a specific >    XSCOM address space, unless someone can explain me how to address 8 >    bytes at 0xb0021 and another 8 different bytes at 0xb0022. I don't >    think the address

Re: [Qemu-devel] Adding resolutions to the VGA driver

On Thu, 2016-09-15 at 13:21 -0400, Programmingkid wrote: > There has been talk about what resolutions to add support for in the > VGA driver. What do you think of this list: We should add check for the vram amount. There's only 16M emulated iirc, we need to check the combination resolution/depth

Re: [Qemu-devel] [PATCH v4 2/3] target-ppc: add flag in chech_tlb_flush()

On Thu, 2016-09-15 at 16:16 +1000, David Gibson wrote: > Oh, I see.  Hmm.  I don't know if that will make a real difference in > TCG or not. It will on 32-bit hosts. Cheers, Ben.

Re: [Qemu-devel] [PATCH v4 3/3] target-ppc: tlbie/tlbivax should have global effect

On Thu, 2016-09-15 at 10:25 +1000, David Gibson wrote: > >  void helper_booke206_tlbivax(CPUPPCState *env, target_ulong > address) > >  { > > -    PowerPCCPU *cpu = ppc_env_get_cpu(env); > > +    CPUState *cs; > >   > >  if (address & 0x4) { > >  /* flush all entries */ > > @@ -2774,11

Re: [Qemu-devel] [PATCH v3 2/3] target-ppc: add flag in chech_tlb_flush()

On Wed, 2016-09-14 at 09:23 +0530, Nikunj A Dadhania wrote: Hr... this is confusing, let me rephrase ;-) > Due to lazy tlb flushes, propagation of the tlb flush is delayed. Moreover, certain operations need to do broadcast flush, this too can be > delayed until we hit the operation that warrant

Re: [Qemu-devel] [PATCH v3 2/3] target-ppc: add flag in chech_tlb_flush()

On Wed, 2016-09-14 at 13:09 +1000, David Gibson wrote: > On Mon, Sep 12, 2016 at 11:18:33AM +0530, Nikunj A Dadhania wrote: > > > > The flag will be used to indicate whether broadcast tlb flush is > > needed > > or not. > > > > Moreover, BookS does both ptesync and tlbsync, so make that a nop >

Re: [Qemu-devel] [PATCH RFC 3/4] target-ppc: use atomic_cmpxchg for ld/st reservation

On Mon, 2016-09-12 at 09:39 +0100, Alex Bennée wrote: >  > They are now in Richard's tcg-next queue > > Message-Id: <1473282648-23487-1-git-send-email-...@twiddle.net> > Subject: [Qemu-devel] [PULL 00/18] tcg queued patches > > All the backends support the new fence op, so far only ARM, Alpha

Re: [Qemu-devel] [PATCH v3 3/3] target-ppc: tlbie should have global effect

On Mon, 2016-09-12 at 11:18 +0530, Nikunj A Dadhania wrote: > diff --git a/target-ppc/translate.c b/target-ppc/translate.c > index 5026804..d96ff66 100644 > --- a/target-ppc/translate.c > +++ b/target-ppc/translate.c > @@ -4448,6 +4448,7 @@ static void gen_tlbie(DisasContext *ctx) >  #if

Re: [Qemu-devel] [PATCH v3 0/3] ppc: Broadcast tlb flush should have global effect

On Mon, 2016-09-12 at 11:18 +0530, Nikunj A Dadhania wrote: > PowerPC targets should do tlb invalidation on other cpus on  > instructions that expect a global effect. > > * ptesync for BookS > * tlbsync primarily for BookE >   (for BookS make it a nop, as it always come along with ptesync) > *

Re: [Qemu-devel] [PATCH RFC v1 1/3] target-ppc: add TLB_NEED_LOCAL_FLUSH flag

On Fri, 2016-09-09 at 15:07 +0100, Alex Bennée wrote: > Nikunj A Dadhania writes: > > I think we need a little more detail here. In fact when you post the > next version of the series could you please include a cover letter to > cover what the series is trying to

Re: [Qemu-devel] [PATCH v2 3/3] target-ppc: tlbie should have global effect

On Fri, 2016-09-09 at 18:44 +0530, Nikunj A Dadhania wrote: > +static inline void tlb_clear_flag(CPUState *cs) > +{ > +    PowerPCCPU *cpu = POWERPC_CPU(cs); > +    CPUPPCState *env = >env; > + > +    env->tlb_need_flush = 0; > +} What is the point of making this a separate function ? Also I'm

Re: [Qemu-devel] [PATCH RFC v1 3/3] target-ppc: tlbie should have global effect

On Fri, 2016-09-09 at 16:15 +0530, Nikunj A Dadhania wrote: > > +env->tlb_need_flush = TLB_NEED_GLOBAL_FLUSH | TLB_NEED_LOCAL_FLUSH; > check_tlb_flush(env th, 1); > Hrm... how did that work bore ? IE. check_tlb_flush won't do anything if tlb_need_flush is 0, isn't it already set elsewhere ?

Re: [Qemu-devel] [PATCH RFC v1 2/3] target-ppc: add flag in chech_tlb_flush()

On Fri, 2016-09-09 at 16:15 +0530, Nikunj A Dadhania wrote: > The flag will be used to indicate whether broadcast tlb flush is > needed > or not. > > Signed-off-by: Nikunj A Dadhania > --- >  hw/ppc/spapr_hcall.c |  4 ++-- >  target-ppc/excp_helper.c |  4 ++-- >  

Re: [Qemu-devel] [PATCH RFC v1 1/3] target-ppc: add TLB_NEED_LOCAL_FLUSH flag

On Fri, 2016-09-09 at 16:15 +0530, Nikunj A Dadhania wrote: > > Signed-off-by: Nikunj A Dadhania > --- >  target-ppc/cpu.h | 1 + >  target-ppc/helper_regs.h | 2 +- >  target-ppc/mmu-hash64.c  | 4 ++-- >  target-ppc/mmu_helper.c  | 6 +++--- >  4 files changed, 7

Re: [Qemu-devel] [PATCH RFC] target-ppc: tlbie should have global effect

On Fri, 2016-09-09 at 10:38 +0530, Nikunj A Dadhania wrote: > One more question, when in gen_check_tlb_flush, don't I need to see > if other CPU has global flag set ? No, you leave it completely alone. You can clear it's local flag as part of the flush (in the MT-TCG case that can be done by the

Re: [Qemu-devel] [PATCH RFC] target-ppc: tlbie should have global effect

On Fri, 2016-09-09 at 15:00 +1000, Benjamin Herrenschmidt wrote: > > No it doesn't. > > When a "broadcast TLB" op happens, such as tlbie, you set both flags. > The existing one which just means the current CPU needs flushing, that > logic doesnt' change at a

Re: [Qemu-devel] [PATCH RFC] target-ppc: tlbie should have global effect

On Fri, 2016-09-09 at 10:15 +0530, Nikunj A Dadhania wrote: > > Benjamin Herrenschmidt <b...@kernel.crashing.org> writes: > > > > > On Fri, 2016-09-09 at 09:53 +0530, Nikunj A Dadhania wrote: > > > > > > tlbie (and H_REMOVE for pseries) should

Re: [Qemu-devel] [PATCH RFC] target-ppc: tlbie should have global effect

On Fri, 2016-09-09 at 09:53 +0530, Nikunj A Dadhania wrote: > tlbie (and H_REMOVE for pseries) should have a global effect. This is > achieved by iterating and setting tlb_need_flush in all the CPUs. > > Suggested-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> >

Re: [Qemu-devel] [PATCH v2 3/7] ppc/pnv: Add XSCOM infrastructure

On Wed, 2016-09-07 at 17:47 +0200, Cédric Le Goater wrote: >  > +static uint64_t pnv_lpc_xscom_mr_read(void *opaque, hwaddr addr, > unsigned size) > +{ > +XScomDevice *xd = XSCOM_DEVICE(opaque); > +uint64_t val = 0; > + > +pnv_lpc_xscom_read(xd, 0, xscom_to_pcb_addr(xd->chip_type, >

Re: [Qemu-devel] [PATCH v2 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

On Wed, 2016-09-07 at 14:13 +0200, Cédric Le Goater wrote: > On 09/07/2016 01:08 PM, Benjamin Herrenschmidt wrote: > > > > On Wed, 2016-09-07 at 12:50 +0200, Cédric Le Goater wrote: > > > > > > This is a bit broader than Ben's patch which used > > &

Re: [Qemu-devel] [PATCH v2 3/7] ppc/pnv: Add XSCOM infrastructure

On Wed, 2016-09-07 at 17:55 +0200, Cédric Le Goater wrote: > > yes. To hack my way through again, I have added a memory region under > the XScomDevice, but we should have a list like the ranges[] because of  > the PHB3 PCBQs. You have the parent region in the chip. Then each device can create

Re: [Qemu-devel] [PATCH v2 01/10] ppc: Fix rfi/rfid/hrfi/... emulation

On Wed, 2016-09-07 at 12:50 +0200, Cédric Le Goater wrote: > This is a bit broader than Ben's patch which used PPC_SEGMENT_64B.  > it's basically !PPC_64B which includes the e5500. > > If so, here is a proposal below adding a new PPC_RFI in the  > "PowerPC Instructions types definitions" enum for

Re: [Qemu-devel] [PATCH v2 3/7] ppc/pnv: Add XSCOM infrastructure

On Wed, 2016-09-07 at 15:46 +1000, David Gibson wrote: > Right, that's probably better.  Not immediately sure how the > scomdevice would get hold of its chip's scom AS, but we can probably > figure out something. Passed at instanciation ? Cheers, Ben.

Re: [Qemu-devel] [PATCH v2 3/7] ppc/pnv: Add XSCOM infrastructure

On Wed, 2016-09-07 at 11:59 +1000, David Gibson wrote: > > That does suggest an alternative approach though.  You could remove > XScomDevice entirely from QOM existence, and just expose the xscom > address space globally, much like address_space_memory.  The > individual devices could just

Re: [Qemu-devel] [PATCH RFC 3/4] target-ppc: use atomic_cmpxchg for ld/st reservation

On Wed, 2016-09-07 at 10:17 +0530, Nikunj A Dadhania wrote: > > David Gibson writes: > > > > > [ Unknown signature status ] > > On Fri, Sep 02, 2016 at 12:02:55PM +0530, Nikunj A Dadhania wrote: > > > > > > > > > Signed-off-by: Nikunj A Dadhania

Re: [Qemu-devel] [PULL 00/66] ppc-for-2.8 queue 20160906

On Wed, 2016-09-07 at 07:52 +1000, Benjamin Herrenschmidt wrote: > On Tue, 2016-09-06 at 23:09 +0200, Thomas Huth wrote: > > > > The bad commit is: "ppc: Speed up load/store multiple" > > > > There are two "#if defined(HOST_WORDS_BIGENDIAN)" se

Re: [Qemu-devel] [PULL 00/66] ppc-for-2.8 queue 20160906

On Tue, 2016-09-06 at 23:09 +0200, Thomas Huth wrote: > The bad commit is: "ppc: Speed up load/store multiple" > > There are two "#if defined(HOST_WORDS_BIGENDIAN)" sections in this patch > which are both bad: The memcpy tries to copy 32-bit values into 64-bit > registers, which of course does

Re: [Qemu-devel] [PATCH v2 3/7] ppc/pnv: Add XSCOM infrastructure

On Wed, 2016-09-07 at 07:47 +1000, Benjamin Herrenschmidt wrote: > d be an extra op in the xscom device model I guess.  > > No. If you split the XSCOM bus from the MMIO -> XSCOM bridge (the > ADU) > then the conversion only happens in the former. You don't directly > route

Re: [Qemu-devel] [PATCH v2 3/7] ppc/pnv: Add XSCOM infrastructure

On Tue, 2016-09-06 at 16:42 +0200, Cédric Le Goater wrote: > > Alternatively.. it might be simpler to just drop the SCOM as a > > separate device.  I think you could just hang the scom bus directly > > off the chip object.  IIUC the scom is basically the only chip- > level > > control mechanism,

Re: [Qemu-devel] [PATCH v2 3/7] ppc/pnv: Add XSCOM infrastructure

On Tue, 2016-09-06 at 16:42 +0200, Cédric Le Goater wrote: > > The change does seem too invasive. I can give it a try in next > version. > > When a memory region is triggered, the impacted device will have > to convert the address with xscom_to_pcb_addr(). There is some  > dependency on the chip

Re: [Qemu-devel] [PATCH RFC 4/4] target-ppc: flush tlb from all the cpu

On Tue, 2016-09-06 at 10:23 +0530, Nikunj A Dadhania wrote: > > > > No there isn't. You can start qemu with --smp 4 and have 4 CPUs. > > That case was prevented to even start in case of TCG. That is why I had > to add "target-ppc: with MTTCG report more threads" No, it works, you are confusing

Re: [Qemu-devel] [PATCH RFC 4/4] target-ppc: flush tlb from all the cpu

On Tue, 2016-09-06 at 07:25 +0530, Nikunj A Dadhania wrote: > > Benjamin Herrenschmidt <b...@kernel.crashing.org> writes: > > > > > On Sun, 2016-09-04 at 18:00 +0100, Alex Bennée wrote: > > > > > > > > When is the synchronisation p

Re: [Qemu-devel] [PATCH v2 4/7] ppc/pnv: add a core mask to PnvChip

On Mon, 2016-09-05 at 13:13 +0200, Cédric Le Goater wrote: > > Is it worth having this cores_max field, since AFAICT you can > > calculate it as hweight(~cores_mask)? > > Sure. I looked for it and missed it.  > > Here is a slightly improved version from Brian Kernighan : > > unsigned

Re: [Qemu-devel] [PATCH v2 2/7] ppc/pnv: add a PnvChip object

On Mon, 2016-09-05 at 09:41 +0200, Cédric Le Goater wrote: > yeah. I have not found a clear definition of all the bits. > > I will try to make a macro with what I can collect from the  > specs and the code. It's the CFAM stuff, there's some doco internally but nothing releasable publicly...

Re: [Qemu-devel] [PATCH v2 3/7] ppc/pnv: Add XSCOM infrastructure

On Mon, 2016-09-05 at 13:39 +1000, David Gibson wrote: > > +static XScomDevice *xscom_find_target(XScomState *s, uint32_t > pcb_addr, > > +  uint32_t *range) > > +{ > > +    BusChild *bc; > > + > > +    QTAILQ_FOREACH(bc, >bus->bus.children, sibling) { > > + 

Re: [Qemu-devel] [PATCH v2 2/7] ppc/pnv: add a PnvChip object

On Mon, 2016-09-05 at 12:58 +1000, David Gibson wrote: > > With the new chip class per cpu class, does this chip_type field > serve > any purpose any more? > > > +    k->chip_f000f = 0x120d30498000ull; > > A comment somewhere explaining what this cryptic value is would be > nice. It's

Re: [Qemu-devel] [PATCH RFC 4/4] target-ppc: flush tlb from all the cpu

On Sun, 2016-09-04 at 18:00 +0100, Alex Bennée wrote: > When is the synchronisation point? On ARM we end the basic block on > system instructions that mess with the cache. As a result the flush > is done as soon as we exit the run loop on the next instruction. Talking o this... Nikunj, I notice,

Re: [Qemu-devel] [PATCH RFC 4/4] target-ppc: flush tlb from all the cpu

On Sun, 2016-09-04 at 18:00 +0100, Alex Bennée wrote: > > > > > We must provide a guarantee that no other processor can see the old > > > translation when the tlb invalidation sequence completes. With the > > > current lazy TLB flush, we already delay the invalidation until > > > we hit that

Re: [Qemu-devel] [PATCH RFC 0/4] Enable MTTCG on PowerPC

On Fri, 2016-09-02 at 13:09 +0530, Nikunj A Dadhania wrote: > Benjamin Herrenschmidt <b...@kernel.crashing.org> writes: > > > > > On Fri, 2016-09-02 at 12:02 +0530, Nikunj A Dadhania wrote: > > > > > > The series is a first attempt at enabling Multi-Th

Re: [Qemu-devel] [PATCH RFC 4/4] target-ppc: flush tlb from all the cpu

On Fri, 2016-09-02 at 12:02 +0530, Nikunj A Dadhania wrote: > Signed-off-by: Nikunj A Dadhania > --- >  cputlb.c| 15 +++ >  include/exec/exec-all.h |  2 ++ >  target-ppc/mmu-hash64.c |  2 +- >  3 files changed, 18 insertions(+), 1 deletion(-)

Re: [Qemu-devel] [PATCH RFC 0/4] Enable MTTCG on PowerPC

On Fri, 2016-09-02 at 12:02 +0530, Nikunj A Dadhania wrote: > The series is a first attempt at enabling Multi-Threaded TCG on PowerPC. > Changes that were needed to enable PowerPC are pretty simple; > > Patch 01: Take a iothread lock during hcall, as hcall can generate io requests >   02: For

Re: [Qemu-devel] [Qemu-ppc] [PATCH v2 1/7] ppc/pnv: add skeleton PowerNV platform

On Fri, 2016-09-02 at 08:32 +0200, Cédric Le Goater wrote: > > This file is a new contribution to QEMU. According to the LICENSE > file, it should > > be released under GPL version 2 or later. If Ben agrees, probably > better to have > > the same text as in include/hw/ppc/pnv.h below. > > Yes.

Re: [Qemu-devel] [PATCH 3/3] ppc/pnv: add a PowerNVCPUCore object

On Tue, 2016-08-30 at 02:28 -0400, David Gibson wrote: > No.. the PIR itself is a cpu level construct (and we already have a > place for that in the cpu state).  The DT id as such isn't, although > it happens to have the same value.  The fact it has the same value is > itself a machine type

Re: [Qemu-devel] [PATCH 3/3] ppc/pnv: add a PowerNVCPUCore object

On Mon, 2016-08-29 at 10:30 -0400, David Gibson wrote: > > Possibly.  In fact, I'm planning to eliminate cpu->cpu_dt_id at some > point, in favour of having the machine type construct the id when it > actually builds the dt.  It's not really a cpu level construct. On PowerNV it is as it's equal

<    1   2   3   4   5   6   7   8   9   10   >