On 04/13/2018 07:38 PM, Tamas K Lengyel wrote:
> On Fri, Apr 13, 2018 at 8:44 AM, Razvan Cojocaru
> <rcojoc...@bitdefender.com> 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 dare say at this point you might just be that person :) I looked at
> the patch, one issue with p2m_change_type_range in its current form is
> that it's unclear how it would behave when the range contains remapped
> gfns in an altp2m (either a page that remaps to this range, or a page
> that remaps from the range). According to the current altp2m approach
> I would say the altp2m views should probably just get completely reset
> if there is such a remapping.
Yes, it's all quite complex.
Actually, for one I think I should set p2m->max_mapped_pfn =
hostp2m->max_mapped_pfn; at switch-time rather than at
p2m_init_altp2m_ept() time, for obvious reasons. I wonder if the sane
behaviour here isn't to always copy everything from the active view to
the view we're switching to (whatever "copy everything" means, I'm fuzzy
on this myself).
Also, looking at the code I think that the default_access parameter to
the libxc function we were discussing earlier should simply reach
p2m_init_altp2m_ept() and be assigned to p2m->default_access - that
probably clears the mystery.
You're saying that p2m_change_type_range() should act more like
p2m_altp2m_propagate_change() for p2ms that are not the hostp2m, right?
Xen-devel mailing list