Xen project Mailing List

On Wed, Jun 24, 2015 at 12:43 PM, Ed White <edmund.h.white@xxxxxxxxx> wrote:

On 06/24/2015 06:37 AM, Razvan Cojocaru wrote:
> On 06/24/2015 04:32 PM, Lengyel, Tamas wrote:
>>
>>
>> On Wed, Jun 24, 2015 at 1:39 AM, Razvan Cojocaru
>> <rcojocaru@xxxxxxxxxxxxxxx <mailto:rcojocaru@xxxxxxxxxxxxxxx>> wrote:
>>
>> On 06/24/2015 12:27 AM, Lengyel, Tamas wrote:
>> > I've extended xen-access to exercise this new feature taking into
>> > account some of the current limitations. Using the altp2m_write|exec
>> > options we create a duplicate view of the default hostp2m, and instead
>> > of relaxing the mem_access permissions when we encounter a violation, we
>> > swap the view on the violating vCPU while also enabling MTF
>> > singlestepping. When the singlestep event fires, we use the response to
>> > that event to swap the view back to the restricted altp2m view.
>>
>> That's certainly very interesting. I wonder what the benefits are in
>> this case over emulating the fault-causing instruction (other than
>> obviously not going through the emulator)? The altp2m method would
>> certainly be slower, since you need more round-trips from userspace to
>> the hypervisor (the EPT vm_event handling + the singlestep event,
>> whereas with emulation you just reply to the original vm_event).
>>
>>
>> Regards,
>> Razvan
>>
>>
>> Certainly, this is pretty slow right now, especially for the altp2m_exec
>> case. However, sometimes you simply cannot emulate. For example if you
>> write breakpoints into target locations, the original instruction has
>> been overwritten with 0xCC. If you have a duplicate of the page without
>> the breakpoint, this is an easy way to make the guest fetch the original
>> instruction. Of course, if you extend the emulation routine where you
>> can provide the instruction to emulate, instead of it being fetched from
>> guest memory, that would be equally useful ;)
>
> Makes sense, thanks for the explanation! Sure, sending back the
> instruction to emulate could be something to consider for the future.
>
>
> Thanks,
> Razvan
>

One thing I'd add is that what Tamas has done provides a valuable test that
the cross-domain functionality works, even if it might not be a recommended
design pattern. Our primary use case at Intel is intra-domain, and there
the advantages of avoiding many exits are clear.

Also, even cross-domain usage allows for different views of, and levels of
access to, memory concurrently on different vcpus.

Ed

Hi Ed,

I tried the system using memsharing and I collected the following crash log. In this test I ran memsharing on all pages of the domain before activating altp2m and creating the view. Afterwards I used my updated xen-access to create a copy of this p2m with only R/X permissions. The idea would be that the altp2m view remains completely shared, while the hostp2m would be able to do its CoW propagation as the domain is executing.

(XEN) mm locking order violation: 278 > 239
(XEN) Xen BUG at mm-locks.h:68
(XEN) ----[ Xen-4.6-unstable x86_64 debug=y Tainted:    C ]----
(XEN) CPU:    2
(XEN) RIP:    e008:[<ffff82d0801f8768>] p2m_altp2m_propagate_change+0x85/0x4a9
(XEN) RFLAGS: 0000000000010282   CONTEXT: hypervisor (d6v0)
(XEN) rax: 0000000000000000   rbx: 0000000000000000   rcx: 0000000000000000
(XEN) rdx: ffff8302163a8000   rsi: 000000000000000a   rdi: ffff82d0802a069c
(XEN) rbp: ffff8302163afa68   rsp: ffff8302163af9e8   r8: ffff83021c000000
(XEN) r9: 0000000000000003   r10: 00000000000000ef   r11: 0000000000000003
(XEN) r12: ffff83010cc51820   r13: 0000000000000000   r14: ffff830158d90000
(XEN) r15: 0000000000025697   cr0: 0000000080050033   cr4: 00000000001526f0
(XEN) cr3: 00000000dbba3000   cr2: 00000000778c9714
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff8302163af9e8:
(XEN)    ffff8302163af9f8 00000000803180f8 000000000000000c ffff82d0801892ee
(XEN)    ffff82d0801fb4d1 ffff83010cc51de0 000000000008ff49 ffff82d08012f86a
(XEN)    ffff83010cc51820 ffff83010cc51820 0000000000000000 0000000000000000
(XEN)    ffff83010cc51820 0000000000000000 ffff8300dbb334b8 ffff8302163afa00
(XEN)    ffff8302163afb18 ffff82d0801fd549 0000000500000009 ffff830200000001
(XEN)    0000000000000001 ffff830158d90000 0000000000000002 000000000008ff49
(XEN)    0000000000025697 000000000000000c ffff8302163afae8 80c000008ff49175
(XEN)    80c00000d0a97175 01ff83010cc51820 0000000000000097 ffff8300dbb33000
(XEN)    ffff8302163afb78 000000000008ff49 0000000000000000 0000000000000001
(XEN)    0000000000025697 ffff83010cc51820 ffff8302163afb38 ffff82d0801fd644
(XEN)    ffffffffffffffff 00000000000d0a97 ffff8302163afb98 ffff82d0801f23c5
(XEN)    ffff830158d90000 000000000cc51820 ffff830158d90000 000000000000000c
(XEN)    000000000008ff49 ffff83010cc51820 0000000000025697 00000000000d0a97
(XEN)    000000000008ff49 ffff830158d90000 ffff8302163afbd8 ffff82d0801f45c8
(XEN)    ffff83010cc51820 000000000000000c ffff83008fd41170 000000000008ff49
(XEN)    0000000000025697 ffff82e001a152e0 ffff8302163afc58 ffff82d080205b51
(XEN)    0000000000000009 000000000008ff49 ffff8300d0a97000 ffff83008fd41160
(XEN)    ffff82e001a152f0 ffff82e0011fe920 ffff83010cc51820 0000000c00000000
(XEN)    0000000000025697 0000000000000003 ffff83010cc51820 ffff8302163afd34
(XEN)    0000000000025697 0000000000000000 ffff8302163afca8 ffff82d0801f1f7d
(XEN) Xen call trace:
(XEN)    [<ffff82d0801f8768>] p2m_altp2m_propagate_change+0x85/0x4a9
(XEN)    [<ffff82d0801fd549>] ept_set_entry_sve+0x5fa/0x6e6
(XEN)    [<ffff82d0801fd644>] ept_set_entry+0xf/0x11
(XEN)    [<ffff82d0801f23c5>] p2m_set_entry+0xd4/0x112
(XEN)    [<ffff82d0801f45c8>] set_shared_p2m_entry+0x2d0/0x39b
(XEN)    [<ffff82d080205b51>] __mem_sharing_unshare_page+0x83f/0xbd6
(XEN)    [<ffff82d0801f1f7d>] __get_gfn_type_access+0x224/0x2b0
(XEN)    [<ffff82d0801c6df5>] hvm_hap_nested_page_fault+0x21f/0x795
(XEN)    [<ffff82d0801e86ae>] vmx_vmexit_handler+0x1764/0x1af3
(XEN)    [<ffff82d0801ee891>] vmx_asm_vmexit_handler+0x41/0xc0

Re: [Xen-devel] [PATCH v2 00/12] Alternate p2m: support multiple copies of host p2m