Xen devel - Jan 2010 - trouble with the new mmap-batch interface

Hi all,

I''m having some trouble with the new mmap-batch ioctl. With ioemu
revision a0066d "use new (replacement) mmap-batch ioctl" applied, my
HVM domain dies as soon as it is unpaused. The first suspicious line
in xm dmesg is

(XEN) HVM3:  - REP INSB across page boundaries ... Bad value at 0x005ffffc: saw
00000000 e
(XEN) HVM3: xpected ff000000
(XEN) HVM3: Bad value at 0x00601000: saw 00000000 expected 000000ff
(XEN) HVM3: failed

and the qemu log ends at
cirrus vga map change while on lfb mode

If I revert to ioemu 3b531c "passthrough: fix a printf format
specifier" then the INSB test passes and the domain runs fine.

I''m running 32-bit 2.6.18.8 dom0 (984:0bec29c94ce9), 32-bit HVM guest,
and 64-bit xen (Tue Jan 19 15:44:54 2010 +0000 20824:07f95839e431)

It seems unlikely to me that this is actual breakage, but I''ve built
world a couple of times. Before I put printfs everywhere I thought I''d
ask if anyone else had seen this or had any ideas.

Thanks,
Brendan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 20/01/2010 07:02, "Brendan Cully" <brendan@cs.ubc.ca> wrote:
> (XEN) HVM3:  - REP INSB across page boundaries ... Bad value at 0x005ffffc:
> saw 00000000 e
> (XEN) HVM3: xpected ff000000
> (XEN) HVM3: Bad value at 0x00601000: saw 00000000 expected 000000ff
> (XEN) HVM3: failed
Failing during hvmloader early regression tests. You could comment out
hvmloader.c:perform_tests() to see whether this problem is at least somewhat
specific to the test, or whether things are much more generally broken.
> I''m running 32-bit 2.6.18.8 dom0 (984:0bec29c94ce9), 32-bit HVM
guest,
> and 64-bit xen (Tue Jan 19 15:44:54 2010 +0000 20824:07f95839e431)
It''s working for me, albeit running 64-bit 2.6.18.8 dom0.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tuesday, 19 January 2010 at 23:02, Brendan Cully
wrote:
> Hi all,
> 
> I''m having some trouble with the new mmap-batch ioctl. With ioemu
> revision a0066d "use new (replacement) mmap-batch ioctl" applied,
my
> HVM domain dies as soon as it is unpaused. The first suspicious line
> in xm dmesg is
> 
> (XEN) HVM3:  - REP INSB across page boundaries ... Bad value at 0x005ffffc:
saw 00000000 e
> (XEN) HVM3: xpected ff000000
> (XEN) HVM3: Bad value at 0x00601000: saw 00000000 expected 000000ff
> (XEN) HVM3: failed
> 
> and the qemu log ends at
> cirrus vga map change while on lfb mode
> 
> If I revert to ioemu 3b531c "passthrough: fix a printf format
> specifier" then the INSB test passes and the domain runs fine.
> 
> I''m running 32-bit 2.6.18.8 dom0 (984:0bec29c94ce9), 32-bit HVM
guest,
> and 64-bit xen (Tue Jan 19 15:44:54 2010 +0000 20824:07f95839e431)
> 
> It seems unlikely to me that this is actual breakage, but I''ve
built
> world a couple of times. Before I put printfs everywhere I thought
I''d
> ask if anyone else had seen this or had any ideas.
The attached patch fixes ioemu for me.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 20/01/2010 21:38, "Brendan Cully" <brendan@cs.ubc.ca> wrote:
>> It seems unlikely to me that this is actual breakage, but I''ve
built
>> world a couple of times. Before I put printfs everywhere I thought
I''d
>> ask if anyone else had seen this or had any ideas.
> 
> The attached patch fixes ioemu for me.
So the issue is that the kernel only writes back the err array if there was
at least one failure in the batch. Given the alternative is pre-zeroing the
array, shouldn''t we just unconditionally copy back the array, even if
it is
all zeroes?

Jan: Is it in fact a bug, because IOCTL_PRIVCMD_MMAPBATCH is similarly
structured (but legitimately, in that case)?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> Keir Fraser <keir.fraser@eu.citrix.com> 20.01.10 22:54
>>>
>On 20/01/2010 21:38, "Brendan Cully" <brendan@cs.ubc.ca>
wrote:
>
>>> It seems unlikely to me that this is actual breakage, but
I''ve built
>>> world a couple of times. Before I put printfs everywhere I thought
I''d
>>> ask if anyone else had seen this or had any ideas.
>> 
>> The attached patch fixes ioemu for me.
>
>So the issue is that the kernel only writes back the err array if there was
>at least one failure in the batch. Given the alternative is pre-zeroing the
>array, shouldn''t we just unconditionally copy back the array, even
if it is
>all zeroes?
>
>Jan: Is it in fact a bug, because IOCTL_PRIVCMD_MMAPBATCH is similarly
>structured (but legitimately, in that case)?
Generally I intended the caller to zero the array. If that''s not a good
idea, I can certainly put together patches (linux and libxc) that remove
that assumption. If you''d like to leave the assumption in, then c/s
20822
(fixing domain save) will also need another adjustment (using realloc()
inside the loop doesn''t seem very nice anyway - allocating the array
where the other two arrays get allocated would be more consistent).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 21/01/2010 08:38, "Jan Beulich" <JBeulich@novell.com> wrote:
>> Jan: Is it in fact a bug, because IOCTL_PRIVCMD_MMAPBATCH is similarly
>> structured (but legitimately, in that case)?
> 
> Generally I intended the caller to zero the array. If that''s not a
good
> idea, I can certainly put together patches (linux and libxc) that remove
> that assumption.
Well I think it''s a bad idea. I can''t imagine the saved
copy_to_user() is
significantly expensive, and it makes the interface a bit confusing but in a
way that sometimes still works and then sometimes fails. So please make some
patches.
> If you''d like to leave the assumption in, then c/s 20822
> (fixing domain save) will also need another adjustment (using realloc()
> inside the loop doesn''t seem very nice anyway - allocating the
array
> where the other two arrays get allocated would be more consistent).
You can make this consistent in a separate patch, if you like.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 20/01/2010 21:38, "Brendan Cully" <brendan@cs.ubc.ca> wrote:
>> It seems unlikely to me that this is actual breakage, but I''ve
built
>> world a couple of times. Before I put printfs everywhere I thought
I''d
>> ask if anyone else had seen this or had any ideas.
> 
> The attached patch fixes ioemu for me.
Hopefully Jan''s patch to dom0 kernel (now applied to
linux-2.6.18-xen.hg)
should also fix your problem.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thursday, 21 January 2010 at 15:06, Keir Fraser
wrote:
> On 20/01/2010 21:38, "Brendan Cully" <brendan@cs.ubc.ca>
wrote:
> 
> >> It seems unlikely to me that this is actual breakage, but
I''ve built
> >> world a couple of times. Before I put printfs everywhere I thought
I''d
> >> ask if anyone else had seen this or had any ideas.
> > 
> > The attached patch fixes ioemu for me.
> 
> Hopefully Jan''s patch to dom0 kernel (now applied to
linux-2.6.18-xen.hg)
> should also fix your problem.
Yes, with that and the other two patches from me (also applied), HVM
migration is working again.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel