kdd's knowledge of Windows kernel internals is several releases out of
date now. However the underlying implementation of the serial protocol
is still sound. I have heard that some people are using it, and I'm happy
to answer questions/bug reports, so don't deprecate it just yet.
Signed-off-by: Tim Deegan <tim@xen.org>
George has a long record of contributions to the x86 memory management
and p2m code. He will be taking over as the primary maintainer of
x86/mm; I will still help out with the shadow pagetable code.
Signed-off-by: Tim Deegan <tim@xen.org>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Razvan and Tamas have been working on this code for a while now, and
have kindly agreed to act as maintainers.
Signed-off-by: Tim Deegan <tim@xen.org>
Acked-by: Tamas K Lengyel <tlengyel@novetta.com>
Acked-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
The struct just contains three methods and no data, so the name
hvm_mmio_ops more accurately reflects its content. A subsequent patch
introduces a new structure which more accurately warrants the name
hvm_mmio_handler so doing the rename in this purely cosmetic patch avoids
conflating functional and cosmetic changes in a single patch.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
... as being identical to is_pv_32bit_vcpu() after the x86-32 removal.
In a few cases this includes an additional is_pv_32bit_vcpu() ->
is_pv_32bit_domain() conversion.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The sharing vm_event ring being enabled is not necessary for mem_sharing
memops.
Signed-off-by: Tamas K Lengyel <tklengyel@sec.in.tum.de>
Reviewed-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
The is_mmio parameter can be inferred from the ioreq type.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Constify its other parameter. Avoid introducing local variable is_mmio.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
The check is done at the wrong point (since it is irrelevant if the
I/O is to be handled by the hypervisor) and its functionality can be
covered by returning X86EMUL_UNHANDLEABLE from hvm_send_assist_req()
instead.
This patch also removes the domain_crash() call from
hvm_send_assist_req(). Returning X86EMUL_UNHANDLEABLE allows the
higher layers of emulation to decide what to do instead.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Currently hvmemul_do_io() handles paging for I/O to/from a guest address
inline. This causes every exit point to have to execute:
if ( ram_page )
put_page(ram_page);
This patch introduces wrapper hvmemul_do_io_addr() and
hvmemul_do_io_buffer() functions. The latter is used for I/O to/from a Xen
buffer and thus the complexity of paging can be restricted only to the
former, making the common hvmemul_do_io() function less convoluted.
This patch also tightens up some types and introduces pio/mmio wrappers
for the above functions with comments to document their semantics.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Managing l4 page table and argument translation area are two unrelated
operations and should be handled separately
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
- use 32-bit types where possible (produces slightly better code)
- drop (now) unnecessary casts
- avoid indirection where not needed
- avoid duplicate log messages in vlapic_write()
- minor other cleanup
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
vcpu_guest_context's fs_base, gs_base_kernel and gs_base_user are not defined
for 32-bit guests.
Drop PVH 32bitfixme ASSERT.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The comments describing the initial pv-domain memory layout are not
complete. They do not mention the pages with console info and xenstore
data.
Add this information to the comments.
Signed-off-by: Juergen Gross <jgross@suse.com>
gdbsx_guest_mem_io() does not get d passed, it expects to handle the
domain lookup itself. Specifically, the caller of
XEN_DOMCTL_gdbsx_guestmemio is expected to use DOMID_IDLE to interact
with the hypervisor, rather than a domain, which doesn't interact well
with with the domain rcu lock.
Signed-off-by: Don Slutz <dslutz@verizon.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The number of struct evtchn in a page must be a power of two. Under
some workloads performance is improved slightly by padding struct
evtchn to 64 bytes (a typical cache line size), thus putting the fewer
per-channel locks into each cache line.
This does not decrease the number of struct evtchn's per-page.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
When sending an event, use a new per-event channel lock to safely
validate the event channel state.
This new lock must be held when changing event channel state. Note
that the event channel lock must also be held when changing state from
ECS_FREE or it will race with a concurrent get_free_port() call.
To avoid having to take the remote event channel locks when sending to
an interdomain event channel, the local and remote channel locks are
both held when binding or closing an interdomain event channel.
This significantly increases the number of events that can be sent
from multiple VCPUs. But struct evtchn increases in size, reducing
the number that fit into a single page to 64 (instead of 128).
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
notify_via_xen_event_channel() and free_xen_event_channel() had to
check if the domain was dying because they may be called while the
domain is being destroyed and the struct evtchn's are being freed.
By deferring the freeing of the struct evtchn's until all references
to the domain are dropped, these functions can rely on the channel
state being present and valid.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Freeing a xen event channel would clear xen_consumer before clearing
the channel state, leaving a window where the channel is in a funny
state (still bound but no consumer).
Move the clear of xen_consumer into free_evtchn() where the state is
also cleared.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Ditch the pointless evtchn_close() wrapper around __evtchn_close()
(renaming the latter) as well as some bogus casts of function results
to void.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
The vector parameters are more usefully u8 right away. This is
particularly important for the vioapic_update_EOI() invocation from
vioapic_write() (which luckily is only a latent issue, as
VIOAPIC_VERSION_ID is still hard coded to 0x11 right now). But it at
once allows simplifying VMX's EXIT_REASON_EOI_INDUCED handling (the
kind of pointless helper function should have been static anyway; not
being use for anything else, it gets removed altogether).
Plus vlapic_handle_EOI() (now renamed for that purpose) can be used as
the tail of vlapic_EOI_set() instead of duplicating that code.
Finally replace a stray current->domain use in vlapic_handle_EOI().
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
If a guest is not evenly grant mapping across its VCPUs one of the
VCPUs may run out of free maptrack entries even though other VCPUs
have many free.
If this happens, "steal" free entries from other VCPUs. We want to
steal entries such that:
a) We avoid ping-ponging stolen entries between VCPUs.
b) The number of free entries owned by each VCPUs tends (over time) to
the number it uses.
So when stealing, we select a VCPU at random (reducing (a)) and we
transfer the stolen entries to the thief VCPU (aiming for (b)).
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Performance analysis of aggregate network throughput with many VMs
shows that performance is signficantly limited by contention on the
maptrack lock when obtaining/releasing maptrack handles from the free
list.
Instead of a single free list use a per-VCPU list. This avoids any
contention when obtaining a handle. Handles must be released back to
their original list and since this may occur on a different VCPU there
is some contention on the destination VCPU's free list tail pointer
(but this is much better than a per-domain lock).
Increase the default maximum number of maptrack frames by 4 times
because: a) struct grant_mapping is now 16 bytes (instead of 8); and
b) a guest may not evenly distribute all the grant map operations
across the VCPUs (meaning some VCPUs need more maptrack entries than
others).
Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Fold msixtbl_addr_to_virt() + virt_to_msi_desc() into simplified
msixtbl_addr_to_desc(), as the callers don't need the virtual address
anymore.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
In particular we want to avoid losing track of our own intention to
have an entry masked. Physical unmasking now happens only when both
host and guest requested so.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
- __pci_enable_msix() now checks that an MSI-X capability was actually
found
- pass "pos" to msix_capability_init() as both callers already know it
(and hence there's no need to re-obtain it)
- call __pci_disable_msi{,x}() directly instead of via
pci_disable_msi() from __pci_enable_msi{x,}() state validation paths
- use msix_control_reg() instead of open coding it
- log message adjustments
- coding style corrections
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The number of slots per page being 511 (i.e. not a power of two) means
that the (32-bit) read and write indexes going beyond 2^32 will likely
disturb operation. Extend I/O req server creation so the caller can
indicate that it is using suitable atomic accesses where needed (not
all accesses to the two pointers really need to be atomic), allowing
the hypervisor to atomically canonicalize both pointers when both have
gone through at least one cycle.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
In hvm_hap_nested_page_fault() latch the current domain alongside the
current vCPU into a local variable, making use of it where possible
also beyond what the title says.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Add a common interface for matching the current cpu against an
array of x86_cpu_ids. Also change mwait-idle.c to use it.
Signed-off-by: Wei Wang <wei.w.wang@intel.com>
Both PV and HVM logic have similar but not similar enough code here.
Synchronize the two so that
- in the HVM case we don't unconditionally try to access extended
config space
- in the PV case we pass a correct range to the XSM hook
- in the PV case we don't needlessly deny access when the operation
isn't really on PCI config space
All this along with sharing the macros HVM already had here.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
By keeping a count of the number of currently valid event channels,
port_is_valid() can be simplified.
d->valid_evtchns is only increased (while holding d->event_lock), so
port_is_valid() may be safely called without taking the lock (this
will be useful later).
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
The interface description of pvUSB lacks some access macros as using
linux kernel macros is assumed to work well. This solution is rather
unfriendly for pvusb implementations being outside the linux kernel.
Additionally things will break quite unpleasent in case the linux
kernel implementation is changed.
To avoid these problems define own macros for accessing bitfields of
the interface and for values of several structure members.
While working on the file add some more comments, especially for the
xenstore interface.
Signed-off-by: Juergen Gross <jgross@suse.com>
The statement to reset nb_watches should be in del_watches, not
del_transactions.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: David Scott <dave.scott@citrix.com>
Acked-by: David Scott <dave.scott@citrix.com>
[ ijc -- fix syntax error by adding a ";" to the previous line in the
new location and removing from the previous line in the old ]
This patch does following things:
1. Document v1 format.
2. Factor out function to handle QEMU restore data and function to
handle v1 blob for restore path.
3. Refactor save function to generate different blobs in the order
specified in format specification.
4. Change functions to use "goto out" idiom.
No functional changes introduced.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
It uses a PPI which we cannot route to a guest, and will surely need
more support than just that anyway.
I noticed this on Mustang with UEFI where the built in DTB contains a
node of this type.
According to linux/Documentation/devicetree/bindings/arm/pmu.txt the
ARM v7 (Cortex-A{7,15}) PMUs require a PPI too, so blacklist them as
well.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@citrix.com>
xc_dom_load_elf_symtab was incorrectly trying to perform the same
calculations already done in elf_parse_bsdsyms when load == 0 is used.
Instead of trying to repeat the calculations, just trust what
elf_parse_bsdsyms has already accounted for.
This also simplifies the code by allowing the non-load case to return
earlier.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
The current code for allocating memory for PV guests batches the
hypercalls to allocate memory by allocating 1024*1024 extents of order 0
at a time. To make this faster, first try allocating extents of order 9
(2 MiB) before falling back to the order 0 allocating if the order 9
allocation fails.
On my test machine this reduced the time to start a 128 GiB PV guest by
about 60 seconds.
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
This patch does the following:
1. Use local variables for dummy vNUMA layout in PV case.
2. Avoid leaking dummy layout back to caller in PV case.
3. Use local variables to reference vNUMA layout (whether it is dummy
or provided by caller) for both PV and HVM.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
These files are leaked when using qemu-trad stubdom. They are
intermediate files created by libxc. Unfortunately they don't fit well
in our userdata scheme. Clean them up after we destroy all userdata,
we're sure they are not useful anymore at that point.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Tim Deegan
Jan Beulich
Paul Durrant
Tamas K Lengyel
Boris Ostrovsky
Ian Jackson
Juergen Gross
Don Slutz
David Vrabel
Malcolm Crossley
Wei Wang
Wei Liu
Ian Campbell
Roger Pau Monne
Ross Lagerwall
Olaf Hering