Re: [Xen-devel] [PATCH] xen/arm: bootfdt: Use proper default for #address-cells and #size-cells
On Wed, 29 Nov 2017, Julien Grall wrote: > Per the device-tree specific [1], when the property #address-cells > and #size-cells are not present, the default value should be resp. 1 > and 2. > > [1] > https://www.devicetree.org/downloads/devicetree-specification-v0.1-20160524.pdf > > Signed-off-by: Julien Grall Acked-by: Stefano Stabellini > --- > > This was discovered debugging DT generated by GRUB on ACPI-only > platform. I am not aware of any DT relying on that for now, but it > would still be nice to be compliant with the spec and avoid > surprise. > --- > xen/arch/arm/bootfdt.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c > index 4a687e725d..8eba42c7b9 100644 > --- a/xen/arch/arm/bootfdt.c > +++ b/xen/arch/arm/bootfdt.c > @@ -109,8 +109,8 @@ int __init device_tree_for_each_node(const void *fdt, > continue; > } > > -as = depth > 0 ? address_cells[depth-1] : 0; > -ss = depth > 0 ? size_cells[depth-1] : 0; > +as = depth > 0 ? address_cells[depth-1] : > DT_ROOT_NODE_ADDR_CELLS_DEFAULT; > +ss = depth > 0 ? size_cells[depth-1] : > DT_ROOT_NODE_SIZE_CELLS_DEFAULT; > > address_cells[depth] = device_tree_get_u32(fdt, node, > "#address-cells", as); > -- > 2.11.0 > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] gnttab: correct GNTTABOP_cache_flush empty batch handling
On Thu, 30 Nov 2017, Jan Beulich wrote:
> Jann validly points out that with a caller bogusly requesting a zero-
> element batch with non-zero high command bits (the ones used for
> continuation encoding), the assertion right before the call to
> hypercall_create_continuation() would trigger. A similar situation would
> arise afaict for non-empty batches with op and/or length zero in every
> element.
>
> While we want the former to succeed (as we do elsewhere for similar
> no-op requests), the latter can clearly be converted to an error, as
> this is a state that can't be the result of a prior operation.
>
> Take the opportunity and also correct the order of argument checks:
> We shouldn't accept zero-length elements with unknown bits set in "op".
> Also constify cache_flush()'s first parameter.
>
> Reported-by: Jann Horn
> Signed-off-by: Jan Beulich
Acked-by: Stefano Stabellini
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -3208,7 +3208,7 @@ gnttab_swap_grant_ref(XEN_GUEST_HANDLE_P
> return 0;
> }
>
> -static int cache_flush(gnttab_cache_flush_t *cflush, grant_ref_t *cur_ref)
> +static int cache_flush(const gnttab_cache_flush_t *cflush, grant_ref_t
> *cur_ref)
> {
> struct domain *d, *owner;
> struct page_info *page;
> @@ -3218,19 +3218,17 @@ static int cache_flush(gnttab_cache_flus
>
> if ( (cflush->offset >= PAGE_SIZE) ||
> (cflush->length > PAGE_SIZE) ||
> - (cflush->offset + cflush->length > PAGE_SIZE) )
> + (cflush->offset + cflush->length > PAGE_SIZE) ||
> + (cflush->op & ~(GNTTAB_CACHE_INVAL | GNTTAB_CACHE_CLEAN)) )
> return -EINVAL;
>
> if ( cflush->length == 0 || cflush->op == 0 )
> -return 0;
> +return !*cur_ref ? 0 : -EILSEQ;
>
> /* currently unimplemented */
> if ( cflush->op & GNTTAB_CACHE_SOURCE_GREF )
> return -EOPNOTSUPP;
>
> -if ( cflush->op & ~(GNTTAB_CACHE_INVAL|GNTTAB_CACHE_CLEAN) )
> -return -EINVAL;
> -
> d = rcu_lock_current_domain();
> mfn = cflush->a.dev_bus_addr >> PAGE_SHIFT;
>
> @@ -3310,6 +3308,9 @@ gnttab_cache_flush(XEN_GUEST_HANDLE_PARA
> *cur_ref = 0;
> guest_handle_add_offset(uop, 1);
> }
> +
> +*cur_ref = 0;
> +
> return 0;
> }
>
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] gnttab: improve GNTTABOP_cache_flush locking
On Thu, 30 Nov 2017, Jan Beulich wrote:
> Dropping the lock before returning from grant_map_exists() means handing
> possibly stale information back to the caller. Return back the pointer
> to the active entry instead, for the caller to release the lock once
> done.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Stefano Stabellini
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -786,10 +786,10 @@ static int _set_status(unsigned gt_versi
> return _set_status_v2(domid, readonly, mapflag, shah, act, status);
> }
>
> -static int grant_map_exists(const struct domain *ld,
> -struct grant_table *rgt,
> -unsigned long mfn,
> -grant_ref_t *cur_ref)
> +static struct active_grant_entry *grant_map_exists(const struct domain *ld,
> + struct grant_table *rgt,
> + unsigned long mfn,
> + grant_ref_t *cur_ref)
> {
> grant_ref_t ref, max_iter;
>
> @@ -805,28 +805,20 @@ static int grant_map_exists(const struct
> nr_grant_entries(rgt));
> for ( ref = *cur_ref; ref < max_iter; ref++ )
> {
> -struct active_grant_entry *act;
> -bool_t exists;
> -
> -act = active_entry_acquire(rgt, ref);
> -
> -exists = act->pin
> -&& act->domid == ld->domain_id
> -&& act->frame == mfn;
> +struct active_grant_entry *act = active_entry_acquire(rgt, ref);
>
> +if ( act->pin && act->domid == ld->domain_id && act->frame == mfn )
> +return act;
> active_entry_release(act);
> -
> -if ( exists )
> -return 0;
> }
>
> if ( ref < nr_grant_entries(rgt) )
> {
> *cur_ref = ref;
> -return 1;
> +return NULL;
> }
>
> -return -EINVAL;
> +return ERR_PTR(-EINVAL);
> }
>
> #define MAPKIND_READ 1
> @@ -3213,6 +3205,7 @@ static int cache_flush(const gnttab_cach
> struct domain *d, *owner;
> struct page_info *page;
> unsigned long mfn;
> +struct active_grant_entry *act = NULL;
> void *v;
> int ret;
>
> @@ -3250,13 +3243,13 @@ static int cache_flush(const gnttab_cach
> {
> grant_read_lock(owner->grant_table);
>
> -ret = grant_map_exists(d, owner->grant_table, mfn, cur_ref);
> -if ( ret != 0 )
> +act = grant_map_exists(d, owner->grant_table, mfn, cur_ref);
> +if ( IS_ERR_OR_NULL(act) )
> {
> grant_read_unlock(owner->grant_table);
> rcu_unlock_domain(d);
> put_page(page);
> -return ret;
> +return act ? PTR_ERR(act) : 1;
> }
> }
>
> @@ -3273,7 +3266,11 @@ static int cache_flush(const gnttab_cach
> ret = 0;
>
> if ( d != owner )
> +{
> +active_entry_release(act);
> grant_read_unlock(owner->grant_table);
> +}
> +
> unmap_domain_page(v);
> put_page(page);
>
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC] WIP: optee: add OP-TEE mediator
On Mon, 27 Nov 2017, Volodymyr Babchuk wrote: > This is follow-up to our conversation during community call. > You asked me to send OP-TEE mediator as a patch, so we can > discuss it in the mailing list. So, there it is. I squashed > two patches into one and skipped patches that we already > discussed. > > So, this is basically all what is needed to support OP-TEE in XEN. > There are some TODOs left all over the code. But, I don't > expect that TODOs implementation would significantly > increase codebase. Currently mediator parses requests to perform > addresses translation and that's all what is should be done > to allow guests to work with OP-TEE. > > This become possible because I completely revisited virtualization > support in OP-TEE. I have found way to enforce complete isolation > between different guest states. This lifts many questions like usage > quotas, RPC routing, sudden guest death, data isolation, etc. > > I'm aware that I didn't addressed all comments from previous > discussion. Sorry for this. I'm currently busy with OP-TEE, > and I think proper mediator implementation will be possible > only after I'll stabilize OP-TEE part. > > So I don't ask anybody to do thorough review. I just want to > share my status and discuss this code a whole. Thank you for sharing! Actually, I think it is not too bad as a starting point. I'll also try to summarize some key concept we have been discussing about OP-TEE support in Xen. = Xen cannot protect the system from a broken/insecure OP-TEE = OP-TEE runs at a higher privilege level than Xen, thus, we can't really expect Xen to protect the system from a broken OP-TEE. Also, Xen cannot really protect OP-TEE from a malicious caller. What we can and should do is to protect Xen, the OP-TEE mediator in Xen specifically, from malicious attackers. In other words, we are not responsible if a call, forwarded to OP-TEE by Xen, ends up crashing OP-TEE, therefore taking down the system. However, we have to pay special care to avoid callers to crash or take over the mediator in Xen. We also have to pay attention so that a caller won't be able to exhaust Xen resources or DOS Xen (allocate too much memory, infinite loops in Xen, etc). This brings me to the next topic. = Error checking / DOS protection = We need powerful checks on arguments passed by the caller and evaluated by the mediator. For example, we cannot expect the guest to actually pass arguments in the format expected by translate_params. ctx->xen_arg could be gibberish. From the resource allocation point of view, it looks like every handle_std_call allocates a new context; every copy_std_request allocates a new Xen page. It would be easy to exhaust Xen resources. Maybe we need a max concurrent request limit or max page allocation per domain or something of the kind. = Locks and Lists = The current lock and list is global. Do you think it should actually be global or per-domain? I do realize that only dom0 is allowed to make calls now so the question for the moment is not too useful. = Xen command forwarding = In the code below, it looks like Xen is forwarding everything to OP-TEE. Are there some commands Xen should avoid forwarding? Should we have a whitelist or a blacklist? = Long running OP-TEE commands and interruptions = I have been told that some OP-TEE RPC commands might take long to complete. Is that right? Like for example one of the OPTEE_MSG_RPC_CMD_*? If so, we need to think what to do in those cases. Specifically, do we need a technique to restart certain commands in Xen, so that when they run for too long and get interrupted by something (such as an interrupt) we know how to restart them? In fact, do we need to setup a timer interrupt to make sure the command doesn't block Xen for too long, consuming the next vcpu's slot as well? = Page pinning = Guest pages passed to OP-TEE need to be pinned (otherwise Xen doesn't guarantee they'll be available). I think the right function to call for that is get_page_from_gfn or get_page. > --- > > Add OP-TEE mediator as an example how TEE mediator framework > works. > > OP-TEE mediator support address translation for DomUs. > It tracks execution of STD calls, correctly handles memory-related RPC > requests, tracks buffer allocated for RPCs. > > With this patch OP-TEE successfully passes own tests, while client is > running in DomU. Currently it lacks some code for exceptional cases, > because this patch was used mostly to debug virtualization in OP-TEE. > Nevertheless, it provides all features needed for OP-TEE mediation. > > WARNING: This is a development patch, it does not cover all corner > cases, so, please don't use it in production. > > It was tested on RCAR Salvator-M3 board. > > Signed-off-by: Volodymyr Babchuk > --- > xen/arch/arm/tee/Kconfig | 4 + > xen/arch/arm/tee/Makefile| 1 + > xen/arch/arm/tee/optee.c | 765 > +++ > xen/arch/arm/tee/optee_smc.h | 5
Re: [Xen-devel] [RFC PATCH 01/31] cpufreq: move cpufreq.h file to the xen/include/xen location
On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> From: Oleksandr Dmytryshyn
>
> Cpufreq driver should be more generalizable (not ACPI-specific).
> Thus this file should be placed to more convenient location.
>
> This is a rebased version of the original patch:
> https://lists.xen.org/archives/html/xen-devel/2014-11/msg00938.html
>
> Signed-off-by: Oleksandr Dmytryshyn
> Signed-off-by: Oleksandr Tyshchenko
> CC: Jan Beulich
> CC: Andrew Cooper
> CC: Stefano Stabellini
> CC: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> MAINTAINERS | 1 +
> xen/arch/x86/acpi/cpu_idle.c | 2 +-
> xen/arch/x86/acpi/cpufreq/cpufreq.c | 2 +-
> xen/arch/x86/acpi/cpufreq/powernow.c | 2 +-
> xen/arch/x86/acpi/power.c| 2 +-
> xen/arch/x86/cpu/mwait-idle.c| 2 +-
> xen/drivers/acpi/pmstat.c| 2 +-
> xen/drivers/cpufreq/cpufreq.c| 2 +-
> xen/drivers/cpufreq/cpufreq_misc_governors.c | 2 +-
> xen/drivers/cpufreq/cpufreq_ondemand.c | 4 +-
> xen/drivers/cpufreq/utility.c| 2 +-
> xen/include/acpi/cpufreq/cpufreq.h | 245 --
> xen/include/xen/cpufreq.h| 248
> +++
> 13 files changed, 260 insertions(+), 256 deletions(-)
> delete mode 100644 xen/include/acpi/cpufreq/cpufreq.h
> create mode 100644 xen/include/xen/cpufreq.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5b9e123..524e067 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -295,6 +295,7 @@ X:xen/arch/x86/acpi/boot.c
> X: xen/arch/x86/acpi/lib.c
> F: xen/drivers/cpufreq/
> F: xen/include/acpi/cpufreq/
> +F: xen/include/xen/cpufreq.h
>
> PUBLIC I/O INTERFACES AND PV DRIVERS DESIGNS
> M: Konrad Rzeszutek Wilk
> diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
> index 482b8a7..c66622e 100644
> --- a/xen/arch/x86/acpi/cpu_idle.c
> +++ b/xen/arch/x86/acpi/cpu_idle.c
> @@ -49,7 +49,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
> diff --git a/xen/arch/x86/acpi/cpufreq/cpufreq.c
> b/xen/arch/x86/acpi/cpufreq/cpufreq.c
> index 1f8d02a..bd82025 100644
> --- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
> +++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
> @@ -41,7 +41,7 @@
> #include
> #include
> #include
> -#include
> +#include
>
> enum {
> UNDEFINED_CAPABLE = 0,
> diff --git a/xen/arch/x86/acpi/cpufreq/powernow.c
> b/xen/arch/x86/acpi/cpufreq/powernow.c
> index 8f1ac74..79f55a3 100644
> --- a/xen/arch/x86/acpi/cpufreq/powernow.c
> +++ b/xen/arch/x86/acpi/cpufreq/powernow.c
> @@ -35,7 +35,7 @@
> #include
> #include
> #include
> -#include
> +#include
>
> #define CPUID_FREQ_VOLT_CAPABILITIES0x8007
> #define CPB_CAPABLE 0x0200
> diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
> index 1e4e568..beebd5a 100644
> --- a/xen/arch/x86/acpi/power.c
> +++ b/xen/arch/x86/acpi/power.c
> @@ -28,7 +28,7 @@
> #include
> #include
> #include
> -#include
> +#include
>
> uint32_t system_reset_counter = 1;
>
> diff --git a/xen/arch/x86/cpu/mwait-idle.c b/xen/arch/x86/cpu/mwait-idle.c
> index 762dff1..29f0286 100644
> --- a/xen/arch/x86/cpu/mwait-idle.c
> +++ b/xen/arch/x86/cpu/mwait-idle.c
> @@ -58,7 +58,7 @@
> #include
> #include
> #include
> -#include
> +#include
>
> #define MWAIT_IDLE_VERSION "0.4.1"
> #undef PREFIX
> diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/acpi/pmstat.c
> index 2a6c4c7..2dbde1c 100644
> --- a/xen/drivers/acpi/pmstat.c
> +++ b/xen/drivers/acpi/pmstat.c
> @@ -38,7 +38,7 @@
> #include
>
> #include
> -#include
> +#include
> #include
>
> DEFINE_PER_CPU_READ_MOSTLY(struct pm_px *, cpufreq_statistic_data);
> diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
> index 212f48f..ab909e2 100644
> --- a/xen/drivers/cpufreq/cpufreq.c
> +++ b/xen/drivers/cpufreq/cpufreq.c
> @@ -43,7 +43,7 @@
> #include
> #include
> #include
> -#include
> +#include
>
> static unsigned int __read_mostly usr_min_freq;
> static unsigned int __read_mostly usr_max_freq;
> diff --git a/xen/drivers/cpufreq/cpufreq_misc_governors.c
> b/xen/drivers/cpufreq/cpufreq_misc_governors.c
> index 746bbcd..4a5510c 100644
> --- a/xen/drivers/cpufreq/cpufreq_misc_governors.c
> +++ b/xen/drivers/cpufreq/cpufreq_misc_governors.c
> @@ -18,7 +18,7 @@
> #incl
Re: [Xen-devel] [RFC PATCH 02/31] pm: move processor_perf.h file to the xen/include/xen location
On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> From: Oleksandr Dmytryshyn
>
> Cpufreq driver should be more generalizable (not ACPI-specific).
> Thus this file should be placed to more convenient location.
>
> This is a rebased version of the original patch:
> https://lists.xen.org/archives/html/xen-devel/2014-11/msg00934.html
>
> Signed-off-by: Oleksandr Dmytryshyn
> Signed-off-by: Oleksandr Tyshchenko
> CC: Jan Beulich
> CC: Andrew Cooper
> CC: Stefano Stabellini
> CC: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> MAINTAINERS | 2 +-
> xen/arch/x86/platform_hypercall.c | 2 +-
> xen/include/acpi/cpufreq/processor_perf.h | 63
> ---
> xen/include/xen/cpufreq.h | 2 +-
> xen/include/xen/processor_perf.h | 63
> +++
> 5 files changed, 66 insertions(+), 66 deletions(-)
> delete mode 100644 xen/include/acpi/cpufreq/processor_perf.h
> create mode 100644 xen/include/xen/processor_perf.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 524e067..9794a81 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -294,8 +294,8 @@ F:xen/arch/x86/acpi/
> X: xen/arch/x86/acpi/boot.c
> X: xen/arch/x86/acpi/lib.c
> F: xen/drivers/cpufreq/
> -F: xen/include/acpi/cpufreq/
> F: xen/include/xen/cpufreq.h
> +F: xen/include/xen/processor_perf.h
>
> PUBLIC I/O INTERFACES AND PV DRIVERS DESIGNS
> M: Konrad Rzeszutek Wilk
> diff --git a/xen/arch/x86/platform_hypercall.c
> b/xen/arch/x86/platform_hypercall.c
> index ebc2f39..17c8304 100644
> --- a/xen/arch/x86/platform_hypercall.c
> +++ b/xen/arch/x86/platform_hypercall.c
> @@ -25,7 +25,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
> diff --git a/xen/include/acpi/cpufreq/processor_perf.h
> b/xen/include/acpi/cpufreq/processor_perf.h
> deleted file mode 100644
> index d8a1ba6..000
> --- a/xen/include/acpi/cpufreq/processor_perf.h
> +++ /dev/null
> @@ -1,63 +0,0 @@
> -#ifndef __XEN_PROCESSOR_PM_H__
> -#define __XEN_PROCESSOR_PM_H__
> -
> -#include
> -#include
> -#include
> -
> -#define XEN_PX_INIT 0x8000
> -
> -int powernow_cpufreq_init(void);
> -unsigned int powernow_register_driver(void);
> -unsigned int get_measured_perf(unsigned int cpu, unsigned int flag);
> -void cpufreq_residency_update(unsigned int, uint8_t);
> -void cpufreq_statistic_update(unsigned int, uint8_t, uint8_t);
> -int cpufreq_statistic_init(unsigned int);
> -void cpufreq_statistic_exit(unsigned int);
> -void cpufreq_statistic_reset(unsigned int);
> -
> -int cpufreq_limit_change(unsigned int);
> -
> -int cpufreq_add_cpu(unsigned int);
> -int cpufreq_del_cpu(unsigned int);
> -
> -struct processor_performance {
> -uint32_t state;
> -uint32_t platform_limit;
> -struct xen_pct_register control_register;
> -struct xen_pct_register status_register;
> -uint32_t state_count;
> -struct xen_processor_px *states;
> -struct xen_psd_package domain_info;
> -uint32_t shared_type;
> -
> -uint32_t init;
> -};
> -
> -struct processor_pminfo {
> -uint32_t acpi_id;
> -uint32_t id;
> -struct processor_performanceperf;
> -};
> -
> -extern struct processor_pminfo *processor_pminfo[NR_CPUS];
> -
> -struct px_stat {
> -uint8_t total;/* total Px states */
> -uint8_t usable; /* usable Px states */
> -uint8_t last; /* last Px state */
> -uint8_t cur; /* current Px state */
> -uint64_t *trans_pt; /* Px transition table */
> -pm_px_val_t *pt;
> -};
> -
> -struct pm_px {
> -struct px_stat u;
> -uint64_t prev_state_wall;
> -uint64_t prev_idle_wall;
> -};
> -
> -DECLARE_PER_CPU(struct pm_px *, cpufreq_statistic_data);
> -
> -int cpufreq_cpu_init(unsigned int cpuid);
> -#endif /* __XEN_PROCESSOR_PM_H__ */
> diff --git a/xen/include/xen/cpufreq.h b/xen/include/xen/cpufreq.h
> index ed38a6c..30c70c9 100644
> --- a/xen/include/xen/cpufreq.h
> +++ b/xen/include/xen/cpufreq.h
> @@ -21,7 +21,7 @@
> #include
> #include
>
> -#include
> +#include
>
> DECLARE_PER_CPU(spinlock_t, cpufreq_statistic_lock);
>
> diff --git a/xen/include/xen/processor_perf.h
> b/xen/include/xen/processor_perf.h
> new file mode 100644
> index 000..d8a1ba6
> --- /dev/null
> +++ b/xen/include/xen/processor_perf.h
> @@ -0,0 +1,63 @@
> +#ifndef __XEN_PROCESSOR_PM_H__
> +#define __XEN_PROCESSOR_PM_H__
> +
> +#include
> +#include
> +#include
> +
Re: [Xen-devel] [RFC PATCH 03/31] pmstat: move pmstat.c file to the xen/drivers/pm/stat.c location
On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote: > From: Oleksandr Dmytryshyn > > Cpufreq driver should be more generalizable (not ACPI-specific). > Thus this file should be placed to more convenient location. > > This is a rebased version of the original patch: > https://lists.xen.org/archives/html/xen-devel/2014-11/msg00935.html > > Signed-off-by: Oleksandr Dmytryshyn > Signed-off-by: Oleksandr Tyshchenko > CC: Jan Beulich > CC: Andrew Cooper > CC: Stefano Stabellini > CC: Julien Grall Reviewed-by: Stefano Stabellini > --- > MAINTAINERS | 1 + > xen/arch/x86/Kconfig | 1 + > xen/common/sysctl.c | 2 +- > xen/drivers/Kconfig | 2 + > xen/drivers/Makefile | 1 + > xen/drivers/acpi/Makefile | 1 - > xen/drivers/acpi/pmstat.c | 526 > -- > xen/drivers/pm/Kconfig| 3 + > xen/drivers/pm/Makefile | 1 + > xen/drivers/pm/stat.c | 526 > ++ > 10 files changed, 536 insertions(+), 528 deletions(-) > delete mode 100644 xen/drivers/acpi/pmstat.c > create mode 100644 xen/drivers/pm/Kconfig > create mode 100644 xen/drivers/pm/Makefile > create mode 100644 xen/drivers/pm/stat.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index 9794a81..87ade6f 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -294,6 +294,7 @@ F:xen/arch/x86/acpi/ > X: xen/arch/x86/acpi/boot.c > X: xen/arch/x86/acpi/lib.c > F: xen/drivers/cpufreq/ > +F: xen/drivers/pm/ > F: xen/include/xen/cpufreq.h > F: xen/include/xen/processor_perf.h > > diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig > index 30c2769..86c8eca 100644 > --- a/xen/arch/x86/Kconfig > +++ b/xen/arch/x86/Kconfig > @@ -23,6 +23,7 @@ config X86 > select HAS_PDX > select NUMA > select VGA > + select HAS_PM > > config ARCH_DEFCONFIG > string > diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c > index a6882d1..ac96347 100644 > --- a/xen/common/sysctl.c > +++ b/xen/common/sysctl.c > @@ -171,7 +171,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) > u_sysctl) > op->u.availheap.avail_bytes <<= PAGE_SHIFT; > break; > > -#if defined (CONFIG_ACPI) && defined (CONFIG_HAS_CPUFREQ) > +#if defined (CONFIG_HAS_PM) && defined (CONFIG_HAS_CPUFREQ) > case XEN_SYSCTL_get_pmstat: > ret = do_get_pm_info(&op->u.get_pmstat); > break; > diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig > index bc3a54f..ddaec11 100644 > --- a/xen/drivers/Kconfig > +++ b/xen/drivers/Kconfig > @@ -12,4 +12,6 @@ source "drivers/pci/Kconfig" > > source "drivers/video/Kconfig" > > +source "drivers/pm/Kconfig" > + > endmenu > diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile > index 1939180..dd0b496 100644 > --- a/xen/drivers/Makefile > +++ b/xen/drivers/Makefile > @@ -4,3 +4,4 @@ subdir-$(CONFIG_HAS_PCI) += pci > subdir-$(CONFIG_HAS_PASSTHROUGH) += passthrough > subdir-$(CONFIG_ACPI) += acpi > subdir-$(CONFIG_VIDEO) += video > +subdir-$(CONFIG_HAS_PM) += pm > diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile > index 444b11d..6f6470a 100644 > --- a/xen/drivers/acpi/Makefile > +++ b/xen/drivers/acpi/Makefile > @@ -5,7 +5,6 @@ subdir-$(CONFIG_X86) += apei > obj-bin-y += tables.init.o > obj-$(CONFIG_NUMA) += numa.o > obj-y += osl.o > -obj-$(CONFIG_HAS_CPUFREQ) += pmstat.o > > obj-$(CONFIG_X86) += hwregs.o > obj-$(CONFIG_X86) += reboot.o > diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/acpi/pmstat.c > deleted file mode 100644 > index 2dbde1c..000 > --- a/xen/drivers/acpi/pmstat.c > +++ /dev/null > @@ -1,526 +0,0 @@ > -/* > -# pmstat.c - Power Management statistic information (Px/Cx/Tx, etc.) > -# > -# Copyright (c) 2008, Liu Jinsong > -# > -# This program is free software; you can redistribute it and/or modify it > -# under the terms of the GNU General Public License as published by the Free > -# Software Foundation; either version 2 of the License, or (at your option) > -# any later version. > -# > -# This program is distributed in the hope that it will be useful, but > WITHOUT > -# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for > -# more details. > -# > -# You should have received a copy of the GNU General Public License along > with > -# this program; If not, see
Re: [Xen-devel] [RFC PATCH 04/31] cpufreq: make turbo settings to be configurable
On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> From: Oleksandr Dmytryshyn
>
> This settings is not needed for some architectures.
> So make it to be configurable and use it for x86
> architecture.
>
> This is a rebased version of the original patch:
> https://lists.xen.org/archives/html/xen-devel/2014-11/msg00942.html
>
> Signed-off-by: Oleksandr Dmytryshyn
> Signed-off-by: Oleksandr Tyshchenko
> CC: Jan Beulich
> CC: Andrew Cooper
> CC: Stefano Stabellini
> CC: Julien Grall
> ---
> xen/arch/x86/Kconfig | 1 +
> xen/drivers/cpufreq/Kconfig | 3 +++
> xen/drivers/cpufreq/utility.c | 11 ++-
> xen/drivers/pm/stat.c | 6 ++
> xen/include/xen/cpufreq.h | 6 ++
> 5 files changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> index 86c8eca..c1eac1d 100644
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -24,6 +24,7 @@ config X86
> select NUMA
> select VGA
> select HAS_PM
> + select HAS_CPU_TURBO
>
> config ARCH_DEFCONFIG
> string
> diff --git a/xen/drivers/cpufreq/Kconfig b/xen/drivers/cpufreq/Kconfig
> index cce80f4..427ea2a 100644
> --- a/xen/drivers/cpufreq/Kconfig
> +++ b/xen/drivers/cpufreq/Kconfig
> @@ -1,3 +1,6 @@
>
> config HAS_CPUFREQ
> bool
> +
> +config HAS_CPU_TURBO
> + bool
> diff --git a/xen/drivers/cpufreq/utility.c b/xen/drivers/cpufreq/utility.c
> index a687e5a..25bf983 100644
> --- a/xen/drivers/cpufreq/utility.c
> +++ b/xen/drivers/cpufreq/utility.c
> @@ -209,7 +209,9 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy
> *policy,
> {
> unsigned int min_freq = ~0;
> unsigned int max_freq = 0;
> +#ifdef CONFIG_HAS_CPU_TURBO
> unsigned int second_max_freq = 0;
> +#endif
> unsigned int i;
>
> for (i=0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
> @@ -221,6 +223,7 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy
> *policy,
> if (freq > max_freq)
> max_freq = freq;
> }
> +#ifdef CONFIG_HAS_CPU_TURBO
> for (i=0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
> unsigned int freq = table[i].frequency;
> if (freq == CPUFREQ_ENTRY_INVALID || freq == max_freq)
> @@ -234,9 +237,13 @@ int cpufreq_frequency_table_cpuinfo(struct
> cpufreq_policy *policy,
> printk("max_freq: %usecond_max_freq: %u\n",
> max_freq, second_max_freq);
>
> +policy->cpuinfo.second_max_freq = second_max_freq;
> +#else /* !CONFIG_HAS_CPU_TURBO */
> +if (cpufreq_verbose)
> +printk("max_freq: %u\n", max_freq);
> +#endif /* CONFIG_HAS_CPU_TURBO */
> policy->min = policy->cpuinfo.min_freq = min_freq;
> policy->max = policy->cpuinfo.max_freq = max_freq;
> -policy->cpuinfo.second_max_freq = second_max_freq;
>
> if (policy->min == ~0)
> return -EINVAL;
> @@ -390,6 +397,7 @@ int cpufreq_driver_getavg(unsigned int cpu, unsigned int
> flag)
> return policy->cur;
> }
>
> +#ifdef CONFIG_HAS_CPU_TURBO
> int cpufreq_update_turbo(int cpuid, int new_state)
> {
> struct cpufreq_policy *policy;
> @@ -430,6 +438,7 @@ int cpufreq_get_turbo_status(int cpuid)
> policy = per_cpu(cpufreq_cpu_policy, cpuid);
> return policy && policy->turbo == CPUFREQ_TURBO_ENABLED;
> }
> +#endif /* CONFIG_HAS_CPU_TURBO */
>
> /*
> * POLICY*
I am wondering if we need to go as far as #ifdef'ing
cpufreq_update_turbo. For the sake of reducing the number if #ifdef's,
would it be enough if we only make sure it is disabled?
In other words, I would keep the changes to stat.c but I would leave
utility.c and cpufreq.h pretty much untouched.
> diff --git a/xen/drivers/pm/stat.c b/xen/drivers/pm/stat.c
> index 2dbde1c..133e64d 100644
> --- a/xen/drivers/pm/stat.c
> +++ b/xen/drivers/pm/stat.c
> @@ -290,7 +290,11 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
> &op->u.get_para.u.ondemand.sampling_rate,
> &op->u.get_para.u.ondemand.up_threshold);
> }
> +#ifdef CONFIG_HAS_CPU_TURBO
> op->u.get_para.turbo_enabled = cpufreq_get_turbo_status(op->cpuid);
> +#else
> +op->u.get_para.turbo_enabled = 0;
> +#endif
>
> return ret;
> }
> @@ -473,6 +477,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
> break;
> }
>
> +#ifdef CONFIG_HAS_CPU_TURBO
> cas
Re: [Xen-devel] [RFC PATCH 05/31] pmstat: make pmstat functions more generalizable
On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> From: Oleksandr Dmytryshyn
>
> ACPI-specific parts are moved under appropriate ifdefs.
> Now pmstat functions can be used in ARM platform.
>
> This is a rebased version of the original patch:
> https://lists.xen.org/archives/html/xen-devel/2014-11/msg00941.html
My first maybe naive question is: why do we want to disable the C-states
and not the P-states? After all, they are both defined in ACPI?
The second question is: instead of #ifdef'ing everything C-states,
couldn't we just rely on XEN_PROCESSOR_PM_CX not being available?
> Signed-off-by: Oleksandr Dmytryshyn
> Signed-off-by: Oleksandr Tyshchenko
> CC: Jan Beulich
> CC: Andrew Cooper
> CC: Stefano Stabellini
> CC: Julien Grall
> ---
> xen/drivers/pm/stat.c| 8 +++-
> xen/include/xen/pmstat.h | 2 ++
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/xen/drivers/pm/stat.c b/xen/drivers/pm/stat.c
> index 133e64d..986ba41 100644
> --- a/xen/drivers/pm/stat.c
> +++ b/xen/drivers/pm/stat.c
> @@ -35,7 +35,6 @@
> #include
> #include
> #include
> -#include
>
> #include
> #include
> @@ -132,6 +131,8 @@ int do_get_pm_info(struct xen_sysctl_get_pmstat *op)
> break;
> }
>
> +/* For now those operations can be used only when ACPI is enabled */
> +#ifdef CONFIG_ACPI
> case PMSTAT_get_max_cx:
> {
> op->u.getcx.nr = pmstat_get_cx_nr(op->cpuid);
> @@ -150,6 +151,7 @@ int do_get_pm_info(struct xen_sysctl_get_pmstat *op)
> ret = pmstat_reset_cx_stat(op->cpuid);
> break;
> }
> +#endif /* CONFIG_ACPI */
>
> default:
> printk("not defined sub-hypercall @ do_get_pm_info\n");
> @@ -465,6 +467,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
> break;
> }
>
> +#ifdef CONFIG_ACPI
> case XEN_SYSCTL_pm_op_get_max_cstate:
> {
> op->u.get_max_cstate = acpi_get_cstate_limit();
> @@ -476,6 +479,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
> acpi_set_cstate_limit(op->u.set_max_cstate);
> break;
> }
> +#endif /* CONFIG_ACPI */
>
> #ifdef CONFIG_HAS_CPU_TURBO
> case XEN_SYSCTL_pm_op_enable_turbo:
> @@ -500,6 +504,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
> return ret;
> }
>
> +#ifdef CONFIG_ACPI
> int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE_PARAM(uint32) pdc)
> {
> u32 bits[3];
> @@ -530,3 +535,4 @@ int acpi_set_pdc_bits(u32 acpi_id,
> XEN_GUEST_HANDLE_PARAM(uint32) pdc)
>
> return ret;
> }
> +#endif /* CONFIG_ACPI */
> diff --git a/xen/include/xen/pmstat.h b/xen/include/xen/pmstat.h
> index 266bc16..a870c8a 100644
> --- a/xen/include/xen/pmstat.h
> +++ b/xen/include/xen/pmstat.h
> @@ -6,10 +6,12 @@
> #include/* for struct pm_cx_stat */
>
> int set_px_pminfo(uint32_t cpu, struct xen_processor_performance *perf);
> +#ifdef CONFIG_ACPI
> long set_cx_pminfo(uint32_t cpu, struct xen_processor_power *power);
> uint32_t pmstat_get_cx_nr(uint32_t cpuid);
> int pmstat_get_cx_stat(uint32_t cpuid, struct pm_cx_stat *stat);
> int pmstat_reset_cx_stat(uint32_t cpuid);
> +#endif
>
> int do_get_pm_info(struct xen_sysctl_get_pmstat *op);
> int do_pm_op(struct xen_sysctl_pm_op *op);
> --
> 2.7.4
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH 07/31] xenpm: Clarify xenpm usage
On Thu, 9 Nov 2017, Wei Liu wrote: > On Thu, Nov 09, 2017 at 07:09:57PM +0200, Oleksandr Tyshchenko wrote: > > From: Oleksandr Tyshchenko > > > > CPU frequencies are in kHz. So, correct displayed text. > > > > Signed-off-by: Oleksandr Tyshchenko > > CC: Ian Jackson > > CC: Wei Liu > > CC: Stefano Stabellini > > CC: Julien Grall > > --- > > tools/misc/xenpm.c | 6 +++--- > > Acked-by: Wei Liu Acked-by: Stefano Stabellini ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH 06/31] cpufreq: make cpufreq driver more generalizable
On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> From: Oleksandr Dmytryshyn
>
> First implementation of the cpufreq driver has been
> written with x86 in mind. This patch makes possible
> the cpufreq driver be working on both x86 and arm
> architectures.
>
> This is a rebased version of the original patch:
> https://lists.xen.org/archives/html/xen-devel/2014-11/msg00932.html
>
> Signed-off-by: Oleksandr Dmytryshyn
> Signed-off-by: Oleksandr Tyshchenko
> CC: Jan Beulich
> CC: Andrew Cooper
> CC: Stefano Stabellini
> CC: Julien Grall
> ---
> xen/drivers/cpufreq/cpufreq.c| 81
> +---
> xen/include/public/platform.h| 1 +
> xen/include/xen/processor_perf.h | 6 +++
> 3 files changed, 82 insertions(+), 6 deletions(-)
>
> diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
> index ab909e2..64e1ae7 100644
> --- a/xen/drivers/cpufreq/cpufreq.c
> +++ b/xen/drivers/cpufreq/cpufreq.c
> @@ -42,7 +42,6 @@
> #include
> #include
> #include
> -#include
> #include
>
> static unsigned int __read_mostly usr_min_freq;
> @@ -206,6 +205,7 @@ int cpufreq_add_cpu(unsigned int cpu)
> } else {
> /* domain sanity check under whatever coordination type */
> firstcpu = cpumask_first(cpufreq_dom->map);
> +#ifdef CONFIG_ACPI
> if ((perf->domain_info.coord_type !=
> processor_pminfo[firstcpu]->perf.domain_info.coord_type) ||
> (perf->domain_info.num_processors !=
> @@ -221,6 +221,19 @@ int cpufreq_add_cpu(unsigned int cpu)
> );
> return -EINVAL;
> }
> +#else /* !CONFIG_ACPI */
> +if ((perf->domain_info.num_processors !=
> +processor_pminfo[firstcpu]->perf.domain_info.num_processors)) {
> +
> +printk(KERN_WARNING "cpufreq fail to add CPU%d:"
> + "incorrect num processors (%"PRIu64"), "
> + "expect(%"PRIu64")\n",
> + cpu, perf->domain_info.num_processors,
> +
> processor_pminfo[firstcpu]->perf.domain_info.num_processors
> +);
> +return -EINVAL;
> +}
> +#endif /* CONFIG_ACPI */
Why is this necessary? I am asking this question, because I think it
would be best to avoid more #ifdef's if we can avoid them, and some of
the code #ifdef'ed doesn't look very acpi specific (at least at first
sight). It doesn't look like this change is very beneficial. What am I
missing?
> }
>
> if (!domexist || hw_all) {
> @@ -380,6 +393,7 @@ int cpufreq_del_cpu(unsigned int cpu)
> return 0;
> }
>
> +#ifdef CONFIG_ACPI
> static void print_PCT(struct xen_pct_register *ptr)
> {
> printk("\t_PCT: descriptor=%d, length=%d, space_id=%d, "
> @@ -387,12 +401,14 @@ static void print_PCT(struct xen_pct_register *ptr)
> ptr->descriptor, ptr->length, ptr->space_id, ptr->bit_width,
> ptr->bit_offset, ptr->reserved, ptr->address);
> }
> +#endif /* CONFIG_ACPI */
same question
> static void print_PSS(struct xen_processor_px *ptr, int count)
> {
> int i;
> printk("\t_PSS: state_count=%d\n", count);
> for (i=0; i +#ifdef CONFIG_ACPI
> printk("\tState%d: %"PRId64"MHz %"PRId64"mW %"PRId64"us "
> "%"PRId64"us %#"PRIx64" %#"PRIx64"\n",
> i,
> @@ -402,15 +418,26 @@ static void print_PSS(struct xen_processor_px *ptr, int
> count)
> ptr[i].bus_master_latency,
> ptr[i].control,
> ptr[i].status);
> +#else /* !CONFIG_ACPI */
> +printk("\tState%d: %"PRId64"MHz %"PRId64"us\n",
> + i,
> + ptr[i].core_frequency,
> + ptr[i].transition_latency);
> +#endif /* CONFIG_ACPI */
> }
> }
same question
> static void print_PSD( struct xen_psd_package *ptr)
> {
> +#ifdef CONFIG_ACPI
> printk("\t_PSD: num_entries=%"PRId64" rev=%"PRId64
> " domain=%"PRId64" coord_type=%"PRId64"
> num_processors=%"PRId64"\n",
> ptr->num_entries, ptr->revision, ptr->domain, ptr->coord_type,
> ptr->num_processors);
> +#else /* !CONFIG_ACPI */
> +printk("\t_PSD: domain=%"PRId64" num_processors=%"PRId64"\n",
> + ptr->domain, ptr->num_processors);
&g
Re: [Xen-devel] [RFC] WIP: optee: add OP-TEE mediator
On Mon, 4 Dec 2017, Volodymyr Babchuk wrote: > Hi Julien, > > > On Mon, Dec 04, 2017 at 04:27:14PM +, Julien Grall wrote: > > [...] > > >>= Error checking / DOS protection = > > >> > > >>We need powerful checks on arguments passed by the caller and evaluated > > >>by the mediator. > > >> > > >>For example, we cannot expect the guest to actually pass arguments in > > >>the format expected by translate_params. ctx->xen_arg could be > > >>gibberish. > > >Yes. The same arguments stands also for OP-TEE itself. OP-TEE checks > > >validity of arguments and mediator should do the same. Actaully, I > > >implemented this checks in mediator. > > > > > >> From the resource allocation point of view, it looks like every > > >>handle_std_call allocates a new context; every copy_std_request > > >>allocates a new Xen page. It would be easy to exhaust Xen resources. > > >>Maybe we need a max concurrent request limit or max page allocation per > > >>domain or something of the kind. > > >This is a very good point. Thanks. Yes, it is currently missing. > > >Is there any mechanism in XEN to provide quotas? I think, this mediator > > >is not the single entity that allocates memory to handle guest calls? > > > > Most of the time, the memory is either accounted to the guest or only a > > small amount of memory is allocated for a known period of time (the time of > > an hypercall for instance). > Aha, so in my case, I will need to implement own quota mechanism. > I think something like "max_pages", initialized with value from > xenpolicy will be fine. What do you think? Yes, that should work. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC] WIP: optee: add OP-TEE mediator
On Mon, 4 Dec 2017, Volodymyr Babchuk wrote:
> > = Xen command forwarding =
> >
> > In the code below, it looks like Xen is forwarding everything to OP-TEE.
> > Are there some commands Xen should avoid forwarding? Should we have a
> > whitelist or a blacklist?
> My code implements whitelists (at least, I hope so :-) ). It forwards
> only known requests. If it does not know type of the request, it
> returns error back to a caller.
Actually, see below:
> > > +static bool optee_handle_smc(struct cpu_user_regs *regs)
> > > +{
> > > +
> > > +switch ( get_user_reg(regs, 0) )
> > > +{
> > > +case OPTEE_SMC_GET_SHM_CONFIG:
> > > +return handle_get_shm_config(regs);
> > > +case OPTEE_SMC_EXCHANGE_CAPABILITIES:
> > > +return handle_exchange_capabilities(regs);
> > > +case OPTEE_SMC_CALL_WITH_ARG:
> > > +return handle_std_call(regs);
> > > +case OPTEE_SMC_CALL_RETURN_FROM_RPC:
> > > +return handle_rpc(regs);
> > > +default:
> > > +return forward_call(regs);
> > > +}
> > > +return false;
> > > +}
In the unknown ("default") case the smc is still forwarded. Am I missing
anything?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH 04/31] cpufreq: make turbo settings to be configurable
On Sat, 2 Dec 2017, Oleksandr Tyshchenko wrote:
> On Sat, Dec 2, 2017 at 3:06 AM, Stefano Stabellini
> wrote:
> > On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> >> From: Oleksandr Dmytryshyn
> >>
> >> This settings is not needed for some architectures.
> >> So make it to be configurable and use it for x86
> >> architecture.
> >>
> >> This is a rebased version of the original patch:
> >> https://lists.xen.org/archives/html/xen-devel/2014-11/msg00942.html
> >>
> >> Signed-off-by: Oleksandr Dmytryshyn
> >> Signed-off-by: Oleksandr Tyshchenko
> >> CC: Jan Beulich
> >> CC: Andrew Cooper
> >> CC: Stefano Stabellini
> >> CC: Julien Grall
> >> ---
> >> xen/arch/x86/Kconfig | 1 +
> >> xen/drivers/cpufreq/Kconfig | 3 +++
> >> xen/drivers/cpufreq/utility.c | 11 ++-
> >> xen/drivers/pm/stat.c | 6 ++
> >> xen/include/xen/cpufreq.h | 6 ++
> >> 5 files changed, 26 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> >> index 86c8eca..c1eac1d 100644
> >> --- a/xen/arch/x86/Kconfig
> >> +++ b/xen/arch/x86/Kconfig
> >> @@ -24,6 +24,7 @@ config X86
> >> select NUMA
> >> select VGA
> >> select HAS_PM
> >> + select HAS_CPU_TURBO
> >>
> >> config ARCH_DEFCONFIG
> >> string
> >> diff --git a/xen/drivers/cpufreq/Kconfig b/xen/drivers/cpufreq/Kconfig
> >> index cce80f4..427ea2a 100644
> >> --- a/xen/drivers/cpufreq/Kconfig
> >> +++ b/xen/drivers/cpufreq/Kconfig
> >> @@ -1,3 +1,6 @@
> >>
> >> config HAS_CPUFREQ
> >> bool
> >> +
> >> +config HAS_CPU_TURBO
> >> + bool
> >> diff --git a/xen/drivers/cpufreq/utility.c b/xen/drivers/cpufreq/utility.c
> >> index a687e5a..25bf983 100644
> >> --- a/xen/drivers/cpufreq/utility.c
> >> +++ b/xen/drivers/cpufreq/utility.c
> >> @@ -209,7 +209,9 @@ int cpufreq_frequency_table_cpuinfo(struct
> >> cpufreq_policy *policy,
> >> {
> >> unsigned int min_freq = ~0;
> >> unsigned int max_freq = 0;
> >> +#ifdef CONFIG_HAS_CPU_TURBO
> >> unsigned int second_max_freq = 0;
> >> +#endif
> >> unsigned int i;
> >>
> >> for (i=0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
> >> @@ -221,6 +223,7 @@ int cpufreq_frequency_table_cpuinfo(struct
> >> cpufreq_policy *policy,
> >> if (freq > max_freq)
> >> max_freq = freq;
> >> }
> >> +#ifdef CONFIG_HAS_CPU_TURBO
> >> for (i=0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
> >> unsigned int freq = table[i].frequency;
> >> if (freq == CPUFREQ_ENTRY_INVALID || freq == max_freq)
> >> @@ -234,9 +237,13 @@ int cpufreq_frequency_table_cpuinfo(struct
> >> cpufreq_policy *policy,
> >> printk("max_freq: %usecond_max_freq: %u\n",
> >> max_freq, second_max_freq);
> >>
> >> +policy->cpuinfo.second_max_freq = second_max_freq;
> >> +#else /* !CONFIG_HAS_CPU_TURBO */
> >> +if (cpufreq_verbose)
> >> +printk("max_freq: %u\n", max_freq);
> >> +#endif /* CONFIG_HAS_CPU_TURBO */
> >> policy->min = policy->cpuinfo.min_freq = min_freq;
> >> policy->max = policy->cpuinfo.max_freq = max_freq;
> >> -policy->cpuinfo.second_max_freq = second_max_freq;
> >>
> >> if (policy->min == ~0)
> >> return -EINVAL;
> >> @@ -390,6 +397,7 @@ int cpufreq_driver_getavg(unsigned int cpu, unsigned
> >> int flag)
> >> return policy->cur;
> >> }
> >>
> >> +#ifdef CONFIG_HAS_CPU_TURBO
> >> int cpufreq_update_turbo(int cpuid, int new_state)
> >> {
> >> struct cpufreq_policy *policy;
> >> @@ -430,6 +438,7 @@ int cpufreq_get_turbo_status(int cpuid)
> >> policy = per_cpu(cpufreq_cpu_policy, cpuid);
> >> return policy && policy->turbo == CPUFREQ_TURBO_ENABLED;
> >> }
> >> +#endif /* CONFIG_HAS_CPU_TURBO */
> >>
> >> /*
> >> * POLICY*
> >
> > I am wondering if we need to go
Re: [Xen-devel] [RFC PATCH 05/31] pmstat: make pmstat functions more generalizable
On Mon, 4 Dec 2017, Oleksandr Tyshchenko wrote:
> Hi Stefano
>
> On Sat, Dec 2, 2017 at 3:21 AM, Stefano Stabellini
> wrote:
> > On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> >> From: Oleksandr Dmytryshyn
> >>
> >> ACPI-specific parts are moved under appropriate ifdefs.
> >> Now pmstat functions can be used in ARM platform.
> >>
> >> This is a rebased version of the original patch:
> >> https://lists.xen.org/archives/html/xen-devel/2014-11/msg00941.html
> >
> > My first maybe naive question is: why do we want to disable the C-states
> > and not the P-states? After all, they are both defined in ACPI?
>
> Good question. Xen CPUFreq infrastructure based on ACPI P-states. We
> have to either
> completely rework generic code/existing drivers or integrate into
> "current environment" (so, the CPUFreq driver,
> this patch series adds, is pretending that it does understand what the
> P-states are). The second option requires much less
> developing & upstreaming (I hope) efforts. BTW, with the current
> solution you don't have to modify public sysctl & xenpm.
> And looking through all previous discussions [1] I got a feeling that
> the original author of this patch had had similar opinion.
>
> [1]
> /* RFC v0 */
> https://lists.xen.org/archives/html/xen-devel/2014-08/msg02919.html
> /* RFC v1 */
> https://lists.xenproject.org/archives/html/xen-devel/2014-10/msg00787.html
> /* RFC v2 */
> https://lists.xenproject.org/archives/html/xen-devel/2014-10/msg01879.html
> /* RFC v3 */
> https://marc.info/?l=xen-devel&m=141407701110860&w=2
> /* RFC v4 */
> https://marc.info/?l=xen-devel&m=141510663108037&w=2
> /* RFC v5 */
> https://lists.xen.org/archives/html/xen-devel/2014-11/msg00940.html
thank you, it makes sense
> >
> > The second question is: instead of #ifdef'ing everything C-states,
> > couldn't we just rely on XEN_PROCESSOR_PM_CX not being available?
>
> I am afraid that relying on XEN_PROCESSOR_PM_CX not being available is
> not enough.
> A few functions, which were #ifdef'd by original author of the patch,
> are located at arch/x86 path.
> So, I think, the question was to get pmstat.c compilable on ARM.
>
> But completely agree that a scope of #ifdef's can be reduced.
>
> 1. For next functions we will be able to omit #ifdef CONFIG_ACPI if we
> create corresponding stubs.
> - pmstat_get_cx_nr()
> - pmstat_get_cx_stat()
> - pmstat_reset_cx_stat()
> They won't never be called if XEN_PROCESSOR_PM_CX is not set.
sounds good
> 2. For next functions we, probably, may omit #ifdef CONFIG_ACPI, since
> the corresponding stubs already present (see !CONFIG_ACPI_CSTATE in
> acpi.h)
> - acpi_get_cstate_limit()
> - acpi_set_cstate_limit()
it looks like it, yes
> But acpi_set_pdc_bits() I would leave under #ifdef CONFIG_ACPI
> (CONFIG_X86 ?) or move it to arch/x86.
> It is called from arch/x86/platform_hypercall.c and pulls a bunch of
> #define-s from pdc_intel.h
Yes, I would move it to arch/x86.
> Something like that:
>
> diff --git a/xen/drivers/pm/stat.c b/xen/drivers/pm/stat.c
> index 133e64d..353d0ab 100644
> --- a/xen/drivers/pm/stat.c
> +++ b/xen/drivers/pm/stat.c
> @@ -500,6 +500,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
> return ret;
> }
>
> +#ifdef CONFIG_ACPI /* or CONFIG_X86 ? */
> int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE_PARAM(uint32) pdc)
> {
> u32 bits[3];
> @@ -530,3 +531,4 @@ int acpi_set_pdc_bits(u32 acpi_id,
> XEN_GUEST_HANDLE_PARAM(uint32) pdc)
>
> return ret;
> }
> +#endif /* CONFIG_ACPI */
> diff --git a/xen/include/xen/pmstat.h b/xen/include/xen/pmstat.h
> index 266bc16..05d6b7b 100644
> --- a/xen/include/xen/pmstat.h
> +++ b/xen/include/xen/pmstat.h
> @@ -6,10 +6,17 @@
> #include/* for struct pm_cx_stat */
>
> int set_px_pminfo(uint32_t cpu, struct xen_processor_performance *perf);
> +#ifdef CONFIG_ACPI /* or CONFIG_X86 ? */
> long set_cx_pminfo(uint32_t cpu, struct xen_processor_power *power);
> uint32_t pmstat_get_cx_nr(uint32_t cpuid);
> int pmstat_get_cx_stat(uint32_t cpuid, struct pm_cx_stat *stat);
> int pmstat_reset_cx_stat(uint32_t cpuid);
> +#else
> +static inline long set_cx_pminfo(uint32_t cpu, struct
> xen_processor_power *power) { return 0; }
> +static inline uint32_t pmstat_get_cx_nr(uint32_t cpuid) { return 0; }
> +static inline int pmstat_get_cx_stat(uint32_t cpuid, struct
> pm_cx_stat *stat) { return 0; }
> +static inline int pmstat_reset_cx_stat(uint32_t cpuid) { return 0; }
> +#endif
>
> int do_get_pm_info(struct xen_sysctl_get_pmstat *op);
> int do_pm_op(struc
Re: [Xen-devel] [RFC PATCH 06/31] cpufreq: make cpufreq driver more generalizable
On Mon, 4 Dec 2017, Oleksandr Tyshchenko wrote:
> Hi, Stefano
>
> On Sat, Dec 2, 2017 at 3:37 AM, Stefano Stabellini
> wrote:
> > On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> >> From: Oleksandr Dmytryshyn
> >>
> >> First implementation of the cpufreq driver has been
> >> written with x86 in mind. This patch makes possible
> >> the cpufreq driver be working on both x86 and arm
> >> architectures.
> >>
> >> This is a rebased version of the original patch:
> >> https://lists.xen.org/archives/html/xen-devel/2014-11/msg00932.html
> >>
> >> Signed-off-by: Oleksandr Dmytryshyn
> >> Signed-off-by: Oleksandr Tyshchenko
> >> CC: Jan Beulich
> >> CC: Andrew Cooper
> >> CC: Stefano Stabellini
> >> CC: Julien Grall
> >> ---
> >> xen/drivers/cpufreq/cpufreq.c| 81
> >> +---
> >> xen/include/public/platform.h| 1 +
> >> xen/include/xen/processor_perf.h | 6 +++
> >> 3 files changed, 82 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
> >> index ab909e2..64e1ae7 100644
> >> --- a/xen/drivers/cpufreq/cpufreq.c
> >> +++ b/xen/drivers/cpufreq/cpufreq.c
> >> @@ -42,7 +42,6 @@
> >> #include
> >> #include
> >> #include
> >> -#include
> >> #include
> >>
> >> static unsigned int __read_mostly usr_min_freq;
> >> @@ -206,6 +205,7 @@ int cpufreq_add_cpu(unsigned int cpu)
> >> } else {
> >> /* domain sanity check under whatever coordination type */
> >> firstcpu = cpumask_first(cpufreq_dom->map);
> >> +#ifdef CONFIG_ACPI
> >> if ((perf->domain_info.coord_type !=
> >> processor_pminfo[firstcpu]->perf.domain_info.coord_type) ||
> >> (perf->domain_info.num_processors !=
> >> @@ -221,6 +221,19 @@ int cpufreq_add_cpu(unsigned int cpu)
> >> );
> >> return -EINVAL;
> >> }
> >> +#else /* !CONFIG_ACPI */
> >> +if ((perf->domain_info.num_processors !=
> >> +processor_pminfo[firstcpu]->perf.domain_info.num_processors))
> >> {
> >> +
> >> +printk(KERN_WARNING "cpufreq fail to add CPU%d:"
> >> + "incorrect num processors (%"PRIu64"), "
> >> + "expect(%"PRIu64")\n",
> >> + cpu, perf->domain_info.num_processors,
> >> +
> >> processor_pminfo[firstcpu]->perf.domain_info.num_processors
> >> +);
> >> +return -EINVAL;
> >> +}
> >> +#endif /* CONFIG_ACPI */
> >
> > Why is this necessary? I am asking this question, because I think it
> > would be best to avoid more #ifdef's if we can avoid them, and some of
> > the code #ifdef'ed doesn't look very acpi specific (at least at first
> > sight). It doesn't look like this change is very beneficial. What am I
> > missing?
>
> Probably, the original author of this patch wanted to avoid playing
> with some stuff (code & variables) which didn't make sense/wouldn't be
> used on non-ACPI systems.
>
> Agree here, we are able to avoid this #ifdef as well as many others. I
> don't see an issue, for example, to print something defaulting for
> coord_type/num_entries/revision/etc.
I agree
> >
> >
> >> }
> >>
> >> if (!domexist || hw_all) {
> >> @@ -380,6 +393,7 @@ int cpufreq_del_cpu(unsigned int cpu)
> >> return 0;
> >> }
> >>
> >> +#ifdef CONFIG_ACPI
> >> static void print_PCT(struct xen_pct_register *ptr)
> >> {
> >> printk("\t_PCT: descriptor=%d, length=%d, space_id=%d, "
> >> @@ -387,12 +401,14 @@ static void print_PCT(struct xen_pct_register *ptr)
> >> ptr->descriptor, ptr->length, ptr->space_id, ptr->bit_width,
> >> ptr->bit_offset, ptr->reserved, ptr->address);
> >> }
> >> +#endif /* CONFIG_ACPI */
> >
> > same question
>
> definitely omit #ifdef
>
> >
> >
> >> static void print_PSS(struct xen_processor_px *ptr, int count)
> >> {
> >> int i;
> >> printk("\t_PSS: state_count=
Re: [Xen-devel] [RFC PATCH 09/31] xen/device-tree: Add dt_property_for_each_string macros
On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> This is a port from Linux.
When you port stuff from Linux you have to retain the original
copyright. Please add the original Signed-off-by lines (you actually
have to use git log and git blame to narrow them down for copyright
reasons):
Signed-off-by: Stephen Warren
Signed-off-by: Linus Walleij
With those:
Acked-by: Stefano Stabellini
> Signed-off-by: Oleksandr Tyshchenko
> CC: Stefano Stabellini
> CC: Julien Grall
> ---
> xen/common/device_tree.c | 18 ++
> xen/include/xen/device_tree.h | 21 +
> 2 files changed, 39 insertions(+)
>
> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index 60b0095..08f8072 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -208,6 +208,24 @@ int dt_property_read_string(const struct dt_device_node
> *np,
> return 0;
> }
>
> +const char *dt_property_next_string(const struct dt_property *prop,
> +const char *cur)
> +{
> +const void *curv = cur;
> +
> +if ( !prop )
> +return NULL;
> +
> +if ( !cur )
> +return prop->value;
> +
> +curv += strlen(cur) + 1;
> +if ( curv >= prop->value + prop->length )
> +return NULL;
> +
> +return curv;
> +}
> +
> bool_t dt_device_is_compatible(const struct dt_device_node *device,
> const char *compat)
> {
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index 738f1b6..9e0931c 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -420,6 +420,27 @@ int dt_property_read_string(const struct dt_device_node
> *np,
> const char *propname, const char **out_string);
>
> /**
> + * dt_property_for_each_string - Iterate over an array of strings within
> + * a property with a given name for a given node.
> + *
> + * Example:
> + *
> + * struct dt_property *prop;
> + * const char *s;
> + *
> + * dt_property_for_each_string(np, "propname", prop, s)
> + * printk("String value: %s\n", s);
> + */
> +const char *dt_property_next_string(const struct dt_property *prop,
> +const char *cur);
> +
> +#define dt_property_for_each_string(np, propname, prop, s)\
> +for (prop = dt_find_property(np, propname, NULL), \
> +s = dt_property_next_string(prop, NULL); \
> +s;\
> +s = dt_property_next_string(prop, s))
> +
> +/**
> * Checks if the given "compat" string matches one of the strings in
> * the device's "compatible" property
> */
> --
> 2.7.4
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH 10/31] xen/device-tree: Add dt_property_read_u32_index helper
On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> This is a port from Linux.
>
> Signed-off-by: Oleksandr Tyshchenko
> CC: Stefano Stabellini
> CC: Julien Grall
Same here: please original signed-off-bys and also name of the property
in Linux.
> ---
> xen/common/device_tree.c | 52
> +++
> xen/include/xen/device_tree.h | 20 +
> 2 files changed, 72 insertions(+)
>
> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index 08f8072..0fa654e 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -176,6 +176,58 @@ bool_t dt_property_read_u32(const struct dt_device_node
> *np,
> return 1;
> }
>
> +/**
> + * dt_find_property_value_of_size
> + *
> + * @np: device node from which the property value is to be read.
> + * @propname: name of the property to be searched.
> + * @min: minimum allowed length of property value
> + * @max: maximum allowed length of property value (0 means unlimited)
> + * @len: if !=NULL, actual length is written to here
> + *
> + * Search for a property in a device node and valid the requested size.
> + * Returns the property value on success, -EINVAL if the property does not
> + * exist, -ENODATA if property does not have a value, and -EOVERFLOW if the
> + * property data is too small or too large.
> + */
> +static void *dt_find_property_value_of_size(const struct dt_device_node *np,
> +const char *propname,
> +u32 min, u32 max, size_t *len)
> +{
> +const struct dt_property *prop = dt_find_property(np, propname, NULL);
> +
> +if ( !prop )
> +return ERR_PTR(-EINVAL);
> +if ( !prop->value )
> +return ERR_PTR(-ENODATA);
> +if ( prop->length < min )
> +return ERR_PTR(-EOVERFLOW);
> +if ( max && prop->length > max )
> +return ERR_PTR(-EOVERFLOW);
> +
> +if ( len )
> +*len = prop->length;
> +
> +return prop->value;
> +}
> +
> +int dt_property_read_u32_index(const struct dt_device_node *np,
> + const char *propname,
> + u32 index, u32 *out_value)
> +{
> +const u32 *val =
> +dt_find_property_value_of_size(np, propname,
> + ((index + 1) * sizeof(*out_value)),
> + 0,
> + NULL);
> +
> +if ( IS_ERR(val) )
> +return PTR_ERR(val);
> +
> +*out_value = be32_to_cpup(((__be32 *)val) + index);
> +
> +return 0;
> +}
>
> bool_t dt_property_read_u64(const struct dt_device_node *np,
> const char *name, u64 *out_value)
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index 9e0931c..87b4b67 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -374,6 +374,26 @@ const struct dt_property *dt_find_property(const struct
> dt_device_node *np,
> */
> bool_t dt_property_read_u32(const struct dt_device_node *np,
> const char *name, u32 *out_value);
> +
> +/**
> + * dt_property_read_u32_index - Find and read a u32 from a multi-value
> property.
> + *
> + * @np:device node from which the property value is to be read.
> + * @propname: name of the property to be searched.
> + * @index: index of the u32 in the list of values
> + * @out_value: pointer to return value, modified only if no error.
> + *
> + * Search for a property in a device node and read nth 32-bit value from
> + * it. Returns 0 on success, -EINVAL if the property does not exist,
> + * -ENODATA if property does not have a value, and -EOVERFLOW if the
> + * property data isn't large enough.
> + *
> + * The out_value is modified only if a valid u32 value can be decoded.
> + */
> +int dt_property_read_u32_index(const struct dt_device_node *np,
> + const char *propname,
> + u32 index, u32 *out_value);
> +
> /**
> * dt_property_read_u64 - Helper to read a u64 property.
> * @np: node to get the value
> --
> 2.7.4
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH 12/31] xen/device-tree: Add dt_property_read_string_helper and friends
On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> This is a port from Linux.
>
> Signed-off-by: Oleksandr Tyshchenko
> CC: Stefano Stabellini
> CC: Julien Grall
Same here
> ---
> xen/common/device_tree.c | 27 +++
> xen/include/xen/device_tree.h | 81
> +++
> 2 files changed, 108 insertions(+)
>
> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index 7b4cad3..827eadd 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -260,6 +260,33 @@ int dt_property_read_string(const struct dt_device_node
> *np,
> return 0;
> }
>
> +int dt_property_read_string_helper(const struct dt_device_node *np,
> + const char *propname, const char
> **out_strs,
> + size_t sz, int skip)
> +{
> +const struct dt_property *prop = dt_find_property(np, propname, NULL);
> +int l = 0, i = 0;
> +const char *p, *end;
> +
> +if ( !prop )
> +return -EINVAL;
> +if ( !prop->value )
> +return -ENODATA;
> +p = prop->value;
> +end = p + prop->length;
> +
> +for ( i = 0; p < end && (!out_strs || i < skip + sz); i++, p += l )
> +{
> +l = strnlen(p, end - p) + 1;
> +if ( p + l > end )
> +return -EILSEQ;
> +if ( out_strs && i >= skip )
> +*out_strs++ = p;
> +}
> +i -= skip;
> +return i <= 0 ? -ENODATA : i;
> +}
> +
> const char *dt_property_next_string(const struct dt_property *prop,
> const char *cur)
> {
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index e2d7346..7e51a7a 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -440,6 +440,87 @@ int dt_property_read_string(const struct dt_device_node
> *np,
> const char *propname, const char **out_string);
>
> /**
> + * dt_property_read_string_helper() - Utility helper for parsing string
> properties
> + * @np: device node from which the property value is to be read.
> + * @propname: name of the property to be searched.
> + * @out_strs: output array of string pointers.
> + * @sz: number of array elements to read.
> + * @skip: Number of strings to skip over at beginning of list.
> + *
> + * Don't call this function directly. It is a utility helper for the
> + * dt_property_read_string*() family of functions.
> + */
> +int dt_property_read_string_helper(const struct dt_device_node *np,
> + const char *propname, const char
> **out_strs,
> + size_t sz, int skip);
> +
> +/**
> + * dt_property_read_string_array() - Read an array of strings from a multiple
> + * strings property.
> + * @np: device node from which the property value is to be read.
> + * @propname: name of the property to be searched.
> + * @out_strs: output array of string pointers.
> + * @sz: number of array elements to read.
> + *
> + * Search for a property in a device tree node and retrieve a list of
> + * terminated string values (pointer to data, not a copy) in that property.
> + *
> + * If @out_strs is NULL, the number of strings in the property is returned.
> + */
> +static inline int dt_property_read_string_array(const struct dt_device_node
> *np,
> +const char *propname,
> +const char **out_strs,
> +size_t sz)
> +{
> + return dt_property_read_string_helper(np, propname, out_strs, sz, 0);
> +}
> +
> +/**
> + * dt_property_count_strings() - Find and return the number of strings from a
> + * multiple strings property.
> + * @np: device node from which the property value is to be read.
> + * @propname: name of the property to be searched.
> + *
> + * Search for a property in a device tree node and retrieve the number of
> null
> + * terminated string contain in it. Returns the number of strings on
> + * success, -EINVAL if the property does not exist, -ENODATA if property
> + * does not have a value, and -EILSEQ if the string is not null-terminated
> + * within the length of the property data.
> + */
> +static inline int dt_property_count_strings(const struct dt_device_node *np,
> +const char *propname)
> +{
> + return
Re: [Xen-devel] [RFC PATCH 11/31] xen/device-tree: Add dt_property_count_elems_of_size helper
On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> This is a port from Linux.
>
> Signed-off-by: Oleksandr Tyshchenko
> CC: Stefano Stabellini
> CC: Julien Grall
Same here
> ---
> xen/common/device_tree.c | 20
> xen/include/xen/device_tree.h | 15 +++
> 2 files changed, 35 insertions(+)
>
> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index 0fa654e..7b4cad3 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -278,6 +278,26 @@ const char *dt_property_next_string(const struct
> dt_property *prop,
> return curv;
> }
>
> +int dt_property_count_elems_of_size(const struct dt_device_node *np,
> +const char *propname, int elem_size)
> +{
> +const struct dt_property *prop = dt_find_property(np, propname, NULL);
> +
> +if ( !prop )
> +return -EINVAL;
> +if ( !prop->value )
> +return -ENODATA;
> +
> +if ( prop->length % elem_size != 0 )
> +{
> +printk("%s: size of %s is not a multiple of %d\n", np->full_name,
> + propname, elem_size);
> +return -EINVAL;
> +}
> +
> +return prop->length / elem_size;
> +}
> +
> bool_t dt_device_is_compatible(const struct dt_device_node *device,
> const char *compat)
> {
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index 87b4b67..e2d7346 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -461,6 +461,21 @@ const char *dt_property_next_string(const struct
> dt_property *prop,
> s = dt_property_next_string(prop, s))
>
> /**
> + * dt_property_count_elems_of_size - Count the number of elements in a
> property
> + *
> + * @np:device node from which the property value is to be read.
> + * @propname: name of the property to be searched.
> + * @elem_size: size of the individual element
> + *
> + * Search for a property in a device node and count the number of elements of
> + * size elem_size in it. Returns number of elements on sucess, -EINVAL if the
> + * property does not exist or its length does not match a multiple of
> elem_size
> + * and -ENODATA if the property does not have a value.
> + */
> +int dt_property_count_elems_of_size(const struct dt_device_node *np,
> +const char *propname, int elem_size);
> +
> +/**
> * Checks if the given "compat" string matches one of the strings in
> * the device's "compatible" property
> */
> --
> 2.7.4
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH 13/31] xen/arm: Add driver_data field to struct device
On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote: > From: Oleksandr Tyshchenko > > Signed-off-by: Oleksandr Tyshchenko > CC: Stefano Stabellini > CC: Julien Grall Acked-by: Stefano Stabellini > --- > xen/include/asm-arm/device.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h > index 6734ae8..3e2f34a 100644 > --- a/xen/include/asm-arm/device.h > +++ b/xen/include/asm-arm/device.h > @@ -20,6 +20,7 @@ struct device > struct dt_device_node *of_node; /* Used by drivers imported from Linux */ > #endif > struct dev_archdata archdata; > +void *driver_data; > }; > > typedef struct device device_t; > -- > 2.7.4 > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH 16/31] arm: add SMC wrapper that is compatible with SMCCC
On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> From: Volodymyr Babchuk
>
> Existing SMC wrapper call_smc() allows only 4 parameters and
> returns only one value. This is enough for existing
> use in PSCI code, but TEE mediator will need a call that is
> fully compatible with ARM SMCCC.
> This patch adds this call for both arm32 and arm64.
>
> There was similar patch by Edgar E. Iglesias ([1]), but looks
> like it is abandoned.
>
> [1] https://lists.xenproject.org/archives/html/xen-devel/2017-02/msg00636.html
>
> CC: "Edgar E. Iglesias"
>
> Signed-off-by: Volodymyr Babchuk
> CC: Stefano Stabellini
> CC: Julien Grall
> ---
> xen/arch/arm/arm32/Makefile | 1 +
> xen/arch/arm/arm32/smc.S| 32
> xen/arch/arm/arm64/Makefile | 1 +
> xen/arch/arm/arm64/smc.S| 29 +
> xen/include/asm-arm/processor.h | 4
> 5 files changed, 67 insertions(+)
> create mode 100644 xen/arch/arm/arm32/smc.S
> create mode 100644 xen/arch/arm/arm64/smc.S
>
> diff --git a/xen/arch/arm/arm32/Makefile b/xen/arch/arm/arm32/Makefile
> index 0ac254f..a2362f3 100644
> --- a/xen/arch/arm/arm32/Makefile
> +++ b/xen/arch/arm/arm32/Makefile
> @@ -8,6 +8,7 @@ obj-y += insn.o
> obj-$(CONFIG_LIVEPATCH) += livepatch.o
> obj-y += proc-v7.o proc-caxx.o
> obj-y += smpboot.o
> +obj-y += smc.o
> obj-y += traps.o
> obj-y += vfp.o
>
> diff --git a/xen/arch/arm/arm32/smc.S b/xen/arch/arm/arm32/smc.S
> new file mode 100644
> index 000..1cc9528
> --- /dev/null
> +++ b/xen/arch/arm/arm32/smc.S
> @@ -0,0 +1,32 @@
> +/*
> + * xen/arch/arm/arm32/smc.S
> + *
> + * Wrapper for Secure Monitors Calls
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +
> +/*
> + * void call_smccc_smc(register_t a0, register_t a1, register_t a2,
> + * register_t a3, register_t a4, register_t a5,
> + * register_t a6, register_t a7, register_t res[4])
> + */
> +ENTRY(call_smccc_smc)
> +mov r12, sp
> +push{r4-r7}
> +ldm r12, {r4-r7}
> +smc #0
> +pop {r4-r7}
> +ldr r12, [sp, #(4 * 4)]
I haven't run this, but shouldn't it be:
ldr r12, [sp, #20]
?
> +stm r12, {r0-r3}
> +bx lr
> diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
> index 149b6b3..7831dc1 100644
> --- a/xen/arch/arm/arm64/Makefile
> +++ b/xen/arch/arm/arm64/Makefile
> @@ -8,5 +8,6 @@ obj-y += entry.o
> obj-y += insn.o
> obj-$(CONFIG_LIVEPATCH) += livepatch.o
> obj-y += smpboot.o
> +obj-y += smc.o
> obj-y += traps.o
> obj-y += vfp.o
> diff --git a/xen/arch/arm/arm64/smc.S b/xen/arch/arm/arm64/smc.S
> new file mode 100644
> index 000..aa44fba
> --- /dev/null
> +++ b/xen/arch/arm/arm64/smc.S
> @@ -0,0 +1,29 @@
> +/*
> + * xen/arch/arm/arm64/smc.S
> + *
> + * Wrapper for Secure Monitors Calls
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +
> +/*
> + * void call_smccc_smc(register_t a0, register_t a1, register_t a2,
> + * register_t a3, register_t a4, register_t a5,
> + * register_t a6, register_t a7, register_t res[4])
> + */
> +ENTRY(call_smccc_smc)
> +smc #0
> +ldr x4, [sp]
> +stp x0, x1, [x4, 0]
> +stp x2, x3, [x4, 16]
> +ret
> diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
> index 9f7a42f..4ce5bb6 100644
> --- a/xen/include/asm-arm/processor.h
> +++ b/xen/include/asm-arm/processor.h
> @@ -786,6 +786,10
Re: [Xen-devel] [RFC PATCH 16/31] arm: add SMC wrapper that is compatible with SMCCC
On Tue, 5 Dec 2017, Volodymyr Babchuk wrote:
> Hi Stefano,
>
> On Mon, Dec 04, 2017 at 06:30:13PM -0800, Stefano Stabellini wrote:
> > On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> > > From: Volodymyr Babchuk
> > >
> > > Existing SMC wrapper call_smc() allows only 4 parameters and
> > > returns only one value. This is enough for existing
> > > use in PSCI code, but TEE mediator will need a call that is
> > > fully compatible with ARM SMCCC.
> > > This patch adds this call for both arm32 and arm64.
> > >
> > > There was similar patch by Edgar E. Iglesias ([1]), but looks
> > > like it is abandoned.
> > >
> > > [1]
> > > https://lists.xenproject.org/archives/html/xen-devel/2017-02/msg00636.html
> > >
> > > CC: "Edgar E. Iglesias"
> > >
> > > Signed-off-by: Volodymyr Babchuk
> > > CC: Stefano Stabellini
> > > CC: Julien Grall
> > > ---
> > > xen/arch/arm/arm32/Makefile | 1 +
> > > xen/arch/arm/arm32/smc.S| 32
> > > xen/arch/arm/arm64/Makefile | 1 +
> > > xen/arch/arm/arm64/smc.S| 29 +
> > > xen/include/asm-arm/processor.h | 4
> > > 5 files changed, 67 insertions(+)
> > > create mode 100644 xen/arch/arm/arm32/smc.S
> > > create mode 100644 xen/arch/arm/arm64/smc.S
> > >
> > > diff --git a/xen/arch/arm/arm32/Makefile b/xen/arch/arm/arm32/Makefile
> > > index 0ac254f..a2362f3 100644
> > > --- a/xen/arch/arm/arm32/Makefile
> > > +++ b/xen/arch/arm/arm32/Makefile
> > > @@ -8,6 +8,7 @@ obj-y += insn.o
> > > obj-$(CONFIG_LIVEPATCH) += livepatch.o
> > > obj-y += proc-v7.o proc-caxx.o
> > > obj-y += smpboot.o
> > > +obj-y += smc.o
> > > obj-y += traps.o
> > > obj-y += vfp.o
> > >
> > > diff --git a/xen/arch/arm/arm32/smc.S b/xen/arch/arm/arm32/smc.S
> > > new file mode 100644
> > > index 000..1cc9528
> > > --- /dev/null
> > > +++ b/xen/arch/arm/arm32/smc.S
> > > @@ -0,0 +1,32 @@
> > > +/*
> > > + * xen/arch/arm/arm32/smc.S
> > > + *
> > > + * Wrapper for Secure Monitors Calls
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License as published by
> > > + * the Free Software Foundation; either version 2 of the License, or
> > > + * (at your option) any later version.
> > > + *
> > > + * This program is distributed in the hope that it will be useful,
> > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > > + * GNU General Public License for more details.
> > > + */
> > > +
> > > +#include
> > > +
> > > +/*
> > > + * void call_smccc_smc(register_t a0, register_t a1, register_t a2,
> > > + * register_t a3, register_t a4, register_t a5,
> > > + * register_t a6, register_t a7, register_t res[4])
> > > + */
> > > +ENTRY(call_smccc_smc)
> > > +mov r12, sp
> > > +push{r4-r7}
> > > +ldm r12, {r4-r7}
> > > +smc #0
> > > +pop {r4-r7}
> > > +ldr r12, [sp, #(4 * 4)]
> >
> > I haven't run this, but shouldn't it be:
> >
> > ldr r12, [sp, #20]
> >
> > ?
> >
> I took this code from linux (arch/arm/kernel/arm-smccc.h).
> But, why #20? There are 5 parameters on the stack: a4-a7 and res:
> a4: [sp]
> a5: [sp, #4]
> a6: [sp, #8]
> a7: [sp, #12]
> res: [sp, #16]
>
> We need to save returnred values to res. So it looks right. Unless
> I'm terribly wrong :)
Ops, I miscounted.
When taking code from Linux, it would be nice to say where you took it
from. Also, you definitely need to add the right signed-off-by lines for
copyright reasons.
Cheers,
Stefano
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/pvcalls: check for xenbus_read() errors
On Tue, 5 Dec 2017, Dan Carpenter wrote:
> Smatch complains that "len" is uninitialized if xenbus_read() fails so
> let's add some error handling.
>
> Signed-off-by: Dan Carpenter
Reviewed-by: Stefano Stabellini
> diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
> index 40caa92bff33..afa3f1b5d807 100644
> --- a/drivers/xen/pvcalls-front.c
> +++ b/drivers/xen/pvcalls-front.c
> @@ -1128,6 +1128,8 @@ static int pvcalls_front_probe(struct xenbus_device
> *dev,
> }
>
> versions = xenbus_read(XBT_NIL, dev->otherend, "versions", &len);
> + if (IS_ERR(versions))
> + return PTR_ERR(versions);
> if (!len)
> return -EINVAL;
> if (strcmp(versions, "1")) {
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] xen/pvcalls: Fix a check in pvcalls_front_remove()
On Tue, 5 Dec 2017, Dan Carpenter wrote:
> bedata->ref can't be less than zero because it's unsigned. This affects
> certain error paths in probe. We first set ->ref = -1 and then we set
> it to a valid value later.
>
> Fixes: 219681909913 ("xen/pvcalls: connect to the backend")
> Signed-off-by: Dan Carpenter
Reviewed-by: Stefano Stabellini
> diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
> index 40caa92bff33..d1e1d8d2b9d5 100644
> --- a/drivers/xen/pvcalls-front.c
> +++ b/drivers/xen/pvcalls-front.c
> @@ -1103,7 +1103,7 @@ static int pvcalls_front_remove(struct xenbus_device
> *dev)
> kfree(map);
> }
> }
> - if (bedata->ref >= 0)
> + if (bedata->ref != -1)
> gnttab_end_foreign_access(bedata->ref, 0, 0);
> kfree(bedata->ring.sring);
> kfree(bedata);
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] linux-arm-xen: Get from shared arm/linux.git xenbits tree
On Tue, 5 Dec 2017, Julien Grall wrote:
> Hi Ian,
>
> On 05/12/17 18:28, Ian Jackson wrote:
> > This drops the dependency on Stefano's personal git tree.
> > The osstest output branch remains unmoved.
> >
> > CC: Stefano Stabellini
> > CC: Julien Grall
> > Signed-off-by: Ian Jackson
>
> Acked-by: Julien Grall
Acked-by: Stefano Stabellini
> Cheers,
>
> > ---
> > ap-common | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/ap-common b/ap-common
> > index bc7c03c..4576ac9 100644
> > --- a/ap-common
> > +++ b/ap-common
> > @@ -100,8 +100,8 @@ info_linux_tree () {
> > : ${TREE_LINUX_THIS:=${KERNEL_SCM}/torvalds/linux-2.6.git}
> > ;;
> > linux-arm-xen)
> > - : ${TREE_LINUX_THIS:=${KERNEL_SCM}/sstabellini/xen.git}
> > - : ${TREE_LINUX_ARM_THIS:=${KERNEL_SCM}/sstabellini/xen.git}
> > + : ${TREE_LINUX_THIS:=git://xenbits.xen.org/arm/linux.git}
> > + : ${TREE_LINUX_ARM_THIS:=git://xenbits.xen.org/arm/linux.git}
> > : ${TAG_LINUX_THIS:=linux-arm-xen}
> > : ${TAG_LINUX_ARM_THIS:=linux-arm-xen}
> > ;;
> >
>
> --
> Julien Grall
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] gnttab: correct GNTTABOP_cache_flush empty batch handling
On Mon, 4 Dec 2017, Jan Beulich wrote: > >>> On 01.12.17 at 22:38, wrote: > > On Thu, 30 Nov 2017, Jan Beulich wrote: > >> Jann validly points out that with a caller bogusly requesting a zero- > >> element batch with non-zero high command bits (the ones used for > >> continuation encoding), the assertion right before the call to > >> hypercall_create_continuation() would trigger. A similar situation would > >> arise afaict for non-empty batches with op and/or length zero in every > >> element. > >> > >> While we want the former to succeed (as we do elsewhere for similar > >> no-op requests), the latter can clearly be converted to an error, as > >> this is a state that can't be the result of a prior operation. > >> > >> Take the opportunity and also correct the order of argument checks: > >> We shouldn't accept zero-length elements with unknown bits set in "op". > >> Also constify cache_flush()'s first parameter. > >> > >> Reported-by: Jann Horn > >> Signed-off-by: Jan Beulich > > > > Acked-by: Stefano Stabellini > > Thanks. Since this and the other patch mainly affect ARM, I'd like > to have your opinion please regarding their backporting. Yes, I think they could be backported. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH 04/31] cpufreq: make turbo settings to be configurable
On Tue, 5 Dec 2017, Oleksandr Tyshchenko wrote:
> >> Another question is second_max_freq. As I understand, it is highest
> >> non-turbo frequency calculated by framework to limit target frequency
> >> when
> >> turbo mode "is disabled". And Xen assumes that second_max_freq is
> >> always P1 if turbo mode is on.
> >> But, there might be a case when a few highest frequencies are
> >> turbo-frequencies. So, I propose to add an extra flag for handling
> >> that.
> >> So, each CPUFreq driver responsibility will be to mark
> >> turbo-frequency(ies) for the framework to properly calculate
> >> second_max_freq.
> >
> > As Andre wrote, we can start simply assuming that ARM doesn't have
> > turbo. If turbo mode is assumed to be off, I don't think we need the
> > patch below and the new flag, because second_max_freq == max_freq.
>
> I just want to show you real example, where we have ARM SoC +
> turbo-mode + > 1 turbo freq
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/tree/arch/arm64/boot/dts/renesas/r8a7795.dtsi?h=v4.9/rcar-3.5.9#n197
> As you can see, there are two freqs marked as turbo-freqs: 16
> Hz and 17 Hz
>
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/tree/arch/arm64/boot/dts/renesas/r8a7796.dtsi?h=v4.9/rcar-3.5.9#n166
> For M3 SoC three turbo-freqs are used: 16 Hz, 17 Hz
> and 18 Hz
Oh well, I take that back then :-)
> If a proposed below patch is not an option then we should find another
> way to clarify second_max_freq.
Yes, it looks like there must be better ways to define second_max_freq.
Taking the first frequency below the max seems a bit crude to me.
> >
> >> Something like that:
> >>
> >> diff --git a/xen/drivers/cpufreq/utility.c b/xen/drivers/cpufreq/utility.c
> >> index 25bf983..122a88b 100644
> >> --- a/xen/drivers/cpufreq/utility.c
> >> +++ b/xen/drivers/cpufreq/utility.c
> >> @@ -226,7 +226,8 @@ int cpufreq_frequency_table_cpuinfo(struct
> >> cpufreq_policy *policy,
> >> #ifdef CONFIG_HAS_CPU_TURBO
> >> for (i=0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
> >> unsigned int freq = table[i].frequency;
> >> -if (freq == CPUFREQ_ENTRY_INVALID || freq == max_freq)
> >> +if ((freq == CPUFREQ_ENTRY_INVALID) ||
> >> +(table[i].flags & CPUFREQ_BOOST_FREQ))
> >> continue;
> >> if (freq > second_max_freq)
> >> second_max_freq = freq;
> >> diff --git a/xen/include/xen/cpufreq.h b/xen/include/xen/cpufreq.h
> >> index 2e0c16a..77b29da 100644
> >> --- a/xen/include/xen/cpufreq.h
> >> +++ b/xen/include/xen/cpufreq.h
> >> @@ -204,7 +204,11 @@ void cpufreq_verify_within_limits(struct
> >> cpufreq_policy *policy,
> >> #define CPUFREQ_ENTRY_INVALID ~0
> >> #define CPUFREQ_TABLE_END ~1
> >>
> >> +/* Special Values of .flags field */
> >> +#define CPUFREQ_BOOST_FREQ(1 << 0)
> >> +
> >> struct cpufreq_frequency_table {
> >> + unsigned intflags;
> >> unsigned intindex; /* any */
> >> unsigned intfrequency; /* kHz - doesn't need to be in ascending
> >> * order */
> >>
> >> Both existing on x86 CPUFreq drivers just need to mark P0 frequency as
> >> a turbo-frequency if turbo mode "is supported". Am I correct?
Yes, I think it is a better approach than what we have today, even for
x86.
> >> And the most important question is how to recognize in Xen on ARM
> >> (using SCPI protocol) which frequencies are turbo-frequencies
> >> actually? I couldn't find any information regarding that in protocol
> >> description.
> >> For DT-based CPUFreq it is not an issue, since there is a specific
> >> property "turbo-mode" to mark corresponding OPPs. [1].
> >> But neither SCPI DT bindings [2] nor the SCPI protocol itself [3]
> >> mentions about it. Perhaps, additional command should be added to pass
> >> such info.
> >>
> >> [1]
> >> https://www.kernel.org/doc/Documentation/devicetree/bindings/opp/opp.txt
> >> [2]
> >> http://elixir.free-electrons.com/linux/v4.15-rc1/source/Documentation/devicetree/bindings/arm/arm,scpi.txt
> >> [3]
> >> http://infocenter.arm.com/help/topic/com.arm.doc.dui0922g/scp_message_interface_v1_2_DUI0922G_en.pdf
If there are no mentions of them, then I would assume that none of the
available frequencies are turbo frequencies.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH 06/31] cpufreq: make cpufreq driver more generalizable
On Tue, 5 Dec 2017, Oleksandr Tyshchenko wrote:
> Hi Stefano
>
> On Tue, Dec 5, 2017 at 12:46 AM, Stefano Stabellini
> wrote:
> > On Mon, 4 Dec 2017, Oleksandr Tyshchenko wrote:
> >> Hi, Stefano
> >>
> >> On Sat, Dec 2, 2017 at 3:37 AM, Stefano Stabellini
> >> wrote:
> >> > On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> >> >> From: Oleksandr Dmytryshyn
> >> >>
> >> >> First implementation of the cpufreq driver has been
> >> >> written with x86 in mind. This patch makes possible
> >> >> the cpufreq driver be working on both x86 and arm
> >> >> architectures.
> >> >>
> >> >> This is a rebased version of the original patch:
> >> >> https://lists.xen.org/archives/html/xen-devel/2014-11/msg00932.html
> >> >>
> >> >> Signed-off-by: Oleksandr Dmytryshyn
> >> >>
> >> >> Signed-off-by: Oleksandr Tyshchenko
> >> >> CC: Jan Beulich
> >> >> CC: Andrew Cooper
> >> >> CC: Stefano Stabellini
> >> >> CC: Julien Grall
> >> >> ---
> >> >> xen/drivers/cpufreq/cpufreq.c| 81
> >> >> +---
> >> >> xen/include/public/platform.h| 1 +
> >> >> xen/include/xen/processor_perf.h | 6 +++
> >> >> 3 files changed, 82 insertions(+), 6 deletions(-)
> >> >>
> >> >> diff --git a/xen/drivers/cpufreq/cpufreq.c
> >> >> b/xen/drivers/cpufreq/cpufreq.c
> >> >> index ab909e2..64e1ae7 100644
> >> >> --- a/xen/drivers/cpufreq/cpufreq.c
> >> >> +++ b/xen/drivers/cpufreq/cpufreq.c
> >> >> @@ -42,7 +42,6 @@
> >> >> #include
> >> >> #include
> >> >> #include
> >> >> -#include
> >> >> #include
> >> >>
> >> >> static unsigned int __read_mostly usr_min_freq;
> >> >> @@ -206,6 +205,7 @@ int cpufreq_add_cpu(unsigned int cpu)
> >> >> } else {
> >> >> /* domain sanity check under whatever coordination type */
> >> >> firstcpu = cpumask_first(cpufreq_dom->map);
> >> >> +#ifdef CONFIG_ACPI
> >> >> if ((perf->domain_info.coord_type !=
> >> >> processor_pminfo[firstcpu]->perf.domain_info.coord_type) ||
> >> >> (perf->domain_info.num_processors !=
> >> >> @@ -221,6 +221,19 @@ int cpufreq_add_cpu(unsigned int cpu)
> >> >> );
> >> >> return -EINVAL;
> >> >> }
> >> >> +#else /* !CONFIG_ACPI */
> >> >> +if ((perf->domain_info.num_processors !=
> >> >> +
> >> >> processor_pminfo[firstcpu]->perf.domain_info.num_processors)) {
> >> >> +
> >> >> +printk(KERN_WARNING "cpufreq fail to add CPU%d:"
> >> >> + "incorrect num processors (%"PRIu64"), "
> >> >> + "expect(%"PRIu64")\n",
> >> >> + cpu, perf->domain_info.num_processors,
> >> >> +
> >> >> processor_pminfo[firstcpu]->perf.domain_info.num_processors
> >> >> +);
> >> >> +return -EINVAL;
> >> >> +}
> >> >> +#endif /* CONFIG_ACPI */
> >> >
> >> > Why is this necessary? I am asking this question, because I think it
> >> > would be best to avoid more #ifdef's if we can avoid them, and some of
> >> > the code #ifdef'ed doesn't look very acpi specific (at least at first
> >> > sight). It doesn't look like this change is very beneficial. What am I
> >> > missing?
> >>
> >> Probably, the original author of this patch wanted to avoid playing
> >> with some stuff (code & variables) which didn't make sense/wouldn't be
> >> used on non-ACPI systems.
> >>
> >> Agree here, we are able to avoid this #ifdef as well as many others. I
> >> don't see an issue, for example, to print something defaulting for
> >> coord_type/num_entries/revision/etc.
> >
> > I agree
> >
> >
> >> >
> >> >
> >> >> }
> >
Re: [Xen-devel] [RFC PATCH 22/31] xen/arm: Add Xen changes to SCPI protocol
On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> Modify the direct ported SCPI Message Protocol driver to be
> functional inside Xen.
>
> As SCPI Message protocol driver expects mailbox to be registed,
> find and initialize mailbox before probing it.
>
> Include "wrappers.h" which contains all required things the direct
> ported code relies on.
>
> Signed-off-by: Oleksandr Tyshchenko
> CC: Stefano Stabellini
> CC: Julien Grall
As far as drivers ported from Linux go, this looks pretty clean in terms
of changes and nasty glue code required to get it to work.
The wrappers.h header is not too bad. The question remains on whether we
should keep the #if 0 to retain "textual compatibility" with Linux, or
we should just bite the bullet and apply the changes. If we commit them
as a separate patch, we can always dig out the difference between the
original driver and the Xen version using git.
Julien, what do you think?
> ---
> xen/arch/arm/cpufreq/arm_scpi.c | 90
>
> xen/arch/arm/cpufreq/scpi_protocol.h | 32 +
> 2 files changed, 122 insertions(+)
>
> diff --git a/xen/arch/arm/cpufreq/arm_scpi.c b/xen/arch/arm/cpufreq/arm_scpi.c
> index 7da9f1b..553a516 100644
> --- a/xen/arch/arm/cpufreq/arm_scpi.c
> +++ b/xen/arch/arm/cpufreq/arm_scpi.c
> @@ -23,8 +23,16 @@
> *
> * You should have received a copy of the GNU General Public License along
> * with this program. If not, see <http://www.gnu.org/licenses/>.
> + *
> + * Based on Linux drivers/firmware/arm_scpi.c
> + * => commit 0d30176819c8738b012ec623c7b3db19df818e70
> + *
> + * Xen modification:
> + * Oleksandr Tyshchenko
> + * Copyright (C) 2017 EPAM Systems Inc.
> */
>
> +#if 0
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> #include
> @@ -44,6 +52,22 @@
> #include
> #include
> #include
> +#endif
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include "scpi_protocol.h"
> +#include "mailbox_client.h"
> +#include "mailbox_controller.h"
> +#include "wrappers.h"
> +
> +/*
> + * TODO:
> + * 1. Add releasing resources since devm.
> + */
>
> #define CMD_ID_SHIFT 0
> #define CMD_ID_MASK 0x7f
> @@ -859,6 +883,7 @@ static int scpi_init_versions(struct scpi_drvinfo *info)
> return ret;
> }
>
> +#if 0
> static ssize_t protocol_version_show(struct device *dev,
>struct device_attribute *attr, char *buf)
> {
> @@ -888,6 +913,7 @@ static struct attribute *versions_attrs[] = {
> NULL,
> };
> ATTRIBUTE_GROUPS(versions);
> +#endif
>
> static void
> scpi_free_channels(struct device *dev, struct scpi_chan *pchan, int count)
> @@ -909,8 +935,10 @@ static int scpi_remove(struct platform_device *pdev)
>
> scpi_info = NULL; /* stop exporting SCPI ops through get_scpi_ops */
>
> +#if 0
> of_platform_depopulate(dev);
> sysfs_remove_groups(&dev->kobj, versions_groups);
> +#endif
> scpi_free_channels(dev, info->channels, info->num_chans);
> platform_set_drvdata(pdev, NULL);
>
> @@ -1055,11 +1083,15 @@ err:
> FW_REV_PATCH(scpi_info->firmware_version));
> scpi_info->scpi_ops = &scpi_ops;
>
> +#if 0
> ret = sysfs_create_groups(&dev->kobj, versions_groups);
> if (ret)
> dev_err(dev, "unable to create sysfs version group\n");
>
> return of_platform_populate(dev->of_node, NULL, NULL, dev);
> +#else
> + return 0;
> +#endif
> }
>
> static const struct of_device_id scpi_of_match[] = {
> @@ -1070,6 +1102,7 @@ static const struct of_device_id scpi_of_match[] = {
>
> MODULE_DEVICE_TABLE(of, scpi_of_match);
>
> +#if 0
> static struct platform_driver scpi_driver = {
> .driver = {
> .name = "scpi_protocol",
> @@ -1083,3 +1116,60 @@ module_platform_driver(scpi_driver);
> MODULE_AUTHOR("Sudeep Holla ");
> MODULE_DESCRIPTION("ARM SCPI mailbox protocol driver");
> MODULE_LICENSE("GPL v2");
> +#endif
> +
> +static struct device *scpi_dev;
> +
> +struct device *get_scpi_dev(void)
> +{
> + return scpi_dev;
> +}
> +
> +int __init scpi_init(void)
> +{
> + struct dt_device_node *scpi, *mbox;
> + bool has_mbox = false;
> + int ret = -ENODEV;
> +
> + scpi = dt_find_matching_node(NULL, scpi_of_match);
> + if (!scpi) {
> + printk("failed to find SCPI node in the devic
Re: [Xen-devel] [RFC PATCH 27/31] cpufreq: hack: perf->states isn't a real guest handle on ARM
On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> This patch is just a temp solution to highlight a problem which
> should be resolved in a proper way.
>
> set_px_pminfo() is intended to be called from platform hypercall
> where "perf" argument was entirely filled in by hwdom.
>
> But unlike x86 we don't get this info from hwdom on ARM,
> we get it from other sources (device tree + firmware). In order to
> retain function interface, we emulate receiving hypercall and
> pass argument which function expects to see. Although "perf->states"
> looks like a guest handle it is not a real handle and we can't use
> copy_from_guest() over it. As only scpi-cpufreq sets XEN_PX_DATA flag
> use it as an indicator to do memcpy.
>
> Signed-off-by: Oleksandr Tyshchenko
> CC: Jan Beulich
> CC: Andrew Cooper
> CC: Stefano Stabellini
> CC: Julien Grall
As a reference, this patch has been discussed here:
https://marc.info/?l=xen-devel&m=151250698607186
> ---
> xen/drivers/cpufreq/cpufreq.c | 19 +++
> 1 file changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
> index 64e1ae7..1022cd1 100644
> --- a/xen/drivers/cpufreq/cpufreq.c
> +++ b/xen/drivers/cpufreq/cpufreq.c
> @@ -558,11 +558,22 @@ int set_px_pminfo(uint32_t acpi_id, struct
> xen_processor_performance *dom0_px_in
> ret = -ENOMEM;
> goto out;
> }
> -if ( copy_from_guest(pxpt->states, dom0_px_info->states,
> - dom0_px_info->state_count) )
> +
> +if ( dom0_px_info->flags == XEN_PX_DATA )
> {
> -ret = -EFAULT;
> -goto out;
> +struct xen_processor_px *states = (dom0_px_info->states).p;
> +
> +memcpy(pxpt->states, states,
> + dom0_px_info->state_count * sizeof(struct
> xen_processor_px));
> +}
> +else
> +{
> +if ( copy_from_guest(pxpt->states, dom0_px_info->states,
> + dom0_px_info->state_count) )
> +{
> +ret = -EFAULT;
> +goto out;
> +}
> }
> pxpt->state_count = dom0_px_info->state_count;
>
> --
> 2.7.4
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH 29/31] xen/arm: Introduce CPUFreq Interface component
On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> This patch adds an interface component which performs following steps:
> 1. Initialize everything needed SCPI based CPUFreq driver to be functional
>(SCPI Message protocol, mailbox to communicate with SCP, etc).
>Also preliminary check if SCPI DVFS clock nodes offered by SCP are
>present in a device tree.
> 2. Register SCPI based CPUFreq driver.
> 3. Populate CPUs. Get DVFS info (OPP list and the latency information)
>for all DVFS capable CPUs using SCPI protocol, convert these capabilities
>into PM data the CPUFreq framework expects to see followed by
>uploading it.
>
> Signed-off-by: Oleksandr Tyshchenko
> CC: Stefano Stabellini
> CC: Julien Grall
> ---
> xen/arch/arm/cpufreq/cpufreq_if.c | 522
> ++
> 1 file changed, 522 insertions(+)
> create mode 100644 xen/arch/arm/cpufreq/cpufreq_if.c
>
> diff --git a/xen/arch/arm/cpufreq/cpufreq_if.c
> b/xen/arch/arm/cpufreq/cpufreq_if.c
> new file mode 100644
> index 000..2451d00
> --- /dev/null
> +++ b/xen/arch/arm/cpufreq/cpufreq_if.c
> @@ -0,0 +1,522 @@
> +/*
> + * xen/arch/arm/cpufreq/cpufreq_if.c
> + *
> + * CPUFreq interface component
> + *
> + * Oleksandr Tyshchenko
> + * Copyright (c) 2017 EPAM Systems.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "scpi_protocol.h"
> +
> +/*
> + * TODO:
> + * 1. Add __init to required funcs
> + * 2. Put get_cpu_device() into common place
> + */
> +
> +static struct scpi_ops *scpi_ops;
> +
> +extern int scpi_cpufreq_register_driver(void);
> +
> +#define dev_name(dev) dt_node_full_name(dev_to_dt(dev))
> +
> +struct device *get_cpu_device(unsigned int cpu)
> +{
> +if ( cpu < nr_cpu_ids && cpu_possible(cpu) )
> +return dt_to_dev(cpu_dt_nodes[cpu]);
> +else
> +return NULL;
> +}
> +
> +static bool is_dvfs_capable(unsigned int cpu)
> +{
> +static const struct dt_device_match scpi_dvfs_clock_match[] =
> +{
> +DT_MATCH_COMPATIBLE("arm,scpi-dvfs-clocks"),
> +{ /* sentinel */ },
> +};
> +struct device *cpu_dev;
> +struct dt_phandle_args clock_spec;
> +struct scpi_dvfs_info *info;
> +u32 domain;
> +int i, ret, count;
> +
> +cpu_dev = get_cpu_device(cpu);
> +if ( !cpu_dev )
> +{
> +printk("cpu%d: failed to get device\n", cpu);
> +return false;
> +}
> +
> +/* First of all find a clock node this CPU is a consumer of */
> +ret = dt_parse_phandle_with_args(cpu_dev->of_node,
> + "clocks",
> + "#clock-cells",
> + 0,
> + &clock_spec);
> +if ( ret )
> +{
> +printk("cpu%d: failed to get clock node\n", cpu);
> +return false;
> +}
> +
> +/* Make sure it is an available DVFS clock node */
> +if ( !dt_match_node(scpi_dvfs_clock_match, clock_spec.np) ||
> + !dt_device_is_available(clock_spec.np) )
> +{
> +printk("cpu%d: clock node '%s' is either non-DVFS or
> non-available\n",
> + cpu, dev_name(&clock_spec.np->dev));
> +return false;
> +}
> +
> +/*
> + * Actually we already have a power domain id this CPU belongs to,
> + * it is a stored in args[0] CPU clock specifier, so we could ask SCP
> + * to provide its DVFS info. But we want to dig a little bit deeper
> + * to make sure that everything is correct.
> + */
> +
> +/* Check how many clock ids a DVFS clock node has */
> +ret = dt_property_count_elems_of_size(clock_spec.np,
> + "clock-indices",
> + si
Re: [Xen-devel] [RFC PATCH 00/31] CPUFreq on ARM
Hi Oleksandr, I just wanted to tell you that the patch series is very well organized and the patches very nicely split. Thank you! - Stefano On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote: > From: Oleksandr Tyshchenko > > Hi, all. > > The purpose of this RFC patch series is to add CPUFreq support to Xen on ARM. > Motivation of hypervisor based CPUFreq is to enable one of the main PM > use-cases in virtualized system powered by Xen hypervisor. Rationale behind > this activity is that CPU virtualization is done by hypervisor and the guest > OS doesn't actually know anything about physical CPUs because it is running > on virtual CPUs. It is quite clear that a decision about frequency change > should be taken by hypervisor as only it has information about actual CPU > load. Although these required components (CPUFreq core, governors, etc) > already exist in Xen, it is worth to mention that they are ACPI specific. So, > a part of the current patch series makes them more generic in order to make > possible a CPUFreq usage on architectures without ACPI support in. > But, the main question we have to answer is about frequency changing > interface in virtualized system. The frequency changing interface and all > dependent components which needed CPUFreq to be functional on ARM are not > present in Xen these days. The list of required components is quite big and > may change across different ARM SoC vendors. As an example, the following > components are involved in DVFS on Renesas Salvator-X board which has R-Car > Gen3 SoC installed: generic clock, regulator and thermal frameworks, Vendor’s > CPG, PMIC, AVS, THS drivers, i2c support, etc. > > We were considering a few possible approaches of hypervisor based CPUFreqs on > ARM and came to conclusion to base this solution on popular at the moment, > already upstreamed to Linux, ARM System Control and Power Interface(SCPI) > protocol [1]. We chose SCPI protocol instead of newer ARM System Control and > Management Interface (SCMI) protocol [2] since it is widely spread in Linux, > there are good examples how to use it, the range of capabilities it has is > enough for implementing hypervisor based CPUFreq and, what is more, upstream > Linux support for SCMI is missed so far, but SCMI could be used as well. > > Briefly speaking, the SCPI protocol is used between the System Control > Processor(SCP) and the Application Processors(AP). The mailbox feature > provides a mechanism for inter-processor communication between SCP and AP. > The main purpose of SCP is to offload different PM related tasks from AP and > one of the services that SCP provides is Dynamic voltage and frequency > scaling (DVFS), it is what we actually need for CPUFreq. I will describe this > approach in details down the text. > > Let me explain a bit more what these possible approaches are: > > 1. “Xen+hwdom” solution. > GlobalLogic team proposed split model [3], where “hwdom-cpufreq” frontend > driver in Xen interacts with the “xen-cpufreq” backend driver in Linux hwdom > (possibly dom0) in order to scale physical CPUs. This solution hasn’t been > accepted by Xen community yet and seems it is not going to be accepted > without taking into the account still unanswered major questions and proving > that “all-in-Xen” solution, which Xen community considered as more > architecturally cleaner option, would be unworkable in practice. > The other reasons why we decided not to stick to this approach are complex > communication interface between Xen and hwdom: event channel, hypercalls, > syscalls, passing CPU info via DT, etc and possible synchronization issues > with a proposed solution. > Although it is worth to mention that the beauty of this approach was that > there wouldn’t be a need to port a lot of things to Xen. All frequency > changing interface and all dependent components which needed CPUFreq to be > functional were already in place. > Although this approach is not used, still I picked a few already acked > patches which made ACPI specific CPUFreq stuff more generic. > > 2. “all-in-Xen” solution. > This implies that all CPUFreq related stuff should be located in Xen. > Community considered this solution as more architecturally cleaner option > than “Xen+hwdom” one. No layering violation comparing with the previous > approach (letting guest OS manage one or more physical CPUs is more of a > layering violation). > This solution looks better, but to be honest, we are not in favor of this > solution as well. We expect enormous developing effort to get this support in > (the scope of required components looks unreal) and maintain it. So, we > decided not to stick to this approach as well. > > 3. “Xen+SCP(ARM TF)” solution. > It is yet another solution based on ARM SCPI protocol. The generic idea here > is that there is a firmware, which being a server runs on some dedicated IP > core (server), provides different PM services (DVFS, sensors, etc
Re: [Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way
On Tue, 5 Dec 2017, Julien Grall wrote: > Hi all, > > Even though it is an Arm failure, I have CCed x86 folks to get feedback on the > approach. I have a WIP branch I could share if that interest people. > > Few months ago, we noticed an heisenbug on jobs run by osstest on the > cubietrucks (see [1]). From the log, we figured out that the guest vCPU 0 is > in data/prefetch abort state at early boot. I have been able to reproduce it > reliably, although from the little information I have I think it is related to > a cache issue because we don't trap cache maintenance instructions by set/way. > > This is a set of 3 instructions (clean, clean & invalidate, invalidate) > working on a given cache level by S/W. Because the OS is not allowed to infer > the S/W to PA mapping, it can only use S/W to nuke the whole cache. "The > expected usage of the cache maintenance that operate by set/way is associated > with powerdown and powerup of caches, if this is required by the > implementation" (see D3-2020 ARM DDI 0487B.b). > > Those instructions will target a local processor and usually working in batch > for nuking the cache. This means if the vCPU is migrated to another pCPU in > the middle of the process, the cache may not be cleaned. This would result to > data corruption and potential crash of the OS. > > Thankfully, the Arm architecture offers a way to trap all the cache > maintenance instructions by S/W (e.g HCR_EL2.TSW). Xen will need to set that > bit and handle S/W. > > The major question now is how to handle them. S/W instructions are difficult > to virtualize (see ARMv7 ARM B1.14.4). > > The suggested policy is based on the KVM one: > - If we trap a S/W instructions, we enable VM trapping (e.g > HCR_EL2.TVM) to detect cache being turned on/off, and do a full clean. > - We flush the caches on both caches being turned on and off. > - Once the caches are enabled, we stop trapping VM instructions. > > Doing a full clean will require to go through the P2M and flush the entries > one by one. At the moment, all the memory is mapped. As you can imagine > flushing guest with hundreds of MB will take a very long time (Linux timeout > during CPU bring). > > Therefore, we need a way to limit the number of entries we need to flush. The > suggested solution here is to introduce Populate On Demand (PoD) on Arm. > > The guest would boot with no RAM mapped in stage-2 page-table. At every > prefetch/data abort, the RAM would be mapped using preferably 2MB chunk or > 4KB. This means that when S/W would be used, the number of entries mapped > would be very limited. However, for safety, the flush should be preemptible. > > For those been worry about the performance impact, I have looked at the > current use of S/W instructions: > - Linux Arm64: The last used in the kernel was beginning of 2015 > - Linux Arm32: Still use S/W for boot and secondary CPU bring-up. No > plan to change. > - UEFI: A couple of use in UEFI, but I have heard they plan to remove > them (need confirmation). > > I haven't looked at all the OSes. However, given the Arm Arm clearly state S/W > instructions are not easily virtualizable, I would expect guest OSes > developers to try there best to limit the use of the instructions. > > To limit the performance impact, we could introduce a guest option to tell > whether the guest will use S/W. If it does plan to use S/W, PoD will be > disabled. > > Now regarding the hardware domain. At the moment, it has its RAM direct > mapped. Supporting direct mapping in PoD will be quite a pain for a limited > benefits (see why above). In that case I would suggest to impose vCPU pinning > for the hardware domain if the S/W are expected to be used. Again, a command > line option could be introduced here. > > Any feedbacks on the approach will be welcomed. Could we pin the hwdom vcpus only at boot time, until all S/W operations are issued, then "release" them? If we can detect the last expected S/W operation with some sort of heuristic. Given the information provided above, would it make sense to consider avoiding PoD for arm64 kernel direct boots? ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-next 01/16] xen/arm: raw_copy_to_guest_helper: Rename flush_dcache to flags
On Thu, 23 Nov 2017, Julien Grall wrote:
> In a follow-up patch, it will be necessary to pass more flags to the
> function.
>
> Rename flush_dcache to flags and introduce a define to tell whether the
> cache needs to be flushed after the copy.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> xen/arch/arm/guestcopy.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
> index 4ee07fcea3..2620e659b4 100644
> --- a/xen/arch/arm/guestcopy.c
> +++ b/xen/arch/arm/guestcopy.c
> @@ -5,8 +5,10 @@
> #include
> #include
>
> +#define COPY_flush_dcache (1U << 0)
> +
> static unsigned long raw_copy_to_guest_helper(void *to, const void *from,
> - unsigned len, int flush_dcache)
> + unsigned len, int flags)
> {
> /* XXX needs to handle faults */
> unsigned offset = (vaddr_t)to & ~PAGE_MASK;
> @@ -24,7 +26,7 @@ static unsigned long raw_copy_to_guest_helper(void *to,
> const void *from,
> p = __map_domain_page(page);
> p += offset;
> memcpy(p, from, size);
> -if ( flush_dcache )
> +if ( flags & COPY_flush_dcache )
> clean_dcache_va_range(p, size);
>
> unmap_domain_page(p - offset);
> @@ -50,7 +52,7 @@ unsigned long raw_copy_to_guest(void *to, const void *from,
> unsigned len)
> unsigned long raw_copy_to_guest_flush_dcache(void *to, const void *from,
> unsigned len)
> {
> -return raw_copy_to_guest_helper(to, from, len, 1);
> +return raw_copy_to_guest_helper(to, from, len, COPY_flush_dcache);
> }
>
> unsigned long raw_clear_guest(void *to, unsigned len)
> --
> 2.11.0
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-next 02/16] xen/arm: raw_copy_to_guest_helper: Rework the prototype and rename it
On Thu, 23 Nov 2017, Julien Grall wrote:
> All the helpers within arch/arm/guestcopy.c are doing the same things:
> copy data from/to the guest.
>
> At the moment, the logic is duplicated in each helpers making more
> difficult to implement new variant.
>
> The first step for the consolidation is to get a common prototype and a
> base. For convenience (it is at the beginning of the file!),
> raw_copy_to_guest_helper is chosen.
>
> The function is now renamed copy_guest to show it will be a
> generic function to copy data from/to the guest. Note that for now, only
> copying to guest virtual address is supported. Follow-up patches will
> extend the support.
>
> Signed-off-by: Julien Grall
> ---
> xen/arch/arm/guestcopy.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
> index 2620e659b4..d1cfbe922c 100644
> --- a/xen/arch/arm/guestcopy.c
> +++ b/xen/arch/arm/guestcopy.c
> @@ -7,11 +7,11 @@
>
> #define COPY_flush_dcache (1U << 0)
>
> -static unsigned long raw_copy_to_guest_helper(void *to, const void *from,
> - unsigned len, int flags)
> +static unsigned long copy_guest(void *buf, paddr_t addr, unsigned int len,
> +unsigned int flags)
Why not use vaddr_t ?
> {
> /* XXX needs to handle faults */
> -unsigned offset = (vaddr_t)to & ~PAGE_MASK;
> +unsigned offset = addr & ~PAGE_MASK;
>
> while ( len )
> {
> @@ -19,21 +19,21 @@ static unsigned long raw_copy_to_guest_helper(void *to,
> const void *from,
> unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
> struct page_info *page;
>
> -page = get_page_from_gva(current, (vaddr_t) to, GV2M_WRITE);
> +page = get_page_from_gva(current, addr, GV2M_WRITE);
> if ( page == NULL )
> return len;
>
> p = __map_domain_page(page);
> p += offset;
> -memcpy(p, from, size);
> +memcpy(p, buf, size);
> if ( flags & COPY_flush_dcache )
> clean_dcache_va_range(p, size);
>
> unmap_domain_page(p - offset);
> put_page(page);
> len -= size;
> -from += size;
> -to += size;
> +buf += size;
> +addr += size;
> /*
> * After the first iteration, guest virtual address is correctly
> * aligned to PAGE_SIZE.
> @@ -46,13 +46,13 @@ static unsigned long raw_copy_to_guest_helper(void *to,
> const void *from,
>
> unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len)
> {
> -return raw_copy_to_guest_helper(to, from, len, 0);
> +return copy_guest((void *)from, (unsigned long)to, len, 0);
> }
>
> unsigned long raw_copy_to_guest_flush_dcache(void *to, const void *from,
> unsigned len)
> {
> -return raw_copy_to_guest_helper(to, from, len, COPY_flush_dcache);
> +return copy_guest((void *)from, (unsigned long)to, len,
> COPY_flush_dcache);
> }
>
> unsigned long raw_clear_guest(void *to, unsigned len)
> --
> 2.11.0
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-next 03/16] xen/arm: Extend copy_to_guest to support copying from guest VA and use it
On Thu, 23 Nov 2017, Julien Grall wrote:
> The only differences between copy_to_guest (formerly called
> raw_copy_to_guest_helper) and raw_copy_from_guest is:
> - The direction of the memcpy
> - The permission use for translating the address
>
> Extend copy_to_guest to support copying from guest VA by adding using a
> bit in the flags to tell the direction of the copy.
>
> Lastly, reimplement raw_copy_from_guest using copy_to_guest.
>
> Signed-off-by: Julien Grall
> ---
> xen/arch/arm/guestcopy.c | 46 +-
> 1 file changed, 13 insertions(+), 33 deletions(-)
>
> diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
> index d1cfbe922c..1ffa717ca6 100644
> --- a/xen/arch/arm/guestcopy.c
> +++ b/xen/arch/arm/guestcopy.c
> @@ -6,6 +6,8 @@
> #include
>
> #define COPY_flush_dcache (1U << 0)
> +#define COPY_from_guest (0U << 1)
> +#define COPY_to_guest (1U << 1)
>
> static unsigned long copy_guest(void *buf, paddr_t addr, unsigned int len,
> unsigned int flags)
> @@ -19,13 +21,18 @@ static unsigned long copy_guest(void *buf, paddr_t addr,
> unsigned int len,
> unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
> struct page_info *page;
>
> -page = get_page_from_gva(current, addr, GV2M_WRITE);
> +page = get_page_from_gva(current, addr,
> + (flags & COPY_to_guest) ? GV2M_WRITE :
> GV2M_READ);
> if ( page == NULL )
> return len;
>
> p = __map_domain_page(page);
> p += offset;
> -memcpy(p, buf, size);
> +if ( flags & COPY_to_guest )
> +memcpy(p, buf, size);
> +else
> +memcpy(buf, p, size);
> +
> if ( flags & COPY_flush_dcache )
> clean_dcache_va_range(p, size);
>
> @@ -46,13 +53,14 @@ static unsigned long copy_guest(void *buf, paddr_t addr,
> unsigned int len,
>
> unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len)
> {
> -return copy_guest((void *)from, (unsigned long)to, len, 0);
> +return copy_guest((void *)from, (unsigned long)to, len, COPY_to_guest);
> }
>
> unsigned long raw_copy_to_guest_flush_dcache(void *to, const void *from,
> unsigned len)
> {
> -return copy_guest((void *)from, (unsigned long)to, len,
> COPY_flush_dcache);
> +return copy_guest((void *)from, (unsigned long)to, len,
> + COPY_to_guest | COPY_flush_dcache);
> }
>
> unsigned long raw_clear_guest(void *to, unsigned len)
> @@ -90,35 +98,7 @@ unsigned long raw_clear_guest(void *to, unsigned len)
>
> unsigned long raw_copy_from_guest(void *to, const void __user *from,
> unsigned len)
> {
> -unsigned offset = (vaddr_t)from & ~PAGE_MASK;
> -
> -while ( len )
> -{
> -void *p;
> -unsigned size = min(len, (unsigned)(PAGE_SIZE - offset));
> -struct page_info *page;
> -
> -page = get_page_from_gva(current, (vaddr_t) from, GV2M_READ);
> -if ( page == NULL )
> -return len;
> -
> -p = __map_domain_page(page);
> -p += ((vaddr_t)from & (~PAGE_MASK));
> -
> -memcpy(to, p, size);
> -
> -unmap_domain_page(p);
> -put_page(page);
> -len -= size;
> -from += size;
> -to += size;
> -/*
> - * After the first iteration, guest virtual address is correctly
> - * aligned to PAGE_SIZE.
> - */
> -offset = 0;
> -}
> -return 0;
> +return copy_guest(to, (unsigned long)from, len, COPY_from_guest);
> }
Same question about vaddr_t for the cast.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-next 04/16] xen/arm: Extend copy_to_guest to support zeroing guest VA and use it
On Thu, 23 Nov 2017, Julien Grall wrote:
> The function copy_to_guest can easily be extended to support zeroing
> guest VA. To avoid using a new bit, it is considered that a NULL buffer
> (i.e buf == NULL) means the guest memory will be zeroed.
>
> Lastly, reimplement raw_clear_guest using copy_to_guest.
>
> Signed-off-by: Julien Grall
Aside from the usual question about vaddr_t:
Reviewed-by: Stefano Stabellini
> ---
> xen/arch/arm/guestcopy.c | 41 +++--
> 1 file changed, 11 insertions(+), 30 deletions(-)
>
> diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
> index 1ffa717ca6..3aaa80859e 100644
> --- a/xen/arch/arm/guestcopy.c
> +++ b/xen/arch/arm/guestcopy.c
> @@ -29,7 +29,16 @@ static unsigned long copy_guest(void *buf, paddr_t addr,
> unsigned int len,
> p = __map_domain_page(page);
> p += offset;
> if ( flags & COPY_to_guest )
> -memcpy(p, buf, size);
> +{
> +/*
> + * buf will be NULL when the caller request to zero the
> + * guest memory.
> + */
> +if ( buf )
> +memcpy(p, buf, size);
> +else
> +memset(p, 0, size);
> +}
> else
> memcpy(buf, p, size);
>
> @@ -65,35 +74,7 @@ unsigned long raw_copy_to_guest_flush_dcache(void *to,
> const void *from,
>
> unsigned long raw_clear_guest(void *to, unsigned len)
> {
> -/* XXX needs to handle faults */
> -unsigned offset = (vaddr_t)to & ~PAGE_MASK;
> -
> -while ( len )
> -{
> -void *p;
> -unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
> -struct page_info *page;
> -
> -page = get_page_from_gva(current, (vaddr_t) to, GV2M_WRITE);
> -if ( page == NULL )
> -return len;
> -
> -p = __map_domain_page(page);
> -p += offset;
> -memset(p, 0x00, size);
> -
> -unmap_domain_page(p - offset);
> -put_page(page);
> -len -= size;
> -to += size;
> -/*
> - * After the first iteration, guest virtual address is correctly
> - * aligned to PAGE_SIZE.
> - */
> -offset = 0;
> -}
> -
> -return 0;
> +return copy_guest(NULL, (unsigned long)to, len, COPY_to_guest);
> }
>
> unsigned long raw_copy_from_guest(void *to, const void __user *from,
> unsigned len)
> --
> 2.11.0
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-next 05/16] xen/arm: guest_copy: Extend the prototype to pass the vCPU
On Thu, 23 Nov 2017, Julien Grall wrote:
> Currently, guest_copy assumes the copy will only be done for the current
> vCPU. A follow-up patch will require to use a different vCPU.
>
> So extend the prototype to pass the vCPU.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> xen/arch/arm/guestcopy.c | 13 +++--
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
> index 3aaa80859e..487f5ab82d 100644
> --- a/xen/arch/arm/guestcopy.c
> +++ b/xen/arch/arm/guestcopy.c
> @@ -10,7 +10,7 @@
> #define COPY_to_guest (1U << 1)
>
> static unsigned long copy_guest(void *buf, paddr_t addr, unsigned int len,
> -unsigned int flags)
> +struct vcpu *v, unsigned int flags)
> {
> /* XXX needs to handle faults */
> unsigned offset = addr & ~PAGE_MASK;
> @@ -21,7 +21,7 @@ static unsigned long copy_guest(void *buf, paddr_t addr,
> unsigned int len,
> unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
> struct page_info *page;
>
> -page = get_page_from_gva(current, addr,
> +page = get_page_from_gva(v, addr,
> (flags & COPY_to_guest) ? GV2M_WRITE :
> GV2M_READ);
> if ( page == NULL )
> return len;
> @@ -62,24 +62,25 @@ static unsigned long copy_guest(void *buf, paddr_t addr,
> unsigned int len,
>
> unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len)
> {
> -return copy_guest((void *)from, (unsigned long)to, len, COPY_to_guest);
> +return copy_guest((void *)from, (unsigned long)to, len,
> + current, COPY_to_guest);
> }
>
> unsigned long raw_copy_to_guest_flush_dcache(void *to, const void *from,
> unsigned len)
> {
> return copy_guest((void *)from, (unsigned long)to, len,
> - COPY_to_guest | COPY_flush_dcache);
> + current, COPY_to_guest | COPY_flush_dcache);
> }
>
> unsigned long raw_clear_guest(void *to, unsigned len)
> {
> -return copy_guest(NULL, (unsigned long)to, len, COPY_to_guest);
> +return copy_guest(NULL, (unsigned long)to, len, current, COPY_to_guest);
> }
>
> unsigned long raw_copy_from_guest(void *to, const void __user *from,
> unsigned len)
> {
> -return copy_guest(to, (unsigned long)from, len, COPY_from_guest);
> +return copy_guest(to, (unsigned long)from, len, current,
> COPY_from_guest);
> }
>
> /*
> --
> 2.11.0
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-next 06/16] xen/arm: Extend copy_to_guest to support copying from/to guest physical address
On Thu, 23 Nov 2017, Julien Grall wrote:
> The only differences between copy_to_guest and access_guest_memory_by_ipa are:
> - The latter does not support copying data crossing page boundary
> - The former is copying from/to guest VA whilst the latter from
> guest PA
>
> copy_to_guest can easily be extended to support copying from/to guest
> physical address. For that a new bit is used to tell whether linear
> address or ipa is been used.
>
> Lastly access_guest_memory_by_ipa is reimplemented using copy_to_guest.
> This also has the benefits to extend the use of it, it is now possible
> to copy data crossing page boundary.
>
> Signed-off-by: Julien Grall
Ah! This is the reason why previous patches were not using vaddr_t. It
makes sense now. May I suggest we use something different from paddr_t
in copy_guest for addr type? I don't think is correct to specify addr as
paddr_t when it could be vaddr_t; in the future we could have type
checks on them.
I suggest we specify it as u64, but if you have a better idea go for it.
> ---
> xen/arch/arm/guestcopy.c | 86
> ++--
> 1 file changed, 39 insertions(+), 47 deletions(-)
>
> diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
> index 487f5ab82d..be53bee559 100644
> --- a/xen/arch/arm/guestcopy.c
> +++ b/xen/arch/arm/guestcopy.c
> @@ -8,6 +8,31 @@
> #define COPY_flush_dcache (1U << 0)
> #define COPY_from_guest (0U << 1)
> #define COPY_to_guest (1U << 1)
> +#define COPY_ipa(0U << 2)
> +#define COPY_linear (1U << 2)
> +
> +static struct page_info *translate_get_page(struct vcpu *v, paddr_t addr,
> +bool linear, bool write)
> +{
> +p2m_type_t p2mt;
> +struct page_info *page;
> +
> +if ( linear )
> +return get_page_from_gva(v, addr, write ? GV2M_WRITE : GV2M_READ);
> +
> +page = get_page_from_gfn(v->domain, paddr_to_pfn(addr), &p2mt,
> P2M_ALLOC);
> +
> +if ( !page )
> +return NULL;
> +
> +if ( !p2m_is_ram(p2mt) )
> +{
> +put_page(page);
> +return NULL;
> +}
> +
> +return page;
> +}
>
> static unsigned long copy_guest(void *buf, paddr_t addr, unsigned int len,
> struct vcpu *v, unsigned int flags)
> @@ -21,8 +46,8 @@ static unsigned long copy_guest(void *buf, paddr_t addr,
> unsigned int len,
> unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
> struct page_info *page;
>
> -page = get_page_from_gva(v, addr,
> - (flags & COPY_to_guest) ? GV2M_WRITE :
> GV2M_READ);
> +page = translate_get_page(v, addr, flags & COPY_linear,
> + flags & COPY_to_guest);
> if ( page == NULL )
> return len;
>
> @@ -63,73 +88,40 @@ static unsigned long copy_guest(void *buf, paddr_t addr,
> unsigned int len,
> unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len)
> {
> return copy_guest((void *)from, (unsigned long)to, len,
> - current, COPY_to_guest);
> + current, COPY_to_guest | COPY_linear);
> }
>
> unsigned long raw_copy_to_guest_flush_dcache(void *to, const void *from,
> unsigned len)
> {
> return copy_guest((void *)from, (unsigned long)to, len,
> - current, COPY_to_guest | COPY_flush_dcache);
> + current, COPY_to_guest | COPY_flush_dcache |
> COPY_linear);
> }
>
> unsigned long raw_clear_guest(void *to, unsigned len)
> {
> -return copy_guest(NULL, (unsigned long)to, len, current, COPY_to_guest);
> +return copy_guest(NULL, (unsigned long)to, len, current,
> + COPY_to_guest | COPY_linear);
> }
>
> unsigned long raw_copy_from_guest(void *to, const void __user *from,
> unsigned len)
> {
> -return copy_guest(to, (unsigned long)from, len, current,
> COPY_from_guest);
> +return copy_guest(to, (unsigned long)from, len, current,
> + COPY_from_guest | COPY_linear);
> }
>
> -/*
> - * Temporarily map one physical guest page and copy data to or from it.
> - * The data to be copied cannot cross a page boundary.
> - */
> int access_guest_memory_by_ipa(struct domain *d, paddr_t gpa, void *buf,
> uint32_t size, bool is_write)
> {
> -struct page_info *page;
> -uint64_t offset = gpa & ~PAGE_MASK; /* Offset within the mapped page */
> -p2m_type_t p2mt;
> -void *p;
> -
> -/* Do not cross a page boundary. */
> -if ( size > (PAGE_SIZE - offset) )
> -{
> -printk(XENLOG_G_ERR "d%d: guestcopy: memory access crosses page
> boundary.\n",
> - d->domain_id);
> -return -EINVAL;
> -}
I don't know if we necessarely care about this, but with this change
this error path goes away. Do we want to keep
Re: [Xen-devel] [PATCH for-next 06/16] xen/arm: Extend copy_to_guest to support copying from/to guest physical address
On Tue, 5 Dec 2017, Stefano Stabellini wrote:
> On Thu, 23 Nov 2017, Julien Grall wrote:
> > The only differences between copy_to_guest and access_guest_memory_by_ipa
> > are:
> > - The latter does not support copying data crossing page boundary
> > - The former is copying from/to guest VA whilst the latter from
> > guest PA
> >
> > copy_to_guest can easily be extended to support copying from/to guest
> > physical address. For that a new bit is used to tell whether linear
> > address or ipa is been used.
> >
> > Lastly access_guest_memory_by_ipa is reimplemented using copy_to_guest.
> > This also has the benefits to extend the use of it, it is now possible
> > to copy data crossing page boundary.
> >
> > Signed-off-by: Julien Grall
>
> Ah! This is the reason why previous patches were not using vaddr_t. It
> makes sense now. May I suggest we use something different from paddr_t
> in copy_guest for addr type? I don't think is correct to specify addr as
> paddr_t when it could be vaddr_t; in the future we could have type
> checks on them.
>
> I suggest we specify it as u64, but if you have a better idea go for it.
>
>
> > ---
> > xen/arch/arm/guestcopy.c | 86
> > ++--
> > 1 file changed, 39 insertions(+), 47 deletions(-)
> >
> > diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
> > index 487f5ab82d..be53bee559 100644
> > --- a/xen/arch/arm/guestcopy.c
> > +++ b/xen/arch/arm/guestcopy.c
> > @@ -8,6 +8,31 @@
> > #define COPY_flush_dcache (1U << 0)
> > #define COPY_from_guest (0U << 1)
> > #define COPY_to_guest (1U << 1)
> > +#define COPY_ipa(0U << 2)
> > +#define COPY_linear (1U << 2)
> > +
> > +static struct page_info *translate_get_page(struct vcpu *v, paddr_t addr,
> > +bool linear, bool write)
> > +{
> > +p2m_type_t p2mt;
> > +struct page_info *page;
> > +
> > +if ( linear )
> > +return get_page_from_gva(v, addr, write ? GV2M_WRITE : GV2M_READ);
> > +
> > +page = get_page_from_gfn(v->domain, paddr_to_pfn(addr), &p2mt,
> > P2M_ALLOC);
> > +
> > +if ( !page )
> > +return NULL;
> > +
> > +if ( !p2m_is_ram(p2mt) )
> > +{
> > +put_page(page);
> > +return NULL;
> > +}
> > +
> > +return page;
> > +}
> >
> > static unsigned long copy_guest(void *buf, paddr_t addr, unsigned int len,
> > struct vcpu *v, unsigned int flags)
> > @@ -21,8 +46,8 @@ static unsigned long copy_guest(void *buf, paddr_t addr,
> > unsigned int len,
> > unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
> > struct page_info *page;
> >
> > -page = get_page_from_gva(v, addr,
> > - (flags & COPY_to_guest) ? GV2M_WRITE :
> > GV2M_READ);
> > +page = translate_get_page(v, addr, flags & COPY_linear,
> > + flags & COPY_to_guest);
> > if ( page == NULL )
> > return len;
> >
> > @@ -63,73 +88,40 @@ static unsigned long copy_guest(void *buf, paddr_t
> > addr, unsigned int len,
> > unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len)
> > {
> > return copy_guest((void *)from, (unsigned long)to, len,
> > - current, COPY_to_guest);
> > + current, COPY_to_guest | COPY_linear);
> > }
> >
> > unsigned long raw_copy_to_guest_flush_dcache(void *to, const void *from,
> > unsigned len)
> > {
> > return copy_guest((void *)from, (unsigned long)to, len,
> > - current, COPY_to_guest | COPY_flush_dcache);
> > + current, COPY_to_guest | COPY_flush_dcache |
> > COPY_linear);
> > }
> >
> > unsigned long raw_clear_guest(void *to, unsigned len)
> > {
> > -return copy_guest(NULL, (unsigned long)to, len, current,
> > COPY_to_guest);
> > +return copy_guest(NULL, (unsigned long)to, len, current,
> > + COPY_to_guest | COPY_linear);
> > }
> >
> > unsigned long raw_copy_from_guest(void *to, const void __user *from,
> > unsigned len)
> > {
> > -return copy_guest(to, (unsigned long)from, len, current,
>
Re: [Xen-devel] [PATCH for-next 07/16] xen/arm: Introduce copy_to_guest_phys_flush_dcache
On Thu, 23 Nov 2017, Julien Grall wrote:
> Hi Andrew,
>
> On 23/11/17 18:49, Andrew Cooper wrote:
> > On 23/11/17 18:32, Julien Grall wrote:
> > > This new function will be used in a follow-up patch to copy data to the
> > > guest
> > > using the IPA (aka guest physical address) and then clean the cache.
> > >
> > > Signed-off-by: Julien Grall
> > > ---
> > > xen/arch/arm/guestcopy.c | 10 ++
> > > xen/include/asm-arm/guest_access.h | 6 ++
> > > 2 files changed, 16 insertions(+)
> > >
> > > diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
> > > index be53bee559..7958663970 100644
> > > --- a/xen/arch/arm/guestcopy.c
> > > +++ b/xen/arch/arm/guestcopy.c
> > > @@ -110,6 +110,16 @@ unsigned long raw_copy_from_guest(void *to, const
> > > void __user *from, unsigned le
> > > COPY_from_guest | COPY_linear);
> > > }
> > > +unsigned long copy_to_guest_phys_flush_dcache(struct domain *d,
> > > + paddr_t gpa,
> > > + void *buf,
> > > + unsigned int len)
> > > +{
> > > +/* P2M is shared between all vCPUs, so the vCPU used does not matter.
> > > */
> >
> > Be very careful with this line of thinking. It is only works after
> > DOMCTL_max_vcpus has succeeded, and before that point, it is a latent
> > NULL pointer dereference.
>
> I really don't expect that function been used before DOMCT_max_vcpus is set.
> It is only used for hardware emulation or Xen loading image into the hardware
> domain memory. I could add a check d->vcpus to be safe.
>
> >
> > Also, what about vcpus configured with alternative views?
>
> It is not important because the underlying call is get_page_from_gfn that does
> not care about the alternative view (that function take a domain in
> parameter). I can update the comment.
Since this is a new function, would it make sense to take a struct
vcpu* as parameter, instead of a struct domain* ?___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-next 08/16] xen/arm: kernel: Rework kernel_zimage_load to use the generic copy helper
On Thu, 23 Nov 2017, Julien Grall wrote:
> The function kernel_zimage is dealing with IPA but uses gvirt_to_maddr to
> do the translation. This is currently working fine because the stage-1 MMU
> is disabled.
>
> Furthermore, the function is implementing its own copy to guest resulting
> in code duplication and making more difficult to update the logic in
> page-tables (such support for Populate On Demand).
>
> The new copy_to_guest_phys_flush_dcache could be used here by
> temporarily mapping the full kernel in the virtual space.
>
> Signed-off-by: Julien Grall
> ---
> xen/arch/arm/domain_build.c | 1 +
> xen/arch/arm/kernel.c | 33 -
> xen/arch/arm/kernel.h | 2 ++
> 3 files changed, 15 insertions(+), 21 deletions(-)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index c74f4dd69d..3f87bf2051 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -2133,6 +2133,7 @@ int construct_dom0(struct domain *d)
> d->max_pages = ~0U;
>
> kinfo.unassigned_mem = dom0_mem;
> +kinfo.d = d;
>
> rc = kernel_probe(&kinfo);
> if ( rc < 0 )
> diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
> index a6c6413712..2fb0b9684d 100644
> --- a/xen/arch/arm/kernel.c
> +++ b/xen/arch/arm/kernel.c
> @@ -15,6 +15,8 @@
> #include
> #include
>
> +#include
> +
> #include "kernel.h"
>
> #define UIMAGE_MAGIC 0x27051956
> @@ -157,7 +159,8 @@ static void kernel_zimage_load(struct kernel_info *info)
> paddr_t load_addr = kernel_zimage_place(info);
> paddr_t paddr = info->zimage.kernel_addr;
> paddr_t len = info->zimage.len;
> -unsigned long offs;
> +void *kernel;
> +int rc;
>
> info->entry = load_addr;
>
> @@ -165,29 +168,17 @@ static void kernel_zimage_load(struct kernel_info *info)
>
> printk("Loading zImage from %"PRIpaddr" to %"PRIpaddr"-%"PRIpaddr"\n",
> paddr, load_addr, load_addr + len);
> -for ( offs = 0; offs < len; )
> -{
> -uint64_t par;
> -paddr_t s, l, ma = 0;
> -void *dst;
> -
> -s = offs & ~PAGE_MASK;
> -l = min(PAGE_SIZE - s, len);
> -
> -par = gvirt_to_maddr(load_addr + offs, &ma, GV2M_WRITE);
> -if ( par )
> -{
> -panic("Unable to map translate guest address");
> -return;
> -}
>
> -dst = map_domain_page(maddr_to_mfn(ma));
> +kernel = ioremap_wc(paddr, len);
Why ioremap_wc?
> +if ( !kernel )
> +panic("Unable to map the hwdom kernel");
>
> -copy_from_paddr(dst + s, paddr + offs, l);
> +rc = copy_to_guest_phys_flush_dcache(info->d, load_addr,
> + kernel, len);
> +if ( rc != 0 )
> +panic("Unable to copy the kernel in the hwdom memory");
>
> -unmap_domain_page(dst);
> -offs += l;
> -}
> +iounmap(kernel);
> }
>
> /*
> diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
> index c1b07d4f7b..6d695097b5 100644
> --- a/xen/arch/arm/kernel.h
> +++ b/xen/arch/arm/kernel.h
> @@ -15,6 +15,8 @@ struct kernel_info {
> enum domain_type type;
> #endif
>
> +struct domain *d;
> +
> void *fdt; /* flat device tree */
> paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
> struct meminfo mem;
> --
> 2.11.0
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-next 08/16] xen/arm: kernel: Rework kernel_zimage_load to use the generic copy helper
On Tue, 5 Dec 2017, Stefano Stabellini wrote:
> On Thu, 23 Nov 2017, Julien Grall wrote:
> > The function kernel_zimage is dealing with IPA but uses gvirt_to_maddr to
> > do the translation. This is currently working fine because the stage-1 MMU
> > is disabled.
> >
> > Furthermore, the function is implementing its own copy to guest resulting
> > in code duplication and making more difficult to update the logic in
> > page-tables (such support for Populate On Demand).
> >
> > The new copy_to_guest_phys_flush_dcache could be used here by
> > temporarily mapping the full kernel in the virtual space.
> >
> > Signed-off-by: Julien Grall
> > ---
> > xen/arch/arm/domain_build.c | 1 +
> > xen/arch/arm/kernel.c | 33 -
> > xen/arch/arm/kernel.h | 2 ++
> > 3 files changed, 15 insertions(+), 21 deletions(-)
> >
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index c74f4dd69d..3f87bf2051 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -2133,6 +2133,7 @@ int construct_dom0(struct domain *d)
> > d->max_pages = ~0U;
> >
> > kinfo.unassigned_mem = dom0_mem;
> > +kinfo.d = d;
> >
> > rc = kernel_probe(&kinfo);
> > if ( rc < 0 )
> > diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
> > index a6c6413712..2fb0b9684d 100644
> > --- a/xen/arch/arm/kernel.c
> > +++ b/xen/arch/arm/kernel.c
> > @@ -15,6 +15,8 @@
> > #include
> > #include
> >
> > +#include
> > +
> > #include "kernel.h"
> >
> > #define UIMAGE_MAGIC 0x27051956
> > @@ -157,7 +159,8 @@ static void kernel_zimage_load(struct kernel_info *info)
> > paddr_t load_addr = kernel_zimage_place(info);
> > paddr_t paddr = info->zimage.kernel_addr;
> > paddr_t len = info->zimage.len;
> > -unsigned long offs;
> > +void *kernel;
> > +int rc;
> >
> > info->entry = load_addr;
> >
> > @@ -165,29 +168,17 @@ static void kernel_zimage_load(struct kernel_info
> > *info)
> >
> > printk("Loading zImage from %"PRIpaddr" to %"PRIpaddr"-%"PRIpaddr"\n",
> > paddr, load_addr, load_addr + len);
> > -for ( offs = 0; offs < len; )
> > -{
> > -uint64_t par;
> > -paddr_t s, l, ma = 0;
> > -void *dst;
> > -
> > -s = offs & ~PAGE_MASK;
> > -l = min(PAGE_SIZE - s, len);
> > -
> > -par = gvirt_to_maddr(load_addr + offs, &ma, GV2M_WRITE);
> > -if ( par )
> > -{
> > -panic("Unable to map translate guest address");
> > -return;
> > -}
> >
> > -dst = map_domain_page(maddr_to_mfn(ma));
> > +kernel = ioremap_wc(paddr, len);
>
> Why ioremap_wc?
That is because we kept the same attributes used today by
copy_from_paddr. Makes sense.
Reviewed-by: Stefano Stabellini
> > +if ( !kernel )
> > +panic("Unable to map the hwdom kernel");
> >
> > -copy_from_paddr(dst + s, paddr + offs, l);
> > +rc = copy_to_guest_phys_flush_dcache(info->d, load_addr,
> > + kernel, len);
> > +if ( rc != 0 )
> > +panic("Unable to copy the kernel in the hwdom memory");
> >
> > -unmap_domain_page(dst);
> > -offs += l;
> > -}
> > +iounmap(kernel);
> > }
> >
> > /*
> > diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
> > index c1b07d4f7b..6d695097b5 100644
> > --- a/xen/arch/arm/kernel.h
> > +++ b/xen/arch/arm/kernel.h
> > @@ -15,6 +15,8 @@ struct kernel_info {
> > enum domain_type type;
> > #endif
> >
> > +struct domain *d;
> > +
> > void *fdt; /* flat device tree */
> > paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
> > struct meminfo mem;
> > --
> > 2.11.0
> >
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-next 09/16] xen/arm: domain_build: Rework initrd_load to use the generic copy helper
On Thu, 23 Nov 2017, Julien Grall wrote:
> The function initrd_load is dealing with IPA but uses gvirt_to_maddr to
> do the translation. This is currently working fine because the stage-1 MMU
> is disabled.
>
> Furthermore, the function is implementing its own copy to guest resulting
> in code duplication and making more difficult to update the logic in
> page-tables (such support for Populate On Demand).
>
> The new copy_to_guest_phys_flush_dcache could be used here by temporarily
> mapping the full initrd in the virtual space.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> xen/arch/arm/domain_build.c | 31 ---
> 1 file changed, 8 insertions(+), 23 deletions(-)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 3f87bf2051..42c2e16ef6 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1966,11 +1966,11 @@ static void initrd_load(struct kernel_info *kinfo)
> const struct bootmodule *mod = kinfo->initrd_bootmodule;
> paddr_t load_addr = kinfo->initrd_paddr;
> paddr_t paddr, len;
> -unsigned long offs;
> int node;
> int res;
> __be32 val[2];
> __be32 *cellp;
> +void __iomem *initrd;
>
> if ( !mod || !mod->size )
> return;
> @@ -2000,29 +2000,14 @@ static void initrd_load(struct kernel_info *kinfo)
> if ( res )
> panic("Cannot fix up \"linux,initrd-end\" property");
>
> -for ( offs = 0; offs < len; )
> -{
> -uint64_t par;
> -paddr_t s, l, ma = 0;
> -void *dst;
> -
> -s = offs & ~PAGE_MASK;
> -l = min(PAGE_SIZE - s, len);
> -
> -par = gvirt_to_maddr(load_addr + offs, &ma, GV2M_WRITE);
> -if ( par )
> -{
> -panic("Unable to translate guest address");
> -return;
> -}
> -
> -dst = map_domain_page(maddr_to_mfn(ma));
> +initrd = ioremap_wc(paddr, len);
> +if ( !initrd )
> +panic("Unable to map the hwdom initrd");
>
> -copy_from_paddr(dst + s, paddr + offs, l);
> -
> -unmap_domain_page(dst);
> -offs += l;
> -}
> +res = copy_to_guest_phys_flush_dcache(kinfo->d, load_addr,
> + initrd, len);
> +if ( res != 0 )
> +panic("Unable to copy the initrd in the hwdom memory");
> }
>
> static void evtchn_fixup(struct domain *d, struct kernel_info *kinfo)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-next 10/16] xen/arm: domain_build: Use copy_to_guest_phys_flush_dcache in dtb_load
On Thu, 23 Nov 2017, Julien Grall wrote:
> The function dtb_load is dealing with IPA but uses gvirt_to_maddr to do
> the translation. This is currently working fine because the stage-1 MMU
> is disabled.
>
> Rather than relying on such assumption, use the new
> copy_to_guest_phys_flush_dcache. This also result to a slightly more
> comprehensible code.
>
> Signed-off-by: Julien Grall
Yes definitely an improvement
Reviewed-by: Stefano Stabellini
> ---
> xen/arch/arm/domain_build.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 42c2e16ef6..9245753a6b 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1948,14 +1948,15 @@ static int prepare_acpi(struct domain *d, struct
> kernel_info *kinfo)
> #endif
> static void dtb_load(struct kernel_info *kinfo)
> {
> -void * __user dtb_virt = (void * __user)(register_t)kinfo->dtb_paddr;
> unsigned long left;
>
> printk("Loading dom0 DTB to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
> kinfo->dtb_paddr, kinfo->dtb_paddr + fdt_totalsize(kinfo->fdt));
>
> -left = raw_copy_to_guest_flush_dcache(dtb_virt, kinfo->fdt,
> -fdt_totalsize(kinfo->fdt));
> +left = copy_to_guest_phys_flush_dcache(kinfo->d, kinfo->dtb_paddr,
> + kinfo->fdt,
> + fdt_totalsize(kinfo->fdt));
> +
> if ( left != 0 )
> panic("Unable to copy the DTB to dom0 memory (left = %lu bytes)",
> left);
> xfree(kinfo->fdt);
> --
> 2.11.0
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH 06/31] cpufreq: make cpufreq driver more generalizable
On Wed, 6 Dec 2017, Jan Beulich wrote:
> >>> On 05.12.17 at 21:48, wrote:
> > You are right. We need to define a new struct for internal usage, for
> > example:
> >
> > struct xen_processor_performance_internal {
> > uint32_t flags; /* flag for Px sub info type */
> > uint32_t platform_limit; /* Platform limitation on freq usage */
> > struct xen_pct_register control_register;
> > struct xen_pct_register status_register;
> > uint32_t state_count; /* total available performance states */
> > struct xen_processor_px states;
> > struct xen_psd_package domain_info;
> > uint32_t shared_type; /* coordination type of this processor */
> > };
> >
> > Jan, Andrew, does this sound like a good approach to you?
>
> I'm afraid I don't have the time to go through this discussion (and
> the original patch) in detail to figure out the full context in which
> you raise the question. IOW please summarize things alongside
> the proposed structure, or alternatively Oleksandr could simply
> submit an updated patch to allow seeing the actual context
> (albeit in any case I can't promise timely feedback, given the
> number of pending patches plus all the work I still hope to be
> able to get done myself eventually.
>
> >From a brief check, I can't really figure much of a difference to
> the already existing (and internal) struct processor_performance.
Fair enough. Actually you have a good eye for being able to spot your
name in one of so many patch replies :-)
Oleksandr would like to call set_px_pminfo from a non-hypercall context,
meaning that there are no XEN_GUEST_HANDLE parameters. Today, struct
xen_processor_performance contains a
XEN_GUEST_HANDLE(xen_processor_px_t) states;
field. Instead of "faking" the XEN_GUEST_HANDLE field from Xen, I
suggested to modify set_px_pminfo to take a different struct, one
without any XEN_GUEST_HANDLE field. For example:
struct xen_processor_performance_internal {
uint32_t flags; /* flag for Px sub info type */
uint32_t platform_limit; /* Platform limitation on freq usage */
struct xen_pct_register control_register;
struct xen_pct_register status_register;
uint32_t state_count; /* total available performance states */
struct xen_processor_px states; < this is the interesting change
struct xen_psd_package domain_info;
uint32_t shared_type; /* coordination type of this processor */
};
The caller, in the x86 case is
xen/arch/x86/platform_hypercall.c:do_platform_op, would be resposible
for issuing the copy_from_guest.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH 29/31] xen/arm: Introduce CPUFreq Interface component
On Wed, 6 Dec 2017, Oleksandr Tyshchenko wrote:
> >> +perf->platform_limit = platform_limit;
> >> +perf->shared_type = CPUFREQ_SHARED_TYPE_ANY;
> >> +perf->domain_info.domain = cpumask_first(mask);
> >> +perf->domain_info.num_processors = cpumask_weight(mask);
> >> +
> >> +/* Iterate through all CPUs which are on the same boat */
> >> +for_each_cpu( cpu, mask )
> >> +{
> >> +ret = set_px_pminfo(cpu, perf);
> >> +if ( ret )
> >> +{
> >> +printk("cpu%d: failed to set Px states (%d)\n", cpu, ret);
> >> +break;
> >> +}
> >> +
> >> +printk(XENLOG_DEBUG "cpu%d: set Px states\n", cpu);
> >> +}
> >> +
> >> +xfree(states);
> >> +out:
> >> +xfree(perf);
> >> +
> >> +return ret;
> >> +}
> >> +
> >> +static int __init scpi_cpufreq_postinit(void)
> >> +{
> >> +struct cpufreq_frequency_table *freq_table = NULL;
> >> +cpumask_t processed_cpus, shared_cpus;
> >> +unsigned int cpu;
> >> +int ret = -ENODEV;
> >> +
> >> +cpumask_clear(&processed_cpus);
> >> +
> >> +for_each_online_cpu( cpu )
> >> +{
> >> +if ( cpumask_test_cpu(cpu, &processed_cpus) )
> >> +continue;
> >> +
> >> +if ( !is_dvfs_capable(cpu) )
> >> +continue;
> >> +
> >> +ret = get_sharing_cpus(cpu, &shared_cpus);
> >> +if ( ret )
> >> +{
> >> +printk("cpu%d: failed to get sharing cpumask (%d)\n", cpu,
> >> ret);
> >> +return ret;
> >> +}
> >> +
> >> +BUG_ON(cpumask_empty(&shared_cpus));
> >> +cpumask_or(&processed_cpus, &processed_cpus, &shared_cpus);
> >> +
> >> +/* Create intermediate frequency table */
> >> +ret = init_cpufreq_table(cpu, &freq_table);
> >> +if ( ret )
> >> +{
> >> +printk("cpu%d: failed to initialize frequency table (%d)\n",
> >> + cpu, ret);
> >> +return ret;
> >> +}
> >> +
> >> +ret = upload_cpufreq_data(&shared_cpus, freq_table);
> >> +/* Destroy intermediate frequency table */
> >> +free_cpufreq_table(&freq_table);
> >> +if ( ret )
> >> +{
> >> +printk("cpu%d: failed to upload cpufreq data (%d)\n", cpu,
> >> ret);
> >> +return ret;
> >> +}
> >> +
> >> +printk(XENLOG_DEBUG "cpu%d: uploaded cpufreq data\n", cpu);
> >> +}
> >> +
> >> +return ret;
> >> +}
> >> +
> >> +static int __init scpi_cpufreq_preinit(void)
> >> +{
> >> +struct dt_device_node *scpi, *clk, *dvfs_clk;
> >> +int ret;
> >> +
> >> +/* Initialize SCPI Message protocol */
> >> +ret = scpi_init();
> >> +if ( ret )
> >> +{
> >> +printk("failed to initialize SCPI (%d)\n", ret);
> >> +return ret;
> >> +}
> >> +
> >> +/* Sanity check */
> >> +if ( !get_scpi_ops() || !get_scpi_dev() )
> >> +return -ENXIO;
> >> +
> >> +scpi = get_scpi_dev()->of_node;
> >> +scpi_ops = get_scpi_ops();
> >> +
> >> +ret = -ENODEV;
> >> +
> >> +/*
> >> + * Check for clock related nodes for now. But it might additional
> >> nodes,
> >> + * like thermal sensor, etc.
> >> + */
> >> +dt_for_each_child_node( scpi, clk )
> >
> > Wouldn't it make sense to have a proper:
> >
> > DT_DEVICE_START
> > ...
> > DT_DEVICE_END
> >
> > block and register the driver that way?
>
> I am not sure that I got your question completely.
> Which driver need to be registered in a such way?
> If we had separate dt-related driver to manage clocks we would have to
> register it in a proposed way.
> Here we just iterating through all SCPI child in order to be sure that
> DVFS clock sub-node is present.
> Let say, preliminary check.
>
> BTW, in a proposed way I register ARM SMC triggered mailbox driver:
> https://www.mail-archive.com/xen-devel@lists.xen.org/msg128411.html
> With adding new DEVICE_MAILBOX class:
> https://www.mail-archive.com/xen-devel@lists.xen.org/msg128402.html
Fair enough, and I see that it is not even scanning the whole device
tree but only the scpi node. It's fine then.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-next 11/16] xen/arm: p2m: Rename p2m_flush_tlb and p2m_flush_tlb_sync
On Thu, 23 Nov 2017, Julien Grall wrote:
> Rename p2m_flush_tlb and p2m_flush_tlb_sync to respectively
> p2m_tlb_flush and p2m_force_tlb_flush_sync.
>
> At first glance, inverting 'flush' and 'tlb' might seem pointless but
> would be helpful in the future in order to get more easily some code ported
> from x86 P2M or even to shared with.
>
> For p2m_flush_tlb_sync, the 'force' was added because the TLBs are
> flush unconditionally. A follow-up patch will add an helper to flush
> TLBs only in certain cases.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> xen/arch/arm/p2m.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 417609ede2..d466a5bc43 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -52,7 +52,7 @@ static const paddr_t level_masks[] =
> static const uint8_t level_orders[] =
> { ZEROETH_ORDER, FIRST_ORDER, SECOND_ORDER, THIRD_ORDER };
>
> -static void p2m_flush_tlb(struct p2m_domain *p2m);
> +static void p2m_tlb_flush(struct p2m_domain *p2m);
>
> /* Unlock the flush and do a P2M TLB flush if necessary */
> void p2m_write_unlock(struct p2m_domain *p2m)
> @@ -65,7 +65,7 @@ void p2m_write_unlock(struct p2m_domain *p2m)
> * to avoid someone else modify the P2M before the TLB
> * invalidation has completed.
> */
> -p2m_flush_tlb(p2m);
> +p2m_tlb_flush(p2m);
> }
>
> write_unlock(&p2m->lock);
> @@ -138,7 +138,7 @@ void p2m_restore_state(struct vcpu *n)
> *last_vcpu_ran = n->vcpu_id;
> }
>
> -static void p2m_flush_tlb(struct p2m_domain *p2m)
> +static void p2m_tlb_flush(struct p2m_domain *p2m)
> {
> unsigned long flags = 0;
> uint64_t ovttbr;
> @@ -170,11 +170,11 @@ static void p2m_flush_tlb(struct p2m_domain *p2m)
> *
> * Must be called with the p2m lock held.
> */
> -static void p2m_flush_tlb_sync(struct p2m_domain *p2m)
> +static void p2m_force_tlb_flush_sync(struct p2m_domain *p2m)
> {
> ASSERT(p2m_is_write_locked(p2m));
>
> -p2m_flush_tlb(p2m);
> +p2m_tlb_flush(p2m);
> p2m->need_flush = false;
> }
>
> @@ -675,7 +675,7 @@ static void p2m_free_entry(struct p2m_domain *p2m,
> * flush?
> */
> if ( p2m->need_flush )
> -p2m_flush_tlb_sync(p2m);
> +p2m_force_tlb_flush_sync(p2m);
>
> mfn = _mfn(entry.p2m.base);
> ASSERT(mfn_valid(mfn));
> @@ -864,7 +864,7 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
> * For more details see (D4.7.1 in ARM DDI 0487A.j).
> */
> p2m_remove_pte(entry, p2m->clean_pte);
> -p2m_flush_tlb_sync(p2m);
> +p2m_force_tlb_flush_sync(p2m);
>
> p2m_write_pte(entry, split_pte, p2m->clean_pte);
>
> @@ -940,7 +940,7 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
> {
> if ( likely(!p2m->mem_access_enabled) ||
> P2M_CLEAR_PERM(pte) != P2M_CLEAR_PERM(orig_pte) )
> -p2m_flush_tlb_sync(p2m);
> +p2m_force_tlb_flush_sync(p2m);
> else
> p2m->need_flush = true;
> }
> @@ -1144,7 +1144,7 @@ static int p2m_alloc_table(struct domain *d)
> * Make sure that all TLBs corresponding to the new VMID are flushed
> * before using it
> */
> -p2m_flush_tlb(p2m);
> +p2m_tlb_flush(p2m);
>
> return 0;
> }
> --
> 2.11.0
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-next 12/16] xen/arm: p2m: Introduce p2m_tlb_flush_sync, export it and use it
On Thu, 23 Nov 2017, Julien Grall wrote:
> Multiple places in the code requires to flush the TLBs wonly when
^ only
Aside from this
Reviewed-by: Stefano Stabellini
> p2m->need_flush is set.
>
> Rather than open-coding it, introduce a new helper p2m_tlb_flush_sync to
> do it.
>
> Note that p2m_tlb_flush_sync is exported as it might be used by other
> part of Xen.
>
> Signed-off-by: Julien Grall
> ---
> xen/arch/arm/p2m.c| 27 +--
> xen/include/asm-arm/p2m.h | 2 ++
> 2 files changed, 15 insertions(+), 14 deletions(-)
>
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index d466a5bc43..37498d8ff1 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -52,21 +52,15 @@ static const paddr_t level_masks[] =
> static const uint8_t level_orders[] =
> { ZEROETH_ORDER, FIRST_ORDER, SECOND_ORDER, THIRD_ORDER };
>
> -static void p2m_tlb_flush(struct p2m_domain *p2m);
> -
> /* Unlock the flush and do a P2M TLB flush if necessary */
> void p2m_write_unlock(struct p2m_domain *p2m)
> {
> -if ( p2m->need_flush )
> -{
> -p2m->need_flush = false;
> -/*
> - * The final flush is done with the P2M write lock taken to
> - * to avoid someone else modify the P2M before the TLB
> - * invalidation has completed.
> - */
> -p2m_tlb_flush(p2m);
> -}
> +/*
> + * The final flush is done with the P2M write lock taken to avoid
> + * someone else modifying the P2M wbefore the TLB invalidation has
> + * completed.
> + */
> +p2m_tlb_flush_sync(p2m);
>
> write_unlock(&p2m->lock);
> }
> @@ -178,6 +172,12 @@ static void p2m_force_tlb_flush_sync(struct p2m_domain
> *p2m)
> p2m->need_flush = false;
> }
>
> +void p2m_tlb_flush_sync(struct p2m_domain *p2m)
> +{
> +if ( p2m->need_flush )
> +p2m_force_tlb_flush_sync(p2m);
> +}
> +
> /*
> * Find and map the root page table. The caller is responsible for
> * unmapping the table.
> @@ -674,8 +674,7 @@ static void p2m_free_entry(struct p2m_domain *p2m,
> * XXX: Should we defer the free of the page table to avoid the
> * flush?
> */
> -if ( p2m->need_flush )
> -p2m_force_tlb_flush_sync(p2m);
> +p2m_tlb_flush_sync(p2m);
>
> mfn = _mfn(entry.p2m.base);
> ASSERT(mfn_valid(mfn));
> diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> index faadcfe8fe..a0abc84ed8 100644
> --- a/xen/include/asm-arm/p2m.h
> +++ b/xen/include/asm-arm/p2m.h
> @@ -204,6 +204,8 @@ static inline int p2m_is_write_locked(struct p2m_domain
> *p2m)
> return rw_is_write_locked(&p2m->lock);
> }
>
> +void p2m_tlb_flush_sync(struct p2m_domain *p2m);
> +
> /* Look up the MFN corresponding to a domain's GFN. */
> mfn_t p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t *t);
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-next 13/16] xen/arm: p2m: Fold p2m_tlb_flush into p2m_force_tlb_flush_sync
On Thu, 23 Nov 2017, Julien Grall wrote:
> p2m_tlb_flush is called in 2 places: p2m_alloc_table and
> p2m_force_tlb_flush_sync.
>
> p2m_alloc_table is called when the domain is initialized and could be
> replace by a call to p2m_force_tlb_flush_sync with the P2M write locked.
>
> This seems a bit pointless but would allow to have a single API for
> flushing and avoid misusage in the P2M code.
>
> So update p2m_alloc_table to use p2m_force_tlb_flush_sync and fold
> p2m_tlb_flush in p2m_force_tlb_flush_sync.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> xen/arch/arm/p2m.c | 24 +++-
> 1 file changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 37498d8ff1..5294113afe 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -132,11 +132,18 @@ void p2m_restore_state(struct vcpu *n)
> *last_vcpu_ran = n->vcpu_id;
> }
>
> -static void p2m_tlb_flush(struct p2m_domain *p2m)
> +/*
> + * Force a synchronous P2M TLB flush.
> + *
> + * Must be called with the p2m lock held.
> + */
> +static void p2m_force_tlb_flush_sync(struct p2m_domain *p2m)
> {
> unsigned long flags = 0;
> uint64_t ovttbr;
>
> +ASSERT(p2m_is_write_locked(p2m));
> +
> /*
> * ARM only provides an instruction to flush TLBs for the current
> * VMID. So switch to the VTTBR of a given P2M if different.
> @@ -157,18 +164,7 @@ static void p2m_tlb_flush(struct p2m_domain *p2m)
> isb();
> local_irq_restore(flags);
> }
> -}
> -
> -/*
> - * Force a synchronous P2M TLB flush.
> - *
> - * Must be called with the p2m lock held.
> - */
> -static void p2m_force_tlb_flush_sync(struct p2m_domain *p2m)
> -{
> -ASSERT(p2m_is_write_locked(p2m));
>
> -p2m_tlb_flush(p2m);
> p2m->need_flush = false;
> }
>
> @@ -1143,7 +1139,9 @@ static int p2m_alloc_table(struct domain *d)
> * Make sure that all TLBs corresponding to the new VMID are flushed
> * before using it
> */
> -p2m_tlb_flush(p2m);
> +p2m_write_lock(p2m);
> +p2m_force_tlb_flush_sync(p2m);
> +p2m_write_unlock(p2m);
>
> return 0;
> }
> --
> 2.11.0
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-next 14/16] xen/arm: traps: Remove the field gva from mmio_info_t
On Thu, 23 Nov 2017, Julien Grall wrote:
> mmio_info_t is used to gather information in order do emulation a
^ of a
Aside from this
Reviewed-by: Stefano Stabellini
> region. Guest virtual address is unlikely to be a useful information and
> not currently used. So remove the field gva from mmio_info_t and replace
> by a local variable.
>
> Signed-off-by: Julien Grall
> ---
> xen/arch/arm/traps.c | 13 +++--
> xen/include/asm-arm/mmio.h | 1 -
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index f6f6de3691..e30dd9b7e2 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2001,6 +2001,7 @@ static void do_trap_data_abort_guest(struct
> cpu_user_regs *regs,
> {
> const struct hsr_dabt dabt = hsr.dabt;
> int rc;
> +vaddr_t gva;
> mmio_info_t info;
> uint8_t fsc = hsr.dabt.dfsc & ~FSC_LL_MASK;
> mfn_t mfn;
> @@ -2014,13 +2015,13 @@ static void do_trap_data_abort_guest(struct
> cpu_user_regs *regs,
>
> info.dabt = dabt;
>
> -info.gva = get_hfar(true /* is_data */);
> +gva = get_hfar(true /* is_data */);
>
> if ( hpfar_is_valid(dabt.s1ptw, fsc) )
> -info.gpa = get_faulting_ipa(info.gva);
> +info.gpa = get_faulting_ipa(gva);
> else
> {
> -rc = gva_to_ipa(info.gva, &info.gpa, GV2M_READ);
> +rc = gva_to_ipa(gva, &info.gpa, GV2M_READ);
> /*
> * We may not be able to translate because someone is
> * playing with the Stage-2 page table of the domain.
> @@ -2041,7 +2042,7 @@ static void do_trap_data_abort_guest(struct
> cpu_user_regs *regs,
> .kind = dabt.s1ptw ? npfec_kind_in_gpt : npfec_kind_with_gla
> };
>
> -p2m_mem_access_check(info.gpa, info.gva, npfec);
> +p2m_mem_access_check(info.gpa, gva, npfec);
> /*
> * The only way to get here right now is because of mem_access,
> * thus reinjecting the exception to the guest is never required.
> @@ -2078,8 +2079,8 @@ static void do_trap_data_abort_guest(struct
> cpu_user_regs *regs,
> }
>
> gdprintk(XENLOG_DEBUG, "HSR=0x%x pc=%#"PRIregister" gva=%#"PRIvaddr
> - " gpa=%#"PRIpaddr"\n", hsr.bits, regs->pc, info.gva, info.gpa);
> -inject_dabt_exception(regs, info.gva, hsr.len);
> + " gpa=%#"PRIpaddr"\n", hsr.bits, regs->pc, gva, info.gpa);
> +inject_dabt_exception(regs, gva, hsr.len);
> }
>
> static void enter_hypervisor_head(struct cpu_user_regs *regs)
> diff --git a/xen/include/asm-arm/mmio.h b/xen/include/asm-arm/mmio.h
> index c620eed4cd..37e2b7a707 100644
> --- a/xen/include/asm-arm/mmio.h
> +++ b/xen/include/asm-arm/mmio.h
> @@ -29,7 +29,6 @@
> typedef struct
> {
> struct hsr_dabt dabt;
> -vaddr_t gva;
> paddr_t gpa;
> } mmio_info_t;
>
> --
> 2.11.0
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-next 15/16] xen/arm: traps: Move the definition of mmio_info_t in try_handle_mmio
On Thu, 23 Nov 2017, Julien Grall wrote:
> mmio_info_t is currently filled by do_trap_data_guest_abort but only
> important when emulation an MMIO region.
>
> A follow-up patch will merge stage-2 prefetch abort and stage-2 data abort
> in a single helper. To prepare that, mmio_info_t is now filled by
> try_handle_mmio.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> xen/arch/arm/traps.c | 31 +--
> 1 file changed, 17 insertions(+), 14 deletions(-)
>
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index e30dd9b7e2..a68e01b457 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -1936,9 +1936,14 @@ static void do_trap_instr_abort_guest(struct
> cpu_user_regs *regs,
> }
>
> static bool try_handle_mmio(struct cpu_user_regs *regs,
> -mmio_info_t *info)
> +const union hsr hsr,
> +paddr_t gpa)
> {
> -const struct hsr_dabt dabt = info->dabt;
> +const struct hsr_dabt dabt = hsr.dabt;
> +mmio_info_t info = {
> +.gpa = gpa,
> +.dabt = dabt
> +};
> int rc;
>
> /* stage-1 page table should never live in an emulated MMIO region */
> @@ -1956,7 +1961,7 @@ static bool try_handle_mmio(struct cpu_user_regs *regs,
> if ( check_workaround_766422() && (regs->cpsr & PSR_THUMB) &&
> dabt.write )
> {
> -rc = decode_instruction(regs, &info->dabt);
> +rc = decode_instruction(regs, &info.dabt);
> if ( rc )
> {
> gprintk(XENLOG_DEBUG, "Unable to decode instruction\n");
> @@ -1964,7 +1969,7 @@ static bool try_handle_mmio(struct cpu_user_regs *regs,
> }
> }
>
> -return !!handle_mmio(info);
> +return !!handle_mmio(&info);
> }
>
> /*
> @@ -2002,7 +2007,7 @@ static void do_trap_data_abort_guest(struct
> cpu_user_regs *regs,
> const struct hsr_dabt dabt = hsr.dabt;
> int rc;
> vaddr_t gva;
> -mmio_info_t info;
> +paddr_t gpa;
> uint8_t fsc = hsr.dabt.dfsc & ~FSC_LL_MASK;
> mfn_t mfn;
>
> @@ -2013,15 +2018,13 @@ static void do_trap_data_abort_guest(struct
> cpu_user_regs *regs,
> if ( dabt.eat )
> return __do_trap_serror(regs, true);
>
> -info.dabt = dabt;
> -
> gva = get_hfar(true /* is_data */);
>
> if ( hpfar_is_valid(dabt.s1ptw, fsc) )
> -info.gpa = get_faulting_ipa(gva);
> +gpa = get_faulting_ipa(gva);
> else
> {
> -rc = gva_to_ipa(gva, &info.gpa, GV2M_READ);
> +rc = gva_to_ipa(gva, &gpa, GV2M_READ);
> /*
> * We may not be able to translate because someone is
> * playing with the Stage-2 page table of the domain.
> @@ -2042,7 +2045,7 @@ static void do_trap_data_abort_guest(struct
> cpu_user_regs *regs,
> .kind = dabt.s1ptw ? npfec_kind_in_gpt : npfec_kind_with_gla
> };
>
> -p2m_mem_access_check(info.gpa, gva, npfec);
> +p2m_mem_access_check(gpa, gva, npfec);
> /*
> * The only way to get here right now is because of mem_access,
> * thus reinjecting the exception to the guest is never required.
> @@ -2054,7 +2057,7 @@ static void do_trap_data_abort_guest(struct
> cpu_user_regs *regs,
> * Attempt first to emulate the MMIO as the data abort will
> * likely happen in an emulated region.
> */
> -if ( try_handle_mmio(regs, &info) )
> +if ( try_handle_mmio(regs, hsr, gpa) )
> {
> advance_pc(regs, hsr);
> return;
> @@ -2065,11 +2068,11 @@ static void do_trap_data_abort_guest(struct
> cpu_user_regs *regs,
> * with the Stage-2 page table. Walk the Stage-2 PT to check
> * if the entry exists. If it's the case, return to the guest
> */
> -mfn = gfn_to_mfn(current->domain, gaddr_to_gfn(info.gpa));
> +mfn = gfn_to_mfn(current->domain, gaddr_to_gfn(gpa));
> if ( !mfn_eq(mfn, INVALID_MFN) )
> return;
>
> -if ( try_map_mmio(gaddr_to_gfn(info.gpa)) )
> +if ( try_map_mmio(gaddr_to_gfn(gpa)) )
> return;
>
> break;
> @@ -2079,7 +2082,7 @@ static void do_trap_data_abort_guest(struct
> cpu_user_regs *regs,
> }
>
> gdprintk(XENLOG_DEBUG, "HSR=0x%x pc=%#"PRIregister" gva=%#"PRIvaddr
> - " gpa=%#"PRIpaddr"\n", hsr.bits, regs->pc, gva, info.gpa);
> + " gpa=%#"PRIpaddr"\n", hsr.bits, regs->pc, gva, gpa);
> inject_dabt_exception(regs, gva, hsr.len);
> }
>
> --
> 2.11.0
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-next 16/16] xen/arm: traps: Merge do_trap_instr_abort_guest and do_trap_data_abort_guest
On Thu, 23 Nov 2017, Julien Grall wrote:
> The two helpers do_trap_instr_abort_guest and do_trap_data_abort_guest
> are used trap stage-2 abort. While the former is only handling prefetch
> abort and the latter data abort, they are very similarly and does not
> warrant to have separate helpers.
>
> For instance, merging the both will make easier to maintain stage-2 abort
> handling. So consolidate the two helpers in a new helper
> do_trap_stage2_abort.
>
> Signed-off-by: Julien Grall
> ---
> xen/arch/arm/traps.c | 133
> ---
> 1 file changed, 41 insertions(+), 92 deletions(-)
>
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index a68e01b457..b83a2d9244 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -1862,79 +1862,6 @@ static inline bool hpfar_is_valid(bool s1ptw, uint8_t
> fsc)
> return s1ptw || (fsc == FSC_FLT_TRANS && !check_workaround_834220());
> }
>
> -static void do_trap_instr_abort_guest(struct cpu_user_regs *regs,
> - const union hsr hsr)
> -{
> -int rc;
> -register_t gva;
> -uint8_t fsc = hsr.iabt.ifsc & ~FSC_LL_MASK;
> -paddr_t gpa;
> -mfn_t mfn;
> -
> -gva = get_hfar(false /* is_data */);
> -
> -/*
> - * If this bit has been set, it means that this instruction abort is
> caused
> - * by a guest external abort. We can handle this instruction abort as
> guest
> - * SError.
> - */
> -if ( hsr.iabt.eat )
> -return __do_trap_serror(regs, true);
> -
> -
> -if ( hpfar_is_valid(hsr.iabt.s1ptw, fsc) )
> -gpa = get_faulting_ipa(gva);
> -else
> -{
> -/*
> - * Flush the TLB to make sure the DTLB is clear before
> - * doing GVA->IPA translation. If we got here because of
> - * an entry only present in the ITLB, this translation may
> - * still be inaccurate.
> - */
> -flush_tlb_local();
> -
> -/*
> - * We may not be able to translate because someone is
> - * playing with the Stage-2 page table of the domain.
> - * Return to the guest.
> - */
> -rc = gva_to_ipa(gva, &gpa, GV2M_READ);
> -if ( rc == -EFAULT )
> -return; /* Try again */
> -}
> -
> -switch ( fsc )
> -{
> -case FSC_FLT_PERM:
> -{
> -const struct npfec npfec = {
> -.insn_fetch = 1,
> -.gla_valid = 1,
> -.kind = hsr.iabt.s1ptw ? npfec_kind_in_gpt : npfec_kind_with_gla
> -};
> -
> -p2m_mem_access_check(gpa, gva, npfec);
> -/*
> - * The only way to get here right now is because of mem_access,
> - * thus reinjecting the exception to the guest is never required.
> - */
> -return;
> -}
> -case FSC_FLT_TRANS:
> -/*
> - * The PT walk may have failed because someone was playing
> - * with the Stage-2 page table. Walk the Stage-2 PT to check
> - * if the entry exists. If it's the case, return to the guest
> - */
> -mfn = gfn_to_mfn(current->domain, _gfn(paddr_to_pfn(gpa)));
> -if ( !mfn_eq(mfn, INVALID_MFN) )
> -return;
> -}
> -
> -inject_iabt_exception(regs, gva, hsr.len);
> -}
> -
> static bool try_handle_mmio(struct cpu_user_regs *regs,
> const union hsr hsr,
> paddr_t gpa)
> @@ -1946,6 +1873,8 @@ static bool try_handle_mmio(struct cpu_user_regs *regs,
> };
> int rc;
>
> +ASSERT(hsr.ec == HSR_EC_DATA_ABORT_LOWER_EL);
> +
> /* stage-1 page table should never live in an emulated MMIO region */
> if ( dabt.s1ptw )
> return false;
> @@ -2001,29 +1930,43 @@ static bool try_map_mmio(gfn_t gfn)
> return !map_regions_p2mt(d, gfn, 1, mfn, p2m_mmio_direct_c);
> }
>
> -static void do_trap_data_abort_guest(struct cpu_user_regs *regs,
> - const union hsr hsr)
> +static void do_trap_stage2_abort_guest(struct cpu_user_regs *regs,
> + const union hsr hsr)
> {
> -const struct hsr_dabt dabt = hsr.dabt;
> +/*
> + * The encoding of hsr_iabt is a subset of hsr_dabt. So use
> + * hsr_dabt to represent an abort fault.
> + */
> +const struct hsr_xabt xabt = hsr.xabt;
> int rc;
> vaddr_t gva;
> paddr_t gpa;
> -uint8_t fsc = hsr.dabt.dfsc & ~FSC_LL_MASK;
> +uint8_t fsc = xabt.fsc & ~FSC_LL_MASK;
> mfn_t mfn;
> +bool is_data = (hsr.ec == HSR_EC_DATA_ABORT_LOWER_EL);
>
> /*
> - * If this bit has been set, it means that this data abort is caused
> - * by a guest external abort. We treat this data abort as guest SError.
> + * If this bit has been set, it means that this stage-2 abort is caused
> + * by a guest external abort. We treat this stage-2 abort as guest
> SError.
> */
> -if ( dabt.
Re: [Xen-devel] [PATCH] xen/arm64: head.S: Introduce macro to load the physical address of a symbol
On Thu, 7 Dec 2017, Julien Grall wrote:
> A lot of places in the ARM64 assembly code requiring to load the
> physical address of a symbol. Rather than open-coding the translation,
> introduce a new macro that will load the physical address of a symbol.
>
> Lastly, use this new macro to replace all the current opencoded version.
>
> Note that most of comments associated to the code changed have been
> removed because the code is now self-explanatory.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> xen/arch/arm/arm64/head.S | 48
> ---
> 1 file changed, 20 insertions(+), 28 deletions(-)
>
> diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> index 78292f4396..fa0ef7034c 100644
> --- a/xen/arch/arm/arm64/head.S
> +++ b/xen/arch/arm/arm64/head.S
> @@ -85,6 +85,12 @@
> #define PRINT(s)
> #endif /* !CONFIG_EARLY_PRINTK */
>
> +/* Load the physical address of a symbol into xb */
> +.macro load_paddr xb, sym
> +ldr \xb, =\sym
> +add \xb, \xb, x20
> +.endm
> +
> /*.aarch64*/
>
> /*
> @@ -247,8 +253,7 @@ real_start_efi:
>
> /* Using the DTB in the .dtb section? */
> #ifdef CONFIG_DTB_FILE
> -ldr x21, =_sdtb
> -add x21, x21, x20 /* x21 := paddr(DTB) */
> +load_paddr x21, _sdtb
> #endif
>
> mov x22, #0/* x22 := is_secondary_cpu */
> @@ -281,8 +286,7 @@ common_start:
> /* Non-boot CPUs wait here until __cpu_up is ready for them */
> cbz x22, 1f
>
> -ldr x0, =smp_up_cpu
> -add x0, x0, x20/* Apply physical offset */
> +load_paddr x0, smp_up_cpu
> dsb sy
> 2: ldr x1, [x0]
> cmp x1, x24
> @@ -323,10 +327,8 @@ el2:PRINT("- Xen starting at EL2 -\r\n")
> cbnz x26, skip_bss
>
> PRINT("- Zero BSS -\r\n")
> -ldr x0, =__bss_start /* Load start & end of bss */
> -ldr x1, =__bss_end
> -add x0, x0, x20/* Apply physical offset */
> -add x1, x1, x20
> +load_paddr x0, __bss_start/* Load paddr of start & end of bss */
> +load_paddr x1, __bss_end
>
> 1: str xzr, [x0], #8
> cmp x0, x1
> @@ -386,13 +388,11 @@ skip_bss:
> cset x25, eq/* x25 := identity map in place, or not
> */
>
> /* Write Xen's PT's paddr into TTBR0_EL2 */
> -ldr x4, =boot_pgtable
> -add x4, x4, x20/* x4 := paddr (boot_pagetable) */
> +load_paddr x4, boot_pgtable
> msr TTBR0_EL2, x4
>
> /* Setup boot_pgtable: */
> -ldr x1, =boot_first
> -add x1, x1, x20/* x1 := paddr (boot_first) */
> +load_paddr x1, boot_first
>
> /* ... map boot_first in boot_pgtable[0] */
> mov x3, #PT_PT /* x2 := table map of boot_first */
> @@ -407,16 +407,14 @@ skip_bss:
> /* Level zero does not support superpage mappings, so we have
> * to use an extra first level page in which we create a 1GB mapping.
> */
> -ldr x2, =boot_first_id
> -add x2, x2, x20/* x2 := paddr (boot_first_id) */
> +load_paddr x2, boot_first_id
>
> mov x3, #PT_PT /* x2 := table map of boot_first_id */
> orr x2, x2, x3 /* + rights for linear PT */
> lsl x1, x1, #3 /* x1 := Slot offset */
> str x2, [x4, x1]
>
> -ldr x4, =boot_first_id /* Next level into boot_first_id */
> -add x4, x4, x20/* x4 := paddr(boot_first_id) */
> +load_paddr x4, boot_first_id
>
> lsr x1, x19, #FIRST_SHIFT /* x1 := Offset of base paddr in
> boot_first_id */
> lsl x2, x1, #FIRST_SHIFT /* x2 := Base address for 1GB mapping */
> @@ -428,12 +426,10 @@ skip_bss:
> mov x25, #1/* x25 := identity map now in place */
>
> 1: /* Setup boot_first: */
> -ldr x4, =boot_first/* Next level into boot_first */
> -add x4, x4, x20/* x4 := paddr(boot_first) */
> +load_paddr x4, boot_first /* Next level into boot_first */
>
> /* ... map boot_second in boot_first[0] */
> -ldr x1, =boot_second
> -add x1, x1, x20/* x1 := paddr(boot_second) */
> +load_paddr x1, boot_second
> mov x3, #PT_PT /* x2 := table map of boot_second */
&
Re: [Xen-devel] [PATCH] xen/arm: Remove unused fixmap slots
On Thu, 7 Dec 2017, Julien Grall wrote: > There are quite a few fixmap slots that have not been used for a while. > Remove them. > > Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini > --- > xen/include/asm-arm/config.h | 9 ++--- > 1 file changed, 2 insertions(+), 7 deletions(-) > > diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h > index 45f472f2fd..cdae8f64ff 100644 > --- a/xen/include/asm-arm/config.h > +++ b/xen/include/asm-arm/config.h > @@ -172,13 +172,8 @@ > > /* Fixmap slots */ > #define FIXMAP_CONSOLE 0 /* The primary UART */ > -#define FIXMAP_PT 1 /* Temporary mappings of pagetable pages */ > -#define FIXMAP_MISC 2 /* Ephemeral mappings of hardware */ > -#define FIXMAP_GICD 3 /* Interrupt controller: distributor registers */ > -#define FIXMAP_GICC14 /* Interrupt controller: CPU registers (first > page) */ > -#define FIXMAP_GICC25 /* Interrupt controller: CPU registers (second > page) */ > -#define FIXMAP_GICH 6 /* Interrupt controller: virtual interface > control registers */ > -#define FIXMAP_ACPI_BEGIN 7 /* Start mappings of ACPI tables */ > +#define FIXMAP_MISC 1 /* Ephemeral mappings of hardware */ > +#define FIXMAP_ACPI_BEGIN 2 /* Start mappings of ACPI tables */ > #define FIXMAP_ACPI_END(FIXMAP_ACPI_BEGIN + NUM_FIXMAP_ACPI_PAGES - 1) > /* End mappings of ACPI tables */ > > #define PAGE_SHIFT 12 > -- > 2.11.0 > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-next 06/16] xen/arm: Extend copy_to_guest to support copying from/to guest physical address
On Wed, 6 Dec 2017, Julien Grall wrote:
> Hi Stefano,
>
> On 12/06/2017 01:22 AM, Stefano Stabellini wrote:
> > On Thu, 23 Nov 2017, Julien Grall wrote:
> > > The only differences between copy_to_guest and access_guest_memory_by_ipa
> > > are:
> > > - The latter does not support copying data crossing page boundary
> > > - The former is copying from/to guest VA whilst the latter from
> > > guest PA
> > >
> > > copy_to_guest can easily be extended to support copying from/to guest
> > > physical address. For that a new bit is used to tell whether linear
> > > address or ipa is been used.
> > >
> > > Lastly access_guest_memory_by_ipa is reimplemented using copy_to_guest.
> > > This also has the benefits to extend the use of it, it is now possible
> > > to copy data crossing page boundary.
> > >
> > > Signed-off-by: Julien Grall
> >
> > Ah! This is the reason why previous patches were not using vaddr_t. It
> > makes sense now. May I suggest we use something different from paddr_t
> > in copy_guest for addr type? I don't think is correct to specify addr as
> > paddr_t when it could be vaddr_t; in the future we could have type
> > checks on them.
> >
> > I suggest we specify it as u64, but if you have a better idea go for it.
>
> We should not use more u64 in the code. uint64_t could be a solution but even
> that, I don't see the reason. How are you sure the physical address will
> always fit in 64-bit?
>
> On the other side, very likely vaddr_t will fit in paddr_t. So paddr_t is the
> right way to go for me.
What about introducing xaddr_t?
Or at least:
static struct page_info *translate_get_page(struct vcpu *v, paddr_t /*or
vaddr_t */ addr
> >
> > > ---
> > > xen/arch/arm/guestcopy.c | 86
> > > ++--
> > > 1 file changed, 39 insertions(+), 47 deletions(-)
> > >
> > > diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
> > > index 487f5ab82d..be53bee559 100644
> > > --- a/xen/arch/arm/guestcopy.c
> > > +++ b/xen/arch/arm/guestcopy.c
> > > @@ -8,6 +8,31 @@
> > > #define COPY_flush_dcache (1U << 0)
> > > #define COPY_from_guest (0U << 1)
> > > #define COPY_to_guest (1U << 1)
> > > +#define COPY_ipa(0U << 2)
> > > +#define COPY_linear (1U << 2)
> > > +
> > > +static struct page_info *translate_get_page(struct vcpu *v, paddr_t addr,
> > > +bool linear, bool write)
> > > +{
> > > +p2m_type_t p2mt;
> > > +struct page_info *page;
> > > +
> > > +if ( linear )
> > > +return get_page_from_gva(v, addr, write ? GV2M_WRITE :
> > > GV2M_READ);
> > > +
> > > +page = get_page_from_gfn(v->domain, paddr_to_pfn(addr), &p2mt,
> > > P2M_ALLOC);
> > > +
> > > +if ( !page )
> > > +return NULL;
> > > +
> > > +if ( !p2m_is_ram(p2mt) )
> > > +{
> > > +put_page(page);
> > > +return NULL;
> > > +}
> > > +
> > > +return page;
> > > +}
> > > static unsigned long copy_guest(void *buf, paddr_t addr, unsigned int
> > > len,
> > > struct vcpu *v, unsigned int flags)
> > > @@ -21,8 +46,8 @@ static unsigned long copy_guest(void *buf, paddr_t addr,
> > > unsigned int len,
> > > unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
> > > struct page_info *page;
> > > -page = get_page_from_gva(v, addr,
> > > - (flags & COPY_to_guest) ? GV2M_WRITE :
> > > GV2M_READ);
> > > +page = translate_get_page(v, addr, flags & COPY_linear,
> > > + flags & COPY_to_guest);
> > > if ( page == NULL )
> > > return len;
> > > @@ -63,73 +88,40 @@ static unsigned long copy_guest(void *buf, paddr_t
> > > addr, unsigned int len,
> > > unsigned long raw_copy_to_guest(void *to, const void *from, unsigned
> > > len)
> > > {
> > > return copy_guest((void *)from, (unsigned long)to, len,
> > > - current, COPY_to_guest);
> > > + current, COPY_to_guest | COPY_linear);
> > > }
&g
Re: [Xen-devel] [PATCH] xen/arm: gic-v3: Bail out if gicv3_cpu_init fail
On Wed, 6 Dec 2017, Julien Grall wrote:
> From: Julien Grall
>
> When system registers are not enabled, all the access to them will trap
^ accesses
> in EL2. In Xen, system registers will be enabled by gicv3_cpu_init only
> on success. As the rest of the code (e.g gicv3_hyp_init) relies on
> system register, it is better to bail out directly.
>
> This will save time on debugging early boot issue on GICv3 platform.
>
> Signed-off-by: Julien Grall
This is good:
Reviewed-by: Stefano Stabellini
Do we also want to print a warning or an error message?
> ---
>
> This makes easier to debug early boot issue on GICv3 platform. It would
> be worth considering to backport it.
> ---
> xen/arch/arm/gic-v3.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index 473e26111f..a0d290b55c 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -847,8 +847,12 @@ static int gicv3_secondary_cpu_init(void)
> spin_lock(&gicv3.lock);
>
> res = gicv3_cpu_init();
> +if ( res )
> +goto out;
> +
> gicv3_hyp_init();
>
> +out:
> spin_unlock(&gicv3.lock);
>
> return res;
> @@ -1705,8 +1709,12 @@ static int __init gicv3_init(void)
> panic("GICv3: ITS: initialization failed: %d\n", res);
>
> res = gicv3_cpu_init();
> +if ( res )
> +goto out;
> +
> gicv3_hyp_init();
>
> +out:
> spin_unlock(&gicv3.lock);
>
> return res;
> --
> 2.11.0
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-next 06/16] xen/arm: Extend copy_to_guest to support copying from/to guest physical address
On Fri, 8 Dec 2017, Julien Grall wrote: > Hi Stefano, > > On 07/12/17 23:01, Stefano Stabellini wrote: > > On Wed, 6 Dec 2017, Julien Grall wrote: > > > Hi Stefano, > > > > > > On 12/06/2017 01:22 AM, Stefano Stabellini wrote: > > > > On Thu, 23 Nov 2017, Julien Grall wrote: > > > > > The only differences between copy_to_guest and > > > > > access_guest_memory_by_ipa > > > > > are: > > > > > - The latter does not support copying data crossing page > > > > > boundary > > > > > - The former is copying from/to guest VA whilst the latter from > > > > > guest PA > > > > > > > > > > copy_to_guest can easily be extended to support copying from/to guest > > > > > physical address. For that a new bit is used to tell whether linear > > > > > address or ipa is been used. > > > > > > > > > > Lastly access_guest_memory_by_ipa is reimplemented using > > > > > copy_to_guest. > > > > > This also has the benefits to extend the use of it, it is now possible > > > > > to copy data crossing page boundary. > > > > > > > > > > Signed-off-by: Julien Grall > > > > > > > > Ah! This is the reason why previous patches were not using vaddr_t. It > > > > makes sense now. May I suggest we use something different from paddr_t > > > > in copy_guest for addr type? I don't think is correct to specify addr as > > > > paddr_t when it could be vaddr_t; in the future we could have type > > > > checks on them. > > > > > > > > I suggest we specify it as u64, but if you have a better idea go for it. > > > > > > We should not use more u64 in the code. uint64_t could be a solution but > > > even > > > that, I don't see the reason. How are you sure the physical address will > > > always fit in 64-bit? > > > > > > On the other side, very likely vaddr_t will fit in paddr_t. So paddr_t is > > > the > > > right way to go for me. > > > > What about introducing xaddr_t? > > I would prefer uint64_t in that case. xaddr_t is quite confusing to read and > could be misused. > > > Or at least: > > > >static struct page_info *translate_get_page(struct vcpu *v, paddr_t /*or > > vaddr_t */ addr > > I can do that as well. What's your preference? I prefer uint64_t ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: gic-v3: Bail out if gicv3_cpu_init fail
On Fri, 8 Dec 2017, Julien Grall wrote: > Hi Stefano, > > On 07/12/17 23:05, Stefano Stabellini wrote: > > On Wed, 6 Dec 2017, Julien Grall wrote: > > > From: Julien Grall > > > > > > When system registers are not enabled, all the access to them will trap > > ^ accesses > > > > > > > in EL2. In Xen, system registers will be enabled by gicv3_cpu_init only > > > on success. As the rest of the code (e.g gicv3_hyp_init) relies on > > > system register, it is better to bail out directly. > > > > > > This will save time on debugging early boot issue on GICv3 platform. > > > > > > Signed-off-by: Julien Grall > > > > This is good: > > > > Reviewed-by: Stefano Stabellini > > > > > > Do we also want to print a warning or an error message? > > AFAICT, all the path that return an error in gicv3_cpu_init (and the callers) > have already a warning/error message. So no need to add an extra one here. committed ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: Surround HSR_SYSREG macro value with ()
On Fri, 8 Dec 2017, Julien Grall wrote: > Hi, > > Ping? > > Cheers, > > On 29/11/17 17:46, Julien Grall wrote: > > The value of the macro HCR_SYSREG is not surrounded by (). This means > > the behavior may change depend on how it is used. > > > > Thanksfully recent GCC will issue a warning for that. > > > > Signed-off-by: Julien Grall reviewed and committed > > --- > > > > I am not aware of any "bad" usage today in Xen. This was found whilst > > playing with sysreg emulation and GCC complaining about the missing (). > > --- > > xen/include/asm-arm/arm64/sysregs.h | 10 +- > > 1 file changed, 5 insertions(+), 5 deletions(-) > > > > diff --git a/xen/include/asm-arm/arm64/sysregs.h > > b/xen/include/asm-arm/arm64/sysregs.h > > index 084d2a1e5d..1811234249 100644 > > --- a/xen/include/asm-arm/arm64/sysregs.h > > +++ b/xen/include/asm-arm/arm64/sysregs.h > > @@ -32,11 +32,11 @@ > > /* These are used to decode traps with HSR.EC==HSR_EC_SYSREG */ > > #define HSR_SYSREG(op0,op1,crn,crm,op2) \ > > -((__HSR_SYSREG_##op0) << HSR_SYSREG_OP0_SHIFT) | \ > > -((__HSR_SYSREG_##op1) << HSR_SYSREG_OP1_SHIFT) | \ > > -((__HSR_SYSREG_##crn) << HSR_SYSREG_CRN_SHIFT) | \ > > -((__HSR_SYSREG_##crm) << HSR_SYSREG_CRM_SHIFT) | \ > > -((__HSR_SYSREG_##op2) << HSR_SYSREG_OP2_SHIFT) > > +(((__HSR_SYSREG_##op0) << HSR_SYSREG_OP0_SHIFT) | \ > > + ((__HSR_SYSREG_##op1) << HSR_SYSREG_OP1_SHIFT) | \ > > + ((__HSR_SYSREG_##crn) << HSR_SYSREG_CRN_SHIFT) | \ > > + ((__HSR_SYSREG_##crm) << HSR_SYSREG_CRM_SHIFT) | \ > > + ((__HSR_SYSREG_##op2) << HSR_SYSREG_OP2_SHIFT)) > > #define HSR_SYSREG_DCISW HSR_SYSREG(1,0,c7,c6,2) > > #define HSR_SYSREG_DCCSW HSR_SYSREG(1,0,c7,c10,2) > > > > -- > Julien Grall > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: bootfdt: Use proper default for #address-cells and #size-cells
On Fri, 8 Dec 2017, Julien Grall wrote: > Hi, > > On 29/11/17 18:12, Stefano Stabellini wrote: > > On Wed, 29 Nov 2017, Julien Grall wrote: > > > Per the device-tree specific [1], when the property #address-cells > > > and #size-cells are not present, the default value should be resp. 1 > > > and 2. > > > > > > [1] > > > https://www.devicetree.org/downloads/devicetree-specification-v0.1-20160524.pdf > > > > > > Signed-off-by: Julien Grall > > > > Acked-by: Stefano Stabellini > > This was acked but not applied to staging. Can you do it please? It was in my arm-next branch together with a couple of patches from Andre. I committed all three to staging. > > > > > > > > --- > > > > > > This was discovered debugging DT generated by GRUB on ACPI-only > > > platform. I am not aware of any DT relying on that for now, but it > > > would still be nice to be compliant with the spec and avoid > > > surprise. > > > --- > > > xen/arch/arm/bootfdt.c | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c > > > index 4a687e725d..8eba42c7b9 100644 > > > --- a/xen/arch/arm/bootfdt.c > > > +++ b/xen/arch/arm/bootfdt.c > > > @@ -109,8 +109,8 @@ int __init device_tree_for_each_node(const void *fdt, > > > continue; > > > } > > > -as = depth > 0 ? address_cells[depth-1] : 0; > > > -ss = depth > 0 ? size_cells[depth-1] : 0; > > > +as = depth > 0 ? address_cells[depth-1] : > > > DT_ROOT_NODE_ADDR_CELLS_DEFAULT; > > > +ss = depth > 0 ? size_cells[depth-1] : > > > DT_ROOT_NODE_SIZE_CELLS_DEFAULT; > > > address_cells[depth] = device_tree_get_u32(fdt, node, > > > "#address-cells", > > > as); > > > -- > > > 2.11.0 > > > > > -- > Julien Grall > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 03/10] ARM: VGIC: move gic_remove_irq_from_queues()
On Thu, 7 Dec 2017, Andre Przywara wrote:
> gic_remove_irq_from_queues() was not only misnamed, it also has the wrong
> abstraction, as it should not live in gic.c.
> Move it into vgic.c and vgic.h, where it belongs to, and rename it on
> the way.
>
> Signed-off-by: Andre Przywara
> Reviewed-by: Stefano Stabellini
I committed the first three patches
> ---
> xen/arch/arm/gic.c | 9 -
> xen/arch/arm/vgic-v3-its.c | 4 ++--
> xen/arch/arm/vgic.c| 11 ++-
> xen/include/asm-arm/gic.h | 1 -
> xen/include/asm-arm/vgic.h | 1 +
> 5 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index ed363f6c37..bac8ada2bb 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -411,15 +411,6 @@ void gic_remove_from_lr_pending(struct vcpu *v, struct
> pending_irq *p)
> list_del_init(&p->lr_queue);
> }
>
> -void gic_remove_irq_from_queues(struct vcpu *v, struct pending_irq *p)
> -{
> -ASSERT(spin_is_locked(&v->arch.vgic.lock));
> -
> -clear_bit(GIC_IRQ_GUEST_QUEUED, &p->status);
> -list_del_init(&p->inflight);
> -gic_remove_from_lr_pending(v, p);
> -}
> -
> void gic_raise_inflight_irq(struct vcpu *v, unsigned int virtual_irq)
> {
> struct pending_irq *n = irq_to_pending(v, virtual_irq);
> diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
> index 72a5c70656..d8fa44258d 100644
> --- a/xen/arch/arm/vgic-v3-its.c
> +++ b/xen/arch/arm/vgic-v3-its.c
> @@ -381,7 +381,7 @@ static int its_handle_clear(struct virt_its *its,
> uint64_t *cmdptr)
> * have no active state, we don't need to care about this here.
> */
> if ( !test_bit(GIC_IRQ_GUEST_VISIBLE, &p->status) )
> -gic_remove_irq_from_queues(vcpu, p);
> +vgic_remove_irq_from_queues(vcpu, p);
>
> spin_unlock_irqrestore(&vcpu->arch.vgic.lock, flags);
> ret = 0;
> @@ -619,7 +619,7 @@ static int its_discard_event(struct virt_its *its,
> }
>
> /* Cleanup the pending_irq and disconnect it from the LPI. */
> -gic_remove_irq_from_queues(vcpu, p);
> +vgic_remove_irq_from_queues(vcpu, p);
> vgic_init_pending_irq(p, INVALID_LPI);
>
> spin_unlock_irqrestore(&vcpu->arch.vgic.lock, flags);
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index d8acbbeaaa..6e933a86d3 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -281,7 +281,7 @@ bool vgic_migrate_irq(struct vcpu *old, struct vcpu *new,
> unsigned int irq)
> /* If the IRQ is still lr_pending, re-inject it to the new vcpu */
> if ( !list_empty(&p->lr_queue) )
> {
> -gic_remove_irq_from_queues(old, p);
> +vgic_remove_irq_from_queues(old, p);
> irq_set_affinity(p->desc, cpumask_of(new->processor));
> spin_unlock_irqrestore(&old->arch.vgic.lock, flags);
> vgic_vcpu_inject_irq(new, irq);
> @@ -508,6 +508,15 @@ void vgic_clear_pending_irqs(struct vcpu *v)
> spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
> }
>
> +void vgic_remove_irq_from_queues(struct vcpu *v, struct pending_irq *p)
> +{
> +ASSERT(spin_is_locked(&v->arch.vgic.lock));
> +
> +clear_bit(GIC_IRQ_GUEST_QUEUED, &p->status);
> +list_del_init(&p->inflight);
> +gic_remove_from_lr_pending(v, p);
> +}
> +
> void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int virq)
> {
> uint8_t priority;
> diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
> index d3d7bda50d..587a14f8b9 100644
> --- a/xen/include/asm-arm/gic.h
> +++ b/xen/include/asm-arm/gic.h
> @@ -244,7 +244,6 @@ extern void gic_raise_guest_irq(struct vcpu *v, unsigned
> int irq,
> unsigned int priority);
> extern void gic_raise_inflight_irq(struct vcpu *v, unsigned int virtual_irq);
> extern void gic_remove_from_lr_pending(struct vcpu *v, struct pending_irq
> *p);
> -extern void gic_remove_irq_from_queues(struct vcpu *v, struct pending_irq
> *p);
>
> /* Accept an interrupt from the GIC and dispatch its handler */
> extern void gic_interrupt(struct cpu_user_regs *regs, int is_fiq);
> diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
> index e489d0bf21..2a93a7bef9 100644
> --- a/xen/include/asm-arm/vgic.h
> +++ b/xen/include/asm-arm/vgic.h
> @@ -204,6 +204,7 @@ extern int vcpu_vgic_init(struct vcpu *v);
> extern struct vcpu *vgic_get_target_vcpu(struct vcpu *v, unsigned int virq);
> extern void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int virq);
> extern void vgic_vcpu_inject_spi(s
Re: [Xen-devel] [PATCH v2 04/10] ARM: VGIC: streamline gic_restore_pending_irqs()
On Thu, 7 Dec 2017, Andre Przywara wrote:
> In gic_restore_pending_irqs() we push our pending virtual IRQs into the
> list registers. This function is called once from a GIC context and once
> from a VGIC context. Refactor the calls so that we have only one callsite
> from the VGIC context. This will help separating the two worlds later.
>
> Signed-off-by: Andre Przywara
> ---
> xen/arch/arm/domain.c | 1 +
> xen/arch/arm/gic.c| 11 +--
> xen/arch/arm/traps.c | 2 +-
> xen/include/asm-arm/gic.h | 2 +-
> 4 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index a74ff1c07c..73f4d4b2b2 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -185,6 +185,7 @@ static void ctxt_switch_to(struct vcpu *n)
>
> /* VGIC */
> gic_restore_state(n);
> +gic_inject(n);
>
> /* VFP */
> vfp_restore_state(n);
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index bac8ada2bb..1f00654ef5 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -36,8 +36,6 @@
> #include
> #include
>
> -static void gic_restore_pending_irqs(struct vcpu *v);
> -
> static DEFINE_PER_CPU(uint64_t, lr_mask);
>
> #define lr_all_full() (this_cpu(lr_mask) == ((1 << gic_hw_ops->info->nr_lrs)
> - 1))
> @@ -91,8 +89,6 @@ void gic_restore_state(struct vcpu *v)
> gic_hw_ops->restore_state(v);
>
> isb();
> -
> -gic_restore_pending_irqs(v);
> }
>
> /* desc->irq needs to be disabled before calling this function */
> @@ -715,11 +711,14 @@ out:
> return rc;
> }
>
> -void gic_inject(void)
> +void gic_inject(struct vcpu *v)
> {
> ASSERT(!local_irq_is_enabled());
>
> -gic_restore_pending_irqs(current);
> +gic_restore_pending_irqs(v);
This looks suspicious to me: gic_restore_pending_irqs calls gic_set_lr.
It doesn't look like gic_restore_pending_irqs can actually be called for
v != current.
However, I think that we could remove the call to
gic_restore_pending_irqs from gic_restore_state safely, because we can
still rely on gic_inject being called before entering the guest.
There is no need to add a call to gic_inject in ctxt_switch_to, I think.
> +if ( v != current )
> +return;
>
> if ( !list_empty(¤t->arch.vgic.lr_pending) && lr_all_full() )
> gic_hw_ops->update_hcr_status(GICH_HCR_UIE, true);
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index ff3d6ff2aa..7fd676ed9d 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2298,7 +2298,7 @@ void leave_hypervisor_tail(void)
> {
> local_irq_disable();
> if (!softirq_pending(smp_processor_id())) {
> -gic_inject();
> +gic_inject(current);
>
> /*
> * If the SErrors handle option is "DIVERSE", we have to prevent
> diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
> index 587a14f8b9..28cf16654a 100644
> --- a/xen/include/asm-arm/gic.h
> +++ b/xen/include/asm-arm/gic.h
> @@ -235,7 +235,7 @@ extern int gic_route_irq_to_guest(struct domain *,
> unsigned int virq,
> int gic_remove_irq_from_guest(struct domain *d, unsigned int virq,
>struct irq_desc *desc);
>
> -extern void gic_inject(void);
> +extern void gic_inject(struct vcpu *v);
> extern void gic_clear_pending_irqs(struct vcpu *v);
> extern int gic_events_need_delivery(void);
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 05/10] ARM: VGIC: split gic.c to observe hardware/virtual GIC separation
On Thu, 7 Dec 2017, Andre Przywara wrote:
> Currently gic.c holds code to handle hardware IRQs as well as code to
> bridge VGIC requests to the GIC virtualization hardware.
> Despite being named gic.c, this file reaches into the VGIC and uses data
> structures describing virtual IRQs.
> To improve abstraction, move the VGIC functions into a separate file,
> so that gic.c does what is says on the tin.
>
> Signed-off-by: Andre Przywara
Reviewed-by: Stefano Stabellini
> ---
> xen/arch/arm/Makefile | 1 +
> xen/arch/arm/gic-vgic.c | 413
>
> xen/arch/arm/gic.c | 366 +-
> 3 files changed, 416 insertions(+), 364 deletions(-)
> create mode 100644 xen/arch/arm/gic-vgic.c
>
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 30a2a6500a..41d7366527 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -16,6 +16,7 @@ obj-y += domain_build.o
> obj-y += domctl.o
> obj-$(EARLY_PRINTK) += early_printk.o
> obj-y += gic.o
> +obj-y += gic-vgic.o
> obj-y += gic-v2.o
> obj-$(CONFIG_HAS_GICV3) += gic-v3.o
> obj-$(CONFIG_HAS_ITS) += gic-v3-its.o
> diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
> new file mode 100644
> index 00..971b3bfe37
> --- /dev/null
> +++ b/xen/arch/arm/gic-vgic.c
> @@ -0,0 +1,413 @@
> +/*
> + * xen/arch/arm/gic-vgic.c
> + *
> + * ARM Generic Interrupt Controller virtualization support
> + *
> + * Tim Deegan
> + * Copyright (c) 2011 Citrix Systems.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +extern uint64_t per_cpu__lr_mask;
> +extern const struct gic_hw_operations *gic_hw_ops;
> +
> +#define lr_all_full() (this_cpu(lr_mask) == ((1 << gic_hw_ops->info->nr_lrs)
> - 1))
> +
> +#undef GIC_DEBUG
> +
> +static void gic_update_one_lr(struct vcpu *v, int i);
> +
> +static inline void gic_set_lr(int lr, struct pending_irq *p,
> + unsigned int state)
> +{
> +ASSERT(!local_irq_is_enabled());
> +
> +clear_bit(GIC_IRQ_GUEST_PRISTINE_LPI, &p->status);
> +
> +gic_hw_ops->update_lr(lr, p, state);
> +
> +set_bit(GIC_IRQ_GUEST_VISIBLE, &p->status);
> +clear_bit(GIC_IRQ_GUEST_QUEUED, &p->status);
> +p->lr = lr;
> +}
> +
> +static inline void gic_add_to_lr_pending(struct vcpu *v, struct pending_irq
> *n)
> +{
> +struct pending_irq *iter;
> +
> +ASSERT(spin_is_locked(&v->arch.vgic.lock));
> +
> +if ( !list_empty(&n->lr_queue) )
> +return;
> +
> +list_for_each_entry ( iter, &v->arch.vgic.lr_pending, lr_queue )
> +{
> +if ( iter->priority > n->priority )
> +{
> +list_add_tail(&n->lr_queue, &iter->lr_queue);
> +return;
> +}
> +}
> +list_add_tail(&n->lr_queue, &v->arch.vgic.lr_pending);
> +}
> +
> +void gic_remove_from_lr_pending(struct vcpu *v, struct pending_irq *p)
> +{
> +ASSERT(spin_is_locked(&v->arch.vgic.lock));
> +
> +list_del_init(&p->lr_queue);
> +}
> +
> +void gic_raise_inflight_irq(struct vcpu *v, unsigned int virtual_irq)
> +{
> +struct pending_irq *n = irq_to_pending(v, virtual_irq);
> +
> +/* If an LPI has been removed meanwhile, there is nothing left to raise.
> */
> +if ( unlikely(!n) )
> +return;
> +
> +ASSERT(spin_is_locked(&v->arch.vgic.lock));
> +
> +/* Don't try to update the LR if the interrupt is disabled */
> +if ( !test_bit(GIC_IRQ_GUEST_ENABLED, &n->status) )
> +return;
> +
> +if ( list_empty(&n->lr_queue) )
> +{
> +if ( v == current )
> +gic_update_one_lr(v, n->lr);
> +}
> +#ifdef GIC_DEBUG
> +else
>
Re: [Xen-devel] [PATCH v2 06/10] ARM: VGIC: split up gic_dump_info() to cover virtual part separately
On Thu, 7 Dec 2017, Andre Przywara wrote:
> Currently gic_dump_info() not only dumps the hardware state of the GIC,
> but also the VGIC internal virtual IRQ lists.
> Split the latter off and move it into gic-vgic.c to observe the abstraction.
>
> Signed-off-by: Andre Przywara
Reviewed-by: Stefano Stabellini
> ---
> xen/arch/arm/domain.c | 1 +
> xen/arch/arm/gic-vgic.c | 11 +++
> xen/arch/arm/gic.c| 12
> xen/include/asm-arm/gic.h | 1 +
> 4 files changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 73f4d4b2b2..5d2943b800 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -942,6 +942,7 @@ long arch_do_vcpu_op(int cmd, struct vcpu *v,
> XEN_GUEST_HANDLE_PARAM(void) arg)
> void arch_dump_vcpu_info(struct vcpu *v)
> {
> gic_dump_info(v);
> +gic_dump_vgic_info(v);
> }
>
> void vcpu_mark_events_pending(struct vcpu *v)
> diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
> index 971b3bfe37..90b827c574 100644
> --- a/xen/arch/arm/gic-vgic.c
> +++ b/xen/arch/arm/gic-vgic.c
> @@ -403,6 +403,17 @@ void gic_inject(struct vcpu *v)
> gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
> }
>
> +void gic_dump_vgic_info(struct vcpu *v)
> +{
> +struct pending_irq *p;
> +
> +list_for_each_entry ( p, &v->arch.vgic.inflight_irqs, inflight )
> +printk("Inflight irq=%u lr=%u\n", p->irq, p->lr);
> +
> +list_for_each_entry( p, &v->arch.vgic.lr_pending, lr_queue )
> +printk("Pending irq=%d\n", p->irq);
> +}
> +
> /*
> * Local variables:
> * mode: C
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 04e6d66b69..4cb74d449e 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -443,20 +443,8 @@ static void maintenance_interrupt(int irq, void *dev_id,
> struct cpu_user_regs *r
>
> void gic_dump_info(struct vcpu *v)
> {
> -struct pending_irq *p;
> -
> printk("GICH_LRs (vcpu %d) mask=%"PRIx64"\n", v->vcpu_id,
> v->arch.lr_mask);
> gic_hw_ops->dump_state(v);
> -
> -list_for_each_entry ( p, &v->arch.vgic.inflight_irqs, inflight )
> -{
> -printk("Inflight irq=%u lr=%u\n", p->irq, p->lr);
> -}
> -
> -list_for_each_entry( p, &v->arch.vgic.lr_pending, lr_queue )
> -{
> -printk("Pending irq=%d\n", p->irq);
> -}
> }
>
> void init_maintenance_interrupt(void)
> diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
> index 28cf16654a..4f4fd555c1 100644
> --- a/xen/include/asm-arm/gic.h
> +++ b/xen/include/asm-arm/gic.h
> @@ -285,6 +285,7 @@ extern void send_SGI_allbutself(enum gic_sgi sgi);
>
> /* print useful debug info */
> extern void gic_dump_info(struct vcpu *v);
> +extern void gic_dump_vgic_info(struct vcpu *v);
>
> /* Number of interrupt lines */
> extern unsigned int gic_number_lines(void);
> --
> 2.14.1
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 10/10] ARM: VGIC: rework gicv[23]_update_lr to not use pending_irq
On Thu, 7 Dec 2017, Andre Przywara wrote:
> The functions to actually populate a list register were accessing
> the VGIC internal pending_irq struct, although they should be abstracting
> from that.
> Break the needed information down to remove the reference to pending_irq
> from gic-v[23].c.
>
> Signed-off-by: Andre Przywara
Reviewed-by: Stefano Stabellini
> ---
> xen/arch/arm/gic-v2.c | 14 +++---
> xen/arch/arm/gic-v3.c | 12 ++--
> xen/arch/arm/gic-vgic.c | 3 ++-
> xen/include/asm-arm/gic.h | 4 ++--
> xen/include/asm-arm/irq.h | 3 +++
> 5 files changed, 20 insertions(+), 16 deletions(-)
>
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index 511c8d7294..2b271ba322 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -428,8 +428,8 @@ static void gicv2_disable_interface(void)
> spin_unlock(&gicv2.lock);
> }
>
> -static void gicv2_update_lr(int lr, const struct pending_irq *p,
> -unsigned int state)
> +static void gicv2_update_lr(int lr, unsigned int virq, uint8_t priority,
> +unsigned int hw_irq, unsigned int state)
> {
> uint32_t lr_reg;
>
> @@ -437,12 +437,12 @@ static void gicv2_update_lr(int lr, const struct
> pending_irq *p,
> BUG_ON(lr < 0);
>
> lr_reg = (((state & GICH_V2_LR_STATE_MASK) << GICH_V2_LR_STATE_SHIFT) |
> - ((GIC_PRI_TO_GUEST(p->priority) & GICH_V2_LR_PRIORITY_MASK)
> - << GICH_V2_LR_PRIORITY_SHIFT) |
> - ((p->irq & GICH_V2_LR_VIRTUAL_MASK) <<
> GICH_V2_LR_VIRTUAL_SHIFT));
> + ((GIC_PRI_TO_GUEST(priority) & GICH_V2_LR_PRIORITY_MASK)
> + << GICH_V2_LR_PRIORITY_SHIFT) |
> + ((virq & GICH_V2_LR_VIRTUAL_MASK) <<
> GICH_V2_LR_VIRTUAL_SHIFT));
>
> -if ( p->desc != NULL )
> -lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
> +if ( hw_irq != INVALID_IRQ )
> +lr_reg |= GICH_V2_LR_HW | ((hw_irq & GICH_V2_LR_PHYSICAL_MASK )
> << GICH_V2_LR_PHYSICAL_SHIFT);
>
> writel_gich(lr_reg, GICH_LR + lr * 4);
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index 473e26111f..ce1e5cad25 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -962,8 +962,8 @@ static void gicv3_disable_interface(void)
> spin_unlock(&gicv3.lock);
> }
>
> -static void gicv3_update_lr(int lr, const struct pending_irq *p,
> -unsigned int state)
> +static void gicv3_update_lr(int lr, unsigned int virq, uint8_t priority,
> +unsigned int hw_irq, unsigned int state)
> {
> uint64_t val = 0;
>
> @@ -979,11 +979,11 @@ static void gicv3_update_lr(int lr, const struct
> pending_irq *p,
> if ( current->domain->arch.vgic.version == GIC_V3 )
> val |= GICH_LR_GRP1;
>
> -val |= ((uint64_t)p->priority & 0xff) << GICH_LR_PRIORITY_SHIFT;
> -val |= ((uint64_t)p->irq & GICH_LR_VIRTUAL_MASK) <<
> GICH_LR_VIRTUAL_SHIFT;
> +val |= (uint64_t)priority << GICH_LR_PRIORITY_SHIFT;
> +val |= ((uint64_t)virq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT;
>
> - if ( p->desc != NULL )
> - val |= GICH_LR_HW | (((uint64_t)p->desc->irq & GICH_LR_PHYSICAL_MASK)
> + if ( hw_irq != INVALID_IRQ )
> + val |= GICH_LR_HW | (((uint64_t)hw_irq & GICH_LR_PHYSICAL_MASK)
> << GICH_LR_PHYSICAL_SHIFT);
>
> gicv3_ich_write_lr(lr, val);
> diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
> index 8d43a6ba76..60f6498092 100644
> --- a/xen/arch/arm/gic-vgic.c
> +++ b/xen/arch/arm/gic-vgic.c
> @@ -52,7 +52,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
>
> clear_bit(GIC_IRQ_GUEST_PRISTINE_LPI, &p->status);
>
> -gic_hw_ops->update_lr(lr, p, state);
> +gic_hw_ops->update_lr(lr, p->irq, p->priority,
> + p->desc ? p->desc->irq : INVALID_IRQ, state);
>
> set_bit(GIC_IRQ_GUEST_VISIBLE, &p->status);
> clear_bit(GIC_IRQ_GUEST_QUEUED, &p->status);
> diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
> index 4f4fd555c1..ce9d1d058a 100644
> --- a/xen/include/asm-arm/gic.h
> +++ b/xen/include/asm-arm/gic.h
> @@ -342,8 +342,8 @@ struct gic_hw_operations {
> /* Disable CPU physical and virtual interfaces */
>
Re: [Xen-devel] [PATCH for-next 07/16] xen/arm: Introduce copy_to_guest_phys_flush_dcache
On Fri, 8 Dec 2017, Julien Grall wrote:
> On 06/12/17 12:27, Julien Grall wrote:
> > On 12/06/2017 01:26 AM, Stefano Stabellini wrote:
> > > On Thu, 23 Nov 2017, Julien Grall wrote:
> > > > Hi Andrew,
> > > >
> > > > On 23/11/17 18:49, Andrew Cooper wrote:
> > > > > On 23/11/17 18:32, Julien Grall wrote:
> > > > > > This new function will be used in a follow-up patch to copy data to
> > > > > > the
> > > > > > guest
> > > > > > using the IPA (aka guest physical address) and then clean the cache.
> > > > > >
> > > > > > Signed-off-by: Julien Grall
> > > > > > ---
> > > > > > xen/arch/arm/guestcopy.c | 10 ++
> > > > > > xen/include/asm-arm/guest_access.h | 6 ++
> > > > > > 2 files changed, 16 insertions(+)
> > > > > >
> > > > > > diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
> > > > > > index be53bee559..7958663970 100644
> > > > > > --- a/xen/arch/arm/guestcopy.c
> > > > > > +++ b/xen/arch/arm/guestcopy.c
> > > > > > @@ -110,6 +110,16 @@ unsigned long raw_copy_from_guest(void *to,
> > > > > > const
> > > > > > void __user *from, unsigned le
> > > > > > COPY_from_guest | COPY_linear);
> > > > > > }
> > > > > > +unsigned long copy_to_guest_phys_flush_dcache(struct domain *d,
> > > > > > + paddr_t gpa,
> > > > > > + void *buf,
> > > > > > + unsigned int len)
> > > > > > +{
> > > > > > + /* P2M is shared between all vCPUs, so the vCPU used does not
> > > > > > matter.
> > > > > > */
> > > > >
> > > > > Be very careful with this line of thinking. It is only works after
> > > > > DOMCTL_max_vcpus has succeeded, and before that point, it is a latent
> > > > > NULL pointer dereference.
> > > >
> > > > I really don't expect that function been used before DOMCT_max_vcpus is
> > > > set.
> > > > It is only used for hardware emulation or Xen loading image into the
> > > > hardware
> > > > domain memory. I could add a check d->vcpus to be safe.
> > > >
> > > > >
> > > > > Also, what about vcpus configured with alternative views?
> > > >
> > > > It is not important because the underlying call is get_page_from_gfn
> > > > that does
> > > > not care about the alternative view (that function take a domain in
> > > > parameter). I can update the comment.
> > > Since this is a new function, would it make sense to take a struct
> > > vcpu* as parameter, instead of a struct domain* ?
> >
> > Well, I suggested this patch this way because likely everyone will use with
> > d->vcpus[0]. And then you would have to wonder why d->vcpus[0] and not
> > d->vcpus[1]...
>
> Thinking a bit more to this, it might be better/safer to pass either a domain
> or a vCPU to copy_guest. I can see 2 solutions:
> 1# Introduce a union that use the same parameter:
> union
> {
> struct
> {
> struct domain *d;
> } ipa;
> struct
> {
> struct vcpu *v;
> } gva;
> }
> The structure here would be to ensure that it is clear that only
> domain (resp. vcpu) should be used with ipa (resp. gva).
>
> 2# Have 2 parameters, vcpu and domain.
>
> Any opinions?
I think that would be clearer. You could also add a paddr_t/vaddr_t
correspondingly inside the union maybe.___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-next 07/16] xen/arm: Introduce copy_to_guest_phys_flush_dcache
On Fri, 8 Dec 2017, Julien Grall wrote:
> On 8 Dec 2017 22:26, "Stefano Stabellini" wrote:
> On Fri, 8 Dec 2017, Julien Grall wrote:
> > On 06/12/17 12:27, Julien Grall wrote:
> > > On 12/06/2017 01:26 AM, Stefano Stabellini wrote:
> > > > On Thu, 23 Nov 2017, Julien Grall wrote:
> > > > > Hi Andrew,
> > > > >
> > > > > On 23/11/17 18:49, Andrew Cooper wrote:
> > > > > > On 23/11/17 18:32, Julien Grall wrote:
> > > > > > > This new function will be used in a follow-up patch to copy
> data to
> > > > > > > the
> > > > > > > guest
> > > > > > > using the IPA (aka guest physical address) and then clean
> the cache.
> > > > > > >
> > > > > > > Signed-off-by: Julien Grall
> > > > > > > ---
> > > > > > > xen/arch/arm/guestcopy.c | 10 ++
> > > > > > > xen/include/asm-arm/guest_access.h | 6 ++
> > > > > > > 2 files changed, 16 insertions(+)
> > > > > > >
> > > > > > > diff --git a/xen/arch/arm/guestcopy.c
> b/xen/arch/arm/guestcopy.c
> > > > > > > index be53bee559..7958663970 100644
> > > > > > > --- a/xen/arch/arm/guestcopy.c
> > > > > > > +++ b/xen/arch/arm/guestcopy.c
> > > > > > > @@ -110,6 +110,16 @@ unsigned long raw_copy_from_guest(void
> *to,
> > > > > > > const
> > > > > > > void __user *from, unsigned le
> > > > > > > COPY_from_guest | COPY_linear);
> > > > > > > }
> > > > > > > +unsigned long copy_to_guest_phys_flush_dcache(struct
> domain *d,
> > > > > > > + paddr_t gpa,
> > > > > > > + void *buf,
> > > > > > > + unsigned int
> len)
> > > > > > > +{
> > > > > > > + /* P2M is shared between all vCPUs, so the vCPU used
> does not
> > > > > > > matter.
> > > > > > > */
> > > > > >
> > > > > > Be very careful with this line of thinking. It is only works
> after
> > > > > > DOMCTL_max_vcpus has succeeded, and before that point, it is
> a latent
> > > > > > NULL pointer dereference.
> > > > >
> > > > > I really don't expect that function been used before
> DOMCT_max_vcpus is
> > > > > set.
> > > > > It is only used for hardware emulation or Xen loading image
> into the
> > > > > hardware
> > > > > domain memory. I could add a check d->vcpus to be safe.
> > > > >
> > > > > >
> > > > > > Also, what about vcpus configured with alternative views?
> > > > >
> > > > > It is not important because the underlying call is
> get_page_from_gfn
> > > > > that does
> > > > > not care about the alternative view (that function take a
> domain in
> > > > > parameter). I can update the comment.
> > > > Since this is a new function, would it make sense to take a struct
> > > > vcpu* as parameter, instead of a struct domain* ?
> > >
> > > Well, I suggested this patch this way because likely everyone will
> use with
> > > d->vcpus[0]. And then you would have to wonder why d->vcpus[0] and
> not
> > > d->vcpus[1]...
> >
> > Thinking a bit more to this, it might be better/safer to pass either
> a domain
> > or a vCPU to copy_guest. I can see 2 solutions:
> > 1# Introduce a union that use the same parameter:
> > union
> > {
> > struct
> > {
> > struct domain *d;
> > } ipa;
> > struct
>
Re: [Xen-devel] [Qemu-devel] [PATCH] xen/pt: Set is_express to avoid out-of-bounds write
On Sat, 28 Oct 2017, Simon Gaiser wrote: > The passed-through device might be an express device. In this case the > old code allocated a too small emulated config space in > pci_config_alloc() since pci_config_size() returned the size for a > non-express device. This leads to an out-of-bound write in > xen_pt_config_reg_init(), which sometimes results in crashes. So set > is_express as already done for KVM in vfio-pci. > > Shortened ASan report: > > ==17512==ERROR: AddressSanitizer: heap-buffer-overflow on address > 0x61141648 at pc 0x55e0fdac51ff bp 0x7ffe4af07410 sp 0x7ffe4af07408 > WRITE of size 2 at 0x61141648 thread T0 > #0 0x55e0fdac51fe in memcpy > /usr/include/x86_64-linux-gnu/bits/string3.h:53 > #1 0x55e0fdac51fe in stw_he_p include/qemu/bswap.h:330 > #2 0x55e0fdac51fe in stw_le_p include/qemu/bswap.h:379 > #3 0x55e0fdac51fe in pci_set_word include/hw/pci/pci.h:490 > #4 0x55e0fdac51fe in xen_pt_config_reg_init > hw/xen/xen_pt_config_init.c:1991 > #5 0x55e0fdac51fe in xen_pt_config_init hw/xen/xen_pt_config_init.c:2067 > #6 0x55e0fdabcf4d in xen_pt_realize hw/xen/xen_pt.c:830 > #7 0x55e0fdf59666 in pci_qdev_realize hw/pci/pci.c:2034 > #8 0x55e0fdda7d3d in device_set_realized hw/core/qdev.c:914 > [...] > > 0x61141648 is located 8 bytes to the right of 256-byte region > [0x61141540,0x61141640) > allocated by thread T0 here: > #0 0x7ff596a94bb8 in __interceptor_calloc > (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xd9bb8) > #1 0x7ff57da66580 in g_malloc0 > (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x50580) > #2 0x55e0fdda7d3d in device_set_realized hw/core/qdev.c:914 > [...] > > Signed-off-by: Simon Gaiser Acked-by: Stefano Stabellini > --- > > I found this by debugging crashes and I'm not familiar with this code, > so I'm not sure if this has no unintended side effects. > > hw/xen/xen_pt.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c > index b6d71bb52a..90ffd45e7d 100644 > --- a/hw/xen/xen_pt.c > +++ b/hw/xen/xen_pt.c > @@ -946,6 +946,7 @@ static void xen_pci_passthrough_class_init(ObjectClass > *klass, void *data) > k->exit = xen_pt_unregister_device; > k->config_read = xen_pt_pci_read_config; > k->config_write = xen_pt_pci_write_config; > +k->is_express = 1; /* We might be */ > set_bit(DEVICE_CATEGORY_MISC, dc->categories); > dc->desc = "Assign an host PCI device with Xen"; > dc->props = xen_pci_passthrough_properties; > -- > 2.15.0.rc1 > > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC] xen/arm: Suspend to RAM Support in Xen for ARM
On Wed, 9 Aug 2017, Mirela Simonovic wrote: > This document contains our draft proposal for implementing "suspend to RAM" > support for ARM in Xen, as discussed during the last Xen ARM community call. > It covers the basic suspend to RAM mechanism based on ARM PSCI standard, > that would allow individual guests and Xen itself to suspend. > > We would appreciate your feedback. > > Signed-off-by: Mirela Simonovic I am really sorry, for the very late reply. This email fell through the cracks. In general, if I forget about an email, please send a follow up to help me remember :-) Do you have an more up-to-date proposal or is this still the latest? From an high level, it looks good, only one minor comment: don't call it "hotplug" because usually in the Xen community hotplug means adding more vcpus or removing vcpus at runtime (removing entirely, not suspending). But the approach looks good to me. > --- > docs/misc/arm/suspend-to-ram.txt | 210 > +++ > 1 file changed, 210 insertions(+) > create mode 100644 docs/misc/arm/suspend-to-ram.txt > > diff --git a/docs/misc/arm/suspend-to-ram.txt > b/docs/misc/arm/suspend-to-ram.txt > new file mode 100644 > index 00..ec8080fc64 > --- /dev/null > +++ b/docs/misc/arm/suspend-to-ram.txt > @@ -0,0 +1,210 @@ > +% Suspend to RAM Support in Xen for ARM > +% Revision 1.0 > + > + > +Overview > + > + > +Suspend to RAM (in the following text 'suspend') for ARM in Xen should be > +coordinated using ARM PSCI standard [1]. > + > +EL1/2 should suspend in the following order: > +1) Unprivileged guests (DomUs) suspend > +2) Privileged guest (Dom0) suspends > +3) Xen suspends > + > +Since this proposal is focused on implementing PSCI-based suspend mechanisms > in > +Xen, communication with or among the guests is not covered by this document. > +The order of suspending the guests is assumed to be guaranteed by the > software > +running in EL1. > + > +- > +Suspending Guests > +- > + > +Suspend procedure for a guest consists of the following: > +1) Suspending devices > +2) Suspending non-boot CPUs > +3) System suspend, performed by the boot CPU > + > +Each guest should suspend the devices it owns. Suspending of devices is not > +covered by this document. The document covers only mechanisms for suspending > +non-boot CPUs, as well as the system suspend. > + > +Guests should suspend their non-boot vCPUs using the hotplug mechanism. > +Virtual CPUs should be put offline using the already implemented PSCI > vCPU_OFF > +call (prefix 'v' is added to distinguish PSCI calls made by guests to Xen, > which > +affect virtual machines; as opposed to PSCI calls made by Xen to the EL3, > which > +can affect power state of the physical machine). > + > +After suspending its non-boot vCPUs a guest should finalize the suspend by > +making the vSYSTEM_SUSPEND PSCI call. The resume address is specified by the > +guest via the vSYSTEM_SUSPEND entry_point_address argument. The > vSYSTEM_SUSPEND > +call is currently not implemented in Xen. > + > +It is expected that a guest leaves enabled all interrupts that should wake it > +up. Other interrupts should be disabled by the guest prior to calling > +vSYSTEM_SUSPEND. > + > +After an unprivileged guest suspends, Xen will not suspend. Xen would suspend > +only after the Dom0 completes the system suspend. > + > +-- > +Suspending Xen > +-- > + > +Xen should start suspending itself upon receiving the vSYSTEM_SUSPEND call > +from the last running guest (Dom0). At that moment all physical CPUs are > still > +online (taking offline a vCPU or suspending a VM does not affect physical > CPUs). > +Xen shall now put offline the non-boot pCPUs by making the CPU_OFF PSCI call > +to EL3. The CPU_OFF PSCI function is currently not implemented in Xen. > + > +After putting offline the non-boot cores Xen must save the context and > finalize > +suspend by invoking SYSTEM_SUSPEND PSCI call, which is passed to EL3. > +The resume point of Xen is specified by the entry_point_address argument of > the > +SYSTEM_SUSPEND call. The SYSTEM_SUSPEND function and context saving is not > +implemented in Xen for ARM today. > + > + > +Resuming Xen > + > + > +Xen must be resumed prior to any software running in EL1. Starting from the > +resume point, Xen should restore the context and resume Dom0. Dom0 shall > always > +be resumed whenever Xen resumes. > +The whole Xen resume flow for the ARM architecture has to be implemented. > + > +--- > +Resuming Guests > +--- > + > +Resume of the privileged guest (Dom0) is always following the Xen resume. > + > +An unprivileged guest shall resume once a device it owns triggers a wake-up > +interrupt, regardless of whether Xen was suspended when the wake-up interrupt > +was triggered. If Xen was suspended, it is assumed that Dom0 will be running > +before the DomU guest starts to r
Re: [Xen-devel] [PATCH v3 for-next 1/4] xen/arm: domain_build: Clean-up insert_11_bank
On Wed, 1 Nov 2017, Julien Grall wrote:
> - Remove spurious ()
> - Add missing spaces
> - Turn 1 << to 1UL <<
> - Rename spfn to smfn and switch to mfn_t
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
>
> Cc: Stefano Stabellini
>
> Changes in v2:
> - Remove double space
> - s/spfn/smfn/ and switch to mfn_t
> ---
> xen/arch/arm/domain_build.c | 17 ++---
> 1 file changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index bf29299707..5532068ab1 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -50,6 +50,8 @@ struct map_range_data
> /* Override macros from asm/page.h to make them work with mfn_t */
> #undef virt_to_mfn
> #define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
> +#undef page_to_mfn
> +#define page_to_mfn(pg) _mfn(__page_to_mfn(pg))
>
> //#define DEBUG_11_ALLOCATION
> #ifdef DEBUG_11_ALLOCATION
> @@ -104,16 +106,16 @@ static bool insert_11_bank(struct domain *d,
> unsigned int order)
> {
> int res, i;
> -paddr_t spfn;
> +mfn_t smfn;
> paddr_t start, size;
>
> -spfn = page_to_mfn(pg);
> -start = pfn_to_paddr(spfn);
> -size = pfn_to_paddr((1 << order));
> +smfn = page_to_mfn(pg);
> +start = mfn_to_maddr(smfn);
> +size = pfn_to_paddr(1UL << order);
>
> D11PRINT("Allocated %#"PRIpaddr"-%#"PRIpaddr" (%ldMB/%ldMB, order %d)\n",
> start, start + size,
> - 1UL << (order+PAGE_SHIFT-20),
> + 1UL << (order + PAGE_SHIFT - 20),
> /* Don't want format this as PRIpaddr (16 digit hex) */
> (unsigned long)(kinfo->unassigned_mem >> 20),
> order);
> @@ -126,7 +128,7 @@ static bool insert_11_bank(struct domain *d,
> goto fail;
> }
>
> -res = guest_physmap_add_page(d, _gfn(spfn), _mfn(spfn), order);
> +res = guest_physmap_add_page(d, _gfn(mfn_x(smfn)), smfn, order);
> if ( res )
> panic("Failed map pages to DOM0: %d", res);
>
> @@ -167,7 +169,8 @@ static bool insert_11_bank(struct domain *d,
> */
> if ( start + size < bank->start && kinfo->mem.nr_banks <
> NR_MEM_BANKS )
> {
> -memmove(bank + 1, bank, sizeof(*bank)*(kinfo->mem.nr_banks - i));
> +memmove(bank + 1, bank,
> +sizeof(*bank) * (kinfo->mem.nr_banks - i));
> kinfo->mem.nr_banks++;
> bank->start = start;
> bank->size = size;
> --
> 2.11.0
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 for-next 2/4] xen/arm32: mm: Rework is_xen_heap_page to avoid nameclash
On Wed, 1 Nov 2017, Julien Grall wrote:
> The arm32 version of the function is_xen_heap_page currently define a
> variable _mfn. This will lead to a compiler when use typesafe MFN in a
> follow-up patch:
>
> called object '_mfn' is not a function or function pointer
>
> Fix it by renaming the local variable _mfn to mfn_.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
>
> Cc: Stefano Stabellini
>
> Changes in v3:
> - Fix typo in the commit message
> ---
> xen/include/asm-arm/mm.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
> index cd6dfb54b9..737a429409 100644
> --- a/xen/include/asm-arm/mm.h
> +++ b/xen/include/asm-arm/mm.h
> @@ -140,9 +140,9 @@ extern vaddr_t xenheap_virt_start;
> #ifdef CONFIG_ARM_32
> #define is_xen_heap_page(page) is_xen_heap_mfn(page_to_mfn(page))
> #define is_xen_heap_mfn(mfn) ({ \
> -unsigned long _mfn = (mfn); \
> -(_mfn >= mfn_x(xenheap_mfn_start) &&\
> - _mfn < mfn_x(xenheap_mfn_end));\
> +unsigned long mfn_ = (mfn); \
> +(mfn_ >= mfn_x(xenheap_mfn_start) &&\
> + mfn_ < mfn_x(xenheap_mfn_end));\
> })
> #else
> #define is_xen_heap_page(page) ((page)->count_info & PGC_xen_heap)
> --
> 2.11.0
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 for-next 4/4] xen: Convert __page_to_mfn and __mfn_to_page to use typesafe MFN
On Wed, 1 Nov 2017, Julien Grall wrote: > Most of the users of page_to_mfn and mfn_to_page are either overriding > the macros to make them work with mfn_t or use mfn_x/_mfn because the > rest of the function use mfn_t. > > So make __page_to_mfn and __mfn_to_page return mfn_t by default. > > Only reasonable clean-ups are done in this patch because it is > already quite big. So some of the files now override page_to_mfn and > mfn_to_page to avoid using mfn_t. > > Lastly, domain_page_to_mfn is also converted to use mfn_t given that > most of the callers are now switched to _mfn(domain_page_to_mfn(...)). > > Signed-off-by: Julien Grall Acked-by: Stefano Stabellini > --- > > Andrew suggested to drop IS_VALID_PAGE in xen/tmem_xen.h. His comment > was: > > "/sigh This is tautological. The definition of a "valid mfn" in this > case is one for which we have frametable entry, and by having a struct > page_info in our hands, this is by definition true (unless you have a > wild pointer, at which point your bug is elsewhere). > > IS_VALID_PAGE() is only ever used in assertions and never usefully, so > instead I would remove it entirely rather than trying to fix it up." > > I can remove the function in a separate patch at the begining of the > series if Konrad (TMEM maintainer) is happy with that. > > Cc: Stefano Stabellini > Cc: Julien Grall > Cc: Andrew Cooper > Cc: George Dunlap > Cc: Ian Jackson > Cc: Jan Beulich > Cc: Konrad Rzeszutek Wilk > Cc: Tim Deegan > Cc: Wei Liu > Cc: Razvan Cojocaru > Cc: Tamas K Lengyel > Cc: Paul Durrant > Cc: Boris Ostrovsky > Cc: Suravee Suthikulpanit > Cc: Jun Nakajima > Cc: Kevin Tian > Cc: George Dunlap > Cc: Gang Wei > Cc: Shane Wang > > Changes in v3: > - Rebase on the latest staging and fix some conflicts. Tags > haven't be retained. > - Switch the printf format to PRI_mfn > > Changes in v2: > - Some part have been moved in separate patch > - Remove one spurious comment > - Convert domain_page_to_mfn to use mfn_t > --- > xen/arch/arm/domain_build.c | 2 -- > xen/arch/arm/kernel.c | 2 +- > xen/arch/arm/mem_access.c | 2 +- > xen/arch/arm/mm.c | 8 > xen/arch/arm/p2m.c | 10 ++ > xen/arch/x86/cpu/vpmu.c | 4 ++-- > xen/arch/x86/domain.c | 21 +++-- > xen/arch/x86/domain_page.c | 6 +++--- > xen/arch/x86/domctl.c | 2 +- > xen/arch/x86/hvm/dm.c | 2 +- > xen/arch/x86/hvm/dom0_build.c | 6 +++--- > xen/arch/x86/hvm/emulate.c | 6 +++--- > xen/arch/x86/hvm/hvm.c | 16 > xen/arch/x86/hvm/ioreq.c| 6 +++--- > xen/arch/x86/hvm/stdvga.c | 2 +- > xen/arch/x86/hvm/svm/svm.c | 4 ++-- > xen/arch/x86/hvm/viridian.c | 6 +++--- > xen/arch/x86/hvm/vmx/vmcs.c | 2 +- > xen/arch/x86/hvm/vmx/vmx.c | 10 +- > xen/arch/x86/hvm/vmx/vvmx.c | 6 +++--- > xen/arch/x86/mm.c | 6 -- > xen/arch/x86/mm/guest_walk.c| 6 +++--- > xen/arch/x86/mm/hap/guest_walk.c| 2 +- > xen/arch/x86/mm/hap/hap.c | 6 -- > xen/arch/x86/mm/hap/nested_ept.c| 2 +- > xen/arch/x86/mm/mem_sharing.c | 5 - > xen/arch/x86/mm/p2m-ept.c | 4 > xen/arch/x86/mm/p2m-pod.c | 6 -- > xen/arch/x86/mm/p2m.c | 6 -- > xen/arch/x86/mm/paging.c| 6 -- > xen/arch/x86/mm/shadow/private.h| 16 ++-- > xen/arch/x86/numa.c | 2 +- > xen/arch/x86/physdev.c | 2 +- > xen/arch/x86/pv/callback.c | 6 -- > xen/arch/x86/pv/descriptor-tables.c | 10 -- > xen/arch/x86/pv/dom0_build.c| 6 ++ > xen/arch/x86/pv/domain.c| 6 -- > xen/arch/x86/pv/emul-gate-op.c | 6 -- > xen/arch/x86/pv/emul-priv-op.c | 10 -- > xen/arch/x86/pv/grant_table.c | 6 -- > xen/arch/x86/pv/ro-page-fault.c | 6 -- > xen/arch/x86/smpboot.c | 6 -- > xen/arch/x86/tboot.c| 4 ++-- > xen/arch/x86/traps.c| 4 ++-- > xen/arch/x86/x86_64/mm.c| 6 ++ > xen/common/domain.c | 4 ++-- > xen/common/grant_table.c| 6 +
Re: [Xen-devel] [PATCH v3 for-next 0/4] xen: Convert __page_to_mfn and _mfn_to_page to use typesafe MFN
On Thu, 9 Nov 2017, Jan Beulich wrote: > >>> On 09.11.17 at 16:48, wrote: > > On 09/11/17 15:47, Jan Beulich wrote: > > On 09.11.17 at 16:39, wrote: > >>> What I meant is you would replace the 4 occurrences by > >>> mfn_to_page(_mfn(...)). If you are happy with that, then fine. > >> > >> Oh, sure, that's a fine intermediate state, which we have all over > >> the place right now. It's clear that it'll take a while to fully carry > >> through typesafeness to everywhere. > > > > Would you be fine with other part of Xen too? If so, I can have a go at > > removing completely __page_to_mfn/__mfn_to_page. > > Oh, if you want to go that extra mile, that's certainly fine with me. FYI I committed the first two patches (which are ARM only). I'll leave to other to commit the other two. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-next 07/16] xen/arm: Introduce copy_to_guest_phys_flush_dcache
On Tue, 12 Dec 2017, Julien Grall wrote:
> Hi Stefano,
>
> On 12/08/2017 10:43 PM, Stefano Stabellini wrote:
> > On Fri, 8 Dec 2017, Julien Grall wrote:
> > > On 8 Dec 2017 22:26, "Stefano Stabellini" wrote:
> > >On Fri, 8 Dec 2017, Julien Grall wrote:
> > >> On 06/12/17 12:27, Julien Grall wrote:
> > >> > On 12/06/2017 01:26 AM, Stefano Stabellini wrote:
> > >> > > On Thu, 23 Nov 2017, Julien Grall wrote:
> > >> > > > Hi Andrew,
> > >> > > >
> > >> > > > On 23/11/17 18:49, Andrew Cooper wrote:
> > >> > > > > On 23/11/17 18:32, Julien Grall wrote:
> > >> > > > > > This new function will be used in a follow-up patch to
> > > copy data to
> > >> > > > > > the
> > >> > > > > > guest
> > >> > > > > > using the IPA (aka guest physical address) and then
> > > clean the cache.
> > >> > > > > >
> > >> > > > > > Signed-off-by: Julien Grall
> > >> > > > > > ---
> > >> > > > > > xen/arch/arm/guestcopy.c | 10 ++
> > >> > > > > > xen/include/asm-arm/guest_access.h | 6 ++
> > >> > > > > > 2 files changed, 16 insertions(+)
> > >> > > > > >
> > >> > > > > > diff --git a/xen/arch/arm/guestcopy.c
> > > b/xen/arch/arm/guestcopy.c
> > >> > > > > > index be53bee559..7958663970 100644
> > >> > > > > > --- a/xen/arch/arm/guestcopy.c
> > >> > > > > > +++ b/xen/arch/arm/guestcopy.c
> > >> > > > > > @@ -110,6 +110,16 @@ unsigned long
> > > raw_copy_from_guest(void *to,
> > >> > > > > > const
> > >> > > > > > void __user *from, unsigned le
> > >> > > > > > COPY_from_guest |
> > > COPY_linear);
> > >> > > > > > }
> > >> > > > > > +unsigned long
> > > copy_to_guest_phys_flush_dcache(struct domain *d,
> > >> > > > > > + paddr_t
> > > gpa,
> > >> > > > > > + void
> > > *buf,
> > >> > > > > > + unsigned
> > > int len)
> > >> > > > > > +{
> > >> > > > > > + /* P2M is shared between all vCPUs, so the vCPU
> > > used does not
> > >> > > > > > matter.
> > >> > > > > > */
> > >> > > > >
> > >> > > > > Be very careful with this line of thinking. It is only
> > > works after
> > >> > > > > DOMCTL_max_vcpus has succeeded, and before that point, it
> > > is a latent
> > >> > > > > NULL pointer dereference.
> > >> > > >
> > >> > > > I really don't expect that function been used before
> > > DOMCT_max_vcpus is
> > >> > > > set.
> > >> > > > It is only used for hardware emulation or Xen loading image
> > > into the
> > >> > > > hardware
> > >> > > > domain memory. I could add a check d->vcpus to be safe.
> > >> > > >
> > >> > > > >
> > >> > > > > Also, what about vcpus configured with alternative views?
> > >> > > >
> > >> > > > It is not important because the underlying call is
> > > get_page_from_gfn
> > >> > > > that does
> > >> > > > not care about the alternative view (that function take a
> > > domain in
> > >> > > > parameter). I can update the comment.
> > >> > > Since this is a new function, would it make sense to take a
> > &
Re: [Xen-devel] [v2 02/16] xen/arm: raw_copy_to_guest_helper: Rework the prototype and rename it
On Tue, 12 Dec 2017, Julien Grall wrote:
> All the helpers within arch/arm/guestcopy.c are doing the same things:
> copy data from/to the guest.
>
> At the moment, the logic is duplicated in each helpers making more
> difficult to implement new variant.
>
> The first step for the consolidation is to get a common prototype and a
> base. For convenience (it is at the beginning of the file!),
> raw_copy_to_guest_helper is chosen.
>
> The function is now renamed copy_guest to show it will be a
> generic function to copy data from/to the guest. Note that for now, only
> copying to guest virtual address is supported. Follow-up patches will
> extend the support.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> Changes in v2:
> - Use vaddr_t
> - Use uint64_t for addr in copy_guest
> - Add a BUILD_BUG_ON to make sure vaddr_t fit in uint64_t.
> ---
> xen/arch/arm/guestcopy.c | 20 +++-
> 1 file changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
> index 2620e659b4..08d0fa0a83 100644
> --- a/xen/arch/arm/guestcopy.c
> +++ b/xen/arch/arm/guestcopy.c
> @@ -7,11 +7,13 @@
>
> #define COPY_flush_dcache (1U << 0)
>
> -static unsigned long raw_copy_to_guest_helper(void *to, const void *from,
> - unsigned len, int flags)
> +static unsigned long copy_guest(void *buf, uint64_t addr, unsigned int len,
> +unsigned int flags)
> {
> /* XXX needs to handle faults */
> -unsigned offset = (vaddr_t)to & ~PAGE_MASK;
> +unsigned offset = addr & ~PAGE_MASK;
> +
> +BUILD_BUG_ON((sizeof(addr)) < sizeof(vaddr_t));
>
> while ( len )
> {
> @@ -19,21 +21,21 @@ static unsigned long raw_copy_to_guest_helper(void *to,
> const void *from,
> unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
> struct page_info *page;
>
> -page = get_page_from_gva(current, (vaddr_t) to, GV2M_WRITE);
> +page = get_page_from_gva(current, addr, GV2M_WRITE);
> if ( page == NULL )
> return len;
>
> p = __map_domain_page(page);
> p += offset;
> -memcpy(p, from, size);
> +memcpy(p, buf, size);
> if ( flags & COPY_flush_dcache )
> clean_dcache_va_range(p, size);
>
> unmap_domain_page(p - offset);
> put_page(page);
> len -= size;
> -from += size;
> -to += size;
> +buf += size;
> +addr += size;
> /*
> * After the first iteration, guest virtual address is correctly
> * aligned to PAGE_SIZE.
> @@ -46,13 +48,13 @@ static unsigned long raw_copy_to_guest_helper(void *to,
> const void *from,
>
> unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len)
> {
> -return raw_copy_to_guest_helper(to, from, len, 0);
> +return copy_guest((void *)from, (vaddr_t)to, len, 0);
> }
>
> unsigned long raw_copy_to_guest_flush_dcache(void *to, const void *from,
> unsigned len)
> {
> -return raw_copy_to_guest_helper(to, from, len, COPY_flush_dcache);
> +return copy_guest((void *)from, (vaddr_t)to, len, COPY_flush_dcache);
> }
>
> unsigned long raw_clear_guest(void *to, unsigned len)
> --
> 2.11.0
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [v2 03/16] xen/arm: Extend copy_to_guest to support copying from guest VA and use it
On Tue, 12 Dec 2017, Julien Grall wrote:
> The only differences between copy_to_guest (formerly called
> raw_copy_to_guest_helper) and raw_copy_from_guest is:
> - The direction of the memcpy
> - The permission use for translating the address
>
> Extend copy_to_guest to support copying from guest VA by adding using a
> bit in the flags to tell the direction of the copy.
>
> Lastly, reimplement raw_copy_from_guest using copy_to_guest.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> Changes in v2:
> - Use vaddr_t
> ---
> xen/arch/arm/guestcopy.c | 46 +-
> 1 file changed, 13 insertions(+), 33 deletions(-)
>
> diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
> index 08d0fa0a83..12fb03dd19 100644
> --- a/xen/arch/arm/guestcopy.c
> +++ b/xen/arch/arm/guestcopy.c
> @@ -6,6 +6,8 @@
> #include
>
> #define COPY_flush_dcache (1U << 0)
> +#define COPY_from_guest (0U << 1)
> +#define COPY_to_guest (1U << 1)
>
> static unsigned long copy_guest(void *buf, uint64_t addr, unsigned int len,
> unsigned int flags)
> @@ -21,13 +23,18 @@ static unsigned long copy_guest(void *buf, uint64_t addr,
> unsigned int len,
> unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
> struct page_info *page;
>
> -page = get_page_from_gva(current, addr, GV2M_WRITE);
> +page = get_page_from_gva(current, addr,
> + (flags & COPY_to_guest) ? GV2M_WRITE :
> GV2M_READ);
> if ( page == NULL )
> return len;
>
> p = __map_domain_page(page);
> p += offset;
> -memcpy(p, buf, size);
> +if ( flags & COPY_to_guest )
> +memcpy(p, buf, size);
> +else
> +memcpy(buf, p, size);
> +
> if ( flags & COPY_flush_dcache )
> clean_dcache_va_range(p, size);
>
> @@ -48,13 +55,14 @@ static unsigned long copy_guest(void *buf, uint64_t addr,
> unsigned int len,
>
> unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len)
> {
> -return copy_guest((void *)from, (vaddr_t)to, len, 0);
> +return copy_guest((void *)from, (vaddr_t)to, len, COPY_to_guest);
> }
>
> unsigned long raw_copy_to_guest_flush_dcache(void *to, const void *from,
> unsigned len)
> {
> -return copy_guest((void *)from, (vaddr_t)to, len, COPY_flush_dcache);
> +return copy_guest((void *)from, (vaddr_t)to, len,
> + COPY_to_guest | COPY_flush_dcache);
> }
>
> unsigned long raw_clear_guest(void *to, unsigned len)
> @@ -92,35 +100,7 @@ unsigned long raw_clear_guest(void *to, unsigned len)
>
> unsigned long raw_copy_from_guest(void *to, const void __user *from,
> unsigned len)
> {
> -unsigned offset = (vaddr_t)from & ~PAGE_MASK;
> -
> -while ( len )
> -{
> -void *p;
> -unsigned size = min(len, (unsigned)(PAGE_SIZE - offset));
> -struct page_info *page;
> -
> -page = get_page_from_gva(current, (vaddr_t) from, GV2M_READ);
> -if ( page == NULL )
> -return len;
> -
> -p = __map_domain_page(page);
> -p += ((vaddr_t)from & (~PAGE_MASK));
> -
> -memcpy(to, p, size);
> -
> -unmap_domain_page(p);
> -put_page(page);
> -len -= size;
> -from += size;
> -to += size;
> -/*
> - * After the first iteration, guest virtual address is correctly
> - * aligned to PAGE_SIZE.
> - */
> -offset = 0;
> -}
> -return 0;
> +return copy_guest(to, (vaddr_t)from, len, COPY_from_guest);
> }
>
> /*
> --
> 2.11.0
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [v2 04/16] xen/arm: Extend copy_to_guest to support zeroing guest VA and use it
On Tue, 12 Dec 2017, Julien Grall wrote:
> The function copy_to_guest can easily be extended to support zeroing
> guest VA. To avoid using a new bit, it is considered that a NULL buffer
> (i.e buf == NULL) means the guest memory will be zeroed.
>
> Lastly, reimplement raw_clear_guest using copy_to_guest.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> Changes in v3:
> - Use vaddr_t
> ---
> xen/arch/arm/guestcopy.c | 41 +++--
> 1 file changed, 11 insertions(+), 30 deletions(-)
>
> diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
> index 12fb03dd19..ff7d15380f 100644
> --- a/xen/arch/arm/guestcopy.c
> +++ b/xen/arch/arm/guestcopy.c
> @@ -31,7 +31,16 @@ static unsigned long copy_guest(void *buf, uint64_t addr,
> unsigned int len,
> p = __map_domain_page(page);
> p += offset;
> if ( flags & COPY_to_guest )
> -memcpy(p, buf, size);
> +{
> +/*
> + * buf will be NULL when the caller request to zero the
> + * guest memory.
> + */
> +if ( buf )
> +memcpy(p, buf, size);
> +else
> +memset(p, 0, size);
> +}
> else
> memcpy(buf, p, size);
>
> @@ -67,35 +76,7 @@ unsigned long raw_copy_to_guest_flush_dcache(void *to,
> const void *from,
>
> unsigned long raw_clear_guest(void *to, unsigned len)
> {
> -/* XXX needs to handle faults */
> -unsigned offset = (vaddr_t)to & ~PAGE_MASK;
> -
> -while ( len )
> -{
> -void *p;
> -unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
> -struct page_info *page;
> -
> -page = get_page_from_gva(current, (vaddr_t) to, GV2M_WRITE);
> -if ( page == NULL )
> -return len;
> -
> -p = __map_domain_page(page);
> -p += offset;
> -memset(p, 0x00, size);
> -
> -unmap_domain_page(p - offset);
> -put_page(page);
> -len -= size;
> -to += size;
> -/*
> - * After the first iteration, guest virtual address is correctly
> - * aligned to PAGE_SIZE.
> - */
> -offset = 0;
> -}
> -
> -return 0;
> +return copy_guest(NULL, (vaddr_t)to, len, COPY_to_guest);
> }
>
> unsigned long raw_copy_from_guest(void *to, const void __user *from,
> unsigned len)
> --
> 2.11.0
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [v2 05/16] xen/arm: guest_copy: Extend the prototype to pass the vCPU
On Tue, 12 Dec 2017, Julien Grall wrote:
> Currently, guest_copy assumes the copy will only be done for the current
> vCPU. copy_guest is meant to be vCPU agnostic, so extend the prototype
> to pass the vCPU.
>
> At the same time, encapsulate the vCPU in an union to allow extension
> for copying from a guest domain (ipa case) in the future.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> Changes in v2:
> - Encapsulate the vCPU in an union.
> - Rework the commit message
> ---
> xen/arch/arm/guestcopy.c | 25 +++--
> 1 file changed, 19 insertions(+), 6 deletions(-)
>
> diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
> index ff7d15380f..7e92e27beb 100644
> --- a/xen/arch/arm/guestcopy.c
> +++ b/xen/arch/arm/guestcopy.c
> @@ -9,8 +9,18 @@
> #define COPY_from_guest (0U << 1)
> #define COPY_to_guest (1U << 1)
>
> +typedef union
> +{
> +struct
> +{
> +struct vcpu *v;
> +} gva;
> +} copy_info_t;
> +
> +#define GVA_INFO(vcpu) ((copy_info_t) { .gva = { vcpu } })
> +
> static unsigned long copy_guest(void *buf, uint64_t addr, unsigned int len,
> -unsigned int flags)
> +copy_info_t info, unsigned int flags)
> {
> /* XXX needs to handle faults */
> unsigned offset = addr & ~PAGE_MASK;
> @@ -23,7 +33,7 @@ static unsigned long copy_guest(void *buf, uint64_t addr,
> unsigned int len,
> unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
> struct page_info *page;
>
> -page = get_page_from_gva(current, addr,
> +page = get_page_from_gva(info.gva.v, addr,
> (flags & COPY_to_guest) ? GV2M_WRITE :
> GV2M_READ);
> if ( page == NULL )
> return len;
> @@ -64,24 +74,27 @@ static unsigned long copy_guest(void *buf, uint64_t addr,
> unsigned int len,
>
> unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len)
> {
> -return copy_guest((void *)from, (vaddr_t)to, len, COPY_to_guest);
> +return copy_guest((void *)from, (vaddr_t)to, len,
> + GVA_INFO(current), COPY_to_guest);
> }
>
> unsigned long raw_copy_to_guest_flush_dcache(void *to, const void *from,
> unsigned len)
> {
> -return copy_guest((void *)from, (vaddr_t)to, len,
> +return copy_guest((void *)from, (vaddr_t)to, len, GVA_INFO(current),
>COPY_to_guest | COPY_flush_dcache);
> }
>
> unsigned long raw_clear_guest(void *to, unsigned len)
> {
> -return copy_guest(NULL, (vaddr_t)to, len, COPY_to_guest);
> +return copy_guest(NULL, (vaddr_t)to, len, GVA_INFO(current),
> + COPY_to_guest);
> }
>
> unsigned long raw_copy_from_guest(void *to, const void __user *from,
> unsigned len)
> {
> -return copy_guest(to, (vaddr_t)from, len, COPY_from_guest);
> +return copy_guest(to, (vaddr_t)from, len, GVA_INFO(current),
> + COPY_from_guest);
> }
>
> /*
> --
> 2.11.0
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [v2 06/16] xen/arm: Extend copy_to_guest to support copying from/to guest physical address
On Tue, 12 Dec 2017, Julien Grall wrote:
> The only differences between copy_to_guest and access_guest_memory_by_ipa are:
> - The latter does not support copying data crossing page boundary
> - The former is copying from/to guest VA whilst the latter from
> guest PA
>
> copy_to_guest can easily be extended to support copying from/to guest
> physical address. For that a new bit is used to tell whether linear
> address or ipa is been used.
>
> Lastly access_guest_memory_by_ipa is reimplemented using copy_to_guest.
> This also has the benefits to extend the use of it, it is now possible
> to copy data crossing page boundary.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> Changes in v2:
> - Rework the patch after the interface changes in the previous
> patch.
> - Use uint64_t rather than paddr_t in translate_get_page
> - Add a BUILD_BUG_ON to check whether paddr_t fits in uint64_t
> ---
> xen/arch/arm/guestcopy.c | 91
> +++-
> 1 file changed, 44 insertions(+), 47 deletions(-)
>
> diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
> index 7e92e27beb..93e4aa2d3f 100644
> --- a/xen/arch/arm/guestcopy.c
> +++ b/xen/arch/arm/guestcopy.c
> @@ -8,6 +8,8 @@
> #define COPY_flush_dcache (1U << 0)
> #define COPY_from_guest (0U << 1)
> #define COPY_to_guest (1U << 1)
> +#define COPY_ipa(0U << 2)
> +#define COPY_linear (1U << 2)
>
> typedef union
> {
> @@ -15,9 +17,39 @@ typedef union
> {
> struct vcpu *v;
> } gva;
> +
> +struct
> +{
> +struct domain *d;
> +} gpa;
> } copy_info_t;
>
> #define GVA_INFO(vcpu) ((copy_info_t) { .gva = { vcpu } })
> +#define GPA_INFO(domain) ((copy_info_t) { .gpa = { domain } })
> +
> +static struct page_info *translate_get_page(copy_info_t info, uint64_t addr,
> +bool linear, bool write)
> +{
> +p2m_type_t p2mt;
> +struct page_info *page;
> +
> +if ( linear )
> +return get_page_from_gva(info.gva.v, addr,
> + write ? GV2M_WRITE : GV2M_READ);
> +
> +page = get_page_from_gfn(info.gpa.d, paddr_to_pfn(addr), &p2mt,
> P2M_ALLOC);
> +
> +if ( !page )
> +return NULL;
> +
> +if ( !p2m_is_ram(p2mt) )
> +{
> +put_page(page);
> +return NULL;
> +}
> +
> +return page;
> +}
>
> static unsigned long copy_guest(void *buf, uint64_t addr, unsigned int len,
> copy_info_t info, unsigned int flags)
> @@ -26,6 +58,7 @@ static unsigned long copy_guest(void *buf, uint64_t addr,
> unsigned int len,
> unsigned offset = addr & ~PAGE_MASK;
>
> BUILD_BUG_ON((sizeof(addr)) < sizeof(vaddr_t));
> +BUILD_BUG_ON((sizeof(addr)) < sizeof(paddr_t));
>
> while ( len )
> {
> @@ -33,8 +66,8 @@ static unsigned long copy_guest(void *buf, uint64_t addr,
> unsigned int len,
> unsigned size = min(len, (unsigned)PAGE_SIZE - offset);
> struct page_info *page;
>
> -page = get_page_from_gva(info.gva.v, addr,
> - (flags & COPY_to_guest) ? GV2M_WRITE :
> GV2M_READ);
> +page = translate_get_page(info, addr, flags & COPY_linear,
> + flags & COPY_to_guest);
> if ( page == NULL )
> return len;
>
> @@ -75,75 +108,39 @@ static unsigned long copy_guest(void *buf, uint64_t
> addr, unsigned int len,
> unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len)
> {
> return copy_guest((void *)from, (vaddr_t)to, len,
> - GVA_INFO(current), COPY_to_guest);
> + GVA_INFO(current), COPY_to_guest | COPY_linear);
> }
>
> unsigned long raw_copy_to_guest_flush_dcache(void *to, const void *from,
> unsigned len)
> {
> return copy_guest((void *)from, (vaddr_t)to, len, GVA_INFO(current),
> - COPY_to_guest | COPY_flush_dcache);
> + COPY_to_guest | COPY_flush_dcache | COPY_linear);
> }
>
> unsigned long raw_clear_guest(void *to, unsigned len)
> {
> return copy_guest(NULL, (vaddr_t)to, len, GVA_INFO(current),
> - COPY_to_guest);
> + COPY_to_guest | COPY_linear);
> }
>
> unsigned long raw_copy_from_guest(void *to, const void __user *from,
> unsigned len)
> {
> re
Re: [Xen-devel] [v2 07/16] xen/arm: Introduce copy_to_guest_phys_flush_dcache
On Tue, 12 Dec 2017, Julien Grall wrote:
> This new function will be used in a follow-up patch to copy data to the guest
> using the IPA (aka guest physical address) and then clean the cache.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> Changes in v2:
> - Use the new interface
> ---
> xen/arch/arm/guestcopy.c | 9 +
> xen/include/asm-arm/guest_access.h | 6 ++
> 2 files changed, 15 insertions(+)
>
> diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
> index 93e4aa2d3f..7a0f3e9d5f 100644
> --- a/xen/arch/arm/guestcopy.c
> +++ b/xen/arch/arm/guestcopy.c
> @@ -130,6 +130,15 @@ unsigned long raw_copy_from_guest(void *to, const void
> __user *from, unsigned le
>COPY_from_guest | COPY_linear);
> }
>
> +unsigned long copy_to_guest_phys_flush_dcache(struct domain *d,
> + paddr_t gpa,
> + void *buf,
> + unsigned int len)
> +{
> +return copy_guest(buf, gpa, len, GPA_INFO(d),
> + COPY_to_guest | COPY_ipa | COPY_flush_dcache);
> +}
> +
> int access_guest_memory_by_ipa(struct domain *d, paddr_t gpa, void *buf,
> uint32_t size, bool is_write)
> {
> diff --git a/xen/include/asm-arm/guest_access.h
> b/xen/include/asm-arm/guest_access.h
> index 6796801cfe..224d2a033b 100644
> --- a/xen/include/asm-arm/guest_access.h
> +++ b/xen/include/asm-arm/guest_access.h
> @@ -11,6 +11,12 @@ unsigned long raw_copy_to_guest_flush_dcache(void *to,
> const void *from,
> unsigned long raw_copy_from_guest(void *to, const void *from, unsigned len);
> unsigned long raw_clear_guest(void *to, unsigned len);
>
> +/* Copy data to guest physical address, then clean the region. */
> +unsigned long copy_to_guest_phys_flush_dcache(struct domain *d,
> + paddr_t phys,
> + void *buf,
> + unsigned int len);
> +
> int access_guest_memory_by_ipa(struct domain *d, paddr_t ipa, void *buf,
> uint32_t size, bool is_write);
>
> --
> 2.11.0
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [v2 16/16] xen/arm: traps: Merge do_trap_instr_abort_guest and do_trap_data_abort_guest
On Tue, 12 Dec 2017, Julien Grall wrote:
> The two helpers do_trap_instr_abort_guest and do_trap_data_abort_guest
> are used trap stage-2 abort. While the former is only handling prefetch
> abort and the latter data abort, they are very similarly and does not
> warrant to have separate helpers.
>
> For instance, merging the both will make easier to maintain stage-2 abort
> handling. So consolidate the two helpers in a new helper
> do_trap_stage2_abort.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> Changes in v2
> - Fix the way to compute npfec.write_access
> ---
> xen/arch/arm/traps.c | 133
> ---
> 1 file changed, 41 insertions(+), 92 deletions(-)
>
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 082396c26d..013c1600ec 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -1861,79 +1861,6 @@ static inline bool hpfar_is_valid(bool s1ptw, uint8_t
> fsc)
> return s1ptw || (fsc == FSC_FLT_TRANS && !check_workaround_834220());
> }
>
> -static void do_trap_instr_abort_guest(struct cpu_user_regs *regs,
> - const union hsr hsr)
> -{
> -int rc;
> -register_t gva;
> -uint8_t fsc = hsr.iabt.ifsc & ~FSC_LL_MASK;
> -paddr_t gpa;
> -mfn_t mfn;
> -
> -gva = get_hfar(false /* is_data */);
> -
> -/*
> - * If this bit has been set, it means that this instruction abort is
> caused
> - * by a guest external abort. We can handle this instruction abort as
> guest
> - * SError.
> - */
> -if ( hsr.iabt.eat )
> -return __do_trap_serror(regs, true);
> -
> -
> -if ( hpfar_is_valid(hsr.iabt.s1ptw, fsc) )
> -gpa = get_faulting_ipa(gva);
> -else
> -{
> -/*
> - * Flush the TLB to make sure the DTLB is clear before
> - * doing GVA->IPA translation. If we got here because of
> - * an entry only present in the ITLB, this translation may
> - * still be inaccurate.
> - */
> -flush_tlb_local();
> -
> -/*
> - * We may not be able to translate because someone is
> - * playing with the Stage-2 page table of the domain.
> - * Return to the guest.
> - */
> -rc = gva_to_ipa(gva, &gpa, GV2M_READ);
> -if ( rc == -EFAULT )
> -return; /* Try again */
> -}
> -
> -switch ( fsc )
> -{
> -case FSC_FLT_PERM:
> -{
> -const struct npfec npfec = {
> -.insn_fetch = 1,
> -.gla_valid = 1,
> -.kind = hsr.iabt.s1ptw ? npfec_kind_in_gpt : npfec_kind_with_gla
> -};
> -
> -p2m_mem_access_check(gpa, gva, npfec);
> -/*
> - * The only way to get here right now is because of mem_access,
> - * thus reinjecting the exception to the guest is never required.
> - */
> -return;
> -}
> -case FSC_FLT_TRANS:
> -/*
> - * The PT walk may have failed because someone was playing
> - * with the Stage-2 page table. Walk the Stage-2 PT to check
> - * if the entry exists. If it's the case, return to the guest
> - */
> -mfn = gfn_to_mfn(current->domain, _gfn(paddr_to_pfn(gpa)));
> -if ( !mfn_eq(mfn, INVALID_MFN) )
> -return;
> -}
> -
> -inject_iabt_exception(regs, gva, hsr.len);
> -}
> -
> static bool try_handle_mmio(struct cpu_user_regs *regs,
> const union hsr hsr,
> paddr_t gpa)
> @@ -1945,6 +1872,8 @@ static bool try_handle_mmio(struct cpu_user_regs *regs,
> };
> int rc;
>
> +ASSERT(hsr.ec == HSR_EC_DATA_ABORT_LOWER_EL);
> +
> /* stage-1 page table should never live in an emulated MMIO region */
> if ( dabt.s1ptw )
> return false;
> @@ -2000,29 +1929,43 @@ static bool try_map_mmio(gfn_t gfn)
> return !map_regions_p2mt(d, gfn, 1, mfn, p2m_mmio_direct_c);
> }
>
> -static void do_trap_data_abort_guest(struct cpu_user_regs *regs,
> - const union hsr hsr)
> +static void do_trap_stage2_abort_guest(struct cpu_user_regs *regs,
> + const union hsr hsr)
> {
> -const struct hsr_dabt dabt = hsr.dabt;
> +/*
> + * The encoding of hsr_iabt is a subset of hsr_dabt. So use
> + * hsr_dabt to represent an abort fault.
> + */
> +const struct hsr_xabt xabt = hsr.xabt;
> int rc;
> vaddr_t gva;
> paddr_t
Re: [Xen-devel] [PATCH] xen/efi: Fix build with clang-5.0
On Wed, 13 Dec 2017, Andrew Cooper wrote:
> The clang-5.0 build is reliably failing with:
>
> Error: size of boot.o:.text is 0x01
>
> which is because efi_arch_flush_dcache_area() exists as a single ret
> instruction. Mark it as __init like everything else in the files.
>
> Spotted by Travis.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Stefano Stabellini
> ---
> CC: Jan Beulich
> CC: Stefano Stabellini
> CC: Julien Grall
>
> For future discussion, Why are these implementations not inline? Why are we
> being special and allowing a header file and define functions and globals like
> this?
> ---
> xen/arch/arm/efi/efi-boot.h | 2 +-
> xen/arch/x86/efi/efi-boot.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
> index 56de26e..ca655ff 100644
> --- a/xen/arch/arm/efi/efi-boot.h
> +++ b/xen/arch/arm/efi/efi-boot.h
> @@ -597,7 +597,7 @@ static void __init
> efi_arch_video_init(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
> {
> }
>
> -static void efi_arch_flush_dcache_area(const void *vaddr, UINTN size)
> +static void __init efi_arch_flush_dcache_area(const void *vaddr, UINTN size)
> {
> __flush_dcache_area(vaddr, size);
> }
> diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
> index 8d295ff..d30f688 100644
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -668,7 +668,7 @@ static bool __init
> efi_arch_use_config_file(EFI_SYSTEM_TABLE *SystemTable)
> return true; /* x86 always uses a config file */
> }
>
> -static void efi_arch_flush_dcache_area(const void *vaddr, UINTN size) { }
> +static void __init efi_arch_flush_dcache_area(const void *vaddr, UINTN size)
> { }
>
> void __init efi_multiboot2(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE
> *SystemTable)
> {
> --
> 2.1.4
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL 3/6] xenfb: Use Input Handlers directly
From: Owen Smith
Avoid the unneccessary calls through the input-legacy.c file by
using the qemu_input_handler_*() calls directly. This did require
reworking the event and sync handlers to use the reverse mapping
from qcode to linux using qemu_input_qcode_to_linux().
Removes the scancode2linux mapping, and supporting documention.
Signed-off-by: Owen Smith
Reviewed-by: Gerd Hoffmann
Reviewed-by: Stefano Stabellini
Signed-off-by: Stefano Stabellini
---
hw/display/xenfb.c | 274 ++---
1 file changed, 137 insertions(+), 137 deletions(-)
diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
index 8e2547a..ed06efa 100644
--- a/hw/display/xenfb.c
+++ b/hw/display/xenfb.c
@@ -27,6 +27,7 @@
#include "qemu/osdep.h"
#include "hw/hw.h"
+#include "ui/input.h"
#include "ui/console.h"
#include "hw/xen/xen_backend.h"
@@ -51,9 +52,10 @@ struct common {
struct XenInput {
struct common c;
int abs_pointer_wanted; /* Whether guest supports absolute pointer */
-int button_state; /* Last seen pointer button state */
-int extended;
-QEMUPutMouseEntry *qmouse;
+QemuInputHandlerState *qkbd;
+QemuInputHandlerState *qmou;
+int axis[INPUT_AXIS__MAX];
+int wheel;
};
#define UP_QUEUE 8
@@ -119,79 +121,6 @@ static void common_unbind(struct common *c)
}
/* */
-
-#if 0
-/*
- * These two tables are not needed any more, but left in here
- * intentionally as documentation, to show how scancode2linux[]
- * was generated.
- *
- * Tables to map from scancode to Linux input layer keycode.
- * Scancodes are hardware-specific. These maps assumes a
- * standard AT or PS/2 keyboard which is what QEMU feeds us.
- */
-const unsigned char atkbd_set2_keycode[512] = {
-
- 0, 67, 65, 63, 61, 59, 60, 88, 0, 68, 66, 64, 62, 15, 41,117,
- 0, 56, 42, 93, 29, 16, 2, 0, 0, 0, 44, 31, 30, 17, 3, 0,
- 0, 46, 45, 32, 18, 5, 4, 95, 0, 57, 47, 33, 20, 19, 6,183,
- 0, 49, 48, 35, 34, 21, 7,184, 0, 0, 50, 36, 22, 8, 9,185,
- 0, 51, 37, 23, 24, 11, 10, 0, 0, 52, 53, 38, 39, 25, 12, 0,
- 0, 89, 40, 0, 26, 13, 0, 0, 58, 54, 28, 27, 0, 43, 0, 85,
- 0, 86, 91, 90, 92, 0, 14, 94, 0, 79,124, 75, 71,121, 0, 0,
-82, 83, 80, 76, 77, 72, 1, 69, 87, 78, 81, 74, 55, 73, 70, 99,
-
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-217,100,255, 0, 97,165, 0, 0,156, 0, 0, 0, 0, 0, 0,125,
-173,114, 0,113, 0, 0, 0,126,128, 0, 0,140, 0, 0, 0,127,
-159, 0,115, 0,164, 0, 0,116,158, 0,150,166, 0, 0, 0,142,
-157, 0, 0, 0, 0, 0, 0, 0,155, 0, 98, 0, 0,163, 0, 0,
-226, 0, 0, 0, 0, 0, 0, 0, 0,255, 96, 0, 0, 0,143, 0,
- 0, 0, 0, 0, 0, 0, 0, 0, 0,107, 0,105,102, 0, 0,112,
-110,111,108,112,106,103, 0,119, 0,118,109, 0, 99,104,119, 0,
-
-};
-
-const unsigned char atkbd_unxlate_table[128] = {
-
- 0,118, 22, 30, 38, 37, 46, 54, 61, 62, 70, 69, 78, 85,102, 13,
- 21, 29, 36, 45, 44, 53, 60, 67, 68, 77, 84, 91, 90, 20, 28, 27,
- 35, 43, 52, 51, 59, 66, 75, 76, 82, 14, 18, 93, 26, 34, 33, 42,
- 50, 49, 58, 65, 73, 74, 89,124, 17, 41, 88, 5, 6, 4, 12, 3,
- 11, 2, 10, 1, 9,119,126,108,117,125,123,107,115,116,121,105,
-114,122,112,113,127, 96, 97,120, 7, 15, 23, 31, 39, 47, 55, 63,
- 71, 79, 86, 94, 8, 16, 24, 32, 40, 48, 56, 64, 72, 80, 87,111,
- 19, 25, 57, 81, 83, 92, 95, 98, 99,100,101,103,104,106,109,110
-
-};
-#endif
-
-/*
- * for (i = 0; i < 128; i++) {
- * scancode2linux[i] = atkbd_set2_keycode[atkbd_unxlate_table[i]];
- * scancode2linux[i | 0x80] = atkbd_set2_keycode[atkbd_unxlate_table[i] |
0x80];
- * }
- */
-static const unsigned char scancode2linux[512] = {
- 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
- 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31,
- 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47,
- 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63,
- 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79,
- 80, 81, 82, 83, 99, 0, 86, 87, 88,117, 0, 0, 95,183,184,185,
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 93, 0, 0, 89, 0, 0, 85, 91, 90, 92, 0, 94, 0,124,121, 0,
-
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-165, 0, 0, 0, 0, 0, 0, 0, 0,163, 0, 0, 96, 97, 0, 0,
-113,140,164, 0,166, 0, 0, 0, 0, 0,255, 0, 0, 0,114, 0,
-115, 0,150, 0, 0, 98,255, 99,100, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0,119,119,102,103,104, 0,105,112,106,118,107,
-108,109,110,111, 0, 0, 0, 0, 0, 0, 0,125,126,127,116,142,
- 0, 0, 0,143, 0,217,156,173,128,159,158,157,155,226, 0,112,
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
[Xen-devel] [PULL 1/6] xen-disk: use an IOThread per instance
From: Paul Durrant
This patch allocates an IOThread object for each xen_disk instance and
sets the AIO context appropriately on connect. This allows processing
of I/O to proceed in parallel.
The patch also adds tracepoints into xen_disk to make it possible to
follow the state transtions of an instance in the log.
Signed-off-by: Paul Durrant
Acked-by: Stefano Stabellini
Signed-off-by: Stefano Stabellini
---
hw/block/trace-events | 7 +++
hw/block/xen_disk.c | 53 ---
2 files changed, 53 insertions(+), 7 deletions(-)
diff --git a/hw/block/trace-events b/hw/block/trace-events
index cb6767b..962a3bf 100644
--- a/hw/block/trace-events
+++ b/hw/block/trace-events
@@ -10,3 +10,10 @@ virtio_blk_submit_multireq(void *vdev, void *mrb, int start,
int num_reqs, uint6
# hw/block/hd-geometry.c
hd_geometry_lchs_guess(void *blk, int cyls, int heads, int secs) "blk %p LCHS
%d %d %d"
hd_geometry_guess(void *blk, uint32_t cyls, uint32_t heads, uint32_t secs, int
trans) "blk %p CHS %u %u %u trans %d"
+
+# hw/block/xen_disk.c
+xen_disk_alloc(char *name) "%s"
+xen_disk_init(char *name) "%s"
+xen_disk_connect(char *name) "%s"
+xen_disk_disconnect(char *name) "%s"
+xen_disk_free(char *name) "%s"
diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index e431bd8..f74fcd4 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -27,10 +27,12 @@
#include "hw/xen/xen_backend.h"
#include "xen_blkif.h"
#include "sysemu/blockdev.h"
+#include "sysemu/iothread.h"
#include "sysemu/block-backend.h"
#include "qapi/error.h"
#include "qapi/qmp/qdict.h"
#include "qapi/qmp/qstring.h"
+#include "trace.h"
/* - */
@@ -125,6 +127,9 @@ struct XenBlkDev {
DriveInfo *dinfo;
BlockBackend*blk;
QEMUBH *bh;
+
+IOThread*iothread;
+AioContext *ctx;
};
/* - */
@@ -596,9 +601,12 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq);
static void qemu_aio_complete(void *opaque, int ret)
{
struct ioreq *ioreq = opaque;
+struct XenBlkDev *blkdev = ioreq->blkdev;
+
+aio_context_acquire(blkdev->ctx);
if (ret != 0) {
-xen_pv_printf(&ioreq->blkdev->xendev, 0, "%s I/O error\n",
+xen_pv_printf(&blkdev->xendev, 0, "%s I/O error\n",
ioreq->req.operation == BLKIF_OP_READ ? "read" :
"write");
ioreq->aio_errors++;
}
@@ -607,10 +615,10 @@ static void qemu_aio_complete(void *opaque, int ret)
if (ioreq->presync) {
ioreq->presync = 0;
ioreq_runio_qemu_aio(ioreq);
-return;
+goto done;
}
if (ioreq->aio_inflight > 0) {
-return;
+goto done;
}
if (xen_feature_grant_copy) {
@@ -647,16 +655,19 @@ static void qemu_aio_complete(void *opaque, int ret)
}
case BLKIF_OP_READ:
if (ioreq->status == BLKIF_RSP_OKAY) {
-block_acct_done(blk_get_stats(ioreq->blkdev->blk), &ioreq->acct);
+block_acct_done(blk_get_stats(blkdev->blk), &ioreq->acct);
} else {
-block_acct_failed(blk_get_stats(ioreq->blkdev->blk), &ioreq->acct);
+block_acct_failed(blk_get_stats(blkdev->blk), &ioreq->acct);
}
break;
case BLKIF_OP_DISCARD:
default:
break;
}
-qemu_bh_schedule(ioreq->blkdev->bh);
+qemu_bh_schedule(blkdev->bh);
+
+done:
+aio_context_release(blkdev->ctx);
}
static bool blk_split_discard(struct ioreq *ioreq, blkif_sector_t
sector_number,
@@ -913,17 +924,29 @@ static void blk_handle_requests(struct XenBlkDev *blkdev)
static void blk_bh(void *opaque)
{
struct XenBlkDev *blkdev = opaque;
+
+aio_context_acquire(blkdev->ctx);
blk_handle_requests(blkdev);
+aio_context_release(blkdev->ctx);
}
static void blk_alloc(struct XenDevice *xendev)
{
struct XenBlkDev *blkdev = container_of(xendev, struct XenBlkDev, xendev);
+Error *err = NULL;
+
+trace_xen_disk_alloc(xendev->name);
QLIST_INIT(&blkdev->inflight);
QLIST_INIT(&blkdev->finished);
QLIST_INIT(&blkdev->freelist);
-blkdev->bh = qemu_bh_new(blk_bh, blkdev);
+
+blkdev->iothread = iothread_create(xendev->name, &err);
+assert(!err);
+
+blkdev->ctx = iothread_get_aio_context(blkdev->iothread);
+blkdev->bh = aio_bh_new(blkdev->ctx, blk_bh, blkdev);
+
if (xen_mode != XEN_EMULATE) {
batch_maps = 1;
}
@@ -950,6 +973,8 @@ static int blk_init(struct XenDevi
[Xen-devel] [PULL 4/6] xenfb: Add [feature|request]-raw-pointer
From: Owen Smith
Writes "feature-raw-pointer" during init to indicate the backend
can pass raw unscaled values for absolute axes to the frontend.
Frontends set "request-raw-pointer" to indicate the backend should
not attempt to scale absolute values to console size.
"request-raw-pointer" is only valid if "request-abs-pointer" is
also set. Raw unscaled pointer values are in the range [0, 0x7fff]
"feature-raw-pointer" and "request-raw-pointer" added to Xen
header in commit 7868654ff7fe5e4a2eeae2b277644fa884a5031e
Signed-off-by: Owen Smith
Reviewed-by: Gerd Hoffmann
Reviewed-by: Stefano Stabellini
Signed-off-by: Stefano Stabellini
---
hw/display/xenfb.c | 47 ++-
1 file changed, 30 insertions(+), 17 deletions(-)
diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
index ed06efa..776a2ce 100644
--- a/hw/display/xenfb.c
+++ b/hw/display/xenfb.c
@@ -52,6 +52,7 @@ struct common {
struct XenInput {
struct common c;
int abs_pointer_wanted; /* Whether guest supports absolute pointer */
+int raw_pointer_wanted; /* Whether guest supports raw (unscaled) pointer */
QemuInputHandlerState *qkbd;
QemuInputHandlerState *qmou;
int axis[INPUT_AXIS__MAX];
@@ -264,24 +265,28 @@ static void xenfb_mouse_event(DeviceState *dev,
QemuConsole *src,
case INPUT_EVENT_KIND_ABS:
move = evt->u.abs.data;
-con = qemu_console_lookup_by_index(0);
-if (!con) {
-xen_pv_printf(&xenfb->c.xendev, 0, "No QEMU console available");
-return;
-}
-surface = qemu_console_surface(con);
-switch (move->axis) {
-case INPUT_AXIS_X:
-scale = surface_width(surface) - 1;
-break;
-case INPUT_AXIS_Y:
-scale = surface_height(surface) - 1;
-break;
-default:
-scale = 0x8000;
-break;
+if (xenfb->raw_pointer_wanted) {
+xenfb->axis[move->axis] = move->value;
+} else {
+con = qemu_console_lookup_by_index(0);
+if (!con) {
+xen_pv_printf(&xenfb->c.xendev, 0, "No QEMU console
available");
+return;
+}
+surface = qemu_console_surface(con);
+switch (move->axis) {
+case INPUT_AXIS_X:
+scale = surface_width(surface) - 1;
+break;
+case INPUT_AXIS_Y:
+scale = surface_height(surface) - 1;
+break;
+default:
+scale = 0x8000;
+break;
+}
+xenfb->axis[move->axis] = move->value * scale / 0x7fff;
}
-xenfb->axis[move->axis] = move->value * scale / 0x7fff;
break;
case INPUT_EVENT_KIND_REL:
@@ -339,6 +344,7 @@ static QemuInputHandler xenfb_rel_mouse = {
static int input_init(struct XenDevice *xendev)
{
xenstore_write_be_int(xendev, "feature-abs-pointer", 1);
+xenstore_write_be_int(xendev, "feature-raw-pointer", 1);
return 0;
}
@@ -362,6 +368,13 @@ static void input_connected(struct XenDevice *xendev)
&in->abs_pointer_wanted) == -1) {
in->abs_pointer_wanted = 0;
}
+if (xenstore_read_fe_int(xendev, "request-raw-pointer",
+ &in->raw_pointer_wanted) == -1) {
+in->raw_pointer_wanted = 0;
+}
+if (in->raw_pointer_wanted && in->abs_pointer_wanted == 0) {
+xen_pv_printf(xendev, 0, "raw pointer set without abs pointer");
+}
if (in->qkbd) {
qemu_input_handler_unregister(in->qkbd);
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL 2/6] ui: generate qcode to linux mappings
From: Owen Smith
Use keycodedb to generate a qcode to linux mapping
Signed-off-by: Owen Smith
Reviewed-by: Gerd Hoffmann
Signed-off-by: Stefano Stabellini
---
Makefile | 1 +
include/ui/input.h | 3 +++
ui/input-keymap.c | 1 +
3 files changed, 5 insertions(+)
diff --git a/Makefile b/Makefile
index ab0354c..0331c18 100644
--- a/Makefile
+++ b/Makefile
@@ -229,6 +229,7 @@ KEYCODEMAP_FILES = \
ui/input-keymap-linux-to-qcode.c \
ui/input-keymap-qcode-to-qnum.c \
ui/input-keymap-qnum-to-qcode.c \
+ui/input-keymap-qcode-to-linux.c \
$(NULL)
GENERATED_FILES += $(KEYCODEMAP_FILES)
diff --git a/include/ui/input.h b/include/ui/input.h
index f8cee43..5cc76d6 100644
--- a/include/ui/input.h
+++ b/include/ui/input.h
@@ -77,4 +77,7 @@ extern const guint16 qemu_input_map_qcode_to_qnum[];
extern const guint qemu_input_map_qnum_to_qcode_len;
extern const guint16 qemu_input_map_qnum_to_qcode[];
+extern const guint qemu_input_map_qcode_to_linux_len;
+extern const guint16 qemu_input_map_qcode_to_linux[];
+
#endif /* INPUT_H */
diff --git a/ui/input-keymap.c b/ui/input-keymap.c
index 3a19a16..663986a 100644
--- a/ui/input-keymap.c
+++ b/ui/input-keymap.c
@@ -8,6 +8,7 @@
#include "ui/input-keymap-linux-to-qcode.c"
#include "ui/input-keymap-qcode-to-qnum.c"
#include "ui/input-keymap-qnum-to-qcode.c"
+#include "ui/input-keymap-qcode-to-linux.c"
int qemu_input_linux_to_qcode(unsigned int lnx)
{
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL 0/6] xen-20171214-tag
The following changes since commit 0a0dc59d27527b78a195c2d838d28b7b49e5a639: Update version for v2.11.0 release (2017-12-13 14:31:09 +) are available in the git repository at: git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20171214-tag for you to fetch changes up to 2e63eb2becc228232f12a1ea30a91b2aa8c5cecd: xen/pt: Set is_express to avoid out-of-bounds write (2017-12-14 16:11:53 -0800) Xen 2017/12/14 Owen Smith (4): ui: generate qcode to linux mappings xenfb: Use Input Handlers directly xenfb: Add [feature|request]-raw-pointer xenfb: activate input handlers for raw pointer devices Paul Durrant (1): xen-disk: use an IOThread per instance Simon Gaiser (1): xen/pt: Set is_express to avoid out-of-bounds write Makefile | 1 + hw/block/trace-events | 7 ++ hw/block/xen_disk.c | 53 +++-- hw/display/xenfb.c| 294 ++ hw/xen/xen_pt.c | 1 + include/ui/input.h| 3 + ui/input-keymap.c | 1 + 7 files changed, 215 insertions(+), 145 deletions(-) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL 6/6] xen/pt: Set is_express to avoid out-of-bounds write
From: Simon Gaiser The passed-through device might be an express device. In this case the old code allocated a too small emulated config space in pci_config_alloc() since pci_config_size() returned the size for a non-express device. This leads to an out-of-bound write in xen_pt_config_reg_init(), which sometimes results in crashes. So set is_express as already done for KVM in vfio-pci. Shortened ASan report: ==17512==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61141648 at pc 0x55e0fdac51ff bp 0x7ffe4af07410 sp 0x7ffe4af07408 WRITE of size 2 at 0x61141648 thread T0 #0 0x55e0fdac51fe in memcpy /usr/include/x86_64-linux-gnu/bits/string3.h:53 #1 0x55e0fdac51fe in stw_he_p include/qemu/bswap.h:330 #2 0x55e0fdac51fe in stw_le_p include/qemu/bswap.h:379 #3 0x55e0fdac51fe in pci_set_word include/hw/pci/pci.h:490 #4 0x55e0fdac51fe in xen_pt_config_reg_init hw/xen/xen_pt_config_init.c:1991 #5 0x55e0fdac51fe in xen_pt_config_init hw/xen/xen_pt_config_init.c:2067 #6 0x55e0fdabcf4d in xen_pt_realize hw/xen/xen_pt.c:830 #7 0x55e0fdf59666 in pci_qdev_realize hw/pci/pci.c:2034 #8 0x55e0fdda7d3d in device_set_realized hw/core/qdev.c:914 [...] 0x61141648 is located 8 bytes to the right of 256-byte region [0x61141540,0x61141640) allocated by thread T0 here: #0 0x7ff596a94bb8 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xd9bb8) #1 0x7ff57da66580 in g_malloc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x50580) #2 0x55e0fdda7d3d in device_set_realized hw/core/qdev.c:914 [...] Signed-off-by: Simon Gaiser Acked-by: Stefano Stabellini Signed-off-by: Stefano Stabellini --- hw/xen/xen_pt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c index 9bba717..d57c6d3 100644 --- a/hw/xen/xen_pt.c +++ b/hw/xen/xen_pt.c @@ -946,6 +946,7 @@ static void xen_pci_passthrough_class_init(ObjectClass *klass, void *data) k->exit = xen_pt_unregister_device; k->config_read = xen_pt_pci_read_config; k->config_write = xen_pt_pci_write_config; +k->is_express = 1; /* We might be */ set_bit(DEVICE_CATEGORY_MISC, dc->categories); dc->desc = "Assign an host PCI device with Xen"; dc->props = xen_pci_passthrough_properties; -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL 5/6] xenfb: activate input handlers for raw pointer devices
From: Owen Smith
If the frontend requests raw pointers, the input handlers must be
activated to have the input events delivered to the xenfb backend.
Without activation, the input events are delivered to handlers
registered earlier, which would be the emulated USB tablet or
emulated PS/2 mouse.
HVM xen_kbdfront can incorrectly scale absolute coordinates when
the display resolution is not 800x600.
Signed-off-by: Owen Smith
Reviewed-by: Gerd Hoffmann
Reviewed-by: Stefano Stabellini
Signed-off-by: Stefano Stabellini
---
hw/display/xenfb.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
index 776a2ce..d4fc0fa 100644
--- a/hw/display/xenfb.c
+++ b/hw/display/xenfb.c
@@ -387,6 +387,11 @@ static void input_connected(struct XenDevice *xendev)
in->qkbd = qemu_input_handler_register((DeviceState *)in, &xenfb_keyboard);
in->qmou = qemu_input_handler_register((DeviceState *)in,
in->abs_pointer_wanted ? &xenfb_abs_mouse : &xenfb_rel_mouse);
+
+if (in->raw_pointer_wanted) {
+qemu_input_handler_activate(in->qkbd);
+qemu_input_handler_activate(in->qmou);
+}
}
static void input_disconnect(struct XenDevice *xendev)
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V2] arm: xen: mm: use __GPF_DMA32 for arm64
+ Juergen, Boris On Fri, 30 Aug 2019, Christoph Hellwig wrote: > Can we take a step back and figure out what we want to do here? > > AFAICS this function allocates memory for the swiotlb-xen buffer, > and that means it must be <= 32-bit addressable to satisfy the DMA API > guarantees. That means we generally want to use GFP_DMA32 everywhere > that exists, but on systems with odd zones we might want to dip into > GFP_DMA. This also means swiotlb-xen doesn't actually do the right > thing on x86 at the moment. So shouldn't we just have one common > routine in swiotlb-xen.c that checks if we have CONFIG_ZONE_DMA32 > set, then try GFP_DMA32, and if not check if CONFIG_ZONE_DMA is set > and then try that, else default to GFP_KERNEL? Yes, for ARM/ARM64 it makes a lot of sense given that dom0 is 1:1 mapped (pseudo-physical == physical). I'll let Juergen and Boris comment on the x86 side of things, but on x86 PV Dom0 is not 1:1 mapped so GFP_DMA32 is probably not meaningful. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 02/11] xen/arm: consolidate page-coherent.h
On Thu, 5 Sep 2019, Christoph Hellwig wrote:
> Shared the duplicate arm/arm64 code in include/xen/arm/page-coherent.h.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Stefano Stabellini
> ---
> arch/arm/include/asm/xen/page-coherent.h | 75
> arch/arm64/include/asm/xen/page-coherent.h | 75
> include/xen/arm/page-coherent.h| 80 ++
> 3 files changed, 80 insertions(+), 150 deletions(-)
>
> diff --git a/arch/arm/include/asm/xen/page-coherent.h
> b/arch/arm/include/asm/xen/page-coherent.h
> index 602ac02f154c..27e984977402 100644
> --- a/arch/arm/include/asm/xen/page-coherent.h
> +++ b/arch/arm/include/asm/xen/page-coherent.h
> @@ -1,77 +1,2 @@
> /* SPDX-License-Identifier: GPL-2.0 */
> -#ifndef _ASM_ARM_XEN_PAGE_COHERENT_H
> -#define _ASM_ARM_XEN_PAGE_COHERENT_H
> -
> -#include
> -#include
> #include
> -
> -static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t
> size,
> - dma_addr_t *dma_handle, gfp_t flags, unsigned long attrs)
> -{
> - return dma_direct_alloc(hwdev, size, dma_handle, flags, attrs);
> -}
> -
> -static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
> - void *cpu_addr, dma_addr_t dma_handle, unsigned long attrs)
> -{
> - dma_direct_free(hwdev, size, cpu_addr, dma_handle, attrs);
> -}
> -
> -static inline void xen_dma_sync_single_for_cpu(struct device *hwdev,
> - dma_addr_t handle, size_t size, enum dma_data_direction dir)
> -{
> - unsigned long pfn = PFN_DOWN(handle);
> -
> - if (pfn_valid(pfn))
> - dma_direct_sync_single_for_cpu(hwdev, handle, size, dir);
> - else
> - __xen_dma_sync_single_for_cpu(hwdev, handle, size, dir);
> -}
> -
> -static inline void xen_dma_sync_single_for_device(struct device *hwdev,
> - dma_addr_t handle, size_t size, enum dma_data_direction dir)
> -{
> - unsigned long pfn = PFN_DOWN(handle);
> - if (pfn_valid(pfn))
> - dma_direct_sync_single_for_device(hwdev, handle, size, dir);
> - else
> - __xen_dma_sync_single_for_device(hwdev, handle, size, dir);
> -}
> -
> -static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
> - dma_addr_t dev_addr, unsigned long offset, size_t size,
> - enum dma_data_direction dir, unsigned long attrs)
> -{
> - unsigned long page_pfn = page_to_xen_pfn(page);
> - unsigned long dev_pfn = XEN_PFN_DOWN(dev_addr);
> - unsigned long compound_pages =
> - (1< - bool local = (page_pfn <= dev_pfn) &&
> - (dev_pfn - page_pfn < compound_pages);
> -
> - if (local)
> - dma_direct_map_page(hwdev, page, offset, size, dir, attrs);
> - else
> - __xen_dma_map_page(hwdev, page, dev_addr, offset, size, dir,
> attrs);
> -}
> -
> -static inline void xen_dma_unmap_page(struct device *hwdev, dma_addr_t
> handle,
> - size_t size, enum dma_data_direction dir, unsigned long attrs)
> -{
> - unsigned long pfn = PFN_DOWN(handle);
> - /*
> - * Dom0 is mapped 1:1, while the Linux page can be spanned accross
> - * multiple Xen page, it's not possible to have a mix of local and
> - * foreign Xen page. Dom0 is mapped 1:1, so calling pfn_valid on a
> - * foreign mfn will always return false. If the page is local we can
> - * safely call the native dma_ops function, otherwise we call the xen
> - * specific function.
> - */
> - if (pfn_valid(pfn))
> - dma_direct_unmap_page(hwdev, handle, size, dir, attrs);
> - else
> - __xen_dma_unmap_page(hwdev, handle, size, dir, attrs);
> -}
> -
> -#endif /* _ASM_ARM_XEN_PAGE_COHERENT_H */
> diff --git a/arch/arm64/include/asm/xen/page-coherent.h
> b/arch/arm64/include/asm/xen/page-coherent.h
> index d88e56b90b93..27e984977402 100644
> --- a/arch/arm64/include/asm/xen/page-coherent.h
> +++ b/arch/arm64/include/asm/xen/page-coherent.h
> @@ -1,77 +1,2 @@
> /* SPDX-License-Identifier: GPL-2.0 */
> -#ifndef _ASM_ARM64_XEN_PAGE_COHERENT_H
> -#define _ASM_ARM64_XEN_PAGE_COHERENT_H
> -
> -#include
> -#include
> #include
> -
> -static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t
> size,
> - dma_addr_t *dma_handle, gfp_t flags, unsigned long attrs)
> -{
> - return dma_direct_alloc(hwdev, size, dma_handle, flags, attrs);
> -}
> -
> -static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
> - void *cpu_addr, dma_addr_t dma_handle, unsigned long attrs)
Re: [Xen-devel] [PATCH 01/11] xen/arm: use dma-noncoherent.h calls for xen-swiotlb cache maintainance
On Thu, 5 Sep 2019, Christoph Hellwig wrote:
> Copy the arm64 code that uses the dma-direct/swiotlb helpers for DMA
> on-coherent devices.
>
> Signed-off-by: Christoph Hellwig
This is much better and much more readable.
Reviewed-by: Stefano Stabellini
> ---
> arch/arm/include/asm/device.h| 3 -
> arch/arm/include/asm/xen/page-coherent.h | 72 +---
> arch/arm/mm/dma-mapping.c| 8 +--
> drivers/xen/swiotlb-xen.c| 20 ---
> 4 files changed, 28 insertions(+), 75 deletions(-)
>
> diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
> index f6955b55c544..c675bc0d5aa8 100644
> --- a/arch/arm/include/asm/device.h
> +++ b/arch/arm/include/asm/device.h
> @@ -14,9 +14,6 @@ struct dev_archdata {
> #endif
> #ifdef CONFIG_ARM_DMA_USE_IOMMU
> struct dma_iommu_mapping*mapping;
> -#endif
> -#ifdef CONFIG_XEN
> - const struct dma_map_ops *dev_dma_ops;
> #endif
> unsigned int dma_coherent:1;
> unsigned int dma_ops_setup:1;
> diff --git a/arch/arm/include/asm/xen/page-coherent.h
> b/arch/arm/include/asm/xen/page-coherent.h
> index 2c403e7c782d..602ac02f154c 100644
> --- a/arch/arm/include/asm/xen/page-coherent.h
> +++ b/arch/arm/include/asm/xen/page-coherent.h
> @@ -6,23 +6,37 @@
> #include
> #include
>
> -static inline const struct dma_map_ops *xen_get_dma_ops(struct device *dev)
> -{
> - if (dev && dev->archdata.dev_dma_ops)
> - return dev->archdata.dev_dma_ops;
> - return get_arch_dma_ops(NULL);
> -}
> -
> static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t
> size,
> dma_addr_t *dma_handle, gfp_t flags, unsigned long attrs)
> {
> - return xen_get_dma_ops(hwdev)->alloc(hwdev, size, dma_handle, flags,
> attrs);
> + return dma_direct_alloc(hwdev, size, dma_handle, flags, attrs);
> }
>
> static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
> void *cpu_addr, dma_addr_t dma_handle, unsigned long attrs)
> {
> - xen_get_dma_ops(hwdev)->free(hwdev, size, cpu_addr, dma_handle, attrs);
> + dma_direct_free(hwdev, size, cpu_addr, dma_handle, attrs);
> +}
> +
> +static inline void xen_dma_sync_single_for_cpu(struct device *hwdev,
> + dma_addr_t handle, size_t size, enum dma_data_direction dir)
> +{
> + unsigned long pfn = PFN_DOWN(handle);
> +
> + if (pfn_valid(pfn))
> + dma_direct_sync_single_for_cpu(hwdev, handle, size, dir);
> + else
> + __xen_dma_sync_single_for_cpu(hwdev, handle, size, dir);
> +}
> +
> +static inline void xen_dma_sync_single_for_device(struct device *hwdev,
> + dma_addr_t handle, size_t size, enum dma_data_direction dir)
> +{
> + unsigned long pfn = PFN_DOWN(handle);
> + if (pfn_valid(pfn))
> + dma_direct_sync_single_for_device(hwdev, handle, size, dir);
> + else
> + __xen_dma_sync_single_for_device(hwdev, handle, size, dir);
> }
>
> static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
> @@ -36,17 +50,8 @@ static inline void xen_dma_map_page(struct device *hwdev,
> struct page *page,
> bool local = (page_pfn <= dev_pfn) &&
> (dev_pfn - page_pfn < compound_pages);
>
> - /*
> - * Dom0 is mapped 1:1, while the Linux page can span across
> - * multiple Xen pages, it's not possible for it to contain a
> - * mix of local and foreign Xen pages. So if the first xen_pfn
> - * == mfn the page is local otherwise it's a foreign page
> - * grant-mapped in dom0. If the page is local we can safely
> - * call the native dma_ops function, otherwise we call the xen
> - * specific function.
> - */
> if (local)
> - xen_get_dma_ops(hwdev)->map_page(hwdev, page, offset, size,
> dir, attrs);
> + dma_direct_map_page(hwdev, page, offset, size, dir, attrs);
> else
> __xen_dma_map_page(hwdev, page, dev_addr, offset, size, dir,
> attrs);
> }
> @@ -63,33 +68,10 @@ static inline void xen_dma_unmap_page(struct device
> *hwdev, dma_addr_t handle,
>* safely call the native dma_ops function, otherwise we call the xen
>* specific function.
>*/
> - if (pfn_valid(pfn)) {
> - if (xen_get_dma_ops(hwdev)->unmap_page)
> - xen_get_dma_ops(hwdev)->unmap_page(hwdev, handle, size,
> dir, attrs);
> - } else
> + if (pfn_valid(pfn))
> + dma_direct_unmap_page(hwdev, handle, size, dir, at
Re: [Xen-devel] [PATCH V2] arm: xen: mm: use __GPF_DMA32 for arm64
On Wed, 11 Sep 2019, Peng Fan wrote:
> > Subject: Re: [PATCH V2] arm: xen: mm: use __GPF_DMA32 for arm64
> >
> > + Juergen, Boris
> >
> > On Fri, 30 Aug 2019, Christoph Hellwig wrote:
> > > Can we take a step back and figure out what we want to do here?
> > >
> > > AFAICS this function allocates memory for the swiotlb-xen buffer, and
> > > that means it must be <= 32-bit addressable to satisfy the DMA API
> > > guarantees. That means we generally want to use GFP_DMA32
> > everywhere
> > > that exists, but on systems with odd zones we might want to dip into
> > > GFP_DMA. This also means swiotlb-xen doesn't actually do the right
> > > thing on x86 at the moment. So shouldn't we just have one common
> > > routine in swiotlb-xen.c that checks if we have CONFIG_ZONE_DMA32 set,
> > > then try GFP_DMA32, and if not check if CONFIG_ZONE_DMA is set and
> > > then try that, else default to GFP_KERNEL?
> >
> > Yes, for ARM/ARM64 it makes a lot of sense given that dom0 is 1:1 mapped
> > (pseudo-physical == physical). I'll let Juergen and Boris comment on the
> > x86
> > side of things, but on x86 PV Dom0 is not 1:1 mapped so
> > GFP_DMA32 is probably not meaningful.
>
> If we only take ARM/ARM64, so could the following patch be ok?
>
> diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
> index d33b77e9add3..e5a6a73b2e06 100644
> --- a/arch/arm/xen/mm.c
> +++ b/arch/arm/xen/mm.c
> @@ -28,7 +28,11 @@ unsigned long xen_get_swiotlb_free_pages(unsigned int
> order)
>
> for_each_memblock(memory, reg) {
> if (reg->base < (phys_addr_t)0x) {
> +#ifdef CONFIG_ZONE_DMA32
> + flags |= __GFP_DMA32;
> +#else
> flags |= __GFP_DMA;
> +#endif
> break;
> }
> }
I am OK with something like this, but at that point we can use
IS_ENABLED(CONFIG_ZONE_DMA32) for the check.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: bootfd: Fix indentation in process_multiboot_node()
On Wed, 11 Sep 2019, Volodymyr Babchuk wrote: > > Julien Grall writes: > > > One line in process_multiboot_node() is using hard tab rather than soft > > tab. So fix it! > > > > Signed-off-by: Julien Grall > Reviewed-by: Volodymyr Babchuk Acked-by: Stefano Stabellini ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: setup: Relocate the Device-Tree later on in the boot
On Wed, 11 Sep 2019, Volodymyr Babchuk wrote: > Hi Julien, > > Julien Grall writes: > > > At the moment, the Device-Tree is relocated into xenheap while setting > > up the memory subsystem. This is actually not necessary because the > > early mapping is still present and we don't require the virtual address > > to be stable until unflatting the Device-Tree. > > > > So the relocation can safely be moved after the memory subsystem is > > fully setup. This has the nice advantage to make the relocation common > > and let the xenheap allocator decides where to put it. > > > > Lastly, the device-tree is not going to be used for ACPI system. So > > there are no need to relocate it and can just be discarded. > > > > Signed-off-by: Julien Grall > Reviewed-by: Volodymyr Babchuk Acked-by: Stefano Stabellini ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/arm32: setup: Give a xenheap page to the boot allocator
On Tue, 17 Sep 2019, Julien Grall wrote:
> After commit 6e3e771203 "xen/arm: setup: Relocate the Device-Tree later on
> in the boot", the boot allocator will not receive any xenheap page (i.e.
> mapped page) on Arm32.
>
> However, the boot allocator implicitely rely on having the first page
> already mapped and therefore result to break boot on Arm32.
>
> The easiest way for now is to give a xenheap page to the boot allocator.
> We may want to rethink the interface in the future.
>
> Fixes: 6e3e771203 ('xen/arm: setup: Relocate the Device-Tree later on in the
> boot')
> Signed-off-by: Julien Grall
> ---
> xen/arch/arm/setup.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index ebbfad94e4..e6ddefb5cf 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -593,6 +593,7 @@ static void __init setup_mm(void)
> unsigned long heap_pages, xenheap_pages, domheap_pages;
> int i;
> const uint32_t ctr = READ_CP32(CTR);
> +mfn_t boot_mfn_start, boot_mfn_end;
>
> if ( !bootinfo.mem.nr_banks )
> panic("No memory bank\n");
> @@ -665,6 +666,11 @@ static void __init setup_mm(void)
>
> setup_xenheap_mappings((e >> PAGE_SHIFT) - xenheap_pages, xenheap_pages);
>
> +/* We need a single mapped page for populating bootmem_region_list. */
> +boot_mfn_start = mfn_add(xenheap_mfn_end, -1);
> +boot_mfn_end = xenheap_mfn_end;
> +init_boot_pages(mfn_to_maddr(boot_mfn_start),
> mfn_to_maddr(boot_mfn_end));
> +
> /* Add non-xenheap memory */
> for ( i = 0; i < bootinfo.mem.nr_banks; i++ )
> {
> @@ -710,7 +716,7 @@ static void __init setup_mm(void)
>
> /* Add xenheap memory that was not already added to the boot allocator.
> */
> init_xenheap_pages(mfn_to_maddr(xenheap_mfn_start),
> - mfn_to_maddr(xenheap_mfn_end));
> + mfn_to_maddr(boot_mfn_end));
I can see what you are trying to do with this patch and it looks like
the right fix at the moment. However, shouldn't this last change:
mfn_to_maddr(boot_mfn_start)
> }
> #else /* CONFIG_ARM_64 */
> static void __init setup_mm(void)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [[PATCH for-4.13]] xen/arm: mm: Allow generic xen page-tables helpers to be called early
On Tue, 17 Sep 2019, Julien Grall wrote:
> The current implementations of xen_{map, unmap}_table() expect
> {map, unmap}_domain_page() to be usable. Those helpers are used to
> map/unmap page tables while update Xen page-tables.
>
> Since commit 022387ee1a "xen/arm: mm: Don't open-code Xen PT update in
> {set, clear}_fixmap()", setup_fixmap() will make use of the helpers
> mentioned above. When booting Xen using GRUB, setup_fixmap() may be used
> before map_domain_page() can be called. This will result to data abort:
>
> (XEN) Data Abort Trap. Syndrome=0x5
> (XEN) CPU0: Unexpected Trap: Data Abort
>
> [...]
>
> (XEN) Xen call trace:
> (XEN)[<0025ab6c>] mm.c#xen_pt_update+0x2b4/0x59c (PC)
> (XEN)[<0025ab20>] mm.c#xen_pt_update+0x268/0x59c (LR)
> (XEN)[<0025ae70>] set_fixmap+0x1c/0x2c
> (XEN)[<002a9c98>] copy_from_paddr+0x7c/0xdc
> (XEN)[<002a4ae0>] has_xsm_magic+0x18/0x34
> (XEN)[<002a5b5c>] bootfdt.c#early_scan_node+0x398/0x560
> (XEN)[<002a5de0>] device_tree_for_each_node+0xbc/0x144
> (XEN)[<002a5ed4>] boot_fdt_info+0x6c/0x260
> (XEN)[<002ac0d0>] start_xen+0x108/0xc74
> (XEN)[<0020044c>] arm64/head.o#paging+0x60/0x88
>
> During early boot, the page tables are either statically allocated in
> Xen binary or allocated via alloc_boot_pages().
>
> For statically allocated page-tables, they will already be mapped as
> part of Xen binary. So we can easily find the virtual address.
>
> For dynamically allocated page-tables, we need to rely
> map_domain_page() to be functionally working.
>
> For arm32, the call will be usable much before page can be dynamically
> allocated (see setup_pagetables()). For arm64, the call will be usable
> after setup_xenheap_mappings().
>
> In both cases, memory are given to the boot allocator afterwards. So we
> can rely on map_domain_page() for mapping page tables allocated
> dynamically.
>
> The helpers xen_{map, unmap}_table() are now updated to take into
> account the case where page-tables are part of Xen binary.
>
> Fixes: 022387ee1a ('xen/arm: mm: Don't open-code Xen PT update in {set,
> clear}_fixmap()')
> Signed-off-by: Julien Grall
> ---
> xen/arch/arm/mm.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index e1cdeaaf2f..da6303a8fd 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -950,11 +950,31 @@ static int create_xen_table(lpae_t *entry)
>
> static lpae_t *xen_map_table(mfn_t mfn)
> {
> +/*
> + * We may require to map the page table before map_domain_page() is
> + * useable. The requirements here is it must be useable as soon as
> + * page-tables are allocated dynamically via alloc_boot_pages().
> + */
> +if ( system_state == SYS_STATE_early_boot )
> +{
> +vaddr_t va = mfn_to_maddr(mfn) - phys_offset;
> +
> +if ( is_kernel(va) )
> +return (lpae_t *)va;
Is it intended to continue if it is not a xen text page? Shouldn't we
BUG() or WARN?
> +}
> +
> return map_domain_page(mfn);
> }
>
> static void xen_unmap_table(const lpae_t *table)
> {
> +/*
> + * During early boot, xen_map_table() will not use map_domain_page()
> + * for page-tables residing in Xen binary. So skip the unmap part.
> + */
> +if ( system_state == SYS_STATE_early_boot && is_kernel(table) )
> +return;
> +
> unmap_domain_page(table);
> }
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: iommu: Panic if not all IOMMUs are initialized
On Tue, 20 Aug 2019, Oleksandr wrote:
>
> On 20.08.19 15:22, Julien Grall wrote:
>
> Hi, Julien
>
> > -iommu_setup();
> > +rc = iommu_setup();
> > +if ( !iommu_enabled && rc != -ENODEV )
> > +panic("Couldn't configure correctly all the IOMMUs.");
> >
>
> Please add "\n"
>
>
> You can add:
>
> Tested-by: Oleksandr Tyshchenko
Reviewed-by: Stefano Stabellini
I added the "\n", fixed a typo in the commit message, and committed the
patch.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
