Re: EPT: Misconfiguration
On Sun, Feb 27, 2011 at 11:46, Avi Kivity wrote: > > Copying netdev: looks like memory corruption in the networking stack. > > Archive link: http://www.spinics.net/lists/kvm/msg50651.html (for the > attachment). There's now only a single guest running on this host (Ubuntu Maverick). I've also upgraded the host kernel to 2.6.38-rc6, and this just happened (after a day or so): 2011-03-05T19:41:58.328866+01:00 phy005 kernel: [85271.656862] BUG kmalloc-2048 (Not tainted): Object padding overwritten 2011-03-05T19:41:58.328870+01:00 phy005 kernel: [85271.656864] - 2011-03-05T19:41:58.328875+01:00 phy005 kernel: [85271.656866] 2011-03-05T19:41:58.328885+01:00 phy005 kernel: [85271.656870] INFO: 0x880c0d52a960-0x880c0d52a967. First byte 0x0 instead of 0x5a 2011-03-05T19:41:58.328890+01:00 phy005 kernel: [85271.656880] INFO: Allocated in __netdev_alloc_skb+0x1f/0x3b age=16039 cpu=5 pid=0 2011-03-05T19:41:58.328894+01:00 phy005 kernel: [85271.656886] INFO: Freed in skb_release_data+0xa5/0xaa age=0 cpu=5 pid=1766 2011-03-05T19:41:58.328898+01:00 phy005 kernel: [85271.656890] INFO: Slab 0xea002a2ea0c0 objects=15 used=13 fp=0x880c0d52a120 flags=0xc040c1 2011-03-05T19:41:58.328902+01:00 phy005 kernel: [85271.656894] INFO: Object 0x880c0d52a120 @offset=8480 fp=0x880c0d52d2d0 2011-03-05T19:41:58.328905+01:00 phy005 kernel: [85271.656895] 2011-03-05T19:41:58.328909+01:00 phy005 kernel: [85271.656897] Bytes b4 0x880c0d52a110: 14 89 12 05 01 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a 2011-03-05T19:41:58.328913+01:00 phy005 kernel: [85271.656909] Object 0x880c0d52a120: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b We have a quite complex network stack, two interfaces (igb) attached to bond0, with on top two bridges and on that two vlans. The guest is running a vpn and an IPv6 tunnel. Let me know if more info is needed. Kind regards, Ruben -- 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
Re: [PATCH 11/15] kvm: Rework inner loop of kvm_cpu_exec
On 2011-03-05 17:05, Marcelo Tosatti wrote:
> On Fri, Mar 04, 2011 at 11:20:08AM +0100, Jan Kiszka wrote:
>> Let kvm_cpu_exec return EXCP_* values consistently and generate those
>> codes already inside its inner loop. This means we will now re-enter the
>> kernel while ret == 0.
>>
>> Update kvm_handle_internal_error accordingly, but keep
>> kvm_arch_handle_exit untouched, it will be converted in a separate step.
>>
>> Signed-off-by: Jan Kiszka
>> ---
>> kvm-all.c | 26 ++
>> 1 files changed, 14 insertions(+), 12 deletions(-)
>>
>> diff --git a/kvm-all.c b/kvm-all.c
>> index 2952499..cc652cf 100644
>> --- a/kvm-all.c
>> +++ b/kvm-all.c
>> @@ -848,7 +848,7 @@ static int kvm_handle_internal_error(CPUState *env,
>> struct kvm_run *run)
>> fprintf(stderr, "emulation failure\n");
>> if (!kvm_arch_stop_on_emulation_error(env)) {
>> cpu_dump_state(env, stderr, fprintf, CPU_DUMP_CODE);
>> -return 0;
>> +return EXCP_INTERRUPT;
>> }
>> }
>> /* FIXME: Should trigger a qmp message to let management know
>> @@ -947,7 +947,7 @@ int kvm_cpu_exec(CPUState *env)
>>
>> if (ret == -EINTR || ret == -EAGAIN) {
>> DPRINTF("io window exit\n");
>> -ret = 0;
>> +ret = EXCP_INTERRUPT;
>> break;
>> }
>>
>> @@ -956,7 +956,6 @@ int kvm_cpu_exec(CPUState *env)
>> abort();
>> }
>>
>> -ret = 0; /* exit loop */
>> switch (run->exit_reason) {
>
> Better keep ret assignment here so default behaviour is to
> exit loop? EXCP_INTERRUPT.
There is no real default behavior: in two cases we stay in the loop, in
two others we leave, and the rest obtains ret from a return value.
Moreover, if a new case misses to set ret, the compiler will complain.
Jan
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 03/15] kvm: Install optimized interrupt handlers
On 2011-03-05 16:37, Marcelo Tosatti wrote:
> On Fri, Mar 04, 2011 at 11:20:00AM +0100, Jan Kiszka wrote:
>> KVM only requires to set the raised IRQ in CPUState and, if the user
>> space irqchip is used, to kick the receiving vcpu if it is remote.
>>
>> Signed-off-by: Jan Kiszka
>> ---
>> kvm-all.c | 17 +
>> 1 files changed, 17 insertions(+), 0 deletions(-)
>>
>> diff --git a/kvm-all.c b/kvm-all.c
>> index 226843c..c460d45 100644
>> --- a/kvm-all.c
>> +++ b/kvm-all.c
>> @@ -650,6 +650,20 @@ static CPUPhysMemoryClient kvm_cpu_phys_memory_client =
>> {
>> .log_stop = kvm_log_stop,
>> };
>>
>> +static void kvm_handle_interrupt(CPUState *env, int mask)
>> +{
>> +env->interrupt_request |= mask;
>> +
>
> If the env->interrupt_request request is processed in userspace, such as
> MCE, the kick is still necessary for irqchip case. CPU_INTERRUPT_DEBUG
> is another example, no?
[this probably targeted kvm_handle_interrupt_kernel_irqchip]
In principle, you are right. But MCE must be injected synchronously over
the target VCPU, see do_inject_x86_mce, and CPU_INTERRUPT_DEBUG is also
synchronous and not even used in KVM mode.
>
>> +if (!qemu_cpu_self(env)) {
>> +qemu_cpu_kick(env);
>> +}
>> +}
>> +
>> +static void kvm_handle_interrupt_kernel_irqchip(CPUState *env, int mask)
>> +{
>> +env->interrupt_request |= mask;
>> +}
>> +
Jan
signature.asc
Description: OpenPGP digital signature
Re: kvm crashes with spice while loading qxl
On 03/05/2011 05:35 PM, Marcelo Tosatti wrote: TCG and KVM execution behaviour can become more similar wrt locking by dropping qemu_global_mutex during generation and execution of TBs. Of course for memory or PIO accesses from vcpu context qemu_global_mutex must be acquired. -icount already has most of the machinery needed for this. At this point, I think people interested in TCG should choose between staying with legacy and gaining a bit more speed for uniprocessor simulation, or following KVM with a more complex architecture and finer-grained locking---but also a more future-proof design. BTW, I'll post soon patches for iothread -icount that work (at least in my tests), are much simpler than anything I posted so far, and hopefully will show that iothread is not fundamentally incompatible with anything (and in fact can simplify things much more than complicate them). With that in place, it becomes easier to justify further improvements regarding parallelization, such as using a read-write lock for l1_phys_map / phys_page_find_alloc. Or URCU (userspace RCU), too. Paolo -- 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
Re: [PATCH 03/15] kvm: Install optimized interrupt handlers
On Fri, Mar 04, 2011 at 11:20:00AM +0100, Jan Kiszka wrote:
> KVM only requires to set the raised IRQ in CPUState and, if the user
> space irqchip is used, to kick the receiving vcpu if it is remote.
>
> Signed-off-by: Jan Kiszka
> ---
> kvm-all.c | 17 +
> 1 files changed, 17 insertions(+), 0 deletions(-)
>
> diff --git a/kvm-all.c b/kvm-all.c
> index 226843c..c460d45 100644
> --- a/kvm-all.c
> +++ b/kvm-all.c
> @@ -650,6 +650,20 @@ static CPUPhysMemoryClient kvm_cpu_phys_memory_client = {
> .log_stop = kvm_log_stop,
> };
>
> +static void kvm_handle_interrupt(CPUState *env, int mask)
> +{
> +env->interrupt_request |= mask;
> +
If the env->interrupt_request request is processed in userspace, such as
MCE, the kick is still necessary for irqchip case. CPU_INTERRUPT_DEBUG
is another example, no?
> +if (!qemu_cpu_self(env)) {
> +qemu_cpu_kick(env);
> +}
> +}
> +
> +static void kvm_handle_interrupt_kernel_irqchip(CPUState *env, int mask)
> +{
> +env->interrupt_request |= mask;
> +}
> +
--
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
Re: [PATCH 11/15] kvm: Rework inner loop of kvm_cpu_exec
On Fri, Mar 04, 2011 at 11:20:08AM +0100, Jan Kiszka wrote:
> Let kvm_cpu_exec return EXCP_* values consistently and generate those
> codes already inside its inner loop. This means we will now re-enter the
> kernel while ret == 0.
>
> Update kvm_handle_internal_error accordingly, but keep
> kvm_arch_handle_exit untouched, it will be converted in a separate step.
>
> Signed-off-by: Jan Kiszka
> ---
> kvm-all.c | 26 ++
> 1 files changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/kvm-all.c b/kvm-all.c
> index 2952499..cc652cf 100644
> --- a/kvm-all.c
> +++ b/kvm-all.c
> @@ -848,7 +848,7 @@ static int kvm_handle_internal_error(CPUState *env,
> struct kvm_run *run)
> fprintf(stderr, "emulation failure\n");
> if (!kvm_arch_stop_on_emulation_error(env)) {
> cpu_dump_state(env, stderr, fprintf, CPU_DUMP_CODE);
> -return 0;
> +return EXCP_INTERRUPT;
> }
> }
> /* FIXME: Should trigger a qmp message to let management know
> @@ -947,7 +947,7 @@ int kvm_cpu_exec(CPUState *env)
>
> if (ret == -EINTR || ret == -EAGAIN) {
> DPRINTF("io window exit\n");
> -ret = 0;
> +ret = EXCP_INTERRUPT;
> break;
> }
>
> @@ -956,7 +956,6 @@ int kvm_cpu_exec(CPUState *env)
> abort();
> }
>
> -ret = 0; /* exit loop */
> switch (run->exit_reason) {
Better keep ret assignment here so default behaviour is to
exit loop? EXCP_INTERRUPT.
--
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
Re: [PATCH 2/10] KVM: MMU: fix kvm_mmu_get_spte_hierarchy
On Fri, Mar 04, 2011 at 06:57:27PM +0800, Xiao Guangrong wrote:
> Don not walk to the next level if spte is mapping to the large page
>
> Signed-off-by: Xiao Guangrong
> ---
> arch/x86/kvm/mmu.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index b9bf016..10e0982 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -3819,7 +3819,8 @@ int kvm_mmu_get_spte_hierarchy(struct kvm_vcpu *vcpu,
> u64 addr, u64 sptes[4])
> for_each_shadow_entry(vcpu, addr, iterator) {
> sptes[iterator.level-1] = *iterator.sptep;
> nr_sptes++;
> - if (!is_shadow_present_pte(*iterator.sptep))
> + if (!is_shadow_present_pte(*iterator.sptep) ||
> + is_last_spte(*iterator.sptep, iterator.level))
> break;
> }
> spin_unlock(&vcpu->kvm->mmu_lock);
shadow_walk_okay covers that case.
--
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
Re: kvm crashes with spice while loading qxl
On Sat, Feb 26, 2011 at 01:29:01PM +0100, Jan Kiszka wrote: > > at > > /var/tmp/portage/app-emulation/qemu-kvm-0.14.0/work/qemu-kvm-0.14.0/qemu-kvm.c:1466 > > #12 0x777bb944 in start_thread () from /lib/libpthread.so.0 > > #13 0x75e491dd in clone () from /lib/libc.so.6 > > (gdb) > > That's a spice bug. In fact, there are a lot of > qemu_mutex_lock/unlock_iothread in that subsystem. I bet at least a few > of them can cause even more subtle problems. > > Two general issues with dropping the global mutex like this: > - The caller of mutex_unlock is responsible for maintaining >cpu_single_env across the unlocked phase (that's related to the >abort above). > - Dropping the lock in the middle of a callback is risky. That may >enable re-entrances of code sections that weren't designed for this >(I'm skeptic about the side effects of >qemu_spice_vm_change_state_handler - why dropping the lock here?). > > Spice requires a careful review regarding such issues. Or it should > pioneer with introducing its own lock so that we can handle at least > related I/O activities over the VCPUs without holding the global mutex > (but I bet it's not the simplest candidate for such a new scheme). > > Jan > Agree with the concern regarding spice. Regarding global mutex, TCG and KVM execution behaviour can become more similar wrt locking by dropping qemu_global_mutex during generation and execution of TBs. Of course for memory or PIO accesses from vcpu context qemu_global_mutex must be acquired. With that in place, it becomes easier to justify further improvements regarding parallelization, such as using a read-write lock for l1_phys_map / phys_page_find_alloc. 21.62% sh3d38920b3f [.] 0x3d38920b3f 6.38% sh qemu-system-x86_64[.] phys_page_find_alloc 4.90% sh qemu-system-x86_64[.] tb_find_fast 4.34% sh qemu-system-x86_64[.] tlb_flush -- 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
Re: when use sriov, guest os could not access the vf device assigned
the version of libvirt is 0.7.6. i find the patch of this problem,now solved. http://libvirt.org/git/?p=libvirt.git;a=commit;h=71e92a1575b6653720b0f4c7a474b6e7baec72f3 thanks. 2011/3/5 Chris Wright : > * lidong chen (chen.lidong.ker...@gmail.com) wrote: >> guest os could not access the vf assigned ，and print this error message . >> PCI: device :00:06.0 has unknown header type 7f, ignoring. >> PCI: device :00:07.0 has unknown header type 7f, ignoring. >> PCI: device :00:08.0 has unknown header type 7f, ignoring. >> >> the reason is the config file /sys/bus/pci/devices/xx/config of pci >> device could not access correctly after guestos start, >> the content qemu-kvm read from /sys/bus/pci/devices/xx/config is all FF. > > This is mostly likely a combination of two bugs, both have since been > fixed (starting in v0.8.3). What version of libvirt are you using? > > One is the 82599 VF has an erratum that it does not show that it supports > Function Level Reset (FLR -- SR-IOV VFs are required to support FLR). > The second is libvirt had buggy handling of device reset for devices > that don't support FLR. IIRC, what you are seeing is the result of a > secondary bus reset resetting all devices on that bus (including the PF). > > Try upgrading libvirt. > > thanks, > -chris > -- 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
2.6.38-rc6: general protection error inside KVM 64 bits guest
[ was post on LKML but try it here since it's more appropriate ]
Hello,
I'm running kernel 2.6.38-rc6 with qemu-kvm 0.12.3.
Doing this inside the guest:
int main(void)
{
if (ioperm(0x3e0, 4, 1) < 0) {
perror("ioperm");
exit(1);
}
outb(0, 0x3e0);
inb(0x3e1);
printf("exiting succesfully\n");
return 0;
}
make a general protection error.
Looking for the faulty instruction with gdb and found that's the 'inb'
instruction the culprit.
Running the same program on the host works fine.
Could anybody tell me what's wrong ?
Thanks
--
Francis
--
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
