> -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'; 'Alexan
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'; 'Alexan
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,
Stuart
> -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: [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; k...@vger.kernel.org;
> kvm-ppc@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; A
(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; A
> -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;
> 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; k...@vger.kernel.org list;
> kvm-ppc@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; A
[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;
> k...@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; k...@vger.kernel.org list;
> kvm-ppc@vger.kernel.org
> Subject: Re: RFC: proposal fo
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
> -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 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; k...@vger.kernel.org list;
> kvm-ppc@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; k...@vger.kernel.or
> -Original Message-
> From: Yoder Stuart-B08248
> Sent: Tuesday, April 09, 2013 3:36 PM
> To: ag...@suse.de
> Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org; Yoder Stuart-B08248
> Subject: [PATCH] KVM: PPC: emulate dcbst
>
> From: Stuart Yoder
>
&g
> -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
>
> -Original Message-
> From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org] On
> Behalf Of Scott Wood
> Sent: Monday, July 16, 2012 12:12 PM
> To: Bhushan Bharat-R65777
> Cc: Wood Scott-B07421; Alexander Graf; qemu-...@nongnu.org;
> kvm-ppc@vger.kernel.org
> Subjec
> -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
> h
> -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 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-ppc@vger.kernel.org; k...@vger.kernel.org
> Subject: Re: [PA
> -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 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-ppc@vger.kernel.org; k...@vger.kernel.org; ga...@kernel.crashing.org;
> Wood Scott-
>
> -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;
> Subject: Re: [PATCH] KVM: PPC: Apply paravirt to all vcpu
>
>
> On 22.11.2
> -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;
> Subject: Re: [PATCH] KVM: PPC: Apply paravirt to all vcpu
>
>
> O
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Monday, October 17, 2011 2:33 PM
> To: Yoder Stuart-B08248
> Cc: kvm-ppc@vger.kernel.org
> Subject: Re: magic page API
>
>
> Am 17.10.2011 um 18:54 schrieb Yoder Stuart-B08248 :
>
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 s
> -Original Message-
> From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org] On
> Behalf Of Kun
> Wang
> Sent: Tuesday, September 13, 2011 5:43 AM
> To: Yoder Stuart-B08248; ag...@suse.de; ji...@pobox.com;
> kvm-ppc@vger.kernel.org
> Subject
> -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-ppc@vger.kernel.org;
> k...@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-ppc@vger.kernel.org;
> k...@
> > 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-ppc@vger.kernel.org; k...@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
> -Original Message-
> From: Avi Kivity [mailto:a...@redhat.com]
> Sent: Tuesday, December 14, 2010 2:49 AM
> To: Hollis Blanchard
> Cc: Yoder Stuart-B08248; Alexander Graf; kvm-ppc@vger.kernel.org
> Subject: Re: re-writing on powerpc
>
> On 12/13/2010 07:17 PM
Avi/Hollis,
Exchanged some emails with Alex on the topic of rewriting on
powerpc KVM-- the current approach taken by Alex's PV patch is
to have a guest Linux paravirt itself, by re-writing certain
instructions.
The downside to this approach (guest side patching) is that every OS
to be run on KVM
> -Original Message-
> From: Hollis Blanchard [mailto:hollis_blanch...@mentor.com]
> Sent: Tuesday, December 07, 2010 6:53 PM
> To: Yoder Stuart-B08248
> Cc: kvm-ppc@vger.kernel.org
> Subject: Re: kvm ppc timing stats
>
> Ah right, makes sense. I guess you'
, December 02, 2010 12: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 e
s.
Will get to the bottom of it, but wanted to make
sure I was not missing something obvious.
Stuart
> -Original Message-
> From: Hollis Blanchard [mailto:hollis_blanch...@mentor.com]
> Sent: Wednesday, December 01, 2010 6:27 PM
> To: Yoder Stuart-B08248
> Cc: kvm-ppc@vger
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
> > > What about using the ehpriv instruction (defined in 2.06)?
> > > We could define a unique "qemu software breakpoint", and the
> > > hypervisor's ehpriv handler will be able to easily distinguish
them.
> > >
> > > On e500v2, this would be an illegal instruction.
> > >
> > > We don't need to wo
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Tuesday, November 09, 2010 9:39 PM
> To: Yoder Stuart-B08248
> Cc: Wood Scott-B07421; Hollis Blanchard; Liu Yu-B13201; kvm-
> p...@vger.kernel.org; Jan Kiszka
> Subject: Re: Software break
> -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: Sof
51 matches
Mail list logo
