21 Dec, 2011
1 commit
-
Add support for mappings without GNTMAP_contains_pte. This was not
supported because the unmap operation assumed that this flag was being
used; adding a parameter to the unmap operation to allow the PTE
clearing to be disabled is sufficient to make unmap capable of
supporting either mapping type.Signed-off-by: Daniel De Graaf
[v1: Fix cleanpatch warnings]
Signed-off-by: Konrad Rzeszutek Wilk
17 Dec, 2011
2 commits
-
These allow a domain A which has been granted access on a page of domain B's
memory to issue domain C with a copy-grant on the same page. This is useful
e.g. for forwarding packets between domains.Signed-off-by: Annie Li
Signed-off-by: Konrad Rzeszutek Wilk -
- They can't be used to map the page (so can only be used in a GNTTABOP_copy
hypercall).
- It's possible to grant access with a finer granularity than whole pages.
- Xen guarantees that they can be revoked quickly (a normal map grant can
only be revoked with the cooperation of the domain which has been granted
access).Signed-off-by: Annie Li
Signed-off-by: Konrad Rzeszutek Wilk
22 Nov, 2011
3 commits
-
Acked-by: Ian Campbell
Signed-off-by: Annie Li
Signed-off-by: Konrad Rzeszutek Wilk -
Receiver-side copying of packets is based on this implementation, it gives
better performance and better CPU accounting. It totally supports three types:
full-page, sub-page and transitive grants.However this patch does not cover sub-page and transitive grants, it mainly
focus on Full-page part and implements grant table V2 interfaces corresponding
to what already exists in grant table V1, such as: grant table V2
initialization, mapping, releasing and exported interfaces.Each guest can only supports one type of grant table type, every entry in grant
table should be the same version. It is necessary to set V1 or V2 version before
initializing the grant table.Grant table exported interfaces of V2 are same with those of V1, Xen is
responsible to judge what grant table version guests are using in every grant
operation.V2 fulfills the same role of V1, and it is totally backwards compitable with V1.
If dom0 support grant table V2, the guests runing on it can run with either V1
or V2.Acked-by: Ian Campbell
Signed-off-by: Annie Li
[v1: Modified alloc_vm_area call (new parameters), indentation, and cleanpatch
warnings]
Signed-off-by: Konrad Rzeszutek Wilk -
This patch introduces new structures of grant table V2, grant table V2 is an
extension from V1. Grant table is shared between guest and Xen, and Xen is
responsible to do corresponding work for grant operations, such as: figure
out guest's grant table version, perform different actions based on
different grant table version, etc. Although full-page structure of V2
is different from V1, it play the same role as V1.Acked-by: Ian Campbell
Signed-off-by: Annie Li
Signed-off-by: Konrad Rzeszutek Wilk
07 Nov, 2011
1 commit
-
* 'stable/vmalloc-3.2' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
net: xen-netback: use API provided by xenbus module to map rings
block: xen-blkback: use API provided by xenbus module to map rings
xen: use generic functions instead of xen_{alloc, free}_vm_area()
30 Sep, 2011
1 commit
-
Replace calls to the Xen-specific xen_alloc_vm_area() and
xen_free_vm_area() functions with the generic equivalent
(alloc_vm_area() and free_vm_area()).On x86, these were identical already.
Signed-off-by: David Vrabel
Signed-off-by: Konrad Rzeszutek Wilk
29 Sep, 2011
1 commit
-
If we want to use granted pages for AIO, changing the mappings of a user
vma and the corresponding p2m is not enough, we also need to update the
kernel mappings accordingly.
Currently this is only needed for pages that are created for user usages
through /dev/xen/gntdev. As in, pages that have been in use by the
kernel and use the P2M will not need this special mapping.
However there are no guarantees that in the future the kernel won't
start accessing pages through the 1:1 even for internal usage.In order to avoid the complexity of dealing with highmem, we allocated
the pages lowmem.
We issue a HYPERVISOR_grant_table_op right away in
m2p_add_override and we remove the mappings using another
HYPERVISOR_grant_table_op in m2p_remove_override.
Considering that m2p_add_override and m2p_remove_override are called
once per page we use multicalls and hypercall batching.Use the kmap_op pointer directly as argument to do the mapping as it is
guaranteed to be present up until the unmapping is done.
Before issuing any unmapping multicalls, we need to make sure that the
mapping has already being done, because we need the kmap->handle to be
set correctly.Signed-off-by: Stefano Stabellini
[v1: Removed GRANT_FRAME_BIT usage]
Signed-off-by: Konrad Rzeszutek Wilk
12 Jan, 2011
2 commits
-
gnttab_map_refs maps some grant refs and uses the new m2p override to
set a proper m2p mapping for the granted pages.gnttab_unmap_refs unmaps the granted refs and removes th mappings from
the m2p override.Signed-off-by: Stefano Stabellini
Signed-off-by: Jeremy Fitzhardinge
Signed-off-by: Konrad Rzeszutek Wilk -
Impact: hypercall definitions
These functions populate the gnttab data structures used by the
granttab map and unmap ops and are used in the backend drivers.Originally xen-unstable.hg 9625:c3bb51c443a7
[ Include Stefano's fix for phys_addr_t ]
Signed-off-by: Ian Campbell
Signed-off-by: Stefano Stabellini
Signed-off-by: Jeremy Fitzhardinge
Signed-off-by: Konrad Rzeszutek Wilk
23 Jul, 2010
1 commit
-
Add the xen pci platform device driver that is responsible
for initializing the grant table and xenbus in PV on HVM mode.
Few changes to xenbus and grant table are necessary to allow the delayed
initialization in HVM mode.
Grant table needs few additional modifications to work in HVM mode.The Xen PCI platform device raises an irq every time an event has been
delivered to us. However these interrupts are only delivered to vcpu 0.
The Xen PCI platform interrupt handler calls xen_hvm_evtchn_do_upcall
that is a little wrapper around __xen_evtchn_do_upcall, the traditional
Xen upcall handler, the very same used with traditional PV guests.When running on HVM the event channel upcall is never called while in
progress because it is a normal Linux irq handler (and we cannot switch
the irq chip wholesale to the Xen PV ones as we are running QEMU and
might have passed in PCI devices), therefore we cannot be sure that
evtchn_upcall_pending is 0 when returning.
For this reason if evtchn_upcall_pending is set by Xen we need to loop
again on the event channels set pending otherwise we might loose some
event channel deliveries.Signed-off-by: Stefano Stabellini
Signed-off-by: Sheng Yang
Signed-off-by: Jeremy Fitzhardinge
27 May, 2008
1 commit
-
This patch implements Xen save/restore and migration.
Saving is triggered via xenbus, which is polled in
drivers/xen/manage.c. When a suspend request comes in, the kernel
prepares itself for saving by:1 - Freeze all processes. This is primarily to prevent any
partially-completed pagetable updates from confusing the suspend
process. If CONFIG_PREEMPT isn't defined, then this isn't necessary.2 - Suspend xenbus and other devices
3 - Stop_machine, to make sure all the other vcpus are quiescent. The
Xen tools require the domain to run its save off vcpu0.4 - Within the stop_machine state, it pins any unpinned pgds (under
construction or destruction), performs canonicalizes various other
pieces of state (mostly converting mfns to pfns), and finally5 - Suspend the domain
Restore reverses the steps used to save the domain, ending when all
the frozen processes are thawed.Signed-off-by: Jeremy Fitzhardinge
Signed-off-by: Thomas Gleixner
25 Apr, 2008
2 commits
-
split out x86 specific part from grant-table.c and
allow ia64/xen specific initialization.
ia64/xen grant table is based on pseudo physical address
(guest physical address) unlike x86/xen. On ia64 init_mm
doesn't map identity straight mapped area.
ia64/xen specific grant table initialization is necessary.Signed-off-by: Isaku Yamahata
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner -
Don't use alloc_vm_area()/free_vm_area() directly, instead define
xen_alloc_vm_area()/xen_free_vm_area() and use them.alloc_vm_area()/free_vm_area() are used to allocate/free area which
are for grant table mapping. Xen/x86 grant table is based on virtual
address so that alloc_vm_area()/free_vm_area() are suitable.
On the other hand Xen/ia64 (and Xen/powerpc) grant table is based on
pseudo physical address (guest physical address) so that allocation
should be done differently.
The original version of xenified Linux/IA64 have its own
allocate_vm_area()/free_vm_area() definitions which don't allocate vm area
contradictory to those names.
Now vanilla Linux already has its definitions so that it's impossible
to have IA64 definitions of allocate_vm_area()/free_vm_area().
Instead introduce xen_allocate_vm_area()/xen_free_vm_area() and use them.Signed-off-by: Isaku Yamahata
Signed-off-by: Jeremy Fitzhardinge
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner
18 Jul, 2007
1 commit
-
Add Xen 'grant table' driver which allows granting of access to
selected local memory pages by other virtual machines and,
symmetrically, the mapping of remote memory pages which other virtual
machines have granted access to.This driver is a prerequisite for many of the Xen virtual device
drivers, which grant the 'device driver domain' restricted and
temporary access to only those memory pages that are currently
involved in I/O operations.Signed-off-by: Jeremy Fitzhardinge
Signed-off-by: Ian Pratt
Signed-off-by: Christian Limpach
Signed-off-by: Chris Wright
