On 14.04.2015 12:02, Jan Kiszka wrote:
What am I missing here?
Nothing. As I said in the other branch of this thread, Jailhouse is not
affected as it doesn't use the IST. Only KVM is because Linux - in host
mode - requires it for the cases Avi mentioned.
Then what I am missing is correct discus
Hi all,
On 13.04.2015 22:41, Avi Kivity wrote:
On 04/13/2015 08:35 PM, Jan Kiszka wrote:
On 2015-04-13 19:29, Avi Kivity wrote:
On 04/13/2015 10:01 AM, Jan Kiszka wrote:
On 2015-04-07 07:43, Jan Kiszka wrote:
On 2015-04-05 19:12, Valentine Sinitsyn wrote:
Hi Jan,
On 05.04.2015 13:31, Jan
On 07.04.2015 11:23, Jan Kiszka wrote:
On 2015-04-07 08:19, Valentine Sinitsyn wrote:
On 07.04.2015 11:13, Jan Kiszka wrote:
It is, at least 160 cycles with hot caches on an AMD A6-5200 APU, more
towards 600 if they are colder (added some usleep to each loop in the
test).
Great, thanks. Could
On 07.04.2015 11:13, Jan Kiszka wrote:
It is, at least 160 cycles with hot caches on an AMD A6-5200 APU, more
towards 600 if they are colder (added some usleep to each loop in the
test).
Great, thanks. Could you post absolute numbers, i.e how long do A and B
take on your CPU?
A is around 1910
Hi Jan,
On 07.04.2015 10:43, Jan Kiszka wrote:
On 2015-04-05 19:12, Valentine Sinitsyn wrote:
Hi Jan,
On 05.04.2015 13:31, Jan Kiszka wrote:
studying the VM exit logic of Jailhouse, I was wondering when AMD's
vmload/vmsave can be avoided. Jailhouse as well as KVM currently use
Hi Jan,
On 05.04.2015 13:31, Jan Kiszka wrote:
studying the VM exit logic of Jailhouse, I was wondering when AMD's
vmload/vmsave can be avoided. Jailhouse as well as KVM currently use
these instructions unconditionally. However, I think both only need
GS.base, i.e. the per-cpu base address, to b
Hi Paolo,
On 02.09.2014 21:13, Paolo Bonzini wrote:
Patches 3 and 4 fix the interaction between emulator and nested EPT/NPT,
which was reported by Valentine.
I can confirm the initial bug I observed is fixed with these patches
(applied to 3.16.1).
All tests in kvm-unit-test's master also pass
On 02.09.2014 17:21, Paolo Bonzini wrote:
Ugh, there are many bugs and the test is even wrong because the actual
error code should be 0x20006 (error while visiting page tables).
Well, good they were spotted. :-) Haven't looked at the test code
actually, just saw it fails for some reason.
V
On 02.09.2014 15:45, Paolo Bonzini wrote:
In any case, the problem seems specific to _writes_ to the APIC page.
I'm going to write a testcase for that and see if I can reproduce it now.
If you'll need a complete trace, not only CPU 0, please let me know -
I'll upload it as well. It's about 17M c
On 02.09.2014 15:45, Paolo Bonzini wrote:
This *is* different though. I don't see any kvm_inj_exception at all
(with my patch it should be for vector 0xfe).
I've applied the part of your patch, that fixes the uninitialized
exception vector problem, otherwise the lockup will trigger before my
c
On 02.09.2014 14:25, Paolo Bonzini wrote:
I actually meant kvm-unit-tests in order to understand the npt_rsvd
failure. (I had sent a separate message for Jailhouse).
Oops, sorry for misunderstanding. Uploaded it here:
https://www.dropbox.com/s/jp6ohb0ul3d6v4u/npt_rsvd.txt.bz2?dl=0
The environm
On 02.09.2014 12:09, Valentine Sinitsyn wrote:
https://www.dropbox.com/s/slbxmxyg74wh9hv/l1mmio-cpu0.txt.gz?dl=0
Forgot to say: the user space is vanilla QEMU 2.1.0 here.
Valentine
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message
Hi Paolo,
On 01.09.2014 23:04, Paolo Bonzini wrote:
Valentine, can you produce another trace, this time with both kvm and
kvmmmu events enabled?
I was able to make the trace shorter by grepping only what's happening
on a single CPU core (#0):
https://www.dropbox.com/s/slbxmxyg74wh9hv/l1mmio-c
Hi Paolo,
On 01.09.2014 23:41, Paolo Bonzini wrote:
Il 21/08/2014 14:28, Valentine Sinitsyn ha scritto:
BTW npt_rsvd does *not* fail on the machine I've been testing on today.
I can confirm l1mmio test doesn't fail in kvm-unit-test's master
anymore. npt_rsvd still does. I
On 22.08.2014 02:31, Paolo Bonzini wrote:
VMX used the right access size already, the tests are separate for VMX
and SVM.
Sure. So the bug is NPT-specific?
BTW I was likely wrong stating:
if nested page tables maps some GPA to 0xfee0 HPA, it's really mapped to
this HPA,
Looks more like
On 21.08.2014 17:24, Paolo Bonzini wrote:
It seems to work for VMX (see the testcase I just sent). For SVM, can you
check if this test works for you, so that we can work on a simple testcase?
I was able to reproduce the bug with your testcase when I changed APIC
register access size (see below)
Sorry for the chain letters.
On 21.08.2014 18:28, Valentine Sinitsyn wrote:
It passes for SVM, too.
I also looked at SVM tests more closely, and found out that NPT maps the
whole memory-range as cached memory. This can also be a reason for a
false positive in the test (if there is one). Will
On 21.08.2014 18:28, Valentine Sinitsyn wrote:
Also, I tried to use different register values for npt_l1mmio_test() and
npt_l1mmio_check() (like 0xfee00030 and 0xfee00400), but got test passed
Just a small clarification: I made npt_l1mmio_test() to read 0xfee00030
and npt_l1mmio_check() to
On 21.08.2014 17:24, Paolo Bonzini wrote:
It seems to work for VMX (see the testcase I just sent). For SVM, can you
check if this test works for you, so that we can work on a simple testcase?
It passes for SVM, too.
However, npt_rsvd seems to be broken - maybe that is the reason?
Also, I trie
On 21.08.2014 17:04, Paolo Bonzini wrote:
I think it's just a bug. Nobody thought that you'd let L2 access L1's
Sure, this is by no means a common use case. However can be seen as a
flaw that lets the malicious guest to affects others by mapping and
reprogramming APICs or other.
Valentine
--
On 21.08.2014 17:06, Jan Kiszka wrote:
Do you think it would only affect the APIC, or could it cause troubles
with other pass-through devices as well (some PCI BAR e.g.)?
I've skimmed the KVM sources only quickly, but if feel there is nothing
APIC-specific in nested paging code. I.e. access to a
On 21.08.2014 12:28, Valentine Sinitsyn wrote:
KVM seems to work properly (no weird exceptions injected), although my
code now freezes (quick look on the trace suggests it's looping reading
APIC). Not sure whose bug is it, will look further.
Looks like the problem is that if nested page t
Hi all,
On 20.08.2014 14:11, Paolo Bonzini wrote:
Another patch... I will post parts of it separately, if I am right
you should get 0xfe as the vector and a WARN from the gva_to_gpa function.
With the patch like this:
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
inde
On 20.08.2014 14:11, Paolo Bonzini wrote:
Another patch... I will post parts of it separately, if I am right
you should get 0xfe as the vector and a WARN from the gva_to_gpa function.
I confirm the vector is 0xfe, however I see no warnings from
gva_to_gpa() - only from emulate_exception():
[
Hi Paolo,
On 20.08.2014 12:55, Paolo Bonzini wrote:
Is the 0x23c always the same?
No, it's just a garbage - I've seen other values as well (0x80 last time).
Can you try this patch?
Sure. It does print a warning:
[ 2176.722098] [ cut here ]
[ 2176.722118] WARNING: CP
Hi all,
Please excuse me for bringing alive a two-month old thread, but I had
time to investigate the issue a bit only recently.
On 18.06.2014 18:47, Jan Kiszka wrote:
On 2014-06-18 13:36, Valentine Sinitsyn wrote:
If we want to provide useful nested SVM support, this must be feasible.
If
st or guest
PATs (thus no easy way to set memory type if NPT is used and guest PAT
has non-default value). And since svm_set_cr0() explicitly clears CD
(for a good reason, I suppose), there seem to be no way to control
caching from the nested setup altogether.
--
Regards,
Valentine Sinitsyn
(see [1],
Will have a look at it, thanks.
--
Best regards,
Valentine Sinitsyn
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
APIC page accesses in Jailhouse guests
uncacheable?
Thanks in advance.
--
Best regards,
Valentine Sinitsyn
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
29 matches
Mail list logo