Only run it after we actually enable the power well. When we're
booting the machine there are cases where we run
hsw_power_well_post_enable without really needing, and even though
this is not causing any real bugs, it is unneeded and causes confusion
to people debugging interrupts.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Current chv spec teels we can only use either 16 or 32 bits as precision.
Although in the past VLV went from 16/32 to 32/64 and spec might not be updated,
these precision values brings stability and fixes some issues Wayne was facing.
Cc: Wayne Boyer <wayne.boyer@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Tested-by: Wayne Boyer <wayne.boyer@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Sprinkle const as requested by Ville.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The indirection here seems to serve no purpose. Probably leftovers
from earlier revisions. Spotted while trying to review some mst
patches.
Cc: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Otherwise we will get WARNs when we read context status registers and
the machine is suspended.
Testcase: igt/pm_rpm/debugfs-read
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I managed to fumble the per spline PCS DW11 register defines in:
commit 570e2a747b
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Mon Aug 18 14:42:46 2014 +0300
drm/i915: Clear TX FIFO reset master override bits on chv
Fortunately the bit in DW0 that was cleared due to this didn't have
any effect as long as the bit we meant to clear was already zero.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[danvet: Fix commit ref as pointed out by Jani.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
intel_crt_reset() resets the ADPA register on all gen5+ platforms.
However the debug message claims it's touching the PCH ADPA register
which is clearly not what it does on VLV. Drop the PCH part from
the debug message.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For some yet-undiscovered reason, when IPS gets enabled, the pipe CRC
changes. Since hsw_enable_ips() doesn't really guarantees to enable
IPS (it depends on package C-states), we can't really predict if IPS
is enabled or disabled while running our CRC tests, so let's just
completely disable IPS while pipe CRCs are being used.
If we find a way to make IPS not change the pipe CRC result, we may
want to fix IPS and then revert this patch. While this doesn't happen,
let's merge this patch, so every IGT test relying on the CRCs can
work on pipe A.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72864
Testcase: igt/kms_cursor_crc (and others)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In its current place, it just segfaults while trying to access the
CRTC structures:
[ 9132.421681] Call Trace:
[ 9132.421707] [<ffffffffa01130d8>] i915_get_crtc_scanoutpos+0x1e8/0x220 [i915]
[ 9132.421727] [<ffffffffa001da34>] drm_calc_vbltimestamp_from_scanoutpos+0x94/0x330 [drm]
[ 9132.421744] [<ffffffffa001d240>] ?vblank_disable_and_save+0x40/0x1e0 [drm]
[ 9132.421769] [<ffffffffa0114328>] i915_get_vblank_timestamp+0x68/0xb0 [i915]
[ 9132.421786] [<ffffffffa001d094>] drm_get_last_vbltimestamp+0x44/0x80 [drm]
[ 9132.421801] [<ffffffffa001d3a6>] vblank_disable_and_save+0x1a6/0x1e0 [drm]
[ 9132.421817] [<ffffffffa001eac1>] drm_vblank_cleanup+0x61/0xa0 [drm]
[ 9132.421849] [<ffffffffa0177a5e>] i915_driver_unload+0xde/0x290 [i915]
[ 9132.421867] [<ffffffffa0020264>] drm_dev_unregister+0x24/0xb0 [drm]
[ 9132.421884] [<ffffffffa002090e>] drm_put_dev+0x1e/0x70 [drm]
[ 9132.421901] [<ffffffffa00e01e0>] i915_pci_remove+0x10/0x20 [i915]
[ 9132.421910] [<ffffffff81347556>] pci_device_remove+0x36/0xb0
[ 9132.421920] [<ffffffff8140084a>] __device_release_driver+0x7a/0xf0
[ 9132.421928] [<ffffffff81400fc8>] driver_detach+0xb8/0xc0
[ 9132.421936] [<ffffffff8140054a>] bus_remove_driver+0x4a/0xb0
[ 9132.421944] [<ffffffff81401717>] driver_unregister+0x27/0x50
[ 9132.421953] [<ffffffff81346f65>] pci_unregister_driver+0x25/0x70
[ 9132.421971] [<ffffffffa00229c8>] drm_pci_exit+0x78/0xa0 [drm]
[ 9132.422000] [<ffffffffa017a6d2>] i915_exit+0x20/0x94e [i915]
[ 9132.422009] [<ffffffff810fb9dc>] SyS_delete_module+0x13c/0x1f0
[ 9132.422019] [<ffffffff8131c5fb>] ?
trace_hardirqs_on_thunk+0x3a/0x3f
[ 9132.422028] [<ffffffff816f7792>] system_call_fastpath+0x16/0x1b
This means it has to be before intel_modeset_cleanup, which cleans the
CRTC structures. But if we move it to before intel_fbdev_fini(), we
get WARNs because intel_fbdev_fini() still tries to use the vblanks,
so the only acceptable point for drm_vblank_cleanup() seems to be this
place.
Related commit:
commit cbb47d179f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Sep 23 17:33:20 2013 -0300
drm/i915: Add some missing steps to i915_driver_load error path
Testsuite: igt/drv_module_reload
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77511
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83484
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
SPT is always in the PCH override mode, and the bit MBZ. Only set
override on LPT.
v2: check for PCH version (Ville)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Some machines (like MBAs) might use a tiled framebuffer but not enable
display swizzling at boot time. We want to preserve that configuration
if possible to prevent a boot time mode set. On IVB+ it shouldn't
affect performance anyway since the memory controller does internal
swizzling anyway.
For most other configs we'll be able to enable swizzling at boot time,
since the initial framebuffer won't be tiled, thus we won't see any
corruption when we enable it.
v2: preserve swizzling if BIOS had it set (Daniel)
v3: preserve swizzling only if we inherited a tiled framebuffer (Daniel)
check display swizzle setting in detect_bit_6_swizzle (Daniel)
use gen6 as cutoff point (Daniel)
v4: fixup swizzle preserve again, had wrong init order (Daniel)
Reported-by: Kristian Høgsberg <hoegsberg@gmail.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
During S4 freeze we don't call intel_suspend_complete(), which would
save the gunit HW state, but during S4 thaw/restore events we call
intel_resume_prepare() which restores it, thus ending up in a corrupted
HW state.
Fix this by calling intel_suspend_complete() from the corresponding
freeze_late event handler.
The issue was introduced in
commit 016970beb0
Author: Sagar Kamble <sagar.a.kamble@intel.com>
Date: Wed Aug 13 23:07:06 2014 +0530
CC: Sagar Kamble <sagar.a.kamble@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As the workaround list has the value as initialization time
constant, we can do the simple checking on the go without
negleting igt.
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we build the workaround list in ring initialization
and decouple it from the actual writing of values, we
gain the ability to decide where and how we want to apply
the values.
The advantage of this will become more clear when
we need to initialize workarounds on older gens where
it is not possible to write all the registers through ring
LRIs.
v2: rebase on newest bdw workarounds
Cc: Arun Siluvery <arun.siluvery@linux.intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com>
[danvet: Resolve tiny conflict in comments and ocd alignments a bit.]
[danvet2: Remove bogus force_wake_get call spotted by Paulo and QA.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The whole file is only built with CONFIG_COMPAT=y.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The legacy DRM suspend logic (effective in UMS) doesn't handle any S4 thaw
events so we don't need to care about it either. Only S3 suspend and S4
freeze events are handled. Leave an assert behind to be sure.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For consistency, since that's the rule followed for internal functions.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For consistency, since that's the rule followed for internal functions.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For consistency, since that's the rule followed for internal functions.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In the ironlake mode set code, there was two instances of a loop through
encoders to find out if one of them has INTEL_OUTPUT_LVDS type. Simplify
the code by deleting some lines and use intel_pipe_has_type() instead.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Too many new drm driver writers seem to look at i915 for inspiration.
But we have two ways to do mmap, so discourage readers from the old,
ugly version. In a new driver we'd just expose two mmap offsets per
object, one for the gtt map and the other for the cpu map.
v2: Make it clear that i915 does cpu mmaps this way for past
cluelessness^W^W historical reasons. Asked for by Jani.
Cc: "Cheng, Yao" <yao.cheng@intel.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Let's clean this a bit
v2: Rebase after other Mika's patch that removed some BDW production workarounds.
v3: Removed stepping info.
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just a couple more macros that assume that they were being passed a
struct drm_device when they want a struct drm_i915_private. Use our
magic macro to ease transitioning over to using drm_i915_privates
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add support for 180 degree rotation for primary and sprite planes
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we are not able to free anything (the shrinker leaves nothing on the
global object lists), do not log anything. This is useful when other
subsystems are being stress-tested for their oom behaviour and i915.ko
is shouting into the logs about doing nothing.
Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The shrinker reports the number of pages freed, but we try to log the
number of bytes - which leads to some nonsense values being reportedly
freed during oom.
Reported-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Avoid to expose RC6 and RC6pp to the platforms that doesn't support it.
So powertop can be changed to show RC6p and RC6pp only on the platforms
they are available.
v2: Simplify by merging RC6p and RC6pp groups and respect the spec that
mentions deep and deepest RC6 on SNB and IVB although they keep disabled
by default.
v3: Remove unecessary space.
v4: RC6p and RC6pp is only for SNB and IVB; unify debug msg and use
has_rc6p() on sanitize options instead of is gen 6 and ivb.
v5: yet another fix on has_rc6p macro. final is_gen6 or is_ivb! To make sure
we are excluding hsw and baytrail.
References: https://bugs.freedesktop.org/show_bug.cgi?id=84524
Cc: Josh Triplett <josh.triplett@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Even if the fb is the same we should still check if the sizes are
valid to be set.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Move check inside intel_crtc_cursor_set_obj() to
intel_check_cursor_plane(), we only use it there so move them out to
make the merge of intel_crtc_cursor_set_obj() into
intel_check_cursor_plane() easier.
This is another step toward the atomic modesetting support and unification
of plane operations such pin/unpin of fb objects on i915.
v2: take Ville's comment: move crtc_{w,h} assignment a bit down in the
code
v3: take Ville's comment: kept only the restructuring changes, the rest of
the code was moved to a separated patch since it is a bug fix (we weren't
checking sizes when the fb was the same)
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
[danvet: Fixup commit message mixup.]
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that universal planes are in place we don't need this plane unref on
failures.
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fold intel_pipe_set_base() in the update primary plane path merging
pieces of code that are common to both paths.
Basically the the pin/unpin procedures are the same for both paths
and some checks can also be shared (some of the were moved to the
check() stage)
v2: take Ville's comments:
- remove unnecessary plane check
- move mutex lock to inside the conditional
- make the pin fail message a debug one
- add a fixme for the fastboot hack
- call intel_frontbuffer_flip() after FBC update
v3: take more Ville's comments:
- fold update code under if (intel_crtc->active), and do the
visible/!visible split inside.
- check ret inside the same conditional we assign it
v4: don't use intel_enable_primary_hw_plane(), the primary_enabled
check inside will break page flips
v5: take more Ville's comments:
- set primary_enabled to true and add BDW hack
- unify if (old_fb) and if (old_fb != fb)
v6: take more Ville's comments:
- make was_primary bool and fix its check
- add the BDW vblank wait comment
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As stated in the few previous commits, IS_ULT/ULX() is better
per-platform as it has different consequences depending on the platform.
We now can get rid of it.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
IS_ULT() wasn't taking into account SKL so we had a warn with SPT-LP.
We don't realy need those checks here, and as we don't need to introduce
IS_SKL_ULT/ULX() at the moment, let's just drop them.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
hsw_get_cdclk_freq() is really just HSW, so we can use IS_HSW_ULT()
instead of IS_ULT() there.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The quality of being a ULT or ULX package doesn't tell anything across
generations and so a global IS_ULT() macro doesn't make much sense, esp.
as we're adding new products.
So, spell out which ULT/ULX SKUs we are talking about here, namely HSW
and BDW.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
HAS_IPS() has a '|| IS_BROADWELL()', no need to check for IS_BDW_ULT().
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
No need to add the BDW pci ULT/ULX checks inside a if (IS_HASWELL(dev))
code path.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This simplifies the code in the vlv irq handler. Also this now
means that we correctly filter underruns on gen2-4.
And as the real upshot I need to document one less function for
the fifo underrun code.
v2: Shorten one long line.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Way too much copypasta all over. And this also clarifies a bit what's
going on since it separates the "do we have an underrun irq" from the
"should we report the underrun" check.
v2: Fix excessively long lines.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Prep work for some nice documentation. Requires that we export the
display irq enable/disable functions on ilk/ibx. But we already export
them for vlv/i915. So not more inconsistency.
v2: Rebase on top of skl stage 1.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Even after the recent fix, the assertion on paging_tmpl.h is triggered.
Apparently, the assertion wants to check that the PAE is always set on
long-mode, but does it in incorrect way. Note that the assertion is not
enabled unless the code is debugged by defining MMU_DEBUG.
Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The third parameter of kvm_unpin_pages() when called from
kvm_iommu_map_pages() is wrong, it should be the number of pages to un-pin
and not the page size.
This error was facilitated with an inconsistent API: kvm_pin_pages() takes
a size, but kvn_unpin_pages() takes a number of pages, so fix the problem
by matching the two.
This was introduced by commit 350b8bd ("kvm: iommu: fix the third parameter
of kvm_iommu_put_pages (CVE-2014-3601)"), which fixes the lack of
un-pinning for pages intended to be un-pinned (i.e. memory leak) but
unfortunately potentially aggravated the number of pages we un-pin that
should have stayed pinned. As far as I understand though, the same
practical mitigations apply.
This issue was found during review of Red Hat 6.6 patches to prepare
Ksplice rebootless updates.
Thanks to Vegard for his time on a late Friday evening to help me in
understanding this code.
Fixes: 350b8bd ("kvm: iommu: fix the third parameter of... (CVE-2014-3601)")
Cc: stable@vger.kernel.org
Signed-off-by: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Jamie Iles <jamie.iles@oracle.com>
Reviewed-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The decode phase of the x86 emulator assumes that every instruction with the
ModRM flag, and which can be used with RIP-relative addressing, has either
SrcMem or DstMem. This is not the case for several instructions - prefetch,
hint-nop and clflush.
Adding SrcMem|NoAccess for prefetch and hint-nop and SrcMem for clflush.
This fixes CVE-2014-8480.
Fixes: 41061cdb98
Cc: stable@vger.kernel.org
Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Currently, all group15 instructions are decoded as clflush (e.g., mfence,
xsave). In addition, the clflush instruction requires no prefix (66/f2/f3)
would exist. If prefix exists it may encode a different instruction (e.g.,
clflushopt).
Creating a group for clflush, and different group for each prefix.
This has been the case forever, but the next patch needs the cflush group
in order to fix a bug introduced in 3.17.
Fixes: 41061cdb98
Cc: stable@vger.kernel.org
Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
A failure to decode the instruction can cause a NULL pointer access.
This is fixed simply by moving the "done" label as close as possible
to the return.
This fixes CVE-2014-8481.
Reported-by: Andy Lutomirski <luto@amacapital.net>
Cc: stable@vger.kernel.org
Fixes: 41061cdb98
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
