; 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: iommu-boun...@lists.linux
-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-...@vger.kernel.org; kvm
: linux-samsung-...@vger.kernel.org; kvm@vger.kernel.org;
ag...@suse.de; Yoder
Stuart-B08248; io...@lists.linux-foundation.org; Antonios Motakis;
t...@virtualopensystems.com
Subject: [PATCH 2/7] Initial skeleton of VFIO support for Device
Tree based
devices
Platform devices in the Linux
-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.com; linux-
ker
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, matching
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
-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...@suse.de; Sethi Varun-B16395
-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; VirtualOpenSystems Technical
-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-...@vger.kernel.org; kvm
-Original Message-
From: Christoffer Dall [mailto:christoffer.d...@linaro.org]
Sent: Wednesday, October 02, 2013 10:14 AM
To: Alex Williamson
Cc: Kim Phillips; gre...@linuxfoundation.org; linux-
ker...@vger.kernel.org; a.mota...@virtualopensystems.com; ag...@suse.de;
Yoder Stuart
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 */
+
Antonios Motakis wrote
Alex Williamson alex.william...@redhat.com 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
-Original Message-
From: Yoder Stuart-B08248
Sent: Thursday, September 05, 2013 12:51 PM
To: Wood Scott-B07421; Sethi Varun-B16395; Bhushan Bharat-R65777; 'Peter
Maydell'; 'Santosh Shukla'; 'Alex Williamson'; 'Alexander Graf';
'Antonios Motakis'; 'Christoffer Dall'; 'kim.phill
Adding Will...
-Original Message-
From: Sethi Varun-B16395
Sent: Friday, September 06, 2013 11:56 AM
To: Yoder Stuart-B08248; Wood Scott-B07421; Bhushan Bharat-R65777; 'Peter
Maydell'; 'Santosh Shukla'; 'Alex Williamson'; 'Alexander Graf';
'Antonios Motakis'; 'Christoffer Dall
We had a call with those interested and/or working on vfio
for platform devices.
Participants: Scott Wood, Varun Sethi, Bharat Bhushan, Peter Maydell,
Santosh Shukla, Alex Williamson, Alexander Graf,
Antonios Motakis, Christoffer Dall, Kim Phillips,
-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. These devices are on a platform bus, as can
+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.h
@@
-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-R65777
Subject: Re: [PATCH 3/5
-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: [PATCH 3/5] booke: define reset
-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; k...@vger.kernel.org;
kvm-ppc@vger.kernel.org; Yoder
Stuart-B08248; Bhushan Bharat-R65777
Subject: Re: [PATCH 3/5
-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; k...@vger.kernel.org;
kvm-ppc@vger.kernel.org; Gleb Natapov
Subject: Re: [PATCH 3/5] booke: define reset
-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;
kvm-...@vger.kernel.org; virtualizat
-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; Antonios Motakis;
kvm
(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(group,
-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; Antonios Motakis;
kvm
-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; k...@vger.kernel.org
list; Bhushan Bharat-R65777;
kvm-ppc@vger.kernel.org; virtualizat
-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; Antonios Motakis;
k
(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(group,
-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; 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_*_INFO
-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;
kvm
[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
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
-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: proposal for VM reset shutdown
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
[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
-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_*_INFO
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
-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 shutdown
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
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
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
-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;
virtualizat...@lists.linux
-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 for VM reset shutdown hcall (v2
-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 for VM reset shutdown hcall (v2
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
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
-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; k...@vger.kernel.org list;
kvm-ppc@vger.kernel.org
Subject: Re: RFC: proposal for VM reset shutdown hcall
-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;
k...@vger.kernel.org list; kvm-
p...@vger.kernel.org
Subject: Re: RFC: proposal for VM reset shutdown hcall (v2
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
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
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
-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/01/2013 10:56:54 AM, Yoder Stuart
-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/01/2013 12:28:34 PM, Yoder Stuart
-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
Am 01.07.2013 um 19:44 schrieb Yoder
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
-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.kernel.org list;
kvm-...@vger.kernel.org
-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: proposal for VM reset shutdown hcall
-Original
-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 for VM reset shutdown hcall
-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; k...@vger.kernel.org list;
kvm-ppc@vger.kernel.org
-Original Message-
From: Yoder Stuart-B08248
Sent: Monday, July 01, 2013 5:59 PM
To: 'Alexander Graf'
Cc: Bhushan Bharat-R65777; Wood Scott-B07421; k...@vger.kernel.org list;
kvm-ppc@vger.kernel.org
Subject: RE: RFC: proposal for VM reset shutdown hcall
-Original
-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; k...@vger.kernel.org list;
kvm-ppc@vger.kernel.org
Subject: Re: RFC: proposal for VM reset shutdown hcall
-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 Bharat-R65777
Subject: Re: RFC
-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 stuart.yo...@freescale.com
Signed-off
-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.org; io...@lists.linux-foundation.org
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_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 fields set.
-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
-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.org; io...@lists.linux-foundation.org
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
-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
Subject: Re: [PATCH][v2] KVM: PPC
-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-ppc@vger.kernel.org;
k...@vger.kernel.org; Yoder Stuart-B08248
Subject: Re: [PATCH][v2] KVM: PPC
-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 v11 4/8] KVM: PPC: Add
-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 hardcoded opcode for ePAPR hcall
invocation
-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
host kernel
On 03.07.2012
-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-ppc@vger.kernel.org; k...@vger.kernel.org
Subject: Re: [PATCH v11 4/8] KVM: PPC: Add
-Original Message-
From: Wood Scott-B07421
Sent: Monday, July 02, 2012 12:25 PM
To: Alexander Graf
Cc: Yoder Stuart-B08248; kvm-ppc@vger.kernel.org; k...@vger.kernel.org; Tabi
Timur-B04825
Subject: Re: [PATCH v11 8/8] PPC: Don't use hardcoded opcode for ePAPR hcall
invocation
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Tuesday, July 03, 2012 2:34 PM
To: Yoder Stuart-B08248
Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org
Subject: Re: [PATCH v12 4/8] KVM: PPC: Add support for ePAPR idle hcall in
host kernel
On 03.07.2012
-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 hcall support for host
-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-ppc@vger.kernel.org; k...@vger.kernel.org
Subject: Re: [PATCH v9 2/4] KVM: PPC: epapr: Add idle hcall support for host
-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-
B07421;
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 hcall.
-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-ppc@vger.kernel.org; k...@vger.kernel.org; ga...@kernel.crashing.org;
Wood Scott-
B07421;
-Original Message-
From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org] On
Behalf Of
Alexander Graf
Sent: Tuesday, November 22, 2011 2:45 PM
To: Wood Scott-B07421
Cc: Liu Yu-B13201; kvm-ppc@vger.kernel.org
Subject: Re: [PATCH] KVM: PPC: Apply paravirt to
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Tuesday, November 22, 2011 3:28 PM
To: Yoder Stuart-B08248
Cc: Wood Scott-B07421; Liu Yu-B13201; kvm-ppc@vger.kernel.org
Subject: Re: [PATCH] KVM: PPC: Apply paravirt to all vcpu
On 22.11.2011, at 22:11
The magic page hcall API and related data structure fields has the following:
unsigned long magic_page_pa; /* phys addr to map the magic page to */
unsigned long magic_page_ea; /* effect. addr to map the magic page to */
Shouldn't the PA be 64-bits? Or some phys addr type. Not
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 way
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
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. And if
-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@vger.kernel.org; qemu-de
-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 PPC for vcpu mmu access
On Mon, 7
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
-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 access
On 02.02.2011, at 21
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Wednesday, February 02, 2011 3:34 PM
To: Yoder Stuart-B08248
Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org; qemu-de...@nongnu.org
Subject: Re: RFC: New API for PPC for vcpu mmu access
On 02.02.2011, at 21
:38 PM
To: Yoder Stuart-B08248
Cc: kvm-ppc@vger.kernel.org
Subject: Re: kvm ppc timing stats
I don't think the numbers added up like that for us either. We treated
them
as relative data, not absolute.
I don't remember how early/late the timestamps were recorded, but
obviously
they cannot
Hollis,
Am looking at some performance data and want to make sure that
I'm understanding things correctly with your CONFIG_KVM_EXIT_TIMING
stuff. If I reset the timing counters, run a workload
under for a fixed duration (e.g. 30 seconds), and then look
at the exit stats, I should see 30 seconds
-Original Message-
From: kvm-ppc-ow...@vger.kernel.org
[mailto:kvm-ppc-ow...@vger.kernel.org]
On Behalf Of Alexander Graf
Sent: Tuesday, November 09, 2010 12:50 PM
To: Wood Scott-B07421
Cc: Hollis Blanchard; Liu Yu-B13201; kvm-ppc@vger.kernel.org; Jan
Kiszka
Subject: Re: Software
98 matches
Mail list logo
