From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: Scott Wood <scottwood@freescale.com>
Cc: David Gibson <david@gibson.dropbear.id.au>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
kvm-ppc@vger.kernel.org, Alexander Graf <agraf@suse.de>,
Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 3/4] KVM: PPC: Add support for IOMMU in-kernel handling
Date: Mon, 27 May 2013 12:44:24 +1000 [thread overview]
Message-ID: <51A2C888.4050704@ozlabs.ru> (raw)
In-Reply-To: <20130525024524.GA6112@boomeroo.fritz.box>
On 05/25/2013 12:45 PM, David Gibson wrote:
> On Wed, May 22, 2013 at 04:06:57PM -0500, Scott Wood wrote:
>> On 05/20/2013 10:06:46 PM, Alexey Kardashevskiy wrote:
>>> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
>>> index 8465c2a..da6bf61 100644
>>> --- a/arch/powerpc/kvm/powerpc.c
>>> @@ -396,6 +396,7 @@ int kvm_dev_ioctl_check_extension(long ext)
>>> +++ b/arch/powerpc/kvm/powerpc.c
>>> break;
>>> #endif
>>> case KVM_CAP_SPAPR_MULTITCE:
>>> + case KVM_CAP_SPAPR_TCE_IOMMU:
>>> r = 1;
>>> break;
>>> default:
>>
>> Don't advertise SPAPR capabilities if it's not book3s -- and
>> probably there's some additional limitation that would be
>> appropriate.
>
> So, in the case of MULTITCE, that's not quite right. PR KVM can
> emulate a PAPR system on a BookE machine, and there's no reason not to
> allow TCE acceleration as well. We can't make it dependent on PAPR
> mode being selected, because that's enabled per-vcpu, whereas these
> capabilities are queried on the VM before the vcpus are created.
>
> CAP_SPAPR_TCE_IOMMU should be dependent on the presence of suitable
> host side hardware (i.e. a PAPR style IOMMU), though.
The capability says that the ioctl is supported. If there is no IOMMU group
registered, than it will fail with a reasonable error and nobody gets hurt.
What is the problem?
>>
>>> @@ -1025,6 +1026,17 @@ long kvm_arch_vm_ioctl(struct file *filp,
>>> r = kvm_vm_ioctl_create_spapr_tce(kvm, &create_tce);
>>> goto out;
>>> }
>>> + case KVM_CREATE_SPAPR_TCE_IOMMU: {
>>> + struct kvm_create_spapr_tce_iommu create_tce_iommu;
>>> + struct kvm *kvm = filp->private_data;
>>> +
>>> + r = -EFAULT;
>>> + if (copy_from_user(&create_tce_iommu, argp,
>>> + sizeof(create_tce_iommu)))
>>> + goto out;
>>> + r = kvm_vm_ioctl_create_spapr_tce_iommu(kvm,
>>> &create_tce_iommu);
>>> + goto out;
>>> + }
>>> #endif /* CONFIG_PPC_BOOK3S_64 */
>>>
>>> #ifdef CONFIG_KVM_BOOK3S_64_HV
>>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
>>> index 5a2afda..450c82a 100644
>>> --- a/include/uapi/linux/kvm.h
>>> +++ b/include/uapi/linux/kvm.h
>>> @@ -667,6 +667,7 @@ struct kvm_ppc_smmu_info {
>>> #define KVM_CAP_PPC_RTAS 91
>>> #define KVM_CAP_IRQ_XICS 92
>>> #define KVM_CAP_SPAPR_MULTITCE (0x110000 + 89)
>>> +#define KVM_CAP_SPAPR_TCE_IOMMU (0x110000 + 90)
>>
>> Hmm...
>
> Ah, yeah, that needs to be fixed. Those were interim numbers so that
> we didn't have to keep changing our internal trees as new upstream
> ioctls got added to the list. We need to get a proper number for the
> merge, though.
>
>>> @@ -939,6 +940,9 @@ struct kvm_s390_ucas_mapping {
>>> #define KVM_GET_DEVICE_ATTR _IOW(KVMIO, 0xe2, struct
>>> kvm_device_attr)
>>> #define KVM_HAS_DEVICE_ATTR _IOW(KVMIO, 0xe3, struct
>>> kvm_device_attr)
>>>
>>> +/* ioctl for SPAPR TCE IOMMU */
>>> +#define KVM_CREATE_SPAPR_TCE_IOMMU _IOW(KVMIO, 0xe4, struct
>>> kvm_create_spapr_tce_iommu)
>>
>> Shouldn't this go under the vm ioctl section?
The KVM_CREATE_SPAPR_TCE_IOMMU ioctl (the version for emulated devices) is
in this section so I decided to keep them together. Wrong?
--
Alexey
next prev parent reply other threads:[~2013-05-27 2:44 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-21 3:06 [PATCH 0/4 v2] KVM: PPC: IOMMU in-kernel handling Alexey Kardashevskiy
2013-05-21 3:06 ` [PATCH 1/4] KVM: PPC: Add support for multiple-TCE hcalls Alexey Kardashevskiy
2013-05-27 10:08 ` Paolo Bonzini
2013-05-27 14:33 ` Alexey Kardashevskiy
2013-05-21 3:06 ` [PATCH 2/4] powerpc: Prepare to support kernel handling of IOMMU map/unmap Alexey Kardashevskiy
2013-05-21 3:06 ` [PATCH 3/4] KVM: PPC: Add support for IOMMU in-kernel handling Alexey Kardashevskiy
2013-05-22 21:06 ` Scott Wood
2013-05-25 2:45 ` David Gibson
2013-05-27 2:44 ` Alexey Kardashevskiy [this message]
2013-05-28 17:45 ` Scott Wood
2013-05-28 23:30 ` Alexey Kardashevskiy
2013-05-28 23:35 ` Scott Wood
2013-05-29 0:12 ` Alexey Kardashevskiy
2013-05-29 20:05 ` Scott Wood
2013-05-29 23:10 ` Alexey Kardashevskiy
2013-05-29 23:14 ` Scott Wood
2013-05-29 23:29 ` Alexey Kardashevskiy
2013-05-29 23:32 ` Scott Wood
2013-05-27 10:23 ` Paolo Bonzini
2013-05-27 14:26 ` Alexey Kardashevskiy
2013-05-27 14:41 ` Paolo Bonzini
2013-05-28 16:32 ` Scott Wood
2013-05-29 0:20 ` Alexey Kardashevskiy
2013-05-21 3:06 ` [PATCH 4/4] KVM: PPC: Add hugepage " Alexey Kardashevskiy
2013-06-05 6:11 [PATCH 0/4 v3] KVM: PPC: " Alexey Kardashevskiy
2013-06-05 6:11 ` [PATCH 3/4] KVM: PPC: Add support for " Alexey Kardashevskiy
2013-06-16 4:39 ` Benjamin Herrenschmidt
2013-06-19 3:17 ` Alexey Kardashevskiy
2013-06-16 22:25 ` Alexander Graf
2013-06-16 22:39 ` Benjamin Herrenschmidt
2013-06-17 3:13 ` Alex Williamson
2013-06-17 3:56 ` Benjamin Herrenschmidt
2013-06-18 2:32 ` Alex Williamson
2013-06-18 4:38 ` Benjamin Herrenschmidt
2013-06-18 14:48 ` Alex Williamson
2013-06-18 21:58 ` Benjamin Herrenschmidt
2013-06-19 3:35 ` Rusty Russell
2013-06-19 4:59 ` Benjamin Herrenschmidt
2013-06-19 9:58 ` Alexander Graf
2013-06-19 14:50 ` Benjamin Herrenschmidt
2013-06-19 15:49 ` Alex Williamson
2013-06-20 4:58 ` Alexey Kardashevskiy
2013-06-20 5:28 ` David Gibson
2013-06-20 7:47 ` Benjamin Herrenschmidt
2013-06-20 8:48 ` Alexey Kardashevskiy
2013-06-20 14:55 ` Alex Williamson
2013-06-22 8:25 ` Alexey Kardashevskiy
2013-06-22 12:03 ` David Gibson
2013-06-22 14:28 ` Alex Williamson
2013-06-24 3:52 ` David Gibson
2013-06-24 4:41 ` Alex Williamson
2013-06-27 11:01 ` David Gibson
2013-06-22 23:28 ` Benjamin Herrenschmidt
2013-06-24 3:54 ` David Gibson
2013-06-24 3:58 ` Benjamin Herrenschmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51A2C888.4050704@ozlabs.ru \
--to=aik@ozlabs.ru \
--cc=agraf@suse.de \
--cc=david@gibson.dropbear.id.au \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=paulus@samba.org \
--cc=scottwood@freescale.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).