On Tue, Feb 12, 2013 at 11:51:13AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2013-02-11 at 20:52 +, Grant Likely wrote:
> > Really the irq mappings should be using reference counting. The existing
> > code is naive on this count and just releases the irq on the first call
> > to irq_dispos
Hi James,
On Mon, 11 Feb 2013 11:57:28 + James Hogan wrote:
>
> On 12/11/12 21:26, Stephen Rothwell wrote:
> > Make if easier for more architectures to select it and thus disable
> > drivers that use virt_to_bus().
> >
> > Signed-off-by: Stephen Rothwell
>
> I was just wondering what the s
Bhushan Bharat-R65777 wrote:
>
>
> > -Original Message-
> > From: Michael Neuling [mailto:mi...@neuling.org]
> > Sent: Tuesday, February 12, 2013 9:16 AM
> > To: Bhushan Bharat-R65777
> > Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> > Subject: Re: BOOKE KVM calling load_up_fpu
On 02/12/2013 12:38 AM, Paul E. McKenney wrote:
> On Mon, Feb 11, 2013 at 05:53:41PM +0530, Srivatsa S. Bhat wrote:
>> On 02/11/2013 05:28 PM, Vincent Guittot wrote:
>>> On 8 February 2013 19:09, Srivatsa S. Bhat
>>> wrote:
>
> [ . . . ]
>
Adding Vincent to CC, who had previously evaluated
> -Original Message-
> From: Michael Neuling [mailto:mi...@neuling.org]
> Sent: Tuesday, February 12, 2013 9:16 AM
> To: Bhushan Bharat-R65777
> Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> Subject: Re: BOOKE KVM calling load_up_fpu from C?
>
> Bhushan Bharat-R65777 wrote:
>
Bhushan Bharat-R65777 wrote:
>
>
> > -Original Message-
> > From: Linuxppc-dev [mailto:linuxppc-dev-
> > bounces+bharat.bhushan=freescale@lists.ozlabs.org] On Behalf Of Michael
> > Neuling
> > Sent: Tuesday, February 12, 2013 8:59 AM
> > To: Wood Scott-B07421
> > Cc: linuxppc-dev@li
> -Original Message-
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+bharat.bhushan=freescale@lists.ozlabs.org] On Behalf Of Michael
> Neuling
> Sent: Tuesday, February 12, 2013 8:59 AM
> To: Wood Scott-B07421
> Cc: linuxppc-dev@lists.ozlabs.org
> Subject: BOOKE KVM calling load_
Scott,
I was looking at changing how load_up_fpu works and I found this in
arch/powerpc/kvm/booke.h:
static inline void kvmppc_load_guest_fp(struct kvm_vcpu *vcpu)
{
#ifdef CONFIG_PPC_FPU
if (vcpu->fpu_active && !(current->thread.regs->msr & MSR_FP)) {
load_up_fpu();
Hi Aneesh,
On Mon, 2013-02-11 at 15:56 +0530, Aneesh Kumar K.V wrote:
> Can you try this patch ?
>
> diff --git a/arch/powerpc/include/asm/mmu-hash64.h
> b/arch/powerpc/include/asm/mmu-hash64.h
I tried your patch on PS3 with a ps3_defconfig build on both Linux-3.7
and Linux-3.8-rc7 and it seems
On Mon, 2013-02-11 at 20:52 +, Grant Likely wrote:
> Really the irq mappings should be using reference counting. The existing
> code is naive on this count and just releases the irq on the first call
> to irq_dispose_mapping(). I've not gotten around to fixing that. Anyone
> want to take that
On Tue, 2013-02-12 at 10:45 +1100, Alexey Kardashevskiy wrote:
> On 12/02/13 09:17, Alex Williamson wrote:
> > On Mon, 2013-02-11 at 22:54 +1100, Alexey Kardashevskiy wrote:
> >> VFIO implements platform independent stuff such as
> >> a PCI driver, BAR access (via read/write on a file descriptor
>
On Tue, 2013-02-12 at 10:19 +1100, Alexey Kardashevskiy wrote:
> On 12/02/13 09:16, Alex Williamson wrote:
> > On Mon, 2013-02-11 at 22:54 +1100, Alexey Kardashevskiy wrote:
> >> @@ -707,11 +709,39 @@ struct iommu_table *iommu_init_table(struct
> >> iommu_table *tbl, int nid)
> >>return tbl;
>
On 12/02/13 09:17, Alex Williamson wrote:
On Mon, 2013-02-11 at 22:54 +1100, Alexey Kardashevskiy wrote:
VFIO implements platform independent stuff such as
a PCI driver, BAR access (via read/write on a file descriptor
or direct mapping when possible) and IRQ signaling.
The platform dependent pa
On 12/02/13 09:16, Alex Williamson wrote:
On Mon, 2013-02-11 at 22:54 +1100, Alexey Kardashevskiy wrote:
This patch initializes IOMMU groups based on the IOMMU
configuration discovered during the PCI scan on POWERNV
(POWER non virtualized) platform. The IOMMU groups are
to be used later by VFIO
>"Aneesh Kumar K.V" < aneesh.ku...@linux.vnet.ibm.com > writes:
>
>> Phileas Fogg < phileas-f...@mail.ru > writes:
>>
>>> And another note.
>>> I took a look at the MMU chapter in the Cell Architecture handbook and
>>> indeed the first 15 bits in VA are treated as 0 by the hardware.
>>>
>>> Quot
On Mon, 2013-02-11 at 22:54 +1100, Alexey Kardashevskiy wrote:
> VFIO implements platform independent stuff such as
> a PCI driver, BAR access (via read/write on a file descriptor
> or direct mapping when possible) and IRQ signaling.
>
> The platform dependent part includes IOMMU initialization
>
On Mon, 2013-02-11 at 22:54 +1100, Alexey Kardashevskiy wrote:
> This patch initializes IOMMU groups based on the IOMMU
> configuration discovered during the PCI scan on POWERNV
> (POWER non virtualized) platform. The IOMMU groups are
> to be used later by VFIO driver (PCI pass through).
>
> It al
On Sun, 2013-02-10 at 12:59 +0400, Phileas Fogg wrote:
> i found where the problem lies.
...
> And that's why lv1_insert_htab_entry fails with -17 which means
> LV1_ILLEGAL_PARAMETER_VALUE because
> the Hypervisor of PS3 checks 'AVPN' values for number of leading zeros and
> allows at least 15 bi
On Mon, 11 Feb 2013 17:19:49 +1100, Michael Ellerman
wrote:
> On Mon, Feb 11, 2013 at 07:31:00AM +0200, Baruch Siach wrote:
> > Hi lkml,
>
> Hi Baruch,
>
> > The drivers/edac/mpc85xx_edac.c driver contains the following (abbreviated)
> > code snippet it its .probe:
>
> You dropped an important
On Mon, Feb 11, 2013 at 05:53:41PM +0530, Srivatsa S. Bhat wrote:
> On 02/11/2013 05:28 PM, Vincent Guittot wrote:
> > On 8 February 2013 19:09, Srivatsa S. Bhat
> > wrote:
[ . . . ]
> >> Adding Vincent to CC, who had previously evaluated the performance and
> >> latency implications of CPU hotp
From: Stefan Roese
Date: Sat, 9 Feb 2013 10:49:12 +0100
> Until now, the MPC5200 FEC ethernet driver relied upon the bootloader
> (U-Boot) to write the MAC address into the ethernet controller
> registers. The Linux driver should not rely on such a thing. So
> lets read the MAC address from the
Hi Srivatsa,
I can try to run some of our stress tests on your patches. Have you
got a git tree that i can pull ?
Regards,
Vincent
On 8 February 2013 19:09, Srivatsa S. Bhat
wrote:
> On 02/08/2013 10:14 PM, Srivatsa S. Bhat wrote:
>> On 02/08/2013 09:11 PM, Russell King - ARM Linux wrote:
>>> O
On 02/11/2013 06:11 PM, David Howells wrote:
> Srivatsa S. Bhat wrote:
>
>> We can use global rwlocks as shown below safely, without fear of deadlocks:
>>
>> Readers:
>>
>> CPU 0CPU 1
>> -- --
>>
>> 1.spin
Srivatsa S. Bhat wrote:
> We can use global rwlocks as shown below safely, without fear of deadlocks:
>
> Readers:
>
> CPU 0CPU 1
> -- --
>
> 1.spin_lock(&random_lock); read_lock(&my_rwlock)
On 02/11/2013 05:28 PM, Vincent Guittot wrote:
> On 8 February 2013 19:09, Srivatsa S. Bhat
> wrote:
>> On 02/08/2013 10:14 PM, Srivatsa S. Bhat wrote:
>>> On 02/08/2013 09:11 PM, Russell King - ARM Linux wrote:
On Thu, Feb 07, 2013 at 11:41:34AM +0530, Srivatsa S. Bhat wrote:
> On 02/07/
This patch initializes IOMMU groups based on the IOMMU
configuration discovered during the PCI scan on POWERNV
(POWER non virtualized) platform. The IOMMU groups are
to be used later by VFIO driver (PCI pass through).
It also implements an API for mapping/unmapping pages for
guest PCI drivers and
From: Alexey Kardashevskiy
The first 2 patches in this set add a multi-tce support feature
(adding/deleting several TCE records at once) in real and virtual mode.
The last 2 patches enable real mode acceleration for VFIO and
extend the multi-tce feature to be available for VFIO devices.
The QEM
From: Alexey Kardashevskiy
The patch allows the host kernel to handle H_PUT_TCE request
without involving QEMU in it what should save time on switching
from the kernel to QEMU and back.
The patch adds an IOMMU ID parameter into the KVM_CAP_SPAPR_TCE ioctl,
QEMU needs to be fixed to support that.
From: Alexey Kardashevskiy
he current VFIO-on-POWER implementation supports only user mode
driven mapping, i.e. QEMU is sending requests to map/unmap pages.
However this approach is really slow in really fast hardware so
it is better to be moved to the real mode.
The patch adds an API to increme
From: Alexey Kardashevskiy
The patch adds real mode handlers for H_PUT_TCE_INDIRECT and
H_STUFF_TCE hypercalls for QEMU emulated devices such as virtio
devices or emulated PCI. These calls allow adding multiple entries
(up to 512) into the TCE table in one call which saves time on
transition to/f
From: Alexey Kardashevskiy
The lookup_linux_pte() function returns a linux PTE which
is required to convert KVM guest physical address into host real
address in real mode.
This convertion will be used by upcoming support of H_PUT_TCE_INDIRECT
as TCE list address comes from the guest directly so
VFIO implements platform independent stuff such as
a PCI driver, BAR access (via read/write on a file descriptor
or direct mapping when possible) and IRQ signaling.
The platform dependent part includes IOMMU initialization
and handling. This patch implements an IOMMU driver for VFIO
which does map
The series introduces a VFIO support on POWER.
The QEMU support is required, the real mode acceleration patches are coming
later.
Alexey Kardashevskiy (2):
vfio powerpc: enabled on powernv platform
vfio powerpc: implemented IOMMU driver for VFIO
arch/powerpc/include/asm/iommu.h|
Hi Stephen,
On 12/11/12 21:26, Stephen Rothwell wrote:
> Make if easier for more architectures to select it and thus disable
> drivers that use virt_to_bus().
>
> Signed-off-by: Stephen Rothwell
I was just wondering what the status of this patch is? It was in -next
for a while but seems to have
"Aneesh Kumar K.V" writes:
> Phileas Fogg writes:
>
>> And another note.
>> I took a look at the MMU chapter in the Cell Architecture handbook and
>> indeed the first 15 bits in VA are treated as 0 by the hardware.
>>
>> Quote:
>>
>> 1. High-order bits above 65 bits in the 80-bit virtual addre
35 matches
Mail list logo
