1. 05 Apr, 2011 4 commits
    • Jan Beulich's avatar
      x86: split struct domain · 1dd3a56b
      Jan Beulich authored
      This is accomplished by converting a couple of embedded arrays (in one
      case a structure containing an array) into separately allocated
      pointers, and (just as for struct arch_vcpu in a prior patch)
      overlaying some PV-only fields with HVM-only ones.
      
      One particularly noteworthy change in the opposite direction is that
      of PITState - this field so far lived in the HVM-only portion, but is
      being used by PV guests too, and hence needed to be moved out of
      struct hvm_domain.
      
      The change to XENMEM_set_memory_map (and hence libxl__build_pre() and
      the movement of the E820 related pieces to struct pv_domain) are
      subject to a positive response to a query sent to xen-devel regarding
      the need for this to happen for HVM guests (see
      http://lists.xensource.com/archives/html/xen-devel/2011-03/msg01848.html).
      
      The protection of arch.hvm_domain.irq.dpci accesses by is_hvm_domain()
      is subject to confirmation that the field is used for HVM guests only
      (see
      http://lists.xensource.com/archives/html/xen-de...
      1dd3a56b
    • Jan Beulich's avatar
      x86: move pv-only members of struct vcpu to struct pv_vcpu · 6b063a4a
      Jan Beulich authored
      
      ... thus further shrinking overall size of struct arch_vcpu.
      
      This has a minor effect on XEN_DOMCTL_{get,set}_ext_vcpucontext - for
      HVM guests, some meaningless fields will no longer get stored or
      retrieved: reads will now return zero, and writes are required to be
      (mostly) zero (the same as was already done on x86-32).
      Signed-off-by: default avatarJan Beulich <jbeulich@novell.com>
      6b063a4a
    • Jan Beulich's avatar
      x86: split struct vcpu · 9a70856b
      Jan Beulich authored
      
      This is accomplished by splitting the guest_context member, which by
      itself is larger than a page on x86-64. Quite a number of fields of
      this structure is completely meaningless for HVM guests, and thus a
      new struct pv_vcpu gets introduced, which is being overlaid with
      struct hvm_vcpu in struct arch_vcpu. The one member that is mostly
      responsible for the large size is trap_ctxt, which now gets allocated
      separately (unless fitting on the same page as struct arch_vcpu, as is
      currently the case for x86-32), and only for non-hvm, non-idle
      domains.
      
      This change pointed out a latent problem in arch_set_info_guest(),
      which is permitted to be called on already initialized vCPU-s, but
      so far copied the new state into struct arch_vcpu without (in this
      case) actually going through all the necessary accounting/validation
      steps. The logic gets changed so that the pieces that bypass
      accounting
      will at least be verified to be no different from the currently active
      bits, and the whole change will fail in case they are. The logic does
      *not* get adjusted here to do full error recovery, that is, partially
      modified state continues to not get unrolled in case of failure.
      Signed-off-by: default avatarJan Beulich <jbeulich@novell.com>
      9a70856b
    • Jan Beulich's avatar
      Remove direct cpumask_t members from struct vcpu and struct domain · 4551775d
      Jan Beulich authored
      
      The CPU masks embedded in these structures prevent NR_CPUS-independent
      sizing of these structures.
      
      Basic concept (in xen/include/cpumask.h) taken from recent Linux.
      
      For scalability purposes, many other uses of cpumask_t should be
      replaced by cpumask_var_t, particularly local variables of functions.
      This implies that no functions should have by-value cpumask_t
      parameters, and that the whole old cpumask interface (cpus_...())
      should go away in favor of the new (cpumask_...()) one.
      Signed-off-by: default avatarJan Beulich <jbeulich@novell.com>
      4551775d
  2. 04 Apr, 2011 3 commits
  3. 02 Apr, 2011 11 commits
  4. 31 Mar, 2011 18 commits
  5. 29 Mar, 2011 1 commit
  6. 28 Mar, 2011 2 commits
  7. 27 Mar, 2011 1 commit