use qemu-xen-unstable instead for solve a qemu crashes using spice
with qxl that I'm unable to find specific patch/es to backport

- Remove python prefix
- Add/remove/stop of main services (xencommons, xendomains)

NOTE:
This patch is only for do fast test build with make debball
and upstream qemu build with spice full features.

Signed-off-by: Fabio Fantoni <fabio.fantoni@m2r.biz>

---

Changes from v2:
- remove add of spice and usbredir on upstream qemu build

Changes from v1:
- Added: Add/remove/stop of main services

Usage:
hdtype=ide|ahci (default=ide)

If hdtype=ahci adds ich9 disk controller in ahci mode and uses it with
upstream qemu to emulate disks instead of ide.
It doesn't support cdroms which still using ide (cdroms will use
"-device ide-cd" as new qemu parameter)
Ahci requires new qemu parameter but for now other emulated disks cases
remains with old ones (I did it in other patch, not needed by this one)
I did it as libxl parameter disabled by default to avoid possible
problems:
- with save/restore/migration (restoring with ahci a domU that was with
ide instead)
- windows < 8 without pv drivers (a registry key change is needed for
AHCI<->IDE change FWIK to avoid possible blue screen)
- windows XP or older that many not support ahci by default.
Setting AHCI with libxl parameter and default to disabled seems the best
solution.
AHCI increase hvm domUs boot performance. On linux hvm domU I saw up to
only 20% of the previous total boot time, whereas boot time decrease a
lot on W7 domUs for most of boots I have done. Small difference in boot
time compared to ide mode on W8 and newer (probably other xen
improvements or fixes are needed not ahci related)

Signed-off-by: Fabio Fantoni <fabio.fantoni@m2r.biz>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- adjust name of LIBXL_HAVE #define as discussed on list,
         fixup pod syntax in xl.cfg.pod.5 ]

Usage:
vga="qxl"

Qxl vga support many resolutions that not supported by stdvga,
mainly the 16:9 ones and other high up to 2560x1600.
With QXL you can get improved performance and smooth video also
with high resolutions and high quality.
Require their drivers installed in the domU and spice used
otherwise act as a simple stdvga.

Signed-off-by: Fabio Fantoni <fabio.fantoni@m2r.biz>
Signed-off-by: Zhou Peng <zpengxen@gmail.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

Usage:
spice_streaming_video=[filter|all|off]

Specifies what streaming video setting is to be used by spice (if
given),
otherwise the qemu default will be used.

Signed-off-by: Fabio Fantoni <fabio.fantoni@m2r.biz>
Acked-by: Wei Liu <wei.liu2@citrix.com>

Usage:
spice_image_compression=[auto_glz|auto_lz|quic|glz|lz|off]

Specifies what image compression is to be used by spice (if given),
otherwise the qemu default will be used.

Signed-off-by: Fabio Fantoni <fabio.fantoni@m2r.biz>
Acked-by: Wei Liu <wei.liu2@citrix.com>

HVM guests have always been confined to using the domain callback
via (see HVM_PARAM_CALLBACK_IRQ) to receive event notifications.
This is usually an IOAPIC vector and is only used if the event
channel is bound to vcpu 0.

PVHVM Linux uses a pre-defined interrupt vector for the event
channel upcall, set using HVM_PARAM_CALLBACK_IRQ by ORing in a
special bit (bit 57) into the value (see params.h). However, it
does not assert the interrupt via the emulated local APIC.

This mechanism is not suitable in the general case since Windows
(and potentially other OSes) because they:

- cannot guarantee the same vector for all VCPUs
- do require the upcall to be asserted via the local APIC

This patch adds a new HVM op allowing a guest to specify a local
APIC vector to use as an upcall notification for a specific vcpu
therefore coping with the case of differing vector numbers.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

To perform certain hypercalls HVM guests need to use Xen's idea of
vcpu id, which may well not match the guest OS idea of CPU id.
This patch adds vcpu id to the HVM cpuid leaf allowing the guest
to build a mapping.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

Release memory allocated for scope.devices dmar units on various
failure paths and when disabling dmar. Set device count after
sucessfull memory allocation, not before, in device scope parsing function.

Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Yang Zhang <yang.z.zhang@intel.com>

# Commit 132231d
# Date 2015-07-16 15:23:37 +0200
# Author Andrew Cooper <andrew.cooper3@citrix.com>
# Committer Jan Beulich <jbeulich@suse.com>
dmar: fix double free in error paths following c/s a8bc99b

Several error paths would end up freeing scope->devices twice.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: a8bc99b
master date: 2015-07-16 11:50:07 +0200
master commit: 132231d
master date: 2015-07-16 15:23:37 +0200

find_range() returns NULL when s is below the lowest range, so we have
to use first_range() here (which is as good performance wise), or else
no range gets reported at all in that case.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
master commit: b1c780c
master date: 2015-07-15 16:11:42 +0200

AFAICT our current version does not correspond to any version in the
Linux history. This commit resynchronised to the state in Linux
commit 598bae70c2a8e35c8d39b610cca2b32afcf047af.

Differences from upstream: find_cpio_data is __init, printk instead of
pr_*.

This appears to fix Debian bug #785187. "Appears" because my test box
happens to be AMD and the issue is that the (valid) cpio generated by
the Intel ucode is not liked by the old Xen code. I've tested by
hacking the hypervisor to look for the Intel path.

Reported-by: Stephan Seitz <stse+debianbugs@fsing.rootsland.net>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Stephan Seitz <stse+debianbugs@fsing.rootsland.net>
Cc: 785187@bugs.debian.org
Acked-by: Jan Beulich <jbeulich@suse.com>
master commit: 39c6664
master date: 2015-07-07 15:10:45 +0100

The functions ring_read and ring_write() have logic to try and deal with
partial reads and writes.

However, in all cases where the "while (len)" loop executed twice, data
corruption would occur as the second memcpy() starts from the beginning of
"data" again, rather than from where it got to.

This bug manifested itself as protocol corruption when a reply header crossed
the first wrap of the response ring.  However, similar corruption would also
occur if hvmloader observed xenstored performing partial writes of the block
in question, or if hvmloader had to wait for xenstored to make space in either
ring.

Reported-by: Adam Kucia <djexit@o2.pl>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: bbbe7e7
master date: 2015-07-07 14:39:27 +0200

Ideally, the pCPUs that are 'free', i.e., not assigned
to any cpupool, should not be considred by the scheduler
for load balancing or anything. In Credit1, we fail at
this, because of how we use cpupool_scheduler_cpumask().
In fact, for a free pCPU, cpupool_scheduler_cpumask()
returns a pointer to cpupool_free_cpus, and hence, near
the top of csched_load_balance():

 if ( unlikely(!cpumask_test_cpu(cpu, online)) )
     goto out;

is false (the pCPU _is_ free!), and we therefore do not
jump to the end right away, as we should. This, causes
the following splat when resuming from ACPI S3 with
pCPUs not assigned to any pool:

(XEN) ----[ Xen-4.6-unstable  x86_64  debug=y  Tainted:    C ]----
(XEN) ... ... ...
(XEN) Xen call trace:
(XEN)    [<ffff82d080122eaa>] csched_load_balance+0x213/0x794
(XEN)    [<ffff82d08012374c>] csched_schedule+0x321/0x452
(XEN)    [<ffff82d08012c85e>] schedule+0x12a/0x63c
(XEN)    [<ffff82d08012fa09>] __do_softirq+0x82/0x8d
(XEN)    [<ffff82d08012fa61>] do_softirq+0x13/0x15
(XEN)    [<ffff82d080164780>] idle_loop+0x5b/0x6b
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 8:
(XEN) GENERAL PROTECTION FAULT
(XEN) [error_code=0000]
(XEN) ****************************************

The cure is:
 * use cpupool_online_cpumask(), as a better guard to the
   case when the cpu is being offlined;
 * explicitly check whether the cpu is free.

SEDF is in a similar situation, so fix it too.

Still in Credit1, we must make sure that free (or offline)
CPUs are not considered "ticklable". Not doing so would impair
the load balancing algorithm, making the scheduler think that
it is possible to 'ask' the pCPU to pick up some work, while
in reallity, that will never happen! Evidence of such behavior
is shown in this trace:

 Name               CPU list
 Pool-0             0,1,2,3,4,5,6,7,8,9,10,11,12,13,14

    0.112998198 | ||.|| -|x||-|- d0v0 runstate_change d0v4 offline->runnable
 ]  0.112998198 | ||.|| -|x||-|- d0v0   22006(2:2:6) 1 [ f ]
 ]  0.112999612 | ||.|| -|x||-|- d0v0   28004(2:8:4) 2 [ 0 4 ]
    0.113003387 | ||.|| -||||-|x d32767v15 runstate_continue d32767v15 running->running

where "22006(2:2:6) 1 [ f ]" means that pCPU 15, which is
free from any pool, is tickled.

The cure, in this case, is to filter out the free pCPUs,
within __runq_tickle().

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Juergen Gross <jgross@suse.com>
Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>
master commit: 02ea503
master date: 2015-07-07 14:30:06 +0200

In fact, when a pCPU goes down, we want to clear its
bit in the correct cpupool's valid mask, rather than
always in cpupool0's one.

Before this commit, all the pCPUs in the non-default
pool(s) will be considered immediately valid, during
system resume, even the one that have not been brought
up yet. As a result, the (Credit1) scheduler will attempt
to run its load balancing logic on them, causing the
following Oops:

# xl cpupool-cpu-remove Pool-0 8-15
# xl cpupool-create name=\"Pool-1\"
# xl cpupool-cpu-add Pool-1 8-15
--> suspend
--> resume
(XEN) ----[ Xen-4.6-unstable  x86_64  debug=y  Tainted:    C ]----
(XEN) CPU:    8
(XEN) RIP:    e008:[<ffff82d080123078>] csched_schedule+0x4be/0xb97
(XEN) RFLAGS: 0000000000010087   CONTEXT: hypervisor
(XEN) rax: 80007d2f7fccb780   rbx: 0000000000000009   rcx: 0000000000000000
(XEN) rdx: ffff82d08031ed40   rsi: ffff82d080334980   rdi: 0000000000000000
(XEN) rbp: ffff83010000fe20   rsp: ffff83010000fd40   r8:  0000000000000004
(XEN) r9:  0000ffff0000ffff   r10: 00ff00ff00ff00ff   r11: 0f0f0f0f0f0f0f0f
(XEN) r12: ffff8303191ea870   r13: ffff8303226aadf0   r14: 0000000000000009
(XEN) r15: 0000000000000008   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 00000000dba9d000   cr2: 0000000000000000
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) ... ... ...
(XEN) Xen call trace:
(XEN)    [<ffff82d080123078>] csched_schedule+0x4be/0xb97
(XEN)    [<ffff82d08012c732>] schedule+0x12a/0x63c
(XEN)    [<ffff82d08012f8c8>] __do_softirq+0x82/0x8d
(XEN)    [<ffff82d08012f920>] do_softirq+0x13/0x15
(XEN)    [<ffff82d080164791>] idle_loop+0x5b/0x6b
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 8:
(XEN) GENERAL PROTECTION FAULT
(XEN) [error_code=0000]
(XEN) ****************************************

The reason why the error is a #GP fault is that, without
this commit, we try to access the per-cpu area of a not
yet allocated and initialized pCPU.
In fact, %rax, which is what is used as pointer, is
80007d2f7fccb780, and we also have this:

#define INVALID_PERCPU_AREA (0x8000000000000000L - (long)__per_cpu_start)

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Juergen Gross <jgross@suse.com>
master commit: 8022b05
master date: 2015-07-07 14:29:39 +0200

The call to iommu_pte_flush() between the two hunks uses &ept_entry->epte
which is a pointer into the mapped page.

It is eventually passed to `clflush` instruction which will suffer a pagefault
if the virtual mapping has fallen out of the TLB.

    (XEN) ----[ Xen-4.5.0-xs102594-d  x86_64  debug=y  Not tainted ]----
    (XEN) CPU:    7
    (XEN) RIP:    e008:[<ffff82d0801572f0>] cacheline_flush+0x4/0x9
    <snip>
    (XEN) Xen call trace:
    (XEN)    [<ffff82d0801572f0>] cacheline_flush+0x4/0x9
    (XEN)    [<ffff82d08014ffff>] __iommu_flush_cache+0x4a/0x6a
    (XEN)    [<ffff82d0801532e2>] iommu_pte_flush+0x2b/0xd5
    (XEN)    [<ffff82d0801f909a>] ept_set_entry+0x4bc/0x61f
    (XEN)    [<ffff82d0801f0c25>] p2m_set_entry+0xd1/0x112
    (XEN)    [<ffff82d0801f25b1>] clear_mmio_p2m_entry+0x1a0/0x200
    (XEN)    [<ffff82d0801f4aac>] unmap_mmio_regions+0x49/0x73
    (XEN)    [<ffff82d080106292>] do_domctl+0x15bd/0x1edb
    (XEN)    [<ffff82d080234fcb>] syscall_enter+0xeb/0x145
    (XEN)
    (XEN) Pagetable walk from ffff820040004ae0:
    (XEN)  L4[0x104] = 00000008668a5063 ffffffffffffffff
    (XEN)  L3[0x001] = 00000008668a3063 ffffffffffffffff
    (XEN)  L2[0x000] = 000000086689c063 ffffffffffffffff
    (XEN)  L1[0x004] = 000000056f078063 000000000007f678
    (XEN)
    (XEN) ****************************************
    (XEN) Panic on CPU 7:
    (XEN) FATAL PAGE FAULT
    (XEN) [error_code=0000]
    (XEN) Faulting linear address: ffff820040004ae0
    (XEN) ****************************************

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: e4e9d2d
master date: 2015-07-07 11:37:26 +0200

If the host EPT entry is changed, the nested EPT should be updated.
the current code does not do this, and it's wrong.
I have tested this patch, the L2 guest can boot and run as normal.

Signed-off-by: Liang Li <liang.z.li@intel.com>
Signed-off-by: Yang Zhang <yang.z.zhang@intel.com>
Reported-by: Tim Deegan <tim@xen.org>
Reviewed-by: Tim Deegan <tim@xen.org>
master commit: 71bb730
master date: 2015-06-30 15:00:54 +0100

Early on boot, current has the sentinel value 0xfffff000.  Blindly using it in
show_registers() causes a nested failure and no useful information printed
from an early crash.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 142473c
master date: 2015-06-25 14:57:04 +0200

Constructing dom0 may take a few seconds, particularly if the slow VESA
graphics terminal is used. Process pending softirqs a few times to avoid
tripping a watchdog with a short timeout.

Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>

Move inclusion of xen/softirq.h (and at once clean up other includes).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
master commit: c5089fa
master date: 2015-06-12 12:07:05 +0200

That flag now means cachability rather than protection, and a new flag
EFI_MEMORY_RO got added in its place.

Along with EFI_MEMORY_RO also add the two other new EFI_MEMORY_*
definitions, even if we don't need them right away.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
master commit: 860313f
master date: 2015-06-10 12:05:21 +0200

Destination pages need mappings to be added to the page tables in the
v1 case (where nothing else calls machine_kexec_add_page() for them).

Further, without the tools mapping the low 1Mb (expected by at least
some Linux version), we need to do so in the hypervisor in the v1 case.

Suggested-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Alan Robinson <alan.robinson@ts.fujitsu.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 5cb57f4
master date: 2015-06-09 16:00:24 +0200

Using gdbsx on Broadwell systems suffers a SMAP violation because
dbg_rw_guest_mem() uses memcpy() with a userspace pointer.

The functions dbg_rw_mem() and dbg_rw_guest_mem() have been updated to pass
'void * __user' pointers which indicates their nature clearly.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 229492e
master date: 2015-06-03 09:27:09 +0200

update_intremap_entry_from_msi() doesn't write to its data pointer on
some error paths, so we copying that variable into the msg would count
as undefined behaviour.

Signed-off-by: Tim Deegan <tim@xen.org>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
master commit: a8ccf2d
master date: 2015-04-24 12:04:57 +0200

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: e59abf8
master date: 2015-04-14 14:59:53 +0200

We are about to release 4.5.1.  And, we want to not have to patch
README each time.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

trying to shutdown the host when a cpupool exists, has
pCPUs, and has a scheduler different than the Xen's default
one, produces this:

 root@Zhaman:~# xl cpupool-cpu-remove Pool-0 8
 root@Zhaman:~# xl cpupool-create name=\"Pool-1\" sched=\"credit2\"
 Using config file "command line"
 cpupool name:   Pool-1
 scheduler:      credit2
 number of cpus: 0
 root@Zhaman:~# xl cpupool-cpu-add Pool-1 8
 root@Zhaman:~# shutdown -h now

 (XEN) ----[ Xen-4.6-unstable  x86_64  debug=y  Not tainted ]----
 (XEN) CPU:    0
 (XEN) RIP:    e008:[<ffff82d080133bdf>] kill_timer+0x56/0x298
 (XEN) RFLAGS: 0000000000010002   CONTEXT: hypervisor
  ... ... ...
 (XEN) Xen call trace:
 (XEN)    [<ffff82d080133bdf>] kill_timer+0x56/0x298
 (XEN)    [<ffff82d08012233f>] csched_free_pdata+0x9b/0xcf
 (XEN)    [<ffff82d08012c30c>] cpu_schedule_callback+0x64/0x8b
 (XEN)    [<ffff82d08011bc7a>] notifier_call_chain+0x67/0x87
 (XEN)    [<ffff82d08010153e>] cpu_down+0xd9/0x12c
 (XEN)    [<ffff82d080101744>] disable_nonboot_cpus+0x93/0x138
 (XEN)    [<ffff82d0801aa6e7>] enter_state_helper+0xbd/0x365
 (XEN)    [<ffff82d0801061e5>] continue_hypercall_tasklet_handler+0x4a/0xb1
 (XEN)    [<ffff82d080132387>] do_tasklet_work+0x78/0xab
 (XEN)    [<ffff82d0801326bd>] do_tasklet+0x5e/0x8a
 (XEN)    [<ffff82d0801646d2>] idle_loop+0x56/0x6b
  ... ... ...
 (XEN) ****************************************
 (XEN) Panic on CPU 0:
 (XEN) FATAL PAGE FAULT
 (XEN) [error_code=0000]
 (XEN) Faulting linear address: 0000000000000041
 (XEN) ****************************************

The fix is, when tearing down a pCPU, call the free_pdata()
hook from the scheduler of the cpupool the pCPU belongs to,
not always the one from the default scheduler.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
master commit: 98c51d0
master date: 2015-06-12 12:06:24 +0200

elf_parse_bsdsyms expects the second paramater to be a physical address, not
a virtual one.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
master commit: 90b18f1
master date: 2015-06-12 12:05:54 +0200

We're being told that while on the server side the issue we're trying
to work around is fixed starting with IvyBridge (another round of
double checking is going on before we're going to remove the one
IvyBridge ID that we're currently applying the workaround for), on the
desktop side even Skylake still requires the workaround. Hence we need
to add a whole bunch of desktop IDs.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Don Dugger <donald.d.dugger@intel.com>
master commit: cdc6204
master date: 2015-06-11 11:55:05 +0200

…e given

From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

For example on Dell machines we see:

(XEN)  00000fed18000-00000fed19fff type=11 attr=8000000000000000
(XEN) Unknown cachability for MFNs 0xfed18-0xfed19

Let's allow them to be mapped as UC.

We also alter the 'efi-rs' to be 'efi=rs' or 'efi=no-rs'.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
master commit: 74cdad5
master date: 2015-06-10 12:04:07 +0200

From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

To help on certain platforms to run.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
master commit: f36886b
master date: 2015-06-10 12:02:43 +0200

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

Backport: Also fix EFI_MEMORY_XP handling (along the lines of what
master commit abcf15f ["x86: switch default mapping attributes
to non-executable"] does): We must not set the NX bit when the CPU
doesn't support it, as the bit being set may trigger Reserved Bit
faults in that case.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
master commit: af23e79
master date: 2015-06-10 12:01:35 +0200

After the first call to ExitBootServices(), avoid calling any boot
services (except GetMemoryMap() and ExitBootServices()) by setting
setting efi_bs to NULL and halting in blexit(). Only GetMemoryMap() and
ExitBootServices() are explicitly allowed to be called after the first
call to ExitBootServices() and so are are called via
SystemTable->BootServices.

Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
master commit: d4300db
master date: 2015-06-10 12:00:10 +0200