>>> On 15.06.16 at 11:38, <li...@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, <li...@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
