Re: PV i386 patch

2011-12-17 Thread Sean Bruno
On Fri, 2011-12-16 at 11:32 -0800, Alan Cox wrote:
 Is anyone here actively working on fixing problems with SMP support 
 under PV i386?  While doing some other maintenance on the 
 vm_page_alloc() callers in the source tree, I happened to take a look at 
 cpu_initialize_context() in mp_machdep.c.  This function is involved in 
 bringing up the 2nd, 3rd, etc. CPUs on an SMP system.  I spotted a 
 couple obvious errors.  First, the size parameter given to kmem_*() 
 functions is expected to be in terms of bytes and not pages.  Second, I 
 believe that PV i386 requires PAE to be used.  If so, there are out of 
 range accesses to the array m[].
 
 Index: i386/xen/mp_machdep.c
 ===
 --- i386/xen/mp_machdep.c   (revision 228561)
 +++ i386/xen/mp_machdep.c   (working copy)
 @@ -810,7 +810,7 @@ cpu_initialize_context(unsigned int cpu)
   {
  /* vcpu_guest_context_t is too large to allocate on the stack.
   * Hence we allocate statically and protect it with a lock */
 -   vm_page_t m[4];
 +   vm_page_t m[NPGPTD + 2];
  static vcpu_guest_context_t ctxt;
  vm_offset_t boot_stack;
  vm_offset_t newPTD;
 @@ -831,8 +831,8 @@ cpu_initialize_context(unsigned int cpu)
  pmap_zero_page(m[i]);
 
  }
 -   boot_stack = kmem_alloc_nofault(kernel_map, 1);
 -   newPTD = kmem_alloc_nofault(kernel_map, NPGPTD);
 +   boot_stack = kmem_alloc_nofault(kernel_map, PAGE_SIZE);
 +   newPTD = kmem_alloc_nofault(kernel_map, NPGPTD * PAGE_SIZE);
  ma[0] = VM_PAGE_TO_MACH(m[0])|PG_V;
 
   #ifdef PAE
 @@ -854,7 +854,7 @@ cpu_initialize_context(unsigned int cpu)
  nkpt*sizeof(vm_paddr_t));
 
  pmap_qremove(newPTD, 4);
 -   kmem_free(kernel_map, newPTD, 4);
 +   kmem_free(kernel_map, newPTD, 4 * PAGE_SIZE);
  /*
   * map actual idle stack to boot_stack
   */


This seems happy on our ref9 VMs.  I don't suppose this means I can go
above 768M of Ram now?


[root@xen1 sbruno]# /usr/sbin/xm create -c ref9-xen32
Using config file /etc/xen/ref9-xen32.
Started domain ref9-xen32 (id=106)
WARNING: loader(8) metadata is missing!
GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2011 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights
reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.0-PRERELEASE #0: Sat Dec 17 16:13:02 PST 2011

sbr...@ref9-xen32.freebsd.org:/dumpster/scratch/sbruno-scratch/9/sys/i386/compile/XEN
 i386
WARNING: WITNESS option enabled, expect reduced performance.
Xen reported: 2493.756 MHz processor.
Timecounter ixen frequency 1953125 Hz quality 0
CPU: Intel(R) Xeon(R) CPU   L5420  @ 2.50GHz (2493.76-MHz
686-class CPU)
  Origin = GenuineIntel  Id = 0x10676  Family = 6  Model = 17
Stepping = 6

Features=0xbfe3fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE

Features2=0xce3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1
  AMD Features=0x2010NX,LM
  AMD Features2=0x1LAHF
real memory  = 805306368 (768 MB)
avail memory = 776830976 (740 MB)
[XEN] IPI cpu=0 irq=128 vector=RESCHEDULE_VECTOR (0)
[XEN] IPI cpu=0 irq=129 vector=CALL_FUNCTION_VECTOR (1)
[XEN] xen_rtc_probe: probing Hypervisor RTC clock
rtc0: Xen Hypervisor Clock on motherboard
[XEN] xen_rtc_attach: attaching Hypervisor RTC clock
xenstore0: XenStore on motherboard
xc0: Xen Console on motherboard
Event timer ixen quality 600
Timecounters tick every 10.000 msec
xenbusb_front0: Xen Frontend Devices on xenstore0
[XEN] hypervisor wallclock nudged; nudging TOD.
xn0: Virtual Network Interface at device/vif/0 on xenbusb_front0
xn0: Ethernet address: 00:16:3e:00:00:03
xenbusb_back0: Xen Backend Devices on xenstore0
xctrl0: Xen Control Device on xenstore0
xn0: backend features: feature-sg feature-gso-tcp4
xbd0: 10240MB Virtual Block Device at device/vbd/768 on xenbusb_front0
xbd0: attaching as ad0
Timecounter TSC frequency 2493756000 Hz quality 800
WARNING: WITNESS option enabled, expect reduced performance.
Trying to mount root from ufs:/dev/ad0p2 []...
rtc0: [XEN] xen_rtc_gettime
rtc0: [XEN] xen_rtc_gettime: wallclock 1313550543 sec; 871707442 nsec
rtc0: [XEN] xen_rtc_gettime: uptime 10619933 sec; 620343100 nsec
rtc0: [XEN] xen_rtc_gettime: TOD 1324170477 sec; 492050542 nsec
Setting hostuuid: 1c127834-ab5a-c2e4-7b24-5ea29d364d9d.
Setting hostid: 0xdea9fbfd.
Entropy harvesting: interrupts ethernet point_to_point kickstart.
Starting file system checks:
/dev/ad0p2: FILE SYSTEM CLEAN; SKIPPING CHECKS
/dev/ad0p2: clean, 1874771 free (883 frags, 234236 blocks, 0.0%
fragmentation)
Mounting local file systems:.
Setting hostname: ref9-xen32.freebsd.org.
xn0: link state changed to DOWN
xn0: link state 

Re: PV i386 patch

2011-12-17 Thread Colin Percival
On 12/17/11 16:56, Sean Bruno wrote:
 This seems happy on our ref9 VMs.  I don't suppose this means I can go
 above 768M of Ram now?

Can't hurt to try... whatever the problem is with our code and large
amounts of RAM, the fact that it's an insta-panic during paging setup
suggests that it's something at a similar level of fail.

-- 
Colin Percival
Security Officer, FreeBSD | freebsd.org | The power to serve
Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org