| Message ID | 1347621207-11294-14-git-send-email-stefano.stabellini@eu.citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Sep 14, 2012 at 12:13:16PM +0100, Stefano Stabellini wrote: > Initialize the grant table mapping at the address specified at index 0 > in the DT under the /xen node. > After the grant table is initialized, call xenbus_probe (if not dom0). So we don't really care about the grant's size then? The DT xen.txt talks about it.. > > Changes in v2: > > - introduce GRANT_TABLE_PHYSADDR; > - remove unneeded initialization of boot_max_nr_grant_frames. > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> > --- > arch/arm/xen/enlighten.c | 14 ++++++++++++++ > 1 files changed, 14 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c > index c2a47a7..036a4d8 100644 > --- a/arch/arm/xen/enlighten.c > +++ b/arch/arm/xen/enlighten.c > @@ -1,8 +1,12 @@ > #include <xen/xen.h> > +#include <xen/grant_table.h> > +#include <xen/hvm.h> > #include <xen/interface/xen.h> > #include <xen/interface/memory.h> > +#include <xen/interface/hvm/params.h> > #include <xen/features.h> > #include <xen/platform_pci.h> > +#include <xen/xenbus.h> > #include <asm/xen/hypervisor.h> > #include <asm/xen/hypercall.h> > #include <linux/module.h> > @@ -42,6 +46,7 @@ EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range); > * see Documentation/devicetree/bindings/arm/xen.txt for the > * documentation of the Xen Device Tree format. > */ > +#define GRANT_TABLE_PHYSADDR 0 > static int __init xen_guest_init(void) > { > struct xen_add_to_physmap xatp; > @@ -51,6 +56,7 @@ static int __init xen_guest_init(void) > const char *s = NULL; > const char *version = NULL; > const char *xen_prefix = "xen,xen-"; > + struct resource res; > > node = of_find_compatible_node(NULL, NULL, "xen,xen"); > if (!node) { > @@ -65,6 +71,9 @@ static int __init xen_guest_init(void) > pr_debug("Xen version not found\n"); > return 0; > } > + if (of_address_to_resource(node, GRANT_TABLE_PHYSADDR, &res)) > + return 0; > + xen_hvm_resume_frames = res.start >> PAGE_SHIFT; > xen_domain_type = XEN_HVM_DOMAIN; > > xen_setup_features(); > @@ -98,6 +107,11 @@ static int __init xen_guest_init(void) > * is required to use VCPUOP_register_vcpu_info to place vcpu info > * for secondary CPUs as they are brought up. */ > per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0]; > + > + gnttab_init(); > + if (!xen_initial_domain()) > + xenbus_probe(NULL); > + > return 0; > } > core_initcall(xen_guest_init); > -- > 1.7.2.5
On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote: > On Fri, Sep 14, 2012 at 12:13:16PM +0100, Stefano Stabellini wrote: > > Initialize the grant table mapping at the address specified at index 0 > > in the DT under the /xen node. > > After the grant table is initialized, call xenbus_probe (if not dom0). > > So we don't really care about the grant's size then? The DT xen.txt > talks about it.. I am assuming that the size of the memory region specified in the device tree is sufficiently large to map the entire grant table, given that both the device tree hypervisor entry and the grant table size comes from Xen. The grant table size is currently queried to Xen directly via an hypercall (GNTTABOP_query_size). Basically the size in the device tree is redundant information. > > Changes in v2: > > > > - introduce GRANT_TABLE_PHYSADDR; > > - remove unneeded initialization of boot_max_nr_grant_frames. > > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> > > --- > > arch/arm/xen/enlighten.c | 14 ++++++++++++++ > > 1 files changed, 14 insertions(+), 0 deletions(-) > > > > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c > > index c2a47a7..036a4d8 100644 > > --- a/arch/arm/xen/enlighten.c > > +++ b/arch/arm/xen/enlighten.c > > @@ -1,8 +1,12 @@ > > #include <xen/xen.h> > > +#include <xen/grant_table.h> > > +#include <xen/hvm.h> > > #include <xen/interface/xen.h> > > #include <xen/interface/memory.h> > > +#include <xen/interface/hvm/params.h> > > #include <xen/features.h> > > #include <xen/platform_pci.h> > > +#include <xen/xenbus.h> > > #include <asm/xen/hypervisor.h> > > #include <asm/xen/hypercall.h> > > #include <linux/module.h> > > @@ -42,6 +46,7 @@ EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range); > > * see Documentation/devicetree/bindings/arm/xen.txt for the > > * documentation of the Xen Device Tree format. > > */ > > +#define GRANT_TABLE_PHYSADDR 0 > > static int __init xen_guest_init(void) > > { > > struct xen_add_to_physmap xatp; > > @@ -51,6 +56,7 @@ static int __init xen_guest_init(void) > > const char *s = NULL; > > const char *version = NULL; > > const char *xen_prefix = "xen,xen-"; > > + struct resource res; > > > > node = of_find_compatible_node(NULL, NULL, "xen,xen"); > > if (!node) { > > @@ -65,6 +71,9 @@ static int __init xen_guest_init(void) > > pr_debug("Xen version not found\n"); > > return 0; > > } > > + if (of_address_to_resource(node, GRANT_TABLE_PHYSADDR, &res)) > > + return 0; > > + xen_hvm_resume_frames = res.start >> PAGE_SHIFT; > > xen_domain_type = XEN_HVM_DOMAIN; > > > > xen_setup_features(); > > @@ -98,6 +107,11 @@ static int __init xen_guest_init(void) > > * is required to use VCPUOP_register_vcpu_info to place vcpu info > > * for secondary CPUs as they are brought up. */ > > per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0]; > > + > > + gnttab_init(); > > + if (!xen_initial_domain()) > > + xenbus_probe(NULL); > > + > > return 0; > > } > > core_initcall(xen_guest_init); > > -- > > 1.7.2.5 >
On Fri, 2012-09-14 at 15:56 +0100, Stefano Stabellini wrote: > On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote: > > On Fri, Sep 14, 2012 at 12:13:16PM +0100, Stefano Stabellini wrote: > > > Initialize the grant table mapping at the address specified at index 0 > > > in the DT under the /xen node. > > > After the grant table is initialized, call xenbus_probe (if not dom0). > > > > So we don't really care about the grant's size then? The DT xen.txt > > talks about it.. > > I am assuming that the size of the memory region specified in the device > tree is sufficiently large to map the entire grant table, given that both > the device tree hypervisor entry and the grant table size comes from Xen. Actually, the grant table can grow dynamically under the control of the guest, I think you just pass GNTTABOP_setup_table with some more frames. See drivers/xen/grant_table.c:gnttab_expand(). > The grant table size is currently queried to Xen directly via an > hypercall (GNTTABOP_query_size). Basically the size in the device tree > is redundant information. This size is the size of the physical address space where the guest could chose map grant table frames. It could be either larger or smaller than the actual grant table. (smaller because the guest could use physical addresses not within this region, if it wanted to for some reason). Ian.
On Fri, 14 Sep 2012, Ian Campbell wrote: > On Fri, 2012-09-14 at 15:56 +0100, Stefano Stabellini wrote: > > On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote: > > > On Fri, Sep 14, 2012 at 12:13:16PM +0100, Stefano Stabellini wrote: > > > > Initialize the grant table mapping at the address specified at index 0 > > > > in the DT under the /xen node. > > > > After the grant table is initialized, call xenbus_probe (if not dom0). > > > > > > So we don't really care about the grant's size then? The DT xen.txt > > > talks about it.. > > > > I am assuming that the size of the memory region specified in the device > > tree is sufficiently large to map the entire grant table, given that both > > the device tree hypervisor entry and the grant table size comes from Xen. > > Actually, the grant table can grow dynamically under the control of the > guest, I think you just pass GNTTABOP_setup_table with some more frames. > See drivers/xen/grant_table.c:gnttab_expand(). gnttab_expand can return error if the new size exceeds gnttab_max_grant_frames(), that is implemented using GNTTABOP_query_size. > > The grant table size is currently queried to Xen directly via an > > hypercall (GNTTABOP_query_size). Basically the size in the device tree > > is redundant information. > > This size is the size of the physical address space where the guest > could chose map grant table frames. It could be either larger or smaller > than the actual grant table. (smaller because the guest could use > physical addresses not within this region, if it wanted to for some > reason). Right. What I am saying is that I assume that the memory region specified in the device tree is greater or equal than gnttab_max_grant_frames(). Maybe I should add this to the device tree doc.
On Fri, 2012-09-14 at 16:29 +0100, Stefano Stabellini wrote: > On Fri, 14 Sep 2012, Ian Campbell wrote: > > On Fri, 2012-09-14 at 15:56 +0100, Stefano Stabellini wrote: > > > On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote: > > > > On Fri, Sep 14, 2012 at 12:13:16PM +0100, Stefano Stabellini wrote: > > > > > Initialize the grant table mapping at the address specified at index 0 > > > > > in the DT under the /xen node. > > > > > After the grant table is initialized, call xenbus_probe (if not dom0). > > > > > > > > So we don't really care about the grant's size then? The DT xen.txt > > > > talks about it.. > > > > > > I am assuming that the size of the memory region specified in the device > > > tree is sufficiently large to map the entire grant table, given that both > > > the device tree hypervisor entry and the grant table size comes from Xen. > > > > Actually, the grant table can grow dynamically under the control of the > > guest, I think you just pass GNTTABOP_setup_table with some more frames. > > See drivers/xen/grant_table.c:gnttab_expand(). > > gnttab_expand can return error if the new size exceeds > gnttab_max_grant_frames(), that is implemented using > GNTTABOP_query_size. I hadn't spotted / wasn't aware that this gives you the max too. > > > The grant table size is currently queried to Xen directly via an > > > hypercall (GNTTABOP_query_size). Basically the size in the device tree > > > is redundant information. > > > > This size is the size of the physical address space where the guest > > could chose map grant table frames. It could be either larger or smaller > > than the actual grant table. (smaller because the guest could use > > physical addresses not within this region, if it wanted to for some > > reason). > > Right. > > What I am saying is that I assume that the memory region specified in > the device tree is greater or equal than gnttab_max_grant_frames(). Makes sense. (note that gnttab_max_grant_frames can be set on the hypervisor command line though) > Maybe I should add this to the device tree doc. No harm in being explicit.
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c index c2a47a7..036a4d8 100644 --- a/arch/arm/xen/enlighten.c +++ b/arch/arm/xen/enlighten.c @@ -1,8 +1,12 @@ #include <xen/xen.h> +#include <xen/grant_table.h> +#include <xen/hvm.h> #include <xen/interface/xen.h> #include <xen/interface/memory.h> +#include <xen/interface/hvm/params.h> #include <xen/features.h> #include <xen/platform_pci.h> +#include <xen/xenbus.h> #include <asm/xen/hypervisor.h> #include <asm/xen/hypercall.h> #include <linux/module.h> @@ -42,6 +46,7 @@ EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range); * see Documentation/devicetree/bindings/arm/xen.txt for the * documentation of the Xen Device Tree format. */ +#define GRANT_TABLE_PHYSADDR 0 static int __init xen_guest_init(void) { struct xen_add_to_physmap xatp; @@ -51,6 +56,7 @@ static int __init xen_guest_init(void) const char *s = NULL; const char *version = NULL; const char *xen_prefix = "xen,xen-"; + struct resource res; node = of_find_compatible_node(NULL, NULL, "xen,xen"); if (!node) { @@ -65,6 +71,9 @@ static int __init xen_guest_init(void) pr_debug("Xen version not found\n"); return 0; } + if (of_address_to_resource(node, GRANT_TABLE_PHYSADDR, &res)) + return 0; + xen_hvm_resume_frames = res.start >> PAGE_SHIFT; xen_domain_type = XEN_HVM_DOMAIN; xen_setup_features(); @@ -98,6 +107,11 @@ static int __init xen_guest_init(void) * is required to use VCPUOP_register_vcpu_info to place vcpu info * for secondary CPUs as they are brought up. */ per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0]; + + gnttab_init(); + if (!xen_initial_domain()) + xenbus_probe(NULL); + return 0; } core_initcall(xen_guest_init);
Initialize the grant table mapping at the address specified at index 0 in the DT under the /xen node. After the grant table is initialized, call xenbus_probe (if not dom0). Changes in v2: - introduce GRANT_TABLE_PHYSADDR; - remove unneeded initialization of boot_max_nr_grant_frames. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> --- arch/arm/xen/enlighten.c | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-)