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
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
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
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 tiejun.c...@intel.com
Looks fine to me.
Thanks
Tiejun
Signed-off-by: Andreas Herrmann
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 andreas.herrm...@caviumnetworks.com
---
tools/kvm/mips/include/kvm/kvm-arch.h | 10
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/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
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 tiejun.c...@intel.com
wrote:
On 2014/12/24 5:29, Andy Lutomirski wrote:
On Tue, Dec 23, 2014 at 1:13 PM, Paolo Bonzini pbonz...@redhat.com
wrote:
I can
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 na...@cs.technion.ac.il
---
arch/x86/kvm/emulate.c | 4 +++-
1 file
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 17:55, Nadav Amit wrote:
Tiejun tiejun.c...@intel.com 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
On 2014/12/24 5:29, Andy Lutomirski wrote:
On Tue, Dec 23, 2014 at 1:13 PM, Paolo Bonzini pbonz...@redhat.com 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
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/25 1:11, Andy Lutomirski wrote:
On Wed, Dec 24, 2014 at 12:23 AM, Chen, Tiejun tiejun.c...@intel.com wrote:
On 2014/12/24 5:29, Andy Lutomirski wrote:
On Tue, Dec 23, 2014 at 1:13 PM, Paolo Bonzini pbonz...@redhat.com
wrote:
I can reproduce it using the same steps on a Sandy
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/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
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
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,
This would
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're
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/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/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
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 '0'
On 2014/12/16 23:47, Joerg Roedel wrote:
From: Joerg Roedel jroe...@suse.de
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
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
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 there is an overflow
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
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 was
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 pbonz...@redhat.com
---
I think we also need to sync
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
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 Chen tiejun.c
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 tiejun.c...@intel.com
---
arch/x86/kvm/mmu.h | 2 ++
1 file changed, 2 insertions(+)
diff --git
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
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
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
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 tiejun.c...@intel.com
---
arch/x86/kvm/lapic.c | 3 +--
1 file changed, 1
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
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 range
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
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/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
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
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 mtosa...@redhat.com
AuthorDate: Tue Nov 27 23:28:56 2012 -0200
Commit: Marcelo Tosatti
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 rongrongx@intel.com
Signed-off-by: Yang Zhang
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 yang.z.zh...@intel.com
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
On 2014/8/8 14:02, Yang Zhang wrote:
From: Yang Zhang yang.z.zh...@intel.com
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
-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...@suse.de;
kvm
49 matches
Mail list logo
