> So, it appears that this is not the case for many platforms: bridge
> itself does a byteswap to make devices behind it work according to spec,
> but this does not apply to programming bridge itself.
>
> This seems common on BE platforms, this is why qemu has
> ifdef TARGET_WORDS_BIGENDIAN there
On Mon, 2010-01-04 at 23:12 +0200, Michael S. Tsirkin wrote:
> Well, the main issue if I understand correcttly is that basically the
> same hardware bridge can be connected to host in different ways. Yes, we
> can say "if it's connected differently it's a different device" but this
> is slightly ug
On Tue, 2010-01-05 at 00:08 +0100, Alexander Graf wrote:
>
> IIRC qemu's mmio functions just pass the register value the guest had
> at that moment to the mmio function.
That means that qemu HW emulation needs, for each device, to add a layer
of byteswap depending on whether the CPU is LE or BE w
> Yes, but I think how you program your host to pci bridge is platform specific,
> the standard (mostly) applies to what happens below the bridge. There's
> no real standard for how PCI host bridge is connected to processor
> AFAIK, it's by luck we can share code there at all.
Well, yes and no .
On Tue, 2010-01-05 at 00:25 +0200, Michael S. Tsirkin wrote:
> On Tue, Jan 05, 2010 at 08:53:52AM +1100, Benjamin Herrenschmidt wrote:
> >
> > > Yes, but I think how you program your host to pci bridge is platform
> > > specific,
> > > the standard (mostl
Thats why i just call it sue
Joe Lee wrote:
To me no matter how you pronounce it, It's not a pronounce friendly
type name - IMO.
Joe
Ed Swierk wrote:
On 6/28/06, Paul Robinson <[EMAIL PROTECTED]> wrote:
How should you pronounce Qemu?
FYI, my best guess is Q (as in the letter Q) followe
> OK, I did put this in my working repository and I'll submit this to
> Fabrice.
> Please try to do this change to check if other bits need to be relax or
> not:
>
> Index: target-ppc/translate.c
> ===
> RCS file: /cvsroot/qemu/qemu/
> console=ttyS0 console=tty0
> Note that the Open-Firmware frame-buffer support is broken in many 2.6
> kernels (I mean on real Macs)
How so ?
> and that most distributions install CDROM
> don't have support for PC serial ports. Then, to be able to have video
> console with any 2.6 based distri
On Mon, 2005-05-23 at 12:47 +0200, J. Mayer wrote:
> On Mon, 2005-05-23 at 10:31 +1000, Benjamin Herrenschmidt wrote:
> > > console=ttyS0 console=tty0
> > > Note that the Open-Firmware frame-buffer support is broken in many 2.6
> > > kernels (I mean on real Macs
> Right, is this set according to some OF properties (which could be a
> cause of the bug) ?
> I didn't find anything like this in OF fb code, but I may have missed
> it
prom_init() sets it using calls to OF fb driver setcolreg method.
Ben.
_
The DEXCR emulation was recently changed to a 32-bit register, possibly
because it does have a 32-bit read-only view. It is a full 64-bit
SPR though, so use the corresponding 64-bit write functions.
Fixes: c9de140c2171 ("target/ppc: Fix width of some 32-bit SPRs")
Signed-off-by: Ben
then return
early if the XML is cached. Otherwise we generate the XML using the
now already initialised gdb_id values.
Fixes: 1b53948ff8f7 ("target/ppc: Use GDBFeature for dynamic XML")
Signed-off-by: Benjamin Gray
---
target/ppc/gdbstub.c | 31 ---
1 f
On Wed, 2024-03-20 at 14:31 +1000, Nicholas Piggin wrote:
> On Wed Mar 20, 2024 at 11:50 AM AEST, Benjamin Gray wrote:
> > The DEXCR emulation was recently changed to a 32-bit register,
> > possibly
> > because it does have a 32-bit read-only view. It is a full 64-bit
>
Hi QEMU,
I am trying to use the -O function to convert a file format to vmdk, but
get the below response. Please could you help?
Bens-iMac:~ ben$ qemu-img -O output_fmt vmdk
/Users/ben/Documents/Windows11_InsiderPreview_Client_ARM64_en-us_22598.VHDX
~/Desktop/Install/Windows11ARM.vmdk
qemu-img:
Sorry, my email service mangled the link I ment to send. It should be:https://github.com/odinssecrets/qemu_gdbstub_multithread_testingOn May 28, 2022 3:53 PM, Ben Cohen wrote:I was testing some multi-threaded code in qemu's usermode and ran into
issues with the gdbstub because the user mode qemu
fails is broken.
So implement the call and claim we have exactly one display
Signed-off-by: Benjamin Herrenschmidt
---
hw/misc/bcm2835_property.c | 4
1 file changed, 4 insertions(+)
diff --git a/hw/misc/bcm2835_property.c b/hw/misc/bcm2835_property.c
index 73941bdae9..b958fa6a5c 100644
Without these the RaspiOS kernel tries to ioremap some bogus address
and dumps a backtrace in the console at boot. These work around it.
The virt-gpio driver still fails to initialize but much more cleanly
Signed-off-by: Benjamin Herrenschmidt
---
hw/misc/bcm2835_property.c | 7 +++
1 file
On Sun, 2021-10-17 at 17:08 +0200, Philippe Mathieu-Daudé wrote:
> Hi Benjamin,
>
> On 10/17/21 09:48, Benjamin Herrenschmidt wrote:
> > The framebuffer driver fails to initialize with recent Raspberry Pi
> > kernels, such as the ones shipped in the current RaspiOS images
On Mon, 2021-10-18 at 11:47 +0200, Philippe Mathieu-Daudé wrote:
>
> > I've just checked the rpi-5.15.y branch and it's the same.
>
> Indeed. I stopped testing recent kernels because they use too many
> features QEMU don't implement.
>
> Our model should generate the DTB blob of devices implemen
On Thu, 2022-03-31 at 18:51 +0100, Peter Maydell wrote:
>
> Hi; Coverity has just spotted an error in this old change
> (CID 1487176):
Oh my this is old ... I don't work for IBM anymore but I found the
relevant doc here:
https://wiki.raptorcs.com/w/images/a/a5/POWER9_PCIe_controller_v11_27JUL201
;t do anything), so declare this in the device tree.
Signed-off-by: Benjamin Gray
---
The current design appears to duplicate the previous block and add the
new features after it. I copied that for the 3.10 features, but not sure
how well this scales, so alternatives welcome.
---
hw/ppc/spapr.c
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 cpu-vers
On Fri, 2016-08-26 at 16:47 +0200, Cédric Le Goater wrote:
> >> +static void powernv_machine_class_init(ObjectClass *oc, void
> *data)
> >> +{
> >> + MachineClass *mc = MACHINE_CLASS(oc);
> >> +
> >> + mc->init = ppc_powernv_init;
> >> + mc->reset = ppc_powernv_reset;
> >> + mc->block_d
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 t
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 propert
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. The
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
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(-)
>
> diff --git a/cputlb.c
On Fri, 2016-09-02 at 13:09 +0530, Nikunj A Dadhania wrote:
> Benjamin Herrenschmidt writes:
>
> >
> > 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
> > > Powe
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 synch
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,
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 snaps
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, &s->bus->bus.children, sibling) {
> > +
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...
Chee
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 int
On Tue, 2016-09-06 at 07:25 +0530, Nikunj A Dadhania wrote:
> > Benjamin Herrenschmidt writes:
>
> >
> > 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
>
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 co
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
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, so
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
>
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 not
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)" section
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
> >
> > This really needs a comment indicating
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 registe
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.
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
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 and
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
> &
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,
> add
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
> Signed-off-by: Nikunj A Dadhania
&g
On Fri, 2016-09-09 at 10:15 +0530, Nikunj A Dadhania wrote:
> > Benjamin Herrenschmidt writes:
>
> >
> > 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
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
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
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 insertions(+), 6 deletions(-
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 ++--
> target-ppc/helper.h | 2
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 ?
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 = &cpu->env;
> +
> + env->tlb_need_flush = 0;
> +}
What is the point of making this a separate function ?
Also I
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 achieve?
In the meantime, for th
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)
> * tlb
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 defined(CO
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 pull
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 virtual
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 ca
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 and
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
> >
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 a
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
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.
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 f
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 spac
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.
Cheer
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.
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 ha
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
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 command-li
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 command-lin
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
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 handling in PowerPC.
> > > Inst
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;
> +
> + #def
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;
> > +
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 workin
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 do
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
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 be
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 device-nod
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 depend
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,
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 a
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.
Ie
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
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 MAINTAINER
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
---
include/exec/cpu_ldst.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
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
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 w
d-off-by: Vladimir Svoboda
Acked-by: Benjamin Herrenschmidt
> ---
> target-ppc/helper_regs.h | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/target-ppc/helper_regs.h b/target-ppc/helper_regs.h
> index bb9ce60..6213816 100644
> --- a/targ
Public bug reported:
Git pseudo-bisected (focused on optionrom commits) it to this commit.
commit cdbd727c20ad7aac7797dc8c95e485e1a4c6901b
Author: Richard Henderson
Date: Thu Jul 7 21:49:36 2016 -0700
build: Use $(AS) for optionrom explicitly
Build output (non-verbose):
ASoptionr
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 u
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
> > - */
> > + s
On Fri, 2016-10-21 at 15:18 +0100, Mark Cave-Ayland wrote:
>
> bd6fefe71cec5a0c7d2be4ac96307f25db56abf9 is the first bad commit
> commit bd6fefe71cec5a0c7d2be4ac96307f25db56abf9
> Author: Benjamin Herrenschmidt
> Date: Wed Jul 27 16:56:32 2016 +1000
>
> ppc: Ma
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 fix
901 - 1000 of 1366 matches
Mail list logo
