On Thu, Oct 03, 2013 at 08:21:20AM +1000, Benjamin Herrenschmidt wrote:
On Wed, 2013-10-02 at 17:37 +0300, Gleb Natapov wrote:
On Wed, Oct 02, 2013 at 04:33:18PM +0200, Paolo Bonzini wrote:
Il 02/10/2013 16:08, Alexander Graf ha scritto:
The hwrng is accessible by host userspace via
On Thu, Oct 03, 2013 at 08:07:22AM +1000, Benjamin Herrenschmidt wrote:
On Wed, 2013-10-02 at 13:02 +0300, Gleb Natapov wrote:
Yes, I alluded to it in my email to Paul and Paolo asked also. How this
interface is disabled? Also hwrnd is MMIO in a host why guest needs to
use hypercall
On Thu, Oct 03, 2013 at 08:06:30PM +1000, Paul Mackerras wrote:
On Thu, Oct 03, 2013 at 08:48:03AM +0300, Gleb Natapov wrote:
On Thu, Oct 03, 2013 at 08:45:42AM +1000, Paul Mackerras wrote:
On Wed, Oct 02, 2013 at 04:36:05PM +0200, Alexander Graf wrote:
On 02.10.2013, at 16:33
On Wed, Oct 02, 2013 at 11:50:50AM +0200, Alexander Graf wrote:
On 02.10.2013, at 11:11, Alexander Graf wrote:
On 02.10.2013, at 11:06, Benjamin Herrenschmidt wrote:
On Wed, 2013-10-02 at 10:46 +0200, Paolo Bonzini wrote:
Thanks. Any chance you can give some numbers of a
On Wed, Oct 02, 2013 at 11:57:55PM +1000, Michael Ellerman wrote:
On Wed, 2013-10-02 at 13:02 +0300, Gleb Natapov wrote:
On Wed, Oct 02, 2013 at 11:50:50AM +0200, Alexander Graf wrote:
On 02.10.2013, at 11:11, Alexander Graf wrote:
So how do you solve live migration between
On Wed, Oct 02, 2013 at 04:33:18PM +0200, Paolo Bonzini wrote:
Il 02/10/2013 16:08, Alexander Graf ha scritto:
The hwrng is accessible by host userspace via /dev/mem.
A guest should live on the same permission level as a user space
application. If you run QEMU as UID 1000 without access
On Thu, Oct 03, 2013 at 08:02:20AM +1000, Benjamin Herrenschmidt wrote:
On Wed, 2013-10-02 at 13:02 +0300, Gleb Natapov wrote:
Yes, I alluded to it in my email to Paul and Paolo asked also. How this
interface is disabled? Also hwrnd is MMIO in a host why guest needs to
use hypercall
On Thu, Oct 03, 2013 at 08:45:42AM +1000, Paul Mackerras wrote:
On Wed, Oct 02, 2013 at 04:36:05PM +0200, Alexander Graf wrote:
On 02.10.2013, at 16:33, Paolo Bonzini wrote:
Il 02/10/2013 16:08, Alexander Graf ha scritto:
The hwrng is accessible by host userspace via /dev/mem.
On Tue, Oct 01, 2013 at 06:34:26PM +1000, Michael Ellerman wrote:
On Thu, Sep 26, 2013 at 11:06:59AM +0200, Paolo Bonzini wrote:
Il 26/09/2013 08:31, Michael Ellerman ha scritto:
Some powernv systems include a hwrng. Guests can access it via the
H_RANDOM hcall.
Is there any reason to
On Tue, Oct 01, 2013 at 07:23:20PM +1000, Paul Mackerras wrote:
On Tue, Oct 01, 2013 at 11:39:08AM +0300, Gleb Natapov wrote:
On Tue, Oct 01, 2013 at 06:34:26PM +1000, Michael Ellerman wrote:
On Thu, Sep 26, 2013 at 11:06:59AM +0200, Paolo Bonzini wrote:
Il 26/09/2013 08:31, Michael
On Sat, Sep 28, 2013 at 09:06:47PM +0530, Aneesh Kumar K.V wrote:
Paolo Bonzini pbonz...@redhat.com writes:
Il 27/09/2013 15:13, Aneesh Kumar K.V ha scritto:
Alexander Graf ag...@suse.de writes:
On 27.09.2013, at 12:03, Aneesh Kumar K.V wrote:
From: Aneesh Kumar K.V
On Sun, Sep 29, 2013 at 08:35:16PM +0530, Aneesh Kumar K.V wrote:
Gleb Natapov g...@redhat.com writes:
On Sat, Sep 28, 2013 at 09:06:47PM +0530, Aneesh Kumar K.V wrote:
Paolo Bonzini pbonz...@redhat.com writes:
Il 27/09/2013 15:13, Aneesh Kumar K.V ha scritto:
Alexander Graf ag
On Fri, Sep 06, 2013 at 08:40:26PM +1000, Alexey Kardashevskiy wrote:
This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT
and H_STUFF_TCE requests targeted an IOMMU TCE table without passing
them to user space which saves time on switching to user space and back.
Both real
On Fri, Sep 06, 2013 at 09:38:21AM +1000, Alexey Kardashevskiy wrote:
On 09/06/2013 04:10 AM, Gleb Natapov wrote:
On Wed, Sep 04, 2013 at 02:01:28AM +1000, Alexey Kardashevskiy wrote:
On 09/03/2013 08:53 PM, Gleb Natapov wrote:
On Mon, Sep 02, 2013 at 01:14:29PM +1000, Alexey Kardashevskiy
On Thu, Sep 05, 2013 at 02:05:09PM +1000, Benjamin Herrenschmidt wrote:
On Tue, 2013-09-03 at 13:53 +0300, Gleb Natapov wrote:
Or supporting all IOMMU links (and leaving emulated stuff as is) in on
device is the last thing I have to do and then you'll ack the patch?
I am concerned
On Wed, Sep 04, 2013 at 02:01:28AM +1000, Alexey Kardashevskiy wrote:
On 09/03/2013 08:53 PM, Gleb Natapov wrote:
On Mon, Sep 02, 2013 at 01:14:29PM +1000, Alexey Kardashevskiy wrote:
On 09/01/2013 10:06 PM, Gleb Natapov wrote:
On Wed, Aug 28, 2013 at 06:50:41PM +1000, Alexey Kardashevskiy
On Mon, Sep 02, 2013 at 01:14:29PM +1000, Alexey Kardashevskiy wrote:
On 09/01/2013 10:06 PM, Gleb Natapov wrote:
On Wed, Aug 28, 2013 at 06:50:41PM +1000, Alexey Kardashevskiy wrote:
This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT
and H_STUFF_TCE requests targeted
On Wed, Aug 28, 2013 at 06:37:41PM +1000, Alexey Kardashevskiy wrote:
This reserves a capability number for upcoming support
of VFIO-IOMMU DMA operations in real mode.
This reserves a number for a new SPAPR TCE IOMMU KVM device
which is going to manage lifetime of SPAPR TCE IOMMU object.
On Sun, Sep 01, 2013 at 09:39:23PM +1000, Alexey Kardashevskiy wrote:
On 09/01/2013 09:27 PM, Gleb Natapov wrote:
On Wed, Aug 28, 2013 at 06:37:41PM +1000, Alexey Kardashevskiy wrote:
This reserves a capability number for upcoming support
of VFIO-IOMMU DMA operations in real mode
On Wed, Aug 28, 2013 at 06:50:41PM +1000, Alexey Kardashevskiy wrote:
This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT
and H_STUFF_TCE requests targeted an IOMMU TCE table without passing
them to user space which saves time on switching to user space and back.
Both real
On Fri, Aug 30, 2013 at 08:26:54PM +1000, Alexey Kardashevskiy wrote:
On 08/28/2013 06:37 PM, Alexey Kardashevskiy wrote:
This accelerates VFIO DMA operations on POWER by moving them
into kernel.
This depends on VFIO external API patch which is on its way to upstream.
Changes:
v9:
On Wed, Aug 28, 2013 at 11:26:31AM +1000, Benjamin Herrenschmidt wrote:
On Wed, 2013-08-28 at 10:51 +1000, Alexey Kardashevskiy wrote:
The ioctl I made up is basically a copy of KVM_CREATE_SPAPR_TCE which does
the same thing for emulated devices and it is there for quite a while but
it is
On Tue, Aug 27, 2013 at 02:19:58PM +1000, Benjamin Herrenschmidt wrote:
On Mon, 2013-08-26 at 15:37 +0300, Gleb Natapov wrote:
Gleb, any chance you can put this (and the next one) into a tree to
lock in the numbers ?
Applied it. Sorry for slow response, was on vocation and still go
On Tue, Aug 27, 2013 at 02:22:42PM +1000, Benjamin Herrenschmidt wrote:
On Tue, 2013-08-27 at 14:19 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2013-08-26 at 15:37 +0300, Gleb Natapov wrote:
Gleb, any chance you can put this (and the next one) into a tree to
lock in the numbers
On Thu, Aug 15, 2013 at 05:49:26PM +1000, Alexey Kardashevskiy wrote:
This is to reserve a capablity number for upcoming support
of VFIO-IOMMU DMA operations in real mode.
The last ioctl in the group which KVM_CREATE_SPAPR_TCE_IOMMU is added to
is 0xac, the next two numbers are taken - 0xad
On Tue, Aug 27, 2013 at 06:42:18PM +1000, Alexey Kardashevskiy wrote:
On 08/27/2013 05:56 PM, Gleb Natapov wrote:
On Thu, Aug 15, 2013 at 05:49:26PM +1000, Alexey Kardashevskiy wrote:
This is to reserve a capablity number for upcoming support
of VFIO-IOMMU DMA operations in real mode
On Sat, Aug 24, 2013 at 10:14:06PM +0200, Yann Droneaud wrote:
Hi,
Following a patchset asking to change calls to get_unused_flag() [1]
to use O_CLOEXEC, Alex Williamson [2][3] decided to change VFIO
to use the flag.
Since it's a related subsystem to KVM, using O_CLOEXEC for
file
On Wed, Aug 14, 2013 at 10:51:14AM +1000, Benjamin Herrenschmidt wrote:
On Thu, 2013-08-01 at 14:44 +1000, Alexey Kardashevskiy wrote:
This is to reserve a capablity number for upcoming support
of H_PUT_TCE_INDIRECT and H_STUFF_TCE pseries hypercalls
which support mulptiple DMA map/unmap
On Wed, Jul 24, 2013 at 03:32:49PM -0500, Scott Wood wrote:
On 07/24/2013 04:39:59 AM, Alexander Graf wrote:
On 24.07.2013, at 11:35, Gleb Natapov wrote:
On Wed, Jul 24, 2013 at 11:21:11AM +0200, Alexander Graf wrote:
Are not we going to use page_is_ram() from
e500_shadow_mas2_attrib
On Thu, Jul 25, 2013 at 06:07:55PM +0200, Alexander Graf wrote:
On 25.07.2013, at 10:50, Gleb Natapov wrote:
On Wed, Jul 24, 2013 at 03:32:49PM -0500, Scott Wood wrote:
On 07/24/2013 04:39:59 AM, Alexander Graf wrote:
On 24.07.2013, at 11:35, Gleb Natapov wrote:
On Wed, Jul 24
On Fri, Mar 22, 2013 at 02:35:50PM +1100, Stephen Rothwell wrote:
Fixes these build error when CONFIG_KVM is not defined:
In file included from arch/powerpc/include/asm/kvm_ppc.h:33:0,
from arch/powerpc/kernel/setup_64.c:67:
arch/powerpc/include/asm/kvm_book3s.h:65:20:
31 matches
Mail list logo
