qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-ppc] Determining interest in PPC e500spin, yield,


From: Mark Cave-Ayland
Subject: Re: [Qemu-devel] [Qemu-ppc] Determining interest in PPC e500spin, yield, and openpic patches
Date: Tue, 14 Jun 2016 20:09:47 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.8.0

On 14/06/16 00:08, address@hidden wrote:

> We've used older versions of QEMU for several years as a virtual
> target for our OS.  Many thanks to the community for providing this
> platform.
> 
> We've been working to get our OS running under QEMU 2.x and have
> identified a few bugs in QEMU, have made some enhancements, and are
> still tracking down some other curious behaviors.  I'm looking for
> some guidance as to how, and whether, you'd like patches for the
> following.
> 
> 1. There is a defect in ppce500_spin.c:spin_kick() that creates an
>    incorrectly sized TLB entry.  This was reported as bug
>    https://bugs.launchpad.net/qemu/+bug/1587535  I can provide a
>    patch if desired.
> 
> 2. We have implemented the PPC "yield" instruction.  I can provide a
>    patch if desired.
> 
> 3. We're working on support for openpic timers.  We're not finished,
>    but it would be helpful to know if a patch is desired or if we
>    should expect to maintain the changes independently.
> 
> 4. We're currently tracking down why in our e500 (both unicore and
>    multi-core) PPC QEMU 2.5 guest (x86 host), that with interrupts
>    disabled, after enabling the decrementer and issuing a "wait"
>    instruction QEMU continues to "busy loop", consuming an entire host
>    CPU doing apparently nothing.  As expected, issuing a "wait" prior
>    to enabling the decrementer leaves the host process idle.  We found
>    the bug in the PPC "wait" instruction implementation that was
>    independently reported and resolved last week, but that did not fix
>    the problem.  We also have our OS running on the g3beige and using
>    MSR.POW which causes the host to "sleep", but we are having no joy
>    with e500 and "wait".  Any pointers would be appreciated.  When we
>    find something we'll report back.

If you are able to submit patches with a valid Signed-off-by then it
would be good to see all your patches; at the very least there are some
people with some very deep knowledge of PPC CPUs around so even if the
patch is not accepted in its current form, it can be reworked into
something that can.

Don't forget to check your patches with scripts/checkpatch.pl and to
explicitly CC the correct MAINTAINERS as given by
scripts/get_maintainer.pl for submission.


ATB,

Mark.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]