Re: [Xen-devel] Create a iSCSI DomU with disks in another DomU running on the same Dom0

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

> > I think we are just swizzling the PFNs with a different MFN when you
> > do the domU -> domX, using two ring protocols. Weird thought as the
> > m2p code has checks WARN_ON(PagePrivate(..)) to catch this sort of
> > thing.
> > 
> > What happens if the dom0/domU are all 3.8 with the persistent grant
> > patches?
> 
> Sorry for the delay, the same error happens when Dom0/DomU is using a
> persistent grants enabled kernel, although I had to backport the
> persistent grants patch to 3.2, because I was unable to get iSCSI
> Enterprise Target dkms working with 3.8. I'm also seeing this messages
> in the DomU that's running the iSCSI target:
> 
> [  511.338845] net_ratelimit: 36 callbacks suppressed
> [  511.338851] net eth0: rx->offset: 0, size: 4294967295

-1 ?! I saw this somewhere with 9000 MTUs.

> [  512.288282] net eth0: rx->offset: 0, size: 4294967295
> [  512.525639] net eth0: rx->offset: 0, size: 4294967295
> [  512.800729] net eth0: rx->offset: 0, size: 4294967295

But wow. It is just all over.

Could you instrument the M2P code to print out the PFN/MFN
values are they are being altered (along with __builtin_func(1) to
get an idea who is doing it). Perhaps that will shed light whether
my theory (that we are overwritting the MFNs) is truly happening.
It does not help that it ends up using multicalls - so it might be
that they are being done both in bathess - so there are multiple
MFN updates. Perhaps the multicalls have two or more changes to the
same MFN?

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