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

[Matthias <matthias.kannenberg@xxxxxxxxxxxxxx>]

Little Update: the above error is caused when I pass one of my OHCI controller to the domU and is not vga passthrough related. Both passing vga and sound card work fine, only ohci (even without ehci) is causing the problem. This might be a resulf of the

libxl: error: libxl_pci.c:990:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:00:12.0

Error I'm seeing when passing these controllers, which previously were handled gracefully and could be ignored, but this is just a guess.. Anyway, I just wanted to clarify that this is an other problem and has nothing to do with the initial one, because this is only caused by the ohci controller and the inital BSOD were independant from passing these controllers to the domU.

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

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!

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel