the appropriate device tree bits
to advertise the presence of the hwrng to the guest kernel.
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
hw/ppc/spapr.c| 16
include/hw/ppc/spapr.h| 1 +
linux-headers/linux/kvm.h | 1 +
target-ppc/kvm.c | 5
On Thu, 2013-09-26 at 13:06 +0200, Alexander Graf wrote:
On 26.09.2013, at 08:37, Michael Ellerman wrote:
Some powerpc systems have support for a hardware random number generator
(hwrng). If such a hwrng is present the host kernel can provide access
to it via the H_RANDOM hcall
On Wed, 2013-06-19 at 15:40 -0500, Anthony Liguori wrote:
If you are on CC, then please Ack this patch as you touched this
file at some point in time.
Barely, but yes.
Acked-by: Michael Ellerman mich...@ellerman.id.au
cheers
diff --git a/hw/char/spapr_vty.c b/hw/char/spapr_vty.c
index
Hi all,
As the subject says, this is an RFC.
I have a few patches (to follow), that change the help output from QEMU
so that we only display options that are accepted by the arch of the
running binary.
So for example qemu-system-ppc64 will not tell you about i386 options
like -no-acpi, -no-hpet
Make it possible to specify what architecture a heading in the help
doco applies to.
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
A possibly nicer way to do this would be to add a new macro, perhaps
ARCHHEADING, that is used for architecture specific headings. That
would make
Only print options in the help output that are accepted by our arch.
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
vl.c | 31 +--
1 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/vl.c b/vl.c
index b492f8c..ba8e76d 100644
--- a/vl.c
+++ b
may as well just put
that in the format string.
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
vl.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/vl.c b/vl.c
index 6a2ca6f..b492f8c 100644
--- a/vl.c
+++ b/vl.c
@@ -1502,7 +1502,7 @@ static void help(int
On Mon, 2011-12-12 at 14:19 -0600, Anthony Liguori wrote:
This was doing something evil building a dt tree so we broke the device.
@@ -711,8 +711,12 @@ VIOsPAPRBus *spapr_vio_bus_init(void)
spapr_rtas_register(ibm,set-tce-bypass, rtas_set_tce_bypass);
spapr_rtas_register(quiesce,
On Mon, 2011-12-12 at 20:10 -0600, Anthony Liguori wrote:
On 12/12/2011 08:04 PM, Michael Ellerman wrote:
On Mon, 2011-12-12 at 14:19 -0600, Anthony Liguori wrote:
This was doing something evil building a dt tree so we broke the device.
@@ -711,8 +711,12 @@ VIOsPAPRBus *spapr_vio_bus_init
On Thu, 2011-12-15 at 17:08 +1100, David Gibson wrote:
This patch adds code to the code for the powernv platform to create
and populate isolation groups on hardware using the p7ioc (aka IODA) PCI host
bridge used on some IBM POWER systems.
diff --git
It's a little unfriendly to call abort() without printing any sort of
error message. So turn the DPRINTK() into an fprintf(stderr, ...).
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
kvm-all.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/kvm-all.c b/kvm
On Mon, 2011-12-19 at 17:19 +1100, y...@ozlabs.org wrote:
From: Michael Ellerman mich...@ellerman.id.au
These are from me obviously. Thankyou POS git-send-email.
cheers
signature.asc
Description: This is a digitally signed message part
On Mon, 2012-02-06 at 13:46 -0600, Scott Wood wrote:
On 02/03/2012 04:52 PM, Anthony Liguori wrote:
On 02/03/2012 12:07 PM, Eric Northup wrote:
On Thu, Feb 2, 2012 at 8:09 AM, Avi Kivitya...@redhat.com wrote:
[...]
Moving to syscalls avoids these problems, but introduces new ones:
On Wed, 2012-02-15 at 22:21 +, Arnd Bergmann wrote:
On Tuesday 07 February 2012, Alexander Graf wrote:
On 07.02.2012, at 07:58, Michael Ellerman wrote:
On Mon, 2012-02-06 at 13:46 -0600, Scott Wood wrote:
You're exposing a large, complex kernel subsystem that does very
low-level
On Thu, 2012-02-16 at 21:28 +0200, Avi Kivity wrote:
On 02/16/2012 03:04 AM, Michael Ellerman wrote:
ioctl is good for hardware devices and stuff that you want to enumerate
and/or control permissions on. For something like KVM that is really a
core kernel service, a syscall makes
are incorrect.
As far as I can tell this does not matter in practice because s390 does
not define a kvm_exit trace point.
While we're there, fix the whitespace to match the rest of the file.
Signed-off-by: Michael Ellerman m...@ellerman.id.au
---
scripts/kvm/kvm_stat | 49
.
We'd also like to add another platform, powerpc, which will just make it
worse. So clean it up in preparation.
Signed-off-by: Michael Ellerman m...@ellerman.id.au
---
scripts/kvm/kvm_stat | 44 +---
1 file changed, 29 insertions(+), 15 deletions(-)
diff --git
Add support for powerpc platforms. We use uname -m, which allows us to
detect ppc, ppc64 and ppc64le/el.
Signed-off-by: Michael Ellerman m...@ellerman.id.au
---
scripts/kvm/kvm_stat | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/scripts/kvm/kvm_stat b
, the online file will not be
present at all.
Signed-off-by: Michael Ellerman m...@ellerman.id.au
---
scripts/kvm/kvm_stat | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/scripts/kvm/kvm_stat b/scripts/kvm/kvm_stat
index d7e97e7..2a788bc 100755
--- a/scripts
Unfortunately ioctl numbers are platform specific, so abstract them out
of the code so they can be overridden. As it happens x86 and s390 share
the same values, so nothing needs to change yet.
Signed-off-by: Michael Ellerman m...@ellerman.id.au
---
scripts/kvm/kvm_stat | 12 +---
1 file
is
'reason'.
So invert the way we setup filters, define it by default for the generic
tracepoint 'kvm_userspace_exit', and let x86 override it. Doing it this
way will also work for powerpc when we add it.
Signed-off-by: Michael Ellerman m...@ellerman.id.au
---
scripts/kvm/kvm_stat | 14
On Tue, 2014-06-17 at 10:27 +0200, Alexander Graf wrote:
On 17.06.14 09:54, Michael Ellerman wrote:
Add support for powerpc platforms. We use uname -m, which allows us to
detect ppc, ppc64 and ppc64le/el.
Signed-off-by: Michael Ellerman m...@ellerman.id.au
Could you please add support
On Wed, 2014-06-18 at 02:59 +0200, Alexander Graf wrote:
On 18.06.14 02:50, Michael Ellerman wrote:
On Tue, 2014-06-17 at 10:27 +0200, Alexander Graf wrote:
On 17.06.14 09:54, Michael Ellerman wrote:
Add support for powerpc platforms. We use uname -m, which allows us to
detect ppc, ppc64
On Tue, 2015-09-08 at 12:09 +0530, Bharata B Rao wrote:
> On Tue, Sep 08, 2015 at 04:08:06PM +1000, Michael Ellerman wrote:
> > On Wed, 2015-08-12 at 10:53 +0530, Bharata B Rao wrote:
> > > On Tue, Aug 11, 2015 at 03:48:26PM +0200, Andrea Arcangeli wrote:
>
On Wed, 2015-08-12 at 10:53 +0530, Bharata B Rao wrote:
> On Tue, Aug 11, 2015 at 03:48:26PM +0200, Andrea Arcangeli wrote:
> > Hello Bharata,
> >
> > On Tue, Aug 11, 2015 at 03:37:29PM +0530, Bharata B Rao wrote:
> > > May be it is a bit late to bring this up, but I needed the following fix
> >
On Tue, 2015-09-08 at 17:14 +1000, Michael Ellerman wrote:
> On Tue, 2015-09-08 at 12:09 +0530, Bharata B Rao wrote:
> > On Tue, Sep 08, 2015 at 04:08:06PM +1000, Michael Ellerman wrote:
> > > Hmm, not for me. See below.
> > >
> > > What setup were you testing
On Wed, 2015-09-02 at 17:48 +1000, David Gibson wrote:
> On Wed, Sep 02, 2015 at 11:04:12AM +0530, Amit Shah wrote:
> > On (Mon) 31 Aug 2015 [20:46:02], Thomas Huth wrote:
> > > The PAPR interface provides a hypercall to pass high-quality
> > > hardware generated random numbers to guests. So let's
On 5 April 2016 7:56:23 pm AEST, Benjamin Herrenschmidt
<b...@kernel.crashing.org> wrote:
>On Tue, 2016-04-05 at 19:35 +1000, Michael Ellerman wrote:
>> Shouldn't we be clearing the user feature there too?
>>
>> The ibm_pa_features array and the logic in scan_
On Mon, 2016-04-04 at 11:11:12 UTC, Paul Mackerras via Linuxppc-dev wrote:
> In check_cpu_pa_features() we check a number of bits in the
Shouldn't we be clearing the user feature there too?
The ibm_pa_features array and the logic in scan_features() knows to flip the
cpu_user_features bits, it
On Fri, 2016-15-04 at 02:06:13 UTC, Unknown sender due to SPF wrote:
> The real LE feature entry in the ibm_pa_feature struct has the
> wrong number of elements. Instead of checking for byte 5, bit 0,
> we check for byte 0, bit 0, and we also incorrectly update cpu user
> feature bit 5.
>
> Fixes:
Cc: sta...@vger.kernel.org
[mpe: Flesh out changelog, add comment reserving 0x4]
Signed-off-by: Michael Ellerman <m...@ellerman.id.au>
---
arch/powerpc/include/uapi/asm/cputable.h | 1 +
arch/powerpc/kernel/prom.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/
On Fri, 2016-15-04 at 02:08:19 UTC, Unknown sender due to SPF wrote:
> We need to update the user TM feature bits (PPC_FEATURE2_HTM and
> PPC_FEATURE2_HTM) to mirror what we do with the kernel TM feature
> bit.
>
> At the moment, if firmware reports TM is not available we turn off
> the kernel TM
On Mon, 2016-18-04 at 10:36:07 UTC, Michael Ellerman wrote:
> From: Anton Blanchard <an...@samba.org>
>
> The REAL_LE feature entry in the ibm_pa_feature struct is missing an MMU
> feature value, meaning all the remaining elements initialise the wrong
> values.
...
>
On Fri, 2016-15-04 at 02:07:24 UTC, Unknown sender due to SPF wrote:
> scan_features() updates cpu_user_features but not cpu_user_features2.
>
> Amongst other things, cpu_user_features2 contains the user TM feature
> bits which we must keep in sync with the kernel TM feature bit.
>
>
On Sat, 2016-04-16 at 00:27 +1000, Michael Ellerman wrote:
> On Fri, 2016-15-04 at 02:06:13 UTC, Unknown sender due to SPF wrote:
> > The real LE feature entry in the ibm_pa_feature struct has the
> > wrong number of elements. Instead of checking for byte 5, bit 0,
> > we ch
On Fri, 2016-15-04 at 02:06:13 UTC, Unknown sender due to SPF wrote:
> The real LE feature entry in the ibm_pa_feature struct has the
> wrong number of elements. Instead of checking for byte 5, bit 0,
> we check for byte 0, bit 0, and we also incorrectly update cpu user
> feature bit 5.
>
> diff
Sam Bobroff <sam.bobr...@au1.ibm.com> writes:
> On Fri, Jul 08, 2016 at 08:49:49PM +1000, Michael Ellerman wrote:
>> On Wed, 2016-06-07 at 06:05:54 UTC, Sam bobroff wrote:
>> > diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
>> > index 02416f
Paolo Bonzini <pbonz...@redhat.com> writes:
> On 20/07/2016 07:46, Michael Ellerman wrote:
>> Thanks.
>>
>> Acked-by: Michael Ellerman <m...@ellerman.id.au>
>>
>> Or do you want me to merge this before Paul gets back?
>
> No, this should
s will be used by QEMU to populate the pa-features bits in the
> guest's device tree.
>
> Signed-off-by: Sam Bobroff <sam.bobr...@au1.ibm.com>
> ---
>
> v2:
>
> * Use CPU_FTR_TM_COMP instead of CPU_FTR_TM.
Thanks.
Acked-by: Michael Ellerman <m...@ellerman.id
On Wed, 2016-06-07 at 06:05:54 UTC, Sam bobroff wrote:
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 02416fe..06d79bc 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -588,6 +588,10 @@ int kvm_vm_ioctl_check_extension(struct kvm
Cédric Le Goater <c...@kaod.org> writes:
>>>> According to https://patchwork.ozlabs.org/patch/776052/
>>>>
>>>> POWER9 DD2's PVR is expected to be 0x004e1200
>>
>> Uh.. I spoke to Michael Ellerman, and he said he expected 0x004e0200.
>>
David Gibson writes:
> For POWER9 DD2.2 cpus, the best current Spectre v2 indirect branch
> mitigation is "count cache disabled", which is configured with:
> -machine cap-ibs=fixed-ccd
> However, this option isn't available on DD2.3 CPUs with KVM, because they
> don't have the count cache
David Gibson writes:
> On Mon, Mar 29, 2021 at 03:32:37PM -0300, Daniel Henrique Barboza wrote:
...
>
>> We assign ibm,chip-id=0x0 to CPUs 0-3, but CPUs 2-3 are located in a
>> different NUMA node than 0-1. This would mean that the same socket
>> would belong to different NUMA nodes at the same
rom 1902 developers
>
> The following fixes try and alleviate that although I still get a
> warning for Aaron which I think is from 9743cd5736.
>
> Signed-off-by: Alex Bennée
> Reviewed-by: Philippe Mathieu-Daudé
> Acked-by: Aaron Larson
> Cc: Andreas Färber
> Cc: Jason Wan
rom 1902 developers
>
> The following fixes try and alleviate that although I still get a
> warning for Aaron which I think is from 9743cd5736.
>
> Signed-off-by: Alex Bennée
> Cc: Aaron Larson
> Cc: Andreas Färber
> Cc: Jason Wang
> Cc: Michael Ellerman
> Cc: Peter Chu
45 matches
Mail list logo
