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

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

[Zhang, Xiantao]

Hi, guys
    With latest kvm commits, our QA team reported this bug when using
RTL8139 for guests, but guests can work well with emulated e1000 NIC. It
should be a regression issue, any volunteer to take it and find the
rootcause ? Thanks!
Xiantao


Environment:
------------
Host OS (ia32/ia32e/IA64): IA64
Guest OS (ia32/ia32e/IA64): IA64
Kernel Commit:    228361787de929b07b13e49df576bc53a415943f
Userspace Commit: d558461210b34f3434506e5c92aec4507661c1da
Host Kernel Version: 2.6.26-rc8
Hardware: Montecito



Bug detailed description:
--------------------------
With this commit, KVM guest can not get its network start with emulated
RTL8139
vif. If we change the emulated network card to e1000. It can work well.
This
issue should be a regression, for recent commit can work:
Kernel Commit:    ce094fc0d25cb364bce6f854dffc6849876ab89a
Userspace Commit: d245251ee955daebb2d8cad21396984e6a198685

Mark it as P1 for it blocks automatical testing.


Reproduce steps:
----------------
1. Prepare an image.
2. create the guest by command # qemu-system-ia64 -hda <image> -m 512
-net
nic,macaddr\0:16:3e:68:fd:bc,model=rtl8139 -net
tap,script=/etc/kvm/qemu-ifup
3. guest can not get its network to work.

Current result:
----------------


Expected result:
----------------


Basic root-causing log:
----------------------


-- 
Configure bugmail:
http://otc-qa.sh.intel.com/kvm/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

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

[Jes Sorensen]

>>>>> "Xiantao" = Zhang, Xiantao <xiantao.zhang@intel.com> writes:

Xiantao> Hi, guys With latest kvm commits, our QA team reported this
Xiantao> bug when using RTL8139 for guests, but guests can work well
Xiantao> with emulated e1000 NIC. It should be a regression issue, any
Xiantao> volunteer to take it and find the rootcause ? Thanks!
Xiantao> Xiantao

Hi Xiantao,

I've never had luck with the rtl8139 driver on ia64, always been using
the e1000 emulation. We probably should try and track it down, but
since the e1000 is far more performant, it's probably not a big thing.

That said, did anyone ever get more than 2 cpus in SMP mode to boot
without hanging?

Cheers,
Jes

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

[Zhang, Xiantao]

Jes Sorensen wrote:
>>>>>> "Xiantao" = Zhang, Xiantao <xiantao.zhang@intel.com> writes:
> 
> Xiantao> Hi, guys With latest kvm commits, our QA team reported this
> Xiantao> bug when using RTL8139 for guests, but guests can work well
> Xiantao> with emulated e1000 NIC. It should be a regression issue, any
> Xiantao> volunteer to take it and find the rootcause ? Thanks!
> Xiantao> Xiantao
> 
> Hi Xiantao,
> 
> I've never had luck with the rtl8139 driver on ia64, always been using
> the e1000 emulation. We probably should try and track it down, but
> since the e1000 is far more performant, it's probably not a big thing.

> That said, did anyone ever get more than 2 cpus in SMP mode to boot
> without hanging?

Hi, Jes
	Didn't you boot smp guests with more than 1 vcpu ? To me, I have
benn always using 4vcpus for booting guests, and didn't find any issue
before.  
Thanks
Xiantao
	

Re: FW: [Bug 117] New: [KVM-IPF] RTL8139 emulated network card can

[Jes Sorensen]

Zhang, Xiantao wrote:
>> That said, did anyone ever get more than 2 cpus in SMP mode to boot
>> without hanging?
> 
> Hi, Jes
> 	Didn't you boot smp guests with more than 1 vcpu ? To me, I have
> benn always using 4vcpus for booting guests, and didn't find any issue
> before.  

I have been able to boot upto 4, but when I boot more than 2, they start
hanging and not booting the way they should :-( It's like interrupts are
not being delivered to some of the cpus.

Cheers,
Jes

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

[Alexander Graf]

On 09.10.2008, at 13:16, Jes Sorensen wrote:

> Zhang, Xiantao wrote:
>>> That said, did anyone ever get more than 2 cpus in SMP mode to boot
>>> without hanging?
>> Hi, Jes
>> 	Didn't you boot smp guests with more than 1 vcpu ? To me, I have
>> benn always using 4vcpus for booting guests, and didn't find any  
>> issue
>> before.
>
> I have been able to boot upto 4, but when I boot more than 2, they  
> start
> hanging and not booting the way they should :-( It's like interrupts  
> are
> not being delivered to some of the cpus.

We had similar effects, but I'll CC Raymund who did the actual KVM- 
IA64 testing.
IIRC things worked stable up to 2 VCPUs.

Alex

Re: [Bug 117] New: [KVM-IPF] RTL8139 emulated network card can not

[Jes Sorensen]

Alexander Graf wrote:
>> I have been able to boot upto 4, but when I boot more than 2, they start
>> hanging and not booting the way they should :-( It's like interrupts are
>> not being delivered to some of the cpus.
> 
> We had similar effects, but I'll CC Raymund who did the actual KVM-IA64 
> testing.
> IIRC things worked stable up to 2 VCPUs.

This is very interesting, at least it means I am not totally mad :-)

Raymond, what hardware were these tests run on? I am curious if it is
an Altix problem or whether you tested Tiger or HP boxes as well?

Cheers,
Jes

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

[Raymund Will]

Jes Sorensen wrote on 2008-10-09T13:56:57 +0200:
> Alexander Graf wrote:
> >>I have been able to boot upto 4, but when I boot more than 2, they start
> >>hanging and not booting the way they should :-( It's like interrupts are
> >>not being delivered to some of the cpus.
> >
> >We had similar effects, but I'll CC Raymund who did the actual KVM-IA64 
> >testing.  IIRC things worked stable up to 2 VCPUs.
> 
> This is very interesting, at least it means I am not totally mad :-)
> 
> Raymond, what hardware were these tests run on? I am curious if it is
> an Altix problem or whether you tested Tiger or HP boxes as well?

It's been on an HP blade with two Montecito CPUs (8 logical), but I
wouldn't call that "testing".  The goal of my effort has been to get KVM
on Itanium compiled and packaged for a first time (based on kvm-74).
That a VM started to boot at all, with 4 CPUs and 4 GB, was almost
"good enough"(TM) for me.  Alas, stability was very poor, so I went
down to 2/2 (or so), which allowed me to install SLES11-Alpha2.
But even that "froze" occasionally, so  I resorted to 1/2 and had
a mostly idle VM survive several days...

IOW, yes I can confirm, that my snapshot of KVM had stability issues
on non-Altix hardware!

Unfortunately there's no time left for keeping up with upstream development
and further testing at this time...

Thanks,
-- 
Raymund Will                                                rw@SuSE.de

Re: FW: [Bug 117] New: [KVM-IPF] RTL8139 emulated network card can

[Jes Sorensen]

Zhang, Xiantao wrote:
> Hi, Jes
> 	Didn't you boot smp guests with more than 1 vcpu ? To me, I have
> benn always using 4vcpus for booting guests, and didn't find any issue
> before.  
> Thanks
> Xiantao
> 	

Hi Xiantao,

Just to confirm, you have booted KVM with 4 vcpus for testing recently?

Cheers,
Jes

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

[Zhang, Xiantao]

Jes Sorensen wrote:
> Zhang, Xiantao wrote:
>> Hi, Jes
>> 	Didn't you boot smp guests with more than 1 vcpu ? To me, I have
>> benn always using 4vcpus for booting guests, and didn't find any
>> issue before. Thanks
>> Xiantao
>> 
> 
> Hi Xiantao,
> 
> Just to confirm, you have booted KVM with 4 vcpus for testing
> recently? 

Hi, Jes
   Yes, with latest commits I can boot it with 4 vcpus, and didn't meet
hang on my box. But seems it may be not stable like before. In the our
test of Sep 25 from our QA team,  ltp test can pass in the guest
configuring with 4vcpus, but in the latest test, it meets lost
interrupts sometimes, but even so, we didn't meet system hang.  So, this
unstable issue should be a regression one from recent days' commits.
Could you detail the issue you meet ?  Thanks! :)
Xiantao

Re: FW: [Bug 117] New: [KVM-IPF] RTL8139 emulated network card can

[Jes Sorensen]

Zhang, Xiantao wrote:
> Hi, Jes
>    Yes, with latest commits I can boot it with 4 vcpus, and didn't meet
> hang on my box. But seems it may be not stable like before. In the our
> test of Sep 25 from our QA team,  ltp test can pass in the guest
> configuring with 4vcpus, but in the latest test, it meets lost
> interrupts sometimes, but even so, we didn't meet system hang.  So, this
> unstable issue should be a regression one from recent days' commits.
> Could you detail the issue you meet ?  Thanks! :)
> Xiantao

Hi Xiantao,

This is interesting - this has been happening for me since before Sep 25
for sure. Basically if I boot with 4 VCPUs, it may boot, it doesn't hang
solid, but I sometimes have to hit enter on the console to get it to
finish booting. It is like timer interrupts aren't being delivered.

Cheers,
Jes

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

[Zhang, Xiantao]

Jes Sorensen wrote:
> Zhang, Xiantao wrote:
>> Hi, Jes
>>    Yes, with latest commits I can boot it with 4 vcpus, and didn't
>> meet hang on my box. But seems it may be not stable like before. In
>> the our test of Sep 25 from our QA team,  ltp test can pass in the
>> guest configuring with 4vcpus, but in the latest test, it meets lost
>> interrupts sometimes, but even so, we didn't meet system hang.  So,
>> this unstable issue should be a regression one from recent days'
>> commits. Could you detail the issue you meet ?  Thanks! :)
>> Xiantao
> 
> Hi Xiantao,
> 
> This is interesting - this has been happening for me since before Sep
> 25 for sure. Basically if I boot with 4 VCPUs, it may boot, it
> doesn't hang solid, but I sometimes have to hit enter on the console
> to get it to finish booting. It is like timer interrupts aren't being
> delivered. 

I also doubt this issue is caused by timer. And it also maybe caused by
system halt's emualtion. I remembered one guy had changed the logic of
system's halt handling, and maybe ia64 side should do some changes
accordingly. 
Thanks
Xiantao

Re: FW: [Bug 117] New: [KVM-IPF] RTL8139 emulated network card can

[Jes Sorensen]

Zhang, Xiantao wrote:
> I also doubt this issue is caused by timer. And it also maybe caused by
> system halt's emualtion. I remembered one guy had changed the logic of
> system's halt handling, and maybe ia64 side should do some changes
> accordingly. 

Hi Xiantao,

It may not be the timer, it's more how it feels from the user
perspective. The higher number of VCPUs I boot, the worse it gets. If I
set it to say 8 or 16 I never finish the boot process at all.

Cheers,
Jes

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

[Zhang, Xiantao]

Jes Sorensen wrote:
> Zhang, Xiantao wrote:
>> I also doubt this issue is caused by timer. And it also maybe caused
>> by system halt's emualtion. I remembered one guy had changed the
>> logic of system's halt handling, and maybe ia64 side should do some
>> changes accordingly.
> 
> Hi Xiantao,
> 
> It may not be the timer, it's more how it feels from the user
> perspective. The higher number of VCPUs I boot, the worse it gets. If
> I set it to say 8 or 16 I never finish the boot process at all.

Hi, Jes
     Currently, we only supports up to 8 vcpus, and to be safe, I set
the limit to 4 (Defined in include/asm/kvm_host.h). Maybe you can
increase the macro KVM_MAX_VCPUS to have a try.  In order to support >8
vcpus, we can decrease the size of vtlb and vhpt, also defined in
include/asm/kvm_host.h.  Thanks! :0
Xiantao

Re: FW: [Bug 117] New: [KVM-IPF] RTL8139 emulated network card can

[Jes Sorensen]

Zhang, Xiantao wrote:
> Hi, Jes
>      Currently, we only supports up to 8 vcpus, and to be safe, I set
> the limit to 4 (Defined in include/asm/kvm_host.h). Maybe you can
> increase the macro KVM_MAX_VCPUS to have a try.  In order to support >8
> vcpus, we can decrease the size of vtlb and vhpt, also defined in
> include/asm/kvm_host.h.  Thanks! :0
Hi Xiantao,
I already increased this value, or it wouldn't have accepted my > 4
number :-)

What is the reason for the max 8 limitation? At some point I will
definately need to do something about that ..... 256 will be my minimum
target :-)

Cheers,
Jes

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

[Zhang, Xiantao]

Jes Sorensen wrote:
> Zhang, Xiantao wrote:
>> Hi, Jes
>>      Currently, we only supports up to 8 vcpus, and to be safe, I set
>> the limit to 4 (Defined in include/asm/kvm_host.h). Maybe you can
>> increase the macro KVM_MAX_VCPUS to have a try.  In order to support
>> >8 vcpus, we can decrease the size of vtlb and vhpt, also defined in
>> include/asm/kvm_host.h.  Thanks! :0
> Hi Xiantao,
> I already increased this value, or it wouldn't have accepted my > 4
> number :-)
> 
> What is the reason for the max 8 limitation? 
In current implementation, we allocated 16M data area(Mapped by one pair
of TR in guest mode) for each VM to hold p2m table, vcpus's vtlb, vhpt,
vpd and so on. 8M p2m table only can hold 1M 's p2m entries(8 bytes per
entry), so the max memory should be 64G for each guests. Since one vcpu
should be configured with one vhpt, vtlb and vpd, so only limited vcpus
are supported. To break the limit, we have two ways, one is  to
increase the data area to 64M or larger, and the other is to decrease
the vtlb and vhpt's size.  Anyway, the best way to  is to determin the
size of data area allocated for guests according to the number of vcpus
and the size of guest memory dynamically. 
 BTW, I have tried to boot guests with 16 vcpus before, and didn't meet
unstable issue.  

>At some point I will
> definately need to do something about that ..... 256 will be my
> minimum target :-)
That should be an easy thing, because I didn't see the hurdles which can
block us to reach this goal. :)
Xiantao

Re: FW: [Bug 117] New: [KVM-IPF] RTL8139 emulated network card can

[Jes Sorensen]

Zhang, Xiantao wrote:
> Hi, Jes
>      Currently, we only supports up to 8 vcpus, and to be safe, I set
> the limit to 4 (Defined in include/asm/kvm_host.h). Maybe you can
> increase the macro KVM_MAX_VCPUS to have a try.  In order to support >8
> vcpus, we can decrease the size of vtlb and vhpt, also defined in
> include/asm/kvm_host.h.  Thanks! :0
> Xiantao

Hi,

I am seeing something interesting here, but it could be a fluke:

I added this printk to my code:

void leave_hypervisor_tail(void)
{
	struct kvm_vcpu *v = current_vcpu;

	if (VMX(v, timer_check)) {
		VMX(v, timer_check) = 0;
		if (VMX(v, itc_check)) {
			if (vcpu_get_itc(v) > VCPU(v, itm)) {
			if (v->vcpu_id > 1)
				printk("vcpu %i irq check\n", v->vcpu_id);

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.

This is when I boot with 8 vcpus.

Cheers,
Jes

Re: FW: [Bug 117] New: [KVM-IPF] RTL8139 emulated network card can

[Jes Sorensen]

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.

Jes

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

[Zhang, Xiantao]

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
	Interesting finding!  Since this is a regression issue, maybe we
can use git-bisect to identify it.  Anyone wants to take it ? Thanks!
Thanks
Xiantao

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

[Zhang, Xiantao]

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
Xiantao   

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

[Zhang, Xiantao]

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

Re: FW: [Bug 117] New: [KVM-IPF] RTL8139 emulated network card can

[Jes Sorensen]

Zhang, Xiantao wrote:
>> 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.  :)

Hi Xiantao,

Sweet! I am looking forward to testing it - or maybe you'd be willing
to bounce me a copy for testing before you post it?

Regards,
Jes

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

[Zhang, Xiantao]

[-- Attachment #1: Type: text/plain, Size: 860 bytes --]

Jes Sorensen wrote:
> Zhang, Xiantao wrote:
>>> 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.  :)
> 
> Hi Xiantao,
> 
> Sweet! I am looking forward to testing it - or maybe you'd be willing
> to bounce me a copy for testing before you post it?

Hi, Jes
	Attached. It! I haven't tested with stress workloads, so once
you find any unstability issue, please let me know.  I just built a
kenel in guest configured with 4 vcpus.:)
Thanks
Xiantao


[-- Attachment #2: 0001-kvm-ia64-Fix-vcpus-halt-emulation.patch --]
[-- Type: application/octet-stream, Size: 8055 bytes --]

From 3bbc6f6c17efa04410cd4f1255e3a0eee769f708 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <xiantao.zhang@intel.com>
Date: Mon, 13 Oct 2008 20:51:51 +0800
Subject: [PATCH] kvm/ia64: Fix vcpus' halt emulation.

Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
---
 arch/ia64/include/asm/kvm_host.h |    3 +-
 arch/ia64/kvm/Makefile           |    3 +-
 arch/ia64/kvm/kvm-ia64.c         |   74 +++++++++++++++++++-------------------
 arch/ia64/kvm/kvm_fw.c           |    9 ++++-
 arch/ia64/kvm/process.c          |    2 +-
 5 files changed, 48 insertions(+), 43 deletions(-)

diff --git a/arch/ia64/include/asm/kvm_host.h b/arch/ia64/include/asm/kvm_host.h
index 85db124..b9e3c7f 100644
--- a/arch/ia64/include/asm/kvm_host.h
+++ b/arch/ia64/include/asm/kvm_host.h
@@ -365,7 +365,8 @@ struct kvm_vcpu_arch {
 	long itc_offset;
 	unsigned long itc_check;
 	unsigned long timer_check;
-	unsigned long timer_pending;
+	unsigned int timer_pending;
+	unsigned int timer_fired;
 
 	unsigned long vrr[8];
 	unsigned long ibr[8];
diff --git a/arch/ia64/kvm/Makefile b/arch/ia64/kvm/Makefile
index cf37f8f..53c7a48 100644
--- a/arch/ia64/kvm/Makefile
+++ b/arch/ia64/kvm/Makefile
@@ -30,7 +30,7 @@ define cmd_offsets
 	 echo "#endif" ) > $@
 endef
 # We use internal rules to avoid the "is up to date" message from make
-arch/ia64/kvm/asm-offsets.s: arch/ia64/kvm/asm-offsets.c
+arch/ia64/kvm/asm-offsets.s: arch/ia64/kvm/asm-offsets.c FORCE
 	$(call if_changed_dep,cc_s_c)
 
 $(obj)/$(offsets-file): arch/ia64/kvm/asm-offsets.s
@@ -53,7 +53,6 @@ endif
 kvm-objs := $(common-objs) kvm-ia64.o kvm_fw.o
 obj-$(CONFIG_KVM) += kvm.o
 
-FORCE : $(obj)/$(offsets-file)
 EXTRA_CFLAGS_vcpu.o += -mfixed-range=f2-f5,f12-f127
 kvm-intel-objs = vmm.o vmm_ivt.o trampoline.o vcpu.o optvfault.o mmio.o \
 	vtlb.o process.o
diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
index c0699f0..48b4998 100644
--- a/arch/ia64/kvm/kvm-ia64.c
+++ b/arch/ia64/kvm/kvm-ia64.c
@@ -325,6 +325,7 @@ static struct kvm_vcpu *lid_to_vcpu(struct kvm *kvm, unsigned long id,
 	return NULL;
 }
 
+
 static int handle_ipi(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
 {
 	struct exit_ctl_data *p = kvm_get_exit_data(vcpu);
@@ -418,33 +419,41 @@ int kvm_emulate_halt(struct kvm_vcpu *vcpu)
 	ktime_t kt;
 	long itc_diff;
 	unsigned long vcpu_now_itc;
-
 	unsigned long expires;
 	struct hrtimer *p_ht = &vcpu->arch.hlt_timer;
 	unsigned long cyc_per_usec = local_cpu_data->cyc_per_usec;
 	struct vpd *vpd = to_host(vcpu->kvm, vcpu->arch.vpd);
 
-	vcpu_now_itc = ia64_getreg(_IA64_REG_AR_ITC) + vcpu->arch.itc_offset;
+	if (irqchip_in_kernel(vcpu->kvm)) {
 
-	if (time_after(vcpu_now_itc, vpd->itm)) {
-		vcpu->arch.timer_check = 1;
-		return 1;
-	}
-	itc_diff = vpd->itm - vcpu_now_itc;
-	if (itc_diff < 0)
-		itc_diff = -itc_diff;
+		vcpu_now_itc = ia64_getreg(_IA64_REG_AR_ITC) + vcpu->arch.itc_offset;
 
-	expires = div64_u64(itc_diff, cyc_per_usec);
-	kt = ktime_set(0, 1000 * expires);
-	vcpu->arch.ht_active = 1;
-	hrtimer_start(p_ht, kt, HRTIMER_MODE_ABS);
+		if (time_after(vcpu_now_itc, vpd->itm)) {
+			vcpu->arch.timer_check = 1;
+			return 1;
+		}
+		itc_diff = vpd->itm - vcpu_now_itc;
+		if (itc_diff < 0)
+			itc_diff = -itc_diff;
+
+		expires = div64_u64(itc_diff, cyc_per_usec);
+		kt = ktime_set(0, 1000 * expires);
+
+		down_read(&vcpu->kvm->slots_lock);
+		vcpu->arch.ht_active = 1;
+		hrtimer_start(p_ht, kt, HRTIMER_MODE_ABS);
 
-	if (irqchip_in_kernel(vcpu->kvm)) {
 		vcpu->arch.mp_state = KVM_MP_STATE_HALTED;
 		kvm_vcpu_block(vcpu);
 		hrtimer_cancel(p_ht);
 		vcpu->arch.ht_active = 0;
 
+		if (test_and_clear_bit(KVM_REQ_UNHALT, &vcpu->requests))
+			if (vcpu->arch.mp_state == KVM_MP_STATE_HALTED)
+				vcpu->arch.mp_state =
+					KVM_MP_STATE_RUNNABLE;
+		up_read(&vcpu->kvm->slots_lock);
+
 		if (vcpu->arch.mp_state != KVM_MP_STATE_RUNNABLE)
 			return -EINTR;
 		return 1;
@@ -484,10 +493,6 @@ static int (*kvm_vti_exit_handlers[])(struct kvm_vcpu *vcpu,
 static const int kvm_vti_max_exit_handlers =
 		sizeof(kvm_vti_exit_handlers)/sizeof(*kvm_vti_exit_handlers);
 
-static void kvm_prepare_guest_switch(struct kvm_vcpu *vcpu)
-{
-}
-
 static uint32_t kvm_get_exit_reason(struct kvm_vcpu *vcpu)
 {
 	struct exit_ctl_data *p_exit_data;
@@ -600,10 +605,9 @@ static int __vcpu_run(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
 
 again:
 	preempt_disable();
-
-	kvm_prepare_guest_switch(vcpu);
 	local_irq_disable();
 
+
 	if (signal_pending(current)) {
 		local_irq_enable();
 		preempt_enable();
@@ -614,7 +618,7 @@ again:
 
 	vcpu->guest_mode = 1;
 	kvm_guest_enter();
-
+	down_read(&vcpu->kvm->slots_lock);
 	r = vti_vcpu_run(vcpu, kvm_run);
 	if (r < 0) {
 		local_irq_enable();
@@ -634,9 +638,8 @@ again:
 	 * But we need to prevent reordering, hence this barrier():
 	 */
 	barrier();
-
 	kvm_guest_exit();
-
+	up_read(&vcpu->kvm->slots_lock);
 	preempt_enable();
 
 	r = kvm_handle_exit(kvm_run, vcpu);
@@ -673,6 +676,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
 
 	if (unlikely(vcpu->arch.mp_state == KVM_MP_STATE_UNINITIALIZED)) {
 		kvm_vcpu_block(vcpu);
+		clear_bit(KVM_REQ_UNHALT, &vcpu->requests);
 		vcpu_put(vcpu);
 		return -EAGAIN;
 	}
@@ -1123,14 +1127,14 @@ static enum hrtimer_restart hlt_timer_fn(struct hrtimer *data)
 	wait_queue_head_t *q;
 
 	vcpu  = container_of(data, struct kvm_vcpu, arch.hlt_timer);
+	q = &vcpu->wq;
+
 	if (vcpu->arch.mp_state != KVM_MP_STATE_HALTED)
 		goto out;
-
-	q = &vcpu->wq;
-	if (waitqueue_active(q)) {
-		vcpu->arch.mp_state = KVM_MP_STATE_RUNNABLE;
+	vcpu->arch.timer_fired = 1;
+	if (waitqueue_active(q))
 		wake_up_interruptible(q);
-	}
+
 out:
 	vcpu->arch.timer_check = 1;
 	return HRTIMER_NORESTART;
@@ -1700,12 +1704,14 @@ static void vcpu_kick_intr(void *info)
 void kvm_vcpu_kick(struct kvm_vcpu *vcpu)
 {
 	int ipi_pcpu = vcpu->cpu;
+	int cpu = get_cpu();
 
 	if (waitqueue_active(&vcpu->wq))
 		wake_up_interruptible(&vcpu->wq);
 
-	if (vcpu->guest_mode)
+	if (vcpu->guest_mode && cpu != ipi_pcpu)
 		smp_call_function_single(ipi_pcpu, vcpu_kick_intr, vcpu, 0);
+	put_cpu();
 }
 
 int kvm_apic_set_irq(struct kvm_vcpu *vcpu, u8 vec, u8 trig)
@@ -1715,13 +1721,7 @@ int kvm_apic_set_irq(struct kvm_vcpu *vcpu, u8 vec, u8 trig)
 
 	if (!test_and_set_bit(vec, &vpd->irr[0])) {
 		vcpu->arch.irq_new_pending = 1;
-		 if (vcpu->arch.mp_state == KVM_MP_STATE_RUNNABLE)
-			kvm_vcpu_kick(vcpu);
-		else if (vcpu->arch.mp_state == KVM_MP_STATE_HALTED) {
-			vcpu->arch.mp_state = KVM_MP_STATE_RUNNABLE;
-			if (waitqueue_active(&vcpu->wq))
-				wake_up_interruptible(&vcpu->wq);
-		}
+		kvm_vcpu_kick(vcpu);
 		return 1;
 	}
 	return 0;
@@ -1791,7 +1791,7 @@ int kvm_cpu_has_interrupt(struct kvm_vcpu *vcpu)
 
 int kvm_cpu_has_pending_timer(struct kvm_vcpu *vcpu)
 {
-	return 0;
+	return vcpu->arch.timer_fired;
 }
 
 gfn_t unalias_gfn(struct kvm *kvm, gfn_t gfn)
diff --git a/arch/ia64/kvm/kvm_fw.c b/arch/ia64/kvm/kvm_fw.c
index 0c69d9e..cb7600b 100644
--- a/arch/ia64/kvm/kvm_fw.c
+++ b/arch/ia64/kvm/kvm_fw.c
@@ -286,6 +286,12 @@ static  u64 kvm_get_pal_call_index(struct kvm_vcpu *vcpu)
 	return index;
 }
 
+static void prepare_for_halt(struct kvm_vcpu *vcpu)
+{
+	vcpu->arch.timer_pending = 1;
+	vcpu->arch.timer_fired = 0;
+}
+
 int kvm_pal_emul(struct kvm_vcpu *vcpu, struct kvm_run *run)
 {
 
@@ -304,11 +310,10 @@ int kvm_pal_emul(struct kvm_vcpu *vcpu, struct kvm_run *run)
 		break;
 	case PAL_HALT_LIGHT:
 	{
-		vcpu->arch.timer_pending = 1;
 		INIT_PAL_STATUS_SUCCESS(result);
+		prepare_for_halt(vcpu);
 		if (kvm_highest_pending_irq(vcpu) == -1)
 			ret = kvm_emulate_halt(vcpu);
-
 	}
 		break;
 
diff --git a/arch/ia64/kvm/process.c b/arch/ia64/kvm/process.c
index 3417783..8008173 100644
--- a/arch/ia64/kvm/process.c
+++ b/arch/ia64/kvm/process.c
@@ -713,7 +713,7 @@ void leave_hypervisor_tail(void)
 				if (!(VCPU(v, itv) & (1 << 16))) {
 					vcpu_pend_interrupt(v, VCPU(v, itv)
 							& 0xff);
-				VMX(v, itc_check) = 0;
+					VMX(v, itc_check) = 0;
 				} else {
 					v->arch.timer_pending = 1;
 				}
-- 
1.5.1

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

[Zhang, Xiantao]

[-- Attachment #1: Type: text/plain, Size: 1562 bytes --]

Jes Sorensen wrote:
> Zhang, Xiantao wrote:
>>> What is the reason for the max 8 limitation?
>> In current implementation, we allocated 16M data area(Mapped by one
>> pair of TR in guest mode) for each VM to hold p2m table, vcpus's
>> vtlb, vhpt, vpd and so on. 8M p2m table only can hold 1M 's p2m
>> entries(8 bytes per entry), so the max memory should be 64G for each
>> guests. Since one vcpu should be configured with one vhpt, vtlb and
>> vpd, so only limited vcpus are supported. To break the limit, we
>> have two ways, one is  to increase the data area to 64M or larger,
>> and the other is to decrease the vtlb and vhpt's size.  Anyway, the
>> best way to  is to determin the size of data area allocated for
>> guests according to the number of vcpus and the size of guest memory
>>  dynamically. BTW, I have tried to boot guests with 16 vcpus before,
>> and didn't meet unstable issue.
> 
> Hi Xiantao,
> 
> Just to make sure I understand this right - this 16M area is what is
> being allocated into kvm_vmm_base and mapped at KVM_VMM_BASE? From
> what I see, the p2m table is basically the second half of the 16MB
> mapping, is that correct? If so, it should be quite easy to allocate
> a larger chunk if we need more than 64GB??
> 
> I am going to look into doing this then.


Hi, Jes
	With attached patch, I can bootup 16 vcpus for guests, and it
should support 384G guest memory and 64 vcpus, but I haven't tested it.
To support >16 vcpus, seems we have to hack userspace, could you have a
look ? 
Thanks
Xiantao

[-- Attachment #2: cleanup.patch --]
[-- Type: application/octet-stream, Size: 17431 bytes --]

diff --git a/arch/ia64/include/asm/kvm.h b/arch/ia64/include/asm/kvm.h
index f38472a..de02c18 100644
--- a/arch/ia64/include/asm/kvm.h
+++ b/arch/ia64/include/asm/kvm.h
@@ -207,5 +207,4 @@ struct kvm_sregs {
 
 struct kvm_fpu {
 };
-
 #endif
diff --git a/arch/ia64/include/asm/kvm_host.h b/arch/ia64/include/asm/kvm_host.h
index b9e3c7f..e98f6f0 100644
--- a/arch/ia64/include/asm/kvm_host.h
+++ b/arch/ia64/include/asm/kvm_host.h
@@ -23,17 +23,6 @@
 #ifndef __ASM_KVM_HOST_H
 #define __ASM_KVM_HOST_H
 
-
-#include <linux/types.h>
-#include <linux/mm.h>
-#include <linux/kvm.h>
-#include <linux/kvm_para.h>
-#include <linux/kvm_types.h>
-
-#include <asm/pal.h>
-#include <asm/sal.h>
-
-#define KVM_MAX_VCPUS 4
 #define KVM_MEMORY_SLOTS 32
 /* memory slots that does not exposed to userspace */
 #define KVM_PRIVATE_MEM_SLOTS 4
@@ -52,68 +41,127 @@
 #define EXIT_REASON_PTC_G		8
 
 /*Define vmm address space and vm data space.*/
-#define KVM_VMM_SIZE (16UL<<20)
+#define KVM_VMM_SIZE (__IA64_UL_CONST(16)<<20)
 #define KVM_VMM_SHIFT 24
-#define KVM_VMM_BASE 0xD000000000000000UL
-#define VMM_SIZE (8UL<<20)
+#define KVM_VMM_BASE 0xD000000000000000
+#define VMM_SIZE (__IA64_UL_CONST(8)<<20)
 
 /*
  * Define vm_buffer, used by PAL Services, base address.
  * Note: vmbuffer is in the VMM-BLOCK, the size must be < 8M
  */
 #define KVM_VM_BUFFER_BASE (KVM_VMM_BASE + VMM_SIZE)
-#define KVM_VM_BUFFER_SIZE (8UL<<20)
-
-/*Define Virtual machine data layout.*/
-#define KVM_VM_DATA_SHIFT  24
-#define KVM_VM_DATA_SIZE (1UL << KVM_VM_DATA_SHIFT)
-#define KVM_VM_DATA_BASE (KVM_VMM_BASE + KVM_VMM_SIZE)
-
-
-#define KVM_P2M_BASE    KVM_VM_DATA_BASE
-#define KVM_P2M_OFS     0
-#define KVM_P2M_SIZE    (8UL << 20)
-
-#define KVM_VHPT_BASE   (KVM_P2M_BASE + KVM_P2M_SIZE)
-#define KVM_VHPT_OFS    KVM_P2M_SIZE
-#define KVM_VHPT_BLOCK_SIZE   (2UL << 20)
-#define VHPT_SHIFT      18
-#define VHPT_SIZE       (1UL << VHPT_SHIFT)
-#define VHPT_NUM_ENTRIES (1<<(VHPT_SHIFT-5))
-
-#define KVM_VTLB_BASE   (KVM_VHPT_BASE+KVM_VHPT_BLOCK_SIZE)
-#define KVM_VTLB_OFS    (KVM_VHPT_OFS+KVM_VHPT_BLOCK_SIZE)
-#define KVM_VTLB_BLOCK_SIZE   (1UL<<20)
-#define VTLB_SHIFT      17
-#define VTLB_SIZE       (1UL<<VTLB_SHIFT)
-#define VTLB_NUM_ENTRIES (1<<(VTLB_SHIFT-5))
-
-#define KVM_VPD_BASE   (KVM_VTLB_BASE+KVM_VTLB_BLOCK_SIZE)
-#define KVM_VPD_OFS    (KVM_VTLB_OFS+KVM_VTLB_BLOCK_SIZE)
-#define KVM_VPD_BLOCK_SIZE   (2UL<<20)
-#define VPD_SHIFT       16
-#define VPD_SIZE        (1UL<<VPD_SHIFT)
-
-#define KVM_VCPU_BASE   (KVM_VPD_BASE+KVM_VPD_BLOCK_SIZE)
-#define KVM_VCPU_OFS    (KVM_VPD_OFS+KVM_VPD_BLOCK_SIZE)
-#define KVM_VCPU_BLOCK_SIZE   (2UL<<20)
-#define VCPU_SHIFT 18
-#define VCPU_SIZE (1UL<<VCPU_SHIFT)
-#define MAX_VCPU_NUM KVM_VCPU_BLOCK_SIZE/VCPU_SIZE
-
-#define KVM_VM_BASE     (KVM_VCPU_BASE+KVM_VCPU_BLOCK_SIZE)
-#define KVM_VM_OFS      (KVM_VCPU_OFS+KVM_VCPU_BLOCK_SIZE)
-#define KVM_VM_BLOCK_SIZE     (1UL<<19)
-
-#define KVM_MEM_DIRTY_LOG_BASE (KVM_VM_BASE+KVM_VM_BLOCK_SIZE)
-#define KVM_MEM_DIRTY_LOG_OFS  (KVM_VM_OFS+KVM_VM_BLOCK_SIZE)
-#define KVM_MEM_DIRTY_LOG_SIZE (1UL<<19)
-
-/* Get vpd, vhpt, tlb, vcpu, base*/
-#define VPD_ADDR(n) (KVM_VPD_BASE+n*VPD_SIZE)
-#define VHPT_ADDR(n) (KVM_VHPT_BASE+n*VHPT_SIZE)
-#define VTLB_ADDR(n) (KVM_VTLB_BASE+n*VTLB_SIZE)
-#define VCPU_ADDR(n) (KVM_VCPU_BASE+n*VCPU_SIZE)
+#define KVM_VM_BUFFER_SIZE (__IA64_UL_CONST(8)<<20)
+
+/*
+ * kvm guest's data aera looks as follow:
+ *
+ *            +----------------------+	-------	KVM_VM_DATA_SIZE
+ *	      |	    vcpu[n]'s data   |	 |     ___________________KVM_STK_OFFSET
+ *     	      |			     |	 |    /			  |
+ *     	      |	       ..........    |	 |   /vcpu's struct&stack |
+ *     	      |	       ..........    |	 |  /---------------------|---- 0
+ *	      |	    vcpu[5]'s data   |	 | /	   vpd		  |
+ *	      |	    vcpu[4]'s data   |	 |/-----------------------|
+ *	      |	    vcpu[3]'s data   |	 /	   vtlb		  |
+ *	      |	    vcpu[2]'s data   |	/|------------------------|
+ *	      |	    vcpu[1]'s data   |/  |	   vhpt		  |
+ *	      |	    vcpu[0]'s data   |____________________________|
+ *            +----------------------+	 |
+ *	      |	   memory dirty log  |	 |
+ *            +----------------------+	 |
+ *	      |	   vm's data struct  |	 |
+ *            +----------------------+	 |
+ *	      |			     |	 |
+ *	      |			     |	 |
+ *	      |			     |	 |
+ *	      |			     |	 |
+ *	      |			     |	 |
+ *	      |			     |	 |
+ *	      |			     |	 |
+ *	      |	  vm's p2m table  |	 |
+ *	      |			     |	 |
+ *            |			     |	 |
+ *	      |			     |	 |  |
+ * vm's data->|			     |   |  |
+ *	      +----------------------+ ------- 0
+ * To support large memory, needs to increase the size of p2m.
+ * To support more vcpus, needs to ensure it has enough space to
+ * hold vcpus' data.
+ */
+
+#define KVM_VM_DATA_SHIFT	26
+#define KVM_VM_DATA_SIZE	(__IA64_UL_CONST(1) << KVM_VM_DATA_SHIFT)
+#define KVM_VM_DATA_BASE	(KVM_VMM_BASE + KVM_VM_DATA_SIZE)
+
+#define KVM_P2M_BASE		KVM_VM_DATA_BASE
+#define KVM_P2M_SIZE		(__IA64_UL_CONST(48) << 20)
+
+#define VHPT_SHIFT		16
+#define VHPT_SIZE		(__IA64_UL_CONST(1) << VHPT_SHIFT)
+#define VHPT_NUM_ENTRIES	(__IA64_UL_CONST(1) << (VHPT_SHIFT-5))
+
+#define VTLB_SHIFT		16
+#define VTLB_SIZE		(__IA64_UL_CONST(1) << VTLB_SHIFT)
+#define VTLB_NUM_ENTRIES	(1UL << (VHPT_SHIFT-5))
+
+#define VPD_SHIFT		16
+#define VPD_SIZE		(__IA64_UL_CONST(1) << VPD_SHIFT)
+
+#define VCPU_STRUCT_SHIFT	16
+#define VCPU_STRUCT_SIZE	(__IA64_UL_CONST(1)<< VCPU_STRUCT_SHIFT)
+
+#define KVM_STK_OFFSET		VCPU_STRUCT_SIZE
+
+#define KVM_VM_STRUCT_SHIFT	19
+#define KVM_VM_STRUCT_SIZE	(__IA64_UL_CONST(1) << KVM_VM_STRUCT_SHIFT)
+
+#define KVM_MEM_DIRY_LOG_SHIFT	19
+#define KVM_MEM_DIRTY_LOG_SIZE (__IA64_UL_CONST(1) << KVM_MEM_DIRY_LOG_SHIFT)
+
+#ifndef __ASSEMBLY__
+
+/*Define the max vcpus and memory for Guests.*/
+#define KVM_MAX_VCPUS	(KVM_VM_DATA_SIZE - KVM_P2M_SIZE - KVM_VM_STRUCT_SIZE -\
+			KVM_MEM_DIRTY_LOG_SIZE) / sizeof(struct kvm_vcpu_data)
+#define KVM_MAX_MEM_SIZE (KVM_P2M_SIZE >> 3 << PAGE_SHIFT)
+
+#include <linux/types.h>
+#include <linux/mm.h>
+#include <linux/kvm.h>
+#include <linux/kvm_para.h>
+#include <linux/kvm_types.h>
+
+#include <asm/pal.h>
+#include <asm/sal.h>
+#include <asm/page.h>
+
+struct kvm_vcpu_data {
+	char vcpu_vhpt[VHPT_SIZE];
+	char vcpu_vtlb[VTLB_SIZE];
+	char vcpu_vpd[VPD_SIZE];
+	char vcpu_struct[VCPU_STRUCT_SIZE];
+};
+
+struct kvm_vm_data {
+	char kvm_p2m[KVM_P2M_SIZE];
+	char kvm_vm_struct[KVM_VM_STRUCT_SIZE];
+	char kvm_mem_dirty_log[KVM_MEM_DIRTY_LOG_SIZE];
+	struct kvm_vcpu_data vcpu_data[KVM_MAX_VCPUS];
+};
+
+#define VCPU_BASE(n)	KVM_VM_DATA_BASE + \
+				offsetof(struct kvm_vm_data, vcpu_data[n])
+#define VM_BASE		KVM_VM_DATA_BASE + \
+				offsetof(struct kvm_vm_data, kvm_vm_struct)
+#define KVM_MEM_DIRTY_LOG_BASE	KVM_VM_DATA_BASE + \
+				offsetof(struct kvm_vm_data, kvm_mem_dirty_log)
+
+#define VHPT_BASE(n) (VCPU_BASE(n) + offsetof(struct kvm_vcpu_data, vcpu_vhpt))
+#define VTLB_BASE(n) (VCPU_BASE(n) + offsetof(struct kvm_vcpu_data, vcpu_vtlb))
+#define VPD_BASE(n)  (VCPU_BASE(n) + offsetof(struct kvm_vcpu_data, vcpu_vpd))
+#define VCPU_STRUCT_BASE(n)	(VCPU_BASE(n) + \
+				offsetof(struct kvm_vcpu_data, vcpu_struct))
 
 /*IO section definitions*/
 #define IOREQ_READ      1
@@ -509,7 +557,7 @@ struct kvm_pt_regs {
 
 static inline struct kvm_pt_regs *vcpu_regs(struct kvm_vcpu *v)
 {
-	return (struct kvm_pt_regs *) ((unsigned long) v + IA64_STK_OFFSET) - 1;
+	return (struct kvm_pt_regs *) ((unsigned long) v + KVM_STK_OFFSET) - 1;
 }
 
 typedef int kvm_vmm_entry(void);
@@ -528,5 +576,6 @@ int kvm_pal_emul(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run);
 void kvm_sal_emul(struct kvm_vcpu *vcpu);
 
 static inline void kvm_inject_nmi(struct kvm_vcpu *vcpu) {}
+#endif /* __ASSEMBLY__*/
 
 #endif
diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
index 1d48c9b..ac0fdf6 100644
--- a/arch/ia64/kvm/kvm-ia64.c
+++ b/arch/ia64/kvm/kvm-ia64.c
@@ -542,7 +542,7 @@ static int kvm_insert_vmm_mapping(struct kvm_vcpu *vcpu)
 	if (r < 0)
 		goto out;
 	vcpu->arch.vmm_tr_slot = r;
-	/*Insert a pairt of tr to map data of vm*/
+	/*Insert a pair of tr to map data of vm*/
 	pte = pte_val(mk_pte_phys(__pa(kvm->arch.vm_base), PAGE_KERNEL));
 	r = ia64_itr_entry(0x3, KVM_VM_DATA_BASE,
 					pte, KVM_VM_DATA_SHIFT);
@@ -578,6 +578,7 @@ static int kvm_vcpu_pre_transition(struct kvm_vcpu *vcpu)
 	vti_set_rr6(vcpu->arch.vmm_rr);
 	return kvm_insert_vmm_mapping(vcpu);
 }
+
 static void kvm_vcpu_post_transition(struct kvm_vcpu *vcpu)
 {
 	kvm_purge_vmm_mapping(vcpu);
@@ -703,27 +704,24 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
 	return r;
 }
 
-/*
- * Allocate 16M memory for every vm to hold its specific data.
- * Its memory map is defined in kvm_host.h.
- */
 static struct kvm *kvm_alloc_kvm(void)
 {
 
 	struct kvm *kvm;
 	uint64_t  vm_base;
 
+	BUG_ON(sizeof(struct kvm) > KVM_VM_STRUCT_SIZE);
+
 	vm_base = __get_free_pages(GFP_KERNEL, get_order(KVM_VM_DATA_SIZE));
 
 	if (!vm_base)
 		return ERR_PTR(-ENOMEM);
-	printk(KERN_DEBUG"kvm: VM data's base Address:0x%lx\n", vm_base);
 
-	/* Zero all pages before use! */
 	memset((void *)vm_base, 0, KVM_VM_DATA_SIZE);
-
-	kvm = (struct kvm *)(vm_base + KVM_VM_OFS);
+	kvm = (struct kvm *)(vm_base +
+			offsetof(struct kvm_vm_data, kvm_vm_struct));
 	kvm->arch.vm_base = vm_base;
+	printk(KERN_DEBUG"kvm: vm's data area:0x%lx\n", vm_base);
 
 	return kvm;
 }
@@ -765,21 +763,12 @@ static void kvm_build_io_pmt(struct kvm *kvm)
 
 static void kvm_init_vm(struct kvm *kvm)
 {
-	long vm_base;
-
 	BUG_ON(!kvm);
 
 	kvm->arch.metaphysical_rr0 = GUEST_PHYSICAL_RR0;
 	kvm->arch.metaphysical_rr4 = GUEST_PHYSICAL_RR4;
 	kvm->arch.vmm_init_rr = VMM_INIT_RR;
 
-	vm_base = kvm->arch.vm_base;
-	if (vm_base) {
-		kvm->arch.vhpt_base = vm_base + KVM_VHPT_OFS;
-		kvm->arch.vtlb_base = vm_base + KVM_VTLB_OFS;
-		kvm->arch.vpd_base  = vm_base + KVM_VPD_OFS;
-	}
-
 	/*
 	 *Fill P2M entries for MMIO/IO ranges
 	 */
@@ -866,7 +855,7 @@ int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
 		goto out;
 	r = copy_from_user(vcpu + 1, regs->saved_stack +
 			sizeof(struct kvm_vcpu),
-			IA64_STK_OFFSET - sizeof(struct kvm_vcpu));
+			KVM_STK_OFFSET - sizeof(struct kvm_vcpu));
 	if (r)
 		goto out;
 	vcpu->arch.exit_data =
@@ -1170,10 +1159,11 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
 		/*Set entry address for first run.*/
 		regs->cr_iip = PALE_RESET_ENTRY;
 
-		/*Initilize itc offset for vcpus*/
+		/*Initialize itc offset for vcpus*/
 		itc_offset = 0UL - ia64_getreg(_IA64_REG_AR_ITC);
-		for (i = 0; i < MAX_VCPU_NUM; i++) {
-			v = (struct kvm_vcpu *)((char *)vcpu + VCPU_SIZE * i);
+		for (i = 0; i < KVM_MAX_VCPUS; i++) {
+			v = (struct kvm_vcpu *)((char *)vcpu +
+					sizeof(struct kvm_vcpu_data) * i);
 			v->arch.itc_offset = itc_offset;
 			v->arch.last_itc = 0;
 		}
@@ -1187,7 +1177,7 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
 	vcpu->arch.apic->vcpu = vcpu;
 
 	p_ctx->gr[1] = 0;
-	p_ctx->gr[12] = (unsigned long)((char *)vmm_vcpu + IA64_STK_OFFSET);
+	p_ctx->gr[12] = (unsigned long)((char *)vmm_vcpu + KVM_STK_OFFSET);
 	p_ctx->gr[13] = (unsigned long)vmm_vcpu;
 	p_ctx->psr = 0x1008522000UL;
 	p_ctx->ar[40] = FPSR_DEFAULT; /*fpsr*/
@@ -1222,12 +1212,12 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
 	vcpu->arch.hlt_timer.function = hlt_timer_fn;
 
 	vcpu->arch.last_run_cpu = -1;
-	vcpu->arch.vpd = (struct vpd *)VPD_ADDR(vcpu->vcpu_id);
+	vcpu->arch.vpd = (struct vpd *)VPD_BASE(vcpu->vcpu_id);
 	vcpu->arch.vsa_base = kvm_vsa_base;
 	vcpu->arch.__gp = kvm_vmm_gp;
 	vcpu->arch.dirty_log_lock_pa = __pa(&kvm->arch.dirty_log_lock);
-	vcpu->arch.vhpt.hash = (struct thash_data *)VHPT_ADDR(vcpu->vcpu_id);
-	vcpu->arch.vtlb.hash = (struct thash_data *)VTLB_ADDR(vcpu->vcpu_id);
+	vcpu->arch.vhpt.hash = (struct thash_data *)VHPT_BASE(vcpu->vcpu_id);
+	vcpu->arch.vtlb.hash = (struct thash_data *)VTLB_BASE(vcpu->vcpu_id);
 	init_ptce_info(vcpu);
 
 	r = 0;
@@ -1277,12 +1267,22 @@ struct kvm_vcpu *kvm_arch_vcpu_create(struct kvm *kvm,
 	int r;
 	int cpu;
 
+	BUG_ON(sizeof(struct kvm_vcpu) > VCPU_STRUCT_SIZE/2);
+
+	r = -EINVAL;
+	if (id >= KVM_MAX_VCPUS) {
+		printk(KERN_ERR"kvm: Can't configure vcpus > %ld",
+				KVM_MAX_VCPUS);
+		goto fail;
+	}
+
 	r = -ENOMEM;
 	if (!vm_base) {
 		printk(KERN_ERR"kvm: Create vcpu[%d] error!\n", id);
 		goto fail;
 	}
-	vcpu = (struct kvm_vcpu *)(vm_base + KVM_VCPU_OFS + VCPU_SIZE * id);
+	vcpu = (struct kvm_vcpu *)(vm_base + offsetof(struct kvm_vm_data,
+					vcpu_data[id].vcpu_struct));
 	vcpu->kvm = kvm;
 
 	cpu = get_cpu();
@@ -1400,7 +1400,7 @@ int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
 					sizeof(union context));
 	if (r)
 		goto out;
-	r = copy_to_user(regs->saved_stack, (void *)vcpu, IA64_STK_OFFSET);
+	r = copy_to_user(regs->saved_stack, (void *)vcpu, KVM_STK_OFFSET);
 	if (r)
 		goto out;
 	SAVE_REGS(mp_state);
@@ -1635,8 +1635,8 @@ static int kvm_ia64_sync_dirty_log(struct kvm *kvm,
 	struct kvm_memory_slot *memslot;
 	int r, i;
 	long n, base;
-	unsigned long *dirty_bitmap = (unsigned long *)((void *)kvm - KVM_VM_OFS
-					+ KVM_MEM_DIRTY_LOG_OFS);
+	unsigned long *dirty_bitmap = (unsigned long *)(kvm->arch.vm_base +
+			offsetof(struct kvm_vm_data, kvm_mem_dirty_log));
 
 	r = -EINVAL;
 	if (log->slot >= KVM_MEMORY_SLOTS)
diff --git a/arch/ia64/kvm/kvm_minstate.h b/arch/ia64/kvm/kvm_minstate.h
index 2cc41d1..5fa5760 100644
--- a/arch/ia64/kvm/kvm_minstate.h
+++ b/arch/ia64/kvm/kvm_minstate.h
@@ -24,6 +24,8 @@
 #include <asm/asmmacro.h>
 #include <asm/types.h>
 #include <asm/kregs.h>
+#include <asm/kvm_host.h>
+
 #include "asm-offsets.h"
 
 #define KVM_MINSTATE_START_SAVE_MIN	     					\
@@ -33,7 +35,7 @@
 	addl r22 = VMM_RBS_OFFSET,r1;            /* compute base of RBS */	\
 	;;									\
 	lfetch.fault.excl.nt1 [r22];						\
-	addl r1 = IA64_STK_OFFSET-VMM_PT_REGS_SIZE,r1;  /* compute base of memory stack */  \
+	addl r1 = KVM_STK_OFFSET-VMM_PT_REGS_SIZE,r1;  /* compute base of memory stack */  \
 	mov r23 = ar.bspstore;			/* save ar.bspstore */          \
 	;;									\
 	mov ar.bspstore = r22;				/* switch to kernel RBS */\
diff --git a/arch/ia64/kvm/misc.h b/arch/ia64/kvm/misc.h
index e585c46..c2ad19a 100644
--- a/arch/ia64/kvm/misc.h
+++ b/arch/ia64/kvm/misc.h
@@ -27,7 +27,8 @@
  */
 static inline uint64_t *kvm_host_get_pmt(struct kvm *kvm)
 {
-	return (uint64_t *)(kvm->arch.vm_base + KVM_P2M_OFS);
+	return (uint64_t *)(kvm->arch.vm_base + 
+				offsetof(struct kvm_vm_data, kvm_p2m ));
 }
 
 static inline void kvm_set_pmt_entry(struct kvm *kvm, gfn_t gfn,
diff --git a/arch/ia64/kvm/vcpu.c b/arch/ia64/kvm/vcpu.c
index e44027c..a528d70 100644
--- a/arch/ia64/kvm/vcpu.c
+++ b/arch/ia64/kvm/vcpu.c
@@ -816,8 +816,9 @@ static void vcpu_set_itc(struct kvm_vcpu *vcpu, u64 val)
 	unsigned long vitv = VCPU(vcpu, itv);
 
 	if (vcpu->vcpu_id == 0) {
-		for (i = 0; i < MAX_VCPU_NUM; i++) {
-			v = (struct kvm_vcpu *)((char *)vcpu + VCPU_SIZE * i);
+		for (i = 0; i < KVM_MAX_VCPUS; i++) {
+			v = (struct kvm_vcpu *)((char *)vcpu +
+					sizeof(struct kvm_vcpu_data) * i);
 			VMX(v, itc_offset) = itc_offset;
 			VMX(v, last_itc) = 0;
 		}
diff --git a/arch/ia64/kvm/vcpu.h b/arch/ia64/kvm/vcpu.h
index 341e3fe..5ed7896 100644
--- a/arch/ia64/kvm/vcpu.h
+++ b/arch/ia64/kvm/vcpu.h
@@ -33,9 +33,8 @@
 
 #ifndef __ASSEMBLY__
 #include "vti.h"
-
-#include <linux/kvm_host.h>
 #include <linux/spinlock.h>
+#include <linux/kvm_host.h>
 
 typedef unsigned long IA64_INST;
 
diff --git a/arch/ia64/kvm/vmm_ivt.S b/arch/ia64/kvm/vmm_ivt.S
index c1d7251..55294b6 100644
--- a/arch/ia64/kvm/vmm_ivt.S
+++ b/arch/ia64/kvm/vmm_ivt.S
@@ -54,7 +54,6 @@
  * Table is based upon EAS2.6 (Oct 1999)
  */
 
-
 #include <asm/asmmacro.h>
 #include <asm/cache.h>
 #include <asm/pgtable.h>
@@ -64,20 +63,12 @@
 #include "kvm_minstate.h"
 #include "vti.h"
 
-#if 1
-# define PSR_DEFAULT_BITS   psr.ac
-#else
-# define PSR_DEFAULT_BITS   0
-#endif
-
-
 #define KVM_FAULT(n)    \
     kvm_fault_##n:;          \
     mov r19=n;;          \
     br.sptk.many kvm_fault_##n;         \
     ;;                  \
 
-
 #define KVM_REFLECT(n)    \
     mov r31=pr;           \
     mov r19=n;       /* prepare to save predicates */ \
@@ -87,16 +78,11 @@
 (p7)br.sptk.many kvm_dispatch_reflection;        \
     br.sptk.many kvm_panic;      \
 
-
 GLOBAL_ENTRY(kvm_panic)
     br.sptk.many kvm_panic
     ;;
 END(kvm_panic)
 
-
-
-
-
     .section .text.ivt,"ax"
 
     .align 32768    // align on 32KB boundary
@@ -108,7 +94,6 @@ ENTRY(kvm_vhpt_miss)
     KVM_FAULT(0)
 END(kvm_vhpt_miss)
 
-
     .org kvm_ia64_ivt+0x400
 ////////////////////////////////////////////////////////////////
 // 0x0400 Entry 1 (size 64 bundles) ITLB (21)
diff --git a/arch/ia64/kvm/vtlb.c b/arch/ia64/kvm/vtlb.c
index e22b933..6b6307a 100644
--- a/arch/ia64/kvm/vtlb.c
+++ b/arch/ia64/kvm/vtlb.c
@@ -183,8 +183,8 @@ void mark_pages_dirty(struct kvm_vcpu *v, u64 pte, u64 ps)
 	u64 i, dirty_pages = 1;
 	u64 base_gfn = (pte&_PAGE_PPN_MASK) >> PAGE_SHIFT;
 	spinlock_t *lock = __kvm_va(v->arch.dirty_log_lock_pa);
-	void *dirty_bitmap = (void *)v - (KVM_VCPU_OFS + v->vcpu_id * VCPU_SIZE)
-						+ KVM_MEM_DIRTY_LOG_OFS;
+	void *dirty_bitmap = (void *)KVM_MEM_DIRTY_LOG_BASE;
+
 	dirty_pages <<= ps <= PAGE_SHIFT ? 0 : ps - PAGE_SHIFT;
 
 	vmm_spin_lock(lock);

Re: FW: [Bug 117] New: [KVM-IPF] RTL8139 emulated network card can

[Jes Sorensen]

Zhang, Xiantao wrote:
> Hi, Jes
> 	With attached patch, I can bootup 16 vcpus for guests, and it
> should support 384G guest memory and 64 vcpus, but I haven't tested it.
> To support >16 vcpus, seems we have to hack userspace, could you have a
> look ? 
> Thanks
> Xiantao

Hi Xiantao,

With this patch I can boot 16 vcpus, I get a segfault from qemu if I
try to go higher, even though I set qemu to 64. I will see whats going
wrong.

Trying to boot with 200GB of ram right now, I only have 256GB in the
test machine I am using right now.

Cheers,
Jes

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

[Zhang, Xiantao]

Jes Sorensen wrote:
> Zhang, Xiantao wrote:
>> Hi, Jes
>> 	With attached patch, I can bootup 16 vcpus for guests, and it
>> should support 384G guest memory and 64 vcpus, but I haven't tested
>> it. To support >16 vcpus, seems we have to hack userspace, could you
>> have a look ? Thanks
>> Xiantao
> 
> Hi Xiantao,
> 
> With this patch I can boot 16 vcpus, I get a segfault from qemu if I
> try to go higher, even though I set qemu to 64. I will see whats going
> wrong.

I also run into the issue, but seems it is casued by userspace side. 
Xiantao


> Trying to boot with 200GB of ram right now, I only have 256GB in the
> test machine I am using right now.

Wish your good news! I just had a SDP with 32G memory at hand. :(

> Cheers,
> Jes

Re: FW: [Bug 117] New: [KVM-IPF] RTL8139 emulated network card can

[Jes Sorensen]

Zhang, Xiantao wrote:
> Jes Sorensen wrote:
>> With this patch I can boot 16 vcpus, I get a segfault from qemu if I
>> try to go higher, even though I set qemu to 64. I will see whats going
>> wrong.
> 
> I also run into the issue, but seems it is casued by userspace side. 

Yes I think so, I will try and see if I can fix it.

>> Trying to boot with 200GB of ram right now, I only have 256GB in the
>> test machine I am using right now.
> 
> Wish your good news! I just had a SDP with 32G memory at hand. :(

Oh, I just found out we have a 1TB Montvale system in-house, but even at
200GB, it is taking a looooooong time to start. I need to look at that
first I think.

Cheers,
Jes

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

[Zhang, Xiantao]

Jes Sorensen wrote:
> Zhang, Xiantao wrote:
>> Jes Sorensen wrote:
>>> With this patch I can boot 16 vcpus, I get a segfault from qemu if I
>>> try to go higher, even though I set qemu to 64. I will see whats
>>> going wrong.
>> 
>> I also run into the issue, but seems it is casued by userspace side.
> 
> Yes I think so, I will try and see if I can fix it.
> 
>>> Trying to boot with 200GB of ram right now, I only have 256GB in the
>>> test machine I am using right now.
>> 
>> Wish your good news! I just had a SDP with 32G memory at hand. :(
> 
> Oh, I just found out we have a 1TB Montvale system in-house, but even
> at 200GB, it is taking a looooooong time to start. I need to look at
> that first I think.

Tooooooooooooooo rich you are!!!  But I think 200G is enough to verify
the logic. Certainly, more memory should be better :-)
Xiantao

> Cheers,
> Jes

Re: FW: [Bug 117] New: [KVM-IPF] RTL8139 emulated network card can

[Jes Sorensen]

Zhang, Xiantao wrote:
> Jes Sorensen wrote:
>> Oh, I just found out we have a 1TB Montvale system in-house, but even
>> at 200GB, it is taking a looooooong time to start. I need to look at
>> that first I think.
> 
> Tooooooooooooooo rich you are!!!  But I think 200G is enough to verify
> the logic. Certainly, more memory should be better :-)

Haha, I wouldn't be able to pay for the electricity for it :-)
It booted, 200GB, but it took like 20 minutes for qemu to init the
memory and start booting. I think I have to work on that too :-)

Cheers,
Jes

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

[Zhang, Xiantao]

Jes Sorensen wrote:
> Zhang, Xiantao wrote:
>> Jes Sorensen wrote:
>>> Oh, I just found out we have a 1TB Montvale system in-house, but
>>> even at 200GB, it is taking a looooooong time to start. I need to
>>> look at that first I think.
>> 
>> Tooooooooooooooo rich you are!!!  But I think 200G is enough to
>> verify the logic. Certainly, more memory should be better :-)
> 
> Haha, I wouldn't be able to pay for the electricity for it :-)
> It booted, 200GB, but it took like 20 minutes for qemu to init the
> memory and start booting. I think I have to work on that too :-)
Hi, Jes
     Good news!!  I have sent the patch to mailing list and hope Avi to
merge it into 2.6.28.  BTW, in future we may rely on you to test guests
configured with so large memory, seems only SGI  has so powerful
mainframes :-)
Thanks
Xiantao

Re: FW: [Bug 117] New: [KVM-IPF] RTL8139 emulated network card can

[Jes Sorensen]

Zhang, Xiantao wrote:

> Hi, Jes
>      Good news!!  I have sent the patch to mailing list and hope Avi to
> merge it into 2.6.28.  BTW, in future we may rely on you to test guests
> configured with so large memory, seems only SGI  has so powerful
> mainframes :-)

Cool!

No problem, part of my target is to make KVM scale to big systems, so
I think my manager will be happy I spend some time on this type of
testing :-)

Cheers,
Jes