Unsupported Requests can be signaled for malformed writes to the MSI
address region, e.g. due to buggy or malicious DMA set up to that
region. These should normally result in IOMMU faults, but don't on
the desktop chipsets dealt with here.
This is CVE-2013-3495 / XSA-59.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Don Dugger <donald.d.dugger@intel.com>
Acked-by: Tim Deegan <tim@xen.org>
Acked-by: Xiantao Zhang <xiantao.zhang@intel.com>
master commit: d6cb14b34f
master date: 2014-04-25 12:12:38 +0200
Unsupported Requests can be signaled for malformed writes to the MSI
address region, e.g. due to buggy or malicious DMA set up to that
region. These should normally result in IOMMU faults, but don't on
the server chipsets dealt with here.
IDs 0xe00, 0xe01, and 0xe04 ... 0xe0b (Ivytown) aren't needed here -
Intel confirmed the issue to be fixed in hardware there.
This is CVE-2013-3495 / XSA-59.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Don Dugger <donald.d.dugger@intel.com>
Acked-by: Tim Deegan <tim@xen.org>
Acked-by: Xiantao Zhang <xiantao.zhang@intel.com>
master commit: d061d200eb
master date: 2014-04-25 12:11:55 +0200
p2m_set_entry() can fail without there being a bug in the code - crash
the domain rather than the host in that case.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
master commit: 1ca73aaf51
master date: 2014-04-14 12:50:56 +0200
CNTKCTL_EL1 is used by the guest to control access to the timer from
userspace. It therefore needs to be save/restored by Xen as part of
the VCPU state.
By default Linux on ARM64 exposes the timer to userspace. Furthermore on
ARM64, Linux provides helpers in a VDSO (gettimeofday/__do_get_tspec)
that use the timer counter. Conversely, during CPU bring up, Xen will
set CNTKCTL_EL1 to 0 (i.e disallow timer access to the userspace). As
a result, currently, if dom0 has 1 VCPU which is migrated to another
PCPU, init might crash.
Alternatively, a guest (malicious or not) might decide to disable
access to the timer from userspace. If the register is not
save/restored, when a DOM0 VCPU runs again, a similar crash would
result.
Also, drop CNTKCTL_EL1 initialization in init_timer_interrupt. Xen
should let the guest deal with this register.
This is XSA-91 / CVE-2014-3125.
Reported-by: Chen Baozi <baozich@gmail.com>
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Permitting arbitrary type changes here has the potential of creating
present P2M (and hence EPT/NPT/IOMMU) entries pointing to an invalid
MFN (INVALID_MFN truncated to the respective hardware structure field's
width). This would become a problem the latest when something real sat
at the end of the physical address space; I'm suspecting though that
other things might break with such bogus entries.
Along with that drop a bogus (and otherwise becoming stale) log
message.
Afaict the similar operation in p2m_set_mem_access() is safe.
This is XSA-92.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
master commit: 83bb5eb4d3
master date: 2014-04-29 15:11:31 +0200
On arm64, VFP instructions requires vfpregs to be 128-byte aligned.
By chance, the field is already correctly aligned. In the case if someone
decides to add a new field before, Xen will receive a data abort as soon as
it saves/restores VFP.
We are safe on arm32 as the only constraint is to be 32-byte aligned.
Reported-by: Chen Baozi <baozich@gmail.com>
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
(cherry picked from commit 9b4e96724e)
early printk on ARM is tied to debug being enabled, so error out instead of silently and unexpectedly building without early printk when asked.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
(cherry picked from commit 5940d3d095)
The allocations for shared_irqs and pending_irqs are not checked and use
later. This may lead to a Xen segfault if the hypervisor run out of memory.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
(cherry picked from commit a34f6affe7)
The function vgic_irq_rank may return NULL is the IRQ is not in range handled
by the guest. This will result to derefence a NULL pointer which will crash
Xen.
I've checked the rest of the emulation and this is only place where the lock
is taken before the rank is checked.
This is CVE-2014-2986 / XSA-94.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Reported-by: Thomas Leonard <talex5@gmail.com>
Reviewed-by: Jan Beulich <JBeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Quoting Andi Kleen in Linux b483570a13be from 2007:
gcc 3.2+ supports __builtin_prefetch, so it's possible to use it on all
architectures. Change the generic fallback in linux/prefetch.h to use it
instead of noping it out. gcc should do the right thing when the
architecture doesn't support prefetching
Undefine the x86-64 inline assembler version and use the fallback.
ARM wants to use the builtins.
Fix a pair of spelling errors, one of which was from Lucas De Marchi in the
Linux tree.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Acked-by: Tim Deegan <tim@xen.org>
master commit: 630017f420
master date: 2014-04-03 17:15:41 +0100
This value is an inclusive one, i.e. this fixes an off-by-one in memory
sharing and an off-by-two in shadow code.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
master commit: 088ee1d47b
master date: 2014-04-03 12:08:43 +0100
Debug and performance registers are not properly switched by Xen.
Trap them and inject an undefined instruction, except for those registers
which might be unconditionally accessed which we implement as RAZ/WI.
This is CVE-2014-2915 / XSA-93.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
On Cortex-A15, CP15 c15 contains registers to retrieve data from L1/L2 RAM.
Exposing this registers to guest may result to leak data from Xen and/or
another guest.
By default trap every registers and inject an undefined instruction.
This is CVE-2014-2915 / XSA-93.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Some cp15 c9/c10/c11 encodings are used for:
- cache control
- TCM control
- branch predictor control
All of them are implementation defined. For now inject an undefined exception
if the guest wants try to access it.
This is CVE-2014-2915 / XSA-93.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
A guest is allowed to use invalidate cache by set/way instruction (i.e DCISW)
without any restriction. As the cache is shared with Xen, the guest invalidate
an address being in used by Xen. This may lead a Xen crash because the memory
state is invalid.
Set the bit HCR.SWIO to upgrade invalidate cache by set/way instruction to an
invalidate and clean.
This is CVE-2014-2915 / XSA-93.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Reported-by: Thomas Leonard <tal36@cam.ac.uk>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
In Xen we only handle save/restore for coprocessor 10 and 11 (NEON). Other
coprocessors (0-9, 12-13) are currently exposed to the guest and may lead
to data shared between guest.
Disable access to all coprocessor except 10 and 11 by setting correctly
HCTPR.
This is CVE-2014-2915 / XSA-93.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Currently Xen panics if it's unable to handle a coprocessor/sysreg instruction.
Replace this behavior by inject an undefined instruction to the faulty guest
and log if Xen is in debug mode.
This is CVE-2014-2915 / XSA-93.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
GRUB usually always loads a whole disk track, even if that means going
beyond the end of the disk. We thus have to gracefully return an error,
instead of letting the blkfront go panic.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
(cherry picked from commit 51e18e41e3)
menuentry in grub2/grub.cfg uses linux16 and initrd16 commands
instead of linux and initrd. Due to this RHEL 7 (beta) guest failed to
boot after the installation.
In addition to this, RHEL 7 menu entries have two different single-quote
delimited strings on the same line, and the greedy grouping for menuentry
parsing gets both strings, and the options inbetween.
Signed-off-by: Joby Poriyath <joby.poriyath@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: george.dunlap@citrix.com
(cherry picked from commit dd03048708)
Otherwise we deference a NULL pointer.
I saw this while experimenting with libvirt on Xen on ARM, xl already checks
that the command line is non NULL and provides "" as a default.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
Cc: george.dunlap@citrix.com>
(cherry picked from commit 3647a486ec)
Update to versions from Debian Wheezy's autotools-dev package (20120608.1)
Adds ARM aarch64 support.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
(cherry picked from commit 0c68ddf308)
If libxl_pipe fails we leave the carefd locked, which translates to
the atfork lock remaining held. This would probably cause the process
to deadlock shortly afterwards.
Of course libxl_pipe is very unlikely to fail unless things are
already going very badly. This bug has not been observed anywhere as
far as we are aware.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
CC: George Dunlap <george.dunlap@eu.citrix.com>
(cherry picked from commit 7eb73add5d)
This avoids the process being forked while a carefd is recorded in the
list but the actual fd has been closed. If that happened, a
subsequent libxl_postfork_child_noexec would attempt to close the fd
again. If we are lucky that results in a harmless warning; but if we
are unlucky the fd number has been reused and we close an unrelated
fd.
This race has not been observed anywhere as far as we are aware.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
CC: George Dunlap <george.dunlap@eu.citrix.com>
(cherry picked from commit 2a0c3a62ea)
The XSA-60 fixes introduced a window during which the guest PAT gets
forced to all zeros. This shouldn't be visible to the guest. Therefore
we need to intercept PAT MSR accesses during that time period.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Liu Jinsong <jinsong.liu@intel.com>
master commit: fce79f8ce9
master date: 2014-04-01 16:49:18 +0200
...otherwise if kimage_alloc_control_page fails (presumably due to
out-of-memory; see the invocation just before this one), the caller of
do_kimage_alloc will think the call was successful.
Signed-off-by: Matthew Daley <mattd@bugfuzz.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
master commit: 66c6349265
master date: 2014-04-01 16:48:02 +0200
There's no point in this being mapped UC by the guest due to using a
respective PAT index - set the ignore-PAT flag to true.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
master commit: 1f8b577797
master date: 2014-03-28 13:43:25 +0100
CPUID[80000008].EAX[23:16] have been given the meaning of the guest
physical address restriction (in case it needs to be smaller than the
host's), hence we need to mirror that into vCPUID[80000008].EAX[7:0].
Enforce a lower limit at the same time, as well as a fixed value for
the virtual address bits, and zero for the guest physical address ones.
In order for the vMTRR code to see these overrides we need to make it
call hvm_cpuid() instead of domain_cpuid(), which in turn requires
special casing (and relaxing) the controlling domain.
This additionally should hide an ordering problem in the tools: Both
xend and xl appear to be restoring a guest from its image before
setting up the CPUID policy in the hypervisor, resulting in
domain_cpuid() returning all zeros and hence the check in
mtrr_var_range_msr_set() failing if the guest previously had more than
the minimum 36 physical address bits.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
master commit: ef437690af
master date: 2014-03-28 13:33:34 +0100
We can't just add in the hole shift value, as the hole may be at or
above the 44-bit boundary. Instead we need to determine the total bit
count until reaching 32 significant (not squashed out) bits in PFN
representations.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: b3d2f8b2cb
master date: 2014-03-24 10:48:03 +0100
Linux commit 40e2d7f9b5dae048789c64672bf3027fbb663ffa ("x86 idle:
Repair large-server 50-watt idle-power regression") tells us that this
applies not just to the named Xeon 7400 series, but also NHM-EX and
WSM-EX; sadly Intel's documentation is so badly searchable that I
wasn't able to locate the respective errata (and hence can't quote
their numbers here).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
master commit: 96d1b237ae
master date: 2014-03-17 16:47:22 +0100
Removing mapped RMRR tracking structures in dma_pte_clear_one() is
wrong for two reasons: First, these regions may cover more than a
single page. And second, multiple devices (and hence multiple devices
assigned to any particular guest) may share a single RMRR (whether
assigning such devices to distinct guests is a safe thing to do is
another question).
Therefore move the removal of the tracking structures into the
counterpart function to the one doing the insertion -
intel_iommu_remove_device(), and add a reference count to the tracking
structure.
Further, for the handling of the mappings of the respective memory
regions to be correct, RMRRs must not overlap. Add a respective check
to acpi_parse_one_rmrr().
And finally, with all of this being VT-d specific, move the cleanup
of the list as well as the structure type definition where it belongs -
in VT-d specific rather than IOMMU generic code.
Note that this doesn't address yet another issue associated with RMRR
handling: The purpose of the RMRRs as well as the way the respective
IOMMU page table mappings get inserted both suggest that these regions
would need to be marked E820_RESERVED in all (HVM?) guests' memory
maps, yet nothing like this is being done in hvmloader. (For PV guests
this would also seem to be necessary, but may conflict with PV guests
possibly assuming there to be just a single E820 entry representing all
of its RAM.)
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Xiantao Zhang <xiantao.zhang@intel.com>
master commit: dd52706177
master date: 2014-03-17 16:45:04 +0100
- never preempt on the first iteration (ensure forward progress)
- never preempt on the last iteration (pointless/wasteful)
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Acked-by: Keir Fraser <keir@xen.org>
master commit: fd7bfce039
master date: 2014-03-13 14:27:51 +0100
- never preempt on the first iteration (ensure forward progress)
- do cheap checks first
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Acked-by: Keir Fraser <keir@xen.org>
master commit: 8c0eed2cc8
master date: 2014-03-13 14:26:35 +0100
A call to do_physdev_op with PHYSDEVOP_pirq_eoi_gmfn_v2/v1 will corrupt
struct hvm_domain when it writes to domain->arch.pv_domain.pirq_eoi_map.
Disallow that. Currently, such a path exists for linux dom0 pvh.
Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
master commit: a7ca5c402e
master date: 2014-03-24 09:47:59 +0100
Just like hvm, pirq eoi shared page is not there for pvh. pvh should
not touch any pv_domain fields.
Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
master commit: bea8ee1a5f
master date: 2014-03-13 14:24:19 +0100
During halt of a pvh guest, the guest may do speaker shutdown. This
results in call to handle_speaker_io in xen. It will hang on the vpit
spin lock because it has not been initialized.
Since, pit_init is also called for both pv and hvm, the call is
moved to a more generic place.
Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: c30c544b19
master date: 2014-03-11 13:56:50 +0100
Processing up to 4G PFNs may take almost arbitrarily long, so
preemption is needed here.
This is CVE-2014-2599 / XSA-89.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
master commit: 0fe53c4f27
master date: 2014-03-25 15:23:57 +0100
When align is superior to size, we need to retrieve the order from
align during multiple page allocation. I guess it was the goal of the commit
fb034f42 "xmalloc: make close-to-PAGE_SIZE allocations more efficient".
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Keir Fraser <keir@xen.org>
master commit: ac2cba2901
master date: 2014-03-10 14:40:50 +0100
A patch to this effect has been in XenServer for a little while, and has
proved to be a useful debugging point for servers which have different
behaviours depending when crashing on the non-bootstrap processor.
Moving the printk() from kexec_panic() to one_cpu_only() means that it will
only be printed for the cpu which wins the race along the kexec path.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: David Vrabel <david.vrabel@citrix.com>
master commit: 4509ada6ba
master date: 2014-03-10 11:11:28 +0100
It is inconsistent to depend on iommu_enabled alone: For a guest
without devices passed through to it, it is of no concern whether the
IOMMU is enabled.
There's one rather special case to take care of: VMX code marks the
LAPIC access page as MMIO. The added assertion needs to take this into
consideration, and the subsequent handling of the direct MMIO case was
inconsistent too: That page would have been WB in the absence of an
IOMMU, but UC in the presence of it, while in fact the cachabilty of
this page is entirely unrelated to an IOMMU being in use.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: "Xu, Dongxiao" <dongxiao.xu@intel.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: 3089a6d82b
master date: 2014-03-10 11:04:36 +0100
Using the minimum numeric value of guest and host specified memory
types is too simplistic - it works only correctly for a subset of
types. It is in particular the WT/WP combination that needs conversion
to UC if the two types conflict.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: "Xu, Dongxiao" <dongxiao.xu@intel.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: b99113b9d5
master date: 2014-03-10 11:03:53 +0100
When trying to get the EPT EMT type, the judgment on
HVM_PARAM_IDENT_PT is not correct which always returns WB type if
the parameter is not set. Remove the related code.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
We can't fully drop the dependency yet, but we should certainly avoid
overriding cases already properly handled. The reason for this is that
the guest setting up its MTRRs happens _after_ the EPT tables got
already constructed, and no code is in place to propagate this to the
EPT code. Without this check we're forcing the guest to run with all of
its memory uncachable until something happens to re-write every single
EPT entry. But of course this has to be just a temporary solution.
In the same spirit we should defer the "very early" (when the guest is
still being constructed and has no vCPU yet) override to the last
possible point.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: "Xu, Dongxiao" <dongxiao.xu@intel.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: cadfd7bca9
master date: 2014-03-10 11:02:25 +0100
c/s 21039:95f5a4ce8f24 ("VT-d: reduce default verbosity") having put a
call to process_pending_softirqs() in VT-d's domain_context_mapping()
was wrong in two ways: For one we shouldn't be doing this when setting
up a device during DomU assignment. And then - I didn't check whether
that was the case already back then - we shouldn't call that function
with the pcidevs_lock (or in fact any spin lock) held.
Move the "preemption" into generic code, at once dealing with further
actual (too much output elsewhere - particularly on systems with very
many host bridge like devices - having been observed to still cause the
watchdog to trigger when enabled) and potential (other IOMMU code may
also end up being too verbose) issues.
Do the "preemption" once per device actually being set up when in
verbose mode, and once per bus otherwise.
Note that dropping pcidevs_lock around the process_pending_softirqs()
invocation is specifically not a problem here: We're in an __init
function and aren't racing with potential additions/removals of PCI
devices. Not acquiring the lock in setup_dom0_pci_devices() otoh is not
an option, as there are too many places that assert the lock being
held.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Xiantao Zhang <xiantao.zhang@intel.com>
master commit: 9ef5aa944a
master date: 2014-03-04 10:52:20 +0100
When booting with "no-mce", the user does not need to be told that "MCE
support [was] disabled by bootparam" for each cpu. Furthermore, a file:line
reference is unnecessary.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: a5ab9c9fa2
master date: 2014-02-25 09:30:59 +0100
The check in question is redundant with the one in the immediately
following if(), where dividing by zero gets carefully avoided.
Spotted-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
master commit: 5d160d913e
master date: 2014-02-24 12:11:01 +0100
Since SVM and VMX use different mechanism to emulate the virtual-vmentry
and virtual-vmexit, it's hard to update the nested paging mode correctly in
common code. So we need to update the nested paging mode in their respective
code path.
SVM already updates the nested paging mode on vmexit. This patch adds the same
logic in VMX side.
Previous discussion is here:
http://lists.xen.org/archives/html/xen-devel/2013-12/msg01759.html
Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
Reviewed-by: Christoph Egger <chegger@amazon.de>
master commit: fd1864f48d
master date: 2014-02-24 12:09:52 +0100
These lines (in mctelem_reserve)
newhead = oldhead->mcte_next;
if (cmpxchgptr(freelp, oldhead, newhead) == oldhead) {
are racy. After you read the newhead pointer it can happen that another
flow (thread or recursive invocation) change all the list but set head
with same value. So oldhead is the same as *freelp but you are setting
a new head that could point to whatever element (even already used).
This patch use instead a bit array and atomic bit operations.
Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
Reviewed-by: Liu Jinsong <jinsong.liu@intel.com>
master commit: 60ea3a3ac3
master date: 2014-02-24 12:07:41 +0100
Jan Beulich
Julien Grall
Ian Campbell
Samuel Thibault
Joby Poriyath
Ian Jackson
Matthew Daley
Mukesh Rathor
Andrew Cooper
Dongxiao Xu
Yang Zhang
Frediano Ziglio