On 22/12/2017 0:30, Yuval Shaia wrote:
On Thu, Dec 21, 2017 at 10:46:35PM +0200, Michael S. Tsirkin wrote:
On Thu, Dec 21, 2017 at 05:59:38PM +0200, Marcel Apfelbaum wrote:
On 21/12/2017 16:22, Michael S. Tsirkin wrote:
On Thu, Dec 21, 2017 at 09:27:51AM +0200, Yuval Shaia wrote:
What happe
On Thu, Dec 21, 2017 at 10:46:35PM +0200, Michael S. Tsirkin wrote:
> On Thu, Dec 21, 2017 at 05:59:38PM +0200, Marcel Apfelbaum wrote:
> > On 21/12/2017 16:22, Michael S. Tsirkin wrote:
> > > On Thu, Dec 21, 2017 at 09:27:51AM +0200, Yuval Shaia wrote:
> > > > > >
> > > > > > > What happens if gu
On Thu, Dec 21, 2017 at 05:59:38PM +0200, Marcel Apfelbaum wrote:
> On 21/12/2017 16:22, Michael S. Tsirkin wrote:
> > On Thu, Dec 21, 2017 at 09:27:51AM +0200, Yuval Shaia wrote:
> > > > >
> > > > > > What happens if guest attempts to register all its memory?
> > > > > >
> > > > >
> > > > > The
On 21/12/2017 16:22, Michael S. Tsirkin wrote:
On Thu, Dec 21, 2017 at 09:27:51AM +0200, Yuval Shaia wrote:
What happens if guest attempts to register all its memory?
Then we loose, is not different from bare metal, reg_mr will pin all the RAM.
We need to find a way to communicate to gues
On Thu, Dec 21, 2017 at 09:27:51AM +0200, Yuval Shaia wrote:
> > >
> > > > What happens if guest attempts to register all its memory?
> > > >
> > >
> > > Then we loose, is not different from bare metal, reg_mr will pin all the
> > > RAM.
> >
> > We need to find a way to communicate to guests a
> >
> > > What happens if guest attempts to register all its memory?
> > >
> >
> > Then we loose, is not different from bare metal, reg_mr will pin all the
> > RAM.
>
> We need to find a way to communicate to guests about amount
> of memory they can pin.
dev_caps.max_mr_size is the way device
On Wed, Dec 20, 2017 at 05:07:38PM +0200, Marcel Apfelbaum wrote:
> On 19/12/2017 20:05, Michael S. Tsirkin wrote:
> > On Sun, Dec 17, 2017 at 02:54:52PM +0200, Marcel Apfelbaum wrote:
> > > RFC -> V2:
> > > - Full implementation of the pvrdma device
> > > - Backend is an ibdevice interface, no
On Wed, Dec 20, 2017 at 07:56:47PM +0200, Yuval Shaia wrote:
> On Tue, Dec 19, 2017 at 08:05:18PM +0200, Michael S. Tsirkin wrote:
> > On Sun, Dec 17, 2017 at 02:54:52PM +0200, Marcel Apfelbaum wrote:
> > > RFC -> V2:
> > > - Full implementation of the pvrdma device
> > > - Backend is an ibdevice
On Tue, Dec 19, 2017 at 08:05:18PM +0200, Michael S. Tsirkin wrote:
> On Sun, Dec 17, 2017 at 02:54:52PM +0200, Marcel Apfelbaum wrote:
> > RFC -> V2:
> > - Full implementation of the pvrdma device
> > - Backend is an ibdevice interface, no need for the KDBR module
> >
> > General description
>
On 19/12/2017 20:05, Michael S. Tsirkin wrote:
On Sun, Dec 17, 2017 at 02:54:52PM +0200, Marcel Apfelbaum wrote:
RFC -> V2:
- Full implementation of the pvrdma device
- Backend is an ibdevice interface, no need for the KDBR module
General description
===
PVRDMA is the QEMU i
On Sun, Dec 17, 2017 at 02:54:52PM +0200, Marcel Apfelbaum wrote:
> RFC -> V2:
> - Full implementation of the pvrdma device
> - Backend is an ibdevice interface, no need for the KDBR module
>
> General description
> ===
> PVRDMA is the QEMU implementation of VMware's paravirtuali
RFC -> V2:
- Full implementation of the pvrdma device
- Backend is an ibdevice interface, no need for the KDBR module
General description
===
PVRDMA is the QEMU implementation of VMware's paravirtualized RDMA device.
It works with its Linux Kernel driver AS IS, no need for any s
12 matches
Mail list logo