Re: Xen-unstable 4.8: HVM domain_crash called from emulate.c:144 RIP: c000:[<000000000000336a>]

["Jan Beulich" <JBeulich@suse.com>]

>>> On 15.06.16 at 11:38, <linux@eikelenboom.it> wrote:
> Wednesday, June 15, 2016, 10:57:03 AM, you wrote:
> 
>> Wednesday, June 15, 2016, 10:29:37 AM, you wrote:
> 
>>>>>> On 15.06.16 at 01:49, <linux@eikelenboom.it> wrote:
>>>> Just tested latest xen-unstable 4.8 (xen_changeset git:d337764),
>>>> but one of the latest commits seems to have broken boot of HVM guests
>>>> (using qemu-xen) previous build with xen_changeset git:6e908ee worked 
>>>> fine.
> 
>>> Primary suspects would seem to be 67fc274bbe and bfa84968b2,
>>> but (obviously) I didn't see any issues with them in my own
>>> testing, so could you
>>> - instead of doing a full bisect, revert just those two
> 
>> Will give reverting that a shot.
> 
> Reverting bfa84968b2 is sufficient.

Could you give this wild guess a try on top of the tree without the
revert?

--- unstable.orig/xen/arch/x86/hvm/emulate.c
+++ unstable/xen/arch/x86/hvm/emulate.c
@@ -1180,7 +1180,7 @@ static int hvmemul_rep_movs(
         pfec |= PFEC_user_mode;
 
     bytes = PAGE_SIZE - (saddr & ~PAGE_MASK);
-    if ( vio->mmio_access.read_access &&
+    if ( vio->mmio_access.read_access && !vio->mmio_access.write_access &&
          (vio->mmio_gla == (saddr & PAGE_MASK)) &&
          bytes >= bytes_per_rep )
     {


>>> And then of course this domain_crash() could of course be
>>> accompanied by some helpful printk() ...
> 
> Do you have a debug patch of what you are interested in ?

Not yet - basically we should log all of the variables involved in the
condition leading to the domain_crash().

Jan


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