[GIT PULL] Xen for 2.6.30 #1

[GIT PULL] Xen for 2.6.30 #1

[Jeremy Fitzhardinge]

Hi Linus,

This is the first set of Xen changes for 2.6.30.  This set contains 
updates, bugfixes, etc for the existing Xen domU support.

The following pull request will have the dom0 bits.

Thanks,
       J

The following changes since commit 0d34fb8e93ceba7b6dad0062dbb4a0813bacd75b:
  Linus Torvalds (1):
        Merge branch 'bzip2-lzma-for-linus' of git://git.kernel.org/.../x86/linux-2.6-tip

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git for-linus/xen/master

Alex Nixon (1):
      Xen: Add virt_to_pfn helper function

Hannes Eder (1):
      NULL noise: arch/x86/xen/smp.c

Ian Campbell (7):
      xen: resume interrupts before system devices.
      xen: add irq_from_evtchn
      xen: add /dev/xen/evtchn driver
      xen: export ioctl headers to userspace
      xen: remove suspend_cancel hook
      xen: use device model for suspending xenbus devices
      xen: drop kexec bits from /sys/hypervisor since kexec isn't implemented yet

Jeremy Fitzhardinge (27):
      mm: disable preemption in apply_to_pte_range
      x86/paravirt: remove lazy mode in interrupts
      x86/pvops: replace arch_enter_lazy_cpu_mode with arch_start_context_switch
      x86/paravirt: flush pending mmu updates on context switch
      x86/paravirt: finish change from lazy cpu to context switch start/end
      x86/paravirt: allow preemption with lazy mmu mode
      mm: allow preemption in apply_to_pte_range
      x86/paravirt: use percpu_ rather than __get_cpu_var
      xen: disable preempt for leave_lazy_mmu
      xen: separate p2m allocation from setting
      xen: split construction of p2m mfn tables from registration
      xen: clean up xen_load_gdt
      xen: make xen_load_gdt simpler
      xen: remove xen_load_gdt debug
      xen: mask XSAVE from cpuid
      x86-64: remove PGE from must-have feature list
      x86-64: non-paravirt systems always has PSE and PGE
      xen/mmu: some early pagetable cleanups
      xen/mmu: weaken flush_tlb_other test
      xen: set _PAGE_NX in __supported_pte_mask before pagetable construction
      xen: clean up gate trap/interrupt constants
      xen/dev-evtchn: clean up locking in evtchn
      xen/xenbus: export xenbus_dev_changed
      xen: add /sys/hypervisor support
      xen/sys/hypervisor: change writable_pt to features
      xen: add "capabilities" file
      Merge branches 'for-linus/xen/dev-evtchn', 'for-linus/xen/xenbus', 'for-linus/xen/xenfs' and 'for-linus/xen/sys-hypervisor' into for-linus/xen/master

 arch/x86/include/asm/paravirt.h          |   22 +-
 arch/x86/include/asm/pgtable.h           |    2 +
 arch/x86/include/asm/required-features.h |    8 +-
 arch/x86/include/asm/thread_info.h       |    2 +
 arch/x86/include/asm/xen/page.h          |    3 +-
 arch/x86/kernel/kvm.c                    |    2 +-
 arch/x86/kernel/paravirt.c               |   56 ++--
 arch/x86/kernel/process_32.c             |    2 +-
 arch/x86/kernel/process_64.c             |    2 +-
 arch/x86/kernel/vmi_32.c                 |   20 +-
 arch/x86/lguest/boot.c                   |   16 +-
 arch/x86/mm/fault.c                      |    6 +-
 arch/x86/mm/highmem_32.c                 |    2 -
 arch/x86/mm/iomap_32.c                   |    1 -
 arch/x86/mm/pageattr.c                   |   14 -
 arch/x86/xen/enlighten.c                 |   99 +++++--
 arch/x86/xen/mmu.c                       |  134 ++++++---
 arch/x86/xen/mmu.h                       |    3 +
 arch/x86/xen/smp.c                       |    4 +-
 arch/x86/xen/xen-ops.h                   |    3 -
 drivers/xen/Kconfig                      |   20 ++
 drivers/xen/Makefile                     |    4 +-
 drivers/xen/events.c                     |    6 +
 drivers/xen/evtchn.c                     |  507 ++++++++++++++++++++++++++++++
 drivers/xen/manage.c                     |   15 +-
 drivers/xen/sys-hypervisor.c             |  445 ++++++++++++++++++++++++++
 drivers/xen/xenbus/xenbus_probe.c        |   61 +---
 drivers/xen/xenbus/xenbus_xs.c           |    2 +
 drivers/xen/xenfs/super.c                |   19 +-
 include/Kbuild                           |    1 +
 include/asm-frv/pgtable.h                |    4 +-
 include/asm-generic/pgtable.h            |   21 +-
 include/xen/Kbuild                       |    1 +
 include/xen/events.h                     |    3 +
 include/xen/evtchn.h                     |   88 +++++
 include/xen/interface/version.h          |    3 +
 include/xen/xenbus.h                     |    3 +-
 kernel/sched.c                           |    2 +-
 38 files changed, 1376 insertions(+), 230 deletions(-)
 create mode 100644 drivers/xen/evtchn.c
 create mode 100644 drivers/xen/sys-hypervisor.c
 create mode 100644 include/xen/Kbuild
 create mode 100644 include/xen/evtchn.h

[GIT PULL] Xen for 2.6.30 #2

[Jeremy Fitzhardinge]

Hi Linus,

This is the second (and final) set of Xen updates for 2.6.30.  This set 
contains Xen dom0 support, which includes:

    * adding to the existing Xen support to allow running as a
      privileged domain
    * some hooks into the apic setup code to allow Xen interrupts to get
      routed properly
    * a Xen implementation of the DMA ops API
    * a Xen MTRR driver
    * other misc things

These changes only hook into init/setup code, and will have no runtime 
performance impact on native execution when CONFIG_PARAVIRT is enabled, 
and are completely compiled out without it.

These changes are more or less unchanged since their first posting about 
3-4 weeks ago.  The x86 parts have been reviewed (mainly by HPA) and 
considered not too objectionable.

I merged current linux-2.6 into my branch and sorted out the couple of 
minor conflicts with recent changes, and merged in the previous changes 
(the domU stuff).  So if you pull this, you'll get the previous pull 
with it; otherwise you can pull them in order.  Uh, I couldn't work out 
how to generate a shortlog+diffstat with just the dom0 set of changes, 
so it includes some of the previous pull-requests changes as well.

(I realize now the previous pull request didn't have much of an 
overview.  The quick take is:

    * allow lazy mmu updates to be preempted, removing some
      preempt_disable sections
    * general Xen core updates
    * add /sys/hypervisor support
    * add a /dev/xen/evtchn driver so usermode can wait for and send Xen
      events)


Thanks,
    J

The following changes since commit 15f7176eb1cccec0a332541285ee752b935c1c85:
  Linus Torvalds (1):
        Merge git://git.kernel.org/.../davem/net-2.6

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git for-linus/xen/merged

Alex Nixon (8):
      Xen: Add virt_to_pfn helper function
      xen: Don't disable the I/O space
      xen: Allow unprivileged Xen domains to create iomap pages
      Xen: Rename the balloon lock
      xen: Add xen_create_contiguous_region
      x86/PCI: Clean up pci_cache_line_size
      x86/PCI: Enable scanning of all pci functions
      Xen/x86/PCI: Add support for the Xen PCI subsytem

Christophe Saout (1):
      paravirtualize IO permission bitmap

Gerd Hoffmann (2):
      xen: set pirq name to something useful.
      xen: fix legacy irq setup, make ioapic-less machines work.

Hannes Eder (1):
      NULL noise: arch/x86/xen/smp.c

Ian Campbell (13):
      xen: resume interrupts before system devices.
      xen: disable PAT
      xen/dom0: Use host E820 map
      xen: implement XENMEM_machphys_mapping
      xen: clear reserved bits in l3 entries given in the initial pagetables
      xen: pre-initialize legacy irqs early
      xen: add /proc/xen/xsd_{kva,port} to xenfs
      swiotlb: range_needs_mapping should take a physical address.
      swiotlb: do not use sg_virt()
      xen swiotlb: fixup swiotlb is chunks smaller than MAX_CONTIG_ORDER
      xen: add hooks for mapping phys<->bus addresses in swiotlb
      xen/swiotlb: add hook for swiotlb_arch_range_needs_mapping
      xen: enable swiotlb for xen domain 0.

Jeremy Fitzhardinge (74):
      mm: disable preemption in apply_to_pte_range
      x86/paravirt: remove lazy mode in interrupts
      x86/pvops: replace arch_enter_lazy_cpu_mode with arch_start_context_switch
      x86/paravirt: flush pending mmu updates on context switch
      x86/paravirt: finish change from lazy cpu to context switch start/end
      x86/paravirt: allow preemption with lazy mmu mode
      mm: allow preemption in apply_to_pte_range
      x86/paravirt: use percpu_ rather than __get_cpu_var
      xen: disable preempt for leave_lazy_mmu
      xen: separate p2m allocation from setting
      xen: split construction of p2m mfn tables from registration
      xen: clean up xen_load_gdt
      xen: make xen_load_gdt simpler
      xen: remove xen_load_gdt debug
      xen: mask XSAVE from cpuid
      x86-64: remove PGE from must-have feature list
      x86-64: non-paravirt systems always has PSE and PGE
      xen/mmu: some early pagetable cleanups
      xen/mmu: weaken flush_tlb_other test
      xen: set _PAGE_NX in __supported_pte_mask before pagetable construction
      xen: clean up gate trap/interrupt constants
      xen dom0: Make hvc_xen console work for dom0.
      xen: add "capabilities" file
      xen/dom0: use _PAGE_IOMAP in ioremap to do machine mappings
      xen: allow enable use of VGA console on dom0
      xen/dom0: add XEN_DOM0 config option
      x86: make /dev/mem mappings _PAGE_IOMAP
      x86: don't need "changed" parameter for set_io_bitmap()
      xen: checkpatch cleanups
      xen/dom0: handle acpi lapic parsing in Xen dom0
      xen: hook io_apic read/write operations
      xen: create dummy ioapic mapping
      xen: implement pirq type event channels
      x86/io_apic: add get_nr_irqs_gsi()
      xen/apic: identity map gsi->irqs
      xen: direct irq registration to pirq event channels
      xen: bind pirq to vector and event channel
      xen: don't setup acpi interrupt unless there is one
      xen: use acpi_get_override_irq() to get triggering for legacy irqs
      xen: initialize irq 0 too
      xen: dynamically allocate irq & event structures
      xen: disable MSI
      xen/apic: checkpatch cleanups
      xen: set cpu_callout_mask to make mtrr work
      xen: set cpu_callout_mask in cpu_up
      Merge branch 'for-linus/xen/xenfs' into for-linus/xen/dom0/xenfs
      xen: add xen_set_domain_pte()
      xen: add privcmd driver
      xen/privcmd: create address space to allow writable mmaps
      xen: add variable hypercall caller
      xen/privcmd: clean up ioctls into their own functions
      xen/privcmd: rearrange mmap ioctl to share code
      xen/xenfs: set_page_dirty is supposed to return true if it dirties
      xen/privcmd: print SIGBUS faults
      xen/privcmd: make sure vma is ours before doing anything to it
      xenbus: export xen_store_interface for xenfs
      xen/xenfs: checkpatch cleanups
      x86/pci: make sure _PAGE_IOMAP it set on pci mappings
      xen/pci: clean up Kconfig a bit
      xen: make sure swiotlb allocation is physically contigious
      xen/swiotlb: use dma_alloc_from_coherent to get device coherent memory
      swiotlb: use swiotlb_alloc_boot to allocate emergency pool
      xen/swiotlb: improve comment on gfp flags in xen_alloc_coherent()
      xen/swiotlb: add sync functions
      pci-swiotlb: fix "no return in non-void function"
      pci-swiotlb: remove __weak vs __weak binding
      xen: checkpatch cleanups
      x86: define arch_vm_get_page_prot to set _PAGE_IOMAP on VM_IO vmas
      agp: use more dma-ops-like operations for agp memory
      agp/intel: use dma_alloc_coherent for special cursor memory
      Merge branches 'for-linus/xen/dom0/apic', 'for-linus/xen/dom0/pci', 'for-linus/xen/dom0/drm', 'for-linus/xen/dom0/mtrr' and 'for-linus/xen/dom0/xenfs' into for-linus/xen/dom0/master
      Merge commit 'origin/master' into for-linus/xen/merged
      xen/swiotlb: update to new new dma_ops
      xen/apic: add pin argument to setup_ioapic_entry()

Juan Quintela (2):
      xen dom0: Initialize xenbus for dom0.
      xen dom0: Set up basic IO permissions for dom0.

Mark McLoughlin (5):
      xen mtrr: Use specific cpu_has_foo macros instead of generic cpu_has()
      xen mtrr: Use generic_validate_add_page()
      xen mtrr: Implement xen_get_free_region()
      xen mtrr: Add xen_{get,set}_mtrr() implementations
      xen mtrr: Kill some unnecessary includes

Stephen Tweedie (2):
      xen dom0: Add support for the platform_ops hypercall
      xen mtrr: Add mtrr_ops support for Xen mtrr

 arch/x86/Kconfig                         |    4 +
 arch/x86/include/asm/agp.h               |   15 +-
 arch/x86/include/asm/io.h                |    2 +
 arch/x86/include/asm/io_apic.h           |    7 +
 arch/x86/include/asm/paravirt.h          |   31 ++-
 arch/x86/include/asm/pat.h               |    5 +
 arch/x86/include/asm/pci.h               |    8 +-
 arch/x86/include/asm/pci_x86.h           |    2 +
 arch/x86/include/asm/pgtable.h           |    5 +
 arch/x86/include/asm/processor.h         |    4 +
 arch/x86/include/asm/required-features.h |    8 +-
 arch/x86/include/asm/thread_info.h       |    2 +
 arch/x86/include/asm/xen/hypercall.h     |   25 ++
 arch/x86/include/asm/xen/interface.h     |    6 +-
 arch/x86/include/asm/xen/interface_32.h  |    5 +
 arch/x86/include/asm/xen/interface_64.h  |   13 +-
 arch/x86/include/asm/xen/iommu.h         |   12 +
 arch/x86/include/asm/xen/page.h          |   19 +-
 arch/x86/include/asm/xen/pci.h           |   13 +
 arch/x86/kernel/acpi/boot.c              |   18 +-
 arch/x86/kernel/apic/io_apic.c           |   37 ++-
 arch/x86/kernel/cpu/mtrr/Makefile        |    1 +
 arch/x86/kernel/cpu/mtrr/amd.c           |    1 +
 arch/x86/kernel/cpu/mtrr/centaur.c       |    1 +
 arch/x86/kernel/cpu/mtrr/cyrix.c         |    1 +
 arch/x86/kernel/cpu/mtrr/generic.c       |    1 +
 arch/x86/kernel/cpu/mtrr/main.c          |   11 +-
 arch/x86/kernel/cpu/mtrr/mtrr.h          |    7 +
 arch/x86/kernel/cpu/mtrr/xen.c           |  120 ++++++++
 arch/x86/kernel/ioport.c                 |   29 ++-
 arch/x86/kernel/kvm.c                    |    2 +-
 arch/x86/kernel/paravirt.c               |   57 ++--
 arch/x86/kernel/pci-dma.c                |    3 +
 arch/x86/kernel/pci-swiotlb.c            |   31 ++-
 arch/x86/kernel/process.c                |   27 +--
 arch/x86/kernel/process_32.c             |    2 +-
 arch/x86/kernel/process_64.c             |    2 +-
 arch/x86/kernel/vmi_32.c                 |   20 +-
 arch/x86/lguest/boot.c                   |   16 +-
 arch/x86/mm/fault.c                      |    6 +-
 arch/x86/mm/highmem_32.c                 |    2 -
 arch/x86/mm/iomap_32.c                   |    1 -
 arch/x86/mm/pageattr.c                   |   14 -
 arch/x86/mm/pat.c                        |    7 +-
 arch/x86/mm/pgtable.c                    |   10 +
 arch/x86/pci/Makefile                    |    1 +
 arch/x86/pci/common.c                    |   18 +-
 arch/x86/pci/i386.c                      |    3 +
 arch/x86/pci/init.c                      |    6 +
 arch/x86/pci/xen.c                       |   51 +++
 arch/x86/xen/Kconfig                     |   40 +++
 arch/x86/xen/Makefile                    |    4 +-
 arch/x86/xen/apic.c                      |   60 ++++
 arch/x86/xen/enlighten.c                 |  150 ++++++++--
 arch/x86/xen/mmu.c                       |  490 +++++++++++++++++++++++++++---
 arch/x86/xen/mmu.h                       |    3 +
 arch/x86/xen/pci.c                       |   86 ++++++
 arch/x86/xen/setup.c                     |   50 +++-
 arch/x86/xen/smp.c                       |    6 +-
 arch/x86/xen/vga.c                       |   68 ++++
 arch/x86/xen/xen-ops.h                   |   21 ++-
 drivers/char/agp/intel-agp.c             |   24 +-
 drivers/char/hvc_xen.c                   |   99 ++++--
 drivers/pci/Makefile                     |    2 +
 drivers/pci/pci.h                        |    2 -
 drivers/pci/xen-iommu.c                  |  331 ++++++++++++++++++++
 drivers/xen/balloon.c                    |   15 +-
 drivers/xen/events.c                     |  276 ++++++++++++++++-
 drivers/xen/manage.c                     |    5 +-
 drivers/xen/xenbus/xenbus_probe.c        |   34 ++-
 drivers/xen/xenfs/Makefile               |    3 +-
 drivers/xen/xenfs/privcmd.c              |  442 +++++++++++++++++++++++++++
 drivers/xen/xenfs/super.c                |  115 +++++++-
 drivers/xen/xenfs/xenfs.h                |    3 +
 drivers/xen/xenfs/xenstored.c            |   67 ++++
 include/asm-frv/pgtable.h                |    4 +-
 include/asm-generic/pgtable.h            |   21 +-
 include/linux/pci.h                      |    6 +
 include/xen/Kbuild                       |    1 +
 include/xen/events.h                     |   24 ++
 include/xen/interface/memory.h           |   92 ++++++
 include/xen/interface/platform.h         |  222 ++++++++++++++
 include/xen/interface/xen.h              |   41 +++
 include/xen/privcmd.h                    |   80 +++++
 include/xen/swiotlb.h                    |   20 ++
 include/xen/xen-ops.h                    |    6 +
 kernel/sched.c                           |    2 +-
 lib/swiotlb.c                            |    5 +-
 88 files changed, 3276 insertions(+), 336 deletions(-)
 create mode 100644 arch/x86/include/asm/xen/iommu.h
 create mode 100644 arch/x86/include/asm/xen/pci.h
 create mode 100644 arch/x86/kernel/cpu/mtrr/xen.c
 create mode 100644 arch/x86/pci/xen.c
 create mode 100644 arch/x86/xen/apic.c
 create mode 100644 arch/x86/xen/pci.c
 create mode 100644 arch/x86/xen/vga.c
 create mode 100644 drivers/pci/xen-iommu.c
 create mode 100644 drivers/xen/xenfs/privcmd.c
 create mode 100644 drivers/xen/xenfs/xenstored.c
 create mode 100644 include/xen/Kbuild
 create mode 100644 include/xen/interface/platform.h
 create mode 100644 include/xen/privcmd.h
 create mode 100644 include/xen/swiotlb.h

Re: [GIT PULL] Xen for 2.6.30 #2

[Ingo Molnar]

* Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> Hi Linus,
>
> This is the second (and final) set of Xen updates for 2.6.30.  
> This set contains Xen dom0 support, which includes:
>
>    * adding to the existing Xen support to allow running as a
>      privileged domain
>    * some hooks into the apic setup code to allow Xen interrupts to get
>      routed properly
>    * a Xen implementation of the DMA ops API
>    * a Xen MTRR driver
>    * other misc things
>
> These changes only hook into init/setup code, and will have no 
> runtime performance impact on native execution when 
> CONFIG_PARAVIRT is enabled, and are completely compiled out 
> without it.
>
> These changes are more or less unchanged since their first posting 
> about 3-4 weeks ago.  The x86 parts have been reviewed (mainly by 
> HPA) and considered not too objectionable.

This stuff is still on my list of things to look at.

AFAIK hpa had a look and found it not too objectionable, but didnt 
ack it, which means the green lights to:

  - review it in detail
 1- then after a round of review feedbacks merge it into the x86 tree
  - then to test it there
  - then to fix the (inevitable) bugs and go to 1 until bug-free
  - then to stage it to linux-next
  - then after many weeks and months, to eventually send it to Linus

That's NOT the same thing as you sending it straight to Linus, 
without the broad acks from the x86 maintainers for all details.

I had a quick look, and stuff like this is not acceptable:

 static inline unsigned int io_apic_read(unsigned int apic, unsigned int reg)
 {
-       struct io_apic __iomem *io_apic = io_apic_base(apic);
+       struct io_apic __iomem *io_apic;
+
+       if (xen_initial_domain())
+               return xen_io_apic_read(apic, reg);
+
+       io_apic = io_apic_base(apic);

Should be done by introducing your own xen specific irqchip. And 
this is not news to you, it has been told you in _early February_:

  http://lkml.indiana.edu/hypermail/linux/kernel/0902.1/00410.html

You didnt reply to that feedback of mine and you didnt fix it.

We are not putting some xen-specific hack into core x86 code ... The 
irqchip method wont put overhead and ugliness into native Linux. 
It's an existing abstraction for such stuff, use it and extend it if 
needed.

And stuff like this in arch/x86/kernel/pci-swiotlb.c:

  dma_addr_t swiotlb_phys_to_bus(struct device *hwdev, phys_addr_t paddr)
  {
 +#ifdef CONFIG_PCI_XEN
 +       if (xen_pv_domain())
 +               return xen_phys_to_bus(paddr);
 +#endif
         return paddr;
  }

and the other PCI bits very much need the ack of the PCI and 
sw-IOMMU folks (Fujita Tomonori mainly). I'd be surprised if they 
werent disgusted by it.

I dont mind pull requests outside of maintenance boundaries, as long 
as the changes are good.

You know our stance which is very simple: dont put in Xen-only hooks 
that slow down native, and get rid of the existing Xen-only hooks.

	Ingo

Re: [Xen-devel] Re: [GIT PULL] Xen for 2.6.30 #2

[Jeremy Fitzhardinge]

Ingo Molnar wrote:
>   - review it in detail
>  1- then after a round of review feedbacks merge it into the x86 tree
>   - then to test it there
>   - then to fix the (inevitable) bugs and go to 1 until bug-free
>   - then to stage it to linux-next
>   - then after many weeks and months, to eventually send it to Linus
>
> That's NOT the same thing as you sending it straight to Linus, 
> without the broad acks from the x86 maintainers for all details.
>   

I sent mail to you about this several days ago, announcing my intention 
to post if I didn't hear back from you.   I heard nothing and went ahead.

I've been working with HPA to get him to review all the x86 
interactions, and reviewed-by the patches accordingly.  I have sent you 
these patches several times over the last month, but haven't seen any 
response.

> I had a quick look, and stuff like this is not acceptable:
>
>  static inline unsigned int io_apic_read(unsigned int apic, unsigned int reg)
>  {
> -       struct io_apic __iomem *io_apic = io_apic_base(apic);
> +       struct io_apic __iomem *io_apic;
> +
> +       if (xen_initial_domain())
> +               return xen_io_apic_read(apic, reg);
> +
> +       io_apic = io_apic_base(apic);
>
> Should be done by introducing your own xen specific irqchip. And 
> this is not news to you, it has been told you in _early February_:
>
>   http://lkml.indiana.edu/hypermail/linux/kernel/0902.1/00410.html
>
> You didnt reply to that feedback of mine and you didnt fix it.
>   

Yes, you've suggested that several times; that particular mail was about 
a different issue, for which it also wasn't the answer.  (I didn't reply 
because shortly after you sent me with another mail saying "Ok, never 
mind my comment on the do_IRQ() detail, this looks good after all[...]")

We *do* define our own irqchip (drivers/xen/events.c), but that 
interface doesn't cover IO apic interactions, which are primarily used 
when doing apic setup, and to set up interrupt routing. 
ioapic_write_entry(), for example, is not reached via any irq_chip method.

In this case we want the normal apic setup to go ahead, but the actual 
read/writes to the apic registers need to be directed to a hypercall.

> We are not putting some xen-specific hack into core x86 code ... The 
> irqchip method wont put overhead and ugliness into native Linux. 
> It's an existing abstraction for such stuff, use it and extend it if 
> needed.
>   
No, it isn't, because it doesn't encapsulate the whole apic layer.  I 
don't want to duplicate all that code; I want to use it (mostly) as-is.

I went around this several times with HPA.  My initial version of the 
patch introduced an io_apic_ops and hooked it appropriately.  He 
objected on the grounds that its pointless adding an extra level of 
abstraction for a single user; he preferred a straightforward call, as 
it is here.  This change is Xen-specific, but it disappears completely 
if you don't enable Xen and it is not on a performance-critical path.  
If any other users appear here, we can easily add an appropriate 
abstraction layer.

> And stuff like this in arch/x86/kernel/pci-swiotlb.c:
>
>   dma_addr_t swiotlb_phys_to_bus(struct device *hwdev, phys_addr_t paddr)
>   {
>  +#ifdef CONFIG_PCI_XEN
>  +       if (xen_pv_domain())
>  +               return xen_phys_to_bus(paddr);
>  +#endif
>          return paddr;
>   }
>
> and the other PCI bits very much need the ack of the PCI and 
> sw-IOMMU folks (Fujita Tomonori mainly). I'd be surprised if they 
> werent disgusted by it.
>   

I believe they've been cc:ed on all these patches, but I'll repost the 
relevent bits to make sure.  The #ifdef definitely should not be there.

> I dont mind pull requests outside of maintenance boundaries, as long 
> as the changes are good.
>   

Well, I've been trying to get your comments about these patches for at 
least a month now, with the intention of hitting this merge window.  I 
realize you're very busy overall, so when HPA took the time to review 
them I didn't see the need to also press it with you.  And I certainly 
wasn't going to let the window go by without doing anything.

> You know our stance which is very simple: dont put in Xen-only hooks 
> that slow down native, and get rid of the existing Xen-only hooks.
>   

Yes, I understand that.  Unlike the pvops stuff, the dom0 changes are 
largely all init-time and setup, and so have no performance impact. 

    J

Re: [Xen-devel] Re: [GIT PULL] Xen for 2.6.30 #2

[Ingo Molnar]

* Jeremy Fitzhardinge <jeremy@goop.org> wrote:

>> You know our stance which is very simple: dont put in Xen-only 
>> hooks that slow down native, and get rid of the existing Xen-only 
>> hooks.
>
> Yes, I understand that.  Unlike the pvops stuff, the dom0 changes 
> are largely all init-time and setup, and so have no performance 
> impact.

Yes, but once dom0 goes in your incentive to fix the native kernel 
performance drain we accumulated along the years of paravirt layers 
will be strongly weakened, right? :)

	Ingo

Re: [Xen-devel] Re: [GIT PULL] Xen for 2.6.30 #2

[Jeremy Fitzhardinge]

Ingo Molnar wrote:
> Yes, but once dom0 goes in your incentive to fix the native kernel 
> performance drain we accumulated along the years of paravirt layers 
> will be strongly weakened, right? :)

Not at all.  There's a pile of performance work that needs to be done, 
both native and Xen.  I've been addressing it in an ad-hoc, time-sliced 
way so far, but I haven't had the chance to concentrate on it as I'd 
like to.  Once I get all the basic stuff off my plate I'll be able to 
actually focus.

Besides, its not really the sort of "incentive" that I respond to; I 
find it demotivating because it carries the presumption that I won't do 
"the right thing" without some element of coercion.  It's not like I 
don't already do a fair amount of generally beneficial kernel work.  If 
you think I should direct my attention in one direction over another, 
I'm happy to take suggestions.

    J

Re: [Xen-devel] Re: [GIT PULL] Xen for 2.6.30 #2

[William Pitcock]

Hi,

On Fri, 2009-04-03 at 19:36 +0200, Ingo Molnar wrote:
> * Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> 
> >> You know our stance which is very simple: dont put in Xen-only 
> >> hooks that slow down native, and get rid of the existing Xen-only 
> >> hooks.
> >
> > Yes, I understand that.  Unlike the pvops stuff, the dom0 changes 
> > are largely all init-time and setup, and so have no performance 
> > impact.
> 
> Yes, but once dom0 goes in your incentive to fix the native kernel 
> performance drain we accumulated along the years of paravirt layers 
> will be strongly weakened, right? :)
> 

There's plenty of incentive for everyone who has a stake in this thing
to ensure that paravirt performs equally to native. I do not see how you
could be legitimately concerned about that.

Are you saying that you are intentionally blocking dom0 work from
progressing (and thus alienating many enterprise linux users who have
millions of $ on hardware running Xen where switching to KVM is simply
NOT an option) because you feel that paravirt performance will not be
improved?

Regardless of however many kernel developers claim that KVM is an
enterprise-capable solution, it simply isn't. It may be at some point,
but that point is not today. Please let us have some modern hardware
support and features for our xen-based server clusters (well, without
forward-porting the 2.6.18 patchset) and stop this political bullshit.

William

Re: [Xen-devel] Re: [GIT PULL] Xen for 2.6.30 #2

[Ingo Molnar]

* William Pitcock <nenolod@dereferenced.org> wrote:

> Hi,
> 
> On Fri, 2009-04-03 at 19:36 +0200, Ingo Molnar wrote:
> > * Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> > 
> > >> You know our stance which is very simple: dont put in Xen-only 
> > >> hooks that slow down native, and get rid of the existing Xen-only 
> > >> hooks.
> > >
> > > Yes, I understand that.  Unlike the pvops stuff, the dom0 changes 
> > > are largely all init-time and setup, and so have no performance 
> > > impact.
> > 
> > Yes, but once dom0 goes in your incentive to fix the native 
> > kernel performance drain we accumulated along the years of 
> > paravirt layers will be strongly weakened, right? :)
> 
> There's plenty of incentive for everyone who has a stake in this 
> thing to ensure that paravirt performs equally to native. I do not 
> see how you could be legitimately concerned about that.

Well, instead of supposedly plenty of speculative incentives in the 
future i'd like to see the existing performance impact of paravirt 
features to be fixed here and now, before piling up new features. 
Which did not get fixed in the past two years, despite those plenty 
of incentives you claim.

This is a basic engineering principle: fix up existing performance 
impact before piling up more overhead.

	Ingo