From: Razvan Cojocaru <rcojocaru@bitdefender.com>
To: George Dunlap <dunlapg@umich.edu>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
Tamas K Lengyel <tamas@tklengyel.com>,
Andrew Cooper <Andrew.Cooper3@citrix.com>,
Tim Deegan <tim@xen.org>,
George Dunlap <george.dunlap@citrix.com>,
Jun Nakajima <jun.nakajima@intel.com>,
xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: Weird altp2m behaviour when switching early to a new view
Date: Tue, 17 Apr 2018 13:49:16 +0300 [thread overview]
Message-ID: <359f9be1-b425-7569-d507-97beee8ec69d@bitdefender.com> (raw)
In-Reply-To: <00b52489-51e5-6bc8-ccc2-7b44d2dec107@bitdefender.com>
On 04/17/2018 11:24 AM, Razvan Cojocaru wrote:
> On 04/16/2018 11:21 PM, George Dunlap wrote:
>> On Mon, Apr 16, 2018 at 7:46 PM, Razvan Cojocaru
>> <rcojocaru@bitdefender.com> wrote:
>>> On 04/16/2018 08:47 PM, George Dunlap wrote:
>>>> On 04/13/2018 03:44 PM, Razvan Cojocaru wrote:
>>>>> On 04/11/2018 11:04 AM, Razvan Cojocaru wrote:
>>>>>> Debugging continues.
>>>>>
>>>>> Finally, the attached patch seems to get the display unstuck in my
>>>>> scenario, although for one guest I get:
>>>>>
>>>>> (XEN) d2v0 Unexpected vmexit: reason 49
>>>>> (XEN) domain_crash called from vmx.c:4120
>>>>> (XEN) Domain 2 (vcpu#0) crashed on cpu#1:
>>>>> (XEN) ----[ Xen-4.11-unstable x86_64 debug=y Not tainted ]----
>>>>> (XEN) CPU: 1
>>>>> (XEN) RIP: 0010:[<fffff96000842354>]
>>>>> (XEN) RFLAGS: 0000000000010246 CONTEXT: hvm guest (d2v0)
>>>>> (XEN) rax: fffff88003000000 rbx: fffff900c0083db0 rcx: 00000000aa55aa55
>>>>> (XEN) rdx: fffffa80041bdc41 rsi: fffff900c00c69a0 rdi: 0000000000000001
>>>>> (XEN) rbp: 0000000000000000 rsp: fffff88002ee9ef0 r8: fffffa80041bdc40
>>>>> (XEN) r9: fffff80001810e80 r10: fffffa800342aa70 r11: fffff88002ee9e80
>>>>> (XEN) r12: 0000000000000005 r13: 0000000000000001 r14: fffff900c00c08b0
>>>>> (XEN) r15: 0000000000000001 cr0: 0000000080050031 cr4: 00000000000406f8
>>>>> (XEN) cr3: 00000000ef771000 cr2: fffff900c00c8000
>>>>> (XEN) fsb: 00000000fffde000 gsb: fffff80001810d00 gss: 000007fffffdc000
>>>>> (XEN) ds: 002b es: 002b fs: 0053 gs: 002b ss: 0018 cs: 0010
>>>>>
>>>>> i.e. EXIT_REASON_EPT_MISCONFIG - so not of the woods yet. I am hoping
>>>>> somebody more familiar with the code can point to a more elegant
>>>>> solution if one exists.
>>>>
>>>> I think I have an idea what's going on, but it's complicated. :-)
>>>>
>>>> Basically, the logdirty functionality isn't simple, and needs careful
>>>> thought on how to integrate it. I'll write some more tomorrow, and see
>>>> if I can come up with a solution.
>>>
>>> I think I know why this happens for the one guest - the other guests
>>> start at a certain resolution display-wise and stay that way until shutdown.
>>>
>>> This particular guest starts with a larger screen, then goes to roughly
>>> 2/3rds of it, then tries to go back to the initial larger one - at which
>>> point the above happens. I assume this corresponds to some pages being
>>> removed and/or added. I'll test this theory more tomorrow - if it's
>>> correct I should be able to reproduce the crash (with the patch) by
>>> simply resetting the screen resolution (increasing it).
>>
>> The trick is that p2m_change_type doesn't actually iterate over the
>> entire p2m range, individually changing entries as it goes. Instead
>> it misconfigures the entries at the top-level, which causes the kinds
>> of faults shown above. As it gets faults for each entry, it checks
>> the current type, the logdirty ranges, and the global logdirty bit to
>> determine what the new types should be.
>>
>> Your patch makes it so that all the altp2ms now get the
>> misconfiguration when the logdirty range is changed; but clearly
>> handling the misconfiguration isn't integrated properly with the
>> altp2m system yet. Doing it right may take some thought.
>
> FWIW, the attached patch has solved the misconfig-related domain crash
> for me (though I'm very likely missing some subtleties). It all seems to
> work as expected when enabling altp2m and switching early to a new view.
> However, now I have domUs with a frozen display when I disconnect the
> introspection application (that is, after I switch back to the default
> view and disable altp2m on the domain).
The for() loop in the previous patch is unnecessary, so here's a new
(cleaner) patch. I can't get the guest to freeze the display when
detaching anymore - unrelated to the for() - (so it might have been
something else in my setup), but I'll watch for it in the following days.
Hopefully this is either a reasonable fix or a basis for one.
Thanks,
Razvan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2018-04-17 10:49 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-08 20:38 Weird altp2m behaviour when switching early to a new view Razvan Cojocaru
2018-04-09 14:12 ` George Dunlap
2018-04-11 6:39 ` Razvan Cojocaru
2018-04-11 8:04 ` Razvan Cojocaru
2018-04-12 16:15 ` Razvan Cojocaru
2018-04-13 14:44 ` Razvan Cojocaru
2018-04-13 16:38 ` Tamas K Lengyel
2018-04-13 17:04 ` Razvan Cojocaru
2018-04-16 17:47 ` George Dunlap
2018-04-16 18:46 ` Razvan Cojocaru
2018-04-16 20:21 ` George Dunlap
2018-04-17 7:24 ` Razvan Cojocaru
2018-04-17 8:24 ` Razvan Cojocaru
2018-04-17 10:49 ` Razvan Cojocaru [this message]
2018-04-17 10:50 ` Razvan Cojocaru
2018-04-17 13:53 ` George Dunlap
2018-04-17 14:21 ` Razvan Cojocaru
2018-04-17 14:58 ` George Dunlap
2018-04-17 15:13 ` Razvan Cojocaru
2018-04-17 17:07 ` Tamas K Lengyel
2018-04-18 8:20 ` Razvan Cojocaru
2018-04-18 10:45 ` George Dunlap
2018-04-18 10:49 ` Razvan Cojocaru
2018-04-11 20:17 ` Tamas K Lengyel
2018-04-12 7:19 ` Razvan Cojocaru
2018-04-09 15:40 ` Alexey G
2018-10-02 16:29 Сергей
2018-10-02 17:59 ` Razvan Cojocaru
2018-10-03 10:56 ` Сергей
2018-10-03 11:02 ` Razvan Cojocaru
2018-10-04 9:17 ` Razvan Cojocaru
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=359f9be1-b425-7569-d507-97beee8ec69d@bitdefender.com \
--to=rcojocaru@bitdefender.com \
--cc=Andrew.Cooper3@citrix.com \
--cc=dunlapg@umich.edu \
--cc=george.dunlap@citrix.com \
--cc=jun.nakajima@intel.com \
--cc=kevin.tian@intel.com \
--cc=tamas@tklengyel.com \
--cc=tim@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.