31 Mar, 2009

1 commit


21 Aug, 2008

1 commit

  • A spinlock can be interrupted while spinning, so make sure we preserve
    the previous lock of interest if we're taking a lock from within an
    interrupt handler.

    We also need to deal with the case where the blocking path gets
    interrupted between testing to see if the lock is free and actually
    blocking. If we get interrupted there and end up in the state where
    the lock is free but the irq isn't pending, then we'll block
    indefinitely in the hypervisor. This fix is to make sure that any
    nested lock-takers will always leave the irq pending if there's any
    chance the outer lock became free.

    Signed-off-by: Jeremy Fitzhardinge
    Acked-by: Jan Beulich
    Signed-off-by: Ingo Molnar

    Jeremy Fitzhardinge
     

16 Jul, 2008

1 commit

  • The standard ticket spinlocks are very expensive in a virtual
    environment, because their performance depends on Xen's scheduler
    giving vcpus time in the order that they're supposed to take the
    spinlock.

    This implements a Xen-specific spinlock, which should be much more
    efficient.

    The fast-path is essentially the old Linux-x86 locks, using a single
    lock byte. The locker decrements the byte; if the result is 0, then
    they have the lock. If the lock is negative, then locker must spin
    until the lock is positive again.

    When there's contention, the locker spin for 2^16[*] iterations waiting
    to get the lock. If it fails to get the lock in that time, it adds
    itself to the contention count in the lock and blocks on a per-cpu
    event channel.

    When unlocking the spinlock, the locker looks to see if there's anyone
    blocked waiting for the lock by checking for a non-zero waiter count.
    If there's a waiter, it traverses the per-cpu "lock_spinners"
    variable, which contains which lock each CPU is waiting on. It picks
    one CPU waiting on the lock and sends it an event to wake it up.

    This allows efficient fast-path spinlock operation, while allowing
    spinning vcpus to give up their processor time while waiting for a
    contended lock.

    [*] 2^16 iterations is threshold at which 98% locks have been taken
    according to Thomas Friebel's Xen Summit talk "Preventing Guests from
    Spinning Around". Therefore, we'd expect the lock and unlock slow
    paths will only be entered 2% of the time.

    Signed-off-by: Jeremy Fitzhardinge
    Cc: Jens Axboe
    Cc: Peter Zijlstra
    Cc: Christoph Lameter
    Cc: Petr Tesarik
    Cc: Virtualization
    Cc: Xen devel
    Cc: Thomas Friebel
    Cc: Nick Piggin
    Signed-off-by: Ingo Molnar

    Jeremy Fitzhardinge
     

27 May, 2008

2 commits

  • This patch implements Xen save/restore and migration.

    Saving is triggered via xenbus, which is polled in
    drivers/xen/manage.c. When a suspend request comes in, the kernel
    prepares itself for saving by:

    1 - Freeze all processes. This is primarily to prevent any
    partially-completed pagetable updates from confusing the suspend
    process. If CONFIG_PREEMPT isn't defined, then this isn't necessary.

    2 - Suspend xenbus and other devices

    3 - Stop_machine, to make sure all the other vcpus are quiescent. The
    Xen tools require the domain to run its save off vcpu0.

    4 - Within the stop_machine state, it pins any unpinned pgds (under
    construction or destruction), performs canonicalizes various other
    pieces of state (mostly converting mfns to pfns), and finally

    5 - Suspend the domain

    Restore reverses the steps used to save the domain, ending when all
    the frozen processes are thawed.

    Signed-off-by: Jeremy Fitzhardinge
    Signed-off-by: Thomas Gleixner

    Jeremy Fitzhardinge
     
  • Add rebind_evtchn_irq(), which will rebind an device driver's existing
    irq to a new event channel on restore. Since the new event channel
    will be masked and bound to vcpu0, we update the state accordingly and
    unmask the irq once everything is set up.

    Signed-off-by: Jeremy Fitzhardinge
    Signed-off-by: Thomas Gleixner

    Jeremy Fitzhardinge
     

25 Apr, 2008

2 commits

  • Define resend_irq_on_evtchn() which ia64/xen uses.
    Although it isn't used by current x86/xen code, it's arch generic
    so that put it into common code.

    Signed-off-by: Isaku Yamahata
    Signed-off-by: Jeremy Fitzhardinge
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Isaku Yamahata
     
  • Remove x86 dependency in drivers/xen/events.c for ia64/xen support
    introducing include/asm/xen/events.h.
    Introduce xen_irqs_disabled() to hide regs->flags
    Introduce xen_do_IRQ() to hide regs->orig_ax.
    make enum ipi_vector definition arch specific. ia64/xen needs four vectors.
    Add one rmb() because on ia64 xchg() isn't barrier.

    Signed-off-by: Isaku Yamahata
    Signed-off-by: Jeremy Fitzhardinge
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Isaku Yamahata
     

18 Jul, 2007

3 commits

  • Implement a Xen back-end for hvc console.

    * * *
    Add early printk support via hvc console, enable using
    "earlyprintk=xen" on the kernel command line.

    From: Gerd Hoffmann
    Signed-off-by: Jeremy Fitzhardinge
    Signed-off-by: Chris Wright
    Acked-by: Ingo Molnar
    Acked-by: Olof Johansson

    Jeremy Fitzhardinge
     
  • This is a fairly straightforward Xen implementation of smp_ops.

    Xen has its own IPI mechanisms, and has no dependency on any
    APIC-based IPI. The smp_ops hooks and the flush_tlb_others pv_op
    allow a Xen guest to avoid all APIC code in arch/i386 (the only apic
    operation is a single apic_read for the apic version number).

    One subtle point which needs to be addressed is unpinning pagetables
    when another cpu may have a lazy tlb reference to the pagetable. Xen
    will not allow an in-use pagetable to be unpinned, so we must find any
    other cpus with a reference to the pagetable and get them to shoot
    down their references.

    Signed-off-by: Jeremy Fitzhardinge
    Signed-off-by: Chris Wright
    Cc: Benjamin LaHaise
    Cc: Ingo Molnar
    Cc: Andi Kleen

    Jeremy Fitzhardinge
     
  • Xen implements interrupts in terms of event channels. Each guest
    domain gets 1024 event channels which can be used for a variety of
    purposes, such as Xen timer events, inter-domain events,
    inter-processor events (IPI) or for real hardware IRQs.

    Within the kernel, we map the event channels to IRQs, and implement
    the whole interrupt handling using a Xen irq_chip.

    Rather than setting NR_IRQ to 1024 under PARAVIRT in order to
    accomodate Xen, we create a dynamic mapping between event channels and
    IRQs. Ideally, Linux will eventually move towards dynamically
    allocating per-irq structures, and we can use a 1:1 mapping between
    event channels and irqs.

    Signed-off-by: Jeremy Fitzhardinge
    Signed-off-by: Chris Wright
    Cc: Ingo Molnar
    Cc: Eric W. Biederman

    Jeremy Fitzhardinge