el.org; ag...@suse.de; Yoder Stuart-B08248;
> io...@lists.linux-foundation.org; t...@virtualopensystems.com
> Subject: Re: [PATCH 2/7] Initial skeleton of VFIO support for Device Tree
> based devices
>
> On 10/29/2013 07:47 AM, Alex Williamson wrote:
> > On Mon, 2013-10-28 at 21
> -Original Message-
> From: Antonios Motakis [mailto:a.mota...@virtualopensystems.com]
> Sent: Wednesday, October 02, 2013 6:14 AM
> To: Yoder Stuart-B08248
> Cc: Alex Williamson; kvm...@lists.cs.columbia.edu; iommu@lists.linux-
> foundation.org; linux-samsung-...@vg
m@vger.kernel.org; ag...@suse.de; Yoder Stuart-B08248;
> io...@lists.linux-foundation.org; t...@virtualopensystems.com
> Subject: Re: [PATCH 2/7] Initial skeleton of VFIO support for Device Tree
> based devices
>
> On 09/30/2013 11:37 AM, Bhushan Bharat-R65777 wrote:
> >
> >
> -Original Message-
> From: Kim Phillips [mailto:kim.phill...@linaro.org]
> Sent: Friday, October 11, 2013 6:17 PM
> To: Wood Scott-B07421
> Cc: Bhushan Bharat-R65777; Wood Scott-B07421; Yoder Stuart-B08248;
> christoffer.d...@linaro.org; alex.william...@redhat
> I am trying to understand what you are proposing here (example "DEVICE"
> can be handled by "DRIVER1" and "VFIO-PLATFORM-DRIVER"):
> - By default drv->explicit_bind_only will be clear in all drivers.
> - By default device->explicit_bind_only will also be clear for all
> devices.
> - On boot, m
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, October 09, 2013 2:22 PM
> To: Yoder Stuart-B08248
> Cc: Wood Scott-B07421; Kim Phillips; Christoffer Dall; Alex Williamson;
> linux-ker...@vger.kernel.org; a.mota...@virtualopensystems.com;
> ag...
Have been thinking about this issue some more. As Scott mentioned,
'wildcard' matching for a driver can be fairly done in the platform
bus driver. We could add a new flag to the platform driver struct:
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 4f8bef3..4d6cf14 100644
-
.@suse.de;
> Yoder Stuart-B08248; Wood Scott-B07421; Sethi Varun-B16395; Bhushan
> Bharat-R65777; peter.mayd...@linaro.org; santosh.shu...@linaro.org;
> kvm@vger.kernel.org
> Subject: Re: RFC: (re-)binding the VFIO platform driver to a platform
> device
>
> On Tue, Oct 01, 20
> -Original Message-
> From: Antonios Motakis [mailto:a.mota...@virtualopensystems.com]
> Sent: Wednesday, October 02, 2013 6:14 AM
> To: Yoder Stuart-B08248
> Cc: Alex Williamson; kvm...@lists.cs.columbia.edu; iommu@lists.linux-
> foundation.org; linux-samsung-...@vg
> -Original Message-
> From: Antonios Motakis [mailto:a.mota...@virtualopensystems.com]
> Sent: Wednesday, October 02, 2013 6:22 AM
> To: Yoder Stuart-B08248
> Cc: Alex Williamson; kvm-arm; Linux IOMMU; Linux Samsung SOC; KVM devel
> mailing list; Alexander Graf;
> Antonios Motakis wrote
> > Alex Williamson wrote:
> > I notice all the open firmware calls here and I'm curious,
> > will all platform devices be making use of open firmware?
> > I don't know if this is synonymous with device tree or not.
> > Thanks,
>
> This VFIO driver will support only device
> > static int __init vfio_iommu_type1_init(void)
> > {
> > - if (!iommu_present(&pci_bus_type))
> > +#ifdef CONFIG_PCI
> > + if (iommu_present(&pci_bus_type)) {
> > + iommu_bus_type = &pci_bus_type;
> > + /* For PCI targets, IOMMU_CAP_INTR_REMAP is required */
> > +
> +MODULE_VERSION(DRIVER_VERSION);
> +MODULE_LICENSE("GPL v2");
> +MODULE_AUTHOR(DRIVER_AUTHOR);
> +MODULE_DESCRIPTION(DRIVER_DESC);
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index 284ff24..1e4bef2 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio
...@lists.linux-foundation.org;
> linux-samsung-...@vger.kernel.org; kvm@vger.kernel.org; ag...@suse.de;
> Yoder Stuart-B08248; Antonios Motakis
> Subject: [RFC 0/3] WIP VFIO for device tree devices on Arndale
I think we should call this infrastructure vfio for "platform
devices"
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Wednesday, July 17, 2013 10:21 AM
> To: Yoder Stuart-B08248
> Cc: Wood Scott-B07421; Bhushan Bharat-R65777; kvm@vger.kernel.org;
> kvm-...@vger.kernel.org; Gleb Natapov
> Subject: Re: [PAT
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Wednesday, July 17, 2013 7:19 AM
> To: Gleb Natapov
> Cc: Wood Scott-B07421; Bhushan Bharat-R65777; kvm@vger.kernel.org;
> kvm-...@vger.kernel.org; Yoder
> Stuart-B08248; Bhushan Bharat
> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, July 16, 2013 5:01 PM
> To: Yoder Stuart-B08248
> Cc: Wood Scott-B07421; Alex Williamson; Alexander Graf; Bhushan
> Bharat-R65777; Sethi Varun-B16395;
> virtualizat...@lists.linux-foundation.org; Ant
(sorry for the delayed response, but I've been on PTO)
> > 1. VFIO_GROUP_GET_DEVICE_FD
> >
> > User space knows by out-of-band means which device it is accessing
> > and will call VFIO_GROUP_GET_DEVICE_FD passing a specific sysfs path
> > to get the device information:
> >
> > fd = ioctl(
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, July 03, 2013 5:32 PM
> To: Yoder Stuart-B08248
> Cc: Alex Williamson; Alexander Graf; Wood Scott-B07421; Bhushan
> Bharat-R65777; Sethi Varun-B16395;
> virtualizat...@lists.linux-foundation.org; Ant
> -Original Message-
> From: Mario Smarduch [mailto:mario.smard...@huawei.com]
> Sent: Thursday, July 04, 2013 9:45 AM
> To: Yoder Stuart-B08248
> Cc: Alex Williamson; Alexander Graf; Wood Scott-B07421; kvm@vger.kernel.org
> list; Bhushan Bharat-R65777;
> kv
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
> -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; kvm@vger.kernel.org list;
> kvm-...@vger.kernel.org
> Subject: Re: PPC: RFC:
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
[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_*_
> -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; Ant
[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
>
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 interrupts to the corresponding
device tree node structure
Version 3 changes
-added "kvm," prefix to hcall properties in device tree
-specified which registers ret and args will end up in
-removed e500-specific comments
KVM_CAP_EXIT_EPAPR_HCALL Capability
A new capability
> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, July 02, 2013 11:56 AM
> To: Yoder Stuart-B08248
> Cc: Alexander Graf; Bhushan Bharat-R65777; Wood Scott-B07421;
> kvm@vger.kernel.org list; kvm-
> p...@vger.kernel.org
> Subject: Re: RFC: proposal
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Tuesday, July 02, 2013 10:23 AM
> To: Yoder Stuart-B08248
> Cc: Bhushan Bharat-R65777; Wood Scott-B07421; kvm@vger.kernel.org list;
> kvm-...@vger.kernel.org
> Subject: Re: RFC: proposal fo
> -Original Message-
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Tuesday, July 02, 2013 9:46 AM
> To: Yoder Stuart-B08248
> Cc: kvm@vger.kernel.org list; Alexander Graf; Bhushan Bharat-R65777;
> a.mota...@virtualopensystems.com;
> virtu
Version 2 changes
-remove advertising via KVM_HC_FEATURES
-define a new exit type (KVM_EXIT_EPAPR_HCALL) for user space
handled hcalls
-advertise KVM_EXIT_EPAPR_HCALL to user space via new capability
flag
-defined device tree properties to advertise the existence
of reset an
Alex,
I'm trying to think through how binding/unbinding of devices will
work with VFIO for platform devices and have a couple of questions
about how vfio-pci works.
When you bind a device to vfio-pci, e.g.:
# echo 1102 0002 > /sys/bus/pci/drivers/vfio-pci/new_id
...I understand that the echo int
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Monday, July 01, 2013 6:01 PM
> To: Yoder Stuart-B08248
> Cc: Bhushan Bharat-R65777; Wood Scott-B07421; kvm@vger.kernel.org list;
> kvm-...@vger.kernel.org
> Subject: Re: RFC: proposal fo
> -Original Message-
> From: Yoder Stuart-B08248
> Sent: Monday, July 01, 2013 5:59 PM
> To: 'Alexander Graf'
> Cc: Bhushan Bharat-R65777; Wood Scott-B07421; kvm@vger.kernel.org list;
> kvm-...@vger.kernel.org
> Subject: RE: RFC: proposa
> -Original Message-
> From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org] On
> Behalf Of Alexander Graf
> Sent: Monday, July 01, 2013 5:14 PM
> To: Yoder Stuart-B08248
> Cc: Bhushan Bharat-R65777; Wood Scott-B07421; kvm@vger.kerne
For the e500 PV platform we need a VM reset and shutdown mechanisms.
Hypercall: KVM_HC_VM_RESET
Description: Requests that the virtual machine be reset. The
hcall takes no arguments. If successful the hcall do
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Monday, July 01, 2013 2:46 PM
> To: Yoder Stuart-B08248
> Cc: Wood Scott-B07421; Bhushan Bharat-R65777; kvm@vger.kernel.org
> Subject: Re: RFC: proposal for VM reset hcall
>
>
>
>
> -Original Message-
> From: Wood Scott-B07421
> Sent: Monday, July 01, 2013 12:32 PM
> To: Yoder Stuart-B08248
> Cc: Wood Scott-B07421; Alexander Graf; Bhushan Bharat-R65777;
> kvm@vger.kernel.org
> Subject: Re: RFC: proposal for VM reset hcall
>
> On 07
> -Original Message-
> From: Wood Scott-B07421
> Sent: Monday, July 01, 2013 11:49 AM
> To: Yoder Stuart-B08248
> Cc: Alexander Graf; Wood Scott-B07421; Bhushan Bharat-R65777;
> kvm@vger.kernel.org
> Subject: Re: RFC: proposal for VM reset hcall
>
> On 07
For the e500 PV platform we need a VM reset mechanisms.
Hypercall: KVM_HC_VM_RESET
Description: Requests that the virtual machine be reset. The
hcall takes no arguments. If successful the hcall does not
return.
Arguments:
r11hcall-token KVM_HC_VM_RESET
Re
> -Original Message-
> From: Joerg Roedel [mailto:j...@8bytes.org]
> Sent: Thursday, April 11, 2013 7:57 AM
> To: Yoder Stuart-B08248
> Cc: Wood Scott-B07421; kvm@vger.kernel.org; qemu-de...@nongnu.org;
> io...@lists.linux-foundation.org;
> ag...@suse.de; Bhushan Bh
> -Original Message-
> From: Yoder Stuart-B08248
> Sent: Tuesday, April 09, 2013 3:36 PM
> To: ag...@suse.de
> Cc: kvm-...@vger.kernel.org; kvm@vger.kernel.org; Yoder Stuart-B08248
> Subject: [PATCH] KVM: PPC: emulate dcbst
>
> From: Stuart Yoder
>
&g
> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, April 05, 2013 5:17 PM
> To: Yoder Stuart-B08248
> Cc: Alex Williamson; Wood Scott-B07421; ag...@suse.de; Bhushan Bharat-R65777;
> Sethi Varun-B16395;
> kvm@vger.kernel.org; qemu-de...@nongnu.o
> -Original Message-
> From: Wood Scott-B07421
> Sent: Thursday, April 04, 2013 5:52 PM
> To: Yoder Stuart-B08248
> Cc: Alex Williamson; Wood Scott-B07421; ag...@suse.de; Bhushan Bharat-R65777;
> Sethi Varun-B16395;
> kvm@vger.kernel.org; qemu-de...@nongnu.o
-v3 updates
-made vfio_pamu_attr a union, added flags
-s/VFIO_PAMU_/VFIO_IOMMU_PAMU_/ for the ioctls to make it more
clear which fd is being operated on
-added flags to vfio_pamu_msi_bank_map/umap
-VFIO_PAMU_GET_MSI_BANK_COUNT now just returns a __u32
not a struct
-fixed some
> > /*
> > * VFIO_PAMU_MAP_MSI_BANK
> > *
> > * Maps the MSI bank at the specified index and iova. User space must
> > * call this ioctl once for each MSI bank (count of banks is returned by
> > * VFIO_IOMMU_GET_MSI_BANK_COUNT).
> > * Caller provides struct vfio_pamu_msi_bank_map with all f
Based on the email thread over the last couple of days, I have
below an more concrete proposal (v2) for new ioctls supporting vfio-pci
on SoCs with the Freescale PAMU.
Example usage is as described by Scott:
count = VFIO_IOMMU_GET_MSI_BANK_COUNT
VFIO_IOMMU_SET_ATTR(ATTR_GEOMETRY)
VFIO_IOMMU_SET_A
Alex,
We are in the process of implementing vfio-pci support for the Freescale
IOMMU (PAMU). It is an aperture/window-based IOMMU and is quite different
than x86, and will involve creating a 'type 2' vfio implementation.
For each device's DMA mappings, PAMU has an overall aperture and a number
o
> -Original Message-
> From: Wood Scott-B07421
> Sent: Thursday, January 24, 2013 12:22 PM
> To: Yoder Stuart-B08248
> Cc: ag...@suse.de; b...@kernel.crashing.org; linuxppc-...@ozlabs.org;
> kvm-...@vger.kernel.org;
> kvm@vger.kernel.org; Yoder Stuart-B08248
>
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Tuesday, July 03, 2012 2:34 PM
> To: Yoder Stuart-B08248
> Cc: kvm-...@vger.kernel.org; kvm@vger.kernel.org
> Subject: Re: [PATCH v12 4/8] KVM: PPC: Add support for ePAPR idle hcall in
> h
> -Original Message-
> From: Wood Scott-B07421
> Sent: Monday, July 02, 2012 12:25 PM
> To: Alexander Graf
> Cc: Yoder Stuart-B08248; kvm-...@vger.kernel.org; kvm@vger.kernel.org; Tabi
> Timur-B04825
> Subject: Re: [PATCH v11 8/8] PPC: Don't use hardco
> -Original Message-
> From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org] On
> Behalf Of Alexander Graf
> Sent: Monday, July 02, 2012 7:18 AM
> To: Yoder Stuart-B08248
> Cc: kvm-...@vger.kernel.org; kvm@vger.kernel.org
> Subject: Re: [PATCH v
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Wednesday, March 07, 2012 5:39 PM
> To: Wood Scott-B07421
> Cc: Yoder Stuart-B08248; kvm-...@vger.kernel.org; kvm@vger.kernel.org
> Subject: Re: [PATCH v9 2/4] KVM: PPC: epapr: Add idle hcal
> >> Hrm. This will return on signal. So if the guest sends an idle hcall,
> >> then user space gets a random signal, we'll continue executing the
> >> guest CPU, getting us out of idle even though the guest didn't expect it,
> >> since the guest
> really wants to get an interrupt after the idle
> -Original Message-
> From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org] On
> Behalf Of
> Alexander Graf
> Sent: Monday, January 09, 2012 8:15 AM
> To: Liu Yu-B13201
> Cc: kvm-...@vger.kernel.org; kvm@vger.kernel.org; ga...@kernel.crashing.org;
> Wood Scott-
> B
Alex Graf, Scott Wood, and I met last week to try to flesh out
some details as to how vfio could work for non-PCI devices,
like we have in embedded systems. This most likely will
require a different kernel driver than vfio-- for now we are
calling it "dtio" (for device tree I/O) as there is no wa
unsubscribe kvm
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
> -Original Message-
> From: Wood Scott-B07421
> Sent: Monday, February 07, 2011 12:52 PM
> To: Alexander Graf
> Cc: Yoder Stuart-B08248; Wood Scott-B07421; kvm-...@vger.kernel.org;
> kvm@vger.kernel.org; qemu-de...@nongnu.org
> Subject: Re: RFC: New API for PP
> -Original Message-
> From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org]
> On Behalf Of Avi Kivity
> Sent: Monday, February 07, 2011 11:14 AM
> To: Alexander Graf
> Cc: Wood Scott-B07421; Yoder Stuart-B08248; kvm-...@vger.kernel.org;
> kvm@
> > A fixed array does mean you wouldn't have to worry about whether qemu
> > supports the more advanced struct format if fields are added -- you
> > can just unconditionally write it, as long as it's backwards
> > compatible. Unless you hit the limit of the pre-determined array
> > size, that is
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Wednesday, February 02, 2011 3:34 PM
> To: Yoder Stuart-B08248
> Cc: kvm-...@vger.kernel.org; kvm@vger.kernel.org; qemu-de...@nongnu.org
> Subject: Re: RFC: New API for PPC for vcpu mmu
Below is a proposal for a new API for PPC to allow KVM clients
to set MMU state in a vcpu.
BookE processors have one or more software managed TLBs and
currently there is no mechanism for Qemu to initialize
or access them. This is needed for normal initialization
as well as debug.
There are 4 API
63 matches
Mail list logo
