[Xen-devel] ARM: SMMUv3 support

[Vijay Kilari]

Hi,

 Is there any effort put by anyone to get SMMUv3 support in Xen for ARM64?.
Would be glad to know.

Regards
Vijay

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

Re: [Xen-devel] [RFC PATCH 00/23] xen/vIOMMU: Add vIOMMU support with irq remapping fucntion on Intel platform

[Lan Tianyu]

On 2017年03月21日 10:28, Lan Tianyu wrote:
> On 2017年03月20日 22:23, Roger Pau Monné wrote:
>> Thanks! So you add all this vIOMMU code, but the maximum number of allowed
>> vCPUs for HVM guests is still limited to 128 (HVM_MAX_VCPUS is not touched). 
>> Is
>> there any missing pieces in order to bump this?
> 
> To increase vcpu number, we need to change APIC ID rule and now it's
> APICID = VCPUID * 2. Andrew's CPUID improvement will change it and so
> our following patches of increasing vcpu number will base on Andrew's job.
> 
> 
>>
>> Also, have you tested if this series works with PVH guests? Boris added PVH
>> support to Linux not long ago, so you should be able to test it just by 
>> picking
>> the latest Linux kernel.
> 
> Our patchset just targets hvm guest and it will not work for PV guest. 

New hypercalls introduced by this patchset also can reuse for PVH to
enable vIOMMU. This patchset relies on Qemu Xen-vIOMMU device model to
create/destroy vIOMMU. If we want to enable DMA translation for hvm
guest later, virtual device's DMA request would be passed from Qemu to
Xen hypervisor and the device model in Qemu is necessary.

-- 
Best regards
Tianyu Lan

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

Re: [Xen-devel] [PATCH 2/2] configure: use pkg-config for obtaining xen version

[Juergen Gross]

On 17/03/17 19:33, Stefano Stabellini wrote:
> On Fri, 17 Mar 2017, Juergen Gross wrote:
>> On 16/03/17 21:20, Stefano Stabellini wrote:
>>> On Thu, 16 Mar 2017, Juergen Gross wrote:
 Instead of trying to guess the Xen version to use by compiling various
 test programs first just ask the system via pkg-config. Only if it
 can't return the version fall back to the test program scheme.
>>>
>>> That's OK, but why did you remove the Xen unstable test?
>>
>> >From Xen 4.9 on pkg-config will return the needed information. There is
>> no longer a need for a test program to determine the Xen version. After
>> all this was the main objective of my series adding the pkg-config
>> files to Xen.
> 
> I was going to say something like "yeah, but is pkg-config always
> available?" In reality, QEMU already has pkg-config as build
> dependency, so I guess there is no problem with that.
> 
> Please add a note about this to the commit message.
> 

Okay.


Juergen

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

Re: [Xen-devel] Supporting systems with large E820 maps

[Juergen Gross]

On 20/03/17 20:03, Alex Thorlton wrote:
> Hey everyone,
> 
> Recently, I've been working with Boris Ostrovsky to get Xen running on
> some of our larger systems, and we've run into a few problems with the
> amount of space that Xen sets aside for the E820 map.
> 
> The first problem that I hit was that E820MAX is far too small, at 128
> entries, for the system that we're testing with.  The EFI memory map
> handed up from the boot loader tops out at 783 entries, which far
> exceeds the amount of space allocated for the memory map in
> arch/x86/boot/mem.S.  I was able to get past this problem by bumping
> E820MAX up to 1024 in arch/x86/boot/mem.S and include/asm-x86/e820.h.
> 
> The second problem that I encountered was that Xen uses a signed char to
> store the number of entries in the memory map in a few places, which is
> too small to hold the number of entries after bumping E820MAX up to
> 1024.  I made the following changes to get past this:

The problem with setting E820MAX to a higher value in mem.S without
further measures is that you are growing the trampoline size. This is
problematic for memory allocation in the multiboot path.

I have some patches sitting here waiting for Daniel's multiboot series
to go in. My patches are not using the mem.S e820 array for the EFI
memory map, so the BIOS memory map buffer can remain smaller while the
EFI buffer can be made rather large. This avoids growing the trampoline
(in fact I've managed to reduce it to a single page).

I didn't post my series up to now in order to not block Daniel's series
again. So what do people think: should I wait some more time with my
patches, or should I send them rather soon?


Juergen

> 
> 8<---
> ---
>  arch/x86/e820.c |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> --- xen.orig/arch/x86/e820.c
> +++ xen/arch/x86/e820.c
> @@ -134,7 +134,7 @@ static struct change_member *change_poin
>  static struct e820entry *overlap_list[E820MAX] __initdata;
>  static struct e820entry new_bios[E820MAX] __initdata;
> 
> -static int __init sanitize_e820_map(struct e820entry * biosmap, char * 
> pnr_map)
> +static int __init sanitize_e820_map(struct e820entry * biosmap, unsigned int 
> * pnr_map)
>  {
>  struct change_member *change_tmp;
>  unsigned long current_type, last_type;
> @@ -509,13 +509,13 @@ static void __init reserve_dmi_region(vo
>  }
>  }
> 
> -static void __init machine_specific_memory_setup(struct e820entry *raw, char 
> *raw_nr)
> +static void __init machine_specific_memory_setup(struct e820entry *raw, 
> unsigned int *raw_nr)
>  {
>  unsigned long mpt_limit, ro_mpt_limit;
>  uint64_t top_of_ram, size;
>  int i;
> 
> -char nr = (char)*raw_nr;
> +unsigned int nr = (unsigned int)*raw_nr;
>  sanitize_e820_map(raw, );
>  *raw_nr = nr;
>  (void)copy_e820_map(raw, nr);
> --->8
> 
> I didn't need to go all the way up to unsigned int here, but I did this
> as a quick/dirty test to see if it got things working.
> 
> These small changes get our large machine to boot up and recognize all
> 32TB of available RAM.  I know that these changes are probably not what
> we'll want to go with in the end, but I wanted to get them sent upstream
> to get a dialogue started.
> 
> So, what do others think here?  How do we want to handle a large E820
> map?  Boris mentioned to me that we might want to attempt to do a
> dynamic allocation scheme, where we reserve more space for the memory
> map when we detect that E820 is large.
> 
> Any comments/suggestions are greatly appreciated!
> 
> - Alex
> 
> ___
> 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

[Xen-devel] Supporting systems with large E820 maps

[Alex Thorlton]

Hey everyone,

Recently, I've been working with Boris Ostrovsky to get Xen running on
some of our larger systems, and we've run into a few problems with the
amount of space that Xen sets aside for the E820 map.

The first problem that I hit was that E820MAX is far too small, at 128
entries, for the system that we're testing with.  The EFI memory map
handed up from the boot loader tops out at 783 entries, which far
exceeds the amount of space allocated for the memory map in
arch/x86/boot/mem.S.  I was able to get past this problem by bumping
E820MAX up to 1024 in arch/x86/boot/mem.S and include/asm-x86/e820.h.

The second problem that I encountered was that Xen uses a signed char to
store the number of entries in the memory map in a few places, which is
too small to hold the number of entries after bumping E820MAX up to
1024.  I made the following changes to get past this:

8<---
---
 arch/x86/e820.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- xen.orig/arch/x86/e820.c
+++ xen/arch/x86/e820.c
@@ -134,7 +134,7 @@ static struct change_member *change_poin
 static struct e820entry *overlap_list[E820MAX] __initdata;
 static struct e820entry new_bios[E820MAX] __initdata;

-static int __init sanitize_e820_map(struct e820entry * biosmap, char * pnr_map)
+static int __init sanitize_e820_map(struct e820entry * biosmap, unsigned int * 
pnr_map)
 {
 struct change_member *change_tmp;
 unsigned long current_type, last_type;
@@ -509,13 +509,13 @@ static void __init reserve_dmi_region(vo
 }
 }

-static void __init machine_specific_memory_setup(struct e820entry *raw, char 
*raw_nr)
+static void __init machine_specific_memory_setup(struct e820entry *raw, 
unsigned int *raw_nr)
 {
 unsigned long mpt_limit, ro_mpt_limit;
 uint64_t top_of_ram, size;
 int i;

-char nr = (char)*raw_nr;
+unsigned int nr = (unsigned int)*raw_nr;
 sanitize_e820_map(raw, );
 *raw_nr = nr;
 (void)copy_e820_map(raw, nr);
--->8

I didn't need to go all the way up to unsigned int here, but I did this
as a quick/dirty test to see if it got things working.

These small changes get our large machine to boot up and recognize all
32TB of available RAM.  I know that these changes are probably not what
we'll want to go with in the end, but I wanted to get them sent upstream
to get a dialogue started.

So, what do others think here?  How do we want to handle a large E820
map?  Boris mentioned to me that we might want to attempt to do a
dynamic allocation scheme, where we reserve more space for the memory
map when we detect that E820 is large.

Any comments/suggestions are greatly appreciated!

- Alex

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf f2333c707dd04f069c102bcae004561ec590a3a0
baseline version:
 ovmf 38b15ebe4fd5888493131d30fc31833a5e9a7d36

Last test of basis   106790  2017-03-20 16:15:14 Z0 days
Testing same since   106798  2017-03-21 02:17:09 Z0 days1 attempts


People who touched revisions under test:
  Suman Prakash 
  Suman Prakash 

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=f2333c707dd04f069c102bcae004561ec590a3a0
+ . ./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 
f2333c707dd04f069c102bcae004561ec590a3a0
+ branch=ovmf
+ revision=f2333c707dd04f069c102bcae004561ec590a3a0
+ . ./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
+ '[' xf2333c707dd04f069c102bcae004561ec590a3a0 = 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] [qemu-mainline test] 106793: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 build-arm64-pvops 5 kernel-build 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-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu940a8ce075e3408742a4edcabfd6c2a15e2539eb
baseline version:
 qemuuebedf0f9cd46b617df331eecc857c379d574ac62

Last test of basis   106774  2017-03-19 12:16:31 Z1 days
Failing since106787  2017-03-20 11:17:23 Z0 days2 attempts
Testing same since   106793  2017-03-20 21:44:25 Z0 days1 attempts


People who touched revisions under test:
  Alex Bennée 
  Cornelia Huck 
  Dong Jia Shi 
  Gerd Hoffmann 
  Greg Kurz 
  Hervé Poussineau 
  Marc-André Lureau 
  Paolo Bonzini 
  Peter Maydell 
  Philippe Mathieu-Daudé 
  Prasad J Pandit 
  Stefano Stabellini 
  Stefano Stabellini 
  Vincent Palatin 
  Yongbok Kim 

jobs:
 build-amd64-xsm

[Xen-devel] [PATCH v9 5/5] x86/ioreq server: Synchronously reset outstanding p2m_ioreq_server entries when an ioreq server unmaps.

[Yu Zhang]

After an ioreq server has unmapped, the remaining p2m_ioreq_server
entries need to be reset back to p2m_ram_rw. This patch does this
synchronously by iterating the p2m table.

The synchronous resetting is necessary because we need to guarantee
the p2m table is clean before another ioreq server is mapped. And
since the sweeping of p2m table could be time consuming, it is done
with hypercall continuation.

Signed-off-by: Yu Zhang 
---
Cc: Paul Durrant 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: George Dunlap 

changes in v2: 
  - According to comments from Jan and Andrew: do not use the
HVMOP type hypercall continuation method. Instead, adding
an opaque in xen_dm_op_map_mem_type_to_ioreq_server to
store the gfn.
  - According to comments from Jan: change routine's comments
and name of parameters of p2m_finish_type_change().

changes in v1: 
  - This patch is splitted from patch 4 of last version.
  - According to comments from Jan: update the gfn_start for 
when use hypercall continuation to reset the p2m type.
  - According to comments from Jan: use min() to compare gfn_end
and max mapped pfn in p2m_finish_type_change()
---
 xen/arch/x86/hvm/dm.c | 41 ++---
 xen/arch/x86/mm/p2m.c | 29 +
 xen/include/asm-x86/p2m.h |  7 +++
 3 files changed, 74 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index 3f9484d..a24d0f8 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -385,16 +385,51 @@ static int dm_op(domid_t domid,
 
 case XEN_DMOP_map_mem_type_to_ioreq_server:
 {
-const struct xen_dm_op_map_mem_type_to_ioreq_server *data =
+struct xen_dm_op_map_mem_type_to_ioreq_server *data =
 _mem_type_to_ioreq_server;
+unsigned long first_gfn = data->opaque;
+unsigned long last_gfn;
+
+const_op = false;
 
 rc = -EOPNOTSUPP;
 /* Only support for HAP enabled hvm. */
 if ( !hap_enabled(d) )
 break;
 
-rc = hvm_map_mem_type_to_ioreq_server(d, data->id,
-  data->type, data->flags);
+if ( first_gfn == 0 )
+rc = hvm_map_mem_type_to_ioreq_server(d, data->id,
+  data->type, data->flags);
+/*
+ * Iterate p2m table when an ioreq server unmaps from p2m_ioreq_server,
+ * and reset the remaining p2m_ioreq_server entries back to p2m_ram_rw.
+ */
+if ( (first_gfn > 0) || (data->flags == 0 && rc == 0) )
+{
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+while ( read_atomic(>ioreq.entry_count) &&
+first_gfn <= p2m->max_mapped_pfn )
+{
+/* Iterate p2m table for 256 gfns each time. */
+last_gfn = first_gfn + 0xff;
+
+p2m_finish_type_change(d, first_gfn, last_gfn,
+   p2m_ioreq_server, p2m_ram_rw);
+
+first_gfn = last_gfn + 1;
+
+/* Check for continuation if it's not the last iteration. */
+if ( first_gfn <= p2m->max_mapped_pfn &&
+ hypercall_preempt_check() )
+{
+rc = -ERESTART;
+data->opaque = first_gfn;
+break;
+}
+}
+}
+
 break;
 }
 
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index e3e54f1..0a2f276 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1038,6 +1038,35 @@ void p2m_change_type_range(struct domain *d,
 p2m_unlock(p2m);
 }
 
+/* Synchronously modify the p2m type for a range of gfns from ot to nt. */
+void p2m_finish_type_change(struct domain *d,
+unsigned long first_gfn, unsigned long last_gfn,
+p2m_type_t ot, p2m_type_t nt)
+{
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
+p2m_type_t t;
+unsigned long gfn = first_gfn;
+
+ASSERT(first_gfn <= last_gfn);
+ASSERT(ot != nt);
+ASSERT(p2m_is_changeable(ot) && p2m_is_changeable(nt));
+
+p2m_lock(p2m);
+
+last_gfn = min(last_gfn, p2m->max_mapped_pfn);
+while ( gfn <= last_gfn )
+{
+get_gfn_query_unlocked(d, gfn, );
+
+if ( t == ot )
+p2m_change_type_one(d, gfn, t, nt);
+
+gfn++;
+}
+
+p2m_unlock(p2m);
+}
+
 /*
  * Returns:
  *0  for success
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 395f125..3d665e8 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -611,6 +611,13 @@ void p2m_change_type_range(struct domain *d,
 int p2m_change_type_one(struct domain *d, unsigned long gfn,
  

[Xen-devel] [PATCH v9 2/5] x86/ioreq server: Add DMOP to map guest ram with p2m_ioreq_server to an ioreq server.

[Yu Zhang]

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

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

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

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

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

changes in v8:
  - According to comments from Jan & Paul: comments changes in hvmemul_do_io().
  - According to comments from Jan: remove the redundant code which would only
be useful for read emulations.
  - According to comments from Jan: change interface which maps mem type to
ioreq server, removed uint16_t pad and added an uint64_t opaque.
  - Address other comments from Jan, i.e. correct return values; remove stray
cast.

changes in v7:
  - Use new ioreq server interface - XEN_DMOP_map_mem_type_to_ioreq_server.
  - According to comments from George: removed domain_pause/unpause() in
hvm_map_mem_type_to_ioreq_server(), because it's too expensive,
and we can avoid the:
a> deadlock issue existed in v6 patch, between p2m lock and ioreq server
   lock by using these locks in the same order - solved in patch 4;
b> for race condition between vm exit and ioreq server unbinding, we can
   just retry this instruction.
  - According to comments from Jan and George: continue to clarify logic in
hvmemul_do_io().
  - According to comments from Jan: clarify comment in p2m_set_ioreq_server().

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

changes in v5:
  - Simplify logic in hvmemul_do_io().
  - Use natual width types instead of fixed width types when possible.
  - Do not grant executable permission for p2m_ioreq_server entries.
  - Clarify comments and commit message.
  - Introduce a seperate patch to recalculate the p2m types after
the ioreq server unmaps the p2m_ioreq_server.

changes in v4:
  - According to Paul's advice, add comments around the definition
of HVMMEM_iore_server in hvm_op.h.
  - According to Wei Liu's comments, change the format of the commit
message.

changes in v3:
  - Only support write emulation in this patch;
  - Remove the code to handle race condition in hvmemul_do_io(),
  - No need to reset the p2m type after an ioreq server has disclaimed
its ownership of p2m_ioreq_server;
  - Only allow p2m type change to p2m_ioreq_server after an ioreq
server has claimed its ownership of p2m_ioreq_server;
  - Only allow p2m type change to p2m_ioreq_server from pages with type
p2m_ram_rw, and vice versa;
  - HVMOP_map_mem_type_to_ioreq_server interface change - use uint16,
instead of enum to specify the memory type;
  - Function prototype change to p2m_get_ioreq_server();
  - Coding style changes;
  - Commit message changes;
  - Add Tim's Acked-by.

changes in v2:
  - Only support HAP enabled HVMs;
  - Replace p2m_mem_type_changed() with p2m_change_entry_type_global()
to reset the p2m type, when an ioreq server tries to claim/disclaim
its ownership of p2m_ioreq_server;
  - 

[Xen-devel] [PATCH v9 3/5] x86/ioreq server: Handle read-modify-write cases for p2m_ioreq_server pages.

[Yu Zhang]

In ept_handle_violation(), write violations are also treated as
read violations. And when a VM is accessing a write-protected
address with read-modify-write instructions, the read emulation
process is triggered first.

For p2m_ioreq_server pages, current ioreq server only forwards
the write operations to the device model. Therefore when such page
is being accessed by a read-modify-write instruction, the read
operations should be emulated here in hypervisor. This patch provides
such a handler to copy the data to the buffer.

Note: MMIOs with p2m_mmio_dm type do not need such special treatment
because both reads and writes will go to the device mode.

Signed-off-by: Paul Durrant 
Signed-off-by: Yu Zhang 
---
Cc: Paul Durrant 
Cc: Jan Beulich 
Cc: Andrew Cooper 

changes in v3: 
  - According to comments from Jan: clarify comments in hvmemul_do_io().

changes in v2: 
  - According to comments from Jan: rename mem_ops to ioreq_server_ops.
  - According to comments from Jan: use hvm_copy_from_guest_phys() in
ioreq_server_read(), instead of do it by myself.
---
 xen/arch/x86/hvm/emulate.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 37139e6..52c726e 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -94,6 +94,26 @@ static const struct hvm_io_handler null_handler = {
 .ops = _ops
 };
 
+static int ioreq_server_read(const struct hvm_io_handler *io_handler,
+uint64_t addr,
+uint32_t size,
+uint64_t *data)
+{
+if ( hvm_copy_from_guest_phys(data, addr, size) != HVMCOPY_okay )
+return X86EMUL_UNHANDLEABLE;
+
+return X86EMUL_OKAY;
+}
+
+static const struct hvm_io_ops ioreq_server_ops = {
+.read = ioreq_server_read,
+.write = null_write
+};
+
+static const struct hvm_io_handler ioreq_server_handler = {
+.ops = _server_ops
+};
+
 static int hvmemul_do_io(
 bool_t is_mmio, paddr_t addr, unsigned long *reps, unsigned int size,
 uint8_t dir, bool_t df, bool_t data_is_addr, uintptr_t data)
@@ -193,6 +213,9 @@ static int hvmemul_do_io(
  *   - If the domain ioreq_server is NULL, assume there is a
  *   race between the unbinding of ioreq server and guest fault
  *   so re-try the instruction.
+ *
+ *   - If the accesss is a read, this could be part of a
+ *   read-modify-write instruction, emulate the read first.
  */
 struct hvm_ioreq_server *s = NULL;
 p2m_type_t p2mt = p2m_invalid;
@@ -226,6 +249,17 @@ static int hvmemul_do_io(
 vio->io_req.state = STATE_IOREQ_NONE;
 break;
 }
+
+/*
+ * This is part of a read-modify-write instruction.
+ * Emulate the read part so we have the value cached.
+ */
+if ( dir == IOREQ_READ )
+{
+rc = hvm_process_io_intercept(_server_handler, );
+vio->io_req.state = STATE_IOREQ_NONE;
+break;
+}
 }
 }
 
-- 
1.9.1


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

[Xen-devel] [PATCH v9 4/5] x86/ioreq server: Asynchronously reset outstanding p2m_ioreq_server entries.

[Yu Zhang]

After an ioreq server has unmapped, the remaining p2m_ioreq_server
entries need to be reset back to p2m_ram_rw. This patch does this
asynchronously with the current p2m_change_entry_type_global()
interface.

This patch also disallows live migration, when there's still any
outstanding p2m_ioreq_server entry left. The core reason is our
current implementation of p2m_change_entry_type_global() can not
tell the state of p2m_ioreq_server entries(can not decide if an
entry is to be emulated or to be resynced).

Note: new field entry_count is introduced in struct p2m_domain,
to record the number of p2m_ioreq_server p2m page table entries.
One nature of these entries is that they only point to 4K sized
page frames, because all p2m_ioreq_server entries are originated
from p2m_ram_rw ones in p2m_change_type_one(). We do not need to
worry about the counting for 2M/1G sized pages.

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

changes in v4: 
  - According to comments from Jan: use ASSERT() instead of 'if'
condition in p2m_change_type_one().
  - According to comments from Jan: commit message changes to mention
the p2m_ioreq_server are all based on 4K sized pages.

changes in v3: 
  - Move the synchronously resetting logic into patch 5.
  - According to comments from Jan: introduce p2m_check_changeable()
to clarify the p2m type change code.
  - According to comments from George: use locks in the same order
to avoid deadlock, call p2m_change_entry_type_global() after unmap
of the ioreq server is finished.

changes in v2: 
  - Move the calculation of ioreq server page entry_cout into 
p2m_change_type_one() so that we do not need a seperate lock.
Note: entry_count is also calculated in resolve_misconfig()/
do_recalc(), fortunately callers of both routines have p2m 
lock protected already.
  - Simplify logic in hvmop_set_mem_type().
  - Introduce routine p2m_finish_type_change() to walk the p2m 
table and do the p2m reset.
---
 xen/arch/x86/hvm/ioreq.c  |  8 
 xen/arch/x86/mm/hap/hap.c |  9 +
 xen/arch/x86/mm/p2m-ept.c |  8 +++-
 xen/arch/x86/mm/p2m-pt.c  | 13 +++--
 xen/arch/x86/mm/p2m.c | 20 
 xen/include/asm-x86/p2m.h |  9 -
 6 files changed, 63 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 746799f..102c6c2 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -949,6 +949,14 @@ int hvm_map_mem_type_to_ioreq_server(struct domain *d, 
ioservid_t id,
 
 spin_unlock_recursive(>arch.hvm_domain.ioreq_server.lock);
 
+if ( rc == 0 && flags == 0 )
+{
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+if ( read_atomic(>ioreq.entry_count) )
+p2m_change_entry_type_global(d, p2m_ioreq_server, p2m_ram_rw);
+}
+
 return rc;
 }
 
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index a57b385..6ec950a 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -187,6 +187,15 @@ out:
  */
 static int hap_enable_log_dirty(struct domain *d, bool_t log_global)
 {
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+/*
+ * Refuse to turn on global log-dirty mode if
+ * there's outstanding p2m_ioreq_server pages.
+ */
+if ( log_global && read_atomic(>ioreq.entry_count) )
+return -EBUSY;
+
 /* turn on PG_log_dirty bit in paging mode */
 paging_lock(d);
 d->arch.paging.mode |= PG_log_dirty;
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index cc1eb21..1df3d09 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -544,6 +544,12 @@ static int resolve_misconfig(struct p2m_domain *p2m, 
unsigned long gfn)
 e.ipat = ipat;
 if ( e.recalc && p2m_is_changeable(e.sa_p2mt) )
 {
+ if ( e.sa_p2mt == p2m_ioreq_server )
+ {
+ p2m->ioreq.entry_count--;
+ ASSERT(p2m->ioreq.entry_count >= 0);
+ }
+
  e.sa_p2mt = p2m_is_logdirty_range(p2m, gfn + i, gfn + 
i)
  ? p2m_ram_logdirty : p2m_ram_rw;
  ept_p2m_type_to_flags(p2m, , e.sa_p2mt, e.access);
@@ -965,7 +971,7 @@ static mfn_t ept_get_entry(struct p2m_domain *p2m,
 if ( is_epte_valid(ept_entry) )
 {
 if ( (recalc || ept_entry->recalc) &&
- p2m_is_changeable(ept_entry->sa_p2mt) )
+ p2m_check_changeable(ept_entry->sa_p2mt) )
 *t = p2m_is_logdirty_range(p2m, gfn, gfn) ? p2m_ram_logdirty

[Xen-devel] [PATCH v9 0/5] x86/ioreq server: Introduce HVMMEM_ioreq_server mem type.

[Yu Zhang]

XenGT leverages ioreq server to track and forward the accesses to GPU 
I/O resources, e.g. the PPGTT(per-process graphic translation tables).
Currently, ioreq server uses rangeset to track the BDF/ PIO/MMIO ranges
to be emulated. To select an ioreq server, the rangeset is searched to
see if the I/O range is recorded. However, number of ram pages to be
tracked may exceed the upper limit of rangeset.

Previously, one solution was proposed to refactor the rangeset, and 
extend its upper limit. However, after 12 rounds discussion, we have
decided to drop this approach due to security concerns. Now this new 
patch series introduces a new mem type, HVMMEM_ioreq_server, and added
hvm operations to let one ioreq server to claim its ownership of ram 
pages with this type. Accesses to a page of this type will be handled
by the specified ioreq server directly. 

Yu Zhang (5):
  x86/ioreq server: Release the p2m lock after mmio is handled.
  x86/ioreq server: Add DMOP to map guest ram with p2m_ioreq_server to
an ioreq server.
  x86/ioreq server: Handle read-modify-write cases for p2m_ioreq_server
pages.
  x86/ioreq server: Asynchronously reset outstanding p2m_ioreq_server
entries.
  x86/ioreq server: Synchronously reset outstanding p2m_ioreq_server
entries when an ioreq server unmaps.

 xen/arch/x86/hvm/dm.c|  72 ++-
 xen/arch/x86/hvm/emulate.c   |  99 +--
 xen/arch/x86/hvm/hvm.c   |   7 +--
 xen/arch/x86/hvm/ioreq.c |  46 +++
 xen/arch/x86/mm/hap/hap.c|   9 +++
 xen/arch/x86/mm/hap/nested_hap.c |   2 +-
 xen/arch/x86/mm/p2m-ept.c|  16 -
 xen/arch/x86/mm/p2m-pt.c |  32 +++---
 xen/arch/x86/mm/p2m.c| 123 +++
 xen/arch/x86/mm/shadow/multi.c   |   3 +-
 xen/include/asm-x86/hvm/ioreq.h  |   2 +
 xen/include/asm-x86/p2m.h|  42 +++--
 xen/include/public/hvm/dm_op.h   |  28 +
 xen/include/public/hvm/hvm_op.h  |   8 ++-
 14 files changed, 459 insertions(+), 30 deletions(-)

-- 
1.9.1


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

[Xen-devel] [PATCH v9 1/5] x86/ioreq server: Release the p2m lock after mmio is handled.

[Yu Zhang]

Routine hvmemul_do_io() may need to peek the p2m type of a gfn to
select the ioreq server. For example, operations on gfns with
p2m_ioreq_server type will be delivered to a corresponding ioreq
server, and this requires that the p2m type not be switched back
to p2m_ram_rw during the emulation process. To avoid this race
condition, we delay the release of p2m lock in hvm_hap_nested_page_fault()
until mmio is handled.

Note: previously in hvm_hap_nested_page_fault(), put_gfn() was moved
before the handling of mmio, due to a deadlock risk between the p2m
lock and the event lock(in commit 77b8dfe). Later, a per-event channel
lock was introduced in commit de6acb7, to send events. So we do not
need to worry about the deadlock issue.

Signed-off-by: Yu Zhang 
Reviewed-by: Jan Beulich 
---
Cc: Paul Durrant 
Cc: Jan Beulich 
Cc: Andrew Cooper 

changes in v4: 
  - According to comments from Jan: remove the redundant "rc = 0" code.
---
 xen/arch/x86/hvm/hvm.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 0282986..bd18d8e 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1815,15 +1815,10 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned 
long gla,
  (npfec.write_access &&
   (p2m_is_discard_write(p2mt) || (p2mt == p2m_ioreq_server))) )
 {
-__put_gfn(p2m, gfn);
-if ( ap2m_active )
-__put_gfn(hostp2m, gfn);
-
-rc = 0;
 if ( !handle_mmio_with_translation(gla, gpa >> PAGE_SHIFT, npfec) )
 hvm_inject_hw_exception(TRAP_gp_fault, 0);
 rc = 1;
-goto out;
+goto out_put_gfn;
 }
 
 /* Check if the page has been paged out */
-- 
1.9.1


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

[Xen-devel] [linux-linus test] 106788: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-xsm 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck 11 guest-start fail REGR. vs. 59254
 test-armhf-armhf-libvirt 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu 11 guest-start  fail REGR. vs. 59254

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pair 4 host-install/dst_host(4) broken in 106781 pass in 
106788
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail pass in 
106781
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 20 leak-check/check fail pass in 
106781

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254
 test-armhf-armhf-xl-vhd   9 debian-di-install   fail baseline untested
 test-armhf-armhf-libvirt-raw  9 debian-di-install   fail baseline untested
 test-amd64-amd64-rumprun-amd64 16 rumprun-demo-xenstorels/xenstorels.repeat 
fail in 106781 baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop   fail in 106781 like 59254
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   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-amd64-i386-libvirt  12 migrate-support-checkfail   never pass

version targeted for testing:
 linux97da3854c526d3a6ee05c849c96e48d21527606c
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  620 days
Failing since 59348  2015-07-10 04:24:05 Z  619 days  348 attempts
Testing same since   106781  2017-03-20 06:49:27 Z0 days2 attempts


8087 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  fail
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  blocked 
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvops   

Re: [Xen-devel] [PATCH v8 1/5] x86/ioreq server: Release the p2m lock after mmio is handled.

[Yu Zhang]

On 3/21/2017 9:18 AM, Yu Zhang wrote:



On 3/21/2017 1:03 AM, Jan Beulich wrote:

On 18.03.17 at 11:53,  wrote:

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1870,18 +1870,14 @@ int hvm_hap_nested_page_fault(paddr_t gpa, 
unsigned long gla,

   (npfec.write_access &&
(p2m_is_discard_write(p2mt) || (p2mt == 
p2m_ioreq_server))) )

  {
-__put_gfn(p2m, gfn);
-if ( ap2m_active )
-__put_gfn(hostp2m, gfn);
-
  rc = 0;
  if ( unlikely(is_pvh_domain(currd)) )
-goto out;
+goto out_put_gfn;

Did you forget to re-base onto staging before you've sent this?
is_pvh_domain() was gone before your submission already. When
re-basing, feel free to also drop the dead "rc = 0;" line.


Oops...
I did a rebase days ago, but did not send the patch directly. There 
were some XenGT test performed based on these patch.

Sorry, I should have a check.  Will resend the patch. :)



BTW, since there's another change - "drop the rc = 0", I'd like to send 
the new patchset with a new version nubmer. :-)


Yu


___
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] [RFC PATCH 00/23] xen/vIOMMU: Add vIOMMU support with irq remapping fucntion on Intel platform

[Lan Tianyu]

On 2017年03月20日 22:23, Roger Pau Monné wrote:
> Thanks! So you add all this vIOMMU code, but the maximum number of allowed
> vCPUs for HVM guests is still limited to 128 (HVM_MAX_VCPUS is not touched). 
> Is
> there any missing pieces in order to bump this?

To increase vcpu number, we need to change APIC ID rule and now it's
APICID = VCPUID * 2. Andrew's CPUID improvement will change it and so
our following patches of increasing vcpu number will base on Andrew's job.


> 
> Also, have you tested if this series works with PVH guests? Boris added PVH
> support to Linux not long ago, so you should be able to test it just by 
> picking
> the latest Linux kernel.

Our patchset just targets hvm guest and it will not work for PV guest.

-- 
Best regards
Tianyu Lan

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

Re: [Xen-devel] question: xen/qemu - mmio mapping issues for device pass-through

[Xuquan (Quan Xu)]

On March 20, 2017 3:35 PM, Jan Beulich wrote:
 On 20.03.17 at 02:58,  wrote:
>> On March 16, 2017 11:32 PM, Jan Beulich wrote:
>> On 16.03.17 at 15:21,  wrote:
 On March 16, 2017 10:06 PM, Jan Beulich wrote:
 On 16.03.17 at 14:55,  wrote:
>> I try to pass-through a device with 8G large bar, such as nvidia
>> M60(note1, pci-e info as below). It takes about '__15 sconds__' to
>> update 8G large bar in QEMU::xen_pt_region_update()..
>> Specifically, it is xc_domain_memory_mapping() in
>>>xen_pt_region_update().
>>
>> Digged into xc_domain_memory_mapping(), I find it mainly call
>> "do_domctl
>> （…case XEN_DOMCTL_memory_mapping…）"
>> to mapping mmio region.. of cause, I find out that this mapping
>> could take a while in the code comment below ' case
>XEN_DOMCTL_memory_mapping '.
>>
>> my questions:
>> 1. could we make this mapping mmio region quicker?
>

 Thanks for your quick reply.

>Yes, e.g. by using large (2M or 1G) pages. This has been on my todo
>list for quite a while...
>
>> 2. if could not, does it limit by hardware performance?
>
>I'm afraid I don't understand the question. If you mean "Is it
>limited by hw performance", then no, see above. If you mean "Does it
>limit hw performance", then again no, I don't think so (other than
>the effect of having more IOMMU translation levels than really
>necessary for such
>>>large a region).
>

 Sorry, my question is  "Is it limited by hw performance"...

 I am much confused. why does this mmio mapping take a while?
 I guessed it takes a lot of time to set up p2m / iommu entry. That's
 why I ask "Is it limited by hw performance".
>>>
>>>Well, just count the number of page table entries and that of the
>>>resulting hypercall continuations. It's the sheer amount of work
>>>that's causing the slowness, together with the need for us to use
>>>continuations to be on the safe side. There may well be redundant TLB
>>>invalidations as well. Since we can do better (by using large
>>>pages) I wouldn't call this "limited by hw performance", but of course
>>>one may.
>>>
>>
>> I agree.
>> So far as I know, xen upstream doesn't support to pass-through
>> large bar (pci-e bar > 4G) device, such as nvidia M60, However cloud
>> providers may want to leverage this feature for machine learning .etc.
>> Is it on your TODO list?
>
>Is what on my todo list?

support to pass-through large bar (pci-e bar > 4G) device..

> I was assuming large BAR handling to work so far
>(Konrad had done some adjustments there quite a while ago, from all I recall).
>


_iirc_ what Konrad mentioned was using qemu-trad..


Quan

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

Re: [Xen-devel] [PATCH v8 1/5] x86/ioreq server: Release the p2m lock after mmio is handled.

[Yu Zhang]

On 3/21/2017 1:03 AM, Jan Beulich wrote:

On 18.03.17 at 11:53,  wrote:

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1870,18 +1870,14 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned 
long gla,
   (npfec.write_access &&
(p2m_is_discard_write(p2mt) || (p2mt == p2m_ioreq_server))) )
  {
-__put_gfn(p2m, gfn);
-if ( ap2m_active )
-__put_gfn(hostp2m, gfn);
-
  rc = 0;
  if ( unlikely(is_pvh_domain(currd)) )
-goto out;
+goto out_put_gfn;

Did you forget to re-base onto staging before you've sent this?
is_pvh_domain() was gone before your submission already. When
re-basing, feel free to also drop the dead "rc = 0;" line.


Oops...
I did a rebase days ago, but did not send the patch directly. There were 
some XenGT test performed based on these patch.

Sorry, I should have a check.  Will resend the patch. :)

B.R.
Yu

Jan





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

Re: [Xen-devel] [RFC PATCH 0/4] Qemu: Add Xen vIOMMU support

[Lan Tianyu]

On 2017年03月20日 19:38, Paolo Bonzini wrote:
> Fair enough, though I'd be worried about increasing the attack surface
> of the hypervisor.  For KVM, for example, IOMMU emulation requires using
> the "split irqchip" feature to move the PIC and IOAPIC out of the kernel
> and back to QEMU.

Yes, just like Roger mentioned we also need to support no-qemu mode on
Xen and this is tradeoff result.

> 
> Also, I think this series is missing changes to support IOMMU
> translation in the vIOMMU device model.

Yes, this series just enabled vIOMMU's irq remapping function and we
need to pass virtual device's DMA request to Xen hypervisor for
translation when enable DMA translation.

-- 
Best regards
Tianyu Lan

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

Re: [Xen-devel] [PATCH 11/11] Enable cirros tests in the default config

[Stefano Stabellini]

On Sun, 19 Mar 2017, Géza Gémes wrote:
> The existing cirros tests are enabled, with the following
> exceptions:
> 
> cirros-minios-stubdom-hvm and cirros-minios-stubdom-pvhvm are
> skipped as raisin does not install the stubdom
> 
> Signed-off-by: Géza Gémes 

Reviewed-by: Stefano Stabellini 

> ---
>  defconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/defconfig b/defconfig
> index 111554e..f3b1759 100644
> --- a/defconfig
> +++ b/defconfig
> @@ -31,6 +31,6 @@ GIT_TRANSPORT="git"
>  # Tests
>  ## All tests: busybox-pv busybox-hvm
>  ## ENABLED_TESTS is the list of test run by raise test
> -ENABLED_TESTS="busybox-pv busybox-hvm"
> +ENABLED_TESTS="busybox-pv busybox-hvm cirros-separate-kernel-pv 
> cirros-pygrub-pv cirros-pvgrub2-pv cirros-qemu-hvm cirros-qemu-pvhvm"
>  
>  . configs/config-cirros
> -- 
> 2.7.4
> ___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [raisin][PATCH 00/11] pygrub fix + cirros tests

[Stefano Stabellini]

Thanks for the patches! :-)

I committed patch #2. Please resend the rest of the series addressing
the comments. I didn't reply to each patch, but the cirros tests look
good except for the few comments regarding the way they interact with
the common functions.

Cheers,

Stefano


On Sun, 19 Mar 2017, Géza Gémes wrote:
> First patch adds a symlink from python2.7/site-packages/*
> to python2.7/dist-packages/ at debian package build, this fixes
> pygrub imports.
> 
> The rest of the patches are the cirros tests rebased to current master
> and the python fix, plus a trivial fix for the pygrub test. in this
> new patchset pygrub test is also added to the ones in the default set.
> 
> Géza Gémes (11):
>   Fix installation of python libs
>   Fix lopartsetup parsing of fdisk output
>   Introduce cirros tests
>   Introduce cirros-separate-kernel-pv test
>   Introduce cirros-pygrub-pv test
>   Introduce cirros-pvgrub2-pv test
>   Introduce cirros-qemu-hvm test
>   Introduce cirros-minios-stubdom-hvm test
>   Introduce cirros-qemu-pvhvm test
>   Introduce cirros-minios-stubdom-pvhvm test
>   Enable cirros tests in the default config
> 
>  configs/config-cirros |  44 
>  defconfig |   4 +-
>  lib/common-tests.sh   | 102 
> ++
>  scripts/lopartsetup   |   6 ++-
>  scripts/mkdeb |   9 
>  tests/cirros-minios-stubdom-hvm   |  29 +++
>  tests/cirros-minios-stubdom-pvhvm |  30 +++
>  tests/cirros-pvgrub2-pv   |  27 ++
>  tests/cirros-pygrub-pv|  27 ++
>  tests/cirros-qemu-hvm |  28 +++
>  tests/cirros-qemu-pvhvm   |  29 +++
>  tests/cirros-separate-kernel-pv   |  28 +++
>  tests/series  |   7 +++
>  13 files changed, 368 insertions(+), 2 deletions(-)
>  create mode 100644 configs/config-cirros
>  create mode 100644 tests/cirros-minios-stubdom-hvm
>  create mode 100644 tests/cirros-minios-stubdom-pvhvm
>  create mode 100644 tests/cirros-pvgrub2-pv
>  create mode 100644 tests/cirros-pygrub-pv
>  create mode 100644 tests/cirros-qemu-hvm
>  create mode 100644 tests/cirros-qemu-pvhvm
>  create mode 100644 tests/cirros-separate-kernel-pv
> 
> -- 
> 2.7.4
> ___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 04/11] Introduce cirros-separate-kernel-pv test

[Stefano Stabellini]

On Sun, 19 Mar 2017, Géza Gémes wrote:
> This test is the cirros equivalent of the bussybox-pv test
> 
> Signed-off-by: Géza Gémes 
> ---
>  tests/cirros-separate-kernel-pv | 28 
>  tests/series|  1 +
>  2 files changed, 29 insertions(+)
>  create mode 100644 tests/cirros-separate-kernel-pv
> 
> diff --git a/tests/cirros-separate-kernel-pv b/tests/cirros-separate-kernel-pv
> new file mode 100644
> index 000..bbbcf7d
> --- /dev/null
> +++ b/tests/cirros-separate-kernel-pv
> @@ -0,0 +1,28 @@
> +#!/usr/bin/env bash
> +
> +set -e
> +
> +function cirros-separate-kernel-pv-cleanup() {
> +tear_down_cirros_tests $tmpdir
> +}
> +
> +function cirros-separate-kernel-pv-test() {
> +if [[ ! -d $tmpdir ]]
> +then
> +set_up_cirros_tests

As I wrote in reply to the other patch, I would remove tmpdir and create
one from scratch for each test (but download the cirros images only
once).

Also, we need a pv specific init function here.

The rest looks good, thanks!


> +fi
> +cd $tmpdir
> +cat >cirros-separate-kernel-pv.cfg < +name = "raisin-test"
> +memory = 128
> +vcpus = 2
> +kernel = "${tmpdir}/${CIRROS_KERNEL_FILE}"
> +ramdisk = "${tmpdir}/${CIRROS_INITRD_FILE}"
> +disk = [ '${tmpdir}/${CIRROS_ROOTFS_FILE},raw,xvda,rw' ]
> +extra = "root=/dev/xvda"
> +vif = [ 'bridge=xenbr1' ]
> +EOF
> +
> +$SUDO xl create cirros-separate-kernel-pv.cfg
> +check_guest_alive
> +}
> diff --git a/tests/series b/tests/series
> index a2f4b34..38ee35a 100644
> --- a/tests/series
> +++ b/tests/series
> @@ -1,3 +1,4 @@
>  busybox-pv
>  busybox-hvm
>  busybox-hvm-migrate
> +cirros-separate-kernel-pv
> -- 
> 2.7.4
> ___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 03/11] Introduce cirros tests

[Stefano Stabellini]

On Sun, 19 Mar 2017, Géza Gémes wrote:
> Add support for using cirros images in raisin tests
> 
> Signed-off-by: Géza Gémes 
> ---
>  configs/config-cirros |  44 ++
>  defconfig |   2 +
>  lib/common-tests.sh   | 102 
> ++
>  3 files changed, 148 insertions(+)
>  create mode 100644 configs/config-cirros
> 
> diff --git a/configs/config-cirros b/configs/config-cirros
> new file mode 100644
> index 000..fa2823e
> --- /dev/null
> +++ b/configs/config-cirros

The files under configs are meant to contain the git urls and software
versions of each component to build. It is not the right place for all
these cirros related variables.

Instead, I would move config-cirros to a new top level directory, maybe
I would call it "tests-configs".



> @@ -0,0 +1,44 @@
> +CIRROS_BASE_URL="https://download.cirros-cloud.net/;
> +CIRROS_VERSION="0.3.5"
> +
> +source `pwd`/lib/common-functions.sh
> +get_arch
> +case $RAISIN_ARCH in
> +x86_64)
> +CIRROS_ARCH=x86_64
> +;;
> +x86_32)
> +CIRROS_ARCH=i386
> +;;
> +*)
> +echo $PREPEND cirros tests only valid on x86, 32 or 64 bit
> +exit 1
> +esac
> +
> +CIRROS_KERNEL_FILE=cirros-${CIRROS_VERSION}-${CIRROS_ARCH}-kernel
> +CIRROS_INITRD_FILE=cirros-${CIRROS_VERSION}-${CIRROS_ARCH}-initramfs
> +CIRROS_ROOTFS_FILE=cirros-${CIRROS_VERSION}-${CIRROS_ARCH}-rootfs.img
> +CIRROS_DISK_FILE=cirros-${CIRROS_VERSION}-${CIRROS_ARCH}-disk.img
> +CIRROS_KERNEL_URL=${CIRROS_BASE_URL}/${CIRROS_VERSION}/${CIRROS_KERNEL_FILE}
> +CIRROS_INITRD_URL=${CIRROS_BASE_URL}/${CIRROS_VERSION}/${CIRROS_INITRD_FILE}
> +CIRROS_ROOTFS_URL=${CIRROS_BASE_URL}/${CIRROS_VERSION}/${CIRROS_ROOTFS_FILE}.gz
> +CIRROS_DISK_URL=${CIRROS_BASE_URL}/${CIRROS_VERSION}/${CIRROS_DISK_FILE}
> +
> +CIRROS_GRUB_CFG="(xen/xvda,msdos1)/boot/grub/grub.cfg"
> +

I like to keep the config files as simple as possible, with just
parameters and variable assignments. Ideally, we would have one
config-cirros file with only varibles, like configs/config-master for
example. Everything else should be elsewhere. I would even go as far as
removing the get_arch call above, writing two fully static cirros config
files, one for x86_64 and one for x86_32.


> +set +e
> +QEMU_IMG=`which qemu-img`
> +set -e
> +if [[ -z "$QEMU_IMG" ]]
> +then
> +QEMU_IMG="/usr/lib/xen/bin/qemu-img"
> +fi
> +
> +set +e
> +PVGRUB=`which grub-${CIRROS_ARCH}-xen`
> +set -e
> +if [[ -z "$PVGRUB" ]]
> +then
> +PVGRUB="/usr/lib/xen/boot/grub-${CIRROS_ARCH}-xen"
> +fi

I would move the detection of QEMU_IMG and PVGRUB to functions in
lib/common-functions.sh.


> diff --git a/defconfig b/defconfig
> index f8ef398..111554e 100644
> --- a/defconfig
> +++ b/defconfig
> @@ -32,3 +32,5 @@ GIT_TRANSPORT="git"
>  ## All tests: busybox-pv busybox-hvm
>  ## ENABLED_TESTS is the list of test run by raise test
>  ENABLED_TESTS="busybox-pv busybox-hvm"
> +
> +. configs/config-cirros
> diff --git a/lib/common-tests.sh b/lib/common-tests.sh
> index d346af4..79815ce 100644
> --- a/lib/common-tests.sh
> +++ b/lib/common-tests.sh
> @@ -178,3 +178,105 @@ function get_host_initrd() {
>  exit 1
>  fi
>  }
> +
> +function cirros_network_init() {
> +rootdir=$1
> +# Configure static ip
> +$SUDO sed -i -e 's/iface eth0 inet dhcp/iface eth0 inet static/' 
> ${rootdir}/etc/network/interfaces
> +$SUDO sed -i -e '/iface eth0 inet static/a\address 169.254.0.2' 
> ${rootdir}/etc/network/interfaces
> +$SUDO sed -i -e '/address/a\network 169.254.0.0' 
> ${rootdir}/etc/network/interfaces
> +$SUDO sed -i -e '/network/a\broadcast 169.254.0.255' 
> ${rootdir}/etc/network/interfaces
> +$SUDO sed -i -e '/broadcast/a\netmask 255.255.255.0' 
> ${rootdir}/etc/network/interfaces

I think that it would be more future-proof to just generate and
overwrite ${rootdir}/etc/network/interfaces with our own. Also in
general we don't use ${} for variables.


> +# Disable cloud-init
> +$SUDO rm -f ${rootdir}/etc/rc3.d/S*cirros*ds*
> +$SUDO rm -f ${rootdir}/etc/rc3.d/S*-cirros-userdata
> +}
> +
> +function get_cirros_kernel() {
> +bootdir=$1
> +basename `find $bootdir -name vmlinuz* 2>/dev/null | head -1`
> +}
> +
> +function get_cirros_initrd() {
> +bootdir=$1
> +basename `find $bootdir -name initrd* 2>/dev/null | head -1`
> +}
> +
> +function cirros_grub_cfg() {
> +rootdir=$1
> +grubcfg="`echo $CIRROS_GRUB_CFG | cut -d ')' -f 2`"
> +grubdir=`dirname $grubcfg`
> +bootdir=`dirname $grubdir`
> +tmpgrubcfg=`mktemp`
> +cat > $tmpgrubcfg < +root='(xen/xvda,msdos1)'
> +insmod xzio
> +insmod gzio
> +insmod btrfs
> +insmod ext2
> +set timeout=1
> +set default=0
> +menuentry Cirros {
> +linux `echo $bootdir`/`get_cirros_kernel ${rootdir}/${bootdir}` 
> root=/dev/xvda1 ro
> +initrd `echo $bootdir`/`get_cirros_initrd ${rootdir}/${bootdir}`
> +}
> +EOF
> +

Re: [Xen-devel] [PATCH 02/18] xen/arm: Restore HCR_EL2 register

[Stefano Stabellini]

On Thu, 16 Mar 2017, Julien Grall wrote:
> Hi Stefano
> 
> On 03/16/2017 10:33 PM, Stefano Stabellini wrote:
> > On Wed, 15 Mar 2017, Julien Grall wrote:
> > > Hi Wei,
> > > 
> > > On 15/03/17 08:34, Wei Chen wrote:
> > > > On 2017/3/15 8:25, Stefano Stabellini wrote:
> > > > > On Mon, 13 Mar 2017, Wei Chen wrote:
> > > > > > Different domains may have different HCR_EL2 flags. For example, the
> > > > > > 64-bit domain needs HCR_RW flag but the 32-bit does not need it. So
> > > > > > we give each domain a default HCR_EL2 value and save it in the
> > > > > > VCPU's
> > > > > > context.
> > > > > > 
> > > > > > HCR_EL2 register has only one bit can be updated automatically
> > > > > > without
> > > > > > explicit write (HCR_VSE). But we haven't used this bit currently, so
> > > > > > we can consider that the HCR_EL2 register will not be modified while
> > > > > > the guest is running. So save the HCR_EL2 while guest exiting to
> > > > > > hypervisor is not neccessary. We just have to restore this register
> > > > > > for
> > > > > > each VCPU while leaving hypervisor.
> > > > > > 
> > > > > > We prefer to restore HCR_EL2 in leave_hypervisor_tail rather than in
> > > > > > ctxt_switch_to. Because the leave_hypervisor_tail is the closest
> > > > > > place
> > > > > > to the exception return. In this case, we don't need to warrant the
> > > > > > HCR_EL2 will not be changed between ctxt_switch_to and exception
> > > > > > return.
> > > > > 
> > > > > Please explain a bit better why it is good to restore HCR_EL2 in
> > > > > leave_hypervisor_tail. Why is it a good thing that is closer to the
> > > > > exception return? What can be the cause of a change in HCR_EL2?
> > > > > 
> > > > 
> > > > Ok, I will try to improve it in next version. In current Xen code, I
> > > > can't see any code would change the HCR_EL2 between ctxt_switch_to and
> > > > return_from_trap. But my concern is that, in the future, if someone
> > > > want to insert some HCR_EL2 change code between them, we can't guarantee
> > > > he will restore correct HCR_EL2 value for current vcpu.
> > > 
> > > Well, the purpose of this series is to inject a virtual SError to the
> > > guest
> > > when a host SError is happening. The host SError will be received in the
> > > hypervisor whilst the vCPU is running and no context switch (e.g call to
> > > ctxt_switch) may happen if the scheduler decides to keep the vCPU running.
> > > 
> > > Also, one could argue that HCR_EL2 could be modified on-fly in the
> > > function
> > > but we may have other places in the future which will modify HCR_EL2. For
> > > instance, this would be the case when the monitor app will gain support of
> > > inspecting some registers.
> > > 
> > > So we want a single place to restore HCR_EL2. And leave_hypervisor_tail is
> > > the
> > > best place for that.
> > 
> > You say that we want a single place to restore HCR_EL2, but this patch
> > introduces two places, one is p2m_restore_state, the other is
> > leave_hypervisor_tail. Are you saying Wei should remove the HCR_EL2
> > restore in p2m_restore_state and just keep the one in
> > leave_hypervisor_tail?
> 
> p2m_restore_state may be used to switch temporarily to a p2m state. For
> instance for TLB flushing or even doing VA -> PA translation. Though the later
> does not yet work quite well when not using the current vCPU.
> 
> Some bits in HCR_EL2 (specifically HCR_EL2.RW) will be used to know how to
> interpret the stage-1 page table as the encoding differ between AArch64 and
> AArch32.
>
> So I think we have to keep the one in p2m_restore_state. But I would like to
> keep the number very limited.

I understand, but restoring HCR_EL2 twice is very counter-intuitive. At
the very least we need a good comment above each of the two
write(HCR_EL2) calls.

Another option would be to only "fix" HCR_RW in p2m_restore_state, and
do the full restore in leave_hypervisor_tail. The purpose of doing that
is separation of responsibilities: it would be clearer what is the
responsibility of each of the two.

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

Re: [Xen-devel] [PATCH 02/11] Fix lopartsetup parsing of fdisk output

[Stefano Stabellini]

On Sun, 19 Mar 2017, Géza Gémes wrote:
> Change lopartsetup in order to handle partitions, which have the
> boot flag enabled.
> 
> Signed-off-by: Géza Gémes 

Reviewed-by: Stefano Stabellini 


> ---
>  scripts/lopartsetup | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/lopartsetup b/scripts/lopartsetup
> index bf33a28..04ce3cc 100755
> --- a/scripts/lopartsetup
> +++ b/scripts/lopartsetup
> @@ -58,7 +58,11 @@ index=0
>  for i in "`fdisk -lu $filename 2>/dev/null | grep -e "^$filename"`"
>  do
>  index=$((index+1))
> -offset=`echo $i | tr -s " " | cut -d " " -f 2`
> +offset=`echo "$i" | tr -s " " | cut -d " " -f 2`
> +if [[ "$offset" == "*" ]]
> +then
> +offset=`echo "$i" | tr -s " " | cut -d " " -f 3`
> +fi
>  offset=$((unit*offset))
>  
>  _create_loop_device "$filename" "$index" "$offset"
> -- 
> 2.7.4
> ___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 01/11] Fix installation of python libs

[Stefano Stabellini]

On Sun, 19 Mar 2017, Géza Gémes wrote:
> Change deb package build in order to symlink the files installed
> to site-packages to dist-packages to have them inluded in the
> default PYTHONPATH
> 
> Signed-off-by: Géza Gémes 
> ---
>  scripts/mkdeb | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/scripts/mkdeb b/scripts/mkdeb
> index 3796300..23bcc2a 100755
> --- a/scripts/mkdeb
> +++ b/scripts/mkdeb
> @@ -46,6 +46,15 @@ then
>  rm -rf deb/usr/lib64
>  fi
>  
> +# Make sure that python libs will be in the path
> +mkdir -p deb/usr/lib/python2.7/dist-packages/
> +cd deb/usr/lib/python2.7/dist-packages/
> +for file in `ls ../site-packages`
> +do
> +ln -s ../site-packages/$file .
> +done
> +cd -

Actually for Debian I think it makes sense to move (not link) the files
to dist-packages, what do you think?


>  # Fill in the debian boilerplate
>  mkdir -p deb/DEBIAN
>  cat >deb/DEBIAN/control < -- 
> 2.7.4
> ___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/3] xen: sched_null: support for hard affinity

[Stefano Stabellini]

On Fri, 17 Mar 2017, Dario Faggioli wrote:
> As a (rudimental) way of directing and affecting the
> placement logic implemented by the scheduler, support
> vCPU hard affinity.
> 
> Basically, a vCPU will now be assigned only to a pCPU
> that is part of its own hard affinity. If such pCPU(s)
> is (are) busy, the vCPU will wait, like it happens
> when there are no free pCPUs.
> 
> Signed-off-by: Dario Faggioli 
> ---
> Cc: George Dunlap 
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> Cc: Jonathan Davies 
> Cc: Marcus Granado 
> ---
>  xen/common/sched_null.c |   43 ---
>  1 file changed, 32 insertions(+), 11 deletions(-)
> 
> diff --git a/xen/common/sched_null.c b/xen/common/sched_null.c
> index 6a13308..ea055f1 100644
> --- a/xen/common/sched_null.c
> +++ b/xen/common/sched_null.c
> @@ -117,6 +117,14 @@ static inline struct null_dom *null_dom(const struct 
> domain *d)
>  return d->sched_priv;
>  }
>  
> +static inline bool check_nvc_affinity(struct null_vcpu *nvc, unsigned int 
> cpu)
> +{
> +cpumask_and(cpumask_scratch_cpu(cpu), nvc->vcpu->cpu_hard_affinity,
> +cpupool_domain_cpumask(nvc->vcpu->domain));
> +
> +return cpumask_test_cpu(cpu, cpumask_scratch_cpu(cpu));
> +}

If you make it take a struct vcpu* as first argument, it will be more
generally usable


>  static int null_init(struct scheduler *ops)
>  {
>  struct null_private *prv;
> @@ -284,16 +292,20 @@ static unsigned int pick_cpu(struct null_private *prv, 
> struct vcpu *v)
>  
>  ASSERT(spin_is_locked(per_cpu(schedule_data, cpu).schedule_lock));
>  
> +cpumask_and(cpumask_scratch_cpu(cpu), v->cpu_hard_affinity, cpus);
> +
>  /*
>   * If our processor is free, or we are assigned to it, and it is
> - * also still valid, just go for it.
> + * also still valid and part of our affinity, just go for it.
>   */
>  if ( likely((per_cpu(npc, cpu).vcpu == NULL || per_cpu(npc, cpu).vcpu == 
> v)
> -&& cpumask_test_cpu(cpu, cpus)) )
> +&& cpumask_test_cpu(cpu, cpumask_scratch_cpu(cpu))) )

Then you can use it here:
 check_nvc_affinity(v, cpu);


>  return cpu;
>  
> -/* If not, just go for a valid free pCPU, if any */
> +/* If not, just go for a free pCPU, within our affinity, if any */
>  cpumask_and(cpumask_scratch_cpu(cpu), >cpus_free, cpus);
> +cpumask_and(cpumask_scratch_cpu(cpu), cpumask_scratch_cpu(cpu),
> +v->cpu_hard_affinity);

You can do this with one cpumask_and (in addition to the one above):

   cpumask_and(cpumask_scratch_cpu(cpu), cpumask_scratch_cpu(cpu),
   >cpus_free);


>  cpu = cpumask_first(cpumask_scratch_cpu(cpu));
>  
>  /*
> @@ -308,7 +320,10 @@ static unsigned int pick_cpu(struct null_private *prv, 
> struct vcpu *v)
>   * only if the pCPU is free.
>   */
>  if ( unlikely(cpu == nr_cpu_ids) )
> -cpu = cpumask_any(cpus);
> +{
> +cpumask_and(cpumask_scratch_cpu(cpu), cpus, v->cpu_hard_affinity);

Could the intersection be 0?


> +cpu = cpumask_any(cpumask_scratch_cpu(cpu));
> +}
>  
>  return cpu;
>  }
> @@ -391,6 +406,9 @@ static void null_vcpu_insert(const struct scheduler *ops, 
> struct vcpu *v)
>  lock = pcpu_schedule_lock(cpu);
>  }
>  
> +cpumask_and(cpumask_scratch_cpu(cpu), v->cpu_hard_affinity,
> + cpupool_domain_cpumask(v->domain));
> +

coding style


>  /*
>   * If the pCPU is free, we assign v to it.
>   *
> @@ -408,8 +426,7 @@ static void null_vcpu_insert(const struct scheduler *ops, 
> struct vcpu *v)
>   */
>  vcpu_assign(prv, v, cpu);
>  }
> -else if ( cpumask_intersects(>cpus_free,
> - cpupool_domain_cpumask(v->domain)) )
> +else if ( cpumask_intersects(>cpus_free, cpumask_scratch_cpu(cpu)) )
>  {
>  spin_unlock(lock);
>  goto retry;
> @@ -462,7 +479,7 @@ static void null_vcpu_remove(const struct scheduler *ops, 
> struct vcpu *v)
>  
>  spin_lock(>waitq_lock);
>  wvc = list_first_entry_or_null(>waitq, struct null_vcpu, 
> waitq_elem);
> -if ( wvc )
> +if ( wvc && cpumask_test_cpu(cpu, cpumask_scratch_cpu(cpu)) )

shouldn't this be

check_nvc_affinity(wvc, cpu)

?


>  {
>  vcpu_assign(prv, wvc->vcpu, cpu);
>  list_del_init(>waitq_elem);
> @@ -550,7 +567,7 @@ static void null_vcpu_migrate(const struct scheduler 
> *ops, struct vcpu *v,
>  
>  spin_lock(>waitq_lock);
>  wvc = list_first_entry_or_null(>waitq, struct null_vcpu, 
> waitq_elem);
> -if ( wvc && cpumask_test_cpu(cpu, cpupool_domain_cpumask(v->domain)) 
> )
> +if ( wvc && check_nvc_affinity(wvc, cpu) )
>  {
>  vcpu_assign(prv, wvc->vcpu, cpu);
>

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

[osstest service owner]

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  6 xen-boot fail REGR. vs. 106778
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 106778
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 106778
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 106778
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 106778
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 106778
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106778
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 106778

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 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-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 xen  4fc380ac0077ecd6b0e0013ca7ca977cb7361662
baseline version:
 xen  02b37b7eff39e40828041b2fe480725ab8443258

Last test of basis   106778  2017-03-20 01:57:56 Z0 days
Testing same since   106786  2017-03-20 11:17:23 Z0 days1 attempts


People who touched revisions under test:
  Boris Ostrovsky 
  Jan Beulich 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  fail
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 

Re: [Xen-devel] [PATCH 1/3] xen: sched: introduce the 'null' semi-static scheduler

[Stefano Stabellini]

On Fri, 17 Mar 2017, Dario Faggioli wrote:
> In cases where one is absolutely sure that there will be
> less vCPUs than pCPUs, having to pay the cose, mostly in
> terms of overhead, of an advanced scheduler may be not
> desirable.
> 
> The simple scheduler implemented here could be a solution.
> Here how it works:
>  - each vCPU is statically assigned to a pCPU;
>  - if there are pCPUs without any vCPU assigned, they
>stay idle (as in, the run their idle vCPU);
>  - if there are vCPUs which are not assigned to any
>pCPU (e.g., because there are more vCPUs than pCPUs)
>they *don't* run, until they get assigned;
>  - if a vCPU assigned to a pCPU goes away, one of the
>waiting to be assigned vCPU, if any, gets assigned
>to the pCPU and can run there.
> 
> This scheduler, therefore, if used in configurations
> where every vCPUs can be assigned to a pCPU, guarantees
> low overhead, low latency, and consistent performance.
> 
> If used as default scheduler, at Xen boot, it is
> recommended to limit the number of Dom0 vCPUs (e.g., with
> 'dom0_max_vcpus=x'). Otherwise, all the pCPUs will have
> one Dom0's vCPU assigned, and there won't be room for
> running efficiently (if at all) any guest.
> 
> Target use cases are embedded and HPC, but it may well
> be interesting also in circumnstances.
> 
> Kconfig and documentation are update accordingly.
> 
> While there, also document the availability of sched=rtds
> as boot parameter, which apparently had been forgotten.
> 
> Signed-off-by: Dario Faggioli 
> ---
> Cc: George Dunlap 
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> Cc: Jonathan Davies 
> Cc: Marcus Granado 
> ---
>  docs/misc/xen-command-line.markdown |2 
>  xen/common/Kconfig  |   11 
>  xen/common/Makefile |1 
>  xen/common/sched_null.c |  816 
> +++
>  xen/common/schedule.c   |2 
>  xen/include/public/domctl.h |1 
>  6 files changed, 832 insertions(+), 1 deletion(-)
>  create mode 100644 xen/common/sched_null.c
> 
> diff --git a/docs/misc/xen-command-line.markdown 
> b/docs/misc/xen-command-line.markdown
> index 4daf5b5..ad6a5ca 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1434,7 +1434,7 @@ Map the HPET page as read only in Dom0. If disabled the 
> page will be mapped
>  with read and write permissions.
>  
>  ### sched
> -> `= credit | credit2 | arinc653`
> +> `= credit | credit2 | arinc653 | rtds | null`
>  
>  > Default: `sched=credit`
>  
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index f2ecbc4..518520e 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -187,6 +187,14 @@ config SCHED_ARINC653
> The ARINC653 scheduler is a hard real-time scheduler for single
> cores, targeted for avionics, drones, and medical devices.
>  
> +config SCHED_NULL
> + bool "Null scheduler support (EXPERIMENTAL)"
> + default y
> + ---help---
> +   The null scheduler is a static, zero overhead scheduler,
> +   for when there always are less vCPUs than pCPUs, typically
> +   in embedded or HPC scenarios.
> +
>  choice
>   prompt "Default Scheduler?"
>   default SCHED_CREDIT_DEFAULT
> @@ -199,6 +207,8 @@ choice
>   bool "RT Scheduler" if SCHED_RTDS
>   config SCHED_ARINC653_DEFAULT
>   bool "ARINC653 Scheduler" if SCHED_ARINC653
> + config SCHED_NULL_DEFAULT
> + bool "Null Scheduler" if SCHED_NULL
>  endchoice
>  
>  config SCHED_DEFAULT
> @@ -207,6 +217,7 @@ config SCHED_DEFAULT
>   default "credit2" if SCHED_CREDIT2_DEFAULT
>   default "rtds" if SCHED_RTDS_DEFAULT
>   default "arinc653" if SCHED_ARINC653_DEFAULT
> + default "null" if SCHED_NULL_DEFAULT
>   default "credit"
>  
>  endmenu
> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index 0fed30b..26c5a64 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -40,6 +40,7 @@ obj-$(CONFIG_SCHED_ARINC653) += sched_arinc653.o
>  obj-$(CONFIG_SCHED_CREDIT) += sched_credit.o
>  obj-$(CONFIG_SCHED_CREDIT2) += sched_credit2.o
>  obj-$(CONFIG_SCHED_RTDS) += sched_rt.o
> +obj-$(CONFIG_SCHED_NULL) += sched_null.o
>  obj-y += schedule.o
>  obj-y += shutdown.o
>  obj-y += softirq.o
> diff --git a/xen/common/sched_null.c b/xen/common/sched_null.c
> new file mode 100644
> index 000..6a13308
> --- /dev/null
> +++ b/xen/common/sched_null.c
> @@ -0,0 +1,816 @@
> +/*
> + * xen/common/sched_null.c
> + *
> + *  Copyright (c) 2017, Dario Faggioli, Citrix Ltd
> + *
> + * 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 

Re: [Xen-devel] [PATCH 3/3] tools: sched: add support for 'null' scheduler

[Stefano Stabellini]

On Fri, 17 Mar 2017, Dario Faggioli wrote:
> It being very very basic, also means this scheduler does
> not need much support at the tools level (for now).
> 
> Basically, just the definition of the symbol of the
> scheduler itself and a couple of stubs.
> 
> Signed-off-by: Dario Faggioli 

Acked-by: Stefano Stabellini 


> ---
> Cc: Wei Liu 
> Cc: Ian Jackson 
> Cc: George Dunlap 
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> ---
>  tools/libxl/libxl.h |6 ++
>  tools/libxl/libxl_sched.c   |   24 
>  tools/libxl/libxl_types.idl |1 +
>  3 files changed, 31 insertions(+)
> 
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 4c60e8f..5adac2d 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -210,6 +210,12 @@
>  #define LIBXL_HAVE_SCHED_RTDS 1
>  
>  /*
> + * LIBXL_HAVE_SCHED_NULL indicates that the 'null' static scheduler
> + * is available.
> + */
> +#define LIBXL_HAVE_SCHED_NULL 1
> +
> +/*
>   * libxl_domain_build_info has u.hvm.viridian_enable and _disable bitmaps
>   * of the specified width.
>   */
> diff --git a/tools/libxl/libxl_sched.c b/tools/libxl/libxl_sched.c
> index 84d3837..d44fbe1 100644
> --- a/tools/libxl/libxl_sched.c
> +++ b/tools/libxl/libxl_sched.c
> @@ -178,6 +178,20 @@ static int sched_arinc653_domain_set(libxl__gc *gc, 
> uint32_t domid,
>  return 0;
>  }
>  
> +static int sched_null_domain_set(libxl__gc *gc, uint32_t domid,
> + const libxl_domain_sched_params *scinfo)
> +{
> +/* The null scheduler doesn't take any domain-specific parameters. */
> +return 0;
> +}
> +
> +static int sched_null_domain_get(libxl__gc *gc, uint32_t domid,
> +   libxl_domain_sched_params *scinfo)
> +{
> +/* The null scheduler doesn't have any domain-specific parameters. */
> +return ERROR_INVAL;
> +}
> +
>  static int sched_credit_domain_get(libxl__gc *gc, uint32_t domid,
> libxl_domain_sched_params *scinfo)
>  {
> @@ -730,6 +744,9 @@ int libxl_domain_sched_params_set(libxl_ctx *ctx, 
> uint32_t domid,
>  case LIBXL_SCHEDULER_RTDS:
>  ret=sched_rtds_domain_set(gc, domid, scinfo);
>  break;
> +case LIBXL_SCHEDULER_NULL:
> +ret=sched_null_domain_set(gc, domid, scinfo);
> +break;
>  default:
>  LOGD(ERROR, domid, "Unknown scheduler");
>  ret=ERROR_INVAL;
> @@ -758,6 +775,7 @@ int libxl_vcpu_sched_params_set(libxl_ctx *ctx, uint32_t 
> domid,
>  case LIBXL_SCHEDULER_CREDIT:
>  case LIBXL_SCHEDULER_CREDIT2:
>  case LIBXL_SCHEDULER_ARINC653:
> +case LIBXL_SCHEDULER_NULL:
>  LOGD(ERROR, domid, "per-VCPU parameter setting not supported for 
> this scheduler");
>  rc = ERROR_INVAL;
>  break;
> @@ -792,6 +810,7 @@ int libxl_vcpu_sched_params_set_all(libxl_ctx *ctx, 
> uint32_t domid,
>  case LIBXL_SCHEDULER_CREDIT:
>  case LIBXL_SCHEDULER_CREDIT2:
>  case LIBXL_SCHEDULER_ARINC653:
> +case LIBXL_SCHEDULER_NULL:
>  LOGD(ERROR, domid, "per-VCPU parameter setting not supported for 
> this scheduler");
>  rc = ERROR_INVAL;
>  break;
> @@ -832,6 +851,9 @@ int libxl_domain_sched_params_get(libxl_ctx *ctx, 
> uint32_t domid,
>  case LIBXL_SCHEDULER_RTDS:
>  ret=sched_rtds_domain_get(gc, domid, scinfo);
>  break;
> +case LIBXL_SCHEDULER_NULL:
> +ret=sched_null_domain_get(gc, domid, scinfo);
> +break;
>  default:
>  LOGD(ERROR, domid, "Unknown scheduler");
>  ret=ERROR_INVAL;
> @@ -858,6 +880,7 @@ int libxl_vcpu_sched_params_get(libxl_ctx *ctx, uint32_t 
> domid,
>  case LIBXL_SCHEDULER_CREDIT:
>  case LIBXL_SCHEDULER_CREDIT2:
>  case LIBXL_SCHEDULER_ARINC653:
> +case LIBXL_SCHEDULER_NULL:
>  LOGD(ERROR, domid, "per-VCPU parameter getting not supported for 
> this scheduler");
>  rc = ERROR_INVAL;
>  break;
> @@ -890,6 +913,7 @@ int libxl_vcpu_sched_params_get_all(libxl_ctx *ctx, 
> uint32_t domid,
>  case LIBXL_SCHEDULER_CREDIT:
>  case LIBXL_SCHEDULER_CREDIT2:
>  case LIBXL_SCHEDULER_ARINC653:
> +case LIBXL_SCHEDULER_NULL:
>  LOGD(ERROR, domid, "per-VCPU parameter getting not supported for 
> this scheduler");
>  rc = ERROR_INVAL;
>  break;
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 6d28dea..ce733c4 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -191,6 +191,7 @@ libxl_scheduler = Enumeration("scheduler", [
>  (6, "credit2"),
>  (7, "arinc653"),
>  (8, "rtds"),
> +(9, "null"),
>  ])
>  
>  # Consistent with SHUTDOWN_* in sched.h (apart from UNKNOWN)
> 

___

Re: [Xen-devel] [PATCH 0/3] The 'null' Scheduler

[Stefano Stabellini]

On Fri, 17 Mar 2017, Dario Faggioli wrote:
> Hello,
> 
> This patch series implements what I call the 'null' scheduler.
> 
> It's a very simple, very static scheduling posicy that always schedules the 
> same vCPU(s) on the same pCPU(s). That's it.
> 
> If there are less vCPUs than pCPUs, some of the pCPUs are _always_ idle. If 
> there are more, some vCPUs _never_ run.
> That is not entirely true, as there is some logic to make sure that waiting 
> to run vCPUs are executed, for instance, on a new pCPU that enters the 
> cpupool, and things like that.
> 
> The demand for this cames from Xen on ARM people and the embedded world in 
> general (Hey, Stefano! :-P), where it is not uncommon to have super static 
> systems that perceives an advanced general purpose scheduler just as pure 
> overhead.

Yep, this scheduler is exactly what I want, thanks! :-)


> As a matter of fact, this may turn out useful in less embedded scenario, like 
> High Performace Computing (where, again, scheduling is, often, unnecessary 
> overhead), but even some of our much more classic Xen use case (like 
> consolidation, Cc-ing Jonathan and Marcus who said they were interested in 
> it).
> 
> The scheduler is really simple, and especially the hot paths --i.e., sleep, 
> wakeup and schedule-- are super lean and quick, in 99% of the cases. All the 
> slightly more complicated logic for dealing with pCPUs coming and going from 
> a cpupool that uses this scheduler resides in functions that handle 
> insertion, removal and migration of vCPUs, which are only called when such 
> configuration changes happens (so, typically, "offline", in most of the 
> embedded usecases).
> 
> I implemented support for hard affinity in order to provide at least a 
> rudimental interface for interacting with the scheduler and affect the 
> placement (it's called assignment within the code) of vCPUs on pCPUs.
> 
> I've tested the scheduler both inside a cpupool (using both Credit1 and 
> Credit2 as boot schedulers) and as default, choosing it at boot and using it 
> for Dom0 and a few other domains. In the latter case, you probably want to 
> limit the number of Dom0's vCPUs too, or there will be very few to experiment 
> with! :-P
> 
> I haven't done any performance or overhead measurements so far, but I will 
> soon enough.
> 
> I also consider this to be experimental, and I'll also write a feature 
> document ASAP.
> 
> Thanks and Regards,
> Dario
> ---
> Dario Faggioli (3):
>   xen: sched: introduce the 'null' semi-static scheduler
>   xen: sched_null: support for hard affinity
>   tools: sched: add support for 'null' scheduler
> 
>  docs/misc/xen-command-line.markdown |2 
>  tools/libxl/libxl.h |6 
>  tools/libxl/libxl_sched.c   |   24 +
>  tools/libxl/libxl_types.idl |1 
>  xen/common/Kconfig  |   11 
>  xen/common/Makefile |1 
>  xen/common/sched_null.c |  837 
> +++
>  xen/common/schedule.c   |2 
>  xen/include/public/domctl.h |1 
>  9 files changed, 884 insertions(+), 1 deletion(-)
>  create mode 100644 xen/common/sched_null.c
> --
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)
> 

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

Re: [Xen-devel] [PATCH v6] xen: Allow a default compiled-in command line using Kconfig

[Stefano Stabellini]

On Tue, 21 Mar 2017, Zhongze Liu wrote:
> Added 2 new config entries in common/Kconfig:
> CMDLINE and CMDLINE_OVERRIDE
> Modifed common/kernel.c:cmdline_parse().
> 
> The 2 new entries enable an embedded command line to be compiled
> in the hypervisor. CMDLINE depends on EXPERT = "y", and CMDLINE_OVERRIDE
> depends on CMDLINE != "".
> 
> If CMDLINE is set, it will be parsed prior to the bootloader command line.
> This order of parsing implies that if any non-cumulative options are set in
> both CMDLINE and the bootloader command line, only the ones in the latter will
> take effect. Further more, if CMDLINE_OVERRIDE is set to y, the whole
> bootloader command line will be ignored, which will be useful to work around
> broken bootloaders. A wrapper to the original common/kernel.c:cmdline_parse()
> was introduced to complete this task.
> 
> This allows downstreams to set their defaults without modifying the source 
> code
> all over the place. Also probably useful for the embedded space.
> (See Also: https://xenproject.atlassian.net/browse/XEN-41)
> 
> Signed-off-by: Zhongze Liu 

Reviewed-by: Stefano Stabellini 


> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> ---
> Changed since v5:
>   * remove the redundent EXPERT = "y" dependency from config CMDLINE_OVERRIDE
>   * make opt_builtin_cmdline[] static and __initconst
>   * changed the name do_cmdline_parse() to _cmdline_parse()
>   * do a NULL check before copying cmdline to saved_cmdline
>   * check the first byte of opt_builtin_cmdline to determine whether it's
> empty or not.
> ---
>  xen/common/Kconfig  | 22 ++
>  xen/common/kernel.c | 30 --
>  2 files changed, 46 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index f2ecbc43d6..e1c90b739a 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -237,4 +237,26 @@ config FAST_SYMBOL_LOOKUP
> The only user of this is Live patching.
>  
> If unsure, say Y.
> +
> +config CMDLINE
> + string "Built-in hypervisor command string"
> + default ""
> + depends on EXPERT = "y"
> + ---help---
> +   Enter arguments here that should be compiled into the hypervisor
> +   image and used at boot time. When the system boots, this string
> +   will be parsed prior to the bootloader command line. So if a
> +   non-cumulative option is set both in this string and in the
> +   bootloader command line, only the latter one will take effect.
> +
> +config CMDLINE_OVERRIDE
> + bool "Built-in command line overrides bootloader arguments"
> + default n
> + depends on CMDLINE != ""
> + ---help---
> +   Set this option to 'Y' to have the hypervisor ignore the bootloader
> +   command line, and use ONLY the built-in command line.
> +
> +   This is used to work around broken bootloaders. This should
> +   be set to 'N' under normal conditions.
>  endmenu
> diff --git a/xen/common/kernel.c b/xen/common/kernel.c
> index 4b87c60845..64920e8304 100644
> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -23,6 +23,7 @@
>  enum system_state system_state = SYS_STATE_early_boot;
>  
>  xen_commandline_t saved_cmdline;
> +static const char __initconst opt_builtin_cmdline[] = CONFIG_CMDLINE;
>  
>  static void __init assign_integer_param(
>  const struct kernel_param *param, uint64_t val)
> @@ -46,18 +47,13 @@ static void __init assign_integer_param(
>  }
>  }
>  
> -void __init cmdline_parse(const char *cmdline)
> +static void __init _cmdline_parse(const char *cmdline)
>  {
>  char opt[100], *optval, *optkey, *q;
>  const char *p = cmdline;
>  const struct kernel_param *param;
>  int bool_assert;
>  
> -if ( cmdline == NULL )
> -return;
> -
> -safe_strcpy(saved_cmdline, cmdline);
> -
>  for ( ; ; )
>  {
>  /* Skip whitespace. */
> @@ -147,6 +143,28 @@ void __init cmdline_parse(const char *cmdline)
>  }
>  }
>  
> +/**
> + *cmdline_parse -- parses the xen command line.
> + * If CONFIG_CMDLINE is set, it would be parsed prior to @cmdline.
> + * But if CONFIG_CMDLINE_OVERRIDE is set to y, @cmdline will be ignored.
> + */
> +void __init cmdline_parse(const char *cmdline)
> +{
> +if ( opt_builtin_cmdline[0] )
> +{
> +printk("Built-in command line: %s\n", opt_builtin_cmdline);
> +_cmdline_parse(opt_builtin_cmdline);
> +}
> +
> +#ifndef CONFIG_CMDLINE_OVERRIDE
> +if ( cmdline == NULL )
> +return;
> +
> +safe_strcpy(saved_cmdline, cmdline);
> +_cmdline_parse(cmdline);
> +#endif
> +}
> +
>  int __init 

Re: [Xen-devel] [PATCH 0/2] xen/arm32: Use alternative to skip the check of pending serrors

[Stefano Stabellini]

On Thu, 16 Mar 2017, Julien Grall wrote:
> Hi,
> 
> On 03/16/2017 09:53 AM, Wei Chen wrote:
> > We have provided an option to administrator to determine how to
> > handle the SErrors. In order to avoid add overhead to check the
> > option at every trap, we want to use the alternative to skip
> > this check.
> > 
> > In this series:
> > 1. Introduce alternative patching support for ARM32.
> > 2. Update the ARM32 SErrors handle code to use the alternative.
> 
> Stefano, this patch is relying on the bug fix "xen/arm: Register re-mapped Xen
> area as a temporary virtual region"
> <1489483637-27456-1-git-send-email-wei.c...@arm.com>. We should avoid to
> commit it before hand as it will break ARM platform.

Thanks for the head's up.

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

Re: [Xen-devel] [PATCH 18/18] xen/arm: Handle guest external abort as guest SError

[Stefano Stabellini]

On Mon, 13 Mar 2017, Wei Chen wrote:
> The guest generated external data/instruction aborts can be treated
> as guest SErrors. We already have a handler to handle the SErrors,
> so we can reuse this handler to handle guest external aborts.
> 
> Signed-off-by: Wei Chen 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/traps.c | 14 ++
>  1 file changed, 6 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 3b84e80..24511e5 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2558,12 +2558,12 @@ static void do_trap_instr_abort_guest(struct 
> cpu_user_regs *regs,
>  
>  /*
>   * If this bit has been set, it means that this instruction abort is 
> caused
> - * by a guest external abort. Currently we crash the guest to protect the
> - * hypervisor. In future one can better handle this by injecting a 
> virtual
> - * abort to the guest.
> + * by a guest external abort. We can handle this instruction abort as 
> guest
> + * SError.
>   */
>  if ( hsr.iabt.eat )
> -domain_crash_synchronous();
> +return __do_trap_serror(regs, true);
> +
>  
>  if ( hpfar_is_valid(hsr.iabt.s1ptw, fsc) )
>  gpa = get_faulting_ipa(gva);
> @@ -2661,12 +2661,10 @@ static void do_trap_data_abort_guest(struct 
> cpu_user_regs *regs,
>  
>  /*
>   * If this bit has been set, it means that this data abort is caused
> - * by a guest external abort. Currently we crash the guest to protect the
> - * hypervisor. In future one can better handle this by injecting a 
> virtual
> - * abort to the guest.
> + * by a guest external abort. We treat this data abort as guest SError.
>   */
>  if ( dabt.eat )
> -domain_crash_synchronous();
> +return __do_trap_serror(regs, true);
>  
>  info.dabt = dabt;
>  #ifdef CONFIG_ARM_32
> -- 
> 2.7.4
> 
> 
> ___
> 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 17/18] xen/arm: Prevent slipping hypervisor SError to guest

[Stefano Stabellini]

On Mon, 13 Mar 2017, Wei Chen wrote:
> If there is a pending SError while we're returning from trap. If the
> SError handle option is "DIVERSE", we have to prevent slipping this
> hypervisor SError to guest. So we have to use the dsb/isb to guarantee
> that the pending hypervisor SError would be caught in hypervisor before
> return to guest.
> 
> Signed-off-by: Wei Chen 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/traps.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index b8c8389..3b84e80 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2953,6 +2953,16 @@ asmlinkage void leave_hypervisor_tail(void)
>  local_irq_disable();
>  if (!softirq_pending(smp_processor_id())) {
>  gic_inject();
> +
> +/*
> + * If the SErrors handle option is "DIVERSE", we have to prevent
> + * slipping the hypervisor SError to guest. So before returning
> + * from trap, we use the synchronize_serror to guarantee that the
> + * pending SError would be caught in hypervisor.
> + */
> +if ( serrors_op == SERRORS_DIVERSE )
> +synchronize_serror();
> +
>  WRITE_SYSREG(current->arch.hcr_el2, HCR_EL2);
>  return;
>  }
> -- 
> 2.7.4
> 
> 
> ___
> 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 16/18] xen/arm: Isolate the SError between the context switch of 2 vCPUs

[Stefano Stabellini]

On Mon, 13 Mar 2017, Wei Chen wrote:
> If there is a pending SError while we are doing context switch, if the
> SError handle option is "FORWARD", We have to guranatee this serror to
> be caught by current vCPU, otherwise it will be caught by next vCPU and
> be forwarded to this wrong vCPU.
> 
> We don't want to export serror_op accessing to other source files and
> use serror_op every place, so we add a helper to synchronize SError for
> context switching. The synchronize_serror has been used in this helper,
> so the "#if 0" can be removed.
> 
> Signed-off-by: Wei Chen 
> ---
>  xen/arch/arm/domain.c   |  2 ++
>  xen/arch/arm/traps.c| 14 --
>  xen/include/asm-arm/processor.h |  2 ++
>  3 files changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 69c2854..a547fcd 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -312,6 +312,8 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
>  
>  local_irq_disable();
>  
> +prevent_forward_serror_to_next_vcpu();
> +
>  set_current(next);
>  
>  prev = __context_switch(prev, next);
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index ee7865b..b8c8389 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2899,7 +2899,6 @@ asmlinkage void do_trap_hypervisor(struct cpu_user_regs 
> *regs)
>  }
>  }
>  
> -#if 0
>  static void synchronize_serror(void)
>  {
>  /* Synchronize against in-flight ld/st. */
> @@ -2908,7 +2907,18 @@ static void synchronize_serror(void)
>  /* A single instruction exception window */
>  isb();
>  }
> -#endif
> +
> +/*
> + * If the SErrors option is "FORWARD", we have to prevent forwarding
> + * serror to wrong vCPU. So before context switch, we have to use the
> + * synchronize_serror to guarantee that the pending serror would be
> + * caught by current vCPU.
> + */
> +void prevent_forward_serror_to_next_vcpu(void)
> +{
> +if ( serrors_op == SERRORS_FORWARD )
> +synchronize_serror();
> +}

I dislike introducing so many 2 lines functions. I would get rid of
prevent_forward_serror_to_next_vcpu and just add

   if ( serrors_op == SERRORS_FORWARD )
   synchronize_serror();

to context_switch, and I would make synchronize_serror a static inline.


>  asmlinkage void do_trap_hyp_serror(struct cpu_user_regs *regs)
>  {
> diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
> index afad78c..3b43234 100644
> --- a/xen/include/asm-arm/processor.h
> +++ b/xen/include/asm-arm/processor.h
> @@ -711,6 +711,8 @@ void do_trap_hyp_serror(struct cpu_user_regs *regs);
>  
>  void do_trap_guest_serror(struct cpu_user_regs *regs);
>  
> +void prevent_forward_serror_to_next_vcpu(void);
> +
>  /* Functions for pending virtual abort checking window. */
>  void abort_guest_exit_start(void);
>  void abort_guest_exit_end(void);
> -- 
> 2.7.4
> 
> 
> ___
> 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 15/18] xen/arm: Introduce a helper to synchronize SError

[Stefano Stabellini]

On Mon, 20 Mar 2017, Stefano Stabellini wrote:
> On Mon, 13 Mar 2017, Wei Chen wrote:
> > We may have to isolate the SError between the context switch of
> > 2 vCPUs or may have to prevent slipping hypervisor SError to guest.
> 
> I thought the problem is not the risk of slipping hypervisor SErrors to
> guest, but the risk of slipping previous guest SErrors to the next
> guest. Is that right?

I can see from the following patches that both situations are a risk.
Although the patch could benefit from a better commit description:

Reviewed-by: Stefano Stabellini 



> > So we need a helper to synchronize SError before context switching
> > or returning to guest.
> > 
> > This function will be used by the later patches in this series, we
> > use "#if 0" to disable it temporarily to remove compiler warnning.
> > 
> > Signed-off-by: Wei Chen 
> > ---
> >  xen/arch/arm/traps.c | 11 +++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> > index 44a0281..ee7865b 100644
> > --- a/xen/arch/arm/traps.c
> > +++ b/xen/arch/arm/traps.c
> > @@ -2899,6 +2899,17 @@ asmlinkage void do_trap_hypervisor(struct 
> > cpu_user_regs *regs)
> >  }
> >  }
> >  
> > +#if 0
> > +static void synchronize_serror(void)
> > +{
> > +/* Synchronize against in-flight ld/st. */
> > +dsb(sy);
> > +
> > +/* A single instruction exception window */
> > +isb();
> > +}
> > +#endif
> > +
> >  asmlinkage void do_trap_hyp_serror(struct cpu_user_regs *regs)
> >  {
> >  enter_hypervisor_head(regs);
> > -- 
> > 2.7.4
> > 
> > 
> > ___
> > 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 15/18] xen/arm: Introduce a helper to synchronize SError

[Stefano Stabellini]

On Mon, 13 Mar 2017, Wei Chen wrote:
> We may have to isolate the SError between the context switch of
> 2 vCPUs or may have to prevent slipping hypervisor SError to guest.

I thought the problem is not the risk of slipping hypervisor SErrors to
guest, but the risk of slipping previous guest SErrors to the next
guest. Is that right?


> So we need a helper to synchronize SError before context switching
> or returning to guest.
> 
> This function will be used by the later patches in this series, we
> use "#if 0" to disable it temporarily to remove compiler warnning.
> 
> Signed-off-by: Wei Chen 
> ---
>  xen/arch/arm/traps.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 44a0281..ee7865b 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2899,6 +2899,17 @@ asmlinkage void do_trap_hypervisor(struct 
> cpu_user_regs *regs)
>  }
>  }
>  
> +#if 0
> +static void synchronize_serror(void)
> +{
> +/* Synchronize against in-flight ld/st. */
> +dsb(sy);
> +
> +/* A single instruction exception window */
> +isb();
> +}
> +#endif
> +
>  asmlinkage void do_trap_hyp_serror(struct cpu_user_regs *regs)
>  {
>  enter_hypervisor_head(regs);
> -- 
> 2.7.4
> 
> 
> ___
> 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 14/18] xen/arm: Unmask the Abort/SError bit in the exception entries

[Stefano Stabellini]

On Mon, 13 Mar 2017, Wei Chen wrote:
> Currently, we masked the Abort/SError bit in Xen exception entries.
> So Xen could not capture any Abort/SError while it's running.
> Now, Xen has the ability to handle the Abort/SError, we should unmask
> the Abort/SError bit by default to let Xen capture Abort/SError while
> it's running.
> 
> But in order to avoid receiving nested asynchronous abort, we don't
> unmask Abort/SError bit in hyp_error and trap_data_abort.
> 
> Signed-off-by: Wei Chen 
> ---
> We haven't done this before, so I don't know how can this change
> will affect the Xen. If the IRQ and Abort take place at the same
> time, how can we handle them?

If the abort is for Xen, the hypervisor will crash and that's the end of
it. If the abort is for the guest, Xen will inject it into the VM, then
it will return from handling the abort, going back to handling the IRQ
as before. Isn't that right?


> If an abort is taking place while we're handling the IRQ, the program
> jump to abort exception, and then enable the IRQ. In this case, what
> will happen? So I think I need more discussions from community.

Do you know of an example scenario where Xen could have a problem with
this?


> ---
>  xen/arch/arm/arm32/entry.S | 15 ++-
>  xen/arch/arm/arm64/entry.S | 13 -
>  2 files changed, 22 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/arm/arm32/entry.S b/xen/arch/arm/arm32/entry.S
> index 79929ca..4d46239 100644
> --- a/xen/arch/arm/arm32/entry.S
> +++ b/xen/arch/arm/arm32/entry.S
> @@ -125,6 +125,7 @@ abort_guest_exit_end:
>  trap_##trap:\
>  SAVE_ALL;   \
>  cpsie i;/* local_irq_enable */  \
> +cpsie a;/* asynchronous abort enable */ \
>  adr lr, return_from_trap;   \
>  mov r0, sp; \
>  mov r11, sp;\
> @@ -135,6 +136,18 @@ trap_##trap: 
>\
>  ALIGN;  \
>  trap_##trap:\
>  SAVE_ALL;   \
> +cpsie a;/* asynchronous abort enable */ \
> +adr lr, return_from_trap;   \
> +mov r0, sp; \
> +mov r11, sp;\
> +bic sp, #7; /* Align the stack pointer (noop on guest trap) */  \
> +b do_trap_##trap
> +
> +#define DEFINE_TRAP_ENTRY_NOABORT(trap) \
> +ALIGN;  \
> +trap_##trap:\
> +SAVE_ALL;   \
> +cpsie i;/* local_irq_enable */  \
>  adr lr, return_from_trap;   \
>  mov r0, sp; \
>  mov r11, sp;\
> @@ -155,10 +168,10 @@ GLOBAL(hyp_traps_vector)
>  DEFINE_TRAP_ENTRY(undefined_instruction)
>  DEFINE_TRAP_ENTRY(supervisor_call)
>  DEFINE_TRAP_ENTRY(prefetch_abort)
> -DEFINE_TRAP_ENTRY(data_abort)
>  DEFINE_TRAP_ENTRY(hypervisor)
>  DEFINE_TRAP_ENTRY_NOIRQ(irq)
>  DEFINE_TRAP_ENTRY_NOIRQ(fiq)
> +DEFINE_TRAP_ENTRY_NOABORT(data_abort)
>  
>  return_from_trap:
>  mov sp, r11
> diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
> index 8d5a890..0401a41 100644
> --- a/xen/arch/arm/arm64/entry.S
> +++ b/xen/arch/arm/arm64/entry.S
> @@ -187,13 +187,14 @@ hyp_error:
>  /* Traps taken in Current EL with SP_ELx */
>  hyp_sync:
>  entry   hyp=1
> -msr daifclr, #2
> +msr daifclr, #6
>  mov x0, sp
>  bl  do_trap_hypervisor
>  exithyp=1
>  
>  hyp_irq:
>  entry   hyp=1
> +msr daifclr, #4
>  mov x0, sp
>  bl  do_trap_irq
>  exithyp=1
> @@ -208,7 +209,7 @@ guest_sync:
>  ALTERNATIVE("bl check_pending_vserror; cbnz x0, 1f",
>  "nop; nop",
>  SKIP_CHECK_PENDING_VSERROR)
> -msr daifclr, #2
> +msr daifclr, #6
>  mov x0, sp
>  bl  do_trap_hypervisor
>  1:
> @@ -224,6 +225,7 @@ guest_irq:
>  ALTERNATIVE("bl check_pending_vserror; cbnz x0, 1f",
>  "nop; nop",
>  SKIP_CHECK_PENDING_VSERROR)
> +

Re: [Xen-devel] [PATCH V2] common/mem_access: merged mem_access setting interfaces

[Tamas K Lengyel]

On Mon, Mar 20, 2017 at 2:20 PM, Razvan Cojocaru 
wrote:

> On 03/20/2017 06:54 PM, Jan Beulich wrote:
>  On 20.03.17 at 17:48,  wrote:
> >> On 03/20/2017 06:40 PM, Jan Beulich wrote:
> >> On 20.03.17 at 17:16,  wrote:
>  On 03/20/2017 06:14 PM, Razvan Cojocaru wrote:
> > In any case, back when I've added xc_set_mem_access_multi() I've also
> > modified struct xen_mem_access_op in the same manner:
> >
> >
>  http://xenbits.xenproject.org/gitweb/?p=xen.git;a=
> commitdiff;h=1ef5056bd6274e
>  cbe065387b6cf45657d6d700cd
> 
>  Oh, nevermind, I think you're referring to the fact that I had back
> then
>  added members to the end of the structure, and so the old layout had
>  remained compatible. Point taken.
> >>>
> >>> Not just that - there you've also introduced a new sub-op.
> >>
> >> Yes, but by modifying the structure for use with
> >> XENMEM_access_op_set_access_multi, it's now also changed for, e.g.,
> >> XENMEM_access_op_set_access - since it's common to them. Other than the
> >> place where the new data has been added, I believe that the same
> >> critique would apply to the old patch, unless I'm misunderstanding
> >> something.
> >
> > Indeed, strictly speaking that change wasn't really okay either,
> > as someone passing the smaller structure near the end of a page
> > might get -EFAULT back. So we're trying to do better this time ...
>
> Two question remain to be answered then:
>
> 1. How should this proceed? Andrew's comment, taken together with Tamas'
> last patch ("altp2m: Allow specifying external-only use-case") would
> seem to imply that the best way forward is to revert to the previous
> patch which duplicates the xc_set_mem_access_multi()'s mem-op with
> xc_altp2m_set_mem_access_multi()'s HVMOP (with the compat code to be
> worked out). Is there a consensus on this?
>
> 2. What is the best way to avoid incompatibilities such as the one
> mentioned? For example, in this case, should I have deprecated
> XENMEM_access_op_set_access and XENMEM_access_op_set_access_multi and
> added XENMEM_access_op_set_access2 and XENMEM_access_op_set_access2? Or
> do you have something different in mind?
>

IMHO deprecating the old memops shouldn't be needed. The code on the
hypervisor side all lands in the same spot, so keeping both memops (and the
hvmop) in place should add no extra work from a maintenance perspective.

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

[Xen-devel] [qemu-mainline test] 106787: regressions - FAIL

[osstest service owner]

-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 bedf13ecab38bcd479e9db6994ebc3b2c5c7a3ae
Merge: ebedf0f 7bc4f08
Author: Peter Maydell <peter.mayd...@linaro.org>
Date:   Mon Mar 20 10:05:45 2017 +

Merge remote-tracking branch 'remotes/kraxel/tags/pull-fixes-20170320-1' 
into staging

fixes for 2.9: vnc, cirrus, tcg display updates.

# gpg: Signature made Mon 20 Mar 2017 08:52:34 GMT
# gpg:using RSA key 0x4CB6D8EED3E87138
# gpg: Good signature from "Gerd Hoffmann (work) <kra...@redhat.com>"
# gpg: aka "Gerd Hoffmann <g...@kraxel.org>"
# gpg: aka "Gerd Hoffmann (private) <kra...@gmail.com>"
# Primary key fingerprint: A032 8CFF B93A 17A7 9901  FE7D 4CB6 D8EE D3E8 
7138

* remotes/kraxel/tags/pull-fixes-20170320-1:
  vnc: fix a qio-channel leak
  cirrus: fix off-by-one in cirrus_bitblt_rop_bkwd_transp_*_16
  ui/console: ensure graphic updates don't race with TCG vCPUs

Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>

commit 7bc4f0846f5e15dad5a54490290241243b5a4416
Author: Marc-André Lureau <marcandre.lur...@redhat.com>
Date:   Fri Mar 17 13:28:02 2017 +0400

vnc: fix a qio-channel leak

Spotted by ASAN.

Signed-off-by: Marc-André Lureau <marcandre.lur...@redhat.com>
Reviewed-by: Daniel P. Berrange <berra...@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4...@amsat.org>
Message-id: 20170317092802.17973-1-marcandre.lur...@redhat.com
Signed-off-by: Gerd Hoffmann <kra...@redhat.com>

commit f019722cbbb45aea153294fc8921fcc96a4d3fa2
Author: Gerd Hoffmann <kra...@redhat.com>
Date:   Fri Mar 17 08:21:36 2017 +0100

cirrus: fix off-by-one in cirrus_bitblt_rop_bkwd_transp_*_16

The switch from pointers to addresses (commit
026aeffcb4752054830ba203020ed6eb05bcaba8 and
ffaf857778286ca54e3804432a2369a279e73aa7) added
a off-by-one bug to 16bit backward blits.  Fix.

Reported-by: 李强 <liqiang...@360.cn>
Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
Reviewed-by: Li Qiang <liqiang...@360.cn>
Message-id: 1489735296-19047-1-git-send-email-kra...@redhat.com

commit 8bb93c6f99a42c2e0943bc904b283cd622d302c5
Author: Alex Bennée <alex.ben...@linaro.org>
Date:   Wed Mar 15 14:48:25 2017 +

ui/console: ensure graphic updates don't race with TCG vCPUs

Commit 8d04fb55..

  tcg: drop global lock during TCG code execution

..broke the assumption that updates to the GUI couldn't happen at the
same time as TCG vCPUs where running. As a result the TCG vCPU could
still be updating a directly mapped frame-buffer while the display
side was updating. This would cause artefacts to appear when the
update code assumed that memory block hadn't changed.

The simplest solution is to ensure the two things can't happen at the
same time like the old BQL locking scheme. Here we use the solution
introduced for MTTCG and schedule the update as async_safe_work when
we know no vCPUs can be running.

Reported-by: Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk>
Signed-off-by: Alex Bennée <alex.ben...@linaro.org>
Message-id: 20170315144825.3108-1-alex.ben...@linaro.org
Cc: BALATON Zoltan <bala...@eik.bme.hu>
Cc: Gerd Hoffmann <kra...@redhat.com>
Cc: Paolo Bonzini <pbonz...@redhat.com>
Signed-off-by: Alex Bennée <alex.ben...@linaro.org>

[ kraxel: updated comment clarifying the display adapters are buggy
  and this is a temporary workaround ]

Signed-off-by: Gerd Hoffmann <kra...@redhat.com>

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

[Xen-devel] [xen-unstable-smoke test] 106791: tolerable trouble: broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   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  69f4633817c38655cd27aa62c3cbfc02f6627234
baseline version:
 xen  2588a12732e71e6754b53689b981ec6a37b39983

Last test of basis   106789  2017-03-20 16:02:05 Z0 days
Testing same since   106791  2017-03-20 19:01:48 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Haozhong Zhang 
  Jan Beulich 
  Paul Durrant 
  Suravee Suthikulpanit 

jobs:
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 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=69f4633817c38655cd27aa62c3cbfc02f6627234
+ . ./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 
69f4633817c38655cd27aa62c3cbfc02f6627234
+ branch=xen-unstable-smoke
+ revision=69f4633817c38655cd27aa62c3cbfc02f6627234
+ . ./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
+ '[' x69f4633817c38655cd27aa62c3cbfc02f6627234 = 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
++ : 

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 38b15ebe4fd5888493131d30fc31833a5e9a7d36
baseline version:
 ovmf 76874be3d411bf8daac051718e20932e0bf97d70

Last test of basis   106785  2017-03-20 10:16:23 Z0 days
Testing same since   106790  2017-03-20 16:15:14 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  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=38b15ebe4fd5888493131d30fc31833a5e9a7d36
+ . ./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 
38b15ebe4fd5888493131d30fc31833a5e9a7d36
+ branch=ovmf
+ revision=38b15ebe4fd5888493131d30fc31833a5e9a7d36
+ . ./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
+ '[' x38b15ebe4fd5888493131d30fc31833a5e9a7d36 = 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] [RFC] xen/pvh: detect PVH after kexec

[Boris Ostrovsky]

On 03/20/2017 02:20 PM, Vitaly Kuznetsov wrote:
> PVH guests after kexec boot like normal HVM guests and we're not entering
> xen_prepare_pvh()

Is it not? Aren't we going via xen_hvm_shutdown() and then
SHUTDOWN_soft_reset which would restart at the same entry point as
regular boot?

-boris


>  but we still want to know that we're PVH. This hack does
> the job by using XEN_IOPORT_MAGIC but I didn't find any straitforward way
> to do it. Did I miss something? Or shall we introduce a CPUID leaf or
> something like that?
>
> Signed-off-by: Vitaly Kuznetsov 
> ---
>  arch/x86/xen/enlighten.c | 18 ++
>  1 file changed, 18 insertions(+)
>
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index ec1d5c4..4a30886 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -51,6 +51,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -1765,6 +1766,20 @@ void __init xen_prepare_pvh(void)
>  
>   x86_init.oem.arch_setup = xen_pvh_arch_setup;
>  }
> +
> +static void xen_detect_pvh(void)
> +{
> + short magic;
> +
> + if (xen_pvh)
> + return;
> +
> + magic = inw(XEN_IOPORT_MAGIC);
> + if (magic != XEN_IOPORT_MAGIC_VAL) {
> + xen_pvh = 1;
> + xen_pvh_arch_setup();
> + }
> +}
>  #endif
>  
>  void __ref xen_hvm_init_shared_info(void)
> @@ -1912,6 +1927,9 @@ static void __init xen_hvm_guest_init(void)
>  
>   init_hvm_pv_info();
>  
> + /* Detect PVH booting after kexec */
> + xen_detect_pvh();
> +
>   xen_hvm_init_shared_info();
>  
>   xen_panic_handler_init();


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

Re: [Xen-devel] [PATCH V2] common/mem_access: merged mem_access setting interfaces

[Razvan Cojocaru]

On 03/20/2017 06:54 PM, Jan Beulich wrote:
 On 20.03.17 at 17:48,  wrote:
>> On 03/20/2017 06:40 PM, Jan Beulich wrote:
>> On 20.03.17 at 17:16,  wrote:
 On 03/20/2017 06:14 PM, Razvan Cojocaru wrote:
> In any case, back when I've added xc_set_mem_access_multi() I've also
> modified struct xen_mem_access_op in the same manner:
>
>
 http://xenbits.xenproject.org/gitweb/?p=xen.git;a=commitdiff;h=1ef5056bd6274e
  
 cbe065387b6cf45657d6d700cd

 Oh, nevermind, I think you're referring to the fact that I had back then
 added members to the end of the structure, and so the old layout had
 remained compatible. Point taken.
>>>
>>> Not just that - there you've also introduced a new sub-op.
>>
>> Yes, but by modifying the structure for use with
>> XENMEM_access_op_set_access_multi, it's now also changed for, e.g.,
>> XENMEM_access_op_set_access - since it's common to them. Other than the
>> place where the new data has been added, I believe that the same
>> critique would apply to the old patch, unless I'm misunderstanding
>> something.
> 
> Indeed, strictly speaking that change wasn't really okay either,
> as someone passing the smaller structure near the end of a page
> might get -EFAULT back. So we're trying to do better this time ...

Two question remain to be answered then:

1. How should this proceed? Andrew's comment, taken together with Tamas'
last patch ("altp2m: Allow specifying external-only use-case") would
seem to imply that the best way forward is to revert to the previous
patch which duplicates the xc_set_mem_access_multi()'s mem-op with
xc_altp2m_set_mem_access_multi()'s HVMOP (with the compat code to be
worked out). Is there a consensus on this?

2. What is the best way to avoid incompatibilities such as the one
mentioned? For example, in this case, should I have deprecated
XENMEM_access_op_set_access and XENMEM_access_op_set_access_multi and
added XENMEM_access_op_set_access2 and XENMEM_access_op_set_access2? Or
do you have something different in mind?


Thanks,
Razvan

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qcow2 3 host-install(3)broken REGR. vs. 106777
 test-amd64-amd64-xl-qemuu-winxpsp3  9 windows-installfail REGR. vs. 106766
 test-amd64-i386-freebsd10-i386  9 freebsd-installfail REGR. vs. 106777
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 106777
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 14 guest-saverestore.2 fail 
REGR. vs. 106777
 test-armhf-armhf-libvirt-raw  6 xen-boot fail REGR. vs. 106777
 test-armhf-armhf-xl   6 xen-boot fail REGR. vs. 106777
 test-armhf-armhf-xl-vhd   6 xen-boot fail REGR. vs. 106777
 test-armhf-armhf-xl-multivcpu  6 xen-bootfail REGR. vs. 106777
 test-armhf-armhf-xl-credit2   6 xen-boot fail REGR. vs. 106777
 test-armhf-armhf-libvirt  6 xen-boot fail REGR. vs. 106777
 test-armhf-armhf-xl-xsm   6 xen-boot fail REGR. vs. 106777
 test-armhf-armhf-xl-cubietruck  6 xen-boot   fail REGR. vs. 106777
 test-armhf-armhf-libvirt-xsm  6 xen-boot fail REGR. vs. 106777
 test-amd64-amd64-libvirt-vhd 16 guest-start/debian.repeat fail REGR. vs. 106777
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail REGR. vs. 
106777
 test-amd64-amd64-pygrub   9 debian-di-installfail REGR. vs. 106777
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-installfail REGR. vs. 106777
 test-amd64-i386-xl-qemut-win7-amd64  9 windows-install   fail REGR. vs. 106777
 test-amd64-i386-xl-qemut-winxpsp3  9 windows-install fail REGR. vs. 106777
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 
106777
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 
106777
 test-amd64-i386-xl-qemuu-win7-amd64  9 windows-install   fail REGR. vs. 106777
 test-amd64-amd64-xl-qemut-win7-amd64  9 windows-install  fail REGR. vs. 106777
 test-amd64-amd64-xl-qemuu-win7-amd64  9 windows-install  fail REGR. vs. 106777

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-xsm   3 host-install(3) broken like 106777
 test-amd64-amd64-qemuu-nested-intel 17 capture-logs/l1(17) fail blocked in 
106777
 test-armhf-armhf-xl-arndale  11 guest-start  fail  like 106777
 test-armhf-armhf-xl-rtds 11 guest-start  fail  like 106777

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 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
 build-arm64-xsm   5 xen-buildfail   never pass
 build-arm64   5 xen-buildfail   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-amd64-i386-libvirt  12 migrate-support-checkfail   never pass

version targeted for testing:
 linuxf921b263d9602fb7873710c2df70671f2ffcf658
baseline version:
 linux93afaa4513bb08e69a3d6988ab4c3bf6c7cf07d3

Last test of basis  (not found) 
Failing since 0  1970-01-01 00:00:00 Z 17245 days
Testing same since   106784  2017-03-20 09:20:02 Z0 days1 attempts

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

[Xen-devel] [PATCH v4] altp2m: Allow specifying external-only use-case

[Tamas K Lengyel]

Currently setting altp2mhvm=1 in the domain configuration allows access to the
altp2m interface for both in-guest and external privileged tools. This poses
a problem for use-cases where only external access should be allowed, requiring
the user to compile Xen with XSM enabled to be able to appropriately restrict
access.

In this patch we deprecate the altp2mhvm domain configuration option and
introduce the altp2m option, which allows specifying if by default the altp2m
interface should be external-only. The information is stored in
HVM_PARAM_ALTP2M which we now define with specific XEN_ALTP2M_* modes.
If external_only mode is selected, the XSM check is shifted to use XSM_DM_PRIV
type check, thus restricting access to the interface by the guest itself. Note
that we keep the default XSM policy untouched. Users of XSM who wish to enforce
external_only mode for altp2m can do so by adjusting their XSM policy directly,
as this domain config option does not override an active XSM policy.

Also, as part of this patch we adjust the hvmop handler to require
HVM_PARAM_ALTP2M to be of a type other then disabled for all ops. This has been
previously only required for get/set altp2m domain state, all other options
were gated on altp2m_enabled. Since altp2m_enabled only gets set during set
altp2m domain state, this change introduces no new requirements to the other
ops but makes it more clear that it is required for all ops.

Signed-off-by: Tamas K Lengyel 
Signed-off-by: Sergej Proskurin 
Acked-by: Jan Beulich 
Acked-by: Daniel De Graaf 
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Andrew Cooper 

v4: Take patch out of ARM altp2m series. No hypervisor-side changes
other then not touching ARM code anymore. Toolstack side introduces the
altp2m config field such that it will require minimal churn once
ARM altp2m is added.
---
 docs/man/xl.cfg.pod.5.in| 37 -
 tools/libxl/libxl_create.c  |  7 +--
 tools/libxl/libxl_dom.c | 18 --
 tools/libxl/libxl_types.idl | 13 +
 tools/xl/xl_parse.c | 20 +++-
 xen/arch/x86/hvm/hvm.c  | 20 ++--
 xen/include/public/hvm/params.h | 10 +-
 xen/include/xsm/dummy.h | 14 +++---
 xen/include/xsm/xsm.h   |  6 +++---
 xen/xsm/flask/hooks.c   |  2 +-
 10 files changed, 123 insertions(+), 24 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index 52802d5d60..9ecda1e02c 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -1283,6 +1283,37 @@ enabled by default and you should usually omit it. It 
may be necessary
 to disable the HPET in order to improve compatibility with guest
 Operating Systems (X86 only)
 
+=item 

Re: [Xen-devel] [PATCH] x86/monitor: add support for descriptor access events

[Vlad-Ioan TOPAN]

On Fri, 17 Mar 2017 05:03:44 -0600
"Jan Beulich"  wrote:

> >>> On 10.03.17 at 16:50,  wrote:
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -3645,6 +3645,41 @@ gp_fault:
> >  return X86EMUL_EXCEPTION;
> >  }
> >  
> > +int hvm_descriptor_access_intercept(uint64_t exit_info, uint64_t 
> > exit_qualification, 
> > +uint8_t descriptor, bool_t is_write)
> 
> bool (also elsewhere)

Ok.

> > +{
> > +struct vcpu *v = current;
> > +struct domain *d = v->domain;
> 
> curr and currd respectively.

Ok.

> > +struct hvm_emulate_ctxt ctxt = {};
> 
> Please move this into the more narrow scope it's needed in.

Ok.

> > +int rc;
> > +
> > +if ( d->arch.monitor.descriptor_access_enabled )
> > +{
> > +ASSERT(v->arch.vm_event);
> > +hvm_monitor_descriptor_access(exit_info, exit_qualification, 
> > descriptor, is_write);
> > +}
> > +else
> > +{
> > +hvm_emulate_init_once(, NULL, guest_cpu_user_regs());
> > +rc = hvm_emulate_one();
> > +switch ( rc )
> > +{
> > +case X86EMUL_UNHANDLEABLE:
> > +hvm_inject_hw_exception(TRAP_invalid_op, X86_EVENT_NO_EC);
> 
> Is #UD the right exception here? In fact, is delivering an exception
> sensible in this case at all?

Possibly not; it's how that case is handled elsewhere. For the given
set of instructions at least, X86EMUL_UNHANDLEABLE should only be
returnable due to some internal bug/error (e.g. invalid/unknown
HVMCOPY_* constant returned by hvm_fetch_from_guest_linear() or an
invalid selector passed to ->write_segment() etc.); what would be the
best way to handle that case?

> > @@ -3369,6 +3384,33 @@ static void vmx_handle_xrstors(void)
> >  domain_crash(current->domain);
> >  }
> >  
> > +static void vmx_handle_descriptor_access(uint32_t exit_reason)
> > +{
> > +uint8_t instr_id;
> > +uint64_t instr_info;
> > +uint64_t exit_qualification;
> > +uint8_t descriptor = VM_EVENT_DESC_INVALID;
> > +
> > +__vmread(EXIT_QUALIFICATION, _qualification);
> > +__vmread(VMX_INSTRUCTION_INFO, _info);
> > +
> > +instr_id = (instr_info >> 28) & 3; /* Instruction identity: bits 29:28 
> > */
> > +
> > +if ( exit_reason == EXIT_REASON_ACCESS_GDTR_OR_IDTR )
> > +if ( instr_id & 1 )
> > +descriptor = VM_EVENT_DESC_IDTR;
> > +else
> > +descriptor = VM_EVENT_DESC_GDTR;
> > +else
> > +if ( instr_id & 1 )
> > +descriptor = VM_EVENT_DESC_TR;
> > +else
> > +descriptor = VM_EVENT_DESC_LDTR;
> 
> Please use conditional expressions instead of if/else in such cases.

Ok.

> > +hvm_descriptor_access_intercept(instr_info, exit_qualification, 
> > descriptor,
> > +instr_id >= 2);
> 
> instr_id & 2 (to be consistent with the other code. But anyway, even
> better would be to use manifest constants instead of all these literal
> numbers.

(instr_id & 2) makes sense, but the 1 & 2 literals are unnamed criteria
inferred from the encoding to simplify the code, they don't have an
explicit meaning (at least in the Intel docs).

> > @@ -444,6 +445,7 @@ int hvm_event_needs_reinjection(uint8_t type, uint8_t 
> > vector);
> >  uint8_t hvm_combine_hw_exceptions(uint8_t vec1, uint8_t vec2);
> >  
> >  void hvm_set_rdtsc_exiting(struct domain *d, bool_t enable);
> > +void hvm_set_descriptor_access_exiting(struct domain *d, bool_t enable);
> 
> Dead declaration.

It somehow got away from a previous (internal) version of the patch; it
will be removed.

> > --- a/xen/include/asm-x86/monitor.h
> > +++ b/xen/include/asm-x86/monitor.h
> > @@ -77,6 +77,7 @@ static inline uint32_t 
> > arch_monitor_get_capabilities(struct domain *d)
> > (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST) |
> > (1U << XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION) |
> > (1U << XEN_DOMCTL_MONITOR_EVENT_CPUID) |
> > +   (1U << XEN_DOMCTL_MONITOR_EVENT_DESC_ACCESS) |
> > (1U << XEN_DOMCTL_MONITOR_EVENT_INTERRUPT);
> 
> If I was the maintainer of this code, I'd ask for the elements to
> remain ordered numerically, i.e. matching ...
> 
> > --- a/xen/include/public/domctl.h
> > +++ b/xen/include/public/domctl.h
> > @@ -1087,6 +1087,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_psr_cmt_op_t);
> >  #define XEN_DOMCTL_MONITOR_EVENT_CPUID 6
> >  #define XEN_DOMCTL_MONITOR_EVENT_PRIVILEGED_CALL   7
> >  #define XEN_DOMCTL_MONITOR_EVENT_INTERRUPT 8
> > +#define XEN_DOMCTL_MONITOR_EVENT_DESC_ACCESS   9
> 
> ... the sequence here.

Ok.

> > @@ -259,6 +261,24 @@ struct vm_event_mov_to_msr {
> >  uint64_t value;
> >  };
> >  
> > +#define VM_EVENT_DESC_INVALID0
> 
> What is this good for?

The default (uninitialized) value is given a semantic of "invalid" to
make potential 

Re: [Xen-devel] [PATCH v2 09/12] x86/vmce, tools/libxl: expose LMCE capability in guest MSR_IA32_MCG_CAP

[Ian Jackson]

Haozhong Zhang writes ("[PATCH v2 09/12] x86/vmce, tools/libxl: expose LMCE 
capability in guest MSR_IA32_MCG_CAP"):
> If LMCE is supported by host and ' mca_caps = [ "lmce" ] ' is
> present in xl config, the LMCE capability will be exposed in guest
> MSR_IA32_MCG_CAP.  By default, LMCE is not exposed to guest so as to
> keep the backwards migration compatibility.

Excluse my ignorance, but I'm not sure what MCE, MCA and LMCE are.
I'm guessing MC = Machine Check ?

Is MCA "Machine Check Architecture" ?  Is that precisely the machinery
for handling MCEs, or is it something else ?

I think we may need a bit of care in the user-facing interface to try
to make the names and docs comprehensible.

> +=head3 x86
> +
> +=over 4
> +
> +=item 

Re: [Xen-devel] [PATCH 3/5] x86/vioapic: introduce support for multiple vIO APICS

[Roger Pau Monne]

On Fri, Mar 03, 2017 at 10:06:03AM -0700, Jan Beulich wrote:
> >>> On 23.02.17 at 12:52,  wrote:
> > +struct hvm_hw_vioapic *gsi_vioapic(struct domain *d, unsigned int gsi,
> 
> const struct domain *d ?
> 
> > +static unsigned int pin_gsi(struct domain *d, struct hvm_hw_vioapic 
> > *vioapic,
> 
> const for both?
>
> > +unsigned int pin)
> > +{
> > +struct hvm_hw_vioapic *tmp;
> 
> And here.

Done for all the above.

> Also wouldn't this function more naturally (i.e. more generally useful)
> simply return the base GSI, leaving it to the caller to add the pin
> number?

I don't have a strong opinion. Most (if not all callers) seem to want the pin,
but you can obtain that by just doing gsi - base_gsi, so I changed it to return
base_gsi (which also simplifies the code).

> > @@ -157,21 +210,22 @@ static void vioapic_write_redirent(
> >  pent->fields.remote_irr = 0;
> >  else if ( !ent.fields.mask &&
> >!ent.fields.remote_irr &&
> > -  hvm_irq->gsi_assert_count[idx] )
> > +  hvm_irq->gsi_assert_count[gsi] )
> 
> Neither this nor any earlier patch modified the size of this array, afaics.

Hm, right. This is still hardcoded to VIOAPIC_NUM_PINS. I should change it in
the earlier patch also.

> > -static void vioapic_write_indirect(struct domain *d, uint32_t val)
> > +static void vioapic_write_indirect(struct domain *d, unsigned long addr,
> > +   uint32_t val)
> >  {
> > -struct hvm_hw_vioapic *vioapic = domain_vioapic(d);
> > +struct hvm_hw_vioapic *vioapic = addr_vioapic(d, addr);
> 
> I think it would be better for the caller to pass the vioapic it
> already established (and ASSERT()ed).

Done. Now that hvm_vioapic has a reference to struct domain I no longer need to
pass the domain around.

> > @@ -430,11 +493,14 @@ void vioapic_update_EOI(struct domain *d, u8 vector)
> >  
> >  static int vioapic_save(struct domain *d, hvm_domain_context_t *h)
> >  {
> > -struct hvm_hw_vioapic *vioapic = domain_vioapic(d);
> > +struct hvm_hw_vioapic *vioapic = domain_vioapic(d, 0);
> >  
> >  if ( !has_vioapic(d) )
> >  return 0;
> >  
> > +if ( d->arch.hvm_domain.nr_vioapics != 1 )
> > +return -ENOSYS;
> > +
> >  if ( vioapic->nr_pins != VIOAPIC_NUM_PINS )
> >  return -ENOSYS;
> 
> Perhaps merge the two if()s? Otherwise -EOPNOTSUPP again.

OK.

> >  int vioapic_init(struct domain *d)
> >  {
> >  if ( !has_vioapic(d) )
> > +{
> > +d->arch.hvm_domain.nr_vioapics = 0;
> 
> I don't think this is needed - if anything you may want to again
> ASSERT() it being zero.

Done.

> > --- a/xen/arch/x86/hvm/vlapic.c
> > +++ b/xen/arch/x86/hvm/vlapic.c
> > @@ -1120,7 +1120,7 @@ static int __vlapic_accept_pic_intr(struct vcpu *v)
> >  if ( !has_vioapic(d) )
> >  return 0;
> >  
> > -redir0 = domain_vioapic(d)->redirtbl[0];
> > +redir0 = domain_vioapic(d, 0)->redirtbl[0];
> 
> What if the first IO-APIC has less than 16 pins?

I'm not sure I understand what this piece of code is trying to do. Why is PIC
relying on the value of the first redirection entry of the IO APIC? Aren't the
PIC and the IO APIC modes mutually exclusive?

I would appreciate if you could provide some reference here.

> > --- a/xen/arch/x86/hvm/vpt.c
> > +++ b/xen/arch/x86/hvm/vpt.c
> > @@ -78,7 +78,8 @@ void hvm_set_guest_time(struct vcpu *v, u64 guest_time)
> >  static int pt_irq_vector(struct periodic_time *pt, enum hvm_intsrc src)
> >  {
> >  struct vcpu *v = pt->vcpu;
> > -unsigned int gsi, isa_irq;
> > +struct hvm_hw_vioapic *vioapic;
> > +unsigned int gsi, isa_irq, pin;
> >  
> >  if ( pt->source == PTSRC_lapic )
> >  return pt->irq;
> > @@ -91,13 +92,16 @@ static int pt_irq_vector(struct periodic_time *pt, enum 
> > hvm_intsrc src)
> >  + (isa_irq & 7));
> >  
> >  ASSERT(src == hvm_intsrc_lapic);
> > -return domain_vioapic(v->domain)->redirtbl[gsi].fields.vector;
> > +vioapic = gsi_vioapic(v->domain, gsi, );
> > +
> > +return vioapic->redirtbl[pin].fields.vector;
> 
> Please don't chance de-referencing NULL here and below.

Done, I've added an ASSERT.

Roger.

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

[Xen-devel] [RFC] xen/pvh: detect PVH after kexec

[Vitaly Kuznetsov]

PVH guests after kexec boot like normal HVM guests and we're not entering
xen_prepare_pvh() but we still want to know that we're PVH. This hack does
the job by using XEN_IOPORT_MAGIC but I didn't find any straitforward way
to do it. Did I miss something? Or shall we introduce a CPUID leaf or
something like that?

Signed-off-by: Vitaly Kuznetsov 
---
 arch/x86/xen/enlighten.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index ec1d5c4..4a30886 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -51,6 +51,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1765,6 +1766,20 @@ void __init xen_prepare_pvh(void)
 
x86_init.oem.arch_setup = xen_pvh_arch_setup;
 }
+
+static void xen_detect_pvh(void)
+{
+   short magic;
+
+   if (xen_pvh)
+   return;
+
+   magic = inw(XEN_IOPORT_MAGIC);
+   if (magic != XEN_IOPORT_MAGIC_VAL) {
+   xen_pvh = 1;
+   xen_pvh_arch_setup();
+   }
+}
 #endif
 
 void __ref xen_hvm_init_shared_info(void)
@@ -1912,6 +1927,9 @@ static void __init xen_hvm_guest_init(void)
 
init_hvm_pv_info();
 
+   /* Detect PVH booting after kexec */
+   xen_detect_pvh();
+
xen_hvm_init_shared_info();
 
xen_panic_handler_init();
-- 
2.9.3


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

[Xen-devel] [PATCH v4 0/8] xen/9pfs: introduce the Xen 9pfs backend

[Stefano Stabellini]

Hi all,

This patch series implements a new transport for 9pfs, aimed at Xen
systems.

The transport is based on a traditional Xen frontend and backend drivers
pair. This patch series implements the backend, which typically runs in
Dom0. I sent another series to implement the frontend in Linux
(http://marc.info/?l=linux-kernel=148883047125960=2).

The backend complies to the Xen transport for 9pfs specification
version 1, available here:

https://xenbits.xen.org/docs/unstable/misc/9pfs.html


Changes in v4:
- add reviewed-bys
- remove useless if(NULL) checks around g_free
- g_free g_malloc'ed sgs
- remove XEN_9PFS_RING_ORDER, make the ring order dynamic per ring,
  reading the ring_order field in xen_9pfs_data_intf
- remove patch not to build Xen backends on non-Xen capable targets
  because it is already upstream

Changes in v3:
- do not build backends for targets that do not support xen
- remove xen_9pfs.h, merge its content into xen-9p-backend.c
- remove xen_9pfs_header, introduce P9MsgHeader
- use le32_to_cpu to access P9MsgHeader fields
- many coding style fixes
- run checkpatch on all patches
- add check if num_rings < 1
- use g_strdup_printf
- free fsdev_id in xen_9pfs_free
- add comments

Changes in v2:
- fix coding style
- compile xen-9p-backend.c if CONFIG_XEN_BACKEND
- add patch to set CONFIG_XEN_BACKEND only for the right targets
- add review-bys


Stefano Stabellini (8):
  xen: import ring.h from xen
  9p: introduce a type for the 9p header
  xen/9pfs: introduce Xen 9pfs backend
  xen/9pfs: connect to the frontend
  xen/9pfs: receive requests from the frontend
  xen/9pfs: implement in/out_iov_from_pdu and vmarshal/vunmarshal
  xen/9pfs: send responses back to the frontend
  xen/9pfs: build and register Xen 9pfs backend

 hw/9pfs/9p.h |   6 +
 hw/9pfs/Makefile.objs|   1 +
 hw/9pfs/virtio-9p-device.c   |   6 +-
 hw/9pfs/xen-9p-backend.c | 444 +
 hw/block/xen_blkif.h |   2 +-
 hw/usb/xen-usb.c |   2 +-
 hw/xen/xen_backend.c |   3 +
 include/hw/xen/io/ring.h | 455 +++
 include/hw/xen/xen_backend.h |   3 +
 9 files changed, 915 insertions(+), 7 deletions(-)
 create mode 100644 hw/9pfs/xen-9p-backend.c
 create mode 100644 include/hw/xen/io/ring.h

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

Re: [Xen-devel] [PATCH v4 05/14] golang/xenlight: Add tests host related functionality functions

[Ian Jackson]

George Dunlap writes ("Re: [Xen-devel] [PATCH v4 05/14] golang/xenlight: Add 
tests host related functionality functions"):
> I had a chat with Ian Jackson, and we agreed that it would be better
> to create a file, maybe "test-common.c", that would contain this
> variable, as well as the three functions below.
> 
> Then the header ("test-common.h") would contain *declarations* of the
> variable (i.e., "extern xentoollog_logger_stdiostream *logger;") and
> function prototypes.
> 
> The test-common.c file is small now, but it may grow as additional
> functionality is needed.

Right.

> The other thing you might consider, to further reduce the boilerplate
> you have in each unit test file, is to also include a libxl_ctx
> pointer in test-common; and have create_context() simply return an int
> (0 for success, -1 for failure).

This would be nice.

You might also consider whether create_context would better simply
exit the program if it fails.  That avoids any possibility of error
handling bugs.  And maybe it should be called test_common_setup() ?
(Names are a matter of taste, though.)

Also: in C, main needs to return a value.  I'm surprised your compiler
isn't complaining.  (Are the compiler warnings properly enabled?)  I
think I mentioned this one before...

Your test main functions should probably end with something like
  return test_common_complete();
(which would be like destroy_context but would return 0.)

Ian.

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

[Xen-devel] [xen-unstable-smoke test] 106789: tolerable trouble: broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   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  2588a12732e71e6754b53689b981ec6a37b39983
baseline version:
 xen  4fc380ac0077ecd6b0e0013ca7ca977cb7361662

Last test of basis   106783  2017-03-20 09:01:41 Z0 days
Testing same since   106789  2017-03-20 16:02:05 Z0 days1 attempts


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

jobs:
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 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=2588a12732e71e6754b53689b981ec6a37b39983
+ . ./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 
2588a12732e71e6754b53689b981ec6a37b39983
+ branch=xen-unstable-smoke
+ revision=2588a12732e71e6754b53689b981ec6a37b39983
+ . ./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
+ '[' x2588a12732e71e6754b53689b981ec6a37b39983 = 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

[Xen-devel] [PATCH 2/2] libxl: preserve console tty across soft reset

[Vitaly Kuznetsov]

On soft reset we remove the domain from xenstore and introduce it back to
have everything reconnected. Console, however, stays attached (as xenconsoled
checks if the domain is dying and our domain is not) but we lose the
information about tty:

before soft reset:
   console = ""
...
type = "xenconsoled"
output = "pty"
tty = "/dev/pts/1"
...

after:
   console = ""
...
type = "xenconsoled"
output = "pty"
tty = ""
...

The issue applies to both HVM and PVH but for HVM guests serial console
through QEMU is usually in use and for PVH we don't have it.

Signed-off-by: Vitaly Kuznetsov 
---
 tools/libxl/libxl_console.c  | 5 -
 tools/libxl/libxl_create.c   | 8 +++-
 tools/libxl/libxl_internal.h | 1 +
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_console.c b/tools/libxl/libxl_console.c
index cbc70b7..446e766 100644
--- a/tools/libxl/libxl_console.c
+++ b/tools/libxl/libxl_console.c
@@ -316,7 +316,10 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t 
domid,
 flexarray_append(ro_front, "output");
 flexarray_append(ro_front, console->output);
 flexarray_append(ro_front, "tty");
-flexarray_append(ro_front, "");
+if (state && state->console_tty)
+flexarray_append(ro_front, state->console_tty);
+else
+flexarray_append(ro_front, "");
 
 if (state) {
 flexarray_append(ro_front, "port");
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 95fd96b..ad8a424 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1696,7 +1696,7 @@ static int do_domain_soft_reset(libxl_ctx *ctx,
 libxl__domain_create_state *dcs;
 libxl__domain_build_state *state;
 libxl__domain_save_state *dss;
-char *dom_path, *xs_store_mfn, *xs_console_mfn;
+char *dom_path, *xs_store_mfn, *xs_console_mfn, *xs_console_tty;
 uint32_t domid_out;
 int rc;
 
@@ -1737,6 +1737,12 @@ static int do_domain_soft_reset(libxl_ctx *ctx,
 state->console_mfn = xs_console_mfn ? atol(xs_console_mfn): 0;
 free(xs_console_mfn);
 
+xs_console_tty = xs_read(ctx->xsh, XBT_NULL,
+ GCSPRINTF("%s/console/tty", dom_path),
+ NULL);
+state->console_tty = libxl__strdup(gc, xs_console_tty);
+free(xs_console_tty);
+
 dss->ao = ao;
 dss->domid = dss->dsps.domid = domid_soft_reset;
 dss->dsps.dm_savefile = GCSPRINTF(LIBXL_DEVICE_MODEL_SAVE_FILE".%d",
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7722665..88fca8e 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1123,6 +1123,7 @@ typedef struct {
 uint32_t console_port;
 uint32_t console_domid;
 unsigned long console_mfn;
+char *console_tty;
 
 char *saved_state;
 
-- 
2.9.3


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

[Xen-devel] [PATCH 1/2] libxl: don't try to rename dm save file for PVH

[Vitaly Kuznetsov]

Guests with LIBXL_DEVICE_MODEL_VERSION_NONE don't have a device model
running so there is no save file to rename.

Signed-off-by: Vitaly Kuznetsov 
---
 tools/libxl/libxl_create.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 25389e1..95fd96b 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1664,12 +1664,16 @@ static void domain_soft_reset_cb(libxl__egc *egc,
 goto error;
 }
 
-savefile = GCSPRINTF(LIBXL_DEVICE_MODEL_SAVE_FILE".%d", dds->domid);
-restorefile = GCSPRINTF(LIBXL_DEVICE_MODEL_RESTORE_FILE".%d", dds->domid);
-rc = rename(savefile, restorefile);
-if (rc) {
-LOGD(ERROR, dds->domid, "failed to rename dm save file.");
-goto error;
+if (cdcs->dcs.guest_config->b_info.device_model_version !=
+LIBXL_DEVICE_MODEL_VERSION_NONE) {
+savefile = GCSPRINTF(LIBXL_DEVICE_MODEL_SAVE_FILE".%d", dds->domid);
+restorefile = GCSPRINTF(LIBXL_DEVICE_MODEL_RESTORE_FILE".%d",
+dds->domid);
+rc = rename(savefile, restorefile);
+if (rc) {
+LOGD(ERROR, dds->domid, "failed to rename dm save file.");
+goto error;
+}
 }
 
 initiate_domain_create(egc, >dcs);
-- 
2.9.3


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

[Xen-devel] [PATCH 0/2] libxl: fix soft reset for PVHv2 guests

[Vitaly Kuznetsov]

Hi,

I'm trying to make kexec/kdump work for PVHv2 guests too. PVHv2 guests are
almost HVM guests so no major changes to the soft reset procedures are
required. A few issues, however, arose during testing.

Linux also requires some changes to boot after kexec. As PVH guests boot
like normal HVM guests after kexec we need to detect their 'PVH-ness'
somehow here's a hack which utilizes XEN_IOPORT_MAGIC:

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index ec1d5c4..b9f3fdf 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -51,6 +51,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1765,6 +1766,19 @@ void __init xen_prepare_pvh(void)
 
x86_init.oem.arch_setup = xen_pvh_arch_setup;
 }
+
+static void xen_detect_pvh(void) {
+   short magic;
+
+   if (xen_pvh)
+   return;
+
+   magic = inw(XEN_IOPORT_MAGIC);
+   if (magic != XEN_IOPORT_MAGIC_VAL) {
+   xen_pvh = 1;
+   xen_pvh_arch_setup();
+   }
+}
 #endif
 
 void __ref xen_hvm_init_shared_info(void)
@@ -1912,6 +1926,9 @@ static void __init xen_hvm_guest_init(void)
 
init_hvm_pv_info();
 
+   /* Detect PVH booting after kexec */
+   xen_detect_pvh();
+
xen_hvm_init_shared_info();
 
xen_panic_handler_init();

With the hack I was able to do kdump on a PVHv2 guest. I'll start a separate
mail thread to discuss how we should do it right.

Vitaly Kuznetsov (2):
  libxl: don't try to rename dm save file for PVH
  libxl: preserve console tty across soft reset

 tools/libxl/libxl_console.c  |  5 -
 tools/libxl/libxl_create.c   | 24 +---
 tools/libxl/libxl_internal.h |  1 +
 3 files changed, 22 insertions(+), 8 deletions(-)

-- 
2.9.3


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

[Xen-devel] [PATCH v5 4/7] xen/9pfs: connect to the backend

[Stefano Stabellini]

Implement functions to handle the xenbus handshake. Upon connection,
allocate the rings according to the protocol specification.

Initialize a work_struct and a wait_queue. The work_struct will be used
to schedule work upon receiving an event channel notification from the
backend. The wait_queue will be used to wait when the ring is full and
we need to send a new request.

Signed-off-by: Stefano Stabellini 
CC: gr...@kaod.org
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
CC: Eric Van Hensbergen 
CC: Ron Minnich 
CC: Latchesar Ionkov 
CC: v9fs-develo...@lists.sourceforge.net
---
 net/9p/trans_xen.c | 273 +
 1 file changed, 273 insertions(+)

diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
index 3d07260..5279ae0 100644
--- a/net/9p/trans_xen.c
+++ b/net/9p/trans_xen.c
@@ -37,10 +37,46 @@
 #include 
 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
 
+#define XEN_9PFS_NUM_RINGS 2
+#define XEN_9PFS_RING_ORDER 6
+#define XEN_9PFS_RING_SIZE  XEN_FLEX_RING_SIZE(XEN_9PFS_RING_ORDER)
+
+/* One per ring, more than one per 9pfs share */
+struct xen_9pfs_dataring {
+   struct xen_9pfs_front_priv *priv;
+
+   struct xen_9pfs_data_intf *intf;
+   grant_ref_t ref;
+   int evtchn;
+   int irq;
+   /* protect a ring from concurrent accesses */
+   spinlock_t lock;
+
+   struct xen_9pfs_data data;
+   wait_queue_head_t wq;
+   struct work_struct work;
+};
+
+/* One per 9pfs share */
+struct xen_9pfs_front_priv {
+   struct list_head list;
+   struct xenbus_device *dev;
+   char *tag;
+   struct p9_client *client;
+
+   int num_rings;
+   struct xen_9pfs_dataring *rings;
+};
+
+static LIST_HEAD(xen_9pfs_devs);
+static DEFINE_RWLOCK(xen_9pfs_lock);
+
 static int p9_xen_cancel(struct p9_client *client, struct p9_req_t *req)
 {
return 0;
@@ -60,6 +96,25 @@ static int p9_xen_request(struct p9_client *client, struct 
p9_req_t *p9_req)
return 0;
 }
 
+static void p9_xen_response(struct work_struct *work)
+{
+}
+
+static irqreturn_t xen_9pfs_front_event_handler(int irq, void *r)
+{
+   struct xen_9pfs_dataring *ring = r;
+
+   if (!ring || !ring->priv->client) {
+   /* ignore spurious interrupt */
+   return IRQ_HANDLED;
+   }
+
+   wake_up_interruptible(>wq);
+   schedule_work(>work);
+
+   return IRQ_HANDLED;
+}
+
 static struct p9_trans_module p9_xen_trans = {
.name = "xen",
.maxsize = 1 << (XEN_9PFS_RING_ORDER + XEN_PAGE_SHIFT),
@@ -76,25 +131,243 @@ static int p9_xen_request(struct p9_client *client, 
struct p9_req_t *p9_req)
{ "" }
 };
 
+static void xen_9pfs_front_free(struct xen_9pfs_front_priv *priv)
+{
+   int i, j;
+
+   write_lock(_9pfs_lock);
+   list_del(>list);
+   write_unlock(_9pfs_lock);
+
+   for (i = 0; i < priv->num_rings; i++) {
+   if (!priv->rings[i].intf)
+   break;
+   if (priv->rings[i].irq > 0)
+   unbind_from_irqhandler(priv->rings[i].irq, priv->dev);
+   if (priv->rings[i].data.in) {
+   for (j = 0; j < (1 << XEN_9PFS_RING_ORDER); j++) {
+   grant_ref_t ref;
+
+   ref = priv->rings[i].intf->ref[j];
+   gnttab_end_foreign_access(ref, 0, 0);
+   }
+   free_pages((unsigned long)priv->rings[i].data.in,
+  XEN_9PFS_RING_ORDER -
+  (PAGE_SHIFT - XEN_PAGE_SHIFT));
+   }
+   gnttab_end_foreign_access(priv->rings[i].ref, 0, 0);
+   free_page((unsigned long)priv->rings[i].intf);
+   }
+   kfree(priv->rings);
+   kfree(priv->tag);
+   kfree(priv);
+}
+
 static int xen_9pfs_front_remove(struct xenbus_device *dev)
 {
+   struct xen_9pfs_front_priv *priv = dev_get_drvdata(>dev);
+
+   dev_set_drvdata(>dev, NULL);
+   xen_9pfs_front_free(priv);
+   return 0;
+}
+
+static int xen_9pfs_front_alloc_dataring(struct xenbus_device *dev,
+struct xen_9pfs_dataring *ring)
+{
+   int i = 0;
+   int ret = -ENOMEM;
+   void *bytes = NULL;
+
+   init_waitqueue_head(>wq);
+   spin_lock_init(>lock);
+   INIT_WORK(>work, p9_xen_response);
+
+   ring->intf = (struct xen_9pfs_data_intf *)get_zeroed_page(GFP_KERNEL);
+   if (!ring->intf)
+   return ret;
+   ret = gnttab_grant_foreign_access(dev->otherend_id,
+ virt_to_gfn(ring->intf), 0);
+   if (ret < 0)
+   goto out;
+   ring->ref = ret;
+   bytes = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
+   XEN_9PFS_RING_ORDER - (PAGE_SHIFT - 

[Xen-devel] [PATCH v5 7/7] xen/9pfs: build 9pfs Xen transport driver

[Stefano Stabellini]

This patch adds a Kconfig option and Makefile support for building the
9pfs Xen driver.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Juergen Gross 
CC: gr...@kaod.org
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
CC: Eric Van Hensbergen 
CC: Ron Minnich 
CC: Latchesar Ionkov 
CC: v9fs-develo...@lists.sourceforge.net
---
 net/9p/Kconfig  | 8 
 net/9p/Makefile | 4 
 2 files changed, 12 insertions(+)

diff --git a/net/9p/Kconfig b/net/9p/Kconfig
index a75174a..3f286f1 100644
--- a/net/9p/Kconfig
+++ b/net/9p/Kconfig
@@ -22,6 +22,14 @@ config NET_9P_VIRTIO
  This builds support for a transports between
  guest partitions and a host partition.
 
+config NET_9P_XEN
+   depends on XEN
+   tristate "9P Xen Transport"
+   help
+ This builds support for a transport for 9pfs between
+ two Xen domains.
+
+
 config NET_9P_RDMA
depends on INET && INFINIBAND && INFINIBAND_ADDR_TRANS
tristate "9P RDMA Transport (Experimental)"
diff --git a/net/9p/Makefile b/net/9p/Makefile
index a0874cc..697ea7c 100644
--- a/net/9p/Makefile
+++ b/net/9p/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_NET_9P) := 9pnet.o
+obj-$(CONFIG_NET_9P_XEN) += 9pnet_xen.o
 obj-$(CONFIG_NET_9P_VIRTIO) += 9pnet_virtio.o
 obj-$(CONFIG_NET_9P_RDMA) += 9pnet_rdma.o
 
@@ -14,5 +15,8 @@ obj-$(CONFIG_NET_9P_RDMA) += 9pnet_rdma.o
 9pnet_virtio-objs := \
trans_virtio.o \
 
+9pnet_xen-objs := \
+   trans_xen.o \
+
 9pnet_rdma-objs := \
trans_rdma.o \
-- 
1.9.1


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

[Xen-devel] [PATCH v5 5/7] xen/9pfs: send requests to the backend

[Stefano Stabellini]

Implement struct p9_trans_module create and close functions by looking
at the available Xen 9pfs frontend-backend connections. We don't expect
many frontend-backend connections, thus walking a list is OK.

Send requests to the backend by copying each request to one of the
available rings (each frontend-backend connection comes with multiple
rings). Handle the ring and notifications following the 9pfs
specification. If there are not enough free bytes on the ring for the
request, wait on the wait_queue: the backend will send a notification
after consuming more requests.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Boris Ostrovsky 
CC: gr...@kaod.org
CC: jgr...@suse.com
CC: Eric Van Hensbergen 
CC: Ron Minnich 
CC: Latchesar Ionkov 
CC: v9fs-develo...@lists.sourceforge.net
---
 net/9p/trans_xen.c | 91 --
 1 file changed, 89 insertions(+), 2 deletions(-)

diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
index 5279ae0..e51edac 100644
--- a/net/9p/trans_xen.c
+++ b/net/9p/trans_xen.c
@@ -77,22 +77,109 @@ struct xen_9pfs_front_priv {
 static LIST_HEAD(xen_9pfs_devs);
 static DEFINE_RWLOCK(xen_9pfs_lock);
 
+/* We don't currently allow canceling of requests */
 static int p9_xen_cancel(struct p9_client *client, struct p9_req_t *req)
 {
-   return 0;
+   return 1;
 }
 
 static int p9_xen_create(struct p9_client *client, const char *addr, char 
*args)
 {
-   return 0;
+   struct xen_9pfs_front_priv *priv;
+
+   read_lock(_9pfs_lock);
+   list_for_each_entry(priv, _9pfs_devs, list) {
+   if (!strcmp(priv->tag, addr)) {
+   priv->client = client;
+   read_unlock(_9pfs_lock);
+   return 0;
+   }
+   }
+   read_unlock(_9pfs_lock);
+   return -EINVAL;
 }
 
 static void p9_xen_close(struct p9_client *client)
 {
+   struct xen_9pfs_front_priv *priv;
+
+   read_lock(_9pfs_lock);
+   list_for_each_entry(priv, _9pfs_devs, list) {
+   if (priv->client == client) {
+   priv->client = NULL;
+   read_unlock(_9pfs_lock);
+   return;
+   }
+   }
+   read_unlock(_9pfs_lock);
+}
+
+static int p9_xen_write_todo(struct xen_9pfs_dataring *ring, RING_IDX size)
+{
+   RING_IDX cons, prod;
+
+   cons = ring->intf->out_cons;
+   prod = ring->intf->out_prod;
+   virt_mb();
+
+   if (XEN_9PFS_RING_SIZE - xen_9pfs_queued(prod, cons,
+XEN_9PFS_RING_SIZE) >= size)
+   return 1;
+   else
+   return 0;
 }
 
 static int p9_xen_request(struct p9_client *client, struct p9_req_t *p9_req)
 {
+   struct xen_9pfs_front_priv *priv = NULL;
+   RING_IDX cons, prod, masked_cons, masked_prod;
+   unsigned long flags;
+   u32 size = p9_req->tc->size;
+   struct xen_9pfs_dataring *ring;
+   int num;
+
+   read_lock(_9pfs_lock);
+   list_for_each_entry(priv, _9pfs_devs, list) {
+   if (priv->client == client)
+   break;
+   }
+   read_unlock(_9pfs_lock);
+   if (!priv || priv->client != client)
+   return -EINVAL;
+
+   num = p9_req->tc->tag % priv->num_rings;
+   ring = >rings[num];
+
+again:
+   while (wait_event_interruptible(ring->wq,
+   p9_xen_write_todo(ring, size) > 0) != 0)
+   ;
+
+   spin_lock_irqsave(>lock, flags);
+   cons = ring->intf->out_cons;
+   prod = ring->intf->out_prod;
+   virt_mb();
+
+   if (XEN_9PFS_RING_SIZE - xen_9pfs_queued(prod, cons,
+XEN_9PFS_RING_SIZE) < size) {
+   spin_unlock_irqrestore(>lock, flags);
+   goto again;
+   }
+
+   masked_prod = xen_9pfs_mask(prod, XEN_9PFS_RING_SIZE);
+   masked_cons = xen_9pfs_mask(cons, XEN_9PFS_RING_SIZE);
+
+   xen_9pfs_write_packet(ring->data.out,
+ _prod, masked_cons,
+ XEN_9PFS_RING_SIZE, p9_req->tc->sdata, size);
+
+   p9_req->status = REQ_STATUS_SENT;
+   virt_wmb(); /* write ring before updating pointer */
+   prod += size;
+   ring->intf->out_prod = prod;
+   spin_unlock_irqrestore(>lock, flags);
+   notify_remote_via_irq(ring->irq);
+
return 0;
 }
 
-- 
1.9.1


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

[Xen-devel] [PATCH v5 2/7] xen: introduce the header file for the Xen 9pfs transport protocol

[Stefano Stabellini]

It uses the new ring.h macros to declare rings and interfaces.

Signed-off-by: Stefano Stabellini 
CC: konrad.w...@oracle.com
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
CC: gr...@kaod.org
---
 include/xen/interface/io/9pfs.h | 42 +
 1 file changed, 42 insertions(+)
 create mode 100644 include/xen/interface/io/9pfs.h

diff --git a/include/xen/interface/io/9pfs.h b/include/xen/interface/io/9pfs.h
new file mode 100644
index 000..088345d
--- /dev/null
+++ b/include/xen/interface/io/9pfs.h
@@ -0,0 +1,42 @@
+/*
+ * 9pfs.h -- Xen 9PFS transport
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (C) 2017 Stefano Stabellini 
+ */
+
+#ifndef __XEN_PUBLIC_IO_9PFS_H__
+#define __XEN_PUBLIC_IO_9PFS_H__
+
+#include "xen/interface/io/ring.h"
+
+/*
+ * See docs/misc/9pfs.markdown in xen.git for the full specification:
+ * https://xenbits.xen.org/docs/unstable/misc/9pfs.html
+ */
+struct xen_9pfs_header {
+   uint32_t size;
+   uint8_t id;
+   uint16_t tag;
+} __packed;
+
+DEFINE_XEN_FLEX_RING_AND_INTF(xen_9pfs);
+
+#endif
-- 
1.9.1


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

[Xen-devel] [PATCH v5 6/7] xen/9pfs: receive responses

[Stefano Stabellini]

Upon receiving a notification from the backend, schedule the
p9_xen_response work_struct. p9_xen_response checks if any responses are
available, if so, it reads them one by one, calling p9_client_cb to send
them up to the 9p layer (p9_client_cb completes the request). Handle the
ring following the Xen 9pfs specification.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Boris Ostrovsky 
CC: gr...@kaod.org
CC: jgr...@suse.com
CC: Eric Van Hensbergen 
CC: Ron Minnich 
CC: Latchesar Ionkov 
CC: v9fs-develo...@lists.sourceforge.net
---
 net/9p/trans_xen.c | 56 ++
 1 file changed, 56 insertions(+)

diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
index e51edac..4ffe250 100644
--- a/net/9p/trans_xen.c
+++ b/net/9p/trans_xen.c
@@ -185,6 +185,62 @@ static int p9_xen_request(struct p9_client *client, struct 
p9_req_t *p9_req)
 
 static void p9_xen_response(struct work_struct *work)
 {
+   struct xen_9pfs_front_priv *priv;
+   struct xen_9pfs_dataring *ring;
+   RING_IDX cons, prod, masked_cons, masked_prod;
+   struct xen_9pfs_header h;
+   struct p9_req_t *req;
+   int status;
+
+   ring = container_of(work, struct xen_9pfs_dataring, work);
+   priv = ring->priv;
+
+   while (1) {
+   cons = ring->intf->in_cons;
+   prod = ring->intf->in_prod;
+   virt_rmb();
+
+   if (xen_9pfs_queued(prod, cons, XEN_9PFS_RING_SIZE) <
+   sizeof(h)) {
+   notify_remote_via_irq(ring->irq);
+   return;
+   }
+
+   masked_prod = xen_9pfs_mask(prod, XEN_9PFS_RING_SIZE);
+   masked_cons = xen_9pfs_mask(cons, XEN_9PFS_RING_SIZE);
+
+   /* First, read just the header */
+   xen_9pfs_read_packet(ring->data.in,
+masked_prod, _cons,
+XEN_9PFS_RING_SIZE, , sizeof(h));
+
+   req = p9_tag_lookup(priv->client, h.tag);
+   if (!req || req->status != REQ_STATUS_SENT) {
+   dev_warn(>dev->dev, "Wrong req tag=%x\n", h.tag);
+   cons += h.size;
+   virt_mb();
+   ring->intf->in_cons = cons;
+   continue;
+   }
+
+   memcpy(req->rc, , sizeof(h));
+   req->rc->offset = 0;
+
+   masked_cons = xen_9pfs_mask(cons, XEN_9PFS_RING_SIZE);
+   /* Then, read the whole packet (including the header) */
+   xen_9pfs_read_packet(ring->data.in,
+masked_prod, _cons,
+XEN_9PFS_RING_SIZE, req->rc->sdata, 
h.size);
+
+   virt_mb();
+   cons += h.size;
+   ring->intf->in_cons = cons;
+
+   status = (req->status != REQ_STATUS_ERROR) ?
+   REQ_STATUS_RCVD : REQ_STATUS_ERROR;
+
+   p9_client_cb(priv->client, req, status);
+   }
 }
 
 static irqreturn_t xen_9pfs_front_event_handler(int irq, void *r)
-- 
1.9.1


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

[Xen-devel] [PATCH v5 3/7] xen/9pfs: introduce Xen 9pfs transport driver

[Stefano Stabellini]

Introduce the Xen 9pfs transport driver: add struct xenbus_driver to
register as a xenbus driver and add struct p9_trans_module to register
as v9fs driver.

All functions are empty stubs for now.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Boris Ostrovsky 
CC: gr...@kaod.org
CC: jgr...@suse.com
CC: Eric Van Hensbergen 
CC: Ron Minnich 
CC: Latchesar Ionkov 
CC: v9fs-develo...@lists.sourceforge.net
---
 net/9p/trans_xen.c | 125 +
 1 file changed, 125 insertions(+)
 create mode 100644 net/9p/trans_xen.c

diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
new file mode 100644
index 000..3d07260
--- /dev/null
+++ b/net/9p/trans_xen.c
@@ -0,0 +1,125 @@
+/*
+ * linux/fs/9p/trans_xen
+ *
+ * Xen transport layer.
+ *
+ * Copyright (C) 2017 by Stefano Stabellini 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+static int p9_xen_cancel(struct p9_client *client, struct p9_req_t *req)
+{
+   return 0;
+}
+
+static int p9_xen_create(struct p9_client *client, const char *addr, char 
*args)
+{
+   return 0;
+}
+
+static void p9_xen_close(struct p9_client *client)
+{
+}
+
+static int p9_xen_request(struct p9_client *client, struct p9_req_t *p9_req)
+{
+   return 0;
+}
+
+static struct p9_trans_module p9_xen_trans = {
+   .name = "xen",
+   .maxsize = 1 << (XEN_9PFS_RING_ORDER + XEN_PAGE_SHIFT),
+   .def = 1,
+   .create = p9_xen_create,
+   .close = p9_xen_close,
+   .request = p9_xen_request,
+   .cancel = p9_xen_cancel,
+   .owner = THIS_MODULE,
+};
+
+static const struct xenbus_device_id xen_9pfs_front_ids[] = {
+   { "9pfs" },
+   { "" }
+};
+
+static int xen_9pfs_front_remove(struct xenbus_device *dev)
+{
+   return 0;
+}
+
+static int xen_9pfs_front_probe(struct xenbus_device *dev,
+   const struct xenbus_device_id *id)
+{
+   return 0;
+}
+
+static int xen_9pfs_front_resume(struct xenbus_device *dev)
+{
+   return 0;
+}
+
+static void xen_9pfs_front_changed(struct xenbus_device *dev,
+  enum xenbus_state backend_state)
+{
+}
+
+static struct xenbus_driver xen_9pfs_front_driver = {
+   .ids = xen_9pfs_front_ids,
+   .probe = xen_9pfs_front_probe,
+   .remove = xen_9pfs_front_remove,
+   .resume = xen_9pfs_front_resume,
+   .otherend_changed = xen_9pfs_front_changed,
+};
+
+int p9_trans_xen_init(void)
+{
+   if (!xen_domain())
+   return -ENODEV;
+
+   pr_info("Initialising Xen transport for 9pfs\n");
+
+   v9fs_register_trans(_xen_trans);
+   return xenbus_register_frontend(_9pfs_front_driver);
+}
+module_init(p9_trans_xen_init);
+
+void p9_trans_xen_exit(void)
+{
+   v9fs_unregister_trans(_xen_trans);
+   return xenbus_unregister_driver(_9pfs_front_driver);
+}
+module_exit(p9_trans_xen_exit);
-- 
1.9.1


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

[Xen-devel] [PATCH v5 1/7] xen: import new ring macros in ring.h

[Stefano Stabellini]

Sync the ring.h file with upstream Xen, to introduce the new ring macros.
They will be used by the Xen transport for 9pfs.

Signed-off-by: Stefano Stabellini 
CC: konrad.w...@oracle.com
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
CC: gr...@kaod.org

---
NB: The new macros have not been committed to Xen yet. Do not apply this
patch until they do.
---
---
 include/xen/interface/io/ring.h | 131 
 1 file changed, 131 insertions(+)

diff --git a/include/xen/interface/io/ring.h b/include/xen/interface/io/ring.h
index 21f4fbd..500e68d 100644
--- a/include/xen/interface/io/ring.h
+++ b/include/xen/interface/io/ring.h
@@ -283,4 +283,135 @@ struct __name##_back_ring {   
\
 (_work_to_do) = RING_HAS_UNCONSUMED_RESPONSES(_r); \
 } while (0)
 
+
+/*
+ * DEFINE_XEN_FLEX_RING_AND_INTF defines two monodirectional rings and
+ * functions to check if there is data on the ring, and to read and
+ * write to them.
+ *
+ * DEFINE_XEN_FLEX_RING is similar to DEFINE_XEN_FLEX_RING_AND_INTF, but
+ * does not define the indexes page. As different protocols can have
+ * extensions to the basic format, this macro allow them to define their
+ * own struct.
+ *
+ * XEN_FLEX_RING_SIZE
+ *   Convenience macro to calculate the size of one of the two rings
+ *   from the overall order.
+ *
+ * $NAME_mask
+ *   Function to apply the size mask to an index, to reduce the index
+ *   within the range [0-size].
+ *
+ * $NAME_read_packet
+ *   Function to read data from the ring. The amount of data to read is
+ *   specified by the "size" argument.
+ *
+ * $NAME_write_packet
+ *   Function to write data to the ring. The amount of data to write is
+ *   specified by the "size" argument.
+ *
+ * $NAME_get_ring_ptr
+ *   Convenience function that returns a pointer to read/write to the
+ *   ring at the right location.
+ *
+ * $NAME_data_intf
+ *   Indexes page, shared between frontend and backend. It also
+ *   contains the array of grant refs.
+ *
+ * $NAME_queued
+ *   Function to calculate how many bytes are currently on the ring,
+ *   ready to be read. It can also be used to calculate how much free
+ *   space is currently on the ring (ring_size - $NAME_queued()).
+ */
+#define XEN_FLEX_RING_SIZE(order) \
+(1UL << (order + XEN_PAGE_SHIFT - 1))
+
+#define DEFINE_XEN_FLEX_RING_AND_INTF(name)   \
+struct name##_data_intf { \
+RING_IDX in_cons, in_prod;\
+  \
+uint8_t pad1[56]; \
+  \
+RING_IDX out_cons, out_prod;  \
+  \
+uint8_t pad2[56]; \
+  \
+RING_IDX ring_order;  \
+grant_ref_t ref[];\
+};\
+DEFINE_XEN_FLEX_RING(name);
+
+#define DEFINE_XEN_FLEX_RING(name)\
+static inline RING_IDX name##_mask(RING_IDX idx, RING_IDX ring_size)  \
+{ \
+return (idx & (ring_size - 1));   \
+} \
+  \
+static inline RING_IDX name##_mask_order(RING_IDX idx, RING_IDX ring_order)   \
+{ \
+return (idx & (XEN_FLEX_RING_SIZE(ring_order) - 1));  \
+} \
+  \
+static inline unsigned char* name##_get_ring_ptr(unsigned char *buf,  \
+ RING_IDX idx,\
+ RING_IDX ring_order) \
+{ \
+return buf + name##_mask_order(idx, ring_order);  \
+} \
+  \
+static inline void 

[Xen-devel] [PATCH v5 0/7] Xen transport for 9pfs frontend driver

[Stefano Stabellini]

Hi all,

This patch series implements a new transport for 9pfs, aimed at Xen
systems.

The transport is based on a traditional Xen frontend and backend drivers
pair. This patch series implements the frontend, which typically runs in
a regular unprivileged guest.

I also sent a series that implements the backend in userspace in QEMU,
which typically runs in Dom0 (but could also run in a another guest).

The frontend complies to the Xen transport for 9pfs specification
version 1, available here:

https://xenbits.xen.org/docs/unstable/misc/9pfs.html


Changes in v5:
- test priv->tag instead of ret
- run checkpatch.pl against the whole series, fix all issues
- set intf->ring_order appropriately
- use shorter link to 9pfs spec

Changes in v4:
- code style improvements
- use xenbus_read_unsigned when possible
- do not leak "versions"
- introduce BUILD_BUG_ON
- introduce rwlock to protect the xen_9pfs_devs list
- add review-by

Changes in v3:
- add full copyright header to trans_xen.c
- rename ring->ring to ring->data
- handle gnttab_grant_foreign_access errors
- remove ring->bytes
- wrap long lines
- add reviewed-by

Changes in v2:
- use XEN_PAGE_SHIFT instead of PAGE_SHIFT
- remove unnecessary initializations
- fix error paths
- fix memory allocations for 64K kernels
- simplify p9_xen_create and p9_xen_close
- use virt_XXX barriers
- set status = REQ_STATUS_ERROR inside the p9_xen_response loop
- add in-code comments


Stefano Stabellini (7):
  xen: import new ring macros in ring.h
  xen: introduce the header file for the Xen 9pfs transport protocol
  xen/9pfs: introduce Xen 9pfs transport driver
  xen/9pfs: connect to the backend
  xen/9pfs: send requests to the backend
  xen/9pfs: receive responses
  xen/9pfs: build 9pfs Xen transport driver

 include/xen/interface/io/9pfs.h |  42 
 include/xen/interface/io/ring.h | 131 ++
 net/9p/Kconfig  |   8 +
 net/9p/Makefile |   4 +
 net/9p/trans_xen.c  | 541 
 5 files changed, 726 insertions(+)
 create mode 100644 include/xen/interface/io/9pfs.h
 create mode 100644 net/9p/trans_xen.c

Cheers,

Stefano

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

Re: [Xen-devel] [PATCH v4 01/14] golang/xenlight: Create stub package

[George Dunlap]

On Thu, Mar 16, 2017 at 7:08 PM, Ronald Rojas  wrote:
> Create a basic Makefile to build and install libxenlight Golang
> bindings. Also add a stub package which only opens libxl context.
>
> Include a global xenlight.Ctx variable which can be used as the
> default context by the entire program if desired.
>
> For now, return simple errors. Proper error handling will be
> added in next patch.
>
> Signed-off-by: Ronald Rojas 
> Signed-off-by: George Dunlap 
> ---
>
> Changes:
>
> - Added global logger variable and destroyed the logger instance
> when closing the context.
>
> - Whitespace fixes
>
> - Commented out CONFIG_GOLANG

> +# Go will do its own dependency checking, and not actuall go through
> +# with the build if none of the input files have changed.
> +#
> +# NB that because the users of this library need to be able to
> +# recompile the library from source, it needs to include '-lxenlight'
> +# in the LDFLAGS; and thus we need to add -L$(XEN_XENLIGHT) here
> +# so that it can find the actual library.
> +.PHONY: build
> +build: package
> +   CGO_CFLAGS="$(CFLAGS_libxenlight) $(CFLAGS_libxentoollog)" 
> CGO_LDFLAGS="$(LDLIBS_libxenlight) $(LDLIBS_libxentoollog)-L$(XEN_XENLIGHT) 
> -L$(XEN_LIBXENTOOLLOG)" GOPATH=$(XEN_GOPATH) $(GO) install -x 
> $(XEN_GOCODE_URL)/xenlight

Also, you're missing a space between `$(LDLIBS_libxentoollog)` and
`-L$(XEN_XENLIGHT)`.  In the future please at least compile-test your
code.

Thanks,
 -George

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

[Xen-devel] [PATCH v2 2/3] Introduce the Xen 9pfs transport header

[Stefano Stabellini]

Define the ring according to the protocol specification, using the new
DEFINE_XEN_FLEX_RING_AND_INTF macro.

Signed-off-by: Stefano Stabellini 
CC: konrad.w...@oracle.com
---
 xen/include/public/io/9pfs.h | 57 
 1 file changed, 57 insertions(+)
 create mode 100644 xen/include/public/io/9pfs.h

diff --git a/xen/include/public/io/9pfs.h b/xen/include/public/io/9pfs.h
new file mode 100644
index 000..bff9ad8
--- /dev/null
+++ b/xen/include/public/io/9pfs.h
@@ -0,0 +1,57 @@
+/*
+ * 9pfs.h -- Xen 9PFS transport
+ *
+ * Refer to docs/misc/9pfs.markdown for the specification
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (C) 2017 Stefano Stabellini 
+ */
+
+#ifndef __XEN_PUBLIC_IO_9PFS_H__
+#define __XEN_PUBLIC_IO_9PFS_H__
+
+#include "ring.h"
+
+/*
+ * See docs/misc/9pfs.markdown in xen.git for the full specification:
+ * https://xenbits.xen.org/docs/unstable/misc/9pfs.html
+ */
+#pragma pack(push)
+#pragma pack(1)
+struct xen_9pfs_header {
+   uint32_t size;
+   uint8_t id;
+   uint16_t tag;
+};
+#pragma pack(pop)
+
+DEFINE_XEN_FLEX_RING_AND_INTF(xen_9pfs);
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.9.1


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

[Xen-devel] [PATCH v2 1/3] [RESEND] ring.h: introduce macros to handle monodirectional rings with multiple req sizes

[Stefano Stabellini]

This patch introduces macros, structs and functions to handle rings in
the format described by docs/misc/pvcalls.markdown and
docs/misc/9pfs.markdown. The index page (struct __name##_data_intf)
contains the indexes and the grant refs to setup two rings.

   Indexes page
   +--+
   |@0 $NAME_data_intf:   |
   |@76: ring_order = 1   |
   |@80: ref[0]+  |
   |@84: ref[1]+  |
   |   |  |
   |   |  |
   +--+
   |
   v (data ring)
   +---+---+
   |  @0->4098: in |
   |  ref[0]   |
   |---|
   |  @4099->8196: out |
   |  ref[1]   |
   +---+

$NAME_read_packet and $NAME_write_packet are provided to read or write
any data struct from/to the ring. In pvcalls, they are unused. In xen
9pfs, they are used to read or write the 9pfs header. In other protocols
they could be used to read/write the whole request structure. See
docs/misc/9pfs.markdown:Ring Usage to learn how to check how much data
is on the ring, and how to handle notifications.

There is a ring_size parameter to most functions so that protocols using
these macros don't have to have a statically defined ring order at build
time. In pvcalls for example, each new ring could have a different
order.

These macros don't help you share the indexes page or the event channels
needed for notifications. You can do that with other out of band
mechanisms, such as xenstore or another ring.

It is not possible to use a macro to define another macro with a
variable name. For this reason, this patch introduces static inline
functions instead, that are not C89 compliant. Additionally, the macro
defines a struct with a variable sized array, which is also not C89
compliant.

Signed-off-by: Stefano Stabellini 
CC: konrad.w...@oracle.com

---
Changes in v4:
- remove packet_t, use void* and size instead

Changes in v3:
- mention C89 compliance breakages
- constify parameters
- use unsigned chars for buffers
- add two macros, one doesn't define the struct

Changes in v2:
- fix typo
- remove leading underscores from names
- use UL
- do not parenthesize parameters
- code readability improvements

Give a look at the following branch to see how they are used with
pvcalls and xen-9pfs (the drivers are still work in progress):

git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git 9pfs-async-v7
---
---
 xen/include/public/io/ring.h | 131 +++
 1 file changed, 131 insertions(+)

diff --git a/xen/include/public/io/ring.h b/xen/include/public/io/ring.h
index 801c0da..8ac9ca3 100644
--- a/xen/include/public/io/ring.h
+++ b/xen/include/public/io/ring.h
@@ -313,6 +313,137 @@ typedef struct __name##_back_ring __name##_back_ring_t
 (_work_to_do) = RING_HAS_UNCONSUMED_RESPONSES(_r);  \
 } while (0)
 
+
+/*
+ * DEFINE_XEN_FLEX_RING_AND_INTF defines two monodirectional rings and
+ * functions to check if there is data on the ring, and to read and
+ * write to them.
+ *
+ * DEFINE_XEN_FLEX_RING is similar to DEFINE_XEN_FLEX_RING_AND_INTF, but
+ * does not define the indexes page. As different protocols can have
+ * extensions to the basic format, this macro allow them to define their
+ * own struct.
+ *
+ * XEN_FLEX_RING_SIZE
+ *   Convenience macro to calculate the size of one of the two rings
+ *   from the overall order.
+ *
+ * $NAME_mask
+ *   Function to apply the size mask to an index, to reduce the index
+ *   within the range [0-size].
+ *
+ * $NAME_read_packet
+ *   Function to read data from the ring. The amount of data to read is
+ *   specified by the "size" argument.
+ *
+ * $NAME_write_packet
+ *   Function to write data to the ring. The amount of data to write is
+ *   specified by the "size" argument.
+ *
+ * $NAME_get_ring_ptr
+ *   Convenience function that returns a pointer to read/write to the
+ *   ring at the right location.
+ *
+ * $NAME_data_intf
+ *   Indexes page, shared between frontend and backend. It also
+ *   contains the array of grant refs.
+ *
+ * $NAME_queued
+ *   Function to calculate how many bytes are currently on the ring,
+ *   ready to be read. It can also be used to calculate how much free
+ *   space is currently on the ring (ring_size - $NAME_queued()).
+ */
+#define XEN_FLEX_RING_SIZE(order) \
+(1UL << (order + PAGE_SHIFT - 1))
+
+#define DEFINE_XEN_FLEX_RING_AND_INTF(name)   \
+struct name##_data_intf { \
+RING_IDX in_cons, in_prod;\
+  

[Xen-devel] [PATCH v2 0/3] new ring macros, 9pfs and pvcalls headers

[Stefano Stabellini]

Hi all,

this patch series introduces a set of new ring macros to support rings
in the formats specified by the Xen 9pfs transport and PV Calls
protocol. It also introduces the Xen 9pfs and PV Calls protocols
headers.


Changes in v2:
- replace __attribute__((packed)) with #pragma pack
- remove XEN_9PFS_RING_ORDER, the 9pfs ring order should be dynamic
- add editor configuration blocks
- add links to the specs


Stefano Stabellini (3):
  [RESEND] ring.h: introduce macros to handle monodirectional rings with 
multiple req sizes
  Introduce the Xen 9pfs transport header
  Introduce the pvcalls header

 xen/include/public/io/9pfs.h|  57 +++
 xen/include/public/io/pvcalls.h | 152 
 xen/include/public/io/ring.h| 131 ++
 3 files changed, 340 insertions(+)
 create mode 100644 xen/include/public/io/9pfs.h
 create mode 100644 xen/include/public/io/pvcalls.h


Cheers,

Stefano

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

Re: [Xen-devel] [PATCH v4 05/14] golang/xenlight: Add tests host related functionality functions

[George Dunlap]

On Thu, Mar 16, 2017 at 7:08 PM, Ronald Rojas  wrote:
> Create tests for the following functions:
> - GetVersionInfo
> - GetPhysinfo
> - GetDominfo
> - GetMaxCpus
> - GetOnlineCpus
> - GetMaxNodes
> - GetFreeMemory
>
> Signed-off-by: Ronald Rojas 
> Signed-off-by: George Dunlap 
>
> ---
> changes since last version
>
> - created CFLAGS and LDLIBS variables to build test C
> files with required dependencies.
>
> - created create_context and destroy_context function
> for tests to create/destroy libxl_ctx and xenlogger
>
> - Formating changes
>
> - Removed stale comments
>
> - Removed redundant error checks in Golang tests
>
> - Negated printed error code in freememory.go

Looks a lot better, thanks!  Still some details that need to be corrected.

> diff --git a/tools/golang/xenlight/test/xeninfo/dominfo.go 
> b/tools/golang/xenlight/test/xeninfo/dominfo.go
> new file mode 100644
> index 000..bb9257b
> --- /dev/null
> +++ b/tools/golang/xenlight/test/xeninfo/dominfo.go
> @@ -0,0 +1,31 @@
> +package main
> +
> +import (
> +   "fmt"
> +   "os"
> +   "xenproject.org/xenlight"

This needs to be changed to use the new name:
golang.xenproject.org/xenlight (in all the .go files).

Also, please do at least a build test for each patch before you send it.

> +)
> +
> +func main() {
> +   ctx := xenlight.Ctx
> +   err := ctx.Open()
> +   if err != nil {
> +   os.Exit(-1)
> +   }
> +   defer ctx.Close()
> +   info, err := ctx.DomainInfo(0)

Just noticed -- in this case, if DomainInfo fails, you simply exit
without printing anything (both for golang and the C versions); but in
most of the other cases, you actually print the return value.

Is there a reason not to print the error value here, but to print it
for the others?

> +   if err != nil {
> +   os.Exit(-1)
> +   }
> +
> +   fmt.Printf("%d\n%d\n", info.Domid, info.Ssidref)
> +   //fmt.Printf("%s\n", info.SsidLabel)

Again, why is there a line here that's commented out?  (I asked this
last time and I didn't see a response.)


> diff --git a/tools/golang/xenlight/test/xeninfo/freememory.go 
> b/tools/golang/xenlight/test/xeninfo/freememory.go
> new file mode 100644
> index 000..2752bd3
> --- /dev/null
> +++ b/tools/golang/xenlight/test/xeninfo/freememory.go
> @@ -0,0 +1,25 @@
> +package main
> +
> +import (
> +   "fmt"
> +   "os"
> +   "xenproject.org/xenlight"
> +)
> +
> +func main() {
> +   ctx := xenlight.Ctx
> +   err := ctx.Open()
> +   if err != nil {
> +   os.Exit(-1)
> +   }
> +
> +   defer ctx.Close()
> +
> +   free_memory, err := ctx.GetFreeMemory()
> +   if err != nil {
> +   fmt.Printf("-%d\n", err)

Hmm, so this isn't quite right.  First of all, normally you'd try to
negate the actual value, rather than just adding a '-' in front of it;
but of course you can't do that simply here because err is an
interface of type 'error'; but that shows the other way this code is a
bit fragile, in that it assumes that GetFreeMemory() will return an
error of type xenlight.Error, and not (say) some other kind of error
-- even though we actually return the results of fmt.Errorf()
occasionally (at least for some methods).

I think even for this kind of testing code, it would be better to do a
type assertion, thus:

if err != nil {
val, ok := err.(xenlight.Error)
if ! ok {
fmt.Printf("Error %v\n", err)
} else {
fmt.Printf("%d\n", -val)
}
}

Also, you need to do this for all the tests which attempt to print the
return value of the error.

Alternately, you could make all the unit tests behave like dominfo.*,
and simply exit without comment on an error.

> diff --git a/tools/golang/xenlight/test/xeninfo/print.h 
> b/tools/golang/xenlight/test/xeninfo/print.h
> new file mode 100644
> index 000..dd6c987
> --- /dev/null
> +++ b/tools/golang/xenlight/test/xeninfo/print.h
> @@ -0,0 +1,22 @@
> +xentoollog_logger_stdiostream *logger;

So here you define (rather than "declare") a global variable in a
header file.  This is generally frowned upon, and usually indicates
that you need to restructure the code somewhat.

I had a chat with Ian Jackson, and we agreed that it would be better
to create a file, maybe "test-common.c", that would contain this
variable, as well as the three functions below.

Then the header ("test-common.h") would contain *declarations* of the
variable (i.e., "extern xentoollog_logger_stdiostream *logger;") and
function prototypes.

The test-common.c file is small now, but it may grow as additional
functionality is needed.

The other thing you might consider, to further reduce the boilerplate
you have in each unit test file, is to also include a libxl_ctx
pointer in test-common; and have create_context() simply return an int
(0 for success, -1 for failure).

> +
> +static inline char 

[Xen-devel] [PATCH v2 3/3] Introduce the pvcalls header

[Stefano Stabellini]

Define the ring and request and response structs according to the
specification. Use the new DEFINE_XEN_FLEX_RING macro.

Signed-off-by: Stefano Stabellini 
CC: konrad.w...@oracle.com
---
 xen/include/public/io/pvcalls.h | 152 
 1 file changed, 152 insertions(+)
 create mode 100644 xen/include/public/io/pvcalls.h

diff --git a/xen/include/public/io/pvcalls.h b/xen/include/public/io/pvcalls.h
new file mode 100644
index 000..4123528
--- /dev/null
+++ b/xen/include/public/io/pvcalls.h
@@ -0,0 +1,152 @@
+/*
+ * pvcalls.h -- Xen PV Calls Protocol
+ *
+ * Refer to docs/misc/pvcalls.markdown for the specification
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (C) 2017 Stefano Stabellini 
+ */
+
+#ifndef __XEN_PUBLIC_IO_PVCALLS_H__
+#define __XEN_PUBLIC_IO_PVCALLS_H__
+
+#include "ring.h"
+
+/*
+ * See docs/misc/pvcalls.markdown in xen.git for the full specification:
+ * https://xenbits.xen.org/docs/unstable/misc/pvcalls.html
+ */
+struct pvcalls_data_intf {
+RING_IDX in_cons, in_prod, in_error;
+
+uint8_t pad1[52];
+
+RING_IDX out_cons, out_prod, out_error;
+
+uint8_t pad2[52];
+
+RING_IDX ring_order;
+grant_ref_t ref[];
+};
+DEFINE_XEN_FLEX_RING(pvcalls);
+
+#define PVCALLS_SOCKET 0
+#define PVCALLS_CONNECT1
+#define PVCALLS_RELEASE2
+#define PVCALLS_BIND   3
+#define PVCALLS_LISTEN 4
+#define PVCALLS_ACCEPT 5
+#define PVCALLS_POLL   6
+
+struct xen_pvcalls_request {
+uint32_t req_id; /* private to guest, echoed in response */
+uint32_t cmd;/* command to execute */
+union {
+struct xen_pvcalls_socket {
+uint64_t id;
+uint32_t domain;
+uint32_t type;
+uint32_t protocol;
+} socket;
+struct xen_pvcalls_connect {
+uint64_t id;
+uint8_t addr[28];
+uint32_t len;
+uint32_t flags;
+grant_ref_t ref;
+uint32_t evtchn;
+} connect;
+struct xen_pvcalls_release {
+uint64_t id;
+uint8_t reuse;
+} release;
+struct xen_pvcalls_bind {
+uint64_t id;
+uint8_t addr[28];
+uint32_t len;
+} bind;
+struct xen_pvcalls_listen {
+uint64_t id;
+uint32_t backlog;
+} listen;
+struct xen_pvcalls_accept {
+uint64_t id;
+uint64_t id_new;
+grant_ref_t ref;
+uint32_t evtchn;
+} accept;
+struct xen_pvcalls_poll {
+uint64_t id;
+} poll;
+/* dummy member to force sizeof(struct xen_pvcalls_request)
+ * to match across archs */
+struct xen_pvcalls_dummy {
+uint8_t dummy[56];
+} dummy;
+} u;
+};
+
+struct xen_pvcalls_response {
+uint32_t req_id;
+uint32_t cmd;
+int32_t ret;
+uint32_t pad;
+union {
+struct _xen_pvcalls_socket {
+uint64_t id;
+} socket;
+struct _xen_pvcalls_connect {
+uint64_t id;
+} connect;
+struct _xen_pvcalls_release {
+uint64_t id;
+} release;
+struct _xen_pvcalls_bind {
+uint64_t id;
+} bind;
+struct _xen_pvcalls_listen {
+uint64_t id;
+} listen;
+struct _xen_pvcalls_accept {
+uint64_t id;
+} accept;
+struct _xen_pvcalls_poll {
+uint64_t id;
+} poll;
+struct _xen_pvcalls_dummy {
+uint8_t dummy[8];
+} dummy;
+} u;
+};
+
+DEFINE_RING_TYPES(xen_pvcalls, struct xen_pvcalls_request,
+  struct xen_pvcalls_response);
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * 

Re: [Xen-devel] [PATCH v2 3/3] x86emul: correct FPU code/data pointers and opcode handling

[Andrew Cooper]

On 15/03/17 10:28, Jan Beulich wrote:
> Prevent leaking the hypervisor ones (stored by hardware during stub
> execution), at once making sure the guest sees correct values there.
> This piggybacks on the backout logic used to deal with write faults of
> FPU insns.
>
> Deliberately ignore the NO_FPU_SEL feature here: Honoring it would
> merely mean extra code with no benefit (once we XRSTOR state, the
> selector values will simply be lost anyway).
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v2 1/3] x86emul: centralize put_fpu() invocations

[Andrew Cooper]

On 15/03/17 10:27, Jan Beulich wrote:
> ..., splitting parts of it into check_*() macros. This is in
> preparation of making ->put_fpu() do further adjustments to register
> state. (Some of the check_xmm() invocations could be avoided, as in
> some of the cases no insns handled there can actually raise #XM, but I
> think we're better off keeping them to avoid later additions of further
> insn patterns rendering the lack of the check a bug.)
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

[Xen-devel] [PATCH v2 1/6] x86/viridian: fix xen-hvmcrash when vp_assist page is present

[Paul Durrant]

Currently use of xen-hvmcrash will cause an immediate domain_crash() in
initialize_vp_assist() because it is called from viridian_load_vcpu_ctxt()
without having first cleared any previous mapping.

This patch addes a check into viridian_load_vcpu_ctxt() to avoid re-
initialization and turned the domain_crash() in initialize_vp_assist()
into an ASSERT() since neither codepath into that function should allow
it to be hit.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 

v2:
 - Patch significantly simplified
---
 xen/arch/x86/hvm/viridian.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/viridian.c b/xen/arch/x86/hvm/viridian.c
index f2c9613..3a2611b 100644
--- a/xen/arch/x86/hvm/viridian.c
+++ b/xen/arch/x86/hvm/viridian.c
@@ -283,6 +283,8 @@ static void initialize_vp_assist(struct vcpu *v)
 struct page_info *page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
 void *va;
 
+ASSERT(!v->arch.hvm_vcpu.viridian.vp_assist.va);
+
 /*
  * See section 7.8.7 of the specification for details of this
  * enlightenment.
@@ -904,7 +906,8 @@ static int viridian_load_vcpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 return -EINVAL;
 
 v->arch.hvm_vcpu.viridian.vp_assist.msr.raw = ctxt.vp_assist_msr;
-if ( v->arch.hvm_vcpu.viridian.vp_assist.msr.fields.enabled )
+if ( v->arch.hvm_vcpu.viridian.vp_assist.msr.fields.enabled &&
+ !v->arch.hvm_vcpu.viridian.vp_assist.va )
 initialize_vp_assist(v);
 
 v->arch.hvm_vcpu.viridian.vp_assist.vector = ctxt.vp_assist_vector;
-- 
2.1.4


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

[Xen-devel] [PATCH v2 0/6] viridian updates

[Paul Durrant]

Only 6 patches now...

Paul Durrant (6):
  x86/viridian: fix xen-hvmcrash when vp_assist page is present
  x86/viridian: don't put Xen version information in CPUID leaf 2
  x86/viridian: get rid of the magic numbers in CPUID leaves 1 and 2
  x86/viridian: add warnings for unimplemented hypercalls and MSRs
  x86/viridian: make the threshold for HvNotifyLongSpinWait tunable
  x86/viridian: implement the crash MSRs

 docs/man/xl.cfg.pod.5.in|  10 +-
 docs/misc/xen-command-line.markdown |  29 +
 tools/libxl/libxl.h |   6 +
 tools/libxl/libxl_dom.c |   4 +
 tools/libxl/libxl_types.idl |   1 +
 xen/arch/x86/hvm/viridian.c | 222 
 xen/include/asm-x86/hvm/viridian.h  |   1 +
 xen/include/public/hvm/params.h |   7 +-
 8 files changed, 255 insertions(+), 25 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH v2 4/6] x86/viridian: add warnings for unimplemented hypercalls and MSRs

[Paul Durrant]

These warnings can be useful when Microsoft updates Windows.

In the past there have been several cases when Windows erroneously uses
hypercalls and MSRs that should be gated on CPUID flags than Xen does
not set. The usual symptom is a guest crash with little or no information
in the hypervisor log. Adding these warnings at least gives a clue as to
what might be happening in such cases.

Some versions of Windows do currently issue hypercalls that they should
not, so this patch whitelists those to avoid the warnings as the lack
of implementation is clearly proved not to be a problem to the guest.

The warnings are rate limited so a malicious guest cannot use them to
as a DoS.

NOTE: Because the MSR warnings need to be gated on range checking the
  MSR address this patch imports the up-to-date definitions of all
  the viridian MSRs from the specification.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 

v2:
 - Use gprintk() rather than gdprintk()
 - Further changes requested by Jan
---
 xen/arch/x86/hvm/viridian.c | 106 ++--
 1 file changed, 92 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/hvm/viridian.c b/xen/arch/x86/hvm/viridian.c
index 27ad5e8..d241de2 100644
--- a/xen/arch/x86/hvm/viridian.c
+++ b/xen/arch/x86/hvm/viridian.c
@@ -23,17 +23,73 @@
 #include 
 
 /* Viridian MSR numbers. */
-#define HV_X64_MSR_GUEST_OS_ID  0x4000
-#define HV_X64_MSR_HYPERCALL0x4001
-#define HV_X64_MSR_VP_INDEX 0x4002
-#define HV_X64_MSR_TIME_REF_COUNT   0x4020
-#define HV_X64_MSR_REFERENCE_TSC0x4021
-#define HV_X64_MSR_TSC_FREQUENCY0x4022
-#define HV_X64_MSR_APIC_FREQUENCY   0x4023
-#define HV_X64_MSR_EOI  0x4070
-#define HV_X64_MSR_ICR  0x4071
-#define HV_X64_MSR_TPR  0x4072
-#define HV_X64_MSR_VP_ASSIST_PAGE   0x4073
+#define HV_X64_MSR_GUEST_OS_ID   0x4000
+#define HV_X64_MSR_HYPERCALL 0x4001
+#define HV_X64_MSR_VP_INDEX  0x4002
+#define HV_X64_MSR_RESET 0x4003
+#define HV_X64_MSR_VP_RUNTIME0x4010
+#define HV_X64_MSR_TIME_REF_COUNT0x4020
+#define HV_X64_MSR_REFERENCE_TSC 0x4021
+#define HV_X64_MSR_TSC_FREQUENCY 0x4022
+#define HV_X64_MSR_APIC_FREQUENCY0x4023
+#define HV_X64_MSR_EOI   0x4070
+#define HV_X64_MSR_ICR   0x4071
+#define HV_X64_MSR_TPR   0x4072
+#define HV_X64_MSR_VP_ASSIST_PAGE0x4073
+#define HV_X64_MSR_SCONTROL  0x4080
+#define HV_X64_MSR_SVERSION  0x4081
+#define HV_X64_MSR_SIEFP 0x4082
+#define HV_X64_MSR_SIMP  0x4083
+#define HV_X64_MSR_EOM   0x4084
+#define HV_X64_MSR_SINT0 0x4090
+#define HV_X64_MSR_SINT1 0x4091
+#define HV_X64_MSR_SINT2 0x4092
+#define HV_X64_MSR_SINT3 0x4093
+#define HV_X64_MSR_SINT4 0x4094
+#define HV_X64_MSR_SINT5 0x4095
+#define HV_X64_MSR_SINT6 0x4096
+#define HV_X64_MSR_SINT7 0x4097
+#define HV_X64_MSR_SINT8 0x4098
+#define HV_X64_MSR_SINT9 0x4099
+#define HV_X64_MSR_SINT100x409A
+#define HV_X64_MSR_SINT110x409B
+#define HV_X64_MSR_SINT120x409C
+#define HV_X64_MSR_SINT130x409D
+#define HV_X64_MSR_SINT140x409E
+#define HV_X64_MSR_SINT150x409F
+#define HV_X64_MSR_STIMER0_CONFIG0x40B0
+#define HV_X64_MSR_STIMER0_COUNT 0x40B1
+#define HV_X64_MSR_STIMER1_CONFIG0x40B2
+#define HV_X64_MSR_STIMER1_COUNT 0x40B3
+#define HV_X64_MSR_STIMER2_CONFIG0x40B4
+#define HV_X64_MSR_STIMER2_COUNT 0x40B5
+#define HV_X64_MSR_STIMER3_CONFIG0x40B6
+#define HV_X64_MSR_STIMER3_COUNT 0x40B7
+#define HV_X64_MSR_POWER_STATE_TRIGGER_C10x40C1
+#define HV_X64_MSR_POWER_STATE_TRIGGER_C20x40C2
+#define HV_X64_MSR_POWER_STATE_TRIGGER_C30x40C3
+#define HV_X64_MSR_POWER_STATE_CONFIG_C1 0x40D1
+#define HV_X64_MSR_POWER_STATE_CONFIG_C2 0x40D2
+#define 

[Xen-devel] [PATCH v2 6/6] x86/viridian: implement the crash MSRs

[Paul Durrant]

Section 2.4.4 of the Hypervisor Top Level Functional Specification states
that enabling bit 10 in EDX of CPUID leaf 3 advertises to Windows a set
of MSRs into which it can write crash information.

This patch advertises that bit and implements the MSRs such that Xen can
log the information if a Windows guest crashes.

Signed-off-by: Paul Durrant 
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Paul Durrant 
Cc: Jan Beulich 
Cc: Andrew Cooper 

v2:
 - Make MSRs per-vcpu rather than per-domain
 - Fix hypervisor stack leak
 - Replicate BUILD_BOG_ON()
 - Use gprintk() rather than printk()
---
 docs/man/xl.cfg.pod.5.in   | 10 --
 tools/libxl/libxl.h|  6 
 tools/libxl/libxl_dom.c|  4 +++
 tools/libxl/libxl_types.idl|  1 +
 xen/arch/x86/hvm/viridian.c| 69 ++
 xen/include/asm-x86/hvm/viridian.h |  1 +
 xen/include/public/hvm/params.h|  7 +++-
 7 files changed, 95 insertions(+), 3 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index 52802d5..991960b 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -1601,11 +1601,17 @@ per-vcpu event channel upcall vectors.
 Note that this enlightenment will have no effect if the guest is
 using APICv posted interrupts.
 
+=item B
+
+This group incorporates the crash control MSRs. These enlightenments
+allow Windows to write crash information such that it can be logged
+by Xen.
+
 =item B
 
 This is a special value that enables the default set of groups, which
-is currently the B, B, B and B
-groups.
+is currently the B, B, B, B
+and B groups.
 
 =item B
 
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 72ec39d..af45582 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -288,6 +288,12 @@
 #define LIBXL_HAVE_SCHED_CREDIT2_PARAMS 1
 
 /*
+ * LIBXL_HAVE_CRASH_CTL indicates that the 'crash_ctl' value
+ * is present in the viridian enlightenment enumeration.
+ */
+#define LIBXL_HAVE_CRASH_CTL 1
+
+/*
  * libxl ABI compatibility
  *
  * The only guarantee which libxl makes regarding ABI compatibility
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index e133962..c25cf48 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -214,6 +214,7 @@ static int hvm_set_viridian_features(libxl__gc *gc, 
uint32_t domid,
 libxl_bitmap_set(, LIBXL_VIRIDIAN_ENLIGHTENMENT_FREQ);
 libxl_bitmap_set(, 
LIBXL_VIRIDIAN_ENLIGHTENMENT_TIME_REF_COUNT);
 libxl_bitmap_set(, 
LIBXL_VIRIDIAN_ENLIGHTENMENT_APIC_ASSIST);
+libxl_bitmap_set(, 
LIBXL_VIRIDIAN_ENLIGHTENMENT_CRASH_CTL);
 }
 
 libxl_for_each_set_bit(v, info->u.hvm.viridian_enable) {
@@ -259,6 +260,9 @@ static int hvm_set_viridian_features(libxl__gc *gc, 
uint32_t domid,
 if (libxl_bitmap_test(, 
LIBXL_VIRIDIAN_ENLIGHTENMENT_APIC_ASSIST))
 mask |= HVMPV_apic_assist;
 
+if (libxl_bitmap_test(, 
LIBXL_VIRIDIAN_ENLIGHTENMENT_CRASH_CTL))
+mask |= HVMPV_crash_ctl;
+
 if (mask != 0 &&
 xc_hvm_param_set(CTX->xch,
  domid,
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 2475a4d..69e789a 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -224,6 +224,7 @@ libxl_viridian_enlightenment = 
Enumeration("viridian_enlightenment", [
 (3, "reference_tsc"),
 (4, "hcall_remote_tlb_flush"),
 (5, "apic_assist"),
+(6, "crash_ctl"),
 ])
 
 libxl_hdtype = Enumeration("hdtype", [
diff --git a/xen/arch/x86/hvm/viridian.c b/xen/arch/x86/hvm/viridian.c
index 5ca1167..c914ee8 100644
--- a/xen/arch/x86/hvm/viridian.c
+++ b/xen/arch/x86/hvm/viridian.c
@@ -154,6 +154,19 @@ typedef struct {
 uint64_t Reserved8:10;
 } HV_PARTITION_PRIVILEGE_MASK;
 
+typedef union _HV_CRASH_CTL_REG_CONTENTS
+{
+uint64_t AsUINT64;
+struct
+{
+uint64_t Reserved:63;
+uint64_t CrashNotify:1;
+};
+} HV_CRASH_CTL_REG_CONTENTS;
+
+/* Viridian CPUID leaf 3, Hypervisor Feature Indication */
+#define CPUID3D_CRASH_MSRS (1 << 10)
+
 /* Viridian CPUID leaf 4: Implementation Recommendations. */
 #define CPUID4A_HCALL_REMOTE_TLB_FLUSH (1 << 2)
 #define CPUID4A_MSR_BASED_APIC (1 << 3)
@@ -248,6 +261,10 @@ void cpuid_viridian_leaves(const struct vcpu *v, uint32_t 
leaf,
 
 res->a = u.lo;
 res->b = u.hi;
+
+if ( viridian_feature_mask(d) & HVMPV_crash_ctl )
+res->d = CPUID3D_CRASH_MSRS;
+
 break;
 }
 
@@ -619,6 +636,36 @@ int wrmsr_viridian_regs(uint32_t idx, uint64_t val)
 update_reference_tsc(d, 1);
 break;
 
+case HV_X64_MSR_CRASH_P0:
+case HV_X64_MSR_CRASH_P1:
+case HV_X64_MSR_CRASH_P2:
+case HV_X64_MSR_CRASH_P3:
+case HV_X64_MSR_CRASH_P4:
+BUILD_BUG_ON(HV_X64_MSR_CRASH_P4 - 

[Xen-devel] [PATCH v2 5/6] x86/viridian: make the threshold for HvNotifyLongSpinWait tunable

[Paul Durrant]

The current threshold before the guest issues the hypercall is, and always
has been, hard-coded to 2047. It is not clear where this number came
from so, to at least allow for ease of experimentation, this patch makes
the threshold tunable via the Xen command line.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 

v2:
 - Significantly simplify patch by directly initializing the parameter
---
 docs/misc/xen-command-line.markdown |  8 
 xen/arch/x86/hvm/viridian.c | 12 +++-
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 44da4bd..962e4d1 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1637,6 +1637,14 @@ The hypervisor minor version number encoded in CPUID 
0x4002:EBX.
 
 The hypervisor build number encoded in CPUID 0x4002:EAX.
 
+### viridian\_spinlock\_retry\_count
+> `= `
+
+> Default: `2047`
+
+Specify the maximum number of retries before an enlightened Windows
+guest will notify Xen that it has failed to acquire a spinlock.
+
 ### vpid (Intel)
 > `= `
 
diff --git a/xen/arch/x86/hvm/viridian.c b/xen/arch/x86/hvm/viridian.c
index d241de2..5ca1167 100644
--- a/xen/arch/x86/hvm/viridian.c
+++ b/xen/arch/x86/hvm/viridian.c
@@ -179,6 +179,10 @@ integer_param("viridian_minor_version", 
viridian_minor_version);
 static uint32_t __read_mostly viridian_build_number = 0x1772;
 integer_param("viridian_build_number", viridian_build_number);
 
+static uint32_t __read_mostly viridian_spinlock_retry_count = 2047;
+integer_param("viridian_spinlock_retry_count",
+  viridian_spinlock_retry_count);
+
 void cpuid_viridian_leaves(const struct vcpu *v, uint32_t leaf,
uint32_t subleaf, struct cpuid_leaf *res)
 {
@@ -257,7 +261,13 @@ void cpuid_viridian_leaves(const struct vcpu *v, uint32_t 
leaf,
 res->a |= CPUID4A_HCALL_REMOTE_TLB_FLUSH;
 if ( !cpu_has_vmx_apic_reg_virt )
 res->a |= CPUID4A_MSR_BASED_APIC;
-res->b = 2047; /* long spin count */
+
+/*
+ * This value is the recommended number of attempts to try to
+ * acquire a spinlock before notifying the hypervisor via the
+ * HvNotifyLongSpinWait hypercall.
+ */
+res->b = viridian_spinlock_retry_count;
 break;
 
 case 6:
-- 
2.1.4


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

[Xen-devel] [PATCH v2 2/6] x86/viridian: don't put Xen version information in CPUID leaf 2

[Paul Durrant]

The Hypervisor Top Level Functional Specification v5.0a states in section
2.5:

"The hypervisor version information is encoded in leaf 0x4002. Two
version numbers are provided: the main version and the service version.
The main version includes a major and minor version number and a build
number. These correspond to Microsoft Windows release numbers."

It also goes on to advise clients (i.e. guest versions of Windows) to use
the following algorithm to determine compatibility with the hypervisor
enlightenments:

if  greater than 
{
your version is compatible
}
else if  equal to  and
  greater than or equal to 
{
your version is compatible
}
else
{
your version is NOT compatible
}

So, clearly putting Xen hypervisor version information in that leaf is
spurious, but we probably get away with it because Xen's major version
is lower than the major version of Windows in which Hyper-V first
appeared (Server 2008).

This patch changes the leaf to use the kernel major and minor
versions, and build number from Windows Server 2008 (64-bit) by default.
These default values can be overriden from the Xen command line using new
'viridian_major_version', 'viridian_minor_version' and
'viridian_build_number' parameters.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 

v2:
 - Use full version information (including build number) from Windows
   Server 2008
 - Add command line parameters to allow version information to be
   overridden
---
 docs/misc/xen-command-line.markdown | 21 +
 xen/arch/x86/hvm/viridian.c | 20 ++--
 2 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index bad20db..44da4bd 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1616,6 +1616,27 @@ The optional `keep` parameter causes Xen to continue 
using the vga
 console even after dom0 has been started.  The default behaviour is to
 relinquish control to dom0.
 
+### viridian\_major\_version
+> `= `
+
+> Default: `6`
+
+The hypervisor major version number encoded in CPUID 0x4002:EBX.
+
+### viridian\_minor\_version
+> `= `
+
+> Default: `0`
+
+The hypervisor minor version number encoded in CPUID 0x4002:EBX.
+
+### viridian\_build\_number
+> `= `
+
+> Default: `0x1772`
+
+The hypervisor build number encoded in CPUID 0x4002:EAX.
+
 ### vpid (Intel)
 > `= `
 
diff --git a/xen/arch/x86/hvm/viridian.c b/xen/arch/x86/hvm/viridian.c
index 3a2611b..0d208c3 100644
--- a/xen/arch/x86/hvm/viridian.c
+++ b/xen/arch/x86/hvm/viridian.c
@@ -106,6 +106,21 @@ typedef struct {
 #define CPUID6A_MSR_BITMAPS (1 << 1)
 #define CPUID6A_NESTED_PAGING   (1 << 3)
 
+/*
+ * Version and build number reported by CPUID leaf 2
+ *
+ * These numbers are chosen to match the version numbers reported by
+ * Windows Server 2008.
+ */
+static uint16_t __read_mostly viridian_major_version = 6;
+integer_param("viridian_major_version", viridian_major_version);
+
+static uint16_t __read_mostly viridian_minor_version = 0;
+integer_param("viridian_minor_version", viridian_minor_version);
+
+static uint32_t __read_mostly viridian_build_number = 0x1772;
+integer_param("viridian_build_number", viridian_build_number);
+
 void cpuid_viridian_leaves(const struct vcpu *v, uint32_t leaf,
uint32_t subleaf, struct cpuid_leaf *res)
 {
@@ -134,8 +149,9 @@ void cpuid_viridian_leaves(const struct vcpu *v, uint32_t 
leaf,
own version number. */
 if ( d->arch.hvm_domain.viridian.guest_os_id.raw == 0 )
 break;
-res->a = 1; /* Build number */
-res->b = (xen_major_version() << 16) | xen_minor_version();
+res->a = viridian_build_number;
+res->b = ((uint32_t)viridian_major_version << 16) |
+ viridian_minor_version;
 res->c = 0; /* SP */
 res->d = 0; /* Service branch and number */
 break;
-- 
2.1.4


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

[Xen-devel] [PATCH v2 3/6] x86/viridian: get rid of the magic numbers in CPUID leaves 1 and 2

[Paul Durrant]

The numbers correspond to ASCII characters so just use appropriate
character strings directly.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 

v2:
 - Use memcpy() rather than cast-and-assign
---
 xen/arch/x86/hvm/viridian.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/hvm/viridian.c b/xen/arch/x86/hvm/viridian.c
index 0d208c3..27ad5e8 100644
--- a/xen/arch/x86/hvm/viridian.c
+++ b/xen/arch/x86/hvm/viridian.c
@@ -134,14 +134,16 @@ void cpuid_viridian_leaves(const struct vcpu *v, uint32_t 
leaf,
 switch ( leaf )
 {
 case 0:
+/* See section 2.4.1 of the specification */
 res->a = 0x4006; /* Maximum leaf */
-res->b = 0x7263694d; /* Magic numbers  */
-res->c = 0x666F736F;
-res->d = 0x76482074;
+memcpy(>b, "Micr", 4);
+memcpy(>c, "osof", 4);
+memcpy(>d, "t Hv", 4);
 break;
 
 case 1:
-res->a = 0x31237648; /* Version number */
+/* See section 2.4.2 of the specification */
+memcpy(>a, "Hv#1", 4);
 break;
 
 case 2:
-- 
2.1.4


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

Re: [Xen-devel] [PATCH 6/7] x86/viridian: make the threshold for HvNotifyLongSpinWait tunable

[Paul Durrant]

> -Original Message-
> From: Andrew Cooper
> Sent: 20 March 2017 17:03
> To: Paul Durrant ; xen-de...@lists.xenproject.org
> Cc: Jan Beulich 
> Subject: Re: [PATCH 6/7] x86/viridian: make the threshold for
> HvNotifyLongSpinWait tunable
> 
> On 17/03/17 09:57, Paul Durrant wrote:
> > The current threshold before the guest issues the hypercall is, and always
> > has been, hard-coded to 2047. It is not clear where this number came
> > from so, to at least allow for ease of experimentation, this patch makes
> > the threshold tunable via the Xen command line.
> >
> > Signed-off-by: Paul Durrant 
> 
> This is one example of a configuration option which I'd prefer to see
> done with the (planned) new CPUID interface.
> 
> The value here doesn't have any impact on the hypervisor, so a
> configuration option is free to be chosen entirely by the toolstack, and
> would also become inherently per-domain configuration rather than global.
> 
> Can I talk you into deferring this change until the CPUID interface is
> sorted, to avoid introducing yet another command line option?
> 

I don't really want to wait for something with no definite timescale. I don't 
see any harm in adding this and then stating it can be overridden by per-domain 
CPU policy later on. Presumably there's a bunch of other stuff where this would 
be the case.

  Paul

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

Re: [Xen-devel] [PATCH v8 1/5] x86/ioreq server: Release the p2m lock after mmio is handled.

[Jan Beulich]

>>> On 18.03.17 at 11:53,  wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1870,18 +1870,14 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned 
> long gla,
>   (npfec.write_access &&
>(p2m_is_discard_write(p2mt) || (p2mt == p2m_ioreq_server))) )
>  {
> -__put_gfn(p2m, gfn);
> -if ( ap2m_active )
> -__put_gfn(hostp2m, gfn);
> -
>  rc = 0;
>  if ( unlikely(is_pvh_domain(currd)) )
> -goto out;
> +goto out_put_gfn;

Did you forget to re-base onto staging before you've sent this?
is_pvh_domain() was gone before your submission already. When
re-basing, feel free to also drop the dead "rc = 0;" line.

Jan


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

Re: [Xen-devel] [PATCH 6/7] x86/viridian: make the threshold for HvNotifyLongSpinWait tunable

[Andrew Cooper]

On 17/03/17 09:57, Paul Durrant wrote:
> The current threshold before the guest issues the hypercall is, and always
> has been, hard-coded to 2047. It is not clear where this number came
> from so, to at least allow for ease of experimentation, this patch makes
> the threshold tunable via the Xen command line.
>
> Signed-off-by: Paul Durrant 

This is one example of a configuration option which I'd prefer to see
done with the (planned) new CPUID interface.

The value here doesn't have any impact on the hypervisor, so a
configuration option is free to be chosen entirely by the toolstack, and
would also become inherently per-domain configuration rather than global.

Can I talk you into deferring this change until the CPUID interface is
sorted, to avoid introducing yet another command line option?

~Andrew

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

Re: [Xen-devel] [PATCH V2] common/mem_access: merged mem_access setting interfaces

[Jan Beulich]

>>> On 20.03.17 at 17:48,  wrote:
> On 03/20/2017 06:40 PM, Jan Beulich wrote:
> On 20.03.17 at 17:16,  wrote:
>>> On 03/20/2017 06:14 PM, Razvan Cojocaru wrote:
 In any case, back when I've added xc_set_mem_access_multi() I've also
 modified struct xen_mem_access_op in the same manner:


>>> http://xenbits.xenproject.org/gitweb/?p=xen.git;a=commitdiff;h=1ef5056bd6274e
>>>  
>>> cbe065387b6cf45657d6d700cd
>>>
>>> Oh, nevermind, I think you're referring to the fact that I had back then
>>> added members to the end of the structure, and so the old layout had
>>> remained compatible. Point taken.
>> 
>> Not just that - there you've also introduced a new sub-op.
> 
> Yes, but by modifying the structure for use with
> XENMEM_access_op_set_access_multi, it's now also changed for, e.g.,
> XENMEM_access_op_set_access - since it's common to them. Other than the
> place where the new data has been added, I believe that the same
> critique would apply to the old patch, unless I'm misunderstanding
> something.

Indeed, strictly speaking that change wasn't really okay either,
as someone passing the smaller structure near the end of a page
might get -EFAULT back. So we're trying to do better this time ...

Jan


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

Re: [Xen-devel] [GSoC] GSoC Introduction : Fuzzing Xen hypercall interface

[Felix Schmoll]

2017-03-20 17:18 GMT+01:00 Wei Liu :

> On Mon, Mar 20, 2017 at 09:12:54AM +0100, Felix Schmoll wrote:
> > 2017-03-16 17:27 GMT+01:00 Wei Liu :
> >
> >  #undef COMP
> > diff --git a/xen/common/kernel.c b/xen/common/kernel.c
> > index 4b87c60845..de07ee529b 100644
> > --- a/xen/common/kernel.c
> > +++ b/xen/common/kernel.c
> > @@ -226,6 +226,12 @@ void __init do_initcalls(void)
> >   * Simple hypercalls.
> >   */
> >
> > +DO(domain_id)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>
> XEN_GUEST_HANDLE_PARAM means arg is a pointer to void type inside of the
> guest, it's better to just use XEN_GUEST_HANDLE_PARAM(uint32_t) arg.
> Also see below.
>
> > +{
> > +struct domain *d = current->domain;
> > +return d->domain_id;
>
> You certainly don't need cmd, because you provide no command.
>
> If you want to return the domain id directly, you don't need arg.
> Also please be aware of the types (long vs uint32_t). I think this is
> the simplest approach.
>
> > +}
> > +
> >  DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
> >  {
> >  bool_t deny = !!xsm_xen_version(XSM_OTHER, cmd);
> > diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> > index 91ba8bb48e..4ad62aa01b 100644
> > --- a/xen/include/public/xen.h
> > +++ b/xen/include/public/xen.h
> > @@ -121,6 +121,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
> >  #define __HYPERVISOR_xc_reserved_op   39 /* reserved for XenClient
> */
> >  #define __HYPERVISOR_xenpmu_op40
> >  #define __HYPERVISOR_dm_op41
> > +#define __HYPERVISOR_domain_id42 /* custom hypercall */
> >
> >  /* Architecture-specific hypercall definitions. */
> >  #define __HYPERVISOR_arch_0   48
> > diff --git a/xen/include/xen/hypercall.h b/xen/include/xen/hypercall.h
> > index cc99aea57d..438684df85 100644
> > --- a/xen/include/xen/hypercall.h
> > +++ b/xen/include/xen/hypercall.h
> > @@ -83,6 +83,11 @@ do_xen_version(
> >  XEN_GUEST_HANDLE_PARAM(void) arg);
> >
> >  extern long
> > +do_domain_id(
> > +int cmd,
> > +XEN_GUEST_HANDLE_PARAM(void) arg);
> > +
> > +extern long
> >  do_console_io(
> >  int cmd,
> >  int count,
> > --
> > 2.11.0
> >
> >
> > From 3a896fcf3bc5d7f8c4613d9d4b854684ec981e7f Mon Sep 17 00:00:00 2001
> > From: Felix Schmoll 
> > Date: Thu, 16 Mar 2017 22:38:23 +0100
> > Subject: [PATCH 2/2] Adjust libxc to new hypercall (untested)
> >
> > ---
> >  tools/libxc/include/xenctrl.h |  1 +
> >  tools/libxc/xc_private.c  | 17 +
> >  tools/libxc/xc_private.h  |  8 
> >  3 files changed, 26 insertions(+)
> >
> > diff --git a/tools/libxc/include/xenctrl.h
> b/tools/libxc/include/xenctrl.h
> > index a48981abea..e454b10f64 100644
> > --- a/tools/libxc/include/xenctrl.h
> > +++ b/tools/libxc/include/xenctrl.h
> > @@ -1546,6 +1546,7 @@ int xc_domctl(xc_interface *xch, struct xen_domctl
> > *domctl);
> >  int xc_sysctl(xc_interface *xch, struct xen_sysctl *sysctl);
> >
> >  int xc_version(xc_interface *xch, int cmd, void *arg);
> > +int xc_domid(xc_interface *xch, int cmd, void *arg);
> >
> >  int xc_flask_op(xc_interface *xch, xen_flask_op_t *op);
> >
> > diff --git a/tools/libxc/xc_private.c b/tools/libxc/xc_private.c
> > index 72e6242417..f4f158c661 100644
> > --- a/tools/libxc/xc_private.c
> > +++ b/tools/libxc/xc_private.c
> > @@ -530,6 +530,23 @@ int xc_version(xc_interface *xch, int cmd, void
> *arg)
> >  return rc;
> >  }
> >
> > +int xc_domid(xc_interface *xch, int cmd, void *arg)
> > +{
> > +DECLARE_HYPERCALL_BOUNCE(arg, 0, XC_HYPERCALL_BUFFER_BOUNCE_OUT);
> /*
> > Size unknown until cmd decoded */
> > +size_t sz;
> > +int rc;
> > +
> > +/* TODO: might want to either consider or remove cmd param */
> > +sz = 0;
> > +
> > +HYPERCALL_BOUNCE_SET_SIZE(arg, sz);
> > +
> > +rc = do_domain_id(xch, cmd, HYPERCALL_BUFFER(arg));
>
> Most likely you will get rc = 0 because you're running your test program
> in Dom0. Try running this a DomU?
>
> > +
> > +return rc;
> > +}
> > +
> > +
> >  unsigned long xc_make_page_below_4G(
> >  xc_interface *xch, uint32_t domid, unsigned long mfn)
> >  {
> > diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
> > index 1c27b0fded..7cf875ffb5 100644
> > --- a/tools/libxc/xc_private.h
> > +++ b/tools/libxc/xc_private.h
> > @@ -229,6 +229,14 @@ static inline int do_xen_version(xc_interface *xch,
> > int cmd, xc_hypercall_buffer
> >  cmd, HYPERCALL_BUFFER_AS_ARG(dest));
> >  }
> >
> > +/* custom hypercall */
> > +static inline int do_domain_id(xc_interface *xch, int cmd,
> > xc_hypercall_buffer_t *dest)
> > +{
> > +DECLARE_HYPERCALL_BUFFER_ARGUMENT(dest);
> > +return xencall2(xch->xcall, __HYPERVISOR_domain_id,
> > +cmd, HYPERCALL_BUFFER_AS_ARG(dest));
> > +}
> > +
> >  static inline int do_physdev_op(xc_interface *xch, int cmd, void *op,
> > size_t len)
> >  

Re: [Xen-devel] [PATCH V2] common/mem_access: merged mem_access setting interfaces

[Razvan Cojocaru]

On 03/20/2017 06:40 PM, Jan Beulich wrote:
 On 20.03.17 at 17:16,  wrote:
>> On 03/20/2017 06:14 PM, Razvan Cojocaru wrote:
>>> On 03/20/2017 06:07 PM, Jan Beulich wrote:
>>> On 20.03.17 at 10:50,  wrote:
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -444,6 +444,8 @@ struct xen_mem_access_op {
>  /* xenmem_access_t */
>  uint8_t access;
>  domid_t domid;
> +uint16_t view_id;
> +uint16_t pad[3];

 Irrespective of Andrew's valid general objection, the change above
 wouldn't be valid either: How would you guarantee compatibility
 with old callers? Other than in e.g. domctl/sysctl there's no
 interface version here which can be bumped, so simply adding
 fields to a structure and re-using an existing sub-op won't do.
>>>
>>> I wouldn't - I thought simply bumping the DOMCTL version macro would be
>>> enough, but obviously I could just add other DOMCTLs and return an error
>>> for the old ones.
> 
> I miss the connection to domctl here - this is a mem-op, isn't it?

Yes, sorry, I meant mem-ops.

>>> In any case, back when I've added xc_set_mem_access_multi() I've also
>>> modified struct xen_mem_access_op in the same manner:
>>>
>>>
>> http://xenbits.xenproject.org/gitweb/?p=xen.git;a=commitdiff;h=1ef5056bd6274e
>>  
>> cbe065387b6cf45657d6d700cd
>>
>> Oh, nevermind, I think you're referring to the fact that I had back then
>> added members to the end of the structure, and so the old layout had
>> remained compatible. Point taken.
> 
> Not just that - there you've also introduced a new sub-op.

Yes, but by modifying the structure for use with
XENMEM_access_op_set_access_multi, it's now also changed for, e.g.,
XENMEM_access_op_set_access - since it's common to them. Other than the
place where the new data has been added, I believe that the same
critique would apply to the old patch, unless I'm misunderstanding
something.


Thanks,
Razvan


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

[Xen-devel] [PATCH v2] xen: use libxendevice model to restrict operations

[Paul Durrant]

This patch adds a command-line option (-xen-domid-restrict) which will
use the new libxendevicemodel API to restrict devicemodel operations to
the specified domid.

This patch also adds a tracepoint to allow successful enabling of the
restriction to be monitored.

Signed-off-by: Paul Durrant 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 
Cc: Paolo Bonzini 

NOTE: This is already re-based on Juergen Gross's patch "xen: use 5 digit
  xen versions" and so should not be applied until after that patch
  has been applied.

v2:
 - Log errno in tracepoint
---
 hw/xen/trace-events |  1 +
 include/hw/xen/xen.h|  1 +
 include/hw/xen/xen_common.h | 20 
 qemu-options.hx |  6 ++
 vl.c|  8 
 xen-hvm.c   |  8 
 6 files changed, 44 insertions(+)

diff --git a/hw/xen/trace-events b/hw/xen/trace-events
index c4fb6f1..5615dce 100644
--- a/hw/xen/trace-events
+++ b/hw/xen/trace-events
@@ -11,3 +11,4 @@ xen_map_portio_range(uint32_t id, uint64_t start_addr, 
uint64_t end_addr) "id: %
 xen_unmap_portio_range(uint32_t id, uint64_t start_addr, uint64_t end_addr) 
"id: %u start: %#"PRIx64" end: %#"PRIx64
 xen_map_pcidev(uint32_t id, uint8_t bus, uint8_t dev, uint8_t func) "id: %u 
bdf: %02x.%02x.%02x"
 xen_unmap_pcidev(uint32_t id, uint8_t bus, uint8_t dev, uint8_t func) "id: %u 
bdf: %02x.%02x.%02x"
+xen_domid_restrict(int err) "err: %u"
diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
index 2b1733b..7efcdaa 100644
--- a/include/hw/xen/xen.h
+++ b/include/hw/xen/xen.h
@@ -21,6 +21,7 @@ enum xen_mode {
 
 extern uint32_t xen_domid;
 extern enum xen_mode xen_mode;
+extern bool xen_domid_restrict;
 
 extern bool xen_allowed;
 
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index df098c7..4f3bd35 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -152,6 +152,13 @@ static inline int xendevicemodel_set_mem_type(
 return xc_hvm_set_mem_type(dmod, domid, mem_type, first_pfn, nr);
 }
 
+static inline int xendevicemodel_restrict(
+xendevicemodel_handle *dmod, domid_t domid)
+{
+errno = ENOTTY;
+return -1;
+}
+
 #else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 40900 */
 
 #include 
@@ -206,6 +213,19 @@ static inline int xen_modified_memory(domid_t domid, 
uint64_t first_pfn,
 return xendevicemodel_modified_memory(xen_dmod, domid, first_pfn, nr);
 }
 
+static inline int xen_restrict(domid_t domid)
+{
+int rc = xendevicemodel_restrict(xen_dmod, domid);
+
+trace_xen_domid_restrict(errno);
+
+if (errno == ENOTTY) {
+return 0;
+}
+
+return rc;
+}
+
 /* Xen 4.2 through 4.6 */
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40701
 
diff --git a/qemu-options.hx b/qemu-options.hx
index 99af8ed..4aab077 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -3354,6 +3354,10 @@ DEF("xen-attach", 0, QEMU_OPTION_xen_attach,
 "-xen-attach attach to existing xen domain\n"
 "xend will use this when starting QEMU\n",
 QEMU_ARCH_ALL)
+DEF("xen-domid-restrict", 0, QEMU_OPTION_xen_domid_restrict,
+"-xen-domid-restrict restrict set of available xen operations\n"
+"to specified domain id\n",
+QEMU_ARCH_ALL)
 STEXI
 @item -xen-domid @var{id}
 @findex -xen-domid
@@ -3366,6 +3370,8 @@ Warning: should not be used when xend is in use (XEN 
only).
 @findex -xen-attach
 Attach to existing xen domain.
 xend will use this when starting QEMU (XEN only).
+@findex -xen-domid-restrict
+Restrict set of available xen operations to specified domain id (XEN only).
 ETEXI
 
 DEF("no-reboot", 0, QEMU_OPTION_no_reboot, \
diff --git a/vl.c b/vl.c
index 0b4ed52..f46e070 100644
--- a/vl.c
+++ b/vl.c
@@ -205,6 +205,7 @@ static NotifierList machine_init_done_notifiers =
 bool xen_allowed;
 uint32_t xen_domid;
 enum xen_mode xen_mode = XEN_EMULATE;
+bool xen_domid_restrict;
 
 static int has_defaults = 1;
 static int default_serial = 1;
@@ -3933,6 +3934,13 @@ int main(int argc, char **argv, char **envp)
 }
 xen_mode = XEN_ATTACH;
 break;
+case QEMU_OPTION_xen_domid_restrict:
+if (!(xen_available())) {
+error_report("Option not supported for this target");
+exit(1);
+}
+xen_domid_restrict = true;
+break;
 case QEMU_OPTION_trace:
 g_free(trace_file);
 trace_file = trace_opt_parse(optarg);
diff --git a/xen-hvm.c b/xen-hvm.c
index 4b928cf..335e263 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -1226,6 +1226,14 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion 
**ram_memory)
 goto err;
 }
 
+if (xen_domid_restrict) {
+rc = xen_restrict(xen_domid);
+if (rc < 0) {
+

Re: [Xen-devel] [PATCH v6] xen: Allow a default compiled-in command line using Kconfig

[Jan Beulich]

>>> On 20.03.17 at 17:32,  wrote:
> Added 2 new config entries in common/Kconfig:
> CMDLINE and CMDLINE_OVERRIDE
> Modifed common/kernel.c:cmdline_parse().
> 
> The 2 new entries enable an embedded command line to be compiled
> in the hypervisor. CMDLINE depends on EXPERT = "y", and CMDLINE_OVERRIDE
> depends on CMDLINE != "".
> 
> If CMDLINE is set, it will be parsed prior to the bootloader command line.
> This order of parsing implies that if any non-cumulative options are set in
> both CMDLINE and the bootloader command line, only the ones in the latter will
> take effect. Further more, if CMDLINE_OVERRIDE is set to y, the whole
> bootloader command line will be ignored, which will be useful to work around
> broken bootloaders. A wrapper to the original 
> common/kernel.c:cmdline_parse()
> was introduced to complete this task.
> 
> This allows downstreams to set their defaults without modifying the source 
> code
> all over the place. Also probably useful for the embedded space.
> (See Also: https://xenproject.atlassian.net/browse/XEN-41)
> 
> Signed-off-by: Zhongze Liu 

Reviewed-by: Jan Beulich 

albeit I think the commit message should have what is now the 4th
paragraph first, with what are currently 1st and 2nd paragraphs
dropped altogether.

Jan


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

Re: [Xen-devel] [PATCH V2] common/mem_access: merged mem_access setting interfaces

[Jan Beulich]

>>> On 20.03.17 at 17:16,  wrote:
> On 03/20/2017 06:14 PM, Razvan Cojocaru wrote:
>> On 03/20/2017 06:07 PM, Jan Beulich wrote:
>> On 20.03.17 at 10:50,  wrote:
 --- a/xen/include/public/memory.h
 +++ b/xen/include/public/memory.h
 @@ -444,6 +444,8 @@ struct xen_mem_access_op {
  /* xenmem_access_t */
  uint8_t access;
  domid_t domid;
 +uint16_t view_id;
 +uint16_t pad[3];
>>>
>>> Irrespective of Andrew's valid general objection, the change above
>>> wouldn't be valid either: How would you guarantee compatibility
>>> with old callers? Other than in e.g. domctl/sysctl there's no
>>> interface version here which can be bumped, so simply adding
>>> fields to a structure and re-using an existing sub-op won't do.
>> 
>> I wouldn't - I thought simply bumping the DOMCTL version macro would be
>> enough, but obviously I could just add other DOMCTLs and return an error
>> for the old ones.

I miss the connection to domctl here - this is a mem-op, isn't it?

>> In any case, back when I've added xc_set_mem_access_multi() I've also
>> modified struct xen_mem_access_op in the same manner:
>> 
>> 
> http://xenbits.xenproject.org/gitweb/?p=xen.git;a=commitdiff;h=1ef5056bd6274e 
> cbe065387b6cf45657d6d700cd
> 
> Oh, nevermind, I think you're referring to the fact that I had back then
> added members to the end of the structure, and so the old layout had
> remained compatible. Point taken.

Not just that - there you've also introduced a new sub-op.

Jan


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

Re: [Xen-devel] [PATCH v2 10/12] xen/mce: add support of vLMCE injection to XEN_MC_inject_v2

[Jan Beulich]

>>> On 17.03.17 at 07:46,  wrote:
> --- a/xen/arch/x86/cpu/mcheck/mce.c
> +++ b/xen/arch/x86/cpu/mcheck/mce.c
> @@ -1546,6 +1546,21 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
>  }
>  break;
>  
> +case XEN_MC_INJECT_TYPE_LMCE:
> +if ( !lmce_support )
> +{
> +ret = x86_mcerr("No LMCE support in platform", -EINVAL);
> +break;
> +}
> +/* Ensure at most one CPU is specified. */
> +if ( nr_cpu_ids > cpumask_next(cpumask_first(cpumap), cpumap) )
> +{
> +ret = x86_mcerr("More than one CPU specified", -EINVAL);
> +break;
> +}
> +on_selected_cpus(cpumap, x86_mc_mceinject, NULL, 1);
> +break;

Please reject XEN_MC_INJECT_CPU_BROADCAST being used
together with this new type.

Jan


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

Re: [Xen-devel] [PATCH V2] common/mem_access: merged mem_access setting interfaces

[Tamas K Lengyel]

On Mon, Mar 20, 2017 at 8:20 AM, Andrew Cooper 
wrote:

> On 20/03/17 09:50, Razvan Cojocaru wrote:
> > xc_altp2m_set_mem_access() and xc_set_mem_access() end up doing the same
> thing
> > in the hypervisor, but the former is a HVMOP and the latter a DOMCTL.
> Since
> > nobody is currently using, or has stated intent to use, this
> functionality
> > specifically as an HVMOP, this patch removes the HVMOP while adding an
> extra
> > parameter to the more flexible DOMCTL variant, in which the altp2m view
> can be
> > transmitted (0 for the default view, or when altp2m is disabled).
> > The xen-access test has been updated in the process.
> >
> > Signed-off-by: Razvan Cojocaru 
>
> I am sorry to be awkward here, but as this patch stands, it definitely
> breaks the original usecase altp2m was introduced for.  Therefore, I
> don't it is appropriate to take in this form.
>
> The problem is that the current permissions are too coarse-grained.
>
> Intel's use case needs all hypercalls usable by the guest, as the agent
> is entirely in-guest.  (It also occurs to me that scenario might be
> useful to develop within.)
>
> Bitdefenders use case needs vmfunc usable by the guest, but all
> alteration of view permissions must be restricted to a more privileged
> entity.
>
> Tamas' usecase is (IIRC) entirely behind the back of the guest.
>
>
> As a result, the two choices needed are "can a guest configure/use
> vmfunc", and "can a guest alter its own view permissions".
>
> These should cater to all usecases, as far as I understand.
>

So I have an outstanding patch that addressed this issue, at least
partially: https://patchwork.kernel.org/patch/9284861. It was part of a
larger series that didn't yet make it to upstream but it doesn't depend on
anything in that series so we could take it out. The goal with that patch
was to be able to indicate how the default altp2m should behave, ie. mixed
internal-external use, or purely external. If there is a need for a third
option that would specify that only the #VE call should be enabled from
within the guest, that could probably be added.

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

Re: [Xen-devel] [PATCH v2 09/12] x86/vmce, tools/libxl: expose LMCE capability in guest MSR_IA32_MCG_CAP

[Jan Beulich]

>>> On 17.03.17 at 07:46,  wrote:
> --- a/xen/include/public/hvm/params.h
> +++ b/xen/include/public/hvm/params.h
> @@ -259,6 +259,11 @@
>   */
>  #define HVM_PARAM_VM86_TSS_SIZED 37
>  
> -#define HVM_NR_PARAMS 38
> +/* Enable MCA capabilities. */
> +#define HVM_PARAM_MCA_CAP 38
> +#define HVMMCA_CAP_LMCE   (1UL << 27)

How come this is bit 27 rather than bit 0? Further, to match up with
other, future definitions here, I think you mean 1ULL (or, to be
precise, xen_mk_ullong()).

> +#define HVMMCA_CAP_MASK   HVMMCA_CAP_LMCE

For both of these, please add XEN_ at the front (perhaps replacing
HVM, or if not, add another underscore between HVM and MCA).

Jan


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

[Xen-devel] [PATCH v6] xen: Allow a default compiled-in command line using Kconfig

[Zhongze Liu]

Added 2 new config entries in common/Kconfig:
CMDLINE and CMDLINE_OVERRIDE
Modifed common/kernel.c:cmdline_parse().

The 2 new entries enable an embedded command line to be compiled
in the hypervisor. CMDLINE depends on EXPERT = "y", and CMDLINE_OVERRIDE
depends on CMDLINE != "".

If CMDLINE is set, it will be parsed prior to the bootloader command line.
This order of parsing implies that if any non-cumulative options are set in
both CMDLINE and the bootloader command line, only the ones in the latter will
take effect. Further more, if CMDLINE_OVERRIDE is set to y, the whole
bootloader command line will be ignored, which will be useful to work around
broken bootloaders. A wrapper to the original common/kernel.c:cmdline_parse()
was introduced to complete this task.

This allows downstreams to set their defaults without modifying the source code
all over the place. Also probably useful for the embedded space.
(See Also: https://xenproject.atlassian.net/browse/XEN-41)

Signed-off-by: Zhongze Liu 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
Changed since v5:
  * remove the redundent EXPERT = "y" dependency from config CMDLINE_OVERRIDE
  * make opt_builtin_cmdline[] static and __initconst
  * changed the name do_cmdline_parse() to _cmdline_parse()
  * do a NULL check before copying cmdline to saved_cmdline
  * check the first byte of opt_builtin_cmdline to determine whether it's
empty or not.
---
 xen/common/Kconfig  | 22 ++
 xen/common/kernel.c | 30 --
 2 files changed, 46 insertions(+), 6 deletions(-)

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index f2ecbc43d6..e1c90b739a 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -237,4 +237,26 @@ config FAST_SYMBOL_LOOKUP
  The only user of this is Live patching.
 
  If unsure, say Y.
+
+config CMDLINE
+   string "Built-in hypervisor command string"
+   default ""
+   depends on EXPERT = "y"
+   ---help---
+ Enter arguments here that should be compiled into the hypervisor
+ image and used at boot time. When the system boots, this string
+ will be parsed prior to the bootloader command line. So if a
+ non-cumulative option is set both in this string and in the
+ bootloader command line, only the latter one will take effect.
+
+config CMDLINE_OVERRIDE
+   bool "Built-in command line overrides bootloader arguments"
+   default n
+   depends on CMDLINE != ""
+   ---help---
+ Set this option to 'Y' to have the hypervisor ignore the bootloader
+ command line, and use ONLY the built-in command line.
+
+ This is used to work around broken bootloaders. This should
+ be set to 'N' under normal conditions.
 endmenu
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 4b87c60845..64920e8304 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -23,6 +23,7 @@
 enum system_state system_state = SYS_STATE_early_boot;
 
 xen_commandline_t saved_cmdline;
+static const char __initconst opt_builtin_cmdline[] = CONFIG_CMDLINE;
 
 static void __init assign_integer_param(
 const struct kernel_param *param, uint64_t val)
@@ -46,18 +47,13 @@ static void __init assign_integer_param(
 }
 }
 
-void __init cmdline_parse(const char *cmdline)
+static void __init _cmdline_parse(const char *cmdline)
 {
 char opt[100], *optval, *optkey, *q;
 const char *p = cmdline;
 const struct kernel_param *param;
 int bool_assert;
 
-if ( cmdline == NULL )
-return;
-
-safe_strcpy(saved_cmdline, cmdline);
-
 for ( ; ; )
 {
 /* Skip whitespace. */
@@ -147,6 +143,28 @@ void __init cmdline_parse(const char *cmdline)
 }
 }
 
+/**
+ *cmdline_parse -- parses the xen command line.
+ * If CONFIG_CMDLINE is set, it would be parsed prior to @cmdline.
+ * But if CONFIG_CMDLINE_OVERRIDE is set to y, @cmdline will be ignored.
+ */
+void __init cmdline_parse(const char *cmdline)
+{
+if ( opt_builtin_cmdline[0] )
+{
+printk("Built-in command line: %s\n", opt_builtin_cmdline);
+_cmdline_parse(opt_builtin_cmdline);
+}
+
+#ifndef CONFIG_CMDLINE_OVERRIDE
+if ( cmdline == NULL )
+return;
+
+safe_strcpy(saved_cmdline, cmdline);
+_cmdline_parse(cmdline);
+#endif
+}
+
 int __init parse_bool(const char *s)
 {
 if ( !strcmp("no", s) ||
-- 
2.12.0


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

[Xen-devel] [PATCH] tools/libxc: Drop dombuilder support for PV autotranslate guests

[Andrew Cooper]

c/s 4045953 "x86/paging: Enforce PG_external == PG_translate == PG_refcounts"
in the hypervisor finally prevented the construction of PV autotranslate
guests.

Remove support for such guests in the domain builder, bailing out with an
obvious "no longer supported" message, rather than a more obscure
"SHADOW_OP_ENABLED failed".

As a piece of cleanup, rename xc_dom_feature_translated() to
xc_dom_translated() to match its actual semantics.

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 
CC: Wei Liu 
---
 tools/libxc/include/xc_dom.h |   5 +-
 tools/libxc/xc_dom_arm.c |   6 +-
 tools/libxc/xc_dom_boot.c|   2 +-
 tools/libxc/xc_dom_x86.c | 133 ---
 tools/libxl/libxl_dom.c  |   2 +-
 5 files changed, 30 insertions(+), 118 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index b416eb5..ce47058 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -168,7 +168,6 @@ struct xc_dom_image {
 xc_interface *xch;
 domid_t guest_domid;
 int claim_enabled; /* 0 by default, 1 enables it */
-int shadow_enabled;
 
 int xen_version;
 xen_capabilities_info_t xen_caps;
@@ -334,7 +333,7 @@ int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
xen_pfn_t xenstore_gmfn,
domid_t console_domid,
domid_t xenstore_domid);
-int xc_dom_feature_translated(struct xc_dom_image *dom);
+bool xc_dom_translated(const struct xc_dom_image *dom);
 
 /* --- debugging bits -- */
 
@@ -420,7 +419,7 @@ static inline void *xc_dom_vaddr_to_ptr(struct xc_dom_image 
*dom,
 
 static inline xen_pfn_t xc_dom_p2m(struct xc_dom_image *dom, xen_pfn_t pfn)
 {
-if ( dom->shadow_enabled || xc_dom_feature_translated(dom) )
+if ( xc_dom_translated(dom) )
 return pfn;
 if (pfn < dom->rambase_pfn || pfn >= dom->rambase_pfn + dom->total_pages)
 return INVALID_MFN;
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index a7e839e..e7d4bd0 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -419,8 +419,6 @@ static int meminit(struct xc_dom_image *dom)
 if ( rc )
 return rc;
 
-dom->shadow_enabled = 1;
-
 for ( i = 0; ramsize && i < GUEST_RAM_BANKS; i++ )
 {
 uint64_t banksize = ramsize > bankmax[i] ? bankmax[i] : ramsize;
@@ -504,9 +502,9 @@ static int meminit(struct xc_dom_image *dom)
 return 0;
 }
 
-int xc_dom_feature_translated(struct xc_dom_image *dom)
+bool xc_dom_translated(const struct xc_dom_image *dom)
 {
-return 1;
+return true;
 }
 
 /*  */
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index 791041b..c3b44dd 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -407,7 +407,7 @@ int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t domid,
 
 int xc_dom_gnttab_init(struct xc_dom_image *dom)
 {
-if ( xc_dom_feature_translated(dom) ) {
+if ( xc_dom_translated(dom) ) {
 return xc_dom_gnttab_hvm_seed(dom->xch, dom->guest_domid,
   dom->console_pfn, dom->xenstore_pfn,
   dom->console_domid, dom->xenstore_domid);
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index c176c00..cb68efc 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -546,7 +546,7 @@ static int alloc_magic_pages(struct xc_dom_image *dom)
 dom->console_pfn = xc_dom_alloc_page(dom, "console");
 if ( dom->console_pfn == INVALID_PFN )
 return -1;
-if ( xc_dom_feature_translated(dom) )
+if ( xc_dom_translated(dom) )
 {
 dom->shared_info_pfn = xc_dom_alloc_page(dom, "shared info");
 if ( dom->shared_info_pfn == INVALID_PFN )
@@ -720,8 +720,7 @@ static int start_info_x86_32(struct xc_dom_image *dom)
 start_info_x86_32_t *start_info =
 xc_dom_pfn_to_ptr(dom, dom->start_info_pfn, 1);
 xen_pfn_t shinfo =
-xc_dom_feature_translated(dom) ? dom->shared_info_pfn : dom->
-shared_info_mfn;
+xc_dom_translated(dom) ? dom->shared_info_pfn : dom->shared_info_mfn;
 
 DOMPRINTF_CALLED(dom->xch);
 
@@ -767,8 +766,7 @@ static int start_info_x86_64(struct xc_dom_image *dom)
 start_info_x86_64_t *start_info =
 xc_dom_pfn_to_ptr(dom, dom->start_info_pfn, 1);
 xen_pfn_t shinfo =
-xc_dom_feature_translated(dom) ? dom->shared_info_pfn : dom->
-shared_info_mfn;
+xc_dom_translated(dom) ? dom->shared_info_pfn : dom->shared_info_mfn;
 
 DOMPRINTF_CALLED(dom->xch);
 
@@ -1063,29 +1061,6 @@ static int x86_compat(xc_interface *xch, domid_t domid, 
char *guest_type)
 return rc;
 }
 
-static int x86_shadow(xc_interface *xch, domid_t 

Re: [Xen-devel] [PATCH 05/11] xen/arm: vpl011: Initialize nr_spis in vgic_init in Xen to atleast 1

[Bhupinder Thakur]

On 16 March 2017 at 18:54, Julien Grall  wrote:
> Hi Bhupinder,
>
> On 03/16/2017 10:31 AM, Bhupinder Thakur wrote:
>>
>> On 16 March 2017 at 13:54, Julien Grall  wrote:


 The other option is to reserve a SPI for pl011 at compile time and use
 that value. Let me know.
>>>
>>>
>>>
>>> Whilst I am ok to have the pl011 SPI number hardcoded, I don't like the
>>> approach taken in this patch because the toolstack is in charge of the
>>> guest
>>> layout (interrupt, memory...) and not the hypervisor.
>>>
>>> The values are hardcoded today because we decided to do a fix layout for
>>> simplicity. It is likely to be changed in the future.
>>>
>>> The toolstack knows how much memory the user requested, the list of
>>> devices
>>> available... So it is the goal of the toolstack to bump the number of
>>> SPIs
>>> before creating the domain if a PL011 will be exposed.
>>>
>>> Also, the interaction between the pl011 and the parameter "irqs" in the
>>> domain configuration file will need to be documented. By that I mean
>>> explaining from which number the SPIs will be allocated when choosing a
>>> pl011 enabling.
>>>
>>> Note the probably want to allow the user to choose the pl011 IRQ and MMIO
>>> region. If he doesn't provide any, we would use the default value.
>>>
>>> Cheers,
>>
>>
>> We can follow the convention that when pl011 is enabled then the last
>> irq in the "irqs" list will be used as the pl011 irq. I believe that
>> the irqs mentioned in the "irqs" list will be reserved by the
>> hypervisor when the domain is created and we need not allocate a SPI
>> separately as we are doing currently.
>
>
> I don't understand what you mean here. If you speak about the xl parameter
> "irqs", it is a list of physical IRQs and not virtual IRQs. Furthermore, we
> would like to keep to avoid a normal user to do more than specifying "pl011"
> or else on in the guest configuration file.
>
> So could you clarify what you mean?
>

Now, I am taking one option in the domU configuration file which tells
whether pl011 emulation is enabled or not. Based on this option, the
tool stack will increment the nr_spis (i have removed the nr_spis
increment logic from the hypervisor code). It will create the pl011 DT
node also based on whether this option is enabled.

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

Re: [Xen-devel] [PATCH v2 08/12] x86/vmce: enable injecting LMCE to guest on Intel host

[Jan Beulich]

>>> On 17.03.17 at 07:46,  wrote:
> @@ -88,18 +89,31 @@ mc_memerr_dhandler(struct mca_binfo *binfo,
>  goto vmce_failed;
>  }
>  
> -if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ||
> -global->mc_vcpuid == XEN_MC_VCPUID_INVALID)
> +mc_vcpuid = global->mc_vcpuid;
> +if (mc_vcpuid == XEN_MC_VCPUID_INVALID ||
> +(boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
> + (!(global->mc_gstatus & MCG_STATUS_LMCE) ||
> +  !(d->vcpu[mc_vcpuid]->arch.vmce.lmce_enabled) ||
> +  /*
> +   * The following check serves for MCE injection
> +   * test, i.e. xen-mceinj. xen-mceinj may specify
> +   * the target domain (i.e. bank->mc_domid) and
> +   * target CPU, but it's hard for xen-mceinj to
> +   * ensure, when Xen prepares the actual
> +   * injection in this function, vCPU currently
> +   * running on the target CPU belongs to the
> +   * target domain. If such inconsistency does
> +   * happen, fallback to broadcast.
> +   */
> +  global->mc_domid != bank->mc_domid)))

Thinking about this another time, I don't think we want hackery
like this for a test utility. Instead I think the test utility wants to
pin the vCPU on the pCPU it wants to deliver the LMCE on.

Jan


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

Re: [Xen-devel] [PATCH v2 07/12] x86/vmce: emulate MSR_IA32_MCG_EXT_CTL

[Jan Beulich]

>>> On 17.03.17 at 07:46,  wrote:
> --- a/xen/include/public/arch-x86/hvm/save.h
> +++ b/xen/include/public/arch-x86/hvm/save.h
> @@ -599,6 +599,8 @@ struct hvm_vmce_vcpu {
>  uint64_t caps;
>  uint64_t mci_ctl2_bank0;
>  uint64_t mci_ctl2_bank1;
> +uint8_t  lmce_enabled;
> +uint8_t  pad[7];

Even if only one bit is used there right now, I think you should migrate
the full MSR.

> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -37,7 +37,7 @@
>  #include "hvm/save.h"
>  #include "memory.h"
>  
> -#define XEN_DOMCTL_INTERFACE_VERSION 0x000c
> +#define XEN_DOMCTL_INTERFACE_VERSION 0x000d

This seemingly unrelated change needs to be explained in the
description.

Jan


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

Re: [Xen-devel] [PATCH V2] common/mem_access: merged mem_access setting interfaces

[Razvan Cojocaru]

On 03/20/2017 06:14 PM, Razvan Cojocaru wrote:
> On 03/20/2017 06:07 PM, Jan Beulich wrote:
> On 20.03.17 at 10:50,  wrote:
>>> --- a/xen/include/public/memory.h
>>> +++ b/xen/include/public/memory.h
>>> @@ -444,6 +444,8 @@ struct xen_mem_access_op {
>>>  /* xenmem_access_t */
>>>  uint8_t access;
>>>  domid_t domid;
>>> +uint16_t view_id;
>>> +uint16_t pad[3];
>>
>> Irrespective of Andrew's valid general objection, the change above
>> wouldn't be valid either: How would you guarantee compatibility
>> with old callers? Other than in e.g. domctl/sysctl there's no
>> interface version here which can be bumped, so simply adding
>> fields to a structure and re-using an existing sub-op won't do.
> 
> I wouldn't - I thought simply bumping the DOMCTL version macro would be
> enough, but obviously I could just add other DOMCTLs and return an error
> for the old ones.
> 
> In any case, back when I've added xc_set_mem_access_multi() I've also
> modified struct xen_mem_access_op in the same manner:
> 
> http://xenbits.xenproject.org/gitweb/?p=xen.git;a=commitdiff;h=1ef5056bd6274ecbe065387b6cf45657d6d700cd

Oh, nevermind, I think you're referring to the fact that I had back then
added members to the end of the structure, and so the old layout had
remained compatible. Point taken.


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH V2] common/mem_access: merged mem_access setting interfaces

[Razvan Cojocaru]

On 03/20/2017 06:07 PM, Jan Beulich wrote:
 On 20.03.17 at 10:50,  wrote:
>> --- a/xen/include/public/memory.h
>> +++ b/xen/include/public/memory.h
>> @@ -444,6 +444,8 @@ struct xen_mem_access_op {
>>  /* xenmem_access_t */
>>  uint8_t access;
>>  domid_t domid;
>> +uint16_t view_id;
>> +uint16_t pad[3];
> 
> Irrespective of Andrew's valid general objection, the change above
> wouldn't be valid either: How would you guarantee compatibility
> with old callers? Other than in e.g. domctl/sysctl there's no
> interface version here which can be bumped, so simply adding
> fields to a structure and re-using an existing sub-op won't do.

I wouldn't - I thought simply bumping the DOMCTL version macro would be
enough, but obviously I could just add other DOMCTLs and return an error
for the old ones.

In any case, back when I've added xc_set_mem_access_multi() I've also
modified struct xen_mem_access_op in the same manner:

http://xenbits.xenproject.org/gitweb/?p=xen.git;a=commitdiff;h=1ef5056bd6274ecbe065387b6cf45657d6d700cd


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH v2 06/12] x86/vmx: expose LMCE feature via guest MSR_IA32_FEATURE_CONTROL

[Jan Beulich]

>>> On 17.03.17 at 07:46,  wrote:
> --- a/xen/arch/x86/cpu/mcheck/mce_intel.c
> +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
> @@ -955,3 +955,7 @@ int vmce_intel_rdmsr(const struct vcpu *v, uint32_t msr, 
> uint64_t *val)
>  return 1;
>  }
>  
> +bool vmce_support_lmce(const struct vcpu *v)

I think you mean vmce_supports_lmce() (or vmce_has_lmce()). I'm
sorry for having overlooked this in v1.

>  static int vmx_msr_read_intercept(unsigned int msr, uint64_t *msr_content)
>  {
> +struct vcpu *curr = current;

const

Jan


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