netif.h: Document xen-net{back, front} multi-queue feature

Document the multi-queue feature in terms of XenStore keys to be written
by the backend and by the frontend.

Signed-off-by: Andrew J. Bennieston <andrew.bennieston@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
xenstat: fix unsigned less-than-0 comparison

Commit 1438d36f ("xenstat: Fix buffer over-run with new_domains being
negative.") attempted to fix the handling of a negative error result
from xc_domain_getinfolist in xenstat_get_node. However, it forgot to
change the result variable from an unsigned type to a signed one.

Do so, allowing the error result to be handled properly.

Signed-off-by: Matthew Daley <mattd@bugfuzz.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
xenstat: don't leak memory in getBridge

getBridge's method of returning a result was a little confused:
allocating a result buffer but never using it.

Simplify by instead allowing a result buffer to be passed in and
modifying the single usage to match.

Signed-off-by: Matthew Daley <mattd@bugfuzz.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
hvm/hpet: Add manual unit test code.

Add the code at tools/tests/vhpet.

See comment in tools/tests/vhpet/main.c for details on running
either in a xen source tree or elsewhere.

A basic in source tree usage is:

make -C tools/tests/vhpet run

Does repro the bug:

..MP-BIOS bug: 8254 timer not connected to IO-APIC

The make file includes coping hpet.c and hpet.h from the source
tree.  hpet.c is then modifed to remove all include file and add the
emul.h include file.

The manual test code has only a few automatic checks that output
messages to stderr:

1) Possible ..MP-BIOS bug: 8254 timer...
   if 1st period is not <= the expected value

2) hpet_set_mode(%ld): T%d Error: Set ...
   if read of comparator != write of comparator in

3) hpet_check_stopped(%ld): T%d Error: Set ...
   if read != write

4) main(%ld): With clock stopped mc64 changed: ...
   if hpet_save returns different master clock values when called
   more then once.

It also generates a lot of output, which is why the sugested way to
use includes a redirect of stdout to a file.

Signed-off-by: Don Slutz <dslutz@verizon.com>
Acked-by: Tim Deegan <tim@xen.org>
hvm/hpet: Only call guest_time_hpet(h) one time per action.

This call is expensive and will cause extra time to pass.

The software-developers-hpet-spec-1-0a.pdf does not say how long it
takes after the main clock is enabled before the first change of the
master clock.  Therefore multiple calls to guest_time_hpet(h) are
not needed.  Since each timer is started by a loop, each ones start
time will change on the multple calls.  In the real hardware, there
is not delta based on which timer.

Without this change it is possible for an HVM guest running linux to
get the message:

..MP-BIOS bug: 8254 timer not connected to IO-APIC

On the guest console(s); and the guest will panic.

Also Xen hypervisor console with be flooded with:

vioapic.c:352:d1 Unsupported delivery mode 7
vioapic.c:352:d1 Unsupported delivery mode 7
vioapic.c:352:d1 Unsupported delivery mode 7

Signed-off-by: Don Slutz <dslutz@verizon.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
hvm/hpet: Only set comparator or period not both.

The current code sets both.  If setting the comparator also set
comparator64 (the hidden version).

Based on:

software-developers-hpet-spec-1-0a.pdf

A write call should only change comparator or period, not both.

Signed-off-by: Don Slutz <dslutz@verizon.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
hvm/hpet: Correctly limit period to a maximum.

In the code section after the comment:

    /*
     * Clamp period to reasonable min/max values:
     *  - minimum is 100us, same as timers controlled by vpt.c
     *  - maximum is to prevent overflow in time_after() calculations
     */

The current maximum limit actually allows "bad" values like 0 and 1.
This is because it uses a mask not a maximum.

Signed-off-by: Don Slutz <dslutz@verizon.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
hvm/hpet: In hpet_save, correctly compute mc64.

When the master clock is not enabled, mc64 has the right value.

Basicly do the same thing as hpet_read_maincounter().

Signed-off-by: Don Slutz <dslutz@verizon.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
hvm/hpet: In hpet_save, call hpet_get_comparator.

This changes save data to consistent/expected values.  It is not
technically required because hpet_get_comparator() will adjust from
any value to the correct value. And hpet_get_comparator() is
effectivly called in hpet_load via hpet_set_timer.

However it does look strange to people that the output from
xen-hvmctx for the comparator values do not change when the master
clock does.

The software-developers-hpet-spec-1-0a.pdf says that the comparator
will allways be greater than master clock for a periodic timer.

Signed-off-by: Don Slutz <dslutz@verizon.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
hvm/hpet: Init comparator64 like comparator.

The software-developers-hpet-spec-1-0a.pdf says that the comparator
starts as all 1's.  Also make the hidden register comparator64 the same.

Since only the hidden register comparator64 is used by hpet_save, it
needs to start out with the right value.

A disabled hpet (like when a guest is starting), should start with
the value the spec says.  Both the guest (via reading the
comparator) and an administrator using xen-hvmctx, will see all 0's
not all 1's.

Signed-off-by: Don Slutz <dslutz@verizon.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
hvm/hpet: comparator can only change when master clock is enabled.

This is based on software-developers-hpet-spec-1-0a.pdf saying:

When the main counter value matches the value in the timer's
comparator register, an interrupt can be generated.  The hardware
will then automatically increase the value in the compare register
by the last value written to that register.

When the overall enable is off (the main count is halted), none of
the compare registers should change.

The code lines:

    elapsed = hpet_read_maincounter(h, guest_time) +
        period - 1 - comparator;
    comparator += (elapsed / period) * period;

are what matter here.  They will always adjust comparator to be no
more then one period away.

Using some numbers to help show the issue:

hpet_read_maincounter(h, guest_time) = 67752
period = 62500
comparator = 255252 == 67752 + 3 * 62500

comparator       : 255252
elapsed          : -125001
elapsed/period   : -2
comparator_delta : -125000
new comparator   : 130252

Signed-off-by: Don Slutz <dslutz@verizon.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
hvm/hpet: Prevent master clock equal to comparator while enabled

Based on the software-developers-hpet-spec-1-0a.pdf, the comparator
for a periodic timer will change to the new value when it matches
the master clock.  The current code here uses a very standard
rounding formula of "((x + y - 1) / y) * y".  This is wrong because
in this case you need to go to the next comparator value when "x"
equals "y". Not when "x + 1" equals "y".  In this case "y" is the
period and "x" is the master clock.

The code lines:

    elapsed = hpet_read_maincounter(h, guest_time) +
        period - 1 - comparator;
    comparator += (elapsed / period) * period;

are what matter here.

Using some numbers to help show the issue:

hpet_read_maincounter(h, guest_time) = 130252
period = 62500

comparator       : 130252
elapsed          : 62499
elapsed/period   : 0
comparator_delta : 0
new comparator   : 130252

Signed-off-by: Don Slutz <dslutz@verizon.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
hvm/hpet: Detect comparator values in the past

This statement only works using 64-bit arithmetic for the main
                                     63
counter never changing by more then 2  .  (Which is a boundary
case that should not happen in my life time.)

Signed-off-by: Don Slutz <dslutz@verizon.com>
Acked-by: Tim Deegan <tim@xen.org>
domctl: tighten XEN_DOMCTL_*_permission

With proper permission (and, for the I/O port case, wrap-around) checks
added (note that for the I/O port case a count of zero is now being
disallowed, in line with I/O memory handling):

XEN_DOMCTL_irq_permission:
XEN_DOMCTL_ioport_permission:

 Of both IRQs and I/O ports there is only a reasonably small amount, so
 there's no excess resource consumption involved here. Additionally
 they both have a specialized XSM hook associated.

XEN_DOMCTL_iomem_permission:

 While this also has a specialized XSM hook associated (just like
 XEN_DOMCTL_{irq,ioport}_permission), it's not clear whether it's
 reasonable to expect XSM to restrict the number of ranges associated
 with a domain via this hook (which is the main resource consumption
 item here).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
x86/P2M: pass on errors from p2m_set_entry()

... at least in a couple of straightforward cases.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
x86/P2M: p2m_change_type() should pass on error from p2m_set_entry()

Modify the function's name to help eventual backports involving this
function, and in one case where this is trivially possible also stop
ignoring its return value.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
gnttab: don't flush the TLB on grant ops for auto-translated guests

For auto-translated guests the p2m code will do the necessary TLB
flushes, so there's no need to perform any TLB flushes in generic
grant table code.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
x86: remove c_identify of the struct cpu_dev

After commit 44e24f85674d (x86: don't call generic_identify() redundantly)
the struct cpu_dev don't need the c_identify.

Signed-off-by: Yi Li <peteryili@tencent.com>
pvh dom0: construct_dom0 changes

This patch changes construct_dom0() to boot in pvh mode:
  - Make sure dom0 elf supports pvh mode.
  - Call guest_physmap_add_page for pvh rather than simple p2m setting
  - Map all non-RAM regions 1:1 upto the end region in e820 or 4GB which
    ever is higher.
  - Allocate p2m, copying calculation from toolstack.
  - Allocate shared info page from the virtual space so that dom0 PT
    can be updated. Then update p2m for it with the actual mfn.
  - Since we build the page tables for pvh same as for pv, in
    pvh_fixup_page_tables_for_hap we replace the mfns with pfns.

Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
Nested VMX: load current_vmcs only when it exists

There may not have valid vmcs on current CPU. So only load it when it exists.

This original fixing is from Edmud <edmund.h.white@intel.com>.

Signed-off-by: Edmund H White <edmund.h.white@intel.com>
Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>