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

[Yu Zhang]

On 9/9/2016 1:22 PM, Yu Zhang wrote:



On 9/2/2016 6:47 PM, Yu Zhang wrote:

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

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

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

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

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

changes in v6:
   - Clarify logic in hvmemul_do_io().
   - Use recursive lock for ioreq server lock.
   - Remove debug print when mapping ioreq server.
   - Clarify code in ept_p2m_type_to_flags() for consistency.
   - Remove definition of P2M_IOREQ_HANDLE_WRITE_ACCESS.
   - Add comments for HVMMEM_ioreq_server to note only changes
 to/from HVMMEM_ram_rw are permitted.
   - Add domain_pause/unpause() in hvm_map_mem_type_to_ioreq_server()
 to avoid the race condition when a vm exit happens on a write-
 protected page, just to find the ioreq server has been unmapped
 already.
   - Introduce a seperate patch to delay the release of p2m
 lock to avoid the race condition.
   - Introduce a seperate patch to handle the read-modify-write
 operations on a write protected page.



Why do we need to do this?  Won't the default case just DTRT if it finds
that the ioreq server has been unmapped?


Well, patch 4 will either mark the remaining p2m_ioreq_server entries as 
"recal" or

reset to p2m_ram_rw directly. So my understanding is that we do not wish to
see a ept violation due to a p2m_ioreq_server access after the ioreq 
server is unmapped.
Yet without this domain_pause/unpause() pair, VM accesses may trigger an 
ept violation
during the hvmop hypercall(hvm_map_mem_type_to_ioreq_server), just to 
find the ioreq
server is NULL. Then we would have to provide handlers which just do the 
copy to/from

actions for the VM. This seems awkward to me.

IIUC, with domain_pause/unpause(), we can guarantee that the VM will not 
trigger such
ept violation during the unmapping process. After that, accesses to a 
p2m_ioreq_server page

will only trigger ept misconfiguration. :)

Thanks
Yu

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

Re: [Xen-devel] [PATCH v3 1/1] xen: move TLB-flush filtering out into populate_physmap during vm creation

[Dongli Zhang]

Thank you all very much for the feedback. I will address them in the next
version.

> > Did you go through and check that there is nothing this information
> > can already get derived from? I can't immediately point you at
> > anything, but it feels like there should. 
> >
> Indeed. And if there isn't and we need to do add our own flagging,
> isn't there a better way and place where to put it (e.g., what Juergen
> and Andrew are hinting at)?

I prefer that to derive whether guest boot finishes is neither limited to a
specific domain type (pv, hvm, pvhvm or pvh) nor a specific arch (i386, x86_64,
arm32, arm64 or more in the future). Ideally, I would have one or a combo of
fields belong to "struct domain" but there isn't.

Can we use the field in vcpu[0]? How about domain->vcpu[0]->last_run_time?  The
only line of code updating the field is in function "schedule":

1411prev->last_run_time = now;

I am afraid if there would be any existing (I did not find one) or future
interfaces that can reset the entire vcpu[0] to 0.

Dongli Zhang

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

[Xen-devel] [xen-4.4-testing test] 100815: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 99757
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 99757
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 99757
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeatfail  like 99757

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 build-i386-rumprun5 rumprun-buildfail   never pass
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail 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  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-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-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 11 guest-start  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-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 20 leak-check/checkfail never pass

version targeted for testing:
 xen  dfddbf35d9df666fa731dcaf35afd8cf24ac8ecf
baseline version:
 xen  0fe7d6961755812503694e9a4741b5f35a09d1f7

Last test of basis99757  2016-07-28 16:16:23 Z   42 days
Testing same since   100815  2016-09-08 12:44:50 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

jobs:
 build-amd64-xend pass
 build-i386-xend  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  fail
 build-i386-rumprun   fail
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumprun-amd64   blocked 
 

Re: [Xen-devel] [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue

[Xuquan (Euler)]

On August 30, 2016 1:58 PM, Tian Kevin < kevin.t...@intel.com > wrote:
>> From: Xuquan (Euler) [mailto:xuqu...@huawei.com]
>> Sent: Friday, August 19, 2016 8:59 PM
>>
>> When Xen apicv is enabled, wall clock time is faster on Windows7-32
>> guest with high payload (with 2vCPU, captured from xentrace, in high
>> payload, the count of IPI interrupt increases rapidly between these vCPUs).
>>
>> If IPI intrrupt (vector 0xe1) and periodic timer interrupt (vector
>> 0xd1) are both pending (index of bit set in VIRR), unfortunately, the
>> IPI intrrupt is high priority than periodic timer interrupt. Xen
>> updates IPI interrupt bit set in VIRR to guest interrupt status (RVI)
>> as a high priority and apicv (Virtual-Interrupt Delivery) delivers IPI
>> interrupt within VMX non-root operation without a VM exit. Within VMX
>> non-root operation, if periodic timer interrupt index of bit is set in
>> VIRR and highest, the apicv delivers periodic timer interrupt within VMX
>non-root operation as well.
>>
>> But in current code, if Xen doesn't update periodic timer interrupt
>> bit set in VIRR to guest interrupt status (RVI) directly, Xen is not
>> aware of this case to decrease the count (pending_intr_nr) of pending
>> periodic timer interrupt, then Xen will deliver a periodic timer
>> interrupt again. The guest receives more periodic timer interrupt.
>>
>> If the periodic timer interrut is delivered and not the highest
>> priority, make Xen be aware of this case to decrease the count of
>> pending periodic timer interrupt.
>>
>> Signed-off-by: Yifei Jiang 
>> Signed-off-by: Rongguang He 
>> Signed-off-by: Quan Xu 
>> ---
>> Why RFC:
>> 1. I am not quite sure for other cases, such as nested case.
>> 2. Within VMX non-root operation, an Asynchronous Enclave Exit (including
>external
>>interrupts, non-maskable interrupt system-management interrrupts,
>exceptions
>>and VM exit) may occur before delivery of a periodic timer interrupt, the
>periodic
>>timer interrupt may be lost when a coming periodic timer interrupt is
>delivered.
>>Actually, and so current code is.
>> ---
>>  xen/arch/x86/hvm/vmx/intr.c | 16 +++-
>>  1 file changed, 15 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c
>> index 8fca08c..d3a034e 100644
>> --- a/xen/arch/x86/hvm/vmx/intr.c
>> +++ b/xen/arch/x86/hvm/vmx/intr.c
>> @@ -334,7 +334,21 @@ void vmx_intr_assist(void)
>>  __vmwrite(EOI_EXIT_BITMAP(i),
>v->arch.hvm_vmx.eoi_exit_bitmap[i]);
>>  }
>>
>> -pt_intr_post(v, intack);
>> +   /*
>> +* If the periodic timer interrut is delivered and not the highest
>priority,
>> +* make Xen be aware of this case to decrease the count of pending
>periodic
>> +* timer interrupt.
>> +*/
>> +if ( pt_vector != -1 && intack.vector > pt_vector )
>> +{
>> +struct hvm_intack pt_intack;
>> +
>> +pt_intack.vector = pt_vector;
>> +pt_intack.source = hvm_intsrc_lapic;
>> +pt_intr_post(v, pt_intack);
>> +}
>> +else
>> +pt_intr_post(v, intack);
>>  }
>
>Here is my thought. w/o above patch one pending pt interrupt may result in
>multiple injections of guest timer interrupt, as you identified, when pt_vector
>happens to be not the highest pending vector. Then w/ your patch, multiple
>pending pt interrupt instances may be combined as one injection of guest timer
>interrupt. Especially intack.vector
>>pt_vector doesn't mean pt_intr is eligible for injection, which might
>be blocked due to other reasons. As Jan pointed out, this path is very 
>fragile, so
>better we can have a fix to sustain the original behavior with one pending pt
>instance causing one actual injection.
>
>What about doing pt_intr_post in EOI-induced VM-exit instead? EOI exit bit for
>pt_intr is already set to 1 which means every injection would incur an
>EOI-induced VM-exit:
>
>   /*
>* Set eoi_exit_bitmap for periodic timer interrup to cause EOI-induced
>VM
>* exit, then pending periodic time interrups have the chance to be
>injected
>* for compensation
>*/
>if (pt_vector != -1)
>vmx_set_eoi_exit_bitmap(v, pt_vector);
>
>I don't think delaying post makes much difference here. Even we do post earlier
>like your patch, further pending instances have to wait until current instance 
>is
>completed. So as long as post happens before EOI is completed, it should be
>fine.

Kevin, I verify your suggestion with below modification. wall clock time is 
__still__ faster. I hope this modification is correct to your suggestion.

I __guess__ that the vm-entry is more frequent than PT interrupt,
Specifically, if there is a PT interrupt pending, the count (pending_intr_nr) 
is 1..

before next PT interrupt coming, each PT interrupt injection may not incur an 

[Xen-devel] [xen-4.6-testing test] 100816: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail REGR. 
vs. 100779
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail 
REGR. vs. 100779

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start  fail  like 100771
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100779
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100779
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100779
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100779

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 build-i386-rumprun5 rumprun-buildfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-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-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail 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-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   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-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 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

version targeted for testing:
 xen  26352b6344ce5d5a2ee78e56ae631e156fbdce7f
baseline version:
 xen  4627e5e5f10bf8cdebaf45b66a476c4adb104f6d

Last test of basis   100779  2016-09-07 02:17:59 Z2 days
Testing same since   100816  2016-09-08 12:44:48 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   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

[Xen-devel] [qemu-mainline baseline-only test] 67676: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67676 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67676/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-i386-pvgrub 10 guest-start   fail REGR. vs. 67672

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67672
 test-amd64-amd64-amd64-pvgrub 10 guest-start  fail  like 67672

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   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  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   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-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 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
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt 12 migrate-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-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 qemuu7faae0b36e51ffdb17d4716ddc40dcfa682d93d9
baseline version:
 qemuu2926375cffce464fde6b4dabaed1e133d549af39

Last test of basis67672  2016-09-08 06:46:58 Z0 days
Testing same since67676  2016-09-08 18:46:25 Z0 days1 attempts


People who touched revisions under test:
  Alistair Francis 
  Cédric Le Goater 
  Eric Auger 
  Marcin Krzeminski 
  Peter Maydell 
  Sergey Sorokin 
  Wei Huang 

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

[Xen-devel] [xen-4.7-testing test] 100813: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-debianhvm-amd64 13 guest-localmigrate fail REGR. vs. 
100777

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop   fail REGR. vs. 100777
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100777
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100777
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100777

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 build-i386-rumprun5 rumprun-buildfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   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-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   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-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-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 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-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   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-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail 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-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  0c9b94208f91032a06198d10a307d86a66e9f207
baseline version:
 xen  dbeb5da648b146339ec49375f2759263fe7ccdc2

Last test of basis   100777  2016-09-06 19:49:12 Z2 days
Testing same since   100813  2016-09-08 12:44:23 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass  

[Xen-devel] [xen-4.5-testing test] 100814: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-arndale  11 guest-start  fail REGR. vs. 100769
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail REGR. 
vs. 100769

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop   fail blocked in 100769
 test-amd64-amd64-xl-rtds  6 xen-boot fail  like 100769
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100769
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100769
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100769
 test-armhf-armhf-xl-rtds 11 guest-start  fail  like 100769

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 build-i386-rumprun5 rumprun-buildfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail 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-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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-xl-vhd  10 guest-start  fail   never pass
 test-armhf-armhf-libvirt-qcow2 10 guest-start  fail never pass
 test-armhf-armhf-libvirt-raw 10 guest-start  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

version targeted for testing:
 xen  433ebca120e8750eb8085745ccac703e47358e6f
baseline version:
 xen  d50078b9f2d7df55157ca353d889b13a8f3f0bc6

Last test of basis   100769  2016-09-06 13:09:38 Z2 days
Testing same since   100814  2016-09-08 12:43:18 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

jobs:
 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-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  fail
 build-i386-rumprun   fail
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass 

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf d74135cd0f8d00d2126df0b4db54938c96456db6
baseline version:
 ovmf 4ac14ceae076439dcea926bc47cda4e1d2779cae

Last test of basis67674  2016-09-08 11:48:48 Z0 days
Testing same since67675  2016-09-08 16:16:16 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Dennis Chen 
  Laszlo Ersek 

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



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

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

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


Push not applicable.


commit d74135cd0f8d00d2126df0b4db54938c96456db6
Author: Ard Biesheuvel 
Date:   Thu Sep 8 09:05:45 2016 +0100

ArmPlatformPkg: remove EFI_MEMORY_UC attribute from normal memory

On ARM systems, mapping normal memory as device memory may have unintended
side effects, given that unaligned accesses or loads and stores with special
semantics (e.g., load/store exclusive) may fault or may not work as 
expected.
Similarly, DC ZVA instructions are only supported on normal memory, not
device memory.

So remove the EFI_MEMORY_UC attribute that we set by default on system RAM.
If any region requires this attribute, it is up to the driver to set this
attribute, and to ensure that no offending operations are performed on it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 

commit f2509d6d3efbed3cf90c44ace94a331b912b0017
Author: Ard Biesheuvel 
Date:   Thu Sep 8 08:40:09 2016 +0100

ArmVirtPkg: restrict mapping attributes of normal memory to EFI_MEMORY_WB

In general, on an ARM system, mapping normal memory as device memory may
have unintended side effects, given that unaligned accesses or loads and
stores with special semantics (e.g., load/store exclusive) may fault or
may not work as expected.

Under KVM, the situation is even worse, since the host may not expect the
guest to perform uncached accesses, and so writes to such an uncached
region may get lost completely.

Since the only safe mapping type under KVM is EFI_MEMORY_WB, remove all
other memory type attributes.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 

commit 2bdf3f2ca78eae4abcaa058c0ff4f590c215dd82
Author: Ard Biesheuvel 
Date:   Mon Sep 5 11:53:57 2016 +0100

ArmPkg/ArmLib: remove all ArmLib flavors except ArmBaseLib

This removes the following ArmLib implementation, which were, apart from
the fact that they targeted either ARM or AARCH64, fully identical:

  ArmPkg/Library/ArmLib/AArch64/AArch64Lib.inf
  ArmPkg/Library/ArmLib/AArch64/AArch64LibPei.inf
  ArmPkg/Library/ArmLib/AArch64/AArch64LibPrePi.inf
  ArmPkg/Library/ArmLib/AArch64/AArch64LibSec.inf
  ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.inf
  ArmPkg/Library/ArmLib/ArmV7/ArmV7LibPrePi.inf
  ArmPkg/Library/ArmLib/ArmV7/ArmV7LibSec.inf

Only ArmBaseLib remains, which can fulfil the dependencies upon each of
the listed flavors.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 

commit 550eaa4a76fcac0c2db90e6fd6620bff497f03d8
Author: Ard Biesheuvel 
Date:   Mon Sep 5 11:48:17 2016 +0100

Re: [Xen-devel] [PATCH v3 18/19] libxl/acpi: Build ACPI tables for HVMlite guests

[Boris Ostrovsky]

On 09/08/2016 10:20 AM, Jan Beulich wrote:
>>
>>  
>>  /*
>> diff --git a/tools/libacpi/libacpi.h b/tools/libacpi/libacpi.h
>> index d803139..b0ff5aa 100644
>> --- a/tools/libacpi/libacpi.h
>> +++ b/tools/libacpi/libacpi.h
>> @@ -48,6 +48,15 @@ struct acpi_ctxt {
>>  void (*free)(struct acpi_ctxt *ctxt, void *v, uint32_t size);
>>  unsigned long (*v2p)(struct acpi_ctxt *ctxt, void *v);
>>  } mem_ops;
>> +
>> +unsigned int page_size;
>> +unsigned int page_shift;
>> +
>> +/* Memory allocator */
>> +unsigned long alloc_base_paddr;
>> +unsigned long alloc_base_vaddr;
>> +unsigned long alloc_currp;
>> +unsigned long alloc_end;
>>  };
> There not being (or getting added) any users of these in libacpi/, I
> wonder how this is related to the subject of the patch. If this is
> data that only libxl needs for its own purposes, then surely this
> shouldn't get added to struct acpi_ctxt, but should be a libxl
> private extension of that structure.

struct acpi_ctxt {
...

void *private;
};

?

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

Re: [Xen-devel] [PATCH v3 13/19] acpi: Makefile should better tolerate interrupts

[Boris Ostrovsky]

On 09/08/2016 10:15 AM, Jan Beulich wrote:
 On 07.09.16 at 20:59,  wrote:
>> Intermediate stages of building a target should be made with
>> temporary files that are copied to final target in the end.
>>
>> Signed-off-by: Boris Ostrovsky 
>> ---
>> New in v3
> Ah, here we go.
>
>> --- a/tools/libacpi/Makefile
>> +++ b/tools/libacpi/Makefile
>> @@ -21,38 +21,45 @@ MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
>>  C_SRC = $(addprefix $(ACPI_BUILD_DIR)/, dsdt_anycpu.c dsdt_15cpu.c  
>> dsdt_anycpu_qemu_xen.c dsdt_pvh.c)
>>  H_SRC = $(addprefix $(ACPI_BUILD_DIR)/, ssdt_s3.h ssdt_s4.h ssdt_pm.h 
>> ssdt_tpm.h)
>>  
>> +ifeq ($(subst all,,$(MAKECMDGOALS)),)
>> +TDIR := $(shell mktemp -d --tmpdir=$(TMPDIR) tmp_XX)
>> +endif
> How is this (or really the rules using this directory) supposed to work
> when other than "all" gets built?


I realize it's a somewhat weak argument but only 'all' and 'clean'
targets are supposed to be used. In fact I was thinking about explicitly
making a check for targets.


>
>>  vpath iasl $(PATH)
>>  all: $(C_SRC) $(H_SRC)
>> +rm -fr $(TDIR)
> And how is the temporary directory going to get cleaned up when
> interrupting make? I think you really should use a subdirectory
> underneath the build directory, which then can stay there until
> "make clean". And then you can also use mv instead of cp below,
> or even move-if-changed.

The reason I am doing this in /tmp and use tmp_X as template is
because I found that at least one old versions of iasl has a bug where
it can't process path that has a '.' in it. It drops anything after the
dot, presumably because it thinks it's file suffix.

This is true on fedora12 (2009), which is what we still use as build
environment. I know that fedora 18 doesn't have this problem but I don't
know at which point this got fixed. (Interestingly enough, I tried to
build from F12's sources for iasl and could not reproduce this. Now, i
built with new tools so perhaps the bug is not in iasl itself but in
something like yacc, which is used for the build).

I don't think we have any requirement on supported iasl version so I am
not sure we can ignore this error.

-boris




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

Re: [Xen-devel] [PATCH v6 2/2] qdisk - hw/block/xen_disk: grant copy implementation

[Stefano Stabellini]

On Thu, 8 Sep 2016, Paulina Szubarczyk wrote:
> > > @@ -582,6 +722,9 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq)
> > >   }
> > >   default:
> > >   /* unknown operation (shouldn't happen -- parse catches this) */
> > > +if (!ioreq->blkdev->feature_grant_copy) {
> > > +ioreq_unmap(ioreq);
> > > +}
> > 
> > Why are you adding this? Is it a bug fix? If so, please explain in the
> > commit message.
> > 
> It is not a bug fix. In the ioreq_runio_qemu_aio there were two error labels
> 'err_no_map' and 'err' each of them used once. So before the patch the labels
> are looking this way:
> err:
> ioreq_unmap(ioreq);
> err_no_map:
> ioreq_finish(ioreq);
> ioreq->status = BLKIF_RSP_ERROR;
> return -1;
> 
> I removed the 'err_no_map' label and from the 'err' section I removed the
> ioreq_unmap. The 'err' label was previously used in that default section of
> the switch because the grant_map is called regardless the
> ioreq->req.operation.
> 
> In the patch, there is no need for any special behavior for grant_copy,
> because buffers were not allocated in this case, so there is only jump to
> 'err'.
> 
> An advantage of this change is one unified error path for both grant
> operations.

Thanks for the explanation, it looks fine.

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

[Xen-devel] [qemu-mainline test] 100809: tolerable FAIL - PUSHED

[osstest service owner]

flight 100809 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100809/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100780
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100798
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100798

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 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-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   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  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  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-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail 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-amd64-i386-libvirt-xsm  12 migrate-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
 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-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuu7faae0b36e51ffdb17d4716ddc40dcfa682d93d9
baseline version:
 qemuu2926375cffce464fde6b4dabaed1e133d549af39

Last test of basis   100798  2016-09-07 18:48:26 Z0 days
Testing same since   100809  2016-09-08 10:13:09 Z0 days1 attempts


People who touched revisions under test:
  Alistair Francis 
  Cédric Le Goater 
  Eric Auger 
  Marcin Krzeminski 
  Peter Maydell 
  Sergey Sorokin 
  Wei Huang 

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

Re: [Xen-devel] [PATCH v3 09/19] acpi/hvmloader: Include file/paths adjustments

[Boris Ostrovsky]

On 09/08/2016 10:05 AM, Jan Beulich wrote:
>>
>> diff --git a/tools/firmware/hvmloader/acpi/libacpi.h 
>> b/tools/firmware/hvmloader/acpi/libacpi.h
>> index 3bcd226..d803139 100644
>> --- a/tools/firmware/hvmloader/acpi/libacpi.h
>> +++ b/tools/firmware/hvmloader/acpi/libacpi.h
>> @@ -84,6 +84,13 @@ struct acpi_config {
>>  
>>  /* RSDP address */
>>  unsigned int rsdp;
>> +
>> +/* x86-specific parameters */
>> +uint16_t (*lapic_id)(unsigned cpu);
> Why uint16_t? Legacy APIC IDs in MADT are in an 8-bit field, and
> x2APIC IDs require 32 bits. Depending on whether we want to be
> able to re-use the same function for x2APIC support (once that
> gets added) the return type should change accordingly. (But if we
> were to re-use it, I guess a second parameter would then also be
> needed.)

No good reason for uint16_t, should be uint8_t.

I think deciding on how interface will look for x2APIC should be
deferred until when we support it.

>
> And then - down the road you're not planning to build a shared
> library using this interface? Otherwise we'd need to consider some
> compatibility aspects.

No specific plans for now, the objects are expected to be built and
linked directly to whoever wants to use this (so libacpi is somewhat of
a misnomer, similar to libelf).


-boris


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

[Xen-devel] [PATCH] xen/x86: Fix build with clang following c/s 4fa0105

[Andrew Cooper]

https://travis-ci.org/xen-project/xen/jobs/158494027#L2344

Clang complains:

  emulate.c:2016:14: error: comparison of unsigned enum expression < 0
  is always false [-Werror,-Wtautological-compare]
  if ( seg < 0 || seg >= ARRAY_SIZE(hvmemul_ctxt->seg_reg) )
   ~~~ ^ ~

Clang is wrong to raise a warning like this.  The signed-ness of an enum is
implementation defined in C, and robust code must not assume the choices made
by the compiler.

In this case, dropping the < 0 check creates a latent bug which would result
in an array underflow when compiled with a compiler which chooses a signed
enum.

Work around the bug by explicitly pulling seg into an unsigned integer, and
only perform the upper bounds check.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Tim Deegan 
CC: George Dunlap 
---
 xen/arch/x86/hvm/emulate.c  | 19 +++
 xen/arch/x86/mm/shadow/common.c |  9 +
 2 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index e3bfda5..cc25676 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1447,13 +1447,14 @@ static int hvmemul_write_segment(
 {
 struct hvm_emulate_ctxt *hvmemul_ctxt =
 container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
+unsigned int idx = seg;
 
-if ( seg < 0 || seg >= ARRAY_SIZE(hvmemul_ctxt->seg_reg) )
+if ( idx >= ARRAY_SIZE(hvmemul_ctxt->seg_reg) )
 return X86EMUL_UNHANDLEABLE;
 
-hvmemul_ctxt->seg_reg[seg] = *reg;
-__set_bit(seg, _ctxt->seg_reg_accessed);
-__set_bit(seg, _ctxt->seg_reg_dirty);
+hvmemul_ctxt->seg_reg[idx] = *reg;
+__set_bit(idx, _ctxt->seg_reg_accessed);
+__set_bit(idx, _ctxt->seg_reg_dirty);
 
 return X86EMUL_OKAY;
 }
@@ -2012,12 +2013,14 @@ struct segment_register *hvmemul_get_seg_reg(
 enum x86_segment seg,
 struct hvm_emulate_ctxt *hvmemul_ctxt)
 {
-if ( seg < 0 || seg >= ARRAY_SIZE(hvmemul_ctxt->seg_reg) )
+unsigned int idx = seg;
+
+if ( idx >= ARRAY_SIZE(hvmemul_ctxt->seg_reg) )
 return ERR_PTR(-X86EMUL_UNHANDLEABLE);
 
-if ( !__test_and_set_bit(seg, _ctxt->seg_reg_accessed) )
-hvm_get_segment_register(current, seg, _ctxt->seg_reg[seg]);
-return _ctxt->seg_reg[seg];
+if ( !__test_and_set_bit(idx, _ctxt->seg_reg_accessed) )
+hvm_get_segment_register(current, idx, _ctxt->seg_reg[idx]);
+return _ctxt->seg_reg[idx];
 }
 
 static const char *guest_x86_mode_to_str(int mode)
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 8d6661c..21607bf 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -130,14 +130,15 @@ __initcall(shadow_audit_key_init);
 static struct segment_register *hvm_get_seg_reg(
 enum x86_segment seg, struct sh_emulate_ctxt *sh_ctxt)
 {
+unsigned int idx = seg;
 struct segment_register *seg_reg;
 
-if ( seg < 0 || seg >= ARRAY_SIZE(sh_ctxt->seg_reg) )
+if ( idx >= ARRAY_SIZE(sh_ctxt->seg_reg) )
 return ERR_PTR(-X86EMUL_UNHANDLEABLE);
 
-seg_reg = _ctxt->seg_reg[seg];
-if ( !__test_and_set_bit(seg, _ctxt->valid_seg_regs) )
-hvm_get_segment_register(current, seg, seg_reg);
+seg_reg = _ctxt->seg_reg[idx];
+if ( !__test_and_set_bit(idx, _ctxt->valid_seg_regs) )
+hvm_get_segment_register(current, idx, seg_reg);
 return seg_reg;
 }
 
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] arm/xen: fix SMP guests boot

[Stefano Stabellini]

On Thu, 8 Sep 2016, Vitaly Kuznetsov wrote:
> Commit 88e957d6e47f ("xen: introduce xen_vcpu_id mapping") broke SMP ARM
> guests on Xen. When FIFO-based event channels are in use (this is the
> default), evtchn_fifo_alloc_control_block() is called on CPU_UP_PREPARE
> event and this happens before we set up xen_vcpu_id mapping in
> xen_starting_cpu. Temporary fix the issue by setting direct Linux CPU id
> <-> Xen vCPU id mapping for all possible CPUs at boot. We don't currently
> support kexec/kdump on Xen/ARM so these ids always match.
> 
> In future, we have several ways to solve the issue, e.g.:
> - Eliminate all hypercalls from CPU_UP_PREPARE, do them from the starting
> CPU. This can probably be done for both x86 and ARM and, if done, will
> allow us to get Xen's idea of vCPU id from CPUID/MPIDR on the starting CPU
> directly, no messing with ACPI/device tree required.
> - Save vCPU id information from ACPI/device tree on ARM and use it to
> initialize xen_vcpu_id mapping. This is the same trick we currently do on
> x86.
> 
> Reported-by: Julien Grall 
> Tested-by: Wei Chen 
> Signed-off-by: Vitaly Kuznetsov 

Acked-by: Stefano Stabellini 


> It would be nice if this patch could still make it to 4.8 as all SMP
> ARM/Xen guests are currently broken.

Yes


>  arch/arm/xen/enlighten.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 3d2cef6..f193414 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -170,9 +170,6 @@ static int xen_starting_cpu(unsigned int cpu)
>   pr_info("Xen: initializing cpu%d\n", cpu);
>   vcpup = per_cpu_ptr(xen_vcpu_info, cpu);
>  
> - /* Direct vCPU id mapping for ARM guests. */
> - per_cpu(xen_vcpu_id, cpu) = cpu;
> -
>   info.mfn = virt_to_gfn(vcpup);
>   info.offset = xen_offset_in_page(vcpup);
>  
> @@ -330,6 +327,7 @@ static int __init xen_guest_init(void)
>  {
>   struct xen_add_to_physmap xatp;
>   struct shared_info *shared_info_page = NULL;
> + int cpu;
>  
>   if (!xen_domain())
>   return 0;
> @@ -380,7 +378,8 @@ static int __init xen_guest_init(void)
>   return -ENOMEM;
>  
>   /* Direct vCPU id mapping for ARM guests. */
> - per_cpu(xen_vcpu_id, 0) = 0;
> + for_each_possible_cpu(cpu)
> + per_cpu(xen_vcpu_id, cpu) = cpu;
>  
>   xen_auto_xlat_grant_frames.count = gnttab_max_grant_frames();
>   if (xen_xlate_map_ballooned_pages(_auto_xlat_grant_frames.pfn,
> -- 
> 2.7.4
> 

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

Re: [Xen-devel] [OSSTEST PATCH v3 20/25] mfi-common: create xtf build job for 4.4 onwards

[Wei Liu]

On Thu, Sep 08, 2016 at 06:41:26PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [OSSTEST PATCH v3 20/25] mfi-common: create xtf build 
> job for 4.4 onwards"):
> > The following fixup patch is required to properly filter out unnecessary
> > branches.
> 
> Right.
> 
> AFAICT the diff you present is of the results of the original v3 20/25
> plus your fixup patch ?  If so, it looks good.
> 
> > There will be one further fixup patch to another patch to switch to use
> > branch_wants_xtf_tests. I will post that separately.
> 

Yes.

> What is the deployment situation ?  See my previous emails about
> mg-branch-setup.
> 

I'm not sure I know what INITIAL-TESTED-VERSION does. Let's have a
conversation IRL and I will write down something where appropriate.

Wei.

> Ian.

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

Re: [Xen-devel] [OSSTEST PATCH v3 25/25] Create XTF branch

[Wei Liu]

On Thu, Sep 08, 2016 at 06:45:06PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [OSSTEST PATCH v3 25/25] Create XTF branch"):
> > On Thu, Sep 08, 2016 at 03:47:38PM +0100, Ian Jackson wrote:
> > > Thanks.  It's not entirely clear from your comments above whether this
> > > is a diff for the whole of your series, including 20/25 (add build
> > > jobs), or just for 25/25 (add xtf branch).
> > 
> > There would be one further fixup patch to change branch_wants_xtf_test
> > to add xtf branch to it.
> 
> Right, the fixup patch is fine.
> 
> The runvars dump shows the following jobs in the xtf branch:
> 
> > +xtfbuild-amd64-xtf[...]
> > +xtftest-xtf-amd64-amd64-1 [...]
> > +xtftest-xtf-amd64-amd64-2 [...]
> > +xtftest-xtf-amd64-amd64-3 [...]
> > +xtftest-xtf-amd64-amd64-4 [...]
> > +xtftest-xtf-amd64-amd64-5 [...]
> 
> I think it needs a hypervisor and kernel build too!  Here are the

It does have hypervisor and kernel build jobs, but they were somehow
truncated in my mail, sorry.  Here is the complete output for xtf
branch:

--- /proc/self/fd/132016-09-08 19:05:52.230115257 +0100
+++ /proc/self/fd/142016-09-08 19:05:52.230115257 +0100
+xtfbuild-amd64all_host_di_version 
current
+xtfbuild-amd64all_host_suite  
wheezy 
+xtfbuild-amd64arch
amd64  
+xtfbuild-amd64build_lvextend_max  50   
  
+xtfbuild-amd64enable_ovmf true 
  
+xtfbuild-amd64enable_xend 
false  
+xtfbuild-amd64enable_xsm  
false  
+xtfbuild-amd64host_hostflags  
share-build-wheezy-amd64,arch-amd64,suite-wheezy,purpose-build 
+xtfbuild-amd64-pvops  all_host_di_version 
current
+xtfbuild-amd64-pvops  all_host_suite  
wheezy 
+xtfbuild-amd64-pvops  arch
amd64  
+xtfbuild-amd64-pvops  build_lvextend_max  50   
  
+xtfbuild-amd64-pvops  host_hostflags  
share-build-wheezy-amd64,arch-amd64,suite-wheezy,purpose-build 
+xtfbuild-amd64-pvops  kconfighow  
xen-enable-xen-config  
+xtfbuild-amd64-pvops  revision_linux  
ap-fetch-version-baseline:linux
+xtfbuild-amd64-pvops  revision_linuxfirmware  
ap-fetch-version-baseline:linuxfirmware
+xtfbuild-amd64-pvops  tree_linuxfirmware  
git://xenbits.xen.org/osstest/linux-firmware.git   
+xtfbuild-amd64-pvops  tree_linux  
git://xenbits.xen.org/linux-pvops.git  
+xtfbuild-amd64-pvops  treevcs_linux   git  
  
+xtfbuild-amd64revision_minios  
  
+xtfbuild-amd64revision_ovmf
  
+xtfbuild-amd64revision_qemu
  
+xtfbuild-amd64revision_qemuu  
ap-fetch-version-baseline:qemu-upstream-unstable   
+xtfbuild-amd64revision_seabios 
  
+xtfbuild-amd64revision_xen
ap-fetch-version-baseline:xen-unstable 
+xtfbuild-amd64tree_minios  
   

Re: [Xen-devel] [PATCH Altp2m cleanup v4 3/4] Move altp2m specific functions to altp2m files.

[Lai, Paul C]

[Paul2] in-line

-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com] 
Sent: Thursday, September 8, 2016 8:02 AM
To: Lai, Paul C 
Cc: george.dun...@citrix.com; Sahita, Ravi ; xen-devel 

Subject: Re: [PATCH Altp2m cleanup v4 3/4] Move altp2m specific functions to 
altp2m files.

>>> On 08.09.16 at 00:04,  wrote:
> @@ -65,6 +66,56 @@ altp2m_vcpu_destroy(struct vcpu *v)
>  vcpu_unpause(v);
>  }
>  
> +int
> +altp2m_domain_init(struct domain *d)
> +{
> +int rc;
> +unsigned int i;
> +
> +if ( !hvm_altp2m_supported() )
> +{
> +rc = 0;
> +goto out;
> +}
> +/* Init alternate p2m data. */
> +if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
> +{
> +rc = -ENOMEM;
> +goto out;
> +}
> +
> +for ( i = 0; i < MAX_EPTP; i++ )
> +d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
> +
> +for ( i = 0; i < MAX_ALTP2M; i++ )
> +{
> +rc = p2m_alloc_table(d->arch.altp2m_p2m[i]);
> +if ( rc != 0 )
> +   goto out;
> +}
> +
> +d->arch.altp2m_active = 0;
> + out:
> +return rc;
> +}

I don't follow: I did specifically ask to avoid goto when where the label is 
there's just a single statement (return in this case).

[Paul2]  In the v3 2/3 patch series you said:
   
  [Jan] When the epilogue (after the target label) is just a return statement, 
please avoid using goto.

[PAUL] I don't see this code in an epilogue (after the target label).  

[Paul2] I didn't get an answer to the question.  After scratching my head, just 
realized you want the 'goto' to become a 'return'.  I will make this change in 
order to pass your review (and the coding style of Xen).  That said, I'm a 
believer in one exit per function -- to me, this is a much cleaner coding 
style.  I'm not trying to start a debate, I'm just explaining how I was 
confused.

> +void
> +altp2m_domain_teardown(struct domain *d) {
> +unsigned int i;
> +
> +if ( !hvm_altp2m_supported() )
> + return;

Bad tab indentation.

> @@ -499,27 +500,7 @@ int hap_enable(struct domain *d, u32 mode)
> goto out;
>  }
>  
> -if ( hvm_altp2m_supported() )
> -{
> -/* Init alternate p2m data */
> -if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
> -{
> -rv = -ENOMEM;
> -goto out;
> -}
> -
> -for ( i = 0; i < MAX_EPTP; i++ )
> -d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
> -
> -for ( i = 0; i < MAX_ALTP2M; i++ )
> -{
> -rv = p2m_alloc_table(d->arch.altp2m_p2m[i]);
> -if ( rv != 0 )
> -   goto out;
> -}
> -
> -d->arch.altp2m_active = 0;
> -}
> +rv = altp2m_domain_init(d);
>  
>  /* Now let other users see the new mode */
>  d->arch.paging.mode = mode | PG_HAP_enable;

I don't think you should reach the following statement(s) when your function 
returned an error. Even if this might be benign now, this is easy to overlook 
if later more code gets added near the end of the function.

Also I wonder whether in an error case there's not a possibility for memory to 
be leaked. That wouldn't be a problem your patch introduces, but I think you 
could have noticed and fixed this as you touch the code anyway.

[Paul2] Good catch

> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -1329,6 +1329,45 @@ void setup_ept_dump(void)
>  register_keyhandler('D', ept_dump_p2m_table, "dump VT-x EPT 
> tables", 0);  }
>  
> +void p2m_init_altp2m_ept( struct domain *d, unsigned int i)

Another instance of you not having corrected what was previously pointed out: 
There's a stray blank here. And even if I hadn't said there are multiple 
instances of this, you should still apply such comments to all of your series. 
And I only now notice that this e.g.
also applies to the suggested re-ordering of operations in 
altp2m_domain_teardown(). I think I'm going to stop reviewing this series here: 
Please make sure you address all review comments (either verbally or by code 
adjustment) before submitting a new version (or in extreme cases, like due to 
lack of feedback, point out open issues right after the first --- separator).

[Paul2] I did do a sweep for the stray blanks (and other like typos/style 
issues), but your eyes are much better trained.  Will do again.  

[Paul 2] Thanks for the quick feedback.

Jan


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  0831e99446121636045cf6f616a1991d6ef22071
baseline version:
 xen  b2405fed195ae7020fc876fc688b0ec85405146c

Last test of basis   100818  2016-09-08 13:03:07 Z0 days
Testing same since   100822  2016-09-08 16:02:40 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Tim Deegan 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  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 :

+ branch=xen-unstable-smoke
+ revision=0831e99446121636045cf6f616a1991d6ef22071
+ . ./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 xen-unstable-smoke 
0831e99446121636045cf6f616a1991d6ef22071
+ branch=xen-unstable-smoke
+ revision=0831e99446121636045cf6f616a1991d6ef22071
+ . ./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=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' x0831e99446121636045cf6f616a1991d6ef22071 = 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/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] [OSSTEST PATCH v3 25/25] Create XTF branch

[Ian Jackson]

Wei Liu writes ("Re: [OSSTEST PATCH v3 25/25] Create XTF branch"):
> On Thu, Sep 08, 2016 at 03:47:38PM +0100, Ian Jackson wrote:
> > Thanks.  It's not entirely clear from your comments above whether this
> > is a diff for the whole of your series, including 20/25 (add build
> > jobs), or just for 25/25 (add xtf branch).
> 
> There would be one further fixup patch to change branch_wants_xtf_test
> to add xtf branch to it.

Right, the fixup patch is fine.

The runvars dump shows the following jobs in the xtf branch:

> +xtfbuild-amd64-xtf[...]
> +xtftest-xtf-amd64-amd64-1 [...]
> +xtftest-xtf-amd64-amd64-2 [...]
> +xtftest-xtf-amd64-amd64-3 [...]
> +xtftest-xtf-amd64-amd64-4 [...]
> +xtftest-xtf-amd64-amd64-5 [...]

I think it needs a hypervisor and kernel build too!  Here are the
buildjobs it refers to:

> +xtftest-xtf-amd64-amd64-5 buildjob 
> build-amd64
> +xtftest-xtf-amd64-amd64-5 kernbuildjob 
> build-amd64-pvops  
> +xtftest-xtf-amd64-amd64-5 xenbuildjob  
> build-amd64
> +xtftest-xtf-amd64-amd64-5 xtfbuildjob  
> build-amd64-xtf

I'm kind of surprised that the build-amd64-xtf job does not need to
refer to a hypervisor build.  Perhaps XTF has its own copy of the Xen
public headers ?

thanks,
Ian.

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

Re: [Xen-devel] [OSSTEST PATCH v3 24/25] make-flight: create 5 xtf jobs

[Ian Jackson]

Wei Liu writes ("Re: [OSSTEST PATCH v3 24/25] make-flight: create 5 xtf jobs"):
> This is a fixup patch to switch from xenbranch_wants_xtf_tests to
> branch_wants_xtf_tests.

Right.  Please retain my ack.

Ian.

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

Re: [Xen-devel] [OSSTEST PATCH v3 20/25] mfi-common: create xtf build job for 4.4 onwards

[Ian Jackson]

Wei Liu writes ("Re: [OSSTEST PATCH v3 20/25] mfi-common: create xtf build job 
for 4.4 onwards"):
> The following fixup patch is required to properly filter out unnecessary
> branches.

Right.

AFAICT the diff you present is of the results of the original v3 20/25
plus your fixup patch ?  If so, it looks good.

> There will be one further fixup patch to another patch to switch to use
> branch_wants_xtf_tests. I will post that separately.

What is the deployment situation ?  See my previous emails about
mg-branch-setup.

Ian.

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

Re: [Xen-devel] [OSSTEST PATCH v3 25/25] Create XTF branch

[Wei Liu]

On Thu, Sep 08, 2016 at 03:47:38PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [OSSTEST PATCH v3 25/25] Create XTF branch"):
> > On Tue, Sep 06, 2016 at 03:03:50PM +0100, Ian Jackson wrote:
> > > Wei Liu writes ("[OSSTEST PATCH v3 25/25] Create XTF branch"):
> > > > This branch contains Xen and Linux build jobs and all jobs which contain
> > > > xtf in their name.
> > > 
> > > This looks plausible but can you please provide the output from
> > > standalone-generate-dump-flight-runvars ?
> > 
> > Here you go.
> 
> Thanks.  It's not entirely clear from your comments above whether this
> is a diff for the whole of your series, including 20/25 (add build
> jobs), or just for 25/25 (add xtf branch).

There would be one further fixup patch to change branch_wants_xtf_test
to add xtf branch to it.

From 62e90057f8c109d925d9c6be3f2681f40f081c18 Mon Sep 17 00:00:00 2001
From: Wei Liu 
Date: Thu, 8 Sep 2016 18:06:26 +0100
Subject: [OSSTEST PATCH] fixup! Create XTF branch
Cc: ian.jack...@eu.citrix.com

---
 mfi-common | 1 +
 1 file changed, 1 insertion(+)

diff --git a/mfi-common b/mfi-common
index 00921c4..1c73fee 100644
--- a/mfi-common
+++ b/mfi-common
@@ -75,6 +75,7 @@ branch_wants_xtf_tests () {
 xen-4.2-testing) return 1 ;;
 xen-4.3-testing) return 1 ;;
 xen-*) return 0;;
+xtf*) return 0;;
 *) return 1 ;;
   esac
 }
-- 
2.1.4



New stuff in DB now:

--- /proc/self/fd/112016-09-08 18:05:57.934736388 +0100
+++ /proc/self/fd/122016-09-08 18:05:57.938736285 +0100
@@ -18554,6 +18554,13 @@
 xen-4.4-testingbuild-amd64-xend  tree_qemu 
  git://xenbits.xen.org/qemu-xen-traditional.git
 
 xen-4.4-testingbuild-amd64-xend  
tree_qemuu  git://xenbits.xen.org/qemu-xen.git  
   
 xen-4.4-testingbuild-amd64-xend  tree_xen  
  git://xenbits.xen.org/xen.git 
 
+xen-4.4-testingbuild-amd64-xtf   
all_host_di_version current 
   
+xen-4.4-testingbuild-amd64-xtf   
all_host_suite  wheezy  
   
+xen-4.4-testingbuild-amd64-xtf   arch  
  amd64 
 
+xen-4.4-testingbuild-amd64-xtf   
build_lvextend_max  50  
   
+xen-4.4-testingbuild-amd64-xtf   
host_hostflags  
share-build-wheezy-amd64,arch-amd64,suite-wheezy,purpose-build 
+xen-4.4-testingbuild-amd64-xtf   
revision_xtfap-fetch-version-baseline:xtf   
   
+xen-4.4-testingbuild-amd64-xtf   tree_xtf  
  git://xenbits.xen.org/people/liuw/xtf.git 
 
 xen-4.4-testingbuild-armhf   
all_host_di_version current 
   
 xen-4.4-testingbuild-armhf   
all_host_suite  wheezy  
   
 xen-4.4-testingbuild-armhf   arch  
  armhf 
 
@@ -19377,6 +19384,61 @@
 xen-4.4-testingtest-armhf-armhf-xl-vhd   toolstack 
  xl
 
 xen-4.4-testingtest-armhf-armhf-xl-vhd   
xenbuildjob build-armhf 
   
 xen-4.4-testingtest-armhf-armhf-xl   
xenbuildjob build-armhf 
   
+xen-4.4-testingtest-xtf-amd64-amd64-1
all_host_di_version current 
   
+xen-4.4-testingtest-xtf-amd64-amd64-1
all_hostflags   
arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test,diverse-xtf-x86
+xen-4.4-testingtest-xtf-amd64-amd64-1
all_host_suite  wheezy  
   
+xen-4.4-testingtest-xtf-amd64-amd64-1arch  
  amd64 
 
+xen-4.4-testingtest-xtf-amd64-amd64-1  

Re: [Xen-devel] [OSSTEST PATCH v3 24/25] make-flight: create 5 xtf jobs

[Wei Liu]

This is a fixup patch to switch from xenbranch_wants_xtf_tests to
branch_wants_xtf_tests.


From ac5eaf4e4f10fb7da604a8bee41b1af1b27ad96f Mon Sep 17 00:00:00 2001
From: Wei Liu 
Date: Thu, 8 Sep 2016 17:54:08 +0100
Subject: [OSSTEST PATCH] fixup! make-flight: create 5 xtf jobs
Cc: ian.jack...@eu.citrix.com

---
 make-flight | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/make-flight b/make-flight
index 0aada37..7b166e1 100755
--- a/make-flight
+++ b/make-flight
@@ -423,7 +423,7 @@ do_rtds_tests () {
 }
 
 do_xtf_tests () {
-  if ! xenbranch_wants_xtf_tests; then
+  if ! branch_wants_xtf_tests; then
   return
   fi
 
-- 
2.1.4


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

Re: [Xen-devel] [OSSTEST PATCH v3 20/25] mfi-common: create xtf build job for 4.4 onwards

[Wei Liu]

On Tue, Sep 06, 2016 at 03:06:02PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[OSSTEST PATCH v3 20/25] mfi-common: create xtf build job 
> for 4.4 onwards"):
> > Xen 4.4 is the oldest one that we still provide security support at this
> > point in time.
> > 
> > Signed-off-by: Wei Liu 
> 
> This ought to come with a diff, showing the change to the output of
> standalone-generate-dump-flight-runvars.  (Consider use of `eatmydata'
> and AP_FETCH_MEMO_KEEP=1, as discussed in 74d81dca.)
> 
> Thanks,
> Ian.

The following fixup patch is required to properly filter out unnecessary
branches.

There will be one further fixup patch to another patch to switch to use
branch_wants_xtf_tests. I will post that separately.

From 074237a5b152d7f772b53594732bcc6946dc31ed Mon Sep 17 00:00:00 2001
From: Wei Liu 
Date: Thu, 8 Sep 2016 17:50:14 +0100
Subject: [OSSTEST PATCH] fixup! mfi-common: create xtf build job for 4.4
 onwards
Cc: ian.jack...@eu.citrix.com

---
 mfi-common | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/mfi-common b/mfi-common
index 0864266..00921c4 100644
--- a/mfi-common
+++ b/mfi-common
@@ -67,15 +67,16 @@ xenbranch_xsm_variants () {
 esac
 }
 
-xenbranch_wants_xtf_tests () {
-case "$xenbranch" in
-xen-3.*-testing) return 1;;
-xen-4.0-testing) return 1;;
-xen-4.1-testing) return 1;;
-xen-4.2-testing) return 1;;
-xen-4.3-testing) return 1;;
-*) return 0;;
-esac
+branch_wants_xtf_tests () {
+  case "$branch" in
+xen-3.*-testing) return 1 ;;
+xen-4.0-testing) return 1 ;;
+xen-4.1-testing) return 1 ;;
+xen-4.2-testing) return 1 ;;
+xen-4.3-testing) return 1 ;;
+xen-*) return 0;;
+*) return 1 ;;
+  esac
 }
 
 job_create_build () {
@@ -276,7 +277,7 @@ create_build_jobs () {
 
 fi
 
-if xenbranch_wants_xtf_tests; then
+if branch_wants_xtf_tests; then
 # Only x86, build once for amd64 and use the same result for
 # both amd64 and i386
 if [ x$arch = xamd64 ] ; then
-- 
2.1.4


And now the diff of new stuff in database:


--- /proc/self/fd/112016-09-08 17:59:55.664055563 +0100
+++ /proc/self/fd/122016-09-08 17:59:55.664055563 +0100
@@ -18554,6 +18554,13 @@
 xen-4.4-testingbuild-amd64-xend  tree_qemu 
  git://xenbits.xen.org/qemu-xen-traditional.git
 
 xen-4.4-testingbuild-amd64-xend  
tree_qemuu  git://xenbits.xen.org/qemu-xen.git  
   
 xen-4.4-testingbuild-amd64-xend  tree_xen  
  git://xenbits.xen.org/xen.git 
 
+xen-4.4-testingbuild-amd64-xtf   
all_host_di_version current 
   
+xen-4.4-testingbuild-amd64-xtf   
all_host_suite  wheezy  
   
+xen-4.4-testingbuild-amd64-xtf   arch  
  amd64 
 
+xen-4.4-testingbuild-amd64-xtf   
build_lvextend_max  50  
   
+xen-4.4-testingbuild-amd64-xtf   
host_hostflags  
share-build-wheezy-amd64,arch-amd64,suite-wheezy,purpose-build 
+xen-4.4-testingbuild-amd64-xtf   
revision_xtf
   
+xen-4.4-testingbuild-amd64-xtf   tree_xtf  
  git://xenbits.xen.org/people/liuw/xtf.git 
 
 xen-4.4-testingbuild-armhf   
all_host_di_version current 
   
 xen-4.4-testingbuild-armhf   
all_host_suite  wheezy  
   
 xen-4.4-testingbuild-armhf   arch  
  armhf 
 
@@ -19441,6 +19448,13 @@
 xen-4.5-testingbuild-amd64   
tree_qemuu  git://xenbits.xen.org/qemu-xen.git  
   
 xen-4.5-testingbuild-amd64   
tree_seabios
   
 xen-4.5-testingbuild-amd64   tree_xen  
  git://xenbits.xen.org/xen.git 
 

Re: [Xen-devel] [PATCH Altp2m cleanup v4 2/4] altp2m cleanup work

[Lai, Paul C]

[Paul2] in-line

-Original Message-
From: Tamas K Lengyel [mailto:tamas.k.leng...@gmail.com] 
Sent: Thursday, September 8, 2016 9:07 AM
To: Lai, Paul C 
Cc: Jan Beulich ; xen-devel 
; Sahita, Ravi ; 
george.dun...@citrix.com
Subject: Re: [Xen-devel] [PATCH Altp2m cleanup v4 2/4] altp2m cleanup work

On Thu, Sep 8, 2016 at 9:50 AM, Lai, Paul C  wrote:
> [Paul] in-line
>
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, September 8, 2016 7:47 AM
> To: Lai, Paul C 
> Cc: george.dun...@citrix.com; Sahita, Ravi ; 
> xen-devel 
> Subject: Re: [PATCH Altp2m cleanup v4 2/4] altp2m cleanup work
>
 On 08.09.16 at 00:04,  wrote:
>> Indent goto labels by one space
>> Inline (header) altp2m functions
>> Define default behavior in switch
>> Define max and min for range of altp2m macroed values
>>
>> Signed-off-by: Paul Lai 
>> ---
>
> Missing a brief summary of changes from previous version here.
>
>> @@ -5413,6 +5426,8 @@ static int do_altp2m_op(
>>  rc = p2m_change_altp2m_gfn(d, a.u.change_gfn.view,
>>  _gfn(a.u.change_gfn.old_gfn),
>>  _gfn(a.u.change_gfn.new_gfn));
>> +default:
>> +ASSERT_UNREACHABLE();
>>  }
>
> Did you test anything using HVMOP_altp2m_change_gfn with this change, on a 
> debug build? There's obviously an unintended fall- through right now.
>
> [Paul] - Yes, this patch series was tested with Tamas's 
> HVMOP_altp2m_change_gfn in a debug build.

Not sure what you used here, the xen-access tool right now in Xen doesn't (yet) 
exercise the gfn remapping, only the mem-access parts.
Sergej has a patch for this in the arm-altp2m series though.

Tamas

[Paul2] All I was testing was if xen-access behaved as before the gfn remapping 
patch was introduced.  After the gfn remapping patch was introduced, 'xen-acess 
-m 1 altp2m_write' hanged the system.  Now, with your fix, it doesn't and the 
output of xen-access appears as before.   Thanks, -Paul
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] fix EFI part of "symbols: Generate an xen-sym.map"

[Jan Beulich]

>>> On 08.09.16 at 18:21,  wrote:
> On Thu, Sep 08, 2016 at 06:45:36AM -0600, Jan Beulich wrote:
>> Commit 6ea24e53f1 introduced two problems: It left out a semicolon and
>> typo-ed the source file name of the EFI map file install command.
> 
>  I really need Fedora to start building ld with PE support.

Just build binutils yourself?

Jan


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

Re: [Xen-devel] [PATCH] fix EFI part of "symbols: Generate an xen-sym.map"

[Konrad Rzeszutek Wilk]

On Thu, Sep 08, 2016 at 06:45:36AM -0600, Jan Beulich wrote:
> Commit 6ea24e53f1 introduced two problems: It left out a semicolon and
> typo-ed the source file name of the EFI map file install command.

 I really need Fedora to start building ld with PE support.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Konrad Rzeszutek Wilk 
> 
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -67,7 +67,7 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_
>   if [ -r $(TARGET).efi -a -n '$(EFI_DIR)' ]; then \
>   [ -d $(D)$(EFI_DIR) ] || $(INSTALL_DIR) $(D)$(EFI_DIR); \
>   $(INSTALL_DATA) $(TARGET).efi 
> $(D)$(EFI_DIR)/$(T)-$(XEN_FULLVERSION).efi; \
> - $(INSTALL_DATA) $(TARGET)-efi.map 
> $(D)$(DEBUG_DIR)/$(T)-$(XEN_FULLVERSION).efi.map \
> + $(INSTALL_DATA) $(TARGET).efi.map 
> $(D)$(DEBUG_DIR)/$(T)-$(XEN_FULLVERSION).efi.map; \
>   ln -sf $(T)-$(XEN_FULLVERSION).efi 
> $(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).$(XEN_SUBVERSION).efi; \
>   ln -sf $(T)-$(XEN_FULLVERSION).efi 
> $(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).efi; \
>   ln -sf $(T)-$(XEN_FULLVERSION).efi $(D)$(EFI_DIR)/$(T).efi; \

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

Re: [Xen-devel] [PATCH Altp2m cleanup v4 2/4] altp2m cleanup work

[Tamas K Lengyel]

On Thu, Sep 8, 2016 at 9:50 AM, Lai, Paul C  wrote:
> [Paul] in-line
>
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, September 8, 2016 7:47 AM
> To: Lai, Paul C 
> Cc: george.dun...@citrix.com; Sahita, Ravi ; xen-devel 
> 
> Subject: Re: [PATCH Altp2m cleanup v4 2/4] altp2m cleanup work
>
 On 08.09.16 at 00:04,  wrote:
>> Indent goto labels by one space
>> Inline (header) altp2m functions
>> Define default behavior in switch
>> Define max and min for range of altp2m macroed values
>>
>> Signed-off-by: Paul Lai 
>> ---
>
> Missing a brief summary of changes from previous version here.
>
>> @@ -5413,6 +5426,8 @@ static int do_altp2m_op(
>>  rc = p2m_change_altp2m_gfn(d, a.u.change_gfn.view,
>>  _gfn(a.u.change_gfn.old_gfn),
>>  _gfn(a.u.change_gfn.new_gfn));
>> +default:
>> +ASSERT_UNREACHABLE();
>>  }
>
> Did you test anything using HVMOP_altp2m_change_gfn with this change, on a 
> debug build? There's obviously an unintended fall- through right now.
>
> [Paul] - Yes, this patch series was tested with Tamas's 
> HVMOP_altp2m_change_gfn in a debug build.

Not sure what you used here, the xen-access tool right now in Xen
doesn't (yet) exercise the gfn remapping, only the mem-access parts.
Sergej has a patch for this in the arm-altp2m series though.

Tamas

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 4ac14ceae076439dcea926bc47cda4e1d2779cae
baseline version:
 ovmf 960d0de80b288c7cd9cbccfde7a12a48935055b4

Last test of basis67671  2016-09-08 03:19:26 Z0 days
Testing same since67674  2016-09-08 11:48:48 Z0 days1 attempts


People who touched revisions under test:
  Jeff Fan 
  Liming Gao 

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



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

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

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


Push not applicable.

(No revision log; it would be 321 lines long.)

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

Re: [Xen-devel] [PATCH v3 1/1] xen: move TLB-flush filtering out into populate_physmap during vm creation

[Dario Faggioli]

On Thu, 2016-09-08 at 09:36 -0600, Jan Beulich wrote:
> > 
> > > 
> > > > 
> > > > On 08.09.16 at 07:30,  wrote:
> > --- a/xen/include/xen/sched.h
> > +++ b/xen/include/xen/sched.h
> > @@ -474,6 +474,9 @@ struct domain
> >  unsigned int guest_request_enabled   : 1;
> >  unsigned int guest_request_sync  : 1;
> >  } monitor;
> > +
> > +/* set to 1 the first time this domain gets scheduled. */
> > +bool_t already_scheduled;
> Did you go through and check that there is nothing this information
> can already get derived from? I can't immediately point you at
> anything, but it feels like there should. 
>
Indeed. And if there isn't and we need to do add our own flagging,
isn't there a better way and place where to put it (e.g., what Juergen
and Andrew are hinting at)?

> And if indeed there isn't,
> then - to extend on someone else's comments (I think it was Dario)
> - please use plain bool in new additions.
> 
It's Wei that commented about bool-s use in the patch. :-)

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [OSSTEST PATCH] TestSupport: use qemu-img to create vhd image

[Wei Liu]

We would like to delete blktap2 from xen.git at some point, but vhd-util
is part of blktap2. Let's switch to use qemu-img to create vhd image to
remove the dependency on blktap2 in osstest.

Note that vhd format is named "vpc" in qemu-img.

Signed-off-by: Wei Liu 
---
 Osstest/TestSupport.pm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 7eb7bc4..3da36da 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1750,7 +1750,8 @@ sub prepareguest_part_lvmdisk ($$$) {
 
 sub make_vhd ($$$) {
 my ($ho, $gho, $disk_mb) = @_;
-target_cmd_root($ho, "vhd-util create -n $gho->{Rootimg} -s $disk_mb");
+my disk_mb_s = sprintf("%dM", $disk_mb);
+target_cmd_root($ho, "qemu-img create -f vpc $gho->{Rootimg} $disk_mb_s");
 }
 sub make_qcow2 ($$$) {
 my ($ho, $gho, $disk_mb) = @_;
-- 
2.1.4


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

Re: [Xen-devel] [PATCH Altp2m cleanup v4 2/4] altp2m cleanup work

[Lai, Paul C]

[Paul] in-line

-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com] 
Sent: Thursday, September 8, 2016 7:47 AM
To: Lai, Paul C 
Cc: george.dun...@citrix.com; Sahita, Ravi ; xen-devel 

Subject: Re: [PATCH Altp2m cleanup v4 2/4] altp2m cleanup work

>>> On 08.09.16 at 00:04,  wrote:
> Indent goto labels by one space
> Inline (header) altp2m functions
> Define default behavior in switch
> Define max and min for range of altp2m macroed values
> 
> Signed-off-by: Paul Lai 
> ---

Missing a brief summary of changes from previous version here.

> @@ -5413,6 +5426,8 @@ static int do_altp2m_op(
>  rc = p2m_change_altp2m_gfn(d, a.u.change_gfn.view,
>  _gfn(a.u.change_gfn.old_gfn),
>  _gfn(a.u.change_gfn.new_gfn));
> +default:
> +ASSERT_UNREACHABLE();
>  }

Did you test anything using HVMOP_altp2m_change_gfn with this change, on a 
debug build? There's obviously an unintended fall- through right now.

[Paul] - Yes, this patch series was tested with Tamas's HVMOP_altp2m_change_gfn 
in a debug build.


>  /* emulates #VE */
> -bool_t altp2m_vcpu_emulate_ve(struct vcpu *v);
> +static inline bool_t altp2m_vcpu_emulate_ve(struct vcpu *v)

Already on v3 I had asked to switch to plain bool (and true/false as 
appropriate).

[Paul] - Maybe I misunderstood something here.  I fixed the return value to 
false in the patch.   ... Ah, it's the non-false case that's returning void.  
Will fix.

Jan


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

Re: [Xen-devel] [PATCH Altp2m cleanup v4 1/4] x86/HVM: adjust feature checking in MSR intercept handling

[Lai, Paul C]

[Paul] in-line
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com] 
Sent: Thursday, September 8, 2016 3:33 AM
To: Lai, Paul C 
Cc: george.dun...@citrix.com; Sahita, Ravi ; xen-devel 

Subject: Re: [PATCH Altp2m cleanup v4 1/4] x86/HVM: adjust feature checking in 
MSR intercept handling

>>> On 08.09.16 at 00:04,  wrote:
> From: Jan Beulich 
> 
> Consistently consult hvm_cpuid(). With that, BNDCFGS gets better 
> handled outside of VMX specific code, just like XSS. Don't needlessly 
> check for MTRR support when the MSR being accessed clearly is not an 
> MTRR one.
> 
> Signed-off-by: Jan Beulich 
> Reviewed-by: Andrew Cooper 

Why did you (re)send this? It went in yesterday together with its VMX prereq. 
Without that prereq it's useless (as it won't apply), and if you worked on a 
tree where the prereq was already present, then this one would have been 
present too (as they got pushed at the same time).

Jan

[Paul] Argh -- looks like I used the wrong commit# during the git send-email 
command  grrr...
   Apologies


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

Re: [Xen-devel] [PATCH v3 1/1] xen: move TLB-flush filtering out into populate_physmap during vm creation

[Jan Beulich]

>>> On 08.09.16 at 07:30,  wrote:
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -474,6 +474,9 @@ struct domain
>  unsigned int guest_request_enabled   : 1;
>  unsigned int guest_request_sync  : 1;
>  } monitor;
> +
> +/* set to 1 the first time this domain gets scheduled. */
> +bool_t already_scheduled;

Did you go through and check that there is nothing this information
can already get derived from? I can't immediately point you at
anything, but it feels like there should. And if indeed there isn't,
then - to extend on someone else's comments (I think it was Dario)
- please use plain bool in new additions.

Jan


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

[Xen-devel] [qemu-mainline baseline-only test] 67672: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67672 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67672/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
67642

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67642
 test-amd64-amd64-amd64-pvgrub 10 guest-start  fail  like 67642

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   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  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   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-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   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-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-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 qemuu2926375cffce464fde6b4dabaed1e133d549af39
baseline version:
 qemuue87d397e5ef66276ccc49b829527d605ca07d0ad

Last test of basis67642  2016-09-05 20:20:13 Z2 days
Testing same since67672  2016-09-08 06:46:58 Z0 days1 attempts


People who touched revisions under test:
  Christian Borntraeger 
  Cornelia Huck 
  David Hildenbrand 
  Denis V. Lunev 
  Eduardo Habkost 
  Eric Blake 
  Igor Mammedov 
  Juergen Gross 
  Kevin Wolf 
  Lluís Vilanova 
  Luwei Kang 
  Michael Mueller 
  Paul Durrant 
  Pavel Butsykin 
  Peter Maydell 
  Stefan Hajnoczi 
  Stefano Stabellini 
  Yi Min Zhao 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass 

Re: [Xen-devel] [xen-unstable test] 100789: regressions - FAIL [and 2 more messages]

[Wei Liu]

On Thu, Sep 08, 2016 at 03:23:38PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [Xen-devel] [xen-unstable test] 100789: regressions - 
> FAIL"):
> > I see three ways to move this forward.
> >
> > 3. Retire these two tests.
> 
> Do we expect users still to want VHD support ?  We still allegedly
> support VHD for guests.  So we shouldn't retire these tests unless we
> are dropping VHD support entirely.
> 
> AFAICT users who want VHD support need to be able to create images
> etc.
> 
> > 2. Install blktap-utils shipped in Debian (available from Wheezy
> >onwards), the main difficulty would be the package depends on a dkms
> >package that seems to require building with kernel header when
> >installing.
> 
> According to Debian, we (Xen) are upstream for this package.  It makes
> no sense for osstest to install something from Debian which we have
> deleted upstream !
> 
> > 1. Resurrect vhd-util from blktap2.
> 
> What is wrong with this plan ?
> 
> > In the meantime, if we want to avoid blocking xen-unstable for too long,
> > we might want to force push.
> 
> If that's a consideration, we should be considering a revert, not a
> force push.
> 
> Andrew Cooper writes ("Re: [Xen-devel] [xen-unstable test] 100789: 
> regressions - FAIL"):
> > +1 to a force push for now.  There are quite a few changes currently
> > blocked.
> 
> IMO that is not a good reason for a force push.
> 
> Wei Liu writes ("Re: [Xen-devel] [xen-unstable test] 100789: regressions - 
> FAIL"):
> > 4. Provide a pre-made vhd image.
> > 
> > vhd-util create disk.vhd -s 1 -> 24K in actual size.
> 
> This is no good because
> 
> 1. disk.vhd is a file for which we would have deleted the source code!
> 
> 2. Users need the ability to create images.
> 

It seems that we have different expectations on how things work.

I will revert that two patches now. Let's sort out the story later.

Wei.

> Ian.

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

Re: [Xen-devel] [PATCH v3 1/1] xen: move TLB-flush filtering out into populate_physmap during vm creation

[Andrew Cooper]

On 08/09/16 15:49, Dario Faggioli wrote:
> On Thu, 2016-09-08 at 13:19 +0200, Juergen Gross wrote:
>> The first scheduling is done via unpausing the domain. Why not
>> setting
>> the flag to true in that path?
>>
> That could be a good idea.
>
> And in general, I'm all for finding a place and/or a state that better
> represents the condition of "setting to run this vcpu for the first
> time" and set the flag there, rather than re-assigning 1 to an
> "already_scheduled" flag each an every time we go through schedule()
> (and not for performance and optimization reason).
>
> Which domain_unpause() (or whatever) do you have in mind precisely?

Domains are created with a single systemcontroller pause refcount, which
must be undone by the use of XEN_DOMCTL_unpausedomain when construction
is complete.

That would be the appropriate place to set such a variable.

~Andrew

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

Re: [Xen-devel] [PATCH Altp2m cleanup v4 3/4] Move altp2m specific functions to altp2m files.

[Jan Beulich]

>>> On 08.09.16 at 00:04,  wrote:
> @@ -65,6 +66,56 @@ altp2m_vcpu_destroy(struct vcpu *v)
>  vcpu_unpause(v);
>  }
>  
> +int
> +altp2m_domain_init(struct domain *d)
> +{
> +int rc;
> +unsigned int i;
> +
> +if ( !hvm_altp2m_supported() )
> +{
> +rc = 0;
> +goto out;
> +}
> +/* Init alternate p2m data. */
> +if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
> +{
> +rc = -ENOMEM;
> +goto out;
> +}
> +
> +for ( i = 0; i < MAX_EPTP; i++ )
> +d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
> +
> +for ( i = 0; i < MAX_ALTP2M; i++ )
> +{
> +rc = p2m_alloc_table(d->arch.altp2m_p2m[i]);
> +if ( rc != 0 )
> +   goto out;
> +}
> +
> +d->arch.altp2m_active = 0;
> + out:
> +return rc;
> +}

I don't follow: I did specifically ask to avoid goto when where the
label is there's just a single statement (return in this case).

> +void
> +altp2m_domain_teardown(struct domain *d)
> +{
> +unsigned int i;
> +
> +if ( !hvm_altp2m_supported() )
> + return;

Bad tab indentation.

> @@ -499,27 +500,7 @@ int hap_enable(struct domain *d, u32 mode)
> goto out;
>  }
>  
> -if ( hvm_altp2m_supported() )
> -{
> -/* Init alternate p2m data */
> -if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
> -{
> -rv = -ENOMEM;
> -goto out;
> -}
> -
> -for ( i = 0; i < MAX_EPTP; i++ )
> -d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
> -
> -for ( i = 0; i < MAX_ALTP2M; i++ )
> -{
> -rv = p2m_alloc_table(d->arch.altp2m_p2m[i]);
> -if ( rv != 0 )
> -   goto out;
> -}
> -
> -d->arch.altp2m_active = 0;
> -}
> +rv = altp2m_domain_init(d);
>  
>  /* Now let other users see the new mode */
>  d->arch.paging.mode = mode | PG_HAP_enable;

I don't think you should reach the following statement(s) when your
function returned an error. Even if this might be benign now, this is
easy to overlook if later more code gets added near the end of the
function.

Also I wonder whether in an error case there's not a possibility for
memory to be leaked. That wouldn't be a problem your patch
introduces, but I think you could have noticed and fixed this as
you touch the code anyway.

> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -1329,6 +1329,45 @@ void setup_ept_dump(void)
>  register_keyhandler('D', ept_dump_p2m_table, "dump VT-x EPT tables", 0);
>  }
>  
> +void p2m_init_altp2m_ept( struct domain *d, unsigned int i)

Another instance of you not having corrected what was previously
pointed out: There's a stray blank here. And even if I hadn't said
there are multiple instances of this, you should still apply such
comments to all of your series. And I only now notice that this e.g.
also applies to the suggested re-ordering of operations in
altp2m_domain_teardown(). I think I'm going to stop reviewing
this series here: Please make sure you address all review comments
(either verbally or by code adjustment) before submitting a new
version (or in extreme cases, like due to lack of feedback, point out
open issues right after the first --- separator).

Jan


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

Re: [Xen-devel] [PATCH v3 1/1] xen: move TLB-flush filtering out into populate_physmap during vm creation

[Dario Faggioli]

On Thu, 2016-09-08 at 13:19 +0200, Juergen Gross wrote:
> The first scheduling is done via unpausing the domain. Why not
> setting
> the flag to true in that path?
> 
That could be a good idea.

And in general, I'm all for finding a place and/or a state that better
represents the condition of "setting to run this vcpu for the first
time" and set the flag there, rather than re-assigning 1 to an
"already_scheduled" flag each an every time we go through schedule()
(and not for performance and optimization reason).

Which domain_unpause() (or whatever) do you have in mind precisely?

Thanks and Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  b2405fed195ae7020fc876fc688b0ec85405146c
baseline version:
 xen  3d20a6f4faf1c6a18b51b80d99d23daa7762dda2

Last test of basis   100800  2016-09-08 02:02:05 Z0 days
Failing since100812  2016-09-08 11:01:37 Z0 days2 attempts
Testing same since   100818  2016-09-08 13:03:07 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Tim Deegan 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  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 :

+ branch=xen-unstable-smoke
+ revision=b2405fed195ae7020fc876fc688b0ec85405146c
+ . ./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 xen-unstable-smoke 
b2405fed195ae7020fc876fc688b0ec85405146c
+ branch=xen-unstable-smoke
+ revision=b2405fed195ae7020fc876fc688b0ec85405146c
+ . ./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=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' xb2405fed195ae7020fc876fc688b0ec85405146c = 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/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
++ : 

Re: [Xen-devel] [OSSTEST PATCH v3 25/25] Create XTF branch

[Ian Jackson]

Wei Liu writes ("Re: [OSSTEST PATCH v3 25/25] Create XTF branch"):
> On Tue, Sep 06, 2016 at 03:03:50PM +0100, Ian Jackson wrote:
> > Wei Liu writes ("[OSSTEST PATCH v3 25/25] Create XTF branch"):
> > > This branch contains Xen and Linux build jobs and all jobs which contain
> > > xtf in their name.
> > 
> > This looks plausible but can you please provide the output from
> > standalone-generate-dump-flight-runvars ?
> 
> Here you go.

Thanks.  It's not entirely clear from your comments above whether this
is a diff for the whole of your series, including 20/25 (add build
jobs), or just for 25/25 (add xtf branch).

The actual diff just shows an additional xtf build job in the
xen-unstable branch, and doesn't mention the new xtf branch even
though you patched cr-for-branches.

All this suggests that you have run
`standalone-generate-dump-flight-runvars xen-unstable' to restrict the
output to that branch only.  I'd like a full diff please.  (At least,
for the series as a whole, but ideally for patch 20 and patch 25
separately.)

Also your commit messages should have a deployment note asking me to

1. Run mg-branch-setup.  You need to specify what value of
   INITIAL-TESTED-VERSION, if any, is appropriate.  If one is
   required, then that means that mg-branch-setup must be run before
   20/25 is pushed, because the change in 20/25 will start to fetch
   the baseline xtf version which is what INITIAL-TESTED-VERSION is.

2. install the new crontab to enable the new branch.

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH Altp2m cleanup v4 2/4] altp2m cleanup work

[Jan Beulich]

>>> On 08.09.16 at 00:04,  wrote:
> Indent goto labels by one space
> Inline (header) altp2m functions
> Define default behavior in switch
> Define max and min for range of altp2m macroed values
> 
> Signed-off-by: Paul Lai 
> ---

Missing a brief summary of changes from previous version here.

> @@ -5413,6 +5426,8 @@ static int do_altp2m_op(
>  rc = p2m_change_altp2m_gfn(d, a.u.change_gfn.view,
>  _gfn(a.u.change_gfn.old_gfn),
>  _gfn(a.u.change_gfn.new_gfn));
> +default:
> +ASSERT_UNREACHABLE();
>  }

Did you test anything using HVMOP_altp2m_change_gfn with this
change, on a debug build? There's obviously an unintended fall-
through right now.

>  /* emulates #VE */
> -bool_t altp2m_vcpu_emulate_ve(struct vcpu *v);
> +static inline bool_t altp2m_vcpu_emulate_ve(struct vcpu *v)

Already on v3 I had asked to switch to plain bool (and true/false as
appropriate).

Jan


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

Re: [Xen-devel] [PATCH v2] Remove ambiguities in the COPYING file; add CONTRIBUTING file

[Andrew Cooper]

On 08/09/16 15:36, Lars Kurth wrote:
>> On 16 Aug 2016, at 09:19, George Dunlap  wrote:
>>
>> On Mon, Aug 15, 2016 at 11:24 AM, Andrew Cooper
>>  wrote:
>>> On 12/08/16 10:37, Lars Kurth wrote:
 COPYING file:
 The motivation of this change is to make it easier for new
 contributors to conduct a license and patent review, WITHOUT
 changing any licenses.
 - Remove references to BSD-style licenses as we have more
  common license exceptions and replace with "other license
  stanzas"
 - List the most common situations under which code is licensed
  under licenses other than GPLv2 (section "Licensing Exceptions")
 - List the most common non-GPLv2 licenses that are in use in
  this repository based on a recent FOSSology scan (section
  "Licensing Exceptions")
 - List other license related conventions within the project
  to make it easier to conduct a license review.
 - Clarify the incoming license as its omission has confused
  past contributors (section "Contributions")

 CONTRIBUTION file:
 The motivation of this file is to make it easier for contributors
 to find contribution related resources. Add information on existing
 license related conventions to avoid unintentional future licensing
 issues. Provide templates for copyright headers for the most commonly
 used licenses in this repository.

 Signed-off-by: Lars Kurth 
>>> Reviewed-by: Andrew Cooper , with one style
>>> correction.
>>>
 diff --git a/CONTRIBUTING b/CONTRIBUTING
 new file mode 100644
 index 000..67ecdb7
 --- /dev/null
 +++ b/CONTRIBUTING
 @@ -0,0 +1,210 @@
 
 + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
 + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
 + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
 + * IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
 + * CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
 + * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
 + * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 + */
 \ No newline at end of file
>>> Newline at the end.
>> That can presumably be fixed up on check-in -- no need to resend.
>>
>> -George
> Thank you. 
>
> Otherwise: Ping? Who else needs to ACK to check this in
> Lars

Given the lack of any objections, I declare that agreement via lazy
consensus.  I reckon it is fine to go in with its current review/ack set.

~Andrew

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

Re: [Xen-devel] [PATCH 1/4] hvm/fep: Allow testing of instructions crossing the -1 -> 0 virtual boundary

[Andrew Cooper]

On 08/09/16 15:28, Jan Beulich wrote:
 On 08.09.16 at 16:11,  wrote:
>> The Force Emulation Prefix is named to follow its PV counterpart for cpuid or
>> rdtsc, but isn't really an instruction prefix.  It behaves as a break-out 
>> into
>> Xen, with the purpose of emulating the next instruction in the current state.
>>
>> It is important to be able to test legal situations which occur in real
>> hardware, including instruction which cross certain boundaries, and
>> instructions starting at 0.
>>
>> Signed-off-by: Andrew Cooper 
>> Reviewed-by: Jan Beulich 
> While you did mostly convince me at that time, I've got some more
> concerns here: What if the instruction to be emulated causes a
> fault that then needs to be propagated to and handled by the
> guest, before it can be restarted? Such a fault would be raised
> with rIP pointing past the forced emulation prefix, and hence the
> restarted instruction then wouldn't get emulated.

The current behaviour is to report a fault at the start of the real
instruction.

Furthermore, this is the useful behaviour for it to have.  If a guest is
explicitly probing the Xen x86 emulator with FEP, it can take
responsibility of rewinding %rip by 5 if it needs to replay.

Having said that, I haven't yet encountered a case where replaying a
faulting instruction in a test is useful.  All tests thusfar check that
in specific situations, faults occur architecturally whether run on real
hardware, or via the xen emulator.

> Along those line, if you don't want to treat this as an instruction
> prefix, there ought to be two #DB due to instruction breakpoint
> match (if set for both places, of course), yet that's impossible to
> implement together with the desire to emulate the insn.

True, but I don't see this is a problem.

The *only* code using FEP is test code deliberately trying to elicit
behaviour from the Xen emulator and check that it matches real
hardware.  It is perfectly fine for test code to know its special when
it is using a special backdoor to perform said tests.

~Andrew

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

[Xen-devel] Unable to build with gcc 6 because of etherboot

[Daniel E. Shub]

This is a follow on to a message I sent to xen-users:
https://lists.xen.org/archives/html/xen-devel/2015-08/msg01924.html

I am trying to compile Xen 4.7.0 with gcc 6.1.1, but I get an error
related to etherboot. It was suggested to update the etherboot
Makefile to the head of the etherboot repository. Another possibility
would be to just pull in the gcc 6 patches from upstream (e.g.,
https://git.ipxe.org/ipxe.git?a=search=refs%2Fheads%2Fmaster=commit=gcc+6).

For 4.6.0 and gcc 5 the recommendation was to just pull in the patches
(cf. https://lists.xen.org/archives/html/xen-devel/2015-08/msg01924.html)
but to update the etherboot version at some point. Is the recommended
course still to just patch as needed or has there been work to update
the etherboot version?

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

Re: [Xen-devel] [PATCH v2] Remove ambiguities in the COPYING file; add CONTRIBUTING file

[Lars Kurth]

> On 16 Aug 2016, at 09:19, George Dunlap  wrote:
> 
> On Mon, Aug 15, 2016 at 11:24 AM, Andrew Cooper
>  wrote:
>> On 12/08/16 10:37, Lars Kurth wrote:
>>> COPYING file:
>>> The motivation of this change is to make it easier for new
>>> contributors to conduct a license and patent review, WITHOUT
>>> changing any licenses.
>>> - Remove references to BSD-style licenses as we have more
>>>  common license exceptions and replace with "other license
>>>  stanzas"
>>> - List the most common situations under which code is licensed
>>>  under licenses other than GPLv2 (section "Licensing Exceptions")
>>> - List the most common non-GPLv2 licenses that are in use in
>>>  this repository based on a recent FOSSology scan (section
>>>  "Licensing Exceptions")
>>> - List other license related conventions within the project
>>>  to make it easier to conduct a license review.
>>> - Clarify the incoming license as its omission has confused
>>>  past contributors (section "Contributions")
>>> 
>>> CONTRIBUTION file:
>>> The motivation of this file is to make it easier for contributors
>>> to find contribution related resources. Add information on existing
>>> license related conventions to avoid unintentional future licensing
>>> issues. Provide templates for copyright headers for the most commonly
>>> used licenses in this repository.
>>> 
>>> Signed-off-by: Lars Kurth 
>> 
>> Reviewed-by: Andrew Cooper , with one style
>> correction.
>> 
>>> diff --git a/CONTRIBUTING b/CONTRIBUTING
>>> new file mode 100644
>>> index 000..67ecdb7
>>> --- /dev/null
>>> +++ b/CONTRIBUTING
>>> @@ -0,0 +1,210 @@
>>> 
>>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
>>> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
>>> + * IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
>>> + * CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
>>> + * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
>>> + * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
>>> + */
>>> \ No newline at end of file
>> 
>> Newline at the end.
> 
> That can presumably be fixed up on check-in -- no need to resend.
> 
> -George

Thank you. 

Otherwise: Ping? Who else needs to ACK to check this in
Lars
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 3/4] x86/hvm: Optimise segment accesses in hvmemul_write_segment()

[Jan Beulich]

>>> On 08.09.16 at 16:11,  wrote:
> There is no need to read the segment information from VMCS/VMCB and cache it,
> just to clobber the cached content immediately afterwards.
> 
> Write straight into the cache and set the accessed/dirty bits.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH 1/4] hvm/fep: Allow testing of instructions crossing the -1 -> 0 virtual boundary

[Jan Beulich]

>>> On 08.09.16 at 16:11,  wrote:
> The Force Emulation Prefix is named to follow its PV counterpart for cpuid or
> rdtsc, but isn't really an instruction prefix.  It behaves as a break-out into
> Xen, with the purpose of emulating the next instruction in the current state.
> 
> It is important to be able to test legal situations which occur in real
> hardware, including instruction which cross certain boundaries, and
> instructions starting at 0.
> 
> Signed-off-by: Andrew Cooper 
> Reviewed-by: Jan Beulich 

While you did mostly convince me at that time, I've got some more
concerns here: What if the instruction to be emulated causes a
fault that then needs to be propagated to and handled by the
guest, before it can be restarted? Such a fault would be raised
with rIP pointing past the forced emulation prefix, and hence the
restarted instruction then wouldn't get emulated.

Along those line, if you don't want to treat this as an instruction
prefix, there ought to be two #DB due to instruction breakpoint
match (if set for both places, of course), yet that's impossible to
implement together with the desire to emulate the insn.

Jan


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

Re: [Xen-devel] [PATCH v3 1/1] xen: move TLB-flush filtering out into populate_physmap during vm creation

[Ian Jackson]

Wei Liu writes ("Re: [PATCH v3 1/1] xen: move TLB-flush filtering out into 
populate_physmap during vm creation"):
> On Thu, Sep 08, 2016 at 01:01:40PM +0200, Dario Faggioli wrote:
> > On Thu, 2016-09-08 at 11:50 +0100, Wei Liu wrote:
> > > On Thu, Sep 08, 2016 at 01:30:03PM +0800, Dongli Zhang wrote:
> > > > +if ( next->domain->already_scheduled == 0 )
> > > > +next->domain->already_scheduled = 1;
> > > > +
> > > Can be simplified by omitting the "if" altogether.  
> > >
> > Are you sure? I mean looking at the cases when the flag is already true
> > (which means, during the life of a domain, basically **always** except
> > a handful of instances after creation), what costs less, a check that
> > is always false, or a write that is always updating a value with its
> > current value?
> 
> Omitting the check certain results in less instructions. And it would
> probably eliminate misses in instruction cache and branch prediction
> logic in the processor.
> 
> In the grand scheme of things, this is a rather minor optimisation, so I
> wouldn't argue strongly for this.

Are we sure we ought to be discussing this in terms of optimisation ?
I doubt it makes any significant difference either way.

But there is a difference in clarity.  I would not normally expect to
see this:

   bool x;

   ...

   if (!x)
   x = 1;

If I saw that I would wonder if the programmer was confused, or
whether I was missing something.

Looking at it without the benefit of the definition of x, it looks
more like x might be a non-boolean type.

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH 3/4] x86/hvm: Optimise segment accesses in hvmemul_write_segment()

[Paul Durrant]

> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 08 September 2016 15:12
> To: Xen-devel 
> Cc: Andrew Cooper ; Jan Beulich
> ; Paul Durrant 
> Subject: [PATCH 3/4] x86/hvm: Optimise segment accesses in
> hvmemul_write_segment()
> 
> There is no need to read the segment information from VMCS/VMCB and
> cache it, just to clobber the cached content immediately afterwards.
> 
> Write straight into the cache and set the accessed/dirty bits.
> 

Yes, the way the code is now does look somewhat silly.

> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Paul Durrant 

Reviewed-by: Paul Durrant 

> ---
>  xen/arch/x86/hvm/emulate.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
> index 0eb7a4d..e3bfda5 100644
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -1447,12 +1447,12 @@ static int hvmemul_write_segment(  {
>  struct hvm_emulate_ctxt *hvmemul_ctxt =
>  container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
> -struct segment_register *sreg = hvmemul_get_seg_reg(seg,
> hvmemul_ctxt);
> 
> -if ( IS_ERR(sreg) )
> - return -PTR_ERR(sreg);
> +if ( seg < 0 || seg >= ARRAY_SIZE(hvmemul_ctxt->seg_reg) )
> +return X86EMUL_UNHANDLEABLE;
> 
> -memcpy(sreg, reg, sizeof(struct segment_register));
> +hvmemul_ctxt->seg_reg[seg] = *reg;
> +__set_bit(seg, _ctxt->seg_reg_accessed);
>  __set_bit(seg, _ctxt->seg_reg_dirty);
> 
>  return X86EMUL_OKAY;
> --
> 2.1.4


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

Re: [Xen-devel] [PATCH v3 12/19] libacpi: Build DSDT for PVH guests

[Jan Beulich]

>>> On 07.09.16 at 20:59,  wrote:
> @@ -32,15 +32,22 @@ $(H_SRC): $(ACPI_BUILD_DIR)/%.h: %.asl iasl
>  $(MK_DSDT): mk_dsdt.c
>   $(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c
>  
> -$(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl $(MK_DSDT)
> +$(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl dsdt_acpi_info.asl 
> $(MK_DSDT)
>   awk 'NR > 1 {print s} {s=$$0}' $< > $@
> + cat dsdt_acpi_info.asl >> $@
>   $(MK_DSDT) --debug=$(debug) --dm-version qemu-xen >> $@
>  
>  # NB. awk invocation is a portable alternative to 'head -n -1'
> -$(ACPI_BUILD_DIR)/dsdt_%cpu.asl: dsdt.asl $(MK_DSDT)
> +$(ACPI_BUILD_DIR)/dsdt_%cpu.asl: dsdt.asl dsdt_acpi_info.asl $(MK_DSDT)
>   awk 'NR > 1 {print s} {s=$$0}' $< > $@
> + cat dsdt_acpi_info.asl >> $@
>   $(MK_DSDT) --debug=$(debug) --maxcpu $*  >> $@
>  
> +$(ACPI_BUILD_DIR)/dsdt_pvh.asl: dsdt_acpi_info.asl $(MK_DSDT)
> + printf "DefinitionBlock (\"DSDT.aml\", \"DSDT\", 5, \"Xen\", \"HVM\", 
> 0)\n{" > $@
> + cat dsdt_acpi_info.asl >> $@
> + $(MK_DSDT) --debug=$(debug) --maxcpu any --dm-version none >> $@

Hadn't I seen you switch to use intermediate files with all this output
redirection in v2? Did that get lost, or do I misremember?

Everything else looks fine.

Jan


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

[Xen-devel] [PATCH 4/4] x86/hvm: Perform a user instruction fetch for a FEP in userspace

[Andrew Cooper]

This matches hardware behaviour, and prevents erroneous failures when a guest
has SMEP/SMAP active and issues a FEP from userspace.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
---
 xen/arch/x86/hvm/hvm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 596a903..159671e 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3978,6 +3978,8 @@ void hvm_ud_intercept(struct cpu_user_regs *regs)
 {
 struct vcpu *cur = current;
 const struct segment_register *cs = _reg[x86_seg_cs];
+uint32_t walk = (ctxt.seg_reg[x86_seg_ss].attr.fields.dpl == 3)
+? PFEC_user_mode : 0;
 unsigned long addr;
 char sig[5]; /* ud2; .ascii "xen" */
 
@@ -3987,7 +3989,7 @@ void hvm_ud_intercept(struct cpu_user_regs *regs)
  cs->attr.fields.l) ? 64 :
 cs->attr.fields.db ? 32 : 16, ) &&
  (hvm_fetch_from_guest_virt_nofault(sig, addr, sizeof(sig),
-0) == HVMCOPY_okay) &&
+walk) == HVMCOPY_okay) &&
  (memcmp(sig, "\xf\xbxen", sizeof(sig)) == 0) )
 {
 regs->eip += sizeof(sig);
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v3 18/19] libxl/acpi: Build ACPI tables for HVMlite guests

[Jan Beulich]

>>> On 07.09.16 at 20:59,  wrote:
> Signed-off-by: Boris Ostrovsky 
> ---
> Changes in v3:
> * Some constification of call parameters
> * Format adjustments
> * New acpi_mem_free hook (a nop)
> * Changes in init_acpi_config() to deal with constified acpi_numa's
>   pointers (initialize pointers as temp variabales)
> * Add '-include acpi' directive in Makefile to make sure acpi
>   target is built before build.o dependencies are processed
>   (specifically, ssdt_*.h files need to exist)
> 
> 
>  .gitignore   |  12 ++-
>  tools/libacpi/build.c|   7 +-
>  tools/libacpi/libacpi.h  |  15 ++-
>  tools/libxl/Makefile |  18 +++-
>  tools/libxl/libxl_arch.h |   3 +
>  tools/libxl/libxl_x86.c  |  30 --
>  tools/libxl/libxl_x86_acpi.c | 218 
> +++
>  tools/libxl/libxl_x86_acpi.h |  35 +++
>  8 files changed, 318 insertions(+), 20 deletions(-)
>  create mode 100644 tools/libxl/libxl_x86_acpi.c
>  create mode 100644 tools/libxl/libxl_x86_acpi.h
> 
> diff --git a/.gitignore b/.gitignore
> index 9b2c405..9f5bd8c 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -173,15 +173,19 @@ tools/include/xen/*
>  tools/include/xen-xsm/*
>  tools/include/xen-foreign/*.(c|h|size)
>  tools/include/xen-foreign/checker
> -tools/libxl/libxlu_cfg_y.output
> +tools/libxl/_libxl.api-for-check
> +tools/libxl/*.api-ok
>  tools/libxl/*.pc
>  tools/libxl/*.pc.in
> -tools/libxl/xl
> +tools/libxl/dsdt*.c
> +tools/libxl/dsdt_*.asl
> +tools/libxl/libxlu_cfg_y.output
> +tools/libxl/mk_dsdt
> +tools/libxl/ssdt_*.h
>  tools/libxl/testenum
>  tools/libxl/testenum.c
>  tools/libxl/tmp.*
> -tools/libxl/_libxl.api-for-check
> -tools/libxl/*.api-ok
> +tools/libxl/xl
>  tools/misc/cpuperf/cpuperf-perfcntr
>  tools/misc/cpuperf/cpuperf-xen
>  tools/misc/xc_shadow
> diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c
> index 1cd640d..ee5f779 100644
> --- a/tools/libacpi/build.c
> +++ b/tools/libacpi/build.c
> @@ -20,6 +20,7 @@
>  #include "ssdt_s4.h"
>  #include "ssdt_tpm.h"
>  #include "ssdt_pm.h"
> +#include 
>  #include 
>  #include 
>  
> @@ -495,7 +496,7 @@ static int new_vm_gid(struct acpi_ctxt *ctxt,
>  return 1;
>  }
>  
> -void acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config)
> +int acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config)
>  {
>  struct acpi_info *acpi_info;
>  struct acpi_20_rsdp *rsdp;
> @@ -630,11 +631,11 @@ void acpi_build_tables(struct acpi_ctxt *ctxt, struct 
> acpi_config *config)
>  if ( !new_vm_gid(ctxt, config, acpi_info) )
>  goto oom;
>  
> -return;
> +return 0;
>  
>  oom:
>  printf("unable to build ACPI tables: out of memory\n");
> -
> +return -1;
>  }
>  
>  /*
> diff --git a/tools/libacpi/libacpi.h b/tools/libacpi/libacpi.h
> index d803139..b0ff5aa 100644
> --- a/tools/libacpi/libacpi.h
> +++ b/tools/libacpi/libacpi.h
> @@ -48,6 +48,15 @@ struct acpi_ctxt {
>  void (*free)(struct acpi_ctxt *ctxt, void *v, uint32_t size);
>  unsigned long (*v2p)(struct acpi_ctxt *ctxt, void *v);
>  } mem_ops;
> +
> +unsigned int page_size;
> +unsigned int page_shift;
> +
> +/* Memory allocator */
> +unsigned long alloc_base_paddr;
> +unsigned long alloc_base_vaddr;
> +unsigned long alloc_currp;
> +unsigned long alloc_end;
>  };

There not being (or getting added) any users of these in libacpi/, I
wonder how this is related to the subject of the patch. If this is
data that only libxl needs for its own purposes, then surely this
shouldn't get added to struct acpi_ctxt, but should be a libxl
private extension of that structure.

Jan


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

[Xen-devel] [PATCH 3/4] x86/hvm: Optimise segment accesses in hvmemul_write_segment()

[Andrew Cooper]

There is no need to read the segment information from VMCS/VMCB and cache it,
just to clobber the cached content immediately afterwards.

Write straight into the cache and set the accessed/dirty bits.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Paul Durrant 
---
 xen/arch/x86/hvm/emulate.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 0eb7a4d..e3bfda5 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1447,12 +1447,12 @@ static int hvmemul_write_segment(
 {
 struct hvm_emulate_ctxt *hvmemul_ctxt =
 container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
-struct segment_register *sreg = hvmemul_get_seg_reg(seg, hvmemul_ctxt);
 
-if ( IS_ERR(sreg) )
- return -PTR_ERR(sreg);
+if ( seg < 0 || seg >= ARRAY_SIZE(hvmemul_ctxt->seg_reg) )
+return X86EMUL_UNHANDLEABLE;
 
-memcpy(sreg, reg, sizeof(struct segment_register));
+hvmemul_ctxt->seg_reg[seg] = *reg;
+__set_bit(seg, _ctxt->seg_reg_accessed);
 __set_bit(seg, _ctxt->seg_reg_dirty);
 
 return X86EMUL_OKAY;
-- 
2.1.4


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

[Xen-devel] [PATCH 1/4] hvm/fep: Allow testing of instructions crossing the -1 -> 0 virtual boundary

[Andrew Cooper]

The Force Emulation Prefix is named to follow its PV counterpart for cpuid or
rdtsc, but isn't really an instruction prefix.  It behaves as a break-out into
Xen, with the purpose of emulating the next instruction in the current state.

It is important to be able to test legal situations which occur in real
hardware, including instruction which cross certain boundaries, and
instructions starting at 0.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
---
 xen/arch/x86/hvm/hvm.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 787f055..596a903 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3981,15 +3981,8 @@ void hvm_ud_intercept(struct cpu_user_regs *regs)
 unsigned long addr;
 char sig[5]; /* ud2; .ascii "xen" */
 
-/*
- * Note that in the call below we pass 1 more than the signature
- * size, to guard against the overall code sequence wrapping between
- * "prefix" and actual instruction. There's necessarily at least one
- * actual instruction byte required, so this won't cause failure on
- * legitimate uses.
- */
 if ( hvm_virtual_to_linear_addr(x86_seg_cs, cs, regs->eip,
-sizeof(sig) + 1, hvm_access_insn_fetch,
+sizeof(sig), hvm_access_insn_fetch,
 (hvm_long_mode_enabled(cur) &&
  cs->attr.fields.l) ? 64 :
 cs->attr.fields.db ? 32 : 16, ) &&
@@ -3999,6 +3992,11 @@ void hvm_ud_intercept(struct cpu_user_regs *regs)
 {
 regs->eip += sizeof(sig);
 regs->eflags &= ~X86_EFLAGS_RF;
+
+/* Zero the upper 32 bits of %rip if not in long mode. */
+if ( !(hvm_long_mode_enabled(cur) && cs->attr.fields.l) )
+regs->eip = regs->_eip;
+
 add_taint(TAINT_HVM_FEP);
 }
 }
-- 
2.1.4


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

[Xen-devel] [PATCH 2/4] x86/segment: Bounds check accesses to emulation ctxt->seg_reg[]

[Andrew Cooper]

HVM HAP codepaths have space for all segment registers in the seg_reg[]
cache (with x86_seg_none still risking an array overrun), while the shadow
codepaths only have space for the user segments.

Range check the input segment of *_get_seg_reg() against the size of the array
used to cache the results, to avoid overruns in the case that the callers
don't filter their input suitably.

Subsume the is_x86_user_segment(seg) checks from the shadow code, which were
an incomplete attempt at range checking, and are now superceeded.  Make
hvm_get_seg_reg() static, as it is not used outside of shadow/common.c

No functional change, but far easier to reason that no overflow is possible.

Reported-by: Andrew Cooper 
Signed-off-by: Andrew Cooper 
Acked-by: Tim Deegan 
Acked-by: Jan Beulich 
---
 xen/arch/x86/hvm/emulate.c| 16 
 xen/arch/x86/mm/shadow/common.c   | 27 ++-
 xen/arch/x86/mm/shadow/private.h  |  2 --
 xen/include/asm-x86/hvm/emulate.h |  1 +
 4 files changed, 31 insertions(+), 15 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index c55ad7b..0eb7a4d 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -535,6 +535,8 @@ static int hvmemul_virtual_to_linear(
 *reps = min_t(unsigned long, *reps, max_reps);
 
 reg = hvmemul_get_seg_reg(seg, hvmemul_ctxt);
+if ( IS_ERR(reg) )
+return -PTR_ERR(reg);
 
 if ( (hvmemul_ctxt->ctxt.regs->eflags & X86_EFLAGS_DF) && (*reps > 1) )
 {
@@ -1430,6 +1432,10 @@ static int hvmemul_read_segment(
 struct hvm_emulate_ctxt *hvmemul_ctxt =
 container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
 struct segment_register *sreg = hvmemul_get_seg_reg(seg, hvmemul_ctxt);
+
+if ( IS_ERR(sreg) )
+ return -PTR_ERR(sreg);
+
 memcpy(reg, sreg, sizeof(struct segment_register));
 return X86EMUL_OKAY;
 }
@@ -1443,6 +1449,9 @@ static int hvmemul_write_segment(
 container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
 struct segment_register *sreg = hvmemul_get_seg_reg(seg, hvmemul_ctxt);
 
+if ( IS_ERR(sreg) )
+ return -PTR_ERR(sreg);
+
 memcpy(sreg, reg, sizeof(struct segment_register));
 __set_bit(seg, _ctxt->seg_reg_dirty);
 
@@ -1995,10 +2004,17 @@ void hvm_emulate_writeback(
 }
 }
 
+/*
+ * Callers which pass a known in-range x86_segment can rely on the return
+ * pointer being valid.  Other callers must explicitly check for errors.
+ */
 struct segment_register *hvmemul_get_seg_reg(
 enum x86_segment seg,
 struct hvm_emulate_ctxt *hvmemul_ctxt)
 {
+if ( seg < 0 || seg >= ARRAY_SIZE(hvmemul_ctxt->seg_reg) )
+return ERR_PTR(-X86EMUL_UNHANDLEABLE);
+
 if ( !__test_and_set_bit(seg, _ctxt->seg_reg_accessed) )
 hvm_get_segment_register(current, seg, _ctxt->seg_reg[seg]);
 return _ctxt->seg_reg[seg];
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 7032869..8d6661c 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -123,10 +123,19 @@ __initcall(shadow_audit_key_init);
 /* x86 emulator support for the shadow code
  */
 
-struct segment_register *hvm_get_seg_reg(
+/*
+ * Callers which pass a known in-range x86_segment can rely on the return
+ * pointer being valid.  Other callers must explicitly check for errors.
+ */
+static struct segment_register *hvm_get_seg_reg(
 enum x86_segment seg, struct sh_emulate_ctxt *sh_ctxt)
 {
-struct segment_register *seg_reg = _ctxt->seg_reg[seg];
+struct segment_register *seg_reg;
+
+if ( seg < 0 || seg >= ARRAY_SIZE(sh_ctxt->seg_reg) )
+return ERR_PTR(-X86EMUL_UNHANDLEABLE);
+
+seg_reg = _ctxt->seg_reg[seg];
 if ( !__test_and_set_bit(seg, _ctxt->valid_seg_regs) )
 hvm_get_segment_register(current, seg, seg_reg);
 return seg_reg;
@@ -143,14 +152,9 @@ static int hvm_translate_linear_addr(
 const struct segment_register *reg;
 int okay;
 
-/*
- * Can arrive here with non-user segments.  However, no such cirucmstance
- * is part of a legitimate pagetable update, so fail the emulation.
- */
-if ( !is_x86_user_segment(seg) )
-return X86EMUL_UNHANDLEABLE;
-
 reg = hvm_get_seg_reg(seg, sh_ctxt);
+if ( IS_ERR(reg) )
+return -PTR_ERR(reg);
 
 okay = hvm_virtual_to_linear_addr(
 seg, reg, offset, bytes, access_type, sh_ctxt->ctxt.addr_size, paddr);
@@ -253,9 +257,6 @@ hvm_emulate_write(enum x86_segment seg,
 unsigned long addr;
 int rc;
 
-if ( !is_x86_user_segment(seg) )
-return X86EMUL_UNHANDLEABLE;
-
 /* How many emulations could we save if we unshadowed on stack writes? */
 if ( seg == x86_seg_ss )
 perfc_incr(shadow_fault_emulate_stack);
@@ -283,7 +284,7 @@ hvm_emulate_cmpxchg(enum x86_segment seg,
 unsigned long addr, old, new;
 int rc;

Re: [Xen-devel] [xen-unstable test] 100789: regressions - FAIL [and 2 more messages]

[Ian Jackson]

Wei Liu writes ("Re: [Xen-devel] [xen-unstable test] 100789: regressions - 
FAIL"):
> I see three ways to move this forward.
>
> 3. Retire these two tests.

Do we expect users still to want VHD support ?  We still allegedly
support VHD for guests.  So we shouldn't retire these tests unless we
are dropping VHD support entirely.

AFAICT users who want VHD support need to be able to create images
etc.

> 2. Install blktap-utils shipped in Debian (available from Wheezy
>onwards), the main difficulty would be the package depends on a dkms
>package that seems to require building with kernel header when
>installing.

According to Debian, we (Xen) are upstream for this package.  It makes
no sense for osstest to install something from Debian which we have
deleted upstream !

> 1. Resurrect vhd-util from blktap2.

What is wrong with this plan ?

> In the meantime, if we want to avoid blocking xen-unstable for too long,
> we might want to force push.

If that's a consideration, we should be considering a revert, not a
force push.

Andrew Cooper writes ("Re: [Xen-devel] [xen-unstable test] 100789: regressions 
- FAIL"):
> +1 to a force push for now.  There are quite a few changes currently
> blocked.

IMO that is not a good reason for a force push.

Wei Liu writes ("Re: [Xen-devel] [xen-unstable test] 100789: regressions - 
FAIL"):
> 4. Provide a pre-made vhd image.
> 
> vhd-util create disk.vhd -s 1 -> 24K in actual size.

This is no good because

1. disk.vhd is a file for which we would have deleted the source code!

2. Users need the ability to create images.

Ian.

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

Re: [Xen-devel] [PATCH v3 13/19] acpi: Makefile should better tolerate interrupts

[Jan Beulich]

>>> On 07.09.16 at 20:59,  wrote:
> Intermediate stages of building a target should be made with
> temporary files that are copied to final target in the end.
> 
> Signed-off-by: Boris Ostrovsky 
> ---
> New in v3

Ah, here we go.

> --- a/tools/libacpi/Makefile
> +++ b/tools/libacpi/Makefile
> @@ -21,38 +21,45 @@ MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
>  C_SRC = $(addprefix $(ACPI_BUILD_DIR)/, dsdt_anycpu.c dsdt_15cpu.c  
> dsdt_anycpu_qemu_xen.c dsdt_pvh.c)
>  H_SRC = $(addprefix $(ACPI_BUILD_DIR)/, ssdt_s3.h ssdt_s4.h ssdt_pm.h 
> ssdt_tpm.h)
>  
> +ifeq ($(subst all,,$(MAKECMDGOALS)),)
> +TDIR := $(shell mktemp -d --tmpdir=$(TMPDIR) tmp_XX)
> +endif

How is this (or really the rules using this directory) supposed to work
when other than "all" gets built?

>  vpath iasl $(PATH)
>  all: $(C_SRC) $(H_SRC)
> + rm -fr $(TDIR)

And how is the temporary directory going to get cleaned up when
interrupting make? I think you really should use a subdirectory
underneath the build directory, which then can stay there until
"make clean". And then you can also use mv instead of cp below,
or even move-if-changed.

Jan


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

Re: [Xen-devel] [PATCH v2] xen/pciback: support driver_override

[Boris Ostrovsky]

On 09/02/2016 08:30 AM, Juergen Gross wrote:
> Support the driver_override scheme introduced with commit 782a985d7af2
> ("PCI: Introduce new device binding path using pci_dev.driver_override")
>
> As pcistub_probe() is called for all devices (it has to check for a
> match based on the slot address rather than device type) it has to
> check for driver_override set to "pciback" itself.
>
> Signed-off-by: Juergen Gross 
> ---
> V2: removed now unused label
> ---
>  drivers/xen/xen-pciback/pci_stub.c | 16 ++--
>  1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/xen/xen-pciback/pci_stub.c 
> b/drivers/xen/xen-pciback/pci_stub.c
> index 258b7c3..85c28f7 100644
> --- a/drivers/xen/xen-pciback/pci_stub.c
> +++ b/drivers/xen/xen-pciback/pci_stub.c
> @@ -25,6 +25,8 @@
>  #include "conf_space.h"
>  #include "conf_space_quirks.h"
>  
> +#define PCISTUB_DRIVER_NAME "pciback"
> +
>  static char *pci_devs_to_hide;
>  wait_queue_head_t xen_pcibk_aer_wait_queue;
>  /*Add sem for sync AER handling and xen_pcibk remove/reconfigue ops,
> @@ -529,16 +531,18 @@ static int pcistub_probe(struct pci_dev *dev, const 
> struct pci_device_id *id)
>   "don't have a normal (0) or bridge (1) "
>   "header type!\n");
>   err = -ENODEV;
> - goto out;
>   }
>  
> + } else if (!dev->driver_override ||
> +strcmp(dev->driver_override, PCISTUB_DRIVER_NAME))
> + /* Didn't find the device */
> + err = -ENODEV;
> +
> + if (!err) {
>   dev_info(>dev, "seizing device\n");
>   err = pcistub_seize(dev);
> - } else
> - /* Didn't find the device */
> - err = -ENODEV;
> + }

Should devices with pciback override be displayed in
/sys/bus/pci/drivers/pciback/slots? If they should then they need to be
either added to pcistub_device_ids or kept on some other list.

Also, do you think checking override might better be done first, before
testing for ID match?

-boris


>  
> -out:
>   return err;
>  }
>  
> @@ -945,7 +949,7 @@ static const struct pci_error_handlers 
> xen_pcibk_error_handler = {
>  static struct pci_driver xen_pcibk_pci_driver = {
>   /* The name should be xen_pciback, but until the tools are updated
>* we will keep it as pciback. */
> - .name = "pciback",
> + .name = PCISTUB_DRIVER_NAME,
>   .id_table = pcistub_ids,
>   .probe = pcistub_probe,
>   .remove = pcistub_remove,



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

Re: [Xen-devel] [PATCH v3 09/19] acpi/hvmloader: Include file/paths adjustments

[Jan Beulich]

>>> On 07.09.16 at 20:59,  wrote:
> In prepearation to moving acpi sources into generally available
> libacpi:
> 
> 1. Pass IOAPIC/LAPIC/PCI mask values via struct acpi_config
> 2. Modify include files search paths to point to acpi directory
> 3. Macro-ise include file for build.c that defines various
>utilities used by that file. Users of libacpi will be expected
>to define this macro when compiling build.c
> 
> Signed-off-by: Boris Ostrovsky 
> ---
> Changes in v3:
> * Instead of adding x86.h pass APIC/IOAPIC info via acpi_config parameter.
> * Use <> instead of "" for include directive
> 
> 
>  tools/firmware/hvmloader/Makefile |  3 ++-
>  tools/firmware/hvmloader/acpi/README  | 16 
>  tools/firmware/hvmloader/acpi/build.c | 19 ++-
>  tools/firmware/hvmloader/acpi/libacpi.h   |  7 +++
>  tools/firmware/hvmloader/hvmloader.c  |  2 +-
>  tools/firmware/hvmloader/rombios.c|  2 +-
>  tools/firmware/hvmloader/seabios.c|  5 +++--
>  tools/firmware/hvmloader/util.c   | 15 +--
>  tools/firmware/rombios/32bit/Makefile |  2 +-
>  tools/firmware/rombios/32bit/tcgbios/Makefile |  2 +-
>  tools/firmware/rombios/32bit/util.h   |  2 +-
>  11 files changed, 52 insertions(+), 23 deletions(-)
> 
> diff --git a/tools/firmware/hvmloader/Makefile 
> b/tools/firmware/hvmloader/Makefile
> index b6c5b83..77e95f1 100644
> --- a/tools/firmware/hvmloader/Makefile
> +++ b/tools/firmware/hvmloader/Makefile
> @@ -76,7 +76,8 @@ smbios.o: CFLAGS += 
> -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
>  ACPI_PATH = acpi
>  ACPI_FILES = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
>  ACPI_OBJS = $(patsubst %.c,%.o,$(ACPI_FILES)) build.o static_tables.o
> -$(ACPI_OBJS): CFLAGS += -I$(ACPI_PATH) -I.
> +$(ACPI_OBJS): CFLAGS += -I. -DLIBACPI_STDUTILS=\"../util.h\"
> +CFLAGS += -I$(ACPI_PATH)
>  vpath build.c $(ACPI_PATH)
>  vpath static_tables.c $(ACPI_PATH)
>  OBJS += $(ACPI_OBJS)
> diff --git a/tools/firmware/hvmloader/acpi/README 
> b/tools/firmware/hvmloader/acpi/README
> index 210d5ba..2b9d6e1 100644
> --- a/tools/firmware/hvmloader/acpi/README
> +++ b/tools/firmware/hvmloader/acpi/README
> @@ -1,11 +1,19 @@
> -ACPI Table for domain firmware
> +ACPI builder for domain firmware
>  
>  
> -INSTALL
> +BUILDING ACPI
>  -
> -Simply make is OK.
> -# make 
> +Users of ACPI builder are expected to provide an include file that makes 
> available
> +the following:
> +* strncpy
> +* printf
> +* NULL
> +* test_bit
> +* offsetof
>  
> +When compiling build.c, the name of this include file should be given to
> +compiler as -DLIBACPI_STDUTILS=\"\". See 
> tools/firmware/hvmloader/Makefile
> +for an example.
>  
>  Note on DSDT Table
>  --
> diff --git a/tools/firmware/hvmloader/acpi/build.c 
> b/tools/firmware/hvmloader/acpi/build.c
> index 2098920..1cd640d 100644
> --- a/tools/firmware/hvmloader/acpi/build.c
> +++ b/tools/firmware/hvmloader/acpi/build.c
> @@ -13,15 +13,13 @@
>   * GNU Lesser General Public License for more details.
>   */
>  
> +#include LIBACPI_STDUTILS
>  #include "acpi2_0.h"
>  #include "libacpi.h"
>  #include "ssdt_s3.h"
>  #include "ssdt_s4.h"
>  #include "ssdt_tpm.h"
>  #include "ssdt_pm.h"
> -#include "../config.h"
> -#include "../util.h"
> -#include "../vnuma.h"
>  #include 
>  #include 
>  
> @@ -81,6 +79,9 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt 
> *ctxt,
>  struct hvm_info_table *hvminfo = config->hvminfo;
>  int i, sz;
>  
> +if ( config->lapic_id == NULL )
> +return NULL;
> +
>  sz  = sizeof(struct acpi_20_madt);
>  sz += sizeof(struct acpi_20_madt_intsrcovr) * 16;
>  sz += sizeof(struct acpi_20_madt_ioapic);
> @@ -97,7 +98,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt 
> *ctxt,
>  madt->header.oem_revision = ACPI_OEM_REVISION;
>  madt->header.creator_id   = ACPI_CREATOR_ID;
>  madt->header.creator_revision = ACPI_CREATOR_REVISION;
> -madt->lapic_addr = LAPIC_BASE_ADDRESS;
> +madt->lapic_addr = config->lapic_base_address;
>  madt->flags  = ACPI_PCAT_COMPAT;
>  
>  if ( config->table_flags & ACPI_HAS_IOAPIC )
> @@ -116,7 +117,7 @@ static struct acpi_20_madt *construct_madt(struct 
> acpi_ctxt *ctxt,
>  intsrcovr->gsi= 2;
>  intsrcovr->flags  = 0x0;
>  }
> -else if ( PCI_ISA_IRQ_MASK & (1U << i) )
> +else if ( config->pci_isa_irq_mask & (1U << i) )
>  {
>  /* PCI: active-low level-triggered. */
>  intsrcovr->gsi= i;
> @@ -135,8 +136,8 @@ static struct acpi_20_madt *construct_madt(struct 
> acpi_ctxt *ctxt,
>  memset(io_apic, 0, sizeof(*io_apic));
>  io_apic->type= ACPI_IO_APIC;
>  io_apic->length  = sizeof(*io_apic);
> -  

Re: [Xen-devel] [PATCH v3 08/19] acpi/hvmloader: Link ACPI object files directly

[Jan Beulich]

>>> On 07.09.16 at 20:59,  wrote:
> ACPI sources will be available to various component which will build
> them according to their own rules. ACPI's Makefile will only generate
> necessary source files.
> 
> Signed-off-by: Boris Ostrovsky 

Acked-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH 4/5] x86/emulate: add support for {, v}movq xmm, xmm/m64

[Mihai Donțu]

On Thursday 08 September 2016 07:45:19 Jan Beulich wrote:
> From: Mihai Donțu 
> 
> Signed-off-by: Mihai Donțu 
> Signed-off-by: Jan Beulich 
> ---
> v4: Re-base on decoding changes. Address my own review comments (where
> still applicable). #UD when vex.l is set. Various adjustments to
> the test tool change.

Thank you! They were in my queue for too long and I was struggling to
find a window of time to get them in shape.

> --- a/tools/tests/x86_emulator/test_x86_emulator.c
> +++ b/tools/tests/x86_emulator/test_x86_emulator.c
> @@ -713,6 +713,54 @@ int main(int argc, char **argv)
>  else
>  printf("skipped\n");
>  
> +printf("%-40s", "Testing movq %%xmm0,32(%%ecx)...");
> +if ( stack_exec && cpu_has_sse2 )
> +{
> +decl_insn(movq_to_mem2);
> +
> +asm volatile ( "pcmpgtb %%xmm0, %%xmm0\n"
> +   put_insn(movq_to_mem2, "movq %%xmm0, 32(%0)")
> +   :: "c" (NULL) );
> +
> +memset(res, 0xbd, 64);
> +set_insn(movq_to_mem2);
> +regs.ecx = (unsigned long)res;
> +regs.edx = 0;
> +rc = x86_emulate(, );
> +if ( rc != X86EMUL_OKAY || !check_eip(movq_to_mem2) ||
> + *((uint64_t *)res + 4) ||
> + memcmp(res, res + 10, 24) ||
> + memcmp(res, res + 6, 8) )
> +goto fail;
> +printf("okay\n");
> +}
> +else
> +printf("skipped\n");
> +
> +printf("%-40s", "Testing vmovq %%xmm1,32(%%edx)...");
> +if ( stack_exec && cpu_has_avx )
> +{
> +decl_insn(vmovq_to_mem);
> +
> +asm volatile ( "pcmpgtb %%xmm1, %%xmm1\n"
> +   put_insn(vmovq_to_mem, "vmovq %%xmm1, 32(%0)")
> +   :: "d" (NULL) );
> +
> +memset(res, 0xdb, 64);
> +set_insn(vmovq_to_mem);
> +regs.ecx = 0;
> +regs.edx = (unsigned long)res;
> +rc = x86_emulate(, );
> +if ( rc != X86EMUL_OKAY || !check_eip(vmovq_to_mem) ||
> + *((uint64_t *)res + 4) ||
> + memcmp(res, res + 10, 24) ||
> + memcmp(res, res + 6, 8) )
> +goto fail;
> +printf("okay\n");
> +}
> +else
> +printf("skipped\n");
> +
>  printf("%-40s", "Testing movdqu %xmm2,(%ecx)...");
>  if ( stack_exec && cpu_has_sse2 )
>  {
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -269,7 +269,7 @@ static const opcode_desc_t twobyte_table
>  ImplicitOps, ImplicitOps, ImplicitOps, ImplicitOps,
>  ImplicitOps, ImplicitOps, ImplicitOps, ImplicitOps,
>  /* 0xD0 - 0xDF */
> -ModRM, ModRM, ModRM, ModRM, ModRM, ModRM, ModRM, ModRM,
> +ModRM, ModRM, ModRM, ModRM, ModRM, ModRM, ImplicitOps|ModRM, ModRM,
>  ModRM, ModRM, ModRM, ModRM, ModRM, ModRM, ModRM, ModRM,
>  /* 0xE0 - 0xEF */
>  ModRM, ModRM, ModRM, ModRM, ModRM, ModRM, ModRM, ImplicitOps|ModRM,
> @@ -4779,6 +4779,8 @@ x86_emulate(
>  case X86EMUL_OPC_F3(0x0f, 0x7f): /* movdqu xmm,xmm/m128 */
>  case X86EMUL_OPC_VEX_F3(0x0f, 0x7f): /* vmovdqu xmm,xmm/m128 */
>   /* vmovdqu ymm,ymm/m256 */
> +case X86EMUL_OPC_66(0x0f, 0xd6): /* movq xmm,xmm/m64 */
> +case X86EMUL_OPC_VEX_66(0x0f, 0xd6): /* vmovq xmm,xmm/m64 */
>  {
>  uint8_t *buf = get_stub(stub);
>  struct fpu_insn_ctxt fic = { .insn_bytes = 5 };
> @@ -4796,7 +4798,8 @@ x86_emulate(
>  case vex_66:
>  case vex_f3:
>  host_and_vcpu_must_have(sse2);
> -buf[0] = 0x66; /* movdqa */
> +/* Converting movdqu to movdqa here: Our buffer is aligned. 
> */
> +buf[0] = 0x66;
>  get_fpu(X86EMUL_FPU_xmm, );
>  ea.bytes = 16;
>  break;
> @@ -4819,6 +4822,11 @@ x86_emulate(
>  get_fpu(X86EMUL_FPU_ymm, );
>  ea.bytes = 16 << vex.l;
>  }
> +if ( b == 0xd6 )
> +{
> +generate_exception_if(vex.l, EXC_UD, -1);
> +ea.bytes = 8;
> +}
>  if ( ea.type == OP_MEM )
>  {
>  generate_exception_if((vex.pfx == vex_66) &&
> 

-- 
Mihai DONȚU


pgpGMsA4XM4H2.pgp
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 06/19] acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops

[Jan Beulich]

>>> On 07.09.16 at 20:59,  wrote:
> Components that wish to use ACPI builder will need to provide their own
> mem_alloc() and virt_to_phys() routines. Pointers to these routines will
> be passed to the builder as memory ops.
> 
> Signed-off-by: Boris Ostrovsky 

Acked-by: Jan Beulich 

Albeit I'd prefer if ...

> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -866,10 +866,27 @@ static uint8_t battery_port_exists(void)
>  return (inb(0x88) == 0x1F);
>  }
>  
> +static unsigned long acpi_v2p(struct acpi_ctxt *ctxt, void *v)
> +{
> +return virt_to_phys(v);
> +}
> +
> +static void *acpi_mem_alloc(struct acpi_ctxt *ctxt,
> +uint32_t size, uint32_t align)
> +{
> +return mem_alloc(size, align);
> +}
> +
> +static void acpi_mem_free(struct acpi_ctxt *ctxt,
> +  void *v, uint32_t size)
> +{
> +}

... the body of this function was actually a brief comment,
clarifying why this does nothing.

Jan


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

[Xen-devel] [PATCH 4/5] x86/emulate: add support for {, v}movq xmm, xmm/m64

[Jan Beulich]

From: Mihai Donțu 

Signed-off-by: Mihai Donțu 
Signed-off-by: Jan Beulich 
---
v4: Re-base on decoding changes. Address my own review comments (where
still applicable). #UD when vex.l is set. Various adjustments to
the test tool change.

--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -713,6 +713,54 @@ int main(int argc, char **argv)
 else
 printf("skipped\n");
 
+printf("%-40s", "Testing movq %%xmm0,32(%%ecx)...");
+if ( stack_exec && cpu_has_sse2 )
+{
+decl_insn(movq_to_mem2);
+
+asm volatile ( "pcmpgtb %%xmm0, %%xmm0\n"
+   put_insn(movq_to_mem2, "movq %%xmm0, 32(%0)")
+   :: "c" (NULL) );
+
+memset(res, 0xbd, 64);
+set_insn(movq_to_mem2);
+regs.ecx = (unsigned long)res;
+regs.edx = 0;
+rc = x86_emulate(, );
+if ( rc != X86EMUL_OKAY || !check_eip(movq_to_mem2) ||
+ *((uint64_t *)res + 4) ||
+ memcmp(res, res + 10, 24) ||
+ memcmp(res, res + 6, 8) )
+goto fail;
+printf("okay\n");
+}
+else
+printf("skipped\n");
+
+printf("%-40s", "Testing vmovq %%xmm1,32(%%edx)...");
+if ( stack_exec && cpu_has_avx )
+{
+decl_insn(vmovq_to_mem);
+
+asm volatile ( "pcmpgtb %%xmm1, %%xmm1\n"
+   put_insn(vmovq_to_mem, "vmovq %%xmm1, 32(%0)")
+   :: "d" (NULL) );
+
+memset(res, 0xdb, 64);
+set_insn(vmovq_to_mem);
+regs.ecx = 0;
+regs.edx = (unsigned long)res;
+rc = x86_emulate(, );
+if ( rc != X86EMUL_OKAY || !check_eip(vmovq_to_mem) ||
+ *((uint64_t *)res + 4) ||
+ memcmp(res, res + 10, 24) ||
+ memcmp(res, res + 6, 8) )
+goto fail;
+printf("okay\n");
+}
+else
+printf("skipped\n");
+
 printf("%-40s", "Testing movdqu %xmm2,(%ecx)...");
 if ( stack_exec && cpu_has_sse2 )
 {
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -269,7 +269,7 @@ static const opcode_desc_t twobyte_table
 ImplicitOps, ImplicitOps, ImplicitOps, ImplicitOps,
 ImplicitOps, ImplicitOps, ImplicitOps, ImplicitOps,
 /* 0xD0 - 0xDF */
-ModRM, ModRM, ModRM, ModRM, ModRM, ModRM, ModRM, ModRM,
+ModRM, ModRM, ModRM, ModRM, ModRM, ModRM, ImplicitOps|ModRM, ModRM,
 ModRM, ModRM, ModRM, ModRM, ModRM, ModRM, ModRM, ModRM,
 /* 0xE0 - 0xEF */
 ModRM, ModRM, ModRM, ModRM, ModRM, ModRM, ModRM, ImplicitOps|ModRM,
@@ -4779,6 +4779,8 @@ x86_emulate(
 case X86EMUL_OPC_F3(0x0f, 0x7f): /* movdqu xmm,xmm/m128 */
 case X86EMUL_OPC_VEX_F3(0x0f, 0x7f): /* vmovdqu xmm,xmm/m128 */
  /* vmovdqu ymm,ymm/m256 */
+case X86EMUL_OPC_66(0x0f, 0xd6): /* movq xmm,xmm/m64 */
+case X86EMUL_OPC_VEX_66(0x0f, 0xd6): /* vmovq xmm,xmm/m64 */
 {
 uint8_t *buf = get_stub(stub);
 struct fpu_insn_ctxt fic = { .insn_bytes = 5 };
@@ -4796,7 +4798,8 @@ x86_emulate(
 case vex_66:
 case vex_f3:
 host_and_vcpu_must_have(sse2);
-buf[0] = 0x66; /* movdqa */
+/* Converting movdqu to movdqa here: Our buffer is aligned. */
+buf[0] = 0x66;
 get_fpu(X86EMUL_FPU_xmm, );
 ea.bytes = 16;
 break;
@@ -4819,6 +4822,11 @@ x86_emulate(
 get_fpu(X86EMUL_FPU_ymm, );
 ea.bytes = 16 << vex.l;
 }
+if ( b == 0xd6 )
+{
+generate_exception_if(vex.l, EXC_UD, -1);
+ea.bytes = 8;
+}
 if ( ea.type == OP_MEM )
 {
 generate_exception_if((vex.pfx == vex_66) &&


x86/emulate: add support for {,v}movq xmm,xmm/m64

From: Mihai Donțu 

Signed-off-by: Mihai Donțu 
Signed-off-by: Jan Beulich 
---
v4: Re-base on decoding changes. Address my own review comments (where
still applicable). #UD when vex.l is set. Various adjustments to
the test tool change.

--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -713,6 +713,54 @@ int main(int argc, char **argv)
 else
 printf("skipped\n");
 
+printf("%-40s", "Testing movq %%xmm0,32(%%ecx)...");
+if ( stack_exec && cpu_has_sse2 )
+{
+decl_insn(movq_to_mem2);
+
+asm volatile ( "pcmpgtb %%xmm0, %%xmm0\n"
+   put_insn(movq_to_mem2, "movq %%xmm0, 32(%0)")
+   :: "c" (NULL) );
+
+memset(res, 0xbd, 64);
+set_insn(movq_to_mem2);
+regs.ecx = (unsigned long)res;
+regs.edx = 0;
+rc = x86_emulate(, );
+if ( rc != X86EMUL_OKAY || 

[Xen-devel] [PATCH 5/5] x86/emulate: add support for {, v}movd {, x}mm, r/m32 and {, v}movq {, x}mm, r/m64

[Jan Beulich]

From: Zhi Wang 

Found that Windows driver was using a SSE2 instruction MOVD.

Signed-off-by: Zhi Wang 
Signed-off-by: Mihai Donțu 
Signed-off-by: Jan Beulich 
---
v4: Re-base on decoding changes. Address Andrew's and my own review
comments (where still applicable). #UD when vex.l is set. Various
adjustments to the test tool change.

--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -973,6 +973,296 @@ int main(int argc, char **argv)
 else
 printf("skipped\n");
 
+printf("%-40s", "Testing movd %%mm3,32(%%ecx)...");
+if ( stack_exec && cpu_has_mmx )
+{
+decl_insn(movd_to_mem);
+
+asm volatile ( "pcmpeqb %%mm3, %%mm3\n"
+   put_insn(movd_to_mem, "movd %%mm3, 32(%0)")
+   :: "c" (NULL) );
+
+memset(res, 0xbd, 64);
+set_insn(movd_to_mem);
+regs.ecx = (unsigned long)res;
+regs.edx = 0;
+rc = x86_emulate(, );
+if ( rc != X86EMUL_OKAY || !check_eip(movd_to_mem) ||
+ res[8] + 1 ||
+ memcmp(res, res + 9, 28) ||
+ memcmp(res, res + 6, 8) )
+goto fail;
+printf("okay\n");
+}
+else
+printf("skipped\n");
+
+printf("%-40s", "Testing movd %%xmm2,32(%%edx)...");
+if ( stack_exec && cpu_has_sse2 )
+{
+decl_insn(movd_to_mem2);
+
+asm volatile ( "pcmpeqb %%xmm2, %%xmm2\n"
+   put_insn(movd_to_mem2, "movd %%xmm2, 32(%0)")
+   :: "d" (NULL) );
+
+memset(res, 0xdb, 64);
+set_insn(movd_to_mem2);
+regs.ecx = 0;
+regs.edx = (unsigned long)res;
+rc = x86_emulate(, );
+if ( rc != X86EMUL_OKAY || !check_eip(movd_to_mem2) ||
+ res[8] + 1 ||
+ memcmp(res, res + 9, 28) ||
+ memcmp(res, res + 6, 8) )
+goto fail;
+printf("okay\n");
+}
+else
+printf("skipped\n");
+
+printf("%-40s", "Testing vmovd %%xmm1,32(%%ecx)...");
+if ( stack_exec && cpu_has_avx )
+{
+decl_insn(vmovd_to_mem);
+
+asm volatile ( "pcmpeqb %%xmm1, %%xmm1\n"
+   put_insn(vmovd_to_mem, "vmovd %%xmm1, 32(%0)")
+   :: "c" (NULL) );
+
+memset(res, 0xbd, 64);
+set_insn(vmovd_to_mem);
+regs.ecx = (unsigned long)res;
+regs.edx = 0;
+rc = x86_emulate(, );
+if ( rc != X86EMUL_OKAY || !check_eip(vmovd_to_mem) ||
+ res[8] + 1 ||
+ memcmp(res, res + 9, 28) ||
+ memcmp(res, res + 6, 8) )
+goto fail;
+printf("okay\n");
+}
+else
+printf("skipped\n");
+
+printf("%-40s", "Testing movd %%mm3,%%ebx...");
+if ( stack_exec && cpu_has_mmx )
+{
+decl_insn(movd_to_reg);
+
+/*
+ * Intentionally not specifying "b" as an input (or even output) here
+ * to not keep the compiler from using the variable, which in turn
+ * allows noticing whether the emulator touches the actual register
+ * instead of the regs field.
+ */
+asm volatile ( "pcmpeqb %%mm3, %%mm3\n"
+   put_insn(movd_to_reg, "movd %%mm3, %%ebx")
+   :: );
+
+set_insn(movd_to_reg);
+#ifdef __x86_64__
+regs.rbx = 0xbdbdbdbdbdbdbdbdUL;
+#else
+regs.ebx = 0xbdbdbdbdUL;
+#endif
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) || !check_eip(movd_to_reg) ||
+ regs.ebx != 0x )
+goto fail;
+printf("okay\n");
+}
+else
+printf("skipped\n");
+
+printf("%-40s", "Testing movd %%xmm2,%%ebx...");
+if ( stack_exec && cpu_has_sse2 )
+{
+decl_insn(movd_to_reg2);
+
+/* See comment next to movd above. */
+asm volatile ( "pcmpeqb %%xmm2, %%xmm2\n"
+   put_insn(movd_to_reg2, "movd %%xmm2, %%ebx")
+   :: );
+
+set_insn(movd_to_reg2);
+#ifdef __x86_64__
+regs.rbx = 0xbdbdbdbdbdbdbdbdUL;
+#else
+regs.ebx = 0xbdbdbdbdUL;
+#endif
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) || !check_eip(movd_to_reg2) ||
+ regs.ebx != 0x )
+goto fail;
+printf("okay\n");
+}
+else
+printf("skipped\n");
+
+printf("%-40s", "Testing vmovd %%xmm1,%%ebx...");
+if ( stack_exec && cpu_has_avx )
+{
+decl_insn(vmovd_to_reg);
+
+/* See comment next to movd above. */
+asm volatile ( "pcmpeqb %%xmm1, %%xmm1\n"
+   put_insn(vmovd_to_reg, "vmovd %%xmm1, %%ebx")
+   :: );
+
+set_insn(vmovd_to_reg);
+#ifdef __x86_64__
+regs.rbx = 0xbdbdbdbdbdbdbdbdUL;
+#else
+regs.ebx = 0xbdbdbdbdUL;
+#endif
+rc = 

[Xen-devel] [PATCH 3/5] x86emul: support RTM instructions

[Jan Beulich]

Minimal emulation: XBEGIN aborts right away, hence
- XABORT is just a no-op,
- XEND always raises #GP,
- XTEST always signals neither RTM nor HLE are active.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1172,6 +1172,8 @@ static bool_t vcpu_has(
 #define vcpu_has_clflush() vcpu_has(   1, EDX, 19, ctxt, ops)
 #define vcpu_has_lzcnt() vcpu_has(0x8001, ECX,  5, ctxt, ops)
 #define vcpu_has_bmi1()  vcpu_has(0x0007, EBX,  3, ctxt, ops)
+#define vcpu_has_hle()   vcpu_has(0x0007, EBX,  4, ctxt, ops)
+#define vcpu_has_rtm()   vcpu_has(0x0007, EBX, 11, ctxt, ops)
 
 #define vcpu_must_have(leaf, reg, bit) \
 generate_exception_if(!vcpu_has(leaf, reg, bit, ctxt, ops), EXC_UD, -1)
@@ -2852,7 +2854,18 @@ x86_emulate(
 lock_prefix = 1;
 break;
 
-case 0xc6 ... 0xc7: /* mov (sole member of Grp11) */
+case 0xc6: /* Grp11: mov / xabort */
+case 0xc7: /* Grp11: mov / xbegin */
+if ( modrm == 0xf8 && vcpu_has_rtm() )
+{
+if ( b & 1 )
+{
+jmp_rel((int32_t)src.val);
+_regs.eax = 0;
+}
+dst.type = OP_NONE;
+break;
+}
 generate_exception_if((modrm_reg & 7) != 0, EXC_UD, -1);
 case 0x88 ... 0x8b: /* mov */
 case 0xa0 ... 0xa1: /* mov mem.offs,{%al,%ax,%eax,%rax} */
@@ -4246,6 +4259,17 @@ x86_emulate(
 goto done;
 goto no_writeback;
 
+case 0xd5: /* xend */
+generate_exception_if(vcpu_has_rtm() && !vex.pfx, EXC_GP, 0);
+break;
+
+case 0xd6: /* xtest */
+if ( (!vcpu_has_rtm() && !vcpu_has_hle()) || vex.pfx )
+break;
+/* Neither HLE nor RTM can be active when we get here. */
+_regs.eflags |= EFLG_ZF;
+goto no_writeback;
+
 case 0xdf: /* invlpga */
 generate_exception_if(!in_protmode(ctxt, ops), EXC_UD, -1);
 generate_exception_if(!mode_ring0(), EXC_GP, 0);



x86emul: support RTM instructions

Minimal emulation: XBEGIN aborts right away, hence
- XABORT is just a no-op,
- XEND always raises #GP,
- XTEST always signals neither RTM nor HLE are active.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1172,6 +1172,8 @@ static bool_t vcpu_has(
 #define vcpu_has_clflush() vcpu_has(   1, EDX, 19, ctxt, ops)
 #define vcpu_has_lzcnt() vcpu_has(0x8001, ECX,  5, ctxt, ops)
 #define vcpu_has_bmi1()  vcpu_has(0x0007, EBX,  3, ctxt, ops)
+#define vcpu_has_hle()   vcpu_has(0x0007, EBX,  4, ctxt, ops)
+#define vcpu_has_rtm()   vcpu_has(0x0007, EBX, 11, ctxt, ops)
 
 #define vcpu_must_have(leaf, reg, bit) \
 generate_exception_if(!vcpu_has(leaf, reg, bit, ctxt, ops), EXC_UD, -1)
@@ -2852,7 +2854,18 @@ x86_emulate(
 lock_prefix = 1;
 break;
 
-case 0xc6 ... 0xc7: /* mov (sole member of Grp11) */
+case 0xc6: /* Grp11: mov / xabort */
+case 0xc7: /* Grp11: mov / xbegin */
+if ( modrm == 0xf8 && vcpu_has_rtm() )
+{
+if ( b & 1 )
+{
+jmp_rel((int32_t)src.val);
+_regs.eax = 0;
+}
+dst.type = OP_NONE;
+break;
+}
 generate_exception_if((modrm_reg & 7) != 0, EXC_UD, -1);
 case 0x88 ... 0x8b: /* mov */
 case 0xa0 ... 0xa1: /* mov mem.offs,{%al,%ax,%eax,%rax} */
@@ -4246,6 +4259,17 @@ x86_emulate(
 goto done;
 goto no_writeback;
 
+case 0xd5: /* xend */
+generate_exception_if(vcpu_has_rtm() && !vex.pfx, EXC_GP, 0);
+break;
+
+case 0xd6: /* xtest */
+if ( (!vcpu_has_rtm() && !vcpu_has_hle()) || vex.pfx )
+break;
+/* Neither HLE nor RTM can be active when we get here. */
+_regs.eflags |= EFLG_ZF;
+goto no_writeback;
+
 case 0xdf: /* invlpga */
 generate_exception_if(!in_protmode(ctxt, ops), EXC_UD, -1);
 generate_exception_if(!mode_ring0(), EXC_GP, 0);
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 1/5] x86emul: support UMIP

[Jan Beulich]

To make this complete, also add support for SLDT and STR. Note that by
just looking at the guest CR4 bit, this is independent of actually
making available the UMIP feature to guests.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -182,7 +182,7 @@ static const opcode_desc_t opcode_table[
 
 static const opcode_desc_t twobyte_table[256] = {
 /* 0x00 - 0x07 */
-SrcMem16|ModRM, ImplicitOps|ModRM, ModRM, ModRM,
+ModRM, ImplicitOps|ModRM, ModRM, ModRM,
 0, ImplicitOps, ImplicitOps, ImplicitOps,
 /* 0x08 - 0x0F */
 ImplicitOps, ImplicitOps, 0, ImplicitOps,
@@ -421,6 +421,7 @@ typedef union {
 /* Control register flags. */
 #define CR0_PE(1<<0)
 #define CR4_TSD   (1<<2)
+#define CR4_UMIP  (1<<11)
 
 /* EFLAGS bit definitions. */
 #define EFLG_VIP  (1<<20)
@@ -1484,6 +1485,17 @@ static bool is_aligned(enum x86_segment
 return !((reg.base + offs) & (size - 1));
 }
 
+static bool is_umip(struct x86_emulate_ctxt *ctxt,
+const struct x86_emulate_ops *ops)
+{
+unsigned long cr4;
+
+/* Intentionally not using mode_ring0() here to avoid its fail_if(). */
+return get_cpl(ctxt, ops) > 0 &&
+   ops->read_cr && ops->read_cr(4, , ctxt) == X86EMUL_OKAY &&
+   (cr4 & CR4_UMIP);
+}
+
 /* Inject a software interrupt/exception, emulating if needed. */
 static int inject_swint(enum x86_swint_type type,
 uint8_t vector, uint8_t insn_len,
@@ -2051,10 +2063,20 @@ x86_decode(
 break;
 
 case ext_0f:
-case ext_0f3a:
-case ext_8f08:
-case ext_8f09:
-case ext_8f0a:
+switch ( b )
+{
+case 0x00: /* Grp6 */
+switch ( modrm_reg & 6 )
+{
+case 0:
+d |= DstMem | SrcImplicit | Mov;
+break;
+case 2: case 4:
+d |= SrcMem16;
+break;
+}
+break;
+}
 break;
 
 case ext_0f38:
@@ -2070,6 +2092,12 @@ x86_decode(
 }
 break;
 
+case ext_0f3a:
+case ext_8f08:
+case ext_8f09:
+case ext_8f0a:
+break;
+
 default:
 ASSERT_UNREACHABLE();
 }
@@ -4177,14 +4205,31 @@ x86_emulate(
 }
 break;
 
-case X86EMUL_OPC(0x0f, 0x00): /* Grp6 */
-fail_if((modrm_reg & 6) != 2);
+case X86EMUL_OPC(0x0f, 0x00): /* Grp6 */ {
+enum x86_segment seg = (modrm_reg & 1) ? x86_seg_tr : x86_seg_ldtr;
+
+fail_if(modrm_reg & 4);
 generate_exception_if(!in_protmode(ctxt, ops), EXC_UD, -1);
-generate_exception_if(!mode_ring0(), EXC_GP, 0);
-if ( (rc = load_seg((modrm_reg & 1) ? x86_seg_tr : x86_seg_ldtr,
-src.val, 0, NULL, ctxt, ops)) != 0 )
-goto done;
+if ( modrm_reg & 2 )
+{
+generate_exception_if(!mode_ring0(), EXC_GP, 0);
+if ( (rc = load_seg(seg, src.val, 0, NULL, ctxt, ops)) != 0 )
+goto done;
+}
+else
+{
+struct segment_register reg;
+
+generate_exception_if(is_umip(ctxt, ops), EXC_GP, 0);
+fail_if(!ops->read_segment);
+if ( (rc = ops->read_segment(seg, , ctxt)) != 0 )
+goto done;
+dst.val = reg.sel;
+if ( dst.type == OP_MEM )
+dst.bytes = 2;
+}
 break;
+}
 
 case X86EMUL_OPC(0x0f, 0x01): /* Grp7 */ {
 struct segment_register reg;
@@ -4282,6 +4327,7 @@ x86_emulate(
 case 0: /* sgdt */
 case 1: /* sidt */
 generate_exception_if(ea.type != OP_MEM, EXC_UD, -1);
+generate_exception_if(is_umip(ctxt, ops), EXC_GP, 0);
 fail_if(ops->read_segment == NULL);
 if ( (rc = ops->read_segment((modrm_reg & 1) ?
  x86_seg_idtr : x86_seg_gdtr,
@@ -4316,6 +4362,7 @@ x86_emulate(
 goto done;
 break;
 case 4: /* smsw */
+generate_exception_if(is_umip(ctxt, ops), EXC_GP, 0);
 ea.bytes = (ea.type == OP_MEM) ? 2 : op_bytes;
 dst = ea;
 fail_if(ops->read_cr == NULL);


x86emul: support UMIP

To make this complete, also add support for SLDT and STR. Note that by
just looking at the guest CR4 bit, this is independent of actually
making available the UMIP feature to guests.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -182,7 +182,7 @@ static const opcode_desc_t opcode_table[
 
 static const opcode_desc_t twobyte_table[256] = {
 /* 0x00 - 0x07 */
-SrcMem16|ModRM, ImplicitOps|ModRM, ModRM, ModRM,
+ModRM, ImplicitOps|ModRM, 

[Xen-devel] [PATCH 2/5] x86emul: consolidate segment register handling

[Jan Beulich]

Use a single set of variables throughout the huge switch() statement,
allowing to funnel SLDT/STR into the mov-from-sreg code path.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -2494,7 +2494,8 @@ x86_emulate(
 
 switch ( ctxt->opcode )
 {
-struct segment_register cs;
+enum x86_segment seg;
+struct segment_register cs, sreg;
 
 case 0x00 ... 0x05: add: /* add */
 emulate_2op_SrcV("add", src, dst, _regs.eflags);
@@ -2530,22 +2531,20 @@ x86_emulate(
 dst.type = OP_NONE;
 break;
 
-case 0x06: /* push %%es */ {
-struct segment_register reg;
+case 0x06: /* push %%es */
 src.val = x86_seg_es;
 push_seg:
 generate_exception_if(mode_64bit() && !ext, EXC_UD, -1);
 fail_if(ops->read_segment == NULL);
-if ( (rc = ops->read_segment(src.val, , ctxt)) != 0 )
+if ( (rc = ops->read_segment(src.val, , ctxt)) != 0 )
 goto done;
 /* 64-bit mode: PUSH defaults to a 64-bit operand. */
 if ( mode_64bit() && (op_bytes == 4) )
 op_bytes = 8;
 if ( (rc = ops->write(x86_seg_ss, sp_pre_dec(op_bytes),
-  , op_bytes, ctxt)) != 0 )
+  , op_bytes, ctxt)) != 0 )
 goto done;
 break;
-}
 
 case 0x07: /* pop %%es */
 src.val = x86_seg_es;
@@ -2861,21 +2860,20 @@ x86_emulate(
 dst.val = src.val;
 break;
 
-case 0x8c: /* mov Sreg,r/m */ {
-struct segment_register reg;
-enum x86_segment seg = decode_segment(modrm_reg);
+case 0x8c: /* mov Sreg,r/m */
+seg = decode_segment(modrm_reg);
 generate_exception_if(seg == decode_segment_failed, EXC_UD, -1);
+store_seg:
 fail_if(ops->read_segment == NULL);
-if ( (rc = ops->read_segment(seg, , ctxt)) != 0 )
+if ( (rc = ops->read_segment(seg, , ctxt)) != 0 )
 goto done;
-dst.val = reg.sel;
+dst.val = sreg.sel;
 if ( dst.type == OP_MEM )
 dst.bytes = 2;
 break;
-}
 
-case 0x8e: /* mov r/m,Sreg */ {
-enum x86_segment seg = decode_segment(modrm_reg);
+case 0x8e: /* mov r/m,Sreg */
+seg = decode_segment(modrm_reg);
 generate_exception_if(seg == decode_segment_failed, EXC_UD, -1);
 generate_exception_if(seg == x86_seg_cs, EXC_UD, -1);
 if ( (rc = load_seg(seg, src.val, 0, NULL, ctxt, ops)) != 0 )
@@ -2884,7 +2882,6 @@ x86_emulate(
 ctxt->retire.flags.mov_ss = 1;
 dst.type = OP_NONE;
 break;
-}
 
 case 0x8d: /* lea */
 generate_exception_if(ea.type != OP_MEM, EXC_UD, -1);
@@ -2941,17 +2938,15 @@ x86_emulate(
 }
 break;
 
-case 0x9a: /* call (far, absolute) */ {
-struct segment_register reg;
-
+case 0x9a: /* call (far, absolute) */
 ASSERT(!mode_64bit());
 fail_if(ops->read_segment == NULL);
 
-if ( (rc = ops->read_segment(x86_seg_cs, , ctxt)) ||
+if ( (rc = ops->read_segment(x86_seg_cs, , ctxt)) ||
  (rc = load_seg(x86_seg_cs, imm2, 0, , ctxt, ops)) ||
  (validate_far_branch(, imm1),
   rc = ops->write(x86_seg_ss, sp_pre_dec(op_bytes),
-  , op_bytes, ctxt)) ||
+  , op_bytes, ctxt)) ||
  (rc = ops->write(x86_seg_ss, sp_pre_dec(op_bytes),
   &_regs.eip, op_bytes, ctxt)) ||
  (rc = ops->write_segment(x86_seg_cs, , ctxt)) )
@@ -2959,7 +2954,6 @@ x86_emulate(
 
 _regs.eip = imm1;
 break;
-}
 
 case 0x9b:  /* wait/fwait */
 host_and_vcpu_must_have(fpu);
@@ -4178,13 +4172,12 @@ x86_emulate(
 
 if ( (modrm_reg & 7) == 3 ) /* call */
 {
-struct segment_register reg;
 fail_if(ops->read_segment == NULL);
-if ( (rc = ops->read_segment(x86_seg_cs, , ctxt)) ||
+if ( (rc = ops->read_segment(x86_seg_cs, , ctxt)) ||
  (rc = load_seg(x86_seg_cs, sel, 0, , ctxt, ops)) ||
  (validate_far_branch(, src.val),
   rc = ops->write(x86_seg_ss, sp_pre_dec(op_bytes),
-  , op_bytes, ctxt)) ||
+  , op_bytes, ctxt)) ||
  (rc = ops->write(x86_seg_ss, sp_pre_dec(op_bytes),
   &_regs.eip, op_bytes, ctxt)) ||
  (rc = ops->write_segment(x86_seg_cs, , ctxt)) )
@@ -4205,34 +4198,24 @@ x86_emulate(
 }
 break;
 
-case X86EMUL_OPC(0x0f, 0x00): /* Grp6 */ {
-enum x86_segment seg = (modrm_reg & 1) ? x86_seg_tr : x86_seg_ldtr;
-
+case X86EMUL_OPC(0x0f, 0x00): /* Grp6 */
+seg = (modrm_reg & 1) ? x86_seg_tr : 

Re: [Xen-devel] [PATCH v3 02/19] acpi/hvmloader: Collect processor and NUMA info in hvmloader

[Jan Beulich]

>>> On 07.09.16 at 20:59,  wrote:
> Changes in v3:
> * Constified acpi_numa's pointers
> * Constified acpi_config call parameter where possible

Thanks, but how about ...

> --- a/tools/firmware/hvmloader/acpi/build.c
> +++ b/tools/firmware/hvmloader/acpi/build.c
> @@ -70,18 +70,20 @@ static void set_checksum(
>  p[checksum_offset] = -sum;
>  }
>  
> -static struct acpi_20_madt *construct_madt(struct acpi_info *info)
> +static struct acpi_20_madt *construct_madt(const struct acpi_config *config,
> +   struct acpi_info *info)
>  {
>  struct acpi_20_madt   *madt;
>  struct acpi_20_madt_intsrcovr *intsrcovr;
>  struct acpi_20_madt_ioapic*io_apic;
>  struct acpi_20_madt_lapic *lapic;
> +struct hvm_info_table *hvminfo = config->hvminfo;

... this?

> --- a/tools/firmware/hvmloader/acpi/libacpi.h
> +++ b/tools/firmware/hvmloader/acpi/libacpi.h
> @@ -20,6 +20,8 @@
>  #ifndef __LIBACPI_H__
>  #define __LIBACPI_H__
>  
> +#include 

Why? struct xen_vmemrange doesn't get instantiated anywhere in
this header.

> @@ -49,6 +59,9 @@ struct acpi_config {
>  uint32_t length;
>  } pt;
>  
> +struct acpi_numa numa;
> +struct hvm_info_table *hvminfo;

And this cannot be const?

Jan


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

[Xen-devel] [PATCH 0/5] x86: further insn emulator improvements

[Jan Beulich]

These are really independent of

and I prefer them to be a separate series, but won't apply without that
one in place. The final two I decided to pick up from Mihai, as it seemed
natural for me to do the rebasing on top of the major earlier changes,
and as I'd like to get the original issue (certain Windows drivers using
these insns) dealt with in 4.8.

1: support UMIP
2: consolidate segment register handling
3: support RTM instructions
4: add support for {,v}movq xmm,xmm/m64
5: add support for {,v}movd {,x}mm,r/m32 and {,v}movq {,x}mm,r/m64

Signed-off-by: Jan Beulich 


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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf d74135cd0f8d00d2126df0b4db54938c96456db6
baseline version:
 ovmf 4ac14ceae076439dcea926bc47cda4e1d2779cae

Last test of basis   100805  2016-09-08 05:50:03 Z0 days
Testing same since   100810  2016-09-08 10:13:28 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Dennis Chen 
  Laszlo Ersek 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=d74135cd0f8d00d2126df0b4db54938c96456db6
+ . ./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 
d74135cd0f8d00d2126df0b4db54938c96456db6
+ branch=ovmf
+ revision=d74135cd0f8d00d2126df0b4db54938c96456db6
+ . ./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.7-testing
+ '[' xd74135cd0f8d00d2126df0b4db54938c96456db6 = 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/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
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : 

Re: [Xen-devel] [PATCH 07/17] x86emul: move x86_execute() common epilogue code

[Jan Beulich]

>>> On 08.09.16 at 15:13,  wrote:
> Only code movement, no functional change.
> 
> Signed-off-by: Jan Beulich 

Just noticed the title was left stale - should really be "x86emul:
move x86_emulate() common epilogue code".

Jan


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

[Xen-devel] [PATCH 17/17] x86emul: don't assume a memory operand

[Jan Beulich]

Especially for x86_insn_operand_ea() to return dependable segment
information even when the caller didn't consider applicability we
shouldn't have ea.type start out as OP_MEM. Make it OP_NONE instead,
and set it to OP_MEM when we actually encounter memory like operands.

This requires to eliminate the XSA-123 fix, which has been no longer
necessary since the elimination of the union in commit dd766684e7. That
in turn allows restricting the scope of override_seg to x86_decode().
At this occasion also make it have a proper type, instead of plain int.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1632,7 +1632,6 @@ struct x86_emulate_state {
 opcode_desc_t desc;
 union vex vex;
 union evex evex;
-int override_seg;
 
 /*
  * Data operand effective address (usually computed from ModRM).
@@ -1664,7 +1663,6 @@ struct x86_emulate_state {
 #define lock_prefix (state->lock_prefix)
 #define vex (state->vex)
 #define evex (state->evex)
-#define override_seg (state->override_seg)
 #define ea (state->ea)
 
 static int
@@ -1693,6 +1691,7 @@ x86_decode_base(
 case 0xa0: case 0xa1: /* mov mem.offs,{%al,%ax,%eax,%rax} */
 case 0xa2: case 0xa3: /* mov {%al,%ax,%eax,%rax},mem.offs */
 /* Source EA is not encoded via ModRM. */
+ea.type = OP_MEM;
 ea.mem.off = insn_fetch_bytes(ad_bytes);
 break;
 
@@ -1783,11 +1782,11 @@ x86_decode(
 {
 uint8_t b, d, sib, sib_index, sib_base;
 unsigned int def_op_bytes, def_ad_bytes, opcode;
+enum x86_segment override_seg = x86_seg_none;
 int rc = X86EMUL_OKAY;
 
 memset(state, 0, sizeof(*state));
-override_seg = -1;
-ea.type = OP_MEM;
+ea.type = OP_NONE;
 ea.mem.seg = x86_seg_ds;
 ea.reg = REG_POISON;
 state->regs = ctxt->regs;
@@ -2085,6 +2084,7 @@ x86_decode(
 else if ( ad_bytes == 2 )
 {
 /* 16-bit ModR/M decode. */
+ea.type = OP_MEM;
 switch ( modrm_rm )
 {
 case 0:
@@ -2135,6 +2135,7 @@ x86_decode(
 else
 {
 /* 32/64-bit ModR/M decode. */
+ea.type = OP_MEM;
 if ( modrm_rm == 4 )
 {
 sib = insn_fetch_type(uint8_t);
@@ -2199,7 +2200,7 @@ x86_decode(
 }
 }
 
-if ( override_seg != -1 && ea.type == OP_MEM )
+if ( override_seg != x86_seg_none )
 ea.mem.seg = override_seg;
 
 /* Fetch the immediate operand, if present. */
@@ -4250,13 +4251,11 @@ x86_emulate(
 generate_exception_if(limit < sizeof(long) ||
   (limit & (limit - 1)), EXC_UD, -1);
 base &= ~(limit - 1);
-if ( override_seg == -1 )
-override_seg = x86_seg_ds;
 if ( ops->rep_stos )
 {
 unsigned long nr_reps = limit / sizeof(zero);
 
-rc = ops->rep_stos(, override_seg, base, sizeof(zero),
+rc = ops->rep_stos(, ea.mem.seg, base, sizeof(zero),
_reps, ctxt);
 if ( rc == X86EMUL_OKAY )
 {
@@ -4268,7 +4267,7 @@ x86_emulate(
 }
 while ( limit )
 {
-rc = ops->write(override_seg, base, , sizeof(zero), ctxt);
+rc = ops->write(ea.mem.seg, base, , sizeof(zero), ctxt);
 if ( rc != X86EMUL_OKAY )
 goto done;
 base += sizeof(zero);
@@ -5254,7 +5253,6 @@ x86_emulate(
 #undef rex_prefix
 #undef lock_prefix
 #undef vex
-#undef override_seg
 #undef ea
 
 #ifdef __XEN__



x86emul: don't assume a memory operand

Especially for x86_insn_operand_ea() to return dependable segment
information even when the caller didn't consider applicability we
shouldn't have ea.type start out as OP_MEM. Make it OP_NONE instead,
and set it to OP_MEM when we actually encounter memory like operands.

This requires to eliminate the XSA-123 fix, which has been no longer
necessary since the elimination of the union in commit dd766684e7. That
in turn allows restricting the scope of override_seg to x86_decode().
At this occasion also make it have a proper type, instead of plain int.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1632,7 +1632,6 @@ struct x86_emulate_state {
 opcode_desc_t desc;
 union vex vex;
 union evex evex;
-int override_seg;
 
 /*
  * Data operand effective address (usually computed from ModRM).
@@ -1664,7 +1663,6 @@ struct x86_emulate_state {
 #define lock_prefix (state->lock_prefix)
 #define vex (state->vex)
 #define evex (state->evex)
-#define override_seg (state->override_seg)
 #define ea (state->ea)
 
 static int
@@ -1693,6 +1691,7 @@ x86_decode_base(
 case 0xa0: case 0xa1: /* mov mem.offs,{%al,%ax,%eax,%rax} */
 

[Xen-devel] [PATCH 16/17] x86/PV: use generic emulator for privileged instruction handling

[Jan Beulich]

There's a new emulator return code being added to allow bypassing
certain operations (see the code comment). Its handling in the epilogue
code involves moving the raising of the single step trap until after
registers were updated. This should probably have been that way from
the beginning, to allow the inject_hw_exception() hook to see updated
register state (in case it cares) - it's a trap, after all.

The other small tweak to the emulator is to single iteration handling
of INS and OUTS: Since we don't want to handle any other memory access
instructions, we want these to be handled by the rep_ins() / rep_outs()
hooks here too. The read() / write() hook pointers get checked for that
purpose.

And finally handling of exceptions gets changed for REP INS / REP OUTS:
If the hook return X86EMUL_EXCEPTION, register state will still get
updated if some iterations have been performed (but the rIP update will
get suppressed if not all of them did get handled). While on the HVM side
the VA -> LA -> PA translation process clips the number of repetitions,
doing so would unduly complicate the PV side code being added here.

Signed-off-by: Jan Beulich 
---
One thing to be considered is that despite avoiding the handling of
memory reads and writes (other than for INS and OUTS) the set of insns
now getting potentially handled by the emulator is much larger than
before. A possible solution to this would be a new hook to be called
between decode and execution stages, allowing further restrictions to
be enforced. Of course this could easily be a follow-up patch, as the
one here is quite big already.

Another thing to consider is to the extend the X86EMUL_EXCEPTION
handling change mentioned above to other string instructions. In that
case this should probably be broken out into a prereq patch.

--- a/tools/tests/x86_emulator/x86_emulate.c
+++ b/tools/tests/x86_emulator/x86_emulate.c
@@ -20,6 +20,9 @@ typedef bool bool_t;
 #define cpu_has_amd_erratum(nr) 0
 #define mark_regs_dirty(r) ((void)(r))
 
+#define likely(x)   __builtin_expect(!!(x), true)
+#define unlikely(x) __builtin_expect(!!(x), false)
+
 #define __packed __attribute__((packed))
 
 /* For generic assembly code: use macros to define operation/operand sizes. */
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -459,6 +459,7 @@ static int hvmemul_linear_to_phys(
 {
 if ( pfec & (PFEC_page_paged | PFEC_page_shared) )
 return X86EMUL_RETRY;
+*reps = 0;
 hvm_inject_page_fault(pfec, addr);
 return X86EMUL_EXCEPTION;
 }
@@ -478,6 +479,7 @@ static int hvmemul_linear_to_phys(
 if ( pfec & (PFEC_page_paged | PFEC_page_shared) )
 return X86EMUL_RETRY;
 done /= bytes_per_rep;
+*reps = done;
 if ( done == 0 )
 {
 ASSERT(!reverse);
@@ -486,7 +488,6 @@ static int hvmemul_linear_to_phys(
 hvm_inject_page_fault(pfec, addr & PAGE_MASK);
 return X86EMUL_EXCEPTION;
 }
-*reps = done;
 break;
 }
 
@@ -568,6 +569,7 @@ static int hvmemul_virtual_to_linear(
 return X86EMUL_UNHANDLEABLE;
 
 /* This is a singleton operation: fail it with an exception. */
+*reps = 0;
 hvmemul_ctxt->exn_pending = 1;
 hvmemul_ctxt->trap.vector =
 (seg == x86_seg_ss) ? TRAP_stack_error : TRAP_gp_fault;
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -662,16 +662,13 @@ static void do_guest_trap(unsigned int t
 trapstr(trapnr), trapnr, regs->error_code);
 }
 
-static void instruction_done(
-struct cpu_user_regs *regs, unsigned long eip, unsigned int bpmatch)
+static void instruction_done(struct cpu_user_regs *regs, unsigned long eip)
 {
 regs->eip = eip;
 regs->eflags &= ~X86_EFLAGS_RF;
-if ( bpmatch || (regs->eflags & X86_EFLAGS_TF) )
+if ( regs->eflags & X86_EFLAGS_TF )
 {
-current->arch.debugreg[6] |= bpmatch | DR_STATUS_RESERVED_ONE;
-if ( regs->eflags & X86_EFLAGS_TF )
-current->arch.debugreg[6] |= DR_STEP;
+current->arch.debugreg[6] |= DR_STEP | DR_STATUS_RESERVED_ONE;
 do_guest_trap(TRAP_debug, regs);
 }
 }
@@ -1272,7 +1269,7 @@ static int emulate_invalid_rdtscp(struct
 return 0;
 eip += sizeof(opcode);
 pv_soft_rdtsc(v, regs, 1);
-instruction_done(regs, eip, 0);
+instruction_done(regs, eip);
 return EXCRET_fault_fixed;
 }
 
@@ -1305,7 +1302,7 @@ static int emulate_forced_invalid_op(str
 
 pv_cpuid(regs);
 
-instruction_done(regs, eip, 0);
+instruction_done(regs, eip);
 
 trace_trap_one_addr(TRC_PV_FORCED_INVALID_OP, regs->eip);
 
@@ -1989,6 +1986,154 @@ static int read_gate_descriptor(unsigned
 return 1;
 }
 
+struct priv_op_ctxt {
+struct x86_emulate_ctxt ctxt;
+struct {
+unsigned long base, limit;
+} cs;
+char *io_emul_stub;
+unsigned int bpmatch;
+ 

[Xen-devel] [PATCH 15/17] x86emul: sort opcode 0f01 special case switch() statement

[Jan Beulich]

Sort the special case opcode 0f01 entries numerically, insert blank
lines between each of the cases, and properly place opening braces.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -4192,6 +4192,14 @@ x86_emulate(
 }
 #endif
 
+case 0xd4: /* vmfunc */
+generate_exception_if(lock_prefix | rep_prefix() | (vex.pfx == 
vex_66),
+  EXC_UD, -1);
+fail_if(ops->vmfunc == NULL);
+if ( (rc = ops->vmfunc(ctxt) != X86EMUL_OKAY) )
+goto done;
+goto no_writeback;
+
 case 0xdf: /* invlpga */
 generate_exception_if(!in_protmode(ctxt, ops), EXC_UD, -1);
 generate_exception_if(!mode_ring0(), EXC_GP, 0);
@@ -4200,7 +4208,9 @@ x86_emulate(
ctxt)) )
 goto done;
 goto no_writeback;
-case 0xf9: /* rdtscp */ {
+
+case 0xf9: /* rdtscp */
+{
 uint64_t tsc_aux;
 fail_if(ops->read_msr == NULL);
 if ( (rc = ops->read_msr(MSR_TSC_AUX, _aux, ctxt)) != 0 )
@@ -4208,14 +4218,9 @@ x86_emulate(
 _regs.ecx = (uint32_t)tsc_aux;
 goto rdtsc;
 }
-case 0xd4: /* vmfunc */
-generate_exception_if(lock_prefix | rep_prefix() | (vex.pfx == 
vex_66),
-  EXC_UD, -1);
-fail_if(ops->vmfunc == NULL);
-if ( (rc = ops->vmfunc(ctxt) != X86EMUL_OKAY) )
-goto done;
-goto no_writeback;
-   case 0xfc: /* clzero */ {
+
+case 0xfc: /* clzero */
+{
 unsigned int eax = 1, ebx = 0, dummy = 0;
 unsigned long zero = 0;
 



x86emul: sort opcode 0f01 special case switch() statement

Sort the special case opcode 0f01 entries numerically, insert blank
lines between each of the cases, and properly place opening braces.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -4192,6 +4192,14 @@ x86_emulate(
 }
 #endif
 
+case 0xd4: /* vmfunc */
+generate_exception_if(lock_prefix | rep_prefix() | (vex.pfx == 
vex_66),
+  EXC_UD, -1);
+fail_if(ops->vmfunc == NULL);
+if ( (rc = ops->vmfunc(ctxt) != X86EMUL_OKAY) )
+goto done;
+goto no_writeback;
+
 case 0xdf: /* invlpga */
 generate_exception_if(!in_protmode(ctxt, ops), EXC_UD, -1);
 generate_exception_if(!mode_ring0(), EXC_GP, 0);
@@ -4200,7 +4208,9 @@ x86_emulate(
ctxt)) )
 goto done;
 goto no_writeback;
-case 0xf9: /* rdtscp */ {
+
+case 0xf9: /* rdtscp */
+{
 uint64_t tsc_aux;
 fail_if(ops->read_msr == NULL);
 if ( (rc = ops->read_msr(MSR_TSC_AUX, _aux, ctxt)) != 0 )
@@ -4208,14 +4218,9 @@ x86_emulate(
 _regs.ecx = (uint32_t)tsc_aux;
 goto rdtsc;
 }
-case 0xd4: /* vmfunc */
-generate_exception_if(lock_prefix | rep_prefix() | (vex.pfx == 
vex_66),
-  EXC_UD, -1);
-fail_if(ops->vmfunc == NULL);
-if ( (rc = ops->vmfunc(ctxt) != X86EMUL_OKAY) )
-goto done;
-goto no_writeback;
-   case 0xfc: /* clzero */ {
+
+case 0xfc: /* clzero */
+{
 unsigned int eax = 1, ebx = 0, dummy = 0;
 unsigned long zero = 0;
 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 04/17] x86emul: track only rIP in emulator state

[Jan Beulich]

>>> On 08.09.16 at 15:08,  wrote:

Please disregard this one - it got sent out with the wrong number in the 
subject.

Jan


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

[Xen-devel] [PATCH 13/17] x86/PV: split out dealing with MSRs from privileged instruction handling

[Jan Beulich]

This is in preparation for using the generic emulator here.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2373,6 +2373,332 @@ static inline uint64_t guest_misc_enable
 return val;
 }
 
+static inline bool is_cpufreq_controller(const struct domain *d)
+{
+return ((cpufreq_controller == FREQCTL_dom0_kernel) &&
+is_hardware_domain(d));
+}
+
+static int priv_op_read_msr(unsigned int reg, uint64_t *val,
+struct x86_emulate_ctxt *ctxt)
+{
+const struct vcpu *curr = current;
+const struct domain *currd = curr->domain;
+bool vpmu_msr = false;
+
+switch ( reg )
+{
+int rc;
+
+case MSR_FS_BASE:
+if ( is_pv_32bit_domain(currd) )
+break;
+*val = cpu_has_fsgsbase ? __rdfsbase() : curr->arch.pv_vcpu.fs_base;
+return X86EMUL_OKAY;
+
+case MSR_GS_BASE:
+if ( is_pv_32bit_domain(currd) )
+break;
+*val = cpu_has_fsgsbase ? __rdgsbase()
+: curr->arch.pv_vcpu.gs_base_kernel;
+return X86EMUL_OKAY;
+
+case MSR_SHADOW_GS_BASE:
+if ( is_pv_32bit_domain(currd) )
+break;
+*val = curr->arch.pv_vcpu.gs_base_user;
+return X86EMUL_OKAY;
+
+case MSR_K7_FID_VID_CTL:
+case MSR_K7_FID_VID_STATUS:
+case MSR_K8_PSTATE_LIMIT:
+case MSR_K8_PSTATE_CTRL:
+case MSR_K8_PSTATE_STATUS:
+case MSR_K8_PSTATE0:
+case MSR_K8_PSTATE1:
+case MSR_K8_PSTATE2:
+case MSR_K8_PSTATE3:
+case MSR_K8_PSTATE4:
+case MSR_K8_PSTATE5:
+case MSR_K8_PSTATE6:
+case MSR_K8_PSTATE7:
+if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
+break;
+if ( unlikely(is_cpufreq_controller(currd)) )
+goto normal;
+*val = 0;
+return X86EMUL_OKAY;
+
+case MSR_IA32_UCODE_REV:
+BUILD_BUG_ON(MSR_IA32_UCODE_REV != MSR_AMD_PATCHLEVEL);
+if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
+{
+if ( wrmsr_safe(MSR_IA32_UCODE_REV, 0) )
+break;
+sync_core();
+}
+goto normal;
+
+case MSR_IA32_MISC_ENABLE:
+if ( rdmsr_safe(reg, *val) )
+break;
+*val = guest_misc_enable(*val);
+return X86EMUL_OKAY;
+
+case MSR_AMD64_DR0_ADDRESS_MASK:
+if ( !boot_cpu_has(X86_FEATURE_DBEXT) )
+break;
+*val = curr->arch.pv_vcpu.dr_mask[0];
+return X86EMUL_OKAY;
+
+case MSR_AMD64_DR1_ADDRESS_MASK ... MSR_AMD64_DR3_ADDRESS_MASK:
+if ( !boot_cpu_has(X86_FEATURE_DBEXT) )
+break;
+*val = curr->arch.pv_vcpu.dr_mask[reg - MSR_AMD64_DR1_ADDRESS_MASK + 
1];
+return X86EMUL_OKAY;
+
+case MSR_IA32_PERF_CAPABILITIES:
+/* No extra capabilities are supported. */
+*val = 0;
+return X86EMUL_OKAY;
+
+case MSR_P6_PERFCTR(0)...MSR_P6_PERFCTR(7):
+case MSR_P6_EVNTSEL(0)...MSR_P6_EVNTSEL(3):
+case MSR_CORE_PERF_FIXED_CTR0...MSR_CORE_PERF_FIXED_CTR2:
+case MSR_CORE_PERF_FIXED_CTR_CTRL...MSR_CORE_PERF_GLOBAL_OVF_CTRL:
+if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
+{
+vpmu_msr = true;
+/* fall through */
+case MSR_AMD_FAM15H_EVNTSEL0...MSR_AMD_FAM15H_PERFCTR5:
+case MSR_K7_EVNTSEL0...MSR_K7_PERFCTR3:
+if ( vpmu_msr || (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) )
+{
+/* Don't leak PMU MSRs to unprivileged domains. */
+if ( (vpmu_mode & XENPMU_MODE_ALL) &&
+ !is_hardware_domain(currd) )
+*val = 0;
+else if ( vpmu_do_rdmsr(reg, val) )
+break;
+return X86EMUL_OKAY;
+}
+}
+/* fall through */
+default:
+if ( rdmsr_hypervisor_regs(reg, val) )
+return X86EMUL_OKAY;
+
+rc = vmce_rdmsr(reg, val);
+if ( rc < 0 )
+break;
+if ( rc )
+return X86EMUL_OKAY;
+/* fall through */
+case MSR_EFER:
+normal:
+/* Everyone can read the MSR space. */
+/* gdprintk(XENLOG_WARNING, "Domain attempted RDMSR %08x\n", reg); */
+if ( rdmsr_safe(reg, *val) )
+break;
+return X86EMUL_OKAY;
+}
+
+return X86EMUL_UNHANDLEABLE;
+}
+
+#include "x86_64/mmconfig.h"
+
+static int priv_op_write_msr(unsigned int reg, uint64_t val,
+ struct x86_emulate_ctxt *ctxt)
+{
+struct vcpu *curr = current;
+const struct domain *currd = curr->domain;
+bool vpmu_msr = false;
+
+switch ( reg )
+{
+uint64_t temp;
+int rc;
+
+case MSR_FS_BASE:
+if ( is_pv_32bit_domain(currd) )
+break;
+wrfsbase(val);
+curr->arch.pv_vcpu.fs_base = val;
+return X86EMUL_OKAY;
+
+case MSR_GS_BASE:
+if ( 

[Xen-devel] [PATCH 12/17] x86/PV: split out dealing with DRn from privileged instruction handling

[Jan Beulich]

This is in preparation for using the generic emulator here.

Some care is needed temporarily to not unduly alter guest register
state: The local variable "res" can only go away once this code got
fully switched over to using x86_emulate().

Also switch to IS_ERR_VALUE() instead of (incorrectly) open coding it.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2343,6 +2343,26 @@ static int priv_op_write_cr(unsigned int
 return X86EMUL_UNHANDLEABLE;
 }
 
+static int priv_op_read_dr(unsigned int reg, unsigned long *val,
+   struct x86_emulate_ctxt *ctxt)
+{
+unsigned long res = do_get_debugreg(reg);
+
+if ( IS_ERR_VALUE(res) )
+return X86EMUL_UNHANDLEABLE;
+
+*val = res;
+
+return X86EMUL_OKAY;
+}
+
+static int priv_op_write_dr(unsigned int reg, unsigned long val,
+struct x86_emulate_ctxt *ctxt)
+{
+return do_set_debugreg(reg, val) == 0
+   ? X86EMUL_OKAY : X86EMUL_UNHANDLEABLE;
+}
+
 static inline uint64_t guest_misc_enable(uint64_t val)
 {
 val &= ~(MSR_IA32_MISC_ENABLE_PERF_AVAIL |
@@ -2761,16 +2781,14 @@ static int emulate_privileged_op(struct
 break;
 
 case 0x21: /* MOV DR?, */ {
-unsigned long res;
 opcode = insn_fetch(u8, code_base, eip, code_limit);
 if ( opcode < 0xc0 )
 goto fail;
 modrm_reg += ((opcode >> 3) & 7) + (lock << 3);
 modrm_rm  |= (opcode >> 0) & 7;
-reg = decode_register(modrm_rm, regs, 0);
-if ( (res = do_get_debugreg(modrm_reg)) > (unsigned long)-256 )
+if ( priv_op_read_dr(modrm_reg, decode_register(modrm_rm, regs, 0),
+ NULL) != X86EMUL_OKAY )
 goto fail;
-*reg = res;
 break;
 }
 
@@ -2799,7 +2817,7 @@ static int emulate_privileged_op(struct
 modrm_reg += ((opcode >> 3) & 7) + (lock << 3);
 modrm_rm  |= (opcode >> 0) & 7;
 reg = decode_register(modrm_rm, regs, 0);
-if ( do_set_debugreg(modrm_reg, *reg) != 0 )
+if ( priv_op_write_dr(modrm_reg, *reg, NULL) != X86EMUL_OKAY )
 goto fail;
 break;
 



x86/PV: split out dealing with DRn from privileged instruction handling

This is in preparation for using the generic emulator here.

Some care is needed temporarily to not unduly alter guest register
state: The local variable "res" can only go away once this code got
fully switched over to using x86_emulate().

Also switch to IS_ERR_VALUE() instead of (incorrectly) open coding it.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2343,6 +2343,26 @@ static int priv_op_write_cr(unsigned int
 return X86EMUL_UNHANDLEABLE;
 }
 
+static int priv_op_read_dr(unsigned int reg, unsigned long *val,
+   struct x86_emulate_ctxt *ctxt)
+{
+unsigned long res = do_get_debugreg(reg);
+
+if ( IS_ERR_VALUE(res) )
+return X86EMUL_UNHANDLEABLE;
+
+*val = res;
+
+return X86EMUL_OKAY;
+}
+
+static int priv_op_write_dr(unsigned int reg, unsigned long val,
+struct x86_emulate_ctxt *ctxt)
+{
+return do_set_debugreg(reg, val) == 0
+   ? X86EMUL_OKAY : X86EMUL_UNHANDLEABLE;
+}
+
 static inline uint64_t guest_misc_enable(uint64_t val)
 {
 val &= ~(MSR_IA32_MISC_ENABLE_PERF_AVAIL |
@@ -2761,16 +2781,14 @@ static int emulate_privileged_op(struct
 break;
 
 case 0x21: /* MOV DR?, */ {
-unsigned long res;
 opcode = insn_fetch(u8, code_base, eip, code_limit);
 if ( opcode < 0xc0 )
 goto fail;
 modrm_reg += ((opcode >> 3) & 7) + (lock << 3);
 modrm_rm  |= (opcode >> 0) & 7;
-reg = decode_register(modrm_rm, regs, 0);
-if ( (res = do_get_debugreg(modrm_reg)) > (unsigned long)-256 )
+if ( priv_op_read_dr(modrm_reg, decode_register(modrm_rm, regs, 0),
+ NULL) != X86EMUL_OKAY )
 goto fail;
-*reg = res;
 break;
 }
 
@@ -2799,7 +2817,7 @@ static int emulate_privileged_op(struct
 modrm_reg += ((opcode >> 3) & 7) + (lock << 3);
 modrm_rm  |= (opcode >> 0) & 7;
 reg = decode_register(modrm_rm, regs, 0);
-if ( do_set_debugreg(modrm_reg, *reg) != 0 )
+if ( priv_op_write_dr(modrm_reg, *reg, NULL) != X86EMUL_OKAY )
 goto fail;
 break;
 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 11/17] x86/PV: split out dealing with CRn from privileged instruction handling

[Jan Beulich]

This is in preparation for using the generic emulator here.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2242,6 +2242,107 @@ unsigned long guest_to_host_gpr_switch(u
 
 void (*pv_post_outb_hook)(unsigned int port, u8 value);
 
+static int priv_op_read_cr(unsigned int reg, unsigned long *val,
+   struct x86_emulate_ctxt *ctxt)
+{
+const struct vcpu *curr = current;
+
+switch ( reg )
+{
+case 0: /* Read CR0 */
+*val = (read_cr0() & ~X86_CR0_TS) | curr->arch.pv_vcpu.ctrlreg[0];
+return X86EMUL_OKAY;
+
+case 2: /* Read CR2 */
+case 4: /* Read CR4 */
+*val = curr->arch.pv_vcpu.ctrlreg[reg];
+return X86EMUL_OKAY;
+
+case 3: /* Read CR3 */
+{
+const struct domain *currd = curr->domain;
+unsigned long mfn;
+
+if ( !is_pv_32bit_domain(currd) )
+{
+mfn = pagetable_get_pfn(curr->arch.guest_table);
+*val = xen_pfn_to_cr3(mfn_to_gmfn(currd, mfn));
+}
+else
+{
+l4_pgentry_t *pl4e =
+
map_domain_page(_mfn(pagetable_get_pfn(curr->arch.guest_table)));
+
+mfn = l4e_get_pfn(*pl4e);
+unmap_domain_page(pl4e);
+*val = compat_pfn_to_cr3(mfn_to_gmfn(currd, mfn));
+}
+/* PTs should not be shared */
+BUG_ON(page_get_owner(mfn_to_page(mfn)) == dom_cow);
+return X86EMUL_OKAY;
+}
+}
+
+return X86EMUL_UNHANDLEABLE;
+}
+
+static int priv_op_write_cr(unsigned int reg, unsigned long val,
+struct x86_emulate_ctxt *ctxt)
+{
+struct vcpu *curr = current;
+
+switch ( reg )
+{
+case 0: /* Write CR0 */
+if ( (val ^ read_cr0()) & ~X86_CR0_TS )
+{
+gdprintk(XENLOG_WARNING,
+"Attempt to change unmodifiable CR0 flags\n");
+break;
+}
+do_fpu_taskswitch(!!(val & X86_CR0_TS));
+return X86EMUL_OKAY;
+
+case 2: /* Write CR2 */
+curr->arch.pv_vcpu.ctrlreg[2] = val;
+arch_set_cr2(curr, val);
+return X86EMUL_OKAY;
+
+case 3: /* Write CR3 */
+{
+struct domain *currd = curr->domain;
+unsigned long gfn;
+struct page_info *page;
+int rc;
+
+gfn = !is_pv_32bit_domain(currd)
+  ? xen_cr3_to_pfn(val) : compat_cr3_to_pfn(val);
+page = get_page_from_gfn(currd, gfn, NULL, P2M_ALLOC);
+if ( !page )
+break;
+rc = new_guest_cr3(page_to_mfn(page));
+put_page(page);
+
+switch ( rc )
+{
+case 0:
+return X86EMUL_OKAY;
+case -ERESTART: /* retry after preemption */
+return X86EMUL_RETRY;
+}
+break;
+}
+
+case 4: /* Write CR4 */
+curr->arch.pv_vcpu.ctrlreg[4] = pv_guest_cr4_fixup(curr, val);
+write_cr4(pv_guest_cr4_to_real_cr4(curr));
+ctxt_switch_levelling(curr);
+return X86EMUL_OKAY;
+}
+
+return X86EMUL_UNHANDLEABLE;
+}
+
 static inline uint64_t guest_misc_enable(uint64_t val)
 {
 val &= ~(MSR_IA32_MISC_ENABLE_PERF_AVAIL |
@@ -2654,48 +2755,9 @@ static int emulate_privileged_op(struct
 goto fail;
 modrm_reg += ((opcode >> 3) & 7) + (lock << 3);
 modrm_rm  |= (opcode >> 0) & 7;
-reg = decode_register(modrm_rm, regs, 0);
-switch ( modrm_reg )
-{
-case 0: /* Read CR0 */
-*reg = (read_cr0() & ~X86_CR0_TS) |
-v->arch.pv_vcpu.ctrlreg[0];
-break;
-
-case 2: /* Read CR2 */
-*reg = v->arch.pv_vcpu.ctrlreg[2];
-break;
-
-case 3: /* Read CR3 */
-{
-unsigned long mfn;
-
-if ( !is_pv_32bit_domain(currd) )
-{
-mfn = pagetable_get_pfn(v->arch.guest_table);
-*reg = xen_pfn_to_cr3(mfn_to_gmfn(currd, mfn));
-}
-else
-{
-l4_pgentry_t *pl4e =
-
map_domain_page(_mfn(pagetable_get_pfn(v->arch.guest_table)));
-
-mfn = l4e_get_pfn(*pl4e);
-unmap_domain_page(pl4e);
-*reg = compat_pfn_to_cr3(mfn_to_gmfn(currd, mfn));
-}
-/* PTs should not be shared */
-BUG_ON(page_get_owner(mfn_to_page(mfn)) == dom_cow);
-}
-break;
-
-case 4: /* Read CR4 */
-*reg = v->arch.pv_vcpu.ctrlreg[4];
-break;
-
-default:
+if ( priv_op_read_cr(modrm_reg, decode_register(modrm_rm, regs, 0),
+ NULL) != X86EMUL_OKAY )
 goto fail;
-}
 break;
 
 case 0x21: /* MOV DR?, */ {
@@ -2719,56 +2781,12 @@ static int emulate_privileged_op(struct
 modrm_reg += ((opcode >> 3) & 7) + (lock << 3);
 modrm_rm  

[Xen-devel] [PATCH 10/17] x86/32on64: use generic instruction decoding for call gate emulation

[Jan Beulich]

... instead of custom handling. Note that we can't use generic
emulation, as the emulator's far branch support is rather rudimentary
at this point in time.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -3138,13 +3139,92 @@ static inline int check_stack_limit(unsi
 (!(ar & _SEGMENT_EC) ? (esp - 1) <= limit : (esp - decr) > limit));
 }
 
+struct gate_op_ctxt {
+struct x86_emulate_ctxt ctxt;
+struct {
+unsigned long base, limit;
+} cs;
+bool insn_fetch;
+};
+
+static int gate_op_read(
+enum x86_segment seg,
+unsigned long offset,
+void *p_data,
+unsigned int bytes,
+struct x86_emulate_ctxt *ctxt)
+{
+const struct gate_op_ctxt *goc =
+container_of(ctxt, struct gate_op_ctxt, ctxt);
+unsigned int rc = bytes, sel = 0;
+unsigned long addr = offset, limit = 0;
+
+switch ( seg )
+{
+case x86_seg_cs:
+addr += goc->cs.base;
+limit = goc->cs.limit;
+break;
+case x86_seg_ds:
+sel = read_sreg(ds);
+break;
+case x86_seg_es:
+sel = read_sreg(es);
+break;
+case x86_seg_fs:
+sel = read_sreg(fs);
+break;
+case x86_seg_gs:
+sel = read_sreg(gs);
+break;
+case x86_seg_ss:
+sel = ctxt->regs->ss;
+break;
+default:
+return X86EMUL_UNHANDLEABLE;
+}
+if ( sel )
+{
+unsigned int ar;
+
+ASSERT(!goc->insn_fetch);
+if ( !read_descriptor(sel, current, , , , 0) ||
+ !(ar & _SEGMENT_S) ||
+ !(ar & _SEGMENT_P) ||
+ ((ar & _SEGMENT_CODE) && !(ar & _SEGMENT_WR)) )
+return X86EMUL_UNHANDLEABLE;
+addr += offset;
+}
+else if ( seg != x86_seg_cs )
+return X86EMUL_UNHANDLEABLE;
+
+if ( limit < bytes - 1 || offset > limit - bytes + 1 )
+return X86EMUL_UNHANDLEABLE;
+
+if ( is_pv_32bit_vcpu(current) )
+addr = (uint32_t)addr;
+
+if ( !__addr_ok(addr) ||
+ (rc = __copy_from_user(p_data, (void *)addr, bytes)) )
+{
+propagate_page_fault(addr + bytes - rc,
+ goc->insn_fetch && cpu_has_nx
+ ? PFEC_insn_fetch : 0 );
+return X86EMUL_EXCEPTION;
+}
+
+return X86EMUL_OKAY;
+}
+
 static void emulate_gate_op(struct cpu_user_regs *regs)
 {
 struct vcpu *v = current;
-unsigned int sel, ar, dpl, nparm, opnd_sel;
-unsigned int op_default, op_bytes, ad_default, ad_bytes;
-unsigned long off, eip, opnd_off, base, limit;
-int jump;
+unsigned int sel, ar, dpl, nparm, insn_len;
+struct gate_op_ctxt ctxt = { .ctxt.regs = regs, .insn_fetch = true };
+struct x86_emulate_state *state;
+unsigned long off, base, limit;
+uint16_t opnd_sel = 0;
+int jump = -1, rc = X86EMUL_OKAY;
 
 /* Check whether this fault is due to the use of a call gate. */
 if ( !read_gate_descriptor(regs->error_code, v, , , ) ||
@@ -3166,7 +3246,8 @@ static void emulate_gate_op(struct cpu_u
  * Decode instruction (and perhaps operand) to determine RPL,
  * whether this is a jump or a call, and the call return offset.
  */
-if ( !read_descriptor(regs->cs, v, , , , 0) ||
+if ( !read_descriptor(regs->cs, v, , ,
+  , 0) ||
  !(ar & _SEGMENT_S) ||
  !(ar & _SEGMENT_P) ||
  !(ar & _SEGMENT_CODE) )
@@ -3175,179 +3256,59 @@ static void emulate_gate_op(struct cpu_u
 return;
 }
 
-op_bytes = op_default = ar & _SEGMENT_DB ? 4 : 2;
-ad_default = ad_bytes = op_default;
-opnd_sel = opnd_off = 0;
-jump = -1;
-for ( eip = regs->eip; eip - regs->_eip < 10; )
+ctxt.ctxt.addr_size = ar & _SEGMENT_DB ? 32 : 16;
+/* Leave zero in ctxt.ctxt.sp_size, as it's not needed for decoding. */
+state = x86_decode_insn(, gate_op_read);
+ctxt.insn_fetch = false;
+if ( IS_ERR_OR_NULL(state) )
+{
+if ( PTR_ERR(state) != -X86EMUL_EXCEPTION )
+do_guest_trap(TRAP_gp_fault, regs);
+return;
+}
+
+switch ( ctxt.ctxt.opcode )
 {
-switch ( insn_fetch(u8, base, eip, limit) )
+unsigned int modrm_345;
+
+case 0xea:
+++jump;
+/* fall through */
+case 0x9a:
+++jump;
+opnd_sel = x86_insn_immediate(state, 1);
+break;
+case 0xff:
+if ( x86_insn_modrm(state, NULL, _345) >= 3 )
+break;
+switch ( modrm_345 & 7 )
 {
-case 0x66: /* operand-size override */
-op_bytes = op_default ^ 6; /* switch between 2/4 bytes */
-continue;
-case 0x67: /* address-size override */
-ad_bytes = ad_default != 4 ? 4 : 2; /* switch to 2/4 bytes */
-continue;
-case 0x2e: /* CS override */
-

[Xen-devel] [PATCH 09/17] SVM: use generic instruction decoding

[Jan Beulich]

... instead of custom handling. To facilitate this break out init code
from _hvm_emulate_one() into the new hvm_emulate_init(), and make
hvmemul_insn_fetch( globally available.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -835,7 +835,7 @@ static int hvmemul_read(
 container_of(ctxt, struct hvm_emulate_ctxt, ctxt));
 }
 
-static int hvmemul_insn_fetch(
+int hvmemul_insn_fetch(
 enum x86_segment seg,
 unsigned long offset,
 void *p_data,
@@ -1765,15 +1765,14 @@ static const struct x86_emulate_ops hvm_
 .vmfunc= hvmemul_vmfunc,
 };
 
-static int _hvm_emulate_one(struct hvm_emulate_ctxt *hvmemul_ctxt,
-const struct x86_emulate_ops *ops)
+void hvm_emulate_init(
+struct hvm_emulate_ctxt *hvmemul_ctxt,
+const unsigned char *insn_buf,
+unsigned int insn_bytes)
 {
-struct cpu_user_regs *regs = hvmemul_ctxt->ctxt.regs;
 struct vcpu *curr = current;
-uint32_t new_intr_shadow, pfec = PFEC_page_present;
-struct hvm_vcpu_io *vio = >arch.hvm_vcpu.hvm_io;
+unsigned int pfec = PFEC_page_present;
 unsigned long addr;
-int rc;
 
 if ( hvm_long_mode_enabled(curr) &&
  hvmemul_ctxt->seg_reg[x86_seg_cs].attr.fields.l )
@@ -1791,14 +1790,14 @@ static int _hvm_emulate_one(struct hvm_e
 if ( hvmemul_ctxt->seg_reg[x86_seg_ss].attr.fields.dpl == 3 )
 pfec |= PFEC_user_mode;
 
-hvmemul_ctxt->insn_buf_eip = regs->eip;
-if ( !vio->mmio_insn_bytes )
+hvmemul_ctxt->insn_buf_eip = hvmemul_ctxt->ctxt.regs->eip;
+if ( !insn_bytes )
 {
 hvmemul_ctxt->insn_buf_bytes =
 hvm_get_insn_bytes(curr, hvmemul_ctxt->insn_buf) ?:
 (hvm_virtual_to_linear_addr(x86_seg_cs,
 _ctxt->seg_reg[x86_seg_cs],
-regs->eip,
+hvmemul_ctxt->insn_buf_eip,
 sizeof(hvmemul_ctxt->insn_buf),
 hvm_access_insn_fetch,
 hvmemul_ctxt->ctxt.addr_size,
@@ -1810,11 +1809,24 @@ static int _hvm_emulate_one(struct hvm_e
 }
 else
 {
-hvmemul_ctxt->insn_buf_bytes = vio->mmio_insn_bytes;
-memcpy(hvmemul_ctxt->insn_buf, vio->mmio_insn, vio->mmio_insn_bytes);
+hvmemul_ctxt->insn_buf_bytes = insn_bytes;
+memcpy(hvmemul_ctxt->insn_buf, insn_buf, insn_bytes);
 }
 
 hvmemul_ctxt->exn_pending = 0;
+}
+
+static int _hvm_emulate_one(struct hvm_emulate_ctxt *hvmemul_ctxt,
+const struct x86_emulate_ops *ops)
+{
+const struct cpu_user_regs *regs = hvmemul_ctxt->ctxt.regs;
+struct vcpu *curr = current;
+uint32_t new_intr_shadow;
+struct hvm_vcpu_io *vio = >arch.hvm_vcpu.hvm_io;
+int rc;
+
+hvm_emulate_init(hvmemul_ctxt, vio->mmio_insn, vio->mmio_insn_bytes);
+
 vio->mmio_retry = 0;
 
 if ( cpu_has_vmx )
--- a/xen/arch/x86/hvm/svm/emulate.c
+++ b/xen/arch/x86/hvm/svm/emulate.c
@@ -15,7 +15,7 @@
  * this program; If not, see .
  */
 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -26,41 +26,6 @@
 #include 
 #include 
 
-static unsigned int is_prefix(u8 opc)
-{
-switch ( opc )
-{
-case 0x66:
-case 0x67:
-case 0x2E:
-case 0x3E:
-case 0x26:
-case 0x64:
-case 0x65:
-case 0x36:
-case 0xF0:
-case 0xF3:
-case 0xF2:
-case 0x40 ... 0x4f:
-return 1;
-}
-return 0;
-}
-
-static unsigned long svm_rip2pointer(struct vcpu *v, unsigned long *limit)
-{
-struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
-unsigned long p = vmcb->cs.base + vmcb->rip;
-
-if ( !(vmcb->cs.attr.fields.l && hvm_long_mode_enabled(v)) )
-{
-*limit = vmcb->cs.limit;
-return (u32)p; /* mask to 32 bits */
-}
-*limit = ~0UL;
-return p;
-}
-
 static unsigned long svm_nextrip_insn_length(struct vcpu *v)
 {
 struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
@@ -89,141 +54,96 @@ static unsigned long svm_nextrip_insn_le
 return vmcb->nextrip - vmcb->rip;
 }
 
-/* First byte: Length. Following bytes: Opcode bytes. */
-#define MAKE_INSTR(nm, ...) static const u8 OPCODE_##nm[] = { __VA_ARGS__ }
-MAKE_INSTR(INVD,   2, 0x0f, 0x08);
-MAKE_INSTR(WBINVD, 2, 0x0f, 0x09);
-MAKE_INSTR(CPUID,  2, 0x0f, 0xa2);
-MAKE_INSTR(RDMSR,  2, 0x0f, 0x32);
-MAKE_INSTR(WRMSR,  2, 0x0f, 0x30);
-MAKE_INSTR(VMCALL, 3, 0x0f, 0x01, 0xd9);
-MAKE_INSTR(HLT,1, 0xf4);
-MAKE_INSTR(INT3,   1, 0xcc);
-MAKE_INSTR(RDTSC,  2, 0x0f, 0x31);
-MAKE_INSTR(PAUSE,  1, 0x90);
-MAKE_INSTR(XSETBV, 3, 0x0f, 0x01, 0xd1);
-MAKE_INSTR(VMRUN,  3, 0x0f, 0x01, 0xd8);
-MAKE_INSTR(VMLOAD, 3, 0x0f, 0x01, 0xda);
-MAKE_INSTR(VMSAVE, 3, 0x0f, 0x01, 0xdb);
-MAKE_INSTR(STGI,   3, 0x0f, 0x01, 0xdc);
-MAKE_INSTR(CLGI,   3, 0x0f, 0x01, 0xdd);
-MAKE_INSTR(INVLPGA,3, 0x0f, 0x01, 0xdf);
-
-static const u8 *const 

[Xen-devel] [PATCH 08/17] x86emul: generate and make use of canonical opcode representation

[Jan Beulich]

This representation is then being made available to interested callers,
to facilitate replacing their custom decoding.

This entails combining the three main switch statements into one.

Signed-off-by: Jan Beulich 

--- a/tools/tests/x86_emulator/x86_emulate.c
+++ b/tools/tests/x86_emulator/x86_emulate.c
@@ -14,6 +14,9 @@ typedef bool bool_t;
 #define ASSERT assert
 #define ASSERT_UNREACHABLE() assert(!__LINE__)
 
+#define MASK_EXTR(v, m) (((v) & (m)) / ((m) & -(m)))
+#define MASK_INSR(v, m) (((v) * ((m) & -(m))) & (m))
+
 #define cpu_has_amd_erratum(nr) 0
 #define mark_regs_dirty(r) ((void)(r))
 
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1611,7 +1611,6 @@ struct x86_emulate_state {
 ext_8f09,
 ext_8f0a,
 } ext;
-uint8_t opcode;
 uint8_t modrm, modrm_mod, modrm_reg, modrm_rm;
 uint8_t rex_prefix;
 bool lock_prefix;
@@ -1657,7 +1656,7 @@ x86_decode_base(
 {
 int rc = X86EMUL_OKAY;
 
-switch ( state->opcode )
+switch ( ctxt->opcode )
 {
 case 0x9a: /* call (far, absolute) */
 case 0xea: /* jmp (far, absolute) */
@@ -1696,11 +1695,9 @@ x86_decode_twobyte(
 {
 int rc = X86EMUL_OKAY;
 
-switch ( state->opcode )
+switch ( ctxt->opcode & X86EMUL_OPC_MASK )
 {
 case 0x78:
-if ( vex.opcx )
-break;
 switch ( vex.pfx )
 {
 case vex_66: /* extrq $imm8, $imm8, xmm */
@@ -1709,7 +1706,23 @@ x86_decode_twobyte(
 imm2 = insn_fetch_type(uint8_t);
 break;
 }
-break;
+/* fall through */
+case 0x10 ... 0x18:
+case 0x28 ... 0x2f:
+case 0x50 ... 0x77:
+case 0x79 ... 0x7f:
+case 0xae:
+case 0xc2:
+case 0xc4 ... 0xc7:
+case 0xd0 ... 0xfe:
+ctxt->opcode |= MASK_INSR(vex.pfx, X86EMUL_OPC_PFX_MASK);
+break;
+/* Intentionally not handling here despite being modified by F3:
+case 0xb8: jmpe / popcnt
+case 0xbc: bsf / tzcnt
+case 0xbd: bsr / lzcnt
+ * They're being dealt with in the execution phase (if at all).
+ */
 }
 
  done:
@@ -1717,13 +1730,35 @@ x86_decode_twobyte(
 }
 
 static int
+x86_decode_0f38(
+struct x86_emulate_state *state,
+struct x86_emulate_ctxt *ctxt,
+const struct x86_emulate_ops *ops)
+{
+switch ( ctxt->opcode & X86EMUL_OPC_MASK )
+{
+case 0x00 ... 0xef:
+case 0xf2 ... 0xff:
+ctxt->opcode |= MASK_INSR(vex.pfx, X86EMUL_OPC_PFX_MASK);
+break;
+
+case 0xf0: case 0xf1: /* movbe / crc32 */
+if ( rep_prefix() )
+ctxt->opcode |= MASK_INSR(vex.pfx, X86EMUL_OPC_PFX_MASK);
+break;
+}
+
+return X86EMUL_OKAY;
+}
+
+static int
 x86_decode(
 struct x86_emulate_state *state,
 struct x86_emulate_ctxt *ctxt,
 const struct x86_emulate_ops  *ops)
 {
 uint8_t b, d, sib, sib_index, sib_base;
-unsigned int def_op_bytes, def_ad_bytes;
+unsigned int def_op_bytes, def_ad_bytes, opcode;
 int rc = X86EMUL_OKAY;
 
 memset(state, 0, sizeof(*state));
@@ -1804,29 +1839,31 @@ x86_decode(
 
 /* Opcode byte(s). */
 d = opcode_table[b];
-if ( d == 0 )
+if ( d == 0 && b == 0x0f)
 {
-/* Two-byte opcode? */
-if ( b == 0x0f )
+/* Two-byte opcode. */
+b = insn_fetch_type(uint8_t);
+d = twobyte_table[b];
+switch ( b )
 {
+default:
+opcode = b | MASK_INSR(0x0f, X86EMUL_OPC_EXT_MASK);
+ext = ext_0f;
+break;
+case 0x38:
 b = insn_fetch_type(uint8_t);
-d = twobyte_table[b];
-switch ( b )
-{
-default:
-ext = ext_0f;
-break;
-case 0x38:
-b = insn_fetch_type(uint8_t);
-ext = ext_0f38;
-break;
-case 0x3a:
-b = insn_fetch_type(uint8_t);
-ext = ext_0f3a;
-break;
-}
+opcode = b | MASK_INSR(0x0f38, X86EMUL_OPC_EXT_MASK);
+ext = ext_0f38;
+break;
+case 0x3a:
+b = insn_fetch_type(uint8_t);
+opcode = b | MASK_INSR(0x0f3a, X86EMUL_OPC_EXT_MASK);
+ext = ext_0f3a;
+break;
 }
 }
+else
+opcode = b;
 
 /* ModRM and SIB bytes. */
 if ( d & ModRM )
@@ -1855,6 +1892,7 @@ x86_decode(
 vex.raw[0] = modrm;
 if ( b == 0xc5 )
 {
+opcode = X86EMUL_OPC_VEX_;
 vex.raw[1] = modrm;
 vex.opcx = vex_0f;
 vex.x = 1;
@@ -1876,31 +1914,44 @@ x86_decode(
 op_bytes = 8;
 }
 }
-if ( b == 0x62 )
+switch ( b )
 {
+

[Xen-devel] [PATCH 07/17] x86emul: move x86_execute() common epilogue code

[Jan Beulich]

Only code movement, no functional change.

Signed-off-by: Jan Beulich 
---
This is just to ease review of a later patch.

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -4111,56 +4111,7 @@ x86_emulate(
 default:
 goto cannot_emulate;
 }
-
- writeback:
-switch ( dst.type )
-{
-case OP_REG:
-/* The 4-byte case *is* correct: in 64-bit mode we zero-extend. */
-switch ( dst.bytes )
-{
-case 1: *(uint8_t  *)dst.reg = (uint8_t)dst.val; break;
-case 2: *(uint16_t *)dst.reg = (uint16_t)dst.val; break;
-case 4: *dst.reg = (uint32_t)dst.val; break; /* 64b: zero-ext */
-case 8: *dst.reg = dst.val; break;
-}
-break;
-case OP_MEM:
-if ( !(d & Mov) && (dst.orig_val == dst.val) &&
- !ctxt->force_writeback )
-/* nothing to do */;
-else if ( lock_prefix )
-rc = ops->cmpxchg(
-dst.mem.seg, dst.mem.off, _val,
-, dst.bytes, ctxt);
-else
-rc = ops->write(
-dst.mem.seg, dst.mem.off, , dst.bytes, ctxt);
-if ( rc != 0 )
-goto done;
-default:
-break;
-}
-
- no_writeback:
-/* Inject #DB if single-step tracing was enabled at instruction start. */
-if ( (ctxt->regs->eflags & EFLG_TF) && (rc == X86EMUL_OKAY) &&
- (ops->inject_hw_exception != NULL) )
-rc = ops->inject_hw_exception(EXC_DB, -1, ctxt) ? : X86EMUL_EXCEPTION;
-
-/* Commit shadow register state. */
-_regs.eflags &= ~EFLG_RF;
-
-/* Zero the upper 32 bits of %rip if not in 64-bit mode. */
-if ( !mode_64bit() )
-_regs.eip = (uint32_t)_regs.eip;
-
-*ctxt->regs = _regs;
-
- done:
-_put_fpu();
-put_stub(stub);
-return rc;
+goto writeback;
 
  ext_0f_insn:
 switch ( b )
@@ -5134,7 +5085,56 @@ x86_emulate(
 default:
 goto cannot_emulate;
 }
-goto writeback;
+
+ writeback:
+switch ( dst.type )
+{
+case OP_REG:
+/* The 4-byte case *is* correct: in 64-bit mode we zero-extend. */
+switch ( dst.bytes )
+{
+case 1: *(uint8_t  *)dst.reg = (uint8_t)dst.val; break;
+case 2: *(uint16_t *)dst.reg = (uint16_t)dst.val; break;
+case 4: *dst.reg = (uint32_t)dst.val; break; /* 64b: zero-ext */
+case 8: *dst.reg = dst.val; break;
+}
+break;
+case OP_MEM:
+if ( !(d & Mov) && (dst.orig_val == dst.val) &&
+ !ctxt->force_writeback )
+/* nothing to do */;
+else if ( lock_prefix )
+rc = ops->cmpxchg(
+dst.mem.seg, dst.mem.off, _val,
+, dst.bytes, ctxt);
+else
+rc = ops->write(
+dst.mem.seg, dst.mem.off, , dst.bytes, ctxt);
+if ( rc != 0 )
+goto done;
+default:
+break;
+}
+
+ no_writeback:
+/* Inject #DB if single-step tracing was enabled at instruction start. */
+if ( (ctxt->regs->eflags & EFLG_TF) && (rc == X86EMUL_OKAY) &&
+ (ops->inject_hw_exception != NULL) )
+rc = ops->inject_hw_exception(EXC_DB, -1, ctxt) ? : X86EMUL_EXCEPTION;
+
+/* Commit shadow register state. */
+_regs.eflags &= ~EFLG_RF;
+
+/* Zero the upper 32 bits of %rip if not in 64-bit mode. */
+if ( !mode_64bit() )
+_regs.eip = (uint32_t)_regs.eip;
+
+*ctxt->regs = _regs;
+
+ done:
+_put_fpu();
+put_stub(stub);
+return rc;
 
  cannot_emulate:
 _put_fpu();



x86emul: move x86_execute() common epilogue code

Only code movement, no functional change.

Signed-off-by: Jan Beulich 
---
This is just to ease review of a later patch.

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -4111,56 +4111,7 @@ x86_emulate(
 default:
 goto cannot_emulate;
 }
-
- writeback:
-switch ( dst.type )
-{
-case OP_REG:
-/* The 4-byte case *is* correct: in 64-bit mode we zero-extend. */
-switch ( dst.bytes )
-{
-case 1: *(uint8_t  *)dst.reg = (uint8_t)dst.val; break;
-case 2: *(uint16_t *)dst.reg = (uint16_t)dst.val; break;
-case 4: *dst.reg = (uint32_t)dst.val; break; /* 64b: zero-ext */
-case 8: *dst.reg = dst.val; break;
-}
-break;
-case OP_MEM:
-if ( !(d & Mov) && (dst.orig_val == dst.val) &&
- !ctxt->force_writeback )
-/* nothing to do */;
-else if ( lock_prefix )
-rc = ops->cmpxchg(
-dst.mem.seg, dst.mem.off, _val,
-, dst.bytes, ctxt);
-else
-rc = ops->write(
-dst.mem.seg, dst.mem.off, , dst.bytes, ctxt);
-if ( rc != 0 )
-goto done;
-default:
-break;
-}
-
- no_writeback:
-/* Inject #DB if single-step tracing was enabled at 

[Xen-devel] [PATCH 06/17] x86emul: add EVEX decoding

[Jan Beulich]

This way we can at least size (and e.g. skip) them if needed, and we
also won't raise the wrong fault due to not having read all relevant
bytes.

Signed-off-by: Jan Beulich 
---
TBD: I'm kind of undecided whether to right away propagate evex.R into
 modrm_reg (and then also deal with the new meaning of evex.x for
 modrm_rm). Since that doesn't affect GPRs (and the extra bits
 would need masking off when accessing GPRs) I've left this out for
 now.

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -336,6 +336,27 @@ union vex {
 ptr[1] = rex | REX_PREFIX; \
 } while (0)
 
+union evex {
+uint8_t raw[3];
+struct {
+uint8_t opcx:2;
+uint8_t :2;
+uint8_t R:1;
+uint8_t b:1;
+uint8_t x:1;
+uint8_t r:1;
+uint8_t pfx:2;
+uint8_t evex:1;
+uint8_t reg:4;
+uint8_t w:1;
+uint8_t opmsk:3;
+uint8_t RX:1;
+uint8_t bcst:1;
+uint8_t lr:2;
+uint8_t z:1;
+};
+};
+
 #define rep_prefix()   (vex.pfx >= vex_f3)
 #define repe_prefix()  (vex.pfx == vex_f3)
 #define repne_prefix() (vex.pfx == vex_f2)
@@ -1596,6 +1617,7 @@ struct x86_emulate_state {
 bool lock_prefix;
 opcode_desc_t desc;
 union vex vex;
+union evex evex;
 int override_seg;
 
 /*
@@ -1623,6 +1645,7 @@ struct x86_emulate_state {
 #define rex_prefix (state->rex_prefix)
 #define lock_prefix (state->lock_prefix)
 #define vex (state->vex)
+#define evex (state->evex)
 #define override_seg (state->override_seg)
 #define ea (state->ea)
 
@@ -1811,7 +1834,8 @@ x86_decode(
 modrm = insn_fetch_type(uint8_t);
 modrm_mod = (modrm & 0xc0) >> 6;
 
-if ( !ext && ((b & ~1) == 0xc4 || (b == 0x8f && (modrm & 0x18))) )
+if ( !ext && ((b & ~1) == 0xc4 || (b == 0x8f && (modrm & 0x18)) ||
+  b == 0x62) )
 switch ( def_ad_bytes )
 {
 default:
@@ -1825,7 +1849,7 @@ x86_decode(
 break;
 /* fall through */
 case 8:
-/* VEX / XOP */
+/* VEX / XOP / EVEX */
 generate_exception_if(rex_prefix || vex.pfx, EXC_UD, -1);
 
 vex.raw[0] = modrm;
@@ -1852,6 +1876,14 @@ x86_decode(
 op_bytes = 8;
 }
 }
+if ( b == 0x62 )
+{
+evex.raw[0] = vex.raw[0];
+evex.raw[1] = vex.raw[1];
+evex.raw[2] = insn_fetch_type(uint8_t);
+
+vex.opcx = evex.opcx;
+}
 }
 if ( mode_64bit() && !vex.r )
 rex_prefix |= REX_R;



x86emul: add EVEX decoding

This way we can at least size (and e.g. skip) them if needed, and we
also won't raise the wrong fault due to not having read all relevant
bytes.

Signed-off-by: Jan Beulich 
---
TBD: I'm kind of undecided whether to right away propagate evex.R into
 modrm_reg (and then also deal with the new meaning of evex.x for
 modrm_rm). Since that doesn't affect GPRs (and the extra bits
 would need masking off when accessing GPRs) I've left this out for
 now.

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -336,6 +336,27 @@ union vex {
 ptr[1] = rex | REX_PREFIX; \
 } while (0)
 
+union evex {
+uint8_t raw[3];
+struct {
+uint8_t opcx:2;
+uint8_t :2;
+uint8_t R:1;
+uint8_t b:1;
+uint8_t x:1;
+uint8_t r:1;
+uint8_t pfx:2;
+uint8_t evex:1;
+uint8_t reg:4;
+uint8_t w:1;
+uint8_t opmsk:3;
+uint8_t RX:1;
+uint8_t bcst:1;
+uint8_t lr:2;
+uint8_t z:1;
+};
+};
+
 #define rep_prefix()   (vex.pfx >= vex_f3)
 #define repe_prefix()  (vex.pfx == vex_f3)
 #define repne_prefix() (vex.pfx == vex_f2)
@@ -1596,6 +1617,7 @@ struct x86_emulate_state {
 bool lock_prefix;
 opcode_desc_t desc;
 union vex vex;
+union evex evex;
 int override_seg;
 
 /*
@@ -1623,6 +1645,7 @@ struct x86_emulate_state {
 #define rex_prefix (state->rex_prefix)
 #define lock_prefix (state->lock_prefix)
 #define vex (state->vex)
+#define evex (state->evex)
 #define override_seg (state->override_seg)
 #define ea (state->ea)
 
@@ -1811,7 +1834,8 @@ x86_decode(
 modrm = insn_fetch_type(uint8_t);
 modrm_mod = (modrm & 0xc0) >> 6;
 
-if ( !ext && ((b & ~1) == 0xc4 || (b == 0x8f && (modrm & 0x18))) )
+if ( !ext && ((b & ~1) == 0xc4 || (b == 0x8f && (modrm & 0x18)) ||
+  b == 0x62) )
 switch ( def_ad_bytes )
 {
 default:
@@ -1825,7 +1849,7 @@ x86_decode(
 break;
 /* fall 

[Xen-devel] [PATCH 04/17] x86emul: complete decoding of two-byte instructions

[Jan Beulich]

This way we can at least size (and e.g. skip) them if needed, and we
also won't raise the wrong fault due to not having read all relevant
bytes.

This at once adds correct raising of #UD for the three "ud" flavors
(Intel names only "ud2", but AMD names all three of them in their
opcode maps), as that may make a difference to callers compared to
getting back X86EMUL_UNHANDLEABLE.

Note on opcodes 0FA6 and 0FA7: These are VIA's PadLock instructions,
which have a ModRM like byte where only register forms are valid. I.e.
we could also use SrcImmByte there, but ModRM is more likely to be
correct for a hypothetical extension allowing non-register operations.

Note on opcode 0FB8: I think we're safe to ignore JMPE (which doesn't
take a ModRM byte, but an immediate).

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -182,11 +182,14 @@ static const opcode_desc_t opcode_table[
 
 static const opcode_desc_t twobyte_table[256] = {
 /* 0x00 - 0x07 */
-SrcMem16|ModRM, ImplicitOps|ModRM, 0, 0, 0, ImplicitOps, ImplicitOps, 0,
+SrcMem16|ModRM, ImplicitOps|ModRM, ModRM, ModRM,
+0, ImplicitOps, ImplicitOps, ImplicitOps,
 /* 0x08 - 0x0F */
-ImplicitOps, ImplicitOps, 0, 0, 0, ImplicitOps|ModRM, 0, 0,
+ImplicitOps, ImplicitOps, 0, ImplicitOps,
+0, ImplicitOps|ModRM, ImplicitOps, ModRM|SrcImmByte,
 /* 0x10 - 0x17 */
-ImplicitOps|ModRM, ImplicitOps|ModRM, 0, 0, 0, 0, 0, 0,
+ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM,
+ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM,
 /* 0x18 - 0x1F */
 ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM,
 ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM,
@@ -194,12 +197,13 @@ static const opcode_desc_t twobyte_table
 ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM,
 0, 0, 0, 0,
 /* 0x28 - 0x2F */
-ImplicitOps|ModRM, ImplicitOps|ModRM, 0, ImplicitOps|ModRM, 0, 0, 0, 0,
+ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM,
+ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM,
 /* 0x30 - 0x37 */
-ImplicitOps, ImplicitOps, ImplicitOps, 0,
-ImplicitOps, ImplicitOps, 0, 0,
+ImplicitOps, ImplicitOps, ImplicitOps, ImplicitOps,
+ImplicitOps, ImplicitOps, 0, ImplicitOps,
 /* 0x38 - 0x3F */
-DstReg|SrcMem|ModRM, 0, 0, 0, 0, 0, 0, 0,
+DstReg|SrcMem|ModRM, 0, DstReg|SrcImmByte|ModRM, 0, 0, 0, 0, 0,
 /* 0x40 - 0x47 */
 DstReg|SrcMem|ModRM|Mov, DstReg|SrcMem|ModRM|Mov,
 DstReg|SrcMem|ModRM|Mov, DstReg|SrcMem|ModRM|Mov,
@@ -211,11 +215,15 @@ static const opcode_desc_t twobyte_table
 DstReg|SrcMem|ModRM|Mov, DstReg|SrcMem|ModRM|Mov,
 DstReg|SrcMem|ModRM|Mov, DstReg|SrcMem|ModRM|Mov,
 /* 0x50 - 0x5F */
-0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ModRM, ModRM, ModRM, ModRM, ModRM, ModRM, ModRM, ModRM,
+ModRM, ModRM, ModRM, ModRM, ModRM, ModRM, ModRM, ModRM,
 /* 0x60 - 0x6F */
-0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ImplicitOps|ModRM,
+ModRM, ModRM, ModRM, ModRM, ModRM, ModRM, ModRM, ModRM,
+ModRM, ModRM, ModRM, ModRM, ModRM, ModRM, ModRM, ImplicitOps|ModRM,
 /* 0x70 - 0x7F */
-0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ImplicitOps|ModRM,
+SrcImmByte|ModRM, SrcImmByte|ModRM, SrcImmByte|ModRM, SrcImmByte|ModRM,
+ModRM, ModRM, ModRM, ImplicitOps,
+ModRM, ModRM, 0, 0, ModRM, ModRM, ModRM, ImplicitOps|ModRM,
 /* 0x80 - 0x87 */
 DstImplicit|SrcImm, DstImplicit|SrcImm,
 DstImplicit|SrcImm, DstImplicit|SrcImm,
@@ -238,9 +246,9 @@ static const opcode_desc_t twobyte_table
 ByteOp|DstMem|SrcNone|ModRM|Mov, ByteOp|DstMem|SrcNone|ModRM|Mov,
 /* 0xA0 - 0xA7 */
 ImplicitOps, ImplicitOps, ImplicitOps, DstBitBase|SrcReg|ModRM,
-DstMem|SrcImmByte|ModRM, DstMem|SrcReg|ModRM, 0, 0,
+DstMem|SrcImmByte|ModRM, DstMem|SrcReg|ModRM, ModRM, ModRM,
 /* 0xA8 - 0xAF */
-ImplicitOps, ImplicitOps, 0, DstBitBase|SrcReg|ModRM,
+ImplicitOps, ImplicitOps, ImplicitOps, DstBitBase|SrcReg|ModRM,
 DstMem|SrcImmByte|ModRM, DstMem|SrcReg|ModRM,
 ImplicitOps|ModRM, DstReg|SrcMem|ModRM,
 /* 0xB0 - 0xB7 */
@@ -249,22 +257,26 @@ static const opcode_desc_t twobyte_table
 DstReg|SrcMem|ModRM|Mov, DstReg|SrcMem|ModRM|Mov,
 ByteOp|DstReg|SrcMem|ModRM|Mov, DstReg|SrcMem16|ModRM|Mov,
 /* 0xB8 - 0xBF */
-0, 0, DstBitBase|SrcImmByte|ModRM, DstBitBase|SrcReg|ModRM,
+DstReg|SrcMem|ModRM, ModRM,
+DstBitBase|SrcImmByte|ModRM, DstBitBase|SrcReg|ModRM,
 DstReg|SrcMem|ModRM, DstReg|SrcMem|ModRM,
 ByteOp|DstReg|SrcMem|ModRM|Mov, DstReg|SrcMem16|ModRM|Mov,
 /* 0xC0 - 0xC7 */
 ByteOp|DstMem|SrcReg|ModRM, DstMem|SrcReg|ModRM,
-0, DstMem|SrcReg|ModRM|Mov,
-0, 0, 0, ImplicitOps|ModRM,
+SrcImmByte|ModRM, 

[Xen-devel] [PATCH 05/17] x86emul: add XOP decoding

[Jan Beulich]

This way we can at least size (and e.g. skip) them if needed, and we
also won't raise the wrong fault due to not having read all relevant
bytes.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -279,6 +279,12 @@ static const opcode_desc_t twobyte_table
 ModRM, ModRM, ModRM, ModRM, ModRM, ModRM, ModRM, ModRM
 };
 
+static const opcode_desc_t xop_table[] = {
+DstReg|SrcImmByte|ModRM,
+DstReg|SrcMem|ModRM,
+DstReg|SrcImm|ModRM,
+};
+
 #define REX_PREFIX 0x40
 #define REX_B 0x01
 #define REX_X 0x02
@@ -1580,6 +1586,9 @@ struct x86_emulate_state {
 ext_0f   = vex_0f,
 ext_0f38 = vex_0f38,
 ext_0f3a = vex_0f3a,
+ext_8f08 = 8,
+ext_8f09,
+ext_8f0a,
 } ext;
 uint8_t opcode;
 uint8_t modrm, modrm_mod, modrm_reg, modrm_rm;
@@ -1802,7 +1811,7 @@ x86_decode(
 modrm = insn_fetch_type(uint8_t);
 modrm_mod = (modrm & 0xc0) >> 6;
 
-if ( !ext && ((b & ~1) == 0xc4) )
+if ( !ext && ((b & ~1) == 0xc4 || (b == 0x8f && (modrm & 0x18))) )
 switch ( def_ad_bytes )
 {
 default:
@@ -1816,11 +1825,11 @@ x86_decode(
 break;
 /* fall through */
 case 8:
-/* VEX */
+/* VEX / XOP */
 generate_exception_if(rex_prefix || vex.pfx, EXC_UD, -1);
 
 vex.raw[0] = modrm;
-if ( b & 1 )
+if ( b == 0xc5 )
 {
 vex.raw[1] = modrm;
 vex.opcx = vex_0f;
@@ -1848,18 +1857,30 @@ x86_decode(
 rex_prefix |= REX_R;
 
 b = insn_fetch_type(uint8_t);
-switch ( ext = vex.opcx )
+ext = vex.opcx;
+if ( b != 0x8f )
+{
+switch ( ext )
+{
+case vex_0f:
+d = twobyte_table[b];
+break;
+case vex_0f38:
+d = twobyte_table[0x38];
+break;
+case vex_0f3a:
+d = twobyte_table[0x3a];
+break;
+default:
+rc = X86EMUL_UNHANDLEABLE;
+goto done;
+}
+}
+else if ( ext < ext_8f08 +
+sizeof(xop_table) / sizeof(*xop_table) )
+d = xop_table[ext - ext_8f08];
+else
 {
-case vex_0f:
-d = twobyte_table[b];
-break;
-case vex_0f38:
-d = twobyte_table[0x38];
-break;
-case vex_0f3a:
-d = twobyte_table[0x3a];
-break;
-default:
 rc = X86EMUL_UNHANDLEABLE;
 goto done;
 }
@@ -1921,6 +1942,9 @@ x86_decode(
 
 case ext_0f:
 case ext_0f3a:
+case ext_8f08:
+case ext_8f09:
+case ext_8f0a:
 break;
 
 case ext_0f38:
@@ -2112,6 +2136,9 @@ x86_decode(
 
 case ext_0f38:
 case ext_0f3a:
+case ext_8f08:
+case ext_8f09:
+case ext_8f0a:
 break;
 
 default:
@@ -2332,6 +2359,9 @@ x86_emulate(
 default:
 ASSERT_UNREACHABLE();
 case ext_0f3a:
+case ext_8f08:
+case ext_8f09:
+case ext_8f0a:
 goto cannot_emulate;
 }
 



x86emul: add XOP decoding

This way we can at least size (and e.g. skip) them if needed, and we
also won't raise the wrong fault due to not having read all relevant
bytes.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -279,6 +279,12 @@ static const opcode_desc_t twobyte_table
 ModRM, ModRM, ModRM, ModRM, ModRM, ModRM, ModRM, ModRM
 };
 
+static const opcode_desc_t xop_table[] = {
+DstReg|SrcImmByte|ModRM,
+DstReg|SrcMem|ModRM,
+DstReg|SrcImm|ModRM,
+};
+
 #define REX_PREFIX 0x40
 #define REX_B 0x01
 #define REX_X 0x02
@@ -1580,6 +1586,9 @@ struct x86_emulate_state {
 ext_0f   = vex_0f,
 ext_0f38 = vex_0f38,
 ext_0f3a = vex_0f3a,
+ext_8f08 = 8,
+ext_8f09,
+ext_8f0a,
 } ext;
 uint8_t opcode;
 uint8_t modrm, modrm_mod, modrm_reg, modrm_rm;
@@ -1802,7 +1811,7 @@ x86_decode(
 modrm = insn_fetch_type(uint8_t);
 modrm_mod = (modrm & 0xc0) >> 6;
 
-if ( !ext && ((b & ~1) == 0xc4) )
+if ( !ext && ((b & ~1) == 0xc4 || (b == 0x8f && (modrm & 0x18))) )
 switch ( def_ad_bytes )
 {
 default:
@@ -1816,11 +1825,11 @@ x86_decode(
 

[Xen-devel] [PATCH 03/17] x86emul: track only rIP in emulator state

[Jan Beulich]

Now that all decoding happens in x86_decode() there's no need to keep
the local registers copy in struct x86_emulate_state. Only rIP gets
updated in the decode phase, so only that register needs tracking
there. All other (read-only) registers can be read from the original
structure (but sadly, due to it getting passed to decode_register(),
the pointer can't be made point to "const" to make the compiler help
ensure no modification happens).

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -590,9 +590,9 @@ do{ asm volatile (
 
 /* Fetch next part of the instruction being emulated. */
 #define insn_fetch_bytes(_size) \
-({ unsigned long _x = 0, _eip = _regs.eip;  \
-   _regs.eip += (_size); /* real hardware doesn't truncate */   \
-   generate_exception_if((uint8_t)(_regs.eip -  \
+({ unsigned long _x = 0, _eip = state->eip; \
+   state->eip += (_size); /* real hardware doesn't truncate */  \
+   generate_exception_if((uint8_t)(state->eip - \
ctxt->regs->eip) > MAX_INST_LEN, \
  EXC_GP, 0);\
rc = ops->insn_fetch(x86_seg_cs, _eip, &_x, (_size), ctxt);  \
@@ -1582,8 +1582,8 @@ struct x86_emulate_state {
 #define imm1 ea.val
 #define imm2 ea.orig_val
 
-/* Shadow copy of register state. Committed on successful emulation. */
-struct cpu_user_regs regs;
+unsigned long eip;
+struct cpu_user_regs *regs;
 };
 
 /* Helper definitions. */
@@ -1599,7 +1599,6 @@ struct x86_emulate_state {
 #define vex (state->vex)
 #define override_seg (state->override_seg)
 #define ea (state->ea)
-#define _regs (state->regs)
 
 static int
 x86_decode_base(
@@ -1655,7 +1654,8 @@ x86_decode(
 ea.type = OP_MEM;
 ea.mem.seg = x86_seg_ds;
 ea.reg = REG_POISON;
-_regs = *ctxt->regs;
+state->regs = ctxt->regs;
+state->eip = ctxt->regs->eip;
 
 ctxt->retire.byte = 0;
 
@@ -1759,7 +1759,7 @@ x86_decode(
 default:
 BUG();
 case 2:
-if ( in_realmode(ctxt, ops) || (_regs.eflags & EFLG_VM) )
+if ( in_realmode(ctxt, ops) || (state->regs->eflags & EFLG_VM) 
)
 break;
 /* fall through */
 case 4:
@@ -1885,7 +1885,7 @@ x86_decode(
 modrm_rm |= (rex_prefix & 1) << 3;
 ea.type = OP_REG;
 ea.reg  = decode_register(
-modrm_rm, &_regs, (d & ByteOp) && (rex_prefix == 0));
+modrm_rm, state->regs, (d & ByteOp) && (rex_prefix == 0));
 }
 else if ( ad_bytes == 2 )
 {
@@ -1893,33 +1893,33 @@ x86_decode(
 switch ( modrm_rm )
 {
 case 0:
-ea.mem.off = _regs.ebx + _regs.esi;
+ea.mem.off = state->regs->ebx + state->regs->esi;
 break;
 case 1:
-ea.mem.off = _regs.ebx + _regs.edi;
+ea.mem.off = state->regs->ebx + state->regs->edi;
 break;
 case 2:
 ea.mem.seg = x86_seg_ss;
-ea.mem.off = _regs.ebp + _regs.esi;
+ea.mem.off = state->regs->ebp + state->regs->esi;
 break;
 case 3:
 ea.mem.seg = x86_seg_ss;
-ea.mem.off = _regs.ebp + _regs.edi;
+ea.mem.off = state->regs->ebp + state->regs->edi;
 break;
 case 4:
-ea.mem.off = _regs.esi;
+ea.mem.off = state->regs->esi;
 break;
 case 5:
-ea.mem.off = _regs.edi;
+ea.mem.off = state->regs->edi;
 break;
 case 6:
 if ( modrm_mod == 0 )
 break;
 ea.mem.seg = x86_seg_ss;
-ea.mem.off = _regs.ebp;
+ea.mem.off = state->regs->ebp;
 break;
 case 7:
-ea.mem.off = _regs.ebx;
+ea.mem.off = state->regs->ebx;
 break;
 }
 switch ( modrm_mod )
@@ -1946,14 +1946,15 @@ x86_decode(
 sib_index = ((sib >> 3) & 7) | ((rex_prefix << 2) & 8);
 sib_base  = (sib & 7) | ((rex_prefix << 3) & 8);
 if ( sib_index != 4 )
-ea.mem.off = *(long*)decode_register(sib_index, &_regs, 0);
+ea.mem.off = *(long *)decode_register(sib_index,
+  state->regs, 0);
 ea.mem.off <<= (sib >> 6) & 3;
 if ( (modrm_mod == 0) && ((sib_base & 7) == 5) )
 ea.mem.off += 

[Xen-devel] [PATCH 04/17] x86emul: track only rIP in emulator state

[Jan Beulich]

Now that all decoding happens in x86_decode() there's no need to keep
the local registers copy in struct x86_emulate_state. Only rIP gets
updated in the decode phase, so only that register needs tracking
there. All other (read-only) registers can be read from the original
structure (but sadly, due to it getting passed to decode_register(),
the pointer can't be made point to "const" to make the compiler help
ensure no modification happens).

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -590,9 +590,9 @@ do{ asm volatile (
 
 /* Fetch next part of the instruction being emulated. */
 #define insn_fetch_bytes(_size) \
-({ unsigned long _x = 0, _eip = _regs.eip;  \
-   _regs.eip += (_size); /* real hardware doesn't truncate */   \
-   generate_exception_if((uint8_t)(_regs.eip -  \
+({ unsigned long _x = 0, _eip = state->eip; \
+   state->eip += (_size); /* real hardware doesn't truncate */  \
+   generate_exception_if((uint8_t)(state->eip - \
ctxt->regs->eip) > MAX_INST_LEN, \
  EXC_GP, 0);\
rc = ops->insn_fetch(x86_seg_cs, _eip, &_x, (_size), ctxt);  \
@@ -1582,8 +1582,8 @@ struct x86_emulate_state {
 #define imm1 ea.val
 #define imm2 ea.orig_val
 
-/* Shadow copy of register state. Committed on successful emulation. */
-struct cpu_user_regs regs;
+unsigned long eip;
+struct cpu_user_regs *regs;
 };
 
 /* Helper definitions. */
@@ -1599,7 +1599,6 @@ struct x86_emulate_state {
 #define vex (state->vex)
 #define override_seg (state->override_seg)
 #define ea (state->ea)
-#define _regs (state->regs)
 
 static int
 x86_decode_base(
@@ -1655,7 +1654,8 @@ x86_decode(
 ea.type = OP_MEM;
 ea.mem.seg = x86_seg_ds;
 ea.reg = REG_POISON;
-_regs = *ctxt->regs;
+state->regs = ctxt->regs;
+state->eip = ctxt->regs->eip;
 
 ctxt->retire.byte = 0;
 
@@ -1759,7 +1759,7 @@ x86_decode(
 default:
 BUG();
 case 2:
-if ( in_realmode(ctxt, ops) || (_regs.eflags & EFLG_VM) )
+if ( in_realmode(ctxt, ops) || (state->regs->eflags & EFLG_VM) 
)
 break;
 /* fall through */
 case 4:
@@ -1885,7 +1885,7 @@ x86_decode(
 modrm_rm |= (rex_prefix & 1) << 3;
 ea.type = OP_REG;
 ea.reg  = decode_register(
-modrm_rm, &_regs, (d & ByteOp) && (rex_prefix == 0));
+modrm_rm, state->regs, (d & ByteOp) && (rex_prefix == 0));
 }
 else if ( ad_bytes == 2 )
 {
@@ -1893,33 +1893,33 @@ x86_decode(
 switch ( modrm_rm )
 {
 case 0:
-ea.mem.off = _regs.ebx + _regs.esi;
+ea.mem.off = state->regs->ebx + state->regs->esi;
 break;
 case 1:
-ea.mem.off = _regs.ebx + _regs.edi;
+ea.mem.off = state->regs->ebx + state->regs->edi;
 break;
 case 2:
 ea.mem.seg = x86_seg_ss;
-ea.mem.off = _regs.ebp + _regs.esi;
+ea.mem.off = state->regs->ebp + state->regs->esi;
 break;
 case 3:
 ea.mem.seg = x86_seg_ss;
-ea.mem.off = _regs.ebp + _regs.edi;
+ea.mem.off = state->regs->ebp + state->regs->edi;
 break;
 case 4:
-ea.mem.off = _regs.esi;
+ea.mem.off = state->regs->esi;
 break;
 case 5:
-ea.mem.off = _regs.edi;
+ea.mem.off = state->regs->edi;
 break;
 case 6:
 if ( modrm_mod == 0 )
 break;
 ea.mem.seg = x86_seg_ss;
-ea.mem.off = _regs.ebp;
+ea.mem.off = state->regs->ebp;
 break;
 case 7:
-ea.mem.off = _regs.ebx;
+ea.mem.off = state->regs->ebx;
 break;
 }
 switch ( modrm_mod )
@@ -1946,14 +1946,15 @@ x86_decode(
 sib_index = ((sib >> 3) & 7) | ((rex_prefix << 2) & 8);
 sib_base  = (sib & 7) | ((rex_prefix << 3) & 8);
 if ( sib_index != 4 )
-ea.mem.off = *(long*)decode_register(sib_index, &_regs, 0);
+ea.mem.off = *(long *)decode_register(sib_index,
+  state->regs, 0);
 ea.mem.off <<= (sib >> 6) & 3;
 if ( (modrm_mod == 0) && ((sib_base & 7) == 5) )
 ea.mem.off += 

[Xen-devel] [PATCH 02/17] x86emul: fetch all insn bytes during the decode phase

[Jan Beulich]

This way we can offer to callers the service of just sizing
instructions, and we also can better guarantee not to raise the wrong
fault due to not having read all relevant bytes.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -129,8 +129,8 @@ static const opcode_desc_t opcode_table[
 ImplicitOps, ImplicitOps, ImplicitOps, ImplicitOps,
 ImplicitOps|Mov, ImplicitOps|Mov, ImplicitOps, ImplicitOps,
 /* 0xA0 - 0xA7 */
-ByteOp|DstEax|SrcImplicit|Mov, DstEax|SrcImplicit|Mov,
-ByteOp|ImplicitOps|Mov, ImplicitOps|Mov,
+ByteOp|DstEax|SrcMem|Mov, DstEax|SrcMem|Mov,
+ByteOp|DstMem|SrcEax|Mov, DstMem|SrcEax|Mov,
 ByteOp|ImplicitOps|Mov, ImplicitOps|Mov,
 ByteOp|ImplicitOps, ImplicitOps,
 /* 0xA8 - 0xAF */
@@ -1602,6 +1602,45 @@ struct x86_emulate_state {
 #define _regs (state->regs)
 
 static int
+x86_decode_base(
+struct x86_emulate_state *state,
+struct x86_emulate_ctxt *ctxt,
+const struct x86_emulate_ops *ops)
+{
+int rc = X86EMUL_OKAY;
+
+switch ( state->opcode )
+{
+case 0x9a: /* call (far, absolute) */
+case 0xea: /* jmp (far, absolute) */
+generate_exception_if(mode_64bit(), EXC_UD, -1);
+
+imm1 = insn_fetch_bytes(op_bytes);
+imm2 = insn_fetch_type(uint16_t);
+break;
+
+case 0xa0: case 0xa1: /* mov mem.offs,{%al,%ax,%eax,%rax} */
+case 0xa2: case 0xa3: /* mov {%al,%ax,%eax,%rax},mem.offs */
+/* Source EA is not encoded via ModRM. */
+ea.mem.off = insn_fetch_bytes(ad_bytes);
+break;
+
+case 0xb8 ... 0xbf: /* mov imm{16,32,64},r{16,32,64} */
+if ( op_bytes == 8 ) /* Fetch more bytes to obtain imm64. */
+imm1 = ((uint32_t)imm1 |
+((uint64_t)insn_fetch_type(uint32_t) << 32));
+break;
+
+case 0xc8: /* enter imm16,imm8 */
+imm2 = insn_fetch_type(uint8_t);
+break;
+}
+
+ done:
+return rc;
+}
+
+static int
 x86_decode(
 struct x86_emulate_state *state,
 struct x86_emulate_ctxt *ctxt,
@@ -1994,10 +2033,29 @@ x86_decode(
 state->opcode = b;
 state->desc = d;
 
+switch ( ext )
+{
+case ext_none:
+rc = x86_decode_base(state, ctxt, ops);
+break;
+
+case ext_0f:
+case ext_0f38:
+break;
+
+default:
+ASSERT_UNREACHABLE();
+return X86EMUL_UNHANDLEABLE;
+}
+
  done:
 return rc;
 }
 
+/* No insn fetching past this point. */
+#undef insn_fetch_bytes
+#undef insn_fetch_type
+
 int
 x86_emulate(
 struct x86_emulate_ctxt *ctxt,
@@ -2560,6 +2618,8 @@ x86_emulate(
 case 0xc6 ... 0xc7: /* mov (sole member of Grp11) */
 generate_exception_if((modrm_reg & 7) != 0, EXC_UD, -1);
 case 0x88 ... 0x8b: /* mov */
+case 0xa0 ... 0xa1: /* mov mem.offs,{%al,%ax,%eax,%rax} */
+case 0xa2 ... 0xa3: /* mov {%al,%ax,%eax,%rax},mem.offs */
 dst.val = src.val;
 break;
 
@@ -2644,18 +2704,13 @@ x86_emulate(
 
 case 0x9a: /* call (far, absolute) */ {
 struct segment_register reg;
-uint16_t sel;
-uint32_t eip;
 
-generate_exception_if(mode_64bit(), EXC_UD, -1);
+ASSERT(!mode_64bit());
 fail_if(ops->read_segment == NULL);
 
-eip = insn_fetch_bytes(op_bytes);
-sel = insn_fetch_type(uint16_t);
-
 if ( (rc = ops->read_segment(x86_seg_cs, , ctxt)) ||
- (rc = load_seg(x86_seg_cs, sel, 0, , ctxt, ops)) ||
- (validate_far_branch(, eip),
+ (rc = load_seg(x86_seg_cs, imm2, 0, , ctxt, ops)) ||
+ (validate_far_branch(, imm1),
   rc = ops->write(x86_seg_ss, sp_pre_dec(op_bytes),
   , op_bytes, ctxt)) ||
  (rc = ops->write(x86_seg_ss, sp_pre_dec(op_bytes),
@@ -2663,7 +2718,7 @@ x86_emulate(
  (rc = ops->write_segment(x86_seg_cs, , ctxt)) )
 goto done;
 
-_regs.eip = eip;
+_regs.eip = imm1;
 break;
 }
 
@@ -2706,23 +2761,6 @@ x86_emulate(
 ((uint8_t *)&_regs.eax)[1] = (_regs.eflags & 0xd7) | 0x02;
 break;
 
-case 0xa0 ... 0xa1: /* mov mem.offs,{%al,%ax,%eax,%rax} */
-/* Source EA is not encoded via ModRM. */
-dst.bytes = (d & ByteOp) ? 1 : op_bytes;
-if ( (rc = read_ulong(ea.mem.seg, insn_fetch_bytes(ad_bytes),
-  , dst.bytes, ctxt, ops)) != 0 )
-goto done;
-break;
-
-case 0xa2 ... 0xa3: /* mov {%al,%ax,%eax,%rax},mem.offs */
-/* Destination EA is not encoded via ModRM. */
-dst.type  = OP_MEM;
-dst.mem.seg = ea.mem.seg;
-dst.mem.off = insn_fetch_bytes(ad_bytes);
-dst.bytes = (d & ByteOp) ? 1 : op_bytes;
-dst.val   = (unsigned long)_regs.eax;
-break;
-
 case 0xa4 ... 0xa5: /* movs */ {
 unsigned long nr_reps = get_rep_prefix();
 dst.bytes = (d & 

[Xen-devel] [PATCH 01/17] x86emul: split instruction decoding from execution

[Jan Beulich]

This is only the mechanical part, a subsequent patch will make non-
mechanical adjustments to actually do all decoding in this new
function.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -48,7 +48,9 @@
 /* All operands are implicit in the opcode. */
 #define ImplicitOps (DstImplicit|SrcImplicit)
 
-static uint8_t opcode_table[256] = {
+typedef uint8_t opcode_desc_t;
+
+static const opcode_desc_t opcode_table[256] = {
 /* 0x00 - 0x07 */
 ByteOp|DstMem|SrcReg|ModRM, DstMem|SrcReg|ModRM,
 ByteOp|DstReg|SrcMem|ModRM, DstReg|SrcMem|ModRM,
@@ -178,7 +180,7 @@ static uint8_t opcode_table[256] = {
 ImplicitOps, ImplicitOps, ByteOp|DstMem|SrcNone|ModRM, DstMem|SrcNone|ModRM
 };
 
-static uint8_t twobyte_table[256] = {
+static const opcode_desc_t twobyte_table[256] = {
 /* 0x00 - 0x07 */
 SrcMem16|ModRM, ImplicitOps|ModRM, 0, 0, 0, ImplicitOps, ImplicitOps, 0,
 /* 0x08 - 0x0F */
@@ -607,7 +609,7 @@ do{ asm volatile (
 })
 #define truncate_ea(ea) truncate_word((ea), ad_bytes)
 
-#define mode_64bit() (def_ad_bytes == 8)
+#define mode_64bit() (ctxt->addr_size == 64)
 
 #define fail_if(p)  \
 do {\
@@ -1558,32 +1560,63 @@ int x86emul_unhandleable_rw(
 return X86EMUL_UNHANDLEABLE;
 }
 
-int
-x86_emulate(
-struct x86_emulate_ctxt *ctxt,
-const struct x86_emulate_ops  *ops)
-{
-/* Shadow copy of register state. Committed on successful emulation. */
-struct cpu_user_regs _regs = *ctxt->regs;
+struct x86_emulate_state {
+unsigned int op_bytes, ad_bytes;
+
+enum { ext_none, ext_0f, ext_0f38 } ext;
+uint8_t opcode;
+uint8_t modrm, modrm_mod, modrm_reg, modrm_rm;
+uint8_t rex_prefix;
+bool lock_prefix;
+opcode_desc_t desc;
+union vex vex;
+int override_seg;
 
-uint8_t b, d, sib, sib_index, sib_base, rex_prefix = 0;
-uint8_t modrm = 0, modrm_mod = 0, modrm_reg = 0, modrm_rm = 0;
-enum { ext_none, ext_0f, ext_0f38 } ext = ext_none;
-union vex vex = {};
-unsigned int op_bytes, def_op_bytes, ad_bytes, def_ad_bytes;
-bool_t lock_prefix = 0;
-int override_seg = -1, rc = X86EMUL_OKAY;
-struct operand src = { .reg = REG_POISON };
-struct operand dst = { .reg = REG_POISON };
-enum x86_swint_type swint_type;
-struct x86_emulate_stub stub = {};
-DECLARE_ALIGNED(mmval_t, mmval);
 /*
  * Data operand effective address (usually computed from ModRM).
  * Default is a memory operand relative to segment DS.
  */
-struct operand ea = { .type = OP_MEM, .reg = REG_POISON };
-ea.mem.seg = x86_seg_ds; /* gcc may reject anon union initializer */
+struct operand ea;
+
+/* Immediate operand values, if any. Use otherwise unused fields. */
+#define imm1 ea.val
+#define imm2 ea.orig_val
+
+/* Shadow copy of register state. Committed on successful emulation. */
+struct cpu_user_regs regs;
+};
+
+/* Helper definitions. */
+#define op_bytes (state->op_bytes)
+#define ad_bytes (state->ad_bytes)
+#define ext (state->ext)
+#define modrm (state->modrm)
+#define modrm_mod (state->modrm_mod)
+#define modrm_reg (state->modrm_reg)
+#define modrm_rm (state->modrm_rm)
+#define rex_prefix (state->rex_prefix)
+#define lock_prefix (state->lock_prefix)
+#define vex (state->vex)
+#define override_seg (state->override_seg)
+#define ea (state->ea)
+#define _regs (state->regs)
+
+static int
+x86_decode(
+struct x86_emulate_state *state,
+struct x86_emulate_ctxt *ctxt,
+const struct x86_emulate_ops  *ops)
+{
+uint8_t b, d, sib, sib_index, sib_base;
+unsigned int def_op_bytes, def_ad_bytes;
+int rc = X86EMUL_OKAY;
+
+memset(state, 0, sizeof(*state));
+override_seg = -1;
+ea.type = OP_MEM;
+ea.mem.seg = x86_seg_ds;
+ea.reg = REG_POISON;
+_regs = *ctxt->regs;
 
 ctxt->retire.byte = 0;
 
@@ -1800,7 +1833,7 @@ x86_emulate(
 d = (d & ~(DstMask | SrcMask)) | DstMem | SrcReg | Mov;
 break;
 default: /* Until it is worth making this table based ... */
-goto cannot_emulate;
+return X86EMUL_UNHANDLEABLE;
 }
 break;
 
@@ -1932,6 +1965,61 @@ x86_emulate(
 if ( override_seg != -1 && ea.type == OP_MEM )
 ea.mem.seg = override_seg;
 
+/* Fetch the immediate operand, if present. */
+switch ( d & SrcMask )
+{
+unsigned int bytes;
+
+case SrcImm:
+if ( !(d & ByteOp) )
+bytes = op_bytes != 8 ? op_bytes : 4;
+else
+{
+case SrcImmByte:
+bytes = 1;
+}
+/* NB. Immediates are sign-extended as necessary. */
+switch ( bytes )
+{
+case 1: imm1 = insn_fetch_type(int8_t);  break;
+case 2: imm1 = insn_fetch_type(int16_t); break;
+case 4: imm1 = 

[Xen-devel] [xen-unstable test] 100803: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail REGR. vs. 100773
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 100773
 test-armhf-armhf-xl-vhd   9 debian-di-installfail REGR. vs. 100773

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  6 xen-boot fail  like 100766
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100773
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100773
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100773
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100773
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100773

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 build-i386-rumprun5 rumprun-buildfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   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-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  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-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass

version targeted for testing:
 xen  3d20a6f4faf1c6a18b51b80d99d23daa7762dda2
baseline version:
 xen  343f84be135e6f9e681960a9e235296eae159fc8

Last test of basis   100773  2016-09-06 13:13:28 Z1 days
Failing since100789  2016-09-07 09:36:36 Z1 days2 attempts
Testing same since   100803  2016-09-08 05:36:29 Z0 days1 attempts


People who touched revisions under test:
  "Rockosov, Dmitry" 
  Andrew Cooper 
  George Dunlap 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Konrad Rzeszutek Wilk 
  Olaf Hering 
  Razvan Cojocaru 
  Stefano Stabellini 
  Tamas K Lengyel 
  Wei Liu 

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

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

[Wei Liu]

On Thu, Sep 08, 2016 at 10:43:59AM +0100, Wei Liu wrote:
> On Thu, Sep 08, 2016 at 05:32:00AM +, osstest service owner wrote:
> > flight 100789 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/100789/
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-amd64-libvirt-vhd  9 debian-di-installfail REGR. vs. 
> > 100773
> [...]
> >  test-armhf-armhf-xl-vhd   9 debian-di-installfail REGR. vs. 
> > 100773
> > 
> 
> Andrew pointed out IRL that these two regressions are unfortunate side
> effect of deleting blktap2. In short, the vhd-util used in these tests
> comes from Xen's blktap2. :-/
> 
> I see three ways to move this forward.
> 
> 1. Resurrect vhd-util from blktap2.
> 2. Install blktap-utils shipped in Debian (available from Wheezy
>onwards), the main difficulty would be the package depends on a dkms
>package that seems to require building with kernel header when
>installing.
> 3. Retire these two tests.
> 

4. Provide a pre-made vhd image.

vhd-util create disk.vhd -s 1 -> 24K in actual size.

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

[Xen-devel] [PATCH 00/17] x86: split insn emulator decode and execution

[Jan Beulich]

..., complete the decoder, leverage decoding for SVM instruction
sizing and PV 32-bit call gate emulation, and use the emulator for
PV priv-op handling.

01: x86emul: split instruction decoding from execution
02: x86emul: fetch all insn bytes during the decode phase
03: x86emul: track only rIP in emulator state
04: x86emul: complete decoding of two-byte instructions
05: x86emul: add XOP decoding
06: x86emul: add EVEX decoding
07: x86emul: move x86_execute() common epilogue code
08: x86emul: generate and make use of canonical opcode representation
09: SVM: use generic instruction decoding
10: x86/32on64: use generic instruction decoding
11: x86/PV: split out dealing with CRn from privileged instruction handling
12: x86/PV: split out dealing with DRn from privileged instruction handling
13: x86/PV: split out dealing with MSRs from privileged instruction handling
14: x86emul: support XSETBV
15: x86emul: sort opcode 0f01 special case switch() statement
16: x86/PV: use generic emulator for privileged instruction handling
17: x86emul: don't assume a memory operand

Signed-off-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH] fix EFI part of "symbols: Generate an xen-sym.map"

[Wei Liu]

On Thu, Sep 08, 2016 at 06:45:36AM -0600, Jan Beulich wrote:
> Commit 6ea24e53f1 introduced two problems: It left out a semicolon and
> typo-ed the source file name of the EFI map file install command.
> 
> Signed-off-by: Jan Beulich 
> 

Acked-by: Wei Liu 

> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -67,7 +67,7 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_
>   if [ -r $(TARGET).efi -a -n '$(EFI_DIR)' ]; then \
>   [ -d $(D)$(EFI_DIR) ] || $(INSTALL_DIR) $(D)$(EFI_DIR); \
>   $(INSTALL_DATA) $(TARGET).efi 
> $(D)$(EFI_DIR)/$(T)-$(XEN_FULLVERSION).efi; \
> - $(INSTALL_DATA) $(TARGET)-efi.map 
> $(D)$(DEBUG_DIR)/$(T)-$(XEN_FULLVERSION).efi.map \
> + $(INSTALL_DATA) $(TARGET).efi.map 
> $(D)$(DEBUG_DIR)/$(T)-$(XEN_FULLVERSION).efi.map; \
>   ln -sf $(T)-$(XEN_FULLVERSION).efi 
> $(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).$(XEN_SUBVERSION).efi; \
>   ln -sf $(T)-$(XEN_FULLVERSION).efi 
> $(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).efi; \
>   ln -sf $(T)-$(XEN_FULLVERSION).efi $(D)$(EFI_DIR)/$(T).efi; \
> 
> 
> 

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

[Xen-devel] [xen-unstable-smoke test] 100812: regressions - trouble: blocked/broken/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf   4 host-build-prep  fail REGR. vs. 100800

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  f8b4d961d5661d2edfaccadf66988596bfbc44c6
baseline version:
 xen  3d20a6f4faf1c6a18b51b80d99d23daa7762dda2

Last test of basis   100800  2016-09-08 02:02:05 Z0 days
Testing same since   100812  2016-09-08 11:01:37 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 
  Tim Deegan 

jobs:
 build-amd64  pass
 build-armhf  broken  
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  blocked 
 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


Not pushing.


commit f8b4d961d5661d2edfaccadf66988596bfbc44c6
Author: Andrew Cooper 
Date:   Tue Jun 14 12:45:56 2016 +0100

x86/paging: Make paging_mode_*() predicates behave like predicates

Signed-off-by: Andrew Cooper 
Acked-by: Tim Deegan 
Acked-by: George Dunlap 
(qemu changes not included)

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

[Xen-devel] [PATCH] fix EFI part of "symbols: Generate an xen-sym.map"

[Jan Beulich]

Commit 6ea24e53f1 introduced two problems: It left out a semicolon and
typo-ed the source file name of the EFI map file install command.

Signed-off-by: Jan Beulich 

--- a/xen/Makefile
+++ b/xen/Makefile
@@ -67,7 +67,7 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_
if [ -r $(TARGET).efi -a -n '$(EFI_DIR)' ]; then \
[ -d $(D)$(EFI_DIR) ] || $(INSTALL_DIR) $(D)$(EFI_DIR); \
$(INSTALL_DATA) $(TARGET).efi 
$(D)$(EFI_DIR)/$(T)-$(XEN_FULLVERSION).efi; \
-   $(INSTALL_DATA) $(TARGET)-efi.map 
$(D)$(DEBUG_DIR)/$(T)-$(XEN_FULLVERSION).efi.map \
+   $(INSTALL_DATA) $(TARGET).efi.map 
$(D)$(DEBUG_DIR)/$(T)-$(XEN_FULLVERSION).efi.map; \
ln -sf $(T)-$(XEN_FULLVERSION).efi 
$(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).$(XEN_SUBVERSION).efi; \
ln -sf $(T)-$(XEN_FULLVERSION).efi 
$(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).efi; \
ln -sf $(T)-$(XEN_FULLVERSION).efi $(D)$(EFI_DIR)/$(T).efi; \



fix EFI part of "symbols: Generate an xen-sym.map"

Commit 6ea24e53f1 introduced two problems: It left out a semicolon and
typo-ed the source file name of the EFI map file install command.

Signed-off-by: Jan Beulich 

--- a/xen/Makefile
+++ b/xen/Makefile
@@ -67,7 +67,7 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_
if [ -r $(TARGET).efi -a -n '$(EFI_DIR)' ]; then \
[ -d $(D)$(EFI_DIR) ] || $(INSTALL_DIR) $(D)$(EFI_DIR); \
$(INSTALL_DATA) $(TARGET).efi 
$(D)$(EFI_DIR)/$(T)-$(XEN_FULLVERSION).efi; \
-   $(INSTALL_DATA) $(TARGET)-efi.map 
$(D)$(DEBUG_DIR)/$(T)-$(XEN_FULLVERSION).efi.map \
+   $(INSTALL_DATA) $(TARGET).efi.map 
$(D)$(DEBUG_DIR)/$(T)-$(XEN_FULLVERSION).efi.map; \
ln -sf $(T)-$(XEN_FULLVERSION).efi 
$(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).$(XEN_SUBVERSION).efi; \
ln -sf $(T)-$(XEN_FULLVERSION).efi 
$(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).efi; \
ln -sf $(T)-$(XEN_FULLVERSION).efi $(D)$(EFI_DIR)/$(T).efi; \
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] Xen Security Advisory 187 (CVE-2016-7094) - x86 HVM: Overflow of sh_ctxt->seg_reg[]

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Xen Security Advisory CVE-2016-7094 / XSA-187
  version 3

x86 HVM: Overflow of sh_ctxt->seg_reg[]

UPDATES IN VERSION 3


Fix the backports xsa187-4.6-0002-*.patch and xsa187-4.4-0002-*.patch.
In v1 and v2 these did not compile in debug builds.  (Debug builds
should not be used in production.)

Public release.

ISSUE DESCRIPTION
=

x86 HVM guests running with shadow paging use a subset of the x86 emulator to
handle the guest writing to its own pagetables.  There are situations a guest
can provoke which result in exceeding the space allocated for internal state.


IMPACT
==

A malicious HVM guest administrator can cause Xen to fail a bug check,
causing a denial of service to the host.


VULNERABLE SYSTEMS
==

All versions of Xen are vulnerable.

The vulnerability is only exposed to HVM guests on x86 hardware, which are
configured to run with shadow paging.

The vulnerability is not exposed to x86 PV guests, x86 HVM guests running with
hardware assisted paging, or ARM guests.


x86 HVM guests run in HAP mode by default on modern CPUs.

To discover whether your HVM guests are using HAP, or shadow page
tables: request debug key `q' (from the Xen console, or with
`xl debug-keys q').  This will print (to the console, and visible in
`xl dmesg'), debug information for every domain, containing something
like this:

  (XEN) General information for domain 2:
  (XEN) refcnt=1 dying=2 pause_count=2
  (XEN) nr_pages=2 xenheap_pages=0 shared_pages=0 paged_pages=0 
dirty_cpus={} max_pages=262400
  (XEN) handle=ef58ef1a-784d-4e59-8079-42bdee87f219 vm_assist=
  (XEN) paging assistance: hap refcounts translate external
   ^^^
The presence of `hap' here indicates that the host is not
vulnerable to this domain.  For an HVM domain the presence of `shadow'
indicates that the domain can exploit the vulnerability.


MITIGATION
==

Running only PV guests will avoid this vulnerability.

On hardware which supports Hardware Assisted Paging, configuring the
guests to not run with shadow paging will avoid this vulnerability.


CREDITS
===

This issue was discovered by Andrew Cooper of Citrix.

RESOLUTION
==

Applying the first patch will resolve this issue.

The second patch provides additional assurance that the vulnerability
is truly eliminated and that there are no related problems.

If hotpatching, applying only the first patch is recommended since the
second patch is awkward for hotpatching.  If deploying new builds,
applying both patches is recommended.

Xen version First patch   Second patch
 xen-unstable:   xsa187-0001-*.patch   xsa187-0002-*.patch
 Xen 4.7.x:  xsa187-4.7-0001-*.patch   xsa187-4.7-0002-*.patch
 Xen 4.6.x:  xsa187-4.7-0001-*.patch   xsa187-4.6-0002-*.patch
 Xen 4.5.x:  xsa187-4.7-0001-*.patch   xsa187-4.6-0002-*.patch
 Xen 4.4.x:  xsa187-4.7-0001-*.patch   xsa187-4.4-0002-*.patch

$ sha256sum xsa187*
65205ee195699d65884af04083ffb86c6ddbc96cbca3141c87f6b2d671de45a3  
xsa187-0001-x86-shadow-Avoid-overflowing-sh_ctxt-seg_reg.patch
f90e6d13385fb9219e1e26e3a148d1670aefc7130e0639415d08bbb6a1d9efee  
xsa187-0002-x86-segment-Bounds-check-accesses-to-emulation-ctxt-.patch
727b18ae83001f7ea04613aa7199ada3e6a84939aa44516f7c426e609d383b2a  
xsa187-4.4-0002-x86-segment-Bounds-check-accesses-to-emulation-ctx.patch
b96731379ea77d4931d969f4742dde985ef7a86af9422dcac8327c2a1916  
xsa187-4.6-0002-x86-segment-Bounds-check-accesses-to-emulation-ctx.patch
be9fe85d36c2c1fbca246c1f4d834c3ef11b6ab3d5467da0ac8c079aa5a68de9  
xsa187-4.7-0001-x86-shadow-Avoid-overflowing-sh_ctxt-seg.patch
36b22d6a168be39f31a1c1304f708269a2a10fe5105f7da4a06877d6059f1cd6  
xsa187-4.7-0002-x86-segment-Bounds-check-accesses-to-emulation-ctx.patch
$


DEPLOYMENT DURING EMBARGO
=

Deployment of the "reconfigure to use HAP" MITIGATION is NOT permitted
(except where all the affected systems and VMs are administered and
used only by organisations which are members of the Xen Project
Security Issues Predisclosure List).  Specifically, deployment on
public cloud systems is NOT permitted.

This is because the mitigation result in guest-visible changes.

Deployment of this mitigation is permitted only AFTER the embargo
ends.


Deployment of the PATCHES described above (or others which are
substantially similar) is permitted during the embargo, even on
public-facing systems with untrusted guest users and administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).


Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.


(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project 

[Xen-devel] Xen Security Advisory 188 (CVE-2016-7154) - use after free in FIFO event channel code

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Xen Security Advisory CVE-2016-7154 / XSA-188
  version 3

   use after free in FIFO event channel code

UPDATES IN VERSION 3


Public release.

ISSUE DESCRIPTION
=

When the EVTCHNOP_init_control operation is called with a bad guest
frame number, it takes an error path which frees a control structure
without also clearing the corresponding pointer.  Certain subsequent
operations (EVTCHNOP_expand_array or another EVTCHNOP_init_control),
upon finding the non-NULL pointer, continue operation assuming it
points to allocated memory.

IMPACT
==

A malicious guest administrator can crash the host, leading to a DoS.
Arbitrary code execution (and therefore privilege escalation), and
information leaks, cannot be excluded.

VULNERABLE SYSTEMS
==

Only Xen 4.4 is vulnerable.  Xen versions 4.5 and later as well as Xen
versions 4.3 and earlier are not vulnerable.

MITIGATION
==

There is no mitigation available.

CREDITS
===

This issue was discovered by Mikhail Gorobets of Advanced Threat
Research, Intel Security.

RESOLUTION
==

Applying the attached patch resolves this issue.

xsa188.patch   Xen 4.4.x

$ sha256sum xsa188*
9f374c2e1437ad71369f41275e7b333e7b7691a783ba693ee567c899bd78c722  xsa188.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJX0VLuAAoJEIP+FMlX6CvZNjYH/RVxqYegZpfj0aiT5pai/a0i
PgPSoMccGoSSVTXzivXUTZS3fTIqfTpd4SQHu2Q2dUqbb6zcPqd3NzF7Jl9IMwLk
JHZwPYXOsZ0D6thFAMYFpjHOWXv7+1Mw7Np82PaA2yAUad+kxUORiJeL1RAE6zG/
xsAR7PTl2mK1Ae9lqDtKLijn0cnicAYoKiSlta8M0T5Sp79CT3xsfHiBbaWUBCcI
gmOW76RUbfOwn2kmhFJ4X5bwSzEhM93pQu7hJCmuwAADc8ezEEFv2lsUm5W8hkmW
a8V2nuqM+prbxY8JI3XbKJm5YrmHQpnX4FiBn13DZeUsaukT4Q1EltP1z/XvJto=
=jzF5
-END PGP SIGNATURE-


xsa188.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel