Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu
切换分支/标签
  1. 03 3月, 2017 1 次提交
    • D
      x86: Work around SMI migration breakages · fc3a1fd7
      由 Dr. David Alan Gilbert 提交于 
      Migration from a 2.3.0 qemu results in a reboot on the receiving QEMU
due to a disagreement about SM (System management) interrupts.

2.3.0 didn't have much SMI support, but it did set CPU_INTERRUPT_SMI
and this gets into the migration stream, but on 2.3.0 it
never got delivered.

~2.4.0 SMI interrupt support was added but was broken - so
that when a 2.3.0 stream was received it cleared the CPU_INTERRUPT_SMI
but never actually caused an interrupt.

The SMI delivery was recently fixed by 68c6efe0, but the
effect now is that an incoming 2.3.0 stream takes the interrupt it
had flagged but it's bios can't actually handle it(I think
partly due to the original interrupt not being taken during boot?).
The consequence is a triple(?) fault and a reboot.

Tested from:
  2.3.1 -M 2.3.0
  2.7.0 -M 2.3.0
  2.8.0 -M 2.3.0
  2.8.0 -M 2.8.0

This corresponds to RH bugzilla entry 1420679.
Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20170223133441.16010-1-dgilbert@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      fc3a1fd7
  3. 22 2月, 2017 1 次提交
  5. 28 1月, 2017 3 次提交
  7. 24 1月, 2017 1 次提交
  9. 20 1月, 2017 1 次提交
  11. 19 1月, 2017 1 次提交
  13. 22 12月, 2016 4 次提交
  15. 28 11月, 2016 1 次提交
  17. 16 11月, 2016 2 次提交
  19. 03 11月, 2016 1 次提交
  21. 28 10月, 2016 1 次提交
  23. 25 10月, 2016 1 次提交
  25. 04 10月, 2016 2 次提交
  27. 28 9月, 2016 1 次提交
  29. 23 9月, 2016 2 次提交
  31. 15 9月, 2016 1 次提交
  33. 10 9月, 2016 2 次提交
    • L
      target-i386: present virtual L3 cache info for vcpus · 14c985cf
      由 Longpeng(Mike) 提交于 
      Some software algorithms are based on the hardware's cache info, for example,
for x86 linux kernel, when cpu1 want to wakeup a task on cpu2, cpu1 will trigger
a resched IPI and told cpu2 to do the wakeup if they don't share low level
cache. Oppositely, cpu1 will access cpu2's runqueue directly if they share llc.
The relevant linux-kernel code as bellow:

	static void ttwu_queue(struct task_struct *p, int cpu)
	{
		struct rq *rq = cpu_rq(cpu);
		......
		if (... && !cpus_share_cache(smp_processor_id(), cpu)) {
			......
			ttwu_queue_remote(p, cpu); /* will trigger RES IPI */
			return;
		}
		......
		ttwu_do_activate(rq, p, 0); /* access target's rq directly */
		......
	}

In real hardware, the cpus on the same socket share L3 cache, so one won't
trigger a resched IPIs when wakeup a task on others. But QEMU doesn't present a
virtual L3 cache info for VM, then the linux guest will trigger lots of RES IPIs
under some workloads even if the virtual cpus belongs to the same virtual socket.

For KVM, there will be lots of vmexit due to guest send IPIs.
The workload is a SAP HANA's testsuite, we run it one round(about 40 minuates)
and observe the (Suse11sp3)Guest's amounts of RES IPIs which triggering during
the period:
        No-L3           With-L3(applied this patch)
cpu0:	363890		44582
cpu1:	373405		43109
cpu2:	340783		43797
cpu3:	333854		43409
cpu4:	327170		40038
cpu5:	325491		39922
cpu6:	319129		42391
cpu7:	306480		41035
cpu8:	161139		32188
cpu9:	164649		31024
cpu10:	149823		30398
cpu11:	149823		32455
cpu12:	164830		35143
cpu13:	172269		35805
cpu14:	179979		33898
cpu15:	194505		32754
avg:	268963.6	40129.8

The VM's topology is "1*socket 8*cores 2*threads".
After present virtual L3 cache info for VM, the amounts of RES IPIs in guest
reduce 85%.

For KVM, vcpus send IPIs will cause vmexit which is expensive, so it can cause
severe performance degradation. We had tested the overall system performance if
vcpus actually run on sparate physical socket. With L3 cache, the performance
improves 7.2%~33.1%(avg:15.7%).
Signed-off-by: NLongpeng(Mike) <longpeng2@huawei.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      14c985cf
    • L
      pc: Add 2.8 machine · a4d3c834
      由 Longpeng(Mike) 提交于 
      This will used by the next patch.
Signed-off-by: NLongpeng(Mike) <longpeng2@huawei.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      a4d3c834
  35. 08 9月, 2016 3 次提交
  37. 04 8月, 2016 1 次提交
  39. 22 7月, 2016 1 次提交
  41. 20 7月, 2016 2 次提交
  43. 14 7月, 2016 1 次提交
  45. 04 7月, 2016 1 次提交
  47. 29 6月, 2016 4 次提交
  49. 24 6月, 2016 1 次提交