[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] Strange failures of Xen 4.3.1, PVHVM storage VM, iSCSI and Windows+GPLPV VM combination

On Fri, Feb 07, 2014 at 03:24:29PM +0000, Wei Liu wrote:
> (Just go through the whole thread...)
> On Thu, Feb 06, 2014 at 09:22:04AM +0100, Roger Pau Monné wrote:
> [...]
> > 
> > Hello,
> > 
> > This is the same problem I've seen when using a similar setup. The root
> > of the problem is that blkback maps a grant ref to a memory page in
> > Dom0, then this memory page ends up in netback, and when netback tries
> > to issue a GNTTABOP_copy using the mfn of this grant mapped page the
> > operation fails because Xen detects that the mfn passed doesn't belong
> > to the guest.
> > 
> When did this copy happen? From DomU to Dom0? From Dom0 to TGT? I guess
> the latter? Data path from DomU to Dom0 should be handled by blkfront /
> blkback, right?
> > The only way I can think of solving this is that netback detects that
> > the page is not local and somehow we use it's grant ref instead of mfn
> > (this means we would need to store the grant ref somewhere in the page).
> > 
> >From my reading of blkback code, it always uses mapping, right? Could
> there be a path that doesn't use mapping (not necessary now, but also
> consider that in the future)?
> Unless there's a simple way to embed information that marks the page is
> from blkback *and* it is grant, mapped there is nothing netback can
> really do about that. Checking every page would incur penalty so we need
> to be careful about that.

We just need to embed information that says "this page is grant mapped
from other domain". Take special case for blkback is not necessary. 


Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.