x86: don't pass negative time to gtime_to_gtsc()

scale_delta(), which is being called by that function, doesn't cope
with that.

Also print a warning message, so hopefully we can eventually figure why
occasionally a negative value results from the calculation in the first
place.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: eb60be3dd870aecfa47bed1118069680389c15f7
master date: 2013-04-11 12:07:55 +0200
iommu/crash: Interrupt remapping is also disabled on crash

This fixes a regression side-effect caused by:
  IOMMU: properly check whether interrupt remapping is enabled
    git: fae0372140befb88d890a30704a8ec058c902af8
     hg: 26742:e1ec14bad0cb

On the crash path in nmi_shootdown_cpus(), we shut down the IOMMU, then
disable the IOAPIC.

On systems which support interrupt remapping, the variable iommu_intremap
remains set, meaning that disable_IO_APIC() issues interrupt remapping
invalidate requests.

IOAPIC interrupt remapping used to be conditional on iommu_enabled, but is now
conditional on iommu_intremap, following the above changeset.

This behaviour can be fixed by also indicating that interrupt remapping is not
enabled after shutting down the IOMMU.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 53fd1d8458de01169dfb56feb315f02c2b521a86
master date: 2013-04-16 10:34:32 +0200
x86: clear EFLAGS.NT in SYSENTER entry path

... as it causes problems if we happen to exit back via IRET: In the
course of trying to handle the fault, the hypervisor creates a stack
frame by hand, and uses PUSHFQ to set the respective EFLAGS field, but
expects to be able to IRET through that stack frame to the second
portion of the fixup code (which causes a #GP due to the stored EFLAGS
having NT set).

And even if this worked (e.g if we cleared NT in that path), it would
then (through the fail safe callback) cause a #GP in the guest with the
SYSENTER handler's first instruction as the source, which in turn would
allow guest user mode code to crash the guest kernel.

Inject a #GP on the fake (NULL) address of the SYSENTER instruction
instead, just like in the case where the guest kernel didn't register
a corresponding entry point.

This is CVE-2013-1917 / XSA-44.

Reported-by: Andrew Cooper <andrew.cooper3@citirx.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: fdac9515607b757c044e7ef0d61b1453ef999b08
master date: 2013-04-18 16:00:35 +0200
x86: fix various issues with handling guest IRQs

- properly revoke IRQ access in map_domain_pirq() error path
- don't permit replacing an in use IRQ
- don't accept inputs in the GSI range for MAP_PIRQ_TYPE_MSI
- track IRQ access permission in host IRQ terms, not guest IRQ ones
  (and with that, also disallow Dom0 access to IRQ0)

This is CVE-2013-1919 / XSA-46.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
master commit: 545607eb3cfeb2abf5742d1bb869734f317fcfe5
master date: 2013-04-18 16:11:23 +0200
libxl: Fix SEGV in network-attach

When "device/vif" directory exists but is empty l!=NULL, but nb==0, so
l[nb-1] is invalid.  Add missing check.

Signed-off-by: Marek Marczykowski <marmarek@invisiblethingslab.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
update Xen version to 4.2.2
update Xen version to 4.2.3-pre
x86/S3: Fix cpu pool scheduling after suspend/resume

This review is another S3 scheduler problem with the system_state
variable introduced with the following changeset:
http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=269f543ea750ed567d18f2e819e5d5ce58eda5c5

Specifically, the cpu_callback function that takes the CPU down during
suspend, and back up during resume. We were seeing situations where,
after S3, only CPU0 was in cpupool0. Guest performance suffered
greatly, since all vcpus were only on a single pcpu. Guests under high
CPU load showed the problem much more quickly than an idle guest.

Removing this if condition forces the CPUs to go through the expected
online/offline state, and be properly scheduled after S3.

This also includes a necessary partial change proposed earlier by
Tomasz Wroblewski here:
http://lists.xen.org/archives/html/xen-devel/2013-01/msg02206.html

It should also resolve the issues discussed in this thread:
http://lists.xen.org/archives/html/xen-devel/2012-11/msg01801.html

Signed-off-by: Ben Guthro <benjamin.guthro@citrix.com>
Acked-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
master commit: 9aa356bc9f7533c3cb7f02c823f532532876d444
master date: 2013-04-19 12:29:01 +0200
x86/EFI: fix runtime call status for compat mode Dom0

The top two bits (indicating error/warning classification) need to
remain the top two bits.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: a7ac9597a7fc6ca934957eb78b41e26638281953
master date: 2013-04-29 11:27:54 +0200
x86: make vcpu_destroy_pagetables() preemptible

... as it may take significant amounts of time.

The function, being moved to mm.c as the better home for it anyway, and
to avoid having to make a new helper function there non-static, is
given a "preemptible" parameter temporarily (until, in a subsequent
patch, its other caller is also being made capable of dealing with
preemption).

This is part of CVE-2013-1918 / XSA-45.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
master commit: 6cdc9be2a5f2a87b4504404fbf648d16d9503c19
master date: 2013-05-02 16:34:21 +0200
x86: make new_guest_cr3() preemptible

... as it may take significant amounts of time.

This is part of CVE-2013-1918 / XSA-45.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
master commit: e2e6b7b627fec0d7a769ab46441f2985ebccbf04
master date: 2013-05-02 16:35:50 +0200
x86: make MMUEXT_NEW_USER_BASEPTR preemptible

... as it may take significant amounts of time.

This is part of CVE-2013-1918 / XSA-45.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
master commit: 918a5f17b447072b40780f4d03a3adc99ff0073b
master date: 2013-05-02 16:36:44 +0200
x86: make vcpu_reset() preemptible

... as dropping the old page tables may take significant amounts of
time.

This is part of CVE-2013-1918 / XSA-45.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
master commit: 4939f9a6dee4280f38730fd3066e5dce353112f6
master date: 2013-05-02 16:37:24 +0200
x86: make arch_set_info_guest() preemptible

.. as the root page table validation (and the dropping of an eventual
old one) can require meaningful amounts of time.

This is part of CVE-2013-1918 / XSA-45.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
master commit: 99d2b149915010e986f4d8778708c5891e7b4635
master date: 2013-05-02 16:38:30 +0200
x86: make page table unpinning preemptible

... as it may take significant amounts of time.

Since we can't re-invoke the operation in a second attempt, the
continuation logic must be slightly tweaked so that we make sure
do_mmuext_op() gets run one more time even when the preempted unpin
operation was the last one in a batch.

This is part of CVE-2013-1918 / XSA-45.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
master commit: a3e049f8e86fe18e3b87f18dc0c7be665026fd9f
master date: 2013-05-02 16:39:06 +0200
x86: make page table handling error paths preemptible

... as they may take significant amounts of time.

This requires cloning the tweaked continuation logic from
do_mmuext_op() to do_mmu_update().

Note that in mod_l[34]_entry() a negative "preemptible" value gets
passed to put_page_from_l[34]e() now, telling the callee to store the
respective page in current->arch.old_guest_table (for a hypercall
continuation to pick up), rather than carrying out the put right away.
This is going to be made a little more explicit by a subsequent cleanup
patch.

This is part of CVE-2013-1918 / XSA-45.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
master commit: b8efae696c9a2d46e91fa0eda739427efc16c250
master date: 2013-05-02 16:39:37 +0200
VT-d: don't permit SVT_NO_VERIFY entries for known device types

Only in cases where we don't know what to do we should leave the IRTE
blank (suppressing all validation), but we should always log a warning
in those cases (as being insecure).

This is CVE-2013-1952 / XSA-49.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: "Zhang, Xiantao" <xiantao.zhang@intel.com>
master commit: 63cec00679cc65ab5d5a9447a62d5202f155b78c
master date: 2013-05-02 17:08:58 +0200
x86: cleanup after making various page table manipulation operations preemptible

This drops the "preemptible" parameters from various functions where
now they can't (or shouldn't, validated by assertions) be run in non-
preemptible mode anymore, to prove that manipulations of at least L3
and L4 page tables and page table entries are now always preemptible,
i.e. the earlier patches actually fulfill their purpose of fixing the
resulting security issue.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
master commit: b965b31a6bce8c37e67e525fae6da0e2f26d6b2e
master date: 2013-05-02 17:04:14 +0200
x86: allow VCPUOP_register_vcpu_info to work again on PVHVM guests

For details on the hypercall please see commit
c58ae69360ccf2495a19bf4ca107e21cf873c75b (VCPUOP_register_vcpu_info) and
the c/s 23143 (git commit 6b063a4a6f44245a727aa04ef76408b2e00af9c7)
(x86: move pv-only members of struct vcpu to struct pv_vcpu)
that introduced the regression.

The current code allows the PVHVM guest to make this hypercall.
But for PVHVM guest it always returns -EINVAL (-22) for Xen 4.2
and above. Xen 4.1 and earlier worked.

The reason is that the check in map_vcpu_info would fail
at:

  if ( v->arch.vcpu_info_mfn != INVALID_MFN )

The reason is that the vcpu_info_mfn for PVHVM guests ends up by
defualt with the value of zero (introduced by c/s 23143).

The code in vcpu_initialise which initialized vcpu_info_mfn to a
valid value (INVALID_MFN), would never be called for PVHVM:

    if ( is_hvm_domain(d) )
    {
        rc = hvm_vcpu_initialise(v);
        goto done;
    }

    v->arch.pv_vcpu.vcpu_info_mfn = INVALID_MFN;

while previously it would be:

     v->arch.vcpu_info_mfn = INVALID_MFN;

[right at the start of the function in Xen 4.1]

This fixes the problem with Linux advertising this error:
register_vcpu_info failed: err=-22

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

x86: call unmap_vcpu_info() regardless of guest type

This fixes a regression from 63753b3e ("x86: allow
VCPUOP_register_vcpu_info to work again on PVHVM guests").

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
master commit: 63753b3e0dc56efb1acf94fa46f3fee7bc59281c
master date: 2013-04-17 11:35:38 +0200
master commit: 9626d1c1fafe2da5af6e59478c9e9db6d03144df
master date: 2013-05-02 09:29:36 +0200
ns16550: delay resume until dom0 ACPI has a chance to run

Check for ioport access, before fully resuming operation, to avoid
spinning in __ns16550_poll when reading the LSR register returns 0xFF
on failing ioport access.

On some systems (like Lenovo T410, and some HP machines of similar vintage)
there is a SuperIO card that provides this legacy ioport on the LPC bus.

In this case, we need to wait for dom0's ACPI processing to run the proper
AML to re-initialize the chip, before we can use the card again.

This may cause a small amount of garbage to be written to the serial log
while we wait patiently for that AML to be executed.

This implementation limits the number of retries, to avoid a situation
where we keep trying over and over again, in the case of some other failure
on the ioport.

Signed-Off-By: Ben Guthro <benjamin.guthro@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
master commit: 6e96c186d23873597896051b043cfeb119c4a7d5
master date: 2013-04-24 11:41:53 +0200