[Xen-devel] [PATCH] x86emul: LOCK check adjustments

[Jan Beulich]

BT, being encoded as DstBitBase just like BT{C,R,S}, nevertheless does
not write its (register or memory) operand and hence also doesn't allow
a LOCK prefix to be used.

At the same time CLAC/STAC have no need to explicitly check lock_prefix
- this is being taken care of by generic code.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -4668,8 +4668,7 @@ x86_emulate(
 case 0xca: /* clac */
 case 0xcb: /* stac */
 vcpu_must_have(smap);
-generate_exception_if(lock_prefix || vex.pfx || !mode_ring0(),
-  EXC_UD);
+generate_exception_if(vex.pfx || !mode_ring0(), EXC_UD);
 
 _regs._eflags &= ~EFLG_AC;
 if ( modrm == 0xcb )
@@ -5475,6 +5474,7 @@ x86_emulate(
 break;
 
 case X86EMUL_OPC(0x0f, 0xa3): bt: /* bt */
+generate_exception_if(lock_prefix, EXC_UD);
 emulate_2op_SrcV_nobyte("bt", src, dst, _regs._eflags);
 dst.type = OP_NONE;
 break;



x86emul: LOCK check adjustments

BT, being encoded as DstBitBase just like BT{C,R,S}, nevertheless does
not write its (register or memory) operand and hence also doesn't allow
a LOCK prefix to be used.

At the same time CLAC/STAC have no need to explicitly check lock_prefix
- this is being taken care of by generic code.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -4668,8 +4668,7 @@ x86_emulate(
 case 0xca: /* clac */
 case 0xcb: /* stac */
 vcpu_must_have(smap);
-generate_exception_if(lock_prefix || vex.pfx || !mode_ring0(),
-  EXC_UD);
+generate_exception_if(vex.pfx || !mode_ring0(), EXC_UD);
 
 _regs._eflags &= ~EFLG_AC;
 if ( modrm == 0xcb )
@@ -5475,6 +5474,7 @@ x86_emulate(
 break;
 
 case X86EMUL_OPC(0x0f, 0xa3): bt: /* bt */
+generate_exception_if(lock_prefix, EXC_UD);
 emulate_2op_SrcV_nobyte("bt", src, dst, _regs._eflags);
 dst.type = OP_NONE;
 break;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-4.8-testing test] 104298: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeatfail  like 104267
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 104267
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 104267
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 104267
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 104267
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 104267
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 104267

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  53c3a7372487e72b98d86a7368616d789d80f12e
baseline version:
 xen  daf491dc1e87fe32b35f2ae75b4add0fa96c0d7f

Last test of basis   104267  2017-01-18 17:43:44 Z1 days
Testing same since   104298  2017-01-19 11:54:17 Z0 days1 attempts


People who touched revisions under test:
  Julien Grall 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvops

Re: [Xen-devel] [PATCH] x86/emul: Corrections to cmpxchg{8, 16}b emulation (to fix 32bit PV guests)

[Jan Beulich]

>>> On 20.01.17 at 09:52,  wrote:
> @@ -2852,6 +2852,11 @@ x86_emulate(
>  else if ( !(d & Mov) ) /* optimisation - avoid slow emulated read */
>  {
>  fail_if(lock_prefix ? !ops->cmpxchg : !ops->write);
> +
> +/* cmpxchg{8,16}b handles its own operand read. */
> +if ( ext == ext_0f && b == 0xc7 )
> +break;

This part in particular is why I don't like this variant of the fix
(and if at all it would need placing ahead of the fail_if()).
I'm sorry for having talked you into that direction yesterday.

Jan


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

[Xen-devel] [PATCH] docs: clarify xl mem-max semantics

[Juergen Gross]

The information given in the xl man page for the mem-max command is
rather brief. Expand it in order to let the reader understand what it
is really doing.

As the related libxl function libxl_domain_setmaxmem() isn't much
clearer add a comment to it explaining the desired semantics.

Signed-off-by: Juergen Gross 
---
 docs/man/xl.pod.1.in | 10 ++
 tools/libxl/libxl.c  |  6 ++
 2 files changed, 16 insertions(+)

diff --git a/docs/man/xl.pod.1.in b/docs/man/xl.pod.1.in
index 09c1faa..62307e8 100644
--- a/docs/man/xl.pod.1.in
+++ b/docs/man/xl.pod.1.in
@@ -401,6 +401,16 @@ for bytes.
 The mem-max value may not correspond to the actual memory used in the
 domain, as it may balloon down its memory to give more back to the OS.
 
+The value given just sets the memory amount the domain is allowed to allocate
+in the hypervisor. Thus it can't be lower than the current reservation, but
+it is allowed to be higher than the configured maximum memory size of the
+domain (B parameter in the domain's configuration). Setting the
+allowed memory size via B above the B size won't let use
+this value to be used for B, as B will still use
+B as an upper limit.
+
+The domain is not receiving any signal regarding the changed memory limit.
+
 =item B I I
 
 Set the domain's used memory using the balloon driver; append 't' for
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 0622311..ed59510 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4018,6 +4018,12 @@ out:
 
 
/**/
 
+/*
+ * Set the maximum memory size of the domain in the hypervisor. There is no
+ * change of the current memory size involved. The allowed memory size can
+ * even be above the configured maxmem size of the domain, but the related
+ * Xenstore entry memory/static-max isn't modified!
+ */
 int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint64_t max_memkb)
 {
 GC_INIT(ctx);
-- 
2.10.2


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

Re: [Xen-devel] [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms

[Jan Beulich]

>>> On 20.01.17 at 02:34,  wrote:
> @@ -100,20 +107,48 @@ multiboot2_header_start:
>  gdt_boot_descr:
>  .word   6*8-1
>  .long   sym_phys(trampoline_gdt)
> +.long   0 /* Needed for 64-bit lgdt */
> +
> +.align 4
> +vga_text_buffer:
> +.long   0xb8000
> +
> +efi_platform:
> +.byte   0

You mean to modify these fields, but you add them to a r/o section.

> +.Lefi_multiboot2_proto:
> +/* Zero EFI SystemTable and EFI ImageHandle addresses. */
> +xor %esi,%esi
> +xor %edi,%edi
> +
> +/* Skip Multiboot2 information fixed part. */
> +lea (MB2_fixed_sizeof+MULTIBOOT2_TAG_ALIGN-1)(%rbx),%ecx

In an earlier reply to Andrew's inquiry regarding the possible
truncation here you said that grub can be made obey to such a
load restriction. None of the tags added here or in patch 2
appear to have such an effect, so would you please clarify how
the address restriction is being enforced?

> +and $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
> +
> +.Lefi_mb2_tsize:
> +/* Check Multiboot2 information total size. */
> +mov %ecx,%r8d
> +sub %ebx,%r8d
> +cmp %r8d,MB2_fixed_total_size(%rbx)
> +jbe run_bs
> +
> +/* Are EFI boot services available? */
> +cmpl$MULTIBOOT2_TAG_TYPE_EFI_BS,MB2_tag_type(%rcx)
> +jne .Lefi_mb2_st
> +
> +/* We are on EFI platform and EFI boot services are available. */
> +incbefi_platform(%rip)
> +
> +/*
> + * Disable real mode and other legacy stuff which should not
> + * be run on EFI platforms.
> + */
> +incbskip_realmode(%rip)
> +jmp .Lefi_mb2_next_tag
> +
> +.Lefi_mb2_st:
> +/* Get EFI SystemTable address from Multiboot2 information. */
> +cmpl$MULTIBOOT2_TAG_TYPE_EFI64,MB2_tag_type(%rcx)
> +cmove   MB2_efi64_st(%rcx),%rsi
> +je  .Lefi_mb2_next_tag
> +
> +/* Get EFI ImageHandle address from Multiboot2 information. */
> +cmpl$MULTIBOOT2_TAG_TYPE_EFI64_IH,MB2_tag_type(%rcx)
> +cmove   MB2_efi64_ih(%rcx),%rdi
> +je  .Lefi_mb2_next_tag
> +
> +/* Is it the end of Multiboot2 information? */
> +cmpl$MULTIBOOT2_TAG_TYPE_END,MB2_tag_type(%rcx)
> +je  run_bs
> +
> +.Lefi_mb2_next_tag:
> +/* Go to next Multiboot2 information tag. */
> +add MB2_tag_size(%rcx),%ecx
> +add $(MULTIBOOT2_TAG_ALIGN-1),%ecx
> +and $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
> +jmp .Lefi_mb2_tsize
> +
> +run_bs:

.Lrun_bs:

> +/* Are EFI boot services available? */
> +cmpb$0,efi_platform(%rip)
> +jnz 0f
> +
> +/* Jump to .Lmb2_no_bs after switching CPU to x86_32 mode. */
> +lea .Lmb2_no_bs(%rip),%edi
> +jmp x86_32_switch
> +0:

I realize you need to avoid clobbering %rdi in the non-error case,
but the register choice seems sub-optimal: If you used a register
which you can clobber here (e.g. %edx as it seems, using %edi in
its place at x86_32_switch and cs32_switch), you could simplify
this to

cmpb ...
lea ...
je x86_32_switch

at once avoiding all the numeric labels here.

> +2:
> +push%rax
> +push%rdi
> +
> +/*
> + * Initialize BSS (no nasty surprises!).
> + * It must be done earlier than in BIOS case
> + * because efi_multiboot2() touches it.
> + */
> +lea __bss_start(%rip),%edi
> +lea __bss_end(%rip),%ecx
> +sub %edi,%ecx
> +shr $3,%ecx
> +xor %eax,%eax
> +rep stosq
> +
> +pop %rdi
> +
> +/*
> + * efi_multiboot2() is called according to System V AMD64 ABI:
> + *   - IN: %rdi - EFI ImageHandle, %rsi - EFI SystemTable,
> + *   - OUT: %rax - highest allocated memory address below 1 MiB;
> + * memory below this address is used for trampoline
> + * stack, trampoline itself and as a storage for
> + * mbi struct created in reloc().
> + *
> + * MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO tag is not provided
> + * on EFI platforms. Hence, it could not be used like
> + * on legacy BIOS platforms.
> + */
> +callefi_multiboot2

Now that we had a need for commit f6b7fedc89 ("x86/EFI: meet
further spec requirements for runtime calls") I'm worried about stack
alignment here. Does GrUB call or jmp to our entry point (and is that
firmly specified to be the case)? Perhaps it would be a good idea to
align the stack earlier on in any case. Or if not (and if alignment at
this call is ABI conforming), a comment should be left here to warn
people of future modifications to the amount of items pushed onto /
popped off the stack.

> +trampoline_setup:
> +

Re: [Xen-devel] [PATCH RESEND v5 01/24] docs: create L2 Cache Allocation Technology (CAT) feature document

[Tian, Kevin]

> From: Yi Sun
> Sent: Thursday, January 19, 2017 2:01 PM
> 
> This patch creates L2 CAT feature document in doc/features/.
> It describes details of L2 CAT.

A good write-up, but still some improvements required. :-)

> 
> Signed-off-by: Yi Sun 
> ---
>  docs/features/intel_psr_l2_cat.pandoc | 347
> ++
>  1 file changed, 347 insertions(+)
>  create mode 100644 docs/features/intel_psr_l2_cat.pandoc
> 
> diff --git a/docs/features/intel_psr_l2_cat.pandoc
> b/docs/features/intel_psr_l2_cat.pandoc
> new file mode 100644
> index 000..77bd61f
> --- /dev/null
> +++ b/docs/features/intel_psr_l2_cat.pandoc
> @@ -0,0 +1,347 @@
> +% Intel L2 Cache Allocation Technology (L2 CAT) Feature
> +% Revision 1.0
> +
> +\clearpage
> +
> +# Basics
> +
> + 
> + Status: **Tech Preview**
> +
> +Architecture(s): Intel x86
> +
> +   Component(s): Hypervisor, toolstack
> +
> +   Hardware: Atom codename Goldmont and beyond CPUs
> + 
> +
> +# Overview
> +
> +L2 CAT allows an OS or Hypervisor/VMM to control allocation of a
> +CPU's shared L2 cache based on application priority or Class of Service
> +(COS). Each CLOS is configured using capacity bitmasks (CBM) which
> +represent cache capacity and indicate the degree of overlap and
> +isolation between classes. Once L2 CAT is configured, the processor
> +allows access to portions of L2 cache according to the established
> +class of service.

I would suggest make this doc for all CAT features, otherwise some
content looks incomplete when you say adding new options or new
ranges with assumption that reader understands the existing stuff.
Yes I do notice you provide many background about L3 CAT/CDP. Let's
just make it complete.

Also as a permanent design, 'new' is not preferred since it will become
'existing' once it's checked in.

> +
> +## Terminology
> +
> +* CAT Cache Allocation Technology
> +* CBM Capacity BitMasks
> +* CDP Code and Data Prioritization
> +* COS/CLOSClass of Service
> +* MSRsMachine Specific Registers
> +* PSR Intel Platform Shared Resource
> +* VMM Virtual Machine Monitor
> +
> +# User details
> +
> +* Feature Enabling:
> +
> +  Add "psr=cat" to boot line parameter to enable all supported level CAT
> +  features.
> +
> +* xl interfaces:
> +
> +  1. `psr-cat-show [OPTIONS] domain-id`:

Need an introduction of 'domain-id'. Is it a Xen domain ID, or
new hardware-defined domain ID (e.g. one socket per domain)?

> +
> + Show domain L2 or L3 CAT CBM.

also please introduce how CBM actually works

> +
> + New option `-l` is added.
> + `-l2`: Show cbm for L2 cache.
> + `-l3`: Show cbm for L3 cache.
> +
> + If neither `-l2` nor `-l3` is given, show both of them. If any one
> + is not supported, will print error info.
> +
> +  2. `psr-cat-cbm-set [OPTIONS] domain-id cbm`:
> +
> + Set domain L2 or L3 CBM.

to be consistent with 'show' - 'CBM' or 'CAT CBM'?

I understand those xl interfaces are there already. If there is chance
to change, I'd recommend removing 'cbm'. Just psr-cat-set to be
consistent with 'show'.

> +
> + New option `-l` is added.
> + `-l2`: Specify cbm for L2 cache.
> + `-l3`: Specify cbm for L3 cache.
> +
> + If neither `-l2` nor `-l3` is given, level 3 is the default option.
> +
> +  3. `psr-hwinfo [OPTIONS]`:
> +
> + Show L2 & L3 CAT HW informations on every socket.

informations -> information

and which HW information? please elaborate.

and where is the interface of setting COS for VCPU?

> +
> +# Technical details
> +
> +L2 CAT is a member of Intel PSR features and part of CAT, it shares
> +some base PSR infrastructure in Xen.

Then add some background of PSR would be useful if nothing exists yet?

> +
> +## Hardware perspective
> +
> +L2 CAT defines a new range MSRs to assign different L2 cache access
> +patterns which are known as CBMs, each CBM is associated with a COS.
> +
> +```
> +
> ++++
> +   IA32_PQR_ASSOC   | MSR (per socket)   |Address |
> + ++---+---+ +++
> + ||COS|   | | IA32_L2_QOS_MASK_0 | 0xD10  |
> + ++---+---+ +++
> +└-> | ...|  ...   |
> ++++
> +| IA32_L2_QOS_MASK_n | 0xD10+n (n<64) |
> ++++
> +```
> +
> +When context switch happens, the COS of VCPU is written to per-thread
> +MSR `IA32_PQR_ASSOC`, and then hardware enforces L2 cache allocation
> +according to the corresponding CBM.
> +
> 

[Xen-devel] memory hotplug for domUs

[Juergen Gross]

Recently Jim asked me why he can use "xl mem-max" to raise the allowed
memory size of a domain in the hypervisor above the configured maxmem
limit of the domain, but not use "xl mem-set" to balloon the domain up
to this value later.

I thought libxl_domain_setmaxmem() being buggy as it doesn't modify the
memory/static-max value in Xenstore and posted a patch adding the
Xenstore modification.

Later I had an IRC discussion with Ian on #xendevel with the following
outcome:

xl mem-max is defined to do things as it does without my patch. OTOH
this is documented very poorly. I'll send a patch enhancing the xl man
page in this regard.

For support of memory hotplug in a domain (adding memory above the
current defined maximum memory as in Xenstore memory/static-max) we
decided to add a new option to xl.

Basically doing such a kind of memory hotplug requires the capability
of the guest to support this feature. PV Linux kernel has support for
it if the kernel has been built with CONFIG_XEN_BALLOON_MEMORY_HOTPLUG
set. For HVM guests support is more difficult as there has to be some
reserved space in the memory map of the guest for hotplugged memory.

Ian suggested to let the guest write a Xenstore entry indicating
support of memory hotplug in order for Xen tools to decide whether such
an operation should be supported. As this entry isn't being written by
current kernels which do support hotplug there has to be some kind of
"force" flag to override the test for presence of the Xenstore entry.

We first thought to enhance "xl mem-set", but after some more thinking
about it I'd rather add a new xl command, e.g. "mem-add" (we could later
even add "mem-remove" to support memory unplug).

xl mem-add would add the specified amount of memory to a running domain
and it would raise memory/static-max accordingly. The first version
would support PV domains only, but future support for HVM could be
possible (the domain configuration would have to be enhanced to create
a memory map entry indicating hot-pluggable memory). Other future
enhancements would include the possibility to add memory to a vnuma
node of the domain, possibly taking the memory from a specified numa
node of the host.

In case this proposal is accepted I can write patches (libxl and Linux
kernel).


Juergen

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

Re: [Xen-devel] [xen-unstable test] 104131: regressions - FAIL

[Xuquan (Quan Xu)]

On January 16, 2017 1:26 PM, Tian, Kevin wrote:
>I cannot come up a valid reason for such situation (intack.vector is 0x30 while
>pt_vector is 0x38 from Chao's data). pt_update_irq is invoked before checking
>highest pending IRRs so pt_vector should be honored anyway.
>One possible reason is that being some reason pt_vector is not in vIRR at that
>point (due to some bug in the path from PIR to vIRR). 

btw, for PIR.. I find that there might be a bug in 
__vmx_deliver_posted_interrupt()...
why test_and_set_bit(VCPU_KICK_SOFTIRQ, _pending(cpu)) ??

static void __vmx_deliver_posted_interrupt(struct vcpu *v)
{
...
if ( !test_and_set_bit(VCPU_KICK_SOFTIRQ, _pending(cpu))
...
}

Suppose that vCPUx is in guest mode, there are two (even more) interrupts to 
vCPUx..
As the bit is set when delivers the first interrupt... the second interrupt is 
pending until next VM entry -- by PIR to vIRR..


Quan




However I didn't catch
>such bug simply by looking at code. We need reproduce this problem in
>developer side to find out actual reason. Andrew it'd be helpful if you can 
>help
>Quan/Chao to find out more test environment info.
>
>One thing noted though. The original patch from Quan is actually orthogonal to
>this ASSERT. Regardless of whether intack.vector is larger or smaller than
>pt_vector, we always require the trick as long as pt_vector is not the one 
>being
>currently programmed to RVI. Then do we want to revert the whole commit
>until the problem is finally fixed, or OK to just remove ASSERT (or replace 
>with
>WARN_ON with more debug info) to unblock test system before the fix is
>ready?
>
>Thanks
>Kevin

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 19ca06bb84cafd661f7da34e9ca3c7ec6add1135
baseline version:
 ovmf 5ab0ffc9f64f5a539a9bdb50446b7fbf92b845d6

Last test of basis   104279  2017-01-19 02:01:37 Z1 days
Testing same since   104306  2017-01-19 15:43:17 Z0 days1 attempts


People who touched revisions under test:
  Dandan Bi 
  Star Zeng 
  Thomas Huth 
  Zhang Lubo 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=19ca06bb84cafd661f7da34e9ca3c7ec6add1135
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
19ca06bb84cafd661f7da34e9ca3c7ec6add1135
+ branch=ovmf
+ revision=19ca06bb84cafd661f7da34e9ca3c7ec6add1135
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.8-testing
+ '[' x19ca06bb84cafd661f7da34e9ca3c7ec6add1135 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : 

Re: [Xen-devel] [xen-unstable test] 104131: regressions - FAIL

[Jan Beulich]

>>> On 20.01.17 at 09:47,  wrote:
> Jan, I can't follow vector classes.. could you explain more? Thanks..

For determining vector priority, the LAPIC uses only the high 4 bits.
Iirc this is well documented in the SDM.

Jan


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

[Xen-devel] [PATCH] x86/emul: Corrections to cmpxchg{8, 16}b emulation (to fix 32bit PV guests)

[Andrew Cooper]

c/s ff913f6 "x86/PV: restrict permitted instructions during memory write
emulation" added an x86_insn_is_mem_write() restriction to all PV instructions
which trap for emulation because of read-only mappings (pagetables, mmcfg and
msi-x intercepts).

Because of the way cmpxchg{8,16}b was decoded (being part of Grp9), it didn't
end up flagged as a DstMem instruction, and failed the x86_insn_is_mem_write()
check.  This causes the emulation to be (incorrectly) rejected, causing
particular problems for 32bit PV guests which need to use cmpxchg8b for atomic
pagetable updates.

Add an early operand adjustment for cmpxchg{8,16}b to flag it as DstMem, which
allows for the removal of final special case for lock_prefix handling of
DstNone instructions.  This does however require introducing an exclusion into
the DstMem handling, as cmpxchg16b would overflow   The emulation of
cmpxchg{8,16}b completes all actions, so avoid the repeated operand writeback.

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

Partially RFC: This is a bit of a rats nest.
---
 tools/tests/x86_emulator/test_x86_emulator.c | 70 
 xen/arch/x86/x86_emulate/x86_emulate.c   | 19 +---
 2 files changed, 82 insertions(+), 7 deletions(-)

diff --git a/tools/tests/x86_emulator/test_x86_emulator.c 
b/tools/tests/x86_emulator/test_x86_emulator.c
index 245d1c6..7c7553b 100644
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -23,6 +23,11 @@ static const struct {
 #endif
 };
 
+struct test_local_state
+{
+unsigned int fetches, reads, writes, cmpxchgs;
+};
+
 /* EFLAGS bit definitions. */
 #define EFLG_OF (1<<11)
 #define EFLG_DF (1<<10)
@@ -41,6 +46,10 @@ static int read(
 unsigned int bytes,
 struct x86_emulate_ctxt *ctxt)
 {
+struct test_local_state *state = ctxt->data;
+
+state->reads++;
+
 if ( verbose )
 printf("** %s(%u, %p,, %u,)\n", __func__, seg, (void *)offset, bytes);
 
@@ -96,6 +105,10 @@ static int fetch(
 unsigned int bytes,
 struct x86_emulate_ctxt *ctxt)
 {
+struct test_local_state *state = ctxt->data;
+
+state->fetches++;
+
 if ( verbose )
 printf("** %s(%u, %p,, %u,)\n", __func__, seg, (void *)offset, bytes);
 
@@ -110,6 +123,10 @@ static int write(
 unsigned int bytes,
 struct x86_emulate_ctxt *ctxt)
 {
+struct test_local_state *state = ctxt->data;
+
+state->writes++;
+
 if ( verbose )
 printf("** %s(%u, %p,, %u,)\n", __func__, seg, (void *)offset, bytes);
 
@@ -127,6 +144,10 @@ static int cmpxchg(
 unsigned int bytes,
 struct x86_emulate_ctxt *ctxt)
 {
+struct test_local_state *state = ctxt->data;
+
+state->cmpxchgs++;
+
 if ( verbose )
 printf("** %s(%u, %p,, %u,)\n", __func__, seg, (void *)offset, bytes);
 
@@ -182,6 +203,7 @@ static struct x86_emulate_ops emulops = {
 
 int main(int argc, char **argv)
 {
+struct test_local_state state;
 struct x86_emulate_ctxt ctxt;
 struct cpu_user_regs regs;
 char *instr;
@@ -196,6 +218,7 @@ int main(int argc, char **argv)
 setbuf(stdout, NULL);
 
 ctxt.regs = 
+ctxt.data = 
 ctxt.force_writeback = 0;
 ctxt.vendor= X86_VENDOR_UNKNOWN;
 ctxt.addr_size = 8 * sizeof(void *);
@@ -461,6 +484,53 @@ int main(int argc, char **argv)
 goto fail;
 printf("okay\n");
 
+#ifdef __x86_64__
+memset(, 0, sizeof(state));
+printf("%-40s", "Testing lock cmpxchg16b (%rdi) [succeeding]...");
+instr[0] = 0xf0; instr[1] = 0x48; instr[2] = 0x0f; instr[3] = 0xc7; 
instr[4] = 0x0f;
+res[0]  = 0x9abcdef0;
+res[1]  = 0x12345678;
+res[2]  = 0x87654321;
+res[3]  = 0x12345678;
+regs.rax= 0x123456789abcdef0ull;
+regs.rdx= 0x1234567887654321ull;
+regs.rflags = 0x200;
+regs.rcx= 0xull;
+regs.rbx= 0xull;
+regs.rip= (unsigned long)[0];
+regs.rdi= (unsigned long)res;
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) ||
+ (res[0] != 0x) ||
+ (res[1] != 0x) ||
+ (res[2] != 0x) ||
+ (res[3] != 0x) ||
+ (state.reads != 1) ||
+ (state.writes != 0) ||
+ (state.cmpxchgs != 1) ||
+ ((regs.rflags&0x240) != 0x240) ||
+ (regs.rip != (unsigned long)[5]) )
+goto fail;
+printf("okay\n");
+
+memset(, 0, sizeof(state));
+printf("%-40s", "Testing lock cmpxchg16b (%rdi) [misaligned]...");
+instr[0] = 0xf0; instr[1] = 0x48; instr[2] = 0x0f; instr[3] = 0xc7; 
instr[4] = 0x0f;
+regs.eflags = 0x200;
+regs.eip= (unsigned long)[0];
+regs.edi= ((unsigned long)res) + 1;
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_EXCEPTION) ||
+ (ctxt.event.vector != 0xd) ||
+ (ctxt.event.error_code != 0) ||
+ (state.reads != 0) ||
+ (state.writes != 0) 

Re: [Xen-devel] [PATCH v12 06/10] x86: change default load address from 1 MiB to 2 MiB

[Jan Beulich]

>>> On 20.01.17 at 05:06,  wrote:
> On 1/19/17 8:34 PM, Daniel Kiper wrote:
>> Subsequent patches introducing relocatable early boot code play with
>> page tables using 2 MiB huge pages. If load address is not aligned at
>> 2 MiB then code touching such page tables must have special cases for
>> start and end of Xen image memory region. So, let's make life easier
>> and move default load address from 1 MiB to 2 MiB. This way page table
>> code will be nice and easy. Hence, there is a chance that it will be
>> less error prone too... :-)))
>> 
>> Additionally, drop first 2 MiB mapping from Xen image mapping.
>> It is no longer needed.
>> 
>> Signed-off-by: Daniel Kiper 
>> Reviewed-by: Jan Beulich 
>> Reviewed-by: Doug Goldstein 
> 
> FWIW, I can't find where I offered my R-b for this patch. Its part of
> the series I've said fails on my hardware.

Looks like you had responded to v11 00/13 without naming specific
patches the tag would apply to, so I think Daniel legitimately applied
it to the entire series. Whether he should have dropped it again
after your report of things not working is kind of fuzzy, unless at
some point you've explicitly withdrawn them (which I don't recall
you having done).

Jan


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

Re: [Xen-devel] [xen-unstable test] 104131: regressions - FAIL

[Xuquan (Quan Xu)]

On January 18, 2017 5:38 PM, Jan Beulich wrote:
 On 18.01.17 at 05:57,  wrote:
>> Attached was my earlier comment:
>>
>> --
>>> >>> On 20.12.16 at 06:37,  wrote:
>>> >>  From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
>>> >> Sent: Friday, December 16, 2016 5:40 PM
>>> >> -if (pt_vector != -1)
>>> >> -vmx_set_eoi_exit_bitmap(v, pt_vector);
>>> >> +if ( pt_vector != -1 ) {
>>> >> +if ( intack.vector > pt_vector )
>>> >> +vmx_set_eoi_exit_bitmap(v, intack.vector);
>>> >> +else
>>> >> +vmx_set_eoi_exit_bitmap(v, pt_vector);
>>> >> +}
>>> >
>>> > Above can be simplified as one line change:
>>> >   if ( pt_vector != -1 )
>>> >   vmx_set_eoi_exit_bitmap(v, intack.vector);
>>>
>>> Hmm, I don't understand. Did you mean to use max() here? Or else how
>>> is this an equivalent of the originally proposed code?
>>>
>>
>> Original code is not 100% correct. The purpose is to set EOI exit
>> bitmap for any vector which may block injection of pt_vector - give
>> chance to recognize pt_vector in future intack and then do pt intr
>> post. The simplified code achieves this effect same as original code
>> if intack.vector >= vector. I cannot come up a case why intack.vector
>> might be smaller than vector. If this case happens, we still need
>> enable exit bitmap for intack.vector instead of pt_vector for said
>> purpose while original code did it wrong.
>>
>> Thanks
>> Kevin
>> --
>>
>> Using intack.vector is always expected here regardless of the
>> comparison result between intack.vector and pt_vector. The reason why
>> I was OK adding an ASSERT was simply to test whether
>> intack.vecor> itself.
>
>Well, a vector lower than pt_vector can't block delivery. Or wait:
>Don't we need to consider vector classes here, i.e.
>
>ASSERT((intack.vector >> 4) >= (pt_vector >> 4));
>

Jan, I can't follow vector classes.. could you explain more? Thanks..


Quan

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

Re: [Xen-devel] [PATCH 1/1] kexec: ensure kexec_status() return bit value of 0 or 1

[Jan Beulich]

>>> On 19.01.17 at 18:10,  wrote:
> --- a/xen/common/kexec.c
> +++ b/xen/common/kexec.c
> @@ -1182,7 +1182,8 @@ static int kexec_status(XEN_GUEST_HANDLE_PARAM(void) 
> uarg)
>  if ( kexec_load_get_bits(status.type, , ) )
>  return -EINVAL;
>  
> -return test_bit(bit, _flags);
> +/* Ensure return bit value of 0 or 1 */
> +return !!test_bit(bit, _flags);
>  }

I don't see the point of adding a comment here, but I'll let Andrew as
the maintainer judge. In any event
Reviewed-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH v13 3/3] iommu: add rmrr Xen command line option for extra rmrrs

[Jan Beulich]

>>> On 19.01.17 at 18:44,  wrote:
> On Thu, Jan 19, 2017 at 01:29:15AM -0700, Jan Beulich wrote:
>> >>> On 18.01.17 at 20:56,  wrote:
>> > I am looking at rmrr_identity_mapping where the RMRR paddr get converted
>> > to pfn and then mapped with iommu.
>> > If ( rmrr->end_address & ~PAGE_SHIFT_MASK_4K ) == 0, the while loop
>> > while ( base_pfn < end_pfn )
>> >  will not map that inclusive end_address of rmrr.
>> > Does it seem wrong?
>> 
>> I don't think so, no. end_pfn is being calculated using
>> PAGE_ALIGN_4K(), i.e. rounding up.
> 
> I mean to say, if the end address is already aligned, then the page wont
> be mapped.

Ah, that would be a problem, but would only affect systems with
non-spec compliant firmware, as the doc says: "The reserved
memory region size (Limit - Base + 1) must be an integer multiple of
4KB", along with requiring the base address to be 4k-aligned.

Jan


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

[Xen-devel] [PATCH v2] x86: segment attribute handling adjustments

[Jan Beulich]

Null selector loads into SS (possible in 64-bit mode only, and only in
rings other than ring 3) must not alter SS.DPL. (This was found to be
an issue on KVM, and fixed in Linux commit 33ab91103b.)

Further arch_set_info_hvm_guest() didn't make sure that the ASSERT()s
in hvm_set_segment_register() wouldn't trigger: Add further checks, but
tolerate (adjust) clear accessed (CS, SS, DS, ES) and busy (TR) bits.

Finally the setting of the accessed bits for user segments was lost by
commit dd5c85e312 ("x86/hvm: Reposition the modification of raw segment
data from the VMCB/VMCS"), yet VMX requires them to be set for usable
segments. Add respective ASSERT()s (the only path not properly setting
them was arch_set_info_hvm_guest()).

Signed-off-by: Jan Beulich 
---
v2: Simplify TSS type check in arch_set_info_hvm_guest().
---
TBD: Said Linux commit also fiddles with G, D/B, P, S, and TYPE, yet
 that does not appear to be generally needed - on my Westmere box
 SS attributes of 0x1c000 (which is what the hardware loads for a
 null selector load), 0x1, or 0x14000 do not result in VM entry
 failures.

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1294,16 +1294,24 @@ static inline int check_segment(struct s
 return 0;
 }
 
-if ( seg != x86_seg_tr && !reg->attr.fields.s )
+if ( seg == x86_seg_tr )
 {
-gprintk(XENLOG_ERR,
-"System segment provided for a code or data segment\n");
-return -EINVAL;
-}
+if ( reg->attr.fields.s )
+{
+gprintk(XENLOG_ERR, "Code or data segment provided for TR\n");
+return -EINVAL;
+}
 
-if ( seg == x86_seg_tr && reg->attr.fields.s )
+if ( reg->attr.fields.type != SYS_DESC_tss_busy )
+{
+gprintk(XENLOG_ERR, "Non-32-bit-TSS segment provided for TR\n");
+return -EINVAL;
+}
+}
+else if ( !reg->attr.fields.s )
 {
-gprintk(XENLOG_ERR, "Code or data segment provided for TR\n");
+gprintk(XENLOG_ERR,
+"System segment provided for a code or data segment\n");
 return -EINVAL;
 }
 
@@ -1366,7 +1374,8 @@ int arch_set_info_hvm_guest(struct vcpu
 #define SEG(s, r) ({\
 s = (struct segment_register){ .base = (r)->s ## _base, \
.limit = (r)->s ## _limit,   \
-   .attr.bytes = (r)->s ## _ar };   \
+   .attr.bytes = (r)->s ## _ar |\
+   (x86_seg_##s != x86_seg_tr ? 1 : 2) }; \
 check_segment(, x86_seg_ ## s); })
 
 rc = SEG(cs, regs);
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5731,6 +5731,7 @@ void hvm_set_segment_register(struct vcp
 case x86_seg_cs:
 ASSERT(reg->attr.fields.p);  /* Usable. */
 ASSERT(reg->attr.fields.s);  /* User segment. */
+ASSERT(reg->attr.fields.type & 0x1); /* Accessed. */
 ASSERT((reg->base >> 32) == 0);  /* Upper bits clear. */
 break;
 
@@ -5740,6 +5741,7 @@ void hvm_set_segment_register(struct vcp
 ASSERT(reg->attr.fields.s);  /* User segment. */
 ASSERT(!(reg->attr.fields.type & 0x8));  /* Data segment. */
 ASSERT(reg->attr.fields.type & 0x2); /* Writeable. */
+ASSERT(reg->attr.fields.type & 0x1); /* Accessed. */
 ASSERT((reg->base >> 32) == 0);  /* Upper bits clear. */
 }
 break;
@@ -5755,6 +5757,8 @@ void hvm_set_segment_register(struct vcp
 if ( reg->attr.fields.type & 0x8 )
 ASSERT(reg->attr.fields.type & 0x2); /* Readable. */
 
+ASSERT(reg->attr.fields.type & 0x1); /* Accessed. */
+
 if ( seg == x86_seg_fs || seg == x86_seg_gs )
 ASSERT(is_canonical_address(reg->base));
 else
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1471,6 +1471,11 @@ protmode_load_seg(
 else
 sreg->attr.bytes = 0;
 sreg->sel = sel;
+
+/* Since CPL == SS.DPL, we need to put back DPL. */
+if ( seg == x86_seg_ss )
+sreg->attr.fields.dpl = sel;
+
 return X86EMUL_OKAY;
 }
 


x86: segment attribute handling adjustments

Null selector loads into SS (possible in 64-bit mode only, and only in
rings other than ring 3) must not alter SS.DPL. (This was found to be
an issue on KVM, and fixed in Linux commit 33ab91103b.)

Further arch_set_info_hvm_guest() didn't make sure that the ASSERT()s
in hvm_set_segment_register() wouldn't trigger: Add further checks, but
tolerate (adjust) clear accessed (CS, SS, DS, ES) and busy (TR) bits.

Finally the setting of the accessed bits for user segments was 

[Xen-devel] [PATCH] x86emul: CMPXCHG{8,16}B are memory writes

[Jan Beulich]

This fixes a regression introduced by commit ff913f68c9 ("x86/PV:
restrict permitted instructions during memory write emulation")
breaking namely 32-bit PV guests (which commonly use CMPXCHG8B for
certain page table updates).

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

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -6566,6 +6566,9 @@ x86_insn_is_mem_write(const struct x86_e
 
 case X86EMUL_OPC(0x0f, 0xba):
 return (state->modrm_reg & 7) > 4; /* BTS / BTR / BTC */
+
+case X86EMUL_OPC(0x0f, 0xc7):
+return (state->modrm_reg & 7) == 1; /* CMPXCHG{8,16}B */
 }
 
 return false;



x86emul: CMPXCHG{8,16}B are memory writes

This fixes a regression introduced by commit ff913f68c9 ("x86/PV:
restrict permitted instructions during memory write emulation")
breaking namely 32-bit PV guests (which commonly use CMPXCHG8B for
certain page table updates).

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

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -6566,6 +6566,9 @@ x86_insn_is_mem_write(const struct x86_e
 
 case X86EMUL_OPC(0x0f, 0xba):
 return (state->modrm_reg & 7) > 4; /* BTS / BTR / BTC */
+
+case X86EMUL_OPC(0x0f, 0xc7):
+return (state->modrm_reg & 7) == 1; /* CMPXCHG{8,16}B */
 }
 
 return false;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel