[Xen-devel] [linux-next test] 125109: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

flight 125109 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125109/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2  broken
 test-armhf-armhf-xl-credit2   4 host-install(4)broken REGR. vs. 125041
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. 
vs. 125041
 test-amd64-amd64-pygrub   7 xen-boot fail REGR. vs. 125041
 test-amd64-amd64-libvirt  7 xen-boot fail REGR. vs. 125041
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot  fail REGR. vs. 125041
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 125041
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 
125041
 test-armhf-armhf-xl-arndale   7 xen-boot fail REGR. vs. 125041
 test-amd64-amd64-examine  8 reboot   fail REGR. vs. 125041
 test-amd64-amd64-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail REGR. 
vs. 125041
 test-armhf-armhf-xl-vhd   7 xen-boot fail REGR. vs. 125041

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt6 libvirt-buildfail  like 125041
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125041
 test-armhf-armhf-examine  8 reboot   fail  like 125041
 test-armhf-armhf-xl   7 xen-boot fail  like 125041
 test-armhf-armhf-libvirt-xsm  7 xen-boot fail  like 125041
 test-armhf-armhf-xl-xsm   7 xen-boot fail  like 125041
 test-armhf-armhf-xl-cubietruck  7 xen-bootfail like 125041
 test-armhf-armhf-xl-rtds  7 xen-boot fail  like 125041
 test-armhf-armhf-libvirt-raw  7 xen-boot fail  like 125041
 test-armhf-armhf-xl-multivcpu  7 xen-boot fail like 125041
 test-armhf-armhf-libvirt  7 xen-boot fail  like 125041
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125041
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125041
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125041
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 125041
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125041
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linux98be45067040799a801e6ce52d8bf4659a153893
baseline version:
 linux43b6b6eca863cf2f83dc062484963377c66a72be

Last test of basis  (not found) 
Failing since   (not found) 
Testing same since   125109  2018-07-11 12:43:03 Z2 days1 attempts

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm

Re: [Xen-devel] [PATCH v2 05/21] xen/arm: extend device tree based multiboot protocol

[Stefano Stabellini]

On Mon, 9 Jul 2018, Julien Grall wrote:
> Hi,
> 
> On 07/07/18 00:12, Stefano Stabellini wrote:
> > Extend the existing device tree based multiboot protocol to include
> > information regarding multiple domains to boot.
> > 
> > Signed-off-by: Stefano Stabellini 
> > 
> > ---
> > Changes in v2:
> > - lower case kernel
> > - rename mem to memory
> > - mandate cpus and memory
> > - replace domU-kernel with kernel and domU-ramdisk with ramdisk
> > - rename xen,domU with xen,domain
> > - add info about dom0
> > - switch memory and cpus to integers
> > - remove defaults
> > - add vpl011
> > ---
> >   docs/misc/arm/device-tree/booting.txt | 108
> > ++
> >   1 file changed, 108 insertions(+)
> > 
> > diff --git a/docs/misc/arm/device-tree/booting.txt
> > b/docs/misc/arm/device-tree/booting.txt
> > index ce2d0dc..5c3b8da 100644
> > --- a/docs/misc/arm/device-tree/booting.txt
> > +++ b/docs/misc/arm/device-tree/booting.txt
> > @@ -119,3 +119,111 @@ For those you would hardcode the Xen commandline in
> > the DTB under
> >   line by writing bootargs (as for native Linux).
> >   A Xen-aware bootloader would set xen,xen-bootargs for Xen,
> > xen,dom0-bootargs
> >   for Dom0 and bootargs for native Linux.
> > +
> > +
> > +Creating Multiple Domains directly from Xen
> > +===
> > +
> > +It is possible to have Xen create other domains, in addition to dom0,
> > +out of the information provided via device tree. A kernel and initrd
> > +(optional) need to be specified for each guest.
> > +
> > +For each domain to be created there needs to be one node under /chosen
> > +with the following properties:
> > +
> > +- compatible
> > +
> > +For domUs: "xen,domain"
> > +For dom0: "xen,domain", "xen,initial-domain"
> 
> Looking briefly at the code, I don't see any support of "xen,initial-domain".
> Did I miss anything?
> 
> But, it is a bit strange to put that in compatible. Shouldn't this be a
> property?

I haven't implemened this in this series yet. Let's add
"xen,initial-domain" to the spec together with the implementation in one
of the follow-up series.

 
> > +
> > +- memory
> > +
> > +An integer specifying the amount of megabytes of RAM to allocate to
> > +the guest.
> 
> I would define this a KB. With Dom0less it would be easy to spawn a guest with
> less than a MB of memory. What matter is the amount of memory should be
> page-aligned.

I think it would be good to allow users to specify the memory in KB, you
are right that we might be able to have <1MB guests. At the same time,
it is a pain to have to deal with KBs when allocating multi GBs guests.

Any suggestion on how to make this more user friendly? Maybe we could
find a way to support multiple units, for instance we could support
memory_mb (for MBs) and memory_kb (for KBs).

Or we could just suck it up and use KBs only. I mean, if we have to
support one unit only, it should probably be KBs. I wonder if it makes
sense to rename memory to memory_ in any case for clarity.


> > +
> > +- cpus
> > +
> > +An integer specifying the number of vcpus to allocate to the guest.
> > +
> > +- vpl011
> > +
> > +An integer to enable/disable a virtual pl011 for the guest to use.
> 
> The interrupt is a bit confusing here. What value will enable? What value will
> disable?
> 
> I think you can just make an empty property.

OK

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

Re: [Xen-devel] [PATCH v2 15/21] xen/arm: generate vpl011 node on device tree for domU

[Stefano Stabellini]

On Thu, 12 Jul 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 07/07/2018 00:12, Stefano Stabellini wrote:
> > Introduce vpl011 support to guests started from Xen: it provides a
> > simple way to print output from a guest, as most guests come with a
> > pl011 driver. It is also able to provide a working console with
> > interrupt support.
> > 
> > The UART exposed to the guest is a SBSA compatible UART and not a PL011.
> > SBSA UART is a subset of PL011 r1p5. A full PL011 implementation in Xen
> > would just be too difficult, so guests may require some drivers changes.
> > 
> > Enable vpl011 conditionally if the user requested it.
> > 
> > Make set_interrupt_ppi able to handle non-PPI and rename it
> > set_interrupt.
> > 
> > Signed-off-by: Stefano Stabellini 
> > ---
> > Changes in v2:
> > - code style fixes
> > - make set_interrupt_ppi generic
> > - rename set_interrupt_ppi to set_interrupt
> > - only make the vpl011 node if the option was enabled
> > ---
> >   xen/arch/arm/domain_build.c | 90
> > +
> >   1 file changed, 75 insertions(+), 15 deletions(-)
> > 
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index 48a91ad..718be48 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -519,17 +519,17 @@ static int write_properties(struct domain *d, struct
> > kernel_info *kinfo,
> > typedef __be32 gic_interrupt_t[3];
> >   -static void set_interrupt_ppi(gic_interrupt_t interrupt, unsigned int
> > irq,
> > -  unsigned int cpumask, unsigned int level)
> > +static void set_interrupt(gic_interrupt_t interrupt, unsigned int irq,
> > +  unsigned int cpumask, unsigned int level)
> >   {
> >   __be32 *cells = interrupt;
> > +int is_ppi = (irq < 32);
> 
> I was about to suggest a bool, but I am not entirely sure what would be the
> value when it is true.
> 
> However, I think you want this to be !!(irq < 32) to make ensure it will be
> 0/1.

OK


> >   -BUG_ON(irq < 16);
> > -BUG_ON(irq >= 32);
> 
> Can we keep an ASSERT/BUG_ON to confirm no SGI is passed here?

Yes


> > +irq -= (is_ppi) ? 16: 32; /* PPIs start at 16, SPIs at 32 */
> > /* See linux
> > Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt */
> > -dt_set_cell(, 1, 1); /* is a PPI */
> > -dt_set_cell(, 1, irq - 16); /* PPIs start at 16 */
> > +dt_set_cell(, 1, is_ppi); /* is a PPI? */
> > +dt_set_cell(, 1, irq);
> >   dt_set_cell(, 1, (cpumask << 8) | level);
> >   }
> >   @@ -648,7 +648,7 @@ static int make_hypervisor_node(struct domain *d,
> >*  - All CPUs
> >*  TODO: Handle properly the cpumask;
> >*/
> > -set_interrupt_ppi(intr, d->arch.evtchn_irq, 0xf,
> > DT_IRQ_TYPE_LEVEL_LOW);
> > +set_interrupt(intr, d->arch.evtchn_irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
> >   res = fdt_property_interrupts(fdt, , 1);
> >   if ( res )
> >   return res;
> > @@ -924,15 +924,15 @@ static int make_timer_node(const struct domain *d,
> > void *fdt,
> > irq = timer_get_irq(TIMER_PHYS_SECURE_PPI);
> >   dt_dprintk("  Secure interrupt %u\n", irq);
> > -set_interrupt_ppi(intrs[0], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
> > +set_interrupt(intrs[0], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
> > irq = timer_get_irq(TIMER_PHYS_NONSECURE_PPI);
> >   dt_dprintk("  Non secure interrupt %u\n", irq);
> > -set_interrupt_ppi(intrs[1], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
> > +set_interrupt(intrs[1], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
> > irq = timer_get_irq(TIMER_VIRT_PPI);
> >   dt_dprintk("  Virt interrupt %u\n", irq);
> > -set_interrupt_ppi(intrs[2], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
> > +set_interrupt(intrs[2], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
> > res = fdt_property_interrupts(fdt, intrs, 3);
> >   if ( res )
> > @@ -1503,9 +1503,9 @@ static int make_timer_domU_node(const struct domain
> > *d, void *fdt)
> >   return res;
> >   }
> >   -set_interrupt_ppi(intrs[0], GUEST_TIMER_PHYS_S_PPI, 0xf,
> > DT_IRQ_TYPE_LEVEL_LOW);
> > -set_interrupt_ppi(intrs[1], GUEST_TIMER_PHYS_NS_PPI, 0xf,
> > DT_IRQ_TYPE_LEVEL_LOW);
> > -set_interrupt_ppi(intrs[2], GUEST_TIMER_VIRT_PPI, 0xf,
> > DT_IRQ_TYPE_LEVEL_LOW);
> > +set_interrupt(intrs[0], GUEST_TIMER_PHYS_S_PPI, 0xf,
> > DT_IRQ_TYPE_LEVEL_LOW);
> > +set_interrupt(intrs[1], GUEST_TIMER_PHYS_NS_PPI, 0xf,
> > DT_IRQ_TYPE_LEVEL_LOW);
> > +set_interrupt(intrs[2], GUEST_TIMER_VIRT_PPI, 0xf,
> > DT_IRQ_TYPE_LEVEL_LOW);
> > res = fdt_property(fdt, "interrupts", intrs, sizeof (intrs[0]) * 3);
> >   if ( res )
> > @@ -1520,12 +1520,63 @@ static int make_timer_domU_node(const struct domain
> > *d, void *fdt)
> >   return res;
> >   }
> >   +#ifdef CONFIG_SBSA_VUART_CONSOLE
> > +static int make_vpl011_uart_node(const struct domain *d, void *fdt,
> > +   

Re: [Xen-devel] Error during cross compiling of xen by chroot

[Stewart Hildebrand]

> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of George John
> Sent: Thursday, July 5, 2018 1:41 AM
> To: xen-devel 
> Subject: [Xen-devel] Error during cross compiling of xen by chroot
> 
> Hi,
> I am using chroot to cross compile xen. I am getting the error as per
> the error log. I have installed libpixman. But still this is occuring.
> what could be the possible reason?

You should be able to gather more info by setting the verbose flag for the qemu 
build
diff --git a/tools/Makefile b/tools/Makefile
index 67977ad..fc82f5b 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -280,7 +280,7 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-find
$(CONFIG_QEMUU_EXTRA_ARGS) \
--cpu=$(IOEMU_CPU_ARCH) \
$(IOEMU_CONFIGURE_CROSS); \
-   $(MAKE) all
+   $(MAKE) V=1 all
 
 subdir-install-qemu-xen-dir: subdir-all-qemu-xen-dir
cd qemu-xen-build; \

Sort of related: if you truly want to cross compile Xen tools for aarch64 with 
less dependence on chroot - see the following example around lines 224-271 
https://gist.github.com/stewdk/110f43e0cc1d905fc6ed4c7e10d8d35e

Thanks,
Stewart Hildebrand
DornerWorks, Ltd.

> 
> Thanks and regards,
> George
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 00/21] dom0less step1: boot multiple domains from device tree

[Stefano Stabellini]

On Thu, 12 Jul 2018, Julien Grall wrote:
> Hi,
> 
> Would it be possible to provide a branch with the patch applied? It would be
> nice to have that for every version, so I can easily know on which version of
> you are based and avoid spending time trying to apply it :).

Makes sense, I'll do from next time

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

[Xen-devel] [PATCH v2 12/13] x86/sysctl: Implement XEN_SYSCTL_get_cpu_policy

[Andrew Cooper]

From: Sergey Dyasli 

Provide a SYSCTL for the toolstack to obtain complete system CPUID and MSR
policy information.

For the XSM side of things, this subop is closely related to
{phys,cputopo,numa}info, so shares the physinfo access vector.

Extend the xen-cpuid utility to be able to dump the system policies.  An
example output is:

  Xen reports there are maximum 113 leaves and 3 MSRs
  Raw policy: 93 leaves, 3 MSRs
   CPUID:
leaf subleaf  -> eax  ebx  ecx  edx
: -> 000d:756e6547:6c65746e:49656e69
0001: -> 000306c3:00100800:7ffafbff:bfebfbff
0002: -> 76036301:00f0b5ff::00c1
0004: -> 1c004121:01c0003f:003f:
0004:0001 -> 1c004122:01c0003f:003f:
0004:0002 -> 1c004143:01c0003f:01ff:
0004:0003 -> 1c03c163:03c0003f:1fff:0006
0005: -> 0040:0040:0003:00042120
0006: -> 0077:0002:0009:
0007: -> :27ab::9c00
000a: -> 07300403:::0603
000b: -> 0001:0002:0100:
000b:0001 -> 0004:0008:0201:
000d: -> 0007:0340:0340:
000d:0001 -> 0001:::
000d:0002 -> 0100:0240::
8000: -> 8008:::
8001: -> ::0021:2c100800
8002: -> 65746e49:2952286c:6f655820:2952286e
8003: -> 55504320:2d334520:30343231:20337620
8004: -> 2e332040:48473034:007a:
8006: -> ::01006040:
8007: -> :::0100
8008: -> 3027:::
   MSRs:
index-> value
00ce -> 8000

Signed-off-by: Andrew Cooper 
Signed-off-by: Sergey Dyasli 
Signed-off-by: Roger Pau Monné 
---
CC: Jan Beulich 
CC: Ian Jackson 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Sergey Dyasli 
CC: Daniel De Graaf 

v2:
 * Avoid introducing a Spectre V1 gadget
---
 tools/libxc/include/xenctrl.h   |  6 +++
 tools/libxc/xc_cpuid_x86.c  | 59 +
 tools/misc/xen-cpuid.c  | 87 +++--
 xen/arch/x86/sysctl.c   | 71 ++
 xen/include/public/sysctl.h | 17 
 xen/xsm/flask/hooks.c   |  1 +
 xen/xsm/flask/policy/access_vectors |  2 +-
 7 files changed, 239 insertions(+), 4 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index dd7d8a9..ee3ab09 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2553,6 +2553,12 @@ int xc_get_cpu_levelling_caps(xc_interface *xch, 
uint32_t *caps);
 int xc_get_cpu_featureset(xc_interface *xch, uint32_t index,
   uint32_t *nr_features, uint32_t *featureset);
 
+int xc_get_cpu_policy_size(xc_interface *xch, uint32_t *nr_leaves,
+   uint32_t *nr_msrs);
+int xc_get_system_cpu_policy(xc_interface *xch, uint32_t index,
+ uint32_t *nr_leaves, xen_cpuid_leaf_t *leaves,
+ uint32_t *nr_msrs, xen_msr_entry_t *msrs);
+
 uint32_t xc_get_cpu_featureset_size(void);
 
 enum xc_static_cpu_featuremask {
diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index cc7300c..8fd04ef 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -132,6 +132,65 @@ const uint32_t *xc_get_static_cpu_featuremask(
 }
 }
 
+int xc_get_cpu_policy_size(xc_interface *xch, uint32_t *nr_leaves,
+   uint32_t *nr_msrs)
+{
+struct xen_sysctl sysctl = {};
+int ret;
+
+sysctl.cmd = XEN_SYSCTL_get_cpu_policy;
+
+ret = do_sysctl(xch, );
+
+if ( !ret )
+{
+*nr_leaves = sysctl.u.cpu_policy.nr_leaves;
+*nr_msrs = sysctl.u.cpu_policy.nr_msrs;
+}
+
+return ret;
+}
+
+int xc_get_system_cpu_policy(xc_interface *xch, uint32_t index,
+ uint32_t *nr_leaves, xen_cpuid_leaf_t *leaves,
+ uint32_t *nr_msrs, xen_msr_entry_t *msrs)
+{
+struct xen_sysctl sysctl = {};
+DECLARE_HYPERCALL_BOUNCE(leaves,
+ *nr_leaves * sizeof(*leaves),
+ XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+DECLARE_HYPERCALL_BOUNCE(msrs,
+ *nr_msrs * sizeof(*msrs),
+ XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+int ret;
+
+if ( xc_hypercall_bounce_pre(xch, leaves) )
+return -1;
+
+if ( xc_hypercall_bounce_pre(xch, msrs) )
+return -1;
+
+sysctl.cmd = XEN_SYSCTL_get_cpu_policy;
+sysctl.u.cpu_policy.index 

[Xen-devel] [PATCH v2 13/13] x86/domctl: Implement XEN_DOMCTL_get_cpu_policy

[Andrew Cooper]

From: Sergey Dyasli 

This finally (after literally years of work!) marks the point where the
toolstack can ask the hypervisor for the current CPUID configuration of a
specific domain.

Also extend xen-cpuid's --policy mode to be able to take a domid and dump a
specific domains CPUID and MSR policy.

Signed-off-by: Andrew Cooper 
Signed-off-by: Sergey Dyasli 
---
CC: Jan Beulich 
CC: Ian Jackson 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Sergey Dyasli 
CC: Daniel De Graaf 
---
 tools/libxc/include/xenctrl.h   |  3 ++
 tools/libxc/xc_cpuid_x86.c  | 40 +++
 tools/misc/xen-cpuid.c  | 64 +++--
 xen/arch/x86/domctl.c   | 34 
 xen/include/public/domctl.h | 18 +++
 xen/xsm/flask/hooks.c   |  1 +
 xen/xsm/flask/policy/access_vectors |  1 +
 7 files changed, 152 insertions(+), 9 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index ee3ab09..3f156c1 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2558,6 +2558,9 @@ int xc_get_cpu_policy_size(xc_interface *xch, uint32_t 
*nr_leaves,
 int xc_get_system_cpu_policy(xc_interface *xch, uint32_t index,
  uint32_t *nr_leaves, xen_cpuid_leaf_t *leaves,
  uint32_t *nr_msrs, xen_msr_entry_t *msrs);
+int xc_get_domain_cpu_policy(xc_interface *xch, uint32_t domid,
+ uint32_t *nr_leaves, xen_cpuid_leaf_t *leaves,
+ uint32_t *nr_msrs, xen_msr_entry_t *msrs);
 
 uint32_t xc_get_cpu_featureset_size(void);
 
diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index 8fd04ef..e4c7a34 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -191,6 +191,46 @@ int xc_get_system_cpu_policy(xc_interface *xch, uint32_t 
index,
 return ret;
 }
 
+int xc_get_domain_cpu_policy(xc_interface *xch, uint32_t domid,
+ uint32_t *nr_leaves, xen_cpuid_leaf_t *leaves,
+ uint32_t *nr_msrs, xen_msr_entry_t *msrs)
+{
+DECLARE_DOMCTL;
+DECLARE_HYPERCALL_BOUNCE(leaves,
+ *nr_leaves * sizeof(*leaves),
+ XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+DECLARE_HYPERCALL_BOUNCE(msrs,
+ *nr_msrs * sizeof(*msrs),
+ XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+int ret;
+
+if ( xc_hypercall_bounce_pre(xch, leaves) )
+return -1;
+
+if ( xc_hypercall_bounce_pre(xch, msrs) )
+return -1;
+
+domctl.cmd = XEN_DOMCTL_get_cpu_policy;
+domctl.domain = domid;
+domctl.u.cpu_policy.nr_leaves = *nr_leaves;
+set_xen_guest_handle(domctl.u.cpu_policy.cpuid_policy, leaves);
+domctl.u.cpu_policy.nr_msrs = *nr_msrs;
+set_xen_guest_handle(domctl.u.cpu_policy.msr_policy, msrs);
+
+ret = do_domctl(xch, );
+
+xc_hypercall_bounce_post(xch, leaves);
+xc_hypercall_bounce_post(xch, msrs);
+
+if ( !ret )
+{
+*nr_leaves = domctl.u.cpu_policy.nr_leaves;
+*nr_msrs = domctl.u.cpu_policy.nr_msrs;
+}
+
+return ret;
+}
+
 struct cpuid_domain_info
 {
 enum
diff --git a/tools/misc/xen-cpuid.c b/tools/misc/xen-cpuid.c
index 1c14d93..dd39268 100644
--- a/tools/misc/xen-cpuid.c
+++ b/tools/misc/xen-cpuid.c
@@ -3,6 +3,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 
@@ -309,11 +311,13 @@ int main(int argc, char **argv)
 {
 enum { MODE_UNKNOWN, MODE_INFO, MODE_DETAIL, MODE_INTERPRET, MODE_POLICY }
 mode = MODE_UNKNOWN;
+int domid = -1;
 
 nr_features = xc_get_cpu_featureset_size();
 
 for ( ;; )
 {
+const char *tmp_optarg;
 int option_index = 0, c;
 static struct option long_options[] =
 {
@@ -321,11 +325,11 @@ int main(int argc, char **argv)
 { "info", no_argument, NULL, 'i' },
 { "detail", no_argument, NULL, 'd' },
 { "verbose", no_argument, NULL, 'v' },
-{ "policy", no_argument, NULL, 'p' },
+{ "policy", optional_argument, NULL, 'p' },
 { NULL, 0, NULL, 0 },
 };
 
-c = getopt_long(argc, argv, "hidvp", long_options, _index);
+c = getopt_long(argc, argv, "hidvp::", long_options, _index);
 
 if ( c == -1 )
 break;
@@ -345,6 +349,28 @@ int main(int argc, char **argv)
 
 case 'p':
 mode = MODE_POLICY;
+
+tmp_optarg = optarg;
+
+/* Make "--policy $DOMID" and "-p $DOMID" work. */
+if ( !optarg && optind < argc &&
+ argv[optind] != NULL && argv[optind][0] != '\0' &&
+ argv[optind][0] != '-' )
+tmp_optarg = argv[optind++];
+
+if ( tmp_optarg )
+{
+char *endptr;
+
+errno = 0;
+domid = 

[Xen-devel] [PATCH v2 10/13] libx86: introduce a helper to deserialise msr_policy objects

[Andrew Cooper]

From: Roger Pau Monné 

Signed-off-by: Sergey Dyasli 
Signed-off-by: Roger Pau Monné 
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Sergey Dyasli 
CC: Ian Jackson 

v2:
 * Rebase over the msr_{domain,vcpu}_policy rename
 * Only deserialse msr_policy
 * Expand boundary justifications
---
 xen/common/libx86/msr.c  | 51 
 xen/include/xen/libx86/msr.h | 10 +
 2 files changed, 61 insertions(+)

diff --git a/xen/common/libx86/msr.c b/xen/common/libx86/msr.c
index 71c8e9a..0912ace 100644
--- a/xen/common/libx86/msr.c
+++ b/xen/common/libx86/msr.c
@@ -45,6 +45,57 @@ int x86_msr_copy_to_buffer(const struct msr_policy *p,
 return 0;
 }
 
+int x86_msr_copy_from_buffer(struct msr_policy *p,
+ const msr_entry_buffer_t msrs, uint32_t nr_msrs,
+ uint32_t *err_msr)
+{
+unsigned int i;
+xen_msr_entry_t data;
+
+/*
+ * A well formed caller is expected pass an array with entries in order,
+ * and without any repetitions.  However, due to per-vendor differences,
+ * and in the case of upgrade or levelled scenarios, we typically expect
+ * fewer than MAX entries to be passed.
+ *
+ * Detecting repeated entries is prohibitively complicated, so we don't
+ * bother.  That said, one way or another if more than MAX entries are
+ * passed, something is wrong.
+ */
+if ( nr_msrs > MSR_MAX_SERIALISED_ENTRIES )
+return -E2BIG;
+
+for ( i = 0; i < nr_msrs; i++ )
+{
+if ( copy_from_buffer_offset(, msrs, i, 1) )
+return -EFAULT;
+
+if ( data.flags ) /* .flags MBZ */
+goto err;
+
+switch ( data.idx )
+{
+case MSR_INTEL_PLATFORM_INFO:
+if ( data.val > ~0u )
+goto err;
+
+p->plaform_info.raw = data.val;
+break;
+
+default:
+goto err;
+}
+}
+
+return 0;
+
+ err:
+if ( err_msr )
+*err_msr = data.idx;
+
+return -EINVAL;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/libx86/msr.h b/xen/include/xen/libx86/msr.h
index 2e4acd4..d71ad78 100644
--- a/xen/include/xen/libx86/msr.h
+++ b/xen/include/xen/libx86/msr.h
@@ -42,6 +42,16 @@ typedef xen_msr_entry_t msr_entry_buffer_t[];
 int x86_msr_copy_to_buffer(const struct msr_policy *p,
msr_entry_buffer_t msrs, uint32_t *nr_entries_p);
 
+/*
+ * Copy MSR data from a buffer, filling an msr_policy object.  MSR indicies
+ * are checked for being in range, but no content validation is performed for
+ * in-range MSRs.  On an error, the optional err_* pointer may help identify
+ * where the issue lies.
+ */
+int x86_msr_copy_from_buffer(struct msr_policy *dp,
+ const msr_entry_buffer_t msrs, uint32_t nr_msrs,
+ uint32_t *err_msr);
+
 #endif /* !XEN_LIBX86_MSR_H */
 
 /*
-- 
2.1.4


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

[Xen-devel] [PATCH v2 11/13] x86: Introduce struct cpu_policy to refer to a group of individual policies

[Andrew Cooper]

This is prep work for the following patch - please refer to it as well.

When auditing and manipulating policies, it is necessary to do so with a
complete set of policies, due to the interdependences of the contents.  A
containing structure like this will allow for clearer APIs and code.

As a first user, this structure is convenient for the mapping used by
XEN_SYSCTL_get_cpu_policy (implemented in the next patch), and for auditing
(later when XEN_DOMCTL_set_cpu_policy is implemented).

At this point, the distinction between *_max and *_default is introduced into
the ABI.  For now, *_default is mapped to *_max, but future development work
will result in *_default being a logical subset of *_max.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Sergey Dyasli 
CC: Ian Jackson 

v2:
 * Drop __read_mostly from MSR declarations.  Fixes clang build.
 * s/policy_group/cpu_policy/g s/cpumsr_policy/cpu_policy/g
 * Rebase over the msr_{domain,vcpu}_policy rename
 * Don't include vcpu_msrs in the cpu_policy
---
 xen/arch/x86/sysctl.c   | 27 +++
 xen/include/asm-x86/cpuid.h |  3 +++
 xen/include/public/sysctl.h | 20 
 xen/include/xen/libx86/cpu-policy.h | 24 
 4 files changed, 74 insertions(+)
 create mode 100644 xen/include/xen/libx86/cpu-policy.h

diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
index 4d372db..9986393 100644
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -31,6 +31,33 @@
 #include 
 #include 
 
+const struct cpu_policy system_policies[] = {
+[ XEN_SYSCTL_cpu_policy_raw ] = {
+_cpuid_policy,
+_msr_policy,
+},
+[ XEN_SYSCTL_cpu_policy_host ] = {
+_cpuid_policy,
+_msr_policy,
+},
+[ XEN_SYSCTL_cpu_policy_pv_max ] = {
+_max_cpuid_policy,
+_max_msr_policy,
+},
+[ XEN_SYSCTL_cpu_policy_hvm_max ] = {
+_max_cpuid_policy,
+_max_msr_policy,
+},
+[ XEN_SYSCTL_cpu_policy_pv_default ] = {
+_max_cpuid_policy,
+_max_msr_policy,
+},
+[ XEN_SYSCTL_cpu_policy_hvm_default ] = {
+_max_cpuid_policy,
+_max_msr_policy,
+},
+};
+
 struct l3_cache_info {
 int ret;
 unsigned long size;
diff --git a/xen/include/asm-x86/cpuid.h b/xen/include/asm-x86/cpuid.h
index ea79445..cb51ccb 100644
--- a/xen/include/asm-x86/cpuid.h
+++ b/xen/include/asm-x86/cpuid.h
@@ -8,6 +8,7 @@
 #include 
 #include 
 
+#include 
 #include 
 
 #include 
@@ -50,6 +51,8 @@ extern struct cpuidmasks cpuidmask_defaults;
 extern struct cpuid_policy raw_cpuid_policy, host_cpuid_policy,
 pv_max_cpuid_policy, hvm_max_cpuid_policy;
 
+extern const struct cpu_policy system_policies[];
+
 /* Check that all previously present features are still available. */
 bool recheck_cpu_features(unsigned int cpu);
 
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 839c1b9..7ec2dd9 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -1063,6 +1063,26 @@ struct xen_sysctl_set_parameter {
 uint16_t pad[3];/* IN: MUST be zero. */
 };
 
+#if defined(__i386__) || defined(__x86_64__)
+/*
+ * XEN_SYSCTL_get_cpu_policy (x86 specific)
+ *
+ * Return information about CPUID and MSR policies available on this host.
+ *  -   Raw: The real H/W values.
+ *  -  Host: The values Xen is using, (after command line overrides, etc).
+ *  - Max_*: Maximum set of features a PV or HVM guest can use.  Includes
+ *   experimental features outside of security support.
+ *  - Default_*: Default set of features a PV or HVM guest can use.  This is
+ *   the security supported set.
+ */
+#define XEN_SYSCTL_cpu_policy_raw  0
+#define XEN_SYSCTL_cpu_policy_host 1
+#define XEN_SYSCTL_cpu_policy_pv_max   2
+#define XEN_SYSCTL_cpu_policy_hvm_max  3
+#define XEN_SYSCTL_cpu_policy_pv_default   4
+#define XEN_SYSCTL_cpu_policy_hvm_default  5
+#endif
+
 struct xen_sysctl {
 uint32_t cmd;
 #define XEN_SYSCTL_readconsole1
diff --git a/xen/include/xen/libx86/cpu-policy.h 
b/xen/include/xen/libx86/cpu-policy.h
new file mode 100644
index 000..ee1c349
--- /dev/null
+++ b/xen/include/xen/libx86/cpu-policy.h
@@ -0,0 +1,24 @@
+/* Common data structures and functions consumed by hypervisor and toolstack */
+#ifndef XEN_LIBX86_POLICIES_H
+#define XEN_LIBX86_POLICIES_H
+
+#include 
+#include 
+
+struct cpu_policy
+{
+struct cpuid_policy *cpuid;
+struct msr_policy *msr;
+};
+
+#endif /* !XEN_LIBX86_POLICIES_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.1.4


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

[Xen-devel] Xen ARM Community Call Wednesday 25th July 9AM Pacific / 4PM UTC

[Stefano Stabellini]

Hi all,

It is time for another Xen on ARM Community Call. I suggest to talk
again on Wed 25 July at 9AM California time. 

Please reply to this thread suggestions topics for discussion. I'll
start by suggesting "progress on certifications".

This time we get to use the Xilinx WebEx conference system, see
attached. I also appended the details to join the conference call.

Cheers,

Stefano


JOIN WEBEX MEETING
https://xilinx.webex.com/xilinx/j.php?MTID=m94c112941ad6a6f6a0ccc2140c84bfe9
Meeting number: 920 504 982
Meeting password: akZPPX*9

JOIN BY PHONE
Call-in toll-free number: 1-(877) 582-3182  (US)
Call-in number: 1-(770) 657-9791  (US)
Show global numbers:
https://www.tcconline.com/offSite/OffSiteController.jpf?cc=1659920463
Conference Code: 165 992 0463
BEGIN:VCALENDAR
PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN
VERSION:2.0
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:Pacific Time
BEGIN:STANDARD
DTSTART:20161101T02
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:Standard Time
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20160301T02
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:Daylight Savings Time
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ATTENDEE;CN="Stefano Stabellini";ROLE=REQ-PARTICIPANT;RSVP=FALSE:MAILTO:stefa...@xilinx.com
ORGANIZER;CN="webex":MAILTO:messen...@webex.com
DTSTART;TZID="Pacific Time":20180725T09
DTEND;TZID="Pacific Time":20180725T10
LOCATION:https://xilinx.webex.com/xilinx
TRANSP:OPAQUE
SEQUENCE:1531511750
UID:21ecfe6a-1e52-4963-a493-ef025bf367d1
DTSTAMP:20180725T16Z
DESCRIPTION:\n\nJOIN WEBEX MEETING\nhttps://xilinx.webex.com/xilinx/j.php?MTID=mbdae4be069c5f63ec4d682d163b6f00e\nMeeting number: 920 504 982\nMeeting password: akZPPX*9\n\n\n\nJOIN BY PHONE\nCall-in toll-free number: 1-(877) 582-3182  (US)\nCall-in number: 1-(770) 657-9791  (US)\nShow global numbers:\nhttps://www.tcconline.com/offSite/OffSiteController.jpf?cc=1659920463\nConference Code: 165 992 0463\n\n\n\n\nCan't join the meeting? Contact support here:\nhttps://xilinx.webex.com/xilinx/mc\n\n\nIMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. You should inform all meeting attendees prior to recording if you intend to record the meeting.\n
X-ALT-DESC;FMTTYPE=text/html:			https://xilinx.webex.com/xilinx/j.php?MTID=mbdae4be069c5f63ec4d682d163b6f00e;>Join WebEx meeting		Meeting number: 920 504 982		Meeting password:akZPPX*9		Join by phone Call-in toll-free number:1-(877) 582-3182  (US) Call-in number:1-(770) 657-9791  (US) https://www.tcconline.com/offSite/OffSiteController.jpf?cc=1659920463;>Show global numbers Conference Code: 165 992 0463 		Can't join the meeting?	https://xilinx.webex.com/xilinx/mc;>	Contact support.	IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. You should inform all meeting attendees prior to recording if you intend to record the meeting.
SUMMARY:Xen on ARM Community Call
PRIORITY:5
CLASS:PUBLIC
BEGIN:VALARM
TRIGGER:-PT5M
ACTION:DISPLAY
DESCRIPTION:Reminder
END:VALARM
END:VEVENT
END:VCALENDAR
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 09/13] libx86: Introduce a helper to deserialise cpuid_policy objects

[Andrew Cooper]

As with the serialise side, Xen's copy_from_guest API is used, with a
compatibility wrapper for the userspace build.

Signed-off-by: Andrew Cooper 
Signed-off-by: Sergey Dyasli 
Signed-off-by: Roger Pau Monné 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Sergey Dyasli 
CC: Ian Jackson 

v2:
 * Rewrite copy_from_buffer_offset() to avoid multiple evaluation of its
   arguments.
 * Expand boundary justifications.
---
 xen/common/libx86/cpuid.c  | 94 ++
 xen/common/libx86/private.h| 14 +++
 xen/include/xen/libx86/cpuid.h | 11 +
 3 files changed, 119 insertions(+)

diff --git a/xen/common/libx86/cpuid.c b/xen/common/libx86/cpuid.c
index cf7dbd3..73cd574 100644
--- a/xen/common/libx86/cpuid.c
+++ b/xen/common/libx86/cpuid.c
@@ -123,6 +123,100 @@ int x86_cpuid_copy_to_buffer(const struct cpuid_policy *p,
 return 0;
 }
 
+int x86_cpuid_copy_from_buffer(struct cpuid_policy *p,
+   const cpuid_leaf_buffer_t leaves,
+   uint32_t nr_leaves, uint32_t *err_leaf,
+   uint32_t *err_subleaf)
+{
+unsigned int i;
+xen_cpuid_leaf_t data;
+struct cpuid_leaf *l = (void *)
+
+/*
+ * A well formed caller is expected pass an array with leaves in order,
+ * and without any repetitions.  However, due to per-vendor differences,
+ * and in the case of upgrade or levelled scenarios, we typically expect
+ * fewer than MAX leaves to be passed.
+ *
+ * Detecting repeated entries is prohibitively complicated, so we don't
+ * bother.  That said, one way or another if more than MAX leaves are
+ * passed, something is wrong.
+ */
+if ( nr_leaves > CPUID_MAX_SERIALISED_LEAVES )
+return -E2BIG;
+
+for ( i = 0; i < nr_leaves; ++i )
+{
+if ( copy_from_buffer_offset(, leaves, i, 1) )
+return -EFAULT;
+
+switch ( data.leaf )
+{
+case 0 ... ARRAY_SIZE(p->basic.raw) - 1:
+switch ( data.leaf )
+{
+case 0x4:
+if ( data.subleaf >= ARRAY_SIZE(p->cache.raw) )
+goto out_of_range;
+
+p->cache.raw[data.subleaf] = *l;
+break;
+
+case 0x7:
+if ( data.subleaf >= ARRAY_SIZE(p->feat.raw) )
+goto out_of_range;
+
+p->feat.raw[data.subleaf] = *l;
+break;
+
+case 0xb:
+if ( data.subleaf >= ARRAY_SIZE(p->topo.raw) )
+goto out_of_range;
+
+p->topo.raw[data.subleaf] = *l;
+break;
+
+case 0xd:
+if ( data.subleaf >= ARRAY_SIZE(p->xstate.raw) )
+goto out_of_range;
+
+p->xstate.raw[data.leaf] = *l;
+break;
+
+default:
+p->basic.raw[data.leaf] = *l;
+break;
+}
+break;
+
+case 0x4000:
+p->hv_limit = l->a;
+break;
+
+case 0x4100:
+p->hv2_limit = l->a;
+break;
+
+case 0x8000 ... 0x8000 + ARRAY_SIZE(p->extd.raw) - 1:
+p->extd.raw[data.leaf & 0x] = *l;
+break;
+
+default:
+goto out_of_range;
+}
+}
+
+return 0;
+
+ out_of_range:
+if ( err_leaf )
+*err_leaf = data.leaf;
+if ( err_subleaf )
+*err_subleaf = data.subleaf;
+
+return -ERANGE;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/libx86/private.h b/xen/common/libx86/private.h
index e874fb6..dc451d0 100644
--- a/xen/common/libx86/private.h
+++ b/xen/common/libx86/private.h
@@ -12,6 +12,7 @@
 #include 
 
 #define copy_to_buffer_offset copy_to_guest_offset
+#define copy_from_buffer_offset copy_from_guest_offset
 
 #else
 
@@ -44,6 +45,19 @@ static inline bool test_bit(unsigned int bit, const void 
*vaddr)
 0;  \
 })
 
+/* memcpy(), but with copy_from_guest_offset()'s API. */
+#define copy_from_buffer_offset(dst, src, index, nr)\
+({  \
+const typeof(*(dst)) *src_ = (src); \
+typeof(*(dst)) *dst_ = (dst);   \
+typeof(index) index_ = (index); \
+typeof(nr) nr_ = (nr), i_;  \
+\
+for ( i_ = 0; i_ < nr_; i_++ )  \
+dst_[i_] = src_[index_ + i_];   \
+0;  \
+})
+
 #endif /* __XEN__ */
 
 #endif /* XEN_LIBX86_PRIVATE_H */
diff --git a/xen/include/xen/libx86/cpuid.h b/xen/include/xen/libx86/cpuid.h
index 460b102..c4c4bd4 100644
--- a/xen/include/xen/libx86/cpuid.h
+++ b/xen/include/xen/libx86/cpuid.h
@@ -260,6 

[Xen-devel] [PATCH v2 04/13] libx86: Share struct cpuid_policy with userspace

[Andrew Cooper]

From: Roger Pau Monné 

Both Xen and the toolstack have need of the same logic when it comes to
manipulation and checking of the CPUID and MSR values offered to guests.  To
that end, libx86 is being introduced to allow Xen and the toolstack to share a
single implementation, rather than duplicating the logic.

No functional change.

Signed-off-by: Roger Pau Monné 
Signed-off-by: Andrew Cooper 
Reviewed-by: Wei Liu 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Sergey Dyasli 
CC: Ian Jackson 

v2:
 * Move MAX() into xen-tools/libs.h
 * Expand commit message.
---
 tools/include/xen-tools/libs.h |   4 +
 xen/include/asm-x86/cpuid.h| 219 -
 xen/include/xen/libx86/cpuid.h | 219 +
 3 files changed, 223 insertions(+), 219 deletions(-)

diff --git a/tools/include/xen-tools/libs.h b/tools/include/xen-tools/libs.h
index 63e3507..f78a3b5 100644
--- a/tools/include/xen-tools/libs.h
+++ b/tools/include/xen-tools/libs.h
@@ -13,4 +13,8 @@
 #define ARRAY_SIZE(a) (sizeof(a) / sizeof(*a))
 #endif
 
+#ifndef MAX
+#define MAX(x, y) ((x) > (y) ? (x) : (y))
+#endif
+
 #endif /* __XEN_TOOLS_LIBS__ */
diff --git a/xen/include/asm-x86/cpuid.h b/xen/include/asm-x86/cpuid.h
index 9637303..7a3f2f4 100644
--- a/xen/include/asm-x86/cpuid.h
+++ b/xen/include/asm-x86/cpuid.h
@@ -4,17 +4,6 @@
 #include 
 #include 
 
-#define FEATURESET_1d 0 /* 0x0001.edx  */
-#define FEATURESET_1c 1 /* 0x0001.ecx  */
-#define FEATURESET_e1d2 /* 0x8001.edx  */
-#define FEATURESET_e1c3 /* 0x8001.ecx  */
-#define FEATURESET_Da14 /* 0x000d:1.eax*/
-#define FEATURESET_7b05 /* 0x0007:0.ebx*/
-#define FEATURESET_7c06 /* 0x0007:0.ecx*/
-#define FEATURESET_e7d7 /* 0x8007.edx  */
-#define FEATURESET_e8b8 /* 0x8008.ebx  */
-#define FEATURESET_7d09 /* 0x0007:0.edx*/
-
 #ifndef __ASSEMBLY__
 #include 
 #include 
@@ -60,214 +49,6 @@ DECLARE_PER_CPU(struct cpuidmasks, cpuidmasks);
 /* Default masking MSR values, calculated at boot. */
 extern struct cpuidmasks cpuidmask_defaults;
 
-#define CPUID_GUEST_NR_BASIC  (0xdu + 1)
-#define CPUID_GUEST_NR_FEAT   (0u + 1)
-#define CPUID_GUEST_NR_CACHE  (5u + 1)
-#define CPUID_GUEST_NR_TOPO   (1u + 1)
-#define CPUID_GUEST_NR_XSTATE (62u + 1)
-#define CPUID_GUEST_NR_EXTD_INTEL (0x8u + 1)
-#define CPUID_GUEST_NR_EXTD_AMD   (0x1cu + 1)
-#define CPUID_GUEST_NR_EXTD   MAX(CPUID_GUEST_NR_EXTD_INTEL, \
-  CPUID_GUEST_NR_EXTD_AMD)
-
-struct cpuid_policy
-{
-#define DECL_BITFIELD(word) _DECL_BITFIELD(FEATURESET_ ## word)
-#define _DECL_BITFIELD(x)   __DECL_BITFIELD(x)
-#define __DECL_BITFIELD(x)  CPUID_BITFIELD_ ## x
-
-/* Basic leaves: 0x00xx */
-union {
-struct cpuid_leaf raw[CPUID_GUEST_NR_BASIC];
-struct {
-/* Leaf 0x0 - Max and vendor. */
-uint32_t max_leaf, vendor_ebx, vendor_ecx, vendor_edx;
-
-/* Leaf 0x1 - Family/model/stepping and features. */
-uint32_t raw_fms;
-uint8_t :8,   /* Brand ID. */
-clflush_size, /* Number of 8-byte blocks per cache line. */
-lppp, /* Logical processors per package. */
-apic_id;  /* Initial APIC ID. */
-union {
-uint32_t _1c;
-struct { DECL_BITFIELD(1c); };
-};
-union {
-uint32_t _1d;
-struct { DECL_BITFIELD(1d); };
-};
-
-/* Leaf 0x2 - TLB/Cache/Prefetch. */
-uint8_t l2_nr_queries; /* Documented as fixed to 1. */
-uint8_t l2_desc[15];
-
-uint64_t :64, :64; /* Leaf 0x3 - PSN. */
-uint64_t :64, :64; /* Leaf 0x4 - Structured Cache. */
-uint64_t :64, :64; /* Leaf 0x5 - MONITOR. */
-uint64_t :64, :64; /* Leaf 0x6 - Therm/Perf. */
-uint64_t :64, :64; /* Leaf 0x7 - Structured Features. */
-uint64_t :64, :64; /* Leaf 0x8 - rsvd */
-uint64_t :64, :64; /* Leaf 0x9 - DCA */
-
-/* Leaf 0xa - Intel PMU. */
-uint8_t pmu_version, _pmu[15];
-
-uint64_t :64, :64; /* Leaf 0xb - Topology. */
-uint64_t :64, :64; /* Leaf 0xc - rsvd */
-uint64_t :64, :64; /* Leaf 0xd - XSTATE. */
-};
-} basic;
-
-/* Structured cache leaf: 0x0004[xx] */
-union {
-struct cpuid_leaf raw[CPUID_GUEST_NR_CACHE];
-struct cpuid_cache_leaf {
-uint32_t type:5,
-:27, :32, :32, :32;
-} subleaf[CPUID_GUEST_NR_CACHE];
-} cache;
-
-/* Structured feature leaf: 0x0007[xx] */
-union {
-struct cpuid_leaf raw[CPUID_GUEST_NR_FEAT];
-struct {
-/* Subleaf 0. */
-uint32_t max_subleaf;
-union {
-uint32_t _7b0;
-  

[Xen-devel] [PATCH v2 00/13] x86: CPUID and MSR policy marshalling support

[Andrew Cooper]

This series introduces libx86, a small shared library between the hypervisor
and libxc, and hypercalls to get full CPUID/MSR policies.  Future work will
implement XEN_DOMCTL_set_cpumsr_policy, after the auditing and comparison
logic is sorted.

In the meantime, the data marshalling logic is in a suitable state for review.

This series is based on staging, and can be found in git form here:

  
http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/cpuid-marshal-v2

There are many changes from v1.  See individual patches for details.

Andrew Cooper (6):
  x86/msr: Drop stale comment for vcpu_msrs.spec_ctrl
  libx86: Introduce libx86/cpuid.h
  libx86: Introduce libx86/msr.h and share msr_policy with userspace
  libx86: Introduce a helper to serialise cpuid_policy objects
  libx86: Introduce a helper to deserialise cpuid_policy objects
  x86: Introduce struct cpu_policy to refer to a group of individual policies

Roger Pau Monné (5):
  libx86: generate cpuid-autogen.h in the libx86 include dir
  libx86: Share struct cpuid_policy with userspace
  libx86: introduce a libx86 shared library
  libx86: Introduce a helper to serialise msr_policy objects
  libx86: introduce a helper to deserialise msr_policy objects

Sergey Dyasli (2):
  x86/sysctl: Implement XEN_SYSCTL_get_cpu_policy
  x86/domctl: Implement XEN_DOMCTL_get_cpu_policy

 .gitignore  |   2 +-
 tools/include/Makefile  |   5 +
 tools/include/xen-tools/libs.h  |   8 +
 tools/libxc/Makefile|  15 +-
 tools/libxc/include/xenctrl.h   |  10 +-
 tools/libxc/xc_cpuid_x86.c  | 112 +++---
 tools/misc/xen-cpuid.c  | 133 +++-
 tools/xenstore/xenstored_core.h |   2 -
 xen/arch/x86/cpu/common.c   |   2 +-
 xen/arch/x86/cpuid.c|  32 +---
 xen/arch/x86/domctl.c   |  34 +
 xen/arch/x86/sysctl.c   |  98 
 xen/arch/x86/x86_emulate/x86_emulate.h  |   7 +-
 xen/common/Makefile |   1 +
 xen/common/libx86/Makefile  |   2 +
 xen/common/libx86/cpuid.c   | 228 
 xen/common/libx86/msr.c | 107 +
 xen/common/libx86/private.h |  73 +
 xen/include/Makefile|  11 +-
 xen/include/asm-x86/cpufeatures.h   |   2 +-
 xen/include/asm-x86/cpuid.h | 228 +---
 xen/include/asm-x86/msr.h   |  28 +---
 xen/include/public/arch-x86/xen.h   |  18 +++
 xen/include/public/domctl.h |  18 +++
 xen/include/public/sysctl.h |  37 +
 xen/include/xen/libx86/Makefile |   8 +
 xen/include/xen/libx86/cpu-policy.h |  24 +++
 xen/include/{asm-x86 => xen/libx86}/cpuid.h | 107 ++---
 xen/include/xen/libx86/msr.h|  65 
 xen/xsm/flask/hooks.c   |   2 +
 xen/xsm/flask/policy/access_vectors |   3 +-
 31 files changed, 1036 insertions(+), 386 deletions(-)
 create mode 100644 xen/common/libx86/Makefile
 create mode 100644 xen/common/libx86/cpuid.c
 create mode 100644 xen/common/libx86/msr.c
 create mode 100644 xen/common/libx86/private.h
 create mode 100644 xen/include/xen/libx86/Makefile
 create mode 100644 xen/include/xen/libx86/cpu-policy.h
 copy xen/include/{asm-x86 => xen/libx86}/cpuid.h (77%)
 create mode 100644 xen/include/xen/libx86/msr.h

-- 
2.1.4


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

[Xen-devel] [PATCH v2 06/13] libx86: Introduce libx86/msr.h and share msr_policy with userspace

[Andrew Cooper]

To facilitate the shared Xen and toolstack code in libx86, struct msr_policy
needs to be available in the same way as struct cpuid_policy.

Signed-off-by: Andrew Cooper 
Reviewed-by: Wei Liu 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Sergey Dyasli 
CC: Ian Jackson 

v2:
 * Rebase over the msr_{domain,vcpu}_policy rename
 * Don't move vcpu_msrs into libx86
---
 tools/libxc/xc_cpuid_x86.c   |  1 +
 xen/include/asm-x86/msr.h| 23 +++
 xen/include/xen/libx86/msr.h | 35 +++
 3 files changed, 39 insertions(+), 20 deletions(-)
 create mode 100644 xen/include/xen/libx86/msr.h

diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index 3c214c8..cc7300c 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -33,6 +33,7 @@ enum {
 };
 
 #include 
+#include 
 
 #define bitmaskof(idx)  (1u << ((idx) & 31))
 #define featureword_of(idx) ((idx) >> 5)
diff --git a/xen/include/asm-x86/msr.h b/xen/include/asm-x86/msr.h
index 9b4e4e0..e6f6f11 100644
--- a/xen/include/asm-x86/msr.h
+++ b/xen/include/asm-x86/msr.h
@@ -8,6 +8,9 @@
 #include 
 #include 
 #include 
+
+#include 
+
 #include 
 #include 
 
@@ -257,26 +260,6 @@ static inline void wrmsr_tsc_aux(uint32_t val)
 }
 }
 
-/* MSR policy object for shared per-domain MSRs */
-struct msr_policy
-{
-/*
- * 0x00ce - MSR_INTEL_PLATFORM_INFO
- *
- * This MSR is non-architectural, but for simplicy we allow it to be read
- * unconditionally.  CPUID Faulting support can be fully emulated for HVM
- * guests so can be offered unconditionally, while support for PV guests
- * is dependent on real hardware support.
- */
-union {
-uint32_t raw;
-struct {
-uint32_t :31;
-bool cpuid_faulting:1;
-};
-} plaform_info;
-};
-
 extern struct msr_policy raw_msr_policy,
 host_msr_policy,
  hvm_max_msr_policy,
diff --git a/xen/include/xen/libx86/msr.h b/xen/include/xen/libx86/msr.h
new file mode 100644
index 000..b8b1751
--- /dev/null
+++ b/xen/include/xen/libx86/msr.h
@@ -0,0 +1,35 @@
+/* Common data structures and functions consumed by hypervisor and toolstack */
+#ifndef XEN_LIBX86_MSR_H
+#define XEN_LIBX86_MSR_H
+
+/* MSR policy object for shared per-domain MSRs */
+struct msr_policy
+{
+/*
+ * 0x00ce - MSR_INTEL_PLATFORM_INFO
+ *
+ * This MSR is non-architectural, but for simplicy we allow it to be read
+ * unconditionally.  CPUID Faulting support can be fully emulated for HVM
+ * guests so can be offered unconditionally, while support for PV guests
+ * is dependent on real hardware support.
+ */
+union {
+uint32_t raw;
+struct {
+uint32_t :31;
+bool cpuid_faulting:1;
+};
+} plaform_info;
+};
+
+#endif /* !XEN_LIBX86_MSR_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.1.4


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

[Xen-devel] [PATCH v2 05/13] libx86: introduce a libx86 shared library

[Andrew Cooper]

From: Roger Pau Monné 

Move x86_cpuid_lookup_deep_deps() into the shared library, removing the
individual copies from the hypervisor and libxc respectively.

Signed-off-by: Roger Pau Monné 
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Sergey Dyasli 
CC: Ian Jackson 

v2:
 * Rename libx86-private.h to just private.h
 * Only vpath libx86 for CONFIG_X86 builds of libxc
---
 tools/libxc/Makefile   |  6 ++
 tools/libxc/include/xenctrl.h  |  1 -
 tools/libxc/xc_cpuid_x86.c | 29 +---
 xen/arch/x86/cpu/common.c  |  2 +-
 xen/arch/x86/cpuid.c   | 32 +-
 xen/common/Makefile|  1 +
 xen/common/libx86/Makefile |  1 +
 xen/common/libx86/cpuid.c  | 44 ++
 xen/common/libx86/private.h| 38 
 xen/include/asm-x86/cpuid.h|  2 --
 xen/include/xen/libx86/cpuid.h |  2 ++
 11 files changed, 95 insertions(+), 63 deletions(-)
 create mode 100644 xen/common/libx86/Makefile
 create mode 100644 xen/common/libx86/cpuid.c
 create mode 100644 xen/common/libx86/private.h

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index ca2b203..cd4225c 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -80,6 +80,12 @@ GUEST_SRCS-y += $(ELF_SRCS-y)
 $(patsubst %.c,%.o,$(ELF_SRCS-y)): CFLAGS += -Wno-pointer-sign
 $(patsubst %.c,%.opic,$(ELF_SRCS-y)): CFLAGS += -Wno-pointer-sign
 
+ifeq ($(CONFIG_X86),y) # Add libx86 to the build
+vpath %.c ../../xen/common/libx86
+
+GUEST_SRCS-y += cpuid.c
+endif
+
 # new domain builder
 GUEST_SRCS-y += xc_dom_core.c xc_dom_boot.c
 GUEST_SRCS-y += xc_dom_elfloader.c
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 5520c94..dd7d8a9 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2564,7 +2564,6 @@ enum xc_static_cpu_featuremask {
 XC_FEATUREMASK_DEEP_FEATURES,
 };
 const uint32_t *xc_get_static_cpu_featuremask(enum xc_static_cpu_featuremask);
-const uint32_t *xc_get_feature_deep_deps(uint32_t feature);
 
 #endif
 
diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index d2f85aa..3c214c8 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -131,33 +131,6 @@ const uint32_t *xc_get_static_cpu_featuremask(
 }
 }
 
-const uint32_t *xc_get_feature_deep_deps(uint32_t feature)
-{
-static const struct {
-uint32_t feature;
-uint32_t fs[FEATURESET_NR_ENTRIES];
-} deep_deps[] = INIT_DEEP_DEPS;
-
-unsigned int start = 0, end = ARRAY_SIZE(deep_deps);
-
-BUILD_BUG_ON(ARRAY_SIZE(deep_deps) != NR_DEEP_DEPS);
-
-/* deep_deps[] is sorted.  Perform a binary search. */
-while ( start < end )
-{
-unsigned int mid = start + ((end - start) / 2);
-
-if ( deep_deps[mid].feature > feature )
-end = mid;
-else if ( deep_deps[mid].feature < feature )
-start = mid + 1;
-else
-return deep_deps[mid].fs;
-}
-
-return NULL;
-}
-
 struct cpuid_domain_info
 {
 enum
@@ -677,7 +650,7 @@ static void sanitise_featureset(struct cpuid_domain_info 
*info)
 const uint32_t *dfs;
 
 if ( !test_bit(b, disabled_features) ||
- !(dfs = xc_get_feature_deep_deps(b)) )
+ !(dfs = x86_cpuid_lookup_deep_deps(b)) )
  continue;
 
 for ( i = 0; i < ARRAY_SIZE(disabled_features); ++i )
diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 6570c2d..185fefe 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -62,7 +62,7 @@ void __init setup_clear_cpu_cap(unsigned int cap)
   __builtin_return_address(0), cap);
 
__clear_bit(cap, boot_cpu_data.x86_capability);
-   dfs = lookup_deep_deps(cap);
+   dfs = x86_cpuid_lookup_deep_deps(cap);
 
if (!dfs)
return;
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 3c29191..731ccb6 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -97,7 +97,7 @@ static void sanitise_featureset(uint32_t *fs)
 for_each_set_bit(i, (void *)disabled_features,
  sizeof(disabled_features) * 8)
 {
-const uint32_t *dfs = lookup_deep_deps(i);
+const uint32_t *dfs = x86_cpuid_lookup_deep_deps(i);
 unsigned int j;
 
 ASSERT(dfs); /* deep_features[] should guarentee this. */
@@ -544,36 +544,6 @@ bool recheck_cpu_features(unsigned int cpu)
 return okay;
 }
 
-const uint32_t *lookup_deep_deps(uint32_t feature)
-{
-static const struct {
-uint32_t feature;
-uint32_t fs[FSCAPINTS];
-} deep_deps[] = INIT_DEEP_DEPS;
-unsigned int start = 0, end = ARRAY_SIZE(deep_deps);
-
-BUILD_BUG_ON(ARRAY_SIZE(deep_deps) != NR_DEEP_DEPS);
-
-/* Fast early exit. */
-if ( 

[Xen-devel] [PATCH v2 02/13] libx86: Introduce libx86/cpuid.h

[Andrew Cooper]

Begin to untangle the header dependency tangle by moving definition of
struct cpuid_leaf out of x86_emulate.h into the new cpuid.h.

Additionally, plumb the header through to libxc.  This is technically a
redundant include at this point, but it helps build-test the later changes,
and will be used eventually.

Signed-off-by: Andrew Cooper 
Signed-off-by: Roger Pau Monné 
Reviewed-by: Wei Liu 
---
CC: Jan Beulich 
CC: Roger Pau Monné 
CC: Sergey Dyasli 
CC: Ian Jackson 

Note concerning the positioning of libx86.  It turns out after trying to move
it elsewhere that the movement is prohibitive because of the way Xen headers
are included by the tools.

For now, this is consistent with the other libs, and we can move it in the
future after some hygene has been applied to the build system.
---
 tools/include/Makefile |  1 +
 tools/libxc/xc_cpuid_x86.c |  2 ++
 xen/arch/x86/x86_emulate/x86_emulate.h |  7 ++-
 xen/include/asm-x86/cpuid.h|  4 +++-
 xen/include/xen/libx86/cpuid.h | 20 
 5 files changed, 28 insertions(+), 6 deletions(-)
 create mode 100644 xen/include/xen/libx86/cpuid.h

diff --git a/tools/include/Makefile b/tools/include/Makefile
index 270a34f..a2403fc 100644
--- a/tools/include/Makefile
+++ b/tools/include/Makefile
@@ -23,6 +23,7 @@ xen/.dir:
ln -sf $(XEN_ROOT)/xen/include/acpi acpi
 ifeq ($(CONFIG_X86),y)
ln -sf $(XEN_ROOT)/xen/include/asm-x86 xen/asm
+   ln -sf $(XEN_ROOT)/xen/include/xen/libx86 xen/libx86
 endif
touch $@
 
diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index c5c3cdc..090e199 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -33,6 +33,8 @@ enum {
 };
 #include "_xc_cpuid_autogen.h"
 
+#include 
+
 #define bitmaskof(idx)  (1u << ((idx) & 31))
 #define featureword_of(idx) ((idx) >> 5)
 #define clear_feature(idx, dst) ((dst) &= ~bitmaskof(idx))
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.h 
b/xen/arch/x86/x86_emulate/x86_emulate.h
index c22e774..abd9796 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.h
+++ b/xen/arch/x86/x86_emulate/x86_emulate.h
@@ -23,6 +23,8 @@
 #ifndef __X86_EMULATE_H__
 #define __X86_EMULATE_H__
 
+#include 
+
 #define MAX_INST_LEN 15
 
 #if defined(__i386__)
@@ -172,11 +174,6 @@ enum x86_emulate_fpu_type {
 X86EMUL_FPU_none
 };
 
-struct cpuid_leaf
-{
-uint32_t a, b, c, d;
-};
-
 struct x86_emulate_state;
 
 /*
diff --git a/xen/include/asm-x86/cpuid.h b/xen/include/asm-x86/cpuid.h
index 4113a5e..9637303 100644
--- a/xen/include/asm-x86/cpuid.h
+++ b/xen/include/asm-x86/cpuid.h
@@ -18,7 +18,9 @@
 #ifndef __ASSEMBLY__
 #include 
 #include 
-#include 
+
+#include 
+
 #include 
 
 extern const uint32_t known_features[FSCAPINTS];
diff --git a/xen/include/xen/libx86/cpuid.h b/xen/include/xen/libx86/cpuid.h
new file mode 100644
index 000..3ccc68e
--- /dev/null
+++ b/xen/include/xen/libx86/cpuid.h
@@ -0,0 +1,20 @@
+/* Common data structures and functions consumed by hypervisor and toolstack */
+#ifndef XEN_LIBX86_CPUID_H
+#define XEN_LIBX86_CPUID_H
+
+struct cpuid_leaf
+{
+uint32_t a, b, c, d;
+};
+
+#endif /* !XEN_LIBX86_CPUID_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.1.4


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

[Xen-devel] [PATCH v2 03/13] libx86: generate cpuid-autogen.h in the libx86 include dir

[Andrew Cooper]

From: Roger Pau Monné 

This avoids all users needing to opencode local generation of the file.

Signed-off-by: Roger Pau Monné 
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Sergey Dyasli 
CC: Ian Jackson 

v2:
 * Rewrite from scratch
---
 .gitignore|  2 +-
 tools/include/Makefile|  6 +-
 tools/libxc/Makefile  |  9 -
 tools/libxc/xc_cpuid_x86.c|  1 -
 xen/include/Makefile  | 11 +--
 xen/include/asm-x86/cpufeatures.h |  2 +-
 xen/include/xen/libx86/Makefile   |  8 
 xen/include/xen/libx86/cpuid.h|  2 ++
 8 files changed, 22 insertions(+), 19 deletions(-)
 create mode 100644 xen/include/xen/libx86/Makefile

diff --git a/.gitignore b/.gitignore
index 5b8448d..861f2ea 100644
--- a/.gitignore
+++ b/.gitignore
@@ -311,7 +311,6 @@ xen/arch/*/efi/runtime.c
 xen/include/headers*.chk
 xen/include/asm
 xen/include/asm-*/asm-offsets.h
-xen/include/asm-x86/cpuid-autogen.h
 xen/include/compat/*
 xen/include/config/
 xen/include/generated/
@@ -319,6 +318,7 @@ xen/include/public/public
 xen/include/xen/*.new
 xen/include/xen/acm_policy.h
 xen/include/xen/compile.h
+xen/include/xen/libx86/cpuid-autogen.h
 xen/test/livepatch/config.h
 xen/test/livepatch/xen_bye_world.livepatch
 xen/test/livepatch/xen_hello_world.livepatch
diff --git a/tools/include/Makefile b/tools/include/Makefile
index a2403fc..07162a7 100644
--- a/tools/include/Makefile
+++ b/tools/include/Makefile
@@ -23,7 +23,11 @@ xen/.dir:
ln -sf $(XEN_ROOT)/xen/include/acpi acpi
 ifeq ($(CONFIG_X86),y)
ln -sf $(XEN_ROOT)/xen/include/asm-x86 xen/asm
-   ln -sf $(XEN_ROOT)/xen/include/xen/libx86 xen/libx86
+   mkdir -p xen/libx86
+   for f in $(filter-out %autogen.h,$(patsubst 
$(XEN_ROOT)/xen/include/xen/libx86/%,%,Makefile $(wildcard 
$(XEN_ROOT)/xen/include/xen/libx86/*.h))); do \
+   ln -sf $(XEN_ROOT)/xen/include/xen/libx86/$$f xen/libx86/$$f; \
+   done
+   $(MAKE) -C xen/libx86 all XEN_ROOT=$(XEN_ROOT)
 endif
touch $@
 
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 157553c..ca2b203 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -147,15 +147,6 @@ $(eval $(genpath-target))
 
 xc_private.h: _paths.h
 
-ifeq ($(CONFIG_X86),y)
-
-_xc_cpuid_autogen.h: $(XEN_ROOT)/xen/include/public/arch-x86/cpufeatureset.h 
$(XEN_ROOT)/xen/tools/gen-cpuid.py
-   $(PYTHON) $(XEN_ROOT)/xen/tools/gen-cpuid.py -i $^ -o $@.new
-   $(call move-if-changed,$@.new,$@)
-
-build: _xc_cpuid_autogen.h
-endif
-
 $(CTRL_LIB_OBJS) $(GUEST_LIB_OBJS) \
 $(CTRL_PIC_OBJS) $(GUEST_PIC_OBJS): xc_private.h
 
diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index 090e199..d2f85aa 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -31,7 +31,6 @@ enum {
 #define XEN_CPUFEATURE(name, value) X86_FEATURE_##name = value,
 #include 
 };
-#include "_xc_cpuid_autogen.h"
 
 #include 
 
diff --git a/xen/include/Makefile b/xen/include/Makefile
index 7c5034e..7b4e862 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -141,14 +141,13 @@ headers++.chk: $(PUBLIC_HEADERS) Makefile
 endif
 
 ifeq ($(XEN_TARGET_ARCH),x86_64)
+.PHONY: libx86-all
+libx86-all:
+   $(MAKE) -C xen/libx86 all
 
-$(BASEDIR)/include/asm-x86/cpuid-autogen.h: 
$(BASEDIR)/include/public/arch-x86/cpufeatureset.h 
$(BASEDIR)/tools/gen-cpuid.py FORCE
-   $(PYTHON) $(BASEDIR)/tools/gen-cpuid.py -i $< -o $@.new
-   $(call move-if-changed,$@.new,$@)
-
-all: $(BASEDIR)/include/asm-x86/cpuid-autogen.h
+all: libx86-all
 endif
 
 clean::
rm -rf compat config generated headers*.chk
-   rm -f $(BASEDIR)/include/asm-x86/cpuid-autogen.h
+   rm -f $(BASEDIR)/include/xen/libx86/cpuid-autogen.h
diff --git a/xen/include/asm-x86/cpufeatures.h 
b/xen/include/asm-x86/cpufeatures.h
index 8e5cc53..b7ceb20 100644
--- a/xen/include/asm-x86/cpufeatures.h
+++ b/xen/include/asm-x86/cpufeatures.h
@@ -2,7 +2,7 @@
  * Explicitly intended for multiple inclusion.
  */
 
-#include 
+#include 
 
 #define FSCAPINTS FEATURESET_NR_ENTRIES
 
diff --git a/xen/include/xen/libx86/Makefile b/xen/include/xen/libx86/Makefile
new file mode 100644
index 000..408d69c
--- /dev/null
+++ b/xen/include/xen/libx86/Makefile
@@ -0,0 +1,8 @@
+include $(XEN_ROOT)/Config.mk
+
+.PHONY: all
+all: cpuid-autogen.h
+
+cpuid-autogen.h: $(XEN_ROOT)/xen/include/public/arch-x86/cpufeatureset.h 
$(XEN_ROOT)/xen/tools/gen-cpuid.py
+   $(PYTHON) $(XEN_ROOT)/xen/tools/gen-cpuid.py -i $< -o $@.new
+   $(call move-if-changed,$@.new,$@)
diff --git a/xen/include/xen/libx86/cpuid.h b/xen/include/xen/libx86/cpuid.h
index 3ccc68e..8f101ba 100644
--- a/xen/include/xen/libx86/cpuid.h
+++ b/xen/include/xen/libx86/cpuid.h
@@ -2,6 +2,8 @@
 #ifndef XEN_LIBX86_CPUID_H
 #define XEN_LIBX86_CPUID_H
 
+#include 
+
 struct cpuid_leaf
 {
 uint32_t a, b, c, d;
-- 
2.1.4

[Xen-devel] [PATCH v2 08/13] libx86: Introduce a helper to serialise msr_policy objects

[Andrew Cooper]

From: Roger Pau Monné 

As with CPUID, an architectural form is used for representing the MSR data.
It is expected not to change moving forwards, but does have a 32 bit field
(currently reserved) which can be used compatibly if needs be.

Signed-off-by: Andrew Cooper 
Signed-off-by: Sergey Dyasli 
Signed-off-by: Roger Pau Monné 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Sergey Dyasli 
CC: Ian Jackson 

v2:
 * Rebase over the msr_{domain,vcpu}_policy rename
 * Only serialise msr_policy
 * Change to an array typedef for constness reasons
---
 tools/libxc/Makefile  |  2 +-
 xen/common/libx86/Makefile|  1 +
 xen/common/libx86/msr.c   | 56 +++
 xen/common/libx86/private.h   |  3 +++
 xen/include/public/arch-x86/xen.h |  9 ++-
 xen/include/xen/libx86/msr.h  | 20 ++
 6 files changed, 89 insertions(+), 2 deletions(-)
 create mode 100644 xen/common/libx86/msr.c

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index cd4225c..904e026 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -83,7 +83,7 @@ $(patsubst %.c,%.opic,$(ELF_SRCS-y)): CFLAGS += 
-Wno-pointer-sign
 ifeq ($(CONFIG_X86),y) # Add libx86 to the build
 vpath %.c ../../xen/common/libx86
 
-GUEST_SRCS-y += cpuid.c
+GUEST_SRCS-y += cpuid.c msr.c
 endif
 
 # new domain builder
diff --git a/xen/common/libx86/Makefile b/xen/common/libx86/Makefile
index 3fb2e0b..2f9691e 100644
--- a/xen/common/libx86/Makefile
+++ b/xen/common/libx86/Makefile
@@ -1 +1,2 @@
 obj-y += cpuid.o
+obj-y += msr.o
diff --git a/xen/common/libx86/msr.c b/xen/common/libx86/msr.c
new file mode 100644
index 000..71c8e9a
--- /dev/null
+++ b/xen/common/libx86/msr.c
@@ -0,0 +1,56 @@
+#include "private.h"
+
+#include 
+
+/*
+ * Copy a single MSR into the provided msr_entry_buffer_t buffer, performing a
+ * boundary check against the buffer size.
+ */
+static int copy_msr_to_buffer(uint32_t idx, uint64_t val,
+  msr_entry_buffer_t msrs,
+  uint32_t *curr_entry, const uint32_t nr_entries)
+{
+const xen_msr_entry_t ent = { .idx = idx, .val = val };
+
+if ( *curr_entry == nr_entries )
+return -ENOBUFS;
+
+if ( copy_to_buffer_offset(msrs, *curr_entry, , 1) )
+return -EFAULT;
+
+++*curr_entry;
+
+return 0;
+}
+
+int x86_msr_copy_to_buffer(const struct msr_policy *p,
+   msr_entry_buffer_t msrs, uint32_t *nr_entries_p)
+{
+const uint32_t nr_entries = *nr_entries_p;
+uint32_t curr_entry = 0;
+
+#define COPY_MSR(idx, val)  \
+({  int ret;\
+if ( (ret = copy_msr_to_buffer( \
+  idx, val, msrs, _entry, nr_entries)) )   \
+return ret; \
+})
+
+COPY_MSR(MSR_INTEL_PLATFORM_INFO, p->plaform_info.raw);
+
+#undef COPY_MSR
+
+*nr_entries_p = curr_entry;
+
+return 0;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/common/libx86/private.h b/xen/common/libx86/private.h
index 5f59961..e874fb6 100644
--- a/xen/common/libx86/private.h
+++ b/xen/common/libx86/private.h
@@ -9,6 +9,7 @@
 #include 
 
 #include 
+#include 
 
 #define copy_to_buffer_offset copy_to_guest_offset
 
@@ -19,6 +20,8 @@
 #include 
 #include 
 
+#include 
+
 #include 
 
 static inline bool test_bit(unsigned int bit, const void *vaddr)
diff --git a/xen/include/public/arch-x86/xen.h 
b/xen/include/public/arch-x86/xen.h
index f3bdd83..55a149f 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -315,7 +315,7 @@ struct xen_arch_domainconfig {
 #endif
 
 /*
- * Representations of architectural CPUID information.  Used as the
+ * Representations of architectural CPUID and MSR information.  Used as the
  * serialised version of Xen's internal representation.
  */
 typedef struct xen_cpuid_leaf {
@@ -325,6 +325,13 @@ typedef struct xen_cpuid_leaf {
 } xen_cpuid_leaf_t;
 DEFINE_XEN_GUEST_HANDLE(xen_cpuid_leaf_t);
 
+typedef struct xen_msr_entry {
+uint32_t idx;
+uint32_t flags; /* Reserved MBZ. */
+uint64_t val;
+} xen_msr_entry_t;
+DEFINE_XEN_GUEST_HANDLE(xen_msr_entry_t);
+
 #endif /* !__ASSEMBLY__ */
 
 /*
diff --git a/xen/include/xen/libx86/msr.h b/xen/include/xen/libx86/msr.h
index b8b1751..2e4acd4 100644
--- a/xen/include/xen/libx86/msr.h
+++ b/xen/include/xen/libx86/msr.h
@@ -2,6 +2,9 @@
 #ifndef XEN_LIBX86_MSR_H
 #define XEN_LIBX86_MSR_H
 
+/* Maximum number of MSRs written when serialising msr_domain_policy. */
+#define MSR_MAX_SERIALISED_ENTRIES 1
+
 /* MSR policy object for shared per-domain MSRs */
 struct msr_policy
 {
@@ -22,6 +25,23 @@ struct msr_policy
 } plaform_info;
 };
 
+#ifdef __XEN__

[Xen-devel] [PATCH v2 07/13] libx86: Introduce a helper to serialise cpuid_policy objects

[Andrew Cooper]

The serialised form is made up of the leaf, subleaf and data tuple.  As this
is the architectural form, it is expected not to change going forwards.

The serialisation of the Xen/Viridian leaves isn't fully implemented yet.  It
is just enough to be bug-compatible with the current DOMCTL_set_cpuid
behaviour, but needs further hypervisor work before the toolstack can sensibly
control these values.

x86_cpuid_copy_to_buffer() is implemented using Xen's regular copy_to_guest
primitives, with an API-compatible memcpy() is used for the libxc half of the
build.

Signed-off-by: Andrew Cooper 
Signed-off-by: Roger Pau Monné 
Signed-off-by: Sergey Dyasli 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Sergey Dyasli 
CC: Ian Jackson 

v2:
 * Move MIN() into xen-tools/libs.h.
 * Leave a TODO for the Xen/Viridian leaf infrastructure, and update the
   commit message.
 * Rewrite copy_to_buffer_offset() to avoid multiple evaluation of its
   parameters.
 * Change to an array typedef for constness reasons
---
 tools/include/xen-tools/libs.h|  4 ++
 tools/xenstore/xenstored_core.h   |  2 -
 xen/common/libx86/cpuid.c | 90 +++
 xen/common/libx86/private.h   | 18 
 xen/include/public/arch-x86/xen.h | 11 +
 xen/include/xen/libx86/cpuid.h| 30 +
 6 files changed, 153 insertions(+), 2 deletions(-)

diff --git a/tools/include/xen-tools/libs.h b/tools/include/xen-tools/libs.h
index f78a3b5..927e057 100644
--- a/tools/include/xen-tools/libs.h
+++ b/tools/include/xen-tools/libs.h
@@ -17,4 +17,8 @@
 #define MAX(x, y) ((x) > (y) ? (x) : (y))
 #endif
 
+#ifndef MIN
+#define MIN(x, y) ((x) < (y) ? (x) : (y))
+#endif
+
 #endif /* __XEN_TOOLS_LIBS__ */
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index 3d7eb91..3d27feb 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -37,8 +37,6 @@
 /* DEFAULT_BUFFER_SIZE should be large enough for each errno string. */
 #define DEFAULT_BUFFER_SIZE 16
 
-#define MIN(a, b) (((a) < (b))? (a) : (b))
-
 typedef int32_t wrl_creditt;
 #define WRL_CREDIT_MAX (1000*1000*1000)
 /* ^ satisfies non-overflow condition for wrl_xfer_credit */
diff --git a/xen/common/libx86/cpuid.c b/xen/common/libx86/cpuid.c
index 0f497d4..cf7dbd3 100644
--- a/xen/common/libx86/cpuid.c
+++ b/xen/common/libx86/cpuid.c
@@ -34,6 +34,96 @@ const uint32_t *x86_cpuid_lookup_deep_deps(uint32_t feature)
 }
 
 /*
+ * Copy a single cpuid_leaf into a provided xen_cpuid_leaf_t buffer,
+ * performing boundary checking against the buffer size.
+ */
+static int copy_leaf_to_buffer(uint32_t leaf, uint32_t subleaf,
+   const struct cpuid_leaf *data,
+   cpuid_leaf_buffer_t leaves,
+   uint32_t *curr_entry, const uint32_t nr_entries)
+{
+const xen_cpuid_leaf_t val = {
+leaf, subleaf, data->a, data->b, data->c, data->d,
+};
+
+if ( *curr_entry == nr_entries )
+return -ENOBUFS;
+
+if ( copy_to_buffer_offset(leaves, *curr_entry, , 1) )
+return -EFAULT;
+
+++*curr_entry;
+
+return 0;
+}
+
+int x86_cpuid_copy_to_buffer(const struct cpuid_policy *p,
+ cpuid_leaf_buffer_t leaves,
+ uint32_t *nr_entries_p)
+{
+const uint32_t nr_entries = *nr_entries_p;
+uint32_t curr_entry = 0, leaf, subleaf;
+
+#define COPY_LEAF(l, s, data)   \
+({  int ret;\
+if ( (ret = copy_leaf_to_buffer(\
+  l, s, data, leaves, _entry, nr_entries)) )   \
+return ret; \
+})
+
+/* Basic leaves. */
+for ( leaf = 0; leaf <= MIN(p->basic.max_leaf,
+ARRAY_SIZE(p->basic.raw) - 1); ++leaf )
+{
+switch ( leaf )
+{
+case 0x4:
+for ( subleaf = 0; subleaf < ARRAY_SIZE(p->cache.raw); ++subleaf )
+COPY_LEAF(leaf, subleaf, >cache.raw[subleaf]);
+break;
+
+case 0x7:
+for ( subleaf = 0;
+  subleaf <= MIN(p->feat.max_subleaf,
+ ARRAY_SIZE(p->feat.raw) - 1); ++subleaf )
+COPY_LEAF(leaf, subleaf, >feat.raw[subleaf]);
+break;
+
+case 0xb:
+for ( subleaf = 0; subleaf < ARRAY_SIZE(p->topo.raw); ++subleaf )
+COPY_LEAF(leaf, subleaf, >topo.raw[subleaf]);
+break;
+
+case 0xd:
+for ( subleaf = 0; subleaf < ARRAY_SIZE(p->xstate.raw); ++subleaf )
+COPY_LEAF(leaf, subleaf, >xstate.raw[subleaf]);
+break;
+
+default:
+COPY_LEAF(leaf, XEN_CPUID_NO_SUBLEAF, >basic.raw[leaf]);
+break;
+}
+}
+
+/* TODO: Port Xen and Viridian 

[Xen-devel] xpti=dom0=false doesn't seem to work on 4.8.4

[Karl Johnson]

Hello,

I'm currently testing last Xen 4.8.4 build for CentOS
(http://cbs.centos.org/koji/buildinfo?buildID=23169) and disabling
XPTI for dom0 doesn't seem to work:

(XEN) Command line: dom0_mem=1792M,max:2048M dom0_max_vcpus=4 cpuinfo
com1=115200,8n1 console=com1,vga xpti=dom0=false loglvl=all
guest_loglvl=all crashkernel=512M@64M

(XEN)   XPTI (64-bit PV only): Dom0 enabled, DomU enabled

Bug or wrong syntax?

Karl

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

[Xen-devel] [linux-4.9 test] 125096: regressions - FAIL

[osstest service owner]

flight 125096 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125096/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  7 xen-bootfail REGR. vs. 122969
 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-libvirt-xsm  7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-xl-shadow7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-xl-pvshim7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-xl-xsm   7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-xl-qemut-ws16-amd64  7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-xl   7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-xl-qemuu-win10-i386  7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 
122969
 test-amd64-amd64-xl-qemut-win7-amd64  7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-qemuu-nested-intel  7 xen-boot  fail REGR. vs. 122969
 test-amd64-amd64-xl-pvhv2-intel  7 xen-boot  fail REGR. vs. 122969
 test-amd64-amd64-libvirt  7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-xl-qemut-debianhvm-amd64  7 xen-bootfail REGR. vs. 122969
 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 122969
 test-amd64-amd64-xl-qemut-win10-i386  7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 122969
 test-amd64-amd64-pygrub   7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-libvirt-vhd  7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host   fail REGR. vs. 122969
 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host   fail REGR. vs. 122969
 test-amd64-amd64-i386-pvgrub  7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-xl-credit2   7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-amd64-pvgrub  7 xen-bootfail REGR. vs. 122969
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. 
vs. 122969
 test-amd64-amd64-xl-qemuu-ws16-amd64  7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
122969
 test-amd64-amd64-xl-qemuu-win7-amd64  7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-xl-multivcpu  7 xen-bootfail REGR. vs. 122969
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-rumprun-amd64  7 xen-boot   fail REGR. vs. 122969
 test-amd64-amd64-examine  8 reboot   fail REGR. vs. 122969
 build-i386-libvirt6 libvirt-buildfail REGR. vs. 122969

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  7 xen-boot fail REGR. vs. 122969

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 122969
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122969
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail never 
pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2 

[Xen-devel] [xen-unstable-smoke test] 125155: tolerable all pass - PUSHED

[osstest service owner]

flight 125155 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125155/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  e3f667bc5f51d0aa44357a64ca134cd952679c81
baseline version:
 xen  c66d9982ebf0247cc8edb355f5adb4e993d431c2

Last test of basis   125153  2018-07-13 11:00:36 Z0 days
Testing same since   125155  2018-07-13 14:00:54 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Roger Pau Monne 
  Roger Pau Monné 
  Wei Liu 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   c66d9982eb..e3f667bc5f  e3f667bc5f51d0aa44357a64ca134cd952679c81 -> smoke

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

[Xen-devel] [PATCH] x86/efi: move the logic to detect PE build support

[Roger Pau Monne]

So that it can be used by other components apart from the efi specific
code.

This is required so that the conditional used to define the efi symbol
in the linker script can be removed and instead the definition of the
efi symbol can be guarded using the preprocessor.

The motivation behind this change is to be able to build Xen using lld
(the LLVM linker), that at least on version 6.0.0 doesn't work
properly with a DEFINED being used in a conditional expression:

ld-melf_x86_64_fbsd  -T xen.lds -N prelink.o --build-id=sha1 \
/root/src/xen/xen/common/symbols-dummy.o -o /root/src/xen/xen/.xen-syms.0
ld: error: xen.lds:233: symbol not found: efi

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Daniel Kiper 
---
 xen/arch/x86/Makefile | 10 ++
 xen/arch/x86/efi/Makefile | 11 +++
 xen/arch/x86/xen.lds.S|  4 +++-
 3 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 5563c813dd..59f96626aa 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -168,6 +168,16 @@ $(TARGET).efi: ALT_BASE = 0x$(shell $(NM) 
efi/relocs-dummy.o | sed -n 's, A ALT_
 # Don't use $(wildcard ...) here - at least make 3.80 expands this too early!
 $(TARGET).efi: guard = $(if $(shell echo efi/dis* | grep disabled),:)
 
+# Check if the build system supports PE.
+efi := y$(shell rm -f efi/disabled)
+efi := $(if $(efi),$(shell $(CC) $(filter-out $(CFLAGS-y) .%.d,$(CFLAGS)) -c 
efi/check.c -o efi/check.o 2>efi/disabled && echo y))
+efi := $(if $(efi),$(shell $(LD) -mi386pep --subsystem=10 -o efi/check.efi 
efi/check.o 2>efi/disabled && echo y))
+efi := $(if $(efi),$(shell rm efi/disabled)y)
+export BUILD_PE := $(efi)
+ifeq ($(efi),y)
+CFLAGS += -DBUILD_PE
+endif
+
 ifneq ($(build_id_linker),)
 ifeq ($(call ld-ver-build-id,$(LD) $(filter -m%,$(EFI_LDFLAGS))),y)
 CFLAGS += -DBUILD_ID_EFI
diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
index 3be9661108..ff5e33fb25 100644
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -1,16 +1,11 @@
 CFLAGS += -fshort-wchar
 
-efi := y$(shell rm -f disabled)
-efi := $(if $(efi),$(shell $(CC) $(filter-out $(CFLAGS-y) .%.d,$(CFLAGS)) -c 
check.c 2>disabled && echo y))
-efi := $(if $(efi),$(shell $(LD) -mi386pep --subsystem=10 -o check.efi check.o 
2>disabled && echo y))
-efi := $(if $(efi),$(shell rm disabled)y)
-
 %.o: %.ihex
$(OBJCOPY) -I ihex -O binary $< $@
 
 boot.init.o: buildid.o
 
 obj-y := stub.o
-obj-$(efi) := boot.init.o compat.o relocs-dummy.o runtime.o
-extra-$(efi) += buildid.o
-nocov-$(efi) += stub.o
+obj-$(BUILD_PE) := boot.init.o compat.o relocs-dummy.o runtime.o
+extra-$(BUILD_PE) += buildid.o
+nocov-$(BUILD_PE) += stub.o
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 326e885402..f93d5d7e16 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -304,7 +304,9 @@ SECTIONS
   } :text
 #endif
 
-  efi = DEFINED(efi) ? efi : .;
+#ifndef BUILD_PE
+  efi = .;
+#endif
 
   /* Sections to be discarded */
   /DISCARD/ : {
-- 
2.17.1


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

[Xen-devel] [ovmf baseline-only test] 74967: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 74967 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74967/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf ae08ea246fe9b4a4e05b7ee6cdbd5b0fa38f3f69
baseline version:
 ovmf 280f49b81170aee9176a47085b168ff3bc9fd3e7

Last test of basis74966  2018-07-13 10:22:34 Z0 days
Testing same since74967  2018-07-13 12:49:38 Z0 days1 attempts


People who touched revisions under test:
  Laszlo Ersek 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



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.


commit ae08ea246fe9b4a4e05b7ee6cdbd5b0fa38f3f69
Author: Laszlo Ersek 
Date:   Fri Jul 13 01:41:12 2018 +0200

ArmVirtPkg/ArmVirtQemu: enable the IPv6 stack

Add the IPv6 stack to ArmVirtQemu with a cumulative port of the following
OvmfPkg commits:

* 36c6413f76e5 "OvmfPkg: enable the IPv6 support", 2014-12-19

* 96302b80d90e "OvmfPkg: Enable Network2 Shell Commands for IPv6",
   2016-03-08

* 6d0f8941bdc2 "OvmfPkg: always resolve OpenSslLib, IntrinsicLib and
   BaseCryptLib", 2017-01-17

* 32e22f20c985 "OvmfPkg: correct the IScsiDxe module included for the IPv6
   stack", 2017-01-17

The IPv6-enabled IScsiDxe driver depends on BaseCryptLib, and the
"CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf" instance depends on
IntrinsicLib and OpensslLib. This is why commit 6d0f8941bdc2 is relevant.

However, unlike in OvmfPkg, in ArmVirtPkg we'll precisely track the
firmware features that require these library classes. (The OvmfPkg
discussion was quite complex, and the OvmfPkg solution was a compromise:

.)

The ArmVirtXen platform is not extended with the relevant drivers because
currently it doesn't include any networking support.

Cc: Julien Grall 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1007
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
Reviewed-by: Ard Biesheuvel 

commit 77b702bfa4947caaa6b4b04730820d91bdf07b03
Author: Laszlo Ersek 
Date:   Fri Jul 13 01:41:11 2018 +0200

ArmVirtPkg: unify HttpLib resolutions in "ArmVirt.dsc.inc"

We already resolve a number of networking-related library classes in
ArmVirt.dsc.inc; follow suit with HttpLib.

Cc: Julien Grall 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1007
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
Reviewed-by: Ard Biesheuvel 

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

[Xen-devel] [xen-unstable-smoke test] 125153: tolerable all pass - PUSHED

[osstest service owner]

flight 125153 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125153/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  c66d9982ebf0247cc8edb355f5adb4e993d431c2
baseline version:
 xen  c6dd998ec8866fafd8f1cb4ff73c52e1c21f2a00

Last test of basis   125149  2018-07-13 08:00:25 Z0 days
Testing same since   125153  2018-07-13 11:00:36 Z0 days1 attempts


People who touched revisions under test:
  Wei Liu 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   c6dd998ec8..c66d9982eb  c66d9982ebf0247cc8edb355f5adb4e993d431c2 -> smoke

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

Re: [Xen-devel] [PATCH 00/16] x86: indirect call overhead reduction

[Julien Grall]

Hi,

On 13/07/18 14:27, Jan Beulich wrote:

On 13.07.18 at 15:00,  wrote:

Hi Jan,

On 13/07/18 09:10, Jan Beulich wrote:

On 11.07.18 at 15:15,  wrote:

While indirect calls have always been more expensive than direct ones,
their cost has further increased with the Spectre v2 mitigations. In a
number of cases we simply pointlessly use them in the first place. In
many other cases the indirection solely exists to abstract from e.g.
vendor specific hardware details, and hence the pointers used never
change once set. Here we can use alternatives patching to get rid of
the indirection.

  From patch 8 onwards dependencies exist on earlier, yet to be reviewed
patches ("x86/alternatives: fully leverage automatic NOP filling" as well
as the "x86: improve PDX <-> PFN and alike translations" series at the
very least). I nevertheless wanted to enable a first round of review of
the series, the more that some of the patches (not just initial ones)
could perhaps be taken irrespective of those dependencies.

Further areas where indirect calls could be eliminated (and that I've put
on my todo list in case the general concept here is deemed reasonable)
are IOMMU, cpufreq, vPMU, and XSM. For some of these, the ARM side
would need dealing with as well - I'm not sure whether replacing indirect
calls by direct ones is worthwhile there as well; if not, the wrappers
would simply need to become function invocations in the ARM case.


Btw, I didn't want to Cc you on the whole series, but input on the above
would certainly be helpful to decide how to deal with indirect calls in code
shared between the architectures.


For the IOMMU, we want to keep the indirect call as it might be possible
to have a platform support different IOMMUs (not yet supported in Xen).

For CPUFreq and vPMU, they are not yet supported on Arm and I haven't
spent much time looking at them. So I can't confirm whether indirect
call could be dropped.

For XSM, I guess indirect call could be dropped.


But you didn't answer the fundamental question: Is this worthwhile on
ARM?
I can't tell, that will depend on the implementation. Although such 
changes should not hurt.





What would be the generic interface here? I saw it was based on
alternative for the plumbing.


Yes, I'd prefer to use the same mechanism as presented in the series.
As per above for the IOMMU case we'd then need another abstraction
layer put in the middle (to produce a patch site on x86, but a normal
[indirect] call on ARM).


I will have a look. Could you point to the patch adding the abstraction?

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v11 07/11] x86/hvm: Introduce viridian_save_vcpu_ctxt_one() func

[Alexandru Stefan ISAILA]

On Vi, 2018-07-13 at 05:53 -0600, Jan Beulich wrote:
> > 
> > > 
> > > > 
> > > > On 13.07.18 at 13:14,  wrote:
> > On Vi, 2018-07-13 at 04:34 -0600, Jan Beulich wrote:
> > > 
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > On 13.07.18 at 11:04,  wrote:
> > > > --- a/xen/arch/x86/hvm/viridian.c
> > > > +++ b/xen/arch/x86/hvm/viridian.c
> > > > @@ -1026,20 +1026,26 @@ static int
> > > > viridian_load_domain_ctxt(struct
> > > > domain *d, hvm_domain_context_t *h)
> > > >  HVM_REGISTER_SAVE_RESTORE(VIRIDIAN_DOMAIN,
> > > > viridian_save_domain_ctxt,
> > > >    viridian_load_domain_ctxt, 1,
> > > > HVMSR_PER_DOM);
> > > >  
> > > > -static int viridian_save_vcpu_ctxt(struct domain *d,
> > > > hvm_domain_context_t *h)
> > > > +static int viridian_save_vcpu_ctxt_one(struct vcpu *v,
> > > > hvm_domain_context_t *h)
> > > >  {
> > > > -struct vcpu *v;
> > > > +struct hvm_viridian_vcpu_context ctxt;
> > > >  
> > > > -if ( !is_viridian_domain(d) )
> > > > +if ( !is_viridian_domain(v->domain) )
> > > >  return 0;
> > > >  
> > > > -for_each_vcpu( d, v ) {
> > > > -struct hvm_viridian_vcpu_context ctxt = {
> > > > -.vp_assist_msr = v-
> > > > > 
> > > > > arch.hvm_vcpu.viridian.vp_assist.msr.raw,
> > > > -.vp_assist_pending = v-
> > > > > 
> > > > > arch.hvm_vcpu.viridian.vp_assist.pending,
> > > > -};
> > > > +memset(, 0, sizeof(ctxt));
> > > > +ctxt.vp_assist_msr = v-
> > > > > 
> > > > > arch.hvm_vcpu.viridian.vp_assist.msr.raw;
> > > > +ctxt.vp_assist_pending = v-
> > > > > 
> > > > > arch.hvm_vcpu.viridian.vp_assist.pending;
> > > >  
> > > > -if ( hvm_save_entry(VIRIDIAN_VCPU, v->vcpu_id, h,
> > > > )
> > > > != 0 )
> > > > +return hvm_save_entry(VIRIDIAN_VCPU, v->vcpu_id, h,
> > > > );
> > > So you now hand on the return value here, but just to ...
> > > 
> > > > 
> > > > 
> > > > +}
> > > > +
> > > > +static int viridian_save_vcpu_ctxt(struct domain *d,
> > > > hvm_domain_context_t *h)
> > > > +{
> > > > +struct vcpu *v;
> > > > +
> > > > +for_each_vcpu( d, v ) {
> > > > +if ( viridian_save_vcpu_ctxt_one(v, h) != 0 )
> > > >  return 1;
> > > ... not pass it on here. Is that really what we want? The vMCE
> > > case
> > > does
> > > it differently, for example. Which means - there are certainly
> > > inconsistencies right now, but since you have to touch all of
> > > this
> > > anyway,
> > > couldn't you make things end in a more consistent shape after
> > > this
> > > rework?
> > In the past there where either returning the value
> > from hvm_save_entry()(like in the hvm_save_tsc_adjust) or check the
> > return value(like in the hvm_save_cpu_ctxt ) like it did here. I
> > made
> > all the save_one funcs return the value from  hvm_save_entry() and
> > then
> > check it in the save func so that they all return in the same way.
> > 
> > I don't say that the old way was bad but it was not consistent.
> > 
> > And yes I have missed the if() check int he save func in the vmce
> > but I
> > think it's better to have the check in place there and have all the
> > save / save_one funcs consistent.
> Consistent - yes. But not the wrong way. It is almost never correct
> to convert one error indicator into another (one exception is errno-
> style error codes vs boolean). So imo it is this patch, not the vMCE
> one which wants to change.

I agree with you on the converting the error codes and I will have the
save funcs return the return value form the save_one funcs but further
down the series the return value is converted into return enum to cover
the CONTINUE value. What is the best way to handle this because we will
be back at version 8 if I drop it. 

Thanks, 
Alex
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 00/16] x86: indirect call overhead reduction

[Jan Beulich]

>>> On 13.07.18 at 15:00,  wrote:
> Hi Jan,
> 
> On 13/07/18 09:10, Jan Beulich wrote:
> On 11.07.18 at 15:15,  wrote:
>>> While indirect calls have always been more expensive than direct ones,
>>> their cost has further increased with the Spectre v2 mitigations. In a
>>> number of cases we simply pointlessly use them in the first place. In
>>> many other cases the indirection solely exists to abstract from e.g.
>>> vendor specific hardware details, and hence the pointers used never
>>> change once set. Here we can use alternatives patching to get rid of
>>> the indirection.
>>>
>>>  From patch 8 onwards dependencies exist on earlier, yet to be reviewed
>>> patches ("x86/alternatives: fully leverage automatic NOP filling" as well
>>> as the "x86: improve PDX <-> PFN and alike translations" series at the
>>> very least). I nevertheless wanted to enable a first round of review of
>>> the series, the more that some of the patches (not just initial ones)
>>> could perhaps be taken irrespective of those dependencies.
>>>
>>> Further areas where indirect calls could be eliminated (and that I've put
>>> on my todo list in case the general concept here is deemed reasonable)
>>> are IOMMU, cpufreq, vPMU, and XSM. For some of these, the ARM side
>>> would need dealing with as well - I'm not sure whether replacing indirect
>>> calls by direct ones is worthwhile there as well; if not, the wrappers
>>> would simply need to become function invocations in the ARM case.
>> 
>> Btw, I didn't want to Cc you on the whole series, but input on the above
>> would certainly be helpful to decide how to deal with indirect calls in code
>> shared between the architectures.
> 
> For the IOMMU, we want to keep the indirect call as it might be possible 
> to have a platform support different IOMMUs (not yet supported in Xen).
> 
> For CPUFreq and vPMU, they are not yet supported on Arm and I haven't 
> spent much time looking at them. So I can't confirm whether indirect 
> call could be dropped.
> 
> For XSM, I guess indirect call could be dropped.

But you didn't answer the fundamental question: Is this worthwhile on
ARM?

> What would be the generic interface here? I saw it was based on 
> alternative for the plumbing.

Yes, I'd prefer to use the same mechanism as presented in the series.
As per above for the IOMMU case we'd then need another abstraction
layer put in the middle (to produce a patch site on x86, but a normal
[indirect] call on ARM).

Jan



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

Re: [Xen-devel] [PATCH 05/16] x86/HVM: add wrapper for hvm_funcs.set_tsc_offset()

[Jan Beulich]

>>> On 13.07.18 at 14:19,  wrote:
> On 11/07/18 14:26, Jan Beulich wrote:
>> It's used in quite a few places, and hence doing so eases subsequent
>> adjustment to how these (indirect) calls are carried out.
>>
>> Signed-off-by: Jan Beulich 
> 
> Reviewed-by: Andrew Cooper 

Thanks.

> Overall, I'd say that it would be good to have wrappers for all the
> functions, to make a cleaner API.

I had considered that, but decided that I'd leave the ones having just
a single use site.

Jan



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

Re: [Xen-devel] [PATCH 10/16] x86/HVM: patch indirect calls through hvm_funcs to direct ones

[Jan Beulich]

>>> On 13.07.18 at 12:06,  wrote:
>>  -Original Message-
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
>> Of Jan Beulich
>> Sent: 11 July 2018 14:43
>> To: xen-devel 
>> Cc: Andrew Cooper 
>> Subject: [Xen-devel] [PATCH 10/16] x86/HVM: patch indirect calls through
>> hvm_funcs to direct ones
>> 
>> This is intentionally not touching hooks used rarely (or not at all)
>> during the lifetime of a VM, like {domain,vcpu}_initialise or cpu_up,
>> as well as nested, VM event, and altp2m ones (they can all be done
>> later, if so desired). Virtual Interrupt delivery ones will be dealt
>> with in a subsequent patch.
>> 
>> Signed-off-by: Jan Beulich 
>> ---
>> Needless to say that I'm pretty unhappy about the workaround I had to
>> add to hvm_set_rdtsc_exiting(). Improvement suggestions welcome.
> 
> Presumably the workaround is needed because of the ?: in ALT_CALL_ARG() and 
> will occur for any bool argument to an alternatives patched call?

Yes.

> If so, and 
> ad hoc workaround seems undesirable. Is it possible to suppress it by 
> dropping the gcc-ism from the ternary operator?

Hmm, yes, that looks to work. Makes the code slightly more ugly,
though. And I dislike this because of the warning being pointless
when such an expression occurs in sizeof(), alignof(), or typeof()
(i.e. when the expression isn't really evaluated). But perhaps
that's less ugly than the current warning suppression.

Jan



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

Re: [Xen-devel] [PATCH v2] tools: remove local links to the x86 headers

[Jan Beulich]

>>> On 13.07.18 at 13:37,  wrote:
> On Fri, Jul 13, 2018 at 04:04:56AM -0600, Jan Beulich wrote:
>> >>> On 13.07.18 at 09:55,  wrote:
>> > On Fri, Jul 13, 2018 at 01:49:37AM -0600, Jan Beulich wrote:
>> >> >>> On 12.07.18 at 18:48,  wrote:
>> >> > In the x86 test harness and the fuzzer, and instead create a link in
>> >> > the tools/include directory that can be used by all the tools.
>> >> > 
>> >> > No functional change.
>> >> > 
>> >> > Signed-off-by: Roger Pau Monné 
>> >> > ---
>> >> > Cc: Jan Beulich 
>> >> > Cc: Andrew Cooper 
>> >> > Cc: Ian Jackson 
>> >> > Cc: Wei Liu 
>> >> > ---
>> >> > Changes since v1:
>> >> >  - Don't remove the header dependencies in the makefile for the x86
>> >> >emulator test harness.
>> >> 
>> >> Hmm, afaics you've done the same for the fuzzer where afaict it's
>> >> unnecessary. Any specific reason?
>> > 
>> > The fuzzer also includes x86-emulate.h which depends on those headers,
>> > so it should also be rebuilt.
>> 
>> See my original mail - afaict the fuzzer makes use of .*.d files, so
>> explicit recodring of dependencies should not be needed.
> 
> I'm afraid that doesn't seem to work. If I modify any of the headers
> without the explicit makefile tracking a rebuild is not triggered.

Well, I don't understand this, but for the patch here
Acked-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH 00/16] x86: indirect call overhead reduction

[Julien Grall]

Hi Jan,

On 13/07/18 09:10, Jan Beulich wrote:

On 11.07.18 at 15:15,  wrote:

While indirect calls have always been more expensive than direct ones,
their cost has further increased with the Spectre v2 mitigations. In a
number of cases we simply pointlessly use them in the first place. In
many other cases the indirection solely exists to abstract from e.g.
vendor specific hardware details, and hence the pointers used never
change once set. Here we can use alternatives patching to get rid of
the indirection.

 From patch 8 onwards dependencies exist on earlier, yet to be reviewed
patches ("x86/alternatives: fully leverage automatic NOP filling" as well
as the "x86: improve PDX <-> PFN and alike translations" series at the
very least). I nevertheless wanted to enable a first round of review of
the series, the more that some of the patches (not just initial ones)
could perhaps be taken irrespective of those dependencies.

Further areas where indirect calls could be eliminated (and that I've put
on my todo list in case the general concept here is deemed reasonable)
are IOMMU, cpufreq, vPMU, and XSM. For some of these, the ARM side
would need dealing with as well - I'm not sure whether replacing indirect
calls by direct ones is worthwhile there as well; if not, the wrappers
would simply need to become function invocations in the ARM case.


Btw, I didn't want to Cc you on the whole series, but input on the above
would certainly be helpful to decide how to deal with indirect calls in code
shared between the architectures.


For the IOMMU, we want to keep the indirect call as it might be possible 
to have a platform support different IOMMUs (not yet supported in Xen).


For CPUFreq and vPMU, they are not yet supported on Arm and I haven't 
spent much time looking at them. So I can't confirm whether indirect 
call could be dropped.


For XSM, I guess indirect call could be dropped.

What would be the generic interface here? I saw it was based on 
alternative for the plumbing.


Cheers,

--
Julien Grall

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

[Xen-devel] [libvirt test] 125086: regressions - FAIL

[osstest service owner]

flight 125086 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125086/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-libvirt   6 libvirt-buildfail REGR. vs. 123814
 build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814
 build-amd64-libvirt   6 libvirt-buildfail REGR. vs. 123814
 build-armhf-libvirt   6 libvirt-buildfail REGR. vs. 123814

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a

version targeted for testing:
 libvirt  fac0dacd54c02b842c995d0999d9450d09d1e7cd
baseline version:
 libvirt  076a2b409667dd9f716a2a2085e1ffea9d58fe8b

Last test of basis   123814  2018-06-05 04:19:23 Z   38 days
Failing since123840  2018-06-06 04:19:28 Z   37 days   28 attempts
Testing same since   125086  2018-07-10 23:54:54 Z2 days1 attempts


People who touched revisions under test:
Andrea Bolognani 
  Anya Harter 
  Bjoern Walk 
  Bobo Du 
  Boris Fiuczynski 
  Brijesh Singh 
  Chen Hanxiao 
  Christian Ehrhardt 
  Cole Robinson 
  Daniel Nicoletti 
  Daniel P. Berrangé 
  Daniel Veillard 
  Eric Blake 
  Erik Skultety 
  Fabiano Fidêncio 
  Filip Alac 
  Han Han 
  intrigeri 
  intrigeri 
  Jamie Strandboge 
  Jie Wang 
  Jiri Denemark 
  John Ferlan 
  Julio Faracco 
  Ján Tomko 
  Kashyap Chamarthy 
  Katerina Koukiou 
  Laine Stump 
  Laszlo Ersek 
  Luyao Huang 
  Marc Hartmayer 
  Marcos Paulo de Souza 
  Martin Kletzander 
  Michal Privoznik 
  Michal Prívozník 
  Pavel Hrdina 
  Peter Krempa 
  Pino Toscano 
  Radostin Stoyanov 
  Ramy Elkest 
  ramyelkest 
  Richard W.M. Jones 
  Roman Bogorodskiy 
  Stefan Bader 
  Stefan Berger 
  w00251574 
  Weilun Zhu 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-arm64-libvirt  fail
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-amd64-libvirt-xsm blocked 
 test-arm64-arm64-libvirt-xsm blocked 
 test-armhf-armhf-libvirt-xsm blocked 
 test-amd64-i386-libvirt-xsm  blocked 
 test-amd64-amd64-libvirt blocked 
 test-arm64-arm64-libvirt blocked 
 test-armhf-armhf-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-libvirt-pairblocked 
 test-amd64-i386-libvirt-pair blocked 
 

[Xen-devel] [ovmf baseline-only test] 74966: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 74966 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74966/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 280f49b81170aee9176a47085b168ff3bc9fd3e7
baseline version:
 ovmf 0c6f94dae5e3ca57fe6093ce2fa4d78fdd061857

Last test of basis74965  2018-07-13 06:52:41 Z0 days
Testing same since74966  2018-07-13 10:22:34 Z0 days1 attempts


People who touched revisions under test:
  Jiaxin Wu 
  Wu Jiaxin 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



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.


commit 280f49b81170aee9176a47085b168ff3bc9fd3e7
Author: Jiaxin Wu 
Date:   Thu Apr 26 14:13:57 2018 +0800

ShellPkg/TftpDynamicCommand: Fix the potential assertion and memory leak 
issue.

This patch is to fix the issue reported from
https://bugzilla.tianocore.org/show_bug.cgi?id=925.

DataSize variable was not assigned the value if ShellOpenFileByName returns 
error.
In the such a case, it should not be used to FreePages. Instead, DataSize 
can be
used to record the file size once DownloadFile successfully.

Cc: Ye Ting 
Cc: Fu Siyuan 
Cc: Jaben Carsey 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
Reviewed-by: Fu Siyuan 
Reviewed-by: Jaben Carsey 

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

Re: [Xen-devel] [PATCH 06/16] x86: allow producing .i or .s for multiply compiled files

[Andrew Cooper]

On 11/07/18 14:27, Jan Beulich wrote:
> Since the generic pattern rules don't match those, explicit rules need
> to be put in place for this to work.
>
> Signed-off-by: Jan Beulich 

Acked-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH 05/16] x86/HVM: add wrapper for hvm_funcs.set_tsc_offset()

[Andrew Cooper]

On 11/07/18 14:26, Jan Beulich wrote:
> It's used in quite a few places, and hence doing so eases subsequent
> adjustment to how these (indirect) calls are carried out.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

Overall, I'd say that it would be good to have wrappers for all the
functions, to make a cleaner API.

~Andrew

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

Re: [Xen-devel] [PATCH 03/16] x86/HVM: switch virtual_intr_delivery_enabled() hook to simple boolean

[Andrew Cooper]

On 11/07/18 14:24, Jan Beulich wrote:
> From: Suravee Suthikulpanit 
>
> This patch modifies the hvm_funcs.virtual_intr_delivery_enabled()
> to become a bool variable as VMX does and SVM will simply return a
> static value.
>
> Signed-off-by: Suravee Suthikulpanit 
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH 04/16] x86/HVM: drop vmfunc_intercept

[Andrew Cooper]

On 11/07/18 14:25, Jan Beulich wrote:
> Commit a1b1572833 ("VMX: add VMFUNC leaf 0 (EPTP switching) to
> emulator") needlessly introduced it, and no user has appeared since.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH 01/16] VMX: reduce number of posted-interrupt hooks

[Andrew Cooper]

On 11/07/18 14:23, Jan Beulich wrote:
> Three of the four hooks are not exposed outside of vmx.c, and all of
> them have only a single possible non-NULL value. So there's no reason to
> use hooks here - a simple set of flag indicators is sufficient (and we
> don't even need a flag for the VM entry one, as it's always
> (de-)activated together the the vCPU blocking hook, which needs to
> remain an actual function pointer). This is the more that with the
> Spectre v2 workarounds indirect calls have become more expensive.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH 02/16] VMX: don't unconditionally set the tsc_scaling.setup hook

[Andrew Cooper]

On 11/07/18 14:23, Jan Beulich wrote:
> Instead of checking hvm_tsc_scaling_supported inside the hook function,
> install the hook only when setting state such that said predicate
> becomes true.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v2] tools: remove local links to the x86 headers

[Roger Pau Monné]

On Fri, Jul 13, 2018 at 04:04:56AM -0600, Jan Beulich wrote:
> >>> On 13.07.18 at 09:55,  wrote:
> > On Fri, Jul 13, 2018 at 01:49:37AM -0600, Jan Beulich wrote:
> >> >>> On 12.07.18 at 18:48,  wrote:
> >> > In the x86 test harness and the fuzzer, and instead create a link in
> >> > the tools/include directory that can be used by all the tools.
> >> > 
> >> > No functional change.
> >> > 
> >> > Signed-off-by: Roger Pau Monné 
> >> > ---
> >> > Cc: Jan Beulich 
> >> > Cc: Andrew Cooper 
> >> > Cc: Ian Jackson 
> >> > Cc: Wei Liu 
> >> > ---
> >> > Changes since v1:
> >> >  - Don't remove the header dependencies in the makefile for the x86
> >> >emulator test harness.
> >> 
> >> Hmm, afaics you've done the same for the fuzzer where afaict it's
> >> unnecessary. Any specific reason?
> > 
> > The fuzzer also includes x86-emulate.h which depends on those headers,
> > so it should also be rebuilt.
> 
> See my original mail - afaict the fuzzer makes use of .*.d files, so
> explicit recodring of dependencies should not be needed.

I'm afraid that doesn't seem to work. If I modify any of the headers
without the explicit makefile tracking a rebuild is not triggered.

Roger.

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

Re: [Xen-devel] [PATCH 10/16] x86/HVM: patch indirect calls through hvm_funcs to direct ones

[Paul Durrant]

> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Jan Beulich
> Sent: 11 July 2018 14:43
> To: xen-devel 
> Cc: Andrew Cooper 
> Subject: [Xen-devel] [PATCH 10/16] x86/HVM: patch indirect calls through
> hvm_funcs to direct ones
> 
> This is intentionally not touching hooks used rarely (or not at all)
> during the lifetime of a VM, like {domain,vcpu}_initialise or cpu_up,
> as well as nested, VM event, and altp2m ones (they can all be done
> later, if so desired). Virtual Interrupt delivery ones will be dealt
> with in a subsequent patch.
> 
> Signed-off-by: Jan Beulich 
> ---
> Needless to say that I'm pretty unhappy about the workaround I had to
> add to hvm_set_rdtsc_exiting(). Improvement suggestions welcome.

Presumably the workaround is needed because of the ?: in ALT_CALL_ARG() and 
will occur for any bool argument to an alternatives patched call? If so, and ad 
hoc workaround seems undesirable. Is it possible to suppress it by dropping the 
gcc-ism from the ternary operator?

  Paul

> 
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -2017,7 +2017,7 @@ static int hvmemul_write_msr(
>  static int hvmemul_wbinvd(
>  struct x86_emulate_ctxt *ctxt)
>  {
> -hvm_funcs.wbinvd_intercept();
> +alternative_vcall0(hvm_funcs.wbinvd_intercept);
>  return X86EMUL_OKAY;
>  }
> 
> @@ -2035,7 +2035,7 @@ static int hvmemul_get_fpu(
>  struct vcpu *curr = current;
> 
>  if ( !curr->fpu_dirtied )
> -hvm_funcs.fpu_dirty_intercept();
> +alternative_vcall0(hvm_funcs.fpu_dirty_intercept);
>  else if ( type == X86EMUL_FPU_fpu )
>  {
>  const typeof(curr->arch.xsave_area->fpu_sse) *fpu_ctxt =
> @@ -2152,7 +2152,7 @@ static void hvmemul_put_fpu(
>  {
>  curr->fpu_dirtied = false;
>  stts();
> -hvm_funcs.fpu_leave(curr);
> +alternative_vcall1(hvm_funcs.fpu_leave, curr);
>  }
>  }
>  }
> @@ -2314,7 +2314,8 @@ static int _hvm_emulate_one(struct hvm_e
>  if ( hvmemul_ctxt->intr_shadow != new_intr_shadow )
>  {
>  hvmemul_ctxt->intr_shadow = new_intr_shadow;
> -hvm_funcs.set_interrupt_shadow(curr, new_intr_shadow);
> +alternative_vcall2(hvm_funcs.set_interrupt_shadow,
> +   curr, new_intr_shadow);
>  }
> 
>  if ( hvmemul_ctxt->ctxt.retire.hlt &&
> @@ -2451,7 +2452,8 @@ void hvm_emulate_init_once(
> 
>  memset(hvmemul_ctxt, 0, sizeof(*hvmemul_ctxt));
> 
> -hvmemul_ctxt->intr_shadow = hvm_funcs.get_interrupt_shadow(curr);
> +hvmemul_ctxt->intr_shadow =
> +alternative_call1(hvm_funcs.get_interrupt_shadow, curr);
>  hvmemul_get_seg_reg(x86_seg_cs, hvmemul_ctxt);
>  hvmemul_get_seg_reg(x86_seg_ss, hvmemul_ctxt);
> 
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -271,13 +271,24 @@ void hvm_set_rdtsc_exiting(struct domain
>  {
>  struct vcpu *v;
> 
> +#if __GNUC__ >= 7
> +/*
> + * gcc from 7.x onwards warns about ternary operators with their middle
> operand
> + * omitted and the controlling expression itself being of _Bool type.
> + */
> +# pragma GCC diagnostic push
> +# pragma GCC diagnostic ignored "-Wparentheses"
> +#endif
>  for_each_vcpu ( d, v )
> -hvm_funcs.set_rdtsc_exiting(v, enable);
> +alternative_vcall2(hvm_funcs.set_rdtsc_exiting, v, enable);
> +#if __GNUC__ >= 7
> +# pragma GCC diagnostic pop
> +#endif
>  }
> 
>  void hvm_get_guest_pat(struct vcpu *v, u64 *guest_pat)
>  {
> -if ( !hvm_funcs.get_guest_pat(v, guest_pat) )
> +if ( !alternative_call2(hvm_funcs.get_guest_pat, v, guest_pat) )
>  *guest_pat = v->arch.hvm_vcpu.pat_cr;
>  }
> 
> @@ -302,7 +313,7 @@ int hvm_set_guest_pat(struct vcpu *v, u6
>  return 0;
>  }
> 
> -if ( !hvm_funcs.set_guest_pat(v, guest_pat) )
> +if ( !alternative_call2(hvm_funcs.set_guest_pat, v, guest_pat) )
>  v->arch.hvm_vcpu.pat_cr = guest_pat;
> 
>  return 1;
> @@ -342,7 +353,7 @@ bool hvm_set_guest_bndcfgs(struct vcpu *
>  /* nothing, best effort only */;
>  }
> 
> -return hvm_funcs.set_guest_bndcfgs(v, val);
> +return alternative_call2(hvm_funcs.set_guest_bndcfgs, v, val);
>  }
> 
>  /*
> @@ -502,7 +513,8 @@ void hvm_migrate_pirqs(struct vcpu *v)
>  static bool hvm_get_pending_event(struct vcpu *v, struct x86_event *info)
>  {
>  info->cr2 = v->arch.hvm_vcpu.guest_cr[2];
> -return hvm_funcs.get_pending_event(v, info);
> +
> +return alternative_call2(hvm_funcs.get_pending_event, v, info);
>  }
> 
>  void hvm_do_resume(struct vcpu *v)
> @@ -1684,7 +1696,7 @@ void hvm_inject_event(const struct x86_e
>  }
>  }
> 
> -hvm_funcs.inject_event(event);
> +alternative_vcall1(hvm_funcs.inject_event, event);
>  }
> 
>  int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla,
> @@ -2271,7 +2283,7 @@ int hvm_set_cr0(unsigned long value, boo
> 

[Xen-devel] [ovmf test] 125151: all pass - PUSHED

[osstest service owner]

flight 125151 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125151/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf ae08ea246fe9b4a4e05b7ee6cdbd5b0fa38f3f69
baseline version:
 ovmf 280f49b81170aee9176a47085b168ff3bc9fd3e7

Last test of basis   125147  2018-07-13 06:40:46 Z0 days
Testing same since   125151  2018-07-13 09:40:50 Z0 days1 attempts


People who touched revisions under test:
  Laszlo Ersek 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   280f49b811..ae08ea246f  ae08ea246fe9b4a4e05b7ee6cdbd5b0fa38f3f69 -> 
xen-tested-master

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

Re: [Xen-devel] [PATCH v11 07/11] x86/hvm: Introduce viridian_save_vcpu_ctxt_one() func

[Jan Beulich]

>>> On 13.07.18 at 13:14,  wrote:
> On Vi, 2018-07-13 at 04:34 -0600, Jan Beulich wrote:
>> > 
>> > > 
>> > > > 
>> > > > On 13.07.18 at 11:04,  wrote:
>> > --- a/xen/arch/x86/hvm/viridian.c
>> > +++ b/xen/arch/x86/hvm/viridian.c
>> > @@ -1026,20 +1026,26 @@ static int viridian_load_domain_ctxt(struct
>> > domain *d, hvm_domain_context_t *h)
>> >  HVM_REGISTER_SAVE_RESTORE(VIRIDIAN_DOMAIN,
>> > viridian_save_domain_ctxt,
>> >viridian_load_domain_ctxt, 1,
>> > HVMSR_PER_DOM);
>> >  
>> > -static int viridian_save_vcpu_ctxt(struct domain *d,
>> > hvm_domain_context_t *h)
>> > +static int viridian_save_vcpu_ctxt_one(struct vcpu *v,
>> > hvm_domain_context_t *h)
>> >  {
>> > -struct vcpu *v;
>> > +struct hvm_viridian_vcpu_context ctxt;
>> >  
>> > -if ( !is_viridian_domain(d) )
>> > +if ( !is_viridian_domain(v->domain) )
>> >  return 0;
>> >  
>> > -for_each_vcpu( d, v ) {
>> > -struct hvm_viridian_vcpu_context ctxt = {
>> > -.vp_assist_msr = v-
>> > >arch.hvm_vcpu.viridian.vp_assist.msr.raw,
>> > -.vp_assist_pending = v-
>> > >arch.hvm_vcpu.viridian.vp_assist.pending,
>> > -};
>> > +memset(, 0, sizeof(ctxt));
>> > +ctxt.vp_assist_msr = v-
>> > >arch.hvm_vcpu.viridian.vp_assist.msr.raw;
>> > +ctxt.vp_assist_pending = v-
>> > >arch.hvm_vcpu.viridian.vp_assist.pending;
>> >  
>> > -if ( hvm_save_entry(VIRIDIAN_VCPU, v->vcpu_id, h, )
>> > != 0 )
>> > +return hvm_save_entry(VIRIDIAN_VCPU, v->vcpu_id, h, );
>> So you now hand on the return value here, but just to ...
>> 
>> > 
>> > +}
>> > +
>> > +static int viridian_save_vcpu_ctxt(struct domain *d,
>> > hvm_domain_context_t *h)
>> > +{
>> > +struct vcpu *v;
>> > +
>> > +for_each_vcpu( d, v ) {
>> > +if ( viridian_save_vcpu_ctxt_one(v, h) != 0 )
>> >  return 1;
>> ... not pass it on here. Is that really what we want? The vMCE case
>> does
>> it differently, for example. Which means - there are certainly
>> inconsistencies right now, but since you have to touch all of this
>> anyway,
>> couldn't you make things end in a more consistent shape after this
>> rework?
> 
> In the past there where either returning the value
> from hvm_save_entry()(like in the hvm_save_tsc_adjust) or check the
> return value(like in the hvm_save_cpu_ctxt ) like it did here. I made
> all the save_one funcs return the value from  hvm_save_entry() and then
> check it in the save func so that they all return in the same way.
> 
> I don't say that the old way was bad but it was not consistent.
> 
> And yes I have missed the if() check int he save func in the vmce but I
> think it's better to have the check in place there and have all the
> save / save_one funcs consistent.

Consistent - yes. But not the wrong way. It is almost never correct
to convert one error indicator into another (one exception is errno-
style error codes vs boolean). So imo it is this patch, not the vMCE
one which wants to change.

Jan



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

Re: [Xen-devel] [PATCH v11 01/11] x86/cpu: Introduce vmce_save_vcpu_ctxt_one() func

[Jan Beulich]

>>> On 13.07.18 at 13:19,  wrote:
> On Vi, 2018-07-13 at 04:29 -0600, Jan Beulich wrote:
>> > 
>> > > 
>> > > > 
>> > > > On 13.07.18 at 11:04,  wrote:
>> > Changes since V10:
>> >- Add memset to 0 for ctxt.
>> Why? What's wrong with ...
>> 
>> > 
>> > --- a/xen/arch/x86/cpu/mcheck/vmce.c
>> > +++ b/xen/arch/x86/cpu/mcheck/vmce.c
>> > @@ -349,6 +349,20 @@ int vmce_wrmsr(uint32_t msr, uint64_t val)
>> >  return ret;
>> >  }
>> >  
>> > +static int vmce_save_vcpu_ctxt_one(struct vcpu *v,
>> > hvm_domain_context_t *h)
>> > + {
>> > +struct hvm_vmce_vcpu ctxt;
>> > +
>> > +memset(, 0, sizeof(ctxt));
>> struct hvm_vmce_vcpu ctxt = {};
>> 
>> instead? Or even pulling all of this ...
>> 
>> > 
>> > +ctxt.caps = v->arch.vmce.mcg_cap;
>> > +ctxt.mci_ctl2_bank0 = v->arch.vmce.bank[0].mci_ctl2;
>> > +ctxt.mci_ctl2_bank1 = v->arch.vmce.bank[1].mci_ctl2;
>> > +ctxt.mcg_ext_ctl = v->arch.vmce.mcg_ext_ctl;
>> ... into the initializer, which will make sure padding fields are
>> zero.
>> I can see that a memset() is warranted in _some_ cases, but not
>> uniformly.
> 
> The memset solution was introduced to have consistency with other
> save_one funcs like hvm_save_cpu_ctxt_one(), hvm_save_mtrr_msr_one(),
> and viridian_save_vcpu_ctxt_one(). They all have memset to 0 fot the
> ctxt variables. Should I keep it with memset or change them all to ={}?

This depends on context.

Jan



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

Re: [Xen-devel] [PATCH v11 01/11] x86/cpu: Introduce vmce_save_vcpu_ctxt_one() func

[Alexandru Stefan ISAILA]

On Vi, 2018-07-13 at 04:29 -0600, Jan Beulich wrote:
> > 
> > > 
> > > > 
> > > > On 13.07.18 at 11:04,  wrote:
> > Changes since V10:
> > - Add memset to 0 for ctxt.
> Why? What's wrong with ...
> 
> > 
> > --- a/xen/arch/x86/cpu/mcheck/vmce.c
> > +++ b/xen/arch/x86/cpu/mcheck/vmce.c
> > @@ -349,6 +349,20 @@ int vmce_wrmsr(uint32_t msr, uint64_t val)
> >  return ret;
> >  }
> >  
> > +static int vmce_save_vcpu_ctxt_one(struct vcpu *v,
> > hvm_domain_context_t *h)
> > + {
> > +struct hvm_vmce_vcpu ctxt;
> > +
> > +memset(, 0, sizeof(ctxt));
> struct hvm_vmce_vcpu ctxt = {};
> 
> instead? Or even pulling all of this ...
> 
> > 
> > +ctxt.caps = v->arch.vmce.mcg_cap;
> > +ctxt.mci_ctl2_bank0 = v->arch.vmce.bank[0].mci_ctl2;
> > +ctxt.mci_ctl2_bank1 = v->arch.vmce.bank[1].mci_ctl2;
> > +ctxt.mcg_ext_ctl = v->arch.vmce.mcg_ext_ctl;
> ... into the initializer, which will make sure padding fields are
> zero.
> I can see that a memset() is warranted in _some_ cases, but not
> uniformly.

The memset solution was introduced to have consistency with other
save_one funcs like hvm_save_cpu_ctxt_one(), hvm_save_mtrr_msr_one(),
and viridian_save_vcpu_ctxt_one(). They all have memset to 0 fot the
ctxt variables. Should I keep it with memset or change them all to ={}?

Alex
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v11 07/11] x86/hvm: Introduce viridian_save_vcpu_ctxt_one() func

[Alexandru Stefan ISAILA]

On Vi, 2018-07-13 at 04:34 -0600, Jan Beulich wrote:
> > 
> > > 
> > > > 
> > > > On 13.07.18 at 11:04,  wrote:
> > --- a/xen/arch/x86/hvm/viridian.c
> > +++ b/xen/arch/x86/hvm/viridian.c
> > @@ -1026,20 +1026,26 @@ static int viridian_load_domain_ctxt(struct
> > domain *d, hvm_domain_context_t *h)
> >  HVM_REGISTER_SAVE_RESTORE(VIRIDIAN_DOMAIN,
> > viridian_save_domain_ctxt,
> >    viridian_load_domain_ctxt, 1,
> > HVMSR_PER_DOM);
> >  
> > -static int viridian_save_vcpu_ctxt(struct domain *d,
> > hvm_domain_context_t *h)
> > +static int viridian_save_vcpu_ctxt_one(struct vcpu *v,
> > hvm_domain_context_t *h)
> >  {
> > -struct vcpu *v;
> > +struct hvm_viridian_vcpu_context ctxt;
> >  
> > -if ( !is_viridian_domain(d) )
> > +if ( !is_viridian_domain(v->domain) )
> >  return 0;
> >  
> > -for_each_vcpu( d, v ) {
> > -struct hvm_viridian_vcpu_context ctxt = {
> > -.vp_assist_msr = v-
> > >arch.hvm_vcpu.viridian.vp_assist.msr.raw,
> > -.vp_assist_pending = v-
> > >arch.hvm_vcpu.viridian.vp_assist.pending,
> > -};
> > +memset(, 0, sizeof(ctxt));
> > +ctxt.vp_assist_msr = v-
> > >arch.hvm_vcpu.viridian.vp_assist.msr.raw;
> > +ctxt.vp_assist_pending = v-
> > >arch.hvm_vcpu.viridian.vp_assist.pending;
> >  
> > -if ( hvm_save_entry(VIRIDIAN_VCPU, v->vcpu_id, h, )
> > != 0 )
> > +return hvm_save_entry(VIRIDIAN_VCPU, v->vcpu_id, h, );
> So you now hand on the return value here, but just to ...
> 
> > 
> > +}
> > +
> > +static int viridian_save_vcpu_ctxt(struct domain *d,
> > hvm_domain_context_t *h)
> > +{
> > +struct vcpu *v;
> > +
> > +for_each_vcpu( d, v ) {
> > +if ( viridian_save_vcpu_ctxt_one(v, h) != 0 )
> >  return 1;
> ... not pass it on here. Is that really what we want? The vMCE case
> does
> it differently, for example. Which means - there are certainly
> inconsistencies right now, but since you have to touch all of this
> anyway,
> couldn't you make things end in a more consistent shape after this
> rework?

In the past there where either returning the value
from hvm_save_entry()(like in the hvm_save_tsc_adjust) or check the
return value(like in the hvm_save_cpu_ctxt ) like it did here. I made
all the save_one funcs return the value from  hvm_save_entry() and then
check it in the save func so that they all return in the same way.

I don't say that the old way was bad but it was not consistent.

And yes I have missed the if() check int he save func in the vmce but I
think it's better to have the check in place there and have all the
save / save_one funcs consistent.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v1] tools/firmware: reproducible seabios build

[Olaf Hering]

The buildsystem of seabios always includes the current time and the
hostname into the resulting binary. To avoid that, it is required to
have a file '.version' in the toplevel directory of seabios-dir-remote.
And it is required to pass EXTRAVERSION= to make because its toplevel
Makefile does not take EXTRAVERSION from environment.

Adjust the code to create a '.version' file with fixed content.
Adjust the code to pass EXTRAVERSION down to make.

Signed-off-by: Olaf Hering 
--

After commit 1233d253a4 ("firmware/seabios: fix build on systems with non GNU
toolchains") this change is now hopefully non-controversial.
---
 tools/firmware/Makefile | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile
index 842b48c3d3..b11f1c5970 100644
--- a/tools/firmware/Makefile
+++ b/tools/firmware/Makefile
@@ -30,6 +30,8 @@ seabios-dir:
GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh $(SEABIOS_UPSTREAM_URL) 
$(SEABIOS_UPSTREAM_REVISION) seabios-dir
cp seabios-config seabios-dir/.config;
$(MAKE) -C seabios-dir olddefconfig CC=$(SEABIOSCC) LD=$(SEABIOSLD)
+   rm -f seabios-dir/.version
+   echo '$(SEABIOS_UPSTREAM_REVISION)' > seabios-dir/.version
 
 .PHONY: all
 all: $(SUBDIRS-y)
@@ -130,4 +132,4 @@ subtree-force-update-all:
$(MAKE) ovmf-dir-force-update
 
 subdir-all-seabios-dir: seabios-dir
-   $(MAKE) -C $< CC=$(SEABIOSCC) LD=$(SEABIOSLD) PYTHON=$(PYTHON) all;
+   $(MAKE) -C $< CC=$(SEABIOSCC) LD=$(SEABIOSLD) PYTHON=$(PYTHON) 
EXTRAVERSION="-Xen" all;

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

Re: [Xen-devel] [PATCH v11 07/11] x86/hvm: Introduce viridian_save_vcpu_ctxt_one() func

[Jan Beulich]

>>> On 13.07.18 at 11:04,  wrote:
> --- a/xen/arch/x86/hvm/viridian.c
> +++ b/xen/arch/x86/hvm/viridian.c
> @@ -1026,20 +1026,26 @@ static int viridian_load_domain_ctxt(struct domain 
> *d, hvm_domain_context_t *h)
>  HVM_REGISTER_SAVE_RESTORE(VIRIDIAN_DOMAIN, viridian_save_domain_ctxt,
>viridian_load_domain_ctxt, 1, HVMSR_PER_DOM);
>  
> -static int viridian_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
> +static int viridian_save_vcpu_ctxt_one(struct vcpu *v, hvm_domain_context_t 
> *h)
>  {
> -struct vcpu *v;
> +struct hvm_viridian_vcpu_context ctxt;
>  
> -if ( !is_viridian_domain(d) )
> +if ( !is_viridian_domain(v->domain) )
>  return 0;
>  
> -for_each_vcpu( d, v ) {
> -struct hvm_viridian_vcpu_context ctxt = {
> -.vp_assist_msr = v->arch.hvm_vcpu.viridian.vp_assist.msr.raw,
> -.vp_assist_pending = v->arch.hvm_vcpu.viridian.vp_assist.pending,
> -};
> +memset(, 0, sizeof(ctxt));
> +ctxt.vp_assist_msr = v->arch.hvm_vcpu.viridian.vp_assist.msr.raw;
> +ctxt.vp_assist_pending = v->arch.hvm_vcpu.viridian.vp_assist.pending;
>  
> -if ( hvm_save_entry(VIRIDIAN_VCPU, v->vcpu_id, h, ) != 0 )
> +return hvm_save_entry(VIRIDIAN_VCPU, v->vcpu_id, h, );

So you now hand on the return value here, but just to ...

> +}
> +
> +static int viridian_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
> +{
> +struct vcpu *v;
> +
> +for_each_vcpu( d, v ) {
> +if ( viridian_save_vcpu_ctxt_one(v, h) != 0 )
>  return 1;

... not pass it on here. Is that really what we want? The vMCE case does
it differently, for example. Which means - there are certainly
inconsistencies right now, but since you have to touch all of this anyway,
couldn't you make things end in a more consistent shape after this rework?

Jan



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

Re: [Xen-devel] [PATCH v11 01/11] x86/cpu: Introduce vmce_save_vcpu_ctxt_one() func

[Jan Beulich]

>>> On 13.07.18 at 11:04,  wrote:
> Changes since V10:
>   - Add memset to 0 for ctxt.

Why? What's wrong with ...

> --- a/xen/arch/x86/cpu/mcheck/vmce.c
> +++ b/xen/arch/x86/cpu/mcheck/vmce.c
> @@ -349,6 +349,20 @@ int vmce_wrmsr(uint32_t msr, uint64_t val)
>  return ret;
>  }
>  
> +static int vmce_save_vcpu_ctxt_one(struct vcpu *v, hvm_domain_context_t *h)
> + {
> +struct hvm_vmce_vcpu ctxt;
> +
> +memset(, 0, sizeof(ctxt));

struct hvm_vmce_vcpu ctxt = {};

instead? Or even pulling all of this ...

> +ctxt.caps = v->arch.vmce.mcg_cap;
> +ctxt.mci_ctl2_bank0 = v->arch.vmce.bank[0].mci_ctl2;
> +ctxt.mci_ctl2_bank1 = v->arch.vmce.bank[1].mci_ctl2;
> +ctxt.mcg_ext_ctl = v->arch.vmce.mcg_ext_ctl;

... into the initializer, which will make sure padding fields are zero.
I can see that a memset() is warranted in _some_ cases, but not
uniformly.

Jan



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

Re: [Xen-devel] [PATCH v3 3/3] xen/x86: declare the efi symbol as weak

[Daniel Kiper]

On Thu, Jul 12, 2018 at 06:37:33PM +0200, Roger Pau Monné wrote:
> On Thu, Jul 12, 2018 at 01:35:14PM +0200, Daniel Kiper wrote:
> > On Wed, Jul 11, 2018 at 05:34:50PM +0200, Roger Pau Monne wrote:
> > > This allows removing the DEFINED conditional in the linker script, and
> > > fixes compilation with lld:
> >
> > s/lld/LLVM linker/?
> >
> > Could you mention the version of LLVM linker in the commit message?
> > And I am still not sure why do you insist on this patch series.
> > IIRC you have told us that both issues will be fixed in LLVM.
>
> Right, but I have no idea when lld 7.0.0 will be released, much less
> when it will be merged into FreeBSD base system.

Please add something like that to the commit messages of both patches.

Daniel

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

[Xen-devel] [xen-unstable-smoke test] 125149: tolerable all pass - PUSHED

[osstest service owner]

flight 125149 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125149/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  c6dd998ec8866fafd8f1cb4ff73c52e1c21f2a00
baseline version:
 xen  41cb2db62627a7438d938aae487550c3f4acb1da

Last test of basis   125142  2018-07-12 20:00:33 Z0 days
Testing same since   125149  2018-07-13 08:00:25 Z0 days1 attempts


People who touched revisions under test:
  Doug Goldstein 
  Wei Liu 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   41cb2db626..c6dd998ec8  c6dd998ec8866fafd8f1cb4ff73c52e1c21f2a00 -> smoke

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

Re: [Xen-devel] [PATCH v3 1/3] xen/x86: replace '||' usage in the linker script

[Daniel Kiper]

On Thu, Jul 12, 2018 at 05:26:49PM +0200, Roger Pau Monné wrote:
> On Thu, Jul 12, 2018 at 01:38:21PM +0200, Daniel Kiper wrote:
> > On Wed, Jul 11, 2018 at 05:34:48PM +0200, Roger Pau Monne wrote:
> > > With '|'. The result is the same, and the later works with lld. Fixes
> > > the following error when building Xen with lld:
> > >
> > > ld-melf_x86_64_fbsd  -T xen.lds -N prelink.o --build-id=sha1 \
> > > /root/src/xen/xen/common/symbols-dummy.o -o 
> > > /root/src/xen/xen/.xen-syms.0
> > > ld: error: xen.lds:260: malformed number: |
> > > >>> ASSERT(__image_base__ > (261 >> 8) * 0x) | 
> > > >>> (261 << 39))) + ((1 << 39) / 2)) + (64 << 30)) + (1 << 30)) + (1 << 
> > > >>> 30))) ||
> > > >>>   
> > > >>>   
> > > >>>   ^
> > >
> > > Signed-off-by: Roger Pau Monné 
> > > ---
> > > Cc: Jan Beulich 
> > > Cc: Andrew Cooper 
> > > Cc: Daniel Kiper 
> > > ---
> > >  xen/arch/x86/xen.lds.S | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
> > > index 70afedd31d..326e885402 100644
> > > --- a/xen/arch/x86/xen.lds.S
> > > +++ b/xen/arch/x86/xen.lds.S
> > > @@ -331,7 +331,7 @@ SECTIONS
> > >.comment 0 : { *(.comment) }
> > >  }
> > >
> > > -ASSERT(__image_base__ > XEN_VIRT_START ||
> > > +ASSERT(__image_base__ > XEN_VIRT_START |
> > > __2M_rwdata_end <= XEN_VIRT_END - NR_CPUS * PAGE_SIZE,
> > > "Xen image overlaps stubs area")
> >
> > I am not happy with this change. Is the same needed for any "&&"?
>
> I haven't tried, but I assume both '||' and '&&' would be equally
> broken. There's no '&&' ATM anyway.
>
> > Anyway, if maintainers are OK with that I will just ask you to put
> > the comment before the ASSERT() why you use "|" instead of "||".
>
> OK, I can add something like:
>
> "lld (LLVM linker) version 6.0.0 doesn't support '||', so use '|'
> instead."

I am OK with that.

Daniel

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

Re: [Xen-devel] [PATCH v2] tools: remove local links to the x86 headers

[Jan Beulich]

>>> On 13.07.18 at 09:55,  wrote:
> On Fri, Jul 13, 2018 at 01:49:37AM -0600, Jan Beulich wrote:
>> >>> On 12.07.18 at 18:48,  wrote:
>> > In the x86 test harness and the fuzzer, and instead create a link in
>> > the tools/include directory that can be used by all the tools.
>> > 
>> > No functional change.
>> > 
>> > Signed-off-by: Roger Pau Monné 
>> > ---
>> > Cc: Jan Beulich 
>> > Cc: Andrew Cooper 
>> > Cc: Ian Jackson 
>> > Cc: Wei Liu 
>> > ---
>> > Changes since v1:
>> >  - Don't remove the header dependencies in the makefile for the x86
>> >emulator test harness.
>> 
>> Hmm, afaics you've done the same for the fuzzer where afaict it's
>> unnecessary. Any specific reason?
> 
> The fuzzer also includes x86-emulate.h which depends on those headers,
> so it should also be rebuilt.

See my original mail - afaict the fuzzer makes use of .*.d files, so
explicit recodring of dependencies should not be needed.

Jan


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

[Xen-devel] [xen-unstable test] 125081: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

flight 125081 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125081/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl  broken
 test-armhf-armhf-xl   4 host-install(4)broken REGR. vs. 124956
 build-i386-libvirt6 libvirt-buildfail REGR. vs. 124956
 test-amd64-amd64-xl-credit2   7 xen-boot fail REGR. vs. 124956
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail 
REGR. vs. 124956

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 124956
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 124956
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 124956
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 124956
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 124956
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 124956
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 124956
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 124956
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 124956
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 124956
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  d8fd67feacc18d5ac071a434469a22f7af487cba
baseline version:
 xen  

[Xen-devel] [ovmf baseline-only test] 74965: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 74965 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74965/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 0c6f94dae5e3ca57fe6093ce2fa4d78fdd061857
baseline version:
 ovmf 79b10d4ce4f08aab4b9548fabc4542ca78a96247

Last test of basis74963  2018-07-13 01:20:21 Z0 days
Testing same since74965  2018-07-13 06:52:41 Z0 days1 attempts


People who touched revisions under test:
  Star Zeng 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



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.


commit 0c6f94dae5e3ca57fe6093ce2fa4d78fdd061857
Author: Star Zeng 
Date:   Wed Jul 11 11:48:37 2018 +0800

MdeModulePkg CapsuleApp: Fix typo EFI_CAPSULE_RPORT_GUID

Cc: Michael D Kinney 
Cc: Jiewen Yao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 

commit 045bb323647c8a2e2f3b319ec5aedff34a730ab0
Author: Star Zeng 
Date:   Wed Jul 11 11:47:24 2018 +0800

MdeModulePkg CapsuleApp: Refine -D option help information

Cc: Michael D Kinney 
Cc: Jiewen Yao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 

commit 1c6dd45b9b3359d5c9d4d2a09ec05f81ad9ccaef
Author: Star Zeng 
Date:   Wed Jul 11 11:45:50 2018 +0800

MdeModulePkg CapsuleApp: Check Arg count for -D option

Cc: Michael D Kinney 
Cc: Jiewen Yao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 

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

[Xen-devel] [distros-debian-jessie test] 74964: tolerable FAIL

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-armhf-jessie-netboot-pygrub 10 debian-di-install fail like 
74939

baseline version:
 flight   74939

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-jessie-netboot-pvgrub pass
 test-amd64-i386-i386-jessie-netboot-pvgrub   pass
 test-amd64-i386-amd64-jessie-netboot-pygrub  pass
 test-armhf-armhf-armhf-jessie-netboot-pygrub fail
 test-amd64-amd64-i386-jessie-netboot-pygrub  pass



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.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [ovmf test] 125147: all pass - PUSHED

[osstest service owner]

flight 125147 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125147/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 280f49b81170aee9176a47085b168ff3bc9fd3e7
baseline version:
 ovmf 0c6f94dae5e3ca57fe6093ce2fa4d78fdd061857

Last test of basis   125145  2018-07-13 02:40:44 Z0 days
Testing same since   125147  2018-07-13 06:40:46 Z0 days1 attempts


People who touched revisions under test:
  Jiaxin Wu 
  Wu Jiaxin 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   0c6f94dae5..280f49b811  280f49b81170aee9176a47085b168ff3bc9fd3e7 -> 
xen-tested-master

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

[Xen-devel] [PATCH v11 10/11] x86/hvm: Remove redundant save functions

[Alexandru Isaila]

This patch removes the redundant save functions and renames the
save_one* to save. It then changes the domain param to vcpu in the save
funcs.

Signed-off-by: Alexandru Isaila 

---
Changes since V9:
- Add enum return type for save funcs
---
 xen/arch/x86/cpu/mcheck/vmce.c |  24 +++--
 xen/arch/x86/hvm/hpet.c|   8 ++-
 xen/arch/x86/hvm/hvm.c | 114 -
 xen/arch/x86/hvm/i8254.c   |   9 ++--
 xen/arch/x86/hvm/irq.c |  24 ++---
 xen/arch/x86/hvm/mtrr.c|  22 +++-
 xen/arch/x86/hvm/pmtimer.c |  10 ++--
 xen/arch/x86/hvm/rtc.c |   9 ++--
 xen/arch/x86/hvm/save.c|  29 +++
 xen/arch/x86/hvm/vioapic.c |  10 ++--
 xen/arch/x86/hvm/viridian.c|  36 ++---
 xen/arch/x86/hvm/vlapic.c  |  45 +++-
 xen/arch/x86/hvm/vpic.c|  12 +++--
 xen/include/asm-x86/hvm/save.h |   8 ++-
 14 files changed, 148 insertions(+), 212 deletions(-)

diff --git a/xen/arch/x86/cpu/mcheck/vmce.c b/xen/arch/x86/cpu/mcheck/vmce.c
index 6090037..265ce61 100644
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -349,7 +349,8 @@ int vmce_wrmsr(uint32_t msr, uint64_t val)
 return ret;
 }
 
-static int vmce_save_vcpu_ctxt_one(struct vcpu *v, hvm_domain_context_t *h)
+static enum save_return_type_t vmce_save_vcpu_ctxt(struct vcpu *v,
+   hvm_domain_context_t *h)
  {
 struct hvm_vmce_vcpu ctxt;
 
@@ -360,24 +361,11 @@ static int vmce_save_vcpu_ctxt_one(struct vcpu *v, 
hvm_domain_context_t *h)
 ctxt.mci_ctl2_bank1 = v->arch.vmce.bank[1].mci_ctl2;
 ctxt.mcg_ext_ctl = v->arch.vmce.mcg_ext_ctl;
 
-return hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, );
+if ( hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, ) != 0 )
+return ERR;
+return OK;
  }
 
-static int vmce_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
-{
-struct vcpu *v;
-int err = 0;
-
-for_each_vcpu ( d, v )
-{
-err = vmce_save_vcpu_ctxt_one(v, h);
-if ( err )
-break;
-}
-
-return err;
-}
-
 static int vmce_load_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
 {
 unsigned int vcpuid = hvm_load_instance(h);
@@ -398,7 +386,7 @@ static int vmce_load_vcpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 }
 
 HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,
-  vmce_save_vcpu_ctxt_one,
+  NULL,
   vmce_load_vcpu_ctxt, 1, HVMSR_PER_VCPU);
 
 /*
diff --git a/xen/arch/x86/hvm/hpet.c b/xen/arch/x86/hvm/hpet.c
index aff8613..0eb302f 100644
--- a/xen/arch/x86/hvm/hpet.c
+++ b/xen/arch/x86/hvm/hpet.c
@@ -516,8 +516,10 @@ static const struct hvm_mmio_ops hpet_mmio_ops = {
 };
 
 
-static int hpet_save(struct domain *d, hvm_domain_context_t *h)
+static enum save_return_type_t hpet_save(struct vcpu *vcpu,
+ hvm_domain_context_t *h)
 {
+struct domain *d = vcpu->domain;
 HPETState *hp = domain_vhpet(d);
 struct vcpu *v = pt_global_vcpu_target(d);
 int rc;
@@ -575,7 +577,9 @@ static int hpet_save(struct domain *d, hvm_domain_context_t 
*h)
 
 write_unlock(>lock);
 
-return rc;
+if ( rc != 0 )
+return ERR;
+return OK;
 }
 
 static int hpet_load(struct domain *d, hvm_domain_context_t *h)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index eb3a012..cdf91f4 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -740,29 +740,18 @@ void hvm_domain_destroy(struct domain *d)
 destroy_vpci_mmcfg(d);
 }
 
-static int hvm_save_tsc_adjust_one(struct vcpu *v, hvm_domain_context_t *h)
+static enum save_return_type_t hvm_save_tsc_adjust(struct vcpu *v,
+   hvm_domain_context_t *h)
  {
 struct hvm_tsc_adjust ctxt;
 
 ctxt.tsc_adjust = v->arch.hvm_vcpu.msr_tsc_adjust;
 
-return hvm_save_entry(TSC_ADJUST, v->vcpu_id, h, );
+if ( hvm_save_entry(TSC_ADJUST, v->vcpu_id, h, ) != 0 )
+return ERR;
+return OK;
  }
 
-static int hvm_save_tsc_adjust(struct domain *d, hvm_domain_context_t *h)
-{
-struct vcpu *v;
-int err = 0;
-
-for_each_vcpu ( d, v )
-{
-err = hvm_save_tsc_adjust_one(v, h);
-if ( err )
-break;
-}
-return err;
-}
-
 static int hvm_load_tsc_adjust(struct domain *d, hvm_domain_context_t *h)
 {
 unsigned int vcpuid = hvm_load_instance(h);
@@ -784,14 +773,22 @@ static int hvm_load_tsc_adjust(struct domain *d, 
hvm_domain_context_t *h)
 }
 
 HVM_REGISTER_SAVE_RESTORE(TSC_ADJUST, hvm_save_tsc_adjust,
-  hvm_save_tsc_adjust_one,
+  NULL,
   hvm_load_tsc_adjust, 1, HVMSR_PER_VCPU);
 
-static int hvm_save_cpu_ctxt_one(struct vcpu *v, hvm_domain_context_t *h)
+static enum save_return_type_t hvm_save_cpu_ctxt(struct vcpu 

[Xen-devel] [PATCH v11 09/11] x86/domctl: Don't pause the whole domain if only getting vcpu state

[Alexandru Isaila]

This patch is focused on moving the for loop to the caller so
now we can save info for a single vcpu instance with the save_one
handlers.

Signed-off-by: Alexandru Isaila 
---
 xen/arch/x86/hvm/save.c | 141 +---
 1 file changed, 111 insertions(+), 30 deletions(-)

diff --git a/xen/arch/x86/hvm/save.c b/xen/arch/x86/hvm/save.c
index b674937..1b28e7f 100644
--- a/xen/arch/x86/hvm/save.c
+++ b/xen/arch/x86/hvm/save.c
@@ -138,9 +138,12 @@ size_t hvm_save_size(struct domain *d)
 int hvm_save_one(struct domain *d, unsigned int typecode, unsigned int 
instance,
  XEN_GUEST_HANDLE_64(uint8) handle, uint64_t *bufsz)
 {
-int rv;
+int rv = 0;
 hvm_domain_context_t ctxt = { };
 const struct hvm_save_descriptor *desc;
+bool is_single_instance = false;
+uint32_t off = 0;
+struct vcpu *v;
 
 if ( d->is_dying ||
  typecode > HVM_SAVE_CODE_MAX ||
@@ -148,43 +151,94 @@ int hvm_save_one(struct domain *d, unsigned int typecode, 
unsigned int instance,
  !hvm_sr_handlers[typecode].save )
 return -EINVAL;
 
+if ( hvm_sr_handlers[typecode].kind == HVMSR_PER_VCPU &&
+instance < d->max_vcpus )
+is_single_instance = true;
+
 ctxt.size = hvm_sr_handlers[typecode].size;
-if ( hvm_sr_handlers[typecode].kind == HVMSR_PER_VCPU )
+if ( hvm_sr_handlers[typecode].kind == HVMSR_PER_VCPU &&
+instance == d->max_vcpus )
 ctxt.size *= d->max_vcpus;
 ctxt.data = xmalloc_bytes(ctxt.size);
 if ( !ctxt.data )
 return -ENOMEM;
 
-if ( (rv = hvm_sr_handlers[typecode].save(d, )) != 0 )
-printk(XENLOG_G_ERR "HVM%d save: failed to save type %"PRIu16" (%d)\n",
-   d->domain_id, typecode, rv);
-else if ( rv = -ENOENT, ctxt.cur >= sizeof(*desc) )
+if ( is_single_instance )
+vcpu_pause(d->vcpu[instance]);
+else
+domain_pause(d);
+
+if ( is_single_instance )
 {
-uint32_t off;
+if ( hvm_sr_handlers[typecode].save_one != NULL )
+rv = hvm_sr_handlers[typecode].save_one(d->vcpu[instance],
+);
+else
+rv = hvm_sr_handlers[typecode].save(d, );
 
-for ( off = 0; off <= (ctxt.cur - sizeof(*desc)); off += desc->length )
+if ( rv != 0 )
 {
-desc = (void *)(ctxt.data + off);
-/* Move past header */
-off += sizeof(*desc);
-if ( ctxt.cur < desc->length ||
- off > ctxt.cur - desc->length )
-break;
-if ( instance == desc->instance )
-{
-rv = 0;
-if ( guest_handle_is_null(handle) )
-*bufsz = desc->length;
-else if ( *bufsz < desc->length )
-rv = -ENOBUFS;
-else if ( copy_to_guest(handle, ctxt.data + off, desc->length) 
)
-rv = -EFAULT;
-else
-*bufsz = desc->length;
-break;
-}
+printk(XENLOG_G_ERR "HVM%d save: failed to save type %"PRIu16" 
(%d)\n",
+   d->domain_id, typecode, rv);
+vcpu_unpause(d->vcpu[instance]);
+}
+else if ( ctxt.cur >= sizeof(*desc) )
+{
+rv = -ENOENT;
+desc = (void *)(ctxt.data);
+ /* Move past header */
+off = sizeof(*desc);
+ if ( ctxt.cur < desc->length ||
+  off > ctxt.cur - desc->length )
+rv = -EFAULT;
+rv = 0;
+if ( guest_handle_is_null(handle) )
+*bufsz = desc->length;
+else if ( *bufsz < desc->length )
+   rv = -ENOBUFS;
+else if ( copy_to_guest(handle, ctxt.data + off, desc->length) )
+rv = -EFAULT;
+else
+*bufsz = desc->length;
+vcpu_unpause(d->vcpu[instance]);
 }
 }
+else
+{
+for_each_vcpu ( d, v )
+{
+if ( (rv = hvm_sr_handlers[typecode].save(d, )) != 0 )
+{
+printk(XENLOG_G_ERR "HVM%d save: failed to save type %"PRIu16" 
(%d)\n",
+   d->domain_id, typecode, rv);
+}
+else if ( ctxt.cur >= sizeof(*desc) )
+{
+rv = -ENOENT;
+desc = (void *)(ctxt.data + off);
+/* Move past header */
+off += sizeof(*desc);
+if ( ctxt.cur < desc->length ||
+ off > ctxt.cur - desc->length )
+break;
+if ( instance == desc->instance )
+{
+rv = 0;
+if ( guest_handle_is_null(handle) )
+*bufsz = desc->length;
+else if ( *bufsz < desc->length )
+rv = 

[Xen-devel] [PATCH v11 07/11] x86/hvm: Introduce viridian_save_vcpu_ctxt_one() func

[Alexandru Isaila]

This is used to save data from a single instance.

Signed-off-by: Alexandru Isaila 
Reviewed-by: Paul Durrant 
---
 xen/arch/x86/hvm/viridian.c | 24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/hvm/viridian.c b/xen/arch/x86/hvm/viridian.c
index 694eae6..1e87cd6 100644
--- a/xen/arch/x86/hvm/viridian.c
+++ b/xen/arch/x86/hvm/viridian.c
@@ -1026,20 +1026,26 @@ static int viridian_load_domain_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 HVM_REGISTER_SAVE_RESTORE(VIRIDIAN_DOMAIN, viridian_save_domain_ctxt,
   viridian_load_domain_ctxt, 1, HVMSR_PER_DOM);
 
-static int viridian_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
+static int viridian_save_vcpu_ctxt_one(struct vcpu *v, hvm_domain_context_t *h)
 {
-struct vcpu *v;
+struct hvm_viridian_vcpu_context ctxt;
 
-if ( !is_viridian_domain(d) )
+if ( !is_viridian_domain(v->domain) )
 return 0;
 
-for_each_vcpu( d, v ) {
-struct hvm_viridian_vcpu_context ctxt = {
-.vp_assist_msr = v->arch.hvm_vcpu.viridian.vp_assist.msr.raw,
-.vp_assist_pending = v->arch.hvm_vcpu.viridian.vp_assist.pending,
-};
+memset(, 0, sizeof(ctxt));
+ctxt.vp_assist_msr = v->arch.hvm_vcpu.viridian.vp_assist.msr.raw;
+ctxt.vp_assist_pending = v->arch.hvm_vcpu.viridian.vp_assist.pending;
 
-if ( hvm_save_entry(VIRIDIAN_VCPU, v->vcpu_id, h, ) != 0 )
+return hvm_save_entry(VIRIDIAN_VCPU, v->vcpu_id, h, );
+}
+
+static int viridian_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
+{
+struct vcpu *v;
+
+for_each_vcpu( d, v ) {
+if ( viridian_save_vcpu_ctxt_one(v, h) != 0 )
 return 1;
 }
 
-- 
2.7.4


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

[Xen-devel] [PATCH v11 11/11] x86/hvm: Remove save_one handler

[Alexandru Isaila]

Signed-off-by: Alexandru Isaila 
---
 xen/arch/x86/cpu/mcheck/vmce.c |  1 -
 xen/arch/x86/hvm/hpet.c|  2 +-
 xen/arch/x86/hvm/hvm.c |  5 +
 xen/arch/x86/hvm/i8254.c   |  2 +-
 xen/arch/x86/hvm/irq.c |  6 +++---
 xen/arch/x86/hvm/mtrr.c|  2 +-
 xen/arch/x86/hvm/pmtimer.c |  2 +-
 xen/arch/x86/hvm/rtc.c |  2 +-
 xen/arch/x86/hvm/save.c| 14 +++---
 xen/arch/x86/hvm/vioapic.c |  2 +-
 xen/arch/x86/hvm/viridian.c|  3 +--
 xen/arch/x86/hvm/vlapic.c  |  4 ++--
 xen/arch/x86/hvm/vpic.c|  2 +-
 xen/include/asm-x86/hvm/save.h |  6 +-
 14 files changed, 18 insertions(+), 35 deletions(-)

diff --git a/xen/arch/x86/cpu/mcheck/vmce.c b/xen/arch/x86/cpu/mcheck/vmce.c
index 265ce61..c679662 100644
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -386,7 +386,6 @@ static int vmce_load_vcpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 }
 
 HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,
-  NULL,
   vmce_load_vcpu_ctxt, 1, HVMSR_PER_VCPU);
 
 /*
diff --git a/xen/arch/x86/hvm/hpet.c b/xen/arch/x86/hvm/hpet.c
index 0eb302f..22e087e 100644
--- a/xen/arch/x86/hvm/hpet.c
+++ b/xen/arch/x86/hvm/hpet.c
@@ -644,7 +644,7 @@ static int hpet_load(struct domain *d, hvm_domain_context_t 
*h)
 return 0;
 }
 
-HVM_REGISTER_SAVE_RESTORE(HPET, hpet_save, NULL, hpet_load, 1, HVMSR_PER_DOM);
+HVM_REGISTER_SAVE_RESTORE(HPET, hpet_save, hpet_load, 1, HVMSR_PER_DOM);
 
 static void hpet_set(HPETState *h)
 {
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index cdf91f4..d11fba6 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -773,7 +773,6 @@ static int hvm_load_tsc_adjust(struct domain *d, 
hvm_domain_context_t *h)
 }
 
 HVM_REGISTER_SAVE_RESTORE(TSC_ADJUST, hvm_save_tsc_adjust,
-  NULL,
   hvm_load_tsc_adjust, 1, HVMSR_PER_VCPU);
 
 static enum save_return_type_t hvm_save_cpu_ctxt(struct vcpu *v,
@@ -1161,7 +1160,7 @@ static int hvm_load_cpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 return 0;
 }
 
-HVM_REGISTER_SAVE_RESTORE(CPU, hvm_save_cpu_ctxt, NULL,
+HVM_REGISTER_SAVE_RESTORE(CPU, hvm_save_cpu_ctxt,
   hvm_load_cpu_ctxt,
   1, HVMSR_PER_VCPU);
 
@@ -1482,7 +1481,6 @@ static int __init hvm_register_CPU_save_and_restore(void)
 hvm_register_savevm(CPU_XSAVE_CODE,
 "CPU_XSAVE",
 hvm_save_cpu_xsave_states,
-NULL,
 hvm_load_cpu_xsave_states,
 HVM_CPU_XSAVE_SIZE(xfeature_mask) +
 sizeof(struct hvm_save_descriptor),
@@ -1495,7 +1493,6 @@ static int __init hvm_register_CPU_save_and_restore(void)
 hvm_register_savevm(CPU_MSR_CODE,
 "CPU_MSR",
 hvm_save_cpu_msrs,
-NULL,
 hvm_load_cpu_msrs,
 HVM_CPU_MSR_SIZE(msr_count_max) +
 sizeof(struct hvm_save_descriptor),
diff --git a/xen/arch/x86/hvm/i8254.c b/xen/arch/x86/hvm/i8254.c
index 00cabac..0d6b84a 100644
--- a/xen/arch/x86/hvm/i8254.c
+++ b/xen/arch/x86/hvm/i8254.c
@@ -440,7 +440,7 @@ static int pit_load(struct domain *d, hvm_domain_context_t 
*h)
 return 0;
 }
 
-HVM_REGISTER_SAVE_RESTORE(PIT, pit_save, NULL, pit_load, 1, HVMSR_PER_DOM);
+HVM_REGISTER_SAVE_RESTORE(PIT, pit_save, pit_load, 1, HVMSR_PER_DOM);
 
 void pit_reset(struct domain *d)
 {
diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
index 73f48a9..14f8dfd 100644
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -776,9 +776,9 @@ static int irq_load_link(struct domain *d, 
hvm_domain_context_t *h)
 return 0;
 }
 
-HVM_REGISTER_SAVE_RESTORE(PCI_IRQ, irq_save_pci, NULL, irq_load_pci,
+HVM_REGISTER_SAVE_RESTORE(PCI_IRQ, irq_save_pci, irq_load_pci,
   1, HVMSR_PER_DOM);
-HVM_REGISTER_SAVE_RESTORE(ISA_IRQ, irq_save_isa, NULL, irq_load_isa,
+HVM_REGISTER_SAVE_RESTORE(ISA_IRQ, irq_save_isa, irq_load_isa,
   1, HVMSR_PER_DOM);
-HVM_REGISTER_SAVE_RESTORE(PCI_LINK, irq_save_link, NULL, irq_load_link,
+HVM_REGISTER_SAVE_RESTORE(PCI_LINK, irq_save_link, irq_load_link,
   1, HVMSR_PER_DOM);
diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index ba00998..4286654 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -810,7 +810,7 @@ static int hvm_load_mtrr_msr(struct domain *d, 
hvm_domain_context_t *h)
 return 0;
 }
 
-HVM_REGISTER_SAVE_RESTORE(MTRR, hvm_save_mtrr_msr, NULL,
+HVM_REGISTER_SAVE_RESTORE(MTRR, hvm_save_mtrr_msr,
   hvm_load_mtrr_msr, 1, HVMSR_PER_VCPU);
 
 void memory_type_changed(struct domain *d)
diff --git a/xen/arch/x86/hvm/pmtimer.c 

[Xen-devel] [PATCH v11 04/11] x86/hvm: Introduce hvm_save_cpu_xsave_states_one

[Alexandru Isaila]

This is used to save data from a single instance.

Signed-off-by: Alexandru Isaila 

---
Changes since V10:
- Add ASSERT to save_one func.
---
 xen/arch/x86/hvm/hvm.c | 36 +++-
 1 file changed, 23 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index c343ba8..4cf8582 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1188,30 +1188,40 @@ HVM_REGISTER_SAVE_RESTORE(CPU, hvm_save_cpu_ctxt, 
hvm_load_cpu_ctxt,
save_area) + \
   xstate_ctxt_size(xcr0))
 
-static int hvm_save_cpu_xsave_states(struct domain *d, hvm_domain_context_t *h)
+static int hvm_save_cpu_xsave_states_one(struct vcpu *v, hvm_domain_context_t 
*h)
 {
-struct vcpu *v;
 struct hvm_hw_cpu_xsave *ctxt;
+unsigned int size = HVM_CPU_XSAVE_SIZE(v->arch.xcr0_accum);
 
 if ( !cpu_has_xsave )
 return 0;   /* do nothing */
 
+ASSERT(!xsave_enabled(v));
+
+if ( _hvm_init_entry(h, CPU_XSAVE_CODE, v->vcpu_id, size) )
+return 1;
+ctxt = (struct hvm_hw_cpu_xsave *)>data[h->cur];
+h->cur += size;
+ctxt->xfeature_mask = xfeature_mask;
+ctxt->xcr0 = v->arch.xcr0;
+ctxt->xcr0_accum = v->arch.xcr0_accum;
+
+expand_xsave_states(v, >save_area,
+size - offsetof(typeof(*ctxt), save_area));
+return 0;
+ }
+
+static int hvm_save_cpu_xsave_states(struct domain *d, hvm_domain_context_t *h)
+{
+struct vcpu *v;
+
 for_each_vcpu ( d, v )
 {
-unsigned int size = HVM_CPU_XSAVE_SIZE(v->arch.xcr0_accum);
-
 if ( !xsave_enabled(v) )
 continue;
-if ( _hvm_init_entry(h, CPU_XSAVE_CODE, v->vcpu_id, size) )
+
+if ( hvm_save_cpu_xsave_states_one(v, h) != 0 )
 return 1;
-ctxt = (struct hvm_hw_cpu_xsave *)>data[h->cur];
-h->cur += size;
-
-ctxt->xfeature_mask = xfeature_mask;
-ctxt->xcr0 = v->arch.xcr0;
-ctxt->xcr0_accum = v->arch.xcr0_accum;
-expand_xsave_states(v, >save_area,
-size - offsetof(typeof(*ctxt), save_area));
 }
 
 return 0;
-- 
2.7.4


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

[Xen-devel] [PATCH v11 02/11] x86/hvm: Introduce hvm_save_tsc_adjust_one() func

[Alexandru Isaila]

This is used to save data from a single instance.

Signed-off-by: Alexandru Isaila 
Reviewed-by: Paul Durrant 

---
Changes since V9:
 - Change return of the save_one func to return hvm_save_entry.
---
 xen/arch/x86/hvm/hvm.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 93092d2..c47d162 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -740,20 +740,26 @@ void hvm_domain_destroy(struct domain *d)
 destroy_vpci_mmcfg(d);
 }
 
+static int hvm_save_tsc_adjust_one(struct vcpu *v, hvm_domain_context_t *h)
+ {
+struct hvm_tsc_adjust ctxt;
+
+ctxt.tsc_adjust = v->arch.hvm_vcpu.msr_tsc_adjust;
+
+return hvm_save_entry(TSC_ADJUST, v->vcpu_id, h, );
+ }
+
 static int hvm_save_tsc_adjust(struct domain *d, hvm_domain_context_t *h)
 {
 struct vcpu *v;
-struct hvm_tsc_adjust ctxt;
 int err = 0;
 
 for_each_vcpu ( d, v )
 {
-ctxt.tsc_adjust = v->arch.hvm_vcpu.msr_tsc_adjust;
-err = hvm_save_entry(TSC_ADJUST, v->vcpu_id, h, );
+err = hvm_save_tsc_adjust_one(v, h);
 if ( err )
 break;
 }
-
 return err;
 }
 
-- 
2.7.4


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

[Xen-devel] [PATCH v11 01/11] x86/cpu: Introduce vmce_save_vcpu_ctxt_one() func

[Alexandru Isaila]

This is used to save data from a single instance.

Signed-off-by: Alexandru Isaila 

---
Changes since V10:
- Add memset to 0 for ctxt.
---
 xen/arch/x86/cpu/mcheck/vmce.c | 23 +++
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/cpu/mcheck/vmce.c b/xen/arch/x86/cpu/mcheck/vmce.c
index e07cd2f..bf58ef5 100644
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -349,6 +349,20 @@ int vmce_wrmsr(uint32_t msr, uint64_t val)
 return ret;
 }
 
+static int vmce_save_vcpu_ctxt_one(struct vcpu *v, hvm_domain_context_t *h)
+ {
+struct hvm_vmce_vcpu ctxt;
+
+memset(, 0, sizeof(ctxt));
+
+ctxt.caps = v->arch.vmce.mcg_cap;
+ctxt.mci_ctl2_bank0 = v->arch.vmce.bank[0].mci_ctl2;
+ctxt.mci_ctl2_bank1 = v->arch.vmce.bank[1].mci_ctl2;
+ctxt.mcg_ext_ctl = v->arch.vmce.mcg_ext_ctl;
+
+return hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, );
+ }
+
 static int vmce_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
 {
 struct vcpu *v;
@@ -356,14 +370,7 @@ static int vmce_save_vcpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 
 for_each_vcpu ( d, v )
 {
-struct hvm_vmce_vcpu ctxt = {
-.caps = v->arch.vmce.mcg_cap,
-.mci_ctl2_bank0 = v->arch.vmce.bank[0].mci_ctl2,
-.mci_ctl2_bank1 = v->arch.vmce.bank[1].mci_ctl2,
-.mcg_ext_ctl = v->arch.vmce.mcg_ext_ctl,
-};
-
-err = hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, );
+err = vmce_save_vcpu_ctxt_one(v, h);
 if ( err )
 break;
 }
-- 
2.7.4


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

[Xen-devel] [PATCH v11 06/11] x86/hvm: Introduce hvm_save_mtrr_msr_one func

[Alexandru Isaila]

This is used to save data from a single instance.

Signed-off-by: Alexandru Isaila 

---
Changes since v10:
- Add blank line before memset.

Note: This patch is based on Roger Pau Monne's series[1]
---
 xen/arch/x86/hvm/mtrr.c | 76 ++---
 1 file changed, 40 insertions(+), 36 deletions(-)

diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index 48facbb..bf6760f 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -718,49 +718,53 @@ int hvm_set_mem_pinned_cacheattr(struct domain *d, 
uint64_t gfn_start,
 return 0;
 }
 
-static int hvm_save_mtrr_msr(struct domain *d, hvm_domain_context_t *h)
+static int hvm_save_mtrr_msr_one(struct vcpu *v, hvm_domain_context_t *h)
 {
-struct vcpu *v;
+const struct mtrr_state *mtrr_state = >arch.hvm_vcpu.mtrr;
+struct hvm_hw_mtrr hw_mtrr;
+unsigned int i;
 
-/* save mtrr */
-for_each_vcpu(d, v)
-{
-const struct mtrr_state *mtrr_state = >arch.hvm_vcpu.mtrr;
-struct hvm_hw_mtrr hw_mtrr = {
-.msr_mtrr_def_type = mtrr_state->def_type |
- MASK_INSR(mtrr_state->fixed_enabled,
-   MTRRdefType_FE) |
- MASK_INSR(mtrr_state->enabled, MTRRdefType_E),
-.msr_mtrr_cap  = mtrr_state->mtrr_cap,
-};
-unsigned int i;
+memset(_mtrr, 0, sizeof(hw_mtrr));
+hw_mtrr.msr_mtrr_def_type = mtrr_state->def_type |
+MASK_INSR(mtrr_state->fixed_enabled,
+  MTRRdefType_FE) |
+ MASK_INSR(mtrr_state->enabled, MTRRdefType_E);
+hw_mtrr.msr_mtrr_cap = mtrr_state->mtrr_cap;
 
-if ( MASK_EXTR(hw_mtrr.msr_mtrr_cap, MTRRcap_VCNT) >
- (ARRAY_SIZE(hw_mtrr.msr_mtrr_var) / 2) )
-{
-dprintk(XENLOG_G_ERR,
-"HVM save: %pv: too many (%lu) variable range MTRRs\n",
-v, MASK_EXTR(hw_mtrr.msr_mtrr_cap, MTRRcap_VCNT));
-return -EINVAL;
-}
+if ( MASK_EXTR(hw_mtrr.msr_mtrr_cap, MTRRcap_VCNT) >
+ (ARRAY_SIZE(hw_mtrr.msr_mtrr_var) / 2) )
+{
+dprintk(XENLOG_G_ERR,
+"HVM save: %pv: too many (%lu) variable range MTRRs\n",
+v, MASK_EXTR(hw_mtrr.msr_mtrr_cap, MTRRcap_VCNT));
+return -EINVAL;
+}
+hvm_get_guest_pat(v, _mtrr.msr_pat_cr);
+for ( i = 0; i < MASK_EXTR(hw_mtrr.msr_mtrr_cap, MTRRcap_VCNT); i++ )
+{
+/* save physbase */
+hw_mtrr.msr_mtrr_var[i*2] =
+((uint64_t*)mtrr_state->var_ranges)[i*2];
+/* save physmask */
+hw_mtrr.msr_mtrr_var[i*2+1] =
+((uint64_t*)mtrr_state->var_ranges)[i*2+1];
+}
 
-hvm_get_guest_pat(v, _mtrr.msr_pat_cr);
+for ( i = 0; i < NUM_FIXED_MSR; i++ )
+hw_mtrr.msr_mtrr_fixed[i] =
+((uint64_t*)mtrr_state->fixed_ranges)[i];
 
-for ( i = 0; i < MASK_EXTR(hw_mtrr.msr_mtrr_cap, MTRRcap_VCNT); i++ )
-{
-/* save physbase */
-hw_mtrr.msr_mtrr_var[i*2] =
-((uint64_t*)mtrr_state->var_ranges)[i*2];
-/* save physmask */
-hw_mtrr.msr_mtrr_var[i*2+1] =
-((uint64_t*)mtrr_state->var_ranges)[i*2+1];
-}
+return hvm_save_entry(MTRR, v->vcpu_id, h, _mtrr);
+ }
 
-for ( i = 0; i < NUM_FIXED_MSR; i++ )
-hw_mtrr.msr_mtrr_fixed[i] =
-((uint64_t*)mtrr_state->fixed_ranges)[i];
+static int hvm_save_mtrr_msr(struct domain *d, hvm_domain_context_t *h)
+{
+struct vcpu *v;
 
-if ( hvm_save_entry(MTRR, v->vcpu_id, h, _mtrr) != 0 )
+/* save mtrr */
+for_each_vcpu(d, v)
+{
+if ( hvm_save_mtrr_msr_one(v, h) != 0 )
 return 1;
 }
 return 0;
-- 
2.7.4


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

[Xen-devel] [PATCH v11 05/11] x86/hvm: Introduce hvm_save_cpu_msrs_one func

[Alexandru Isaila]

This is used to save data from a single instance.

Signed-off-by: Alexandru Isaila 
Reviewed-by: Paul Durrant 

---
Changes since V7:
- Moved the init of ctxt->count to hvm_save_cpu_msrs_one()
---
 xen/arch/x86/hvm/hvm.c | 101 +++--
 1 file changed, 55 insertions(+), 46 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 4cf8582..cc69d13 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1364,66 +1364,75 @@ static const uint32_t msrs_to_send[] = {
 };
 static unsigned int __read_mostly msr_count_max = ARRAY_SIZE(msrs_to_send);
 
-static int hvm_save_cpu_msrs(struct domain *d, hvm_domain_context_t *h)
+static int hvm_save_cpu_msrs_one(struct vcpu *v, hvm_domain_context_t *h)
 {
-struct vcpu *v;
+unsigned int i;
+struct hvm_msr *ctxt;
+struct hvm_save_descriptor *desc = _p(>data[h->cur]);
 
-for_each_vcpu ( d, v )
+if ( _hvm_init_entry(h, CPU_MSR_CODE, v->vcpu_id,
+ HVM_CPU_MSR_SIZE(msr_count_max)) )
+return 1;
+ctxt = (struct hvm_msr *)>data[h->cur];
+
+ctxt->count = 0;
+for ( i = 0; i < ARRAY_SIZE(msrs_to_send); ++i )
 {
-struct hvm_save_descriptor *desc = _p(>data[h->cur]);
-struct hvm_msr *ctxt;
-unsigned int i;
+uint64_t val;
+int rc = guest_rdmsr(v, msrs_to_send[i], );
 
-if ( _hvm_init_entry(h, CPU_MSR_CODE, v->vcpu_id,
- HVM_CPU_MSR_SIZE(msr_count_max)) )
-return 1;
-ctxt = (struct hvm_msr *)>data[h->cur];
-ctxt->count = 0;
+/*
+ * It is the programmers responsibility to ensure that
+ * msrs_to_send[] contain generally-read/write MSRs.
+ * X86EMUL_EXCEPTION here implies a missing feature, and that the
+ * guest doesn't have access to the MSR.
+ */
+if ( rc == X86EMUL_EXCEPTION )
+continue;
 
-for ( i = 0; i < ARRAY_SIZE(msrs_to_send); ++i )
+if ( rc != X86EMUL_OKAY )
 {
-uint64_t val;
-int rc = guest_rdmsr(v, msrs_to_send[i], );
+ASSERT_UNREACHABLE();
+return -ENXIO;
+}
 
-/*
- * It is the programmers responsibility to ensure that
- * msrs_to_send[] contain generally-read/write MSRs.
- * X86EMUL_EXCEPTION here implies a missing feature, and that the
- * guest doesn't have access to the MSR.
- */
-if ( rc == X86EMUL_EXCEPTION )
-continue;
+if ( !val )
+continue; /* Skip empty MSRs. */
 
-if ( rc != X86EMUL_OKAY )
-{
-ASSERT_UNREACHABLE();
-return -ENXIO;
-}
+ctxt->msr[ctxt->count].index = msrs_to_send[i];
+ctxt->msr[ctxt->count++].val = val;
+}
 
-if ( !val )
-continue; /* Skip empty MSRs. */
+if ( hvm_funcs.save_msr )
+hvm_funcs.save_msr(v, ctxt);
 
-ctxt->msr[ctxt->count].index = msrs_to_send[i];
-ctxt->msr[ctxt->count++].val = val;
-}
+ASSERT(ctxt->count <= msr_count_max);
 
-if ( hvm_funcs.save_msr )
-hvm_funcs.save_msr(v, ctxt);
+for ( i = 0; i < ctxt->count; ++i )
+ctxt->msr[i]._rsvd = 0;
 
-ASSERT(ctxt->count <= msr_count_max);
+if ( ctxt->count )
+{
+/* Rewrite length to indicate how much space we actually used. */
+desc->length = HVM_CPU_MSR_SIZE(ctxt->count);
+h->cur += HVM_CPU_MSR_SIZE(ctxt->count);
+}
+else
+/* or rewind and remove the descriptor from the stream. */
+h->cur -= sizeof(struct hvm_save_descriptor);
 
-for ( i = 0; i < ctxt->count; ++i )
-ctxt->msr[i]._rsvd = 0;
+return 0;
+}
 
-if ( ctxt->count )
-{
-/* Rewrite length to indicate how much space we actually used. */
-desc->length = HVM_CPU_MSR_SIZE(ctxt->count);
-h->cur += HVM_CPU_MSR_SIZE(ctxt->count);
-}
-else
-/* or rewind and remove the descriptor from the stream. */
-h->cur -= sizeof(struct hvm_save_descriptor);
+
+static int hvm_save_cpu_msrs(struct domain *d, hvm_domain_context_t *h)
+{
+struct vcpu *v;
+
+for_each_vcpu ( d, v )
+{
+if ( hvm_save_cpu_msrs_one(v, h) != 0 )
+return 1;
 }
 
 return 0;
-- 
2.7.4


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

[Xen-devel] [PATCH v11 03/11] x86/hvm: Introduce hvm_save_cpu_ctxt_one func

[Alexandru Isaila]

This is used to save data from a single instance.

Signed-off-by: Alexandru Isaila 
Reviewed-by: Paul Durrant 

---
Changes since V8:
- Change return of the save_one func to return hvm_save_entry
- Move continue out of on func
- Remove #define CONTINUE.
---
 xen/arch/x86/hvm/hvm.c | 211 ++---
 1 file changed, 110 insertions(+), 101 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index c47d162..c343ba8 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -786,117 +786,126 @@ static int hvm_load_tsc_adjust(struct domain *d, 
hvm_domain_context_t *h)
 HVM_REGISTER_SAVE_RESTORE(TSC_ADJUST, hvm_save_tsc_adjust,
   hvm_load_tsc_adjust, 1, HVMSR_PER_VCPU);
 
+static int hvm_save_cpu_ctxt_one(struct vcpu *v, hvm_domain_context_t *h)
+{
+struct segment_register seg;
+struct hvm_hw_cpu ctxt;
+
+memset(, 0, sizeof(ctxt));
+
+/* Architecture-specific vmcs/vmcb bits */
+hvm_funcs.save_cpu_ctxt(v, );
+
+ctxt.tsc = hvm_get_guest_tsc_fixed(v, v->domain->arch.hvm_domain.sync_tsc);
+
+ctxt.msr_tsc_aux = hvm_msr_tsc_aux(v);
+
+hvm_get_segment_register(v, x86_seg_idtr, );
+ctxt.idtr_limit = seg.limit;
+ctxt.idtr_base = seg.base;
+
+hvm_get_segment_register(v, x86_seg_gdtr, );
+ctxt.gdtr_limit = seg.limit;
+ctxt.gdtr_base = seg.base;
+
+hvm_get_segment_register(v, x86_seg_cs, );
+ctxt.cs_sel = seg.sel;
+ctxt.cs_limit = seg.limit;
+ctxt.cs_base = seg.base;
+ctxt.cs_arbytes = seg.attr;
+
+hvm_get_segment_register(v, x86_seg_ds, );
+ctxt.ds_sel = seg.sel;
+ctxt.ds_limit = seg.limit;
+ctxt.ds_base = seg.base;
+ctxt.ds_arbytes = seg.attr;
+
+hvm_get_segment_register(v, x86_seg_es, );
+ctxt.es_sel = seg.sel;
+ctxt.es_limit = seg.limit;
+ctxt.es_base = seg.base;
+ctxt.es_arbytes = seg.attr;
+
+hvm_get_segment_register(v, x86_seg_ss, );
+ctxt.ss_sel = seg.sel;
+ctxt.ss_limit = seg.limit;
+ctxt.ss_base = seg.base;
+ctxt.ss_arbytes = seg.attr;
+
+hvm_get_segment_register(v, x86_seg_fs, );
+ctxt.fs_sel = seg.sel;
+ctxt.fs_limit = seg.limit;
+ctxt.fs_base = seg.base;
+ctxt.fs_arbytes = seg.attr;
+
+hvm_get_segment_register(v, x86_seg_gs, );
+ctxt.gs_sel = seg.sel;
+ctxt.gs_limit = seg.limit;
+ctxt.gs_base = seg.base;
+ctxt.gs_arbytes = seg.attr;
+
+hvm_get_segment_register(v, x86_seg_tr, );
+ctxt.tr_sel = seg.sel;
+ctxt.tr_limit = seg.limit;
+ctxt.tr_base = seg.base;
+ctxt.tr_arbytes = seg.attr;
+
+hvm_get_segment_register(v, x86_seg_ldtr, );
+ctxt.ldtr_sel = seg.sel;
+ctxt.ldtr_limit = seg.limit;
+ctxt.ldtr_base = seg.base;
+ctxt.ldtr_arbytes = seg.attr;
+
+if ( v->fpu_initialised )
+{
+memcpy(ctxt.fpu_regs, v->arch.fpu_ctxt, sizeof(ctxt.fpu_regs));
+ctxt.flags = XEN_X86_FPU_INITIALISED;
+}
+
+ctxt.rax = v->arch.user_regs.rax;
+ctxt.rbx = v->arch.user_regs.rbx;
+ctxt.rcx = v->arch.user_regs.rcx;
+ctxt.rdx = v->arch.user_regs.rdx;
+ctxt.rbp = v->arch.user_regs.rbp;
+ctxt.rsi = v->arch.user_regs.rsi;
+ctxt.rdi = v->arch.user_regs.rdi;
+ctxt.rsp = v->arch.user_regs.rsp;
+ctxt.rip = v->arch.user_regs.rip;
+ctxt.rflags = v->arch.user_regs.rflags;
+ctxt.r8  = v->arch.user_regs.r8;
+ctxt.r9  = v->arch.user_regs.r9;
+ctxt.r10 = v->arch.user_regs.r10;
+ctxt.r11 = v->arch.user_regs.r11;
+ctxt.r12 = v->arch.user_regs.r12;
+ctxt.r13 = v->arch.user_regs.r13;
+ctxt.r14 = v->arch.user_regs.r14;
+ctxt.r15 = v->arch.user_regs.r15;
+ctxt.dr0 = v->arch.debugreg[0];
+ctxt.dr1 = v->arch.debugreg[1];
+ctxt.dr2 = v->arch.debugreg[2];
+ctxt.dr3 = v->arch.debugreg[3];
+ctxt.dr6 = v->arch.debugreg[6];
+ctxt.dr7 = v->arch.debugreg[7];
+
+return hvm_save_entry(CPU, v->vcpu_id, h, );
+}
+
 static int hvm_save_cpu_ctxt(struct domain *d, hvm_domain_context_t *h)
 {
 struct vcpu *v;
-struct hvm_hw_cpu ctxt;
-struct segment_register seg;
 
 for_each_vcpu ( d, v )
 {
-/* We don't need to save state for a vcpu that is down; the restore 
- * code will leave it down if there is nothing saved. */
+/*
+ * We don't need to save state for a vcpu that is down; the restore
+ * code will leave it down if there is nothing saved.
+ */
 if ( v->pause_flags & VPF_down )
 continue;
 
-memset(, 0, sizeof(ctxt));
-
-/* Architecture-specific vmcs/vmcb bits */
-hvm_funcs.save_cpu_ctxt(v, );
-
-ctxt.tsc = hvm_get_guest_tsc_fixed(v, d->arch.hvm_domain.sync_tsc);
-
-ctxt.msr_tsc_aux = hvm_msr_tsc_aux(v);
-
-hvm_get_segment_register(v, x86_seg_idtr, );
-ctxt.idtr_limit = seg.limit;
-ctxt.idtr_base = seg.base;
-
-hvm_get_segment_register(v, x86_seg_gdtr, );
-

[Xen-devel] [PATCH v11 00/11] x86/domctl: Save info for one vcpu instance

[Alexandru Isaila]

Hi all,

This patch series addresses the ideea of saving data from a single vcpu 
instance.
First it starts by adding *save_one functions, then it introduces a handler for 
the
new save_one* funcs and makes use of it in the hvm_save and hvm_save_one funcs.
The final 2 patches are used for clean up. The first one removes the save* 
funcs and
renames the save_one* to save.
The last patch removes the save_one* handler that is no longer used.

Cheers,

Alexandru Isaila (11):

x86/cpu: Introduce vmce_save_vcpu_ctxt_one() func
x86/hvm: Introduce hvm_save_tsc_adjust_one() func
x86/hvm: Introduce hvm_save_cpu_ctxt_one func
x86/hvm: Introduce hvm_save_cpu_xsave_states_one
x86/hvm: Introduce hvm_save_cpu_msrs_one func
x86/hvm: Introduce hvm_save_mtrr_msr_one func
x86/hvm: Introduce viridian_save_vcpu_ctxt_one()
x86/hvm: Add handler for save_one funcs
x86/domctl: Don't pause the whole domain if only
x86/hvm: Remove redundant save functions
x86/hvm: Remove save_one handler

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

Re: [Xen-devel] [PATCH 1/8] cpupools: fix state when downing a CPU failed

[Juergen Gross]

On 11/07/18 14:04, Jan Beulich wrote:
> While I've run into the issue with further patches in place which no
> longer guarantee the per-CPU area to start out as all zeros, the
> CPU_DOWN_FAILED processing looks to have the same issue: By not zapping
> the per-CPU cpupool pointer, cpupool_cpu_add()'s (indirect) invocation
> of schedule_cpu_switch() will trigger the "c != old_pool" assertion
> there.
> 
> Clearing the field during CPU_DOWN_PREPARE is too early (afaict this
> should not happen before cpu_disable_scheduler()). Clearing it in
> CPU_DEAD and CPU_DOWN_FAILED would be an option, but would take the same
> piece of code twice. Since the field's value shouldn't matter while the
> CPU is offline, simply clear it in CPU_ONLINE and CPU_DOWN_FAILED, but
> only for other than the suspend/resume case (which gets specially
> handled in cpupool_cpu_remove()).
> 
> Signed-off-by: Jan Beulich 
> ---
> TBD: I think this would better call schedule_cpu_switch(cpu, NULL) from
>  cpupool_cpu_remove(), but besides that - as per above - likely
>  being too early, that function has further prereqs to be met. It
>  also doesn't look as if cpupool_unassign_cpu_helper() could be used
>  there.
> 
> --- a/xen/common/cpupool.c
> +++ b/xen/common/cpupool.c
> @@ -778,6 +778,8 @@ static int cpu_callback(
>  {
>  case CPU_DOWN_FAILED:
>  case CPU_ONLINE:
> +if ( system_state <= SYS_STATE_active )
> +per_cpu(cpupool, cpu) = NULL;
>  rc = cpupool_cpu_add(cpu);

Wouldn't it make more sense to clear the field in cpupool_cpu_add()
which already is testing system_state?

Modifying the condition in cpupool_cpu_add() to

  if ( system_state <= SYS_STATE_active )

at the same time would have the benefit to catch problems in case
suspending cpus is failing during SYS_STATE_suspend (I'd expect
triggering the first ASSERT in schedule_cpu_switch() in this case).

It should be noted that this scenario is theoretical only, as today
the CPU_DOWN_FAILED case can't happen in the suspend case.


Juergen

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

Re: [Xen-devel] [PATCH] xen/x86/vpmu: Zero struct pt_regs before calling into sample handling code

[Juergen Gross]

On 12/07/18 19:27, Boris Ostrovsky wrote:
> Otherwise we may leak kernel stack for events that sample user
> registers.
> 
> Reported-by: Mark Rutland 
> Signed-off-by: Boris Ostrovsky 
> Cc: sta...@vger.kernel.org

Reviewed-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH 2/8] x86: distinguish CPU offlining from CPU removal

[Wei Liu]

On Thu, Jul 12, 2018 at 05:48:40AM -0600, Jan Beulich wrote:
> >>> On 12.07.18 at 12:53,  wrote:
> > On Wed, Jul 11, 2018 at 06:06:04AM -0600, Jan Beulich wrote:
> > [...]
> >> --- a/xen/arch/x86/smpboot.c
> >> +++ b/xen/arch/x86/smpboot.c
> >> @@ -63,6 +63,8 @@ static cpumask_t scratch_cpu0mask;
> >>  cpumask_t cpu_online_map __read_mostly;
> >>  EXPORT_SYMBOL(cpu_online_map);
> >>  
> >> +bool __read_mostly park_offline_cpus;
> >> +
> >>  unsigned int __read_mostly nr_sockets;
> >>  cpumask_t **__read_mostly socket_cpumask;
> >>  static cpumask_t *secondary_socket_cpumask;
> >> @@ -887,7 +889,7 @@ static void cleanup_cpu_root_pgt(unsigne
> >>  }
> >>  }
> >>  
> >> -static void cpu_smpboot_free(unsigned int cpu)
> >> +static void cpu_smpboot_free(unsigned int cpu, bool all)
> > 
> > I think "all" is too vague. It doesn't convey the idea what constitutes
> > "partial". But I don't have any better suggestion either.
> 
> Indeed I've been trying to come up with a better name before
> posting, but couldn't. One thing though - I don't think the name
> should in anyway be required to express what "partial" means.
> 

A sentence or two to describe what !all is for would be helpful.

Wei.

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

Re: [Xen-devel] [PATCH v2] tools: remove local links to the x86 headers

[Wei Liu]

On Thu, Jul 12, 2018 at 06:48:06PM +0200, Roger Pau Monne wrote:
> In the x86 test harness and the fuzzer, and instead create a link in
> the tools/include directory that can be used by all the tools.
> 
> No functional change.
> 
> Signed-off-by: Roger Pau Monné 
> ---

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 6/8] x86: (command line option to) avoid use of secondary hyper-threads

[Jan Beulich]

>>> On 12.07.18 at 17:45,  wrote:
> On 11/07/18 13:10, Jan Beulich wrote:
>> --- a/docs/misc/xen-command-line.markdown
>> +++ b/docs/misc/xen-command-line.markdown
>> @@ -1040,6 +1040,13 @@ identical to the boot CPU will be parked
>>  ### hpetbroadcast (x86)
>>  > `= `
>>  
>> +### ht (x86)
> 
> I'd suggest smt rather than ht here.  SMT is the technical term, while
> HT is Intel's marketing name.

Hmm, many BIOSes (if the have such an option) talk about HT, which
to me makes "ht" a closer match. How about we allow both?

Jan



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

Re: [Xen-devel] [PATCH 5/8] x86: bring up all CPUs even if not all are supposed to be used

[Jan Beulich]

>>> On 12.07.18 at 17:38,  wrote:
> On 11/07/18 13:09, Jan Beulich wrote:
>> Reportedly Intel CPUs which can't broadcast #MC to all targeted
>> cores/threads because some have CR4.MCE clear will shut down. Therefore
>> we want to keep CR4.MCE enabled when offlining a CPU, and we need to
>> bring up all CPUs in order to be able to set CR4.MCE in the first place.
>>
>> The use of clear_in_cr4() in cpu_mcheck_disable() was ill advised
>> anyway, and to avoid future similar mistakes I'm removing clear_in_cr4()
>> altogether right here.
>>
>> Signed-off-by: Jan Beulich 
>> ---
>> Instead of fully bringing up CPUs and then calling cpu_down(), another
>> option would be to suppress/cancel full bringup in smp_callin().
> 
> What is the practical difference?  When we know ahead of time that we
> are intending to part the core, then cancelling in smp_callin() seems
> cleaner.

There are things that get left out in that case, in particular anything
done in CPU_STARTING and CPU_ONLINE notifications. A prime
omission here would be mwait_idle_cpu_init() setting up C-state
information for the CPU.

The other risk I see is that of the apparent error that this causes
to be handed up the call tree. As you can see from the cpupool fix
that was necessary, we'd chance to run into more buggy error
handling paths.

All in all - originally I had also thought that this approach might be
cleaner, but the above together with the ease of invoking
cpu_down() (requiring pretty little change overall) made me
change minds. The main downside is really that runtime soft-
online attempts will make (in patch 6, as mentioned there) the
hyperthreads visible to the scheduler for a brief moment.

Jan



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

Re: [Xen-devel] [PATCH 00/16] x86: indirect call overhead reduction

[Jan Beulich]

>>> On 11.07.18 at 15:15,  wrote:
> While indirect calls have always been more expensive than direct ones,
> their cost has further increased with the Spectre v2 mitigations. In a
> number of cases we simply pointlessly use them in the first place. In
> many other cases the indirection solely exists to abstract from e.g.
> vendor specific hardware details, and hence the pointers used never
> change once set. Here we can use alternatives patching to get rid of
> the indirection.
> 
> From patch 8 onwards dependencies exist on earlier, yet to be reviewed
> patches ("x86/alternatives: fully leverage automatic NOP filling" as well
> as the "x86: improve PDX <-> PFN and alike translations" series at the
> very least). I nevertheless wanted to enable a first round of review of
> the series, the more that some of the patches (not just initial ones)
> could perhaps be taken irrespective of those dependencies.
> 
> Further areas where indirect calls could be eliminated (and that I've put
> on my todo list in case the general concept here is deemed reasonable)
> are IOMMU, cpufreq, vPMU, and XSM. For some of these, the ARM side
> would need dealing with as well - I'm not sure whether replacing indirect
> calls by direct ones is worthwhile there as well; if not, the wrappers
> would simply need to become function invocations in the ARM case.

Btw, I didn't want to Cc you on the whole series, but input on the above
would certainly be helpful to decide how to deal with indirect calls in code
shared between the architectures.

Thanks, Jan



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

Re: [Xen-devel] [PATCH v2] tools: remove local links to the x86 headers

[Roger Pau Monné]

On Fri, Jul 13, 2018 at 01:49:37AM -0600, Jan Beulich wrote:
> >>> On 12.07.18 at 18:48,  wrote:
> > In the x86 test harness and the fuzzer, and instead create a link in
> > the tools/include directory that can be used by all the tools.
> > 
> > No functional change.
> > 
> > Signed-off-by: Roger Pau Monné 
> > ---
> > Cc: Jan Beulich 
> > Cc: Andrew Cooper 
> > Cc: Ian Jackson 
> > Cc: Wei Liu 
> > ---
> > Changes since v1:
> >  - Don't remove the header dependencies in the makefile for the x86
> >emulator test harness.
> 
> Hmm, afaics you've done the same for the fuzzer where afaict it's
> unnecessary. Any specific reason?

The fuzzer also includes x86-emulate.h which depends on those headers,
so it should also be rebuilt.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v2] tools: remove local links to the x86 headers

[Jan Beulich]

>>> On 12.07.18 at 18:48,  wrote:
> In the x86 test harness and the fuzzer, and instead create a link in
> the tools/include directory that can be used by all the tools.
> 
> No functional change.
> 
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
> Changes since v1:
>  - Don't remove the header dependencies in the makefile for the x86
>emulator test harness.

Hmm, afaics you've done the same for the fuzzer where afaict it's
unnecessary. Any specific reason?

Jan


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

[Xen-devel] [linux-4.14 test] 125079: tolerable FAIL - PUSHED

[osstest service owner]

flight 125079 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125079/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linux5893f4c3fb784f48c020d2637c129a45da7be39e
baseline version:
 linuxcda6fd4d9382205bb792255cd56a91062d404bc0

Last test of basis   124389  2018-06-19 04:33:40 Z   24 days
Failing since124456  2018-06-20 19:09:25 Z   22 days   12 attempts
Testing same since   125079  2018-07-10 16:42:10 Z2 days1 attempts


437 people touched revisions under test,
not listing them all

jobs:
 

Re: [Xen-devel] [PATCH] automation/build: update stretck-i386 dockerfile

[Wei Liu]

On Thu, Jul 12, 2018 at 08:14:06PM -0500, Doug Goldstein wrote:
> On Thu, Jul 12, 2018 at 02:33:42PM -0500, Doug Goldstein wrote:
> > On Thu, Jul 12, 2018 at 05:31:27PM +0100, Wei Liu wrote:
> > > We don't need to specify /bin/bash in the entry point rune, otherwise
> > > non-interactive invocation of the container would fail with something
> > > like:
> > > 
> > > + C=debian:stretch-i386
> > > + export CONTAINER=registry.gitlab.com/xen-project/xen/debian:stretch-i386
> > > + CONTAINER=registry.gitlab.com/xen-project/xen/debian:stretch-i386
> > > + cd /local/work/COMMITTER/xen-32.git
> > > + git fetch origin
> > > + con git reset --hard origin/staging
> > > *** Ensuring registry.gitlab.com/xen-project/xen/debian:stretch-i386 is 
> > > up to date
> > > *** Launching container ...
> > > /usr/bin/git: /usr/bin/git: cannot execute binary file
> > > 
> > > While at it, use shorthand "linux32".
> > > 
> > > Signed-off-by: Wei Liu 
> > > ---
> > 
> > Acked-by: Doug Goldstein 
> 
> Oh I forgot to note that there's a typo in the subject but that can just
> be fixed while committing.

Thanks for the reminder. Fixed and applied.

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

[Xen-devel] [ovmf test] 125145: all pass - PUSHED

[osstest service owner]

flight 125145 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125145/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 0c6f94dae5e3ca57fe6093ce2fa4d78fdd061857
baseline version:
 ovmf 79b10d4ce4f08aab4b9548fabc4542ca78a96247

Last test of basis   125143  2018-07-12 22:10:39 Z0 days
Testing same since   125145  2018-07-13 02:40:44 Z0 days1 attempts


People who touched revisions under test:
  Star Zeng 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   79b10d4ce4..0c6f94dae5  0c6f94dae5e3ca57fe6093ce2fa4d78fdd061857 -> 
xen-tested-master

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