[PATCH] xen: complete device_attribute

in xenbus_probe and xenbus_probe_backend

Define global xenbus_dev_attrs for xenbus front and backend 
dev_atts, and do some clean work for xenbus front and xenbus 
backend code.

(xenbus code in alikernel is much more close to upstream, so
keep close to upstream here.)

Signed-off-by: Charles Wang <muming.wq@taobao.com>
[PATCH] xen: fbdev frontend needs xenbus frontend

The fbdev (and kbddev) frontend needs the xenbus frontend, but does not
define a dependency.  Make the fbdev frontend select the xenbus
frontend.

Signed-off-by: Bastian Blank <waldi@debian.org>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Charles Wang <muming.wq@taobao.com>
[PATCH] blktap: Fix wild ptr deref during device destruction.

A put_disk() before blk_cleanup_queue() would free gd before gd->queue
is read.

Signed-off-by: Daniel Stodden <daniel.stodden@citrix.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Charles Wang <muming.wq@taobao.com>
[PATCH] blktap: Fix queue restart, racing block device removal.

Makes tapdisk context test dev->gd before attempting a queue restart,
with the device lock held. Fixes a race lost against device
destruction, which may issued anywhere on the control path.

Signed-off-by: Daniel Stodden <daniel.stodden@citrix.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Charles Wang <muming.wq@taobao.com>
[PATCH] xen/blktap: Fix tap kobj double unref in sysfs_destroy

It's that final put_device in device_unregister which is supposed to
clear the caller's reference. Subtle indeed, because refcount went
2->3 when after sysfs_destroy:

 +1 for our own ring->dev
 +1 for the open sysfs ./remove attribute
 +1 for the callback scheduled

Drops to 1 in device_unregister and 0 only after leaving callbacks.

Signed-off-by: Daniel Stodden <daniel.stodden@citrix.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Charles Wang <muming.wq@taobao.com>
[PATCH] agp: Use PAGE_KERNEL_IO_NOCACHE for AGP mappings

When mapping AGP memory, the offset is a machine address.  In Xen we
need to make sure mappings of physical machine addresses have _PAGE_IO
included in the PTE, so use PAGE_KERNEL_IO_NOCACHE for these mappings.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Charles Wang <muming.wq@taobao.com>
[PATCH] x86: define arch_vm_get_page_prot to set _PAGE_IOMAP on

 VM_IO vmas

commit: 9016c11715c77eeaf7c3f7601f455dacacc02d7f

Set _PAGE_IOMAP in ptes mapping a VM_IO vma.  This says that the mapping
is of a real piece of physical hardware, and not just system memory.

Xen, in particular, uses to this to inhibit the normal pfn->mfn conversion
that would normally happen - in other words, treat the address directly
as a machine physical address without converting it from pseudo-physical.

[ Impact: make VM_IO mappings map the right thing under Xen ]

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Charles Wang <muming.wq@taobao.com>
patch agp-intel-use-dma_alloc_coherent-for-special-cursor-.patch
[PATCH] drm: recompute vma->vm_page_prot after changing vm_flags

vm_get_page_prot() computes vm_page_prot depending on vm_flags, so
we need to re-call it if we change flags.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Charles Wang <muming.wq@taobao.com>
[PATCH] drm: make sure all pages in vmalloc area are really

 DMA-ready

commit: 726efc2f3ddb86435cfd1f62372f115b3268cea6

Under Xen, vmalloc_32() isn't guaranteed to return pages which are really
under 4G in machine physical addresses (only in virtual pseudo-physical
addresses).  To work around this, implement a vmalloc variant which
allocates each page with dma_alloc_coherent() to guarantee that each
page is suitable for the device in question.

(This is playing rather fast-and-loose with dma_alloc_coherent by
assuming that vfree will correctly release the pages.  That happens
to be OK for Xen, but will quite likely break if its drawing memory
from another type of IOMMU... So I don't think this alone is the correct
solution.)

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Charles Wang <muming.wq@taobao.com>
[PATCH] drm: free vmalloc dma memory properly

Having allocated pages with drm_alloc_coherent, we need to free them with
drm_free_coherent.  We're still not preserving the bus addresses so
we're hoping the backend dma_ops implementation can cope with the ones
we're making up.

Derived from patch by Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Charles Wang <muming.wq@taobao.com>
[PATCH] fb-defio: If FBINFO_VIRTFB is defined, do not set VM_IO

 flag.

commit: 8d944da6c29ed307db601dd6c375240a97b08d2f

Most users (except sh_mobile_lcdcfb.c) get their framebuffer from
vmalloc. Setting VM_IO is not necessary as the memory obtained
from vmalloc is System RAM type and is not susceptible to PCI memory
constraints.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Acked-by: Jaya Kumar <jayakumar.lkml@gmail.com>
Signed-off-by: Charles Wang <muming.wq@taobao.com>
[PATCH] fb-defio: Inhibit VM_IO flag to be set on vmalloc-ed

 framebuffers.

commit: c0509cfdd2600eb9a4a565dc1837ddcf87b101ce

The framebuffers (screenbase) these drivers present are actually
vmalloc-ed pages. There is no need for them to have the VM_IO flag set.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Acked-by: Jaya Kumar <jayakumar.lkml@gmail.com>
Signed-off-by: Charles Wang <muming.wq@taobao.com>
patch xen-pvfb-Inhibit-VM_IO-flag-to-be-set-on-vmalloc-ed-.patch
patch pci-xen-For-non-privileged-domains-implement-a-pcibi.patch
[PATCH] pci: Export pci_walk_bus function.

In preperation of modularizing Xen-pcifront the pci_walk_bus
needs to be exported so that the xen-pcifront module can walk
call the pci subsystem to walk the PCI devices and claim them.

Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> [http://marc.info/?l=linux-pci&m=126149958010298&w=2]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Charles Wang <muming.wq@taobao.com>
[PATCH] xen: Find an unbound irq number in reverse order (high to

 low).

commit: 482839e7b96098f678d0404ec4dd321419ab3ea7

In earlier Xen Linux kernels, the IRQ mapping was a straight 1:1 and the
find_unbound_irq started looking around 256 for open IRQs and up. IRQs
from 0 to 255 were reserved for PCI devices.  Previous to this patch,
the 'find_unbound_irq'  started looking at get_nr_hw_irqs() number.
For privileged  domain where the ACPI information is available that
returns the upper-bound of what the GSIs. For non-privileged PV domains,
where ACPI is no-existent the get_nr_hw_irqs() reports the IRQ_LEGACY (16).
With PCI passthrough enabled, and with PCI cards that have IRQs pinned
to a higher number than 16 we collide with previously allocated IRQs.
Specifically the PCI IRQs collide with the IPI's for Xen functions
(as they are allocated earlier).
For example:

00:00.11 USB Controller: ATI Technologies Inc SB700 USB OHCI1 Controller (prog-if 10 [OHCI])
        ...
        Interrupt: pin A routed to IRQ 18

[root@localhost ~]# cat /proc/interrupts | head
           CPU0       CPU1       CPU2
 16:      38186          0          0   xen-dyn-virq      timer0
 17:        149          0          0   xen-dyn-ipi       spinlock0
 18:        962          0          0   xen-dyn-ipi       resched0

and when the USB controller is loaded, the kernel reports:
IRQ handler type mismatch for IRQ 18
current handler: resched0

One way to fix this is to reverse the logic when looking for un-used
IRQ numbers and start with the highest available number. With that,
we would get:

           CPU0       CPU1       CPU2
... snip ..
292:         35          0          0   xen-dyn-ipi       callfunc0
293:       3992          0          0   xen-dyn-ipi       resched0
294:        224          0          0   xen-dyn-ipi       spinlock0
295:      57183          0          0   xen-dyn-virq      timer0
NMI:          0          0          0   Non-maskable interrupts
.. snip ..

And interrupts for PCI cards are now accessible.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Charles Wang <muming.wq@taobao.com>
[PATCH] xen: fix off-by-one error in find_unbound_irq

68458a36 "fix off-by-one error in find_unbound_irq" introduced an issue with
the error handling in this function. It incorrectly assumed that exiting the
searhc loop with irq == nr_irqs - 1 was an error case when in fact it is
prefectly possible for irq == nr_irqs - 1 to be an available IRQ.

The actual error condition which 68458a36 tried to fix is when start ==
nr_irqs, IOW when there is literaly no interrupts which aren't already h/w
interrupts.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Charles Wang <muming.wq@taobao.com>
 drivers/xen/events.c |   10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)
[PATCH] xen: Provide a variant of xen_poll_irq with timeout.

The 'xen_poll_irq_timeout' provides a method to pass in
the poll timeout for IRQs if requested.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Charles Wang <muming.wq@taobao.com>
[PATCH] xen: Export xen_clear_irq_pending and xen_poll_irq_timeout

 as the PCI front module utilizes them.

commit: 707c9601ba85ed99184e0595e26bcca6f27bb3e7

These two functions are used in the IRQ handler of the PCI front
driver to check its state. They need to be accessible if
PCI front is compiled as a module.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Charles Wang <muming.wq@taobao.com>