search for: xen_domain_type

...bus.o privcmd.o xenstored.o diff --git a/include/xen/xen.h b/include/xen/xen.h index a164024..d814ef7 100644 --- a/include/xen/xen.h +++ b/include/xen/xen.h @@ -1,6 +1,9 @@ #ifndef _XEN_XEN_H #define _XEN_XEN_H +#include <xen/interface/xen.h> +#include <asm/xen/hypervisor.h> + enum xen_domain_type { XEN_NATIVE, /* running on bare hardware */ XEN_PV_DOMAIN, /* running in a PV domain */ @@ -18,15 +21,7 @@ extern enum xen_domain_type xen_domain_type; xen_domain_type == XEN_PV_DOMAIN) #define xen_hvm_domain() (xen_domain() && \ xen_domain_type == XEN_HVM_DOMA...

...bus.o privcmd.o xenstored.o diff --git a/include/xen/xen.h b/include/xen/xen.h index a164024..d814ef7 100644 --- a/include/xen/xen.h +++ b/include/xen/xen.h @@ -1,6 +1,9 @@ #ifndef _XEN_XEN_H #define _XEN_XEN_H +#include <xen/interface/xen.h> +#include <asm/xen/hypervisor.h> + enum xen_domain_type { XEN_NATIVE, /* running on bare hardware */ XEN_PV_DOMAIN, /* running in a PV domain */ @@ -18,15 +21,7 @@ extern enum xen_domain_type xen_domain_type; xen_domain_type == XEN_PV_DOMAIN) #define xen_hvm_domain() (xen_domain() && \ xen_domain_type == XEN_HVM_DOMA...

...bus.o privcmd.o xenstored.o diff --git a/include/xen/xen.h b/include/xen/xen.h index a164024..d814ef7 100644 --- a/include/xen/xen.h +++ b/include/xen/xen.h @@ -1,6 +1,9 @@ #ifndef _XEN_XEN_H #define _XEN_XEN_H +#include <xen/interface/xen.h> +#include <asm/xen/hypervisor.h> + enum xen_domain_type { XEN_NATIVE, /* running on bare hardware */ XEN_PV_DOMAIN, /* running in a PV domain */ @@ -18,15 +21,7 @@ extern enum xen_domain_type xen_domain_type; xen_domain_type == XEN_PV_DOMAIN) #define xen_hvm_domain() (xen_domain() && \ xen_domain_type == XEN_HVM_DOMA...

...he * documentation of the Xen Device Tree format. */ #define GRANT_TABLE_PHYSADDR 0 +void __init xen_early_init(void) +{ + struct device_node *node; + + node = of_find_compatible_node(NULL, NULL, "xen,xen"); + if (!node) { + pr_debug("No Xen support\n"); + return; + } + + xen_domain_type = XEN_HVM_DOMAIN; + machine_desc->smp_init = xen_smp_init; +} + static int __init xen_guest_init(void) { struct xen_add_to_physmap xatp; @@ -194,25 +221,21 @@ static int __init xen_guest_init(void) int i; node = of_find_compatible_node(NULL, NULL, "xen,xen"); - if (!node) { -...

This patch set is for the next merge window. They are just enhancements of the already merged patches or ia64 porting from x86 paravirt techniques and that their quality is enough for merge. This patch set is for more paravirtualization on ia64/xen domU. This patch set does - remove existing warnings - paravirtualize fsys call (fsys.S) by multi compile - paravirtualize gate page (gate.S) by multi

This patch set is for the next merge window. They are just enhancements of the already merged patches or ia64 porting from x86 paravirt techniques and that their quality is enough for merge. This patch set is for more paravirtualization on ia64/xen domU. This patch set does - remove existing warnings - paravirtualize fsys call (fsys.S) by multi compile - paravirtualize gate page (gate.S) by multi

This patchset is ia64/xen domU patch take 10 which is rebased to 2.6.27-rc4. This patchset implements ia64/xen domU support based on ia64/pv_ops frame work which was sent as another patchest. This patchset does the followings. - Some preparation work. Mainly importing header files to define related structures. - Then, define functions related to hypercall which is the way to communicate with

This patchset is ia64/xen domU patch take 10 which is rebased to 2.6.27-rc4. This patchset implements ia64/xen domU support based on ia64/pv_ops frame work which was sent as another patchest. This patchset does the followings. - Some preparation work. Mainly importing header files to define related structures. - Then, define functions related to hypercall which is the way to communicate with

This patchset is ia64/xen domU patch take 11. Tony, please commit those patches. They are ready to commit because all the issues which were pointed out had been addressed and got enough reviews. This patchset does the followings. - Some preparation work. Mainly importing header files to define related structures. - Then, define functions related to hypercall which is the way to communicate

This patchset is ia64/xen domU patch take 11. Tony, please commit those patches. They are ready to commit because all the issues which were pointed out had been addressed and got enough reviews. This patchset does the followings. - Some preparation work. Mainly importing header files to define related structures. - Then, define functions related to hypercall which is the way to communicate

This patchset is ia64/xen domU patch take 12. Tony, please commit those patches. They are ready to commit because all the issues which were pointed out had been addressed and got enough reviews. This patchset does the followings. - Some preparation work. Mainly importing header files to define related structures. - Then, define functions related to hypercall which is the way to communicate

This patchset is ia64/xen domU patch take 12. Tony, please commit those patches. They are ready to commit because all the issues which were pointed out had been addressed and got enough reviews. This patchset does the followings. - Some preparation work. Mainly importing header files to define related structures. - Then, define functions related to hypercall which is the way to communicate

...ecific variables should + * be rewritten to fetch this info by themselves from the + * start_info page. + */ + console_page = + (char *)(ptoa(si->console.domU.mfn) + KERNBASE); + xen_store = (struct xenstore_domain_interface *) + (ptoa(si->store_mfn) + KERNBASE); + + xen_domain_type = XEN_PV_DOMAIN; + vm_guest = VM_GUEST_XEN; + + /* + * Use the stack Xen gives us to build the page tables + * as native FreeBSD expects to find them (created + * by the boot trampoline). + */ + for (i = 0; i < 512; i++) { + /* Each slot of the level 4 pages points to the same level 3 page...

Hi Ingo, Here''s the chunk of patches to add Xen Dom0 support (it''s probably worth creating a new xen/dom0 topic branch for it). A dom0 Xen domain is basically the same as a normal domU domain, but it has extra privileges to directly access hardware. There are two issues to deal with: - translating to and from the domain''s pseudo-physical addresses and real machine