|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen-unstable 4.8: HVM domain_crash called from emulate.c:144 RIP: c000:[<000000000000336a>]
Wednesday, June 15, 2016, 12:12:37 PM, you wrote:
>>>> On 15.06.16 at 11:38, <linux@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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 )
> {
Unfortunately still crashes.
--
Sander
>>>> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |