The patch adds new IOCTL commands for sPAPR VFIO container device
to support EEH functionality for PCI devices, which have been passed
through from host to somebody else via VFIO.
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
Documentation/vfio.txt | 87
We must not handle EEH error on devices which are passed to somebody
else. Instead, we expect that the frozen device owner detects an EEH
error and recovers from it.
This avoids EEH error handling on passed through devices so the device
owner gets a chance to handle them.
Signed-off-by: Gavin
The series of patches adds support EEH for PCI devices, which are passed
through to PowerKVM based guest via VFIO. The implementation is straightforward
based on the issues or problems we have to resolve to support EEH for PowerKVM
based guest.
- Emulation for EEH RTAS requests. All EEH RTAS
The patch exports functions to be used by new VFIO ioctl command,
which will be introduced in subsequent patch, to support EEH
functinality for VFIO PCI devices.
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/eeh.h | 14 +++
arch/powerpc/kernel/eeh.c | 268
On Thu, 2014-06-05 at 16:36 +1000, Gavin Shan wrote:
+#define EEH_OPT_GET_PE_ADDR0 /* Get PE addr */
+#define EEH_OPT_GET_PE_MODE1 /* Get PE mode */
I assume that's just some leftover from the previous patches :-)
Don't respin just yet, let's see what other comments come
This reserves 2 capability numbers.
This implements an extended version of KVM_CREATE_SPAPR_TCE_64 ioctl.
Please advise how to proceed with these patches as I suspect that
first two should go via Paolo's tree while the last one via Alex Graf's tree
(correct?).
Thanks!
Alexey Kardashevskiy (3):
The existing KVM_CREATE_SPAPR_TCE only supports 32bit windows which is not
enough for directly mapped windows as the guest can get more than 4GB.
This adds KVM_CREATE_SPAPR_TCE_64 ioctl and advertises it
via KVM_CAP_SPAPR_TCE_64 capability.
Since 64bit windows are to support Dynamic DMA windows
This adds a capability number for 64-bit TCE tables support.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
include/uapi/linux/kvm.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 944cd21..e6972bf 100644
---
This adds a capability number for in-kernel support for VFIO on
SPAPR platform.
The capability will tell the user space whether in-kernel handlers of
H_PUT_TCE can handle VFIO-targeted requests or not. If not, the user space
must not attempt allocating a TCE table in the host kernel via
the
On Thu, 2014-06-05 at 17:25 +1000, Alexey Kardashevskiy wrote:
+This creates a virtual TCE (translation control entry) table, which
+is an IOMMU for PAPR-style virtual I/O. It is used to translate
+logical addresses used in virtual I/O into guest physical addresses,
+and provides a
On 06/05/2014 05:38 PM, Benjamin Herrenschmidt wrote:
On Thu, 2014-06-05 at 17:25 +1000, Alexey Kardashevskiy wrote:
+This creates a virtual TCE (translation control entry) table, which
+is an IOMMU for PAPR-style virtual I/O. It is used to translate
+logical addresses used in virtual I/O
On Thu, 2014-06-05 at 19:26 +1000, Alexey Kardashevskiy wrote:
No trees yet. For 64GB window we need (6430)/(1620)*8 = 32K TCE table.
Do we really need trees?
The above is assuming hugetlbfs backed guests. These are the least of my worry
indeed. But we need to deal with 4k and 64k guests.
On 05.06.14 12:27, Benjamin Herrenschmidt wrote:
On Thu, 2014-06-05 at 19:26 +1000, Alexey Kardashevskiy wrote:
No trees yet. For 64GB window we need (6430)/(1620)*8 = 32K TCE table.
Do we really need trees?
The above is assuming hugetlbfs backed guests. These are the least of my worry
On 05.06.14 09:25, Alexey Kardashevskiy wrote:
This reserves 2 capability numbers.
This implements an extended version of KVM_CREATE_SPAPR_TCE_64 ioctl.
Please advise how to proceed with these patches as I suspect that
first two should go via Paolo's tree while the last one via Alex Graf's
This patchset adds support for emulating VTB, IC and Doorbell features in P8.
Doorbell support is dummy since we don't support SMT cores with PR-KVM.
-aneesh
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo
We don't have SMT support yet, hence we should not find a doorbell
message generated
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
arch/powerpc/kvm/book3s_emulate.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/powerpc/kvm/book3s_emulate.c
virtual time base register is a per VM, per cpu register that needs
to be saved and restored on vm exit and entry. Writing to VTB is not
allowed in the privileged mode.
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/kvm_host.h | 1 +
Writing to IC is not allowed in the privileged mode.
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/kvm_host.h | 1 +
arch/powerpc/kvm/book3s.c | 6 ++
arch/powerpc/kvm/book3s_emulate.c | 3 +++
arch/powerpc/kvm/book3s_hv.c| 6
Since we don't support SMT yet, we should always find zero in
Directed privileged doorbell exception state register.
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
arch/powerpc/kvm/book3s_emulate.c | 1 +
1 file changed, 1 insertion(+)
diff --git
On 05.06.14 14:08, Aneesh Kumar K.V wrote:
virtual time base register is a per VM, per cpu register that needs
to be saved and restored on vm exit and entry. Writing to VTB is not
allowed in the privileged mode.
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
On 05.06.14 14:08, Aneesh Kumar K.V wrote:
We don't have SMT support yet, hence we should not find a doorbell
message generated
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
arch/powerpc/kvm/book3s_emulate.c | 18 ++
1 file changed, 18 insertions(+)
On 05.06.14 14:21, Alexander Graf wrote:
On 05.06.14 14:08, Aneesh Kumar K.V wrote:
We don't have SMT support yet, hence we should not find a doorbell
message generated
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
arch/powerpc/kvm/book3s_emulate.c | 18
On Thu, 2014-06-05 at 13:56 +0200, Alexander Graf wrote:
What if we ask user space to give us a pointer to user space allocated
memory along with the TCE registration? We would still ask user space to
only use the returned fd for TCE modifications, but would have some
nicely swappable
On 05.06.14 14:30, Benjamin Herrenschmidt wrote:
On Thu, 2014-06-05 at 13:56 +0200, Alexander Graf wrote:
What if we ask user space to give us a pointer to user space allocated
memory along with the TCE registration? We would still ask user space to
only use the returned fd for TCE
On 05.06.14 08:36, Gavin Shan wrote:
The series of patches adds support EEH for PCI devices, which are passed
through to PowerKVM based guest via VFIO. The implementation is straightforward
based on the issues or problems we have to resolve to support EEH for PowerKVM
based guest.
- Emulation
On 06/05/2014 10:30 PM, Benjamin Herrenschmidt wrote:
On Thu, 2014-06-05 at 13:56 +0200, Alexander Graf wrote:
What if we ask user space to give us a pointer to user space allocated
memory along with the TCE registration? We would still ask user space to
only use the returned fd for TCE
Alexander Graf ag...@suse.de writes:
On 05.06.14 14:08, Aneesh Kumar K.V wrote:
virtual time base register is a per VM, per cpu register that needs
to be saved and restored on vm exit and entry. Writing to VTB is not
allowed in the privileged mode.
Signed-off-by: Aneesh Kumar K.V
Alexander Graf ag...@suse.de writes:
On 05.06.14 14:21, Alexander Graf wrote:
On 05.06.14 14:08, Aneesh Kumar K.V wrote:
We don't have SMT support yet, hence we should not find a doorbell
message generated
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
On 05.06.14 17:50, Aneesh Kumar K.V wrote:
Alexander Graf ag...@suse.de writes:
On 05.06.14 14:08, Aneesh Kumar K.V wrote:
virtual time base register is a per VM, per cpu register that needs
to be saved and restored on vm exit and entry. Writing to VTB is not
allowed in the privileged mode.
Paolo Bonzini pbonz...@redhat.com writes:
Il 03/06/2014 09:02, Michal Nazarewicz ha scritto:
On Tue, Jun 03 2014, Joonsoo Kim wrote:
Now, we have general CMA reserved area management framework,
so use it for future maintainabilty. There is no functional change.
Signed-off-by: Joonsoo Kim
On Thu, 2014-06-05 at 16:36 +1000, Gavin Shan wrote:
The patch adds new IOCTL commands for sPAPR VFIO container device
to support EEH functionality for PCI devices, which have been passed
through from host to somebody else via VFIO.
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
Alexander Graf ag...@suse.de writes:
On 05.06.14 17:50, Aneesh Kumar K.V wrote:
Alexander Graf ag...@suse.de writes:
On 05.06.14 14:08, Aneesh Kumar K.V wrote:
virtual time base register is a per VM, per cpu register that needs
to be saved and restored on vm exit and entry. Writing to VTB
Joonsoo Kim iamjoonsoo@lge.com writes:
Currently, there are two users on CMA functionality, one is the DMA
subsystem and the other is the kvm on powerpc. They have their own code
to manage CMA reserved area even if they looks really similar.
From my guess, it is caused by some needs on
On 05.06.14 19:33, Aneesh Kumar K.V wrote:
Alexander Graf ag...@suse.de writes:
On 05.06.14 17:50, Aneesh Kumar K.V wrote:
Alexander Graf ag...@suse.de writes:
On 05.06.14 14:08, Aneesh Kumar K.V wrote:
virtual time base register is a per VM, per cpu register that needs
to be saved and
On 06.06.14 00:32, Alexander Graf wrote:
On 05.06.14 19:33, Aneesh Kumar K.V wrote:
Alexander Graf ag...@suse.de writes:
On 05.06.14 17:50, Aneesh Kumar K.V wrote:
Alexander Graf ag...@suse.de writes:
On 05.06.14 14:08, Aneesh Kumar K.V wrote:
virtual time base register is a per VM, per
On 06/05/2014 09:57 PM, Alexander Graf wrote:
On 05.06.14 09:25, Alexey Kardashevskiy wrote:
This reserves 2 capability numbers.
This implements an extended version of KVM_CREATE_SPAPR_TCE_64 ioctl.
Please advise how to proceed with these patches as I suspect that
first two should go via
On Thu, Jun 05, 2014 at 04:50:04PM +1000, Benjamin Herrenschmidt wrote:
On Thu, 2014-06-05 at 16:36 +1000, Gavin Shan wrote:
+#define EEH_OPT_GET_PE_ADDR0 /* Get PE addr */
+#define EEH_OPT_GET_PE_MODE1 /* Get PE mode */
I assume that's just some leftover from the previous
On Thu, Jun 05, 2014 at 11:18:34AM -0600, Alex Williamson wrote:
On Thu, 2014-06-05 at 16:36 +1000, Gavin Shan wrote:
The patch adds new IOCTL commands for sPAPR VFIO container device
to support EEH functionality for PCI devices, which have been passed
through from host to somebody else via
On Thu, Jun 05, 2014 at 02:54:47PM +0200, Alexander Graf wrote:
On 05.06.14 08:36, Gavin Shan wrote:
The series of patches adds support EEH for PCI devices, which are passed
through to PowerKVM based guest via VFIO. The implementation is
straightforward
based on the issues or problems we have to
The patch adds new IOCTL commands for sPAPR VFIO container device
to support EEH functionality for PCI devices, which have been passed
through from host to somebody else via VFIO.
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
Acked-by: Alexander Graf ag...@suse.de
---
We must not handle EEH error on devices which are passed to somebody
else. Instead, we expect that the frozen device owner detects an EEH
error and recovers from it.
This avoids EEH error handling on passed through devices so the device
owner gets a chance to handle them.
Signed-off-by: Gavin
The series of patches adds support EEH for PCI devices, which are passed
through to PowerKVM based guest via VFIO. The implementation is straightforward
based on the issues or problems we have to resolve to support EEH for PowerKVM
based guest.
- Emulation for EEH RTAS requests. All EEH RTAS
The patch exports functions to be used by new VFIO ioctl command,
which will be introduced in subsequent patch, to support EEH
functinality for VFIO PCI devices.
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
Acked-by: Alexander Graf ag...@suse.de
---
arch/powerpc/include/asm/eeh.h | 12 ++
43 matches
Mail list logo
