From: Matthias <matthias.kannenberg@googlemail.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Cc: "tim@xen.org" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: Please revert / review 077fc1c04d70ef1748ac2daa6622b3320a1a004c
Date: Thu, 19 Jun 2014 03:29:41 +0200 [thread overview]
Message-ID: <CABoYbGoRz_KNi9+2w8r28yGYsrmWQuTi-+Qb8xEgZRA04CjsnA@mail.gmail.com> (raw)
In-Reply-To: <CABoYbGq5qfkSBmoxMhbEkkxEfk4MCiXH+CMjNQMzNWSgTww7-g@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 5086 bytes --]
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!
>>
>>
>>
>
[-- Attachment #1.2: Type: text/html, Size: 6199 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2014-06-19 1:29 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-11 15:44 Please revert / review 077fc1c04d70ef1748ac2daa6622b3320a1a004c Matthias
2014-06-12 1:02 ` Zhang, Yang Z
2014-06-12 9:35 ` Jan Beulich
2014-06-12 13:49 ` Matthias
2014-06-16 7:47 ` Zhang, Yang Z
2014-06-16 8:08 ` Jan Beulich
2014-06-16 13:42 ` Matthias
2014-06-16 14:52 ` Jan Beulich
2014-06-16 15:07 ` Matthias
2014-06-18 7:25 ` Zhang, Yang Z
2014-06-18 22:21 ` Matthias
2014-06-19 1:07 ` Matthias
2014-06-19 1:29 ` Matthias [this message]
2014-06-19 12:25 ` Zhang, Yang Z
2014-06-19 16:22 ` Matthias
2014-06-20 0:20 ` Zhang, Yang Z
2014-06-20 8:22 ` Jan Beulich
2014-06-20 10:07 ` Matthias
2014-06-20 11:18 ` Jan Beulich
2014-06-20 11:27 ` Zhang, Yang Z
2014-06-20 11:24 ` Zhang, Yang Z
2014-06-20 11:28 ` Zhang, Yang Z
2014-06-20 8:17 ` Jan Beulich
2014-06-20 11:26 ` Zhang, Yang Z
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABoYbGoRz_KNi9+2w8r28yGYsrmWQuTi-+Qb8xEgZRA04CjsnA@mail.gmail.com \
--to=matthias.kannenberg@googlemail.com \
--cc=JBeulich@suse.com \
--cc=tim@xen.org \
--cc=xen-devel@lists.xen.org \
--cc=yang.z.zhang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.