I did some furthor testing with a much more recent commit (the 6b4d71d0 Jan suggested earlier from 05-28-14) and with your patch now in the first run everything seemed fine and the domU came up. In the second run however, I got this:
(XEN) svm.c:1439:d1v0 SVM violation gpa 0x000000f2088004, mfn 0xfe5f7, type 5
(XEN) domain_crash called from svm.c:1440
(XEN) Domain 1 (vcpu#0) crashed on cpu#5:
(XEN) ----[ Xen-4.5-unstable x86_64 debug=y Not tainted ]----
(XEN) CPU: 5
(XEN) RIP: 0010:[<fffff8000461e2a6>]
(XEN) RFLAGS: 0000000000000086 CONTEXT: hvm guest
(XEN) rax: ffffffffffd07000 rbx: ffffffffffd07000 rcx: 0000000000000046
(XEN) rdx: fffff6ffffffe838 rsi: 0000000000000000 rdi: 0000000000000000
(XEN) rbp: 0000000000008086 rsp: fffff80000b9cdc0 r8: ffffffffffd07000
(XEN) r9: 0000000000000000 r10: ffffffffffd08000 r11: 0000000fffffffff
(XEN) r12: 0000000000000007 r13: 0000000000000000 r14: 0000000000000007
(XEN) r15: 0000000000000000 cr0: 0000000080050031 cr4: 00000000000006a0
(XEN) cr3: 0000000000187000 cr2: 0000000000000000
(XEN) ds: 002b es: 002b fs: 0053 gs: 002b ss: 0000 cs: 0010
And the domU died. I know this behaviour from the time when I simply reverted your 077 commit and could backtrace this to a series of commits by Jan:
2014-05-02 Jan Beulich x86/NPT: don't walk entire page tables when globally...
2014-05-02 Jan Beulich x86/NPT: don't walk page tables when changing types...
2014-05-02 Jan Beulich x86/EPT: don't walk page tables when changing types...
2014-05-02 Jan Beulich x86/EPT: don't walk entire page tables when globally...
which seem to introduce this behaviour. But since in the first one he mentions something about the log dirty, I assume that this is just a cross dependancy from your log dirty change and would be resolved when my issue with your commit is resolved. But since it happened again I thought it was worth mentioning. It also seems that this issue only occurs when I pass my USB hosts to the domU in addion to the VGA. If I only pass through my vga, it works, but performance seems to be slower (only judged from the time windows needs for login / boot, no dedicated benchmarking).
Maybe it helps..