Re: [PATCHEs]: support more than 32 VCPUs in guests

[Mukesh Rathor <mukesh.rathor@oracle.com>]

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

On Tue, 15 Jun 2010 09:30:35 +0100
Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> On 06/15/2010 03:49 AM, Mukesh Rathor wrote:
> > On Mon, 14 Jun 2010 10:37:30 +0100
> > Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> >
> >   
> >> On 06/10/2010 03:13 AM, Mukesh Rathor wrote:
> >>     
> >>> Well, BUG_ON is only triggered if booting more than 32 VCPUs on a
> >>> *very old* xen (pre xen 3.1.0). 
> >>>
> >>> Looking at code closely, we could just set setup_max_cpus to 32
> >>> some where in xen function, perhaps even in xen_vcpu_setup().
> >>> That way later in smp_init() it would just be ok. 
> >>>   
> >>>       
> >> Yes.
> >>
> >>     
> >>> One thing tho, the per cpus areas are already setup at that point,
> >>> so that would need to be cleaned. BTW, I don't understand why 
> >>> have_vcpu_info_placement is set to 0 in xen_guest_init()? 
> >>>   
> >>>       
> >> xen_guest_init is used by the pvhvm path, and hvm domains don't
> >> have a notion of vcpu info placement.
> >>
> >>     
> >>> What minimum version of xen is required to run pvops kernel?
> >>>   
> >>>       
> >> In theory it should be back-compatible for all Xen 3, but in
> >> practice it tweaks lots of bugs in older Xens (particularly
> >> 32-on-64).  I don't know that anyone has definitively established
> >> an earliest version.  I implemented vcpu info placement for use in
> >> pvops kernels, but it was never my intention that it be an
> >> absolute requirement.
> >>
> >>     J
> >>     
> > Ok, attached  patch without BUG_ON. Please feel free to modify
> > to your liking also.
> >   
> 
> It looks like you smashed all the tabs into spaces so its hard to see
> what you've changed in the diff.  I'll fix it up and give it a
> look-over.
> 
>     J

Sorry, I've tabs turned off because patches I submit to other product I
work on must be tab free.  Anyways, re attached a new one with tabs.

thanks again,
Mukesh

Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>




[-- Attachment #2: pvops.diff --]
[-- Type: text/x-patch, Size: 1208 bytes --]

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 615897c..fe24c32 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -116,13 +116,17 @@ static void xen_vcpu_setup(int cpu)
 	struct vcpu_info *vcpup;
 
 	BUG_ON(HYPERVISOR_shared_info == &xen_dummy_shared_info);
-	per_cpu(xen_vcpu, cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu];
 
-	if (!have_vcpu_info_placement)
-		return;		/* already tested, not available */
+	if (cpu < MAX_VIRT_CPUS)
+		per_cpu(xen_vcpu,cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu];
 
-	vcpup = &per_cpu(xen_vcpu_info, cpu);
+	if (!have_vcpu_info_placement) {
+		if (cpu >= MAX_VIRT_CPUS && setup_max_cpus > MAX_VIRT_CPUS)
+			setup_max_cpus = MAX_VIRT_CPUS;
+		return;
+	}
 
+	vcpup = &per_cpu(xen_vcpu_info, cpu);
 	info.mfn = arbitrary_virt_to_mfn(vcpup);
 	info.offset = offset_in_page(vcpup);
 
@@ -137,6 +141,8 @@ static void xen_vcpu_setup(int cpu)
 	if (err) {
 		printk(KERN_DEBUG "register_vcpu_info failed: err=%d\n", err);
 		have_vcpu_info_placement = 0;
+		if (setup_max_cpus > MAX_VIRT_CPUS)
+			setup_max_cpus = MAX_VIRT_CPUS;
 	} else {
 		/* This cpu is using the registered vcpu info, even if
 		   later ones fail to. */

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel