From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?C=c3=a9dric_Le_Goater?= Subject: Re: [PATCH v2 11/16] KVM: introduce a 'mmap' method for KVM devices Date: Mon, 25 Feb 2019 11:57:02 +0100 Message-ID: References: <20190222112840.25000-1-clg@kaod.org> <20190222112840.25000-12-clg@kaod.org> <20190225033309.GO7668@umbus.fritz.box> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, Paul Mackerras , Paolo Bonzini , linuxppc-dev@lists.ozlabs.org To: David Gibson Return-path: In-Reply-To: <20190225033309.GO7668@umbus.fritz.box> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org Sender: "Linuxppc-dev" List-Id: kvm.vger.kernel.org Hello Paolo, On 2/25/19 4:33 AM, David Gibson wrote: > On Fri, Feb 22, 2019 at 12:28:35PM +0100, Cédric Le Goater wrote: >> Some KVM devices will want to handle special mappings related to the >> underlying HW. For instance, the XIVE interrupt controller of the >> POWER9 processor has MMIO pages for thread interrupt management and >> for interrupt source control that need to be exposed to the guest when >> the OS has the required support. >> >> Signed-off-by: Cédric Le Goater > > Ah, when I suggested mmap() on the base device fd, I hadn't realized > there wasn't a facility for that yet. > > Have you discussed this with Paolo? Not yet. > We'll need some core KVM buy in to merge this. Here is an extension of the KVM device to allow special mappings. Something we would need for the support of the POWER9 XIVE interrupt controller. There are two MMIOs we need to expose to the guest : 1. HW MMIO controlling of the interrupt presenter registers (TIMA) 2. HW MMIO of the interrupt sources for interrupt management (ESB) The TIMA could have been exposed with a page offset in the vCPU mapping but as it only makes sense when the XIVE interrupt mode is active, we chose to use directly the KVM device fd for that. Is that ok ? An alternate solution is to use a device ioctl to allocate an anon fd and do the mapping, but that seems like extra fuss for the same result. Thanks, C. >> --- >> include/linux/kvm_host.h | 1 + >> virt/kvm/kvm_main.c | 11 +++++++++++ >> 2 files changed, 12 insertions(+) >> >> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h >> index c38cc5eb7e73..cbf81487b69f 100644 >> --- a/include/linux/kvm_host.h >> +++ b/include/linux/kvm_host.h >> @@ -1223,6 +1223,7 @@ struct kvm_device_ops { >> int (*has_attr)(struct kvm_device *dev, struct kvm_device_attr *attr); >> long (*ioctl)(struct kvm_device *dev, unsigned int ioctl, >> unsigned long arg); >> + int (*mmap)(struct kvm_device *dev, struct vm_area_struct *vma); >> }; >> >> void kvm_device_get(struct kvm_device *dev); >> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c >> index 585845203db8..84717d8cb5e4 100644 >> --- a/virt/kvm/kvm_main.c >> +++ b/virt/kvm/kvm_main.c >> @@ -2878,6 +2878,16 @@ static long kvm_vcpu_compat_ioctl(struct file *filp, >> } >> #endif >> >> +static int kvm_device_mmap(struct file *filp, struct vm_area_struct *vma) >> +{ >> + struct kvm_device *dev = filp->private_data; >> + >> + if (dev->ops->mmap) >> + return dev->ops->mmap(dev, vma); >> + >> + return -ENODEV; >> +} >> + >> static int kvm_device_ioctl_attr(struct kvm_device *dev, >> int (*accessor)(struct kvm_device *dev, >> struct kvm_device_attr *attr), >> @@ -2927,6 +2937,7 @@ static const struct file_operations kvm_device_fops = { >> .unlocked_ioctl = kvm_device_ioctl, >> .release = kvm_device_release, >> KVM_COMPAT(kvm_device_ioctl), >> + .mmap = kvm_device_mmap, >> }; >> >> struct kvm_device *kvm_device_from_filp(struct file *filp) > From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?C=c3=a9dric_Le_Goater?= Date: Mon, 25 Feb 2019 10:57:02 +0000 Subject: Re: [PATCH v2 11/16] KVM: introduce a 'mmap' method for KVM devices Message-Id: List-Id: References: <20190222112840.25000-1-clg@kaod.org> <20190222112840.25000-12-clg@kaod.org> <20190225033309.GO7668@umbus.fritz.box> In-Reply-To: <20190225033309.GO7668@umbus.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: David Gibson Cc: kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, Paul Mackerras , Paolo Bonzini , linuxppc-dev@lists.ozlabs.org Hello Paolo, On 2/25/19 4:33 AM, David Gibson wrote: > On Fri, Feb 22, 2019 at 12:28:35PM +0100, C=E9dric Le Goater wrote: >> Some KVM devices will want to handle special mappings related to the >> underlying HW. For instance, the XIVE interrupt controller of the >> POWER9 processor has MMIO pages for thread interrupt management and >> for interrupt source control that need to be exposed to the guest when >> the OS has the required support. >> >> Signed-off-by: C=E9dric Le Goater >=20 > Ah, when I suggested mmap() on the base device fd, I hadn't realized > there wasn't a facility for that yet. >=20 > Have you discussed this with Paolo? =20 Not yet. > We'll need some core KVM buy in to merge this. Here is an extension of the KVM device to allow special mappings. Something we would need for the support of the POWER9 XIVE interrupt=20 controller. There are two MMIOs we need to expose to the guest :=20 1. HW MMIO controlling of the interrupt presenter registers (TIMA) 2. HW MMIO of the interrupt sources for interrupt management (ESB) The TIMA could have been exposed with a page offset in the vCPU mapping but as it only makes sense when the XIVE interrupt mode is active, we=20 chose to use directly the KVM device fd for that. Is that ok ?=20 An alternate solution is to use a device ioctl to allocate an anon fd and do the mapping, but that seems like extra fuss for the same result.=20 Thanks, C.=20 >> --- >> include/linux/kvm_host.h | 1 + >> virt/kvm/kvm_main.c | 11 +++++++++++ >> 2 files changed, 12 insertions(+) >> >> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h >> index c38cc5eb7e73..cbf81487b69f 100644 >> --- a/include/linux/kvm_host.h >> +++ b/include/linux/kvm_host.h >> @@ -1223,6 +1223,7 @@ struct kvm_device_ops { >> int (*has_attr)(struct kvm_device *dev, struct kvm_device_attr *attr); >> long (*ioctl)(struct kvm_device *dev, unsigned int ioctl, >> unsigned long arg); >> + int (*mmap)(struct kvm_device *dev, struct vm_area_struct *vma); >> }; >> =20 >> void kvm_device_get(struct kvm_device *dev); >> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c >> index 585845203db8..84717d8cb5e4 100644 >> --- a/virt/kvm/kvm_main.c >> +++ b/virt/kvm/kvm_main.c >> @@ -2878,6 +2878,16 @@ static long kvm_vcpu_compat_ioctl(struct file *fi= lp, >> } >> #endif >> =20 >> +static int kvm_device_mmap(struct file *filp, struct vm_area_struct *vm= a) >> +{ >> + struct kvm_device *dev =3D filp->private_data; >> + >> + if (dev->ops->mmap) >> + return dev->ops->mmap(dev, vma); >> + >> + return -ENODEV; >> +} >> + >> static int kvm_device_ioctl_attr(struct kvm_device *dev, >> int (*accessor)(struct kvm_device *dev, >> struct kvm_device_attr *attr), >> @@ -2927,6 +2937,7 @@ static const struct file_operations kvm_device_fop= s =3D { >> .unlocked_ioctl =3D kvm_device_ioctl, >> .release =3D kvm_device_release, >> KVM_COMPAT(kvm_device_ioctl), >> + .mmap =3D kvm_device_mmap, >> }; >> =20 >> struct kvm_device *kvm_device_from_filp(struct file *filp) >=20