[Xen-devel] [xen-4.8-testing test] 117586: regressions - trouble: broken/fail/pass

[osstest service owner]

flight 117586 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117586/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm   broken
 test-amd64-amd64-livepatch   broken
 test-amd64-i386-rumprun-i386 broken
 test-amd64-amd64-xl-qemuu-win7-amd64 broken
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm  broken
 test-amd64-i386-xl-xsm   broken
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 4 host-install(4) broken 
REGR. vs. 117144
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 4 host-install(4) broken REGR. 
vs. 117144
 test-amd64-amd64-livepatch4 host-install(4)broken REGR. vs. 117144
 test-amd64-i386-rumprun-i386  4 host-install(4)broken REGR. vs. 117144
 test-amd64-amd64-xl-qemuu-win7-amd64 4 host-install(4) broken REGR. vs. 117144
 build-amd64  broken  in 117533
 build-armhf  broken  in 117533
 build-i386-prev  broken  in 117533
 build-i386   broken  in 117533
 build-armhf-pvopsbroken  in 117533
 build-armhf-xsm  broken  in 117533
 build-amd644 host-install(4) broken in 117533 REGR. vs. 117144
 build-i386 4 host-install(4) broken in 117533 REGR. vs. 117144
 build-armhf-pvops  4 host-install(4) broken in 117533 REGR. vs. 117144
 build-i386-prev4 host-install(4) broken in 117533 REGR. vs. 117144
 build-armhf4 host-install(4) broken in 117533 REGR. vs. 117144
 build-armhf-xsm4 host-install(4) broken in 117533 REGR. vs. 117144
 test-xtf-amd64-amd64-2 49 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 117144

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-xsm4 host-install(4)  broken pass in 117533
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail 
pass in 117533

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemut-win10-i386  1 build-check(1)blocked in 117533 n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked in 117533 n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked in 117533 n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)blocked in 117533 n/a
 test-amd64-amd64-xl-qemut-win10-i386  1 build-check(1)   blocked in 117533 n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)  blocked in 117533 n/a
 test-amd64-i386-livepatch 1 build-check(1)   blocked in 117533 n/a
 build-armhf-libvirt   1 build-check(1)   blocked in 117533 n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1)   blocked in 117533 n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked in 117533 n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1)   blocked in 117533 n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked in 117533 n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 
117533 n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked in 117533 n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1) blocked in 117533 n/a
 test-xtf-amd64-amd64-41 build-check(1)   blocked in 117533 n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked in 117533 n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)  blocked in 117533 n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)   blocked in 117533 n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 
117533 n/a
 build-amd64-libvirt   1 build-check(1)   blocked in 117533 n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked in 117533 
n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked in 117533 n/a
 test-xtf-amd64-amd64-51 build-check(1)   blocked in 117533 n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked in 117533 n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)blocked in 117533 n/a
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)blocked in 117533 n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked in 117533 n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1)   blocked in 117533 n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked in 117533 n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)blocked in 117533 n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)blocked in 117533 n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked in 117533 n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked in 117533 n/a
 

Re: [Xen-devel] [RFC XEN PATCH v4 03/41] hvmloader/util: do not compare characters after '\0' in strncmp

[Chao Peng]

On Thu, 2017-12-07 at 18:09 +0800, Haozhong Zhang wrote:
> ... to make its behavior the same as C standard (e.g., C99 and C11).
> 
> Signed-off-by: Haozhong Zhang 
> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
>  tools/firmware/hvmloader/util.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/tools/firmware/hvmloader/util.c
> b/tools/firmware/hvmloader/util.c
> index 0c3f2d24cd..76a61ee052 100644
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -141,9 +141,16 @@ int strcmp(const char *cs, const char *ct)
>  int strncmp(const char *s1, const char *s2, uint32_t n)
>  {
>  uint32_t ctr;
> +
>  for (ctr = 0; ctr < n; ctr++)
> +{
>  if (s1[ctr] != s2[ctr])
>  return (int)(s1[ctr] - s2[ctr]);
> +
> +if (!s1[ctr])

Coding style, but, the original code above has issue too.
Besides this, Reviewed-by: Chao Peng 

> +break;
> +}
> +
>  return 0;
>  }
>  

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

Re: [Xen-devel] [RFC XEN PATCH v4 02/41] x86_64/mm: avoid cleaning the unmapped frame table

[Chao Peng]

On Thu, 2017-12-07 at 18:09 +0800, Haozhong Zhang wrote:
> cleanup_frame_table() initializes the entire newly added frame table
> to all -1's. If it's called after extend_frame_table() failed to map
> the entire frame table, the initialization will hit a page fault.
> 
> Move the cleanup of partially mapped frametable to
> extend_frame_table(),
> which has enough knowledge of the mapping status.
> 
> Signed-off-by: Haozhong Zhang 
> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> 
> @Chao: I don't modify this patch per your comment, because I feel it's
> better to handle the errors locally in each function (rather than
> handle
> all of them in the top-level), which will make each function easier to
> use.

I don't insist on this, to me this is kind of flavor choice.

Chao

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

Re: [Xen-devel] [RFC XEN PATCH v4 01/41] x86_64/mm: fix the PDX group check in mem_hotadd_check()

[Chao Peng]

On Thu, 2017-12-07 at 18:09 +0800, Haozhong Zhang wrote:
> The current check refuses the hot-plugged memory that falls in one
> unused PDX group, which should be allowed.
> 
Reviewed-by: Chao Peng 

> Signed-off-by: Haozhong Zhang 
> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> ---
>  xen/arch/x86/x86_64/mm.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
> index 9b37da6698..839038b6c3 100644
> --- a/xen/arch/x86/x86_64/mm.c
> +++ b/xen/arch/x86/x86_64/mm.c
> @@ -1295,12 +1295,8 @@ static int mem_hotadd_check(unsigned long spfn,
> unsigned long epfn)
>  return 0;
>  
>  /* Make sure the new range is not present now */
> -sidx = ((pfn_to_pdx(spfn) + PDX_GROUP_COUNT - 1)  &
> ~(PDX_GROUP_COUNT - 1))
> -/ PDX_GROUP_COUNT;
> +sidx = (pfn_to_pdx(spfn) & ~(PDX_GROUP_COUNT - 1)) /
> PDX_GROUP_COUNT;
>  eidx = (pfn_to_pdx(epfn - 1) & ~(PDX_GROUP_COUNT - 1)) /
> PDX_GROUP_COUNT;
> -if (sidx >= eidx)
> -return 0;
> -
>  s = find_next_zero_bit(pdx_group_valid, eidx, sidx);
>  if ( s > eidx )
>  return 0;

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

Re: [Xen-devel] [PATCH v4 0/4] x86/cpuid: enable new cpu features

[Yang Zhong]

On Wed, Jan 03, 2018 at 01:38:13AM -0700, Jan Beulich wrote:
> >>> On 03.01.18 at 09:26,  wrote:
> > The new cpu features in intel icelake: AVX512VBMI2/GFNI/VAES/
> > AVX512VNNI/AVX512BITALG/VPCLMULQDQ.
> 
> Could you please play by patch submission rules: They are to be
> sent _to_ the list, with maintainers (and perhaps other interested
> parties) _cc_-ed.
> 
  Thanks Jan, i will be care of this in next version. thanks! Yang. 

> Jan

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

Re: [Xen-devel] [PATCH v4 4/4] x86/cpuid: Enable new SSE/AVX/AVX512 cpu features

[Yang Zhong]

On Wed, Jan 03, 2018 at 01:46:09AM -0700, Jan Beulich wrote:

> > --- a/xen/include/public/arch-x86/cpufeatureset.h
> > +++ b/xen/include/public/arch-x86/cpufeatureset.h
> > @@ -228,6 +228,12 @@ XEN_CPUFEATURE(AVX512VBMI,6*32+ 1) /*A  AVX-512 
> > Vector Byte Manipulation Ins
> >  XEN_CPUFEATURE(UMIP,  6*32+ 2) /*S  User Mode Instruction 
> > Prevention */
> >  XEN_CPUFEATURE(PKU,   6*32+ 3) /*H  Protection Keys for Userspace 
> > */
> >  XEN_CPUFEATURE(OSPKE, 6*32+ 4) /*!  OS Protection Keys Enable */
> > +XEN_CPUFEATURE(AVX512_VBMI2,  6*32+ 6) /*A  addition AVX-512 VBMI 
> > Instructions */
> 
> "additional"?
  Jan, i will change "addition" to "additional", thanks! Yang.
 
> > --- a/xen/tools/gen-cpuid.py
> > +++ b/xen/tools/gen-cpuid.py
> > @@ -255,7 +255,8 @@ def crunch_numbers(state):
> >  # top of AVX512F
> >  AVX512F: [AVX512DQ, AVX512IFMA, AVX512PF, AVX512ER, AVX512CD,
> >AVX512BW, AVX512VL, AVX512VBMI, AVX512_4VNNIW,
> > -  AVX512_4FMAPS, AVX512_VPOPCNTDQ],
> > +  AVX512_4FMAPS, AVX512_VPOPCNTDQ, AVX512_VBMI2,
> > +  AVX512_VNNI, AVX512_BITALG],
> >  }
> 
> This is insufficient afaict: VAES and VPCLMULQDQ ought to be
> made dependent upon AVX.

  Thanks Jan, i will do below changes for this.  Yang.

-AVX: [FMA, FMA4, F16C, AVX2, XOP],
+AVX: [FMA, FMA4, F16C, AVX2, XOP, VAES, VPCLMULQDQ],

> 
> Jan

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

[Xen-devel] [linux-linus test] 117585: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-intel broken
 test-amd64-amd64-libvirt broken
 test-amd64-i386-xl-raw   broken
 test-amd64-i386-xl-qemuu-win7-amd64 broken
 test-armhf-armhf-xl  broken
 test-amd64-i386-xl-qemuu-win7-amd64  4 host-install(4) broken REGR. vs. 115643
 test-amd64-amd64-libvirt  4 host-install(4)broken REGR. vs. 115643
 test-amd64-i386-xl-raw4 host-install(4)broken REGR. vs. 115643
 test-amd64-amd64-qemuu-nested-intel  4 host-install(4) broken REGR. vs. 115643
 build-i386-pvops broken  in 117544
 build-armhf-xsm  broken  in 117544
 build-i386-pvops   4 host-install(4) broken in 117544 REGR. vs. 115643
 build-armhf-xsm4 host-install(4) broken in 117544 REGR. vs. 115643
 build-amd64-pvops 6 kernel-build   fail in 117544 REGR. vs. 115643

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl   4 host-install(4)  broken pass in 117544
 test-armhf-armhf-examine  6 xen-install  fail in 117544 pass in 117585

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked in 117544 n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)  blocked in 117544 n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked in 117544 n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked in 117544 n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked in 117544 n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked in 117544 n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked in 117544 n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 
117544 n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1) blocked in 117544 n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)blocked in 117544 n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked in 117544 n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
in 117544 n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked in 117544 n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)blocked in 117544 n/a
 test-amd64-i386-xl1 build-check(1)   blocked in 117544 n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)blocked in 117544 n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1) blocked in 117544 n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked in 117544 n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked in 117544 n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked in 117544 n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)blocked in 117544 n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)blocked in 117544 n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)   blocked in 117544 n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked in 117544 n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked in 117544 n/a
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)blocked in 117544 n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked in 117544 n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked in 117544 n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked in 117544 n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 
117544 n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)blocked in 117544 n/a
 test-amd64-amd64-examine  1 build-check(1)   blocked in 117544 n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)   blocked in 117544 n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)blocked in 117544 n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked in 117544 n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked in 117544 n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1)   blocked in 117544 n/a
 test-amd64-amd64-xl-qemut-win10-i386  1 build-check(1)   blocked in 117544 n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked in 
117544 n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1) blocked in 117544 n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1) blocked in 117544 
n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked in 117544 n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked in 117544 n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 

Re: [Xen-devel] [PATCH v6.5 15/26] x86/feature: Definitions for Indirect Branch Controls

[Anthony Liguori]

On Wed, Jan 3, 2018 at 5:14 PM, Doug Goldstein  wrote:
> On 1/3/18 6:15 PM, Andrew Cooper wrote:
>> Contemporary processors are gaining Indirect Branch Controls via microcode
>> updates.  Intel are introducing one bit to indicate IBRS and IBPB support, 
>> and
>> a second bit for STIBP.  AMD are introducing IPBP only, so enumerate it with 
>> a
>> separate bit.
>
> s/IPBP/IBPB/ no? Still getting caught up here so I could certainly be wrong.

IBPB is indeed right.

Regards,

Anthony Liguori

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

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

Re: [Xen-devel] [PATCH v6.5 15/26] x86/feature: Definitions for Indirect Branch Controls

[Andrew Cooper]

On 04/01/2018 01:14, Doug Goldstein wrote:
> On 1/3/18 6:15 PM, Andrew Cooper wrote:
>> Contemporary processors are gaining Indirect Branch Controls via microcode
>> updates.  Intel are introducing one bit to indicate IBRS and IBPB support, 
>> and
>> a second bit for STIBP.  AMD are introducing IPBP only, so enumerate it with 
>> a
>> separate bit.
> s/IPBP/IBPB/ no? Still getting caught up here so I could certainly be wrong.

Correct.  I'll add this to the fixup list.

I've lost count of how many times I've mis-typed or mixed these two
initialisms up :(

~Andrew



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v6.5 15/26] x86/feature: Definitions for Indirect Branch Controls

[Doug Goldstein]

On 1/3/18 6:15 PM, Andrew Cooper wrote:
> Contemporary processors are gaining Indirect Branch Controls via microcode
> updates.  Intel are introducing one bit to indicate IBRS and IBPB support, and
> a second bit for STIBP.  AMD are introducing IPBP only, so enumerate it with a
> separate bit.

s/IPBP/IBPB/ no? Still getting caught up here so I could certainly be wrong.

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v6.5 21/26] x86/entry: Use MSR_SPEC_CTRL at each entry/exit point

[Andrew Cooper]

Set or clear IBRS in Xen context, and appropriate guest values in guest
context.  See the documentation in asm-x86/spec_ctrl_asm.h for details.

Two semi-unrelated bugfixes are that various asm_defn.h macros have a hidden
dependency on PAGE_SIZE, which results in an assembler error if used in a
.macro definition.  Secondly, _ASM_MK_NOP() needs a separator at the end,
rather than relying on its calling context for separation.

Signed-off-by: Andrew Cooper 
---
v3:
 * Basically rewritten from scratch
v4:
 * Use STACK* macrocs
 * Drop semicolons
 * Fix several offset bugs
 * Introduce init_shadow_spec_ctrl_state() rather than opencoding it for the
   BSP and APs
 * Rebase over AMD changes
---
 xen/arch/x86/hvm/svm/entry.S|   8 +-
 xen/arch/x86/hvm/vmx/entry.S|  11 ++
 xen/arch/x86/setup.c|   1 +
 xen/arch/x86/smpboot.c  |   2 +
 xen/arch/x86/x86_64/asm-offsets.c   |   6 +
 xen/arch/x86/x86_64/compat/entry.S  |  12 ++
 xen/arch/x86/x86_64/entry.S |  33 ++
 xen/include/asm-x86/asm_defns.h |   3 +
 xen/include/asm-x86/current.h   |   6 +
 xen/include/asm-x86/nops.h  |   8 +-
 xen/include/asm-x86/spec_ctrl.h |   9 ++
 xen/include/asm-x86/spec_ctrl_asm.h | 230 
 12 files changed, 327 insertions(+), 2 deletions(-)
 create mode 100644 xen/include/asm-x86/spec_ctrl_asm.h

diff --git a/xen/arch/x86/hvm/svm/entry.S b/xen/arch/x86/hvm/svm/entry.S
index df86da0..fb1048b 100644
--- a/xen/arch/x86/hvm/svm/entry.S
+++ b/xen/arch/x86/hvm/svm/entry.S
@@ -79,6 +79,9 @@ UNLIKELY_END(svm_trace)
 or   $X86_EFLAGS_MBS,%rax
 mov  %rax,VMCB_rflags(%rcx)
 
+/* WARNING! `ret`, `call *`, `jmp *` not safe beyond this point. */
+SPEC_CTRL_EXIT_TO_GUEST /* Req: b=curr %rsp=regs/cpuinfo, Clob: acd */
+
 pop  %r15
 pop  %r14
 pop  %r13
@@ -101,8 +104,11 @@ UNLIKELY_END(svm_trace)
 SAVE_ALL
 
 GET_CURRENT(bx)
-mov  VCPU_svm_vmcb(%rbx),%rcx
 
+SPEC_CTRL_ENTRY_FROM_VMEXIT /* Req: b=curr %rsp=regs/cpuinfo, Clob: 
acd */
+/* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */
+
+mov  VCPU_svm_vmcb(%rbx),%rcx
 movb $0,VCPU_svm_vmcb_in_sync(%rbx)
 mov  VMCB_rax(%rcx),%rax
 mov  %rax,UREGS_rax(%rsp)
diff --git a/xen/arch/x86/hvm/vmx/entry.S b/xen/arch/x86/hvm/vmx/entry.S
index b2f98be..21e959f 100644
--- a/xen/arch/x86/hvm/vmx/entry.S
+++ b/xen/arch/x86/hvm/vmx/entry.S
@@ -38,6 +38,9 @@ ENTRY(vmx_asm_vmexit_handler)
 movb $1,VCPU_vmx_launched(%rbx)
 mov  %rax,VCPU_hvm_guest_cr2(%rbx)
 
+SPEC_CTRL_ENTRY_FROM_VMEXIT /* Req: b=curr %rsp=regs/cpuinfo, Clob: 
acd */
+/* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */
+
 mov  %rsp,%rdi
 call vmx_vmexit_handler
 
@@ -68,6 +71,10 @@ UNLIKELY_END(realmode)
 call vmx_vmenter_helper
 test %al, %al
 jz .Lvmx_vmentry_restart
+
+/* WARNING! `ret`, `call *`, `jmp *` not safe beyond this point. */
+SPEC_CTRL_EXIT_TO_GUEST /* Req: b=curr %rsp=regs/cpuinfo, Clob: acd */
+
 mov  VCPU_hvm_guest_cr2(%rbx),%rax
 
 pop  %r15
@@ -99,6 +106,10 @@ UNLIKELY_END(realmode)
 .Lvmx_vmentry_fail:
 sti
 SAVE_ALL
+
+SPEC_CTRL_ENTRY_FROM_PV /* Req: %rsp=regs/cpuinfo Clob: acd */
+/* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */
+
 call vmx_vmentry_failure
 BUG  /* vmx_vmentry_failure() shouldn't return. */
 
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 470427b..b2aa281 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -668,6 +668,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 set_processor_id(0);
 set_current(INVALID_VCPU); /* debug sanity. */
 idle_vcpu[0] = current;
+init_shadow_spec_ctrl_state();
 
 percpu_init_areas();
 
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 7b97ff8..a695d12 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -308,6 +309,7 @@ void start_secondary(void *unused)
 set_current(idle_vcpu[cpu]);
 this_cpu(curr_vcpu) = idle_vcpu[cpu];
 rdmsrl(MSR_EFER, this_cpu(efer));
+init_shadow_spec_ctrl_state();
 
 /*
  * Just as during early bootstrap, it is convenient here to disable
diff --git a/xen/arch/x86/x86_64/asm-offsets.c 
b/xen/arch/x86/x86_64/asm-offsets.c
index e136af6..7d36185 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -88,6 +88,7 @@ void __dummy__(void)
 OFFSET(VCPU_kernel_ss, struct vcpu, arch.pv_vcpu.kernel_ss);
 OFFSET(VCPU_iopl, struct vcpu, arch.pv_vcpu.iopl);
 OFFSET(VCPU_guest_context_flags, struct vcpu, arch.vgc_flags);
+OFFSET(VCPU_arch_msr, struct vcpu, 

[Xen-devel] [PATCH v6.5 15/26] x86/feature: Definitions for Indirect Branch Controls

[Andrew Cooper]

Contemporary processors are gaining Indirect Branch Controls via microcode
updates.  Intel are introducing one bit to indicate IBRS and IBPB support, and
a second bit for STIBP.  AMD are introducing IPBP only, so enumerate it with a
separate bit.

Furthermore, depending on compiler and microcode availability, we may want to
run Xen with IBRS set, or clear.

To use these facilities, we synthesise separate IBRS and IBPB bits for
internal use.  A lot of infrastructure is required before these features are
safe to offer to guests.

Signed-off-by: Andrew Cooper 
---
v4:
 * Update for AMD, drop acks/reviews.
---
 tools/libxl/libxl_cpuid.c   |  3 +++
 tools/misc/xen-cpuid.c  | 12 ++--
 xen/arch/x86/spec_ctrl.c| 17 +
 xen/include/asm-x86/cpufeatures.h   |  3 +++
 xen/include/asm-x86/msr-index.h | 11 +++
 xen/include/public/arch-x86/cpufeatureset.h |  3 +++
 xen/tools/gen-cpuid.py  |  5 +
 7 files changed, 52 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c
index e692b61..81ba961 100644
--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -202,6 +202,8 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list 
*cpuid, const char* str)
 
 {"avx512-4vnniw",0x0007,  0, CPUID_REG_EDX,  2,  1},
 {"avx512-4fmaps",0x0007,  0, CPUID_REG_EDX,  3,  1},
+{"ibrsb",0x0007,  0, CPUID_REG_EDX, 26,  1},
+{"stibp",0x0007,  0, CPUID_REG_EDX, 27,  1},
 
 {"lahfsahf", 0x8001, NA, CPUID_REG_ECX,  0,  1},
 {"cmplegacy",0x8001, NA, CPUID_REG_ECX,  1,  1},
@@ -239,6 +241,7 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list 
*cpuid, const char* str)
 
 {"invtsc",   0x8007, NA, CPUID_REG_EDX,  8,  1},
 
+{"ibpb", 0x8008, NA, CPUID_REG_EBX, 12,  1},
 {"nc",   0x8008, NA, CPUID_REG_ECX,  0,  8},
 {"apicidsize",   0x8008, NA, CPUID_REG_ECX, 12,  4},
 
diff --git a/tools/misc/xen-cpuid.c b/tools/misc/xen-cpuid.c
index 0831f75..8c3dac0 100644
--- a/tools/misc/xen-cpuid.c
+++ b/tools/misc/xen-cpuid.c
@@ -149,7 +149,11 @@ static const char *str_e8b[32] =
 {
 [ 0] = "clzero",
 
-[1 ... 31] = "REZ",
+[1 ... 11] = "REZ",
+
+[12] = "ibpb",
+
+[13 ... 31] = "REZ",
 };
 
 static const char *str_7d0[32] =
@@ -158,7 +162,11 @@ static const char *str_7d0[32] =
 
 [ 2] = "avx512_4vnniw", [ 3] = "avx512_4fmaps",
 
-[4 ... 31] = "REZ",
+[4 ... 25] = "REZ",
+
+[26] = "ibrsb", [27] = "stibp",
+
+[28 ... 31] = "REZ",
 };
 
 static struct {
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 8301648..d9ace2d 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -67,8 +67,25 @@ custom_param("bti", parse_bti);
 
 static void __init print_details(enum ind_thunk thunk)
 {
+unsigned int _7d0 = 0, e8b = 0, tmp;
+
+/* Collect diagnostics about available mitigations. */
+if ( boot_cpu_data.cpuid_level >= 7 )
+cpuid_count(7, 0, , , , &_7d0);
+if ( boot_cpu_data.extended_cpuid_level >= 0x8008 )
+cpuid(0x8008, , , , );
+
 printk(XENLOG_DEBUG "Speculative mitigation facilities:\n");
 
+/* Hardware features which pertain to speculative mitigations. */
+if ( (_7d0 & (cpufeat_mask(X86_FEATURE_IBRSB) |
+  cpufeat_mask(X86_FEATURE_STIBP))) ||
+ (e8b & cpufeat_mask(X86_FEATURE_IBPB)) )
+printk(XENLOG_DEBUG "  Hardware features:%s%s%s\n",
+   (_7d0 & cpufeat_mask(X86_FEATURE_IBRSB)) ? " IBRS/IBPB" : "",
+   (_7d0 & cpufeat_mask(X86_FEATURE_STIBP)) ? " STIBP" : "",
+   (e8b  & cpufeat_mask(X86_FEATURE_IBPB))  ? " IBPB"  : "");
+
 /* Compiled-in support which pertains to BTI mitigations. */
 if ( IS_ENABLED(CONFIG_INDIRECT_THUNK) )
 printk(XENLOG_DEBUG "  Compiled-in support: INDIRECT_THUNK\n");
diff --git a/xen/include/asm-x86/cpufeatures.h 
b/xen/include/asm-x86/cpufeatures.h
index ba1771b..dd2388f 100644
--- a/xen/include/asm-x86/cpufeatures.h
+++ b/xen/include/asm-x86/cpufeatures.h
@@ -25,3 +25,6 @@ XEN_CPUFEATURE(XEN_SMAP,(FSCAPINTS+0)*32+11) /* SMAP 
gets used by Xen it
 XEN_CPUFEATURE(LFENCE_DISPATCH, (FSCAPINTS+0)*32+12) /* lfence set as Dispatch 
Serialising */
 XEN_CPUFEATURE(IND_THUNK_LFENCE,(FSCAPINTS+0)*32+13) /* Use IND_THUNK_LFENCE */
 XEN_CPUFEATURE(IND_THUNK_JMP,   (FSCAPINTS+0)*32+14) /* Use IND_THUNK_JMP */
+XEN_CPUFEATURE(XEN_IBPB,(FSCAPINTS+0)*32+15) /* IBRSB || IBPB */
+XEN_CPUFEATURE(XEN_IBRS_SET,(FSCAPINTS+0)*32+16) /* IBRSB && IRBS set in 
Xen */
+XEN_CPUFEATURE(XEN_IBRS_CLEAR,  (FSCAPINTS+0)*32+17) /* IBRSB && IBRS clear in 
Xen */
diff --git a/xen/include/asm-x86/msr-index.h b/xen/include/asm-x86/msr-index.h
index 56f5359..3a73013 

[Xen-devel] [PATCH v6.5 20/26] x86: Protect unaware domains from meddling hyperthreads

[Andrew Cooper]

Signed-off-by: Andrew Cooper 
---
v3:
 * Spelling corrections
v4:
 * Rebase over AMD changes
v6:
 * Fix cpuid_policy_updated() to not corrupt vp->spec_ctrl.host on migrate, or
   on older versions of Xen where feature flags start as 0 rather than the
   domain maximum.
---
 xen/arch/x86/domain.c| 19 +++
 xen/arch/x86/msr.c   | 15 ++-
 xen/include/asm-x86/cpufeature.h |  3 +++
 3 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index d383489..698346e 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2027,6 +2027,25 @@ int domain_relinquish_resources(struct domain *d)
  */
 void cpuid_policy_updated(struct vcpu *v)
 {
+const struct cpuid_policy *cp = v->domain->arch.cpuid;
+struct msr_vcpu_policy *vp = v->arch.msr;
+
+/*
+ * For guests which know about IBRS but are not told about STIBP running
+ * on hardware supporting hyperthreading, the guest doesn't know to
+ * protect itself fully.  (Such a guest won't be permitted direct access
+ * to the MSR.)  Have Xen fill in the gaps, so an unaware guest can't be
+ * interfered with by a meddling guest on an adjacent hyperthread.
+ */
+if ( cp->feat.ibrsb )
+{
+if ( !cp->feat.stibp && cpu_has_stibp &&
+ !(vp->spec_ctrl.guest & (SPEC_CTRL_IBRS | SPEC_CTRL_STIBP)) )
+vp->spec_ctrl.host = SPEC_CTRL_STIBP;
+else
+vp->spec_ctrl.host = vp->spec_ctrl.guest;
+}
+
 if ( is_hvm_vcpu(v) )
 hvm_cpuid_policy_changed(v);
 }
diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
index 697cc6e..2d99c64 100644
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -181,7 +181,20 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
  (cp->feat.stibp ? SPEC_CTRL_STIBP : 0)) )
 goto gp_fault; /* Rsvd bit set? */
 vp->spec_ctrl.guest = val;
-vp->spec_ctrl.host  = val;
+
+/*
+ * For guests which are not told about STIBP, running on hardware
+ * supporting hyperthreading, the guest doesn't know to protect itself
+ * fully.  (Such a guest won't be permitted direct access to the MSR.)
+ * When IBRS is not in force, have Xen fill in the gaps, so an unaware
+ * guest can't be interfered with by a meddling guest on an adjacent
+ * hyperthread.
+ */
+if ( !cp->feat.stibp && cpu_has_stibp &&
+ !(val & (SPEC_CTRL_IBRS | SPEC_CTRL_STIBP)) )
+vp->spec_ctrl.host = SPEC_CTRL_STIBP;
+else
+vp->spec_ctrl.host = val;
 break;
 
 case MSR_PRED_CMD:
diff --git a/xen/include/asm-x86/cpufeature.h b/xen/include/asm-x86/cpufeature.h
index adc333f..988a834 100644
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -100,6 +100,9 @@
 /* CPUID level 0x8007.edx */
 #define cpu_has_itscboot_cpu_has(X86_FEATURE_ITSC)
 
+/* CPUID level 0x0007:0.edx */
+#define cpu_has_stibp   boot_cpu_has(X86_FEATURE_STIBP)
+
 /* Synthesized. */
 #define cpu_has_arch_perfmonboot_cpu_has(X86_FEATURE_ARCH_PERFMON)
 #define cpu_has_cpuid_faulting  boot_cpu_has(X86_FEATURE_CPUID_FAULTING)
-- 
2.1.4


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

[Xen-devel] [PATCH v6.5 14/26] x86: Introduce alternative indirect thunks

[Andrew Cooper]

Depending on hardware and microcode availability, we will want to replace
IND_THUNK_REPOLINE with other implementations.

For AMD hardware, choose IND_THUNK_LFENCE in preference to retpoline if lfence
is known to be (or was successfully made) dispatch serialising.

Signed-off-by: Andrew Cooper 
---
v4:
 * New
v5:
 * Introduce a command line option
---
 docs/misc/xen-command-line.markdown | 14 +++
 xen/arch/x86/indirect_thunk.S   | 13 ++-
 xen/arch/x86/spec_ctrl.c| 73 -
 xen/include/asm-x86/cpufeatures.h   |  2 +
 4 files changed, 99 insertions(+), 3 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 781110d..c9dbfbb 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -245,6 +245,20 @@ and not running softirqs. Reduce this if softirqs are not 
being run frequently
 enough. Setting this to a high value may cause boot failure, particularly if
 the NMI watchdog is also enabled.
 
+### bti (x86)
+> `= List of [ thunk=retpoline|lfence|plain ]`
+
+Branch Target Injection controls.  By default, Xen will pick the most
+appropriate BTI mitigations based on compiled in support, loaded microcode,
+and hardware details.
+
+**WARNING: Any use of this option inhibits all heristcs.  Use with extreme 
care.**
+
+If Xen was compiled with INDIRECT_THUNK support, `thunk=` can be used to
+select which of the thunks gets patched into the `__x86.indirect_thunk.%reg`
+locations.  The default thunk is `retpoline`, with the alternatives being
+`plain` (a `jmp *%reg` gadget), and `lfence` (an `lfence; jmp *%reg` gadget).
+
 ### xenheap\_megabytes (arm32)
 > `= `
 
diff --git a/xen/arch/x86/indirect_thunk.S b/xen/arch/x86/indirect_thunk.S
index 4fef1c8..542974a 100644
--- a/xen/arch/x86/indirect_thunk.S
+++ b/xen/arch/x86/indirect_thunk.S
@@ -10,6 +10,15 @@
 ret
 .endm
 
+.macro IND_THUNK_LFENCE reg:req
+lfence
+jmp *\reg
+.endm
+
+.macro IND_THUNK_JMP reg:req
+jmp *\reg
+.endm
+
 /*
  * Build the __x86.indirect_thunk.* symbols.  Execution lands on an
  * alternative patch point which implements one of the above THUNK_*'s
@@ -18,7 +27,9 @@
 .section .text.__x86.indirect_thunk.\name, "ax", @progbits
 
 ENTRY(__x86.indirect_thunk.\name)
-IND_THUNK_RETPOLINE \reg
+ALTERNATIVE_2 __stringify(IND_THUNK_RETPOLINE \reg),  \
+__stringify(IND_THUNK_LFENCE \reg), X86_FEATURE_IND_THUNK_LFENCE, \
+__stringify(IND_THUNK_JMP \reg),X86_FEATURE_IND_THUNK_JMP
 .endm
 
 /* Instantiate GEN_INDIRECT_THUNK for each register except %rsp. */
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index ffee909..8301648 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -16,6 +16,7 @@
  *
  * Copyright (c) 2017 Citrix Systems Ltd.
  */
+#include 
 #include 
 #include 
 
@@ -27,7 +28,42 @@ enum ind_thunk {
 THUNK_NONE,/* Missing compiler support for thunks. */
 
 THUNK_RETPOLINE,
-};
+THUNK_LFENCE,
+THUNK_JMP,
+} opt_thunk __initdata = THUNK_DEFAULT;
+
+static int __init parse_bti(const char *s)
+{
+const char *ss;
+int rc = 0;
+
+do {
+ss = strchr(s, ',');
+if ( !ss )
+ss = strchr(s, '\0');
+
+if ( !strncmp(s, "thunk=", 6) )
+{
+s += 6;
+
+if ( !strncmp(s, "retpoline", ss - s) )
+opt_thunk = THUNK_RETPOLINE;
+else if ( !strncmp(s, "lfence", ss - s) )
+opt_thunk = THUNK_LFENCE;
+else if ( !strncmp(s, "jmp", ss - s) )
+opt_thunk = THUNK_JMP;
+else
+rc = -EINVAL;
+}
+else
+rc = -EINVAL;
+
+s = ss + 1;
+} while ( *ss );
+
+return rc;
+}
+custom_param("bti", parse_bti);
 
 static void __init print_details(enum ind_thunk thunk)
 {
@@ -40,7 +76,9 @@ static void __init print_details(enum ind_thunk thunk)
 printk(XENLOG_INFO
"BTI mitigations: Thunk %s\n",
thunk == THUNK_NONE  ? "N/A" :
-   thunk == THUNK_RETPOLINE ? "RETPOLINE" : "?");
+   thunk == THUNK_RETPOLINE ? "RETPOLINE" :
+   thunk == THUNK_LFENCE? "LFENCE" :
+   thunk == THUNK_JMP   ? "JMP" : "?");
 }
 
 void __init init_speculation_mitigations(void)
@@ -48,6 +86,31 @@ void __init init_speculation_mitigations(void)
 enum ind_thunk thunk = THUNK_DEFAULT;
 
 /*
+ * Has the user specified any custom BTI mitigations?  If so, follow their
+ * instructions exactly and disable all heuristics.
+ */
+if ( opt_thunk != THUNK_DEFAULT )
+{
+thunk = opt_thunk;
+}
+else
+{
+/*
+ * Evaluate the safest Branch Target Injection mitigations to use.
+ * First, begin with compiler-aided mitigations.
+ */
+if ( 

[Xen-devel] [PATCH v6.5 12/26] x86/boot: Report details of speculative mitigations

[Andrew Cooper]

Nothing very interesting at the moment, but the logic will grow as new
mitigations are added.

Signed-off-by: Andrew Cooper 
---
v3:
 * New
v4:
 * Drop the else-clause printk
 * Rebase over AMD additions
---
 xen/arch/x86/Makefile   |  1 +
 xen/arch/x86/setup.c|  3 ++
 xen/arch/x86/spec_ctrl.c| 75 +
 xen/include/asm-x86/spec_ctrl.h | 35 +++
 4 files changed, 114 insertions(+)
 create mode 100644 xen/arch/x86/spec_ctrl.c
 create mode 100644 xen/include/asm-x86/spec_ctrl.h

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 433233c..90ab93d 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -57,6 +57,7 @@ obj-y += setup.o
 obj-y += shutdown.o
 obj-y += smp.o
 obj-y += smpboot.o
+obj-y += spec_ctrl.o
 obj-y += srat.o
 obj-y += string.o
 obj-y += sysctl.o
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 2e10c6b..470427b 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -51,6 +51,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* opt_nosmp: If true, secondary processors are ignored. */
 static bool __initdata opt_nosmp;
@@ -1502,6 +1503,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 if ( cpu_has_fsgsbase )
 set_in_cr4(X86_CR4_FSGSBASE);
 
+init_speculation_mitigations();
+
 init_idle_domain();
 
 this_cpu(stubs.addr) = alloc_stub_page(smp_processor_id(),
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
new file mode 100644
index 000..ffee909
--- /dev/null
+++ b/xen/arch/x86/spec_ctrl.c
@@ -0,0 +1,75 @@
+/**
+ * arch/x86/spec_ctrl.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; If not, see .
+ *
+ * Copyright (c) 2017 Citrix Systems Ltd.
+ */
+#include 
+#include 
+
+#include 
+#include 
+
+enum ind_thunk {
+THUNK_DEFAULT, /* Decide which thunk to use at boot time. */
+THUNK_NONE,/* Missing compiler support for thunks. */
+
+THUNK_RETPOLINE,
+};
+
+static void __init print_details(enum ind_thunk thunk)
+{
+printk(XENLOG_DEBUG "Speculative mitigation facilities:\n");
+
+/* Compiled-in support which pertains to BTI mitigations. */
+if ( IS_ENABLED(CONFIG_INDIRECT_THUNK) )
+printk(XENLOG_DEBUG "  Compiled-in support: INDIRECT_THUNK\n");
+
+printk(XENLOG_INFO
+   "BTI mitigations: Thunk %s\n",
+   thunk == THUNK_NONE  ? "N/A" :
+   thunk == THUNK_RETPOLINE ? "RETPOLINE" : "?");
+}
+
+void __init init_speculation_mitigations(void)
+{
+enum ind_thunk thunk = THUNK_DEFAULT;
+
+/*
+ * Supplimentary minor adjustments.  Without compiler support, there are
+ * no thunks.
+ */
+if ( !IS_ENABLED(CONFIG_INDIRECT_THUNK) )
+thunk = THUNK_NONE;
+
+/*
+ * If there are still no thunk preferences, the compiled default is
+ * actually retpoline, and it is better than nothing.
+ */
+if ( thunk == THUNK_DEFAULT )
+thunk = THUNK_RETPOLINE;
+
+print_details(thunk);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-x86/spec_ctrl.h b/xen/include/asm-x86/spec_ctrl.h
new file mode 100644
index 000..d0b44f6
--- /dev/null
+++ b/xen/include/asm-x86/spec_ctrl.h
@@ -0,0 +1,35 @@
+/**
+ * include/asm-x86/spec_ctrl.h
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; If not, see .
+ *
+ * Copyright (c) 2017 Citrix Systems Ltd.
+ */
+
+#ifndef __X86_SPEC_CTRL_H__
+#define __X86_SPEC_CTRL_H__
+
+void init_speculation_mitigations(void);
+
+#endif 

[Xen-devel] [PATCH v6.5 11/26] x86: Support indirect thunks from assembly code

[Andrew Cooper]

Introduce CALL_THUNK and JMP_THUNK which either degrade to a normal indirect
branch, or dispatch to the __x86.indirect_thunk.* symbols.

Update all the manual indirect branches in to use the new thunks.  The
indirect branches in the early boot and kexec path are left intact as we can't
use the compiled-in thunks at those points.

Signed-off-by: Andrew Cooper 
---
v4:
 * New
v6:
 * Thunk more assembly
 * Fix check_wakeup_from_wait() to not corrupt its stack
v7:
 * Protect the jmp from the trampoline into the high mappings on the AP boot
   path, and the hand-crafted indirect jump in the PV IO emulation stubs.
---
 xen/arch/x86/boot/trampoline.S   | 24 +--
 xen/arch/x86/extable.c   |  4 ++--
 xen/arch/x86/pv/emul-priv-op.c   | 41 
 xen/arch/x86/x86_64/entry.S  |  6 +++--
 xen/arch/x86/x86_emulate/x86_emulate.c   |  4 ++--
 xen/common/wait.c|  8 ---
 xen/include/asm-x86/asm_defns.h  |  8 +++
 xen/include/asm-x86/indirect_thunk_asm.h | 41 
 8 files changed, 115 insertions(+), 21 deletions(-)
 create mode 100644 xen/include/asm-x86/indirect_thunk_asm.h

diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/trampoline.S
index 4d640f3..abf40f3 100644
--- a/xen/arch/x86/boot/trampoline.S
+++ b/xen/arch/x86/boot/trampoline.S
@@ -153,8 +153,28 @@ trampoline_protmode_entry:
 .code64
 start64:
 /* Jump to high mappings. */
-movabs  $__high_start,%rax
-jmpq*%rax
+movabs  $__high_start, %rdi
+
+#ifdef CONFIG_INDIRECT_THUNK
+/*
+ * If booting virtualised, or hot-onlining a CPU, sibling threads can
+ * attempt Branch Target Injection against this jmp.
+ *
+ * We've got no usable stack so can't use a RETPOLINE thunk, and are
+ * further than +- 2G from the high mappings so couldn't use JUMP_THUNK
+ * even if was a non-RETPOLINE thunk.  Futhermore, an LFENCE isn't
+ * necesserily safe to use at this point.
+ *
+ * As this isn't a hotpath, use a fully serialising event to reduce
+ * the speculation window as much as possible.  %ebx needs preserving
+ * for __high_start.
+ */
+mov %ebx, %esi
+cpuid
+mov %esi, %ebx
+#endif
+
+jmpq*%rdi
 
 #include "wakeup.S"
 
diff --git a/xen/arch/x86/extable.c b/xen/arch/x86/extable.c
index 6fffe05..bf5822d 100644
--- a/xen/arch/x86/extable.c
+++ b/xen/arch/x86/extable.c
@@ -158,7 +158,7 @@ static int __init stub_selftest(void)
 memcpy(ptr, tests[i].opc, ARRAY_SIZE(tests[i].opc));
 unmap_domain_page(ptr);
 
-asm volatile ( "call *%[stb]\n"
+asm volatile ( "CALL_THUNK %[stb]\n"
".Lret%=:\n\t"
".pushsection .fixup,\"ax\"\n"
".Lfix%=:\n\t"
@@ -167,7 +167,7 @@ static int __init stub_selftest(void)
".popsection\n\t"
_ASM_EXTABLE(.Lret%=, .Lfix%=)
: [exn] "+m" (res)
-   : [stb] "rm" (addr), "a" (tests[i].rax));
+   : [stb] "r" (addr), "a" (tests[i].rax));
 ASSERT(res == tests[i].res.raw);
 }
 
diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
index 1041a4c..6da9b46 100644
--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -73,37 +73,58 @@ void (*pv_post_outb_hook)(unsigned int port, u8 value);
 
 typedef void io_emul_stub_t(struct cpu_user_regs *);
 
+#ifdef CONFIG_INDIRECT_THUNK
+extern char ind_thunk_rcx[] asm ("__x86.indirect_thunk.rcx");
+#endif
+
 static io_emul_stub_t *io_emul_stub_setup(struct priv_op_ctxt *ctxt, u8 opcode,
   unsigned int port, unsigned int 
bytes)
 {
+struct stubs *this_stubs = _cpu(stubs);
+unsigned long stub_va = this_stubs->addr + STUB_BUF_SIZE / 2;
+
 if ( !ctxt->io_emul_stub )
-ctxt->io_emul_stub = map_domain_page(_mfn(this_cpu(stubs.mfn))) +
- (this_cpu(stubs.addr) &
-  ~PAGE_MASK) +
- STUB_BUF_SIZE / 2;
+ctxt->io_emul_stub =
+map_domain_page(_mfn(this_stubs->mfn)) + (stub_va & ~PAGE_MASK);
 
 /* movq $host_to_guest_gpr_switch,%rcx */
 ctxt->io_emul_stub[0] = 0x48;
 ctxt->io_emul_stub[1] = 0xb9;
 *(void **)>io_emul_stub[2] = (void *)host_to_guest_gpr_switch;
+
+#ifdef CONFIG_INDIRECT_THUNK
+/* callq __x86.indirect_thunk.rcx */
+ctxt->io_emul_stub[10] = 0xe8;
+*(int32_t *)>io_emul_stub[11] =
+_p(ind_thunk_rcx) - _p(stub_va + 11 + 4);
+
+#else
 /* callq *%rcx */
 ctxt->io_emul_stub[10] = 0xff;
 ctxt->io_emul_stub[11] = 0xd1;
+
+/*
+ * 3 bytes 

[Xen-devel] [PATCH v6.5 19/26] x86/hvm: Permit guests direct access to MSR_{SPEC_CTRL, PRED_CMD}

[Andrew Cooper]

For performance reasons, HVM guests should have direct access to these MSRs
when possible.

Signed-off-by: Andrew Cooper 
---
v4:
 * Redo almost from scratch to support AMD
v6:
 * Allow direct access to PRED_CMD for IBPB
---
 xen/arch/x86/domctl.c  | 19 +++
 xen/arch/x86/hvm/svm/svm.c |  5 +
 xen/arch/x86/hvm/vmx/vmx.c | 18 ++
 xen/arch/x86/msr.c |  3 ++-
 xen/include/asm-x86/msr.h  |  5 -
 5 files changed, 48 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 72b4489..81fbeaa 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -53,6 +53,7 @@ static int update_domain_cpuid_info(struct domain *d,
 struct cpuid_policy *p = d->arch.cpuid;
 const struct cpuid_leaf leaf = { ctl->eax, ctl->ebx, ctl->ecx, ctl->edx };
 int old_vendor = p->x86_vendor;
+unsigned int old_7d0 = p->feat.raw[0].d, old_e8b = p->extd.raw[8].b;
 bool call_policy_changed = false; /* Avoid for_each_vcpu() unnecessarily */
 
 /*
@@ -218,6 +219,14 @@ static int update_domain_cpuid_info(struct domain *d,
 
 d->arch.pv_domain.cpuidmasks->_7ab0 = mask;
 }
+
+/*
+ * If the IBSRB/STIBP policy has changed, we need to recalculate the
+ * MSR interception bitmaps and STIBP protection default.
+ */
+call_policy_changed = ((old_7d0 ^ p->feat.raw[0].d) &
+   (cpufeat_mask(X86_FEATURE_IBRSB) |
+cpufeat_mask(X86_FEATURE_STIBP)));
 break;
 
 case 0xa:
@@ -292,6 +301,16 @@ static int update_domain_cpuid_info(struct domain *d,
 d->arch.pv_domain.cpuidmasks->e1cd = mask;
 }
 break;
+
+case 0x8008:
+/*
+ * If the IBRB policy has changed, we need to recalculate the MSR
+ * interception bitmaps.
+ */
+call_policy_changed = (is_hvm_domain(d) &&
+   ((old_e8b ^ p->extd.raw[8].b) &
+(cpufeat_mask(X86_FEATURE_IBPB;
+break;
 }
 
 if ( call_policy_changed )
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index c48fdfa..ee47508 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -617,6 +617,7 @@ static void svm_cpuid_policy_changed(struct vcpu *v)
 {
 struct arch_svm_struct *arch_svm = >arch.hvm_svm;
 struct vmcb_struct *vmcb = arch_svm->vmcb;
+const struct cpuid_policy *cp = v->domain->arch.cpuid;
 u32 bitmap = vmcb_get_exception_intercepts(vmcb);
 
 if ( opt_hvm_fep ||
@@ -626,6 +627,10 @@ static void svm_cpuid_policy_changed(struct vcpu *v)
 bitmap &= ~(1U << TRAP_invalid_op);
 
 vmcb_set_exception_intercepts(vmcb, bitmap);
+
+/* Give access to MSR_PRED_CMD if the guest has been told about it. */
+svm_intercept_msr(v, MSR_PRED_CMD,
+  cp->extd.ibpb ? MSR_INTERCEPT_NONE : MSR_INTERCEPT_RW);
 }
 
 static void svm_sync_vmcb(struct vcpu *v)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index e036303..8609de3 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -656,6 +656,8 @@ void vmx_update_exception_bitmap(struct vcpu *v)
 
 static void vmx_cpuid_policy_changed(struct vcpu *v)
 {
+const struct cpuid_policy *cp = v->domain->arch.cpuid;
+
 if ( opt_hvm_fep ||
  (v->domain->arch.cpuid->x86_vendor != boot_cpu_data.x86_vendor) )
 v->arch.hvm_vmx.exception_bitmap |= (1U << TRAP_invalid_op);
@@ -665,6 +667,22 @@ static void vmx_cpuid_policy_changed(struct vcpu *v)
 vmx_vmcs_enter(v);
 vmx_update_exception_bitmap(v);
 vmx_vmcs_exit(v);
+
+/*
+ * We can only pass though MSR_SPEC_CTRL if the guest knows about all bits
+ * in it.  Otherwise, Xen may be fixing up in the background.
+ */
+v->arch.msr->spec_ctrl.direct_access = cp->feat.ibrsb && cp->feat.stibp;
+if ( v->arch.msr->spec_ctrl.direct_access )
+vmx_clear_msr_intercept(v, MSR_SPEC_CTRL, VMX_MSR_RW);
+else
+vmx_set_msr_intercept(v, MSR_SPEC_CTRL, VMX_MSR_RW);
+
+/* MSR_PRED_CMD is safe to pass through if the guest knows about it. */
+if ( cp->feat.ibrsb || cp->extd.ibpb )
+vmx_clear_msr_intercept(v, MSR_PRED_CMD,  VMX_MSR_RW);
+else
+vmx_set_msr_intercept(v, MSR_PRED_CMD,  VMX_MSR_RW);
 }
 
 int vmx_guest_x86_mode(struct vcpu *v)
diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
index 02a7b49..697cc6e 100644
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -132,7 +132,8 @@ int guest_rdmsr(const struct vcpu *v, uint32_t msr, 
uint64_t *val)
 case MSR_SPEC_CTRL:
 if ( !cp->feat.ibrsb )
 goto gp_fault;
-*val = vp->spec_ctrl.guest;
+*val = (vp->spec_ctrl.direct_access
+? vp->spec_ctrl.host : vp->spec_ctrl.guest);
 break;
 
 case MSR_INTEL_PLATFORM_INFO:

[Xen-devel] [PATCH v6.5 13/26] x86/amd: Try to set lfence as being Dispatch Serialising

[Andrew Cooper]

This property is required for the AMD's recommended mitigation for Branch
Target Injection, but Xen needs to cope with being unable to detect or modify
the MSR.

Signed-off-by: Andrew Cooper 
---
v4:
 * New
v5:
 * Use mnemonics.
---
 xen/arch/x86/cpu/amd.c| 35 ++-
 xen/include/asm-x86/cpufeature.h  |  1 +
 xen/include/asm-x86/cpufeatures.h |  1 +
 xen/include/asm-x86/msr-index.h   |  1 +
 4 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 5f36ac7..db78b50 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -558,8 +558,41 @@ static void init_amd(struct cpuinfo_x86 *c)
wrmsr_amd_safe(0xc001100d, l, h & ~1);
}
 
+   /*
+* Attempt to set lfence to be Dispatch Serialising.  This MSR almost
+* certainly isn't virtualised (and Xen at least will leak the real
+* value in but silently discard writes), as well as being per-core
+* rather than per-thread, so do a full safe read/write/readback cycle
+* in the worst case.
+*/
+   if (c->x86 == 0x0f || c->x86 == 0x11)
+   /* Always dispatch serialising on this hardare. */
+   __set_bit(X86_FEATURE_LFENCE_DISPATCH, c->x86_capability);
+   else if (c->x86 == 0x10 || c->x86 >= 0x12) {
+   if (rdmsr_safe(MSR_AMD64_DE_CFG, value))
+   /* Unable to read.  Assume the safer default. */
+   __clear_bit(X86_FEATURE_LFENCE_DISPATCH,
+   c->x86_capability);
+   else if (value & AMD64_DE_CFG_LFENCE_SERIALISE)
+   /* Already dispatch serialising. */
+   __set_bit(X86_FEATURE_LFENCE_DISPATCH,
+ c->x86_capability);
+   else if (wrmsr_safe(MSR_AMD64_DE_CFG,
+   value | AMD64_DE_CFG_LFENCE_SERIALISE) ||
+rdmsr_safe(MSR_AMD64_DE_CFG, value) ||
+!(value & AMD64_DE_CFG_LFENCE_SERIALISE))
+   /* Attempt to set failed.  Assume the safer default */
+   __clear_bit(X86_FEATURE_LFENCE_DISPATCH,
+   c->x86_capability);
+   else
+   /* Successfully enabled! */
+   __set_bit(X86_FEATURE_LFENCE_DISPATCH,
+ c->x86_capability);
+   }
+
/* MFENCE stops RDTSC speculation */
-   __set_bit(X86_FEATURE_MFENCE_RDTSC, c->x86_capability);
+   if (!cpu_has_lfence_dispatch)
+   __set_bit(X86_FEATURE_MFENCE_RDTSC, c->x86_capability);
 
switch(c->x86)
{
diff --git a/xen/include/asm-x86/cpufeature.h b/xen/include/asm-x86/cpufeature.h
index 84cc51d..adc333f 100644
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -104,6 +104,7 @@
 #define cpu_has_arch_perfmonboot_cpu_has(X86_FEATURE_ARCH_PERFMON)
 #define cpu_has_cpuid_faulting  boot_cpu_has(X86_FEATURE_CPUID_FAULTING)
 #define cpu_has_aperfmperf  boot_cpu_has(X86_FEATURE_APERFMPERF)
+#define cpu_has_lfence_dispatch boot_cpu_has(X86_FEATURE_LFENCE_DISPATCH)
 
 enum _cache_type {
 CACHE_TYPE_NULL = 0,
diff --git a/xen/include/asm-x86/cpufeatures.h 
b/xen/include/asm-x86/cpufeatures.h
index bc98227..58b37d6 100644
--- a/xen/include/asm-x86/cpufeatures.h
+++ b/xen/include/asm-x86/cpufeatures.h
@@ -22,3 +22,4 @@ XEN_CPUFEATURE(APERFMPERF,  (FSCAPINTS+0)*32+ 8) /* 
APERFMPERF */
 XEN_CPUFEATURE(MFENCE_RDTSC,(FSCAPINTS+0)*32+ 9) /* MFENCE synchronizes 
RDTSC */
 XEN_CPUFEATURE(XEN_SMEP,(FSCAPINTS+0)*32+10) /* SMEP gets used by Xen 
itself */
 XEN_CPUFEATURE(XEN_SMAP,(FSCAPINTS+0)*32+11) /* SMAP gets used by Xen 
itself */
+XEN_CPUFEATURE(LFENCE_DISPATCH, (FSCAPINTS+0)*32+12) /* lfence set as Dispatch 
Serialising */
diff --git a/xen/include/asm-x86/msr-index.h b/xen/include/asm-x86/msr-index.h
index a834f3b..56f5359 100644
--- a/xen/include/asm-x86/msr-index.h
+++ b/xen/include/asm-x86/msr-index.h
@@ -207,6 +207,7 @@
 #define MSR_AMD64_IC_CFG   0xc0011021
 #define MSR_AMD64_DC_CFG   0xc0011022
 #define MSR_AMD64_DE_CFG   0xc0011029
+#define AMD64_DE_CFG_LFENCE_SERIALISE  (_AC(1, ULL) << 1)
 
 #define MSR_AMD64_DR0_ADDRESS_MASK 0xc0011027
 #define MSR_AMD64_DR1_ADDRESS_MASK 0xc0011019
-- 
2.1.4


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

[Xen-devel] [PATCH v6.5 10/26] common/wait: Clarifications to wait infrastructure

[Andrew Cooper]

This logic is not as clear as it could be.  Add some comments to help.

Rearrange the asm block in __prepare_to_wait() to separate the GPR
saving/restoring from the internal logic.

While tweaking, add an unreachable() following the jmp in
check_wakeup_from_wait().

No functional change.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
---
v6:
 * New
---
 xen/common/wait.c | 31 ---
 1 file changed, 24 insertions(+), 7 deletions(-)

diff --git a/xen/common/wait.c b/xen/common/wait.c
index c5fc094..3d3d9fe 100644
--- a/xen/common/wait.c
+++ b/xen/common/wait.c
@@ -138,14 +138,26 @@ static void __prepare_to_wait(struct waitqueue_vcpu *wqv)
 domain_crash_synchronous();
 }
 
+/* Hand-rolled setjmp(). */
 asm volatile (
-"push %%rax; push %%rbx; push %%rdx; "
-"push %%rbp; push %%r8; push %%r9; push %%r10; push %%r11; "
-"push %%r12; push %%r13; push %%r14; push %%r15; call 1f; "
-"1: addq $2f-1b,(%%rsp); sub %%esp,%%ecx; cmp %3,%%ecx; ja 3f; "
-"mov %%rsp,%%rsi; 2: rep movsb; mov %%rsp,%%rsi; 3: pop %%rax; "
-"pop %%r15; pop %%r14; pop %%r13; pop %%r12; "
-"pop %%r11; pop %%r10; pop %%r9; pop %%r8; "
+"push %%rax; push %%rbx; push %%rdx; push %%rbp;"
+"push %%r8;  push %%r9;  push %%r10; push %%r11;"
+"push %%r12; push %%r13; push %%r14; push %%r15;"
+
+"call 1f;"
+"1: addq $2f-1b,(%%rsp);"
+"sub %%esp,%%ecx;"
+"cmp %3,%%ecx;"
+"ja 3f;"
+"mov %%rsp,%%rsi;"
+
+/* check_wakeup_from_wait() longjmp()'s to this point. */
+"2: rep movsb;"
+"mov %%rsp,%%rsi;"
+"3: pop %%rax;"
+
+"pop %%r15; pop %%r14; pop %%r13; pop %%r12;"
+"pop %%r11; pop %%r10; pop %%r9;  pop %%r8;"
 "pop %%rbp; pop %%rdx; pop %%rbx; pop %%rax"
 : "=" (wqv->esp), "=" (dummy), "=" (dummy)
 : "i" (PAGE_SIZE), "0" (0), "1" (cpu_info), "2" (wqv->stack)
@@ -189,11 +201,16 @@ void check_wakeup_from_wait(void)
 wait(); /* takes us back into the scheduler */
 }
 
+/*
+ * Hand-rolled longjmp().  Returns to the pointer on the top of
+ * wqv->stack, and lands on a `rep movs` instruction.
+ */
 asm volatile (
 "mov %1,%%"__OP"sp; jmp *(%0)"
 : : "S" (wqv->stack), "D" (wqv->esp),
 "c" ((char *)get_cpu_info() - (char *)wqv->esp)
 : "memory" );
+unreachable();
 }
 
 #else /* !CONFIG_X86 */
-- 
2.1.4


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

[Xen-devel] [PATCH v6.5 16/26] x86/cmdline: Introduce a command line option to disable IBRS/IBPB, STIBP and IBPB

[Andrew Cooper]

Instead of gaining yet another top level boolean, introduce a more generic
cpuid= option.  Also introduce a helper function to parse a generic boolean
value.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 

v3:
 * New
v4:
 * Rename "xen-cpuid" to "cpuid"
 * Adjust comment in parse_boolean()
---
 docs/misc/xen-command-line.markdown | 12 
 xen/arch/x86/cpuid.c| 35 +++
 xen/common/kernel.c | 23 +++
 xen/include/xen/lib.h   |  7 +++
 4 files changed, 77 insertions(+)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index c9dbfbb..19e12ac 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -469,6 +469,18 @@ choice of `dom0-kernel` is deprecated and not supported by 
all Dom0 kernels.
   respectively.
 * `verbose` option can be included as a string or also as `verbose=`
 
+### cpuid (x86)
+> `= List of comma separated booleans`
+
+This option allows for fine tuning of the facilities Xen will use, after
+accounting for hardware capabilities as enumerated via CPUID.
+
+Currently accepted:
+
+The Speculation Control hardware features `ibrsb`, `stibp`, `ibpb` are used by
+default if avaiable.  They can be ignored, e.g. `no-ibrsb`, at which point Xen
+won't use them itself, and won't offer them to guests.
+
 ### cpuid\_mask\_cpu (AMD only)
 > `= fam_0f_rev_c | fam_0f_rev_d | fam_0f_rev_e | fam_0f_rev_f | fam_0f_rev_g 
 > | fam_10_rev_b | fam_10_rev_c | fam_11_rev_b`
 
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 5ee82d3..2ef71d2 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -18,6 +18,41 @@ static const uint32_t hvm_shadow_featuremask[] = 
INIT_HVM_SHADOW_FEATURES;
 static const uint32_t hvm_hap_featuremask[] = INIT_HVM_HAP_FEATURES;
 static const uint32_t deep_features[] = INIT_DEEP_FEATURES;
 
+static int __init parse_xen_cpuid(const char *s)
+{
+const char *ss;
+int val, rc = 0;
+
+do {
+ss = strchr(s, ',');
+if ( !ss )
+ss = strchr(s, '\0');
+
+if ( (val = parse_boolean("ibpb", s, ss)) >= 0 )
+{
+if ( !val )
+setup_clear_cpu_cap(X86_FEATURE_IBPB);
+}
+else if ( (val = parse_boolean("ibrsb", s, ss)) >= 0 )
+{
+if ( !val )
+setup_clear_cpu_cap(X86_FEATURE_IBRSB);
+}
+else if ( (val = parse_boolean("stibp", s, ss)) >= 0 )
+{
+if ( !val )
+setup_clear_cpu_cap(X86_FEATURE_STIBP);
+}
+else
+rc = -EINVAL;
+
+s = ss + 1;
+} while ( *ss );
+
+return rc;
+}
+custom_param("cpuid", parse_xen_cpuid);
+
 #define EMPTY_LEAF ((struct cpuid_leaf){})
 static void zero_leaves(struct cpuid_leaf *l,
 unsigned int first, unsigned int last)
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 8d137c5..19f9bad 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -244,6 +244,29 @@ int parse_bool(const char *s, const char *e)
 return -1;
 }
 
+int parse_boolean(const char *name, const char *s, const char *e)
+{
+size_t slen, nlen;
+int val = !!strncmp(s, "no-", 3);
+
+if ( !val )
+s += 3;
+
+slen = e ? ({ ASSERT(e >= s); e - s; }) : strlen(s);
+nlen = strlen(name);
+
+/* Does s now start with name? */
+if ( slen < nlen || strncmp(s, name, nlen) )
+return -1;
+
+switch ( s[nlen] )
+{
+case '\0': return val;
+case '=':  return parse_bool([nlen + 1], e);
+default:   return -1;
+}
+}
+
 unsigned int tainted;
 
 /**
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index ed00ae1..1d97713 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -74,6 +74,13 @@ void cmdline_parse(const char *cmdline);
 int runtime_parse(const char *line);
 int parse_bool(const char *s, const char *e);
 
+/**
+ * Given a specific name, parses a string of the form:
+ *   [no-]$NAME[=...]
+ * returning 0 or 1 for a recognised boolean, or -1 for an error.
+ */
+int parse_boolean(const char *name, const char *s, const char *e);
+
 /*#define DEBUG_TRACE_DUMP*/
 #ifdef DEBUG_TRACE_DUMP
 extern void debugtrace_dump(void);
-- 
2.1.4


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

[Xen-devel] [PATCH v6.5 07/26] x86/hvm: Use SAVE_ALL to construct the cpu_user_regs frame after VMExit

[Andrew Cooper]

No practical change.

One side effect in debug builds is that %rbp is inverted in the manner
expected by the stack unwinder to indicate a interrupt frame.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
Reviewed-by: Wei Liu 
---
 xen/arch/x86/hvm/svm/entry.S | 22 --
 xen/arch/x86/hvm/vmx/entry.S | 17 ++---
 2 files changed, 6 insertions(+), 33 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/entry.S b/xen/arch/x86/hvm/svm/entry.S
index 4a72e38..df86da0 100644
--- a/xen/arch/x86/hvm/svm/entry.S
+++ b/xen/arch/x86/hvm/svm/entry.S
@@ -98,24 +98,10 @@ UNLIKELY_END(svm_trace)
 
 VMRUN
 
-GET_CURRENT(ax)
-push %rdi
-push %rsi
-push %rdx
-push %rcx
-mov  VCPU_svm_vmcb(%rax),%rcx
-push %rax
-push %r8
-push %r9
-push %r10
-push %r11
-push %rbx
-mov  %rax,%rbx
-push %rbp
-push %r12
-push %r13
-push %r14
-push %r15
+SAVE_ALL
+
+GET_CURRENT(bx)
+mov  VCPU_svm_vmcb(%rbx),%rcx
 
 movb $0,VCPU_svm_vmcb_in_sync(%rbx)
 mov  VMCB_rax(%rcx),%rax
diff --git a/xen/arch/x86/hvm/vmx/entry.S b/xen/arch/x86/hvm/vmx/entry.S
index 47cd674..b2f98be 100644
--- a/xen/arch/x86/hvm/vmx/entry.S
+++ b/xen/arch/x86/hvm/vmx/entry.S
@@ -30,23 +30,10 @@
 #define VMLAUNCH .byte 0x0f,0x01,0xc2
 
 ENTRY(vmx_asm_vmexit_handler)
-push %rdi
-push %rsi
-push %rdx
-push %rcx
-push %rax
+SAVE_ALL
+
 mov  %cr2,%rax
-push %r8
-push %r9
-push %r10
-push %r11
-push %rbx
 GET_CURRENT(bx)
-push %rbp
-push %r12
-push %r13
-push %r14
-push %r15
 
 movb $1,VCPU_vmx_launched(%rbx)
 mov  %rax,VCPU_hvm_guest_cr2(%rbx)
-- 
2.1.4


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

[Xen-devel] [PATCH v6.5 05/26] x86/entry: Remove support for partial cpu_user_regs frames

[Andrew Cooper]

Save all GPRs on entry to Xen.

The entry_int82() path is via a DPL1 gate, only usable by 32bit PV guests, so
can get away with only saving the 32bit registers.  All other entrypoints can
be reached from 32 or 64bit contexts.

Signed-off-by: Andrew Cooper 
Reviewed-by: Wei Liu 
---
 tools/tests/x86_emulator/x86-emulate.c |   1 -
 xen/arch/x86/pv/domain.c   |   1 -
 xen/arch/x86/pv/emul-priv-op.c |   2 -
 xen/arch/x86/x86_64/compat/entry.S |   7 ++-
 xen/arch/x86/x86_64/entry.S|  12 ++--
 xen/arch/x86/x86_64/traps.c|  13 ++--
 xen/arch/x86/x86_emulate.c |   1 -
 xen/arch/x86/x86_emulate/x86_emulate.c |   8 +--
 xen/common/wait.c  |   1 -
 xen/include/asm-x86/asm_defns.h| 105 +++--
 10 files changed, 26 insertions(+), 125 deletions(-)

diff --git a/tools/tests/x86_emulator/x86-emulate.c 
b/tools/tests/x86_emulator/x86-emulate.c
index 975ddc7..9056610 100644
--- a/tools/tests/x86_emulator/x86-emulate.c
+++ b/tools/tests/x86_emulator/x86-emulate.c
@@ -3,7 +3,6 @@
 #include 
 
 #define cpu_has_amd_erratum(nr) 0
-#define mark_regs_dirty(r) ((void)(r))
 #define cpu_has_mpx false
 #define read_bndcfgu() 0
 #define xstate_set_init(what)
diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
index 2234128..74e9e66 100644
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -20,7 +20,6 @@
 static void noreturn continue_nonidle_domain(struct vcpu *v)
 {
 check_wakeup_from_wait();
-mark_regs_dirty(guest_cpu_user_regs());
 reset_stack_and_jump(ret_from_intr);
 }
 
diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
index 6115840..1041a4c 100644
--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -337,7 +337,6 @@ static int read_io(unsigned int port, unsigned int bytes,
 io_emul_stub_t *io_emul =
 io_emul_stub_setup(poc, ctxt->opcode, port, bytes);
 
-mark_regs_dirty(ctxt->regs);
 io_emul(ctxt->regs);
 return X86EMUL_DONE;
 }
@@ -436,7 +435,6 @@ static int write_io(unsigned int port, unsigned int bytes,
 io_emul_stub_t *io_emul =
 io_emul_stub_setup(poc, ctxt->opcode, port, bytes);
 
-mark_regs_dirty(ctxt->regs);
 io_emul(ctxt->regs);
 if ( (bytes == 1) && pv_post_outb_hook )
 pv_post_outb_hook(port, val);
diff --git a/xen/arch/x86/x86_64/compat/entry.S 
b/xen/arch/x86/x86_64/compat/entry.S
index ba6e941..3fea54e 100644
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -16,7 +16,8 @@
 ENTRY(entry_int82)
 ASM_CLAC
 pushq $0
-SAVE_VOLATILE type=HYPERCALL_VECTOR compat=1
+movl  $HYPERCALL_VECTOR, 4(%rsp)
+SAVE_ALL compat=1 /* DPL1 gate, restricted to 32bit PV guests only. */
 CR4_PV32_RESTORE
 
 GET_CURRENT(bx)
@@ -60,7 +61,6 @@ compat_test_guest_events:
 /* %rbx: struct vcpu */
 compat_process_softirqs:
 sti
-andl  $~TRAP_regs_partial,UREGS_entry_vector(%rsp)
 call  do_softirq
 jmp   compat_test_all_events
 
@@ -197,7 +197,8 @@ ENTRY(cstar_enter)
 pushq $FLAT_USER_CS32
 pushq %rcx
 pushq $0
-SAVE_VOLATILE TRAP_syscall
+movl  $TRAP_syscall, 4(%rsp)
+SAVE_ALL
 GET_CURRENT(bx)
 movq  VCPU_domain(%rbx),%rcx
 cmpb  $0,DOMAIN_is_32bit_pv(%rcx)
diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
index 6066ed8..1dd9ccf 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -98,7 +98,8 @@ ENTRY(lstar_enter)
 pushq $FLAT_KERNEL_CS64
 pushq %rcx
 pushq $0
-SAVE_VOLATILE TRAP_syscall
+movl  $TRAP_syscall, 4(%rsp)
+SAVE_ALL
 GET_CURRENT(bx)
 testb $TF_kernel_mode,VCPU_thread_flags(%rbx)
 jzswitch_to_kernel
@@ -140,7 +141,6 @@ test_guest_events:
 /* %rbx: struct vcpu */
 process_softirqs:
 sti   
-SAVE_PRESERVED
 call do_softirq
 jmp  test_all_events
 
@@ -190,7 +190,8 @@ GLOBAL(sysenter_eflags_saved)
 pushq $3 /* ring 3 null cs */
 pushq $0 /* null rip */
 pushq $0
-SAVE_VOLATILE TRAP_syscall
+movl  $TRAP_syscall, 4(%rsp)
+SAVE_ALL
 GET_CURRENT(bx)
 cmpb  $0,VCPU_sysenter_disables_events(%rbx)
 movq  VCPU_sysenter_addr(%rbx),%rax
@@ -207,7 +208,6 @@ UNLIKELY_END(sysenter_nt_set)
 leal  (,%rcx,TBF_INTERRUPT),%ecx
 UNLIKELY_START(z, sysenter_gpf)
 movq  VCPU_trap_ctxt(%rbx),%rsi
-SAVE_PRESERVED
 movl  $TRAP_gp_fault,UREGS_entry_vector(%rsp)
 movl  %eax,TRAPBOUNCE_error_code(%rdx)
 movq  TRAP_gp_fault * TRAPINFO_sizeof + TRAPINFO_eip(%rsi),%rax
@@ -225,7 +225,8 @@ UNLIKELY_END(sysenter_gpf)
 ENTRY(int80_direct_trap)
 

[Xen-devel] [PATCH v6.5 06/26] x86/entry: Rearrange RESTORE_ALL to restore register in stack order

[Andrew Cooper]

Results in a more predictable (i.e. linear) memory access pattern.

No functional change.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
Reviewed-by: Wei Liu 
---
 xen/include/asm-x86/asm_defns.h | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/xen/include/asm-x86/asm_defns.h b/xen/include/asm-x86/asm_defns.h
index 98192eb..fa62c54 100644
--- a/xen/include/asm-x86/asm_defns.h
+++ b/xen/include/asm-x86/asm_defns.h
@@ -259,6 +259,19 @@ static always_inline void stac(void)
  */
 .macro RESTORE_ALL adj=0 compat=0
 .if !\compat
+movq  UREGS_r15(%rsp), %r15
+movq  UREGS_r14(%rsp), %r14
+movq  UREGS_r13(%rsp), %r13
+movq  UREGS_r12(%rsp), %r12
+.else
+xor %r15, %r15
+xor %r14, %r14
+xor %r13, %r13
+xor %r12, %r12
+.endif
+LOAD_ONE_REG(bp, \compat)
+LOAD_ONE_REG(bx, \compat)
+.if !\compat
 movq  UREGS_r11(%rsp),%r11
 movq  UREGS_r10(%rsp),%r10
 movq  UREGS_r9(%rsp),%r9
@@ -274,19 +287,6 @@ static always_inline void stac(void)
 LOAD_ONE_REG(dx, \compat)
 LOAD_ONE_REG(si, \compat)
 LOAD_ONE_REG(di, \compat)
-.if !\compat
-movq  UREGS_r15(%rsp),%r15
-movq  UREGS_r14(%rsp),%r14
-movq  UREGS_r13(%rsp),%r13
-movq  UREGS_r12(%rsp),%r12
-.else
-xor %r15, %r15
-xor %r14, %r14
-xor %r13, %r13
-xor %r12, %r12
-.endif
-LOAD_ONE_REG(bp, \compat)
-LOAD_ONE_REG(bx, \compat)
 subq  $-(UREGS_error_code-UREGS_r15+\adj), %rsp
 .endm
 
-- 
2.1.4


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

[Xen-devel] [PATCH v6.5 09/26] x86: Support compiling with indirect branch thunks

[Andrew Cooper]

Use -mindirect-branch=thunk-extern/-mindirect-branch-register when available.
To begin with, use the retpoline thunk.  Later work will add alternative
thunks which can be selected at boot time.

Signed-off-by: Andrew Cooper 
---
v4:
 * New
---
 xen/arch/x86/Makefile |  1 +
 xen/arch/x86/Rules.mk |  7 +++
 xen/arch/x86/indirect_thunk.S | 28 
 xen/arch/x86/xen.lds.S|  1 +
 4 files changed, 37 insertions(+)
 create mode 100644 xen/arch/x86/indirect_thunk.S

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index d5d58a2..433233c 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -36,6 +36,7 @@ obj-y += io_apic.o
 obj-$(CONFIG_LIVEPATCH) += alternative.o livepatch.o
 obj-y += msi.o
 obj-y += msr.o
+obj-$(CONFIG_INDIRECT_THUNK) += indirect_thunk.o
 obj-y += ioport_emulate.o
 obj-y += irq.o
 obj-$(CONFIG_KEXEC) += machine_kexec.o
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 568657e..abcc4d4 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -30,3 +30,10 @@ CFLAGS += -fno-asynchronous-unwind-tables
 ifneq ($(call cc-option,$(CC),-fvisibility=hidden,n),n)
 CFLAGS += -DGCC_HAS_VISIBILITY_ATTRIBUTE
 endif
+
+# Compile with thunk-extern, indirect-branch-register if avaiable.
+ifneq ($(call cc-option,$(CC),-mindirect-branch-register,n),n)
+CFLAGS += -mindirect-branch=thunk-extern -mindirect-branch-register
+CFLAGS += -DCONFIG_INDIRECT_THUNK
+export CONFIG_INDIRECT_THUNK=y
+endif
diff --git a/xen/arch/x86/indirect_thunk.S b/xen/arch/x86/indirect_thunk.S
new file mode 100644
index 000..4fef1c8
--- /dev/null
+++ b/xen/arch/x86/indirect_thunk.S
@@ -0,0 +1,28 @@
+#include 
+
+.macro IND_THUNK_RETPOLINE reg:req
+call 2f
+1:
+lfence
+jmp 1b
+2:
+mov \reg, (%rsp)
+ret
+.endm
+
+/*
+ * Build the __x86.indirect_thunk.* symbols.  Execution lands on an
+ * alternative patch point which implements one of the above THUNK_*'s
+ */
+.macro GEN_INDIRECT_THUNK name:req reg:req
+.section .text.__x86.indirect_thunk.\name, "ax", @progbits
+
+ENTRY(__x86.indirect_thunk.\name)
+IND_THUNK_RETPOLINE \reg
+.endm
+
+/* Instantiate GEN_INDIRECT_THUNK for each register except %rsp. */
+.irp enc, rax, rbx, rcx, rdx, rsi, rdi, rbp, \
+  r8, r9, r10, r11, r12, r13, r14, r15
+GEN_INDIRECT_THUNK name=\enc, reg=%\enc
+.endr
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index d5e8821..345946f 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -59,6 +59,7 @@ SECTIONS
   .text : {
 _stext = .;/* Text and read-only data */
*(.text)
+   *(.text.__x86.*)
*(.text.cold)
*(.text.unlikely)
*(.fixup)
-- 
2.1.4


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

[Xen-devel] [PATCH v6.5 08/26] x86/entry: Erase guest GPR state on entry to Xen

[Andrew Cooper]

This reduces the number of code gadgets which can be attacked with arbitrary
guest-controlled GPR values.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
Reviewed-by: Wei Liu 
---
 xen/include/asm-x86/asm_defns.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/xen/include/asm-x86/asm_defns.h b/xen/include/asm-x86/asm_defns.h
index fa62c54..7e8838e 100644
--- a/xen/include/asm-x86/asm_defns.h
+++ b/xen/include/asm-x86/asm_defns.h
@@ -217,22 +217,34 @@ static always_inline void stac(void)
 addq  $-(UREGS_error_code-UREGS_r15), %rsp
 cld
 movq  %rdi,UREGS_rdi(%rsp)
+xor   %edi, %edi
 movq  %rsi,UREGS_rsi(%rsp)
+xor   %esi, %esi
 movq  %rdx,UREGS_rdx(%rsp)
+xor   %edx, %edx
 movq  %rcx,UREGS_rcx(%rsp)
+xor   %ecx, %ecx
 movq  %rax,UREGS_rax(%rsp)
+xor   %eax, %eax
 .if !\compat
 movq  %r8,UREGS_r8(%rsp)
 movq  %r9,UREGS_r9(%rsp)
 movq  %r10,UREGS_r10(%rsp)
 movq  %r11,UREGS_r11(%rsp)
 .endif
+xor   %r8, %r8
+xor   %r9, %r9
+xor   %r10, %r10
+xor   %r11, %r11
 movq  %rbx,UREGS_rbx(%rsp)
+xor   %ebx, %ebx
 movq  %rbp,UREGS_rbp(%rsp)
 #ifdef CONFIG_FRAME_POINTER
 /* Indicate special exception stack frame by inverting the frame pointer. */
 leaq  UREGS_rbp(%rsp), %rbp
 notq  %rbp
+#else
+xor   %ebp, %ebp
 #endif
 .if !\compat
 movq  %r12,UREGS_r12(%rsp)
@@ -240,6 +252,10 @@ static always_inline void stac(void)
 movq  %r14,UREGS_r14(%rsp)
 movq  %r15,UREGS_r15(%rsp)
 .endif
+xor   %r12, %r12
+xor   %r13, %r13
+xor   %r14, %r14
+xor   %r15, %r15
 .endm
 
 #define LOAD_ONE_REG(reg, compat) \
-- 
2.1.4


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

[Xen-devel] [PATCH v6.5 02/26] x86/alt: Introduce ALTERNATIVE{, _2} macros

[Andrew Cooper]

To help creating alternative frames in assembly.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
---
v3:
 * Drop the now-unused ALTERNATIVE_2
 * Use .L\@ rather than opencoded numbers
v4:
 * Extra @progbits
 * Reinstate ALTERNATIVE_2
---
 xen/include/asm-x86/alternative-asm.h | 46 +++
 1 file changed, 46 insertions(+)

diff --git a/xen/include/asm-x86/alternative-asm.h 
b/xen/include/asm-x86/alternative-asm.h
index bf0332e..6640e85 100644
--- a/xen/include/asm-x86/alternative-asm.h
+++ b/xen/include/asm-x86/alternative-asm.h
@@ -17,6 +17,52 @@
 .byte \alt_len
 .endm
 
+.macro ALTERNATIVE oldinstr, newinstr, feature
+.Lold_start_\@:
+\oldinstr
+.Lold_end_\@:
+
+.pushsection .altinstructions, "a", @progbits
+altinstruction_entry .Lold_start_\@, .Lnew_start_\@, \feature, \
+(.Lold_end_\@ - .Lold_start_\@), (.Lnew_end_\@ - .Lnew_start_\@)
+
+.section .discard, "a", @progbits
+/* Assembler-time check that \newinstr isn't longer than \oldinstr. */
+.byte 0xff + (.Lnew_end_\@ - .Lnew_start_\@) - (.Lold_end_\@ - 
.Lold_start_\@)
+
+.section .altinstr_replacement, "ax", @progbits
+.Lnew_start_\@:
+\newinstr
+.Lnew_end_\@:
+.popsection
+.endm
+
+.macro ALTERNATIVE_2 oldinstr, newinstr1, feature1, newinstr2, feature2
+.Lold_start_\@:
+\oldinstr
+.Lold_end_\@:
+
+.pushsection .altinstructions, "a", @progbits
+altinstruction_entry .Lold_start_\@, .Lnew1_start_\@, \feature1, \
+(.Lold_end_\@ - .Lold_start_\@), (.Lnew1_end_\@ - .Lnew1_start_\@)
+altinstruction_entry .Lold_start_\@, .Lnew2_start_\@, \feature2, \
+(.Lold_end_\@ - .Lold_start_\@), (.Lnew2_end_\@ - .Lnew2_start_\@)
+
+.section .discard, "a", @progbits
+/* Assembler-time check that \newinstr{1,2} aren't longer than \oldinstr. 
*/
+.byte 0xff + (.Lnew1_end_\@ - .Lnew1_start_\@) - (.Lold_end_\@ - 
.Lold_start_\@)
+.byte 0xff + (.Lnew2_end_\@ - .Lnew2_start_\@) - (.Lold_end_\@ - 
.Lold_start_\@)
+
+.section .altinstr_replacement, "ax", @progbits
+.Lnew1_start_\@:
+\newinstr1
+.Lnew1_end_\@:
+.Lnew2_start_\@:
+\newinstr2
+.Lnew2_end_\@:
+.popsection
+.endm
+
 #endif /* __ASSEMBLY__ */
 #endif /* _ASM_X86_ALTERNATIVE_ASM_H_ */
 
-- 
2.1.4


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

[Xen-devel] [PATCH v6.5 01/26] x86/alt: Break out alternative-asm into a separate header file

[Andrew Cooper]

Signed-off-by: Andrew Cooper 
Reviewed-by: Wei Liu 
Acked-by: Jan Beulich 
---
 xen/include/asm-x86/alternative-asm.h | 31 +++
 xen/include/asm-x86/alternative.h | 13 +++--
 2 files changed, 34 insertions(+), 10 deletions(-)
 create mode 100644 xen/include/asm-x86/alternative-asm.h

diff --git a/xen/include/asm-x86/alternative-asm.h 
b/xen/include/asm-x86/alternative-asm.h
new file mode 100644
index 000..bf0332e
--- /dev/null
+++ b/xen/include/asm-x86/alternative-asm.h
@@ -0,0 +1,31 @@
+#ifndef _ASM_X86_ALTERNATIVE_ASM_H_
+#define _ASM_X86_ALTERNATIVE_ASM_H_
+
+#ifdef __ASSEMBLY__
+
+/*
+ * Issue one struct alt_instr descriptor entry (need to put it into
+ * the section .altinstructions, see below). This entry contains
+ * enough information for the alternatives patching code to patch an
+ * instruction. See apply_alternatives().
+ */
+.macro altinstruction_entry orig alt feature orig_len alt_len
+.long \orig - .
+.long \alt - .
+.word \feature
+.byte \orig_len
+.byte \alt_len
+.endm
+
+#endif /* __ASSEMBLY__ */
+#endif /* _ASM_X86_ALTERNATIVE_ASM_H_ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-x86/alternative.h 
b/xen/include/asm-x86/alternative.h
index db4f08e..ba537d6 100644
--- a/xen/include/asm-x86/alternative.h
+++ b/xen/include/asm-x86/alternative.h
@@ -1,17 +1,10 @@
 #ifndef __X86_ALTERNATIVE_H__
 #define __X86_ALTERNATIVE_H__
 
+#include 
 #include 
 
-#ifdef __ASSEMBLY__
-.macro altinstruction_entry orig alt feature orig_len alt_len
-.long \orig - .
-.long \alt - .
-.word \feature
-.byte \orig_len
-.byte \alt_len
-.endm
-#else
+#ifndef __ASSEMBLY__
 #include 
 #include 
 
@@ -145,6 +138,6 @@ extern void alternative_instructions(void);
 /* Use this macro(s) if you need more than one output parameter. */
 #define ASM_OUTPUT2(a...) a
 
-#endif  /*  __ASSEMBLY__  */
+#endif /*  !__ASSEMBLY__  */
 
 #endif /* __X86_ALTERNATIVE_H__ */
-- 
2.1.4


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

[Xen-devel] [PATCH v6.5 03/26] x86/hvm: Rename update_guest_vendor() callback to cpuid_policy_changed()

[Andrew Cooper]

It will shortly be used for more than just changing the vendor.

Signed-off-by: Andrew Cooper 
Reviewed-by: Wei Liu 
Reviewed-by: Jan Beulich 
---
v3:
 * Drop forward declaration of vmx_update_guest_vendor()
---
 xen/arch/x86/domctl.c | 17 ++---
 xen/arch/x86/hvm/hvm.c|  2 +-
 xen/arch/x86/hvm/svm/svm.c|  4 ++--
 xen/arch/x86/hvm/vmx/vmx.c|  5 ++---
 xen/include/asm-x86/hvm/hvm.h |  6 +++---
 5 files changed, 18 insertions(+), 16 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 36ab235..cc7f433 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -53,6 +53,7 @@ static int update_domain_cpuid_info(struct domain *d,
 struct cpuid_policy *p = d->arch.cpuid;
 const struct cpuid_leaf leaf = { ctl->eax, ctl->ebx, ctl->ecx, ctl->edx };
 int old_vendor = p->x86_vendor;
+bool call_policy_changed = false; /* Avoid for_each_vcpu() unnecessarily */
 
 /*
  * Skip update for leaves we don't care about.  This avoids the overhead
@@ -128,13 +129,7 @@ static int update_domain_cpuid_info(struct domain *d,
 switch ( ctl->input[0] )
 {
 case 0:
-if ( is_hvm_domain(d) && (p->x86_vendor != old_vendor) )
-{
-struct vcpu *v;
-
-for_each_vcpu( d, v )
-hvm_update_guest_vendor(v);
-}
+call_policy_changed = (p->x86_vendor != old_vendor);
 break;
 
 case 1:
@@ -299,6 +294,14 @@ static int update_domain_cpuid_info(struct domain *d,
 break;
 }
 
+if ( is_hvm_domain(d) && call_policy_changed )
+{
+struct vcpu *v;
+
+for_each_vcpu( d, v )
+hvm_cpuid_policy_changed(v);
+}
+
 return 0;
 }
 
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 28bc7e4..61df92c 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1555,7 +1555,7 @@ int hvm_vcpu_initialise(struct vcpu *v)
 hvm_set_guest_tsc(v, 0);
 }
 
-hvm_update_guest_vendor(v);
+hvm_cpuid_policy_changed(v);
 
 return 0;
 
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 2e62b9b..c48fdfa 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -613,7 +613,7 @@ static void svm_update_guest_efer(struct vcpu *v)
 vmcb_set_efer(vmcb, new_efer);
 }
 
-static void svm_update_guest_vendor(struct vcpu *v)
+static void svm_cpuid_policy_changed(struct vcpu *v)
 {
 struct arch_svm_struct *arch_svm = >arch.hvm_svm;
 struct vmcb_struct *vmcb = arch_svm->vmcb;
@@ -2424,7 +2424,7 @@ static struct hvm_function_table __initdata 
svm_function_table = {
 .get_shadow_gs_base   = svm_get_shadow_gs_base,
 .update_guest_cr  = svm_update_guest_cr,
 .update_guest_efer= svm_update_guest_efer,
-.update_guest_vendor  = svm_update_guest_vendor,
+.cpuid_policy_changed = svm_cpuid_policy_changed,
 .fpu_leave= svm_fpu_leave,
 .set_guest_pat= svm_set_guest_pat,
 .get_guest_pat= svm_get_guest_pat,
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index e526e88..e036303 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -72,7 +72,6 @@ static void vmx_free_vlapic_mapping(struct domain *d);
 static void vmx_install_vlapic_mapping(struct vcpu *v);
 static void vmx_update_guest_cr(struct vcpu *v, unsigned int cr);
 static void vmx_update_guest_efer(struct vcpu *v);
-static void vmx_update_guest_vendor(struct vcpu *v);
 static void vmx_wbinvd_intercept(void);
 static void vmx_fpu_dirty_intercept(void);
 static int vmx_msr_read_intercept(unsigned int msr, uint64_t *msr_content);
@@ -655,7 +654,7 @@ void vmx_update_exception_bitmap(struct vcpu *v)
 __vmwrite(EXCEPTION_BITMAP, bitmap);
 }
 
-static void vmx_update_guest_vendor(struct vcpu *v)
+static void vmx_cpuid_policy_changed(struct vcpu *v)
 {
 if ( opt_hvm_fep ||
  (v->domain->arch.cpuid->x86_vendor != boot_cpu_data.x86_vendor) )
@@ -2318,7 +2317,7 @@ static struct hvm_function_table __initdata 
vmx_function_table = {
 .update_host_cr3  = vmx_update_host_cr3,
 .update_guest_cr  = vmx_update_guest_cr,
 .update_guest_efer= vmx_update_guest_efer,
-.update_guest_vendor  = vmx_update_guest_vendor,
+.cpuid_policy_changed = vmx_cpuid_policy_changed,
 .fpu_leave= vmx_fpu_leave,
 .set_guest_pat= vmx_set_guest_pat,
 .get_guest_pat= vmx_get_guest_pat,
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index 6ecad33..7275c65 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -135,7 +135,7 @@ struct hvm_function_table {
 void (*update_guest_cr)(struct vcpu *v, unsigned int cr);
 void (*update_guest_efer)(struct vcpu *v);
 
-void (*update_guest_vendor)(struct vcpu *v);
+void 

[Xen-devel] [PATCH v6.5 00/26] x86: Mitigations for SP2/CVE-2017-5715/Branch Target Injection

[Andrew Cooper]

Due to the foreshortening of the embargo, I've posted what is currently
available.  I have yet to complete all the feedback from v6 review, but what
is here should be functionally correct, if a little rough around the edges.

*Important:*

In addition to this software series, you will need the following:

  1) A compiler which understands -mindirect-branch=thunk-external and
 -mindirect-branch-register.  A GCC patch series implementing this
 should be available imminently.

  2) New microcode from Intel and AMD.  These provide new MSRs for Xen to use,
 and virtualise for guest kernels to use.

There are some limitations, even with the work presented here.

  1) vCPU-to-vCPU SP2 attacks can only be mitigated at the hypervisor level
 with IBPB support, which for internal pipeline reasons, we do not expect
 to be made available on older processors.  For now, I will leave these
 details to the hardware vendors.

  2) Hardware lacking SMEP is in a worse position than hardware with SMEP.  If
 you have SMEP (Intel IvyBridge and later, Some AMD Fam16h and all Fam17h
 and later), make absolutely sure it is enabled in the BIOS and working.

  3) On hardware lacking SMEP support, it is still an open question how to
 protect against RSB-to-SMM speculation.  Native operating systems can fix
 this by prohibiting userspace from mmap()'ing addresses which alias the
 SMM range, but Xen has no feasible way of enforcing this restriction on
 PV guests, even if we could tolerate the ABI breakage.  (However, see the
 forthcoming SP3 mitigation series for alternatives for un trusted PV
 guests).


Please see the commit messages and comments for more details about mitigation
details and available options/impacts.  Its more complicated than I care to
reproduce here (and risk introducing a contradition).

~Andrew

Andrew Cooper (26):
  x86/alt: Break out alternative-asm into a separate header file
  x86/alt: Introduce ALTERNATIVE{,_2} macros
  x86/hvm: Rename update_guest_vendor() callback to cpuid_policy_changed()
  x86: Introduce a common cpuid_policy_updated()
  x86/entry: Remove support for partial cpu_user_regs frames
  x86/entry: Rearrange RESTORE_ALL to restore register in stack order
  x86/hvm: Use SAVE_ALL to construct the cpu_user_regs frame after VMExit
  x86/entry: Erase guest GPR state on entry to Xen
  x86: Support compiling with indirect branch thunks
  common/wait: Clarifications to wait infrastructure
  x86: Support indirect thunks from assembly code
  x86/boot: Report details of speculative mitigations
  x86/amd: Try to set lfence as being Dispatch Serialising
  x86: Introduce alternative indirect thunks
  x86/feature: Definitions for Indirect Branch Controls
  x86/cmdline: Introduce a command line option to disable IBRS/IBPB, STIBP and 
IBPB
  x86/msr: Emulation of MSR_{SPEC_CTRL,PRED_CMD} for guests
  x86/migrate: Move MSR_SPEC_CTRL on migrate
  x86/hvm: Permit guests direct access to MSR_{SPEC_CTRL,PRED_CMD}
  x86: Protect unaware domains from meddling hyperthreads
  x86/entry: Use MSR_SPEC_CTRL at each entry/exit point
  x86/boot: Calculate the most appropriate BTI mitigation to use
  x86/entry: Clobber the Return Stack Buffer on entry to Xen
  x86/ctxt: Issue a speculation barrier between vcpu contexts
  x86/cpuid: Offer Indirect Branch Controls to guests
  x86/idle: Clear SPEC_CTRL while idle

 docs/misc/xen-command-line.markdown |  37 
 tools/libxc/xc_cpuid_x86.c  |   4 +-
 tools/libxl/libxl_cpuid.c   |   3 +
 tools/misc/xen-cpuid.c  |  12 +-
 tools/tests/x86_emulator/x86-emulate.c  |   1 -
 xen/arch/x86/Makefile   |   2 +
 xen/arch/x86/Rules.mk   |   7 +
 xen/arch/x86/acpi/cpu_idle.c|  21 ++
 xen/arch/x86/boot/trampoline.S  |  24 +-
 xen/arch/x86/cpu/amd.c  |  35 ++-
 xen/arch/x86/cpu/mwait-idle.c   |   7 +
 xen/arch/x86/cpuid.c|  43 
 xen/arch/x86/domain.c   |  42 
 xen/arch/x86/domctl.c   |  38 +++-
 xen/arch/x86/extable.c  |   4 +-
 xen/arch/x86/hvm/hvm.c  |   4 +-
 xen/arch/x86/hvm/svm/entry.S|  28 +--
 xen/arch/x86/hvm/svm/svm.c  |   9 +-
 xen/arch/x86/hvm/vmx/entry.S|  28 ++-
 xen/arch/x86/hvm/vmx/vmx.c  |  23 +-
 xen/arch/x86/indirect_thunk.S   |  39 
 xen/arch/x86/msr.c  |  49 +
 xen/arch/x86/pv/domain.c|   1 -
 xen/arch/x86/pv/emul-priv-op.c  |  43 +++-
 xen/arch/x86/setup.c|   4 +
 xen/arch/x86/smpboot.c  |   2 +
 xen/arch/x86/spec_ctrl.c| 328 
 xen/arch/x86/x86_64/asm-offsets.c   |   6 +
 xen/arch/x86/x86_64/compat/entry.S

[Xen-devel] [PATCH v6.5 04/26] x86: Introduce a common cpuid_policy_updated()

[Andrew Cooper]

No practical change at the moment, but future changes will need to react
irrespective of guest type.

Signed-off-by: Andrew Cooper 
Reviewed-by: Wei Liu 
Acked-by: Jan Beulich 
---
 xen/arch/x86/domain.c| 12 
 xen/arch/x86/domctl.c|  4 ++--
 xen/arch/x86/hvm/hvm.c   |  2 --
 xen/include/asm-x86/domain.h |  2 ++
 4 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index b17468c..d383489 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -363,6 +363,8 @@ int vcpu_initialise(struct vcpu *v)
 
 if ( (rc = init_vcpu_msr_policy(v)) )
 goto fail;
+
+cpuid_policy_updated(v);
 }
 
 return rc;
@@ -2019,6 +2021,16 @@ int domain_relinquish_resources(struct domain *d)
 return 0;
 }
 
+/*
+ * Called during vcpu construction, and each time the toolstack changes the
+ * CPUID configuration for the domain.
+ */
+void cpuid_policy_updated(struct vcpu *v)
+{
+if ( is_hvm_vcpu(v) )
+hvm_cpuid_policy_changed(v);
+}
+
 void arch_dump_domain_info(struct domain *d)
 {
 paging_dump_domain_info(d);
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index cc7f433..5973d9f 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -294,12 +294,12 @@ static int update_domain_cpuid_info(struct domain *d,
 break;
 }
 
-if ( is_hvm_domain(d) && call_policy_changed )
+if ( call_policy_changed )
 {
 struct vcpu *v;
 
 for_each_vcpu( d, v )
-hvm_cpuid_policy_changed(v);
+cpuid_policy_updated(v);
 }
 
 return 0;
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 61df92c..6a1c752 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1555,8 +1555,6 @@ int hvm_vcpu_initialise(struct vcpu *v)
 hvm_set_guest_tsc(v, 0);
 }
 
-hvm_cpuid_policy_changed(v);
-
 return 0;
 
  fail6:
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index f699119..4679d54 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -79,6 +79,8 @@ void toggle_guest_mode(struct vcpu *);
 /* x86/64: toggle guest page tables between kernel and user modes. */
 void toggle_guest_pt(struct vcpu *);
 
+void cpuid_policy_updated(struct vcpu *v);
+
 /*
  * Initialise a hypercall-transfer page. The given pointer must be mapped
  * in Xen virtual address space (accesses are not validated or checked).
-- 
2.1.4


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

[Xen-devel] [xen-unstable test] 117557: trouble: broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-credit2  broken
 test-amd64-i386-qemuu-rhel6hvm-intel broken
 test-amd64-amd64-xl-qemuu-win7-amd64 broken
 test-amd64-amd64-xl-qemut-win7-amd64 broken
 test-amd64-i386-xl-qemuu-win10-i386 broken
 test-amd64-amd64-xl-qemuu-ws16-amd64 broken
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsmbroken

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 4 host-install(4) broken pass in 
117365
 test-amd64-i386-xl-qemuu-win10-i386  4 host-install(4)   broken pass in 117365
 test-amd64-amd64-xl-qemut-win7-amd64  4 host-install(4)  broken pass in 117365
 test-amd64-amd64-xl-qemuu-ws16-amd64  4 host-install(4)  broken pass in 117365
 test-amd64-i386-qemuu-rhel6hvm-intel  4 host-install(4)  broken pass in 117365
 test-amd64-amd64-xl-qemuu-win7-amd64  4 host-install(4)  broken pass in 117365
 test-amd64-amd64-xl-credit2   4 host-install(4)  broken pass in 117365
 test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail in 117365 
pass in 117557

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop  fail in 117365 like 117311
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop  fail in 117365 like 117311
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop  fail in 117365 like 117311
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail in 117365 never 
pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 117311
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 117311
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 117311
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 117311
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 117311
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 117311
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 117311
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  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  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-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  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-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail 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-libvirt 13 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-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-libvirt-raw 12 migrate-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-libvirt-xsm 13 migrate-support-checkfail   never pass
 

Re: [Xen-devel] PCI Device Subtree Change from Traditional to Upstream

[Kevin Stange]

On 01/03/2018 11:57 AM, Anthony PERARD wrote:
> On Wed, Dec 20, 2017 at 11:40:03AM -0600, Kevin Stange wrote:
>> Hi,
>>
>> I've been working on transitioning a number of Windows guests under HVM
>> from using QEMU traditional to QEMU upstream as is recommended in the
>> documentation.  When I move these guests, the PCI subtree for Xen
>> devices changes and Windows creates a totally new copy of each device.
>> Windows tracks down the storage without issue, but it treats the new
>> instance of the NIC driver as a new device and clears the network
>> configuration even though the MAC address is unchanged.  Manually
>> booting the guest back on the traditional device model reactivates the
>> original PCI subtree and the old network configuration with it.
>>
>> The only thing that I have been able to find that's substantially
>> different comparing the device trees is that the device instance ID
>> values differ on the parent Xen PCI device:
>>
>> PCI\VEN_5853_0001_00015853_01\3&267A616A&3&18
>>
>> PCI\VEN_5853_0001_00015853_01\3&267A616A&3&10
>>
>> Besides actually setting the guest to boot using QEMU traditional, is
>> there a way to convince Windows to treat these devices as the same?  A
>> patch-based solution would be acceptable to me if there is one, but I
>> don't understand the code well enough to create my own solution.
> 
> Hi Kevin,
> 
> I've got a patch to QEMU that seems to do the trick:
> 
> From: Anthony PERARD 
> Subject: [PATCH] xen-platform: Hardcode PCI slot to 3
> 
> Signed-off-by: Anthony PERARD 
> ---
>  hw/i386/pc_piix.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index 5e47528993..93e3a9a916 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -405,7 +405,7 @@ static void pc_xen_hvm_init(MachineState *machine)
>  
>  bus = pci_find_primary_bus();
>  if (bus != NULL) {
> -pci_create_simple(bus, -1, "xen-platform");
> +pci_create_simple(bus, PCI_DEVFN(3, 0), "xen-platform");
>  }
>  }
>  #endif
> 
> 
> The same thing could be done by libxl, by providing specific command
> line options to qemu. (I think that could even be done via a different
> config file for the guest.)

This patch doesn't seem to work for me.  It seems like the device model
process is exiting immediately, but I haven't been able to find any
information as to what is going wrong.  I tested with Xen 4.6.6 and the
QEMU packaged with that release.  Should I try it on a different version
of Xen and QEMU?

-- 
Kevin Stange
Chief Technology Officer
Steadfast | Managed Infrastructure, Datacenter and Cloud Services
800 S Wells, Suite 190 | Chicago, IL 60607
312.602.2689 X203 | Fax: 312.602.2688
ke...@steadfast.net | www.steadfast.net

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

[Xen-devel] Xen Security Advisory 254 - Information leak via side effects of speculative execution

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory XSA-254

Information leak via side effects of speculative execution

ISSUE DESCRIPTION
=

Processors give the illusion of a sequence of instructions executed
one-by-one.  However, in order to most efficiently use cpu resources,
modern superscalar processors actually begin executing many
instructions in parallel.  In cases where instructions depend on the
result of previous instructions or checks which have not yet
completed, execution happens based on guesses about what the outcome
will be.  If the guess is correct, execution has been sped up.  If the
guess is incorrect, partially-executed instructions are cancelled and
architectural state changes (to registers, memory, and so on)
reverted; but the whole process is no slower than if no guess had been
made at all.  This is sometimes called "speculative execution".

Unfortunately, although architectural state is rolled back, there are
other side effects, such as changes to TLB or cache state, which are
not rolled back.  These side effects can subsequently be detected by
an attacker to determine information about what happened during the
speculative execution phase.  If an attacker can cause speculative
execution to access sensitive memory areas, they may be able to infer
what that sensitive memory contained.

Furthermore, these guesses can often be 'poisoned', such that attacker
can cause logic to reliably 'guess' the way the attacker chooses.
This advisory discusses three ways to cause speculative execution to
access sensitive memory areas (named here according to the
discoverer's naming scheme):

SP1, "Bounds-check bypass": Poison the branch predictor, such that
operating system or hypervisor code is speculatively executed past
boundary and security checks.  This would allow an attacker to, for
instance, cause speculative code in the normal hypercall / emulation
path to execute with wild array indexes.

SP2, "Branch Target Injection": Poison the branch predictor.
Well-abstracted code often involves calling function pointers via
indirect branches; reading these function pointers may involve a
(slow) memory access, so the CPU attempts to guess where indirect
branches will lead.  Poisoning this enables an attacker to
speculatively branch to any code that exists in the hypervisor.

SP3, "Rogue Data Load": On some processors, certain pagetable
permission checks only happen when the instruction is retired;
effectively meaning that speculative execution is not subject to
pagetable permission checks.  On such processors, an attacker can
speculatively execute arbitrary code in userspace with, effectively,
the highest privilege level.

More information is available here:
  https://meltdownattack.com/
  https://spectreattack.com/

Additional Xen-specific background:

64-bit Xen hypervisors on systems with less than 5TiB of RAM map all
of physical RAM, so code speculatively executed in a hypervisor
context can read all of system RAM.

When running PV guests, the guest and the hypervisor share the address
space; guest kernels run in a lower privilege level, and Xen runs in
the highest privilege level.  (HVM and PVH guests run in a separate
address space to the hypervisor.)  However, only 64-bit PV guests can
generate addresses large enough to point to hypervisor memory.

IMPACT
==

Xen guests may be able to infer the contents of arbitrary host memory,
including memory assigned to other guests.

An attacker's choice of code to speculatively execute (and thus the
ease of extracting useful information) goes up with the numbers.  For
SP1, or SP2 on systems where SMEP (supervisor mode execute protection)
is enabled: an attacker is limited to windows of code after bound
checks of user-supplied indexes.  For SP2 without SMEP, or SP3, an
attacker can write arbitrary code to speculatively execute.

NOTE ON TIMING
==

This vulnerability was originally scheduled to be made public on 9
January.  It was accelerated at the request of the discloser due to
one of the issues being made public.

VULNERABLE SYSTEMS
==

Systems running all versions of Xen are affected.

For SP1 and SP2, both Intel and AMD are vulnerable.

For SP3, only Intel processors are vulnerable. Furthermore, only
64-bit PV guests can exploit SP3 against Xen.  PVH and 32-bit PV
guests cannot exploit SP3.

We believe that ARM is affected, but unfortunately due to the
accelerated schedule, we haven't been able to get concrete input from
ARM.  We are asking ARM and will publish more information when it is
available.

MITIGATION
==

There is no mitigation for SP1 and SP2.

SP3 can be mitigated by running guests in HVM or PVH mode.

For guests with legacy PV kernels which cannot be run in HVM mode, we
have developed a "shim" hypervisor that allows PV guests to run in PVH
mode.  Unfortunately, due to the accelerated schedule, this is not yet
ready to release.  We expect 

Re: [Xen-devel] [BUG] kernel bug encountered at drivers/net/xen-netback/netback.c:430!

[Christoph Moench-Tegeder]

## Paul Durrant (paul.durr...@citrix.com):

> How easy is it to trigger this? I'm assuming, from the original
> description, that I can probably trigger it by forcibly terminating
> a running domain and then trying to restart it.

As Alex said: in the "common cases" (like his and mine) it seems to
be enough to run a few DomUs and just wait a little (no special
load required) - with my 10 domains, the bg triggers in a few minutes
( https://lists.xenproject.org/archives/html/xen-devel/2017-12/msg01516.html
is my report of the issue - I didn't spot Alex' report).
The order of event here is:
- boot Dom0
- xl create a few DomUs (all recent Linux, all builder=hvm in my setup,
  each VM has exactly one virtual network interface, all bridged onto
  the one ethernet interface on the Dom0 which carries all traffic
  to the Dom0 and the DomUs)
- after a few minutes, the Dom0 kernel logs the BUG() in question
- shortly after (not immediately! - may take even some more minutes)
  the DomU behind the vif reported in the BUG becomes unresponsive:
  no network traffic, no reaction on the virtual console, no message
  in syslog).
- trying to xl destroy the unresponsive domain (or trying to do a
  normal shutdown on one of the other domains) results in the corrupted
  state documented in my earlier report (see link).

In my case this "cannot" be an issue with an old gcc - Debian 9 ships
with "gcc (Debian 6.3.0-18) 6.3.0 20170516" (but beware of new bugs,
who knows?).

I could try a new kernel (KPTI, yay!) with that "mildly suspicious" commit
cc8737a5fe9051b7fa052b08c57ddb9f539c389a reverted on the weekend and
report back (just to rule that out - like you, I don't really believe
that this is the cause).
For the record, I'm still running 4.13.16 on the Dom0 (that's the last
working Dom0 kernel).

Regards,
Christoph

-- 
Spare Space

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

[Xen-devel] [xen-4.10-testing test] 117549: trouble: blocked/broken/fail/pass

[osstest service owner]

flight 117549 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117549/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xtf  broken
 build-amd64-pvopsbroken
 test-amd64-i386-qemut-rhel6hvm-intel broken
 build-amd64-xtf   4 host-install(4)broken REGR. vs. 117130
 build-amd64-pvops 4 host-install(4)broken REGR. vs. 117130
 test-amd64-i386-qemut-rhel6hvm-intel 4 host-install(4) broken REGR. vs. 117130

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-11 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-21 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-xtf-amd64-amd64-31 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-41 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-qemut-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-xtf-amd64-amd64-51 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  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  13 migrate-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-xl-credit2  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-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 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  

[Xen-devel] [seabios test] 117584: regressions - FAIL

[osstest service owner]

flight 117584 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117584/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 115539

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115539
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 115539
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail 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-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 seabios  844b86464a5cbfffb62b87808632018ca250d867
baseline version:
 seabios  0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea

Last test of basis   115539  2017-11-03 20:48:58 Z   60 days
Failing since115733  2017-11-10 17:19:59 Z   54 days   60 attempts
Testing same since   117014  2017-12-08 19:11:23 Z   26 days   15 attempts


People who touched revisions under test:
  Kevin O'Connor 
  Paul Menzel 
  Stefan Berger 

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-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-ws16-amd64 fail
 test-amd64-i386-xl-qemuu-ws16-amd64  fail
 test-amd64-amd64-xl-qemuu-win10-i386 fail
 test-amd64-i386-xl-qemuu-win10-i386  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel 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


Not pushing.


commit 844b86464a5cbfffb62b87808632018ca250d867
Author: Paul Menzel 
Date:   Mon Oct 2 08:13:13 2017 +0200

docs/Download: Use more secure HTTPS URLs where possible

Signed-off-by: Paul Menzel 

commit df46d10c8a7b88eb82f3ceb2aa31782dee15593d
Author: Stefan Berger 
Date:   Tue Nov 14 15:03:47 2017 -0500

tpm: Add support for TPM2 ACPI table

Add support for the TPM2 ACPI table. If we find it and its
of the appropriate size, we can get the log_area_start_address
and log_area_minimum_size from it.

The latest version of the spec can be found here:

https://trustedcomputinggroup.org/tcg-acpi-specification/

Signed-off-by: Stefan Berger 

commit 0541f2f0f246e77d7c726926976920e8072d1119
Author: Kevin O'Connor 
Date:   Fri Nov 10 12:20:35 2017 -0500

paravirt: Only enable sercon in NOGRAPHIC mode if no other console specified

Re: [Xen-devel] [BUG] kernel bug encountered at drivers/net/xen-netback/netback.c:430!

[Alex Braunegg]

> How easy is it to trigger this? I'm assuming, from the original description, 
> that I can probably trigger it by forcibly terminating a running domain and 
> then trying to restart it.

For me the trigger was just having 2 VM's running and then within 24 hr's one 
would crash with the debug data sent to console / dmesg. I didn’t have to do 
anything special to trigger it - nor did I try / attempt to trigger it.

When attempting to restart the crashed VM (using xl) - that’s when I got the 
additional xl messages & the server rebooted.

> This breaks compilation of xen-netback with older compilers.
>>From kbuild bot with gcc-4.4.7:

My Xen version (and all packages other packages including the kernel) are built 
/ rebuilt using gcc 4.6.2 so I don’t think I am hitting this gcc issue that the 
patch fixed.

Best regards,

Alex




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

Re: [Xen-devel] PCI Device Subtree Change from Traditional to Upstream

[Anthony PERARD]

On Wed, Dec 20, 2017 at 11:40:03AM -0600, Kevin Stange wrote:
> Hi,
> 
> I've been working on transitioning a number of Windows guests under HVM
> from using QEMU traditional to QEMU upstream as is recommended in the
> documentation.  When I move these guests, the PCI subtree for Xen
> devices changes and Windows creates a totally new copy of each device.
> Windows tracks down the storage without issue, but it treats the new
> instance of the NIC driver as a new device and clears the network
> configuration even though the MAC address is unchanged.  Manually
> booting the guest back on the traditional device model reactivates the
> original PCI subtree and the old network configuration with it.
> 
> The only thing that I have been able to find that's substantially
> different comparing the device trees is that the device instance ID
> values differ on the parent Xen PCI device:
> 
> PCI\VEN_5853_0001_00015853_01\3&267A616A&3&18
> 
> PCI\VEN_5853_0001_00015853_01\3&267A616A&3&10
> 
> Besides actually setting the guest to boot using QEMU traditional, is
> there a way to convince Windows to treat these devices as the same?  A
> patch-based solution would be acceptable to me if there is one, but I
> don't understand the code well enough to create my own solution.

Hi Kevin,

I've got a patch to QEMU that seems to do the trick:

From: Anthony PERARD 
Subject: [PATCH] xen-platform: Hardcode PCI slot to 3

Signed-off-by: Anthony PERARD 
---
 hw/i386/pc_piix.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 5e47528993..93e3a9a916 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -405,7 +405,7 @@ static void pc_xen_hvm_init(MachineState *machine)
 
 bus = pci_find_primary_bus();
 if (bus != NULL) {
-pci_create_simple(bus, -1, "xen-platform");
+pci_create_simple(bus, PCI_DEVFN(3, 0), "xen-platform");
 }
 }
 #endif


The same thing could be done by libxl, by providing specific command
line options to qemu. (I think that could even be done via a different
config file for the guest.)

Regards,

-- 
Anthony PERARD

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

[Xen-devel] [linux-3.18 test] 117581: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-debianhvm-amd64   broken
 test-amd64-amd64-rumprun-amd64 broken
 test-armhf-armhf-xl-rtds broken
 test-amd64-i386-xl   broken
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm  broken
 test-amd64-i386-rumprun-i386 broken
 test-amd64-i386-xl4 host-install(4)broken REGR. vs. 117375
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 4 host-install(4) broken 
REGR. vs. 117375
 test-amd64-amd64-rumprun-amd64  4 host-install(4)  broken REGR. vs. 117375
 test-amd64-i386-rumprun-i386  4 host-install(4)broken REGR. vs. 117375
 test-amd64-amd64-xl-qemut-debianhvm-amd64 4 host-install(4) broken REGR. vs. 
117375

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  4 host-install(4)broken REGR. vs. 117375

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 117375
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 117375
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 117375
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 117375
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 117375
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 117375
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 117375
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 build-arm64-pvops 6 kernel-build fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail 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-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  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 13 migrate-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-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 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-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail 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-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-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-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linux   

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 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-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  f98689c6cd6b0d04e7a02c24ce08591216f910ab
baseline version:
 xen  7762c2d6f4382776d97446f3fdaa1838443720cb

Last test of basis   117604  2018-01-03 14:01:20 Z0 days
Testing same since   117606  2018-01-03 16:01:09 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

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
   7762c2d6f4..f98689c6cd  f98689c6cd6b0d04e7a02c24ce08591216f910ab -> smoke

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

Re: [Xen-devel] [PATCH v17 06/11] x86/hvm/ioreq: add a new mappable resource type...

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 03 January 2018 17:05
> To: Paul Durrant 
> Cc: JulienGrall ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Wei Liu
> ; StefanoStabellini ; xen-
> de...@lists.xenproject.org; Tim (Xen.org) 
> Subject: RE: [Xen-devel] [PATCH v17 06/11] x86/hvm/ioreq: add a new
> mappable resource type...
> 
> >>> On 03.01.18 at 17:48,  wrote:
> >>  -Original Message-
> >> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On
> Behalf
> >> Of Jan Beulich
> >> >>> On 03.01.18 at 17:06,  wrote:
> >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> >> Sent: 03 January 2018 15:48
> >> >> >>> On 03.01.18 at 13:19,  wrote:
> >> >> What is additionally confusing me is the page ownership: Wasn't
> >> >> the (original) intention to make the pages owned by the emulator
> >> >> domain rather than the guest? I seem to recall you referring to
> >> >> restrictions in do_mmu_update(), but a domain should always be
> >> >> able to map pages it owns, shouldn't it?
> >> >
> >> > I'm sure we had this discussion before. I am trying to make resource
> >> mapping
> >> > as uniform as possible so, like the grant table pages, the ioreq server
> pages
> >> > are assigned to the target domain. Otherwise the domain trying to map
> >> > resources has know which actual domain they are assigned to, rather
> than
> >> the
> >> > domain they relate to... which is pretty ugly.
> >>
> >> Didn't I suggest a slight change to the interface to actually make
> >> this not as ugly?
> >
> > Yes, you did but I didn't really want to go that way unless I absolutely had
> > to. If you'd really prefer things that way then I'll re-work the hypercall 
> > to
> > allow the domain owning the resource pages to be passed back. Maybe it
> will
> > ultimately end up neater.
> 
> A 3rd opinion wouldn't hurt before you invest much time.
> 

Andrew,

  Do you have any particular preferences on whether ioreq server pages are 
assigned to the tools domain or the target domain (the former requiring a tweak 
to the hypercall to pass back the owner of the resource pages)?

  Paul

> Jan


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

Re: [Xen-devel] [PATCH v4 1/4] x86emul: Support GFNI insns

[Jan Beulich]

>>> On 03.01.18 at 09:26,  wrote:
> @@ -7741,6 +7752,16 @@ x86_emulate(
>  op_bytes = 16;
>  goto simd_0f3a_common;
>  
> +case X86EMUL_OPC_66(0x0f3a, 0xce): /* gf2p8affineqb 
> $imm8,xmm/m128,xmm,xmm */
> +case X86EMUL_OPC_VEX_66(0x0f3a, 0xce): /* vgf2p8affineqb 
> $imm8,{x,y}mm/mem,{x,y}mm,{x,y}mm */
> +case X86EMUL_OPC_66(0x0f3a, 0xcf): /* gf2p8affineinvqb 
> $imm8,xmm/m128,xmm,xmm */
> +case X86EMUL_OPC_VEX_66(0x0f3a, 0xcf): /* vgf2p8affineinvqb 
> $imm8,{x,y}mm/mem,{x,y}mm,{x,y}mm */
> +host_and_vcpu_must_have(gfni);
> +if ( vex.opcx == vex_none )
> +goto simd_0f3a_common;
> +generate_exception_if(vex.w, EXC_UD);

The documentation says .W1, but I of course don't know whether
you meanwhile tested your code (you still don't add a test case)
and the doc is wrong, or this needs to be !vex.w.

Jan


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

Re: [Xen-devel] [PATCH] xen: Add EFI_LOAD_OPTION support

[Tamas K Lengyel]

On Wed, Jan 3, 2018 at 9:36 AM, Jan Beulich  wrote:
 On 03.01.18 at 17:04,  wrote:
>> On Wed, Jan 3, 2018 at 4:20 AM, Jan Beulich  wrote:
>> On 02.01.18 at 16:56,  wrote:
 +if ( elo->Attributes & LOAD_OPTION_ACTIVE )
>>>
>>> Without any other (earlier) check, how can you reliably tell this
>>> being a pointer to EFI_LOAD_OPTION from it being the
>>> currently used one to CHAR16? Is the distinction perhaps UEFI
>>> version dependent? In the 2.3 spec I can't find any information
>>> on the layout of what ->LoadOptions points to.
>>
>> AFAICT there is no clear cut way to distinguish what is being passed
>> here. When launched via UEFI Xen receives the EFI_LOAD_OPTION buffer
>> here already, which it tries to parse as a string and fails. Take a
>> look at the same problem in the shim:
>> https://github.com/rhboot/shim/blob/master/shim.c#L2501. If there is a
>> clearer way to distinguish what is being passed here or more checks
>> that can be done I would be open for suggestions.
>
> Well, first of all the code you point to tells me that this situation is
> indeed as bad as it can be. However, the code also shows you
> some heuristics you could re-use.

From what I've seen the only heuristic we could copy is counting ucs2
strings in the buffer. I wasn't entirely convinced that it's necessary
and rather went with the "if it looks like a duck, swims like a duck,
and quacks like a duck, then it probably is a duck" test. What are the
chances we could encounter a string that also properly parses as an
EFI_LOAD_OPTION buffer passing the checks in place in this patch?
Anyway, if the ucs2 string counting is something we also want to
utilize, I have nothing against it.

> What they don't seem to utilize
> is the fact that as long as there are few enough bits defined for
> the Attributes field, checking that one for being a printable
> character (and the upper 16 bits to be non-null) might give a good
> indication what form we're dealing with. In fact it might be that
> when it's a string, the first character is always '\', but I'm afraid
> that's not written down anywhere.
>

I don't think that's true, when I printed this buffer when launched
through the shell (after entering the xen folder on the ESP) it
started with "xen.efi".

Tamas

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

Re: [Xen-devel] [PATCH v17 06/11] x86/hvm/ioreq: add a new mappable resource type...

[Paul Durrant]

> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Jan Beulich
> Sent: 03 January 2018 16:41
> To: Paul Durrant 
> Cc: StefanoStabellini ; Wei Liu
> ; Andrew Cooper ; Tim
> (Xen.org) ; George Dunlap ;
> JulienGrall ; xen-devel@lists.xenproject.org; Ian
> Jackson 
> Subject: Re: [Xen-devel] [PATCH v17 06/11] x86/hvm/ioreq: add a new
> mappable resource type...
> 
> >>> On 03.01.18 at 17:06,  wrote:
> >>  -Original Message-
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: 03 January 2018 15:48
> >> To: Paul Durrant 
> >> Cc: JulienGrall ; Andrew Cooper
> >> ; Wei Liu ; George
> >> Dunlap ; Ian Jackson
> ;
> >> Stefano Stabellini ; xen-
> de...@lists.xenproject.org;
> >> Konrad Rzeszutek Wilk ; Tim (Xen.org)
> >> 
> >> Subject: Re: [PATCH v17 06/11] x86/hvm/ioreq: add a new mappable
> >> resource type...
> >>
> >> >>> On 03.01.18 at 13:19,  wrote:
> >> > +static void hvm_free_ioreq_mfn(struct hvm_ioreq_server *s, bool
> buf)
> >> > +{
> >> > +struct domain *d = s->domain;
> >> > +struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
> >> > +
> >> > +if ( !iorp->page )
> >> > +return;
> >> > +
> >> > +page_list_add_tail(iorp->page, 
> >> >arch.hvm_domain.ioreq_server.pages);
> >>
> >> Afaict s->domain is the guest, not the domain containing the
> >> emulator. Hence this new model of freeing the pages is safe only
> >> when the emulator domain is dead by the time the guest is being
> >> cleaned up.
> >
> > From the investigations done w.r.t. the grant table pages I don't think this
> > is the case. The emulating domain will have references on the pages and
> this
> > keeps the target domain in existence, only completing domain destruction
> when
> > the references are finally dropped. I've tested this by leaving an emulator
> > running whilst I 'xl destroy' the domain; the domain remains as a zombie
> > until emulator terminates.
> 
> Oh, right, I forgot about that aspect.
> 
> >> What is additionally confusing me is the page ownership: Wasn't
> >> the (original) intention to make the pages owned by the emulator
> >> domain rather than the guest? I seem to recall you referring to
> >> restrictions in do_mmu_update(), but a domain should always be
> >> able to map pages it owns, shouldn't it?
> >
> > I'm sure we had this discussion before. I am trying to make resource
> mapping
> > as uniform as possible so, like the grant table pages, the ioreq server 
> > pages
> > are assigned to the target domain. Otherwise the domain trying to map
> > resources has know which actual domain they are assigned to, rather than
> the
> > domain they relate to... which is pretty ugly.
> 
> Didn't I suggest a slight change to the interface to actually make
> this not as ugly?

Yes, you did but I didn't really want to go that way unless I absolutely had 
to. If you'd really prefer things that way then I'll re-work the hypercall to 
allow the domain owning the resource pages to be passed back. Maybe it will 
ultimately end up neater.

> 
> >> Furthermore you continue to use Xen heap pages rather than
> >> domain heap ones.
> >
> > Yes, this seems reasonable since Xen will always need mappings of the
> pages
> > and the aforementioned reference counting only works for Xen heap
> pages AIUI.
> 
> share_xen_page_with_guest() makes any page a Xen heap one.

Oh, that's somewhat counter-intuitive.

> See vmx_alloc_vlapic_mapping() for an example.
> 

Ok, thanks. If change back to having the pages owned by the tools domain then I 
guess this will all be avoided anyway.

  Paul

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

Re: [Xen-devel] [PATCH v17 06/11] x86/hvm/ioreq: add a new mappable resource type...

[Jan Beulich]

>>> On 03.01.18 at 17:06,  wrote:
>>  -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 03 January 2018 15:48
>> To: Paul Durrant 
>> Cc: JulienGrall ; Andrew Cooper
>> ; Wei Liu ; George
>> Dunlap ; Ian Jackson ;
>> Stefano Stabellini ; xen-devel@lists.xenproject.org;
>> Konrad Rzeszutek Wilk ; Tim (Xen.org)
>> 
>> Subject: Re: [PATCH v17 06/11] x86/hvm/ioreq: add a new mappable
>> resource type...
>> 
>> >>> On 03.01.18 at 13:19,  wrote:
>> > +static void hvm_free_ioreq_mfn(struct hvm_ioreq_server *s, bool buf)
>> > +{
>> > +struct domain *d = s->domain;
>> > +struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
>> > +
>> > +if ( !iorp->page )
>> > +return;
>> > +
>> > +page_list_add_tail(iorp->page, 
>> >arch.hvm_domain.ioreq_server.pages);
>> 
>> Afaict s->domain is the guest, not the domain containing the
>> emulator. Hence this new model of freeing the pages is safe only
>> when the emulator domain is dead by the time the guest is being
>> cleaned up.
> 
> From the investigations done w.r.t. the grant table pages I don't think this 
> is the case. The emulating domain will have references on the pages and this 
> keeps the target domain in existence, only completing domain destruction when 
> the references are finally dropped. I've tested this by leaving an emulator 
> running whilst I 'xl destroy' the domain; the domain remains as a zombie 
> until emulator terminates.

Oh, right, I forgot about that aspect.

>> What is additionally confusing me is the page ownership: Wasn't
>> the (original) intention to make the pages owned by the emulator
>> domain rather than the guest? I seem to recall you referring to
>> restrictions in do_mmu_update(), but a domain should always be
>> able to map pages it owns, shouldn't it?
> 
> I'm sure we had this discussion before. I am trying to make resource mapping 
> as uniform as possible so, like the grant table pages, the ioreq server pages 
> are assigned to the target domain. Otherwise the domain trying to map 
> resources has know which actual domain they are assigned to, rather than the 
> domain they relate to... which is pretty ugly.

Didn't I suggest a slight change to the interface to actually make
this not as ugly?

>> Furthermore you continue to use Xen heap pages rather than
>> domain heap ones.
> 
> Yes, this seems reasonable since Xen will always need mappings of the pages 
> and the aforementioned reference counting only works for Xen heap pages AIUI.

share_xen_page_with_guest() makes any page a Xen heap one.
See vmx_alloc_vlapic_mapping() for an example.

Jan


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

Re: [Xen-devel] [PATCH] xen: Add EFI_LOAD_OPTION support

[Jan Beulich]

>>> On 03.01.18 at 17:04,  wrote:
> On Wed, Jan 3, 2018 at 4:20 AM, Jan Beulich  wrote:
> On 02.01.18 at 16:56,  wrote:
>>> +if ( elo->Attributes & LOAD_OPTION_ACTIVE )
>>
>> Without any other (earlier) check, how can you reliably tell this
>> being a pointer to EFI_LOAD_OPTION from it being the
>> currently used one to CHAR16? Is the distinction perhaps UEFI
>> version dependent? In the 2.3 spec I can't find any information
>> on the layout of what ->LoadOptions points to.
> 
> AFAICT there is no clear cut way to distinguish what is being passed
> here. When launched via UEFI Xen receives the EFI_LOAD_OPTION buffer
> here already, which it tries to parse as a string and fails. Take a
> look at the same problem in the shim:
> https://github.com/rhboot/shim/blob/master/shim.c#L2501. If there is a
> clearer way to distinguish what is being passed here or more checks
> that can be done I would be open for suggestions.

Well, first of all the code you point to tells me that this situation is
indeed as bad as it can be. However, the code also shows you
some heuristics you could re-use. What they don't seem to utilize
is the fact that as long as there are few enough bits defined for
the Attributes field, checking that one for being a printable
character (and the upper 16 bits to be non-null) might give a good
indication what form we're dealing with. In fact it might be that
when it's a string, the first character is always '\', but I'm afraid
that's not written down anywhere.

Jan


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

[Xen-devel] [xen-4.9-testing test] 117535: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

flight 117535 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117535/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-multivcpu broken
 test-amd64-i386-xl-qemut-ws16-amd64 broken
 build-armhf-pvopsbroken
 test-amd64-i386-xl-qemut-debianhvm-amd64broken
 test-amd64-amd64-xl-multivcpu  4 host-install(4)   broken REGR. vs. 116619
 test-amd64-i386-xl-qemut-ws16-amd64  4 host-install(4) broken REGR. vs. 116619
 test-amd64-i386-xl-qemut-debianhvm-amd64 4 host-install(4) broken REGR. vs. 
116619
 build-armhf-pvops 5 host-build-prep  fail REGR. vs. 116619
 test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
116619
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
116619

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-ws16-amd64 14 guest-localmigrate fail REGR. vs. 
116619

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 116619
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 116619
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 116619
 test-amd64-i386-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail like 116619
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-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-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-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-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail 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-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-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 xen  d6fe1860285bd4e3e3f1f6cc96f7d64200bc2138
baseline version:
 xen  0a0dcdcd20e9711cbfb08db5b21af5299ee1eb8b

Last test of basis   116619  2017-11-28 12:49:51 Z   36 days
Failing since117096  2017-12-12 14:19:03 Z   22 days9 attempts
Testing same since   117535  2018-01-02 17:40:18 Z0 days1 attempts


People who touched revisions under test:
  Adrian Pop 
  Andrew Cooper 
  Daniel Kiper 
  George Dunlap 
  Ingo Molnar 
  Jan Beulich 
  Kevin Tian 
  Paul Durrant 
  Ross Lagerwall 
  Sergey Dyasli 
  Stefano Stabellini 
  Thomas Gleixner 
  Tom Lendacky 

jobs:
 build-amd64-xsm 

Re: [Xen-devel] [PATCH v17 06/11] x86/hvm/ioreq: add a new mappable resource type...

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 03 January 2018 15:48
> To: Paul Durrant 
> Cc: JulienGrall ; Andrew Cooper
> ; Wei Liu ; George
> Dunlap ; Ian Jackson ;
> Stefano Stabellini ; xen-devel@lists.xenproject.org;
> Konrad Rzeszutek Wilk ; Tim (Xen.org)
> 
> Subject: Re: [PATCH v17 06/11] x86/hvm/ioreq: add a new mappable
> resource type...
> 
> >>> On 03.01.18 at 13:19,  wrote:
> > +static void hvm_free_ioreq_mfn(struct hvm_ioreq_server *s, bool buf)
> > +{
> > +struct domain *d = s->domain;
> > +struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
> > +
> > +if ( !iorp->page )
> > +return;
> > +
> > +page_list_add_tail(iorp->page, 
> >arch.hvm_domain.ioreq_server.pages);
> 
> Afaict s->domain is the guest, not the domain containing the
> emulator. Hence this new model of freeing the pages is safe only
> when the emulator domain is dead by the time the guest is being
> cleaned up.

From the investigations done w.r.t. the grant table pages I don't think this is 
the case. The emulating domain will have references on the pages and this keeps 
the target domain in existence, only completing domain destruction when the 
references are finally dropped. I've tested this by leaving an emulator running 
whilst I 'xl destroy' the domain; the domain remains as a zombie until emulator 
terminates.

> I'm not only unaware of this being enforced anywhere,
> but also unconvinced this is a desirable restriction: Why shouldn't
> emulator domains be allowed to be long lived, servicing more than
> a single guest if so desired by the admin?
> 
> What is additionally confusing me is the page ownership: Wasn't
> the (original) intention to make the pages owned by the emulator
> domain rather than the guest? I seem to recall you referring to
> restrictions in do_mmu_update(), but a domain should always be
> able to map pages it owns, shouldn't it?
> 

I'm sure we had this discussion before. I am trying to make resource mapping as 
uniform as possible so, like the grant table pages, the ioreq server pages are 
assigned to the target domain. Otherwise the domain trying to map resources has 
know which actual domain they are assigned to, rather than the domain they 
relate to... which is pretty ugly.

> Furthermore you continue to use Xen heap pages rather than
> domain heap ones.
> 

Yes, this seems reasonable since Xen will always need mappings of the pages and 
the aforementioned reference counting only works for Xen heap pages AIUI.

> And finally I'm still missing the is_hvm_domain() check in
> hvm_get_ioreq_server_frame(). Nor is there a NULL check for
> the return value of get_ioreq_server(), as I notice only now.
> 

Dammit. I forgot about the is_hvm_domain() check over Christmas. I'll add those 
two.

  Paul

> Jan


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

Re: [Xen-devel] [PATCH] xen: Add EFI_LOAD_OPTION support

[Tamas K Lengyel]

On Wed, Jan 3, 2018 at 4:20 AM, Jan Beulich  wrote:
 On 02.01.18 at 16:56,  wrote:
>> When booting Xen via UEFI the Xen config file can contain multiple sections
>> each describing different boot options. It is currently only possible to 
>> choose
>> which section to boot with if Xen is started through an EFI Shell.
>
> Is this true? I thought that EFI Boot Manager entries can very well
> have command line options. And other boot loaders (e.g. grub2)
> should provide their own means to hand over options.

Maybe the comment is inaccurate in that if you use grub or some other
bootloader it can also specify which section to use from the Xen
config. I only tried it with the Shell though so I can't speak for
other bootloaders. If Xen is being launched directly by UEFI (or by
the shim) the only way to specify the section is with
EFI_LOAD_OPTION's OptionalData. When you do that though the current
command line parsing code won't work because it's not a string:

# efibootmgr -w -L "Xen" -l "\EFI\xen\xen.efi" -c -d /dev/nvme0n1
--part 1 -e 3 -u "section5"
# efivar -p --name 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot
GUID: 8be4df61-93ca-11d2-aa0d-00e098032b8c
Name: "Boot"
Attributes:
Non-Volatile
Boot Service Access
Runtime Service Access
Value:
  01 00 00 00 7c 00 58 00  65 00 6e 00 00 00 02 01  ||.X.e.n.|
0010  0c 00 d0 41 03 0a 00 00  00 00 01 01 06 00 00 1d  |...A|
0020  01 01 06 00 00 00 03 17  10 00 01 00 00 00 00 08  ||
0030  0d 03 00 0b a8 e0 04 01  2a 00 01 00 00 00 00 08  |*...|
0040  00 00 00 00 00 00 00 00  10 00 00 00 00 00 9b e2  ||
0050  c5 ff 57 fa 3d 48 a5 de  00 53 f8 7a bd c4 02 02  |..W.=H...S.z|
0060  04 04 26 00 5c 00 45 00  46 00 49 00 5c 00 78 00  |..&.\.E.F.I.\.x.|
0070  65 00 6e 00 5c 00 78 00  65 00 6e 00 2e 00 65 00  |e.n.\.x.e.n...e.|
0080  66 00 69 00 00 00 7f ff  04 00 73 00 65 00 63 00  |f.i...s.e.c.|
0090  74 00 69 00 6f 00 6e 00  35 00|t.i.o.n.5.  |

>> +if ( elo->Attributes & LOAD_OPTION_ACTIVE )
>
> Without any other (earlier) check, how can you reliably tell this
> being a pointer to EFI_LOAD_OPTION from it being the
> currently used one to CHAR16? Is the distinction perhaps UEFI
> version dependent? In the 2.3 spec I can't find any information
> on the layout of what ->LoadOptions points to.

AFAICT there is no clear cut way to distinguish what is being passed
here. When launched via UEFI Xen receives the EFI_LOAD_OPTION buffer
here already, which it tries to parse as a string and fails. Take a
look at the same problem in the shim:
https://github.com/rhboot/shim/blob/master/shim.c#L2501. If there is a
clearer way to distinguish what is being passed here or more checks
that can be done I would be open for suggestions.

>> --- a/xen/include/efi/efiapi.h
>> +++ b/xen/include/efi/efiapi.h
>
> Generally additions to this file are expected to come from the gnu-efi
> package, which it was originally cloned from. I've just checked and
> see that 3.0.6 doesn't appear to have any of this (yet). In such a
> case at the very least you should match pre-existing style (e.g.
> indentation). Commonly, however, we introduce such private
> (and temporary) definitions into the source file that needs them (see
> e.g. the Apple Properties interface).

This part I took as-is from
tools/firmware/etherboot/ipxe/src/include/ipxe/efi/Uefi/UefiSpec.h as
found in the Xen source tree.

Tamas

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

Re: [Xen-devel] [PATCH v17 06/11] x86/hvm/ioreq: add a new mappable resource type...

[Jan Beulich]

>>> On 03.01.18 at 13:19,  wrote:
> +static void hvm_free_ioreq_mfn(struct hvm_ioreq_server *s, bool buf)
> +{
> +struct domain *d = s->domain;
> +struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
> +
> +if ( !iorp->page )
> +return;
> +
> +page_list_add_tail(iorp->page, >arch.hvm_domain.ioreq_server.pages);

Afaict s->domain is the guest, not the domain containing the
emulator. Hence this new model of freeing the pages is safe only
when the emulator domain is dead by the time the guest is being
cleaned up. I'm not only unaware of this being enforced anywhere,
but also unconvinced this is a desirable restriction: Why shouldn't
emulator domains be allowed to be long lived, servicing more than
a single guest if so desired by the admin?

What is additionally confusing me is the page ownership: Wasn't
the (original) intention to make the pages owned by the emulator
domain rather than the guest? I seem to recall you referring to
restrictions in do_mmu_update(), but a domain should always be
able to map pages it owns, shouldn't it?

Furthermore you continue to use Xen heap pages rather than
domain heap ones.

And finally I'm still missing the is_hvm_domain() check in
hvm_get_ioreq_server_frame(). Nor is there a NULL check for
the return value of get_ioreq_server(), as I notice only now.

Jan


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 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-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  7762c2d6f4382776d97446f3fdaa1838443720cb
baseline version:
 xen  d287c90369d870f15cc3b3cf113287093e7118b9

Last test of basis   117600  2018-01-03 11:01:18 Z0 days
Testing same since   117604  2018-01-03 14:01:20 Z0 days1 attempts


People who touched revisions under test:
  Andrew Morton 
  David Woodhouse 
  Jan Beulich 
  Linus Torvalds 
  Michel Lespinasse 
  Praveen Kumar 
  Rik van Riel 
  Wei Yang 

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
   d287c90369..7762c2d6f4  7762c2d6f4382776d97446f3fdaa1838443720cb -> smoke

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

[Xen-devel] [PATCH v3] x86/hvm: Add MSR old value

[Alexandru Isaila]

This patch adds the old value param and the onchangeonly option
to the VM_EVENT_REASON_MOV_TO_MSR event.

The param was added to the vm_event_mov_to_msr struct and to the
hvm_monitor_msr function. Finally I've changed the bool_t param
to a bool for the hvm_msr_write_intercept function.

Signed-off-by: Alexandru Isaila 
Acked-by: Tamas K Lengyel 
Acked-by: Wei Liu 
Acked-by: Jan Beulich 

---
Changes since V2:
- Rb V2
---
 tools/libxc/include/xenctrl.h |  2 +-
 tools/libxc/xc_monitor.c  |  3 ++-
 xen/arch/x86/hvm/hvm.c| 10 --
 xen/arch/x86/hvm/monitor.c|  9 ++---
 xen/arch/x86/monitor.c| 27 ---
 xen/include/asm-x86/hvm/monitor.h |  2 +-
 xen/include/asm-x86/hvm/support.h |  2 +-
 xen/include/asm-x86/monitor.h |  1 +
 xen/include/public/domctl.h   |  2 ++
 xen/include/public/vm_event.h |  5 +++--
 10 files changed, 49 insertions(+), 14 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 666db0b..09e1363 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2048,7 +2048,7 @@ int xc_monitor_write_ctrlreg(xc_interface *xch, uint32_t 
domain_id,
  * non-architectural indices.
  */
 int xc_monitor_mov_to_msr(xc_interface *xch, uint32_t domain_id, uint32_t msr,
-  bool enable);
+  bool enable, bool onchangeonly);
 int xc_monitor_singlestep(xc_interface *xch, uint32_t domain_id, bool enable);
 int xc_monitor_software_breakpoint(xc_interface *xch, uint32_t domain_id,
bool enable);
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index 2840f14..0233b87 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -90,7 +90,7 @@ int xc_monitor_write_ctrlreg(xc_interface *xch, uint32_t 
domain_id,
 }
 
 int xc_monitor_mov_to_msr(xc_interface *xch, uint32_t domain_id, uint32_t msr,
-  bool enable)
+  bool enable, bool onchangeonly)
 {
 DECLARE_DOMCTL;
 
@@ -100,6 +100,7 @@ int xc_monitor_mov_to_msr(xc_interface *xch, uint32_t 
domain_id, uint32_t msr,
 : XEN_DOMCTL_MONITOR_OP_DISABLE;
 domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR;
 domctl.u.monitor_op.u.mov_to_msr.msr = msr;
+domctl.u.monitor_op.u.mov_to_msr.onchangeonly = onchangeonly;
 
 return do_domctl(xch, );
 }
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 28bc7e4..2185ddc 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3534,7 +3534,7 @@ int hvm_msr_read_intercept(unsigned int msr, uint64_t 
*msr_content)
 }
 
 int hvm_msr_write_intercept(unsigned int msr, uint64_t msr_content,
-bool_t may_defer)
+bool may_defer)
 {
 struct vcpu *v = current;
 struct domain *d = v->domain;
@@ -3545,6 +3545,12 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t 
msr_content,
 
 if ( may_defer && unlikely(monitored_msr(v->domain, msr)) )
 {
+uint64_t msr_old_content;
+
+ret = hvm_msr_read_intercept(msr, _old_content);
+if ( ret != X86EMUL_OKAY )
+return ret;
+
 ASSERT(v->arch.vm_event);
 
 /* The actual write will occur in hvm_do_resume() (if permitted). */
@@ -3552,7 +3558,7 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t 
msr_content,
 v->arch.vm_event->write_data.msr = msr;
 v->arch.vm_event->write_data.value = msr_content;
 
-hvm_monitor_msr(msr, msr_content);
+hvm_monitor_msr(msr, msr_content, msr_old_content);
 return X86EMUL_OKAY;
 }
 
diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
index 4ce778c..131b852 100644
--- a/xen/arch/x86/hvm/monitor.c
+++ b/xen/arch/x86/hvm/monitor.c
@@ -74,16 +74,19 @@ bool hvm_monitor_emul_unimplemented(void)
 monitor_traps(curr, true, ) == 1;
 }
 
-void hvm_monitor_msr(unsigned int msr, uint64_t value)
+void hvm_monitor_msr(unsigned int msr, uint64_t new_value, uint64_t old_value)
 {
 struct vcpu *curr = current;
 
-if ( monitored_msr(curr->domain, msr) )
+if ( monitored_msr(curr->domain, msr) &&
+ (!monitored_msr_onchangeonly(curr->domain, msr) ||
+   new_value != old_value) )
 {
 vm_event_request_t req = {
 .reason = VM_EVENT_REASON_MOV_TO_MSR,
 .u.mov_to_msr.msr = msr,
-.u.mov_to_msr.value = value,
+.u.mov_to_msr.new_value = new_value,
+.u.mov_to_msr.old_value = old_value
 };
 
 monitor_traps(curr, 1, );
diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
index e59f1f5..f229e69 100644
--- a/xen/arch/x86/monitor.c
+++ b/xen/arch/x86/monitor.c
@@ -25,7 +25,8 @@
 int 

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 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-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  d287c90369d870f15cc3b3cf113287093e7118b9
baseline version:
 xen  971d299c04df379734d10c44d637433e9e564f36

Last test of basis   117565  2018-01-02 18:02:18 Z0 days
Testing same since   117600  2018-01-03 11:01:18 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

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
   971d299c04..d287c90369  d287c90369d870f15cc3b3cf113287093e7118b9 -> smoke

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

[Xen-devel] [PATCH v17 10/11] common: add a new mappable resource type: XENMEM_resource_grant_table

[Paul Durrant]

This patch allows grant table frames to be mapped using the
XENMEM_acquire_resource memory op.

NOTE: This patch expands the on-stack mfn_list array in acquire_resource()
  but it is still small enough to remain on-stack.

Signed-off-by: Paul Durrant 
Reviewed-by: Jan Beulich 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 

v13:
 - Re-work the internals to avoid using the XENMAPIDX_grant_table_status
   hack.

v12:
 - Dropped limit checks as requested by Jan.

v10:
 - Addressed comments from Jan.

v8:
 - The functionality was originally incorporated into the earlier patch
   "x86/mm: add HYPERVISOR_memory_op to acquire guest resources".
---
 xen/common/grant_table.c  | 63 +--
 xen/common/memory.c   | 45 ++-
 xen/include/public/memory.h   |  6 +
 xen/include/xen/grant_table.h |  4 +++
 4 files changed, 109 insertions(+), 9 deletions(-)

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 250450bdda..c4fee21347 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -3770,21 +3770,21 @@ int mem_sharing_gref_to_gfn(struct grant_table *gt, 
grant_ref_t ref,
 }
 #endif
 
-int gnttab_map_frame(struct domain *d, unsigned long idx, gfn_t gfn,
- mfn_t *mfn)
+/* Caller must hold write lock as version may change and table may grow */
+static int gnttab_get_frame(struct domain *d, bool is_status,
+unsigned long idx, mfn_t *mfn)
 {
-int rc = 0;
 struct grant_table *gt = d->grant_table;
-
-grant_write_lock(gt);
+int rc = 0;
 
 if ( gt->gt_version == 0 )
 gt->gt_version = 1;
 
-if ( gt->gt_version == 2 &&
- (idx & XENMAPIDX_grant_table_status) )
+if ( is_status )
 {
-idx &= ~XENMAPIDX_grant_table_status;
+if ( gt->gt_version != 2 )
+return -EINVAL;
+
 if ( idx < nr_status_frames(gt) )
 *mfn = _mfn(virt_to_mfn(gt->status[idx]));
 else
@@ -3801,6 +3801,25 @@ int gnttab_map_frame(struct domain *d, unsigned long 
idx, gfn_t gfn,
 rc = -EINVAL;
 }
 
+return rc;
+}
+
+int gnttab_map_frame(struct domain *d, unsigned long idx, gfn_t gfn,
+ mfn_t *mfn)
+{
+struct grant_table *gt = d->grant_table;
+bool is_status = false;
+int rc;
+
+grant_write_lock(gt);
+
+if ( idx & XENMAPIDX_grant_table_status )
+{
+is_status = true;
+idx &= ~XENMAPIDX_grant_table_status;
+}
+
+rc = gnttab_get_frame(d, is_status, idx, mfn);
 if ( !rc )
 gnttab_set_frame_gfn(gt, idx, gfn);
 
@@ -3809,6 +3828,34 @@ int gnttab_map_frame(struct domain *d, unsigned long 
idx, gfn_t gfn,
 return rc;
 }
 
+int gnttab_get_grant_frame(struct domain *d, unsigned long idx,
+   mfn_t *mfn)
+{
+struct grant_table *gt = d->grant_table;
+int rc;
+
+/* write lock required as version may change and/or table may grow */
+grant_write_lock(gt);
+rc = gnttab_get_frame(d, false, idx, mfn);
+grant_write_unlock(gt);
+
+return rc;
+}
+
+int gnttab_get_status_frame(struct domain *d, unsigned long idx,
+mfn_t *mfn)
+{
+struct grant_table *gt = d->grant_table;
+int rc;
+
+/* write lock required as version may change and/or table may grow */
+grant_write_lock(gt);
+rc = gnttab_get_frame(d, true, idx, mfn);
+grant_write_unlock(gt);
+
+return rc;
+}
+
 static void gnttab_usage_print(struct domain *rd)
 {
 int first = 1;
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 3d810606da..905865f116 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -944,6 +945,43 @@ static long xatp_permission_check(struct domain *d, 
unsigned int space)
 return xsm_add_to_physmap(XSM_TARGET, current->domain, d);
 }
 
+static int acquire_grant_table(struct domain *d, unsigned int id,
+   unsigned long frame,
+   unsigned int nr_frames,
+   xen_pfn_t mfn_list[])
+{
+unsigned int i = nr_frames;
+
+/* Iterate backwards in case table needs to grow */
+while ( i-- != 0 )
+{
+mfn_t mfn = INVALID_MFN;
+int rc;
+
+switch ( id )
+{
+case XENMEM_resource_grant_table_id_grant:
+rc = gnttab_get_grant_frame(d, frame + i, );
+break;
+
+case XENMEM_resource_grant_table_id_status:
+rc = gnttab_get_status_frame(d, frame + i, );
+break;
+
+   

[Xen-devel] [PATCH v17 01/11] x86/hvm/ioreq: maintain an array of ioreq servers rather than a list

[Paul Durrant]

A subsequent patch will remove the current implicit limitation on creation
of ioreq servers which is due to the allocation of gfns for the ioreq
structures and buffered ioreq ring.

It will therefore be necessary to introduce an explicit limit and, since
this limit should be small, it simplifies the code to maintain an array of
that size rather than using a list.

Also, by reserving an array slot for the default server and populating
array slots early in create, the need to pass an 'is_default' boolean
to sub-functions can be avoided.

Some function return values are changed by this patch: Specifically, in
the case where the id of the default ioreq server is passed in, -EOPNOTSUPP
is now returned rather than -ENOENT.

Signed-off-by: Paul Durrant 
Reviewed-by: Roger Pau Monné 
Reviewed-by: Jan Beulich 
---
Cc: Andrew Cooper 

v10:
 - modified FOR_EACH... macro as suggested by Jan.
 - check for NULL in IS_DEFAULT macro as suggested by Jan.

v9:
 - modified FOR_EACH... macro as requested by Andrew.

v8:
 - Addressed various comments from Jan.

v7:
 - Fixed assertion failure found in testing.

v6:
 - Updated according to comments made by Roger on v4 that I'd missed.

v5:
 - Switched GET/SET_IOREQ_SERVER() macros to get/set_ioreq_server()
   functions to avoid possible double-evaluation issues.

v4:
 - Introduced more helper macros and relocated them to the top of the
   code.

v3:
 - New patch (replacing "move is_default into struct hvm_ioreq_server") in
   response to review comments.
---
 xen/arch/x86/hvm/ioreq.c | 502 +++
 xen/include/asm-x86/hvm/domain.h |  10 +-
 2 files changed, 245 insertions(+), 267 deletions(-)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 5aeaaaccd9..8a8033e5c5 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -33,6 +33,37 @@
 
 #include 
 
+static void set_ioreq_server(struct domain *d, unsigned int id,
+ struct hvm_ioreq_server *s)
+{
+ASSERT(id < MAX_NR_IOREQ_SERVERS);
+ASSERT(!s || !d->arch.hvm_domain.ioreq_server.server[id]);
+
+d->arch.hvm_domain.ioreq_server.server[id] = s;
+}
+
+#define GET_IOREQ_SERVER(d, id) \
+(d)->arch.hvm_domain.ioreq_server.server[id]
+
+static struct hvm_ioreq_server *get_ioreq_server(const struct domain *d,
+ unsigned int id)
+{
+if ( id >= MAX_NR_IOREQ_SERVERS )
+return NULL;
+
+return GET_IOREQ_SERVER(d, id);
+}
+
+#define IS_DEFAULT(s) \
+((s) && (s) == GET_IOREQ_SERVER((s)->domain, DEFAULT_IOSERVID))
+
+/* Iterate over all possible ioreq servers */
+#define FOR_EACH_IOREQ_SERVER(d, id, s) \
+for ( (id) = 0; (id) < MAX_NR_IOREQ_SERVERS; (id)++ ) \
+if ( !(s = GET_IOREQ_SERVER(d, id)) ) \
+continue; \
+else
+
 static ioreq_t *get_ioreq(struct hvm_ioreq_server *s, struct vcpu *v)
 {
 shared_iopage_t *p = s->ioreq.va;
@@ -47,10 +78,9 @@ bool hvm_io_pending(struct vcpu *v)
 {
 struct domain *d = v->domain;
 struct hvm_ioreq_server *s;
+unsigned int id;
 
-list_for_each_entry ( s,
-  >arch.hvm_domain.ioreq_server.list,
-  list_entry )
+FOR_EACH_IOREQ_SERVER(d, id, s)
 {
 struct hvm_ioreq_vcpu *sv;
 
@@ -127,10 +157,9 @@ bool handle_hvm_io_completion(struct vcpu *v)
 struct hvm_vcpu_io *vio = >arch.hvm_vcpu.hvm_io;
 struct hvm_ioreq_server *s;
 enum hvm_io_completion io_completion;
+unsigned int id;
 
-  list_for_each_entry ( s,
-  >arch.hvm_domain.ioreq_server.list,
-  list_entry )
+FOR_EACH_IOREQ_SERVER(d, id, s)
 {
 struct hvm_ioreq_vcpu *sv;
 
@@ -243,13 +272,12 @@ static int hvm_map_ioreq_page(
 bool is_ioreq_server_page(struct domain *d, const struct page_info *page)
 {
 const struct hvm_ioreq_server *s;
+unsigned int id;
 bool found = false;
 
 spin_lock_recursive(>arch.hvm_domain.ioreq_server.lock);
 
-list_for_each_entry ( s,
-  >arch.hvm_domain.ioreq_server.list,
-  list_entry )
+FOR_EACH_IOREQ_SERVER(d, id, s)
 {
 if ( (s->ioreq.va && s->ioreq.page == page) ||
  (s->bufioreq.va && s->bufioreq.page == page) )
@@ -302,7 +330,7 @@ static void hvm_update_ioreq_evtchn(struct hvm_ioreq_server 
*s,
 }
 
 static int hvm_ioreq_server_add_vcpu(struct hvm_ioreq_server *s,
- bool is_default, struct vcpu *v)
+ struct vcpu *v)
 {
 struct hvm_ioreq_vcpu *sv;
 int rc;
@@ -331,7 +359,7 @@ static int hvm_ioreq_server_add_vcpu(struct 
hvm_ioreq_server *s,
 goto fail3;
 
 s->bufioreq_evtchn = rc;
-if ( is_default )
+if ( IS_DEFAULT(s) )
 

[Xen-devel] [PATCH v17 08/11] tools/libxenforeignmemory: add support for resource mapping

[Paul Durrant]

A previous patch introduced a new HYPERVISOR_memory_op to acquire guest
resources for direct priv-mapping.

This patch adds new functionality into libxenforeignmemory to make use
of a new privcmd ioctl [1] that uses the new memory op to make such
resources available via mmap(2).

[1] 
http://xenbits.xen.org/gitweb/?p=people/pauldu/linux.git;a=commit;h=ce59a05e6712

Signed-off-by: Paul Durrant 
Reviewed-by: Roger Pau Monné 
Reviewed-by: Wei Liu 
---
Cc: Ian Jackson 

v4:
 - Fixed errno and removed single-use label
 - The unmap call now returns a status
 - Use C99 initialization for ioctl struct

v2:
 - Bump minor version up to 3.
---
 tools/include/xen-sys/Linux/privcmd.h  | 11 +
 tools/libs/foreignmemory/Makefile  |  2 +-
 tools/libs/foreignmemory/core.c| 53 ++
 .../libs/foreignmemory/include/xenforeignmemory.h  | 41 +
 tools/libs/foreignmemory/libxenforeignmemory.map   |  5 ++
 tools/libs/foreignmemory/linux.c   | 45 ++
 tools/libs/foreignmemory/private.h | 31 +
 7 files changed, 187 insertions(+), 1 deletion(-)

diff --git a/tools/include/xen-sys/Linux/privcmd.h 
b/tools/include/xen-sys/Linux/privcmd.h
index 732ff7c15a..9531b728f9 100644
--- a/tools/include/xen-sys/Linux/privcmd.h
+++ b/tools/include/xen-sys/Linux/privcmd.h
@@ -86,6 +86,15 @@ typedef struct privcmd_dm_op {
const privcmd_dm_op_buf_t __user *ubufs;
 } privcmd_dm_op_t;
 
+typedef struct privcmd_mmap_resource {
+   domid_t dom;
+   __u32 type;
+   __u32 id;
+   __u32 idx;
+   __u64 num;
+   __u64 addr;
+} privcmd_mmap_resource_t;
+
 /*
  * @cmd: IOCTL_PRIVCMD_HYPERCALL
  * @arg: _hypercall_t
@@ -103,5 +112,7 @@ typedef struct privcmd_dm_op {
_IOC(_IOC_NONE, 'P', 5, sizeof(privcmd_dm_op_t))
 #define IOCTL_PRIVCMD_RESTRICT \
_IOC(_IOC_NONE, 'P', 6, sizeof(domid_t))
+#define IOCTL_PRIVCMD_MMAP_RESOURCE\
+   _IOC(_IOC_NONE, 'P', 7, sizeof(privcmd_mmap_resource_t))
 
 #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
diff --git a/tools/libs/foreignmemory/Makefile 
b/tools/libs/foreignmemory/Makefile
index cbe815fce8..ee5c3fd67e 100644
--- a/tools/libs/foreignmemory/Makefile
+++ b/tools/libs/foreignmemory/Makefile
@@ -2,7 +2,7 @@ XEN_ROOT = $(CURDIR)/../../..
 include $(XEN_ROOT)/tools/Rules.mk
 
 MAJOR= 1
-MINOR= 2
+MINOR= 3
 SHLIB_LDFLAGS += -Wl,--version-script=libxenforeignmemory.map
 
 CFLAGS   += -Werror -Wmissing-prototypes
diff --git a/tools/libs/foreignmemory/core.c b/tools/libs/foreignmemory/core.c
index 7c8562ae74..63f12e2450 100644
--- a/tools/libs/foreignmemory/core.c
+++ b/tools/libs/foreignmemory/core.c
@@ -17,6 +17,8 @@
 #include 
 #include 
 
+#include 
+
 #include "private.h"
 
 static int all_restrict_cb(Xentoolcore__Active_Handle *ah, domid_t domid) {
@@ -135,6 +137,57 @@ int xenforeignmemory_restrict(xenforeignmemory_handle 
*fmem,
 return osdep_xenforeignmemory_restrict(fmem, domid);
 }
 
+xenforeignmemory_resource_handle *xenforeignmemory_map_resource(
+xenforeignmemory_handle *fmem, domid_t domid, unsigned int type,
+unsigned int id, unsigned long frame, unsigned long nr_frames,
+void **paddr, int prot, int flags)
+{
+xenforeignmemory_resource_handle *fres;
+int rc;
+
+/* Check flags only contains POSIX defined values */
+if ( flags & ~(MAP_SHARED | MAP_PRIVATE) )
+{
+errno = EINVAL;
+return NULL;
+}
+
+fres = calloc(1, sizeof(*fres));
+if ( !fres )
+{
+errno = ENOMEM;
+return NULL;
+}
+
+fres->domid = domid;
+fres->type = type;
+fres->id = id;
+fres->frame = frame;
+fres->nr_frames = nr_frames;
+fres->addr = *paddr;
+fres->prot = prot;
+fres->flags = flags;
+
+rc = osdep_xenforeignmemory_map_resource(fmem, fres);
+if ( rc )
+{
+free(fres);
+fres = NULL;
+} else
+*paddr = fres->addr;
+
+return fres;
+}
+
+int xenforeignmemory_unmap_resource(
+xenforeignmemory_handle *fmem, xenforeignmemory_resource_handle *fres)
+{
+int rc = osdep_xenforeignmemory_unmap_resource(fmem, fres);
+
+free(fres);
+return rc;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libs/foreignmemory/include/xenforeignmemory.h 
b/tools/libs/foreignmemory/include/xenforeignmemory.h
index f4814c390f..d594be8df0 100644
--- a/tools/libs/foreignmemory/include/xenforeignmemory.h
+++ b/tools/libs/foreignmemory/include/xenforeignmemory.h
@@ -138,6 +138,47 @@ int xenforeignmemory_unmap(xenforeignmemory_handle *fmem,
 int xenforeignmemory_restrict(xenforeignmemory_handle *fmem,
   domid_t domid);
 
+typedef struct xenforeignmemory_resource_handle 
xenforeignmemory_resource_handle;
+
+/**
+ * This 

[Xen-devel] [PATCH v17 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

[Paul Durrant]

Certain memory resources associated with a guest are not necessarily
present in the guest P2M.

This patch adds the boilerplate for new memory op to allow such a resource
to be priv-mapped directly, by either a PV or HVM tools domain.

NOTE: Whilst the new op is not intrinsicly specific to the x86 architecture,
  I have no means to test it on an ARM platform and so cannot verify
  that it functions correctly.

Signed-off-by: Paul Durrant 
Reviewed-by: Jan Beulich 
Acked-by: Daniel De Graaf 
---
Cc: George Dunlap 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
Cc: Julien Grall 

v14:
 - Addressed more comments from Jan.

v13:
 - Use xen_pfn_t for mfn_list.
 - Addressed further comments from Jan and Julien.

v12:
 - Addressed more comments form Jan.
 - Removed #ifdef CONFIG_X86 from common code and instead introduced a
   stub set_foreign_p2m_entry() in asm-arm/p2m.h returning -EOPNOTSUPP.
 - Restricted mechanism for querying implementation limit on nr_frames
   and simplified compat code.

v11:
 - Addressed more comments from Jan.

v9:
 - Addressed more comments from Jan.

v8:
 - Move the code into common as requested by Jan.
 - Make the gmfn_list handle a 64-bit type to avoid limiting the MFN
   range for a 32-bit tools domain.
 - Add missing pad.
 - Add compat code.
 - Make this patch deal with purely boilerplate.
 - Drop George's A-b and Wei's R-b because the changes are non-trivial,
   and update Cc list now the boilerplate is common.

v5:
 - Switched __copy_to/from_guest_offset() to copy_to/from_guest_offset().
---
 tools/flask/policy/modules/xen.if   |  4 +-
 xen/arch/x86/mm/p2m.c   |  3 +-
 xen/common/compat/memory.c  | 95 +
 xen/common/memory.c | 89 ++
 xen/include/asm-arm/p2m.h   | 10 
 xen/include/asm-x86/p2m.h   |  3 ++
 xen/include/public/memory.h | 43 -
 xen/include/xlat.lst|  1 +
 xen/include/xsm/dummy.h |  6 +++
 xen/include/xsm/xsm.h   |  6 +++
 xen/xsm/dummy.c |  1 +
 xen/xsm/flask/hooks.c   |  6 +++
 xen/xsm/flask/policy/access_vectors |  2 +
 13 files changed, 265 insertions(+), 4 deletions(-)

diff --git a/tools/flask/policy/modules/xen.if 
b/tools/flask/policy/modules/xen.if
index cb48a6ccdd..5f5184b972 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -52,7 +52,8 @@ define(`create_domain_common', `
settime setdomainhandle getvcpucontext set_misc_info };
allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim
set_max_evtchn set_vnumainfo get_vnumainfo cacheflush
-   psr_cmt_op psr_alloc soft_reset set_gnttab_limits };
+   psr_cmt_op psr_alloc soft_reset set_gnttab_limits
+   resource_map };
allow $1 $2:security check_context;
allow $1 $2:shadow enable;
allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage 
mmuext_op updatemp };
@@ -152,6 +153,7 @@ define(`device_model', `
allow $1 $2_target:domain { getdomaininfo shutdown };
allow $1 $2_target:mmu { map_read map_write adjust physmap target_hack 
};
allow $1 $2_target:hvm { getparam setparam hvmctl cacheattr dm };
+   allow $1 $2_target:domain2 resource_map;
 ')
 
 # make_device_model(priv, dm_dom, hvm_dom)
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index c72a3cdebb..71bb9b4f93 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1132,8 +1132,7 @@ static int set_typed_p2m_entry(struct domain *d, unsigned 
long gfn_l,
 }
 
 /* Set foreign mfn in the given guest's p2m table. */
-static int set_foreign_p2m_entry(struct domain *d, unsigned long gfn,
- mfn_t mfn)
+int set_foreign_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn)
 {
 return set_typed_p2m_entry(d, gfn, mfn, PAGE_ORDER_4K, p2m_map_foreign,
p2m_get_hostp2m(d)->default_access);
diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
index 35bb259808..9a7cb1a71b 100644
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -71,6 +71,7 @@ int compat_memory_op(unsigned int cmd, 
XEN_GUEST_HANDLE_PARAM(void) compat)
 struct xen_remove_from_physmap *xrfp;
 struct xen_vnuma_topology_info *vnuma;
 struct xen_mem_access_op *mao;
+struct xen_mem_acquire_resource *mar;
 } nat;
 union 

[Xen-devel] [PATCH v17 06/11] x86/hvm/ioreq: add a new mappable resource type...

[Paul Durrant]

... XENMEM_resource_ioreq_server

This patch adds support for a new resource type that can be mapped using
the XENMEM_acquire_resource memory op.

If an emulator makes use of this resource type then, instead of mapping
gfns, the IOREQ server will allocate pages from the heap. These pages
will never be present in the P2M of the guest at any point and so are
not vulnerable to any direct attack by the guest. They are only ever
accessible by Xen and any domain that has mapping privilege over the
guest (which may or may not be limited to the domain running the emulator).

Because an emulator may continue to hold references to the pages beyond
initial domain tear-down, it is important that they are not freed during
the normal ioreq server tear-down. Instead a per-domain free-list of pages
is maintained and pages in this list are not freed until final domain
destruction.

NOTE: Use of the new resource type is not compatible with use of
  XEN_DMOP_get_ioreq_server_info unless the XEN_DMOP_no_gfns flag is
  set.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: George Dunlap 
Cc: Wei Liu 
Cc: Andrew Cooper 
Cc: Ian Jackson 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Julien Grall 

v17:
 - The use of xenheap pages means that freeing needs to be deferred until
   domain destruction. Add an explanatory paragraph to the commit comment.

v15:
 - Use xenheap pages rather than domheap pages and assign ownership to
   target domain.

v14:
 - Addressed more comments from Jan.

v13:
 - Introduce an arch_acquire_resource() as suggested by Julien (and have
   the ARM varient simply return -EOPNOTSUPP).
 - Check for ioreq server id truncation as requested by Jan.
 - Not added Jan's R-b due to substantive change from v12.

v12:
 - Addressed more comments from Jan.
 - Dropped George's A-b and Wei's R-b because of material change.

v11:
 - Addressed more comments from Jan.

v10:
 - Addressed comments from Jan.

v8:
 - Re-base on new boilerplate.
 - Adjust function signature of hvm_get_ioreq_server_frame(), and test
   whether the bufioreq page is present.

v5:
 - Use get_ioreq_server() function rather than indexing array directly.
 - Add more explanation into comments to state than mapping guest frames
   and allocation of pages for ioreq servers are not simultaneously
   permitted.
 - Add a comment into asm/ioreq.h stating the meaning of the index
   value passed to hvm_get_ioreq_server_frame().
---
 xen/arch/x86/hvm/hvm.c   |   2 +
 xen/arch/x86/hvm/ioreq.c | 154 +++
 xen/arch/x86/mm.c|  41 +++
 xen/common/memory.c  |   3 +-
 xen/include/asm-arm/mm.h |   7 ++
 xen/include/asm-x86/hvm/domain.h |   1 +
 xen/include/asm-x86/hvm/ioreq.h  |   3 +
 xen/include/asm-x86/mm.h |   5 ++
 xen/include/public/hvm/dm_op.h   |   4 +
 xen/include/public/memory.h  |   9 +++
 10 files changed, 228 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 28bc7e4252..0d7a2f984b 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -726,6 +726,8 @@ void hvm_domain_destroy(struct domain *d)
 list_del(>list);
 xfree(ioport);
 }
+
+hvm_ioreq_deinit(d);
 }
 
 static int hvm_save_tsc_adjust(struct domain *d, hvm_domain_context_t *h)
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 1e6f0f41e4..1568224f08 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -259,6 +259,19 @@ static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, 
bool buf)
 struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
 int rc;
 
+if ( iorp->page )
+{
+/*
+ * If a page has already been allocated (which will happen on
+ * demand if hvm_get_ioreq_server_frame() is called), then
+ * mapping a guest frame is not permitted.
+ */
+if ( gfn_eq(iorp->gfn, INVALID_GFN) )
+return -EPERM;
+
+return 0;
+}
+
 if ( d->is_dying )
 return -EINVAL;
 
@@ -281,6 +294,56 @@ static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, 
bool buf)
 return rc;
 }
 
+static int hvm_alloc_ioreq_mfn(struct hvm_ioreq_server *s, bool buf)
+{
+struct domain *d = s->domain;
+struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
+
+if ( iorp->page )
+{
+/*
+ * If a guest frame has already been mapped (which may happen
+ * on demand if hvm_get_ioreq_server_info() is called), then
+ * allocating a page is not permitted.
+ */
+if ( !gfn_eq(iorp->gfn, INVALID_GFN) )
+return -EPERM;
+
+return 0;
+}
+
+iorp->page =
+

[Xen-devel] [PATCH v17 03/11] x86/hvm/ioreq: use gfn_t in struct hvm_ioreq_page

[Paul Durrant]

This patch adjusts the ioreq server code to use type-safe gfn_t values
where possible. No functional change.

Signed-off-by: Paul Durrant 
Reviewed-by: Roger Pau Monné 
Reviewed-by: Wei Liu 
Acked-by: Jan Beulich 
---
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/ioreq.c | 44 
 xen/include/asm-x86/hvm/domain.h |  2 +-
 2 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 7f6dcac26f..b2ef81f003 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -210,7 +210,7 @@ bool handle_hvm_io_completion(struct vcpu *v)
 return true;
 }
 
-static unsigned long hvm_alloc_ioreq_gfn(struct hvm_ioreq_server *s)
+static gfn_t hvm_alloc_ioreq_gfn(struct hvm_ioreq_server *s)
 {
 struct domain *d = s->domain;
 unsigned int i;
@@ -220,20 +220,19 @@ static unsigned long hvm_alloc_ioreq_gfn(struct 
hvm_ioreq_server *s)
 for ( i = 0; i < sizeof(d->arch.hvm_domain.ioreq_gfn.mask) * 8; i++ )
 {
 if ( test_and_clear_bit(i, >arch.hvm_domain.ioreq_gfn.mask) )
-return d->arch.hvm_domain.ioreq_gfn.base + i;
+return _gfn(d->arch.hvm_domain.ioreq_gfn.base + i);
 }
 
-return gfn_x(INVALID_GFN);
+return INVALID_GFN;
 }
 
-static void hvm_free_ioreq_gfn(struct hvm_ioreq_server *s,
-   unsigned long gfn)
+static void hvm_free_ioreq_gfn(struct hvm_ioreq_server *s, gfn_t gfn)
 {
 struct domain *d = s->domain;
-unsigned int i = gfn - d->arch.hvm_domain.ioreq_gfn.base;
+unsigned int i = gfn_x(gfn) - d->arch.hvm_domain.ioreq_gfn.base;
 
 ASSERT(!IS_DEFAULT(s));
-ASSERT(gfn != gfn_x(INVALID_GFN));
+ASSERT(!gfn_eq(gfn, INVALID_GFN));
 
 set_bit(i, >arch.hvm_domain.ioreq_gfn.mask);
 }
@@ -242,7 +241,7 @@ static void hvm_unmap_ioreq_gfn(struct hvm_ioreq_server *s, 
bool buf)
 {
 struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
 
-if ( iorp->gfn == gfn_x(INVALID_GFN) )
+if ( gfn_eq(iorp->gfn, INVALID_GFN) )
 return;
 
 destroy_ring_for_helper(>va, iorp->page);
@@ -251,7 +250,7 @@ static void hvm_unmap_ioreq_gfn(struct hvm_ioreq_server *s, 
bool buf)
 if ( !IS_DEFAULT(s) )
 hvm_free_ioreq_gfn(s, iorp->gfn);
 
-iorp->gfn = gfn_x(INVALID_GFN);
+iorp->gfn = INVALID_GFN;
 }
 
 static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, bool buf)
@@ -264,16 +263,17 @@ static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, 
bool buf)
 return -EINVAL;
 
 if ( IS_DEFAULT(s) )
-iorp->gfn = buf ?
-d->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_PFN] :
-d->arch.hvm_domain.params[HVM_PARAM_IOREQ_PFN];
+iorp->gfn = _gfn(buf ?
+ d->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_PFN] :
+ d->arch.hvm_domain.params[HVM_PARAM_IOREQ_PFN]);
 else
 iorp->gfn = hvm_alloc_ioreq_gfn(s);
 
-if ( iorp->gfn == gfn_x(INVALID_GFN) )
+if ( gfn_eq(iorp->gfn, INVALID_GFN) )
 return -ENOMEM;
 
-rc = prepare_ring_for_helper(d, iorp->gfn, >page, >va);
+rc = prepare_ring_for_helper(d, gfn_x(iorp->gfn), >page,
+ >va);
 
 if ( rc )
 hvm_unmap_ioreq_gfn(s, buf);
@@ -309,10 +309,10 @@ static void hvm_remove_ioreq_gfn(struct hvm_ioreq_server 
*s, bool buf)
 struct domain *d = s->domain;
 struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
 
-if ( IS_DEFAULT(s) || iorp->gfn == gfn_x(INVALID_GFN) )
+if ( IS_DEFAULT(s) || gfn_eq(iorp->gfn, INVALID_GFN) )
 return;
 
-if ( guest_physmap_remove_page(d, _gfn(iorp->gfn),
+if ( guest_physmap_remove_page(d, iorp->gfn,
_mfn(page_to_mfn(iorp->page)), 0) )
 domain_crash(d);
 clear_page(iorp->va);
@@ -324,12 +324,12 @@ static int hvm_add_ioreq_gfn(struct hvm_ioreq_server *s, 
bool buf)
 struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
 int rc;
 
-if ( IS_DEFAULT(s) || iorp->gfn == gfn_x(INVALID_GFN) )
+if ( IS_DEFAULT(s) || gfn_eq(iorp->gfn, INVALID_GFN) )
 return 0;
 
 clear_page(iorp->va);
 
-rc = guest_physmap_add_page(d, _gfn(iorp->gfn),
+rc = guest_physmap_add_page(d, iorp->gfn,
 _mfn(page_to_mfn(iorp->page)), 0);
 if ( rc == 0 )
 paging_mark_dirty(d, _mfn(page_to_mfn(iorp->page)));
@@ -590,8 +590,8 @@ static int hvm_ioreq_server_init(struct hvm_ioreq_server *s,
 INIT_LIST_HEAD(>ioreq_vcpu_list);
 spin_lock_init(>bufioreq_lock);
 
-s->ioreq.gfn = gfn_x(INVALID_GFN);
-s->bufioreq.gfn = gfn_x(INVALID_GFN);
+s->ioreq.gfn = INVALID_GFN;
+s->bufioreq.gfn = INVALID_GFN;
 
 rc = hvm_ioreq_server_alloc_rangesets(s, id);
 if ( rc )
@@ -757,11 +757,11 @@ int 

[Xen-devel] [PATCH v17 02/11] x86/hvm/ioreq: simplify code and use consistent naming

[Paul Durrant]

This patch re-works much of the ioreq server initialization and teardown
code:

- The hvm_map/unmap_ioreq_gfn() functions are expanded to call through
  to hvm_alloc/free_ioreq_gfn() rather than expecting them to be called
  separately by outer functions.
- Several functions now test the validity of the hvm_ioreq_page gfn value
  to determine whether they need to act. This means can be safely called
  for the bufioreq page even when it is not used.
- hvm_add/remove_ioreq_gfn() simply return in the case of the default
  IOREQ server so callers no longer need to test before calling.
- hvm_ioreq_server_setup_pages() is renamed to hvm_ioreq_server_map_pages()
  to mirror the existing hvm_ioreq_server_unmap_pages().

All of this significantly shortens the code.

Signed-off-by: Paul Durrant 
Reviewed-by: Roger Pau Monné 
Reviewed-by: Wei Liu 
Acked-by: Jan Beulich 
---
Cc: Andrew Cooper 

v3:
 - Rebased on top of 's->is_default' to 'IS_DEFAULT(s)' changes.
 - Minor updates in response to review comments from Roger.
---
 xen/arch/x86/hvm/ioreq.c | 182 ++-
 1 file changed, 69 insertions(+), 113 deletions(-)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 8a8033e5c5..7f6dcac26f 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -210,63 +210,75 @@ bool handle_hvm_io_completion(struct vcpu *v)
 return true;
 }
 
-static int hvm_alloc_ioreq_gfn(struct domain *d, unsigned long *gfn)
+static unsigned long hvm_alloc_ioreq_gfn(struct hvm_ioreq_server *s)
 {
+struct domain *d = s->domain;
 unsigned int i;
-int rc;
 
-rc = -ENOMEM;
+ASSERT(!IS_DEFAULT(s));
+
 for ( i = 0; i < sizeof(d->arch.hvm_domain.ioreq_gfn.mask) * 8; i++ )
 {
 if ( test_and_clear_bit(i, >arch.hvm_domain.ioreq_gfn.mask) )
-{
-*gfn = d->arch.hvm_domain.ioreq_gfn.base + i;
-rc = 0;
-break;
-}
+return d->arch.hvm_domain.ioreq_gfn.base + i;
 }
 
-return rc;
+return gfn_x(INVALID_GFN);
 }
 
-static void hvm_free_ioreq_gfn(struct domain *d, unsigned long gfn)
+static void hvm_free_ioreq_gfn(struct hvm_ioreq_server *s,
+   unsigned long gfn)
 {
+struct domain *d = s->domain;
 unsigned int i = gfn - d->arch.hvm_domain.ioreq_gfn.base;
 
-if ( gfn != gfn_x(INVALID_GFN) )
-set_bit(i, >arch.hvm_domain.ioreq_gfn.mask);
+ASSERT(!IS_DEFAULT(s));
+ASSERT(gfn != gfn_x(INVALID_GFN));
+
+set_bit(i, >arch.hvm_domain.ioreq_gfn.mask);
 }
 
-static void hvm_unmap_ioreq_page(struct hvm_ioreq_server *s, bool buf)
+static void hvm_unmap_ioreq_gfn(struct hvm_ioreq_server *s, bool buf)
 {
 struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
 
+if ( iorp->gfn == gfn_x(INVALID_GFN) )
+return;
+
 destroy_ring_for_helper(>va, iorp->page);
+iorp->page = NULL;
+
+if ( !IS_DEFAULT(s) )
+hvm_free_ioreq_gfn(s, iorp->gfn);
+
+iorp->gfn = gfn_x(INVALID_GFN);
 }
 
-static int hvm_map_ioreq_page(
-struct hvm_ioreq_server *s, bool buf, unsigned long gfn)
+static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, bool buf)
 {
 struct domain *d = s->domain;
 struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
-struct page_info *page;
-void *va;
 int rc;
 
-if ( (rc = prepare_ring_for_helper(d, gfn, , )) )
-return rc;
-
-if ( (iorp->va != NULL) || d->is_dying )
-{
-destroy_ring_for_helper(, page);
+if ( d->is_dying )
 return -EINVAL;
-}
 
-iorp->va = va;
-iorp->page = page;
-iorp->gfn = gfn;
+if ( IS_DEFAULT(s) )
+iorp->gfn = buf ?
+d->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_PFN] :
+d->arch.hvm_domain.params[HVM_PARAM_IOREQ_PFN];
+else
+iorp->gfn = hvm_alloc_ioreq_gfn(s);
 
-return 0;
+if ( iorp->gfn == gfn_x(INVALID_GFN) )
+return -ENOMEM;
+
+rc = prepare_ring_for_helper(d, iorp->gfn, >page, >va);
+
+if ( rc )
+hvm_unmap_ioreq_gfn(s, buf);
+
+return rc;
 }
 
 bool is_ioreq_server_page(struct domain *d, const struct page_info *page)
@@ -279,8 +291,7 @@ bool is_ioreq_server_page(struct domain *d, const struct 
page_info *page)
 
 FOR_EACH_IOREQ_SERVER(d, id, s)
 {
-if ( (s->ioreq.va && s->ioreq.page == page) ||
- (s->bufioreq.va && s->bufioreq.page == page) )
+if ( (s->ioreq.page == page) || (s->bufioreq.page == page) )
 {
 found = true;
 break;
@@ -292,20 +303,30 @@ bool is_ioreq_server_page(struct domain *d, const struct 
page_info *page)
 return found;
 }
 
-static void hvm_remove_ioreq_gfn(
-struct domain *d, struct hvm_ioreq_page *iorp)
+static void hvm_remove_ioreq_gfn(struct hvm_ioreq_server *s, bool buf)
+
 {
+

[Xen-devel] [PATCH v17 04/11] x86/hvm/ioreq: defer mapping gfns until they are actually requested

[Paul Durrant]

A subsequent patch will introduce a new scheme to allow an emulator to
map ioreq server pages directly from Xen rather than the guest P2M.

This patch lays the groundwork for that change by deferring mapping of
gfns until their values are requested by an emulator. To that end, the
pad field of the xen_dm_op_get_ioreq_server_info structure is re-purposed
to a flags field and new flag, XEN_DMOP_no_gfns, defined which modifies the
behaviour of XEN_DMOP_get_ioreq_server_info to allow the caller to avoid
requesting the gfn values.

Signed-off-by: Paul Durrant 
Reviewed-by: Roger Pau Monné 
Acked-by: Wei Liu 
Reviewed-by: Jan Beulich 
---
Cc: Ian Jackson 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Chao Gao 

v17:
 - Fix typo in commit comment

v16:
 - Leave call to map pages in hvm_ioreq_server_init() for default ioreq
   server instance, as pointed out by Chao (cc-ed). This is small and
   obvious change which reduces the size of the patch, so I have left
   existent R-bs and A-bs in place.

v8:
 - For safety make all of the pointers passed to
   hvm_get_ioreq_server_info() optional.
 - Shrink bufioreq_handling down to a uint8_t.

v3:
 - Updated in response to review comments from Wei and Roger.
 - Added a HANDLE_BUFIOREQ macro to make the code neater.
 - This patch no longer introduces a security vulnerability since there
   is now an explicit limit on the number of ioreq servers that may be
   created for any one domain.
---
 tools/libs/devicemodel/core.c   |  8 
 tools/libs/devicemodel/include/xendevicemodel.h |  6 +--
 xen/arch/x86/hvm/dm.c   |  9 +++--
 xen/arch/x86/hvm/ioreq.c| 49 -
 xen/include/asm-x86/hvm/domain.h|  2 +-
 xen/include/public/hvm/dm_op.h  | 32 +---
 6 files changed, 69 insertions(+), 37 deletions(-)

diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c
index 355b7dec18..df2a8a0fe7 100644
--- a/tools/libs/devicemodel/core.c
+++ b/tools/libs/devicemodel/core.c
@@ -204,6 +204,14 @@ int xendevicemodel_get_ioreq_server_info(
 
 data->id = id;
 
+/*
+ * If the caller is not requesting gfn values then instruct the
+ * hypercall not to retrieve them as this may cause them to be
+ * mapped.
+ */
+if (!ioreq_gfn && !bufioreq_gfn)
+data->flags |= XEN_DMOP_no_gfns;
+
 rc = xendevicemodel_op(dmod, domid, 1, , sizeof(op));
 if (rc)
 return rc;
diff --git a/tools/libs/devicemodel/include/xendevicemodel.h 
b/tools/libs/devicemodel/include/xendevicemodel.h
index dda0bc7695..fffee3a4a0 100644
--- a/tools/libs/devicemodel/include/xendevicemodel.h
+++ b/tools/libs/devicemodel/include/xendevicemodel.h
@@ -61,11 +61,11 @@ int xendevicemodel_create_ioreq_server(
  * @parm domid the domain id to be serviced
  * @parm id the IOREQ Server id.
  * @parm ioreq_gfn pointer to a xen_pfn_t to receive the synchronous ioreq
- *  gfn
+ *  gfn. (May be NULL if not required)
  * @parm bufioreq_gfn pointer to a xen_pfn_t to receive the buffered ioreq
- *gfn
+ *gfn. (May be NULL if not required)
  * @parm bufioreq_port pointer to a evtchn_port_t to receive the buffered
- * ioreq event channel
+ * ioreq event channel. (May be NULL if not required)
  * @return 0 on success, -1 on failure.
  */
 int xendevicemodel_get_ioreq_server_info(
diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index a787f43737..3c617bd754 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -416,16 +416,19 @@ static int dm_op(const struct dmop_args *op_args)
 {
 struct xen_dm_op_get_ioreq_server_info *data =
 _ioreq_server_info;
+const uint16_t valid_flags = XEN_DMOP_no_gfns;
 
 const_op = false;
 
 rc = -EINVAL;
-if ( data->pad )
+if ( data->flags & ~valid_flags )
 break;
 
 rc = hvm_get_ioreq_server_info(d, data->id,
-   >ioreq_gfn,
-   >bufioreq_gfn,
+   (data->flags & XEN_DMOP_no_gfns) ?
+   NULL : >ioreq_gfn,
+   (data->flags & XEN_DMOP_no_gfns) ?
+   NULL : >bufioreq_gfn,
>bufioreq_port);
 break;
 }
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index b2ef81f003..1e6f0f41e4 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ 

[Xen-devel] [PATCH v17 09/11] tools/libxenforeignmemory: reduce xenforeignmemory_restrict code footprint

[Paul Durrant]

By using a static inline stub in private.h for OS where this functionality
is not implemented, the various duplicate stubs in the OS-specific source
modules can be avoided.

Signed-off-by: Paul Durrant 
Reviewed-by: Roger Pau Monné 
Acked-by: Wei Liu 
---
Cc: Ian Jackson 

v4:
 - Removed extraneous freebsd code.

v3:
 - Patch added in response to review comments.
---
 tools/libs/foreignmemory/freebsd.c |  7 ---
 tools/libs/foreignmemory/minios.c  |  7 ---
 tools/libs/foreignmemory/netbsd.c  |  7 ---
 tools/libs/foreignmemory/private.h | 12 +---
 tools/libs/foreignmemory/solaris.c |  7 ---
 5 files changed, 9 insertions(+), 31 deletions(-)

diff --git a/tools/libs/foreignmemory/freebsd.c 
b/tools/libs/foreignmemory/freebsd.c
index dec447485a..6e6bc4b11f 100644
--- a/tools/libs/foreignmemory/freebsd.c
+++ b/tools/libs/foreignmemory/freebsd.c
@@ -95,13 +95,6 @@ int osdep_xenforeignmemory_unmap(xenforeignmemory_handle 
*fmem,
 return munmap(addr, num << PAGE_SHIFT);
 }
 
-int osdep_xenforeignmemory_restrict(xenforeignmemory_handle *fmem,
-domid_t domid)
-{
-errno = -EOPNOTSUPP;
-return -1;
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libs/foreignmemory/minios.c 
b/tools/libs/foreignmemory/minios.c
index 75f340122e..43341ca301 100644
--- a/tools/libs/foreignmemory/minios.c
+++ b/tools/libs/foreignmemory/minios.c
@@ -58,13 +58,6 @@ int osdep_xenforeignmemory_unmap(xenforeignmemory_handle 
*fmem,
 return munmap(addr, num << PAGE_SHIFT);
 }
 
-int osdep_xenforeignmemory_restrict(xenforeignmemory_handle *fmem,
-domid_t domid)
-{
-errno = -EOPNOTSUPP;
-return -1;
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libs/foreignmemory/netbsd.c 
b/tools/libs/foreignmemory/netbsd.c
index 9bf95ef4f0..54a418ebd6 100644
--- a/tools/libs/foreignmemory/netbsd.c
+++ b/tools/libs/foreignmemory/netbsd.c
@@ -100,13 +100,6 @@ int osdep_xenforeignmemory_unmap(xenforeignmemory_handle 
*fmem,
 return munmap(addr, num*XC_PAGE_SIZE);
 }
 
-int osdep_xenforeignmemory_restrict(xenforeignmemory_handle *fmem,
-domid_t domid)
-{
-errno = -EOPNOTSUPP;
-return -1;
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libs/foreignmemory/private.h 
b/tools/libs/foreignmemory/private.h
index b191000b49..b06ce12583 100644
--- a/tools/libs/foreignmemory/private.h
+++ b/tools/libs/foreignmemory/private.h
@@ -35,9 +35,6 @@ void *osdep_xenforeignmemory_map(xenforeignmemory_handle 
*fmem,
 int osdep_xenforeignmemory_unmap(xenforeignmemory_handle *fmem,
  void *addr, size_t num);
 
-int osdep_xenforeignmemory_restrict(xenforeignmemory_handle *fmem,
-domid_t domid);
-
 #if defined(__NetBSD__) || defined(__sun__)
 /* Strictly compat for those two only only */
 void *compat_mapforeign_batch(xenforeignmem_handle *fmem, uint32_t dom,
@@ -57,6 +54,13 @@ struct xenforeignmemory_resource_handle {
 };
 
 #ifndef __linux__
+static inline int osdep_xenforeignmemory_restrict(xenforeignmemory_handle 
*fmem,
+  domid_t domid)
+{
+errno = EOPNOTSUPP;
+return -1;
+}
+
 static inline int osdep_xenforeignmemory_map_resource(
 xenforeignmemory_handle *fmem, xenforeignmemory_resource_handle *fres)
 {
@@ -70,6 +74,8 @@ static inline int osdep_xenforeignmemory_unmap_resource(
 return 0;
 }
 #else
+int osdep_xenforeignmemory_restrict(xenforeignmemory_handle *fmem,
+domid_t domid);
 int osdep_xenforeignmemory_map_resource(
 xenforeignmemory_handle *fmem, xenforeignmemory_resource_handle *fres);
 int osdep_xenforeignmemory_unmap_resource(
diff --git a/tools/libs/foreignmemory/solaris.c 
b/tools/libs/foreignmemory/solaris.c
index a33decb4ae..ee8aae4fbd 100644
--- a/tools/libs/foreignmemory/solaris.c
+++ b/tools/libs/foreignmemory/solaris.c
@@ -97,13 +97,6 @@ int osdep_xenforeignmemory_unmap(xenforeignmemory_handle 
*fmem,
 return munmap(addr, num*XC_PAGE_SIZE);
 }
 
-int osdep_xenforeignmemory_restrict(xenforeignmemory_handle *fmem,
-domid_t domid)
-{
-errno = -EOPNOTSUPP;
-return -1;
-}
-
 /*
  * Local variables:
  * mode: C
-- 
2.11.0


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

[Xen-devel] [PATCH v17 07/11] x86/mm: add an extra command to HYPERVISOR_mmu_update...

[Paul Durrant]

...to allow the calling domain to prevent translation of specified l1e
value.

Despite what the comment in public/xen.h might imply, specifying a
command value of MMU_NORMAL_PT_UPDATE will not simply update an l1e with
the specified value. Instead, mod_l1_entry() tests whether foreign_dom
has PG_translate set in its paging mode and, if it does, assumes that the
the pfn value in the l1e is a gfn rather than an mfn.

To allow PV tools domain to map mfn values from a previously issued
HYPERVISOR_memory_op:XENMEM_acquire_resource, there needs to be a way
to tell HYPERVISOR_mmu_update that the specific l1e value does not
require translation regardless of the paging mode of foreign_dom. This
patch therefore defines a new command value, MMU_PT_UPDATE_NO_TRANSLATE,
which has the same semantics as MMU_NORMAL_PT_UPDATE except that the
paging mode of foreign_dom is ignored and the l1e value is used verbatim.

Signed-off-by: Paul Durrant 
Reviewed-by: Jan Beulich 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 

v13:
 - Re-base.

v8:
 - New in this version, replacing "allow a privileged PV domain to map
   guest mfns".
---
 xen/arch/x86/mm.c| 13 -
 xen/include/public/xen.h | 12 +---
 2 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 9cca748134..785addd4c0 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1886,9 +1886,10 @@ void page_unlock(struct page_info *page)
 
 /* Update the L1 entry at pl1e to new value nl1e. */
 static int mod_l1_entry(l1_pgentry_t *pl1e, l1_pgentry_t nl1e,
-unsigned long gl1mfn, int preserve_ad,
+unsigned long gl1mfn, unsigned int cmd,
 struct vcpu *pt_vcpu, struct domain *pg_dom)
 {
+bool preserve_ad = (cmd == MMU_PT_UPDATE_PRESERVE_AD);
 l1_pgentry_t ol1e;
 struct domain *pt_dom = pt_vcpu->domain;
 int rc = 0;
@@ -1910,7 +1911,8 @@ static int mod_l1_entry(l1_pgentry_t *pl1e, l1_pgentry_t 
nl1e,
 }
 
 /* Translate foreign guest address. */
-if ( paging_mode_translate(pg_dom) )
+if ( cmd != MMU_PT_UPDATE_NO_TRANSLATE &&
+ paging_mode_translate(pg_dom) )
 {
 p2m_type_t p2mt;
 p2m_query_t q = l1e_get_flags(nl1e) & _PAGE_RW ?
@@ -3602,6 +3604,7 @@ long do_mmu_update(
  */
 case MMU_NORMAL_PT_UPDATE:
 case MMU_PT_UPDATE_PRESERVE_AD:
+case MMU_PT_UPDATE_NO_TRANSLATE:
 {
 p2m_type_t p2mt;
 
@@ -3661,8 +3664,7 @@ long do_mmu_update(
 {
 case PGT_l1_page_table:
 rc = mod_l1_entry(va, l1e_from_intpte(req.val), mfn,
-  cmd == MMU_PT_UPDATE_PRESERVE_AD, v,
-  pg_owner);
+  cmd, v, pg_owner);
 break;
 
 case PGT_l2_page_table:
@@ -3948,7 +3950,8 @@ static int __do_update_va_mapping(
 goto out;
 }
 
-rc = mod_l1_entry(pl1e, val, mfn_x(gl1mfn), 0, v, pg_owner);
+rc = mod_l1_entry(pl1e, val, mfn_x(gl1mfn), MMU_NORMAL_PT_UPDATE, v,
+  pg_owner);
 
 page_unlock(gl1pg);
 put_page(gl1pg);
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 308109f176..fb1df8f293 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -268,6 +268,10 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
  * As MMU_NORMAL_PT_UPDATE above, but A/D bits currently in the PTE are ORed
  * with those in @val.
  *
+ * ptr[1:0] == MMU_PT_UPDATE_NO_TRANSLATE:
+ * As MMU_NORMAL_PT_UPDATE above, but @val is not translated though FD
+ * page tables.
+ *
  * @val is usually the machine frame number along with some attributes.
  * The attributes by default follow the architecture defined bits. Meaning that
  * if this is a X86_64 machine and four page table layout is used, the layout
@@ -334,9 +338,11 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
  *
  * PAT (bit 7 on) --> PWT (bit 3 on) and clear bit 7.
  */
-#define MMU_NORMAL_PT_UPDATE  0 /* checked '*ptr = val'. ptr is MA.  */
-#define MMU_MACHPHYS_UPDATE   1 /* ptr = MA of frame to modify entry for */
-#define MMU_PT_UPDATE_PRESERVE_AD 2 /* atomically: *ptr = val | (*ptr&(A|D)) */
+#define MMU_NORMAL_PT_UPDATE   0 /* checked '*ptr = val'. ptr is MA.  
*/
+#define MMU_MACHPHYS_UPDATE1 /* ptr = MA of frame to modify entry for 
*/
+#define MMU_PT_UPDATE_PRESERVE_AD  2 /* atomically: *ptr = val | (*ptr&(A|D)) 
*/
+#define MMU_PT_UPDATE_NO_TRANSLATE 3 /* checked '*ptr = val'. ptr is MA.  
*/
+  

[Xen-devel] [distros-debian-squeeze test] 73828: trouble: blocked/broken

[Platform Team regression test user]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvopsbroken
 build-i386   broken
 build-amd64-pvopsbroken
 build-armhf  broken
 build-amd64  broken
 build-i386-pvops broken
 build-armhf-pvops 5 capture-logsbroken REGR. vs. 73464
 build-armhf   5 capture-logsbroken REGR. vs. 73464
 build-armhf-pvops 3 syslog-serverrunning
 build-armhf   3 syslog-serverrunning

Tests which did not succeed, but are not blocking:
 test-amd64-i386-i386-squeeze-netboot-pygrub  1 build-check(1)  blocked n/a
 test-amd64-amd64-i386-squeeze-netboot-pygrub  1 build-check(1) blocked n/a
 test-amd64-i386-amd64-squeeze-netboot-pygrub  1 build-check(1) blocked n/a
 test-amd64-amd64-amd64-squeeze-netboot-pygrub  1 build-check(1)blocked n/a
 build-armhf   4 host-install(4)  broken like 73464
 build-armhf-pvops 4 host-install(4)  broken like 73464
 build-amd64   4 host-install(4)  broken like 73464
 build-i386-pvops  4 host-install(4)  broken like 73464
 build-amd64-pvops 4 host-install(4)  broken like 73464
 build-i3864 host-install(4)  broken like 73464

baseline version:
 flight   73464

jobs:
 build-amd64  broken  
 build-armhf  broken  
 build-i386   broken  
 build-amd64-pvopsbroken  
 build-armhf-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-amd64-squeeze-netboot-pygrubblocked 
 test-amd64-i386-amd64-squeeze-netboot-pygrub blocked 
 test-amd64-amd64-i386-squeeze-netboot-pygrub blocked 
 test-amd64-i386-i386-squeeze-netboot-pygrub  blocked 



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

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

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


Push not applicable.


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

Re: [Xen-devel] [PATCH v6 15/16 RESEND] rbtree: low level optimizations in rb_erase()

[Jan Beulich]

>>> On 21.11.17 at 16:20,  wrote:
> From: Michel Lespinasse 
> 
> Various minor optimizations in rb_erase():
> - Avoid multiple loading of node->__rb_parent_color when computing parent
>   and color information (possibly not in close sequence, as there might
>   be further branches in the algorithm)
> - In the 1-child subcase of case 1, copy the __rb_parent_color field from
>   the erased node to the child instead of recomputing it from the desired
>   parent and color
> - When searching for the erased node's successor, differentiate between
>   cases 2 and 3 based on whether any left links were followed. This avoids
>   a condition later down.
> - In case 3, keep a pointer to the erased node's right child so we don't
>   have to refetch it later to adjust its parent.
> - In the no-childs subcase of cases 2 and 3, place the rebalance assigment
>   last so that the compiler can remove the following if(rebalance) test.
> 
> Also, added some comments to illustrate cases 2 and 3.
> 
> Signed-off-by: Michel Lespinasse 
> Acked-by: Rik van Riel 
> Cc: Peter Zijlstra 
> Cc: Andrea Arcangeli 
> Cc: David Woodhouse 
> Signed-off-by: Andrew Morton 
> Signed-off-by: Linus Torvalds 
> [Linux commit 4f035ad67f4633c233cb3642711d49b4efc9c82d]
> 
> Ported to Xen.
> 
> Signed-off-by: Praveen Kumar 

Acked-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH v6 14/16] rbtree: handle 1-child recoloring in rb_erase() instead of rb_erase_color()

[Jan Beulich]

>>> On 21.11.17 at 16:20,  wrote:
> From: Michel Lespinasse 
> 
> An interesting observation for rb_erase() is that when a node has
> exactly one child, the node must be black and the child must be red.
> An interesting consequence is that removing such a node can be done by
> simply replacing it with its child and making the child black,
> which we can do efficiently in rb_erase(). __rb_erase_color() then
> only needs to handle the no-childs case and can be modified accordingly.
> 
> Signed-off-by: Michel Lespinasse 
> Acked-by: Rik van Riel 
> Cc: Peter Zijlstra 
> Cc: Andrea Arcangeli 
> Cc: David Woodhouse 
> Signed-off-by: Andrew Morton 
> Signed-off-by: Linus Torvalds 
> [Linux commit 46b6135a7402ac23c5b25f2bd79b03bab8f98278]
> 
> Ported to Xen.
> 
> Signed-off-by: Praveen Kumar 

Acked-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH v6 13/16 RESEND] rbtree: place easiest case first in rb_erase()

[Jan Beulich]

>>> On 21.11.17 at 16:20,  wrote:
> From: Michel Lespinasse 
> 
> In rb_erase, move the easy case (node to erase has no more than
> 1 child) first. I feel the code reads easier that way.
> 
> Signed-off-by: Michel Lespinasse 
> Reviewed-by: Rik van Riel 
> Cc: Peter Zijlstra 
> Cc: Andrea Arcangeli 
> Cc: David Woodhouse 
> Signed-off-by: Andrew Morton 
> Signed-off-by: Linus Torvalds 
> [Linux commit 60670b8034d6e2ba860af79c9379b7788d09db73]
> 
> Ported to Xen.
> 
> Signed-off-by: Praveen Kumar 

Acked-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH v6 12/16 RESEND] rbtree: add __rb_change_child() helper function

[Jan Beulich]

>>> On 21.11.17 at 16:20,  wrote:
> From: Michel Lespinasse 
> 
> Add __rb_change_child() as an inline helper function to replace code that
> would otherwise be duplicated 4 times in the source.
> 
> No changes to binary size or speed.
> 
> Signed-off-by: Michel Lespinasse 
> Reviewed-by: Rik van Riel 
> Cc: Peter Zijlstra 
> Cc: Andrea Arcangeli 
> Cc: David Woodhouse 
> Signed-off-by: Andrew Morton 
> Signed-off-by: Linus Torvalds 
> [Linux commit 7abc704ae399fcb9c51ca200b0456f8a975a8011]
> 
> Ported to Xen.
> 
> Signed-off-by: Praveen Kumar 

Acked-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH v6 10/16 RESEND] rbtree: coding style adjustments

[Jan Beulich]

>>> On 21.11.17 at 16:20,  wrote:
> From: Michel Lespinasse 
> 
> Set comment and indentation style to be consistent with linux coding style
> and the rest of the file, as suggested by Peter Zijlstra
> 
> Signed-off-by: Michel Lespinasse 
> Cc: Andrea Arcangeli 
> Acked-by: David Woodhouse 
> Cc: Rik van Riel 
> Cc: Peter Zijlstra 
> Cc: Daniel Santos 
> Cc: Jens Axboe 
> Cc: "Eric W. Biederman" 
> Signed-off-by: Andrew Morton 
> Signed-off-by: Linus Torvalds 
> [Linux commit 7ce6ff9e5de99e7b72019c7de82fb438fe1dc5a0]
> 
> Ported to Xen.
> 
> Signed-off-by: Praveen Kumar 

Acked-by: Jan Beulich 



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

[Xen-devel] [xtf test] 117575: all pass - PUSHED

[osstest service owner]

flight 117575 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117575/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xtf  bade68b7087acd6b5ca6310a7460faeea48e4b1c
baseline version:
 xtf  167052779c0546e99aadd26ebd848e10f91fb557

Last test of basis   116370  2017-11-20 10:46:19 Z   44 days
Testing same since   117543  2018-01-02 17:33:13 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   pass
 test-xtf-amd64-amd64-2   pass
 test-xtf-amd64-amd64-3   pass
 test-xtf-amd64-amd64-4   pass
 test-xtf-amd64-amd64-5   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/xtf.git
   1670527..bade68b  bade68b7087acd6b5ca6310a7460faeea48e4b1c -> 
xen-tested-master

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

Re: [Xen-devel] [PATCH] xen: Add EFI_LOAD_OPTION support

[Jan Beulich]

>>> On 02.01.18 at 16:56,  wrote:
> When booting Xen via UEFI the Xen config file can contain multiple sections
> each describing different boot options. It is currently only possible to 
> choose
> which section to boot with if Xen is started through an EFI Shell.

Is this true? I thought that EFI Boot Manager entries can very well
have command line options. And other boot loaders (e.g. grub2)
should provide their own means to hand over options.

> @@ -375,12 +375,40 @@ static void __init PrintErrMesg(const CHAR16 *mesg, 
> EFI_STATUS ErrCode)
>  
>  static unsigned int __init get_argv(unsigned int argc, CHAR16 **argv,
>  CHAR16 *cmdline, UINTN cmdsize,
> -CHAR16 **options)
> +CHAR16 **options, bool *elo_active)
>  {
>  CHAR16 *ptr = (CHAR16 *)(argv + argc + 1), *prev = NULL;
>  bool prev_sep = true;
>  
> -for ( ; cmdsize > sizeof(*cmdline) && *cmdline;
> +if ( cmdsize > sizeof(EFI_LOAD_OPTION) )
> +{
> +/*
> + * See include/efi/efiapi.h for more info about the following
> + */

This should be a single line comment (also elsewhere).

> +EFI_LOAD_OPTION *elo = (EFI_LOAD_OPTION*)cmdline;

Missing blank before * (also elsewhere). And please make this a
pointer to const (and wherever else this would be suitable).

> +if ( elo->Attributes & LOAD_OPTION_ACTIVE )

Without any other (earlier) check, how can you reliably tell this
being a pointer to EFI_LOAD_OPTION from it being the
currently used one to CHAR16? Is the distinction perhaps UEFI
version dependent? In the 2.3 spec I can't find any information
on the layout of what ->LoadOptions points to.

> +{
> +UINT8 *_opts = (UINT8*)elo;
> +UINTN _cmdsize = cmdsize;

Leading underscores should only be used on file scope variables.

> @@ -1074,6 +1102,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
> *SystemTable)
>  bool base_video = false;
>  char *option_str;
>  bool use_cfg_file;
> +bool elo_active = false;

Please add to one of the existing bool lines instead of introducing
yet another one.

> --- a/xen/include/efi/efiapi.h
> +++ b/xen/include/efi/efiapi.h

Generally additions to this file are expected to come from the gnu-efi
package, which it was originally cloned from. I've just checked and
see that 3.0.6 doesn't appear to have any of this (yet). In such a
case at the very least you should match pre-existing style (e.g.
indentation). Commonly, however, we introduce such private
(and temporary) definitions into the source file that needs them (see
e.g. the Apple Properties interface).

> +typedef struct __packed _EFI_LOAD_OPTION {

Is the __packed here really needed? I'd much rather uncomment
the Description[] field (allowing you to get at it without using
sizeof(the-whole-structure).

Jan


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

[Xen-devel] [xen-unstable-coverity test] 117598: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen  971d299c04df379734d10c44d637433e9e564f36
baseline version:
 xen  1b33150fe06ab9217f7f12b01bc5e607f4f55658

Last test of basis   117377  2017-12-20 09:48:29 Z   14 days
Testing same since   117598  2018-01-03 09:21:56 Z0 days1 attempts


People who touched revisions under test:
  Adrian Hunter 
  Andrew Cooper 
  Andrew Morton 
  David Woodhouse 
  Jan Beulich 
  Linus Torvalds 
  Michel Lespinasse 
  Peter Zijlstra 
  Praveen Kumar 
  Roger Pau Monné 
  Stephen Rothwell 
  Tim Deegan 
  Wolfram Strepp 
  Yi Sun 

jobs:
 coverity-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/xen.git
   1b33150fe0..971d299c04  971d299c04df379734d10c44d637433e9e564f36 -> 
coverity-tested/smoke

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

Re: [Xen-devel] [PATCH v4 4/4] x86/cpuid: Enable new SSE/AVX/AVX512 cpu features

[Jan Beulich]

>>> On 03.01.18 at 09:26,  wrote:
> Intel IceLake cpu has added new cpu features: AVX512VBMI2/GFNI/
> VAES/AVX512VNNI/AVX512BITALG/VPCLMULQDQ. Those new cpu features
> need expose to guest.
> 
> The bit definition:
> CPUID.(EAX=7,ECX=0):ECX[bit 06] AVX512VBMI2
> CPUID.(EAX=7,ECX=0):ECX[bit 08] GFNI
> CPUID.(EAX=7,ECX=0):ECX[bit 09] VAES
> CPUID.(EAX=7,ECX=0):ECX[bit 10] VPCLMULQDQ
> CPUID.(EAX=7,ECX=0):ECX[bit 11] AVX512VNNI
> CPUID.(EAX=7,ECX=0):ECX[bit 12] AVX512_BITALG
> 
> The release document ref below link:
> https://software.intel.com/sites/default/files/managed/c5/15/\ 
> architecture-instruction-set-extensions-programming-reference.pdf
> 
> Signed-off-by: Yang Zhong 
> Acked-by: Jan Beulich 

I have to withdraw my ack here.

> --- a/xen/include/public/arch-x86/cpufeatureset.h
> +++ b/xen/include/public/arch-x86/cpufeatureset.h
> @@ -228,6 +228,12 @@ XEN_CPUFEATURE(AVX512VBMI,6*32+ 1) /*A  AVX-512 
> Vector Byte Manipulation Ins
>  XEN_CPUFEATURE(UMIP,  6*32+ 2) /*S  User Mode Instruction Prevention 
> */
>  XEN_CPUFEATURE(PKU,   6*32+ 3) /*H  Protection Keys for Userspace */
>  XEN_CPUFEATURE(OSPKE, 6*32+ 4) /*!  OS Protection Keys Enable */
> +XEN_CPUFEATURE(AVX512_VBMI2,  6*32+ 6) /*A  addition AVX-512 VBMI 
> Instructions */

"additional"?

> --- a/xen/tools/gen-cpuid.py
> +++ b/xen/tools/gen-cpuid.py
> @@ -255,7 +255,8 @@ def crunch_numbers(state):
>  # top of AVX512F
>  AVX512F: [AVX512DQ, AVX512IFMA, AVX512PF, AVX512ER, AVX512CD,
>AVX512BW, AVX512VL, AVX512VBMI, AVX512_4VNNIW,
> -  AVX512_4FMAPS, AVX512_VPOPCNTDQ],
> +  AVX512_4FMAPS, AVX512_VPOPCNTDQ, AVX512_VBMI2,
> +  AVX512_VNNI, AVX512_BITALG],
>  }

This is insufficient afaict: VAES and VPCLMULQDQ ought to be
made dependent upon AVX.

Jan


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

[Xen-devel] [PATCH v4 2/4] x86emul: Support vpclmulqdq

[Yang Zhong]

The previous vpclmulqdq only support AVX128.
Icelake added AVX256 support.

Signed-off-by: Yang Zhong 
---
 xen/arch/x86/x86_emulate/x86_emulate.c | 10 --
 xen/include/asm-x86/cpufeature.h   |  1 +
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c 
b/xen/arch/x86/x86_emulate/x86_emulate.c
index 2d331ea..15f37e4 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1626,6 +1626,7 @@ static bool vcpu_has(
 #define vcpu_has_clwb()vcpu_has( 7, EBX, 24, ctxt, ops)
 #define vcpu_has_sha() vcpu_has( 7, EBX, 29, ctxt, ops)
 #define vcpu_has_gfni()vcpu_has( 7, ECX,  8, ctxt, ops)
+#define vcpu_has_vpclmulqdq()  vcpu_has( 7, ECX, 10, ctxt, ops)
 #define vcpu_has_rdpid()   vcpu_has( 7, ECX, 22, ctxt, ops)
 #define vcpu_has_clzero()  vcpu_has(0x8008, EBX,  0, ctxt, ops)
 
@@ -6168,6 +6169,7 @@ x86_emulate(
 simd_0f_imm8_avx:
 host_and_vcpu_must_have(avx);
 }
+simd_0f_imm8_ymm:
 get_fpu(X86EMUL_FPU_ymm, );
 }
 else if ( vex.pfx )
@@ -7668,11 +7670,15 @@ x86_emulate(
 goto simd_0f_imm8_avx;
 
 case X86EMUL_OPC_66(0x0f3a, 0x44): /* pclmulqdq $imm8,xmm/m128,xmm */
-case X86EMUL_OPC_VEX_66(0x0f3a, 0x44): /* vpclmulqdq 
$imm8,xmm/m128,xmm,xmm */
+case X86EMUL_OPC_VEX_66(0x0f3a, 0x44): /* vpclmulqdq 
$imm8,{x,y}mm/mem,{x,y}mm,{x,y}mm */
+if ( vex.l )
+{
+host_and_vcpu_must_have(vpclmulqdq);
+goto simd_0f_imm8_ymm;
+}
 host_and_vcpu_must_have(pclmulqdq);
 if ( vex.opcx == vex_none )
 goto simd_0f3a_common;
-generate_exception_if(vex.l, EXC_UD);
 goto simd_0f_imm8_avx;
 
 case X86EMUL_OPC_VEX_66(0x0f3a, 0x4a): /* vblendvps 
{x,y}mm,{x,y}mm/mem,{x,y}mm,{x,y}mm */
diff --git a/xen/include/asm-x86/cpufeature.h b/xen/include/asm-x86/cpufeature.h
index 9c43cd8..3f24f06 100644
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -99,6 +99,7 @@
 
 /* CPUID level 0x0007:0.ecx */
 #define cpu_has_gfniboot_cpu_has(X86_FEATURE_GFNI)
+#define cpu_has_vpclmulqdq  boot_cpu_has(X86_FEATURE_VPCLMULQDQ)
 
 /* CPUID level 0x8007.edx */
 #define cpu_has_itscboot_cpu_has(X86_FEATURE_ITSC)
-- 
1.9.1


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