On Wed, Jul 3, 2013 at 5:07 AM, Alex Williamson
wrote:
> On Tue, 2013-07-02 at 23:25 +, Yoder Stuart-B08248 wrote:
>> The write-up below is the first draft of a proposal for how the kernel can
>> expose
>> platform devices to user space using vfio.
>>
>> In short, I'm proposing a new ioctl VF
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, June 05, 2013 1:40 AM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; Caraman Mihai Claudiu-B02008
> Subject: Re: [RFC PATCH 5/6] KVM: PPC: Book3E: Ad
> So we can remove this hack in kvm_asm.h:
Not yet, this comment was added in the context of AltiVec RFC patches
which intended to remove a similar dependency.
>
> /*
> * TODO: Unify 32-bit and 64-bit kernel exception handlers to use same
> defines
> */
> #define BOOKE_INTERRUPT_SPE_UNAVAIL
Add KVM Book3E AltiVec support. KVM Book3E FPU support gracefully reuse host
infrastructure so follow the same approach for AltiVec.
Signed-off-by: Mihai Caraman
---
arch/powerpc/kvm/booke.c | 72 -
1 files changed, 70 insertions(+), 2 deletions(-)
Add ONE_REG support for AltiVec on Book3E.
Signed-off-by: Mihai Caraman
---
arch/powerpc/kvm/booke.c | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index c3c3af6..6ac1f68 100644
--- a/ar
Use common BOOKE_IRQPRIO and BOOKE_INTERRUPT defines for SPE/FP/AltiVec
which share the same interrupts numbers.
Signed-off-by: Mihai Caraman
---
arch/powerpc/kvm/booke.c | 16
arch/powerpc/kvm/booke.h |4 ++--
arch/powerpc/kvm/bookehv_interrupts.
Add KVM Book3E AltiVec support and enable e6500 core.
Mihai Caraman (6):
KVM: PPC: Book3E: Use common defines for SPE/FP/AltiVec int numbers
KVM: PPC: Book3E: Refactor SPE/FP exit handling
KVM: PPC: Book3E: Increase FPU laziness
KVM: PPC: Book3E: Add AltiVec support
KVM: PPC: Book3E: Add
SPE/FP/AltiVec interrupts share the same numbers. Refactor SPE/FP exit handling
to accommodate AltiVec later. Detect the targeted unit at run time since it can
be configured in the kernel but not featured on hardware.
Signed-off-by: Mihai Caraman
---
arch/powerpc/kvm/booke.c | 102 +
Increase FPU laziness by calling kvmppc_load_guest_fp() just before
returning to guest instead of each sched in. Without this improvement
an interrupt may also claim floting point corrupting guest state.
Signed-off-by: Mihai Caraman
---
arch/powerpc/kvm/booke.c |1 +
arch/powerpc/kvm/e500mc
Now that AltiVec support is in place enable e6500 core.
Signed-off-by: Mihai Caraman
---
arch/powerpc/kvm/e500mc.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
index 09da1ac..bec897c 100644
--- a/arch/pow
On 03.07.2013, at 14:42, Mihai Caraman wrote:
> SPE/FP/AltiVec interrupts share the same numbers. Refactor SPE/FP exit
> handling
> to accommodate AltiVec later. Detect the targeted unit at run time since it
> can
> be configured in the kernel but not featured on hardware.
>
> Signed-off-by: M
Some guests are making use of return from machine check instruction
to do crazy things even though the 64-bit kernel doesn't handle yet
this interrupt. Emulate MCSRR0/1 SPR and rfmci instruction accordingly.
Signed-off-by: Mihai Caraman
---
arch/powerpc/include/asm/kvm_host.h |1 +
arch/powe
Some exit ids where left out from kvm_exit_names array.
Signed-off-by: Mihai Caraman
---
arch/powerpc/kvm/timing.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kvm/timing.c b/arch/powerpc/kvm/timing.c
index 07b6110..c392d26 100644
--- a/arch/powerpc/kv
On 03.07.2013, at 14:42, Mihai Caraman wrote:
> Increase FPU laziness by calling kvmppc_load_guest_fp() just before
> returning to guest instead of each sched in. Without this improvement
> an interrupt may also claim floting point corrupting guest state.
Not sure I follow. Could you please desc
> > -#ifdef CONFIG_SPE
> > case BOOKE_INTERRUPT_SPE_ALTIVEC_UNAVAIL: {
> > - if (vcpu->arch.shared->msr & MSR_SPE)
> > - kvmppc_vcpu_enable_spe(vcpu);
> > - else
> > - kvmppc_booke_queue_irqprio(vcpu,
> > -
> BOOKE_IRQPRIO_SPE_ALTIVEC_UNAV
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Wednesday, July 03, 2013 4:45 PM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org
> Subject: Re: [PATCH 3/6] KVM: PPC: Book3E: Increase FPU laz
On 03.07.2013, at 15:55, Caraman Mihai Claudiu-B02008 wrote:
>> -Original Message-
>> From: Alexander Graf [mailto:ag...@suse.de]
>> Sent: Wednesday, July 03, 2013 4:45 PM
>> To: Caraman Mihai Claudiu-B02008
>> Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org; linuxppc-
>> d...@lists.ozl
On 03.07.2013, at 15:53, Caraman Mihai Claudiu-B02008 wrote:
>>> -#ifdef CONFIG_SPE
>>> case BOOKE_INTERRUPT_SPE_ALTIVEC_UNAVAIL: {
>>> - if (vcpu->arch.shared->msr & MSR_SPE)
>>> - kvmppc_vcpu_enable_spe(vcpu);
>>> - else
>>> - kvmppc_b
On 03.07.2013, at 14:42, Mihai Caraman wrote:
> Add KVM Book3E AltiVec support. KVM Book3E FPU support gracefully reuse host
> infrastructure so follow the same approach for AltiVec.
>
> Signed-off-by: Mihai Caraman
> ---
> arch/powerpc/kvm/booke.c | 72 +++
> >>> Increase FPU laziness by calling kvmppc_load_guest_fp() just before
> >>> returning to guest instead of each sched in. Without this improvement
> >>> an interrupt may also claim floting point corrupting guest state.
> >>
> >> Not sure I follow. Could you please describe exactly what's happeni
> > + * Simulate AltiVec unavailable fault to load guest state
> > + * from thread to AltiVec unit.
> > + * It requires to be called with preemption disabled.
> > + */
> > +static inline void kvmppc_load_guest_altivec(struct kvm_vcpu *vcpu)
> > +{
> > + if (kvmppc_supports_altivec()) {
> > +
On 03.07.2013, at 18:09, Caraman Mihai Claudiu-B02008 wrote:
>>> + * Simulate AltiVec unavailable fault to load guest state
>>> + * from thread to AltiVec unit.
>>> + * It requires to be called with preemption disabled.
>>> + */
>>> +static inline void kvmppc_load_guest_altivec(struct kvm_vcpu *v
> >>> +
> >>> if (!vcpu->arch.sane) {
> >>> kvm_run->exit_reason = KVM_EXIT_INTERNAL_ERROR;
> >>> return -EINVAL;
> >>> @@ -716,6 +750,22 @@ int kvmppc_vcpu_run(struct kvm_run *kvm_run,
> >> struct kvm_vcpu *vcpu)
> >>> kvmppc_load_guest_fp(vcpu);
> >>> #endif
> >>>
> >>> +#
Add LRAT (Logical to Real Address Translation) error exception handler to
Booke3E 64-bit kernel. LRAT support in KVM will follow afterwards.
Signed-off-by: Mihai Caraman
---
arch/powerpc/include/asm/kvm_asm.h |1 +
arch/powerpc/include/asm/reg_booke.h |1 +
arch/powerpc/kernel/exceptio
With LRAT (Logical to Real Address Translation) error exception handler in
kernel
KVM needs to add the counterpart otherwise will break the build.
Signed-off-by: Mihai Caraman
---
arch/powerpc/kvm/bookehv_interrupts.S |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arc
On 03.07.2013, at 17:41, Caraman Mihai Claudiu-B02008 wrote:
> Increase FPU laziness by calling kvmppc_load_guest_fp() just before
> returning to guest instead of each sched in. Without this improvement
> an interrupt may also claim floting point corrupting guest state.
Not
On 07/03/2013 10:11:50 AM, Alexander Graf wrote:
On 03.07.2013, at 15:55, Caraman Mihai Claudiu-B02008 wrote:
>> -Original Message-
>> From: Alexander Graf [mailto:ag...@suse.de]
>> Sent: Wednesday, July 03, 2013 4:45 PM
>> To: Caraman Mihai Claudiu-B02008
>> Cc: kvm-ppc@vger.kernel.org
On 03.07.2013, at 18:49, Caraman Mihai Claudiu-B02008 wrote:
> +
> if (!vcpu->arch.sane) {
> kvm_run->exit_reason = KVM_EXIT_INTERNAL_ERROR;
> return -EINVAL;
> @@ -716,6 +750,22 @@ int kvmppc_vcpu_run(struct kvm_run *kvm_run,
struct kvm_vcpu *vcpu)
On 03.07.2013, at 19:07, Scott Wood wrote:
> On 07/03/2013 10:11:50 AM, Alexander Graf wrote:
>> On 03.07.2013, at 15:55, Caraman Mihai Claudiu-B02008 wrote:
>> >> -Original Message-
>> >> From: Alexander Graf [mailto:ag...@suse.de]
>> >> Sent: Wednesday, July 03, 2013 4:45 PM
>> >> To: C
On 07/03/2013 11:59:45 AM, Alexander Graf wrote:
On 03.07.2013, at 17:41, Caraman Mihai Claudiu-B02008 wrote:
> Increase FPU laziness by calling kvmppc_load_guest_fp() just
before
> returning to guest instead of each sched in. Without this
improvement
> an interrupt may also cla
On 07/03/2013 07:42:36 AM, Mihai Caraman wrote:
Increase FPU laziness by calling kvmppc_load_guest_fp() just before
returning to guest instead of each sched in. Without this improvement
an interrupt may also claim floting point corrupting guest state.
Signed-off-by: Mihai Caraman
---
arch/powe
[cut]
> So overall the interface and extension makes sense. My only question is
> whether it's better to get complete reuse out of GET_REGION_INFO and
> GET_IRQ_INFO and then add another device tree specific ioctl or is it
> better to add a device tree index and path to the existing GET_*_INFO
>
On 03.07.2013, at 19:18, Scott Wood wrote:
> On 07/03/2013 07:42:36 AM, Mihai Caraman wrote:
>> Increase FPU laziness by calling kvmppc_load_guest_fp() just before
>> returning to guest instead of each sched in. Without this improvement
>> an interrupt may also claim floting point corrupting gues
On 03.07.2013, at 19:17, Scott Wood wrote:
> On 07/03/2013 11:59:45 AM, Alexander Graf wrote:
>> On 03.07.2013, at 17:41, Caraman Mihai Claudiu-B02008 wrote:
>> > Increase FPU laziness by calling kvmppc_load_guest_fp() just before
>> > returning to guest instead of each sched in. Without
On 07/03/2013 12:23:16 PM, Alexander Graf wrote:
On 03.07.2013, at 19:18, Scott Wood wrote:
> On 07/03/2013 07:42:36 AM, Mihai Caraman wrote:
>> Increase FPU laziness by calling kvmppc_load_guest_fp() just before
>> returning to guest instead of each sched in. Without this
improvement
>> an
On 07/03/2013 10:13:57 AM, Alexander Graf wrote:
On 03.07.2013, at 15:53, Caraman Mihai Claudiu-B02008 wrote:
>>> -#ifdef CONFIG_SPE
>>>case BOOKE_INTERRUPT_SPE_ALTIVEC_UNAVAIL: {
>>> - if (vcpu->arch.shared->msr & MSR_SPE)
>>> - kvmppc_vcpu_enable_spe(vcpu);
>>>
On 07/03/2013 07:11:52 AM, Caraman Mihai Claudiu-B02008 wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, June 05, 2013 1:40 AM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; Caraman Mihai C
On 07/03/2013 12:07:30 PM, Alexander Graf wrote:
On 03.07.2013, at 18:49, Caraman Mihai Claudiu-B02008 wrote:
Do we need to do this even when the guest doesn't use Altivec?
Can't
>> we
just load it on demand then once we fault? This code path really
>> should
only be a prefetc
On 07/03/2013 07:42:36 AM, Mihai Caraman wrote:
Increase FPU laziness by calling kvmppc_load_guest_fp() just before
returning to guest instead of each sched in. Without this improvement
an interrupt may also claim floting point corrupting guest state.
Signed-off-by: Mihai Caraman
---
arch/powe
On 03.07.2013, at 19:44, Scott Wood wrote:
> On 07/03/2013 12:23:16 PM, Alexander Graf wrote:
>> On 03.07.2013, at 19:18, Scott Wood wrote:
>> > On 07/03/2013 07:42:36 AM, Mihai Caraman wrote:
>> >> Increase FPU laziness by calling kvmppc_load_guest_fp() just before
>> >> returning to guest inste
On 07/03/2013 07:42:37 AM, Mihai Caraman wrote:
Add KVM Book3E AltiVec support. KVM Book3E FPU support gracefully
reuse host
infrastructure so follow the same approach for AltiVec.
Signed-off-by: Mihai Caraman
---
arch/powerpc/kvm/booke.c | 72
On 03.07.2013, at 20:37, Scott Wood wrote:
> On 07/03/2013 07:42:36 AM, Mihai Caraman wrote:
>> Increase FPU laziness by calling kvmppc_load_guest_fp() just before
>> returning to guest instead of each sched in. Without this improvement
>> an interrupt may also claim floting point corrupting gues
On 03.07.2013, at 20:28, Scott Wood wrote:
> On 07/03/2013 10:13:57 AM, Alexander Graf wrote:
>> On 03.07.2013, at 15:53, Caraman Mihai Claudiu-B02008 wrote:
>> >>> -#ifdef CONFIG_SPE
>> >>> case BOOKE_INTERRUPT_SPE_ALTIVEC_UNAVAIL: {
>> >>> -if (vcpu->arch.shared->msr & MSR_SPE)
On 07/03/2013 01:42:12 PM, Alexander Graf wrote:
On 03.07.2013, at 20:28, Scott Wood wrote:
> On 07/03/2013 10:13:57 AM, Alexander Graf wrote:
>> There is no chip that supports SPE and HV at the same time. So
we'll never hit this anyway, since kvmppc_supports_spe() always
returns false on H
On 03.07.2013, at 20:36, Scott Wood wrote:
> On 07/03/2013 12:07:30 PM, Alexander Graf wrote:
>> On 03.07.2013, at 18:49, Caraman Mihai Claudiu-B02008 wrote:
>> Do we need to do this even when the guest doesn't use Altivec? Can't
>> >> we
>> just load it on demand then once we fault? Th
On 07/02/2013 08:07:53 PM, Alexander Graf wrote:
On 03.07.2013, at 01:25, Yoder Stuart-B08248 wrote:
> 8. Open Issues
>
> -how to handle cases where VFIO is requested to handle
>a device where the valid, mappable range for a region
>is less than a page size. See example above where
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, July 03, 2013 1:52 PM
> To: Alexander Graf
> Cc: Yoder Stuart-B08248; Alex Williamson; Wood Scott-B07421; Bhushan
> Bharat-R65777; Sethi Varun-B16395;
> virtualizat...@lists.linux-foundation.org; Antonios Motakis;
> k...@
[cut]
> > So overall the interface and extension makes sense. My only question is
> > whether it's better to get complete reuse out of GET_REGION_INFO and
> > GET_IRQ_INFO and then add another device tree specific ioctl or is it
> > better to add a device tree index and path to the existing GET_*_
Version 4 changes
-clarified that KVM zeros the upper half of the struct fields
if the VM is not in 64-bit mode
KVM_CAP_EXIT_EPAPR_HCALL Capability
A new capability KVM_CAP_EXIT_EPAPR_HCALL is defined to advertise
th
On 03.07.2013, at 21:29, Yoder Stuart-B08248 wrote:
> Version 4 changes
> -clarified that KVM zeros the upper half of the struct fields
>if the VM is not in 64-bit mode
>
>
> KVM_CAP_EXIT_EPAPR_HCALL Capability
>
>
On 07/03/2013 02:32:07 PM, Alexander Graf wrote:
On 03.07.2013, at 21:29, Yoder Stuart-B08248 wrote:
> Version 4 changes
> -clarified that KVM zeros the upper half of the struct fields
>if the VM is not in 64-bit mode
>
>
-
On 07/03/2013 11:56:06 AM, Mihai Caraman wrote:
With LRAT (Logical to Real Address Translation) error exception
handler in kernel
KVM needs to add the counterpart otherwise will break the build.
Signed-off-by: Mihai Caraman
---
arch/powerpc/kvm/bookehv_interrupts.S |2 ++
1 files changed
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Wednesday, July 03, 2013 2:32 PM
> To: Yoder Stuart-B08248
> Cc: Bhushan Bharat-R65777; Wood Scott-B07421; k...@vger.kernel.org list;
> kvm-ppc@vger.kernel.org
> Subject: Re: PPC: RFC: proposal for VM reset & shut
On 07/03/2013 11:56:05 AM, Mihai Caraman wrote:
@@ -1410,6 +1423,7 @@ _GLOBAL(setup_doorbell_ivors)
_GLOBAL(setup_ehv_ivors)
SET_IVOR(40, 0x300) /* Embedded Hypervisor System Call */
SET_IVOR(41, 0x320) /* Embedded Hypervisor Privilege */
+ SET_IVOR(42, 0x340) /* LRAT Error
Version 2
-VFIO_GROUP_GET_DEVICE_FD-- specified that the path is a sysfs path
-VFIO_DEVICE_GET_INFO-- defined 2 flags instead of 1
-deleted VFIO_DEVICE_GET_DEVTREE_INFO ioctl
-VFIO_DEVICE_GET_REGION_INFO-- updated as per AlexW's suggestion,
defined 5 new flags and associated structs
-V
On 03.07.2013, at 22:16, Yoder Stuart-B08248 wrote:
>
>
>> -Original Message-
>> From: Alexander Graf [mailto:ag...@suse.de]
>> Sent: Wednesday, July 03, 2013 2:32 PM
>> To: Yoder Stuart-B08248
>> Cc: Bhushan Bharat-R65777; Wood Scott-B07421; k...@vger.kernel.org list;
>> kvm-ppc@vger.
On 03.07.2013, at 22:16, Scott Wood wrote:
> On 07/03/2013 11:56:06 AM, Mihai Caraman wrote:
>> With LRAT (Logical to Real Address Translation) error exception handler in
>> kernel
>> KVM needs to add the counterpart otherwise will break the build.
>> Signed-off-by: Mihai Caraman
>> ---
>> arch
On 07/03/2013 04:42:40 PM, Alexander Graf wrote:
On 03.07.2013, at 22:16, Scott Wood wrote:
> On 07/03/2013 11:56:06 AM, Mihai Caraman wrote:
>> With LRAT (Logical to Real Address Translation) error exception
handler in kernel
>> KVM needs to add the counterpart otherwise will break the buil
On 07/02/2013 06:25:59 PM, Yoder Stuart-B08248 wrote:
The write-up below is the first draft of a proposal for how the
kernel can expose
platform devices to user space using vfio.
In short, I'm proposing a new ioctl VFIO_DEVICE_GET_DEVTREE_INFO which
allows user space to correlate regions and i
On Wed, 2013-07-03 at 21:40 +, Yoder Stuart-B08248 wrote:
> Version 2
> -VFIO_GROUP_GET_DEVICE_FD-- specified that the path is a sysfs path
> -VFIO_DEVICE_GET_INFO-- defined 2 flags instead of 1
> -deleted VFIO_DEVICE_GET_DEVTREE_INFO ioctl
> -VFIO_DEVICE_GET_REGION_INFO-- updated as pe
On 07/03/2013 05:53:09 PM, Alex Williamson wrote:
Seems like it should work. My only API concern with this model of
appending structs is that a user needs to know the size of each struct
even if they don't otherwise care about it in order to step over it.
In that case, it might be better to ma
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, July 03, 2013 11:18 PM
> To: Caraman Mihai Claudiu-B02008
> Cc: linuxppc-...@lists.ozlabs.org; kvm-ppc@vger.kernel.org;
> k...@vger.kernel.org; Caraman Mihai Claudiu-B02008
> Subject: Re: [PATCH 1/2] powerpc/booke64: Add LRAT
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, July 03, 2013 11:17 PM
> To: Caraman Mihai Claudiu-B02008
> Cc: linuxppc-...@lists.ozlabs.org; kvm-ppc@vger.kernel.org;
> k...@vger.kernel.org; Caraman Mihai Claudiu-B02008
> Subject: Re: [PATCH 2/2] KVM: PPC: Book3E: Add LRA
> -Original Message-
> From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-
> ow...@vger.kernel.org] On Behalf Of Alexander Graf
> Sent: Wednesday, July 03, 2013 9:40 PM
> To: Wood Scott-B07421
> Cc: Caraman Mihai Claudiu-B02008; kvm-ppc@vger.kernel.org;
> k...@vger.kernel.org; linuxppc-.
On Thu, 2013-07-04 at 06:47 +, Caraman Mihai Claudiu-B02008 wrote:
> This is a solid reason. Ben it's ok for you to apply the combined
> patch? If so I will respin it.
Sure, but nowadays, all that stuff goes via Scott and Alex.
Cheers,
Ben.
--
To unsubscribe from this list: send the line "u
65 matches
Mail list logo
