)]}'
{
  "log": [
    {
      "commit": "b14f5c100ce4c63e4c5a71ab47e71cf4a1caa9e3",
      "tree": "5c13bf03d4ce199bebffb66146daf5d9fd731bfd",
      "parents": [
        "f8be339c02c1e543eee8e09ffe600c0e61be5898"
      ],
      "author": {
        "name": "David S. Miller",
        "email": "davem@sunset.davemloft.net",
        "time": "Sat Jul 14 00:45:16 2007 -0700"
      },
      "committer": {
        "name": "David S. Miller",
        "email": "davem@sunset.davemloft.net",
        "time": "Mon Jul 16 04:04:49 2007 -0700"
      },
      "message": "[SPARC64]: Fix build regressions added by dr-cpu changes.\n\nDo not select HOTPLUG_CPU from SUN_LDOMS, that causes\nHOTPLUG_CPU to be selected even on non-SMP which is\nillegal.\n\nOnly build hvtramp.o when SMP, just like trampoline.o\n\nProtect dr-cpu code in ds.c with HOTPLUG_CPU.\n\nLikewise move ldom_startcpu_cpuid() to smp.c and protect\nit and the call site with SUN_LDOMS \u0026\u0026 HOTPLUG_CPU.\n\nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\n"
    },
    {
      "commit": "4f0234f4f9da485ecb9729af1b88567700fd4767",
      "tree": "7073115c86dbf4e691ddac12f5c9ce1c58ce53be",
      "parents": [
        "b3e13fbeb9ac1eb8e7b0791bf56e1775c692972b"
      ],
      "author": {
        "name": "David S. Miller",
        "email": "davem@sunset.davemloft.net",
        "time": "Fri Jul 13 16:03:42 2007 -0700"
      },
      "committer": {
        "name": "David S. Miller",
        "email": "davem@sunset.davemloft.net",
        "time": "Mon Jul 16 04:04:40 2007 -0700"
      },
      "message": "[SPARC64]: Initial LDOM cpu hotplug support.\n\nOnly adding cpus is supports at the moment, removal\nwill come next.\n\nWhen new cpus are configured, the machine description is\nupdated.  When we get the configure request we pass in a\ncpu mask of to-be-added cpus to the mdesc CPU node parser\nso it only fetches information for those cpus.  That code\nalso proceeds to update the SMT/multi-core scheduling bitmaps.\n\ncpu_up() does all the work and we return the status back\nover the DS channel.\n\nCPUs via dr-cpu need to be booted straight out of the\nhypervisor, and this requires:\n\n1) A new trampoline mechanism.  CPUs are booted straight\n   out of the hypervisor with MMU disabled and running in\n   physical addresses with no mappings installed in the TLB.\n\n   The new hvtramp.S code sets up the critical cpu state,\n   installs the locked TLB mappings for the kernel, and\n   turns the MMU on.  It then proceeds to follow the logic\n   of the existing trampoline.S SMP cpu bringup code.\n\n2) All calls into OBP have to be disallowed when domaining\n   is enabled.  Since cpus boot straight into the kernel from\n   the hypervisor, OBP has no state about that cpu and therefore\n   cannot handle being invoked on that cpu.\n\n   Luckily it\u0027s only a handful of interfaces which can be called\n   after the OBP device tree is obtained.  For example, rebooting,\n   halting, powering-off, and setting options node variables.\n\nCPU removal support will require some infrastructure changes\nhere.  Namely we\u0027ll have to process the requests via a true\nkernel thread instead of in a workqueue.  workqueues run on\na per-cpu thread, but when unconfiguring we might need to\nforce the thread to execute on another cpu if the current cpu\nis the one being removed.  Removal of a cpu also causes the kernel\nto destroy that cpu\u0027s workqueue running thread.\n\nAnother issue on removal is that we may have interrupts still\npointing to the cpu-to-be-removed.  So new code will be needed\nto walk the active INO list and retarget those cpus as-needed.\n\nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\n"
    },
    {
      "commit": "b3e13fbeb9ac1eb8e7b0791bf56e1775c692972b",
      "tree": "06539dfe2332c98c4d8b83450fe1e6055680ddc0",
      "parents": [
        "83292e0a9c3f1c326b28fbf8cb70a8ce81a98163"
      ],
      "author": {
        "name": "David S. Miller",
        "email": "davem@sunset.davemloft.net",
        "time": "Thu Jul 12 15:55:55 2007 -0700"
      },
      "committer": {
        "name": "David S. Miller",
        "email": "davem@sunset.davemloft.net",
        "time": "Mon Jul 16 04:04:36 2007 -0700"
      },
      "message": "[SPARC64]: Fix setting of variables in LDOM guest.\n\nThere is a special domain services capability for setting\nvariables in the OBP options node.  Guests don\u0027t have permanent\nstore for the OBP variables like a normal system, so they are\ninstead maintained in the LDOM control node or in the SC.\n\nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\n"
    },
    {
      "commit": "133f09a169f3022be3de671b29658b7ecb375022",
      "tree": "c30e7d34eceb96dd1b0d2b999713bc99f74efbdd",
      "parents": [
        "e450992d13ffaec6dde4bbbd308b834ae9fc3708"
      ],
      "author": {
        "name": "David S. Miller",
        "email": "davem@sunset.davemloft.net",
        "time": "Wed Jul 11 23:22:55 2007 -0700"
      },
      "committer": {
        "name": "David S. Miller",
        "email": "davem@sunset.davemloft.net",
        "time": "Mon Jul 16 04:04:24 2007 -0700"
      },
      "message": "[SPARC64]: Use more mearningful names for IRQ registry.\n\nAll of the interrupts say \"LDX RX\" and \"LDX TX\" currently\nwhich is next to useless.  Put a device specific prefix\nbefore \"RX\" and \"TX\" instead which makes it much more\nuseful.\n\nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\n"
    },
    {
      "commit": "cb4812358423e7ea47d2b6471918d65238452cc5",
      "tree": "baa325ecdec9ee88542a5e2350ecf48c3dc88d05",
      "parents": [
        "5a606b72a4309a656cd1a19ad137dc5557c4b8ea"
      ],
      "author": {
        "name": "David S. Miller",
        "email": "davem@sunset.davemloft.net",
        "time": "Wed Jul 11 18:14:41 2007 -0700"
      },
      "committer": {
        "name": "David S. Miller",
        "email": "davem@sunset.davemloft.net",
        "time": "Mon Jul 16 04:04:09 2007 -0700"
      },
      "message": "[SPARC64]: Assorted LDC bug cures.\n\n1) LDC_MODE_RELIABLE is deprecated an unused by anything, plus\n   it and LDC_MODE_STREAM were mis-numbered.\n\n2) read_stream() should try to read as much as possible into\n   the per-LDC stream buffer area, so do not trim the read_nonraw()\n   length by the caller\u0027s size parameter.\n\n3) Send data ACKs when necessary in read_nonraw().\n\n4) In read_nonraw() when we get a pure ACK, advance the RX head\n   unconditionally past it.\n\n5) Provide the ACKID field in the ldcdgb() packet dump in read_nonraw().\n   This helps debugging stream mode LDC channel problems.\n\n6) Decrease verbosity of rx_data_wait() so that it is more useful.\n   A debugging message each loop iteration is too much.\n\n7) In process_data_ack() stop the loop checking when we hit lp-\u003etx_tail\n   not lp-\u003etx_head.\n\n8) Set the seqid field properly in send_data_nack().\n\nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\n"
    },
    {
      "commit": "e53e97ce3c7119199d2788d8fd1618efa9c2d1eb",
      "tree": "799f1b7960fcaf9a02800419b038d42eb031f776",
      "parents": [
        "8f41958bdd577731f7411c9605cfaa9db6766809"
      ],
      "author": {
        "name": "David S. Miller",
        "email": "davem@sunset.davemloft.net",
        "time": "Mon Jul 09 22:22:44 2007 -0700"
      },
      "committer": {
        "name": "David S. Miller",
        "email": "davem@sunset.davemloft.net",
        "time": "Mon Jul 16 04:03:18 2007 -0700"
      },
      "message": "[SPARC64]: Add LDOM virtual channel driver and VIO device layer.\n\nVirtual devices on Sun Logical Domains are built on top\nof a virtual channel framework.  This, with help of hypervisor\ninterfaces, provides a link layer protocol with basic\nhandshaking over which virtual device clients and servers\ncommunicate.\n\nBuilt on top of this is a VIO device protocol which has it\u0027s\nown handshaking and message types.  At this layer attributes\nare exchanged (disk size, network device addresses, etc.)\ndescriptor rings are registered, and data transfers are\ntriggers and replied to.\n\nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\n"
    }
  ]
}
