[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

(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.

Or a simpler solution would be -- don't use this setup. My google-fu
tells me that Linux can be booted from iSCSI so probably a valid setup
would be exporting target from TGT, DomU uses it directly, avoiding
proxying through Dom0. (I could be talking crap as I've never played
with iSCSI).


> Roger.

Xen-users mailing list



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