1. 22 7月, 2008 1 次提交
    • J
      x86: rename PTE_MASK to PTE_PFN_MASK · 59438c9f
      Jeremy Fitzhardinge 提交于
      Rusty, in his peevish way, complained that macros defining constants
      should have a name which somewhat accurately reflects the actual
      purpose of the constant.
      
      Aside from the fact that PTE_MASK gives no clue as to what's actually
      being masked, and is misleadingly similar to the functionally entirely
      different PMD_MASK, PUD_MASK and PGD_MASK, I don't really see what the
      problem is.
      
      But if this patch silences the incessent noise, then it will have
      achieved its goal (TODO: write test-case).
      Signed-off-by: NJeremy Fitzhardinge <jeremy@goop.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      59438c9f
  2. 16 7月, 2008 9 次提交
    • J
      xen64: allocate and manage user pagetables · d6182fbf
      Jeremy Fitzhardinge 提交于
      Because the x86_64 architecture does not enforce segment limits, Xen
      cannot protect itself with them as it does in 32-bit mode.  Therefore,
      to protect itself, it runs the guest kernel in ring 3.  Since it also
      runs the guest userspace in ring3, the guest kernel must maintain a
      second pagetable for its userspace, which does not map kernel space.
      Naturally, the guest kernel pagetables map both kernel and userspace.
      
      The userspace pagetable is attached to the corresponding kernel
      pagetable via the pgd's page->private field.  It is allocated and
      freed at the same time as the kernel pgd via the
      paravirt_pgd_alloc/free hooks.
      
      Fortunately, the user pagetable is almost entirely shared with the
      kernel pagetable; the only difference is the pgd page itself.  set_pgd
      will populate all entries in the kernel pagetable, and also set the
      corresponding user pgd entry if the address is less than
      STACK_TOP_MAX.
      
      The user pagetable must be pinned and unpinned with the kernel one,
      but because the pagetables are aliased, pgd_walk() only needs to be
      called on the kernel pagetable.  The user pgd page is then
      pinned/unpinned along with the kernel pgd page.
      
      xen_write_cr3 must write both the kernel and user cr3s.
      
      The init_mm.pgd pagetable never has a user pagetable allocated for it,
      because it can never be used while running usermode.
      
      One awkward area is that early in boot the page structures are not
      available.  No user pagetable can exist at that point, but it
      complicates the logic to avoid looking at the page structure.
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: Stephen Tweedie <sct@redhat.com>
      Cc: Eduardo Habkost <ehabkost@redhat.com>
      Cc: Mark McLoughlin <markmc@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d6182fbf
    • J
      xen: rework pgd_walk to deal with 32/64 bit · 5deb30d1
      Jeremy Fitzhardinge 提交于
      Rewrite pgd_walk to deal with 64-bit address spaces.  There are two
      notible features of 64-bit workspaces:
      
       1. The physical address is only 48 bits wide, with the upper 16 bits
          being sign extension; kernel addresses are negative, and userspace is
          positive.
      
       2. The Xen hypervisor mapping is at the negative-most address, just above
          the sign-extension hole.
      
      1. means that we can't easily use addresses when traversing the space,
      since we must deal with sign extension.  This rewrite expresses
      everything in terms of pgd/pud/pmd indices, which means we don't need
      to worry about the exact configuration of the virtual memory space.
      This approach works equally well in 32-bit.
      
      To deal with 2, assume the hole is between the uppermost userspace
      address and PAGE_OFFSET.  For 64-bit this skips the Xen mapping hole.
      For 32-bit, the hole is zero-sized.
      
      In all cases, the uppermost kernel address is FIXADDR_TOP.
      
      A side-effect of this patch is that the upper boundary is actually
      handled properly, exposing a long-standing bug in 32-bit, which failed
      to pin kernel pmd page.  The kernel pmd is not shared, and so must be
      explicitly pinned, even though the kernel ptes are shared and don't
      need pinning.
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: Stephen Tweedie <sct@redhat.com>
      Cc: Eduardo Habkost <ehabkost@redhat.com>
      Cc: Mark McLoughlin <markmc@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5deb30d1
    • J
      xen: use set_pte_vaddr · 836fe2f2
      Jeremy Fitzhardinge 提交于
      Make Xen's set_pte_mfn() use set_pte_vaddr rather than copying it.
      Signed-off-by: NJeremy Fitzhardinge <jeremy@xensource.com>
      Signed-off-by: NJuan Quintela <quintela@redhat.com>
      Signed-off-by: NMark McLoughlin <markmc@redhat.com>
      Cc: Stephen Tweedie <sct@redhat.com>
      Cc: Eduardo Habkost <ehabkost@redhat.com>
      Cc: Mark McLoughlin <markmc@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      836fe2f2
    • J
      xen64: use arbitrary_virt_to_machine for xen_set_pmd · ce803e70
      Jeremy Fitzhardinge 提交于
      When building initial pagetables in 64-bit kernel the pud/pmd pointer may
      be in ioremap/fixmap space, so we need to walk the pagetable to look up the
      physical address.
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: Stephen Tweedie <sct@redhat.com>
      Cc: Eduardo Habkost <ehabkost@redhat.com>
      Cc: Mark McLoughlin <markmc@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ce803e70
    • J
      xen: fix truncation of machine address · ebd879e3
      Jeremy Fitzhardinge 提交于
      arbitrary_virt_to_machine can truncate a machine address if its above
      4G.  Cast the problem away.
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: Stephen Tweedie <sct@redhat.com>
      Cc: Eduardo Habkost <ehabkost@redhat.com>
      Cc: Mark McLoughlin <markmc@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ebd879e3
    • J
      xen64: get active_mm from the pda · ce87b3d3
      Jeremy Fitzhardinge 提交于
      x86_64 stores the active_mm in the pda, so fetch it from there.
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: Stephen Tweedie <sct@redhat.com>
      Cc: Eduardo Habkost <ehabkost@redhat.com>
      Cc: Mark McLoughlin <markmc@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ce87b3d3
    • J
      xen64: add extra pv_mmu_ops · f6e58732
      Jeremy Fitzhardinge 提交于
      We need extra pv_mmu_ops for 64-bit, to deal with the extra level of
      pagetable.
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: Stephen Tweedie <sct@redhat.com>
      Cc: Eduardo Habkost <ehabkost@redhat.com>
      Cc: Mark McLoughlin <markmc@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f6e58732
    • J
      x86: use __page_aligned_data/bss · cbcd79c2
      Jeremy Fitzhardinge 提交于
      Update arch/x86's use of page-aligned variables.  The change to
      arch/x86/xen/mmu.c fixes an actual bug, but the rest are cleanups
      and to set a precedent.
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: Stephen Tweedie <sct@redhat.com>
      Cc: Eduardo Habkost <ehabkost@redhat.com>
      Cc: Mark McLoughlin <markmc@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      cbcd79c2
    • E
      pvops-64: call paravirt_post_allocator_init() on setup_arch() · c1f2f09e
      Eduardo Habkost 提交于
      Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: Stephen Tweedie <sct@redhat.com>
      Cc: Mark McLoughlin <markmc@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c1f2f09e
  3. 04 7月, 2008 1 次提交
  4. 26 6月, 2008 1 次提交
  5. 25 6月, 2008 2 次提交
    • J
      xen: add mechanism to extend existing multicalls · 400d3494
      Jeremy Fitzhardinge 提交于
      Some Xen hypercalls accept an array of operations to work on.  In
      general this is because its more efficient for the hypercall to the
      work all at once rather than as separate hypercalls (even batched as a
      multicall).
      
      This patch adds a mechanism (xen_mc_extend_args()) to allocate more
      argument space to the last-issued multicall, in order to extend its
      argument list.
      
      The user of this mechanism is xen/mmu.c, which uses it to extend the
      args array of mmu_update.  This is particularly valuable when doing
      the update for a large mprotect, which goes via
      ptep_modify_prot_commit(), but it also manages to batch updates to
      pgd/pmds as well.
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Acked-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      400d3494
    • J
      xen: implement ptep_modify_prot_start/commit · e57778a1
      Jeremy Fitzhardinge 提交于
      Xen has a pte update function which will update a pte while preserving
      its accessed and dirty bits.  This means that ptep_modify_prot_start() can be
      implemented as a simple read of the pte value.  The hardware may
      update the pte in the meantime, but ptep_modify_prot_commit() updates it while
      preserving any changes that may have happened in the meantime.
      
      The updates in ptep_modify_prot_commit() are batched if we're currently in lazy
      mmu mode.
      
      The mmu_update hypercall can take a batch of updates to perform, but
      this code doesn't make particular use of that feature, in favour of
      using generic multicall batching to get them all into the hypervisor.
      
      The net effect of this is that each mprotect pte update turns from two
      expensive trap-and-emulate faults into they hypervisor into a single
      hypercall whose cost is amortized in a batched multicall.
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Acked-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e57778a1
  6. 24 6月, 2008 1 次提交
  7. 20 6月, 2008 4 次提交
  8. 02 6月, 2008 2 次提交
  9. 28 5月, 2008 1 次提交
    • I
      xen: fix early bootup crash on native hardware · b20aeccd
      Ingo Molnar 提交于
      -tip tree auto-testing found the following early bootup hang:
      
      -------------->
      get_memcfg_from_srat: assigning address to rsdp
      RSD PTR  v0 [Nvidia]
      BUG: Int 14: CR2 ffd00040
           EDI 8092fbfe  ESI ffd00040  EBP 80b0aee8  ESP 80b0aed0
           EBX 000f76f0  EDX 0000000e  ECX 00000003  EAX ffd00040
           err 00000000  EIP 802c055a   CS 00000060  flg 00010006
      Stack: ffd00040 80bc78d0 80b0af6c 80b1dbfe 8093d8ba 00000008 80b42810 80b4ddb4
             80b42842 00000000 80b0af1c 801079c8 808e724e 00000000 80b42871 802c0531
             00000100 00000000 0003fff0 80b0af40 80129999 00040100 00040100 00000000
      Pid: 0, comm: swapper Not tainted 2.6.26-rc4-sched-devel.git #570
       [<802c055a>] ? strncmp+0x11/0x25
       [<80b1dbfe>] ? get_memcfg_from_srat+0xb4/0x568
       [<801079c8>] ? mcount_call+0x5/0x9
       [<802c0531>] ? strcmp+0xa/0x22
       [<80129999>] ? printk+0x38/0x3a
       [<80129999>] ? printk+0x38/0x3a
       [<8011b122>] ? memory_present+0x66/0x6f
       [<80b216b4>] ? setup_memory+0x13/0x40c
       [<80b16b47>] ? propagate_e820_map+0x80/0x97
       [<80b1622a>] ? setup_arch+0x248/0x477
       [<80129999>] ? printk+0x38/0x3a
       [<80b11759>] ? start_kernel+0x6e/0x2eb
       [<80b110fc>] ? i386_start_kernel+0xeb/0xf2
       =======================
      <------
      
      with this config:
      
         http://redhat.com/~mingo/misc/config-Wed_May_28_01_33_33_CEST_2008.bad
      
      The thing is, the crash makes little sense at first sight. We crash on a
      benign-looking printk. The code around it got changed in -tip but
      checking those topic branches individually did not reproduce the bug.
      
      Bisection led to this commit:
      
      |   d5edbc1f is first bad commit
      |   commit d5edbc1f
      |   Author: Jeremy Fitzhardinge <jeremy@goop.org>
      |   Date:   Mon May 26 23:31:22 2008 +0100
      |
      |   xen: add p2m mfn_list_list
      
      Which is somewhat surprising, as on native hardware Xen client side
      should have little to no side-effects.
      
      After some head scratching, it turns out the following happened:
      randconfig enabled the following Xen options:
      
        CONFIG_XEN=y
        CONFIG_XEN_MAX_DOMAIN_MEMORY=8
        # CONFIG_XEN_BLKDEV_FRONTEND is not set
        # CONFIG_XEN_NETDEV_FRONTEND is not set
        CONFIG_HVC_XEN=y
        # CONFIG_XEN_BALLOON is not set
      
      which activated this piece of code in arch/x86/xen/mmu.c:
      
      > @@ -69,6 +69,13 @@
      >  	__attribute__((section(".data.page_aligned"))) =
      >  		{ [ 0 ... TOP_ENTRIES - 1] = &p2m_missing[0] };
      >
      > +/* Arrays of p2m arrays expressed in mfns used for save/restore */
      > +static unsigned long p2m_top_mfn[TOP_ENTRIES]
      > +	__attribute__((section(".bss.page_aligned")));
      > +
      > +static unsigned long p2m_top_mfn_list[TOP_ENTRIES / P2M_ENTRIES_PER_PAGE]
      > +	__attribute__((section(".bss.page_aligned")));
      
      The problem is, you must only put variables into .bss.page_aligned that
      have a _size_ that is _exactly_ page aligned. In this case the size of
      p2m_top_mfn_list is not page aligned:
      
       80b8d000 b p2m_top_mfn
       80b8f000 b p2m_top_mfn_list
       80b8f008 b softirq_stack
       80b97008 b hardirq_stack
       80b9f008 b bm_pte
      
      So all subsequent variables get unaligned which, depending on luck,
      breaks the kernel in various funny ways. In this case what killed the
      kernel first was the misaligned bootmap pte page, resulting in that
      creative crash above.
      
      Anyway, this was a fun bug to track down :-)
      
      I think the moral is that .bss.page_aligned is a dangerous construct in
      its current form, and the symptoms of breakage are very non-trivial, so
      i think we need build-time checks to make sure all symbols in
      .bss.page_aligned are truly page aligned.
      
      The Xen fix below gets the kernel booting again.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b20aeccd
  10. 27 5月, 2008 5 次提交
  11. 23 5月, 2008 2 次提交
  12. 28 4月, 2008 1 次提交
  13. 25 4月, 2008 4 次提交
  14. 05 4月, 2008 1 次提交
  15. 10 2月, 2008 1 次提交
  16. 30 1月, 2008 4 次提交