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@googlemail.com>:

> 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@googlemail.com>:
>
> 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!
>>
>>
>>
>