Xen project Mailing List

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..

2014-06-19 0:21 GMT+02:00 Matthias <matthias.kannenberg@xxxxxxxxxxxxxx>:

Yes, I'm only seeing the BSOD since 077fc1c04d. 0e251a837 is still fine and I can boot my win7 domU.

My bisection process is pretty basic. I have a script which checks out the git staging tree, does a hard reset on the git commit I want to test, applies some custom patches (only changes in vif-nat and mkdeb to put some git build info into the package description so i can use dpkg -I to see what commit the package is on) and does a make world and make debball:

git clone -b staging git://xenbits.xen.org/xen.git xen-unstable-staging
git reset --hard 077fc1c04d70ef1748ac2daa6622b3320a1a004c
// add custom patches
./configureÂ --disable-kernels --disable-stubdom --disable-docs
make -j4 world
make -j4 debball

Then I save the created .deb into a folder for storage / later testing and install it if I want. And with that, I did the usual bisection: use a previous commit if something goes wrong and a later commit if everything works, until I arrived at your commit and wrote the mail..

> Also, the original problem I am trying to fix only related to EPT and VT-d page table sharing. So have you tried to not share them?

Sorry, can you explain this a little more? I don't know how to influence VT-d page table sharing since I don't know much about the deeper mechanics of XEN.

But I am very grateful for your help and therefor would like to help with the testing of your patches.

For my last test I once again used your 077fc1c commit and applied both your first (printing out if log dirty mode is enabled) and second (the latest) patch and it actually workd: no BSOD and the domU came up fine and was usable. Also logs seem fine and there were no VT-d page faults. I attached qemu log and xl dmesg log never the less.

Hope this helps!

Re: [Xen-devel] Please revert / review 077fc1c04d70ef1748ac2daa6622b3320a1a004c