RE: FW: [Bug 117] New: [KVM-IPF] RTL8139 emulated network card can not work

Zhang, Xiantao wrote:
> Jes Sorensen wrote:
>> Jes Sorensen wrote:
>>> Now I am seeing this in my syslog:
>>> 
>>> Oct 10 07:21:34 a4700rac kernel: vcpu 5 irq check
>>> Oct 10 07:21:34 a4700rac kernel: vcpu 3 irq check
>>> Oct 10 07:21:34 a4700rac kernel: vcpu 2 irq check
>>> Oct 10 07:21:34 a4700rac kernel: vcpu 5 irq check
>>> Oct 10 07:21:34 a4700rac kernel: vcpu 3 irq check
>>> Oct 10 07:21:34 a4700rac kernel: vcpu 2 irq check
>>> Oct 10 07:21:34 a4700rac kernel: vcpu 5 irq check
>>> Oct 10 07:21:34 a4700rac kernel: vcpu 3 irq check
>>> Oct 10 07:21:34 a4700rac kernel: vcpu 2 irq check
>>> Oct 10 07:21:34 a4700rac kernel: vcpu 5 irq check
>>> Oct 10 07:21:34 a4700rac kernel: vcpu 3 irq check
>>> Oct 10 07:21:34 a4700rac kernel: vcpu 2 irq check
>>> Oct 10 07:21:34 a4700rac kernel: vcpu 5 irq check
>>> Oct 10 07:21:34 a4700rac kernel: vcpu 3 irq check
>>> 
>>> Note that I never seem to see irq checks for cpus 4, 6, 7 .....
>>> maybe syslog is chewing them up though, but it seems strange that
>>> they never seem to appear.
>> 
>> Now, this is where it gets strange - I pulled out the above snapshot
>> why the system was stuck in the boot process. However after a bit it
>> came back and irqs showed up on cpu 4, 6, 7 as well..... adding the
>> printk seems to have have an impact.... strange.
> 
> Hi, Jes
> 	I just did a simple try with disabling pal_halt_light emulation,
and
> guests boot well! So this is an issue caused by guest's halt
> handling.  I remembered a guy of x86 side modified the halt
> logic(common code in kvm_main.c) days ago. So this should be possible
> rootcause which cause the issue.  :) Thanks   

I have worked out the patch to fix this issue, and will send it out
after passing internal test.  :)
Xiantao