On 9/10/2015 11:08 PM, Alex Williamson wrote:
On Thu, 2015-09-10 at 18:22 +0800, Nan Xiao wrote:
Hi all,
When building kernel, it prompts "CONFIG_KVM_DEVICE_ASSIGNMENT" is "deprecated".
But it is still used in kernel code. E.g.:
"kvm_vm_ioctl_check_extension" function:
{
...
#ifdef CONFIG_K
On 2015/7/3 19:23, Paolo Bonzini wrote:
On 03/07/2015 10:56, Tiejun Chen wrote:
After commit 1cde2930e154 ("sched/preempt: Add static_key() to
preempt_notifiers") is introduced, preempt_notifier_{register, unregister}
always hold a mutex, jump_label_mutex. So in current case this shouldn't
work
On 2015/3/27 9:31, Marcelo Tosatti wrote:
On Wed, Mar 25, 2015 at 05:09:13PM +, Marc Zyngier wrote:
On 23/03/15 15:58, Andre Przywara wrote:
In kvm_destroy_vm() we call kvm_io_bus_destroy() pretty early,
especially before calling kvm_arch_destroy_vm(). To avoid
unregistering devices from th
On 2015/3/10 4:54, Marcelo Tosatti wrote:
On Sat, Dec 27, 2014 at 09:41:45PM +0100, Paolo Bonzini wrote:
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index f528343..6e52f3f 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -672,6 +672,7 @@ static void update_memslots(struct
On 2015/1/13 18:19, Andreas Herrmann wrote:
Two guest memory regions need to be defined and two "mem=" parameters
need to be passed to guest kernel to support more than 256 MB.
Cc: Chen, Tiejun
Looks fine to me.
Thanks
Tiejun
Signed-off-by: Andreas Herrmann
---
tools/kvm/mi
On 2015/1/6 21:15, Andreas Herrmann wrote:
Two guest memory regions need to be defined and two "mem=" parameters
need to be passed to guest kernel to support more than 256 MB.
Signed-off-by: Andreas Herrmann
---
tools/kvm/mips/include/kvm/kvm-arch.h | 10 +
tools/kvm/mips/kvm.c
On 2014/12/27 22:52, Paolo Bonzini wrote:
On 26/12/2014 18:59, Peter Maydell wrote:
Mm, but once you're into such microoptimisations as this you really
need to have a good justification for the effort, in the form of
profiling measurements that indicate that this is a hot path.
In this case t
On 2014/12/28 4:41, Paolo Bonzini wrote:
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index f528343..6e52f3f 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -672,6 +672,7 @@ static void update_memslots(struct kvm_memslots *slots,
WARN_ON(mslots[i].id != id);
On 2014/12/25 17:55, Nadav Amit wrote:
Tiejun wrote:
On 2014/12/25 8:52, Nadav Amit wrote:
Although pop sreg updates RSP according to the operand size, only 2 bytes are
read. The current behavior may result in incorrect #GP or #PF exceptions.
Signed-off-by: Nadav Amit
---
arch/x86/kvm/em
On 2014/12/25 18:52, Jamie Heilman wrote:
Chen, Tiejun wrote:
On 2014/12/24 19:02, Jamie Heilman wrote:
Chen, Tiejun wrote:
On 2014/12/23 15:26, Jamie Heilman wrote:
Chen, Tiejun wrote:
On 2014/12/23 9:50, Chen, Tiejun wrote:
On 2014/12/22 17:23, Jamie Heilman wrote:
KVM internal error
On 2014/12/25 8:52, Nadav Amit wrote:
Although pop sreg updates RSP according to the operand size, only 2 bytes are
read. The current behavior may result in incorrect #GP or #PF exceptions.
Signed-off-by: Nadav Amit
---
arch/x86/kvm/emulate.c | 4 +++-
1 file changed, 3 insertions(+), 1 del
On 2014/12/25 8:55, Chen, Tiejun wrote:
On 2014/12/25 1:11, Andy Lutomirski wrote:
On Wed, Dec 24, 2014 at 12:23 AM, Chen, Tiejun
wrote:
On 2014/12/24 5:29, Andy Lutomirski wrote:
On Tue, Dec 23, 2014 at 1:13 PM, Paolo Bonzini
wrote:
I can reproduce it using the same steps on a
On 2014/12/24 19:11, Paolo Bonzini wrote:
On 24/12/2014 12:02, Jamie Heilman wrote:
Running qemu-system-x86_64 -machine pc,accel=kvm -nodefaults works,
my real (headless) kvm guests work, but this new patch makes running
"qemu-system-x86_64 -machine pc,accel=kvm" fail again, this time with
err
On 2014/12/24 19:02, Jamie Heilman wrote:
Chen, Tiejun wrote:
On 2014/12/23 15:26, Jamie Heilman wrote:
Chen, Tiejun wrote:
On 2014/12/23 9:50, Chen, Tiejun wrote:
On 2014/12/22 17:23, Jamie Heilman wrote:
KVM internal error. Suberror: 1
emulation failure
EAX=000de494 EBX= ECX
On 2014/12/25 1:11, Andy Lutomirski wrote:
On Wed, Dec 24, 2014 at 12:23 AM, Chen, Tiejun wrote:
On 2014/12/24 5:29, Andy Lutomirski wrote:
On Tue, Dec 23, 2014 at 1:13 PM, Paolo Bonzini
wrote:
I can reproduce it using the same steps on a Sandy Bridge laptop, with
whatever QEMU is
On 2014/12/23 15:26, Jamie Heilman wrote:
Chen, Tiejun wrote:
On 2014/12/23 9:50, Chen, Tiejun wrote:
On 2014/12/22 17:23, Jamie Heilman wrote:
Chen, Tiejun wrote:
On 2014/12/21 20:46, Jamie Heilman wrote:
With v3.19-rc1 when I run qemu-system-x86_64 -machine pc,accel=kvm I
get:
KVM: entry
On 2014/12/24 5:29, Andy Lutomirski wrote:
On Tue, Dec 23, 2014 at 1:13 PM, Paolo Bonzini wrote:
I can reproduce it using the same steps on a Sandy Bridge laptop, with
whatever QEMU is packaged in Fedora 21. I attached the config.
I also submitted a virtme update for Fedora Rawhide and 21 (
On 2014/12/23 9:38, Andy Lutomirski wrote:
I can't get it to work at all. It fails with:
How can we reproduce this? I just try the following command,
qemu-system-x86_64 -machine pc,accel=kvm -m 2048 -smp 2 -hda ubuntu.img
but at least I can boot that successfully and already live for a whil
On 2014/12/23 15:26, Jamie Heilman wrote:
Chen, Tiejun wrote:
On 2014/12/23 9:50, Chen, Tiejun wrote:
On 2014/12/22 17:23, Jamie Heilman wrote:
Chen, Tiejun wrote:
On 2014/12/21 20:46, Jamie Heilman wrote:
With v3.19-rc1 when I run qemu-system-x86_64 -machine pc,accel=kvm I
get:
KVM: entry
On 2014/12/23 9:50, Chen, Tiejun wrote:
On 2014/12/22 17:23, Jamie Heilman wrote:
Chen, Tiejun wrote:
On 2014/12/21 20:46, Jamie Heilman wrote:
With v3.19-rc1 when I run qemu-system-x86_64 -machine pc,accel=kvm I
get:
KVM: entry failed, hardware error 0x8021
Looks some MSR writing
On 2014/12/22 17:23, Jamie Heilman wrote:
Chen, Tiejun wrote:
On 2014/12/21 20:46, Jamie Heilman wrote:
With v3.19-rc1 when I run qemu-system-x86_64 -machine pc,accel=kvm I
get:
KVM: entry failed, hardware error 0x8021
Looks some MSR writing issues such a failed entry.
If you&#x
On 2014/12/19 19:12, Paolo Bonzini wrote:
On 19/12/2014 03:32, Chen, Tiejun wrote:
Are you saying something below?
if (enable_apicv)
...
else {
kvm_x86_ops->hwapic_irr_update = NULL;
Yes.
But this means we have to revise hadware_setup() to get 'kvm' inside,
T
On 2014/12/21 20:46, Jamie Heilman wrote:
With v3.19-rc1 when I run qemu-system-x86_64 -machine pc,accel=kvm I
get:
KVM: entry failed, hardware error 0x8021
Looks some MSR writing issues such a failed entry.
If you're running a guest on an Intel machine without unrestricted mode
support
On 2014/12/1 19:43, Paolo Bonzini wrote:
On 01/12/2014 10:28, Tiejun Chen wrote:
In most cases calling hwapic_isr_update(), actually we always
check if kvm_apic_vid_enabled() == 1, and also actually,
kvm_apic_vid_enabled()
-> kvm_x86_ops->vm_has_apicv()
-> vmx_vm_has_apicv() or '
On 2014/12/16 23:47, Joerg Roedel wrote:
From: Joerg Roedel
When assigning devices to large memory guests (>=128GB guest
memory in the failure case) the functions to create the
IOMMU page-tables for the whole guest might run for a very
long time. On non-preemptible kernels this might cause
Soft
On 2014/12/12 9:02, Chen, Tiejun wrote:
On 2014/12/11 19:29, Paolo Bonzini wrote:
On 11/12/2014 04:02, Tiejun Chen wrote:
We already check 'len' above to make sure it already isn't
negative here, so indeed, (addr + len < addr) should never be happened.
... except if th
On 2014/12/11 19:29, Paolo Bonzini wrote:
On 11/12/2014 04:02, Tiejun Chen wrote:
We already check 'len' above to make sure it already isn't
negative here, so indeed, (addr + len < addr) should never be happened.
... except if there is an overflow.
Sorry, I'm confused. 'addr' is u64 and no
On 2014/11/27 9:46, Zhang Haoyu wrote:
Hi,
what is virtio-1 device?
Are you mean subsystem device id is '1'? That should be a network card.
In the mail "qemu: towards virtio-1 host support", "virtio: allow virtio-1 queue
layout",
"dataplane: allow virtio-1 devices", etc., "virtio-1 devices"
On 2014/11/27 9:26, Zhang Haoyu wrote:
Hi,
what is virtio-1 device?
Are you mean subsystem device id is '1'? That should be a network card.
Tiejun
--
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 ht
On 2014/11/20 5:05, Paolo Bonzini wrote:
KVM for ia64 has been marked as broken not just once, but twice even,
and the last patch from the maintainer is now roughly 5 years old.
Time for it to rest in piece.
Signed-off-by: Paolo Bonzini
---
I think we also need to sync this in Documentation:
On 2014/11/17 19:40, Paolo Bonzini wrote:
On 17/11/2014 12:31, Tiejun Chen wrote:
In non-ept 64-bit of PAE case maxphyaddr may be 52bit as well,
There is no such thing as 64-bit PAE.
Definitely.
On 32-bit PAE hosts, PTEs have bit 62 reserved, as in your patch:
Do you mean just one re
On 2014/11/17 17:22, Paolo Bonzini wrote:
On 17/11/2014 02:34, Chen, Tiejun wrote:
On 2014/11/14 18:06, Paolo Bonzini wrote:
On 14/11/2014 10:31, Tiejun Chen wrote:
In some real scenarios 'start' may not be less than 'end' like
maxphyaddr = 52.
Signed-off-by: Tiejun C
On 2014/11/14 18:11, Paolo Bonzini wrote:
On 14/11/2014 10:31, Tiejun Chen wrote:
In PAE case maxphyaddr may be 52bit as well, we also need to
disable mmio page fault. Here we can check MMIO_SPTE_GEN_HIGH_SHIFT
directly to determine if we should set the present bit, and
bring a little cleanup.
On 2014/11/14 18:06, Paolo Bonzini wrote:
On 14/11/2014 10:31, Tiejun Chen wrote:
In some real scenarios 'start' may not be less than 'end' like
maxphyaddr = 52.
Signed-off-by: Tiejun Chen
---
arch/x86/kvm/mmu.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/kvm/mmu.h b/ar
On 2014/11/5 18:22, Paolo Bonzini wrote:
On 05/11/2014 10:03, Tiejun Chen wrote:
Finally we always return highest_irr so its unnecessary to return -1
after check if highest_irr == -1.
Signed-off-by: Tiejun Chen
---
arch/x86/kvm/lapic.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
On 2014/11/5 16:50, Wang, Wei W wrote:
On 05/11/2014 4:07, Tiejun Chen wrote:
A bug was reported as follows: when running Windows 7 32-bit guests
on qemu-kvm, sometimes the guests run into blue screen during
reboot. The problem was that a guest's RVI was not cleared when it
rebooted. This
patch
On 2014/11/5 15:39, Wang, Wei W wrote:
On 05/11/2014 2:14, Tiejun Chen wrote:
A bug was reported as follows: when running Windows 7 32-bit guests on
qemu-kvm, sometimes the guests run into blue screen during reboot. The
problem was that a guest's RVI was not cleared when it rebooted. This
patch
On 2014/11/5 10:53, Wei Wang wrote:
A bug was reported as follows: when running Windows 7 32-bit guests on qemu-kvm,
sometimes the guests run into blue screen during reboot. The problem was that a
guest's RVI was not cleared when it rebooted. This patch has fixed the problem.
Signed-off-by: Wei
On 2014/11/5 1:34, Paolo Bonzini wrote:
On 31/10/2014 07:45, Tiejun Chen wrote:
Return value should be as bool type as this function declaration,
static inline bool vmcs12_read_any().
Actually, bool return values are in general a bad idea if you mean
success/fail, especially if you can use POS
On 2014/11/5 9:43, Chen, Tiejun wrote:
On 2014/11/5 1:33, Paolo Bonzini wrote:
Return a negative error code instead, and WARN() when we should be
covering
the entire 2-bit space of vmcs_field_type's return value. For increased
robustness, add a BUILD_BUG_ON checking the ran
On 2014/11/5 1:33, Paolo Bonzini wrote:
Return a negative error code instead, and WARN() when we should be covering
the entire 2-bit space of vmcs_field_type's return value. For increased
robustness, add a BUILD_BUG_ON checking the range of vmcs_field_to_offset.
Suggested-by: Tiejun Chen
Signe
On 2014/10/31 14:26, Wanpeng Li wrote:
The srcu read lock must be held while accessing memslots (e.g.
when using gfn_to_* functions), however, commit c24ae0dcd3e8
("kvm: x86: Unpin and remove kvm_arch->apic_access_page") call
gfn_to_page() in kvm_vcpu_reload_apic_access_page() w/o hold it in
vmx_
On 2014/10/31 12:33, Wanpeng Li wrote:
The srcu read lock must be held while accessing memslots (e.g.
when using gfn_to_* functions), however, commit c24ae0dcd3e8
("kvm: x86: Unpin and remove kvm_arch->apic_access_page") call
gfn_to_page() in kvm_vcpu_reload_apic_access_page() w/o hold it
which l
On 2014/9/30 15:59, Fengguang Wu wrote:
Greetings,
0day kernel testing robot got the below dmesg and the first bad commit is
commit 3dc4f7cfb7441e5e0fed3a02fc81cdaabd28300a
Author: Marcelo Tosatti
AuthorDate: Tue Nov 27 23:28:56 2012 -0200
Commit: Marcelo Tosatti
CommitDate: Tue Nov 2
On 2014/8/27 22:05, Wei Wang wrote:
kvm_ioapic_scan_entry() needs to update tmr. The previous lapic tmr value
(old_tmr) needs to sync with ioapic to get an accurate updated tmr
value before the updating work.
Tested-by: Rongrong Liu
Signed-off-by: Yang Zhang
Signed-off-by: Wei Wang
---
arch
On 2014/8/27 0:27, Wei Wang wrote:
Guest may mask the IOAPIC entry before issue EOI. In such case,
EOI will not be intercepted by hypervisor, since the corrensponding
Looks this is always missed :)
s/corrensponding/corresponding
Tiejun
bit in eoi exit bitmap is not set after the masking of
On 2014/8/14 3:16, Wei Wang wrote:
From: Yang Zhang
Guest may mask the IOAPIC entry before issue EOI. In such case,
EOI will not be intercepted by hypervisor due to the corrensponding
s/corrensponding/corresponding
bit in eoi exit bitmap is not setting.
The solution is to check ISR + TMR t
On 2014/8/8 14:02, Yang Zhang wrote:
From: Yang Zhang
Guest may mask the IOAPIC entry before issue EOI. In such case,
EOI will not be intercepted by hypervisor due to the corrensponding
bit in eoi exit bitmap is not setting.
The solution is to check ISR + TMR to construct the EOI exit bitmap.
> -Original Message-
> From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
> Sent: Thursday, May 09, 2013 8:38 PM
> To: Chen, Tiejun
> Cc: Bhushan Bharat-R65777; Caraman Mihai Claudiu-B02008; Wood
> Scott-B07421; linuxppc-...@lists.ozlabs.org; ag.
49 matches
Mail list logo
