[Xen-devel] [distros-debian-snapshot test] 66558: tolerable trouble: blocked/broken

[Platform Team regression test user]

flight 66558 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66558/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-armhf-pvops 3 host-install(3)  broken like 66519
 build-armhf   3 host-install(3)  broken like 66519
 build-i386-pvops  3 host-install(3)  broken like 66519
 build-amd64   3 host-install(3)  broken like 66519
 build-amd64-pvops 3 host-install(3)  broken like 66519
 build-i3863 host-install(3)  broken like 66519

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-armhf-daily-netboot-pygrub  1 build-check(1)  blocked n/a
 test-amd64-amd64-amd64-current-netinst-pygrub  1 build-check(1)blocked n/a
 test-amd64-amd64-i386-weekly-netinst-pygrub  1 build-check(1)  blocked n/a
 test-amd64-amd64-amd64-daily-netboot-pvgrub  1 build-check(1)  blocked n/a
 test-amd64-i386-i386-daily-netboot-pvgrub  1 build-check(1)blocked n/a
 test-amd64-amd64-i386-daily-netboot-pygrub  1 build-check(1)   blocked n/a
 test-amd64-i386-i386-current-netinst-pygrub  1 build-check(1)  blocked n/a
 test-amd64-i386-amd64-weekly-netinst-pygrub  1 build-check(1)  blocked n/a
 test-amd64-amd64-i386-current-netinst-pygrub  1 build-check(1) blocked n/a
 test-amd64-i386-amd64-current-netinst-pygrub  1 build-check(1) blocked n/a
 test-amd64-i386-i386-weekly-netinst-pygrub  1 build-check(1)   blocked n/a
 test-amd64-amd64-amd64-weekly-netinst-pygrub  1 build-check(1) blocked n/a
 test-amd64-i386-amd64-daily-netboot-pygrub  1 build-check(1)   blocked n/a

baseline version:
 flight   66519

jobs:
 build-amd64  broken  
 build-armhf  broken  
 build-i386   broken  
 build-amd64-pvopsbroken  
 build-armhf-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-amd64-daily-netboot-pvgrub  blocked 
 test-amd64-i386-i386-daily-netboot-pvgrubblocked 
 test-amd64-i386-amd64-daily-netboot-pygrub   blocked 
 test-armhf-armhf-armhf-daily-netboot-pygrub  blocked 
 test-amd64-amd64-i386-daily-netboot-pygrub   blocked 
 test-amd64-amd64-amd64-current-netinst-pygrubblocked 
 test-amd64-i386-amd64-current-netinst-pygrub blocked 
 test-amd64-amd64-i386-current-netinst-pygrub blocked 
 test-amd64-i386-i386-current-netinst-pygrub  blocked 
 test-amd64-amd64-amd64-weekly-netinst-pygrub blocked 
 test-amd64-i386-amd64-weekly-netinst-pygrub  blocked 
 test-amd64-amd64-i386-weekly-netinst-pygrub  blocked 
 test-amd64-i386-i386-weekly-netinst-pygrub   blocked 



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 04/17] libxl/arm: prepare for constructing ACPI tables

[Shannon Zhao]

On 2016/7/7 23:50, Wei Liu wrote:
> On Tue, Jul 05, 2016 at 11:12:34AM +0800, Shannon Zhao wrote:
>> > From: Shannon Zhao 
>> > 
>> > It only constructs the ACPI tables for 64-bit ARM DomU when user enables
>> > acpi because 32-bit DomU doesn't support ACPI.
>> > 
>> > Signed-off-by: Shannon Zhao 
>> > ---
>> >  tools/libxl/Makefile |  4 
>> >  tools/libxl/libxl_arm.c  | 19 ++-
>> >  tools/libxl/libxl_arm.h  | 33 ++
>> >  tools/libxl/libxl_arm_acpi.c | 56 
>> > 
>> >  4 files changed, 111 insertions(+), 1 deletion(-)
>> >  create mode 100644 tools/libxl/libxl_arm.h
>> >  create mode 100644 tools/libxl/libxl_arm_acpi.c
>> > 
>> > diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
>> > index 0cf9f6a..88ab4d2 100644
>> > --- a/tools/libxl/Makefile
>> > +++ b/tools/libxl/Makefile
>> > @@ -91,6 +91,10 @@ acpi:
>> >  
>> >  LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o 
>> > libxl_x86_acpi.o
>> >  LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o 
>> > libxl_libfdt_compat.o
>> > +LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o
>> > +
>> > +libxl_arm_acpi.o: libxl_arm_acpi.c
>> > +  $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c
>> >  
>> >  ifeq ($(CONFIG_NetBSD),y)
>> >  LIBXL_OBJS-y += libxl_netbsd.o
>> > diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
>> > index 4a57dd7..7c522e1 100644
>> > --- a/tools/libxl/libxl_arm.c
>> > +++ b/tools/libxl/libxl_arm.c
>> > @@ -1,6 +1,7 @@
>> >  #include "libxl_internal.h"
>> >  #include "libxl_arch.h"
>> >  #include "libxl_libfdt_compat.h"
>> > +#include "libxl_arm.h"
>> >  
>> >  #include 
>> >  #include 
>> > @@ -885,8 +886,24 @@ int libxl__arch_domain_init_hw_description(libxl__gc 
>> > *gc,
>> > libxl__domain_build_state 
>> > *state,
>> > struct xc_dom_image *dom)
>> >  {
>> > +int rc;
>> > +
>> >  assert(info->type == LIBXL_DOMAIN_TYPE_PV);
>> > -return libxl__prepare_dtb(gc, info, state, dom);
>> > +rc = libxl__prepare_dtb(gc, info, state, dom);
>> > +if (rc)
>> > +return rc;
>> > +
>> > +if (!libxl_defbool_val(info->arch_arm.acpi)) {
>> > +LOG(DEBUG, "Generating ACPI tables is disabled by user.");
>> > +return 0;
>> > +}
>> > +
>> > +if (strcmp(dom->guest_type, "xen-3.0-aarch64")) {
>> > +LOG(ERROR, "Can not enable xl option 'acpi' for %s", 
>> > dom->guest_type);
>> > +return ERROR_FAIL;
>> > +}
>> > +
>> > +return libxl__prepare_acpi(gc, info, state, dom);
> Please use goto style error handling for consistency. See
> tools/libxl/CODING_STYLE. Please fix all other instances as well.
> 
Ok, will fix these. Thanks.

-- 
Shannon


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6] x86/mem-sharing: mem-sharing a range of memory

[Wei Liu]

On Mon, Jul 11, 2016 at 01:57:50PM -0600, Tamas K Lengyel wrote:
> Currently mem-sharing can be performed on a page-by-page basis from the 
> control
> domain. However, this process is quite wasteful when a range of pages have to
> be deduplicated.
> 
> This patch introduces a new mem_sharing memop for range sharing where
> the user doesn't have to separately nominate each page in both the source and
> destination domain, and the looping over all pages happen in the hypervisor.
> This significantly reduces the overhead of sharing a range of memory.
> 
> Signed-off-by: Tamas K Lengyel 
> ---
> Cc: Ian Jackson 
> Cc: Wei Liu 
> Cc: George Dunlap 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> ---
>  tools/libxc/include/xenctrl.h|  15 
>  tools/libxc/xc_memshr.c  |  19 +
>  tools/tests/mem-sharing/memshrtool.c |  22 ++
>  xen/arch/x86/mm/mem_sharing.c| 140 
> +++
>  xen/include/public/memory.h  |  10 ++-
>  5 files changed, 205 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 4a85b4a..650a763 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -2333,6 +2333,21 @@ int xc_memshr_add_to_physmap(xc_interface *xch,
>  domid_t client_domain,
>  unsigned long client_gfn);
>  
> +/* Allows to deduplicate a range of memory of a client domain. Using
> + * this function is equivalent of calling xc_memshr_nominate_gfn for each gfn
> + * in the two domains followed by xc_memshr_share_gfns.
> + *
> + * May fail with -EINVAL if the source and client domain have different
> + * memory size or if memory sharing is not enabled on either of the domains.
> + * May also fail with -ENOMEM if there isn't enough memory available to store
> + * the sharing metadata before deduplication can happen.
> + */
> +int xc_memshr_range_share(xc_interface *xch,
> + domid_t source_domain,
> + domid_t client_domain,
> + unsigned long start,
> + unsigned long end);

Indentation seems wrong -- did you use tab here?

> +
>  /* Debug calls: return the number of pages referencing the shared frame 
> backing
>   * the input argument. Should be one or greater. 
>   *
> diff --git a/tools/libxc/xc_memshr.c b/tools/libxc/xc_memshr.c
> index deb0aa4..6b26f3f 100644
> --- a/tools/libxc/xc_memshr.c
> +++ b/tools/libxc/xc_memshr.c
> @@ -181,6 +181,25 @@ int xc_memshr_add_to_physmap(xc_interface *xch,
>  return xc_memshr_memop(xch, source_domain, &mso);
>  }
>  
> +int xc_memshr_range_share(xc_interface *xch,
> + domid_t source_domain,
> + domid_t client_domain,
> + unsigned long start,
> + unsigned long end)

Ditto.

> +{
> +xen_mem_sharing_op_t mso;
> +
> +memset(&mso, 0, sizeof(mso));
> +
> +mso.op = XENMEM_sharing_op_range_share;
> +
> +mso.u.range.client_domain = client_domain;
> +mso.u.range.start = start;
> +mso.u.range.end = end;
> +
> +return xc_memshr_memop(xch, source_domain, &mso);
> +}
> +
>  int xc_memshr_domain_resume(xc_interface *xch,
>  domid_t domid)
>  {
> diff --git a/tools/tests/mem-sharing/memshrtool.c 
> b/tools/tests/mem-sharing/memshrtool.c
> index 437c7c9..bd1f4e0 100644
> --- a/tools/tests/mem-sharing/memshrtool.c
> +++ b/tools/tests/mem-sharing/memshrtool.c
> @@ -24,6 +24,8 @@ static int usage(const char* prog)
>  printf("  nominate- Nominate a page for sharing.\n");
>  printf("  share  
> \n");
>  printf("  - Share two pages.\n");
> +printf("  range
> \n");
> +printf("  - Share pages between domains in 
> range.\n");
>  printf("  unshare - Unshare a page by grabbing a 
> writable map.\n");
>  printf("  add-to-physmap 
> \n");
>  printf("  - Populate a page in a domain with a 
> shared page.\n");
> @@ -180,6 +182,26 @@ int main(int argc, const char** argv)
>  }
>  printf("Audit returned %d errors.\n", rc);
>  }
> +else if( !strcasecmp(cmd, "range") )
> +{
> +domid_t sdomid, cdomid;
> +int rc;
> +unsigned long start, end;
> +
> +if( argc != 6 )

Space after "if".

With all those fixed:

Acked-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v4] xen/arm: Add a clock property

[Dirk Behme]

Clocks described by this property are reserved for use by Xen, and the OS
must not alter their state any way, such as disabling or gating a clock,
or modifying its rate. Ensuring this may impose constraints on parent
clocks or other resources used by the clock tree.

This property is used to proxy clocks for devices Xen has taken ownership
of, such as UARTs, for which the associated clock controller(s) remain
under the control of Dom0.

Up to now, the workaround for this has been to use the Linux kernel
command line parameter 'clk_ignore_unused'. See Xen bug

http://bugs.xenproject.org/xen/bug/45

too.

Signed-off-by: Dirk Behme 
---
Changes in v4: Switch to the xen.txt description proposed by Mark:
   https://www.spinics.net/lists/arm-kernel/msg516158.html

Changes in v3: Use the xen.txt description proposed by Michael. Thanks!

Changes in v2: Drop the Linux implementation details like clk_disable_unused
   in xen.txt.

 Documentation/devicetree/bindings/arm/xen.txt | 12 +++
 arch/arm/xen/enlighten.c  | 47 +++
 2 files changed, 59 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/xen.txt 
b/Documentation/devicetree/bindings/arm/xen.txt
index c9b9321..437e50b 100644
--- a/Documentation/devicetree/bindings/arm/xen.txt
+++ b/Documentation/devicetree/bindings/arm/xen.txt
@@ -17,6 +17,18 @@ the following properties:
   A GIC node is also required.
   This property is unnecessary when booting Dom0 using ACPI.
 
+Optional properties:
+
+- clocks: a list of phandle + clock-specifier pairs
+  Clocks described by this property are reserved for use by Xen, and the
+  OS must not alter their state any way, such as disabling or gating a
+  clock, or modifying its rate. Ensuring this may impose constraints on
+  parent clocks or other resources used by the clock tree.
+
+  Note: this property is used to proxy clocks for devices Xen has taken
+  ownership of, such as UARTs, for which the associated clock
+  controller(s) remain under the control of Dom0.
+
 To support UEFI on Xen ARM virtual platforms, Xen populates the FDT "uefi" node
 under /hypervisor with following parameters:
 
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 47acb36..5c546d0 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -444,6 +445,52 @@ static int __init xen_pm_init(void)
 }
 late_initcall(xen_pm_init);
 
+/*
+ * Check if we want to register some clocks, that they
+ * are not freed because unused by clk_disable_unused().
+ * E.g. the serial console clock.
+ */
+static int __init xen_arm_register_clks(void)
+{
+   struct clk *clk;
+   struct device_node *xen_node;
+   unsigned int i, count;
+   int ret = 0;
+
+   xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
+   if (!xen_node) {
+   pr_err("Xen support was detected before, but it has 
disappeared\n");
+   return -EINVAL;
+   }
+
+   count = of_clk_get_parent_count(xen_node);
+   if (!count)
+   goto out;
+
+   for (i = 0; i < count; i++) {
+   clk = of_clk_get(xen_node, i);
+   if (IS_ERR(clk)) {
+   pr_err("Xen failed to register clock %i. Error: %li\n",
+  i, PTR_ERR(clk));
+   ret = PTR_ERR(clk);
+   goto out;
+   }
+
+   ret = clk_prepare_enable(clk);
+   if (ret < 0) {
+   pr_err("Xen failed to enable clock %i. Error: %i\n",
+  i, ret);
+   goto out;
+   }
+   }
+
+   ret = 0;
+
+out:
+   of_node_put(xen_node);
+   return ret;
+}
+late_initcall(xen_arm_register_clks);
 
 /* empty stubs */
 void xen_arch_pre_suspend(void) { }
-- 
2.8.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 00/16] x86/vm-event: numerous adjustments & fixes

[Tian, Kevin]

Thanks for explanation. It makes sense then.

From: Corneliu ZUZU [mailto:cz...@bitdefender.com]
Sent: Monday, July 11, 2016 1:32 PM
To: Tian, Kevin; xen-devel@lists.xen.org
Cc: Andrew Cooper; George Dunlap; Jan Beulich; Julien Grall; Nakajima, Jun; 
Paul Durrant; Razvan Cojocaru; Stefano Stabellini; Tamas K Lengyel
Subject: Re: [PATCH 00/16] x86/vm-event: numerous adjustments & fixes

On 7/11/2016 5:54 AM, Tian, Kevin wrote:

what's the difference between this series and earlier one?



[PATCH v3 0/8] x86/vm-event: Adjustments & fixes



looks you have some patches cross-posted (e.g. 1/16)...



Corneliu ZUZU (16):

  x86/vmx_update_guest_cr: minor optimization

  x86: fix: make atomic_read() param const

  x86/monitor: mechanical renames

  x86/monitor: relocate vm_event_register_write_resume() function to

monitor code

  x86/monitor: relocate code more appropriately

  x86/monitor: fix: set msr_bitmap to NULL after xfree

  x86/vm-event: fix: call cleanup when init fails, to free partial

allocs

  x86/vm-event: call monitor init & cleanup funcs from respective

vm_event funcs

  arm/monitor: move d->monitor cleanup to monitor_cleanup_domain()

  x86/vm-event: centralize vcpu-destroy cleanup in vm-events code

  x86/monitor: fix: treat -monitor- properly, as a subsys of the

vm-event subsys

  x86/vm-event: fix: move cleanup of mem_access_emulate_each_rep to

monitor stub

  x86/monitor: introduce writes_pending field in monitor_write_data

  x86/monitor: clarify separation between monitor subsys and vm-event as

a whole

  x86/monitor: fix: don't compromise a monitor_write_data with pending

CR writes

  x86/monitor: fix: xc_monitor _write_ctrlreg w/o previous _enable must

fail



--

2.5.0





Hi Kevin,

I'm sorry about the confusion, the _older v3 series is superseded by this 
16-patches one_. I thought the latter was too complex to consider as a v4 over 
the former, but I should have at least stated something to lead you guys to 
that conclusion (and to specify changes..). The patches that are still in this 
series from the older one, the changes and the acks are as following:

- P 1/16, was 1/8 in v3
* changed since v3: nothing
* acked-by in old v3: Acked-by: Kevin Tian 


- P 5/16, was 2/8 in v3
* changed since v3:
- title slightly changed
- renames due to 3/16: 
arch_monitor_write_data()->monitor_ctrlreg_write_data(), 
write_ctrlreg_adjust_traps()->monitor_ctrlreg_adjust_traps(), 
write_ctrlreg_disable_traps()->monitor_ctrlreg_disable_traps()
- added 'const' attribute to "struct *domain" param of 
vmx_vm_event_update_cr3_traps
- 'index' param of monitor_ctrlreg_adjust_traps now of type 'unsigned 
int'
* acked-by in old v3: no-one

- P 15/16, was 3/8 in v3:
 * changed since v3 (IMO changes are too many and depends on previous 
patches in this 16-p-series and it would be better if the old v3 one is simply 
forgotten-about):
- separated fields in arch_vm_event in another structure and 
arch_vm_event only holds a pointer to that struct (arch_vm_event->monitor->...) 
- see 14/16 for details
- arch_vm_event.monitor freed entirely when the pending writes are 
committed (monitor_ctrlreg_write_data()) or when the domain/vcpu is destroyed
 * acked-by in old v3: no-one

- P 16/16, was 4/8 in v3:
 * changed since v3: use ENODEV error code instead of ENOSYS
 * acked-by in old v3: no-one

The rest of patches in v3 (P5-P8) already made it to staging.

Sorry again and thanks,
Zuzu C.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 05/16] x86/monitor: relocate code more appropriately

[Tian, Kevin]

> From: Corneliu ZUZU [mailto:cz...@bitdefender.com]
> Sent: Monday, July 11, 2016 2:19 PM
> >
> > +static inline
> > +void monitor_ctrlreg_adjust_traps(struct domain *d, unsigned int index)
> > +{
> > +/* For now, VMX only. */
> > +ASSERT(cpu_has_vmx);
> > +
> > +/* Other CRs than CR3 are always trapped. */
> > +if ( VM_EVENT_X86_CR3 == index )
> > +vmx_vm_event_update_cr3_traps(d);
>  [Kevin wrote]:
> 
>   Please add above into a hvm function instead of directly calling
>   vmx in common file. (other arch can have it unimplemented).
>   Then you don't need change this common code again later when
>   other archs are added
> 
> ---
> 
> 
> This is not common code, it's in arch/x86/monitor.c (?) and currently,
> as the above ASSERT indicates, only VMX is supported. If in the future
> support for SVM for example will be added, then the hvm move you suggest
> must be done (Jan also suggested this).
> Or, I only now realize, if you guys prefer doing this now I could add a
> vm_event_update_cr3_traps field in hvm_function_table, but BUG() in the
> SVM one..
> 

The latter is desired. Instead of BUG, it makes more sense to return
error on an arch which doesn't register the callback.

Thanks
Kevin
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [Minios-devel] [PATCH] mini-os: make cscope repair

[Wei Liu]

On Fri, Jul 01, 2016 at 11:33:11AM +0200, Juergen Gross wrote:
> "make cscope" doesn't like symbolic link include/mini-os->. as it
> leads to a file system recursion. Repair that by not following links
> when searching the sources.
> 
> Signed-off-by: Juergen Gross 

Queued.

Juergen, please CC me on all your mini-os patches so that I know I need
to commit them when they are acked.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [Minios-devel] [PATCH] mini-os: replace lib/printf.c with a version not under GPL

[Wei Liu]

On Mon, Jul 04, 2016 at 09:26:20PM +0200, Samuel Thibault wrote:
> Hello,
> 
> Juergen Gross, on Mon 04 Jul 2016 07:29:46 +0200, wrote:
> > > Did you check the boot output e.g. of a trivial mini-os application?
> > > Notably, iirc there were perhaps odd formating with %x, %p or such.
> > > Moving to the posix behavior would be a good thing, I'd just want to
> > > know whether we have some behavior change.
> > 
> > Just double checked: some of the prints are now without leading zeroes:
> 
> Ok, so %p moves from %08x to 0x%x. That's fine by me, anybody against
> the change?
> 

No objection from me. :-)

If you ack this patch I will just queue it.

Wei.

> Samuel
> 
> ___
> Minios-devel mailing list
> minios-de...@lists.xenproject.org
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/minios-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] xen_pvscsi: reclaim the ring request when the prepairing failed

[Juergen Gross]

On 12/07/16 02:36, Bin Wu wrote:
> During scsi command queueing or exception handling, if prepairing
> fails, we need to reclaim the failed request. Otherwise, the garbage
> request will be pushed into the ring for the backend to work.
> 
> Signed-off-by: Bin Wu 

Reviewed-by: Juergen Gross 

> ---
>  drivers/scsi/xen-scsifront.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/xen-scsifront.c b/drivers/scsi/xen-scsifront.c
> index 9dc8687..8646db1 100644
> --- a/drivers/scsi/xen-scsifront.c
> +++ b/drivers/scsi/xen-scsifront.c
> @@ -184,8 +184,6 @@ static struct vscsiif_request *scsifront_pre_req(struct 
> vscsifrnt_info *info)
>  
>   ring_req = RING_GET_REQUEST(&(info->ring), ring->req_prod_pvt);
>  
> - ring->req_prod_pvt++;
> -
>   ring_req->rqid = (uint16_t)id;
>  
>   return ring_req;
> @@ -196,6 +194,8 @@ static void scsifront_do_request(struct vscsifrnt_info 
> *info)
>   struct vscsiif_front_ring *ring = &(info->ring);
>   int notify;
>  
> + ring->req_prod_pvt++;
> +
>   RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(ring, notify);
>   if (notify)
>   notify_remote_via_irq(info->irq);
> 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [Minios-devel] [PATCH] mini-os: make cscope repair

[Juergen Gross]

On 12/07/16 09:59, Wei Liu wrote:
> On Fri, Jul 01, 2016 at 11:33:11AM +0200, Juergen Gross wrote:
>> "make cscope" doesn't like symbolic link include/mini-os->. as it
>> leads to a file system recursion. Repair that by not following links
>> when searching the sources.
>>
>> Signed-off-by: Juergen Gross 
> 
> Queued.
> 
> Juergen, please CC me on all your mini-os patches so that I know I need
> to commit them when they are acked.

Okay, will do.


Thanks,

Juergen


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 05/16] x86/monitor: relocate code more appropriately

[Corneliu ZUZU]

On 7/12/2016 10:45 AM, Tian, Kevin wrote:

From: Corneliu ZUZU [mailto:cz...@bitdefender.com]
Sent: Monday, July 11, 2016 2:19 PM

+static inline
+void monitor_ctrlreg_adjust_traps(struct domain *d, unsigned int index)
+{
+/* For now, VMX only. */
+ASSERT(cpu_has_vmx);
+
+/* Other CRs than CR3 are always trapped. */
+if ( VM_EVENT_X86_CR3 == index )
+vmx_vm_event_update_cr3_traps(d);

  [Kevin wrote]:

Please add above into a hvm function instead of directly calling
vmx in common file. (other arch can have it unimplemented).
Then you don't need change this common code again later when
other archs are added

---


This is not common code, it's in arch/x86/monitor.c (?) and currently,
as the above ASSERT indicates, only VMX is supported. If in the future
support for SVM for example will be added, then the hvm move you suggest
must be done (Jan also suggested this).
Or, I only now realize, if you guys prefer doing this now I could add a
vm_event_update_cr3_traps field in hvm_function_table, but BUG() in the
SVM one..


The latter is desired. Instead of BUG, it makes more sense to return
error on an arch which doesn't register the callback.

Thanks
Kevin


Will do.

Thanks,
Zuzu C.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] mini-os: replace lib/printf.c with a version not under GPL

[Samuel Thibault]

Juergen Gross, on Mon 04 Jul 2016 11:16:59 +0200, wrote:
> Instead of a Linux kernel based implementation use one from freeBSD.
> 
> As a result some of the printings will change due to more posix like
> behavior of %p format (omitting leading zeroes, prepending "0x").
> 
> Signed-off-by: Juergen Gross 

Acked-by: Samuel Thibault 

> ---
> V2: remove include/lib-gpl.h as requested by Samuel Thibault
> ---
>  blkfront.c|4 -
>  include/lib-gpl.h |   59 --
>  include/lib.h |   27 +-
>  lib/printf.c  | 1744 
> +
>  tpmback.c |4 -
>  5 files changed, 1119 insertions(+), 719 deletions(-)
>  delete mode 100644 include/lib-gpl.h
> 
> diff --git a/blkfront.c b/blkfront.c
> index bdb7765..f747216 100644
> --- a/blkfront.c
> +++ b/blkfront.c
> @@ -17,10 +17,6 @@
>  #include 
>  #include 
>  
> -#ifndef HAVE_LIBC
> -#define strtoul simple_strtoul
> -#endif
> -
>  /* Note: we generally don't need to disable IRQs since we hardly do anything 
> in
>   * the interrupt handler.  */
>  
> diff --git a/include/lib-gpl.h b/include/lib-gpl.h
> deleted file mode 100644
> index d5602b2..000
> --- a/include/lib-gpl.h
> +++ /dev/null
> @@ -1,59 +0,0 @@
> -/* -*-  Mode:C; c-basic-offset:4; tab-width:4 -*-
> - 
> - * (C) 2003 - Rolf Neugebauer - Intel Research Cambridge
> - 
> - *
> - *File: lib.h
> - *  Author: Rolf Neugebauer (neuge...@dcs.gla.ac.uk)
> - * Changes: 
> - *  
> - *Date: Aug 2003
> - * 
> - * Environment: Xen Minimal OS
> - * Description: Random useful library functions, from Linux'
> - * include/linux/kernel.h
> - *
> - *  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, write to the Free Software
> - *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  
> USA
> - */
> -
> -#ifndef _LIB_GPL_H_
> -#define _LIB_GPL_H_
> -
> -#ifndef HAVE_LIBC
> -/* printing */
> -extern unsigned long simple_strtoul(const char *,char **,unsigned int);
> -extern long simple_strtol(const char *,char **,unsigned int);
> -extern unsigned long long simple_strtoull(const char *,char **,unsigned int);
> -extern long long simple_strtoll(const char *,char **,unsigned int);
> -
> -extern int sprintf(char * buf, const char * fmt, ...)
> - __attribute__ ((format (printf, 2, 3)));
> -extern int vsprintf(char *buf, const char *, va_list)
> - __attribute__ ((format (printf, 2, 0)));
> -extern int snprintf(char * buf, size_t size, const char * fmt, ...)
> - __attribute__ ((format (printf, 3, 4)));
> -extern int vsnprintf(char *buf, size_t size, const char *fmt, va_list args)
> - __attribute__ ((format (printf, 3, 0)));
> -extern int scnprintf(char * buf, size_t size, const char * fmt, ...)
> - __attribute__ ((format (printf, 3, 4)));
> -extern int vscnprintf(char *buf, size_t size, const char *fmt, va_list args)
> - __attribute__ ((format (printf, 3, 0)));
> -extern int sscanf(const char *, const char *, ...)
> - __attribute__ ((format (scanf, 2, 3)));
> -extern int vsscanf(const char *, const char *, va_list)
> - __attribute__ ((format (scanf, 2, 0)));
> -#endif
> -
> -#endif /* _LIB_GPL_H_ */
> diff --git a/include/lib.h b/include/lib.h
> index 62836c7..39d6a18 100644
> --- a/include/lib.h
> +++ b/include/lib.h
> @@ -66,11 +66,6 @@
>  #ifdef HAVE_LIBC
>  #include 
>  #include 
> -#else
> -#include 
> -#endif
> -
> -#ifdef HAVE_LIBC
>  #include 
>  #else
>  /* string and memory manipulation */
> @@ -107,6 +102,28 @@ char *strrchr(const char *p, int ch);
>  void *memcpy(void *to, const void *from, size_t len);
>  
>  size_t strnlen(const char *, size_t);
> +
> +unsigned long strtoul(const char *nptr, char **endptr, int base);
> +int64_t strtoq(const char *nptr, char **endptr, int base);
> +uint64_t strtouq(const char *nptr, char **endptr, int base);
> +
> +extern int sprintf(char * buf, const char * fmt, ...)
> +__attribute__ ((format (printf, 2, 3)));
> +extern int vsprintf(char *buf, const char *, va_list)
> +__attribute__ ((format (printf, 2, 0)));
> +extern int snprintf(char * buf, size_t size, const char * fmt, ...)
> +__attribute__ ((format (printf, 3, 4)));
> +extern int vsnprintf(char *buf, size_t size, const 

[Xen-devel] [PATCH v5 2/4] x86/ioreq server: Add new functions to get/set memory types.

[Yu Zhang]

For clarity this patch breaks the code to set/get memory types out
of do_hvm_op() into dedicated functions: hvmop_set/get_mem_type().
Also, for clarity, checks for whether a memory type change is allowed
are broken out into a separate function called by hvmop_set_mem_type().

There is no intentional functional change in this patch.

Signed-off-by: Paul Durrant 
Signed-off-by: Yu Zhang 
Reviewed-by: George Dunlap 
Acked-by: Andrew Cooper 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 

changes in v4: 
  - According to Wei Liu's comments, change the format of the commit
message.
  
changes in v3: 
  - Add Andrew's Acked-by and George's Reviewed-by.

changes in v2: 
  - According to George Dunlap's comments, follow the "set rc /
do something / goto out" pattern in hvmop_get_mem_type().
---
 xen/arch/x86/hvm/hvm.c | 288 +++--
 1 file changed, 161 insertions(+), 127 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 4b51c57..4453ec0 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5345,6 +5345,61 @@ static int do_altp2m_op(
 return rc;
 }
 
+static int hvmop_get_mem_type(
+XEN_GUEST_HANDLE_PARAM(xen_hvm_get_mem_type_t) arg)
+{
+struct xen_hvm_get_mem_type a;
+struct domain *d;
+p2m_type_t t;
+int rc;
+
+if ( copy_from_guest(&a, arg, 1) )
+return -EFAULT;
+
+d = rcu_lock_domain_by_any_id(a.domid);
+if ( d == NULL )
+return -ESRCH;
+
+rc = xsm_hvm_param(XSM_TARGET, d, HVMOP_get_mem_type);
+if ( rc )
+goto out;
+
+rc = -EINVAL;
+if ( !is_hvm_domain(d) )
+goto out;
+
+/*
+ * Use get_gfn query as we are interested in the current
+ * type, not in allocating or unsharing. That'll happen
+ * on access.
+ */
+get_gfn_query_unlocked(d, a.pfn, &t);
+if ( p2m_is_mmio(t) )
+a.mem_type =  HVMMEM_mmio_dm;
+else if ( t == p2m_ioreq_server )
+a.mem_type = HVMMEM_ioreq_server;
+else if ( p2m_is_readonly(t) )
+a.mem_type =  HVMMEM_ram_ro;
+else if ( p2m_is_ram(t) )
+a.mem_type =  HVMMEM_ram_rw;
+else if ( p2m_is_pod(t) )
+a.mem_type =  HVMMEM_ram_rw;
+else if ( p2m_is_grant(t) )
+a.mem_type =  HVMMEM_ram_rw;
+else
+a.mem_type =  HVMMEM_mmio_dm;
+
+rc = -EFAULT;
+if ( __copy_to_guest(arg, &a, 1) )
+goto out;
+rc = 0;
+
+ out:
+rcu_unlock_domain(d);
+
+return rc;
+}
+
 /*
  * Note that this value is effectively part of the ABI, even if we don't need
  * to make it a formal part of it: A guest suspended for migration in the
@@ -5353,6 +5408,107 @@ static int do_altp2m_op(
  */
 #define HVMOP_op_mask 0xff
 
+static bool_t hvm_allow_p2m_type_change(p2m_type_t old, p2m_type_t new)
+{
+if ( p2m_is_ram(old) ||
+ (p2m_is_hole(old) && new == p2m_mmio_dm) ||
+ (old == p2m_ioreq_server && new == p2m_ram_rw) )
+return 1;
+
+return 0;
+}
+
+static int hvmop_set_mem_type(
+XEN_GUEST_HANDLE_PARAM(xen_hvm_set_mem_type_t) arg,
+unsigned long *iter)
+{
+unsigned long start_iter = *iter;
+struct xen_hvm_set_mem_type a;
+struct domain *d;
+int rc;
+
+/* Interface types to internal p2m types */
+static const p2m_type_t memtype[] = {
+[HVMMEM_ram_rw]  = p2m_ram_rw,
+[HVMMEM_ram_ro]  = p2m_ram_ro,
+[HVMMEM_mmio_dm] = p2m_mmio_dm,
+[HVMMEM_unused] = p2m_invalid,
+[HVMMEM_ioreq_server] = p2m_ioreq_server
+};
+
+if ( copy_from_guest(&a, arg, 1) )
+return -EFAULT;
+
+rc = rcu_lock_remote_domain_by_id(a.domid, &d);
+if ( rc != 0 )
+return rc;
+
+rc = -EINVAL;
+if ( !is_hvm_domain(d) )
+goto out;
+
+rc = xsm_hvm_control(XSM_DM_PRIV, d, HVMOP_set_mem_type);
+if ( rc )
+goto out;
+
+rc = -EINVAL;
+if ( a.nr < start_iter ||
+ ((a.first_pfn + a.nr - 1) < a.first_pfn) ||
+ ((a.first_pfn + a.nr - 1) > domain_get_maximum_gpfn(d)) )
+goto out;
+
+if ( a.hvmmem_type >= ARRAY_SIZE(memtype) ||
+ unlikely(a.hvmmem_type == HVMMEM_unused) )
+goto out;
+
+while ( a.nr > start_iter )
+{
+unsigned long pfn = a.first_pfn + start_iter;
+p2m_type_t t;
+
+get_gfn_unshare(d, pfn, &t);
+if ( p2m_is_paging(t) )
+{
+put_gfn(d, pfn);
+p2m_mem_paging_populate(d, pfn);
+rc = -EAGAIN;
+goto out;
+}
+if ( p2m_is_shared(t) )
+{
+put_gfn(d, pfn);
+rc = -EAGAIN;
+goto out;
+}
+if ( !hvm_allow_p2m_type_change(t, memtype[a.hvmmem_type]) )
+{
+put_gfn(d, pfn);
+goto out;
+}
+
+rc = p2m_change_type_one(d, pfn, t, memtype[a.hvmmem_type]);
+put_gfn(d, pfn);
+
+if ( rc )
+goto out;
+
+/* Check for continuation if it's not 

[Xen-devel] [PATCH v5 3/4] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

[Yu Zhang]

A new HVMOP - HVMOP_map_mem_type_to_ioreq_server, is added to
let one ioreq server claim/disclaim its responsibility for the
handling of guest pages with p2m type p2m_ioreq_server. Users
of this HVMOP can specify which kind of operation is supposed
to be emulated in a parameter named flags. Currently, this HVMOP
only support the emulation of write operations. And it can be
further extended to support the emulation of read ones if an
ioreq server has such requirement in the future.

For now, we only support one ioreq server for this p2m type, so
once an ioreq server has claimed its ownership, subsequent calls
of the HVMOP_map_mem_type_to_ioreq_server will fail. Users can also
disclaim the ownership of guest ram pages with p2m_ioreq_server, by
triggering this new HVMOP, with ioreq server id set to the current
owner's and flags parameter set to 0.

Note both HVMOP_map_mem_type_to_ioreq_server and p2m_ioreq_server
are only supported for HVMs with HAP enabled.

Also note that only after one ioreq server claims its ownership
of p2m_ioreq_server, will the p2m type change to p2m_ioreq_server
be allowed.

Signed-off-by: Paul Durrant 
Signed-off-by: Yu Zhang 
Acked-by: Tim Deegan 
---
Cc: Paul Durrant 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: Tim Deegan 

changes in v5:
  - Simplify logic in hvmemul_do_io().
  - Use natual width types instead of fixed width types when possible.
  - Do not grant executable permission for p2m_ioreq_server entries.
  - Clarify comments and commit message.
  - Introduce a seperate patch to recalculate the p2m types after
the ioreq server unmaps the p2m_ioreq_server.

changes in v4:
  - According to Paul's advice, add comments around the definition
of HVMMEM_iore_server in hvm_op.h.
  - According to Wei Liu's comments, change the format of the commit
message.

changes in v3:
  - Only support write emulation in this patch;
  - Remove the code to handle race condition in hvmemul_do_io(),
  - No need to reset the p2m type after an ioreq server has disclaimed
its ownership of p2m_ioreq_server;
  - Only allow p2m type change to p2m_ioreq_server after an ioreq
server has claimed its ownership of p2m_ioreq_server;
  - Only allow p2m type change to p2m_ioreq_server from pages with type
p2m_ram_rw, and vice versa;
  - HVMOP_map_mem_type_to_ioreq_server interface change - use uint16,
instead of enum to specify the memory type;
  - Function prototype change to p2m_get_ioreq_server();
  - Coding style changes;
  - Commit message changes;
  - Add Tim's Acked-by.

changes in v2: 
  - Only support HAP enabled HVMs;
  - Replace p2m_mem_type_changed() with p2m_change_entry_type_global()
to reset the p2m type, when an ioreq server tries to claim/disclaim
its ownership of p2m_ioreq_server;
  - Comments changes.
---
 xen/arch/x86/hvm/emulate.c   | 33 --
 xen/arch/x86/hvm/hvm.c   | 66 +--
 xen/arch/x86/hvm/ioreq.c | 41 ++
 xen/arch/x86/mm/hap/nested_hap.c |  2 +-
 xen/arch/x86/mm/p2m-ept.c|  8 -
 xen/arch/x86/mm/p2m-pt.c | 20 +++
 xen/arch/x86/mm/p2m.c| 74 
 xen/arch/x86/mm/shadow/multi.c   |  3 +-
 xen/include/asm-x86/hvm/ioreq.h  |  2 ++
 xen/include/asm-x86/p2m.h| 29 ++--
 xen/include/public/hvm/hvm_op.h  | 31 -
 11 files changed, 290 insertions(+), 19 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 855af4d..c235a40 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -100,6 +100,7 @@ static int hvmemul_do_io(
 uint8_t dir, bool_t df, bool_t data_is_addr, uintptr_t data)
 {
 struct vcpu *curr = current;
+struct domain *currd = curr->domain;
 struct hvm_vcpu_io *vio = &curr->arch.hvm_vcpu.hvm_io;
 ioreq_t p = {
 .type = is_mmio ? IOREQ_TYPE_COPY : IOREQ_TYPE_PIO,
@@ -141,7 +142,7 @@ static int hvmemul_do_io(
  (p.dir != dir) ||
  (p.df != df) ||
  (p.data_is_ptr != data_is_addr) )
-domain_crash(curr->domain);
+domain_crash(currd);
 
 if ( data_is_addr )
 return X86EMUL_UNHANDLEABLE;
@@ -178,8 +179,34 @@ static int hvmemul_do_io(
 break;
 case X86EMUL_UNHANDLEABLE:
 {
-struct hvm_ioreq_server *s =
-hvm_select_ioreq_server(curr->domain, &p);
+struct hvm_ioreq_server *s;
+
+if ( is_mmio )
+{
+unsigned long gmfn = paddr_to_pfn(addr);
+p2m_type_t p2mt;
+
+(void) get_gfn_query_unlocked(currd, gmfn, &p2mt);
+
+if ( p2mt == p2m_ioreq_server )
+{
+unsigned int flags;
+
+if ( dir != IOREQ_WRITE )
+s = NULL;
+else
+{
+s = p2m_get_ioreq_server

[Xen-devel] [PATCH v5 0/4] x86/ioreq server: Introduce HVMMEM_ioreq_server mem type.

[Yu Zhang]

XenGT leverages ioreq server to track and forward the accesses to GPU 
I/O resources, e.g. the PPGTT(per-process graphic translation tables).
Currently, ioreq server uses rangeset to track the BDF/ PIO/MMIO ranges
to be emulated. To select an ioreq server, the rangeset is searched to
see if the I/O range is recorded. However, number of ram pages to be
tracked may exceed the upper limit of rangeset.

Previously, one solution was proposed to refactor the rangeset, and 
extend its upper limit. However, after 12 rounds discussion, we have
decided to drop this approach due to security concerns. Now this new 
patch series introduces a new mem type, HVMMEM_ioreq_server, and added
hvm operations to let one ioreq server to claim its ownership of ram 
pages with this type. Accesses to a page of this type will be handled
by the specified ioreq server directly. 

Yu Zhang (4):
  x86/ioreq server: Rename p2m_mmio_write_dm to p2m_ioreq_server.
  x86/ioreq server: Add new functions to get/set memory types.
  x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to
an ioreq server.
  x86/ioreq server: Reset outstanding p2m_ioreq_server entries when an
ioreq server unmaps.

 xen/arch/x86/hvm/emulate.c   |  33 +++-
 xen/arch/x86/hvm/hvm.c   | 395 ++-
 xen/arch/x86/hvm/ioreq.c |  41 
 xen/arch/x86/mm/hap/hap.c|   9 +
 xen/arch/x86/mm/hap/nested_hap.c |   2 +-
 xen/arch/x86/mm/p2m-ept.c|  14 +-
 xen/arch/x86/mm/p2m-pt.c |  30 ++-
 xen/arch/x86/mm/p2m.c|  77 
 xen/arch/x86/mm/shadow/multi.c   |   3 +-
 xen/include/asm-x86/hvm/ioreq.h  |   2 +
 xen/include/asm-x86/p2m.h|  36 +++-
 xen/include/public/hvm/hvm_op.h  |  34 +++-
 12 files changed, 528 insertions(+), 148 deletions(-)

-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v5 1/4] x86/ioreq server: Rename p2m_mmio_write_dm to p2m_ioreq_server.

[Yu Zhang]

Previously p2m type p2m_mmio_write_dm was introduced for write-
protected memory pages whose write operations are supposed to be
forwarded to and emulated by an ioreq server. Yet limitations of
rangeset restrict the number of guest pages to be write-protected.

This patch replaces the p2m type p2m_mmio_write_dm with a new name:
p2m_ioreq_server, which means this p2m type can be claimed by one
ioreq server, instead of being tracked inside the rangeset of ioreq
server. And a new memory type, HVMMEM_ioreq_server, is now used in
the HVMOP_set/get_mem_type interface to set/get this p2m type.

Patches following up will add the related HVMOP handling code which
map/unmap type p2m_ioreq_server to/from an ioreq server. Without
following patches, memory type changes to HVMMEM_ioreq_server can
still be allowed, and in such cases, p2m_ioreq_server pages will be
treated the same as ones with previous type p2m_mmio_write_dm, and
are tracked inside the ioreq server's rangeset.

Signed-off-by: Paul Durrant 
Signed-off-by: Yu Zhang 
Acked-by: Tim Deegan 
Acked-by: Andrew Cooper 
Acked-by: George Dunlap 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: George Dunlap 
Cc: Tim Deegan 

changes in v5: 
  - Commit message changes - explained why we can allow memory
type changes to HVMMEM_ioreq_server.
  - Add George's Acked-by.

changes in v4: 
  - According to George's comments, move the HVMMEM_unused part
into a seperate patch(which has already been accepted);
  - Removed George's Reviewed-by because of changes after v3.
  - According to Wei Liu's comments, change the format of the commit
message.

changes in v3: 
  - According to Jan & George's comments, keep HVMMEM_mmio_write_dm
for old xen interface versions, and replace it with HVMMEM_unused
for xen interfaces newer than 4.7.0; For p2m_ioreq_server, a new 
enum - HVMMEM_ioreq_server is introduced for the get/set mem type
interfaces;
  - Add George's Reviewed-by and Acked-by from Tim & Andrew.

changes in v2: 
  - According to George Dunlap's comments, only rename the p2m type,
with no behavior changes.
---
 xen/arch/x86/hvm/hvm.c  | 9 ++---
 xen/arch/x86/mm/p2m-ept.c   | 2 +-
 xen/arch/x86/mm/p2m-pt.c| 2 +-
 xen/arch/x86/mm/shadow/multi.c  | 2 +-
 xen/include/asm-x86/p2m.h   | 4 ++--
 xen/include/public/hvm/hvm_op.h | 5 +++--
 6 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index c89ab6e..4b51c57 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1865,7 +1865,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long 
gla,
  */
 if ( (p2mt == p2m_mmio_dm) || 
  (npfec.write_access &&
-  (p2m_is_discard_write(p2mt) || (p2mt == p2m_mmio_write_dm))) )
+  (p2m_is_discard_write(p2mt) || (p2mt == p2m_ioreq_server))) )
 {
 __put_gfn(p2m, gfn);
 if ( ap2m_active )
@@ -5565,6 +5565,8 @@ long do_hvm_op(unsigned long op, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 get_gfn_query_unlocked(d, a.pfn, &t);
 if ( p2m_is_mmio(t) )
 a.mem_type =  HVMMEM_mmio_dm;
+else if ( t == p2m_ioreq_server )
+a.mem_type = HVMMEM_ioreq_server;
 else if ( p2m_is_readonly(t) )
 a.mem_type =  HVMMEM_ram_ro;
 else if ( p2m_is_ram(t) )
@@ -5595,7 +5597,8 @@ long do_hvm_op(unsigned long op, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 [HVMMEM_ram_rw]  = p2m_ram_rw,
 [HVMMEM_ram_ro]  = p2m_ram_ro,
 [HVMMEM_mmio_dm] = p2m_mmio_dm,
-[HVMMEM_unused] = p2m_invalid
+[HVMMEM_unused] = p2m_invalid,
+[HVMMEM_ioreq_server] = p2m_ioreq_server
 };
 
 if ( copy_from_guest(&a, arg, 1) )
@@ -5644,7 +5647,7 @@ long do_hvm_op(unsigned long op, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 }
 if ( !p2m_is_ram(t) &&
  (!p2m_is_hole(t) || a.hvmmem_type != HVMMEM_mmio_dm) &&
- (t != p2m_mmio_write_dm || a.hvmmem_type != HVMMEM_ram_rw) )
+ (t != p2m_ioreq_server || a.hvmmem_type != HVMMEM_ram_rw) )
 {
 put_gfn(d, pfn);
 goto setmemtype_fail;
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 7166c71..7adc77d 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -171,7 +171,7 @@ static void ept_p2m_type_to_flags(struct p2m_domain *p2m, 
ept_entry_t *entry,
 entry->a = entry->d = !!cpu_has_vmx_ept_ad;
 break;
 case p2m_grant_map_ro:
-case p2m_mmio_write_dm:
+case p2m_ioreq_server:
 entry->r = 1;
 entry->w = entry->x = 0;
 entry->a = !!cpu_has_vmx_ept_ad;
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index 4980934..05aaf8f 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.

[Xen-devel] [PATCH v5 4/4] x86/ioreq server: Reset outstanding p2m_ioreq_server entries when an ioreq server unmaps.

[Yu Zhang]

This patch resets p2m_ioreq_server entries back to p2m_ram_rw,
after an ioreq server has unmapped. The resync is done both
asynchronously with the current p2m_change_entry_type_global()
interface, and synchronously by iterating the p2m table. The
synchronous resetting is necessary because we need to guarantee
the p2m table is clean before another ioreq server is mapped.
And since the sweeping of p2m table could be time consuming,
it is done with hypercall continuation. Asynchronous approach
is also taken so that p2m_ioreq_server entries can also be reset
when the HVM is scheduled between hypercall continuations.

This patch also disallows live migration, when there's still any
outstanding p2m_ioreq_server entry left. The core reason is our
current implementation of p2m_change_entry_type_global() can not
tell the state of p2m_ioreq_server entries(can not decide if an
entry is to be emulated or to be resynced).

Signed-off-by: Yu Zhang 
---
Cc: Paul Durrant 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Jun Nakajima 
Cc: Kevin Tian 
---
 xen/arch/x86/hvm/hvm.c| 52 ---
 xen/arch/x86/mm/hap/hap.c |  9 
 xen/arch/x86/mm/p2m-ept.c |  6 +-
 xen/arch/x86/mm/p2m-pt.c  | 10 +++--
 xen/arch/x86/mm/p2m.c |  3 +++
 xen/include/asm-x86/p2m.h |  5 -
 6 files changed, 78 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 4d98cc6..e57c8b9 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5485,6 +5485,7 @@ static int hvmop_set_mem_type(
 {
 unsigned long pfn = a.first_pfn + start_iter;
 p2m_type_t t;
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
 get_gfn_unshare(d, pfn, &t);
 if ( p2m_is_paging(t) )
@@ -5512,6 +5513,12 @@ static int hvmop_set_mem_type(
 if ( rc )
 goto out;
 
+if ( t == p2m_ram_rw && memtype[a.hvmmem_type] == p2m_ioreq_server )
+p2m->ioreq.entry_count++;
+
+if ( t == p2m_ioreq_server && memtype[a.hvmmem_type] == p2m_ram_rw )
+p2m->ioreq.entry_count--;
+
 /* Check for continuation if it's not the last interation */
 if ( a.nr > ++start_iter && !(start_iter & HVMOP_op_mask) &&
  hypercall_preempt_check() )
@@ -5530,11 +5537,13 @@ static int hvmop_set_mem_type(
 }
 
 static int hvmop_map_mem_type_to_ioreq_server(
-XEN_GUEST_HANDLE_PARAM(xen_hvm_map_mem_type_to_ioreq_server_t) uop)
+XEN_GUEST_HANDLE_PARAM(xen_hvm_map_mem_type_to_ioreq_server_t) uop,
+unsigned long *iter)
 {
 xen_hvm_map_mem_type_to_ioreq_server_t op;
 struct domain *d;
 int rc;
+unsigned long gfn = *iter;
 
 if ( copy_from_guest(&op, uop, 1) )
 return -EFAULT;
@@ -5559,7 +5568,42 @@ static int hvmop_map_mem_type_to_ioreq_server(
 if ( rc != 0 )
 goto out;
 
-rc = hvm_map_mem_type_to_ioreq_server(d, op.id, op.type, op.flags);
+if ( gfn == 0 || op.flags != 0 )
+rc = hvm_map_mem_type_to_ioreq_server(d, op.id, op.type, op.flags);
+
+/*
+ * Iterate p2m table when an ioreq server unmaps from p2m_ioreq_server,
+ * and reset the remaining p2m_ioreq_server entries back to p2m_ram_rw.
+ */
+if ( op.flags == 0 && rc == 0 )
+{
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+while ( gfn <= p2m->max_mapped_pfn )
+{
+p2m_type_t t;
+
+if ( p2m->ioreq.entry_count == 0 )
+break;
+
+get_gfn_unshare(d, gfn, &t);
+
+if ( (t == p2m_ioreq_server) &&
+ !(p2m_change_type_one(d, gfn, t, p2m_ram_rw)) )
+p2m->ioreq.entry_count--;
+
+put_gfn(d, gfn);
+
+/* Check for continuation if it's not the last iteration. */
+if ( ++gfn <= p2m->max_mapped_pfn &&
+ !(gfn & HVMOP_op_mask) &&
+ hypercall_preempt_check() )
+{
+rc = -ERESTART;
+goto out;
+}
+}
+}
 
  out:
 rcu_unlock_domain(d);
@@ -5578,6 +5622,7 @@ long do_hvm_op(unsigned long op, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 break;
 case HVMOP_modified_memory:
 case HVMOP_set_mem_type:
+case HVMOP_map_mem_type_to_ioreq_server:
 mask = HVMOP_op_mask;
 break;
 }
@@ -5607,7 +5652,8 @@ long do_hvm_op(unsigned long op, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 
 case HVMOP_map_mem_type_to_ioreq_server:
 rc = hvmop_map_mem_type_to_ioreq_server(
-guest_handle_cast(arg, xen_hvm_map_mem_type_to_ioreq_server_t));
+guest_handle_cast(arg, xen_hvm_map_mem_type_to_ioreq_server_t),
+&start_iter);
 break;
 
 case HVMOP_set_ioreq_server_state:
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 9c2cd49..0442b1d 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -190,6 +190,15 @@ out:
  

Re: [Xen-devel] [Minios-devel] [PATCH v2] mini-os: replace lib/printf.c with a version not under GPL

[Wei Liu]

On Tue, Jul 12, 2016 at 10:48:50AM +0200, Samuel Thibault wrote:
> Juergen Gross, on Mon 04 Jul 2016 11:16:59 +0200, wrote:
> > Instead of a Linux kernel based implementation use one from freeBSD.
> > 
> > As a result some of the printings will change due to more posix like
> > behavior of %p format (omitting leading zeroes, prepending "0x").
> > 
> > Signed-off-by: Juergen Gross 
> 
> Acked-by: Samuel Thibault 

Queued.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3] xen/arm: enable clocks used by the hypervisor

[Julien Grall]

Hi Mike,

On 08/07/16 18:06, Michael Turquette wrote:

Quoting Julien Grall (2016-07-08 02:34:43)

Hi Dirk,

On 08/07/16 08:44, Dirk Behme wrote:

Xen hypervisor drivers might replace native OS drivers. The result is
that some important clocks that are enabled by the OS in the non-Xen
case are not properly enabled in the presence of Xen. The clocks
property enumerates the clocks that must be enabled by the Xen clock
consumer.

An example is a serial driver enabled by the hypervisor. Xen must


I would say "An example is the UART used by the hypervisor."


consume and enable these clocks in the OS to ensure behavior continues
after firmware configures the UART hardware and corresponding clock
harder.


What do you mean by "harder"?

Also, relying on DOM0 to enable the clock looks very wrong to me and you
give an example which prove that. The UART will be used before hand by
Xen, however it will not be possible to use it if you expect DOM0 to
enable the clock (or even modify the clock frequency).

The clock should be enabled either by the firmware or Xen. But not DOM0.
DOM0 should not touch this clock at all.

Furthermore, this property could be used for clock associated to device
that will be passthrough-ed to a guest. In this case, the clock would be
enabled even if the device is not in use which will result more power
consumption.


Is there a need to pass clock references through to guests? If so the
unmerged CLK_ENABLE_HAND_OFF[0] feature might be useful to you? If this
flag is set on a given clk, it will be enabled at the time it is
registered by the clk provider driver, and it's enable_count reference
counter will be "handed off" to the first consumer that calls clk_get()
and clk_prepare_enable() on it. This means the clock CAN be gated by
it's proper driver, but it will be enabled at boot time as well.


Some driver requires to have the clock in hand to be able to configure 
the clock (such as setting the rate). So we would have to find a way to 
let the guest using the clock either by assigning the clock or some PV 
clock driver.


However, platform device passthrough (i.e non-pci device) cannot be done 
generically. The user has to provide a lots of information manually 
(such as MMIO, IRQ, device tree node...). So I am not sure if we want to 
have a generic solution here.


I though it would be worth to mention it because we may (or not) use 
this clock to tell DOM0 (don't touch it).



This is useful for use cases like splash screens where the bootloader
configures the display and plays some animation, and we want the linux
kernel to take over the display controller hardware without cutting
clocks, blanking or reseting it. Handing off the clock reference count
helps achieve this.


From my understanding, any device used by Xen would be in a similar 
situation, although there will be no driver in Linux. The current patch 
(as well as the v4) is calling clk_prepare_enable for each clock used by 
Xen. Could enabling the clock create unexpected behavior such as the 
UART loosing/dropping characters?


Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 03/17] libxl/arm: Add a configuration option for ARM DomU ACPI

[Julien Grall]

Hi Shannon,

On 12/07/16 04:40, Shannon Zhao wrote:



On 2016/7/7 23:30, Wei Liu wrote:

On Mon, Jun 27, 2016 at 11:40:32AM +0100, Julien Grall wrote:

On 23/06/16 15:34, Shannon Zhao wrote:

On 2016年06月23日 21:39, Stefano Stabellini wrote:

On Thu, 23 Jun 2016, Shannon Zhao wrote:

From: Shannon Zhao 
+if (xlu_cfg_get_defbool(config, "acpi", &b_info->arch_arm.acpi, 0)) {
+libxl_defbool_set(&b_info->arch_arm.acpi, 0);
+}

We cannot share the existing code to parse the acpi paramter because
that is saved in b_info->u.hvm.acpi, right?

Yes.

It's a pity. I wonder if we
could refactor the existing code so that we can actually share the acpi
parameter between x86 and arm.


I have no idea about this since I'm not familiar with this. But is there
any downsides of current way? Because for x86, it will use
b_info->u.hvm.acpi and for ARM it will use b_info->arch_arm.acpi. I
think they don't conflict even though we store it at two places.


Yes, there is a downside.  Toolstack, such as libvirt, would need to have
separate code for x86 and ARM in order to enable/disable ACPI.

I would introduce a new generic acpi parameters, deprecate
b_info->u.hvm.acpi. Ian, Stefano, Wei, any opinions?


Yeah, we can deprecate that field. But we need to take care to not break
users of the old field.

Ok, what name would you suggest?


I would suggest b_info->u.acpi

Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Julien Grall]

Hi Shannon,

On 12/07/16 04:47, Shannon Zhao wrote:

On 2016/7/6 18:12, Stefano Stabellini wrote:

On Wed, 6 Jul 2016, Julien Grall wrote:

On 05/07/16 18:13, Stefano Stabellini wrote:

On Thu, 23 Jun 2016, Julien Grall wrote:

On 23/06/2016 04:17, Shannon Zhao wrote:

From: Shannon Zhao 
+static int xc_dom_copy_acpi(struct xc_dom_image *dom)
+{
+int rc, i;
+uint32_t pages_num = ROUNDUP(dom->acpitable_size, XC_PAGE_SHIFT) >>
+ XC_PAGE_SHIFT;
+const xen_pfn_t base = GUEST_ACPI_BASE >> XC_PAGE_SHIFT;
+xen_pfn_t *p2m;
+void *acpi_pages;
+
+p2m = malloc(pages_num * sizeof(*p2m));
+for (i = 0; i < pages_num; i++)
+p2m[i] = base + i;
+
+rc = xc_domain_populate_physmap_exact(dom->xch, dom->guest_domid,
+  pages_num, 0, 0, p2m);


H... it looks like this is working because libxl is setting the
maximum
size of the domain with some slack (1MB). However, I guess the slack was
for
something else. Wei, Stefano, Ian, can you confirm?


If I recall correctly, the slack is a magic value coming from the
ancient history of toolstacks.


Does it mean we would need to update the slack to take into account the ACPI
blob?

Yes, we need to take into account the ACPI blob. Probably not in the
slack but directly in mam_memkb.

Sorry, I'm not sure understand this. I found the b_info->max_memkb but
didn't find the slack you said. And how to fix this? Update
b_info->max_memkb or the slack?


You can give a look to LIBXL_MAXMEM_CONSTANT.

I am not very familiar with libxl, so I will let Wei and Stefano giving 
you advice on how to fix this.


Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 02/16] x86: fix: make atomic_read() param const

[Andrew Cooper]

On 12/07/16 06:11, Corneliu ZUZU wrote:
> Hi Andrew,
>
> On 7/11/2016 6:18 PM, Andrew Cooper wrote:
>> On 09/07/16 05:12, Corneliu ZUZU wrote:
>>> This wouldn't let me make a param of a function that used
>>> atomic_read() const.
>>>
>>> Signed-off-by: Corneliu ZUZU 
>> This is a good improvement, but you must make an identical adjustment to
>> the arm code, otherwise you will end up with subtle build failures.
>
> Right, didn't even realize it was X86-specific.

It isn't x86 specific.  (Which is what I presume you meant to say.)

>
>>
>> If you are really feeling up to it, having a common xen/atomic.h with
>>
>> typedef struct { int counter; } atomic_t;
>> #define ATOMIC_INIT(i) { (i) }
>>
>> and some prototypes such as:
>>
>> static inline int atomic_read(const atomic_t *v);
>>
>> would be great, but this looks like it has the possibility to turn into
>> a rats nest.  If it does, then just doubling up this code for arm is ok.
>>
>> ~Andrew
>
> Yes, that might be more complicated than we expect and I don't know if
> making code such as this common would be a good idea, usually these
> functions are always architecture-specific.

I only suggested making the prototype common, not the implementation. 
As such, the issue you accidentally introduced would become a hard build
failure on affected architectures, rather than a subtle build failure in
common code at some point in the future.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [Minios-devel] [PATCH v2] mini-os: replace lib/printf.c with a version not under GPL

[Wei Liu]

On Tue, Jul 12, 2016 at 10:19:41AM +0100, Wei Liu wrote:
> On Tue, Jul 12, 2016 at 10:48:50AM +0200, Samuel Thibault wrote:
> > Juergen Gross, on Mon 04 Jul 2016 11:16:59 +0200, wrote:
> > > Instead of a Linux kernel based implementation use one from freeBSD.

Roger has asked me on IRC to s/freeBSD/FreeBSD/. I will do that when I
push this patch.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Data Abort while in booting when using latest version on arm32 fastmodels

[Julien Grall]

On 12/07/16 06:20, Wonseok Ko wrote:

Hi, All


Hello,


I founded the previous post to solve the problem as the same as mine,
the patch was applied in latest version, but I've got the data abort.
previous post:
https://lists.xen.org/archives/html/xen-devel/2013-09/msg00606.html and I 
referred
to the wiki page:
http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/FastModels


This page has not been updated for a while for ARM32. It might be 
possible that the page is out-of-date for the newer models.



I build the latest version of Xen with command as below:
# make distclean; XEN_TARGET_ARCH=arm32
CROSS_COMPILE=arm-linux-gnueabihf- debug=y CONFIG_EARLY_PRINTK=fastmodel
./configure
# make xen XEN_TARGET_ARCH=arm32 CROSS_COMPILE=arm-linux-gnueabihf-
debug=y CONFIG_EARLY_PRINTK=fastmodel -j 8

My fastmodels command as below:

FVP_VE_Cortex-A15x4-A7x4 -acoretile.cluster0.*=./linux-system-semi.axf \

-acoretile.cluster1.*=./linux-system-semi.axf \

-Cmotherboard.smsc_91c111.enabled=1-Cmotherboard.hostbridge.userNetworking=1\

-Ccoretile.dualclustersystemconfigurationblock.CFG_ACTIVECLUSTER=0x3 \

-Ccoretile.cluster0.cpu0.semihosting-cmd_line="\

 --kernel ../xen/xen/xen \

 --module ../linux/arch/arm/boot/zImage \

 --dtb rtsm_ve-cortex_a15x4_a7x4.dtb \

 -- earlyprintk console=ttyAMA0 mem=2048M
root=/dev/nfs nfsroot=192.168.0.8:/srv/nfsroot/ rw ip=dhcp"


This should be the Xen command line and not Linux one.




Does anybody help me to fix it? or If I did something wrong, please let
me know.

here is log:

Trying 127.0.0.1...

Connected to localhost.

Escape character is '^]'.

- UART enabled -

- CPU  booting -

- Xen starting in Hyp mode -

- Zero BSS -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) Checking for initrd in /chosen

(XEN) RAM: 8000 - 

(XEN)

(XEN) MODULE[0]: 80d0230c - 80d0473d Device Tree

(XEN) MODULE[1]: 80a0 - 80d904b8 Kernel
console=ttyAMA0


If I am not mistaken, the Device Tree and the Kernel overlaps in the 
memory. So Xen will try to free twice the same page, hence the data 
abort later one.


I would look into the bootwrapper to find out why the addresses overlap.

[...]


(XEN) Xen call trace:

(XEN)[<0021be40>] page_alloc.c#free_heap_pages+0x2c0/0x428 (PC)

(XEN)[<0021be18>] page_alloc.c#free_heap_pages+0x298/0x428 (LR)

(XEN)[<0021cbb8>] page_alloc.c#init_heap_pages+0x100/0x118

(XEN)[<0021ce78>] init_domheap_pages+0xb0/0xb4

(XEN)[<002549e8>] dt_unreserved_regions+0xf4/0xfc

(XEN)[<0028b378>] discard_initial_modules+0x138/0x178

(XEN)[<0024b1b0>] construct_dom0+0xb24/0xc8c

(XEN)[<0028c12c>] start_xen+0xd38/0xeb0

(XEN)[<00200550>] arm32/head.o#paging+0x94/0xd8


Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 02/16] x86: fix: make atomic_read() param const

[Corneliu ZUZU]

On 7/12/2016 12:42 PM, Andrew Cooper wrote:

On 12/07/16 06:11, Corneliu ZUZU wrote:

Hi Andrew,

On 7/11/2016 6:18 PM, Andrew Cooper wrote:

On 09/07/16 05:12, Corneliu ZUZU wrote:

This wouldn't let me make a param of a function that used
atomic_read() const.

Signed-off-by: Corneliu ZUZU 

This is a good improvement, but you must make an identical adjustment to
the arm code, otherwise you will end up with subtle build failures.

Right, didn't even realize it was X86-specific.

It isn't x86 specific.  (Which is what I presume you meant to say.)


Heh, yes, depends how you look at it, I was referring precisely to (the 
implementation of) the function I've modified (which was X86-specific, 
called from common, which meant there's an ARM one as well).





If you are really feeling up to it, having a common xen/atomic.h with

typedef struct { int counter; } atomic_t;
#define ATOMIC_INIT(i) { (i) }

and some prototypes such as:

static inline int atomic_read(const atomic_t *v);

would be great, but this looks like it has the possibility to turn into
a rats nest.  If it does, then just doubling up this code for arm is ok.

~Andrew

Yes, that might be more complicated than we expect and I don't know if
making code such as this common would be a good idea, usually these
functions are always architecture-specific.

I only suggested making the prototype common, not the implementation.
As such, the issue you accidentally introduced would become a hard build
failure on affected architectures, rather than a subtle build failure in
common code at some point in the future.

~Andrew



Oh, I see, good idea, I've just tested it and it works, what did you 
have in mind when you said it could cause problems?


Zuzu C.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi

[Julien Grall]

Hi Fu Wei,

On 06/07/16 18:53, fu@linaro.org wrote:

From: Fu Wei 

delete: xen_linux, xen_initrd, xen_xsm
add: xen_module

This update bases on
 commit 0edd750e50698854068358ea53528100a9192902
 Author: Vladimir Serbinenko 
 Date:   Fri Jan 22 10:18:47 2016 +0100

 xen_boot: Remove obsolete module type distinctions.

Also bases on the module loading mechanism of Xen code:
488c2a8 docs/arm64: clarify the documention for loading XSM support
67831c4 docs/arm64: update the documentation for loading XSM support
ca32012 xen/arm64: check XSM Magic from the second unknown module.

Signed-off-by: Fu Wei 


Reviewed-by: Julien Grall 

Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 3/4] * util/grub.d/20_linux_xen.in: Add xen_boot command support

[Julien Grall]

Hi Fu Wei,

On 06/07/16 18:53, fu@linaro.org wrote:

From: Fu Wei 

This patch adds the support of xen_boot command:
 xen_hypervisor
 xen_module

Also add a new "feature_xen_boot" to indicate this grub support
xen_boot command.

Signed-off-by: Fu Wei 
---
  grub-core/normal/main.c |  2 +-
  util/grub.d/20_linux_xen.in | 13 ++---
  2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/grub-core/normal/main.c b/grub-core/normal/main.c
index 78a70a8..3402a05 100644
--- a/grub-core/normal/main.c
+++ b/grub-core/normal/main.c
@@ -488,7 +488,7 @@ static const char *features[] = {
"feature_chainloader_bpb", "feature_ntldr", "feature_platform_search_hint",
"feature_default_font_path", "feature_all_video_module",
"feature_menuentry_id", "feature_menuentry_options", "feature_200_final",
-  "feature_nativedisk_cmd", "feature_timeout_style"
+  "feature_nativedisk_cmd", "feature_timeout_style", "feature_xen_boot"
  };

  GRUB_MOD_INIT(normal)
diff --git a/util/grub.d/20_linux_xen.in b/util/grub.d/20_linux_xen.in
index c48af94..6a88a39 100644
--- a/util/grub.d/20_linux_xen.in
+++ b/util/grub.d/20_linux_xen.in
@@ -122,16 +122,23 @@ linux_entry ()
  else
  xen_rm_opts="no-real-mode edd=off"
  fi
-   multiboot   ${rel_xen_dirname}/${xen_basename} placeholder 
${xen_args} \${xen_rm_opts}
+if [ "x\$feature_xen_boot" != xy ]; then
+xen_loader="multiboot"
+module_loader="module"
+else
+xen_loader="xen_hypervisor"
+module_loader="xen_module"
+fi
+   \${xen_loader}  ${rel_xen_dirname}/${xen_basename} placeholder 
${xen_args} \${xen_rm_opts}


What is the coding style for grub? This line is using hard tabs, but the 
previous one are using soft tab.



echo'$(echo "$lmessage" | grub_quote)'
-   module  ${rel_dirname}/${basename} placeholder 
root=${linux_root_device_thisversion} ro ${args}
+   \${module_loader}   ${rel_dirname}/${basename} placeholder 
root=${linux_root_device_thisversion} ro ${args}
  EOF
if test -n "${initrd}" ; then
  # TRANSLATORS: ramdisk isn't identifier. Should be translated.
  message="$(gettext_printf "Loading initial ramdisk ...")"
  sed "s/^/$submenu_indentation/" << EOF
echo'$(echo "$message" | grub_quote)'
-   module  --nounzip   ${rel_dirname}/${initrd}
+   \${module_loader} --nounzip ${rel_dirname}/${initrd}
  EOF
fi
sed "s/^/$submenu_indentation/" << EOF



Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 02/16] x86: fix: make atomic_read() param const

[Andrew Cooper]

On 12/07/16 11:11, Corneliu ZUZU wrote:
>
>>
 If you are really feeling up to it, having a common xen/atomic.h with

 typedef struct { int counter; } atomic_t;
 #define ATOMIC_INIT(i) { (i) }

 and some prototypes such as:

 static inline int atomic_read(const atomic_t *v);

 would be great, but this looks like it has the possibility to turn
 into
 a rats nest.  If it does, then just doubling up this code for arm
 is ok.

 ~Andrew
>>> Yes, that might be more complicated than we expect and I don't know if
>>> making code such as this common would be a good idea, usually these
>>> functions are always architecture-specific.
>> I only suggested making the prototype common, not the implementation.
>> As such, the issue you accidentally introduced would become a hard build
>> failure on affected architectures, rather than a subtle build failure in
>> common code at some point in the future.
>>
>> ~Andrew
>>
>
> Oh, I see, good idea, I've just tested it and it works, what did you
> have in mind when you said it could cause problems?

The build issues would come at some point later when someone attempts to
atomic_read() a constant atomic_t in common code, when the ARM build
would break.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/4] boot-wrapper: arm64: Xen support

[Julien Grall]

Hi Andre,

On 20/06/16 16:09, Andre Przywara wrote:

These patches allow to include a Xen hypervisor binary into a boot-wrapper
ELF file, so that a Foundation Platform or a Fast Model can boot a Xen
system (including a Dom0 kernel).
This has been floating around for a while, I just updated the patches
to apply on the latest boot-wrapper tree. Also I increased Xen's load
address to accomodate for Dom0 kernels bigger than 16 MB.
For testing this just add: "--with-xen=/path/to/xen/xen/xen" to the
./configure command line and feed the resulting xen-system.axf file to
the model.


Tested-by: Julien Grall 

Regards,


Cheers,
Andre.

Christoffer Dall (3):
   Support for building in a Xen binary
   Xen: Support adding DT nodes
   Explicitly clean linux-system.axf and xen-system.axf

Ian Campbell (1):
   Xen: Select correct dom0 console

  .gitignore|  1 +
  Makefile.am   | 38 +-
  boot_common.c |  4 ++--
  configure.ac  | 26 +-
  model.lds.S   | 14 ++
  5 files changed, 67 insertions(+), 16 deletions(-)



--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 02/16] x86: fix: make atomic_read() param const

[Corneliu ZUZU]

On 7/12/2016 1:22 PM, Andrew Cooper wrote:

On 12/07/16 11:11, Corneliu ZUZU wrote:

If you are really feeling up to it, having a common xen/atomic.h with

typedef struct { int counter; } atomic_t;
#define ATOMIC_INIT(i) { (i) }

and some prototypes such as:

static inline int atomic_read(const atomic_t *v);

would be great, but this looks like it has the possibility to turn
into
a rats nest.  If it does, then just doubling up this code for arm
is ok.

~Andrew

Yes, that might be more complicated than we expect and I don't know if
making code such as this common would be a good idea, usually these
functions are always architecture-specific.

I only suggested making the prototype common, not the implementation.
As such, the issue you accidentally introduced would become a hard build
failure on affected architectures, rather than a subtle build failure in
common code at some point in the future.

~Andrew


Oh, I see, good idea, I've just tested it and it works, what did you
have in mind when you said it could cause problems?

The build issues would come at some point later when someone attempts to
atomic_read() a constant atomic_t in common code, when the ARM build
would break.

~Andrew


Sorry, could you rephrase this? When the ARM build would break (i.e. 
fail, I presume) because of what?


Zuzu C.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 02/16] x86: fix: make atomic_read() param const

[Corneliu ZUZU]

On 7/12/2016 1:22 PM, Andrew Cooper wrote:

On 12/07/16 11:11, Corneliu ZUZU wrote:

If you are really feeling up to it, having a common xen/atomic.h with

typedef struct { int counter; } atomic_t;
#define ATOMIC_INIT(i) { (i) }

and some prototypes such as:

static inline int atomic_read(const atomic_t *v);

would be great, but this looks like it has the possibility to turn
into
a rats nest.  If it does, then just doubling up this code for arm
is ok.

~Andrew

Yes, that might be more complicated than we expect and I don't know if
making code such as this common would be a good idea, usually these
functions are always architecture-specific.

I only suggested making the prototype common, not the implementation.
As such, the issue you accidentally introduced would become a hard build
failure on affected architectures, rather than a subtle build failure in
common code at some point in the future.

~Andrew


Oh, I see, good idea, I've just tested it and it works, what did you
have in mind when you said it could cause problems?

The build issues would come at some point later when someone attempts to
atomic_read() a constant atomic_t in common code, when the ARM build
would break.

~Andrew


Ooh, no, I was asking what you meant when you said "this looks like it 
has the possibility to turn into a rats nest" in your first message, not 
the thing about hard build failure..


Zuzu C.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/4] Support for building in a Xen binary

[Julien Grall]

Hi Andre,

On 20/06/16 16:09, Andre Przywara wrote:

diff --git a/Makefile.am b/Makefile.am
index 692d2cc..1a801c0 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -85,7 +85,6 @@ TEXT_LIMIT:= 0x8008
  endif

  LD_SCRIPT := model.lds.S
-IMAGE  := linux-system.axf

  FS_OFFSET := 0x1000
  FILESYSTEM_START:= $(shell echo $$(($(PHYS_OFFSET) + $(FS_OFFSET
@@ -108,6 +107,11 @@ CHOSEN_NODE:= chosen { 
\
   };
  endif

+if XEN
+XEN:= -DXEN=$(XEN_IMAGE)
+XEN_OFFSET := 0x0820
+endif
+
  CPPFLAGS  += $(INITRD_FLAGS)
  CFLAGS+= -Iinclude/ -I$(ARCH_SRC)/include/
  CFLAGS+= -Wall -fomit-frame-pointer
@@ -117,11 +121,11 @@ LDFLAGS   += --gc-sections
  OFILES+= boot_common.o bakery_lock.o platform.o $(GIC) 
cache.o lib.o
  OFILES+= $(addprefix $(ARCH_SRC),boot.o stack.o $(BOOTMETHOD) 
utils.o)

-all: $(IMAGE)
+all: $(IMAGE) $(XIMAGE)


I cannot find where XIMAGE is set. What XIMAGE is used for?

Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/4] Xen: Support adding DT nodes

[Julien Grall]

Hi Andre,

On 20/06/16 16:09, Andre Przywara wrote:

From: Christoffer Dall 

Support adding xen,xen-bootargs node via --with-xen-bootargs to the
configure script and automatically add the Dom0 node to the DT as well.

Signed-off-by: Christoffer Dall 
Signed-off-by: Andre Przywara 
---
  Makefile.am  | 34 +-
  configure.ac |  9 +
  2 files changed, 30 insertions(+), 13 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 1a801c0..d83b417 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -93,24 +93,32 @@ FILESYSTEM_END  := $(shell echo $$(($(FILESYSTEM_START) 
+ $(FILESYSTEM_SIZE

  FDT_OFFSET:= 0x0800

+if XEN
+XEN:= -DXEN=$(XEN_IMAGE)
+XEN_OFFSET := 0x0820
+KERNEL_SIZE:= $(shell stat -Lc %s $(KERNEL_IMAGE) 2>/dev/null || echo 0)
+DOM0_OFFSET:= $(shell echo $$(($(PHYS_OFFSET) + $(KERNEL_OFFSET
+XEN_BOOTARGS   := xen,xen-bootargs = \"$(BOOTARGS)\";\


I would prefer BOOTARGS with XEN_ to avoid confusion.


+  \#address-cells = <2>; \
+  \#size-cells = <2>;\
+  module@1 {   \
+   compatible = \"xen,linux-zimage\", 
\"xen,multiboot-module\"; \
+   reg = <0x0 $(DOM0_OFFSET) 0x0 $(KERNEL_SIZE)>;\
+  };
+endif
+
+
  if INITRD
  INITRD_FLAGS  := -DUSE_INITRD
+INITRD_CHOSEN   := linux,initrd-start = <$(FILESYSTEM_START)>;   \
+  linux,initrd-end = <$(FILESYSTEM_END)>;
+endif
+
  CHOSEN_NODE   := chosen { \
bootargs = \"$(CMDLINE)\";\
-   linux,initrd-start = <$(FILESYSTEM_START)>;   \
-   linux,initrd-end = <$(FILESYSTEM_END)>;   \
-  };
-else
-INITRD_FLAGS   :=
-CHOSEN_NODE:= chosen { \
-   bootargs = \"$(CMDLINE)\";\
+   $(INITRD_CHOSEN)\
+   $(XEN_BOOTARGS) \
   };
-endif
-
-if XEN
-XEN:= -DXEN=$(XEN_IMAGE)
-XEN_OFFSET := 0x0820
-endif


This code was added in the previous patch. Can you add the code in the 
correct place directly in patch #1?




  CPPFLAGS  += $(INITRD_FLAGS)
  CFLAGS+= -Iinclude/ -I$(ARCH_SRC)/include/
diff --git a/configure.ac b/configure.ac
index 2441f8b..b001939 100644
--- a/configure.ac
+++ b/configure.ac
@@ -95,6 +95,12 @@ AC_ARG_WITH([cmdline],
[C_CMDLINE=$withval])
  AC_SUBST([CMDLINE], [$C_CMDLINE])

+X_BOOTARGS="console=dtuart dtuart=serial0 no-bootscrub"
+AC_ARG_WITH([xen-bootargs],


I would name the option xen-cmdline to stay inline with the kernel one.


+   AS_HELP_STRING([--with-xen-bootargs], [set Xen bootargs]),
+   [X_BOOTARGS=$withval])
+AC_SUBST([BOOTARGS], [$X_BOOTARGS])
+
  # Allow a user to pass --enable-gicv3
  AC_ARG_ENABLE([gicv3],
AS_HELP_STRING([--enable-gicv3], [enable GICv3 instead of GICv2]),
@@ -133,4 +139,7 @@ echo "  Use GICv3? ${USE_GICV3}"
  echo "  Boot-wrapper execution state:  AArch${BOOTWRAPPER_ES}"
  echo "  Kernel execution state:AArch${KERNEL_ES}"
  echo "  Xen image  ${X_IMAGE:-NONE}"
+if test "x${X_IMAGE}" != "x"; then
+echo "  Xen Bootargs:  ${X_BOOTARGS}"


Same suggestion here "Xen command line".


+fi
  echo ""



Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 3/4] Xen: Select correct dom0 console

[Julien Grall]

Hi Andrew,

On 20/06/16 16:09, Andre Przywara wrote:

From: Ian Campbell 

If Xen is enabled, tell Dom0 to use the 'hvc0' console, and fall back to
the usual ttyAMA0 otherwise.

Signed-off-by: Ian Campbell 
Signed-off-by: Christoffer Dall 
Signed-off-by: Andre Przywara 


Reviewed-by: Julien Grall 

Regards,


---
  configure.ac | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index b001939..f381a80 100644
--- a/configure.ac
+++ b/configure.ac
@@ -89,7 +89,8 @@ AC_ARG_WITH([initrd],
  AC_SUBST([FILESYSTEM], [$USE_INITRD])
  AM_CONDITIONAL([INITRD], [test "x$USE_INITRD" != "x"])

-C_CMDLINE="console=ttyAMA0 earlyprintk=pl011,0x1c09"
+AS_IF([test "x$X_IMAGE" = "x"],[C_CONSOLE="ttyAMA0"],[C_CONSOLE="hvc0"])
+C_CMDLINE="console=$C_CONSOLE earlyprintk=pl011,0x1c09"
  AC_ARG_WITH([cmdline],
AS_HELP_STRING([--with-cmdline], [set a command line for the kernel]),
[C_CMDLINE=$withval])



--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 4/4] Explicitly clean linux-system.axf and xen-system.axf

[Julien Grall]

Hi Andre,

On 20/06/16 16:09, Andre Przywara wrote:

From: Christoffer Dall 

When doing a make clean, only the output image currently configured to
build is being removed.  However, one would expect all build artifacts
to be removed when doing a 'make clean' and when switching between Xen
and Linux builds, it is easy to accidentally run an older build than
intended.  Simply hardcode the axf image file names.

Signed-off-by: Christoffer Dall 
Signed-off-by: Andre Przywara 


Reviewed-by: Julien Grall 

Regards,


---
  Makefile.am | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index d83b417..cd022e9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -131,7 +131,7 @@ OFILES  += $(addprefix $(ARCH_SRC),boot.o 
stack.o $(BOOTMETHOD) utils.o)

  all: $(IMAGE) $(XIMAGE)

-CLEANFILES = $(IMAGE) $(OFILES) model.lds fdt.dtb
+CLEANFILES = $(IMAGE) linux-system.axf xen-system.axf $(OFILES) model.lds 
fdt.dtb

  $(IMAGE): $(OFILES) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM) 
$(XEN_IMAGE)
$(LD) $(LDFLAGS) $(OFILES) -o $@ --script=model.lds



--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 03/17] libxl/arm: Add a configuration option for ARM DomU ACPI

[Wei Liu]

On Tue, Jul 12, 2016 at 10:22:39AM +0100, Julien Grall wrote:
[...]
> >>Yeah, we can deprecate that field. But we need to take care to not break
> >>users of the old field.
> >Ok, what name would you suggest?
> 
> I would suggest b_info->u.acpi
> 

b_info->acpi would be more appropriate.

diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index ef614be..a57823d 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -494,11 +494,16 @@ libxl_domain_build_info = Struct("domain_build_info",[
 # Note that the partial device tree should avoid to use the phandle
 # 65000 which is reserved by the toolstack.
 ("device_tree",  string),
+("acpi", libxl_defbool),
 ("u", KeyedUnion(None, libxl_domain_type, "type",
 [("hvm", Struct(None, [("firmware", string),
("bios", libxl_bios_type),
("pae",  libxl_defbool),
("apic", libxl_defbool),
+   # The following acpi field is
+   # deprecated. Please use the unified
+   # acpi field above which works for both
+   # x86 and ARM.
("acpi", libxl_defbool),
("acpi_s3",  libxl_defbool),
("acpi_s4",  libxl_defbool),


And then:

1. modify xl to set the new field.
2. modify libxl to handle compatibility: user of the old field should
   continue to work.

I know this is a bit terse. Feel free to ask questions if you have any
doubt.

Wei.

> Regards,
> 
> -- 
> Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Wei Liu]

On Tue, Jul 12, 2016 at 11:47:04AM +0800, Shannon Zhao wrote:
> 
> 
> On 2016/7/6 18:12, Stefano Stabellini wrote:
> > On Wed, 6 Jul 2016, Julien Grall wrote:
> >> > Hi Stefano,
> >> > 
> >> > On 05/07/16 18:13, Stefano Stabellini wrote:
> >>> > > On Thu, 23 Jun 2016, Julien Grall wrote:
>  > > > On 23/06/2016 04:17, Shannon Zhao wrote:
> > > > > > From: Shannon Zhao 
> > > > > > 
> > > > > > Copy all the ACPI tables to guest space so that UEFI or guest 
> > > > > > could
> > > > > > access them.
> > > > > > 
> > > > > > Signed-off-by: Shannon Zhao 
> > > > > > ---
> > > > > >   tools/libxc/xc_dom_arm.c | 51
> > > > > > 
> > > > > >   1 file changed, 51 insertions(+)
> > > > > > 
> > > > > > diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
> > > > > > index 64a8b67..6a0a5b7 100644
> > > > > > --- a/tools/libxc/xc_dom_arm.c
> > > > > > +++ b/tools/libxc/xc_dom_arm.c
> > > > > > @@ -63,6 +63,47 @@ static int setup_pgtables_arm(struct 
> > > > > > xc_dom_image
> > > > > > *dom)
> > > > > > 
> > > > > >   /*
> > > > > > 
> > > > > > */
> > > > > > 
> > > > > > +static int xc_dom_copy_acpi(struct xc_dom_image *dom)
> > > > > > +{
> > > > > > +int rc, i;
> > > > > > +uint32_t pages_num = ROUNDUP(dom->acpitable_size, 
> > > > > > XC_PAGE_SHIFT) >>
> > > > > > + XC_PAGE_SHIFT;
> > > > > > +const xen_pfn_t base = GUEST_ACPI_BASE >> XC_PAGE_SHIFT;
> > > > > > +xen_pfn_t *p2m;
> > > > > > +void *acpi_pages;
> > > > > > +
> > > > > > +p2m = malloc(pages_num * sizeof(*p2m));
> > > > > > +for (i = 0; i < pages_num; i++)
> > > > > > +p2m[i] = base + i;
> > > > > > +
> > > > > > +rc = xc_domain_populate_physmap_exact(dom->xch, 
> > > > > > dom->guest_domid,
> > > > > > +  pages_num, 0, 0, 
> > > > > > p2m);
>  > > > 
>  > > > H... it looks like this is working because libxl is setting the
>  > > > maximum
>  > > > size of the domain with some slack (1MB). However, I guess the 
>  > > > slack was
>  > > > for
>  > > > something else. Wei, Stefano, Ian, can you confirm?
> >>> > > 
> >>> > > If I recall correctly, the slack is a magic value coming from the
> >>> > > ancient history of toolstacks.
> >> > 
> >> > Does it mean we would need to update the slack to take into account the 
> >> > ACPI
> >> > blob?
> > Yes, we need to take into account the ACPI blob. Probably not in the
> > slack but directly in mam_memkb.
> Sorry, I'm not sure understand this. I found the b_info->max_memkb but
> didn't find the slack you said. And how to fix this? Update
> b_info->max_memkb or the slack?

Can you calculate the size of your payload and add that to max_memkb?

Don't bump the slack.

Wei.

> 
> Thanks,
> -- 
> Shannon
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 05/17] libxl/arm: Generate static ACPI DSDT table

[Wei Liu]

On Tue, Jul 12, 2016 at 11:50:32AM +0800, Shannon Zhao wrote:
> 
> 
> On 2016/7/7 23:52, Wei Liu wrote:
> > On Tue, Jul 05, 2016 at 11:12:35AM +0800, Shannon Zhao wrote:
> >> > From: Shannon Zhao 
> >> > 
> >> > It uses static DSDT table like the way x86 uses. Currently the DSDT
> >> > table only contains processor device objects and it generates the
> >> > maximal objects which so far is 128.
> >> > 
> >> > Signed-off-by: Shannon Zhao 
> >> > ---
> >> >  tools/libacpi/Makefile| 15 -
> >> >  tools/libacpi/mk_dsdt.c   | 51 
> >> > ---
> >> >  tools/libxl/Makefile  |  5 -
> >> >  tools/libxl/libxl_arm_acpi.c  |  5 +
> >> >  xen/include/public/arch-arm.h |  3 +++
> >> >  5 files changed, 64 insertions(+), 15 deletions(-)
> >> > 
> >> > diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
> >> > index 4068d9a..0401810 100644
> >> > --- a/tools/libacpi/Makefile
> >> > +++ b/tools/libacpi/Makefile
> >> > @@ -22,6 +22,7 @@ MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
> >> >  # Sources to be generated
> >> >  C_SRC = $(ACPI_BUILD_DIR)/dsdt_anycpu.c $(ACPI_BUILD_DIR)/dsdt_15cpu.c 
> >> >  C_SRC += $(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.c 
> >> > $(ACPI_BUILD_DIR)/dsdt_pvh.c
> >> > +C_SRC += $(ACPI_BUILD_DIR)/dsdt_anycpu_arm.c
> >> >  H_SRC = $(ACPI_BUILD_DIR)/ssdt_s3.h $(ACPI_BUILD_DIR)/ssdt_s4.h 
> >> > $(ACPI_BUILD_DIR)/ssdt_pm.h $(ACPI_BUILD_DIR)/ssdt_tpm.h
> >> >  
> >> >  vpath iasl $(PATH)
> >> > @@ -35,7 +36,7 @@ $(H_SRC): $(ACPI_BUILD_DIR)/%.h: %.asl iasl
> >> >  cd $(CURDIR)
> >> >  
> >> >  $(MK_DSDT): mk_dsdt.c
> >> > -$(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c
> >> > +$(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -D__XEN_TOOLS__ -o 
> >> > $@ mk_dsdt.c
> > Why is this needed? Which unstable hypervisor interface you need in
> > order to build this?
> It needs GUEST_MAX_VCPUS in mk_dsdt.c while the GUEST_MAX_VCPUS is
> defined under #if defined(__XEN__) || defined(__XEN_TOOLS__) in
> xen/include/public/arch-arm.h
> 

OK. Let me elaborate a bit on this.

The two macros basically imply everything enclosed in them is subject to
change. I guess I can live with this because this is not a public facing
interface for library users.

Can you ack or nack my assessment?

Wei.

> Thanks,
> -- 
> Shannon
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH] x86, hvm: document the de facto policy for vCPU ids

[Vitaly Kuznetsov]

PVHVM guests may need to know Xen's idea of vCPU ids they have and the
only way they can figure them out is to use ACPI ids from MADT table.
Document the de facto policy.

Signed-off-by: Vitaly Kuznetsov 
---
 xen/include/public/hvm/hvm_info_table.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/xen/include/public/hvm/hvm_info_table.h 
b/xen/include/public/hvm/hvm_info_table.h
index 9e3f807..08c252e 100644
--- a/xen/include/public/hvm/hvm_info_table.h
+++ b/xen/include/public/hvm/hvm_info_table.h
@@ -34,6 +34,14 @@
 /* Maximum we can support with current vLAPIC ID mapping. */
 #define HVM_MAX_VCPUS128
 
+/*
+ * In some cases SMP HVM guests may require knowledge of Xen's idea of vCPU ids
+ * for their vCPUs. For example, HYPERVISOR_vcpu_op and some EVTCHNOP_*
+ * hypercalls take vcpu id as a parameter. It is valid for HVM guests to assume
+ * that Xen's vCPU id always equals to ACPI (not APIC!) id in MADT table which
+ * is always present for SMP guests.
+ */
+
 struct hvm_info_table {
 charsignature[8]; /* "HVM INFO" */
 uint32_tlength;
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Data Abort while in booting when using latest version on arm32 fastmodels

[Wonseok Ko]

Thank you for your help, Julien

I found the memory overlapping problem between Kernel and Device Tree in
bootwrapper.
The problem came from INITRD_OFFSET and PHYS_OFFSET macro(0x00d0)
I fixed these offsets from 0x00d0 to 0x00e0 and then I avoided the
memory overlapping problem:

(XEN) MODULE[0]: 80e0230c - 80e04731 Device Tree
(XEN) MODULE[1]: 80a0 - 80d904b8 Kernel
console=hvc0 earlyprintk=xen debug mem=2048M root=/dev/mmcblk0 rw ip=dhcp


However, I've got another error as below:

(XEN) Checking for initrd in /chosen
(XEN) RAM: 8000 - 
(XEN)
(XEN) MODULE[0]: 80e0230c - 80e04731 Device Tree
(XEN) MODULE[1]: 80a0 - 80d904b8 Kernel
console=hvc0 earlyprintk=xen debug mem=2048M root=/dev/mmcblk0 rw ip=dhcp

(XEN)
(XEN) Command line: earlyprintk console=ttyAMA0
(XEN) Placing Xen at 0xffe0-0x0001
(XEN) Update BOOTMOD_XEN from 8020-802fd781 =>
ffe0-ffefd781
(XEN) Xen heap: fa00-fe00 (16384 pages)
(XEN) Dom heap: 507904 pages
(XEN) Domain heap initialised
(XEN) Platform: VERSATILE EXPRESS
(XEN) Bad console= option 'ttyAMA0'
 Xen 4.8-unstable
(XEN) Xen version 4.8-unstable (wonseok@) (arm-linux-gnueabihf-gcc
(crosstool-NG linaro-1.13.1-4.7-2013.03-20130313 - Linaro GCC 2013.03)
4.7.3 20130226 (prerelease)) debug=y Tue Jul 12 19:59:29 KST 2016
(XEN) Latest ChangeSet: Thu Jun 30 14:01:02 2016 +0200 git:bb4f41b-dirty
(XEN) Processor: 412fc0f0: "ARM Limited", variant: 0x2, part 0xc0f, rev 0x0
(XEN) 32-bit Execution:
(XEN)   Processor Features: 1131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle
(XEN) Extensions: GenericTimer Security
(XEN)   Debug Features: 02010555
(XEN)   Auxiliary Features: 
(XEN)   Memory Model Features: 10201105 2000 0124 02102211
(XEN)  ISA Features: 02101110 13112111 21232041 2131 10011142 
(XEN) Set SYS_FLAGS to ffe0004c (0020004c)
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 24000 KHz
(XEN) GICv2 initialization:
(XEN) gic_dist_addr=2c001000
(XEN) gic_cpu_addr=2c002000
(XEN) gic_hyp_addr=2c004000
(XEN) gic_vcpu_addr=2c006000
(XEN) gic_maintenance_irq=25
(XEN) GICv2: 128 lines, 8 cpus, secure (IID 3902043b).
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Allocated console ring of 64 KiB.
(XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
(XEN) Bringing up CPU1
- CPU 0001 booting -
- Xen starting in Hyp mode -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 2 booted.
(XEN) Bringing up CPU3
- CPU 0003 booting -
- Xen starting in Hyp mode -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 3 booted.
(XEN) Bringing up CPU4
- CPU 0100 booting -
- Xen starting in Hyp mode -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 4 booted.
(XEN) Bringing up CPU5
- CPU 0101 booting -
- Xen starting in Hyp mode -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 5 booted.
(XEN) Bringing up CPU6
- CPU 0102 booting -
- Xen starting in Hyp mode -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 6 booted.
(XEN) Bringing up CPU7
(XEN) CPU7 never came online
(XEN) Failed to bring up CPU 7 (error -5)
(XEN) Brought up 7 CPUs
(XEN) P2M: 40-bit IPA
(XEN) P2M: 3 levels with order-1 root, VTCR 0x80003558
(XEN) I/O virtualisation disabled
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Loading kernel from boot module @ 80a0
(XEN) Allocating 1:1 mappings totalling 128MB for dom0:
(XEN) BANK[0] 0x008800-0x009000 (128MB)
(XEN) Grant table range: 0x00ffe0-0x00ffe5d000
(XEN) Loading zImage from 80a0 to
8fc0-8ff904b8
(XEN) Allocating PPI 16 for event channel interrupt
(XEN) Loading dom0 DTB to 0x8fa0-0x8fa0220e
(XEN) Scrubbing Free RAM on 1 nodes using 7 CPUs
(XEN) ...done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input
to Xen)
(XEN) Freed 268kB init memory.
(XEN) traps.c:2506:d0v0 HSR=0x9045 pc=0x80341924 gva=0xefffe000
gpa=0x00f7ffe000

Could you please explain the reason why the above fault?

Thanks,
Wonseok



Thanks,
Wonseok.

2016-07-12 19:09 GMT+09:00 Julien Grall :

>
>
> On 12/07/16 06:20, Wonseok Ko wrote:
>
>> Hi, All
>>
>
> Hello,
>
> I founded the previous post to solve the problem as the same as mine,
>> the patch was applied in latest version, but I've got the data abort.
>> previous post:
>> https://lists.xen.org/archives/html/xen-devel/2013-09/msg00606.html and
>> I referred
>> to the wiki page:
>> http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensio

Re: [Xen-devel] linux-next: manual merge of the xen-tip tree with the pm tree

[Rafael J. Wysocki]

On Tuesday, July 12, 2016 02:09:26 PM Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the xen-tip tree got a conflict in:
> 
>   drivers/acpi/scan.c
> 
> between commit:
> 
>   68bdb6773289 ("ACPI: add support for ACPI reconfiguration notifiers")
> 
> from the pm tree and commit:
> 
>   c8ac8b6fb495 ("Xen: ACPI: Hide UART used by Xen")
> 
> from the xen-tip tree.
> 
> I fixed it up (see below) and can carry the fix as necessary.

Looks good to me, thanks Stehpen!

Best,
Rafael


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 00/44] dma-mapping: Use unsigned long for dma_attrs

[Daniel Vetter]

On Thu, Jun 30, 2016 at 10:23:39AM +0200, Krzysztof Kozlowski wrote:
> Hi,
> 
> 
> This is fifth approach for replacing struct dma_attrs with unsigned
> long.
> 
> The main patch (1/44) doing the change is split into many subpatches
> for easier review (2-42).  They should be squashed together when
> applying.

For all the drm driver patches:

Acked-by: Daniel Vetter 

Should I pull these in through drm-misc, or do you prefer to merge them
through a special topic branch (with everything else) instead on your own?
-Daniel

> 
> 
> Rebased on v4.7-rc5.
> 
> For easier testing the patchset is available here:
> repo:   https://github.com/krzk/linux
> branch: for-next/dma-attrs-const-v5
> 
> 
> Changes since v4
> 
> 1. Collect some acks. Still need more.
> 2. Minor fixes pointed by Robin Murphy.
> 3. Applied changes from Bart Van Assche's comment.
> 4. More tests and builds (using https://www.kernel.org/pub/tools/crosstool/).
> 
> 
> Changes since v3
> 
> 1. Collect some acks.
> 2. Drop wrong patch 1/45 ("powerpc: dma-mapping: Don't hard-code
>the value of DMA_ATTR_WEAK_ORDERING").
> 3. Minor fix pointed out by Michael Ellerman.
> 
> 
> Changes since v2
> 
> 1. Follow Christoph Hellwig's comments (don't use BIT add
>documentation, remove dma_get_attr).
> 
> 
> Rationale
> =
> The dma-mapping core and the implementations do not change the
> DMA attributes passed by pointer.  Thus the pointer can point to const
> data.  However the attributes do not have to be a bitfield. Instead
> unsigned long will do fine:
> 
> 1. This is just simpler.  Both in terms of reading the code and setting
>attributes.  Instead of initializing local attributes on the stack
>and passing pointer to it to dma_set_attr(), just set the bits.
> 
> 2. It brings safeness and checking for const correctness because the
>attributes are passed by value.
> 
> 
> Best regards,
> Krzysztof
> 
> 
> Krzysztof Kozlowski (44):
>   dma-mapping: Use unsigned long for dma_attrs
>   alpha: dma-mapping: Use unsigned long for dma_attrs
>   arc: dma-mapping: Use unsigned long for dma_attrs
>   ARM: dma-mapping: Use unsigned long for dma_attrs
>   arm64: dma-mapping: Use unsigned long for dma_attrs
>   avr32: dma-mapping: Use unsigned long for dma_attrs
>   blackfin: dma-mapping: Use unsigned long for dma_attrs
>   c6x: dma-mapping: Use unsigned long for dma_attrs
>   cris: dma-mapping: Use unsigned long for dma_attrs
>   frv: dma-mapping: Use unsigned long for dma_attrs
>   drm/exynos: dma-mapping: Use unsigned long for dma_attrs
>   drm/mediatek: dma-mapping: Use unsigned long for dma_attrs
>   drm/msm: dma-mapping: Use unsigned long for dma_attrs
>   drm/nouveau: dma-mapping: Use unsigned long for dma_attrs
>   drm/rockship: dma-mapping: Use unsigned long for dma_attrs
>   infiniband: dma-mapping: Use unsigned long for dma_attrs
>   iommu: dma-mapping: Use unsigned long for dma_attrs
>   [media] dma-mapping: Use unsigned long for dma_attrs
>   xen: dma-mapping: Use unsigned long for dma_attrs
>   swiotlb: dma-mapping: Use unsigned long for dma_attrs
>   powerpc: dma-mapping: Use unsigned long for dma_attrs
>   video: dma-mapping: Use unsigned long for dma_attrs
>   x86: dma-mapping: Use unsigned long for dma_attrs
>   iommu: intel: dma-mapping: Use unsigned long for dma_attrs
>   h8300: dma-mapping: Use unsigned long for dma_attrs
>   hexagon: dma-mapping: Use unsigned long for dma_attrs
>   ia64: dma-mapping: Use unsigned long for dma_attrs
>   m68k: dma-mapping: Use unsigned long for dma_attrs
>   metag: dma-mapping: Use unsigned long for dma_attrs
>   microblaze: dma-mapping: Use unsigned long for dma_attrs
>   mips: dma-mapping: Use unsigned long for dma_attrs
>   mn10300: dma-mapping: Use unsigned long for dma_attrs
>   nios2: dma-mapping: Use unsigned long for dma_attrs
>   openrisc: dma-mapping: Use unsigned long for dma_attrs
>   parisc: dma-mapping: Use unsigned long for dma_attrs
>   misc: mic: dma-mapping: Use unsigned long for dma_attrs
>   s390: dma-mapping: Use unsigned long for dma_attrs
>   sh: dma-mapping: Use unsigned long for dma_attrs
>   sparc: dma-mapping: Use unsigned long for dma_attrs
>   tile: dma-mapping: Use unsigned long for dma_attrs
>   unicore32: dma-mapping: Use unsigned long for dma_attrs
>   xtensa: dma-mapping: Use unsigned long for dma_attrs
>   dma-mapping: Remove dma_get_attr
>   dma-mapping: Document the DMA attributes next to the declaration
> 
>  Documentation/DMA-API.txt  |  33 +++---
>  Documentation/DMA-attributes.txt   |   2 +-
>  arch/alpha/include/asm/dma-mapping.h   |   2 -
>  arch/alpha/kernel/pci-noop.c   |   2 +-
>  arch/alpha/kernel/pci_iommu.c  |  12 +-
>  arch/arc/mm/dma.c  |  12 +-
>  arch/arm/common/dmabounce.c|   4 +-
>  arch/arm/include/asm/dma-mapping.h |  13 +--

Re: [Xen-devel] [PATCH v5 00/44] dma-mapping: Use unsigned long for dma_attrs

[Krzysztof Kozlowski]

On 07/12/2016 02:16 PM, Daniel Vetter wrote:
> On Thu, Jun 30, 2016 at 10:23:39AM +0200, Krzysztof Kozlowski wrote:
>> Hi,
>>
>>
>> This is fifth approach for replacing struct dma_attrs with unsigned
>> long.
>>
>> The main patch (1/44) doing the change is split into many subpatches
>> for easier review (2-42).  They should be squashed together when
>> applying.
> 
> For all the drm driver patches:
> 
> Acked-by: Daniel Vetter 
> 
> Should I pull these in through drm-misc, or do you prefer to merge them
> through a special topic branch (with everything else) instead on your own?
> -Daniel

Thanks. I saw today that Andrew Morton applied the patchset so I think
he will handle it.

Best regards,
Krzysztof


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 02/16] x86: fix: make atomic_read() param const

[Andrew Cooper]

On 12/07/16 11:38, Corneliu ZUZU wrote:
> On 7/12/2016 1:22 PM, Andrew Cooper wrote:
>> On 12/07/16 11:11, Corneliu ZUZU wrote:
>> If you are really feeling up to it, having a common xen/atomic.h
>> with
>>
>> typedef struct { int counter; } atomic_t;
>> #define ATOMIC_INIT(i) { (i) }
>>
>> and some prototypes such as:
>>
>> static inline int atomic_read(const atomic_t *v);
>>
>> would be great, but this looks like it has the possibility to turn
>> into
>> a rats nest.  If it does, then just doubling up this code for arm
>> is ok.
>>
>> ~Andrew
> Yes, that might be more complicated than we expect and I don't
> know if
> making code such as this common would be a good idea, usually these
> functions are always architecture-specific.
 I only suggested making the prototype common, not the implementation.
 As such, the issue you accidentally introduced would become a hard
 build
 failure on affected architectures, rather than a subtle build
 failure in
 common code at some point in the future.

 ~Andrew

>>> Oh, I see, good idea, I've just tested it and it works, what did you
>>> have in mind when you said it could cause problems?
>> The build issues would come at some point later when someone attempts to
>> atomic_read() a constant atomic_t in common code, when the ARM build
>> would break.
>>
>> ~Andrew
>
> Ooh, no, I was asking what you meant when you said "this looks like it
> has the possibility to turn into a rats nest" in your first message,
> not the thing about hard build failure..

Ah. sorry.

You would have to invert all the includes of atomic.h to include
 rather than , and have xen/atomic.h include
asm/atomic.h towards the end, such that the common prototypes are
first.  I just suspect that this might not be completely trivial to
untangle (of course, I could also be wrong).

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 0/4] libxl: add framework for device types

[Wei Liu]

On Fri, Jul 08, 2016 at 06:54:54PM +0100, Ian Jackson wrote:
> Juergen Gross writes ("[PATCH v2 0/4] libxl: add framework for device types"):
> > Instead of duplicate coding for each device type (vtpms, usbctrls, ...)
> > especially on domain creation introduce a framework for that purpose.
> > 
> > I especially found it annoying that e.g. the vtpm callback issued the
> > error message for a failed attach of nic devices.
> 
> I was tempted to just commit this, having acked all four, but given
> the nature of this series I'm going to wait a bit for further comments
> :-).
> 

Pushed with Ian's ack.

> Regards,
> Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 18/19] xen: credit2: implement SMT support independent runq arrangement

[George Dunlap]

On Sat, Jun 18, 2016 at 12:13 AM, Dario Faggioli
 wrote:
> In fact, right now, we recommend keepeing runqueues
> arranged per-core, so that it is the inter-runqueue load
> balancing code that automatically spreads the work in an
> SMT friendly way. This means that any other runq
> arrangement one may want to use falls short of SMT
> scheduling optimizations.
>
> This commit implements SMT awareness --similar to the
> one we have in Credit1-- for any possible runq
> arrangement. This turned out to be pretty easy to do,
> as the logic can live entirely in runq_tickle()
> (although, in order to avoid for_each_cpu loops in
> that function, we use a new cpumask which indeed needs
> to be updated in other places).
>
> In addition to disentangling SMT awareness from load
> balancing, this also allows us to support the
> sched_smt_power_savings parametar in Credit2 as well.
>
> Signed-off-by: Dario Faggioli 

Other than the issues Jan pointed out, looks good.

 -George

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 0/5] libxl: update available vcpus map in retrieved configuration

[Wei Liu]

On Mon, Jul 11, 2016 at 04:49:32PM +0100, Wei Liu wrote:
> See individual patch for detailed changelog.

Series pushed.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 02/16] x86: fix: make atomic_read() param const

[Corneliu ZUZU]

On 7/12/2016 3:49 PM, Andrew Cooper wrote:

On 12/07/16 11:38, Corneliu ZUZU wrote:

On 7/12/2016 1:22 PM, Andrew Cooper wrote:

On 12/07/16 11:11, Corneliu ZUZU wrote:

If you are really feeling up to it, having a common xen/atomic.h
with

typedef struct { int counter; } atomic_t;
#define ATOMIC_INIT(i) { (i) }

and some prototypes such as:

static inline int atomic_read(const atomic_t *v);

would be great, but this looks like it has the possibility to turn
into
a rats nest.  If it does, then just doubling up this code for arm
is ok.

~Andrew

Yes, that might be more complicated than we expect and I don't
know if
making code such as this common would be a good idea, usually these
functions are always architecture-specific.

I only suggested making the prototype common, not the implementation.
As such, the issue you accidentally introduced would become a hard
build
failure on affected architectures, rather than a subtle build
failure in
common code at some point in the future.

~Andrew


Oh, I see, good idea, I've just tested it and it works, what did you
have in mind when you said it could cause problems?

The build issues would come at some point later when someone attempts to
atomic_read() a constant atomic_t in common code, when the ARM build
would break.

~Andrew

Ooh, no, I was asking what you meant when you said "this looks like it
has the possibility to turn into a rats nest" in your first message,
not the thing about hard build failure..

Ah. sorry.

You would have to invert all the includes of atomic.h to include
 rather than , and have xen/atomic.h include
asm/atomic.h towards the end, such that the common prototypes are
first.  I just suspect that this might not be completely trivial to
untangle (of course, I could also be wrong).

~Andrew


I did it the other way - included  from .

Zuzu C.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v7 10/14] xen/arm: Use the typesafes mfn and gfn in map_dev_mmio_region...

[Julien Grall]

to avoid mixing machine frame with guest frame. Also drop the prefix start_.

Signed-off-by: Julien Grall 

---
Changes in v6:
- Qualify what is being mapped
- Use PRI_mfn

Changes in v4:
- Patch added
---
 xen/arch/arm/mm.c |  2 +-
 xen/arch/arm/p2m.c| 12 ++--
 xen/include/asm-arm/p2m.h |  4 ++--
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 0e408f8..b5fc034 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1145,7 +1145,7 @@ int xenmem_add_to_physmap_one(
 if ( extra.res0 )
 return -EOPNOTSUPP;
 
-rc = map_dev_mmio_region(d, gfn_x(gfn), 1, idx);
+rc = map_dev_mmio_region(d, gfn, 1, _mfn(idx));
 return rc;
 
 default:
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index f11094e..5fe1b91 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1211,20 +1211,20 @@ int unmap_mmio_regions(struct domain *d,
 }
 
 int map_dev_mmio_region(struct domain *d,
-unsigned long start_gfn,
+gfn_t gfn,
 unsigned long nr,
-unsigned long mfn)
+mfn_t mfn)
 {
 int res;
 
-if ( !(nr && iomem_access_permitted(d, mfn, mfn + nr - 1)) )
+if ( !(nr && iomem_access_permitted(d, mfn_x(mfn), mfn_x(mfn) + nr - 1)) )
 return 0;
 
-res = map_mmio_regions(d, _gfn(start_gfn), nr, _mfn(mfn));
+res = map_mmio_regions(d, gfn, nr, mfn);
 if ( res < 0 )
 {
-printk(XENLOG_G_ERR "Unable to map [%#lx - %#lx] in Dom%d\n",
-   mfn, mfn + nr - 1, d->domain_id);
+printk(XENLOG_G_ERR "Unable to map MFNs [%#"PRI_mfn" - %#"PRI_mfn" in 
Dom%d\n",
+   mfn_x(mfn), mfn_x(mfn) + nr - 1, d->domain_id);
 return res;
 }
 
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 4752161..8d29eda 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -152,9 +152,9 @@ int unmap_regions_rw_cache(struct domain *d,
unsigned long mfn);
 
 int map_dev_mmio_region(struct domain *d,
-unsigned long start_gfn,
+gfn_t gfn,
 unsigned long nr,
-unsigned long mfn);
+mfn_t mfn);
 
 int guest_physmap_add_entry(struct domain *d,
 gfn_t gfn,
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v7 08/14] xen/arm: dom0_build: Remove dead code in allocate_memory

[Julien Grall]

The code to allocate memory when dom0 does not use direct mapping is
relying on the presence of memory node in the DT.

However, they are not present when booting using UEFI or when using
ACPI.

Rather than fixing the code, remove it because dom0 is always direct
memory mapped and therefore the code is never tested. Also add a
check to avoid disabling direct memory mapped and not implementing
the associated RAM bank allocation.

Signed-off-by: Julien Grall 
Acked-by: Stefano Stabellini 

---
Changes in v6:
- Add Stefano's acked-by

Changes in v4:
- Patch added
---
 xen/arch/arm/domain_build.c | 58 ++---
 1 file changed, 7 insertions(+), 51 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 49185f0..923f48a 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -235,7 +235,7 @@ fail:
  * (as described above) we allow higher allocations and continue until
  * that runs out (or we have allocated sufficient dom0 memory).
  */
-static void allocate_memory_11(struct domain *d, struct kernel_info *kinfo)
+static void allocate_memory(struct domain *d, struct kernel_info *kinfo)
 {
 const unsigned int min_low_order =
 get_order_from_bytes(min_t(paddr_t, dom0_mem, MB(128)));
@@ -247,6 +247,12 @@ static void allocate_memory_11(struct domain *d, struct 
kernel_info *kinfo)
 bool_t lowmem = is_32bit_domain(d);
 unsigned int bits;
 
+/*
+ * TODO: Implement memory bank allocation when DOM0 is not direct
+ * mapped
+ */
+BUG_ON(!dom0_11_mapping);
+
 printk("Allocating 1:1 mappings totalling %ldMB for dom0:\n",
/* Don't want format this as PRIpaddr (16 digit hex) */
(unsigned long)(kinfo->unassigned_mem >> 20));
@@ -343,56 +349,6 @@ static void allocate_memory_11(struct domain *d, struct 
kernel_info *kinfo)
 }
 }
 
-static void allocate_memory(struct domain *d, struct kernel_info *kinfo)
-{
-
-struct dt_device_node *memory = NULL;
-const void *reg;
-u32 reg_len, reg_size;
-unsigned int bank = 0;
-
-if ( dom0_11_mapping )
-return allocate_memory_11(d, kinfo);
-
-while ( (memory = dt_find_node_by_type(memory, "memory")) )
-{
-int l;
-
-dt_dprintk("memory node\n");
-
-reg_size = dt_cells_to_size(dt_n_addr_cells(memory) + 
dt_n_size_cells(memory));
-
-reg = dt_get_property(memory, "reg", ®_len);
-if ( reg == NULL )
-panic("Memory node has no reg property");
-
-for ( l = 0;
-  kinfo->unassigned_mem > 0 && l + reg_size <= reg_len
-  && kinfo->mem.nr_banks < NR_MEM_BANKS;
-  l += reg_size )
-{
-paddr_t start, size;
-
-if ( dt_device_get_address(memory, bank, &start, &size) )
-panic("Unable to retrieve the bank %u for %s",
-  bank, dt_node_full_name(memory));
-
-if ( size > kinfo->unassigned_mem )
-size = kinfo->unassigned_mem;
-
-printk("Populate P2M %#"PRIx64"->%#"PRIx64"\n",
-   start, start + size);
-if ( p2m_populate_ram(d, start, start + size) < 0 )
-panic("Failed to populate P2M");
-kinfo->mem.bank[kinfo->mem.nr_banks].start = start;
-kinfo->mem.bank[kinfo->mem.nr_banks].size = size;
-kinfo->mem.nr_banks++;
-
-kinfo->unassigned_mem -= size;
-}
-}
-}
-
 static int write_properties(struct domain *d, struct kernel_info *kinfo,
 const struct dt_device_node *node)
 {
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v7 03/14] xen: Use a typesafe to define INVALID_MFN

[Julien Grall]

Also take the opportunity to convert arch/x86/debug.c to the typesafe
mfn and use proper printf format for MFN/GFN when the code around is
modified.

Signed-off-by: Julien Grall 
Reviewed-by: Andrew Cooper 
Acked-by: Stefano Stabellini 

---
Cc: Christoph Egger 
Cc: Liu Jinsong 
Cc: Jan Beulich 
Cc: Elena Ufimtseva 
Cc: Paul Durrant 
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: George Dunlap 
Cc: Tim Deegan 

Changes in v7:
- Forgot to convert back one MFN_INVALID_T to INVALID_MFN

Changes in v6:
- Add Stefano's acked-by for ARM bits
- Use PRI_mfn and PRI_gfn
- Remove set of brackets when it is not necessary
- Use mfn_add when possible
- Add Andrew's reviewed-by

Changes in v5:
- Patch added
---
 xen/arch/arm/p2m.c  |  4 +--
 xen/arch/x86/cpu/mcheck/mce.c   |  2 +-
 xen/arch/x86/debug.c| 58 +
 xen/arch/x86/hvm/hvm.c  |  6 ++---
 xen/arch/x86/hvm/viridian.c | 12 -
 xen/arch/x86/hvm/vmx/vmx.c  |  2 +-
 xen/arch/x86/mm/guest_walk.c|  4 +--
 xen/arch/x86/mm/hap/hap.c   |  4 +--
 xen/arch/x86/mm/p2m-ept.c   |  6 ++---
 xen/arch/x86/mm/p2m-pod.c   | 18 ++---
 xen/arch/x86/mm/p2m-pt.c| 18 ++---
 xen/arch/x86/mm/p2m.c   | 54 +++---
 xen/arch/x86/mm/paging.c| 12 -
 xen/arch/x86/mm/shadow/common.c | 43 +++---
 xen/arch/x86/mm/shadow/multi.c  | 36 -
 xen/common/domain.c |  6 ++---
 xen/common/grant_table.c|  6 ++---
 xen/include/xen/mm.h|  2 +-
 18 files changed, 147 insertions(+), 146 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 34563bb..d690602 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1461,7 +1461,7 @@ int relinquish_p2m_mapping(struct domain *d)
 return apply_p2m_changes(d, RELINQUISH,
   pfn_to_paddr(p2m->lowest_mapped_gfn),
   pfn_to_paddr(p2m->max_mapped_gfn),
-  pfn_to_paddr(INVALID_MFN),
+  pfn_to_paddr(mfn_x(INVALID_MFN)),
   MATTR_MEM, 0, p2m_invalid,
   d->arch.p2m.default_access);
 }
@@ -1476,7 +1476,7 @@ int p2m_cache_flush(struct domain *d, xen_pfn_t 
start_mfn, xen_pfn_t end_mfn)
 return apply_p2m_changes(d, CACHEFLUSH,
  pfn_to_paddr(start_mfn),
  pfn_to_paddr(end_mfn),
- pfn_to_paddr(INVALID_MFN),
+ pfn_to_paddr(mfn_x(INVALID_MFN)),
  MATTR_MEM, 0, p2m_invalid,
  d->arch.p2m.default_access);
 }
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index edcbe48..2695b0c 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1455,7 +1455,7 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
 gfn = PFN_DOWN(gaddr);
 mfn = mfn_x(get_gfn(d, gfn, &t));
 
-if ( mfn == INVALID_MFN )
+if ( mfn == mfn_x(INVALID_MFN) )
 {
 put_gfn(d, gfn);
 put_domain(d);
diff --git a/xen/arch/x86/debug.c b/xen/arch/x86/debug.c
index 58cae22..9213ea7 100644
--- a/xen/arch/x86/debug.c
+++ b/xen/arch/x86/debug.c
@@ -43,11 +43,11 @@ typedef unsigned long dbgva_t;
 typedef unsigned char dbgbyte_t;
 
 /* Returns: mfn for the given (hvm guest) vaddr */
-static unsigned long 
+static mfn_t
 dbg_hvm_va2mfn(dbgva_t vaddr, struct domain *dp, int toaddr,
 unsigned long *gfn)
 {
-unsigned long mfn;
+mfn_t mfn;
 uint32_t pfec = PFEC_page_present;
 p2m_type_t gfntype;
 
@@ -60,16 +60,17 @@ dbg_hvm_va2mfn(dbgva_t vaddr, struct domain *dp, int toaddr,
 return INVALID_MFN;
 }
 
-mfn = mfn_x(get_gfn(dp, *gfn, &gfntype)); 
+mfn = get_gfn(dp, *gfn, &gfntype);
 if ( p2m_is_readonly(gfntype) && toaddr )
 {
 DBGP2("kdb:p2m_is_readonly: gfntype:%x\n", gfntype);
 mfn = INVALID_MFN;
 }
 else
-DBGP2("X: vaddr:%lx domid:%d mfn:%lx\n", vaddr, dp->domain_id, mfn);
+DBGP2("X: vaddr:%lx domid:%d mfn:%#"PRI_mfn"\n",
+  vaddr, dp->domain_id, mfn_x(mfn));
 
-if ( mfn == INVALID_MFN )
+if ( mfn_eq(mfn, INVALID_MFN) )
 {
 put_gfn(dp, *gfn);
 *gfn = INVALID_GFN;
@@ -91,7 +92,7 @@ dbg_hvm_va2mfn(dbgva_t vaddr, struct domain *dp, int toaddr,
  *   mode.
  * Returns: mfn for the given (pv guest) vaddr 
  */
-static unsigned long 
+static mfn_t
 dbg_pv_va2mfn(dbgva_t vaddr, struct domain *dp, uint64_t pgd3val)
 {
 l4_pgentry_t l4e, *l4t;
@@ -99,31 +100,31 @@ dbg_pv_va2mfn(dbgva_t vaddr, struct domain *dp, uint64_t 
pgd3val)
 l2_pgentry_t l2e, *

[Xen-devel] [PATCH v7 07/14] xen/arm: map_regions_rw_cache: Map the region with p2m->default_access

[Julien Grall]

The parameter 'access' is used by memaccess to restrict temporarily the
permission. This parameter should not be used for other purpose (such
as restricting permanently the permission).

Instead, we should use the default access requested by memacess. When it
is not enabled, the access will be p2m_access_rwx (i.e no restriction
applied).

The type p2m_mmio_direct will map the region read-write and
non-executable before any further restriction by memaccess. Note that
this is already the resulting permission with the curreent combination
of the type and the access. So there is no functional change.

Signed-off-by: Julien Grall 

---
Cc: Shannon Zhao 

This patch is a candidate for Xen 4.7. Currently this function is
only used to map ACPI regions.

I am wondering if we should introduce a new p2m type for it. And map
this region RO (I am not sure why a guest would want to
modify this region).

Changes in v2:
- Reword the commit message

Changes in v4:
- Patch added
---
 xen/arch/arm/p2m.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 1cfb62b..fcc4513 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1231,7 +1231,7 @@ int map_regions_rw_cache(struct domain *d,
  pfn_to_paddr(start_gfn + nr),
  pfn_to_paddr(mfn),
  MATTR_MEM, 0, p2m_mmio_direct,
- p2m_access_rw);
+ d->arch.p2m.default_access);
 }
 
 int unmap_regions_rw_cache(struct domain *d,
@@ -1244,7 +1244,7 @@ int unmap_regions_rw_cache(struct domain *d,
  pfn_to_paddr(start_gfn + nr),
  pfn_to_paddr(mfn),
  MATTR_MEM, 0, p2m_invalid,
- p2m_access_rw);
+ d->arch.p2m.default_access);
 }
 
 int map_mmio_regions(struct domain *d,
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v7 01/14] xen: Use the typesafe mfn and gfn in map_mmio_regions...

[Julien Grall]

to avoid mixing machine frame with guest frame.

Signed-off-by: Julien Grall 
Acked-by: Jan Beulich 
Acked-by: Stefano Stabellini 

---
Cc: Stefano Stabellini 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Konrad Rzeszutek Wilk 
Cc: Tim Deegan 
Cc: Wei Liu 

Changes in v6:
- Add Stefano's acked-by

Changes in v3:
- Use mfn_add when it is possible
- Add Jan's acked-by
---
 xen/arch/arm/domain_build.c  |  4 ++--
 xen/arch/arm/gic-v2.c|  4 ++--
 xen/arch/arm/p2m.c   | 22 +++---
 xen/arch/arm/platforms/exynos5.c |  8 
 xen/arch/arm/platforms/omap5.c   | 16 
 xen/arch/arm/vgic-v2.c   |  4 ++--
 xen/arch/x86/mm/p2m.c| 18 ++
 xen/common/domctl.c  |  4 ++--
 xen/include/xen/p2m-common.h |  8 
 9 files changed, 45 insertions(+), 43 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 9035486..49185f0 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1036,9 +1036,9 @@ static int map_range_to_domain(const struct 
dt_device_node *dev,
 if ( need_mapping )
 {
 res = map_mmio_regions(d,
-   paddr_to_pfn(addr),
+   _gfn(paddr_to_pfn(addr)),
DIV_ROUND_UP(len, PAGE_SIZE),
-   paddr_to_pfn(addr));
+   _mfn(paddr_to_pfn(addr)));
 if ( res < 0 )
 {
 printk(XENLOG_ERR "Unable to map 0x%"PRIx64
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 4e2f4c7..3893ece 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -601,9 +601,9 @@ static int gicv2_map_hwdown_extra_mappings(struct domain *d)
d->domain_id, v2m_data->addr, v2m_data->size,
v2m_data->spi_start, v2m_data->nr_spis);
 
-ret = map_mmio_regions(d, paddr_to_pfn(v2m_data->addr),
+ret = map_mmio_regions(d, _gfn(paddr_to_pfn(v2m_data->addr)),
 DIV_ROUND_UP(v2m_data->size, PAGE_SIZE),
-paddr_to_pfn(v2m_data->addr));
+_mfn(paddr_to_pfn(v2m_data->addr)));
 if ( ret )
 {
 printk(XENLOG_ERR "GICv2: Map v2m frame to d%d failed.\n",
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 0395a40..34563bb 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1245,27 +1245,27 @@ int unmap_regions_rw_cache(struct domain *d,
 }
 
 int map_mmio_regions(struct domain *d,
- unsigned long start_gfn,
+ gfn_t start_gfn,
  unsigned long nr,
- unsigned long mfn)
+ mfn_t mfn)
 {
 return apply_p2m_changes(d, INSERT,
- pfn_to_paddr(start_gfn),
- pfn_to_paddr(start_gfn + nr),
- pfn_to_paddr(mfn),
+ pfn_to_paddr(gfn_x(start_gfn)),
+ pfn_to_paddr(gfn_x(start_gfn) + nr),
+ pfn_to_paddr(mfn_x(mfn)),
  MATTR_DEV, 0, p2m_mmio_direct,
  d->arch.p2m.default_access);
 }
 
 int unmap_mmio_regions(struct domain *d,
-   unsigned long start_gfn,
+   gfn_t start_gfn,
unsigned long nr,
-   unsigned long mfn)
+   mfn_t mfn)
 {
 return apply_p2m_changes(d, REMOVE,
- pfn_to_paddr(start_gfn),
- pfn_to_paddr(start_gfn + nr),
- pfn_to_paddr(mfn),
+ pfn_to_paddr(gfn_x(start_gfn)),
+ pfn_to_paddr(gfn_x(start_gfn) + nr),
+ pfn_to_paddr(mfn_x(mfn)),
  MATTR_DEV, 0, p2m_invalid,
  d->arch.p2m.default_access);
 }
@@ -1280,7 +1280,7 @@ int map_dev_mmio_region(struct domain *d,
 if ( !(nr && iomem_access_permitted(d, mfn, mfn + nr - 1)) )
 return 0;
 
-res = map_mmio_regions(d, start_gfn, nr, mfn);
+res = map_mmio_regions(d, _gfn(start_gfn), nr, _mfn(mfn));
 if ( res < 0 )
 {
 printk(XENLOG_G_ERR "Unable to map [%#lx - %#lx] in Dom%d\n",
diff --git a/xen/arch/arm/platforms/exynos5.c b/xen/arch/arm/platforms/exynos5.c
index bf4964d..c43934f 100644
--- a/xen/arch/arm/platforms/exynos5.c
+++ b/xen/arch/arm/platforms/exynos5.c
@@ -83,12 +83,12 @@ static int exynos5_init_time(void)
 static int exynos5250_specific_mapping(struct domain *d)
 {
 /* Map the chip ID */
-map_mmio_regions(d, paddr_to_pfn(EXYNOS5_PA_CHIPID), 1,
- paddr_to_pfn(EXYNOS5_PA_CHIPID));
+map_mmio_regions(d, _gfn(paddr_t

[Xen-devel] [PATCH v7 06/14] xen/arm: Rework the interface of p2m_cache_flush and use typesafe gfn

[Julien Grall]

p2m_cache_flush is expecting GFNs in parameter and not MFNs. Rename
the variable to *gfn* and use typesafe to avoid possible misusage.

Also, modify the prototype of the function to describe the range
using the start and the number of GFNs. This will avoid to wonder
whether the end if inclusive or exclusive.

Note that the type of the parameters 'start' is changed from xen_pfn_t
(aka uint64_t) to gfn_t (aka unsigned long). This means that a truncation
will occur for ARM32. It is fine because it will always be encoded on 28
bits maximum (40 bits address).

Signed-off-by: Julien Grall 
Acked-by: Stefano Stabellini 

---
Changes in v6:
- Add Stefano's acked-by

Changes in v4:
- This patch was originally called "xen/arm: p2m_cache_flush:
Use the correct terminology and typesafe gfn"
- Describe the range using the start and the number of GFNs.

Changes in v3:
- Add a word in the commit message about the truncation.

Changes in v2:
- Drop _gfn suffix
---
 xen/arch/arm/domctl.c |  2 +-
 xen/arch/arm/p2m.c| 11 ++-
 xen/include/asm-arm/p2m.h |  2 +-
 3 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index 30453d8..f61f98a 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -30,7 +30,7 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain 
*d,
 if ( e < s )
 return -EINVAL;
 
-return p2m_cache_flush(d, s, e);
+return p2m_cache_flush(d, _gfn(s), domctl->u.cacheflush.nr_pfns);
 }
 case XEN_DOMCTL_bind_pt_irq:
 {
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 54a363a..1cfb62b 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1469,16 +1469,17 @@ int relinquish_p2m_mapping(struct domain *d)
   d->arch.p2m.default_access);
 }
 
-int p2m_cache_flush(struct domain *d, xen_pfn_t start_mfn, xen_pfn_t end_mfn)
+int p2m_cache_flush(struct domain *d, gfn_t start, unsigned long nr)
 {
 struct p2m_domain *p2m = &d->arch.p2m;
+gfn_t end = gfn_add(start, nr);
 
-start_mfn = MAX(start_mfn, p2m->lowest_mapped_gfn);
-end_mfn = MIN(end_mfn, p2m->max_mapped_gfn);
+start = gfn_max(start, _gfn(p2m->lowest_mapped_gfn));
+end = gfn_min(end, _gfn(p2m->max_mapped_gfn));
 
 return apply_p2m_changes(d, CACHEFLUSH,
- pfn_to_paddr(start_mfn),
- pfn_to_paddr(end_mfn),
+ pfn_to_paddr(gfn_x(start)),
+ pfn_to_paddr(gfn_x(end)),
  pfn_to_paddr(mfn_x(INVALID_MFN)),
  MATTR_MEM, 0, p2m_invalid,
  d->arch.p2m.default_access);
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index f204482..8a96e68 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -139,7 +139,7 @@ void p2m_dump_info(struct domain *d);
 mfn_t p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t *t);
 
 /* Clean & invalidate caches corresponding to a region of guest address space 
*/
-int p2m_cache_flush(struct domain *d, xen_pfn_t start_mfn, xen_pfn_t end_mfn);
+int p2m_cache_flush(struct domain *d, gfn_t start, unsigned long nr);
 
 /* Setup p2m RAM mapping for domain d from start-end. */
 int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v7 00/14] xen/arm: Use the typesafes gfn and mfn

[Julien Grall]

Hello all,

Some of the ARM functions are mixing gfn vs mfn and even physical vs frame.

To avoid more confusion, this patch series makes use of the terminology
described in xen/include/xen/mm.h and the associated typesafe.

I pushed a branch with this series applied on top of staging:
git://xenbits.xen.org/people/julieng/xen-unstable.git branch typesafe-v7

For all the changes see in each patch.

Yours sincerely,

Cc: Andrew Cooper 
Cc: Boris Ostrovsky 
Cc: Christoph Egger 
Cc: Elena Ufimtseva 
Cc: Feng Wu 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: Konrad Rzeszutek Wilk 
Cc: Liu Jinsong 
Cc: Paul Durrant 
Cc: Shannon Zhao 
Cc: Stefano Stabellini 
Cc: Suravee Suthikulpanit 
Cc: Tim Deegan 
Cc: Wei Liu 

Julien Grall (14):
  xen: Use the typesafe mfn and gfn in map_mmio_regions...
  xen/passthrough: x86: Use INVALID_GFN rather than INVALID_MFN
  xen: Use a typesafe to define INVALID_MFN
  xen: Use a typesafe to define INVALID_GFN
  xen/arm: Rework the interface of p2m_lookup and use typesafe gfn and
mfn
  xen/arm: Rework the interface of p2m_cache_flush and use typesafe gfn
  xen/arm: map_regions_rw_cache: Map the region with p2m->default_access
  xen/arm: dom0_build: Remove dead code in allocate_memory
  xen/arm: p2m: Remove unused operation ALLOCATE
  xen/arm: Use the typesafes mfn and gfn in map_dev_mmio_region...
  xen/arm: Use the typesafes mfn and gfn in map_regions_rw_cache ...
  xen/arm: p2m: Introduce helpers to insert and remove mapping
  xen/arm: p2m: Use typesafe gfn for {max,lowest}_mapped_gfn
  xen/arm: p2m: Rework the interface of apply_p2m_changes and use
typesafe

 xen/arch/arm/domain_build.c |  70 ++---
 xen/arch/arm/domctl.c   |   2 +-
 xen/arch/arm/gic-v2.c   |   4 +-
 xen/arch/arm/mm.c   |   4 +-
 xen/arch/arm/p2m.c  | 263 
 xen/arch/arm/platforms/exynos5.c|   8 +-
 xen/arch/arm/platforms/omap5.c  |  16 +-
 xen/arch/arm/traps.c|  21 +--
 xen/arch/arm/vgic-v2.c  |   4 +-
 xen/arch/x86/cpu/mcheck/mce.c   |   2 +-
 xen/arch/x86/debug.c|  72 -
 xen/arch/x86/domain.c   |   2 +-
 xen/arch/x86/hvm/emulate.c  |   7 +-
 xen/arch/x86/hvm/hvm.c  |  12 +-
 xen/arch/x86/hvm/ioreq.c|   8 +-
 xen/arch/x86/hvm/svm/nestedsvm.c|   2 +-
 xen/arch/x86/hvm/viridian.c |  12 +-
 xen/arch/x86/hvm/vmx/vmx.c  |   8 +-
 xen/arch/x86/mm/altp2m.c|   2 +-
 xen/arch/x86/mm/guest_walk.c|   4 +-
 xen/arch/x86/mm/hap/guest_walk.c|  10 +-
 xen/arch/x86/mm/hap/hap.c   |   4 +-
 xen/arch/x86/mm/hap/nested_ept.c|   2 +-
 xen/arch/x86/mm/p2m-ept.c   |   6 +-
 xen/arch/x86/mm/p2m-pod.c   |  24 +--
 xen/arch/x86/mm/p2m-pt.c|  18 +--
 xen/arch/x86/mm/p2m.c   |  90 +--
 xen/arch/x86/mm/paging.c|  12 +-
 xen/arch/x86/mm/shadow/common.c |  45 +++---
 xen/arch/x86/mm/shadow/multi.c  |  38 ++---
 xen/arch/x86/mm/shadow/private.h|   2 +-
 xen/common/domain.c |   6 +-
 xen/common/domctl.c |   4 +-
 xen/common/grant_table.c|   6 +-
 xen/drivers/passthrough/amd/iommu_map.c |   2 +-
 xen/drivers/passthrough/vtd/iommu.c |   4 +-
 xen/drivers/passthrough/x86/iommu.c |   2 +-
 xen/include/asm-arm/p2m.h   |  32 ++--
 xen/include/asm-x86/guest_pt.h  |   4 +-
 xen/include/asm-x86/p2m.h   |   2 +-
 xen/include/xen/mm.h|   4 +-
 xen/include/xen/p2m-common.h|   8 +-
 42 files changed, 371 insertions(+), 477 deletions(-)

-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v7 09/14] xen/arm: p2m: Remove unused operation ALLOCATE

[Julien Grall]

The operation ALLOCATE is unused. If we ever need it, it could be
reimplemented with INSERT.

Signed-off-by: Julien Grall 
Acked-by: Stefano Stabellini 

---
Changes in v6:
- Add Stefano's acked-by

Changes in v4:
- Patch added
---
 xen/arch/arm/p2m.c| 67 ++-
 xen/include/asm-arm/p2m.h |  3 ---
 2 files changed, 2 insertions(+), 68 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index fcc4513..f11094e 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -547,7 +547,6 @@ static int p2m_mem_access_radix_set(struct p2m_domain *p2m, 
unsigned long pfn,
 
 enum p2m_operation {
 INSERT,
-ALLOCATE,
 REMOVE,
 RELINQUISH,
 CACHEFLUSH,
@@ -667,7 +666,6 @@ static int apply_one_level(struct domain *d,
 {
 const paddr_t level_size = level_sizes[level];
 const paddr_t level_mask = level_masks[level];
-const paddr_t level_shift = level_shifts[level];
 
 struct p2m_domain *p2m = &d->arch.p2m;
 lpae_t pte;
@@ -678,58 +676,6 @@ static int apply_one_level(struct domain *d,
 
 switch ( op )
 {
-case ALLOCATE:
-ASSERT(level < 3 || !p2m_valid(orig_pte));
-ASSERT(*maddr == 0);
-
-if ( p2m_valid(orig_pte) )
-return P2M_ONE_DESCEND;
-
-if ( is_mapping_aligned(*addr, end_gpaddr, 0, level_size) &&
-   /* We only create superpages when mem_access is not in use. */
- (level == 3 || (level < 3 && !p2m->mem_access_enabled)) )
-{
-struct page_info *page;
-
-page = alloc_domheap_pages(d, level_shift - PAGE_SHIFT, 0);
-if ( page )
-{
-rc = p2m_mem_access_radix_set(p2m, paddr_to_pfn(*addr), a);
-if ( rc < 0 )
-{
-free_domheap_page(page);
-return rc;
-}
-
-pte = mfn_to_p2m_entry(page_to_mfn(page), mattr, t, a);
-if ( level < 3 )
-pte.p2m.table = 0;
-p2m_write_pte(entry, pte, flush_cache);
-p2m->stats.mappings[level]++;
-
-*addr += level_size;
-
-return P2M_ONE_PROGRESS;
-}
-else if ( level == 3 )
-return -ENOMEM;
-}
-
-/* L3 is always suitably aligned for mapping (handled, above) */
-BUG_ON(level == 3);
-
-/*
- * If we get here then we failed to allocate a sufficiently
- * large contiguous region for this level (which can't be
- * L3) or mem_access is in use. Create a page table and
- * continue to descend so we try smaller allocations.
- */
-rc = p2m_create_table(d, entry, 0, flush_cache);
-if ( rc < 0 )
-return rc;
-
-return P2M_ONE_DESCEND;
-
 case INSERT:
 if ( is_mapping_aligned(*addr, end_gpaddr, *maddr, level_size) &&
/*
@@ -1169,7 +1115,7 @@ static int apply_p2m_changes(struct domain *d,
 }
 }
 
-if ( op == ALLOCATE || op == INSERT )
+if ( op == INSERT )
 {
 p2m->max_mapped_gfn = max(p2m->max_mapped_gfn, egfn);
 p2m->lowest_mapped_gfn = min(p2m->lowest_mapped_gfn, sgfn);
@@ -1197,7 +1143,7 @@ out:
 
 spin_unlock(&p2m->lock);
 
-if ( rc < 0 && ( op == INSERT || op == ALLOCATE ) &&
+if ( rc < 0 && ( op == INSERT ) &&
  addr != start_gpaddr )
 {
 BUG_ON(addr == end_gpaddr);
@@ -1212,15 +1158,6 @@ out:
 return rc;
 }
 
-int p2m_populate_ram(struct domain *d,
- paddr_t start,
- paddr_t end)
-{
-return apply_p2m_changes(d, ALLOCATE, start, end,
- 0, MATTR_MEM, 0, p2m_ram_rw,
- d->arch.p2m.default_access);
-}
-
 int map_regions_rw_cache(struct domain *d,
  unsigned long start_gfn,
  unsigned long nr,
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 8a96e68..4752161 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -141,9 +141,6 @@ mfn_t p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t 
*t);
 /* Clean & invalidate caches corresponding to a region of guest address space 
*/
 int p2m_cache_flush(struct domain *d, gfn_t start, unsigned long nr);
 
-/* Setup p2m RAM mapping for domain d from start-end. */
-int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
-
 int map_regions_rw_cache(struct domain *d,
  unsigned long start_gfn,
  unsigned long nr_mfns,
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v7 11/14] xen/arm: Use the typesafes mfn and gfn in map_regions_rw_cache ...

[Julien Grall]

to avoid mixing machine frame with guest frame. Also rename the
parameters of the function and drop pointless PAGE_MASK in the caller.

Signed-off-by: Julien Grall 
Acked-by: Stefano Stabellini 

---
Changes in v6:
- Add Stefano's acked-by

Changes in v4:
- Patch added
---
 xen/arch/arm/domain_build.c |  8 
 xen/arch/arm/p2m.c  | 20 ++--
 xen/include/asm-arm/p2m.h   | 12 ++--
 3 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 923f48a..60db9e4 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1522,9 +1522,9 @@ static void acpi_map_other_tables(struct domain *d)
 addr = acpi_gbl_root_table_list.tables[i].address;
 size = acpi_gbl_root_table_list.tables[i].length;
 res = map_regions_rw_cache(d,
-   paddr_to_pfn(addr & PAGE_MASK),
+   _gfn(paddr_to_pfn(addr)),
DIV_ROUND_UP(size, PAGE_SIZE),
-   paddr_to_pfn(addr & PAGE_MASK));
+   _mfn(paddr_to_pfn(addr)));
 if ( res )
 {
  panic(XENLOG_ERR "Unable to map ACPI region 0x%"PRIx64
@@ -1878,9 +1878,9 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 
 /* Map the EFI and ACPI tables to Dom0 */
 rc = map_regions_rw_cache(d,
-  paddr_to_pfn(d->arch.efi_acpi_gpa),
+  _gfn(paddr_to_pfn(d->arch.efi_acpi_gpa)),
   PFN_UP(d->arch.efi_acpi_len),
-  
paddr_to_pfn(virt_to_maddr(d->arch.efi_acpi_table)));
+  
_mfn(paddr_to_pfn(virt_to_maddr(d->arch.efi_acpi_table;
 if ( rc != 0 )
 {
 printk(XENLOG_ERR "Unable to map EFI/ACPI table 0x%"PRIx64
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 5fe1b91..2ba9477 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1159,27 +1159,27 @@ out:
 }
 
 int map_regions_rw_cache(struct domain *d,
- unsigned long start_gfn,
+ gfn_t gfn,
  unsigned long nr,
- unsigned long mfn)
+ mfn_t mfn)
 {
 return apply_p2m_changes(d, INSERT,
- pfn_to_paddr(start_gfn),
- pfn_to_paddr(start_gfn + nr),
- pfn_to_paddr(mfn),
+ pfn_to_paddr(gfn_x(gfn)),
+ pfn_to_paddr(gfn_x(gfn) + nr),
+ pfn_to_paddr(mfn_x(mfn)),
  MATTR_MEM, 0, p2m_mmio_direct,
  d->arch.p2m.default_access);
 }
 
 int unmap_regions_rw_cache(struct domain *d,
-   unsigned long start_gfn,
+   gfn_t gfn,
unsigned long nr,
-   unsigned long mfn)
+   mfn_t mfn)
 {
 return apply_p2m_changes(d, REMOVE,
- pfn_to_paddr(start_gfn),
- pfn_to_paddr(start_gfn + nr),
- pfn_to_paddr(mfn),
+ pfn_to_paddr(gfn_x(gfn)),
+ pfn_to_paddr(gfn_x(gfn) + nr),
+ pfn_to_paddr(mfn_x(mfn)),
  MATTR_MEM, 0, p2m_invalid,
  d->arch.p2m.default_access);
 }
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 8d29eda..6e258b9 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -142,14 +142,14 @@ mfn_t p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t 
*t);
 int p2m_cache_flush(struct domain *d, gfn_t start, unsigned long nr);
 
 int map_regions_rw_cache(struct domain *d,
- unsigned long start_gfn,
- unsigned long nr_mfns,
- unsigned long mfn);
+ gfn_t gfn,
+ unsigned long nr,
+ mfn_t mfn);
 
 int unmap_regions_rw_cache(struct domain *d,
-   unsigned long start_gfn,
-   unsigned long nr_mfns,
-   unsigned long mfn);
+   gfn_t gfn,
+   unsigned long nr,
+   mfn_t mfn);
 
 int map_dev_mmio_region(struct domain *d,
 gfn_t gfn,
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v7 12/14] xen/arm: p2m: Introduce helpers to insert and remove mapping

[Julien Grall]

More the half of the arguments of INSERT and REMOVE are the same for
each callers. Simplify the callers of apply_p2m_changes by adding new
helpers which will fill common arguments with default values.

Signed-off-by: Julien Grall 

---
Changes in v7:
- MATTR_DEV should be used in map_mmio_regions rather than MATTR_MEM

Changes in v5:
- Add missing Signed-off-by

Changes in v4:
- Patch added
---
 xen/arch/arm/p2m.c | 70 --
 1 file changed, 36 insertions(+), 34 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 2ba9477..dd890c2 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1158,17 +1158,40 @@ out:
 return rc;
 }
 
+static inline int p2m_insert_mapping(struct domain *d,
+ gfn_t start_gfn,
+ unsigned long nr,
+ mfn_t mfn,
+ int mattr, p2m_type_t t)
+{
+return apply_p2m_changes(d, INSERT,
+ pfn_to_paddr(gfn_x(start_gfn)),
+ pfn_to_paddr(gfn_x(start_gfn) + nr),
+ pfn_to_paddr(mfn_x(mfn)),
+ mattr, 0, t, d->arch.p2m.default_access);
+}
+
+static inline int p2m_remove_mapping(struct domain *d,
+ gfn_t start_gfn,
+ unsigned long nr,
+ mfn_t mfn)
+{
+return apply_p2m_changes(d, REMOVE,
+ pfn_to_paddr(gfn_x(start_gfn)),
+ pfn_to_paddr(gfn_x(start_gfn) + nr),
+ pfn_to_paddr(mfn_x(mfn)),
+ /* arguments below not used when removing mapping 
*/
+ MATTR_MEM, 0, p2m_invalid,
+ d->arch.p2m.default_access);
+}
+
 int map_regions_rw_cache(struct domain *d,
  gfn_t gfn,
  unsigned long nr,
  mfn_t mfn)
 {
-return apply_p2m_changes(d, INSERT,
- pfn_to_paddr(gfn_x(gfn)),
- pfn_to_paddr(gfn_x(gfn) + nr),
- pfn_to_paddr(mfn_x(mfn)),
- MATTR_MEM, 0, p2m_mmio_direct,
- d->arch.p2m.default_access);
+return p2m_insert_mapping(d, gfn, nr, mfn,
+  MATTR_MEM, p2m_mmio_direct);
 }
 
 int unmap_regions_rw_cache(struct domain *d,
@@ -1176,12 +1199,7 @@ int unmap_regions_rw_cache(struct domain *d,
unsigned long nr,
mfn_t mfn)
 {
-return apply_p2m_changes(d, REMOVE,
- pfn_to_paddr(gfn_x(gfn)),
- pfn_to_paddr(gfn_x(gfn) + nr),
- pfn_to_paddr(mfn_x(mfn)),
- MATTR_MEM, 0, p2m_invalid,
- d->arch.p2m.default_access);
+return p2m_remove_mapping(d, gfn, nr, mfn);
 }
 
 int map_mmio_regions(struct domain *d,
@@ -1189,12 +1207,8 @@ int map_mmio_regions(struct domain *d,
  unsigned long nr,
  mfn_t mfn)
 {
-return apply_p2m_changes(d, INSERT,
- pfn_to_paddr(gfn_x(start_gfn)),
- pfn_to_paddr(gfn_x(start_gfn) + nr),
- pfn_to_paddr(mfn_x(mfn)),
- MATTR_DEV, 0, p2m_mmio_direct,
- d->arch.p2m.default_access);
+return p2m_insert_mapping(d, start_gfn, nr, mfn,
+  MATTR_DEV, p2m_mmio_direct);
 }
 
 int unmap_mmio_regions(struct domain *d,
@@ -1202,12 +1216,7 @@ int unmap_mmio_regions(struct domain *d,
unsigned long nr,
mfn_t mfn)
 {
-return apply_p2m_changes(d, REMOVE,
- pfn_to_paddr(gfn_x(start_gfn)),
- pfn_to_paddr(gfn_x(start_gfn) + nr),
- pfn_to_paddr(mfn_x(mfn)),
- MATTR_DEV, 0, p2m_invalid,
- d->arch.p2m.default_access);
+return p2m_remove_mapping(d, start_gfn, nr, mfn);
 }
 
 int map_dev_mmio_region(struct domain *d,
@@ -1237,22 +1246,15 @@ int guest_physmap_add_entry(struct domain *d,
 unsigned long page_order,
 p2m_type_t t)
 {
-return apply_p2m_changes(d, INSERT,
- pfn_to_paddr(gfn_x(gfn)),
- pfn_to_paddr(gfn_x(gfn) + (1 << page_order)),
- pfn_to_paddr(mfn_x(mfn)), MATTR_MEM, 0, t,
- d->arch.p2m.default_access);
+return p2m_insert_mapping(d, gfn, (1 << page_order), mfn,
+   

[Xen-devel] [PATCH v7 13/14] xen/arm: p2m: Use typesafe gfn for {max, lowest}_mapped_gfn

[Julien Grall]

Signed-off-by: Julien Grall 
Acked-by: Stefano Stabellini 

---
Changes in v6:
- Add Stefano's acked-by

Changes in v4:
- Patch added
---
 xen/arch/arm/mm.c |  2 +-
 xen/arch/arm/p2m.c| 18 +-
 xen/include/asm-arm/p2m.h |  4 ++--
 3 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index b5fc034..4e256c2 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1004,7 +1004,7 @@ int page_is_ram_type(unsigned long mfn, unsigned long 
mem_type)
 
 unsigned long domain_get_maximum_gpfn(struct domain *d)
 {
-return d->arch.p2m.max_mapped_gfn;
+return gfn_x(d->arch.p2m.max_mapped_gfn);
 }
 
 void share_xen_page_with_guest(struct page_info *page,
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index dd890c2..de2ab05 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -976,7 +976,7 @@ static int apply_p2m_changes(struct domain *d,
  * This is set in preempt_count_limit.
  *
  */
-p2m->lowest_mapped_gfn = addr >> PAGE_SHIFT;
+p2m->lowest_mapped_gfn = _gfn(addr >> PAGE_SHIFT);
 rc = -ERESTART;
 goto out;
 
@@ -1117,8 +1117,8 @@ static int apply_p2m_changes(struct domain *d,
 
 if ( op == INSERT )
 {
-p2m->max_mapped_gfn = max(p2m->max_mapped_gfn, egfn);
-p2m->lowest_mapped_gfn = min(p2m->lowest_mapped_gfn, sgfn);
+p2m->max_mapped_gfn = gfn_max(p2m->max_mapped_gfn, _gfn(egfn));
+p2m->lowest_mapped_gfn = gfn_min(p2m->lowest_mapped_gfn, _gfn(sgfn));
 }
 
 rc = 0;
@@ -1383,8 +1383,8 @@ int p2m_init(struct domain *d)
 
 p2m->root = NULL;
 
-p2m->max_mapped_gfn = 0;
-p2m->lowest_mapped_gfn = ULONG_MAX;
+p2m->max_mapped_gfn = _gfn(0);
+p2m->lowest_mapped_gfn = _gfn(ULONG_MAX);
 
 p2m->default_access = p2m_access_rwx;
 p2m->mem_access_enabled = false;
@@ -1401,8 +1401,8 @@ int relinquish_p2m_mapping(struct domain *d)
 struct p2m_domain *p2m = &d->arch.p2m;
 
 return apply_p2m_changes(d, RELINQUISH,
-  pfn_to_paddr(p2m->lowest_mapped_gfn),
-  pfn_to_paddr(p2m->max_mapped_gfn),
+  pfn_to_paddr(gfn_x(p2m->lowest_mapped_gfn)),
+  pfn_to_paddr(gfn_x(p2m->max_mapped_gfn)),
   pfn_to_paddr(mfn_x(INVALID_MFN)),
   MATTR_MEM, 0, p2m_invalid,
   d->arch.p2m.default_access);
@@ -1413,8 +1413,8 @@ int p2m_cache_flush(struct domain *d, gfn_t start, 
unsigned long nr)
 struct p2m_domain *p2m = &d->arch.p2m;
 gfn_t end = gfn_add(start, nr);
 
-start = gfn_max(start, _gfn(p2m->lowest_mapped_gfn));
-end = gfn_min(end, _gfn(p2m->max_mapped_gfn));
+start = gfn_max(start, p2m->lowest_mapped_gfn);
+end = gfn_min(end, p2m->max_mapped_gfn);
 
 return apply_p2m_changes(d, CACHEFLUSH,
  pfn_to_paddr(gfn_x(start)),
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 6e258b9..34096bc 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -34,13 +34,13 @@ struct p2m_domain {
 /* Highest guest frame that's ever been mapped in the p2m
  * Only takes into account ram and foreign mapping
  */
-unsigned long max_mapped_gfn;
+gfn_t max_mapped_gfn;
 
 /* Lowest mapped gfn in the p2m. When releasing mapped gfn's in a
  * preemptible manner this is update to track recall where to
  * resume the search. Apart from during teardown this can only
  * decrease. */
-unsigned long lowest_mapped_gfn;
+gfn_t lowest_mapped_gfn;
 
 /* Gather some statistics for information purposes only */
 struct {
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v7 05/14] xen/arm: Rework the interface of p2m_lookup and use typesafe gfn and mfn

[Julien Grall]

The prototype and the declaration of p2m_lookup disagree on how the
function should be used. One expect a frame number whilst the other
an address.

Thankfully, everyone is using with an address today. However, most of
the callers have to convert a guest frame to an address. Modify
the interface to take a guest physical frame in parameter and return
a machine frame.

Whilst modifying the interface, use typesafe gfn and mfn for clarity
and catching possible misusage.

Signed-off-by: Julien Grall 
Acked-by: Stefano Stabellini 

---
Changes in v6:
- Add Stefano's acked-by

Changes in v4:
- Use INVALID_MFN_T when possible
---
 xen/arch/arm/p2m.c| 43 +++
 xen/arch/arm/traps.c  | 21 +++--
 xen/include/asm-arm/p2m.h |  7 +++
 3 files changed, 37 insertions(+), 34 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index c938dde..54a363a 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -140,14 +140,15 @@ void flush_tlb_domain(struct domain *d)
 }
 
 /*
- * Lookup the MFN corresponding to a domain's PFN.
+ * Lookup the MFN corresponding to a domain's GFN.
  *
  * There are no processor functions to do a stage 2 only lookup therefore we
  * do a a software walk.
  */
-static paddr_t __p2m_lookup(struct domain *d, paddr_t paddr, p2m_type_t *t)
+static mfn_t __p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t *t)
 {
 struct p2m_domain *p2m = &d->arch.p2m;
+const paddr_t paddr = pfn_to_paddr(gfn_x(gfn));
 const unsigned int offsets[4] = {
 zeroeth_table_offset(paddr),
 first_table_offset(paddr),
@@ -158,7 +159,7 @@ static paddr_t __p2m_lookup(struct domain *d, paddr_t 
paddr, p2m_type_t *t)
 ZEROETH_MASK, FIRST_MASK, SECOND_MASK, THIRD_MASK
 };
 lpae_t pte, *map;
-paddr_t maddr = INVALID_PADDR;
+mfn_t mfn = INVALID_MFN;
 paddr_t mask = 0;
 p2m_type_t _t;
 unsigned int level, root_table;
@@ -216,21 +217,22 @@ static paddr_t __p2m_lookup(struct domain *d, paddr_t 
paddr, p2m_type_t *t)
 {
 ASSERT(mask);
 ASSERT(pte.p2m.type != p2m_invalid);
-maddr = (pte.bits & PADDR_MASK & mask) | (paddr & ~mask);
+mfn = _mfn(paddr_to_pfn((pte.bits & PADDR_MASK & mask) |
+(paddr & ~mask)));
 *t = pte.p2m.type;
 }
 
 err:
-return maddr;
+return mfn;
 }
 
-paddr_t p2m_lookup(struct domain *d, paddr_t paddr, p2m_type_t *t)
+mfn_t p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t *t)
 {
-paddr_t ret;
+mfn_t ret;
 struct p2m_domain *p2m = &d->arch.p2m;
 
 spin_lock(&p2m->lock);
-ret = __p2m_lookup(d, paddr, t);
+ret = __p2m_lookup(d, gfn, t);
 spin_unlock(&p2m->lock);
 
 return ret;
@@ -493,8 +495,9 @@ static int __p2m_get_mem_access(struct domain *d, gfn_t gfn,
  * No setting was found in the Radix tree. Check if the
  * entry exists in the page-tables.
  */
-paddr_t maddr = __p2m_lookup(d, gfn_x(gfn) << PAGE_SHIFT, NULL);
-if ( INVALID_PADDR == maddr )
+mfn_t mfn = __p2m_lookup(d, gfn, NULL);
+
+if ( mfn_eq(mfn, INVALID_MFN) )
 return -ESRCH;
 
 /* If entry exists then its rwx. */
@@ -1483,8 +1486,7 @@ int p2m_cache_flush(struct domain *d, xen_pfn_t 
start_mfn, xen_pfn_t end_mfn)
 
 mfn_t gfn_to_mfn(struct domain *d, gfn_t gfn)
 {
-paddr_t p = p2m_lookup(d, pfn_to_paddr(gfn_x(gfn)), NULL);
-return _mfn(p >> PAGE_SHIFT);
+return p2m_lookup(d, gfn, NULL);
 }
 
 /*
@@ -1498,8 +1500,8 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
long flag)
 {
 long rc;
 paddr_t ipa;
-unsigned long maddr;
-unsigned long mfn;
+gfn_t gfn;
+mfn_t mfn;
 xenmem_access_t xma;
 p2m_type_t t;
 struct page_info *page = NULL;
@@ -1508,11 +1510,13 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
long flag)
 if ( rc < 0 )
 goto err;
 
+gfn = _gfn(paddr_to_pfn(ipa));
+
 /*
  * We do this first as this is faster in the default case when no
  * permission is set on the page.
  */
-rc = __p2m_get_mem_access(current->domain, _gfn(paddr_to_pfn(ipa)), &xma);
+rc = __p2m_get_mem_access(current->domain, gfn, &xma);
 if ( rc < 0 )
 goto err;
 
@@ -1561,12 +1565,11 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
long flag)
  * We had a mem_access permission limiting the access, but the page type
  * could also be limiting, so we need to check that as well.
  */
-maddr = __p2m_lookup(current->domain, ipa, &t);
-if ( maddr == INVALID_PADDR )
+mfn = __p2m_lookup(current->domain, gfn, &t);
+if ( mfn_eq(mfn, INVALID_MFN) )
 goto err;
 
-mfn = maddr >> PAGE_SHIFT;
-if ( !mfn_valid(mfn) )
+if ( !mfn_valid(mfn_x(mfn)) )
 goto err;
 
 /*
@@ -1575,7 +1578,7 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
long f

[Xen-devel] [PATCH v7 14/14] xen/arm: p2m: Rework the interface of apply_p2m_changes and use typesafe

[Julien Grall]

Most of the callers of apply_p2m_changes have a GFN, a MFN and the
number of frame to change in hand.

Rather than asking each caller to convert the frame to an address,
rework the interfaces to pass the GFN, MFN and the number of frame.

Note that it would be possible to do more clean-up in apply_p2m_changes,
but this will be done in a follow-up series.

Signed-off-by: Julien Grall 

---
Changes in v4:
- Patch added
---
 xen/arch/arm/p2m.c | 62 --
 1 file changed, 28 insertions(+), 34 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index de2ab05..976f97b 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -906,25 +906,26 @@ static void update_reference_mapping(struct page_info 
*page,
 
 static int apply_p2m_changes(struct domain *d,
  enum p2m_operation op,
- paddr_t start_gpaddr,
- paddr_t end_gpaddr,
- paddr_t maddr,
+ gfn_t sgfn,
+ unsigned long nr,
+ mfn_t smfn,
  int mattr,
  uint32_t mask,
  p2m_type_t t,
  p2m_access_t a)
 {
+paddr_t start_gpaddr = pfn_to_paddr(gfn_x(sgfn));
+paddr_t end_gpaddr = pfn_to_paddr(gfn_x(sgfn) + nr);
+paddr_t maddr = pfn_to_paddr(mfn_x(smfn));
 int rc, ret;
 struct p2m_domain *p2m = &d->arch.p2m;
 lpae_t *mappings[4] = { NULL, NULL, NULL, NULL };
 struct page_info *pages[4] = { NULL, NULL, NULL, NULL };
-paddr_t addr, orig_maddr = maddr;
+paddr_t addr;
 unsigned int level = 0;
 unsigned int cur_root_table = ~0;
 unsigned int cur_offset[4] = { ~0, ~0, ~0, ~0 };
 unsigned int count = 0;
-const unsigned long sgfn = paddr_to_pfn(start_gpaddr),
-egfn = paddr_to_pfn(end_gpaddr);
 const unsigned int preempt_count_limit = (op == MEMACCESS) ? 1 : 0x2000;
 const bool_t preempt = !is_idle_vcpu(current);
 bool_t flush = false;
@@ -986,9 +987,9 @@ static int apply_p2m_changes(struct domain *d,
  * Preempt setting mem_access permissions as required by 
XSA-89,
  * if it's not the last iteration.
  */
-uint32_t progress = paddr_to_pfn(addr) - sgfn + 1;
+uint32_t progress = paddr_to_pfn(addr) - gfn_x(sgfn) + 1;
 
-if ( (egfn - sgfn) > progress && !(progress & mask) )
+if ( nr > progress && !(progress & mask) )
 {
 rc = progress;
 goto out;
@@ -1117,8 +1118,9 @@ static int apply_p2m_changes(struct domain *d,
 
 if ( op == INSERT )
 {
-p2m->max_mapped_gfn = gfn_max(p2m->max_mapped_gfn, _gfn(egfn));
-p2m->lowest_mapped_gfn = gfn_min(p2m->lowest_mapped_gfn, _gfn(sgfn));
+p2m->max_mapped_gfn = gfn_max(p2m->max_mapped_gfn,
+  gfn_add(sgfn, nr));
+p2m->lowest_mapped_gfn = gfn_min(p2m->lowest_mapped_gfn, sgfn);
 }
 
 rc = 0;
@@ -1127,7 +1129,7 @@ out:
 if ( flush )
 {
 flush_tlb_domain(d);
-ret = iommu_iotlb_flush(d, sgfn, egfn - sgfn);
+ret = iommu_iotlb_flush(d, gfn_x(sgfn), nr);
 if ( !rc )
 rc = ret;
 }
@@ -1146,12 +1148,14 @@ out:
 if ( rc < 0 && ( op == INSERT ) &&
  addr != start_gpaddr )
 {
+unsigned long gfn = paddr_to_pfn(addr);
+
 BUG_ON(addr == end_gpaddr);
 /*
  * addr keeps the address of the end of the last successfully-inserted
  * mapping.
  */
-apply_p2m_changes(d, REMOVE, start_gpaddr, addr, orig_maddr,
+apply_p2m_changes(d, REMOVE, sgfn, gfn - gfn_x(sgfn), smfn,
   mattr, 0, p2m_invalid, d->arch.p2m.default_access);
 }
 
@@ -1164,10 +1168,7 @@ static inline int p2m_insert_mapping(struct domain *d,
  mfn_t mfn,
  int mattr, p2m_type_t t)
 {
-return apply_p2m_changes(d, INSERT,
- pfn_to_paddr(gfn_x(start_gfn)),
- pfn_to_paddr(gfn_x(start_gfn) + nr),
- pfn_to_paddr(mfn_x(mfn)),
+return apply_p2m_changes(d, INSERT, start_gfn, nr, mfn,
  mattr, 0, t, d->arch.p2m.default_access);
 }
 
@@ -1176,10 +1177,7 @@ static inline int p2m_remove_mapping(struct domain *d,
  unsigned long nr,
  mfn_t mfn)
 {
-return apply_p2m_changes(d, REMOVE,
- pfn_to_paddr(gfn_x(start_gfn)),
- pfn_to_paddr(gfn_x(start_gfn) + nr),
- pfn_to_paddr(mfn_x(mfn)),
+return apply_p2m_changes(d, REMOVE, start_gfn, nr, mfn,
  /* argumen

[Xen-devel] [PATCH v7 02/14] xen/passthrough: x86: Use INVALID_GFN rather than INVALID_MFN

[Julien Grall]

A variable containing a guest frame should be compared to INVALID_GFN
and not INVALID_MFN.

Signed-off-by: Julien Grall 
Reviewed-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

---
Cc: Suravee Suthikulpanit 

Changes in v6:
- Fix typo in the commit message
- Add Andrew's and Jan' reviewed-by

Changes in v5:
- Patch added
---
 xen/drivers/passthrough/amd/iommu_map.c | 2 +-
 xen/drivers/passthrough/x86/iommu.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/amd/iommu_map.c 
b/xen/drivers/passthrough/amd/iommu_map.c
index 1b914ba..c758459 100644
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -555,7 +555,7 @@ static int update_paging_mode(struct domain *d, unsigned 
long gfn)
 unsigned long old_root_mfn;
 struct domain_iommu *hd = dom_iommu(d);
 
-if ( gfn == INVALID_MFN )
+if ( gfn == INVALID_GFN )
 return -EADDRNOTAVAIL;
 ASSERT(!(gfn >> DEFAULT_DOMAIN_ADDRESS_WIDTH));
 
diff --git a/xen/drivers/passthrough/x86/iommu.c 
b/xen/drivers/passthrough/x86/iommu.c
index a18a608..cd435d7 100644
--- a/xen/drivers/passthrough/x86/iommu.c
+++ b/xen/drivers/passthrough/x86/iommu.c
@@ -61,7 +61,7 @@ int arch_iommu_populate_page_table(struct domain *d)
 unsigned long mfn = page_to_mfn(page);
 unsigned long gfn = mfn_to_gmfn(d, mfn);
 
-if ( gfn != INVALID_MFN )
+if ( gfn != INVALID_GFN )
 {
 ASSERT(!(gfn >> DEFAULT_DOMAIN_ADDRESS_WIDTH));
 BUG_ON(SHARED_M2P(gfn));
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v7 04/14] xen: Use a typesafe to define INVALID_GFN

[Julien Grall]

Also take the opportunity to convert arch/x86/debug.c to the typesafe gfn.

Signed-off-by: Julien Grall 
Reviewed-by: Andrew Cooper 
Acked-by: Stefano Stabellini 
Acked-by: Elena Ufimtseva 

---
Cc: Jan Beulich 
Cc: Paul Durrant 
Cc: Boris Ostrovsky 
Cc: Suravee Suthikulpanit 
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: George Dunlap 
Cc: Tim Deegan 
Cc: Feng Wu 

Changes in v7:
- Add Elena's acked-by

Changes in v6:
- Add Stefano's acked-by for ARM bits
- Remove set of brackets when it is not necessary
- Add Andrew's reviewed-by

Changes in v5:
- Patch added
---
 xen/arch/arm/p2m.c  |  4 ++--
 xen/arch/x86/debug.c| 18 +-
 xen/arch/x86/domain.c   |  2 +-
 xen/arch/x86/hvm/emulate.c  |  7 ---
 xen/arch/x86/hvm/hvm.c  |  6 +++---
 xen/arch/x86/hvm/ioreq.c|  8 
 xen/arch/x86/hvm/svm/nestedsvm.c|  2 +-
 xen/arch/x86/hvm/vmx/vmx.c  |  6 +++---
 xen/arch/x86/mm/altp2m.c|  2 +-
 xen/arch/x86/mm/hap/guest_walk.c| 10 +-
 xen/arch/x86/mm/hap/nested_ept.c|  2 +-
 xen/arch/x86/mm/p2m-pod.c   |  6 +++---
 xen/arch/x86/mm/p2m.c   | 18 +-
 xen/arch/x86/mm/shadow/common.c |  2 +-
 xen/arch/x86/mm/shadow/multi.c  |  2 +-
 xen/arch/x86/mm/shadow/private.h|  2 +-
 xen/drivers/passthrough/amd/iommu_map.c |  2 +-
 xen/drivers/passthrough/vtd/iommu.c |  4 ++--
 xen/drivers/passthrough/x86/iommu.c |  2 +-
 xen/include/asm-x86/guest_pt.h  |  4 ++--
 xen/include/asm-x86/p2m.h   |  2 +-
 xen/include/xen/mm.h|  2 +-
 22 files changed, 57 insertions(+), 56 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index d690602..c938dde 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -479,7 +479,7 @@ static int __p2m_get_mem_access(struct domain *d, gfn_t gfn,
 }
 
 /* If request to get default access. */
-if ( gfn_x(gfn) == INVALID_GFN )
+if ( gfn_eq(gfn, INVALID_GFN) )
 {
 *access = memaccess[p2m->default_access];
 return 0;
@@ -1879,7 +1879,7 @@ long p2m_set_mem_access(struct domain *d, gfn_t gfn, 
uint32_t nr,
 p2m->mem_access_enabled = true;
 
 /* If request to set default access. */
-if ( gfn_x(gfn) == INVALID_GFN )
+if ( gfn_eq(gfn, INVALID_GFN) )
 {
 p2m->default_access = a;
 return 0;
diff --git a/xen/arch/x86/debug.c b/xen/arch/x86/debug.c
index 9213ea7..3030022 100644
--- a/xen/arch/x86/debug.c
+++ b/xen/arch/x86/debug.c
@@ -44,8 +44,7 @@ typedef unsigned char dbgbyte_t;
 
 /* Returns: mfn for the given (hvm guest) vaddr */
 static mfn_t
-dbg_hvm_va2mfn(dbgva_t vaddr, struct domain *dp, int toaddr,
-unsigned long *gfn)
+dbg_hvm_va2mfn(dbgva_t vaddr, struct domain *dp, int toaddr, gfn_t *gfn)
 {
 mfn_t mfn;
 uint32_t pfec = PFEC_page_present;
@@ -53,14 +52,14 @@ dbg_hvm_va2mfn(dbgva_t vaddr, struct domain *dp, int toaddr,
 
 DBGP2("vaddr:%lx domid:%d\n", vaddr, dp->domain_id);
 
-*gfn = paging_gva_to_gfn(dp->vcpu[0], vaddr, &pfec);
-if ( *gfn == INVALID_GFN )
+*gfn = _gfn(paging_gva_to_gfn(dp->vcpu[0], vaddr, &pfec));
+if ( gfn_eq(*gfn, INVALID_GFN) )
 {
 DBGP2("kdb:bad gfn from gva_to_gfn\n");
 return INVALID_MFN;
 }
 
-mfn = get_gfn(dp, *gfn, &gfntype);
+mfn = get_gfn(dp, gfn_x(*gfn), &gfntype);
 if ( p2m_is_readonly(gfntype) && toaddr )
 {
 DBGP2("kdb:p2m_is_readonly: gfntype:%x\n", gfntype);
@@ -72,7 +71,7 @@ dbg_hvm_va2mfn(dbgva_t vaddr, struct domain *dp, int toaddr,
 
 if ( mfn_eq(mfn, INVALID_MFN) )
 {
-put_gfn(dp, *gfn);
+put_gfn(dp, gfn_x(*gfn));
 *gfn = INVALID_GFN;
 }
 
@@ -165,7 +164,8 @@ unsigned int dbg_rw_guest_mem(struct domain *dp, void * 
__user gaddr,
 char *va;
 unsigned long addr = (unsigned long)gaddr;
 mfn_t mfn;
-unsigned long gfn = INVALID_GFN, pagecnt;
+gfn_t gfn = INVALID_GFN;
+unsigned long pagecnt;
 
 pagecnt = min_t(long, PAGE_SIZE - (addr & ~PAGE_MASK), len);
 
@@ -189,8 +189,8 @@ unsigned int dbg_rw_guest_mem(struct domain *dp, void * 
__user gaddr,
 }
 
 unmap_domain_page(va);
-if ( gfn != INVALID_GFN )
-put_gfn(dp, gfn);
+if ( !gfn_eq(gfn, INVALID_GFN) )
+put_gfn(dp, gfn_x(gfn));
 
 addr += pagecnt;
 buf += pagecnt;
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index bb59247..c8c7e2d 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -783,7 +783,7 @@ int arch_domain_soft_reset(struct domain *d)
  * gfn == INVALID_GFN indicates that the shared_info page was never mapped
  * to the domain's address space and there is nothing to replace.
  */
-if ( gfn == INVALID_G

Re: [Xen-devel] [PATCH v2 03/17] libxl/arm: Add a configuration option for ARM DomU ACPI

[Shannon Zhao]

On 2016年07月12日 19:33, Wei Liu wrote:
> On Tue, Jul 12, 2016 at 10:22:39AM +0100, Julien Grall wrote:
> [...]
 > >>Yeah, we can deprecate that field. But we need to take care to not 
 > >>break
 > >>users of the old field.
>>> > >Ok, what name would you suggest?
>> > 
>> > I would suggest b_info->u.acpi
>> > 
> b_info->acpi would be more appropriate.
> 
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index ef614be..a57823d 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -494,11 +494,16 @@ libxl_domain_build_info = Struct("domain_build_info",[
>  # Note that the partial device tree should avoid to use the phandle
>  # 65000 which is reserved by the toolstack.
>  ("device_tree",  string),
> +("acpi", libxl_defbool),
>  ("u", KeyedUnion(None, libxl_domain_type, "type",
>  [("hvm", Struct(None, [("firmware", string),
> ("bios", libxl_bios_type),
> ("pae",  libxl_defbool),
> ("apic", libxl_defbool),
> +   # The following acpi field is
> +   # deprecated. Please use the unified
> +   # acpi field above which works for 
> both
> +   # x86 and ARM.
> ("acpi", libxl_defbool),
> ("acpi_s3",  libxl_defbool),
> ("acpi_s4",  libxl_defbool),
> 
> 
> And then:
> 
> 1. modify xl to set the new field.
> 2. modify libxl to handle compatibility: user of the old field should
>continue to work.
> 
> I know this is a bit terse. Feel free to ask questions if you have any
> doubt.
I'm not sure I understand correctly. While xl is always matching libxl,
so can we just let xl set the new field and libxl to use the new field?
To users, they will still use the configure option "acpi".

Thanks,
-- 
Shannon

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v1 20/20] libxl/acpi: Build ACPI tables for HVMlite guests

[Wei Liu]

On Mon, Jul 11, 2016 at 10:40:17AM -0400, Boris Ostrovsky wrote:
> On 07/11/2016 09:41 AM, Wei Liu wrote:
> > On Mon, Jul 11, 2016 at 09:33:21AM -0400, Boris Ostrovsky wrote:
> >> On 07/11/2016 06:47 AM, Wei Liu wrote:
> >>> On Fri, Jul 08, 2016 at 01:20:46PM -0400, Boris Ostrovsky wrote:
>  On 07/08/2016 12:07 PM, Wei Liu wrote:
> > On Fri, Jul 08, 2016 at 10:48:52AM -0400, Boris Ostrovsky wrote:
> >> On 07/08/2016 06:55 AM, Wei Liu wrote:
>  +
>  +/* Map page that will hold RSDP */
>  +extent = RSDP_ADDRESS >> ctxt.page_shift;
>  +rc = populate_acpi_pages(dom, &extent, 1, &ctxt);
>  +if (rc) {
>  +LOG(ERROR, "%s: populate_acpi_pages for rsdp failed with 
>  %d",
>  +__FUNCTION__, rc);
>  +goto out;
>  +}
>  +config.rsdp = (unsigned long)xc_map_foreign_range(xch, domid,
>  +  
>  ctxt.page_size,
>  +  PROT_READ | 
>  PROT_WRITE,
>  +  RSDP_ADDRESS 
>  >> ctxt.page_shift);
> >>> I think with Anthony's on-going work you should be more flexible for 
> >>> all
> >>> you tables.
> >> Not sure I understand what you mean here. You want the address
> >> (RSDP_ADDRESS) to be a variable as opposed to a macro?
> >>
> > I'm still trying to wrap my head around the possible interaction between
> > Anthony's work and your work.
> >
> > Anthony's work allows dynamically loading of firmware blobs. If you use
> > a fixed address, theoretically it can clash with firmware blobs among
> > other things libxc can load. The high address is a safe bet so that
> > probably won't happen in practice.
> >
> > Anthony's work allows loading arbitrary blobs actually. Can you take
> > advantage of that mechanism as well? That is, to specify all your tables
> > as modules and let libxc handle actually loading them  into guest
> > memory.
> >
> > Does this make sense?
> >
> > Also CC Anthony here.
>  My understanding of Anthony's series is that its goal was to provide an
>  interface to pass DSDT (and maybe some other tables) from the toolstack
>  to hvmloader.
> 
>  Here we don't have hvmloader, we are loading the tables directly into
>  guest's memory.
> 
> >>> Do you use the same hvm_start_info structure? I don't think that
> >>> structure is restricted to hvmloader.
> >>
> >> Yes, we do. However, in PVH(v2) case it will be seen next by the guest
> >> who will expect the tables to already be in memory. I.e. there is no
> >> intermediate Xen component, such as hvmloader, who can load the blobs.
> >>
> > Maybe you misunderstood. Anthony's work will load the blobs into guest
> > memory -- all fields in hvm_start_info points to guest physical address
> > IIRC. Hvmloader might want to relocate them, but that's a different
> > matter.
> 
> What's the status on Anthony's series? I can rebase on top of his tree
> (I might indeed be able to reuse some of his code) but if this is way
> off the dependencies become problematic (because Shannon's series would
> also be delayed).
> 

His series is very close to get merged. I believe toolstack in his
series only require cosmetic changes and hvmloader patches are all
acked.

> >
> >> Having said that, I wonder whether we (both x86 and ARM) could use
> >> Anthony's xc_dom_image.full_acpi_module instead 
> 
> 
> (no full_acpi_module anymore, I was looking at an earlier series
> version. I guess it's system_firmware_module now)
> 
> 
> >> of acpitables_blob that
> >> Shannon's series added. (even if we can't, I think
> >> xc_hvm_firmware_module is the right datastructure to store the blob
> >> since it has both toolstack's virtual and guest's physical addresses).
> >>
> > Yes, that's along the line I'm thinking about.
> 
> So I am confused about xc_hvm_firmware_mode: is guest_addr_out meant to
> be guest's physical or virtual?
> 
> One one hand it looks like virtual:
> 
> in
> https://lists.xenproject.org/archives/html/xen-devel/2016-06/msg02901.html
> +module->guest_addr_out = seg.vstart;
> 
> but then in
> https://lists.xenproject.org/archives/html/xen-devel/2016-06/msg02902.html
> 
> +modlist[index].paddr = module->guest_addr_out;
> 

It should be guest physical.

Wei.

> 
> -boris
> 
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 03/17] libxl/arm: Add a configuration option for ARM DomU ACPI

[Wei Liu]

On Tue, Jul 12, 2016 at 10:17:20PM +0800, Shannon Zhao wrote:
> On 2016年07月12日 19:33, Wei Liu wrote:
> > On Tue, Jul 12, 2016 at 10:22:39AM +0100, Julien Grall wrote:
> > [...]
>  > >>Yeah, we can deprecate that field. But we need to take care to not 
>  > >>break
>  > >>users of the old field.
> >>> > >Ok, what name would you suggest?
> >> > 
> >> > I would suggest b_info->u.acpi
> >> > 
> > b_info->acpi would be more appropriate.
> > 
> > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> > index ef614be..a57823d 100644
> > --- a/tools/libxl/libxl_types.idl
> > +++ b/tools/libxl/libxl_types.idl
> > @@ -494,11 +494,16 @@ libxl_domain_build_info = Struct("domain_build_info",[
> >  # Note that the partial device tree should avoid to use the phandle
> >  # 65000 which is reserved by the toolstack.
> >  ("device_tree",  string),
> > +("acpi", libxl_defbool),
> >  ("u", KeyedUnion(None, libxl_domain_type, "type",
> >  [("hvm", Struct(None, [("firmware", string),
> > ("bios", 
> > libxl_bios_type),
> > ("pae",  libxl_defbool),
> > ("apic", libxl_defbool),
> > +   # The following acpi field is
> > +   # deprecated. Please use the unified
> > +   # acpi field above which works for 
> > both
> > +   # x86 and ARM.
> > ("acpi", libxl_defbool),
> > ("acpi_s3",  libxl_defbool),
> > ("acpi_s4",  libxl_defbool),
> > 
> > 
> > And then:
> > 
> > 1. modify xl to set the new field.
> > 2. modify libxl to handle compatibility: user of the old field should
> >continue to work.
> > 
> > I know this is a bit terse. Feel free to ask questions if you have any
> > doubt.
> I'm not sure I understand correctly. While xl is always matching libxl,
> so can we just let xl set the new field and libxl to use the new field?
> To users, they will still use the configure option "acpi".
> 

We need to distinguish between the library to control Xen (libxl) and
the user of that library (xl). Xl is just one of the possibly users of
libxl. For example, libvirt uses libxl APIs without involving xl at all,
hence my second point.

Wei.

> Thanks,
> -- 
> Shannon

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Shannon Zhao]

On 2016年07月12日 19:35, Wei Liu wrote:
> On Tue, Jul 12, 2016 at 11:47:04AM +0800, Shannon Zhao wrote:
>> > 
>> > 
>> > On 2016/7/6 18:12, Stefano Stabellini wrote:
>>> > > On Wed, 6 Jul 2016, Julien Grall wrote:
> > >> > Hi Stefano,
> > >> > 
> > >> > On 05/07/16 18:13, Stefano Stabellini wrote:
>>> > >>> > > On Thu, 23 Jun 2016, Julien Grall wrote:
> >  > > > On 23/06/2016 04:17, Shannon Zhao wrote:
>>> > > > > > > From: Shannon Zhao 
>>> > > > > > > 
>>> > > > > > > Copy all the ACPI tables to guest space so that 
>>> > > > > > > UEFI or guest could
>>> > > > > > > access them.
>>> > > > > > > 
>>> > > > > > > Signed-off-by: Shannon Zhao 
>>> > > > > > > 
>>> > > > > > > ---
>>> > > > > > >   tools/libxc/xc_dom_arm.c | 51
>>> > > > > > > 
>>> > > > > > >   1 file changed, 51 insertions(+)
>>> > > > > > > 
>>> > > > > > > diff --git a/tools/libxc/xc_dom_arm.c 
>>> > > > > > > b/tools/libxc/xc_dom_arm.c
>>> > > > > > > index 64a8b67..6a0a5b7 100644
>>> > > > > > > --- a/tools/libxc/xc_dom_arm.c
>>> > > > > > > +++ b/tools/libxc/xc_dom_arm.c
>>> > > > > > > @@ -63,6 +63,47 @@ static int 
>>> > > > > > > setup_pgtables_arm(struct xc_dom_image
>>> > > > > > > *dom)
>>> > > > > > > 
>>> > > > > > >   /*
>>> > > > > > > 
>>> > > > > > > */
>>> > > > > > > 
>>> > > > > > > +static int xc_dom_copy_acpi(struct xc_dom_image 
>>> > > > > > > *dom)
>>> > > > > > > +{
>>> > > > > > > +int rc, i;
>>> > > > > > > +uint32_t pages_num = 
>>> > > > > > > ROUNDUP(dom->acpitable_size, XC_PAGE_SHIFT) >>
>>> > > > > > > + XC_PAGE_SHIFT;
>>> > > > > > > +const xen_pfn_t base = GUEST_ACPI_BASE >> 
>>> > > > > > > XC_PAGE_SHIFT;
>>> > > > > > > +xen_pfn_t *p2m;
>>> > > > > > > +void *acpi_pages;
>>> > > > > > > +
>>> > > > > > > +p2m = malloc(pages_num * sizeof(*p2m));
>>> > > > > > > +for (i = 0; i < pages_num; i++)
>>> > > > > > > +p2m[i] = base + i;
>>> > > > > > > +
>>> > > > > > > +rc = 
>>> > > > > > > xc_domain_populate_physmap_exact(dom->xch, 
>>> > > > > > > dom->guest_domid,
>>> > > > > > > +  
>>> > > > > > > pages_num, 0, 0, p2m);
> >  > > > 
> >  > > > H... it looks like this is working because libxl is 
> >  > > > setting the
> >  > > > maximum
> >  > > > size of the domain with some slack (1MB). However, I 
> >  > > > guess the slack was
> >  > > > for
> >  > > > something else. Wei, Stefano, Ian, can you confirm?
>>> > >>> > > 
>>> > >>> > > If I recall correctly, the slack is a magic value coming from 
>>> > >>> > > the
>>> > >>> > > ancient history of toolstacks.
> > >> > 
> > >> > Does it mean we would need to update the slack to take into 
> > >> > account the ACPI
> > >> > blob?
>>> > > Yes, we need to take into account the ACPI blob. Probably not in the
>>> > > slack but directly in mam_memkb.
>> > Sorry, I'm not sure understand this. I found the b_info->max_memkb but
>> > didn't find the slack you said. And how to fix this? Update
>> > b_info->max_memkb or the slack?
> Can you calculate the size of your payload and add that to max_memkb?
> 
Yeah, but the size will be changed if we change the tables in the future
and this also should consider x86, right?

Thanks,
-- 
Shannon

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v6 06/14] xen: Move the hvm_start_info C representation from libxc to public/xen.h

[Anthony PERARD]

Instead of having several representation of hvm_start_info in C, define
it in public/xen.h so both libxc and hvmloader can use it.

Signed-off-by: Anthony PERARD 

---
Changes in V6:
- move C representation to public/arch-x86/hvm/start_info.h instead of
  public/xen.h

Change in V5:
- remove packed attribute.

New in V4.
---
 tools/libxc/include/xc_dom.h | 31 
 tools/libxc/xc_dom_x86.c |  1 +
 xen/include/public/arch-x86/hvm/start_info.h | 53 
 3 files changed, 54 insertions(+), 31 deletions(-)
 create mode 100644 xen/include/public/arch-x86/hvm/start_info.h

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 0629971..de7dca9 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -219,37 +219,6 @@ struct xc_dom_image {
 struct xc_hvm_firmware_module smbios_module;
 };
 
-#if defined(__i386__) || defined(__x86_64__)
-/* C representation of the x86/HVM start info layout.
- *
- * The canonical definition of this layout resides in public/xen.h, this
- * is just a way to represent the layout described there using C types.
- *
- * NB: the packed attribute is not really needed, but it helps us enforce
- * the fact this this is just a representation, and it might indeed
- * be required in the future if there are alignment changes.
- */
-struct hvm_start_info {
-uint32_t magic; /* Contains the magic value 0x336ec578   */
-/* ("xEn3" with the 0x80 bit of the "E" set).*/
-uint32_t version;   /* Version of this structure.*/
-uint32_t flags; /* SIF_xxx flags.*/
-uint32_t nr_modules;/* Number of modules passed to the kernel.   */
-uint64_t modlist_paddr; /* Physical address of an array of   */
-/* hvm_modlist_entry.*/
-uint64_t cmdline_paddr; /* Physical address of the command line. */
-uint64_t rsdp_paddr;/* Physical address of the RSDP ACPI data*/
-/* structure.*/
-} __attribute__((packed));
-
-struct hvm_modlist_entry {
-uint64_t paddr; /* Physical address of the module.   */
-uint64_t size;  /* Size of the module in bytes.  */
-uint64_t cmdline_paddr; /* Physical address of the command line. */
-uint64_t reserved;
-} __attribute__((packed));
-#endif /* x86 */
-
 /* --- pluggable kernel loader - */
 
 struct xc_dom_loader {
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index bc2dbb2..0eab8a7 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "xg_private.h"
diff --git a/xen/include/public/arch-x86/hvm/start_info.h 
b/xen/include/public/arch-x86/hvm/start_info.h
new file mode 100644
index 000..6981187
--- /dev/null
+++ b/xen/include/public/arch-x86/hvm/start_info.h
@@ -0,0 +1,53 @@
+/*
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (c) 2016, Citrix Systems, Inc.
+ */
+
+#ifndef __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__
+#define __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__
+
+/*
+ * C representation of the x86/HVM start info layout.
+ *
+ * The canonical definition of this layout resides in public/xen.h, this
+ * is just a way to represent the layout described there using C types.
+ *
+ */
+struct hvm_start_info {
+uint32_t magic; /* Contains the magic value 0x336ec578   */
+/* ("xEn3" with the 0x80 bit of the "E" set).*/
+uint32_t version;   /* Version of this structure.*/
+uint32_t flags; /* SIF_xxx flags.*/

[Xen-devel] [PATCH v6 09/14] hvmloader: Check modules whereabouts in perform_tests

[Anthony PERARD]

As perform_tests() is going to clear memory past 4MB, we check that the
memory can be use or we skip the tests.

Signed-off-by: Anthony PERARD 

---
Changes in V6:
- define and use TEST_START and PT_END.
- cast addresses to uintptr_t instead of uint32_t.
- use UINTPTR_MAX for upper limit checks, instead of UINT_MAX.
- fix typos
- include xen/arch-x86/hvm/start_info.h
- better check for the cmdlines, now check if a string would cross the
  4GB boundary.

Changes in V5:
- also account for the pages table
- fix coding style
- also check modules cmdline and main cmdline
  and modlist_paddr
- make use of check_overlap.

Changes in v4:
- move the check into the perform_test() function.
- skip tests instead of using BUG.

New in V3
---
 tools/firmware/hvmloader/tests.c | 76 +++-
 1 file changed, 75 insertions(+), 1 deletion(-)

diff --git a/tools/firmware/hvmloader/tests.c b/tools/firmware/hvmloader/tests.c
index fea3ad3..4b5cb93 100644
--- a/tools/firmware/hvmloader/tests.c
+++ b/tools/firmware/hvmloader/tests.c
@@ -20,6 +20,8 @@
  */
 
 #include "util.h"
+#include "config.h"
+#include 
 
 #define TEST_FAIL 0
 #define TEST_PASS 1
@@ -32,8 +34,10 @@
  *  4 page table pages reside at 8MB+4kB to 8MB+20kB.
  *  Pagetables identity-map 0-16MB, except 4kB at va 6MB maps to pa 5MB.
  */
+#define TEST_START (4ul << 20)
 #define PD_START (8ul << 20)
 #define PT_START (PD_START + 4096)
+#define PT_END (PT_START + 4 * PAGE_SIZE)
 
 static void setup_paging(void)
 {
@@ -189,6 +193,37 @@ static int shadow_gs_test(void)
 return (ebx == 2) ? TEST_PASS : TEST_FAIL;
 }
 
+static bool check_test_overlap(uint64_t start, uint64_t size)
+{
+if ( start )
+return check_overlap(start, size,
+ TEST_START,
+ PT_END - TEST_START);
+return false;
+}
+
+/* Only return true if the string overlap with the TEST_START,PT_END */
+static bool check_string_overlap_with_test(uint64_t paddr)
+{
+unsigned len = 0;
+const char *s;
+
+if ( !paddr || paddr > UINTPTR_MAX )
+return false;
+
+s = (char *)(uintptr_t)paddr;
+while ( *s && (uintptr_t)s < UINTPTR_MAX )
+s++;
+
+/* Not valid string, ignore it. */
+if ( (uintptr_t)s == UINTPTR_MAX && *s )
+return false;
+
+len = (uintptr_t)s - paddr;
+
+return check_test_overlap(paddr, len);
+}
+
 void perform_tests(void)
 {
 int i, passed, skipped;
@@ -210,11 +245,50 @@ void perform_tests(void)
 return;
 }
 
+/* Check that tests does not use memory where modules are stored */
+if ( check_test_overlap((uintptr_t)hvm_start_info,
+sizeof(*hvm_start_info)) )
+{
+printf("Skipping tests due to memory used by hvm_start_info\n");
+return;
+}
+if ( check_test_overlap(hvm_start_info->modlist_paddr,
+hvm_start_info->nr_modules *
+  sizeof(struct hvm_modlist_entry)) )
+{
+printf("Skipping tests due to memory used by"
+   " hvm_start_info->modlist\n");
+return;
+}
+for ( i = 0; i < hvm_start_info->nr_modules; i++ )
+{
+const struct hvm_modlist_entry *modlist =
+(void *)(uintptr_t)hvm_start_info->modlist_paddr;
+
+if ( check_test_overlap(modlist[i].paddr, modlist[i].size) )
+{
+printf("Skipping tests due to memory used by module[%d]\n", i);
+return;
+}
+if ( check_string_overlap_with_test(modlist[i].cmdline_paddr) )
+{
+printf("Skipping tests due to memory used by"
+   " module[%d]'s cmdline\n", i);
+return;
+}
+}
+if ( check_string_overlap_with_test(hvm_start_info->cmdline_paddr) )
+{
+printf("Skipping tests due to memory used by the"
+   " hvm_start_info->cmdline\n");
+return;
+}
+
 passed = skipped = 0;
 for ( i = 0; tests[i].test; i++ )
 {
 printf(" - %s ... ", tests[i].description);
-memset((char *)(4ul << 20), 0, 4ul << 20);
+memset((char *)TEST_START, 0, 4ul << 20);
 setup_paging();
 switch ( (*tests[i].test)() )
 {
-- 
Anthony PERARD


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v6 02/14] libxc: Prepare a start info structure for hvmloader

[Anthony PERARD]

... and load BIOS/UEFI firmware into guest memory.

This adds a new firmware module, system_firmware_module. It is loaded in
the guest memory and final location is provided to hvmloader via the
hvm_start_info struct.

This patch create the hvm_start_info struct for HVM guest that have a
device model, so this is now common code with HVM guest without device
model.

Signed-off-by: Anthony PERARD 

---
CC: boris.ostrov...@oracle.com
CC: roger@citrix.com

Changes in V6:
- change description (for verbose output) of the allocation of
  hvm_start_info from "HVMlite start info" to "HVM start info".

Changes in V5:
- in alloc_magic_pages_hvm, check dom->device_model only once instead of
  twice (fold second if into previous else)
- rework add_module_to_list to make it easier to read
- also comment about the intended memory layout of start_info and the
  modules
- in bootlate_hvm(), drop start_page and use start_info as they point to
  the same address
- rename xc_dom_image.bios_module to xc_dom_image.system_firmware_module
- rename module name to "firmware" (was "bios")

Changes in V4:
- change title to suggest the change of beavior
- remove code to load acpi tables (dsdt)
- Update public/xen.h about hvm_start_info available on other HVM guest
  in %ebx.

Changes in V3:
- rename acpi_table_module to full_acpi_module.
- factorise module loading, using new function to load existing optinal
  module, this should not change anything
- should now use the same code to loads modules as for HVMlite VMs.
  this avoid duplication of code.
- no more generic cmdline with a list of modules, each module have its name
  in the module specific cmdline.
- scope change for common code between hvmlite and hvmloader
---
 tools/libxc/include/xc_dom.h   |   3 +
 tools/libxc/xc_dom_hvmloader.c |   3 +
 tools/libxc/xc_dom_x86.c   | 152 +
 xen/include/public/xen.h   |   2 +-
 4 files changed, 116 insertions(+), 44 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 6cb10c4..0629971 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -209,6 +209,9 @@ struct xc_dom_image {
 /* If unset disables the setup of the IOREQ pages. */
 bool device_model;
 
+/* BIOS/Firmware passed to HVMLOADER */
+struct xc_hvm_firmware_module system_firmware_module;
+
 /* Extra ACPI tables passed to HVMLOADER */
 struct xc_hvm_firmware_module acpi_module;
 
diff --git a/tools/libxc/xc_dom_hvmloader.c b/tools/libxc/xc_dom_hvmloader.c
index 8150b74..6eb8516 100644
--- a/tools/libxc/xc_dom_hvmloader.c
+++ b/tools/libxc/xc_dom_hvmloader.c
@@ -169,6 +169,9 @@ static int modules_init(struct xc_dom_image *dom)
 {
 int rc;
 
+rc = module_init_one(dom, &dom->system_firmware_module,
+ "System Firmware module");
+if ( rc ) goto err;
 rc = module_init_one(dom, &dom->acpi_module, "ACPI module");
 if ( rc ) goto err;
 rc = module_init_one(dom, &dom->smbios_module, "SMBIOS module");
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 021f8a8..bc2dbb2 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -69,6 +69,9 @@
 #define round_up(addr, mask) ((addr) | (mask))
 #define round_pg_up(addr)  (((addr) + PAGE_SIZE_X86 - 1) & ~(PAGE_SIZE_X86 - 
1))
 
+#define HVMLOADER_MODULE_MAX_COUNT 1
+#define HVMLOADER_MODULE_NAME_SIZE 10
+
 struct xc_dom_params {
 unsigned levels;
 xen_vaddr_t vaddr_mask;
@@ -590,6 +593,7 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
 xen_pfn_t special_array[X86_HVM_NR_SPECIAL_PAGES];
 xen_pfn_t ioreq_server_array[NR_IOREQ_SERVER_PAGES];
 xc_interface *xch = dom->xch;
+size_t start_info_size = sizeof(struct hvm_start_info);
 
 /* Allocate and clear special pages. */
 for ( i = 0; i < X86_HVM_NR_SPECIAL_PAGES; i++ )
@@ -624,8 +628,6 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
 
 if ( !dom->device_model )
 {
-size_t start_info_size = sizeof(struct hvm_start_info);
-
 if ( dom->cmdline )
 {
 dom->cmdline_size = ROUNDUP(strlen(dom->cmdline) + 1, 8);
@@ -635,17 +637,18 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
 /* Limited to one module. */
 if ( dom->ramdisk_blob )
 start_info_size += sizeof(struct hvm_modlist_entry);
-
-rc = xc_dom_alloc_segment(dom, &dom->start_info_seg,
-  "HVMlite start info", 0, start_info_size);
-if ( rc != 0 )
-{
-DOMPRINTF("Unable to reserve memory for the start info");
-goto out;
-}
 }
 else
 {
+start_info_size +=
+sizeof(struct hvm_modlist_entry) * HVMLOADER_MODULE_MAX_COUNT;
+/*
+ * Add extra space to write modules name.
+ * The HVMLOADER_MODULE_NAME_SIZE accounts for NUL byte.
+ */
+start_info_s

Re: [Xen-devel] [PATCH v2 03/17] libxl/arm: Add a configuration option for ARM DomU ACPI

[Shannon Zhao]

On 2016年07月12日 22:33, Wei Liu wrote:
> On Tue, Jul 12, 2016 at 10:17:20PM +0800, Shannon Zhao wrote:
>> > On 2016年07月12日 19:33, Wei Liu wrote:
>>> > > On Tue, Jul 12, 2016 at 10:22:39AM +0100, Julien Grall wrote:
>>> > > [...]
> >  > >>Yeah, we can deprecate that field. But we need to take 
> >  > >>care to not break
> >  > >>users of the old field.
>>> > >>> > >Ok, what name would you suggest?
> > >> > 
> > >> > I would suggest b_info->u.acpi
> > >> > 
>>> > > b_info->acpi would be more appropriate.
>>> > > 
>>> > > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
>>> > > index ef614be..a57823d 100644
>>> > > --- a/tools/libxl/libxl_types.idl
>>> > > +++ b/tools/libxl/libxl_types.idl
>>> > > @@ -494,11 +494,16 @@ libxl_domain_build_info = 
>>> > > Struct("domain_build_info",[
>>> > >  # Note that the partial device tree should avoid to use the phandle
>>> > >  # 65000 which is reserved by the toolstack.
>>> > >  ("device_tree",  string),
>>> > > +("acpi", libxl_defbool),
>>> > >  ("u", KeyedUnion(None, libxl_domain_type, "type",
>>> > >  [("hvm", Struct(None, [("firmware", string),
>>> > > ("bios", 
>>> > > libxl_bios_type),
>>> > > ("pae",  
>>> > > libxl_defbool),
>>> > > ("apic", 
>>> > > libxl_defbool),
>>> > > +   # The following acpi field is
>>> > > +   # deprecated. Please use the 
>>> > > unified
>>> > > +   # acpi field above which works 
>>> > > for both
>>> > > +   # x86 and ARM.
>>> > > ("acpi", 
>>> > > libxl_defbool),
>>> > > ("acpi_s3",  
>>> > > libxl_defbool),
>>> > > ("acpi_s4",  
>>> > > libxl_defbool),
>>> > > 
>>> > > 
>>> > > And then:
>>> > > 
>>> > > 1. modify xl to set the new field.
>>> > > 2. modify libxl to handle compatibility: user of the old field should
>>> > >continue to work.
>>> > > 
>>> > > I know this is a bit terse. Feel free to ask questions if you have any
>>> > > doubt.
>> > I'm not sure I understand correctly. While xl is always matching libxl,
>> > so can we just let xl set the new field and libxl to use the new field?
>> > To users, they will still use the configure option "acpi".
>> > 
> We need to distinguish between the library to control Xen (libxl) and
> the user of that library (xl). Xl is just one of the possibly users of
> libxl. For example, libvirt uses libxl APIs without involving xl at all,
> hence my second point.
Oh, I see. Thanks for the clarification.

-- 
Shannon

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v6 08/14] hvmloader: Locate the BIOS blob

[Anthony PERARD]

The BIOS blob can be found an entry called "firmware" of the modlist of
the hvm_start_info struct.

The found BIOS blob is not loaded by this patch, but only passed as
argument to bios_load() function.

Signed-off-by: Anthony PERARD 

---
Changes in V6:
- cast addresses to uintptr_t instead of uint32_t.
- use UINTPTR_MAX for the upper boundary checks.
- Do a full check of every things that are used, check that modlist,
  cmdlines, modules lives below 4GB and does not cross the boundary.

Changes in V5:
- don't BUG() on module's paddr having value 0, and just skip.
- fix some coding style
- rename module name to "firmware" (was "bios")
- less use of BUG_ON in get_module_entry() and skip entries instead.
  Only BUG() if the module which match name is not accessible.

Changes in V4:
- add more BUG_ON into get_module_entry(). Check that modules paddr and
  size are 32bits.

Changes in V3:
- fix some codying style
- use module.cmdline to look for a module name instead of the main cmdline
  from hvm_start_info.
---
 tools/firmware/hvmloader/config.h|  2 +-
 tools/firmware/hvmloader/hvmloader.c | 60 ++--
 tools/firmware/hvmloader/ovmf.c  |  3 +-
 tools/firmware/hvmloader/rombios.c   |  3 +-
 4 files changed, 63 insertions(+), 5 deletions(-)

diff --git a/tools/firmware/hvmloader/config.h 
b/tools/firmware/hvmloader/config.h
index b838cf9..4c6d8ad 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -22,7 +22,7 @@ struct bios_config {
 /* ROMS */
 void (*load_roms)(void);
 
-void (*bios_load)(const struct bios_config *config);
+void (*bios_load)(const struct bios_config *config, void *addr, uint32_t 
size);
 
 void (*bios_info_setup)(void);
 void (*bios_info_finish)(void);
diff --git a/tools/firmware/hvmloader/hvmloader.c 
b/tools/firmware/hvmloader/hvmloader.c
index 77c70e0..5c57ab3 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -254,10 +254,57 @@ static void acpi_enable_sci(void)
 BUG_ON(!(pm1a_cnt_val & ACPI_PM1C_SCI_EN));
 }
 
+const struct hvm_modlist_entry *get_module_entry(
+const struct hvm_start_info *info,
+const char *name)
+{
+const struct hvm_modlist_entry *modlist =
+(struct hvm_modlist_entry *)(uintptr_t)info->modlist_paddr;
+unsigned int i;
+
+if ( !modlist ||
+ info->modlist_paddr > UINTPTR_MAX ||
+ (info->modlist_paddr + info->nr_modules * sizeof(*modlist) - 1)
+> UINTPTR_MAX
+ )
+return NULL;
+
+for ( i = 0; i < info->nr_modules; i++ )
+{
+char *module_name = (char*)(uintptr_t)modlist[i].cmdline_paddr;
+
+/* Skip if the module or its cmdline is missing. */
+if ( !module_name || !modlist[i].paddr )
+continue;
+
+/* Skip if the cmdline can not be read. */
+if ( modlist[i].cmdline_paddr > UINTPTR_MAX ||
+ (modlist[i].cmdline_paddr + strlen(name)) > UINTPTR_MAX )
+continue;
+
+if ( !strcmp(name, module_name) )
+{
+if ( modlist[i].paddr > UINTPTR_MAX ||
+ modlist[i].size > UINTPTR_MAX ||
+ (modlist[i].paddr + modlist[i].size - 1) > UINTPTR_MAX )
+{
+printf("Can not load \"%s\" from 0x"PRIllx" (0x"PRIllx")\n",
+   name, PRIllx_arg(modlist[i].paddr),
+   PRIllx_arg(modlist[i].size));
+BUG();
+}
+return &modlist[i];
+}
+}
+
+return NULL;
+}
+
 int main(void)
 {
 const struct bios_config *bios;
 int acpi_enabled;
+const struct hvm_modlist_entry *bios_module;
 
 /* Initialise hypercall stubs with RET, rendering them no-ops. */
 memset((void *)HYPERCALL_PHYSICAL_ADDRESS, 0xc3 /* RET */, PAGE_SIZE);
@@ -293,8 +340,17 @@ int main(void)
 }
 
 printf("Loading %s ...\n", bios->name);
-if ( bios->bios_load )
-bios->bios_load(bios);
+bios_module = get_module_entry(hvm_start_info, "firmware");
+if ( bios_module && bios->bios_load )
+{
+uint32_t paddr = bios_module->paddr;
+
+bios->bios_load(bios, (void*)paddr, bios_module->size);
+}
+else if ( bios->bios_load )
+{
+bios->bios_load(bios, NULL, 0);
+}
 else
 {
 BUG_ON(bios->bios_address + bios->image_size >
diff --git a/tools/firmware/hvmloader/ovmf.c b/tools/firmware/hvmloader/ovmf.c
index db9fa7a..858a2d4 100644
--- a/tools/firmware/hvmloader/ovmf.c
+++ b/tools/firmware/hvmloader/ovmf.c
@@ -93,7 +93,8 @@ static void ovmf_finish_bios_info(void)
 info->checksum = -checksum;
 }
 
-static void ovmf_load(const struct bios_config *config)
+static void ovmf_load(const struct bios_config *config,
+  void *bios_addr, uint32_t bios_length)
 {
 xen_pfn_t mfn;
 uint64_t addr = OVMF_BEGIN;
diff --git a/tools/firmware/hvmloader/rombios.c 
b/tools/firmware/

[Xen-devel] [PATCH v6 07/14] hvmloader: Grab the hvm_start_info pointer

[Anthony PERARD]

Signed-off-by: Anthony PERARD 
Reviewed-by: Konrad Rzeszutek Wilk 
Acked-by: Jan Beulich 

---
Changes in V6:
- include xen/arch-x86/hvm/start_info.h

Change in V4:
- remove struct hvm_info_start redefinition, as it's moved to
  public/xen.h in a previous patch.

Change in V3:
- remove cmdline parser
- load hvm_start_info pointer earlier, before calling main().
- Add struct hvm_start_info definition to hvmloader.
---
 tools/firmware/hvmloader/hvmloader.c | 6 ++
 tools/firmware/hvmloader/util.h  | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/tools/firmware/hvmloader/hvmloader.c 
b/tools/firmware/hvmloader/hvmloader.c
index 716d03c..77c70e0 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -28,6 +28,9 @@
 #include "vnuma.h"
 #include 
 #include 
+#include 
+
+const struct hvm_start_info *hvm_start_info;
 
 asm (
 ".text   \n"
@@ -46,6 +49,8 @@ asm (
 "ljmp $"STR(SEL_CODE32)",$1f \n"
 "1:  movl $stack_top,%esp\n"
 "movl %esp,%ebp  \n"
+/* store HVM start info ptr */
+"mov  %ebx, hvm_start_info   \n"
 "call main   \n"
 /* Relocate real-mode trampoline to 0x0. */
 "mov  $trampoline_start,%esi \n"
@@ -258,6 +263,7 @@ int main(void)
 memset((void *)HYPERCALL_PHYSICAL_ADDRESS, 0xc3 /* RET */, PAGE_SIZE);
 
 printf("HVM Loader\n");
+BUG_ON(hvm_start_info->magic != XEN_HVM_START_MAGIC_VALUE);
 
 init_hypercalls();
 
diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
index 3126817..9808016 100644
--- a/tools/firmware/hvmloader/util.h
+++ b/tools/firmware/hvmloader/util.h
@@ -158,6 +158,9 @@ static inline void cpu_relax(void)
 struct hvm_info_table *get_hvm_info_table(void) __attribute__ ((const));
 #define hvm_info (get_hvm_info_table())
 
+/* HVM start info */
+extern const struct hvm_start_info *hvm_start_info;
+
 /* String and memory functions */
 int strcmp(const char *cs, const char *ct);
 int strncmp(const char *s1, const char *s2, uint32_t n);
-- 
Anthony PERARD


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v6 00/14] Load BIOS via toolstack instead of been embedded in hvmloader.

[Anthony PERARD]

Hi all,

V6:
  few changes detailed in patches.

  Missing acks on the following patches:
1 libxc: Rework extra module initialisation
2 libxc: Prepare a start info structure for hvmloader
5 libxl: Load guest BIOS from file
6 xen: Move the hvm_start_info C representation from libxc to public/xen.h
8 hvmloader: Locate the BIOS blob
9 hvmloader: Check modules whereabouts in perform_tests

Thanks.

Changes in V5:
  quite a few rework

  it as been suggest that "bios" was not quite right to name SeaBIOS/OVMF, so
  when I introduce a new name/variable instead of bios, I tried to use
  system_firmware which is more appropriate, I think, with regards to OVMF.
  Details of the changes in the patches.

  Other changes detailed patches description.

I've look at loading the BIOS via the toolstack instead of having them embedded
in the hvmloader binary. After this patch series, hvmloader compilation would
be indenpendant from SeaBIOS and OVMF compilation.

Here is a general view of the few step to load the BIOS:
- libxl load the BIOS blob into it's memory and add it to struct
  xc_hvm_build_args.system_firmware_module
- libxc load the blob into the guest memory and fill the struct
  hvm_start_info and store a name for each module into the module cmdline.
- hvmloader read the addresses from the hvm_start_info, find out which
  module to load and copy the blob to the right place.

A git tree can be found here:
git://xenbits.xen.org/people/aperard/xen-unstable.git
tag: hvmloader-with-separated-bios-v6

Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Andrew Cooper 
Cc: Jan Beulich 

Regards,

Anthony PERARD (14):
  libxc: Rework extra module initialisation
  libxc: Prepare a start info structure for hvmloader
  configure: #define SEABIOS_PATH and OVMF_PATH
  firmware/makefile: install BIOS blob ...
  libxl: Load guest BIOS from file
  xen: Move the hvm_start_info C representation from libxc to
public/xen.h
  hvmloader: Grab the hvm_start_info pointer
  hvmloader: Locate the BIOS blob
  hvmloader: Check modules whereabouts in perform_tests
  hvmloader: Load SeaBIOS from hvm_start_info modules
  hvmloader: Load OVMF from modules
  hvmloader: bios->bios_load() now needs to be defined
  hvmloader: Always build-in SeaBIOS and OVMF loader
  configure: do not depend on SEABIOS_PATH or OVMF_PATH ...

 docs/man/xl.cfg.pod.5.in |   9 ++
 tools/configure.ac   |  12 ++-
 tools/firmware/Makefile  |  10 +-
 tools/firmware/hvmloader/Makefile|  39 +--
 tools/firmware/hvmloader/config.h|   2 +-
 tools/firmware/hvmloader/hvmloader.c |  82 --
 tools/firmware/hvmloader/ovmf.c  |  34 +++---
 tools/firmware/hvmloader/rombios.c   |   3 +-
 tools/firmware/hvmloader/seabios.c   |  25 +++--
 tools/firmware/hvmloader/tests.c |  76 -
 tools/firmware/hvmloader/util.h  |   3 +
 tools/libxc/include/xc_dom.h |  34 +-
 tools/libxc/xc_dom_hvmloader.c   | 136 
 tools/libxc/xc_dom_x86.c | 153 +++
 tools/libxl/libxl.h  |   8 ++
 tools/libxl/libxl_dom.c  |  61 +++
 tools/libxl/libxl_internal.h |   2 +
 tools/libxl/libxl_paths.c|  10 ++
 tools/libxl/libxl_types.idl  |   1 +
 tools/libxl/xl_cmdimpl.c |  11 +-
 xen/include/public/arch-x86/hvm/start_info.h |  53 ++
 xen/include/public/xen.h |   2 +-
 22 files changed, 511 insertions(+), 255 deletions(-)
 create mode 100644 xen/include/public/arch-x86/hvm/start_info.h

-- 
Anthony PERARD


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v6 04/14] firmware/makefile: install BIOS blob ...

[Anthony PERARD]

... into the firmware directory, along with hvmloader.

Signed-off-by: Anthony PERARD 
Acked-by: Wei Liu 

---
No change in V6.
- acked

Change in V5:
- remove use of "variable" for SEABIOS_ROM and OVMF_ROM location
  there are static location
- install seabios as bios.bin instead of seabios.bin
Change in V4:
- remove install of acpi dsdt table

Change in V3:
- do not check if ROMs file exist before installing, they should exist
- change rules for dsdt_anycpu_qemu_xen.c in oder to generate both .c and
  .aml files without changing temporarly the other dsdt_*.c rules.
---
 tools/firmware/Makefile | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile
index 6cc86ce..82b1f6b 100644
--- a/tools/firmware/Makefile
+++ b/tools/firmware/Makefile
@@ -45,6 +45,16 @@ endif
 install: all
[ -d $(INST_DIR) ] || $(INSTALL_DIR) $(INST_DIR)
[ ! -e $(TARGET) ] || $(INSTALL_DATA) $(TARGET) $(INST_DIR)
+ifeq ($(CONFIG_SEABIOS),y)
+ifeq ($(SEABIOS_PATH),)
+   $(INSTALL_DATA) seabios-dir/out/bios.bin $(INST_DIR)/bios.bin
+endif
+endif
+ifeq ($(CONFIG_OVMF),y)
+ifeq ($(OVMF_PATH),)
+   $(INSTALL_DATA) ovmf-dir/ovmf.bin $(INST_DIR)/ovmf.bin
+endif
+endif
 
 .PHONY: clean
 clean: subdirs-clean
-- 
Anthony PERARD


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v6 12/14] hvmloader: bios->bios_load() now needs to be defined

[Anthony PERARD]

All BIOSes but ROMBIOS needs to be loaded via modules.

ROMBIOS is handled as a special case.

Signed-off-by: Anthony PERARD 
Acked-by: Jan Beulich 

---
Change in V5:
- rename patch, was:
  "hvmloader: Specific bios_load function required"

No change in V4.

Change in V3:
- reprint Main BIOS in bios map with now available information from bios
  modules.
- handle rombios, and keep its built-in ROMs.
---
 tools/firmware/hvmloader/hvmloader.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/tools/firmware/hvmloader/hvmloader.c 
b/tools/firmware/hvmloader/hvmloader.c
index 5c57ab3..b5f51f6 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -341,22 +341,26 @@ int main(void)
 
 printf("Loading %s ...\n", bios->name);
 bios_module = get_module_entry(hvm_start_info, "firmware");
-if ( bios_module && bios->bios_load )
+if ( bios_module )
 {
 uint32_t paddr = bios_module->paddr;
 
 bios->bios_load(bios, (void*)paddr, bios_module->size);
 }
-else if ( bios->bios_load )
+#ifdef ENABLE_ROMBIOS
+else if ( bios == &rombios_config )
 {
 bios->bios_load(bios, NULL, 0);
 }
+#endif
 else
 {
-BUG_ON(bios->bios_address + bios->image_size >
-   HVMLOADER_PHYSICAL_ADDRESS);
-memcpy((void *)bios->bios_address, bios->image,
-   bios->image_size);
+/*
+ * If there is no BIOS module supplied and if there is no embeded BIOS
+ * image, then we failed. Only rombios might have an embedded bios 
blob.
+ */
+printf("no BIOS ROM image found\n");
+BUG();
 }
 
 if ( (hvm_info->nr_vcpus > 1) || hvm_info->apic_mode )
-- 
Anthony PERARD


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v6 10/14] hvmloader: Load SeaBIOS from hvm_start_info modules

[Anthony PERARD]

... and do not include the SeaBIOS ROM into hvmloader anymore.

This also fix the dependency on roms.inc, hvmloader.o does not include it.

Signed-off-by: Anthony PERARD 
Acked-by: Jan Beulich 

---
Change in V6:
  acked

Change in V5:
- update BUG_ON in seabios_setup_e820().

Change in V4:
- check that seabios_config.bios_address have a probably good value
  instead of checking only if it's set.

Change in V3:
- change makefile to not include seabios roms into roms.inc.
- update the struct bios_config with the location of the bios blob.
---
 tools/firmware/hvmloader/Makefile  | 15 +--
 tools/firmware/hvmloader/seabios.c | 25 +++--
 2 files changed, 16 insertions(+), 24 deletions(-)

diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index f2f4791..ed0bfad 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -45,7 +45,6 @@ CIRRUSVGA_DEBUG ?= n
 
 OVMF_DIR := ../ovmf-dir
 ROMBIOS_DIR := ../rombios
-SEABIOS_DIR := ../seabios-dir
 
 ifeq ($(CONFIG_ROMBIOS),y)
 STDVGA_ROM:= ../vgabios/VGABIOS-lgpl-latest.bin
@@ -80,19 +79,13 @@ endif
 ifeq ($(CONFIG_SEABIOS),y)
 OBJS += seabios.o
 CFLAGS += -DENABLE_SEABIOS
-ifeq ($(SEABIOS_PATH),)
-   SEABIOS_ROM := $(SEABIOS_DIR)/out/bios.bin
-else
-   SEABIOS_ROM := $(SEABIOS_PATH)
-endif
-ROMS += $(SEABIOS_ROM)
 endif
 
 .PHONY: all
 all: subdirs-all
$(MAKE) hvmloader
 
-ovmf.o rombios.o seabios.o hvmloader.o: roms.inc
+ovmf.o rombios.o: roms.inc
 smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
 
 hvmloader: $(OBJS) acpi/acpi.a
@@ -109,12 +102,6 @@ ifneq ($(ROMBIOS_ROM),)
echo "#endif" >> $@.new
 endif
 
-ifneq ($(SEABIOS_ROM),)
-   echo "#ifdef ROM_INCLUDE_SEABIOS" >> $@.new
-   sh ./mkhex seabios $(SEABIOS_ROM) >> $@.new
-   echo "#endif" >> $@.new
-endif
-
 ifneq ($(OVMF_ROM),)
echo "#ifdef ROM_INCLUDE_OVMF" >> $@.new
sh ./mkhex ovmf $(OVMF_ROM) >> $@.new
diff --git a/tools/firmware/hvmloader/seabios.c 
b/tools/firmware/hvmloader/seabios.c
index c6b3d9f..c5d2b34 100644
--- a/tools/firmware/hvmloader/seabios.c
+++ b/tools/firmware/hvmloader/seabios.c
@@ -27,9 +27,6 @@
 #include "smbios_types.h"
 #include "acpi/acpi2_0.h"
 
-#define ROM_INCLUDE_SEABIOS
-#include "roms.inc"
-
 extern unsigned char dsdt_anycpu_qemu_xen[];
 extern int dsdt_anycpu_qemu_xen_len;
 
@@ -127,22 +124,30 @@ static void seabios_setup_e820(void)
 struct e820entry *e820 = scratch_alloc(sizeof(struct e820entry)*16, 0);
 info->e820 = (uint32_t)e820;
 
+/* Upper boundary already checked by seabios_load(). */
+BUG_ON(seabios_config.bios_address < 0x000c);
 /* SeaBIOS reserves memory in e820 as necessary so no low reservation. */
-info->e820_nr = build_e820_table(e820, 0, 0x10-sizeof(seabios));
+info->e820_nr = build_e820_table(e820, 0, seabios_config.bios_address);
 dump_e820_table(e820, info->e820_nr);
 }
 
-struct bios_config seabios_config = {
-.name = "SeaBIOS",
+static void seabios_load(const struct bios_config *bios,
+ void *bios_addr, uint32_t bios_length)
+{
+unsigned int bios_dest = 0x10 - bios_length;
 
-.image = seabios,
-.image_size = sizeof(seabios),
+BUG_ON(bios_dest + bios_length > HVMLOADER_PHYSICAL_ADDRESS);
+memcpy((void *)bios_dest, bios_addr, bios_length);
+seabios_config.bios_address = bios_dest;
+seabios_config.image_size = bios_length;
+}
 
-.bios_address = 0x10 - sizeof(seabios),
+struct bios_config seabios_config = {
+.name = "SeaBIOS",
 
 .load_roms = NULL,
 
-.bios_load = NULL,
+.bios_load = seabios_load,
 
 .bios_info_setup = seabios_setup_bios_info,
 .bios_info_finish = seabios_finish_bios_info,
-- 
Anthony PERARD


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v6 01/14] libxc: Rework extra module initialisation

[Anthony PERARD]

This patch use xc_dom_alloc_segment() to allocate the memory space for the
ACPI modules and the SMBIOS modules. This is to replace the arbitrary
placement of 1MB (+ extra for MB alignement) after the hvmloader image.

This patch can help if one add extra ACPI table and hvmloader contain
OVMF (OVMF is a 2MB binary), as in that case the extra ACPI table could
easily be loaded past the address 4MB, but hvmloader use a range of
memory from 4MB to 10MB to perform tests and in the process, clears the
memory, before loading the modules.

Signed-off-by: Anthony PERARD 

---
Changes in V6:
- in module_init_one(), check that the module is to be loaded bellow
  dom->mmio_start instead of UINT32_MAX.

Changes in V5:
- rewrite patch description

Changes in V4:
- check that guest_addr_out have a reasonable value.

New patch in V3.
---
 tools/libxc/xc_dom_hvmloader.c | 133 +
 1 file changed, 40 insertions(+), 93 deletions(-)

diff --git a/tools/libxc/xc_dom_hvmloader.c b/tools/libxc/xc_dom_hvmloader.c
index 330d5e8..8150b74 100644
--- a/tools/libxc/xc_dom_hvmloader.c
+++ b/tools/libxc/xc_dom_hvmloader.c
@@ -129,98 +129,54 @@ static elf_errorstatus xc_dom_parse_hvm_kernel(struct 
xc_dom_image *dom)
 return rc;
 }
 
-static int modules_init(struct xc_dom_image *dom,
-uint64_t vend, struct elf_binary *elf,
-uint64_t *mstart_out, uint64_t *mend_out)
+static int module_init_one(struct xc_dom_image *dom,
+   struct xc_hvm_firmware_module *module,
+   char *name)
 {
-#define MODULE_ALIGN 1UL << 7
-#define MB_ALIGN 1UL << 20
-#define MKALIGN(x, a) (((uint64_t)(x) + (a) - 1) & ~(uint64_t)((a) - 1))
-uint64_t total_len = 0, offset1 = 0;
+struct xc_dom_seg seg;
+void *dest;
 
-if ( dom->acpi_module.length == 0 && dom->smbios_module.length == 0 )
-return 0;
-
-/* Find the total length for the firmware modules with a reasonable large
- * alignment size to align each the modules.
- */
-total_len = MKALIGN(dom->acpi_module.length, MODULE_ALIGN);
-offset1 = total_len;
-total_len += MKALIGN(dom->smbios_module.length, MODULE_ALIGN);
-
-/* Want to place the modules 1Mb+change behind the loader image. */
-*mstart_out = MKALIGN(elf->pend, MB_ALIGN) + (MB_ALIGN);
-*mend_out = *mstart_out + total_len;
-
-if ( *mend_out > vend )
-return -1;
-
-if ( dom->acpi_module.length != 0 )
-dom->acpi_module.guest_addr_out = *mstart_out;
-if ( dom->smbios_module.length != 0 )
-dom->smbios_module.guest_addr_out = *mstart_out + offset1;
+if ( module->length )
+{
+if ( xc_dom_alloc_segment(dom, &seg, name, 0, module->length) )
+goto err;
+dest = xc_dom_seg_to_ptr(dom, &seg);
+if ( dest == NULL )
+{
+DOMPRINTF("%s: xc_dom_seg_to_ptr(dom, &seg) => NULL",
+  __FUNCTION__);
+goto err;
+}
+memcpy(dest, module->data, module->length);
+module->guest_addr_out = seg.vstart;
+
+assert(dom->mmio_start > 0 && dom->mmio_start < UINT32_MAX);
+if ( module->guest_addr_out > dom->mmio_start ||
+ module->guest_addr_out + module->length > dom->mmio_start )
+{
+DOMPRINTF("%s: Module %s would be loaded abrove 4GB",
+  __FUNCTION__, name);
+goto err;
+}
+}
 
 return 0;
+err:
+return -1;
 }
 
-static int loadmodules(struct xc_dom_image *dom,
-   uint64_t mstart, uint64_t mend,
-   uint32_t domid)
+static int modules_init(struct xc_dom_image *dom)
 {
-privcmd_mmap_entry_t *entries = NULL;
-unsigned long pfn_start;
-unsigned long pfn_end;
-size_t pages;
-uint32_t i;
-uint8_t *dest;
-int rc = -1;
-xc_interface *xch = dom->xch;
-
-if ( mstart == 0 || mend == 0 )
-return 0;
-
-pfn_start = (unsigned long)(mstart >> PAGE_SHIFT);
-pfn_end = (unsigned long)((mend + PAGE_SIZE - 1) >> PAGE_SHIFT);
-pages = pfn_end - pfn_start;
-
-/* Map address space for module list. */
-entries = calloc(pages, sizeof(privcmd_mmap_entry_t));
-if ( entries == NULL )
-goto error_out;
-
-for ( i = 0; i < pages; i++ )
-entries[i].mfn = (mstart >> PAGE_SHIFT) + i;
-
-dest = xc_map_foreign_ranges(
-xch, domid, pages << PAGE_SHIFT, PROT_READ | PROT_WRITE, 1 << 
PAGE_SHIFT,
-entries, pages);
-if ( dest == NULL )
-goto error_out;
-
-/* Zero the range so padding is clear between modules */
-memset(dest, 0, pages << PAGE_SHIFT);
-
-/* Load modules into range */
-if ( dom->acpi_module.length != 0 )
-{
-memcpy(dest,
-   dom->acpi_module.data,
-   dom->acpi_module.length);
-}
-if ( dom->smbios_module.length != 0 )
-{
-memcpy(dest + (dom->smbios

[Xen-devel] [PATCH v6 05/14] libxl: Load guest BIOS from file

[Anthony PERARD]

The path to the BIOS blob can be overriden by the xl's
bios_path_override option, or provided by u.hvm.bios_firmware in the
domain_build_info struct by other libxl user.

Signed-off-by: Anthony PERARD 

---
Changes in V6:
- use goto for error handling of libxl__load_hvm_firmware_module()

Changes in V5:
- man page, use B<> to highlight config option in description.
- rename config option from `bios_override` to `bios_path_override`
- store libxl_read_file_contents() return value into r instead of e
  (just renamed the variable)
- rename domain_build_info.u.hvm.bios_firmware to system_firmware

Changes in V4:
- updating man page to have bios_override described.
- return ERROR_INVAL in libxl__load_hvm_firmware_module when the file is
  empty.

Changes in V3:
- move seabios_path and ovmf_path to libxl_path.c (with renaming)
- fix some coding style
- warn for empty file
- remove rombios stuff (will still be built-in hvmloader)
- rename field bios_filename in domain_build_info to bios_firmware to
  follow naming of acpi and smbios.
- log an error after libxl_read_file_contents() only when it return ENOENT
- return an error on empty file.
- added #define LIBXL_HAVE_BUILDINFO_HVM_BIOS_FIRMWARE
---
 docs/man/xl.cfg.pod.5.in |  9 +++
 tools/libxl/libxl.h  |  8 ++
 tools/libxl/libxl_dom.c  | 61 
 tools/libxl/libxl_internal.h |  2 ++
 tools/libxl/libxl_paths.c| 10 
 tools/libxl/libxl_types.idl  |  1 +
 tools/libxl/xl_cmdimpl.c | 11 +---
 7 files changed, 99 insertions(+), 3 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index 3bb27d0..a685b83 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -1212,6 +1212,15 @@ Requires device_model_version=qemu-xen.
 
 =back
 
+=item B
+
+Override the path to the blob to be used as BIOS. The blob provided here MUST
+be consistent with the B which you have specified. You should not
+normally need to specify this option.
+
+This options does not have any effect if using B or
+B.
+
 =item B
 
 Hide or expose the IA32 Physical Address Extensions. These extensions
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 2c0f868..2b1f678 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -928,6 +928,14 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst, 
libxl_mac *src);
 #define LIBXL_HAVE_CHECKPOINTED_STREAM 1
 
 /*
+ * LIBXL_HAVE_BUILDINFO_HVM_SYSTEM_FIRMWARE
+ *
+ * libxl_domain_build_info has u.hvm.system_firmware field which can be use
+ * to provide a different firmware blob (like SeaBIOS or OVMF).
+ */
+#define LIBXL_HAVE_BUILDINFO_HVM_SYSTEM_FIRMWARE
+
+/*
  * ERROR_REMUS_XXX error code only exists from Xen 4.5, Xen 4.6 and it
  * is changed to ERROR_CHECKPOINT_XXX in Xen 4.7
  */
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index ec29060..2a1793d 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -862,6 +862,42 @@ err:
 return ret;
 }
 
+static int libxl__load_hvm_firmware_module(libxl__gc *gc,
+   const char *filename,
+   const char *what,
+   struct xc_hvm_firmware_module *m)
+{
+int datalen = 0;
+void *data = NULL;
+int r, rc;
+
+LOG(DEBUG, "Loading %s: %s", what, filename);
+r = libxl_read_file_contents(CTX, filename, &data, &datalen);
+if (r) {
+/*
+ * Print a message only on ENOENT, other errors are logged by the
+ * function libxl_read_file_contents().
+ */
+if (r == ENOENT)
+LOGEV(ERROR, r, "failed to read %s file", what);
+rc =  ERROR_FAIL;
+goto out;
+}
+libxl__ptr_add(gc, data);
+if (datalen) {
+/* Only accept non-empty files */
+m->data = data;
+m->length = datalen;
+} else {
+LOG(ERROR, "file %s for %s is empty", filename, what);
+rc = ERROR_INVAL;
+goto out;
+}
+rc = 0;
+out:
+return rc;
+}
+
 static int libxl__domain_firmware(libxl__gc *gc,
   libxl_domain_build_info *info,
   struct xc_dom_image *dom)
@@ -871,6 +907,7 @@ static int libxl__domain_firmware(libxl__gc *gc,
 int e, rc;
 int datalen = 0;
 void *data;
+const char *bios_filename = NULL;
 
 if (info->u.hvm.firmware)
 firmware = info->u.hvm.firmware;
@@ -914,6 +951,30 @@ static int libxl__domain_firmware(libxl__gc *gc,
 goto out;
 }
 
+if (info->device_model_version == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
+if (info->u.hvm.system_firmware) {
+bios_filename = info->u.hvm.system_firmware;
+} else {
+switch (info->u.hvm.bios) {
+case LIBXL_BIOS_TYPE_SEABIOS:
+bios_filename = libxl__seabios_path();
+break;
+case LIBXL_BIOS_TYPE_

[Xen-devel] [PATCH v6 03/14] configure: #define SEABIOS_PATH and OVMF_PATH

[Anthony PERARD]

Those paths are to be used by libxl, in order to load the firmware in
memory. If a system path is not defined via --with-system-seabios or
--with-system-ovmf, then default to the Xen firmware directory.

Signed-off-by: Anthony PERARD 
Reviewed-by: Konrad Rzeszutek Wilk 
Acked-by: Wei Liu 

---
Please, run ./autogen.sh on this patch.

Change in V5:
  - rename seabios.bin to bios.bin.
---
 tools/configure.ac | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/tools/configure.ac b/tools/configure.ac
index 87e14a8..af3b6e9 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -220,6 +220,9 @@ AC_ARG_WITH([system-seabios],
 esac
 ],[])
 AC_SUBST(seabios_path)
+AC_DEFINE_UNQUOTED([SEABIOS_PATH],
+   ["${seabios_path:-$XENFIRMWAREDIR/bios.bin}"],
+   [SeaBIOS path])
 
 AC_ARG_WITH([system-ovmf],
 AS_HELP_STRING([--with-system-ovmf@<:@=PATH@:>@],
@@ -231,6 +234,9 @@ AC_ARG_WITH([system-ovmf],
 esac
 ],[])
 AC_SUBST(ovmf_path)
+AC_DEFINE_UNQUOTED([OVMF_PATH],
+   ["${ovmf_path:-$XENFIRMWAREDIR/ovmf.bin}"],
+   [OVMF path])
 
 AC_ARG_WITH([extra-qemuu-configure-args],
 AS_HELP_STRING([--with-extra-qemuu-configure-args@<:@="--ARG1 ..."@:>@],
-- 
Anthony PERARD


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v6 11/14] hvmloader: Load OVMF from modules

[Anthony PERARD]

... and do not include the OVMF ROM into hvmloader anymore.

Signed-off-by: Anthony PERARD 
Acked-by: Jan Beulich 

---
Change in V5:
- define OVMF_END macro
- fix some cast coding style

Change in V4:
- check if source and dest of ovmf binary does not overlaps

Change in V3:
- change makefile to not include ovmf rom into roms.inc.
- update the struct bios_config with bios destination
---
 tools/firmware/hvmloader/Makefile | 15 +--
 tools/firmware/hvmloader/ovmf.c   | 31 ++-
 2 files changed, 15 insertions(+), 31 deletions(-)

diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index ed0bfad..dee1c6b 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -43,7 +43,6 @@ endif
 
 CIRRUSVGA_DEBUG ?= n
 
-OVMF_DIR := ../ovmf-dir
 ROMBIOS_DIR := ../rombios
 
 ifeq ($(CONFIG_ROMBIOS),y)
@@ -61,12 +60,6 @@ ROMS :=
 ifeq ($(CONFIG_OVMF),y)
 OBJS += ovmf.o
 CFLAGS += -DENABLE_OVMF
-ifeq ($(OVMF_PATH),)
-   OVMF_ROM := $(OVMF_DIR)/ovmf.bin
-else
-   OVMF_ROM := $(OVMF_PATH)
-endif
-ROMS += $(OVMF_ROM)
 endif
 
 ifeq ($(CONFIG_ROMBIOS),y)
@@ -85,7 +78,7 @@ endif
 all: subdirs-all
$(MAKE) hvmloader
 
-ovmf.o rombios.o: roms.inc
+rombios.o: roms.inc
 smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
 
 hvmloader: $(OBJS) acpi/acpi.a
@@ -102,12 +95,6 @@ ifneq ($(ROMBIOS_ROM),)
echo "#endif" >> $@.new
 endif
 
-ifneq ($(OVMF_ROM),)
-   echo "#ifdef ROM_INCLUDE_OVMF" >> $@.new
-   sh ./mkhex ovmf $(OVMF_ROM) >> $@.new
-   echo "#endif" >> $@.new 
-endif 
-
 ifneq ($(STDVGA_ROM),)
echo "#ifdef ROM_INCLUDE_VGABIOS" >> $@.new
sh ./mkhex vgabios_stdvga $(STDVGA_ROM) >> $@.new
diff --git a/tools/firmware/hvmloader/ovmf.c b/tools/firmware/hvmloader/ovmf.c
index 858a2d4..59d0e45 100644
--- a/tools/firmware/hvmloader/ovmf.c
+++ b/tools/firmware/hvmloader/ovmf.c
@@ -34,17 +34,11 @@
 #include 
 #include 
 
-#define ROM_INCLUDE_OVMF
-#include "roms.inc"
-
-#define OVMF_SIZE   (sizeof(ovmf))
 #define OVMF_MAXOFFSET  0x000FULL
-#define OVMF_BEGIN  (0x1ULL - ((OVMF_SIZE + 
OVMF_MAXOFFSET) & ~OVMF_MAXOFFSET))
-#define OVMF_END(OVMF_BEGIN + OVMF_SIZE)
+#define OVMF_END0x1ULL
 #define LOWCHUNK_BEGIN  0x000F
 #define LOWCHUNK_SIZE   0x0001
 #define LOWCHUNK_MAXOFFSET  0x
-#define LOWCHUNK_END(OVMF_BEGIN + OVMF_SIZE)
 #define OVMF_INFO_PHYSICAL_ADDRESS 0x1000
 
 extern unsigned char dsdt_anycpu_qemu_xen[];
@@ -97,24 +91,31 @@ static void ovmf_load(const struct bios_config *config,
   void *bios_addr, uint32_t bios_length)
 {
 xen_pfn_t mfn;
-uint64_t addr = OVMF_BEGIN;
+uint64_t addr = OVMF_END
+- ((bios_length + OVMF_MAXOFFSET) & ~OVMF_MAXOFFSET);
+uint64_t ovmf_end = addr + bios_length;
+
+ovmf_config.bios_address = addr;
+ovmf_config.image_size = bios_length;
 
 /* Copy low-reset vector portion. */
-memcpy((void *) LOWCHUNK_BEGIN, (uint8_t *) config->image
-   + OVMF_SIZE
-   - LOWCHUNK_SIZE,
+memcpy((void *)LOWCHUNK_BEGIN,
+   (uint8_t *)bios_addr + bios_length - LOWCHUNK_SIZE,
LOWCHUNK_SIZE);
 
 /* Ensure we have backing page prior to moving FD. */
-while ( (addr >> PAGE_SHIFT) != (OVMF_END >> PAGE_SHIFT) )
+while ( (addr >> PAGE_SHIFT) != (ovmf_end >> PAGE_SHIFT) )
 {
 mfn = (uint32_t) (addr >> PAGE_SHIFT);
 addr += PAGE_SIZE;
 mem_hole_populate_ram(mfn, 1);
 }
 
+/* Check that source and destination does not overlaps. */
+BUG_ON(addr + bios_length > (unsigned)bios_addr &&
+   addr < (unsigned)bios_addr + bios_length);
 /* Copy FD. */
-memcpy((void *) OVMF_BEGIN, config->image, OVMF_SIZE);
+memcpy((void *)ovmf_config.bios_address, bios_addr, bios_length);
 }
 
 static void ovmf_acpi_build_tables(void)
@@ -151,10 +152,6 @@ static void ovmf_setup_e820(void)
 struct bios_config ovmf_config =  {
 .name = "OVMF",
 
-.image = ovmf,
-.image_size = sizeof(ovmf),
-
-.bios_address = OVMF_BEGIN,
 .bios_load = ovmf_load,
 
 .load_roms = 0,
-- 
Anthony PERARD


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v6 13/14] hvmloader: Always build-in SeaBIOS and OVMF loader

[Anthony PERARD]

Signed-off-by: Anthony PERARD 
Acked-by: Jan Beulich 
---
 tools/firmware/hvmloader/Makefile| 11 +--
 tools/firmware/hvmloader/hvmloader.c |  4 
 2 files changed, 1 insertion(+), 14 deletions(-)

diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index dee1c6b..9f7357f 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -37,6 +37,7 @@ OBJS  = hvmloader.o mp_tables.o util.o smbios.o
 OBJS += smp.o cacheattr.o xenbus.o vnuma.o
 OBJS += e820.o pci.o pir.o ctype.o
 OBJS += hvm_param.o
+OBJS += ovmf.o seabios.o
 ifeq ($(debug),y)
 OBJS += tests.o
 endif
@@ -57,11 +58,6 @@ endif
 
 ROMS := 
 
-ifeq ($(CONFIG_OVMF),y)
-OBJS += ovmf.o
-CFLAGS += -DENABLE_OVMF
-endif
-
 ifeq ($(CONFIG_ROMBIOS),y)
 OBJS += optionroms.o 32bitbios_support.o rombios.o
 CFLAGS += -DENABLE_ROMBIOS
@@ -69,11 +65,6 @@ ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
 ROMS += $(ROMBIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) $(ETHERBOOT_ROMS)
 endif
 
-ifeq ($(CONFIG_SEABIOS),y)
-OBJS += seabios.o
-CFLAGS += -DENABLE_SEABIOS
-endif
-
 .PHONY: all
 all: subdirs-all
$(MAKE) hvmloader
diff --git a/tools/firmware/hvmloader/hvmloader.c 
b/tools/firmware/hvmloader/hvmloader.c
index b5f51f6..61875a0 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -210,12 +210,8 @@ struct bios_info {
 #ifdef ENABLE_ROMBIOS
 { "rombios", &rombios_config, },
 #endif
-#ifdef ENABLE_SEABIOS
 { "seabios", &seabios_config, },
-#endif
-#ifdef ENABLE_OVMF
 { "ovmf", &ovmf_config, },
-#endif
 { NULL, NULL }
 };
 
-- 
Anthony PERARD


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v6 14/14] configure: do not depend on SEABIOS_PATH or OVMF_PATH ...

[Anthony PERARD]

... to compile SeaBIOS and OVMF. Only depend on CONFIG_*.

If --with-system-* configure option is used, then set *_CONFIG=n to not
compile SEABIOS and OVMF.

Signed-off-by: Anthony PERARD 
Reviewed-by: Konrad Rzeszutek Wilk 
Acked-by: Wei Liu 

---
Please, run ./autogen.sh on this patch.

No change in V5.

Change in V4:
- change subject prefix
---
 tools/configure.ac  | 6 --
 tools/firmware/Makefile | 8 
 2 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/tools/configure.ac b/tools/configure.ac
index af3b6e9..0229d44 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -214,12 +214,13 @@ AC_ARG_WITH([system-seabios],
 AS_HELP_STRING([--with-system-seabios@<:@=PATH@:>@],
[Use system supplied seabios PATH instead of building and installing
 our own version]),[
+# Disable compilation of SeaBIOS.
+seabios=n
 case $withval in
 no) seabios_path= ;;
 *)  seabios_path=$withval ;;
 esac
 ],[])
-AC_SUBST(seabios_path)
 AC_DEFINE_UNQUOTED([SEABIOS_PATH],
["${seabios_path:-$XENFIRMWAREDIR/bios.bin}"],
[SeaBIOS path])
@@ -228,12 +229,13 @@ AC_ARG_WITH([system-ovmf],
 AS_HELP_STRING([--with-system-ovmf@<:@=PATH@:>@],
[Use system supplied OVMF PATH instead of building and installing
 our own version]),[
+# Disable compilation of OVMF.
+ovmf=n
 case $withval in
 no) ovmf_path= ;;
 *)  ovmf_path=$withval ;;
 esac
 ],[])
-AC_SUBST(ovmf_path)
 AC_DEFINE_UNQUOTED([OVMF_PATH],
["${ovmf_path:-$XENFIRMWAREDIR/ovmf.bin}"],
[OVMF path])
diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile
index 82b1f6b..cf09ad2 100644
--- a/tools/firmware/Makefile
+++ b/tools/firmware/Makefile
@@ -6,12 +6,8 @@ TARGET  := hvmloader/hvmloader
 INST_DIR := $(DESTDIR)$(XENFIRMWAREDIR)
 
 SUBDIRS-y :=
-ifeq ($(OVMF_PATH),)
 SUBDIRS-$(CONFIG_OVMF) += ovmf-dir
-endif
-ifeq ($(SEABIOS_PATH),)
 SUBDIRS-$(CONFIG_SEABIOS) += seabios-dir
-endif
 SUBDIRS-$(CONFIG_ROMBIOS) += rombios
 SUBDIRS-$(CONFIG_ROMBIOS) += vgabios
 SUBDIRS-$(CONFIG_ROMBIOS) += etherboot
@@ -46,15 +42,11 @@ install: all
[ -d $(INST_DIR) ] || $(INSTALL_DIR) $(INST_DIR)
[ ! -e $(TARGET) ] || $(INSTALL_DATA) $(TARGET) $(INST_DIR)
 ifeq ($(CONFIG_SEABIOS),y)
-ifeq ($(SEABIOS_PATH),)
$(INSTALL_DATA) seabios-dir/out/bios.bin $(INST_DIR)/bios.bin
 endif
-endif
 ifeq ($(CONFIG_OVMF),y)
-ifeq ($(OVMF_PATH),)
$(INSTALL_DATA) ovmf-dir/ovmf.bin $(INST_DIR)/ovmf.bin
 endif
-endif
 
 .PHONY: clean
 clean: subdirs-clean
-- 
Anthony PERARD


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 05/17] libxl/arm: Generate static ACPI DSDT table

[Shannon Zhao]

On 2016年07月12日 19:38, Wei Liu wrote:
> On Tue, Jul 12, 2016 at 11:50:32AM +0800, Shannon Zhao wrote:
>> > 
>> > 
>> > On 2016/7/7 23:52, Wei Liu wrote:
>>> > > On Tue, Jul 05, 2016 at 11:12:35AM +0800, Shannon Zhao wrote:
> > >> > From: Shannon Zhao 
> > >> > 
> > >> > It uses static DSDT table like the way x86 uses. Currently the DSDT
> > >> > table only contains processor device objects and it generates the
> > >> > maximal objects which so far is 128.
> > >> > 
> > >> > Signed-off-by: Shannon Zhao 
> > >> > ---
> > >> >  tools/libacpi/Makefile| 15 -
> > >> >  tools/libacpi/mk_dsdt.c   | 51 
> > >> > ---
> > >> >  tools/libxl/Makefile  |  5 -
> > >> >  tools/libxl/libxl_arm_acpi.c  |  5 +
> > >> >  xen/include/public/arch-arm.h |  3 +++
> > >> >  5 files changed, 64 insertions(+), 15 deletions(-)
> > >> > 
> > >> > diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
> > >> > index 4068d9a..0401810 100644
> > >> > --- a/tools/libacpi/Makefile
> > >> > +++ b/tools/libacpi/Makefile
> > >> > @@ -22,6 +22,7 @@ MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
> > >> >  # Sources to be generated
> > >> >  C_SRC = $(ACPI_BUILD_DIR)/dsdt_anycpu.c 
> > >> > $(ACPI_BUILD_DIR)/dsdt_15cpu.c 
> > >> >  C_SRC += $(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.c 
> > >> > $(ACPI_BUILD_DIR)/dsdt_pvh.c
> > >> > +C_SRC += $(ACPI_BUILD_DIR)/dsdt_anycpu_arm.c
> > >> >  H_SRC = $(ACPI_BUILD_DIR)/ssdt_s3.h $(ACPI_BUILD_DIR)/ssdt_s4.h 
> > >> > $(ACPI_BUILD_DIR)/ssdt_pm.h $(ACPI_BUILD_DIR)/ssdt_tpm.h
> > >> >  
> > >> >  vpath iasl $(PATH)
> > >> > @@ -35,7 +36,7 @@ $(H_SRC): $(ACPI_BUILD_DIR)/%.h: %.asl iasl
> > >> >cd $(CURDIR)
> > >> >  
> > >> >  $(MK_DSDT): mk_dsdt.c
> > >> > -  $(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c
> > >> > +  $(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -D__XEN_TOOLS__ -o 
> > >> > $@ mk_dsdt.c
>>> > > Why is this needed? Which unstable hypervisor interface you need in
>>> > > order to build this?
>> > It needs GUEST_MAX_VCPUS in mk_dsdt.c while the GUEST_MAX_VCPUS is
>> > defined under #if defined(__XEN__) || defined(__XEN_TOOLS__) in
>> > xen/include/public/arch-arm.h
>> > 
> OK. Let me elaborate a bit on this.
> 
> The two macros basically imply everything enclosed in them is subject to
> change. I guess I can live with this because this is not a public facing
> interface for library users.
> 
> Can you ack or nack my assessment?
Yeah, the mk_dsdt is just a middle result of compilation which is used
to generate DSDT table.

Thanks,
-- 
Shannon

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Wei Liu]

On Tue, Jul 12, 2016 at 10:42:07PM +0800, Shannon Zhao wrote:
> > > >> > 
> > > >> > Does it mean we would need to update the slack to take into 
> > > >> > account the ACPI
> > > >> > blob?
> >>> > > Yes, we need to take into account the ACPI blob. Probably not in the
> >>> > > slack but directly in mam_memkb.
> >> > Sorry, I'm not sure understand this. I found the b_info->max_memkb but
> >> > didn't find the slack you said. And how to fix this? Update
> >> > b_info->max_memkb or the slack?
> > Can you calculate the size of your payload and add that to max_memkb?
> > 
> Yeah, but the size will be changed if we change the tables in the future
> and this also should consider x86, right?

That could easily be solved by introducing a function to calculate the
size, right?

Wei.

> 
> Thanks,
> -- 
> Shannon

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] ACPI builder re-licensing

[Boris Ostrovsky]

Starting a new thread on ACPI code re-licensing, continuing from
https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg01245.html

Summary
==

While working on refactoring ACPI builder code from
tools/firmware/hvmloader/acpi/ and making it available to both hvmloader
and libxl/libxc (and possibly, in the future, to the hypervisor) we
realized that these two components use different licenses: the former is
licensed under GPLv2 and the latter uses LGPL.

The proposal is to re-license the builder to LGPL which should allow us
to have it linked against both GPLv2 and LGPL code (and possibly other
licenses?)


Details
=

Currently we have:
ostr@workbase> ls -l tools/firmware/hvmloader/acpi/
total 116
-rw-rw-r-- 1 ostr ostr 11388 Sep  1  2015 acpi2_0.h
-rw-rw-r-- 1 ostr ostr 21010 Jun 22 10:51 build.c
-rw-rw-r-- 1 ostr ostr 16856 Jun 22 10:51 dsdt.asl
-rw-rw-r-- 1 ostr ostr  2023 Sep  1  2015 Makefile
-rw-rw-r-- 1 ostr ostr 15452 Jun 22 10:51 mk_dsdt.c
-rw-rw-r-- 1 ostr ostr   618 Feb  3  2015 README
-rw-rw-r-- 1 ostr ostr 12694 Sep  1  2015 ssdt_pm.asl
-rw-rw-r-- 1 ostr ostr   999 Sep  1  2015 ssdt_s3.asl
-rw-rw-r-- 1 ostr ostr   999 Sep  1  2015 ssdt_s4.asl
-rw-rw-r-- 1 ostr ostr   978 Sep  1  2015 ssdt_tpm.asl
-rw-rw-r-- 1 ostr ostr  5474 Sep  1  2015 static_tables.c

All these files are under GPLv2

The idea is to make code that lives in tools/firmware/hvmloader/acpi
available to
* hmloader (GPLv2)
* libxl/libxc (LGPL)
* possibly the hypervisor (although that's not on the table at the moment)

No static or dynamic library will be created. Just like in the case of
libelf, each component will link object files from tools/libacpi
directory. Specifically, they will link:
* build.o static_tables.o
* dsdt_*.o, which is compiled from dsdt_*.c, which is generated from
dsdt.asl by iasl and mk_dsdt.

The C files (corresponding to the objects above) will include acpi2_0.h,
ssdt_*.h (generated by iasl from ssdt_*.asl).

In addition, chunks of acpi2_0.h and build.c (structure definitions)
will be excised into newly created libacpi.h and that file will be
included by consumers (i.e. libxl/libxc and hvmloader). libacpi.h will
also include acpi2_0.h. dsdt.asl will be broken into two files, both of
which will be used by iasl.

It's probably worth noting that the builder does not make any further
calls with the exception of:
* standard C utilities such as printf and strcmp
* callbacks into the caller (libxl/libxc or hvmloader) via function
pointers provided by the caller.


Who needs to be notified
===

Assuming that S-o-b and From are a good indication of who needs to be
notified of the change (and needs to ack it):

ostr@workbase> git log tools/firmware/hvmloader/acpi | egrep
"Signed|From" | sed -e 's/.*@/ /g' | sort | uniq -c
  1  citrix.com
 73  citrix.com>
  1  debian.org>
  5  eu.citrix.com>
 18  intel.com>
  2  jp.fujitsu.com>
  1  net-space.pl>
  1  novell.com>
  1  oracle.com>
  1  redhat.com>
  1  sun.com>
  8  suse.com>
  1  us.ibm.com>
  6  verge.net.au>
  4  xen.org>
 25  xensource.com>


which indicated major contributions (and therefore a required ack) from
Citrix/Xensource, Suse/Novell, Oracle/Sun, Intel.

For the rest ("trivial" or "simple" is, of course, a matter of opinion):

* debian.com is a single trivial patch to a Makefile
   
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=83f34fdcdd26c3dcc793c571e7b75c705bd92e7a
 
* Fujitsu provided two patches, one trivial the other not completely trivial
 
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e451db15ef6198f5d21b84618c833ac276087d70
 
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=ab438874b6a8ae955b337c36e7b3204e29b8d407

* net-space.pl is Daniel Kiper's (now, but not at the patch's time, at
Oracle) ISP. The patch is
 
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=37fddaa5fe1a7e369827e4b9e25cdae5df9b3d7d

* redhat is one trivial patch by Paolo Bonzini that has been reversed later:
 
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e4fd0475a08fda414da27c4e57b568f147cfc07e

* IBM one patch from Stefan Berger
 
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=9fd9787b0e7995ac5f2da504b92723c24d6a3737

  (plus what seems to inclusion of his work in
   
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=883236e49a86a0174c6df61cac995ebf16d72b35)

  Also, ssdt_tpm.asl is explicitly copyrighted by IBM

* A bunch of patches from from Simon Horman at Verge

* xen.org are S-o-b by Keir, all from 2011.



-boris


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Shannon Zhao]

On 2016年07月12日 22:50, Wei Liu wrote:
> On Tue, Jul 12, 2016 at 10:42:07PM +0800, Shannon Zhao wrote:
>>> > > > >> > 
>>> > > > >> > Does it mean we would need to update the slack to 
>>> > > > >> > take into account the ACPI
>>> > > > >> > blob?
>>> > >>> > > Yes, we need to take into account the ACPI blob. Probably not 
>>> > >>> > > in the
>>> > >>> > > slack but directly in mam_memkb.
> > >> > Sorry, I'm not sure understand this. I found the b_info->max_memkb 
> > >> > but
> > >> > didn't find the slack you said. And how to fix this? Update
> > >> > b_info->max_memkb or the slack?
>>> > > Can you calculate the size of your payload and add that to max_memkb?
>>> > > 
>> > Yeah, but the size will be changed if we change the tables in the future
>> > and this also should consider x86, right?
> That could easily be solved by introducing a function to calculate the
> size, right?
Oh, I'm not familiar with this. Let's clarify on this. It can add the
size to max_memkb after generating the ACPI tables and before loading
the tables to guest space and it doesn't have to add the size at
libxl__domain_build_info_setdefault(), right?

Thanks,
-- 
Shannon

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 06/14] xen: Move the hvm_start_info C representation from libxc to public/xen.h

[Wei Liu]

On Tue, Jul 12, 2016 at 03:42:43PM +0100, Anthony PERARD wrote:
> Instead of having several representation of hvm_start_info in C, define
> it in public/xen.h so both libxc and hvmloader can use it.
> 

Commit message is wrong. I think this can be easily handled during
committing though.

Now we need an ack from Andrew or Jan.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 02/14] libxc: Prepare a start info structure for hvmloader

[Wei Liu]

On Tue, Jul 12, 2016 at 03:42:39PM +0100, Anthony PERARD wrote:
> ... and load BIOS/UEFI firmware into guest memory.
> 
> This adds a new firmware module, system_firmware_module. It is loaded in
> the guest memory and final location is provided to hvmloader via the
> hvm_start_info struct.
> 
> This patch create the hvm_start_info struct for HVM guest that have a
> device model, so this is now common code with HVM guest without device
> model.
> 
> Signed-off-by: Anthony PERARD 
> 

Acked-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 05/14] libxl: Load guest BIOS from file

[Wei Liu]

On Tue, Jul 12, 2016 at 03:42:42PM +0100, Anthony PERARD wrote:
> The path to the BIOS blob can be overriden by the xl's
> bios_path_override option, or provided by u.hvm.bios_firmware in the
> domain_build_info struct by other libxl user.
> 
> Signed-off-by: Anthony PERARD 
> 

Acked-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 00/14] Load BIOS via toolstack instead of been embedded in hvmloader.

[Wei Liu]

I believe we only need a mechanical ack from Andrew and Jan for patch 6.
I'm happy to take care of this series once everything is ready.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 00/14] Load BIOS via toolstack instead of been embedded in hvmloader.

[Wei Liu]

On Tue, Jul 12, 2016 at 04:03:21PM +0100, Wei Liu wrote:
> I believe we only need a mechanical ack from Andrew and Jan for patch 6.

Spoke too soon. Patch 8 and 9 would also need acks.

> I'm happy to take care of this series once everything is ready.
> 

This stays the same. :-)

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Boris Ostrovsky]

On 07/12/2016 10:57 AM, Shannon Zhao wrote:
> On 2016年07月12日 22:50, Wei Liu wrote:
>> On Tue, Jul 12, 2016 at 10:42:07PM +0800, Shannon Zhao wrote:
>> Does it mean we would need to update the slack to take 
>> into account the ACPI
>> blob?
>> Yes, we need to take into account the ACPI blob. Probably not in 
>> the
>> slack but directly in mam_memkb.
>> Sorry, I'm not sure understand this. I found the b_info->max_memkb 
>> but
>> didn't find the slack you said. And how to fix this? Update
>> b_info->max_memkb or the slack?
>> Can you calculate the size of your payload and add that to max_memkb?
>>
 Yeah, but the size will be changed if we change the tables in the future
 and this also should consider x86, right?
>> That could easily be solved by introducing a function to calculate the
>> size, right?
> Oh, I'm not familiar with this. Let's clarify on this. It can add the
> size to max_memkb after generating the ACPI tables and before loading
> the tables to guest space and it doesn't have to add the size at
> libxl__domain_build_info_setdefault(), right?

This was discussed before: ACPI tables are part of RAM whose size is
specified by the config file (and is reflected in max_memkb I believe).
It may not be presented to the guest as RAM (i.e. on x86 it is labeled
by BIOS (or whoever) as a dedicated type in e820) but it still resides
in DIMMs.

I believe we should not increase memory resources for ACPI tables.

-boris





___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 01/14] libxc: Rework extra module initialisation

[Wei Liu]

On Tue, Jul 12, 2016 at 03:42:38PM +0100, Anthony PERARD wrote:
> This patch use xc_dom_alloc_segment() to allocate the memory space for the
> ACPI modules and the SMBIOS modules. This is to replace the arbitrary
> placement of 1MB (+ extra for MB alignement) after the hvmloader image.
> 
> This patch can help if one add extra ACPI table and hvmloader contain
> OVMF (OVMF is a 2MB binary), as in that case the extra ACPI table could
> easily be loaded past the address 4MB, but hvmloader use a range of
> memory from 4MB to 10MB to perform tests and in the process, clears the
> memory, before loading the modules.
> 
> Signed-off-by: Anthony PERARD 
> 

Acked-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 06/14] xen: Move the hvm_start_info C representation from libxc to public/xen.h

[Andrew Cooper]

On 12/07/16 15:42, Anthony PERARD wrote:
> +#ifndef __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__
> +#define __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__
> +
> +/*
> + * C representation of the x86/HVM start info layout.
> + *
> + * The canonical definition of this layout resides in public/xen.h, this

You should also move the big comment block from public/xen.h to here,
along with the XEN_HVM_START_MAGIC_VALUE define.

There is no point having it split across two locations in the public
headers.

~Andrew

> + * is just a way to represent the layout described there using C types.
> + *
> + */
> +struct hvm_start_info {
> +uint32_t magic; /* Contains the magic value 0x336ec578   
> */
> +/* ("xEn3" with the 0x80 bit of the "E" 
> set).*/
> +uint32_t version;   /* Version of this structure.
> */
> +uint32_t flags; /* SIF_xxx flags.
> */
> +uint32_t nr_modules;/* Number of modules passed to the kernel.   
> */
> +uint64_t modlist_paddr; /* Physical address of an array of   
> */
> +/* hvm_modlist_entry.
> */
> +uint64_t cmdline_paddr; /* Physical address of the command line. 
> */
> +uint64_t rsdp_paddr;/* Physical address of the RSDP ACPI data
> */
> +/* structure.
> */
> +};
> +
> +struct hvm_modlist_entry {
> +uint64_t paddr; /* Physical address of the module.   
> */
> +uint64_t size;  /* Size of the module in bytes.  
> */
> +uint64_t cmdline_paddr; /* Physical address of the command line. 
> */
> +uint64_t reserved;
> +};
> +
> +#endif /* __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__ */


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] xenbits "official" repo for XTF (was Re: [PATCH 0/2] xtf: add launcher (+1 bugfix)

[George Dunlap]

On Fri, Jul 8, 2016 at 2:06 PM, Andrew Cooper  wrote:
> However, OSSTest has always been known as OSSTest (including all
> references in the automated emails), and not as a xen test framework.
> Taking any steps to make OSSTest retroactively searchable as a xen test
> framework is a dumb move, which will only confuse users.
>
> I fully admit that had OSSTest been named differently then I might not
> have chosen XTF as a name, but that didn't happen.  Trying to rewrite
> history isn't the answer.

I'm glad we have a solution, but it seems that we still don't all
understand one another; in which case I'm afraid something like this
may come up again.

The objection has nothing to do with OSSTest.  It has to do with the
fact that 1) contains the word "Xen", and 2) seems to describe
something much more general than what it actually is.

If you'd called it "Andy's Test Framework", or even "Cooper's
Universal Testing Solution", I don't think anyone would have had any
strong objections, because although the names very general, they're
made much more specific by adding your name to the front.

By adding "Xen" to it, you associate it with the community, and thus
the community has a right to say whether they accept the name or not.
The fact that you used the name for 2 years *privately* doesn't give
you any right to suddenly come out and use the name publicly.  You can
use whatever name you want privately, of course, but once you start to
use it publicly, the community has a right to say whether they accept
that or not.

 -George

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Wei Liu]

On Tue, Jul 12, 2016 at 11:08:47AM -0400, Boris Ostrovsky wrote:
> On 07/12/2016 10:57 AM, Shannon Zhao wrote:
> > On 2016年07月12日 22:50, Wei Liu wrote:
> >> On Tue, Jul 12, 2016 at 10:42:07PM +0800, Shannon Zhao wrote:
> >> Does it mean we would need to update the slack to take 
> >> into account the ACPI
> >> blob?
> >> Yes, we need to take into account the ACPI blob. Probably not 
> >> in the
> >> slack but directly in mam_memkb.
> >> Sorry, I'm not sure understand this. I found the b_info->max_memkb 
> >> but
> >> didn't find the slack you said. And how to fix this? Update
> >> b_info->max_memkb or the slack?
> >> Can you calculate the size of your payload and add that to max_memkb?
> >>
>  Yeah, but the size will be changed if we change the tables in the future
>  and this also should consider x86, right?
> >> That could easily be solved by introducing a function to calculate the
> >> size, right?
> > Oh, I'm not familiar with this. Let's clarify on this. It can add the
> > size to max_memkb after generating the ACPI tables and before loading
> > the tables to guest space and it doesn't have to add the size at
> > libxl__domain_build_info_setdefault(), right?
> 

Hmm... I would like to think a bit more about this. But before dwelling
on this too much...

> This was discussed before: ACPI tables are part of RAM whose size is
> specified by the config file (and is reflected in max_memkb I believe).
> It may not be presented to the guest as RAM (i.e. on x86 it is labeled
> by BIOS (or whoever) as a dedicated type in e820) but it still resides
> in DIMMs.
> 
> I believe we should not increase memory resources for ACPI tables.
> 

This is an interesting point. If there is already such resolution I will
be happy to follow it.

Any reference?

Wei.

> -boris
> 
> 
> 
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Boris Ostrovsky]

On 07/12/2016 11:13 AM, Wei Liu wrote:
> On Tue, Jul 12, 2016 at 11:08:47AM -0400, Boris Ostrovsky wrote:
>> On 07/12/2016 10:57 AM, Shannon Zhao wrote:
>>> On 2016年07月12日 22:50, Wei Liu wrote:
 On Tue, Jul 12, 2016 at 10:42:07PM +0800, Shannon Zhao wrote:
 Does it mean we would need to update the slack to take 
 into account the ACPI
 blob?
 Yes, we need to take into account the ACPI blob. Probably not 
 in the
 slack but directly in mam_memkb.
 Sorry, I'm not sure understand this. I found the b_info->max_memkb 
 but
 didn't find the slack you said. And how to fix this? Update
 b_info->max_memkb or the slack?
 Can you calculate the size of your payload and add that to max_memkb?

>> Yeah, but the size will be changed if we change the tables in the future
>> and this also should consider x86, right?
 That could easily be solved by introducing a function to calculate the
 size, right?
>>> Oh, I'm not familiar with this. Let's clarify on this. It can add the
>>> size to max_memkb after generating the ACPI tables and before loading
>>> the tables to guest space and it doesn't have to add the size at
>>> libxl__domain_build_info_setdefault(), right?
> Hmm... I would like to think a bit more about this. But before dwelling
> on this too much...
>
>> This was discussed before: ACPI tables are part of RAM whose size is
>> specified by the config file (and is reflected in max_memkb I believe).
>> It may not be presented to the guest as RAM (i.e. on x86 it is labeled
>> by BIOS (or whoever) as a dedicated type in e820) but it still resides
>> in DIMMs.
>>
>> I believe we should not increase memory resources for ACPI tables.
>>
> This is an interesting point. If there is already such resolution I will
> be happy to follow it.
>
> Any reference?

The last one (that I can find) is
   
https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg00821.html

(conveniently in the same thread is the one we have been using to talk
about licensing)

-boris



___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 1/6] libxl: add "merge" function to generic device type support

[Juergen Gross]

Instead of using a macro generating the code to merge xenstore and
json configuration data, use the generic device type support for
this purpose.

This requires to add some accessor functions to the framework and
a structure for disks (as disks are added separately they didn't need
such a structure up to now).

Signed-off-by: Juergen Gross 
---
 tools/libxl/libxl.c  | 181 ---
 tools/libxl/libxl_create.c   |  18 +++--
 tools/libxl/libxl_internal.h |  52 +++--
 tools/libxl/libxl_pci.c  |   8 +-
 tools/libxl/libxl_pvusb.c|  12 +++
 5 files changed, 181 insertions(+), 90 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 2cf7451..07b96c7 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -7371,93 +7371,68 @@ int libxl_retrieve_domain_configuration(libxl_ctx *ctx, 
uint32_t domid,
  *entry retrieved from xenstore while "dst" points to the entry
  *retrieve from JSON.
  */
-#define MERGE(type, ptr, compare, merge)\
-do {\
-libxl_device_##type *p = NULL;  \
-int i, j, num;  \
-\
-p = libxl_device_##type##_list(CTX, domid, &num);   \
-if (p == NULL) {\
-LOG(DEBUG,  \
-"no %s from xenstore for domain %d",\
-#type, domid);  \
-}   \
-\
-for (i = 0; i < d_config->num_##ptr; i++) { \
-libxl_device_##type *q = &d_config->ptr[i]; \
-for (j = 0; j < num; j++) { \
-if (compare(&p[j], q))  \
-break;  \
-}   \
-\
-if (j < num) { /* found in xenstore */  \
-libxl_device_##type *dst, *src; \
-dst = q;\
-src = &p[j];\
-merge;  \
-} else {/* not found in xenstore */ \
-LOG(WARN,   \
-"Device present in JSON but not in xenstore, ignored"); \
-\
-libxl_device_##type##_dispose(q);   \
-\
-for (j = i; j < d_config->num_##ptr - 1; j++)   \
-memcpy(&d_config->ptr[j], &d_config->ptr[j+1],  \
-   sizeof(libxl_device_##type));\
-\
-d_config->ptr = \
-libxl__realloc(NOGC, d_config->ptr, \
-   sizeof(libxl_device_##type) *\
-   (d_config->num_##ptr - 1));  \
-\
-/* rewind counters */   \
-d_config->num_##ptr--;  \
-i--;\
-}   \
-}   \
-\
-for (i = 0; i < num; i++)   \
-libxl_device_##type##_dispose(&p[i]);   \
-free(p);\
-} while (0);
+{
+const struct libxl_device_type *dt;
+int idx;
 
-MERGE(nic, nics, COMPARE_DEVID, {});
+for (idx = 0;; idx++) {
+void *p = NULL;
+void **devs;
+int i, j, num;
+int *num_dev;
 
-MERGE(vtpm, vtpms, COMPARE_DEVID, {});
+dt = device_type_tbl[idx];
+if (!dt)
+

[Xen-devel] [PATCH 4/6] libxl: split libxl vtpm code into one source

[Juergen Gross]

Put all vtpm related stuff of libxl into a dedicated source file.

Signed-off-by: Juergen Gross 
---
 tools/libxl/Makefile |   1 +
 tools/libxl/libxl.c  | 302 ---
 tools/libxl/libxl_internal.h |   1 -
 tools/libxl/libxl_utils.c|  43 -
 tools/libxl/libxl_vtpm.c | 366 +++
 5 files changed, 367 insertions(+), 346 deletions(-)
 create mode 100644 tools/libxl/libxl_vtpm.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 9fee752..86c11bf 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -115,6 +115,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o 
libxl_pci.o \
libxl_save_callout.o _libxl_save_msgs_callout.o \
libxl_qmp.o libxl_event.o libxl_fork.o \
libxl_dom_suspend.o libxl_dom_save.o libxl_pvusb.o \
+   libxl_vtpm.o \
 $(LIBXL_OBJS-y)
 LIBXL_OBJS += libxl_genid.o
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 12bc0e1..7ada4a7 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2031,292 +2031,6 @@ int libxl__resolve_domid(libxl__gc *gc, const char 
*name, uint32_t *domid)
 }
 
 
/**/
-int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vtpm *vtpm)
-{
-int rc;
-if (libxl_uuid_is_nil(&vtpm->uuid)) {
-libxl_uuid_generate(&vtpm->uuid);
-}
-rc = libxl__resolve_domid(gc, vtpm->backend_domname, &vtpm->backend_domid);
-return rc;
-}
-
-static int libxl__device_from_vtpm(libxl__gc *gc, uint32_t domid,
-   libxl_device_vtpm *vtpm,
-   libxl__device *device)
-{
-   device->backend_devid   = vtpm->devid;
-   device->backend_domid   = vtpm->backend_domid;
-   device->backend_kind= LIBXL__DEVICE_KIND_VTPM;
-   device->devid   = vtpm->devid;
-   device->domid   = domid;
-   device->kind= LIBXL__DEVICE_KIND_VTPM;
-
-   return 0;
-}
-
-static void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid,
-   libxl_device_vtpm *vtpm,
-   libxl__ao_device *aodev)
-{
-STATE_AO_GC(aodev->ao);
-flexarray_t *front;
-flexarray_t *back;
-libxl__device *device;
-int rc;
-xs_transaction_t t = XBT_NULL;
-libxl_domain_config d_config;
-libxl_device_vtpm vtpm_saved;
-libxl__domain_userdata_lock *lock = NULL;
-
-libxl_domain_config_init(&d_config);
-libxl_device_vtpm_init(&vtpm_saved);
-libxl_device_vtpm_copy(CTX, &vtpm_saved, vtpm);
-
-rc = libxl__device_vtpm_setdefault(gc, vtpm);
-if (rc) goto out;
-
-front = flexarray_make(gc, 16, 1);
-back = flexarray_make(gc, 16, 1);
-
-if (vtpm->devid == -1) {
-if ((vtpm->devid = libxl__device_nextid(gc, domid, "vtpm")) < 0) {
-rc = ERROR_FAIL;
-goto out;
-}
-}
-
-libxl__update_config_vtpm(gc, &vtpm_saved, vtpm);
-
-GCNEW(device);
-rc = libxl__device_from_vtpm(gc, domid, vtpm, device);
-if ( rc != 0 ) goto out;
-
-flexarray_append(back, "frontend-id");
-flexarray_append(back, GCSPRINTF("%d", domid));
-flexarray_append(back, "online");
-flexarray_append(back, "1");
-flexarray_append(back, "state");
-flexarray_append(back, GCSPRINTF("%d", XenbusStateInitialising));
-flexarray_append(back, "handle");
-flexarray_append(back, GCSPRINTF("%d", vtpm->devid));
-
-flexarray_append(back, "uuid");
-flexarray_append(back, GCSPRINTF(LIBXL_UUID_FMT, 
LIBXL_UUID_BYTES(vtpm->uuid)));
-flexarray_append(back, "resume");
-flexarray_append(back, "False");
-
-flexarray_append(front, "backend-id");
-flexarray_append(front, GCSPRINTF("%d", vtpm->backend_domid));
-flexarray_append(front, "state");
-flexarray_append(front, GCSPRINTF("%d", XenbusStateInitialising));
-flexarray_append(front, "handle");
-flexarray_append(front, GCSPRINTF("%d", vtpm->devid));
-
-if (aodev->update_json) {
-lock = libxl__lock_domain_userdata(gc, domid);
-if (!lock) {
-rc = ERROR_LOCK_FAIL;
-goto out;
-}
-
-rc = libxl__get_domain_configuration(gc, domid, &d_config);
-if (rc) goto out;
-
-DEVICE_ADD(vtpm, vtpms, domid, &vtpm_saved, COMPARE_DEVID, &d_config);
-
-rc = libxl__dm_check_start(gc, &d_config, domid);
-if (rc) goto out;
-}
-
-for (;;) {
-rc = libxl__xs_transaction_start(gc, &t);
-if (rc) goto out;
-
-rc = libxl__device_exists(gc, t, device);
-if (rc < 0) goto out;
-if (rc == 1) {  /* already exists in xenstore */
-LOG(ERROR, "device already exists in xenstore");
-