Peter Chacko wrote:
Did you consider VirtualBox ? Of course VmWare is the market leader
NOW, but if you plan to invest on future open source platforms, You
should choose KVM(which is now Linux native) or XEN.( Its unlikely to
be killed). KVM still lag behind in terms of enterprise-class
Emmanuel Noobadmin wrote:
if by 'put storage on the network' you mean using a block-level
protocol (iSCSI, FCoE, AoE, NBD, DRBD...), then you should by all
means initiate on the host OS (Dom0 in Xen) and present to the VM as
if it were local storage. it's far faster and more stable that way.
Commit 341d9b535b6c simplify reload logic while entry guest mode, it
can avoid unnecessary sync-root if KVM_REQ_MMU_RELOAD and
KVM_REQ_MMU_SYNC both set.
But, it cause a issue that when we handle 'KVM_REQ_TLB_FLUSH', the
root is invalid, it is triggered during my test:
Kernel BUG at
Marcelo Tosatti wrote:
+
+if (is_rsvd_bits_set(vcpu, gpte, PT_PAGE_TABLE_LEVEL))
+break;
BTW, doesnt sync_page also lack reserved bit checking? (unrelated to
this patch).
I think it's not since if EPT is enabled, no unsync page exist, the sync page
path
Marcelo Tosatti wrote:
+if (len != 4) {
+printk(KERN_WARNING ioapic: wrong length %d\n, len);
+return 0;
+}
+
Just remove the printks please, as guests can flood hosts dmesg.
OK, please review this one, thanks, Marcelo!
Subject: [PATCH v3] KVM:
On Mon, Jun 28, 2010 at 05:56:07PM +0800, Xin, Xiaohui wrote:
OK, if I understand you correctly then I don't think have a
problem. With your current patch-set you have exactly the same
situation when the skb-data is reallocated as a kernel buffer.
When will skb-data to be reallocated? May
On 07/02/2010 11:00 AM, Xiao Guangrong wrote:
The IOAPIC spec says:
When accessing these registers, accesses must be done one dword at a time.
For example, software should never access byte 2 from the Data register before
accessing bytes 0 and 1. The hardware will not attempt to recover from a
On 07/03/2010 01:44 AM, Marcelo Tosatti wrote:
Config entry:
[access]
file = access.flat
Massive log, compressed and attached.
run
test pde.p user: FAIL: error code 5 expected 4
test pte.rw pde.p user: FAIL: error code 5 expected 4
test pte.user pde.p user: FAIL: error code 5 expected
On 07/02/2010 10:08 PM, BuraphaLinux Server wrote:
Hello,
I tried my best to do the bisection, and the result after many kernels was:
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[3ce672d48400e0112fec7a3cb6bb2120493c6e11] KVM: SVM: init_vmcb():
remove redundant save-cr0
Marcelo Tosatti wrote:
On Thu, Jul 01, 2010 at 09:55:56PM +0800, Xiao Guangrong wrote:
Combine guest pte read between guest pte walk and pte prefetch
Signed-off-by: Xiao Guangrong xiaoguangr...@cn.fujitsu.com
---
arch/x86/kvm/paging_tmpl.h | 48
On 07/02/2010 08:03 PM, Marcelo Tosatti wrote:
On Thu, Jul 01, 2010 at 09:55:56PM +0800, Xiao Guangrong wrote:
Combine guest pte read between guest pte walk and pte prefetch
Signed-off-by: Xiao Guangrongxiaoguangr...@cn.fujitsu.com
---
arch/x86/kvm/paging_tmpl.h | 48
subscribe kvm
--
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
On 07/03/2010 01:31 PM, Xiao Guangrong wrote:
See how the pte is reread inside fetch with mmu_lock held.
It looks like something is broken in 'fetch' functions, this patch will
fix it.
Subject: [PATCH] KVM: MMU: fix last level broken in FNAME(fetch)
We read the guest level out of
Avi Kivity wrote:
On 07/03/2010 01:31 PM, Xiao Guangrong wrote:
See how the pte is reread inside fetch with mmu_lock held.
It looks like something is broken in 'fetch' functions, this patch will
fix it.
Subject: [PATCH] KVM: MMU: fix last level broken in FNAME(fetch)
We read the
On 07/03/2010 03:16 PM, Xiao Guangrong wrote:
Avi Kivity wrote:
On 07/03/2010 01:31 PM, Xiao Guangrong wrote:
See how the pte is reread inside fetch with mmu_lock held.
It looks like something is broken in 'fetch' functions, this patch will
fix it.
Subject:
subscribe kvm
--
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
subscribe kvm
--
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
On 07/03/2010 03:31 PM, Xiao Guangrong wrote:
Avi Kivity wrote:
if (!direct) {
r = kvm_read_guest_atomic(vcpu-kvm,
gw-pte_gpa[level - 2],
curr_pte, sizeof(curr_pte));
if (r || curr_pte != gw-ptes[level - 2]) {
On 07/03/2010 03:44 PM, Avi Kivity wrote:
On 07/03/2010 03:31 PM, Xiao Guangrong wrote:
Avi Kivity wrote:
if (!direct) {
r = kvm_read_guest_atomic(vcpu-kvm,
gw-pte_gpa[level - 2],
curr_pte, sizeof(curr_pte));
if (r || curr_pte
Avi Kivity wrote:
And this check is not sufficient, since it's only checked if the
mapping is zapped or not exist, for other words only when broken this
judgment:
is_shadow_present_pte(*sptep) !is_large_pte(*sptep)
but if the middle level is present and it's not the large mapping,
Avi Kivity wrote:
Well, in the description, it looked like everything was using small
pages (in kvm, level=1 means PTE level, we need to change this one
day). Please describe again and say exactly when the guest or host
uses large pages.
Oh, I see what you mean.
Regarding the
Ok, I kept going like you said. Here is what it said:
$git bisect good
44ea2b1758d88ad822e65b1c4c21ca6164494e27 is the first bad commit
commit 44ea2b1758d88ad822e65b1c4c21ca6164494e27
Author: Avi Kivity a...@redhat.com
Date: Sun Sep 6 15:55:37 2009 +0300
KVM: VMX: Move MSR_KERNEL_GS_BASE
On Fri, 2010-07-02 at 18:27 +0200, Segher Boessenkool wrote:
+To find out if we're running on KVM or not, we overlay the PVR
register. Usually
+the PVR register contains an id that identifies your CPU type. If,
however, you
+pass KVM_PVR_PARA in the register that you want the PVR
On Fri, 2010-07-02 at 20:41 +0200, Alexander Graf wrote:
The u64s are 64-bit aligned, should they always be?
That's obvious, isn't it? And the ABI only specifies u64s to be 32 bit
aligned, no? At least that's what ld and std specify.
No, the PowerPC ABI specifies u64's to be 64-bit aligned,
On Fri, 2010-07-02 at 18:27 +0200, Segher Boessenkool wrote:
+To find out if we're running on KVM or not, we overlay the PVR
register. Usually
+the PVR register contains an id that identifies your CPU type. If,
however, you
+pass KVM_PVR_PARA in the register that you want the PVR
On Fri, 2010-07-02 at 20:41 +0200, Alexander Graf wrote:
The u64s are 64-bit aligned, should they always be?
That's obvious, isn't it? And the ABI only specifies u64s to be 32 bit
aligned, no? At least that's what ld and std specify.
No, the PowerPC ABI specifies u64's to be 64-bit aligned,
26 matches
Mail list logo
