Re: Please revert / review 077fc1c04d70ef1748ac2daa6622b3320a1a004c

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:07:12 +0200	[thread overview]
Message-ID: <CABoYbGq5qfkSBmoxMhbEkkxEfk4MCiXH+CMjNQMzNWSgTww7-g@mail.gmail.com> (raw)
In-Reply-To: <CABoYbGpQRKYrp5rEE=rGbs=Xrvbvt4B33QDV9mSHx-GBstWK-Q@mail.gmail.com>

[-- Attachment #1.1: Type: text/plain, Size: 4117 bytes --]

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: 4951 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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