linux/drivers/xen, branch v3.0.62

xen/xenbus: Add quirk to deal with misconfigured backends.

2012-04-27T16:51:05Z

commit 3066616ce23aad5719c23a0f21f32676402cb44b upstream. A rather annoying and common case is when booting a PVonHVM guest and exposing the PV KBD and PV VFB - as broken toolstacks don't always initialize the backends correctly. Normally The HVM guest is using the VGA driver and the emulated keyboard for this (though upstream version of QEMU implements PV KBD, but still uses a VGA driver). We provide a very basic two-stage wait mechanism - where we wait for 30 seconds for all devices, and then for 270 for all them except the two mentioned. That allows us to wait for the essential devices, like network or disk for the full 6 minutes. To trigger this, put this in your guest config: vfb = [ 'vnc=1, vnclisten=0.0.0.0 ,vncunused=1'] instead of this: vnc=1 vnclisten="0.0.0.0" Acked-by: Stefano Stabellini [v3: Split delay in non-essential (30 seconds) and essential devices per Ian and Stefano suggestion] [v4: Added comments per Stefano suggestion] Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman

xen/gntdev: do not set VM_PFNMAP

2012-04-27T16:51:05Z

commit e8e937be971d706061dc56220ff3605ab77622a7 upstream. Since we are using the m2p_override we do have struct pages corresponding to the user vma mmap'ed by gntdev. Removing the VM_PFNMAP flag makes get_user_pages work on that vma. An example test case would be using a Xen userspace block backend (QDISK) on a file on NFS using O_DIRECT. Signed-off-by: Stefano Stabellini Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman

xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.

2012-01-26T01:24:41Z

commit 9e7860cee18241633eddb36a4c34c7b61d8cecbc upstream. Haogang Chen found out that: There is a potential integer overflow in process_msg() that could result in cross-domain attack. body = kmalloc(msg->hdr.len + 1, GFP_NOIO | __GFP_HIGH); When a malicious guest passes 0xffffffff in msg->hdr.len, the subsequent call to xb_read() would write to a zero-length buffer. The other end of this connection is always the xenstore backend daemon so there is no guest (malicious or otherwise) which can do this. The xenstore daemon is a trusted component in the system. However this seem like a reasonable robustness improvement so we should have it. And Ian when read the API docs found that: The payload length (len field of the header) is limited to 4096 (XENSTORE_PAYLOAD_MAX) in both directions. If a client exceeds the limit, its xenstored connection will be immediately killed by xenstored, which is usually catastrophic from the client's point of view. Clients (particularly domains, which cannot just reconnect) should avoid this. so this patch checks against that instead. This also avoids a potential integer overflow pointed out by Haogang Chen. Signed-off-by: Ian Campbell Cc: Haogang Chen Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman

xen/swiotlb: Use page alignment for early buffer allocation.

2012-01-06T22:14:11Z

commit 63a741757d15320a25ebf5778f8651cce2ed0611 upstream. This fixes an odd bug found on a Dell PowerEdge 1850/0RC130 (BIOS A05 01/09/2006) where all of the modules doing pci_set_dma_mask would fail with: ata_piix 0000:00:1f.1: enabling device (0005 -> 0007) ata_piix 0000:00:1f.1: can't derive routing for PCI INT A ata_piix 0000:00:1f.1: BMDMA: failed to set dma mask, falling back to PIO The issue was the Xen-SWIOTLB was allocated such as that the end of buffer was stradling a page (and also above 4GB). The fix was spotted by Kalev Leonid which was to piggyback on git commit e79f86b2ef9c0a8c47225217c1018b7d3d90101c "swiotlb: Use page alignment for early buffer allocation" which: We could call free_bootmem_late() if swiotlb is not used, and it will shrink to page alignment. So alloc them with page alignment at first, to avoid lose two pages And doing that fixes the outstanding issue. Suggested-by: "Kalev, Leonid" Reported-and-Tested-by: "Taylor, Neal E" Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman

xen-gntalloc: signedness bug in add_grefs()

2011-11-21T22:31:24Z

commit 99cb2ddcc617f43917e94a4147aa3ccdb2bcd77e upstream. gref->gref_id is unsigned so the error handling didn't work. gnttab_grant_foreign_access() returns an int type, so we can add a cast here, and it doesn't cause any problems. gnttab_grant_foreign_access() can return a variety of errors including -ENOSPC, -ENOSYS and -ENOMEM. Signed-off-by: Dan Carpenter Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman

xen-gntalloc: integer overflow in gntalloc_ioctl_alloc()

2011-11-21T22:31:24Z

commit 21643e69a4c06f7ef155fbc70e3fba13fba4a756 upstream. On 32 bit systems a high value of op.count could lead to an integer overflow in the kzalloc() and gref_ids would be smaller than expected. If the you triggered another integer overflow in "if (gref_size + op.count > limit)" then you'd probably get memory corruption inside add_grefs(). Signed-off-by: Dan Carpenter Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman

genirq: Add IRQF_RESUME_EARLY and resume such IRQs earlier

2011-11-11T17:35:54Z

commit 9bab0b7fbaceec47d32db51cd9e59c82fb071f5a upstream. This adds a mechanism to resume selected IRQs during syscore_resume instead of dpm_resume_noirq. Under Xen we need to resume IRQs associated with IPIs early enough that the resched IPI is unmasked and we can therefore schedule ourselves out of the stop_machine where the suspend/resume takes place. This issue was introduced by 676dc3cf5bc3 "xen: Use IRQF_FORCE_RESUME". Signed-off-by: Ian Campbell Cc: Rafael J. Wysocki Cc: Jeremy Fitzhardinge Cc: xen-devel Cc: Konrad Rzeszutek Wilk Link: http://lkml.kernel.org/r/1318713254.11016.52.camel@dagon.hellion.org.uk Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman

xen-swiotlb: Fix wrong panic.

2011-11-11T17:35:46Z

commit ab2a47bd242d6cdcf6b2b64797f271c6f0a6d338 upstream. Propagate the baremetal git commit "swiotlb: fix wrong panic" (fba99fa38b023224680308a482e12a0eca87e4e1) in the Xen-SWIOTLB version. wherein swiotlb's map_page wrongly calls panic() when it can't find a buffer fit for device's dma mask. It should return an error instead. Devices with an odd dma mask (i.e. under 4G) like b44 network card hit this bug (the system crashes): http://marc.info/?l=linux-kernel&m=129648943830106&w=2 If xen-swiotlb returns an error, b44 driver can use the own bouncing mechanism. Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman

Merge branch 'stable/bug.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen

2011-06-20T16:01:33Z

* 'stable/bug.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen: xen/setup: Fix for incorrect xen_extra_mem_start. xen: When calling power_off, don't call the halt function. xen: Fix compile warning when CONFIG_SMP is not defined. xen: support CONFIG_MAXSMP xen: partially revert "xen: set max_pfn_mapped to the last pfn mapped"

xen: Fix compile warning when CONFIG_SMP is not defined.

2011-06-15T18:25:01Z

.. which is quite benign. drivers/xen/events.c:398: warning: unused variable ‘desc’ Signed-off-by: Konrad Rzeszutek Wilk