On Tue, Jan 22, 2013 at 11:44:43PM +0800, Amos Kong wrote:
Currently virtio-net code relys on the layout of descriptor,
this patchset removed the assumptions and introduced a control
command to set mac address. Last patch is a trivial renaming.
V2: check guest's iov_len
V3: fix of migration
On Wed, Jan 23, 2013 at 2:21 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
Missing signed off by.
Signed-off-by: Avi Kivity avi.kiv...@gmail.com
--
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
Do not drop large spte until it can be insteaded by small pages so that
the guest can happliy read memory through it
The idea is from Avi:
| As I mentioned before, write-protecting a large spte is a good idea,
| since it moves some work from protect-time to fault-time, so it reduces
| jitter.
Use min() to cleanup mapping_level
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 0f90269..8dca8af 100644
--- a/arch/x86/kvm/mmu.c
+++
In order to detecting spte remapping, we can simply check whether the
spte has already been pointing to the pfn even if the spte is not the
last spte, for middle spte is pointing to the kernel pfn which can not
be mapped to userspace
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
For the logic, the function can be divided into two parts: one is adjusting
pte_access, the rest one is setting spte according the pte_access. It makes
the code more readable
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c | 51
Introduce it to split the code of adjusting pte_access from the large
function of set_spte
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c | 63 +---
1 files changed, 40 insertions(+), 23 deletions(-)
diff
It makes set_spte more clean and reduces branch prediction
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c | 37 ++---
1 files changed, 26 insertions(+), 11 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
It is only used in debug code, so drop it
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c | 15 ++-
arch/x86/kvm/paging_tmpl.h |9 -
2 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/arch/x86/kvm/mmu.c
Use link_shadow_page to link the sp to the spte in __direct_map
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index c0bb7cf..7d7eb4a
It is used to establish the spte if it is not present to cleanup the
code, it also marks spte present before linking it to the sp's
parent_list, then we can integrate the code between rmap walking and
parent_lisk walking in the later patch
Signed-off-by: Xiao Guangrong
Walking parent spte and walking ramp have same logic, this patch introduces
for_each_spte_in_pte_list to integrate their code
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c | 199 ++
PT_PRESENT_MASK bit is not enough to see the spte has already been mapped
into pte-list for mmio spte also set this bit. Use is_shadow_present_pte
instead to fix it
Also, this patch move many assertions to the common place to clean up the
code
Signed-off-by: Xiao Guangrong
If the pte_list need to be destroyed, no need to delete its spte one
by one, we can directly reset it and free the memory its used
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c | 36 +++-
1 files changed, 27 insertions(+),
This patch set mitigates another mmu_lock hold time issue. Although
this is not enough and I'm thinking of additional work already, this
alone can reduce the lock hold time to some extent.
Takuya Yoshikawa (8):
KVM: MMU: Fix and clean up for_each_gfn_* macros
KVM: MMU: Use
The expression (sp)-gfn should not be expanded using @gfn.
Although no user of these macros passes a string other than gfn now,
this should be fixed before anyone sees strange errors.
Also, the counter-intuitive conditions, which had been used before these
macros were introduced to avoid extra
We are traversing the linked list, invalid_list, deleting each entry by
kvm_mmu_free_page(). _safe version is there for such a case.
Signed-off-by: Takuya Yoshikawa yoshikawa_takuya...@lab.ntt.co.jp
---
arch/x86/kvm/mmu.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff
Currently we cannot do the isolation of mmu pages, i.e. deleting the
current hash_link node by hlist_del(), in this function, because we
may call it while traversing the linked list; we cannot solve the
problem by hlist_for_each_entry_safe as zapping can happen recursively.
Since the isolation
This is a preparation for moving hlist_del(sp-hash_link) from
kvm_mmu_isolate_page() to kvm_mmu_prepare_zap_page().
All for_each_gfn_indirect_valid_sp's whose bodies contain a function
call which will reach kvm_mmu_prepare_zap_page(), and not break the
loop right after the call, are converted to
Now that we are using for_each_gfn_indirect_valid_sp_safe, we can safely
delete the node by correctly updating the pointer to the next one.
The only case we need to care about is when mmu_zap_unsync_children()
has zapped anything other than the current one.
Signed-off-by: Takuya Yoshikawa
This will be split out from kvm_mmu_commit_zap_page() and moved out of
the protection of the mmu_lock later.
Note: kvm_mmu_isolate_page() is folded into kvm_mmu_free_page() since it
now does nothing but free sp-gfns.
Signed-off-by: Takuya Yoshikawa yoshikawa_takuya...@lab.ntt.co.jp
---
Just trivial conversions at this point. Some of these will be moved out
of the protection of the mmu_lock in the following patch.
Signed-off-by: Takuya Yoshikawa yoshikawa_takuya...@lab.ntt.co.jp
---
arch/x86/kvm/mmu.c | 24 +---
1 files changed, 21 insertions(+), 3
We noticed that kvm_mmu_zap_all() could take hundreds of milliseconds
for zapping mmu pages with mmu_lock held.
Although we need to do conditional rescheduling for completely
fixing this issue, we can reduce the hold time to some extent by moving
free_zapped_mmu_pages() out of the protection.
On Tue, Jan 22, 2013 at 06:25:01PM -0200, Eduardo Habkost wrote:
This will allow each architecture to define how the VCPU ID is set on
the KVM_CREATE_VCPU ioctl call.
Signed-off-by: Eduardo Habkost ehabk...@redhat.com
Acked-by: Gleb Natapov g...@redhat.com
---
Cc: kvm@vger.kernel.org
Cc:
On Tue, Jan 22, 2013 at 06:25:02PM -0200, Eduardo Habkost wrote:
The CPU ID in KVM is supposed to be the APIC ID, so change the
KVM_CREATE_VCPU call to match it. The current behavior didn't break
anything yet because today the APIC ID is assumed to be equal to the CPU
index, but this won't be
On Tue, Jan 22, 2013 at 09:13:06PM -0200, Marcelo Tosatti wrote:
On Tue, Jan 22, 2013 at 05:55:53PM +0200, Gleb Natapov wrote:
On Tue, Jan 22, 2013 at 12:21:47PM +, Zhang, Yang Z wrote:
+static void vmx_set_msr_bitmap(struct kvm_vcpu *vcpu)
+{
+ unsigned long *msr_bitmap;
On Wed, Jan 23, 2013 at 12:45:39AM +, Zhang, Yang Z wrote:
We are getting close so please test with userspace irq chip too.
Thanks for your suggestion to test with userspace irqchip. I found some
issues and will modify the logic:
As we known, APICv deponds on TPR shadow. But TPR shadow
On 01/23/2013 06:12 PM, Takuya Yoshikawa wrote:
This patch set mitigates another mmu_lock hold time issue. Although
this is not enough and I'm thinking of additional work already, this
alone can reduce the lock hold time to some extent.
It is not worth doing this kind of complex thing,
Gleb Natapov wrote on 2013-01-23:
On Wed, Jan 23, 2013 at 12:45:39AM +, Zhang, Yang Z wrote:
We are getting close so please test with userspace irq chip too.
Thanks for your suggestion to test with userspace irqchip. I found some
issues and will modify the logic: As we known, APICv deponds
On Tue, Jan 22, 2013 at 01:49:31PM +0800, Yang Zhang wrote:
From: Yang Zhang yang.z.zh...@intel.com
The acknowledge interrupt on exit feature controls processor behavior
for external interrupt acknowledgement. When this control is set, the
processor acknowledges the interrupt controller to
On 23/01/13 11:24, Pranavkumar Sawargaonkar wrote:
Hi Pranav,
I have tried kvm-arm64/kvm branch but seems it is not booting on foundation
model.
Hmmm...
root@hot-poop:~# dmesg | head
Initializing cgroup subsys cpu
Linux version 3.8.0-rc4+ (maz@e102391-lin) (gcc version 4.7.1 (0.11.114) )
On Wed, 23 Jan 2013 18:44:52 +0800
Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com wrote:
On 01/23/2013 06:12 PM, Takuya Yoshikawa wrote:
This patch set mitigates another mmu_lock hold time issue. Although
this is not enough and I'm thinking of additional work already, this
alone can
On 01/23/2013 09:28 PM, Takuya Yoshikawa wrote:
On Wed, 23 Jan 2013 18:44:52 +0800
Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com wrote:
On 01/23/2013 06:12 PM, Takuya Yoshikawa wrote:
This patch set mitigates another mmu_lock hold time issue. Although
this is not enough and I'm thinking
On Tue, Jan 22, 2013 at 01:08:54PM +0530, Raghavendra K T wrote:
In some special scenarios like #vcpu = #pcpu, PLE handler may
prove very costly, because there is no need to iterate over vcpus
and do unsuccessful yield_to burning CPU.
The first patch optimizes all the yield_to by bailing
On Wed, 23 Jan 2013 21:45:23 +0800
Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com wrote:
The current code which deletes the two link nodes in different functions
looks unnatural to me: traversing the sp-link nodes forces us to break
the loop and sp-hash_link nodes alone is allowed to
From: Yang Zhang yang.z.zh...@intel.com
APIC virtualization is a new feature which can eliminate most of VM exit
when vcpu handle a interrupt:
APIC register virtualization:
APIC read access doesn't cause APIC-access VM exits.
APIC write becomes trap-like.
Virtual interrupt
- APIC read doesn't cause VM-Exit
- APIC write becomes trap-like
Signed-off-by: Kevin Tian kevin.t...@intel.com
Signed-off-by: Yang Zhang yang.z.zh...@intel.com
---
arch/x86/include/asm/vmx.h |2 ++
arch/x86/kvm/lapic.c | 15 +++
arch/x86/kvm/lapic.h |2 ++
From: Yang Zhang yang.z.zh...@intel.com
basically to benefit from apicv, we need to enable virtualized x2apic mode.
Currently, we only enable it when guest is really using x2apic.
Also, clear MSR bitmap for corresponding x2apic MSRs when guest enabled x2apic:
0x800 - 0x8ff: no read intercept for
From: Yang Zhang yang.z.zh...@intel.com
Virtual interrupt delivery avoids KVM to inject vAPIC interrupts
manually, which is fully taken care of by the hardware. This needs
some special awareness into existing interrupr injection path:
- for pending interrupt, instead of direct injection, we may
Using RHEL7A2 with newest libvirt etc. Doing some work that uses external
snapshot and qcow2.
I understand that virsh snapshot-delete domain snap-name is not
implemented yet.
Neither can you destroy/delete a VM that has external snapshots.
Is there another way to delete snapshots?
Is there a
On Tue, Jan 22, 2013 at 11:44:44PM +0800, Amos Kong wrote:
From: Michael S. Tsirkin m...@redhat.com
Virtio-net code makes assumption about virtqueue descriptor layout
(e.g. sg[0] is the header, sg[1] is the data buffer).
This patch makes code not rely on the layout of descriptors.
On 01/23/2013 10:49 PM, Takuya Yoshikawa wrote:
On Wed, 23 Jan 2013 21:45:23 +0800
Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com wrote:
The current code which deletes the two link nodes in different functions
looks unnatural to me: traversing the sp-link nodes forces us to break
the loop
Am 23.01.2013 11:26, schrieb Gleb Natapov:
On Tue, Jan 22, 2013 at 06:25:02PM -0200, Eduardo Habkost wrote:
The CPU ID in KVM is supposed to be the APIC ID, so change the
KVM_CREATE_VCPU call to match it. The current behavior didn't break
anything yet because today the APIC ID is assumed to be
Hi Will,
I've prepared a stable branch for you, for-will/kvm/core, based on
your stable perf branch.
Since the last patch series, I've addressed the reviewer comments, and
rev'ed KVM_CAP_ARM_PSCI to 87, since 86 is already used by PPC in
kvm/next.
kvmtool should probably be updated acoordingly.
Creating a vhost-net device allocates an object large enough (34320 bytes
on x86-64) to trigger an order-4 allocation, which may fail if memory if
fragmented:
libvirtd: page allocation failure: order:4, mode:0x2000d0
...
SLAB: Unable to allocate memory on node 0 (gfp=0xd0)
cache:
On Wed, Jan 23, 2013 at 09:46:47PM +0100, Romain Francoise wrote:
Creating a vhost-net device allocates an object large enough (34320 bytes
on x86-64) to trigger an order-4 allocation, which may fail if memory if
fragmented:
libvirtd: page allocation failure: order:4, mode:0x2000d0
...
On Wed, Jan 23, 2013 at 10:47:23PM +0800, Yang Zhang wrote:
From: Yang Zhang yang.z.zh...@intel.com
APIC virtualization is a new feature which can eliminate most of VM exit
when vcpu handle a interrupt:
APIC register virtualization:
APIC read access doesn't cause APIC-access VM
On Wed, Jan 23, 2013 at 10:47:23PM +0800, Yang Zhang wrote:
From: Yang Zhang yang.z.zh...@intel.com
APIC virtualization is a new feature which can eliminate most of VM exit
when vcpu handle a interrupt:
APIC register virtualization:
APIC read access doesn't cause APIC-access VM
Even PCIe 1.x had extended config space.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
drivers/vfio/pci/vfio_pci_config.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci_config.c
b/drivers/vfio/pci/vfio_pci_config.c
index
Marcelo Tosatti wrote on 2013-01-24:
On Wed, Jan 23, 2013 at 10:47:23PM +0800, Yang Zhang wrote:
From: Yang Zhang yang.z.zh...@intel.com
APIC virtualization is a new feature which can eliminate most of VM exit
when vcpu handle a interrupt:
APIC register virtualization:
APIC read
On Mon, Jan 21, 2013 at 03:36:40PM +0200, Gleb Natapov wrote:
Gleb Natapov (9):
KVM: VMX: remove special CPL cache access during transition to real
mode.
KVM: VMX: reset CPL only on CS register write.
KVM: VMX: if unrestricted guest is enabled vcpu state is always
valid.
We don't know pre-init time whether the device we're exposing is PCIe
or legacy PCI. We could ask for it to be specified via a device
option, but that seems like too much to ask of the user. Instead we
can assume everything will be PCIe, which makes PCI-core allocate
enough config space.
Gleb Natapov wrote on 2013-01-23:
On Tue, Jan 22, 2013 at 01:49:31PM +0800, Yang Zhang wrote:
From: Yang Zhang yang.z.zh...@intel.com
The acknowledge interrupt on exit feature controls processor behavior
for external interrupt acknowledgement. When this control is set, the
processor
On Tue, Jan 22, 2013 at 09:00:25PM +0300, Andrey Korolyov wrote:
Hi,
problem described in the title happens on heavy I/O pressure on the
host, without idle=poll trace almost always is the same, involving
mwait, with poll and nohz=off RIP varies from time to time, at the
previous hang it was
On Thu, Jan 24, 2013 at 12:47:14AM +, Zhang, Yang Z wrote:
Gleb Natapov wrote on 2013-01-23:
On Tue, Jan 22, 2013 at 01:49:31PM +0800, Yang Zhang wrote:
From: Yang Zhang yang.z.zh...@intel.com
The acknowledge interrupt on exit feature controls processor behavior
for external
Gleb Natapov wrote on 2013-01-24:
On Thu, Jan 24, 2013 at 12:47:14AM +, Zhang, Yang Z wrote:
Gleb Natapov wrote on 2013-01-23:
On Tue, Jan 22, 2013 at 01:49:31PM +0800, Yang Zhang wrote:
From: Yang Zhang yang.z.zh...@intel.com
The acknowledge interrupt on exit feature controls processor
On Wed, Jan 23, 2013 at 10:47:25PM +0800, Yang Zhang wrote:
From: Yang Zhang yang.z.zh...@intel.com
basically to benefit from apicv, we need to enable virtualized x2apic mode.
Currently, we only enable it when guest is really using x2apic.
Also, clear MSR bitmap for corresponding x2apic
57 matches
Mail list logo
