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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

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


Wei.

> Roger.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users