)]}'
{
  "log": [
    {
      "commit": "e3d2697669abbe26c08dc9b95e2a71c634d096ed",
      "tree": "a253ae576a5820adfdaa59ee3b95ea0dd34e354d",
      "parents": [
        "fb1d84043ca73212b08ff57608f51b372529e6d6"
      ],
      "author": {
        "name": "Jeremy Fitzhardinge",
        "email": "jeremy@xensource.com",
        "time": "Tue Oct 16 11:51:31 2007 -0700"
      },
      "committer": {
        "name": "Jeremy Fitzhardinge",
        "email": "jeremy@goop.org",
        "time": "Tue Oct 16 11:51:31 2007 -0700"
      },
      "message": "xen: fix incorrect vcpu_register_vcpu_info hypercall argument\n\nThe kernel\u0027s copy of struct vcpu_register_vcpu_info was out of date,\nat best causing the hypercall to fail and the guest kernel to fall\nback to the old mechanism, or worse, causing random memory corruption.\n\n[ Stable folks: applies to 2.6.23 ]\n\nSigned-off-by: Jeremy Fitzhardinge \u003cjeremy@xensource.com\u003e\nCc: Stable Kernel \u003cstable@kernel.org\u003e\nCc: Morten \u003d?utf-8?q?B\u003dC3\u003dB8geskov?\u003d \u003cxen-users@morten.bogeskov.dk\u003e\nCc: Mark Williamson \u003cmark.williamson@cl.cam.ac.uk\u003e\n\n"
    },
    {
      "commit": "dfb68689bf3e3d31dc9fb5c2bde5379a4ca9b0ec",
      "tree": "92479cdbfbe076cca2f426ccc4c66076863c9eb5",
      "parents": [
        "bd16f9ebd083b965dcdfb6b762e206374d5b823b"
      ],
      "author": {
        "name": "Jeremy Fitzhardinge",
        "email": "jeremy@goop.org",
        "time": "Thu Jul 26 10:41:01 2007 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@woody.linux-foundation.org",
        "time": "Thu Jul 26 11:35:16 2007 -0700"
      },
      "message": "xen: xen/page.h compile fix\n\nFix:\nlinux/include/xen/page.h: In function mfn_pte:\nlinux/include/xen/page.h:149: error: __supported_pte_mask undeclared (first use in this function)\nlinux/include/xen/page.h:149: error: (Each undeclared identifier is reported only once\nlinux/include/xen/page.h:149: error: for each function it appears in.)\n\nSigned-off-by: Jeremy Fitzhardinge \u003cjeremy@xensource.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n"
    },
    {
      "commit": "60223a326fc8fa6e90e2c3fd28ae6de4a311d731",
      "tree": "cf4e667a56402b846488373bfaf5bf840395e219",
      "parents": [
        "3e2b8fbeec8f005672f2a2e862fb9c26a0bafedc"
      ],
      "author": {
        "name": "Jeremy Fitzhardinge",
        "email": "jeremy@xensource.com",
        "time": "Tue Jul 17 18:37:07 2007 -0700"
      },
      "committer": {
        "name": "Jeremy Fitzhardinge",
        "email": "jeremy@goop.org",
        "time": "Wed Jul 18 08:47:45 2007 -0700"
      },
      "message": "xen: Place vcpu_info structure into per-cpu memory\n\nAn experimental patch for Xen allows guests to place their vcpu_info\nstructs anywhere.  We try to use this to place the vcpu_info into the\nPDA, which allows direct access.\n\nIf this works, then switch to using direct access operations for\nirq_enable, disable, save_fl and restore_fl.\n\nSigned-off-by: Jeremy Fitzhardinge \u003cjeremy@xensource.com\u003e\nCc: Chris Wright \u003cchrisw@sous-sol.org\u003e\nCc: Keir Fraser \u003ckeir@xensource.com\u003e\n"
    },
    {
      "commit": "4bac07c993d03434ea902d3d4290d9e45944b66c",
      "tree": "1930a1d8c23d3968d4644edda50791ff390bfe93",
      "parents": [
        "ad9a86121f5a374b48ce2924f8a9d7e94a04db27"
      ],
      "author": {
        "name": "Jeremy Fitzhardinge",
        "email": "jeremy@xensource.com",
        "time": "Tue Jul 17 18:37:06 2007 -0700"
      },
      "committer": {
        "name": "Jeremy Fitzhardinge",
        "email": "jeremy@goop.org",
        "time": "Wed Jul 18 08:47:45 2007 -0700"
      },
      "message": "xen: add the Xenbus sysfs and virtual device hotplug driver\n\nThis communicates with the machine control software via a registry\nresiding in a controlling virtual machine. This allows dynamic\ncreation, destruction and modification of virtual device\nconfigurations (network devices, block devices and CPUS, to name some\nexamples).\n\n[ Greg, would you mind giving this a review?  Thanks -J ]\n\nSigned-off-by: Ian Pratt \u003cian.pratt@xensource.com\u003e\nSigned-off-by: Christian Limpach \u003cChristian.Limpach@cl.cam.ac.uk\u003e\nSigned-off-by: Jeremy Fitzhardinge \u003cjeremy@xensource.com\u003e\nSigned-off-by: Chris Wright \u003cchrisw@sous-sol.org\u003e\nCc: Greg KH \u003cgreg@kroah.com\u003e\n"
    },
    {
      "commit": "ad9a86121f5a374b48ce2924f8a9d7e94a04db27",
      "tree": "c14af462957ce9ee6de3e4537e15879c25a679aa",
      "parents": [
        "b536b4b9623084d86f2b1f19cb44a2d6d74f00bf"
      ],
      "author": {
        "name": "Jeremy Fitzhardinge",
        "email": "jeremy@xensource.com",
        "time": "Tue Jul 17 18:37:06 2007 -0700"
      },
      "committer": {
        "name": "Jeremy Fitzhardinge",
        "email": "jeremy@goop.org",
        "time": "Wed Jul 18 08:47:44 2007 -0700"
      },
      "message": "xen: Add grant table support\n\nAdd Xen \u0027grant table\u0027 driver which allows granting of access to\nselected local memory pages by other virtual machines and,\nsymmetrically, the mapping of remote memory pages which other virtual\nmachines have granted access to.\n\nThis driver is a prerequisite for many of the Xen virtual device\ndrivers, which grant the \u0027device driver domain\u0027 restricted and\ntemporary access to only those memory pages that are currently\ninvolved in I/O operations.\n\nSigned-off-by: Jeremy Fitzhardinge \u003cjeremy@xensource.com\u003e\nSigned-off-by: Ian Pratt \u003cian.pratt@xensource.com\u003e\nSigned-off-by: Christian Limpach \u003cChristian.Limpach@cl.cam.ac.uk\u003e\nSigned-off-by: Chris Wright \u003cchrisw@sous-sol.org\u003e\n"
    },
    {
      "commit": "b536b4b9623084d86f2b1f19cb44a2d6d74f00bf",
      "tree": "86c1981309dbd8b9bf120d4ddba50abd105af89a",
      "parents": [
        "8b84ad942b534f8faeb34b68f0f7277ea375fed0"
      ],
      "author": {
        "name": "Jeremy Fitzhardinge",
        "email": "jeremy@xensource.com",
        "time": "Tue Jul 17 18:37:06 2007 -0700"
      },
      "committer": {
        "name": "Jeremy Fitzhardinge",
        "email": "jeremy@goop.org",
        "time": "Wed Jul 18 08:47:44 2007 -0700"
      },
      "message": "xen: use the hvc console infrastructure for Xen console\n\nImplement a Xen back-end for hvc console.\n\n* * *\nAdd early printk support via hvc console, enable using\n\"earlyprintk\u003dxen\" on the kernel command line.\n\nFrom: Gerd Hoffmann \u003ckraxel@suse.de\u003e\nSigned-off-by: Jeremy Fitzhardinge \u003cjeremy@xensource.com\u003e\nSigned-off-by: Chris Wright \u003cchrisw@sous-sol.org\u003e\nAcked-by: Ingo Molnar \u003cmingo@elte.hu\u003e\nAcked-by: Olof Johansson \u003colof@lixom.net\u003e\n"
    },
    {
      "commit": "f87e4cac4f4e940b328d3deb5b53e642e3881f43",
      "tree": "7409f86561e5f97459378abd2ae21e9a5c82bfea",
      "parents": [
        "ab55028886dd1dd54585f22bf19a00eb23869340"
      ],
      "author": {
        "name": "Jeremy Fitzhardinge",
        "email": "jeremy@xensource.com",
        "time": "Tue Jul 17 18:37:06 2007 -0700"
      },
      "committer": {
        "name": "Jeremy Fitzhardinge",
        "email": "jeremy@goop.org",
        "time": "Wed Jul 18 08:47:44 2007 -0700"
      },
      "message": "xen: SMP guest support\n\nThis is a fairly straightforward Xen implementation of smp_ops.\n\nXen has its own IPI mechanisms, and has no dependency on any\nAPIC-based IPI.  The smp_ops hooks and the flush_tlb_others pv_op\nallow a Xen guest to avoid all APIC code in arch/i386 (the only apic\noperation is a single apic_read for the apic version number).\n\nOne subtle point which needs to be addressed is unpinning pagetables\nwhen another cpu may have a lazy tlb reference to the pagetable. Xen\nwill not allow an in-use pagetable to be unpinned, so we must find any\nother cpus with a reference to the pagetable and get them to shoot\ndown their references.\n\nSigned-off-by: Jeremy Fitzhardinge \u003cjeremy@xensource.com\u003e\nSigned-off-by: Chris Wright \u003cchrisw@sous-sol.org\u003e\nCc: Benjamin LaHaise \u003cbcrl@kvack.org\u003e\nCc: Ingo Molnar \u003cmingo@redhat.com\u003e\nCc: Andi Kleen \u003cak@suse.de\u003e\n"
    },
    {
      "commit": "e46cdb66c8fc1c8d61cfae0f219ff47ac4b9d531",
      "tree": "7d9cdfef91e69fcfcba762a5a70cd58900308a5b",
      "parents": [
        "3b827c1b3aadf3adb4c602d19863f2d24e7cbc18"
      ],
      "author": {
        "name": "Jeremy Fitzhardinge",
        "email": "jeremy@xensource.com",
        "time": "Tue Jul 17 18:37:05 2007 -0700"
      },
      "committer": {
        "name": "Jeremy Fitzhardinge",
        "email": "jeremy@goop.org",
        "time": "Wed Jul 18 08:47:42 2007 -0700"
      },
      "message": "xen: event channels\n\nXen implements interrupts in terms of event channels.  Each guest\ndomain gets 1024 event channels which can be used for a variety of\npurposes, such as Xen timer events, inter-domain events,\ninter-processor events (IPI) or for real hardware IRQs.\n\nWithin the kernel, we map the event channels to IRQs, and implement\nthe whole interrupt handling using a Xen irq_chip.\n\nRather than setting NR_IRQ to 1024 under PARAVIRT in order to\naccomodate Xen, we create a dynamic mapping between event channels and\nIRQs.  Ideally, Linux will eventually move towards dynamically\nallocating per-irq structures, and we can use a 1:1 mapping between\nevent channels and irqs.\n\nSigned-off-by: Jeremy Fitzhardinge \u003cjeremy@xensource.com\u003e\nSigned-off-by: Chris Wright \u003cchrisw@sous-sol.org\u003e\nCc: Ingo Molnar \u003cmingo@elte.hu\u003e\nCc: Eric W. Biederman \u003cebiederm@xmission.com\u003e\n"
    },
    {
      "commit": "5ead97c84fa7d63a6a7a2f4e9f18f452bd109045",
      "tree": "26f6bc55dce0f119f7d3c8d6b40d2f287601db36",
      "parents": [
        "a42089dd358a7673a0a23126589a9029e57c2049"
      ],
      "author": {
        "name": "Jeremy Fitzhardinge",
        "email": "jeremy@xensource.com",
        "time": "Tue Jul 17 18:37:04 2007 -0700"
      },
      "committer": {
        "name": "Jeremy Fitzhardinge",
        "email": "jeremy@goop.org",
        "time": "Wed Jul 18 08:47:42 2007 -0700"
      },
      "message": "xen: Core Xen implementation\n\nThis patch is a rollup of all the core pieces of the Xen\nimplementation, including:\n - booting and setup\n - pagetable setup\n - privileged instructions\n - segmentation\n - interrupt flags\n - upcalls\n - multicall batching\n\nBOOTING AND SETUP\n\nThe vmlinux image is decorated with ELF notes which tell the Xen\ndomain builder what the kernel\u0027s requirements are; the domain builder\nthen constructs the address space accordingly and starts the kernel.\n\nXen has its own entrypoint for the kernel (contained in an ELF note).\nThe ELF notes are set up by xen-head.S, which is included into head.S.\nIn principle it could be linked separately, but it seems to provoke\nlots of binutils bugs.\n\nBecause the domain builder starts the kernel in a fairly sane state\n(32-bit protected mode, paging enabled, flat segments set up), there\u0027s\nnot a lot of setup needed before starting the kernel proper.  The main\nsteps are:\n  1. Install the Xen paravirt_ops, which is simply a matter of a\n     structure assignment.\n  2. Set init_mm to use the Xen-supplied pagetables (analogous to the\n     head.S generated pagetables in a native boot).\n  3. Reserve address space for Xen, since it takes a chunk at the top\n     of the address space for its own use.\n  4. Call start_kernel()\n\nPAGETABLE SETUP\n\nOnce we hit the main kernel boot sequence, it will end up calling back\nvia paravirt_ops to set up various pieces of Xen specific state.  One\nof the critical things which requires a bit of extra care is the\nconstruction of the initial init_mm pagetable.  Because Xen places\ntight constraints on pagetables (an active pagetable must always be\nvalid, and must always be mapped read-only to the guest domain), we\nneed to be careful when constructing the new pagetable to keep these\nconstraints in mind.  It turns out that the easiest way to do this is\nuse the initial Xen-provided pagetable as a template, and then just\ninsert new mappings for memory where a mapping doesn\u0027t already exist.\n\nThis means that during pagetable setup, it uses a special version of\nxen_set_pte which ignores any attempt to remap a read-only page as\nread-write (since Xen will map its own initial pagetable as RO), but\nlets other changes to the ptes happen, so that things like NX are set\nproperly.\n\nPRIVILEGED INSTRUCTIONS AND SEGMENTATION\n\nWhen the kernel runs under Xen, it runs in ring 1 rather than ring 0.\nThis means that it is more privileged than user-mode in ring 3, but it\nstill can\u0027t run privileged instructions directly.  Non-performance\ncritical instructions are dealt with by taking a privilege exception\nand trapping into the hypervisor and emulating the instruction, but\nmore performance-critical instructions have their own specific\nparavirt_ops.  In many cases we can avoid having to do any hypercalls\nfor these instructions, or the Xen implementation is quite different\nfrom the normal native version.\n\nThe privileged instructions fall into the broad classes of:\n  Segmentation: setting up the GDT and the GDT entries, LDT,\n     TLS and so on.  Xen doesn\u0027t allow the GDT to be directly\n     modified; all GDT updates are done via hypercalls where the new\n     entries can be validated.  This is important because Xen uses\n     segment limits to prevent the guest kernel from damaging the\n     hypervisor itself.\n  Traps and exceptions: Xen uses a special format for trap entrypoints,\n     so when the kernel wants to set an IDT entry, it needs to be\n     converted to the form Xen expects.  Xen sets int 0x80 up specially\n     so that the trap goes straight from userspace into the guest kernel\n     without going via the hypervisor.  sysenter isn\u0027t supported.\n  Kernel stack: The esp0 entry is extracted from the tss and provided to\n     Xen.\n  TLB operations: the various TLB calls are mapped into corresponding\n     Xen hypercalls.\n  Control registers: all the control registers are privileged.  The most\n     important is cr3, which points to the base of the current pagetable,\n     and we handle it specially.\n\nAnother instruction we treat specially is CPUID, even though its not\nprivileged.  We want to control what CPU features are visible to the\nrest of the kernel, and so CPUID ends up going into a paravirt_op.\nXen implements this mainly to disable the ACPI and APIC subsystems.\n\nINTERRUPT FLAGS\n\nXen maintains its own separate flag for masking events, which is\ncontained within the per-cpu vcpu_info structure.  Because the guest\nkernel runs in ring 1 and not 0, the IF flag in EFLAGS is completely\nignored (and must be, because even if a guest domain disables\ninterrupts for itself, it can\u0027t disable them overall).\n\n(A note on terminology: \"events\" and interrupts are effectively\nsynonymous.  However, rather than using an \"enable flag\", Xen uses a\n\"mask flag\", which blocks event delivery when it is non-zero.)\n\nThere are paravirt_ops for each of cli/sti/save_fl/restore_fl, which\nare implemented to manage the Xen event mask state.  The only thing\nworth noting is that when events are unmasked, we need to explicitly\nsee if there\u0027s a pending event and call into the hypervisor to make\nsure it gets delivered.\n\nUPCALLS\n\nXen needs a couple of upcall (or callback) functions to be implemented\nby each guest.  One is the event upcalls, which is how events\n(interrupts, effectively) are delivered to the guests.  The other is\nthe failsafe callback, which is used to report errors in either\nreloading a segment register, or caused by iret.  These are\nimplemented in i386/kernel/entry.S so they can jump into the normal\niret_exc path when necessary.\n\nMULTICALL BATCHING\n\nXen provides a multicall mechanism, which allows multiple hypercalls\nto be issued at once in order to mitigate the cost of trapping into\nthe hypervisor.  This is particularly useful for context switches,\nsince the 4-5 hypercalls they would normally need (reload cr3, update\nTLS, maybe update LDT) can be reduced to one.  This patch implements a\ngeneric batching mechanism for hypercalls, which gets used in many\nplaces in the Xen code.\n\nSigned-off-by: Jeremy Fitzhardinge \u003cjeremy@xensource.com\u003e\nSigned-off-by: Chris Wright \u003cchrisw@sous-sol.org\u003e\nCc: Ian Pratt \u003cian.pratt@xensource.com\u003e\nCc: Christian Limpach \u003cChristian.Limpach@cl.cam.ac.uk\u003e\nCc: Adrian Bunk \u003cbunk@stusta.de\u003e\n"
    },
    {
      "commit": "a42089dd358a7673a0a23126589a9029e57c2049",
      "tree": "aa076610832f5cdb0ee209c42ea7e40d54534ef4",
      "parents": [
        "24037a8b69dbf15bfed8fd42a2a2e442d7b0395b"
      ],
      "author": {
        "name": "Jeremy Fitzhardinge",
        "email": "jeremy@xensource.com",
        "time": "Tue Jul 17 18:37:04 2007 -0700"
      },
      "committer": {
        "name": "Jeremy Fitzhardinge",
        "email": "jeremy@goop.org",
        "time": "Wed Jul 18 08:47:42 2007 -0700"
      },
      "message": "xen: Add Xen interface header files\n\nAdd Xen interface header files. These are taken fairly directly from\nthe Xen tree, but somewhat rearranged to suit the kernel\u0027s conventions.\n\nDefine macros and inline functions for doing hypercalls into the\nhypervisor.\n\nSigned-off-by: Jeremy Fitzhardinge \u003cjeremy@xensource.com\u003e\nSigned-off-by: Ian Pratt \u003cian.pratt@xensource.com\u003e\nSigned-off-by: Christian Limpach \u003cChristian.Limpach@cl.cam.ac.uk\u003e\nSigned-off-by: Chris Wright \u003cchrisw@sous-sol.org\u003e\n"
    }
  ]
}
