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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt   6 libvirt-buildfail REGR. vs. 146182
 build-i386-libvirt6 libvirt-buildfail REGR. vs. 146182
 build-arm64-libvirt   6 libvirt-buildfail REGR. vs. 146182
 build-armhf-libvirt   6 libvirt-buildfail REGR. vs. 146182

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

version targeted for testing:
 libvirt  3a3a85c529e92ad767fbe01587186854c175
baseline version:
 libvirt  a1cd25b919509be2645dbe6f952d5263e0d4e4e5

Last test of basis   146182  2020-01-17 06:00:23 Z   11 days
Failing since146211  2020-01-18 04:18:52 Z   10 days   11 attempts
Testing same since   146546  2020-01-28 04:19:33 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Boris Fiuczynski 
  Christian Ehrhardt 
  Daniel P. Berrangé 
  Han Han 
  Jonathon Jongsma 
  Julio Faracco 
  Ján Tomko 
  Marek Marczykowski-Górecki 
  Michal Privoznik 
  Pavel Hrdina 
  Peter Krempa 
  Richard W.M. Jones 
  Thomas Huth 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-arm64-libvirt  fail
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-amd64-libvirt-xsm blocked 
 test-arm64-arm64-libvirt-xsm blocked 
 test-amd64-i386-libvirt-xsm  blocked 
 test-amd64-amd64-libvirt blocked 
 test-arm64-arm64-libvirt blocked 
 test-armhf-armhf-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-libvirt-pairblocked 
 test-amd64-i386-libvirt-pair blocked 
 test-arm64-arm64-libvirt-qcow2   blocked 
 test-armhf-armhf-libvirt-raw blocked 
 test-amd64-amd64-libvirt-vhd 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

[Xen-devel] [PATCH v2] docs: document CONTROL command of xenstore protocol

[Juergen Gross]

The CONTROL command (former DEBUG command) isn't specified in the
xenstore protocol doc. Add it.

Signed-off-by: Juergen Gross 
---
 docs/misc/xenstore.txt | 36 
 1 file changed, 28 insertions(+), 8 deletions(-)

diff --git a/docs/misc/xenstore.txt b/docs/misc/xenstore.txt
index 65570183b6..6f8569d576 100644
--- a/docs/misc/xenstore.txt
+++ b/docs/misc/xenstore.txt
@@ -318,12 +318,32 @@ SET_TARGET||
 
 -- Miscellaneous --
 
-DEBUG  print||??   sends  to debug log
-DEBUG  print|   EINVAL
-DEBUG  check|??checks xenstored innards
-DEBUG  no-op (future extension)
-
-   These requests should not generally be used and may be
-   withdrawn in the future.
-
+CONTROL|[|]
+   Send a control command  with optional parameters
+   () to Xenstore daemon.
+
+   The set of commands and their semantics is implementation
+   specific and is likely to change from one Xen version to the
+   next.  Out-of-tree users will encounter compatibility issues.
+
+   Current commands are:
+   check
+   checks xenstored innards
+   log|on
+   turn xenstore logging on
+   log|off
+   turn xenstore logging off
+   logfile|
+   log to specified file
+   memreport|[]
+   print memory statistics to logfile (no 
+   specified) or to specific file
+   print|
+   print  to syslog (xenstore runs as daemon) or
+   to console (xenstore runs as stubdom)
+   help
+   return list of supported commands for CONTROL
+
+DEBUG
+   Deprecated, now named CONTROL
 
-- 
2.16.4


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

Re: [Xen-devel] [RFC 0/6] vDSO support for Hyper-V guest on ARM64

[Boqun Feng]

On Fri, Jan 24, 2020 at 10:24:44AM +, Vincenzo Frascino wrote:
> Hi Boqun Feng,
> 
> On 24/01/2020 06:32, Boqun Feng wrote:
> > Hi Vincenzo,
> > 
> 
> [...]
> 
> >>
> >> I had a look to your patches and overall, I could not understand why we 
> >> can't
> >> use the arch_timer to do the same things you are doing with the one you
> >> introduced in this series. What confuses me is that KVM works just fine 
> >> with the
> >> arch_timer which was designed with virtualization in mind. Why do we need
> >> another one? Could you please explain?
> >>
> > 
> > Please note that the guest VM on Hyper-V for ARM64 doesn't use
> > arch_timer as the clocksource. See:
> > 
> > 
> > https://lore.kernel.org/linux-arm-kernel/1570129355-16005-7-git-send-email-mikel...@microsoft.com/
> > 
> > ,  ACPI_SIG_GTDT is used for setting up Hyper-V synthetic clocksource
> > and other initialization work.
> >
> 
> I had a look a look at it and my question stands, why do we need another timer
> on arm64?
> 

Sorry for the late response. It's weekend and Chinese New Year, so I got
to spend some time making (and mostly eating) dumplings ;-)

After discussion with Michael, here is some explanation why we need
another timer:

The synthetic clocks that Hyper-V presents in a guest VM were originally
created for the x86 architecture. They provide a level of abstraction
that solves problems like continuity across live migrations where the
hardware clock (i.e., TSC in the case x86) frequency may be different
across the migration. When Hyper-V was brought to ARM64, this
abstraction was maintained to provide consistency across the x86 and
ARM64 architectures, and for both Windows and Linux guest VMs.   The
core Linux code for the Hyper-V clocks (in
drivers/clocksource/hyperv_timer.c) is architecture neutral and works on
both x86 and ARM64. As you can see, this part is done in Michael's
patchset.

Arguably, Hyper-V for ARM64 should have optimized for consistency with
the ARM64 community rather with the existing x86 implementation and
existing guest code in Windows. But at this point, it is what it is,
and the Hyper-V clocks do solve problems like migration that aren’t
addressed in ARM64 until v8.4 of the architecture with the addition of
the counter hardware scaling feature. Hyper-V doesn’t currently map the
ARM arch timer interrupts into guest VMs, so we need to use the existing
Hyper-V clocks and the common code that already exists.


Does the above answer your question?

Regards,
Boqun

> > So just to be clear, your suggestion is
> > 
> > 1) Hyper-V guest on ARM64 should use arch_timer as clocksource and vDSO
> > will just work.
> > 
> > or
> > 
> > 2) Even though arch_timer is not used as the clocksource, we can still
> > use it for vDSO.
> > 
> > ?
> > 
> 
> Option #1 would be the preferred solution, unless there is a good reason 
> against.
> 
> > Regards,
> > Boqun
> > 
> 
> -- 
> Regards,
> Vincenzo



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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   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-qemuu-debianhvm-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-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw

[Xen-devel] [ovmf test] 146542: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 
145767

version targeted for testing:
 ovmf c8b8157e126ae2fb6f65842677251d300ceff104
baseline version:
 ovmf 70911f1f4aee0366b6122f2b90d367ec0f066beb

Last test of basis   145767  2020-01-08 00:39:09 Z   20 days
Failing since145774  2020-01-08 02:50:20 Z   20 days   76 attempts
Testing same since   146482  2020-01-24 19:39:39 Z3 days   15 attempts


People who touched revisions under test:
  Aaron Li 
  Albecki, Mateusz 
  Ard Biesheuvel 
  Ashish Singhal 
  Bob Feng 
  Brian R Haug 
  Eric Dong 
  Fan, ZhijuX 
  Hao A Wu 
  Jason Voelz 
  Jian J Wang 
  Krzysztof Koch 
  Laszlo Ersek 
  Leif Lindholm 
  Li, Aaron 
  Liming Gao 
  Mateusz Albecki 
  Michael D Kinney 
  Michael Kubacki 
  Pavana.K 
  Philippe Mathieu-Daud? 
  Philippe Mathieu-Daude 
  Siyuan Fu 
  Siyuan, Fu 
  Sudipto Paul 
  Vitaly Cheptsov 
  Vitaly Cheptsov via Groups.Io 
  Wei6 Xu 
  Xu, Wei6 
  Zhiguang Liu 
  Zhiju.Fan 

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 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] [RFC XEN PATCH 00/23] xen: beginning support for RISC-V

[Bobby Eshleman]

On Sat, Jan 25, 2020 at 05:11:18PM +, Andrew Cooper wrote:
> On 25/01/2020 03:26, Bobby Eshleman wrote:
> > On Fri, Jan 24, 2020 at 01:41:38PM +, Andrew Cooper wrote:
> >> Other areas where you can reduce the minimum build would be to put some
> >> defaults into the defconfig, such as disabling grant tables and mem
> >> access.  There are almost certainly others which will help, so have a
> >> search around menuconfig.
> > Taking note of these, I can definitely do that.
> 
> To fore-warn you, there probably will be more things like this which
> become apparent on further review.
> 
> While I don't expect you to do all the cleanup (some will almost
> certainly be quicker for others to do), I would like to take the
> opportunity to do the obvious bits of cleanup, given the rare
> opportunity of seeing the minimum viable set of things to make a new
> arch compile.

This sounds very reasonable.

> This looks to be the same as what we've chosen to do in x86, give or
> take a fencepost.
> 
> I'd recommend using L{3..0} for similarity with the spec (you surely
> don't want an off-by-one difference between code in Xen and the spec). 
> Whatever you end up choosing, put a description at the top of mm.h (or
> wherever appropriate) which briefly introduces the terminology in Xen,
> and cross references any differences with the spec.

Roger that.

Thanks again for the feedback.

-Bobby

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

[Xen-devel] [linux-5.4 test] 146536: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 146121
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 
146121
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 
146121
 build-amd64-xsm   6 xen-buildfail REGR. vs. 146121

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10   fail REGR. vs. 146121
 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 146121

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  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-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 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-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-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail 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-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-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-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail 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-libvirt 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-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail 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-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 146526
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 146526
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 146526
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 146526
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail like 
146526
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 146526
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 146526
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 146526
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 146526
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 146526
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 146526
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  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-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 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-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   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  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  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-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-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  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-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  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-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass

version targeted for testing:
 xen  3c601c5f056fba055b7a1438b84b69fc649275c3
baseline version:
 xen  f190e634daba1a40570700b3e7697d497874c66f

Last test of basis   146526  2020-01-27 01:51:14 Z1 days
Testing same since   146534  2020-01-27 14:36:42 Z0 days1 attempts


People who touched revisions under test:
  Jeff Kubascik 
  Julien Grall 

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

[Xen-devel] [ovmf test] 146537: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 
145767

version targeted for testing:
 ovmf c8b8157e126ae2fb6f65842677251d300ceff104
baseline version:
 ovmf 70911f1f4aee0366b6122f2b90d367ec0f066beb

Last test of basis   145767  2020-01-08 00:39:09 Z   20 days
Failing since145774  2020-01-08 02:50:20 Z   19 days   75 attempts
Testing same since   146482  2020-01-24 19:39:39 Z3 days   14 attempts


People who touched revisions under test:
  Aaron Li 
  Albecki, Mateusz 
  Ard Biesheuvel 
  Ashish Singhal 
  Bob Feng 
  Brian R Haug 
  Eric Dong 
  Fan, ZhijuX 
  Hao A Wu 
  Jason Voelz 
  Jian J Wang 
  Krzysztof Koch 
  Laszlo Ersek 
  Leif Lindholm 
  Li, Aaron 
  Liming Gao 
  Mateusz Albecki 
  Michael D Kinney 
  Michael Kubacki 
  Pavana.K 
  Philippe Mathieu-Daud? 
  Philippe Mathieu-Daude 
  Siyuan Fu 
  Siyuan, Fu 
  Sudipto Paul 
  Vitaly Cheptsov 
  Vitaly Cheptsov via Groups.Io 
  Wei6 Xu 
  Xu, Wei6 
  Zhiguang Liu 
  Zhiju.Fan 

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 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



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

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

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

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


Not pushing.

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

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-seattle   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-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 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-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 

Re: [Xen-devel] Linux 5.5 fails to boot in VM

[Ilpo Järvinen]

On Mon, 27 Jan 2020, Boris Ostrovsky wrote:

> (Sorry, with proper addressing now)
> 
> On 1/27/20 6:29 PM, Boris Ostrovsky wrote:
> >
> >
> > On 1/27/20 4:37 PM, Marek Marczykowski-Górecki wrote:
> >>
>  Loading Linux 5.5.0-accecn30 ...
> 
>  .[5;22H  [ initrd.img-5.5.0-acc  16.52MiB  100%  10.23MiB/s 
>  ].[5;1HSetting up swapspace version 1, size = 1073737728 bytes
>  /dev/xvda3: clean, 852118/1294896 files, 3076785/5190907 blocks
>  [2.730931] BUG: kernel NULL pointer dereference, address: 
>  03b0
>  [2.730959] #PF: supervisor read access in kernel mode
>  [2.730966] #PF: error_code(0x) - not-present page
>  [2.730973] PGD 0 P4D 0
>  [2.730978] Oops:  [#1] SMP PTI
>  [2.730985] CPU: 1 PID: 402 Comm: qubesdb-daemon Tainted: G   
>  O  5.5.0-accecn30 #31
>  [2.731000] RIP: 0010:mmu_interval_read_begin+0x24/0xc0
> >
> >
> >
> >
> > This looks like it could well be
> > d3eeb1d77c5d0af9df442db63722928238310a86. Can you revert it and see if
> > it makes a difference?
> >
> > (+Jason)
> >
> > -boris
> >
> >
> >
> >
>  [2.731008] Code: e9 51 66 e1 ff 90 0f 1f 44 00 00 41 54 49 89 fc 55 
>  53 48 83 ec 30 65 48 8b 04 25 28 00 00 00 48 89 44 24 28 31 c0 48 8b 47 
>  38 <48> 8b a8 b0 03 00 00 48 8d 5d 0c 48 89 df e8 49 27 6f 00 4d 8b 64
>  [2.731030] RSP: 0018:9873001e7d20 EFLAGS: 00010246
>  [2.731037] RAX:  RBX: 8a4e94712500 RCX: 
>  
> 
> 
> 
> I am pretty sure it is.
> 
> RAX=0 most likely means that map->notifier is NULL (assuming your
> compiler generates code similar to mine).
> 
> I believe you at least need
> 
> 
> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> index 4fc83e3f..d35cf0b 100644
> --- a/drivers/xen/gntdev.c
> +++ b/drivers/xen/gntdev.c
> @@ -1016,7 +1016,8 @@ static int gntdev_mmap(struct file *flip, struct
> vm_area_struct *vma)
>  * and we are holding it now, there is no need for the
> notifier_range
>  * locking pattern.
>  */
> -   mmu_interval_read_begin(>notifier);
> +   if (use_ptemod)
> +   mmu_interval_read_begin(>notifier);
>  
>     if (use_ptemod) {
>     map->pages_vm_start = vma->vm_start;
> 
> 
> and maybe more.  Give that a try.

Thanks, I'll try to get these tested tomorrow evening.

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

Re: [Xen-devel] Linux 5.5 fails to boot in VM

[Boris Ostrovsky]

(Sorry, with proper addressing now)

On 1/27/20 6:29 PM, Boris Ostrovsky wrote:
>
>
> On 1/27/20 4:37 PM, Marek Marczykowski-Górecki wrote:
>>
 Loading Linux 5.5.0-accecn30 ...

 .[5;22H  [ initrd.img-5.5.0-acc  16.52MiB  100%  10.23MiB/s 
 ].[5;1HSetting up swapspace version 1, size = 1073737728 bytes
 /dev/xvda3: clean, 852118/1294896 files, 3076785/5190907 blocks
 [2.730931] BUG: kernel NULL pointer dereference, address: 
 03b0
 [2.730959] #PF: supervisor read access in kernel mode
 [2.730966] #PF: error_code(0x) - not-present page
 [2.730973] PGD 0 P4D 0
 [2.730978] Oops:  [#1] SMP PTI
 [2.730985] CPU: 1 PID: 402 Comm: qubesdb-daemon Tainted: G   O 
  5.5.0-accecn30 #31
 [2.731000] RIP: 0010:mmu_interval_read_begin+0x24/0xc0
>
>
>
>
> This looks like it could well be
> d3eeb1d77c5d0af9df442db63722928238310a86. Can you revert it and see if
> it makes a difference?
>
> (+Jason)
>
> -boris
>
>
>
>
 [2.731008] Code: e9 51 66 e1 ff 90 0f 1f 44 00 00 41 54 49 89 fc 55 53 
 48 83 ec 30 65 48 8b 04 25 28 00 00 00 48 89 44 24 28 31 c0 48 8b 47 38 
 <48> 8b a8 b0 03 00 00 48 8d 5d 0c 48 89 df e8 49 27 6f 00 4d 8b 64
 [2.731030] RSP: 0018:9873001e7d20 EFLAGS: 00010246
 [2.731037] RAX:  RBX: 8a4e94712500 RCX: 
 



I am pretty sure it is.

RAX=0 most likely means that map->notifier is NULL (assuming your
compiler generates code similar to mine).

I believe you at least need


diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 4fc83e3f..d35cf0b 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -1016,7 +1016,8 @@ static int gntdev_mmap(struct file *flip, struct
vm_area_struct *vma)
 * and we are holding it now, there is no need for the
notifier_range
 * locking pattern.
 */
-   mmu_interval_read_begin(>notifier);
+   if (use_ptemod)
+   mmu_interval_read_begin(>notifier);
 
    if (use_ptemod) {
    map->pages_vm_start = vma->vm_start;


and maybe more.  Give that a try.


-boris





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

Re: [Xen-devel] Linux 5.5 fails to boot in VM

[Boris Ostrovsky]

On 1/27/20 6:29 PM, Boris Ostrovsky wrote:
>
>
> On 1/27/20 4:37 PM, Marek Marczykowski-Górecki wrote:
>> On Mon, Jan 27, 2020 at 03:45:11PM +0100, Jürgen Groß wrote:
>>> On 27.01.20 14:16, Ilpo Järvinen wrote:
 Hi,

 I've noted that 5.5-rcs and now 5.5-based kernel fails to boot in VM.
 5.4 based kernels worked fine and there seems to have been some changes in
 drivers/xen post-5.4 so perhaps they broke something?
>>> I can't reproduce your problem. Just booted a VM with kernel 5.5 as
>>> PV- and as HVM-guest without any problems.
>> It looks like an issue with gntdev driver, so reproducing it require any
>> userspace that actually makes use of it. Any idea what recent change
>> could cause that?
>>
 Loading Linux 5.5.0-accecn30 ...

 .[5;22H  [ initrd.img-5.5.0-acc  16.52MiB  100%  10.23MiB/s 
 ].[5;1HSetting up swapspace version 1, size = 1073737728 bytes
 /dev/xvda3: clean, 852118/1294896 files, 3076785/5190907 blocks
 [2.730931] BUG: kernel NULL pointer dereference, address: 
 03b0
 [2.730959] #PF: supervisor read access in kernel mode
 [2.730966] #PF: error_code(0x) - not-present page
 [2.730973] PGD 0 P4D 0
 [2.730978] Oops:  [#1] SMP PTI
 [2.730985] CPU: 1 PID: 402 Comm: qubesdb-daemon Tainted: G   O 
  5.5.0-accecn30 #31
 [2.731000] RIP: 0010:mmu_interval_read_begin+0x24/0xc0
>
>
>
>
> This looks like it could well be
> d3eeb1d77c5d0af9df442db63722928238310a86. Can you revert it and see if
> it makes a difference?
>
> (+Jason)
>
> -boris
>
>
>
>
 [2.731008] Code: e9 51 66 e1 ff 90 0f 1f 44 00 00 41 54 49 89 fc 55 53 
 48 83 ec 30 65 48 8b 04 25 28 00 00 00 48 89 44 24 28 31 c0 48 8b 47 38 
 <48> 8b a8 b0 03 00 00 48 8d 5d 0c 48 89 df e8 49 27 6f 00 4d 8b 64
 [2.731030] RSP: 0018:9873001e7d20 EFLAGS: 00010246
 [2.731037] RAX:  RBX: 8a4e94712500 RCX: 
 


I am pretty sure it is.

RAX=0 most likely means that map->notifier is NULL (assuming your
compiler generates code similar to mine).

I believe you at least need


diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 4fc83e3f..d35cf0b 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -1016,7 +1016,8 @@ static int gntdev_mmap(struct file *flip, struct
vm_area_struct *vma)
 * and we are holding it now, there is no need for the
notifier_range
 * locking pattern.
 */
-   mmu_interval_read_begin(>notifier);
+   if (use_ptemod)
+   mmu_interval_read_begin(>notifier);
 
    if (use_ptemod) {
    map->pages_vm_start = vma->vm_start;


and maybe more.  Give that a try.


-boris


 [2.731047] RDX: 8a4ef53add00 RSI:  RDI: 
 8a4e94712500
 [2.731057] RBP: 8a4e0bf7a640 R08: 7bc5c0573000 R09: 
 0008
 [2.731066] R10: 8a4ec756c190 R11: 7bc5c05a2000 R12: 
 8a4e94712500
 [2.731076] R13: 8a4ed3ab9d50 R14:  R15: 
 0001
 [2.731086] FS:  7bc5c00dc7c0() GS:8a4ef5d0() 
 knlGS:
 [2.731097] CS:  0010 DS:  ES:  CR0: 80050033
 [2.731105] CR2: 03b0 CR3: 8148e004 CR4: 
 003606e0
 [2.731116] Call Trace:
 [2.731123]  ? vma_merge+0xef/0x370
 [2.731132]  gntdev_mmap+0x153/0x30e [xen_gntdev]
 [2.731139]  mmap_region+0x3d9/0x660
 [2.731146]  do_mmap+0x372/0x520
 [2.731153]  vm_mmap_pgoff+0xd2/0x120
 [2.731160]  ksys_mmap_pgoff+0x1b8/0x270
 [2.731167]  ? ksys_ioctl+0x60/0x90
 [2.731174]  do_syscall_64+0x5b/0x180
 [2.731182]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
 [2.731191] RIP: 0033:0x7bc5c03e8133
 [2.731196] Code: 54 41 89 d4 55 48 89 fd 53 4c 89 cb 48 85 ff 74 56 49 
 89 d9 45 89 f8 45 89 f2 44 89 e2 4c 89 ee 48 89 ef b8 09 00 00 00 0f 05 
 <48> 3d 00 f0 ff ff 77 7d 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 2e 0f
 [2.731219] RSP: 002b:7ffcbccc89b8 EFLAGS: 0246 ORIG_RAX: 
 0009
 [2.731230] RAX: ffda RBX:  RCX: 
 7bc5c03e8133
 [2.731243] RDX: 0003 RSI: 1000 RDI: 
 
 [2.731252] RBP:  R08: 0007 R09: 
 
 [2.731263] R10: 0001 R11: 0246 R12: 
 0003
 [2.731273] R13: 1000 R14: 0001 R15: 
 0007
 [2.731284] Modules linked in: xen_netback u2mfn(O) xen_gntdev 
 xen_gntalloc xen_blkback xen_evtchn parport_pc ppdev xenfs xen_privcmd lp 
 parport ip_tables xen_netfront xen_blkfront crc32c_intel
 [2.731309] CR2: 03b0
 [2.731315] fbcon: Taking 

Re: [Xen-devel] Linux 5.5 fails to boot in VM

[Boris Ostrovsky]

On 1/27/20 4:37 PM, Marek Marczykowski-Górecki wrote:
> On Mon, Jan 27, 2020 at 03:45:11PM +0100, Jürgen Groß wrote:
>> On 27.01.20 14:16, Ilpo Järvinen wrote:
>>> Hi,
>>>
>>> I've noted that 5.5-rcs and now 5.5-based kernel fails to boot in VM.
>>> 5.4 based kernels worked fine and there seems to have been some changes in
>>> drivers/xen post-5.4 so perhaps they broke something?
>> I can't reproduce your problem. Just booted a VM with kernel 5.5 as
>> PV- and as HVM-guest without any problems.
> It looks like an issue with gntdev driver, so reproducing it require any
> userspace that actually makes use of it. Any idea what recent change
> could cause that?
>
>>> Loading Linux 5.5.0-accecn30 ...
>>>
>>> .[5;22H  [ initrd.img-5.5.0-acc  16.52MiB  100%  10.23MiB/s 
>>> ].[5;1HSetting up swapspace version 1, size = 1073737728 bytes
>>> /dev/xvda3: clean, 852118/1294896 files, 3076785/5190907 blocks
>>> [2.730931] BUG: kernel NULL pointer dereference, address: 
>>> 03b0
>>> [2.730959] #PF: supervisor read access in kernel mode
>>> [2.730966] #PF: error_code(0x) - not-present page
>>> [2.730973] PGD 0 P4D 0
>>> [2.730978] Oops:  [#1] SMP PTI
>>> [2.730985] CPU: 1 PID: 402 Comm: qubesdb-daemon Tainted: G   O  
>>> 5.5.0-accecn30 #31
>>> [2.731000] RIP: 0010:mmu_interval_read_begin+0x24/0xc0




This looks like it could well be
d3eeb1d77c5d0af9df442db63722928238310a86. Can you revert it and see if
it makes a difference?

(+Jason)

-boris




>>> [2.731008] Code: e9 51 66 e1 ff 90 0f 1f 44 00 00 41 54 49 89 fc 55 53 
>>> 48 83 ec 30 65 48 8b 04 25 28 00 00 00 48 89 44 24 28 31 c0 48 8b 47 38 
>>> <48> 8b a8 b0 03 00 00 48 8d 5d 0c 48 89 df e8 49 27 6f 00 4d 8b 64
>>> [2.731030] RSP: 0018:9873001e7d20 EFLAGS: 00010246
>>> [2.731037] RAX:  RBX: 8a4e94712500 RCX: 
>>> 
>>> [2.731047] RDX: 8a4ef53add00 RSI:  RDI: 
>>> 8a4e94712500
>>> [2.731057] RBP: 8a4e0bf7a640 R08: 7bc5c0573000 R09: 
>>> 0008
>>> [2.731066] R10: 8a4ec756c190 R11: 7bc5c05a2000 R12: 
>>> 8a4e94712500
>>> [2.731076] R13: 8a4ed3ab9d50 R14:  R15: 
>>> 0001
>>> [2.731086] FS:  7bc5c00dc7c0() GS:8a4ef5d0() 
>>> knlGS:
>>> [2.731097] CS:  0010 DS:  ES:  CR0: 80050033
>>> [2.731105] CR2: 03b0 CR3: 8148e004 CR4: 
>>> 003606e0
>>> [2.731116] Call Trace:
>>> [2.731123]  ? vma_merge+0xef/0x370
>>> [2.731132]  gntdev_mmap+0x153/0x30e [xen_gntdev]
>>> [2.731139]  mmap_region+0x3d9/0x660
>>> [2.731146]  do_mmap+0x372/0x520
>>> [2.731153]  vm_mmap_pgoff+0xd2/0x120
>>> [2.731160]  ksys_mmap_pgoff+0x1b8/0x270
>>> [2.731167]  ? ksys_ioctl+0x60/0x90
>>> [2.731174]  do_syscall_64+0x5b/0x180
>>> [2.731182]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
>>> [2.731191] RIP: 0033:0x7bc5c03e8133
>>> [2.731196] Code: 54 41 89 d4 55 48 89 fd 53 4c 89 cb 48 85 ff 74 56 49 
>>> 89 d9 45 89 f8 45 89 f2 44 89 e2 4c 89 ee 48 89 ef b8 09 00 00 00 0f 05 
>>> <48> 3d 00 f0 ff ff 77 7d 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 2e 0f
>>> [2.731219] RSP: 002b:7ffcbccc89b8 EFLAGS: 0246 ORIG_RAX: 
>>> 0009
>>> [2.731230] RAX: ffda RBX:  RCX: 
>>> 7bc5c03e8133
>>> [2.731243] RDX: 0003 RSI: 1000 RDI: 
>>> 
>>> [2.731252] RBP:  R08: 0007 R09: 
>>> 
>>> [2.731263] R10: 0001 R11: 0246 R12: 
>>> 0003
>>> [2.731273] R13: 1000 R14: 0001 R15: 
>>> 0007
>>> [2.731284] Modules linked in: xen_netback u2mfn(O) xen_gntdev 
>>> xen_gntalloc xen_blkback xen_evtchn parport_pc ppdev xenfs xen_privcmd lp 
>>> parport ip_tables xen_netfront xen_blkfront crc32c_intel
>>> [2.731309] CR2: 03b0
>>> [2.731315] fbcon: Taking over console
>>> [2.731321] ---[ end trace 5ec57aa3f3a40247 ]---
>>> [2.731329] RIP: 0010:mmu_interval_read_begin+0x24/0xc0
>>> [2.731336] Code: e9 51 66 e1 ff 90 0f 1f 44 00 00 41 54 49 89 fc 55 53 
>>> 48 83 ec 30 65 48 8b 04 25 28 00 00 00 48 89 44 24 28 31 c0 48 8b 47 38 
>>> <48> 8b a8 b0 03 00 00 48 8d 5d 0c 48 89 df e8 49 27 6f 00 4d 8b 64
>>> [2.731358] RSP: 0018:9873001e7d20 EFLAGS: 00010246
>>> [2.731365] RAX:  RBX: 8a4e94712500 RCX: 
>>> 
>>> [2.731375] RDX: 8a4ef53add00 RSI:  RDI: 
>>> 8a4e94712500
>>> [2.731385] RBP: 8a4e0bf7a640 R08: 7bc5c0573000 R09: 
>>> 0008
>>> [2.731395] R10: 8a4ec756c190 R11: 7bc5c05a2000 R12: 
>>> 8a4e94712500
>>> [2.731405] R13: 8a4ed3ab9d50 R14:  R15: 
>>> 0001
>>> [2.731415] FS:  

Re: [Xen-devel] Linux 5.5 fails to boot in VM

[Ilpo Järvinen]

On Mon, 27 Jan 2020, Marek Marczykowski-Górecki wrote:

> On Mon, Jan 27, 2020 at 03:45:11PM +0100, Jürgen Groß wrote:
> > On 27.01.20 14:16, Ilpo Järvinen wrote:
> > > Hi,
> > > 
> > > I've noted that 5.5-rcs and now 5.5-based kernel fails to boot in VM.
> > > 5.4 based kernels worked fine and there seems to have been some changes in
> > > drivers/xen post-5.4 so perhaps they broke something?
> > 
> > I can't reproduce your problem. Just booted a VM with kernel 5.5 as
> > PV- and as HVM-guest without any problems.
> 
> It looks like an issue with gntdev driver, so reproducing it require any
> userspace that actually makes use of it.

I don't know enough about gntdev to understand what would use it.

> Any idea what recent change could cause that?

This is just my debian-10 based AppVM booting up. There's nothing special 
in it I can think of besides the fact I've compiled the kernels myself 
(and have some TCP related changes in the kernel, the same which work very 
fine on 5.4; but the crash occurs so early into the boot I don't think TCP 
even comes into the equation yet).

I can of course compile a kernel without any of my mods if necessary 
and even try to bisect the problem if need be but any hint or idea which 
way I should look would certainly help in that effort.


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

Re: [Xen-devel] Linux 5.5 fails to boot in VM

[Marek Marczykowski-Górecki]

On Mon, Jan 27, 2020 at 03:45:11PM +0100, Jürgen Groß wrote:
> On 27.01.20 14:16, Ilpo Järvinen wrote:
> > Hi,
> > 
> > I've noted that 5.5-rcs and now 5.5-based kernel fails to boot in VM.
> > 5.4 based kernels worked fine and there seems to have been some changes in
> > drivers/xen post-5.4 so perhaps they broke something?
> 
> I can't reproduce your problem. Just booted a VM with kernel 5.5 as
> PV- and as HVM-guest without any problems.

It looks like an issue with gntdev driver, so reproducing it require any
userspace that actually makes use of it. Any idea what recent change
could cause that?

> > Loading Linux 5.5.0-accecn30 ...
> > 
> > .[5;22H  [ initrd.img-5.5.0-acc  16.52MiB  100%  10.23MiB/s 
> > ].[5;1HSetting up swapspace version 1, size = 1073737728 bytes
> > /dev/xvda3: clean, 852118/1294896 files, 3076785/5190907 blocks
> > [2.730931] BUG: kernel NULL pointer dereference, address: 
> > 03b0
> > [2.730959] #PF: supervisor read access in kernel mode
> > [2.730966] #PF: error_code(0x) - not-present page
> > [2.730973] PGD 0 P4D 0
> > [2.730978] Oops:  [#1] SMP PTI
> > [2.730985] CPU: 1 PID: 402 Comm: qubesdb-daemon Tainted: G   O  
> > 5.5.0-accecn30 #31
> > [2.731000] RIP: 0010:mmu_interval_read_begin+0x24/0xc0
> > [2.731008] Code: e9 51 66 e1 ff 90 0f 1f 44 00 00 41 54 49 89 fc 55 53 
> > 48 83 ec 30 65 48 8b 04 25 28 00 00 00 48 89 44 24 28 31 c0 48 8b 47 38 
> > <48> 8b a8 b0 03 00 00 48 8d 5d 0c 48 89 df e8 49 27 6f 00 4d 8b 64
> > [2.731030] RSP: 0018:9873001e7d20 EFLAGS: 00010246
> > [2.731037] RAX:  RBX: 8a4e94712500 RCX: 
> > 
> > [2.731047] RDX: 8a4ef53add00 RSI:  RDI: 
> > 8a4e94712500
> > [2.731057] RBP: 8a4e0bf7a640 R08: 7bc5c0573000 R09: 
> > 0008
> > [2.731066] R10: 8a4ec756c190 R11: 7bc5c05a2000 R12: 
> > 8a4e94712500
> > [2.731076] R13: 8a4ed3ab9d50 R14:  R15: 
> > 0001
> > [2.731086] FS:  7bc5c00dc7c0() GS:8a4ef5d0() 
> > knlGS:
> > [2.731097] CS:  0010 DS:  ES:  CR0: 80050033
> > [2.731105] CR2: 03b0 CR3: 8148e004 CR4: 
> > 003606e0
> > [2.731116] Call Trace:
> > [2.731123]  ? vma_merge+0xef/0x370
> > [2.731132]  gntdev_mmap+0x153/0x30e [xen_gntdev]
> > [2.731139]  mmap_region+0x3d9/0x660
> > [2.731146]  do_mmap+0x372/0x520
> > [2.731153]  vm_mmap_pgoff+0xd2/0x120
> > [2.731160]  ksys_mmap_pgoff+0x1b8/0x270
> > [2.731167]  ? ksys_ioctl+0x60/0x90
> > [2.731174]  do_syscall_64+0x5b/0x180
> > [2.731182]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > [2.731191] RIP: 0033:0x7bc5c03e8133
> > [2.731196] Code: 54 41 89 d4 55 48 89 fd 53 4c 89 cb 48 85 ff 74 56 49 
> > 89 d9 45 89 f8 45 89 f2 44 89 e2 4c 89 ee 48 89 ef b8 09 00 00 00 0f 05 
> > <48> 3d 00 f0 ff ff 77 7d 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 2e 0f
> > [2.731219] RSP: 002b:7ffcbccc89b8 EFLAGS: 0246 ORIG_RAX: 
> > 0009
> > [2.731230] RAX: ffda RBX:  RCX: 
> > 7bc5c03e8133
> > [2.731243] RDX: 0003 RSI: 1000 RDI: 
> > 
> > [2.731252] RBP:  R08: 0007 R09: 
> > 
> > [2.731263] R10: 0001 R11: 0246 R12: 
> > 0003
> > [2.731273] R13: 1000 R14: 0001 R15: 
> > 0007
> > [2.731284] Modules linked in: xen_netback u2mfn(O) xen_gntdev 
> > xen_gntalloc xen_blkback xen_evtchn parport_pc ppdev xenfs xen_privcmd lp 
> > parport ip_tables xen_netfront xen_blkfront crc32c_intel
> > [2.731309] CR2: 03b0
> > [2.731315] fbcon: Taking over console
> > [2.731321] ---[ end trace 5ec57aa3f3a40247 ]---
> > [2.731329] RIP: 0010:mmu_interval_read_begin+0x24/0xc0
> > [2.731336] Code: e9 51 66 e1 ff 90 0f 1f 44 00 00 41 54 49 89 fc 55 53 
> > 48 83 ec 30 65 48 8b 04 25 28 00 00 00 48 89 44 24 28 31 c0 48 8b 47 38 
> > <48> 8b a8 b0 03 00 00 48 8d 5d 0c 48 89 df e8 49 27 6f 00 4d 8b 64
> > [2.731358] RSP: 0018:9873001e7d20 EFLAGS: 00010246
> > [2.731365] RAX:  RBX: 8a4e94712500 RCX: 
> > 
> > [2.731375] RDX: 8a4ef53add00 RSI:  RDI: 
> > 8a4e94712500
> > [2.731385] RBP: 8a4e0bf7a640 R08: 7bc5c0573000 R09: 
> > 0008
> > [2.731395] R10: 8a4ec756c190 R11: 7bc5c05a2000 R12: 
> > 8a4e94712500
> > [2.731405] R13: 8a4ed3ab9d50 R14:  R15: 
> > 0001
> > [2.731415] FS:  7bc5c00dc7c0() GS:8a4ef5d0() 
> > knlGS:
> > [2.731427] CS:  0010 DS:  ES:  CR0: 80050033
> > [2.731436] CR2: 03b0 CR3: 8148e004 CR4: 
> > 

[Xen-devel] [PATCH] x86/suspend: disable watchdog before calling console_start_sync()

[Igor Druzhinin]

... and enable it after exiting S-state. Otherwise accumulated
output in serial buffer might easily trigger the watchdog if it's
still enabled after entering sync transmission mode.

The issue observed on machines which, unfortunately, generate non-0
output in CPU offline callbacks.

Signed-off-by: Igor Druzhinin 
---
 xen/arch/x86/acpi/power.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index 8078352..62384a4 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -223,6 +224,7 @@ static int enter_state(u32 state)
 
 acpi_sleep_prepare(state);
 
+watchdog_disable();
 console_start_sync();
 printk("Entering ACPI S%d state.\n", state);
 
@@ -281,6 +283,7 @@ static int enter_state(u32 state)
 tboot_s3_error(error);
 
 console_end_sync();
+watchdog_enable();
 
 microcode_update_one(true);
 
-- 
2.7.4


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

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

[osstest service owner]

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

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  0b70b2ff8f5a61196d090cc70040a20178327347
baseline version:
 xen  1a3673da64822f52b50a3048dd7c5616573a9cd8

Last test of basis   146535  2020-01-27 15:00:43 Z0 days
Testing same since   146539  2020-01-27 18:00:52 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  George Dunlap 
  Ian Jackson 
  Paul Durrant 

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-amd64pass
 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
   1a3673da64..0b70b2ff8f  0b70b2ff8f5a61196d090cc70040a20178327347 -> smoke

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

Re: [Xen-devel] HVM Driver Domain

[tosher 1]

Rojer,

> You can also start xl devd manually, as that will give you verbose
> output of whats going on. In the driver domain:

> # killall xl
> # xl -vvv devd -F

> That should give you detailed output of what's going on in the driver
> domain, can you paste the output you get from the driver domain when
> you try to start the failed guest?

I ran both commands in the driver domain. Before starting the domU, I get the 
following verbose.

# sudo xl -vvv devd -F
libxl: debug: libxl_device.c:1733:libxl_device_events_handler: Domain 0:ao 
0x556e3e940ef0: create: how=(nil) callback=(nil) poller=0x556e3e940c10
libxl: debug: libxl_event.c:636:libxl__ev_xswatch_register: watch 
w=0x7ffca33549d8 wpath=/local/domain/0/backend token=3/0: register slotnum=3
libxl: debug: libxl_device.c:1790:libxl_device_events_handler: Domain 0:ao 
0x556e3e940ef0: inprogress: poller=0x556e3e940c10, flags=i
libxl: debug: libxl_event.c:573:watchfd_callback: watch w=0x7ffca33549d8 
wpath=/local/domain/0/backend token=3/0: event epath=/local/domain/0/backend
libxl: debug: libxl_event.c:2227:libxl__nested_ao_create: ao 0x556e3e940600: 
nested ao, parent 0x556e3e940ef0
libxl: debug: libxl_event.c:1838:libxl__ao__destroy: ao 0x556e3e940600: destroy

I know this is not exactly what you asked for. Unfortunately, I don't see any 
other verbose when try to start DomU. The error messages I get from the failed 
DomU launch is as the following, where driver domain id is 7.

libxl: error: libxl_device.c:1075:device_backend_callback: Domain 8:unable to 
add device with path /local/domain/7/backend/vif/8/0
libxl: error: libxl_create.c:1458:domcreate_attach_devices: Domain 8:unable to 
add nic devices
libxl: error: libxl_device.c:1075:device_backend_callback: Domain 8:unable to 
remove device with path /local/domain/7/backend/vif/8/0
libxl: error: libxl_domain.c:1075:devices_destroy_cb: Domain 
8:libxl__devices_destroy failed
libxl: error: libxl_domain.c:1003:libxl__destroy_domid: Domain 8:Non-existant 
domain
libxl: error: libxl_domain.c:962:domain_destroy_callback: Domain 8:Unable to 
destroy guest
libxl: error: libxl_domain.c:889:domain_destroy_cb: Domain 8:Destruction of 
domain failed


On the other hand, if I run devd in Dom0, I get a lot of verbose when I try to 
launch DomU, dependent on Driver Domain for networking. I am not sure if I 
should paste it here. Please let me know what you think.

Thanks,
Mehrab


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

[Xen-devel] [PATCH RFC] x86/amd: Avoid cpu_has_hypervisor evaluating true on native hardware

[Andrew Cooper]

Currently when booting native on AMD hardware, cpuidmask_defaults._1cd gets
configured with the HYPERVISOR bit before native CPUID is scanned for feature
bits.

This results in cpu_has_hypervisor becoming set as part of identify_cpu(), and
ends up appearing in the raw and host CPU policies.  Nothing has really cared
in the past.

Alter amd_init_levelling() to exclude the HYPERVISOR bit from
cpumask_defaults, and update domain_cpu_policy_changed() to allow it to be
explicitly forwarded.

This in turn highlighted that dom0 construction was asymetric with domU
construction, by not having any calls to domain_cpu_policy_changed().  Extend
arch_domain_create() to always call domain_cpu_policy_changed().

Reported-by: Igor Druzhinin 
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Igor Druzhinin 

Without this fix, there is apparently a problem with Roger's "[PATCH v3 7/7]
x86/tlb: use Xen L0 assisted TLB flush when available" on native AMD hardware.
I haven't investgiated the issue with that patch specifically, because
cpu_has_hypervisor being wrong is obviously a bug.

This is one of two possible approaches, and both have their downsides.  This
one takes an extra hit on context switches between PV vcpus and idle/hvm, as
they will usually differ in HYPERVISOR bit.

The other approach is to order things more carefully so levelling is
configured after scanning for cpuid bits, but that has the downside that it is
very easy to regress.

Thoughts on which is the least-bad approach to take?  Having written this
patch, I'm now erring on the side of doing it the other way.
---
 xen/arch/x86/cpu/amd.c   | 3 ---
 xen/arch/x86/domain.c| 2 ++
 xen/arch/x86/domctl.c| 9 -
 xen/include/asm-x86/domain.h | 2 ++
 4 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 8b5f0f2e4c..0906b23582 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -297,9 +297,6 @@ static void __init noinline amd_init_levelling(void)
ecx |= cpufeat_mask(X86_FEATURE_OSXSAVE);
edx |= cpufeat_mask(X86_FEATURE_APIC);
 
-   /* Allow the HYPERVISOR bit to be set via guest policy. */
-   ecx |= cpufeat_mask(X86_FEATURE_HYPERVISOR);
-
cpuidmask_defaults._1cd = ((uint64_t)ecx << 32) | edx;
}
 
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 28fefa1f81..316b801597 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -665,6 +665,8 @@ int arch_domain_create(struct domain *d,
  */
 d->arch.x87_fip_width = cpu_has_fpu_sel ? 0 : 8;
 
+domain_cpu_policy_changed(d);
+
 return 0;
 
  fail:
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 5ed63ac10a..0627eb4e06 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -48,7 +48,7 @@ static int gdbsx_guest_mem_io(domid_t domid, struct 
xen_domctl_gdbsx_memio *iop)
 }
 #endif
 
-static void domain_cpu_policy_changed(struct domain *d)
+void domain_cpu_policy_changed(struct domain *d)
 {
 const struct cpuid_policy *p = d->arch.cpuid;
 struct vcpu *v;
@@ -106,6 +106,13 @@ static void domain_cpu_policy_changed(struct domain *d)
 ecx = 0;
 edx = cpufeat_mask(X86_FEATURE_APIC);
 
+/*
+ * If the Hypervisor bit is set in the policy, we can also
+ * forward it into real CPUID.
+ */
+if ( p->basic.hypervisor )
+ecx |= cpufeat_mask(X86_FEATURE_HYPERVISOR);
+
 mask |= ((uint64_t)ecx << 32) | edx;
 break;
 }
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index a3ae5d9a20..817065bf81 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -624,6 +624,8 @@ struct guest_memory_policy
 void update_guest_memory_policy(struct vcpu *v,
 struct guest_memory_policy *policy);
 
+void domain_cpu_policy_changed(struct domain *d);
+
 bool update_runstate_area(struct vcpu *);
 bool update_secondary_system_time(struct vcpu *,
   struct vcpu_time_info *);
-- 
2.11.0


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

Re: [Xen-devel] [Vote] Approve hypervisor project check-in policy

[Wei Liu]

On Mon, Jan 27, 2020 at 03:27:40PM +0100, Jan Beulich wrote:
> On 27.01.2020 15:12, George Dunlap wrote:
> > I have drafted an explicit policy on what is (generally) required to
> > check a patch in.  It's been through several rounds, and v4 has been
> > acked [1].
> > 
> > I've had informal assent from all committers, but just to dot all our
> > i's and cross all our t's, it's probably worth having a vote of the
> > committers, in line with the XenProject governance policy [1].
> > 
> > Please respond by 10 February with your vote:
> > +1: for proposal
> > -1: against proposal
> > in public or private.
> 
> +1
> 
> As an aside, I notice you may want to update your address book. I've
> corrected Wei's and Julien's email addresses.

Thanks.

+1 to this proposal.

Wei.

> 
> Jan

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

Re: [Xen-devel] [PATCH v1 2/4] x86/microcode: Improve parsing for ucode=

[Eslam Elnikety]

Thanks for getting the other patches in the series onto master, Jan.

This is the only patch out of this series that did not make it through, 
so I keeping my comments here.


On 23.01.20 11:26, Jan Beulich wrote:

On 22.01.2020 23:30, Eslam Elnikety wrote:

Decouple the microcode indexing mechanism when using GRUB to that
when using EFI. This allows us to avoid the "unspecified effect" of
using `` when booting via EFI.


Personally I'd prefer us to continue call this unspecified. It
simply shouldn't be used. People shouldn't rely on it getting
ignored. (Iirc, despite this being v1, you had previously
submitted a patch to this effect, with me replaying about the
same.)


With that, Xen can explicitly ignore that option when using EFI.


Don't we do so already, by way of the "if ( !ucode_mod_forced )"
you delete?



Not quite. If cfg.efi does not specify "ucode=", then a 
`ucode=` from the commandline gets parsed, resulting in the 
"unspecified" behaviour. Here, the ucode_mod_idx will hold the  
which will be used as index into the modules prepared in whatever order 
the efi/boot.c defines.


In any case, let me know (and others too) if, later on, you may want to 
favor the explicitly ignore (opposed to unspecified) semantic and I will 
be happy to send another revision of this patch while addressing your 
comment below.



--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -2147,9 +2147,9 @@ for updating CPU micrcode. When negative, counting starts 
at the end of
  the modules in the GrUB entry (so with the blob commonly being last,
  one could specify `ucode=-1`). Note that the value of zero is not valid
  here (entry zero, i.e. the first module, is always the Dom0 kernel
-image). Note further that use of this option has an unspecified effect
-when used with xen.efi (there the concept of modules doesn't exist, and
-the blob gets specified via the `ucode=` config file/section
+image). This option should be used only with legacy boot, as it is explicitly
+ignored in EFI boot. When booting via EFI, the microcode update blob for
+early loading can be specified via the `ucode=` config file/section
  entry; see [EFI configuration file description](efi.html)).


Just like in patch 1, please distinguish "EFI boot" in general from
"use of xen.efi" (relevant here of course only if indeed we went
with this patch).

Jan

You have mentioned this very same remark on the other patch too. My 
understanding is that "EFI boot" may be ambiguous between (a) we are 
actually booting from xen.efi or (b) a system with EFI support (and the 
latter may still be falling onto grub for booting). Let me know if 
that's not actually what your remark is about.


Cheers,
Eslam

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

[Xen-devel] [PATCH] RCU: reimplement RCU barrier to avoid deadlock

[Igor Druzhinin]

The existing RCU barrier implementation is prone to a deadlock scenario
due to IRQs being re-enabled inside stopmachine context. If due to a race
IRQs are re-enabled on some of CPUs and softirqs are allowed to be
processed in stopmachine, i.e. what currently happens in rcu_barrier(),
timer interrupt is able to invoke TSC synchronization rendezvous.
At this moment sending TSC synchronization IPI will stall waiting for
other CPUs to synchronize while they in turn are waiting in stopmachine
busy loop with IRQs disabled.

To avoid the scenario above - reimplement rcu_barrier() in a way where
IRQs are not being disabled at any moment. The proposed implementation
is just a simplified and specialized version of stopmachine. The semantic
of the call is preserved.

Signed-off-by: Igor Druzhinin 
---
This change has been stress tested by doing actions invoking rcu_barrier()
functionality and didn't show any issues.
---
 xen/common/rcupdate.c | 36 ++--
 1 file changed, 26 insertions(+), 10 deletions(-)

diff --git a/xen/common/rcupdate.c b/xen/common/rcupdate.c
index cb712c8..95a1f85 100644
--- a/xen/common/rcupdate.c
+++ b/xen/common/rcupdate.c
@@ -145,6 +145,9 @@ struct rcu_barrier_data {
 atomic_t *cpu_count;
 };
 
+static DEFINE_PER_CPU(struct tasklet, rcu_barrier_tasklet);
+static atomic_t rcu_barrier_cpu_count, rcu_barrier_cpu_done;
+
 static void rcu_barrier_callback(struct rcu_head *head)
 {
 struct rcu_barrier_data *data = container_of(
@@ -152,12 +155,9 @@ static void rcu_barrier_callback(struct rcu_head *head)
 atomic_inc(data->cpu_count);
 }
 
-static int rcu_barrier_action(void *_cpu_count)
+static void rcu_barrier_action(void *unused)
 {
-struct rcu_barrier_data data = { .cpu_count = _cpu_count };
-
-ASSERT(!local_irq_is_enabled());
-local_irq_enable();
+struct rcu_barrier_data data = { .cpu_count = _barrier_cpu_count };
 
 /*
  * When callback is executed, all previously-queued RCU work on this CPU
@@ -172,15 +172,30 @@ static int rcu_barrier_action(void *_cpu_count)
 cpu_relax();
 }
 
-local_irq_disable();
-
-return 0;
+atomic_inc(_barrier_cpu_done);
 }
 
 int rcu_barrier(void)
 {
-atomic_t cpu_count = ATOMIC_INIT(0);
-return stop_machine_run(rcu_barrier_action, _count, NR_CPUS);
+unsigned int i;
+
+if ( !get_cpu_maps() )
+return -EBUSY;
+
+atomic_set(_barrier_cpu_count, 0);
+atomic_set(_barrier_cpu_done, 0);
+
+for_each_online_cpu ( i )
+if ( i != smp_processor_id() )
+tasklet_schedule_on_cpu(_cpu(rcu_barrier_tasklet, i), i);
+
+rcu_barrier_action(NULL);
+
+while ( atomic_read(_barrier_cpu_done) != num_online_cpus() )
+cpu_relax();
+
+put_cpu_maps();
+return 0;
 }
 
 /* Is batch a before batch b ? */
@@ -564,6 +579,7 @@ static void rcu_init_percpu_data(int cpu, struct 
rcu_ctrlblk *rcp,
 rdp->cpu = cpu;
 rdp->blimit = blimit;
 init_timer(>idle_timer, rcu_idle_timer_handler, rdp, cpu);
+tasklet_init(_cpu(rcu_barrier_tasklet, cpu), rcu_barrier_action, NULL);
 }
 
 static int cpu_callback(
-- 
2.7.4


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

Re: [Xen-devel] [PATCH v4 01/15] drm: Initialize struct drm_crtc_state.no_vblank from device settings

[Thomas Zimmermann]

Hi Emil

Am 27.01.20 um 19:12 schrieb Emil Velikov:
> Hi Thomas,
> 
> On Thu, 23 Jan 2020 at 09:21, Thomas Zimmermann  wrote:
> 
>> @@ -174,12 +174,22 @@ struct drm_crtc_state {
>>  * @no_vblank:
>>  *
>>  * Reflects the ability of a CRTC to send VBLANK events. This state
>> -* usually depends on the pipeline configuration, and the main usuage
>> -* is CRTCs feeding a writeback connector operating in oneshot mode.
>> -* In this case the VBLANK event is only generated when a job is 
>> queued
>> -* to the writeback connector, and we want the core to fake VBLANK
>> -* events when this part of the pipeline hasn't changed but others 
>> had
>> -* or when the CRTC and connectors are being disabled.
>> +* usually depends on the pipeline configuration. If set to true, DRM
>> +* atomic helpers will sendout a fake VBLANK event during display
>> +* updates.
>> +*
>> +* One usage is for drivers and/or hardware without support for 
>> VBLANK
>> +* interrupts. Such drivers typically do not initialize vblanking
>> +* (i.e., call drm_vblank_init() wit the number of CRTCs). For CRTCs
>> +* without initialized vblanking, the field is initialized to true 
>> and
>> +* a VBLANK event will be send out on each update of the display
>> +* pipeline.
>> +*
>> +* Another usage is CRTCs feeding a writeback connector operating in
>> +* oneshot mode. In this case the VBLANK event is only generated when
>> +* a job is queued to the writeback connector, and we want the core
>> +* to fake VBLANK events when this part of the pipeline hasn't 
>> changed
>> +* but others had or when the CRTC and connectors are being disabled.
>>  *
> 
> Perhaps it's just me, yet the following ideas would make the topic
> significantly easier and clearer.
> 
>  - adding explicit "fake" when talking about drm/atomic _helpers_
> generating/sending a VBLANK event.
> For example, in 15/15 the commit message says "fake", while inline
> comment omits it... Leading to the confusion pointed out.

No problem on being more precise here. I'll update the docs accordingly.

> 
> - s/no_vblank/fake_vblank/g or s/no_vblank/no_hw_vblank/g
> Simple and concise. With slight inclination towards the former wording :-)

I'd prefer to not change the field's name. The current name 'no_vblank'
indicates state and lets helpers decide what to do with it. The name
'fake_vblank' indicates an instruction to the helpers, telling them what
to do. It does neither seem to fit into drm_crtc_state, nor into the
overall concept.

Best regards
Thomas

> 
> If you and Daniel agree with the rename, then the first sentence of
> the description should probably be tweaked.
> 
> HTH
> Emil
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



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

[Xen-devel] [PATCH v6 3/9] xen/x86: Make hap_get_allocation accessible

[Tamas K Lengyel]

During VM forking we'll copy the parent domain's parameters to the client,
including the HAP shadow memory setting that is used for storing the domain's
EPT. We'll copy this in the hypervisor instead doing it during toolstack launch
to allow the domain to start executing and unsharing memory before (or
even completely without) the toolstack.

Signed-off-by: Tamas K Lengyel 
---
 xen/arch/x86/mm/hap/hap.c | 3 +--
 xen/include/asm-x86/hap.h | 1 +
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 3d93f3451c..c7c7ff6e99 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -321,8 +321,7 @@ static void hap_free_p2m_page(struct domain *d, struct 
page_info *pg)
 }
 
 /* Return the size of the pool, rounded up to the nearest MB */
-static unsigned int
-hap_get_allocation(struct domain *d)
+unsigned int hap_get_allocation(struct domain *d)
 {
 unsigned int pg = d->arch.paging.hap.total_pages
 + d->arch.paging.hap.p2m_pages;
diff --git a/xen/include/asm-x86/hap.h b/xen/include/asm-x86/hap.h
index b94bfb4ed0..1bf07e49fe 100644
--- a/xen/include/asm-x86/hap.h
+++ b/xen/include/asm-x86/hap.h
@@ -45,6 +45,7 @@ int   hap_track_dirty_vram(struct domain *d,
 
 extern const struct paging_mode *hap_paging_get_mode(struct vcpu *);
 int hap_set_allocation(struct domain *d, unsigned int pages, bool *preempted);
+unsigned int hap_get_allocation(struct domain *d);
 
 #endif /* XEN_HAP_H */
 
-- 
2.20.1


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

[Xen-devel] [PATCH v6 6/9] xen/mem_sharing: VM forking

[Tamas K Lengyel]

VM forking is the process of creating a domain with an empty memory space and a
parent domain specified from which to populate the memory when necessary. For
the new domain to be functional the VM state is copied over as part of the fork
operation (HVM params, hap allocation, etc).

Signed-off-by: Tamas K Lengyel 
---
v6: use get_domain/put_domain on parent to make sure it's not destroyed
---
 xen/arch/x86/domain.c |  11 ++
 xen/arch/x86/hvm/hvm.c|   2 +-
 xen/arch/x86/mm/mem_sharing.c | 222 ++
 xen/arch/x86/mm/p2m.c |  11 +-
 xen/include/asm-x86/mem_sharing.h |  20 ++-
 xen/include/public/memory.h   |   5 +
 xen/include/xen/sched.h   |   2 +
 7 files changed, 269 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 28fefa1f81..60d110c08f 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2198,6 +2198,17 @@ int domain_relinquish_resources(struct domain *d)
 ret = relinquish_shared_pages(d);
 if ( ret )
 return ret;
+
+/*
+ * If the domain is forked, decrement the parent's pause count
+ * and release the domain.
+ */
+if ( d->parent )
+{
+domain_unpause(d->parent);
+put_domain(d->parent);
+d->parent = NULL;
+}
 }
 #endif
 
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 0505c75661..dffab7e899 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1911,7 +1911,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long 
gla,
 }
 #endif
 
-/* Spurious fault? PoD and log-dirty also take this path. */
+/* Spurious fault? PoD, log-dirty and VM forking also take this path. */
 if ( p2m_is_ram(p2mt) )
 {
 rc = 1;
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 52b139c1bb..b6be78486d 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -22,6 +22,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -36,6 +37,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 
 #include "mm-locks.h"
@@ -1421,6 +1425,194 @@ static inline int mem_sharing_control(struct domain *d, 
bool enable)
 return 0;
 }
 
+/*
+ * Forking a page only gets called when the VM faults due to no entry being
+ * in the EPT for the access. Depending on the type of access we either
+ * populate the physmap with a shared entry for read-only access or
+ * fork the page if its a write access.
+ *
+ * The client p2m is already locked so we only need to lock
+ * the parent's here.
+ */
+int mem_sharing_fork_page(struct domain *d, gfn_t gfn, bool unsharing)
+{
+int rc = -ENOENT;
+shr_handle_t handle;
+struct domain *parent;
+struct p2m_domain *p2m;
+unsigned long gfn_l = gfn_x(gfn);
+mfn_t mfn, new_mfn;
+p2m_type_t p2mt;
+struct page_info *page;
+
+if ( !mem_sharing_is_fork(d) )
+return -ENOENT;
+
+parent = d->parent;
+
+if ( !unsharing )
+{
+/* For read-only accesses we just add a shared entry to the physmap */
+while ( parent )
+{
+if ( !(rc = nominate_page(parent, gfn, 0, )) )
+break;
+
+parent = parent->parent;
+}
+
+if ( !rc )
+{
+/* The client's p2m is already locked */
+struct p2m_domain *pp2m = p2m_get_hostp2m(parent);
+
+p2m_lock(pp2m);
+rc = add_to_physmap(parent, gfn_l, handle, d, gfn_l, false);
+p2m_unlock(pp2m);
+
+if ( !rc )
+return 0;
+}
+}
+
+/*
+ * If it's a write access (ie. unsharing) or if adding a shared entry to
+ * the physmap failed we'll fork the page directly.
+ */
+p2m = p2m_get_hostp2m(d);
+parent = d->parent;
+
+while ( parent )
+{
+mfn = get_gfn_query(parent, gfn_l, );
+
+if ( mfn_valid(mfn) && p2m_is_any_ram(p2mt) )
+break;
+
+put_gfn(parent, gfn_l);
+parent = parent->parent;
+}
+
+if ( !parent )
+return -ENOENT;
+
+if ( !(page = alloc_domheap_page(d, 0)) )
+{
+put_gfn(parent, gfn_l);
+return -ENOMEM;
+}
+
+new_mfn = page_to_mfn(page);
+copy_domain_page(new_mfn, mfn);
+set_gpfn_from_mfn(mfn_x(new_mfn), gfn_l);
+
+put_gfn(parent, gfn_l);
+
+return p2m->set_entry(p2m, gfn, new_mfn, PAGE_ORDER_4K, p2m_ram_rw,
+  p2m->default_access, -1);
+}
+
+static int bring_up_vcpus(struct domain *cd, struct cpupool *cpupool)
+{
+int ret;
+unsigned int i;
+
+if ( (ret = cpupool_move_domain(cd, cpupool)) )
+return ret;
+
+for ( i = 0; i < cd->max_vcpus; i++ )
+{
+if ( cd->vcpu[i] )
+continue;
+
+if ( 

[Xen-devel] [PATCH v6 9/9] xen/tools: VM forking toolstack side

[Tamas K Lengyel]

Add necessary bits to implement "xl fork-vm" commands. The command allows the
user to specify how to launch the device model allowing for a late-launch model
in which the user can execute the fork without the device model and decide to
only later launch it.

Signed-off-by: Tamas K Lengyel 
---
 docs/man/xl.1.pod.in  |  36 ++
 tools/libxc/include/xenctrl.h |  13 ++
 tools/libxc/xc_memshr.c   |  22 
 tools/libxl/libxl.h   |   7 +
 tools/libxl/libxl_create.c| 237 +++---
 tools/libxl/libxl_dm.c|   2 +-
 tools/libxl/libxl_dom.c   |  43 +-
 tools/libxl/libxl_internal.h  |   1 +
 tools/libxl/libxl_types.idl   |   1 +
 tools/xl/xl.h |   5 +
 tools/xl/xl_cmdtable.c|  12 ++
 tools/xl/xl_saverestore.c |  95 ++
 tools/xl/xl_vmcontrol.c   |   8 ++
 13 files changed, 398 insertions(+), 84 deletions(-)

diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in
index d4b5e8e362..22cc4149b0 100644
--- a/docs/man/xl.1.pod.in
+++ b/docs/man/xl.1.pod.in
@@ -694,6 +694,42 @@ Leave the domain paused after creating the snapshot.
 
 =back
 
+=item B [I] I
+
+Create a fork of a running VM. The domain will be paused after the operation
+and needs to remain paused while forks of it exist.
+
+B
+
+=over 4
+
+=item B<-p>
+
+Leave the fork paused after creating it.
+
+=item B<--launch-dm>
+
+Specify whether the device model (QEMU) should be launched for the fork. Late
+launch allows to start the device model for an already running fork.
+
+=item B<-C>
+
+The config file to use when launching the device model. Currently required when
+launching the device model.
+
+=item B<-Q>
+
+The qemu save file to use when launching the device model.  Currently required
+when launching the device model.
+
+=item B<--fork-reset>
+
+Perform a reset operation of an already running fork. Note that resetting may
+be less performant then creating a new fork depending on how much memory the
+fork has deduplicated during its runtime.
+
+=back
+
 =item B [I]
 
 Display the number of shared pages for a specified domain. If no domain is
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index cc4eb1e3d3..6f65888dd0 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2225,6 +2225,19 @@ int xc_memshr_range_share(xc_interface *xch,
   uint64_t first_gfn,
   uint64_t last_gfn);
 
+int xc_memshr_fork(xc_interface *xch,
+   uint32_t source_domain,
+   uint32_t client_domain);
+
+/*
+ * Note: this function is only intended to be used on short-lived forks that
+ * haven't yet aquired a lot of memory. In case the fork has a lot of memory
+ * it is likely more performant to create a new fork with xc_memshr_fork.
+ *
+ * With VMs that have a lot of memory this call may block for a long time.
+ */
+int xc_memshr_fork_reset(xc_interface *xch, uint32_t forked_domain);
+
 /* Debug calls: return the number of pages referencing the shared frame backing
  * the input argument. Should be one or greater.
  *
diff --git a/tools/libxc/xc_memshr.c b/tools/libxc/xc_memshr.c
index 97e2e6a8d9..d0e4ee225b 100644
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -239,6 +239,28 @@ int xc_memshr_debug_gref(xc_interface *xch,
 return xc_memshr_memop(xch, domid, );
 }
 
+int xc_memshr_fork(xc_interface *xch, uint32_t pdomid, uint32_t domid)
+{
+xen_mem_sharing_op_t mso;
+
+memset(, 0, sizeof(mso));
+
+mso.op = XENMEM_sharing_op_fork;
+mso.u.fork.parent_domain = pdomid;
+
+return xc_memshr_memop(xch, domid, );
+}
+
+int xc_memshr_fork_reset(xc_interface *xch, uint32_t domid)
+{
+xen_mem_sharing_op_t mso;
+
+memset(, 0, sizeof(mso));
+mso.op = XENMEM_sharing_op_fork_reset;
+
+return xc_memshr_memop(xch, domid, );
+}
+
 int xc_memshr_audit(xc_interface *xch)
 {
 xen_mem_sharing_op_t mso;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 54abb9db1f..75cb070587 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1536,6 +1536,13 @@ int libxl_domain_create_new(libxl_ctx *ctx, 
libxl_domain_config *d_config,
 const libxl_asyncop_how *ao_how,
 const libxl_asyncprogress_how *aop_console_how)
 LIBXL_EXTERNAL_CALLERS_ONLY;
+int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid, uint32_t *domid)
+ LIBXL_EXTERNAL_CALLERS_ONLY;
+int libxl_domain_fork_launch_dm(libxl_ctx *ctx, libxl_domain_config *d_config,
+uint32_t domid,
+const libxl_asyncprogress_how *aop_console_how)
+LIBXL_EXTERNAL_CALLERS_ONLY;
+int libxl_domain_fork_reset(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
 

[Xen-devel] [PATCH v6 4/9] x86/mem_sharing: Replace MEM_SHARING_DEBUG with gdprintk

[Tamas K Lengyel]

Using XENLOG_ERR level since this is only used in debug paths (ie. it's
expected the user already has loglvl=all set). Also use %pd to print the domain
ids.

Signed-off-by: Tamas K Lengyel 
---
 xen/arch/x86/mm/mem_sharing.c | 82 +--
 1 file changed, 41 insertions(+), 41 deletions(-)

diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 5ce075d307..2b3be5b125 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -49,9 +49,6 @@ typedef struct pg_lock_data {
 
 static DEFINE_PER_CPU(pg_lock_data_t, __pld);
 
-#define MEM_SHARING_DEBUG(_f, _a...)  \
-debugtrace_printk("mem_sharing_debug: %s(): " _f, __func__, ##_a)
-
 /* Reverse map defines */
 #define RMAP_HASHTAB_ORDER  0
 #define RMAP_HASHTAB_SIZE   \
@@ -482,9 +479,9 @@ static int audit(void)
 /* If we can't lock it, it's definitely not a shared page */
 if ( !mem_sharing_page_lock(pg) )
 {
-MEM_SHARING_DEBUG(
-"mfn %lx in audit list, but cannot be locked (%lx)!\n",
-mfn_x(mfn), pg->u.inuse.type_info);
+gdprintk(XENLOG_ERR,
+ "mfn %lx in audit list, but cannot be locked (%lx)!\n",
+ mfn_x(mfn), pg->u.inuse.type_info);
 errors++;
 continue;
 }
@@ -492,9 +489,9 @@ static int audit(void)
 /* Check if the MFN has correct type, owner and handle. */
 if ( (pg->u.inuse.type_info & PGT_type_mask) != PGT_shared_page )
 {
-MEM_SHARING_DEBUG(
-"mfn %lx in audit list, but not PGT_shared_page (%lx)!\n",
-mfn_x(mfn), pg->u.inuse.type_info & PGT_type_mask);
+gdprintk(XENLOG_ERR,
+ "mfn %lx in audit list, but not PGT_shared_page (%lx)!\n",
+ mfn_x(mfn), pg->u.inuse.type_info & PGT_type_mask);
 errors++;
 continue;
 }
@@ -502,24 +499,24 @@ static int audit(void)
 /* Check the page owner. */
 if ( page_get_owner(pg) != dom_cow )
 {
-MEM_SHARING_DEBUG("mfn %lx shared, but wrong owner %pd!\n",
-  mfn_x(mfn), page_get_owner(pg));
+gdprintk(XENLOG_ERR, "mfn %lx shared, but wrong owner (%pd)!\n",
+ mfn_x(mfn), page_get_owner(pg));
 errors++;
 }
 
 /* Check the m2p entry */
 if ( !SHARED_M2P(get_gpfn_from_mfn(mfn_x(mfn))) )
 {
-MEM_SHARING_DEBUG("mfn %lx shared, but wrong m2p entry (%lx)!\n",
-  mfn_x(mfn), get_gpfn_from_mfn(mfn_x(mfn)));
+gdprintk(XENLOG_ERR, "mfn %lx shared, but wrong m2p entry 
(%lx)!\n",
+ mfn_x(mfn), get_gpfn_from_mfn(mfn_x(mfn)));
 errors++;
 }
 
 /* Check we have a list */
 if ( (!pg->sharing) || rmap_count(pg) == 0 )
 {
-MEM_SHARING_DEBUG("mfn %lx shared, but empty gfn list!\n",
-  mfn_x(mfn));
+gdprintk(XENLOG_ERR, "mfn %lx shared, but empty gfn list!\n",
+ mfn_x(mfn));
 errors++;
 continue;
 }
@@ -538,24 +535,26 @@ static int audit(void)
 d = get_domain_by_id(g->domain);
 if ( d == NULL )
 {
-MEM_SHARING_DEBUG("Unknown dom: %hu, for PFN=%lx, MFN=%lx\n",
-  g->domain, g->gfn, mfn_x(mfn));
+gdprintk(XENLOG_ERR,
+ "Unknown dom: %d, for PFN=%lx, MFN=%lx\n",
+ g->domain, g->gfn, mfn_x(mfn));
 errors++;
 continue;
 }
 o_mfn = get_gfn_query_unlocked(d, g->gfn, );
 if ( !mfn_eq(o_mfn, mfn) )
 {
-MEM_SHARING_DEBUG("Incorrect P2M for d=%hu, PFN=%lx."
-  "Expecting MFN=%lx, got %lx\n",
-  g->domain, g->gfn, mfn_x(mfn), mfn_x(o_mfn));
+gdprintk(XENLOG_ERR, "Incorrect P2M for %pd, PFN=%lx."
+ "Expecting MFN=%lx, got %lx\n",
+ d, g->gfn, mfn_x(mfn), mfn_x(o_mfn));
 errors++;
 }
 if ( t != p2m_ram_shared )
 {
-MEM_SHARING_DEBUG("Incorrect P2M type for d=%hu, PFN=%lx 
MFN=%lx."
-  "Expecting t=%d, got %d\n",
-  g->domain, g->gfn, mfn_x(mfn), 
p2m_ram_shared, t);
+gdprintk(XENLOG_ERR,
+ "Incorrect P2M type for %pd, PFN=%lx MFN=%lx."
+ "Expecting t=%d, got %d\n",
+ d, g->gfn, mfn_x(mfn), p2m_ram_shared, t);
 errors++;
 }
 put_domain(d);
@@ -564,10 +563,10 @@ static int 

[Xen-devel] [PATCH v6 8/9] x86/mem_sharing: reset a fork

[Tamas K Lengyel]

Implement hypercall that allows a fork to shed all memory that got allocated
for it during its execution and re-load its vCPU context from the parent VM.
This allows the forked VM to reset into the same state the parent VM is in a
faster way then creating a new fork would be. Measurements show about a 2x
speedup during normal fuzzing operations. Performance may vary depending how
much memory got allocated for the forked VM. If it has been completely
deduplicated from the parent VM then creating a new fork would likely be more
performant.

Signed-off-by: Tamas K Lengyel 
---
 xen/arch/x86/mm/mem_sharing.c | 76 +++
 xen/include/public/memory.h   |  1 +
 2 files changed, 77 insertions(+)

diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index b6be78486d..88549db7b2 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1613,6 +1613,59 @@ static int mem_sharing_fork(struct domain *d, struct 
domain *cd)
 return rc;
 }
 
+/*
+ * The fork reset operation is intended to be used on short-lived forks only.
+ * There is no hypercall continuation operation implemented for this reason.
+ * For forks that obtain a larger memory footprint it is likely going to be
+ * more performant to create a new fork instead of resetting an existing one.
+ *
+ * TODO: In case this hypercall would become useful on forks with larger memory
+ * footprints the hypercall continuation should be implemented.
+ */
+static int mem_sharing_fork_reset(struct domain *d, struct domain *cd)
+{
+int rc;
+struct p2m_domain* p2m = p2m_get_hostp2m(cd);
+struct page_info *page, *tmp;
+
+domain_pause(cd);
+
+page_list_for_each_safe(page, tmp, >page_list)
+{
+p2m_type_t p2mt;
+p2m_access_t p2ma;
+gfn_t gfn;
+mfn_t mfn = page_to_mfn(page);
+
+if ( !mfn_valid(mfn) )
+continue;
+
+gfn = mfn_to_gfn(cd, mfn);
+mfn = __get_gfn_type_access(p2m, gfn_x(gfn), , ,
+0, NULL, false);
+
+if ( !p2m_is_ram(p2mt) || p2m_is_shared(p2mt) )
+continue;
+
+/* take an extra reference */
+if ( !get_page(page, cd) )
+continue;
+
+rc = p2m->set_entry(p2m, gfn, INVALID_MFN, PAGE_ORDER_4K,
+p2m_invalid, p2m_access_rwx, -1);
+ASSERT(!rc);
+
+put_page_alloc_ref(page);
+put_page(page);
+}
+
+if ( !(rc = hvm_copy_context_and_params(d, cd)) )
+fork_tsc(d, cd);
+
+domain_unpause(cd);
+return rc;
+}
+
 int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
 {
 int rc;
@@ -1897,6 +1950,29 @@ int 
mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
 break;
 }
 
+case XENMEM_sharing_op_fork_reset:
+{
+struct domain *pd;
+
+rc = -EINVAL;
+if ( mso.u.fork._pad[0] || mso.u.fork._pad[1] ||
+ mso.u.fork._pad[2] )
+goto out;
+
+rc = -ENOSYS;
+if ( !d->parent )
+goto out;
+
+rc = rcu_lock_live_remote_domain_by_id(d->parent->domain_id, );
+if ( rc )
+goto out;
+
+rc = mem_sharing_fork_reset(pd, d);
+
+rcu_unlock_domain(pd);
+break;
+}
+
 default:
 rc = -ENOSYS;
 break;
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index 90a3f4498e..e3d063e22e 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -483,6 +483,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_mem_access_op_t);
 #define XENMEM_sharing_op_audit 7
 #define XENMEM_sharing_op_range_share   8
 #define XENMEM_sharing_op_fork  9
+#define XENMEM_sharing_op_fork_reset10
 
 #define XENMEM_SHARING_OP_S_HANDLE_INVALID  (-10)
 #define XENMEM_SHARING_OP_C_HANDLE_INVALID  (-9)
-- 
2.20.1


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

[Xen-devel] [PATCH v6 2/9] x86/hvm: introduce hvm_copy_context_and_params

[Tamas K Lengyel]

Currently the hvm parameters are only accessible via the HVMOP hypercalls. In
this patch we introduce a new function that can copy both the hvm context and
parameters directly into a target domain. No functional changes in existing
code.

Signed-off-by: Tamas K Lengyel 
---
v6: finish addressing all of Jan's comments
---
 xen/arch/x86/hvm/hvm.c| 236 +-
 xen/include/asm-x86/hvm/hvm.h |   2 +
 2 files changed, 148 insertions(+), 90 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 0b93609a82..0505c75661 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4077,16 +4077,17 @@ static int hvmop_set_evtchn_upcall_vector(
 }
 
 static int hvm_allow_set_param(struct domain *d,
-   const struct xen_hvm_param *a)
+   uint32_t index,
+   uint64_t new_value)
 {
-uint64_t value = d->arch.hvm.params[a->index];
+uint64_t value = d->arch.hvm.params[index];
 int rc;
 
 rc = xsm_hvm_param(XSM_TARGET, d, HVMOP_set_param);
 if ( rc )
 return rc;
 
-switch ( a->index )
+switch ( index )
 {
 /* The following parameters can be set by the guest. */
 case HVM_PARAM_CALLBACK_IRQ:
@@ -4119,7 +4120,7 @@ static int hvm_allow_set_param(struct domain *d,
 if ( rc )
 return rc;
 
-switch ( a->index )
+switch ( index )
 {
 /* The following parameters should only be changed once. */
 case HVM_PARAM_VIRIDIAN:
@@ -4129,7 +4130,7 @@ static int hvm_allow_set_param(struct domain *d,
 case HVM_PARAM_NR_IOREQ_SERVER_PAGES:
 case HVM_PARAM_ALTP2M:
 case HVM_PARAM_MCA_CAP:
-if ( value != 0 && a->value != value )
+if ( value != 0 && new_value != value )
 rc = -EEXIST;
 break;
 default:
@@ -4139,49 +4140,32 @@ static int hvm_allow_set_param(struct domain *d,
 return rc;
 }
 
-static int hvmop_set_param(
-XEN_GUEST_HANDLE_PARAM(xen_hvm_param_t) arg)
+static int hvm_set_param(struct domain *d, uint32_t index, uint64_t value)
 {
 struct domain *curr_d = current->domain;
-struct xen_hvm_param a;
-struct domain *d;
 struct vcpu *v;
 int rc;
 
-if ( copy_from_guest(, arg, 1) )
-return -EFAULT;
-
-if ( a.index >= HVM_NR_PARAMS )
+if ( index >= HVM_NR_PARAMS )
 return -EINVAL;
 
-/* Make sure the above bound check is not bypassed during speculation. */
-block_speculation();
-
-d = rcu_lock_domain_by_any_id(a.domid);
-if ( d == NULL )
-return -ESRCH;
-
-rc = -EINVAL;
-if ( !is_hvm_domain(d) )
-goto out;
-
-rc = hvm_allow_set_param(d, );
+rc = hvm_allow_set_param(d, index, value);
 if ( rc )
 goto out;
 
-switch ( a.index )
+switch ( index )
 {
 case HVM_PARAM_CALLBACK_IRQ:
-hvm_set_callback_via(d, a.value);
+hvm_set_callback_via(d, value);
 hvm_latch_shinfo_size(d);
 break;
 case HVM_PARAM_TIMER_MODE:
-if ( a.value > HVMPTM_one_missed_tick_pending )
+if ( value > HVMPTM_one_missed_tick_pending )
 rc = -EINVAL;
 break;
 case HVM_PARAM_VIRIDIAN:
-if ( (a.value & ~HVMPV_feature_mask) ||
- !(a.value & HVMPV_base_freq) )
+if ( (value & ~HVMPV_feature_mask) ||
+ !(value & HVMPV_base_freq) )
 rc = -EINVAL;
 break;
 case HVM_PARAM_IDENT_PT:
@@ -4191,7 +4175,7 @@ static int hvmop_set_param(
  */
 if ( !paging_mode_hap(d) || !cpu_has_vmx )
 {
-d->arch.hvm.params[a.index] = a.value;
+d->arch.hvm.params[index] = value;
 break;
 }
 
@@ -4206,7 +4190,7 @@ static int hvmop_set_param(
 
 rc = 0;
 domain_pause(d);
-d->arch.hvm.params[a.index] = a.value;
+d->arch.hvm.params[index] = value;
 for_each_vcpu ( d, v )
 paging_update_cr3(v, false);
 domain_unpause(d);
@@ -4215,23 +4199,23 @@ static int hvmop_set_param(
 break;
 case HVM_PARAM_DM_DOMAIN:
 /* The only value this should ever be set to is DOMID_SELF */
-if ( a.value != DOMID_SELF )
+if ( value != DOMID_SELF )
 rc = -EINVAL;
 
-a.value = curr_d->domain_id;
+value = curr_d->domain_id;
 break;
 case HVM_PARAM_ACPI_S_STATE:
 rc = 0;
-if ( a.value == 3 )
+if ( value == 3 )
 hvm_s3_suspend(d);
-else if ( a.value == 0 )
+else if ( value == 0 )
 hvm_s3_resume(d);
 else
 rc = -EINVAL;
 
 break;
 case HVM_PARAM_ACPI_IOPORTS_LOCATION:
-rc = pmtimer_change_ioport(d, a.value);
+rc = pmtimer_change_ioport(d, value);
 break;
 case HVM_PARAM_MEMORY_EVENT_CR0:
 case HVM_PARAM_MEMORY_EVENT_CR3:
@@ -4246,24 +4230,24 @@ static int hvmop_set_param(
  

[Xen-devel] [PATCH v6 7/9] xen/mem_access: Use __get_gfn_type_access in set_mem_access

[Tamas K Lengyel]

Use __get_gfn_type_access instead of p2m->get_entry to trigger page-forking
when the mem_access permission is being set on a page that has not yet been
copied over from the parent.

Signed-off-by: Tamas K Lengyel 
---
 xen/arch/x86/mm/mem_access.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
index d16540a9aa..ede774fb50 100644
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -303,11 +303,10 @@ static int set_mem_access(struct domain *d, struct 
p2m_domain *p2m,
 ASSERT(!ap2m);
 #endif
 {
-mfn_t mfn;
 p2m_access_t _a;
 p2m_type_t t;
-
-mfn = p2m->get_entry(p2m, gfn, , &_a, 0, NULL, NULL);
+mfn_t mfn = __get_gfn_type_access(p2m, gfn_x(gfn), , &_a,
+  P2M_ALLOC, NULL, false);
 rc = p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, t, a, -1);
 }
 
-- 
2.20.1


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

[Xen-devel] [PATCH v6 5/9] x86/mem_sharing: use default_access in add_to_physmap

[Tamas K Lengyel]

When plugging a hole in the target physmap don't use the access permission
returned by __get_gfn_type_access as it can be non-sensical, leading to
spurious vm_events being sent out for access violations at unexpected
locations. Make use of p2m->default_access instead.

Signed-off-by: Tamas K Lengyel 
---
 xen/arch/x86/mm/mem_sharing.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 2b3be5b125..52b139c1bb 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1071,11 +1071,10 @@ int add_to_physmap(struct domain *sd, unsigned long 
sgfn, shr_handle_t sh,
 p2m_type_t smfn_type, cmfn_type;
 struct gfn_info *gfn_info;
 struct p2m_domain *p2m = p2m_get_hostp2m(cd);
-p2m_access_t a;
 struct two_gfns tg;
 
 get_two_gfns(sd, _gfn(sgfn), _type, NULL, ,
- cd, _gfn(cgfn), _type, , , 0, , lock);
+ cd, _gfn(cgfn), _type, NULL, , 0, , lock);
 
 /* Get the source shared page, check and lock */
 ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
@@ -1110,7 +1109,7 @@ int add_to_physmap(struct domain *sd, unsigned long sgfn, 
shr_handle_t sh,
 }
 
 ret = p2m_set_entry(p2m, _gfn(cgfn), smfn, PAGE_ORDER_4K,
-p2m_ram_shared, a);
+p2m_ram_shared, p2m->default_access);
 
 /* Tempted to turn this into an assert */
 if ( ret )
-- 
2.20.1


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

[Xen-devel] [PATCH v6 0/9] VM forking

[Tamas K Lengyel]

The following series implements VM forking for Intel HVM guests to allow for
the fast creation of identical VMs without the assosciated high startup costs
of booting or restoring the VM from a savefile.

JIRA issue: https://xenproject.atlassian.net/browse/XEN-89

The fork operation is implemented as part of the "xl fork-vm" command:
xl fork-vm -C  -Q  

By default a fully functional fork is created. The user is in charge however to
create the appropriate config file for the fork and to generate the QEMU save
file before the fork-vm call is made. The config file needs to give the
fork a new name at minimum but other settings may also require changes.

The interface also allows to split the forking into two steps:
xl fork-vm --launch-dm no \
   -p 
xl fork-vm --launch-dm late \
   -C  \
   -Q  \
   

The split creation model is useful when the VM needs to be created as fast as
possible. The forked VM can be unpaused without the device model being launched
to be monitored and accessed via VMI. Note however that without its device
model running (depending on what is executing in the VM) it is bound to
misbehave or even crash when its trying to access devices that would be
emulated by QEMU. We anticipate that for certain use-cases this would be an
acceptable situation, in case for example when fuzzing is performed of code
segments that don't access such devices.

Launching the device model requires the QEMU Xen savefile to be generated
manually from the parent VM. This can be accomplished simply by connecting to
its QMP socket and issuing the "xen-save-devices-state" command. For example
using the standard tool socat these commands can be used to generate the file:
socat - UNIX-CONNECT:/var/run/xen/qmp-libxl-
{ "execute": "qmp_capabilities" }
{ "execute": "xen-save-devices-state", \
"arguments": { "filename": "/path/to/save/qemu_state", \
"live": false} }

At runtime the forked VM starts running with an empty p2m which gets lazily
populated when the VM generates EPT faults, similar to how altp2m views are
populated. If the memory access is a read-only access, the p2m entry is
populated with a memory shared entry with its parent. For write memory accesses
or in case memory sharing wasn't possible (for example in case a reference is
held by a third party), a new page is allocated and the page contents are
copied over from the parent VM. Forks can be further forked if needed, thus
allowing for further memory savings.

A VM fork reset hypercall is also added that allows the fork to be reset to the
state it was just after a fork, also accessible via xl:
xl fork-vm --fork-reset -p 

This is an optimization for cases where the forks are very short-lived and run
without a device model, so resetting saves some time compared to creating a
brand new fork provided the fork has not aquired a lot of memory. If the fork
has a lot of memory deduplicated it is likely going to be faster to create a
new fork from scratch and asynchronously destroying the old one.

The series has been tested with both Linux and Windows VMs and functions as
expected. VM forking time has been measured to be 0.0007s, device model launch
to be around 1s depending largely on the number of devices being emulated. Fork
resets have been measured to be 0.0001s under the optimal circumstances.

New in v6: minor fixes and improvements only + rebasing on staging

Patch 1 is a mem_sharing bugfix

Patches 2-3 implement changes to existing internal Xen APIs to make VM forking
possible.

Patches 4-5 are simple code-cleanups to mem_sharing

Patch 6 adds the hypervisor-side code implementing VM forking.

Patch 7 is integration of mem_access with forked VMs.

Patch 8 implements the VM fork reset operation hypervisor side bits.

Patch 9 adds the toolstack-side code implementing VM forking and reset.

Tamas K Lengyel (9):
  x86/hvm: introduce hvm_copy_context_and_params
  xen/x86: Make hap_get_allocation accessible
  x86/p2m: Allow p2m_get_page_from_gfn to return shared entries
  x86/mem_sharing: Replace MEM_SHARING_DEBUG with gdprintk
  x86/mem_sharing: use default_access in add_to_physmap
  xen/mem_sharing: VM forking
  xen/mem_access: Use __get_gfn_type_access in set_mem_access
  x86/mem_sharing: reset a fork
  xen/tools: VM forking toolstack side

 docs/man/xl.1.pod.in  |  36 +++
 tools/libxc/include/xenctrl.h |  13 +
 tools/libxc/xc_memshr.c   |  22 ++
 tools/libxl/libxl.h   |   7 +
 tools/libxl/libxl_create.c| 237 --
 tools/libxl/libxl_dm.c|   2 +-
 tools/libxl/libxl_dom.c   |  43 +++-
 tools/libxl/libxl_internal.h  |   1 +
 tools/libxl/libxl_types.idl   |   1 +
 tools/xl/xl.h |   5 +
 tools/xl/xl_cmdtable.c|  12 +
 tools/xl/xl_saverestore.c |  95 
 tools/xl/xl_vmcontrol.c   |   8 +
 xen/arch/x86/domain.c  

[Xen-devel] [PATCH v6 1/9] x86/p2m: Allow p2m_get_page_from_gfn to return shared entries

[Tamas K Lengyel]

The owner domain of shared pages is dom_cow, use that for get_page
otherwise the function fails to return the correct page. Fixing the
error now and simplifying the checks since we can't have any shared
entries with dom_cow being NULL.

Signed-off-by: Tamas K Lengyel 
---
v6: use simplified check for dom_cow in both slow and fast path
---
 xen/arch/x86/mm/p2m.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 49cc138362..f54360b43d 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -574,11 +574,12 @@ struct page_info *p2m_get_page_from_gfn(
 if ( fdom == NULL )
 page = NULL;
 }
-else if ( !get_page(page, p2m->domain) &&
-  /* Page could be shared */
-  (!dom_cow || !p2m_is_shared(*t) ||
-   !get_page(page, dom_cow)) )
-page = NULL;
+else
+{
+struct domain *d = !p2m_is_shared(*t) ? p2m->domain : dom_cow;
+if ( !get_page(page, d) )
+page = NULL;
+}
 }
 p2m_read_unlock(p2m);
 
@@ -594,8 +595,9 @@ struct page_info *p2m_get_page_from_gfn(
 mfn = get_gfn_type_access(p2m, gfn_x(gfn), t, a, q, NULL);
 if ( p2m_is_ram(*t) && mfn_valid(mfn) )
 {
+struct domain *d = !p2m_is_shared(*t) ? p2m->domain : dom_cow;
 page = mfn_to_page(mfn);
-if ( !get_page(page, p2m->domain) )
+if ( !get_page(page, d) )
 page = NULL;
 }
 put_gfn(p2m->domain, gfn_x(gfn));
-- 
2.20.1


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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-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-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  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
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  

Re: [Xen-devel] [PATCH v4 01/15] drm: Initialize struct drm_crtc_state.no_vblank from device settings

[Emil Velikov]

Hi Thomas,

On Thu, 23 Jan 2020 at 09:21, Thomas Zimmermann  wrote:

> @@ -174,12 +174,22 @@ struct drm_crtc_state {
>  * @no_vblank:
>  *
>  * Reflects the ability of a CRTC to send VBLANK events. This state
> -* usually depends on the pipeline configuration, and the main usuage
> -* is CRTCs feeding a writeback connector operating in oneshot mode.
> -* In this case the VBLANK event is only generated when a job is 
> queued
> -* to the writeback connector, and we want the core to fake VBLANK
> -* events when this part of the pipeline hasn't changed but others had
> -* or when the CRTC and connectors are being disabled.
> +* usually depends on the pipeline configuration. If set to true, DRM
> +* atomic helpers will sendout a fake VBLANK event during display
> +* updates.
> +*
> +* One usage is for drivers and/or hardware without support for VBLANK
> +* interrupts. Such drivers typically do not initialize vblanking
> +* (i.e., call drm_vblank_init() wit the number of CRTCs). For CRTCs
> +* without initialized vblanking, the field is initialized to true and
> +* a VBLANK event will be send out on each update of the display
> +* pipeline.
> +*
> +* Another usage is CRTCs feeding a writeback connector operating in
> +* oneshot mode. In this case the VBLANK event is only generated when
> +* a job is queued to the writeback connector, and we want the core
> +* to fake VBLANK events when this part of the pipeline hasn't changed
> +* but others had or when the CRTC and connectors are being disabled.
>  *

Perhaps it's just me, yet the following ideas would make the topic
significantly easier and clearer.

 - adding explicit "fake" when talking about drm/atomic _helpers_
generating/sending a VBLANK event.
For example, in 15/15 the commit message says "fake", while inline
comment omits it... Leading to the confusion pointed out.

- s/no_vblank/fake_vblank/g or s/no_vblank/no_hw_vblank/g
Simple and concise. With slight inclination towards the former wording :-)

If you and Daniel agree with the rename, then the first sentence of
the description should probably be tweaked.

HTH
Emil

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

[Xen-devel] [PATCH v3 7/7] x86/tlb: use Xen L0 assisted TLB flush when available

[Roger Pau Monne]

Use Xen's L0 HVMOP_flush_tlbs hypercall in order to perform flushes.
This greatly increases the performance of TLB flushes when running
with a high amount of vCPUs as a Xen guest, and is specially important
when running in shim mode.

The following figures are from a PV guest running `make -j32 xen` in
shim mode with 32 vCPUs and HAP.

Using x2APIC and ALLBUT shorthand:
real4m35.973s
user4m35.110s
sys 36m24.117s

Using L0 assisted flush:
real1m2.596s
user4m34.818s
sys 5m16.374s

The implementation adds a new hook to hypervisor_ops so other
enlightenments can also implement such assisted flush just by filling
the hook. Note that the Xen implementation completely ignores the
dirty CPU mask and the linear address passed in, and always performs a
global TLB flush on all vCPUs.

Signed-off-by: Roger Pau Monné 
---
Changes since v1:
 - Add a L0 assisted hook to hypervisor ops.
---
 xen/arch/x86/guest/hypervisor.c| 10 ++
 xen/arch/x86/guest/xen/xen.c   |  6 ++
 xen/arch/x86/smp.c | 11 +++
 xen/include/asm-x86/guest/hypervisor.h | 17 +
 4 files changed, 44 insertions(+)

diff --git a/xen/arch/x86/guest/hypervisor.c b/xen/arch/x86/guest/hypervisor.c
index 4f27b98740..4085b19734 100644
--- a/xen/arch/x86/guest/hypervisor.c
+++ b/xen/arch/x86/guest/hypervisor.c
@@ -18,6 +18,7 @@
  *
  * Copyright (c) 2019 Microsoft.
  */
+#include 
 #include 
 #include 
 
@@ -64,6 +65,15 @@ void hypervisor_resume(void)
 ops->resume();
 }
 
+int hypervisor_flush_tlb(const cpumask_t *mask, const void *va,
+ unsigned int order)
+{
+if ( ops && ops->flush_tlb )
+return ops->flush_tlb(mask, va, order);
+
+return -ENOSYS;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/guest/xen/xen.c b/xen/arch/x86/guest/xen/xen.c
index 6dbc5f953f..639a2a4b32 100644
--- a/xen/arch/x86/guest/xen/xen.c
+++ b/xen/arch/x86/guest/xen/xen.c
@@ -310,11 +310,17 @@ static void resume(void)
 pv_console_init();
 }
 
+static int flush_tlb(const cpumask_t *mask, const void *va, unsigned int order)
+{
+return xen_hypercall_hvm_op(HVMOP_flush_tlbs, NULL);
+}
+
 static const struct hypervisor_ops ops = {
 .name = "Xen",
 .setup = setup,
 .ap_setup = ap_setup,
 .resume = resume,
+.flush_tlb = flush_tlb,
 };
 
 const struct hypervisor_ops *__init xg_probe(void)
diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c
index 65eb7cbda8..9bc925616a 100644
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -256,6 +257,16 @@ void flush_area_mask(const cpumask_t *mask, const void 
*va, unsigned int flags)
 if ( (flags & ~FLUSH_ORDER_MASK) &&
  !cpumask_subset(mask, cpumask_of(cpu)) )
 {
+if ( cpu_has_hypervisor &&
+ !(flags & ~(FLUSH_TLB | FLUSH_TLB_GLOBAL | FLUSH_VA_VALID |
+ FLUSH_ORDER_MASK)) &&
+ !hypervisor_flush_tlb(mask, va, flags & FLUSH_ORDER_MASK) )
+{
+if ( tlb_clk_enabled )
+tlb_clk_enabled = false;
+return;
+}
+
 spin_lock(_lock);
 cpumask_and(_cpumask, mask, _online_map);
 cpumask_clear_cpu(cpu, _cpumask);
diff --git a/xen/include/asm-x86/guest/hypervisor.h 
b/xen/include/asm-x86/guest/hypervisor.h
index 392f4b90ae..e230a5d065 100644
--- a/xen/include/asm-x86/guest/hypervisor.h
+++ b/xen/include/asm-x86/guest/hypervisor.h
@@ -19,6 +19,8 @@
 #ifndef __X86_HYPERVISOR_H__
 #define __X86_HYPERVISOR_H__
 
+#include 
+
 struct hypervisor_ops {
 /* Name of the hypervisor */
 const char *name;
@@ -28,6 +30,8 @@ struct hypervisor_ops {
 void (*ap_setup)(void);
 /* Resume from suspension */
 void (*resume)(void);
+/* L0 assisted TLB flush */
+int (*flush_tlb)(const cpumask_t *mask, const void *va, unsigned int 
order);
 };
 
 #ifdef CONFIG_GUEST
@@ -36,6 +40,14 @@ const char *hypervisor_probe(void);
 void hypervisor_setup(void);
 void hypervisor_ap_setup(void);
 void hypervisor_resume(void);
+/*
+ * L0 assisted TLB flush.
+ * mask: cpumask of the dirty vCPUs that should be flushed.
+ * va: linear address to flush, or NULL for global flushes.
+ * order: order of the linear address pointed by va.
+ */
+int hypervisor_flush_tlb(const cpumask_t *mask, const void *va,
+ unsigned int order);
 
 #else
 
@@ -46,6 +58,11 @@ static inline const char *hypervisor_probe(void) { return 
NULL; }
 static inline void hypervisor_setup(void) { ASSERT_UNREACHABLE(); }
 static inline void hypervisor_ap_setup(void) { ASSERT_UNREACHABLE(); }
 static inline void hypervisor_resume(void) { ASSERT_UNREACHABLE(); }
+static inline int hypervisor_flush_tlb(const cpumask_t *mask, const void *va,
+   unsigned int order)
+{
+return -ENOSYS;
+}
 
 #endif  /* CONFIG_GUEST */
 
-- 

[Xen-devel] [PATCH v3 4/7] x86/hap: improve hypervisor assisted guest TLB flush

[Roger Pau Monne]

The current implementation of the hypervisor assisted flush for HAP is
extremely inefficient.

First of all there's no need to call paging_update_cr3, as the only
relevant part of that function when doing a flush is the ASID vCPU
flush, so just call that function directly.

Since hvm_asid_flush_vcpu is protected against concurrent callers by
using atomic operations there's no need anymore to pause the affected
vCPUs.

Finally the global TLB flush performed by flush_tlb_mask is also not
necessary, since we only want to flush the guest TLB state it's enough
to trigger a vmexit on the pCPUs currently holding any vCPU state, as
such vmexit will already perform an ASID/VPID update, and thus clear
the guest TLB.

Signed-off-by: Roger Pau Monné 
---
 xen/arch/x86/mm/hap/hap.c | 48 +--
 1 file changed, 21 insertions(+), 27 deletions(-)

diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 6894c1aa38..401eaf8026 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -669,32 +669,24 @@ static void hap_update_cr3(struct vcpu *v, int 
do_locking, bool noflush)
 hvm_update_guest_cr3(v, noflush);
 }
 
+static void do_flush(void *data)
+{
+cpumask_t *mask = data;
+unsigned int cpu = smp_processor_id();
+
+ASSERT(cpumask_test_cpu(cpu, mask));
+cpumask_clear_cpu(cpu, mask);
+}
+
 bool hap_flush_tlb(bool (*flush_vcpu)(void *ctxt, struct vcpu *v),
void *ctxt)
 {
 static DEFINE_PER_CPU(cpumask_t, flush_cpumask);
 cpumask_t *mask = _cpu(flush_cpumask);
 struct domain *d = current->domain;
+unsigned int this_cpu = smp_processor_id();
 struct vcpu *v;
 
-/* Avoid deadlock if more than one vcpu tries this at the same time. */
-if ( !spin_trylock(>hypercall_deadlock_mutex) )
-return false;
-
-/* Pause all other vcpus. */
-for_each_vcpu ( d, v )
-if ( v != current && flush_vcpu(ctxt, v) )
-vcpu_pause_nosync(v);
-
-/* Now that all VCPUs are signalled to deschedule, we wait... */
-for_each_vcpu ( d, v )
-if ( v != current && flush_vcpu(ctxt, v) )
-while ( !vcpu_runnable(v) && v->is_running )
-cpu_relax();
-
-/* All other vcpus are paused, safe to unlock now. */
-spin_unlock(>hypercall_deadlock_mutex);
-
 cpumask_clear(mask);
 
 /* Flush paging-mode soft state (e.g., va->gfn cache; PAE PDPE cache). */
@@ -705,20 +697,22 @@ bool hap_flush_tlb(bool (*flush_vcpu)(void *ctxt, struct 
vcpu *v),
 if ( !flush_vcpu(ctxt, v) )
 continue;
 
-paging_update_cr3(v, false);
+hvm_asid_flush_vcpu(v);
 
 cpu = read_atomic(>dirty_cpu);
-if ( is_vcpu_dirty_cpu(cpu) )
+if ( cpu != this_cpu && is_vcpu_dirty_cpu(cpu) )
 __cpumask_set_cpu(cpu, mask);
 }
 
-/* Flush TLBs on all CPUs with dirty vcpu state. */
-flush_tlb_mask(mask);
-
-/* Done. */
-for_each_vcpu ( d, v )
-if ( v != current && flush_vcpu(ctxt, v) )
-vcpu_unpause(v);
+/*
+ * Trigger a vmexit on all pCPUs with dirty vCPU state in order to force an
+ * ASID/VPIT change and hence accomplish a guest TLB flush. Note that vCPUs
+ * not currently running will already be flushed when scheduled because of
+ * the ASID tickle done in the loop above.
+ */
+on_selected_cpus(mask, do_flush, mask, 0);
+while ( !cpumask_empty(mask) )
+cpu_relax();
 
 return true;
 }
-- 
2.25.0


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

[Xen-devel] [PATCH v3 1/7] x86/tlb: fix NEED_FLUSH return type

[Roger Pau Monne]

The returned type wants to be bool instead of int.

No functional change intended.

Signed-off-by: Roger Pau Monné 
---
 xen/include/asm-x86/flushtlb.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/asm-x86/flushtlb.h b/xen/include/asm-x86/flushtlb.h
index 434821aaf3..2cfe4e6e97 100644
--- a/xen/include/asm-x86/flushtlb.h
+++ b/xen/include/asm-x86/flushtlb.h
@@ -42,7 +42,7 @@ static inline void page_set_tlbflush_timestamp(struct 
page_info *page)
  * @lastuse_stamp is a timestamp taken when the PFN we are testing was last 
  * used for a purpose that may have caused the CPU's TLB to become tainted.
  */
-static inline int NEED_FLUSH(u32 cpu_stamp, u32 lastuse_stamp)
+static inline bool NEED_FLUSH(u32 cpu_stamp, u32 lastuse_stamp)
 {
 u32 curr_time = tlbflush_current_time();
 /*
-- 
2.25.0


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

[Xen-devel] [PATCH v3 5/7] x86/tlb: introduce a flush guests TLB flag

[Roger Pau Monne]

Introduce a specific flag to request a HVM guest TLB flush, which is
an ASID/VPID tickle that forces a linear TLB flush for all HVM guests.

This was previously unconditionally done in each pre_flush call, but
that's not required: HVM guests not using shadow don't require linear
TLB flushes as Xen doesn't modify the guest page tables in that case
(ie: when using HAP).

Modify all shadow code TLB flushes to also flush the guest TLB, in
order to keep the previous behavior. I haven't looked at each specific
shadow code TLB flush in order to figure out whether it actually
requires a guest TLB flush or not, so there might be room for
improvement in that regard.

Signed-off-by: Roger Pau Monné 
---
 xen/arch/x86/flushtlb.c |  5 +++--
 xen/arch/x86/mm/shadow/common.c | 18 +-
 xen/arch/x86/mm/shadow/hvm.c|  2 +-
 xen/arch/x86/mm/shadow/multi.c  | 16 
 xen/include/asm-x86/flushtlb.h  |  2 ++
 5 files changed, 23 insertions(+), 20 deletions(-)

diff --git a/xen/arch/x86/flushtlb.c b/xen/arch/x86/flushtlb.c
index 03f92c23dc..e7ccd4ec7b 100644
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -59,8 +59,6 @@ static u32 pre_flush(void)
 raise_softirq(NEW_TLBFLUSH_CLOCK_PERIOD_SOFTIRQ);
 
  skip_clocktick:
-hvm_flush_guest_tlbs();
-
 return t2;
 }
 
@@ -221,6 +219,9 @@ unsigned int flush_area_local(const void *va, unsigned int 
flags)
 do_tlb_flush();
 }
 
+if ( flags & FLUSH_GUESTS_TLB )
+hvm_flush_guest_tlbs();
+
 if ( flags & FLUSH_CACHE )
 {
 const struct cpuinfo_x86 *c = _cpu_data;
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index ee90e55b41..2a85e10112 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -363,7 +363,7 @@ static int oos_remove_write_access(struct vcpu *v, mfn_t 
gmfn,
 }
 
 if ( ftlb )
-flush_tlb_mask(d->dirty_cpumask);
+flush_mask(d->dirty_cpumask, FLUSH_TLB | FLUSH_GUESTS_TLB);
 
 return 0;
 }
@@ -939,7 +939,7 @@ static void _shadow_prealloc(struct domain *d, unsigned int 
pages)
 /* See if that freed up enough space */
 if ( d->arch.paging.shadow.free_pages >= pages )
 {
-flush_tlb_mask(d->dirty_cpumask);
+flush_mask(d->dirty_cpumask, FLUSH_TLB | FLUSH_GUESTS_TLB);
 return;
 }
 }
@@ -993,7 +993,7 @@ static void shadow_blow_tables(struct domain *d)
pagetable_get_mfn(v->arch.shadow_table[i]), 0);
 
 /* Make sure everyone sees the unshadowings */
-flush_tlb_mask(d->dirty_cpumask);
+flush_mask(d->dirty_cpumask, FLUSH_TLB | FLUSH_GUESTS_TLB);
 }
 
 void shadow_blow_tables_per_domain(struct domain *d)
@@ -1102,7 +1102,7 @@ mfn_t shadow_alloc(struct domain *d,
 if ( unlikely(!cpumask_empty()) )
 {
 perfc_incr(shadow_alloc_tlbflush);
-flush_tlb_mask();
+flush_mask(, FLUSH_TLB | FLUSH_GUESTS_TLB);
 }
 /* Now safe to clear the page for reuse */
 clear_domain_page(page_to_mfn(sp));
@@ -2290,7 +2290,7 @@ void sh_remove_shadows(struct domain *d, mfn_t gmfn, int 
fast, int all)
 
 /* Need to flush TLBs now, so that linear maps are safe next time we
  * take a fault. */
-flush_tlb_mask(d->dirty_cpumask);
+flush_mask(d->dirty_cpumask, FLUSH_TLB | FLUSH_GUESTS_TLB);
 
 paging_unlock(d);
 }
@@ -3005,7 +3005,7 @@ static void sh_unshadow_for_p2m_change(struct domain *d, 
unsigned long gfn,
 {
 sh_remove_all_shadows_and_parents(d, mfn);
 if ( sh_remove_all_mappings(d, mfn, _gfn(gfn)) )
-flush_tlb_mask(d->dirty_cpumask);
+flush_mask(d->dirty_cpumask, FLUSH_TLB | FLUSH_GUESTS_TLB);
 }
 }
 
@@ -3045,7 +3045,7 @@ static void sh_unshadow_for_p2m_change(struct domain *d, 
unsigned long gfn,
 }
 omfn = mfn_add(omfn, 1);
 }
-flush_tlb_mask();
+flush_mask(, FLUSH_TLB | FLUSH_GUESTS_TLB);
 
 if ( npte )
 unmap_domain_page(npte);
@@ -3332,7 +3332,7 @@ int shadow_track_dirty_vram(struct domain *d,
 }
 }
 if ( flush_tlb )
-flush_tlb_mask(d->dirty_cpumask);
+flush_mask(d->dirty_cpumask, FLUSH_TLB | FLUSH_GUESTS_TLB);
 goto out;
 
 out_sl1ma:
@@ -3402,7 +3402,7 @@ bool shadow_flush_tlb(bool (*flush_vcpu)(void *ctxt, 
struct vcpu *v),
 }
 
 /* Flush TLBs on all CPUs with dirty vcpu state. */
-flush_tlb_mask(mask);
+flush_mask(mask, FLUSH_TLB | FLUSH_GUESTS_TLB);
 
 /* Done. */
 for_each_vcpu ( d, v )
diff --git a/xen/arch/x86/mm/shadow/hvm.c b/xen/arch/x86/mm/shadow/hvm.c
index a219266fa2..64077d181b 100644
--- a/xen/arch/x86/mm/shadow/hvm.c
+++ b/xen/arch/x86/mm/shadow/hvm.c
@@ -590,7 +590,7 @@ static void 

[Xen-devel] [PATCH v3 6/7] x86/tlb: allow disabling the TLB clock

[Roger Pau Monne]

The TLB clock is helpful when running Xen on bare metal because when
doing a TLB flush each CPU is IPI'ed and can keep a timestamp of the
last flush.

This is not the case however when Xen is running virtualized, and the
underlying hypervisor provides mechanism to assist in performing TLB
flushes: Xen itself for example offers a HVMOP_flush_tlbs hypercall in
order to perform a TLB flush without having to IPI each CPU. When
using such mechanisms it's no longer possible to keep a timestamp of
the flushes on each CPU, as they are performed by the underlying
hypervisor.

Offer a boolean in order to signal Xen that the timestamped TLB
shouldn't be used. This avoids keeping the timestamps of the flushes,
and also forces NEED_FLUSH to always return true.

No functional change intended, as this change doesn't introduce any
user that disables the timestamped TLB.

Signed-off-by: Roger Pau Monné 
---
 xen/arch/x86/flushtlb.c| 19 +--
 xen/include/asm-x86/flushtlb.h | 17 -
 2 files changed, 29 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/flushtlb.c b/xen/arch/x86/flushtlb.c
index e7ccd4ec7b..3649900793 100644
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -32,6 +32,9 @@
 u32 tlbflush_clock = 1U;
 DEFINE_PER_CPU(u32, tlbflush_time);
 
+/* Signals whether the TLB flush clock is in use. */
+bool __read_mostly tlb_clk_enabled = true;
+
 /*
  * pre_flush(): Increment the virtual TLB-flush clock. Returns new clock value.
  * 
@@ -82,12 +85,13 @@ static void post_flush(u32 t)
 static void do_tlb_flush(void)
 {
 unsigned long flags, cr4;
-u32 t;
+u32 t = 0;
 
 /* This non-reentrant function is sometimes called in interrupt context. */
 local_irq_save(flags);
 
-t = pre_flush();
+if ( tlb_clk_enabled )
+t = pre_flush();
 
 if ( use_invpcid )
 invpcid_flush_all();
@@ -99,7 +103,8 @@ static void do_tlb_flush(void)
 else
 write_cr3(read_cr3());
 
-post_flush(t);
+if ( tlb_clk_enabled )
+post_flush(t);
 
 local_irq_restore(flags);
 }
@@ -107,7 +112,7 @@ static void do_tlb_flush(void)
 void switch_cr3_cr4(unsigned long cr3, unsigned long cr4)
 {
 unsigned long flags, old_cr4;
-u32 t;
+u32 t = 0;
 
 /* Throughout this function we make this assumption: */
 ASSERT(!(cr4 & X86_CR4_PCIDE) || !(cr4 & X86_CR4_PGE));
@@ -115,7 +120,8 @@ void switch_cr3_cr4(unsigned long cr3, unsigned long cr4)
 /* This non-reentrant function is sometimes called in interrupt context. */
 local_irq_save(flags);
 
-t = pre_flush();
+if ( tlb_clk_enabled )
+t = pre_flush();
 
 old_cr4 = read_cr4();
 ASSERT(!(old_cr4 & X86_CR4_PCIDE) || !(old_cr4 & X86_CR4_PGE));
@@ -167,7 +173,8 @@ void switch_cr3_cr4(unsigned long cr3, unsigned long cr4)
 if ( cr4 & X86_CR4_PCIDE )
 invpcid_flush_all_nonglobals();
 
-post_flush(t);
+if ( tlb_clk_enabled )
+post_flush(t);
 
 local_irq_restore(flags);
 }
diff --git a/xen/include/asm-x86/flushtlb.h b/xen/include/asm-x86/flushtlb.h
index 07f9bc6103..9773014320 100644
--- a/xen/include/asm-x86/flushtlb.h
+++ b/xen/include/asm-x86/flushtlb.h
@@ -21,10 +21,21 @@ extern u32 tlbflush_clock;
 /* Time at which each CPU's TLB was last flushed. */
 DECLARE_PER_CPU(u32, tlbflush_time);
 
-#define tlbflush_current_time() tlbflush_clock
+/* TLB clock is in use. */
+extern bool tlb_clk_enabled;
+
+static inline uint32_t tlbflush_current_time(void)
+{
+/* Returning 0 from tlbflush_current_time will always force a flush. */
+return tlb_clk_enabled ? tlbflush_clock : 0;
+}
 
 static inline void page_set_tlbflush_timestamp(struct page_info *page)
 {
+/* Avoid the write if the TLB clock is disabled. */
+if ( !tlb_clk_enabled )
+return;
+
 /*
  * Prevent storing a stale time stamp, which could happen if an update
  * to tlbflush_clock plus a subsequent flush IPI happen between the
@@ -67,6 +78,10 @@ static inline void tlbflush_filter(cpumask_t *mask, uint32_t 
page_timestamp)
 {
 unsigned int cpu;
 
+/* Short-circuit: there's no need to iterate if the clock is disabled. */
+if ( !tlb_clk_enabled )
+return;
+
 for_each_cpu ( cpu, mask )
 if ( !NEED_FLUSH(per_cpu(tlbflush_time, cpu), page_timestamp) )
 __cpumask_clear_cpu(cpu, mask);
-- 
2.25.0


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

[Xen-devel] [PATCH v3 2/7] x86/hvm: allow ASID flush when v != current

[Roger Pau Monne]

Current implementation of hvm_asid_flush_vcpu is not safe to use
unless the target vCPU is either paused or the currently running one,
as it modifies the generation without any locking.

Fix this by using atomic operations when accessing the generation
field, both in hvm_asid_flush_vcpu_asid and other ASID functions. This
allows to safely flush the current ASID generation. Note that for the
flush to take effect if the vCPU is currently running a vmexit is
required.

Note the same could be achieved by introducing an extra field to
hvm_vcpu_asid that signals hvm_asid_handle_vmenter the need to call
hvm_asid_flush_vcpu on the given vCPU before vmentry, this however
seems unnecessary as hvm_asid_flush_vcpu itself only sets two vCPU
fields to 0, so there's no need to delay this to the vmentry ASID
helper.

This is not a bugfix as no callers that would violate the assumptions
listed in the first paragraph have been found, but a preparatory
change in order to allow remote flushing of HVM vCPUs.

Signed-off-by: Roger Pau Monné 
---
 xen/arch/x86/hvm/asid.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/asid.c b/xen/arch/x86/hvm/asid.c
index 9d3c671a5f..80b73da89b 100644
--- a/xen/arch/x86/hvm/asid.c
+++ b/xen/arch/x86/hvm/asid.c
@@ -82,7 +82,7 @@ void hvm_asid_init(int nasids)
 
 void hvm_asid_flush_vcpu_asid(struct hvm_vcpu_asid *asid)
 {
-asid->generation = 0;
+write_atomic(>generation, 0);
 }
 
 void hvm_asid_flush_vcpu(struct vcpu *v)
@@ -120,7 +120,7 @@ bool_t hvm_asid_handle_vmenter(struct hvm_vcpu_asid *asid)
 goto disabled;
 
 /* Test if VCPU has valid ASID. */
-if ( asid->generation == data->core_asid_generation )
+if ( read_atomic(>generation) == data->core_asid_generation )
 return 0;
 
 /* If there are no free ASIDs, need to go to a new generation */
@@ -134,7 +134,7 @@ bool_t hvm_asid_handle_vmenter(struct hvm_vcpu_asid *asid)
 
 /* Now guaranteed to be a free ASID. */
 asid->asid = data->next_asid++;
-asid->generation = data->core_asid_generation;
+write_atomic(>generation, data->core_asid_generation);
 
 /*
  * When we assign ASID 1, flush all TLB entries as we are starting a new
-- 
2.25.0


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

[Xen-devel] [PATCH v3 0/7] x86: improve assisted tlb flush and use it in guest mode

[Roger Pau Monne]

Hello,

The following series aims to improve the TLB flush times when running
nested Xen, and it's specially beneficial when running in shim mode.

Only the HAP guest TLB flush is improved, the shadow paging TLB flush is
left as-is, and can be improved later if there's interest.

For a reference on the performance improvement see patch #7, as it's a
huge increase which can benefit other guests using assisted TLB flushes,
and also the ones using the viridian TLB flush assist (ie: Windows).

Thanks, Roger.

Roger Pau Monne (7):
  x86/tlb: fix NEED_FLUSH return type
  x86/hvm: allow ASID flush when v != current
  x86/paging: add TLB flush hooks
  x86/hap: improve hypervisor assisted guest TLB flush
  x86/tlb: introduce a flush guests TLB flag
  x86/tlb: allow disabling the TLB clock
  x86/tlb: use Xen L0 assisted TLB flush when available

 xen/arch/x86/flushtlb.c| 24 ++---
 xen/arch/x86/guest/hypervisor.c| 10 
 xen/arch/x86/guest/xen/xen.c   |  6 +++
 xen/arch/x86/hvm/asid.c|  6 +--
 xen/arch/x86/hvm/hvm.c | 51 ++
 xen/arch/x86/mm/hap/hap.c  | 48 +
 xen/arch/x86/mm/shadow/common.c| 71 +++---
 xen/arch/x86/mm/shadow/hvm.c   |  2 +-
 xen/arch/x86/mm/shadow/multi.c | 17 +++---
 xen/arch/x86/smp.c | 11 
 xen/include/asm-x86/flushtlb.h | 21 +++-
 xen/include/asm-x86/guest/hypervisor.h | 17 ++
 xen/include/asm-x86/hap.h  |  3 ++
 xen/include/asm-x86/shadow.h   | 12 +
 14 files changed, 220 insertions(+), 79 deletions(-)

-- 
2.25.0


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

[Xen-devel] [PATCH v3 3/7] x86/paging: add TLB flush hooks

[Roger Pau Monne]

Add shadow and hap implementation specific helpers to perform guest
TLB flushes. Note that the code for both is exactly the same at the
moment, and is copied from hvm_flush_vcpu_tlb. This will be changed by
further patches that will add implementation specific optimizations to
them.

No functional change intended.

Signed-off-by: Roger Pau Monné 
---
 xen/arch/x86/hvm/hvm.c  | 51 ++
 xen/arch/x86/mm/hap/hap.c   | 54 
 xen/arch/x86/mm/shadow/common.c | 55 +
 xen/arch/x86/mm/shadow/multi.c  |  1 -
 xen/include/asm-x86/hap.h   |  3 ++
 xen/include/asm-x86/shadow.h| 12 +++
 6 files changed, 127 insertions(+), 49 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 0b93609a82..96c419f0ef 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3986,55 +3986,10 @@ static void hvm_s3_resume(struct domain *d)
 bool hvm_flush_vcpu_tlb(bool (*flush_vcpu)(void *ctxt, struct vcpu *v),
 void *ctxt)
 {
-static DEFINE_PER_CPU(cpumask_t, flush_cpumask);
-cpumask_t *mask = _cpu(flush_cpumask);
-struct domain *d = current->domain;
-struct vcpu *v;
-
-/* Avoid deadlock if more than one vcpu tries this at the same time. */
-if ( !spin_trylock(>hypercall_deadlock_mutex) )
-return false;
-
-/* Pause all other vcpus. */
-for_each_vcpu ( d, v )
-if ( v != current && flush_vcpu(ctxt, v) )
-vcpu_pause_nosync(v);
-
-/* Now that all VCPUs are signalled to deschedule, we wait... */
-for_each_vcpu ( d, v )
-if ( v != current && flush_vcpu(ctxt, v) )
-while ( !vcpu_runnable(v) && v->is_running )
-cpu_relax();
-
-/* All other vcpus are paused, safe to unlock now. */
-spin_unlock(>hypercall_deadlock_mutex);
-
-cpumask_clear(mask);
-
-/* Flush paging-mode soft state (e.g., va->gfn cache; PAE PDPE cache). */
-for_each_vcpu ( d, v )
-{
-unsigned int cpu;
-
-if ( !flush_vcpu(ctxt, v) )
-continue;
-
-paging_update_cr3(v, false);
+struct domain *currd = current->domain;
 
-cpu = read_atomic(>dirty_cpu);
-if ( is_vcpu_dirty_cpu(cpu) )
-__cpumask_set_cpu(cpu, mask);
-}
-
-/* Flush TLBs on all CPUs with dirty vcpu state. */
-flush_tlb_mask(mask);
-
-/* Done. */
-for_each_vcpu ( d, v )
-if ( v != current && flush_vcpu(ctxt, v) )
-vcpu_unpause(v);
-
-return true;
+return shadow_mode_enabled(currd) ? shadow_flush_tlb(flush_vcpu, ctxt)
+  : hap_flush_tlb(flush_vcpu, ctxt);
 }
 
 static bool always_flush(void *ctxt, struct vcpu *v)
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 3d93f3451c..6894c1aa38 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -669,6 +669,60 @@ static void hap_update_cr3(struct vcpu *v, int do_locking, 
bool noflush)
 hvm_update_guest_cr3(v, noflush);
 }
 
+bool hap_flush_tlb(bool (*flush_vcpu)(void *ctxt, struct vcpu *v),
+   void *ctxt)
+{
+static DEFINE_PER_CPU(cpumask_t, flush_cpumask);
+cpumask_t *mask = _cpu(flush_cpumask);
+struct domain *d = current->domain;
+struct vcpu *v;
+
+/* Avoid deadlock if more than one vcpu tries this at the same time. */
+if ( !spin_trylock(>hypercall_deadlock_mutex) )
+return false;
+
+/* Pause all other vcpus. */
+for_each_vcpu ( d, v )
+if ( v != current && flush_vcpu(ctxt, v) )
+vcpu_pause_nosync(v);
+
+/* Now that all VCPUs are signalled to deschedule, we wait... */
+for_each_vcpu ( d, v )
+if ( v != current && flush_vcpu(ctxt, v) )
+while ( !vcpu_runnable(v) && v->is_running )
+cpu_relax();
+
+/* All other vcpus are paused, safe to unlock now. */
+spin_unlock(>hypercall_deadlock_mutex);
+
+cpumask_clear(mask);
+
+/* Flush paging-mode soft state (e.g., va->gfn cache; PAE PDPE cache). */
+for_each_vcpu ( d, v )
+{
+unsigned int cpu;
+
+if ( !flush_vcpu(ctxt, v) )
+continue;
+
+paging_update_cr3(v, false);
+
+cpu = read_atomic(>dirty_cpu);
+if ( is_vcpu_dirty_cpu(cpu) )
+__cpumask_set_cpu(cpu, mask);
+}
+
+/* Flush TLBs on all CPUs with dirty vcpu state. */
+flush_tlb_mask(mask);
+
+/* Done. */
+for_each_vcpu ( d, v )
+if ( v != current && flush_vcpu(ctxt, v) )
+vcpu_unpause(v);
+
+return true;
+}
+
 const struct paging_mode *
 hap_paging_get_mode(struct vcpu *v)
 {
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 6212ec2c4a..ee90e55b41 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -3357,6 +3357,61 @@ out:
 return rc;
 }
 
+/* Fluhs TLB of selected vCPUs. */

Re: [Xen-devel] [PATCH v3 8/8] RFC: Sketch constructors, DomainCreateNew

[George Dunlap]

On 1/24/20 7:32 PM, Nick Rosbrook wrote:
> Sorry for the late reply on this one.
> 
>> +func NewDomainConfig(t DomainType) (*DomainConfig, error) {
>> +   var cconfig C.libxl_domain_config
>> +
>> +   C.libxl_domain_config_init()
>> +   C.libxl_domain_build_info_init_type(_info, 
>> C.libxl_domain_type(t))
>> +
>> +   gconfig := {}
>> +   err := gconfig.fromC()
>> +   if err != nil {
>> +   return nil, err
>> +   }
>> +
>> +   return gconfig, nil
>> +}
> 
> I think this is sufficient for the "New" functions; simple is probably
> better here. I appreciate the idea of the `populate func` approach you
> mentioned in another email, but I think in practice people will want
> to leverage encoding/json or otherwise to unmarshal some data into a
> DomainConfig etc. Or, we would hopefully be able to unmarshal an
> xl.cfg. All that is to say, I think the approach you have shown here
> gives us and package users the most flexibility.

I think marshaling and unmarshalling should be fine, *as long as* the
structure being unmarshalled actually went through the
libxl__init() function first.

In fact, I was kicking around the idea of adding a non-exported field to
all the generated structs -- maybe "bool initalized" -- and having the
.fromC() methods set this to 'true', and the .toC() methods return an
error if it wasn't set.  But then we'd need to write custom JSON
marshallers to handle these.

I'm not personally very interested in parsing xl.cfg files, but libxl
has library functions to do that, so it should be something very easy to
add if you want.  (Although in fact, it looks like a lot of the code to
actually interpret the results of the parsing is in xl; we might want to
see about moving some of that functionality into libxlu.)

> If we stick with this outline for constructors, they will be easy to
> generate. I'm happy to work on that, unless you were already planning
> on it.

I'm afraid my 1 day a week of coding is going to have to be diverted to
something else for a month or so; so please go ahead if you have the time.

As far as further steps -- do you have a clear idea what kind of
functionality you'd like to see possible by the time of the feature
freeze (probably in May)?  Do you have plans to use these bindings
yourself, and if so, how?

For my part, I want to start and reap guests.  The latter will require
adding event callback functionality which will require more thought (and
perhaps expose more libxl issues).  But I don't yet have a clear target
beyond that.

Re function calls -- do we want to just manually duplicate them as
needed, or try to get some sort of IDL support?

Other work items include:

* modifying configure to detect the availability of go and enable the
bindings if it's available

* Enabling go build testing in the gitlab CI loop

* Making `go get` work, which might involve having code to push
post-generated code to a repo and tagging as appropriate

 -George

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

Re: [Xen-devel] [PATCH v5 2/7] x86: introduce a new set of APIs to manage Xen page tables

[Wei Liu]

On Mon, Jan 27, 2020 at 03:43:12PM +0100, Jan Beulich wrote:
> On 27.01.2020 15:33, Xia, Hongyan wrote:
> > On Thu, 2020-01-16 at 13:04 +0100, Jan Beulich wrote:
> >> ...
> >>
> >>> +void free_xen_pagetable(void *v)
> >>> +{
> >>> +mfn_t mfn = v ? virt_to_mfn(v) : INVALID_MFN;
> >>> +
> >>> +if ( system_state != SYS_STATE_early_boot )
> >>> +free_xen_pagetable_new(mfn);
> >>
> >> The condition is (partly) redundant with what
> >> free_xen_pagetable_new() does. Therefore I'd like to ask that
> >> either the if() be dropped here, or be completed by also
> >> checking v to be non-NULL, at which point this would likely
> >> become just
> >>
> >> void free_xen_pagetable(void *v)
> >> {
> >> if ( v && system_state != SYS_STATE_early_boot )
> >> free_xen_pagetable_new(virt_to_mfn(v));
> >> }
> > 
> > You are right. Will change in the next revision.
> > 
> >>> +/* v can point to an entry within a table or be NULL */
> >>> +void unmap_xen_pagetable(const void *v)
> >>
> >> Why "entry" in the comment?
> > 
> > I think the comment originally meant pointing to the entry in its
> > parent table, which then meant pointing to this table. It's a bit
> > confusing. Will reword.
> > 
> > Reflecting back to your comment in v3 about whether the new Xen page
> > table mapping APIs (map/unmap_xen_pagetable) are really necessary, I
> > agree in the end they will just do the same thing as
> > map/unmap_domain_page, although one thing is that the latter suggests
> > it is trying to map a `domain' page, whose definition probably does not
> > include Xen page tables, so the name could be a bit confusing (well, we
> > could argue that Xen page tables are just idle `domain' pages so the
> > name still holds). If we are happy with using map_domain_page on Xen
> > PTE tables then I am okay with dropping the new mapping APIs and only
> > include the new alloc APIs.
> 
> Anyone on the To: list - opinions?

I'm not too fussed about this.

I think eventually we will just change map_domain_page to map_page and
use that directly. The intermediate steps aren't terribly interesting to
me.

Wei.

> 
> Thanks, Jan

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

Re: [Xen-devel] [PATCH v5 2/7] x86: introduce a new set of APIs to manage Xen page tables

[Wei Liu]

On Thu, Jan 16, 2020 at 01:04:16PM +0100, Jan Beulich wrote:
[...]
> > +/* v can point to an entry within a table or be NULL */
> > +void unmap_xen_pagetable(const void *v)
> 
> Why "entry" in the comment?

IIRC there would be cases that umap_xen_pagetable would be called with a
pointer to a PTE.

The comment was mostly a note to remind me that when I got around
implementing that function it would need to do v_MASK.

This may or may not apply to this patch series in its current form.

Wei.

> 
> Jan

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

Re: [Xen-devel] [PATCH v2 2/2] x86/apic: simplify disconnect_bsp_APIC setup of LVT{0/1}

[Andrew Cooper]

On 27/01/2020 17:21, Roger Pau Monné wrote:
> On Mon, Jan 27, 2020 at 04:47:48PM +, Andrew Cooper wrote:
>> On 27/01/2020 16:43, Jan Beulich wrote:
>>> On 23.01.2020 19:06, Roger Pau Monne wrote:
 There's no need to read the current values of LVT{0/1} for the
 purposes of the function, which seem to be to save the currently
 selected vector: in the destination modes used (ExtINT and NMI) the
 vector field is ignored and hence can be set to 0.
>>> The question is - is there firmware putting data in these fields
>>> that it expects to survive unmodified? Such behavior would be
>>> highly suspect (to me at least), but you never know. There ought
>>> to be a reason it's been done this way not just in Xen, but also
>>> in Linux. IOW may I ask that you at least make an attempt to
>>> submit the same change for Linux, to see what the feedback is?
>> I can tell you what the Linux feedback will be.
>>
>> This is not a fastpath.  Always do RMW, because life is too short to
>> keep on unbreaking hardware which makes such assumptions.
> We already do such kinds of direct writes to LVT{0/1}, see
> clear_local_APIC where Xen clears the registers by directly writing
> APIC_LVT_MASKED to them (no RMW). As the modified code follows a call
> to clear_local_APIC there's nothing to preserve at this point.
>
> Note that init_bsp_APIC and smp_callin also call clear_local_APIC, so
> there's no data in those registers that could survive (regardless of
> my added call to clear_local_APIC in the previous patch).
>
> I'm not arguing this is correct (not sure it's incorrect either), but
> given how things are handled ATM it seems quite dumb to do a RMW in
> disconnect_bsp_APIC: it gives the false impression Xen is preserving
> something, when the register has already been wiped at startup.

The problem isn't with the currently defined fields (when we're trying
to clear them).  It is with implementations which depend on set reserved
bits not changing, and/or new fields defined at some future point.

If we already have a mix, then some more probably isn't a problem, but
you did ask what the Linux feedback would be...

~Andrew

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

Re: [Xen-devel] [PATCH v2 2/2] x86/apic: simplify disconnect_bsp_APIC setup of LVT{0/1}

[Roger Pau Monné]

On Mon, Jan 27, 2020 at 04:47:48PM +, Andrew Cooper wrote:
> On 27/01/2020 16:43, Jan Beulich wrote:
> > On 23.01.2020 19:06, Roger Pau Monne wrote:
> >> There's no need to read the current values of LVT{0/1} for the
> >> purposes of the function, which seem to be to save the currently
> >> selected vector: in the destination modes used (ExtINT and NMI) the
> >> vector field is ignored and hence can be set to 0.
> > The question is - is there firmware putting data in these fields
> > that it expects to survive unmodified? Such behavior would be
> > highly suspect (to me at least), but you never know. There ought
> > to be a reason it's been done this way not just in Xen, but also
> > in Linux. IOW may I ask that you at least make an attempt to
> > submit the same change for Linux, to see what the feedback is?
> 
> I can tell you what the Linux feedback will be.
> 
> This is not a fastpath.  Always do RMW, because life is too short to
> keep on unbreaking hardware which makes such assumptions.

We already do such kinds of direct writes to LVT{0/1}, see
clear_local_APIC where Xen clears the registers by directly writing
APIC_LVT_MASKED to them (no RMW). As the modified code follows a call
to clear_local_APIC there's nothing to preserve at this point.

Note that init_bsp_APIC and smp_callin also call clear_local_APIC, so
there's no data in those registers that could survive (regardless of
my added call to clear_local_APIC in the previous patch).

I'm not arguing this is correct (not sure it's incorrect either), but
given how things are handled ATM it seems quite dumb to do a RMW in
disconnect_bsp_APIC: it gives the false impression Xen is preserving
something, when the register has already been wiped at startup.

Thanks, Roger.

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

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

[osstest service owner]

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

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  1a3673da64822f52b50a3048dd7c5616573a9cd8
baseline version:
 xen  3c601c5f056fba055b7a1438b84b69fc649275c3

Last test of basis   146533  2020-01-27 12:00:48 Z0 days
Testing same since   146535  2020-01-27 15:00:43 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Doug Goldstein 

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-amd64pass
 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
   3c601c5f05..1a3673da64  1a3673da64822f52b50a3048dd7c5616573a9cd8 -> smoke

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

Re: [Xen-devel] [PATCH v5 2/7] x86: introduce a new set of APIs to manage Xen page tables

[George Dunlap]

On 1/27/20 3:07 PM, Xia, Hongyan wrote:
> On Mon, 2020-01-27 at 15:43 +0100, Jan Beulich wrote:
>> On 27.01.2020 15:33, Xia, Hongyan wrote:
>>> ...
>>>
>>> Reflecting back to your comment in v3 about whether the new Xen
>>> page
>>> table mapping APIs (map/unmap_xen_pagetable) are really necessary,
>>> I
>>> agree in the end they will just do the same thing as
>>> map/unmap_domain_page, although one thing is that the latter
>>> suggests
>>> it is trying to map a `domain' page, whose definition probably does
>>> not
>>> include Xen page tables, so the name could be a bit confusing
>>> (well, we
>>> could argue that Xen page tables are just idle `domain' pages so
>>> the
>>> name still holds). If we are happy with using map_domain_page on
>>> Xen
>>> PTE tables then I am okay with dropping the new mapping APIs and
>>> only
>>> include the new alloc APIs.
>>
>> Anyone on the To: list - opinions?
> 
> There is one argument. We already use map_domain_page on non-domain
> pages and outside the domheap. For example, the trap handler walks page
> tables and print traces via map_domain_page regardless of where the
> underlying page is from. The mapped page could just be from Xen.

Yes, I've long sort of mentally filtered out the 'domain' part of
"map_domain_page()"; it's really an artifact of a bygone era, when there
were separate xen and domain heaps.  (In fact, it's really "map domheap
page", and at the moment we only  have a domheap.)

It might be worth thinking about doing a global
s/map_domain_page/map_page/; but until then, I think it's fine to use
"map_domain_page" for "map pages in the domheap", given that there *is*
only the domheap.

 -George

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

Re: [Xen-devel] [PATCH resend] docs: add DIRECTORY_PART specification do xenstore protocol doc

[Durrant, Paul]

> -Original Message-
> From: Xen-devel  On Behalf Of
> Juergen Gross
> Sent: 27 January 2020 16:51
> To: xen-devel@lists.xenproject.org
> Cc: Juergen Gross ; Stefano Stabellini
> ; Julien Grall ; Wei Liu
> ; Konrad Rzeszutek Wilk ; George
> Dunlap ; Andrew Cooper
> ; Ian Jackson 
> Subject: [Xen-devel] [PATCH resend] docs: add DIRECTORY_PART specification
> do xenstore protocol doc
> 
> DIRECTORY_PART was missing in docs/misc/xenstore.txt. Add it.
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Paul Durrant 

> ---
>  docs/misc/xenstore.txt | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/docs/misc/xenstore.txt b/docs/misc/xenstore.txt
> index ae1b6a8c6e..65570183b6 100644
> --- a/docs/misc/xenstore.txt
> +++ b/docs/misc/xenstore.txt
> @@ -152,6 +152,15 @@ DIRECTORY|  leaf-name>|*
>   leafnames.  The resulting children are each named
>   /.
> 
> +DIRECTORY_PART   | | name>|*
> + Same as DIRECTORY, but to be used for children lists longer than
> + XENSTORE_PAYLOAD_MAX. Input are  and the byte offset into
> + the list of children to return. Return values are the generation
> + count  of the node (to be used to ensure the node hasn't
> + changed between two reads:  being the same for multiple
> + reads guarantees the node hasn't changed) and the list of children
> + starting at the specified  of the complete list.
> +
>  GET_PERMS| |+
>  SET_PERMS||+?
>is one of the following
> --
> 2.16.4
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] docs: Fix StudlyCaps in libxc-migration-stream.pandoc and xl.1.pod

[Durrant, Paul]

> -Original Message-
> From: Ian Jackson 
> Sent: 27 January 2020 16:46
> To: xen-devel@lists.xenproject.org
> Cc: Durrant, Paul ; Ian Jackson
> ; Wei Liu ; Andrew Cooper
> ; George Dunlap ;
> Jan Beulich ; Julien Grall ; Konrad
> Rzeszutek Wilk ; Stefano Stabellini
> 
> Subject: [PATCH] docs: Fix StudlyCaps in libxc-migration-stream.pandoc and
> xl.1.pod
> 
> $ git-grep libxenctrl | wc -l
> 99
> $ git-grep libxc | wc -l
> 206
> $ git-grep libxenlight | wc -l
> 48
> $ git-grep libxl | wc -l
> 13433
> $ git-grep LibXen | wc -l
> 2
> $
> 
> Reported-by: Paul Durrant 
> Signed-off-by: Ian Jackson 
> ---
>  docs/man/xl.1.pod.in | 2 +-
>  docs/specs/libxc-migration-stream.pandoc | 2 +-

What about docs/specs/libxl-migration-stream.pandoc? It could use a similar fix 
while you're at it.

  Paul

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

Re: [Xen-devel] [PATCH] docs: Fix StudlyCaps in libxc-migration-stream.pandoc and xl.1.pod

[Andrew Cooper]

On 27/01/2020 16:45, Ian Jackson wrote:
> $ git-grep libxenctrl | wc -l
> 99
> $ git-grep libxc | wc -l
> 206
> $ git-grep libxenlight | wc -l
> 48
> $ git-grep libxl | wc -l
> 13433
> $ git-grep LibXen | wc -l
> 2
> $
>
> Reported-by: Paul Durrant 
> Signed-off-by: Ian Jackson 

Acked-by: Andrew Cooper 

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

[Xen-devel] [PATCH resend] docs: add DIRECTORY_PART specification do xenstore protocol doc

[Juergen Gross]

DIRECTORY_PART was missing in docs/misc/xenstore.txt. Add it.

Signed-off-by: Juergen Gross 
---
 docs/misc/xenstore.txt | 9 +
 1 file changed, 9 insertions(+)

diff --git a/docs/misc/xenstore.txt b/docs/misc/xenstore.txt
index ae1b6a8c6e..65570183b6 100644
--- a/docs/misc/xenstore.txt
+++ b/docs/misc/xenstore.txt
@@ -152,6 +152,15 @@ DIRECTORY  | 
|*
leafnames.  The resulting children are each named
/.
 
+DIRECTORY_PART | ||*
+   Same as DIRECTORY, but to be used for children lists longer than
+   XENSTORE_PAYLOAD_MAX. Input are  and the byte offset into
+   the list of children to return. Return values are the generation
+   count  of the node (to be used to ensure the node hasn't
+   changed between two reads:  being the same for multiple
+   reads guarantees the node hasn't changed) and the list of children
+   starting at the specified  of the complete list.
+
 GET_PERMS  | |+
 SET_PERMS  ||+?
 is one of the following
-- 
2.16.4


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

Re: [Xen-devel] [PATCH v2 2/2] x86/apic: simplify disconnect_bsp_APIC setup of LVT{0/1}

[Andrew Cooper]

On 27/01/2020 16:43, Jan Beulich wrote:
> On 23.01.2020 19:06, Roger Pau Monne wrote:
>> There's no need to read the current values of LVT{0/1} for the
>> purposes of the function, which seem to be to save the currently
>> selected vector: in the destination modes used (ExtINT and NMI) the
>> vector field is ignored and hence can be set to 0.
> The question is - is there firmware putting data in these fields
> that it expects to survive unmodified? Such behavior would be
> highly suspect (to me at least), but you never know. There ought
> to be a reason it's been done this way not just in Xen, but also
> in Linux. IOW may I ask that you at least make an attempt to
> submit the same change for Linux, to see what the feedback is?

I can tell you what the Linux feedback will be.

This is not a fastpath.  Always do RMW, because life is too short to
keep on unbreaking hardware which makes such assumptions.

~Andrew

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

Re: [Xen-devel] [PATCH] docs/designs: Add a design document for transparent live migration

[Ian Jackson]

Paul Durrant writes ("[PATCH] docs/designs: Add a design document for 
transparent live migration"):
> It has become apparent to some large cloud providers that the current
> model of co-operative migration of guests under Xen is not usable as it
> places trust in software running inside the guest, which is likely
> beyond the provider's trust boundary.
> This patch introduces a proposal for a 'transparent' live migration,
> designed to overcome the need for this trust.

I have reviewed this and it seems like an accurate summary of the
situation, and a plausible proposal.  I wonder if some of the
existing-situation text could go into other documents.

I have some very minor comments.

I don't like the term `transparent'.  It is often abused in other
contexts.  It can be clear to whom things are transparent.  In a very
real sense existing migration is `transparent' to a domain's network
peers, for example.  How about `oblivious' ?

I don't think `trust' is right, either.  I think you mean `reliance'
or something.  `Trust' makes it sound like the guest can cause trouble
for the host.  Whereas the problem you are addressing here is that
the guest can cause trouble *for itself* by not operating the
migration protocols correctly.  This is an operational inconvenience,
but `trust' implies a security issue.

Ian.

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

[Xen-devel] [PATCH] docs: Fix StudlyCaps in libxc-migration-stream.pandoc and xl.1.pod

[Ian Jackson]

$ git-grep libxenctrl | wc -l
99
$ git-grep libxc | wc -l
206
$ git-grep libxenlight | wc -l
48
$ git-grep libxl | wc -l
13433
$ git-grep LibXen | wc -l
2
$

Reported-by: Paul Durrant 
Signed-off-by: Ian Jackson 
---
 docs/man/xl.1.pod.in | 2 +-
 docs/specs/libxc-migration-stream.pandoc | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in
index d4b5e8e362..33ad2ebd71 100644
--- a/docs/man/xl.1.pod.in
+++ b/docs/man/xl.1.pod.in
@@ -1,6 +1,6 @@
 =head1 NAME
 
-xl - Xen management tool, based on LibXenlight
+xl - Xen management tool, based on libxenlight
 
 =head1 SYNOPSIS
 
diff --git a/docs/specs/libxc-migration-stream.pandoc 
b/docs/specs/libxc-migration-stream.pandoc
index a7a8a08936..89705c9207 100644
--- a/docs/specs/libxc-migration-stream.pandoc
+++ b/docs/specs/libxc-migration-stream.pandoc
@@ -1,4 +1,4 @@
-% LibXenCtrl Domain Image Format
+% libxenctrl (libxc) Domain Image Format
 % David Vrabel <>
   Andrew Cooper <>
   Wen Congyang <>
-- 
2.11.0


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

Re: [Xen-devel] [PATCH v2 2/2] x86/apic: simplify disconnect_bsp_APIC setup of LVT{0/1}

[Jan Beulich]

On 23.01.2020 19:06, Roger Pau Monne wrote:
> There's no need to read the current values of LVT{0/1} for the
> purposes of the function, which seem to be to save the currently
> selected vector: in the destination modes used (ExtINT and NMI) the
> vector field is ignored and hence can be set to 0.

The question is - is there firmware putting data in these fields
that it expects to survive unmodified? Such behavior would be
highly suspect (to me at least), but you never know. There ought
to be a reason it's been done this way not just in Xen, but also
in Linux. IOW may I ask that you at least make an attempt to
submit the same change for Linux, to see what the feedback is?

Jan

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

Re: [Xen-devel] [PATCH v2 1/2] x86/apic: fix disabling LVT0 in disconnect_bsp_APIC

[Jan Beulich]

On 23.01.2020 19:06, Roger Pau Monne wrote:
> The Intel SDM states:
> 
> "When an illegal vector value (0 to 15) is written to a LVT entry and
> the delivery mode is Fixed (bits 8-11 equal 0), the APIC may signal an
> illegal vector error, without regard to whether the mask bit is set or
> whether an interrupt is actually seen on the input."
> 
> And that's exactly what's currently done in disconnect_bsp_APIC when
> virt_wire_setup is true and LVT LINT0 is being masked. By writing only
> APIC_LVT_MASKED Xen is actually setting the vector to 0 and the
> delivery mode to Fixed (0), and hence it triggers an APIC error even
> when the LVT entry is masked.
> 
> This would usually manifest when Xen is being shut down, as that's
> where disconnect_bsp_APIC is called:
> 
> (XEN) APIC error on CPU0: 40(00)
> 
> Fix this by calling clear_local_APIC prior to setting the LVT LINT
> registers which already clear LVT LINT0, and hence the troublesome
> write can be avoided as the register is already cleared.
> 
> Reported-by: Andrew Cooper 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Jan Beulich 

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

[Xen-devel] [PATCH] docs/designs: Add a design document for transparent live migration

[Paul Durrant]

It has become apparent to some large cloud providers that the current
model of co-operative migration of guests under Xen is not usable as it
places trust in software running inside the guest, which is likely
beyond the provider's trust boundary.
This patch introduces a proposal for a 'transparent' live migration,
designed to overcome the need for this trust.

Signed-off-by: Paul Durrant 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Wei Liu 
---
 docs/designs/transparent-migration.md | 266 ++
 1 file changed, 266 insertions(+)
 create mode 100644 docs/designs/transparent-migration.md

diff --git a/docs/designs/transparent-migration.md 
b/docs/designs/transparent-migration.md
new file mode 100644
index 00..9f26d4da6d
--- /dev/null
+++ b/docs/designs/transparent-migration.md
@@ -0,0 +1,266 @@
+# Transparent Migration of Guests on Xen
+
+## Background
+
+The term **transparent migration** needs qualification. Here it is taken to
+mean migration of a guest without the co-operation of software running inside
+that guest. It is not taken to mean that a guest, aware that it is virtualized
+under Xen, is not going to see *any* changes across a migration but no part of
+migration should require any explicit action by the guest (including re-reading
+any state that it may have cached).
+
+The normal model of migration in Xen is driven by the guest because it was
+originally implemented for PV guests, where the guest must be aware it is
+running under Xen and is hence expected to co-operate. This model dates from
+an era when it was assumed that the host administrator had control of at least
+the privileged software running in the guest (i.e. the guest kernel) which may
+still be true in an enterprise deployment but is not generally true in a cloud
+environment. The aim of transparent migration is to provide a model which is
+purely host driven, requiring no co-operation from or trust in the software
+running in the guest, and is thus suitable for cloud scenarios.
+
+PV guests are out of scope for this project because, as is outlined above, they
+have a symbiotic relationship with the hypervisor and therefore a certain level
+of co-operation can be assumed.
+HVM guests can already be migrated on Xen without guest co-operation but only
+if they don’t have PV drivers installed[1] or are in power state S3. The
+reason for not expecting co-operation if the guest is in S3 is obvious, but the
+reason co-operation is expected if PV drivers are installed is due to the
+nature of PV protocols.
+
+## Xenstore Nodes and Domain ID
+
+The PV driver model consists of a *frontend* and a *backend*. The frontend runs
+inside the guest domain and the backend runs inside a *service domain* which
+may or may not domain 0. The frontend and backend typically pass data via
+memory pages which are shared between the two domains, but this channel of
+communication is generally established using xenstore (the store protocol
+itself being an exception to this for obvious chicken-and-egg reasons).
+
+Typical protocol establishment is based on use of two separate xenstore
+*areas*. If we consider PV drivers for the *netif* protocol (i.e. class vif)
+and assume the guest has domid X, the service domain has domid Y, and the vif
+has index Z then the frontend area will reside under the parent node:
+
+`/local/domain/Y/device/vif/Z`
+
+All backends, by convention, typically reside under parent node:
+
+`/local/domain/X/backend`
+
+and the normal backend area for vif Z would be:
+
+`/local/domain/X/backend/vif/Y/Z`
+
+but this should not be assumed.
+
+The toolstack will place two nodes in the frontend area to explicitly locate
+the backend:
+
+* `backend`: the fully qualified xenstore path of the backend area
+* `backend-id`: the domid of the service domain
+
+and similarly two nodes in the backend area to locate the frontend area:
+
+* `frontend`: the fully qualified xenstore path of the frontend area
+* `frontend-id`: the domid of the guest domain
+
+
+The guest domain only has write permission to the frontend area and similarly
+the service domain only has write permission to the backend area, but both ends
+have read permission to both areas.
+
+Under both frontend and backend areas is a node called *state*. This is key to
+protocol establishment. Upon PV device creation the toolstack will set the
+value of both state nodes to 1 (XenbusStateInitialising[2]). This should cause
+enumeration of appropriate devices in both the guest and service domains. The
+backend device, once it has written any necessary protocol specific information
+into the xenstore backend area (to be read by the frontend driver) will update
+the backend state node to 2 (XenbusStateInitWait). From this point on PV
+protocols differ slightly; the following illustration is true of the netif
+protocol.
+Upon seeing a backend 

Re: [Xen-devel] [PATCH v3 00/10] libxl: event: Fix hang for some applications

[Ian Jackson]

Ian Jackson writes ("[PATCH v3 00/10] libxl: event: Fix hang for some 
applications"):
> The meat here, including a description of the bug, is in:
>   libxl: event: Fix hang when mixing blocking and eventy calls
> 
> This is all now Reviewed-by and Tested-by George, so it is ready to be
> committed.  But I will be away for a bit soon and reverting something
> of this form is probably undesirable.  So I will commit this in
> something over a week (assuming no further comments arise).
> 
> The changes here from v2 are only to two of the commit messages
> (marked m in the list below).
> 
> I am not sure whether this series is a backport candidate.  It is not
> impossible that the bug we are fixing here is affecting (say) libvirt.
> But if so presumably not in a significant way as we haven't seen
> reports.  So even though this is a bugfix, I'm sceptical.

I have pushed this now.

Ian.

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

Re: [Xen-devel] [PATCH] docs: retrospectively add XS_DIRECTORY_PART to the xenstore protocol...

[Durrant, Paul]

> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@citrix.com]
> Sent: 27 January 2020 15:49
> To: Jürgen Groß 
> Cc: Durrant, Paul ; xen-devel@lists.xenproject.org;
> Andrew Cooper ; George Dunlap
> ; Jan Beulich ; Julien Grall
> ; Konrad Rzeszutek Wilk ; Stefano
> Stabellini ; Wei Liu 
> Subject: Re: [PATCH] docs: retrospectively add XS_DIRECTORY_PART to the
> xenstore protocol...
> 
> Jürgen Groß writes ("Re: [PATCH] docs: retrospectively add
> XS_DIRECTORY_PART to the xenstore protocol..."):
> > On 27.01.20 16:33, Ian Jackson wrote:
> > > Paul Durrant writes ("[PATCH] docs: retrospectively add
> XS_DIRECTORY_PART to the xenstore protocol..."):
> > >> ... specification.
> > >>
> > >> This was added by commit 0ca64ed8 "xenstore: add support for
> > >> reading directory with many children" but not added to the
> > >> specification at that point. A version of xenstored supporting the
> > >> command was first released in Xen 4.9.
> > >
> > > Thanks for documenting this.  A docs fix like this should be
> > > backported if it applies, IMO.
> > >
> > > Acked-by: Ian Jackson 
> > > Backport: 4.9+
> > >
> > > I will commit it to staging momentarily.
> > >
> > >> +DIRECTORY_PART  | |*
> > >> +Performs the same function as DIRECTORY, but returns a
> > >> +sub-list of children starting at  in the overall
> > >> +child list and less than or equal to XENSTORE_PAYLOAD_MAX
> > >> +octets in length. If  is beyond the end of the
> > >> +overall child list then the returned sub-list will be
> > >> +empty.
> > >
> > > I wonder if it should be somehow made more explicit that `index' is
> > > a count of directory entries, not bytes.  Maybe this is obvious.
> >
> > But this is wrong. It is bytes, and the generation count returned is
> > missing (see my original patch back in 2017).
> 
> Sorry for being too quick.  I have reverted my commit.
> 

Since I got it wrong, I suggest just taking Juergen's original text (which I 
was unaware of before). It seems ok to me.

  Paul

> Ian.

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

Re: [Xen-devel] [PATCH v2 16/17] tools/libxc: Restore CPUID/MSR data found in the migration stream

[Andrew Cooper]

On 27/01/2020 14:51, Jan Beulich wrote:
> On 27.01.2020 15:34, Andrew Cooper wrote:
>> With all other pieces in place, it is now safe to restore the CPUID and MSR
>> data in the migration stream, rather than discarding them and using the 
>> higher
>> level toolstacks compatibility logic.
>>
>> While this is a small patch, it has large implications for migrated/resumed
>> domains.  Most obviously, the CPU family/model/stepping data,
>> cache/tlb/etc. will no longer change behind the guests back.
>>
>> Another change is the interpretation of the Xend cpuid strings.  The 'k'
>> option is not a sensible thing to have ever supported, and 's' is how how the
>> stream will end up behaving.
> I'm a little confused I guess - I'd have expected such a description
> to mean that ...
>
>> --- a/tools/libxc/xc_cpuid_x86.c
>> +++ b/tools/libxc/xc_cpuid_x86.c
>> @@ -291,10 +291,9 @@ int xc_set_domain_cpu_policy(xc_interface *xch, 
>> uint32_t domid,
>>   *   '0' -> force to 0
>>   *   'x' -> we don't care (use default)
>>   *   'k' -> pass through host value
>> - *   's' -> pass through the first time and then keep the same value
>> - *  across save/restore and migration.
>> + *   's' -> legacy alias for 'k'
> ... 's' remains documented as is, and 'k' to become a legacy alias.

Given that s has never worked in the past, k is the only plausible one
used by people.

As they mean the same now, we could specify it either way around, but
this way round gives users less work to do.

~Andrew

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

Re: [Xen-devel] [PATCH] docs: retrospectively add XS_DIRECTORY_PART to the xenstore protocol...

[Ian Jackson]

Jürgen Groß writes ("Re: [PATCH] docs: retrospectively add XS_DIRECTORY_PART to 
the xenstore protocol..."):
> On 27.01.20 16:33, Ian Jackson wrote:
> > Paul Durrant writes ("[PATCH] docs: retrospectively add XS_DIRECTORY_PART 
> > to the xenstore protocol..."):
> >> ... specification.
> >>
> >> This was added by commit 0ca64ed8 "xenstore: add support for reading
> >> directory with many children" but not added to the specification at that
> >> point. A version of xenstored supporting the command was first released
> >> in Xen 4.9.
> > 
> > Thanks for documenting this.  A docs fix like this should be
> > backported if it applies, IMO.
> > 
> > Acked-by: Ian Jackson 
> > Backport: 4.9+
> > 
> > I will commit it to staging momentarily.
> > 
> >> +DIRECTORY_PART| |*
> >> +  Performs the same function as DIRECTORY, but returns a
> >> +  sub-list of children starting at  in the overall
> >> +  child list and less than or equal to XENSTORE_PAYLOAD_MAX
> >> +  octets in length. If  is beyond the end of the
> >> +  overall child list then the returned sub-list will be
> >> +  empty.
> > 
> > I wonder if it should be somehow made more explicit that `index' is a
> > count of directory entries, not bytes.  Maybe this is obvious.
> 
> But this is wrong. It is bytes, and the generation count returned is
> missing (see my original patch back in 2017).

Sorry for being too quick.  I have reverted my commit.

Ian.

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  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-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 

Re: [Xen-devel] [PATCH] docs: retrospectively add XS_DIRECTORY_PART to the xenstore protocol...

[Jürgen Groß]

On 27.01.20 16:33, Ian Jackson wrote:

Paul Durrant writes ("[PATCH] docs: retrospectively add XS_DIRECTORY_PART to the 
xenstore protocol..."):

... specification.

This was added by commit 0ca64ed8 "xenstore: add support for reading
directory with many children" but not added to the specification at that
point. A version of xenstored supporting the command was first released
in Xen 4.9.


Thanks for documenting this.  A docs fix like this should be
backported if it applies, IMO.

Acked-by: Ian Jackson 
Backport: 4.9+

I will commit it to staging momentarily.


+DIRECTORY_PART | |*
+   Performs the same function as DIRECTORY, but returns a
+   sub-list of children starting at  in the overall
+   child list and less than or equal to XENSTORE_PAYLOAD_MAX
+   octets in length. If  is beyond the end of the
+   overall child list then the returned sub-list will be
+   empty.


I wonder if it should be somehow made more explicit that `index' is a
count of directory entries, not bytes.  Maybe this is obvious.


But this is wrong. It is bytes, and the generation count returned is
missing (see my original patch back in 2017).


Juergen


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

Re: [Xen-devel] [PATCH] docs: retrospectively add XS_DIRECTORY_PART to the xenstore protocol...

[Ian Jackson]

Paul Durrant writes ("[PATCH] docs: retrospectively add XS_DIRECTORY_PART to 
the xenstore protocol..."):
> ... specification.
> 
> This was added by commit 0ca64ed8 "xenstore: add support for reading
> directory with many children" but not added to the specification at that
> point. A version of xenstored supporting the command was first released
> in Xen 4.9.

Thanks for documenting this.  A docs fix like this should be
backported if it applies, IMO.

Acked-by: Ian Jackson 
Backport: 4.9+

I will commit it to staging momentarily.

> +DIRECTORY_PART   | |*
> + Performs the same function as DIRECTORY, but returns a
> + sub-list of children starting at  in the overall
> + child list and less than or equal to XENSTORE_PAYLOAD_MAX
> + octets in length. If  is beyond the end of the
> + overall child list then the returned sub-list will be
> + empty.

I wonder if it should be somehow made more explicit that `index' is a
count of directory entries, not bytes.  Maybe this is obvious.

Ian.

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

Re: [Xen-devel] [PATCH] docs: retrospectively add XS_DIRECTORY_PART to the xenstore protocol...

[Jürgen Groß]

On 27.01.20 16:19, Paul Durrant wrote:

... specification.

This was added by commit 0ca64ed8 "xenstore: add support for reading
directory with many children" but not added to the specification at that
point. A version of xenstored supporting the command was first released
in Xen 4.9.

Signed-off-by: Paul Durrant 
---
Cc: Juergen Gross 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Wei Liu 
---
  docs/misc/xenstore.txt | 13 +++--
  1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/docs/misc/xenstore.txt b/docs/misc/xenstore.txt
index ae1b6a8c6e..bf42e9ec37 100644
--- a/docs/misc/xenstore.txt
+++ b/docs/misc/xenstore.txt
@@ -125,8 +125,9 @@ Values commonly included in payloads include:
  
  
  
-The following are the actual type values, including the request and

-reply payloads as applicable:
+The following are the actual type values defined in io/xs_wire.h
+(omitting the XS_ prefix), including the request and reply payloads
+as applicable:
  
  
  -- Database read, write and permissions operations --

@@ -152,6 +153,14 @@ DIRECTORY  |   
|*
leafnames.  The resulting children are each named
/.
  
+DIRECTORY_PART		|		|*

+   Performs the same function as DIRECTORY, but returns a
+   sub-list of children starting at  in the overall
+   child list and less than or equal to XENSTORE_PAYLOAD_MAX
+   octets in length. If  is beyond the end of the
+   overall child list then the returned sub-list will be
+   empty.
+


Hmm, not quite.

I did send this some years ago:

https://lists.xen.org/archives/html/xen-devel/2017-05/msg00650.html

Ian wanted to suggest something better, but he never did.


Juergen

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

[Xen-devel] [PATCH] docs: retrospectively add XS_DIRECTORY_PART to the xenstore protocol...

[Paul Durrant]

... specification.

This was added by commit 0ca64ed8 "xenstore: add support for reading
directory with many children" but not added to the specification at that
point. A version of xenstored supporting the command was first released
in Xen 4.9.

Signed-off-by: Paul Durrant 
---
Cc: Juergen Gross 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Wei Liu 
---
 docs/misc/xenstore.txt | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/docs/misc/xenstore.txt b/docs/misc/xenstore.txt
index ae1b6a8c6e..bf42e9ec37 100644
--- a/docs/misc/xenstore.txt
+++ b/docs/misc/xenstore.txt
@@ -125,8 +125,9 @@ Values commonly included in payloads include:
 
 
 
-The following are the actual type values, including the request and
-reply payloads as applicable:
+The following are the actual type values defined in io/xs_wire.h
+(omitting the XS_ prefix), including the request and reply payloads
+as applicable:
 
 
 -- Database read, write and permissions operations --
@@ -152,6 +153,14 @@ DIRECTORY  | 
|*
leafnames.  The resulting children are each named
/.
 
+DIRECTORY_PART | |*
+   Performs the same function as DIRECTORY, but returns a
+   sub-list of children starting at  in the overall
+   child list and less than or equal to XENSTORE_PAYLOAD_MAX
+   octets in length. If  is beyond the end of the
+   overall child list then the returned sub-list will be
+   empty.
+
 GET_PERMS  | |+
 SET_PERMS  ||+?
 is one of the following
-- 
2.20.1


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

Re: [Xen-devel] [Vote] For Xen Project Code of Conduct (deadline March 31st)

[Ian Jackson]

Lars Kurth writes ("[Vote] For Xen Project Code of Conduct (deadline March 
31st)"):
> People allowed to vote on behalf of the Hypervisor project are:
> Julien Grall, Andy Cooper, George Dunlap, Ian Jackson, Jan Beulich, Konrad R
> Wilk, Stefano Stabellini, Wei Liu and Paul Durrant (as Release Manager).

+1

Ian.

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

Re: [Xen-devel] [PATCH v5 2/7] x86: introduce a new set of APIs to manage Xen page tables

[Xia, Hongyan]

On Mon, 2020-01-27 at 15:43 +0100, Jan Beulich wrote:
> On 27.01.2020 15:33, Xia, Hongyan wrote:
> > ...
> > 
> > Reflecting back to your comment in v3 about whether the new Xen
> > page
> > table mapping APIs (map/unmap_xen_pagetable) are really necessary,
> > I
> > agree in the end they will just do the same thing as
> > map/unmap_domain_page, although one thing is that the latter
> > suggests
> > it is trying to map a `domain' page, whose definition probably does
> > not
> > include Xen page tables, so the name could be a bit confusing
> > (well, we
> > could argue that Xen page tables are just idle `domain' pages so
> > the
> > name still holds). If we are happy with using map_domain_page on
> > Xen
> > PTE tables then I am okay with dropping the new mapping APIs and
> > only
> > include the new alloc APIs.
> 
> Anyone on the To: list - opinions?

There is one argument. We already use map_domain_page on non-domain
pages and outside the domheap. For example, the trap handler walks page
tables and print traces via map_domain_page regardless of where the
underlying page is from. The mapped page could just be from Xen.

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

Re: [Xen-devel] Linux 5.5 fails to boot in VM

[Ilpo Järvinen]

On Mon, 27 Jan 2020, Jürgen Groß wrote:

> On 27.01.20 14:16, Ilpo Järvinen wrote:
> > Hi,
> > 
> > I've noted that 5.5-rcs and now 5.5-based kernel fails to boot in VM.
> > 5.4 based kernels worked fine and there seems to have been some changes in
> > drivers/xen post-5.4 so perhaps they broke something?
> 
> I can't reproduce your problem. Just booted a VM with kernel 5.5 as
> PV- and as HVM-guest without any problems.

Thanks. The VM in question is using PVH (but I don't know enough to know 
if that makes any difference).

> You seem to use qubes. Maybe you should start asking there?

Yes, I'm using qubes and I actually first send an email there asking 
whether I should escalate it to xen-devel.

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

Re: [Xen-devel] [PATCH] xen/x86: domctl: Don't leak data via XEN_DOMCTL_gethvmcontext

[Jan Beulich]

On 27.01.2020 14:48, Julien Grall wrote:
> From: Julien Grall 
> 
> The HVM context may not fill up the full buffer passed by the caller.
> While we report corectly the size of the context, we will still be
> copying back the full size of the buffer.
> 
> As the buffer is allocated through xmalloc(), we will be copying some
> bits from the previous allocation.
> 
> Only copy back the part of the buffer used by the HVM context to prevent
> any leak.
> 
> Note that per XSA-72, this is not a security issue.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Jan Beulich 

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

Re: [Xen-devel] PVH PCI passthrough for DomUs

[Roger Pau Monné]

Forgot to set 'To:' correctly.

On Mon, Jan 27, 2020 at 03:28:36PM +0100, Roger Pau Monné wrote:
> On Mon, Jan 27, 2020 at 12:27:18PM +, Wei Liu wrote:
> > Cc Roger
> 
> Thanks :).
> 
> > On Sun, Jan 19, 2020 at 11:30:42PM -0800, Roman Shaposhnik wrote:
> > > Hi!
> > > 
> > > I've just tried this with Xen 4.13.0 and it seems like that is still
> > > not supported.
> 
> No, there hasn't been much progress on this sadly.
> 
> > > This makes me curious if anybody is working on this and whether
> > > there's anything we can do to help accelerate the effort.
> 
> The first step would be to get vPCI hooked into the ioreq machinery,
> so that a domain can have devices on the emulated PCI bus handled by
> vPCI while others are handled by external ioreq emulators. I've posted
> a v3 of this work on September:
> 
> https://lists.xenproject.org/archives/html/xen-devel/2019-09/msg03278.html
> 
> But I haven't got time to go over the comments and post a new version.
> 
> Once that's done the remaining step would be to make vPCI safe for
> unprivileged guests. We need to assure that guests can only write to
> specific bits of the config space, and need to limit the capabilities
> that are exposed to the ones Xen knows to be safe to handle. This can
> be worked by multiple people concurrently IMO, but requires step 1
> (integration with ioreq) to be finished first.
> 
> I'm more than happy for someone to pick any of those tasks, including
> the integration of vPCI with the ioreq machinery. If not, I expect I
> will be able to do some work on this in a couple of weeks, but that
> depends on nothing else getting on fire, and me being able to flush my
> queue of pending patches.
> 
> Would you be up to pick some of these tasks?
> 
> I can try to speedup the vPCI ioreq integration if there's people
> willing to work on the remaining steps, I haven't done so because I
> didn't see much interest in general, and I was expecting to be the
> only one working on the remaining steps anyway.
> 
> Regards, Roger.
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

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

[Xen-devel] [linux-5.4 test] 146530: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 146121
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 
146121
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 
146121

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-rtds   16 guest-localmigrate fail in 146523 pass in 146530
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail in 146523 
pass in 146530
 test-amd64-amd64-xl-credit1  23 leak-check/check   fail pass in 146523

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10   fail REGR. vs. 146121
 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 146121

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-pvshim12 guest-start  fail   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-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  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-arm64-arm64-xl-credit2  13 migrate-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-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-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-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail 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-libvirt 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-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 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-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail 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-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 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-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 

Re: [Xen-devel] [PATCH v2 16/17] tools/libxc: Restore CPUID/MSR data found in the migration stream

[Jan Beulich]

On 27.01.2020 15:34, Andrew Cooper wrote:
> With all other pieces in place, it is now safe to restore the CPUID and MSR
> data in the migration stream, rather than discarding them and using the higher
> level toolstacks compatibility logic.
> 
> While this is a small patch, it has large implications for migrated/resumed
> domains.  Most obviously, the CPU family/model/stepping data,
> cache/tlb/etc. will no longer change behind the guests back.
> 
> Another change is the interpretation of the Xend cpuid strings.  The 'k'
> option is not a sensible thing to have ever supported, and 's' is how how the
> stream will end up behaving.

I'm a little confused I guess - I'd have expected such a description
to mean that ...

> --- a/tools/libxc/xc_cpuid_x86.c
> +++ b/tools/libxc/xc_cpuid_x86.c
> @@ -291,10 +291,9 @@ int xc_set_domain_cpu_policy(xc_interface *xch, uint32_t 
> domid,
>   *   '0' -> force to 0
>   *   'x' -> we don't care (use default)
>   *   'k' -> pass through host value
> - *   's' -> pass through the first time and then keep the same value
> - *  across save/restore and migration.
> + *   's' -> legacy alias for 'k'

... 's' remains documented as is, and 'k' to become a legacy alias.

Jan

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

[Xen-devel] [ovmf test] 146531: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 
145767

version targeted for testing:
 ovmf c8b8157e126ae2fb6f65842677251d300ceff104
baseline version:
 ovmf 70911f1f4aee0366b6122f2b90d367ec0f066beb

Last test of basis   145767  2020-01-08 00:39:09 Z   19 days
Failing since145774  2020-01-08 02:50:20 Z   19 days   74 attempts
Testing same since   146482  2020-01-24 19:39:39 Z2 days   13 attempts


People who touched revisions under test:
  Aaron Li 
  Albecki, Mateusz 
  Ard Biesheuvel 
  Ashish Singhal 
  Bob Feng 
  Brian R Haug 
  Eric Dong 
  Fan, ZhijuX 
  Hao A Wu 
  Jason Voelz 
  Jian J Wang 
  Krzysztof Koch 
  Laszlo Ersek 
  Leif Lindholm 
  Li, Aaron 
  Liming Gao 
  Mateusz Albecki 
  Michael D Kinney 
  Michael Kubacki 
  Pavana.K 
  Philippe Mathieu-Daud? 
  Philippe Mathieu-Daude 
  Siyuan Fu 
  Siyuan, Fu 
  Sudipto Paul 
  Vitaly Cheptsov 
  Vitaly Cheptsov via Groups.Io 
  Wei6 Xu 
  Xu, Wei6 
  Zhiguang Liu 
  Zhiju.Fan 

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 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] Linux 5.5 fails to boot in VM

[Jürgen Groß]

On 27.01.20 14:16, Ilpo Järvinen wrote:

Hi,

I've noted that 5.5-rcs and now 5.5-based kernel fails to boot in VM.
5.4 based kernels worked fine and there seems to have been some changes in
drivers/xen post-5.4 so perhaps they broke something?


I can't reproduce your problem. Just booted a VM with kernel 5.5 as
PV- and as HVM-guest without any problems.

You seem to use qubes. Maybe you should start asking there?


Juergen




Loading Linux 5.5.0-accecn30 ...

.[5;22H  [ initrd.img-5.5.0-acc  16.52MiB  100%  10.23MiB/s ].[5;1HSetting 
up swapspace version 1, size = 1073737728 bytes
/dev/xvda3: clean, 852118/1294896 files, 3076785/5190907 blocks
[2.730931] BUG: kernel NULL pointer dereference, address: 03b0
[2.730959] #PF: supervisor read access in kernel mode
[2.730966] #PF: error_code(0x) - not-present page
[2.730973] PGD 0 P4D 0
[2.730978] Oops:  [#1] SMP PTI
[2.730985] CPU: 1 PID: 402 Comm: qubesdb-daemon Tainted: G   O  
5.5.0-accecn30 #31
[2.731000] RIP: 0010:mmu_interval_read_begin+0x24/0xc0
[2.731008] Code: e9 51 66 e1 ff 90 0f 1f 44 00 00 41 54 49 89 fc 55 53 48 83 ec 
30 65 48 8b 04 25 28 00 00 00 48 89 44 24 28 31 c0 48 8b 47 38 <48> 8b a8 b0 03 
00 00 48 8d 5d 0c 48 89 df e8 49 27 6f 00 4d 8b 64
[2.731030] RSP: 0018:9873001e7d20 EFLAGS: 00010246
[2.731037] RAX:  RBX: 8a4e94712500 RCX: 
[2.731047] RDX: 8a4ef53add00 RSI:  RDI: 8a4e94712500
[2.731057] RBP: 8a4e0bf7a640 R08: 7bc5c0573000 R09: 0008
[2.731066] R10: 8a4ec756c190 R11: 7bc5c05a2000 R12: 8a4e94712500
[2.731076] R13: 8a4ed3ab9d50 R14:  R15: 0001
[2.731086] FS:  7bc5c00dc7c0() GS:8a4ef5d0() 
knlGS:
[2.731097] CS:  0010 DS:  ES:  CR0: 80050033
[2.731105] CR2: 03b0 CR3: 8148e004 CR4: 003606e0
[2.731116] Call Trace:
[2.731123]  ? vma_merge+0xef/0x370
[2.731132]  gntdev_mmap+0x153/0x30e [xen_gntdev]
[2.731139]  mmap_region+0x3d9/0x660
[2.731146]  do_mmap+0x372/0x520
[2.731153]  vm_mmap_pgoff+0xd2/0x120
[2.731160]  ksys_mmap_pgoff+0x1b8/0x270
[2.731167]  ? ksys_ioctl+0x60/0x90
[2.731174]  do_syscall_64+0x5b/0x180
[2.731182]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[2.731191] RIP: 0033:0x7bc5c03e8133
[2.731196] Code: 54 41 89 d4 55 48 89 fd 53 4c 89 cb 48 85 ff 74 56 49 89 d9 45 
89 f8 45 89 f2 44 89 e2 4c 89 ee 48 89 ef b8 09 00 00 00 0f 05 <48> 3d 00 f0 ff 
ff 77 7d 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 2e 0f
[2.731219] RSP: 002b:7ffcbccc89b8 EFLAGS: 0246 ORIG_RAX: 
0009
[2.731230] RAX: ffda RBX:  RCX: 7bc5c03e8133
[2.731243] RDX: 0003 RSI: 1000 RDI: 
[2.731252] RBP:  R08: 0007 R09: 
[2.731263] R10: 0001 R11: 0246 R12: 0003
[2.731273] R13: 1000 R14: 0001 R15: 0007
[2.731284] Modules linked in: xen_netback u2mfn(O) xen_gntdev xen_gntalloc 
xen_blkback xen_evtchn parport_pc ppdev xenfs xen_privcmd lp parport ip_tables 
xen_netfront xen_blkfront crc32c_intel
[2.731309] CR2: 03b0
[2.731315] fbcon: Taking over console
[2.731321] ---[ end trace 5ec57aa3f3a40247 ]---
[2.731329] RIP: 0010:mmu_interval_read_begin+0x24/0xc0
[2.731336] Code: e9 51 66 e1 ff 90 0f 1f 44 00 00 41 54 49 89 fc 55 53 48 83 ec 
30 65 48 8b 04 25 28 00 00 00 48 89 44 24 28 31 c0 48 8b 47 38 <48> 8b a8 b0 03 
00 00 48 8d 5d 0c 48 89 df e8 49 27 6f 00 4d 8b 64
[2.731358] RSP: 0018:9873001e7d20 EFLAGS: 00010246
[2.731365] RAX:  RBX: 8a4e94712500 RCX: 
[2.731375] RDX: 8a4ef53add00 RSI:  RDI: 8a4e94712500
[2.731385] RBP: 8a4e0bf7a640 R08: 7bc5c0573000 R09: 0008
[2.731395] R10: 8a4ec756c190 R11: 7bc5c05a2000 R12: 8a4e94712500
[2.731405] R13: 8a4ed3ab9d50 R14:  R15: 0001
[2.731415] FS:  7bc5c00dc7c0() GS:8a4ef5d0() 
knlGS:
[2.731427] CS:  0010 DS:  ES:  CR0: 80050033
[2.731436] CR2: 03b0 CR3: 8148e004 CR4: 003606e0
[2.731446] Kernel panic - not syncing: Fatal exception
[2.731527] Kernel Offset: 0x2a00 from 0x8100 (relocation 
range: 0x8000-0xbfff)

--
  i.

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




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

Re: [Xen-devel] [XEN PATCH 0/3] Default to python3

[Wei Liu]

On Mon, Jan 27, 2020 at 02:40:40PM +, Wei Liu wrote:
> On Mon, Jan 27, 2020 at 12:36:23PM +, Anthony PERARD wrote:
> > On Mon, Jan 27, 2020 at 12:30:21PM +, Wei Liu wrote:
> > > On Mon, Jan 20, 2020 at 11:52:17AM +, Anthony PERARD wrote:
> > > > On Mon, Jan 20, 2020 at 11:50:50AM +, Anthony PERARD wrote:
> > > > > Patch series available in this git branch:
> > > > > https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git 
> > > > > br.python3-default-v1
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > I think it's time for Xen to build with python3 by default.
> > > > > 
> > > > > The main reason for that is that QEMU upstream don't build with 
> > > > > python 2.x
> > > > > anymore, and the python binary selected by Xen build system is the 
> > > > > one used
> > > > > when building qemu-xen. So now osstest failed to build QEMU upstream.
> > > > > 
> > > > > Also, python2 is EOL.
> > > > > 
> > > > > FYI, the hypervisor build system already select python3 by default, 
> > > > > this change
> > > > > the tools side.
> > > > 
> > > > I forgot to say that there's a osstest patch as well:
> > > > [OSSTEST PATCH] ts-xen-build-prep: Install python3-dev
> > > 
> > > AIUI I don't need to wait for that patch to be applied before applying
> > > this series. Let me know if I'm wrong.
> > 
> > It just going to prevent a push :-). All build of staging will fail. So,
> > the osstest patch is needed before applying the patch 3/3.
> 
> Ack. I will push the first two patches first.
> 
> BTW, have you updated the docker images in Gitlab CI?

Never mind. You said that in the commit message already.

Wei.

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

Re: [Xen-devel] [PATCH v5 2/7] x86: introduce a new set of APIs to manage Xen page tables

[Jan Beulich]

On 27.01.2020 15:33, Xia, Hongyan wrote:
> On Thu, 2020-01-16 at 13:04 +0100, Jan Beulich wrote:
>> ...
>>
>>> +void free_xen_pagetable(void *v)
>>> +{
>>> +mfn_t mfn = v ? virt_to_mfn(v) : INVALID_MFN;
>>> +
>>> +if ( system_state != SYS_STATE_early_boot )
>>> +free_xen_pagetable_new(mfn);
>>
>> The condition is (partly) redundant with what
>> free_xen_pagetable_new() does. Therefore I'd like to ask that
>> either the if() be dropped here, or be completed by also
>> checking v to be non-NULL, at which point this would likely
>> become just
>>
>> void free_xen_pagetable(void *v)
>> {
>> if ( v && system_state != SYS_STATE_early_boot )
>> free_xen_pagetable_new(virt_to_mfn(v));
>> }
> 
> You are right. Will change in the next revision.
> 
>>> +/* v can point to an entry within a table or be NULL */
>>> +void unmap_xen_pagetable(const void *v)
>>
>> Why "entry" in the comment?
> 
> I think the comment originally meant pointing to the entry in its
> parent table, which then meant pointing to this table. It's a bit
> confusing. Will reword.
> 
> Reflecting back to your comment in v3 about whether the new Xen page
> table mapping APIs (map/unmap_xen_pagetable) are really necessary, I
> agree in the end they will just do the same thing as
> map/unmap_domain_page, although one thing is that the latter suggests
> it is trying to map a `domain' page, whose definition probably does not
> include Xen page tables, so the name could be a bit confusing (well, we
> could argue that Xen page tables are just idle `domain' pages so the
> name still holds). If we are happy with using map_domain_page on Xen
> PTE tables then I am okay with dropping the new mapping APIs and only
> include the new alloc APIs.

Anyone on the To: list - opinions?

Thanks, Jan

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

Re: [Xen-devel] [XEN PATCH 3/3] tools: Default to python3

[Wei Liu]

On Mon, Jan 20, 2020 at 11:50:53AM +, Anthony PERARD wrote:
> Main reason, newer version of QEMU doesn't support python 2.x anymore.
> Second main reason, python2 is EOL.
> 
> Signed-off-by: Anthony PERARD 

Acked-by: Wei Liu 

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

[Xen-devel] [PATCH v2 10/17] tools/libxl: Plumb a restore boolean down into libxl__build_pre()

[Andrew Cooper]

To fix CPUID handling, libxl__build_pre() is going to have to distinguish
between a brand new VM vs one which is being migrated-in/resumed.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Anthony PERARD 

v2:
 * New.  This is c/s aacc1430064 "tools/libxl: Plumb domain_create_state down
   into libxl__build_pre()" take-2, without any collateral damage to stubdoms.
---
 tools/libxl/libxl_create.c   | 9 +
 tools/libxl/libxl_dm.c   | 2 +-
 tools/libxl/libxl_dom.c  | 4 +++-
 tools/libxl/libxl_internal.h | 6 --
 4 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 12113185ac..1d2e193509 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -434,14 +434,15 @@ static void init_console_info(libxl__gc *gc,
 int libxl__domain_build(libxl__gc *gc,
 libxl_domain_config *d_config,
 uint32_t domid,
-libxl__domain_build_state *state)
+libxl__domain_build_state *state,
+bool restore)
 {
 libxl_domain_build_info *const info = _config->b_info;
 char **vments = NULL, **localents = NULL;
 struct timeval start_time;
 int i, ret;
 
-ret = libxl__build_pre(gc, domid, d_config, state);
+ret = libxl__build_pre(gc, domid, d_config, state, restore);
 if (ret)
 goto out;
 
@@ -1218,7 +1219,7 @@ static void domcreate_bootloader_done(libxl__egc *egc,
 dcs->sdss.callback = domcreate_devmodel_started;
 
 if (restore_fd < 0 && dcs->domid_soft_reset == INVALID_DOMID) {
-rc = libxl__domain_build(gc, d_config, domid, state);
+rc = libxl__domain_build(gc, d_config, domid, state, false);
 domcreate_rebuild_done(egc, dcs, rc);
 return;
 }
@@ -1245,7 +1246,7 @@ static void domcreate_bootloader_done(libxl__egc *egc,
 goto out;
 }
 
-rc = libxl__build_pre(gc, domid, d_config, state);
+rc = libxl__build_pre(gc, domid, d_config, state, restore_fd >= 0);
 if (rc)
 goto out;
 
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index e92e412c1b..d3dfa8751c 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2197,7 +2197,7 @@ void libxl__spawn_stub_dm(libxl__egc *egc, 
libxl__stub_dm_spawn_state *sdss)
 if (ret)
 goto out;
 uint32_t dm_domid = sdss->pvqemu.guest_domid;
-ret = libxl__domain_build(gc, dm_config, dm_domid, stubdom_state);
+ret = libxl__domain_build(gc, dm_config, dm_domid, stubdom_state, false);
 if (ret)
 goto out;
 
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index b730365f47..1bac277351 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -244,7 +244,9 @@ static int numa_place_domain(libxl__gc *gc, uint32_t domid,
 }
 
 int libxl__build_pre(libxl__gc *gc, uint32_t domid,
-  libxl_domain_config *d_config, libxl__domain_build_state *state)
+ libxl_domain_config *d_config,
+ libxl__domain_build_state *state,
+ bool restore)
 {
 libxl_domain_build_info *const info = _config->b_info;
 libxl_ctx *ctx = libxl__gc_owner(gc);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 50856ca703..e66b068d16 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1390,7 +1390,8 @@ _hidden void 
libxl__domain_build_state_dispose(libxl__domain_build_state *s);
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
   libxl_domain_config * const d_config,
-  libxl__domain_build_state *state);
+  libxl__domain_build_state *state,
+  bool restore);
 _hidden int libxl__build_post(libxl__gc *gc, uint32_t domid,
libxl_domain_build_info *info, libxl__domain_build_state *state,
char **vms_ents, char **local_ents);
@@ -1963,7 +1964,8 @@ _hidden int libxl__domain_make(libxl__gc *gc,
 _hidden int libxl__domain_build(libxl__gc *gc,
 libxl_domain_config *d_config,
 uint32_t domid,
-libxl__domain_build_state *state);
+libxl__domain_build_state *state,
+bool restore);
 
 /* for device model creation */
 _hidden const char *libxl__domain_device_model(libxl__gc *gc,
-- 
2.11.0


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

[Xen-devel] [PATCH v2 15/17] tools/libx[cl]: Plumb 'missing' through static_data_done() up into libxl

[Andrew Cooper]

Pre Xen-4.14 streams will not contain any CPUID/MSR information.  There is
nothing libxc can do about this, and will have to rely on the higher level
toolstack to provide backwards compatibility.

To facilitate this, extend the static_data_done() callback, highlighting the
missing information, and modify libxl to use it.  At the libxc level, this
requires an arch-specific hook which, for now, always reports CPUID and MSR as
missing.  This will be adjusted in a later change.

No overall functional change - this is just plumbing.

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Anthony PERARD 

v2:
 * Split/rearrange from v1
 * Don't re-evalute 'k' on migrate
---
 tools/libxc/include/xenguest.h  | 12 ++--
 tools/libxc/xc_sr_common.h  |  9 +
 tools/libxc/xc_sr_common_x86.c  |  8 
 tools/libxc/xc_sr_common_x86.h  |  5 +
 tools/libxc/xc_sr_restore.c |  7 ++-
 tools/libxc/xc_sr_restore_x86_hvm.c |  1 +
 tools/libxc/xc_sr_restore_x86_pv.c  |  1 +
 tools/libxl/libxl_create.c  | 18 ++
 tools/libxl/libxl_save_msgs_gen.pl  |  2 +-
 9 files changed, 55 insertions(+), 8 deletions(-)

diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
index b4df8d0ffe..7a12d21ff2 100644
--- a/tools/libxc/include/xenguest.h
+++ b/tools/libxc/include/xenguest.h
@@ -139,8 +139,16 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t 
dom,
 
 /* callbacks provided by xc_domain_restore */
 struct restore_callbacks {
-/* Called once the STATIC_DATA_END record has been received/inferred. */
-int (*static_data_done)(void *data);
+/*
+ * Called once the STATIC_DATA_END record has been received/inferred.
+ *
+ * For compatibility with older streams, provides a list of static data
+ * expected to be found in the stream, which was missing.  A higher level
+ * toolstack is responsible for providing any necessary compatibiltiy.
+ */
+#define XGR_SDD_MISSING_CPUID (1 << 0)
+#define XGR_SDD_MISSING_MSR   (1 << 1)
+int (*static_data_done)(unsigned int missing, void *data);
 
 /* Called after a new checkpoint to suspend the guest. */
 int (*suspend)(void *data);
diff --git a/tools/libxc/xc_sr_common.h b/tools/libxc/xc_sr_common.h
index 7742260690..f3bdea8006 100644
--- a/tools/libxc/xc_sr_common.h
+++ b/tools/libxc/xc_sr_common.h
@@ -159,6 +159,15 @@ struct xc_sr_restore_ops
 int (*process_record)(struct xc_sr_context *ctx, struct xc_sr_record *rec);
 
 /**
+ * Perform any actions required after the static data has arrived.  Called
+ * when the STATIC_DATA_COMPLETE record has been recieved/inferred.
+ * 'missing' should be filled in for any data item the higher level
+ * toolstack needs to provide compatiblity for.
+ */
+int (*static_data_complete)(struct xc_sr_context *ctx,
+unsigned int *missing);
+
+/**
  * Perform any actions required after the stream has been finished. Called
  * after the END record has been received.
  */
diff --git a/tools/libxc/xc_sr_common_x86.c b/tools/libxc/xc_sr_common_x86.c
index 6267655dab..a849891634 100644
--- a/tools/libxc/xc_sr_common_x86.c
+++ b/tools/libxc/xc_sr_common_x86.c
@@ -132,6 +132,14 @@ int handle_x86_msr_policy(struct xc_sr_context *ctx, 
struct xc_sr_record *rec)
 return rc;
 }
 
+int x86_static_data_complete(struct xc_sr_context *ctx, unsigned int *missing)
+{
+/* TODO: Become conditional on there being no data in the stream. */
+*missing = XGR_SDD_MISSING_MSR | XGR_SDD_MISSING_CPUID;
+
+return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xc_sr_common_x86.h b/tools/libxc/xc_sr_common_x86.h
index d1050981dd..e08d81e0e7 100644
--- a/tools/libxc/xc_sr_common_x86.h
+++ b/tools/libxc/xc_sr_common_x86.h
@@ -34,6 +34,11 @@ int handle_x86_cpuid_policy(struct xc_sr_context *ctx,
 int handle_x86_msr_policy(struct xc_sr_context *ctx,
   struct xc_sr_record *rec);
 
+/*
+ * Perform common x86 actions required after the static data has arrived.
+ */
+int x86_static_data_complete(struct xc_sr_context *ctx, unsigned int *missing);
+
 #endif
 /*
  * Local variables:
diff --git a/tools/libxc/xc_sr_restore.c b/tools/libxc/xc_sr_restore.c
index bb94cd879d..bc811e6e3a 100644
--- a/tools/libxc/xc_sr_restore.c
+++ b/tools/libxc/xc_sr_restore.c
@@ -659,6 +659,7 @@ static int buffer_record(struct xc_sr_context *ctx, struct 
xc_sr_record *rec)
 int handle_static_data_end(struct xc_sr_context *ctx)
 {
 xc_interface *xch = ctx->xch;
+unsigned int missing = 0;
 int rc = 0;
 
 if ( ctx->restore.seen_static_data_end )
@@ -669,9 +670,13 @@ int handle_static_data_end(struct xc_sr_context *ctx)
 
 ctx->restore.seen_static_data_end = true;
 
+rc = ctx->restore.ops.static_data_complete(ctx, );
+if ( rc )
+return rc;
+
 if ( ctx->restore.callbacks->static_data_done &&
 

[Xen-devel] [PATCH v2 16/17] tools/libxc: Restore CPUID/MSR data found in the migration stream

[Andrew Cooper]

With all other pieces in place, it is now safe to restore the CPUID and MSR
data in the migration stream, rather than discarding them and using the higher
level toolstacks compatibility logic.

While this is a small patch, it has large implications for migrated/resumed
domains.  Most obviously, the CPU family/model/stepping data,
cache/tlb/etc. will no longer change behind the guests back.

Another change is the interpretation of the Xend cpuid strings.  The 'k'
option is not a sensible thing to have ever supported, and 's' is how how the
stream will end up behaving.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Ian Jackson 
CC: Wei Liu 
---
 tools/libxc/xc_cpuid_x86.c |  8 
 tools/libxc/xc_sr_common_x86.c | 26 --
 2 files changed, 28 insertions(+), 6 deletions(-)

diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index ac38c1406e..c78d00bbc3 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -291,10 +291,9 @@ int xc_set_domain_cpu_policy(xc_interface *xch, uint32_t 
domid,
  *   '0' -> force to 0
  *   'x' -> we don't care (use default)
  *   'k' -> pass through host value
- *   's' -> pass through the first time and then keep the same value
- *  across save/restore and migration.
+ *   's' -> legacy alias for 'k'
  *
- * For 's' and 'x' the configuration is overwritten with the value applied.
+ * In all cases, the returned string consists of just '0' and '1'.
  */
 int xc_cpuid_set(
 xc_interface *xch, uint32_t domid, const unsigned int *input,
@@ -420,7 +419,8 @@ int xc_cpuid_set(
 clear_feature(31 - j, regs[i]);
 
 config_transformed[i][j] = config[i][j];
-if ( config[i][j] == 's' )
+/* All non 0/1 values get overwritten. */
+if ( (config[i][j] & ~1) != '0' )
 config_transformed[i][j] = '0' + val;
 }
 }
diff --git a/tools/libxc/xc_sr_common_x86.c b/tools/libxc/xc_sr_common_x86.c
index a849891634..77ea044a74 100644
--- a/tools/libxc/xc_sr_common_x86.c
+++ b/tools/libxc/xc_sr_common_x86.c
@@ -134,8 +134,30 @@ int handle_x86_msr_policy(struct xc_sr_context *ctx, 
struct xc_sr_record *rec)
 
 int x86_static_data_complete(struct xc_sr_context *ctx, unsigned int *missing)
 {
-/* TODO: Become conditional on there being no data in the stream. */
-*missing = XGR_SDD_MISSING_MSR | XGR_SDD_MISSING_CPUID;
+xc_interface *xch = ctx->xch;
+uint32_t nr_leaves = 0, nr_msrs = 0;
+uint32_t err_l = ~0, err_s = ~0, err_m = ~0;
+
+if ( ctx->x86.restore.cpuid.ptr )
+nr_leaves = ctx->x86.restore.cpuid.size / sizeof(xen_cpuid_leaf_t);
+else
+*missing |= XGR_SDD_MISSING_CPUID;
+
+if ( ctx->x86.restore.msr.ptr )
+nr_msrs = ctx->x86.restore.msr.size / sizeof(xen_msr_entry_t);
+else
+*missing |= XGR_SDD_MISSING_MSR;
+
+if ( (nr_leaves || nr_msrs) &&
+ xc_set_domain_cpu_policy(xch, ctx->domid,
+  nr_leaves, ctx->x86.restore.cpuid.ptr,
+  nr_msrs,   ctx->x86.restore.msr.ptr,
+  _l, _s, _m) )
+{
+PERROR("Failed to set CPUID policy: leaf %08x, subleaf %08x, msr %08x",
+   err_l, err_s, err_m);
+return -1;
+}
 
 return 0;
 }
-- 
2.11.0


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

[Xen-devel] [PATCH v2 11/17] tools/libxl: Re-position CPUID handling during domain construction

[Andrew Cooper]

CPUID handling needs to be earlier in construction.  Move it from its current
position in libxl__build_post() to libxl__build_pre() for fresh builds, and
libxl__srm_callout_callback_static_data_done() for the migration/resume case.

Later changes will make the migration/resume case conditional on whether CPUID
data was present in the migration stream, and the libxc layer took care of
restoring it.

No functional change.

Signed-off-by: Andrew Cooper 
Acked-by: Ian Jackson 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Anthony PERARD 
---
 tools/libxl/libxl_create.c |  8 +++-
 tools/libxl/libxl_dom.c| 16 
 2 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 1d2e193509..09f84858d5 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1303,8 +1303,14 @@ int libxl__srm_callout_callback_static_data_done(void 
*user)
 libxl__save_helper_state *shs = user;
 libxl__domain_create_state *dcs = shs->caller_state;
 STATE_AO_GC(dcs->ao);
+libxl_ctx *ctx = libxl__gc_owner(gc);
+
+const libxl_domain_config *d_config = dcs->guest_config;
+const libxl_domain_build_info *info = _config->b_info;
 
-/* Nothing to do (yet). */
+libxl__cpuid_apply_policy(ctx, dcs->guest_domid);
+if (info->cpuid != NULL)
+libxl__cpuid_set(ctx, dcs->guest_domid, info->cpuid);
 
 return 0;
 }
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 1bac277351..5dc8369eda 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -389,6 +389,18 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
 
 rc = libxl__arch_domain_create(gc, d_config, domid);
 
+/* Construct a CPUID policy, but only for brand new domains.  Domains
+ * being migrated-in/restored have CPUID handled during the
+ * static_data_done() callback. */
+if (!restore) {
+/* For x86 at least, libxl_cpuid_apply_policy() takes an implicit
+ * parameter, HVM_PARAM_PAE_ENABLED, which is only set up in
+ * libxl__arch_domain_create(). */
+libxl_cpuid_apply_policy(ctx, domid);
+if (info->cpuid != NULL)
+libxl_cpuid_set(ctx, domid, info->cpuid);
+}
+
 return rc;
 }
 
@@ -456,10 +468,6 @@ int libxl__build_post(libxl__gc *gc, uint32_t domid,
 if (rc)
 return rc;
 
-libxl__cpuid_apply_policy(ctx, domid);
-if (info->cpuid != NULL)
-libxl__cpuid_set(ctx, domid, info->cpuid);
-
 if (info->type == LIBXL_DOMAIN_TYPE_HVM
 && !libxl_ms_vm_genid_is_zero(>u.hvm.ms_vm_genid)) {
 rc = libxl__ms_vm_genid_set(gc, domid,
-- 
2.11.0


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

[Xen-devel] [PATCH v2 14/17] libxc/save: Write X86_{CPUID, MSR}_DATA records

[Andrew Cooper]

With all other plumbing in place, obtain the CPU Policy from Xen and
write it into the migration stream.

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 
CC: Wei Liu 
---
 tools/libxc/xc_sr_common_x86.c   | 50 
 tools/libxc/xc_sr_common_x86.h   |  6 +
 tools/libxc/xc_sr_save_x86_hvm.c |  2 +-
 tools/libxc/xc_sr_save_x86_pv.c  | 12 +-
 4 files changed, 68 insertions(+), 2 deletions(-)

diff --git a/tools/libxc/xc_sr_common_x86.c b/tools/libxc/xc_sr_common_x86.c
index 8980299e9a..6267655dab 100644
--- a/tools/libxc/xc_sr_common_x86.c
+++ b/tools/libxc/xc_sr_common_x86.c
@@ -42,6 +42,56 @@ int handle_x86_tsc_info(struct xc_sr_context *ctx, struct 
xc_sr_record *rec)
 return 0;
 }
 
+int write_x86_cpu_policy_records(struct xc_sr_context *ctx)
+{
+xc_interface *xch = ctx->xch;
+struct xc_sr_record cpuid = { .type = REC_TYPE_X86_CPUID_POLICY, };
+struct xc_sr_record msrs  = { .type = REC_TYPE_X86_MSR_POLICY, };
+uint32_t nr_leaves = 0, nr_msrs = 0;
+int rc;
+
+if ( xc_get_cpu_policy_size(xch, _leaves, _msrs) < 0 )
+{
+PERROR("Unable to get CPU Policy size");
+return -1;
+}
+
+cpuid.data = malloc(nr_leaves * sizeof(xen_cpuid_leaf_t));
+msrs.data  = malloc(nr_msrs   * sizeof(xen_msr_entry_t));
+if ( !cpuid.data || !msrs.data )
+{
+ERROR("Cannot allocate memory for CPU Policy");
+rc = -1;
+goto out;
+}
+
+if ( xc_get_domain_cpu_policy(xch, ctx->domid, _leaves, cpuid.data,
+  _msrs, msrs.data) )
+{
+PERROR("Unable to get d%d CPU Policy", ctx->domid);
+rc = -1;
+goto out;
+}
+
+cpuid.length = nr_leaves * sizeof(xen_cpuid_leaf_t);
+if ( cpuid.length )
+{
+rc = write_record(ctx, );
+if ( rc )
+goto out;
+}
+
+msrs.length = nr_msrs * sizeof(xen_msr_entry_t);
+if ( msrs.length )
+rc = write_record(ctx, );
+
+ out:
+free(cpuid.data);
+free(msrs.data);
+
+return rc;
+}
+
 int handle_x86_cpuid_policy(struct xc_sr_context *ctx, struct xc_sr_record 
*rec)
 {
 xc_interface *xch = ctx->xch;
diff --git a/tools/libxc/xc_sr_common_x86.h b/tools/libxc/xc_sr_common_x86.h
index c458c1aa37..d1050981dd 100644
--- a/tools/libxc/xc_sr_common_x86.h
+++ b/tools/libxc/xc_sr_common_x86.h
@@ -15,6 +15,12 @@ int write_x86_tsc_info(struct xc_sr_context *ctx);
 int handle_x86_tsc_info(struct xc_sr_context *ctx, struct xc_sr_record *rec);
 
 /*
+ * Obtains a domains CPU Policy from Xen, and writes X86_{CPUID,MSR}_POLICY
+ * records into the stream.
+ */
+int write_x86_cpu_policy_records(struct xc_sr_context *ctx);
+
+/*
  * Parses an X86_CPUID_POLICY record and stashes the content for application
  * when a STATIC_DATA_END record is encountered.
  */
diff --git a/tools/libxc/xc_sr_save_x86_hvm.c b/tools/libxc/xc_sr_save_x86_hvm.c
index 93bcc1c273..acf9264dec 100644
--- a/tools/libxc/xc_sr_save_x86_hvm.c
+++ b/tools/libxc/xc_sr_save_x86_hvm.c
@@ -172,7 +172,7 @@ static int x86_hvm_setup(struct xc_sr_context *ctx)
 
 static int x86_hvm_static_data(struct xc_sr_context *ctx)
 {
-return 0;
+return write_x86_cpu_policy_records(ctx);
 }
 
 static int x86_hvm_start_of_stream(struct xc_sr_context *ctx)
diff --git a/tools/libxc/xc_sr_save_x86_pv.c b/tools/libxc/xc_sr_save_x86_pv.c
index 46019d962d..c7e246ef4f 100644
--- a/tools/libxc/xc_sr_save_x86_pv.c
+++ b/tools/libxc/xc_sr_save_x86_pv.c
@@ -1054,7 +1054,17 @@ static int x86_pv_setup(struct xc_sr_context *ctx)
 
 static int x86_pv_static_data(struct xc_sr_context *ctx)
 {
-return write_x86_pv_info(ctx);
+int rc;
+
+rc = write_x86_pv_info(ctx);
+if ( rc )
+return rc;
+
+rc = write_x86_cpu_policy_records(ctx);
+if ( rc )
+return rc;
+
+return 0;
 }
 
 static int x86_pv_start_of_stream(struct xc_sr_context *ctx)
-- 
2.11.0


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

[Xen-devel] [PATCH v2 17/17] docs/xl.cfg: Rewrite cpuid= section

[Andrew Cooper]

This is partly to adjust the description of 'k' and 's' seeing as they have
changed, but mostly restructuring the information for clarity.

In particular, use indentation to clearly separate the areas discussing libxl
format from xend format.  In addition, extend the xend format section to
discuss subleaf notation.

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Anthony PERARD 

v2:
 * New
---
 docs/man/xl.cfg.5.pod.in | 74 ++--
 1 file changed, 53 insertions(+), 21 deletions(-)

diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index 245d3f9472..1da68c4a07 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -1964,26 +1964,42 @@ This option is disabled by default.
 Configure the value returned when a guest executes the CPUID instruction.
 Two versions of config syntax are recognized: libxl and xend.
 
-The libxl syntax is a comma separated list of key=value pairs, preceded by the
-word "host". A few keys take a numerical value, all others take a single
-character which describes what to do with the feature bit.
-
-Possible values for a single feature bit:
+Both formats use a common notation for specifying a single feature bit.
+Possible values are:
   '1' -> force the corresponding bit to 1
   '0' -> force to 0
   'x' -> Get a safe value (pass through and mask with the default policy)
-  'k' -> pass through the host bit value
-  's' -> as 'k' but preserve across save/restore and migration (not 
implemented)
+  'k' -> pass through the host bit value (at boot only - value preserved on 
migrate)
+  's' -> legacy alias for 'k'
 
-Note: when specifying B for hypervisor leaves (0x4000 major group)
-only the lowest 8 bits of leaf's 0x4000xx00 EAX register are processed, the
-rest are ignored (these 8 bits signify maximum number of hypervisor leaves).
+B:
+
+=over 4
+
+The libxl format is a single string, starting with the word "host", and
+followed by a comma separated list of key=value pairs.  A few keys take a
+numerical value, all others take a single character which describes what to do
+with the feature bit.  e.g.:
+
+=over 4
+
+cpuid="host,tm=0,sse3=0"
+
+=back
 
 List of keys taking a value:
+
+=over 4
+
 apicidsize brandid clflush family localapicid maxleaf maxhvleaf model nc
 proccount procpkg stepping
 
+=back
+
 List of keys taking a character:
+
+=over 4
+
 3dnow 3dnowext 3dnowprefetch abm acpi adx aes altmovcr8 apic arat avx avx2
 avx512-4fmaps avx512-4vnniw avx512bw avx512cd avx512dq avx512er avx512f
 avx512ifma avx512pf avx512vbmi avx512vl bmi1 bmi2 clflushopt clfsh clwb cmov
@@ -1997,21 +2013,37 @@ ssse3 svm svm_decode svm_lbrv svm_npt svm_nrips 
svm_pausefilt svm_tscrate
 svm_vmcbclean syscall sysenter tbm tm tm2 topoext tsc tsc-deadline tsc_adjust
 umip vme vmx wdt x2apic xop xsave xtpr
 
+=back
+
+=back
+
+B:
 
-The xend syntax is a list of values in the form of
-'leafnum:register=bitstring,register=bitstring'
-  "leafnum" is the requested function,
-  "register" is the response register to modify
-  "bitstring" represents all bits in the register, its length must be 32 chars.
-  Each successive character represent a lesser-significant bit, possible values
-  are listed above in the libxl section.
+=over 4
 
-Example to hide two features from the guest: 'tm', which is bit #29 in EDX, and
-'pni' (SSE3), which is bit #0 in ECX:
+Xend format consists of an array of one or more strings of the form
+"leaf:reg=bitstring,...".  e.g. (matching the libxl example above):
 
-xend: [ 
"1:ecx=xxx0,edx=xx0x" ]
+=over 4
 
-libxl: "host,tm=0,sse3=0"
+cpuid=["1:ecx=xxx0,edx=xx0x",
 ...]
+
+=back
+
+"leaf" is an integer, either decimal or hex with a "0x" prefix.  e.g. to
+specify something in the AMD feature leaves, use "0x8001:ecx=...".
+
+Some leaves have subleaves which can be specified as "leaf,subleaf".  e.g. for
+the Intel structured feature leaf, use "7,0:ebx=..."
+
+The bitstring represents all bits in the register, its length must be 32
+chars.  Each successive character represent a lesser-significant bit.
+
+=back
+
+Note: when specifying B for hypervisor leaves (0x4000 major group)
+only the lowest 8 bits of leaf's 0x4000xx00 EAX register are processed, the
+rest are ignored (these 8 bits signify maximum number of hypervisor leaves).
 
 More info about the CPUID instruction can be found in the processor manuals,
 and on Wikipedia: L
-- 
2.11.0


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

Re: [Xen-devel] [XEN PATCH 0/3] Default to python3

[Wei Liu]

On Mon, Jan 27, 2020 at 12:36:23PM +, Anthony PERARD wrote:
> On Mon, Jan 27, 2020 at 12:30:21PM +, Wei Liu wrote:
> > On Mon, Jan 20, 2020 at 11:52:17AM +, Anthony PERARD wrote:
> > > On Mon, Jan 20, 2020 at 11:50:50AM +, Anthony PERARD wrote:
> > > > Patch series available in this git branch:
> > > > https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git 
> > > > br.python3-default-v1
> > > > 
> > > > Hi,
> > > > 
> > > > I think it's time for Xen to build with python3 by default.
> > > > 
> > > > The main reason for that is that QEMU upstream don't build with python 
> > > > 2.x
> > > > anymore, and the python binary selected by Xen build system is the one 
> > > > used
> > > > when building qemu-xen. So now osstest failed to build QEMU upstream.
> > > > 
> > > > Also, python2 is EOL.
> > > > 
> > > > FYI, the hypervisor build system already select python3 by default, 
> > > > this change
> > > > the tools side.
> > > 
> > > I forgot to say that there's a osstest patch as well:
> > > [OSSTEST PATCH] ts-xen-build-prep: Install python3-dev
> > 
> > AIUI I don't need to wait for that patch to be applied before applying
> > this series. Let me know if I'm wrong.
> 
> It just going to prevent a push :-). All build of staging will fail. So,
> the osstest patch is needed before applying the patch 3/3.

Ack. I will push the first two patches first.

BTW, have you updated the docker images in Gitlab CI?

Wei.

> 
> Cheers,
> 
> -- 
> Anthony PERARD

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

[Xen-devel] [PATCH v2 12/17] docs/migration: Specify X86_{CPUID, MSR}_POLICY records

[Andrew Cooper]

These two records move blobs from the XEN_DOMCTL_{get,set}_cpu_policy
hypercall.

Signed-off-by: Andrew Cooper 
---
CC: George Dunlap 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Tim Deegan 
CC: Wei Liu 
CC: Julien Grall 
CC: Marek Marczykowski-Górecki 
---
 docs/specs/libxc-migration-stream.pandoc | 42 +++
 tools/libxc/xc_sr_common.c   |  2 ++
 tools/libxc/xc_sr_stream_format.h|  2 ++
 tools/python/xen/migration/libxc.py  | 43 
 4 files changed, 89 insertions(+)

diff --git a/docs/specs/libxc-migration-stream.pandoc 
b/docs/specs/libxc-migration-stream.pandoc
index 22ff306e0b..3a0915b795 100644
--- a/docs/specs/libxc-migration-stream.pandoc
+++ b/docs/specs/libxc-migration-stream.pandoc
@@ -634,6 +634,46 @@ The end record contains no fields; its body_length is 0.
 
 \clearpage
 
+X86_CPUID_POLICY
+
+
+CPUID policy content, as accessed by the XEN_DOMCTL_{get,set}_cpu_policy
+hypercall sub-ops.
+
+ 0 1 2 3 4 5 6 7 octet
++-+
+| CPUID_policy|
+...
++-+
+
+
+FieldDescription
+ ---
+CPUID_policy Array of xen_cpuid_leaf_t[]'s
+
+
+\clearpage
+
+X86_MSR_POLICY
+--
+
+MSR policy content, as accessed by the XEN_DOMCTL_{get,set}_cpu_policy
+hypercall sub-ops.
+
+ 0 1 2 3 4 5 6 7 octet
++-+
+| MSR_policy  |
+...
++-+
+
+
+FieldDescription
+--   ---
+MSR_policy   Array of xen_msr_entry_t[]'s
+
+
+\clearpage
+
 
 Layout
 ==
@@ -656,6 +696,7 @@ A typical save record for an x86 PV guest image would look 
like:
 * Domain header
 * Static data records:
 * X86_PV_INFO record
+* X86_{CPUID,MSR}_POLICY
 * STATIC_DATA_END
 * X86_PV_P2M_FRAMES record
 * Many PAGE_DATA records
@@ -685,6 +726,7 @@ A typical save record for an x86 HVM guest image would look 
like:
 * Image header
 * Domain header
 * Static data records:
+* X86_{CPUID,MSR}_POLICY
 * STATIC_DATA_END
 * Many PAGE_DATA records
 * X86_TSC_INFO
diff --git a/tools/libxc/xc_sr_common.c b/tools/libxc/xc_sr_common.c
index 7f22cf0365..7c54b03414 100644
--- a/tools/libxc/xc_sr_common.c
+++ b/tools/libxc/xc_sr_common.c
@@ -37,6 +37,8 @@ static const char *const mandatory_rec_types[] =
 [REC_TYPE_CHECKPOINT]   = "Checkpoint",
 [REC_TYPE_CHECKPOINT_DIRTY_PFN_LIST]= "Checkpoint dirty pfn list",
 [REC_TYPE_STATIC_DATA_END]  = "Static data end",
+[REC_TYPE_X86_CPUID_POLICY] = "x86 CPUID policy",
+[REC_TYPE_X86_MSR_POLICY]   = "x86 MSR policy",
 };
 
 const char *rec_type_to_str(uint32_t type)
diff --git a/tools/libxc/xc_sr_stream_format.h 
b/tools/libxc/xc_sr_stream_format.h
index 81c9765b0a..8a0da26f75 100644
--- a/tools/libxc/xc_sr_stream_format.h
+++ b/tools/libxc/xc_sr_stream_format.h
@@ -74,6 +74,8 @@ struct xc_sr_rhdr
 #define REC_TYPE_CHECKPOINT 0x000eU
 #define REC_TYPE_CHECKPOINT_DIRTY_PFN_LIST  0x000fU
 #define REC_TYPE_STATIC_DATA_END0x0010U
+#define REC_TYPE_X86_CPUID_POLICY   0x0011U
+#define REC_TYPE_X86_MSR_POLICY 0x0012U
 
 #define REC_TYPE_OPTIONAL 0x8000U
 
diff --git a/tools/python/xen/migration/libxc.py 
b/tools/python/xen/migration/libxc.py
index 5fb51b56ac..9881f5ced4 100644
--- a/tools/python/xen/migration/libxc.py
+++ b/tools/python/xen/migration/libxc.py
@@ -57,6 +57,8 @@
 REC_TYPE_checkpoint = 0x000e
 REC_TYPE_checkpoint_dirty_pfn_list  = 0x000f
 REC_TYPE_static_data_end= 0x0010
+REC_TYPE_x86_cpuid_policy   = 0x0011
+REC_TYPE_x86_msr_policy = 0x0012
 
 rec_type_to_str = {
 REC_TYPE_end: "End",
@@ -76,6 +78,8 @@
 REC_TYPE_checkpoint : "Checkpoint",
 REC_TYPE_checkpoint_dirty_pfn_list  : "Checkpoint dirty pfn list",
 REC_TYPE_static_data_end: "Static data end",
+REC_TYPE_x86_cpuid_policy   : "x86 CPUID policy",
+REC_TYPE_x86_msr_policy : "x86 MSR policy",
 }
 
 # page_data
@@ -113,6 +117,12 @@
 HVM_PARAMS_ENTRY_FORMAT   = "QQ"
 HVM_PARAMS_FORMAT = "II"
 
+# x86_cpuid_policy => 

[Xen-devel] [PATCH v2 13/17] libxc/restore: Handle X86_{CPUID, MSR}_DATA records

[Andrew Cooper]

For now, the data are just stashed, and discarded at the end.

A future change will restore the data, once libxl has been adjusted to avoid
clobbering the data.

No functional change.

Signed-off-by: Andrew Cooper 
Acked-by: Ian Jackson 
---
CC: Ian Jackson 
CC: Wei Liu 
---
 tools/libxc/xc_sr_common.h  | 10 ++
 tools/libxc/xc_sr_common_x86.c  | 40 +
 tools/libxc/xc_sr_common_x86.h  | 14 +
 tools/libxc/xc_sr_restore_x86_hvm.c |  9 +
 tools/libxc/xc_sr_restore_x86_pv.c  |  9 +
 5 files changed, 82 insertions(+)

diff --git a/tools/libxc/xc_sr_common.h b/tools/libxc/xc_sr_common.h
index fd7fb67305..7742260690 100644
--- a/tools/libxc/xc_sr_common.h
+++ b/tools/libxc/xc_sr_common.h
@@ -296,6 +296,16 @@ struct xc_sr_context
 {
 struct /* x86 */
 {
+/* Common save/restore data. */
+union
+{
+struct
+{
+/* X86_{CPUID,MSR}_DATA blobs for CPU Policy. */
+struct xc_sr_blob cpuid, msr;
+} restore;
+};
+
 struct /* x86 PV guest. */
 {
 /* 4 or 8; 32 or 64 bit domain */
diff --git a/tools/libxc/xc_sr_common_x86.c b/tools/libxc/xc_sr_common_x86.c
index 011684df97..8980299e9a 100644
--- a/tools/libxc/xc_sr_common_x86.c
+++ b/tools/libxc/xc_sr_common_x86.c
@@ -42,6 +42,46 @@ int handle_x86_tsc_info(struct xc_sr_context *ctx, struct 
xc_sr_record *rec)
 return 0;
 }
 
+int handle_x86_cpuid_policy(struct xc_sr_context *ctx, struct xc_sr_record 
*rec)
+{
+xc_interface *xch = ctx->xch;
+int rc;
+
+if ( rec->length == 0 ||
+ rec->length % sizeof(xen_cpuid_leaf_t) != 0 )
+{
+ERROR("X86_CPUID_POLICY size %u should be multiple of %zu",
+  rec->length, sizeof(xen_cpuid_leaf_t));
+return -1;
+}
+
+rc = update_blob(>x86.restore.cpuid, rec->data, rec->length);
+if ( rc )
+ERROR("Unable to allocate %u bytes for X86_CPUID_POLICY", rec->length);
+
+return rc;
+}
+
+int handle_x86_msr_policy(struct xc_sr_context *ctx, struct xc_sr_record *rec)
+{
+xc_interface *xch = ctx->xch;
+int rc;
+
+if ( rec->length == 0 ||
+ rec->length % sizeof(xen_msr_entry_t) != 0 )
+{
+ERROR("X86_MSR_POLICY size %u should be multiple of %zu",
+  rec->length, sizeof(xen_cpuid_leaf_t));
+return -1;
+}
+
+rc = update_blob(>x86.restore.msr, rec->data, rec->length);
+if ( rc )
+ERROR("Unable to allocate %u bytes for X86_MSR_POLICY", rec->length);
+
+return rc;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xc_sr_common_x86.h b/tools/libxc/xc_sr_common_x86.h
index ebc4355bd1..c458c1aa37 100644
--- a/tools/libxc/xc_sr_common_x86.h
+++ b/tools/libxc/xc_sr_common_x86.h
@@ -14,6 +14,20 @@ int write_x86_tsc_info(struct xc_sr_context *ctx);
  */
 int handle_x86_tsc_info(struct xc_sr_context *ctx, struct xc_sr_record *rec);
 
+/*
+ * Parses an X86_CPUID_POLICY record and stashes the content for application
+ * when a STATIC_DATA_END record is encountered.
+ */
+int handle_x86_cpuid_policy(struct xc_sr_context *ctx,
+struct xc_sr_record *rec);
+
+/*
+ * Parses an X86_MSR_POLICY record and stashes the content for application
+ * when a STATIC_DATA_END record is encountered.
+ */
+int handle_x86_msr_policy(struct xc_sr_context *ctx,
+  struct xc_sr_record *rec);
+
 #endif
 /*
  * Local variables:
diff --git a/tools/libxc/xc_sr_restore_x86_hvm.c 
b/tools/libxc/xc_sr_restore_x86_hvm.c
index 3f78248f32..cef99e0397 100644
--- a/tools/libxc/xc_sr_restore_x86_hvm.c
+++ b/tools/libxc/xc_sr_restore_x86_hvm.c
@@ -171,6 +171,12 @@ static int x86_hvm_process_record(struct xc_sr_context 
*ctx,
 case REC_TYPE_HVM_PARAMS:
 return handle_hvm_params(ctx, rec);
 
+case REC_TYPE_X86_CPUID_POLICY:
+return handle_x86_cpuid_policy(ctx, rec);
+
+case REC_TYPE_X86_MSR_POLICY:
+return handle_x86_msr_policy(ctx, rec);
+
 default:
 return RECORD_NOT_PROCESSED;
 }
@@ -227,6 +233,9 @@ static int x86_hvm_cleanup(struct xc_sr_context *ctx)
 {
 free(ctx->x86.hvm.restore.context.ptr);
 
+free(ctx->x86.restore.cpuid.ptr);
+free(ctx->x86.restore.msr.ptr);
+
 return 0;
 }
 
diff --git a/tools/libxc/xc_sr_restore_x86_pv.c 
b/tools/libxc/xc_sr_restore_x86_pv.c
index 3756225be6..3aac4bd502 100644
--- a/tools/libxc/xc_sr_restore_x86_pv.c
+++ b/tools/libxc/xc_sr_restore_x86_pv.c
@@ -1102,6 +1102,12 @@ static int x86_pv_process_record(struct xc_sr_context 
*ctx,
 case REC_TYPE_X86_TSC_INFO:
 return handle_x86_tsc_info(ctx, rec);
 
+case REC_TYPE_X86_CPUID_POLICY:
+return handle_x86_cpuid_policy(ctx, rec);
+
+case REC_TYPE_X86_MSR_POLICY:
+return handle_x86_msr_policy(ctx, rec);
+
 default:
 return 

[Xen-devel] [PATCH v2 01/17] tools/libxl: Remove libxl_cpuid_{set, apply_policy}() from the API

[Andrew Cooper]

These functions should never have been exposed.  They don't have external
users, and can't usefully be used for several reasons.

Move libxl_cpuid_{set,apply_policy}() to being internal functions, and leave
an equivalent of the nop stubs in the API for caller compatibility.

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Anthony PERARD 

RFC for obvious reasons.  An alternative would be to #if 0 them, which would
result in a compile failure rather than silent stubbing.  I'm not sure which
is least bad, but I don't think either are going to cause a problem in
practice.
---
 tools/libxl/libxl.h  | 26 ++
 tools/libxl/libxl_cpuid.c|  6 +++---
 tools/libxl/libxl_dom.c  |  4 ++--
 tools/libxl/libxl_internal.h |  4 
 tools/libxl/libxl_nocpuid.c  |  6 +++---
 5 files changed, 34 insertions(+), 12 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 54abb9db1f..a02548f595 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -665,7 +665,7 @@ typedef struct libxl__ctx libxl_ctx;
 #if LIBXL_API_VERSION != 0x040200 && LIBXL_API_VERSION != 0x040300 && \
 LIBXL_API_VERSION != 0x040400 && LIBXL_API_VERSION != 0x040500 && \
 LIBXL_API_VERSION != 0x040700 && LIBXL_API_VERSION != 0x040800 && \
-LIBXL_API_VERSION != 0x041300
+LIBXL_API_VERSION != 0x041300 && LIBXL_API_VERSION != 0x041400
 #error Unknown LIBXL_API_VERSION
 #endif
 #endif
@@ -2323,9 +2323,27 @@ libxl_device_pci 
*libxl_device_pci_assignable_list(libxl_ctx *ctx, int *num);
 int libxl_cpuid_parse_config(libxl_cpuid_policy_list *cpuid, const char* str);
 int libxl_cpuid_parse_config_xend(libxl_cpuid_policy_list *cpuid,
   const char* str);
-void libxl_cpuid_apply_policy(libxl_ctx *ctx, uint32_t domid);
-void libxl_cpuid_set(libxl_ctx *ctx, uint32_t domid,
- libxl_cpuid_policy_list cpuid);
+#if LIBXL_API_VERSION < 0x041400
+/*
+ * Dropped from the API in Xen 4.14.  At the time of writing, these functions
+ * don't appear to ever have had external callers.
+ *
+ * These have always been used internally during domain construction, and
+ * can't easily be used externally because of their implicit parameters in
+ * other pieces of global state.
+ *
+ * Furthermore, an API user can't usefully determine whether they get
+ * libxl_cpuid (the real implementation) or libxl_nocpuid (no-op stubs).
+ *
+ * The internal behaviour of these functions also needs to change.  Therefore
+ * for simplicitly, provide the no-op stubs.  Yes technically this is an API
+ * change in some cases for existing software, but there is 0 of that in
+ * practice.
+ */
+static inline void libxl_cpuid_apply_policy(libxl_ctx *ctx, uint32_t domid) {}
+static inline void libxl_cpuid_set(libxl_ctx *ctx, uint32_t domid,
+   libxl_cpuid_policy_list cpuid) {}
+#endif
 
 /*
  * Functions for allowing users of libxl to store private data
diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c
index 5c52cbe0f9..505ec1b048 100644
--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -410,13 +410,13 @@ int libxl_cpuid_parse_config_xend(libxl_cpuid_policy_list 
*cpuid,
 return 0;
 }
 
-void libxl_cpuid_apply_policy(libxl_ctx *ctx, uint32_t domid)
+void libxl__cpuid_apply_policy(libxl_ctx *ctx, uint32_t domid)
 {
 xc_cpuid_apply_policy(ctx->xch, domid, NULL, 0);
 }
 
-void libxl_cpuid_set(libxl_ctx *ctx, uint32_t domid,
- libxl_cpuid_policy_list cpuid)
+void libxl__cpuid_set(libxl_ctx *ctx, uint32_t domid,
+  libxl_cpuid_policy_list cpuid)
 {
 int i;
 char *cpuid_res[4];
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 573c63692b..b730365f47 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -454,9 +454,9 @@ int libxl__build_post(libxl__gc *gc, uint32_t domid,
 if (rc)
 return rc;
 
-libxl_cpuid_apply_policy(ctx, domid);
+libxl__cpuid_apply_policy(ctx, domid);
 if (info->cpuid != NULL)
-libxl_cpuid_set(ctx, domid, info->cpuid);
+libxl__cpuid_set(ctx, domid, info->cpuid);
 
 if (info->type == LIBXL_DOMAIN_TYPE_HVM
 && !libxl_ms_vm_genid_is_zero(>u.hvm.ms_vm_genid)) {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 64f6fdada8..50856ca703 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2042,6 +2042,10 @@ struct libxl__cpuid_policy {
 char *policy[4];
 };
 
+_hidden void libxl__cpuid_apply_policy(libxl_ctx *ctx, uint32_t domid);
+_hidden void libxl__cpuid_set(libxl_ctx *ctx, uint32_t domid,
+  libxl_cpuid_policy_list cpuid);
+
 /* Calls poll() again - useful to check whether a signaled condition
  * is still true.  Cannot fail.  Returns currently-true revents. */
 _hidden short libxl__fd_poll_recheck(libxl__egc *egc, int fd, short events);
diff --git 

[Xen-devel] [PATCH v2 09/17] tools/libxl: Provide a static_data_done callback for domain restore

[Andrew Cooper]

This will be needed shortly to provide backwards compatiblity for migration
streams which do not have CPUID information contained within them.

No functional change yet.

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Anthony PERARD 

v2:
 * Split/rearranged from v1
---
 tools/libxl/libxl_create.c | 12 
 tools/libxl/libxl_save_msgs_gen.pl |  1 +
 2 files changed, 13 insertions(+)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 32d45dcef0..12113185ac 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1227,6 +1227,7 @@ static void domcreate_bootloader_done(libxl__egc *egc,
 dcs->srs.dcs = dcs;
 
 /* Restore */
+callbacks->static_data_done = libxl__srm_callout_callback_static_data_done;
 callbacks->restore_results = libxl__srm_callout_callback_restore_results;
 
 /* COLO only supports HVM now because it does not work very
@@ -1296,6 +1297,17 @@ static void libxl__colo_restore_setup_done(libxl__egc 
*egc,
 libxl__stream_read_start(egc, >srs);
 }
 
+int libxl__srm_callout_callback_static_data_done(void *user)
+{
+libxl__save_helper_state *shs = user;
+libxl__domain_create_state *dcs = shs->caller_state;
+STATE_AO_GC(dcs->ao);
+
+/* Nothing to do (yet). */
+
+return 0;
+}
+
 void libxl__srm_callout_callback_restore_results(xen_pfn_t store_mfn,
   xen_pfn_t console_mfn, void *user)
 {
diff --git a/tools/libxl/libxl_save_msgs_gen.pl 
b/tools/libxl/libxl_save_msgs_gen.pl
index 831a15e0bb..93dc252370 100755
--- a/tools/libxl/libxl_save_msgs_gen.pl
+++ b/tools/libxl/libxl_save_msgs_gen.pl
@@ -29,6 +29,7 @@ our @msgs = (
 [ 'srcxA',  "wait_checkpoint", [] ],
 [ 'scxA',   "switch_qemu_logdirty",  [qw(uint32_t domid
   unsigned enable)] ],
+[ 'rcxW',   "static_data_done",  [] ],
 [ 'rcx',"restore_results",   ['xen_pfn_t', 'store_gfn',
   'xen_pfn_t', 'console_gfn'] ],
 [ 'srW',"complete",  [qw(int retval
-- 
2.11.0


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

[Xen-devel] [PATCH v2 06/17] libxc/restore: Support v3 streams and handle STATIC_DATA_END

[Andrew Cooper]

Higher level toolstacks may wish to know when the static data is complete, so
introduce a restore_callback for the purpose.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 
CC: Wei Liu 

v2:
 * Split/rearranged from v1
---
 tools/libxc/include/xenguest.h |  3 +++
 tools/libxc/xc_sr_common.h |  3 +++
 tools/libxc/xc_sr_restore.c| 29 +++--
 3 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
index 19d828a7f2..efd90b0d42 100644
--- a/tools/libxc/include/xenguest.h
+++ b/tools/libxc/include/xenguest.h
@@ -139,6 +139,9 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t 
dom,
 
 /* callbacks provided by xc_domain_restore */
 struct restore_callbacks {
+/* Called once the STATIC_DATA_END record has been received. */
+int (*static_data_done)(void *data);
+
 /* Called after a new checkpoint to suspend the guest. */
 int (*suspend)(void *data);
 
diff --git a/tools/libxc/xc_sr_common.h b/tools/libxc/xc_sr_common.h
index 5dd51ccb15..ae0ab70f76 100644
--- a/tools/libxc/xc_sr_common.h
+++ b/tools/libxc/xc_sr_common.h
@@ -253,6 +253,9 @@ struct xc_sr_context
 /* Currently buffering records between a checkpoint */
 bool buffer_all_records;
 
+/* Whether a STATIC_DATA_END record has been seen. */
+bool seen_static_data_end;
+
 /*
  * With Remus/COLO, we buffer the records sent by the primary at checkpoint,
  * in case the primary will fail, we can recover from the last
diff --git a/tools/libxc/xc_sr_restore.c b/tools/libxc/xc_sr_restore.c
index dc2ffcf855..9c924387ae 100644
--- a/tools/libxc/xc_sr_restore.c
+++ b/tools/libxc/xc_sr_restore.c
@@ -35,9 +35,9 @@ static int read_headers(struct xc_sr_context *ctx)
 return -1;
 }
 
-if ( ihdr.version != 2 )
+if ( ihdr.version < 2 || ihdr.version > 3 )
 {
-ERROR("Invalid Version: Expected 2, Got %d",
+ERROR("Invalid Version: Expected 2 <= ver <= 3, Got %d",
   ihdr.version);
 return -1;
 }
@@ -631,6 +631,27 @@ static int buffer_record(struct xc_sr_context *ctx, struct 
xc_sr_record *rec)
 return 0;
 }
 
+static int handle_static_data_end(struct xc_sr_context *ctx)
+{
+xc_interface *xch = ctx->xch;
+int rc = 0;
+
+if ( ctx->restore.seen_static_data_end )
+{
+ERROR("Multiple STATIC_DATA_END records found");
+return -1;
+}
+
+ctx->restore.seen_static_data_end = true;
+
+if ( ctx->restore.callbacks->static_data_done &&
+ (rc = ctx->restore.callbacks->static_data_done(
+ ctx->restore.callbacks->data) != 0) )
+ERROR("static_data_done() callback failed: %d\n", rc);
+
+return rc;
+}
+
 static int process_record(struct xc_sr_context *ctx, struct xc_sr_record *rec)
 {
 xc_interface *xch = ctx->xch;
@@ -654,6 +675,10 @@ static int process_record(struct xc_sr_context *ctx, 
struct xc_sr_record *rec)
 rc = handle_checkpoint(ctx);
 break;
 
+case REC_TYPE_STATIC_DATA_END:
+rc = handle_static_data_end(ctx);
+break;
+
 default:
 rc = ctx->restore.ops.process_record(ctx, rec);
 break;
-- 
2.11.0


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

[Xen-devel] [PATCH v2 07/17] libxc/restore: STATIC_DATA_END inference for v2 compatibility

[Andrew Cooper]

A v3 stream can compatibly read a v2 stream by inferring the position of the
STATIC_DATA_END record.

v2 compatibility is only needed for x86.  No other architectures exist yet,
but they will have a minimum of v3 when introduced.

The x86 HVM compatibility point being in handle_page_data() (which is common
code) is a bit awkward.  However, as the two compatibility points are subtly
different, and it is (intentionally) not possible to call into arch specific
code from common code (except via the ops hooks), use some #ifdef-ary and
opencode the check, rather than make handle_page_data() a per-arch helper.

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 
CC: Wei Liu 

v2:
 * Split/rearranged from v1
 * Rewrite the commit message to explain why compatibility is done this way.
---
 tools/libxc/include/xenguest.h |  2 +-
 tools/libxc/xc_sr_common.h |  5 -
 tools/libxc/xc_sr_restore.c| 27 ++-
 tools/libxc/xc_sr_restore_x86_pv.c | 17 +
 4 files changed, 48 insertions(+), 3 deletions(-)

diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
index efd90b0d42..b4df8d0ffe 100644
--- a/tools/libxc/include/xenguest.h
+++ b/tools/libxc/include/xenguest.h
@@ -139,7 +139,7 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t 
dom,
 
 /* callbacks provided by xc_domain_restore */
 struct restore_callbacks {
-/* Called once the STATIC_DATA_END record has been received. */
+/* Called once the STATIC_DATA_END record has been received/inferred. */
 int (*static_data_done)(void *data);
 
 /* Called after a new checkpoint to suspend the guest. */
diff --git a/tools/libxc/xc_sr_common.h b/tools/libxc/xc_sr_common.h
index ae0ab70f76..51e3d3ee3b 100644
--- a/tools/libxc/xc_sr_common.h
+++ b/tools/libxc/xc_sr_common.h
@@ -253,7 +253,7 @@ struct xc_sr_context
 /* Currently buffering records between a checkpoint */
 bool buffer_all_records;
 
-/* Whether a STATIC_DATA_END record has been seen. */
+/* Whether a STATIC_DATA_END record has been seen/inferred. */
 bool seen_static_data_end;
 
 /*
@@ -428,6 +428,9 @@ int read_record(struct xc_sr_context *ctx, int fd, struct 
xc_sr_record *rec);
 int populate_pfns(struct xc_sr_context *ctx, unsigned int count,
   const xen_pfn_t *original_pfns, const uint32_t *types);
 
+/* Handle a STATIC_DATA_END record. */
+int handle_static_data_end(struct xc_sr_context *ctx);
+
 #endif
 /*
  * Local variables:
diff --git a/tools/libxc/xc_sr_restore.c b/tools/libxc/xc_sr_restore.c
index 9c924387ae..bb94cd879d 100644
--- a/tools/libxc/xc_sr_restore.c
+++ b/tools/libxc/xc_sr_restore.c
@@ -342,6 +342,31 @@ static int handle_page_data(struct xc_sr_context *ctx, 
struct xc_sr_record *rec)
 xen_pfn_t *pfns = NULL, pfn;
 uint32_t *types = NULL, type;
 
+/*
+ * v2 compatibility only exists for x86 streams.  This is a bit of a
+ * bodge, but it is less bad than duplicating handle_page_data() between
+ * different architectures.
+ */
+#if defined(__i386__) || defined(__x86_64__)
+/* v2 compat.  Infer the position of STATIC_DATA_END. */
+if ( ctx->restore.format_version < 3 && !ctx->restore.seen_static_data_end 
)
+{
+rc = handle_static_data_end(ctx);
+if ( rc )
+{
+ERROR("Inferred STATIC_DATA_END record failed");
+goto err;
+}
+rc = -1;
+}
+
+if ( !ctx->restore.seen_static_data_end )
+{
+ERROR("No STATIC_DATA_END seen");
+goto err;
+}
+#endif
+
 if ( rec->length < sizeof(*pages) )
 {
 ERROR("PAGE_DATA record truncated: length %u, min %zu",
@@ -631,7 +656,7 @@ static int buffer_record(struct xc_sr_context *ctx, struct 
xc_sr_record *rec)
 return 0;
 }
 
-static int handle_static_data_end(struct xc_sr_context *ctx)
+int handle_static_data_end(struct xc_sr_context *ctx)
 {
 xc_interface *xch = ctx->xch;
 int rc = 0;
diff --git a/tools/libxc/xc_sr_restore_x86_pv.c 
b/tools/libxc/xc_sr_restore_x86_pv.c
index 16e738884e..3756225be6 100644
--- a/tools/libxc/xc_sr_restore_x86_pv.c
+++ b/tools/libxc/xc_sr_restore_x86_pv.c
@@ -679,6 +679,23 @@ static int handle_x86_pv_p2m_frames(struct xc_sr_context 
*ctx,
 unsigned int start, end, x, fpp = PAGE_SIZE / ctx->x86.pv.width;
 int rc;
 
+/* v2 compat.  Infer the position of STATIC_DATA_END. */
+if ( ctx->restore.format_version < 3 && !ctx->restore.seen_static_data_end 
)
+{
+rc = handle_static_data_end(ctx);
+if ( rc )
+{
+ERROR("Inferred STATIC_DATA_END record failed");
+return rc;
+}
+}
+
+if ( !ctx->restore.seen_static_data_end )
+{
+ERROR("No STATIC_DATA_END seen");
+return -1;
+}
+
 if ( !ctx->x86.pv.restore.seen_pv_info )
 {
 ERROR("Not yet received X86_PV_INFO record");
-- 
2.11.0

[Xen-devel] [PATCH v2 04/17] docs/migration Specify migration v3 and STATIC_DATA_END

[Andrew Cooper]

Migration data can be split into two parts - that which is invariant of
guest execution, and that which is not.  Separate these two with the
STATIC_DATA_END record.

The short term, we want to move the x86 CPU Policy data into the stream.
In the longer term, we want to provisionally send the static data only
to the destination as a more robust compatibility check.  In both cases,
we will want a callback into the higher level toolstack.

Mandate the presence of the STATIC_DATA_END record, and declare this v3,
along with instructions for how to compatibly interpret a v2 stream.

Signed-off-by: Andrew Cooper 
Acked-by: Ian Jackson 
---
CC: George Dunlap 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Wei Liu 
CC: Julien Grall 
CC: Marek Marczykowski-Górecki 
---
 docs/specs/libxc-migration-stream.pandoc | 39 +---
 tools/libxc/xc_sr_common.c   |  1 +
 tools/libxc/xc_sr_stream_format.h|  1 +
 tools/python/xen/migration/libxc.py  |  2 ++
 4 files changed, 40 insertions(+), 3 deletions(-)

diff --git a/docs/specs/libxc-migration-stream.pandoc 
b/docs/specs/libxc-migration-stream.pandoc
index a7a8a08936..22ff306e0b 100644
--- a/docs/specs/libxc-migration-stream.pandoc
+++ b/docs/specs/libxc-migration-stream.pandoc
@@ -127,7 +127,7 @@ marker  0x.
 
 id  0x58454E46 ("XENF" in ASCII).
 
-version 0x0002.  The version of this specification.
+version 0x0003.  The version of this specification.
 
 options bit 0: Endianness.  0 = little-endian, 1 = big-endian.
 
@@ -620,6 +620,21 @@ The count of pfns is: record->length/sizeof(uint64_t).
 
 \clearpage
 
+STATIC_DATA_END
+---
+
+A static data end record marks the end of the static state.  I.e. state which
+is invariant of guest execution.
+
+
+ 0 1 2 3 4 5 6 7 octet
++-+
+
+The end record contains no fields; its body_length is 0.
+
+\clearpage
+
+
 Layout
 ==
 
@@ -639,7 +654,9 @@ A typical save record for an x86 PV guest image would look 
like:
 
 * Image header
 * Domain header
-* X86_PV_INFO record
+* Static data records:
+* X86_PV_INFO record
+* STATIC_DATA_END
 * X86_PV_P2M_FRAMES record
 * Many PAGE_DATA records
 * X86_TSC_INFO
@@ -667,6 +684,8 @@ A typical save record for an x86 HVM guest image would look 
like:
 
 * Image header
 * Domain header
+* Static data records:
+* STATIC_DATA_END
 * Many PAGE_DATA records
 * X86_TSC_INFO
 * HVM_PARAMS
@@ -675,9 +694,23 @@ A typical save record for an x86 HVM guest image would 
look like:
 HVM_PARAMS must precede HVM_CONTEXT, as certain parameters can affect
 the validity of architectural state in the context.
 
+Compatibility with older versions
+=
+
+v3 compat with v2
+-
+
+A v3 stream is compatible with a v2 stream, but mandates the presense of a
+STATIC_DATA_END record ahead of any memory/register content.  This is to ease
+the introduction of new static configuration records over time.
+
+A v3-compatible reciever interpreting a v2 stream should infer the position of
+STATIC_DATA_END based on finding the first X86_PV_P2M_FRAMES record (for PV
+guests), or PAGE_DATA record (for HVM guests) and behave as if STATIC_DATA_END
+had been sent.
 
 Legacy Images (x86 only)
-
+
 
 Restoring legacy images from older tools shall be handled by
 translating the legacy format image into this new format.
diff --git a/tools/libxc/xc_sr_common.c b/tools/libxc/xc_sr_common.c
index dd9a11b4b5..7f22cf0365 100644
--- a/tools/libxc/xc_sr_common.c
+++ b/tools/libxc/xc_sr_common.c
@@ -36,6 +36,7 @@ static const char *const mandatory_rec_types[] =
 [REC_TYPE_VERIFY]   = "Verify",
 [REC_TYPE_CHECKPOINT]   = "Checkpoint",
 [REC_TYPE_CHECKPOINT_DIRTY_PFN_LIST]= "Checkpoint dirty pfn list",
+[REC_TYPE_STATIC_DATA_END]  = "Static data end",
 };
 
 const char *rec_type_to_str(uint32_t type)
diff --git a/tools/libxc/xc_sr_stream_format.h 
b/tools/libxc/xc_sr_stream_format.h
index ae7c0de393..81c9765b0a 100644
--- a/tools/libxc/xc_sr_stream_format.h
+++ b/tools/libxc/xc_sr_stream_format.h
@@ -73,6 +73,7 @@ struct xc_sr_rhdr
 #define REC_TYPE_VERIFY 0x000dU
 #define REC_TYPE_CHECKPOINT 0x000eU
 #define REC_TYPE_CHECKPOINT_DIRTY_PFN_LIST  0x000fU
+#define REC_TYPE_STATIC_DATA_END0x0010U
 
 #define REC_TYPE_OPTIONAL 0x8000U
 
diff --git a/tools/python/xen/migration/libxc.py 
b/tools/python/xen/migration/libxc.py
index 63b3558029..d0c4f3527d 100644
--- a/tools/python/xen/migration/libxc.py
+++ b/tools/python/xen/migration/libxc.py
@@ -56,6 +56,7 @@
 REC_TYPE_verify = 0x000d
 REC_TYPE_checkpoint = 0x000e
 

[Xen-devel] [PATCH v2 05/17] python/migration: Update validation logic to understand a v3 stream

[Andrew Cooper]

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Marek Marczykowski-Górecki 
---
 tools/python/xen/migration/libxc.py | 26 ++
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/tools/python/xen/migration/libxc.py 
b/tools/python/xen/migration/libxc.py
index d0c4f3527d..5fb51b56ac 100644
--- a/tools/python/xen/migration/libxc.py
+++ b/tools/python/xen/migration/libxc.py
@@ -119,6 +119,7 @@ class VerifyLibxc(VerifyBase):
 def __init__(self, info, read):
 VerifyBase.__init__(self, info, read)
 
+self.version = 0
 self.squashed_pagedata_records = 0
 
 
@@ -145,9 +146,12 @@ def verify_ihdr(self):
 raise StreamError("Bad image id: Expected 0x%x, got 0x%x" %
   (IHDR_IDENT, ident))
 
-if version != 2:
-raise StreamError("Unknown image version: Expected 2, got %d" %
-  (version, ))
+if not (2 <= version <= 3):
+raise StreamError(
+"Unknown image version: Expected 2 <= ver <= 3, got %d" %
+(version, ))
+
+self.version = version
 
 if options & IHDR_OPT_RESZ_MASK:
 raise StreamError("Reserved bits set in image options field: 0x%x" 
%
@@ -164,7 +168,8 @@ def verify_ihdr(self):
 "Stream is not native endianess - unable to validate")
 
 endian = ["little", "big"][options & IHDR_OPT_LE]
-self.info("Libxc Image Header: %s endian" % (endian, ))
+self.info("Libxc Image Header: Version %d, %s endian" %
+  (version, endian))
 
 
 def verify_dhdr(self):
@@ -424,6 +429,16 @@ def verify_record_checkpoint_dirty_pfn_list(self, content):
 raise RecordError("Found checkpoint dirty pfn list record in stream")
 
 
+def verify_record_static_data_end(self, content):
+""" static data end record """
+
+if len(content) != 0:
+raise RecordError("End record with non-zero length")
+
+if self.version < 3:
+raise RecordError("Static data end record found in v2 stream")
+
+
 record_verifiers = {
 REC_TYPE_end:
 VerifyLibxc.verify_record_end,
@@ -465,4 +480,7 @@ def verify_record_checkpoint_dirty_pfn_list(self, content):
 VerifyLibxc.verify_record_checkpoint,
 REC_TYPE_checkpoint_dirty_pfn_list:
 VerifyLibxc.verify_record_checkpoint_dirty_pfn_list,
+
+REC_TYPE_static_data_end:
+VerifyLibxc.verify_record_static_data_end,
 }
-- 
2.11.0


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

[Xen-devel] [PATCH v2 03/17] tools/migration: Drop IHDR_VERSION constant from libxc and python

[Andrew Cooper]

Migration v3 is in the process of being introduced, meaning that the code has
to cope with both versions.  Use an explicit 2 for now.

For the verify-stream-v2 and convert-legacy-stream scripts, update text to say
"v2 (or later)".  What matters is the distinction vs legacy streams.

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Marek Marczykowski-Górecki 
---
 tools/libxc/xc_sr_restore.c| 6 +++---
 tools/libxc/xc_sr_save.c   | 2 +-
 tools/libxc/xc_sr_stream_format.h  | 1 -
 tools/python/scripts/convert-legacy-stream | 6 +++---
 tools/python/scripts/verify-stream-v2  | 2 +-
 tools/python/xen/migration/libxc.py| 9 -
 6 files changed, 12 insertions(+), 14 deletions(-)

diff --git a/tools/libxc/xc_sr_restore.c b/tools/libxc/xc_sr_restore.c
index 5e31908ca8..dc2ffcf855 100644
--- a/tools/libxc/xc_sr_restore.c
+++ b/tools/libxc/xc_sr_restore.c
@@ -35,10 +35,10 @@ static int read_headers(struct xc_sr_context *ctx)
 return -1;
 }
 
-if ( ihdr.version != IHDR_VERSION )
+if ( ihdr.version != 2 )
 {
-ERROR("Invalid Version: Expected %d, Got %d",
-  IHDR_VERSION, ihdr.version);
+ERROR("Invalid Version: Expected 2, Got %d",
+  ihdr.version);
 return -1;
 }
 
diff --git a/tools/libxc/xc_sr_save.c b/tools/libxc/xc_sr_save.c
index fa736a311f..5c5ce18ac3 100644
--- a/tools/libxc/xc_sr_save.c
+++ b/tools/libxc/xc_sr_save.c
@@ -13,7 +13,7 @@ static int write_headers(struct xc_sr_context *ctx, uint16_t 
guest_type)
 struct xc_sr_ihdr ihdr = {
 .marker  = IHDR_MARKER,
 .id  = htonl(IHDR_ID),
-.version = htonl(IHDR_VERSION),
+.version = htonl(2),
 .options = htons(IHDR_OPT_LITTLE_ENDIAN),
 };
 struct xc_sr_dhdr dhdr = {
diff --git a/tools/libxc/xc_sr_stream_format.h 
b/tools/libxc/xc_sr_stream_format.h
index 37a7da6eab..ae7c0de393 100644
--- a/tools/libxc/xc_sr_stream_format.h
+++ b/tools/libxc/xc_sr_stream_format.h
@@ -23,7 +23,6 @@ struct xc_sr_ihdr
 
 #define IHDR_MARKER  0xULL
 #define IHDR_ID  0x58454E46U
-#define IHDR_VERSION 2
 
 #define _IHDR_OPT_ENDIAN 0
 #define IHDR_OPT_LITTLE_ENDIAN (0 << _IHDR_OPT_ENDIAN)
diff --git a/tools/python/scripts/convert-legacy-stream 
b/tools/python/scripts/convert-legacy-stream
index 2922fb3185..02a194178f 100755
--- a/tools/python/scripts/convert-legacy-stream
+++ b/tools/python/scripts/convert-legacy-stream
@@ -79,7 +79,7 @@ def write_libxc_ihdr():
 stream_write(pack(libxc.IHDR_FORMAT,
   libxc.IHDR_MARKER,  # Marker
   libxc.IHDR_IDENT,   # Ident
-  libxc.IHDR_VERSION, # Version
+  2,  # Version
   libxc.IHDR_OPT_LE,  # Options
   0, 0))  # Reserved
 
@@ -632,13 +632,13 @@ def main():
   usage = ("%prog [options] -i INPUT -o OUTPUT"
" -w WIDTH -g GUEST"),
   description =
-  "Convert a legacy stream to a v2 stream")
+  "Convert a legacy stream to a v2 (or later) stream")
 
 # Required options
 parser.add_option("-i", "--in", dest = "fin", metavar = "",
   help = "Legacy input to convert")
 parser.add_option("-o", "--out", dest = "fout", metavar = "",
-  help = "v2 format output")
+  help = "v2 (or later) format output")
 parser.add_option("-w", "--width", dest = "twidth",
   metavar = "<32/64>", choices = ["32", "64"],
   help = "Legacy toolstack bitness")
diff --git a/tools/python/scripts/verify-stream-v2 
b/tools/python/scripts/verify-stream-v2
index 8bac04d566..fe82b86c11 100755
--- a/tools/python/scripts/verify-stream-v2
+++ b/tools/python/scripts/verify-stream-v2
@@ -108,7 +108,7 @@ def main():
 
 parser = OptionParser(usage = "%prog [options]",
   description =
-  "Verify a stream according to the v2 spec")
+  "Verify a stream according to the v2 (or later) 
spec")
 
 # Optional options
 parser.add_option("-i", "--in", dest = "fin", metavar = "",
diff --git a/tools/python/xen/migration/libxc.py 
b/tools/python/xen/migration/libxc.py
index 8a800df980..63b3558029 100644
--- a/tools/python/xen/migration/libxc.py
+++ b/tools/python/xen/migration/libxc.py
@@ -19,7 +19,6 @@
 
 IHDR_MARKER  = 0x
 IHDR_IDENT   = 0x58454E46 # "XENF" in ASCII
-IHDR_VERSION = 2
 
 IHDR_OPT_BIT_ENDIAN = 0
 IHDR_OPT_LE = (0 << IHDR_OPT_BIT_ENDIAN)
@@ -113,7 +112,7 @@
 HVM_PARAMS_FORMAT = "II"
 
 class VerifyLibxc(VerifyBase):
-""" Verify a Libxc v2 stream """
+""" Verify a Libxc v2 (or later) stream """
 
 def __init__(self, info, read):
 

[Xen-devel] [PATCH v2 00/17] Support CPUID/MSR data in migration streams

[Andrew Cooper]

Here is v2 of the work to plumb CPUID/MSR data into the migration stream.

Patches 1 and 2 are cleanup.  3-8 are concerned with introducing the
STATIC_DATA_END record.  9-11 are some libxl work to reposition CPUID
construction during domain create.  12-14 are the introduction of the
X86_{CPUID,MSR}_DATA records, and 15-17 are the final adjustments in libxc and
libxl to use them.

This series does have a net change in behaviour for CPUID handing in migrated
domains.  See patch 16 for details.

Some acks are carried forwards from the v1 review.  Others are not.  The
majority change has been to shuffle the order of actions to hopefully make the
logic much more clear to follow.

~Andrew

Andrew Cooper (17):
  tools/libxl: Remove libxl_cpuid_{set,apply_policy}() from the API
  tools/libxl: Simplify callback handling in libxl-save-helper
  tools/migration: Drop IHDR_VERSION constant from libxc and python
  docs/migration Specify migration v3 and STATIC_DATA_END
  python/migration: Update validation logic to understand a v3 stream
  libxc/restore: Support v3 streams and handle STATIC_DATA_END
  libxc/restore: STATIC_DATA_END inference for v2 compatibility
  libxc/save: Write a v3 stream
  tools/libxl: Provide a static_data_done callback for domain restore
  tools/libxl: Plumb a restore boolean down into libxl__build_pre()
  tools/libxl: Re-position CPUID handling during domain construction
  docs/migration: Specify X86_{CPUID,MSR}_POLICY records
  libxc/restore: Handle X86_{CPUID,MSR}_DATA records
  libxc/save: Write X86_{CPUID,MSR}_DATA records
  tools/libx[cl]: Plumb 'missing' through static_data_done() up into libxl
  tools/libxc: Restore CPUID/MSR data found in the migration stream
  docs/xl.cfg: Rewrite cpuid= section

 docs/man/xl.cfg.5.pod.in   |  74 +-
 docs/specs/libxc-migration-stream.pandoc   |  81 ++-
 tools/libxc/include/xenguest.h |  11 +++
 tools/libxc/xc_cpuid_x86.c |   8 +-
 tools/libxc/xc_sr_common.c |   3 +
 tools/libxc/xc_sr_common.h |  35 -
 tools/libxc/xc_sr_common_x86.c | 120 +
 tools/libxc/xc_sr_common_x86.h |  25 ++
 tools/libxc/xc_sr_restore.c|  61 ++-
 tools/libxc/xc_sr_restore_x86_hvm.c|  10 +++
 tools/libxc/xc_sr_restore_x86_pv.c |  27 +++
 tools/libxc/xc_sr_save.c   |  20 -
 tools/libxc/xc_sr_save_x86_hvm.c   |   6 ++
 tools/libxc/xc_sr_save_x86_pv.c|  14 +++-
 tools/libxc/xc_sr_stream_format.h  |   4 +-
 tools/libxl/libxl.h|  26 ++-
 tools/libxl/libxl_cpuid.c  |   6 +-
 tools/libxl/libxl_create.c |  37 -
 tools/libxl/libxl_dm.c |   2 +-
 tools/libxl/libxl_dom.c|  20 +++--
 tools/libxl/libxl_internal.h   |  10 ++-
 tools/libxl/libxl_nocpuid.c|   6 +-
 tools/libxl/libxl_save_helper.c|  16 ++--
 tools/libxl/libxl_save_msgs_gen.pl |   3 +-
 tools/python/scripts/convert-legacy-stream |  13 +++-
 tools/python/scripts/verify-stream-v2  |   2 +-
 tools/python/xen/migration/libxc.py|  74 --
 27 files changed, 635 insertions(+), 79 deletions(-)

-- 
2.11.0


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