Ping?
On 24.03.2015 12:43, Bogdan Purcareata wrote:
After previous discussions regarding the subject [1][2], there's no clear
explanation or reason why the call was needed in the first place. The sensible
argument is some sort of synchronization between the CPU and the MPIC, which
hasn't been
On 24.04.2015 00:26, Scott Wood wrote:
On Thu, 2015-04-23 at 15:31 +0300, Purcareata Bogdan wrote:
On 23.04.2015 03:30, Scott Wood wrote:
On Wed, 2015-04-22 at 15:06 +0300, Purcareata Bogdan wrote:
On 21.04.2015 03:52, Scott Wood wrote:
On Mon, 2015-04-20 at 13:53 +0300, Purcareata Bogdan
On 23.04.2015 03:30, Scott Wood wrote:
On Wed, 2015-04-22 at 15:06 +0300, Purcareata Bogdan wrote:
On 21.04.2015 03:52, Scott Wood wrote:
On Mon, 2015-04-20 at 13:53 +0300, Purcareata Bogdan wrote:
There was a weird situation for .kvmppc_mpic_set_epr - its corresponding inner
function
On 21.04.2015 03:52, Scott Wood wrote:
On Mon, 2015-04-20 at 13:53 +0300, Purcareata Bogdan wrote:
There was a weird situation for .kvmppc_mpic_set_epr - its corresponding inner
function is kvmppc_set_epr, which is a static inline. Removing the static inline
yields a compiler crash
On 10.04.2015 02:53, Scott Wood wrote:
On Thu, 2015-04-09 at 10:44 +0300, Purcareata Bogdan wrote:
So at this point I was getting kinda frustrated so I decided to measure
the time spend in kvm_mpic_write and kvm_mpic_read. I assumed these were
the main entry points in the in-kernel MPIC
On 04.04.2015 00:26, Scott Wood wrote:
On Fri, 2015-04-03 at 11:07 +0300, Purcareata Bogdan wrote:
On 03.04.2015 02:11, Scott Wood wrote:
On Fri, 2015-03-27 at 19:07 +0200, Purcareata Bogdan wrote:
On 27.02.2015 03:05, Scott Wood wrote:
On Thu, 2015-02-26 at 14:31 +0100, Sebastian Andrzej
On 03.04.2015 02:11, Scott Wood wrote:
On Fri, 2015-03-27 at 19:07 +0200, Purcareata Bogdan wrote:
On 27.02.2015 03:05, Scott Wood wrote:
On Thu, 2015-02-26 at 14:31 +0100, Sebastian Andrzej Siewior wrote:
On 02/26/2015 02:02 PM, Paolo Bonzini wrote:
On 24/02/2015 00:27, Scott Wood wrote
On 27.02.2015 03:05, Scott Wood wrote:
On Thu, 2015-02-26 at 14:31 +0100, Sebastian Andrzej Siewior wrote:
On 02/26/2015 02:02 PM, Paolo Bonzini wrote:
On 24/02/2015 00:27, Scott Wood wrote:
This isn't a host PIC driver. It's guest PIC emulation, some of which
is indeed not suitable for a
On 27.02.2015 22:54, Benjamin Herrenschmidt wrote:
On Fri, 2015-02-27 at 09:28 +0200, Purcareata Bogdan wrote:
Ping?
What is the ping for ?
Ben.
Hello Ben,
I just wanted to check with you what's the current status of these
patches. I noticed in patchwork [1][2][3] that the patches
On 27.02.2015 22:54, Benjamin Herrenschmidt wrote:
On Fri, 2015-02-27 at 09:28 +0200, Purcareata Bogdan wrote:
Ping?
What is the ping for ?
Ben.
Making sure the patches are not lost on the mailing lists :) Didn't
receive any feedback on v4 and just wanted to check if there's anything
Ping?
On 18.02.2015 10:16, Bogdan Purcareata wrote:
Add the missing pieces in order to enable SECCOMP_FILTER on PowerPC
architectures, and enable this support.
Testing has been pursued using libseccomp with the latest ppc support patches
[1][2], on Freescale platforms for both ppc and ppc64.
On 20.02.2015 17:17, Sebastian Andrzej Siewior wrote:
On 02/20/2015 04:10 PM, Paolo Bonzini wrote:
On 20/02/2015 16:06, Sebastian Andrzej Siewior wrote:
On 02/20/2015 03:57 PM, Paolo Bonzini wrote:
Yes, but large latencies just mean the code has to be rewritten (x86
doesn't anymore do event
On 20.02.2015 17:06, Sebastian Andrzej Siewior wrote:
On 02/20/2015 03:57 PM, Paolo Bonzini wrote:
On 20/02/2015 15:54, Sebastian Andrzej Siewior wrote:
Usually you see scheduling while atomic on -RT and convert them to
raw locks if it is appropriate.
Bogdan wrote in 2/2 that he needs to
On 20.02.2015 16:54, Sebastian Andrzej Siewior wrote:
On 02/20/2015 03:12 PM, Paolo Bonzini wrote:
Thomas, what is the usual approach for patches like this? Do you take
them into your rt tree or should they get integrated to upstream?
Patch 1 is definitely suitable for upstream, that's the
On 18.02.2015 05:01, Mike Strosaker wrote:
This patch failed to build using pseries_le_defconfig. With the change
noted below in entry_64.S, the build succeeded and seccomp mode 2 worked
correctly.
Best,
Mike Strosaker
On 02/13/2015 02:22 AM, Bogdan Purcareata wrote:
In certain scenarios -
On 12.02.2015 07:24, Michael Ellerman wrote:
On Wed, 2015-02-11 at 08:36 +, Bogdan Purcareata wrote:
In certain scenarios - e.g. seccomp filtering with ERRNO as default action -
the system call fails for other reasons than the syscall not being available.
The seccomp filter can be
On 11.02.2015 05:04, Michael Ellerman wrote:
On Mon, 2015-02-09 at 07:55 +, Bogdan Purcareata wrote:
In certain scenarios - e.g. seccomp filtering with ERRNO as default action -
the system call fails for other reasons than the syscall not being available.
The seccomp filter can be
Obvious mistake on my behalf to send the patch with lines commented out.
I will fix it in v2.
On 09.02.2015 09:55, Bogdan Purcareata wrote:
In certain scenarios - e.g. seccomp filtering with ERRNO as default action -
the system call fails for other reasons than the syscall not being available.
On 14.01.2015 19:58, Scott Wood wrote:
On Wed, 2015-01-14 at 11:57 +, Bogdan Purcareata wrote:
The readback is necessary in order to handle PCI posted
writes,
That is unclear.
I'm going to try an venture a different explanation here.
I found a good explanation in Writing PCI Drivers
Hello,
While doing some performance testing of a KVM guest on a PPC platform, I
noticed that there's a read of the CPU_WHOAMI register after each MPIC
EOI [1]. This has been present since the initial implementation of the
MPIC driver [2]. In a KVM virtualized environment, this results in an
20 matches
Mail list logo
