Abstract:
Methods, systems, apparatuses and program products are disclosed for managing memory multiple OSes within a single computer and the like. 
     Provision is made for memory recovery between hot swapped OSes with BIOS assistance and conforming with ACPI features for System State management and capable of use without virtualization.

Description:
RELATED APPLICATION 
       [0001]    This application claims the benefit of U.S. Provisional Application Ser. No. 61/210,578, filed on Mar. 20, 2009. 
     
    
     FIELD OF THE INVENTION 
       [0002]    The present invention generally relates to personal computers and devices sharing similar architectures and, more particularly relates to a system and corresponding method for managing, activating and controlling memory resources in an environment of plural non-virtualized plural operating systems and/or the like within a computing apparatus or within a single computer operational session or context. 
       BACKGROUND OF THE INVENTION 
       [0003]    Modernly, the use of PCs (personal computers), including so-called laptop and notebook computers, is increasingly common and the computers themselves are of increasing computer powerful, decreasing thermal power and ever more complex. 
         [0004]    A vast majority of PCs have a controlling software, for example an OS (Operating System) such as Microsoft® Windows® Vista® or a like commercial product. Many varieties of OS are available largely due to the need to make design tradeoffs. In particular, feature richness with attendant complexity and size is traded off against (relatively) limited capabilities with increased speed (especially speed of operation and of load time). 
         [0005]    Thus a need has existed to provide for the use of multiple OS within a computer and various approaches, each with its own tradeoffs, have been used. 
         [0006]    One approach, disclosed in the U.S. Provisional Application Ser. No. 61/210,578, filed on Mar. 20, 2009 for a patent and which is hereby included by this reference, provided for OS interchange in a non-virtualized environment. 
         [0007]    When implementing such a system a need for enhanced memory management exists to avoid or mitigate inflexible partitioning of system memory between OSes. 
       SUMMARY OF THE INVENTION 
       [0008]    The disclosed invention includes, among other things, methods and techniques for providing OS memory recovery assistance in pursuit of the support of multiple OSes (Operating Systems). 
         [0009]    The present invention provides a method for operating a computer for data communications and also an apparatus that embodies the method. In addition program products and other means for exploiting the invention are presented. 
         [0010]    According to an aspect of the present invention an embodiment of the invention may provide for partitioning system memory into three paged partitions; creating page table(s); making respective memory partitions visible to at least two OSes; marking some pages associated with one OS as usable by the other OS; swapping out pages memory so that pages may be borrowed and resinstated later when a previous context resumes. 
         [0011]    An advantage and/or feature provided by or resulting from implementing the present invention is that memory may be redeployed between multiple OSes (typically two OSes but optionally three or more) without need for either a lengthy reboot time or the disadvantages inherent in the use of virtualization techniques. Consequently there is improved use of memory resource is such systems, for example the Hyperspace™ firmware and software product of Phoenix® Technologies Ltd. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0012]    The aforementioned and related advantages and features of the present invention will become better understood and appreciated upon review of the following detailed description of the invention, taken in conjunction with the following drawings, which are incorporated in and constitute a part of the specification, illustrate an embodiment of the invention and wherein like numerals represent like elements, and in which: 
           [0013]      FIG. 1  is a schematic block diagram of an electronic device configured to implement the security functionality according to the present invention; 
           [0014]      FIG. 2  is a diagram that illustrates memory as manipulated in one particular embodiment of the invention. 
           [0015]      FIGS. 3 and 4 , taken together are a somewhat more detailed flowchart illustrating an overview of some of the steps performed in implementing an embodiment of the invention in further detail. 
           [0016]      FIG. 5  shows how an exemplary embodiment of the invention may be encoded onto a computer medium or media; and 
           [0017]      FIG. 6  shows how an exemplary embodiment of the invention may be encoded, transmitted, received and decoded using electromagnetic waves. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0018]    The numerous components shown in the drawings are presented to provide a person of ordinary skill in the art a thorough, enabling disclosure of the present invention. The description of well known components is not included within this description so as not to obscure the disclosure or take away or otherwise reduce the novelty of the present invention and the main benefits provided thereby. 
         [0019]    An exemplary embodiment of the present invention will now be described with reference to the figures.  FIG. 1  is a schematic block diagram of an electronic device configured to implement the security functionality according to the present invention. 
         [0020]    In an exemplary embodiment, the electronic device  10  may be implemented as a personal computer, for example, a desktop computer, a laptop computer, a tablet PC or other suitable computing device. Although the description outlines the operation of a personal computer, it will be appreciated by those of ordinary skill in the art, that the electronic device  10  may be implemented as a PDA, wireless communication device, for example, a cellular telephone, embedded controllers or devices, for example, set top boxes, printing devices or other suitable devices or combination thereof and suitable for operating or interoperating with the invention. 
         [0021]    The electronic device  10  may include at least one processor or CPU (Central Processing Unit)  12 , configured to control the overall operation of the electronic device  10 . Similar controllers or MPUs (Microprocessor Units) are commonplace. The processor  12  may typically be coupled to a bus controller  14  such as a Northbridge chip by way of a bus  13  such as a FSB (Front-Side Bus). The bus controller  14  may typically provide an interface for read-write system memory  16  such as RAM (random access memory). 
         [0022]    In ordinary operation, CPU  12  may fetch computer instructions (also termed computer instruction codes, not shown in  FIG. 1 ) from system memory  16 . The CPU may then interpret the fetched computer instructions and operate to interpret the instructions thereby to control operation of the electronic device  10 . Such use of CPU, system memory and computer instructions that typically comprise OS (Operating System) codes and other software are well known in the computing arts. 
         [0023]    The bus controller  14  may also be coupled to a system bus  18 , for example a DMI (Direct Media Interface) in typical Intel® style embodiments. Coupled to the DMI  18  may be a so-called Southbridge chip such as an Intel® ICH8 (Input/Output Controller Hub type 8) chip  24   
         [0024]    The Southbridge chip  24 , may typically incorporate a first NIC (Network Interface Controller)  32  such as of the 1000 BASE-T type of IEEE 802.3 (Institute of Electrical and Electronics Engineers standard number 802.3) interface connecting to an 8PC8  31  (8 positions, 8 contacts) type of wired network connector. An 8PC8 connector  31  is, colloquially known as an RJ45 port and IEEE 802.3 is colloquially known as Ethernet. 
         [0025]    In a typical embodiment, the Southbridge chip  24  may be connected to a PCI (peripheral component interconnect) bus  22  which may in turn be connected to a second NIC  66  which drives a Wireless Transceiver  71 . Wireless Transceiver  71  may operate in compliance with IEEE 802.11 or other suitable standards. Wireless Transceiver  71  will typically be coupled to some form of radio antenna  72 . Also, typically, Southbridge chip  24  may also be coupled to a NVRAM (non-volatile random-access memory)  33 . 
         [0026]    Either or both NICs  32  and  66  may convey communications signals that are used to form logical network connections such as to an Internet Service. Indeed a typical computer or similar electronic device  10  may have other interfaces, for example USB (Universal Serial Bus, not shown in  FIG. 1 ) that may in turn connect to (for example) a Bluetooth® transceiver for other modes of communication within the general scope of the invention. 
         [0027]      FIG. 2  is a diagram that illustrates memory as manipulated in one particular embodiment of the invention. With reference to  FIG. 2  now follows a description of necessary changes to Linux® style Virtual Memory Management in X86 processor based computers. Only the needed changes for one particular embodiment is described, the reader is assumed to have ordinary skill in the art of Linux® style Virtual Memory Management software. It should be noted however, that some of the features described are particularly well suited to implementation and distribution in platform firmware since intimated changes of basic hardware controlling entities, such as page tables, in envisaged. 
         [0028]    In this implementation described, there is a first OS (operating system) which is Linux®-like in nature and reference to an OS termed “Windows” which is a generic term for any non-open source proprietary OS such as one of the Microsoft® Windows® program products. The understanding is that the “Windows” is a software black-box meaning that if memory resource (whether virtual or physical) is redeployed the only way to have Windows run correctly after such redeployment is to reinstate the memory contents and/or mapping prior to Windows being allowed to execute. Otherwise problems similar to a memory integrity problem are likely to be detects irrespective of whether a false alarm is occurring. 
         [0029]    Here then is a description that focuses on the differences in memory management between Linux® and Hyperspace™. 
         [0030]    HyperSpace™ is first OS to be booted on system ‘cold boot’ (ACPI state S5→S0), and based on HyperSpace S5 or S3 trigger, BIOS boots Windows® OS. OSM hooks into BIOS&#39;s Int 15—E820 service routine and passes “LAST_BOOT_OS” indicator, such that if its value is HyperSpace, modified memory map (excluding HyperSpace memory) is returned to Windows® and save HyperSpace hardware/memory context. Similar information is saved for Windows® context. This allows BIOS to keep a “S3” context of both HyperSpace and Windows® OS and use it during S3 resume operation for each OS. 
         [0031]    HyperSpace boot is described:—HyperSpace is based on Linux® and inherits all of its booting primitives. These primitives not only define how the initial “real mode” OS loading takes place but also how a “protected mode” OS establishes itself as a controlling software from memory management, IO management, and process management aspects. During early boot HyperSpace queries for e820 map to find out information about architecture specific memory characteristics. Return response is disseminated by early boot components to chart out memory in terms of zone boundaries and user/kernel-space spilt. Kernel variables: min_low_pfn, max_low_pfn, max_pfn are values calculated. Difference (max_low_pfn−min_low_pfn) is used to figure out start/end of high memory zone (ZONE_HIGHMEM), max_low_pfn is a highest addressable frame for normal zone (ZONE_NORMAL) and rest memory is treated for dma operations (ZONE_DMA). None of the above characteristics differ with proposed e820h change. However, HyperSpace memory management is altered to be aware of memory occupied by Windows®. This behavior has an impact on its page allocation/de-allocation scheme, but that is an artifact of memory hot-swapping, which is discussed in memory hot-swapping section. 
         [0032]    Windows boot in this embodiment of the invention is described. BIOS e820 and OSM changes are transparent to Windows® OS. Memory region occupied by HyperSpace is marked “reserved” (by BIOS) for Windows®. This prevents Windows from mem-mapping this region. Windows® ends up with total memory=(Total Physical Memory−Gfx UMA−BIOS reserved memory−HyperSpace “reserved” memory).  FIG. 3.0  shows typical (non-PAE) physical to virtual memory mapping seen by HyperSpace and Windows® after boot. 
         [0033]    “OS context switch” implementation on HyperSpace system is tied to: OS ACPI “suspend/resume” and BIOS firmware. System BIOS registers with ‘SleepTrap’ handler code such that S3 suspend writes to PM_CNT 1  port is intercepted. This handler code assists OSM to determine if sleep request came from HyperSpace or Windows OS and use this information to ‘resume’ Windows® OS or HyperSpace. Note, suspend sequence is tied to respective OS ACPI capability.  FIG. 4.0  depicts altered boot/suspend/resume operational flow. 
         [0034]    Non-HyperSpace OS can have a HyperSpace software component to facilitate OS context switch. Further, it can be tied to a “keyboard hook-specific key” or “desktop UI” software component. 
         [0035]    Keyboard based “suspend” uses a “key” to initiate ACPI S3 state. On Windows® OS, this can be a service or a keyboard filter driver. On HyperSpace OS “suspend” can be controlled through i8042 driver change. 
         [0036]    Desktop UI based “suspend” involves programming of a short-cut on Windows® desktop, which will have logic to put Windows® to S3. The ‘resume’ sequence can be “firmware-controlled” or “hardware-controlled”. All resume sequence modes are programmed in OSM module and rely on the fact if both OS&#39;s are in ACPI S3 state. “Firmware controlled” resume can be “alternating” or “sequential”. “Alternating resume” mode resumes OS other than last suspended OS. “Sequential resume” mode resumes to last suspended OS, which is how current resume operation behaves. This mode effectively turns-off S3 based OS context switching. Hardware-controlled resume mode ties GPIO (General Purpose Input Output) ports to trigger boot and/or resume sequence for HyperSpace and Windows. In resume sequence, the handler passes control to OSM entry point in real mode, which continues with the OS resume . . . 
         [0037]    The technique for HyperSpace temporary memory growth using hot-swap memory is described: 
         [0038]    On x86-based platforms HyperSpace supports hot-swap memory feature, which allows ranges of physical memory from suspended (S3) Windows® to be added to running (S0) HyperSpace without requiring a system reboot. 
         [0039]    HyperSpace support for “hot-swap memory” consists of following changes: Page management and e820 map changes for HyperSpace: System boot into HyperSpace ensures entire “OS usable memory” to be mapped by memory management unit. This memory range includes physical memory reported to Windows® OS. Windows® OS may be suspended (S3) or shutdown (S5) state; if it is suspended then this memory should have a running OS snapshot including device and process memory. HyperSpace memory management unit reads through entire e820 map for the highest page frame. HyperSpace sees entire machine physical memory map, but its memory management is modified to map (memmap( )) pages from HyperSpace “reserved” memory only and leave rest of the memory page-mapped but not-used. 
         [0040]    This means change to page frame management such that “reserved” Windows® memory (and associated page frames) is ‘initialized but not used’ by HyperSpace page management code. This involves following: 
         [0041]    Early mm function find_max_pfn( ) sees max_pfn=(Top−x−y)−1M for HyperSpace. Read “real usable physical memory” from OSM/BIOS and store in new variable max_real_pfn. 
         [0042]    Add new flag value ‘PG_hsusable’ to existing “page” structure (defined in &lt;linux/mm.h&gt;). Pages deemed as ‘PG_hsusable’ or ‘PG_skip’ will not be used by zone or kernel page table initialization routines. Specifically, functions page_init( ) and free_area_init( ) (mm/page_alloc.c), which set up zones and page descriptors. By default ‘PG_reserved’ flag is set for all pages during execution of this function. 
         [0043]    mem_init( ) (in mm/init — 32 and mm/init — 64.c) functions need to be modified to use max_real_mfn when resetting “PG_reserved’ to zone specific flag (PG_highmem). This ensure all (pages&gt;max_real_mfn) to be ‘PG_hsusable’. Note, we considered using ‘PG_reserved’ value but decided to create new flag value to avoid inter-mixing with existing logic. 
         [0044]    Zone watermarks and page swapping to disk: Linux® has three memory zones for managing non-kernel page-table memory: ZONE_DMA, ZONE_NORMAL and ZONE_HIGHMEM. Each zone has three watermarks called pages_low, pages_min and pages_high, which help track how much pressure a zone is under during OS execution. The number of pages for pages_min per zone is calculated in the function free_area_init_core( ) during memory initialization and is based on a ratio to the size of the zone in pages. Each watermark warrants different action per Zone. Note that watermarking woks in tandem with page-out daemon called ‘kswapd’. kswapd is responsible for swapping out pages to/from the disk in an asynchronous manner. Synchronous per zone-page-freeing (referred to as “direct-reclaim”) is implemented and used by page allocator. 
         [0045]    Memory hot-swap requires following changes to zone and disk swap considerations: 
         [0046]    Windows® Memory is “disk saved &amp; swapped” in chunks of 128 MiB and used to extend ZONE_NORMAL, ZONE_HIGHMEM memory and/or any user-configurable chunks of memory. 
         [0047]    Zone watermark “reached” detection logic (for all watermarks per zone) needs to account for “PG_hsusable” pages transitioning into per zone free page-pool. This action may warrant a page-table walk to verify “fixed and distributed” pages per zone. 
         [0048]    Page allocation (_alloc_pages in mm/page_alloc.c) uses direct-reclaim path using _alloc_pages_internal( ) or kswapd invocation upon low memory condition. It should implement “PG_hsusable” pages transitioning into zone specific “PG-xx” and set additional bitmask “flag=PG-xx|PG_hsinuse” before invoking kswapd or doing kswapd&#39;s job manually. Before marking these pages to be used by HyperSpace, it should ensure Windows® paginated memory is written to a “Windows swap” disk file in a page contiguous manner. 
         [0049]    Upon HyperSpace suspend (S3), while in protected-mode, and after process “refrigeration”, page_allocator should swap the content of “PG_hsinuse” pages onto the HyperSpace “swap” disk file. This file will be read and pages will be “restored” during HyperSpace resume sequence. This ensures re-constructing “memory” as it was before suspend operation. 
         [0050]      FIGS. 3 and 4 , taken together are a flowchart illustrating an overview of some of the steps performed in implementing one particular embodiment of the invention. In contrast with the fuller description above the flowchart bring out the novelty of the various embodiment of the invention with some focus on the steps involved. 
         [0051]    At step  300 , system memory is partitioned. A first partition may be set up for HS (Hyperspace™), a second partition for a complex, resource intensive and/or black box non open source OS, such as a Windows® product. A third partition encompasses substantially the entire system memory thus allowing the low level parts of the Hyperspace system to manipulate substantially the entire system memory. 
         [0052]    At step  320 , a page table is created to map the first paged partition into a first virtual memory partition. Hyperspace OS will typically be loaded into the first partition. 
         [0053]    At step  350 , either the page table is expanded to incorporate pages for the second OS (typically Windows) or a second page table is created and used. This is a simplification, page tables can be complex, and/or even cascading but this is an implementation detail not critical to the invention. 
         [0054]    First OS (typically HS) may be loaded into the first partition and set running. At step  360 , BIOS fields an E820 memory request from the first OS (typically HS) this actually enables (for example) HS to see the first partition as its primary memory (available for applications and more), but HS also may see the entire third partition including the second partition. 
         [0055]    The second partition is memory set aside primarily for use by a second OS (typically Windows). Second OS may be loaded into the second partition and set running. At step  370 , BIOS fields an E820 memory request from the second OS (typically Windows) and makes the second virtual memory partition to the second OS. Second OS (Windows) can be expected to have been loaded into the second partition. 
         [0056]    At step  380  some as the pages in the second partition are marked as reclaimable. Typically these are HSusable (usable by HS as reclaimed memory). Some of Windows&#39;s pages can be expected to be marked in this way while many or most are not. 
         [0057]    At step  400 , first OS (HS) makes a request for further memory and reclaimable pages from the first partition are swapped out. Typically this will involve writing the page context and control information to a storage file on a disk. However, technology may change over time and the use of files and disk in swapping may prove not to be crucial. However the memory “owned” by Windows must be swapped out so that it can be reinstated later. 
         [0058]    At step  410  the swapped out page is handed over to the first OS which can be expected to write to the page (presumably if HS requests one or more reclaimable memory pages that request arises from an intention to write to the memory involved). 
         [0059]    Then, at step  420  there is a request to reactivate the second OS (Windows). To do this, at step  430  there is a reinstating of a saved hardware context, and, from the storage file the reclaimed page contents. 
         [0060]    At step  440 , control passes to the second OS. 
         [0061]    It will be apparent to a programmer of ordinary skill in the art how to extend the above procedure to provide for further extended forms of memory reclamation. 
         [0062]    With regards to  FIG. 5 , computer instructions to be incorporated into an electronic device  10  may be distributed as manufactured firmware and/or software computer products  510  using a variety of possible media  530  having the instructions recorded thereon such as by using a storage recorder  520 . Often in products as complex as those that deploy the invention, more than one medium may be used, both in distribution and in manufacturing relevant product. Only one medium is shown in  FIG. 5  for clarity but more than one medium may be used and a single computer product may be divided among a plurality of media. 
         [0063]      FIG. 6  shows how an exemplary embodiment of the invention may be encoded, transmitted, received and decoded using electro-magnetic waves. 
         [0064]    With regard to  FIG. 6 , additionally, and especially since the rise in Internet usage, computer products  610  may be distributed by encoding them into signals modulated as a wave. The resulting waveforms may then be transmitted by a transmitter  640 , propagated as tangible modulated electro-magnetic carrier waves  650  and received by a receiver  660 . Upon reception they may be demodulated and the signal decoded into a further version or copy of the computer product  611  in a memory or other storage device that is part of a second electronic device  11  and typically similar in nature to electronic device  10 . 
         [0065]    Other topologies and/or devices could also be used to construct alternative embodiments of the invention. The embodiments described above are exemplary rather than limiting and the bounds of the invention should be determined from the claims. Although preferred embodiments of the present invention have been described in detail hereinabove, it should be clearly understood that many variations and/or modifications of the basic inventive concepts herein taught which may appear to those skilled in the present art will still fall within the spirit and scope of the present invention, as defined in the appended claims.