Re: [Xen-devel] Setting up a call to discuss PCI Emulation - Future Direction

[Paul Durrant]

> -Original Message-
> From: Roger Pau Monne
> Sent: 13 April 2018 20:53
> To: Lars Kurth 
> Cc: xen-devel ; Daniel Smith
> ; Alexey G ; Stefano
> Stabellini ; Julien Grall ; Paul
> Durrant ; Christopher Clark
> ; Rich Persaud 
> Subject: Re: Setting up a call to discuss PCI Emulation - Future Direction
> 
> On Fri, Apr 13, 2018 at 12:59:15PM +0100, Lars Kurth wrote:
> >
> >
> > On 13/04/2018, 11:01, "Roger Pau Monne"  wrote:
> >
> > On Thu, Apr 12, 2018 at 05:50:00PM +0100, Lars Kurth wrote:
> > >
> > >
> > > On 12/04/2018, 17:41, "Roger Pau Monne" 
> wrote:
> > >
> > > On Thu, Apr 12, 2018 at 05:32:57PM +0100, Lars Kurth wrote:
> > >
> > >
> > > >may work. For me Mon, Wed and Fri’s generally work at those
> time-slots.
> > > >Next week is a little busy for me, so I would prefer the 
> > following
> week.
> > > >If you could fill out the following Google poll, if this 
> > week works
> that
> > > >would be great. Otherwise please scream.
> > >
> > > I'm afraid I'm on vacations from the 21st to the 29th of April, 
> > so I
> > > won't be able to join the meeting unless we move it to the week
> after.
> > > Let's see what people think of the current dates.
> > >
> > > Roger.
> > >
> > > Hi, I changed the dates to the week after. Poll so far has been
> invalidated.
> > >
> > > See https://doodle.com/poll/gdnmcrvnibmw563n
> >
> > Thanks! I've already fixed my vote.
> >
> > I guess this will come later, but we need a clear agenda of items
> > because the x86 and ARM topics are probably going to be completely
> > different (albeit all related to PCI).
> >
> > Royger: I am OK with trying to get a draft agenda in place in this e-mail
> thread. But I can't drive this, as I don’t understand the issues. But I am 
> happy
> to collate everything as for the x86 call and write up minutes
> 
> On the x86 side:
> 
>  - Q35 HVM emulation, adding MCFG support to guests.

One of the issues here is support for multiple external emulators w.r.t. config 
space access.

>  - PVH guest pci-passthrough: using the internal vPCI infrastructure.

Let's not distinguish between HVM or PVH here. We want to use the same 
passthrough mechanisms for both.

Cheers,

  Paul

> 
> At least that I can think of ATM.
> 
> Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/xen: Remove use of VLAs

[Laura Abbott]

On 04/13/2018 07:55 PM, David Brown wrote:

On Fri, Apr 13, 2018 at 03:11:46PM -0700, Laura Abbott wrote:


There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. The few VLAs in use have an upper bound based on a size
of 64K. This doesn't produce an excessively large stack so just switch
the upper bound.

[1] https://lkml.org/lkml/2018/3/7/621


This comment is more in regards to many of these patches, and not as
much this one specifically.

How confident are we in the upper bounds we're setting, and how
obvious is it in the resulting code so that something does later
change to overflow these bounds.

The danger here is that we're converting something a little easier to
detect (a stack overflow), with something harder to detect
(overflowing an array on the stack).



Several people have remarked on that and the solution has been to
put in some kind of WARN and/or error check to make it obvious something
needs to be adjusted.


I guess the question is twofold: how did you determine that 64K was
the largest 'size' value, and how should reviewers verify this as
well.  Perhaps this should at least be in the commit text so someone
tracking down something with this code can find it later.



It's not in the patch context but there's a large comment below:

/*
 * A GDT can be up to 64k in size, which corresponds to 8192
 * 8-byte entries, or 16 4k pages..
 */

BUG_ON(size > 65536);


Given the frames was calculated based off the size, that seemed
sufficient.


David


Thanks,
Laura

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  16fb4b5a9a79f95df17f10ba62e9f44d21cf89b5
baseline version:
 xen  82540b66ceb9318aa185f2488cbbbe479694de8f

Last test of basis   122174  2018-04-11 11:01:17 Z2 days
Failing since122191  2018-04-12 16:01:30 Z1 days   13 attempts
Testing same since   122264  2018-04-13 19:58:45 Z0 days1 attempts


People who touched revisions under test:
  Doug Goldstein 
  George Dunlap 
  Ian Jackson 
  Konrad Rzeszutek Wilk 
  Lars Kurth 
  Oleksandr Andrushchenko 
  Oleksandr Grytsov 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   82540b66ce..16fb4b5a9a  16fb4b5a9a79f95df17f10ba62e9f44d21cf89b5 -> smoke

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

[Xen-devel] [ovmf baseline-only test] 74601: trouble: blocked/broken

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm  broken
 build-i386   broken
 build-amd64-pvopsbroken
 build-i386-xsm   broken
 build-amd64  broken
 build-i386-pvops broken

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 build-amd64-xsm   4 host-install(4)   broken baseline untested
 build-amd64   4 host-install(4)   broken baseline untested
 build-amd64-pvops 4 host-install(4)   broken baseline untested
 build-i3864 host-install(4)   broken baseline untested
 build-i386-xsm4 host-install(4)   broken baseline untested
 build-i386-pvops  4 host-install(4)   broken baseline untested

version targeted for testing:
 ovmf 2167c7f7a55b9964912d08aae71879357101ace1
baseline version:
 ovmf 54ec85dd2902bd5dee39106d5291f71088b7d85a

Last test of basis74595  2018-04-13 17:56:39 Z0 days
Testing same since74601  2018-04-14 00:18:54 Z0 days1 attempts


People who touched revisions under test:
  Gary Lin 
  Laszlo Ersek 

jobs:
 build-amd64-xsm  broken  
 build-i386-xsm   broken  
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



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

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

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

broken-job build-amd64-xsm broken
broken-job build-i386 broken
broken-job build-amd64-pvops broken
broken-job build-i386-xsm broken
broken-job build-amd64 broken
broken-job build-i386-pvops broken
broken-step build-amd64-xsm host-install(4)
broken-step build-amd64 host-install(4)
broken-step build-amd64-pvops host-install(4)
broken-step build-i386 host-install(4)
broken-step build-i386-xsm host-install(4)
broken-step build-i386-pvops host-install(4)

Push not applicable.


commit 2167c7f7a55b9964912d08aae71879357101ace1
Author: Laszlo Ersek 
Date:   Sat Mar 31 17:33:14 2018 +0200

CryptoPkg/TlsLib: rewrite TlsSetCipherList()

Rewrite the TlsSetCipherList() function in order to fix the following
issues:

- Any cipher identifier in CipherId that is not recognized by
  TlsGetCipherMapping() will cause the function to return EFI_UNSUPPORTED.

  This is a problem because CipherId is an ordered preference list, and a
  caller should not get EFI_UNSUPPORTED just because it has an elaborate
  CipherId preference list. Instead, we can filter out cipher identifiers
  that we don't recognize, as long as we keep the relative order intact.

- CipherString is allocated on the stack, with 500 bytes.

  While processing a large CipherId preference list, this room may not be
  enough. Although no buffer overflow is possible, CipherString exhaustion
  can lead to a failed TLS connection, because any cipher names that don't
  fit on CipherString cannot be negotiated.

  Compute CipherStringSize first, and allocate CipherString dynamically.

- Finally, the "@STRENGTH" pseudo cipher name is appended to CipherString.
  (Assuming there is enough room left in CipherString.) This causes
  OpenSSL to sort the cipher list "in order of encryption algorithm key
  length".

  This is a bad idea. The 

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 2167c7f7a55b9964912d08aae71879357101ace1
baseline version:
 ovmf 54ec85dd2902bd5dee39106d5291f71088b7d85a

Last test of basis   16  2018-04-13 05:16:49 Z0 days
Testing same since   122250  2018-04-13 12:52:24 Z0 days1 attempts


People who touched revisions under test:
  Gary Lin 
  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 :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   54ec85dd29..2167c7f7a5  2167c7f7a55b9964912d08aae71879357101ace1 -> 
xen-tested-master

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

[Xen-devel] [libvirt test] 122224: tolerable all pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 122005
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 122005
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 122005
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  65a372d6e0a958b4dd670a8244dab86f5671dfdc
baseline version:
 libvirt  4300a56378cb4401ac2b66be5da985e94a4ca90c

Last test of basis   122005  2018-04-07 03:34:15 Z6 days
Failing since122154  2018-04-10 04:23:02 Z3 days4 attempts
Testing same since   14  2018-04-13 04:20:09 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Christian Ehrhardt 
  Daniel P. Berrangé 
  Erik Skultety 
  Jim Fehlig 
  John Ferlan 
  Ján Tomko 
  Michal Privoznik 
  Vincent Bernat 
  Wim ten Have 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-arm64-arm64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   pass
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd pass



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

Logs, config 

[Xen-devel] [qemu-mainline baseline-only test] 74598: trouble: blocked/broken

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 build-amd64  broken
 build-i386   broken
 build-armhf-pvopsbroken
 build-arm64-xsm  broken
 build-i386-xsm   broken
 build-amd64-xsm  broken
 build-amd64-pvopsbroken
 build-i386-pvops broken
 build-arm64-pvopsbroken
 build-armhf-xsm  broken
 build-armhf  broken
 build-armhf-pvops 4 host-install(4) broken REGR. vs. 74574
 build-i386-xsm4 host-install(4) broken REGR. vs. 74574
 build-i386-pvops  4 host-install(4) broken REGR. vs. 74574
 build-armhf-xsm   4 host-install(4) broken REGR. vs. 74574
 build-amd64-pvops 4 host-install(4) broken REGR. vs. 74574
 build-amd64   4 host-install(4) broken REGR. vs. 74574
 build-armhf   4 host-install(4) broken REGR. vs. 74574
 build-amd64-xsm   4 host-install(4) broken REGR. vs. 74574
 build-i3864 host-install(4) broken REGR. vs. 74574

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-xl-midway1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 

[Xen-devel] [PATCH] x86/xen: Remove use of VLAs

[Laura Abbott]

There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. The few VLAs in use have an upper bound based on a size
of 64K. This doesn't produce an excessively large stack so just switch
the upper bound.

[1] https://lkml.org/lkml/2018/3/7/621

Signed-off-by: Laura Abbott 
---
 arch/x86/xen/enlighten_pv.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index c36d23aa6c35..d96a5a535cbb 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -421,8 +421,7 @@ static void xen_load_gdt(const struct desc_ptr *dtr)
 {
unsigned long va = dtr->address;
unsigned int size = dtr->size + 1;
-   unsigned pages = DIV_ROUND_UP(size, PAGE_SIZE);
-   unsigned long frames[pages];
+   unsigned long frames[DIV_ROUND_UP(SZ_64K, PAGE_SIZE)];
int f;
 
/*
@@ -470,8 +469,7 @@ static void __init xen_load_gdt_boot(const struct desc_ptr 
*dtr)
 {
unsigned long va = dtr->address;
unsigned int size = dtr->size + 1;
-   unsigned pages = DIV_ROUND_UP(size, PAGE_SIZE);
-   unsigned long frames[pages];
+   unsigned long frames[DIV_ROUND_UP(SZ_64K, PAGE_SIZE)];
int f;
 
/*
-- 
2.14.3


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

[Xen-devel] [ovmf baseline-only test] 74595: trouble: blocked/broken

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm  broken
 build-i386   broken
 build-amd64-pvopsbroken
 build-i386-xsm   broken
 build-amd64  broken
 build-i386-pvops broken

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 build-amd64-xsm   4 host-install(4)   broken baseline untested
 build-amd64   4 host-install(4)   broken baseline untested
 build-amd64-pvops 4 host-install(4)   broken baseline untested
 build-i3864 host-install(4)   broken baseline untested
 build-i386-xsm4 host-install(4)   broken baseline untested
 build-i386-pvops  4 host-install(4)   broken baseline untested

version targeted for testing:
 ovmf 54ec85dd2902bd5dee39106d5291f71088b7d85a
baseline version:
 ovmf bf453d581ecff2a73128873fd714a07508e2ab11

Last test of basis74587  2018-04-13 03:22:19 Z0 days
Testing same since74595  2018-04-13 17:56:39 Z0 days1 attempts


People who touched revisions under test:
  Jian J Wang 
  Star Zeng 

jobs:
 build-amd64-xsm  broken  
 build-i386-xsm   broken  
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



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

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

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

broken-job build-amd64-xsm broken
broken-job build-i386 broken
broken-job build-amd64-pvops broken
broken-job build-i386-xsm broken
broken-job build-amd64 broken
broken-job build-i386-pvops broken
broken-step build-amd64-xsm host-install(4)
broken-step build-amd64 host-install(4)
broken-step build-amd64-pvops host-install(4)
broken-step build-i386 host-install(4)
broken-step build-i386-xsm host-install(4)
broken-step build-i386-pvops host-install(4)

Push not applicable.


commit 54ec85dd2902bd5dee39106d5291f71088b7d85a
Author: Jian J Wang 
Date:   Wed Apr 11 14:12:12 2018 +0800

MdeModulePkg/PiSmmIpl: fix non-executable SMM RAM

This patch fixes an issue introduced by commit

  5b91bf82c67b586b9588cbe4bbffa1588f6b5926

and

  0c9f2cb10b7ddec56a3440e77219fd3ab1725e5c

This issue will only happen if PcdDxeNxMemoryProtectionPolicy is
enabled for reserved memory, which will mark SMM RAM as NX (non-
executable) during DXE core initialization. SMM IPL driver will
unset the NX attribute for SMM RAM to allow loading and running
SMM core/drivers.

But above commit will fail the unset operation of the NX attribute
due to a fact that SMM RAM has zero cache attribute (MRC code always
sets 0 attribute to reserved memory), which will cause GCD internal
method ConverToCpuArchAttributes() to return 0 attribute, which is
taken as invalid CPU paging attribute and skip the calling of
gCpu->SetMemoryAttributes().

The solution is to make use of existing functionality in PiSmmIpl
to make sure one cache attribute is set for SMM RAM. For performance
consideration, PiSmmIpl will always try to set SMM RAM to write-back.
But there's a hole in the code which will fail the setting write-back
attribute because of no corresponding cache capabilities. This patch
will add necessary cache 

[Xen-devel] [xen-4.8-testing baseline-only test] 74594: trouble: blocked/broken

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 74594 xen-4.8-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74594/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 build-amd64  broken
 build-amd64-prev broken
 build-armhf-pvopsbroken
 build-i386   broken
 build-arm64-xsm  broken
 build-i386-xsm   broken
 build-amd64-xtf  broken
 build-amd64-xsm  broken
 build-amd64-pvopsbroken
 build-i386-pvops broken
 build-arm64-pvopsbroken
 build-armhf-xsm  broken
 build-armhf  broken
 build-i386-prev  broken

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-xtf-amd64-amd64-11 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-midway1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemut-win10-i386  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 build-i386-rumprun1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-21 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-amd64-rumprun   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-livepatch 1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-41 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 122144
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 122144
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122144
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122144
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 122144
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 122144
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 qemuu38e83a71d02e026d4a6d0ab1ef9855c4924c2c68
baseline version:
 qemuu915d34c5f99b0ab91517c69f54272bfdb6ca2b32

Last test of basis   122144  2018-04-09 19:01:09 Z3 days
Failing since122165  2018-04-10 23:20:31 Z2 days3 attempts
Testing same since   122177  2018-04-11 23:26:15 Z1 days2 attempts


People who touched revisions under test:
  Alexey Kardashevskiy 
  Andrey Smirnov 
  BALATON Zoltan 
  Christian Borntraeger 
  Cornelia Huck 
  Daniel P. Berrangé 
  David Gibson 
  David Hildenbrand 
  Dr. David Alan Gilbert 
  Eric Auger 
  Eric Blake 
  Gerd Hoffmann 
  Greg Kurz 
  James Cowgill 

Re: [Xen-devel] [PATCH 3/3] x86: check feature flags after resume

[Simon Gaiser]

Simon Gaiser:
> Jan Beulich:
>> Make sure no previously present features are missing after resume (and
>> the re-loading of microcode), to avoid later crashes or (likely silent)
>> hangs / live locks. This doesn't go beyond checking x86_capability[],
>> but this should be good enough for the immediate need of making sure
>> that the BIT mitigation MSRs are still available.
>>
>> Signed-off-by: Jan Beulich 
>>
>> --- a/xen/arch/x86/acpi/power.c
>> +++ b/xen/arch/x86/acpi/power.c
>> @@ -254,6 +254,9 @@ static int enter_state(u32 state)
>>  
>>  microcode_resume_cpu(0);
>>  
>> +if ( !recheck_cpu_features(0) )
>> +panic("Missing previously available feature(s).");
>> +
>>  ci->bti_ist_info = default_bti_ist_info;
>>  asm volatile (ALTERNATIVE("", "wrmsr", X86_FEATURE_XEN_IBRS_SET)
>>:: "a" (SPEC_CTRL_IBRS), "c" (MSR_SPEC_CTRL), "d" (0)
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -501,6 +501,9 @@ void identify_cpu(struct cpuinfo_x86 *c)
>>  printk("\n");
>>  #endif
>>  
>> +if (system_state == SYS_STATE_resume)
>> +return;
>> +
>>  /*
>>   * On SMP, boot_cpu_data holds the common feature set between
>>   * all CPUs; so make sure that we indicate which features are
>> --- a/xen/arch/x86/cpuid.c
>> +++ b/xen/arch/x86/cpuid.c
>> @@ -473,6 +473,28 @@ void __init init_guest_cpuid(void)
>>  calculate_hvm_max_policy();
>>  }
>>  
>> +bool recheck_cpu_features(unsigned int cpu)
>> +{
>> +bool okay = true;
>> +struct cpuinfo_x86 c;
>> +const struct cpuinfo_x86 *bsp = _cpu_data;
>> +unsigned int i;
>> +
>> +identify_cpu();
> 
> This runs into a bug in identify_cpu(). x86_vendor_id does not get
> zeroed, so the x86_vendor_id is not null terminated and the vendor
> identification fails.
> 
> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
> index 4feaa2ceb6..5750d26216 100644
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -366,8 +366,8 @@ void identify_cpu(struct cpuinfo_x86 *c)
> c->x86_vendor = X86_VENDOR_UNKNOWN;
> c->cpuid_level = -1;/* CPUID not detected */
> c->x86_model = c->x86_mask = 0; /* So far unknown... */
> -   c->x86_vendor_id[0] = '\0'; /* Unset */
> -   c->x86_model_id[0] = '\0';  /* Unset */
> +   memset(>x86_vendor_id, 0, sizeof(c->x86_vendor_id));
> +   memset(>x86_model_id, 0, sizeof(c->x86_model_id));
> c->x86_max_cores = 1;
> c->x86_num_siblings = 1;
> c->x86_clflush_size = 0;
> 
> With this patch it works for me.

Meh, also a backport failure from me. Since e34bc403c3c7 this problem
should not appear since it does not assume a null terminated string.



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

Re: [Xen-devel] [PATCH 2/2] x86/microcode: Do not upload microcode if CPUs are offline

[Borislav Petkov]

On Fri, Apr 13, 2018 at 10:57:46AM -0700, Raj, Ashok wrote:
> > I'm afraid I don't fully agree - not applying an ucode update to the online
> > CPUs because some are offline isn't any better. Plus (while updating)
> > there's always going to be some discrepancy between ucode versions.
> > As long as we apply updates while bringing a CPU online, I think we're fine.

When a core is soft-offlined as we do it, it doesn't mean that it
doesn't execute instructions...

> This is the safest option. Microcode is considered part of the cpu. We don't
> allow cpus with different capabilities in the same system.. yes they might
> work, but not something we allow.

... so yes, we better be safe than having to debug some insane lockups.

> In general we recommend early update. Earliest the best. 
> 
> - BIOS update (difficult to deploy, but some microcodes have to be done
>   this way.)
> - early update from initrd.. almost same as #1, since we apply at earliest
>   chance that's the closest and most recommended method.
> - late update. Before this procedure of stopping all cpus, we did have a 
>   time when some are updated and some werent uptodate yet. This synchronized
>   update is precicely to get as close as possible to updating all of them.

Yap.

> > Also please consider valid cases you make not work anymore, like someone
> > having brought offline all sibling hyperthreads, with each core still having
> > one thread active. In that case an ucode update will implicitly update all
> > offline threads as well.

That's some strange use case which I can't imagine worked, like ever.
Because the microcode engine is shared between the HT threads so no
matter on which of the hyperthreads you update, the same, one and only
engine gets updated.

> Of cource we can tweak this to be much better, there are other ideas, but
> this is an effort to keep this simple, and also address microcode requirements
> post spectre for some processors.  In the grand scheme of things although its
> interesting to allow such updates we think it may not be best practice.
> 
> We want to get this working right first before getting fancy.

Ack.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

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

Re: [Xen-devel] [PATCH 2/3] x86: suppress BTI mitigations around S3 suspend/resume

[Simon Gaiser]

Andrew Cooper:
> On 13/04/18 19:25, Simon Gaiser wrote:
>> Jan Beulich:
>>> NMI and #MC can occur at any time after S3 resume, yet the MSR_SPEC_CTRL
>>> may become available only once we're reloaded microcode. Make
>>> SPEC_CTRL_ENTRY_FROM_INTR_IST and DO_SPEC_CTRL_EXIT_TO_XEN no-ops for
>>> the critical period of time.
>>>
>>> Also set the MSR back to its intended value.
>>>
>>> Signed-off-by: Jan Beulich 
>>>
>>> --- a/xen/arch/x86/acpi/power.c
>>> +++ b/xen/arch/x86/acpi/power.c
>>> @@ -28,6 +28,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  
>>>  uint32_t system_reset_counter = 1;
>>> @@ -163,6 +164,7 @@ static int enter_state(u32 state)
>>>  {
>>>  unsigned long flags;
>>>  int error;
>>> +struct cpu_info *ci;
>>>  unsigned long cr4;
>>>  
>>>  if ( (state <= ACPI_STATE_S0) || (state > ACPI_S_STATES_MAX) )
>>> @@ -210,6 +212,10 @@ static int enter_state(u32 state)
>>>  else
>>>  error = 0;
>>>  
>>> +ci = get_cpu_info();
>>> +ci->use_shadow_spec_ctrl = 0;
>>> +ci->bti_ist_info = 0;
>>> +
>>>  ACPI_FLUSH_CPU_CACHE();
>>>  
>>>  switch ( state )
>>> @@ -248,6 +254,11 @@ static int enter_state(u32 state)
>>>  
>>>  microcode_resume_cpu(0);
>>>  
>>> +ci->bti_ist_info = default_bti_ist_info;
>>> +asm volatile (ALTERNATIVE("", "wrmsr", X86_FEATURE_XEN_IBRS_SET)
>> This does not compile for me:
>>
>>   power.c: Assembler messages:
>>   power.c:272: Error: value of 257 too large for field of 1 bytes at 0
>>
>> Changing the alternative based on the other "wrmsr" calls fixes it:
>>
>>   asm volatile (ALTERNATIVE(ASM_NOP3, "wrmsr", X86_FEATURE_XEN_IBRS_SET)
> 
> Ah - you're presumably back-porting this to 4.8?
> 
> Jan's code is correct for staging, and your version here is correct for
> all currently-released versions of Xen.  (I've done quite a lot of
> playing with alternatives generation for 4.11.)

Yeah, sorry, I should have checked if it works with staging.



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

Re: [Xen-devel] [PATCH 3/3] x86: check feature flags after resume

[Simon Gaiser]

Jan Beulich:
> Make sure no previously present features are missing after resume (and
> the re-loading of microcode), to avoid later crashes or (likely silent)
> hangs / live locks. This doesn't go beyond checking x86_capability[],
> but this should be good enough for the immediate need of making sure
> that the BIT mitigation MSRs are still available.
> 
> Signed-off-by: Jan Beulich 
> 
> --- a/xen/arch/x86/acpi/power.c
> +++ b/xen/arch/x86/acpi/power.c
> @@ -254,6 +254,9 @@ static int enter_state(u32 state)
>  
>  microcode_resume_cpu(0);
>  
> +if ( !recheck_cpu_features(0) )
> +panic("Missing previously available feature(s).");
> +
>  ci->bti_ist_info = default_bti_ist_info;
>  asm volatile (ALTERNATIVE("", "wrmsr", X86_FEATURE_XEN_IBRS_SET)
>:: "a" (SPEC_CTRL_IBRS), "c" (MSR_SPEC_CTRL), "d" (0)
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -501,6 +501,9 @@ void identify_cpu(struct cpuinfo_x86 *c)
>   printk("\n");
>  #endif
>  
> + if (system_state == SYS_STATE_resume)
> + return;
> +
>   /*
>* On SMP, boot_cpu_data holds the common feature set between
>* all CPUs; so make sure that we indicate which features are
> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -473,6 +473,28 @@ void __init init_guest_cpuid(void)
>  calculate_hvm_max_policy();
>  }
>  
> +bool recheck_cpu_features(unsigned int cpu)
> +{
> +bool okay = true;
> +struct cpuinfo_x86 c;
> +const struct cpuinfo_x86 *bsp = _cpu_data;
> +unsigned int i;
> +
> +identify_cpu();

This runs into a bug in identify_cpu(). x86_vendor_id does not get
zeroed, so the x86_vendor_id is not null terminated and the vendor
identification fails.

diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 4feaa2ceb6..5750d26216 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -366,8 +366,8 @@ void identify_cpu(struct cpuinfo_x86 *c)
c->x86_vendor = X86_VENDOR_UNKNOWN;
c->cpuid_level = -1;/* CPUID not detected */
c->x86_model = c->x86_mask = 0; /* So far unknown... */
-   c->x86_vendor_id[0] = '\0'; /* Unset */
-   c->x86_model_id[0] = '\0';  /* Unset */
+   memset(>x86_vendor_id, 0, sizeof(c->x86_vendor_id));
+   memset(>x86_model_id, 0, sizeof(c->x86_model_id));
c->x86_max_cores = 1;
c->x86_num_siblings = 1;
c->x86_clflush_size = 0;

With this patch it works for me.

> +
> +for ( i = 0; i < NCAPINTS; ++i )
> +{
> +if ( !(~c.x86_capability[i] & bsp->x86_capability[i]) )
> +continue;
> +
> +printk(XENLOG_ERR "CPU%u: cap[%2u] is %08x (expected %08x)\n",
> +   cpu, i, c.x86_capability[i], bsp->x86_capability[i]);
> +okay = false;
> +}
> +
> +return okay;
> +}
> +
>  const uint32_t *lookup_deep_deps(uint32_t feature)
>  {
>  static const struct {
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -90,11 +90,14 @@ void initialize_cpu_data(unsigned int cp
>  cpu_data[cpu] = boot_cpu_data;
>  }
>  
> -static void smp_store_cpu_info(int id)
> +static bool smp_store_cpu_info(unsigned int id)
>  {
>  unsigned int socket;
>  
> -identify_cpu(_data[id]);
> +if ( system_state != SYS_STATE_resume )
> +identify_cpu(_data[id]);
> +else if ( !recheck_cpu_features(id) )
> +return false;
>  
>  socket = cpu_to_socket(id);
>  if ( !socket_cpumask[socket] )
> @@ -102,6 +105,8 @@ static void smp_store_cpu_info(int id)
>  socket_cpumask[socket] = secondary_socket_cpumask;
>  secondary_socket_cpumask = NULL;
>  }
> +
> +return true;
>  }
>  
>  /*
> @@ -187,12 +192,19 @@ static void smp_callin(void)
>  setup_local_APIC();
>  
>  /* Save our processor parameters. */
> -smp_store_cpu_info(cpu);
> +if ( !smp_store_cpu_info(cpu) )
> +{
> +printk("CPU%u: Failed to validate features - not coming back 
> online\n",
> +   cpu);
> +cpu_error = -ENXIO;
> +goto halt;
> +}
>  
>  if ( (rc = hvm_cpu_up()) != 0 )
>  {
>  printk("CPU%d: Failed to initialise HVM. Not coming online.\n", cpu);
>  cpu_error = rc;
> +halt:
>  clear_local_APIC();
>  spin_debug_enable();
>  cpu_exit_clear(cpu);
> --- a/xen/include/asm-x86/cpuid.h
> +++ b/xen/include/asm-x86/cpuid.h
> @@ -253,6 +253,9 @@ static inline void cpuid_featureset_to_p
>  extern struct cpuid_policy raw_cpuid_policy, host_cpuid_policy,
>  pv_max_cpuid_policy, hvm_max_cpuid_policy;
>  
> +/* Check that all previously present features are still available. */
> +bool recheck_cpu_features(unsigned int cpu);
> +
>  /* Allocate and initialise a CPUID policy suitable for the domain. */
>  int init_domain_cpuid_policy(struct domain *d);
>  



signature.asc
Description: OpenPGP digital signature

[Xen-devel] [xen-unstable-smoke test] 122258: regressions - trouble: blocked/fail

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm   6 xen-buildfail REGR. vs. 122174
 build-amd64   6 xen-buildfail REGR. vs. 122174
 build-armhf   6 xen-buildfail REGR. vs. 122174

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-i386  1 build-check(1) blocked n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a

version targeted for testing:
 xen  ba2931d4e38fac4e6960e10b245efd3badeb4aa2
baseline version:
 xen  82540b66ceb9318aa185f2488cbbbe479694de8f

Last test of basis   122174  2018-04-11 11:01:17 Z2 days
Failing since122191  2018-04-12 16:01:30 Z1 days   12 attempts
Testing same since   122193  2018-04-12 17:01:11 Z1 days   11 attempts


People who touched revisions under test:
  George Dunlap 
  Ian Jackson 
  Konrad Rzeszutek Wilk 
  Lars Kurth 
  Oleksandr Andrushchenko 
  Oleksandr Grytsov 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit ba2931d4e38fac4e6960e10b245efd3badeb4aa2
Author: Oleksandr Andrushchenko 
Date:   Wed Mar 7 10:21:20 2018 +0200

sndif: Add explicit back and front parameter negotiation

In order to provide explicit stream parameter negotiation between
backend and frontend the following changes are introduced in the protocol:
add XENSND_OP_HW_PARAM_QUERY request to read/update
configuration space for the parameter given: request passes
desired parameter interval (mask) and the response to this request
returns min/max interval (mask) for the parameter to be used.

Parameters supported by this request/response:
 - format mask
 - sample rate interval
 - number of channels interval
 - buffer size, interval, frames
 - period size, interval, frames

Signed-off-by: Oleksandr Andrushchenko 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Takashi Iwai 
Cc: Konrad Rzeszutek Wilk 
Cc: Takashi Iwai 
Signed-off-by: Konrad Rzeszutek Wilk 
Release-acked-by: Juergen Gross 

commit 41b4cff11f4c4a497067f543cb010d70119f1843
Author: Oleksandr Andrushchenko 
Date:   Mon Feb 5 09:41:57 2018 +0200

sndif: Add explicit back and front synchronization

In order to provide explicit synchronization between backend and
frontend the following changes are introduced in the protocol:
 - add new ring buffer for sending asynchronous events from
   backend to frontend to report number of bytes played by the
   frontend (XENSND_EVT_CUR_POS)
 - introduce trigger events for playback control: start/stop/pause/resume
 - add "req-" prefix to event-channel and ring-ref to unify naming
   of the Xen event channels for requests and events

Signed-off-by: Oleksandr Andrushchenko 
Signed-off-by: Oleksandr Grytsov 

Re: [Xen-devel] [PATCH 2/3] x86: suppress BTI mitigations around S3 suspend/resume

[Simon Gaiser]

Jan Beulich:
> NMI and #MC can occur at any time after S3 resume, yet the MSR_SPEC_CTRL
> may become available only once we're reloaded microcode. Make
> SPEC_CTRL_ENTRY_FROM_INTR_IST and DO_SPEC_CTRL_EXIT_TO_XEN no-ops for
> the critical period of time.
> 
> Also set the MSR back to its intended value.
> 
> Signed-off-by: Jan Beulich 
> 
> --- a/xen/arch/x86/acpi/power.c
> +++ b/xen/arch/x86/acpi/power.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  uint32_t system_reset_counter = 1;
> @@ -163,6 +164,7 @@ static int enter_state(u32 state)
>  {
>  unsigned long flags;
>  int error;
> +struct cpu_info *ci;
>  unsigned long cr4;
>  
>  if ( (state <= ACPI_STATE_S0) || (state > ACPI_S_STATES_MAX) )
> @@ -210,6 +212,10 @@ static int enter_state(u32 state)
>  else
>  error = 0;
>  
> +ci = get_cpu_info();
> +ci->use_shadow_spec_ctrl = 0;
> +ci->bti_ist_info = 0;
> +
>  ACPI_FLUSH_CPU_CACHE();
>  
>  switch ( state )
> @@ -248,6 +254,11 @@ static int enter_state(u32 state)
>  
>  microcode_resume_cpu(0);
>  
> +ci->bti_ist_info = default_bti_ist_info;
> +asm volatile (ALTERNATIVE("", "wrmsr", X86_FEATURE_XEN_IBRS_SET)

This does not compile for me:

  power.c: Assembler messages:
  power.c:272: Error: value of 257 too large for field of 1 bytes at 0

Changing the alternative based on the other "wrmsr" calls fixes it:

  asm volatile (ALTERNATIVE(ASM_NOP3, "wrmsr", X86_FEATURE_XEN_IBRS_SET)

> +  :: "a" (SPEC_CTRL_IBRS), "c" (MSR_SPEC_CTRL), "d" (0)
> +  : "memory");
> +
>   done:
>  spin_debug_enable();
>  local_irq_restore(flags);



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

Re: [Xen-devel] [PATCH 7/8] x86/SVM: Introduce svm command line option

[Andrew Cooper]

On 04/04/18 00:01, Janakarajan Natarajan wrote:
> From: Suravee Suthikulpanit 
>
> This patch introduces a new Xen command line option to enable/disable
> SVM sub-options. Currently, it support sub-option "avic", which can
> be used to enable/disable SVM AVIC feature.
>
> Signed-off-by: Suavee Suthikulpant 
> Signed-off-by: Janakarajan Natarajan 
> ---
>  docs/misc/xen-command-line.markdown | 16 
>  xen/arch/x86/hvm/svm/svm.c  | 32 
>  2 files changed, 48 insertions(+)
>
> diff --git a/docs/misc/xen-command-line.markdown 
> b/docs/misc/xen-command-line.markdown
> index b353352adf..60a1005c42 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1730,6 +1730,22 @@ enforces the maximum theoretically necessary timeout 
> of 670ms. Any number
>  is being interpreted as a custom timeout in milliseconds. Zero or boolean
>  false disable the quirk workaround, which is also the default.
>  
> +### svm
> +> `= List of [ avic ]`
> +
> +> Sub-options:
> +
> +> All sub-options are of boolean kind and can be prefixed with `no-` to
> +> effect the inverse meaning.
> +
> +> `avic`
> +
> +> Default: `false`
> +
> +>> This option enables Advanced Virtual Interrupt Controller (AVIC),
> +>> which is an extension of AMD Secure Virtual Machine (SVM) to virtualize
> +>> local APIC for guest VM.
> +
>  ### sync\_console
>  > `= `
>  
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> index fdbe8e3008..0c5c26cce8 100644
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -64,6 +64,16 @@
>  #include 
>  #include 
>  
> +static int parse_svm_param(const char *s);
> +
> +/*
> + * The 'svm' parameter en/dis-ables various SVM features.
> + * Optional comma separated value may contain:
> + *
> + *   avic - Enable SVM Advanced Virtual Interrupt Controller (AVIC)
> + */
> +custom_param("svm", parse_svm_param);

Move this custom_param to below the definition, and drop the forward
declaration.  You can drop the comment here, because the important
information is in the real command line doc.

> +
>  void svm_asm_do_resume(void);
>  
>  u32 svm_feature_flags;
> @@ -89,6 +99,28 @@ static bool_t amd_erratum383_found __read_mostly;
>  static uint64_t osvw_length, osvw_status;
>  static DEFINE_SPINLOCK(osvw_lock);
>  
> +static int __init parse_svm_param(const char *s)
> +{
> +char *ss;
> +int val;
> +
> +do {
> +val = !!strncmp(s, "no-", 3);
> +if ( !val )
> +s += 3;
> +
> +ss = strchr(s, ',');
> +if ( ss )
> +*ss = '\0';

This is writing to a const pointer.  strchr() is a particularly evil
part of the C standard library, because it drops const from its input
parameter.

See parse_xen_cpuid() for a similar piece of functionality, and please
use the parse_boolean() helper.

~Andrew

> +
> +if ( !strcmp(s, "avic") )
> +svm_avic = val;
> +
> +s = ss + 1;
> +} while ( ss );
> +
> +return 0;
> +}
>  /* Only crash the guest if the problem originates in kernel mode. */
>  static void svm_crash_or_fault(struct vcpu *v)
>  {


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

Re: [Xen-devel] [PATCH 4/8] x86/SVM: Add vcpu scheduling support for AVIC

[Andrew Cooper]

On 04/04/18 00:01, Janakarajan Natarajan wrote:
> @@ -63,6 +64,54 @@ avic_get_physical_id_entry(struct svm_domain *d, unsigned 
> int index)
>  return >avic_physical_id_table[index];
>  }
>  
> +static void avic_vcpu_load(struct vcpu *v)
> +{
> +unsigned long tmp;
> +struct arch_svm_struct *s = >arch.hvm_svm;
> +int h_phy_apic_id;
> +struct avic_physical_id_entry *entry = (struct avic_physical_id_entry 
> *)
> +
> +ASSERT(!test_bit(_VPF_blocked, >pause_flags));
> +
> +/*
> + * Note: APIC ID = 0xff is used for broadcast.
> + *   APIC ID > 0xff is reserved.
> + */
> +h_phy_apic_id = cpu_data[v->processor].apicid;
> +ASSERT(h_phy_apic_id < AVIC_PHY_APIC_ID_MAX);
> +
> +tmp = read_atomic((u64*)(s->avic_last_phy_id));
> +entry->host_phy_apic_id = h_phy_apic_id;
> +entry->is_running = 1;
> +write_atomic((u64*)(s->avic_last_phy_id), tmp);

What is the purpose of s->avic_last_phy_id ?

As far as I can tell, it is always an unchanging pointer into the
physical ID table, which is only ever updated synchronously in current
context.

If so, I don't see why it needs any of these hoops to be jumped though.

~Andrew

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

Re: [Xen-devel] [PATCH 2/2] x86/microcode: Do not upload microcode if CPUs are offline

[Raj, Ashok]

Hi Jan

+ Boris

On Fri, Apr 13, 2018 at 09:57:25AM -0600, Jan Beulich wrote:
> >>> On 30.03.18 at 08:59,  wrote:
> > This patch is to backport the patch below from linux kernel.
> > 
> > commit 30ec26da9967d0d785abc24073129a34c3211777
> > Author: Ashok Raj 
> > Date:   Wed Feb 28 11:28:43 2018 +0100
> > 
> > x86/microcode: Do not upload microcode if CPUs are offline
> > 
> > Avoid loading microcode if any of the CPUs are offline, and issue a
> > warning. Having different microcode revisions on the system at any 
> > time
> > is outright dangerous.
> 
> I'm afraid I don't fully agree - not applying an ucode update to the online
> CPUs because some are offline isn't any better. Plus (while updating)
> there's always going to be some discrepancy between ucode versions.
> As long as we apply updates while bringing a CPU online, I think we're fine.

This is the safest option. Microcode is considered part of the cpu. We don't
allow cpus with different capabilities in the same system.. yes they might
work, but not something we allow. 

In general we recommend early update. Earliest the best. 

- BIOS update (difficult to deploy, but some microcodes have to be done
  this way.)
- early update from initrd.. almost same as #1, since we apply at earliest
  chance that's the closest and most recommended method.
- late update. Before this procedure of stopping all cpus, we did have a 
  time when some are updated and some werent uptodate yet. This synchronized
  update is precicely to get as close as possible to updating all of them.
> 
> Also please consider valid cases you make not work anymore, like someone
> having brought offline all sibling hyperthreads, with each core still having
> one thread active. In that case an ucode update will implicitly update all
> offline threads as well.

Of cource we can tweak this to be much better, there are other ideas, but
this is an effort to keep this simple, and also address microcode requirements
post spectre for some processors.  In the grand scheme of things although its
interesting to allow such updates we think it may not be best practice.

We want to get this working right first before getting fancy.

Cheers,
Ashok

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

Re: [Xen-devel] Setting up a call to discuss PCI Emulation - Future Direction

[Roger Pau Monné]

On Fri, Apr 13, 2018 at 12:59:15PM +0100, Lars Kurth wrote:
> 
> 
> On 13/04/2018, 11:01, "Roger Pau Monne"  wrote:
> 
> On Thu, Apr 12, 2018 at 05:50:00PM +0100, Lars Kurth wrote:
> > 
> > 
> > On 12/04/2018, 17:41, "Roger Pau Monne"  wrote:
> > 
> > On Thu, Apr 12, 2018 at 05:32:57PM +0100, Lars Kurth wrote:
> > 
> > 
> > >may work. For me Mon, Wed and Fri’s generally work at those 
> time-slots.
> > >Next week is a little busy for me, so I would prefer the 
> following week.
> > >If you could fill out the following Google poll, if this week 
> works that
> > >would be great. Otherwise please scream.
> > 
> > I'm afraid I'm on vacations from the 21st to the 29th of April, so I
> > won't be able to join the meeting unless we move it to the week 
> after.
> > Let's see what people think of the current dates.
> > 
> > Roger.
> > 
> > Hi, I changed the dates to the week after. Poll so far has been 
> invalidated.
> > 
> > See https://doodle.com/poll/gdnmcrvnibmw563n
> 
> Thanks! I've already fixed my vote.
> 
> I guess this will come later, but we need a clear agenda of items
> because the x86 and ARM topics are probably going to be completely
> different (albeit all related to PCI).
> 
> Royger: I am OK with trying to get a draft agenda in place in this e-mail 
> thread. But I can't drive this, as I don’t understand the issues. But I am 
> happy to collate everything as for the x86 call and write up minutes

On the x86 side:

 - Q35 HVM emulation, adding MCFG support to guests.
 - PVH guest pci-passthrough: using the internal vPCI infrastructure.

At least that I can think of ATM.

Roger.

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

Re: [Xen-devel] [PATCH 3/8] x86/SVM: Add AVIC vmexit handlers

[Andrew Cooper]

On 04/04/18 00:01, Janakarajan Natarajan wrote:
> From: Suravee Suthikulpanit 
>
> AVIC introduces two new #vmexit handlers:
>
> VMEXIT_INCOMP_IPI:
> This occurs when an IPI could not be delivered to all targeted guest
> virtual processors because at least one guest virtual processor
> was not allocated to a physical core at the time. In this case,
> Xen would try to emulate IPI.
>
> VMEXIT_DO_NOACCEL:
> This occurs when a guest access to an APIC register that cannot be
> accelerated by AVIC. In this case, Xen tries to emulate register accesses.
>
> This fault is also generated if an EOI is attempted when the highest priority
> in-service interrupt is set for level-triggered mode.
>
> This patch also declare vlapic_read_aligned() and vlapic_reg_write()
> as non-static to expose them to be used by AVIC.
>
> Signed-off-by: Suravee Suthikulpanit 
> Signed-off-by: Janakarajan Natarajan 
> ---
>  xen/arch/x86/hvm/svm/avic.c| 296 
> +
>  xen/arch/x86/hvm/svm/svm.c |   8 +
>  xen/arch/x86/hvm/vlapic.c  |   4 +-
>  xen/include/asm-x86/hvm/svm/avic.h |   3 +
>  xen/include/asm-x86/hvm/svm/vmcb.h |   6 +
>  xen/include/asm-x86/hvm/vlapic.h   |   4 +
>  6 files changed, 319 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/svm/avic.c b/xen/arch/x86/hvm/svm/avic.c
> index 8108698911..e112469774 100644
> --- a/xen/arch/x86/hvm/svm/avic.c
> +++ b/xen/arch/x86/hvm/svm/avic.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -37,6 +38,8 @@
>  
>  #define AVIC_VAPIC_BAR_MASK (((1ULL << 40) - 1) << PAGE_SHIFT)
>  
> +#define AVIC_UNACCEL_ACCESS_OFFSET_MASK0xFF0
> +
>  /*
>   * Note:
>   * Currently, svm-avic mode is not supported with nested virtualization.
> @@ -101,6 +104,8 @@ int svm_avic_dom_init(struct domain *d)
>  d->arch.hvm_domain.svm.avic_physical_id_table_pg = pg;
>  d->arch.hvm_domain.svm.avic_physical_id_table = 
> __map_domain_page_global(pg);
>  
> +spin_lock_init(>arch.hvm_domain.svm.avic_dfr_mode_lock);
> +
>  return ret;
>   err_out:
>  svm_avic_dom_destroy(d);
> @@ -181,6 +186,297 @@ int svm_avic_init_vmcb(struct vcpu *v)
>  }
>  
>  /*
> + * Note:
> + * This function handles the AVIC_INCOMP_IPI #vmexit when AVIC is enabled.
> + * The hardware generates this fault when an IPI could not be delivered
> + * to all targeted guest virtual processors because at least one guest
> + * virtual processor was not allocated to a physical core at the time.
> + */
> +void svm_avic_vmexit_do_incomp_ipi(struct cpu_user_regs *regs)
> +{
> +struct vcpu *curr = current;
> +struct domain *currd = curr->domain;
> +struct vmcb_struct *vmcb = curr->arch.hvm_svm.vmcb;
> +u32 icrh = vmcb->exitinfo1 >> 32;
> +u32 icrl = vmcb->exitinfo1;
> +u32 id = vmcb->exitinfo2 >> 32;
> +u32 index = vmcb->exitinfo2 && 0xFF;
> +
> +switch ( id )
> +{
> +case AVIC_INCMP_IPI_ERR_INVALID_INT_TYPE:
> +/*
> + * AVIC hardware handles the delivery of
> + * IPIs when the specified Message Type is Fixed
> + * (also known as fixed delivery mode) and
> + * the Trigger Mode is edge-triggered. The hardware
> + * also supports self and broadcast delivery modes
> + * specified via the Destination Shorthand(DSH)
> + * field of the ICRL. Logical and physical APIC ID
> + * formats are supported. All other IPI types cause
> + * a #VMEXIT, which needs to emulated.
> + */
> +vlapic_reg_write(curr, APIC_ICR2, icrh);
> +vlapic_reg_write(curr, APIC_ICR, icrl);
> +break;
> +
> +case AVIC_INCMP_IPI_ERR_TARGET_NOT_RUN:
> +{
> +/*
> + * At this point, we expect that the AVIC HW has already
> + * set the appropriate IRR bits on the valid target
> + * vcpus. So, we just need to kick the appropriate vcpu.
> + */
> +struct vcpu *v;
> +uint32_t dest = GET_xAPIC_DEST_FIELD(icrh);
> +uint32_t short_hand = icrl & APIC_SHORT_MASK;
> +bool dest_mode = !!(icrl & APIC_DEST_MASK);

No need for !!.  It is the explicit behaviour of the bool type.

> +
> +for_each_vcpu ( currd,  v )
> +{
> +if ( v != curr &&
> + vlapic_match_dest(vcpu_vlapic(v), vcpu_vlapic(curr),
> +   short_hand, dest, dest_mode) )
> +{
> +vcpu_kick(v);
> +break;
> +}
> +}
> +break;
> +}
> +
> +case AVIC_INCMP_IPI_ERR_INV_TARGET:
> +gprintk(XENLOG_ERR,
> +"SVM: %s: Invalid IPI target (icr=%#08x:%08x, idx=%u)\n",
> +__func__, icrh, icrl, index);
> +domain_crash(currd);
> +break;
> +
> +case AVIC_INCMP_IPI_ERR_INV_BK_PAGE:
> 

Re: [Xen-devel] [RFC PATCH 1/2] Add Designated Reviewer (R:) to MAINTAINERS file and add support for it in get_maintainer.pl

[Ian Jackson]

Lars Kurth writes ("Re: [RFC PATCH 1/2] Add Designated Reviewer (R:) to 
MAINTAINERS file and add support for it in get_maintainer.pl"):
> I don't know whether it is needed. The same code block of code is in Linux 
> and 
> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=scripts/get_maintainer.pl;h=3fb1ad4b694d68d5f90ad642420d4b50b934ed2b;hb=HEAD
>   line 1082 onwards

Linux's MAINTAINERS says this:

P: Person (obsolete)

The code seems to be doing some kind of indirection.  I suggest we
drop it.  At the very least, we should not make any more copies of
this!

Ian.

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

Re: [Xen-devel] [RFC PATCH 1/2] Add Designated Reviewer (R:) to MAINTAINERS file and add support for it in get_maintainer.pl

[Lars Kurth]

On 13/04/2018, 18:14, "Ian Jackson"  wrote:

Lars Kurth writes ("[RFC PATCH 1/2] Add Designated Reviewer (R:) to 
MAINTAINERS file and add support for it in get_maintainer.pl"):
> The syntax has been copied from the Linux Maintainers file. I moved the 
following Linux
> get_maintainer.pl patches to Xen, fixing up some merge issues (and a bug).
...
>   'm!' => \$email_maintainer,
> +'r!' => \$email_reviewer,
>   'n!' => \$email_usename,

Your text editor has some difficulty with the tabs here, resulting in
misalignment.  Set its tab width to 8 and reindent.

I noticed: will fix.

> +} elsif ($ptype eq "R") {
> +my ($name, $address) = parse_email($pvalue);
> +if ($name eq "") {
> +if ($i > 0) {
> +my $tv = $typevalue[$i - 1];
> +if ($tv =~ m/^([A-Z]):\s*(.*)/) {
> +if ($1 eq "P") {
> +$name = $2;
> +$pvalue = format_email($name, $address, $email_usename);
> +}
> +}
> +}
> +}

What on earth is all thisif ($name eq "")  stuff doing ?  Is it
appropriate in this case ?

If it is actually needed, you should probably not just cut and paste
it.

I don't know whether it is needed. The same code block of code is in Linux and 
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=scripts/get_maintainer.pl;h=3fb1ad4b694d68d5f90ad642420d4b50b934ed2b;hb=HEAD
  line 1082 onwards

Lars 

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

Re: [Xen-devel] [RFC PATCH 1/2] Add Designated Reviewer (R:) to MAINTAINERS file and add support for it in get_maintainer.pl

[Ian Jackson]

Lars Kurth writes ("[RFC PATCH 1/2] Add Designated Reviewer (R:) to MAINTAINERS 
file and add support for it in get_maintainer.pl"):
> The syntax has been copied from the Linux Maintainers file. I moved the 
> following Linux
> get_maintainer.pl patches to Xen, fixing up some merge issues (and a bug).
...
>   'm!' => \$email_maintainer,
> +'r!' => \$email_reviewer,
>   'n!' => \$email_usename,

Your text editor has some difficulty with the tabs here, resulting in
misalignment.  Set its tab width to 8 and reindent.

> +} elsif ($ptype eq "R") {
> +my ($name, $address) = parse_email($pvalue);
> +if ($name eq "") {
> +if ($i > 0) {
> +my $tv = $typevalue[$i - 1];
> +if ($tv =~ m/^([A-Z]):\s*(.*)/) {
> +if ($1 eq "P") {
> +$name = $2;
> +$pvalue = format_email($name, $address, $email_usename);
> +}
> +}
> +}
> +}

What on earth is all thisif ($name eq "")  stuff doing ?  Is it
appropriate in this case ?

If it is actually needed, you should probably not just cut and paste
it.

Thanks,
Ian.

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

[Xen-devel] [RFC PATCH 1/2] Add Designated Reviewer (R:) to MAINTAINERS file and add support for it in get_maintainer.pl

[Lars Kurth]

The syntax has been copied from the Linux Maintainers file. I moved the 
following Linux
get_maintainer.pl patches to Xen, fixing up some merge issues (and a bug).

The get_maintainer.pl changes were based on the following git commits
* 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/scripts/get_maintainer.pl?id=
* c1c3f2c906e35bcb6e4cdf5b8e077660fead14fe
* 4f07510df2e8c47fd65b8ffaaf6c5d334d59d598

I have tested on a number of files using mock entries in MAINTAINERS
using ./scripts/get_maintainer.pl -f ...

I also tested --nor to disable the support and it worked as expected.

Signed-off-by: Lars Kurth 
---
 MAINTAINERS   |  2 ++
 scripts/get_maintainer.pl | 24 ++--
 2 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index bbda4b9f43..29c0c4b3a7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -60,6 +60,8 @@ appropriate branch.
 Descriptions of section entries:
 
M: Mail patches to: FullName 
+R: Designated reviewer: FullName 
+   These reviewers should be CCed on patches.
L: Mailing list that is relevant to this area
W: Web-page with status/info
T: SCM tree type and location.  Type is one of: git, hg, quilt, stgit.
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index 3fb1ad4b69..85bf518704 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -21,6 +21,7 @@ my $xen_path = "./";
 my $email = 1;
 my $email_usename = 1;
 my $email_maintainer = 1;
+my $email_reviewer = 1;
 my $email_list = 1;
 my $email_subscriber_list = 0;
 my $email_git_penguin_chiefs = 0;
@@ -199,6 +200,7 @@ if (!GetOptions(
'mailmap!' => \$email_use_mailmap,
'drop_the_rest_supporter!' => 
\$email_drop_the_rest_supporter_if_supporter_found,
'm!' => \$email_maintainer,
+'r!' => \$email_reviewer,
'n!' => \$email_usename,
'l!' => \$email_list,
's!' => \$email_subscriber_list,
@@ -257,7 +259,8 @@ if ($sections) {
 }
 
 if ($email &&
-($email_maintainer + $email_list + $email_subscriber_list +
+($email_maintainer + $email_reviewer +
+ $email_list + $email_subscriber_list +
  $email_git + $email_git_penguin_chiefs + $email_git_blame) == 0) {
 die "$P: Please select at least 1 email option\n";
 }
@@ -791,6 +794,7 @@ MAINTAINER field selection options:
 --hg-since => hg history to use (default: $email_hg_since)
 --interactive => display a menu (mostly useful if used with the --git 
option)
 --m => include maintainer(s) if any
+--r => include reviewer(s) if any
 --n => include name 'Full Name '
 --l => include list(s) if any
 --s => include subscriber only list(s) if any
@@ -817,7 +821,7 @@ Other options:
   --help => show this help information
 
 Default options:
-  [--email --nogit --git-fallback --m --n --l --multiline -pattern-depth=0
+  [--email --nogit --git-fallback --m --r --n --l --multiline -pattern-depth=0
--remove-duplicates --rolestats]
 
 Notes:
@@ -1095,6 +1099,22 @@ sub add_categories {
my $role = get_maintainer_role($i);
push_email_addresses($pvalue, $role);
}
+} elsif ($ptype eq "R") {
+my ($name, $address) = parse_email($pvalue);
+if ($name eq "") {
+if ($i > 0) {
+my $tv = $typevalue[$i - 1];
+if ($tv =~ m/^([A-Z]):\s*(.*)/) {
+if ($1 eq "P") {
+$name = $2;
+$pvalue = format_email($name, $address, $email_usename);
+}
+}
+}
+}
+if ($email_reviewer) {
+push_email_addresses($pvalue, 'reviewer');
+}
} elsif ($ptype eq "T") {
push(@scm, $pvalue);
} elsif ($ptype eq "W") {
-- 
2.13.0


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

[Xen-devel] [RFC PATCH 0/2] Add Designated Reviewer (R:) to MAINTAINERS (using a test case)

[Lars Kurth]

This follows up from a conversation after the April x86 community call, in 
which I had
the following action: Lars to propose fixing CC issue in xen.git:MAINTAINERS 
copying 
the R section entries from Linux.git:MAINTAINERS (will need changes to 
get_maintainers.pl also)

Lars Kurth (2):
  Add Designated Reviewer (R:) to MAINTAINERS file and add support for
it in get_maintainer.pl
  Add Brian Woods as Designated reviewer to AMD IOMMU and AMD SVM

 MAINTAINERS   |  4 
 scripts/get_maintainer.pl | 24 ++--
 2 files changed, 26 insertions(+), 2 deletions(-)

-- 
2.13.0


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

[Xen-devel] [RFC PATCH 2/2] Add Brian Woods as Designated reviewer to AMD IOMMU and AMD SVM

[Lars Kurth]

This was discussed in an IRC discussion post the April x86 meeting.

Signed-off-by: Lars Kurth 
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 29c0c4b3a7..eb2c78ee43 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -144,12 +144,14 @@ F:tools/libacpi/
 
 AMD IOMMU
 M: Suravee Suthikulpanit 
+R: Brian Woods 
 S: Maintained
 F: xen/drivers/passthrough/amd/
 
 AMD SVM
 M: Boris Ostrovsky 
 M: Suravee Suthikulpanit 
+R: Brian Woods 
 S: Supported
 F: xen/arch/x86/hvm/svm/
 F: xen/arch/x86/cpu/vpmu_amd.c
-- 
2.13.0


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

Re: [Xen-devel] [PATCH 0/8] Introduce AMD SVM AVIC

[Brian Woods]

On Tue, Apr 03, 2018 at 06:01:16PM -0500, Janakarajan Natarajan wrote:
> OVERVIEW
> 
> This patchset is the first of a two-part patch series to introduce
> the AMD Advanced Virtual Interrupt Controller (AVIC) support.
> 
> The AVIC hardware virtualizes local APIC registers of each vCPU via
> the virtual APIC (vAPIC) backing page. This allows the guest to access
> certain APIC registers without the need for emulation of hardware
> behaviour in the hypervisor. More information about AVIC can be found in
> 
> * AMD64 Architecture Programmers Manual Volume 2 - System Programming
>   https://support.amd.com/TechDocs/24593.pdf
> 
> For SVM AVIC, we extend the existing SVM driver to:
> * Check CPUID to detect AVIC support in the processor.
> * Program new fields in VMCB to enable AVIC.
> * Introduce new AVIC data structures and add code to manage them.
> * Handle two new AVIC #VMEXITs.
> * Add new interrupt injection code using vAPIC backing page
>   instead of the existing V_IRQ, V_INTR_PRIO, V_INTR_VECTOR and
>   V_IGN_TPR fields.
> 
> This patchset does not enable AVIC by default since it does not
> yet support nested VMs. Until then, users can enable SVM AVIC by
> specifying Xen parameter svm=avic.
> 
> Later, in Part 2, we will introduce the IOMMU AVIC support, which
> provides speed-up for the PCI device passthrough use case by allowing
> the IOMMU hardware to inject interrupts directly into the guest via
> the vAPIC backing page.
> 
> OVERALL PERFORMANCE
> ===
> AVIC is available on AMD Family 15h models 6Xh (Carrizo) processors
> and newer. An AMD Family 17h Epyc processor is used to collect the
> performance data shown below.
> 
> Generally, SVM AVIC alone (w/o IOMMU AVIC) should provide overall
> speed-up for HVM guest since it does not require #VMEXIT into the
> hypervisor to emulate certain guest accesses to local APIC registers.
> 
> It should also improve performance when the hypervisor wants to
> inject interrupts into a running vcpu. It can do this by setting the 
> corresponding IRR bit in the vAPIC backing page and triggering the
> AVIC_DOORBELL.
> 
> For sending IPI interrupts between running vcpus in a Linux guest,
> Xen defaults to using event channels. However, in case of
> non-paravirtualized guests, AVIC can also provide performance
> improvements for sending IPIs.
> 
> BENCHMARK: HACKBENCH
> 
> For measuring IPI performance used for scheduling workload, some
> performance numbers are collected using hackbench.
> 
> # hackbench -p -l 10
> Running in process mode with 10 groups using 40 file descriptors
> each (== 400 tasks)
> Each sender will pass 10 messages of 100 bytes
> |  3 vcpus (sec)|
> --
> No AVIC w/  xen_nopv  |   517 |
> AVIC w/ xen_nopv  |   173 |
> No AVIC w/o xen_nopv  |   141 |
> AVIC w/o xen_nopv |   135 |
> 
> Each benchmark test was averaged over 10 runs.
> 
> CURRENT UNTESTED USE_CASES
> ==
> * Nested VM
> 
> Any feedback and comments are very much appreciated.
> 
> Suravee Suthikulpanit (8):
>   x86/SVM: Modify VMCB fields to add AVIC support
>   x86/HVM/SVM: Add AVIC initialization code
>   x86/SVM: Add AVIC vmexit handlers
>   x86/SVM: Add vcpu scheduling support for AVIC
>   x86/SVM: Add interrupt management code via AVIC
>   x86/HVM: Hook up miscellaneous AVIC functions
>   x86/SVM: Introduce svm command line option
>   x86/SVM: Add AMD AVIC key handler
> 
>  docs/misc/xen-command-line.markdown |  16 +
>  xen/arch/x86/hvm/svm/Makefile   |   1 +
>  xen/arch/x86/hvm/svm/avic.c | 626 
> 
>  xen/arch/x86/hvm/svm/intr.c |   4 +
>  xen/arch/x86/hvm/svm/svm.c  |  77 -
>  xen/arch/x86/hvm/svm/vmcb.c |   3 +
>  xen/arch/x86/hvm/vlapic.c   |  20 +-
>  xen/arch/x86/hvm/vmx/vmx.c  |   8 +-
>  xen/include/asm-x86/hvm/hvm.h   |   4 +-
>  xen/include/asm-x86/hvm/svm/avic.h  |  43 +++
>  xen/include/asm-x86/hvm/svm/svm.h   |   2 +
>  xen/include/asm-x86/hvm/svm/vmcb.h  |  52 ++-
>  xen/include/asm-x86/hvm/vlapic.h|   4 +
>  xen/include/asm-x86/msr-index.h |   1 +
>  14 files changed, 831 insertions(+), 30 deletions(-)
>  create mode 100644 xen/arch/x86/hvm/svm/avic.c
>  create mode 100644 xen/include/asm-x86/hvm/svm/avic.h
> 
> -- 
> 2.11.0
> 

Not a Xen expert by any means but I've looked over the patch set and
nothing jumps out as wrong.

Reviewed-by: Brian Woods 

-- 
Brian Woods

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

Re: [Xen-devel] Weird altp2m behaviour when switching early to a new view

[Razvan Cojocaru]

On 04/13/2018 07:38 PM, Tamas K Lengyel wrote:
> On Fri, Apr 13, 2018 at 8:44 AM, Razvan Cojocaru
>  wrote:
>> On 04/11/2018 11:04 AM, Razvan Cojocaru wrote:
>>> Debugging continues.
>>
>> Finally, the attached patch seems to get the display unstuck in my
>> scenario, although for one guest I get:
>>
>> (XEN) d2v0 Unexpected vmexit: reason 49
>> (XEN) domain_crash called from vmx.c:4120
>> (XEN) Domain 2 (vcpu#0) crashed on cpu#1:
>> (XEN) [ Xen-4.11-unstable  x86_64  debug=y   Not tainted ]
>> (XEN) CPU:1
>> (XEN) RIP:0010:[]
>> (XEN) RFLAGS: 00010246   CONTEXT: hvm guest (d2v0)
>> (XEN) rax: f8800300   rbx: f900c0083db0   rcx: aa55aa55
>> (XEN) rdx: fa80041bdc41   rsi: f900c00c69a0   rdi: 0001
>> (XEN) rbp:    rsp: f88002ee9ef0   r8:  fa80041bdc40
>> (XEN) r9:  f80001810e80   r10: fa800342aa70   r11: f88002ee9e80
>> (XEN) r12: 0005   r13: 0001   r14: f900c00c08b0
>> (XEN) r15: 0001   cr0: 80050031   cr4: 000406f8
>> (XEN) cr3: ef771000   cr2: f900c00c8000
>> (XEN) fsb: fffde000   gsb: f80001810d00   gss: 07fdc000
>> (XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
>>
>> i.e. EXIT_REASON_EPT_MISCONFIG - so not of the woods yet. I am hoping
>> somebody more familiar with the code can point to a more elegant
>> solution if one exists.
> 
> I dare say at this point you might just be that person :) I looked at
> the patch, one issue with p2m_change_type_range in its current form is
> that it's unclear how it would behave when the range contains remapped
> gfns in an altp2m (either a page that remaps to this range, or a page
> that remaps from the range). According to the current altp2m approach
> I would say the altp2m views should probably just get completely reset
> if there is such a remapping.

Yes, it's all quite complex.

Actually, for one I think I should set p2m->max_mapped_pfn =
hostp2m->max_mapped_pfn; at switch-time rather than at
p2m_init_altp2m_ept() time, for obvious reasons. I wonder if the sane
behaviour here isn't to always copy everything from the active view to
the view we're switching to (whatever "copy everything" means, I'm fuzzy
on this myself).

Also, looking at the code I think that the default_access parameter to
the libxc function we were discussing earlier should simply reach
p2m_init_altp2m_ept() and be assigned to p2m->default_access - that
probably clears the mystery.

You're saying that p2m_change_type_range() should act more like
p2m_altp2m_propagate_change() for p2ms that are not the hostp2m, right?


Thanks,
Razvan

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

Re: [Xen-devel] Weird altp2m behaviour when switching early to a new view

[Tamas K Lengyel]

On Fri, Apr 13, 2018 at 8:44 AM, Razvan Cojocaru
 wrote:
> On 04/11/2018 11:04 AM, Razvan Cojocaru wrote:
>> Debugging continues.
>
> Finally, the attached patch seems to get the display unstuck in my
> scenario, although for one guest I get:
>
> (XEN) d2v0 Unexpected vmexit: reason 49
> (XEN) domain_crash called from vmx.c:4120
> (XEN) Domain 2 (vcpu#0) crashed on cpu#1:
> (XEN) [ Xen-4.11-unstable  x86_64  debug=y   Not tainted ]
> (XEN) CPU:1
> (XEN) RIP:0010:[]
> (XEN) RFLAGS: 00010246   CONTEXT: hvm guest (d2v0)
> (XEN) rax: f8800300   rbx: f900c0083db0   rcx: aa55aa55
> (XEN) rdx: fa80041bdc41   rsi: f900c00c69a0   rdi: 0001
> (XEN) rbp:    rsp: f88002ee9ef0   r8:  fa80041bdc40
> (XEN) r9:  f80001810e80   r10: fa800342aa70   r11: f88002ee9e80
> (XEN) r12: 0005   r13: 0001   r14: f900c00c08b0
> (XEN) r15: 0001   cr0: 80050031   cr4: 000406f8
> (XEN) cr3: ef771000   cr2: f900c00c8000
> (XEN) fsb: fffde000   gsb: f80001810d00   gss: 07fdc000
> (XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
>
> i.e. EXIT_REASON_EPT_MISCONFIG - so not of the woods yet. I am hoping
> somebody more familiar with the code can point to a more elegant
> solution if one exists.

I dare say at this point you might just be that person :) I looked at
the patch, one issue with p2m_change_type_range in its current form is
that it's unclear how it would behave when the range contains remapped
gfns in an altp2m (either a page that remaps to this range, or a page
that remaps from the range). According to the current altp2m approach
I would say the altp2m views should probably just get completely reset
if there is such a remapping.

Tamas

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

Re: [Xen-devel] [PATCH RFC 7/8] mm: allow to control onlining/offlining of memory by a driver

[David Hildenbrand]

On 13.04.2018 17:59, Michal Hocko wrote:
> On Fri 13-04-18 15:33:28, David Hildenbrand wrote:
>> Some devices (esp. paravirtualized) might want to control
>> - when to online/offline a memory block
>> - how to online memory (MOVABLE/NORMAL)
>> - in which granularity to online/offline memory
>>
>> So let's add a new flag "driver_managed" and disallow to change the
>> state by user space. Device onlining/offlining will still work, however
>> the memory will not be actually onlined/offlined. That has to be handled
>> by the device driver that owns the memory.
> 
> Is there any reason to create the memblock sysfs interface to this
> memory at all? ZONE_DEVICE mem hotplug users currently do not do that
> and manage the memory themselves. It seems you want to achieve the same
> thing, no?
> 

Yes, I think so, namely kdump. We have to retrigger kexec() whenever a
memory block is added/removed. udev events are sent for that reason when
a memory block is created/deleted. And I think this is not done for
ZONE_DEVICE devices, or am I wrong?

-- 

Thanks,

David / dhildenb

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

Re: [Xen-devel] [PATCH] docs/gen-html-index: Make HTML::TreeBuilder::XPath optional again

[Ian Jackson]

Doug Goldstein writes ("Re: [PATCH] docs/gen-html-index: Make 
HTML::TreeBuilder::XPath optional again"):
> Reviewed-by: Doug Goldstein 
> Tested-by: Doug Goldstein 
> 
> The test run is here: https://gitlab.com/cardoe/xen/pipelines/20462270

Thanks.  Since this bug was blocking the smoke test, I have pushed
this fix.

Ian.

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

Re: [Xen-devel] [PATCH] docs/gen-html-index: Make HTML::TreeBuilder::XPath optional again

[Doug Goldstein]

On 4/13/18 8:58 AM, Ian Jackson wrote:
> 7782db9260d4 "docs/gen-html-index: Extract titles from HTML documents"
> requires HTML::TreeBuilder::XPath.
> 
> This is sadly not as widely available as I had hoped.  Work around
> this problem by making the use of this module optional: instead of
> `use'ing at the toplevel, we `require' it in the eval.  If it's not
> present, then the title is simply not extracted and the filename is
> used as before, which is tolerable.
> 
> Reported-by: Doug Goldstein 
> Signed-off-by: Ian Jackson 

Reviewed-by: Doug Goldstein 
Tested-by: Doug Goldstein 

The test run is here: https://gitlab.com/cardoe/xen/pipelines/20462270

-- 
Doug Goldstein

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

Re: [Xen-devel] [PATCH RFC 7/8] mm: allow to control onlining/offlining of memory by a driver

[Michal Hocko]

On Fri 13-04-18 15:33:28, David Hildenbrand wrote:
> Some devices (esp. paravirtualized) might want to control
> - when to online/offline a memory block
> - how to online memory (MOVABLE/NORMAL)
> - in which granularity to online/offline memory
> 
> So let's add a new flag "driver_managed" and disallow to change the
> state by user space. Device onlining/offlining will still work, however
> the memory will not be actually onlined/offlined. That has to be handled
> by the device driver that owns the memory.

Is there any reason to create the memblock sysfs interface to this
memory at all? ZONE_DEVICE mem hotplug users currently do not do that
and manage the memory themselves. It seems you want to achieve the same
thing, no?
-- 
Michal Hocko
SUSE Labs

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

Re: [Xen-devel] [PATCH 2/2] x86/microcode: Do not upload microcode if CPUs are offline

[Jan Beulich]

>>> On 30.03.18 at 08:59,  wrote:
> This patch is to backport the patch below from linux kernel.
> 
> commit 30ec26da9967d0d785abc24073129a34c3211777
> Author: Ashok Raj 
> Date:   Wed Feb 28 11:28:43 2018 +0100
> 
> x86/microcode: Do not upload microcode if CPUs are offline
> 
> Avoid loading microcode if any of the CPUs are offline, and issue a
> warning. Having different microcode revisions on the system at any 
> time
> is outright dangerous.

I'm afraid I don't fully agree - not applying an ucode update to the online
CPUs because some are offline isn't any better. Plus (while updating)
there's always going to be some discrepancy between ucode versions.
As long as we apply updates while bringing a CPU online, I think we're fine.

Also please consider valid cases you make not work anymore, like someone
having brought offline all sibling hyperthreads, with each core still having
one thread active. In that case an ucode update will implicitly update all
offline threads as well.

Jan



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

[Xen-devel] [xen-unstable-smoke test] 122252: regressions - trouble: blocked/fail

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm   6 xen-buildfail REGR. vs. 122174
 build-amd64   6 xen-buildfail REGR. vs. 122174
 build-armhf   6 xen-buildfail REGR. vs. 122174

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386  1 build-check(1) blocked n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a

version targeted for testing:
 xen  ba2931d4e38fac4e6960e10b245efd3badeb4aa2
baseline version:
 xen  82540b66ceb9318aa185f2488cbbbe479694de8f

Last test of basis   122174  2018-04-11 11:01:17 Z2 days
Failing since122191  2018-04-12 16:01:30 Z0 days   11 attempts
Testing same since   122193  2018-04-12 17:01:11 Z0 days   10 attempts


People who touched revisions under test:
  George Dunlap 
  Ian Jackson 
  Konrad Rzeszutek Wilk 
  Lars Kurth 
  Oleksandr Andrushchenko 
  Oleksandr Grytsov 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit ba2931d4e38fac4e6960e10b245efd3badeb4aa2
Author: Oleksandr Andrushchenko 
Date:   Wed Mar 7 10:21:20 2018 +0200

sndif: Add explicit back and front parameter negotiation

In order to provide explicit stream parameter negotiation between
backend and frontend the following changes are introduced in the protocol:
add XENSND_OP_HW_PARAM_QUERY request to read/update
configuration space for the parameter given: request passes
desired parameter interval (mask) and the response to this request
returns min/max interval (mask) for the parameter to be used.

Parameters supported by this request/response:
 - format mask
 - sample rate interval
 - number of channels interval
 - buffer size, interval, frames
 - period size, interval, frames

Signed-off-by: Oleksandr Andrushchenko 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Takashi Iwai 
Cc: Konrad Rzeszutek Wilk 
Cc: Takashi Iwai 
Signed-off-by: Konrad Rzeszutek Wilk 
Release-acked-by: Juergen Gross 

commit 41b4cff11f4c4a497067f543cb010d70119f1843
Author: Oleksandr Andrushchenko 
Date:   Mon Feb 5 09:41:57 2018 +0200

sndif: Add explicit back and front synchronization

In order to provide explicit synchronization between backend and
frontend the following changes are introduced in the protocol:
 - add new ring buffer for sending asynchronous events from
   backend to frontend to report number of bytes played by the
   frontend (XENSND_EVT_CUR_POS)
 - introduce trigger events for playback control: start/stop/pause/resume
 - add "req-" prefix to event-channel and ring-ref to unify naming
   of the Xen event channels for requests and events

Signed-off-by: Oleksandr Andrushchenko 
Signed-off-by: Oleksandr Grytsov 

Re: [Xen-devel] [PATCH 1/2] x86/microcode: Synchronize late microcode loading

[Jan Beulich]

>>> On 30.03.18 at 08:59,  wrote:
> @@ -281,24 +287,52 @@ static int microcode_update_cpu(const void *buf, size_t 
> size)
>  return err;
>  }
>  
> -static long do_microcode_update(void *_info)
> +static int __wait_for_cpus(atomic_t *cnt, int timeout)

No new double-underscore prefixed functions please.

>  {
> -struct microcode_info *info = _info;
> -int error;
> +int cpus = num_online_cpus();

unsigned int

> -BUG_ON(info->cpu != smp_processor_id());
> +atomic_inc(cnt);
>  
> -error = microcode_update_cpu(info->buffer, info->buffer_size);
> -if ( error )
> -info->error = error;
> +while (atomic_read(cnt) != cpus)

There are a number of style issues in the patch, mostly (like here) missing
blanks.

> +{
> +if ( timeout <= 0 )
> +{
> +printk("Timeout when waiting for CPUs calling in\n");
> +return -1;
> +}
> +udelay(1);
> +timeout--;
> +}
>  
> -info->cpu = cpumask_next(info->cpu, _online_map);
> -if ( info->cpu < nr_cpu_ids )
> -return continue_hypercall_on_cpu(info->cpu, do_microcode_update, 
> info);
> +return 0;
> +}
>  
> -error = info->error;
> -xfree(info);
> -return error;
> +static int do_microcode_update(void *_info)
> +{
> +struct microcode_info *info = _info;
> +int error, ret = 0;
> +
> +error = __wait_for_cpus(>cpu_in, USEC_PER_SEC);

Why this long a timeout here?

> +if ( error )
> +{
> +ret = -EBUSY;
> +return ret;
> +}
> +
> +error = microcode_update_cpu(info->buffer, info->buffer_size);
> +if ( error && !ret )
> +ret = error;
> +/*
> + * Increase the wait timeout to a safe value here since we're serializing
> + * the microcode update and that could take a while on a large number of
> + * CPUs. And that is fine as the *actual* timeout will be determined by
> + * the last CPU finished updating and thus cut short
> + */
> +error = __wait_for_cpus(>cpu_out, USEC_PER_SEC * 
> num_online_cpus());

And this one's even worse, in particular on huge systems. I'm afraid such a long
period of time in stop-machine context is going to confuse most of the running
domains (including Dom0). There's nothing inherently wrong with e.g. processing
the updates on distinct cores (and even more so on distinct sockets) in 
parallel.
Therefore revising the locking in microcode_update_cpu() might be a necessary
prereq step. Or alternatively you may need to demand that no other running
domains exist besides Dom0 (and hope the best for Dom0 itself).

I also don't think there's any point invoking the operation on all HT threads 
on a
core, but I realize stop_machine_run() isn't flexible enough to allow such.

Jan



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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-xsm  10 debian-install   fail REGR. vs. 118324
 test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 118324
 test-armhf-armhf-xl-arndale  10 debian-install   fail REGR. vs. 118324
 test-armhf-armhf-xl-credit2  10 debian-install   fail REGR. vs. 118324

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 10 debian-install   fail REGR. vs. 118324

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118324
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 118324
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 118324
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118324
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118324
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 118324
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118324
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118324
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linux5d1365940a68dd57b031b6e3c07d7d451cd69daf
baseline version:
 linux5b7d27967dabfb17c21b0d98b29153b9e3ee71e5

Last test of basis   118324  2018-01-25 07:31:24 Z   78 days
Failing since118362  2018-01-26 16:56:17 Z   76 days   64 attempts
Testing same since   122203  2018-04-12 20:05:21 Z0 days1 attempts


3246 people touched revisions under test,
not listing them all

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

Re: [Xen-devel] Weird altp2m behaviour when switching early to a new view

[Razvan Cojocaru]

On 04/11/2018 11:04 AM, Razvan Cojocaru wrote:
> Debugging continues.

Finally, the attached patch seems to get the display unstuck in my
scenario, although for one guest I get:

(XEN) d2v0 Unexpected vmexit: reason 49
(XEN) domain_crash called from vmx.c:4120
(XEN) Domain 2 (vcpu#0) crashed on cpu#1:
(XEN) [ Xen-4.11-unstable  x86_64  debug=y   Not tainted ]
(XEN) CPU:1
(XEN) RIP:0010:[]
(XEN) RFLAGS: 00010246   CONTEXT: hvm guest (d2v0)
(XEN) rax: f8800300   rbx: f900c0083db0   rcx: aa55aa55
(XEN) rdx: fa80041bdc41   rsi: f900c00c69a0   rdi: 0001
(XEN) rbp:    rsp: f88002ee9ef0   r8:  fa80041bdc40
(XEN) r9:  f80001810e80   r10: fa800342aa70   r11: f88002ee9e80
(XEN) r12: 0005   r13: 0001   r14: f900c00c08b0
(XEN) r15: 0001   cr0: 80050031   cr4: 000406f8
(XEN) cr3: ef771000   cr2: f900c00c8000
(XEN) fsb: fffde000   gsb: f80001810d00   gss: 07fdc000
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010

i.e. EXIT_REASON_EPT_MISCONFIG - so not of the woods yet. I am hoping
somebody more familiar with the code can point to a more elegant
solution if one exists.


Thanks,
Razvan
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 14b5939..3be02ca 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -1375,8 +1375,15 @@ void setup_ept_dump(void)
 void p2m_init_altp2m_ept(struct domain *d, unsigned int i)
 {
 struct p2m_domain *p2m = d->arch.altp2m_p2m[i];
+struct p2m_domain *hostp2m = p2m_get_hostp2m(d);
 struct ept_data *ept;
 
+p2m->max_mapped_pfn = hostp2m->max_mapped_pfn;
+p2m->default_access = hostp2m->default_access;
+p2m->domain = hostp2m->domain;
+p2m->logdirty_ranges = hostp2m->logdirty_ranges;
+p2m->global_logdirty = hostp2m->global_logdirty;
+
 p2m->min_remapped_gfn = gfn_x(INVALID_GFN);
 p2m->max_remapped_gfn = 0;
 ept = >ept;
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index c53cab4..00f85e1 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -248,7 +249,6 @@ int p2m_init(struct domain *d)
 int p2m_is_logdirty_range(struct p2m_domain *p2m, unsigned long start,
   unsigned long end)
 {
-ASSERT(p2m_is_hostp2m(p2m));
 if ( p2m->global_logdirty ||
  rangeset_contains_range(p2m->logdirty_ranges, start, end) )
 return 1;
@@ -964,12 +964,12 @@ int p2m_change_type_one(struct domain *d, unsigned long gfn_l,
 }
 
 /* Modify the p2m type of a range of gfns from ot to nt. */
-void p2m_change_type_range(struct domain *d, 
-   unsigned long start, unsigned long end,
-   p2m_type_t ot, p2m_type_t nt)
+static void _p2m_change_type_range(struct p2m_domain *p2m,
+   unsigned long start, unsigned long end,
+   p2m_type_t ot, p2m_type_t nt)
 {
+struct domain *d = p2m->domain;
 unsigned long gfn = start;
-struct p2m_domain *p2m = p2m_get_hostp2m(d);
 int rc = 0;
 
 ASSERT(ot != nt);
@@ -1022,6 +1022,23 @@ void p2m_change_type_range(struct domain *d,
 p2m_unlock(p2m);
 }
 
+void p2m_change_type_range(struct domain *d,
+   unsigned long start, unsigned long end,
+   p2m_type_t ot, p2m_type_t nt)
+{
+unsigned int i;
+
+if ( !altp2m_active(d) )
+{
+_p2m_change_type_range(p2m_get_hostp2m(d), start, end, ot, nt);
+return;
+}
+
+for ( i = 0; i < MAX_ALTP2M; i++ )
+if ( d->arch.altp2m_eptp[i] != mfn_x(INVALID_MFN) )
+_p2m_change_type_range(d->arch.altp2m_p2m[i], start, end, ot, nt);
+}
+
 /*
  * Finish p2m type change for gfns which are marked as need_recalc in a range.
  * Returns: 0/1 for success, negative for failure
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] broken build on staging docs

[Ian Jackson]

Doug Goldstein writes ("broken build on staging docs"):
> Since change 7782db9260d4c6499458de4e8d9866bc0427e143 the build has been
> broken. See https://gitlab.com/xen-project/xen/pipelines/20403549 for
> logs. Ultimately its because HTML::TreeBuilder::XPath is now a required
> Perl module. Previously the only necessary Perl modules where those
> shipped in the core of Perl. While I've got no problem updating all the
> containers to include it, there is a bit of a conundrum where
> CentOS/RHEL don't actually package and include it. I've also checked
> EPEL and its not included. Not sure what approach folks would like to
> take as this will require people to bust out CPAN for RHEL/CentOS based
> builds.

I've just posted a patch which I think will fix this for you.  Can you
try it please ?

 [PATCH] docs/gen-html-index: Make HTML::TreeBuilder::XPath optional again

Thanks,
Ian.

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

[Xen-devel] [PATCH] docs/gen-html-index: Make HTML::TreeBuilder::XPath optional again

[Ian Jackson]

7782db9260d4 "docs/gen-html-index: Extract titles from HTML documents"
requires HTML::TreeBuilder::XPath.

This is sadly not as widely available as I had hoped.  Work around
this problem by making the use of this module optional: instead of
`use'ing at the toplevel, we `require' it in the eval.  If it's not
present, then the title is simply not extracted and the filename is
used as before, which is tolerable.

Reported-by: Doug Goldstein 
Signed-off-by: Ian Jackson 
---
 docs/gen-html-index | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/docs/gen-html-index b/docs/gen-html-index
index 8258e2b..4fad6db 100644
--- a/docs/gen-html-index
+++ b/docs/gen-html-index
@@ -10,7 +10,6 @@ use warnings;
 use Getopt::Long;
 use IO::File;
 use File::Basename;
-use HTML::TreeBuilder::XPath;
 
 Getopt::Long::Configure('bundling');
 
@@ -21,8 +20,10 @@ our @dirs;
 our %index;
 
 our $outdir;
+our $debug;
 
-GetOptions("i=s" => sub { read_index(@_);} )
+GetOptions("i=s" => sub { read_index(@_);},
+   "D" => \$debug)
 or die;
 
 ($outdir,@docs) = @ARGV;
@@ -68,6 +69,7 @@ sub make_linktext ($) {
 
 my $from_html;
 eval {
+require HTML::TreeBuilder::XPath;
 my $tree = new HTML::TreeBuilder::XPath;
 my $f = "$outdir/$l.html";
 open F, '<', $f or die "$l $f $!";
@@ -75,6 +77,7 @@ sub make_linktext ($) {
 close F;
 $from_html = $tree->findvalue("/html/head/title");
 };
+print "$l: get title: $@" if $@ && $debug;
 return $from_html if $from_html;
 
 return basename($l);
-- 
2.1.4


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

[Xen-devel] [xen-unstable-smoke test] 122247: regressions - trouble: blocked/fail

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm   6 xen-buildfail REGR. vs. 122174
 build-amd64   6 xen-buildfail REGR. vs. 122174
 build-armhf   6 xen-buildfail REGR. vs. 122174

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386  1 build-check(1) blocked n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a

version targeted for testing:
 xen  ba2931d4e38fac4e6960e10b245efd3badeb4aa2
baseline version:
 xen  82540b66ceb9318aa185f2488cbbbe479694de8f

Last test of basis   122174  2018-04-11 11:01:17 Z2 days
Failing since122191  2018-04-12 16:01:30 Z0 days   10 attempts
Testing same since   122193  2018-04-12 17:01:11 Z0 days9 attempts


People who touched revisions under test:
  George Dunlap 
  Ian Jackson 
  Konrad Rzeszutek Wilk 
  Lars Kurth 
  Oleksandr Andrushchenko 
  Oleksandr Grytsov 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit ba2931d4e38fac4e6960e10b245efd3badeb4aa2
Author: Oleksandr Andrushchenko 
Date:   Wed Mar 7 10:21:20 2018 +0200

sndif: Add explicit back and front parameter negotiation

In order to provide explicit stream parameter negotiation between
backend and frontend the following changes are introduced in the protocol:
add XENSND_OP_HW_PARAM_QUERY request to read/update
configuration space for the parameter given: request passes
desired parameter interval (mask) and the response to this request
returns min/max interval (mask) for the parameter to be used.

Parameters supported by this request/response:
 - format mask
 - sample rate interval
 - number of channels interval
 - buffer size, interval, frames
 - period size, interval, frames

Signed-off-by: Oleksandr Andrushchenko 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Takashi Iwai 
Cc: Konrad Rzeszutek Wilk 
Cc: Takashi Iwai 
Signed-off-by: Konrad Rzeszutek Wilk 
Release-acked-by: Juergen Gross 

commit 41b4cff11f4c4a497067f543cb010d70119f1843
Author: Oleksandr Andrushchenko 
Date:   Mon Feb 5 09:41:57 2018 +0200

sndif: Add explicit back and front synchronization

In order to provide explicit synchronization between backend and
frontend the following changes are introduced in the protocol:
 - add new ring buffer for sending asynchronous events from
   backend to frontend to report number of bytes played by the
   frontend (XENSND_EVT_CUR_POS)
 - introduce trigger events for playback control: start/stop/pause/resume
 - add "req-" prefix to event-channel and ring-ref to unify naming
   of the Xen event channels for requests and events

Signed-off-by: Oleksandr Andrushchenko 
Signed-off-by: Oleksandr Grytsov 

Re: [Xen-devel] [PATCH v4 7/7] add sleep, msleep and NOW() macros to time manager

[Roger Pau Monné]

On Tue, Apr 10, 2018 at 09:17:01PM +0200, Paul Semel wrote:
> those are helpful macro to use the time manager correctly
> 
> Signed-off-by: Paul Semel 
> ---
> 
> Notes:
> v4:
> - new patch version
> 
>  common/time.c  | 10 ++
>  include/xtf/time.h | 12 
>  2 files changed, 22 insertions(+)
> 
> diff --git a/common/time.c b/common/time.c
> index 7515eb0..e2779b9 100644
> --- a/common/time.c
> +++ b/common/time.c
> @@ -163,6 +163,16 @@ static inline void mspin_sleep(uint64_t t)
>  nspin_sleep(nsec);
>  }
>  
> +void sleep(uint64_t t)
> +{
> +spin_sleep(t);
> +}
> +
> +void msleep(uint64_t t)
> +{
> +mspin_sleep(t);

Why can you just call mspin_sleep msleep directly?

The same applies to spin_sleep.

Also I was expecting to see some kind of test appear at the end of the
series. You are basically adding a bunch of dead code, since there's
no user of any of the newly introduced functions.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v4 6/7] add mspin_sleep function to time manager

[Roger Pau Monné]

On Tue, Apr 10, 2018 at 09:17:00PM +0200, Paul Semel wrote:
> this function uses mspin_sleep to spin sleep for t milliseconds
> 
> Signed-off-by: Paul Semel 
> ---
> 
> Notes:
> v4:
> - new patch version
> 
>  common/time.c  | 6 ++
>  include/xtf/time.h | 1 +
>  2 files changed, 7 insertions(+)
> 
> diff --git a/common/time.c b/common/time.c
> index 87db124..7515eb0 100644
> --- a/common/time.c
> +++ b/common/time.c
> @@ -157,6 +157,12 @@ static inline void spin_sleep(uint64_t t)
>  nspin_sleep(nsec);
>  }
>  
> +static inline void mspin_sleep(uint64_t t)
> +{
> +uint64_t nsec = MSEC_TO_NSEC(t);

Newline.

And IMO can be squashed into the previous patch.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v4 5/7] add spin_sleep function to time manager

[Roger Pau Monné]

On Tue, Apr 10, 2018 at 09:16:59PM +0200, Paul Semel wrote:
> this function uses nspin_sleep to spin sleep for t seconds

IMO you can squash this into the previous patch.

> Signed-off-by: Paul Semel 
> ---
> 
> Notes:
> v4:
> - new patch version
> 
>  common/time.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/common/time.c b/common/time.c
> index 232e134..87db124 100644
> --- a/common/time.c
> +++ b/common/time.c
> @@ -151,6 +151,12 @@ static inline void nspin_sleep(uint64_t t)
>  asm volatile ("pause");
>  }
>  
> +static inline void spin_sleep(uint64_t t)
> +{
> +uint64_t nsec = SEC_TO_NSEC(t);

Newline.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v4 4/7] add nspin_sleep function to time manager

[Roger Pau Monné]

On Tue, Apr 10, 2018 at 09:16:58PM +0200, Paul Semel wrote:
> this function spin sleeps for t nanoseconds
> 
> Signed-off-by: Paul Semel 
> ---
> 
> Notes:
> v4:
> - new patch version
> 
>  common/time.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/common/time.c b/common/time.c
> index 8489f3b..232e134 100644
> --- a/common/time.c
> +++ b/common/time.c
> @@ -139,6 +139,18 @@ int gettimeofday(struct timeval *tp, void *restrict tzp)
>  return 0;
>  }
>  
> +static inline void nspin_sleep(uint64_t t)
> +{
> +uint64_t curr = since_boot_time();
> +uint64_t end = curr + t;
> +
> +if ( end < curr )
> +panic("end value overflows counter\n");
> +
> +while ( since_boot_time() < end )
> +asm volatile ("pause");

You likely want to add a pause helper to arch/x86/include/arch/lib.h
in order to avoid open-coding the asm instruction in common code.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v4 3/7] add gettimeofday function to time managment

[Roger Pau Monné]

On Tue, Apr 10, 2018 at 09:16:57PM +0200, Paul Semel wrote:
> this function acts as the POSIX gettimeofday function
> 
> Signed-off-by: Paul Semel 
> ---
> 
> Notes:
> v4:
> - new patch version
> 
>  common/time.c  | 30 ++
>  include/xtf/time.h |  8 
>  2 files changed, 38 insertions(+)
> 
> diff --git a/common/time.c b/common/time.c
> index c1b7cd1..8489f3b 100644
> --- a/common/time.c
> +++ b/common/time.c
> @@ -1,6 +1,7 @@
>  #include 
>  #include 
>  #include 
> +#include 

Sorting.

>  
>  #include 
>  #include 
> @@ -109,6 +110,35 @@ uint64_t current_time(void)
>  return sec + boot_time;
>  }
>  
> +/* The POSIX gettimeofday syscall normally takes a second argument, which is
> + * the timezone (struct timezone). However, it sould be NULL because linux
> + * doesn't use it anymore. So we need for us to add it in this function
> + */
> +int gettimeofday(struct timeval *tp, void *restrict tzp)
> +{
> +uint64_t boot_time, sec;
> +uint32_t mod, nsec;
> +
> +if ( tzp != NULL )
> +return -EOPNOTSUPP;
> +
> +if ( tp == NULL )
> +return -EINVAL;
> +
> +get_time_info(_time, , );

Why are you using get_time_info here? Shouldn't you use the
current_time function introduced in the previous patch?

Or else I don't see the need to introduce current_time in the previous
patch.

> +#if defined(__i386__)
> +mod = divmod64(_time, SEC_TO_NSEC(1));
> +#else
> +mod = boot_time % SEC_TO_NSEC(1);
> +boot_time /= SEC_TO_NSEC(1);
> +#endif

Please use divmod64 unconditionally.

> +
> +tp->sec = sec + boot_time;
> +tp->nsec = nsec + mod;
> +return 0;
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/include/xtf/time.h b/include/xtf/time.h
> index e33dc8a..ce4d6db 100644
> --- a/include/xtf/time.h
> +++ b/include/xtf/time.h
> @@ -8,6 +8,12 @@
>  
>  #include 
>  
> +struct timeval {
> +uint64_t sec;
> +uint64_t nsec;
> +};
> +
> +

Extra newline.

Roger.

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

Re: [Xen-devel] [PATCH v4 2/7] add current_time function to time manager

[Roger Pau Monné]

On Tue, Apr 10, 2018 at 09:16:56PM +0200, Paul Semel wrote:
> this function returns the "epoch" time
> 
> Signed-off-by: Paul Semel 
> ---
> 
> Notes:
> v4:
> - new patch version
> 
>  common/time.c  | 39 +++
>  include/xtf/time.h |  5 +
>  2 files changed, 44 insertions(+)
> 
> diff --git a/common/time.c b/common/time.c
> index 79abc7e..c1b7cd1 100644
> --- a/common/time.c
> +++ b/common/time.c
> @@ -4,6 +4,7 @@
>  
>  #include 
>  #include 
> +#include 

Sorting

>  
>  /* This function was taken from mini-os source code */
>  /* It returns ((delta << shift) * mul_frac) >> 32 */
> @@ -70,6 +71,44 @@ uint64_t since_boot_time(void)
>  return system_time;
>  }
>  
> +static void get_time_info(uint64_t *boot_time, uint64_t *sec, uint32_t *nsec)
> +{
> +uint32_t ver1, ver2;
> +do {
> +ver1 = ACCESS_ONCE(shared_info.wc_version);
> +smp_rmb();
> +*boot_time = since_boot_time();

Why are you reading the uptime in the middle of the loop? You can
read this out of the loop, or in a different function.

> +#if defined(__i386__)
> +*sec = (uint64_t)ACCESS_ONCE(shared_info.wc_sec);
> +#else
> +*sec = ((uint64_t)ACCESS_ONCE(shared_info.wc_sec_hi) << 32)
> +| ACCESS_ONCE(shared_info.wc_sec);
> +#endif

I think this should be:

*sec = shared_info.wc_sec;
#ifdef __i386__
*sec |= shared_info.arch.wc_sec_hi << 32;
#else
*sec |= shared_info.wc_sec_hi << 32;
#endif

> +*nsec = (uint64_t)ACCESS_ONCE(shared_info.wc_nsec);
> +smp_rmb();
> +ver2 = ACCESS_ONCE(shared_info.wc_version);
> +smp_rmb();

This AFAICT this has the same issues as the code used in patch 1 to
access the vcpu_time_info data.

You only need the ACCESS_ONCE in order to read ver2, the rest can be
dropped.

> +} while ( (ver1 & 1) != 0 && ver1 != ver2 );
> +}
> +
> +/* This function return the epoch time (number of seconds elapsed
> + * since Juanary 1, 1970) */
> +uint64_t current_time(void)
> +{
> +uint32_t nsec;
> +uint64_t boot_time, sec;
> +
> +get_time_info(_time, , );

I think it would make more sense to:

1. Call since_boot_time hypervisor_uptime.
2. Call get_time_info hypervisor_wallclock.

In order to get the current time here you call both functions and then
add the result, like you do below.

> +
> +#if defined(__i386__)
> +divmod64(_time, SEC_TO_NSEC(1));
> +#else
> +boot_time /= SEC_TO_NSEC(1);
> +#endif

Please use devmod64 unconditionally.

Thanks, Roger.

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

[Xen-devel] [PATCH RFC 7/8] mm: allow to control onlining/offlining of memory by a driver

[David Hildenbrand]

Some devices (esp. paravirtualized) might want to control
- when to online/offline a memory block
- how to online memory (MOVABLE/NORMAL)
- in which granularity to online/offline memory

So let's add a new flag "driver_managed" and disallow to change the
state by user space. Device onlining/offlining will still work, however
the memory will not be actually onlined/offlined. That has to be handled
by the device driver that owns the memory.

Signed-off-by: David Hildenbrand 
---
 drivers/base/memory.c  | 22 ++
 drivers/xen/balloon.c  |  2 +-
 include/linux/memory.h |  1 +
 include/linux/memory_hotplug.h |  4 +++-
 mm/memory_hotplug.c| 34 --
 5 files changed, 51 insertions(+), 12 deletions(-)

diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index bffe8616bd55..3b8616551561 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -231,27 +231,28 @@ static bool pages_correctly_probed(unsigned long 
start_pfn)
  * Must already be protected by mem_hotplug_begin().
  */
 static int
-memory_block_action(unsigned long phys_index, unsigned long action, int 
online_type)
+memory_block_action(struct memory_block *mem, unsigned long action)
 {
-   unsigned long start_pfn;
+   unsigned long start_pfn = section_nr_to_pfn(mem->start_section_nr);
unsigned long nr_pages = PAGES_PER_SECTION * sections_per_block;
-   int ret;
+   int ret = 0;
 
-   start_pfn = section_nr_to_pfn(phys_index);
+   if (mem->driver_managed)
+   return 0;
 
switch (action) {
case MEM_ONLINE:
if (!pages_correctly_probed(start_pfn))
return -EBUSY;
 
-   ret = online_pages(start_pfn, nr_pages, online_type);
+   ret = online_pages(start_pfn, nr_pages, mem->online_type);
break;
case MEM_OFFLINE:
ret = offline_pages(start_pfn, nr_pages);
break;
default:
WARN(1, KERN_WARNING "%s(%ld, %ld) unknown action: "
-"%ld\n", __func__, phys_index, action, action);
+"%ld\n", __func__, mem->start_section_nr, action, action);
ret = -EINVAL;
}
 
@@ -269,8 +270,7 @@ static int memory_block_change_state(struct memory_block 
*mem,
if (to_state == MEM_OFFLINE)
mem->state = MEM_GOING_OFFLINE;
 
-   ret = memory_block_action(mem->start_section_nr, to_state,
-   mem->online_type);
+   ret = memory_block_action(mem, to_state);
 
mem->state = ret ? from_state_req : to_state;
 
@@ -350,6 +350,11 @@ store_mem_state(struct device *dev,
 */
mem_hotplug_begin();
 
+   if (mem->driver_managed) {
+   ret = -EINVAL;
+   goto out;
+   }
+
switch (online_type) {
case MMOP_ONLINE_KERNEL:
case MMOP_ONLINE_MOVABLE:
@@ -364,6 +369,7 @@ store_mem_state(struct device *dev,
ret = -EINVAL; /* should never happen */
}
 
+out:
mem_hotplug_done();
 err:
unlock_device_hotplug();
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 065f0b607373..89981d573c06 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -401,7 +401,7 @@ static enum bp_state reserve_additional_memory(void)
 * callers drop the mutex before trying again.
 */
mutex_unlock(_mutex);
-   rc = add_memory_resource(nid, resource, memhp_auto_online);
+   rc = add_memory_resource(nid, resource, memhp_auto_online, false);
mutex_lock(_mutex);
 
if (rc) {
diff --git a/include/linux/memory.h b/include/linux/memory.h
index 9f8cd856ca1e..018c5e5ecde1 100644
--- a/include/linux/memory.h
+++ b/include/linux/memory.h
@@ -29,6 +29,7 @@ struct memory_block {
unsigned long state;/* serialized by the dev->lock */
int section_count;  /* serialized by mem_sysfs_mutex */
int online_type;/* for passing data to online routine */
+   bool driver_managed;/* driver handles online/offline */
int phys_device;/* to which fru does this belong? */
void *hw;   /* optional pointer to fw/hw data */
int (*phys_callback)(struct memory_block *);
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index e0e49b5b1ee1..46c6ceb1110d 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -320,7 +320,9 @@ static inline void remove_memory(int nid, u64 start, u64 
size) {}
 extern int walk_memory_range(unsigned long start_pfn, unsigned long end_pfn,
void *arg, int (*func)(struct memory_block *, void *));
 extern int add_memory(int nid, u64 start, u64 size);
-extern int add_memory_resource(int nid, struct resource *resource, bool 

Re: [Xen-devel] [PATCH v4 1/7] introduce time managment in xtf

[Roger Pau Monné]

On Tue, Apr 10, 2018 at 09:16:55PM +0200, Paul Semel wrote:
> this file is introduce to be able to implement an inter domain
> communication protocol over xenstore. For synchronization purpose, we do
> really want to be able to "control" time
> 
> common/time.c: since_boot_time gets the time in nanoseconds from the
> moment the VM has booted
> 
> Signed-off-by: Paul Semel 
> ---
> 
> Notes:
> v4:
> - moved rdtsc to arch/x86/include/arch/lib.h
> - added a rdtsc_ordered implementation to serialize rdtsc
> - simplified since_boot_time function
> - still need to have Andrew's scale_delta version
> 
>  arch/x86/include/arch/lib.h | 18 ++
>  build/files.mk  |  1 +
>  common/time.c   | 81 
> +
>  include/xtf/time.h  | 24 ++
>  4 files changed, 124 insertions(+)
>  create mode 100644 common/time.c
>  create mode 100644 include/xtf/time.h
> 
> diff --git a/arch/x86/include/arch/lib.h b/arch/x86/include/arch/lib.h
> index 0045902..510cdb1 100644
> --- a/arch/x86/include/arch/lib.h
> +++ b/arch/x86/include/arch/lib.h
> @@ -6,6 +6,7 @@
>  #include 
>  #include 
>  #include 
> +#include 

This include list is sorted alphabetically.

>  
>  static inline void cpuid(uint32_t leaf,
>   uint32_t *eax, uint32_t *ebx,
> @@ -374,6 +375,23 @@ static inline void write_xcr0(uint64_t xcr0)
>  xsetbv(0, xcr0);
>  }
>  
> +static inline uint64_t rdtsc(void)
> +{
> +uint32_t lo, hi;
> +
> +asm volatile("rdtsc": "=a"(lo), "=d"(hi));
> +
> +return ((uint64_t)hi << 32) | lo;
> +}
> +
> +static inline uint64_t rdtsc_ordered(void)
> +{
> +rmb();
> +mb();
> +
> +return rdtsc();
> +}

I would likely just add a single function like:

static inline uint64_t rdtsc_ordered(void)
{
uint32_t lo, hi;

asm volatile("lfence; mfence; rdtsc" : "=a" (lo), "=d" (hi));

return ((uint64_t)hi << 32) | lo;
}

Because there's no external caller of rdtsc, but I will leave that to
Andrew to decide. In any case this should work fine.

> +
>  #endif /* XTF_X86_LIB_H */
>  
>  /*
> diff --git a/build/files.mk b/build/files.mk
> index 46b42d6..55ed1ca 100644
> --- a/build/files.mk
> +++ b/build/files.mk
> @@ -16,6 +16,7 @@ obj-perarch += $(ROOT)/common/libc/vsnprintf.o
>  obj-perarch += $(ROOT)/common/report.o
>  obj-perarch += $(ROOT)/common/setup.o
>  obj-perarch += $(ROOT)/common/xenbus.o
> +obj-perarch += $(ROOT)/common/time.o
>  
>  obj-perenv += $(ROOT)/arch/x86/decode.o
>  obj-perenv += $(ROOT)/arch/x86/desc.o
> diff --git a/common/time.c b/common/time.c
> new file mode 100644
> index 000..79abc7e
> --- /dev/null
> +++ b/common/time.c
> @@ -0,0 +1,81 @@
> +#include 
> +#include 
> +#include 

Alphabetic order please.

> +#include 
> +#include 
> +
> +/* This function was taken from mini-os source code */
> +/* It returns ((delta << shift) * mul_frac) >> 32 */

Comment has wrong style, please check CODING_STYLE.

> +static inline uint64_t scale_delta(uint64_t delta, uint32_t mul_frac, int 
> shift)
> +{
> +uint64_t product;
> +#ifdef __i386__
> +uint32_t tmp1, tmp2;
> +#endif
> +
> +if ( shift < 0 )
> +delta >>= -shift;
> +else
> +delta <<= shift;
> +
> +#ifdef __i386__
> +__asm__ (
> +"mul  %5   ; "
> +"mov  %4,%%eax ; "
> +"mov  %%edx,%4 ; "
> +"mul  %5   ; "
> +"add  %4,%%eax ; "
> +"xor  %5,%5; "
> +"adc  %5,%%edx ; "
> +: "=A" (product), "=r" (tmp1), "=r" (tmp2)
> +: "a" ((uint32_t)delta), "1" ((uint32_t)(delta >> 32)), "2" 
> (mul_frac) );

This line is too long.

> +#else
> +__asm__ (
> +"mul %%rdx ; shrd $32,%%rdx,%%rax"
> +: "=a" (product) : "0" (delta), "d" ((uint64_t)mul_frac) );

Not sure whether you need to add a ': "d"' clobber here, since the d
register is used but it's not in the list of output operands.

> +#endif
> +
> +return product;
> +}
> +
> +
> +uint64_t since_boot_time(void)
> +{
> +uint32_t ver1, ver2;
> +uint64_t tsc_timestamp, system_time, tsc;
> +uint32_t tsc_to_system_mul;
> +int8_t tsc_shift;
> +
> +do
> +{
> +ver1 = ACCESS_ONCE(shared_info.vcpu_info[0].time.version);
> +smp_rmb();
> +
> +system_time = shared_info.vcpu_info[0].time.system_time;
> +tsc_timestamp = shared_info.vcpu_info[0].time.tsc_timestamp;
> +tsc_to_system_mul = shared_info.vcpu_info[0].time.tsc_to_system_mul;
> +tsc_shift = shared_info.vcpu_info[0].time.tsc_shift;
> +tsc = rdtsc_ordered();
> +smp_rmb();

I don't think you need the barrier here if you use rdtsc_ordered, but
I would like confirmation from someone else.

> +
> +ver2 = ACCESS_ONCE(shared_info.vcpu_info[0].time.version);
> +} while ( ver2 & 1 || ver1 != ver2 );
> +
> +
> +system_time += scale_delta(tsc - 

Re: [Xen-devel] [PATCH 0/3] x86: S3 resume adjustments

[Andrew Cooper]

On 13/04/18 12:49, Jan Beulich wrote:
> 1: correct ordering of operations during S3 resume
> 2: suppress BTI mitigations around S3 suspend/resume
> 3: check feature flags after resume
>
> Signed-off-by: Jan Beulich 

Acked-by: Andrew Cooper 

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

Re: [Xen-devel] Setting up a call to discuss PCI Emulation - Future Direction

[Lars Kurth]

On 13/04/2018, 11:01, "Roger Pau Monne"  wrote:

On Thu, Apr 12, 2018 at 05:50:00PM +0100, Lars Kurth wrote:
> 
> 
> On 12/04/2018, 17:41, "Roger Pau Monne"  wrote:
> 
> On Thu, Apr 12, 2018 at 05:32:57PM +0100, Lars Kurth wrote:
> 
> 
> >may work. For me Mon, Wed and Fri’s generally work at those 
time-slots.
> >Next week is a little busy for me, so I would prefer the 
following week.
> >If you could fill out the following Google poll, if this week 
works that
> >would be great. Otherwise please scream.
> 
> I'm afraid I'm on vacations from the 21st to the 29th of April, so I
> won't be able to join the meeting unless we move it to the week after.
> Let's see what people think of the current dates.
> 
> Roger.
> 
> Hi, I changed the dates to the week after. Poll so far has been 
invalidated.
> 
> See https://doodle.com/poll/gdnmcrvnibmw563n

Thanks! I've already fixed my vote.

I guess this will come later, but we need a clear agenda of items
because the x86 and ARM topics are probably going to be completely
different (albeit all related to PCI).

Royger: I am OK with trying to get a draft agenda in place in this e-mail 
thread. But I can't drive this, as I don’t understand the issues. But I am 
happy to collate everything as for the x86 call and write up minutes

Lars
 

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

Re: [Xen-devel] [PATCH 5/5] SUPPORT.md: Document the new text ordering rule

[Lars Kurth]

On 13/04/2018, 11:31, "Ian Jackson"  wrote:

Lars Kurth writes ("Re: [PATCH 5/5] SUPPORT.md: Document the new text 
ordering rule"):
...
> +In each case, descriptions which expand on the name of a feature as
> +provided in the section heading, precede the Status indications.
> 
> The following is a little clearer
> s/, descriptions which expand on the name of a feature as provided in the 
section heading,/, descriptions which describe the feature in the section 
heading in more detail,/

I used the wording I did because the word "description" is very
elastic, and might well be thought to include things that we intend as
caveats.

I don't mind either way. Just something which sounded odd. 

Lars


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

[Xen-devel] [PATCH 3/3] x86: check feature flags after resume

[Jan Beulich]

Make sure no previously present features are missing after resume (and
the re-loading of microcode), to avoid later crashes or (likely silent)
hangs / live locks. This doesn't go beyond checking x86_capability[],
but this should be good enough for the immediate need of making sure
that the BIT mitigation MSRs are still available.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -254,6 +254,9 @@ static int enter_state(u32 state)
 
 microcode_resume_cpu(0);
 
+if ( !recheck_cpu_features(0) )
+panic("Missing previously available feature(s).");
+
 ci->bti_ist_info = default_bti_ist_info;
 asm volatile (ALTERNATIVE("", "wrmsr", X86_FEATURE_XEN_IBRS_SET)
   :: "a" (SPEC_CTRL_IBRS), "c" (MSR_SPEC_CTRL), "d" (0)
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -501,6 +501,9 @@ void identify_cpu(struct cpuinfo_x86 *c)
printk("\n");
 #endif
 
+   if (system_state == SYS_STATE_resume)
+   return;
+
/*
 * On SMP, boot_cpu_data holds the common feature set between
 * all CPUs; so make sure that we indicate which features are
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -473,6 +473,28 @@ void __init init_guest_cpuid(void)
 calculate_hvm_max_policy();
 }
 
+bool recheck_cpu_features(unsigned int cpu)
+{
+bool okay = true;
+struct cpuinfo_x86 c;
+const struct cpuinfo_x86 *bsp = _cpu_data;
+unsigned int i;
+
+identify_cpu();
+
+for ( i = 0; i < NCAPINTS; ++i )
+{
+if ( !(~c.x86_capability[i] & bsp->x86_capability[i]) )
+continue;
+
+printk(XENLOG_ERR "CPU%u: cap[%2u] is %08x (expected %08x)\n",
+   cpu, i, c.x86_capability[i], bsp->x86_capability[i]);
+okay = false;
+}
+
+return okay;
+}
+
 const uint32_t *lookup_deep_deps(uint32_t feature)
 {
 static const struct {
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -90,11 +90,14 @@ void initialize_cpu_data(unsigned int cp
 cpu_data[cpu] = boot_cpu_data;
 }
 
-static void smp_store_cpu_info(int id)
+static bool smp_store_cpu_info(unsigned int id)
 {
 unsigned int socket;
 
-identify_cpu(_data[id]);
+if ( system_state != SYS_STATE_resume )
+identify_cpu(_data[id]);
+else if ( !recheck_cpu_features(id) )
+return false;
 
 socket = cpu_to_socket(id);
 if ( !socket_cpumask[socket] )
@@ -102,6 +105,8 @@ static void smp_store_cpu_info(int id)
 socket_cpumask[socket] = secondary_socket_cpumask;
 secondary_socket_cpumask = NULL;
 }
+
+return true;
 }
 
 /*
@@ -187,12 +192,19 @@ static void smp_callin(void)
 setup_local_APIC();
 
 /* Save our processor parameters. */
-smp_store_cpu_info(cpu);
+if ( !smp_store_cpu_info(cpu) )
+{
+printk("CPU%u: Failed to validate features - not coming back online\n",
+   cpu);
+cpu_error = -ENXIO;
+goto halt;
+}
 
 if ( (rc = hvm_cpu_up()) != 0 )
 {
 printk("CPU%d: Failed to initialise HVM. Not coming online.\n", cpu);
 cpu_error = rc;
+halt:
 clear_local_APIC();
 spin_debug_enable();
 cpu_exit_clear(cpu);
--- a/xen/include/asm-x86/cpuid.h
+++ b/xen/include/asm-x86/cpuid.h
@@ -253,6 +253,9 @@ static inline void cpuid_featureset_to_p
 extern struct cpuid_policy raw_cpuid_policy, host_cpuid_policy,
 pv_max_cpuid_policy, hvm_max_cpuid_policy;
 
+/* Check that all previously present features are still available. */
+bool recheck_cpu_features(unsigned int cpu);
+
 /* Allocate and initialise a CPUID policy suitable for the domain. */
 int init_domain_cpuid_policy(struct domain *d);
 





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

[Xen-devel] [PATCH 2/3] x86: suppress BTI mitigations around S3 suspend/resume

[Jan Beulich]

NMI and #MC can occur at any time after S3 resume, yet the MSR_SPEC_CTRL
may become available only once we're reloaded microcode. Make
SPEC_CTRL_ENTRY_FROM_INTR_IST and DO_SPEC_CTRL_EXIT_TO_XEN no-ops for
the critical period of time.

Also set the MSR back to its intended value.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 uint32_t system_reset_counter = 1;
@@ -163,6 +164,7 @@ static int enter_state(u32 state)
 {
 unsigned long flags;
 int error;
+struct cpu_info *ci;
 unsigned long cr4;
 
 if ( (state <= ACPI_STATE_S0) || (state > ACPI_S_STATES_MAX) )
@@ -210,6 +212,10 @@ static int enter_state(u32 state)
 else
 error = 0;
 
+ci = get_cpu_info();
+ci->use_shadow_spec_ctrl = 0;
+ci->bti_ist_info = 0;
+
 ACPI_FLUSH_CPU_CACHE();
 
 switch ( state )
@@ -248,6 +254,11 @@ static int enter_state(u32 state)
 
 microcode_resume_cpu(0);
 
+ci->bti_ist_info = default_bti_ist_info;
+asm volatile (ALTERNATIVE("", "wrmsr", X86_FEATURE_XEN_IBRS_SET)
+  :: "a" (SPEC_CTRL_IBRS), "c" (MSR_SPEC_CTRL), "d" (0)
+  : "memory");
+
  done:
 spin_debug_enable();
 local_irq_restore(flags);




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

[Xen-devel] [PATCH 1/3] x86: correct ordering of operations during S3 resume

[Jan Beulich]

Microcode loading needs to happen before re-enabling interrupts, in case
only updated microcode allows the use of e.g. the SPEC_{CTRL,CMD} MSRs.
Otoh it doesn't need to happen at all when we didn't suspend in the
first place. It needs to happen before spin_debug_enable() though, as it
acquires a lock and hence would otherwise make
common/spinlock.c:check_lock() unhappy. As micrcode loading can be
pretty verbose, also make sure it only runs after console_end_sync().

cpufreq_add_cpu() doesn't need calling on the only "goto enable_cpu"
path, which sits ahead of cpufreq_del_cpu().

Reported-by: Simon Gaiser 
Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -203,6 +203,7 @@ static int enter_state(u32 state)
 printk(XENLOG_ERR "Some devices failed to power down.");
 system_state = SYS_STATE_resume;
 device_power_up(error);
+console_end_sync();
 error = -EIO;
 goto done;
 }
@@ -243,17 +244,19 @@ static int enter_state(u32 state)
 if ( (state == ACPI_STATE_S3) && error )
 tboot_s3_error(error);
 
+console_end_sync();
+
+microcode_resume_cpu(0);
+
  done:
 spin_debug_enable();
 local_irq_restore(flags);
-console_end_sync();
 acpi_sleep_post(state);
 if ( hvm_cpu_up() )
 BUG();
+cpufreq_add_cpu(0);
 
  enable_cpu:
-cpufreq_add_cpu(0);
-microcode_resume_cpu(0);
 rcu_barrier();
 mtrr_aps_sync_begin();
 enable_nonboot_cpus();




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

Re: [Xen-devel] [PATCH 2/3] x86/pv: Introduce and use x86emul_write_dr()

[Jan Beulich]

>>> On 13.04.18 at 13:37,  wrote:
> On 13/04/18 09:39, Jan Beulich wrote:
> On 12.04.18 at 18:55,  wrote:
>>> @@ -2029,7 +2035,17 @@ long set_debugreg(struct vcpu *v, unsigned int reg, 
> unsigned long value)
>>>  if ( v == curr )
>>>  write_debugreg(3, value);
>>>  break;
>>> +
>>> +case 4:
>>> +if ( v->arch.pv_vcpu.ctrlreg[4] & X86_CR4_DE )
>>> +return -ENODEV;
>>> +
>>> +/* Fallthrough */
>>>  case 6:
>>> +/* The upper 32 bits are strictly reserved. */
>>> +if ( value != (uint32_t)value )
>>> +return -EINVAL;
>>> +
>>>  /*
>>>   * DR6: Bits 4-11,16-31 reserved (set to 1).
>>>   *  Bit 12 reserved (set to 0).
>> How are the upper 32 bits different from the other reserved bits (named in 
>> the
>> comment visible here)?
> 
> The upper 32 bits are MBZ and will raise #GP if set.  The lower reserved
> bits are write-ignored.

Oh, indeed, I didn't recall that.

Reviewed-by: Jan Beulich 

Jan



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

[Xen-devel] [PATCH 0/3] x86: S3 resume adjustments

[Jan Beulich]

1: correct ordering of operations during S3 resume
2: suppress BTI mitigations around S3 suspend/resume
3: check feature flags after resume

Signed-off-by: Jan Beulich 

Simon, could you give this a try please?

Thanks, Jan



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

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

[Dario Faggioli]

On Fri, 2018-04-13 at 11:29 +, George Dunlap wrote:
> I think as far as backports go, my current RFC would be
> fine.  Another possibility, though, would be to simply add a
> migrate() callback to remove the vcpu from the runqueue before
> switching v->processor, *without* removing any of the current song
> and dance about vcpu_sleep_nosync().  That should be fairly simple
> and straightforward to backport, and won’t make anything worse (since
> in theory it should have been removed by that point anyway).  Then
> for 4.12 we can figure out what we want to do going forward.
> 
FYI, adapting (but then I haven't even compiled) the first two patches
to as far as 4.7 was rather easy.

And, modulo the fact that I still have to properly review them (which
I'll do... but I looked at them, and they seem fine), I do prefer the
series, to the Credit1 migrate callback.

*Especially* if you are right, and the invariant is entirely Credit1
specific. In fact, that means here might be other code paths, in
sched_credit.c, that relies on it, and hence I'd prefer for it to be
enforced better, rather than relaxed, at this point in the cycle.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

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

Re: [Xen-devel] [PATCH 1/3] x86/pv: Introduce and use x86emul_read_dr()

[Jan Beulich]

>>> On 13.04.18 at 13:17,  wrote:
> On 13/04/18 09:31, Jan Beulich wrote:
> On 12.04.18 at 18:55,  wrote:
>>> do_get_debugreg() has several bugs:
>>>
>>>  * The %cr4.de condition is inverted.  %dr4/5 should be accessible only when
>>>%cr4.de is disabled.
>>>  * When %cr4.de is disabled, emulation should yield #UD rather than complete
>>>with zero.
>>>  * Using -EINVAL for errors is a broken ABI, as it overlaps with valid 
>>> values
>>>near the top of the address space.
>>>
>>> Introduce a common x86emul_read_dr() handler (as we will eventually want to
>>> add HVM support) which separates its success/failure indication from the 
>>> data
>>> value, and have do_get_debugreg() call into the handler.
>> The HVM part here is sort of questionable because of your use of
>> curr->arch.pv_vcpu.ctrlreg[4].
> 
> That is what the "needs further plumbing" refers to, as well as needing
> hooks to get/modify %dr6/7 from the VMCB/VMCS.
> 
> However, we are gaining an increasing amount of common x86 code which
> needs to read control register values, and I've got a plan to refactor
> across the board to v->arch.cr4 (and similar).  There is no point having
> identical information in different parts of sub-unions.

I agree.

>> This is appropriate for the NULL ctxt case,
>> but it's already a layering violation for the use of the function in
>> priv_op_ops, where the read_cr() hook should be used instead.
> 
> Hmm - doing this, while probably the better long temr course of action,
> would require passing the ops structures down into the callbacks.

That doesn't sound like a problem, though - the hypercall path would
pass NULL there as well.

>>> +int x86emul_read_dr(unsigned int reg, unsigned long *val,
>>> +struct x86_emulate_ctxt *ctxt)
>>> +{
>>> +struct vcpu *curr = current;
>>> +
>>> +/* HVM support requires a bit more plumbing before it will work. */
>>> +ASSERT(is_pv_vcpu(curr));
>>> +
>>> +switch ( reg )
>>> +{
>>> +case 0 ... 3:
>>> +case 6:
>>> +*val = curr->arch.debugreg[reg];
>>> +break;
>>> +
>>> +case 7:
>>> +*val = (curr->arch.debugreg[7] |
>>> +curr->arch.debugreg[5]);
>>> +break;
>>> +
>>> +case 4 ... 5:
>>> +if ( !(curr->arch.pv_vcpu.ctrlreg[4] & X86_CR4_DE) )
>>> +{
>>> +*val = curr->arch.debugreg[reg + 2];
>>> +break;
>> Once at it, wouldn't you better also fix the missing ORing of [5] into the 
>> DR7 (really
>> DR5) value here?
> 
> [5] is zero when %cr4.de is clear (subject to a bugfix in the subsequent
> patch), as IO breakpoints are only valid to use when %cr4.de is enabled.

Oh, right you are.

Jan



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

Re: [Xen-devel] [PATCH 2/3] x86/pv: Introduce and use x86emul_write_dr()

[Andrew Cooper]

On 13/04/18 09:39, Jan Beulich wrote:
 On 12.04.18 at 18:55,  wrote:
>> @@ -2029,7 +2035,17 @@ long set_debugreg(struct vcpu *v, unsigned int reg, 
>> unsigned long value)
>>  if ( v == curr )
>>  write_debugreg(3, value);
>>  break;
>> +
>> +case 4:
>> +if ( v->arch.pv_vcpu.ctrlreg[4] & X86_CR4_DE )
>> +return -ENODEV;
>> +
>> +/* Fallthrough */
>>  case 6:
>> +/* The upper 32 bits are strictly reserved. */
>> +if ( value != (uint32_t)value )
>> +return -EINVAL;
>> +
>>  /*
>>   * DR6: Bits 4-11,16-31 reserved (set to 1).
>>   *  Bit 12 reserved (set to 0).
> How are the upper 32 bits different from the other reserved bits (named in the
> comment visible here)?

The upper 32 bits are MBZ and will raise #GP if set.  The lower reserved
bits are write-ignored.

~Andrew

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

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

[George Dunlap]

> On Apr 13, 2018, at 10:25 AM, Dario Faggioli  wrote:
> 
> On Fri, 2018-04-13 at 09:03 +, George Dunlap wrote:
>>> On Apr 12, 2018, at 6:25 PM, Dario Faggioli 
>>> wrote:
>>> 
>> I think the bottom line is, for this test to be valid, then at this
>> point test_bit(VPF_migrating) *must* imply !vcpu_on_runqueue(v), but
>> at this point it doesn’t: If someone else has come by and cleared the
>> bit, done migration, and woken it up, and then someone *else* set the
>> bit again without taking it off the runqueue, it may still be on the
>> runqueue.
>> 
>> My series which calls vcpu_sleep_nosync_locked() after setting
>> VPF_migrating should help with this.
>> 
> Yes. In fact, Olaf, I still think that doing a run with George's RFC
> applied, would be useful, if only as a data point.
> 
>> Or, alternately, instead of baking all this implicit  knowledge about
>> credit into the scheduler, we should just implement
>> credit_vcpu_migrate(), and have it remove it from one runqueue and
>> put it on another.
>> 
> But it's not really "baking Credit implicit knowledge", IMO. It is that
> we have an invariant which we are failing to enforce.

Which invariant is that?  That a vcpu is not on a runqueue when switching 
v->processor.  But “on a runqueue” is a scheduler-specific construct that the 
main scheduling code doesn’t know about.  Otherwise we could make the late 
bail-out clause in vcpu_migrate() something like this:

if ( !v->is_running ||
 vcpu_on_runq(v) ||
 !test_and_clear_bit(VPF_migrating) )
{
 /* unlock and return */
}

All this stuff with vcpu_sleep_nosync() and vcpu_wake() is just indirectly 
making sure that the Credit1-specific invariant — that switching v->processor 
removes it from one runqueue and adds it to another — actually happens; but it 
does it in an opaque way.  And the main reason the migrate() callback was 
introduced (IIRC) is because credit2’s migration invariants didn’t really 
correspond to the invariants implicitly defined by schedule.c for credit1.

I think as far as backports go, my current RFC would be fine.  Another 
possibility, though, would be to simply add a migrate() callback to remove the 
vcpu from the runqueue before switching v->processor, *without* removing any of 
the current song and dance about vcpu_sleep_nosync().  That should be fairly 
simple and straightforward to backport, and won’t make anything worse (since in 
theory it should have been removed by that point anyway).  Then for 4.12 we can 
figure out what we want to do going forward.

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

Re: [Xen-devel] [PATCH 1/3] x86/pv: Introduce and use x86emul_read_dr()

[Andrew Cooper]

On 13/04/18 09:31, Jan Beulich wrote:
 On 12.04.18 at 18:55,  wrote:
>> do_get_debugreg() has several bugs:
>>
>>  * The %cr4.de condition is inverted.  %dr4/5 should be accessible only when
>>%cr4.de is disabled.
>>  * When %cr4.de is disabled, emulation should yield #UD rather than complete
>>with zero.
>>  * Using -EINVAL for errors is a broken ABI, as it overlaps with valid values
>>near the top of the address space.
>>
>> Introduce a common x86emul_read_dr() handler (as we will eventually want to
>> add HVM support) which separates its success/failure indication from the data
>> value, and have do_get_debugreg() call into the handler.
> The HVM part here is sort of questionable because of your use of
> curr->arch.pv_vcpu.ctrlreg[4].

That is what the "needs further plumbing" refers to, as well as needing
hooks to get/modify %dr6/7 from the VMCB/VMCS.

However, we are gaining an increasing amount of common x86 code which
needs to read control register values, and I've got a plan to refactor
across the board to v->arch.cr4 (and similar).  There is no point having
identical information in different parts of sub-unions.

> This is appropriate for the NULL ctxt case,
> but it's already a layering violation for the use of the function in
> priv_op_ops, where the read_cr() hook should be used instead.

Hmm - doing this, while probably the better long temr course of action,
would require passing the ops structures down into the callbacks.

>
>> +int x86emul_read_dr(unsigned int reg, unsigned long *val,
>> +struct x86_emulate_ctxt *ctxt)
>> +{
>> +struct vcpu *curr = current;
>> +
>> +/* HVM support requires a bit more plumbing before it will work. */
>> +ASSERT(is_pv_vcpu(curr));
>> +
>> +switch ( reg )
>> +{
>> +case 0 ... 3:
>> +case 6:
>> +*val = curr->arch.debugreg[reg];
>> +break;
>> +
>> +case 7:
>> +*val = (curr->arch.debugreg[7] |
>> +curr->arch.debugreg[5]);
>> +break;
>> +
>> +case 4 ... 5:
>> +if ( !(curr->arch.pv_vcpu.ctrlreg[4] & X86_CR4_DE) )
>> +{
>> +*val = curr->arch.debugreg[reg + 2];
>> +break;
> Once at it, wouldn't you better also fix the missing ORing of [5] into the 
> DR7 (really
> DR5) value here?

[5] is zero when %cr4.de is clear (subject to a bugfix in the subsequent
patch), as IO breakpoints are only valid to use when %cr4.de is enabled.

I haven't yet investigated the native behaviour of selecting an IO
breakpoint, then disabling Debug Extensions.

That said, one of my TODO items is to allow PV guests to use General
Detect (because its trivial to implement), at which point [5] will turn
from an IO breakpoint shadow, into a more general %dr7 shadow, and ORing
it in here will matter.

~Andrew

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

[Xen-devel] [xen-unstable-smoke test] 122239: regressions - trouble: blocked/fail

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm   6 xen-buildfail REGR. vs. 122174
 build-amd64   6 xen-buildfail REGR. vs. 122174
 build-armhf   6 xen-buildfail REGR. vs. 122174

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a

version targeted for testing:
 xen  ba2931d4e38fac4e6960e10b245efd3badeb4aa2
baseline version:
 xen  82540b66ceb9318aa185f2488cbbbe479694de8f

Last test of basis   122174  2018-04-11 11:01:17 Z1 days
Failing since122191  2018-04-12 16:01:30 Z0 days9 attempts
Testing same since   122193  2018-04-12 17:01:11 Z0 days8 attempts


People who touched revisions under test:
  George Dunlap 
  Ian Jackson 
  Konrad Rzeszutek Wilk 
  Lars Kurth 
  Oleksandr Andrushchenko 
  Oleksandr Grytsov 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit ba2931d4e38fac4e6960e10b245efd3badeb4aa2
Author: Oleksandr Andrushchenko 
Date:   Wed Mar 7 10:21:20 2018 +0200

sndif: Add explicit back and front parameter negotiation

In order to provide explicit stream parameter negotiation between
backend and frontend the following changes are introduced in the protocol:
add XENSND_OP_HW_PARAM_QUERY request to read/update
configuration space for the parameter given: request passes
desired parameter interval (mask) and the response to this request
returns min/max interval (mask) for the parameter to be used.

Parameters supported by this request/response:
 - format mask
 - sample rate interval
 - number of channels interval
 - buffer size, interval, frames
 - period size, interval, frames

Signed-off-by: Oleksandr Andrushchenko 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Takashi Iwai 
Cc: Konrad Rzeszutek Wilk 
Cc: Takashi Iwai 
Signed-off-by: Konrad Rzeszutek Wilk 
Release-acked-by: Juergen Gross 

commit 41b4cff11f4c4a497067f543cb010d70119f1843
Author: Oleksandr Andrushchenko 
Date:   Mon Feb 5 09:41:57 2018 +0200

sndif: Add explicit back and front synchronization

In order to provide explicit synchronization between backend and
frontend the following changes are introduced in the protocol:
 - add new ring buffer for sending asynchronous events from
   backend to frontend to report number of bytes played by the
   frontend (XENSND_EVT_CUR_POS)
 - introduce trigger events for playback control: start/stop/pause/resume
 - add "req-" prefix to event-channel and ring-ref to unify naming
   of the Xen event channels for requests and events

Signed-off-by: Oleksandr Andrushchenko 
Signed-off-by: Oleksandr Grytsov 

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 54ec85dd2902bd5dee39106d5291f71088b7d85a
baseline version:
 ovmf bf453d581ecff2a73128873fd714a07508e2ab11

Last test of basis   122200  2018-04-12 19:58:18 Z0 days
Testing same since   16  2018-04-13 05:16:49 Z0 days1 attempts


People who touched revisions under test:
  Jian J Wang 
  Star Zeng 

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 :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   bf453d581e..54ec85dd29  54ec85dd2902bd5dee39106d5291f71088b7d85a -> 
xen-tested-master

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

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

[Olaf Hering]

On Fri, Apr 13, Dario Faggioli wrote:

> Yes. In fact, Olaf, I still think that doing a run with George's RFC
> applied, would be useful, if only as a data point.

First tests indicate that this series fixes the bug.

Olaf


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

Re: [Xen-devel] [PATCH 5/5] SUPPORT.md: Document the new text ordering rule

[Ian Jackson]

Lars Kurth writes ("Re: [PATCH 5/5] SUPPORT.md: Document the new text ordering 
rule"):
...
> +In each case, descriptions which expand on the name of a feature as
> +provided in the section heading, precede the Status indications.
> 
> The following is a little clearer
> s/, descriptions which expand on the name of a feature as provided in the 
> section heading,/, descriptions which describe the feature in the section 
> heading in more detail,/

I used the wording I did because the word "description" is very
elastic, and might well be thought to include things that we intend as
caveats.

Ian.

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

Re: [Xen-devel] [PATCH v7 0/9] xen/x86: various XPTI speedups

[Juergen Gross]

On 13/04/18 11:59, Andrew Cooper wrote:
> On 12/04/18 19:09, Juergen Gross wrote:
>> This patch series aims at reducing the overhead of the XPTI Meltdown
>> mitigation.
> 
> Sadly, there are still problems. 
> 
> (XEN) [   13.486805] Dom0 has maximum 2 VCPUs
> (XEN) [   13.486824] [ Xen-4.11.0-5.0.3-d  x86_64  debug=y   Not tainted 
> ]
> (XEN) [   13.486826] CPU:0
> (XEN) [   13.486828] RIP:e008:[] 
> switch_cr3_cr4+0x58/0x116
> (XEN) [   13.486833] RFLAGS: 00010086   CONTEXT: hypervisor
> (XEN) [   13.486836] rax: 00df   rbx: 0282   rcx: 
> 82d0804b7fff
> (XEN) [   13.486839] rdx: 00152660   rsi: 001526e0   rdi: 
> 801071d4a000
> (XEN) [   13.486841] rbp: 82d0804b78d8   rsp: 82d0804b78a8   r8:  
> 
> (XEN) [   13.486844] r9:     r10: 00ff00ff00ff00ff   r11: 
> 0f0f0f0f0f0f0f0f
> (XEN) [   13.486847] r12: 801071d4a000   r13: 57ea8000   r14: 
> 001526e0
> (XEN) [   13.486849] r15: 83107326f000   cr0: 8005003b   cr4: 
> 00152660
> (XEN) [   13.486851] cr3: 57ea8000   cr2: 
> (XEN) [   13.486853] fsb:    gsb:    gss: 
> 
> (XEN) [   13.486855] ds:    es:    fs:    gs:    ss:    
> cs: e008
> (XEN) [   13.486859] Xen code around  
> (switch_cr3_cr4+0x58/0x116):
> (XEN) [   13.486860]  00 00 66 0f 38 82 4d d0 <41> 0f 22 dc 4c 39 f2 75 56 4c 
> 89 ea 81 e2 ff 0f
> (XEN) [   13.486869] Xen stack trace from rsp=82d0804b78a8:
> (XEN) [   13.486870]82d0804b78d8 82d0804466a2 83005a1f1000 
> 0002
> (XEN) [   13.486874]8200 83060fa0 82d0804b7d68 
> 82d08044349e
> (XEN) [   13.486878] 83060fa0 8200 
> 0ff0
> (XEN) [   13.486881] 001071d4c000 831071d4b000 
> 831071d4c000
> (XEN) [   13.486884]81d49000  0013 
> 831071d4dff8
> (XEN) [   13.486887]001071d5c000 831071d4d000 81d5e000 
> 8100
> (XEN) [   13.486891]01072000 001071d5d000 81d4a000 
> 81d49000
> (XEN) [   13.486894]831071d4c080 2000 0107 
> 81d49000
> (XEN) [   13.486897]8200 831071d4aff8 2000 
> 0001
> (XEN) [   13.486900]00800020 0080 570a 
> 0004
> (XEN) [   13.486903] 8000 831071d4dff0 
> 82d080485580
> (XEN) [   13.486907]83005a1f1000 05709ac2  
> 832079bd182c
> (XEN) [   13.486910]832079bd19e8   
> 
> (XEN) [   13.486913]0001 82d0803fd5e8 81b051f0 
> 0001
> (XEN) [   13.486916]82d0803fd436 81001000 0001 
> 82d0803fd410
> (XEN) [   13.486919]8000 0001 82d0803fd429 
> 
> (XEN) [   13.486923]0002 82d0803fd578 832079bd1868 
> 0002
> (XEN) [   13.486926]82d0803fd3d4 832079bd183c 0002 
> 82d0803fd584
> (XEN) [   13.486929]832079bd1854 0002 82d0803fd3cd 
> 832079bd1944
> (XEN) [   13.486933]0002 82d0803fd592 832079bd1930 
> 0002
> (XEN) [   13.486936] Xen call trace:
> (XEN) [   13.486938][] switch_cr3_cr4+0x58/0x116
> (XEN) [   13.486942][] dom0_construct_pv+0x1bb1/0x29e3
> (XEN) [   13.486945][] construct_dom0+0x8c/0xb86
> (XEN) [   13.486949][] __start_xen+0x23c4/0x2629
> (XEN) [   13.486952][] __high_start+0x53/0x58
> (XEN) [   13.486954]
> (XEN) [   14.047278]
> (XEN) [   14.049274] 
> (XEN) [   14.054734] Panic on CPU 0:
> (XEN) [   14.058026] GENERAL PROTECTION FAULT
> (XEN) [   14.062099] [error_code=]
> (XEN) [   14.065565] 
> (XEN) [   14.071024]
> (XEN) [   14.073018] Reboot in five seconds...
> 
> The faulting instruction is `mov %r12, %cr3` which is trying to use
> noflush while %cr4.pcide is clear.

While I can see how that happened I'm not sure why I didn't hit this
when testing my series. Could it be some cpus won't GP in this case?

Could you try the series without the last patch? Maybe it would be
possible to commit some of the patches at least.

I'm just about to leave for the Linux root conference in Kiev, so the
patch attached is only compile tested. You might want to try that.


Juergen

diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index 22c5150444..34c77bcbe4 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -718,7 +718,7 @@ int __init dom0_construct_pv(struct domain *d,
 

Re: [Xen-devel] [PATCH 0/7] xen/arm: CPU hotplug fixes

[Mirela Simonovic]

Hi Julien,

On Thu, Apr 12, 2018 at 10:43 AM, Julien Grall  wrote:
>
>
> On 11/04/18 17:37, Mirela Simonovic wrote:
>>
>> Hi Julien,
>
>
> Hi,
>
> May I ask you to configure your mail client to use > for quoting and use
> plain text? Otherwise, this is going to be really difficult to follow the
> discussion after few round (see already below).
>
>> On Wed, Apr 11, 2018 at 6:02 PM, Julien Grall > > wrote:
>>
>> Hi,
>>
>> On 11/04/18 16:58, Mirela Simonovic wrote:
>>
>> On 04/11/2018 05:07 PM, Julien Grall wrote:
>>
>> On 11/04/18 14:19, Mirela Simonovic wrote:
>>
>> Migrating interrupts when turning off a CPU already works.
>> However, when a CPU is turned back on there is no interrupt
>> migration back to the hotplugged CPU - all interrupts will
>> remain routed to the CPU#0.
>> Patch 7/7 fixes this
>>
>>
>> What do you mean by all interrupts? Interrupts routed to guest will
>> always follow the vCPU. So are you sure they are going to be
>> migrated when that vCPU is paused/off?
>>
>>
>> Just to make sure we're on the same page - this is about hotplugging
>> physical CPUs. Hotplugging vCPUs using virtual PSCI CPU_OFF interface is
>> already implemented and unrelated to this series.
>
>
> Yes, we are on the same page :). I was just wondering what happen to
> interrupt routed to that pCPU.
>
>>
>> Assuming that system has 2 pCPUs by 'all interrupts' I mean interrupts
>> that were targeted to the pCPU#0 and pCPU#1 prior to doing any hotplug.
>>
>> For example, if a guest is pinned to pCPU#1 an interrupt of a device it
>> owns will be targeted to pCPU#1.
>> When pCPU#1 is turned off that interrupt will be migrated to pCPU#0.
>> pCPU#0 finalizes the suspend and receives wake-up interrupts. However, when
>> CPU#1 is turned back on that interrupt will remain targeted to the CPU#0,
>> which I assumed is wrong.
>> The scenario described here is also how I tested this.
>>
>> Can you give the path in Xen doing that?
>>
>>
>> Sure, here is a backtrace (dumped on the CPU being turned off):
>>  0  0x2603dc arch_move_irqs(): vgic.c, line 309
>>  1  0x22ee58 sched_move_irqs()+20: schedule.c, line 303
>>  2  0x2318e8 cpu_disable_scheduler()+1000: schedule.c, line 586
>>  3  0x2318e8 cpu_disable_scheduler()+1000: schedule.c, line 586
>>  4  0x25aff8 __cpu_disable()+96: smpboot.c, line 386
>>  5  0x201608 take_cpu_down()+52: cpu.c, line 75
>>  6  0x23426c stopmachine_action()+188: stop_machine.c, line 159
>>  7  0x235858 do_tasklet_work()+176: tasklet.c, line 94
>>  8  0x235c80 do_tasklet()+104: tasklet.c, line 126
>>  9  0x24daec idle_loop()+144: domain.c, line 72
>> 10  0x25b1f8 start_secondary()+404: smpboot.c, line 368
>
>
>
> So this cover interrupt routed to a virtual CPU. However, this does not
> handle interrupts used by Xen. How do you handle them?
>
> For instance SMMUs IRQ might be routed to other interrupt than CPU #0.

Interrupts used by Xen should not wake-up the system and will be
disabled when we suspend the devices used by Xen.
However, I need to double check that such interrupts get enabled on
the right CPU on resume. Could you please tell me which mechanism in
Xen is used to target such an interrupt to a secondary CPU only? Is
that even possible and why would that be used?
Currently, I have no way to try out SMMU but I could try UART.

Thanks,
Mirela

>
> [...]
>
>>
>> If the former, it would be nice to get the code you used. If the
>> latter, then having a hack patch to test that code would be nice.
>> Ideally, you want to plug that in the SYSCTL interface for
>> out-of-box testing.
>>
>>
>> Ok, I have never used that but I'll try to figure it out. I may come up
>> with additional questions.
>
>
> You might want to have a look at the x86 version XEN_SYSCTL_cpu_hotplug in
> x86/systcl.c.
>
> Cheers,
>
> --
> Julien Grall

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

Re: [Xen-devel] [PATCH 5/5] SUPPORT.md: Document the new text ordering rule

[Lars Kurth]

On 12/04/2018, 19:26, "Ian Jackson"  wrote:

Signed-off-by: Ian Jackson 
---
 SUPPORT.md | 5 +
 1 file changed, 5 insertions(+)

diff --git a/SUPPORT.md b/SUPPORT.md
index 5ae84cf..098262b 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -725,6 +725,11 @@ The file is in markdown format.
 The machine-readable fragments are markdown literals
 containing RFC-822-like (deb822-like) data.
 
+In each case, descriptions which expand on the name of a feature as
+provided in the section heading, precede the Status indications.

The following is a little clearer
s/, descriptions which expand on the name of a feature as provided in the 
section heading,/, descriptions which describe the feature in the section 
heading in more detail,/

+Any paragraphs which follow the Status indication are caveats or
+qualifications of the information provided in Status fields.
+
 ## Keys found in the Feature Support subsections
 
 ### Status

Acked-by: Lars Kurth 

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

Re: [Xen-devel] [PATCH 7/7] xen/arm: Restore IRQ affinity after hotplugging a CPU

[Mirela Simonovic]

Hi Dario,

On Thu, Apr 12, 2018 at 6:49 PM, Dario Faggioli  wrote:
> On Wed, 2018-04-11 at 15:19 +0200, Mirela Simonovic wrote:
>> Secondary pCPUs will be offlined on system suspend and hotplugged
>> on resume. When offlining secondary CPUs all interrupts targeted
>> to those CPUs will be routed to the boot CPU. The boot CPU
>> is responsible for finalizing suspend procedure. All wake-up
>> interrupts are therefore targeted to the boot CPU.
>>

Maybe I should have made the last sentence more understandable, like
"Interrupts that could wake-up the system from suspend to RAM state
are therefore targeted to the boot CPU."

> There is no wake-up interrupt involved in the process of unpausing
> domains during resume. So, I that that what you mean is "the interrups
> that the vcpus receive once they're running again. And even in that
> case, rather than "All", is it "The interrupts received until the first
> time the vcpu goes through vcpu_migrate()", as vcpu_migrate() does call
> sched_move_irq()?
>
> Note that I'm not (trying to) being picky, I'm just trying to
> undestand. :-)

No worries, my commit message should be more understandable and your
answer helps me identify what's unclear. I'll try to explain below.

This is about suspend/resume implementation for ARM that is based on
PSCI and targeted for embedded systems as well. Each guest could have
its own wake-up devices/interrupts (passthrough) that could trigger
the resume. So the wake-up interrupt in this context triggers the
resume. By 'all interrupts' I meant interrupts that are left enabled
by guests upon suspend (those interrupts could wake-up the system).
Here is the PSCI-based suspend to RAM design spec:
https://lists.xenproject.org/archives/html/xen-devel/2017-12/msg01574.html

This patch is required to ensure that interrupts are migrated back to
secondary pCPUs on resume if that is needed. When a vCPU is pinned to
a secondary pCPU the vcpu migration will not happen on resume (and may
never happen), so the interrupt will remain targeted to the boot CPU.
I'll try to fix the commit message to better explain this.

>
>> Existing code
>> was missing the restoration of interrupts affinity after
>> hotplugging a CPU.
>>
> Either use hot-unplug and hotplug, or offline and online. I think the
> latter is better in this case.
>
>>  This patch restores the IRQ affinity after
>> a CPU is hotplugged.
>>
>> Signed-off-by: Mirela Simonovic 
>
>> diff --git a/xen/common/schedule.c b/xen/common/schedule.c
>> index 343ab6306e..e3956019bc 100644
>> --- a/xen/common/schedule.c
>> +++ b/xen/common/schedule.c
>> @@ -724,6 +725,9 @@ void restore_vcpu_affinity(struct domain *d)
>>  lock = vcpu_schedule_lock_irq(v);
>>  v->processor = SCHED_OP(vcpu_scheduler(v), pick_cpu, v);
>>  spin_unlock_irq(lock);
>> +
>> +if ( affinity_was_broken )
>> +sched_move_irqs(v);
>>
> But I guess that, more than on whether or not the affinity was broken,
> you are interested in whether or not v->processor changed.
>
> In fact, for the vcpus that had 0 in v->processor at the beginning of
> this function, and also have 0 in there now, there is no need to call
> sched_move_irq(), is there?
>
> Similarly, if the affinity of a vcpu has not been broken, but pick_cpu
> end up selecting a different v->processor, you do want to call
> sched_move_irq(), I think.
>
> If I'm right, I think it would be better to do, at the beginning of the
> for:
>
>  unsigned int old_cpu = v->processor;
>
> And here:
>
>  if (old_cpu != v->processor)
>sched_move_irqs(v);
>
> And I'd also add a comment (above the if()), briefly saying how this is
> necessary to match/undo the call work of vcpu_move_nosched() in
> cpu_disable_scheduler().
>

I though affinity check was sufficient but your proposal is better and
I'll fix the patch accordingly. Thanks for the feedback!

Regards,
Mirela

> Regards,
> Dario
> --
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Software Engineer @ SUSE https://www.suse.com/

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

Re: [Xen-devel] Setting up a call to discuss PCI Emulation - Future Direction

[Roger Pau Monné]

On Thu, Apr 12, 2018 at 05:50:00PM +0100, Lars Kurth wrote:
> 
> 
> On 12/04/2018, 17:41, "Roger Pau Monne"  wrote:
> 
> On Thu, Apr 12, 2018 at 05:32:57PM +0100, Lars Kurth wrote:
> 
> 
> >may work. For me Mon, Wed and Fri’s generally work at those 
> time-slots.
> >Next week is a little busy for me, so I would prefer the following 
> week.
> >If you could fill out the following Google poll, if this week works 
> that
> >would be great. Otherwise please scream.
> 
> I'm afraid I'm on vacations from the 21st to the 29th of April, so I
> won't be able to join the meeting unless we move it to the week after.
> Let's see what people think of the current dates.
> 
> Roger.
> 
> Hi, I changed the dates to the week after. Poll so far has been invalidated.
> 
> See https://doodle.com/poll/gdnmcrvnibmw563n

Thanks! I've already fixed my vote.

I guess this will come later, but we need a clear agenda of items
because the x86 and ARM topics are probably going to be completely
different (albeit all related to PCI).

Roger.

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

Re: [Xen-devel] [PATCH v7 0/9] xen/x86: various XPTI speedups

[Andrew Cooper]

On 12/04/18 19:09, Juergen Gross wrote:
> This patch series aims at reducing the overhead of the XPTI Meltdown
> mitigation.

Sadly, there are still problems. 

(XEN) [   13.486805] Dom0 has maximum 2 VCPUs
(XEN) [   13.486824] [ Xen-4.11.0-5.0.3-d  x86_64  debug=y   Not tainted 
]
(XEN) [   13.486826] CPU:0
(XEN) [   13.486828] RIP:e008:[] switch_cr3_cr4+0x58/0x116
(XEN) [   13.486833] RFLAGS: 00010086   CONTEXT: hypervisor
(XEN) [   13.486836] rax: 00df   rbx: 0282   rcx: 
82d0804b7fff
(XEN) [   13.486839] rdx: 00152660   rsi: 001526e0   rdi: 
801071d4a000
(XEN) [   13.486841] rbp: 82d0804b78d8   rsp: 82d0804b78a8   r8:  

(XEN) [   13.486844] r9:     r10: 00ff00ff00ff00ff   r11: 
0f0f0f0f0f0f0f0f
(XEN) [   13.486847] r12: 801071d4a000   r13: 57ea8000   r14: 
001526e0
(XEN) [   13.486849] r15: 83107326f000   cr0: 8005003b   cr4: 
00152660
(XEN) [   13.486851] cr3: 57ea8000   cr2: 
(XEN) [   13.486853] fsb:    gsb:    gss: 

(XEN) [   13.486855] ds:    es:    fs:    gs:    ss:    cs: 
e008
(XEN) [   13.486859] Xen code around  
(switch_cr3_cr4+0x58/0x116):
(XEN) [   13.486860]  00 00 66 0f 38 82 4d d0 <41> 0f 22 dc 4c 39 f2 75 56 4c 
89 ea 81 e2 ff 0f
(XEN) [   13.486869] Xen stack trace from rsp=82d0804b78a8:
(XEN) [   13.486870]82d0804b78d8 82d0804466a2 83005a1f1000 
0002
(XEN) [   13.486874]8200 83060fa0 82d0804b7d68 
82d08044349e
(XEN) [   13.486878] 83060fa0 8200 
0ff0
(XEN) [   13.486881] 001071d4c000 831071d4b000 
831071d4c000
(XEN) [   13.486884]81d49000  0013 
831071d4dff8
(XEN) [   13.486887]001071d5c000 831071d4d000 81d5e000 
8100
(XEN) [   13.486891]01072000 001071d5d000 81d4a000 
81d49000
(XEN) [   13.486894]831071d4c080 2000 0107 
81d49000
(XEN) [   13.486897]8200 831071d4aff8 2000 
0001
(XEN) [   13.486900]00800020 0080 570a 
0004
(XEN) [   13.486903] 8000 831071d4dff0 
82d080485580
(XEN) [   13.486907]83005a1f1000 05709ac2  
832079bd182c
(XEN) [   13.486910]832079bd19e8   

(XEN) [   13.486913]0001 82d0803fd5e8 81b051f0 
0001
(XEN) [   13.486916]82d0803fd436 81001000 0001 
82d0803fd410
(XEN) [   13.486919]8000 0001 82d0803fd429 

(XEN) [   13.486923]0002 82d0803fd578 832079bd1868 
0002
(XEN) [   13.486926]82d0803fd3d4 832079bd183c 0002 
82d0803fd584
(XEN) [   13.486929]832079bd1854 0002 82d0803fd3cd 
832079bd1944
(XEN) [   13.486933]0002 82d0803fd592 832079bd1930 
0002
(XEN) [   13.486936] Xen call trace:
(XEN) [   13.486938][] switch_cr3_cr4+0x58/0x116
(XEN) [   13.486942][] dom0_construct_pv+0x1bb1/0x29e3
(XEN) [   13.486945][] construct_dom0+0x8c/0xb86
(XEN) [   13.486949][] __start_xen+0x23c4/0x2629
(XEN) [   13.486952][] __high_start+0x53/0x58
(XEN) [   13.486954]
(XEN) [   14.047278]
(XEN) [   14.049274] 
(XEN) [   14.054734] Panic on CPU 0:
(XEN) [   14.058026] GENERAL PROTECTION FAULT
(XEN) [   14.062099] [error_code=]
(XEN) [   14.065565] 
(XEN) [   14.071024]
(XEN) [   14.073018] Reboot in five seconds...

The faulting instruction is `mov %r12, %cr3` which is trying to use
noflush while %cr4.pcide is clear.

~Andrew

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

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

[Dario Faggioli]

On Fri, 2018-04-13 at 09:03 +, George Dunlap wrote:
> > On Apr 12, 2018, at 6:25 PM, Dario Faggioli 
> > wrote:
> > 
> I think the bottom line is, for this test to be valid, then at this
> point test_bit(VPF_migrating) *must* imply !vcpu_on_runqueue(v), but
> at this point it doesn’t: If someone else has come by and cleared the
> bit, done migration, and woken it up, and then someone *else* set the
> bit again without taking it off the runqueue, it may still be on the
> runqueue.
> 
> My series which calls vcpu_sleep_nosync_locked() after setting
> VPF_migrating should help with this.
> 
Yes. In fact, Olaf, I still think that doing a run with George's RFC
applied, would be useful, if only as a data point.

> Or, alternately, instead of baking all this implicit  knowledge about
> credit into the scheduler, we should just implement
> credit_vcpu_migrate(), and have it remove it from one runqueue and
> put it on another.
> 
But it's not really "baking Credit implicit knowledge", IMO. It is that
we have an invariant which we are failing to enforce.

That's why your series goes in the right direction, because by calling
sleep() in the same critical section of where the bit is set, it
improves how we enforce the invariant.

Implementing a csched_vcpu_migrate(), looks to me like "relaxing" the
invariant, which is right the opposite direction. :-)

We may well decide to _get_rid_ of the invariant, but I'm not sure that
implementing csched_vcpu_migrate() would be all that this takes and, in
general, I don't think that something like this:
 - is an approapriate thing to do at this point of 4.11 cycle;
 - will be easy to backport (while, despite the look of it, 
   backporting patch 1 and 2 of your series might not be too terrible).

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

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

[Xen-devel] [distros-debian-jessie test] 74590: trouble: blocked/broken

[Platform Team regression test user]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvopsbroken
 build-i386   broken
 build-arm64  broken
 build-amd64-pvopsbroken
 build-armhf  broken
 build-i386-pvops broken
 build-amd64  broken
 build-arm64-pvopsbroken
 build-armhf   2 hosts-allocate  broken REGR. vs. 74300
 build-amd64-pvops 2 hosts-allocate  broken REGR. vs. 74300
 build-i3862 hosts-allocate  broken REGR. vs. 74300
 build-i386-pvops  2 hosts-allocate  broken REGR. vs. 74300
 build-armhf-pvops 2 hosts-allocate  broken REGR. vs. 74300
 build-amd64   2 hosts-allocate  broken REGR. vs. 74300
 build-i386-pvops  3 capture-logsbroken REGR. vs. 74300
 build-amd64   3 capture-logsbroken REGR. vs. 74300
 build-i3863 capture-logsbroken REGR. vs. 74300
 build-amd64-pvops 3 capture-logsbroken REGR. vs. 74300

Tests which did not succeed, but are not blocking:
 test-amd64-i386-i386-jessie-netboot-pvgrub  1 build-check(1)   blocked n/a
 test-amd64-i386-amd64-jessie-netboot-pygrub  1 build-check(1)  blocked n/a
 test-amd64-amd64-i386-jessie-netboot-pygrub  1 build-check(1)  blocked n/a
 test-armhf-armhf-armhf-jessie-netboot-pygrub  1 build-check(1) blocked n/a
 test-arm64-arm64-armhf-jessie-netboot-pygrub  1 build-check(1) blocked n/a
 test-amd64-amd64-amd64-jessie-netboot-pvgrub  1 build-check(1) blocked n/a
 build-arm64-pvops 2 hosts-allocate broken blocked in 74300
 build-arm64   2 hosts-allocate broken blocked in 74300
 build-arm64   3 capture-logs   broken blocked in 74300
 build-arm64-pvops 3 capture-logs   broken blocked in 74300
 build-armhf   3 capture-logs broken like 74300
 build-armhf-pvops 3 capture-logs broken like 74300

baseline version:
 flight   74300

jobs:
 build-amd64  broken  
 build-arm64  broken  
 build-armhf  broken  
 build-i386   broken  
 build-amd64-pvopsbroken  
 build-arm64-pvopsbroken  
 build-armhf-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-amd64-jessie-netboot-pvgrub blocked 
 test-amd64-i386-i386-jessie-netboot-pvgrub   blocked 
 test-amd64-i386-amd64-jessie-netboot-pygrub  blocked 
 test-arm64-arm64-armhf-jessie-netboot-pygrub blocked 
 test-armhf-armhf-armhf-jessie-netboot-pygrub blocked 
 test-amd64-amd64-i386-jessie-netboot-pygrub  blocked 



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

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

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


Push not applicable.


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

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

[George Dunlap]

> On Apr 12, 2018, at 6:25 PM, Dario Faggioli  wrote:
> 
> On Thu, 2018-04-12 at 17:38 +0200, Dario Faggioli wrote:
>> On Thu, 2018-04-12 at 15:15 +0200, Dario Faggioli wrote:
>>> On Thu, 2018-04-12 at 14:45 +0200, Olaf Hering wrote:
 
 dies after the first iteration.
 
BUG_ON(!test_bit(_VPF_migrating, >pause_flags));
 
>> 
>> Update. I replaced this:
>> 
> Olaf, new patch! :-)
> 
> FTR, a previous version of this (where I was not printing
> smp_processor_id() and prev->is_running), produced the output that I am
> attaching below.
> 
> Looks to me like, while on the crashing CPU, we are here [*]:
> 
> void context_saved(struct vcpu *prev)
> {
>...
>if ( unlikely(prev->pause_flags & VPF_migrating) )
>{
>unsigned long flags;
>spinlock_t *lock = vcpu_schedule_lock_irqsave(prev, );
> 
>if (vcpu_runnable(prev) || !test_bit(_VPF_migrating, 
> >pause_flags))
>printk("CPU %u: d%uv%d isr=%u runnbl=%d proc=%d pf=%lu orq=%d 
> csf=%u\n",
>   smp_processor_id(), prev->domain->domain_id, prev->vcpu_id,
>   prev->is_running, vcpu_runnable(prev),
>   prev->processor, prev->pause_flags,
>   SCHED_OP(vcpu_scheduler(prev), onrunq, prev),
>   SCHED_OP(vcpu_scheduler(prev), csflags, prev));
> 
>[*]
> 
>if ( prev->runstate.state == RUNSTATE_runnable )
>vcpu_runstate_change(prev, RUNSTATE_offline, NOW());
>BUG_ON(curr_on_cpu(prev->processor) == prev);
>SCHED_OP(vcpu_scheduler(prev), sleep, prev);
> 
>vcpu_schedule_unlock_irqrestore(lock, flags, prev);
> 
>vcpu_migrate(prev);
>}
> }
> 
> On the "other CPU", we might be around here [**]:
> 
> static void vcpu_migrate(struct vcpu *v)
> {
>...
>if ( v->is_running ||
> !test_and_clear_bit(_VPF_migrating, >pause_flags) )n

I think the bottom line is, for this test to be valid, then at this point 
test_bit(VPF_migrating) *must* imply !vcpu_on_runqueue(v), but at this point it 
doesn’t: If someone else has come by and cleared the bit, done migration, and 
woken it up, and then someone *else* set the bit again without taking it off 
the runqueue, it may still be on the runqueue.

My series which calls vcpu_sleep_nosync_locked() after setting VPF_migrating 
should help with this.

Or, alternately, instead of baking all this implicit  knowledge about credit 
into the scheduler, we should just implement credit_vcpu_migrate(), and have it 
remove it from one runqueue and put it on another.

 -George

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

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

[Dario Faggioli]

On Fri, 2018-04-13 at 08:23 +0200, Olaf Hering wrote:
> Am Thu, 12 Apr 2018 19:25:43 +0200
> schrieb Dario Faggioli :
> 
> > Olaf, new patch! :-)
> 
> BUG_ON(__vcpu_on_runq(CSCHED_VCPU(vc)));
> 
Thanks!

> (XEN) CPU 36: d10v1 isr=0 runnbl=1 proc=36 pf=0 orq=0 csf=4
>
So, FTR:
- CPU is smp_processor_id()
- dXvY is prev, in context_saved()
- isr is prev->is_running
- runnbl is vcpu_runnable(prev)
- proc is prev->processor
- pf is pref->pause_flags
- orq is __vcpu_on_runq(CSCHED_VCPU(prev)) (coming from sched_credit.c)
- csf is CSCHED_VCPU(prev)->flags

csf = 4 is CSCHED_FLAG_VCPU_MIGRATING, which means someone is calling
vcpu_migrate() on prev, on some other processor (presumably via
vcpu_set_affinity()) and is around here:

static void vcpu_migrate(struct vcpu *v)
{
...
if ( v->is_running ||
 !test_and_clear_bit(_VPF_migrating, >pause_flags) )
{
sched_spin_unlock_double(old_lock, new_lock, flags); 
return; 
} 
 
vcpu_move_locked(v, new_cpu); 
 
sched_spin_unlock_double(old_lock, new_lock, flags); 

[**] 

if ( old_cpu != new_cpu ) 
sched_move_irqs(v); 
 
/* Wake on new CPU. */ 
vcpu_wake(v); 
}

I.e., SCHED_OP(pick_cpu) has been called already, but not vcpu_wake().

We must be past the sched_spin_unlock_double() because, on this
processor (i.e., CPU 31 in this crash), we are, while printing,
_inside_ a critical section on prev's scheduler lock.

> (XEN) CPU 33: d10v2 isr=0 runnbl=0 proc=33 pf=1 orq=0 csf=4
> (XEN) CPU 20: d10v2 isr=0 runnbl=1 proc=20 pf=0 orq=0 csf=4
> (XEN) CPU 32: d10v0 isr=0 runnbl=1 proc=32 pf=0 orq=0 csf=4
> (XEN) CPU 33: d10v0 isr=0 runnbl=1 proc=12 pf=0 orq=0 csf=4
> (XEN) CPU 36: d10v0 isr=0 runnbl=1 proc=36 pf=0 orq=0 csf=4
> (XEN) CPU 31: d10v0 isr=0 runnbl=1 proc=31 pf=0 orq=0 csf=4
> (XEN) Xen BUG at sched_credit.c:877
> (XEN) [ Xen-4.11.20180411T100655.82540b66ce-
> 180413055758  x86_64  debug=y   Not tainted ]
> (XEN) CPU:31
>
Right, so, in this case, the vcpu_migrate()->SCHED_OP(pick_cpu) did not
change prev->processor. That could very well have happened. This just
means that, if it weren't for the BUG_ON added in csched_vcpu_migrate()
by this patch, this iteration would not have crashed in
csched_load_balance().

However, in previous report, we have seen a situation where
prev->processor was 31 on CPU 16.

Fact is, VPF_migrating is 0 right now, for prev, which corroborates the
theory that we are at [*] point, in vcpu_migrate() on the other CPU. In
fact, it was 1, but !test_and_clear_bit() has been called to reset it.

However, in order for us, on this CPU, to actually execute
sched_move_locked(), like we do:

> (XEN) Xen call trace:
> (XEN)[]
> sched_credit.c#csched_vcpu_migrate+0x52/0x54
> (XEN)[] schedule.c#vcpu_move_locked+0x42/0xcc
>
It means that someone raise VPF_migrating again!

> (XEN)[] schedule.c#vcpu_migrate+0x210/0x23b
> (XEN)[] context_saved+0x236/0x479
> (XEN)[] context_switch+0xe9/0xf67
> (XEN)[] schedule.c#schedule+0x306/0x6ab
> (XEN)[] softirq.c#__do_softirq+0x71/0x9a
> (XEN)[] do_softirq+0x13/0x15
> (XEN)[] vmx_asm_do_vmentry+0x2b/0x30
> (XEN) 
> (XEN) Panic on CPU 31:
> (XEN) Xen BUG at sched_credit.c:877
> (XEN) 
>
Now, VPF_migrating is raise in the following circumstances:

* in __runq_tickle(): I actually was about to pinpoint this as the 
  problem, but then I realized that, when calling __runq_tickle(prev),
  in vcpu_wake() (called by vcpu_migrate()), we do not set the bit on
  prev itself, but on the currently running vcpu of prev->processor.
  And a vcpu that is in  per_cpu(schedule_data, ).curr, can't 
  also be prev in (any) context_saved(), I think.

* in csched_vcpu_acct(): we set the flag on CSCHED_VCPU(current). I 
   may be wrong, but I don't immediatly see why we use current here, 
   instead than curr_on_cpu(cpu). Yet, I think that, similarly to 
   above, current can't be prev. Still, I may send a "Just in case"^TM 
   patch... :-P

* in vcpu_force_reschedule(): it's used in shim code (well... :-) and 
  in VCPUOP_set_periodic_timer(). But it only sets the flag if
  prev->is_running is 1, which is not. Besides, don't most guests use 
  singleshot timer only these days?

* in cpu_disable_scheduler(): no. Just no.

* in vcpu_set_affinity(): well, it looks to me that, either, a) we use
  the set of the bit in here to actually enter the if() in
  context_saved(), which is a precondition for the race, and then we
  are already past that or, b) things just work. Will think more...

* in vcpu_pin_override(): again, no I think?

So, thoughts? :-)

Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

signature.asc
Description: This is a digitally signed message part

[Xen-devel] [xen-unstable-smoke test] 122230: regressions - trouble: blocked/fail

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm   6 xen-buildfail REGR. vs. 122174
 build-amd64   6 xen-buildfail REGR. vs. 122174
 build-armhf   6 xen-buildfail REGR. vs. 122174

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386  1 build-check(1) blocked n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a

version targeted for testing:
 xen  ba2931d4e38fac4e6960e10b245efd3badeb4aa2
baseline version:
 xen  82540b66ceb9318aa185f2488cbbbe479694de8f

Last test of basis   122174  2018-04-11 11:01:17 Z1 days
Failing since122191  2018-04-12 16:01:30 Z0 days8 attempts
Testing same since   122193  2018-04-12 17:01:11 Z0 days7 attempts


People who touched revisions under test:
  George Dunlap 
  Ian Jackson 
  Konrad Rzeszutek Wilk 
  Lars Kurth 
  Oleksandr Andrushchenko 
  Oleksandr Grytsov 

jobs:
 build-arm64-xsm  fail
 build-amd64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit ba2931d4e38fac4e6960e10b245efd3badeb4aa2
Author: Oleksandr Andrushchenko 
Date:   Wed Mar 7 10:21:20 2018 +0200

sndif: Add explicit back and front parameter negotiation

In order to provide explicit stream parameter negotiation between
backend and frontend the following changes are introduced in the protocol:
add XENSND_OP_HW_PARAM_QUERY request to read/update
configuration space for the parameter given: request passes
desired parameter interval (mask) and the response to this request
returns min/max interval (mask) for the parameter to be used.

Parameters supported by this request/response:
 - format mask
 - sample rate interval
 - number of channels interval
 - buffer size, interval, frames
 - period size, interval, frames

Signed-off-by: Oleksandr Andrushchenko 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Takashi Iwai 
Cc: Konrad Rzeszutek Wilk 
Cc: Takashi Iwai 
Signed-off-by: Konrad Rzeszutek Wilk 
Release-acked-by: Juergen Gross 

commit 41b4cff11f4c4a497067f543cb010d70119f1843
Author: Oleksandr Andrushchenko 
Date:   Mon Feb 5 09:41:57 2018 +0200

sndif: Add explicit back and front synchronization

In order to provide explicit synchronization between backend and
frontend the following changes are introduced in the protocol:
 - add new ring buffer for sending asynchronous events from
   backend to frontend to report number of bytes played by the
   frontend (XENSND_EVT_CUR_POS)
 - introduce trigger events for playback control: start/stop/pause/resume
 - add "req-" prefix to event-channel and ring-ref to unify naming
   of the Xen event channels for requests and events

Signed-off-by: Oleksandr Andrushchenko 
Signed-off-by: Oleksandr Grytsov 

Re: [Xen-devel] [PATCH v7 1/9] x86/xpti: avoid copying L4 page table contents when possible

[Jan Beulich]

>>> On 12.04.18 at 20:09,  wrote:
> For mitigation of Meltdown the current L4 page table is copied to the
> cpu local root page table each time a 64 bit pv guest is entered.
> 
> Copying can be avoided in cases where the guest L4 page table hasn't
> been modified while running the hypervisor, e.g. when handling
> interrupts or any hypercall not modifying the L4 page table or %cr3.
> 
> So add a per-cpu flag indicating whether the copying should be
> performed and set that flag only when loading a new %cr3 or modifying
> the L4 page table.  This includes synchronization of the cpu local
> root page table with other cpus, so add a special synchronization flag
> for that case.
> 
> A simple performance check (compiling the hypervisor via "make -j 4")
> in dom0 with 4 vcpus shows a significant improvement:
> 
> - real time drops from 112 seconds to 103 seconds
> - system time drops from 142 seconds to 131 seconds
> 
> Signed-off-by: Juergen Gross 
> Reviewed-by: Jan Beulich 
> ---
> V7:
> - add missing flag setting in shadow code

This now needs an ack from Tim (now Cc-ed).

Jan



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

Re: [Xen-devel] [PATCH 3/3] x86/traps: Misc non-functional improvements to set_debugreg()

[Jan Beulich]

 >>> On 12.04.18 at 18:55,  wrote:
> * Change 'int i' to being unsigned, and move it into its most narrow scope.
>  * Fold the access_ok() checks for %dr{0..3}.  This halves the compiled size
>of the function.
>  * Additional newlines in appropriate places.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH 2/3] x86/pv: Introduce and use x86emul_write_dr()

[Jan Beulich]

>>> On 12.04.18 at 18:55,  wrote:
> @@ -2029,7 +2035,17 @@ long set_debugreg(struct vcpu *v, unsigned int reg, 
> unsigned long value)
>  if ( v == curr )
>  write_debugreg(3, value);
>  break;
> +
> +case 4:
> +if ( v->arch.pv_vcpu.ctrlreg[4] & X86_CR4_DE )
> +return -ENODEV;
> +
> +/* Fallthrough */
>  case 6:
> +/* The upper 32 bits are strictly reserved. */
> +if ( value != (uint32_t)value )
> +return -EINVAL;
> +
>  /*
>   * DR6: Bits 4-11,16-31 reserved (set to 1).
>   *  Bit 12 reserved (set to 0).

How are the upper 32 bits different from the other reserved bits (named in the
comment visible here)?

> @@ -2039,7 +2055,17 @@ long set_debugreg(struct vcpu *v, unsigned int reg, 
> unsigned long value)
>  if ( v == curr )
>  write_debugreg(6, value);
>  break;
> +
> +case 5:
> +if ( v->arch.pv_vcpu.ctrlreg[4] & X86_CR4_DE )
> +return -ENODEV;
> +
> +/* Fallthrough */
>  case 7:
> +/* The upper 32 bits are strictly reserved. */
> +if ( value != (uint32_t)value )
> +return -EINVAL;
> +
>  /*
>   * DR7: Bit 10 reserved (set to 1).
>   *  Bits 11-12,14-15 reserved (set to 0).

Same here then.

Jan



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

Re: [Xen-devel] [PATCH 1/3] x86/pv: Introduce and use x86emul_read_dr()

[Jan Beulich]

>>> On 12.04.18 at 18:55,  wrote:
> do_get_debugreg() has several bugs:
> 
>  * The %cr4.de condition is inverted.  %dr4/5 should be accessible only when
>%cr4.de is disabled.
>  * When %cr4.de is disabled, emulation should yield #UD rather than complete
>with zero.
>  * Using -EINVAL for errors is a broken ABI, as it overlaps with valid values
>near the top of the address space.
> 
> Introduce a common x86emul_read_dr() handler (as we will eventually want to
> add HVM support) which separates its success/failure indication from the data
> value, and have do_get_debugreg() call into the handler.

The HVM part here is sort of questionable because of your use of
curr->arch.pv_vcpu.ctrlreg[4]. This is appropriate for the NULL ctxt case,
but it's already a layering violation for the use of the function in
priv_op_ops, where the read_cr() hook should be used instead.

> The ABI of do_get_debugreg() remains broken, but switches from -EINVAL to
> -ENODEV for compatibility with the changes in the following patch.
> 
> Take the opportunity to add a missing local variable block to x86_emulate.c

I don't think such a block can ever be "missing" - it shouldn't really be a 
requirement
for one to be there; note how ./CODING_STYLE says "is permitted". Of course I
don't mind its addition here.

> +int x86emul_read_dr(unsigned int reg, unsigned long *val,
> +struct x86_emulate_ctxt *ctxt)
> +{
> +struct vcpu *curr = current;
> +
> +/* HVM support requires a bit more plumbing before it will work. */
> +ASSERT(is_pv_vcpu(curr));
> +
> +switch ( reg )
> +{
> +case 0 ... 3:
> +case 6:
> +*val = curr->arch.debugreg[reg];
> +break;
> +
> +case 7:
> +*val = (curr->arch.debugreg[7] |
> +curr->arch.debugreg[5]);
> +break;
> +
> +case 4 ... 5:
> +if ( !(curr->arch.pv_vcpu.ctrlreg[4] & X86_CR4_DE) )
> +{
> +*val = curr->arch.debugreg[reg + 2];
> +break;

Once at it, wouldn't you better also fix the missing ORing of [5] into the DR7 
(really
DR5) value here?

Jan



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

Re: [Xen-devel] [PATCH 1/2] x86/microcode: Synchronize late microcode loading

[Jan Beulich]

>>> On 13.04.18 at 07:25,  wrote:
> On Thu, Apr 12, 2018 at 09:29:34AM -0700, Raj, Ashok wrote:
>>On Fri, Mar 30, 2018 at 02:59:00PM +0800, Chao Gao wrote:
>>> From: Gao Chao 
>>> 
>>> This patch is to backport microcode improvement patches from linux
>>> kernel. Below are the original patches description:
>>> 
>>> commit a5321aec6412b20b5ad15db2d6b916c05349dbff
>>> Author: Ashok Raj 
>>> Date:   Wed Feb 28 11:28:46 2018 +0100
>>> 
>>> x86/microcode: Synchronize late microcode loading
>>> 
>>> Original idea by Ashok, completely rewritten by Borislav.
>>> 
>>> Before you read any further: the early loading method is still the
>>> preferred one and you should always do that. The following patch is
>>> improving the late loading mechanism for long running jobs and cloud use
>>> cases.
>>> 
>>> Gather all cores and serialize the microcode update on them by doing it
>>> one-by-one to make the late update process as reliable as possible and
>>> avoid potential issues caused by the microcode update.
>>> 
>>> [ Borislav: Rewrite completely. ]
>>> 
>>> Co-developed-by: Borislav Petkov 
>>> Signed-off-by: Ashok Raj 
>>> Signed-off-by: Borislav Petkov 
>>> Signed-off-by: Thomas Gleixner 
>>> Tested-by: Tom Lendacky 
>>> Tested-by: Ashok Raj 
>>
>>The tested by tags were good for linux upstream. Can you make sure
>>you add your name under tested-by for xen?
> 
> Tested-by doesn't mean they have tested this patch. I just put the
> original commits description here.

Tested-by being as meaningful in Xen as it is in Linux, retaining such tags 
(other
than authorship ones) is generally wrong, as it gives a wrong impression on
what testing the _Xen_ patch has seen.

> If Xen permits such tested-by from the sender and author, I will add one.

I think it is generally implied that the author has done some testing. In the
case here - with a ported over Linux commit by other than the original
author - I would view a T-b by the original author as meaningful though. It
should be made clear though that this is a ported Linux commit, which
generally we do by naming the Linux commit. See e.g. the history of
mwait-idle.c, where most of the commits are straight ports from Linux.

Jan



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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
122170

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 122170
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 122170
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122170
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 122170
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 122170
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 122170
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 122170
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 122170
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122170
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 xen  82540b66ceb9318aa185f2488cbbbe479694de8f
baseline version:
 xen  50f8ba84a50ebf80dd22067a04062dbaaf2621ff

Last test of basis   122170  2018-04-11 08:04:39 Z1 days
Testing same since   122185  2018-04-12 07:57:25 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

Re: [Xen-devel] Setting up a call to discuss PCI Emulation - Future Direction

[Jan Beulich]

>>> On 12.04.18 at 18:32,  wrote:
> I had an action to set up a call on discussing the future direction of PCI 
> Emulation. I CC’ed everyone who raised an interest. I propose to use 
> Gotomeeting unless there are objections.

FTR - I had expressed an interest too; I can't really plan for the next week or
two though at this point, so I'd join if I can whenever the meeting takes place.

Jan


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

Re: [Xen-devel] [PATCH 0/5] SUPPORT.md: Distinguish descriptions from caveats

[Lars Kurth]

On 12/04/2018, 19:29, "Ian Jackson"  wrote:

Ian Jackson writes ("[PATCH 0/5] SUPPORT.md: Distinguish descriptions from 
caveats"):
> The new support matrix output puts a [*] after each entry in the
> support matrix in many cases where the linked-to text is simply a
> longer description of the feature.

Example output:
  https://xenbits.xen.org/people/iwj/2018/support-matrix-example-B-v1/t.html

Looks good to me
Lars
 

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

Re: [Xen-devel] Linux Dom0 console handling (again)

[Jan Beulich]

>>> On 12.04.18 at 19:56,  wrote:
> On 04/12/2018 04:06 AM, Jan Beulich wrote:
>> Jürgen, Boris,
>>
>> looks like commit 47b02f4c62 ("x86/xen: add tty0 and hvc0 as
>> preferred consoles for dom0") doesn't get us quite there yet - non-
>> kernel boot output (and a console prompt) still doesn't appear on
>> the screen. 
> 
> 
> Hmm.. I get both kernel and systemd output, as well as console prompt,
> on both serial and screen.
> 
> Is there a specific set of console-related boot options that causes this
> problem?

None at all, but I'm observing this on an older distro (not systemd based).

Jan


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