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

[osstest service owner]

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

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. 104005

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 104005
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 104005
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 104005
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 104005

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   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-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 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  7f7d99048350935a394d07b98a13d7da9c4b0502
baseline version:
 libvirt  0735ddf744f95cd9f88c5f8465b1a64883710d37

Last test of basis   104005  2017-01-03 04:20:30 Z1 days
Testing same since   104021  2017-01-04 04:20:15 Z0 days1 attempts


People who touched revisions under test:
  John Ferlan 

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-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   pass
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd fail



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 7f7d99048350935a394d07b98a13d7da9c4b0502
Author: John Ferlan 
Date:   Thu Dec 22 07:12:49 2016 -0500

qemu: Don't assume secret provided for LUKS encryption

https://bugzilla.redhat.com/show_bug.cgi?id=1405269

If a secret was not provided for what was determined to be a LUKS
encrypted disk (during virStorageFileGetMetadata processing when
called from qemuDomainDetermineDiskChain as a result of hotplug
attach qemuDomainAttachDeviceDiskLive), then do not attempt to
look it up (avoiding a libvirtd crash) and do not 

Re: [Xen-devel] [RFC] kbdif: add multi-touch support

[Oleksandr Andrushchenko]

First of all, thank you for comments

On 01/04/2017 03:03 AM, Stefano Stabellini wrote:

On Tue, 3 Jan 2017, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

Signed-off-by: Oleksandr Andrushchenko 
---
  xen/include/public/io/kbdif.h | 64 +++
  1 file changed, 64 insertions(+)

diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
index 2d2aebd..ad94b53 100644
--- a/xen/include/public/io/kbdif.h
+++ b/xen/include/public/io/kbdif.h
@@ -45,6 +45,19 @@
   */
  #define XENKBD_TYPE_POS 4
  
+/*

+ * Multi-touch event
+ * Capable backend sets feature-multi-touch in xenstore.
+ * Frontend requests feature by setting request-multi-touch in xenstore.
+ * Frontend supports up to XENKBD_MT_NUM_DEV virtual multi-touch input devices,
+ * configured by the backend in xenstore under mt-%d folder, %d being
+ * a sequential number of the virtual input device:
+ *   o num-contacts - number of simultaneous touches supported
+ *   o width - width of the touch area in pixels
+ *   o height - height of the touch area in pixels

Please write down the max width and height supported by the protocol,
keeping in mind that motion events below use int32_t for coordinates.

I will put "width(height) of the... in pixels, 32-bit signed integer"


Are there any benefits of this compared to just setting up multiple kbd
connections, one per multi-touch device? The only benefit I can think of
is saving few pages.

Well, not only saving a few pages, but somewhat
simplifying handling of the protocol on both back and
front ends. But, you are probably right as current
protocol is capable of holding
(XENKBD_IN_RING_SIZE - XENKBD_IN_RING_OFFS) / XENKBD_IN_EVENT_SIZE ==
(2048 - 1024) / 40 = 25 incoming events which may not be
enough for multiple mt devices delivering hundreds of
events per second.
Will set-up dedicated rings per mt device then.
Will also remove
  uint8_t dev_idx;/* index of the multi-touch device */
as every device will have its own ring.
Will extend XenStore configuration for mt devices with:
 o page-ref (?)
 o page-gref
 o event-channel
as it is done by the Linux xen-kbdfront driver.

BTW, is there any reason we need "page-ref"? My understanding is
that the pair of page-gref + event-channel is enough to establish
and uniquely identify the connection.


+ */
+#define XENKBD_TYPE_MTOUCH  5
  struct xenkbd_motion
  {
  uint8_t type;/* XENKBD_TYPE_MOTION */
@@ -68,6 +81,56 @@ struct xenkbd_position
  int32_t rel_z;   /* relative Z motion (wheel) */
  };
  
+/* number of simultaneously supported multi-touch virtual input devices */

+#define XENKBD_MT_NUM_DEV   4

If it turns out that supporting multiple devices per connection is a
good idea, then I suggest that the max number of devices is a backend
property on xenstore.

Instead of setting the number of mt devices front can easily
find this value by reading "mt-%d" XenStore entries.
The requirement in the protocol is that "...%d being
a sequential number of the virtual input device". Thus,
first entry which we fail to sequentially read will
indicate end of configured devices. Of course,
xenbus_scanf return value needs to be checked if it
has failed because there is no such value in XenStore
or for any other reason.




+/* Sent when a new touch is made: touch is assigned a unique contact
+ * ID, sent with this and consequent events related to this touch.
+ * Contact ID will be reused after XENKBD_MT_EV_UP event.

Will be reused or can be reused?

I would probably say "may be reused" as it depends on how
and if new touches/contacts are made

  Please provide an example of a Contact
ID lifecycle.

Do you want it to be described in the protocol or just here?
If the latter then, for example, as Wayland documentation
describes it [1]:
"Touch interactions can consist of one or more contacts.
 For each contact, a series of events is generated, starting
 with a down event, followed by zero or more motion events,
 and ending with an up event. Events relating to the same
 contact point can be identified by the ID of the sequence."
So, if there is contact/touch a free Contact ID is assigned to
this contact(sequence) and it is "released" when contact is
done, e.g. after up event. From this point contact ID may be
reused.

I was basing the mt additions to the protocol on Wayland [1],
Linux [2] and Windows [3] multi-touch support, so those may
better explain the idea

What is the max Contact ID?


/* contact ID, [0; num-contacts - 1] */
num-contacts - number of simultaneous touches supported

+ */
+#define XENKBD_MT_EV_DOWN   0
+/* Touch point has been released */
+#define XENKBD_MT_EV_UP 1
+/* Touch point has changed its coordinate(s) */
+#define XENKBD_MT_EV_MOTION 2
+/* Input synchronization event: shows end of a set of events
+ * which logically belong together.
+ */
+#define XENKBD_MT_EV_SYN3
+/* Touch point 

Re: [Xen-devel] [PATCHv6 00/11] CONFIG_DEBUG_VIRTUAL for arm64

[Florian Fainelli]

On 01/03/2017 09:21 AM, Laura Abbott wrote:
> Happy New Year!
> 
> This is a very minor rebase from v5. It only moves a few headers around.
> I think this series should be ready to be queued up for 4.11.

FWIW:

Tested-by: Florian Fainelli 

How do we get this series included? I would like to get the ARM 32-bit
counterpart included as well (will resubmit rebased shortly), but I have
no clue which tree this should be going through.

Thanks!

> 
> Thanks,
> Laura
> 
> Laura Abbott (11):
>   lib/Kconfig.debug: Add ARCH_HAS_DEBUG_VIRTUAL
>   mm/cma: Cleanup highmem check
>   arm64: Move some macros under #ifndef __ASSEMBLY__
>   arm64: Add cast for virt_to_pfn
>   mm: Introduce lm_alias
>   arm64: Use __pa_symbol for kernel symbols
>   drivers: firmware: psci: Use __pa_symbol for kernel symbol
>   kexec: Switch to __pa_symbol
>   mm/kasan: Switch to using __pa_symbol and lm_alias
>   mm/usercopy: Switch to using lm_alias
>   arm64: Add support for CONFIG_DEBUG_VIRTUAL
> 
>  arch/arm64/Kconfig|  1 +
>  arch/arm64/include/asm/kvm_mmu.h  |  4 +-
>  arch/arm64/include/asm/memory.h   | 66 
> +--
>  arch/arm64/include/asm/mmu_context.h  |  6 +--
>  arch/arm64/include/asm/pgtable.h  |  2 +-
>  arch/arm64/kernel/acpi_parking_protocol.c |  3 +-
>  arch/arm64/kernel/cpu-reset.h |  2 +-
>  arch/arm64/kernel/cpufeature.c|  3 +-
>  arch/arm64/kernel/hibernate.c | 20 +++---
>  arch/arm64/kernel/insn.c  |  2 +-
>  arch/arm64/kernel/psci.c  |  3 +-
>  arch/arm64/kernel/setup.c |  9 +++--
>  arch/arm64/kernel/smp_spin_table.c|  3 +-
>  arch/arm64/kernel/vdso.c  |  8 +++-
>  arch/arm64/mm/Makefile|  2 +
>  arch/arm64/mm/init.c  | 12 +++---
>  arch/arm64/mm/kasan_init.c| 22 +++
>  arch/arm64/mm/mmu.c   | 33 ++--
>  arch/arm64/mm/physaddr.c  | 30 ++
>  arch/x86/Kconfig  |  1 +
>  drivers/firmware/psci.c   |  2 +-
>  include/linux/mm.h|  4 ++
>  kernel/kexec_core.c   |  2 +-
>  lib/Kconfig.debug |  5 ++-
>  mm/cma.c  | 15 +++
>  mm/kasan/kasan_init.c | 15 +++
>  mm/usercopy.c |  4 +-
>  27 files changed, 180 insertions(+), 99 deletions(-)
>  create mode 100644 arch/arm64/mm/physaddr.c
> 


-- 
Florian

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

[Xen-devel] [xen-unstable test] 104015: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 104004
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 104004
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 104004
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 104004
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 104004
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 104004
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 104004
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 104004
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 104004

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

version targeted for testing:
 xen  e34bc403c3c7dc0075111fa9cd29e2a385bc66ed
baseline version:
 xen  ee524f2bfa681ad116b8ae925fa8f3f18ee12ba5

Last test of basis   104004  2017-01-03 01:59:38 Z1 days
Failing since104008  2017-01-03 11:13:37 Z0 days2 attempts
Testing same since   104015  2017-01-03 19:45:46 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 
  Jan Beulich 
  Kevin Tian 
  Wei Liu 

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf ab50ab6ea159821d780be60759874dcf38835d1b
baseline version:
 ovmf 32ea56f0a65b80324e3e651432bdf496a6fc55b7

Last test of basis   104009  2017-01-03 11:44:38 Z0 days
Testing same since   104020  2017-01-04 00:45:08 Z0 days1 attempts


People who touched revisions under test:
  Jiaxin Wu 
  Wu Jiaxin 

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



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

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

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

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


Pushing revision :

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

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

[Xuquan (Quan Xu)]

On January 03, 2017 4:23 PM, Jan Beulich wrote:
 On 03.01.17 at 09:15,  wrote:
>
>>
>>>-Original Message-
>>>From: Jan Beulich [mailto:jbeul...@suse.com]
>>>Sent: Tuesday, January 03, 2017 3:35 PM
>>>To: Xuquan (Quan Xu)
>>>Cc: Andrew Cooper; George Dunlap; yang.zhang...@gmail.com; Chao
>Gao;
>>>Jun Nakajima; Kevin Tian; Lan Tianyu; xen-devel@lists.xen.org
>>>Subject: RE: [PATCH v4] x86/apicv: fix RTC periodic timer and apicv
>>>issue
>>>
>> On 23.12.16 at 13:24,  wrote:
 On December 22, 2016 4:12 PM, Jan Beulich wrote:
 On 21.12.16 at 06:44,  wrote:
>> --- a/xen/arch/x86/hvm/vmx/intr.c
>> +++ b/xen/arch/x86/hvm/vmx/intr.c
>> @@ -315,9 +315,13 @@ void vmx_intr_assist(void)
>>  * 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
>> +* Set eoi_exit_bitmap for intack.vector when it's higher
>> + than
>pending
>> +* periodic time interrupts. This way we can guarantee
>> + there's
>always a chance
>> +* to post periodic time interrupts when periodic time
>interrupts becomes the
>> +* highest one
>>  */
>>  if (pt_vector != -1)
>> -vmx_set_eoi_exit_bitmap(v, pt_vector);
>> +vmx_set_eoi_exit_bitmap(v, intack.vector);
>
>The comment does not clarify why max(pt_vector, intack.vector) is
>not needed. And I'd expect you to add ASSERT(intack.vector >=
>pt_vector) then, to prove this (and one might argue that this
>addition could be sufficient documentation, albeit perhaps a brief
>comment next to the assertion would help readers of this non-trivial
>piece of code).
>
 Kevin or Jan..
 ASSERT(...) is ok to me.. Could you help me give a brief comment?
>>>
>>>I don't see why you couldn't simply use what Kevin said in reply to my
>>>earlier question regarding the lack of max() here.
>>>
>>
>> What about """ Set EOI exit bitmap for any vector which may block
>> injection of pt_vector - give a chance to recognize pt_vector in
>> future intack and then do pt interrupts post"""?
>
>To me that doesn't explain the absence of max(pt_vector, intack.vector)
>here.
>

intack.vector is the highest priority vector..

Jan, thanks for your patience.. then, I'd say:
"""
intack.vector is the highest priority vector. So we set eoi_exit_bitmap
for intack.vector - give a chance to post periodic time interrupts when
periodic time interrupts become the highest one.
"""

If this is still not the comment you want, could you help me enhance it?

Quan 



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

Re: [Xen-devel] (no subject)

[Stefano Stabellini]

On Wed, 28 Dec 2016, Ronald Rojas wrote:
> The first 57 commits are merged from previous work done by 
> George Dunlap at (https://github.com/gwd/schedbench) and 
> implement manipulating Cpu pool. The last 2 commits merge 
> his work onto the Xen tree and implement finding system 
> information and throwing errors.

You need to add your Signed-off-by to all patches you touched for
copyright reasons. In fact, usually people add their Signed-off-by to
all patches. 

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

Re: [Xen-devel] [RFC] kbdif: add multi-touch support

[Stefano Stabellini]

On Tue, 3 Jan 2017, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko 
> 
> Signed-off-by: Oleksandr Andrushchenko 
> ---
>  xen/include/public/io/kbdif.h | 64 
> +++
>  1 file changed, 64 insertions(+)
> 
> diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
> index 2d2aebd..ad94b53 100644
> --- a/xen/include/public/io/kbdif.h
> +++ b/xen/include/public/io/kbdif.h
> @@ -45,6 +45,19 @@
>   */
>  #define XENKBD_TYPE_POS 4
>  
> +/*
> + * Multi-touch event
> + * Capable backend sets feature-multi-touch in xenstore.
> + * Frontend requests feature by setting request-multi-touch in xenstore.
> + * Frontend supports up to XENKBD_MT_NUM_DEV virtual multi-touch input 
> devices,
> + * configured by the backend in xenstore under mt-%d folder, %d being
> + * a sequential number of the virtual input device:
> + *   o num-contacts - number of simultaneous touches supported
> + *   o width - width of the touch area in pixels
> + *   o height - height of the touch area in pixels

Please write down the max width and height supported by the protocol,
keeping in mind that motion events below use int32_t for coordinates.

Are there any benefits of this compared to just setting up multiple kbd
connections, one per multi-touch device? The only benefit I can think of
is saving few pages.


> + */
> +#define XENKBD_TYPE_MTOUCH  5
>  struct xenkbd_motion
>  {
>  uint8_t type;/* XENKBD_TYPE_MOTION */
> @@ -68,6 +81,56 @@ struct xenkbd_position
>  int32_t rel_z;   /* relative Z motion (wheel) */
>  };
>  
> +/* number of simultaneously supported multi-touch virtual input devices */
> +#define XENKBD_MT_NUM_DEV   4

If it turns out that supporting multiple devices per connection is a
good idea, then I suggest that the max number of devices is a backend
property on xenstore.


> +/* Sent when a new touch is made: touch is assigned a unique contact
> + * ID, sent with this and consequent events related to this touch.
> + * Contact ID will be reused after XENKBD_MT_EV_UP event.

Will be reused or can be reused? Please provide an example of a Contact
ID lifecycle. What is the max Contact ID?


> + */
> +#define XENKBD_MT_EV_DOWN   0
> +/* Touch point has been released */
> +#define XENKBD_MT_EV_UP 1
> +/* Touch point has changed its coordinate(s) */
> +#define XENKBD_MT_EV_MOTION 2
> +/* Input synchronization event: shows end of a set of events
> + * which logically belong together.
> + */
> +#define XENKBD_MT_EV_SYN3
> +/* Touch point has changed its shape. Shape is approximated by an ellipse
> + * through the major and minor axis lengths: major is the longer diameter
> + * of the ellipse and minor is the shorter one. Center of the ellipse is
> + * reported via XENKBD_MT_EV_DOWN/XENKBD_MT_EV_MOTION events.
> + */
> +#define XENKBD_MT_EV_SHAPE  4
> +/* Touch point's shape has changed its orientation: calculated as a clockwise
> + * angle between the major axis of the ellipse and positive Y axis in 
> degrees,
> + * [-180; +180].
> + */
> +#define XENKBD_MT_EV_ORIENT 5
> +
> +struct xenkbd_mtouch {
> +uint8_t type; /* XENKBD_TYPE_MTOUCH */
> +uint8_t dev_idx;  /* index of the multi-touch device */
> +uint8_t event_type;   /* XENKBD_MT_EV_??? */
> +uint8_t reserved; /* reserved for the future use */
> +int32_t contact_id;   /* contact ID, [0; num-contacts - 1] */
> +union {
> +/* XENKBD_MT_EV_DOWN/XENKBD_MT_EV_MOTION */
> +struct {
> +int32_t abs_x;/* absolute X position, pixels */
> +int32_t abs_y;/* absolute Y position, pixels */
> +} pos;
> +/* XENKBD_MT_EV_SHAPE */
> +struct {
> +uint32_t major;   /* length of the major axis, pixels */
> +uint32_t minor;   /* length of the minor axis, pixels */
> +} shape;
> +/* XENKBD_MT_EV_ORIENT */
> +uint16_t orientation; /* clockwise angle of the major axis */
> +} u;
> +};

Need a binary representation.


>  #define XENKBD_IN_EVENT_SIZE 40
>  
>  union xenkbd_in_event
> @@ -76,6 +139,7 @@ union xenkbd_in_event
>  struct xenkbd_motion motion;
>  struct xenkbd_key key;
>  struct xenkbd_position pos;
> +struct xenkbd_mtouch mtouch;
>  char pad[XENKBD_IN_EVENT_SIZE];
>  };
>  
> -- 
> 2.7.4
> 

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

Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document

[Stefano Stabellini]

On Thu, 29 Dec 2016, Julien Grall wrote:
> Hi all,
> 
> The document below is an early version of a design
> proposal for PCI Passthrough in Xen. It aims to
> describe from an high level perspective the interaction
> with the different subsystems and how guest will be able
> to discover and access PCI.
> 
> I am aware that a similar design has been posted recently
> by Cavium (see [1]), however the approach to expose PCI
> to guest is different. We have request to run unmodified
> baremetal OS on Xen, a such guest would directly
> access the devices and no PV drivers will be used.
> 
> That's why this design is based on emulating a root controller.
> This also has the advantage to have the VM interface as close
> as baremetal allowing the guest to use firmware tables to discover
> the devices.
> 
> Currently on ARM, Xen does not have any knowledge about PCI devices.
> This means that IOMMU and interrupt controller (such as ITS)
> requiring specific configuration will not work with PCI even with
> DOM0.
> 
> The PCI Passthrough work could be divided in 2 phases:
>   * Phase 1: Register all PCI devices in Xen => will allow
>  to use ITS and SMMU with PCI in Xen
> * Phase 2: Assign devices to guests
> 
> This document aims to describe the 2 phases, but for now only phase
> 1 is fully described.
> 
> I have sent the design document to start to gather feedback on
> phase 1.
> 
> Cheers,
> 
> [1] https://lists.xen.org/archives/html/xen-devel/2016-12/msg00224.html 
> 
> 
> % PCI pass-through support on ARM
> % Julien Grall 
> % Draft A
> 
> # Preface
> 
> This document aims to describe the components required to enable PCI
> passthrough on ARM.
> 
> This is an early draft and some questions are still unanswered, when this is
> the case the text will contain XXX.
> 
> # Introduction
> 
> PCI passthrough allows to give control of physical PCI devices to guest. This
> means that the guest will have full and direct access to the PCI device.
> 
> ARM is supporting one kind of guest that is exploiting as much as possible
> virtualization support in hardware. The guest will rely on PV driver only
> for IO (e.g block, network), interrupts will come through the virtualized
> interrupt controller. This means that there are no big changes required
> within the kernel.
> 
> By consequence, it would be possible to replace PV drivers by assigning real
  ^ As a consequence


> devices to the guest for I/O access. Xen on ARM would therefore be able to
> run unmodified operating system.
> 
> To achieve this goal, it looks more sensible to go towards emulating the
> host bridge (we will go into more details later). A guest would be able
> to take advantage of the firmware tables and obviating the need for a specific
> driver for Xen.
> 
> Thus in this document we follow the emulated host bridge approach.
> 
> # PCI terminologies
> 
> Each PCI device under a host bridge is uniquely identified by its Requester ID
> (AKA RID). A Requester ID is a triplet of Bus number, Device number, and
> Function.
> 
> When the platform has multiple host bridges, the software can add fourth
   ^ a fourth

> number called Segment to differentiate host bridges. A PCI device will
> then uniquely by segment:bus:device:function (AKA SBDF).
> 
> So given a specific SBDF, it would be possible to find the host bridge and the
> RID associated to a PCI device.
> 
> # Interaction of the PCI subsystem with other subsystems
> 
> In order to have a PCI device fully working, Xen will need to configure
> other subsystems subsytems such as the SMMU and the Interrupt Controller.
  ^ repetition

> The interaction expected between the PCI subsystem and the other is:
> * Add a device
> * Remove a device
> * Assign a device to a guest
> * Deassign a device from a guest
> 
> XXX: Detail the interaction when assigning/deassigning device
> 
> The following subsections will briefly describe the interaction from an
> higher level perspective. Implementation details (callback, structure...)
> is out of scope.
> 
> ## SMMU
> 
> The SMMU will be used to isolate the PCI device when accessing the memory
> (for instance DMA and MSI Doorbells). Often the SMMU will be configured using
> a StreamID (SID) that can be deduced from the RID with the help of the 
> firmware
> tables (see below).
> 
> Whilst in theory all the memory transaction issued by a PCI device should
  ^ transactions

> go through the SMMU, on certain platforms some of the memory transaction may
^ transactions

> not reach the SMMU because they are interpreted by the host bridge. For
> instance this could happen if the MSI doorbell is built into the PCI host
> bridge. See [6] for more details.
> 
> XXX: I think this could be solved by using 

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

[osstest service owner]

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

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  e03d4e867456cf4e288aee79b04da05d3626c242
baseline version:
 xen  e34bc403c3c7dc0075111fa9cd29e2a385bc66ed

Last test of basis   104011  2017-01-03 14:01:44 Z0 days
Testing same since   104018  2017-01-03 22:01:00 Z0 days1 attempts


People who touched revisions under test:
  Stefano Stabellini 

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=e03d4e867456cf4e288aee79b04da05d3626c242
+ . ./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 
e03d4e867456cf4e288aee79b04da05d3626c242
+ branch=xen-unstable-smoke
+ revision=e03d4e867456cf4e288aee79b04da05d3626c242
+ . ./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.8-testing
+ '[' xe03d4e867456cf4e288aee79b04da05d3626c242 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : 

Re: [Xen-devel] [PATCH v2 3/4] arm, vgic_migrate_irq: take the right vgic lock

[Stefano Stabellini]

On Wed, 28 Dec 2016, Julien Grall wrote:
> Hi Stefano,
> 
> On 22/12/16 02:15, Stefano Stabellini wrote:
> > Always take the vgic lock of the old vcpu. When more than one irq
> > migration is requested before the first one completes, take the vgic
> > lock of the oldest vcpu.
> > 
> > Write the new vcpu id into the rank from vgic_migrate_irq, protected by
> > the oldest vgic vcpu lock.
> > 
> > Use barriers to ensure proper ordering between clearing inflight and
> > MIGRATING and setting vcpu to GIC_INVALID_VCPU.
> 
> The field p->status was designed to be accessed without any lock using *_bit
> helpers.
> 
> Currently vgic_migrate_irq is protected by the rank lock (an ASSERT would
> probably useful for documentation) and can only be called once at the time.
> 
> Let's take the following example to describe the problem:
> 1) IRQ has been injected into vCPU A (e.g present in the LR)
> 2) IRQ is migrated to vCPU B
> 3) IRQ is migrated to vCPU C
> 4) IRQ is EOIed by the guest
> 
> When vgic_irq_migrate_irq is called for the first time (step 2), the vCPU A
> vgic lock will be taken and GIC_IRQ_GUEST_MIGRATED will be set at the end. The
> second time (step 3), GIC_IRQ_GUEST_MIGRATING is already set, so the function
> will return directly no lock needed.

Right, but the caller, vgic_store_itargetsr, will still write to
rank->vcpu.


> So, I think the vgic lock taken is already correct.

The problem arises by 3) and 4) running simultaneously, and specifically
from the rank->vcpu write in vgic_store_itargetsr running concurrently
with gic_update_one_lr, as described in
alpine.DEB.2.10.1612191337370.13831@sstabellini-ThinkPad-X260:

  CPU0  CPU1

  --
vgic_migrate_irq C (does nothing)
  clear GIC_IRQ_GUEST_MIGRATING
  read rank->vcpu B
set rank->vcpu C
  irq_set_affinity B


Result: the irq physical affinity is B instead of C.

Please note that the new patch
(1483486167-24607-1-git-send-email-sstabell...@kernel.org) doesn't have
this problem because it removes the call to irq_set_affinity in
gic_update_one_lr.

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

[Xen-devel] [PATCH v3] xen/arm: fix rank/vgic lock inversion bug

[Stefano Stabellini]

Always set the new physical irq affinity at the beginning of
vgic_migrate_irq, in all cases.

No need to set physical irq affinity in gic_update_one_lr anymore,
solving the lock inversion problem.

After migrating an interrupt from vcpu/pcpu 0 to vcpu/pcpu 1, it is
possible to receive a physical interrupt on pcpu 1, which Xen is
supposed to inject into vcpu 1, before the LR on pcpu 0 has been
cleared. In this case the irq is still marked as
GIC_IRQ_GUEST_MIGRATING, and struct pending_irq is still "inflight" on
vcpu 0. As the irq cannot be "inflight" on vcpu 0 and vcpu 1
simultaneously, drop the interrupt.

Coverity-ID: 1381855
Coverity-ID: 1381853

Signed-off-by: Stefano Stabellini 
---
 xen/arch/arm/gic.c  |  6 +-
 xen/arch/arm/vgic.c | 19 +++
 2 files changed, 12 insertions(+), 13 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index a5348f2..767fc9e 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -504,11 +504,7 @@ static void gic_update_one_lr(struct vcpu *v, int i)
 gic_raise_guest_irq(v, irq, p->priority);
 else {
 list_del_init(>inflight);
-if ( test_and_clear_bit(GIC_IRQ_GUEST_MIGRATING, >status) )
-{
-struct vcpu *v_target = vgic_get_target_vcpu(v, irq);
-irq_set_affinity(p->desc, cpumask_of(v_target->processor));
-}
+clear_bit(GIC_IRQ_GUEST_MIGRATING, >status);
 }
 }
 }
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 364d5f0..11ffb9b 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -264,20 +264,17 @@ void vgic_migrate_irq(struct vcpu *old, struct vcpu *new, 
unsigned int irq)
 if ( p->desc == NULL )
 return;
 
+irq_set_affinity(p->desc, cpumask_of(new->processor));
+
 /* migration already in progress, no need to do anything */
 if ( test_bit(GIC_IRQ_GUEST_MIGRATING, >status) )
 return;
+if ( list_empty(>inflight) )
+return;
 
 perfc_incr(vgic_irq_migrates);
 
 spin_lock_irqsave(>arch.vgic.lock, flags);
-
-if ( list_empty(>inflight) )
-{
-irq_set_affinity(p->desc, cpumask_of(new->processor));
-spin_unlock_irqrestore(>arch.vgic.lock, flags);
-return;
-}
 /* If the IRQ is still lr_pending, re-inject it to the new vcpu */
 if ( !list_empty(>lr_queue) )
 {
@@ -286,7 +283,6 @@ void vgic_migrate_irq(struct vcpu *old, struct vcpu *new, 
unsigned int irq)
 list_del_init(>inflight);
 irq_set_affinity(p->desc, cpumask_of(new->processor));
 spin_unlock_irqrestore(>arch.vgic.lock, flags);
-vgic_vcpu_inject_irq(new, irq);
 return;
 }
 /* if the IRQ is in a GICH_LR register, set GIC_IRQ_GUEST_MIGRATING
@@ -495,6 +491,13 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int 
virq)
 return;
 }
 
+if ( test_bit(GIC_IRQ_GUEST_MIGRATING, >status) )
+{
+/* Drop the interrupt, because it is still inflight on another vcpu */
+spin_unlock_irqrestore(>arch.vgic.lock, flags);
+return;
+}
+
 set_bit(GIC_IRQ_GUEST_QUEUED, >status);
 
 if ( !list_empty(>inflight) )
-- 
1.9.1


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

Re: [Xen-devel] [PATCHv6 00/11] CONFIG_DEBUG_VIRTUAL for arm64

[Laura Abbott]

On 01/03/2017 02:56 PM, Florian Fainelli wrote:
> On 01/03/2017 09:21 AM, Laura Abbott wrote:
>> Happy New Year!
>>
>> This is a very minor rebase from v5. It only moves a few headers around.
>> I think this series should be ready to be queued up for 4.11.
> 
> FWIW:
> 
> Tested-by: Florian Fainelli 
> 

Thanks!

> How do we get this series included? I would like to get the ARM 32-bit
> counterpart included as well (will resubmit rebased shortly), but I have
> no clue which tree this should be going through.
> 

I was assuming this would go through the arm64 tree unless Catalin/Will
have an objection to that.

> Thanks!
> 
>>
>> Thanks,
>> Laura
>>
>> Laura Abbott (11):
>>   lib/Kconfig.debug: Add ARCH_HAS_DEBUG_VIRTUAL
>>   mm/cma: Cleanup highmem check
>>   arm64: Move some macros under #ifndef __ASSEMBLY__
>>   arm64: Add cast for virt_to_pfn
>>   mm: Introduce lm_alias
>>   arm64: Use __pa_symbol for kernel symbols
>>   drivers: firmware: psci: Use __pa_symbol for kernel symbol
>>   kexec: Switch to __pa_symbol
>>   mm/kasan: Switch to using __pa_symbol and lm_alias
>>   mm/usercopy: Switch to using lm_alias
>>   arm64: Add support for CONFIG_DEBUG_VIRTUAL
>>
>>  arch/arm64/Kconfig|  1 +
>>  arch/arm64/include/asm/kvm_mmu.h  |  4 +-
>>  arch/arm64/include/asm/memory.h   | 66 
>> +--
>>  arch/arm64/include/asm/mmu_context.h  |  6 +--
>>  arch/arm64/include/asm/pgtable.h  |  2 +-
>>  arch/arm64/kernel/acpi_parking_protocol.c |  3 +-
>>  arch/arm64/kernel/cpu-reset.h |  2 +-
>>  arch/arm64/kernel/cpufeature.c|  3 +-
>>  arch/arm64/kernel/hibernate.c | 20 +++---
>>  arch/arm64/kernel/insn.c  |  2 +-
>>  arch/arm64/kernel/psci.c  |  3 +-
>>  arch/arm64/kernel/setup.c |  9 +++--
>>  arch/arm64/kernel/smp_spin_table.c|  3 +-
>>  arch/arm64/kernel/vdso.c  |  8 +++-
>>  arch/arm64/mm/Makefile|  2 +
>>  arch/arm64/mm/init.c  | 12 +++---
>>  arch/arm64/mm/kasan_init.c| 22 +++
>>  arch/arm64/mm/mmu.c   | 33 ++--
>>  arch/arm64/mm/physaddr.c  | 30 ++
>>  arch/x86/Kconfig  |  1 +
>>  drivers/firmware/psci.c   |  2 +-
>>  include/linux/mm.h|  4 ++
>>  kernel/kexec_core.c   |  2 +-
>>  lib/Kconfig.debug |  5 ++-
>>  mm/cma.c  | 15 +++
>>  mm/kasan/kasan_init.c | 15 +++
>>  mm/usercopy.c |  4 +-
>>  27 files changed, 180 insertions(+), 99 deletions(-)
>>  create mode 100644 arch/arm64/mm/physaddr.c
>>
> 
> 


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

Re: [Xen-devel] [PATCH v2 1/4] xen/arm: fix GIC_INVALID_LR

[Stefano Stabellini]

On Wed, 28 Dec 2016, Julien Grall wrote:
> Hi Stefano,
> 
> On 22/12/16 02:15, Stefano Stabellini wrote:
> > GIC_INVALID_LR should be 0xff, but actually, defined as ~(uint8_t)0, is
> > 0x. Fix the problem by placing the ~ operator before the cast.
> > 
> > Signed-off-by: Stefano Stabellini 
> 
> Reviewed-by: Julien Grall 

Thanks, I committed the fix

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

Re: [Xen-devel] [PATCH v2 4/4] The locking order is: first rank lock, then vgic lock. The order is respected everywhere, except for gic_update_one_lr.

[Stefano Stabellini]

On Wed, 28 Dec 2016, Julien Grall wrote:
> Hi Stefano,
> 
> On 22/12/16 02:15, Stefano Stabellini wrote:
> > gic_update_one_lr is called with the vgic lock held, but it calls
> > vgic_get_target_vcpu, which tries to obtain the rank lock. This can
> > cause deadlocks.
> > 
> > We already have a version of vgic_get_target_vcpu that doesn't take the
> > rank lock: __vgic_get_target_vcpu.
> > 
> > Solve the lock inversion problem, by not taking the rank lock in
> > gic_update_one_lr (calling __vgic_get_target_vcpu instead of
> > vgic_get_target_vcpu).  This is safe, because vcpu target modifications
> > are protected by the same vgic vcpu lock.
> 
> I maintain what I said on the first version of this patch. All this patch
> could be simplified by moving the call to irq_set_affinity in
> vgic_irq_migrate.
> 
> There are no restriction to do that and no need to have any lock taken but the
> rank lock.
 
All right. I'll submit a patch that does exactly that. It is not
perfect, because it drops interrupts in the problematic scenario, but it
should be a good place to start for a technical discussion.

If it turns out that this is the best approach, we can come back to it.

Cheers,

Stefano

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

Re: [Xen-devel] [PATCH] x86/svm: Replace opencoded 1GB superpage check

[Boris Ostrovsky]

On 01/03/2017 12:53 PM, Andrew Cooper wrote:
> No functional change.
>
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Boris Ostrovsky 
> CC: Suravee Suthikulpanit 

Reviewed-by:  Boris Ostrovsky 

> ---
>  xen/arch/x86/hvm/svm/svm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> index 89daa39..04a7b60 100644
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -1473,7 +1473,7 @@ const struct hvm_function_table * __init start_svm(void)
>  
>  svm_function_table.hap_supported = !!cpu_has_svm_npt;
>  svm_function_table.hap_capabilities = HVM_HAP_SUPERPAGE_2MB |
> -((cpuid_edx(0x8001) & 0x0400) ? HVM_HAP_SUPERPAGE_1GB : 0);
> +(cpu_has_page1gb ? HVM_HAP_SUPERPAGE_1GB : 0);
>  
>  return _function_table;
>  }


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

Re: [Xen-devel] Future support of 5-level paging in Xen

[Boris Ostrovsky]

On 01/03/2017 12:32 PM, anshul makkar wrote:
>
>
> On 08/12/16 23:40, Boris Ostrovsky wrote:
>>
>>
>> On 12/08/2016 05:21 PM, Andrew Cooper wrote:
>>> On 08/12/2016 19:18, Stefano Stabellini wrote:
>>
>>>
 Of course even the largest virtual machine today (2TB on Amazon AFAIK)
 is not close to reaching the current memory limit, but it's just a
 matter of time.
>>>
>>> /me things Oracle will have something to say about this.  I'm sure
>>> there
>>> was talk about VMs larger than this at previous hackathons. XenServer
>>> functions (ish, so long as you don't migrate) with 6TB VMs, although
>>> starting and shutting them down feels like treacle.
>>
>>
>>
>> I've been working (on and off) with SGI to get one of their 32TB
>> boxes to boot and I don't think that works. We've fixed a couple of
>> bugs but I don't think Xen can boot with that much memory. We
>> successfully booted with just under 8TB but couldn't do it with the
>> full system. The machine has been taken from us for now so this work
>> is on hold.
>>
>> This is on OVM, which is 4.4-based, we haven't tried (IIRC) latest bits.
>>
>> (BTW, speaking of slow starting and shutting down very large guests ---
>> have you or anyone else had a chance to look at this? My
>> investigation initially pointed to scrubbing and then to an insane
>> number of hypercall preemptions in relinquish_memory()).
>>
> I had a quick look at it when I was working on support for large guest
> and found that scrubbing was indeed one of the issue. Just haven't got
> time to look at it in more details. Hopefully in near future, might
> work on it.

If you are interested I can share with you the prototype code that I
have for improving scrubbing performance. Ping me when/if you start
looking into this.

-boris

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

Re: [Xen-devel] How to find device name in order to fill STAO ACPI table

[Al Stone]

On 12/23/2016 05:51 AM, Roger Pau Monné wrote:
> Hello,
> 
> I've been looking into the STAO specification[0], because I think it would 
> also
> be useful for x86 PVHv2 Dom0, but I'm not really sure how is Xen supposed to
> use it.
> 
> Xen doesn't have an AML parser, so I'm not sure how is it supposed to guess
> the name of the devices it wants to hide from Dom0. Is there something I'm
> missing that can be used in order to find out the device name in the ACPI
> namespace without parsing AML tables?
> 
> Thanks, Roger.
> 
> [0] https://lists.xen.org/archives/html/xen-devel/2016-08/pdfYfOWKJ83jH.pdf
> 

I don't know if you've gotten a response to this or not yet

If you have an ACPI namespace available, then there had to be an AML parser
and/or interpreter available.  Once devices are enumerated in Linux, for
example, you can use the device info to get an ACPI handle which can then be
used to call the interpreter and have it return the ACPI path name.

If you don't have an ACPI namespace available,  you would have to look at
tools such as libacpi, or reuse parts of QEMU, or the upstream ACPICA
interpreter to be able to sort through the DSDT/SSDT tables containing the AML
that would contain the device names.  OpenBSD has such an interpreter, too.
You don't necessarily have to use the ACPI info, but you do need to be able
to read the contents of the DSDT/SSDTs to determine device names.

Stefano thought this through in more detail than I did when we were proposing
the STAO so he probably has additional insights.

-- 
ciao,
al
---
Al Stone
Software Engineer
Linaro Enterprise Group
al.st...@linaro.org
---

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

Re: [Xen-devel] [PATCH] uapi: use wildcards to list files

[Arnd Bergmann]

On Tuesday, January 3, 2017 3:35:44 PM CET Nicolas Dichtel wrote:
> Regularly, when a new header is created in include/uapi/, the developer
> forgets to add it in the corresponding Kbuild file. This error is usually
> detected after the release is out.
> 
> In fact, all headers under include/uapi/ should be exported, so let's
> use wildcards.

I think the idea makes a lot of sense: if a header is in uapi, we should
really export it. However, using a wildcard expression seems a bit
backwards here, I think we should make this implicit and not have the
Kbuild file at all.

The "header-y" syntax was originally added back when the uapi headers
were mixed with the internal headers in the same directory. After
David Howells introduced the separate directory for uapi, it has
become a bit redundant.

Can you try to modify scripts/Makefile.headersinst instead so we
can simply remove the Kbuild files entirely?

Arnd

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

Re: [Xen-devel] [PATCH v5 09/14] jump_label: port __jump_table to linker tables

[Luis R. Rodriguez]

On Thu, Dec 22, 2016 at 04:08:22PM +0200, Andy Shevchenko wrote:
> On Wed, 2016-12-21 at 18:38 -0800, Luis R. Rodriguez wrote:
> > Move the __jump_table from the a custom section solution
> > to a generic solution, this avoiding extra vmlinux.lds.h
> > customizations.
> > 
> > This also demos the use of the .data linker table and of
> > the shared asm call push_section_tbl().
> > 
> 
> >  {
> >     asm_volatile_goto("1:\n\t"
> >      WASM(nop) "\n\t"
> > -    ".pushsection __jump_table,  \"aw\"\n\t"
> > +    push_section_tbl_any(.data, __jump_table, aw)
> >      ".word 1b, %l[l_yes], %c0\n\t"
> >      ".popsection\n\t"
> >      : :  "i" (&((char *)key)[branch]) :  : l_yes);
> > @@ -26,7 +28,7 @@ static __always_inline bool
> > arch_static_branch_jump(struct static_key *key, bool
> >  {
> >     asm_volatile_goto("1:\n\t"
> >      WASM(b) " %l[l_yes]\n\t"
> > -    ".pushsection __jump_table,  \"aw\"\n\t"
> > +    push_section_tbl_any(.data, __jump_table, aw)
> >      ".word 1b, %l[l_yes], %c0\n\t"
> >      ".popsection\n\t"
> 
> Does it make sense to introduce something like
> 
> #define pop_section_tbl ".popsection\n\t"
> #define pop_section_tbl_any pop_section_tbl

Absolutely ! However this would be an evolution, and I would much
prefer to add this later as an atomic step later to enable other
users to also be using this shared macro. I did not have an immediate
need for a pop_section_tbl() macro as its not section specific.

  Luis

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

Re: [Xen-devel] [PATCH v5 04/14] tables.h: add linker table support

[Luis R. Rodriguez]

On Thu, Dec 22, 2016 at 03:58:18PM +0200, Andy Shevchenko wrote:
> On Wed, 2016-12-21 at 18:38 -0800, Luis R. Rodriguez wrote:
> > +#define LINKTABLE_FOR_EACH(pointer, tbl)   
> 
> Hmm... SOMEONE LIKES CAPITAL LETTERS FOR everything, right? :-)
>
> I would expect more standard linktable_for_each() macro

hpa had recommended this, if he prefers a lower case I can change that
but I really do consider this bikeshedding.

> Same to the rest of similar macros.

Same answer here.

> > +/**
> > + * LINKTABLE_RUN_ERR - run each linker table entry func and return
> > error if any
> > + *
> > + * @tbl: linker table
> > + * @func: structure name for the function name we want to call.
> > + * @args...: arguments to pass to func
> > + *
> > + * Example usage::
> > + *
> > + *   unsigned int err = LINKTABLE_RUN_ERR(frobnicator_fns,
> > some_run,);
> > + */
> > +#define LINKTABLE_RUN_ERR(tbl, func, args...)  
> > \
> > +({ 
> > \
> > +   size_t i;   
> > \
> > +   int err = 0;
> > \
> > +   for (i = 0; !err && i < LINKTABLE_SIZE(tbl); i++)   
> > \
> > +   err = (LINKTABLE_START(tbl)[i]).func (args);
> 
> 
> > \
> > +   err;
> 
> Indentation here a bit confusing.

Ah yes, good catch, fixed.

  Luis

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

Re: [Xen-devel] [PATCH v6 01/12] domctl: Add XEN_DOMCTL_acpi_access

[Konrad Rzeszutek Wilk]

> diff --git a/xen/arch/x86/hvm/acpi.c b/xen/arch/x86/hvm/acpi.c
> new file mode 100644
> index 000..04901c1
> --- /dev/null
> +++ b/xen/arch/x86/hvm/acpi.c
> @@ -0,0 +1,24 @@
> +/* acpi.c: ACPI access handling
> + *
> + * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.

2017.

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

Re: [Xen-devel] [PATCH v6 12/12] docs: Describe PVHv2's VCPU hotplug procedure

[Boris Ostrovsky]

On 01/03/2017 01:19 PM, Stefano Stabellini wrote:
> On Tue, 3 Jan 2017, Boris Ostrovsky wrote:
>> Signed-off-by: Boris Ostrovsky 
>> Reviewed-by: Konrad Rzeszutek Wilk 
>> ---
>> CC: George Dunlap 
>> CC: Konrad Rzeszutek Wilk 
>> CC: Stefano Stabellini 
>> CC: Tim Deegan 
>> ---
>> Changes in v6:
>> * No GPE0 update is needed anymore.
>>
>>  docs/misc/hvmlite.markdown | 11 +++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/docs/misc/hvmlite.markdown b/docs/misc/hvmlite.markdown
>> index 898b8ee..472edee 100644
>> --- a/docs/misc/hvmlite.markdown
>> +++ b/docs/misc/hvmlite.markdown
>> @@ -75,3 +75,14 @@ info structure that's passed at boot time (field 
>> rsdp_paddr).
>>  
>>  Description of paravirtualized devices will come from XenStore, just as it's
>>  done for HVM guests.
>> +
>> +## VCPU hotplug ##
>> +
>> +VCPU hotplug (e.g. 'xl vcpu-set  ') for PVHv2 guests
>> +follows ACPI model where change in domain's number of VCPUS (stored in
>> +domain.avail_vcpus) results in an SCI being sent to the guest. The guest
>> +then executes DSDT's PRSC method, updating MADT enable status for the
>> +affected VCPU.
>> +
>> +Updating VCPU number is achieved by having the toolstack issue a write to
>> +ACPI's XEN_ACPI_CPU_MAP.
> Looking at 1483452256-2879-10-git-send-email-boris.ostrov...@oracle.com,
> this is done via domctl. I think it is worth documenting that.

Will do.

-boirs

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

Re: [Xen-devel] Xen ARM - Exposing a PL011 to the guest

[Stefano Stabellini]

On Thu, 29 Dec 2016, Bhupinder Thakur wrote:
> On 28 December 2016 at 23:19, Julien Grall  wrote:
> > On 21/12/16 22:12, Stefano Stabellini wrote:
> >>
> >> On Wed, 21 Dec 2016, Julien Grall wrote:
> >>>
> >>> On 20/12/2016 20:53, Stefano Stabellini wrote:
> 
>  On Tue, 20 Dec 2016, Julien Grall wrote:
> >
> > On 19/12/2016 21:24, Stefano Stabellini wrote:
> >>
> >> On Mon, 19 Dec 2016, Christoffer Dall wrote:
> >>>
> >>> On Fri, Dec 16, 2016 at 05:03:13PM +, Julien Grall wrote:
> >>
> >> If we use hvm_params for this, we need two new hvm_params and Xen
> >> needs
> >> to unmap the pfn from the guest immediately, because we don't want the
> >> guest to have access to it.
> >
> >
> > If you unmap the pfn, the PV backend will not be able to request the
> > page
> > because there will be no translation available.
> >
> > So what you want to do is preventing the guest to at least write into
> > region
> > (not sure if it is worth to restrict read)
> 
> 
>  That's a good idea.
> 
> 
> > and unmap the page via the hypercall XENMEM_decrease_reservation.
> 
> 
>  That would be issued by the guest itself, right? To save address space?
> >>>
> >>>
> >>> Correct. The main use case today is ballooning, but guest could call it
> >>> on any
> >>> other RAM baked page.
> >>>
> >>> I was thinking about more about the protection needed. Technically the
> >>> data in
> >>> the ring are not trusted. So if the guest is messing up with it, it would
> >>> not
> >>> be a big issue. Or did I miss anything here?
> >>
> >>
> >> I understand that a guest would be smart to call
> >> XENMEM_decrease_reservation on the PV console page for pl011, but it
> >> cannot be a security measure, because, in fact, it needs to be called by
> >> the guest.  Of course, a malicious guest can simply not call
> >> XENMEM_decrease_reservation for it.
> >
> >
> > Sorry I was not clear. I was not suggested the guest to call
> > XENMEM_decrease_reservation on ring for security but a malicious guest
> > issuing the hypercall on the ring protected and replacing by another page.
> >
> > This is the exact same problem as the one I mentioned on the ITS thread. The
> > page live in guest memory but contains data that will only be touched by
> > Xen.
> >
> > If you remove those page from stage-2, the translation IPA -> MFN will be
> > lost unless you store somewhere else. You would have to do it per-page as
> > the buffer will use contiguous IPA but potentially noncontiguous MFN.
> >
> > In the case of ITS the memory is provisioned by the guest. So there are not
> > much to do there except adding protection in stage-2 such as write
> > protection and preventing the guest to unmap it. However for the pl011 ring,
> > as Andrew pointed on IRC, what we need to do is accounting this page to the
> > domain memory. No mapping is necessary in stage-2.
> 
> Please clarify what is meant by that no stage-2 mapping is required.
> Does it mean that no stage-2 mapping is required for the guest as it
> never needs to access this page?

That's right.


> However, the Xen HYP will need the stage-2 mapping to find out the
> pl011 PFN --> physical MFN mapping so that it can map the page to its
> own address space. Currently, I am using prepare_ring_for_helper () to
> map the pl011 PFN (passed via hvm call) ---> phyiscal MFN ---> Xen HYP
> VA.

I am not sure what Julien had in mind exactly. I like the idea of not
mapping the page at stage-2, but it is true that many interfaces expect
pfns. If Xen is the one to allocate the pl011 PV console page, then Xen
knows the mfn and could use it to map the page, instead of the pfn.
However, the PV console backend also needs to map the same page, and it
currently does that by calling xc_map_foreign_range, which I believe
also expect a pfn.

So maybe it is easier to use write-protection in stage-2 (as for ITS),
unless Julien has a better idea?

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

Re: [Xen-devel] [RFC] kbdif: add multi-touch support

[Oleksandr Andrushchenko]

On 01/03/2017 06:28 PM, Jan Beulich wrote:

On 03.01.17 at 16:39,  wrote:

--- a/xen/include/public/io/kbdif.h
+++ b/xen/include/public/io/kbdif.h
@@ -45,6 +45,19 @@
   */
  #define XENKBD_TYPE_POS 4
  
+/*

+ * Multi-touch event
+ * Capable backend sets feature-multi-touch in xenstore.
+ * Frontend requests feature by setting request-multi-touch in xenstore.
+ * Frontend supports up to XENKBD_MT_NUM_DEV virtual multi-touch input devices,
+ * configured by the backend in xenstore under mt-%d folder, %d being
+ * a sequential number of the virtual input device:
+ *   o num-contacts - number of simultaneous touches supported
+ *   o width - width of the touch area in pixels
+ *   o height - height of the touch area in pixels
+ */
+#define XENKBD_TYPE_MTOUCH  5
+
  struct xenkbd_motion
  {
  uint8_t type;/* XENKBD_TYPE_MOTION */
@@ -68,6 +81,56 @@ struct xenkbd_position
  int32_t rel_z;   /* relative Z motion (wheel) */
  };
  
+/* number of simultaneously supported multi-touch virtual input devices */

+#define XENKBD_MT_NUM_DEV   4

Why is this limit needed? There's no use of it within the other
interface additions you make.

Jan

Well, the only reason for that was a shy attempt to somewhat simplify
changes to the existing frontend, e.g. handling fixed number of mt input
devices rather than allocating all those dynamically, finding the number
of devices configured at run-time etc.
I will happily remove this limitation though

Oleksandr


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

Re: [Xen-devel] Xen ARM - Exposing a PL011 to the guest

[Stefano Stabellini]

On Wed, 28 Dec 2016, Julien Grall wrote:
> Hi Stefano,
> 
> On 21/12/16 22:12, Stefano Stabellini wrote:
> > On Wed, 21 Dec 2016, Julien Grall wrote:
> > > On 20/12/2016 20:53, Stefano Stabellini wrote:
> > > > On Tue, 20 Dec 2016, Julien Grall wrote:
> > > > > On 19/12/2016 21:24, Stefano Stabellini wrote:
> > > > > > On Mon, 19 Dec 2016, Christoffer Dall wrote:
> > > > > > > On Fri, Dec 16, 2016 at 05:03:13PM +, Julien Grall wrote:
> > > > > > If we use hvm_params for this, we need two new hvm_params and Xen
> > > > > > needs
> > > > > > to unmap the pfn from the guest immediately, because we don't want
> > > > > > the
> > > > > > guest to have access to it.
> > > > > 
> > > > > If you unmap the pfn, the PV backend will not be able to request the
> > > > > page
> > > > > because there will be no translation available.
> > > > > 
> > > > > So what you want to do is preventing the guest to at least write into
> > > > > region
> > > > > (not sure if it is worth to restrict read)
> > > > 
> > > > That's a good idea.
> > > > 
> > > > 
> > > > > and unmap the page via the hypercall XENMEM_decrease_reservation.
> > > > 
> > > > That would be issued by the guest itself, right? To save address space?
> > > 
> > > Correct. The main use case today is ballooning, but guest could call it on
> > > any
> > > other RAM baked page.
> > > 
> > > I was thinking about more about the protection needed. Technically the
> > > data in
> > > the ring are not trusted. So if the guest is messing up with it, it would
> > > not
> > > be a big issue. Or did I miss anything here?
> > 
> > I understand that a guest would be smart to call
> > XENMEM_decrease_reservation on the PV console page for pl011, but it
> > cannot be a security measure, because, in fact, it needs to be called by
> > the guest.  Of course, a malicious guest can simply not call
> > XENMEM_decrease_reservation for it.
> 
> Sorry I was not clear. I was not suggested the guest to call
> XENMEM_decrease_reservation on ring for security but a malicious guest issuing
> the hypercall on the ring protected and replacing by another page.
> 
> This is the exact same problem as the one I mentioned on the ITS thread. The
> page live in guest memory but contains data that will only be touched by Xen.
> 
> If you remove those page from stage-2, the translation IPA -> MFN will be lost
> unless you store somewhere else. You would have to do it per-page as the
> buffer will use contiguous IPA but potentially noncontiguous MFN.
> 
> In the case of ITS the memory is provisioned by the guest. So there are not
> much to do there except adding protection in stage-2 such as write protection
> and preventing the guest to unmap it. However for the pl011 ring, as Andrew
> pointed on IRC, what we need to do is accounting this page to the domain
> memory. No mapping is necessary in stage-2.

Thanks Julien for the explanation. I think you are right.

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

Re: [Xen-devel] [PATCH v6 12/12] docs: Describe PVHv2's VCPU hotplug procedure

[Boris Ostrovsky]

On 01/03/2017 11:58 AM, Jan Beulich wrote:
 On 03.01.17 at 15:04,  wrote:
>> --- a/docs/misc/hvmlite.markdown
>> +++ b/docs/misc/hvmlite.markdown
>> @@ -75,3 +75,14 @@ info structure that's passed at boot time (field 
>> rsdp_paddr).
>>  
>>  Description of paravirtualized devices will come from XenStore, just as it's
>>  done for HVM guests.
>> +
>> +## VCPU hotplug ##
>> +
>> +VCPU hotplug (e.g. 'xl vcpu-set  ') for PVHv2 guests
>> +follows ACPI model where change in domain's number of VCPUS (stored in
>> +domain.avail_vcpus) results in an SCI being sent to the guest. The guest
>> +then executes DSDT's PRSC method, updating MADT enable status for the
>> +affected VCPU.
>> +
>> +Updating VCPU number is achieved by having the toolstack issue a write to
>> +ACPI's XEN_ACPI_CPU_MAP.
> Is any of this valid anymore in the context of the recent discussion?
> Perhaps even wider - how much of this series is applicable if pCPU
> hotplug is to use the normal ACPI code path? 

pCPU hotplug is not going to use this path because it would not be
executing PRSC method that we (Xen toolstack) provide.


> I hope the plan is not
> to have different vCPU hotplug for DomU and Dom0?

That was not the plan. But I haven't thought of dom0 not being able to
execute PRSC.

-boris



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

Re: [Xen-devel] Xen: ARM: Support for mapping ECAM PCIe Config Space Specified In Static ACPI Table

[Stefano Stabellini]

On Wed, 28 Dec 2016, Julien Grall wrote:
> (CC Andrew and Jan)
> 
> Hi Stefano,
> 
> On 20/12/16 22:33, Stefano Stabellini wrote:
> > On Tue, 20 Dec 2016, Julien Grall wrote:
> > > Hi Stefano,
> > > 
> > > On 20/12/2016 00:54, Stefano Stabellini wrote:
> > > > On Mon, 19 Dec 2016, Julien Grall wrote:
> > > > > On 16/12/2016 15:49, Julien Grall wrote:
> > > > > > On 14/12/16 08:00, Jiandi An wrote:
> > > > > > > Xen currently doesn't map ECAM space specified in static ACPI
> > > > > > > table.
> > > > > > > Seeking opinion on how this should be handled properly.
> > > > > > > Each root complex ECAM region takes up 64K 4K pages (256MB).
> > > > > > > For some platforms there might be multiple root complexes.
> > > > > > > Is the plan to map all at once?Julien has mentioned support
> > > > > > > for mapping ECAM may come when support for PCI passthrough is
> > > > > > > added, is that right? What mechanism will it be? Will Xen or
> > > > > > > dom0 be the one that parses the staic ACPI tables and map the ECAM
> > > > > > > space?
> > > > > > 
> > > > > > For performance reason, each ECAM region would need to be mapped at
> > > > > > once, so the stage-2 page table could take advantage of superpage
> > > > > > (it
> > > > > > will mostly be 2MB).
> > > > > > 
> > > > > > Now, I don't think Xen should map the ECAM region in stage-2 before
> > > > > > hand. All the regions may not be described in the MCFG and I would
> > > > > > like
> > > > > > to see a generic solution.
> > > > > > 
> > > > > > Looking at the code (see pci_create_ecam_create in
> > > > > > drivers/pci/ecam.c),
> > > > > > ioremap is used. I believe the problem is the same for the 2 other
> > > > > > threads you sent ( [1] and [2]).
> > > > > > 
> > > > > > So it might be good to look at hooking up a call to
> > > > > > XENMEM_add_to_physmap_range in ioremap.
> > > > > > 
> > > > > > Any opinions?
> > > > > 
> > > > > I thought a bit more about it and I realized we need to be cautious on
> > > > > how
> > > > > to
> > > > > proceed here.
> > > > > 
> > > > > DOM0 will have a mix of real devices and emulated devices (e.g some
> > > > > part
> > > > > of
> > > > > the GIC). For the emulated devices, DOM0 should not call
> > > > > XENMEM_add_to_physmap_range. However, DOM0 is not aware what is
> > > > > emulated
> > > > > or
> > > > > not, so even the current approach (hooking up in platform device)
> > > > > seems
> > > > > fragile. We rely on Xen to say "this region cannot be mapped".
> > > > 
> > > > You are right that Dom0 doesn't and shouldn't be able to tell the
> > > > difference between emulated and real devices. But I don't think that
> > > > should be a problem because Xen knows exactly if an MMIO region belongs
> > > > to an emulated device thanks to the 1:1 mapping. When
> > > > XENMEM_add_to_physmap_range is called, Xen can check whether the region
> > > > belongs to an emulated device or a real device, mapping memory only if
> > > > it belongs to a real device. No need to report errors: from Dom0 point
> > > > of view the operation succeeded either way.
> > > 
> > > By no need to report errors, did you mean Xen failing, or DOM0 failing?
> > 
> > Sorry I haven't been clear. I meant that if Dom0 asks Xen to map a
> > region which belongs to an emulated device, of course Xen won't actually
> > do any mappings, but it is not an error condition. Xen shouldn't return
> > error for mappings that hasn't performed because the region belongs to
> > an emulated device.
> 
> I disagree here. You make the assumption that DOM0 will always issue the
> hypercall with MFN == GFN.
> 
> Today we only check whether the region is allowed in iomem. If it is not
> allowed we will ignore the request and report as "succeeded". But it does not
> mean there will be an emulation behind nor DOM0 decided to map the region with
> MFN != GFN.
> 
> So DOM0 expects the region to be mapped, but actually it may not be done by
> the hypervisor. It will be a pain to debug it because the error may come up
> much later.
> 
> The description of the hypercall is "the region is mapped in Stage-2 using the
> memory attribute Device-nGnRE". Nowhere it is stated the region will not be
> mapped if emulated nor must be called MFN == GFN.
> 
> Now, we have two hypercalls XEN_DOMCTL_memory_mapping and
> XENMEM_add_to_physmap_range having two distinct behavior when mapping an MMIO
> into a guest.
> 
> We should at least return an error, even if DOM0 decides to ignore it.
> 
> I am open to any other suggestion. But I don't think the hypercall should
> silently ignore a request as it is done today.

I agree that assigning clear and unequivocal error codes is a good idea.
The error code for "failure to map" should be different from the error
code for "this belongs to an emulated device".


> > Of course, Xen should report errors for any genuine error conditions.
> > 
> > 
> > > I looked at the code (map_dev_mmio_region), we check whether DOM0 is
> > > allowed
> > > to access the iomem. 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-multivcpu  6 xen-bootfail REGR. vs. 104004
 test-armhf-armhf-xl 15 guest-start/debian.repeat fail REGR. vs. 104004

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 16 guest-start.2fail REGR. vs. 104002
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 104004
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 104004
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 104004
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 104004
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 104004
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 104004
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 104004
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 104004
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 104004

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

version targeted for testing:
 xen  6d9d597713ad8ef1d83d6479f5864818a177db20
baseline version:
 xen  ee524f2bfa681ad116b8ae925fa8f3f18ee12ba5

Last test of basis   104004  2017-01-03 01:59:38 Z0 days
Testing same since   104008  2017-01-03 11:13:37 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 
  Jan Beulich 
  Kevin Tian 

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

Re: [Xen-devel] [PATCH v4 14/14] xen/x86: setup PVHv2 Dom0 ACPI tables

[Boris Ostrovsky]

> We can provide a crafted MADT that reflects the number of vCPUs available to
> Dom0 at boot time, let Dom0 find the Processor objects in the ACPI namespace
> and perform pCPU hotplug as it's been done until now. Then for Dom0 vCPU
> hotplug we would need to use the hypercall interface as it's used by classic 
> PV
> guests, because AFAICT there's no way we can provide Dom0 with a PRST/PRSC
> that's valid for both vCPUs and pCPUs.

If we have a PV-like interface for bringing up vCPUs for dom0 then
what's the point of doing it differently for domUs?

-boris



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

Re: [Xen-devel] Xen: Support for mapping OperationRegion in ACPI ASL

[Stefano Stabellini]

On Thu, 22 Dec 2016, Jan Beulich wrote:
> >>> On 20.12.16 at 23:50,  wrote:
> > On Tue, 20 Dec 2016, Jan Beulich wrote:
> >> >>> On 20.12.16 at 00:01,  wrote:
> >> > This is actually not an ARM specific question, so changing the subject
> >> > and CC'ing more people.
> >> > 
> >> > On Wed, 14 Dec 2016, Konrad Rzeszutek Wilk wrote:
> >> >> On Tue, Dec 13, 2016 at 07:14:27PM -0600, Jiandi An wrote:
> >> >> > Xen currently does not handle mapping of MMIO regions specified under 
> >> > OperationRegion in ACPI ASL.  OperationRegion is well defined in ACPI 
> >> > specification.  I'm seeking for architectural direction on adding 
> >> > support 
> > for 
> >> > mapping OperationRegion.
> >> >> > 
> >> >> > Some context here.  Mapping of resources specificed under _CRS in 
> >> >> > ACPI is 
> >> > handled by dom0 requesting Xen to map as platform devices are added.  
> >> > https://lwn.net/Articles/674666/ provided service xen_map_device_mmio() 
> >> > in 
> >> > dom0 to call Xen to map and it's done so by registering 
> >> > xen_platform_notifier() platform bus driver.  This covers the platform 
> >> > devices.
> >> >> > 
> >> >> > The OperationRegion access in dom0 is in acpica path.  The following 
> >> >> > is a 
> >> > stack of the code path where OperationRegion is parsed.  
> >> 
> >> But aren't such regions required to be claimed by resource
> >> declarations elsewhere? I don't think the mapping (into the p2m)
> >> should happen during an access attempt, but much earlier. But
> >> perhaps I'm missing some context ...
> > 
> > Please correct me if I am wrong, but we are talking about ACPI
> > initialization here. In fact, acpi_init was one of the first functions
> > in the callstack of the previous email. So yes, we are trying to map the
> > regions when they are discovered during ACPI initialization, which is as
> > early as possible I think.
> 
> Yes and no: Yes - we are in the context of acpi_init(). But no, the
> mapping did not get established prior to the first access, or else
> the call stack wouldn't include
> 
> acpi_ex_system_memory_space_handler+0x378/0x424
> acpi_ev_address_space_dispatch+0x294/0x310
> acpi_ex_access_region+0x3c0/0x468
> acpi_ex_field_datum_io+0x14c/0x380
> acpi_ex_extract_from_field+0xe8/0x2f4
> acpi_ex_read_data_from_field+0x330/0x38c
> 
> I would expect resource claiming to precede this, and that would
> then be where the mapping should also be requested.

Good point.

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

Re: [Xen-devel] How to find device name in order to fill STAO ACPI table

[Stefano Stabellini]

On Fri, 23 Dec 2016, Roger Pau Monné wrote:
> Hello,
> 
> I've been looking into the STAO specification[0], because I think it would 
> also
> be useful for x86 PVHv2 Dom0, but I'm not really sure how is Xen supposed to
> use it.
> 
> Xen doesn't have an AML parser, so I'm not sure how is it supposed to guess
> the name of the devices it wants to hide from Dom0. Is there something I'm
> missing that can be used in order to find out the device name in the ACPI
> namespace without parsing AML tables?
> 
> Thanks, Roger.
> 
> [0] https://lists.xen.org/archives/html/xen-devel/2016-08/pdfYfOWKJ83jH.pdf

Hi Roger,

Happy New Year!

There is no silver bullet here. However, we discussed several
alternative options in the past:

o per platform hardcoded paths
  we could have a per platform static table in Xen to store namespace
  paths to hide via STAO

o find out namespace paths without an interpreter
  Al Stone described a way to determine namespace paths without a full
  interpreter. Copy/pasting from 547f8a54.6060...@linaro.org:

> > Okey dokey.  The basic idea is that objects in the ACPI namespace
> > (i.e., everything in the summation of the DSDT and any SSDTs) can
> > have an identifier describing what it is, similar to the compatible
> > property in DT.  There are three methods involved: _HID (hardware ID),
> > _CID (compatible ID), or _CLS; one or more of these must be present
> > for every namespace object needed by a device driver -- it's how the
> > driver probe finds the right object.
> > 
> > While it's a bit fiddly, it is possible and reasonably straightforward
> > to hunt down the _HID/_CID values in the DSDT without running the ACPI
> > interpreter.  If we can do that, I think we can determine the path name
> > since we can treat the DSDT as a static data structure for this usage.

  In the end, we didn't use this strategy and opted for a special flag
  for the UART.


If neither of these options are good enough for your use case, then it
is worth considering updating the STAO specification to include other
ways to match devices to hide from OSPM. For example:

o new ad hoc flag, as for the UART
  if your device is easily identifiable via another table, like the UART
  is with the SPCR table, then we could add another special flag to
  STAO. The flag would be something like "hide the device described in
  XXX".

o something based on BDF
  if your goal is to hide a PCI device, then we could add a list of PCI
  BDFs to hide. It would be up to the OSPM to match these BDFs with
  their corresponding DSDT entries and ignore them.

These two are just ideas, Al and Graeme might have better ones. it would
be helpful to know your use case in details to be able to suggest an
appropriate solution.___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xsm: allow relevant permission during migrate and gpu-passthrough.

[Daniel De Graaf]

On 12/19/2016 11:03 PM, Doug Goldstein wrote:

On 12/19/16 10:02 AM, Doug Goldstein wrote:

On 12/14/16 3:09 PM, Daniel De Graaf wrote:

On 12/12/2016 09:00 AM, Anshul Makkar wrote:

During guest migrate allow permission to prevent
spurious page faults.
Prevents these errors:
d73: Non-privileged (73) attempt to map I/O space 

avc: denied  { set_misc_info } for domid=0 target=11
scontext=system_u:system_r:dom0_t
tcontext=system_u:system_r:domU_t tclass=domain

GPU passthrough for hvm guest:
avc:  denied  { send_irq } for domid=0 target=10
scontext=system_u:system_r:dom0_t
tcontext=system_u:system_r:domU_t tclass=hvm

Signed-off-by: Anshul Makkar 


Acked-by: Daniel De Graaf 



Daniel,

Should this be backported to 4.8?



Yes, I would consider this a candidate for backporting.


FWIW, Daniel's email is bouncing. Anshul, do you want to test/confirm?


I believe this is fixed now; my email server was changed while I was gone
for the holiday and apparently the change was not tested properly.

--
Daniel De Graaf
National Security Agency

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

Re: [Xen-devel] [PATCH v6 01/12] domctl: Add XEN_DOMCTL_acpi_access

[Daniel De Graaf]

On 01/03/2017 09:04 AM, Boris Ostrovsky wrote:

This domctl will allow toolstack to read and write some
ACPI registers. It will be available to both x86 and ARM
but will be implemented first only for x86

Signed-off-by: Boris Ostrovsky 


Acked-by: Daniel De Graaf 



--
Daniel De Graaf
National Security Agency

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

Re: [Xen-devel] How to find device name in order to fill STAO ACPI table

[G Gregory]

On 3 January 2017 at 17:50, Al Stone  wrote:
> On 12/23/2016 05:51 AM, Roger Pau Monné wrote:
>> Hello,
>>
>> I've been looking into the STAO specification[0], because I think it would 
>> also
>> be useful for x86 PVHv2 Dom0, but I'm not really sure how is Xen supposed to
>> use it.
>>
>> Xen doesn't have an AML parser, so I'm not sure how is it supposed to guess
>> the name of the devices it wants to hide from Dom0. Is there something I'm
>> missing that can be used in order to find out the device name in the ACPI
>> namespace without parsing AML tables?
>>
>> Thanks, Roger.
>>
>> [0] https://lists.xen.org/archives/html/xen-devel/2016-08/pdfYfOWKJ83jH.pdf
>>
>
> I don't know if you've gotten a response to this or not yet
>
> If you have an ACPI namespace available, then there had to be an AML parser
> and/or interpreter available.  Once devices are enumerated in Linux, for
> example, you can use the device info to get an ACPI handle which can then be
> used to call the interpreter and have it return the ACPI path name.
>
> If you don't have an ACPI namespace available,  you would have to look at
> tools such as libacpi, or reuse parts of QEMU, or the upstream ACPICA
> interpreter to be able to sort through the DSDT/SSDT tables containing the AML
> that would contain the device names.  OpenBSD has such an interpreter, too.
> You don't necessarily have to use the ACPI info, but you do need to be able
> to read the contents of the DSDT/SSDTs to determine device names.
>
> Stefano thought this through in more detail than I did when we were proposing
> the STAO so he probably has additional insights.
>
Back when we originally discussed this I asked the question and the
Xen guys told me that Xen would keep a table per motherboard as there
wasn't a generic discoverable way to find the devices that need
hidden.

Graeme

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

Re: [Xen-devel] [PATCH v6 12/12] docs: Describe PVHv2's VCPU hotplug procedure

[Stefano Stabellini]

On Tue, 3 Jan 2017, Boris Ostrovsky wrote:
> Signed-off-by: Boris Ostrovsky 
> Reviewed-by: Konrad Rzeszutek Wilk 
> ---
> CC: George Dunlap 
> CC: Konrad Rzeszutek Wilk 
> CC: Stefano Stabellini 
> CC: Tim Deegan 
> ---
> Changes in v6:
> * No GPE0 update is needed anymore.
> 
>  docs/misc/hvmlite.markdown | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/docs/misc/hvmlite.markdown b/docs/misc/hvmlite.markdown
> index 898b8ee..472edee 100644
> --- a/docs/misc/hvmlite.markdown
> +++ b/docs/misc/hvmlite.markdown
> @@ -75,3 +75,14 @@ info structure that's passed at boot time (field 
> rsdp_paddr).
>  
>  Description of paravirtualized devices will come from XenStore, just as it's
>  done for HVM guests.
> +
> +## VCPU hotplug ##
> +
> +VCPU hotplug (e.g. 'xl vcpu-set  ') for PVHv2 guests
> +follows ACPI model where change in domain's number of VCPUS (stored in
> +domain.avail_vcpus) results in an SCI being sent to the guest. The guest
> +then executes DSDT's PRSC method, updating MADT enable status for the
> +affected VCPU.
> +
> +Updating VCPU number is achieved by having the toolstack issue a write to
> +ACPI's XEN_ACPI_CPU_MAP.

Looking at 1483452256-2879-10-git-send-email-boris.ostrov...@oracle.com,
this is done via domctl. I think it is worth documenting that.

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

Re: [Xen-devel] [PATCH V2] Xen: ARM: Zero reserved fields of xatp before making hypervisor call

[Stefano Stabellini]

On Mon, 2 Jan 2017, Juergen Gross wrote:
> On 28/12/16 01:47, Jiandi An wrote:
> > Ensure all reserved fields of xatp are zero before making
> > hypervisor call to XEN in xen_map_device_mmio().
> > xenmem_add_to_physmap_one() in XEN fails the mapping request if
> > extra.res reserved field in xatp is not zero for XENMAPSPACE_dev_mmio
> > request.
> > 
> > Signed-off-by: Jiandi An 
> > ---
> > Changed zeroing xatp to a static initialization
> > of .domid and .space for xatp.
> > 
> >  drivers/xen/arm-device.c | 8 +---
> >  1 file changed, 5 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/xen/arm-device.c b/drivers/xen/arm-device.c
> > index 778acf8..85dd20e 100644
> > --- a/drivers/xen/arm-device.c
> > +++ b/drivers/xen/arm-device.c
> > @@ -58,9 +58,13 @@ static int xen_map_device_mmio(const struct resource 
> > *resources,
> > xen_pfn_t *gpfns;
> > xen_ulong_t *idxs;
> > int *errs;
> > -   struct xen_add_to_physmap_range xatp;
> >  
> > for (i = 0; i < count; i++) {
> > +   struct xen_add_to_physmap_range xatp = {
> > +   .domid = DOMID_SELF,
> > +   .space = XENMAPSPACE_dev_mmio
> > +   };
> > +
> 
> I still don't see the need to re-initialize the input parts of xatp
> on each loop iteration unless you can show the need for it (e.g. a
> buggy hypervisor version not conforming to the interface specification).
> 
> OTOH I don't feel really strong about it and let Stefano being the
> maintainer for the ARM parts decide.

I don't feel strongly about this either - I think this patch is good
enough. I'll apply to xentip.

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

Re: [Xen-devel] [RFC] Xen PV Drivers Lifecycle

[Stefano Stabellini]

On Wed, 28 Dec 2016, George Dunlap wrote:
> On Tue, Dec 20, 2016 at 11:09 PM, Stefano Stabellini
>  wrote:
> > On Tue, 20 Dec 2016, Jan Beulich wrote:
> >> >>> On 20.12.16 at 01:47,  wrote:
> >> > ## Design Phase
> >> >
> >> > The first step toward acceptance of a new PV protocol is to write a
> >> > design document and send it to xen-devel. It should cover the xenstore
> >> > handshake mechanism, the ABI, how the protocol works and anything else
> >> > which is required to write an implementation of it. The usage of C-like
> >> > structs to describe language and platform agnostic protocols is
> >> > discouraged.
> >> >
> >> > An attempt should be made for the protocol ABI to be backward compatible
> >> > and OS agnostic, but, realistically, backward and cross-platform
> >> > compatibility are not fully expected at this stage.
> >>
> >> How does backward compatibility matter for a new protocol? Is
> >> this perhaps rather about forward compatibility provisions
> >> (like requiring reserved fields to be zero to allow future use)?
> >
> > By "backward compatibility" I mean promising that, in 5 years time, a
> > new frontend will still be able to connect to a backend written in 2016.
> >
> > This level of support requires an understanding of the protocol and its
> > subtleties which usually only comes from experience. Hence, I am
> > suggesting to make this kind of promises only after the code has lived
> > in-tree for a while and has been subject to wider testing.
> >
> > Maybe I should call it cross-versions compatibility?
> 
> Right, so I think you mean that you design the (new) protocol such
> that *future* versions can be backwards-compatible.
> 
> What if you rephrase it something like the following?
> 
> "An attempt should be made to design the ABI such that it will be OS
> agnostic, that future versions will not need to introduce
> backward-incompatible changes, and so on; but these are not yet hard
> requirements."  (Or perhaps, "not yet first-order goals.")

sounds good to me

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

[Xen-devel] [PATCH] x86/svm: Replace opencoded 1GB superpage check

[Andrew Cooper]

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Boris Ostrovsky 
CC: Suravee Suthikulpanit 
---
 xen/arch/x86/hvm/svm/svm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 89daa39..04a7b60 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1473,7 +1473,7 @@ const struct hvm_function_table * __init start_svm(void)
 
 svm_function_table.hap_supported = !!cpu_has_svm_npt;
 svm_function_table.hap_capabilities = HVM_HAP_SUPERPAGE_2MB |
-((cpuid_edx(0x8001) & 0x0400) ? HVM_HAP_SUPERPAGE_1GB : 0);
+(cpu_has_page1gb ? HVM_HAP_SUPERPAGE_1GB : 0);
 
 return _function_table;
 }
-- 
2.1.4


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

Re: [Xen-devel] [PATCH RFC 59/59] tools/xenlight: Create interface for xenlight info

[Ronald Rojas]

On Thu, Dec 29, 2016 at 01:45:54PM +, George Dunlap wrote:
> Hey Ronald!  Looks like you're getting going pretty well here.
> 
> At a high level: I think I began by saying that this would probably all
> be a single patch.  But I think it would probably be easier to review
> the different decisions made at each point by filling out the file bit
> by bit, and explaining what's going on at each point.
> 
> I think also it would be helpful to have somewhere -- either in a
> comment or in a text file -- a description of the general approach to
> converting the libxl C style into xenlight golang style.  For instance,
> saying that for functions, we'll take the function name
> (libxl_cpupool_remove), remove the libxl_ prefix (since the packages are
> namespaced already) and convert it to CamelCase by capitalizing the first
> 
> I'll take a stab at breaking it down in an example order that makes some
> sense to me, and then you can see what you think.

I made some guidelines that I think would nicely adjust the naming convention
from C to Go. I'll add it as a file below.
> 
> Futher comments...
> 
> On 29/12/16 01:14, Ronald Rojas wrote:
> > diff --git a/tools/golang/xenlight/xenlight.go 
> > b/tools/golang/xenlight/xenlight.go
> > new file mode 100644
> > index 000..b0eb6f8
> > --- /dev/null
> > +++ b/tools/golang/xenlight/xenlight.go
> > @@ -0,0 +1,1000 @@
> > +/*
> > + * Copyright (C) 2016 George W. Dunlap, Citrix Systems UK Ltd
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation; version 2 of the
> > + * License only.
> > + *
> > + * This program is distributed in the hope that it will be useful, but
> > + * WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> > + * General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License
> > + * along with this program; if not, write to the Free Software
> > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> > + * 02110-1301, USA.
> > + */
> > +package xenlight
> > +
> > +/*
> > +#cgo LDFLAGS: -lxenlight -lyajl
> > +#include 
> > +#include 
> > +*/
> > +import "C"
> 
> I see you switched back to dynamic linking -- any particular reason?
> 
> We probably need to put a "// FIXME" here saying that we need to
> generate these compile-time dependencies using pkg-config.

We discussed this on IRC but I'll just restate here that I was not able 
to compile the program through static linking and it would be fine to 
just use dynamic linking for now.
Since we are doing dynamic linking do we still need to use pkg-config?
> 
> > +
> > +/*
> > + * Other flags that may be needed at some point:
> > + *  -lnl-route-3 -lnl-3
> > +#cgo LDFLAGS: -lxenlight -lyajl_s -lxengnttab -lxenstore -lxenguest 
> > -lxentoollog -lxenevtchn -lxenctrl -lblktapctl -lxenforeignmemory -lxencall 
> > -lz -luuid -lutil
> > + *
> > + * To get back to simple dynamic linking:
> > +*/
> 
> Comment needs updating (to "To use static linking").

Fixed.
> 
> > +
> > +import (
> > +   "fmt"
> > +   "time"
> > +   "unsafe"
> > +)
> > +
> > +/*
> > + * Errors
> > + */
> > +const (
> > +   ErrorNonspecific  = int(C.ERROR_NONSPECIFIC)
> > +   ErrorVersion  = int(C.ERROR_VERSION)
> > +   ErrorFail = int(C.ERROR_FAIL)
> > +   ErrorNi   = int(C.ERROR_NI)
> > +   ErrorNomem= int(C.ERROR_NOMEM)
> > +   ErrorInval= int(C.ERROR_INVAL)
> > +   ErrorBadfail  = int(C.ERROR_BADFAIL)
> > +   ErrorGuestTimedout= int(C.ERROR_GUEST_TIMEDOUT)
> > +   ErrorTimedout = int(C.ERROR_TIMEDOUT)
> > +   ErrorNoparavirt   = int(C.ERROR_NOPARAVIRT)
> > +   ErrorNotReady = int(C.ERROR_NOT_READY)
> > +   ErrorOseventRegFail   = int(C.ERROR_OSEVENT_REG_FAIL)
> > +   ErrorBufferfull   = int(C.ERROR_BUFFERFULL)
> > +   ErrorUnknownChild = int(C.ERROR_UNKNOWN_CHILD)
> > +   ErrorLockFail = int(C.ERROR_LOCK_FAIL)
> > +   ErrorJsonConfigEmpty  = int(C.ERROR_JSON_CONFIG_EMPTY)
> > +   ErrorDeviceExists = int(C.ERROR_DEVICE_EXISTS)
> > +   ErrorCheckpointDevopsDoesNotMatch = 
> > int(C.ERROR_CHECKPOINT_DEVOPS_DOES_NOT_MATCH)
> > +   ErrorCheckpointDeviceNotSupported = 
> > int(C.ERROR_CHECKPOINT_DEVICE_NOT_SUPPORTED)
> > +   ErrorVnumaConfigInvalid   = int(C.ERROR_VNUMA_CONFIG_INVALID)
> > +   ErrorDomainNotfound   = int(C.ERROR_DOMAIN_NOTFOUND)
> > +   ErrorAborted  = int(C.ERROR_ABORTED)
> > +   ErrorNotfound = int(C.ERROR_NOTFOUND)
> > +   ErrorDomainDestroyed  = 

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

[Mark Rutland]

On Thu, Dec 15, 2016 at 12:27:13PM +, Andre Przywara wrote:
> These patches allow to include a Xen hypervisor binary into a boot-wrapper
> ELF file, so that a Foundation Platform or a Fast Model can boot a Xen
> system (including a Dom0 kernel).

Thanks!

I've applied the series and pushed it out to git.kernel.org.

I made minor tweaks to patches 1 and 3 for consistency, as noted in the
commit logs, but neither of these should have a functional impact.

Thanks,
Mark.

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

Re: [Xen-devel] Future support of 5-level paging in Xen

[anshul makkar]

On 08/12/16 23:40, Boris Ostrovsky wrote:



On 12/08/2016 05:21 PM, Andrew Cooper wrote:

On 08/12/2016 19:18, Stefano Stabellini wrote:





Of course even the largest virtual machine today (2TB on Amazon AFAIK)
is not close to reaching the current memory limit, but it's just a
matter of time.


/me things Oracle will have something to say about this.  I'm sure there
was talk about VMs larger than this at previous hackathons. XenServer
functions (ish, so long as you don't migrate) with 6TB VMs, although
starting and shutting them down feels like treacle.




I've been working (on and off) with SGI to get one of their 32TB boxes 
to boot and I don't think that works. We've fixed a couple of bugs but 
I don't think Xen can boot with that much memory. We successfully 
booted with just under 8TB but couldn't do it with the full system. 
The machine has been taken from us for now so this work is on hold.


This is on OVM, which is 4.4-based, we haven't tried (IIRC) latest bits.

(BTW, speaking of slow starting and shutting down very large guests ---
have you or anyone else had a chance to look at this? My investigation 
initially pointed to scrubbing and then to an insane number of 
hypercall preemptions in relinquish_memory()).


I had a quick look at it when I was working on support for large guest 
and found that scrubbing was indeed one of the issue. Just haven't got 
time to look at it in more details. Hopefully in near future, might work 
on it.



-boris

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



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

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

[Mark Rutland]

On Thu, Dec 15, 2016 at 12:27:17PM +, Andre Przywara wrote:
> From: Ian Campbell 
> 
> If Xen is enabled, tell Dom0 to use the 'hvc0' console, and fall back to
> the usual ttyAMA0 otherwise.
> 
> Signed-off-by: Ian Campbell 
> Signed-off-by: Christoffer Dall 
> Signed-off-by: Andre Przywara 
> Reviewed-by: Julien Grall 
> Tested-by: Konrad Rzeszutek Wilk 
> ---
>  configure.ac | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/configure.ac b/configure.ac
> index ea02dca..d23cced 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -105,7 +105,8 @@ AC_ARG_WITH([initrd],
>  AC_SUBST([FILESYSTEM], [$USE_INITRD])
>  AM_CONDITIONAL([INITRD], [test "x$USE_INITRD" != "x"])
>  
> -C_CMDLINE="console=ttyAMA0 earlyprintk=pl011,0x1c09"
> +AS_IF([test "x$X_IMAGE" = "x"],[C_CONSOLE="ttyAMA0"],[C_CONSOLE="hvc0"])
> +C_CMDLINE="console=$C_CONSOLE earlyprintk=pl011,0x1c09"

Just to check: what happesns if Dom0 tries to write to 0x1c09?

Shouldn't we override/delete earlyprintk/earlycon here too?

I've applied this as-is, so if we do need to, I'll need a fixup patch.

Thanks,
Mark.

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

Re: [Xen-devel] [PATCH] x86/HVM: restrict permitted instructions during special purpose emulation

[Andrew Cooper]

On 03/01/17 16:19, Jan Beulich wrote:
 On 03.01.17 at 16:22,  wrote:
>> On 03/01/17 13:10, Jan Beulich wrote:
>>> --- a/xen/arch/x86/hvm/emulate.c
>>> +++ b/xen/arch/x86/hvm/emulate.c
>>> @@ -1039,6 +1039,17 @@ static int hvmemul_cmpxchg(
>>>  return hvmemul_write(seg, offset, p_new, bytes, ctxt);
>>>  }
>>>  
>>> +static int hvmemul_validate(
>>> +const struct x86_emulate_state *state,
>>> +struct x86_emulate_ctxt *ctxt)
>>> +{
>>> +struct hvm_emulate_ctxt *hvmemul_ctxt =
>>> +container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
>>> +
>>> +return hvmemul_ctxt->validate ? hvmemul_ctxt->validate(state, 
>>> hvmemul_ctxt)
>>> +  : X86EMUL_OKAY;
>> There is nothing hvm-specific about any of the validation functions, and
>> x86_insn_is_{portio,cr_access,is_invlpg} seem more generally useful than
>> hvm-specific varients.
>>
>> Do you forsee any validation which would need to peek into hvmeml_ctxt? 
>> I can't think of anything off the top of my head.
>>
>> If not, this would be cleaner and shorter to have an x86emul_validate_t
>> based interface, always passing const struct x86_emulate_ctxt *ctxt.
> I had thought about this, but it feels like a layering violation to
> pass a pointer to a function taking x86_emulate_ctxt to functions
> in the HVM emulation group. Even if it involves adding slightly more
> code, I think it would better stay this way.

Given that one structure is embedded in the other, I am less concerned
about this being a layering violation.

I was specifically thinking along the line of not needing hvm and sh
stubs to call into x86_insn_is_mem_access(), as the hvm/sh nature isn't
relevant to the operation.

>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -4004,7 +4004,7 @@ void hvm_ud_intercept(struct cpu_user_re
>>>  cur->domain->arch.x86_vendor != boot_cpu_data.x86_vendor;
>>>  struct hvm_emulate_ctxt ctxt;
>>>  
>>> -hvm_emulate_init_once(, regs);
>>> +hvm_emulate_init_once(, NULL, regs);
>> Please could we have a validation function here which, for the
>> opt_hvm_fep case permits everything, and for the cross-vendor case
>> permits only SYS{CALL,RET,ENTER,EXIT}?
>>
>> This severely limits the attack surface even for a VM configured in
>> cross-vendor mode, and we only need to cope with instructions which have
>> different #UD behaviour between vendors.
> I can certainly do that (albeit I'd pass NULL for the FEP case
> instead of a function permitting everything), yet that will
> lock us further into the corner where actively emulating insns
> without hardware support is rather difficult to achieve.

Well, not really.  When we choose to offer that facility, it should come
with an opt-in, and we can extend the validate function to permit
instructions in classes permitted by the domain featureset, but missing
in the host featureset.

>
>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>>> @@ -3774,7 +3774,7 @@ x86_emulate(
>>>  emulate_fpu_insn_memsrc("flds", src.val);
>>>  dst.type = OP_NONE;
>>>  break;
>>> -case 2: /* fstp m32fp */
>>> +case 2: /* fst m32fp */
>> This change looks like it is spurious from a different patch?
> It doesn't belong anywhere - I found the comment wrong while
> collecting the memory store insns, and putting this in a separate
> patch didn't seem worthwhile. I've added a word to the commit
> message.

Ok.

~Andrew

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

[Xen-devel] [PATCHv6 00/11] CONFIG_DEBUG_VIRTUAL for arm64

[Laura Abbott]

Happy New Year!

This is a very minor rebase from v5. It only moves a few headers around.
I think this series should be ready to be queued up for 4.11.

Thanks,
Laura

Laura Abbott (11):
  lib/Kconfig.debug: Add ARCH_HAS_DEBUG_VIRTUAL
  mm/cma: Cleanup highmem check
  arm64: Move some macros under #ifndef __ASSEMBLY__
  arm64: Add cast for virt_to_pfn
  mm: Introduce lm_alias
  arm64: Use __pa_symbol for kernel symbols
  drivers: firmware: psci: Use __pa_symbol for kernel symbol
  kexec: Switch to __pa_symbol
  mm/kasan: Switch to using __pa_symbol and lm_alias
  mm/usercopy: Switch to using lm_alias
  arm64: Add support for CONFIG_DEBUG_VIRTUAL

 arch/arm64/Kconfig|  1 +
 arch/arm64/include/asm/kvm_mmu.h  |  4 +-
 arch/arm64/include/asm/memory.h   | 66 +--
 arch/arm64/include/asm/mmu_context.h  |  6 +--
 arch/arm64/include/asm/pgtable.h  |  2 +-
 arch/arm64/kernel/acpi_parking_protocol.c |  3 +-
 arch/arm64/kernel/cpu-reset.h |  2 +-
 arch/arm64/kernel/cpufeature.c|  3 +-
 arch/arm64/kernel/hibernate.c | 20 +++---
 arch/arm64/kernel/insn.c  |  2 +-
 arch/arm64/kernel/psci.c  |  3 +-
 arch/arm64/kernel/setup.c |  9 +++--
 arch/arm64/kernel/smp_spin_table.c|  3 +-
 arch/arm64/kernel/vdso.c  |  8 +++-
 arch/arm64/mm/Makefile|  2 +
 arch/arm64/mm/init.c  | 12 +++---
 arch/arm64/mm/kasan_init.c| 22 +++
 arch/arm64/mm/mmu.c   | 33 ++--
 arch/arm64/mm/physaddr.c  | 30 ++
 arch/x86/Kconfig  |  1 +
 drivers/firmware/psci.c   |  2 +-
 include/linux/mm.h|  4 ++
 kernel/kexec_core.c   |  2 +-
 lib/Kconfig.debug |  5 ++-
 mm/cma.c  | 15 +++
 mm/kasan/kasan_init.c | 15 +++
 mm/usercopy.c |  4 +-
 27 files changed, 180 insertions(+), 99 deletions(-)
 create mode 100644 arch/arm64/mm/physaddr.c

-- 
2.7.4


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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 32ea56f0a65b80324e3e651432bdf496a6fc55b7
baseline version:
 ovmf 7c6075e2546dd818b7b87090a983429b1942796a

Last test of basis68309  2017-01-03 10:17:45 Z0 days
Testing same since68310  2017-01-03 15:17:10 Z0 days1 attempts


People who touched revisions under test:
  Laszlo Ersek 

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



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

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

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


Push not applicable.


commit 32ea56f0a65b80324e3e651432bdf496a6fc55b7
Author: Laszlo Ersek 
Date:   Wed Nov 30 20:31:18 2016 +0100

Vlv2TbltDevicePkg/BootScriptSaveDxe: save 64-bit LoopTimes

The BootScriptMemPoll() helper function does the following:

- pop LoopTimes from the variable argument list as UINT64, then truncate
  it to UINTN,

- pass the truncated value to S3BootScriptSaveMemPoll() as last argument.

The truncation to UINTN is now superfluous, thanks to the patch titled
"MdePkg, MdeModulePkg: S3BootScriptSaveMemPoll(): accept 64-bit
LoopTimes".

Cc: David Wei 
Cc: Mang Guo 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: "Yao, Jiewen" 
Reviewed-by: Michael Kinney 

commit 387ccad8f6f3acbae80bbeb816c944dec672aa66
Author: Laszlo Ersek 
Date:   Wed Nov 30 20:19:06 2016 +0100

MdeModulePkg: S3SaveStateDxe, SmmS3SaveState: save 64-bit LoopTimes

The BootScriptWriteMemPoll() helper function in both drivers does the
following:

- pop Delay from the variable argument list as UINT64, then truncate it to
  UINTN,

- divide Delay by 10, using DivU64x32Remainder(), then store the quotient
  in LoopTimes (also UINTN),

- pass LoopTimes to S3BootScriptSaveMemPoll() as last argument.

The truncation to UINTN is superfluous and wrong in this logic (not to
mention incompatible with the PI spec); it prevents callers from
specifying Delays longer than 0x_ * 100ns (approximately 429
seconds == 7 minutes 9 seconds) on Ia32. In particular it prevents callers
from specifying an infinite timeout (for example, 0x___ *
100ns, approximately 58494 years).

Change the type of Delay and LoopTimes to UINT64. Keep the same logic,
just remove the truncations. The resultant LoopTimes values can be safely
passed to S3BootScriptSaveMemPoll() thanks to the previous patch.

Cc: Feng Tian 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: "Yao, Jiewen" 
Reviewed-by: Michael Kinney 

commit 63042a718887693a07e6575fc8c8f58cdd0933cc
Author: Laszlo Ersek 
Date:   Wed Nov 30 20:07:50 2016 +0100

MdePkg, MdeModulePkg: S3BootScriptSaveMemPoll(): accept 64-bit LoopTimes

The BaseNull instance of S3BootScriptLib obviously doesn't care about the
type of the S3BootScriptSaveMemPoll() function's LoopTimes parameter; this
lib instance doesn't do anything with the parameters received in
S3BootScriptSaveMemPoll().

The PiDxe instance saves the LoopTimes parameter in
EFI_BOOT_SCRIPT_MEM_POLL.LoopTimes. This target field already has UINT64
type. Furthermore, the BootScriptExecuteMemPoll() function in the same
library instance already uses a local UINT64 

Re: [Xen-devel] [PATCH v6 12/12] docs: Describe PVHv2's VCPU hotplug procedure

[Jan Beulich]

>>> On 03.01.17 at 15:04,  wrote:
> --- a/docs/misc/hvmlite.markdown
> +++ b/docs/misc/hvmlite.markdown
> @@ -75,3 +75,14 @@ info structure that's passed at boot time (field 
> rsdp_paddr).
>  
>  Description of paravirtualized devices will come from XenStore, just as it's
>  done for HVM guests.
> +
> +## VCPU hotplug ##
> +
> +VCPU hotplug (e.g. 'xl vcpu-set  ') for PVHv2 guests
> +follows ACPI model where change in domain's number of VCPUS (stored in
> +domain.avail_vcpus) results in an SCI being sent to the guest. The guest
> +then executes DSDT's PRSC method, updating MADT enable status for the
> +affected VCPU.
> +
> +Updating VCPU number is achieved by having the toolstack issue a write to
> +ACPI's XEN_ACPI_CPU_MAP.

Is any of this valid anymore in the context of the recent discussion?
Perhaps even wider - how much of this series is applicable if pCPU
hotplug is to use the normal ACPI code path? I hope the plan is not
to have different vCPU hotplug for DomU and Dom0?

Jan


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

Re: [Xen-devel] [PATCH v6 02/12] x86/save: public/arch-x86/hvm/save.h is available to hypervisor and tools only

[Jan Beulich]

>>> On 03.01.17 at 15:04,  wrote:
> Noone else needs to include it since it is only useful to code
> that can made domctl calls. And public domctl.h can only be included
> by the toolstack or the hypervisor.
> 
> Signed-off-by: Boris Ostrovsky 
> ---
> New in v6 (not required by the series).
> 
> Q: Should include/public/hvm/save.h have the same guards?

Yes. In fact the architecture specific header should never be included
directly, so putting the guard just there (and ...

> --- a/xen/include/public/arch-x86/hvm/save.h
> +++ b/xen/include/public/arch-x86/hvm/save.h
> @@ -26,6 +26,8 @@
>  #ifndef __XEN_PUBLIC_HVM_SAVE_X86_H__
>  #define __XEN_PUBLIC_HVM_SAVE_X86_H__
>  
> +#if defined(__XEN__) || defined(__XEN_TOOLS__)

... an #error here and in the ARM counterpart) would seem best.

Jan


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

[Xen-devel] [distros-debian-snapshot test] 68308: tolerable FAIL

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-amd64-weekly-netinst-pygrub 9 debian-di-install fail like 
68277
 test-armhf-armhf-armhf-daily-netboot-pygrub 9 debian-di-install fail like 68277
 test-amd64-i386-amd64-daily-netboot-pygrub 9 debian-di-install fail like 68277
 test-amd64-i386-i386-daily-netboot-pvgrub  9 debian-di-install fail like 68277
 test-amd64-amd64-i386-daily-netboot-pygrub 9 debian-di-install fail like 68277
 test-amd64-i386-amd64-weekly-netinst-pygrub 9 debian-di-install fail like 68277
 test-amd64-amd64-amd64-daily-netboot-pvgrub 9 debian-di-install fail like 68277
 test-amd64-i386-i386-weekly-netinst-pygrub 9 debian-di-install fail like 68277
 test-amd64-amd64-i386-weekly-netinst-pygrub 9 debian-di-install fail like 68277

baseline version:
 flight   68277

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-daily-netboot-pvgrub  fail
 test-amd64-i386-i386-daily-netboot-pvgrubfail
 test-amd64-i386-amd64-daily-netboot-pygrub   fail
 test-armhf-armhf-armhf-daily-netboot-pygrub  fail
 test-amd64-amd64-i386-daily-netboot-pygrub   fail
 test-amd64-amd64-amd64-current-netinst-pygrubpass
 test-amd64-i386-amd64-current-netinst-pygrub pass
 test-amd64-amd64-i386-current-netinst-pygrub pass
 test-amd64-i386-i386-current-netinst-pygrub  pass
 test-amd64-amd64-amd64-weekly-netinst-pygrub fail
 test-amd64-i386-amd64-weekly-netinst-pygrub  fail
 test-amd64-amd64-i386-weekly-netinst-pygrub  fail
 test-amd64-i386-i386-weekly-netinst-pygrub   fail



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

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

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


Push not applicable.


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

Re: [Xen-devel] [RFC] kbdif: add multi-touch support

[Jan Beulich]

>>> On 03.01.17 at 16:39,  wrote:
> --- a/xen/include/public/io/kbdif.h
> +++ b/xen/include/public/io/kbdif.h
> @@ -45,6 +45,19 @@
>   */
>  #define XENKBD_TYPE_POS 4
>  
> +/*
> + * Multi-touch event
> + * Capable backend sets feature-multi-touch in xenstore.
> + * Frontend requests feature by setting request-multi-touch in xenstore.
> + * Frontend supports up to XENKBD_MT_NUM_DEV virtual multi-touch input 
> devices,
> + * configured by the backend in xenstore under mt-%d folder, %d being
> + * a sequential number of the virtual input device:
> + *   o num-contacts - number of simultaneous touches supported
> + *   o width - width of the touch area in pixels
> + *   o height - height of the touch area in pixels
> + */
> +#define XENKBD_TYPE_MTOUCH  5
> +
>  struct xenkbd_motion
>  {
>  uint8_t type;/* XENKBD_TYPE_MOTION */
> @@ -68,6 +81,56 @@ struct xenkbd_position
>  int32_t rel_z;   /* relative Z motion (wheel) */
>  };
>  
> +/* number of simultaneously supported multi-touch virtual input devices */
> +#define XENKBD_MT_NUM_DEV   4

Why is this limit needed? There's no use of it within the other
interface additions you make.

Jan


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

Re: [Xen-devel] [PATCH] x86/HVM: restrict permitted instructions during special purpose emulation

[Jan Beulich]

>>> On 03.01.17 at 16:22,  wrote:
> On 03/01/17 13:10, Jan Beulich wrote:
>> --- a/xen/arch/x86/hvm/emulate.c
>> +++ b/xen/arch/x86/hvm/emulate.c
>> @@ -1039,6 +1039,17 @@ static int hvmemul_cmpxchg(
>>  return hvmemul_write(seg, offset, p_new, bytes, ctxt);
>>  }
>>  
>> +static int hvmemul_validate(
>> +const struct x86_emulate_state *state,
>> +struct x86_emulate_ctxt *ctxt)
>> +{
>> +struct hvm_emulate_ctxt *hvmemul_ctxt =
>> +container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
>> +
>> +return hvmemul_ctxt->validate ? hvmemul_ctxt->validate(state, 
>> hvmemul_ctxt)
>> +  : X86EMUL_OKAY;
> 
> There is nothing hvm-specific about any of the validation functions, and
> x86_insn_is_{portio,cr_access,is_invlpg} seem more generally useful than
> hvm-specific varients.
> 
> Do you forsee any validation which would need to peek into hvmeml_ctxt? 
> I can't think of anything off the top of my head.
> 
> If not, this would be cleaner and shorter to have an x86emul_validate_t
> based interface, always passing const struct x86_emulate_ctxt *ctxt.

I had thought about this, but it feels like a layering violation to
pass a pointer to a function taking x86_emulate_ctxt to functions
in the HVM emulation group. Even if it involves adding slightly more
code, I think it would better stay this way.

>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -4004,7 +4004,7 @@ void hvm_ud_intercept(struct cpu_user_re
>>  cur->domain->arch.x86_vendor != boot_cpu_data.x86_vendor;
>>  struct hvm_emulate_ctxt ctxt;
>>  
>> -hvm_emulate_init_once(, regs);
>> +hvm_emulate_init_once(, NULL, regs);
> 
> Please could we have a validation function here which, for the
> opt_hvm_fep case permits everything, and for the cross-vendor case
> permits only SYS{CALL,RET,ENTER,EXIT}?
> 
> This severely limits the attack surface even for a VM configured in
> cross-vendor mode, and we only need to cope with instructions which have
> different #UD behaviour between vendors.

I can certainly do that (albeit I'd pass NULL for the FEP case
instead of a function permitting everything), yet that will
lock us further into the corner where actively emulating insns
without hardware support is rather difficult to achieve.

>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -3774,7 +3774,7 @@ x86_emulate(
>>  emulate_fpu_insn_memsrc("flds", src.val);
>>  dst.type = OP_NONE;
>>  break;
>> -case 2: /* fstp m32fp */
>> +case 2: /* fst m32fp */
> 
> This change looks like it is spurious from a different patch?

It doesn't belong anywhere - I found the comment wrong while
collecting the memory store insns, and putting this in a separate
patch didn't seem worthwhile. I've added a word to the commit
message.

Jan


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

Re: [Xen-devel] [PATCH v2 10/10] x86/SVM: Add AMD AVIC key handler

[Andrew Cooper]

On 03/01/17 16:01, Boris Ostrovsky wrote:
>>  
>> +static void avic_dump(unsigned char ch)
>> +{
>> +struct domain *d;
>> +struct vcpu *v;
>> +
>> +printk("*** SVM AVIC Statistics **\n");
>> +
>> +rcu_read_lock(_read_lock);
>> +
>> +for_each_domain ( d )
>> +{
>> +if ( !is_hvm_domain(d) )
> || !svm_avic_vcpu_enabled(d->v[0]) (or something along these lines)?

It isn't safe to deference the vcpu array like this, which in turn
highlights that the avic predicate should be per-domain, not per-cpu. 
Under no circumstances should we have AVIC on some vcpus but not others
of the same domain.

~Andrew

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

Re: [Xen-devel] [PATCH v2 10/10] x86/SVM: Add AMD AVIC key handler

[Boris Ostrovsky]

>  
> +static void avic_dump(unsigned char ch)
> +{
> +struct domain *d;
> +struct vcpu *v;
> +
> +printk("*** SVM AVIC Statistics **\n");
> +
> +rcu_read_lock(_read_lock);
> +
> +for_each_domain ( d )
> +{
> +if ( !is_hvm_domain(d) )

|| !svm_avic_vcpu_enabled(d->v[0]) (or something along these lines)?


> +continue;
> +printk(">>> Domain %d <<<\n", d->domain_id);
> +for_each_vcpu ( d, v )
> +{
> +printk("\tVCPU %d\n", v->vcpu_id);
> +printk("\t* incomp_ipi = %u\n",
> +   v->arch.hvm_svm.cnt_avic_incomp_ipi);
> +printk("\t* noaccel= %u\n",
> +   v->arch.hvm_svm.cnt_avic_noaccel);
> +printk("\t* post_intr  = %u\n",
> +   v->arch.hvm_svm.cnt_avic_post_intr);
> +printk("\t* doorbell   = %u\n",
> +   v->arch.hvm_svm.cnt_avic_doorbell);
> +}
> +}
> +
> +rcu_read_unlock(_read_lock);
> +
> +printk("**\n");
> +
> +}
> +
> +void __init setup_avic_dump(void)
> +{

if ( !svm_avic ) return; ?


-boris


> +register_keyhandler('j', avic_dump, "dump SVM AVIC", 1);
> +}
> +


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

Re: [Xen-devel] [PATCH] uapi: use wildcards to list files

[David Miller]

From: Nicolas Dichtel 
Date: Tue,  3 Jan 2017 15:35:44 +0100

> Regularly, when a new header is created in include/uapi/, the developer
> forgets to add it in the corresponding Kbuild file. This error is usually
> detected after the release is out.
> 
> In fact, all headers under include/uapi/ should be exported, so let's
> use wildcards.
> 
> After this patch, the following files, which were not exported, are now
> exported:
 ...
> 
> Signed-off-by: Nicolas Dichtel 

Acked-by: David S. Miller 

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

Re: [Xen-devel] [PATCH v4 14/14] xen/x86: setup PVHv2 Dom0 ACPI tables

[Roger Pau Monne]

On Fri, Dec 23, 2016 at 12:13:47PM -0500, Boris Ostrovsky wrote:
> On 12/23/2016 11:02 AM, Konrad Rzeszutek Wilk wrote:
> > On Fri, Dec 23, 2016 at 10:35:10AM -0500, Boris Ostrovsky wrote:
> >> On 12/23/2016 10:31 AM, Konrad Rzeszutek Wilk wrote:
>  But this still assumes that dom0 handles ACPI event for a pCPUs as well,
>  right? And I am not sure this can work.
> 
>  Actually, how do we hotplug pCPUs now?
> >>> xen-hptool
> >> Yes, but this has nothing to do with an actual pCPU being hot-plugged
> >> into the system. It's similar to doing 'echo 1 > /sys/.../cpuX/online in
> >> Lnux.
> >>
> >> My question is --- how do we (hypervisor/dom0/toolstack) become aware of
> >> appearance of a new processor.
> > Ooooh. drivers/xen/xen-acpi-cpuhotplug.c
> 
> Looking at this code I think we should be able to at least differentiate
> between pCPU and vCPU and not add pCPU to dom0.

Right, but I don't really see any way to do this with the current ACPI
interface, and still be able to use ACPI CPU hotplug for both pCPUs and
vCPUs.

We can provide a crafted MADT that reflects the number of vCPUs available to
Dom0 at boot time, let Dom0 find the Processor objects in the ACPI namespace
and perform pCPU hotplug as it's been done until now. Then for Dom0 vCPU
hotplug we would need to use the hypercall interface as it's used by classic PV
guests, because AFAICT there's no way we can provide Dom0 with a PRST/PRSC
that's valid for both vCPUs and pCPUs.

Roger.


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

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

[osstest service owner]

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

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  e34bc403c3c7dc0075111fa9cd29e2a385bc66ed
baseline version:
 xen  ed5f19aea66fe5a72060d6a795ffcd23b7643ee3

Last test of basis   104010  2017-01-03 12:01:14 Z0 days
Testing same since   104011  2017-01-03 14:01:44 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

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=e34bc403c3c7dc0075111fa9cd29e2a385bc66ed
+ . ./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 
e34bc403c3c7dc0075111fa9cd29e2a385bc66ed
+ branch=xen-unstable-smoke
+ revision=e34bc403c3c7dc0075111fa9cd29e2a385bc66ed
+ . ./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.8-testing
+ '[' xe34bc403c3c7dc0075111fa9cd29e2a385bc66ed = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : 

Re: [Xen-devel] [PATCH v2 07/10] x86/SVM: Add vcpu scheduling support for AVIC

[Boris Ostrovsky]

On 12/31/2016 12:45 AM, Suravee Suthikulpanit wrote:
> Add hooks to manage AVIC data structure during vcpu scheduling.
>
> Signed-off-by: Suravee Suthikulpanit 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Jan Beulich 
> Cc: Boris Ostrovsky 
> ---
>  xen/arch/x86/hvm/svm/avic.c | 78 
> +
>  xen/arch/x86/hvm/svm/svm.c  | 10 ++
>  2 files changed, 88 insertions(+)
>
> diff --git a/xen/arch/x86/hvm/svm/avic.c b/xen/arch/x86/hvm/svm/avic.c
> index c0b7151..6351c8e 100644
> --- a/xen/arch/x86/hvm/svm/avic.c
> +++ b/xen/arch/x86/hvm/svm/avic.c
> @@ -73,6 +73,79 @@ avic_get_phy_apic_id_ent(const struct vcpu *v, unsigned 
> int index)
>  return _phy_apic_id_table[index];
>  }
>  
> +static void avic_vcpu_load(struct vcpu *v)
> +{
> +struct arch_svm_struct *s = >arch.hvm_svm;
> +int h_phy_apic_id;
> +struct avic_phy_apic_id_ent entry;
> +
> +if ( !s->avic_last_phy_id )
> +return;
> +
> +if ( test_bit(_VPF_blocked, >pause_flags) )
> +return;
> +
> +/*
> + * Note: APIC ID = 0xff is used for broadcast.
> + *   APIC ID > 0xff is reserved.
> + */
> +h_phy_apic_id = cpu_data[v->processor].apicid;
> +ASSERT(h_phy_apic_id < AVIC_PHY_APIC_ID_MAX);
> +
> +entry = *(s->avic_last_phy_id);
> +smp_rmb();
> +entry.host_phy_apic_id = h_phy_apic_id;
> +entry.is_running = 1;
> +*(s->avic_last_phy_id) = entry;
> +smp_wmb();
> +}
> +
> +static void avic_vcpu_unload(struct vcpu *v)
> +{
> +struct arch_svm_struct *s = >arch.hvm_svm;
> +struct avic_phy_apic_id_ent entry;
> +
> +if ( !svm_avic || !s->avic_last_phy_id )
> +return;
> +
> +entry = *(s->avic_last_phy_id);
> +smp_rmb();
> +entry.is_running = 0;
> +*(s->avic_last_phy_id) = entry;
> +smp_wmb();
> +}
> +
> +static void avic_vcpu_resume(struct vcpu *v)
> +{
> +struct avic_phy_apic_id_ent entry;
> +struct arch_svm_struct *s = >arch.hvm_svm;
> +
> +ASSERT(svm_avic_vcpu_enabled(v));
> +ASSERT(s->avic_last_phy_id);
> +ASSERT(!test_bit(_VPF_blocked, >pause_flags));
> +
> +entry = *(s->avic_last_phy_id);
> +smp_rmb();
> +entry.is_running = 1;
> +*(s->avic_last_phy_id) = entry;
> +smp_wmb();
> +}
> +
> +static void avic_vcpu_block(struct vcpu *v)
> +{
> +struct avic_phy_apic_id_ent entry;
> +struct arch_svm_struct *s = >arch.hvm_svm;
> +
> +ASSERT(svm_avic_vcpu_enabled(v));
> +ASSERT(s->avic_last_phy_id);
> +
> +entry = *(s->avic_last_phy_id);
> +smp_rmb();
> +entry.is_running = 0;
> +*(s->avic_last_phy_id) = entry;
> +smp_wmb();
> +}

I don't understand use of r/w barriers here (and I think Andrew had
similar comment) but in any case the last 5 lines can be factored out.

>  int svm_avic_dom_init(struct domain *d)
>  {
>  int ret = 0;
> @@ -127,6 +200,11 @@ int svm_avic_dom_init(struct domain *d)
>  
>  spin_lock_init(>arch.hvm_domain.svm.avic_ldr_mode_lock);
>  
> +d->arch.hvm_domain.pi_ops.pi_switch_to = avic_vcpu_unload;
> +d->arch.hvm_domain.pi_ops.pi_switch_from = avic_vcpu_load;
> +d->arch.hvm_domain.pi_ops.vcpu_block = avic_vcpu_block;
> +d->arch.hvm_domain.pi_ops.pi_do_resume = avic_vcpu_resume;
> +

I wonder whether it might be better to declare a (static) svm_pi_ops
structure and assign is here to d->arch.hvm_domain.pi_ops. And make a
similar change in patch 1 for VMX.

-boris


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

[Xen-devel] [RFC] kbdif: add multi-touch support

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Hi, all!

I am working on adding multi-touch support to the existing
kbdif protocol and would like to request for comments on the
below patch.
The aim is to provide multi-touch support to unprivileged
domains which may employ multiple virtual displays.
Thus, the protocol should handle multiple virtual touch input
devices withing the same domain, so those can be mapped to
different virtual displays.

Thank you in advance,
Oleksandr

Oleksandr Andrushchenko (1):
  kbdif: add multi-touch support

 xen/include/public/io/kbdif.h | 64 +++
 1 file changed, 64 insertions(+)

-- 
2.7.4


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

[Xen-devel] [RFC] kbdif: add multi-touch support

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Signed-off-by: Oleksandr Andrushchenko 
---
 xen/include/public/io/kbdif.h | 64 +++
 1 file changed, 64 insertions(+)

diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
index 2d2aebd..ad94b53 100644
--- a/xen/include/public/io/kbdif.h
+++ b/xen/include/public/io/kbdif.h
@@ -45,6 +45,19 @@
  */
 #define XENKBD_TYPE_POS 4
 
+/*
+ * Multi-touch event
+ * Capable backend sets feature-multi-touch in xenstore.
+ * Frontend requests feature by setting request-multi-touch in xenstore.
+ * Frontend supports up to XENKBD_MT_NUM_DEV virtual multi-touch input devices,
+ * configured by the backend in xenstore under mt-%d folder, %d being
+ * a sequential number of the virtual input device:
+ *   o num-contacts - number of simultaneous touches supported
+ *   o width - width of the touch area in pixels
+ *   o height - height of the touch area in pixels
+ */
+#define XENKBD_TYPE_MTOUCH  5
+
 struct xenkbd_motion
 {
 uint8_t type;/* XENKBD_TYPE_MOTION */
@@ -68,6 +81,56 @@ struct xenkbd_position
 int32_t rel_z;   /* relative Z motion (wheel) */
 };
 
+/* number of simultaneously supported multi-touch virtual input devices */
+#define XENKBD_MT_NUM_DEV   4
+
+/* Sent when a new touch is made: touch is assigned a unique contact
+ * ID, sent with this and consequent events related to this touch.
+ * Contact ID will be reused after XENKBD_MT_EV_UP event.
+ */
+#define XENKBD_MT_EV_DOWN   0
+/* Touch point has been released */
+#define XENKBD_MT_EV_UP 1
+/* Touch point has changed its coordinate(s) */
+#define XENKBD_MT_EV_MOTION 2
+/* Input synchronization event: shows end of a set of events
+ * which logically belong together.
+ */
+#define XENKBD_MT_EV_SYN3
+/* Touch point has changed its shape. Shape is approximated by an ellipse
+ * through the major and minor axis lengths: major is the longer diameter
+ * of the ellipse and minor is the shorter one. Center of the ellipse is
+ * reported via XENKBD_MT_EV_DOWN/XENKBD_MT_EV_MOTION events.
+ */
+#define XENKBD_MT_EV_SHAPE  4
+/* Touch point's shape has changed its orientation: calculated as a clockwise
+ * angle between the major axis of the ellipse and positive Y axis in degrees,
+ * [-180; +180].
+ */
+#define XENKBD_MT_EV_ORIENT 5
+
+struct xenkbd_mtouch {
+uint8_t type; /* XENKBD_TYPE_MTOUCH */
+uint8_t dev_idx;  /* index of the multi-touch device */
+uint8_t event_type;   /* XENKBD_MT_EV_??? */
+uint8_t reserved; /* reserved for the future use */
+int32_t contact_id;   /* contact ID, [0; num-contacts - 1] */
+union {
+/* XENKBD_MT_EV_DOWN/XENKBD_MT_EV_MOTION */
+struct {
+int32_t abs_x;/* absolute X position, pixels */
+int32_t abs_y;/* absolute Y position, pixels */
+} pos;
+/* XENKBD_MT_EV_SHAPE */
+struct {
+uint32_t major;   /* length of the major axis, pixels */
+uint32_t minor;   /* length of the minor axis, pixels */
+} shape;
+/* XENKBD_MT_EV_ORIENT */
+uint16_t orientation; /* clockwise angle of the major axis */
+} u;
+};
+
 #define XENKBD_IN_EVENT_SIZE 40
 
 union xenkbd_in_event
@@ -76,6 +139,7 @@ union xenkbd_in_event
 struct xenkbd_motion motion;
 struct xenkbd_key key;
 struct xenkbd_position pos;
+struct xenkbd_mtouch mtouch;
 char pad[XENKBD_IN_EVENT_SIZE];
 };
 
-- 
2.7.4


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

Re: [Xen-devel] [PATCH v2 06/10] x86/SVM: Add AVIC vmexit handlers

[Boris Ostrovsky]

> +
> +static int avic_ldr_write(struct vcpu *v, u8 g_phy_id, u32 ldr, bool valid)
> +{
> +struct avic_log_apic_id_ent *entry, new_entry;
> +u32 *bp = avic_get_bk_page_entry(v, APIC_DFR);

dfr would be a better name (and you use it in avic_handle_dfr_update()).

Also, 'logical' instead of 'log' in avic_log_apic_id_ent would be far
less confusing imo.

> +
> +if ( !bp )
> +return -EINVAL;
> +
> +entry = avic_get_logical_id_entry(v, ldr, (*bp == APIC_DFR_FLAT));
> +if (!entry)
> +return -EINVAL;
> +
> +new_entry = *entry;
> +smp_rmb();
> +new_entry.guest_phy_apic_id = g_phy_id;
> +new_entry.valid = valid;
> +*entry = new_entry;
> +smp_wmb();
> +
> +return 0;
> +}



> +
> +static int avic_handle_apic_id_update(struct vcpu *v, bool init)
> +{
> +struct avic_phy_apic_id_ent *old, *new;
> +struct arch_svm_struct *s = >arch.hvm_svm;
> +u32 *apic_id_reg = avic_get_bk_page_entry(v, APIC_ID);
> +
> +if ( !apic_id_reg )
> +return -EINVAL;
> +
> +old = s->avic_last_phy_id;
> +ASSERT(old);
> +
> +new = avic_get_phy_apic_id_ent(v, GET_APIC_PHYSICAL_ID(*apic_id_reg));
> +if ( !new )
> +return 0;
> +
> +/* We need to move physical_id_entry to new offset */
> +*new = *old;
> +*((u64 *)old) = 0ULL;

This is pretty ugly. Can you define an invalid entry and assign it here
instead?

> +s->avic_last_phy_id = new;
> +
> +/*
> + * Update the guest physical APIC ID in the logical
> + * APIC ID table entry if LDR is already setup.
> + */
> +if ( v->arch.hvm_svm.avic_last_ldr )
> +avic_handle_ldr_update(v);
> +
> +return 0;
> +}
> +
> +static int avic_handle_dfr_update(struct vcpu *v)
> +{
> +u32 mod;
> +struct svm_domain *d = >domain->arch.hvm_domain.svm;
> +u32 *dfr = avic_get_bk_page_entry(v, APIC_DFR);
> +
> +if ( !dfr )
> +return -EINVAL;
> +
> +mod = (*dfr >> 28) & 0xFu;
> +
> +spin_lock(>avic_ldr_mode_lock);
> +if ( d->avic_ldr_mode != mod )
> +{
> +/*
> + * We assume that all local APICs are using the same type.
> + * If LDR mode changes, we need to flush the domain AVIC logical
> + * APIC id table.
> + */
> +clear_domain_page(_mfn(d->avic_log_apic_id_table_mfn));
> +smp_wmb();

Is this needed? I think clear_page() guarantees visibility/ordering (we
have SFENCE in clear_page_sse2() for this reason).


-boris


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

Re: [Xen-devel] [PATCH v2 2/2] p2m: split mem_access into separate files

[Tamas K Lengyel]

On Fri, Dec 9, 2016 at 12:59 PM, Tamas K Lengyel
 wrote:
> This patch relocates mem_access components that are currently mixed with p2m
> code into separate files. This better aligns the code with similar subsystems,
> such as mem_sharing and mem_paging, which are already in separate files. There
> are no code-changes introduced, the patch is mechanical code movement.
>
> On ARM we also relocate the static inline gfn_next_boundary function to p2m.h
> as it is a function the mem_access code needs access to.
>
> Signed-off-by: Tamas K Lengyel 
> Acked-by: Razvan Cojocaru 

Acked-by: George Dunlap 

> ---
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: George Dunlap 
>
> v2: Don't move ARM radix tree functions
> Include asm/mem_accesss.h in xen/mem_access.h

Patch ping. I think this only needs an ARM-side ack.

> ---
>  MAINTAINERS  |   2 +
>  xen/arch/arm/Makefile|   1 +
>  xen/arch/arm/mem_access.c| 431 
>  xen/arch/arm/p2m.c   | 414 +--
>  xen/arch/arm/traps.c |   1 +
>  xen/arch/x86/mm/Makefile |   1 +
>  xen/arch/x86/mm/mem_access.c | 462 
> +++
>  xen/arch/x86/mm/p2m.c| 421 ---
>  xen/arch/x86/vm_event.c  |   3 +-
>  xen/common/mem_access.c  |   2 +-
>  xen/include/asm-arm/mem_access.h |  53 +
>  xen/include/asm-arm/p2m.h|  31 ++-
>  xen/include/asm-x86/mem_access.h |  61 ++
>  xen/include/asm-x86/p2m.h|  24 +-
>  xen/include/xen/mem_access.h |  67 +-
>  xen/include/xen/p2m-common.h |  52 -
>  16 files changed, 1089 insertions(+), 937 deletions(-)
>  create mode 100644 xen/arch/arm/mem_access.c
>  create mode 100644 xen/arch/x86/mm/mem_access.c
>  create mode 100644 xen/include/asm-arm/mem_access.h
>  create mode 100644 xen/include/asm-x86/mem_access.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f0d0202..fb26be3 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -402,6 +402,8 @@ S:  Supported
>  F: tools/tests/xen-access
>  F: xen/arch/*/monitor.c
>  F: xen/arch/*/vm_event.c
> +F: xen/arch/arm/mem_access.c
> +F: xen/arch/x86/mm/mem_access.c
>  F: xen/arch/x86/hvm/monitor.c
>  F: xen/common/mem_access.c
>  F: xen/common/monitor.c
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index da39d39..b095e8a 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -24,6 +24,7 @@ obj-y += io.o
>  obj-y += irq.o
>  obj-y += kernel.o
>  obj-$(CONFIG_LIVEPATCH) += livepatch.o
> +obj-y += mem_access.o
>  obj-y += mm.o
>  obj-y += monitor.o
>  obj-y += p2m.o
> diff --git a/xen/arch/arm/mem_access.c b/xen/arch/arm/mem_access.c
> new file mode 100644
> index 000..a6e5bcd
> --- /dev/null
> +++ b/xen/arch/arm/mem_access.c
> @@ -0,0 +1,431 @@
> +/*
> + * arch/arm/mem_access.c
> + *
> + * Architecture-specific mem_access handling routines
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public
> + * License v2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public
> + * License along with this program; If not, see 
> .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static int __p2m_get_mem_access(struct domain *d, gfn_t gfn,
> +xenmem_access_t *access)
> +{
> +struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +void *i;
> +unsigned int index;
> +
> +static const xenmem_access_t memaccess[] = {
> +#define ACCESS(ac) [p2m_access_##ac] = XENMEM_access_##ac
> +ACCESS(n),
> +ACCESS(r),
> +ACCESS(w),
> +ACCESS(rw),
> +ACCESS(x),
> +ACCESS(rx),
> +ACCESS(wx),
> +ACCESS(rwx),
> +ACCESS(rx2rw),
> +ACCESS(n2rwx),
> +#undef ACCESS
> +};
> +
> +ASSERT(p2m_is_locked(p2m));
> +
> +/* If no setting was ever set, just return rwx. */
> +if ( !p2m->mem_access_enabled )
> +{
> +*access = XENMEM_access_rwx;
> +return 0;
> +}
> +
> +/* If request to get default access. */
> +if ( gfn_eq(gfn, INVALID_GFN) )
> +{
> +*access 

Re: [Xen-devel] [PATCH v2 1/2] arm/mem_access: adjust check_and_get_page to not rely on current

[Tamas K Lengyel]

On Fri, Dec 9, 2016 at 12:59 PM, Tamas K Lengyel
 wrote:
> The only caller of this function is get_page_from_gva which already takes
> a vcpu pointer as input. Pass this along to make the function in-line with
> its intended use-case.
>
> Signed-off-by: Tamas K Lengyel 
> ---
> Cc: Stefano Stabellini 
> Cc: Julien Grall 

Patch ping.

> ---
>  xen/arch/arm/p2m.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index cc5634b..837be1d 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -1461,7 +1461,8 @@ mfn_t gfn_to_mfn(struct domain *d, gfn_t gfn)
>   * we indeed found a conflicting mem_access setting.
>   */
>  static struct page_info*
> -p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned long flag)
> +p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned long flag,
> +  const struct vcpu *v)
>  {
>  long rc;
>  paddr_t ipa;
> @@ -1470,7 +1471,7 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
> long flag)
>  xenmem_access_t xma;
>  p2m_type_t t;
>  struct page_info *page = NULL;
> -struct p2m_domain *p2m = >domain->arch.p2m;
> +struct p2m_domain *p2m = >domain->arch.p2m;
>
>  rc = gva_to_ipa(gva, , flag);
>  if ( rc < 0 )
> @@ -1482,7 +1483,7 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
> long flag)
>   * We do this first as this is faster in the default case when no
>   * permission is set on the page.
>   */
> -rc = __p2m_get_mem_access(current->domain, gfn, );
> +rc = __p2m_get_mem_access(v->domain, gfn, );
>  if ( rc < 0 )
>  goto err;
>
> @@ -1546,7 +1547,7 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
> long flag)
>
>  page = mfn_to_page(mfn_x(mfn));
>
> -if ( unlikely(!get_page(page, current->domain)) )
> +if ( unlikely(!get_page(page, v->domain)) )
>  page = NULL;
>
>  err:
> @@ -1587,7 +1588,7 @@ struct page_info *get_page_from_gva(struct vcpu *v, 
> vaddr_t va,
>
>  err:
>  if ( !page && p2m->mem_access_enabled )
> -page = p2m_mem_access_check_and_get_page(va, flags);
> +page = p2m_mem_access_check_and_get_page(va, flags, v);
>
>  p2m_read_unlock(p2m);
>
> --
> 2.10.2
>

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

Re: [Xen-devel] [PATCH] x86/HVM: restrict permitted instructions during special purpose emulation

[Andrew Cooper]

On 03/01/17 13:10, Jan Beulich wrote:
> Most invocations of the instruction emulator are for VM exits where the
> set of legitimate instructions (i.e. ones capable of causing the
> respective exit) is rather small. Restrict the permitted sets via a new
> callback, at once eliminating the abuse of handle_mmio() for non-MMIO
> operations.
>
> Signed-off-by: Jan Beulich 
> ---
> TBD: Better way to cover FPU/SIMD insns in x86_insn_is_mem_write()?

Not that I can see.

>
> Note that hvm_emulate_is_mem_*() (for now) intentionally don't include
> implicit memory operands: I don't think we mean to support namely
> the stack to live in MMIO, but otoh we may need to permit that.
>
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -1039,6 +1039,17 @@ static int hvmemul_cmpxchg(
>  return hvmemul_write(seg, offset, p_new, bytes, ctxt);
>  }
>  
> +static int hvmemul_validate(
> +const struct x86_emulate_state *state,
> +struct x86_emulate_ctxt *ctxt)
> +{
> +struct hvm_emulate_ctxt *hvmemul_ctxt =
> +container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
> +
> +return hvmemul_ctxt->validate ? hvmemul_ctxt->validate(state, 
> hvmemul_ctxt)
> +  : X86EMUL_OKAY;

There is nothing hvm-specific about any of the validation functions, and
x86_insn_is_{portio,cr_access,is_invlpg} seem more generally useful than
hvm-specific varients.

Do you forsee any validation which would need to peek into hvmeml_ctxt? 
I can't think of anything off the top of my head.

If not, this would be cleaner and shorter to have an x86emul_validate_t
based interface, always passing const struct x86_emulate_ctxt *ctxt.

> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4004,7 +4004,7 @@ void hvm_ud_intercept(struct cpu_user_re
>  cur->domain->arch.x86_vendor != boot_cpu_data.x86_vendor;
>  struct hvm_emulate_ctxt ctxt;
>  
> -hvm_emulate_init_once(, regs);
> +hvm_emulate_init_once(, NULL, regs);

Please could we have a validation function here which, for the
opt_hvm_fep case permits everything, and for the cross-vendor case
permits only SYS{CALL,RET,ENTER,EXIT}?

This severely limits the attack surface even for a VM configured in
cross-vendor mode, and we only need to cope with instructions which have
different #UD behaviour between vendors.

> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -3774,7 +3774,7 @@ x86_emulate(
>  emulate_fpu_insn_memsrc("flds", src.val);
>  dst.type = OP_NONE;
>  break;
> -case 2: /* fstp m32fp */
> +case 2: /* fst m32fp */

This change looks like it is spurious from a different patch?

~Andrew

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

Re: [Xen-devel] [PATCH v3] x86emul: support LAR/LSL/VERR/VERW

[Jan Beulich]

>>> On 03.01.17 at 15:56,  wrote:
> On 03/01/17 13:02, Jan Beulich wrote:
>> This involves protmode_load_seg() accepting x86_seg_none as input, with
>> the meaning to
>> - suppress any exceptions other than #PF,
>> - not commit any state.
>>
>> Signed-off-by: Jan Beulich 
> 
> Reviewed-by: Andrew Cooper , although I note
> you do introduce new uses of _regs.eflags.  Is this intentional, given
> your other register naming changes?

Yes, it is - in the insn emulator code we can't switch to _eflags yet
without breaking the 32-bit test harness build. Taking care of those
instances is going to be the subject of part 2 of the renaming
activity.

Jan


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

Re: [Xen-devel] [PATCH v3] x86emul: support LAR/LSL/VERR/VERW

[Andrew Cooper]

On 03/01/17 13:02, Jan Beulich wrote:
> This involves protmode_load_seg() accepting x86_seg_none as input, with
> the meaning to
> - suppress any exceptions other than #PF,
> - not commit any state.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper , although I note
you do introduce new uses of _regs.eflags.  Is this intentional, given
your other register naming changes?

~Andrew

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 32ea56f0a65b80324e3e651432bdf496a6fc55b7
baseline version:
 ovmf 7c6075e2546dd818b7b87090a983429b1942796a

Last test of basis   104006  2017-01-03 08:46:09 Z0 days
Testing same since   104009  2017-01-03 11:44:38 Z0 days1 attempts


People who touched revisions under test:
  Laszlo Ersek 

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



sg-report-flight on osstest.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=32ea56f0a65b80324e3e651432bdf496a6fc55b7
+ . ./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 
32ea56f0a65b80324e3e651432bdf496a6fc55b7
+ branch=ovmf
+ revision=32ea56f0a65b80324e3e651432bdf496a6fc55b7
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.8-testing
+ '[' x32ea56f0a65b80324e3e651432bdf496a6fc55b7 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : 

Re: [Xen-devel] [PATCH] x86emul: use unambiguous register names

[Jan Beulich]

>>> On 03.01.17 at 15:12,  wrote:
 On 03.01.17 at 14:30,  wrote:
>> On 03/01/17 13:01, Jan Beulich wrote:
>>> @@ -2716,36 +2716,36 @@ x86_emulate(
>>>  struct segment_register cs, sreg;
>>>  
>>>  case 0x00 ... 0x05: add: /* add */
>>> -emulate_2op_SrcV("add", src, dst, _regs.eflags);
>>> +emulate_2op_SrcV("add", src, dst, _regs.r(flags));
>>>  break;
>>>  
>> 
>> All of these types of operations only adjust the arithmetic flags, so
>> could legitimately use eflags alone.  Is it worth reducing?
> 
> Yes, but not now and here: Using _eflags breaks the inline asm which
> these macros resolve to.

Actually, after some staring at those macros I think this might be
relatively simple to deal with, so let me see if I can put together a
prereq patch allowing _eflags to be used here instead.

Jan


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

Re: [Xen-devel] [PATCH v2 05/10] x86/HVM/SVM: Add AVIC initialization code

[Boris Ostrovsky]

> +
> +#define AVIC_DOORBELL   0xc001011b

MSR_AVIC_DOORBELL (and it should probably go to include/asm-x86/msr-index.h)

> +
> +#define AVIC_HPA_SHIFT  12

Is there a reason not to use regular PAGE_SHIFT?

> +#define AVIC_HPA_MASK   (((1ULL << 40) - 1) << AVIC_HPA_SHIFT)
> +#define AVIC_VAPIC_BAR_MASK AVIC_HPA_MASK
> +
> +/*
> + * Note:
> + * Currently, svm-avic mode is not supported with nested virtualization.
> + * Therefore, it is not yet currently enabled by default. Once the support
> + * is in-place, this should be enabled by default.
> + */
> +bool svm_avic = 0;
> +boolean_param("svm-avic", svm_avic);
> +
> +static struct avic_phy_apic_id_ent *
> +avic_get_phy_apic_id_ent(const struct vcpu *v, unsigned int index)

Something like phys_apicid might be more descriptive.

> +{
> +struct avic_phy_apic_id_ent *avic_phy_apic_id_table;
> +struct svm_domain *d = >domain->arch.hvm_domain.svm;
> +
> +if ( !d->avic_phy_apic_id_table_mfn )
> +return NULL;
> +
> +/*
> +* Note: APIC ID = 0xff is used for broadcast.
> +*   APIC ID > 0xff is reserved.
> +*/
> +if ( index >= 0xff )
> +return NULL;
> +
> +avic_phy_apic_id_table = mfn_to_virt(d->avic_phy_apic_id_table_mfn);
> +
> +return _phy_apic_id_table[index];
> +}


> +}
> +
> +static inline u32 *
> +avic_get_bk_page_entry(const struct vcpu *v, u32 offset)
> +{
> +const struct vlapic *vlapic = vcpu_vlapic(v);
> +char *tmp;
> +
> +if ( !vlapic || !vlapic->regs_page )

Should this be changed to an ASSERT? I think this is only called from
places that already tested this or from places that you wouldn't get to
unless these both were true (like VMEXIT handler).

-boris


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

Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking

[Jan Beulich]

>>> On 03.01.17 at 15:38,  wrote:
> Jan Beulich writes ("Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict 
> -Werror checking"):
>> Alistair Francis  12/22/16 8:14 PM >>>
>> >Unfortunately the APPEND_CFLAGS=-Wno-error doesn't fix all the issues
>> >as I still see warnings/errors when building: tools/kconfig/conf.c.
>> 
>> Well, it's quite obvious that the same set of options (and hence overrides)
>> can't possibly fit both the build of target binaries and the build of build
>> helper tools (i.e. build host binaries).
> 
> I think that the example of `-Wno-error' shows that this is, in fact,
> false.  There are some overrides that, if desirable, apply equally
> everywhere.

I agree, but I don't think this is relevant here: How does one
easily(!) know that APPEND_CFLAGS affects both host and
target binaries? Just like there is HOSTCC and HOSTCFLAGS,
there should be (e.g.) APPEND_HOSTCFLAGS. What if
$(HOSTCC) doesn't even understand -Wno-error (or any other
option put into such a shared variable)?

> -Wno-error is a good example because it is mostly needed when a new
> compiler throws up new warnings for existing code.  Admittedly,
> -Wno-error may not be the best response, but it is often the most
> expedient, and we shouldn't make it unnecessarily hard for
> downstreams to support it.
> 
> For now I think the proposed approach, to make kconf build honour
> APPEND_CFLAGS, is good.  Do you agree, Jan ?
> 
> If someone wants to introduce HYPERVISOR_APPEND_CFLAGS and
> TOOLS_APPEND_CFLAGS, I don't object, but that should be a separate
> project.

As per above, I disagree. We shouldn't help people making
mistakes by lumping together two disjoint sets of flags.

Jan


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

[Xen-devel] [PATCH] uapi: use wildcards to list files

[Nicolas Dichtel]

Regularly, when a new header is created in include/uapi/, the developer
forgets to add it in the corresponding Kbuild file. This error is usually
detected after the release is out.

In fact, all headers under include/uapi/ should be exported, so let's
use wildcards.

After this patch, the following files, which were not exported, are now
exported:
drm/vgem_drm.h
drm/armada_drm.h
drm/omap_drm.h
drm/etnaviv_drm.h
rdma/qedr-abi.h
linux/bcache.h
linux/kfd_ioctl.h
linux/cryptouser.h
linux/kcm.h
linux/kcov.h
linux/seg6_iptunnel.h
linux/stm.h
linux/seg6.h
linux/auto_dev-ioctl.h
linux/userio.h
linux/pr.h
linux/wil6210_uapi.h
linux/nilfs2_ondisk.h
linux/hash_info.h
linux/seg6_genl.h
linux/seg6_hmac.h
linux/batman_adv.h
linux/nsfs.h
linux/qrtr.h
linux/btrfs_tree.h
linux/coresight-stm.h
linux/dma-buf.h
linux/module.h
linux/lightnvm.h
linux/nilfs2_api.h

Signed-off-by: Nicolas Dichtel 
---

This patch is built against linus tree. I don't know if it should be
done against antoher tree.

Comments are welcomed,
Nicolas

 include/uapi/asm-generic/Kbuild|  36 +--
 include/uapi/drm/Kbuild|  22 +-
 include/uapi/linux/Kbuild  | 463 +
 include/uapi/linux/android/Kbuild  |   2 +-
 include/uapi/linux/byteorder/Kbuild|   3 +-
 include/uapi/linux/caif/Kbuild |   3 +-
 include/uapi/linux/can/Kbuild  |   6 +-
 include/uapi/linux/dvb/Kbuild  |   9 +-
 include/uapi/linux/hdlc/Kbuild |   2 +-
 include/uapi/linux/hsi/Kbuild  |   2 +-
 include/uapi/linux/iio/Kbuild  |   3 +-
 include/uapi/linux/isdn/Kbuild |   2 +-
 include/uapi/linux/mmc/Kbuild  |   2 +-
 include/uapi/linux/netfilter/Kbuild|  88 +-
 include/uapi/linux/netfilter/ipset/Kbuild  |   5 +-
 include/uapi/linux/netfilter_arp/Kbuild|   3 +-
 include/uapi/linux/netfilter_bridge/Kbuild |  18 +-
 include/uapi/linux/netfilter_ipv4/Kbuild   |  10 +-
 include/uapi/linux/netfilter_ipv6/Kbuild   |  13 +-
 include/uapi/linux/nfsd/Kbuild |   6 +-
 include/uapi/linux/raid/Kbuild |   3 +-
 include/uapi/linux/spi/Kbuild  |   2 +-
 include/uapi/linux/sunrpc/Kbuild   |   2 +-
 include/uapi/linux/tc_act/Kbuild   |  15 +-
 include/uapi/linux/tc_ematch/Kbuild|   5 +-
 include/uapi/linux/usb/Kbuild  |  12 +-
 include/uapi/linux/wimax/Kbuild|   2 +-
 include/uapi/misc/Kbuild   |   2 +-
 include/uapi/mtd/Kbuild|   6 +-
 include/uapi/rdma/Kbuild   |  17 +-
 include/uapi/rdma/hfi/Kbuild   |   2 +-
 include/uapi/scsi/Kbuild   |   5 +-
 include/uapi/scsi/fc/Kbuild|   5 +-
 include/uapi/sound/Kbuild  |  16 +-
 include/uapi/video/Kbuild  |   4 +-
 include/uapi/xen/Kbuild|   5 +-
 36 files changed, 47 insertions(+), 754 deletions(-)

diff --git a/include/uapi/asm-generic/Kbuild b/include/uapi/asm-generic/Kbuild
index b73de7bb7a62..8e52cdc3d941 100644
--- a/include/uapi/asm-generic/Kbuild
+++ b/include/uapi/asm-generic/Kbuild
@@ -1,36 +1,2 @@
 # UAPI Header export list
-header-y += auxvec.h
-header-y += bitsperlong.h
-header-y += errno-base.h
-header-y += errno.h
-header-y += fcntl.h
-header-y += int-l64.h
-header-y += int-ll64.h
-header-y += ioctl.h
-header-y += ioctls.h
-header-y += ipcbuf.h
-header-y += kvm_para.h
-header-y += mman-common.h
-header-y += mman.h
-header-y += msgbuf.h
-header-y += param.h
-header-y += poll.h
-header-y += posix_types.h
-header-y += resource.h
-header-y += sembuf.h
-header-y += setup.h
-header-y += shmbuf.h
-header-y += shmparam.h
-header-y += siginfo.h
-header-y += signal-defs.h
-header-y += signal.h
-header-y += socket.h
-header-y += sockios.h
-header-y += stat.h
-header-y += statfs.h
-header-y += swab.h
-header-y += termbits.h
-header-y += termios.h
-header-y += types.h
-header-y += ucontext.h
-header-y += unistd.h
+header-y += $(notdir $(wildcard $(srctree)/include/uapi/asm-generic/*.h))
diff --git a/include/uapi/drm/Kbuild b/include/uapi/drm/Kbuild
index 9355dd8eff3b..75f4cde6d9ba 100644
--- a/include/uapi/drm/Kbuild
+++ b/include/uapi/drm/Kbuild
@@ -1,22 +1,2 @@
 # UAPI Header export list
-header-y += drm.h
-header-y += drm_fourcc.h
-header-y += drm_mode.h
-header-y += drm_sarea.h
-header-y += amdgpu_drm.h
-header-y += exynos_drm.h
-header-y += i810_drm.h
-header-y += i915_drm.h
-header-y += mga_drm.h
-header-y += nouveau_drm.h
-header-y += qxl_drm.h
-header-y += r128_drm.h
-header-y += radeon_drm.h
-header-y += savage_drm.h
-header-y += sis_drm.h
-header-y += tegra_drm.h
-header-y += via_drm.h
-header-y += vmwgfx_drm.h
-header-y += msm_drm.h
-header-y += vc4_drm.h
-header-y += virtgpu_drm.h
+header-y += $(notdir $(wildcard $(srctree)/include/uapi/drm/*.h))
diff --git a/include/uapi/linux/Kbuild 

Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking

[Ian Jackson]

Jan Beulich writes ("Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict 
-Werror checking"):
> Alistair Francis  12/22/16 8:14 PM >>>
> >Unfortunately the APPEND_CFLAGS=-Wno-error doesn't fix all the issues
> >as I still see warnings/errors when building: tools/kconfig/conf.c.
> 
> Well, it's quite obvious that the same set of options (and hence overrides)
> can't possibly fit both the build of target binaries and the build of build
> helper tools (i.e. build host binaries).

I think that the example of `-Wno-error' shows that this is, in fact,
false.  There are some overrides that, if desirable, apply equally
everywhere.

-Wno-error is a good example because it is mostly needed when a new
compiler throws up new warnings for existing code.  Admittedly,
-Wno-error may not be the best response, but it is often the most
expedient, and we shouldn't make it unnecessarily hard for
downstreams to support it.

For now I think the proposed approach, to make kconf build honour
APPEND_CFLAGS, is good.  Do you agree, Jan ?

If someone wants to introduce HYPERVISOR_APPEND_CFLAGS and
TOOLS_APPEND_CFLAGS, I don't object, but that should be a separate
project.

Ian.

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

Re: [Xen-devel] [PATCH] x86emul: use unambiguous register names

[Andrew Cooper]

On 03/01/17 14:12, Jan Beulich wrote:
>
>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.h
>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.h
>>> @@ -583,41 +583,9 @@ x86_emulate(
>>>  const struct x86_emulate_ops *ops);
>>>  
>>>  #ifndef NDEBUG
>>> -/*
>>> - * In debug builds, wrap x86_emulate() with some assertions about its 
>>> expected
>>> - * behaviour.
>>> - */
>> I'd leave this comment here as well.
> Hmm, in that case I'd drop it at the definition site. I don't think we
> need to have the comment in both places. What do you think?

If you insist on only having it in one place, I'd err on having it in
the header file.

~Andrew

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

Re: [Xen-devel] [PATCH] x86emul: use unambiguous register names

[Jan Beulich]

>>> On 03.01.17 at 14:30,  wrote:
> On 03/01/17 13:01, Jan Beulich wrote:
>> --- a/xen/arch/x86/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate.c
>> @@ -21,6 +21,8 @@
>>  #undef cpuid
>>  #undef wbinvd
>>  
>> +#define r(name) r ## name
>> +
> 
> Hmm.  I am no overwhelmed with this syntax, but I can't propose an
> alternative, so ok.

I kind of suspected such a response.

>> @@ -2716,36 +2716,36 @@ x86_emulate(
>>  struct segment_register cs, sreg;
>>  
>>  case 0x00 ... 0x05: add: /* add */
>> -emulate_2op_SrcV("add", src, dst, _regs.eflags);
>> +emulate_2op_SrcV("add", src, dst, _regs.r(flags));
>>  break;
>>  
> 
> All of these types of operations only adjust the arithmetic flags, so
> could legitimately use eflags alone.  Is it worth reducing?

Yes, but not now and here: Using _eflags breaks the inline asm which
these macros resolve to.

>> --- a/xen/arch/x86/x86_emulate/x86_emulate.h
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.h
>> @@ -583,41 +583,9 @@ x86_emulate(
>>  const struct x86_emulate_ops *ops);
>>  
>>  #ifndef NDEBUG
>> -/*
>> - * In debug builds, wrap x86_emulate() with some assertions about its 
>> expected
>> - * behaviour.
>> - */
> 
> I'd leave this comment here as well.

Hmm, in that case I'd drop it at the definition site. I don't think we
need to have the comment in both places. What do you think?

> Otherwise, Reviewed-by: Andrew Cooper 

Thanks (but I'll wait for your feedback to the above),
Jan


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

[Xen-devel] [PATCH v6 07/12] pvh: Send an SCI on VCPU hotplug event

[Boris Ostrovsky]

Send and SCI when VCPU map is updated by domctl or when guest sets
GPE0 enable bit and status bit is already set.

Also update send_guest_global_virq() to handle cases when VCPU0
is offlined.

Signed-off-by: Boris Ostrovsky 
---
Changes in v6:
* Change conditions causing the SCI to be generated:
  - domctl write to VCPU map
  - Enabling a pending GPE0 event


 xen/arch/x86/hvm/acpi.c| 20 
 xen/common/event_channel.c |  7 +--
 xen/include/xen/domain.h   |  1 +
 xen/include/xen/event.h|  8 
 4 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/acpi.c b/xen/arch/x86/hvm/acpi.c
index 9f0578e..946640e 100644
--- a/xen/arch/x86/hvm/acpi.c
+++ b/xen/arch/x86/hvm/acpi.c
@@ -4,6 +4,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -85,6 +86,17 @@ int hvm_acpi_domctl_access(struct domain *d,
 return -EFAULT;
 }
 
+/*
+ * For simplicity don't verify whether CPU map changed and
+ * always send an SCI on a write (provided it's enabled).
+ */
+if ( is_write )
+{
+d->arch.hvm_domain.acpi.gpe0_sts |= 1U << XEN_ACPI_GPE0_CPUHP_BIT;
+if ( d->arch.hvm_domain.acpi.gpe0_en & (1U << XEN_ACPI_GPE0_CPUHP_BIT) 
)
+send_guest_global_virq(d, VIRQ_SCI);
+}
+
 return 0;
 }
 
@@ -144,6 +156,7 @@ static int acpi_guest_access(int dir, unsigned int port,
 else
 {
 uint32_t v = *val;
+uint16_t en_orig = *en;
 
 /* Status register is write-1-to-clear */
 switch ( port & 3 )
@@ -170,6 +183,13 @@ static int acpi_guest_access(int dir, unsigned int port,
 *en = (((v & 0xff) << 8) | (*en & 0xff)) & *mask_en;
 break;
 }
+
+/*
+ * If an event became enabled and corresponding status bit is set
+ * then send an SCI to the guest.
+ */
+if ( (*en & ~en_orig) & *sts )
+send_guest_global_virq(d, VIRQ_SCI);
 }
 
 return X86EMUL_OKAY;
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 638dc5e..1d77373 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -727,7 +727,7 @@ void send_guest_vcpu_virq(struct vcpu *v, uint32_t virq)
 spin_unlock_irqrestore(>virq_lock, flags);
 }
 
-static void send_guest_global_virq(struct domain *d, uint32_t virq)
+void send_guest_global_virq(struct domain *d, uint32_t virq)
 {
 unsigned long flags;
 int port;
@@ -739,7 +739,10 @@ static void send_guest_global_virq(struct domain *d, 
uint32_t virq)
 if ( unlikely(d == NULL) || unlikely(d->vcpu == NULL) )
 return;
 
-v = d->vcpu[0];
+/* Send to first available VCPU */
+for_each_vcpu(d, v)
+if ( is_vcpu_online(v) )
+break;
 if ( unlikely(v == NULL) )
 return;
 
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index bce0ea1..b386038 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -52,6 +52,7 @@ void vcpu_destroy(struct vcpu *v);
 int map_vcpu_info(struct vcpu *v, unsigned long gfn, unsigned offset);
 void unmap_vcpu_info(struct vcpu *v);
 
+int arch_update_avail_vcpus(struct domain *d);
 int arch_domain_create(struct domain *d, unsigned int domcr_flags,
struct xen_arch_domainconfig *config);
 
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 5008c80..74bd605 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -23,6 +23,14 @@
 void send_guest_vcpu_virq(struct vcpu *v, uint32_t virq);
 
 /*
+ * send_guest_global_virq: Notify guest via a global VIRQ.
+ *  @d:domain to which virtual IRQ should be sent. First
+ * online VCPU will be selected.
+ *  @virq: Virtual IRQ number (VIRQ_*)
+ */
+void send_guest_global_virq(struct domain *d, uint32_t virq);
+
+/*
  * send_global_virq: Notify the domain handling a global VIRQ.
  *  @virq: Virtual IRQ number (VIRQ_*)
  */
-- 
2.7.4


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

[Xen-devel] [PATCH v6 10/12] pvh: Set online VCPU map to avail_vcpus

[Boris Ostrovsky]

ACPI builder marks VCPUS set in vcpu_online map as enabled in MADT.
With ACPI-based CPU hotplug we only want VCPUs that are started by
the guest to be marked as such. Remaining VCPUs will be set to
"enable" by AML code during hotplug.

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Konrad Rzeszutek Wilk 
Acked-by: Wei Liu 
---
 tools/libxl/libxl_x86_acpi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_x86_acpi.c b/tools/libxl/libxl_x86_acpi.c
index c0a6e32..08178d6 100644
--- a/tools/libxl/libxl_x86_acpi.c
+++ b/tools/libxl/libxl_x86_acpi.c
@@ -98,7 +98,7 @@ static int init_acpi_config(libxl__gc *gc,
 uint32_t domid = dom->guest_domid;
 xc_dominfo_t info;
 struct hvm_info_table *hvminfo;
-int i, r, rc;
+int r, rc;
 
 config->dsdt_anycpu = config->dsdt_15cpu = dsdt_pvh;
 config->dsdt_anycpu_len = config->dsdt_15cpu_len = dsdt_pvh_len;
@@ -147,8 +147,8 @@ static int init_acpi_config(libxl__gc *gc,
 hvminfo->nr_vcpus = info.max_vcpu_id + 1;
 }
 
-for (i = 0; i < hvminfo->nr_vcpus; i++)
-hvminfo->vcpu_online[i / 8] |= 1 << (i & 7);
+memcpy(hvminfo->vcpu_online, b_info->avail_vcpus.map,
+   b_info->avail_vcpus.size);
 
 config->hvminfo = hvminfo;
 
-- 
2.7.4


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

[Xen-devel] [PATCH v6 12/12] docs: Describe PVHv2's VCPU hotplug procedure

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Konrad Rzeszutek Wilk 
---
CC: George Dunlap 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Tim Deegan 
---
Changes in v6:
* No GPE0 update is needed anymore.

 docs/misc/hvmlite.markdown | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/docs/misc/hvmlite.markdown b/docs/misc/hvmlite.markdown
index 898b8ee..472edee 100644
--- a/docs/misc/hvmlite.markdown
+++ b/docs/misc/hvmlite.markdown
@@ -75,3 +75,14 @@ info structure that's passed at boot time (field rsdp_paddr).
 
 Description of paravirtualized devices will come from XenStore, just as it's
 done for HVM guests.
+
+## VCPU hotplug ##
+
+VCPU hotplug (e.g. 'xl vcpu-set  ') for PVHv2 guests
+follows ACPI model where change in domain's number of VCPUS (stored in
+domain.avail_vcpus) results in an SCI being sent to the guest. The guest
+then executes DSDT's PRSC method, updating MADT enable status for the
+affected VCPU.
+
+Updating VCPU number is achieved by having the toolstack issue a write to
+ACPI's XEN_ACPI_CPU_MAP.
-- 
2.7.4


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

[Xen-devel] [PATCH v6 11/12] pvh/acpi: Save ACPI registers for PVH guests

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
---
Can't generate SCI over event channel during is an event
is enabled and pending:
* v->virq_to_evtchn is not initialized yet (it's done by guest)
* The SCI is sent immediately after event is made pending so it's
  not possible to miss it (at least for the only event that have)


 xen/arch/x86/hvm/pmtimer.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/xen/arch/x86/hvm/pmtimer.c b/xen/arch/x86/hvm/pmtimer.c
index b70c299..e96805e 100644
--- a/xen/arch/x86/hvm/pmtimer.c
+++ b/xen/arch/x86/hvm/pmtimer.c
@@ -22,6 +22,7 @@
 #include 
 #include  /* for hvm_acpi_power_button prototype */
 #include 
+#include 
 
 /* Slightly more readable port I/O addresses for the registers we intercept */
 #define PM1a_STS_ADDR_V0 (ACPI_PM1A_EVT_BLK_ADDRESS_V0)
@@ -257,7 +258,11 @@ static int acpi_save(struct domain *d, 
hvm_domain_context_t *h)
 int rc;
 
 if ( !has_vpm(d) )
+{
+if ( !has_acpi_dm_ff(d) )
+return hvm_save_entry(PMTIMER, 0, h, acpi);
 return 0;
+}
 
 spin_lock(>lock);
 
@@ -286,7 +291,11 @@ static int acpi_load(struct domain *d, 
hvm_domain_context_t *h)
 PMTState *s = >arch.hvm_domain.pl_time->vpmt;
 
 if ( !has_vpm(d) )
+{
+if ( !has_acpi_dm_ff(d) )
+return hvm_load_entry(PMTIMER, h, acpi);
 return -ENODEV;
+}
 
 spin_lock(>lock);
 
-- 
2.7.4


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

[Xen-devel] [PATCH v6 04/12] pvh/acpi: Handle ACPI accesses for PVH guests

[Boris Ostrovsky]

Subsequent domctl access  VCPU map will use the same code. We create 
acpi_cpumap_access_common() routines in anticipation of these changes.

Signed-off-by: Boris Ostrovsky 
---
Changes in v6:
* ACPI registers are only accessed by guest code (not by domctl), thus
  acpi_access_common() is no longer needed
* Adjusted access direction (RW) to be a boolean.
* Dropped unnecessary masking of status register

 xen/arch/x86/hvm/acpi.c | 110 +++-
 xen/common/domain.c |   1 +
 xen/common/domctl.c |   5 +++
 xen/include/xen/sched.h |   3 ++
 4 files changed, 117 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/acpi.c b/xen/arch/x86/hvm/acpi.c
index 15a9a0e..f0a84f9 100644
--- a/xen/arch/x86/hvm/acpi.c
+++ b/xen/arch/x86/hvm/acpi.c
@@ -2,12 +2,43 @@
  *
  * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
  */
+#include 
 #include 
 #include 
 #include 
 
 #include 
 
+static int acpi_cpumap_access_common(struct domain *d, bool is_write,
+ unsigned int port,
+ unsigned int bytes, uint32_t *val)
+{
+unsigned int first_byte = port - XEN_ACPI_CPU_MAP;
+
+BUILD_BUG_ON(XEN_ACPI_CPU_MAP + XEN_ACPI_CPU_MAP_LEN
+ > ACPI_GPE0_BLK_ADDRESS_V1);
+
+if ( !is_write )
+{
+uint32_t mask = (bytes < 4) ? ~0U << (bytes * 8) : 0;
+
+/*
+ * Clear bits that we are about to read to in case we
+ * copy fewer than @bytes.
+ */
+*val &= mask;
+
+if ( ((d->max_vcpus + 7) / 8) > first_byte )
+memcpy(val, (uint8_t *)d->avail_vcpus + first_byte,
+   min(bytes, ((d->max_vcpus + 7) / 8) - first_byte));
+}
+else
+/* Guests do not write CPU map */
+return X86EMUL_UNHANDLEABLE;
+
+return X86EMUL_OKAY;
+}
+
 int hvm_acpi_domctl_access(struct domain *d,
const struct xen_domctl_acpi_access *access)
 {
@@ -17,13 +48,88 @@ int hvm_acpi_domctl_access(struct domain *d,
 static int acpi_cpumap_guest_access(int dir, unsigned int port,
 unsigned int bytes, uint32_t *val)
 {
-return X86EMUL_UNHANDLEABLE;
+return  acpi_cpumap_access_common(current->domain,
+  (dir == IOREQ_WRITE) ? true : false,
+  port, bytes, val);
 }
 
 static int acpi_guest_access(int dir, unsigned int port,
  unsigned int bytes, uint32_t *val)
 {
-return X86EMUL_UNHANDLEABLE;
+struct domain *d = current->domain;
+uint16_t *sts = NULL, *en = NULL;
+const uint16_t *mask_en = NULL;
+static const uint16_t pm1a_en_mask = ACPI_BITMASK_GLOBAL_LOCK_ENABLE;
+static const uint16_t gpe0_en_mask = 1U << XEN_ACPI_GPE0_CPUHP_BIT;
+
+ASSERT(!has_acpi_dm_ff(d));
+
+switch ( port )
+{
+case ACPI_PM1A_EVT_BLK_ADDRESS_V1 ...
+ACPI_PM1A_EVT_BLK_ADDRESS_V1 +
+sizeof(d->arch.hvm_domain.acpi.pm1a_sts) +
+sizeof(d->arch.hvm_domain.acpi.pm1a_en):
+
+sts = >arch.hvm_domain.acpi.pm1a_sts;
+en = >arch.hvm_domain.acpi.pm1a_en;
+mask_en = _en_mask;
+break;
+
+case ACPI_GPE0_BLK_ADDRESS_V1 ...
+ACPI_GPE0_BLK_ADDRESS_V1 +
+sizeof(d->arch.hvm_domain.acpi.gpe0_sts) +
+sizeof(d->arch.hvm_domain.acpi.gpe0_en):
+
+sts = >arch.hvm_domain.acpi.gpe0_sts;
+en = >arch.hvm_domain.acpi.gpe0_en;
+mask_en = _en_mask;
+break;
+
+default:
+return X86EMUL_UNHANDLEABLE;
+}
+
+if ( dir == IOREQ_READ )
+{
+uint32_t mask = (bytes < 4) ? ~0U << (bytes * 8) : 0;
+uint32_t data = (((uint32_t)*en) << 16) | *sts;
+
+data >>= 8 * (port & 3);
+*val = (*val & mask) | (data & ~mask);
+}
+else
+{
+uint32_t v = *val;
+
+/* Status register is write-1-to-clear */
+switch ( port & 3 )
+{
+case 0:
+*sts &= ~(v & 0xff);
+if ( !--bytes )
+break;
+v >>= 8;
+/* fallthrough */
+case 1:
+*sts &= ~((v & 0xff) << 8);
+if ( !--bytes )
+break;
+v >>= 8;
+/* fallthrough */
+case 2:
+*en = ((*en & 0xff00) | (v & 0xff)) & *mask_en;
+if ( !--bytes )
+break;
+v >>= 8;
+/* fallthrough */
+case 3:
+*en = (((v & 0xff) << 8) | (*en & 0xff)) & *mask_en;
+break;
+}
+}
+
+return X86EMUL_OKAY;
 }
 
 void hvm_acpi_init(struct domain *d)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 05130e2..ca1f0ed 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -847,6 +847,7 @@ static void complete_domain_destroy(struct rcu_head *head)
 

[Xen-devel] [PATCH v6 03/12] pvh/acpi: Install handlers for ACPI-related PVH IO accesses

[Boris Ostrovsky]

PVH guests will have ACPI accesses emulated by the hypervisor as
opposed to QEMU (as is the case for HVM guests). This patch installs
handler for accesses to PM1A, GPE0 (which is added to struct
hvm_hw_acpi) and VCPU map. Logic for the handler will be provided
by a later patch.

Whether or not the handler needs to be installed is decided based
on the value of XEN_X86_EMU_ACPI_FF flag which indicates whether
emulation is implemented in QEMU.

Signed-off-by: Boris Ostrovsky 
---
Changes in v6:
* Drop ifdef guards in include/public/arch-x86/hvm/save.h

 xen/arch/x86/hvm/acpi.c| 31 +++
 xen/arch/x86/hvm/hvm.c |  2 ++
 xen/include/asm-x86/domain.h   |  2 ++
 xen/include/asm-x86/hvm/domain.h   |  1 +
 xen/include/public/arch-x86/hvm/save.h | 21 +++--
 xen/include/public/arch-x86/xen.h  |  4 +++-
 6 files changed, 58 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/acpi.c b/xen/arch/x86/hvm/acpi.c
index 04901c1..15a9a0e 100644
--- a/xen/arch/x86/hvm/acpi.c
+++ b/xen/arch/x86/hvm/acpi.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 
+#include 
 
 int hvm_acpi_domctl_access(struct domain *d,
const struct xen_domctl_acpi_access *access)
@@ -13,6 +14,36 @@ int hvm_acpi_domctl_access(struct domain *d,
 return -ENOSYS;
 }
 
+static int acpi_cpumap_guest_access(int dir, unsigned int port,
+unsigned int bytes, uint32_t *val)
+{
+return X86EMUL_UNHANDLEABLE;
+}
+
+static int acpi_guest_access(int dir, unsigned int port,
+ unsigned int bytes, uint32_t *val)
+{
+return X86EMUL_UNHANDLEABLE;
+}
+
+void hvm_acpi_init(struct domain *d)
+{
+if ( has_acpi_dm_ff(d) )
+return;
+
+register_portio_handler(d, XEN_ACPI_CPU_MAP,
+XEN_ACPI_CPU_MAP_LEN, acpi_cpumap_guest_access);
+
+register_portio_handler(d, ACPI_GPE0_BLK_ADDRESS_V1,
+sizeof(d->arch.hvm_domain.acpi.gpe0_sts) +
+sizeof(d->arch.hvm_domain.acpi.gpe0_en),
+acpi_guest_access);
+register_portio_handler(d, ACPI_PM1A_EVT_BLK_ADDRESS_V1,
+sizeof(d->arch.hvm_domain.acpi.pm1a_sts) +
+sizeof(d->arch.hvm_domain.acpi.pm1a_en),
+acpi_guest_access);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 708f474..d0dd9fc 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -667,6 +667,8 @@ int hvm_domain_initialise(struct domain *d)
 
 hvm_ioreq_init(d);
 
+hvm_acpi_init(d);
+
 if ( is_pvh_domain(d) )
 {
 register_portio_handler(d, 0, 0x10003, handle_pvh_io);
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 95762cf..233233a 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -426,6 +426,8 @@ struct arch_domain
 #define has_vvga(d)(!!((d)->arch.emulation_flags & XEN_X86_EMU_VGA))
 #define has_viommu(d)  (!!((d)->arch.emulation_flags & XEN_X86_EMU_IOMMU))
 #define has_vpit(d)(!!((d)->arch.emulation_flags & XEN_X86_EMU_PIT))
+#define has_acpi_dm_ff(d)  (!!((d)->arch.emulation_flags & \
+   XEN_X86_EMU_ACPI_DM_FF))
 
 #define has_arch_pdevs(d)(!list_empty(&(d)->arch.pdev_list))
 
diff --git a/xen/include/asm-x86/hvm/domain.h b/xen/include/asm-x86/hvm/domain.h
index 52f934a..07815b6 100644
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -166,6 +166,7 @@ struct hvm_domain {
 
 #define hap_enabled(d)  ((d)->arch.hvm_domain.hap_enabled)
 
+void hvm_acpi_init(struct domain *d);
 int hvm_acpi_domctl_access(struct domain *d,
const struct xen_domctl_acpi_access *access);
 
diff --git a/xen/include/public/arch-x86/hvm/save.h 
b/xen/include/public/arch-x86/hvm/save.h
index ee0a3f7..f47fd21 100644
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -529,14 +529,31 @@ DECLARE_HVM_SAVE_TYPE(HPET, 12, struct hvm_hw_hpet);
 /*
  * PM timer
  */
-
 struct hvm_hw_pmtimer {
 uint32_t tmr_val;   /* PM_TMR_BLK.TMR_VAL: 32bit free-running counter */
 uint16_t pm1a_sts;  /* PM1a_EVT_BLK.PM1a_STS: status register */
 uint16_t pm1a_en;   /* PM1a_EVT_BLK.PM1a_EN: enable register */
+uint16_t gpe0_sts;
+uint16_t gpe0_en;
+};
+
+struct hvm_hw_pmtimer_compat {
+uint32_t tmr_val;
+uint16_t pm1a_sts;
+uint16_t pm1a_en;
 };
 
-DECLARE_HVM_SAVE_TYPE(PMTIMER, 13, struct hvm_hw_pmtimer);
+static inline int _hvm_hw_fix_pmtimer(void *h, uint32_t size)
+{
+struct hvm_hw_pmtimer *acpi = (struct hvm_hw_pmtimer *)h;
+
+if ( size == sizeof(struct hvm_hw_pmtimer_compat) )
+acpi->gpe0_sts = acpi->gpe0_en = 0;
+return 0;
+}
+

[Xen-devel] [PATCH v6 09/12] tools: Call XEN_DOMCTL_acpi_access on PVH VCPU hotplug

[Boris Ostrovsky]

Provide libxc interface for accessing ACPI via XEN_DOMCTL_acpi_access.

When a VCPU is hot-(un)plugged to/from a PVH guest update VCPU map
by writing to ACPI's XEN_ACPI_CPU_MAP register and then set GPE0
status bit in GPE0.status.

Signed-off-by: Boris Ostrovsky 
---
Changes in v6:
* Fix xc_acpi_access() by updating the val pointer passed to the hypercall
  and take some domctl initializers out of the loop
* Don't update GPE0 status on VCPU map update as it is no longer necessary


 tools/libxc/include/xenctrl.h | 20 
 tools/libxc/xc_domain.c   | 41 +
 tools/libxl/libxl.c   |  4 
 tools/libxl/libxl_arch.h  |  4 
 tools/libxl/libxl_arm.c   |  6 ++
 tools/libxl/libxl_dom.c   | 10 ++
 tools/libxl/libxl_x86.c   | 11 +++
 7 files changed, 96 insertions(+)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 4ab0f57..3d771bc 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2710,6 +2710,26 @@ int xc_livepatch_revert(xc_interface *xch, char *name, 
uint32_t timeout);
 int xc_livepatch_unload(xc_interface *xch, char *name, uint32_t timeout);
 int xc_livepatch_replace(xc_interface *xch, char *name, uint32_t timeout);
 
+int xc_acpi_access(xc_interface *xch, domid_t domid,
+   uint8_t rw, uint8_t space_id, unsigned long addr,
+   unsigned int bytes, void *val);
+
+static inline int xc_acpi_ioread(xc_interface *xch, domid_t domid,
+ unsigned long port,
+ unsigned int bytes, void *val)
+{
+return xc_acpi_access(xch, domid, XEN_DOMCTL_ACPI_READ, XEN_ACPI_SYSTEM_IO,
+  port, bytes, val);
+}
+
+static inline int xc_acpi_iowrite(xc_interface *xch, domid_t domid,
+  unsigned long port,
+  unsigned int bytes, void *val)
+{
+return xc_acpi_access(xch, domid, XEN_DOMCTL_ACPI_WRITE, 
XEN_ACPI_SYSTEM_IO,
+  port, bytes, val);
+}
+
 /* Compat shims */
 #include "xenctrl_compat.h"
 
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 296b852..ed1dddb 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -2520,6 +2520,47 @@ int xc_domain_soft_reset(xc_interface *xch,
 domctl.domain = (domid_t)domid;
 return do_domctl(xch, );
 }
+
+int
+xc_acpi_access(xc_interface *xch, domid_t domid,
+   uint8_t rw, uint8_t space_id,
+   unsigned long address, unsigned int bytes, void *val)
+{
+DECLARE_DOMCTL;
+DECLARE_HYPERCALL_BOUNCE(val, bytes, XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
+struct xen_domctl_acpi_access *access = _access;
+unsigned int max_bytes = (1U << (sizeof(access->width) * 8)) - 1;
+int ret;
+
+memset(, 0, sizeof(domctl));
+domctl.domain = domid;
+domctl.cmd = XEN_DOMCTL_acpi_access;
+access->space_id = space_id;
+access->rw = rw;
+access->address = address;
+
+if ( (ret = xc_hypercall_bounce_pre(xch, val)) )
+return ret;
+
+while ( bytes != 0 )
+{
+access->width = bytes < max_bytes ? bytes : max_bytes;
+set_xen_guest_handle_offset(domctl.u.acpi_access.val,
+val, access->address - address);
+
+if ( (ret = do_domctl(xch, )) )
+ goto out;
+
+bytes -= access->width;
+access->address += access->width;
+}
+
+ out:
+xc_hypercall_bounce_post(xch, val);
+
+return ret;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 3de..d8306ff 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5147,7 +5147,11 @@ int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, 
libxl_bitmap *cpumap)
 case LIBXL_DOMAIN_TYPE_HVM:
 switch (libxl__device_model_version_running(gc, domid)) {
 case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
+break;
 case LIBXL_DEVICE_MODEL_VERSION_NONE:
+rc = libxl__arch_set_vcpuonline(gc, domid, cpumap);
+if (rc < 0)
+LOGE(ERROR, "Can't change vcpu online map (%d)", rc);
 break;
 case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
 rc = libxl__set_vcpuonline_qmp(gc, domid, cpumap, );
diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
index 5e1fc60..9649c21 100644
--- a/tools/libxl/libxl_arch.h
+++ b/tools/libxl/libxl_arch.h
@@ -71,6 +71,10 @@ int libxl__arch_extra_memory(libxl__gc *gc,
  const libxl_domain_build_info *info,
  uint64_t *out);
 
+_hidden
+int libxl__arch_set_vcpuonline(libxl__gc *gc, uint32_t domid,
+   libxl_bitmap *cpumap);
+
 #if defined(__i386__) || defined(__x86_64__)
 
 #define LAPIC_BASE_ADDRESS  

[Xen-devel] [PATCH v6 05/12] x86/domctl: Handle ACPI access from domctl

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
---
Changes in v6:
* Adjustments to to patch 4 changes.
* Added a spinlock for VCPU map access
* Return an error on guest trying to write VCPU map

 xen/arch/x86/hvm/acpi.c  | 57 +++-
 xen/include/asm-x86/hvm/domain.h |  1 +
 2 files changed, 52 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/hvm/acpi.c b/xen/arch/x86/hvm/acpi.c
index f0a84f9..9f0578e 100644
--- a/xen/arch/x86/hvm/acpi.c
+++ b/xen/arch/x86/hvm/acpi.c
@@ -7,17 +7,22 @@
 #include 
 #include 
 
+#include 
+
 #include 
 
-static int acpi_cpumap_access_common(struct domain *d, bool is_write,
- unsigned int port,
+static int acpi_cpumap_access_common(struct domain *d, bool is_guest_access,
+ bool is_write, unsigned int port,
  unsigned int bytes, uint32_t *val)
 {
 unsigned int first_byte = port - XEN_ACPI_CPU_MAP;
+int rc = X86EMUL_OKAY;
 
 BUILD_BUG_ON(XEN_ACPI_CPU_MAP + XEN_ACPI_CPU_MAP_LEN
  > ACPI_GPE0_BLK_ADDRESS_V1);
 
+spin_lock(>arch.hvm_domain.acpi_lock);
+
 if ( !is_write )
 {
 uint32_t mask = (bytes < 4) ? ~0U << (bytes * 8) : 0;
@@ -32,23 +37,61 @@ static int acpi_cpumap_access_common(struct domain *d, bool 
is_write,
 memcpy(val, (uint8_t *)d->avail_vcpus + first_byte,
min(bytes, ((d->max_vcpus + 7) / 8) - first_byte));
 }
+else if ( !is_guest_access )
+memcpy((uint8_t *)d->avail_vcpus + first_byte, val,
+   min(bytes, ((d->max_vcpus + 7) / 8) - first_byte));
 else
 /* Guests do not write CPU map */
-return X86EMUL_UNHANDLEABLE;
+rc = X86EMUL_UNHANDLEABLE;
 
-return X86EMUL_OKAY;
+spin_unlock(>arch.hvm_domain.acpi_lock);
+
+return rc;
 }
 
 int hvm_acpi_domctl_access(struct domain *d,
const struct xen_domctl_acpi_access *access)
 {
-return -ENOSYS;
+unsigned int bytes, i;
+uint32_t val = 0;
+uint8_t *ptr = (uint8_t *)
+int rc;
+bool is_write = (access->rw == XEN_DOMCTL_ACPI_WRITE) ? true : false;
+
+if ( has_acpi_dm_ff(d) )
+return -EOPNOTSUPP;
+
+if ( access->space_id != XEN_ACPI_SYSTEM_IO )
+return -EINVAL;
+
+if ( !((access->address >= XEN_ACPI_CPU_MAP) &&
+   (access->address < XEN_ACPI_CPU_MAP + XEN_ACPI_CPU_MAP_LEN)) )
+return -ENODEV;
+
+for ( i = 0; i < access->width; i += sizeof(val) )
+{
+bytes = (access->width - i > sizeof(val)) ?
+sizeof(val) : access->width - i;
+
+if ( is_write && copy_from_guest_offset(ptr, access->val, i, bytes) )
+return -EFAULT;
+
+rc = acpi_cpumap_access_common(d, false, is_write,
+   access->address, bytes, );
+if ( rc )
+return rc;
+
+if ( !is_write && copy_to_guest_offset(access->val, i, ptr, bytes) )
+return -EFAULT;
+}
+
+return 0;
 }
 
 static int acpi_cpumap_guest_access(int dir, unsigned int port,
 unsigned int bytes, uint32_t *val)
 {
-return  acpi_cpumap_access_common(current->domain,
+return  acpi_cpumap_access_common(current->domain, true,
   (dir == IOREQ_WRITE) ? true : false,
   port, bytes, val);
 }
@@ -148,6 +191,8 @@ void hvm_acpi_init(struct domain *d)
 sizeof(d->arch.hvm_domain.acpi.pm1a_sts) +
 sizeof(d->arch.hvm_domain.acpi.pm1a_en),
 acpi_guest_access);
+
+spin_lock_init(>arch.hvm_domain.acpi_lock);
 }
 
 /*
diff --git a/xen/include/asm-x86/hvm/domain.h b/xen/include/asm-x86/hvm/domain.h
index 07815b6..438ea12 100644
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -111,6 +111,7 @@ struct hvm_domain {
  */
 #define hvm_hw_acpi hvm_hw_pmtimer
 struct hvm_hw_acpi acpi;
+spinlock_t acpi_lock;
 
 /* VCPU which is current target for 8259 interrupts. */
 struct vcpu   *i8259_target;
-- 
2.7.4


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

[Xen-devel] [PATCH v6 00/12] PVH VCPU hotplug support

[Boris Ostrovsky]

This series adds support for ACPI-based VCPU hotplug for unprivileged
PVH guests.

Main changes in v6:
* Generate SCI on VCPU map update by domctl
* Simplify public domctl structure
* Make ACPI registers accessible only by guest (and not by domctl)
* Update VCPU map under lock
* Fix pointer update in xc_acpi_access()

Boris Ostrovsky (12):
  domctl: Add XEN_DOMCTL_acpi_access
  x86/save: public/arch-x86/hvm/save.h is available to hypervisor and
tools only
  pvh/acpi: Install handlers for ACPI-related PVH IO accesses
  pvh/acpi: Handle ACPI accesses for PVH guests
  x86/domctl: Handle ACPI access from domctl
  events/x86: Define SCI virtual interrupt
  pvh: Send an SCI on VCPU hotplug event
  libxl: Update xenstore on VCPU hotplug for all guest types
  tools: Call XEN_DOMCTL_acpi_access on PVH VCPU hotplug
  pvh: Set online VCPU map to avail_vcpus
  pvh/acpi: Save ACPI registers for PVH guests
  docs: Describe PVHv2's VCPU hotplug procedure

 docs/misc/hvmlite.markdown |  13 ++
 tools/flask/policy/modules/dom0.te |   2 +-
 tools/flask/policy/modules/xen.if  |   4 +-
 tools/libxc/include/xenctrl.h  |  20 +++
 tools/libxc/xc_domain.c|  41 ++
 tools/libxl/libxl.c|  10 +-
 tools/libxl/libxl_arch.h   |   4 +
 tools/libxl/libxl_arm.c|   6 +
 tools/libxl/libxl_dom.c|  10 ++
 tools/libxl/libxl_x86.c|  11 ++
 tools/libxl/libxl_x86_acpi.c   |   6 +-
 xen/arch/x86/domctl.c  |   7 +
 xen/arch/x86/hvm/Makefile  |   1 +
 xen/arch/x86/hvm/acpi.c| 226 +
 xen/arch/x86/hvm/hvm.c |   2 +
 xen/arch/x86/hvm/pmtimer.c |   9 ++
 xen/common/domain.c|   1 +
 xen/common/domctl.c|   5 +
 xen/common/event_channel.c |   7 +-
 xen/include/asm-x86/domain.h   |   2 +
 xen/include/asm-x86/hvm/domain.h   |   5 +
 xen/include/public/arch-x86/hvm/save.h |  25 +++-
 xen/include/public/arch-x86/xen.h  |   7 +-
 xen/include/public/domctl.h|  17 +++
 xen/include/xen/domain.h   |   1 +
 xen/include/xen/event.h|   8 ++
 xen/include/xen/sched.h|   3 +
 xen/xsm/flask/hooks.c  |   3 +
 xen/xsm/flask/policy/access_vectors|   2 +
 29 files changed, 445 insertions(+), 13 deletions(-)
 create mode 100644 xen/arch/x86/hvm/acpi.c

-- 
2.7.4


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

[Xen-devel] [PATCH v6 08/12] libxl: Update xenstore on VCPU hotplug for all guest types

[Boris Ostrovsky]

Currently HVM guests that use upstream qemu do not update xenstore's
availability entry for VCPUs. While it is not strictly necessary for
hotplug to work, xenstore ends up not reflecting actual status of
VCPUs. We should fix this.

Signed-off-by: Boris Ostrovsky 
---
 tools/libxl/libxl.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 6fd4fe1..3de 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5148,7 +5148,6 @@ int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, 
libxl_bitmap *cpumap)
 switch (libxl__device_model_version_running(gc, domid)) {
 case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
 case LIBXL_DEVICE_MODEL_VERSION_NONE:
-rc = libxl__set_vcpuonline_xenstore(gc, domid, cpumap, );
 break;
 case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
 rc = libxl__set_vcpuonline_qmp(gc, domid, cpumap, );
@@ -5158,11 +5157,14 @@ int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t 
domid, libxl_bitmap *cpumap)
 }
 break;
 case LIBXL_DOMAIN_TYPE_PV:
-rc = libxl__set_vcpuonline_xenstore(gc, domid, cpumap, );
 break;
 default:
 rc = ERROR_INVAL;
 }
+
+if (!rc)
+rc = libxl__set_vcpuonline_xenstore(gc, domid, cpumap, );
+
 out:
 libxl_dominfo_dispose();
 GC_FREE;
-- 
2.7.4


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

[Xen-devel] [PATCH v6 02/12] x86/save: public/arch-x86/hvm/save.h is available to hypervisor and tools only

[Boris Ostrovsky]

Noone else needs to include it since it is only useful to code
that can made domctl calls. And public domctl.h can only be included
by the toolstack or the hypervisor.

Signed-off-by: Boris Ostrovsky 
---
New in v6 (not required by the series).

Q: Should include/public/hvm/save.h have the same guards?

 xen/include/public/arch-x86/hvm/save.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/xen/include/public/arch-x86/hvm/save.h 
b/xen/include/public/arch-x86/hvm/save.h
index 8d73b51..ee0a3f7 100644
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -26,6 +26,8 @@
 #ifndef __XEN_PUBLIC_HVM_SAVE_X86_H__
 #define __XEN_PUBLIC_HVM_SAVE_X86_H__
 
+#if defined(__XEN__) || defined(__XEN_TOOLS__)
+
 /* 
  * Save/restore header: general info about the save file. 
  */
@@ -632,6 +634,8 @@ struct hvm_msr {
  */
 #define HVM_SAVE_CODE_MAX 20
 
+#endif /* __XEN__ || __XEN_TOOLS__ */
+
 #endif /* __XEN_PUBLIC_HVM_SAVE_X86_H__ */
 
 /*
-- 
2.7.4


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

[Xen-devel] [PATCH v6 01/12] domctl: Add XEN_DOMCTL_acpi_access

[Boris Ostrovsky]

This domctl will allow toolstack to read and write some
ACPI registers. It will be available to both x86 and ARM
but will be implemented first only for x86

Signed-off-by: Boris Ostrovsky 
---
CC: Daniel De Graaf 
---
Changes in v6:
* Fold xen_acpi_access into xen_domctl_acpi_access
* Some new error return values


 tools/flask/policy/modules/dom0.te  |  2 +-
 tools/flask/policy/modules/xen.if   |  4 ++--
 xen/arch/x86/domctl.c   |  7 +++
 xen/arch/x86/hvm/Makefile   |  1 +
 xen/arch/x86/hvm/acpi.c | 24 
 xen/include/asm-x86/hvm/domain.h|  3 +++
 xen/include/public/domctl.h | 17 +
 xen/xsm/flask/hooks.c   |  3 +++
 xen/xsm/flask/policy/access_vectors |  2 ++
 9 files changed, 60 insertions(+), 3 deletions(-)
 create mode 100644 xen/arch/x86/hvm/acpi.c

diff --git a/tools/flask/policy/modules/dom0.te 
b/tools/flask/policy/modules/dom0.te
index d0a4d91..475d446 100644
--- a/tools/flask/policy/modules/dom0.te
+++ b/tools/flask/policy/modules/dom0.te
@@ -39,7 +39,7 @@ allow dom0_t dom0_t:domain {
 };
 allow dom0_t dom0_t:domain2 {
set_cpuid gettsc settsc setscheduler set_max_evtchn set_vnumainfo
-   get_vnumainfo psr_cmt_op psr_cat_op
+   get_vnumainfo psr_cmt_op psr_cat_op acpi_access
 };
 allow dom0_t dom0_t:resource { add remove };
 
diff --git a/tools/flask/policy/modules/xen.if 
b/tools/flask/policy/modules/xen.if
index 1aca75d..42a8cc2 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -52,7 +52,7 @@ define(`create_domain_common', `
settime setdomainhandle getvcpucontext set_misc_info };
allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim
set_max_evtchn set_vnumainfo get_vnumainfo cacheflush
-   psr_cmt_op psr_cat_op soft_reset };
+   psr_cmt_op psr_cat_op soft_reset acpi_access };
allow $1 $2:security check_context;
allow $1 $2:shadow enable;
allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage 
mmuext_op updatemp };
@@ -85,7 +85,7 @@ define(`manage_domain', `
getaddrsize pause unpause trigger shutdown destroy
setaffinity setdomainmaxmem getscheduler resume
setpodtarget getpodtarget };
-allow $1 $2:domain2 set_vnumainfo;
+allow $1 $2:domain2 { set_vnumainfo acpi_access };
 ')
 
 # migrate_domain_out(priv, target)
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index ab9ad39..2904e49 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1425,6 +1425,13 @@ long arch_do_domctl(
 }
 break;
 
+case XEN_DOMCTL_acpi_access:
+if ( !is_hvm_domain(d) )
+ret = -ENODEV;
+else
+ret = hvm_acpi_domctl_access(d, >u.acpi_access);
+break;
+
 default:
 ret = iommu_do_domctl(domctl, d, u_domctl);
 break;
diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
index f750d13..bae3244 100644
--- a/xen/arch/x86/hvm/Makefile
+++ b/xen/arch/x86/hvm/Makefile
@@ -1,6 +1,7 @@
 subdir-y += svm
 subdir-y += vmx
 
+obj-y += acpi.o
 obj-y += asid.o
 obj-y += emulate.o
 obj-y += hpet.o
diff --git a/xen/arch/x86/hvm/acpi.c b/xen/arch/x86/hvm/acpi.c
new file mode 100644
index 000..04901c1
--- /dev/null
+++ b/xen/arch/x86/hvm/acpi.c
@@ -0,0 +1,24 @@
+/* acpi.c: ACPI access handling
+ *
+ * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
+ */
+#include 
+#include 
+#include 
+
+
+int hvm_acpi_domctl_access(struct domain *d,
+   const struct xen_domctl_acpi_access *access)
+{
+return -ENOSYS;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-x86/hvm/domain.h b/xen/include/asm-x86/hvm/domain.h
index d55d180..52f934a 100644
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -166,6 +166,9 @@ struct hvm_domain {
 
 #define hap_enabled(d)  ((d)->arch.hvm_domain.hap_enabled)
 
+int hvm_acpi_domctl_access(struct domain *d,
+   const struct xen_domctl_acpi_access *access);
+
 #endif /* __ASM_X86_HVM_DOMAIN_H__ */
 
 /*
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 85cbb7c..5978664 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -1145,6 +1145,21 @@ struct xen_domctl_psr_cat_op {
 typedef struct xen_domctl_psr_cat_op xen_domctl_psr_cat_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_psr_cat_op_t);
 
+struct xen_domctl_acpi_access {
+#define XEN_DOMCTL_ACPI_READ   0
+#define XEN_DOMCTL_ACPI_WRITE  1
+uint8_trw; /* IN: Read or write */
+#define XEN_ACPI_SYSTEM_MEMORY 0
+#define 

[Xen-devel] [PATCH v6 06/12] events/x86: Define SCI virtual interrupt

[Boris Ostrovsky]

PVH guests do not have IOAPIC which typically generates an SCI. For
those guests SCI will be provided as a virtual interrupt.

Copy VIRQ_MCA definition from of xen-mca.h to xen.h to keep all
x86-specific VIRQ_ARCH_* in one place. (However, because we don't
want to require inclusion of xen.h in xen-mca.h we preserve original
definition of VIRQ_MCA as well.)

Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
---
 xen/include/public/arch-x86/xen.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/include/public/arch-x86/xen.h 
b/xen/include/public/arch-x86/xen.h
index 2565acd..b1290a3 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -302,6 +302,9 @@ struct xen_arch_domainconfig {
 #define XEN_ACPI_GPE0_CPUHP_BIT  2
 #endif
 
+#define VIRQ_MCA VIRQ_ARCH_0 /* G. (DOM0) Machine Check Architecture */
+#define VIRQ_SCI VIRQ_ARCH_1 /* G. (PVH) ACPI interrupt */
+
 #endif /* !__ASSEMBLY__ */
 
 /*
-- 
2.7.4


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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 7c6075e2546dd818b7b87090a983429b1942796a
baseline version:
 ovmf 8ad05bd26b4850b5ed89867039fa989d4f256348

Last test of basis68293  2016-12-30 03:49:28 Z4 days
Testing same since68309  2017-01-03 10:17:45 Z0 days1 attempts


People who touched revisions under test:
  Hao Wu 

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 7c6075e2546dd818b7b87090a983429b1942796a
Author: Hao Wu 
Date:   Fri Dec 23 13:04:38 2016 +0800

MdeModulePkg/PrintLib: Add missing return status check for Print APIs

https://bugzilla.tianocore.org/show_bug.cgi?id=307

For the following APIs in PrintLib instance
MdeModulePkg\Library\DxePrintLibPrint2Protocol:
UnicodeVSPrint
UnicodeSPrint
UnicodeVSPrintAsciiFormat
UnicodeSPrintAsciiFormat
AsciiVSPrint
AsciiSPrint
AsciiVSPrintUnicodeFormat
AsciiSPrintUnicodeFormat

The internal function DxePrintLibPrint2ProtocolVaListToBaseList() will be
called to convert a VA_LIST to a BASE_LIST. However, those APIs miss
checking the return value of the internal function.

This commit adds codes to check the return value. If the VA_LIST fails to
be converted to a BASE_LIST, those PrintLib APIs will return 0 and leave
the output 'StartOfBuffer' unmodified.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
Reviewed-by: Jiewen Yao 

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

Re: [Xen-devel] [PATCH] xen: events: Replace BUG() with BUG_ON()

[Juergen Gross]

On 24/12/16 09:52, Shyam Saini wrote:
> Replace BUG() with BUG_ON() using coccinelle
> 
> Signed-off-by: Shyam Saini 

Committed to xen/tip.git for-linus-4.10


Thanks,

Juergen

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

Re: [Xen-devel] [PATCH] x86emul: use unambiguous register names

[Andrew Cooper]

On 03/01/17 13:01, Jan Beulich wrote:
> This is in preparation of eliminating the mis-naming of 64-bit fields
> with 32-bit register names (eflags instead of rflags etc).
>
> Note that the result is not fully consistent until after at least one
> more patch is in place, primarily to limit patch size (by trying to not
> touch the same line twice).
>
> Signed-off-by: Jan Beulich 
>
> --- a/tools/tests/x86_emulator/x86_emulate.c
> +++ b/tools/tests/x86_emulator/x86_emulate.c
> @@ -10,9 +10,11 @@
>  
>  /* For generic assembly code: use macros to define operation/operand sizes. 
> */
>  #ifdef __i386__
> +# define r(name)   e ## name
>  # define __OS  "l"  /* Operation Suffix */
>  # define __OP  "e"  /* Operand Prefix */
>  #else
> +# define r(name)   r ## name
>  # define __OS  "q"  /* Operation Suffix */
>  # define __OP  "r"  /* Operand Prefix */
>  #endif
> --- a/xen/arch/x86/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate.c
> @@ -21,6 +21,8 @@
>  #undef cpuid
>  #undef wbinvd
>  
> +#define r(name) r ## name
> +

Hmm.  I am no overwhelmed with this syntax, but I can't propose an
alternative, so ok.

> @@ -2716,36 +2716,36 @@ x86_emulate(
>  struct segment_register cs, sreg;
>  
>  case 0x00 ... 0x05: add: /* add */
> -emulate_2op_SrcV("add", src, dst, _regs.eflags);
> +emulate_2op_SrcV("add", src, dst, _regs.r(flags));
>  break;
>  

All of these types of operations only adjust the arithmetic flags, so
could legitimately use eflags alone.  Is it worth reducing?

> --- a/xen/arch/x86/x86_emulate/x86_emulate.h
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.h
> @@ -583,41 +583,9 @@ x86_emulate(
>  const struct x86_emulate_ops *ops);
>  
>  #ifndef NDEBUG
> -/*
> - * In debug builds, wrap x86_emulate() with some assertions about its 
> expected
> - * behaviour.
> - */

I'd leave this comment here as well.

Otherwise, Reviewed-by: Andrew Cooper 

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

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

[osstest service owner]

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

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  ed5f19aea66fe5a72060d6a795ffcd23b7643ee3
baseline version:
 xen  6d9d597713ad8ef1d83d6479f5864818a177db20

Last test of basis   104007  2017-01-03 09:00:59 Z0 days
Testing same since   104010  2017-01-03 12:01:14 Z0 days1 attempts


People who touched revisions under test:
  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=ed5f19aea66fe5a72060d6a795ffcd23b7643ee3
+ . ./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 
ed5f19aea66fe5a72060d6a795ffcd23b7643ee3
+ branch=xen-unstable-smoke
+ revision=ed5f19aea66fe5a72060d6a795ffcd23b7643ee3
+ . ./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.8-testing
+ '[' xed5f19aea66fe5a72060d6a795ffcd23b7643ee3 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : 

[Xen-devel] [PATCH] x86/HVM: restrict permitted instructions during special purpose emulation

[Jan Beulich]

Most invocations of the instruction emulator are for VM exits where the
set of legitimate instructions (i.e. ones capable of causing the
respective exit) is rather small. Restrict the permitted sets via a new
callback, at once eliminating the abuse of handle_mmio() for non-MMIO
operations.

Signed-off-by: Jan Beulich 
---
TBD: Better way to cover FPU/SIMD insns in x86_insn_is_mem_write()?

Note that hvm_emulate_is_mem_*() (for now) intentionally don't include
implicit memory operands: I don't think we mean to support namely
the stack to live in MMIO, but otoh we may need to permit that.

--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1039,6 +1039,17 @@ static int hvmemul_cmpxchg(
 return hvmemul_write(seg, offset, p_new, bytes, ctxt);
 }
 
+static int hvmemul_validate(
+const struct x86_emulate_state *state,
+struct x86_emulate_ctxt *ctxt)
+{
+struct hvm_emulate_ctxt *hvmemul_ctxt =
+container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
+
+return hvmemul_ctxt->validate ? hvmemul_ctxt->validate(state, hvmemul_ctxt)
+  : X86EMUL_OKAY;
+}
+
 static int hvmemul_rep_ins(
 uint16_t src_port,
 enum x86_segment dst_seg,
@@ -1663,6 +1674,7 @@ static const struct x86_emulate_ops hvm_
 .insn_fetch= hvmemul_insn_fetch,
 .write = hvmemul_write,
 .cmpxchg   = hvmemul_cmpxchg,
+.validate  = hvmemul_validate,
 .rep_ins   = hvmemul_rep_ins,
 .rep_outs  = hvmemul_rep_outs,
 .rep_movs  = hvmemul_rep_movs,
@@ -1808,7 +1820,8 @@ int hvm_emulate_one_mmio(unsigned long m
 else
 ops = _ro_emulate_ops_mmio;
 
-hvm_emulate_init_once(, guest_cpu_user_regs());
+hvm_emulate_init_once(, hvm_emulate_is_mem_write,
+  guest_cpu_user_regs());
 ctxt.ctxt.data = _ro_ctxt;
 rc = _hvm_emulate_one(, ops);
 switch ( rc )
@@ -1833,7 +1846,7 @@ void hvm_emulate_one_vm_event(enum emul_
 struct hvm_emulate_ctxt ctx = {{ 0 }};
 int rc;
 
-hvm_emulate_init_once(, guest_cpu_user_regs());
+hvm_emulate_init_once(, NULL, guest_cpu_user_regs());
 
 switch ( kind )
 {
@@ -1887,6 +1900,7 @@ void hvm_emulate_one_vm_event(enum emul_
 
 void hvm_emulate_init_once(
 struct hvm_emulate_ctxt *hvmemul_ctxt,
+hvm_emulate_validate_t *validate,
 struct cpu_user_regs *regs)
 {
 struct vcpu *curr = current;
@@ -1897,6 +1911,7 @@ void hvm_emulate_init_once(
 hvmemul_get_seg_reg(x86_seg_cs, hvmemul_ctxt);
 hvmemul_get_seg_reg(x86_seg_ss, hvmemul_ctxt);
 
+hvmemul_ctxt->validate = validate;
 hvmemul_ctxt->ctxt.regs = regs;
 hvmemul_ctxt->ctxt.vendor = curr->domain->arch.x86_vendor;
 hvmemul_ctxt->ctxt.force_writeback = true;
@@ -1991,6 +2006,56 @@ struct segment_register *hvmemul_get_seg
 return _ctxt->seg_reg[idx];
 }
 
+int hvm_emulate_is_mem_access(const struct x86_emulate_state *state,
+  struct hvm_emulate_ctxt *ctxt)
+{
+return x86_insn_is_mem_access(state, >ctxt) ? X86EMUL_OKAY
+  : X86EMUL_UNHANDLEABLE;
+}
+
+int hvm_emulate_is_mem_write(const struct x86_emulate_state *state,
+ struct hvm_emulate_ctxt *ctxt)
+{
+return x86_insn_is_mem_write(state, >ctxt) ? X86EMUL_OKAY
+ : X86EMUL_UNHANDLEABLE;
+}
+
+int hvm_emulate_is_portio(const struct x86_emulate_state *state,
+  struct hvm_emulate_ctxt *ctxt)
+{
+switch ( ctxt->ctxt.opcode )
+{
+case 0x6c ... 0x6f: /* INS / OUTS */
+case 0xe4 ... 0xe7: /* IN / OUT imm8 */
+case 0xec ... 0xef: /* IN / OUT %dx */
+return X86EMUL_OKAY;
+}
+
+return X86EMUL_UNHANDLEABLE;
+}
+
+int hvm_emulate_is_cr_access(const struct x86_emulate_state *state,
+ struct hvm_emulate_ctxt *ctxt)
+{
+switch ( ctxt->ctxt.opcode )
+{
+unsigned int ext;
+
+case X86EMUL_OPC(0x0f, 0x01):
+x86_insn_modrm(state, NULL, );
+if ( (ext & 5) == 4 ) /* SMSW / LMSW */
+return X86EMUL_OKAY;
+break;
+
+case X86EMUL_OPC(0x0f, 0x06): /* CLTS */
+case X86EMUL_OPC(0x0f, 0x20): /* MOV from CRn */
+case X86EMUL_OPC(0x0f, 0x22): /* MOV to CRn */
+return X86EMUL_OKAY;
+}
+
+return X86EMUL_UNHANDLEABLE;
+}
+
 static const char *guest_x86_mode_to_str(int mode)
 {
 switch ( mode )
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4004,7 +4004,7 @@ void hvm_ud_intercept(struct cpu_user_re
 cur->domain->arch.x86_vendor != boot_cpu_data.x86_vendor;
 struct hvm_emulate_ctxt ctxt;
 
-hvm_emulate_init_once(, regs);
+hvm_emulate_init_once(, NULL, regs);
 
 if ( opt_hvm_fep )
 {
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -78,7 +78,7 @@ void send_invalidate_req(void)
 gprintk(XENLOG_ERR, 

Re: [Xen-devel] [PATCH] x86/VMX: use unambiguous register names

[Andrew Cooper]

On 03/01/17 13:01, Jan Beulich wrote:
> @@ -1321,10 +1321,10 @@ static void virtual_vmexit(struct cpu_us
>  if ( lm_l1 != lm_l2 )
>  paging_update_paging_modes(v);
>  
> -regs->eip = get_vvmcs(v, HOST_RIP);
> -regs->esp = get_vvmcs(v, HOST_RSP);
> +regs->rip = get_vvmcs(v, HOST_RIP);
> +regs->rsp = get_vvmcs(v, HOST_RSP);
>  /* VM exit clears all bits except bit 1 */
> -regs->eflags = 0x2;
> +regs->rflags = 0x2;

With this updated to X86_EFLAGS_MBS,

Reviewed-by: Andrew Cooper 

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

[Xen-devel] [PATCH v3] x86emul: support LAR/LSL/VERR/VERW

[Jan Beulich]

This involves protmode_load_seg() accepting x86_seg_none as input, with
the meaning to
- suppress any exceptions other than #PF,
- not commit any state.

Signed-off-by: Jan Beulich 
---
v3: Re-base.
v2: Extend commit message and add a respective code comment. Add
ASSERT()s to ensure/document that only #PF can make it out of
protmode_load_seg().

--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -44,7 +44,47 @@ static int read(
 if ( verbose )
 printf("** %s(%u, %p,, %u,)\n", __func__, seg, (void *)offset, bytes);
 
-bytes_read += bytes;
+switch ( seg )
+{
+uint64_t value;
+
+case x86_seg_gdtr:
+/* Fake system segment type matching table index. */
+if ( (offset & 7) || (bytes > 8) )
+return X86EMUL_UNHANDLEABLE;
+#ifdef __x86_64__
+if ( !(offset & 8) )
+{
+memset(p_data, 0, bytes);
+return X86EMUL_OKAY;
+}
+value = (offset - 8) >> 4;
+#else
+value = (offset - 8) >> 3;
+#endif
+if ( value >= 0x10 )
+return X86EMUL_UNHANDLEABLE;
+value |= value << 40;
+memcpy(p_data, , bytes);
+return X86EMUL_OKAY;
+
+case x86_seg_ldtr:
+/* Fake user segment type matching table index. */
+if ( (offset & 7) || (bytes > 8) )
+return X86EMUL_UNHANDLEABLE;
+value = offset >> 3;
+if ( value >= 0x10 )
+return X86EMUL_UNHANDLEABLE;
+value |= (value | 0x10) << 40;
+memcpy(p_data, , bytes);
+return X86EMUL_OKAY;
+
+default:
+if ( !is_x86_user_segment(seg) )
+return X86EMUL_UNHANDLEABLE;
+bytes_read += bytes;
+break;
+}
 memcpy(p_data, (void *)offset, bytes);
 return X86EMUL_OKAY;
 }
@@ -73,6 +113,8 @@ static int write(
 if ( verbose )
 printf("** %s(%u, %p,, %u,)\n", __func__, seg, (void *)offset, bytes);
 
+if ( !is_x86_user_segment(seg) )
+return X86EMUL_UNHANDLEABLE;
 memcpy((void *)offset, p_data, bytes);
 return X86EMUL_OKAY;
 }
@@ -88,17 +130,48 @@ static int cmpxchg(
 if ( verbose )
 printf("** %s(%u, %p,, %u,)\n", __func__, seg, (void *)offset, bytes);
 
+if ( !is_x86_user_segment(seg) )
+return X86EMUL_UNHANDLEABLE;
 memcpy((void *)offset, new, bytes);
 return X86EMUL_OKAY;
 }
 
+static int read_segment(
+enum x86_segment seg,
+struct segment_register *reg,
+struct x86_emulate_ctxt *ctxt)
+{
+if ( !is_x86_user_segment(seg) )
+return X86EMUL_UNHANDLEABLE;
+memset(reg, 0, sizeof(*reg));
+reg->attr.fields.p = 1;
+return X86EMUL_OKAY;
+}
+
+static int read_msr(
+unsigned int reg,
+uint64_t *val,
+struct x86_emulate_ctxt *ctxt)
+{
+switch ( reg )
+{
+case 0xc080: /* EFER */
+*val = ctxt->addr_size > 32 ? 0x500 /* LME|LMA */ : 0;
+return X86EMUL_OKAY;
+}
+
+return X86EMUL_UNHANDLEABLE;
+}
+
 static struct x86_emulate_ops emulops = {
 .read   = read,
 .insn_fetch = fetch,
 .write  = write,
 .cmpxchg= cmpxchg,
+.read_segment = read_segment,
 .cpuid  = emul_test_cpuid,
 .read_cr= emul_test_read_cr,
+.read_msr   = read_msr,
 .get_fpu= emul_test_get_fpu,
 };
 
@@ -611,6 +684,156 @@ int main(int argc, char **argv)
 goto fail;
 printf("okay\n");
 
+printf("%-40s", "Testing lar (null selector)...");
+instr[0] = 0x0f; instr[1] = 0x02; instr[2] = 0xc1;
+regs.eflags = 0x240;
+regs.eip= (unsigned long)[0];
+regs.ecx= 0;
+regs.eax= 0x;
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) ||
+ (regs.eax != 0x) ||
+ (regs.eflags != 0x200) ||
+ (regs.eip != (unsigned long)[3]) )
+goto fail;
+printf("okay\n");
+
+printf("%-40s", "Testing lsl (null selector)...");
+instr[0] = 0x0f; instr[1] = 0x03; instr[2] = 0xca;
+regs.eflags = 0x240;
+regs.eip= (unsigned long)[0];
+regs.edx= 0;
+regs.ecx= 0x;
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) ||
+ (regs.ecx != 0x) ||
+ (regs.eflags != 0x200) ||
+ (regs.eip != (unsigned long)[3]) )
+goto fail;
+printf("okay\n");
+
+printf("%-40s", "Testing verr (null selector)...");
+instr[0] = 0x0f; instr[1] = 0x00; instr[2] = 0x21;
+regs.eflags = 0x240;
+regs.eip= (unsigned long)[0];
+regs.ecx= (unsigned long)res;
+*res= 0;
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) ||
+ (regs.eflags != 0x200) ||
+ (regs.eip != (unsigned long)[3]) )
+goto fail;
+printf("okay\n");
+
+printf("%-40s", "Testing verw (null selector)...");
+instr[0] = 0x0f; instr[1] = 0x00; instr[2] = 0x2a;
+regs.eflags = 0x240;
+regs.eip= (unsigned long)[0];
+   

[Xen-devel] [PATCH] x86/VMX: use unambiguous register names

[Jan Beulich]

This is in preparation of eliminating the mis-naming of 64-bit fields
with 32-bit register names (eflags instead of rflags etc). Use the
guaranteed 32-bit underscore prefixed names for now where appropriate.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -1778,10 +1778,10 @@ void vmcs_dump_vcpu(struct vcpu *v)
vmr(GUEST_PDPTE(2)), vmr(GUEST_PDPTE(3)));
 }
 printk("RSP = 0x%016lx (0x%016lx)  RIP = 0x%016lx (0x%016lx)\n",
-   vmr(GUEST_RSP), regs->esp,
-   vmr(GUEST_RIP), regs->eip);
+   vmr(GUEST_RSP), regs->rsp,
+   vmr(GUEST_RIP), regs->rip);
 printk("RFLAGS=0x%08lx (0x%08lx)  DR7 = 0x%016lx\n",
-   vmr(GUEST_RFLAGS), regs->eflags,
+   vmr(GUEST_RFLAGS), regs->rflags,
vmr(GUEST_DR7));
 printk("Sysenter RSP=%016lx CS:RIP=%04x:%016lx\n",
vmr(GUEST_SYSENTER_ESP),
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -295,7 +295,7 @@ static int vmx_vcpu_initialise(struct vc
 
 /* %eax == 1 signals full real-mode support to the guest loader. */
 if ( v->vcpu_id == 0 )
-v->arch.user_regs.eax = 1;
+v->arch.user_regs.rax = 1;
 
 return 0;
 }
@@ -560,7 +560,7 @@ int vmx_guest_x86_mode(struct vcpu *v)
 
 if ( unlikely(!(v->arch.hvm_vcpu.guest_cr[0] & X86_CR0_PE)) )
 return 0;
-if ( unlikely(guest_cpu_user_regs()->eflags & X86_EFLAGS_VM) )
+if ( unlikely(guest_cpu_user_regs()->_eflags & X86_EFLAGS_VM) )
 return 1;
 __vmread(GUEST_CS_AR_BYTES, _ar_bytes);
 if ( hvm_long_mode_enabled(v) &&
@@ -1670,7 +1670,7 @@ static void vmx_inject_event(const struc
 switch ( _event.vector | -(_event.type == X86_EVENTTYPE_SW_INTERRUPT) )
 {
 case TRAP_debug:
-if ( guest_cpu_user_regs()->eflags & X86_EFLAGS_TF )
+if ( guest_cpu_user_regs()->_eflags & X86_EFLAGS_TF )
 {
 __restore_debug_registers(curr);
 write_debugreg(6, read_debugreg(6) | DR_STEP);
@@ -1770,7 +1770,7 @@ static void vmx_set_info_guest(struct vc
  */
 __vmread(GUEST_INTERRUPTIBILITY_INFO, _shadow);
 if ( v->domain->debugger_attached &&
- (v->arch.user_regs.eflags & X86_EFLAGS_TF) &&
+ (v->arch.user_regs._eflags & X86_EFLAGS_TF) &&
  (intr_shadow & VMX_INTR_SHADOW_STI) )
 {
 intr_shadow &= ~VMX_INTR_SHADOW_STI;
@@ -2331,8 +2331,8 @@ void update_guest_eip(void)
 struct cpu_user_regs *regs = guest_cpu_user_regs();
 unsigned long x;
 
-regs->eip += get_instruction_length(); /* Safe: callers audited */
-regs->eflags &= ~X86_EFLAGS_RF;
+regs->rip += get_instruction_length(); /* Safe: callers audited */
+regs->_eflags &= ~X86_EFLAGS_RF;
 
 __vmread(GUEST_INTERRUPTIBILITY_INFO, );
 if ( x & (VMX_INTR_SHADOW_STI | VMX_INTR_SHADOW_MOV_SS) )
@@ -2341,7 +2341,7 @@ void update_guest_eip(void)
 __vmwrite(GUEST_INTERRUPTIBILITY_INFO, x);
 }
 
-if ( regs->eflags & X86_EFLAGS_TF )
+if ( regs->_eflags & X86_EFLAGS_TF )
 hvm_inject_hw_exception(TRAP_debug, X86_EVENT_NO_EC);
 }
 
@@ -2370,21 +2370,21 @@ static int vmx_do_cpuid(struct cpu_user_
 return 1;  /* Don't advance the guest IP! */
 }
 
-eax = regs->eax;
-ebx = regs->ebx;
-ecx = regs->ecx;
-edx = regs->edx;
+eax = regs->_eax;
+ebx = regs->_ebx;
+ecx = regs->_ecx;
+edx = regs->_edx;
 
-leaf = regs->eax;
-subleaf = regs->ecx;
+leaf = regs->_eax;
+subleaf = regs->_ecx;
 
 hvm_cpuid(leaf, , , , );
 HVMTRACE_5D(CPUID, leaf, eax, ebx, ecx, edx);
 
-regs->eax = eax;
-regs->ebx = ebx;
-regs->ecx = ecx;
-regs->edx = edx;
+regs->rax = eax;
+regs->rbx = ebx;
+regs->rcx = ecx;
+regs->rdx = edx;
 
 return hvm_monitor_cpuid(get_instruction_length(), leaf, subleaf);
 }
@@ -3097,8 +3097,8 @@ void vmx_enter_realmode(struct cpu_user_
 /* Adjust RFLAGS to enter virtual 8086 mode with IOPL == 3.  Since
  * we have CR4.VME == 1 and our own TSS with an empty interrupt
  * redirection bitmap, all software INTs will be handled by vm86 */
-v->arch.hvm_vmx.vm86_saved_eflags = regs->eflags;
-regs->eflags |= (X86_EFLAGS_VM | X86_EFLAGS_IOPL);
+v->arch.hvm_vmx.vm86_saved_eflags = regs->_eflags;
+regs->_eflags |= (X86_EFLAGS_VM | X86_EFLAGS_IOPL);
 }
 
 static int vmx_handle_eoi_write(void)
@@ -3240,12 +3240,10 @@ void vmx_vmexit_handler(struct cpu_user_
 
 if ( hvm_long_mode_enabled(v) )
 HVMTRACE_ND(VMEXIT64, 0, 1/*cycles*/, 3, exit_reason,
-(uint32_t)regs->eip, (uint32_t)((uint64_t)regs->eip >> 32),
-0, 0, 0);
+regs->_eip, regs->rip >> 32, 0, 0, 0);
 else
 HVMTRACE_ND(VMEXIT, 0, 1/*cycles*/, 2, exit_reason,
-(uint32_t)regs->eip, 
-0, 0, 0, 0);
+regs->_eip, 0, 0, 0, 0);
 

[Xen-devel] [PATCH] x86emul: use unambiguous register names

[Jan Beulich]

This is in preparation of eliminating the mis-naming of 64-bit fields
with 32-bit register names (eflags instead of rflags etc).

Note that the result is not fully consistent until after at least one
more patch is in place, primarily to limit patch size (by trying to not
touch the same line twice).

Signed-off-by: Jan Beulich 

--- a/tools/tests/x86_emulator/x86_emulate.c
+++ b/tools/tests/x86_emulator/x86_emulate.c
@@ -10,9 +10,11 @@
 
 /* For generic assembly code: use macros to define operation/operand sizes. */
 #ifdef __i386__
+# define r(name)   e ## name
 # define __OS  "l"  /* Operation Suffix */
 # define __OP  "e"  /* Operand Prefix */
 #else
+# define r(name)   r ## name
 # define __OS  "q"  /* Operation Suffix */
 # define __OP  "r"  /* Operand Prefix */
 #endif
--- a/xen/arch/x86/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate.c
@@ -21,6 +21,8 @@
 #undef cpuid
 #undef wbinvd
 
+#define r(name) r ## name
+
 #define cpu_has_amd_erratum(nr) \
 cpu_has_amd_erratum(_cpu_data, AMD_ERRATUM_##nr)
 
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -662,12 +662,12 @@ do{ asm volatile (
 
 /* Fetch next part of the instruction being emulated. */
 #define insn_fetch_bytes(_size) \
-({ 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, \
+({ unsigned long _x = 0, _ip = state->ip;   \
+   state->ip += (_size); /* real hardware doesn't truncate */   \
+   generate_exception_if((uint8_t)(state->ip -  \
+   ctxt->regs->r(ip)) > MAX_INST_LEN,   \
  EXC_GP, 0);\
-   rc = ops->insn_fetch(x86_seg_cs, _eip, &_x, (_size), ctxt);  \
+   rc = ops->insn_fetch(x86_seg_cs, _ip, &_x, (_size), ctxt);   \
if ( rc ) goto done; \
_x;  \
 })
@@ -735,25 +735,25 @@ do {
 ad_bytes)
 
 #define sp_pre_dec(dec) ({  \
-_register_address_increment(_regs.esp, -(dec), ctxt->sp_size/8);\
-truncate_word(_regs.esp, ctxt->sp_size/8);  \
+_register_address_increment(_regs.r(sp), -(dec), ctxt->sp_size/8);  \
+truncate_word(_regs.r(sp), ctxt->sp_size/8);\
 })
 #define sp_post_inc(inc) ({ \
-unsigned long __esp = truncate_word(_regs.esp, ctxt->sp_size/8);\
-_register_address_increment(_regs.esp, (inc), ctxt->sp_size/8); \
-__esp;  \
+unsigned long sp = truncate_word(_regs.r(sp), ctxt->sp_size/8); \
+_register_address_increment(_regs.r(sp), (inc), ctxt->sp_size/8);   \
+sp; \
 })
 
 #define jmp_rel(rel)\
 do {\
-unsigned long ip = _regs.eip + (int)(rel);  \
+unsigned long ip = _regs.r(ip) + (int)(rel);\
 if ( op_bytes == 2 )\
 ip = (uint16_t)ip;  \
 else if ( !mode_64bit() )   \
 ip = (uint32_t)ip;  \
 rc = ops->insn_fetch(x86_seg_cs, ip, NULL, 0, ctxt);\
 if ( rc ) goto done;\
-_regs.eip = ip; \
+_regs.r(ip) = ip;   \
 } while (0)
 
 #define validate_far_branch(cs, ip) ({  \
@@ -767,9 +767,9 @@ do {
   : (ip) > (cs)->limit, EXC_GP, 0); \
 })
 
-#define commit_far_branch(cs, ip) ({\
-validate_far_branch(cs, ip);\
-_regs.eip = (ip);   \
+#define commit_far_branch(cs, newip) ({ \
+validate_far_branch(cs, newip); \
+_regs.r(ip) = (newip);  \
 ops->write_segment(x86_seg_cs, cs, ctxt);   \
 })
 
@@ -783,7 +783,7 @@ static void fpu_handle_exception(void *_
 

Re: [Xen-devel] [PATCH 2/2] x86/cpu: Improvements to get_cpu_vendor()

[Jan Beulich]

>>> On 03.01.17 at 13:41,  wrote:
> On 03/01/17 12:40, Jan Beulich wrote:
>> For the patch itself
>> Reviewed-by: Jan Beulich 
> 
> Does this still stand if I split the patch into two, for easier backport?

Yes.

Jan


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

Re: [Xen-devel] [PATCH 2/2] x86/cpu: Improvements to get_cpu_vendor()

[Andrew Cooper]

On 03/01/17 12:40, Jan Beulich wrote:
 On 03.01.17 at 13:06,  wrote:
>> Comparing 3 integers is more efficient than using strcmp(), and is more 
>> useful
>> to the gcv_guest case than having to fabricate a suitable string to pass.  
>> The
>> gcv_host cases have both options easily to hand, and experimentally, the
>> resulting code is more efficient.
>>
>> While modifying get_cpu_vendor(), fix a bug where this_cpu got updated even 
>> in
>> the gcv_guest case.
> Isn't this something we'd better fix separately, to ease backporting?

I can do.

>
>> Update the cpu_dev structure to be more efficient.  c_vendor[] only needs to
>> be 8 bytes long to cover all the CPU drivers Xen has, which avoids storing an
>> 8-byte pointer to 8 bytes of data.  Drop c_ident[1] as we have no CPU drivers
>> with a second ident string, and turn it into a transparent union to allow
>> access to the integer values directly.
> I think "transparent" is misleading here, as you don't add the respective
> gcc attribute. I think you mean "unnamed".

Yes sorry.  My mistake.

>
>> This avoids all need for the vendor_id union in update_domain_cpuid_info().
>>
>> Signed-off-by: Andrew Cooper 
> For the patch itself
> Reviewed-by: Jan Beulich 

Does this still stand if I split the patch into two, for easier backport?

~Andrew

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

Re: [Xen-devel] [PATCH 2/2] x86/cpu: Improvements to get_cpu_vendor()

[Jan Beulich]

>>> On 03.01.17 at 13:06,  wrote:
> Comparing 3 integers is more efficient than using strcmp(), and is more useful
> to the gcv_guest case than having to fabricate a suitable string to pass.  The
> gcv_host cases have both options easily to hand, and experimentally, the
> resulting code is more efficient.
> 
> While modifying get_cpu_vendor(), fix a bug where this_cpu got updated even in
> the gcv_guest case.

Isn't this something we'd better fix separately, to ease backporting?

> Update the cpu_dev structure to be more efficient.  c_vendor[] only needs to
> be 8 bytes long to cover all the CPU drivers Xen has, which avoids storing an
> 8-byte pointer to 8 bytes of data.  Drop c_ident[1] as we have no CPU drivers
> with a second ident string, and turn it into a transparent union to allow
> access to the integer values directly.

I think "transparent" is misleading here, as you don't add the respective
gcc attribute. I think you mean "unnamed".

> This avoids all need for the vendor_id union in update_domain_cpuid_info().
> 
> Signed-off-by: Andrew Cooper 

For the patch itself
Reviewed-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH 1/2] x86/cpu: Drop unused X86_VENDOR_* values

[Jan Beulich]

>>> On 03.01.17 at 13:06,  wrote:
> Xen only has CPU drivers for Intel, Centaur and AMD.  All other contributions
> to X86_VENDOR_NUM simply make the cpu_devs[] array longer, reducing the
> efficiency of get_cpu_vendor()
> 
> There is one remaning hidden reference to X86_VENDOR_CYRIX in the MTRR code.
> However, as far as I can tell, Cyrix never realeased a 64bit processor.  It is
> therefore dead code.
> 
> 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] x86/vvmx: Drop sreg_to_index[]

[Jan Beulich]

>>> On 03.01.17 at 12:58,  wrote:
> Since c/s 0888d36b "x86/emul: Correct the decoding of SReg3 operands",
> x86_seg_* have followed hardware encodings, meaning that this translation
> table is now an identiy transform.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 


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