Xen devel - Jul 2010 - Re: Ping: regressions from post-3.2.3 c/s 17041

On Friday 02 July 2010 12:05:05 Jan Beulich wrote:
> Christoph,
>
> that patch of yours, even though it doesn''t say so, appears to be
a
> plain revert of 3.2''s c/s 16898. Consequently it re-introduces the
> problems fixed by that earlier c/s, in particular the bad behavior of
> the SVM decoder near page boundaries. Presumably that patch,
> never having been part of an official release, has seen very little
> testing, but as it was taken into our post-release SLE10 SP3 code
> base is now apparently causing regressions there.
>
> In order to find a way to better fix the problems you tried to
> address, could you provide as much detail as you can recall/
> reconstruct on what lead you to that patch of yours (the patch
> comment unfortunately was rather terse), and namely what the
> precise problem was that you encountered? In particular I''m
> having trouble connecting the patch to the error messages noted
> in its description - afaics the SVM decoder shouldn''t be used for
> the (generic) HVM MMIO path.
>
> Thanks, Jan
>
> (original mail was Cc-ed to xen-devel, please add this back on your reply)

Following setup did not work on one of our PC-Ware boxes with
a Rev.F Athlon X2 and xen-3.2-testing:

Guest: SLES10 64bit
Memory: 2GB
VCPUs: 2

The guest becomes unresponsive and is using 100% CPU. I tried to assign only 1
VCPU, but the result was the same.
The exact same test did work on a Family10h box.

xm dmesg gets flooded with this repeating two lines:
(XEN) platform.c:1049:d6 handle_mmio: failed to get instruction
(XEN) instrlen.c:252:d6 Cannot read from address 802eb001 (eip 802eb001, mode 
2)

The specific changeset has been nailed down to:
16984:9750ac9b7e8b              bad
16932:d31315b23f28              bad
16907:0016f5a1dd5a              bad

16907 with 16898 reverted       good
16898:784805591fa2              ?       that''s the cause

16888:9733f681d5c5              good
16881:4073b3ded545              good    (3.2.1 release)
16718:f4a57e0474af              good    (3.2.0 release)

Checked following xen-unstable changesets on the same box:

18510:694b7daa353c (current tip)
17575:01aa7c088e98 (SVM: clean up __get_instruction_length_from_list())

Both are working. So it''s only a problem within xen-3.2-testing.

The testing results shown so far mean that c/s 16898 has a dependency
to at least one c/s in xen-unstable prior to 17575 that has *not* been
backported to Xen-3.2-testing.

The issue is described in c/s 17202 (xen-unstable tree):
-----------------------------------------------------------------
description:    SVM: handle page faults in emulated instruction fetches

Deal with failures in hvm_copy_from_guest_virt when fetching
instructions in the various SVM emulation paths. Since we know that
the instruction was fetchable by the hardware, we can usually just
return from the VMEXIT and try again; whatever caused us to fail will
cause the hardware to fail next time and we''ll get the correct exit
code.
-----------------------------------------------------------------

Unfortunately, the SVM emulation code has been rewritten in
c/s 17090 (xen-unstable tree) and not been backported to Xen 3.2.x.
Therefore, the real fix is way more complicated than the diff
from c/s 17202.


Hope, this helps Jan.

Christoph



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


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

>>> On 02.07.10 at 13:24, Christoph Egger
<Christoph.Egger@amd.com> wrote:
> Hope, this helps Jan.
Unfortunately not much, as it still doesn''t allow me to determine what
needs to be fixed without effectively reverting c/s 16898. Unless of
course we can reproduce this in our lab, based on the information
on the box you saw this on. We''ll have to see...

Jan


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

>>> On 02.07.10 at 13:24, Christoph Egger
<Christoph.Egger@amd.com> wrote:
> The testing results shown so far mean that c/s 16898 has a dependency
> to at least one c/s in xen-unstable prior to 17575 that has *not* been
> backported to Xen-3.2-testing.
> 
> The issue is described in c/s 17202 (xen-unstable tree):
> -----------------------------------------------------------------
> description:    SVM: handle page faults in emulated instruction fetches
> 
> Deal with failures in hvm_copy_from_guest_virt when fetching
> instructions in the various SVM emulation paths. Since we know that
> the instruction was fetchable by the hardware, we can usually just
> return from the VMEXIT and try again; whatever caused us to fail will
> cause the hardware to fail next time and we''ll get the correct
exit
> code.
> -----------------------------------------------------------------
> 
> Unfortunately, the SVM emulation code has been rewritten in
> c/s 17090 (xen-unstable tree) and not been backported to Xen 3.2.x.
> Therefore, the real fix is way more complicated than the diff
> from c/s 17202.
Two main things this doesn''t answer:

1) The changes we talk about here don''t (afaics) touch the
handle_mmio() path at all, yet your testing says that this path
is affected.

2) According to the second of the messages
> (XEN) instrlen.c:252:d6 Cannot read from address 802eb001 (eip 802eb001,
mode 2)
the guest is in 16-bit mode. Since 64-bit kernels don''t call 16-bit
BIOS routines, this must be before the kernel even starts. If
however this is BIOS code, the reported instruction pointer looks
rather bogus, and there should presumably not be any talk about
page faults.

Jan


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